OpenAI前工程师造了1个"自医"AI：代码崩了不用人管

去年有个数据挺有意思：GitHub Copilot用户平均花37%的 coding 时间在调试，而非写新功能。更扎心的是，AI 生成的代码出错后，调试时间反而比手写代码更长——因为你得先搞懂 AI 写了什么，才能开始修。

Okahu 联合创始人兼 CTO Vinod Vavilapalli 最近放了个 demo，试图把这个闭环彻底关掉。不是让 AI 少写 bug，而是让 AI 自己读日志、自己诊断、自己修。

这个 demo 的核心逻辑很直白：给 agent 开一扇看自己的窗户。

传统软件里，代码即文档。你读源码就知道程序在干嘛。但 agent 驱动的应用不一样——代码只是脚手架，真正的决策发生在模型运行时。一个看不到自己运行轨迹的 agent，就像医生不给病人做检查就开药，全靠猜。

Monocle：让 AI 自动留下"病历"

Monocle 做的第一件事，是把遥测（telemetry）的门槛降到零。它自动给 OpenAI、LangChain、LlamaIndex 等 SDK 插桩，不需要你手动创建 span。

启用只需要一行代码：

```python from monocle_apptrace import setup_monocle_telemetry setup_monocle_telemetry(workflow_name="text_to_sql_analyst") ```

从这行之后，每次 LLM 调用、每次数据库查询、每次工具调用，都会被捕获为 trace span。输入输出、模型名、token 消耗、异常详情、耗时数据——全打包进去。

关键是：agent 不会给自己的生成代码加遥测。如果插桩需要额外工作量，这件事就不会发生。Monocle 的 auto-instrumentation 解决的就是这个"人性懒惰"问题。

Okahu MCP：让 AI 能查自己的"病历"

有了 trace，下一步是让 agent 能读到它。Okahu 的做法是把遥测数据通过 MCP（Model Context Protocol，模型上下文协议）暴露出来。

MCP 是 Anthropic 去年推出的开放协议，初衷是让 LLM 能安全地访问外部数据源和工具。Okahu 在这里的角色是遥测 provider——agent 通过 MCP 查询自己的历史运行数据，就像医生调病人的既往病史。

具体实现上，Okahu MCP 提供了几个关键工具：

- `get_traces`：按时间范围拉取 trace 列表

- `get_trace_details`：获取单个 trace 的完整细节

- `search_traces`：按错误类型、耗时、特定关键词过滤

这些工具被注册到 agent 的工具箱里，agent 可以在推理过程中自主调用。

OpenCode：执行层

OpenCode 是 Salesforce 开源的 AI 编程 agent，在这个 demo 里扮演"手"的角色。它接收任务、写代码、跑测试、看到失败、决定下一步。

三者的协作链条是这样的：OpenCode 写代码 → Monocle 自动记录运行轨迹 → 测试失败 → OpenCode 通过 Okahu MCP 查询自己的 trace → 基于 trace 诊断 → 生成修复 → 循环直到通过。

整个过程中，人类只负责设定目标（"让这个 Text-to-SQL 应用通过测试"），不参与任何调试决策。

Vinod Vavilapalli 在演示视频里展示的具体 case 是：一个 Text-to-SQL 应用，用户问"上个月销售额最高的 5 个产品"，agent 生成的 SQL 在特定 edge case 下报错。

传统 workflow 里，你会看到测试失败，打开日志，发现是日期格式处理有问题，然后告诉 agent"把日期格式从 MM-DD-YYYY 改成 YYYY-MM-DD"。

在这个自愈合 demo 里，agent 自己做了这些：看到测试失败 → 调用 `get_traces` 拉最近 5 分钟的 trace → 发现某个 span 里有 `ValueError: time data '2024-13-45' does not match format '%m-%d-%Y'` → 定位到日期解析函数 → 生成修复 → 重跑测试 → 通过。

从失败到修复，demo 里的耗时是 47 秒。没有人看过一行日志。

技术细节：trace 里到底有什么

能让 agent 有效诊断，trace 的颗粒度必须够细。Monocle 捕获的结构大概长这样：

``` Span: text_to_sql_analyst ├── Span: llm_call (OpenAI gpt-4) │ ├── Attributes: input_messages, model, temperature │ └── Events: completion, token_usage(prompt=124, completion=89) ├── Span: tool_invocation (generate_sql) │ ├── Attributes: tool_name, tool_input │ └── Span: db_query │ ├── Attributes: query_string, execution_time_ms │ └── Events: error (ValueError: time data...) └── Span: response_formatting ```

当 agent 查询 `get_trace_details` 时，拿到的是这个树状结构的文本化表示。LLM 的上下文窗口足够消化这种层级信息，并定位到具体的错误叶子节点。

一个有趣的细节是：agent 的修复提案有时会"过度修复"。比如看到日期解析报错，它可能把整个日期处理模块重写，而不是最小改动。Vavilapalli 提到他们正在实验让 agent 对比多个候选修复的 trace 预测结果，选择最保守的那个——但这已经属于下一步优化了。

为什么是现在

这个概念能跑通，依赖几个前提条件同时成熟：

第一，LLM 的 tool use 能力。GPT-4 级别的模型才能可靠地决定"我现在需要查 trace"而不是瞎猜。

第二，MCP 的标准化。没有统一协议，每个遥测系统都要写定制接入层，生态碎掉。

第三，auto-instrumentation 的成熟。Monocle 这类工具让"所有 agent 行为都被记录"成为默认而非额外工作。

第四，成本下降。查询 trace、生成修复、跑测试的循环可能重复多次，单次推理成本必须够低才能负担得起。

Okahu 的定价策略也反映了这点：遥测存储按量计费，但 MCP 查询本身目前免费。他们的 bet 是，agent 自主调试的场景会创造足够的存储需求，查询成本可以被摊平。

局限和未解问题

这个 demo 是精心设计的 sandbox。真实生产环境的复杂度会暴露更多问题：

Trace 噪音。一个 busy 系统的 trace 量可能让 agent 的上下文窗口爆炸，需要更智能的预过滤机制。

因果推断。多个并行组件同时失败时，agent 可能误判 root cause。人类工程师会凭经验知道"数据库超时通常是因为下游服务挂了"，agent 需要类似的经验注入。

修复验证。测试通过不等于修复正确，可能只是测试覆盖不足。如何设计"修复置信度"的评估，还没看到成熟方案。

安全边界。让 agent 自主修改代码并执行，需要严格的沙箱和回滚机制。demo 里用的是临时容器，生产环境的等效方案还在演进。

Vavilapalli 在视频结尾的 Q&A 环节被问到："如果 agent 的修复引入了新的 bug，但测试没覆盖到，怎么办？"

他的回答很直接："这就是我们还不敢叫这东西'生产就绪'的原因。现在的价值是压缩调试循环，不是消除人类审查。但方向很明确——让 agent 能处理的 case 越来越多，人类从'必须参与'变成'抽样检查'。"

这个 demo 的代码已经开源在 Okahu 的 GitHub 仓库，依赖 Monocle 的 Python SDK 和 Okahu Cloud 的免费 tier 就能跑。Vavilapalli 说他们的下一个迭代目标是让 agent 能处理"测试也通过了但业务逻辑明显有问题"的场景——也就是从"自愈合"进化到"自验证"。

如果调试时间真的能从 37% 压到 10% 以下，开发者的工作流会变成什么样？agent 的 commit 记录里出现 "fixed by self-diagnosis at 3:47 AM" 的时候，code review 的重心又该往哪移？