当 AI Agent 开始代表用户执行真实动作——提交代码、发布文章、调用 API，甚至发送邮件或转账——一个现实问题随之出现：如果进程中途崩溃，谁来证明它做了什么？一次失败教训显示，依赖 Agent 自己生成的运行总结并不可靠，工程团队需要把“意图”和“结果”分开记录，并让日志先于动作落盘。
一次夜间任务暴露出的证据链缺口
素材中的案例来自一次自动化发布任务：系统原本计划在夜间让 Agent 自动撰写并提交三篇文章，但运行到第 70 分钟时连接中断，远端进程随之终止。第二天检查时，开发者只在仓库里看到一个未跟踪的 Markdown 文件：没有提交记录，没有运行日志，也没有任何证据表明任务曾正式启动。文件本身包含 3141 个单词，看起来像是过去 6 小时内某个时刻生成，但无法证明它是什么时候、为什么、以什么流程产生的。
问题不在于连接断开，而在于整个证据链都存在于 Agent 自己的进程里。进程一旦死亡，关于任务为何启动、拒绝了哪些选题、是否尝试过其余文章的线索也随之消失。开发者只能从最终产物倒推过程，这相当于让“被告”自己写证词。此后，流程被改为：运行日志必须在任务开始时就打开，而不是等到结束时补写。
意图与结果必须分开记录
文章将 Agent 日志分成两类，认为混淆二者是审计链失效的常见原因。第一类是意图（Intent）：Agent 决定做什么、为什么这么做、考虑并放弃了哪些动作，以及它明确拒绝执行了什么。第二类是结果（Effect）：动作真正发生后留下的客观痕迹，例如 commit SHA、API 响应、落盘文件、数据库插入记录或资金变动。
两者缺一不可。只记录意图，日志只是一份计划；只记录结果，则无法解释结果从何而来。更关键的是，二者需要通过稳定标识符关联起来。文章建议生成一个 Run ID，可以是 UUID，也可以是 timestamp-slug，在 Agent 执行任何动作前写入磁盘，后续所有日志行和 commit message 都应带上这个 ID。这样即使任务最终完成、崩溃、被人工终止，或被上游 API 限流，仍可以围绕同一个 ID 还原上下文。
这种分离可以帮助排障时快速判断故障类型：Agent 是否已经决定行动但尚未执行就崩溃，可以安全重试；是否决定行动并只完成了一部分，需要人工介入；或者是否已经执行动作但未来得及记录，后者风险最高，因为下一次运行可能重复执行同一操作。
为什么不能只相信 Agent 的运行总结
文章认为，Agent 自己生成的执行摘要不适合作为主要审计证据，原因有三。首先，摘要由被审计对象自己撰写，属于“既当运动员又当裁判”。其次，摘要来自同一个进程内部：如果进程在摘要写入前终止，就没有摘要；如果进程在摘要写入后、真实结果落地前终止，摘要可能报告了一个并未发生的结果。第三，模型本身被训练为生成连贯叙述，会自动填补空白，让解释看起来完整。这并非故意撒谎，但当工程团队需要知道“到底发生了什么”时，流畅解释并不是可靠证据。
由此得出的原则是：结果要从 Agent 外部记录，例如来自版本控制系统、API 网关、数据库或文件系统的事件；意图可以从 Agent 内部记录，但不能让 Agent 成为自身行为的唯一证人。
面向小团队的“最小可用日志”思路
文章提到，合规指南往往会要求包含政策指针、租户 ID、GDPR 保留标记和复杂分类的多层日志结构。如果是在银行等强监管环境，应遵循这些规范。但对独立开发者或小团队而言，更需要一份更短、更容易坚持执行的清单。素材给出的第一项字段就是 Run ID：在运行开始时生成并先落盘，后续所有记录都要携带它。
这一思路的核心不是字段越多越好，而是保证日志在故障发生时仍有解释力。当 AI Agent 被授权写入 Git 仓库、操作生产站点、代表用户发送邮件或触发支付动作时，日志系统需要回答三个问题：它想做什么、它实际做成了什么、两者如何对应。对生产环境来说，这不是可选的工程细节，而是把自动化从“黑箱执行”变成“可追责操作”的基础设施。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/gei-ai-dai-li-bu-shang-xing-che-ji-lu-yi-sheng-chan-huan
