Agent稳定交付的关键：学会拆解大任务

同一个模型，同一个任务，为什么有人的 Agent 跑出一堆垃圾，有人的却能交付全套？差距往往不在模型本身，而在于你有没有教会 Agent 一件事——把活拆开。

本文基于 B站一位技术 UP 主的分享，系统梳理了大模型任务拆解的方法论：从「一次性塞进整个项目、烧掉 20 多万 token 却得到编造数据」的翻车现场，到通过结构化拆解实现稳定交付的完整路径。

为什么大任务不能一次性塞给Agent

很多人有一个直觉误区：模型越来越强，上下文窗口越来越长，那把整个项目指令一次性塞进对话，让它自己领悟不就好了？

现实是残酷的。UP 主举了一个经典翻车案例：跑了一整页、烧掉 20 多万 token，前三页全是行业历史，数据全是编造的，写到第五页时，Agent 甚至忘了自己做的是什么产品。

这背后有三个硬性约束：

注意力是 U 型的：长文本里模型看起来很强，但往往开头结尾记得住，中间却犯迷糊，学名叫「中间迷失」（Lost in the Middle）。
错误会复利：每一步 90% 靠谱，五步串联下来就只剩约 59% 的成功率。
工作记忆有限：中间结果塞满上下文，模型就忘了自己在干嘛。

打个比方：你买了套毛坯房，对装修队说「把这房子弄能住，我出趟差」——你敢吗？水电、泥瓦、木工、油漆，每一步都得单独安排、逐步验收。Agent 也一样，大任务不能整只吞，得拆。 拆解就是 AI 世界里的施工进度表。

第一招：规划与执行分离（Plan and Execute）

主流 Agent 框架最常用的骨架，是 Plan and Execute（规划与执行分离）：

Planner 只想不做：把大任务拆成带编号的进度表。
Executor 只做不想：逐条领取、执行。

为什么非得拆开？因为分工才能专注。规划时容易被执行细节带偏，执行时又容易忘了总目标。分开之后各司其职，稳定性大幅提升。

更关键的是，拆出来的不是一份流水账，而是一张 DAG（有向无环图）。以竞品分析为例：采集三家竞品的数据互不依赖，可以并行；清洗要等采集完成；分析要等清洗完成。箭头代表依赖关系——谁不依赖别人，谁就先跑；依赖别人的，等料到齐再动。有了这张依赖图，调度才有章法，哪几步能并行省时间一目了然。

任务拆到多细才合适

那是不是拆得越细越好？恰恰相反。

太粗等于没拆，太细则成本爆炸

太粗：等于没拆，照样啃不动。
太细：三十个微任务，光传递上下文就把人累死，成本爆炸，还谁都看不清全貌。

判断标准只有一句话：每个子任务能在一次 LLM 调用里完成，有清晰的输入，有可验证的产出。 像「分析市场」这种就太粗了，需要继续拆分。

子任务内部：ReAct 循环驱动执行

每个子任务内部，Agent 走的是一个循环——ReAct：想一步（Thought）、做一步（Action）、看一步（Observation）。

这不就是我们调试代码的方式吗？猜一下、跑一下、看看日志、再修正。调试的本质就是反馈循环。没有 Observation，Agent 就是闭着眼睛瞎猜；有了它，每一步都能及时纠偏。

计划必须是「活」的：动态重规划

一次性计划是最常见的错觉。走到第三步，API 突然挂了，这张 DAG 不就废了？

所以计划必须能动态调整。当 Observation 不符合预期，就交回 Planner 重新规划：API 不行就换网页抓取，DAG 局部重绘，而不是推倒重来。

靠谱的 Agent = 好的初始计划 + 敢于认错改道的能力。

上下文管理：只传摘要不传聊天记录

还有一个容易被忽略的关键环节——上下文交接。

原始产出必须压缩成摘要再传递

水电师傅交给你的是一张交接单：哪根管走了哪、开关在哪，而不会把自己跟业主的全部聊天记录甩给下一道工序。

Agent 也一样。每个子任务的原始产出，必须压缩成摘要，再进入下一段上下文；原始资料则沉到长期记忆（向量库）里，需要时再检索。记住：上下文是昂贵的地皮，别堆垃圾。

验收机制：每个子任务都要闭环

Agent 怎么知道一个子任务做完了？总不能凭感觉。

答案是验收标准，而且写进任务定义里。比如「价格表至少三行、必须带来源 URL」——达标就盖章放行，不达标就打回 ReAct 循环重做。

没有验收，拆解就是形式主义。错误留到下一步，下游就得替上游背锅。

生产环境的三个坑与三道护栏

头号坑：没有终止条件

某一步一直失败，Agent 会不会一直重试？答案是会——它会一直试到把你的账户余额刷爆。这是生产事故的头号来源。

没有终止条件是头号生产事故

防护三件套：

每个子任务设最大迭代数；
全局设预算上限；
超限触发兜底策略：要么降级处理，要么升级给人。让 Agent 学会说「不行」，也是可靠性的一部分。

第二坑：上下文污染与并行脏读

把中间结果全塞进上下文，注意力被稀释，Agent 会在自己的笔记里迷路——解法就是前面说的「传摘要，不传原始数据」。

另一个是并行脏读：任务 A 还没写完，任务 B 就去拿它的产出，读到半个文件。记住：并行只属于互相独立的节点，有依赖的必须设门，验收通过才放行。

三道护栏保障生产可靠性

结构化才是治理的开始

真正上生产，还需要三道护栏：

用 JSON Schema 约束输出。让模型自由发挥是混乱的开始，结构化输出才是治理的开始。
关键节点放人工检查点。群发邮件前、删库前，停下来问人。
完整日志留痕。把每一步的 Thought 和 Action 都记进日志，出问题能回放、能定位到跑偏的那一步。否则就是黑盒，你连它怎么死的都不知道。

总结：Agent稳定交付四句口诀

把整套方法论浓缩，就是四句话：

大任务是进度表（规划执行分离，拆成 DAG）；
子任务是闭环（一次调用一份产出，ReAct 反馈，步步有验收）；
上下文是地皮（传摘要不传原料）；
可靠性靠护栏（迭代上限、预算上限、人工检查点、日志留痕）。

同一个模型、同一个任务，只是加了一张进度表，就能从翻车走向稳定交付——这就是任务拆解的价值。

那拆得好，能不能让好几个 Agent 一人领一条分支？那是多智能体协作的话题了。但要记住：一切协作都从拆解开始。拆不好，Agent 再多也只是多了几个甩手掌柜。