规划（Planning）：Agent 怎么把帮我做一个网站拆成 20 个步骤

我最早让 GPT-4 写一个完整网站的时候，就直接说：“帮我做一个个人博客网站，要好看、能部署。”然后它吐出一大段 HTML、CSS 和 JavaScript，还夹杂着“这是你的博客”之类的注释。兴奋地把代码贴到浏览器里，果然——页面跑偏了，样式没加载，链接点不开。我对着屏幕叹气：它明明知道怎么做，但就是没把事做对。后来我才明白，能说出步骤和能按步骤做成事，中间隔着一条巨大的鸿沟。而填补这条鸿沟的东西，就叫 规划（Planning）。

现在很多 AI Agent 产品在演示里都能“帮你做一个网站”，你只要说一句需求，它就能拆成 20 个步骤，然后一步步执行：创建项目结构、写 HTML 骨架、填充样式、添加交互、部署到云端……看着很爽，但如果你仔细看它的拆分过程，会发现很多反直觉的细节。这篇文章，我就想带你钻进 Agent 的“大脑”，看看它到底是怎么把一句模糊的话，变成一个可执行的步骤清单的。而且不光讲原理，也会聊到它经常在哪翻车，以及我们该怎么理解它现在的能力边界。

先让模型把“想法”说出来：Chain-of-Thought 的启发

规划不是凭空出现的概念。2022 年，Google 的一篇论文Chain-of-Thought Prompting 让很多人第一次意识到：让模型在给出最终答案之前，先一步步把推理过程写出来，能极大提升复杂问题的正确率。比如做数学题，如果你让它直接说答案，它可能瞎猜；但如果你让它“先写步骤，再给答案”，它就能做对很多题。

这个思路后来被疯狂扩展。如果说 Chain-of-Thought 是让模型在脑子里打草稿，那规划就是让模型在行动前先画一张施工图。施工图不光要列出步骤，还要考虑步骤之间的依赖关系、需要哪些工具、每一步的输出是什么。这比单纯解一道数学题要复杂得多，因为现实世界里的任务经常有分支、有不确定性，而且一旦某一步做错了，后面可能全盘崩溃。

我最早以为规划就是让模型把步骤列出来，然后按顺序执行。但后来发现，单纯“列出步骤”远远不够，因为模型经常会脑补出一些根本实现不了的步骤，或者把顺序搞反。比如它可能会写“第 3 步：部署到服务器”，但第 2 步连 HTML 文件都还没生成。这种低级错误暴露了一个关键问题：模型在生成步骤列表时，并没有真正理解每一步的前置条件，它只是在“流畅地编故事”。

ReAct：把推理和行动拧在一起

2023 年初，一篇叫 ReAct 的论文把规划这件事往前推了一大步。它提出了一种模式：让模型交替输出“思考（Thought）”和“行动（Action）”，然后根据行动的结果再产生新的思考，循环往复。举个例子，当你要它做一个网站时，它的流程可能是：

• Thought: 我需要知道用户想要什么风格的博客，先问一下。 Action: 向用户提问“你喜欢极简风还是卡片风？”
• Thought: 用户选了极简风，那我先建一个项目文件夹，然后生成 index.html。 Action: 调用 create_file 工具，在当前目录创建 index.html。
• Thought: 页面需要导航栏，我来写一段语义化的 HTML 骨架。 Action: 调用 edit_file 工具，在 index.html 中写入
  
  …

  。

这种模式之所以有效，是因为它把“想”和“做”绑在了一起，每一步都基于上一步的实际结果，而不是凭空想象整个计划。就像你装修房子，你会先拆墙，看看里面有没有管线，然后再决定下一步怎么走，而不是一开始就画死所有细节。ReAct 成为了很多 Agent 框架（比如 LangChain 的 Agent 模块）的基础范式。

但 ReAct 也有一个很明显的毛病：它太短视了，走一步看一步，容易在局部最优里打转，却忘了全局目标。比如在做一个电商网站时，它可能花 10 步去优化一个按钮的颜色，而忘了购物车功能还没做。而且，如果某一步行动失败了，它可能会反复尝试同一个错误操作，陷入死循环。

Plan-and-Execute：先画蓝图，再施工

针对 ReAct 的短视问题，另一种思路出现了：先让模型生成一个完整的计划，然后再按计划一步步执行。这种模式叫 Plan-and-Execute，最早由Plan-and-Solve Prompting 提出，后来被 LangChain 和很多 Agent 框架采用。

它的核心流程是：

1. 用户给出最终目标。
2. Planning Agent 生成一个步骤列表，每个步骤包含描述、工具调用、预期输出。
3. Execution Agent 按顺序执行步骤，每步执行完后把结果反馈给 Planner，Planner 可以决定是否修改后续计划。

这就好比一个建筑项目：先由建筑师画出完整图纸，然后施工队按图施工，施工过程中如果发现图纸有问题，再反馈给建筑师修改。这样一来，模型在规划阶段就能从一个更高的视角审视整个任务，避免“只见树木不见森林”。

我自己的实践也印证了这一点。我最早用 ReAct 模式让 Agent 搭建一个包含多个页面的网站时，它经常在某个页面卡住，然后忽略其他页面。后来我改用 Plan-and-Execute，让模型先列出所有页面及其依赖关系，再逐个生成，效果好了很多。不过，新的问题又来了：初始计划往往不完美，模型会高估一些步骤的可行性，或者低估某些步骤的复杂度。比如它可能计划“用一行命令部署到 Netlify”，但实际执行时发现需要配置环境变量、处理认证，这就比它想的复杂得多。

计划怎么生成？拆解、排序、依赖管理

那么，当我们说“把目标拆成 20 个步骤”时，模型到底在做什么？它并不是真的在“思考”，而是在做一个高维度的条件生成任务。简单来说，模型基于大量的训练数据（包括代码库、教程、项目文档）学会了“做网站”这类任务的典型模式，然后根据你的具体需求，从这些模式中抽取出一个可能的步骤序列。

这个过程可以拆成三个关键动作：

• 任务分解：把目标“做一个网站”拆成子任务，比如“设计页面结构”“编写 HTML”“添加样式”“部署”。模型会利用它学到的常识（比如网站通常包含前端和后端，或者静态网站只需要 HTML/CSS/JS）来生成子任务。如果一个子任务过于复杂，它还可以继续分解，比如“编写 HTML”可以拆成“写 header”“写 main 内容区”“写 footer”。
• 步骤排序：确定哪些步骤必须先做，哪些可以并行。这一步很关键，模型经常在这里翻车，因为它对现实世界的物理约束和时间逻辑理解很弱。比如它可能会把“购买域名”排在“部署”之后，或者在“写 CSS”之前先“写 JavaScript 交互”。为了提高排序的准确性，一些框架会引入结构化约束，比如要求模型用 JSON 格式输出步骤，并标注每个步骤的“前置步骤 ID”。
• 工具分配：为每个步骤指定要调用的工具或 API。比如“创建文件”用 file_write 工具，“搜索图片”用 search_images 工具。这要求模型对工具的功能有准确的理解，否则就会“拿错工具”。

一个典型的例子来自 TaskWeaver（微软开源的 Agent 框架），它会把用户需求转成结构化的计划，每个步骤都包含“任务名”“工具”“输入”“输出”四个字段。这种结构化输出大大减少了执行阶段的歧义。

但即便如此，模型生成的计划仍然是一个“概率最高的猜测”，它并没有真正理解这个世界的因果关系。比如当你让它“做一个登录功能”时，它可能计划去调用一个生成用户认证代码的工具，但如果你没有事先告诉它你用的是 JWT 还是 Session，它可能就会随便选一个，导致后续跟你的后端不兼容。

当计划出错时：反思与重规划

任何做过项目管理的人都知道，计划不可能一蹴而就。Agent 也是如此，规划能力真正高级的地方不在于一次生成完美计划，而在于能在执行中发现错误并修正计划。这被称为 Reflection 或 Replanning。

2023 年有一篇叫 Reflexion 的论文提出了一个很巧妙的方法：让 Agent 在执行每一步后，用语言总结当前状态、检查是否偏离目标，如果偏离就生成一个“反思”文本，然后把这个反思塞进接下来的规划提示里。比如，如果 Agent 发现在写 HTML 时忘了考虑移动端适配，它就会在反思里写：“之前的步骤忽略了移动端适配，导致页面在小屏幕上错位，接下来的步骤需要添加响应式设计。”然后 Planner 会根据这个反思调整后续步骤。

这种反思机制让 Agent 的行为更像一个人类新手：边做边学，边犯错边改。但它的局限性也很明显：反思的质量完全取决于模型能否准确诊断错误原因。如果模型把问题归咎于工具调用失败，而实际上是计划本身逻辑有误，那它就会反复尝试同样的错误，陷入“反思死循环”。

我在用 AutoGPT 做网站时遇到过这种情况：它尝试用 Python 启动一个 HTTP 服务器，但端口被占用，于是它反思说“工具调用失败，换一个端口”，但换端口后还是失败，它又反思说“工具调用失败，检查防火墙”，其实真正的问题是它没有权限。它绕着真正的问题走了三圈，浪费了大量 token。

多 Agent 协作：让规划更复杂也更有用

当任务越来越复杂，单个 Agent 的规划能力就捉襟见肘了。于是出现了多 Agent 协作模式，比如 HuggingGPT 把任务拆解后分配给不同的专家模型，一个 Planner 作为“经理”协调多个 Worker。这种架构下，规划不仅要考虑步骤，还要考虑哪个 Agent 最适合执行哪个步骤，以及它们之间的通信协议。

这让我想起一个有趣的对比：人类做项目时，项目经理会分配任务给不同的人，每个人又可以自己规划自己的子任务。但 AI 的多 Agent 系统目前还做不到这么灵活，因为 Planner 和 Worker 之间的信息传递还是靠自然语言，容易产生歧义和丢失信息。而且，当多个 Worker 同时执行时，如何保证它们不互相冲突（比如同时修改同一个文件），仍然是一个开放问题。

目前规划能力的真实边界

说了这么多，我们回到最初的问题：Agent 到底能不能可靠地把“帮我做一个网站”拆成 20 个步骤并执行成功？我的判断是：在任务相对标准、依赖关系清晰、且工具调用稳定的情况下，可以做到 80% 的程度；但一旦任务带有非标准需求或需要灵活判断，就很容易翻车。

一张表说清不同场景下的表现：

而且，所有规划都受限于模型的上下文窗口长度。当一个网站拆成 20 个步骤，每步执行后产生大量日志和代码，很快就超出上下文长度，导致模型“忘记”前面的步骤或目标。虽然像 TaskWeaver 这样的框架通过向量数据库和摘要机制来缓解，但本质上仍是一个挑战。

更根本的问题在于：当前的 LLM 规划是完全基于模式的，它没有真正的“目标感”和“世界模型”。它之所以能拆出步骤，是因为它在训练数据里见过类似的项目结构，而不是因为它理解了“为什么需要先做这一步再做那一步”。这也解释了为什么在面对一个新奇的任务时，它常常会给出一个看似合理但实际不可行的计划——就像让一个只读过菜谱但没下过厨的人去设计宴会菜单。

常见误解 FAQ

模型生成的步骤清单是它“思考”出来的吗？

不是。它是在做条件生成，基于训练数据中的模式，拼凑出一个最可能被人类接受的步骤序列。它没有“思考”这个过程，也没有真正的因果推理能力。所以你会看到它有时写出逻辑不通的步骤，就像梦游的人说出的话——流利但没逻辑。

Plan-and-Execute 是不是比 ReAct 更好？

不一定。Plan-and-Execute 适合任务结构清晰、变化少的情况；ReAct 适合需要频繁与环境交互、动态调整的任务。实际项目中，很多框架会混合使用：先用 Planner 生成一个初始计划，然后 Execution 阶段用 ReAct 模式灵活处理每一步。

为什么 Agent 有时会陷入死循环，反复执行同一个步骤？

因为它的反思机制没有正确诊断问题。它看到步骤执行失败，但归因错误，于是尝试同样的解决方案，或者做出微小调整但没触及根本原因。这就像一个人反复按电梯按钮，以为按得越快电梯就越快来。

多 Agent 规划是不是更聪明？

多 Agent 可以分担复杂度，但增加了通信开销和协调难度。目前还没有一种成熟的多 Agent 系统能稳定地处理复杂网站开发，它更多是研究阶段的概念。实际上，让一个 Agent 集中规划，再调用不同的工具，可能比多个 Agent 互相“聊天”更高效。

最后留一个让我自己都细思极恐的观察：当 Agent 把“做一个网站”拆成 20 个步骤并执行时，它其实只是在执行一个超高质量的“填空游戏”，它并不知道自己正在创造一个网站。它理解 HTML 标签，但不理解浏览器如何渲染；它知道部署命令，但不知道服务器在哪。它像一个极其熟练的工人，但不是一个有创造力的工程师。下次你看到 AI 帮你搭好一个网站时，不妨想想：它到底是在“建造”，还是在“拼凑”？