切换深色模式
Planning 与多 Agent：工作流、调度器和微服务的类比边界
一张图上画出规划者、执行者和评审者，连上消息箭头，很像微服务架构。但这些节点可能都运行在同一个进程里，调用同一个模型，看到同一份资料。图形相似不能证明系统具备独立服务的隔离性，也不能证明获得了三份独立判断。
先分清生成计划与执行计划
对于故障调查，一个计划可以写成：查日志，确认部署版本，核实恢复条件，整理建议。若第二步需要第一步发现的实例 ID，就存在依赖边。调度器负责在依赖满足时运行节点，遇到失败时暂停、重试或终止。
依赖管理、队列、并发上限和超时控制都属于成熟的工作流工程。计划由人工写、规则生成还是模型生成，不改变执行器处理这些问题的基本职责。
模型参与 Planning 的变化在于：它根据开放任务生成或修改计划。于是新的检验对象是计划本身——有没有遗漏必要条件，是否使用存在的能力，步骤之间有没有真实的信息依赖，完成判据能否观察。
“搜索、分析、总结”虽然看起来像计划，却没有足够的执行语义。把它存成 JSON 或 DAG，也不会自动补齐缺失的前置条件。
动态图不能自动保证有效进展
假设模型读到配置说明引用另一份文档，新增一个读取节点，这种动态扩展有理由。但它也可能不断把“继续调查”拆成更多同义子任务，图越来越大，关键证据一条也没增加。
因此可以要求每个新节点说明所解决的缺口、所需输入和产物，并由系统控制深度与预算。允许模型提议分解，不等于必须接受所有分解。
预定义工作流与动态编排的区别，可以借助Anthropic 对工作流和 Agent 模式的划分理解。具体到本项目，是否动态拆分仍要与固定调查基线对照，而不是由模式名称决定。
多 Agent 的边界与微服务边界并不一致
微服务通常围绕独立部署、业务能力和运行责任划分。多 Agent 可以围绕信息范围、提示、工具权限或决策职责划分。二者可以组合，但不自动重合。
“日志调查 Agent”和“文档调查 Agent”可能只是两次模型调用；给它们两个名称，不会自动获得进程隔离、独立故障域或稳定接口。反过来，一个 Agent 也可以调用很多既有微服务，无需让每个服务都变成一个 Agent。
更有用的协作契约包括任务版本、输入资料、允许工具、预算、证据引用和输出判据。它让协调者可以检查结果，而不是只能接收一段“我已经完成”的文字。
并行的收益需要扣掉协调成本
用一个原创耗时算例：日志调查四秒，文档调查七秒，汇总两秒。串行耗时十三秒。若两项调查真正独立，可以并行；再假设额外协调开销一秒，墙钟耗时为 max(4,7)+2+1=10 秒。
这个十秒依赖假设：两项调查没有等待彼此的数据，没有共同限流，也没有返工。若日志调查必须先提供版本，文档调查才能开始，简单取最大值就错了。
即使墙钟时间减少，按此算例的累计执行工作仍从十三秒增至十四秒。实际账单更取决于各项调用费用，不能把墙钟时间与总成本直接等同。并行可用于降低延迟，不自动意味着省钱。
投票不能修复共同缺少的证据
三个模型都读取了一段漏掉版本条件的摘要，都判断可以自动恢复。多数意见很明确，证据却仍有缺口。模型之间的一致可能来自共同输入、相似训练或相同提示，而非独立验证。
有效复核应增加区分力：回到原文、检查运行配置、引入可执行测试，或使用不同的错误判据。仅增加“审计专家”角色名称，没有增加任何事实。
结果合并也要处理冲突：一份资料描述产品能力，另一份描述当前配置，表面矛盾可能来自不同层次。协调者应保留主张、条件与来源，不能把两段文字压成“总体可恢复”。
本篇判断：计划执行与协作通信大量复用工作流和分布式系统；模型生成计划、语义分工和证据冲突解决增加了新的质量问题。多 Agent 是否值得采用，要与单 Agent及普通并行检索一起比较。