Shell Engineering 的五种形态HERMES & AGENT ENGINEERING · 课时 02

2.1 先回到我们熟悉的传统软件

在聊 Shell Engineering 的交付物之前，我们先回顾一下传统软件时代，一个产品交付给用户时，长什么样。

过去几十年，我们做软件，交付物是非常明确的。常见的有这么几类：

第一类：前后端 Web 项目。

一个 Web 应用，前端可能是 React 写的，后端可能是 Java/Go/Python，数据库可能是 MySQL/PostgreSQL。交付给用户的时候，可能是一套部署脚本，可能是一个 Docker 镜像，也可能直接给你一个 SaaS 账号。用户拿到手，部署好、打开浏览器就能用。

第二类：移动端 App。

iOS 的 IPA 包，Android 的 APK 包，或者直接上架应用商店。用户下载安装，点开就是一个独立的应用。所有的逻辑、界面、数据存储，全部打包在里面。

第三类：桌面软件。

Photoshop、Word、Excel、IDE、游戏……安装包下载下来，双击安装，打开就是一个完整的软件。所有功能都在本地跑，数据也存在本地。

第四类：命令行工具。

git、ffmpeg、grep、各种 CLI 工具……没有图形界面，在终端里敲命令用。但本质上还是一个独立的程序，下载下来就能跑。

第五类：库 / 框架 / SDK。

React、Spring、TensorFlow、各种 SDK……开发者把它们引入自己的项目，用来搭建应用。虽然不是直接给最终用户用的，但交付物也是明确的——一包代码，有明确的 API，拿过来就能调用。

除此之外，还有小程序、插件、脚本、嵌入式软件、游戏引擎……形式多种多样，数不过来。

但不管是哪一种，有一点是共同的：它交付的是一套可以独立运行的代码或程序。

用户拿到手，它就能自己跑起来，自己完成任务，自己存数据，自己展示界面。它不依赖另一个"更聪明的东西"来帮它思考和做决策——它的所有逻辑，都已经写死在代码里了。它只需要一个操作系统或者运行环境，就能工作。

这就是我们习惯了几十年的产品形态：一个完整、独立、自包含的软件。

2.2 从一个具体场景说起

我们先站在用户的角度想。

上一章我们做了一个自动化视频系统——丢给它一篇文章，它自动写分镜、生成幻灯片、配音、合成视频，最后给你一支成片。这个东西很方便，但它到底是什么？

如果我觉得这个系统特别好用，想分享给我的朋友用，我要给他什么东西，他才能用起来？

你总不能跟他说："你去用 Hermes 吧，它能做视频。"——那跟没说一样。

也不能只是说："你按我这个思路自己搭一套吧。"——那成本太高了，他得花好几天去摸索。

一个真正能用的产品，必须有明确的交付物。用户拿到手，知道怎么装、怎么用、出了问题怎么查。

那 Shell Engineering 做出来的产品——比如这个自动化视频系统——交付物到底是什么？

是一个 Skill 吗？是一个 Python 程序吗？是一个 MCP Server 吗？还是一份文档？

答案是：都可以。Shell Engineering 的交付物没有固定形态。

它可以很轻，轻到就一份 Skill 配置文件；也可以很重，重到是一个完整的前后端应用。形态不重要，重要的是本质。

2.3 本质只有一个：依赖超级 Agent

判断一个东西是不是 Shell Engineering 的产物，只有一个标准：

把超级 Agent 拿掉，你的系统还能不能干活？

• 拿掉之后，核心功能全废了 → 这是 Shell Engineering 应用
• 拿掉之后，还能正常运行，只是少了点"智能" → 这不是，这是传统应用加了个 AI 功能

举个例子。

自动化视频系统：把 Hermes 拿掉，整个流程就走不下来了——谁来写分镜？谁来生成幻灯片内容？谁来组织配音文案？都不行。所以它是 Shell Engineering 应用。。

再加一个例子。一个笔记 App，加了个 AI 总结按钮：把 AI 拿掉，笔记功能照样用，只是不能自动总结了。这就不是 Shell Engineering，这是传统应用加了个 AI 增强功能。

Shell Engineering 的核心价值，是建立在超级 Agent 之上的。 超级 Agent 是你的内核，你做的是外层的业务壳。没有内核，壳就只是一个空架子。

这是它和传统软件的本质区别。

2.4 从轻到重的五种典型形态

虽然没有固定形态，但实际做出来的东西，大致可以分成这么几类。从轻到重排一下：

形态一：纯 Skill（最轻）

你可能没想到——绝大多数 Skill 本身，就是一个 Shell。

比如 frontend-design、美学设计系统、代码审查技能……这些 Skill 把一套做事的方法、规则、风格封装起来，Agent 装上之后，做相关事情的时候就会按这套规则来。

你装一个 frontend-design Skill，Hermes 就从"什么都会一点的通用 Agent"，变成了"懂设计的前端 Agent"。这个 Skill 就是套在 Hermes 外面的一层业务壳。

交付物就一个 Skill 文件夹。用户拿过去装上就能用。

特点：最轻量、最灵活、最容易分享。但也最依赖用户的 Agent 和模型能力——同一个 Skill 在不同的 Agent 上表现可能差异很大。适合个人使用，业务逻辑不复杂的场景。

个人认为，这种形式的最大缺点是，不可精确复现，极难测试。试想一下，你在网上找的很多优质 SKILL，看着作者的宣传效果，都很出彩。但是放到自己的 Agent 下，又总是会出问题，或者不满意。这是正常的现象。

形态二：Skill + 模板 + 生成物（单一业务型）

比纯 Skill 稍重一点的，是围绕单一业务做的完整 Skill 系统。我们上一章做的「映画」（自动化视频系统）就是典型代表。

它的核心仍然是 Skill——定义了从文章到成片的完整流程：文章 → 分镜 → 幻灯片 → 配音 → 合成。但除了 Skill 规则之外，它还有：

• 模板：PPT 主题、幻灯片布局、分镜格式
• 流程：明确的步骤顺序，每一步的输入输出
• 生成物：最终交付一个完整的视频文件
• 配套工具：ffmpeg、edge-tts 等外部工具的调用方式

业务很单一，就是做视频。但在这个单一业务里，它是一个完整的、端到端的解决方案。用户拿到手，按说明装好 Skill 和模板，丢一篇文章进去，就能出来一支成片。

特点：业务纯粹，端到端可用，用户体验好。虽然仍然以 Skill 为核心，但已经是一个"产品"的形态了，而不只是一个"技能"。

形态三：MCP Server + Skill（可复用的工具层）

如果你的系统需要让 Agent 访问一些特定的数据或者外部系统，可以做成 MCP Server + Skill 的形式。

比如你做了一个对接公司内部 CRM 的 Shell： - MCP Server 负责和 CRM 系统对接，提供查询客户、创建工单、更新状态等工具 - Skill 负责告诉 Agent 什么时候查、怎么查、查到了之后怎么处理

MCP Server 是工具层，Skill 是规则层。两者配合，Agent 就知道怎么跟你的业务系统打交道了。

比如一个麦当劳点餐服务： - MCP Server 负责对接门店系统，提供查菜单、下单、查订单状态这些工具 - Skill 负责根据用户口味推荐搭配、处理特殊备注、管理优惠规则

特点：工具和规则分离。MCP Server 可以被多个 Agent、多个场景复用，Skill 定义具体的业务玩法。适合需要对接外部系统的场景。MCP Server 最大的优点在于分离干净，且工具层可以被多个项目复用。

但说实话，现在 MCP 用的并不多，它适合企业级别的应用开发，个人业务或者小企业业务最好还是走 SKill+CLI的路线。因为 MCP 服务的维护也是一个难点。

形态四：代码骨架 + Skill（工程化）

当系统复杂到一定程度，全靠 Skill 里的规则来指导 Agent 干活，就会变得不稳定、效率低。这时候需要把确定性的东西下沉到代码里，把真正需要判断的地方留给 Skill 和大模型。

这就是「代码做骨架，Skill 做灵魂」。

比如胶囊系统（后面要开发的）： - 代码骨架：抓取文章、建文档、更新索引表、去重判断、状态流转……这些机械的、确定的操作，全部写成 Python 函数/模块 - Skill 灵魂：判断文章价值、归类到哪个主题、观点怎么融合、主题怎么演化……这些需要理解和判断的，留给 Skill

Agent 怎么调用这些代码？直接调用 Python 函数或脚本就行，不需要包一层 CLI。当然这取决于你的需求，大多数情况下没有必要封装成 CLI（取决于 Python 代码是否需要反复复用）。

比如，如果你想直接在 Bash 里输入命令执行这些代码，你可以在代码骨架外面再包一层 CLI。但 CLI 只是「人的接口」，不是必须的——对于 Shell Engineering 来说，核心是代码骨架，不是命令行界面。

两种调用方式的对比：

方式一：直接调用              方式二：通过 CLI 调用

Skill                         Skill
  │                             │
  ▼                             ▼
Python 函数/模块              CLI 命令
                                  │
                                  ▼
                                Python 函数/模块
                               （CLI 只是包装）

左边更简洁，Agent 直接调函数，少一层中转。右边多了一层 CLI 外壳，但换来的是可以在终端里手动执行，也方便多个项目共享同一套命令。大多数时候左边就够了，只有在需要这些额外能力时才走右边。

特点：稳定性好、效率高、可测试。确定性的东西都下沉到代码了，大模型只负责真正需要判断的地方。适合复杂系统、团队内部使用、或者对稳定性要求较高的场景。

个人经验，这是最值得探讨，应用最广泛的一种形态。如果你的业务比较复杂，优先参考这种形态。

形态五：完整应用 + Skill（最重）

如果你要做面向普通用户的产品，用户不一定喜欢和 Agent 对话，也不一定知道 Hermes 是什么。那你可以做一个完整的应用——有前端界面、有后端服务，用户打开网页就能用。

但后端的核心智能，仍然是调用超级 Agent 来完成的。你的应用只是套了个壳，把交互做友好，把流程串起来，真正的理解和判断还是超级 Agent 在做。

比如一个在线知识管理产品，用户丢链接进去，后台调 Hermes 处理，处理完展示在网页上。用户感知不到 Hermes 的存在，他只看到一个好用的知识库工具。

特点：用户体验最好，最像传统产品。但开发成本也最高，已经接近传统应用的开发量了。

2.5 怎么选哪种形态

根据你的场景和用户来选：

没有对错，只有适不适合。

很多时候我们的项目也会逐步演进——先做个纯 Skill 自己用，感觉稳定后可以加模板整理成完整业务；继续扩展功能，系统复杂了可以沉淀代码骨架，最后做大了做完整产品。从 1 到 5，逐步变重。

2.6 和 Harness Engineering 到底有什么不一样

很多人容易把 Shell Engineering 和 Harness Engineering 搞混。确实，两者都是"套壳"，但套的对象完全不一样。

• Harness Engineering：给模型套壳。从裸模型出发，加上工具系统、记忆系统、规划能力，把模型变成一个能用的 Agent。Claude Code、Cursor Agent、Codex，本质上都是模型层的 Harness。

• Shell Engineering：给超级 Agent套壳。从现成的超级 Agent 出发，加上业务规则、数据结构、领域知识，把通用 Agent 变成你的垂直业务系统。

层次不一样。一个在模型层，一个在 Agent 层。

你的业务系统（Shell）  ← Shell Engineering 在这一层
        |
        v
超级 Agent（Hermes / Claude …）
        |
        v
大语言模型（LLM）          ← Harness Engineering 在这一层

2.7 一句话总结

Shell Engineering 不是"必须做成什么样"，而是"你的核心价值是不是建立在超级 Agent 之上"。

形态可以千变万化——可以是一份 Skill，可以是一个 MCP Server，可以是一个 CLI 工具，也可以是一个完整的 Web 应用。这些都不重要。

重要的是：超级 Agent 是内核，你做的是外层的业务壳。没有内核，壳就只是个空架子。

理解了这个本质，下一节我们来看一个更工程化的做法：怎么用代码做骨架、用 Skill 做灵魂，把 Shell 做得既灵活又稳定。

2.8 ■ 学点英语