每天替我做1000个决定的AI系统，我在哪画了红线

CostGuard的代理端点会对每个经过的大语言模型调用做出自主决定。它对响应打分，与阈值比较，在约1毫秒内完成接受或拒绝，全程无人参与。

起初这感觉是对的。快速、自动化、可扩展。这正是大语言模型可靠性层该有的样子。

直到我查看了它实际捕获了什么——更重要的是，它遗漏了什么——我才不得不重新思考：自动化该止于何处，人工判断又该从哪开始。

这是我在构建一个处于生产级大语言模型管道关键路径的系统时学到的东西，也是我现在认为"人在回路"设计是一项工程决策、而非仅仅是伦理决策的原因。

CostGuard实际做什么

CostGuard是一个HTTP代理，包装你的大语言模型调用。你把智能体的请求路由到它，而不是直接发给供应商。每次调用时，它会：

• 检查供应商的熔断器状态
• 发起大语言模型调用，30秒超时
• 用启发式有效性评分器给响应打分（约1毫秒）
• 若分数低于阈值则拒绝响应，回退到下一个模型
• 记录成本、延迟、有效性分数及是否使用了回退

这些决定全是自动化的。无人参与。在生产规模下这是正确的选择——你无法让人工审查实时管道中的每个大语言模型响应。

但自动化的效果取决于评分器实际能检测到什么。

我在自己README里记录的缺陷

CostGuard的/proxy端点中的启发式评分器，通过奖励统计标记——置信区间、p值、不确定性语言——并惩罚失败信号（如空输出、错误堆栈、拒绝短语）来工作。

它能可靠捕获明显的失败。返回空字符串、错误信息或"我无法帮助这个"的模型，每次都会被拦截。

它无法捕获的是：生成流畅、自信、统计上站不住脚的分析的模型。

一个用错误方法论生成听起来合理的置信区间的模型，在任何阈值下都能通过启发式过滤器。这是CostGuard README中"已知限制"部分的原话。

我在发布前就把这写进了文档。不是作为未来改进，而是作为塑造系统使用方式的硬性约束。

因为基准数据说明了问题。在RealDataAgentBench的1,412次运行中，最常见的失败模式不是模型拒绝或产生错误。而是模型在底层推理破损的情况下，生成看起来正确的输出。

一个模型计算出了正确的特征重要性。正确排序。然后停了——没有置信区间，没有跨折的稳定性检查，没有过拟合风险的提示。

正确性分数：1.0。统计有效性分数：0.25。

CostGuard关键路径中的启发式评分器无法区分这些。这不是用更好的正则表达式就能修复的bug。这是在1毫秒内、不运行完整评估的情况下，所能检查的内容的根本限制。

工程上的权衡

1毫秒的限制是真实的。生产管道不能为每次调用等待数秒。这意味着某些检查在架构上就不可能放在热路径中。

我画的红线：启发式评分器只负责它擅长的——捕获明显失败。任何需要理解方法论正确性的判断，必须移到异步的人类审查流程中。

这不是理想设计。这是承认工程约束后的务实选择。自动化处理它能处理的，人类接手其余部分。

问题在于，很多系统假装这条线不存在。它们把启发式评分包装成"质量保证"，让用户误以为流畅的输出等于可靠的输出。

CostGuard的文档明确说了不能做什么。这限制了它的卖点，但定义了它能被信任的范围。

实际运作方式

现在系统有两条路径。热路径：1毫秒决策，捕获明显失败。冷路径：完整评估，标记方法论问题供人工审查。

大多数调用走热路径。可疑输出进入冷路径。人类每周审查一次批量结果，调整阈值，偶尔发现评分器遗漏的模式。

这个设计增加了复杂性。需要维护两条路径，管理队列，处理审查延迟。但替代方案更糟：要么过度拒绝（把好的输出也拦掉），要么盲目信任（让破损的推理溜过去）。

我见过太多系统选择后者，因为"准确率99%"的指标好看。它们不告诉你的是，那1%的失败在关键任务场景中可能是灾难性的。

重新思考"人在回路"

这个短语常被当作伦理装饰——"我们有监督"的 checkbox。但我的经历让它变成了一项工程原则。

人在回路不是关于道德姿态。是关于识别自动化的硬边界，并设计系统在这些边界处优雅降级。

CostGuard的评分器有已知的盲区。与其假装能修复它们，我围绕它们设计了架构。热路径快速且自动化。冷路径缓慢且有人参与。两者之间的接口是系统最关键的部分。

这影响了我们如何设定阈值。不是优化单一指标，而是平衡三个变量：延迟、覆盖率、人工审查负担。降低阈值减少漏网之鱼，但增加误报和审查工作量。提高阈值则相反。

没有全局最优解。每个部署根据使用场景选择自己的位置。医疗诊断？低阈值，高审查负担。内容摘要？可以容忍更高阈值。

我现在的判断标准

构建自主决策系统时，我问我自己三个问题：

第一，这个决策的错误成本是多少？1毫秒评分器的错误是接受破损推理，成本是下游错误。拒绝好输出的成本是延迟和额外调用。前者在某些场景下可能致命。

第二，检测需要什么信息？置信区间是否有效，需要理解生成方法。这在1毫秒内做不到。任何声称能做到的系统要么在撒谎，要么在隐藏延迟。

第三，人类审查能否改进系统？如果审查结果不反馈到评分器，人在回路就只是昂贵的保险。CostGuard的审查日志用于调整启发式规则，缩小盲区。

这三个问题的答案决定了红线画在哪。不是基于"我们能自动化多少"，而是基于"我们在哪必须停止自动化"。

对构建者的建议

如果你在设计类似的可靠性层，先写下你的已知限制。不是事后，是在发布前。这会感到不舒服——它在承认你的系统不完美。但这定义了信任的基础。

区分"我们能检测的"和"我们假装能检测的"。前者进入自动化路径。后者需要人类判断或明确的不确定标记。

设计两条路径，而不是一条带有人类覆盖层的自动化路径。热路径和冷路径应该有清晰的接口，而不是模糊的"必要时升级"。

最后，把审查视为工程输入，不是合规 checkbox。人类发现的模式应该反馈到系统中，逐步缩小需要人工干预的范围。

这不是关于构建完美的自动化。是关于构建诚实的自动化——清楚知道它能做什么，不能做什么，并据此设计。

CostGuard每天做大约1000个决定。其中99%以上不需要人类。但剩下的那些，以及我们如何处理它们，定义了系统是否值得信任。

红线不是限制。它是设计的一部分。