文档说明

这份白皮书研究一个尚未被证明、但值得被严格检验的问题：

当越来越多 Task 需要跨越不同 Agent、Tool、Service、数据和权限边界时，是否需要一个独立或联邦的 Coordination Layer，让 Agent 能够发现、评估、委托和验证外部 Capability？

本文先定义理论，再提出原型。它不是产品 PRD、融资叙事或协议标准，也不假设开放 Agent Internet 必然出现。

判断标签

观察：当前已有资料、协议或系统能够支持的描述。
工作假设：尚未被直接验证，但可被实验或现实结果推翻的判断。
已收敛结论：项目内部稳定采用的理论表述，不等于外部事实。
已推翻观点：已经被否定或显著修正的早期表达。
待验证问题：证据不足，必须保持开放的问题。

证据边界

本文引用 A2A、MCP、OAuth、Verifiable Credentials、Agent SDK 和相邻研究，用来证明相关技术对象与机制存在。它们不能证明独立 Coordination Layer 已经拥有市场需求，也不能替代目标场景中的对照实验。

Executive Summary

观察

Agent 正从单纯生成内容，走向调用 Tool、访问数据和产生外部行动。与此同时，完成真实任务所需的能力并不是单一对象：Model 提供推理，Tool 提供操作，Service 提供数据或履约，Agent 在授权边界内选择行动，组织和人类承担部分专业与责任角色。

现有协议已经开始处理这些边界：MCP 连接 AI 应用与 Tool、Resource、Prompt；A2A 连接独立 Agent，并定义 Agent Card、Task、Message、Artifact 与状态；OAuth 和 Token Exchange 提供受限访问与部分 Delegation 语义。

这些组件表明协调问题可以被清晰描述，但不证明一个新平台必然成立。

现实供给基础：Evidence-backed Supply Layer

截至 2026-07-27，关联项目 Agent Yellow Pages 已形成一份有界的供给索引：覆盖 40 个领域、10,022 个带官方证据的 Task Scenario、1,000 个 Product、1,015 个 ServiceOffer，以及 33,728 条 Product—Scenario 官方 Evidence Link。每个已发布的 ServiceOffer 都保留官方来源与已观察到的可用启动路径。

这是一项事实：分散的供给可以被结构化为 Task / Scenario → ServiceOffer → Product → Activation Path，并保留来源关系。它为 Capability Discovery 和候选 Matching 提供现实的供给侧输入。

它不是以下任一项的证据：独立检索质量已经成立、用户已经成功启动或完成任务、Provider 会接受特定委托、Grant 已被授予、执行状态可跨主体追踪、Result 已被独立验证，或 Verified Outcome 已能改善后续协调。因此，这层供给图谱支持 Discovery 的可行性，不替代本文对 P4、P5、P6 的验证要求。

从 Agent 库到可信供给网络

本文所说的“Agent 库”不是按名称、标签和热度排列的静态黄页，而是以 Provider、Capability Offer、当前可用性和条件化 Evidence 为核心的可信供给网络。其成熟度至少需要区分：

状态	最小含义
`Listed`	拥有可追溯的身份、Capability 声明、来源和版本记录
`Reachable`	可解析到当前入口或端点，并已观测到可建立连接
`Callable`	在明确身份、输入和授权条件下完成过真实调用，能返回状态或 Result
`Verified`	在冻结条件下通过一致性测试或独立验收
`Proven`	在真实的 Accepted Task 中持续产生与条件绑定的 Verified Outcome

当前 Supply Atlas 只证明 Listed 层的供给可以被结构化。部分记录包含可尝试的 Activation Path，但尚未经过统一的实时可达性、真实调用和独立验收，因此不能整体升级为 Reachable、Callable、Verified 或 Proven。

核心问题

如果 Primary Agent 已经理解用户目标，为什么不能直接调用最强 Model 或固定 Tool？

因为许多 Task 的瓶颈不只是推理能力，还包括：

外部数据和实时状态。
不同组织持有的权限。
专业 Capability 和现实履约。
Provider 的成本、时延、地域与 Policy 差异。
Task 接受、持续状态、失败恢复与结果验证。
行动的身份、授权和责任归属。

模型能力集中，不等于数据所有权、执行权和责任边界也会集中。

核心主张

AI 时代可能缺失的，不是另一个更强的 Agent，而是一组让独立 Agent 围绕具体 Task 发现 Capability、判断 Trust、形成 Delegation、获得最小授权并验证 Result 的公共协调语义与基础设施。

这个主张包含三个层次：

Agent Internet：不同 Principal 和组织的 Agent 可以跨域协作的长期愿景。
Coordination Layer：本文研究的控制层，连接 Task、Capability、Trust、Delegation、Authorization 和 Verification。
Task Completion Network：只有在真实执行结果能够持续改善后续协调时，才可能形成的网络状态。

第三层尚未被证明。

产品映射：从用户目标到 Verified Outcome

v0.2 增加一个面向产品的参考映射，用来说明理论对象如何出现在真实交互中：

User Goal / Intent

→ Thin Reference Client

→ Intent & Task Broker

→ Trusted Supply Network

→ Third-party Provider

→ Verified Outcome

User Goal / Intent：用户先表达想要达成的结果，而不是先浏览和挑选 Agent。
Thin Reference Client：可以是一个极简网页或 Chatbot，负责接收目标、暴露关键不确定性、请求必要确认并呈现结果。
Intent & Task Broker：将目标转成包含约束、权限、风险和 Completion Criteria 的 Task，完成候选召回、条件化 Matching、Proposal、Delegation、状态与失败恢复。
Trusted Supply Network：以 Task 条件而不是全局热度组织 Provider、Capability Offer、可用性和 Evidence。
Third-party Provider：接受、拒绝或修改 Task 边界，并在有限 Grant 下完成实际执行；协调层不默认亲自提供所有专业履约能力。
Verified Outcome：把 Result、Completion Criteria、Evidence、成本、异常和未验证项返回用户，不把 Provider 自报成功直接当成 Task Completion。

自有网页只是第一个 Reference Client，不是 Agent Internet 的网络边界。同一组 Broker 和 Task Transaction 语义应当也能被 Codex、Claude、企业 Agent 或其他 Primary Agent 通过 API、Plugin、MCP、A2A 或后续适配层调用。这不推翻 D6-A 对通用 Primary Agent 吸收风险的警惕：本项目不与它们争夺完整长期 Memory、通用本地执行权或封闭的综合 Runtime。

这是一项产品工作假设，不是已实现的产品现状。它不证明 Reference Client 已经获得需求、Broker 已经能稳定路由、第三方 Provider 已接受委托，或 Verified Outcome 已经形成飞轮。

产品与开放协议的演进顺序

“产品先行”不等于先做一个没有结构化内核的聊天外壳。第一版 Reference Client 从第一天起就应使用内部统一的 Task Request / Capability Offer / Proposal / Delegation / Grant / Task State / Result / Evidence / Verified Outcome 对象，但不应在缺少真实对照和外部采用时把它们宣称为公共标准。推荐的演进顺序是：

用薄 Reference Client 跑通一个边界清晰的 Task 类型，验证用户是否愿意从“选 Agent”转向“提交目标”。
使用内部交易对象接入少量真实 Provider，比较固定选择、静态 Discovery、Context-aware Matching 和 Managed Delegation。
只有在 Provider Acceptance、最小 Grant、Task State、Independent Verification 和 Outcome Evidence 通过预设门槛后，才扩大供给和对外入口。
先把稳定对象封装为 Provider SDK、Adapter 和一致性测试，降低外部接入成本。
只将经过多 Provider、多入口和真实履约反复验证的交互语义抽象为开放协议，并继续复用现有身份、授权、传输和 Agent 互操作基础。

这一顺序不保证最终一定形成独立协议。如果 P4 或 P5 失败，这些对象可以只作为产品内部 Schema；如果 P6 失败，则不应将 Outcome 数据描述为网络飞轮。

三个基本对象

本文不把 Agent、Task 或 Capability 中任何一个设为唯一中心：

Task 是一次有目标、约束、权限、状态和 Completion Criteria 的需求实例。
Capability 是某个主体在特定条件下能够产生某类结果的可描述能力。
Agent 是代表某个 Principal、在有限授权内选择并采取行动，且行为可被归属的软件主体。

Task 驱动一次协调，Capability 支持跨 Provider 发现与比较，Agent 承载选择、委托、执行和行为归属。

为什么 Discovery 不够

Discovery 只能形成 Candidate Set。从 Capability Claim 到 Verified Outcome 之间仍存在七个缺口：

Matching：是否适合当前 Task。
Trust：身份和 Capability Evidence 是否可信。
Commitment：Provider 是否接受这次 Task。
Authorization：Principal 是否允许它采取相关行动。
Execution：Task 如何更新、暂停、取消和恢复。
Verification：Result 是否满足 Completion Criteria。
Accountability：失败和责任如何归因。

对公共信息查询，Discovery + Direct Call 可能足够；对敏感数据、外部承诺和高影响 Task，完整闭环更可能必要。

六个核心命题

命题	当前状态	作用
P1 能力供给将持续分散	工作假设	解释外部协调需求
P2 搜索主体将部分转向 Agent	工作假设	解释 Machine-first 入口
P3 适配度比绝对能力更重要	已收敛理论判断，待实证	定义 Matching 目标
P4 Discovery 不足以形成任务闭环	已收敛理论判断，待实证	证明 Coordination 必要性
P5 协调层不必拥有全部原始 Context	高风险工作假设	证明独立控制平面可行性
P6 真实执行结果能够改善后续协调	高风险工作假设	解释学习与网络价值

P4 是“为什么不是只做 Discovery”的核心；P5 是“为什么可以成为独立控制平面”的核心；P6 是“为什么可能形成 Task Completion Network”的核心。

Coordination Layer 的最小闭环

Intent

→ Task Formation

→ Context Boundary

→ Capability Discovery

→ Matching

→ Trust Assessment

→ Proposal / Task Acceptance

→ Delegation

→ Authorization

→ Execution State

→ Verification

→ Feedback / Evidence

这些阶段可以分布在 Primary Agent、Provider、企业 IAM、独立服务和现有协议之间，不要求一个平台持有全部数据。

数据边界

本文倾向于把 Coordination Layer 设计为控制平面：

保存 Task Summary、身份、Capability Offer、Delegation、Grant 引用、状态和 Evidence。
不默认保存用户完整 Memory、原始敏感数据、长期 Token 和全部 Artifact。
在 Provider 被选定并接受 Task 后，再按需披露 Execution Context。

这项边界由 P5 支撑，必须通过“最小 Context 与完整 Context”的同任务对照实验验证。

Trust 与 Delegation

Trust 不是全局评分，而是：

Provider × Capability × Task Context × Evidence × Operating Conditions × Principal Policy

Delegation 不是普通 Tool Call。它需要绑定：

Task 与版本。
Delegator 和 Delegatee。
允许的行动与 Context。
时间、成本和风险边界。
Subdelegation Policy。
Completion Criteria 与 Verification。

Authentication 证明身份，Authorization 落实权限，Delegation 表达一次任务中的有限授权关系，三者不能混用。

参考模型

Coordination Layer 可以被理解为七个逻辑层：

Identity and Principal。
Capability Description and Discovery。
Task and Matching。
Trust and Evidence。
Delegation and Authorization。
Execution and Verification。
Governance and Audit。

它可以部署为 Primary Agent 内嵌模块、企业控制平面、独立协调服务、联邦网络或纯协议组合。

最强反方

独立 Coordination Layer 可能不会成立，因为：

更强的通用 Agent 可能吸收大部分专业能力。
OS 和超级助手可能内建协调并占据 Context 与入口。
企业可能只接受封闭 Provider 网络。
A2A、MCP、OAuth 等协议组合可能已经足够。
多 Agent 协调成本可能高于专业化收益。
Trust Evidence 可能无法安全迁移或抵抗攻击。
人类可能拒绝把高影响 Provider 选择交给 Agent。

如果 P4 失败，项目应收缩为 Discovery / Router；如果 P5 失败，应收缩为 Primary Agent 或企业内部控制平面；如果 P6 失败，应放弃数据飞轮和 Task Completion Network 叙事。

最小验证方向

本文建议先用“软件变更质量保障”作为研究原型，而不是直接做开放 Agent 商店。

同一批 Task、Provider 和预算下比较：

固定 Provider。
静态目录或全局排名。
Context-aware Matching。
加入 Proposal、Delegation、最小 Context、状态和 Verification 的 Managed Delegation。
加入 Verified Outcome 的 Evidence-aware Routing。

这个原型优先验证 P3、P4、P5，再验证 P6。它只是实验夹具，不是已经确定的产品切口。

当前成熟度

**已经具备：**正式概念定义、核心命题、反方论证、参考模型和验证设计。
**仍然缺失：**目标用户证据、真实多 Provider 数据、最小 Context 实验、Delegation 实现、Verified Outcome 和采用证据。

因此，本白皮书完成的是一套可被检验的理论框架，而不是对市场和网络已经成立的宣告。

第一部分：问题从哪里产生

第 1 章：从单一 Agent 到开放协作网络

1.0 本章要回答的问题

更强的单一 Agent 是否最终会吸收所有能力，从而让 Agent 之间的协调成为一个伪问题？

本章的回答是：模型能力的增强会提升单个 Agent 的通用性，却不会自动消除数据、权限、专业服务、现实执行和责任边界的分散。 因此，开放协作是否成为基础设施，不取决于模型会不会继续变强，而取决于有价值任务是否仍需跨越多个能力与信任域。

这是一项工作假设，不是已经发生完毕的历史事实。

1.1 观察：能力供给不是一个单一对象

今天被统称为“AI 能力”的供给，至少包含六类不同对象：

Model：提供推理、生成、预测或理解能力。
Tool：执行明确操作，例如查询、计算、写入或发送。
Skill / Workflow：封装可复用的解决步骤。
Agent：在授权边界内围绕目标选择并采取行动。
Service / Organization：提供数据、专业服务、库存、支付或现实履约。
Human Expert：承担需要判断、许可、签字或现实责任的环节。

这些对象可以组合，但不能互相替代。一个更好的 Model 可以改善计划，却不能凭空获得企业数据库权限；一个 Tool 可以执行支付，却不会自行判断是否应该支付；一个 Agent 可以选择服务，却不能自动拥有服务商的库存、牌照和责任能力。

现代协议也体现了这种分层：MCP 规范 AI 应用如何连接 Tool、Resource 和 Prompt；A2A 则面向独立 Agent 系统之间的通信与 Task 协作。两者解决的层次不同，说明“能力接入”与“行为主体协作”不能被简单合并为一个接口概念。

判断状态

观察。 不同能力对象和协议边界当前已经存在。

1.2 单一 Agent 的四种边界

1.2.1 认知边界

Agent 的 Model 不可能持续、准确地内生化所有领域知识和实时状态。即使推理能力足够强，许多信息仍然来自不断变化的外部系统。

1.2.2 执行边界

知道如何完成任务，不等于能够执行任务。执行可能需要：

一个受控 API。
一个现实世界设备。
一个有库存或履约能力的服务商。
一名具备资质的人类专业人员。
一个能够承担结果责任的组织。

1.2.3 权限边界

不同数据和资源属于不同 Principal。Agent 对一套系统有访问权，不代表它对另一套系统也有权。跨域行动必须重新认证、授权或获得委托。

1.2.4 责任边界

某些任务不仅要求产生结果，还要求有人对结果做出承诺、提供售后、接受审计或承担法律责任。软件 Agent 可以留下可归属记录，但它本身不因此获得法律人格。

推导

单一 Agent 的上限不只是“智能上限”，还包括它能合法、安全、经济地控制哪些外部资源。模型能力越强，Agent 可能越擅长跨越这些边界，但边界本身未必消失。

1.3 从 Tool Use 到跨主体委托

并非每次外部调用都构成 Agent 协作。

Tool Use

Agent 已经决定做什么，只需要调用一个确定操作。Tool 没有独立目标和接受任务的责任边界。

Service Invocation

Agent 调用外部服务获得结果，但服务可能只履行预定义契约，不围绕 Task 自主选择行动。

Delegation

Agent 把一个有目标、约束和生命周期的 Task 交给另一个主体。对方可以接受、拒绝、澄清、执行、返回状态或再委托。

三者的差别不是技术复杂度，而是控制权和责任边界：

模式	谁决定具体行动	是否接受 Task 责任	是否需要持续状态
Tool Use	调用方	否	通常不需要
Service Invocation	调用方与服务契约	有限	视服务而定
Delegation	接受委托的 Agent 在约束内决定	是	通常需要

暂定结论

未来生态不应被简单描述为“Agent 调用更多 Tool”。当外部主体拥有自己的目标、Policy、权限和执行选择时，问题已经从调用升级为协调。

1.4 三种可能的生态形态

能力分散不必然导向开放 Agent Internet。至少存在三种可能形态。

1.4.1 封闭整合

超级助手或操作系统提供统一入口，内部完成 Tool 选择、授权和路由。外部 Provider 只能通过平台批准的接口接入。

优点是体验一致、安全边界清楚；风险是分发与协调权高度集中。

1.4.2 企业或组织内联邦

多个部门、系统和 Agent 在同一组织的身份与治理框架下协作。跨组织调用仍然稀少或需要人工审批。

这是较现实的早期形态，因为身份、权限和责任更容易落在同一信任域内。

1.4.3 开放跨域协作

来自不同平台和组织的 Agent 可以发现 Capability、协商委托、交换最小 Context，并带回可验证结果。

这是 Agent Internet 的完整愿景，也是证据最不足、实现难度最高的形态。

工作假设

生态可能同时存在这三种形态，而不是由开放网络一次性取代封闭平台。Coordination Layer 是否独立存在，需要在这些形态之间找到不可被单一平台完全吸收的公共问题。

1.5 为什么现在讨论 Coordination

当前出现了几个方向性信号：

Agent Framework 已经把 Tool、Handoff、Guardrail 和 Session 作为基础构件。例如 OpenAI Agents SDK 把 Agent 表达为配置了指令、Tool 与运行行为的 Model，并支持 Handoff。
MCP 让 AI 应用可以动态发现并调用多个外部 Tool 和 Resource。
A2A 为独立 Agent 提供 Agent Card、Task 生命周期、Message、Artifact 与状态更新。
OAuth 等授权体系已经能够表达受限访问；RFC 8693 还提供 Token Exchange 及 Actor 链条等委托语义。

这些组件并没有自动组成完整 Coordination Layer，但它们使问题第一次可以被拆成相对明确的协议对象。

风险提示

“相关组件已经出现”不等于“新的平台机会已经成立”。这些组件也可能被现有云平台、操作系统或企业基础设施吸收。

1.6 代表性案例：一次跨境商务出行

假设一个 Primary Agent 接到任务：

在预算、签证、公司差旅 Policy、个人偏好和会议时间约束下，规划并完成一次跨境商务出行。

它可能需要：

读取日历与公司差旅 Policy。
判断签证和入境要求。
比较航班、酒店和地面交通。
使用企业协议价或个人会员权益。
在支付前请求确认。
处理价格变化、取消和改签。
把最终行程写回日历和报销系统。

一个 Model 可以给出计划，但真正完成 Task 需要跨越多个数据源、服务商、权限域和责任边界。

这个案例只是贯穿全文的解释工具，不代表最小原型已经选定差旅场景。

1.7 最强反方观点

反方 1：通用 Agent 最终会足够强

回应：它可能足够强地完成规划和选择，但仍需获得外部数据、权限和履约。真正的问题是协调是否由开放层处理，还是被超级入口内部化。

反方 2：API 与 Tool Calling 已经足够

回应：对确定、低风险操作可能足够；对需要候选比较、任务接受、持续状态和结果验收的跨主体工作则未必足够。

反方 3：企业不会允许开放 Agent 互调

回应：这可能成立，并会把 Agent Internet 缩小为组织内联邦或批准网络。白皮书必须把它视为真实边界，而不是暂时阻力。

反方 4：人类仍会选择重要服务商

回应：高风险决策可能继续由人批准，但候选召回、约束检查和低风险路由仍可能由 Agent 完成。P2 只主张“部分转向”。

1.8 本章结论

观察

Model、Tool、Service、Agent 和 Human Expert 已经构成不同的能力与责任对象，当前协议也分别处理上下文接入与 Agent 协作。

推导

模型变强不会自动统一数据、权限、履约和责任。因此，单一入口与多主体协作可以同时存在。

工作假设

有价值任务将越来越多地跨越多个能力和信任域，形成持续的协调需求。

暂定结论

白皮书研究的不是“如何让很多 Agent 聊天”，而是：当 Task 必须跨越多个独立能力与授权边界时，需要怎样的发现、信任、委托和结果机制。

风险 / 反例

如果少数平台能够在封闭体系内以更低成本完成绝大多数任务，独立开放 Coordination Layer 的空间会显著缩小。

第 2 章：问题不是找 Agent，而是完成 Task

2.0 本章要回答的问题

如果开放生态中存在大量 Agent，平台的中心任务是否就是“帮助用户找到 Agent”？

本章认为，这个表述把供给放在了需求之前。用户和 Primary Agent 的目标通常不是找到一个新 Agent，而是让某个现实任务达到可接受结果。因此：

Discovery 的起点应是 Task，检索对象应是 Capability Offer，Agent 则是接受委托、选择行动或承担结果归属的主体。

这不是要把 Agent 从系统中移除，而是把 Agent 放回正确位置。

2.1 Agent Directory 为什么容易偏离问题

一个 Agent Directory 通常围绕供给方组织信息：

Agent 名称。
开发者或 Provider。
分类与标签。
功能描述。
调用入口。
评分与使用量。

这些信息适合浏览，但不能直接回答：

当前 Task 真正需要什么结果。
哪些约束不能违反。
哪个 Provider 在当前 Context 下最合适。
需要披露哪些数据和权限。
如何判断任务已经完成。

目录可以是 Discovery 的一种实现，却不能替代 Task 建模、Matching 和 Delegation。

已推翻观点

“只要把足够多 Agent 收录并分类，Agent Internet 就会自然形成。”

问题不在收录量，而在一次具体需求如何转化为可验证的跨主体工作。

2.2 从 Intent 到 Task

人类最初表达的往往是 Intent：

帮我安排下周去东京见客户。

这还不是一个可被可靠委托的 Task。Primary Agent 需要逐步形成：

会议时间是否确定。
出发地和最晚到达时间。
护照、签证和入境约束。
公司预算与舱位 Policy。
可接受的转机、酒店和交通偏好。
哪些步骤可以自动执行。
哪些步骤必须由人确认。
什么状态算“安排完成”。

因此，Task 不是一条 Prompt，而是一个会被澄清、约束、分解和跟踪的工作单元。

Task Formation

本文把 Intent 转化为可协调 Task 的过程称为 Task Formation。它至少包含：

明确 Desired Outcome。
识别硬约束与软偏好。
识别缺失 Context。
确定允许的权限和风险。
定义 Completion Criteria。
判断是否需要拆成 Subtask。

Task Formation 可以由 Primary Agent、人类或双方共同完成。

2.3 从 Task 到 Capability Requirements

Task 不能直接与 Agent 名称匹配。协调系统需要先提取 Capability Requirements。

以商务出行为例，可能包含：

读取企业差旅 Policy。
检查入境条件。
搜索并比较可售库存。
使用特定身份或会员权益报价。
生成满足时间约束的组合行程。
在得到确认后执行预订与支付。
处理取消、变化和通知。

这些 Requirement 不预设由一个 Agent 完成。某个 Provider Agent 可以组合多项 Capability，也可以只承担其中一个 Subtask。

推导

先表达 Capability Requirements，再寻找 Provider，有三个好处：

可以比较不同实现方式，而不被 Agent 品牌绑定。
可以把复杂 Task 拆成风险和权限不同的 Subtask。
可以对每项结果分别定义验证方式。

2.4 “最适合”不是一个单一分数

对当前 Task 的适配度可能由多个维度组成：

维度	需要回答的问题
Capability Fit	是否真正能产生所需结果
Context Fit	是否理解或支持当前环境、语言、地域和领域
Constraint Fit	是否满足成本、时间、格式、Policy 等约束
Authority Fit	是否能在最小权限下完成任务
Trust Fit	身份、历史行为与证据是否足够可信
Operational Fit	当前是否可用，容量和时延是否合适
Verification Fit	结果是否可被可靠验收

因此，一个 Provider 可以在某项能力上更强，却因为价格、数据驻留、权限范围或结果不可验证而不适合当前 Task。

已收敛表述

从“寻找最强 Agent”改写为：

在当前 Task、Context、约束和风险条件下，寻找预期效用最高的 Capability Offer 与 Provider。

2.5 Task 不是静态查询

把 Task 当成一次搜索 Query 会遗漏四种动态性。

2.5.1 澄清

Provider 可能在接受前要求补充输入、约束或权限。

2.5.2 协商

成本、交付时间、输出形式和责任范围可能需要重新确认。

2.5.3 执行变化

库存、价格、系统状态或外部事件可能在执行中变化，导致重新路由或降级。

2.5.4 结果验收

输出 Artifact 不等于 Task 完成。结果还需要与 Completion Criteria 比较，并可能触发修正、拒绝或人工介入。

暂定结论

任务匹配既包含 Search 和 Recommendation，也包含 Scheduling、Policy Evaluation 与 Delegation。任何单一类比都只能解释其中一部分。

2.6 Agent、Task、Capability 的正确关系

第 3 章将三者正式定义为：

Task：一次有生命周期的需求实例。
Capability：面向一类 Task 的结果能力。
Agent：在授权边界内选择、接受委托或采取行动的主体。

因此，它们不是三个互斥的中心：

Task 驱动一次协调。
Capability 使供给可以被发现和比较。
Agent 承载行动选择与行为归属。

关系链

Intent

→ Task Formation

→ Capability Requirements

→ Capability Discovery

→ Provider Matching

→ Task Acceptance / Delegation

→ Execution / Verification

Task 位于链路起点，但身份与信任需要跨 Task 持续存在；因此不能把整个网络简化成无主体的 Task Marketplace。

2.7 什么时候“找 Agent”仍然合理

以下场景中，Agent-centered Discovery 仍然有价值：

用户已经信任某个长期合作的专业 Agent。
Agent 的风格、关系连续性或责任主体比单项能力更重要。
Provider 提供一组无法拆开的综合服务。
Task 需要多轮互动，切换 Provider 的成本很高。
企业只允许从批准 Agent List 中选择。

因此，白皮书不是反对 Agent Identity 或 Agent Directory，而是反对把目录当成完整问题定义。

2.8 失败归因需要 Task 视角

如果一次委托失败，原因可能是：

Task 表达错误。
Capability Requirement 提取错误。
Provider 匹配错误。
Context 披露不足。
授权范围错误。
Provider 执行失败。
Completion Criteria 不合理。
Verification 失败。

只给 Agent 一个差评会把多个环节混成一个分数。Task 视角让系统能够区分：是谁在什么条件下、哪一步出了问题。

这也是 P6 中“执行 Evidence 必须条件化”的原因。

2.9 风险 / 反例

Task 很难被完整表达

成立。本文不要求 Task 在开始时完整，只要求它可以通过状态、澄清和约束逐步收敛。

用户不想填写复杂结构

成立。Task Formation 应主要由 Primary Agent 从自然语言和已有 Context 中完成，并把关键不确定性暴露给用户，而不是让用户填写长表单。

Provider 可能比请求方更懂如何定义任务

成立。Task Request 与 Accepted Task 之间需要协商，Provider 可以提出更可行的边界。

过度结构化会损失新颖性

成立。Capability Schema 应允许开放描述和扩展，不能要求所有任务先进入固定分类法。

2.10 本章结论

观察

用户表达的是 Intent，真正可协调的对象是逐步形成的 Task；Agent 名称和能力标签不足以描述一次任务的约束、权限和成功标准。

推导

协调系统需要把 Task 转化为 Capability Requirements，再结合 Context、Trust 和运行条件选择 Provider。

已收敛结论

目标不是“找 Agent”，而是“完成 Task”。
Discovery 的主要检索对象应是 Capability Offer。
Agent 仍然是接受委托、选择行动和形成行为归属的主体。

工作假设

Primary Agent 可以在不过度增加用户负担的情况下完成足够好的 Task Formation。

风险 / 反例

如果真实 Task 无法形成稳定、可比较的 Requirement，或者结构化成本高于匹配收益，Coordination Layer 将只能服务少数高度标准化场景。

第二部分：定义与核心命题

第 3 章：核心概念与边界

3.0 为什么需要重新定义

Agent 已经成为一个高度泛化的词：一个配置过 Prompt 的模型、一个固定 Workflow、一个 MCP Server，甚至一个只有聊天界面的产品，都可能被称为 Agent。如果白皮书沿用这种宽泛用法，Discovery、Trust 和 Delegation 将失去明确对象。

本章不试图给出适用于所有研究和产品的唯一标准，而是提出一套服务于开放协作网络的操作性定义。一项定义是否有用，取决于它能否帮助回答以下问题：

谁在代表谁行动？
谁对下一步行动拥有选择权？
谁能够提供什么能力？
哪个任务被委托给了谁？
哪些权限和上下文随委托被授予？
结果、失败和责任可以归属于谁？

3.0.1 与现有定义的关系

经典 Agent 研究通常从自主性、反应性、主动性和社会能力描述 Agent。现代 Agent SDK 则常采用更偏工程实现的定义，例如把 Agent 表达为配置了指令、工具和运行行为的模型。A2A 协议关注独立 Agent 之间的互操作，把 Task 作为具有状态和生命周期的工作单元，并通过 Agent Card 描述身份、接口和 Skill。MCP 主要规范 AI 应用与外部工具、资源和 Prompt 之间的上下文交换，不规定应用如何使用模型，也不天然构成 Agent。

本章吸收这些定义，但增加两个对 Coordination Layer 必不可少的约束：

Agent 必须有可识别的代表关系与授权来源。
Agent 必须有可识别的行为、权限与责任边界。

这是一项规范性取舍。它会排除部分被市场称为 Agent 的简单软件，但能让 Trust 与 Delegation 有清晰的落点。

3.1 Agent

3.1.1 正式定义

Agent 是一个具有可识别行为边界的软件行动主体：它代表某个 Principal，在给定目标、上下文、权限与约束下，对下一步行动保有有限的自主选择，并能通过自身行为或调用外部 Capability 产生可观察结果；其行为可以被归属、限制、审计和终止。

这一定义包含六个必要条件。

1. 代表关系：Representing a Principal

Agent 不是无来源的自主实体。它直接或间接代表某个人、组织或上级 Agent 行动。这个关系决定了：

Agent 的目标从哪里来。
Agent 有权使用哪些数据、工具和资源。
Agent 可以承担多大风险。
出现失败或冲突时应向谁升级。

代表关系不要求 Principal 实时批准每一步，但必须能够解释 Agent 的授权来源。

2. 目标导向：Goal-directed

Agent 接收的是目标、任务或期望结果，而不只是一个确定函数的参数。它需要围绕目标判断当前状态与下一步行动。

目标可以不完整，也可以在交互中被澄清。Agent 不需要理解人类全部意图，但必须能够维持“当前正在尝试完成什么”的任务状态。

3. 有限自主性：Bounded Autonomy

Agent 在允许的行动空间内拥有一定选择权，例如：

是否需要追问。
使用哪个 Capability。
采用什么步骤或顺序。
是否委托给其他 Agent。
是否拒绝、暂停、重试或升级。

自主性不是无限权限，也不等于脱离人类控制。需要审批、受 Policy 约束或只能在 Sandbox 内行动的系统，仍然可以是 Agent。关键在于它是否对至少一部分行动选择拥有控制权。

4. 行动能力：Ability to Act

Agent 必须能产生可观察结果，例如输出一份交付物、改变系统状态、调用工具、发送请求或发起委托。只有生成内部推理、但不能产生任何可交付结果的组件，不构成本白皮书中的完整 Agent。

5. 任务状态：Task State

Agent 必须能够读取或维持完成当前 Task 所需的状态。状态可以存在于模型上下文、外部数据库、Workflow Engine 或其他运行时中，不要求 Agent 自己拥有永久 Memory。

因此，持久记忆不是 Agent 的必要条件；能够处理当前任务的连续性才是。

6. 可归属边界：Attributable Boundary

外部系统必须能够在合理程度上识别：

正在与哪个 Agent 交互。
它代表谁或由谁运营。
它声明拥有哪些 Capability。
它当前获得了哪些权限。
哪些行动和结果应归属于它。

身份不一定是全球统一 ID，但不能只有一个无法区分来源的模型输出。

这里的“可归属”是技术和治理意义上的行为追踪，不表示 Agent 自身拥有法律人格或承担最终法律责任；最终责任仍需回到运营主体与授权链条中判断。

3.1.2 什么不是必要条件

以下特征可能增强 Agent，但不构成必要条件：

使用 LLM。
拥有拟人化名称或形象。
拥有长期 Memory。
同时调用多个 Tool。
能与人自然语言对话。
能持续自主运行很长时间。
使用某个特定 Agent Framework。

一个基于确定性 Policy 的系统也可能是 Agent；一个非常强的 LLM Endpoint 也可能仅仅是 Model。区别不在“智能程度”，而在是否形成了目标、选择、行动、授权和归属的完整边界。

3.1.3 Agent 的最小判定测试

判断一个系统是否属于本文所称的 Agent，可以依次询问：

它代表哪个 Principal？
它接收的是目标或 Task，还是一个确定操作的参数？
它是否能在多个可能行动之间作出选择？
它是否能产生可观察结果或改变外部状态？
它的身份、权限和行为能否被区分与归属？
它能否被限制、撤销或终止？

如果第 2、3 项不成立，它更可能是 Tool 或固定 Workflow；如果第 5、6 项不成立，它可能具有 Agentic Behavior，但还不是适合进入开放协调网络的 Agent。

3.1.4 Networked Agent

并非所有 Agent 都天然属于 Agent Internet。本文把能够参与开放发现与委托的 Agent 进一步称为 Networked Agent。

除满足 Agent 定义外，Networked Agent 还需要至少提供：

可解析的身份或运营主体信息。
可发现的 Capability 声明。
可访问的交互端点或委托方式。
明确的认证与授权要求。
可观察的 Task 状态或结果返回机制。
失败、取消和终止语义。

这些要求描述的是网络参与资格，不限定必须使用某一种协议。

3.1.5 边界案例

LLM Endpoint

模型提供推理或生成能力，但通常不独立持有目标、权限和任务责任。它是 Agent 的组成部分，不自动等于 Agent。

固定 Workflow

如果每个步骤和分支都由外部预先决定，系统只是执行流程，不具有必要的行动选择权。如果 Workflow 中存在一个能根据目标和状态自主选择行动的控制主体，则整体系统可能构成 Agent。

MCP Server

MCP Server 可以暴露 Tool、Resource 和 Prompt，也可以支持复杂逻辑，但 MCP 身份本身只说明一种协议角色。只有当该系统同时满足代表关系、目标导向、自主选择、行动和归属边界时，才属于本文定义的 Agent。

A2A Endpoint

支持 A2A 能证明系统能够使用 Agent 间交互协议，不能单独证明其内部具有本文要求的自主性。一个把固定 API 包装成 A2A 接口的服务，更准确地说是“可通过 A2A 调用的服务”。

Human-in-the-loop System

需要人在高风险步骤批准，不会取消 Agent 属性。审批是自主性的边界，而不是自主性不存在的证据。

多个 Agent 共用一个 Runtime

是否属于多个 Agent，不取决于进程数量，而取决于它们是否具有可区分的目标、身份、权限、状态和行为归属。

3.2 Principal

虽然本章的主要对象是 Agent、Task 和 Capability，但如果不定义 Principal，就无法解释 Agent 的权限和责任从何而来。

3.2.1 正式定义

Principal 是授权 Agent 代表其行动，并最终承受该行动主要收益、成本或风险的个人、组织或上游行为主体。

一次委托链中可以同时存在：

Root Principal：委托链最终服务的人或组织。
Immediate Principal：直接向当前 Agent 下达任务或授予权限的主体。

例如，用户把行程规划交给个人 Agent，个人 Agent 再委托给旅行 Agent。对旅行 Agent 而言，个人 Agent 是 Immediate Principal，用户是 Root Principal。

3.2.2 工作假设

涉及外部数据、资金、通信或现实世界行动时，委托链应能在授权范围内追溯到可承担责任的 Root Principal。匿名研究或低风险公共查询可以例外，但不能把例外默认为所有 Agent 协作的基础。

3.3 Task

3.3.1 正式定义

Task 是一个需要被推进到可判定状态的有边界工作单元：它表达期望结果、当前已知上下文和约束，并具有可跟踪的生命周期，以及完成、失败、取消或等待补充信息等终止或中断条件。

Task 是一次具体需求，不是抽象能力。它回答“这一次要完成什么”，而 Capability 回答“某个主体通常能够完成什么类型的事情”。

3.3.2 Task 的最小构成

一个能够进入协调过程的 Task，至少需要逐步形成以下信息：

Desired Outcome：希望得到的结果或状态变化。
Context：完成任务所需的当前信息。
Constraints：时间、成本、质量、格式、Policy 与风险限制。
Authority：允许使用的数据、工具、资金或外部行动范围。
Completion Criteria：如何判断结果可以被接受。
Lifecycle State：当前是待澄清、已提交、执行中、已完成、失败、取消还是被拒绝。

这些信息不必在 Task 创建时全部完整。真实任务往往从模糊意图开始，在澄清和执行过程中逐步收敛。

3.3.3 Task、Intent 与 Message

三者不能混用：

Intent 是 Principal 想要发生的变化，可能模糊且没有边界。
Message 是传递信息的一次通信行为。
Task 是需要被跟踪、委托和判定状态的工作单元。

一条 Message 可以表达 Intent、补充 Context 或更新 Task，但 Message 本身不等于 Task。同一个 Intent 可能被拆成多个 Task，一个 Task 也可能跨越多轮 Message。

3.3.4 Task Request 与 Accepted Task

发现和匹配阶段产生的是 Task Request：它询问某个候选者是否愿意并能够承担工作。

候选者接受后，才形成具有明确执行主体和约束的 Accepted Task。这个区别很重要，因为：

能力匹配不等于对方承诺执行。
接受 Task 可能需要重新协商成本、时间、权限或成功标准。
Delegation 发生在“请求”转化为“被接受的责任”这一边界上。

3.3.5 Task 分解

一个 Task 可以被分解成多个 Subtask，但分解会引入新的责任边界：

谁决定分解方式。
每个 Subtask 被委托给谁。
哪些 Context 和权限可以继续向下传递。
子结果如何汇总与验证。
上层 Agent 是否仍对最终结果负责。

因此，Task Graph 不是普通 Workflow Graph 的同义词。前者还需要记录委托、授权与责任关系。

3.3.6 工作假设与风险

工作假设： Task 是协调过程的起点，因为协调系统需要先理解一次具体需求，才能寻找合适的 Capability。

这不等于认定 Task 是整个 Agent Internet 唯一的中心。开放网络仍然需要持久的 Agent Identity、Capability 描述和 Trust 关系。

主要风险是：

复杂目标可能无法提前形成稳定 Task。
成功标准可能主观或在执行中变化。
Task 的边界可能由提供者而不是请求者决定。
过度结构化会增加用户和主 Agent 的表达成本。

3.4 Capability

3.4.1 正式定义

Capability 是某个主体在特定前提和约束下，能够产生某类结果或状态变化的可描述能力。它面向一类潜在 Task，而不是某一次具体执行。

Capability 连接需求与供给，但不等于宣传文案，也不等于一个可调用 Endpoint。协调系统需要区分“声称能做”“具备调用方式”和“已经被结果证明能做”。

3.4.2 三个层次

Capability Type

与具体提供者无关的抽象能力类别，例如：

把一段会议录音转成带时间戳的逐字稿。
在给定预算和日期内生成可预订的差旅行程。
检查一个代码变更是否违反指定安全规则。

Capability Type 用于表达 Task 需要什么。

Capability Offer

某个 Agent、Service 或组织对外提供的具体能力承诺。除能力类别外，还应描述：

支持的输入与输出。
适用范围和不支持事项。
所需 Context、认证与权限。
成本、时效和容量。
数据处理与保留 Policy。
交互方式和服务端点。
结果验证方式。

Capability Offer 是 Discovery 和 Matching 的主要对象。

Capability Evidence

用于判断 Capability Offer 是否可信的证据，例如：

可复现测试。
认证或审计结果。
特定任务条件下的历史完成记录。
失败率、取消率和人工复核结果。
来自可信主体的结构化反馈。

Capability Evidence 不应与提供者自己的声明混为一谈。

3.4.3 Capability 的最小描述

一个机器可用于初步匹配的 Capability Offer，至少需要表达：

Outcome：能产生什么结果。
Preconditions：成立需要哪些前提。
Input / Context：需要什么输入和上下文。
Authority：需要什么权限。
Constraints：范围、成本、时效、容量和限制。
Output：结果形式和可观察状态。
Verification：如何判断结果符合承诺。
Provider：由谁提供并承担对应责任。

这不是最终 Schema，只是判断一个能力描述是否足以进入协调过程的概念检查表。

3.4.4 Capability 与 Skill

本文暂时采用以下边界：

Skill 是某个 Agent 或系统用于实现、封装或对外呈现一个或多个 Capability 的可复用单元。

因此：

Capability 描述“能够造成什么结果”。
Skill 描述“某个提供者如何把这种能力组织成可复用单元”。
同一个 Capability 可以由多个不同 Skill、Tool 或 Agent 实现。
一个 Skill 也可能组合多个底层 Capability。

A2A 的 AgentSkill 同时承担 Capability 声明与 Agent 内部 Skill 描述的作用。白皮书在概念上将两者分开，以便跨提供者比较相同类型的能力。

3.4.5 风险 / 反例

Capability 很难完全脱离具体提供者和上下文进行描述。
自然语言描述可能无法支持稳定的机器匹配。
成本、质量和可用性会随时间快速变化。
一个能力在测试环境成立，不代表在真实授权和数据条件下成立。
标准化过强可能排除新能力，标准化过弱则无法比较。

3.5 相邻概念边界

概念	本文中的含义	与 Agent / Task / Capability 的关系
`Model`	提供推理、预测或生成能力的计算组件	可以支持 Agent 决策，但不自动具有目标、权限和责任边界
`Tool`	具有明确输入、操作和输出的可调用函数	是 Agent 采取行动的机制，也可以实现某项 Capability
`Skill`	某个提供者封装或呈现能力的可复用单元	可以实现或声明一个或多个 Capability
`Workflow`	预先定义的步骤、依赖和控制流	可以被 Agent 使用；只有存在自主行动主体时，整体才可能是 Agent
`Service / API`	对外提供功能的部署与访问形式	可以承载 Tool、Capability 或 Agent，但接口形式不决定其本体类型
`MCP`	AI 应用与 Tool、Resource、Prompt 等交换上下文和调用信息的协议	连接 Agent 与外部能力；MCP Server 不自动等于 Agent
`A2A`	独立 Agent 系统之间通信、Task 跟踪和互操作的协议	可承载 Networked Agent 的交互，但协议兼容不单独证明 Agent 属性
`Prompt`	给 Model 或 Agent 的一段指令或上下文	可能表达 Intent 或 Task 信息，但不等于 Task 本身
`Orchestrator`	负责安排多个步骤或执行主体的控制组件	如果它具有目标、选择权和归属边界，可以是 Agent；否则可能只是 Workflow Engine
`Coordination Layer`	跨主体完成发现、匹配、信任判断、委托、状态与结果反馈的控制平面	连接具体 Task、Capability Offer 与 Agent，不必亲自执行 Task

3.6 三个核心概念的关系

可以用一句话概括：

Task 表达一次具体需求，Capability 描述可供选择的结果能力，Agent 是在授权边界内理解 Task、选择或提供 Capability，并对行动形成可归属记录的主体。

三者分别对应：

Task：需求实例。
Capability：供给类型与供给承诺。
Agent：做出选择、接受委托或采取行动的主体。

一个最小协调链路是：

Principal Intent

→ Primary Agent 形成 Task Request

→ Task 被转换为 Capability Requirements

→ 发现并比较 Capability Offers 与 Evidence

→ 选择 Provider Agent

→ 协商并形成 Delegation

→ Provider Agent 使用 Skill / Tool / Service 执行 Accepted Task

→ 产生 Result 与 Verification Evidence

→ 结果返回 Principal，并形成新的 Capability Evidence

3.6.1 为什么 Agent 不是唯一中心

只围绕 Agent 建目录，会把“这个 Agent 是谁”置于“这次任务需要什么”之前，也难以比较多个提供者对同一 Capability 的不同约束。

3.6.2 为什么 Task 也不是唯一中心

Task 是瞬时需求。身份、能力供给和信任关系需要跨 Task 持续存在，否则每次协调都必须从零开始。

3.6.3 为什么 Capability 也不是唯一中心

Capability 是抽象供给。没有具体 Task，无法判断适配度；没有 Agent 或 Provider，无法形成授权、执行和责任关系。

3.6.4 暂定结论

Agent / Task / Capability 不是互相竞争的三个中心，而是协调网络中不可互相替代的三个基本对象：

Task 驱动一次协调。
Capability 支持跨提供者发现与比较。
Agent 承载选择、委托、执行与行为归属。

这是本章最重要的概念收敛，但仍需由后续 Trust、Delegation 和原型章节检验。

3.7 对后续章节的约束

以上定义直接产生以下设计约束。

对 Discovery 的约束

Discovery 的主要检索对象应是 Capability Offer，而不是只返回 Agent 名称。Agent Identity、运营主体和访问方式是 Offer 的归属信息。

对 Matching 的约束

Matching 比较的是 Task Requirements 与 Capability Offer + Evidence，不能只比较关键词或全局排名。

对 Trust 的约束

Trust 不应只是 Agent 的单一全局分数，更合理的对象是：

Provider × Capability × Task Context × Operating Conditions

对 Delegation 的约束

Delegation 不是普通 Tool Call。它至少包含：

一个 Accepted Task。
一个承担工作的 Agent 或 Provider。
一组可传递的 Context 与权限。
一组约束、生命周期和终止条件。
一个结果归属与验证方式。

对 Coordination Layer 的约束

Coordination Layer 需要处理身份、Capability 描述、Task 状态、授权边界和结果证据，但不因此必然需要持有全部原始上下文或亲自执行任务。

对 Task Completion Network 的约束

网络价值不能只来自 Agent 数量或 Capability 声明数量。更有意义的边是实际发生过的委托及其可验证结果。

3.8 风险与待验证问题

定义风险

本文对 Agent 的要求可能过于严格，与行业通行叫法不一致。
现实系统中的 Principal 和责任链可能无法清晰识别。
Agent 的自主选择与 Workflow 的动态分支可能很难从外部区分。
Capability Offer 可能无法准确表达真实能力。
Task 在执行前可能没有稳定边界和成功标准。

待验证问题

Agent 是否必须具有稳定身份，还是每次 Task 的临时身份已经足够？
Root Principal 是否需要对所有外部委托可见？
Capability Type 能否跨行业形成可复用标准？
Capability Evidence 应由提供者、协调层还是独立验证者保存？
一个固定 Workflow 需要拥有多大的动态选择空间，才应被视为 Agent？
对低风险、一次性任务，完整 Delegation 结构是否成本过高？

3.9 本章结论

观察

现有生态对 Agent、Task、Skill、Tool 和 Capability 的使用并不统一。协议和 SDK 往往根据自身实现目标定义概念，不能直接替代 Coordination Layer 所需的跨主体边界。

推导

如果系统需要在开放网络中完成发现、信任判断与委托，它就必须能够区分：谁在行动、要完成什么、能够提供什么、权限来自哪里，以及结果归属于谁。

已收敛为新表述

Agent / Task / Capability 不应争夺同一个“中心”位置：

Agent 是可归属的行动主体。
Task 是一次有生命周期的需求实例。
Capability 是面向一类 Task 的结果能力。

工作假设

以这三个对象为基础，再加入 Principal、Delegation 与 Evidence，足以描述 Coordination Layer 的最小概念模型。

风险 / 反例

如果现实中的 Agent 无法形成稳定身份与授权边界，或者 Task 与 Capability 无法被机器有效描述，那么独立 Coordination Layer 的适用范围将显著缩小。

本章参考锚点

Michael Wooldridge 与 Nicholas R. Jennings，Intelligent Agents: Theory and Practice。用于追溯自主性、反应性、主动性和社会能力等经典 Agent 属性。
OpenAI Agents SDK：Agents。用于对照现代 SDK 中以 Model、Instructions、Tools 和运行行为构成 Agent 的工程定义。
A2A Protocol Specification。用于对照 Agent Card、Agent Skill、Task 生命周期、Message 与 Artifact 等协议对象。
Model Context Protocol：Architecture Overview。用于界定 MCP 的 Host、Client、Server、Tool、Resource、Prompt 与上下文交换范围。

第 4 章：白皮书的核心命题

4.0 本章的任务

第 3 章回答了 Coordination Layer 需要处理哪些基本对象。本章进一步回答：整份白皮书究竟依赖哪些主张，这些主张之间是什么关系，以及什么证据会让我们接受、缩小或推翻它们。

本章不把未来趋势写成既定事实。六个命题包含三种不同性质：

环境命题：描述 Coordination Layer 可能出现的外部条件。
机制命题：解释为什么现有 Discovery 或单一排名不足以完成协调。
可行性与积累命题：解释独立协调层能否成立，以及是否会随使用持续改善。

4.0.1 命题的统一检验方式

每个命题统一回答七个问题：

精确主张是什么。
当前有什么观察或相邻证据。
从观察到主张之间需要哪一步推导。
当前应将它标为哪种判断状态。
最强反例是什么。
什么结果会使它被推翻或缩小。
如何用研究或原型验证。

“已有协议为某种问题设计了对象”只能证明生态正在处理这个问题，不能证明独立 Coordination Layer 必然存在市场需求。类似地，相邻领域的路由或信誉研究只能作为可行性线索，不能替代 Agent 场景中的直接证据。

4.0.2 六个命题的角色

命题	角色	当前状态	对白皮书的重要性
P1 能力供给将持续分散	环境条件	工作假设	高
P2 搜索主体将部分转向 Agent	入口与交互变化	工作假设	中
P3 适配度比绝对能力更重要	Matching 目标	已收敛的理论判断，待实证	高
P4 Discovery 不足以形成任务闭环	Coordination Layer 必要性	已收敛的理论判断，待实证	最高
P5 协调层不必拥有全部原始上下文	独立控制平面可行性	高风险工作假设	最高
P6 真实执行结果能够改善后续协调	学习与网络价值	高风险工作假设	高

4.1 命题 P1：能力供给将持续分散

4.1.1 精确主张

在可预见的 Agent 生态中，完成有意义任务所需的 Capability、数据、权限、专业知识和执行资源，将持续分布在不同 Agent、组织、Service 与信任域中；不存在一个能够在可接受成本和风险下，长期内生化全部供给的单一 Agent。

这里的“分散”不是指用户一定要面对多个产品界面。一个 Primary Agent 可以成为统一入口，但它背后仍可能需要协调多个能力提供者。

4.1.2 观察依据

当前互操作协议本身已经把异构供给作为设计前提：

A2A Protocol 面向由不同框架、语言和供应商构建的独立 Agent 系统，目标是让这些系统发现能力、管理协作 Task，并在不暴露内部实现的情况下交互。
MCP Architecture 采用 Host–Client–Server 结构，一个 AI 应用可以连接多个 MCP Server，分别获得 Tool、Resource 和 Prompt。

这些事实说明“一个 Agent 使用外部能力”已经成为现实架构问题，但还不能证明这种分散必然长期存在。

4.1.3 推导

即使基础 Model 持续变强，以下资源仍可能难以被单一 Agent 完全内生化：

组织内部数据与业务系统。
受地域、牌照或合同限制的专业服务。
代表不同主体持有的身份与权限。
实时变化的库存、价格和运行状态。
需要现实世界执行或人工承担责任的服务。
在成本、时延、隐私和质量上具有不同优势的专业能力。

模型能力集中，不等于数据所有权、执行权和责任边界也会集中。因此，更强的 Primary Agent 可能减少用户切换入口的次数，却不一定消除外部协调。

4.1.4 当前判断状态

工作假设。 当前生态与协议发展与该命题一致，但缺少跨场景、长期的直接证据。

4.1.5 最强反例

操作系统、超级助手或少数基础模型平台可能通过以下方式吸收分散性：

内建最常用的专业能力。
与主要服务商完成商业整合。
统一身份、支付、授权和数据访问。
在平台内部完成路由，使外部 Coordination Layer 没有独立位置。

在这种未来中，能力仍可能在技术上分散，但协调权被少数封闭入口掌握。对白皮书而言，这与能力完全不分散具有相近后果：独立开放协调层的空间会显著缩小。

4.1.6 可证伪条件

在选定场景中，如果长期观察到以下情况，P1 应被缩小或推翻：

一个 Agent 或平台可以在没有外部能力选择的情况下完成绝大多数目标 Task。
外部 Provider 之间不存在有意义的质量、成本、权限或风险差异。
接入更多外部能力没有显著提高任务完成率或约束满足率。
用户和组织稳定地接受单一平台拥有所需数据、权限和执行入口。

“绝大多数”必须在具体研究中预先给出阈值，不能在结果出现后调整标准。

4.1.7 验证方法

选择一个真实任务集合，记录每个 Task 需要的：

数据来源。
Capability Type。
权限域。
Provider 数量。
专业或合规约束。

比较：

单一 Primary Agent 只使用内建能力。
Primary Agent 使用预设外部 Tool。
Primary Agent 可以从多个外部 Capability Offer 中选择。

主要指标是任务完成率、质量、成本、时延、权限范围和失败恢复能力。

4.1.8 如果命题不成立

白皮书应从“开放 Agent Internet”收缩为特定平台内部的 Orchestration 问题，不再主张独立跨平台 Coordination Layer 是普遍基础设施。

4.2 命题 P2：搜索主体将部分转向 Agent

4.2.1 精确主张

随着可调用 Capability 数量增加，相当一部分发现、筛选和初步选择行为，将由代表个人或组织的 Primary Agent 发起；人类更多负责表达目标、设定约束和批准高风险行动，而不是逐项浏览候选者。

关键词是“部分转向”，不是“人类退出”。不同风险等级的 Task 可能采用不同程度的自动化。

4.2.2 观察依据

MCP 的 Tool 可以由 AI 应用动态发现，并由 Model 根据上下文决定是否调用；官方规范同时强调用户应能看到并拒绝敏感调用。MCP Tools
A2A 的 Agent Card 向 Client Agent 暴露身份、Skill、交互模式和认证要求，Client Agent 可以据此判断候选 Agent 是否适合当前请求。A2A Agent Discovery

这些机制已经允许 Agent 成为发现和选择链路中的参与者，但尚不能证明用户会广泛接受自动委托。

4.2.3 推导

当候选 Capability 很少且风险很高时，人类逐项选择是合理的。当候选数量、调用频率和上下文变量增加时，人工搜索会面临：

难以阅读机器接口和动态限制。
无法持续比较成本、时延与可用性。
难以把分散的个人偏好重复应用到每次选择。
无法在复杂 Task Graph 中为每个 Subtask 手工选取提供者。

Primary Agent 已经持有当前 Task 和部分用户约束，因此更适合完成候选召回、初筛与低风险路由。人类的角色更可能转向设定 Policy、查看理由和处理例外。

4.2.4 当前判断状态

工作假设。 技术接口已经支持 Agent-side Discovery，但采用速度、信任阈值和高风险边界仍然未知。

4.2.5 最强反例

用户可能把 Provider 选择视为品牌和责任决策，坚持亲自完成。
企业采购、合规与安全流程可能要求预批准名单，Agent 没有开放搜索空间。
Agent 的选择理由难以解释，错误选择会迅速破坏信任。
少数超级入口可能把选择隐藏在平台内部，外部看起来仍是面向人的产品。

4.2.6 可证伪条件

如果在候选数量较多、任务重复发生的场景中仍持续出现以下结果，P2 应被缩小：

用户更愿意手工选择，而不是接受 Agent 推荐或自动路由。
Agent 推荐没有降低选择时间或提高完成率。
推荐覆盖率提高时，撤销率、错误率或信任损失同步显著上升。
企业只允许静态 Provider List，动态发现没有实际使用空间。

4.2.7 验证方法

在同一任务集合中比较三种模式：

人工浏览并选择 Provider。
Agent 推荐候选，人类确认。
Agent 在 Policy 范围内自动选择，只对例外请求确认。

观察选择耗时、任务完成率、人工干预率、推荐接受率、撤销率和事后信任。

4.2.8 如果命题不成立

Coordination Layer 仍可能成立，但入口应优先面向人或企业管理员，而不是假设 Machine-first API 会自然成为第一产品形态。

4.3 命题 P3：适配度比绝对能力更重要

4.3.1 精确主张

Provider 的价值不是一个脱离场景的全局强弱排序。协调系统应选择在当前 Task、Context 与 Operating Conditions 下，预期效用最高的 Capability Offer。

可以把选择目标抽象为：

选择结果 = arg max E[Utility | Task, Context, Provider, Conditions]

其中 Utility 至少可能包含：

结果质量。
约束满足程度。
成本与时延。
权限和隐私暴露。
失败概率与恢复能力。
结果可验证性。
Principal 的偏好与风险承受能力。

4.3.2 观察依据

现有协议已经在能力描述中加入适配条件，而不是只给出 Agent 名称。A2A Agent Card 和 Agent Skill 可以声明 Skill、输入输出模式及认证要求；MCP Tool 具有描述和输入 Schema。这些信息的存在说明调用方需要判断“能否适用于当前请求”。

在相邻的 Model Routing 问题中，RouteLLM 根据查询和偏好数据在不同强度、成本的 Model 之间动态路由，并展示了质量与成本之间可以通过条件化选择获得更好平衡。它不是 Agent 路由的直接证据，但证明“始终选择最强模型”并非唯一有效策略。

4.3.3 推导

“最强 Agent”至少存在三个问题：

强弱必须依赖具体能力维度，无法形成单一尺度。
即使质量更高，也可能不满足成本、权限、时延或数据驻留要求。
Provider 的状态会变化，同一个选择在不同时间可能产生不同结果。

因此，Matching 更接近受约束的决策问题，而不是把 Agent 放进一个静态排行榜。

4.3.4 当前判断状态

已收敛的理论判断，等待实证。 这是项目内部已经稳定的 Matching 原则，但尚未在目标场景中证明其收益幅度。

4.3.5 最强反例

某个通用 Provider 可能在质量、价格和便利性上同时占优，情境匹配没有足够收益。
用户可能更看重稳定品牌，而不是每次寻找理论最优解。
获取 Context 和计算适配度的成本可能超过路由收益。
Provider 之间的差异可能无法被可靠观察或预测。

4.3.6 可证伪条件

如果在具有真实差异的候选 Provider 集合上：

全局固定排名与 Context-aware Matching 的任务结果没有显著差异。
Task 和 Context 特征不能预测 Provider 表现。
Context-aware Matching 带来的时延、隐私或复杂度超过质量收益。

则 P3 应从普遍原则缩小为仅适用于高差异、高价值任务的策略。

4.3.7 验证方法

对同一批 Task 和 Provider，比较：

固定选择一个全局最强 Provider。
按静态排行榜选择。
按 Task、约束和 Context 做匹配。

主要指标是任务效用、约束违反率、成本、时延和相对最优选择的 Regret。必须避免用不同任务集合比较不同策略。

4.3.8 如果命题不成立

Matching 可以被简化成稳定 Provider List 或全局排名。Coordination Layer 仍可能处理授权与委托，但“深度理解 Task 和 Context”不再是核心价值。

4.4 命题 P4：Discovery 不足以形成任务闭环

4.4.1 精确主张

对需要外部行动、权限传递或结果验收的 Task，Discovery 只能返回潜在 Capability Offer；它不能单独证明对方值得信任、愿意接受任务、已经获得适当授权、正在执行，或最终结果满足要求。

因此，一个完整但未必全部中心化的协调闭环至少需要：

Discovery → Matching → Trust Assessment → Delegation → Authorization → Execution State → Verification → Feedback

4.4.2 观察依据

A2A 没有在 Agent Card Discovery 处停止。其规范还定义了具有状态和生命周期的 Task、Message、Artifact、取消、流式状态更新和认证授权机制。A2A Specification

MCP 也区分 Tool Discovery 与 Tool Call，并在安全建议中强调用户应能看见和拒绝敏感调用。MCP Tools

这些协议结构说明：知道某个接口“声称能做什么”，与安全地完成一次具体工作不是同一问题。

4.4.3 推导

Discovery 回答的是候选集合问题：

谁声称可能提供这类 Capability？

Task Completion 还需要回答：

候选者是否适合当前约束。
Capability 声明是否可信。
候选者是否愿意接受这次 Task。
Principal 授予了哪些 Context 和权限。
执行过程是否需要补充信息或人工介入。
输出是否满足 Completion Criteria。
失败、取消和争议如何处理。

这些问题可以由不同主体和协议分别完成，但不能因为它们是分布式的，就假设它们不存在。

4.4.4 当前判断状态

已收敛的理论判断，等待实证。 对高风险、长周期和可执行 Task，该命题在逻辑上较强；对低风险、一次性的信息查询，其必要程度可能明显下降。

4.4.5 最强反例

低风险 Tool Call 可能只需要发现 Endpoint、传入参数并获取结果。
Trust、支付、授权和审计可能已经由现有云平台或企业基础设施提供。
Primary Agent 可以自行承担后续协调，不需要独立 Coordination Layer。
增加显式 Delegation 和 Verification 会降低速度并增加交互成本。

最强反例不是“这些步骤不存在”，而是“这些步骤不需要由一个新的独立层统一处理”。

4.4.6 可证伪条件

在目标场景中，如果 Discovery + Direct Call 与完整协调闭环相比：

任务完成率相当。
权限和数据暴露没有显著增加。
失败恢复与审计能力相当。
用户没有更高的不确定感或干预负担。
完整闭环只增加成本，没有带来可观察收益。

则 P4 应缩小到特定高风险、高复杂度任务，不能作为所有 Agent 交互的普遍基础。

4.4.7 验证方法

在同一任务与 Provider 集合上比较：

目录检索后直接调用。
增加 Context-aware Matching。
再增加显式 Task Acceptance、最小授权、状态跟踪和结果验证。

分别测量每增加一层后，完成率、权限暴露、人工介入、失败恢复、可审计性和总成本的变化。这样才能知道真正产生价值的是哪一个环节。

4.4.8 如果命题不成立

这是对白皮书打击最大的结果。项目应退回 Agent Discovery、Capability Registry 或轻量 Router，不再把完整 Coordination Layer 作为核心定位。

4.5 命题 P5：协调层不必拥有全部原始上下文

4.5.1 精确主张

Coordination Layer 可以在不集中保存用户完整画像、长期 Memory 和任务原始数据的前提下，使用由 Primary Agent 生成的结构化 Task 表达、最小必要披露与 Policy-bound Grant，完成有实际价值的 Discovery、Matching 和 Delegation。

该命题不主张“零上下文匹配”。它主张的是 Context 分层与选择性披露，而不是原始数据集中化。

4.5.2 观察依据

A2A 的设计目标之一，是让独立、内部实现可能不透明的 Agent 安全协作，而不要求彼此访问内部状态、Memory 或 Tool。A2A Specification

MCP 把 Host 作为连接与协调多个 Client 的 AI 应用，并保持不同 Server 的连接和安全边界；协议本身只规范 Context Exchange，不规定 Host 必须把全部对话或 Memory 交给 Server。MCP Architecture

这些架构证明“协作不要求共享全部内部状态”在协议上可表达，但不能证明最小披露后的匹配质量足够好。

4.5.3 推导

对于 Capability Matching，协调层可能只需要知道：

Desired Outcome。
必要的任务类别与输入形式。
时间、成本、地域和质量约束。
可接受的数据处理 Policy。
所需权限类型，而非完整凭证。
风险等级和结果验证方式。

更敏感的原始数据可以在 Provider 被选定、Delegation 被接受后，由 Primary Agent 直接向 Provider 披露，或者通过短期、用途受限的 Grant 访问。

如果这种分层成立，Coordination Layer 可以更像控制平面：持有选择和授权所需的最小信息，而不是成为新的数据仓库。

4.5.4 当前判断状态

高风险工作假设。 它决定独立 Coordination Layer 是否能在隐私、信任和平台边界之间成立，也是当前最需要优先验证的命题之一。

4.5.5 最强反例

高质量匹配可能依赖长期行为、隐性偏好和完整任务历史。
Primary Agent 生成的摘要可能丢失决定 Provider 适配度的细节。
Provider 在接受任务前就需要看到原始数据才能报价或判断可行性。
结构化摘要本身可能泄露敏感信息，或者被恶意 Agent 操纵。
如果完整 Context 始终留在 OS 或超级助手内，最优协调功能也可能被它们内建。

4.5.6 可证伪条件

如果在敏感但可评估的目标场景中：

最小 Context 方案的匹配质量显著低于完整 Context。
缺失信息无法通过分阶段澄清或 Provider-specific Disclosure 补足。
为维持质量而披露的信息接近完整原始数据。
用户无法理解或控制 Context 被如何转换和传递。

则“独立且不持有数据的协调层”应被削弱。协调能力可能必须内嵌在 Primary Agent、OS 或企业内部环境中。

4.5.7 验证方法

对同一批 Task 比较三种输入：

只有任务类别，没有个性化 Context。
结构化 Task Summary 与最小 Policy 信息。
完整原始 Context。

比较 Matching Quality、任务完成率、约束满足率、需要追问的次数、信息暴露量和用户可理解度。

验证时必须同时测量质量与隐私，不能只证明摘要方案“能运行”。

4.5.8 如果命题不成立

白皮书仍可主张需要 Coordination，但更可能是一种运行在 Primary Agent 或企业信任域内部的能力，而不是独立中立的网络控制平面。

4.6 命题 P6：真实执行结果能够改善后续协调

4.6.1 精确主张

在控制 Task 类型、Context、运行条件与身份连续性后，可验证的执行结果和委托历史，能够比静态 Capability 声明更准确地估计 Provider 对未来相似 Task 的适配度，并改善后续 Matching、Trust Assessment 和 Routing。

该命题强调的是条件化 Evidence，不是给 Agent 生成一个脱离场景的全局星级。

4.6.2 观察依据

Agent Card、Tool Description 和 Capability Offer 主要表达提供者声明。声明有助于 Discovery，但不能单独证明真实表现。

相邻研究提供了两个线索：

RouteLLM 使用偏好数据学习路由策略，说明历史比较数据可以改善后续模型选择。
P2P 信誉研究中的 EigenTrust 根据历史交易结果形成信任信号，并在其模拟环境中减少了错误内容的选择。

这些结果支持“行为历史可能改善选择”的一般机制，但不能直接证明它会在 Agent Delegation 中形成可靠网络效应。

4.6.3 推导

每一次 Accepted Task 都可能产生以下 Evidence：

是否按时完成。
是否满足 Completion Criteria。
是否发生权限越界或异常请求。
是否需要大量人工修正。
成本和时延是否符合承诺。
失败后是否正确恢复或升级。
结果是否经过自动或人工验证。

当这些记录能够与 Task 类型和运行条件关联时，协调系统就可以校准 Capability Offer，识别“在哪些条件下可信”，而不是只相信 Provider 的静态描述。

4.6.4 当前判断状态

高风险工作假设。 “结果数据有用”相对可信；“它能够跨主体积累为可靠、可防作弊、可迁移的网络资产”仍然非常不确定。

4.6.5 最强反例

许多任务结果难以客观验证。
不同 Task 的难度不同，直接比较完成率会惩罚承担困难工作的 Provider。
反馈可能被刷取、串谋、报复或选择性提交。
Provider 的 Model、Tool 和 Policy 快速变化，旧 Evidence 很快失效。
结果数据可能包含敏感信息，不能跨组织共享。
新 Provider 缺少历史记录，形成进入壁垒。
Primary Agent 的错误 Task 定义可能被错误归因给 Provider。

4.6.6 可证伪条件

如果在控制 Task 难度和 Provider 变化后：

加入历史 Evidence 不能提高留出任务上的选择质量。
Evidence 只在同一用户、同一环境内有效，无法迁移。
防刷取、隐私处理和验证成本高于路由收益。
静态 Capability Offer 已经足以完成可靠选择。

则 P6 应被缩小为局部个性化或审计功能，不能用来解释网络效应和长期护城河。

4.6.7 验证方法

对未来任务做时间顺序留出，比较：

只使用静态 Capability Offer。
加入未经验证的用户反馈。
加入与 Task 条件关联的 Verification Evidence。

评估 Provider 选择准确率、完成率、预期效用 Regret、置信度校准和冷启动表现。另行进行虚假反馈、身份重建和 Provider 版本变化的对抗测试。

4.6.8 如果命题不成立

Coordination Layer 仍可以作为标准、协议或交易控制层存在，但不能把“执行结果数据飞轮”作为核心壁垒，也不应过早使用 Task Completion Network 描述长期价值。

4.7 六个命题之间的依赖

六个命题不是并列口号，而是一条逐步收窄的逻辑链：

P1 说明为什么外部能力选择长期存在。
P2 说明谁更可能发起高频发现和选择。
P3 说明选择的目标不是全局最强，而是当前 Task 下的适配度。
P4 说明从适配度判断到 Task Completion 之间还缺少哪些环节。
P5 说明这些环节能否由不掌握全部原始数据的控制平面完成。
P6 说明完成记录能否反过来改善下一次协调。

可以把它们压缩成三层：

第一层：为什么存在协调需求

P1 + P2 + P3

能力供给分散，发现行为部分机器化，选择目标需要结合 Task 与 Context。

第二层：为什么需要 Coordination Layer

P4 + P5

Discovery 之后仍有 Trust、Delegation、Authorization 和 Verification；这些控制过程可能在不集中原始数据的前提下成立。

第三层：为什么可能形成网络价值

P6

真实执行 Evidence 如果能够改善后续选择，协调层才可能从一次性 Router 演进为 Task Completion Network。

4.8 哪些失败是致命的

命题失败	对项目的影响	可保留的方向
P1 失败	开放跨 Provider 协调需求显著下降	单一平台内部 Orchestration
P2 失败	Machine-first 入口不成立	面向人或企业管理员的选择与治理界面
P3 失败	Context-aware Matching 的价值下降	静态目录、白名单或全局排名
P4 失败	完整 Coordination Layer 的必要性被否定	Agent Discovery、Registry 或轻量 Router
P5 失败	独立中立控制平面难以成立	内嵌于 Primary Agent、OS 或企业内部的协调能力
P6 失败	数据飞轮和 Task Completion Network 叙事失效	标准、协议、授权与审计基础设施

其中：

P4 是“为什么不是只做 Discovery”的核心命题。
P5 是“为什么可以成为独立控制平面”的核心命题。
P6 是“为什么可能形成长期网络价值”的核心命题。
P2 影响入口与采用顺序，但单独失败不会否定协调问题本身。

4.9 推荐验证顺序

验证顺序不应按照命题编号，而应按照“重要性 × 不确定性 × 可验证性”安排。

第一优先：联合验证 P3 与 P4

选择一个具有多个 Provider、真实约束和可验证结果的场景，比较：

静态目录或固定 Provider。
Context-aware Matching。
Matching 加显式 Delegation、状态和 Verification。

这一步可以直接回答：项目究竟是 Discovery、Routing，还是 Coordination 问题。

第二优先：验证 P5

在同一场景比较无 Context、结构化最小 Context 和完整 Context，测量匹配收益与信息暴露。

这一步决定 Coordination Layer 应位于开放网络、Primary Agent 内部，还是企业信任域内部。

第三优先：验证 P6

积累一定数量的重复 Task 后，测试 Verification Evidence 是否提高下一轮选择质量。没有足够真实执行记录前，不应提前宣称数据飞轮。

第四优先：观察 P2

通过用户行为比较推荐、确认和自动选择三种模式。P2 更适合随原型使用自然观察，不必在最初单独建设完整面向 Agent 的入口。

持续研究：P1

P1 很难通过一次产品实验验证，需要持续绘制目标场景中的 Capability、数据和权限分布，并观察集中化趋势。

4.10 本章结论

观察

当前 Agent 与 Tool 协议已经包含能力发现、动态调用、Task 生命周期、认证授权和结果返回等对象。这证明协调问题正在被不同技术层分别处理，但不能证明市场一定需要一个新的独立平台。

推导

如果能力持续分散，Agent 开始代表 Principal 选择外部能力，并且任务适配、委托与结果验证不能被简单 Discovery 取代，那么 Coordination Layer 才成为一个独立且有意义的问题。

已收敛结论

“寻找最强 Agent”应改写为“在当前 Task、Context 与约束下寻找最适合的 Capability Offer”。
Discovery 与 Task Completion 不是同一个阶段。
P1–P6 不能作为同等确定的六条事实对外表达。

工作假设

独立协调层可以在不持有全部原始 Context 的情况下保持足够匹配质量。
可验证执行 Evidence 能够改善后续协调并形成持续价值。

风险 / 反例

如果完整 Context 必须留在 OS、超级助手或企业平台内部，或者执行 Evidence 无法可靠验证与迁移，那么 Coordination 仍然存在，但独立开放的 Coordination Layer 和 Task Completion Network 都可能不成立。

本章后的核心问题

第 5 章不应再泛泛论述“Discovery 不够”，而应具体拆解 P4：哪些 Task 必须经过 Trust、Delegation、Authorization 和 Verification，哪些低风险调用可以停留在 Discovery + Direct Call。

本章参考锚点

A2A Protocol Specification。用于观察异构 Agent 互操作、Agent Card、Task 生命周期、认证授权与结果对象。
A2A Agent Discovery。用于观察 Client Agent 如何利用 Agent Card 判断候选适配性。
Model Context Protocol: Architecture Overview。用于观察一个 Host 连接多个能力 Server，以及 Context Exchange 的协议边界。
Model Context Protocol: Tools。用于观察 Tool Discovery、Model-controlled Invocation 与 Human-in-the-loop 安全要求。
Isaac Ong 等，RouteLLM: Learning to Route LLMs with Preference Data。作为 Task-conditioned Routing 与质量—成本权衡的相邻研究证据。
Sepandar Kamvar、Mario Schlosser、Hector Garcia-Molina，The EigenTrust Algorithm for Reputation Management in P2P Networks。作为历史交易 Evidence 改善开放网络选择的相邻研究证据。

第三部分：为什么需要 Coordination Layer

第 5 章：Discovery Is Not Enough

5.0 本章要回答的问题

为什么一个可机器搜索的 Agent Directory、Capability Registry 或 Agent Card Network，仍然不足以支持开放任务完成？

核心原因是：

Discovery 只能找到“可能能做”的候选者；Task Completion 还需要证明“适合做、愿意做、有权做、正在做，以及确实做完”。

这不意味着每次调用都要经过复杂流程。低风险、确定性强的 Tool Call 可以非常轻量。问题在于，不能把这种简单路径外推到所有跨主体 Task。

5.1 Discovery 的正确边界

Discovery 至少可以完成三件事：

找到可能满足 Capability Requirements 的 Provider。
获取 Capability Offer、接口、输入输出和认证要求。
形成可供后续 Matching 的候选集合。

A2A 使用 Agent Card 描述身份、接口、Skill 和认证要求；MCP 使用 tools/list 等方法暴露可调用 Tool。它们都让能力可以被机器发现。A2A Agent Discovery MCP Architecture

Discovery 通常不能单独回答：

Capability 声明是否真实。
Provider 当前是否可用。
它是否愿意接受这次具体 Task。
需要披露什么 Context。
Principal 是否授权这次行动。
结果是否符合 Completion Criteria。
失败、撤销和争议由谁处理。

暂定结论

Discovery 的产物是 Candidate Set，不是 Task Commitment，更不是 Verified Outcome。

5.2 三个容易被混淆的对象

Capability Claim

Provider 声称能够完成某类工作。它适合召回候选，但属于自我描述。

Capability Evidence

测试、认证、历史 Task 或第三方验证表明 Provider 曾在特定条件下完成类似工作。

Task Commitment

Provider 接受一次具体 Task，并确认目标、约束、时间、权限和结果边界。

三者之间不能自动推导：

声称能做，不等于已经被证明能做。
曾经能做，不等于当前条件下仍能做。
当前能做，不等于愿意接受这次 Task。
接受 Task，不等于最终已经完成。

一个只记录 Capability Claim 的 Agent Registry，最多解决网络的可见性问题。

5.3 Discovery 之后的七个缺口

5.3.1 Matching Gap

候选者可能都声明相同 Capability，但在成本、时延、数据 Policy、地域、语言和可验证性上不同。系统需要结合当前 Task 计算适配度。

5.3.2 Trust Gap

Provider Identity、Capability Evidence 和历史行为是否足够可信？一个签名正确的 Agent Card 只能证明 Card 来自某个密钥，不自动证明能力声明真实。

5.3.3 Commitment Gap

Provider 是否接受当前 Task？接受后是否确认了交付时间、输出和限制？这是从 Candidate 到 Delegatee 的边界。

5.3.4 Authorization Gap

即使 Provider 值得信任，Principal 是否授权它访问特定数据、调用特定服务或产生外部承诺？认证成功不等于被授权完成任意动作。

5.3.5 Execution Gap

长周期 Task 需要状态、进度、补充输入、重试、取消和超时。一次 RPC 成功返回不能覆盖这些状态。

5.3.6 Verification Gap

Artifact 已产生不等于 Desired Outcome 已实现。系统需要根据 Completion Criteria 判断结果是否可接受。

5.3.7 Accountability Gap

失败来自 Task 定义、Matching、Context、授权还是执行？如果没有 Delegation Record 与 Evidence，问题只能被粗略归为“Agent 不好用”。

5.4 不同风险等级需要不同闭环

并非所有 Task 都需要同样重的 Coordination。可以按行动风险粗分五级。

等级	示例	最小机制
L0 公共信息	查询公开天气、读取公开文档	Discovery + Direct Call
L1 可逆低风险	生成草稿、创建本地临时文件	Matching + 基本日志
L2 敏感数据	读取企业文档、分析个人记录	身份、最小授权、数据 Policy、审计
L3 外部承诺	发消息、预订、付款、修改生产系统	显式 Delegation、确认、状态、撤销与 Verification
L4 高影响或受监管	医疗、法律、信贷、关键基础设施	专业资质、强验证、人工负责、合规与完整审计

这张表是风险分析框架，不是正式行业标准。目标是说明：

P4 对 L2–L4 更强。
对 L0–L1，完整闭环可能得不偿失。
Coordination Layer 应按风险渐进增加控制，而不是让所有 Task 走同一套繁重流程。

5.5 “已有基础设施会处理后续步骤”的反方观点

一个有力反对意见是：

身份、授权、支付、日志和工作流已经分别存在，为什么需要新的 Coordination Layer？

这个反对意见部分成立。Coordination Layer 不应该重新发明成熟基础设施：

身份可使用现有企业 IAM、OAuth、证书或可验证凭证。
授权可使用现有 Scope、Policy Engine 和短期 Token。
支付可以由现有支付网络处理。
工作流和状态可以由现有 Task 系统承载。
审计可以进入现有日志与合规平台。

新的问题不是替代这些系统，而是让一次跨 Agent Task 能够引用、组合并协调它们：

哪个身份代表哪个 Principal。
哪项 Capability 与哪个授权关联。
某个 Grant 只允许完成哪个 Task。
哪个 Artifact 对应哪个 Completion Criteria。
哪些 Evidence 可以用于后续 Trust。

已收敛表述

Coordination Layer 更像跨系统的控制语义和状态连接，不应默认成为所有基础设施的重新实现。

5.6 Coordination 不等于中心化

P4 只说明完整 Task 存在多个必要环节，不说明它们必须由一个平台统一持有。

可能的分工是：

Primary Agent 完成 Task Formation 和用户交互。
Discovery Service 返回 Capability Offer。
Trust Service 提供身份与 Evidence。
Authorization Server 颁发最小 Grant。
Provider Agent 维护执行状态。
Verifier 检查 Artifact。
Coordination Layer 只关联状态和证据引用。

因此，“需要协调层”和“需要一个掌握全部数据的中心平台”是两个不同命题。P5 专门检验后者是否可以避免。

5.7 一个 Discovery-only 流程如何失败

继续使用商务出行案例：

Primary Agent 搜索到三个“差旅 Agent”。
目录按评分返回排名最高者。
Primary Agent 把完整护照、日历和支付信息发送给它。
Provider 给出一个价格合理的行程并直接预订。

这个流程表面上高效，却留下多个未回答问题：

排名是否适用于当前国家、公司 Policy 和签证状态？
Provider 是否需要看到完整护照才能初步匹配？
用户是否允许它直接付款？
如果价格在执行中变化，最大可接受差额是多少？
预订失败后是否可以换 Provider？
输出是建议、预留还是已出票？
退款和改签由谁跟进？

Discovery 找到了候选者，但没有建立安全、可判定的任务关系。

5.8 最强反例与适用边界

反例 1：Tool Schema 已经是契约

对确定性、即时返回的 Tool 可能成立。但 Tool Schema 通常不包含任务接受、长周期状态、结果责任和争议处理。

反例 2：Primary Agent 可以自己协调

成立。这会削弱独立平台机会，却不否定 Coordination 作为功能。白皮书必须区分“问题存在”和“谁提供这项能力”。

反例 3：用户只使用可信白名单

白名单可以降低 Discovery 和 Trust 成本，但仍可能需要 Task-specific Authorization、状态和 Verification。

反例 4：完整流程太慢

成立。系统需要根据风险自动选择轻量或完整路径。若 L0 Task 也必须显式签署 Delegation Contract，设计就已经失败。

5.9 可证伪条件

如果在目标场景中，Discovery + Direct Call 与加入 Matching、Delegation、Authorization 和 Verification 的流程相比：

完成率相当。
权限暴露相当。
错误和争议相当。
恢复与撤销能力相当。
用户理解和信任相当。
完整流程只增加成本和时延。

那么 P4 应被缩小到少数高风险任务，项目也应收缩为 Discovery 或 Routing。

5.10 本章结论

观察

现有协议同时设计 Discovery、Task State、Tool Call、认证和结果对象，说明能力可见性与任务完成属于不同问题。

推导

从 Capability Claim 到 Verified Outcome 之间至少存在 Matching、Trust、Commitment、Authorization、Execution、Verification 和 Accountability 七个缺口。

已收敛结论

Discovery 是协调闭环的入口，不是闭环本身。

工作假设

对 L2–L4 风险任务，补齐这些缺口会显著提高完成率、安全性或可追责性。

风险 / 反例

如果这些功能已被 Primary Agent 或封闭平台低成本内建，独立 Coordination Layer 仍可能没有产品位置。

第 6 章：协调闭环

6.0 本章要回答的问题

如果 Discovery 不是完整答案，那么一次最小但可追踪的跨 Agent 协调究竟包含哪些阶段？

本章提出一个参考闭环：

Intent → Task Formation → Context Boundary → Discovery → Matching → Trust → Proposal → Delegation → Authorization → Execution → Verification → Feedback

这不是要求所有 Task 都经过十二个显式页面或网络调用。多个阶段可以由同一个系统合并完成，低风险 Task 也可以跳过部分步骤。模型的作用是确保关键问题有人负责，而不是制造流程。

6.0.1 核心关系图

图中的回路只有在 P6 成立时才会产生持续学习价值；否则 Evidence 主要用于当前 Task 的审计与解释。

6.1 阶段 0：选择协调强度

Primary Agent 首先根据 Task 风险决定使用哪种路径：

Direct Call：公开信息或确定性低风险 Tool。
Managed Call：需要 Provider Matching、日志或可逆写入。
Delegated Task：需要敏感 Context、外部承诺或持续状态。
High-assurance Task：需要专业资质、人工批准或完整审计。

这个阶段避免对所有调用施加相同成本。

输出

风险等级。
需要的控制步骤。
必须由人确认的 Gate。

6.2 阶段 1：Task Formation

Primary Agent 把 Principal 的 Intent 转化为初始 Task Request。

至少需要逐步形成：

Desired Outcome。
已知 Context。
硬约束与软偏好。
Completion Criteria。
时间和预算。
可接受风险。
可自动执行与必须确认的边界。

失败模式

Intent 被错误理解。
成功标准缺失。
把偏好误当成硬约束。
Task 范围过大，无法由一个 Provider 接受。

输出

Task Request v0

6.3 阶段 2：Context Boundary

Primary Agent 判断哪些信息用于：

候选召回。
初步 Matching。
Provider 接受 Task 前的可行性判断。
接受后实际执行。

四个阶段不应默认获得相同 Context。

Context 分层

层级	内容	典型接收者
Public Task Summary	去标识化目标与约束	Discovery / Matching Service
Selective Attributes	地域、资格、Policy 等必要属性	候选 Provider
Execution Context	完成任务所需原始数据	已接受委托的 Provider
Restricted Secret	凭证、支付或高敏感数据	目标 Resource，通过受限 Grant 访问

原则

先比较所需属性，再传递原始数据。
先确定 Provider，再扩大披露范围。
能引用就不复制，能短期授权就不长期保存。

输出

Task Summary。
Disclosure Policy。
需要的 Grant 类型。

6.4 阶段 3：Capability Discovery

Discovery 使用 Capability Requirements 找到候选 Offer。

可能的来源包括：

已配置 Provider List。
企业内部 Registry。
A2A Agent Card。
MCP Tool Registry。
行业目录或开放搜索。
Primary Agent 的历史关系。

输出

Candidate Set

每个候选至少应关联：

Provider Identity。
Capability Offer。
交互端点。
输入输出模式。
认证与授权要求。
适用范围与限制。
Evidence 引用。

6.5 阶段 4：Matching and Routing

Matching 计算候选者对当前 Task 的条件化适配度。它不是对 Provider 的永久评价。

主要输入

Task Requirements。
可披露 Context。
Principal Policy。
Capability Offer。
Provider 当前状态。
Capability Evidence。

主要输出

候选排序或选择。
选择理由。
关键不确定性。
需要进一步询问的内容。
备选 Provider 与降级策略。

要求

选择理由应能指出决定结果的约束，例如“支持企业协议价且数据驻留符合 Policy”，而不是只返回无法解释的总分。

6.6 阶段 5：Trust Assessment

Trust Assessment 判断当前 Provider 是否足以承担当前风险等级的 Task。

它应分别检查：

Identity 是否可信。
Capability Evidence 是否相关。
Security / Data Policy 是否符合要求。
历史行为是否在相似条件下可靠。
当前 Task 是否需要人工或第三方担保。

输出

Trust Decision：允许、限制、请求额外证据或拒绝。
决策所依赖的 Evidence。
仍未解决的风险。

6.7 阶段 6：Proposal 与协商

Primary Agent 向候选 Provider 发送 Task Request。Provider 可以：

接受。
拒绝。
请求补充信息。
提出修改后的范围、价格、时限或权限要求。
建议拆分 Task。

为什么需要 Proposal

Capability Offer 面向一类任务，Proposal 面向这一次具体 Task。它把静态声明转化为可接受或拒绝的具体承诺。

输出

Task Proposal

至少包含：

Task 版本。
Provider。
预期 Artifact。
成本与时间。
所需 Context 和权限。
假设与排除项。
取消与失败条件。

6.8 阶段 7：Delegation 与 Task Acceptance

当 Principal 或 Primary Agent 在授权范围内接受 Proposal，Provider 同意承担工作时，Task Request 转化为 Accepted Task。

Delegation 应明确：

谁委托谁。
委托哪个 Task 版本。
允许采取哪些行动。
是否允许继续 Subdelegation。
哪些步骤必须请求确认。
何时到期或可撤销。
什么结果构成完成。

输出

Delegation Record

Delegation Record 是控制平面记录，不必包含全部原始数据。

6.9 阶段 8：Authorization

Delegation 表达“允许完成什么 Task”，Authorization 则把其中一部分权限落实为可执行的技术 Grant。

可能使用：

短期 Access Token。
受目标 Resource 限制的 Token。
单次操作确认。
企业 Policy 决策。
临时数据访问链接。
Sandbox 或受限账户。

RFC 8707 允许 OAuth 客户端指明目标 Resource；RFC 8693 描述 Token Exchange 和 Actor Delegation；RFC 9700 则强调限制 Access Token 权限与防止 Token 重放。它们可以承载部分授权机制，但不自动表达完整 Task 语义。

原则

最小权限。
最短必要时限。
绑定目标 Resource 和行动类型。
可撤销或自然过期。
Delegation 与实际 Grant 可追溯关联。

输出

Context Grant / Action Grant

6.10 阶段 9：Execution and Coordination

Provider 执行 Accepted Task，并对外暴露必要状态。

概念状态模型

状态	含义
`SUBMITTED`	Task 已提交但未开始
`WORKING`	正在执行
`INPUT_REQUIRED`	需要补充信息或确认
`AUTH_REQUIRED`	需要新的认证或授权
`PAUSED`	因 Policy、依赖或外部条件暂停
`VERIFYING`	已产生结果，等待验收
`COMPLETED`	Completion Criteria 已满足
`FAILED`	无法完成
`CANCELED`	被授权主体取消
`REJECTED`	Provider 拒绝承担或继续 Task
`DISPUTED`	对完成状态或责任存在争议

A2A 已定义 Submitted、Working、Input Required、Auth Required、Completed、Failed、Canceled 和 Rejected 等 Task 状态。本章增加的状态只用于白皮书分析，不声称属于 A2A 标准。A2A Specification

Execution 期间的协调事件

进度更新。
Context 请求。
价格或范围变化。
Subdelegation 请求。
超时和重试。
Provider 切换。
人工升级。

6.11 阶段 10：Verification

Verification 比较实际 Result 与 Completion Criteria。

四种验证方式

确定性验证：Schema、单元测试、签名、余额或状态查询。
规则验证：Policy、预算、格式、合规检查。
模型或 Agent 验证：对开放文本、计划或分析做质量判断。
人工或专业验证：对高影响、主观或受监管结果负责。

验证输出

Accepted。
Needs Revision。
Rejected。
Partially Completed。
Escalated。

关键边界

Provider 不能仅凭自己的成功状态证明 Task 完成。高风险 Task 需要独立 Evidence 或由 Principal 认可。

6.12 阶段 11：Feedback and Memory

任务结束后，系统可以保存：

Task 类型与约束摘要。
Provider 与 Capability 版本。
Delegation 和 Grant 引用。
结果状态与 Verification Evidence。
成本、时延和人工介入。
失败原因和恢复路径。

不应默认保存：

完整原始用户数据。
与后续协调无关的私人 Context。
可被简化为 Evidence 引用的完整 Artifact。

输出

Capability Evidence 更新。
关系级偏好或黑白名单。
审计记录。
对下一次 Matching 的可用信号。

P6 是否成立，取决于这些信号能否在控制偏差和攻击后真正改善未来选择。

6.13 控制平面与数据平面

控制平面可能保存

Task ID 与状态。
Agent / Provider Identity。
Capability Offer 引用。
Proposal 与 Delegation Record。
Grant 引用和有效期。
Result 与 Evidence 引用。

数据平面可能保存

原始文档、邮件、音视频。
凭证与敏感记录。
实际业务系统状态。
大体积执行 Artifact。

暂定原则

Coordination Layer 应优先保存控制关系与可验证引用，让原始数据停留在 Principal、Provider 或专门的数据系统中。该原则仍需由 P5 验证。

6.14 异常路径

完整闭环必须设计异常，而不是只设计成功路径。

Provider 拒绝

返回可解释原因，选择备选 Provider，避免泄露额外 Context。

需要更多权限

暂停 Task，展示新增权限与原因；不能静默扩大 Grant。

Subdelegation

检查是否允许、Context 能否继续传递，以及上层 Provider 是否仍承担结果责任。

超时或失联

触发取消、回收 Grant、切换 Provider 或人工接管。

结果不合格

进入修正、部分接受、退款、争议或重新委托。

Principal 撤销

停止后续动作、回收未使用权限，并记录已产生的不可逆结果。

6.15 最小可验证闭环

首个原型不需要实现所有阶段。验证 P3、P4、P5 的最小闭环可以是：

接收一个结构化 Task Summary。
从多个 Capability Offer 中返回候选与理由。
由人确认 Provider。
生成一个明确的 Delegation Record。
使用最小 Context 执行。
根据预定义规则验证 Result。
记录结构化 Evidence。

暂时可以不实现开放注册、全球身份、支付结算或复杂信誉系统。

6.16 本章结论

观察

一次跨主体 Task 从 Intent 到 Verified Outcome 会经历多个状态和授权边界。

推导

Coordination Layer 的价值不在替代所有系统，而在让 Task、Provider、Delegation、Grant、Result 和 Evidence 形成可追踪关系。

暂定结论

完整协调闭环包含十二个概念阶段，但应按风险压缩为不同执行路径。

工作假设

控制平面可以只保存关系、状态和 Evidence 引用，而不集中保存全部数据。

风险 / 反例

如果状态和授权语义无法跨 Provider 互操作，或者协调开销超过失败成本，闭环只能在封闭平台或少数高价值场景中成立。

第 7 章：Trust 与 Delegation

7.0 本章要回答的问题

Agent 为什么敢把 Task、Context、权限或资源交给另一个陌生主体？

仅靠 Capability Discovery 无法回答这个问题。开放协作需要同时建立两种关系：

Trust：基于当前证据，是否有理由相信对方能在特定条件下可靠行动。
Delegation：在明确边界内，把完成某个 Task 的行动权授予对方。

Trust 是判断，Delegation 是受约束的授权与责任关系。信任某个 Provider，不等于允许它采取任意行动；授予权限，也不等于它值得被信任。

7.1 Trust 不是什么

Trust 不等于 Authentication

Authentication 证明交互方控制某个身份或凭证。它不能证明其 Capability 声明真实，也不能证明它适合当前 Task。

Trust 不等于 Authorization

Authorization 决定某个身份能做什么。系统可能向一个不熟悉的 Provider 授予极小、可撤销的权限，也可能拒绝向高度可信的 Provider 授予超出 Task 的权限。

Trust 不等于 Reputation

Reputation 是来自历史行为或第三方评价的信号，只是 Trust Decision 的输入之一。

Trust 不等于 Popularity

调用量、收藏量和品牌知名度不能直接证明特定 Capability 在当前条件下可靠。

Trust 不等于法律责任

技术系统可以记录身份、授权和行为归属，但最终法律责任仍由合同、监管和具体主体关系决定。

7.2 Trust 的五个维度

7.2.1 Identity Trust

我们是否知道正在与谁交互？

身份是否稳定。
由谁运营。
凭证是否有效。
域名、密钥或组织关系是否可验证。
身份是否发生版本或所有权变化。

7.2.2 Capability Trust

它是否真的能够完成声明的工作？

Capability Offer 是否具体。
是否有相关测试或认证。
是否在类似 Task 中成功。
能力版本是否与 Evidence 对应。

7.2.3 Behavioral Trust

它是否遵守约束和授权边界？

是否最小化数据使用。
是否未经允许继续委托。
是否在需要时请求确认。
是否如实报告失败和不确定性。

7.2.4 Outcome Trust

它产生的 Result 是否达到 Completion Criteria？

质量。
时效。
成本。
可验证性。
失败恢复。

7.2.5 Contextual Trust

以上信号是否适用于当前 Task、地区、数据、风险等级和运行条件？

一个擅长公开资料总结的 Agent，不因此值得读取公司机密；一个在英语合同上表现良好的 Provider，不因此适合处理另一司法辖区的法律工作。

7.3 Trust 的正确对象

本文不建议给 Agent 一个永久、全局的单一分数。更合理的表达是：

Trust Decision = f(Provider, Capability, Task Context, Evidence, Conditions, Principal Policy)

这意味着：

Trust 是关系性的，不是 Provider 单方面拥有的属性。
Trust 是条件性的，不是脱离环境的总分。
Trust 是随时间变化的，不是一次认证后永久有效。
Trust 可以通过限制权限来补偿证据不足。

示例

同一个旅行 Agent 可能：

被允许搜索公开航班。
被允许读取去标识化的偏好摘要。
需要确认后才能查看护照信息。
需要再次确认后才能支付。
永远不被允许把支付凭证继续委托给其他 Agent。

信任不是二元开关，而是不同 Task 阶段下的授权强度。

7.4 Evidence 分层

Trust Decision 可以使用不同强度的 Evidence。

层级	Evidence	局限
E0 自我声明	Capability Offer、Agent Card	可发现，但尚未验证
E1 身份与来源	签名、域名、组织声明	证明来源，不证明能力
E2 可复现测试	Benchmark、测试任务、Schema 验证	可能脱离真实环境
E3 第三方证明	审计、资质、认证、担保	依赖签发者可信度和时效
E4 历史执行	相似 Task 的 Verified Outcome	受选择偏差、版本变化影响
E5 关系经验	当前 Principal 与 Provider 的历史	准确但难以迁移和共享

W3C Verifiable Credentials Data Model v2.0 提供了 Issuer、Holder 与 Verifier 之间表达可验证声明的一般数据模型。它可以承载身份或资质 Evidence，但不会自动决定签发者是否值得信任，也不会替 Coordination Layer 做 Capability Matching。

原则

高风险 Task 应要求更强、更新且更相关的 Evidence；不能用大量低质量评分替代关键资质或直接验证。

7.5 Reputation 的局限

开放信誉系统面临至少六类问题：

Sybil Attack：创建大量新身份相互评分。
Collusion：多个主体串谋抬高信誉。
Selection Bias：只接受容易 Task 的 Provider 看起来更优秀。
Context Collapse：把不同难度、地区和权限条件下的结果混在一起。
Version Drift：Model、Tool 和 Policy 更新后，旧记录不再代表当前能力。
Retaliation / Manipulation：评分被报复、诱导或选择性提交。

EigenTrust 等 P2P 研究说明历史交易可以形成有用信号，也同时表明开放信誉必须专门处理恶意身份与串谋。EigenTrust

暂定结论

P6 不应被简化为“收集评分就会形成壁垒”。真正有价值的是与 Task 条件关联、可验证且能处理攻击的 Evidence。

7.6 Delegation 的正式定义

Delegation 是一个 Principal 或其获授权 Agent，把完成特定 Task 所需的有限行动权，在明确范围、期限、条件和可追溯关系下授予另一个 Agent 或 Provider。

Delegation 至少包含三个不同对象：

Task Commitment：对方接受完成什么。
Authority Grant：对方被允许做什么。
Accountability Record：谁在何种授权链下采取了行动。

三者必须能够关联，但不必由同一系统存储。

7.7 Delegation Contract 的最小字段

本文所称 Delegation Contract 是概念性任务契约，不等同于法律合同。它至少需要表达：

Parties

Root Principal。
Immediate Principal / Delegator。
Delegatee / Provider。
必要时的 Verifier 或 Guarantor。

Task

Task ID 与版本。
Desired Outcome。
Input 和已知假设。
Completion Criteria。

Authority

允许的行动。
目标 Resource。
可使用的数据与 Context。
最大成本、数量或频率。
是否允许 Subdelegation。

Lifecycle

生效时间与到期时间。
状态更新要求。
暂停、取消和撤销方式。
需要重新确认的变化条件。

Result

预期 Artifact。
Verification 方法。
失败、部分完成与争议路径。

Provenance

Delegation 由谁签发或确认。
关联的 Capability Offer 与版本。
关联的 Grant 与 Evidence 引用。

7.8 Delegation 与 Impersonation

这两个概念必须区分：

Impersonation：被授权主体以 Principal 的身份行动，外部系统主要看到 Principal。
Delegation：被授权主体以自己的身份行动，同时表明它代表哪个 Principal 以及授权链条。

开放 Agent 协作更应偏向可追溯 Delegation，因为它保留 Actor Identity，便于限制权限和归因。

RFC 8693 的 Token Exchange 区分相关语义，并可通过 Actor Claim 表达当前与先前 Actor。它提供了技术积木，但完整 Agent Delegation 仍需额外绑定 Task、Capability 和 Completion Criteria。

7.9 最小授权原则

一个安全 Delegation 不应把 Primary Agent 或用户的完整权限复制给 Provider。

约束维度

Audience / Resource：Token 只能用于特定服务。
Scope / Action：只能执行指定动作。
Time：短期有效，Task 结束后失效。
Amount：限制费用、次数或资源量。
Context：只访问完成 Task 所需数据。
Actor：绑定特定 Provider 或运行实例。
Confirmation：高影响动作需要新的用户确认。

RFC 9700 强调限制 Access Token 权限、保护 Token 并防止重放；这些原则同样适用于 Agent，但 Agent 的动态调用和 Subdelegation 会扩大攻击面。

工作假设

现有授权标准可以承载大部分底层 Grant，Coordination Layer 主要补充 Task-level 语义和委托关系，而不是重新发明认证系统。

7.10 Subdelegation

一个 Provider Agent 可能需要把 Subtask 再委托给第三方。

Subdelegation 必须回答：

原始 Delegation 是否允许继续委托。
哪些 Context 可以向下传递。
下游 Provider 获得哪些新 Grant。
上游 Provider 是否仍承担最终 Result 责任。
Principal 是否需要看到或批准下游主体。
撤销上游 Task 时，如何级联撤销下游 Grant。

非传递原则

对 Provider A 的 Trust 不应自动传递给 A 选择的 Provider B；授予 A 的权限也不应默认完整传给 B。

风险

如果 Subdelegation 链不可见，Primary Agent 可能以为数据只交给一个 Provider，实际却经过多个主体。

7.11 Trust 与 Delegation 的联合决策

高 Trust 不必对应大权限，低 Trust 也不一定意味着完全不能使用。

Trust / Evidence	Task 风险	合理决策示例
低	低	Sandbox 中试运行，限制数据和动作
低	高	拒绝或要求强担保、人工审核
高	低	自动委托，保留基本日志
高	高	仍使用最小权限、确认和独立 Verification

安全设计的目标不是“找到绝对可信的 Agent”，而是让 Evidence、风险和授权强度相匹配。

7.12 攻击与失败模型

身份替换

合法 Agent Card 或域名被接管，旧 Reputation 被新运营者继承。

Capability 夸大

Provider 用模糊描述进入更多候选集合，但真实结果不稳定。

Context Extraction

Provider 通过不必要的澄清请求收集更多敏感数据。

Authority Escalation

Agent 请求超出 Task 所需的 Scope，或把短期权限转化为长期访问。

Prompt / Instruction Injection

外部数据诱导 Primary Agent 或 Provider 忽略 Delegation Policy。

Hidden Subdelegation

Provider 未经允许把 Task 和 Context 交给下游主体。

False Completion

Provider 报告成功，但 Artifact 未满足 Completion Criteria。

Evidence Poisoning

虚假任务、串谋评价或选择性上报污染后续 Trust。

责任模糊

Task 定义、授权和执行记录不完整，失败后无法判断哪个环节负责。

7.13 人类在环中的位置

Human-in-the-loop 不应被设计成每一步都弹窗，而应位于风险变化点：

Task 从建议升级为外部行动。
新增敏感 Context。
新增 Provider 或 Subdelegatee。
权限、价格或范围超出原批准条件。
Result 难以自动验证。
Task 进入争议或高影响状态。

Primary Agent 的职责之一，是把复杂授权压缩成少量可理解决策，而不是把每个 API Scope 原样抛给用户。

7.14 本章结论

观察

身份、能力、行为、结果和上下文可信度是不同问题；认证和评分都不能单独回答“是否应委托当前 Task”。

推导

Trust 必须条件化到 Provider、Capability、Task 和运行条件；Delegation 必须绑定 Task、权限、期限与结果标准。

暂定结论

Trust 是基于 Evidence 的风险判断。
Delegation 是有限行动权的可追溯授予。
Authorization 是 Delegation 的技术落实，但不等于完整 Delegation。
Reputation 只能作为 Evidence，不能成为脱离 Context 的全局真相。

工作假设

现有身份和授权标准，加上 Task-level Delegation Record，可以支撑最小开放协调。

风险 / 反例

如果身份不能稳定、结果不能验证、Subdelegation 无法控制，或者授权语义不能跨域互认，开放 Trust 与 Delegation 只会在封闭信任网络中成立。

第四部分：系统与网络模型

第 8 章：Coordination Layer 参考模型

8.0 本章要回答的问题

如果 Coordination Layer 成立，它最少需要连接哪些角色、对象和状态？哪些事情属于协调层，哪些必须留在执行系统和数据所有者一侧？

本章提出的参考模型遵循三个原则：

先表达跨主体语义，再选择具体协议。
先定义控制平面，再决定是否托管数据平面。
允许中心化、联邦化和点对点实现，不预设唯一平台形态。

8.1 参考模型的目标与非目标

目标

让 Task、Capability、Agent 与 Principal 可以被区分和关联。
让 Capability Offer 可被发现、比较和验证。
让一次 Delegation 的范围和授权链可追踪。
让执行状态、Result 和 Evidence 可以回到原 Task。
让敏感数据尽可能留在现有信任域。

非目标

不定义一个全球唯一 Agent Registry。
不要求所有 Agent 使用相同内部架构。
不替代 OAuth、企业 IAM、支付或工作流系统。
不要求协调层托管所有原始数据和 Artifact。
不在本版定义完整网络协议、商业结算或治理制度。

8.2 参与者

Principal

提出目标、提供授权并承受主要收益与风险的人或组织。

Primary Agent

代表 Principal 完成 Task Formation、Policy 应用、Provider 选择与用户交互。

Provider Agent

接受 Delegation，并在约束内选择行动、使用 Capability 或继续拆分 Subtask。

Capability Provider

提供 Tool、Service、数据、专业能力或现实履约。它可以与 Provider Agent 是同一主体，也可以只是被 Agent 调用的服务。

Discovery Service

索引或解析 Capability Offer，返回候选集合。可能是本地配置、企业 Registry、开放目录或分布式发现机制。

Trust / Evidence Service

提供身份声明、资质、历史 Result、验证记录或风险信号。它不应自动拥有最终 Trust Decision。

Authorization Service

根据 Principal Policy 和 Delegation 生成、限制或撤销技术 Grant。

Verifier

根据 Completion Criteria 检查 Result。可以是规则、测试系统、另一个 Agent、第三方机构或人类。

Coordinator

关联 Task、候选、Proposal、Delegation、Grant、状态和 Evidence。Coordinator 可以由 Primary Agent、企业平台、独立服务或多个协议组件共同实现。

角色重叠

参考模型中的角色是责任划分，不是部署数量。一个 Primary Agent 可以同时承担 Coordinator 和 Verifier；一个企业平台也可以同时提供 Discovery、Authorization 与审计。

8.3 核心对象

Agent Identity

用于区分行为主体和运营者，至少包含：

Identity ID。
运营或签发主体。
可验证凭证或端点。
当前版本和状态。
支持的交互方式。

Capability Type

与 Provider 无关的抽象结果能力，用于表达 Task Requirement。

Capability Offer

Provider 对某个 Capability Type 的具体供给声明，包含条件、限制、接口、Policy 与 Evidence 引用。

Task Request

尚未被 Provider 接受的工作请求，包含 Outcome、Context Summary、约束、风险和 Completion Criteria。

Task Proposal

Provider 针对 Task Request 给出的具体范围、成本、时限、权限需求和交付承诺。

Delegation Record

记录谁把哪个 Task 版本在何种条件下委托给谁，以及是否允许 Subdelegation。

Context / Action Grant

把 Delegation 中的一部分权限落实为短期、目标受限的技术授权。

Task State

Task 当前生命周期状态以及需要的下一步行动。

Result / Artifact

Provider 产生的输出、状态变化或外部承诺。

Verification Evidence

证明 Result 是否符合 Completion Criteria 的测试、签名、规则结果、人工确认或第三方证明。

Feedback

Principal、Primary Agent 或 Verifier 对 Task 过程和 Result 的结构化评价。它与 Verification Evidence 不等价。

8.4 七个逻辑层

8.4.1 Identity and Principal Layer

负责回答：

谁在行动。
谁代表谁。
哪个身份或组织运营 Agent。
委托链是否可追溯。

可以复用企业身份、证书、域名、OAuth Client Identity 或 Verifiable Credential。

8.4.2 Capability Description and Discovery Layer

负责：

表达 Capability Type 与 Offer。
解析 Provider 接口和认证要求。
召回候选。
管理 Offer 版本与失效。

A2A Agent Card 和 MCP Tool Description 可以成为输入，但参考模型不要求它们是唯一来源。

8.4.3 Task and Matching Layer

负责：

Task Formation。
Requirement 提取。
Context-aware Matching。
约束检查。
候选解释与备选路径。

8.4.4 Trust and Evidence Layer

负责：

Identity、Capability、Behavior 和 Outcome Evidence。
Evidence 的来源、时间、版本和适用条件。
风险级别与 Trust Decision 输入。

8.4.5 Delegation and Authorization Layer

负责：

Proposal 与 Task Acceptance。
Delegation Record。
Grant 生成与回收。
Subdelegation Policy。
人类确认 Gate。

8.4.6 Execution and Verification Layer

负责：

Provider 执行。
Task State 与事件。
Result / Artifact。
Verification 与争议。

大部分实际执行可以发生在协调层之外。

8.4.7 Governance and Audit Layer

负责：

Policy 与风险分级。
事件和授权审计。
投诉、争议和 Provider 治理。
数据保留与删除。
网络级攻击处理。

8.5 最小交互接口

本章不定义 HTTP Endpoint，只定义应存在的语义操作。

`discover(requirements, context_summary)`

返回 Capability Offer 候选和匹配所需元数据。

`assess(candidate, task, evidence_policy)`

返回 Trust Evidence、风险和未解决问题。

`propose(task_request)`

Provider 返回接受、拒绝、澄清或修改后的 Proposal。

`delegate(proposal, policy)`

创建 Accepted Task 与 Delegation Record。

`authorize(delegation, resource, action)`

生成或引用最小 Grant。

`observe(task_id)`

读取状态、进度和需要的输入。

`cancel(task_id)`

请求取消，并触发 Grant 回收与下游处理。

`verify(task_id, result, criteria)`

返回验收状态与 Verification Evidence。

`record_evidence(task_id, evidence)`

把经过 Policy 允许的结构化结果用于审计或未来协调。

这些操作可以映射到 A2A、MCP、OAuth 和现有业务 API，但映射关系需要后续协议草案验证。

8.6 四类图结构

Capability Graph

连接 Capability Type、Offer、Provider、依赖和适用条件。

它回答：哪些主体在什么条件下提供哪些能力？

Evidence Graph

连接 Provider、Capability、Task 条件与 Verification Evidence。

项目早期使用的 Reputation Graph 容易让人联想到单一评分，因此本章优先使用 Evidence Graph。Reputation 可以是其上计算出的局部视图。

Delegation Graph

连接 Principal、Primary Agent、Provider Agent 和 Subdelegatee，记录 Task 与授权如何传递。

它回答：谁把什么权力交给了谁？

Task Completion Graph

连接 Task、Requirement、Provider、Result、Verifier 与完成状态。

它回答：哪些任务在什么条件下被谁完成，结果如何被证明？

关系

这四张图不一定是四个数据库，更可能是同一组事件和对象的不同投影视图。

8.7 控制平面的最小数据边界

建议保存

稳定 ID 与版本。
Task Summary 与风险等级。
Capability Offer 和 Evidence 引用。
Delegation 关系。
Grant 的类型、范围和有效期，不保存 Secret 本身。
Task State、Result 摘要和 Verification 状态。
审计所需事件。

默认不保存

用户完整长期 Memory。
与当前 Task 无关的个人画像。
可通过受控引用访问的原始敏感数据。
支付凭证、长期 Token 或可复用 Secret。
不必要的完整执行 Artifact。

例外

某些企业部署可能要求集中存储，某些 Consumer 产品也可能经用户同意保存 Memory。本章只主张“不是协调成立的默认前提”，不禁止具体部署做不同选择。

8.8 部署形态

8.8.1 Primary Agent 内嵌

Discovery、Matching 和 Delegation 都运行在用户或企业 Primary Agent 内部。

优点：Context 完整、隐私边界清晰。
风险：跨平台互操作和共享 Evidence 较弱。

8.8.2 企业控制平面

组织统一管理 Agent、Capability、Policy 和审计。

优点：身份和授权基础成熟。
风险：主要解决组织内协调，开放网络价值有限。

8.8.3 独立协调服务

第三方提供 Discovery、Matching、Trust 或 Task State，执行和原始数据留在两端。

优点：跨 Provider 中立性和网络覆盖。
风险：Context 不足、冷启动和双边信任。

8.8.4 联邦协调网络

多个 Registry、企业或平台通过公共语义交换 Capability、Delegation 和 Evidence。

优点：避免单一平台控制。
风险：标准、治理、身份和争议处理最复杂。

8.8.5 协议优先、无独立平台

各方直接使用公共协议协作，没有统一 Coordinator。

优点：开放、可组合。
风险：Discovery、Trust、观测和用户体验可能碎片化。

8.9 关键不变量

无论采用哪种部署形态，都应尽量维持以下不变量：

每次行动可关联到 Agent Identity 和 Task。
Delegation 不自动授予超出 Task 的权限。
Context 披露范围可解释并可审计。
Task 状态不能由未授权主体任意修改。
Provider 自报成功不自动等于 Verification 通过。
Subdelegation 不自动继承完整权限。
Grant 到期、取消或 Task 完成后应失效。
Evidence 必须记录适用条件和版本。
Principal 能看到不可逆行动与未解决风险。
协议错误不能静默扩大权限。

这些不变量比具体 API 形状更适合成为白皮书长期结论。

8.10 参考流程映射

以跨境差旅 Task 为例：

用户是 Principal，个人 Agent 是 Primary Agent。
Primary Agent 形成 Task Summary 与公司 Policy 约束。
Discovery Service 返回多个差旅 Capability Offer。
Evidence Service 提供身份、覆盖地区和历史结果。
Matching 选择一个 Provider Agent，并保留备选。
Provider 提出价格范围、所需信息和交付时间。
用户确认后形成 Delegation Record。
Authorization Service 为航班查询、日历写入和限定额度支付分别生成 Grant。
Provider 执行并持续返回 Task State。
Verifier 检查时间、预算、Policy 和出票状态。
结构化 Evidence 被记录，护照和支付凭证不进入协调层长期存储。

这个流程展示的是角色与对象关系，不预设必须由一个平台实现。

8.11 与现有协议的关系

A2A

可承载 Agent Card、Message、Task State、Artifact 与 Agent 间交互，但不负责全球 Discovery、跨网络 Reputation 或完整业务授权。A2A Specification

MCP

可让 Agent Host 发现并调用 Tool、读取 Resource 和使用 Prompt，但 MCP Server 不自动构成独立 Agent，也不完整表达 Task Delegation。MCP Architecture

OAuth 与 Token Exchange

可承载目标受限的访问和部分 Delegation Actor 语义，但不定义 Capability Matching、Task Acceptance 或 Completion Criteria。RFC 8693 RFC 8707

Verifiable Credentials

可表达 Issuer 对身份、资质或属性的可验证 Claim，但不能自动决定 Claim 是否适用于当前 Task。W3C VC Data Model

暂定结论

Coordination Layer 更可能是现有协议之上的语义组合与控制关系，而不是替代它们的新“万能协议”。

8.12 本章结论

观察

身份、能力发现、任务状态、授权和验证已经分别存在技术积木，但它们缺少统一的 Task-level 关联。

推导

协调层最小需要连接 Principal、Agent、Capability Offer、Task、Delegation、Grant、Result 与 Evidence。

暂定结论

参考模型由七个逻辑层、十类核心对象和四种关系视图组成；具体部署可以中心化、内嵌、联邦化或协议优先。

工作假设

跨主体语义和关键不变量可以比具体协议实现更稳定，并允许控制平面与数据平面分离。

风险 / 反例

如果不同生态无法对 Task、Capability、Identity 和 Delegation 达成最低语义共识，参考模型只能成为单一平台内部架构，无法形成开放 Coordination Layer。

第 9 章：从协调层到网络

9.0 本章要回答的问题

一个帮助 Agent 发现和委托能力的系统，为什么不会退化为普通 API Gateway、Registry 或可替代的中间件？它在什么条件下才能形成真正的网络价值？

本章的核心判断是：

Coordination Layer 只有在增加参与者会同时改善供给覆盖、任务完成和可信 Evidence 时，才可能形成网络；单纯积累 Agent 列表、日志或调用量不构成网络效应。

这是整份白皮书证据最弱的部分之一。

9.1 从“可连接”到“可完成”

一个技术层可能经历四个阶段：

Stage 1：Connectivity

Agent 或 Tool 能够通过协议互相调用。

价值来自接口统一，但替代性较高。

Stage 2：Discovery and Matching

系统能够根据 Task 找到并比较 Capability Offer。

价值来自候选覆盖与路由质量。

Stage 3：Delegated Completion

系统能够管理 Task Acceptance、Authorization、状态和 Verification。

价值来自更高的完成率、可控风险和失败恢复。

Stage 4：Learning Network

跨 Task 的 Verified Outcome 改善后续 Matching 与 Trust，更多高质量 Provider 又吸引更多 Task。

只有第四阶段接近 Task Completion Network。前三个阶段仍可能只是有用但容易被内建的基础设施。

9.2 三个可能的正反馈循环

9.2.1 Capability Liquidity Loop

更多真实 Task

→ 更多 Provider 愿意发布 Capability Offer

→ Task 找到合适供给的概率提高

→ 更多 Task 愿意进入系统

这个循环只有在新增 Provider 提供差异化能力，而不是重复低质量供给时才成立。

9.2.2 Evidence and Trust Loop

更多 Accepted Task

→ 更多条件化 Verification Evidence

→ Matching 与 Trust Assessment 更准确

→ 完成率和信任提高

→ 更多高价值 Task 愿意被委托

这个循环依赖 P6。若结果难以验证或无法共享，它会退化为每个用户的本地 Memory。

9.2.3 Composability Loop

更多可互操作的 Capability

→ Agent 能组合更多复杂 Task

→ 产生新的 Task 类型和 Subdelegation 关系

→ 进一步吸引专业 Provider

这个循环依赖稳定的 Task、Capability、授权和失败语义，而不只是接口可调用。

9.3 什么不算网络效应

以下现象可以提高产品价值，但不能直接证明网络效应：

数据库中的 Agent 数量增长。
API 调用量增加。
单一客户产生更多日志。
模型因内部训练而变好。
销售规模带来更低成本。
Provider 因平台补贴而短期加入。

真正的网络效应要求一个参与者的加入或一次高质量交互，为其他参与者创造可观察增量价值。

检验问题

新 Provider 是否提高其他 Task 的完成概率？
新 Task 是否为其他用户产生可迁移的 Evidence？
新关系是否降低后续 Delegation 的信任成本？
退出一个主要 Provider 是否降低整个网络价值？
数据是否只有平台自身可用，还是能形成生态公共能力？

9.4 冷启动问题

没有 Task，就没有 Evidence

初期只能依赖自我声明、测试或第三方资质，Trust 较弱。

没有 Provider，Task 没有选择价值

如果每类 Capability 只有一个 Provider，Matching 只是固定路由。

没有标准，接入成本过高

Provider 需要为不同 Primary Agent 重复描述能力、权限和状态。

没有入口，双方都不愿投入

开放网络的经典双边冷启动会被 Agent 生态进一步放大，因为还需要解决机器可理解性和授权。

9.5 更现实的采用顺序

直接建立“全球 Agent Internet”不是合理起点。更可能的顺序是：

第一步：单一场景、已知 Provider

在一个可验证 Task 类型中证明 Context-aware Matching 与协调闭环优于固定选择。

第二步：单一信任域、多 Provider

在企业或开发环境内引入真实身份、Policy 和重复 Task，积累可比较 Evidence。

第三步：跨组织的批准网络

允许有限外部 Provider 接入，验证跨域身份、授权和争议处理。

第四步：开放或联邦 Discovery

在基本语义、攻击防护和治理成熟后，再扩大开放接入。

推导

采用顺序应从“可验证完成”向“开放供给”扩展，而不是先追求最大 Agent 数量。

9.6 第一批用户的可能顺序

现有文档把人、Primary Agent、企业 Agent 和开发者都列为候选。它们并不需要被一次选定为同一入口。

开发者

关心接口、调试、评估和多 Provider 路由。最容易接受机器可读对象，但不一定拥有足够高价值 Task。

企业 Agent Platform Team

拥有身份、Policy、重复任务和多个内部系统，是验证 Delegation 与审计的有利环境。

Primary Agent

是长期 Machine-first 入口，但前提是它能够获得足够 Context、用户信任和调用权限。

人类用户

更适合通过确认、解释和异常处理参与，而不一定直接浏览开放 Agent Directory。

工作假设

最现实的采用顺序可能是：开发与企业环境先验证协议和控制价值，Primary Agent 再成为高频需求入口，消费者开放网络最后出现。

9.7 可能的护城河

标准与互操作

只有在多方采用且迁移成本低于封闭接口时才有价值。标准本身也可能是公共品，未必带来商业护城河。

Trust 与 Evidence

条件化、可验证的历史可能提高选择质量，但也面临隐私、可迁移性和平台锁定争议。

Delegation Relationship

稳定的 Principal–Provider 关系、Policy 与授权习惯可以降低重复协调成本，但应允许用户迁移，避免把依赖伪装成信任。

Distribution

成为 Primary Agent 或企业控制平面的默认入口会带来分发优势，也最容易被 OS 和大平台控制。

Protocol Compatibility

能够连接不同 Agent、Tool、身份和授权系统可以形成工程优势，但可能随标准成熟而商品化。

Completion Dataset

如果 Verified Outcome 真能改善 Routing，它可能形成数据优势；如果只是无法比较的日志，就不是护城河。

9.8 开放性与价值捕获的矛盾

一个开放 Coordination Layer 面临结构性张力：

越开放，Provider 越容易接入，攻击和低质量供给也越多。
越严格治理，网络越可信，但接入成本和中心化程度越高。
Evidence 越可迁移，生态越健康，平台独占数据优势越弱。
数据越封闭，商业壁垒可能更强，但开放网络主张越不可信。

白皮书不能同时默认“完全开放、完全可信、完全可迁移、平台拥有强数据壁垒”。这些目标之间需要明确取舍。

暂定原则

如果项目以 Agent Internet 为长期愿景，应优先把价值建立在互操作、验证和协调质量上，而不是依靠扣留用户 Identity、Memory 或 Reputation。

9.9 命名关系

现阶段可以暂时采用以下层级：

Agent Internet

长期生态愿景：不同 Principal 和组织的 Agent 可以跨域发现、委托和协作。

Coordination Layer

本文研究的基础设施层：连接 Task、Capability、Trust、Delegation、Authorization 与 Verification。

Task Completion Network

只有在真实委托与 Verified Outcome 能持续改善后续协调时，才形成的网络结果。

Capability Internet

强调供给可发现和可组合的视角，但容易弱化 Agent Identity、Delegation 和责任边界。

命名状态

这是解释层级，不是最终品牌决策。白皮书标题使用 Agent Internet / Coordination Layer，因为它能同时表达愿景与研究对象；Task Completion Network 暂不作为已成立事实。

9.10 网络形成的可证伪条件

如果出现以下结果，不应继续使用“网络效应”叙事：

Provider 数量增加没有提高任务覆盖或完成率。
Evidence 只对单一用户有效，不能安全迁移。
历史数据不能改善留出 Task 的 Matching。
用户始终依赖固定 Provider，不发生跨 Provider 选择。
互操作标准成熟后，协调服务没有持续差异化。
开放接入导致的攻击与治理成本超过新增供给价值。

在这种情况下，Coordination Layer 仍可能是有价值的软件或协议，但不是 Task Completion Network。

9.11 本章结论

观察

连接数量、调用量和数据量都不能单独证明网络效应。

推导

网络价值需要通过 Capability Liquidity、Evidence / Trust 和 Composability 三个循环，为其他参与者创造增量价值。

工作假设

以 Verified Outcome 为基础的条件化 Evidence，可以让协调质量随真实使用提高。

暂定结论

Coordination Layer 是基础设施层。
Agent Internet 是长期生态愿景。
Task Completion Network 是需要被结果证明的网络状态。

风险 / 反例

如果 Evidence 无法迁移、Provider 供给高度集中或协调被 OS 内建，网络效应和独立商业位置都可能不成立。

第五部分：反方论证与边界

第 10 章：为什么可能不需要独立 Coordination Layer

10.0 本章要回答的问题

什么样的未来会让本文的核心主张失败？即使 Coordination 作为功能存在，为什么它可能不形成一个独立、开放的基础设施层？

本章区分两个问题：

Agent 完成复杂任务是否需要协调。
协调是否需要一个独立的 Coordination Layer。

第一个问题成立，第二个问题仍可能失败。

10.1 反方一：更强的通用 Agent 会吸收专业能力

论点

基础 Model 和 Agent Runtime 继续进步后，一个通用 Agent 可以自己完成规划、推理、Tool Use 和错误恢复。专业 Agent 的必要性下降，多 Agent 协作只是当前能力不足的过渡方案。

它攻击哪些命题

P1：能力供给将持续分散。
P3：需要按 Task 匹配不同 Provider。
P4：Discovery 之后需要独立协调。

它成立的条件

通用 Agent 在主要领域达到足够质量。
外部数据和 Tool 可通过统一接口获得。
用户接受一个 Agent 持有广泛 Context 和权限。
专业 Provider 的质量优势不足以抵消调用复杂度。

白皮书仍可能保留的边界

即使推理集中，外部库存、组织权限、牌照和现实履约仍可能分散。Coordination 可能从“选择专业 Agent”收缩为“统一 Agent 对外部 Capability 和责任主体的协调”。

Kill Signal

在多个高价值场景中，单一通用 Agent 长期达到与多 Provider 系统相当的完成率、成本和风险表现，且用户无需开放外部选择。

10.2 反方二：操作系统和超级助手会内建协调

论点

最了解用户 Context、Identity、设备和权限的是 OS、浏览器、企业套件或超级助手。它们天然处于 Primary Agent 位置，能够内部完成 Discovery、Matching、授权和结果反馈。独立协调服务既拿不到完整 Context，也没有默认入口。

它攻击哪些命题

P2：开放 Agent-side Discovery 会成为主要入口。
P5：不持有完整 Context 的独立控制平面仍有足够价值。
P6：独立网络能积累可迁移 Evidence。

它成立的条件

超级入口覆盖主要 Provider。
用户信任其长期持有 Context。
平台提供足够好的授权与审计。
Provider 接受平台分发和规则。
跨平台迁移不是用户重要诉求。

白皮书仍可能保留的边界

不同超级入口之间仍需互操作。
企业可能不接受消费者平台控制业务 Agent。
Provider 可能需要跨平台发布一次 Capability Offer。
公共 Delegation 和 Evidence 语义仍可作为协议层存在。

Kill Signal

主要 Task 的协调长期被少数入口内部完成，外部 Provider 只需适配各平台接口，市场没有对中立 Discovery、Evidence 或 Delegation 的独立需求。

10.3 反方三：企业只需要封闭控制平面

论点

企业真正关心的是已批准 Agent、内部数据、固定 Policy 和完整审计，而不是开放网络。跨组织委托风险过高，开放 Agent Internet 不符合采购、合规和责任要求。

它攻击哪些命题

P1 中“开放供给”的意义。
P2 中动态 Discovery 的采用。
Agent Internet 的跨域愿景。

它成立的条件

大多数高价值 Task 都在组织边界内完成。
外部 Provider 必须经过长期采购和安全审查。
动态 Capability Offer 无法进入生产环境。
跨域身份和争议处理成本过高。

白皮书仍可能保留的边界

Coordination Layer 可以先成为企业 Agent Control Plane：管理内部 Capability、Delegation、最小授权和 Verification。长期是否开放由证据决定。

Kill Signal

组织内场景有明确需求，但多年没有向跨组织动态委托扩展；“Internet”只能作为愿景而不能描述实际网络。

10.4 反方四：协议已经足够，不需要平台层

论点

A2A、MCP、OAuth、Verifiable Credentials 和现有 API 可以分别解决交互、Tool、授权与身份。开发者可以按需组合，Coordination Layer 只是这些协议的包装。

它攻击哪些命题

P4 的独立层必要性。
第 8 章参考模型的产品位置。
标准与兼容性护城河。

它成立的条件

协议之间的组合成本足够低。
Task Formation、Matching 和 Verification 都可由 Primary Agent 本地完成。
Provider 不需要共享 Discovery 或 Evidence 网络。
用户不需要统一状态和审计视图。

白皮书仍可能保留的边界

Coordination Layer 可以是公共语义、开源组件或企业参考架构，而不一定是独立平台或商业网络。

Kill Signal

采用现有协议的 Primary Agent 能低成本实现同等完成率与治理能力，独立协调服务没有可测量增量价值。

10.5 反方五：协调成本高于专业化收益

论点

多 Agent 系统带来通信、Context 丢失、延迟、失败传播和责任模糊。即使专业 Provider 单项更强，整体系统也可能不如一个较弱但一致的 Agent。

它攻击哪些命题

P1 的供给多样性是否有价值。
P3 的动态 Matching 是否值得。
P4 完整闭环是否增加完成率。

成本来源

Task Formation 与 Requirement 转换。
Capability Offer 标准化。
多轮协商和授权。
Context 复制与损失。
网络时延和可用性。
失败恢复与重复执行。
Verification 成本。

白皮书仍可能保留的边界

只服务高价值、高差异、可验证 Task；对简单 Task 使用 Direct Call。Coordination 应是风险自适应，而非默认多 Agent 化。

Kill Signal

在同任务对照实验中，协调系统的质量提升长期无法覆盖成本、时延和失败复杂度。

10.6 反方六：Trust 和 Evidence 无法形成公共网络

论点

任务结果高度私密、主观和情境化，无法跨用户比较。开放 Reputation 会被刷取、串谋和选择偏差破坏。最终每个 Primary Agent 只能维护自己的关系 Memory。

它攻击哪些命题

P6：执行结果改善后续协调。
Evidence Graph 的跨主体价值。
Task Completion Network 与数据飞轮。

它成立的条件

Completion Criteria 大多主观。
Evidence 不能去标识化或共享。
Provider 变化速度快于历史积累。
防作弊和难度校准成本过高。
用户不愿让协调服务看到结果摘要。

白皮书仍可能保留的边界

Evidence 可以保持本地或在企业内部使用；开放层只交换资质和协议级证明，不建立全局 Reputation。

Kill Signal

历史 Outcome 无法在留出 Task 上提高选择质量，或提高幅度小于隐私与治理成本。

10.7 反方七：人类不会把高影响选择交给 Agent

论点

Provider 选择涉及品牌、责任和主观偏好。错误委托比人工搜索更难接受，人会继续亲自选择重要服务。

它攻击哪些命题

P2：搜索主体部分转向 Agent。
Machine-first API 的采用顺序。

白皮书仍可能保留的边界

Agent 可以完成候选召回、约束检查、解释和低风险路由，人类保留最终确认。P2 本身只主张部分转向，不要求全自动。

Kill Signal

即使 Agent Recommendation 稳定优于人工选择，用户仍长期拒绝授权或使用率极低。

10.8 未来形态矩阵

能力供给	协调入口	最可能形态
高度集中	封闭入口	超级 Agent，无独立协调层
分散	封闭入口	OS / 平台内建 Router 与授权
分散	企业信任域	企业 Agent Control Plane
分散	多入口但协议互通	联邦 Coordination Layer
高度开放	可迁移身份与 Evidence	Agent Internet / Task Completion Network

当前证据只足以确认前四种形态都具有可能性，不足以宣布最后一种必然胜出。

10.9 独立层必须证明的增量价值

要反驳本章，项目必须在真实场景中证明至少一项：

比 Primary Agent 本地实现找到更合适的 Provider。
在更少 Context 暴露下保持接近或更高完成率。
显著降低跨 Provider 接入和授权成本。
提高失败恢复、撤销和审计能力。
让 Verified Outcome 改善其他参与者的后续选择。
提供单一 OS、平台或企业无法独自覆盖的互操作价值。

如果没有这些证据，“Coordination Layer”只是对已有 Agent Runtime 功能的重新命名。

10.10 本章结论

观察

Coordination 作为功能可能被通用 Agent、OS、企业平台或现有协议组合吸收。

推导

证明协调问题存在，不等于证明独立开放层成立。项目必须同时证明跨 Provider 需求、Context 边界和可迁移 Evidence。

暂定结论

最现实的早期形态可能是 Primary Agent 内嵌或企业控制平面，而不是立即出现全球开放网络。

工作假设

跨平台、跨组织的 Capability Discovery、Delegation 和 Evidence 最终会产生不能被单一入口完全内部化的公共价值。

风险 / 反例

如果 P4、P5 或 P6 在目标场景中失败，白皮书必须主动收缩定位，不能用更宏大的愿景掩盖证据不足。

第 11 章：本文不主张什么

11.0 为什么需要负面边界

Agent Internet 是一个容易扩张的概念。Discovery、Marketplace、Identity、Memory、Payment、Workflow、Reputation 和 Agent Runtime 都可以被放进这个叙事。如果不明确排除范围，白皮书会看起来无所不包，也就无法被验证。

本章给出当前版本的明确非主张。

11.1 不主张未来每个人必然拥有 Agent

“越来越多个人和组织可能使用代表其行动的 Agent”是趋势假设，不是已经确认的事实。

白皮书真正依赖的是：足够多高价值 Task 由 Primary Agent 发起或管理，使 Machine-readable Coordination 具有实际需求。即使不是每个人都有 Agent，这个条件也可能在企业和专业场景中成立。

11.2 不主张所有任务都需要多 Agent

大量任务可以由单一 Agent、固定 Workflow 或 Direct Tool Call 更高效地完成。

Coordination 主要面向：

能力跨多个 Provider 分布。
需要敏感 Context 或外部权限。
存在 Provider 选择差异。
任务具有持续状态。
结果需要验证或承担责任。

对简单任务强行多 Agent 化，只会增加成本和故障点。

11.3 不主张建立全球唯一 Agent 商店

一个中心化商店无法代表所有企业、个人和地域的 Trust Policy，也容易把 Capability Discovery 简化为上架、分类和排名。

白皮书允许多个 Registry、企业目录、协议发现和直接配置并存。真正需要互操作的是 Capability、Task、Delegation 和 Evidence 语义。

11.4 不主张平台拥有全部 Agent

Coordination Layer 的价值不依赖 Provider Agent 运行在同一平台。相反，本文关注独立、内部实现可能不透明的主体如何协作。

具体平台可以托管 Agent，但托管不是协调协议成立的前提。

11.5 不主张平台保存完整用户 Context

P5 明确把“最小必要披露是否足够”列为高风险工作假设。

本版倾向于：

Primary Agent 持有完整 Intent、Memory 和个人 Policy。
Coordination Layer 使用结构化 Task Summary。
已接受委托的 Provider 按需获得受限 Context。
Secret 和原始数据尽可能通过受控引用访问。

如果实验表明这种边界无法维持质量，白皮书将收缩独立层主张，而不是默认扩大数据所有权。

11.6 不主张 Agent 拥有法律人格

本文使用“Agent Identity”“行为归属”和“责任边界”，指技术与治理上的可追溯关系。

最终法律责任仍需根据运营主体、Principal、合同、授权和当地法律判断。白皮书不提出新的法律人格制度，也不提供法律意见。

11.7 不主张存在一个普遍有效的 Trust Score

Trust 是 Provider、Capability、Task Context、运行条件和 Principal Policy 的函数。

全局星级可能适合低风险浏览，却不能替代：

身份验证。
资质和适用范围。
Task-specific Evidence。
权限限制。
Result Verification。

Reputation 是输入，不是真理。

11.8 不主张 Capability 可以被完全标准化

一部分高频能力可以形成稳定 Schema，但开放世界会持续出现新任务、复合能力和领域差异。

本版只主张 Capability Offer 至少表达 Outcome、Input、约束、权限、Provider 和 Verification。它应允许自然语言描述、结构化字段和扩展并存。

11.9 不主张重新发明所有协议

身份、授权、Token、Tool、Task State 和可验证 Claim 已有大量标准与基础设施。

Coordination Layer 应优先复用：

A2A 的 Agent 间任务交互。
MCP 的 Tool 与 Context 接入。
OAuth 的授权与 Token 机制。
企业 IAM 与 Policy Engine。
Verifiable Credentials 的 Claim 表达。

白皮书关注这些对象如何在一次 Task 中形成一致关系，不以发布另一个万能协议为前提。

11.10 不主张开放生态必然战胜封闭平台

封闭系统可能具有更好的体验、Context、分发和安全治理。开放网络只有在跨平台互操作、供给多样性、迁移或中立性产生可测量价值时才成立。

项目必须允许以下结论：某些领域长期只适合封闭或企业联邦网络。

11.11 不主张 Coordination Layer 必然是独立公司或产品

它可能是：

Primary Agent 的内部模块。
企业 Agent Control Plane。
开源协议与参考实现。
云平台服务。
多个服务共同构成的联邦层。
独立的中立协调网络。

白皮书先证明问题与机制，再讨论最合适的产品和组织形态。

11.12 不主张当前已经存在数据飞轮

项目目前没有真实 Task、跨 Provider Outcome 或长期 Routing 数据。

因此，以下表述都只能是工作假设：

执行结果会改善后续 Matching。
Reputation 会形成网络效应。
Task Completion Data 会构成护城河。

只有 P6 通过留出任务和攻击测试后，才可以升级这些表述。

11.13 不主张本白皮书已经证明市场需求

协议、论文和架构趋势只能证明问题可被描述，并不能证明客户愿意采用或付费。

市场需求至少还需验证：

谁最痛。
现有替代方案为何不足。
协调收益是否高于接入成本。
谁承担集成和治理责任。
谁愿意为结果改善付费。

11.14 当前成熟度：Present / Missing / Proposed

Present

一套明确的 Agent、Task、Capability、Principal 定义。
六个核心命题及可证伪条件。
Discovery、Trust、Delegation 和 Verification 的概念闭环。
Coordination Layer 参考模型。
反方论证和停止条件。

Missing

目标场景中的直接用户证据。
多 Provider 的真实 Capability Offer。
Context 最小化实验。
Delegation 与授权的可运行实现。
Verified Outcome 数据。
采用、留存和付费证据。

Proposed

先以可验证、低外部风险场景测试 P3–P5。
再用重复 Task 测试 P6。
只有结果支持时，才扩大到开放 Discovery 和网络叙事。

11.15 本章结论

观察

Agent Internet 很容易被误读为包含所有 Agent 产品能力的总平台。

推导

若不主动限定范围，项目就无法识别哪些证据真正支持 Coordination Layer。

已收敛结论

本文只研究跨主体 Task 中的 Capability Discovery、Trust、Delegation、Authorization、状态和 Verification 关系。

工作假设

这些关系最终可能形成开放或联邦的 Task Completion Network。

风险 / 反例

原型结果可能只支持企业内部控制平面、Primary Agent 模块或轻量 Routing；这些都应被视为有效但更窄的结论。

第六部分：验证路径

第 12 章：研究议程与最小原型

12.0 本章要回答的问题

如何用最小成本验证白皮书最重要、最不确定的命题，而不是先构建一个大而全的 Agent 平台？

本章把原型定义为研究工具：

它的目标不是证明我们能做出 Agent Directory，而是区分 Discovery、Context-aware Routing 与完整 Coordination 在真实结果上的差异。

12.1 研究优先级

按照第 4 章的命题依赖，优先级是：

P3：Task-specific Matching 是否优于固定 Provider 或全局排名。
P4：Delegation、状态和 Verification 是否比 Discovery + Direct Call 带来额外价值。
P5：最小 Context 是否能保持足够匹配和执行质量。
P6：Verified Outcome 是否改善未来 Routing。
P2：人是否愿意从手动选择迁移到推荐或自动委托。
P1：Capability 与权限是否在目标场景中真实分散。

P1 需要持续市场和系统研究；P2 可以随使用观察。最小原型应首先直接验证 P3–P5。

12.2 核心研究问题

RQ1：Provider 是否存在可预测的任务差异？

如果所有 Provider 表现高度一致，Context-aware Matching 没有必要。

RQ2：Task 和约束特征能否预测最佳 Provider？

这决定 P3 是否成立。

RQ3：Capability Offer 是否足以支持初步 Matching？

如果 Offer 无法准确表达边界，Discovery 只能依赖人工配置。

RQ4：显式 Delegation 和 Completion Criteria 是否减少错误完成？

这决定 P4 在目标场景中的增量价值。

RQ5：最小 Task Summary 与完整 Context 的质量差距是多少？

这决定 P5 和控制平面边界。

RQ6：哪些 Evidence 能预测未来结果？

这决定 P6 是否只是合理直觉，还是可测量机制。

RQ7：协调成本是多少？

必须同时计算额外时延、Token、人工确认和集成复杂度。

RQ8：用户在哪个风险点愿意授权？

这决定 Human-in-the-loop 和 P2 的实际边界。

12.3 场景选择标准

第一个场景应同时满足：

至少存在三个有差异的 Provider 或 Capability 实现。
Task 可以重复生成，避免只依赖单个案例。
Result 能通过测试、规则或稳定人工标准验证。
Context 和约束会影响最佳选择。
存在一定 Delegation 和权限边界。
外部失败成本可控。
可以在数周而不是数月内获得结果。

排除标准

只有一个真实 Provider。
结果完全主观且无法复核。
必须先建设全球身份、支付或开放市场。
一次失败会造成不可接受的现实损害。
需要大量用户才能产生第一个有效样本。

12.4 三个候选场景

场景	Provider 差异	可验证性	权限 / Delegation	风险可控	可重复性
软件变更质量保障	高	高	中	高	高
跨境商务出行	高	中高	高	中低	中
企业知识研究与报告	中	中	中	高	高

12.4.1 软件变更质量保障

Task 示例：

根据代码变更、仓库 Policy 和风险等级，选择并委托适合的 Review、Security、Test 或 Dependency Capability，产出可验证的发布建议。

可用 Provider 可以是不同模型、专业 Agent、静态分析 Tool 或组合 Workflow。Result 可通过已知缺陷、测试、规则和人工复核验证。

12.4.2 跨境商务出行

能够真实体现 Context、支付、外部承诺和多个 Provider，但涉及个人数据、库存变化和现实资金，原型成本更高。

12.4.3 企业知识研究与报告

风险较低、容易获取重复 Task，但 Provider 差异和 Completion Criteria 可能不够明确，容易退化成普通 RAG 或模型评测。

当前推荐

工作建议：先使用“软件变更质量保障”作为研究原型。

原因：

能以只读权限开始。
Task 和 Result 可重复、可注入已知真值。
不同 Capability 的适用范围明显。
可以验证 Task-specific Routing，而不是只比较通用模型。
可以逐步加入写入、发布和高风险授权，但初期不必承担现实资金与个人数据风险。

这不是最终产品定位，只是验证白皮书命题的实验夹具。正式选择前仍需结合团队技术资产确认。

12.5 最小实验对象

Task Spec

至少包含：

task_id
desired_outcome
change_type
repository_context_summary
constraints
risk_level
allowed_actions
completion_criteria

Capability Offer

至少包含：

provider_id
capability_type
supported_languages_or_domains
input_requirements
limitations
cost_and_latency_class
required_permissions
verification_method

Delegation Record

至少包含：

task_id
delegator
delegatee
accepted_scope
context_grant
action_grant
expires_at
completion_criteria

Result Evidence

至少包含：

task_id
provider_version
result_summary
verification_status
verified_findings
missed_findings
false_positive_findings
cost
latency
human_intervention

这些字段是实验最小结构，不是最终公共 Schema。

12.6 实验组

Baseline A：固定 Provider

所有 Task 使用同一个总体表现最好的 Provider。

它代表“直接使用最强 Agent”。

Baseline B：静态目录 / 全局排名

根据 Capability 标签或历史全局分数选择 Provider，不使用当前 Task Context。

它代表 Discovery-first 方案。

Treatment C：Context-aware Matching

根据 Task 类型、仓库特征、风险、成本和权限选择 Provider，并给出理由。

它主要验证 P3。

Treatment D：Managed Delegation

在 C 基础上增加：

Provider Proposal / Acceptance。
明确 Completion Criteria。
最小 Context Grant。
Task State。
Result Verification。

它主要验证 P4、P5。

Treatment E：Evidence-aware Routing

在积累历史 Task 后，加入条件化 Verified Outcome，再对未来 Task 路由。

它主要验证 P6。

12.7 数据集设计

首轮建议使用 36–60 个 Task，覆盖至少：

功能逻辑缺陷。
安全问题。
依赖与许可证风险。
性能退化。
测试缺失或不稳定。
文档与 Policy 不一致。

每类 Task 应包含：

已知真值或可复核标准。
不同规模和语言。
不同风险等级。
对不同 Provider 有真实区分度的特征。

防止实验自证

Task 设计者与 Routing 规则设计者应尽量分离。
在查看最终结果前冻结 Matching 规则。
使用留出 Task 检验泛化。
失败样本不能从报告中删除。
Provider 版本变化必须记录。

12.8 主要指标

Task Utility

综合：

真问题召回。
误报。
严重度判断。
约束满足。
成本和时延。

Completion Rate

满足 Completion Criteria 的 Task 比例，不使用 Provider 自报成功。

Routing Regret

实际选择与该 Task 上可观察最佳 Provider 之间的效用差距。

Permission Exposure

为完成 Task 暴露的数据字段、文件范围和可执行动作。

Coordination Overhead

相对于 Direct Call 增加的时延、Token、网络交互和人工确认。

Recovery Quality

Provider 失败后能否暂停、换路由、撤销权限并保留可用中间结果。

User / Operator Trust

对选择理由、权限请求和最终状态的理解与接受程度。

12.9 命题支持规则

这些规则应在正式实验前冻结。

P3 获得支持，如果

Context-aware Matching 在相同预算约束下，留出 Task 的平均 Utility 高于最佳固定 Provider 和静态排名，并且收益不是来自使用更多 Context 或更高成本。

P4 获得支持，如果

Managed Delegation 显著降低无效完成、约束违反或失败恢复成本，且新增协调开销没有抵消收益。

P5 获得支持，如果

结构化最小 Context 保留完整 Context 方案至少 90% 的 Task Utility，同时显著减少敏感信息暴露。90% 是初始研究阈值，可在采集数据前根据场景风险调整，但不能在结果出现后修改。

P6 获得支持，如果

Evidence-aware Routing 在时间顺序留出 Task 上优于 Card-only Matching，并在加入虚假反馈、Provider 版本变化和新 Provider 后仍保持收益。

12.10 停止和收缩条件

收缩为 Discovery / Registry

如果 Context-aware Matching 与固定排名没有差异，或者 Proposal、状态和 Verification 没有额外收益。

收缩为 Primary Agent 内部模块

如果完整 Context 对质量至关重要，最小披露无法维持表现。

收缩为企业控制平面

如果身份、授权和 Evidence 只在单一组织内可用，跨域成本过高。

放弃数据飞轮叙事

如果历史 Evidence 不能提高未来 Routing，或防作弊和隐私成本过高。

暂停开放接入

如果无法控制身份重建、隐藏 Subdelegation、权限升级或 Evidence Poisoning。

停止条件不是失败后的补救，而是原型开始前必须接受的决策规则。

12.11 分阶段实施

Phase 0：离线基准

构造 Task Dataset。
定义 Capability Offer。
跑固定 Provider 和静态排名。

Phase 1：Context-aware Router

实现 Task Summary。
返回候选、理由和不确定性。
验证 P3。

Phase 2：Managed Delegation

增加 Proposal、Acceptance 和状态。
使用只读、最小权限执行。
增加 Verification。
验证 P4、P5。

Phase 3：Evidence Loop

记录条件化 Outcome。
对未来 Task 做 Evidence-aware Routing。
进行攻击与漂移测试。
验证 P6。

Phase 4：受控真实用户

比较人工选择、Agent 推荐和 Policy 内自动委托。
观察 P2、理解度和信任变化。

在 Phase 2 之前不需要开放市场、支付或全球 Agent Identity。

12.12 原型明确不做

不做通用 Agent 商店。
不做完整消费者 UI。
不允许开放匿名 Provider 注册。
不设计全球 Reputation Score。
不保存用户完整长期 Memory。
不处理现实支付和高影响写入。
不为了演示完整而实现所有协议。
不把单次 Demo 成功当作命题验证。

12.13 原型交付物

Task Dataset 与真值说明。
Capability Offer 样本。
Baseline 与 Treatment 定义。
可复现运行记录。
Matching Decision 与解释。
Delegation、Grant 和 Task State 记录。
Verification Evidence。
命题级评估报告。
失败样本与停止条件复盘。

原型价值取决于是否能改变我们对 P3–P6 的判断，而不是界面完成度。

12.14 本章结论

观察

目前项目没有直接证据证明 Context-aware Matching、独立控制平面或 Outcome 数据飞轮成立。

推导

最小原型必须用同一 Task、Provider 和预算比较固定选择、静态 Discovery、Context-aware Matching 与 Managed Delegation。

当前建议

先使用软件变更质量保障作为低外部风险、可重复、可验证的研究场景，依次验证 P3、P4、P5，再验证 P6。

工作假设

该场景能够代表 Coordination 的核心机制，而不会因为过于工程化而失去向其他领域迁移的价值。

风险 / 反例

如果该场景主要表现为 Tool Routing，而不存在真实 Task Acceptance、权限和 Provider 边界，它只能验证 P3，不能充分证明开放 Agent Delegation。

Conclusion

回到最初的问题

Agent Internet 是否需要一个 Coordination Layer？

本白皮书给出的不是无条件的“是”，而是一个可检验的条件判断：

如果有价值 Task 持续跨越多个 Capability、数据、权限和责任边界；如果 Provider 的适配度依赖具体 Task 与 Context；如果 Discovery 无法低成本替代 Trust、Delegation、Authorization 和 Verification；并且这些过程可以在不过度集中原始数据的前提下完成，那么 Coordination Layer 将成为 Agent 生态中的独立基础设施问题。

反之，如果通用 Agent 或超级入口能够在封闭体系内高效覆盖主要 Task，或者完整 Context 必须由入口平台独占，或者 Outcome Evidence 无法改善后续选择，那么 Coordination 仍然存在，但不会形成本文设想的开放独立层。

白皮书最重要的收敛

1. 问题中心从 Agent 列表转向 Task Completion

用户不需要更多 Agent 名称，而需要一次具体 Task 在约束内达到可验证结果。

2. Agent、Task、Capability 是不可互相替代的基本对象

Task 驱动一次协调。
Capability 支持供给发现与比较。
Agent 承载选择、委托、执行和行为归属。

3. Discovery 是入口，不是闭环

从 Candidate Set 到 Verified Outcome 之间存在 Matching、Trust、Commitment、Authorization、Execution、Verification 和 Accountability。

4. Coordination Layer 更像控制平面

它应优先连接身份、Task、Capability、Delegation、Grant、状态和 Evidence，而不是默认成为新的用户数据仓库。

5. Trust 必须条件化，Delegation 必须受限

全局 Agent Score 不足以支持高风险委托。Trust 需要结合 Provider、Capability、Task、Evidence 和运行条件；Delegation 需要绑定范围、期限、权限和结果标准。

6. Task Completion Network 仍是假设

只有 Verified Outcome 能够跨 Task 改善 Matching，并且在隐私、漂移和攻击条件下仍然有效，协调层才可能形成网络价值。

三种可能的最终结论

后续验证可能导向三种都合理的结果。

Outcome A：开放或联邦 Coordination Layer 成立

跨 Provider Task 普遍存在，最小 Context 足以匹配，公共 Evidence 能改善选择。此时 Agent Internet 和 Task Completion Network 得到支持。

Outcome B：Coordination 成立，但只适合封闭信任域

企业、OS 或 Primary Agent 需要完整 Context 与身份控制。此时成果更像 Agent Control Plane 或本地协调协议。

Outcome C：问题主要是 Discovery / Routing

显式 Delegation、状态和 Verification 没有足够增量价值。此时项目应收缩为 Capability Registry、Router 或开发工具。

一个严肃的白皮书必须允许后两种结果，而不是把所有证据都解释成对最宏大愿景的支持。

下一道决策门

理论阶段之后，不应立即建设开放平台。下一步是完成第 12 章定义的对照实验：

固定 Provider。
静态 Discovery。
Context-aware Matching。
Managed Delegation。
Evidence-aware Routing。

只有当 P3–P5 获得支持，才有理由进入跨组织 Provider、开放 Discovery 或网络治理。

最终表述

Agent Internet 的核心不是让 Agent 数量更多，而是让独立行动主体能够在可理解、可授权、可撤销、可验证的关系中共同完成 Task。Coordination Layer 的价值，不在拥有所有 Agent 和数据，而在让这些关系可以被机器表达、被 Principal 控制，并被真实结果检验。

附录 A：术语表

术语	本文定义
`Principal`	授权 Agent 代表其行动，并承受主要收益、成本或风险的个人、组织或上游主体
`Root Principal`	委托链最终服务的人或组织
`Immediate Principal`	直接向当前 Agent 下达 Task 或授予权限的主体
`Agent`	代表 Principal、围绕目标有限自主选择行动，且行为可归属的软件主体
`Primary Agent`	直接代表 Principal 进行 Task Formation、Policy 应用和外部协调的 Agent
`Provider Agent`	接受 Delegation 并执行或组织执行 Task 的 Agent
`Networked Agent`	具有可发现 Identity、Capability、交互方式和 Task 语义，可参与跨主体委托的 Agent
`Intent`	Principal 想要发生的变化，可能模糊且没有完整边界
`Task`	具有 Outcome、Context、约束、权限、生命周期和 Completion Criteria 的工作单元
`Task Request`	尚未被 Provider 接受的具体工作请求
`Accepted Task`	Provider 已接受范围、约束和结果责任的 Task
`Task Formation`	把 Intent 转化为可协调 Task 的过程
`Capability`	某主体在特定前提和约束下产生某类结果的能力
`Capability Type`	与具体 Provider 无关的抽象能力类别
`Capability Offer`	Provider 对 Capability 的具体供给声明、条件、接口和限制
`Capability Evidence`	支持或反驳 Capability Offer 的测试、资质或历史结果
`Skill`	某个 Provider 实现、封装或呈现一个或多个 Capability 的可复用单元
`Tool`	具有明确输入、操作和输出的可调用函数
`Model`	提供推理、生成、预测或理解的计算组件
`Workflow`	预先定义步骤、依赖和控制流的执行结构
`Discovery`	根据 Capability Requirements 找到潜在 Offer 和 Provider 的过程
`Matching`	在当前 Task、Context 和条件下评估候选适配度的过程
`Routing`	把 Task 或请求发送给选定 Provider 或 Capability 的动作与策略
`Trust`	基于 Evidence 和当前条件，对 Provider 是否足以承担特定风险 Task 的判断
`Reputation`	来自历史行为或第三方评价的 Trust 信号，不等于最终 Trust Decision
`Delegation`	在明确范围、期限和条件下，把完成特定 Task 的有限行动权授予另一主体
`Authorization`	把 Policy 或 Delegation 落实为可执行权限决定的过程
`Grant`	针对特定 Resource、Action、时间或 Actor 的技术授权
`Subdelegation`	Delegatee 把 Task 的一部分继续委托给其他主体
`Result`	Task 执行产生的输出或状态变化
`Artifact`	Result 的可传递表示，例如文档、代码、记录或凭证
`Verification`	根据 Completion Criteria 判断 Result 是否可接受的过程
`Feedback`	用户或系统对过程和结果的评价，不一定经过验证
`Evidence`	可用于支持身份、能力、行为或结果判断的可追溯信息
`Context`	完成或判断当前 Task 所需的环境、历史、偏好和数据
`Control Plane`	管理身份、选择、Delegation、Grant、状态和 Evidence 关系的层
`Data Plane`	保存原始数据、执行动作和产生大体积 Artifact 的系统
`Coordination Layer`	连接 Task、Capability、Trust、Delegation、Authorization、状态和 Verification 的控制层
`Agent Internet`	不同 Principal 和组织的 Agent 能够跨域协作的长期生态愿景
`Task Completion Network`	真实委托和 Verified Outcome 能持续改善后续协调时形成的网络状态

附录 B：命题与 Evidence 台账

命题	当前状态	支持线索	主要反证	首要验证
P1 能力供给持续分散	工作假设	A2A / MCP 以异构系统为前提；数据与权限分域	超级 Agent 或平台吸收主要能力	绘制目标场景 Capability、数据和权限分布
P2 搜索主体部分转向 Agent	工作假设	Tool Discovery、Agent Card、Model-controlled Call	人坚持手动选择；企业仅用白名单	比较手动、推荐、Policy 内自动路由
P3 适配度比绝对能力重要	已收敛理论判断，待实证	Provider 条件差异；Model Routing 相邻研究	单一 Provider 全面占优；Context 成本过高	同任务比较固定、静态排名和 Context-aware Matching
P4 Discovery 不足以形成闭环	已收敛理论判断，待实证	A2A Task State、Authorization、Artifact 等对象	Direct Call 已有同等完成与治理效果	逐层加入 Delegation、状态和 Verification
P5 不必拥有全部原始 Context	高风险工作假设	A2A 不要求共享内部状态；控制 / 数据平面可分离	完整历史对匹配不可替代	无 Context、最小 Summary、完整 Context 对照
P6 Outcome 改善后续协调	高风险工作假设	Routing 与 P2P Reputation 相邻研究	Evidence 主观、私密、易攻击或快速过期	Card-only 与 Evidence-aware 留出任务对照

台账更新规则

每次研究或原型后，为每个命题记录：

新增支持 Evidence。
新增反对 Evidence。
Evidence 是否直接来自目标场景。
适用边界是否变化。
是否触发收缩或停止条件。
结论状态是否需要升级或降级。

没有直接 Evidence 的命题不得因重复出现在文档中而自动升级为事实。

附录 C：已推翻或修正的观点

C.1 “做一个 Agent 商店”

原表达

附录 D：代表性任务案例

D.1 案例目的

以下跨境商务出行案例用于解释抽象对象，不代表原型已经选择差旅产品。

D.2 Intent

下周去东京见客户，帮我安排好行程。

D.3 Task Formation

Primary Agent 需要澄清：

会议时间、地点和优先级。
出发地和可接受时段。
护照、签证与入境条件。
公司预算、舱位和酒店 Policy。
个人偏好与会员权益。
哪些动作可自动完成。
什么状态算安排完成。

D.4 Capability Requirements

日历与 Policy 读取。
入境条件检查。
航班、酒店和交通库存查询。
多约束行程组合。
企业协议价或会员价格访问。
预订、支付、通知、取消和改签。

D.5 Discovery and Matching

协调系统发现多个 Capability Offer，并比较：

覆盖地域。
可访问库存。
企业协议支持。
数据 Policy。
价格与时延。
取消能力。
结果 Evidence。

D.6 Trust and Proposal

Provider 证明运营身份和相关 Capability，返回：

可行行程范围。
预计价格。
需要的 Context。
支付前确认点。
失败与取消条件。

D.7 Delegation and Grant

Primary Agent 在用户确认后创建 Delegation：

允许搜索和预留。
支付上限为批准预算。
只能访问本次出行所需护照属性。
不允许隐藏 Subdelegation。
价格变化超过阈值必须重新确认。

D.8 Execution and Verification

Provider 返回状态和 Artifact。Verifier 检查：

时间是否覆盖会议。
是否符合公司 Policy。
票据是否真实出票。
总成本是否在预算内。
日历和报销记录是否正确写入。

D.9 Evidence

协调层可以记录：

Provider 和 Capability 版本。
Task 条件摘要。
是否按时完成。
是否发生价格偏差、人工介入和改签。
Verification 状态。

不必长期保存完整护照、支付凭证和全部旅行历史。

D.10 案例暴露的问题

完整 Context 是否必须由单一入口持有。
Provider 是否能在最小披露下报价。
外部承诺需要多强的人类确认。
失败后的退款和责任如何处理。
真实 Result 是否能形成可迁移 Evidence。

附录 E：最小对象草图

以下结构仅用于说明对象边界，不是最终协议或 Schema。

E.1 Task Request

{
  "task_id": "task_123",
  "desired_outcome": "完成符合公司政策的东京商务出行安排",
  "context_summary": {
    "origin": "Shanghai",
    "destination": "Tokyo",
    "meeting_window": "2026-07-21T09:00:00+09:00/2026-07-21T17:00:00+09:00"
  },
  "constraints": {
    "budget": "policy-defined",
    "confirmation_required_for": ["payment", "price_change"]
  },
  "risk_level": "L3",
  "completion_criteria": [
    "arrives_before_meeting",
    "complies_with_travel_policy",
    "booking_is_confirmed"
  ]
}

E.2 Capability Offer

{
  "offer_id": "offer_travel_tokyo_v3",
  "provider_id": "provider_456",
  "capability_type": "business_travel_booking",
  "supported_regions": ["JP"],
  "required_context": ["travel_dates", "policy_attributes"],
  "required_actions": ["inventory_read", "booking_write"],
  "limitations": ["no_visa_legal_advice"],
  "verification": ["booking_reference", "policy_check"],
  "evidence_refs": ["evidence_set_789"]
}

E.3 Delegation Record

{
  "delegation_id": "del_321",
  "task_id": "task_123",
  "delegator": "primary_agent_001",
  "delegatee": "provider_456",
  "accepted_scope": ["search", "hold", "book_after_confirmation"],
  "subdelegation": "approval_required",
  "grant_refs": ["grant_inventory", "grant_payment_limited"],
  "expires_at": "2026-07-18T12:00:00Z",
  "completion_criteria_version": "v2"
}

E.4 Verification Evidence

{
  "evidence_id": "evidence_654",
  "task_id": "task_123",
  "provider_id": "provider_456",
  "provider_version": "v3",
  "verification_status": "accepted",
  "checks": {
    "schedule": "pass",
    "travel_policy": "pass",
    "booking_reference": "pass",
    "budget": "pass"
  },
  "human_intervention": 1,
  "contains_raw_personal_data": false
}

E.5 设计要求

每个对象有稳定 ID 和版本。
Task 与 Delegation 明确关联。
Grant 只存引用，不保存 Secret。
Evidence 记录 Provider 版本和适用条件。
Schema 允许扩展，不要求所有领域共享同一字段。
原始 Context 与控制对象分离。

附录 F：参考资料

Agent 与多主体系统

Michael Wooldridge、Nicholas R. Jennings，Intelligent Agents: Theory and Practice。经典 Agent 属性与多 Agent 理论背景。
OpenAI Agents SDK: Agents。现代 Agent SDK 的工程定义、Tool 与 Handoff 构件。

Agent 与 Tool 协议

A2A Protocol Specification。Agent Card、Task、Message、Artifact、状态和安全语义。
A2A Agent Discovery。Agent Card 的发现方式与适配判断。
Model Context Protocol: Architecture Overview。Host、Client、Server、Tool、Resource、Prompt 与 Context Exchange。
Model Context Protocol: Tools。Tool Discovery、调用和 Human-in-the-loop 安全要求。

身份与授权

RFC 8693: OAuth 2.0 Token Exchange。Token Exchange、Delegation 与 Actor Chain。
RFC 8707: Resource Indicators for OAuth 2.0。目标 Resource 约束。
RFC 9700: Best Current Practice for OAuth 2.0 Security。Token 权限限制、保护与攻击缓解。
W3C Verifiable Credentials Data Model。Issuer、Holder、Verifier 与可验证 Claim。

Routing 与 Reputation 相邻研究

Isaac Ong 等，RouteLLM: Learning to Route LLMs with Preference Data。Task-conditioned Model Routing 与质量—成本权衡。
Sepandar Kamvar、Mario Schlosser、Hector Garcia-Molina，The EigenTrust Algorithm for Reputation Management in P2P Networks。历史交易 Evidence、开放 Reputation 与攻击问题。

引用说明

以上资料用于定义技术边界和提供相邻机制证据。A2A、MCP 或授权标准的存在不构成对独立 Coordination Layer 市场需求的证明；RouteLLM 和 EigenTrust 也不是 Agent Delegation 场景的直接实证。

Agent Internet面向开放 Agent 生态的 Coordination Layer