当我们让智能体舰队全天候运行时，什么出了问题（不是提示质量）

大多数关于自主智能体的讨论集中在推理基准或巧妙的提示模式上。在生产环境中，我们几乎没有灾难性故障是由于LLM推理失败引起的。它们源于框架和管道的崩溃。当你让智能体全天候并行运行任务时，真正的瓶颈是那些乏味的分布式系统问题：静默的模式漂移比完全崩溃更糟糕。上游重命名了API响应键或添加了意外的枚举。查询仍然以200 OK状态执行。智能体没有失败，而是合理化了缺失的字段，抓取相邻的数字列，并以100%置信度报告幻觉。如果你在绑定时不识别模式并关闭到死信队列，下游状态会静默地被污染。未协调的重试会触发429错误洪流。标准的指数退避包装器将速率限制视为急性峰值。当6个并行子智能体暂停进行退避并在几乎相同的毫秒内唤醒时，它们不会恢复——它们形成了雷群效应，直接撞上OpenAI的slow_down代码。并发治理不能存在于提示循环中；它需要客户端网关准入控制，并带有严格的加速/斜坡平滑。转录是审计日志，而不是工作记忆。在智能体之间传递原始对话历史是触发令牌最大化的最快方式。下游工作者花费一半的上下文窗口重新发现已经最终确定的决策。我们转而传递不可变的工件指针（收据哈希）而不是原始工具返回。很好奇这里的其他团队是如何构建生产交接的——你们是在传递修剪后的对话历史，还是将工具返回严格视为版本化的外部工件？