引言
大模型正从"会聊天"走向"能干活"，工具调用（Tool Use / Function Calling）已成为智能体落地的关键能力。在持续推进的企业AI化转型中，越来越多团队希望让模型调用内部系统、查询数据库、驱动业务流程，而理解工具调用的底层范式，是做好这件事的前提。
但在工程实践中，Few-shot（少样本提示）与 ReAct（推理-行动）经常被混为一谈：一个解决"怎么教模型输出格式"，一个解决"怎么让模型自主调工具"，二者职责不同却常被当作一回事，导致提示设计混乱、效果不稳。
本文把两者拆开讲清：Few-shot 如何用少量示例奠定输出结构，ReAct 如何用"思考-行动-观察"循环完成工具调用，二者如何配合，并给出可直接套用的提示模板与五条高频技术疑问，帮助读者建立清晰的心智模型。
一、两种范式到底在解决什么问题
用一句话区分：Few-shot 是"用示例教格式"，ReAct 是"用循环走流程"。前者属于上下文学习（In-context Learning），靠提示里的范例让模型归纳规律；后者把推理与行动交织成可迭代流程，每一步都依赖上一步的真实观察。
二、三个关键差异点
1. Few-shot 是"示范"，ReAct 是"流程"
Few-shot 本质是给模型看几个"输入→输出"配对，它便照猫画虎地套用；而 ReAct 是一套运行机制------先写 Thought 推理该调什么工具，再输出 Action 调用，拿到 Observation 后继续推理，直到能作答。一个是静态示范，一个是动态流程。
2. 抑制幻觉的能力不同
纯 Few-shot 遇到实时数据仍可能编造答案；ReAct 强制走工具，把工具返回的真实结果回填上下文，使结论建立在可验证数据上，显著降低幻觉。这也是它适合"查天气、查汇率、查库存"这类任务的原因。
3. ReAct 通常依赖 Few-shot 启动
在 ReAct 原始论文中，提示几乎都以 few-shot 演示开头：先放 2--3 条完整的 Thought/Action/Observation 轨迹，模型据此学会格式，再在新任务上仿写。换言之，Few-shot 是 ReAct 的"格式模板"。
三、两者如何配合：Few-shot 是 ReAct 的"演示模板"
实际搭建一个能查天气、汇率的助手时，提示里先给几条完整 ReAct 轨迹作示例，遇到新问题模型就会仿写同款结构。下图先给出 ReAct 的机制循环，再给出组合提示骨架，帮助建立直观认识。
你是一个能调用工具的助手。需要外部信息时，按以下格式输出：
Thought: <推理> Action: <工具名>(<参数>) Observation: <系统回填>
Final Answer: <最终回答>
--- 示例 --- Question: 1美元约多少人民币？
Thought: 需汇率 → Action: get_rate(USD,CNY)
Observation: 7.18 → Final Answer: 约7.18元
--- 新任务 --- Question: 北京今天天气怎么样？
如上图所示，演示轨迹作为"格式模板"被前置到提示中，新任务到来时模型沿相同结构依次生成 Thought、Action 与 Observation，而非自由发挥。值得补充的是，如今主流框架与模型厂商已把"手动 ReAct"封装为原生函数调用（Function Calling）与统一协议，开发者不必手写循环；但理解这套底层范式，仍是调试自定义智能体、设计提示与处理异常的基础。
四、全文总结
回到开头的问题：Few-shot 负责"教格式"，ReAct 负责"走流程"，一静一动、相辅相成。固定结构输出用前者，依赖外部真实信息的多步任务用后者。
在真实的企业AI化转型项目中，多数生产级智能体需要二者结合------用 Few-shot 锚定稳定的输出格式，用 ReAct（或其原生封装）打通工具与数据。先想清"要不要调工具"，再决定"用哪种范式"，是落地时最实用的判断框架。
五、AI 工具调用的未来展望
工具调用正从"手工编排"走向"原生内建"，笔者认为接下来有三个清晰方向。下图给出了生产级智能体的工具调用流水线形态，便于理解方向二与方向三。
方向一：从手动 ReAct 到原生函数调用
模型厂商把工具协议直接内置，开发者以 JSON Schema 声明函数即可，模型自行决定调用时机与参数，省去手写解析与循环，错误率更低、延迟更小。
方向二：多工具自主规划与并行编排
智能体将具备任务拆解能力，面对复杂请求自行规划步骤、并行调用多个接口（如同时查库存、算物流、比价格），由编排层汇总结果，而非单线串行。
方向三：可观测、可控与可回滚
面向企业场景，工具调用需全程可追溯、可中断、可回滚。调用链路日志、权限沙箱与人工确认节点，会成为生产级 Agent 的标配能力。
如图4所示，规划节点负责拆解任务与决定调用时机，工具节点并行执行，观察结果统一回流------这正是企业级 Agent 在可控、可观测前提下的可扩展形态，也是上述三个方向共同指向的落地画面。
六、技术FAQ
1. Few-shot 最少给几个示例才有效？
通常 2--5 个即可见效，任务越复杂所需示例越多。相比数量，示例质量更关键：需覆盖典型情况与边界情形，且输入输出格式保持统一，避免互相矛盾。
2. ReAct 一定比直接问答更好吗？
不一定。简单事实类问题直接回答更快、更省 token；只有当任务依赖实时或外部数据、或需要多步推理时，ReAct 的工具调用才真正体现价值，否则反而增加开销。
3. 程序如何解析模型的 Action？
约定结构化格式（如 JSON 或固定函数签名），用解析器提取工具名与参数，再路由到对应函数执行；执行结果以 Observation 回填上下文，继续下一轮推理。
4. ReAct 会不会陷入无限循环？
可能。需设最大步数（常见 5--8 步）与终止条件（出现 Final Answer 即停止）；若超步数或工具报错，应退回兜底回答并记录日志，避免资源空耗。
5. 现在还需要手写 ReAct 吗？
多数框架已内置 Function Calling，常规场景无需手写。但理解 ReAct 有助于调试自定义智能体、设计提示词、处理异常与多轮工具失败，仍是必备底层认知。
本文仅代表作者个人行业观察，不构成任何商业建议。