过去的软件可观测性主要关注运行中的系统。我们会观察CPU内存延迟错误率TraceLogMetric因为一个系统上线之后最重要的问题之一就是当它出现异常时我们能不能知道到底发生了什么但进入 AI Coding Agent 时代之后这个问题出现了一个新的版本当 Codex 修改了一批代码我们能不能知道它为什么这么改这其实是一个比“AI 能不能写代码”更深的问题。ChatGPT Plus、ChatGPT Pro、Codex 等 AI 工具开始逐渐进入真实软件工程流程后团队不只是需要观察软件运行状态还需要观察 AI 的工程行为。于是一个新的技术方向开始变得重要Agent Observability也就是 AI Agent 可观测性。一、传统 Observability 观察的是系统Agent Observability 观察的是决策过程传统应用可能有这样一条链路HTTP Request ↓ API Gateway ↓ Order Service ↓ Payment Service ↓ Database当请求失败时我们通过 Trace 找到Order Service 耗时 100ms Payment Service 耗时 3000ms Database 正常于是可以判断问题大概率来自 Payment Service。这就是分布式 Trace 的价值。但 Codex 执行代码任务之后我们可能遇到另一种问题为什么它修改了 payment.service.ts 为什么多增加了一个依赖 为什么原本只要求修 Bug 最后改了 8 个文件如果没有记录 AI 执行过程开发者只能重新猜。因此Agent 也需要类似 Trace 的机制。二、ChatGPT Pro 与 Codex 的一次工程任务其实也是一条 Trace可以把一次 AI 编程任务看成User Intent ↓ Context Retrieval ↓ ChatGPT Pro Planning ↓ Codex Repository Analysis ↓ File Modification ↓ Test Execution ↓ Review每一步其实都可以生成一个 Span。类似 OpenTelemetrytypeAgentSpan{traceId:stringspanId:stringparentSpanId?:stringoperation:stringstartedAt:numberendedAt:numberinputSummary:stringoutputSummary:stringmetadata:Recordstring,unknown}例如{operation:CODEX_FILE_EDIT,metadata:{file:src/order/order.service.ts,reason:add idempotency guard,taskId:TASK-2088}}这意味着未来不仅请求需要 Trace。AI 修改代码也需要 Trace。三、为什么 ChatGPT Plus 适合做 Context 层Codex 是否能正确完成任务很大程度上取决于它看到什么上下文。例如需求是修复退款重复执行问题。但实际项目规则可能散落在README 历史 Issue 支付接口文档 退款测试 代码注释 业务说明ChatGPT Plus 可以先把这些材料归一化。形成context:confirmed_rules:-refund must be idempotent-completed refund cannot retryrelated_modules:-payment-order-event-consumerknown_risks:-duplicate message delivery-concurrent request然后将更干净的上下文交给 ChatGPT Pro 或 Codex。这本质上是在降低Context Noise。四、ChatGPT Pro 更适合生成 Plan Trace复杂任务不应该直接执行。例如优化订单模块。这个任务过于模糊。更合理的处理ChatGPT Pro 先输出 Planplan:step_1:action:analyze order state transitionmode:read_onlystep_2:action:identify duplicate refund pathsstep_3:action:create minimal patchstep_4:action:run regression tests这份 Plan 本身也应该进入 Trace。因为后面出了问题需要知道AI 原来计划做什么 实际又做了什么两者如果不一致就说明发生了Plan Drift。五、Codex 需要监控 Scope DriftAI Coding Agent 一个常见问题是任务越来越大。原本修复一个 Bug后来顺便重构 顺便改类型 顺便升级依赖 顺便调整架构这在人工开发里也会发生。但 AI 执行速度更快因此风险会被放大。可以定义typeTaskScope{allowedFiles:string[]forbiddenFiles:string[]maxChangedFiles:number}例如constscope:TaskScope{allowedFiles:[src/order/**,tests/order/**],forbiddenFiles:[src/payment/**,database/migrations/**],maxChangedFiles:5}如果 Codex 修改超过范围立即产生事件SCOPE_DRIFT_DETECTED这其实就是AI 工程监控。六、未来需要专门的 Agent Metrics传统系统监控QPS P95 Latency Error Rate CPU Memory未来 AI 开发环境可能增加Agent Task Success Rate Average Files Changed Context Retrieval Size Plan Drift Rate Scope Violation Rate Test Failure Rate Human Rejection Rate例如typeCodexMetrics{taskSuccessRate:numberavgChangedFiles:numberscopeViolationRate:numberverificationFailureRate:numberhumanRejectRate:number}如果一个 Coding Agent80% 的任务都被人工重新修改那么它看起来执行速度很快但实际价值并不高。七、AI 工程效率不能只看“生成速度”传统评估生成 500 行代码只需要几分钟看起来很好。但如果300 行需要重写 测试失败 架构被破坏 引入技术债真正效率可能是负数。更合理的指标Accepted Change Ratio也就是AI 生成的修改有多少最终被接受。可以定义Agent Engineering Efficiency Accepted Changes / Generated Changes这比“写了多少代码”更有意义。八、Log 不应该只记录结果还要记录原因普通日志Edited order.service.ts信息太少。更好的 Agent Log{event:FILE_MODIFIED,file:src/order/order.service.ts,reason:duplicate cancel request could restore inventory twice,constraint:keep existing API contract,relatedTest:order-cancel-idempotency.test.ts}开发者可以直接知道为什么修改。这会显著降低 Review 成本。九、Codex 需要 Audit Trail企业使用 AI 最大的问题之一是责任链。例如某段代码出现事故团队需要知道谁提出的任务 AI 读取了什么 谁批准计划 Codex 修改了什么 测试有没有通过 谁最终合并因此未来 AI 开发平台需要Audit Trail例如TASK-1008 User Goal ↓ ChatGPT Pro Plan ↓ Human Approved ↓ Codex Modified ↓ Tests Passed ↓ Human Merged这和金融系统审计逻辑很像。十、ChatGPT Pro Codex 需要 Human-in-the-loopAI 可观测性最终不是为了让人完全退出。恰恰相反。它是为了让人更容易介入关键节点。例如Risk Low → 自动执行 Risk Medium → 执行后 Review Risk High → 执行前审批可以写成functionapprovalPolicy(risk:LOW|MEDIUM|HIGH){if(riskHIGH){returnPRE_APPROVAL_REQUIRED}if(riskMEDIUM){returnPOST_EXECUTION_REVIEW}returnAUTO_EXECUTE}权限、支付、数据库迁移这类高风险任务应该永远比普通 UI 修改更严格。十一、未来 IDE 可能直接出现 Agent Dashboard未来 AI 原生 IDE 可能不仅有Editor Terminal Git Debug还会多一个Agent Dashboard展示Running Tasks Current Plan Files Being Modified Test Status Risk Level Context Sources Human Approval开发者不再只是观察程序。也开始观察AI 如何工作。十二、结语AI Coding Agent 越强可观测性越重要2026 年 8 月之后讨论 Codex 已经不能只讨论代码生成。真正进入软件工程之后更重要的是可追踪 可解释 可验证 可中断 可回滚ChatGPT Plus 可以负责整理上下文。ChatGPT Pro 可以负责复杂规划。Codex 可以负责代码执行。而 Agent Observability负责让整个过程保持透明。最终AI Engineering Reliability Agent Capability × Observability × Verification × Human GovernanceAI Coding Agent 越来越像工程执行者之后软件团队就必须像监控生产系统一样开始监控 AI 的工程行为。这可能是 ChatGPT、Codex 进入企业级软件开发之后一个比“生成代码速度”更加重要的技术方向。
过去的软件可观测性主要关注运行中的系统。我们会观察CPU内存延迟错误率TraceLogMetric因为一个系统上线之后最重要的问题之一就是当它出现异常时我们能不能知道到底发生了什么但进入 AI Coding Agent 时代之后这个问题出现了一个新的版本当 Codex 修改了一批代码我们能不能知道它为什么这么改这其实是一个比“AI 能不能写代码”更深的问题。ChatGPT Plus、ChatGPT Pro、Codex 等 AI 工具开始逐渐进入真实软件工程流程后团队不只是需要观察软件运行状态还需要观察 AI 的工程行为。于是一个新的技术方向开始变得重要Agent Observability也就是 AI Agent 可观测性。一、传统 Observability 观察的是系统Agent Observability 观察的是决策过程传统应用可能有这样一条链路HTTP Request ↓ API Gateway ↓ Order Service ↓ Payment Service ↓ Database当请求失败时我们通过 Trace 找到Order Service 耗时 100ms Payment Service 耗时 3000ms Database 正常于是可以判断问题大概率来自 Payment Service。这就是分布式 Trace 的价值。但 Codex 执行代码任务之后我们可能遇到另一种问题为什么它修改了 payment.service.ts 为什么多增加了一个依赖 为什么原本只要求修 Bug 最后改了 8 个文件如果没有记录 AI 执行过程开发者只能重新猜。因此Agent 也需要类似 Trace 的机制。二、ChatGPT Pro 与 Codex 的一次工程任务其实也是一条 Trace可以把一次 AI 编程任务看成User Intent ↓ Context Retrieval ↓ ChatGPT Pro Planning ↓ Codex Repository Analysis ↓ File Modification ↓ Test Execution ↓ Review每一步其实都可以生成一个 Span。类似 OpenTelemetrytypeAgentSpan{traceId:stringspanId:stringparentSpanId?:stringoperation:stringstartedAt:numberendedAt:numberinputSummary:stringoutputSummary:stringmetadata:Recordstring,unknown}例如{operation:CODEX_FILE_EDIT,metadata:{file:src/order/order.service.ts,reason:add idempotency guard,taskId:TASK-2088}}这意味着未来不仅请求需要 Trace。AI 修改代码也需要 Trace。三、为什么 ChatGPT Plus 适合做 Context 层Codex 是否能正确完成任务很大程度上取决于它看到什么上下文。例如需求是修复退款重复执行问题。但实际项目规则可能散落在README 历史 Issue 支付接口文档 退款测试 代码注释 业务说明ChatGPT Plus 可以先把这些材料归一化。形成context:confirmed_rules:-refund must be idempotent-completed refund cannot retryrelated_modules:-payment-order-event-consumerknown_risks:-duplicate message delivery-concurrent request然后将更干净的上下文交给 ChatGPT Pro 或 Codex。这本质上是在降低Context Noise。四、ChatGPT Pro 更适合生成 Plan Trace复杂任务不应该直接执行。例如优化订单模块。这个任务过于模糊。更合理的处理ChatGPT Pro 先输出 Planplan:step_1:action:analyze order state transitionmode:read_onlystep_2:action:identify duplicate refund pathsstep_3:action:create minimal patchstep_4:action:run regression tests这份 Plan 本身也应该进入 Trace。因为后面出了问题需要知道AI 原来计划做什么 实际又做了什么两者如果不一致就说明发生了Plan Drift。五、Codex 需要监控 Scope DriftAI Coding Agent 一个常见问题是任务越来越大。原本修复一个 Bug后来顺便重构 顺便改类型 顺便升级依赖 顺便调整架构这在人工开发里也会发生。但 AI 执行速度更快因此风险会被放大。可以定义typeTaskScope{allowedFiles:string[]forbiddenFiles:string[]maxChangedFiles:number}例如constscope:TaskScope{allowedFiles:[src/order/**,tests/order/**],forbiddenFiles:[src/payment/**,database/migrations/**],maxChangedFiles:5}如果 Codex 修改超过范围立即产生事件SCOPE_DRIFT_DETECTED这其实就是AI 工程监控。六、未来需要专门的 Agent Metrics传统系统监控QPS P95 Latency Error Rate CPU Memory未来 AI 开发环境可能增加Agent Task Success Rate Average Files Changed Context Retrieval Size Plan Drift Rate Scope Violation Rate Test Failure Rate Human Rejection Rate例如typeCodexMetrics{taskSuccessRate:numberavgChangedFiles:numberscopeViolationRate:numberverificationFailureRate:numberhumanRejectRate:number}如果一个 Coding Agent80% 的任务都被人工重新修改那么它看起来执行速度很快但实际价值并不高。七、AI 工程效率不能只看“生成速度”传统评估生成 500 行代码只需要几分钟看起来很好。但如果300 行需要重写 测试失败 架构被破坏 引入技术债真正效率可能是负数。更合理的指标Accepted Change Ratio也就是AI 生成的修改有多少最终被接受。可以定义Agent Engineering Efficiency Accepted Changes / Generated Changes这比“写了多少代码”更有意义。八、Log 不应该只记录结果还要记录原因普通日志Edited order.service.ts信息太少。更好的 Agent Log{event:FILE_MODIFIED,file:src/order/order.service.ts,reason:duplicate cancel request could restore inventory twice,constraint:keep existing API contract,relatedTest:order-cancel-idempotency.test.ts}开发者可以直接知道为什么修改。这会显著降低 Review 成本。九、Codex 需要 Audit Trail企业使用 AI 最大的问题之一是责任链。例如某段代码出现事故团队需要知道谁提出的任务 AI 读取了什么 谁批准计划 Codex 修改了什么 测试有没有通过 谁最终合并因此未来 AI 开发平台需要Audit Trail例如TASK-1008 User Goal ↓ ChatGPT Pro Plan ↓ Human Approved ↓ Codex Modified ↓ Tests Passed ↓ Human Merged这和金融系统审计逻辑很像。十、ChatGPT Pro Codex 需要 Human-in-the-loopAI 可观测性最终不是为了让人完全退出。恰恰相反。它是为了让人更容易介入关键节点。例如Risk Low → 自动执行 Risk Medium → 执行后 Review Risk High → 执行前审批可以写成functionapprovalPolicy(risk:LOW|MEDIUM|HIGH){if(riskHIGH){returnPRE_APPROVAL_REQUIRED}if(riskMEDIUM){returnPOST_EXECUTION_REVIEW}returnAUTO_EXECUTE}权限、支付、数据库迁移这类高风险任务应该永远比普通 UI 修改更严格。十一、未来 IDE 可能直接出现 Agent Dashboard未来 AI 原生 IDE 可能不仅有Editor Terminal Git Debug还会多一个Agent Dashboard展示Running Tasks Current Plan Files Being Modified Test Status Risk Level Context Sources Human Approval开发者不再只是观察程序。也开始观察AI 如何工作。十二、结语AI Coding Agent 越强可观测性越重要2026 年 8 月之后讨论 Codex 已经不能只讨论代码生成。真正进入软件工程之后更重要的是可追踪 可解释 可验证 可中断 可回滚ChatGPT Plus 可以负责整理上下文。ChatGPT Pro 可以负责复杂规划。Codex 可以负责代码执行。而 Agent Observability负责让整个过程保持透明。最终AI Engineering Reliability Agent Capability × Observability × Verification × Human GovernanceAI Coding Agent 越来越像工程执行者之后软件团队就必须像监控生产系统一样开始监控 AI 的工程行为。这可能是 ChatGPT、Codex 进入企业级软件开发之后一个比“生成代码速度”更加重要的技术方向。
