第二章 ReAct 与工具调用：给模型装上双手

第二章 · ReAct 与工具调用：给模型装上双手

本章要回答的三个问题：模型怎么"点菜"一样地调用工具？一次工具调用从发起到结果回填，完整链路长什么样？让模型自主循环干活时，怎么保证它不跑飞、不停不下来？

为什么会有这一章

第 1 章把四个缺口摆上了桌，其中最要命的是"没有手"——不能行动的智能体只是个会写建议的顾问。补齐这个缺口的技术组合叫 ReAct（Reasoning + Acting，推理与行动交替）加 Function Calling（函数调用协议）：模型负责决定"做什么"，程序负责"真去做"，结果再喂回模型。本章是全册地基，后面每一章的组件——记忆里存的是工具返回的观察、规划拆出的是一串工具调用、护栏拦的是即将执行的动作——全部挂在这套机制上。

值得强调的是学习的性价比：这一章的内容不依赖任何框架，用两三百行原生代码就能完整实现。先手写一遍再去看 LangChain、LangGraph 之类的框架，你会发现框架帮你管的正是本章讲的这些细节，而不是什么魔法。

本章全景

图：从聊天到干活的三步补短路线

读完能解决什么

• 能为一组业务操作设计工具定义：名字、描述、参数 schema，让模型一次选对。
• 能说清一次工具调用的完整时序，并手动实现"意图解析—参数校验—执行—结果回填"。
• 能手写一个带步数上限、错误恢复与终止判断的 ReAct 循环，不依赖任何框架。
• 能诊断"智能体不干活"的三类根因：契约不清、循环失控、观察太脏——并分别给出修法。

各节怎么分工

先决条件

• 读完第 1 章，理解"感知—决策—行动"闭环的定义。
• 会读 Python：字典、函数、异常处理。本章代码全部可脱离 SDK 理解，模型调用统一写作 llm.complete。
• 不需要前端或运维知识。

往下走到哪

本章结束时你有一个能跑的单步决策与多步循环，但它的"记性"只有当前上下文。第 3 章解决记性的问题：窗口怎么管理，过去发生的事怎么存、怎么查。

上手前的三个提醒

先跑不通的，多半是契约不是代码。第一次让模型稳定输出可解析的动作格式，失败率会高得出乎意料——JSON 里混一句客套话、参数里带个单位后缀，都是常见开局。处理方式在 2.1 节：违约不崩溃，把解析错误喂回去让它自己改，两三轮之后格式服从会稳定下来。这个"喂错自修"的机制值得优先实现，它是循环韧性的第一块砖。

工具宁少勿多。原型期的诱惑是把所有能想到的工具一口气注册进去。经验做法是先注册当前场景必需的三到五个，跑顺了再按需增加——工具数量的膨胀会先于你察觉地拖垮选中率（这一点 5.1 节有系统分析）。

从第一天就留轨迹。原型的每一次运行都把完整的思考、行动、观察序列落盘。它在调试阶段是你的排查依据，在评测阶段是判分材料，在给相关方演示时是"它为什么这么做"的解释材料——一份留痕，三处受益。