2 篇博文 含有标签「forensics」

周二，客户给支持团队发了一张截图。他们的账户显示六天前有一笔他们从未要求的退款。你的 CRO 转发了这张截图，并问了一个问题：“这是怎么产生的？”你知道是智能体（agent）干的——审计日志显示 actor: refund-agent-v3。但自那以后，提示词（prompt）已经修改了四次。由于财务部门为了追求 12% 的成本削减而更换了供应商，模型 ID 在上周四进行了轮换。系统提示词是根据三个检索到的文档生成的模板，而检索索引在周一重新进行了索引。对话历史被运行时（runtime）裁剪，以适应更小的上下文窗口。

你可以告诉 CRO 是智能体做的。你无法告诉他们为什么。这种差距——即知道发生了某个操作与能够重建导致该操作的输入之间的差距——是大多数智能体团队在工程团队之外的人提出真正的取证问题时发现的。

当 agent 在生产环境中第一次失控时——它删错了行，给错误的客户发了邮件，在单个任务上烧掉了 400 美元的推理费用，或者对受监管的用户说了法律风险极高的话——团队打开日志，却发现他们实际上拥有的是：一串参数被截断的 CloudWatch 工具调用名，一个只捕获了最新一轮对话的“用户提示词”字段，而且没有记录实际运行的是哪个模型版本。供应商在两周前滚动更新了别名。系统提示词存在于一个没有快照的配置服务中。由于框架默认值是 0.7 且“人尽皆知”，因此没有记录温度。触发错误操作的工具结果超过了日志行大小限制，并被截断为“...”。

你无法重现决策过程。你只能猜测。六个月后，你堆积了一堆无解的“它为什么这么做”的报告，团队开始像对待天气一样对待 agent——把它当作一种发生在你身上的事情，而不是你可以调试的东西。

飞行记录仪准则（Flight recorder discipline）是你为了防止这种情况所能交付的最廉价的东西，但如果你等到第一次事故发生才开始，它也将是你交付的最昂贵的东西。以下字段是最低要求，存储形式不容商量，采样和隐私边界必须同步设计，而不是事后修补。