过去的软件可观测性，主要关注运行中的系统。

我们会观察：

• 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：

type AgentSpan = {
  traceId: string
  spanId: string
  parentSpanId?: string

  operation: string

  startedAt: number
  endedAt: number

  inputSummary: string
  outputSummary: string

  metadata: 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 retry


related_modules:

  - payment

  - order

  - event-consumer


known_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 transition

  mode:
    read_only


step_2:

  action:
    identify duplicate refund paths


step_3:

  action:
    create minimal patch


step_4:

  action:
    run regression tests

这份 Plan 本身也应该进入 Trace。

因为后面出了问题，需要知道：

AI 原来计划做什么？

实际又做了什么？

两者如果不一致，就说明发生了：

Plan Drift。

---

五、Codex 需要监控 Scope Drift

AI Coding Agent 一个常见问题是：

任务越来越大。

原本：

修复一个 Bug

后来：

顺便重构

顺便改类型

顺便升级依赖

顺便调整架构

这在人工开发里也会发生。

但 AI 执行速度更快，因此风险会被放大。

可以定义：

type TaskScope = {
  allowedFiles: string[]
  forbiddenFiles: string[]
  maxChangedFiles: number
}

例如：

const scope: 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

例如：

type CodexMetrics = {
  taskSuccessRate: number
  avgChangedFiles: number
  scopeViolationRate: number
  verificationFailureRate: number
  humanRejectRate: 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

→ 执行前审批

可以写成：

function approvalPolicy(
  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 Governance

AI Coding Agent 越来越像工程执行者之后，

软件团队就必须像监控生产系统一样：

开始监控 AI 的工程行为。

这可能是 ChatGPT、Codex 进入企业级软件开发之后，一个比“生成代码速度”更加重要的技术方向。