不要让模型编写审计日志

在大多数代理堆栈中，代理所执行操作的记录是由代理本身编写的。运行摘要、队友在追踪UI中浏览的叙述性记录，都是模型输出。这段文本是对所发生事件的一种声称。它是否与实际发生的情况相符是另一个问题。两者以无聊且可预测的方式偏离。工具调用出错，模型重试两次，最终摘要却描述第一次尝试。某步骤被跳过，但叙述中仍包含它，因为摘要是根据计划编写的，而计划说它会执行。部分完成被四舍五入为已完成。这并不需要模型特别差劲。摘要有损，损失倾向于使故事连贯。问题在于谁读什么。原始工具结果是嘈杂的JSON，因此人类转而阅读叙述。这意味着保证最薄弱的层最终被装扮成权威记录，而这个版本流入状态仪表板和事后分析。修复方法主要是管道问题。运行时已经看到每个工具调用：名称、参数、原始结果、状态码、时间戳。在调用时从执行框架持久化这些数据，并将其视为日志。模型文本成为其上的注释。从响应码或外部状态检查来推导成功。模型说它成功了不能算作证据。在摘要到达任何人之前，对摘要声称的操作与运行时记录的操作进行简单的差异检查，几乎免费就能捕捉到大部分偏差。这大致是对工具名称的字符串匹配。注意事项，因为这不是万能药。运行时日志证明调用发生了。它是否在语义上做了正确的事是另一个问题——邮件确实发出去了，只是发错了列表。外部状态检查需要执行实际的调用。而且偶尔叙述正确而原始结果误导，例如幂等重试返回409，因为要创建的东西已经存在。有人会自动对比声称的操作与记录的操作吗？你在信任摘要后，抓到的最糟糕的叙述与现实差距是什么？