过去的软件可观测性，主要关注运行中的系统。
我们会观察：
- CPU
- 内存
- 延迟
- 错误率
- Trace
- Log
- Metric
因为一个系统上线之后，最重要的问题之一就是：
当它出现异常时，我们能不能知道到底发生了什么？
但进入 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。
类似 OpenTelemetry：
typeAgentSpan={traceId:stringspanId:stringparentSpanId?:stringoperation:stringstartedAt:numberendedAt:numberinputSummary:stringoutputSummary:stringmetadata:Record<string,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 先输出 Plan：
plan: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 Drift
AI 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 Agent：
80% 的任务都被人工重新修改那么它看起来执行速度很快，
但实际价值并不高。
七、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-loop
AI 可观测性最终不是为了：
让人完全退出。
恰恰相反。
它是为了让人更容易介入关键节点。
例如：
Risk = Low → 自动执行 Risk = Medium → 执行后 Review Risk = High → 执行前审批可以写成：
functionapprovalPolicy(risk:"LOW"|"MEDIUM"|"HIGH"){if(risk==="HIGH"){return"PRE_APPROVAL_REQUIRED"}if(risk==="MEDIUM"){return"POST_EXECUTION_REVIEW"}return"AUTO_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 进入企业级软件开发之后，一个比“生成代码速度”更加重要的技术方向。
