大家好，我是金全。

AI 写代码，已经不是什么新鲜事。

真正的变化是，Coding Agent 不再只生成一段代码，而是开始读文件、执行命令、运行测试，甚至提交 PR。

当这些代码进入生产系统，企业就会遇到一个过去不太需要回答的问题：

这段代码，到底是怎样形成的？

比如，一段由 Coding Agent 修改的代码上线以后，生产环境出现了异常。

回头看 Git，记录很完整。

改了哪些文件。

哪一行发生了变化。

什么时候提交。

经过了谁的评审。

最后合并进了哪个版本。

这些都能查到。

但企业真正开始调查时，还是会遇到一组新的问题：

Coding Agent 为什么修改这里？

它为什么没有检查另一个文件？

执行过哪些命令？

哪些测试失败过？

人工中途修改过什么要求？

Git 能够告诉我们代码最后改成了什么。

但这段代码是怎样一步一步形成的，

很多时候并没有被完整记录。

这并不是 Git 的问题。

Git 已经很好地完成了版本控制的职责。

真正发生变化的是：

Coding Agent 没有改变 Git 的职责。

它改变的是：企业需要围绕一次编码行为，把原本分散的任务、操作、验证和代码结果重新关联起来。

过去，一个开发者接到任务以后，会阅读代码、判断修改位置、执行命令、调试问题、运行测试，最后提交代码。

Git 记录最终改动。

Issue 记录任务。

CI 记录构建和测试。

Code Review 记录评审意见。

发布系统记录代码进入了哪个环境。

这些记录一直都在。

但过去的软件工程隐含了一个前提：

开发者能够对自己的修改作出说明。

为什么读了这些文件。

为什么选择这种实现。

为什么执行这条命令。

为什么认为测试已经足够。

这些判断未必都写进系统，

但通常可以找到当时的开发者继续追问。

Coding Agent 出现以后，这个前提开始发生变化。

Agent 可以独立搜索代码、读取文件、调用工具、修改程序、运行测试，甚至创建 Commit 和 PR。

它完成的不再只是一次代码生成。

而是一段真实的软件工程工作。

这段工作如果没有留下可核对的运行事实，事后再让模型解释，很容易得到一个听起来合理的答案。

但能说得通，不等于当时就是这样发生的。

所以，Coding Agent 的工作过程开始需要由系统记录下来。

以“修复登录接口偶发超时”为例。

Agent 可能先搜索认证模块，

阅读接口实现和配置文件。

它发现一段重试逻辑，判断超时可能与重试次数有关，于是修改配置并运行测试。

第一次测试失败。

它继续检查调用方，调整另一处代码，再次运行测试。

中途，开发者发现它准备修改公共接口，于是补充要求：

不要改变现有接口，只在认证模块内部处理。

Agent 随后改变方案，完成修改，测试通过，最终提交代码。

在 Git 里，企业看到的可能只是最后三个文件的 Diff。

但一次完整的编码行为，还包括：

• 最初接到的任务；

• 搜索和阅读过哪些文件；

• 执行过哪些命令；

• 中间尝试过哪些方案；

• 哪些测试失败过；

• 人工在什么位置改变了要求；

• 最终怎样形成这次提交。

这些信息可能分别存在于 Issue、Agent Session、终端日志、测试报告、Code Review 和 Git 记录里。

问题往往不是完全没有记录。

而是这些记录没有围绕同一次编码行为关联起来。

第 14 篇里，我提出：

AI 可观测性的观察对象，不再只是一条 Trace，而应该是一次业务行为。

放到 Coding Agent 场景里，这个观察对象就是一次编码行为。

它从任务被交给 Agent 开始，经过代码搜索、文件读取、方案选择、命令执行、代码修改、测试验证和人工介入，直到形成可以评审、合并或者发布的结果。

要还原这次编码行为，我认为至少要把四类事实关联起来。

第一：任务和边界

要留下 Agent 最初接到的任务，允许修改的仓库、分支和文件，以及它能否直接修改代码、执行命令和创建 PR。

如果人工中途改变了要求，也要记录下来。否则，企业无法判断哪些动作属于任务范围，哪些已经越过边界。

第二：实际操作

要记录 Agent 搜索、读取和修改过哪些文件，执行过哪些命令和工具，是否访问外部网络、下载依赖或者调用其他 Agent。

Git 能看到最终保留下来的代码改动。

行为链还要区分哪些操作只是读取信息，哪些真正改变了代码、配置或开发环境，以及那些影响了结果、却没有出现在最终 Diff 里的操作。

第三：验证和人工介入

要记录 Agent 运行了哪些测试、静态检查和构建流程，哪些通过，哪些失败。失败以后，它是重试、切换方案，还是跳过检查？

一段代码最终看起来正确，并不能证明形成它的过程没有问题。

企业还要知道这个结果经过了什么验证，人工又在哪些位置修改要求、批准操作或接管任务。

第四：代码结果和后续影响

最终修改了哪些文件，形成了哪些 Commit 和 PR，是否经过评审、合并和发布？它是否改变了依赖、配置、权限或部署方式，进入生产以后又影响了什么？

企业真正要还原的，不只是一段代码，而是形成这段代码的整个行为过程。

只有这个过程与后续发布和运行结果能够关联起来，企业才能判断这次编码行为真正带来了什么。

讲到这里，一个容易出现的误解是：

既然要记录 Coding Agent 的工作过程，是不是要把模型的所有思考都保存下来？

我认为不是。

企业真正需要的是可以核对的运行事实：

• Agent 接到了什么任务；

• 读取和修改了哪些文件；

• 执行了什么命令和工具；

• 命令返回了什么结果；

• 运行了哪些测试；

• 人工批准、拒绝或者修改了什么；

• 最终产生了哪些代码和业务影响。

至于模型事后生成的一段解释，可以作为调查线索，但不能直接当作事实。

特别是 Coding Agent 经常会经历多轮尝试。

最终代码可能很简洁，真正的工作过程却包含搜索、失败、回退、重新选择和人工纠正。

如果只保留最后一次成功结果，企业看到的仍然不是完整现场。

最终代码可以被整理得很干净。

运行事实不能靠事后补写。

现在，越来越多 Coding Agent 开始记录会话、命令、文件修改和测试结果，并把 Commit 与产生它的任务和操作记录关联起来。

连运行在开发者电脑上的 Agent，也开始被纳入文件读取、代码修改、命令执行和工具调用的追踪范围。

这些变化说明，软件工程正在把过去分散在各处的记录，围绕一次编码行为重新组织起来。

企业真正需要回答的，不是又多了什么日志，而是：

一段代码由 Agent 完成时，这段工作究竟是怎样发生的。

只有这些分散记录能够关联起来，企业才可能还原出完整现场。

第一：是代码评审

评审者不仅要看最后的 Diff，还需要知道 Agent 理解了什么任务，做过哪些验证，人工在哪些位置介入。

第二：是事故调查

代码上线以后出了问题，企业需要沿着生产结果追到代码改动，再从代码改动追到当时的任务、操作和验证过程。

第三：是安全审计

Coding Agent 可能读取敏感代码、执行高风险命令、访问外部网络或者修改关键配置。这些动作不能只留在开发者电脑上。

第四：是质量改进

哪些任务经常失败？

哪些代码区域反复需要人工接管？

哪些测试经常被跳过？

哪些 Agent 版本产生了更多返工？

只有编码行为能够被关联和比较，企业才知道应该改模型、改工具、改流程，还是改任务本身。

当 Agent 开始承担真实的软件开发工作以后，企业需要在代码版本和最终改动之外，补上另一部分记录：

代码仓库继续记录代码如何变化。

行为链开始记录这些变化是怎样形成的。

这也意味着，可观测性的边界，开始从软件运行过程向软件开发过程延伸，关注一次编码行为是怎样形成的。

这就是第 14 篇所说的“一次业务行为”，在软件工程里的具体样子。

但记录了这些行为，还没有回答另一个问题：

Coding Agent 为什么会读取这些文件、采用这些规则，并作出这样的选择？

这就进入了下一篇要讨论的内容：

什么样的信息，才能成为 AI 判断的证据？

#AI系统 #AI可观测性 #因果AI #AgentOps #AI运行系统

行业参考：GitHub Managing Agent Sessions、GitHub Copilot CLI Session Data、OpenAI Codex System Card。