6 月 26 日，Comet 旗下的开源项目 Opik 发了 2.1.5 版本。
这次更新本身不算大，但它戳中了一个越来越尴尬的问题：AI 应用跑进生产环境以后，出了错到底怎么查？
以前写个接口，报错了还能看状态码、异常栈、请求参数。现在换成 Agent，事情就没那么清爽了。它可能先检索，再调用工具，再让模型判断，再把结果拼起来。最后用户只看到一句回答，工程师面对的是一串黑盒操作。
一句话，AI 应用开始需要自己的行车记录仪了。
Opik 想做的，差不多就是这件事：给 RAG、代码助手和 Agent 系统装一个“黑匣子”。
AI 应用的问题，已经不只是“能不能跑”
Opik 的官方说法是开源 AI Observability、Evaluation 和 Optimization 平台。说人话，就是帮开发者记录调用链、评估输出质量，再把这些结果拿来调 prompt、调工具、调流程。
它盯的不是单次聊天，而是完整应用：RAG 聊天机器人、代码助手、复杂 Agent 工作流，都在它的范围里。
这个项目现在接近 2 万 Star ，许可证是 Apache-2.0 ，可以自托管，也可以用 Comet 的云服务。数字不是重点，重点是这类工具开始频繁出现在开发者视野里。
原因也简单。AI 应用变复杂了。
一个 Agent 出错，可能不是模型“笨”这么简单。检索材料可能错了，工具可能选歪了，上下文可能被前一步污染了，也可能是评分规则压根没跟上业务变化。
没有 trace，最后只能靠猜。
2.1.5 主要在补线上评分
这次 2.1.5 的 release note 里，最有用的不是花哨功能，而是几个偏后端的改动。
| 2.1.5 | |
| 2026-06-26 10:31 UTC | |
| Apache-2.0 | |
第一处，是 reactive online-scoring enqueue。可以把它理解成：线上评分任务怎么更稳定地排队、入队、打指标。
这听起来很工程，甚至有点无聊。但生产系统里，很多真正要命的问题都藏在这种“无聊”的地方。评估任务能不能可靠进入队列，失败时有没有指标，工作区维度能不能分清，都会影响后面排查。
第二处更有意思：线上 LLM-as-a-judge scorer 可以读取并推理 trace attachments。
很多 AI 应用的判断依据不只是一段文本。一次调用可能带着截图、文件、检索片段、工具返回结果，甚至还有中间过程附件。如果评估器只能看最后那句回答，就像医生只看出院小结，不看检查报告。
Opik 这次补的，是让评估器看到更多上下文。
让模型当裁判，听起来怪，但工程上有用
“LLM-as-a-judge”这个词现在已经不新鲜了。用一个模型评价另一个模型的输出，听上去多少有点“自己人审自己人”。
但很多 AI 应用确实没法靠传统单元测试解决。
客服回答有没有答到点上？RAG 有没有编？代码助手有没有遵守约束？Agent 调工具的顺序合不合理？这些问题不是简单的 yes/no，也很难给每一种情况写标准答案。
所以更现实的做法，是把评估流程固定下来：数据集、实验、评分器、线上规则、人工反馈，各自留下记录。分数不一定是真理，但至少能比较版本，能发现回退，能知道问题是从哪次改动后开始变多的。
Opik README 里提到，它面向高流量生产 trace 设计，规模说法是 每天 4000 万条以上 trace 。这个数字对多数团队来说用不上，但方向很清楚：这不是给本地 demo 看看的小插件，而是往生产监控走。
Agent 出问题，换模型不一定救得回来
现在很多 AI 产品一出问题，第一反应是：换更强的模型。
有时候有用。有时候只是把问题藏得更深。
Agent 系统不是一次问答。它是一串动作：检索、规划、调用工具、改文件、再验证。每一步都可能出错，而且前一步的小偏差会滚到后面。
用户看到的是一个结果。工程师真正需要看的，是整条链路。
这也是 Opik、LangSmith、Langfuse 这类工具会被放在一起讨论的原因。大家不是突然迷恋仪表盘，而是 AI 应用也开始需要自己的日志系统。
传统软件有日志、APM、指标、告警。AI 应用也需要这些东西，只是里面多了 prompt、上下文、模型输出、工具调用、评分器和人工反馈。
Opik 更像质检员，不是魔法棒
Opik 不训练模型，也不替你写 Agent 框架。
它更像站在生产线旁边的记录员和质检员：模型什么时候被调用，拿了什么上下文，用了哪个工具，评分器怎么判，哪个版本的结果更稳，都尽量留下痕迹。
从 README 看，它已经在接主流工具链：LangChain、LlamaIndex、OpenAI、Anthropic、Google ADK、Autogen、AG2、Flowise AI 等等。路线很明显，往 AI 应用生命周期里钻：开发、测试、上线、监控、优化。
但它也不是万能答案。
LLM-as-a-judge 本身会有偏差。评分提示词写得不好，结果也会跟着歪。线上评估适合做趋势监控、风险筛查和版本对比，不适合被当成“自动真理机”。
医疗、金融、法律这类高风险场景，更不能把模型评分直接当最终结论。该有人审的地方，还是得有人审。
热闹背后，其实是 AI 工程化变重了
Opik 不是突然冒出来的新项目。它 2023 年就创建了，真正值得看的是，它到 2026 年还在高频更新，而且更新点越来越贴近生产环境。
这和 AI 应用这两年的变化对得上。
一开始，大家问模型能不能答。后来，大家问 Agent 能不能干活。现在问题变成：干完活怎么验收？出错之后怎么复盘？版本升级以后，怎么知道没有把旧能力搞坏？
这没有发布新模型那么刺激，但更接近软件工程的日常。
AI 应用要长期跑，不能只靠几段漂亮 demo。它需要日志，需要回放，需要评估，也需要上线后的持续观察。
Opik 这类工具的价值，大概就在这里：它不负责让 AI 看起来更聪明。它负责帮团队看清楚，AI 到底聪明在哪一步，又是从哪一步开始犯糊涂的。
附链接
Opik GitHub：https://github.com/comet-ml/opik Opik 2.1.5 Release：https://github.com/comet-ml/opik/releases/tag/2.1.5 Opik 文档：https://www.comet.com/docs/opik/
