先记住一句话： Tool 解决“能做什么”，Memory 解决“过去知道什么”，而 Skill 解决的是——这类事情，我已经知道一套成熟做法了吗？

这一课不追求让模型“想得更多”，而是反过来追问：哪些问题已经被过去的经验解决过，下一次不该再从零推理？

如果一个工程师连续三天遇到同一个问题。

第一天，他踩坑，排查两个小时，最后解决。

第二天，他又踩一遍同样的坑，再排查两个小时，又解决。

第三天，还是如此。

你会说这个工程师“解决问题能力很强”吗？

也许。

但你大概率不会说：

他已经学会了。

因为真正的“学会”，不是每次都能重新推理出答案。

而是下一次再遇到类似问题时，不需要重新从零开始。

这正是 Agent 做到第十课以后，会碰到的下一个大问题。

第十课我们已经让 Agent 有了 Verification 和 Reflection：

Action

↓

Environment

↓

Evidence

↓

Verification

↓

Reflection

↓

Retry / Replan

它做错以后，不再只是拍脑袋说“已完成”，而是允许现实纠正自己。第十课里我们甚至已经把 Reflection 和 Learning 分开：Reflection 解决的是“这一次为什么错、下一步怎么改”；Learning 则要进一步考虑“这次经验里，有没有什么值得以后继续使用”。

但这里藏着一个很大的问题。

Reflection 只保证这一次变聪明。

任务结束，Context 消失。

下次来了一个类似任务，LLM 很可能又从头想。

于是一个非常反直觉的情况出现了：

Agent 明明昨天已经成功解决过，今天却仍然像第一次见到一样。

这就是第十一课。

这一课我们不讨论“怎么让模型想得更多”。

恰恰相反。

我们要讨论的是：

哪些事情，模型已经不应该再重新想了？

这就是 Skill。

---

先别急着定义 Skill，先看一个采购报价的坑

假设你做了一个采购分析 Agent。

用户给它 20 份供应商报价，让它：

找出价格异常，并给采购建议。

Agent 第一次做的时候，很自然地读取报价表。

它看到：

Supplier A    5.20
Supplier B    5.45
Supplier C    38.00

于是马上判断：

Supplier C 明显异常。

听起来很合理。

结果仔细一看：

Supplier A    USD / meter
Supplier B    USD / meter
Supplier C    RMB / yard

直接比较毫无意义。

于是 Verification Fail。

Agent Reflection：

我错误地假设所有报价使用相同币种和单位。比较供应商报价之前，应该先统一 Currency 和 UOM。

很好。

重新计算。

又发现另外一个问题：

Supplier A    FOB
Supplier B    CIF

价格仍然不能直接比。

第二轮 Reflection：

除了 Currency 和 UOM，还必须考虑 Incoterm。

再跑一次。

这次终于成功。

到这里，第十课已经完成使命。

Agent 被现实教育了两次，最后做对。

可现在我问一个问题：

明天再来另外 20 份供应商报价，它还应该从“直接比较价格”开始吗？

如果答案是“应该”，那么这个 Agent 其实没有真正学会任何东西。

它只是拥有：

失败之后重新思考的能力。

而我们真正希望它拥有的是：

以前已经证明有效的方法，可以直接带到下一次。

于是这一次任务里得到的经验：

报价比较之前：

先统一 Currency

↓

统一 UOM

↓

检查 MOQ

↓

检查 Incoterm

↓

处理 Freight / Tax

↓

再比较价格

不应该随着这次 Context 一起消失。

它应该成为一个以后可以重复调用的方法。

这就是 Skill。

---

01Skill 的核心：把“临时推理”沉淀成“可复用能力”

很多 Agent 教程会直接告诉你：

Skill 就是一段 Prompt。

这个理解不能说完全错。

但它只看到了存储形式，没有看到 Skill 为什么存在。

Markdown 不是 Skill 的本质。

SKILL.md 也不是。

YAML 不是。

某个 Framework 的 Skills API 更不是。

Skill 真正解决的是一个更底层的问题：

LLM 每次调用，本质上都非常擅长临场推理，但临场推理不等于能力积累。

如果每一个任务都从这里开始：

Goal

↓

LLM：这件事应该怎么做？

那么过去十次成功经验和第一次做，系统结构上没有本质区别。

而 Skill 加进来之后，流程第一次变成：

Goal

↓

这种问题以前有没有成熟方法？

↓

有

↓

加载 Skill

↓

LLM 基于已有方法继续判断

变化看似只是多了一个文件。

其实意义非常大。

因为一部分原本存在于：

模型这一次临时生成的 Reasoning

里的东西，

开始被外部化成：

Runtime 可以保存、检索、复用的能力资产

这才是 Skill 真正值得学习的地方。

把前面的概念压成三句话，其实就已经很清楚：

Context：当前知道
Memory：过去知道
Skill：学会怎么做

并且把 Skill 定义为“遇到某类问题时，已经总结出来的一套可复用解决方法”。

这四个字最重要：

怎么做。

---

02Memory 与 Skill：一个记事实，一个记做法

这个地方一定要讲透。

假设 Agent 昨天处理过 Supplier A。

它保存了一条：

Supplier A 去年的报价是 USD 4.80 / meter。

这是 Memory。

为什么？

因为它描述的是一个事实：

我过去知道什么。

再看另外一条：

比较供应商报价之前，
必须先统一 Currency、UOM 和 Incoterm。

这就不是普通 Memory 了。

它已经变成：

遇到这类问题，我应该怎么做。

所以最简单的区分是：

Memory = What I know

Skill = How I do

但我建议再深入一步。

Memory 很多时候属于：

某一次人
某一个文件
某一个项目
某一个过去事件

例如：

这个用户喜欢英文报告。

上一次采购价格是 4.80。

昨天这个 API 返回过 500。

sales.xlsx 的日期列在 C 列。

这些都可能非常有用。

但它们大部分是在描述：

世界。

Skill 描述的则是：

做事的方法。

例如：

做报价分析时，不要直接比较原始价格。

做 Coding Debug 时，先复现 Failure，再修改代码。

做 Web Research 时，关键结论至少验证来源和时间。

做 Excel 分析时，不要假设第一行一定是 Header。

你会发现一个很明显的变化。

Skill 通常比一次 Memory 更抽象。

因为它必须能够：

跨任务复用。

如果只能服务昨天那一个文件，它大概率还不是 Skill。

---

03Tool ≠ Skill：会调用工具，不等于会做事

接下来是另一个特别容易混淆的地方。

假设 Agent 有这些能力：

read_excel()
search_web()
run_python()
write_file()
send_email()

这些是什么？

Tools。

Tool 回答的是：

Agent 能执行什么动作？

Skill 回答的是：

面对某一类问题，这些动作应该怎么组织起来？

这是两个完全不同的层级。

比如：

read_excel

只能说明 Agent 能读 Excel。

但“销售 Excel 应该怎么分析”里面可能包含：

先看 Workbook Structure

↓

识别真实 Header

↓

确认 Date / Region / Sales 字段

↓

Normalize Date

↓

检查 Duplicate

↓

验证 Numeric Fields

↓

计算同比

↓

检查异常

↓

核对 Row Count

这套东西本身并没有增加新的底层 Tool。

Agent 还是调用同样的：

read_excel
run_python
write_file

但它使用 Tool 的方式变成熟了。

所以一个很好理解的类比是：

Tool = 工具

Skill = 手艺

有刀、有锅、有烤箱，不代表会做一道菜。

有浏览器不代表会 Research。

有 Shell 不代表会 Debug。

有 Excel Reader，也不代表会做靠谱的数据分析。

所以这一课必须把 Skill 和 Tool 拆开讲，而且实验也要落到 Skill Loader：问题不在“有没有工具”，而在“工具该怎么被组织起来”。

---

04Skill 也不是 Workflow：方法可以复用，路径仍要判断

也不是。

这两个看起来更像。

假设程序被开发者写死：

data = read_excel(path)

data = normalize_date(data)

data = remove_duplicates(data)

result = calculate_sales(data)

write_report(result)

这是 Workflow。

因为无论今天这个 Excel 长什么样，程序的路径基本已经确定：

A

↓

B

↓

C

↓

D

而 Skill 不应该完全拿走 Agent 的判断权。

比如一个 Excel Skill 可以写：

不要假设第一行就是 Header。

先识别实际日期字段。

进行指标计算之前检查 Duplicate。

处理结束后核对输入行数和输出行数。

它规定了一些成熟方法。

但具体到当前文件：

Header 在第几行？

日期列叫什么？

哪些 Sheet 应该合并？

Duplicate 的业务主键是什么？

异常阈值应该是多少？

Agent 仍然需要根据现实动态判断。

所以更准确地说：

Workflow
=
固定执行路径

Skill
=
可复用的方法、约束和经验，
但保留当前任务的决策空间

这也是 Skill 为什么特别适合 Agent。

它既不是：

什么都交给模型临场发挥。

也不是：

把所有步骤完全写死。

它位于两者之间。

---

05到这里，可以给 Skill 一个更准确的定义

我会这样定义：

Skill 是针对某类任务沉淀下来的、可持久化、可检索、可复用的程序性知识。Runtime 在相关任务出现时把它加载进 Context，用来影响 Agent 的 Planning、Decision、Action，甚至 Verification。

这个定义里每一个词都有用。

“某类任务”，意味着它不是一次性的 Episode。

“可持久化”，意味着任务结束以后不会一起消失。

“可检索”，意味着不是所有 Skill 永远塞进 Prompt。

“程序性知识”，意味着它描述的是 How，而不仅仅是 What。

“影响行为”，意味着真正的 Skill 最终应该让 Agent 做得不一样。

如果一个 Skill 加进去和删掉以后，Agent 的行为几乎毫无变化，

那它很可能不是 Skill。

只是：

Prompt Decoration。

---

06为什么不能把所有 Skill 都塞进 System Prompt？

刚开始做 Agent 的时候，很容易想：

那我把所有经验都写进 System Prompt 不就好了？

三个 Skill 的时候确实没问题。

假设只有：

Excel Analysis
Coding Debug
Web Research

全部放进去也就几千 Token。

但系统运行半年以后呢？

你可能拥有：

Supplier Quote Analysis
Sales Excel Analysis
Inventory Reconciliation
Fabric Test Analysis
Contract Review
PDF Extraction
Web Research
Python Debugging
SQL Analysis
Presentation Generation
Email Follow-up
ERP Troubleshooting
...

再过一年：

500 Skills

怎么办？

500 个 Skill 全部进入每一次 Context？

那第五课 Context Engineering 学的东西全部白学了。

前面讲 Context Engineering 时已经反复强调：Agent 一轮里可能同时出现 System Prompt、History、Tools、Memory、Skills、Files、Environment State 等大量信息，真正困难的从来不是“能塞多少”，而是：

什么应该进 Context？ 什么不应该进？

Skill 同样遵守这个原则。

所以一定要区分：

Agent 拥有的 Skills

和：

这一轮 LLM 看见的 Skills

它们不是一回事。

这自然会逼出一个新组件：

07Skill Loader：不是“读文件”，而是“按需加载能力”

---

08Skill Loader：不是“读文件”，而是“按需加载能力” 其实只干两件事

不要被名字吓到。

最初版本的 Skill Loader 只需要回答两个问题：

当前任务应该使用哪个 Skill？

以及：

找到以后，怎么把它放进 Context？

假设用户说：

分析 sales.xlsx，找出同比下降最大的三个地区。

系统现在有：

excel_analysis
coding_debug
web_research
supplier_quote_analysis
email_followup

Runtime 第一件事不是把五个全部加载。

而是判断：

当前任务

↓

Excel Analysis

然后：

load excel_analysis

LLM 最终看到的 Context 从：

Goal:
分析 sales.xlsx

变成：

Goal:
分析 sales.xlsx

Relevant Skill:
Excel Analysis

Method:
- inspect workbook structure
- identify actual header
- normalize date fields
- check duplicates
- validate numeric fields
- reconcile row counts before completion

再让 Planner 工作。

这一前一后的差距非常大。

---

09有 Skill 的 Planner，会从“空白搜索”变成“基于经验规划”

没有 Skill。

用户：

找出销售下降最大的三个地区。

Planner 很可能产生：

1. 读取 Excel
2. 分析销售数据
3. 找下降地区
4. 输出报告

不能说错。

但非常泛。

加入 Excel Skill 以后：

1. Inspect workbook structure
2. Identify business sheets and actual header
3. Validate Region / Date / Sales columns
4. Normalize dates and numeric values
5. Check duplicate business keys
6. Calculate regional sales by period
7. Calculate YoY changes
8. Rank declining regions
9. Reconcile processed row count
10. Produce the final analysis

注意：

模型依然在 Planning。

Skill 没有替它完成任务。

Skill做的是另外一件非常重要的事情：

让 Planner 不需要在一个完全空白的搜索空间里重新发明方法。

这其实是理解 Skill 最好的角度之一。

---

10Skill 的价值：把推理预算留给真正未知的问题

没有 Skill：

问题

↓

LLM 探索各种可能路径

↓

找到一个办法

有 Skill：

问题

↓

过去已经证明有效的方法

↓

排除大量低质量路线

↓

只对当前真正未知的部分推理

举个例子。

供应商报价分析已经形成成熟 Skill：

Currency 必须 Normalize

UOM 必须 Normalize

MOQ 必须检查

Incoterm 必须检查

那么下一次 LLM 根本不应该再耗费推理预算去思考：

Currency 要不要检查呢？

这个问题已经被解决了。

真正值得模型思考的是：

当前 Currency 是什么？

汇率依据是什么？

meter 和 yard 怎么换算？

FOB 和 CIF 之间具体差了哪些成本？

也就是说：

Skill 把已经解决的问题固化下来，让 Reasoning 留给还没有解决的问题。

这才是一种成熟的 Agent Architecture。

真正优秀的 Agent，并不是越来越会“想”。

而是越来越清楚：

什么已经不需要重新想。

---

11一个有用的 Skill，写的不是“认真一点”

假设我们建立：

skills/
    excel_analysis.md

如果内容是：

你是一名优秀的数据分析专家。

请认真思考。

请注意准确性。

考虑各种边界情况。

输出专业结果。

这东西基本没什么价值。

因为换任何任务都成立。

它没有告诉 Agent：

这类任务真正容易在哪里出错。

更好的 Excel Skill 应该像：

# Excel Analysis

## When to use

Use for spreadsheet analysis tasks.

## Procedure

1. Inspect workbook and sheet structure.
2. Identify the actual header instead of assuming row 1.
3. Validate required business fields.
4. Normalize date values.
5. Normalize numeric and percentage fields.
6. Check duplicate business keys.
7. Perform requested calculations.
8. Inspect anomalies before reporting.
9. Reconcile input and processed row counts.

## Known failure modes

- Dates may be Excel serial numbers.
- 25% may appear as 0.25 or 25.
- Merged cells may break naive parsing.
- Supplier names may contain whitespace differences.
- Blank rows should not automatically be treated as missing records.

## Verification

Before completion:

- required sheets were processed
- required columns were found
- requested metrics were calculated
- no requested records were silently skipped
- row counts were reconciled

这里有一个很值得注意的特点。

真正有价值的内容通常不是：

“请认真。”

而是：

以前真正吃过亏的地方。

这就是为什么最好的 Skill 往往会随着真实使用越来越强。

---

12Failure 为什么是 Skill 最好的老师？

第一次做 Excel 分析时，你可能只知道：

读取

↓

计算

↓

输出

但真实世界不断教育你：

第一次：

原来第一行不一定是 Header。

第二次：

原来百分比可能是 0.25，也可能是 25。

第三次：

原来日期可能是 Excel Serial Number。

第四次：

原来 Merge Cell 会让 Parser 出问题。

第五次：

原来 20 份文件只处理 18 份，程序照样可以正常结束。

慢慢地：

Failure

↓

Evidence

↓

Verification

↓

Reflection

产生了一批非常宝贵的东西。

这些东西真正值得留下来的，不是：

我失败过五次。

而是：

以后处理这种问题，应该注意什么。

这就是从 Episode 到 Skill 的变化。

可以把这条路径记住：

Experience

↓

Failure / Success

↓

Reflection

↓

Pattern

↓

Reusable Method

↓

Skill

但是这里有一个非常重要的陷阱。

---

13Reflection 不是 Skill：经验还要经过抽象

假设这次 Agent 失败是因为：

文件实际叫 sales_final_v2.xlsx，
而不是 sales.xlsx。

Reflection：

应该读取 sales_final_v2.xlsx。

对当前任务完全正确。

值得保存成 Skill 吗？

显然不值得。

因为它不具备跨任务价值。

再看一个：

这个 Repository 必须运行：

uv run pytest

直接运行 pytest 会进入错误环境。

如果这个事实长期稳定，

那么它已经很像：

Repository Testing Skill

再看一个更通用的：

调试代码时，修改之前先复现失败；
修改以后必须重新运行同一个验证。

这个复用范围更广。

所以这里有一个非常关键的层次变化：

Reflection
=
这一次我学到了什么？

Skill
=
这里面有没有一种以后还值得使用的方法？

这就是为什么第十二课必须放在 Skill 后面。

因为第十二课 Learning Loop 真正难的地方不是：

怎么把 Reflection 写进文件。

而是：

什么东西有资格从一次经验升级成长期能力？

---

14动手实现：从 11_skill.py 开始

继续沿用这个系列一直以来的原则：

不用框架帮你藏掉核心。

前面是：

08_memory.py
09_planner.py
10_verifier.py

现在自然长成：

11_skill.py

这套代码会让同一个 Agent 从 08_memory.py → 09_planner.py → 10_verifier.py → 11_skill.py 一层层长出来，而不是每一课都换一套 Framework。

第一版甚至只需要一个目录：

agent-from-zero/

├── 10_verifier.py
├── 11_skill.py
│
└── skills/
    ├── excel_analysis.md
    ├── coding_debug.md
    └── web_research.md

然后一个最普通的 Loader：

from pathlib import Path

SKILL_DIR = Path("skills")


def load_skill(name):
    path = SKILL_DIR / f"{name}.md"

    if not path.exists():
        return None

    return path.read_text(
        encoding="utf-8"
    )

很普通。

甚至普通得有点让人失望。

但这一步的意义并不在代码难度。

真正的变化是：

以前“怎么做”存在于模型这一次的临时 Reasoning。

现在：

How to do

第一次成为了一个：

Runtime 可以独立管理的对象。

这是架构升级。

---

15Load 很简单，Select 才是真正的难点

文件怎么读没什么技术含量。

真正的问题是：

当前任务到底应该加载什么？

三个 Skill 的时候，第一版完全可以简单粗暴：

def select_skills(goal):
    selected = []

    text = goal.lower()

    if "excel" in text or ".xlsx" in text:
        selected.append("excel_analysis")

    if "python" in text or "bug" in text:
        selected.append("coding_debug")

    if "research" in text or "搜索" in goal:
        selected.append("web_research")

    return selected

然后：

def retrieve_skills(goal):
    names = select_skills(goal)

    skills = []

    for name in names:
        content = load_skill(name)

        if content:
            skills.append({
                "name": name,
                "content": content,
            })

    return skills

最后：

skills = retrieve_skills(goal)

放进：

plan = create_plan(
    goal=goal,
    state=state,
    memories=memories,
    skills=skills,
)

现在整个 Runtime 变成：

Goal

↓

Retrieve Memories

↓

Select Skills

↓

Load Skills

↓

Build Context

↓

Planning

↓

Execute

↓

Observe

↓

Verify

↓

Reflect

到这里，第十一课真正进入了之前那条 Agent 主循环。

---

16Skill 为什么要在 Planning 之前出现？

因为 Skill 不只是告诉 Executor：

下一步怎么干。

它应该从一开始就影响：

整个 Plan 应该长什么样。

例如 Coding Agent 接到：

修复 calculator.py，直到测试通过。

它加载：

coding_debug

里面写：

先复现当前 Failure。

不要只根据函数名猜语义。

优先把 Tests 当作行为 Contract。

每次修改以后重新运行验证。

禁止为了通过测试而修改 Test。

那么 Planner 从一开始就会产生更靠谱的路线：

1. Run existing tests
2. Inspect the failing test
3. Inspect relevant implementation
4. Make minimum code change
5. Rerun tests
6. Verify test files were not modified

而不是：

1. 看代码
2. 猜哪里错
3. 修改
4. Done

Skill 已经开始改变 Planning。

这才是真正的 Skill。

---

17Skill 不只影响 Planning，也应该影响 Verification

这是非常容易被忽略的一层。

例如 excel_analysis Skill 不仅知道：

怎么分析。

它还知道：

这类任务通常应该怎么验收。

比如：

处理结束前必须检查：

expected rows == processed rows

required sheets all covered

requested metrics all produced

那么 Skill 可以包含：

Procedure

和：

Verification Rules

Executor 使用前者。

Verifier 使用后者。

于是第十课和第十一课真正拼起来：

Skill

↓

告诉 Agent 这类事情通常怎么做

↓

Execute

↓

Environment

↓

Evidence

↓

Skill-defined checks + Goal criteria

↓

Verification

这就已经不仅是一个 Prompt Library。

它开始接近：

Domain-specific operational knowledge。

---

18再成熟的 Skill，也不能凌驾于 Reality 之上

假设旧 Skill 写着：

POST API 返回 200，
就认为状态修改成功。

今天 Agent 调：

POST /users/123/status

返回：

200 OK

按照旧 Skill：

成功。

但是第十课已经告诉我们：

验证 Outcome，不要只验证 Action。

于是 Runtime 再：

GET /users/123

结果：

status = inactive

这时候怎么办？

当然相信 Reality。

而不是相信 Skill。

所以我非常建议记住一个优先关系：

Environment Evidence
>
Skill
>
Model Guess

Skill 的本质是：

过去被证明有效的方法。

不是：

世界永远必须按照它运行。

一旦现实反复推翻某个 Skill，

正确动作应该是：

Verification

↓

Skill assumption failed

↓

Reflection

↓

Revise Skill

否则 Skill 不会让 Agent 越来越聪明。

它会让 Agent：

越来越稳定地犯错。

---

19Skill 一旦进入生产，就绕不开 Version

还是报价分析。

最开始：

supplier_quote_analysis v1

直接比较价格。

现实教育一次：

v2

先 Normalize Currency 和 UOM。

又失败一次：

v3

再检查 MOQ 和 Incoterm。

再碰到 Freight / Tax：

v4

Normalize comparison basis:

Currency
UOM
MOQ
Incoterm
Freight
Tax

这个过程很像什么？

软件版本。

所以 Production 里的 Skill，最终很可能需要：

name
version
scope
updated_at
last_verified
owner
known_failure_modes

为什么要有 scope？

因为一个 Skill 可能只适用于：

某个 Repository

而不是全世界所有 Python 项目。

为什么要有 last_verified？

因为方法会过期。

去年公司的 Deploy 方法可能是：

scp

↓

restart service

今年已经迁到 Kubernetes。

如果 Agent 还把旧 Skill 当真理，

Skill 反而会成为新的风险来源。

---

20Skill 最难设计的，往往不是内容，而是粒度

假设你做：

Excel Skill

听起来很好。

但是很快它里面塞进：

Sales Analysis
Inventory
Finance
Supplier Quotation
Production Planning
Fabric Testing
HR Report

最后变成 8000 行超级 Skill。

每次加载它，Context 都被污染。

那你只是把 System Prompt 的问题搬到了另一个文件。

所以 Skill 应该具有合适的 Scope。

例如：

excel_basic_handling

sales_excel_analysis

supplier_quote_comparison

inventory_reconciliation

fabric_test_report_analysis

但也不能反过来拆得过细。

例如：

how_to_read_supplier_a_20260813_final_v2.xlsx

这根本不是 Skill。

只是一次任务记录。

一个好的 Skill 应该处在两个极端之间：

足够抽象
→ 能跨任务复用

足够具体
→ 能真正改变行为

这是实际做 Skill Library 时最值得花时间设计的地方之一。

---

21Skill Library 一旦变大，Retrieval 才是核心工程问题

只有三个 Skill：

if ".xlsx" in goal:

完全没问题。

但是 500 个以后呢？

你不可能把 500 个 Skill 全文放进 Prompt，然后问模型：

你选一下。

因为为了选择 Skill，你已经把所有 Skill 加载了。

这跟没做 Skill Loader 没区别。

更合理的结构是两阶段。

第一阶段只给 Skill Index：

excel_analysis
Analyze spreadsheet datasets and validate calculations.

supplier_quote_analysis
Normalize and compare supplier quotations.

coding_debug
Debug code using tests and runtime evidence.

web_research
Research a topic using external sources.

只包含：

Name
+
Description
+
可能还有 Tags / Scope

模型或 Retriever 先选：

supplier_quote_analysis

Runtime 再读取完整 Skill：

Skill Index

↓

Candidate Retrieval

↓

Ranking

↓

Selected Skill

↓

Load Full Content

↓

Inject into Context

这才真正解决 Context 问题。

---

22Skill 也不一定要在 Goal 开始时一次性选完

假设用户要求：

研究三家 AI 公司，做成 Excel，然后把结果发给团队。

这是一个 Goal。

但里面至少有三个阶段：

Research

↓

Spreadsheet

↓

Communication

第一步可能需要：

web_research

第二步：

spreadsheet_analysis

第三步：

business_email

如果任务开始时一次性把三份大 Skill 全塞进去，

模型在做 Research 时却同时看到几十条 Email Writing 规则。

没有必要。

所以一个成熟一点的 Skill System 甚至可以：

retrieve_skills(
    goal=goal,
    step=step,
    state=state,
)

也就是：

Goal-level Skill Selection

进一步变成：

Step-level Skill Selection

任务进行到哪一阶段，就加载当前真正需要的方法。

这个设计和 Context Engineering 是完全连起来的。

---

23Skill 让“Agent 能力 ≠ 模型能力”这件事变得非常直观

这是第十一课非常重要、但经常被低估的一点。

假设 Day 1。

Agent 使用某个模型。

会 Tools。

但不会稳定处理供应商报价。

Day 30。

模型一个参数都没有变化。

没有 Fine-tune。

没有重新训练。

还是同一个 Model。

但是 Runtime 多了：

supplier_quote_analysis v4

于是现在 Agent 接到报价分析任务，一开始就会：

Normalize Currency
Normalize UOM
Check MOQ
Check Incoterm
Validate Freight
Verify supplier count

请问：

这个 Agent 有没有比一个月前更强？

有。

模型有没有变强？

没有。

这说明：

Model Capability
≠
Agent Capability

Agent 的能力来自整个系统：

Model
+
Context
+
State
+
Tools
+
Memory
+
Planning
+
Verification
+
Skills
+
Runtime
+
Environment

这和整门课最开始的第一性原理完全一致：Agent 不是“一个更聪明的 LLM”，而是以 LLM 为决策器，在环境中持续观察、决策、行动、获取反馈和更新状态的软件系统。

Skill 只是第一次让这个事实变得特别直观：

模型不升级，Agent 也可以升级。

---

24Skill 与 Fine-tuning：改变行为，但改的不是同一层

Fine-tuning 的路径大概是：

Training Data

↓

Optimization

↓

Weights Change

↓

Model Behavior Change

Skill 的路径是：

Human Knowledge / Experience

↓

Skill Artifact

↓

Runtime Retrieval

↓

Context

↓

Agent Behavior Change

Fine-tuning 修改的是：

Model Parameters

Skill 修改的是：

Runtime 可用的程序性知识

Skill 有一个非常实际的工程优势。

它通常可以：

查看
修改
版本控制
单独禁用
限定 Scope
人工审核
回滚

某个业务 SOP 改了，

你不需要重新训练整个模型。

更新对应 Skill 即可。

这也是为什么企业 Agent 很适合把大量业务 Know-how 做成 Skill。

---

25企业里其实早就有大量 Skill，只是以前不这么叫

这一点非常重要。

不要误以为：

Skill 一定要 AI 自己学出来。

现实公司里，第一批真正高价值的 Skills 很可能早就存在。

只是它们叫：

SOP
Playbook
Checklist
Troubleshooting Guide
Best Practice
Operating Procedure
Business Rules

例如采购团队已经有：

Supplier Quote Review SOP。

IT 团队已经有：

Production Incident Troubleshooting Guide。

数据团队已经有：

Monthly Sales Report Procedure。

这些东西本质上非常接近 Agent Skill 的原材料。

把一份人类 SOP 转成 Agent Skill 时，真正值得提取的不是所有文字。

而是：

什么时候使用

前置条件是什么

应该怎么做

哪些地方不能做

常见 Failure Mode 是什么

怎样判断真的完成

于是 Skill 不只是“AI 学习”。

它还有一个非常现实的价值：

把组织里原本散落在人脑、文档和经验里的做事方法，变成 Agent Runtime 可以调用的执行知识。

这件事对企业 Agent 的价值，远比“Prompt 写得更漂亮”大得多。

---

26怎么判断一份内容到底配不配叫 Skill？

这里我给一个非常实用的判断方式。

不要先问：

这是不是一个 Markdown 文件？

而问三个问题：

第一，它是不是针对某一类可重复任务？

第二，它里面是不是包含可执行的方法、约束或者检查规则？

第三，也是最重要的一条：

加载它以后，Agent 的实际 Planning 或 Action 会不会明显改变？

例如：

请仔细思考。

不会。

不是 Skill。

输出要专业。

基本不会。

不是一个有价值的 Skill。

而：

在比较报价前，不允许直接比较 Raw Price；
必须先 Normalize Currency、UOM、MOQ、Incoterm。

会直接改变 Agent 的执行路线。

这是 Skill。

好的 Skill 不是让 Agent：

听起来更聪明。

而是让 Agent：

做事方式更成熟。

---

27把前十一课重新拼起来，Agent 的结构就清楚了

一开始只有 Model。

后来我们一步一步加东西。

Tool 回答：

我能做什么？

Environment 回答：

现实发生了什么？

State 回答：

当前任务做到哪里？

Memory 回答：

过去有什么值得知道？

Planning 回答：

接下来准备怎么走？

Verification 回答：

现实真的满足要求了吗？

Reflection 回答：

为什么预期和现实不一致？

而 Skill 回答：

这种事情，我已经知道一套成熟做法了吗？

这时候 LLM 的角色反而越来越清楚。

它不是万能数据库。

不是操作系统。

不是 Workflow Engine。

不是 Memory。

也不是整个 Agent。

它更像：

站在这些结构化能力之间，根据当前 Context 做动态 Decision 的决策器。

这才是把 Agent 真正拆开以后应该看到的东西。

---

28最后，把第十一课的 Agent 完整跑一遍

用户：

分析 20 份供应商报价，找出异常价格并给采购建议。

Runtime 收到 Goal。

先 Retrieve Memory：

去年采购历史
用户输出偏好
项目相关事实

再 Select Skill：

supplier_quote_analysis

Skill 告诉 Planner：

不能直接比较 Raw Price。

先统一：
Currency
UOM
MOQ
Incoterm
Freight / Tax Basis

最后必须核对：
expected supplier count
processed supplier count

Planner 产生：

获取 20 份报价

↓

识别报价基础

↓

Normalize comparison basis

↓

获取历史采购价格

↓

做 Comparable Price Analysis

↓

识别异常

↓

检查遗漏供应商

↓

形成采购建议

Executor 开始执行。

Tool 负责：

读 Excel
查询历史数据
计算
写报告

Environment 返回 Reality。

State 保存：

已经处理多少
产生了什么结果
有哪些 Evidence

Verifier 最后发现：

expected_supplier_count = 20
processed_supplier_count = 18

于是：

UNKNOWN / FAIL

绝对不允许 Done。

继续取证或者修正。

最后：

20 / 20 processed
comparison basis normalized
required outputs generated

Verification PASS。

任务结束。

如果本次执行又发现一个新的稳定规律，例如：

这种供应商报价还必须统一 Packaging Basis，否则每箱和每件价格会失真。

当前 Reflection 可以先记录。

但要不要升级：

supplier_quote_analysis v5

还不能草率决定。

因为一次任务里得到的东西，有可能是：

偶然情况

也可能是：

稳定方法

而区分这两个东西，就是整个 Agent Learning 最难的一步。

---

29真正学懂这一课，至少要能回答这一句

学完这一课，如果别人问你：

Skill 是不是就是一个 Prompt 文件？

你不应该回答“是”。

文件只是实现。

真正的 Skill 是：

Agent 已经学会的一种可复用做事方法。它把过去已经验证过的程序性知识从一次性的 LLM Reasoning 中外部化，由 Runtime 持久化，在未来相关任务中按需检索进入 Context，从而真正改变 Planning、Decision、Action 或 Verification。

所以第十课和第十一课之间，其实只有一句话的距离：

第十课让 Agent 学会：

“现实证明我错了，我应该改。”

第十一课让 Agent 再进一步：

“这条路我已经走通过了，下次没必要重新撞墙。”

而真正麻烦的问题，也恰恰从这里才开始。

因为如果我们允许 Agent 把经验变成 Skill，就必须回答：

什么经验值得永久留下？

一次成功够不够？

一次失败后的 Reflection 能不能直接写 Skill？

如果 Skill 写错怎么办？

多个 Skill 相互冲突怎么办？

Skill 使用以后到底有没有让成功率提高？

一个旧 Skill 什么时候应该更新、降级甚至删除？

到了这里，问题已经不再是：

怎么加载 Skill？

而变成：

Agent 怎样从自己的真实经历中，
持续产生、验证、修改和淘汰 Skill？

这才是下一课真正有意思的地方。

Agent 原理（十二）：一个 Agent 把所有“经验”都记下来，只会越来越蠢——Learning Loop 到底怎样才能让它真的越用越强