数月生产环境中的代理崩溃教训：为何简单构建胜出

当围绕自主多代理群体的炒作开始时，我构建了一个复杂的助手来端到端地规划、执行和自我修正工作流程。上线后几周内，它变成了一个难以维护的token陷阱，在推理循环中深入四步后迷失方向，且静默失败而不抛出错误。很快我明白，构建真实代理最困难的部分不是让模型更智能，而是在LLM偏离时构建外部护栏，确保系统保持在正轨上。突破来自于放弃开放式规划器架构，转而采用严格的每代理一任务模式。给每个代理一个狭窄的任务，并明确状态边界，消除了大部分边界情况故障。无需指望主代理处理整个流水线，而是隔离具有严格输入和输出契约的微代理，使系统变得确定且易于调试状态转换失败。我们还学会了通过关注爆炸半径来平衡人在回路控制：低风险的内部任务自主运行，而任何不可逆的外部写入都需要一次点击的人工批准。如果你目前被框架选择压得喘不过气来，请停止追逐复杂的抽象。将语言模型视为一个优秀但不可预测的子组件，而不是整个架构，并专注于稳固的状态管理和错误恢复。