当写代码的AI也需要被实时监控

在软件工程的大部分历史里，工程师监控的始终是「运行中的应用」。

我们在请求路径上打 Trace，在数据库调用上记 Metric，在所有涉及交易和状态变更的地方狂打 Log。至于「写代码」这个动作本身，一直被挡在可观测性的边界之外。代码是工程师在系统上线前写下的东西，它属于外部输入，并不是系统运行的一部分。

GitHub 近期的一项更新悄然挪动了这条边界：Copilot 应用开始支持 OpenTelemetry（OTel）数据导出。企业管理员现在可以把 Agent 会话遥测数据——包括模型调用、工具执行、执行链路拓扑——直接接入已有的 APM 监控系统。此前，VS Code 和 CLI 版本的 Copilot 也已完成了类似改造。

巧合的是，AWS 几乎在同一时间上线了 CloudWatch Omni，专门针对传统应用与 AI Agent 的混合场景提供基于 OpenTelemetry 的监控。两家巨头在同一周走向了同一个方向：AI 编程 Agent 已经不再是一个单纯的辅助调用工具，而是一个必须纳入可观测体系的线上服务。

功能的落地并不轰动，但它背后的工程转向耐人寻味。

代码 Diff 解释不了 Agent 的决策

人类工程师提交 Pull Request 时，团队审查的物料虽然是代码变更（Diff），但真正起支撑作用的上下文其实留在开发者脑子里，或者分散在飞书、企业微信的讨论记录中：为什么选这个方案？中间否定过哪些思路？提 PR 前手动跑过哪些边界测试？这些上下文历来都是有损的，但大家习惯了它属于「人」，属于组织沟通成本。

换成 AI Agent，问题变得更棘手。

一个完整的 Agent 会话往往包含一系列复杂操作：调用底层模型、遍历多个文件、发起代码检索、执行外部工具、推翻错误方案、调整参数重试，最终才吐出那个清晰的 Commit。这期间的所有中间动作，在最终的 Diff 里完全看不见。

如果这段代码隐蔽地报错了，或者它能跑通但没人讲得清机制，单纯看 Diff 根本无法追溯根因。你是在对一个完全看不见过程的系统产物做 Debug。

这就是推动 Agent 遥测落地的最直接动力：既然 Agent 可以自主读写代码仓、调 API、跑测试、打提交，那它的执行链路就已经不是软件工程的边缘杂音。它本身就是软件构建链路的一环。日后排查「这段代码为什么这么写」时，答案不再需要依赖某个前同事的回忆，而是直接沉淀在可以检索的 Trace 数据里。

Trace 能记录「做了什么」，但难解释「为什么做」

传统的线上排障往往是倒推链条：哪个接口延迟突增，哪次 RPC 超时，哪个下游依赖挂了。因果关系是机械式的，Trace 记录的是因果，而非意图。

Agent 的 Trace 完全是另一回事。它记录的不仅是动作顺序，更是 Agent 的「决策尝试」：

• 它在第几步调了代码检索工具？
• 在改动核心模块前，它检索了哪部分上下文？
• 它在什么时候突然改变了重构方向？

这本质上是对「AI 思考路径」的埋点，排障问题也从「哪里挂了」变成了更玄学的「Agent 当时建立了怎样的推断，这个推断在哪一步走偏了」。

这是一种全新的调试挑战。必须承认，把数据吐给监控系统并不能自动解决问题。Trace 能告诉你它调了某个工具，但无法告诉你它为什么觉得调这个工具是对的——就像堆栈报错能告诉你哪一行空指针，却解释不了写这行代码的业务逻辑。可观测性只是还原了现场，怎么解读这些痕迹、怎么界定逻辑故障，需要工程团队建立全新的复盘习惯。

追踪 Commit 的真实来源

这套动作不是孤立的。GitHub 正在将 Copilot 生成的 Commit 与其背后的 Agent 会话日志直接关联。结合 OpenTelemetry 导出，开发团队终于拿到了完整的审计链条：哪个 Commit 产自哪次 Agent 交互，中间经历了哪些步骤。

「出处溯源 + 执行链路」的组合，才是这次变革的关键。

一个没有中间记录的 Commit 就是彻底的黑盒。一旦写代码的人离职，或者当初触发 Agent 的人本来也没看懂中间的几十步试错，几个月后系统出故障，后人将无从查起。这种现象在人工维护的老代码堆里很常见；而当代码从一开始就不是由人类完整推导出来的，黑盒化的风险只会成倍放大。

Agent 遥测，谁来做运维责任人？

配置一条数据采集管道很容易，难的是确定谁来消费它。

这就涉及研发运维的权责切分：

• 代码线上炸了，看 Agent Trace 的是应用运维、业务开发，还是平台工程团队？
• 它是否像安全事件一样，需要专属的应急响应角色（Owner）？
• 涉及源代码及提示词上下文的会话数据，要按传统业务日志保存 30 天，还是作为代码资产永久归档？

只开启 OTel 开关解决不了这些治理问题。关键在于企业是把 Agent 执行当成一等公民的线上服务来严阵以待，还是仅仅当成一个满足合规审计的被动打卡项。

如果推进得当，Agent 链路追踪会自然融入每周的故障复盘，与应用日志、发布流水线并列排查，帮团队更快搞清楚自动化引入的暗坑。如果流于形式，它就会退化为昂贵而庞杂的数据垃圾，在监控大盘里静静积灰，直到下一次严重事故发生。

编程动作本身正在变成分布式系统

行业关注 AI，习惯聚焦在「生成代码有多快」。但这只是表层现象。

真正的范式转移在于：写代码这个动作本身，正在演变出自己的生产运维界面。 它拥有独立的会话生命周期、复杂的工具链调用、密集的模型交互，以及一套平行的排障规约。

伴随 Agent 渗透到研发流程的各个角落，这几乎是工程演化的必然终局。但工程师并不会因此轻松省心。它没有减少认知负荷，反而在原本复杂的微服务之上，又叠加了一层充满不确定性的决策链路。凌晨两点的排障大盘上，从此多了一种需要凝神辨析的 Trace：代码虽然跑通了，但系统深处的决策黑盒，依然等待着人类去确认它究竟为何而运行。