重新理解 AI 系列39:Agent 设计模式:不是万能大脑,而是任务循环的增强方式

副标题：从目标、计划、执行、观察、验证出发，理解可靠 Agent 为什么需要模式化设计

引言

在上一篇《重新理解 AI 系列38：Agent 的基本任务循环：目标、计划、执行、观察、修正》里，我们讨论了 Agent 最基础的运转方式：

目标澄清 → 计划拆解 → 执行动作 → 观察反馈 → 修正路线 → 验证结果。

这条线帮我们把 Agent 和普通聊天区分开了：普通聊天主要是在回答一个问题，Agent 则要围绕一个目标持续推进。

但知道这条循环以后，我们就会设计 Agent 了吗？

还不一定。

因为真实任务的难点并不一样。

有的任务难在目标太模糊，用户只说“帮我优化一下”，但没有说清楚优化什么；有的任务难在步骤很多，需要跨文件、跨工具、跨系统推进；有的任务难在事实不在模型脑子里，必须先读日志、查数据、看文件；还有的任务难在风险很高，不能让模型自己决定是否删除、覆盖、发布。

所以，讲完 Agent 的任务循环之后，我们自然要进入下一层：Agent 设计模式。

我觉得，先不要把“设计模式”想成一堆高大上的框架名词。它不是为了让 Agent 显得更复杂，也不是为了把 planner、executor、memory、verifier 全部塞进系统里。

更准确地说：

Agent 设计模式不是让模型“更像人”，而是让任务循环“更可靠”。

这里的几种模式，也不是官方分类，更不是完整清单。它们只是我从任务循环出发，挑出的几个最适合入门理解的设计视角。

Anthropic 在《Building effective agents》里也提醒过，很多有效的 Agent 实现并不是靠复杂框架取胜，而是靠简单、可组合的模式。这个提醒很适合放在这里：模式不是堆料，模式是补短板。

这一篇，我们先不做“Agent 模式大全”，也不展开复杂论文脉络。我们先看几个最基础、也最常用的模式，理解它们分别在补任务循环里的哪一块短板。

一、设计模式不是框架名词，而是问题的重复解法

“设计模式”这个词，听起来很容易让人紧张。一说模式，很多人脑子里可能立刻出现一堆名词：ReAct、Plan-and-Execute、Reflexion、Multi-Agent、Workflow、Handoff……

这些当然都可以讨论，但一上来就堆名词，很容易把问题讲偏。

我们可以先用一个更朴素的理解：

模式，就是同类问题反复出现之后，人们总结出来的一种稳定解法。

它不是模板崇拜，也不是固定套路。传统软件工程里会谈设计模式，是因为有些问题反复出现之后，人们会慢慢沉淀出更稳定的处理方式。Agent 也是一样。

当我们反复遇到“目标不清，Agent 一上来就跑偏”“计划很漂亮，但执行时完全不更新”“工具很多，但模型不知道先用哪个”“结果看起来合理，但没有验证”“动作风险很高，却没有人工确认”这些问题，就会自然沉淀出一些模式。

所以，Agent 设计模式不是为了显得高级，而是为了减少重复踩坑。它的价值，不是让系统看起来“架构感很强”，而是帮助我们回答一个更实际的问题：

这个任务最容易在哪里断？我应该给它补上什么结构？

模式不是越多越好。

如果任务很简单，一次问答就能解决，硬塞一个复杂 Agent，只会增加成本、延迟和不稳定性。如果任务只需要查一个接口，固定流程就够了，也没必要搞一个会“自主规划”的系统。

模式要服务任务，不要让任务迁就模式。

二、每个模式都在补任务循环里的一块短板

我们再回到上一篇文章里的任务循环：

目标澄清 → 计划拆解 → 执行动作 → 观察反馈 → 修正路线 → 验证结果。

如果把这条线当作 Agent 的基本骨架，那设计模式就不是漂在外面的概念，而是贴在这条线上的增强结构。

比如：计划-执行模式，主要强化“计划拆解”和“步骤推进”；工具优先模式，主要强化“执行动作”和“真实反馈”；草稿-验证模式，主要强化“生成结果”和“验证结果”的分离；人工验收模式，主要强化“风险边界”和“最终责任”。

你会发现，这些模式并不是彼此独立的魔法插件。它们本质上都在回答同一个问题：

这个任务循环里，哪一环最容易出问题？

如果目标不清，就先补目标澄清；如果步骤复杂，就补计划；如果事实很重要，就补工具和观察；如果结果不能只靠感觉判断，就补验证；如果风险进入真实世界，就补人工确认。

这也解释了为什么很多 Agent 项目会失败。不是因为没有用某个流行框架，而是因为任务本身需要的结构没有补上：目标模糊，却急着自动执行；事实缺失，却让模型凭经验猜；输出要准确，却没有验证；动作有风险，却没有边界。这些问题，不是换一个更酷的框架名就能解决的。

图示：设计模式不是漂在任务循环之外的框架名词，而是针对目标、计划、执行、观察、验证等薄弱环节的结构化补强。

三、计划-执行模式：先把任务拆开，再一步步推进

第一种基础模式，是计划-执行模式。简单说：当任务不是一步能完成，而是需要连续推进时，就很可能需要它。

这类任务里，用户通常给的是目标，不是具体操作指令。

比如用户说“帮我排查这个异常”，通常不会把每一步都告诉你：先看哪份日志，再查哪个配置，再跑哪个测试，再怎么判断结果。这时候，Agent 需要先把目标拆成当前可执行的步骤。

一个典型结构是：

• • Planner 先理解目标，拆出阶段性步骤。
• • Executor 按步骤执行。
• • 每一步执行之后观察反馈。
• • 根据反馈继续执行、调整计划，或者停下来问人。

但这里一定要注意：计划-执行不是“一次计划到底”。真实任务中，计划经常会被反馈改写：日志缺失、接口没权限、问题不在代码而在配置里，都可能让原计划失效。

好的计划，不是把未来一次性写死，而是让下一步更清楚。

计划-执行模式最怕两种情况。

第一种，是计划写得很好看，但没有执行细节。比如“分析问题、定位原因、输出方案”，这不是计划，只是把任务换了一种说法。第二种，是执行过程中不更新计划。明明反馈已经说明原来的判断错了，Agent 还沿着旧计划继续走，看起来很有条理，其实越走越偏。

所以，计划-执行模式的关键，不是生成一张漂亮的任务清单，而是让 Agent 在复杂任务里始终知道：我现在做什么，为什么做，做完以后看什么反馈。

图示：左边是“一次计划到底”的脆弱清单，右边是计划、执行、观察、调整下一步的动态循环。好的计划不是锁死未来，而是让下一步更清楚。

四、工具优先模式：别先猜，先去现场看证据

第二种基础模式，是工具优先模式。它特别适合那些“事实在外部世界”的任务。

排查异常时，事实在日志里；修改代码时，事实在现有实现里；分析数据时，事实在数据表里；查询业务状态时，事实在系统接口里；检查网页问题时，事实在页面、请求和控制台输出里。

这类任务如果只靠模型推断，就很容易出现一种熟悉的问题：模型说得很像那么回事，但其实没有看现场。它可能根据经验猜一个原因，也可能根据常见模式给一套建议，甚至还能把建议写得很完整、很自信。但这不等于它真的知道发生了什么。

工具优先模式的直觉很简单：

先接触事实，再组织判断。

它不是工具崇拜，不是说工具越多越好。它强调的是：如果任务有明确的外部证据源，就不要让模型在没有证据的情况下先编一个答案。

比如排查异常，好的 Agent 不应该一上来就说“可能是缓存问题、网络问题、数据库问题”。它应该先确认时间范围，读取日志，查看错误码，对比最近变更，再形成可能原因。比如修改代码，它也应该先读现有实现，理解调用链，确认测试方式，再决定怎么改。

这和 ReAct 论文里的一个核心直觉是相通的：让模型在推理和行动之间交替前进。思考可以帮助它更新计划，行动则让它接触外部环境，获得新的信息。

工具优先模式其实是在对抗 LLM 的一个天然倾向：当信息不够时，它仍然会生成看起来合理的文本。

而 Agent 的工程价值，就在于把模型从“凭空生成”拉回到“基于现场判断”。

五、草稿-验证模式：把“生成”和“判断”分开

第三种基础模式，是草稿-验证模式。它适合那些“结果看起来合理，但不能只靠看起来”的任务。

比如写了一段代码，要跑测试；生成了一份报告，要核对数据口径；整理了一批资料，要检查来源和遗漏；输出一个方案，要看是否满足约束；生成一段结构化内容，要校验格式和字段。

很多 Agent 的问题就在这里：模型生成了一个结果，然后自己宣布完成。这很危险，因为 LLM 很擅长生成“看起来合理”的东西，但“看起来合理”和“真的正确”之间，隔着验证。

草稿-验证模式，就是把这两件事拆开：先生成候选结果，再用独立标准检查它。

这里的 Verifier 不一定是另一个模型。它可以是测试用例、类型检查、规则校验、脚本检查、数据对账、人工审阅，也可以是事实来源核对。

关键是：验证不能只是“再看一遍”。如果模型只是把自己刚刚生成的内容再读一遍，然后说“整体没问题”，这不叫验证，最多叫自我安慰。

真正的验证，需要有标准。

代码有没有通过测试？数据行数是否对得上？字段是否完整？事实有没有来源？格式是否符合要求？高风险结论有没有人工确认？

草稿-验证模式的核心，不是让 Agent 永远不犯错，而是让错误更容易被发现。

所以我觉得可以这样理解：

可靠不是不犯错，而是有机制发现错误。

这也是为什么很多可靠 Agent 系统里，会专门设计 verifier、critic、reviewer、guardrail，或者把测试、检查、审批接进任务循环。OpenAI Agents SDK 里的 guardrails，也是在不同阶段加入检查和验证。具体实现可以不同，但背后的思想是一致的：不要把生成结果直接等同于可信结果。

图示：候选结果只有经过独立验证、证据检查，并在高风险动作前加入人工确认，才更接近真正可交付的结果。

六、人工验收模式：不是每步都问人，而是在关键点让人负责

第四种基础模式，是人工验收模式。这个模式看起来最朴素，但在真实系统里非常重要。

很多人一听 Agent，就会想象“完全自动化”：用户说一个目标，Agent 自己计划、自己执行、自己完成。这个方向当然很有吸引力，但也很容易危险，因为 Agent 一旦连接真实系统，动作就会产生真实后果。

读取文件和删除文件，不是一个风险等级；生成草稿和直接发布，不是一个风险等级；查询数据和批量修改数据，也不是一个风险等级。

人工验收模式要解决的，不是“让人每一步都盯着”，而是“让人卡在真正需要负责的位置”。

比如：目标是否理解正确？可以使用哪些数据和系统权限？是否允许执行删除、覆盖、发布、发送、付款这类动作？这个判断是否涉及组织取舍、品牌表达或价值判断？最终结果是否可以交付？

这些地方，不应该默认交给模型自己决定。但反过来，人工验收也不是让人变成每一步的审批机器。如果 Agent 每读一个文件、每跑一个检查、每生成一个草稿都要问一次人，那它就不是一个可靠助手，而是一个很会打断人的表单系统。

更好的方式是：低风险准备工作让 Agent 自动完成，到关键节点停下来，解释判断、展示证据、请求确认。人确认之后，再执行高风险动作。

所以，人工验收不是降低自动化，而是在提高可信度。一句话：

人不需要挡在每一步前面，但必须站在风险和责任真正发生的地方。

七、怎么选择模式：先看任务，而不是先看框架

讲到这里，我们可以做一个简单收束。设计 Agent 时，不要一上来问：“我要不要用某某框架？”

更好的问题是：

这个任务的主要不确定性在哪里？

如果目标模糊，就先强化目标澄清；如果步骤很多，就用计划-执行；如果外部事实很重要，就用工具优先；如果输出质量很重要，就用草稿-验证；如果动作风险高，就加人工验收；如果状态容易断，就加状态记录和可恢复执行。

这比“把所有模式都上齐”更重要。因为模式不是堆料，而是按任务风险和不确定性做取舍。

一个简单任务，可能只需要工具优先：查一下真实数据，然后回答。一个复杂任务，可能需要计划-执行加草稿-验证：先拆步骤，再一步步做，最后用测试或规则验收。一个高风险任务，还要加人工验收：准备工作可以自动完成，但真正发布、删除、发送之前必须停下来确认。

所以，同样叫 Agent，结构可以很不一样。

可靠 Agent 的关键，不是结构多复杂，而是结构是否刚好补上这个任务最容易断的地方。

结语

在上一篇文章里，我们理解了 Agent 的基本任务循环。这一篇，我们进一步讨论了 Agent 设计模式。

如果只记住一个观点，我希望是这一句：

Agent 设计模式不是框架炫技，而是针对任务循环薄弱环节的工程化增强。

计划-执行，让复杂任务有步骤；工具优先，让判断贴近事实；草稿-验证，让结果接受检查；人工验收，让风险和责任回到人类边界。

这些模式不是彼此孤立的名词，而是可以围绕任务组合起来的结构。

当目标不清时，先补目标；当事实不在模型里时，先看现场；当结果需要可靠时，增加验证；当动作会影响真实世界时，让人类回到关键位置。

这就是 Agent 从“看起来会做事”，走向“真的能可靠推进任务”的关键。

一个可靠 Agent 的设计，不是把模型推到台前表演，而是把目标、行动、反馈、验证和边界组织成一套稳得住的结构。

参考资料

• • Anthropic Engineering: Building effective agents, 2024-12-19. https://www.anthropic.com/engineering/building-effective-agents
• • Shunyu Yao et al.: ReAct: Synergizing Reasoning and Acting in Language Models, arXiv:2210.03629. https://arxiv.org/abs/2210.03629
• • OpenAI Agents SDK: Agents. https://openai.github.io/openai-agents-python/agents/
• • OpenAI Agents SDK: Guardrails. https://openai.github.io/openai-agents-python/guardrails/