Function-Calling on Renxin's Blog

第四话｜模型说调 refund_order，Runtime 怎么不把事情搞砸？

Tue, 14 Apr 2026 00:00:00 +0000

第三话结束时，我们留下一个问题没解决：

tool_calls 永远是候选，不是命令。谁来判断"能不能执行、怎么执行"？

这就是第四话要回答的。模型提出的工具调用，哪怕 JSON 合法、参数齐全，也可能是错的、越权的、有副作用的。Runtime 不能照单全收——它得先校验，再执行，而且要在执行出问题时不把局面搞得更糟。

这里最危险的，不是选错工具，而是一个有副作用、结果又说不清的操作。比如模型要调 refund_order 退款：

handler 执行到一半超时了。钱到底退了没有？直接重试，可能重复退款；不重试，用户又以为没退成。

这一话就沿着这条退款主线，讲清楚 Runtime 怎么把"模型说要调用"变成"安全地执行"——以及最关键的，超时之后怎么根据真实状态做决定，而不是靠猜。

一、模型说"调 refund_order"，Runtime 先干什么？

模型返回的 tool_calls 里，是一段结构化申请单：工具名 refund_order、参数 order_id 和 idempotency_key。但它是模型生成的，是外部输入，不是已经校验过的命令。

Runtime 拿到它，第一件事不是执行，是问三个问题：

这个工具名，是允许执行的吗？
参数齐全、类型对吗？
这个工具现在可用吗？

任何一个不过，就不进 handler，而是返回一个结构化的错误，让上层能稳定地分支处理。

为什么要结构化，不能是一段"调用失败，请稍后再试"的文案？因为文案里没有可编程的信息——程序没法可靠地区分"工具不存在"和"参数缺了"和"执行到一半挂了"。而这三种情况，处理方式完全不同：

错误码	发生了什么	该怎么处理
`UNKNOWN_TOOL`	模型报了个不存在的工具名	拒绝，修正工具选择
`INVALID_ARGUMENT`	参数不满足契约	补参数或拒绝
`TOOL_UNAVAILABLE`	工具已下线或不健康	告知不可用，不能硬调
`EXECUTION_ERROR`	handler 或下游执行失败	按恢复语义决定，见下一节

前三个错误，handler 根本没执行——它们发生在执行之前。第四个才是真正进到了执行阶段，也是最麻烦的。

二、执行时出了问题，最怕的是"结果说不清"

refund_order 通过了校验，handler 真的去调订单服务了——然后超时。

超时意味着什么？意味着"结果不确定"。请求可能压根没到达订单服务，也可能已经到达、退款都成功了，只是响应没传回来。你分不清。

这就是最危险的地方：如果 Runtime 把"超时"直接当成"没执行"，再调一次，就可能退了两笔钱。而如果当成"失败了"，用户这边又显示退款失败，但其实钱已经退了——两边对不上。

所以规则只有一条：超时之后，先查这笔操作的真实状态，不要直接重试。

怎么查？靠 idempotency_key（幂等键）。它是发起退款时就带上的、这笔操作的唯一标识。领域服务按这个键记录"这笔退款到底执行了没有"，Runtime 超时后先去查它，而不是再发起一笔。

flowchart TD
 A[refund_order 超时] --> B[按 idempotency_key 查询真实状态]
 B -->|SUCCEEDED| C[回放成功结果
不再调 handler]
 B -->|NOT_EXECUTED| D[确认没执行
才重试一次]
 B -->|UNKNOWN / 执行中| E[等待或人工核验]

三条分支，对应三种真实状态：

SUCCEEDED：钱已经退了。Runtime 把成功结果回放给用户，不再调 handler。这是最容易犯错的场景——明明已经成功，却因为"没收到响应"而再退一次。
NOT_EXECUTED：确认没执行过。这时重试一次是安全的。
UNKNOWN / 执行中：状态也查不到。这时既不能重试，也不能谎报成功，只能等待对账或转人工核验。

跑一遍主线 demo，你会看到这样一条 Trace：

refund_order response=EXECUTION_ERROR
idempotency_status=SUCCEEDED
runtime_action=REPLAY_SUCCESS
final=SUCCESS
refund_order handler_execution_count=1

最后一行是整条链路的关键证据：handler_execution_count=1。它证明 Runtime 虽然经历了"超时 → 查状态 → 回放"，但真正执行退款的 handler 只跑了一次。没有重复退款。

三、把"谁负责什么"钉死

超时恢复这件事，看着是 Runtime 一个人的活，其实牵涉三个角色，职责不能混：

角色	负责什么	不负责什么
领域服务（`RefundDomain`）	记录和查询"退款到底发生没有"	不负责重试策略，也不知道 Runtime 怎么编排
Runtime	按恢复语义，决定回放、重试还是等待	不拥有退款事实，退款有没有发生得问领域
模型	只提出候选调用	不拥有执行权，更不能拿它的话当退款状态

一句话：有副作用工具的超时恢复，首先是领域状态问题，其次才是 Runtime 的重试策略问题。 退款有没有发生，是领域事实，只能问领域服务；Runtime 能做的是照着这个事实去编排下一步，而不是自己猜。

反过来看，如果领域服务不记录幂等状态，Runtime 再聪明也没用——它没有可以查询的真相，超时之后只能抓瞎。所以幂等这件事，得从工具设计那天就带上，而不是等出了超时才补。

四、把这条链路跑起来

配套 demo 在 code/agent-tutorial/c04-tool-registry/，Python 和 Java 各一份，语义一致。它不调用 LLM、订单或支付系统——所有 handler 都是本地确定性模拟，所以它验证的是 Runtime 的控制流，不是退款系统的可用性证明。

cd code/agent-tutorial/c04-tool-registry/python
python3 registry.py
python3 -m unittest test_registry.py

cd ../java
gradle run

它覆盖六类场景，每一类都对应上面讲的一个环节：

场景	验证什么
工具不存在	`UNKNOWN_TOOL`，不进 handler
工具下线	`TOOL_UNAVAILABLE`，不能硬调
参数缺失	`INVALID_ARGUMENT`，补参或拒绝
正常调用	一次执行，`SUCCEEDED`
超时但已成功	查幂等 → `SUCCEEDED` → 回放，`handler_execution_count=1`
超时且未执行	查幂等 → `NOT_EXECUTED` → 重试一次

其中"超时但已成功"是最值得盯着看的一条：它模拟了 handler 执行成功后、响应却丢失的场景——退款已经发生，SUCCEEDED，但 Runtime 收到的是超时。正确的 Trace 必须是"回放成功结果"，而不是"再退一次"。

五、还差的：执行成功 ≠ 永远可靠

跑通这条链路，Runtime 能安全地执行一次有副作用的调用了。但这离"可靠"还有距离，几件事本篇点到为止，先立个边界：

一次超时不等于工具坏了。订单服务偶发抖动，不能立刻把 refund_order 永久下线；连续失败达到阈值才考虑熔断。
熔断后的探测，不能用一笔新退款去试。要用无副作用的健康检查——否则"检查服务恢复没有"这件事本身，又制造了一笔业务动作。
Runtime 不替代鉴权、审批和审计。工具能不能调，除了契约校验，还涉及"这个用户有没有权限"“要不要二次确认"“留不留审计留底”——这些是 Runtime 与领域服务的责任，本篇没展开。

这些都属于"从单次安全执行到生产级可靠"的延伸，先把边界划在这，不抢后续章节的戏。

到下一话，问题才真正变难

现在，Runtime 已经能把单个候选调用安全地执行，并在超时后不搞砸。

但它还不会根据第一次工具的结果，决定第二步做什么。

第五话才进入真正的 ReAct 循环：第二个 Action 必须依赖第一个 Observation。那时，今天建立的 ToolResponse 和幂等恢复，会成为循环里可复用的执行底座。

第三话｜模型为什么能生成工具调用？

Tue, 31 Mar 2026 00:00:00 +0000

上一话跑通了 Function Calling 协议，但留了个更根本的问题没收尾：

模型凭什么知道该从 tools 菜单里挑 get_weather、又凭什么把“北京”填进 city？

不是提示词写得好。协议只是给了模型一个“填在哪里”的位置，真正让模型知道“填什么”的，是它的训练。这一话就追这件事：模型是怎么学会“提出一次工具调用”的。

先给结论，后面再拆：工具调用不是模型的内置能力，而是训练出来的“输出倾向”。训练改变的是它生成某些 token 序列的概率，不是给它装了一个真的会退款的函数。

一、模型学的，仍然是下一个 token

模型里没有一个叫“退款”的函数。它有的，只是“给定上文，预测下一个词”的能力。所谓“会调工具”，是它学会了：当上下文里出现“退款意图 + 工具定义”时，下一个该输出的，是 refund_order 和 order_id 这几个 token。

训练样本把它要学的样子，直接摆出来：

上下文：订单 O-100 已支付，用户要求退款；可用工具有 refund_order(order_id)
目标：refund_order({"order_id":"O-100"})

反复见这样的样本，模型参数里就长出一套倾向：“退款 + 已支付”这类上下文，会抬高 refund_order 的概率；订单号 O-100，会抬高被填进 order_id 的概率。

注意，训练集还得有反例，否则模型会养成坏习惯：

用户只问配送时间 → 直接回答，不调工具；
订单状态不明 → 先追问，不调工具。

少了这些负样本，模型就会变成“看见什么都想调工具”。

flowchart LR
 A[训练样本
意图、工具定义、目标调用] --> B[模型参数
形成输出倾向]
 C[本次请求
用户消息、当前工具、订单状态] --> D[模型生成候选 tool_calls]
 B --> D
 D --> E[Runtime
校验、确认、执行或拒绝]

关键洞察：模型只是提出了候选调用。它没有因此获得订单事实、权限，也没有执行权。 会“说”要干什么，和“真的干了什么”，是两码事。

二、这条“倾向”，是靠什么训练出来的？

问题来了：这些“上下文 → 正确调用”的样本，是怎么来的？人工一条条标注太贵，学界给了几条公开的路线。

Toolformer 解决的是“数据怎么规模化造出来”。它的做法很有意思——让模型自己当标注员：

在一段普通文本里，让模型猜哪些位置可能需要调 API，采样出一堆候选调用；
真的去执行这些调用，拿到结果；
关键一步：只保留那些“拿到结果后，模型预测后续文字更准了”的调用——具体说，就是比较“有结果”和“没结果”两种情况下，模型对后面 token 的预测损失，损失降得够多才留下；
用过滤后的样本去微调模型。

一句话：模型自己提出调用、自己执行、再自己判断“这次调用到底有没有用”，有用的才拿来当训练样本。 全程不需要人工标注“这里该不该调工具”。Toolformer

Gorilla 解决的是另一个问题：API 会变。哪怕模型学过 get_weather(city)，文档也可能改成 get_weather(location, unit)。Gorilla 的做法是微调 + 文档检索结合：训练给模型调用能力，检索把“当前最新的接口契约”带进上下文，让它跟得上变化。Gorilla

CoT 常被顺带提起，但它其实是个对照，不是工具调用训练：它研究的是“在提示里给推理示例能不能改变输出”。它能改变当前这一轮的输出，但不改模型参数——和 Toolformer/Gorilla 那种真正动参数的训练，是两回事。CoT

三、一件必须分清的事：哪些证据能信，哪些不能

讲到这里，得划一条诚实的边界。关于“模型为什么能调工具”，能拿到的证据分三类，它们不能互相冒充：

证据类型	能说明什么	不能说明什么
论文公开的方法（Toolformer/Gorilla）	“存在这些训练工具调用的公开方法”	不代表某个商业模型就用了它
厂商披露（OpenAI 公告）	0613 模型经过微调、Structured Outputs 靠训练+约束解码	只限定到那几家、那段时间，不能外推
黑盒 API 能观察到的	输入什么、输出什么（比如 description 改了就选错工具）	看不到训练语料、训练阶段、奖励方法

最关键的一条是第三类：你从 API 拿到的结果再稳定，也反推不出厂商到底是怎么训练的。 训练语料长什么样、分几个阶段、有没有用 RLHF——这些是黑盒，除非厂商自己说，否则只能标“未知”。

所以别犯那个错：看到 tool_calls 稳定输出，就说“这个模型用了 Toolformer”。稳定输出能证明“它训练得很好”，证明不了“它是怎么训练的”。

四、Prompt-only 和 Native tools，差的不只是“格式”

上一话讲了 Native tools 的协议形态，这里补一层它和训练/推理的关系。

Prompt-only：在 system prompt 里约定“需要退款时输出 JSON”。模型把 JSON 塞进普通 content 里，Runtime 还得从正文里把命令抠出来——这里混着自然语言、Markdown、可能还有好几个 JSON。

Native tools：在 API 的 tools 字段传 schema，模型用独立的 tool_calls 字段返回。Runtime 直接拿到工具名、参数和调用 id，不用猜哪里是命令。

这个差异不是“格式好看点”，而是责任归属变了：Prompt-only 把“保证输出长得像 JSON”的责任甩给了提示词和你的解析器；Native tools 把这层责任接了过去，一部分靠训练（让模型更会按 schema 输出），一部分靠推理阶段的约束解码（生成时卡住，只允许符合 schema 的 token 出来）。

OpenAI 官方也明确说过：Function Calling 的可靠性，一部分来自模型的微调，一部分来自 Structured Outputs 的 constrained decoding。Structured Outputs

这里有个真实的坑能说明这层差异。我们 Java 版最初只写了“需要时输出 JSON”，没说清 name 和 arguments.order_id 的形状。结果 Native tools 模式仍能返回结构化调用，Prompt-only 模式却解析不出来。把提示词补成明确的 JSON 模板后，Java 的 8 个场景才全过。这不是“Java 不适合做 Agent”，而是Prompt-only 把输出协议的一部分责任，留在了你的提示词和解析器上——而 Native tools 帮你卸掉了一部分。

五、动手看一次：description 才是“选哪个”的开关

我们用一套虚构订单做实验，Python 和 Java 21 各跑一遍。Runtime 先注入已验证的订单状态，模型只做一次工具选择，程序只记录候选调用，绝不执行退款或取消。

四种场景，正确行为是这样：

场景	正确行为
已支付 O-100，要求退款	`refund_order(O-100)`
未支付 O-200，要求取消	`cancel_order(O-200)`
无订单号和状态	追问，不调用
无退款/取消意图	自然语言回答，不调用

基线下两种语言都过。然后做一个故障注入：只把 refund_order 和 cancel_order 的 description 对调，其余全不变——工具名、模型、用户请求、参数 schema 都一样。

结果很干净：已支付退款稳定变成 cancel_order(O-100)，未支付取消稳定变成 refund_order(O-200)，而订单号仍然是对的。恢复 description 后，回归全过。

这个实验说明两件事：

工具选择（选哪个）靠的是 description——模型是读描述来判断“这个工具是干嘛的”，描述写错了，它就选错。
参数提取（填什么）可以和工具选择分开看——订单号还是从用户消息和 Runtime 注入的上下文里来的，两个工具的参数 schema 没变，所以订单号没错。

但这能证明什么、不能证明什么，得说清楚：它证明了“description 影响路由”这个可观察行为，证明不了模型用了哪种训练法。description 写对了，也不代表参数永远填对——Runtime 照样得校验。

六、所以，能信到什么程度

绕了一圈，回到开头那个问题：模型为什么能生成工具调用？

因为它被训练成了这样——训练样本让它形成了“意图 + 工具定义 → 结构化调用”的输出倾向。Toolformer、Gorilla 这些公开方法，展示了这条倾向可以怎么规模化地训练出来；厂商还叠加了微调和约束解码，让输出更稳。

但“会提请求”不等于“可靠”。训练让模型更会“说”要干什么，不会让它“变聪明”——它照样可能选错工具、编造业务参数、请求一个无权执行的动作。tool_calls 永远是候选，不是命令。 谁来判断“能不能执行、怎么执行”，是下一篇的事。

参考资料：

Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools
Patil et al., Gorilla: Large Language Model Connected with Massive APIs
OpenAI, Function calling and other API updates
OpenAI, Introducing Structured Outputs in the API

第二话｜Function Calling：谁把“调用工具”做成了一套协议？

Tue, 17 Mar 2026 00:00:00 +0000

上一话我们搞懂了两件事：模型只会补全文字；想让它干活，得让它把“想干什么”说成某种格式，再由外面的代码去执行。

但上一话那个办法很脆——用提示词逼模型输出 JSON，模型经常给你残缺的 JSON、在前后多写几句废话、或者干脆忘了格式。于是就有了 Function Calling：它把“让模型提出一次工具调用”这件事，从碰运气的提示词技巧，做成了一套规规矩矩的协议。

这一话就讲这套协议：它长什么样，谁先做出来的，以及为什么它能让模型“说清楚要干什么”。

一、协议要解决的，就是上一话那个“脆”

先看上一话的提示词 hack 是怎么翻车的。你在 system prompt 里写“想查天气就输出 {"tool":"get_weather","city":"..."}”，然后：

模型输出的不是纯 JSON，前后还夹着“好的，我帮你查一下”这种话；
JSON 本身残缺，少个引号、少个逗号，json.loads 直接崩；
换了个问法，模型就把格式忘得一干二净。

每次翻车，你都得靠更长的提示词、更严的正则去兜，兜到最后还是不可靠。

协议的意义就在这里：别再用文字去“暗示”模型输出格式，而是给一个结构化的位置，让模型把调用填进去。 这个位置是 API 里明确规定好的，模型要么填对，要么 API 直接拒绝，没有“碰运气”的中间地带。

二、协议长什么样：`tools` 进，`tool_calls` 出

整个协议，一进一出两件事：

请求里传 tools：你告诉模型“现在有哪些工具可以用”。这是一份菜单，写清楚每个工具叫什么、干什么、参数长什么样。
响应里收 tool_calls：模型告诉你“我想调哪个工具、带什么参数”。这是一张申请单。

下面是一份声明了本地天气工具的菜单：

TOOLS = [
 {
 "type": "function",
 "function": {
 "name": "get_weather",
 "description": "查询指定城市的天气演示数据",
 "parameters": {
 "type": "object",
 "properties": {
 "city": {"type": "string", "description": "城市名，如北京"}
 },
 "required": ["city"],
 "additionalProperties": False,
 },
 },
 }
]

注意，tools 不是把 Python 函数“上传”给模型。它只是一份描述：函数叫 get_weather、查天气的、需要一个 city 字符串参数。模型拿到的是这些文字，不是那个函数本身。Chat Completions API

把菜单连同问题一起发过去：

assistant_message = client.chat.completions.create(
 model=MODEL,
 messages=[{"role": "user", "content": "请查询北京现在的天气。"}],
 tools=TOOLS,
 tool_choice="required",
).choices[0].message

响应里我们关心的不是自然语言，而是这张申请单：

{
 "id": "call_00_...",
 "type": "function",
 "function": {
 "name": "get_weather",
 "arguments": "{\"city\": \"北京\"}"
 }
}

拆开看每个字段：

id：这条调用的唯一标识，回传结果时要靠它关联；
type：固定是 function，标记这是一次函数调用；
function.name：想调哪个工具；
function.arguments：一个 JSON 字符串——注意它还是字符串，不是对象，代码里得再 json.loads 一层才能用。

它表达的就是一句话：“请调用 get_weather，参数是北京。”到这里，模型既没有运行 Python，也没有拿到天气数据。它只是把“想干什么”用协议规定的格式写清楚了。

三、这套协议，是谁先做出来的

它不是我编的，也不是模型厂商某天灵机一动。时间线很清晰：

2022 年，ReAct（Yao et al., arXiv 2210.03629）提出“推理 + 行动”交替，用提示词让模型按 Thought / Action 的格式输出，再让代码去执行；
2023 年 2 月，Toolformer（Meta AI, arXiv 2302.04761）证明“模型自己决定何时调 API”这个能力是能被训练出来的；
2023 年 5 月，Gorilla（UC Berkeley, arXiv 2305.15334）开始微调模型学写 API 调用。

这几篇走的都是“提示词 + 解析”的路线——也就是上一话讲的那个脆办法。

真正的转折在 2023 年 6 月 13 日：OpenAI 首次发布原生 Function Calling，随 gpt-4-0613 和 gpt-3.5-turbo-0613 两个模型快照一起推出。从这一天起，“让模型提工具调用”不再靠提示词暗示，而是变成了 API 里的标准字段——就是我们第二节看到的 tools 进、tool_calls 出。

四、别看就一个 `tool_calls`，背后做了很多工作

有个问题自然冒出来：同样是“让模型输出调用”，为什么提示词 hack 天天翻车，而协议一出来，模型就能稳定地输出合法参数、不再给你残缺 JSON？

不是因为提示词写得好了。是厂商在背后做了工作——模型是被训练成“会正确提出调用”的，这个能力不是运气，是训练出来的。

这里只说结论，不展开原理（那是下一话的事）：

微调：训练阶段喂了大量“工具调用对话”样本，让模型学会判断要不要调、选哪个工具、生成合法参数；
约束解码：生成的时候，在输出层卡住模型，让它只能吐出符合 schema 的内容，从根上杜绝“残缺 JSON”。

这两件事把“正确提出调用”从提示词的玄学，变成了模型本身的能力。至于模型内部到底是怎么学会的、这两件事的具体机制——那是第三话要专门讲的问题，这里先按下不表。

五、协议只负责“提出”，不负责“执行”

回到那张申请单。tool_calls 拿回来，协议的部分就结束了。接下来是你的代码接手：

def execute_tool(name: str, arguments_json: str) -> str:
 if name != "get_weather":
 raise ValueError(f"不允许执行未知工具：{name}")

 arguments = json.loads(arguments_json)
 if not isinstance(arguments, dict) or set(arguments) != {"city"}:
 raise ValueError("get_weather 参数必须且只能包含 city")

 city = arguments["city"]
 if not isinstance(city, str) or not city.strip():
 raise ValueError("city 必须是非空字符串")

 return get_weather(city.strip())

模型输出在这里被当成外部输入处理：先校验工具名，再校验参数，然后才真正执行。25℃ 来自 get_weather() 的返回值，不是模型编的：

def get_weather(city: str) -> str:
 weather = {
 "北京": "多云，25℃，东北风3级",
 "上海": "小雨，22℃，东南风2级",
 }
 return weather.get(city, f"暂无{city}的天气演示数据")

协议让模型“说清楚要干什么”，执行永远在模型外面——这是上一话那条结论的延续，在这里变成了可运行的代码。

六、把结果交回去，也是协议的一部分

函数执行完，Python 手里有了天气文本，但用户还没看到一句话。模型上一次只停在“我想调什么工具”，所以要把两样东西放回消息历史：

messages.append(assistant_message) # 模型提出的调用请求
messages.append(
 {
 "role": "tool", # 工具执行结果
 "tool_call_id": tool_call.id, # 关联到上面那条 tool_calls
 "content": result,
 }
)

role=tool 这一步不是可选的，是协议强制要求的。这里有个真实的坑：有人把 role=tool 写成了 role=user，API 直接报 HTTP 400——

An assistant message with 'tool_calls' must be followed by
tool messages responding to each 'tool_call_id'.

意思很直白：你给模型看了一张 tool_calls 申请单，就必须逐条配上一份对应的 tool 结果，用 tool_call_id 对上号。少一条、错一条，协议层面就拒绝，根本轮不到模型来猜。这个报错本身，就是“协议不是约定俗成、而是硬约束”的最好证据。

补上结果后再问一次模型，它才能把“多云，25℃”组织成一句人话。事实来自函数，句子由模型生成，两边分得清清楚楚。

七、回到最开始的问题：到底谁调用了工具？

角色	输入	输出	不负责什么
模型	用户问题与 `tools` 菜单	`tool_calls` 申请单	不执行本地函数
你的代码	工具名、参数与本地能力	校验后的工具结果	不应把模型请求原样放行
模型	`role=tool` 结果	面向用户的回答	不产生工具返回的外部事实

Function Calling 没有把函数“装进模型”。它做的，是把上一话那个脆弱的提示词 hack，变成了一套 tools 进、tool_calls 出的标准协议——模型提请求，你的代码执行，模型再说话。

跑通一次，你会看到这三步按顺序发生：

模型请求：get_weather({"city":"北京"})
程序执行：多云，25℃，东北风3级
模型回答：北京现在多云，气温 25℃，东北风 3 级。

配套 Python 与 Java 实现在 GYA 仓库与 GYA-Java 仓库的 c02-function-calling 目录，按 README 的命令跑，不复制这篇文章里零散的代码块。

协议跑通了，但一个更根本的问题还悬着：模型凭什么知道，该从菜单里挑 get_weather、该填北京？ 这已经不是协议能回答的了——得回到模型训练本身。下一话。

参考资料：

DeepSeek, Tool Calls
DeepSeek, Chat Completions API
Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models
Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools
Patil et al., Gorilla: Large Language Model Connected with Massive APIs

第一话｜大模型只会补全文字，Agent 的“手脚”是怎么来的？

Tue, 03 Mar 2026 00:00:00 +0000

几年前，我还在用 ChatGPT 查技术资料、翻译文档、写文案前先理个大纲。那时候它是“聊天窗口”：我打字，它回文字，聊完就关掉。

后来出现的 Agent 工具，真的能帮我干活了——写代码、执行命令行、调用 API 查数据。

从“聊”到“干”，这几年发生了什么？

要回答这个问题，得先看清一件被很多人忽略的事：大模型从头到尾，只会做一件事。

模型只会补全文字

不管外面把它包装成聊天助手还是 Agent，模型干的事情始终只有一件：给你一段上文，它预测下一个最可能出现的词，然后把这个词接上去，再预测下一个，一直循环，直到吐出一段完整的文字。

这个过程有个名字，叫“自回归生成”。它的输入是文字，输出还是文字。

所以模型天生有几个边界，跟它聪不聪明没关系，是它的结构决定的：

它没有手，不会真的去点一个按钮、执行一行代码；
它没有网络，不会自己发一个 HTTP 请求去查天气；
它没有文件系统，不会自己创建一个文件、改一行代码。

它唯一能做的，是根据上文，猜下一段文字该怎么写。

理解了这一点，再回头看那个问题就清楚了一半：一个只会补全文字的模型，是怎么“干起活”来的？

让它“说”出要干什么

答案藏在一个很朴素的技巧里。

模型只会写字，那我们就让它把“想干什么”用固定格式写出来。

比如，我们在提示词里跟模型约定：

如果你想查天气，就严格输出下面这个格式，别的什么都别写：

{"action": "get_weather", "city": "北京"}

然后用户问“北京今天天气怎么样”。模型还是只会补全文字，只不过这一次，它补全出来的不是一段聊天，而是一行长得很像代码的 JSON：

{"action": "get_weather", "city": "北京"}

到这里，模型仍然什么都没做。它只是“说出”了：我想调 get_weather，参数是北京。

真正动手的是模型外面的程序。它拿到这行 JSON，解析出 action 是 get_weather、city 是北京，然后自己去调用真正的查天气函数：

import json, re

# 模型输出的那行文字
model_output = '{"action": "get_weather", "city": "北京"}'

# 程序解析它
data = json.loads(model_output)
if data["action"] == "get_weather":
 result = get_weather(data["city"]) # 真正查天气的是这行代码

拿到天气结果后，程序再把这个结果塞回给模型，模型补全成一句人话：“北京今天多云，25 度”。

看明白了吗？整条链路里，模型从头到尾没执行过任何东西。它只是把“想干什么”用固定格式说了出来，动手的是外面那段解析加执行的代码。

看起来模型“长出了手脚”，其实是外面套了一双手。

这套做法，其实是 Function Calling 的前身

上面那套“提示词逼出格式、代码解析执行”的做法，不是谁凭空想出来的玩具。在原生 Function Calling 出现之前，它是开发者让模型调用工具的标准办法——先用提示词约定好输出格式，再用正则表达式或者 JSON 解析器去抠出工具名和参数。

它好用，但也很脆。模型会输出残缺的 JSON、在 JSON 外面多写一句“好的，我帮你查”、或者干脆忘掉约定格式。这些问题，逼着人们后来把这件事从“提示词技巧”升级成了“协议”——也就是第二话要讲的 Function Calling。

但不管怎么升级，底层逻辑从没变过：

模型只负责用固定的格式，把“要干什么”说清楚；真正的执行，永远发生在模型外面。

想通这一点，整个 Agent 世界就有一把钥匙了。你之后会看到的所有花活——多步循环、记忆、MCP、Skill——都在做同一件事的不同部分：让模型把意图说清楚，让外面那套代码把事做成，再把结果喂回去。

而外面这套代码，我们给它起了个名字，叫 Runtime。它才是 Agent 真正“长”出来的那只手。

下一篇，我们就从这套做法的标准化形态开始：模型怎么用一套协议，规规矩矩地提出一次工具调用——Function Calling。

参考资料：

OpenAI, Function Calling
Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models

Function-Calling on Renxin's Blog

第四话｜模型说调 refund_order，Runtime 怎么不把事情搞砸？

一、模型说"调 refund_order"，Runtime 先干什么？

二、执行时出了问题，最怕的是"结果说不清"

三、把"谁负责什么"钉死

四、把这条链路跑起来

五、还差的：执行成功 ≠ 永远可靠

到下一话，问题才真正变难

第三话｜模型为什么能生成工具调用？

一、模型学的，仍然是下一个 token

二、这条“倾向”，是靠什么训练出来的？

三、一件必须分清的事：哪些证据能信，哪些不能

四、Prompt-only 和 Native tools，差的不只是“格式”

五、动手看一次：description 才是“选哪个”的开关

六、所以，能信到什么程度

第二话｜Function Calling：谁把“调用工具”做成了一套协议？

一、协议要解决的，就是上一话那个“脆”

二、协议长什么样：tools 进，tool_calls 出

三、这套协议，是谁先做出来的

四、别看就一个 tool_calls，背后做了很多工作

五、协议只负责“提出”，不负责“执行”

六、把结果交回去，也是协议的一部分

七、回到最开始的问题：到底谁调用了工具？

第一话｜大模型只会补全文字，Agent 的“手脚”是怎么来的？

模型只会补全文字

让它“说”出要干什么

这套做法，其实是 Function Calling 的前身

二、协议长什么样：`tools` 进，`tool_calls` 出

四、别看就一个 `tool_calls`，背后做了很多工作