企业任务要不要用多 Agent：先检查能否独立并行和汇总验证

Anthropic 的工作流文章区分预定义路径、并行处理与由协调者动态分派的模式；其多 Agent 研究文章讨论独立探索带来的收益，也讨论协调、成本和持久状态的工程负担。供应商内部研究系统的结果不能直接当作本企业项目的效果承诺。

本演练只比较公开或获授权的供应商资料，不进行下单。每份资料都可独立提取产品范围、交期说明、服务边界和证据位置，之后按统一字段汇总。这部分适合尝试并行；确定采购预算、选择供应商和修改采购单涉及共同状态及业务责任，不让研究 Agent 独立决定。

如果下一步总是需要上一步的结果，例如先补齐型号再查询库存，再按库存计算交期，多 Agent 并不能让这些依赖消失。流程图中可并行的片段与必须等待的片段要分别设计。

“独立”包含数据、权限和结果上的独立。两个 Agent 都读取同一合同，但一个检查适用范围、另一个检查期限，可以是不同职责；如果都完整阅读并写同一份总结，就应说明重复工作的用途，否则只增加费用。

说明中写清对象、问题、允许来源、输出字段、缺失值表示和停止条件。供应商甲的处理者只负责甲的资料，不自行比较其他公司；每项结论附文档标识、版本和位置，找不到就标记未确认。

用相同字段表达结果：资料名称、可确认的产品范围、交期条件、售后限制、原文证据和疑问。单位和日期格式统一，但保留原始表述便于核对。模型不应把没有交期说明改写成“交付快”，也不能将市场宣传转成已经实测的性能。

给子任务有限的调用与时间预算，说明找不到资料时如何返回。协调者不能为了填满表格无限增派任务。已获得足够证据时结束，新增检索必须有未解决的问题和预期用途。

工具权限按子任务最小范围分配。只读研究者不需要采购单写权限，某个子任务完成也不会自动授予其他角色更大范围。

汇总者先检查结果结构和证据可访问性，再按统一标准比较。不能只把各段总结拼接在一起；需要确认比较的是同类产品、相同地区和相近的服务条件。不同范围的资料应标出无法直接比较的位置。

有冲突时回到证据。例如一份页面写“提供部署服务”，另一份方案书把部署列为选配，先记录范围差异并请求确认。多数 Agent 得到同一结论，不代表结论真实；它们可能读到了相同错误来源。

共享任务状态保存已完成对象、待处理疑问、来源版本和责任人。子任务提交结果时带任务版本，过时结果不覆盖新版本。协调者只接收必要产物和引用，详细检索记录可以单独保存，减少转述中的信息丢失。

最后写业务可读的比较说明，明确哪些字段已核实、哪些只有厂商描述、哪些需要供应商答复。采购决定仍由有权限的人或既定规则作出。

耗时要从用户提交到可用结果计算，费用要包括协调者、子任务、重复检索和失败重试。只比较单个 Agent 的响应速度，会漏掉等待最慢分支和汇总核验的时间。

某个子任务超时，汇总可以返回部分结果并明确缺项，或按预设规则等待与重试。必须保证用户看得出比较表不完整，不能让其他角色猜测缺失数据。多个失败分支同时重试时，也要受总预算约束。

多个角色提交到共享存储时，使用明确的对象归属、版本检查和状态更新规则。业务副作用由一个受控入口提交，或者采用经过设计的并发与幂等契约。角色名“审核员”不会自然产生可靠的审批或授权能力。

运行记录应能关联主任务与子任务，说明分派范围、来源和最终产物。权限控制同样覆盖子任务日志及附件，不能因为它们属于内部协作就暴露全部客户资料。维护团队需要知道哪一层可以停止新增任务和外部动作。

当输入少、标准固定、结果容易一次校验时，固定工作流往往更容易维护。高度耦合的业务写入即使使用多个模型角色，也需要统一状态与执行控制，不能依靠角色互相讨论解决一致性问题。

可以从一个只读并行片段开始，在固定测试包上验证，再逐步扩展。多 Agent 的价值来自更合适的分工与可用结果；若只是把同一任务换成许多角色名称，企业要承担的协调成本会先增加。