用 WorkBuddy 编排多工具 AI Agent：从 ReAct 到 Plan-and-Execute 的工程取舍

摘要

单轮对话的大模型是「答题机器」，而真正能干活的是 Agent——给它一堆工具，它能自己决定先查什么、再算什么、最后做什么。但 Agent 怎么编排，直接决定了它靠不靠谱。本文用 WorkBuddy 作为编排端，拆解两种主流范式：ReAct（边想边做）和 Plan-and-Execute（先规划再执行），讲清各自的适用场景、工程实现、以及踩过的坑。读完你能根据任务复杂度选对范式，不再让 Agent 乱调工具、陷入死循环。

一、Agent 到底是什么：从「回答」到「行动」

普通对话：用户问 → 模型答。模型全程在「生成文字」。

Agent 模式：用户给目标 → 模型可以调用工具（查天气、跑代码、读文件、发消息）→ 看到结果 → 再决定下一步 → 直到完成。模型在「思考 + 行动」之间循环。

核心区别在于：Agent 的输出不再只是文字，还可能是「我要调用工具 X，参数是 Y」。一个能编排多工具的 Agent，等于把一堆独立能力粘成了一个会自动办事的同事。

但要小心一个误区：不是所有任务都需要 Agent。如果你只是想做个固定流程的自动回复，写个 if-else 脚本比上 Agent 更稳更便宜。Agent 的价值在「路径不确定、需要模型临场决策」的场景，比如「帮我分析这份合同有哪些风险点并起草回复邮件」——该查哪些条款、要不要搜法规、邮件怎么措辞，都是动态的。

二、范式一：ReAct（边想边做）

ReAct 是当下最主流的 Agent 范式，名字来自 Reason + Act。它的循环长这样：

1. 思考（Thought）：模型分析当前状态和目标，决定下一步做什么；
2. 行动（Action）：调用一个工具，带上参数；
3. 观察（Observation）：拿到工具返回结果；
4. 回到第 1 步，直到模型认为可以给出最终答案。

它把「思考过程」显式写进提示词，强迫模型先推理再行动，比直接让模型吐工具调用更可控、更可解释。

用 WorkBuddy 落地 ReAct：WorkBuddy 本身支持工具调用，你不需要从零实现循环。你可以这样设计你的工具集和提示词：

你是一个智能助理，可以调用以下工具完成任务：

• search_web(关键词)：联网搜索
• read_file(路径)：读取本地文件
• run_code(代码)：执行 Python 代码
• send_email(收件人, 内容)：发送邮件

规则：

1. 每步先说明你的思考，再决定调用哪个工具；
2. 一次只调用一个工具，等结果后再决定下一步；
3. 如果工具报错，分析原因并重试或换方案；
4. 所有信息齐备后，给出最终结论，不要继续调用工具。

关键设计点：强制单步调用 + 思考可见。很多新手让模型一次调一堆工具，结果参数互相依赖、报错连环。约束成「一次一个、看完再走」，稳定性立刻提升。这也是 WorkBuddy 这类客户端默认的策略——把工具调用串行化，避免混乱。

三、范式二：Plan-and-Execute（先规划再执行）

ReAct 在小任务上很灵，但任务一长就露馅：模型容易「走一步看一步」，忘了最初目标，或在无关分支上打转。Plan-and-Execute 是对策。

它的思路是把「规划」和「执行」拆开：

1. 规划阶段：给模型一个高层目标，让它先产出一份完整步骤计划（步骤1、步骤2……），不直接动手；
2. 执行阶段：按计划逐步执行，每步可以用 ReAct 式的工具调用；
3. 动态调整：如果某步失败或发现计划不对，回到规划阶段修订，再继续。

好处是全局观更强——模型一开始就「看见」整条路径，不容易迷路。坏处是规划阶段会多花一次推理，且计划可能一开始就错了（垃圾进垃圾出）。

适用对比：

• 任务步骤少（≤3 步）、路径明确 → 直接用 ReAct，快；
• 任务步骤多、有分支、需要统筹 → Plan-and-Execute，稳；
• 任务需要反复试错（比如调试代码）→ ReAct 更灵活。

用 WorkBuddy 落地 Plan-and-Execute：把它拆成两轮对话。第一轮只让模型出计划：

给定一个目标：<用户的目标> 请只输出一个分步执行计划，每步说明要做什么、可能用到什么工具。 不要执行任何动作，不要写代码，只规划。

确认计划合理后，第二轮把计划喂回去，让模型按计划逐步执行（这步用 ReAct 式的工具调用）。你也可以让 WorkBuddy 在每完成一步后汇报进度，你在关键节点人工把关，避免它跑偏。

四、工具设计：Agent 好不好用，七成看工具

很多 Agent 翻车，不是模型不行，是工具设计烂。三条铁律：

1. 工具描述要像写给人看的操作手册：模型靠工具名 + 描述决定调不调。描述含糊，模型就不会用或误用。把「什么时候用、参数格式、返回什么」写清楚。
2. 参数要简单、好填：不要让模型传一个超长 JSON。能用一个字符串参数解决的，别拆成五个。参数越多，模型填错概率越高。
3. 工具要幂等、可重试：Agent 会反复调用工具，工具如果被调用两次就重复发邮件、重复下单，就出大事。关键动作加确认或幂等保护。

另外，给工具设「边界」：比如 send_email 这种有副作用的工具，最好让 Agent 先生成草稿、经人确认再发，而不是直接发出去。这是生产环境的保命设计。

五、避坑：Agent 最常见的五个翻车现场

1. 死循环：模型反复调同一个工具，停不下来。对策：限制单轮最大工具调用次数（比如 15 次），超过就强制收尾。
2. 幻觉式工具调用：模型编了一个不存在的工具名或参数格式。对策：严格用 schema 约束参数，返回「工具不存在」错误让它纠正。
3. 遗漏步骤：长任务里模型做到一半忘了最初目标。对策：用 Plan-and-Execute，把目标钉在计划里。
4. 副作用失控：Agent 直接删库、直接群发。对策：危险工具加人工确认，最小权限原则。
5. 成本失控：Agent 疯狂调工具，token 烧穿。对策：设步数上限 + 监控单次任务消耗，异常即停。

六、总结

Agent 编排的本质，是在「让模型自由发挥」和「把模型关进笼子」之间找平衡。

• ReAct：轻量、灵活，适合短任务、试错型任务；
• Plan-and-Execute：稳、有全局观，适合长任务、多分支任务；
• 工具设计决定下限，提示词约束决定上限。

用 WorkBuddy 编排多工具 Agent，你不必从零写循环——它的工具调用能力就是现成的 ReAct 引擎。你要做的是设计好工具、写好约束提示词、给危险操作加护栏。做到这三点，你的 Agent 就从「玩具」变成「能放心交办活儿的同事」。