工作流、单 Agent 与多 Agent 怎么选

学完能做什么

你会根据任务的确定性、并行性、风险和可评测程度，在固定工作流、单 Agent 和多 Agent 之间做选择，并为复杂方案设置清楚的协作协议。

先选最简单的可行结构

结构越复杂，延迟、成本、错误路径和排障难度越高。不要把“多个角色提示词”误认为真正的多 Agent 系统。

能用函数和规则表达的步骤，优先放在工作流里。只有需要语言理解和动态判断的节点才交给模型。

固定工作流：默认起点

例如“接收文件—校验—提取—人工确认—归档”的顺序稳定，使用显式流程最合适：

上传 → 格式校验 → 文本提取 → 字段检查
                         ├─ 缺字段 → 退回
                         └─ 完整 → 人工确认 → 归档

模型可以做文本提取，但不能改变审批和归档规则。

单 Agent：让动态判断集中在一个循环

适合研究、材料整理和故障初步诊断等任务。一个 Agent 可以在多个只读工具间选择，状态和权限仍由统一运行器管理。

单 Agent 失控的常见表现：

• 反复搜索相同关键词；
• 没有新证据仍继续调用模型；
• 把建议当成已执行事实；
• 在上下文变长后忘记原始目标。

对应护栏是步骤上限、重复检测、完成条件、证据要求和任务状态快照。

什么时候多 Agent 才有实际价值

同时满足越多条件，越值得考虑：

• 子任务可以清楚拆分，输入输出可定义；
• 子任务之间能并行，而不是轮流聊天；
• 不同子任务需要不同工具、权限或模型；
• 每个子结果可以独立评测；
• 聚合失败时能定位到具体子任务；
• 节省的时间或提升的质量大于协调成本。

如果所有 Agent 都看同一上下文、用同一工具、按顺序工作，通常一个带步骤的 Agent 更简单。

用任务合同代替自由对话

多 Agent 之间传递结构化任务合同：

{
  "task_id": "research-42-part-b",
  "objective": "找出文档中与数据保留期有关的规则",
  "allowed_sources": ["policy-a-v3", "policy-b-v2"],
  "constraints": ["只报告有直接证据的结论"],
  "output_schema": {
    "findings": "array",
    "citations": "array",
    "unresolved": "array"
  },
  "deadline_ms": 20000,
  "budget": {"model_calls": 3, "tool_calls": 5}
}

不要让子 Agent 自己扩张目标或邀请更多 Agent。是否继续拆分由编排器和预算规则决定。

编排器需要处理的失败

                   ┌─ 子任务 A 成功 ─┐
主任务 → 分解与分发 ├─ 子任务 B 超时 ─┼→ 聚合与校验 → 最终状态
                   └─ 子任务 C 冲突 ─┘

聚合器不能把部分成功伪装成完整成功。它要知道：

• 哪些子任务完成、失败或未开始；
• 失败是否可重试，重试会不会重复副作用；
• 两个结果冲突时依据什么裁决；
• 缺少哪个结果时必须停止；
• 是否需要向用户展示部分结果并请求决定。

权限要按角色真正隔离

“研究员”“审核员”的名字不构成权限。为每个执行身份配置独立的工具白名单、数据范围和凭据：

• 研究 Agent 只读指定材料；
• 生成 Agent 只接收经过筛选的证据；
• 审核 Agent 只检查结构和引用；
• 发布动作由人工或专门服务执行。

高权限凭据不能因为某个子 Agent “可能会用到”就共享给全部节点。

用实验决定是否升级架构

为同一组任务比较三个版本：

1. 固定工作流加一个模型节点；
2. 单 Agent 加多个工具；
3. 多 Agent 分解与聚合。

记录成功率、人工修正率、平均与长尾延迟、模型和工具成本、重复动作、不可解释失败数。只有复杂方案在关键指标上稳定胜出，才值得保留。

方案评审练习

对“每天收集行业材料并生成内部简报”做选择：

1. 列出确定步骤和动态判断步骤；
2. 判断检索、去重、事实核验能否独立并行；
3. 为每个子任务定义输入、输出、超时和预算；
4. 写出一项子任务失败时的整体结果；
5. 设计一个最简单基线，与复杂方案做对照测试。

完成检查清单

• 固定规则留在工作流，模型只处理必要的动态判断。
• 多 Agent 的子任务可以独立定义、执行和评测。
• 协作使用结构化合同，不依赖自由聊天传话。
• 权限、预算、超时和失败状态按子任务隔离。
• 已用基线实验验证复杂架构确实带来收益。

下一步

最后一篇会把 Agent 从“能运行”推进到“可上线”：建立测试集、安全边界、成本预算、监控和发布门槛。