很多人第一次设计 AI Agent 工作流时，会很自然地把它想成一张流程图：Planner 拆任务，Tool 执行，能并行的就并行，最后汇总结果。
真正开始做以后，麻烦很快出现。
搜索和数据分析能不能同时跑？如果一个子任务失败，后面的任务还要不要继续？Planner 怎么知道某个 Tool 根本做不了这件事？更棘手的是：有些任务看起来互不相关，实际上却共享一个前提；有些失败看起来只是局部异常，却会让后面的结果全部失去意义。
所以，Agent 编排真正需要解决的，并不是"怎样调用更多工具"，而是三个问题：任务之间有什么依赖，工具具有什么能力，失败会产生什么影响。
必须 Sequential 的，不是"步骤"，而是有依赖的任务
判断两个节点是否必须顺序执行，一个很实用的问题是：
后一个节点开始之前，是否必须知道前一个节点的结果？
如果答案是肯定的，它们就有真实依赖。
例如：
找出公司官网 → 获取最新财报链接 → 下载财报 → 分析收入变化
这里后面的输入是前面的输出。你甚至不知道财报文件在哪里，自然无法提前分析。这种工作流不应该为了追求速度强行并行。
另一种容易被忽略的顺序关系，是"决策依赖"。
假设任务是：
查询用户所在城市 → 判断当地天气 → 推荐今天的户外活动
"推荐活动"并不直接使用天气查询 Tool 的原始输出格式，但它的决策依赖天气结果。下雨和晴天对应的是两套完全不同的后续动作，所以依然应该 Sequential。
还有一类是"副作用依赖"。
比如：
创建订单 → 支付订单 → 发送确认邮件
即使技术上三个 API 都能同时调用，也绝不能并行。支付必须对应已经存在的订单，确认邮件也应该在订单真正成立之后发送。
因此，Sequential 的判断标准不应该是"业务描述里有没有先后顺序"，而应该检查三件事：数据依赖、决策依赖、副作用依赖。
没有这些依赖，才有资格考虑并行。
Parallel Task 的关键，不是同时执行，而是怎么合并
并行任务最容易被低估的部分，是汇总。
例如用户问：
帮我评估一家公司的投资价值。
Planner 可能拆出几个任务：
-
查财务数据；
-
查行业趋势；
-
查竞争对手；
-
查最近新闻。
这四个任务大体可以并行执行。但如果四个 Agent 最后各自返回一大段文字，然后直接拼接起来，得到的通常不是答案，只是一堆资料。
真正的 Parallel Workflow 通常需要一个显式的 Join 节点。
它负责三件事。
第一，确认哪些结果已经返回。
第二，把不同 Tool 的输出转换成统一结构。
第三，根据任务目标做综合判断。
例如可以让每个子任务都返回：
status
key_findings
evidence
confidence
missing_information这样 Join 节点面对的不是四篇风格完全不同的小作文，而是四份结构一致的输入。
还有一个重要问题：是不是必须等待所有 Parallel Task？
不一定。
假设五个搜索源中已经有四个返回，而且信息高度一致，第五个只是补充来源，那么系统可能允许继续。
但如果任务是：
比较三家供应商并选出价格最低的一家。
只返回两家结果显然不能得出可靠结论。
因此 Parallel Task 需要的不只是 Fork，还需要定义 Join Policy：
All required、Partial acceptable，还是 First successful。
没有明确的汇总规则，并行只是把混乱发生得更快。
一个前置任务失败，下游不应该只有"停止"这一种答案
任务失败以后怎么办，取决于这个任务在依赖图里的角色。
假设工作流是：
获取商品价格 → 计算折扣 → 生成报价单
如果价格查询失败，"计算折扣"已经没有有效输入，继续执行没有意义。这里应该阻断整个依赖链。
但换一个场景：
查询天气
查询餐厅
查询景点
生成周末旅行建议
如果天气 Tool 暂时失败，餐厅和景点仍然可以继续执行。最终系统可以生成一个不包含天气判断的部分结果，并明确告诉用户：
"天气信息暂时无法获取，因此户外活动建议存在不确定性。"
这说明失败至少应该区分三类。
Fatal Failure：没有它，下游无法成立。
Recoverable Failure：可以重试、换 Tool 或修改参数。
Optional Failure：部分信息缺失，但仍然可以完成主要目标。
很多 Agent 系统的问题，是把所有异常统一处理成"Retry 三次，然后整个任务失败"。
更好的设计是让依赖关系本身携带失败语义。
一个节点失败以后，Planner 不只是问：
"要不要重试？"
还应该问：
"哪些节点因此失去了执行条件？"
这时工作流才真正从"调用链"变成了"依赖图"。
Planner 不需要知道 Tool 的内部实现，但必须知道能力边界
Planner 是否需要提前知道每个 Tool 的能力？
需要，但不意味着它要理解 Tool 的代码。
Planner 真正需要的是一份足够清晰的 Capability Contract。
例如一个 Search Tool 的描述不应该只有：
用于搜索互联网。
更有价值的描述是：
可以根据关键词搜索公开网页，返回标题、摘要和来源链接；适合获取公开信息，不保证访问登录页面、付费内容和私人数据库。
这段描述同时告诉 Planner：
它能做什么、返回什么、适合什么场景，以及不能做什么。
一个好的 Tool Contract 通常至少包含：
-
输入要求；
-
输出结构；
-
能力范围；
-
限制条件；
-
是否产生外部副作用；
-
常见失败类型。
Planner 不需要知道浏览器 Tool 是用 Chromium 还是别的技术实现，却必须知道它能不能登录、能不能下载文件、能不能点击网页按钮。
否则 Planner 很容易产生一种典型幻觉：
把"我希望这个 Tool 能做到什么"，误认为"这个 Tool 实际能做到什么"。
Planner 判断"无法完成"，靠的不是感觉，而是约束检查
最成熟的 Planner，不只是会规划成功路径，还应该知道什么时候停止规划。
假设用户要求：
登录我的银行账户，把过去一年的流水下载下来并分析。
Planner 应该依次判断几个条件：
有没有访问银行账户的 Tool？
有没有用户授权？
Tool 是否支持登录和下载？
是否存在必须由用户完成的验证码或人工确认？
如果关键条件无法满足，就应该尽早返回"当前条件下无法完成"，而不是继续生成一串看起来合理但根本无法执行的步骤。
可以把 Planner 的判断理解成一个简单的可达性问题。
目标是终点。
Tool 是可以使用的动作。
当前上下文、权限、数据和资源，是起点条件。
如果 Planner 找不到一条满足约束的路径，任务就是不可达的。
还有一种情况更隐蔽：理论上有路径，但已经没有合理价值继续。
例如连续多个数据源都无法访问，而用户要求的是"基于最新公开资料做准确判断"。此时 Planner 即使还能继续调用其他低质量来源，也应该意识到：继续执行可能只会制造一个看似完整、实际上证据不足的答案。
所以"无法完成"至少包含两种情况：
Capability Impossible：现有 Tool 根本没有能力完成。
Constraint Impossible：能力存在，但缺少权限、数据、前置条件或可靠证据。
能够主动识别这两种情况，比无限重试更重要。
一个可靠的 Planner，其实是在维护一张动态依赖图
把这些问题放在一起看，会发现设计 Agent Workflow 最有用的模型并不是"步骤列表"，而是一张动态 DAG，也就是有向无环依赖图。
每个节点描述任务。
每条边描述依赖。
Tool Contract 描述节点可以怎样被执行。
Join Policy 决定并行结果什么时候可以汇合。
Failure Policy 决定某个节点失败以后影响多大。
Planner 则不断根据新结果更新这张图。
比如一个原本计划并行的搜索任务，可能在执行过程中发现其中一个结果提供了新的公司名称，于是 Planner 动态增加一个竞争对手查询节点。
一个原本必须执行的任务，也可能因为另一个节点已经提供了足够证据，而变成可选任务。
这比"Planner 一开始生成十个步骤，然后从头执行到尾"更接近真实世界。
因为现实中的任务，本来就充满未知信息。
优秀的 Planner 并不是一次把计划猜对，而是能够在执行过程中持续回答三个问题：
现在知道了什么？
接下来哪些任务已经具备执行条件？
这个目标是否仍然可达？
如果要真正开始设计一个 Agent Workflow，与其先画漂亮的流程图，不如给每个节点补上五个字段：dependencies、required_inputs、tool_capability、failure_policy 和 join_policy。
很多关于 Sequential、Parallel、Retry 和 Planner 的争论，会在这一步突然变得清晰。
因为一个稳定的 Agent 系统，靠的从来不是"让模型更聪明地安排步骤"，而是让它清楚地知道：什么可以开始，什么必须等待，什么失败以后还能继续，以及什么时候应该承认这条路走不通。