最近在理解 Codex 的 Skill 时，我遇到一个很容易混淆的问题：

Skill 里面的 .py 脚本，是不是就叫 Tool？

答案是：

不一定。普通 Python 脚本本身通常不叫 Tool。

1. 先看一个 Skill 目录

例如：

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

这里：

SKILL.md

是这项 Skill 的工作说明书。

而：

check_excel.py

只是一个普通 Python 脚本。

它本身不会自动变成 Tool。

2. 那这个 Python 脚本是谁执行的？

假设 SKILL.md 里写着：

处理 Excel 完成后，
运行 scripts/check_excel.py 检查结果。

Codex 可能会这样执行：

Codex 读取 Skill
↓
发现需要运行 check_excel.py
↓
调用 bash Tool
↓
执行：

python scripts/check_excel.py

所以这里真正的 Tool 是：

bash

而不是：

check_excel.py

更准确地说：

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

其中：

bash
= Tool

python scripts/check_excel.py
= 传给 Tool 的命令

check_excel.py
= 被执行的 Python 脚本

可以简单理解成：

Tool = 模型可以直接调用的一个能力入口。

例如：

bash(command)

read(path)

write(path, content)

query_order(order_no)

这些都可以是 Tool。

模型会决定：

调用哪个 Tool
+
传什么参数

真正执行 Tool 的，是 Agent 的 Runtime / Harness。

如果我们把一个 Python 函数专门注册给模型，例如：

def check_excel(file_path: str):
    ...

并把它暴露成：

check_excel(file_path)

让模型可以直接选择并调用它，

那么：

这个 Python 函数就可以成为一个 Tool。

所以：

普通 Python 脚本
≠ 天然就是 Tool

而：

被注册、暴露成模型可调用能力的函数
= 可以成为 Tool

5. 最简单的关系

可以这样记：

Skill
= 工作说明书

Python 脚本
= 配套代码

Tool
= 模型可以调用的能力入口

Harness / Runtime
= 真正负责执行 Tool

完整流程：

用户提出任务
↓
Codex 使用 Skill
↓
Skill 告诉 Codex 要运行某个脚本
↓
Codex 调用 bash Tool
↓
Harness 执行 Python 脚本
↓
脚本返回结果
↓
Codex 继续处理

最后总结

一句话记住：

Skill 里的 Python 脚本只是代码文件，不一定是 Tool；只有当某个函数或能力被注册并暴露给模型直接调用时，它才算 Tool。

再压缩一点：

.py 脚本
= 被执行的代码

Tool
= 执行能力的入口