到目前为止，我们的模型只会说，不会做。它能告诉你「这个订单应该退款」，但退款动作本身，还得人点按钮。这一章讲的是跨越这条线的机制——也是「聊天机器人」和「智能体」之间真正的分界。
工具调用：模型写申请单，程序去执行
工具调用（function calling）的机制，说穿了朴素得让人意外：你把系统里可供使用的函数（查订单、算运费、发邮件）按 JSON Schema 的格式登记给模型；模型在生成时如果发现「我需要先查一下订单」，就输出一段结构化数据——函数名加参数——而不是普通文本。然后轮到你的程序干活：解析这段数据，真的去执行那个函数，把结果塞回上下文，模型接着往下说。
注意这里一个常被误解的事实：模型自己什么都不能执行。它只能「提议」调用。执行权限、参数校验、超时、失败重试，全部在你的代码里。这不是缺陷，恰恰是安全边界所在——把「想做什么」的决定权给模型，把「能不能做」的否决权留在程序里。
大白话：模型是个只能写申请单的员工，盖章执行的永远是你的程序。审批流设计得好，员工再聪明也闯不了大祸。
智能体循环：一个 while 循环而已
把工具调用串起来，就得到了 智能体（agent）。它的核心骨架简单到可以写在黑板上：
- 把任务和可用工具交给模型；
- 模型输出「下一步动作」——要么调用工具，要么给出最终答案；
- 如果是工具调用，程序执行，把结果追加进上下文；
- 回到第 1 步，直到模型给出最终答案或撞上限。
所谓「会自己干活的 AI」，就是这个循环加上一堆工程护栏。神奇感消失了，但工程问题浮出来了：这个循环会放大错误。单次调用准确率 95% 的模型，连走十步，全对的概率只剩约六成。步数越多，复利式衰减越狠。这就是为什么「演示里惊艳、上线就翻车」是智能体的常态——演示是三步，生产是三十步。
护栏设计：架构师在智能体上的真正工作
既然错误会复利累积，工程重心就不是「让每一步更聪明」，而是「让错误可被拦截」。几条久经考验的做法：
- 限制步数和预算：硬性上限（比如最多十五步、最多花掉多少 token），撞限就停下来交给人。没有上限的循环是定时炸弹。
- 工具分级：只读工具（查询、搜索）放开用；写操作分两级——可逆的（存草稿）自动执行，不可逆的（发钱、发邮件给外部）必须人工确认。
- 验证步骤：关键动作后加一个「检查结果的合理性」的步骤，由模型或规则校验。比如转账后核对余额变化。
- 全程留痕：每一步的输入输出落日志。智能体出错时，没有轨迹就等于没有现场。
什么时候不该用智能体
这是本章最重要的判断：能用固定流程写死的，不要用智能体。如果任务的步骤是确定的（先查订单、再算金额、再退款），写成普通代码，让模型只在真正需要判断的环节出场。智能体的自由度是成本、延迟、不可靠性的总和，只该花在「步骤事先无法穷举」的任务上。架构师的功力，体现在把 80% 的流程写死、把 20% 的判断留给模型。
到这里，系统会看、会说、会做了。下一个问题随之而来：你怎么知道它做得好不好？改了一行提示词，是进步了还是退步了？没有评估，前面所有的工程都是盲修。下一章，评估。