从自然语言到 Tool Call

人说的是自然语言，程序执行的是结构化指令。

agent 的一个关键能力，就是把这两者接起来。

用户可能会说：

“帮我给 Alice 发一条消息，说我 10 分钟后到。”

但 IM 软件真正能执行的，不是“帮我发一下”这句话。它需要更明确的字段：

{
  "action": "send_message",
  "to": "Alice",
  "text": "我 10 分钟后到"
}

这就是 tool call 的基本形态：把模糊的人类意图，变成机器可以校验、授权、执行和记录的结构化数据。

再比如用户说：

“把客厅灯打开，亮度调到 30%。”

智能家居系统最后需要的，可能是：

{
  "action": "set_device_state",
  "device": "living_room_light",
  "power": "on",
  "brightness": 30
}

这里有几个关键变化。

第一，自然语言变成了明确动作。action 是什么，系统可以识别。

第二，参数变成了可检查字段。brightness 是不是数字，范围对不对，device 是否存在，都可以在执行前验证。

第三，不同动作可以挂不同权限。开灯可以自动执行，转账可能要确认，删除文件可能永远不允许。

第四，执行过程可以审计。事后能看到 agent 到底请求了什么动作，带了什么参数，工具返回了什么结果。

所以 agent 并不是直接“用语言操作世界”。更准确地说，它先根据当前 context 生成一个结构化意图，然后由 runtime 做确定性处理：

- schema 校验

- 权限检查

- approval gate

- dispatch 到具体工具

- timeout、重试或取消

- 记录 trace

- 把结果带回下一轮 context

coding agent 也是这样。

用户说：

“帮我看看为什么测试挂了。”

背后可能会变成一串动作：

read_file("package.json")
run_command("pnpm test")
search("UserService")
read_file("src/user-service.ts")
edit_file(...)
run_command("pnpm test")

这些动作不是聊天内容，而是 runtime 可以执行的操作。模型负责决定下一步可能该做什么，runtime 负责把这一步变成受控执行。

这也说明为什么提示词清楚很重要，但原因不只是“让回答更好”。清楚的任务、约束和背景，会让模型更容易选对工具、填对参数、知道缺什么字段时应该追问或检索，而不是瞎猜。

比如创建日历事件时，如果用户只说“明天下午三点约 Bob 开会”，系统还需要知道 Bob 是哪个邮箱、会议多长、是否有冲突。如果这些信息不在 context 里，好的 agent 不应该随便填一个，而应该查通讯录、读日历，或者问用户。

tool call 的价值就在这里：它把“AI 好像懂了我的意思”推进到“系统能不能安全执行这个动作”。

自然语言适合表达意图，结构化数据适合执行。agent 要可靠，就必须在这两层之间有清楚的翻译和边界。