当一个多代理系统在生产环境里突然给出错误答案时，你拉开观测面板，看到的是一棵结构清晰的 span 树：每一个 LLM 调用、工具执行、检索步骤的耗时、token 消耗、输入输出都记录得清清楚楚。

可当你想知道“为什么最终答案忽略了检索到的关键上下文”时，这棵树突然变成了沉默的档案。你只能一层层展开 span，手动拼凑因果链，写一个补丁，再小心翼翼地部署，祈祷它不会把原本正常的功能也带崩。

新模型一发布、工具 schema 一微调，同样的失败模式很可能换个面貌卷土重来。你又回到原点，重复整个手动循环。

这不是工具不够好，而是整个观测范式在 agentic 时代遇到了结构性天花板。

Trace 之后，团队真正卡住的地方

传统观测平台把“发生了什么”做到了极致，却把“为什么发生”“该怎么改”“怎么确保下次不复发”全部留给人工。

这四个环节的断层，在 agent 复杂度指数级上升时被无限放大：

• 模型每更新一次，就引入一批新的 failure mode；
• 工具和检索链路每增加一层，边缘 case 就多一层；
• harness（提示词、工具选择、检查逻辑）的复杂度增长速度，远超团队手动追踪和修复的速度。

结果是：团队把大量高价值工程时间，消耗在低信号的“读 trace → 猜原因 → 手写 patch → 希望没副作用”这个循环里。

我起初以为，只要 tracing 足够细 + 加上 LLM-as-a-judge 就能解决大部分问题。但当真正面对生产级多步 agent 时才发现：可见性只是起点，真正的战场在 trace 落地之后。

Opik 用四层栈把这个循环闭合了

Opik（Comet ML 出品的开源项目）把“观测之后必须发生的事”做成了一个连贯的工作流：Trace → Ollie 诊断 → 提出修复 → 审批验证 → 自动锁定回归测试。

整个流程不是四个独立功能，而是一个自我强化的飞轮。

Layer 1：Tracing
一行装饰器即可自动捕获所有 LLM 调用、工具调用和检索步骤，支持 LangGraph、CrewAI 等 50+ 框架。每次 trace 还会记录当时的 agent 配置，实现失败输入的精确重放。

import opik

opik.configure(use_local=True)  # 或连接云端

@opik.track(project_name="production-agent")
def run_multi_step_agent(query: str):
    # 你的 agent 逻辑：规划 → 检索 → 工具调用 → 最终回答
    ...
    return final_answer

Layer 2：Ollie（核心差异化能力）
这是目前大多数观测平台缺失的一环。
Ollie 是一个内置的 coding agent。它能直接读取 span tree，跨多个 LLM 调用追踪因果链，回答“为什么最终答案忽略了上下文”这类问题。

当你在项目根目录执行 opik connect 后，Ollie 获得代码访问权限：
它会定位到具体 responsible lines，生成精确的 diff 提案。没有任何变更会自动应用，必须由你显式审批。审批后，它会用原失败输入在 Sandbox 中重跑，并把这次 trace 与原 trace 并排展示。

Layer 3：Test Suites（从真实失败中生长）
不再依赖提前写好的合成数据集。
Opik 支持用自然语言描述期望行为（例如：“最终答案必须包含检索上下文中的关键事实”），底层自动转为 LLM-as-a-judge 检查。

更重要的是：每一次被调试过的失败 trace，都会自动变成一个新的回归测试用例。测试套件不是静态的，而是随生产真实故障持续生长。harness 每经历一次失败，就多一层防护。

Layer 4：Agent Sandbox
不是简单的 prompt playground，而是完整 agent graph 的端到端运行环境。
你可以在 UI 里修改系统提示、切换模型、增减工具，立即看到整个 span tree 的变化。产品经理、领域专家、QA 都能安全参与验证，而不需要动 git。

传统观测 vs Opik 四层栈的真实差距

维度	传统观测平台	Opik 四层闭环	实际影响
Visibility	Trace + 指标 + Dashboard	同上 + 完整可重放上下文	基础能力相当
根因诊断	完全手动	Ollie 自动跨调用因果链分析	诊断时间大幅缩短
修复建议	工程师手写	Ollie 提出精确 diff（需审批）	减少低水平重复劳动
回归防护	手动补充测试	失败 trace 自动转回归测试	防止同一类问题反复出现
变更验证	局部 prompt 测试	全 agent graph Sandbox 重跑	降低引入新 bug 的风险
长期演进	静态或缓慢迭代	每一次失败都让 harness 更强	形成 compounding 优势

为什么“自动化低信号，保留高信号人工”才是可持续路径

Ollie 不会自动合并代码，这不是技术做不到，而是刻意保留的信任边界。
全自动合并会让团队快速失去对系统的掌控感；而把诊断、diff 生成、回归锁定这些低信号重复劳动自动化，只把最终审批权留给人，才是真正 scalable 的做法。

我后来反复想：真正的护城河从来不是模型参数多几亿，而是让每一次生产失败都自动转化为系统的免疫记忆。一次失败如果只是被解释清楚而没有被锁进测试套件，那它下个月大概率还会回来。

这个闭环正在重新定义 Agent 工程的竞争力来源

当 agent 从 demo 走向生产，团队花在“读 trace 然后手动修”的时间，很快会成为最大的隐性成本。
而把这个循环闭合之后，工程师可以把精力集中在更高阶的系统设计、工具选择和业务逻辑上。

Cursor 团队分享过，他们在同一个模型上投入了大量工程构建 harness，才获得了远超基线模型的效果。Opik 做的，正是把“构建和持续强化 harness”这件事，从纯手动劳动，变成一个有反馈闭环的工程实践。

如果你正在运行生产级 AI Agent，不妨问自己一个问题：
你的团队目前把多少时间花在“读完 trace 之后的手动循环”上？这个循环断在诊断、修复，还是防止复发这个环节？

Opik 已经开源（GitHub comet-ml/opik，star 数已超 19k），可以用三条命令自托管。把你遇到的第一个 failing trace 扔给 Ollie 看一看，或许会让你对“观测之后真正需要发生什么”有新的理解。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。