你的 Agent Harness 应该会自我修复

AI agent 在生产环境里失败的时候，你的可观测性工具会告诉你它到底做了什么，而对于该怎么修，几乎什么都不会说。

你会拿到一份干净的运行 trace：每一次模型调用、每一个触发的工具、每一步耗时、每一步花了多少 token。

拿不到的，是它为什么坏、哪一处改动能修好它，以及任何「下周不会再犯」的保证。

于是你只好一段一段地翻 trace，猜出一个理论，手写一个补丁，然后祈祷它没有把原本正常的东西弄坏。

接着新模型上线，带来一批新的失败模式，你又得把这套手工流程从头跑一遍。

真正的瓶颈不在可观测性，而在 trace 落到你屏幕上之后要发生的一切。

Cursor 最近分享了他们在 agent 外围那层 harness 上投入了多少工程——也就是包在裸模型外面的提示词、工具和检查。同一个模型，换成更好的 harness，结果会好得多，而这项工作永远不会真正结束。

这恰恰是所有可观测性平台止步的地方：它回答了「发生了什么」，然后把「为什么发生」「该改什么」「怎么防止再发生」原样退还给你。

今天大多数团队就卡在这个缺口里。这篇要讲的是它为什么反复被撕开，以及最终要怎样才能合上。

为什么现有可观测性在大规模下会失灵

大多数 agent 可观测性平台交付一条 trace 就结束了。

你拿到 span 树、延迟数字、token 成本和一个看板。你拿不到的仍然是：为什么失败、该修什么、以及「不会再坏」的保证。

• 「发生了什么」→ 平台能处理
• 「为什么发生」→ 人工
• 「这里是修复方案」→ 人工
• 「这次不会再坏了」→ 人工

在 2023 年，这是一个合理的产品。但对今天在生产里跑 agent 的团队，这是一个错误的抽象层。

问题是会自己滚大的：每次模型升级都引入新的失败模式，每加一个工具就多一批边界情况。harness 变复杂的速度，快过任何团队手工跟踪和修复的速度。

下面这套栈就是用来干这件事的。

Opik：面向 Agent 时代的可观测性与评测

Opik 是一个开源的日志、调试与优化平台，面向 AI agent 和 LLM 应用。它立在一个前提上：这个循环应该被自动化，而不是靠堆人力。

（原文注明本篇由 Comet ML 赞助，Opik 是他们的产品。）

四层栈

Opik 的架构是一条连起来的流水线：

链路追踪 → Ollie 诊断 → Ollie 提出修复 → 应用修复并验证 → 测试套件把这次失败锁成回归测试 → 回到链路追踪。

下面逐层说。

第 1 层：链路追踪

每一次 LLM 调用、工具调用、检索步骤，都靠一个装饰器自动打点。

import opik

@opik.track
def my_agent(query: str):
    # your agent logic here
    ...

开箱支持 LangGraph、CrewAI 以及 50 多个框架。每条 trace 都会记录当时生效的 agent 配置，方便你之后重跑某个失败输入时完整复现。

第 2 层：Ollie

别的可观测性平台停在「这是你的 trace」。Opik 则由 Ollie 把 trace 一路推到改好的代码。

Ollie 是内置在 Opik 里的编码 agent，一个 agent，带着完整上下文。

在完全没有代码访问权限的情况下，Ollie 也能读 span 树、识别失败模式、解释跨每一次 LLM 调用的因果链。你问它「为什么最终回答忽略了检索到的上下文」，它会走完整棵 span 树，把根因翻出来。

在项目根目录运行 opik connect，Ollie 就升级到完整的改码模式：

• 读你的源文件
• 定位到具体哪几行该负责
• 提出一份 diff，没有你的明确批准，什么都不改

批准之后，Ollie 会用原始失败 trace 里的确切输入重跑你的 agent，把新的 trace 流式输出出来做并排对比，并把这次原始失败锁成测试套件里的一个回归用例。

坏 trace → 根因 → diff → 批准 → 重跑 → 回归锁定。

第 3 层：测试套件

常见的评测流程是：建一个带标注的数据集，定义一个数值指标，比浮点数。这套东西适合研究者，它不匹配工程师对「质量」的思考方式。

Opik 用大白话写的断言替掉它：

suite = opik.TestSuite("crm-agent-v2")
suite.add_assertion("The response must include specific deal details, not just a count")
suite.add_assertion("The response must never reveal unauthorized information")
suite.run_tests()

底层会把这些转成 LLM-as-a-judge 的检查，每个用例给出干净的通过/失败。

真正改变工作流的是这一点：你每调试一个失败 trace，它都会自动变成一个测试用例。套件从真实的生产失败里长出来，而不是由某个人提前编好的场景。

于是每一轮下来，harness 都更难被弄坏。

但即使测试套件在长大，你仍然需要一个在发布前安全试验改动的地方——那就是第 4 层。

第 4 层：Agent 沙箱

大多数 playground 是提示词 playground：改一下 system prompt，重跑一次 LLM 调用。这回答的是错误的问题。

生产上真正的问题是：我改这一处，整个 agent 图会怎样。

Opik 的 Agent Sandbox 在 UI 里端到端跑完整打点的 agent。改提示词、换模型、加工具，然后看整个系统在完整 span 树上怎么反应。每次沙箱运行都会产出一条完整的 Opik trace。

非开发岗——产品经理、领域专家、QA——都可以安全地试配置，不用碰 git。

飞轮跑起来是什么样

这四层不是四个独立功能，是一个循环。

用 @opik.track 打点，声明一个 opik.Config。生产上出错。Ollie 读 trace、读你的源码，提出修复。你批准。Ollie 在沙箱里用原始失败输入重跑 agent。修复通过。存成一个新的 Blueprint。环境指针提升到 staging。原始失败被锁成一条回归测试。

下一次失败进入同一个循环。

每一轮下来，harness 都更难被弄坏。

把环闭上

当 agent 还简单的时候，止步于 trace 的可观测性是说得通的。可一旦它们进了生产，真正的工作是 trace 之后的一切，而这部分工作正是 Opik 替你跑完、而不是留给你自己扛的地方。

这整套东西都开源发布：追踪、Ollie、测试套件、Agent 沙箱，一个 6 种算法的 Agent Optimizer，以及 50 多个框架集成；项目在 GitHub 上已过 19.3K 星（按现在的仓库数据是 2.27 万星，Apache-2.0，最新版本 2.2.105）。

自托管三条命令：

git clone https://github.com/comet-ml/opik
cd opik
./opik.sh

Cursor 描述的那个手工循环，正是 Opik 想自己闭合的部分——从一条坏 trace 一直到一条锁定的回归测试。

如果你在生产里跑 agent，值得看一眼。

去 Comet ML 和 Opik 看看 →

作者在文末留了个问题：你的 agent 栈现在处于什么可观测性状态，调试循环又断在团队的哪一环？