当 URL 开始调用程序
早期 Web 的一个页面，常常可以想成服务器返回的一份文件。这个模型极其适合文档：地址大致对应资源，资源被读取，浏览器把它呈现出来。可一旦站点要根据请求显示不同结果，收集表单、查询库存、处理登录或生成个性化内容，文件就不再足够了。
CGI 的意义正在这里。它给 Web 服务器一套共同接口，让请求能够调用程序，再把程序生成的响应送回浏览器。今天回头看，早期 CGI URL 中经常出现的 cgi-bin 和长 query string 显得笨拙，但它们记录了一次真正的扩张：一个 URL 不必只指向已存在的页面，也可以触发一次计算。
这个变化不该被写成“URL 从此脱离了文件系统”。早期 CGI 往往仍然从服务器上的可执行文件开始，路径、部署与权限仍紧密相关。更准确的说法是，Web 从此可以把资源、输入与动作组合起来。页面不再只是存放好的东西，也可以是一个根据上下文生成的结果。
从访问者的角度看，那个年代的变化很直观。一个人打开目录页，填写搜索框或注册表单，点击提交；浏览器把输入带进请求，地址栏常会出现 cgi-bin 和很长的 query string。服务器调用一个 CGI 程序，程序查询数据或处理表单，再返回一份新的 HTML 页面。界面通常仍是一页一页地重新加载，但页面第一次能根据“我刚刚输入了什么”改变内容。对当时的开发者而言，站点开始同时包含页面文件、可执行程序、权限和输入处理，而不再只有一个能被复制的目录。
动态页面不是静态页面的敌人
随后，PHP、Classic ASP 等服务器端脚本与模板技术，把 HTML、数据访问和程序逻辑放得更近。它们减少了手工拼接响应的痛苦，也让一份页面可以复用布局、读取数据、根据条件呈现不同内容。对于新闻站、论坛、商店和后台系统，这不是多余的复杂度，而是使 Web 有用的前提。
这也是为什么“所有页面都应该回到 Markdown”从来不是一个严肃的答案。内容有时是文章，有时是查询结果，有时是表单状态，有时是某个经过权限判断后才能看到的资源。真正的挑战不是选择文件或程序，而是让两者不必在每个项目里重新发明彼此的边界。
传统 Web 框架通常从应用开始设计这件事。开发者建立路由、控制器、模板、数据库模型和身份中间件，再决定哪些请求返回 HTML，哪些请求返回 JSON。这个模式给了应用充分的自由，也把许多共通责任压到每一支团队身上。发布型页面和高度定制的业务流程，于是从同一个项目骨架起步。
ARC 的切法不同，但并不否认程序化 Web。AFS 里既可以有可读取的资源，也可以有可执行的 action；provider 可以把外部系统、数据或专门逻辑挂到统一路径上。这样，计算不是文件模型的例外，而是同一套可寻址系统中的一种能力。页面要读取数据、调用一个受控操作或显示某个状态时，不必先假设它们来自一个传统 Web 框架的私有内部。
把动作放进模型，不等于把复杂性藏起来
这里很容易产生一个误会：既然 action 和 provider 可以被 AFS 表示，是否意味着任何复杂应用都能被几句声明式配置取代？不是。特殊业务、第三方服务、性能敏感的计算和复杂数据结构，仍然需要清晰的实现和运行边界。Provider 的存在恰恰承认这一点，它是扩展系统能力的地方，而不是把代码假装消失的地方。
真正改变的是重复劳动的位置。一个发布型页面可以复用内容、站点声明、身份上下文和发布检查；一个特殊应用可以只为特殊部分写 provider 或应用逻辑，而不必从页面、认证和发布重新开始。对 agent 而言，这种差别尤其重要：读、写、查找和执行都走一致的系统接口，减少了“先理解一套业务私有 API，再理解另一套部署脚本”的断裂。
这并不会让 action 天然安全。动作仍要受权限、调用者身份、输入校验和能力边界约束。ARC 的价值不在于把这些限制绕开，而在于把它们表达为系统的共同责任，而不是每个页面临时添加的一段防护代码。
从“程序生成页面”到“系统生成发布面”
这也是 Web Device 的位置。它并不是一个通用 CGI 替代品，也不是让浏览器上的互动消失。它面向的是另一类稳定需求：当内容、结构和站点规则已经有可理解的声明时，系统可以把它们装配为 HTML，并沿着同一条路径做预览、检查和发布。
一个需要持续响应输入的界面，仍应该由 UI Device 或其他应用 runtime 维护会话；一个需要专用后端的系统，仍应使用专用 provider。Web Device 的贡献是让“把受管理的事实变成可读的 Web”不再等同于“重新建立一个应用服务”。这不是缩小 Web，而是把 Web 中已经不同的责任重新分开。
下一篇会继续看这种分开为何越来越难。CMS、数据库、应用服务器与浏览器 runtime 共同让 Web 更强，也让一套小站点越来越像一个需要持续运营的软件系统。