基础协议：面向智能体社会的协调层 Foundation Protocol: A Coordination Layer for Agentic Society
面向智能体社会的图优先协调协议，统一身份、组织、价值与审计。
前置知识
Model Context Protocol (MCP)
MCP 是 Anthropic 提出的模型-工具交互协议，让 LLM 通过统一接口调用外部工具和数据源，相当于工具调用领域的 USB-C 接口。每个 MCP 服务器暴露资源、提示和工具三类原语，客户端可通过 JSON-RPC 调用。
FP 把 MCP 当作需要桥接而非替代的协议层之一，必须理解 MCP 的工具语义才能明白 FP 为什么要设计桥接 (bridge) 而非定义新工具接口。
去中心化标识符与 DIDComm
DID 是 W3C 提出的去中心化身份标识方案，实体可自生成并由 DID 文档绑定公钥、服务端点。DIDComm 则是在此之上的加密点对点消息协议，使用 DID 寻址并支持端到端加密。
FP 的实体与信任面要求可寻址、可问责的身份，但又不强制某一种身份方案，因此需要先了解 DID/DIDComm 这种自管身份的代表实现，才能体会 FP 的协议无关设计哲学。
能力发现与渐进式披露
能力发现指代理在开放网络中通过查询或广播找到具备特定技能的实体；渐进式披露则是先返回最小元数据，按需再提供完整 schema，避免一次性把大量细节塞入上下文窗口。
FP 明确把轻量元数据先发、细节按需拉取作为降低 token 开销和提升安全性的核心原则，理解这一概念对掌握 FP 与传统工具描述全量注入 prompt 模式的差异至关重要。
审计追踪与起源 (Provenance)
审计追踪记录系统行为的时间序列证据，供事后核查；起源记录则刻画哪个主体基于哪些输入与策略产生了某项决策，是合规与争议解决的基础。两者结合构成可问责性的证据骨架。
FP 把策略决策、批准、吊销都视为一等事件并写入起源记录，作者认为执行速度超过验证能力是当前自动系统的核心经济缺口，因此理解 provenance 是读懂 FP 监管面设计的钥匙。
研究动机
随着自主智能体从工具演化为代为行动的社会参与者，它们已能代用户浏览、购买、部署软件并彼此交互；瓶颈从模型能力转移到协调层面。当单一工作流需要同时调用工具 (MCP)、智能体间委派 (A2A)、可控 UI 委派 (A2UI)、身份验证 (DIDComm)、开放网络发现 (ANP) 和商业结算 (UCP) 时，每个协议各自携带身份、会话状态、权限、追踪和证据的私有语义，集成成本远不止写适配器——语义会在协议边界漂移，起源链会断裂，监督沦为日志、收据、访问控制规则和 prompt 片段的拼凑。Microsoft 安全团队把自托管智能体运行时描述为带持久权限的不可信代码执行，意味着通信层本身就是安全边界；近期对智能体协议的综述也明确指出协作、可扩展性、安全、隐私和群组交互五类缺口。这些碎片化与垂直整合的风险（少数平台端到端控制身份、策略、路由、记忆与结算）共同构成 FP 要解决的具体痛点。
本文的目标是本文提出 Foundation Protocol (FP) 的目标是为正在浮现的人机混合社会提供一个图优先 (graph-first) 的协调层，将智能体、工具、资源、人类、机构和组织统一为同一图中的可寻址节点；把关系、成员关系、会话和活动作为一等协议对象，把计量、收据与结算等经济原语以账本无关方式呈现，并把策略、起源与审计作为协议内置的一等关切。FP 的设计目标是使异构协议更易组合，同时保持身份、权限与问责在跨域运行时仍然一致可治理，使协调本身成为开放、多元、可治理的人机社会共享基础设施。
与已有工作不同的是，FP 的独特切入角度在于不替代，而是包装与桥接：它不主张推翻 MCP、A2A、A2UI、DIDComm、ANP、UCP 等已有协议，而是用一张统一的图把它们粘合起来。作者用一个经济隐喻解释——当自主执行变得便宜时，稀缺资源转向验证能力、密码学起源与责任承保，因此 FP 把核心做得极小（仅七个对象：Entity、Session、Activity、Envelope、Event、Receipt/Settlement、Provenance），把可变性推到 profiles、extensions 与 bridges 中，让现有协议生态能够增量采用。这种小核心加配置面的边界划分，与当下流行的 all-in-one agent framework 思路形成鲜明对比。
核心方法
FP 采用图原生的视角看待智能体系统：实体是节点，关系/成员/会话是边，交互是图上的活动，策略、起源与审计则是治理这些活动的证据层。这套思路直观看像把企业组织结构、合同、审计日志统一映射到同一张图，技术路线上则落地为四个并行平面加一个配置/Profile 平面：(1) 实体与信任面定义身份、能力、凭证与隐私约束；(2) 传输与路由面规定寻址、发现、信道建立与流控；(3) 交互与组织面承载消息、事件流、会话、组、角色与经济原语；(4) 监管与审计面提供策略、起源、监控、合规与争议升级；(5) 配置/Profile 平面把核心语义绑定到具体传输、身份方法、模式库与桥接器。
FP 与已有方案的本质区别在于统一实体加一等证据：传统协议通常只覆盖单一维度（MCP 管工具、A2A 管任务、UCP 管商业），FP 则把人类、智能体、工具、服务、机构、组织都抽象为同一种 Entity，并让 Session、Envelope、Provenance 这些对象在跨域调用中保持同一结构。第二个区别是渐进式披露优先于 prompt stuffing——能力描述默认只发摘要与 schema 哈希，全量 schema 与定价按需拉取，从而把 LLM 工作上下文从装下整个工具市场压缩为先选后详。第三个区别是证据即一等输出——策略评估结果、人类批准、支付 checkpoint 都写入事件流，使任何一方事后都可独立验证而不必重放执行。
方法步骤详情
FP 操作分五步：(1) 实体与信任面上 Entity 注册获 FP 地址、加密身份与 EntityCard，仅发短摘要而非完整 schema 实现渐进披露；(2) 传输与路由面通过发现钩子聚合 EntityCard，按需建立 HTTP/SSE/QUIC/IPC 等多种 profile 信道；(3) 交互与组织面发起方构造 Envelope（意图、路由/相关 ID、策略引用、最小元数据）并发起 Session，把成员、角色、预算绑定为协议对象；(4) 会话内每次 Activity 发出 typed Event，支持排序、回放、背压，计量数据按账本无关方式生成 Receipt/Settlement；(5) 监管面每个 checkpoint 产出可独立验证 Provenance，桥接器把 MCP/A2A/A2UI/DIDComm 映射为 FP Activity。整体可表达为 $\text{Activity} = f(\text{Entity}, \text{Session}, \text{Envelope})$，策略函数 $\pi(\cdot)$ 作用其上生成 Provenance。
技术新颖性
技术新颖性体现在三个层面。其一，在协议层面提出四个平面加 Profile 的边界划分，把 FP 必须强制互操作的语义（实体、会话、事件、证据）与可演化的部分（传输、身份、垂直模式、桥接器）显式解耦，避免核心膨胀。其二，在工程层面引入短摘要到按需 schema 的渐进披露范式，与传统把工具全文塞入 LLM 上下文的工作流形成对照，给出可量化的 token 节省路径。其三，在治理层面把策略 enforcement points、起源记录、争议信号都封装进协议流本身，并支持同一轨迹、不同策略多次审查，使审计可移植而无须重放交互。这种组合在 MCP、A2A、ANP 等单一职责协议中并不存在，是 FP 区别于增量修补式工作的核心贡献。
实验结果
作为白皮书，FP 没有传统实验表格，但其结果以架构边界图、能力对照表和端到端场景三种形式呈现。第一项发现是 FP 用四个平面加配置面把已有 6 种主流协议 (MCP/A2A/A2UI/DIDComm/ANP/UCP) 的关切映射到统一图上：Table 2 标注了 FP 在统一实体、一等组织、经济原语、策略审计、渐进披露五个能力上的核心覆盖 (✓) 与各现有协议的部分/间接覆盖 (◦/–)，证明 FP 差异化在于横向贯通而非纵向超越。第二项发现是 FP 的七对象词汇表（Table 3：Entity、Session、Activity、Envelope、Event、Receipt/Settlement、Provenance）足以同时表达工具调用、多智能体协作、组织工作流与商业结算而不膨胀。第三项发现来自 AI 公司场景（Table 4）：五阶段生命周期逐步激活五个平面，证明单一协议核心能复用一个 Entity 模型、一个 checkpoint 流水线、一个 Envelope 同时承载任务消息与支付收据。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 统一实体 (agent/tool/human/org) | 协议覆盖度 (✓核心 / ◦部分 / –不在范围) | FP = ✓ | MCP=◦, A2A=◦, A2UI=–, DIDComm=◦, ANP=◦, UCP=◦ | FP 是唯一在统一实体层面提供核心覆盖的协议，其余 6 个协议均仅做部分覆盖或完全不在范围。 |
| 原生组与组织结构 | 协议覆盖度 | FP = ✓ | MCP=–, A2A=◦, A2UI=–, DIDComm=–, ANP=◦, UCP=– | FP 把 Session、Group、Role、Membership 作为一等对象，其余协议仅 A2A 和 ANP 间接涉及。 |
| 经济原语 (receipt/settle/dispute) | 协议覆盖度 | FP = ✓ | MCP=–, A2A=–, A2UI=–, DIDComm=–, ANP=–, UCP=◦ | FP 是首个将计量、收据、结算、争议信号同时纳入协议核心的方案，仅 UCP 在商业范围内部分覆盖。 |
| 策略、审计、起源一等公民 | 协议覆盖度 | FP = ✓ | MCP=◦, A2A=◦, A2UI=–, DIDComm=◦, ANP=◦, UCP=◦ | FP 在所有六个对照项中唯一达成核心覆盖，强调证据与执行同源。 |
| 渐进式披露低开销 | 协议覆盖度 | FP = ✓ | MCP=◦, A2A=◦, A2UI=–, DIDComm=–, ANP=◦, UCP=◦ | FP 默认按 EntityCard 摘要交互、按需拉取 schema，其余协议无内置机制。 |
局限与改进
作者明确指出的局限是：FP 目前仍是白皮书形式，下一步需把架构翻译成精确规范和参考绑定以便生态评估、实现和迭代；附录 A 仅简述参考实现的架构与核心技术选择，缺乏 wire-format 级别细节，未公开 API、序列化方案或具体传输 profile。我自己的额外观察包括：Table 2 的能力覆盖度评估是作者自评而非社区共识，存在主观性；FP 的五阶段 AI 公司场景描述是定性 narrative，没有给出吞吐量、延迟、token 节省比例等量化指标；小核心加 profile 的边界划分虽然在原则上优雅，但 profile 之间如何避免能力碎片化、桥接器带来的语义漂移如何检测，文中未深入讨论；此外论文对去中心化身份与传统 PKI 的混部、跨组织争议解决的去信任化机制、监管面的形式化验证（model checking、策略证明）几乎未展开，留下了大量工程与理论空白。
独立分析的弱点
独立审视 FP 还有若干弱点。第一，协议核心抽象层次较高，缺少具体 wire-format、序列化 schema（如是否采用 JSON-LD、Protobuf、CBOR）、错误码、并发模型与一致性保证，实施者难以直接落地；改进方向是发布规范草案并维护 conformance test suite。第二，渐进披露仅给出短摘要到按需拉取的思路，但未量化在典型工作流中可节省多少 token；改进方向是给出最小 EntityCard 字段集与 schema 哈希机制并附基准测试。第三，监管面依赖策略钩子和 provenance 哈希，但未指明策略语言（如 Rego、OPA、Cedar）与 evidence 链结构；改进方向是引入可机读的策略描述和 verifiable credential 绑定。第四，桥接器本身的版本治理、语义漂移检测与回滚机制未被讨论；改进方向是引入 schema diff 监控与桥接器 conformance profile。第五，对延迟敏感场景下 Envelope 签名、Provenance 写入的开销未给出评估。
未来方向
作者明确的下一步是把架构转化为精确规范与一组参考绑定，让生态能够评估、实现并迭代 FP。基于成果可延伸的方向还包括：(1) 形式化核心语义，把 Entity/Session/Activity/Envelope 等对象用进程代数或类型论刻画其状态转换正确性，可用 $\delta: \text{State} \times \text{Event} \to \text{State}$ 表示，从而获得可机检的合规保证；(2) 探索与零知识证明结合，使 provenance 可在不暴露敏感负载的情况下被验证；(3) 在 Web-of-Trust、PBFT、HotStuff 等不同信任模型上 profile 化共识层，应对去中心化与半中心化部署；(4) 引入仿真基准 (FPBench)，在 AI 公司场景中量化吞吐量、token 节省、审计成本等指标；(5) 跨组织争议解决的去信任机制，如把策略决策与仲裁者身份写入 Envelope 并支持第三方仲裁；(6) 与传统监管科技 (RegTech) 集成，把 HIPAA、GDPR、SOX 等合规规则直接编译为 FP 策略。
复现评估
FP 项目仓库已在 GitHub 公开（https://github.com/FoundationAgents/foundation-protocol），代码可获取，但本文作为白皮书阶段的研究成果，可复现的内容仅限架构叙述与参考实现的高层描述，并未提供端到端实验脚本、训练数据或评测算力清单。附录 A 描述了参考实现的核心概念与关键技术选择，但缺少 wire-format、API、配置文件样例；复现难度估计中等偏高，需要实施者自行补全协议细节并搭建多智能体测试床。建议关注者：(1) 跟踪仓库的 v0.x 参考实现与 conformance suite；(2) 复现 AI 公司五阶段场景作为最小可运行 demo；(3) 与 MCP、A2A、ANP 等成熟协议做桥接兼容性测试；(4) 由于协议本身不依赖大规模 GPU 训练，复现瓶颈主要是协议工程的实现细节而非算力。
论文图表
图 1 以四列对比 Web 1.0 到 Web 4.0 的技术核心 (Tech Core)、交互模型 (Interaction Model) 与社会影响 (Social Impact)：Web 1.0 是静态文档与只读消费；Web 2.0 是用户生成内容与社交平台，伴随监控资本主义；Web 3.0 引入区块链与去中心化身份但带来复杂性与新的权力集中；Web 4.0 则是普适 AI、IoT、XR 与共生智能体，强调人机协作但同时放大偏见与代理权丧失。
这张图奠定了 FP 的历史观——每一代 Web 在提升能力的同时都暴露新的协调失败，Web 4.0 的智能体尤其把能力先于治理的张力推到极致，因此 FP 必须把问责内化进协议层。