为什么在 ARC 里，Web 是一种 Device，而不只是一个应用
前面几篇讲了同一件事的两面。Web 一开始把发布做得很直接，随后又必须学会执行程序、管理状态、承载复杂交互。问题从来不是某一种演进走错了，而是这些能力后来常常被打包成同一个默认前提：想发布一份内容，先运营一套应用。
ARC 对这个前提的回答，是把 Web 当作一种 Device。这里的 Device 不是把网站比作键盘、屏幕或一块物理硬件，也不是说所有设备有同样的运行方式。它指的是一种由 runtime 直接识别的输出面：AFS 中已经存在的资源、声明和数据，可以通过一个被系统理解的设备，变成特定对象能够读取或操作的表面。对 Web Device 来说，那个表面就是可发布的文档型 Web。
用今天常见的工作现场来对照会更容易理解。一个团队要做内容站，通常会在代码仓库、CMS、构建服务、云端部署控制台、身份服务和评论插件之间来回切换。在 ARC 的模型里，站点的内容、页面声明和数据来源先落在同一套 AFS 路径语义中；Web Device 把适合公开阅读的部分构成页面。读者看到的仍是一张正常的 Web 页面，而不是文件浏览器。变化发生在作者和系统之间：发布不必先从拼出一套独立 Web 应用开始。
这个名称的价值在于边界。一个网站不再首先被假定为某个框架里的应用项目，而可以先被理解成一组待发布的事实。它当然仍可连接应用、调用动作、读取动态数据，但“把这些东西组织成可读网站”本身，成为 runtime 的一项责任。
两条通向浏览器的路，不是一条路的不同包装
ARC 里很容易混淆的地方，是浏览器同时可以承接两种完全不同的工作。
第一种是 Web Device。它面向文档和发布：站点有怎样的全局声明，哪些页面和内容要被发现，怎样组成 HTML，怎样预览、检查、发布。它适合文章、文档、产品介绍、内容集合，以及那些读者首先需要稳定 URL 和可读取输出的页面。Web Device 不维持一个长期的浏览器会话；它生成的是可发布的输出。
第二种是 UI Device。它面向仍在进行中的交互：用户输入后立即校验，拖拽后立即重排，多人协作时持续更新，或一个应用需要维持会话和事件通道。它把 AUP，即 Agentic UI Protocol，作为描述界面与交互语义的方式，再由浏览器等 renderer 在会话中呈现。它不应该被伪装成一张静态页面，正如一篇文章也不应被迫变成一套常驻应用。
两者共享 AFS 和 AUP 的许多语义，却承担不同的生命周期。Web Device 不以持续会话为前提，优先产出稳定、可检查、面向发布的页面；UI Device 则以持续会话承接实时状态和操作。把它们都叫作 Device，不是为了模糊差异，恰恰是为了让系统能先识别这种差异，再选择正确的输出路径。
这也解释了为什么“Web Device 能否做所有网站”不是一个有价值的问题。实时协作、重度浏览器能力、专门业务服务和高频状态同步，仍然需要 UI Device、provider 或其他运行时。反过来，很多内容页面也不该因为整个系统里存在这些需求，就被迫继承全部应用复杂度。
该下沉的不是一套框架，而是重复出现的责任
现代 Web 项目里有一类工作几乎每次都会出现：识别当前调用者，判断其可访问的范围，读取或修改受控资源，记录谁创建了什么，以及把结果呈现给读者。不同框架给这些工作取了不同的名字，最后却常常由每个项目重新接一遍身份库、权限中间件、表单处理和评论插件。
ARC 的判断不是“这些问题从此不需要设计”，而是其中一部分不该每次从页面层重新发明。一个使用 runtime 的应用可以获得经验证的调用者身份和授权上下文；评论和 reaction 这类通用操作可以由服务端推导作者归属，并按配置的所有权与权限规则处理。对发布型页面而言，这意味着一篇预渲染文章也可以接入受控的回应表面，而不必为了一个评论区先拼装另一套独立系统。
需要把这句话说得准确一些。runtime 提供身份、角色和操作边界，并不自动生成完整的注册流程、团队后台、订阅系统或社区治理产品。完整讨论板、通知网络、复杂 feed 和业务特有审批，依然属于更高层的应用选择。ARC 没有把这些差异抹平；它试图减少的是那些本来就不该每个站点重复做一遍的公共底座。
可以把这种分工压缩成一个很小的契约：
- 发布者声明内容、结构、呈现，以及选择接入的互动能力；
- ARC runtime 提供已验证的调用者与授权上下文，并执行受控动作；
- Web Device 把适合发布的事实构成可预览、可检查的 Web 输出；
- UI Device 承担必须保持实时的交互；
- 真正特殊的业务、外部系统和计算，由 provider 或专用应用明确承担。
这不是“少写代码”那样笼统的承诺。它是把代码和复杂性推回它真正有差异的地方。一个站点不必先造自己的认证、构建和评论管线，才能发布一篇文章；一个复杂产品也不必假装自己只是一份站点声明。
AFS 是共同事实面，不是旧式目录的复刻
这套切法之所以可行，靠的不是把传统文件夹包装得更漂亮。AFS 是一种文件系统抽象：资源、内容、配置、索引、数据 provider 和可执行 action 可以被组织在同一套可寻址空间中。对 Web Device 来说，它提供的是一个可发现的事实面，而不是要求所有数据都变成磁盘上的 HTML 或 Markdown。
一个内容集合可以由目录和元数据表达；需要查询或索引时，可以通过相应的 provider 提供；需要执行某个操作时，可以走明确的 action。Web Device 从中负责发布性呈现。这样做的价值，不是宣称“文件系统胜过数据库”，而是避免作者为了让同一份事实出现在网页上，再维护一份脱离来源的复制品。
对 AI agent 来说，这个共同事实面也很重要。一个 agent 不必先猜测某个站点把内容藏在哪个私有 CMS、把动作分散在哪些脚本里，再另学一套部署步骤；它可以沿着系统已经暴露的路径、权限和声明理解工作。不过这也不是一句“agent 已经可以操作任何界面”的许诺。AUP 的目标是让界面的语义和重要操作更可描述，具体能力仍取决于实现的 renderer、会话和授权边界。
Web 曾经把发布从一项专业运维任务变成普通人的日常动作。ARC 想恢复的不是当年的技术限制，而是那种合理的默认值：发布是计算环境本来就能做好的事；应用是在需要独特逻辑时才进入的下一层。下一篇会继续追问，若许多站点共享这一层公共语义，它们怎样更容易交流，又怎样避免把这种便利变成另一堵围墙。