（注：本文原文是 Comet ML 赞助的产品发布，结尾明确写了 "Thanks to Comet ML for sponsoring today's issue"。解读只取它的产品定位与四层架构，营销话术不在范围内。）
Agent 在生产里挂掉之后，observability 工具能告诉你它做了什么——每一段 span、每个模型调用、每个工具触发、每步耗时、每个 token 成本。它不能告诉你的是：它为什么挂了、改什么能修好、下周同一件事会不会再发生一次。
这就是 Akshay Pachaar 提出的「harness 自我修复」主张的起点：把 trace 之后那一整段原本由人跑的循环，也变成自动化。Cursor 团队最近分享过——围绕 agent 的 harness（prompt 工具和检查的包裹层）几乎是无止境的工程量。同一个模型，包一层更好的 harness 表现就好得多，而且这活永远做不完。
但绝大多数 agent observability 平台到 trace 这一步就停了：
- 「发生了什么」→ 平台能告诉你
- 「为什么发生」→ 手动
- 「怎么修」→ 手动
- 「不会再发生」→ 手动
2023 年这是合理的产品。2026 年对于把 agent 跑在生产里的团队是错误的抽象层级。问题会自复合：每升级一次模型就有一批新的失败模式、每加一个工具就有一批新的边界情况、harness 复杂度增长快过任何团队手动跟踪和修复的速度。
Opik 的四层：把「右半边」打包成自己会关闭的循环
Comet ML 开源的 Opik（github.com/comet-ml/opik，19.3K+ stars，自托管三行命令）把这条循环拆成四层，每层不是独立 feature，是同一圈 loop 的连续节点：
Trace → Ollie 诊断 → Ollie 提 fix → fix 被应用并验证 → Test Suite 锁回归 → 回到 Trace
Layer 1：Tracing——一个 @opik.track 装饰器自动埋点 LLM 调用、工具调用、检索步骤。LangGraph、CrewAI、50+ 框架开箱即用。每条 trace 记录当时活跃的 agent 配置，做可复现。
Layer 2：Ollie——嵌在 Opik 里的 coding agent，一个 agent 拿全上下文。
- 不接代码时：读 span tree，定位失败模式，把跨多次 LLM 调用的因果链讲清楚。问它「最终回答为什么忽略了检索到的上下文？」它走完整条 span tree 把根因顶到表面。
- 接代码时：跑
opik connect，Ollie 升级到 full code-fix 模式——读源文件、定位具体行、出 diff、没你显式 approve 之前一行不改。approve 之后，Ollie 拿原始失败 trace 的输入再跑一遍 agent，把新 trace 并排展示，把这次失败锁成 test suite 里的 regression 用例。
整条路径是：坏 trace → 根因 → diff → approve → 重跑 → 锁回归。
Layer 3：Test Suite——用自然语言写断言，不写数值 metric：
suite = opik.TestSuite("crm-agent-v2")
suite.add_assertion("回复必须包含具体 deal 细节，不能只给数量")
suite.add_assertion("回复绝不能泄露未授权信息")
suite.run_tests()
Opik 内部把它们转成 LLM-as-a-judge 检查，输出干净的 pass/fail。
真正改变 workflow 的是这条：你 debug 的每一条失败 trace，自动变成一条新的 test case。Test suite 从真实生产失败里长出来，不是提前编出来的合成场景。每一轮循环，harness 变得更难被打穿。
Layer 4：Agent Sandbox——大多数 playground 是 prompt playground：改一句 system prompt，重跑一次 LLM 调用。答错问题了。
生产里要问的是：「我改了这个，整张 agent graph 会怎么变？」Opik 的 Agent Sandbox 把完整 instrumented agent 端到端跑在 UI 里。改 prompt、换模型、加工具，看整张 spanning tree 怎么响应。每次 sandbox run 都产出一条完整 Opik trace。PM、领域专家、QA 都可以在不动 git 的情况下安全测配置。
端到端 loop：故障进、闭环出
串起来是这样：
- 用
.track把 agent instrument 起来 - 声明一个
opik.Config - 生产里出故障
- Ollie 读 trace、读源码、出 fix
- 你 approve
- Ollie 在 Sandbox 里拿原始失败输入重跑 agent
- Fix 通过 → 保存为新 Blueprint → environment pointer 升 staging
- 原始失败锁为 regression test
- 下一条故障从顶部进同一圈
每一轮循环，harness 变得更难被打穿。
这条产品在替什么挡刀
Opik 切的是 Agent 工具链右半边——从 trace 到 locked regression test 这一段，过去由 on-call 工程师盯。Cursor 团队说 harness 工程是无限游戏，Opik 直接把「trace 后那一段」也变成自动化。这条产品定位和 Cursor 描述的「人工修复循环」正好互补：Cursor 的 Cursor Agent 已经把 harness 左半边（trace 之前）做到极致，Opik 把右半边（trace 之后）也包进来。
对 2026 年把 agent 跑在生产里的团队来说，这是一条真缺口——不是「又有一个 observability 工具」，是「observability 终于接上了」。生产里跑的 agent 越多，harness 的复杂度增长越快，人盯的回报越低，自愈循环的边际收益越高。
是否要看一眼，看你 agent 现在多大程度上「挂掉之后要人盯」。 如果你还在用一份 Langfuse / Helicone / Phoenix / LangSmith 之类的 trace 平台 + 一个 Slack on-call 群手动对线 root cause，Opik 这条路径值得放进评估清单。