以前我一直以为：

Tool 就是 Function Calling 里的函数，或者 MCP Server 里面暴露出来的函数。

后来在用 Codex 时，我发现它还会调用：

bash
read
write
grep
浏览器
GitHub
MCP Tool

这时候我才意识到：

Tool 不只是“业务函数”，而是 Agent 可以调用的一项具体能力。

这篇文章就用最小白的方式把 Tool 讲明白。

---

先记一句：

Tool = 给 AI Agent 使用的一项“可调用能力”。

例如：

查订单
读文件
写文件
执行命令
搜索代码
调用浏览器
访问 GitHub
查询 OA

这些都可以被做成 Tool。

所以 Tool 的范围其实比“函数”更大。

---

因为我们最常见的例子是 Function Calling。

例如：

def query_order(order_no: str):
    ...

把它注册给模型后，模型就可以调用：

query_order(order_no)

用户问：

帮我查一下订单 10086。

模型可能选择：

query_order(
    order_no="10086"
)

后台执行这个函数，再把结果交回模型。

所以这个例子里：

query_order
=
Tool

因此很容易形成：

Tool = Python 函数

这个理解不算错，但不够完整。

---

假设 Codex 想执行：

python check_excel.py

真正的 Tool 不是：

python check_excel.py

而是：

bash(command)

Codex 实际上相当于调用：

bash(
    command="python check_excel.py"
)

所以：

bash
=
Tool

python check_excel.py
=
传给 Tool 的参数

这和：

query_order(order_no)

其实是一个思路。

对模型来说，它们都是：

“我可以调用的一个能力入口”。

---

例如 Codex 要读取文件：

read(path)

要写文件：

write(path, content)

要搜索代码：

grep(pattern, path)

从模型角度看，它们也都像函数：

read("/project/app.py")

write("/project/result.md", "...")

grep("login", "/project")

所以：

Tool 最常见的表现形式确实很像“函数名 + 参数”。

但 Tool 背后真正做什么，不一定只是执行一个普通 Python 函数。

---

例如：

Tool：query_order(order_no)

底层可能是：

Python 函数
↓
HTTP API
↓
订单系统

而：

Tool：bash(command)

底层可能是：

Harness / Runtime
↓
Shell
↓
操作系统

再比如：

Tool：read(path)

底层就是文件读取能力。

所以：

Tool 是上层概念，底层可以用函数、API、Shell、文件系统、浏览器等很多方式实现。

---

MCP 可以理解成：

把 Tool 按统一标准提供给 Agent 的协议。

例如 OA 的 MCP Server 提供：

query_todo
query_approval
create_ticket

Codex 连接后，就可以把这些当 Tool 使用。

所以：

MCP
=
提供和连接 Tool 的标准协议

MCP Tool
=
通过 MCP 暴露出来的具体能力

MCP 不是 Tool 本身。

---

可以简单理解：

Tool
=
能力

Function Calling
=
模型表达“我要调用这个能力”的一种方式

例如：

Tool：
query_order(order_no)

模型通过 Function Calling 表达：

我要调用 query_order
参数是 10086

所以 Tool 是“能力”，Function Calling 更像“调用机制”。

---

不一定。

例如 Skill 里有：

scripts/check_excel.py

这个文件本身只是：

Python 脚本

Codex 可能通过：

bash(
    command="python scripts/check_excel.py"
)

来执行它。

这里：

bash
=
Tool

check_excel.py
=
被 Tool 执行的脚本

只有当 check_excel 被专门注册、暴露成：

check_excel(file_path)

让模型可以直接选择调用时，它才真正成为一个 Tool。

---

模型本身不会真正执行 Tool。

模型只负责决定：

调用哪个 Tool
+
传什么参数

真正执行 Tool 的，是：

Agent Runtime / Harness

完整流程：

用户提出问题
↓
模型判断需要 Tool
↓
模型选择 Tool + 参数
↓
Harness / Runtime 执行 Tool
↓
返回执行结果
↓
模型继续判断
↓
最终回答

所以：

LLM
=
大脑

Tool
=
可以使用的具体能力

Harness
=
真正负责执行和调度 Tool 的运行底座

---

10. 用 Codex 举个完整例子

用户说：

帮我检查这个 Excel 文件，然后生成一份结果。

Codex 可能这样工作：

1. 调用 read Tool
   ↓
   读取文件

2. 调用 bash Tool
   ↓
   执行 Python 检查脚本

3. 调用 write Tool
   ↓
   保存分析结果

4. 再检查结果

5. 最终回复用户

所以 Codex 做任务时，并不是只靠大模型“想”。

而是：

LLM
+
Tool
+
Harness

一起工作。

---

最后总结

最终我把 Tool 理解成：

Tool = Agent 可以调用的一项具体能力。

它可能是：

业务函数
HTTP API
Shell
文件读取
文件写入
浏览器
GitHub
MCP Tool
数据库查询

但从模型角度看，通常都会被包装成类似：

工具名称(参数)

的形式。

所以最关键的一句话是：

Tool 不只是 Function Calling 里的业务函数，也不只是 MCP 里的函数；只要是 Agent 能够选择并调用的一项具体能力，都可以叫 Tool。

再压缩成一句：

Tool
=
AI Agent 的“手”

模型负责决定“用哪只手”，Harness 负责真正把这只手动起来。