今天讲的主题是：Skill 为什么不是一个 Python 函数？
前段时间，我在整理整个 Agent Runtime 的架构时，突然意识到一个问题。
我们每天都在说 Skill。
但是，大家对于 Skill 的理解，好像并不是同一个东西。
有人认为：
Skill 就是 Tool。
有人认为：
Skill 就是 Function Calling。
还有人认为：
Skill 就是 MCP。
如果只是体验 ChatGPT，这些理解都没有太大问题。
但当我真正开始做企业级 Agent 平台的时候，我发现，这些理解都太"轻"了。
因为一个真正上线运行的 Skill，远远不是一个 Python 函数那么简单。
我们为什么会认为 Skill 就是一个 Function？
我想，大多数人第一次接触 Skill，大概都是这样的例子。
defweather(city):return query_weather(city)
LLM 输出：
{"tool":"weather","arguments":{"city":"Shanghai"}}
然后程序执行：
LLM → Tool Calling → weather() → Result
整个过程非常自然。
所以很多人都会觉得：
Skill，不就是一个函数吗？
其实，对于天气查询这种场景来说，这个理解没有问题。
因为它确实只是一个 HTTP 请求。
但是，如果我们把 Skill 换成另外几个场景呢？
例如：
这时候，一个 Python Function 就开始解释不了了。
我第一次意识到 Skill 没有那么简单
真正让我开始重新思考 Skill 的，是 OCR。
假设现在有一个 OCR Skill。
很多人的第一反应，大概是：
defocr(image): ...
但是，真正上线以后，它实际运行的过程更像这样。
Agent │ ▼Python Runtime │ ▼Torch → PaddleOCR → OpenCV │ ▼GPU / CPU │ ▼Result
真正执行 OCR 的，并不是那个 ocr() 函数。
而是整个 Python Runtime。
里面已经加载了：
Torch + PaddleOCR + OpenCV + 模型文件 + GPU 环境。
那个函数，只是 Runtime 的一个入口。
后来我发现，不只是 OCR。
几乎所有复杂 Skill 都是这样。
Function 只是入口，Runtime 才是真正干活的人
后来，我越来越喜欢用一个很形象的比喻。
如果把 Agent 看成一家公司的 CEO。
那么：
Function 更像是一张工单。
真正完成工作的，是后面的整个团队。
例如：
天气查询。
Function → HTTP Client → Weather API
OCR。
Function → Python Runtime → Torch → OCR Model
浏览器自动化。
Function → Browser Runtime → Chromium → DOM
Claude Code。
Function → Sandbox → Ubuntu → Git → Python → Build
Workflow。
Function → Workflow Runtime → Queue → Database → MQ
所以我现在越来越觉得。
Function 决定了"调用什么"。
Runtime 才真正决定了"如何执行"。
这也是我开始重新理解 Skill 的起点。
我理解的 Skill，更像一个可执行应用
后来，我尝试重新定义 Skill。
以前我觉得：
Skill = Function
现在，我更愿意理解成：
Skill = Context + Runtime + Resource + Logic
或者画成下面这样。
Skill├── Metadata├── Input Schema├── Runtime├── Resource├── Execution Logic├── Skill Context└── Output
这里最重要的，其实不是 Logic。
而是 Runtime。
举个例子。
天气 Skill。
OCR Skill。
浏览器 Skill。
虽然它们都叫 Skill。
但运行方式已经完全不同。
为什么不同 Skill，需要不同 Runtime？
这是我后来思考最多的问题。
答案其实很简单。
因为它们依赖的资源完全不同。
例如：
HTTP Skill。
真正需要的是：
HTTP Client + Connection Pool
Python Skill。
真正需要的是：
Python + Pip + 第三方库 + Workspace
Browser Skill。
真正需要的是：
Chromium + Browser Context + Cookie + DOM
Claude Code。
真正需要的是：
Ubuntu + Git + Docker + Workspace + Sandbox
Workflow Skill。
真正需要的是：
Queue + Database + Scheduler
所以：
Runtime 并不是为了运行 Python。
而是为了提供 Skill 所依赖的一整套执行环境。
我把 Skill 分成六种类型
目前，我更倾向于把企业里的 Skill 分成下面几类。
| | | |
|---|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | Deep Research、Research Agent |
虽然都叫 Skill。
但是：
它们真正运行的位置完全不同。
也正因为如此。
一个统一的 Runtime，是无法支撑所有 Skill 的。
我越来越觉得，Skill 更像一个应用，而不是一个函数
做到这里，我开始重新思考 Skill。
如果一定让我用一句话来描述。
我现在会这样说。
Skill 并不是一个 Python 函数，而是一个拥有独立 Runtime、独立资源、独立生命周期的可执行应用。
Function。
只是入口。
Runtime。
才是真正工作的地方。
这一点，也是我认为很多 Agent Framework 最容易被忽略的地方。
写在最后
如果这篇文章只留下一个观点。
我希望是下面这一句话。
Agent 并不是在调用一个函数，而是在调度一个 Runtime。
从天气查询，到 OCR，再到浏览器自动化、代码生成、Workflow，每一种 Skill 的背后，其实都是不同的执行环境。
理解了这一点，我们才能真正理解：
为什么企业级 Agent 平台需要 Runtime。
为什么 Runtime 需要资源池。
为什么需要 Sandbox。
为什么需要调度器。
这些问题，我会在后面的几篇文章里继续展开。
下一篇，我准备聊一个我认为目前讨论得最少、但也是最重要的话题：
Agent Context 与 Skill Context，到底是什么关系？为什么它们永远不应该是同一个 Context？
