一、为什么用厨房打比方

智能体这个词被用得极烂，谁都能给它下个定义。要讲清楚，得先找一个大家都有直觉的场景。 厨房是最好用的那个：你点菜、厨师掌勺、台面就那么大、锅碗瓢盆有限、菜谱决定怎么做。 六个要素一一对应，而且每一样缺了会怎样，都能在家里厨房里想明白。 台面太小，菜摆不开；没有菜谱，全凭手感；没有锅，只能凉拌。 这套比喻不精确，但它能让你在写技能卡住的时候，问对一个问题：我缺的是哪一样？

二、提示词与大模型：指令和执行者

提示词是你说的那句话，大模型是听懂并执行的那个人。 两者是一对，缺一不可。只有提示词没有模型，是一张纸条；只有模型没有提示词，是个闲着的厨师。 这一对的特点是可塑性极强、稳定性极差。同一句话换个说法，出来的东西就不一样。 所以指望用提示词把一件事固定下来，是在跟它的本性对抗。 这就是为什么后面所有的东西（技能、工具、MCP）本质上都在做一件事：把不稳定的部分固定下来。

三、上下文：台面有多大

上下文是一次对话里模型能同时看到的所有文字，包括系统提示、你的话、它的回答、工具的返回。 它有一个硬上限，通常叫窗口。装不下的部分，等于不存在。 这句话听起来平常，后果很重：模型不会告诉你它忘了什么，它只是不知道。 台面就那么大，你把一整箱食材倒上去，最先掉地上的是最早放的那几样。 第 3 节会把这件事算成具体的数。这里先记住一条：上下文是预算，不是仓库。

四、工具与 MCP：用具和插座

工具是模型能主动调用的函数：读文件、跑命令、查数据库、发请求。 没有工具的时候，模型只能凭记忆说话；有了工具，它才能去看、去改、去验证。 这一点决定了它能不能干「有事实可查」的活。写文案不需要工具，改代码必须有。 MCP 是工具的标准接口。它的价值不在「多几个工具」，在于接法统一。 没有 MCP 的时候，每接一个外部系统都要单独写适配；有了它，换个服务只要换一份配置。 所以工具和 MCP 是两层：工具是「能做什么」，MCP 是「怎么把外面的东西接成工具」。 新手常把这两样混成一件事，结果在该写工具的时候去研究协议，在该配 MCP 的时候去写代码。

五、技能：菜谱

技能是一份写下来的做法：这类活该按什么步骤做、哪些不能做。 它和工具的区别，用厨房的话说最清楚：锅是工具，红烧肉的做法是技能。 锅决定你能做什么菜，菜谱决定你做出来是什么味。 技能在六个要素里位置特殊：它是唯一一个你写、模型读、而且只在该读的时候读的东西。 这句话里三个环节各自对应一个机制：你写（文本文件）、模型读（进上下文）、 按需读（description 触发）。 所以技能写得好不好，是三件事的总和，不是一件事。

六、一张表记住六大要素

这张表可以贴在显示器边上。写技能卡住的时候，从第一列往下扫一遍，问自己缺的是哪一样。 大部分「技能不好用」，最后都落在两行上：上下文（正文太长， 读进来就挤爆）和技能本身（步骤和边界没写清）。

七、动手 Demo：六个要素各占一个变量，跑一次任务就看得见

这一段把一个任务拆成两次执行：一次带着技能清单和技能里的步骤，一次什么都不带。 每次记录「这一轮调了什么工具、上下文涨了多少」，跑完把两边的账本摆在一起看。

# 六大要素在代码里就是六个位置
messages = [
    {'role': 'system', 'content': SYS_PROMPT},     # 提示词
    {'role': 'user',   'content': TASK},           # 你的请求
]
tools    = [run_shell, read_file, write_file]     # 工具
catalog  = [(name, desc), ...]                    # 技能清单（只进名字与描述）
# 大模型：调 API 的那一步（本沙箱没有）
# 上下文：messages 这个数组的总长度

实跑输出：

--------------------------------------------------------------------
六个要素各占一个变量，跑一次任务就看得见
--------------------------------------------------------------------


  ① 把六大要素落成代码里的六个位置
  --------------------------------------------------------------------
| 要素 | 厨房里的角色 | 代码里的位置 | 这次占多少 |
|---|---|---|---:|
| 提示词 | 系统提示与用户任务 | system + 第一条 user | 113 |
| 大模型 | 做判断的那部分 | （本沙箱没有，用规则替身） | — |
| 上下文 | 这次对话能装多少 | messages 数组 | 345 |
| 工具 | 能调的函数 | run_shell / read_file / write_file | 3 个 |
| 技能 | 按需读进来的经验 | 技能清单 8 条（只进名字与描述） | 232 |
| MCP | 外部系统的插座 | （本沙箱无，等价于多几个工具） | — |

  六个要素里，只有三个是你能直接改的：提示词、工具、技能。
  大模型是买的，上下文是窗口大小定的，MCP 是接进来的插座。
  ! 技能和工具的位置要分清：工具是「能做什么」，技能是「该怎么做」。
  ! 一把菜刀是工具，一道菜的做法是技能。厨房里两样都得有。

  ② 有技能：四步收敛
  --------------------------------------------------------------------
| 轮 | 工具 | 参数 | 新增 | 累计 | 占 32k |
|:---:|---|---|---:|---:|---:|
| 1 | run_shell | rg -n 'TODO' . | 340 | 685 | 2% |
| 2 | read_file | docs/TODO.md（不存在，确认要新建） | 120 | 805 | 3% |
| 3 | write_file | TODO_LIST.md，按文件分组写 23 条 | 260 | 1065 | 3% |
| 4 | run_shell | wc -l TODO_LIST.md | 60 | 1125 | 4% |

  起手 345 token，四轮之后 1125 token。每一步都在做具体的事。

  ③ 没技能：七步，其中三步是找路
  --------------------------------------------------------------------
| 轮 | 工具 | 参数 | 新增 | 累计 | 占 32k |
|:---:|---|---|---:|---:|---:|
| 1 | run_shell | ls | 210 | 555 | 2% |
| 2 | run_shell | find . -name '*.md' | 380 | 935 | 3% |
| 3 | read_file | README.md（以为里面有清单） | 620 | 1555 | 5% |
| 4 | run_shell | grep -rn TODO src/ | 520 | 2075 | 6% |
| 5 | run_shell | grep -rn 'FIXME' . | 480 | 2555 | 8% |
| 6 | write_file | output.md，格式自己定的 | 300 | 2855 | 9% |
| 7 | run_shell | ls -la output.md | 60 | 2915 | 9% |

  起手同样是 345 token——技能清单一进对话就在，用不用都得先列出名字。
  七轮之后 2915 token。
  多出来的三轮全在猜：猜清单在哪、猜格式、猜范围。
  这不是模型笨。是它手上没有「这类活该怎么做」的经验，只能从零试。

  ④ 两边的差，差在哪一件事上
  --------------------------------------------------------------------
| 指标 | 有技能 | 没技能 | 差 |
|---|---:|---:|---|
| 轮数 | 4 | 7 | +3 |
| 总 token | 1125 | 2915 | +1790 |
| 猜测性动作 | 0 | 3 | +3 |
| 产出格式 | 技能定好的 | 模型自己定的 | 不稳定 |

  技能省下的不是「想的时间」，是「试的次数」。
  ! 这是本沙箱用一套规则替身在演，不是真模型跑出来的。
  ! 能信的只有结构：有步骤的走四步，没步骤的走七步，方向不会反。

  ⑤ 要素之间的关系，一句话一条
  --------------------------------------------------------------------
  提示词 → 大模型        告诉它这一次要干什么
  大模型 → 上下文        只能在窗口里思考，装不下的等于不存在
  上下文 → 技能         技能清单常驻，正文按需读进来
  技能 → 工具          技能里写「跑哪个脚本」，工具负责真的跑
  工具 → 上下文         工具返回的结果，反过来又占上下文
  最后一条是个圈：工具用得越多，上下文涨得越快。
  所以「少调几次工具」和「每次少返回一点」，是两件都要管的事。

第一张表是六个要素的落点。提示词 113 token、技能清单 232 token、合计 345， 这三样是这次任务的起手成本。 大模型和 MCP 那两行写「本沙箱没有」——不是省略，是真的没有，不能编。 第二段是有技能的四轮：查一遍、确认文件不存在、写清单、数行数。 四轮下来 1125 token，每一轮都在做事，没有一轮在找路。 第三段是没技能的七轮，起手一样是 345——技能清单在不在，都要先列出名字。 差别在中间：前三轮在猜清单在哪、猜格式、猜范围，最后落到 2915 token。 第四段把两边的账摆在一起：轮数 4 对 7，token 1125 对 2915。 差的 1790 token 全在「试」上，不在「想」上。 这一整套是本沙箱用规则替身在演，不是真模型跑出来的，能信的只有结构。

30 秒实验

1. 拿一张纸写下你现在这台机器上六个要素各是什么：模型是谁、工具有哪几个、技能放哪。
2. 把同一个任务分别在有技能和无技能的情况下各跑一次，记下轮数。差三轮以上，说明这个技能值得写。
3. 找出你最近一次「答得不对」的对话，判断缺的是六样里的哪一样。多数情况是上下文塞满了。

常见误区

1. 把技能当成提示词的一种写法。提示词在对话里，技能在文件里；提示词每次重说，技能按需加载。 位置不同，用法完全不同。
2. 以为上下文很大所以随便塞。窗口再大也有上限，而且塞得越满，回答的空间越小。 「对话越长越笨」不是错觉。
3. 把 MCP 当成工具本身。MCP 是把外部系统接成工具的接口层。 你需要的是「能查数据库」，MCP 只是实现这件事的一种标准做法。

下一篇把「技能」这一格单独拎出来， 和提示词做四个维度的对比——为什么它能固定住提示词固定不住的东西。

• ☐ （本篇完，下一篇 2.2 技能比提示词强在哪）

相关笔记

• 打开技能文件夹看看
• 技能比提示词强在哪
• DeepSeek Harness 技术架构原理 · 索引
• 🧩 Skill提效实战 · 索引