给我看收据：为智能体工作留下不可变痕迹的理由

我们仍然无法真正信任我们的智能体。我们乐于让它们起草、总结、研究和提出建议，但远不愿意让它们在没有人工核查的情况下转移资金、批准操作、更改核心数据或推进工作。工作越重要，我们就越可能让人重新介入其中。

即使智能体产出了不错的结果，我们往往也缺乏有效手段来了解它依赖了什么、完成了哪些中间步骤、是否跳过了关键环节，或者另一个智能体应如何安全地从它停下的地方继续。

如果我们想让智能体承担更重要的工作，就需要更好的证据来证明工作确实完成了。换句话说，我们需要智能体在工作过程中留下收据。

一张收据应当告诉我们：智能体产出了什么、产出时掌握了哪些信息、结果依赖了哪些先前的工作。更重要的是，系统应当要求这些收据作为完成工作的一部分，而不是事后重建。

这不仅仅是审计功能或可观测性。因为最妙的是：这种让我们事后放心的结构，从一开始就能塑造智能体的工作方式。要实现这一点，我们需要对软件产品历来大多隐而不显的东西进行建模——即工作本身。

为智能体行为建模

产品已有描述其世界的数据模型。销售产品包含账户、联系人、商机、活动和合同。金融平台则涵盖账户、交易、持仓、转账和审批。

这些是产品原语。智能体围绕它们产生另一层数据。它们调查问题、收集证据、形成假设、做出评估、比较备选方案、提出行动建议、审查先前结论并请求批准。这些是工作原语。

从历史上看，这类活动多发生在人的脑海中、会议之间，或产品核心数据模型之外的文档里。智能体使缺失的这一层变得尤为明显，因为它们的中间工作已是数字化形式。我们往往只是将其留在上下文窗口、转录记录、临时文件或生成的文本块中。

其中一些工作应成为一等数据。调查可以有类型，发现、假设、证据评估、建议、审查或决策同样如此。每一项都可以有明确的形态，并与周围工作建立显式关系。

这与我们习惯的数据建模不同。我们不仅对业务中的对象建模，还要对围绕它们发生的工作进行建模。

打字即一切（大体上）

类型化工件之所以重要，是因为收据需要有意义。仅仅让代理留下一堆文档或文本块是不够的。产品需要知道每个工件代表何种工作、应包含什么内容，以及它与其他工作的关联。

例如，如果代理正在调查客户可能流失的原因，那么有用的工作可能包括证据、假设、评估，最终还有建议。为这些工件赋予类型，意味着产品能够区分它们，并定义每个工件需要包含的内容。

这使得收据更加可信。我们不仅知道代理产生了一些输出，还知道这些输出代表什么，并能验证它是否包含产品所期望的内容。类型还为我们提供了一种定义工作之间关系的方式，而不是事后试图从散文中恢复这些关系。

将工作模型暴露给代理

创建工件只是其中一半。代理应该能够理解你的产品支持的工件类型、它们包含的字段、它们之间的关系，以及当前任务中已存在的内容。

如果产品有风险评估的概念，代理应该知道它是什么。如果某个操作需要审批，这种关系应该是可见的。如果调查发现了尚未解决的冲突证据，代理应该能够查询到这一点，而不是从记录中重新发现。

现在，数据模型开始影响代理的工作方式。你不必规定每一步。代理仍然可以决定检查哪些来源、调用哪些工具、哪些证据重要、是否修改其评估，以及多少调查才算足够。

但现在，产品有了描述有意义进展的词汇。不再是在提示词里写“先收集充分证据，获得批准后再行动”，然后指望模型照做，系统可以将证据、评估、决策和批准作为独立对象，供代理检查和创建。

代理在如何完成工作上有自由，但不能重新定义完成工作的标准。

别让代理跳过工作

下一步是强制执行其中一些关系。如果建议应基于评估，产品就不应接受未引用任何评估的建议。如果评估需要证据，则在撰写评估时要求引用这些证据。

代理可以广泛搜索、追踪意外线索、放弃薄弱假设，或向另一个代理求助。但当它想把工作转化为产品认可的评估或建议时，就必须满足产品定义的结构。

这与在提示词或技能中解释某事并希望它奏效完全不同，因为它改变了完成的含义。代理说“我完成了调查”是薄弱的证据。系统显示预期工件存在且具有所需关系，则有力得多。

代理不能仅仅因为自己认为信息足够，就从调查直接跳到行动。它被迫在每一步都产出凭证，并留下这条轨迹。

重要的是，我们不必信任代理记住流程，因为部分流程存在于代理之外。

让工件不可变

要使其成为可靠的记录，工件必须不可变。一旦代理撰写了评估，不要让它日后悄悄重写该评估。如果新证据改变了结论，应创建新版本并保留旧版本。

假设代理最初得出结论，某客户流失风险较高。两天后，新的使用数据显示另一部门有大规模部署。代理将评估从高风险修正为中等风险。

这应产生第二份评估，而非修改第一份。这样我们就能知道代理在新信息到达前的看法、之后的看法，以及促使其改变的原因。

产品在常规界面中仍可仅展示最新评估。在其之下，先前版本保持完整。同样的规则适用于其他代理提出异议、人类更改结论，或审查后修订建议的情况。

收据应显示手头所有

不可变性直接促成了我认为这一切中最重要的部分：当代理撰写新工件时，要求其指明用于生成该工件的上游工件。并且需要具体到所使用的确切版本。

假设代理基于客户快照、使用分析、支持摘要及一组先前识别的风险信号创建账户风险评估。这些不应仅作为生成文本中的模糊引用出现。

评估应包含对这些确切工件的实际引用。它们可能是ID、密钥、哈希或外键式关系。系统精确记录代理在创建下游工件时声称手头拥有的上游工件。

该工件现在既记录了评估结果，也记录了形成评估所依据的工作。由于上游工件是不可变的，我们可以在之后检索到确切的版本。如果后续使用分析发生变化，原始评估仍指向当时存在的分析。这就是凭证。

凭证自然形成一张图

随着代理创建更多工件，这些关系便构成了一张工作图。一个代理可能在生成五个值得保留的工件时，进行数十次模型调用和数百次工具调用。工件图记录了值得保留的工作。

一项推荐可能依赖于一项评估。该评估可能依赖于若干证据片段和一个假设。这些证据片段可能源自源数据或早期分析。后续审查可能会引用该推荐，而修订后的评估则同时引用之前的评估和导致其变化的新证据。

日志和追踪对于调试和可观测性仍然重要，但它们回答的是不同的问题。追踪告诉你代理做了什么。工作图告诉你它确立了什么，以及这些工作基于什么。对于重要工作而言，这更接近我们真正想了解的内容。

副作用：延续与协作

一旦工作有了持久化的模型，另一个代理无需继承原始代理的全部上下文即可继续。它可以检查当前的调查进展，查看已收集的证据，阅读最新的评估，注意到早期假设已被取代，并从此处继续。

同样的理念也让代理间的协作变得更加清晰。如果两个代理共享同一个工作模型，它们无需拥有相同的上下文窗口。一个代理可以产出证据，另一个可以评估，第三个可以审查最终建议。交接通过工件完成。

代理还可以查询仍需关注的工作，因为你的工作模型可以包含工作队列或待办事项。换句话说，工作模型既能回顾过去，也能展望未来。它告诉下一个代理已经发生了什么，并为其提供理解剩余任务的方式。

如果你愿意，可以称之为治理

如果某项特定策略被要求执行，你可以查看引用了哪个版本。如果人类审阅了决策，该审阅可以成为同一图谱的一部分。如果新证据后来改变了结论，这一历史会被保留，而不是消失在更新后的记录背后。

你还可以反向遍历图谱。如果上游工件后来被发现是错误的，你可以识别出依赖它的评估，以及依赖这些评估的建议。

这与在问题发生后从大量提示和工具日志中重建审计追踪截然不同。审计追踪之所以存在，是因为代理在工作过程中必须创建它。

而这又回到了信任的话题。当我们对代理留下的工作及其推进前必须满足的条件有更强保证时，我们可以给予它更多自由。

如果我们希望智能体承担更多责任，就需要有系统让我们在不逐帧监视其每一步的情况下验证其工作成果。

当智能体声称工作已完成时，要求查看凭证。