Kalibr：如果你手动调试Agent，你已经落后了

Source: Dev.to

有一个瓶颈正在扼杀生产环境中的 AI 代理。
这并不是模型质量、提示词或工具的问题。
瓶颈是你——更准确地说，是一种假设始终有人类在场维持运行的架构。

某些东西出现退化。必须有人类注意到、诊断、决定要更改什么，并部署修复。
这个循环就是限制因素。它慢、间歇性、夜间不工作，且无法扩展到每小时做出数千次决策的系统。

什么是代理可靠性

这就是当前的默认设置。

代理的成功率会略微下降。没有错误。JSON 仍然通过验证。日志看起来正常。但随着时间推移，延迟漂移，成功率下降，成本上升，边缘案例堆积。

最终有人注意到，警报触发，或客户投诉。于是流程开始：检查仪表盘，深入追踪，争论是模型、提示词还是工具的问题，发布更改，并希望它有效。

• 最佳情况： 恢复需要数小时。
• 典型情况： 需要数天。
• 最坏情况： 从未发生，因为没人注意到。

这就是 2026 年生产环境中“自主代理”的实际表现。

为什么这是一次架构失败

在其他所有成熟系统中，人类并不负责实时路由决策。

• 人类不进行数据包路由。
• 人类不对数据库进行再平衡。
• 人类不决定容器的运行位置。

如果把后端描述为“我们依赖工程师监视仪表盘并在出现故障时手动切换”，听起来会像个笑话——或者是2008年的一家创业公司。之所以把这些决策交给系统，是因为人类在可靠地做大量快速、重复的决策方面表现不佳。代理也没有本质区别；只不过我们尚未构建相应的抽象。把监视仪表盘和调节配置视为可接受的做法只是一种权宜之计，而不是解决方案。

当你去除人工环路会发生什么变化

想象一个系统，其中每个模型‑工具组合都被视为一条路径。每次执行后都会报告结果，概率在线更新，性能变化时流量会自动转移。当出现退化时，系统会绕过它——没有警报、没有仪表盘、没有事故。从用户的角度来看，什么也没有坏掉。

这不是优化，而是另一种可靠性模型。这正是 Kalibr 所做的：它学习在给定目标下哪些执行路径效果最佳，并相应地进行路由，而无需人在恢复环路中介入。可靠性始终是首要目标；其他考虑只有在成功得到保证后才会重要。

为什么这会随时间复合

• 一个持续运行的系统会收集干净的结果数据，学习更快，并持续改进。
• 一个宕机的系统会产生噪声数据，需要事后分析才能运行，并且每次故障时学习速度都会变慢。

人类仍然的作用

这并不是关于“取代人类”。人类仍然：

• 定义目标。
• 设计执行路径。
• 决定成功的意义。
• 改进策略。

人类只需停止为概率系统进行事件响应，而是转向更有杠杆作用的上游环节。任何需要人类日常维持运行的代理系统，都将输给只需要人类来改进的系统。

后果

• 可观测性是必要的，但不足以解决全部问题。
• 离线评估有用，但并不完整。
• 人在环中的调试无法规模化。

内部化这些理念的团队将交付真正有效的代理系统；其余团队则会继续在同样的火灾中苦苦挣扎。

这是一种决策边界的转变

• 可观测性工具： 将数据交给人类；人类决定。
• 路由系统： 将决策移入系统；人类监督。

这种区别很重要。当决策边界转移时，基础设施会进步：TCP 将数据包路由移至网络，编译器将硬件翻译移至软件，Kubernetes 将调度移至控制平面。决定当前代理应使用哪种模型也属于同一类。

在此失效的情况

There are limits:

• Cold start 仍然需要判断；每条路径大约需要 20–50 个结果，路由才能变得自信。
• Bad success metrics 会导致糟糕的优化。
• 某些任务本质上是模糊的。

These constraints define the boundary of where this approach works; they don’t change the direction of travel.

我所打的赌

代理已经在做比人类能够合理监督的更多的决策。将人类从可靠性循环中移除的抽象将会获胜，因为注意力是无法扩展的。这样的抽象必然会出现。

这就是我创建的公司：Kalibr。如果你的代理每天要做同样的决策数百次甚至上千次，这个问题已经在耗费你的成本。如果你仍然在手动为单个代理接线，你现在可以忽略它——但不会太久。