我让一个代理处理太多任务，结果它以四种不同方式失败。关于防护栏和交接的AMA

不久前，我一直试图让一个代理同时处理录入、查询、系统更新和最终回复。这在纸面上看起来很高效，但实际上却是一团糟，而且这些失败异常难以捕捉。明显的故障是糟糕的工具调用和缺失字段。更隐蔽的是：更新了错误的记录、基于过时上下文自信回复、几乎没有有用状态就移交给人类。这些东西在涉及真实客户之前似乎还行。# 我常看到的问题 大多数失败并非模型智商问题。通常属于以下之一：* **流程不明确**，导致代理猜测自己处于哪一步 * **源数据质量差**，检索看似正确实则不然 * **过早给予过多自主权**，尤其是在写入和外部操作方面 * **交接薄弱**，人类得到输出却没有推理过程或证据 * **缺乏成功指标**，所以人们说感觉有帮助，而运维团队却还在收拾残局 对我改变最大的模式是尽早拆分角色。一个代理负责录入/分类，一个负责研究/上下文，一个负责行动，如果工作流敏感，有时再加一个负责QA。这是个无聊的修复，但老实说比又一轮提示微调更有用。# 真正有帮助的防护栏 有几件事比预期的更有效：* 在使用任何工具前强制执行结构化输出 * 让代理注明它使用了什么内部来源，即使只是为了记录 * 限制写入权限，直到评估不再随机 * 将**交接设计**视为产品表面，而非事后考虑 我仍然认为交接在代理设计中被低估了。如果代理无法完成，人类应该得到当前状态、它尝试了什么、什么失败了、以及什么看起来有风险。而不是一句模糊的“需要审核”备注。总之，我花了很多时间处理这种混乱，在真实业务流程中调试代理，这些流程半文档化，每个工具都有自己奇怪的小毛病。我很乐意讨论失败模式、防护栏、评估、多代理拆分，或者为什么某些自动化应该保持部分自主。你们最近的代理设置中最烦人的失败模式是什么？