Kalibr：用于 Agent 自我优化的基础设施

Source: Dev.to

大多数代理今天会因为与逻辑错误无关的原因而崩溃。它们在一个永远无法保持稳定的环境中盲目运行，静态路由根本无法存活。模型行为会变化，提供商延迟会波动，工具会悄然退化，速率限制会莫名出现，JSON 解析在负载下表现也会不同。每个变量都是移动的目标，开发者被迫用只能捕获真实行为一小部分的日志来调试后果。

系统越大，盲目程度越严重。当一个复杂的代理系统在真实生产环境中出现可变性时，人为的优化就会变得事后且过时。这一瓶颈正在扼杀代理的采纳。

我们构建了 Kalibr 来消除它。

Kalibr 在每一次代理运行时捕获步骤级遥测，将这些数据聚合为真实系统情报，并为代理提供一个简单的 API，让其根据当前整个系统实际有效的情况，选择最安全、最便宜或最快的执行路径。

一行代码。
代理不再因你无法控制的原因而失败。

为什么代理会崩溃

现代多代理系统在 GPT、Claude、Gemini、内部工具和外部 API 之间生成成千上万的分支 LLM 调用。这些组件没有一个是稳定的；它们全部在漂移。

开发者无法回答基本问题：

• Why did cost jump 300 % this morning
• Why did latency triple on the same workflow
• Why is GPT hallucinating in a branch that worked yesterday
• Why does the same agent behave differently on the same input
• Where is the actual bottleneck in this chain of calls

仪表盘只能在它们“死掉”之后才显示内容。人工调试总是滞后；当你注意到问题时，优化已经过时。这个领域需要实时、运行时的情报，而不是事后分析。

Kalibr 的功能

1. 自动遥测捕获

每一次对 OpenAI、Anthropic、Google 以及本地模型的调用都会被拦截，且无需更改你的工作流。Kalibr 捕获：

• 持续时间
• 令牌使用量
• 成本
• 成功或失败
• 模型和提供商
• 父/子关系
• 时间戳

你的代理代码保持不变；SDK 会包装这些调用。这一基础层使得后续所有功能成为可能。

2. 多代理系统的分布式追踪

Kalibr 为每个工作流重建完整的执行图。如果某个分支崩溃，你可以看到：

• 崩溃发生的位置
• 崩溃的原因
• 导致它的上游决策
• 它触发的下游影响

类似 Datadog 的追踪，但专为代理工作负载而非微服务设计。

3. 智能 API

在代理执行一步之前，它可以向 Kalibr 提出唯一的问题：现在什么在工作？（不是上周，也不是几个月前你提交的路由文件）

Kalibr 根据以下因素返回模型推荐：

• 实时成功率
• p50 与 p95 延迟
• 成本漂移
• 波动性
• 错误模式
• 整个系统最近的失败

路由从猜测转变为数据驱动的决策。

4. TraceCapsules 用于交接

当 Agent A 将任务交给 Agent B 时，B 会继承完整的执行历史：

• 使用了哪些模型
• 花费了多少
• 哪些失败
• 哪些成功

该胶囊随工作流一路传递直至完成。每一次跳转都会扩展记录，默认提供端到端的透明度。

5. 跨代理的共享学习

一个代理失败 → Kalibr 记录 → 下一个代理避免同样的错误。无需重新训练管道、共享代码或人工干预。情报层在系统运行时持续更新，阻止病态失败永远重复。

为什么这层不是可选的

代理运行在不稳定的环境中：

• 模型性能波动
• 成本变化
• 速率限制激增
• 外部工具退化
• 输入混乱
• 输出在不同运行间差异显著

所有这些都比人类的反应速度快，影响可靠性、正确性和成本。静态路由在面对现实时会瞬间失效。人工调试无法扩展。模型供应商永远不会公开跨供应商的洞察，仪表盘也无法为未来决策进行优化。如果代理要在真实工作负载中生存，它们需要一个共享的大脑——Kalibr 就是这个大脑。

结果

没有 Kalibr 时

• 代理盲目运行
• 失败无限循环
• 成本突增毫无预警
• 漂移无从解释
• 每个代理各自为政
• 规模扩展导致可靠性崩溃

有了 Kalibr 时

• 代理自动选择最优路径
• 失败转化为系统级学习
• 实时可视化取代猜测
• 路由变得自适应且稳定
• 成本和延迟趋于平稳
• 随系统运行，可靠性提升

我们正在构建代理系统在大规模下运行所需的情报基底。

1. 安装 SDK。
2. 包装你的 LLM 调用。
3. 让系统自我学习。

代理从未拥有先见之明。现在它们拥有了。