摘要复杂任务要拆成步骤问题是由谁来拆。让智能体自己规划灵活但不可控把流程写死可控但无法应对变化。这大概是智能体架构设计中最核心的一次取舍。本文拆解四种分解方式、各自的适用条件、分解粒度如何确定以及被广泛采用的混合方案。2026 奇点智能技术大会11 月 20-21 日 · 北京万达文华酒店将讨论智能体系统与工程实践。一、四种分解方式方式谁来决定步骤灵活性可控性适用全自动规划模型最高最低探索性、容错高预定义工作流开发者最低最高流程固定的业务骨架 填充开发者定框架模型填细节中中大多数生产场景规划 审批模型规划人确认后执行高高高风险任务第三种是生产中最常见的形态关键节点固定保证可控节点内部交给模型保留灵活性。第四种在高价值场景不可替代当错误的代价很高时人的判断必须介入。但要注意审批的成本——高频任务上的逐步审批会让自动化失去意义。二、什么时候不该让模型自己规划三种情况下自动规划的收益小于风险情况一流程本身就是固定的。报销审批、订单处理这类流程已经有明确步骤让模型重新规划只会引入不必要的变动。情况二任务有强合规要求。需要严格按规定的顺序与条件执行自动规划无法保证这一点。情况三需要可审计的解释。每一步为什么这么做必须能给出确定答案。自动规划的解释是模型当时这么想通常无法满足审计要求。判断标准 流程是否固定 → 是 → 预定义 是否强合规 / 强审计 → 是 → 预定义或审批 任务是否未知 / 多变 → 是 → 自动规划三、什么时候不该写死工作流反过来也有两种情况情况一任务空间开放。用户可能提出任何请求无法预先枚举所有路径。写死工作流会导致大量请求无法处理。情况二步骤依赖于中间结果。下一步做什么取决于上一步发现了什么这种依赖无法在事前静态描述。典型的例子是帮我调研这个问题——需要检索、看结果、决定是否需要补充检索、再综合。写死的流程无法应对中间结果带来的分支。四、分解粒度怎么定粒度太粗模型不知道该做什么粒度太细调用次数与成本上升且容易在细节上出错。三个实用判断判断一每个步骤是否可独立验证如果一个步骤做完了无法判断成功与否说明它还需要再拆。判断二每个步骤的输入是否明确如果某步骤需要看情况说明边界不清。判断三步骤之间是否有明确的交接物每一步应当产出可供下一步使用的明确产物。没有交接物的步骤链会产生大量上下文污染。classStep:步骤定义明确输入、可验证的产出、失败时的处理方式。def__init__(self,name,inputs,validator,on_fail):self.namename self.inputsinputs self.validatorvalidator# 产出校验失败即重试或中止self.on_failon_fail# retry | abort | escalatedefrun(self,ctx):outexecute(self.name,ctx[self.inputs])ifnotself.validator(out):returnself.on_failreturnoutvalidator是关键它把步骤完成从感觉变成了可判断的条件。没有校验的步骤链错误会一路传到最后才被发现。五、规划失败的三种表现表现一分解不完整。漏掉了必要步骤导致结果不成立。表现二步骤顺序错误。依赖关系搞反前一步需要的输入后一步才产生。表现三陷入循环。反复执行相似步骤而无法推进。这在自动规划里非常常见必须设置最大步数与重复检测。defguard(plan_trace,max_steps12):规划防护步数上限 重复检测防止无限循环。iflen(plan_trace)max_steps:returnabortrecentplan_trace[-3:]iflen(set(recent))1:returnloop_detectedreturncontinue六、混合方案的设计要点骨架 填充的模式要做对有三个要点要点一骨架要定义关键节点而非全部步骤。把必须保证的环节固定下来其余留给模型。要点二给模型提供可用的步骤库。模型在骨架内选择时应当有一个明确的动作集合可供选择而不是完全自由发挥。要点三允许模型请求扩展。当现有骨架无法完成任务时让模型明确提出需要额外步骤由系统决定是否放行。这比让它默默偏离骨架更可控。混合方案的核心固定的是约束灵活的是路径 ↑ 固定路径而放开约束是最糟的组合七、验证分解效果两类测试其一任务完成率按复杂度分层。简单任务与复杂任务分别统计。总体数字会掩盖复杂任务完全失败。其二步骤数与成本的关系。平均每个任务消耗多少步、多少 token。这个数字是成本模型的基础。一个实用的观察当某类任务的步骤数方差很大时通常说明分解策略不稳定需要针对性地收紧骨架或改进提示。八、骨架设计的三个原则骨架 填充模式要做得好骨架设计是关键。三个原则原则一只固定必须固定的。固定的节点越多灵活性损失越大。每固定一个节点都要问这个顺序真的不能变吗原则二节点之间要松耦合。每个节点的输入应当明确且可从上下文获取而不是依赖前一个节点的内部状态。原则三为异常预留分支。每个节点都要定义失败路径重试、跳过、还是中止。没有失败分支的骨架在遇到异常时会卡住。骨架检查固定节点是否必要耦合是否够松失败分支是否齐全九、读者问答问模型规划的步骤数差异很大怎么办设置步数上限与重复检测同时观察步骤数方差——方差大通常说明分解不稳定。问骨架需要多少个节点合适通常三到七个。超过十个的骨架往往过于僵化不如部分放开。问如何让模型理解骨架在提示词中明确列出可用步骤与约束提供示例比描述规则更有效。问任务失败时如何定位是哪一步错了依赖每步的校验与留痕。没有逐步留痕的多步流程排查会极其困难。十、几个延伸问题问可以让模型自己修改骨架吗可以但需要审批或限制。完全自主修改会让可控性丧失。问骨架与工作流引擎是什么关系工作流引擎负责执行与状态管理骨架定义逻辑结构。两者配合比自己实现状态机更可靠。十一、规划能力的可观测性自动规划的黑盒特性是推广的主要障碍。三类可观测手段手段一规划过程留痕。记录模型在每一步给出的计划与理由。手段二计划与实际执行的对比。模型计划了几步、实际执行了几步、有多少偏离。偏离率是判断规划质量的有效指标。手段三失败步骤的归因统计。哪类步骤最容易失败这直接指出应该把哪些节点固定下来。从可观测到可控记录 → 对比 → 归因 → 把高失败节点固定为骨架最后一步形成了一个正循环用数据决定骨架应该固定哪些节点而不是凭直觉设计。十二、最后几个问题问规划能力会随模型升级自然改善吗会有所改善但不稳定。依赖这一点做架构决策是危险的。问如何降低规划成本限制步数、用小模型做规划大模型执行、以及对常见任务类型缓存计划模板。问用户能否看到并修改计划应当可以。展示计划并允许修改是兼顾灵活与可控的有效方式。十三、衔接大会专题问子任务失败后应该重试还是重新规划先判断失败原因。可恢复的临时错误适合重试说明计划本身没问题因理解偏差导致的失败应重新规划简单重试只会重复同样的错误。问分解后的子任务需要独立上下文吗通常需要。为每个子任务提供精简的相关上下文比把完整历史全部传入更高效也更准确。上下文传递的关键是保留结论而非保留过程。问任务分解是否适用于所有场景不适用于强实时或高度耦合的场景。分解带来的调度与通信开销在简单任务上可能超过收益简单任务直接端到端执行往往更快更稳。问应该让模型自己拆任务还是预先定义流程二者结合更现实。稳定、高频的流程预先定义保证可预期探索性、低频的任务交给模型自主分解。完全自主在复杂场景下容易失控完全预设则失去灵活性。问任务拆多细合适以每个子任务可独立验证为标准。过粗会导致失败难以定位过细会增加调度开销与上下文传递成本。如果一个子任务的结果无法单独判断对错说明还需要继续拆分。问分解错误如何发现和纠正靠中间结果的校验点。在每个子任务完成后做一次轻量检查发现偏差及时调整后续计划而不是等到全部执行完再判断。缺乏校验点的系统错误会沿任务链放大。问任务分解会不会显著增加成本会主要来自额外的模型调用与上下文传递。控制方式是限制分解深度与每层的分支数量并对已确认稳定的子任务跳过重新分解。问如何评估分解质量看两个指标任务完成率与返工率。完成率高但返工率也高说明分解虽然能跑通但计划质量差两者都低则需要重新审视是分解策略问题还是底层能力不足。11 月 20-21 日北京万达文华酒店2026 奇点智能技术大会将讨论智能体架构、规划能力与工程实践C 及系统软件技术大会则从状态机、工作流引擎与可靠性角度给出底层视角。带着我们的智能体有多少步骤是写死的、多少是模型自己定的这个问题的答案去参会会立刻知道架构的可控程度。大会信息2026 奇点智能技术大会 C 及系统软件技术大会时间2026 年 11 月 20-21 日地点中国·北京万达文华酒店大会报名点击报名领取大会资料立即报名锁定 Lukasz Kaiser Keynote 与 70 场演讲完整资料