我终于搞懂了 Codex 的 Tool：原来它不只是 Function Calling 里的“函数”

以前我一直以为：

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

后来真正使用 Codex 才发现，它还会读文件、写文件、执行命令、跑测试、查 GitHub、搜文档、调用浏览器。

这时候我才真正理解：

Tool（工具）就是 Codex 真正能够“动手做事”的一项具体能力。

如果把大模型比作“大脑”，那么：

LLM
= 负责想、判断、决定下一步

Tool
= 真正动手的“手脚”

Harness / Runtime
= 负责把这些 Tool 调度和执行起来的运行底座

---

1. Tool 到底是什么？

例如我对 Codex 说：

帮我看看这个项目里哪里调用了 login 方法。

Codex不能只靠“想”完成，它需要真正搜索代码，于是可能会调用：

grep(pattern, path)

再比如我说：

帮我运行一下测试。

Codex需要执行：

npm test

它可能调用：

bash(command="npm test")

这里：

bash
= Tool

npm test
= 传给 Tool 的参数

所以 Tool 可以理解为：

模型能够选择并调用的一个“能力入口”。

---

2. 为什么以前会觉得 Tool 就是函数？

因为 Function Calling 最常见的例子就是：

def query_order(order_no: str):
    ...

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

query_order(order_no="10086")

所以这个例子里：

query_order
= Tool

很容易形成：

Tool = Python函数

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

更准确地说：

Tool 常常会以“名字 + 参数”的形式暴露给模型，但它背后不一定只是一个普通 Python 函数。

---

3. Codex 里的 Tool 来自哪里？

我现在把它分成三类理解。

第一类：Codex 自带的 Tool

例如可以理解成：

read
write
edit
grep
shell / bash

它们让 Codex 可以：

读文件
写文件
修改文件
搜索代码
执行命令
运行测试

例如：

bash(command="python check.py")

这里真正的 Tool 是：

bash

而：

python check.py

只是 bash Tool 要执行的一条命令。

---

第二类：MCP Server 提供的 Tool

假设公司有一个 OA MCP Server，它可能提供：

query_todo
query_approval
create_ticket

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

所以：

MCP
≠ Tool

MCP Tool
= 通过 MCP 暴露给 Codex 的具体能力

可以理解成：

Codex
↓
MCP
↓
MCP Server
↓
发现 Tool
↓
query_todo
query_approval
create_ticket

---

第三类：App / Plugin 带进来的外部能力

Codex 现在还可以通过 App、Plugin 接入外部系统，例如：

GitHub
Google Drive
Slack
Sites

这些能力最终也可能给 Codex 提供可以查询数据或执行动作的 Tool。

因此可以先这样记：

Plugin
= 能力包

App
= 外部系统入口

MCP
= 标准连接协议

Tool
= Codex最终真正可以调用的具体动作

---

4. Tool 在 Codex 工作流程里的位置

Codex完成任务，本质上是一个循环：

你下任务
↓
模型判断下一步做什么
↓
调用 Tool
↓
Tool 返回结果
↓
模型继续判断
↓
可能再次调用 Tool
↓
……
↓
完成任务

例如：

你：
“帮我找出测试失败原因并修复。”

Codex可能这样工作：

1. 读取项目文件
   ↓
   read Tool

2. 执行测试
   ↓
   shell / bash Tool

3. 查看错误日志
   ↓
   read / grep Tool

4. 修改代码
   ↓
   edit Tool

5. 再跑一遍测试
   ↓
   shell / bash Tool

6. 测试通过
   ↓
   最终回复

这就是典型的 Agent Loop：

模型决策
↓
Tool
↓
结果
↓
模型继续决策

---

5. Skill 和 Tool 到底有什么区别？

一句话：

Tool 是“能做什么”，Skill 是“应该怎么做”。

例如 Codex手里有：

read Tool
write Tool
bash Tool
浏览器 Tool

这些只代表它有这些能力。

但“前端测试应该按什么步骤做”，可以由 Skill 告诉它：

Frontend Testing Skill

1. 先启动项目
2. 打开页面
3. 查看 Console
4. 查看 Network
5. 修改问题
6. 再次测试

关系就是：

Skill
↓
告诉 Codex工作步骤
↓
Codex按照步骤选择不同 Tool
↓
Tool真正执行动作

所以：

Skill
= 工作方法 / SOP

Tool
= 真正执行动作的能力

---

6. Skill 里的 Python 脚本是不是 Tool？

不一定。

例如：

excel-skill/
├── SKILL.md
└── scripts/
    └── check_excel.py

这里：

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。

---

7. Function Calling 和 Tool 是什么关系？

可以这样理解：

Tool
= 能力

Function Calling
= 模型调用某类 Tool 的一种机制

例如：

Tool：
query_order(order_no)

模型通过 Function Calling 表达：

我要调用 query_order
参数是 10086

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

---

8. Plugin、App、Skill、MCP、Tool 一次串起来

可以用这张关系图理解：

                 Codex
                   │
                   ↓
             LLM 做决策
                   │
          ┌────────┴────────┐
          │                 │
        Skill              Tool
      告诉怎么做         真正执行动作
                            │
               ┌────────────┼────────────┐
               ↓            ↓            ↓
          Codex内置Tool    MCP Tool    App带来的能力
               │            │            │
            文件/Shell    MCP Server    GitHub等外部系统

Plugin 更像最外面的“能力包”：

Plugin
│
├── Skill
├── App
└── 其他工作流能力

所以：

概念	最简单的理解	和 Tool 的关系
Tool	一项真正可执行的能力	自己就是执行动作的一环
Skill	工作方法 / SOP	指导 Codex 怎么组合和使用 Tool
MCP	外部能力连接协议	MCP Server 可以向 Codex 提供 Tool
App	外部系统入口	可以给 Codex 带来数据和动作能力
Plugin	能力包	可以把 Skill、App 等能力打包起来

---

9. 一个完整例子：修改页面并验证

我对 Codex 说：

优化首页，并验证移动端布局。

如果 Codex有一个前端 Skill，又接入了浏览器相关能力，它可能这样工作：

前端 Skill：
先检查页面
↓
再修改代码
↓
最后浏览器验证

真正执行时：

读取代码
↓
read Tool

修改代码
↓
edit Tool

启动项目
↓
bash / shell Tool

打开页面
↓
浏览器 Tool

截图检查
↓
截图相关 Tool

所以：

Skill 是“工作剧本”，Tool 是“真正去做动作”。

---

10. Tool 是谁真正执行的？

还有一个很重要的问题：

大模型自己会执行 Tool 吗？

不会。

模型主要负责：

判断
选择 Tool
生成参数
分析 Tool 返回结果

真正负责执行的是 Agent 的：

Harness / Runtime

可以理解成：

用户
↓
LLM：我要调用 bash
↓
Harness 接收到 Tool Call
↓
真正执行命令
↓
把执行结果返回给 LLM
↓
LLM继续判断

所以：

LLM
= 大脑

Tool
= 手脚

Harness / Runtime
= 负责调度和执行这些手脚的运行底座

---

11. 我平时需要自己指定 Tool 吗？

大部分情况下不需要。

正常使用 Codex：

你只需要说清楚要干什么
↓
Codex自己判断需要哪些 Tool
↓
自动调用

例如：

帮我检查这个项目为什么启动失败，并修复。

Codex会自己决定：

读什么文件
搜什么代码
跑什么命令
改什么代码
什么时候重新测试

只有在一些特殊情况下，才需要明确告诉它：

使用 GitHub 查询
使用某个 MCP
先跑测试再修改
不要执行写操作

---

12. Tool 不是越多越好

Tool 越多，Agent能做的事情确实越多。

但也不是：

Tool越多
=
一定越好

因为 Tool 太多可能带来：

选择成本增加
权限范围扩大
危险写操作增加
工具描述变复杂

所以大型 Agent 系统通常会做：

Tool Search
Tool Router
权限控制
工具白名单

核心目的就是：

让模型在真正需要的时候，只看到、只使用合适的 Tool。

---

最后总结

以前我以为：

Tool
=
Function Calling 里的函数

现在更准确的理解是：

Tool = Agent 能够选择并调用的一项具体能力。

它可以是：

查业务数据的函数
读文件
写文件
执行 Shell
跑测试
操作浏览器
GitHub能力
MCP Server提供的能力

而：

Skill
= 告诉 Codex怎么组合这些 Tool

MCP
= 把外部 Tool 标准化接给 Codex

App
= 把外部系统的数据和动作接给 Codex

Plugin
= 把 Skill、App 等能力打成一个能力包

最后只记一句：

模型负责“想”，Skill 负责“教它怎么干”，Tool 负责“真正动手”，MCP/App 负责把外部能力接进来，Plugin 负责把这些能力组合和分发。

这时再回头看 Codex，就会发现它不是“一个只会聊天的大模型”，而是：

LLM
+
Harness
+
Tool
+
Skill
+
MCP / App
+
Plugin

组合起来的一套完整 Agent 工作系统。