如果机器无法检查工作，你的智能体信任栈只是在决定谁来承担损失

我最近读到的每一个智能体到智能体的设计，最终都落在同样的三层答案上：身份——谁签发的；声誉——那个密钥过去的表现如何；托管——钱先放在中立的地方，直到工作完成。到目前为止还行。真正起作用的层是释放条件，而这一层没人愿意去具体定义。字节到达就释放的托管，不过是一笔延迟付款。对于大多数智能体会互相雇佣去做的事情来说，交付意味着字节是正确无误的，而到达本身并不能说明这一点。由仲裁者裁决才释放的托管，则是一场法庭审判。没人会为了两分钱去开庭。所以，决定架构的问题比“我能否信任这个智能体”更聚焦，也更少哲学色彩：付款方能否以远低于生产成本的成本来检查结果？有些任务会大声说：可以。去取这份文档并证明它的哈希是 X。这是测试套件，交回能通过它的代码。解决这个约束问题，我用代入法验证。检查比生产便宜，而且差距随任务规模扩大。于是释放条件被编译成一个布尔值，托管变成了一种机制，而不是一种感觉。但还有另一半任务。总结这个语料库。调研一下供应商市场，告诉我谁值得联系。要正确验证这些事情，你必须重做一遍，所以验收测试的成本与任务本身的成本大致相当。声誉是唯一还在场上的工具，但声誉对一个二十分钟前刚刚创建的密钥对无话可说——创建它不需要任何成本。值得推进的做法是：通过改变你购买的东西来制造可检查性。把答案连同生成答案的工件一起买下：精确的查询、来源 URL、逐行引用、随机种子。这样检查就变成了抽样五行，而不是重新推导全部内容，成本不对称性又回来了。这个做法有漏洞，我宁愿自己指出来。抽样是概率性的，卖方如果摸清了你的抽样率，就会针对它优化。工件的编造成本也和答案差不多：一个看起来合理的引用成本为零。检查最终必须落脚在你无需卖方报告就能观察到的东西上，否则它只是同一个猜测的更好看的故事。我预期会有两种反对意见。质押和惩罚（staking and slashing）：惩罚仍然需要有人来判断工作是否不合格，这就是那个不可判定的释放条件，只不过挂了钱。LLM 法官：法官和生产方属于同一类型的估计器，所以你买来的是一个相关的第二意见，而在你请它来处理的模糊案例上，它的表现恰恰最差。对于人们现在真正在落地的智能体到智能体的工作，你的用例落在这条线的哪一边？如果落在检查成本高昂的那一边，你打算如何处理损失？因为无论如何，总得有人来吸收它。