你的代理工具链应该能自我修复

当AI代理在生产环境中失败时，你的可观测性工具只会精确展示它做了什么，却几乎不告诉你如何修复。

你会看到一次运行的完整追踪：每次模型调用和工具触发、每个步骤耗时、以及消耗的token成本。

但你得不到的是：它为什么出问题、什么改动可以修复它、或者任何保证同样的事情下周不会再次发生。

于是你逐段滚动查看追踪跨度，形成关于哪里出错的推测，手动写一个补丁，并祈祷它不会破坏之前正常工作的部分。

然后一个新模型发布，带来一批全新的失败模式，你又得从头跑一遍整个手动循环。

真正的瓶颈不是你的可观测性。而是追踪信息落在你屏幕上之后必须发生的所有事情。

虚线左侧的一切自动运行。虚线右侧的一切消耗你的时间，而生产调试恰恰就发生在这里。

虚线左侧的一切自动运行。虚线右侧的一切消耗你的时间，而生产调试恰恰就发生在这里。

Cursor最近分享了围绕其代理的工具链需要投入多少工程工作——那一层包裹在原始模型周围的提示、工具和检查。在同一个模型上使用更好的工具链，结果会好得多，而且这项工作永无止境。

这就是每个可观测性平台留给你的境地。它回答了“发生了什么”，然后把“为什么发生”、“该改什么”、“如何防止再次出问题”交还给你。

这个差距正是今天大多数团队陷入的循环。下面是为什么这个差距会反复出现，以及最终需要什么来弥合它。

为什么当前的可观测性在大规模下会崩溃

大多数代理可观测性平台提供一条追踪后就停止了。

你得到一个跨度树、延迟数字、token成本和仪表盘。你得不到的是：它为什么失败、该修复什么、或者任何保证它不会再次出问题。

• “发生了什么” → 平台处理
• “为什么发生” → 手动
• “这是修复方案” → 手动
• “这不会再出问题” → 手动

这在2023年是一个合理的产品。但对于今天在生产环境中运行代理的团队来说，这是一个错误的抽象。

问题会不断累积。每次模型升级都会引入新的失败模式。每个新工具都会增加新的边缘情况。工具链变得越来越复杂，任何团队都无法手动追踪和修复。

下面就是解决这个问题的栈。

大多数平台止步于仪表盘，把剩下的交给你。右侧是Opik自行运行的循环。

大多数平台止步于仪表盘，把剩下的交给你。右侧是Opik自行运行的循环。

Opik：面向代理时代的AI可观测性与评估

Opik是一个开源的日志记录、调试和优化平台，专为AI代理和LLM应用打造。Opik的核心理念是：这个循环应该自动化，而不是靠人力填充。

四层堆栈

Opik的架构是一个连贯的工作流。

追踪 → Ollie诊断 → Ollie提出修复 → 修复被应用并验证 → 测试套件将失败锁定为回归测试 → 回到追踪

这四层不是独立的功能。它们在一个闭环中相互供给，自行完成闭环。

这四层不是独立的功能。它们在一个闭环中相互供给，自行完成闭环。

下面是每一层。

第一层：追踪

所有LLM调用、工具调用和检索步骤通过一个装饰器自动进行检测。

import opik

@opik.track
def my_agent(query: str):
    # 你的代理逻辑
    ...

开箱即用，支持LangGraph、CrewAI以及50多个框架。每次追踪都会记录当前活跃的代理配置，以便后续需要重新运行失败的输入时完全可复现。

这四层不是独立的功能。它们在一个闭环中相互供给，自行完成闭环。

这四层不是独立的功能。它们在一个闭环中相互供给，自行完成闭环。

第二层：Ollie

其他任何可观测性平台都止步于“这是你的追踪”。而Opik从追踪到修复代码，由Ollie驱动。

Ollie是内置于Opik中的编码代理。一个代理，完整上下文。

Ollie在侧面板中处理修复，只有在你批准每个步骤后才会读取和编辑文件。

Ollie在侧面板中处理修复，只有在你批准每个步骤后才会读取和编辑文件。

在没有代码访问权限的情况下，Ollie也能读取跨度树，识别失败模式，并解释跨越所有LLM调用的因果链。问它“为什么最终答案忽略了检索到的上下文？”，它会遍历整个跨度树，找出根本原因。

从项目根目录运行 opik connect，Ollie 就会升级到完整代码修复模式：

• 读取你的源文件
• 找出负责的确切代码行
• 提出一个差异(diff)；未经你明确批准，不会做任何更改

一旦你批准，Ollie 会针对原始失败追踪中的确切输入重新运行你的代理，流式输出新的追踪以便并排比较，并将原始失败锁定为测试套件中的一个回归用例。

坏追踪 → 根本原因 → 差异 → 批准 → 重新运行 → 回归锁定

从坏追踪到锁定回归测试的完整路径，你唯一的手动步骤就是批准。

从坏追踪到锁定回归测试的完整路径，你唯一的手动步骤就是批准。

第三层：测试套件

大多数评估工作流：构建一个带标签的数据集，定义一个数值指标，比较浮点数。这种模式对研究人员有用，不符合工程师思考质量的方式。

Opik用纯英语断言取而代之。

suite = opik.TestSuite("crm-agent-v2")
suite.add_assertion("响应必须包含具体的交易细节，而不仅仅是数量")
suite.add_assertion("响应绝不能泄露未经授权信息")
suite.run_tests()

Opik 在底层将其转换为LLM作为裁判的检查。每个测试用例清晰显示通过/失败。

一个基于真实失败构建的回归套件，每个断言都写成一个纯英语检查。

一个基于真实失败构建的回归套件，每个断言都写成一个纯英语检查。

改变工作流的部分是：你调试的每个失败追踪会自动成为一个新的测试用例。套件从真实的生产失败中成长，而不是某人提前编写的合成场景。

每一个循环，工具链都更难被破坏。

但即使有不断增长的测试套件，你仍然需要一个安全的地方来测试更改后再发布。这就是第四层的用途。

第四层：代理沙盒

大多数游乐场是提示游乐场。你更改系统提示并重新运行一次LLM调用。这回答了一个错误的问题。

生产环境的问题是我更改了这个之后，整个代理图会发生什么。

Opik 的代理沙盒在UI内部端到端运行完全可检测的代理。更改提示、切换模型、添加工具，然后观察整个系统在完整跨度树上的响应。每次沙盒运行都会生成一个完整的Opik追踪。

非开发人员利益相关者、产品经理、领域专家和QA可以安全地测试配置，而无需接触git。

实践中的飞轮效应

这些层不是独立的功能。它们是一个循环。

用 @opik.track 进行检测。声明一个 opik.Config。生产环境中发生了失败。Ollie 读取追踪，读取你的源代码，并建议一个修复方案。你批准。Ollie 在沙盒中针对原始失败输入重新运行代理。修复通过。保存为新的蓝图。环境指针提升到staging。原始失败锁定为回归测试。

同一个循环从头到尾画出来，从检测你的代理到下一个失败进入顶部。

同一个循环从头到尾画出来，从检测你的代理到下一个失败进入顶部。

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

每一个循环，工具链都更难被破坏。

闭环

当代理很简单的时候，以追踪结尾的可观测性是合理的。一旦它们进入生产环境，真正的工作在追踪之后才真正开始，而这正是Opik为你运行的，而不是把它留在你的盘子里。

整个堆栈都是开源的：追踪、Ollie、测试套件、代理沙盒、一个6算法的代理优化器，以及50多个框架集成，项目在GitHub上已超过19.3K星。

三个命令即可自托管：

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

Cursor描述的那个手动循环，正是Opik自行闭环的——从一条坏追踪一直到锁定一个回归测试。

如果你在生产环境中运行代理，值得一看。

查看 Comet ML 和 Opik →

（别忘了给星星 🌟）

你代理栈中的可观测性目前处于什么状态？你们的调试循环现在在哪里断开？

如果你正在构建一个AI工程师会喜欢的开源工具，请联系我们。我们只报道通过我们自己测试的工具，所以我们会先试用你的，只有它表现良好我们才会写。

感谢 Comet ML 赞助本期内容。