第 11 章 跨智能体协作

这一章补上第 5 章讲 MCP 时留的口子，智能体与智能体怎么跨组织协作：编排模式默认监督者与工人跑在同一个执行上下文里，可连锁品牌的法务智能体部署在企业内网，它想委托的那家律所的合规审查智能体放在律所自己的机房，中间隔着互联网、两套身份体系和两份商业合同，函数调用够不着，只能靠协议。11.1 讲 A2A 的三件套，智能体名片、任务生命周期和多协议绑定；11.2 回答工程师问得最多的那个问题，跟 MCP 比，到底怎么选；11.3 看注册、发现与市场怎么把“找智能体”变成工程问题；11.4 用博弈论回答一个更根本的疑问，为什么必须有编排、有契约这些设计；11.5 收拾理论剩下的两个问题，协作时信息怎么组织，功劳算谁的。标准化现状一句话，2026 年 3 月，A2A 协议（Agent2Agent Protocol，一个让相互独立的智能体系统跨组织互通的开放标准）放出 1.0.0，头一个稳定版，治理归 Linux Foundation，技术指导委员会是 AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNow 八家。

11.1 A2A 协议，智能体名片、任务生命周期与多协议绑定

A2A 用三件套回答跨组织握手的三个问题：对方到底是谁、凭什么信它，靠智能体名片（Agent Card）；活干到哪一步了、中途要人拍板该怎么办，靠任务（Task）生命周期；消息走哪条通道传，靠协议绑定（protocol binding）。把第 10 章那套监督者编排原样搬进跨组织场景，第一次握手碰上的正是这三个问题。

整套协议在规范里切成三层。Task、Message、AgentCard 这类结构放在数据模型这一层；发消息、查任务和取消任务这类动作，归操作这一层定义；把前两层搬上具体传输的，是绑定这一层。

智能体互相通信的标准，这条路已经走了三十来年。上世纪九十年代的知识共享工程（Knowledge Sharing Effort）出过一门 KQML（Knowledge Query and Manipulation Language，知识查询与操作语言），消息按言语行为分类，问一件事、告诉一件事、请对方办成一件事，各有各的保留字。设计思路跟今天几乎是同一份，智能体内部长什么样不重要，重要的是彼此的消息说得规不规矩。那一代智能体终究没能走向实用，KQML 停在了实验室。这一轮标准把同一个想法搬到 HTTP 和 JSON 的底座上，又补上了当年最缺的三件事，身份、签名和可查的记录。

每个 A2A 服务器都得在网络上发布一张名片。这张名片是一份 JSON 元数据文档，自己是什么、有什么能力、带哪些技能、服务端点在哪、认证上有什么要求，全都写在里面。

客户端想让对方干活，头一步是取名片。最常见也最简单的取法，是往一条固定路径发 GET 请求，路径就放在域名下的 /.well-known/agent-card.json。想查某家律所的合规智能体，就去取 https://agent.lawfirm.example/.well-known/agent-card.json。除了这条 well-known 路径，规范还列了目录查询和人工配置好的地址两种发现方式，其中目录查询正是 11.3 的主题。

supportedInterfaces 是 1.0 新增的设计，它是一个有序数组，每一项声明一种传输组合（URL、绑定类型、协议版本），排在最前面的就是首选。capabilities 用来声明可选能力，比如支不支持流式、支不支持 webhook 推送、有没有通过认证之后才可见的扩展名片。

认证方式写在 securitySchemes 里，采用 OpenAPI 风格，可以从 API key、HTTP Bearer、OAuth 2.0、OpenID Connect 和双向 TLS 这五种里挑。

skills 数组最像一份给模型读的说明书，里面每一项是一个技能，带着 id、名称、详述、标签和示例提问。客户端的编排智能体把这串 skills 读完，就知道这单活该不该派过来。defaultInputModes 与 defaultOutputModes 声明的是默认能收、默认会回的媒体类型，比如收文本和 PDF、回 JSON；客户端按这份声明去组织消息体。

把字段凑齐了看，名片其实只回答一个问题，把远端智能体当黑盒用的时候，该把哪些自我介绍公开出去。

名片是从对方域名下取回来的，可怎么确认它真的原样送达、确实出自它自称的那家律所，而不是被人半路改了内容，或者干脆是一张把客户端往恶意端点上引的假名片？

1.0 拿出来的方案是JWS 签名（JSON Web Signature，RFC 7515 定义的标准，对 JSON 内容做数字签名）。发布方先用自己的私钥给名片内容签名，把结果放进名片的 signatures 字段，跟着名片一起发出去。客户端拿到名片，取来公钥验签，签名能对上，内容的完整性和来源就有了密码学层面的保证。

做起来有两处要留神。签名之前，名片得先按 JCS 方案（JSON Canonicalization Scheme，RFC 8785）做一次规范化，键按字典序排好，没意义的空白和默认值去掉，这样不管哪家实现去算，算出来的待签名内容都一字不差。signatures 字段本身不参与签名，不然就成了循环引用。

签名结构里那个 protected 头带着密钥标识 kid，也能额外带一个 jku 地址，指向一个公钥集，客户端按这个地址去取公钥。规范还允许同一张名片带上多个签名，这是给密钥轮换留的余地。

这里有条分寸得拿捏住，签名属于可选能力，不是强制要求。规范的建议是，客户端在信任一张名片之前，至少验证其中一个签名。到了跨组织、强合规的场景，这条建议就该当成硬性要求，写进采购条款。

下面是一张最小的名片，字段却一个不缺（签名值只是示意，真跑起来是发布方拿私钥算出来的）。

{
  "name": "连锁门店合同合规审查智能体",
  "description": "面向连锁品牌的门店租赁合同合规审查，输出结构化风险清单。",
  "supportedInterfaces": [
    {"url": "https://agent.lawfirm.example/a2a/v1", "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0"},
    {"url": "agent.lawfirm.example:443", "protocolBinding": "GRPC", "protocolVersion": "1.0"}
  ],
  "version": "2.1.0",
  "capabilities": {"streaming": true, "pushNotifications": true},
  "securitySchemes": {
    "firmOAuth": {"oauth2SecurityScheme": {"flows": {
      "clientCredentials": {"tokenUrl": "https://auth.lawfirm.example/token", "scopes": {"contract:read": "读取合同", "report:write": "写回报告"}}
    }}}
  },
  "defaultInputModes": ["text/plain", "application/pdf"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "lease-compliance",
      "name": "租赁合同合规审查",
      "description": "按品牌方所在地的租赁法规与门店开业规范审查合同条款，输出风险等级与修改建议。",
      "tags": ["legal", "compliance", "lease"],
      "examples": ["审查这份北京新店的租赁合同，重点看免租期与违约条款"]
    }
  ],
  "signatures": [
    {
      "protected": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpPU0UiLCJraWQiOiJrZXktMSJ9",
      "signature": "QFdkNLNszlGj3z3u0YQGt_T9LixY3qtdQpZmsTdDHDe3fXV9y9"
    }
  ]
}

客户端读完这张名片，能得出这些结论。对面是一家律所的合规智能体，HTTP+JSON 绑定排在前面，gRPC 也支持；token 走 OAuth 拿，scope 读写分开；它挂着一个租赁合规技能；签名验得过。识别对方的部分到这里讲完，下一段讲任务管理。

A2A 把协作组织成一条条任务。客户端发来一条消息，服务器就为它建一个 Task，这个 Task 有服务端生成的唯一 ID，有状态，能跨很多轮往前走，最后产出若干工件（Artifact，也就是任务的结果物，可能是文档、图像或结构化数据）。规范对这三件事分得很清楚，消息管沟通，任务管过程，工件管结果。凡是结果性质的内容，都装进工件随任务返回，不该塞在消息里。换到第 10 章的话说，消息就是编排器循环里的输入输出，任务是跨组织的会话句柄，工件是验收时盯着的对象。

消息负责沟通，可沟通本身并没有保证。一条消息说“任务我接了”，它就成了一个承诺。承诺要算数，得两个条件同时成立，一是宣布的内容确实能约束住发送方，二是接收方有办法去验证。缺了任何一个，这句话就只是说说，不算承诺。智能体之间交接东西，能不能信，靠的是机制而不是话术，这个问题到 11.4 会用博弈论正面讲。

任务的整个生命周期，就是一台八状态的状态机。

八态里 SUBMITTED、WORKING 连着终态构成主线，两个中断态从主线分岔，缺的补齐，任务就回到 WORKING 继续跑。

状态	类别	含义
SUBMITTED	进行中	任务已提交并确认，排队等待执行
WORKING	进行中	任务处理中
INPUT_REQUIRED	中断	等待用户补充输入才能继续
AUTH_REQUIRED	中断	需要补充授权凭据才能继续
COMPLETED	终态	任务成功完成
FAILED	终态	任务执行出错终止
CANCELED	终态	任务在完成前取消
REJECTED	终态	智能体拒绝执行该任务

两个进行中状态与四个终态，表格里一行就写清了，真正要细看的是中间那两个中断态，它们要处理的其实是“把人拉进来”。

INPUT_REQUIRED 的意思是，智能体活干到一半，发现手里的信息不够，得等人来补。拿订机票的智能体说，它收到“帮我订下周去上海的航班”，任务推进到 INPUT_REQUIRED，同时附一条消息问出发时段和舱位偏好。客户端这边的人答完，用同一个任务 ID 再发一条消息，任务就回到 WORKING 继续跑。

协议把“等人”做成了一等公民，第 15 章讲人机协同的时候还会把这个状态展开细说。第 5 章 MCP 里的 MRTR 模式（多轮请求）干的也是同一件事，差别只在于等待挂在哪儿，MCP 挂在请求上，A2A 挂在任务上。AUTH_REQUIRED 更进一层，处理的是授权不足。

拿合规审查智能体来说，它要去调品牌方的合同库，手上却没有凭据，任务就转进 AUTH_REQUIRED，把搞定授权的差事交还给客户端。客户端要么自己去申请凭据，要么把这个任务继续标记成 AUTH_REQUIRED，让授权请求沿上游再传一层，规范写明这样能连成一条授权链。

把两个中断态放到一起看，A2A 把长任务的现实摆在了明处，活干到一半发现缺信息、缺权限，都是常见的事。协议的应对是停下来、把缺什么说清楚、等补齐了再走，而不是硬着头皮猜。

状态机之外，还有一个标识负责把多次任务串成一条线，那就是 contextId。它是服务端生成的上下文标识，在同一个上下文里，任务之间共享对话历史和历史工件。先让智能体订去上海的航班，过一会儿再让它订同一趟出行的酒店，只要第二条消息带上第一条任务返回的 contextId，智能体就知道这还是那次出行安排，航班信息不用再重复一遍。要多轮、要多任务、还要带记忆的协作，靠的就是它。

把这条生命周期走一遍的客户端骨架收在下面，场景就用章首那家连锁品牌的合同合规委托。

"""示意代码：A2A 任务生命周期的最小客户端骨架，python3 可直接运行。
远端律所的服务器用桩代替，状态流转与消息构造用的是真实语义。"""

import json
import uuid

def lawfirm_server(message: dict, task: dict | None) -> dict:
    """律所合规审查智能体（桩）：按消息推进任务状态机。"""
    if task is None:                      # 建任务，进入 WORKING
        return {"state": "WORKING", "context_id": uuid.uuid4().hex[:8],
                "question": None}
    if message.get("reply") is None:      # 材料缺细节，转 INPUT_REQUIRED
        return {**task, "state": "INPUT_REQUIRED",
                "question": "租赁合同的租期起算日，交付日还是开业日？"}
    return {**task, "state": "COMPLETED",  # 补答到位，直接完成
            "artifact": {"risk_level": "中",
                         "items": ["免租期条款缺兜底", "违约金上限偏高"]}}

def collaborate(contract: str) -> dict:
    """客户端循环：建任务、等中断、补信息、收工件，认同一对标识。"""
    message = {"text": f"审查这份门店租赁合同：{contract}"}
    task = lawfirm_server(message, None)
    while task["state"] != "COMPLETED":
        if task["state"] == "INPUT_REQUIRED":
            print(f"[{task['state']}] 智能体追问：{task['question']}")
            message = {"reply": "租期自交付日起算。",
                       "context_id": task["context_id"]}   # 同一上下文
        task = lawfirm_server(message, task)
    return task["artifact"]

if __name__ == "__main__":
    print(json.dumps(collaborate("华东区新店，三年期，含免租期两个月"),
                     ensure_ascii=False))

任务在 INPUT_REQUIRED 停下来等人，这一等可以隔着进程重启与好几天；补答带着同一个 contextId 回去，前面的合同背景不必重发一遍，这就是中断态加上下文标识合起来办成的事。

共享的历史一多，分布式系统的老问题就跟进来了，一致性。第 8 章讲记忆拓扑时提过共享层的并发读写，这里把档位摆全，常用的有三档。最终一致性（eventual consistency）最便宜，各份副本松一阵子终归对齐，代价是读的人可能拿到旧值；强一致性（strong consistency）最贵，任何一次读都拿得到最新写入，代价是每次写都得等所有人对齐；因果一致性（causal consistency）卡在中间，有先后因果的写按序可见，没有因果关系的并发写，各处的先后可以不同。选型有条经验律，默认从因果档起步，大多数协作够用又付得起；真要升到强一致性，先想清楚它退不回去：系统一旦按强一致性设计，事后放松会破坏正确性。跨组织的 A2A 协作尤其如此，一次对齐就是一趟跨网络往返，强一致性那一档基本不现实。

任务还在跑的时候，客户端有三条路可以跟进进展。最简单的是轮询，定时调一次 GetTask 看状态，任何绑定下都能用。流式（streaming）把连接保持住，状态更新和工件的分片实时推过来，适合那种要盯着进度的界面。webhook 推送则留给要跑好几个小时的长任务，客户端先登记一个回调地址，任务状态一变，服务器主动 POST 过来，不用一直占着连接。这三种通道跟第 15 章长任务 worker 的回调通知是同一个思路，协议把它定成了标准做法。

三件套里最后一件是多协议绑定，它同时也是 1.0 跟旧版之间的一道分水岭。0.2、0.3 那个时期，A2A 的正式传输只有 JSON-RPC 一种，走 HTTP 的 POST 端点，消息格式跟传输方式绑得很死。

到了 1.0，语义跟传输彻底拆开了。数据模型与操作先定义在一个不依赖任何绑定的层面，随后映射到三种正式绑定，JSON-RPC、gRPC 和 HTTP+JSON（REST 风格）。

同一种操作，三种绑定下叫法不同。REST 里发消息是 POST /message:send，查任务是 GET /tasks/{id}，取消任务是 POST /tasks/{id}:cancel；换成 gRPC，就都是同名 RPC 方法。名片里的 supportedInterfaces 把服务器支持的绑定按优先级排定，客户端从自己会的里面挑最靠前的。规范还劝客户端备一套回退逻辑，首选绑定接不通就换下一个。

三种绑定之外，协议自己还留了一道能长大的口子，叫扩展（extension）。每个扩展用一个 URI 标识，服务器在名片的 capabilities 字段里声明自己支持哪些，客户端看见了才用，不认识的直接忽略。按改动的东西分，常见的扩展有四类，加新数据结构、给名片添画像类的元信息、加新方法、改状态机行为，规范不预设哪类合法，留给生态自己长。要当心的是碎片化，扩展一多，两套实现彼此认不认得对方的扩展，全凭运气，跨组织协作里启用冷门扩展，等于给对方立了一道隐形门槛。核心协议能解决的，先别急着上扩展。

真到选型的时候，三条经验基本够用。对外开放的服务选 REST，对防火墙友好，调试工具到处都有，一条 curl 就能握手。内网里高频的服务间调用选 gRPC，靠二进制序列化和长连接，吞吐更高，延迟也更低。JSON-RPC 留着，主要是兼容 0.x 时代留下来的存量实现。

绑定机制自己留了扩展口，自定义绑定用 URI 标识，规范举的例子是 WebSocket 绑定。多租户的实现同样在这套机制上，supportedInterfaces 里每一项 AgentInterface 都有一个 tenant 字段，当路由标识用，多个智能体共用一个端点的时候靠它分流，客户端在每个请求里原样带上就行。1.0 那项“单端点多租户”能力，就在这里实现。走到这一步，开头那三个问题各自有了答案，对方是谁看名片，活干到哪一步看任务状态，消息走哪条通道看绑定。

11.2 MCP 与 A2A 怎么选，组合式编排与委托式自治

分界一句话就能说清，MCP 管智能体调工具，A2A 管智能体找智能体干活。1.0 的发布公告专门澄清过这点，因为两个协议长得实在太像，都是 JSON 格式的开放协议、都走 HTTP、都声明能力、都有发现机制，连文档示例都常常是“订机票”，生态里因此传过一阵“A2A 要取代 MCP”的说法。两个协议解决的不是同一层的问题，MCP 用在智能体内部，去接工具和数据；A2A 用在智能体之间，去做通信和协调，这一节把这条分界展开：差别在协议对象上，两种用法（组合式编排与委托式自治）怎么选，责任与典型事故各长什么样。

长得像，是因为两边借的是同一套 Web 底座；真正要紧的，是它们不一样的地方。MCP 面向的是能力，也就是工具、资源和提示这些。服务器把它们摊开来摆好，什么时候调、调哪一个、结果怎么用，决定权全在宿主手里，每一次调用对宿主都可见、可拦、可审计。

A2A 面向的则是另一个自主系统。对方接下活，自己规划、自己调工具、自己推任务，内部用哪个框架、读哪些库、怎么推理，一概不外露，规范描述这种协作，用的词是不透明（opaque）。一边是摊开等人调用的能力清单，一边是主动接活的自主系统，协议给两类对象配的构件自然也不一样，MCP 端出工具列表和调用结果，A2A 端出任务状态机和工件。

对象不一样，用起来也就分化出两种形态。

头一种叫组合式编排。主智能体亲手拼流程，用 A2A 把子任务一步一步递到外部，控制权始终在主智能体手里。委托出去的每个步骤，都只是流程图上的一个节点；节点怎么衔接、上下文怎么准备、结果怎么用，全凭主智能体做主。

这种形态的价值，在于信息流由主智能体决定。主智能体坐在中间，给每个节点喂什么内容自己定，敏感字段可以先摘掉再递出去，两个外部智能体彼此不见面，产出全部汇回自己这边合并。第 10 章的监督者式只要换一层通信，就是这个形态，分派那一步从进程内函数调用，换成了跨组织的 A2A 任务。

第二种叫委托式自治。客户端把目标整个交给对方智能体，自己只等 Task 的最终结果。对方内部怎么拆解、调哪些工具、跑多少轮，客户端既不插手，也看不见，等拿到 COMPLETED 状态和工件，交付就算完成。这种形态适合的场景，是对方本来就是个专业黑盒。它的知识库、推理过程、行业积累，恰恰是不能摊开给人看的部分，硬要验看这些环节，委托就谈不成，对方能交付的只有结论。

连锁餐饮品牌栗粟轩准备开新店，法务智能体部署在品牌方内网，手头压着一摞等审的门店租赁合同。它自己没有文档处理能力，也没有律所那套合规知识，这两处都得向外面的智能体借。

第一处是借文档智能体，干的活是合同条款的结构化抽取。法务智能体把合同文本递过去，告诉对方要什么输出结构，拿回一份条款清单，然后自己接着审风险、写批注。

这一步就是组合式。抽取只是法务智能体整条流程里的一步，条款清单拿回来以后往哪走、风险规则怎么套，全由它自己定，文档智能体不知道、也不需要知道整个流程。

第二处向律所的合规审查智能体借力，求的是整份合同的合规意见。法务智能体把合同和门店背景信息打成一个包，当作任务发出去，接下来只剩等。等待途中对方可能转进 INPUT_REQUIRED，追一句租期细节，答完继续等，最后收回一件带风险等级的审查报告工件。

这一步是委托式。审查依据的地方法规、内部判例库、整套审查流程，全在律所那一侧，品牌方买的，就是这个黑盒里的专业判断。

两种形态还常常并肩出现在同一个系统里。怎么分，只看一个问题，这一步要不要盯住。要盯中间过程、要把喂给外部的信息管住、还得在节点间做路由与合并，走组合式。只图最终结论到手，对方中间怎么折腾插不上手、也看不明白，就走委托式。

责任也是摆在前面的现实约束。组合式里，每一步都是主智能体自己挑的，出了错，责任在自己。委托式里，结论从对方那边来，服务水平做到什么程度、免责条款怎么划，都得提前写进商务合同。协议的状态机管不到这份契约，但 Task 留下的完整轨迹（提交、中断、恢复、完成的时间线），事后追责，证据是现成的。

追责有证据还不够，得有章法，智能体之间可以立一套问责（accountability）机制。按事先谈定的规约，一方有权向另一方索取结构化的解释，为什么选这个方案、依据是什么、哪些信息没查到，对方按固定格式作答，而不是摊开全部内部状态。委托式自治保的就是对方那点不透明，问责问的因此该是决策依据，不是内部全部状态。规约里把哪些问题必须答、答成什么格式写死，事后追责不用逐条翻轨迹，对方也拿不出含糊的托词。

责任讲清楚是一回事，损失补回来是另一回事。商务合同里的惩罚条款，挪到跨组织的智能体协作上，有几种通行做法。一种是押金，接活之前先押一笔钱，或者押一笔预授权的支付额度，任务没按约交付，就按事先谈定的约定从里面直接赔付。另一种拿信誉当质押，违约的事实记进登记库，往后接单的机会跟着往下压，押上去的不是现钱，是未来的生意，11.3 讲的信任信号正是这套质押的底座。

双方扯不清的，还有第三条路，仲裁。事先约一个双方都认的第三方，违约没违约不听各说各话，听 Task 轨迹里的时间线和工件，裁决下来按约执行。三种做法办的是同一件事，让违约的代价在接活之前就谈定，而不是出了事只剩一句道歉。

两种形态还各有各的典型事故。组合式选对了却管得太细，把对方当成一个能遥控的函数库，每个中间产物都要传回来审一遍才放行下一步，跨网络的往返一多，延迟就叠了好几倍。对方真正的长处，比如自己清楚该先查哪张表、先核哪条法规，一点也用不上，结果等于花委托的钱，买了个慢速工具。

委托式选对了，放得又太开，同样出事。该自己把关的信息流整包送了出去，客户名单、报价底线这些不该出境的字段，跟着合同一起进了对方的上下文。事后想追，能追的只有 Task 轨迹，内容早就出去了。

两类事故的原因是同一个，形态跟信任没配好。组合式有个前提，这一步的中间过程确实在自己视野之内；委托式也有个前提，这个对象值得整包信任。选之前先把这两句话掂量清楚，比对着功能清单一项项打勾要靠谱得多。

跨组织之外，单个系统里多个智能体怎么搭伙，方式也多起来了。Claude Code 的团队模式正在试验四种协作拓扑，竞争假设让几个队友各带一套假设去查同一个问题，免得单线思路先入为主；并行评审是分头看同一份产出再把意见汇拢；模块所有让每个队友长期持有一个模块；提案审批加魔鬼代言人，则给每份提案安排一个专职唱反调的角色。截至 2026 年年中，团队模式还在实验阶段。

从两种用法再往上看一层，最常撞见的是两个协议各守一层。法务智能体接自家工具，走的是 MCP，合同库检索、OCR 和日程系统全挂在 MCP 服务器上；要委托外部的智能体，才换成 A2A。1.0 公告把这话讲得直白，多数系统实际用下来两个都要，MCP 待在智能体里面，A2A 用在智能体之间。

两个协议各管一层，可它们面对的功能需求，是同一张清单。为什么都要流式、要可恢复、要持久、要多轮？这四项需求，全都来自智能体跟传统分布式系统不一样的本性，自主、长时运行、交互和自适应。

任务常常一跑就是几小时甚至几天，人看不到进展就没法信任它，所以才要流式、要进度。熬到第三个小时，网络断了，之前干完的工作不能全部清零，这得靠可恢复。服务器重启了，结果还要在，客户端拿着引用什么时候都能来取，这归持久性管。活干到一半要人确认授权、澄清一句话，多轮交互接的就是这个。

拿这张清单回看本章，A2A 逐项都能对上号。流式这一项，归流式通道与 webhook 推送管；可恢复这一项，断线后凭任务 ID 重连，还能接着查、接着推；持久这一项，归持久的任务与工件管；多轮这一项，靠 INPUT_REQUIRED 和 AUTH_REQUIRED 两个中断态接住。

第 5 章那张清单，MCP 也有对应的实现，进度通知、Tasks 长任务、elicitation（服务器执行到一半向用户要输入）都在其中，协议细节以该章讲过的 2026-07-28 版规范为准。选型挑的是对象与信任，四项需求两边谁也躲不掉。

第 5 章还提过 MCP 的 Tasks 官方扩展，异步长任务、轮询查状态、中途要输入，功能清单跟 A2A 的 Task 非常像，那分界到底划在哪？答案不在功能强弱，而在对象与身份。MCP 的长任务，本质是给工具执行加异步，执行者是那个把能力摊开的工具服务器，做决定的始终是宿主。A2A 的任务是两个自主系统之间的工作单元，接活这一侧自己就是决策者。一句话说清，接能力用 MCP，请帮手用 A2A，分界就画在对面系统是否自主做决策上。

这条分界有个现成的例子，生态里已经有人这么干，把一整队智能体打包成一个 MCP 服务器。队伍的执行入口暴露成一个工具，调用一次，整队跑完。说明文档做成资源，上手引导做成提示，宿主想了解这支队伍能干什么，读一遍材料就有数。落到现实里，宿主就是 Cursor、Claude Code 这类编码智能体，它们读完材料，再自己决定什么时候调那个工具。

而打包在里面的那队智能体，各自都是自主的，每个成员有自己的分工和回路，这些自主全部留在接口后面。宿主看得到、调得动的只是一个能力，什么时候调、调完结果怎么用，决定权在宿主。接能力这一侧的形态就是这样，一整队自主的智能体，只要以工具、资源和提示的面目出现在宿主面前，宿主接它的方式就依然是 MCP，队伍内部的自主，改不了这一层的接法。

11.3 注册、发现与市场，登记库、能力声明与合规过滤

智能体名片管的是“找到之后怎么认、怎么连”，至于“上哪找”，它没有回答。合作对象只有三家五家的时候，靠人工互换名片地址还够用，把地址记在配置文件里，出不了大乱子。

规模一大，这套土办法就不够用了。集团内部几十个团队各建各的，上百个智能体，外部还站着一排服务商，地址谁来记、过期了谁来盯、“有没有能审华东区租赁合同的智能体”这种问题谁来答。A2A 规范给自己留了扩展的余地，发现机制除了 well-known 路径，还列出目录（registries/catalogs）和预配置两种，目录这一种正是本节要讲的登记库。

登记库（registry），用工程话讲，就是系统记录（system of record），是全生态唯一权威的记录，记着“什么存在、能干什么、归谁管、守什么规矩”。记录里要立的实体有六类。智能体自己算一类；对话记的是人与智能体之间的往来，留给追溯和审计；交互记的是一件任务从发起到执行再到完成的全程，是整份记录最基本的工作单元；工作区把目标、任务、消息攒成一份协作上下文，活得比单次对话久；策略与认证挂在智能体条目上，给执行层检查；用户则把身份和操作关联起来。六类里日常打交道最多的是智能体条目与策略，其余四类到审计、追溯时才翻。

智能体条目是登记库里的主表，对话和交互的历史，让整份记录事后能追溯、能审计。走到这一步，登记库就不止是个目录了，自主协作可不可靠，靠的就是这份记录。没有它，智能体难找，能力含糊，策略也没法一致地执行下去。

登记库里最要紧的，是能力声明怎么写，也就是一个智能体条目该怎么落笔。从字段看，它算名片的扩展版。除了名字、版本、描述，还得写清楚目的（这个智能体交付什么结果）、方法（它靠什么步骤把任务做完）、角色（在系统里担什么职责）、可用的工具清单、允许协作的对象名单，再加上策略与认证。

这些字段摆在那，读者分两类，写法也就跟着有两套标准。给模型读的那部分得机器可解析，要拿去路由和过滤，技能标签、输入输出媒体类型、版本号都得规规整整。给人读的那部分，是用来支撑信任判断的，谁发布的、过了什么认证、运行记录怎么样，都得能查。

两套标准合到一起，共同要防的是空话。“智能、强大、全面”这类形容词，机器看了是噪声，人看了是套话。一条既要机器能过滤、又要人能核实的能力声明，每个字都得具体到可验证。拿例子说，“按城市级租赁法规输出风险等级 JSON”就比“提供法律支持”值钱得多。

能力声明和名片，两份文档字段大量重叠，可各自职责不一样。名片活在对面的域名下，面向协议握手，客户端取它，是为了连线、为了调用。登记库条目活在治理域里，面向检索与管控，运维查它，是为了回答“谁能用、合规吗、版本对不对”。职责一分，就带出一个绕不开的工程问题，两边信息对不上时，听谁的。

设计上必须挑一头当权威源。要么以名片为准，登记库定期到各服务器去拉取核对，版本或技能清单对不上，就标成待核并触发再认证。要么以登记库为准，目录状态一变更，就要求服务器把名片同步更新。前一种更顺理成章，名片本来就在对方域名下，随时可取。可不管选哪头，同步本身就是登记库设计里最容易低估的一块，登记库可不可信，不光看认证做得有多严，还要看它跟线上实际跑着的服务贴得有多紧。

能力声明回答的是“能不能干”，企业真正放在心上的，是另外三件事，合不合规、可不可信、出了事找谁。合规过滤要做的，就是把这几条要求做成流程节点，挂到三个环节上。

发布之前，先过认证工作流。智能体上架不能光由发布者自己说了算，得过三道检查。策略检查，看声明的行为边界跟既定策略对不对得上。集成测试，看端点和能力是不是真的。信任认证，交给第三方或内部机构核验。全过了，才在登记库里查得到。而且认证不是办一次就完的事，它自带生命周期。有效、吊销和过期三种状态都记在记录里，策略更新会触发再认证，版本演进时要重新走一遍流程。

发现这一步有过滤。登记库的查询不是全库全文搜索，而是带规则的筛选。先按可见性范围圈定“谁有资格看到哪些智能体”，再按功能与策略属性去匹配特性范围，定下“这一类里哪个合适”。品牌方的法务团队搜合规智能体，结果里不会冒出它无权调用的内部审计智能体。标了“仅限金融域”的智能体，也不会进零售场景的候选。命名空间解析是配套机制，agent.legal.group 这种全限定名，把候选池天然圈在某个部门或某个合作方范围里。

候选池筛出来，一次具体的请求怎么落到某个智能体上，有种两步走的做法。头一步，把用户请求解析成一个语义意图对象，要干什么、带什么参数、有什么约束，字段按严格 schema 填，填不进就打回，不留自由文本的余地。第二步，拿这个对象去查能力图（capability graph），也就是把登记库里的能力声明连同它们的调用关系连成的那张网，看这张图允许的候选里哪个对得上，任务就派给谁。两步走的好处，是把路由从提示词里的自由发挥变成一次可测试、可审计的数据查询，路由错了能定位，是意图解析错了，还是能力图缺了条目。

运行阶段则看权限继承。智能体替用户干活，权限不能越过发起它的那个用户。法务专员的智能体，就调不动只有法务总监才有权签的接口。这条原则要求登记库跟企业的身份体系（IAM）接上，用户的角色和权限跟着请求传下去，智能体每执行一个动作前，都要拿发起人的权限边界过一遍。

登记库立起来，还有一个口子别漏，它记的全是智能体，智能体干活靠的工具，自己也该有一份记录。工具注册表（tool registry）跟智能体登记库是一个思路，字段换成工具的。生命周期记的是哪个工具上架、弃用、下架，各在什么日子；版本记的是接口定义改过几版，破坏性变更何时生效；归属记的是出了问题找哪个团队；审计记的是谁在什么时候调用过。工具跟智能体一样会在系统里烂掉，一个没人认领的老工具、一份改了 schema 没人知道的定义，出起事故来一点不比智能体越权少。治理只管智能体这一侧，等于大门装了门禁，侧门一直敞着。

在登记库之上再加一层面向人的界面，市场（marketplace）就出来了。市场天然是双边的。生产者这一侧发布智能体，消费者那一侧搜索、评估、调用。同一个市场，两类人看到的是两种模样。工程师看它，像看 PyPI 那种包仓库，关心版本、接口、生命周期。业务用户看它，像看应用商店，要搜索、比价、读评价。

评价体系要叫人信服，靠的是两条绑定。评分绑到智能体的具体版本上，反馈绑到完成过真实调用的认证身份上，两条一起，才能把刷分掺的水分挤出去。

真正帮人在市场页面上拿主意的，是信任信号（trust signal），包括发布者身份、审计历史、运行成功率和认证状态。这些信号的数据源，就是登记库的记录。市场是登记库的查询界面，登记库是市场的底座。

这一层到今天还没有统一的行业模样。登记库建到多细、市场怎么运营，各企业都按自己的路子摸索；本节给的实体模型和认证流程，是一套完整的设计参考，动手时按自家情况裁一裁就行。协议侧的采纳倒是实打实的。发布满一年，150 多家组织宣布支持，GitHub 上 star 数超过 2.2 万，Google Cloud、Azure、AWS 三大云平台全部接入。登记库最终长成行业公共设施，还是各企业自己建，这个走向的推演留给第 18 章。

同类的协议不止 A2A 一个。ANP（Agent Network Protocol）走去中心化路线，身份建立在 W3C 的 DID（Decentralized Identifier，去中心化身份标识符）上，不依赖任何中央登记机构，智能体跨互联网互认，给没有统一权威的多方协作打底。ACP（Agent Communication Protocol）由 IBM 在 2025 年 3 月发起，走 REST 风格，同样托管在 Linux 基金会，2025 年 8 月并入了 A2A 项目，两支团队合到了一处。支付那条线还另长出一个协议，AP2（Agent Payments Protocol），Google 牵头一批支付公司定的开放标准，管智能体替用户收付款时怎么把交易做得可验证、可审计，截至 2026 年 9 月，治理权已交给 FIDO Alliance。四个名字摆进一张表里看，一眼就能分清各自管什么。

协议	管什么	身份与治理
A2A	智能体之间的任务与通信	名片自描述加 JWS 签名，Linux Foundation 治理
ANP	去中心化的智能体互认与发现	W3C DID，无中央权威
ACP	REST 风格的智能体互操作	IBM 发起，2025 年 8 月并入 A2A
AP2	智能体发起的支付	Google 牵头，FIDO Alliance 治理

选型的时候盯住 A2A 这条主线就好，这几个名字的用处，是读新闻、读别人的架构图时认得出来路。

把这条链路放在一起看，名片是智能体在网络上的自描述，登记库把成百上千张名片收进一份带策略的记录，市场把这份记录翻给人看，合规过滤在发布、发现、运行三个环节把着关。这样，发现就从“记地址”变成了“按能力与权限检索”，信任也从口头承诺变成了可执行的元数据。智能体生态要上规模，靠的正是这些前提。

11.4 理论基础，囚徒困境、均衡与重复博弈

为什么非得有编排、有协议、有登记库？让一群智能体自己随便协作，效率不是更高吗？多智能体强化学习的研究，给过这个问题一个不留情面的答案，而这个答案，要从七十多年前的博弈论讲起。

假设两个智能体共用一个资源池，各自都有任务指标要完成。每一轮，它们面临两个选择。合作，就是按配额取用；背叛，就是超配额多占。把双方的收益排成一个矩阵来看，负数代表代价，每个格子里前一个数是自己的收益，后一个数是对方的。

	对方合作	对方背叛
自己合作	–1，–1	–5，0
自己背叛	0，–5	–3，–3

对着矩阵一列一列查。对方选合作那列，自己合作是 –1，背叛是 0，背叛更划算。对方选背叛那列，自己合作是 –5，背叛是 –3，背叛依旧更划算。也就是说，不管对方怎么选，自己这一轮背叛的收益都更高，这种动作就叫占优动作（dominant action）。

诱惑恰恰来自两个不对称的格子。自己背叛、对方合作那一格，收益是全表最高的；自己合作、对方背叛那一格，又是全表最低的。于是每个个体都倾向于赌对方守约、自己多占，多占来的资源，实打实地算进自己的指标。

两边都这么盘算，最后就是双双超采，一起落到 –3 对 –3 那一格，比双方都合作的 –1 对 –1 更差，资源池很快耗尽，下一轮谁的指标都完不成。

这就构成了囚徒困境（Prisoner's Dilemma）。双方合作，各自拿的是次高的收益。双方背叛，各自拿的是倒数第二差的收益。可背叛偏偏是每个个体理性算下来都会选的那条路。

放到工程语境里看，这套结构一点都不抽象。两个智能体共用一个缓存，容量一满，就得把旧条目挤掉。谁抢先写入，谁就把对方的常用数据挤出去。单看每一次写入，都是在“优化了自己的响应时间”，可两边都这么抢，最后两边的命中率一起往下掉。两个智能体共用一份预算，也都倾向把预算花在自己的子任务上，单看每一笔支出，都是“用在了刀刃上”。背叛不是故障，不是恶意，也不需要哪个智能体“变坏”。每个智能体只要老老实实优化自己的局部目标，坏结果自己就会冒出来。

坏结果出现以后会停在哪，均衡（equilibrium）这个概念回答的就是这个问题。所谓纳什均衡（Nash equilibrium），是指这样一种局面，任何一个参与者单独改变自己的策略，都拿不到更高的收益，于是谁都没有单方面变招的动机。多智能体反复互动，通常会停在某个均衡上稳定下来。糟糕的是，囚徒困境唯一的均衡恰恰是双双背叛，个体理性就这样把系统稳稳推向集体次优。

顺手把两个术语对上号。前面反复说的集体最优，学名叫帕累托最优（Pareto optimality），再也找不到一种改法，能让某一方更好，同时没有谁变得更差。纳什均衡也有个等价说法，局面里每个参与者的当前策略，都是对其余参与者策略的最优响应（best response），人人互为最优响应，谁单方面动谁吃亏，这正是没有变招动机的另一种讲法。往后读多智能体文献，这两个词会反复出现，认得出来，就不会被同一件事的两套说法唬住。

还有更微妙的局面，是均衡不止一个。协调博弈就是这样，两个智能体一起选方案 A、或者一起选方案 B，都是均衡；选岔了，一个 A 一个 B，两边全输。版本不齐、协议不齐、约定不齐的多智能体系统，天天都在演示选岔了是什么后果。

选岔的问题有种解法，靠的是公共信号，博弈论给的名字是相关均衡（correlated equilibrium）。设想一个双方都信得过的推荐装置，按公开的概率抽一个动作组合，私下把各自该选的动作发给它们。抽到 A 就两边都收到选 A，抽到 B 就两边都收到选 B，人人照建议做。给定别人都听话，自己听话就是最优，谁也没有偏离的动机。路口的红绿灯就是生活里的现成例子，谁先走不是两辆车谈出来的，是公共信号定下来的。这套结构经济学家奥曼在七十年代提出，覆盖面比纳什均衡更宽。工程里的对应物正是编排者，监督者看全局状态，给各智能体分派动作，扮演的就是那个发建议的装置；11.2 讲的委托式自治是另一头，把推荐权整个交给对方。编排为什么管用，这里多了一层解释，它不光收走了变招的自由，还把相关信号递到了每个人手里。

编排与契约为什么躲不掉，理论根源就在这三句话里，个体理性保不住集体最优，均衡又不只一个，还可能选岔。第 10 章的编排智能体，把下一步谁上从各智能体的局部判断里收走；A2A 的 Task 状态机，把承诺和交付写成可验证的协议；第 9.3 节的任务复杂度评估，把要不要拆成多个各自优化的智能体当第一道闸。它们挡的是同一件东西，自主个体滑向坏均衡的势头。

坏均衡还有一条更隐蔽的进场路线，不需要谁背叛，一群各自求稳的智能体也会一块儿退守。把猎鹿博弈（Stag Hunt）摆出来，两个智能体各自在猎鹿（S）和猎兔（H）之间挑。两边都猎鹿（S,S）各得 4，回报最高，这是回报占优均衡（reward-dominant equilibrium）；两边都猎兔（H,H）各得 2，这是风险占优均衡（risk-dominant equilibrium）。猎兔单干就能成，保底 2 分；猎鹿要是碰上对方溜号，落 0 分。

学习智能体从随机探索起步，用不了多久就会发现，猎鹿可能拿 0，猎兔稳拿 2，于是把概率一点点挪向猎兔。这一挪还会反过头来加固猎兔，当对方也在猎兔时，谁偏离猎兔谁就吃亏，系统就这样滑进风险占优的次优均衡，哪怕人人本来都更偏好合作。多智能体系统那种保守化倾向，理论根源就在这里。每个智能体都在学着求稳，学着学着，就把集体从人人更想要的均衡上拖走了，而这整个过程里，没有任何一步能单独拎出来说它是错的。

那还有没有能走出困境的路？博弈论指的方向，是把一次性博弈改造成重复博弈（repeated game）。同一批参与者反复交手，每一轮的历史都摊得开、看得见。局面马上就不一样了。这一轮的背叛，下一轮对方看得见、记得住、会还回来，背叛捞到的那点短期收益，得拿去对冲长期挨报复的成本。

有一招经典策略叫“以牙还牙”（Tit-for-Tat），它拿对方上一轮的动作当模板，对方合作，它就合作；对方背叛，它就背叛。光靠这点记性和对等回敬，合作就能在长期互动里维持下去。

长期互动还能沉淀出一样东西，惯例。合作类纸牌游戏 Hanabi 把这点演示得很干净。一桌人合伙按颜色和数字把牌从小到大摞上去，每个人只能看见别人的牌，看不见自己的，能用的通信只剩两种提示，指某几张牌的颜色，或者指某几张牌的数字。就这么点带宽，玩家照样长出一整套约定，比如刚给出的提示永远指最新的那张牌，比如提示一张暂时出不去的牌，意思是先把最老的牌打掉。智能体在自我对局里也会自发长出这类约定，毛病是碰上没一起磨合过的搭档就失灵，暗语对不上，配合反而更乱。跨组织协作里这个现象天天见，两家公司的智能体共享不了多少状态，说不了多少话，大量协调靠的正是长期磨合出来的默契规则。“我们一直是这么配合的”这句话，就是两套系统之间的 Hanabi 约定，值得写进文档，别只活在两个团队的口头习惯里。

这条出路是有边界的。合作靠“未来还会见面”这一点撑着，交互一旦有了已知的终点，越接近终点，背叛就重新变得理性。研究给过一个很具体的口径，在囚徒困境的重复对局里，双方前面各步都合作是最优的，可到最后一个时间步，合作值 –1，背叛值 0，两个智能体都会选背叛。最后一轮没有未来可言，报复也就无从谈起。工程里对应的节点同样认得出来，合同到期、项目收尾、交付前验收那几步，都是博弈论意义上的最后一轮，罚则和审计在这些节点上最不能放松。

这两条结论当场就能模拟出来，让守约到底、唯独末轮背叛的一位，去跟以牙还牙打二十轮。

"""示意代码：重复囚徒困境的最小模拟，python3 可直接运行。
场景是两个共用资源池的智能体，收益矩阵沿用本节那张表。"""

PAYOFF = {("合作", "合作"): (-1, -1), ("合作", "背叛"): (-5, 0),
          ("背叛", "合作"): (0, -5), ("背叛", "背叛"): (-3, -3)}

def tit_for_tat(opponent_last: str | None) -> str:
    """以牙还牙：拿对方上一轮的动作当模板，首轮合作。"""
    return "背叛" if opponent_last == "背叛" else "合作"

def coop_until_last(round_no: int, total: int) -> str:
    """守约到底，唯独最后一轮改判背叛。"""
    return "背叛" if round_no == total else "合作"

def play(total_rounds: int = 20) -> None:
    a_last = b_last = None
    score_a = score_b = 0
    for r in range(1, total_rounds + 1):
        a = coop_until_last(r, total_rounds)
        b = tit_for_tat(a_last)
        score_a += PAYOFF[(a, b)][0]
        score_b += PAYOFF[(a, b)][1]
        a_last, b_last = a, b
    print("二十轮累计（负数是代价，越接近 0 越好）：")
    print(f"  守约到底、末轮背叛：{score_a}")
    print(f"  以牙还牙：{score_b}")

if __name__ == "__main__":
    play()

前十九轮合作靠以牙还牙的记性维持着；到最后一轮，背叛没有了可报复的未来，那一格从各付一分变成一方不付、一方付五分。

放到工程系统里，对应物一样不缺。Task 的状态轨迹让每次交付都有记录，登记库的认证与审计让历史可查、可吊销，合约与服务水平协议让背叛要付代价。契约与编排做的事，就是把智能体之间那种一次性、无记忆、无承诺的交互，改造成有记录、可验证、带承诺结构的重复互动。

这套理论顺手也解释了，跨组织场景为什么把身份与历史看得那么重。博弈论里，最难维持合作的恰恰是一次性的陌生人交互。只交手一轮，互相不知名，此后再也不见，背叛没有任何后续成本，占优动作选得毫无悬念。

跨组织委托默认就在这种局面上。两个分属不同企业的智能体，一次 Task 交付完，可能再也没有往来。指望每一方都自觉合作，等于指望对方主动放弃占优动作。

把本章前面的组件回看一遍，件件干的是同一件事，把陌生人之间的一次性交互，改造成熟人间的重复博弈。JWS 签名的名片，把身份钉进密码学；登记库的认证与审计，把过往履历记进登记库；Task 的状态轨迹，把这一单的表现留作证据。

身份、历史、证据，三件都在，背叛才有代价，合作才能成立。协议的设计者未必是存心去引用博弈论，同一个问题逼到眼前，自然给出相同的答案。

契约把陌生人变成熟人，靠的是事后追责；还有条更冷静的路线，把功夫全花在事前。多智能体协作惯常的两端，一头是编排器把控制流写死，一头是让智能体自己协商，中间还有第三条路，先写规约。规约不规定谁在什么时候做什么决定，只声明消息之间的信息因果与完整性约束，哪份信息必须先到，缺了哪份流程不得往下走，哪几件事必须互斥。规约写完，智能体一行代码没写，就能先验证两条性质，活性（liveness），该发生的事最终会发生，流程不会卡死；安全性（safety），系统永远不会进入非法状态。协作的正确性从运行时测试前移到了设计时验证。第 10 章讲过，工作流图的执行路径能在运行前验证，规约式把同一种前移推到了整张信息流上。局限是这套工具眼下都停在研究原型阶段，工业界的主流仍是编排器加协议，但思路值得借鉴。

外部结构之外，智能体自己还能练一件事，给对方建模。认知科学管这叫心智理论（theory of mind），对别的智能体的目标、手里的信息、大概会怎么行动，持有一份内部模型，拿它预期对方的行为。放到协作里，头一个用处是不重复干活，模型里写着对方多半已经在查合同库了，自己就先去干别的，两个智能体都这么想，互相等、抢同一样活的两类死锁都少。

再进一层是递归推理，我料到对方会怎么看我，对方也在料我。谈判前先估对方的底线，派活前先想接活的那家会不会敷衍，用的全是这一层。分寸也得拿捏，眼下模型对同行的理解是统计意义上的近似，不是真共情，会高估也会低估，把一个只会硬套模板的对方当成深谋远虑的对手，或者反过来。心智模型只能作为先行的线索，关键决策还是得回到显式协议，名片怎么签、任务怎么记、赔付怎么定，本章前面立的规矩一样都不能省。

真要谈条件，给对方建模立刻用得上。协商（negotiation）是另一套市场化机制，没有中央裁决者，两边靠报价与反报价（offer and counteroffer）往返讨价，一方出个价，另一方压一刀，再让半步，几轮下来收敛到双方都能接受的折中点。往返要能走通，两个东西得事先定死。终止条件，最多几轮、最长多久，免得无限试探；回退立场，谈崩了各自退回什么保底方案，自己单干、换一家谈，还是上报人工。让步的幅度也有讲究，开头让得爽快，越往后让得越少，对方看见这个走势，自然明白快碰到底线了。它跟下一套要讲的合同网是同一家族，都不靠中央编排，靠交易式的往来把条件和资源谈拢。

分派还有一套市场化机制，叫合同网（Contract-Net Protocol）。招标者把任务公告广播到池子里，各智能体自行评估后回一份投标，写清能力、成本、预计完成时间和置信度，招标者再按效用分数把合同授出去。这套机制天生的毛病有两个，投标者不说真话，会把置信度往高了报，先把任务抢到手再说；招标这边还得干等，不设期限就无限等下去。修的办法有两条，一条给投标接收设截止时间；一条给投标者记信誉分，合同赢了却交不出好结果就扣分。信誉分的作用，正是把一次性投标改造成有记录、有后果的重复互动，与 11.3 登记库的信任信号同源。

11.5 集中训练分散执行与信用分配

这一节收理论剩下的两个问题：协作时信息怎么组织，多智能体强化学习给的答案是集中训练分散执行（Centralized Training with Decentralized Execution，CTDE）；奖励到手功劳算谁的，这道题叫信用分配。

做法是给训练和执行分别配一套信息条件。训练期大家共享集中信息，例如用所有智能体的联合观测去训一个集中式评估网络，这网络专给全局局面打分，看得见全局、评得才准。执行期反过来，每个智能体的策略（policy，从观测到动作的行为规则）只吃自己的本地观测，训完的集中评估网络当场退场，各智能体完全独立行动。

这套拆法有出处，不是拍脑袋。多智能体强化学习有个磨人的性质，叫非平稳性。每个智能体学习时把别的智能体当成环境的一部分，可别的智能体也在学，策略一直在动，于是从任一智能体的角度看，环境始终在漂，刚学到的经验转眼就过期。集中训练针对的正是这个问题。评估网络的输入是全部智能体的联合观测，同伴策略的变化它看得见、也进了输入，环境就不再是飘忽不定的了。

在深度多智能体强化学习里，这个范式尤其常见。集中式的那部分只在训练期存在，真正要部署出去的，是分散式的那部分。

这套拆法跟本书前面各章搭起的工程结构正好咬合。同一个问题在两个领域给出同构答案，不是巧合。第 10 章的监督者看得到全局状态和各工人的结论摘要，那是集中的部分；每个工人各拿独立上下文、只读自己那份系统提示，那是分散的部分。第 8 章的子智能体隔离、第 7 章的 Isolate 策略，全是执行时只靠本地信息的现成例子。集中买来准确，分散买来独立和扩展。

两边有一条共同纪律，全局信息只到中心为止。评估网络训完就退场；工程里的监督者可没法退，它得一直在线。要守住这条纪律，就得让监督者的摘要不进工人的上下文，编排层别去侵入执行层。

到了跨组织场景，这套结构还得再加上一层。企业级登记库和编排智能体，构成集中的视野；各组织的智能体，在各自内网独立执行；A2A 的名片与任务，在最外层交换刚好够用的信息。

第 9 章的升级阶梯、第 10 章的编排模式、第 11 章的协作协议，三套设计底下装着同一道题，个体理性跟集体目标的张力，拿什么化解。上一节用博弈论讲了张力打哪来，工程这边给的则是应对的办法。

另有一道题，两个领域都绕不过去，奖励到手了，功劳算谁的。强化学习管它叫信用分配（credit assignment），再往里拆，可以拆成两类。一类是时序问题，眼下这笔奖励，是过去哪些时刻的动作换来的；另一类是多智能体问题，一群智能体里，到底是谁的动作起了作用。

后一类问题，多智能体强化学习里有个觅食的例子正好讲它。在那套环境里，智能体和物品各带一个数值等级。一件物品要能收下来，得同时凑齐三个条件，一组智能体全都紧挨着它，它们同时做“收集”动作，这一组智能体的等级加起来还得够得着物品的等级。

三个智能体的摆位是，两个贴着同一件物品，第三个贴着另一件。三人同时做了“收集”动作，系统给了同一个 +1。这份 +1 是前两位挣来的，它俩贴的那件物品等级相加够格，顺利收下。第三位没使上劲，它贴的物品等级比它自己高，又没同伴搭手，收集扑了空，动作毫无效果。可学习算法眼里只有各自动作、环境状态和那个 +1，贡献根本拆不开，策略自然学不准。

训练侧的解法叫价值分解。把联合价值函数（value function，给整队一局打的总分）近似拆成各智能体价值之和，总分摊到每个人头上，集中训练阶段就把每个成员的贡献学了出来。

工程这边撞上的是同样的问题。第 10 章的编排跑完一单，交货的只有末端工人，中间谁立功、谁坏事，光凭一个总分讲不清楚。第 12 章 12.2 的轨迹树正是治这个的，子智能体的完整轨迹挂在派发节点下面，功劳和责任都能往下钻着查。评测就这样把信用分配从靠猜变成查档。除了查档，还能直接算：怀疑哪个子智能体不值开销，12.5 的反事实基线把它换成直连调用再跑一遍，两份总分一减就是净值。

这套理论在深度强化学习里有一个出了名的验证案例。2019 年，AlphaStar 头一个在《星际争霸 II》完整博弈里打到宗师水平，按游戏排名指标，排在 99.8% 的正式排名人类玩家前面。

它开局不是白纸一张。研究者先用 971,000 场匿名人类对局的公开数据做监督学习初始化，对局来自匹配评级（MMR）前 22% 的玩家；初始化完的策略，已经排在 84% 的人类玩家前面。随后进入联盟训练，32 块第三代 TPU 跑 44 天，三个种族都打到宗师。这个博弈一步约有 10^26 个可选动作，奖励要熬到数千步后的终局才发，从零探索根本不现实。

对本书更管用的是联盟训练（league training）里头的分工。联盟有三类角色，主智能体负责变强，主剥削者专挑主智能体的弱点打，联盟剥削者对联盟里所有策略找漏洞。剥削者一旦打赢，就把当时的策略冻结进联盟当陪练，自己重置回初始参数，再去找新弱点。联盟里常驻一批专攻自身弱点的对手，这思想搬到工程上就是评测里的用例策略。任务集不能只放顺手的样本，还得养一批专门打崩当前系统的用例，12.3 的对抗任务集走的就是这条路。

本章小结

• 11.1 A2A 三件套：名片（Agent Card）管认人，从 /.well-known/agent-card.json 取回，JWS 签名验真（先按 JCS 规范化，signatures 字段不参与签名；签名是可选能力，跨组织强合规场景当硬性要求）；八状态任务状态机管事，INPUT_REQUIRED 与 AUTH_REQUIRED 把等人补信息、等授权写进协议，contextId 串起多任务共享历史；多协议绑定管通路，REST、gRPC 和 JSON-RPC 三种正式绑定，选型经验是对外开放选 REST、内网高频选 gRPC、JSON-RPC 留给存量。
• 11.2 协议分界：接能力用 MCP，请帮手用 A2A，分界画在对面系统是否自主做决策，多数系统两层同时存在。两种用法，组合式编排（控制权在手、敏感字段先摘、盯中间过程）与委托式自治（整包交付、只等工件，问责问决策依据，不问内部状态）；典型事故分别是管得太细（往返叠加延迟）与放得太开（敏感字段跟着出境）。
• 11.3 注册、发现与市场：登记库是唯一权威记录，六类实体里日常用得最多的是智能体条目与策略；能力声明每个字要具体到可验证，权威源在名片与登记库之间挑一头；合规过滤挂在发布（认证工作流，有效、吊销和过期三状态）、发现（可见性与特性范围过滤，语义意图对象加能力图两步路由）、运行（权限继承接 IAM）三个环节；工具注册表同样要建；市场是登记库的查询界面，信任信号帮人拿主意。同类协议认得出就行，ANP 走 DID 去中心化，ACP 已并入 A2A，AP2 管支付（FIDO Alliance 治理）。
• 11.4 博弈论基础：囚徒困境里背叛是占优动作，个体理性把系统推向双输的纳什均衡；相关均衡解释编排为什么管用（公共信号定动作）；猎鹿博弈解释保守化倾向（各自求稳滑向风险占优）；重复博弈与以牙还牙是出路，最后一轮（合同到期、验收）罚则最松不得；合同网靠投标与信誉分把一次性交互改造成重复互动。
• 11.5 CTDE 与信用分配：训练期共享集中信息（联合观测训集中评估网络，治非平稳性），执行期只靠本地观测，共同纪律是全局信息只到中心为止；信用分配拆时序与多智能体两类，工程对应物是 12.2 轨迹树（查功劳与责任）与 12.5 反事实基线（直连对比算净值）；联盟训练养剥削者的思想，对应评测的对抗任务集。

参考资料

• A2A 协议官方规范 1.0（三层结构、Agent Card 字段与 well-known 路径、JWS 签名与 RFC 8785 规范化、Task 八状态与中断态语义、contextId、方法映射表、多租户 tenant 字段、发现机制）https://a2a-protocol.org/latest/specification/ 核实于 2026-08
• A2A 协议 1.0 发布公告（首个稳定版、多协议绑定、多租户单端点、签名 Agent Card、与 MCP 互补的官方口径、技术指导委员会八家名单）https://a2a-protocol.org/latest/announcing-1.0/ 核实于 2026-08
• Linux Foundation 新闻稿 A2A Protocol Surpasses 150 Organizations（一周年超 150 家组织、GitHub 超 2.2 万 star、接入 Google Cloud、Azure、AWS）https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year 核实于 2026-08
• RFC 7515 JSON Web Signature（JWS 结构与签名流程）、RFC 8785 JSON Canonicalization Scheme（JCS 规范化）https://datatracker.ietf.org/doc/html/rfc7515 、https://datatracker.ietf.org/doc/html/rfc8785 核实于 2026-08
• 《Designing Multi-Agent Systems》第 12 章 Protocols for Distributed Agents（分布式智能体的流式、可恢复、持久、多轮四需求，A2A 核心概念，MCP 组合式编排与 A2A 委托式自治的选型论述；该书基于 0.x 版本写成，本章所有协议细节已按 1.0 官方规范修正），见 txt-ref-zh/designing-multi-agent-systems/
• 《Agentic Mesh》第 7-9 章（登记库六实体、能力声明字段、认证生命周期与合规过滤、双边市场与信任信号；2026 年 O'Reilly 观点性内容，按观点口径引用），见 txt-ref-zh/agentic-mesh/
• 《Multi-Agent Reinforcement Learning: Foundations and Modern Approaches》（Stefano V. Albrecht、Filippos Christianos、Lukas Schäfer，MIT Press 2024；囚徒困境矩阵（数字取该书图 3.2(c)）与占优动作、纳什均衡定义与均衡选择、猎鹿博弈与风险占优均衡及学习动态漂移（图 5.6(b)，(S,S)=4,4、(H,H)=2,2）、智能体通信的不可靠条件（5.4.2）、重复博弈与 Tit-for-Tat（Axelrod 与 Hamilton 1981）、有限重复博弈的残局效应与末步动作值（3.2 与 6.3.3，末步合作 –1 对背叛 0）、训练-执行范式（书中详述 CTDE 一支）、非平稳性、时序与多智能体信用分配及觅食例子、价值分解（VDN 式求和）、AlphaStar 数字链（9.9.3：971,000 场人类对局监督初始化、对局来自 MMR 前 22% 玩家、初始策略即超 84% 人类玩家、32 块第三代 TPU 联盟训练 44 天达 99.8% 宗师、动作空间约 10^26、主智能体/主剥削者/联盟剥削者三类角色）），见 txt-ref-zh/multi-agent-rl/
• 《Agentic Architectural Patterns for Building Multi-Agent Systems》（Dr. Ali Arsanjani、Juan Pablo Bustos，2026，Packt）第 5 章（合同网市场：广播任务、投标、授标，夸大置信度的失效与投标截止时间、信誉分两道修法），见 txt-ref-zh/agentic-architectural-patterns/
• Max Gfeller《Building Agentic Applications with CrewAI and MCP》（Manning MEAP）第 4 章（整队智能体打包成 MCP 服务器的实例：执行入口暴露为单一工具、文档页做成资源、引导做成提示，宿主读资源踩点后决定何时调工具），见 txt/crewai-mcp.txt（英文原文，第 4 章，行 3000-3338）。
• 《The Claude Code Operating Model》第 4 章（团队模式四种协作拓扑：竞争假设、并行评审、模块所有、提案审批加魔鬼代言人；实验特性，口径截至 2026 年年中），见 txt/claude-code-operating-model.txt（英文原文，第 4 章，行 4122-5383）。
• Finin 等《KQML as an Agent Communication Language》（知识共享工程的智能体通信语言：言语行为式保留字消息，A2A 之前三十年的标准尝试），https://ebiquity.umbc.edu/paper/html/id/330/KQML-as-an-agent-communication-language ，核实于 2026-09。
• ANP 官网与技术白皮书 Chowdhury 等《Agent Network Protocol: Scalable and Interoperable Communication Standard for Intelligent Agents》（W3C DID 去中心化身份、did:wba 方法），https://www.agent-network-protocol.com/ 、https://arxiv.org/abs/2508.00007 ，核实于 2026-09。
• LF AI & Data 社区博客 ACP Joins Forces with A2A（IBM 2025 年 3 月发起 REST 风格的 Agent Communication Protocol、托管 Linux 基金会，2025-08-29 并入 A2A 项目），https://lfaidata.foundation/communityblog/2025/08/29/acp-joins-forces-with-a2a-under-the-linux-foundations-lf-ai-data/ ，核实于 2026-09。
• AP2 官网与 Google 官方公告（Agent Payments Protocol：Google 牵头、支付业界共建的开放支付协议，已交 FIDO Alliance 治理），https://ap2-protocol.org/ 、https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol ，核实于 2026-09。
• 《Agentic AI For Dummies》（Pam Baker，Wiley 2026）（协议版图：ANP 去中心化身份与 ACP 的 REST 路线；心智理论与递归推理的概率近似定位），见 txt/agentic-ai-for-dummies.txt（英文原文）。
• 《GenAI on Google Cloud》（Ayo Adedeji 等，O'Reilly 2026）（A2A 扩展机制按数据、画像、方法、状态机四类以 URI 声明激活；AP2 支付协议），见 txt/genai-google-cloud.txt（英文原文）。
• 《Agents and Multi-Agent Systems Development》（R. Collier 等 编，Springer 2026）（信息协议约束式协作规约：只声明消息间信息因果与完整性约束、写任何智能体之前先验证活性与安全性，工具均系研究原型；智能体间按预定规约索取结构化解释的问责机制），见 txt/agents-mas-platforms.txt（英文原文）。
• 《Agentic Architectural Patterns for Building Multi-Agent Systems》（Dr. Ali Arsanjani、Juan Pablo Bustos，2026，Packt）（智能体协商：报价-反报价往返、终止条件与回退立场；意图路由两步：语义意图对象加能力图白名单查询），见 txt-ref-zh/agentic-architectural-patterns/。
• Heiko Hotz、Sokratis Kartakis《Multimodal, Real-Time AI Agent Systems》（O'Reilly 抢先版）（工具注册表治理：工具侧的生命周期、版本、归属与审计），见 txt-ref-zh/multimodal-realtime-agents/。
• 《Multi-Agent Reinforcement Learning: Foundations and Modern Approaches》（Stefano V. Albrecht、Filippos Christianos、Lukas Schäfer，MIT Press 2024）（帕累托最优与最优响应、相关均衡与推荐装置、Hanabi 受限通信下自对局长出的惯例），见 txt-ref-zh/multi-agent-rl/。
• 《Agentic GraphRAG》（Anthony Alcaraz、Sam Julien，O'Reilly 2026 中译）（记忆一致性三档：最终、强、因果，默认因果起、升强不可逆的选型律），见 txt-ref-zh/agentic-graphrag/。