Web 作为系统能力
今天要上线一个网站，通常不难。难的是让它真正成为一个可以长期使用的地方。
一篇文章需要页面、域名和部署。有人读完想回应，就需要身份、审核和通知。内容多起来，需要搜索、索引和权限。再往前一步，站点要接入 API、允许同事协作、让 agent 帮忙维护，事情很快从“发布一个网页”变成“运营一套应用”。这不是现代 Web 做错了什么。数据库、应用服务器、前端运行时和托管平台，都是为真实需求而出现的。问题在于，今天常常把这些需求绑成一个默认前提：想发布自己拥有的信息，先要部署并管理一套应用。
我想讨论的不是怎样回到早期静态主页，也不是说所有网站都应该放弃框架。更准确的说法是：一个网站可以是一套应用，但它不该只能是一套应用。 对大多数发布型页面而言，公开呈现、基本身份、权限和回应，应该是计算环境本身能提供的能力；复杂的实时协作、业务流程和专用运行时，则应在需要时再向上生长。
这也是 ARC（Agentic Realm Computer）把 Web 设计成一种 device 的出发点。它并不把 Web 简化成“一个文件夹”，也不把 Web Device 单独说成身份或互动系统。ARC 的共同模型是 AFS（Agentic File System）：发布、检查、经验证的调用者身份、授权上下文和可调用动作，都可以在同一套系统语义中协作；Web Device 是其中面向公开发布的一面。这一篇是整个系列的总览：先回到 Web 为什么会变复杂，再解释为什么 ARC 的答案不是再造一个建站框架。
Web 最初把发布做得很直接
Web 最早的吸引力，并不只是超链接或浏览器本身。它让一份可读的内容有了一个可以被分享的地址。HTML 是 SGML 的一个应用，但它没有要求每个作者先成为网络管理员或计算机科学家，才可以把文字、链接和图片组织成一个可访问的页面。早期的个人主页，以及后来的 Apache UserDir 和 macOS Personal Web Sharing 等个人发布模式，进一步把这种直觉放进了日常使用里：把内容放进一个自己拥有的空间，它就有机会成为别人可以访问的页面。
Separate concerns instead of one tangled web stack.
同一件“小事”的手感后来不断变化。早期作者可能是在共享主机上改一份 index.html，把自己的 URL 发给朋友；博客时代的作者在网页后台写一段新日志，读者从固定链接和按日期排列的首页进入；应用栈时代的编辑把内容写进 CMS，开发者则要同时照顾构建、数据库、部署和权限。每一步都带来了真实的便利，但“发表一份自己的东西”与“运营一套完整系统”也慢慢被绑在了一起。
这当然从来不是无条件成立的。public_html 是 Web 服务器的约定，不是 Unix 自动送给每个人的公网主页；Mac 的 Sites 目录也仍需要 Web Sharing、网络和安全配置。可它们留下了一个很有价值的心智模型：发布的起点是作者拥有的资源，而不是一个遥远平台替作者保管的“应用实例”。
在 Web 走向大众之前，Gopher 也是访问互联网信息的重要方式。Web 的扩散并不是某一个技术特性战胜了一切，而是链接文档模型、图形浏览器、跨平台分发，以及开放实现和许可条件共同降低了参与门槛。这里值得保留的不是“过去比较简单”这种怀旧，而是一个更朴素的问题：发布一段内容时，作者究竟要操作多少彼此无关的系统？
ARC 在这里并不主张把世界退回成静态目录。AFS 是一种文件系统抽象，而不是传统目录树的复刻。它的价值在于让内容、配置、数据和可调用能力可以进入同一个可寻址的事实模型。文件的直接性因此不是功能上限，而是系统边界的起点。
Web 变成应用系统，是一次真实的进步
一旦 URL 可以调用程序，Web 就不再只能返回预先写好的文件。CGI 让服务器能够根据请求执行程序并生成响应；模板语言让页面与数据更容易组合；CMS、应用服务器和数据库又让大量内容、用户和业务状态可被管理。后来浏览器中的 JavaScript 日益强大，Ajax、单页应用和前后端分层把实时交互推到新的高度。今天的服务器渲染、静态生成和边缘部署，看起来像某种“回归”，其实是对性能、可索引性和开发体验的重新权衡。
因此，复杂并不应被写成敌人。一个协作文档、实时交易界面或多方工作流，确实需要持续状态、事件处理、隔离和更细的安全策略。问题是，现代实践往往让一篇文章、一个产品页和一个复杂应用从同一条部署流水线开始，然后再让每个团队分别补上内容管理、搜索、登录、评论、监控和权限。
这也是为什么静态站点生成器和托管平台虽然大幅降低了发布门槛，却没有终结这个问题。它们很好地解决了“把内容送到 Web 上”这一段。可一旦读者要登录、回应、收藏、协作或订阅，作者常常又要接入另一套身份系统、另一套评论服务、另一套数据与审核逻辑。发布被简化了，交流却重新碎裂了。
ARC 的判断不是要否认这些工具，而是要把它们各自反复实现的公共部分向下沉。Web Device 是 ARC 中面向公开、可索引的文档和内容页面的发布能力。它从声明的站点资源、页面内容和主题中组装 HTML，并把构建、预览、链接与 SEO 检查、发布等工作放进系统的同一条路径。它不是任意应用的替代品，也不承诺让所有动态工作负载变成静态页面。它回答的是更窄的问题：当一件事主要是发布时，作者是否必须先运营一整套应用，才配拥有一个专业的站点？
可以把这个切法理解成一个很小的契约。发布型站点只声明内容、呈现和它愿意开放的互动方式；ARC runtime 为使用它的应用提供经验证的调用者身份与授权上下文，Web Device 复用构建和发布路径。需求一旦变成实时编辑、拖拽或协作，就交给 UI Device；需求一旦变成特殊业务和专用数据源，就交给更高层的 provider 或应用。这不是消除运维、安全或审核责任，更不是让站点自动信任外部身份。它只是避免把同一批基础工作在每个小站点里重新发明。
发布之后，Web 还应该能回应
博客工具的流行曾经给出过一个不同的答案。它们把持续发帖、时间归档、模板和托管收进比传统 CMS 更轻的工作流。Weblog 不是个人表达的起点，却把“反复发布”变成许多人实际做得到的事。TrackBack 随后提出了一个同样重要的想法：回应可以留在回应者自己的站点上，同时让原文的作者知道这条回应存在。
这样的时刻并不只有博客。个人主页、可视化编辑器、Apple 的 HomePage 和 iWeb、托管博客，以及一度能把公开文件夹变成静态页面的云盘服务，都曾把发布能力交还给普通人。它们的产品形态各不相同，但共同说明了一点：人们一直想拥有可直接表达和分享的空间。详细的产品史会放到本系列的编年目录；这里要看的只是，它们为何没有让发布、互动与长期控制同时变成默认能力。
今天的 Webmention 延续了这种 linkback 思路。它让一个页面能够通知另一个页面“我链接了你”，而接收方会验证这条链接是否真的存在。这个机制比早期的 TrackBack 更强调可验证性，但它不是一个现成的评论系统。接收端仍要自己处理发现、验证、存储、反滥用、审核和呈现。也正因为如此，许多独立站点最终选择关闭评论，或把对话让给另一个中心化平台。
这里的缺口很具体。读者在一篇文章下留下评论、表达 reaction、订阅后续内容，表面上是几个小功能，底下却至少涉及身份、作者归属、写入权限、审核、记录和展示。如果每个发布者都要从零拼起这条链路，独立发布就很容易退化成“只读发布”。这也帮助解释了为什么，不少独立发布最后把对话放到另一个平台，或干脆不再开放回应。
ARC 的现有 runtime 已经把其中一部分做成了通用能力：系统可以向使用它的应用提供经验证的调用者身份与授权上下文；评论与 reaction 可以复用同一套作者归属、所有权和管理员删除规则。Web Device 的预渲染页面也能够接入 ARC runtime 的评论表面，而不要求它自己变成一条长期保持的实时会话。完整讨论板、订阅通知、复杂 feed 和专门的社交产品仍然是更高层的应用问题。Discuss Kit 仍然是完整讨论板的参考应用，而其中跨项目反复出现的互动原语正在被下沉为共享能力。这里真正下沉的不是所有社区产品，而是它们一再重写的基础部分。
为什么 ARC 把 Web 当成一种 device
在 ARC 中，Web Device 和 UI Device 的分工是刻意分开的。前者负责发布型的 Web：把内容、AUP（Agentic UI Protocol）页面、站点声明和资源装配成面向读者的页面。后者负责持续的交互式界面：维护会话、接收事件、返回增量更新。它们共享 AFS 的路径语义和 AUP 的界面表达，但并不假装是同一种运行模式。
这个分工的意义不只是性能或渲染方式。它把“我要让世界读到这份内容”和“我要让一个用户持续操作这个界面”还原为两种不同的系统责任。前者可以强调稳定、可索引、可预览和可发布；后者可以强调会话、事件、状态和设备能力。经验证的调用者身份、授权上下文和动作不需要在两边各造一遍，它们属于更底层的计算环境。
所以，称 Web 为 device 并不是说一个网站等同于键盘、屏幕或 agent。更准确地说，ARC 把公开 Web 发布提升为一种可发现、可调用、可检查的系统 surface。在适合发布型内容的场景里，一个 blocklet 或 agent 可以复用 Web Device 的构建和发布路径，沿着同一套 AFS 语义读取事实、产生页面、检查结果并执行发布。需要更特殊的数据源、复杂业务或专用交互时，仍然可以通过更高层的 provider 和应用去承担。
这也解释了 ARC 为什么同时强调“同构”与“开放”。同一套 ARC 语义下的站点，可以更自然地复用身份、记录和互动规则，但这不意味着它们自动共享用户数据、信任或权限，相关授权仍需由站点和用户明确作出。面向 ARC 之外，Webmention 和 ActivityPub 则是值得对接的开放方向：前者适合跨站确认可验证的引用，后者提供 Actor、活动与 inbox/outbox 的联邦模型。两者都不是零配置的评论按钮，也都还不是 ARC 已经交付的兼容层。开放的意义不在于声称今天已经兼容一切，而在于不把内部的便利设计成外部的围墙。
复杂性不该消失，它应该换一个位置
一个现代网站当然仍可能是一套复杂应用。但应该有另一种可能：当需求只是发表文章、维护一个产品页、分享资料或组织一组内容时，作者先得到的是一个属于自己的发布空间；当读者需要回应时，身份、权限和基础互动不必重新从零拼装；当需求发展为实时协作或专用业务，应用再在清晰的系统边界上生长。
这不是把 Web 变回 1990 年代。早期 Web 的直接性之所以值得重新理解，不是因为它的能力足够，而是因为它把“我拥有的内容可以被我发布”看作自然起点。今天真正值得追问的是：在 agent 能帮助人们创建和维护软件之后，为什么拥有一处能够发布、交流并持续演进的 Web 空间，仍然像部署一个小型基础设施项目？
ARC 对这个问题的回答还在构建中。它的可取之处不在于宣称已经替代所有框架，而在于先把问题拆开：公共发布不是一套应用的副作用，基础互动不是每个作者的插件负担，开放互操作也不应等到所有人使用同一个平台才被考虑。后续文章会分别展开 Web 从目录到程序、从应用栈到浏览器 runtime、从 weblog 到 linkback 的过程，也会更具体地说明 Web Device、UI Device 和 AFS 各自该承担什么。
延伸阅读与事实边界
完整的编年目录、术语表和逐项来源会作为本系列的参考子页维护。本文只使用这些事实来说明论点，不把它们当作一条必然的技术进步史。