给 AI 打工下单：ERC-8183 智能体商业协议的托管与验收结构

“让 AI 代理替我去干活”正在从演示走进交易，随之而来的问题是老问题：先付款还是先交货？AI 交错了怎么办？ERC-8183（Agentic Commerce）用一个带托管的任务合约来回答：客户把钱锁进合约，代理交活，验收人点头才放款。按 ercs 仓库记录，该提案状态为 Draft，创建于 2026 年 2 月 25 日。

一个任务、四种状态、一个验收人

协议的中心对象是 job：一份带托管预算的任务。生命周期被压成四态直线：createJob 创建后处于 Open；客户经 fund 注入预算后进入 Funded，claimRefund 提供未成交退路；代理完成工作后调用 submit 进入 Submitted；最后由唯一有权判定完成的 evaluator 调用 complete 放款（PaymentReleased）或 reject 拒付，进入终态。超时路径同样被编进状态机，JobExpired 事件记录过期，过期预算经退款流程回到客户，Refunded 事件为退款留痕。getJob 把全部字段摊开可查，setBudget、setProvider、setEvaluatorFee、setPlatformFee 管理参数，beforeAction 与 afterAction 两个钩子配合白名单机制（setHookWhitelist、HookNotWhitelisted 错误）允许在动作前后挂扩展逻辑。

对 NFT 语境，这套结构可套的场景相当具体：买一张委托创作、雇一个代投研究、为链上艺术定制衍生设计——这些恰好都是”先款后货加主观验收”的交易形状。

信任被压缩到了哪一个点上

这套协议没有消灭信任，而是把它集中：验收人是全系统唯一能宣布”完成”的角色，complete 只认 evaluator，客户与代理都无法单方面宣布成功。这个设计押注的是验收环节可以外包给可信第三方（平台、仲裁人、预言机、去中心化评审），于是安全审查的重点全部转移到三处。其一，evaluator 是谁、由谁指定、失职时受什么约束——EvaluatorFeePaid 只说明它收费，不说明它可靠。其二，钩子合约的权限边界：白名单能限制注入面，但被放行的钩子代码在执行路径上有权读写任务上下文，审计要覆盖到它们。其三，平台费的抽取逻辑与 FeesTooHigh 之类的参数护栏是否真在链上生效。

验收争议的现实路径与协议的留白

四态状态机干净，但真实世界的工作纠纷很少非黑即白：代理交付了八成，验收人整单拒付合理吗？协议对此留了明显的白——标准版本里没有引入仲裁状态或分期放款，complete 与 reject 都是全有全无，争议解决被留给链下协议与钩子扩展。这意味着使用该协议谈生意时，几件事必须在创建任务前敲定：验收标准的书面定义（提交物边界、质量判据、返工程序），因为 evaluator 只按被教会的标准打分；验收人身份的提前披露与替换机制，setEvaluatorFee 之外的参数变更要盯事件，防止中途换打分人；争议兜底的链下安排，钩子函数如果实现了申诉通道，其合约代码要进审计范围。还有一个容易被忽视的时间维度：JobExpired 事件意味着预算过期可退，但过期判定用的是区块时间戳，谈排期时把它按链上时钟而非自然日核对，能避免”我以为还有三天”的扯皮。协议的留白不是缺陷，是把主观争议的复杂性推到链下的清醒取舍，代价是使用双方都要自备合同思维。反过来看，这份标准的价值恰恰在于给出一个足够小的可信内核：预算在合约里、状态在链上、判定权归属写死在函数签名里，其余一切争议都在这个内核之外协商解决，双方至少不必为“钱在谁手里”争执。

对普通用户，使用这类协议的检查动作和普通托管并无不同，只是要多问一句：验收人是不是我事前就认识、能提前查证的人；如果验收人由对方平台默认指定，那笔预算的信任成本要按”对方既干活又打分”来估，那就更接近先款后货而不是双向托管。本文为机制说明，不构成任何投资建议。