ERC-8001 智能体协调框架：多个 AI 代理要在链上合办一件事时怎么签字

一个交易机器人想开杠杆仓位，按风控要求必须同时获得风险管理代理和资金调度代理的同意；几个平台的结算代理需要在同一批交易里完成分账。这类”多个程序各代表一方，必须凑齐一致意见才能动手”的场景，靠人拉群确认显然跟不上速度。ERC-8001 给出的答案是把这些意向和同意标准化：提案、签署接受、达到票数、原子执行，全部走同一套合约接口。按照以太坊 ercs 仓库的记录，这份提案名为 Agent Coordination Framework，状态为 Final，创建于 2025 年 8 月 2 日。

一份意向先变成一个哈希

流程从 proposeCoordination 开始：发起方提交一份 AgentIntent（结构化意向，包含参与者列表、协调类型和执行参数）以及自己的 EIP-712 签名，合约返回一个 intentHash。此后所有围绕这件事的接受、取消、执行，都以这个哈希为索引。CoordinationProposed 事件记录发起者、参与者数量与协调值，旁观者从事件日志就能看到桌上有什么提案在等人签字。把意向压成哈希的意义和文档指纹一样：任何一方签字之后，其他方都没办法偷偷改动条款——改一个字，哈希就对不上。

接受证明是一张带名字的收据

参与者调用 acceptCoordination(bytes32 intentHash, AcceptanceAttestation calldata attestation) 表达同意，其中的 AcceptanceAttestation 是一份签名化的接受证明，链下生成、链上验证。每收到一份，CoordinationAccepted 事件就把当前已接受人数和所需人数一起写进日志，getRequiredAcceptances(intentHash) 则让任何人查询门槛票数。凑齐之前，这件事可以按规则走到 CoordinationCancelled；凑齐之后，任何人调用 executeCoordination 提交载荷，合约在单笔交易里完成全部约定动作，成败与消耗记录在 CoordinationExecuted 事件。getCoordinationStatus 把状态机摊开给人查：谁发起、谁已签、何时过期，一次只读调用全部可见。

和 Safe 多签是同一件事吗

机制上高度相似——都是多方同意凑齐后执行，差别在签字方是谁。传统多签预设签字的是人，操作界面是网页审批队列；ERC-8001 的签字方是程序，接口设计（结构化意向、类型化签名、过期字段）都围绕机器读写优化，并且引入 getAgentNonce(address agent) 为每个智能体维护独立的操作计数，防止某个代理的旧签名被重放。它没有取代多签，更像把多签的协调语义翻译成了智能体之间能直接对话的方言。

看一个协调合约时的三个检查点

为什么这类标准偏偏在智能体时代冒出来

人签多签，慢一点无所谓，因为人本身就在做风险判断；智能体协作慢一秒就可能错过整个窗口，但智能体没有常识，把人的共识环节直接删掉又太危险。协调类标准填的就是这个空档：把共识的达成从聊天软件搬进可验证的链上流程，让速度回到机器一侧，让证据留在审计一侧。回头看 ERC-8001 的字段设计——接受证明是链下生成链上验证的，省掉多轮确认交易；票数凑齐前一切都可以低成本取消；执行只发生一次且有唯一执行记录——每一条都在给程序化决策补人类流程里免费拥有的东西：缓冲、核对与事后追责。理解了这层对应关系，就能准确评估任何智能体协作产品：问它把共识存在哪、能否用只读调用数出已同意的一方，两个问题都有肯定答案才配得上去中心化这个说法。

一是查过期：从 getCoordinationStatus 返回的 expiry 字段确认意向有没有时限，无时限的协调队列可能积累陈旧意向。二是查门槛：getRequiredAcceptances 与参与者名单是否匹配，如果所需票数长期是一票而参与者很多，等于单点否决缺失。三是查执行者：executeCoordination 允许任何人触发执行是设计使然，但用户应理解凑齐票数后动作必然发生，不接受的一方合法的路径是在凑齐之前走完取消流程，而不是执行之后再争议。按 ercs 仓库口径该提案为 Final，代表规范冻结而非全市场部署，接入前仍需核对目标合约是否真的实现了这套接口。本文为机制说明，不构成任何投资建议。