当业界热衷于讨论 AI Agent 的工具调用能力、记忆机制和多模态交互时，一个根本性的基础设施问题往往被忽视：AI Agent 缺乏像 Web 浏览器那样的「用户代理」（User Agent）角色定义。Mark Nottingham 在其最新博客中指出，当前 Agentic AI 系统的架构设计中，用户利益的代表机制几乎空白 —— 这不仅是一个信任问题，更是阻碍 AI 生态系统形成的结构性缺陷。本文从系统架构视角出发，分析这一缺失背后的工程化挑战与可能的解决路径。
从工具到代理： computing 范式的根本转变
过去数十年的计算历史建立在这样一个假设之上：机器执行用户明确的指令，且这种执行是本地化的。你购买一台笔记本电脑，它运行你安装的程序，存储你创建的文件 —— 软硬件的行为是可预测的、可审计的。超出预期行为的软件被归类为「恶意软件」，有明确的处理机制。这种范式延伸到物理工具：螺丝刀就是用来拧螺丝的，它没有「自主意图」。
然而，现代联网计算已经彻底打破这一假设。当你使用智能手机、智能手表或任何 IoT 设备时，你实际上在将大量信任委托给设备制造商及其云服务。这些设备可能在后台收集位置信息、活动数据，并将这些信息分享给第三方 —— 而用户往往毫不知情。Amazon Ring 摄像头允许「内部人员」和黑客访问用户视频、Meta 秘密解密竞争服务的流量以获取用户数据、智能汽车向保险公司分享驾驶行为 —— 这些并非孤例，而是正在「正常化」的信任滥用。
AI Agent 的出现将这一问题推向了更深层次。与传统软件不同，LLM 具有生成行为的能力 —— 它不只是执行预定义指令，而是可能「自主」做出决策。当一个 AI Agent 代表用户执行任务时，它实际上嵌入的是开发者的利益，而非用户的利益。用户无法像理解传统软件那样理解 Agent 将会做什么，更无法有效审计其行为。
用户代理的历史范式：Web 浏览器的启示
理解用户代理角色的最佳参照是 Web 浏览器。浏览器本质上是一种代表用户利益的软件 —— 它在用户与网站之间进行利益平衡：网站希望页面以可预测的方式渲染，用户希望保护隐私和使用辅助功能，这些 delicate tradeoffs 通过公开的标准制定过程（在 W3C 或 IETF 中以共识机制）来解决。
关键在于，浏览器提供的是「同一套交易框架」给所有人。用户无需与每个网站单独谈判权限 —— 如果每访问一个网站都需要就数据使用进行单独协商，用户很快就会因疲惫而放弃。浏览器实际上代表用户与整个互联网形成了一份「全球性条约」，通过市场力量（用户可以选择不同的浏览器）来约束网站行为。
这种设计的核心价值在于：第一，它创建了可预期的行为边界；第二，它通过标准化的公开流程形成共识；第三，它允许用户通过选择来施加市场压力。这三者共同构成了用户信任的基础设施。
Agentic AI 缺失的抽象层
对比 Web 浏览器，AI Agent 几乎在所有关键维度上都缺乏基础设施抽象。
首先，没有明确的 Agent 角色定义。什么是 AI Agent？它能做什么、不能做什么？目前没有标准化的答案。不同供应商的 Agent 行为各异，用户无法建立稳定的预期。Web 浏览器有明确的文档模型（DOM、CSS、JavaScript 暴露的 API），而 AI Agent 只有模糊的「能力」描述。
其次，权限模型缺失。浏览器有清晰的同源策略、CSP、Cookie 机制来控制网站能做什么。但 AI Agent 访问用户数据时，如何约束其行为？如果 Agent 可以访问用户的日历、邮件、文件存储，这些访问权限的边界在哪里？当前没有成熟的权限模型来表达这些约束。
第三，缺乏可审计的交互框架。Web 浏览器的每次网络请求都有明确的日志、开发者工具可以检查。但 AI Agent 的决策过程是一个黑箱 —— 用户无法知道 Agent 为什么做出了某个决定，也无法审计其与第三方服务的交互。
第四，市场机制缺位。用户可以切换浏览器来表达对隐私政策的偏好，但 AI Agent 的切换成本极高，因为 Agent 积累的上下文和适配的 prompt 难以迁移。
工程化缺失的具体表现
从工程实现角度，这些抽象层缺失转化为几个具体问题。
工具调用的无序扩张。当前 Agent 可以调用任意工具（API），但没有标准化的工具权限分级体系。一个 Agent 可以「请求」访问摄像头、读取文件、发送邮件 —— 这些权限请求的粒度、撤销机制、有效期都没有规范。可以类比：如果每个网站都可以无差别地请求摄像头权限，用户将疲于应付，信任很快崩塌。
状态与上下文的失控。传统 Web 应用有清晰的状态边界 —— 会话结束即状态清除。但 AI Agent 的记忆机制是一个持续增长的黑箱。用户无法知道 Agent 保存了哪些对话片段、这些片段如何被用于后续推理、是否被共享给第三方。
第三方服务的信任真空。当 Agent 访问第三方数据源时（例如查询天气 API、访问数据库），服务提供方无法判断这个 Agent 的意图。它可能声称用于某个合法目的，但也可能将数据用于其他用途。这种不确定性会阻碍数据提供方与 Agent 的合作。
可移植性的缺失。用户在一个 Agent 中积累的 prompt 工程、对话历史、工具配置难以迁移到另一个 Agent。这与 Web 的可互操作性形成鲜明对比 —— 网页可以在不同浏览器中一致渲染，但 Agent 的行为高度依赖特定实现。
走向成熟的基础设施组件
要建立生产级可用的 Agentic AI 系统，行业需要在几个基础设施层面达成共识并实现标准化。
标准化的工具权限分级。参考 OAuth 2.0 的 scopes 机制，定义 Agent 工具调用的权限级别。例如：只读 vs 可写、一次性 vs 持续有效、用户确认 vs 自动放行。这需要工具提供方和 Agent 平台共同遵守的规范。
可审计的交互日志。Agent 与用户、第三方服务的每次交互都应该有结构化的日志，支持用户事后审计。这不仅是技术问题，也涉及监管合规 ——GDPR 等法规要求数据处理的透明性。
沙箱与执行隔离。将 Agent 的执行环境与敏感数据隔离，参考 TEE（可信执行环境）或进程隔离技术。关键在于：隔离不仅是安全措施，更是建立信任的基础 —— 用户需要确信 Agent 无法绕过限制。
用户控制的代理层。借鉴浏览器扩展的许可机制，让用户在更细粒度上控制 Agent 的行为。例如：允许 Agent 访问特定域名的资源、限制数据保留期限、要求特定操作前确认。
标准化的 Agent 描述语言。参考 Web 的 IDL（接口定义语言），定义机器可读的 Agent 能力描述文件。第三方服务可以通过这个描述判断 Agent 的可信度、决定是否授权访问。
结语
当前 Agentic AI 的发展重心仍在「能力」—— 更好的推理、更多的工具调用、更自然的对话。但正如 Mark Nottingham 所指出的，能力扩张如果没有同步建立「代理角色」的抽象层，最终会陷入信任危机。当每个 Agent 都可以不受约束地访问用户数据、调用第三方服务时，AI 带来的便利将被持续的安全事故和隐私侵犯所抵消。
Web 浏览器用了数十年时间通过公开标准、共识机制和市场力量建立起用户代理的信任框架。AI Agent 需要的不是另一次「能力竞赛」，而是对这一基础设施问题的正视与系统性解决。唯有如此，Agentic AI 才能从技术展示走向真正的规模化应用。
资料来源：本文核心观点参考 Mark Nottingham 博客文章《What's Missing in the 'Agentic' Story》（2026 年 4 月 24 日），原载于 mnot.net。