代码做骨架，Skill 做灵魂HERMES & AGENT ENGINEERING · 课时 04

4.1 这一节讲的就是形态四

上一节列了五种形态，其中第四种叫「代码骨架 + Skill」。

为什么单独拿一节出来讲？因为这种形态最常用。

纯 Skill 太轻，稍微复杂一点的业务就稳不住。 完整应用又太重，投入接近传统开发，很多场景没必要。

形态四夹在中间——既有代码的稳定和效率，又保留了大模型的灵活和智能。绝大多数业务系统，最后都会落到这个形态上。

4.2 纯 Skill 为什么不稳

如果你做过稍微复杂一点的 Skill，大概率会遇到这些问题。

每一步都要"想"，想就可能出错

一个流程如果有 10 个步骤，每一步都让大模型读 Skill、理解、决策，那每一步都有概率跑偏。

每一步 90% 的准确率，10 步乘下来，整体就只剩 35% 了。中间只要有一步走偏，后面就全乱套了。

同一件事，这次这么做，下次那么做

大模型有随机性。同样的输入、同样的 Skill，两次执行的路径可能不一样。

有时候它会"灵机一动"，走一条你没预料到的路，结果就翻车了。你没法保证每次行为一致。这种不确定性放在企业环境里就更加危险了，企业是绝对接受不了不确定性的。

出了问题很难排查

代码出 bug 了，打个断点、加个 log，一步一步追，总能找到问题在哪。

Skill 执行出问题了，你只能读对话历史，猜它当时怎么想的。排查起来全靠猜测。

简单操作也烧 Token

就一个简单的文件移动和重命名，大模型也要先理解需求、确认路径、然后调用工具。

光这一堆推理就烧掉几千个 Token。明明一行命令就能搞定的事。

这些问题的根源是一样的：该用代码的地方，我们用了自然语言推理。

4.3 形态四的核心思路：代码做骨架，Skill 做灵魂

那怎么解决？可以把流程中固定的、确定性的部分，用代码固化下来，做成一个个函数和工具；把需要判断、理解、创意的部分，留给 Skill 和大模型。

这就是形态四的核心思路：代码做骨架，Skill 做灵魂。

但这里有一个关键点，很多人一开始会忽略：Skill 不只是"做判断"，它还要"做编排"。

Skill 的两种用法

Skill 在整个系统里，有两种截然不同的用法：

第一种：直接用大模型做理解，不需要任何代码。 比如提取一篇文章的中心思想、判断一段文本属于什么主题、评估某个方案的质量好不好。这些事情你根本不需要写 Python 函数，Skill 直接让大模型读文本、想、给出结论就完了。代码在这里没有存在的意义，大模型天然就擅长做这个。

第二种：想清楚之后，编排 Python 工具来执行。 比如用户丢进来一个 URL，Skill 先判断这个 URL 要不要处理、是更新已有内容还是新建条目，想清楚之后，再依次调用 extract_article() 提取正文、compute_hash() 算哈希去重、save_to_feishu() 写入飞书。这一串工具怎么组合、什么顺序、什么时候该调哪个，都是 Skill 想清楚之后决定的。

+---------------------------------------------------
|  你的 Shell（壳）
|
|  Skill 的两种用法：
|
|    用法一：直接理解                用法二：理解 + 编排
|    ┌──────────────┐              ┌──────────────┐
|    │ 大模型直接思考 │              │ 大模型先思考   │
|    │ 得出结论      │              │ ↓             │
|    │ 结束          │              │ 调用 Python   │
|    └──────────────┘              │ 工具执行      │
|                                  │ ↓             │
|                                  │ 拿到结果，     │
|                                  │ 继续思考或结束  │
|                                  └──────────────┘
|
|  Python 代码：一个个独立的工具函数
|    每个函数做一件确定的事
|    不负责思考，不负责编排
|
+---------------------------------------------------
          |
          v
+------------------------
|  超级 Agent（内核）
+------------------------

用一句话概括：Skill 是脑，代码是手。 有些时候，脑想想就直接给出答案了；有些时候，脑想清楚之后，指挥手去干活。但无论如何，做决定的都是脑，不是手。

这也是为什么我们说"代码做骨架，Skill 做灵魂"：骨架撑起身体结构，灵魂决定怎么行动。

4.4 提升有多大

不用精确数字，从几个维度感受一下：

• 稳定性：原来 10 步全靠大模型，现在 8 步用代码固化，稳定性可能提升一个数量级
• 速度：代码执行是毫秒级的，大模型推理要几秒几十秒，整体快 3 到 10 倍很正常
• Token 消耗：省掉了大量"我现在该干什么"的中间推理，只保留了真正需要智能的地方。
• 可维护性：代码的部分可以写测试、可以 CI、可以 debug，和纯 Skill 比是天壤之别

把确定性的东西下沉到代码，就把"不可控"的部分压缩到了最小。剩下需要大模型判断的地方，都是真正需要智能的地方。

4.5 形态四的交付物长什么样

关于交付物，是我思考最多的问题。 Shell Engineering 的交付物 远比传统软件的交付物要复杂很多。传统的交付物，无非就是代码（业务代码 Python、java) + 环境（MySQL、文件系统）。

但 Shell Engineering 是基于超级 Agent 的，如何在这个基座上交付”可复用“的程序是一个比较复杂的问题。

我们在第 10、第 11 章在深刻讨论这个问题，这涉及到以下几个概念&技术之间的关系：

• Hermes 或 Pi Agent 提供通用的理解、规划、工具调用和任务编排能力。
• Codex或者 Claude Code 负责去做开发，生产确定性的，不变的业务，然后将代码嫁接到 Hermes 上。
• Skill 提供语义理解和流程编排
• SDD 把业务规则、数据结构、流程和验收条件写清楚，让系统不是凭一次对话的感觉运行。
• OpenSpec 让这些规则可以版本化、变更、验收和回溯，而不是散在聊天记录和某个作者的脑子里。

4.6 ■ 学点英语