多 Agent 与实时交互：协作不是把模型数量相加

当一个 Agent 的上下文、工具或任务跨度变得很大时，人们常常想到“再增加几个 Agent”。但多个模型并不会自动形成团队：如果没有清晰的职责、消息协议和完成标准，它们只会更快地产生重复工作和相互矛盾的结论。

一、什么时候值得拆成多个 Agent

单 Agent 更适合共享上下文、连续决策和需要频繁调整的任务。多 Agent 的价值通常来自隔离和并行：不同角色需要不同工具或知识，子任务之间相对独立，或者需要一个独立评审者检查主流程。

常见拓扑包括：

拆分前要先证明单 Agent 的瓶颈确实来自职责冲突、上下文过载或可并行性，而不是工具设计和提示词本身的问题。

共享上下文让协作简单，但容易把每个 Agent 的中间猜测全部扩散。隔离上下文可以减少噪声和权限范围，却需要显式传递任务契约与结果证据。

更稳妥的消息不应只是“我认为应该这样做”，而应包含：

任务：要解决什么问题
输入：使用了哪些事实和版本
结果：完成了什么
证据：测试、文件、接口或引用
未决：哪些内容仍不确定

汇总者只接收必要事实和证据，必要时再向子 Agent 请求细节。这样可以控制上下文增长，也能减少未经验证的推理在团队中传播。

多 Agent 系统至少要定义三种状态：成功、失败、结果未知。执行者超时后，管理者不能直接派另一个 Agent 重做可能已经完成的副作用；应该先通过任务 ID 或幂等状态查询结果。

还需要限制循环：最大转交次数、每个角色的预算、全局截止时间和冲突升级路径。两个 Agent 意见不一致时，不能让它们无限辩论；可以请求证据、运行确定性检查，或把决策交给用户。

真实工具不会全部立即返回。文件索引、长任务、审批和外部回调都适合事件驱动的模式：Agent 发起任务，系统保存状态，事件到达后恢复对应会话。

人工介入也不一定意味着流程失败。对于付款、删除、生产发布或模糊授权，可以把人工放在风险最高的节点：展示目标、参数、影响范围和验证结果，让用户只需做一个明确决策。

语音、视觉和 Computer Use 场景不只是在文本前面加一个输入转换器。系统需要处理流式音频、增量识别、用户打断、屏幕状态变化和动作确认。对于实时交互，先返回低延迟反馈，再异步完成耗时工作，通常比等待完整推理更符合用户预期。

不过，实时性不能覆盖安全边界。鼠标点击、表单提交和系统设置修改等动作，仍应有明确的目标确认、可见状态和可回退机制。屏幕上的文字也只是外部内容，不能自动获得系统指令的优先级。

多 Agent 是否有效，应该比较同一任务在单 Agent 和协作版本中的：最终成功率、P95 延迟、总 token、工具失败率、人工介入次数和错误恢复时间。如果只是把成功率提高了一点，却让成本和延迟大幅增加，系统可能并没有真正变好。

最终，多 Agent 的目标不是模拟一个热闹的组织，而是让职责、权限、证据和失败恢复更加清楚。能用一个 Agent 可靠完成的任务，就不要为了“看起来更智能”增加协作层。