从超文本到平台系统，Web 一直是人类连接信息、组织资源的基础设施。而 Agent（智能体）与 Web 的深度集成，正在以更高效智能的方式重构人与数字世界的交互范式。Agentic Web（智能体网络）的出现，标志着 Web 从面向人类用户的交互系统，过渡到以 Agent 为交互主体的网络形态。

这一形态包括两个纬度：一方面， Agentic Web 是 Agent + Web 的集成体。Agent 作为 Web 的主要使用者与感知者，成为访问网络服务的入口。同时，Web 架构也逐步向 Agent 原生友好的方向演化，为 Agent 的感知、规划、行动提供底层支持；另一方面，Agentic Web 也是由多个 Agent 组成的协作网络。在其中，Agent 分化为不同的角色，基于协议互操作，构成一个任务驱动、动态编排、共享能力的多智能体系统。无论是 Agent 嵌入 Web 架构、Agent 组成 Web 的演化，都驱动着网络形态的深层转变。

本文试图系统性地梳理 Agentic Web 的核心组成，围绕以下五个层面展开：1）意图驱动，2）Web 感知交互，3）任务执行，4）多 Agent 协作，5）价值流通，探讨 Agentic Web 形态背后的系统结构、演化趋势与挑战。

1. 人类意图层（Human Intent Layer）

Agentic Web 的起点，是 Agent 感知和理解人类表达的意图和目标。

意图传递

用户可通过自然语言、语音、图像、GUI 操作或其他传感器输入，以多模态方式表达其需求与意图。Agent 的任务不止是理解字面指令，而是构建意图图谱：一个反映用户真实目标、约束条件与偏好偏向的结构化语义图。这要求 Agent 在表层解析基础上，进一步识别核心目标、任务结构、优先级关系与可接受的执行方式等深层语义。Agent 需要以下路径：

• 多模态意图处理：将来自多源的输入（语音、文本、图像、手势等）统一转化为结构化语义表示。例如，用户语音说“我想去这儿旅行”，同时上传一张风景照并在地图上点击位置，Agent 应能综合语音识别、图像理解与手势定位，生成一条明确的意图链：包括目的地、时间、预算与偏好等要素。这类多模态融合通常依赖跨模态嵌入模型，以统一不同感知信号的语义空间。
• 上下文与语义记忆：配合上下文历史与用户画像进行动态解析。例如，当用户说“订上次那家酒店三晚”，Agent 应从历史对话中调取对应酒店记录，推断出“那家”具体指代谁。同时，Agent 还需持续积累用户的偏好与行为反馈，构建可更新的语义记忆图谱，提升长期交互质量。
• 意图解析与目标图构建：将自然语言请求映射为可执行的目标结构，抽取动作、对象、约束与条件等要素。对于复杂任务，这一过程可递归展开，形成分层的任务图。例如，一次旅行请求可被分解为“预订航班”“选择住宿”“安排接送”等子任务，每个节点附带参数与约束条件。该过程通常结合专用意图解析器、领域本体（Domain Ontology）与微调的大模型协同实现，从而兼顾语义泛化与任务精度。

生成式 UI

Agent 获取用户初始意图后，并非所有任务环节都完全在后台完成。Agent 常需要与用户交互以补充信息、获取确认或展示结果。生成式 UI 是 Agent 按需即时生成的交互组件，不依赖预制的静态界面。

• 从静态到动态的 UI 组合：Agent 可通过输出结构化的 Schema（如 JSON 或 DSL）来描述页面布局与组件结构，例如包含图片、价格、按钮的商品列表。这些 Schema 由前端系统实时渲染为用户界面，使交互界面高度上下文相关且可定制。同一份 Schema 还可在 Web、移动端等多平台上复用渲染，减少逐端开发成本。
• 生成式与复用式组件的混合机制：在实际部署中，Agent 不必从零构建所有 UI。平台通常提供通用组件库（如按钮、表格、模态框），Agent 可在生成 Schema 时调用这些组件，实现灵活编排的同时保持一致性与性能。生成式适合新颖 / 高度个性化、缺乏固定 UI 的场景；复用式更适合高频、稳定、对性能 / 安全敏感的流程（如结账）。所以实际系统多为混合策略，对独特场景自动生成结构，对标准流程调用模板，从而兼顾实时适配与稳定高效。

生成式 UI 也是 Agent 显性化其计划与行为、接受人类干预的重要手段。它提升了任务执行的可解释性，并构建起 Agent 与用户之间的信任机制。当用户初始指令模糊或上下文不明确时，Agent 可生成澄清式 UI，引导用户逐步补全意图，从而实现更精准的任务规划与执行。

权限

Agent 感知和理解人类意图的关键之一，是明确它在什么范围内被允许代表用户采取行动。可以将其视为一份“意图契约”：用户主动授予 Agent 某些自主权限，并设定边界。尤其是在涉及交易、数据访问等敏感任务时，Agent 只有在用户明确授权的前提下才可执行。

因此，用户需为 Agent 配置如下约束条件：1）预算上限与风险阈值：例如，“单笔支付不得超过 100 美元”，或按商品类别、频率设定支出限额。同时可定义风险触发器，如涉及披露个人信息或执行高金额转账时，必须请求用户确认。2）许可动作与自主开关：用户可以启用或关闭某些权限，如“允许自动购买数字商品”、“允许雇佣其他 Agent”、“允许绑定实名账户”等。这实质上构成了一种能力导向的访问控制机制，每个 Agent 的行为权限都被限制在带时限和上下文范围的白名单中。明确权限边界不仅保护用户，也有助于 Agent 聚焦在其可执行空间内优化方案。比如，一个具备预算意识的 Agent，会优先在成本与风险可接受的范围内进行规划与推荐。

为实现这些边界，有多种技术机制：

• 面向 Agent 的委托式 OAuth：在传统 OAuth 2.0 基础上扩展，允许用户向 Agent 委托具有边界的访问令牌（Access Token）。例如 IETF 草案中提出了专为智能体设计的 AI agent 授权类型，用户可明确授予特定作用域（scope）的权限。Agent 以自身身份参与授权流程，获得短时效、可撤销、可审计的 Token。该 Token 中可嵌入“代表哪位用户行动的 Agent 身份”字段，形成清晰的委托关系链。这种机制支持 Agent 独立运行并执行任务，服务方可根据 Token 结构验证其合法授权来源。
• 签名意图令牌（JWT）：用户意图可被编码进 JWT，并由用户或可信机构进行签名，从而为 Agent 的每一步行为附加密码学担保。该令牌可包含原始请求内容（或其哈希）、授权参数（如预算、时间窗口）。Agent 调用服务时附带 JWT 作为证据：“授权做 X，用户在 T 时刻签署了 Y。“ 服务方可验证该 Token 是否与执行行为一致，确保其确实源于用户真实意图。在多 Agent 委托链中，每次转移都可追加一层签名，构成可验证的链式信任结构。这种方法比 OAuth 更通用，支持脱机验证、异步调用、跨平台协作等复杂场景。
• 可验证凭证授权（Verifiable Credential, VC）：W3C VC 标准为表达声明（如权限、身份、资格）提供结构化签名格式。用户可向 Agent 签发 VC 表达其权限范围。服务方在接收 Agent 请求时可验证 VC 签名、颁发者、时效性等元数据。VC 支持精细粒度（如类别、金额、时间、地点等）授权控制，并可通过 CRL（撤销列表）或 VC 状态服务进行吊销。在多 Agent 协作或雇佣场景下，VC 亦支持链式委托，Agent A 可将权限转授 Agent B，同时保留授权链可验证性。

小结：意图驱动行动生成，授权界定执行边界。通过意图传递、可生成 UI、授权追溯机制，系统得以实现从人类意图到自主执行的闭环，为后续的交互、执行和协作奠定基础。

2. Web 交互层（Web Interaction Layer）

在 Agent 明确人类目标意图之后，需要接入具体的任务环境，进而感知外部世界、评估状态变化，并据此采取行动。Web 交互层是 Agent 与外部世界建立链接的接口，它承载两个核心职责：1）感知外部环境（Perception），包括理解网页内容、界面状态等；2）执行操作指令（Action），即在页面上完成点击、输入、导航、提交等任务。Agent 的行动链路由此展开，实现意图的落地执行。

环境容器

在 Agent 能够感知与操作数字环境之前，首先需将其嵌入一个可控的执行容器中，使其具备对目标网页的访问、状态读取、交互执行与结果回馈的能力。当前主流系统主要采用两类 Web 接入方式：可视化浏览器容器（Visual Browser） 与 无头浏览器（Headless Browser），前者支持图形化界面渲染，后者则更轻量、适合结构化 DOM 感知。

• 可视浏览器容器（Visual Browser）提供带图形用户界面（GUI）的浏览器实例，通常构建于 Chromium 内核，辅以自动化控制框架如 Selenium、Playwright、Puppeteer 等。该容器不仅能渲染页面，还支持精细化交互操作，如鼠标移动、点击、键盘输入、文件上传等。在实际系统中，通常与结构化提取与视觉感知结合使用。Agent 可先调用 DOM 分析获取元素语义，再借助 GUI 浏览器对目标元素执行操作，并在操作后通过截图或状态变化判断其是否成功。其优势在于可高度还原的人类使用流程，适用于任务流程复杂、状态不确定性高、UI 结构不固定等场景。
• 无头浏览器（Headless Browser）运行于无 GUI 的模式，但保留了页面加载、JavaScript 执行、DOM 操作等全部功能。这使其资源开销较低，适合处理结构化数据密集型的任务。无头浏览器如 Headless Chromium、Playwright Headless 模式通常支持离屏渲染（off-screen rendering），可在后台生成页面截图并作为视觉模型的输入。部分系统也采用 “可配置头” 浏览器，即在任务启动时灵活切换是否启用 GUI，以在多任务部署中平衡资源与能力。

感知

Web Agent 的感知机制大致可划分为以下三类：（a）基于 DOM 的结构化提取，（b）基于截图的视觉理解，（c）两者融合的混合式方法。三者在准确性、通用性与资源开销之间各有取舍。

(a) 结构化提取（DOM/HTML/API）

该方法将网页视为结构化文档，包括 DOM 树与 HTML 元素。通过解析 DOM/HTML，Agent 可获得机读的页面元素表示、其属性（如按钮文案、输入框标签），以及元数据（ 如 ARIA、microdata）。其优势在于高效（文本较图像更紧凑）与确定性（结构显式可见），且 LLM 对 HTML 语料具备一定预训练先验。有多项系统采用结构化提取的思路：

• AutoWebGLM（KDD 2024）：在 60 亿参数的 ChatGLM 上构建的网页导航 Agent，核心在于让 HTML 输入更易于被模型消化。它采用 HTML 简化算法去除 DOM 中的冗余部分（广告、追踪、无关脚本等），仅保留“关键信息”，在降低 token 长度的同时保留交互性内容；并采用课程式学习页面，由简入繁，再结合强化学习与拒绝采样进行微调。这一流程使模型更擅长理解页面结构。AutoWebGLM 在 Web 导航方面上展现出超越 GPT-4 的表现，而在真实站点评测（AutoWebBench）中，采用上述技术的 60 亿参数模型取得了与大得多的 LLM 具有竞争力的成功率。通过针对性的训练，简化输入并专注于与 Web 相关的技能，较小模型也能表现出色。
• D2Snap（2025）：面向“大 DOM”的下采样算法。许多网页的 DOM 极为庞大，可能超出 token 上限。D2Snap 对 DOM 树进行分析，为每个节点评估“交互权重”（可见性、可点击性、是否含面向用户的文本等），随后剪除或合并低权重节点，生成紧凑的“DOM 快照”。实验显示，在复杂页面上，D2Snap 平均可将 DOM 输入的 token 数量降低 60%–80%，同时维持与完整 DOM 相当的任务成功率；在使用 GPT-4 作为后端执行 Web 导航任务时，经 D2Snap 处理的 DOM 成功率约为 67%，比原始 DOM 优化 2%，在最佳下采样配置下可提升 8%，说明对 DOM 去噪有助于减少混淆、提升可用性。因此，基于 DOM 的感知可以通过聚焦可执行元素来实现可扩展性。

结构化提取的优势在于其契合 Web 开发者的思维：元素拥有 ID、class、role 等可利用的语义。同时，由于语料中很可能包含大量原始 HTML，LLM 也能更直接地利用其在 Web 数据上的训练。所以，DOM 提取相对其他方法通常速度更快、资源占用低。但其局限在于，页面外观或语义并不总能在原始 DOM 文本中完整体现（如 canvas 绘制、图像文本、JS 动态渲染），有些网站还会混淆 HTML 或使用无语义的元素 ID，削弱纯 DOM 方法的稳定性。

(b) 视觉感知（截图 + 视觉 - 语言模型）

该方法让 Agent 以图像的方式感知页面，具备视觉能力的 LLM（VLM，如 BLIP-2、GPT-4V 等）处理页面截图，生成描述或直接输出操作（如点击坐标）。它将页面视为 GUI 截图：模型需要在视觉上识别按钮、链接、文本，并基于外观与上下文推断其功能。

一个示例是 WebSight-7B，针对 UI 理解优化的 70 亿参数视觉 - 语言模型。它通过 LoRA 在在 Wave-UI-25K 的数据集（带标注的 UI 截图集）上进行微调，专门用于 Web UI 任务。WebSight-7B 的输入是截图 + 指令，输出是交互所需的坐标或元素标识。在无 DOM 的前提下，它在 Showdown Clicks 基准上达到 58.84% top-1，优于一些更大的模型，同时推理更快；在 WebVoyager 基准中，完整的 WebSight 智能体（结合独立的规划与校验模块）任务成功率为 68.0%。当 HTML 不可用或不可靠时，视觉优先的路径依然可行，这对于通过 canvas 渲染内容或使用反爬措施隐藏结构的网站尤为重要。

视觉感知能更好地处理特殊布局的页面，能处理图标识别或 CAPTCHA 等纯 DOM 方法容易遗漏的内容。不过，其代价是计算开销更高，用 VLM 处理图像比解析文本更慢、更耗内存。且在小字识别、精确可点击区域定位上更易受分辨率限制。因而，纯视觉往往作为后备方案，当结构化数据不可访问时使用。

(c) 混合感知（DOM + 视觉）

目前 Agent 多采用混合 DOM 和视觉的感知：尽量利用 HTML 的效率与语义清晰度，遇到歧义或动态内容时，再引入视觉上下文补强。混合感知常遵循两步流程：先用 DOM 筛选候选元素 / 区域，再对这些区域使用视觉感知进行确认与细化。

• WyseOS 提供了一个 Web 自动化的 AgentOS 实践例证，其底层采用 YOLO12 模型的视觉检测与 DOM 语义检测相结合，构建了具备高精度的页面元素融合检测系统。其融合策略基于两类检测结果的重叠率与类型一致性：若两类结果重叠度超过 15%，优先使用结构更清晰的 DOM 检测；若分歧较大，则保留视觉结果以增强鲁棒性。这种自适应融合方式在实际应用中显著提升了跨站点任务的通用性与检测成功率，是目前混合感知落地工程化较为先进的方案之一。此外，其还集成了一个持续演化的知识经验库，用于积累不同网页上的操作经验和失败恢复策略，进一步强化感知模块在现实任务中的表现。
• Surfer-H 是一个模块化的 Web Agent，与开源 VLM Holo-1（7B）搭配时在 WebVoyager 上取得 92.2% 成功率。Surfer-H 的架构包含明确分工的模块：Policy 模块基于文本上下文决定下一步的动作；Localizer 模块在截图中精确定位目标元素的像素坐标；Validator 模块负责验证目标是否达成，并在未达成时触发重试或替代策略。这种模块分工让 Policy 依赖 DOM 确定要操作的元素，而 Localizer 则通过视觉在渲染后的页面中找到其坐标。Surfer-H 展示了完全开源栈也能在许多任务上达到 92% 的成功率，接近人类操作的可靠性。同时其平均每个任务约 $0.13，成本也很高效。
• Dual-View 上下文化：不同于将 DOM 与截图分别处理，Dual-View 为每个 DOM 元素配对其在截图中的视觉区域（patch）及邻近的视觉上下文，构建更“富语义”的元素嵌入。其考虑到 Web 设计师通常根据视觉邻近来放置相关元素，而这些元素在视觉布局上相邻，在 DOM 结构中却可能因为嵌套或排版反而相距较远。在 Mind2Web 数据集上的实验表明，引入 Dual-View 表征始终比纯 DOM 提取或纯视觉感知呈现更好的表现，带来平均 3.7% 的提升。

综上，Agent 可以通过多种模态感知 Web 内容：结构化 DOM 提供简洁且语义丰富的输入，网页截图提供直接的视觉定位和理解，两者融合则提升适应性与准确性。最佳选择取决于场景，若页面结构良好且以文本为主，结构化 DOM 提取最适合；若页面图形化程度高或被混淆（如图表、地图，或为阻止抓取而设计的网站），网页截图的视觉感知为佳。 Agent 往往通常会基于内容类型与任务需求动态决定使用哪种模式。

在理解网页之外，Agent 常常结合外部知识来补充感知能力。不少系统引入 RAG（检索增强生成） 到 Web 智能体中。在访问网站的过程中，Agent 可以查询 FAQ、技术文档、历史交互记录等，将相关信息纳入 LLM 的上下文，帮助处理异常、错误码或流程细节，减少 LLM 仅凭当前页面进行猜测的负担。

浏览器控制

Agent 的 Web 交互主要分为两类实现路径：一是基于视觉操作的可视操作栈，二是基于通信协议的浏览器自动化框架。

可视操作栈通过构建完整图形化桌面环境，让 Agent 像人类用户一样完成交互。其以 OpenAI 的 Computer-Using Agent（CUA）和 Anthropic 的 Computer Use 为代表。模型被置于图形界面（如 GUI 浏览器）的虚拟机或容器中，通过获取屏幕像素图像作为输入，并结合多模态模型的视觉理解能力，识别页面结构、元素与状态。在此基础上，Agent 决定下一步操作，并通过模拟鼠标点击与键盘输入，在环境中执行动作。该流程构成“感知—理解—行动”的闭环。模型需持续判断当前页面是否达成预期状态，是否需要重试、滚动、返回，具备一定程度的自主修复与流程控制能力。在训练方面，CUA 类系统依赖人类演示数据与任务回放记录，通过强化学习来优化多步执行策略。CUA 搭配 GPT-4o 的多模态能力，在开放 GUI 环境中实现复杂任务，如文件上传、表单填写、网页跳转与验证等，具备强泛化能力。

浏览器自动化则通过通信协议来控制浏览器。以 Chromium 为例，浏览器内部暴露了远程调试接口 Chrome DevTools Protocol (CDP)，Agent 可以通过这个端口与浏览器通信，实现可编程的控制。Playwright 是目前主流的浏览器自动化框架，它原生支撑 Chromium、WebKit、Firefox，并且可以将 Agent 发起的高层命令翻译成底层 CDP 指令序列，让执行稳定可复现。通过监听浏览器事件实现自动等待（auto-wait），让 Agent 执行时因未加载等造成的假性失败率降低。

相较而言，Playwright、Selenium、Puppeteer 等传统浏览器自动化框架采用更工程化的方式。它们基于浏览器公开的通信协议，如 Chrome DevTools Protocol（CDP），通过与浏览器渲染进程建立 WebSocket 通信，直接对网页 DOM、网络、存储等模块进行编程式控制。Playwright 是其中最具代表性的框架，原生支持 Chromium、WebKit 与 Firefox，并通过封装高层操作（如点击、输入、跳转）将指令编译为底层协议命令序列。其特有的自动等待机制（auto-wait）可监听浏览器加载与事件触发，避免因资源未加载等造成的假失败，提高任务执行的稳定性。浏览器自动化的优势在于工程可控性与高吞吐量。在结构明确、流程稳定的任务中（如电商下单、数据采集、身份验证等），具备稳定性、易调试、可审计等特点。但它依赖网页结构信息，面对以 Canvas、WebGL 等方式渲染的高度动态界面时，处理能力受限。

两类路径分别代表了对“控制力”与“泛化力”的不同权衡。浏览器自动化提供结构化、可预测的控制路径，适用于规范流程与数据密集型任务。可视操作栈则摆脱了对 DOM/CSS 结构的依赖，在视觉驱动的复杂任务或混淆结构中具备优势。但与此同时，也带来更高的计算成本与系统复杂度。开发者需要根据具体任务的结构清晰度、复杂性、可靠性需求与执行成本，选择适配的执行路径，或构建融合两者的混合控制架构，实现更广泛、更稳健的智能体执行能力。

交互标准化（MCP）

尽管如此，当前智能体在真实 Web 的感交互仍面临许多问题：网站间的界面与交互千差万别，多页流程中的状态维护对 LLM 调用并不友好。为此，业界正推动让 Web 本身更适合 Agent 使用的标准化接口，来帮助 Agent 解析 Web 界面。比如 Agent-Tool 通信协议。类似 Web API 结构化应用之间的通讯，Agent-Tool 通讯协议尝试标准化 Agent ↔ 网站的交互，其中的代表是 Model Context Protocol（MCP），在任务执行层进行描述。

目前 Agent 已能通过 DOM 结构化提取与截图驱动的视觉理解获得对 Web 的类人感知。长期来看，若 Web 朝 Agent 标准协议化演进，感知的复杂度将被大幅简化。为了这一转变，网站需要开放标准化端点（函数 / 资源的清晰 schema），并建立可持续的接入与收益分配机制。在此之前，我们仍处于过渡期： Agent 需要继续读取为人交互而设计的传统 Web，也要逐步对齐适配面向 Agent 的新型接口。

MCP 是一个探索中的针对 Agent <> Web 交互的开放标准。MCP 使 Agent 能够以一致的方式在不同服务之间发现并调用工具，为 Web 赋予一层“可调用函数”，每个函数的输入输出由 Schema 描述。在 MCP 下，服务提供方会托管一个 MCP server，对外暴露特定的动作。智能体通过 MCP client 可以查询注册表或目录来发现可用服务及其提供的函数。协议消息采用 JSON（JSON-RPC 2.0 扩展），因此都是结构化、可机读的。其核心组件包括 MCP Host（Agent 的 LLM 运行环境）、MCP Client（中间件，负责通信管理与可用工具上下文维护），以及 MCP Server（实现工具逻辑的服务端）。例如，当 Agent 需要订机票时，它可以查询 MCP 目录寻找机票预定工具；若机票网站提供了此类接口， Agent 就可以以结构化 JSON 形式调用。

MCP 的目标在于一致性与安全性。Agent 调用官方的工具端点，而这些工具有明确的 Schema，模型知道需要哪些输入以及期待的输出格式。这将交互从非结构化的提示，转变为函数式 API 调用，更易调试与验证。LiveMCP-101 基准测试发现，即便是最好的模型，在复杂多步查询上的成功率也低于 60%。这表明，即使界面被标准化，如何正确使用它的推理能力仍是瓶颈。常见的失败模式是语义错误， 即 Agent 生成的调用参数在语法上合法，但在语义上与任务不匹配。这类错误源于模型在中间推理过程中未能准确理解 schema 或任务上下文。

然而，当前 MCP 尚处于早期，现实距离完全用标准化协议取代 Web 抓取仍有不小距离。一方面是部署规模，目前具备 MCP 端点的网站很少；另一方面是复杂性，即便有 schema，跨工具、跨域的序列化编排对当下的 LLM 仍然困难。目前开发者在探索的改进方向：

• 更丰富的工具 Schema 与注释：为每个参数提供自然语言说明、使用示例与语义标签，相当于让 schema 文档化并充分说明约束条件。这可以帮助 LLM 理解如何使用该工具，降低模型的猜测空间。
• 执行前参数校验：MCP 服务器可以为工具提供 validate(params) 接口，类似运行前进行类型检查（ Type Check）。Agent 在实际执行前先调用该端点检查计划参数，再根据 Server 返回的错误类型进行调整。
• API 自动生成封装：为降低服务方接入 MCP 的门槛，可以用包装器把现有 API 自动转成 MCP 形态。例如，AutoMCP 可以把标准的 REST API 规范转换为 MCP 的 Schema。类似地，也可为 GraphQL 或 SOAP 服务，为已知网站的抓取逻辑打包成 MCP 服务。这样，Agent 能够看到统一的接口，即便底层调用的是旧式 API 或 HTML 抓取。
• 更友好的文档与语义增强：如 ACE、Stainless 等，改进提供给 Agent 的工具文档。它们可能为每个函数生成简明的目的说明，指出函数间关系。通过将更高质量的文档喂入 Agent 的上下文，可显著降低误用率。
• 按需工具发现：预加载所有可能工具会对 Agent 带来噪声干扰。MCP-Zero 提出了主动工具发现框架 ，让 Agent 按需主动检索与装载缺失能力。Agent 在感知到能力缺口时，主动发起结构化工具请求，由系统通过层级语义路由匹配最相关服务与工具，并在执行过程中逐步扩展工具链。

小结：当前 Agent 正在从以 API 与 DOM 为基础的机器式感知，逐步学习如何像人一样读取、操作可视化界面，提升对 Web 的直观理解与适应能力。这使得传统面向人的网页，也能被 Agent 更灵活地使用与控制。然而，Agentic Web 的演进不应仅靠 Agent 的适配，更需 Web 本体的结构性变革。MCP 等新兴协议正推动 Web 向 Agent 原生友好的方向演进，让 Agent 不再仅是用户模拟器，而是具备原生接口能力的网络行动者。

3. 任务执行层（Task Execution Layer）

Agent 的任务执行，不仅关乎如何完成服务调用，更需要一整套可落地的操作机制：如何验证自身身份、如何在多方系统完成支付结算、以及如何在执行链条中处理中断异常灯。它不仅是技术调用的问题，更是信任问题。随着 Agent 能力、安全性和稳定性的提升，Agent 需要逐步具备类似人类的可验证身份、独立的支付能力，以及在现实任务中的责任承担与策略选择能力。

身份验证与凭证

当 Agent 代表用户执行操作时，往往需要获得用户的身份权限。这涉及了多种情况下的身份授权机制：

（a）浏览器上下文与 Cookie 复用

这是最简单常见的 Agent 身份认证方式，即利用已有的用户浏览器上下文（如 Cookie、LocalStorage），使 Agent “借用”人类的登录状态完成任务。此类方案广泛用于浏览器自动化框架（如 Puppeteer、Playwright），Agent 可直接读取登录后的浏览器存储信息，在无需登录交互的前提下访问网页服务。这种方式对接现实系统门槛低，适用于需要执行 UI 操作等简单任务的 Agent。但其缺点也非常明显，Cookie 暴露后极易被滥用，安全边界模糊。因此，当 Agent 不再只是单次 UI 交互，而是需长期稳定地访问多类服务接口（如数据获取、指令执行、交易发起），便需要转向更标准的认证授权协议。

（b）OAuth 授权协议

当 Agent 需要长时间或跨服务访问多种接口时，往往需要采用更标准的授权协议。OAuth 2.0 则提供了跨平台、无状态的授权模型，将身份认证与资源访问解耦，使得 Agent 能在不暴露用户凭证的前提下令牌形式获得访问权限。常见的授权流程包括：授权码模式，适用于用户主动参与授权的场景，Agent 可通过网页跳转或设备码方式，引导用户完成登录，从而获取访问令牌；客户端凭证模式，适用于无人值守、服务账户调用的任务，Agent 通过注册的 client_id/client_secret 获取自身的服务凭证，代表服务账户调用接口。OAuth 的优势在于其广泛的标准支持与丰富的细粒度权限控制，能与绝大多数 Web 服务良好兼容，也是目前 Agent 执行 SaaS 接口任务的主流方式。

但在 Agent 场景下的挑战是令牌管理，如何自动刷新、缓存和保护访问令牌。LangChain 等项目已经探索出统一的 Agent Auth 管理系统，提供了 OAuth Token 管理接口，并可与 Agent 身份挂钩生成短时访问凭证。WorkOS 推出的 AuthKit 支持 OAuth 2.1，可作为专门针对 MCP 服务器的授权服务器，为 Agent 应用提供灵活的权限管理。其他工具（如 Pica 的 AuthKit）也为 Agent 提供接入多 API 时的安全认证管理。这些实现通常会生成限期访问令牌、并在内部进行刷新管理，以避免长久凭证泄露的风险，确保 Agent 只能在用户授权的范围内、在可控时间内执行操作。

（c）分布式身份（DID）与可验证凭证（VC）

DID 为每个 Agent 提供去中心化、自我主权的身份标识；VC 则用以表达某个 Agent 拥有的权限、代表的身份、授权范围与期限等信息，并支持链式验证与追溯。两者配合使用，可以保证身份及授权的真实性和审计链，为 Agent 行动构建更完整的信任链条。例如，在 AP2 协议中，所有授权令牌（Mandate）都以 W3C 可验证凭证格式签名，确保不可伪造和可审计。下游平台通过验证 VC 的签名、发行者公钥、时间戳和范围等信息，确认该调用合法且可追责。

DID + VC 机制在分布式协作场景中也尤为重要。例如，在下述 AP2 协议的应用场景里，用户可先签发一个 Intent Mandate（刻画条件和范围的授权凭证），主 Agent 再根据此凭证生成 Cart Mandate 转给商户或其他 Agent，每一级都保留签名和上下文哈希，形成透明的授权链。每次操作都产生加密签名的凭证，将用户意图、执行责任和审计痕迹串联起来。目前 DID + VC 的框架已经在多个项目得到初步实践。

交易支付（AP2 与 x402）

随着 Agent 逐步参与更高价值的任务，其不可避免地将介入实际支付行为，包括购物、订阅、金融交易等。这类交易对安全性、可审计性和合规性提出了更高要求。传统支付流程默认用户亲自确认与发起，而 Agent 驱动的场景需要新的机制来表达与验证用户意图。

Google 推出了 Agent Payments Protocol（AP2），为此类场景提供基础框架。在 AP2 中，通常涉及两到三类 mandate：

• Intent Mandate（用户不在场）：用户事先签署的预授权，在特定条件下赋予 Agent 预先批准（例如：“若门票开售，且票价低于 $300，请立即为我购票”），这允许 Agent 在无人监督的前提下完成购买。
• Cart Mandate（用户在场）：由 Agent 构建的购物车提交给用户进行确认。例如：2 张票共计 $250。用户签名后，该 mandate 绑定具体商品、价格、时间等信息，具有法律效力。Cart Mandate 也由商家共同签署，确保订单不被修改。
• Payment Mandate：由商户端触发，将交易行为映射到实际支付行为，它可能包含对上述 intent 或 cart mandate 的引用。这些 Mandate 被设计为加密签名的 VC，可以在 agent 执行任务、发起交易或提交结果时携带，提供了对执行权限的加密签名授权，并作为任务内容、责任界定的依据。

从 Agent 的实现角度看，AP2 引入以下关键流程：若用户事先通过 Intent Mandate 授权，Agent 可直接根据条件判断是否触发支付；若为人类在场情境，Agent 会动态生成 Cart Mandate 并请求用户签名确认；商家 Agent 接收到 Cart Mandate 后签发 Payment Mandate，并提交给支付系统（如银行或 PayPal）。为方便开发者，Google 与多个合作方正推出支持 AP2 的 SDK 和库，封装这些底层机制，让开发者聚焦业务逻辑。

虽然 AP2 当前主要服务于客户端 Agent ↔ 商户 Agent 的一对一交易路径，其设计思想可被扩展到更复杂的多 Agent 协作网络中。例如，引入 Composite Mandate / Delegated Mandate，允许主 Agent 将任务意图拆分后再授权给子 Agent，并在每一级 Mandate 中嵌入父级引用与上下文哈希，从而形成一条可验证的授权链条。这种链条既能作为协作路径的行为日志，也可作为后续收益清算与责任认定的基础结构。

Coinbase 提出的 x402 支付标准，基于 HTTP 协议中原本保留的 402 Payment Required 状态码，为 Agent 与 Agent（M2M, Machine-to-Machine）间的自动支付交互提供了一种轻量、无状态、原生于 Web 的解决方案。它特别适用于无需用户交互的小额、高频交易场景。x402 并不依赖 Web UI 或钱包弹窗，而是允许 Agent 在收到 402 响应时，根据服务端返回的 metadata 自动构造支付请求，将支付信息直接附加在后续的 HTTP 请求头中发起第二次请求。支付验证成功后，服务端便返回 200 OK 及所请求的资源。这种“支付即请求”的流程，使支付行为成为 Web 原生流程的一部分。

x402 的设计具有多项优势，使其非常适合在 Agentic Web 作为支付执行层的基建标准：1）协议无关链、无需插件，支持多种加密货币，不绑定特定链或钱包生态；2）高频低延迟：通信开销极低，无需跳转页面或复杂交互；3）极简部署：服务端仅需在原有 HTTP 服务逻辑中增加一行配置或中间件，即可支持 x402 支付；

目前，x402 机制已被集成至 AP2 框架，作为 Agent 自动化支付路径之一。例如，Cloudflare 与 Coinbase 已联合成立 x402 Foundation，并将该标准整合进 Agent SDK 与 MCP 服务。更进一步的研究也探索了将 x402 与 AgentCard 结合的方式，通过 VC 锚定 Agent 身份，并以 x402 支付路径完成 Agent 间交易，为构建可信、高效的 Agent-to-Agent 经济打下基础。这种架构非常适合模型即服务（MaaS）、流式 API 消费等自动化经济网络。

小结：身份和支付是 Agent 以代理身份参与现实世界的重要环节。这些机制需要与 Agent 的能力水平同步，目前阶段系统多采取更保守和简化的授权和交易路径。而随着 Agent 智能、可控和安全性的增强，将逐步支持更开放的身份管理和交易支付机制，扩展其行动边界与委托责任。Agent 作为人的代理，执行的每一项现实行为都需要人的授权、监管和责任承担。因此，任务委托和权限下发更需要注重安全边界、合规和可追溯性。

4. 协调与协作层（Coordination and Collaboration Layer）

随着任务复杂度的提高，单个 Agent 无法精通所有的任务，需要通过协作机制整合多个 Agent 的能力。因此，一个新的问题随之出现：Agent 之间如何协作交互？这种协作又将形成怎样的生态系统？ 协调协作层旨在解决这些核心问题：Agent 如何相互发现、通信、协作完成任务，以及如何设计更高效的 Agent 网络结构。

协作生态

当前部分系统采用 Agent 应用商店（Agent Marketplace）的模式。用户可以浏览并安装具有特定功能的 Agent（例如一个研究 Agent、一个理财 Agent 等）。研究质疑这种模型看似面向消费者友好，却充斥大量“玩具”型的产品。多数 Agent 功能单一、难以组合，整体实用性不足。更重要的是，用户并不希望手动管理一堆 Agent，而真正关心的是问题是否被解决，不需要知道使用哪一个具体的 Agent。

更具扩展性的架构是 Agent 协调层（Agent Orchestration Layer）。由主 Agent 作为入口，根据任务需求动态分派子任务委派给各个专业化 Agent。当用户发出指令，例如“预定本周末旅行”时，主 Agent 即可在后台自动调用多个服务 Agent 完成任务。这种架构强调由 Agent 自主采购 Agent，而非用户亲自管理数十个 Agent。Agent 向其他 Agent 广播自己的能力，主 Agent 则依赖声誉、凭证或经济激励机制来判断和使用其他 Agent。

Agent 协作会形成怎样的生态？微软在一份报告中提出了“Agent 封闭花园（agentic walled gardens）”的概念，用以描述一种平台型 Agent 生态，其中 Agent 主要与自家生态的 Agent 通信，外部 Agent 可能无法自由接入。例如，大多数消费级任务由 Google 或 Amazon 的 Agent 处理，在各自的封闭平台中运行，而第三方开发者必须通过这些平台的审核才能接入。封闭花园可能在一致性、安全性与质量上更可控，却会以垄断和跨平台适应性为代价。

另一种路径是开放的 Agent 网络（open web of agents）。任何 Agent 只要遵循通信协议，即可实现自由协作。开放网络的实现，需要统一的通信协议与身份基础设施。Agent-to-Agent（A2A）等标准正在为跨平台 Agent 提供通用的交互层，带来更充分的竞争和创新。

微软在 Build 2025 提出“AI 平台的操作系统”定位，表明其愿意通过中间层协议与平台抽象，推动更大范围的 Agent 互操作。Agent 网络走向封闭亦或是开放，牵涉多方面如技术设计、经济激励、监管等多方面的因素，本文只考虑协作层上的设计。 

通信协议

在多 Agent 协作系统中，标准化的通信协议是实现互操作的前提。

早期，FIPA（Foundation for Intelligent Physical Agents）推出了 FIPA-ACL（Agent Communication Language）以标准化 Agent 间消息传递的结构。随着 LLM 工具调用架构的普及，现代 Agent 系统倾向采用更轻量、通用的协议栈。Google 推动 Agent-to-Agent（A2A）协议的标准化，该协议主要采用 JSON-RPC over HTTP(S) 作为通信基元，支持同步、异步与流式交互。在具体实现层面，Agent 通常通过结构化 JSON 请求进行消息交换，如：{"to": "agentB", "action": "collaborate", "data": {...}} 。同步场景可直接使用 HTTP 请求；而对于复杂或多轮的协作流程，协议支持 Server‑Sent Events（SSE）或推送通知机制，以实现状态广播与松耦合通信。

在实现层面，若遵循 A2A 标准的 Agent 之间通信，通常按照以下流程运作：用户将任务交由其入口 Agent（client agent）处理，该 Agent 依据任务内容读取或搜索各个 AgentCard 元数据，选择合适 remote Agent 执行。任务被包装为一个任务对象（task object）并赋予唯一标识；接下来，client Agent 与 remote Agent 通过 JSON‑RPC 接口进行通信，例如调用 “message/send” 方法提交输入，或 “message/stream” 方法开启 SSE 流以接收实时结果，亦或采用 Webhook 模式接收状态更新。A2A 协议设计允许 Agent 在不暴露其内部 memory、工具或逻辑的前提下，通过 AgentCard 宣告能力与接口契约，从而实现跨平台、跨供应商的安全协作。

此外，现有如 AutoGen、LangGraph 等框架支持多角色协作模型，通过定义 Planner、Executor、Verifier 等角色 Agent，基于自然语言对话与共享 memory/context 协同工作。这种结构类似于一种内部的制衡体系，在复杂推理与自动化编程任务中有一定成果。AutoGen 在最新版本中引入了异步事件驱动机制，允许各角色以独立进程并行工作，通过调度引擎进行统一协调。CMA（Concurrent Modular Agent）模型进一步增强了并发能力，其多个 module 可独立运行并在共享全局状态上协作，通过语言调度保持上下文一致性。然而，这些框架多基于静态角色预定义与封闭任务空间，难以应对开放环境中的动态角色发现与协作。

在 Agent 网络构建方面，OpenAgents 支持构建和连接大规模 Agent 网络，具有跨协议（protocol-agnostic） 特性，可通过 HTTP、WebSocket、gRPC、libp2p 等多种传输层实现 Agent 互联。Agent 让 Agent 能够自我分配或交易任务。 OpenAgents 让开发者能够快速搭建 Agent 社区，实现能力共享、形成协作网络，从而推动开放 Agent 生态的落地。其模块化架构、事件驱动机制及多模型融合展示了 Agent 协作网络的雏形。

Agent 网络的挑战是，如何在真实开放环境中部署时，需要实现无需预定义角色、任意 Agent 动态发现并组成团队的能力，即所谓的 “开放世界协作 open‑world collaboration”。目前多 Agent 框架仍局限于静态角色与封闭任务。其次，A2A 规范已强调其跨模态（modality‑agnostic）特性，协议还需要提高 Agent 通信协议对于多模态及长时任务（任务可能持续数小时或数天）的支持能力。

身份注册与发现

要支持动态协作，Agent 网络需要可发现的身份与能力基础设施。当前已有多种机制试图构建 Agent 的注册和发现系统，例如 Olas 提出的链上注册表（on-chain registry），将每个 Agent 及其组件都作为 ERC‑721 NFT 存储，支持能力声明、接口索引与元数据存档。

此外，AgentCard 提供标准化的统一格式，用于声明 Agent 的调用接口与执行契约。配合 AgentFacts 文档，提供了结构化、自描述、可扩展的能力声明体系。AgentFacts 使用 JSON-LD 表示能力元数据，支持多重签名结构（如多机构联合背书）、基于 CRDT / append-only 的更新协议、最小披露与能力撤销机制。在身份周期管理上，LOKA Protocol 提出将 Agent 生命周期分为注册（Genesis）→ 进化（Growth）→ 故障处理（Crisis）→ 退役（Sunset），为每个 Agent 身份设计状态字段与生命周期治理规则，实现状态机式身份控制，增强了系统对 Agent 行为演化的监管能力。

Agent 能力发现还需要语义搜索（semantic search）功能。当某个 Agent 需要其他服务时，它应能查询目录并找到合适的候选者。通过嵌入式向量与最近邻搜索算法，可以对 Agent 能力进行语义匹配和排序，构建 Agent 的搜索引擎。例如 OpenAgents 正在构建的注册网络，让 Agent 可以上传能力向量，并且通过语义搜索找到最适配的合作 Agent 。另一种设计是 NANDA Index，通过区域对注册目录进行分片，避免全局注册表过于庞大。未来可能存在多个局部 Agent 网络，再通过一个元注册系统（meta-registry）进行汇聚，形成所谓的拼布式（quilt）注册结构。

为支持更高效率的 Agent 搜索，可以引入轻量级索引层。例如 NANDA Index 提出解耦 Agent DID 与 AgentFacts，通过本地缓存与增量同步机制，实现子秒级的注册 、能力检索与部分披露验证、以及能力轮换机制。NANDA 的架构适用于高频协作、动态代理生成、短生命周期 agent 等场景，能够在无需信任中心化注册服务器的情况下，提供高性能、高可用的身份与能力发现服务。此外，有研究提出 Agent Naming Service（ANS）模块，在命名解析之上集成访问控制与会话策略的中枢。

将 AgentCard 与身份信誉、经济模型结合起来，是推动 Agent 网络可信协作的一步。比如，在 AgentFacts 能力文档中嵌入标准化的“信誉属性集”（Reputation Attributes），包括过去任务成功率、平均验证得分、争议处理历史、协作贡献值等。这些字段可以由信誉评估模块签发为 VC 凭证，作为对 Agent 行为历史的可验证记录。信誉凭证应具备时间敏感性与动态更新能力，每当 Agent 完成一个任务并通过验证后，系统滢自动生成一条“信誉变动凭证”（Reputation Delta VC），写入其身份记录中。近年的多 Agent 系统研究显示，基于交互的信誉奖励可以显著提升 Agent 系统的合作倾向。

编排协作

编排（orchestration）机制是多 Agent 协同执行复杂任务的核心机制，其需要考虑如何进行任务的分解、角色的动态指派、消息的协调同步，以及跨 Agent 的子任务整合。

当前主流的编排框架中，AutoGen、LangGraph 等主要采用静态配置（static configuration）和固定角色设定（role assignment）的方式，每个 Agent 的角色、职责、调用顺序与任务边界在开发阶段即被预定义。静态配置的优势在于明确性强、易于调试，然而难以适应真实世界种更动态、多变和开放性的任务场景。

为应对更开放的执行环境，研究者们提出了动态配置（dynamic orchestration） 的设计：系统根据运行时的任务需求，自动发现并匹配合适的 Agent 进行即时协作。这种模式虽然显著提升了灵活性与可扩展性，但也引入了更高的系统复杂度，如能力评估、上下文同步、依赖管理等问题均需动态解决，导致落地门槛较高。

部分系统提出了任务交易所（Agent Exchange，AEX） 的架构，实现去中心化的任务调度与资源匹配。AEX 充当多 Agent 网络中的协调系统，任务发起方可以将任务委托给交易所进行智能匹配。AEX 亦引入组队机制：AEX 可以维护多个 Agent Hub，每个 Hub 是由多个协作能力已知、历史表现已验证的 Agent 组成的协作单元。在任务匹配阶段，系统首先根据任务的属性（目标、预算、时效性、资源需求等）筛选出一个或多个合适的 Hub，再由该 Hub 内部进行任务细化、角色划分、执行协调与结果集成。这种模式在一定程度上结合了静态与动态配置的优点：上层任务匹配保留灵活性，可根据任务属性、预算、时间等维度在多个 Hub 中选择；下层协作过程则由 Hub 内部静态设定的角色分工完成，提升协作效率、降低同步成本。

任务匹配机制是 AEX 的核心组成，通常包括两类模式：

• 直接指派（Direct Assignment），适用于低竞争、或任务发起方 Agent 能够准确评估候选 Agent 能力的场景。任务发起方可以在 Agent 注册的能力画像库中直接选出最匹配的 Agent。 
• 多属性拍卖（Multi-Attribute Auction），适用于高竞争、或需要多维评估的场景。任务以拍卖形式发布，多个 Agent 或者 Hub 提交包括价格、执行时间、质量估计、信誉分数等多维度的竞标提案。系统给予可配置的评分函数（如加权、层级打分）选择中标方。

任务被接收后，系统会将其拆分为若干子任务，由不同的 Agent 执行。并且，指定明确的输入输出格式、数据接口及验收标准，确保下游 Agent 能够无缝承接上游结果、系统还需要统一的状态同步机制，实时追踪子任务进展，协调执行顺序，动态处理依赖关系的变更。整个过程中，调度引擎需保持任务拓扑结构的一致性，避免重复执行、冲突分配或资源阻塞。此外，在实际部署中不可避免地会出现 Agent 执行失败、响应延迟或数据出错等问题，因此还需设计完善的容错策略，包括备用 Agent 的动态替换、部分失败的回滚或重试机制等，以确保整个任务流程具有弹性与鲁棒性。

此外，为保证任务流程可解释与可追溯，可以采用有向无环图（Directed Acyclic Graph, DAG）结构来建模多 Agent 的协作链。每个 Agent 执行的产物被视为图中的节点，其输入输出关系构成图的边。这一结构有助于系统内部任务依赖与流程优化，为后续的审计、责任归属与贡献评估提供了基础结构支撑。

报酬结算

在多 Agent 协作系统中，合理设计报酬分配机制是维持系统激励相容性、促进高质量协作的关键。一个理想的分配系统应公平透明，能有效量化并回馈各 Agent 的真实贡献，防止搭便车（free-riding）与策略操控行为。

一种具有理论基础的方法是基于合作博弈论（Cooperative Game Theory）中的 Shapley Value 模型，强调通过边际贡献来评估每个参与方整体成果的共享。在多 Agent 协作任务重，Shapley Value 可根据 Agent 在任务链中的作用，例如承担任务比例、完成质量、异常恢复能力等，对其在整体工作流中的贡献进行定量分析。该方法已广泛用于联邦学习（Federated Learning）或多 Agent 强化学习（Multi-Agent RL）中的信用分配问题，如 Shapley Counterfactual Credits）提出基于 counterfactual policy 估计 Agent 在合作中的真实影响力。在区块链场景中，Shapley Value 也被用于多个节点协作完成交易处理时的收益拆分建模。

Shapley Value 优势在于理论上的公平性与去偏性，但缺点是计算复杂度为指数级，尤其在参与 Agent 数量较大时难以实时求解。为解决这一问题，实际系统多采用稍微简单的策略，如 1）启发式近似（heuristic approximation）：仅计算主要子集的边际贡献，或使用蒙特卡洛采样。2）加权评分模型：设定多维指标，如任务执行时长、通信轮次、资源消耗等，并设权重线性组合，用于逼近 Shapley 分配结果。

除了基础分润规则外，为优化长期协作表现，系统可引入一套带激励系数的自适应奖励模型。比如，对超预期完成任务的 Agent 提高其分润权重，激励其持续投入优质算力与服务；对响应超时、任务失败、或输出不合格的 Agent 则降低分润比例；Agent 报价并不直接决定其实际收益，而是作为预算上限。最终收益需结合任务表现与协同过程中的实际贡献进行调整。任务初始的预算由系统根据历史执行数据、市场基准价格、Agent 信用等级等生成，并在拍卖或匹配阶段作为参考。

为在多 Agent 协作系统中实现可信的价值结算与行为约束机制，可以引入由动态质押、可编程惩罚逻辑（programmable slashing）构成的行为约束机制。该框架要求执行 Agent 在任务执行前承担经济责任，并为协作网络提供可验证的行为约束和问责路径。在此模型中，Agent 可使用自有资金、接受资金授权，代表运行节点在协作网络中承担任务，向系统抵押一定数量的担保资产，作为其诚实执行行为的经济保证。一旦任务未能在指定时间或质量要求下完成，或其结果被验证 Agent 判定为不合格、欺诈或未按约履约，则将自动触发罚没机制，执行 Agent 的质押将被部分或全部扣除，且其信誉状态也将同步降低。

监督审计

为了保障多 Agent 协作中的任务质量与系统可信性，Agent 协议层可内建一套结构化的监督与审计机制。有研究提出引入独立验证 Agent （Validation Agent）。验证 Agent 可以在不中断主任务流程的前提下，对协作过程中的关键中间步骤与最终产出进行真实性、正确性与合规性验证。验证机制有几种方式：

• 采用乐观验证模式：1）执行 Agent 提交结果，2）进入限定时间的挑战窗口，3）如果在此期间没有验证 Agent 或质押节点发起挑战，则结果自动通过并结算；4）若出现挑战，协议会触发仲裁程序，聚合多方验证报告，并根据质押博弈机制做出最终裁决。为防止懈怠攻击或挑战滥用，协议要求执行者与挑战者都需质押保证金。挑战成功则奖励验证者，失败者罚没质押，从而在经济上激励验证质量与系统健康。
• 强调“证据优先”原则：每次任务提交必须附带承诺数据（commitment）与最小可验证元数据，这些将被结构化封装进协议消息中，供验证 Agent 在隔离环境中进行重演、状态差分或见证背书。对于资金清算、敏感数据处理等高价值路径任务，协议可要求更强的验证证据。例如，在资金清算或敏感数据处理等环节，执行 Agent 可被要求提交更强的证明，包括零知识证明、可信执行环境的远程认证、或由独立见证者集体签名的背书结果。验证 Agent 会将其检验过程生成结构化的验证记录，附带验证方法、证据摘要、结论与置信度，从而形成可审计的轨迹。

现有框架中已出现验证 Agent 的探索雏形。AutoGen 引入了 Critic Agent 用于审查执行 Agent 的输出，但其验证停留在自然语言层面；MAPTA 将验证 Agent 设为独立角色，借由 Sandbox Agent 激活潜在漏洞，再由 Validation Agent 判断是否触发成功，有效降低理论型误报，其在标准基准测试中实现了 76.9% 的成功率；AgentGuard 将编排器（orchestrator）反向用作验证器，通过识别不安全的工作流、在真实环境中执行验证、生成安全约束并对约束有效性进行再验证，形成了一个闭环式的安全管控流程。在这些设计的基础上，可以将验证 Agent 制度化为协议层的基础角色，将验证过程与奖惩机制结合，从而在保持灵活性的同时，能够在关键场景中提供更强的安全保障与可追溯性。

为避免单点故障引发协作链条崩溃，Agent 协议层需内建多层次的 fallback 机制。现有框架已经探索过类似机制，例如 AutoGen 在执行失败时允许对话重写或引入新的候选 Agent ，Voyager 在策略失效后会自动探索替代路径等。Fallback 机制需要在执行、编排与协议三个层次中被系统化地支持：1）执行层，备用 Agent 接管来确保任务不中断；2）在编排层，Orchestrator 能够重构任务流程、重新分配子任务；3）在协议层，则可以通过定义统一的 fallback_action 字段来明确失败后的应对策略，包括回滚、转交或仲裁。通过将这些机制与监督审计结合，验证 Agent 在判定结果不合法或不可信时能够直接触发 fallback，从而保持协作链条的连续性与鲁棒性。

小结：协调协作层是为异构 Agent 之间协作，构建一系列的通讯协议、身份发现、任务分配和价值结算系统。让 Agent 协作机制从固定角色和静态流程，走向动态发现和弹性匹配的开放协同范式。这一转变的设计重心，也从流程建模转向协议层能力共享与调度策略优化。

5. 价值流通层（Value and Economic Layer）

Agentic Web 在重塑价值在网络中的创造与交换方式，主要体现在两个方面：(a) 以意图为驱动的经济系统（Intent Economy），经济活动不再围绕用户浏览行为，而是意图驱动的 Agent 行为；(b) 内容生态，内容的生产与分发需适应 Agent 的消费模式。

意图经济 Intent Economy

在 agentic web 中，用户意图成为触发经济活动的基础。Client Agent 将用户的意图转化为可执行的交易流程，通过平台接口调用服务资源，完成任务交易。这一过程构建出一个由意图驱动的经济系统——意图经济（Intent Economy）。它不同于广告经济中注意力曝光的范式，也不同于数据经济中基于用户画像推荐的范式，转而以精准的意图表达与资源匹配为中心。

传统平台中，流量的定义给予人类用户的点击、浏览、停留时间；在 Agentic Web 之中，流量变成 Agent 的接口调用频次。因此，平台原本依赖页面空间与流量分发变现的商业模式被削弱，其价值重心转向控制接口的数据流结构与排序逻辑。在这一模式下，平台通过结构化响应项（Structured Response Items）将商品、服务、内容等候选项返回给发起请求的 Client Agent。响应内容的结构组织（包括排序、嵌套、优先级元数据）成为平台新的商业控制点。商品或服务是否能进入 Agent 可见的候选集，是否获得靠前的调用顺序，往往取决于平台如何设计其接口响应结构，以及是否引入某种出价机制或排序逻辑。例如，一个旅游平台在接收到 Client Agent 的请求后，返回一个结构化的 JSON 响应，包含数个酒店方案，而方案的排序优先级则受到平台影响。

这个机制可类比为“面向 Agent 的广告”，即广告投放对象不再是人类用户，而是请求接口的 Client Agent。商家 Agent 若希望其商品服务在接口响应中被优先展示，可能需要通过平台广告、提交更优质的数据结构等。当 Agent 足够智能时，会评估“赞助选项”是否对用户真正有利——若无价值，可能直接忽略。这需要 Client Agent 更加智能，能够规避平台诱导偏差、识别无效激励，保护用户利益。同时，也迫使市场平台确保所有付费优先选项仍需维持一定的相关性与价值基线。

由于 Agent 不会被情绪煽动或视觉吸引，其选择主要基于定量指标（如价格、质量、用户偏好），因此广告形式会更偏向于算法竞价。因此，商家 Agent 更需要做出策略优化、智能执行，提供影响排序的竞价权重、可识别的重点字段、更丰富的数据结构等等。运营流程集中于“产品 / 服务意图识别 → 市场趋势与平台数据分析 → 结构化发布 → 监控匹配效果并优化表达”的链条。

Client Agent 的调用行为会生成响应的交易和调用数据。这些数据可以被聚合，形成基于意图的市场反馈系统，提供给商家 Agent 进行市场分析。数据分析能力会继续称为商家竞争力的核心之一：商家 Agent 需要洞察市场中用户意图的分布特征，快速识别被忽视的意图集，及时调整供给策略、优化结构表达，提升被 Agent 选中和用户意图匹配的概率。开放数据时必须有完善的制度设计以确保数据中立性和公平访问，让商家 Agent 享有平等透明的数据获取权，避免因信息不对称导致部分商家获得不当优势。平台需要通过标准化的协议和通用格式提供数据接口。同时，也需要对 Client Agent 交易和意图数据进行匿名化处理，保护用户隐私与系统中立性，防止商家反向建模用户。

虽然在意图经济的早期阶段，广告收入仍是平台内容运营和流量变现的重要手段，但其形态将发生根本性转变。广告的对象从人转向 Agent，营销策略从注意力吸引转向调用排序结构。这意味着意图经济中的广告机制将朝向数据中立、排序竞价、意图融合的方向发展，为平台、商家、用户三方之间建立新的价值连接逻辑。

内容生态

传统 Web 模式中，知识生态在用户的浏览、分享、互动、反馈中的开放循环里保持活跃。用户行为不仅是信息消费，也是贡献与反馈的过程，大部分问答社区和知识平台都在用户行为中实现了信息的生产、验证与迭代。然而，在 Agentic Web 中，这一循环正面临系统性瓦解：用户行为大量转移至私密的 Agent 界面完成，信息浏览被替代为 AI 的接口读取，反馈路径则部分或完全截断。

这一转变带来了“再利用悖论”：用户通过 Agent 获取信息的便捷性越高，对原始知识库的直接访问与贡献意愿就越低，从而使这些知识库的更新速率逐步下降，进而削弱未来 Agent 系统的知识基础，形成一个自我耗竭的负向循环。例如，Stack Overflow 自大模型问世后，其日发帖量出现断崖式下降。尽管如此，平台上提问的复杂化呈上升趋势，用户平均账号龄延长，使其聚焦于处理更复杂、更具深度的问题。相比之下，社交性较强的平台（如 Reddit 的同主题板块）则受到的影响相对较小，不同类型平台被冲击的程度存在差异。因此，当平台的交互性越强，其生态对 Agent 化的适应能力越强。同时，大模型也在其生成答案中保留所引用内容的原网址链接，鼓励用户访问查证、补充反馈。

可持续的 agentic web 需要维护知识生态的活跃度。这个问题可从两个方面切入：一是 Agent 的知识更新与反馈机制，二是激励机制对内容生产者与平台的系统调动。

首先，Agent 系统应具备主动识别“知识盲区”的机制，让 Agent 在运行过程中对低置信度响应设定阈值，当其遇到无法高置信度回答的问题时，应能够自动构造问题语句，识别最相关的开放社区或知识源，发出公开提问。再将后续响应纳入训练预料或缓存知识中，在用户授权或平台许可下同步更新长期知识存储。以此形成类“元问题”机制（meta-questioning），驱动知识生态的更新。

另一方面，在平台与创作者之间构建系统性的激励体系，实现内容可追踪、调用收益可分润机制。当前已出现多种探索方向：例如，Perplexity AI 设立出版商收益基金，将其订阅收入的 80% 分配给被引用的内容合作方，以引用次数为分配依据；Cloudflare 则提出按次抓取计费（Pay-Per-Crawl）协议，平台或网站可设置 Agent 抓取内容的价格与许可条件，通过 HTTP 402 状态码与签名验证形成自动化的 API 接口。Agent 可根据预算与需求自动交易。这一模式可扩展为一套跨平台的内容分发协议，让多个 Agent 系统共享统一的抓取或引用结算逻辑。内容平台或创作者只需接入一次，即可在整个联盟生态中获得收益。

此外，通过 Agent-to-Creator 的机制，让 Agent 的引用行为嵌入创作者的身份声誉之中。在 Web2 中，创作者声誉由用户行为构建，如浏览量、转发频率与评论互动；而在 agentic web 中，内容是否被 Agent 检索、调用与引用，将成为新的信誉评价核心。因此，需要设计基于 Agent 引用为基础的身份声誉体系，从而使引用频次、引用上下文与引用影响力等共同构成 Agent-to-Creator 声誉评价模型。被 Agent 广泛引用的内容及其创作者，可以得到更高的可信度权重，动态提升优质内容的可见度和排序权重，影响后续 Agent 在内容选择时的决策逻辑。同时， Agent-to-Creator 声誉权重也可以反馈给创作者，用于持续优化内容。最终，被 Agent 广泛调用的内容不仅可以获得经济收益，还将在整个知识图谱中获得更高的可信度。这为创作者提供了可被量化与反馈的外部价值，也为 Agent 系统建立了一套可追溯、可演化的内容信任基础。

结语

Agentic Web 正在构建更强大的 Agent 感知系统、更 Agent 原生的 Web 架构、更开放的多 Agent 协作机制。信息网络朝着更符合人类意图、更开放和动态的方向演进。尽管 Agentic Web 的发展趋势是由 Agent 主导的系统，但它的核心仍是服务人类用户，在于重塑人与数字世界之间的关系与交互范式。

因此，Agentic Web 的建构不仅是一项技术工程，更是一种社会结构的重构：我们需要设计对 Agent 有吸引力的激励机制、赋予开发者和用户足够的主权与交互自由、构建出既灵活又稳定的协议结构，支撑 Agent 网络的长期演化。这些都是人们必须直面的核心问题。站在这一转折点，走向一个持续演变的、服务人本身的智能体网络。