很多开发者在搭完第一个 Agent 的时候都会经历一个类似的心路历程Demo 阶段一切都很丝滑让大模型查资料、写代码、调工具每一步都像模像样一旦把真实业务接进系统Agent 就开始花式翻车。要么漏掉关键步骤要么在同一个地方反复绕圈要么生成的结果看起来合理但根本不能用。这些翻车案例看多了之后你会慢慢发现一个规律真正的问题往往不在模型本身。无论是 GPT、Claude还是各类国产开源模型单次对话都足够聪明但只要任务一长、环节一多模型就会在“全局规划”和“长程执行”上露馅。这也是为什么很多团队在把 Agent 从 Demo 推向生产时最终都会回到同一个课题——任务拆解。这篇文章想聊清楚三件事第一Agent 翻车的底层原因到底是什么第二任务拆解为什么是提升稳定性的关键杠杆第三也是最重要的怎么用一套可落地的工程方法把大模型任务拆解成可校验、可追踪、可重试的稳定流程。读完你至少能拿自己正在做的 Agent 项目做一个体检找出最容易翻车的那个环节。1. 为什么你写的 Agent 总在翻车问题本质不在模型先还原几个真实业务里非常常见的翻车现场。第一个场景让 Agent 写一份市场竞品分析报告。你给它一个目标“分析竞争对手的产品策略”它查了两三个公开资料就自动得出结论“该产品主打性价比路线”然后草草收尾。整个流程看似完成了但核心的定价区间、目标用户、迭代节奏全都缺失。如果你不逐字检查这份报告根本没法用。第二个场景让 Agent 跑一个多步骤的数据处理任务。它在第二步把某个字段的类型判断错了后面所有步骤都基于这个错误结果继续执行。更麻烦的是模型在最终输出时并没有暴露这个中间错误反而用非常自信的语气描述了一个完全错误的结果。第三个场景让 Agent 调用外部工具完成业务操作。它需要先查订单状态再判断是否退款最后调用退款接口。结果模型在调用接口时把金额单位传错了从“分”写成了“元”下游系统收到参数后直接报错。整个流程中断而且因为错误发生在工具调用层普通的日志监控根本发现不了。这三个场景看起来问题各不相同但背后其实是同一件事当前大模型的推理方式决定了它很难稳定地完成长链路任务。第一层原因是模型本身的不确定性。大模型本质上是概率模型同样的输入、同样的 Prompt两次输出的结果可能完全不同。这就意味着你没有办法靠“把 Prompt 写得更详细”来保证每一步都稳定因为每一步都是一个全新的概率采样过程。第二层原因是注意力漂移和上下文遗忘。模型在处理长对话时早期的指令约束会被后续内容逐渐稀释。你会发现它越往后执行越容易偏离你最初给它定义的目标和边界条件。这也是为什么很多 Agent 一开始执行得挺好跑到后期就“忘了自己要干嘛”。第三层原因也是最容易被忽视的缺少工程约束。你在 Prompt 里让模型“自己判断下一步做什么”实际上就是把所有决策权都交给了概率采样。模型在单点上的错误率可能只有 2% 到 5%但如果一个任务需要连续做 20 个决策整体成功率就会迅速下降。所以如果你发现自己的 Agent 经常翻车先不要急着换更大的模型也不要反复改 Prompt。更值得做的是把你对任务的期望从“让模型自由发挥”改成“让模型在约束框架里执行”。而任务拆解就是建立这套约束框架最核心的手段。2. 任务拆解在 Agent 架构中的位置与核心原理在讨论具体方法论之前有必要先建立一个共识Agent 的标准工作循环是什么以及任务拆解在这个循环里扮演什么角色。一个典型的 Agent 工作循环可以拆成四段感知Perception获取用户输入、外部数据、工具返回结果。规划Planning决定接下来要做什么生成一个或多个后续动作。行动Action调用工具、生成文本、执行代码或发起请求。反馈Feedback观察行动结果判断是否达成目标或决定下一步动作。大多数 Agent 框架无论底层用的是 ReAct 范式还是 Plan-then-Execute 范式本质上都是这四个环节的循环。而任务拆解主要作用在“规划”和“行动”两个环节。这里需要解释两个容易混淆的概念ReAct 和 Plan-then-Execute。ReActReasoning Acting是目前很多 Agent 项目默认使用的范式。它的特点是“边想边做”模型每执行一步都会结合当前观察结果决定下一步动作。优点是灵活适合开放探索类任务缺点是长链路下容易漂移缺乏全局约束。Plan-then-Execute 则分两个阶段。第一阶段让模型先做整体规划把一个大目标拆成若干个子任务第二阶段再按计划逐步执行每个子任务单独处理。优点是每个子任务的上下文更清晰决策范围更小稳定性更高缺点是需要额外设计和维护“计划”这一层结构。如果你的目标是让 Agent 稳定交付Plan-then-Execute 通常是更稳妥的起点。它不是让模型一次性输出整段工作计划就结束而是把计划固化成一种数据结构让后续的执行器按状态机的方式逐步推进。在这个结构里有几个概念需要约定清楚子任务Task拆解后的最小执行单元有明确的输入、输出和完成条件。工具Tool子任务执行时可能调用的外部能力比如搜索、数据库查询、代码执行。检查点Checkpoint子任务完成后的校验节点判断输出是否符合预期。状态State整个任务执行过程中的全局上下文记录已完成、进行中和失败的任务。任务拆解的本质就是把一个不可控的“开放式长程决策”转换成一组可控的“封闭式单步决策”。每一个子任务仍然由模型执行但模型的决策空间被压缩了它不再需要想清楚整个流程只需要在当前步骤做好一件事。如果你能理解这一层后面所有工程手段都是为了同一个目标减少模型单次决策的信息量和候选路径同时增加对每一步输出的校验和纠错。3. 拆解粒度多细才算合理很多刚开始做任务拆解的人会遇到一个困惑到底要把任务拆到什么程度才算好有一种做法是把所有任务都拆成最小原子操作比如“读文件第一行”“把字符串转小写”拆到最后整个系统的状态管理和上下文传递复杂度急剧上升。另一种做法是只做一层粗拆比如“先调研再写报告”结果每个子任务内部仍然是长链路翻车概率并没有下降。判断粒度是否合适有一个很朴素的标准一个子任务是否能在“有限次”的大模型调用内稳定完成换句话说如果这个子任务仍然需要模型自己连续做很多个相互依赖的决策那就说明拆得不够细。如果这个子任务简单到不需要模型直接用普通代码就能完成那拆得又太细了反而增加了不必要的模型调用和上下文拼接成本。我见过很多团队在实践中总结出来的经验是子任务的目标描述应该尽量短短到可以用一句话说清楚子任务的输出应该尽量结构化最好能对应到固定字段子任务的完成验证要尽量简单简单到不需要再调一次模型来判断。为了更直观地说明我整理了一个拆解粒度的对比拆解粒度子任务特点典型例子优势风险粗粒度子任务内部仍有大量决策链写一份市场分析报告结构简单上下文切换少模型容易漏步骤结果不稳定中粒度子任务有明确边界和输出格式先搜集竞品定价再分析价格策略决策范围缩小可校验需要设计好子任务之间的依赖细粒度子任务接近原子操作查询指定商品最新价格并返回JSON最稳定几乎不会漂移状态管理复杂Token开销大从实际项目看中粒度是大多数业务场景的起点。你先把任务拆成“有明确边界、有固定输出格式、单次可以完成”的模块跑通之后再去调整粒度。拆解过程中还要注意一个反向指标如果某个子任务在执行时模型经常需要“多想想”才能决定怎么做那这个子任务很可能还是太粗了。反过来如果执行器代码里到处都是“if task_type xxx”这种分支那可能拆得太碎已经退化成了普通流程编码。这里真正容易踩坑的地方是拆解粒度不是一个固定值它取决于你使用的模型能力、任务本身的复杂度、以及你对错误容忍度的要求。同一个任务用强模型做粗拆可能没问题换到轻量模型就必须拆得更细。所以在一开始你可以对每个子任务做一次“小规模试跑”用 5 到 10 组输入观察它的失败率再决定要不要继续往下拆。4. 一套可落地的任务拆解方法论从目标到流水线理解了原理和粒度之后接下来是本文最核心的内容一套可以直接拿到项目里用的任务拆解流程。它不是某个框架的专属方案而是适用于任何大模型应用项目的通用方法。4.1 把目标翻译成可验证的交付物任务拆解的第一步不是急着列步骤而是先定义“什么叫完成”。很多开发者给 Agent 下达目标时写的是“分析用户反馈”“生成一份报告”“处理这批数据”。这类描述的问题在于它们无法被自动验证。Agent 输出一段文本后你很难判断它到底算不算完成了。正确做法是给目标绑定一个可验证的交付物。比如“分析用户反馈”可以改成“从 100 条用户反馈中按问题类别输出汇总表包含类别、提及次数、典型原文”“生成一份报告”可以改成“生成一篇 800 字左右的文档包含背景、发现、结论三个章节每个章节的小标题固定”。只有交付物是明确的结构化对象后续的校验才有依据。这一步看似简单却是整个任务拆解里最影响成败的动作。4.2 用“关键子问题”驱动拆解拿到目标之后不要直接让模型列步骤而是你先自己问一个问题要完成这个目标必须回答哪些关键子问题以“竞品分析”为例关键子问题可能是竞品有哪些分别是什么定位它们的核心功能点是什么它们的定价策略是怎么设计的它们最近有什么市场动作这几个子问题之间有并列关系也有先后依赖。比如你不先确定“竞品有哪些”后面的“定价策略”就无从谈起。你在这一阶段的工作就是把目标还原成一组子问题的集合再根据子问题之间的依赖关系排出执行顺序。4.3 为每个子任务定义输入、输出和校验点这是任务拆解和普通“列提纲”之间最大的区别。提纲只描述“做什么”任务拆解要求你为每个子任务定义清楚三样东西输入、输出、校验点。输入包括这个子任务需要哪些上下文比如原始数据片段、上游子任务的输出结果、全局约束条件。输出要尽量定义成结构化格式比如 JSON、固定字段的表格这样执行器可以自动解析。校验点是子任务完成后的自动检查逻辑比如“输出是否包含指定字段”“数值是否在合理范围内”“文本长度是否达到要求”。给一个例子假设子任务是“提取订单信息”输入是“订单原始文本”输出可以定义为{ order_no: 字符串订单号, amount: 浮点数金额, currency: 字符串币种, items: [数组商品名称列表] }校验点可以这样设计order_no 不为空amount 大于 0items 长度大于等于 1。任何一个校验失败执行器都能立刻感知而不是让错误结果流向下一个环节。4.4 确定执行顺序、依赖关系和兜底策略子任务定义好之后把它们组织成一张执行图。图里要标记清楚哪些任务可以并行哪些任务必须串行哪些任务允许失败重试哪些任务一旦失败则整个流程终止。这个环节不需要引入多复杂的调度框架最简单的方式就是用状态机或有序队列。每一步执行器从队列里取出一个任务执行完成后更新状态再根据结果决定下一步是推进、重试还是终止。兜底策略也必须提前设计。模型调用可能超时、工具可能返回异常、校验可能不通过。你在任务 schema 里就应该声明每个子任务的最大重试次数和失败后的动作而不是等运行时再临时决定。4.5 先跑通一条“最小主线”再逐步放宽最后一个方法论建议是不要一开始就把所有分支和边界情况都塞进任务定义里。先把最核心的主线流程拆好、跑通、验证通过再逐步加入异常分支和复杂场景。这样做的好处有两点。第一主线流程的任务依赖最简单方便你识别到底是拆解得不对还是模型能力不足。第二先有稳定主线的“心理锚点”之后再处理边缘情况时你更容易判断新增的复杂度到底值不值得。5. 代码实现从 Prompt 到可执行的任务流水线前面几节偏方法论这一节把它落到代码里。我会用一个非常精简的 Python 示例演示如何把一组子任务定义成结构化数据再通过一个简单的执行器按顺序执行、校验和重试。这段代码的目标不是给你一套可以直接上线的框架而是展示“任务拆解”在工程上到底长什么样。理解了这段代码你就能轻松迁移到 LangChain、Dify、自研框架等不同实现上。5.1 定义任务 Schema# 文件路径task_schema.py from dataclasses import dataclass, field from typing import Any, Callable, Optional dataclass class Task: name: str # 子任务名称 prompt_template: str # 调用大模型时使用的提示词模板 validate: Callable[[Any], bool] # 校验函数判断输出是否合格 max_retries: int 2 # 最大重试次数 fallback: Optional[Callable[[], Any]] None # 重试失败后的兜底逻辑 output_key: str result # 本任务输出在全局状态中的字段名 depends_on: list field(default_factorylist) # 依赖的上游任务 def always_pass(_): return True这里把每个子任务定义成了一个 Task 对象。name 是唯一标识prompt_template 是模型提示词validate 是校验函数。执行器每完成一个任务都会调用 validate 检查输出只有通过校验才算成功。5.2 实现一个最小执行器# 文件路径executor.py import json from typing import Dict, Any from task_schema import Task def call_llm(prompt: str) - str: 模拟一次大模型调用实际项目中替换为真实模型 API # 这里只是演示实际项目中通常通过 OpenAI SDK、LangChain、Ollama 等方式调用 return {status: ok, summary: task finished} def execute_task(task: Task, state: Dict[str, Any]) - Any: 执行单个子任务带校验和重试 prompt task.prompt_template.format(**state) last_error None for attempt in range(task.max_retries 1): try: raw_output call_llm(prompt) parsed_output json.loads(raw_output) if task.validate(parsed_output): state[task.output_key] parsed_output print(f[OK] {task.name} 通过校验) return parsed_output last_error 校验失败 except Exception as e: last_error str(e) print(f[RETRY] {task.name} 第 {attempt 1} 次失败: {last_error}) if task.fallback: print(f[FALLBACK] {task.name} 使用兜底逻辑) state[task.output_key] task.fallback() return state[task.output_key] raise RuntimeError(f任务 {task.name} 最终失败: {last_error}) def run_pipeline(tasks: list[Task], initial_state: Dict[str, Any]) - Dict[str, Any]: 按依赖关系顺序执行任务 state dict(initial_state) for task in tasks: if not all(dep in state for dep in task.depends_on): raise RuntimeError(f任务 {task.name} 的上游依赖未完成) execute_task(task, state) return state这一段是整个任务拆解落地的骨架。执行器做的事情非常朴素按顺序取出任务、构造 Prompt、调模型、解析输出、做校验、失败重试、再失败则走兜底。它并没有使用任何复杂的调度算法但已经能明显提升稳定性的原因在于每一个子任务的输出都经过了校验错误的中间结果不会被静默地带入下一个步骤。5.3 组装一个带校验的流水线# 文件路径main.py from executor import run_pipeline from task_schema import Task def validate_summary(data): return isinstance(data, dict) and len(data.get(summary, )) 0 def validate_report(data): return isinstance(data, dict) and title in data and body in data def build_tasks(): # 任务1生成摘要 task1 Task( namegenerate_summary, prompt_template根据原始数据生成摘要。原始数据{input_text}\n输出JSON字段summary, validatevalidate_summary, output_keysummary_result ) # 任务2基于摘要生成报告 task2 Task( namegenerate_report, prompt_template根据摘要生成报告。摘要{summary_result}\n输出JSON字段title, body, validatevalidate_report, output_keyreport_result, depends_on[generate_summary] ) return [task1, task2] if __name__ __main__: state run_pipeline( build_tasks(), initial_state{input_text: 这是一段需要分析的原始业务数据包含订单量、用户反馈和退款记录。} ) print(最终状态, state)这段代码把两个子任务串成了一条流水线。第一个任务负责生成摘要第二个任务依赖摘要结果生成报告。每个子任务都有独立的校验函数任何一个输出不符合要求都会触发重试。需要说明的是这里的 call_llm 是模拟函数真实项目里需要替换成大模型 API 调用。替换时你至少要做两件事把 prompt_template 中的占位符和实际状态变量对应起来把模型返回的非 JSON 文本做兼容处理比如从 Markdown 代码块中提取 JSON。这样一个最小实现已经具备任务拆解的核心特征职责单一的子任务、结构化的输入输出、自动校验、失败重试和兜底。你会发现这套结构几乎不依赖任何特定 Agent 框架你自己用 Flask 加一个队列也能搭建。6. 实战案例把“写周报”拆成稳定交付的 Agent理论讲得多不如完整跑一个业务例子。这里选一个很多团队都在做的场景让 Agent 根据项目数据自动生成周报。先看不做任务拆解时的写法和它的翻车点。你可能会写这样一个 Prompt你是团队助理请根据以下数据生成一份周报 {数据}这个 Prompt 至少有四个问题数据格式不固定时模型不知道先做什么模型可能只挑一两个数据点展开漏掉关键指标输出格式完全不可控有时候是 Markdown有时候是纯文本你无法判断它到底有没有理解数据内容。现在用任务拆解的方式重新设计。目标不变但先定义交付物一份包含“核心数据摘要、风险事件、下周计划”三个板块的周报每个板块有固定结构。拆解后的子任务如下6.1 子任务一提取本周核心数据指标第一个子任务的输入是原始业务数据输出是结构化的指标列表。{ metrics: [ {name: 订单量, value: 1520, unit: 单, trend: up}, {name: 客单价, value: 230, unit: 元, trend: up}, {name: 退款率, value: 3.2, unit: %, trend: down} ] }校验点metrics 不为空每条数据必须包含 name、value、unit、trend 字段trend 只能取 up、down、flat 三个值之一。这样校验很具体模型输出稍有不规范就能被系统发现并触发重试。6.2 子任务二识别风险事件第二个子任务依赖第一个子任务的输出同时还需要传入一份异常日志。输出是风险事件列表{ risks: [ {event: 支付接口在周三出现5分钟超时, level: high, impact: 影响约20笔订单} ] }校验点level 只能是 high、medium、low 之一每条风险必须包含事件描述和影响说明。6.3 子任务三生成下周计划第三个子任务的输入是前两个子任务的输出再加上目标的优先级说明。输出同样要求结构化{ next_plan: [ {action: 修复支付接口超时问题, priority: P0, owner: 后端组} ] }校验点next_plan 为数组每条计划必须有 action 和 prioritypriority 只能是 P0、P1、P2。6.4 子任务四组装周报模板最后一个子任务不再需要模型做太多思考它只是把前面几个子任务的输出填入模板。这里可以直接用普通代码完成也可以让模型做一次格式润色。建议优先用代码做拼接因为这一步的格式要求最严格模型反而容易画蛇添足。组装后的周报结构如下# 本周核心数据 - 订单量1520 单较上周上升 - 客单价230 元较上周上升 - 退款率3.2%较上周下降 # 风险事件 - 【高】支付接口在周三出现 5 分钟超时影响约 20 笔订单 # 下周计划 - 【P0】修复支付接口超时问题负责人后端组对比最初的单次 Prompt 方案拆解后的方案有几个明显的差异。第一每个环节的输出都是结构化的系统可以自动检查是否合理。第二如果“提取核心指标”这一步失败系统不会继续执行后续的风险识别和计划生成避免错误传播。第三你可以在任意两个子任务之间插入人工审核节点。比如风险事件识别结果可以由业务人员确认后再生成计划这在真实项目中非常重要。如果你在开发中遇到类似场景可以先照着这个套路试着拆一遍。即使不写代码光是把“写周报”改成“提取指标、识别风险、生成计划、组装模板”这四个模块你的 Agent 稳定性就已经提升了一个量级。7. Agent 任务拆解常见问题与排查方法任务拆解不是一拆就灵实践中会遇到很多新的问题。这里整理一份高频问题清单你在调试时可以直接对照。问题现象可能原因排查方式解决方案模型不按定义好的任务顺序执行单次 Prompt 里同时给了多个任务模型自由组合步骤查看模型实际输出的动作序列与预期计划对比把每个任务拆成独立调用用执行器控制顺序不让模型自主跳转子任务输出格式不稳定提示词里的格式说明不够强模型对 JSON 理解不一致记录原始输出看是字段缺失还是类型错误在提示词中给出输出示例解析时兼容 Markdown 代码块解析失败触发重试中间任务失败后无法恢复整个流程没有保存中间状态检查执行器状态是否落盘引入任务状态持久化至少记录已完成的任务和对应输出上下文越来越长Token 超限每个子任务都拼接所有历史上下文查看发给模型的 Prompt 长度只传入当前任务需要的字段对长文本做摘要压缩Agent 陷入死循环重试逻辑没有上限或失败后不断重建计划观察执行日志是否反复执行同一任务设置最大重试次数重试后仍然失败则走兜底或终止下游任务拿到污染数据上游校验不够严格错误输出被当成正常结果在管线各节点打印状态快照为每个任务定义严格校验函数不通过就不放行拆完还是不稳定拆解粒度仍然太粗或者模型本身能力不足对比不同输入下失败任务的共性继续拆分换更强的模型对高风险任务引入人工复核这里最值得强调的一条是日志和可观测性必须和任务拆解同步建设。如果你的执行器没有一个清晰的日志输出你很难定位到底是哪个子任务、哪次重试、哪个校验函数出的问题。建议每个任务执行时至少记录任务名、输入摘要、输出摘要、校验结果、重试次数、耗时。这些数据不仅是排错依据也是后续优化任务拆解粒度的重要参考。8. 从拆解到稳定交付工程侧的最佳实践最后这部分把任务拆解放进完整的工程上下文里聊几个直接决定项目成败的实践建议。8.1 指令上下文隔离而不是全局拼接很多 Agent 翻车是因为把所有上下文一股脑拼进每个子任务的 Prompt。正确做法是每个子任务只接收它需要的上下文片段。比如“生成报告”任务不需要看到原始数据全集只需要看到上一个任务提取的结构化摘要。你可以用一个全局状态对象保存所有中间结果但每次构造 Prompt 时只挑选相关字段。这样既降低 Token 成本也减少上下文干扰。8.2 强制结构化输出并准备解析兜底大模型返回的文本风格千变万化你要做的是在系统层面强制结构化。具体有两个手段一是在提示词中给出明确的 JSON 输出示例二是在解析层写一个兼容函数能处理“JSON 前后有 Markdown 标记”“字段值为 null”“字符串里包含换行”等常见问题。解析失败不应该直接崩而应该进入重试流程让模型重新生成。8.3 状态管理是稳定性的基石任务拆解之后状态的记录和传递变得比单次 Prompt 调用更重要。建议把每个子任务的输入、输出、状态、重试次数记录下来至少存在内存中的数据结构里如果流程较长或可能中断还需要持久化到文件或数据库。有了状态快照你就能在任务失败后从最近一个成功的检查点继续而不是整体重跑。8.4 重试策略要限次数、加退避模型调用失败后重试是必要的但要有限制。无限重试会造成成本失控也可能让 Agent 在同一个错误上反复打转。推荐的做法是每个子任务最多重试 2 到 3 次重试之间增加短暂等待重试后仍然失败则走兜底逻辑或者终止任务。判断兜底逻辑是否合理标准是“兜底结果是否安全”比如默认值为空列表比伪造一个数值更安全。8.5 在关键路径上加入人工审核并不是所有环节都适合全自动。对于高风险的决策类任务比如“是否执行退款”“是否修改数据库记录”“是否对外发布内容”任务拆解框架里应该保留一个人工审核的检查点。让 Agent 负责信息收集、方案生成和初步判断让人类负责最终确认。这既符合最小权限原则也是 Agent 工程落地中最稳妥的边界。8.6 用评测数据指导拆解迭代任务拆解是否合理不能靠感觉判断。建议为你的 Agent 准备一组典型输入建立一个回归评测集每次调整拆解结构后都跑一遍。关注三个指标任务整体成功率、平均模型调用次数、平均处理时间。如果某个子任务在评测中频繁失败就优先优化那个子任务而不是整体重写 Prompt。8.7 成本控制要和稳定性挂钩任务拆解会显著增加模型调用次数成本上升是必然的。你可以通过两个方式控制一是让轻量模型处理简单子任务让强模型只处理复杂判断类子任务二是对每个子任务设置最大输出长度和重试次数避免模型生成过长的无效内容。稳定性和成本不是矛盾关系而是需要在任务粒度和模型选择上做联合优化。9. 总结把“聪明”变成“可靠”回到文章开头的问题。你的 Agent 翻车未必是模型不够强更可能是你把一个复杂的开放问题直接抛给了模型。任务拆解的真正价值不是让模型变得更聪明而是让模型的聪明用在封闭的、可控的、可校验的局部步骤上。这篇文章讲清楚了几个关键点Agent 翻车的三层原因任务拆解在 Agent 工作循环中的位置拆解粒度的判断标准一套从目标定义到校验设计的五步拆解法以及一个可复制的最小执行器实现。如果你正在做一个 Agent 项目下一步值得做的实践是挑一个你当前最不稳定的任务先别急着调 Prompt而是按这篇文章的思路拆成三到五个子任务给每个子任务定义输入、输出和校验函数跑一遍对比一下前后差异。你大概率会发现很多原本反复出现的问题在拆解之后就不再出现了。再往后你还可以继续深入状态压缩、多 Agent 协作、自动评测这些方向但前提都是先把任务拆解这一步做扎实。