摘要

复杂任务要拆成步骤，问题是由谁来拆。让智能体自己规划，灵活但不可控；把流程写死，可控但无法应对变化。这大概是智能体架构设计中最核心的一次取舍。本文拆解四种分解方式、各自的适用条件、分解粒度如何确定，以及被广泛采用的混合方案。2026 奇点智能技术大会（11 月 20-21 日 · 北京万达文华酒店）将讨论智能体系统与工程实践。

一、四种分解方式

第三种是生产中最常见的形态：关键节点固定（保证可控），节点内部交给模型（保留灵活性）。

第四种在高价值场景不可替代：当错误的代价很高时，人的判断必须介入。但要注意审批的成本——高频任务上的逐步审批会让自动化失去意义。

二、什么时候不该让模型自己规划

三种情况下，自动规划的收益小于风险：

情况一：流程本身就是固定的。报销审批、订单处理这类流程已经有明确步骤，让模型重新规划只会引入不必要的变动。

情况二：任务有强合规要求。需要严格按规定的顺序与条件执行，自动规划无法保证这一点。

情况三：需要可审计的解释。每一步为什么这么做，必须能给出确定答案。自动规划的解释是"模型当时这么想"，通常无法满足审计要求。

判断标准： 流程是否固定？ → 是 → 预定义 是否强合规 / 强审计？ → 是 → 预定义或审批 任务是否未知 / 多变？ → 是 → 自动规划

三、什么时候不该写死工作流

反过来也有两种情况：

情况一：任务空间开放。用户可能提出任何请求，无法预先枚举所有路径。写死工作流会导致大量请求无法处理。

情况二：步骤依赖于中间结果。下一步做什么取决于上一步发现了什么，这种依赖无法在事前静态描述。

典型的例子是"帮我调研这个问题"——需要检索、看结果、决定是否需要补充检索、再综合。写死的流程无法应对中间结果带来的分支。

四、分解粒度怎么定

粒度太粗，模型不知道该做什么；粒度太细，调用次数与成本上升，且容易在细节上出错。

三个实用判断：

判断一：每个步骤是否可独立验证？
如果一个步骤做完了无法判断成功与否，说明它还需要再拆。

判断二：每个步骤的输入是否明确？
如果某步骤需要"看情况"，说明边界不清。

判断三：步骤之间是否有明确的交接物？
每一步应当产出可供下一步使用的明确产物。没有交接物的步骤链会产生大量上下文污染。

classStep:"""步骤定义：明确输入、可验证的产出、失败时的处理方式。"""def__init__(self,name,inputs,validator,on_fail):self.name=name self.inputs=inputs self.validator=validator# 产出校验，失败即重试或中止self.on_fail=on_fail# "retry" | "abort" | "escalate"defrun(self,ctx):out=execute(self.name,ctx[self.inputs])ifnotself.validator(out):returnself.on_failreturnout

validator是关键：它把"步骤完成"从感觉变成了可判断的条件。没有校验的步骤链，错误会一路传到最后才被发现。

五、规划失败的三种表现

表现一：分解不完整。漏掉了必要步骤，导致结果不成立。

表现二：步骤顺序错误。依赖关系搞反，前一步需要的输入后一步才产生。

表现三：陷入循环。反复执行相似步骤而无法推进。这在自动规划里非常常见，必须设置最大步数与重复检测。

defguard(plan_trace,max_steps=12):"""规划防护：步数上限 + 重复检测，防止无限循环。"""iflen(plan_trace)>max_steps:return"abort"recent=plan_trace[-3:]iflen(set(recent))==1:return"loop_detected"return"continue"

六、混合方案的设计要点

骨架 + 填充的模式要做对，有三个要点：

要点一：骨架要定义关键节点而非全部步骤。把必须保证的环节固定下来，其余留给模型。

要点二：给模型提供可用的步骤库。模型在骨架内选择时，应当有一个明确的动作集合可供选择，而不是完全自由发挥。

要点三：允许模型请求扩展。当现有骨架无法完成任务时，让模型明确提出"需要额外步骤"，由系统决定是否放行。这比让它默默偏离骨架更可控。

混合方案的核心：固定的是约束，灵活的是路径 ↑ 固定路径而放开约束，是最糟的组合

七、验证分解效果

两类测试：

其一，任务完成率按复杂度分层。简单任务与复杂任务分别统计。总体数字会掩盖"复杂任务完全失败"。

其二，步骤数与成本的关系。平均每个任务消耗多少步、多少 token。这个数字是成本模型的基础。

一个实用的观察：当某类任务的步骤数方差很大时，通常说明分解策略不稳定，需要针对性地收紧骨架或改进提示。

八、骨架设计的三个原则

骨架 + 填充模式要做得好，骨架设计是关键。三个原则：

原则一：只固定必须固定的。固定的节点越多，灵活性损失越大。每固定一个节点都要问：这个顺序真的不能变吗？

原则二：节点之间要松耦合。每个节点的输入应当明确且可从上下文获取，而不是依赖前一个节点的内部状态。

原则三：为异常预留分支。每个节点都要定义失败路径：重试、跳过、还是中止。没有失败分支的骨架在遇到异常时会卡住。

骨架检查：固定节点是否必要？耦合是否够松？失败分支是否齐全？

九、读者问答

问：模型规划的步骤数差异很大怎么办？
设置步数上限与重复检测，同时观察步骤数方差——方差大通常说明分解不稳定。

问：骨架需要多少个节点合适？
通常三到七个。超过十个的骨架往往过于僵化，不如部分放开。

问：如何让模型理解骨架？
在提示词中明确列出可用步骤与约束，提供示例比描述规则更有效。

问：任务失败时如何定位是哪一步错了？
依赖每步的校验与留痕。没有逐步留痕的多步流程，排查会极其困难。

十、几个延伸问题

问：可以让模型自己修改骨架吗？
可以，但需要审批或限制。完全自主修改会让可控性丧失。

问：骨架与工作流引擎是什么关系？
工作流引擎负责执行与状态管理，骨架定义逻辑结构。两者配合比自己实现状态机更可靠。

十一、规划能力的可观测性

自动规划的黑盒特性是推广的主要障碍。三类可观测手段：

手段一：规划过程留痕。记录模型在每一步给出的计划与理由。

手段二：计划与实际执行的对比。模型计划了几步、实际执行了几步、有多少偏离。偏离率是判断规划质量的有效指标。

手段三：失败步骤的归因统计。哪类步骤最容易失败，这直接指出应该把哪些节点固定下来。

从可观测到可控：记录 → 对比 → 归因 → 把高失败节点固定为骨架

最后一步形成了一个正循环：用数据决定骨架应该固定哪些节点，而不是凭直觉设计。

十二、最后几个问题

问：规划能力会随模型升级自然改善吗？
会有所改善，但不稳定。依赖这一点做架构决策是危险的。

问：如何降低规划成本？
限制步数、用小模型做规划大模型执行、以及对常见任务类型缓存计划模板。

问：用户能否看到并修改计划？
应当可以。展示计划并允许修改，是兼顾灵活与可控的有效方式。

十三、衔接大会专题

问：子任务失败后应该重试还是重新规划？
先判断失败原因。可恢复的临时错误适合重试，说明计划本身没问题；因理解偏差导致的失败应重新规划，简单重试只会重复同样的错误。

问：分解后的子任务需要独立上下文吗？
通常需要。为每个子任务提供精简的相关上下文，比把完整历史全部传入更高效也更准确。上下文传递的关键是保留结论而非保留过程。

问：任务分解是否适用于所有场景？
不适用于强实时或高度耦合的场景。分解带来的调度与通信开销在简单任务上可能超过收益，简单任务直接端到端执行往往更快更稳。

问：应该让模型自己拆任务还是预先定义流程？
二者结合更现实。稳定、高频的流程预先定义，保证可预期；探索性、低频的任务交给模型自主分解。完全自主在复杂场景下容易失控，完全预设则失去灵活性。

问：任务拆多细合适？
以"每个子任务可独立验证"为标准。过粗会导致失败难以定位，过细会增加调度开销与上下文传递成本。如果一个子任务的结果无法单独判断对错，说明还需要继续拆分。

问：分解错误如何发现和纠正？
靠中间结果的校验点。在每个子任务完成后做一次轻量检查，发现偏差及时调整后续计划，而不是等到全部执行完再判断。缺乏校验点的系统，错误会沿任务链放大。

问：任务分解会不会显著增加成本？
会，主要来自额外的模型调用与上下文传递。控制方式是限制分解深度与每层的分支数量，并对已确认稳定的子任务跳过重新分解。

问：如何评估分解质量？
看两个指标：任务完成率与返工率。完成率高但返工率也高，说明分解虽然能跑通但计划质量差；两者都低则需要重新审视是分解策略问题还是底层能力不足。

11 月 20-21 日，北京万达文华酒店，2026 奇点智能技术大会将讨论智能体架构、规划能力与工程实践；C++ 及系统软件技术大会则从状态机、工作流引擎与可靠性角度给出底层视角。

带着"我们的智能体有多少步骤是写死的、多少是模型自己定的"这个问题的答案去参会，会立刻知道架构的可控程度。

大会信息
2026 奇点智能技术大会 + C++ 及系统软件技术大会
时间：2026 年 11 月 20-21 日
地点：中国·北京万达文华酒店
大会报名：点击报名，领取大会资料

立即报名，锁定 Lukasz Kaiser Keynote 与 70+ 场演讲完整资料！