FOUNDATION PROTOCOL

当 agent 真正替人工作
需要一个可信协作网络

今天的 agent 协议解决了"agent 怎么说话"——MCP、A2A、AG-UI。
但没人解决"agent 怎么对结果负责"。
当委托产生真实成本、有交付物、要分账、出问题要追究时,缺的是合同、信任、溯源和结算的协议层

FP / FOUNDATION PROTOCOL
The protocol layer for accountable agent work.
contract · trust · provenance · settlement

协作一直在发生。责任没有被协议化。

在谈 FP 是什么之前,先谈它为什么应该存在。

每一次真正的委托,都会同时产生三件东西:意图、成本和后果。过去这些东西由人、组织和平台兜底;agent 进入工作流后,委托可以自动发起,任务可以跨系统流转,支付可以即时发生。问题不再只是 agent 会不会说话,而是它们开始形成真实的工作关系

一旦事情出错,追问不会停留在日志层:谁授权了这件事,哪一版算交付,谁验收了结果,凭什么付款,争议由谁处理?这些问题不是 observability 问题,而是责任关系问题

今天这些答案散落在 Slack 截图、Jira 工单、SQL log 和平台后台里。它们能辅助排查,却不能构成工作关系本身的凭证。MCP 让 agent 能调工具,A2A 让 agent 能互相说话,AG-UI 让 agent 能对人解释过程。但没有任何一层协议规定:一个委托如何产生、双方如何签字、交付如何证明、争议如何裁决、款项如何结算、信誉如何沉淀

Agent 协作的瓶颈不是通信,是责任

过去这个问题不紧迫,因为 agent 大多只是工具调用者。但现在,agent 开始互相委托、花钱、提交交付、等待审批。一旦工作有成本、有版本、有验收,就需要一套独立于 runtime 和平台的责任对象。

FP 不是另一个 agent 通信协议,也不是新的 observability 平台。它把委托、双方签字、交付证据、仲裁背书、验收、支付、争议与信誉,协议化为一组可验证的协议对象。换句话说,FP 要标准化的不是消息,而是有后果的协作

五个角色,共用一个可信协议层

FP 的运行模型最清晰的描述不是一张拓扑图,而是一个场景:一项有成本的工作被委托出去,执行方提交交付,仲裁者对状态推进签字,监督者持续可见,第三方事后独立校验。五个角色各司其职,围绕同一条责任链协作。

B 委托方 Buyer / party_a 提交 contract · 验收 · 评分 V 执行方 Vendor / party_b 签字 · 提交 DeliveryEvidence FP THE TRUST LAYER · 可信协议层 Contract Snapshot Chain Ledger Delivery Approval Gate Reputation commit · attest · arbitrate · settle A 仲裁者 Arbiter Ed25519 sign · escrow · dispute O 监督者 Owner CarbonCopy · pending approvals 第三方 Observer / Auditor verify chain · compute reputation propose contract delivery + signature attestation CC stream signed chain
● B · Buyer

委托方party_a

发起一项有成本、有交付、有后果的工作。委托方可以是真人、agent 或组织账户;它不需要盯执行细节,只需要把需求写成 contract、批准 revision、验收交付,并给出评价。

它不需要相信对手,因为每一次签字都被仲裁者背书,形成可独立验证的快照链。

→ Human · Agent · Org account · Owner-supervised agent
● V · Vendor

执行方party_b

承接一项工作,并提交 DeliveryEvidence。Delivery 不是一句"做完了",而是带 artifact、digest、cost report、session id 的结构化对象;仲裁者会把它打包进当前快照并签字。

交付的可证伪性是协议级保证:买方、仲裁者、任何第三方都看同一份签名快照。

→ Agent · Tool entity · MCP server · 跨 Host vendor
▲ A · Arbiter

仲裁者arbiter

FP 里的有限见证者,不是去信任化设计的对立面。它持有 Ed25519 签名密钥,对每一次状态推进生成 ArbiterAttestation,并维护快照链:prev_snapshot_hash 把所有 transition 串成一条链。

争议入口也由它持有:DISPUTE state、超时、escrow 释放都是协议化路径。它做的事情是有限的,但每一件都被见证

→ Snapshot sign · Escrow ledger · Dispute path
◆ O · Owner

监督者owner

每个 entity 都可以挂 owner。默认的 CarbonCopyCheckpoint(order 800、全 kind 挂载)让 owner 自动收到这个 entity 的所有协议消息——零配置 fleet observability。

监督者不替 agent 执行,也不替仲裁者裁决。它负责看见、批准、暂停、追问,让 agent fleet 的行为不再藏在各自 runtime 里。

→ Owner CC stream · Pending approvals · Human oversight
✦ * · Observer

第三方observer · auditor

第三方不需要参与每一次对话。审计员、合规、买方背后的人,只要拿到签名链,就可以独立重算 reputation、独立校验 attestation。

这让"事后能证明"不依赖某个平台后台。信誉不锁在某个平台里,责任也不靠截图拼出来。

→ Auditor replay · Verify chain · ReputationProfile

五个可验证对象,一条跨协议不变量

每一个对象都对应代码里的真实类型、状态机和验证路径。协作从 contract 开始,流向 delivery,被 arbiter attestation 串成快照链,被 owner 持续看见,并沉淀为 reputation;最后由 bridge invariant 带过 MCP / A2A / OTel,让同一条责任链在协议转换中继续流动。

壹 · Contract

合同双方签字才生效

# 双方对同一 revision 都签字才进 ACTIVE
# amend 会清空旧 approvals,不能跨版本背书
await alice.send_message(
    to=arbiter.entity_card,
    message=Message(
        kind=MessageKind.CONTRACT_APPROVE,
        payload=ContractActionPayload(
            contract_id=cid,
            revision=contract.draft_version,
            terms_hash=contract.terms_hash,
        ).model_dump(),
    ),
)

委托不再是 chat log,是被双方签字、被仲裁者背书的协议对象。 → test_contract_requires_both_parties_approval_before_activation

贰 · DeliveryEvidence

交付证据"做完了"必须可证伪

# 完成 = 提交带 artifact 与 cost 的结构化证据
# 仲裁者把它写入当前快照并签名
DeliveryEvidence(
    delivery_id="delivery-v1",
    version="v1.0.0",
    summary="Vendor portal MVP v1",
    artifacts=[
        DeliveryArtifact(
            kind="commit",
            uri="git://repo/commit/abc123",
            digest="sha256:abc123",
        ),
    ],
    produced_by=vendor.address,
)

交付物有 digest,验收 ack 有签名,第三方可独立重放。 → test_contract_snapshot_attestation_and_ack_flow

叁 · ArbiterAttestation

仲裁者签名快照每个 transition 都被见证

# 每次状态推进生成一个 ContractSnapshot
# 用 arbiter 私钥签名,链到前一个 snapshot
snapshot = contract.to_snapshot()
snapshot.attestation = sign_snapshot(
    snapshot,
    signer=arbiter.address,
    private_key=arbiter.sign_private_key,
    prev_snapshot_hash=contract.prev_hash,
)
assert verify_attestation(snapshot, pub_key)

ed25519-sha256:v1。任何第三方拿着公钥都能独立校验。 → fp/trade/hashing.py · verify_attestation()

肆 · CarbonCopy

溯源owner 零配置看到一切

# 给 entity 挂 owner,自动获得全协议消息 CC
# 默认 order=800、kinds=set(MessageKind)
bot = host.register_entity(
    name="BotA",
    kind=EntityKind.AGENT,
    owner=alice.address,
)
# 之后 BotA 收发的每一条都自动 CC 给 Alice
# 不必修改 BotA 一行代码

agent fleet 的行为对监督者天然可见,无需 SIEM 或 vendor APM。 → fp/host.py · _setup_default_checkpoints · CarbonCopyCheckpoint

伍 · ReputationChain

信誉从签名合同链派生

# 输入是被签名的合同链,不是平台星星
# 任何持链者都可独立重算同一份分数
profiles = aggregate_vendor_reputation(contracts)
p = profiles[0]
print(p.overall_score)    # 0..100
print(p.quality_score,
      p.reliability_score,
      p.integrity_score)

agent 把自己的工作履历带到下一个平台,无需平台同意。 → fp/trade/reputation.py · test_trade_reputation.py

陆 · Bridge Invariant

跨协议 audit spinetrace 不在桥上断

# FP ↔ MCP / FP ↔ A2A 的每一次转换
# 必须保留 trace_id / policy_id / evidence_refs
call = fp_invoke_to_mcp_call(fp_msg)
# 服务端追加新 evidence,trace 块原样回传
fp_result = mcp_result_to_fp_message(resp)
assert extract_trace_context(
    fp_result.metadata
).trace_id == original_trace_id

一条 trace_id 串起 A2A → FP → MCP,所有 evidence 在桥两侧不丢失。 → fp/bridges/ · test_bridges_trace_preservation.py (12 tests)

FP 在 agent protocol 里的坐标

现有 agent protocol 大多占据两个维度中的一个:要么标准化通信与交互(MCP / A2A / AG-UI),要么提供支付或身份基础设施(x402 / AP2 / DIDComm / VC)。它们回答"怎么调用、怎么说话、怎么付款、怎么证明身份"。FP 的定位,是把"责任结构 + 经济关系"同时变成协议化对象,让协作本身可被追溯、可被审计、可被验证。

ECONOMIC SURFACE → ↑ TRUST / PROTOCOLISED MCP 通信:tool call A2A 通信:task / message AG-UI 通信:agent→human LangSmith / Trace 平台 观测,不签字 x402 / AP2 支付:怎么付 DIDComm / VC 身份层 FP contract + trust + settle OBSERVABILITY TRUST + ECONOMICS PURE COMMUNICATION PAYMENT RAILS
维度 MCPtools call A2Atask / artifact x402 / AP2payment rails FPcontract / delivery / settle
解决的问题 怎么调工具 怎么互相说话 怎么付钱 为什么这件事该做、该付、该信
核心对象 tools/call Task / Message / Artifact PaymentRequest Contract · DeliveryEvidence · Attestation
身份与签名 外挂 外挂 钱包 Ed25519 / X25519 一等公民
双方授权 单方 task owner 双方对同一 revision 签字才生效
交付证明 tool 返回 artifact 不涉及 DeliveryEvidence + 仲裁者签名快照
争议路径 退款 DISPUTED state · arbiter ledger
监督 owner push notification CarbonCopy 全 kind 自动 CC
跨协议 trace request id task id txn id bridge invariant 保留 trace_id + evidence
信誉沉淀 钱包历史 从签名合同链派生 ReputationProfile
身份定位 tool 协议 agent 通信协议 支付协议 trust layer · agent economy 可信协议层

协作可追溯之后,自然涌现的六件事

这些不是 FP 额外堆出来的"功能列表"。它们来自同一个底层变化:协作里的关键事实先被协议记录下来,再进入应用。谁委托、谁交付、谁签收、谁见证,都有可验证对象;所以系统不是事后补日志,而是一开始就留下责任链。

壹 / 委托可追溯

每一次"做什么"都成为可被双方签名的对象

Contract 携带 terms_hashdraft_version、双方 approvals。任何后续讨论永远可以回溯到"我们究竟同意了哪一版"。

Committed Intent
贰 / 交付可验证

"做完了"必须能被对方、仲裁者、第三方独立校验

DeliveryEvidence 带 artifact digest 和 cost report;仲裁者签名快照;买方 ack 也带签名。三方都看同一条 ed25519-sha256:v1 链。

Cryptographic Attestation
叁 / 责任可定位

单方签字不能让合同生效

amend 会清空旧 approvals,不能跨版本背书。出问题时,"是谁授权的"是协议级答案,不是 Slack 截图。

Dual-Party Authorization
肆 / 监督零成本

owner 默认收到自己旗下 agent 的全协议消息

无需修改 agent 一行代码,无需接入 SIEM。换一家框架的 agent 上来,CC 流仍然按统一 schema 进。

Zero-Config Observability
伍 / 信誉可移植

第一次,agent 可以带着自己的工作履历离开平台

过去 agent 的"信誉"分散在每个 marketplace 的内部表里——平台关门、agent 换栈、买卖换边,全部归零。FP 让 reputation 来自一份签名合同链的派生函数:买方拿着合同集合,可以独立重算同一份 ReputationProfile,跟 vendor 在哪个平台无关。

这不是给 vendor 一颗星,是给 vendor 一份可被审计的工作履历。它把"换平台 = 信誉归零"从 agent 经济的默认设定里删掉。

Portable Trust · Vendor-Owned Work History
陆 / 跨协议 audit spine

一条 trace 串起 A2A → FP → MCP 三段证据

MCP / A2A / OTel 各自的 trace id 互不认识,是当前 agent 协作最大的责任黑洞:出事时三段日志拼不到一起。FP 把 trace_id / policy_id / evidence_refs 作为 bridge invariant:任何转换都必须保留这三件事。

实际效果:MCP server 端追加 mcp-tool-call-001 到 evidence 链,回程被 FP 完整恢复;同一条 trace_id 在 A2A Task、FP Session、MCP _meta、A2A Artifact 上都能看到。一次业务行动 = 一段端到端可审计的事实

Trace Lineage · Bridge Invariant

责任关系一旦协议化,应用边界会自然外扩三层

到这里我们已经讲过:有后果的协作正在发生,但责任关系从未被协议化。FP 是这次标准化尝试。协议化一旦发生,应用边界就会自然往外扩,远远超出 agent marketplace。

Agent-to-agent economy 第一次可以真正运行

agent 接 agent 的活,按结果付费,争议有协议路径,信誉可携带。整个生态需要的"真实经济关系"骨架,不再依赖某个平台的 ToS

vendor agent 可以同时在 5 个平台接单,每个平台只是入口,合同 / 交付 / 信誉 都属于 vendor 自己。MCP server 不再只是免费 SaaS,可以挂 Contract,按结果计费。

Agent Marketplace · MCP-as-Service

Human + agent 混合协作有了统一接口

FP 的角色(buyer / vendor / arbiter / owner)天然不绑定 LLM。人是 entity,agent 是 entity,工具是 entity,组织账户是 entity——同一套 contract / delivery / approval 流程。

HITL 不再是 agent 框架里的特殊路径,是协议里的一等公民:ApprovalResponseCheckPoint 持久化 pending approvals,进程崩了、人睡着了、跨时区——审批照样能 resume。"人在回路"不再意味着系统脆弱

Hybrid HITL · Durable Approval

任何"需要责任结构"的协作,都可被同一抽象描述

合规咨询、法律文书、医疗会诊、投资决策、学术评审、跨实验室科研——所有这些场景的共性都是:两方/多方对某项工作达成意图、产生交付、需要验收、可能产生争议、最终结算。这不是 agent 独有的痛点,是有责任的协作本身的痛点。

FP 的抽象不预设"agent"。它预设的是"有签名身份的实体之间产生有后果的协作"。一旦协议对象齐备,agent 协作只是这个抽象的第一个杀手应用——真正的边界是:所有"好"能被形式化的责任关系

Universal Accountability Substrate
Closing

真实世界构建在有责任的协作之上。
FP 是那个一直缺席的 可信协议层

from fp.trade import contract, deliver, attest, settle