核心小节一：Function Calling 到底是什么——模型只是生成“可执行意图”

先从最简单的例子开始。

假设我们有一个 Python 函数：

def read_file(path: str) -> str:
    with open(path, "r", encoding="utf-8") as file:
        return file.read()

普通模型可能回答：

我建议先读取 app.py。

程序看到这句话，不知道应该做什么。

它还得自己写 NLP 规则解析：

是不是要读文件？
文件名是什么？

非常不稳定。

Tool Calling 的意义，就是让模型把动作意图结构化。

例如：

{
  "name": "read_file",
  "arguments": {
    "path": "app.py"
  }
}

这时程序就很好处理。

可以直接：

tool_name = tool_call["name"]
arguments = tool_call["arguments"]

然后：

read_file(**arguments)

大模型到底做了什么？

它做的事情可以抽象成：

输入：
- 用户任务
- 当前 messages
- 可用 Tool 描述

输出：
- 文本答案
或者
- Tool Call

也就是说，模型在做的是，动作选择。

而不是动作执行。

我们可以把它写成：

例如：

Context：
用户要求检查 app.py

Tools：
- read_file(path)
- list_files()

模型输出：
read_file(path="app.py")

先用纯 Python 模拟一次 Tool Call

下面不用真实模型。

def read_file(path: str) -> str:
    files = {
        "app.py": "print('hello agent')",
        "README.md": "Agent Harness Demo",
    }

    return files.get(
        path,
        "FILE_NOT_FOUND",
    )


def fake_llm() -> dict:
    return {
        "name": "read_file",
        "arguments": {
            "path": "app.py"
        }
    }


if __name__ == "__main__":
    tool_call = fake_llm()

    print("模型输出：")
    print(tool_call)

    result = read_file(
        tool_call["arguments"]["path"]
    )

    print("真正执行结果：")
    print(result)

运行以后：

模型输出：
{'name': 'read_file', 'arguments': {'path': 'app.py'}}

真正执行结果：
print('hello agent')

这段代码最值得看的就是中间那条线：

模型输出
  ↓
程序读取
  ↓
Python 函数执行

模型从头到尾没有碰磁盘。

Function Calling 和 Tool Calling 有什么关系？

工程里这两个词经常混用。

早期很多接口更习惯叫：

Function Calling

因为模型主要选择“函数”。

后来 Tool 的概念更宽。

Tool 可能是：

• Python 函数；
• HTTP API；
• SQL 查询器；
• Shell Executor；
• 浏览器；
• MCP Server；
• SubAgent。

所以现在更通用地理解为，Tool Calling = 模型选择外部能力。

而 Python Function 只是 Tool 的一种实现。

为什么 Tool Call 要结构化？

因为自然语言太模糊。

模型说：

帮我读一下 app.py。

程序可能还能猜。

但如果是：

查询 2026-09-01 到 2026-09-03 的媒体收入，
按收入降序，取前 20。

对应参数可能是：

{
  "start_date": "2026-09-01",
  "end_date": "2026-09-03",
  "metric": "revenue",
  "dimension": "media",
  "order": "desc",
  "limit": 20
}

结构化以后：

• 好校验；
• 好记录；
• 好重放；
• 好审批；
• 好统计。

这就是 Tool Call 设计的重要价值。

光靠一句“模型会调工具”还不够，把职责边界画出来会更好理解。下面这张图可以先建立一个最核心的直觉：模型只负责给出结构化调用意图，真正让文件、数据库或者 Shell 发生变化的，是后面的 Harness。

顺着这张图往下看，你会更容易分清 Tool Call 和真实执行到底差在哪里。后面无论是权限、审批还是错误恢复，都是沿着这条执行边界展开的。