给超级 Agent 套上业务壳HERMES & AGENT ENGINEERING · 课时 01

1.1 一个容易被忽略的选择

很多人一想到做 Agent，第一反应就是：我要选一个框架，LangChain 还是 AutoGPT？我要接哪个模型？我要自己做工具调用、记忆系统、规划模块。

相信我，类似 LangChain 或者 LangGraph 这样的框架，对于绝大多数开发者可能根本是用不到的。

很少有人在开发 Agent 前会先问一句：我真的需要从头做一个 Agent 吗？

我们来算一笔账。做一个能用的 Agent，你至少要搞定这些事情：模型接入、上下文管理、工具调用、错误重试、记忆系统、多轮对话规划、输出解析、安全边界……这些还只是基础设施，跟你的业务一毛钱关系都没有。等你把这些都搭起来，可能一两个月过去了，业务逻辑还没开始写。

而另一边，像 Hermes、Claude Code、OpenCode、ChatGPT 这样的超级 Agent 已经做得相当成熟了。它们有完整的工具系统，有稳定的记忆机制，有经过大量验证的规划能力，甚至连错误处理和重试策略都给你做好了。你直接用它们做底座，省下来的时间全部可以花在真正重要的地方——你的业务逻辑上。

换一个角度，类似 Hermes 这种超级智能体，本身就是一个很好的基座，我们可以考虑优先在它的基础上进行我们的业务开发，而不是再造一个几乎可以 100%肯定不如 Hermes 的Agent。

这就是 Shell Engineering（壳工程）的核心思路：不从头造 Agent，而是给已有的超级 Agent 套一个业务外壳，让它变成专属于你的垂直系统。

后面的实战章节会把 Shell Engineering 项目简称为 SE 项目。这里的 SE 专指 Shell Engineering，不是传统工程领域的 Systems Engineering，也不是 Software Engineering。

一个很容易理解的例子，以前在非 LLM 时代，当你去开发一个网站时，你第一个想法会是从 HTTP协议 开始开发吗？

肯定不是。你最先的想法一定是寻找一个优秀的开源框架，比如 SpringBoot 或者 Flask，在它的基础上进行自己的业务开发。

在 LLM 时代，这一点依然没变。只不过我们应该把Web 框架换成一个 超级 Agent。

1.2 什么是 Shell Engineering

不是什么，是什么

先澄清一下，Shell Engineering 不是什么新技术，也不是什么新框架。它是一种开发范式，一种选择。

业界有一个概念叫 Harness Engineering（笼具工程），讲的是给裸模型套上一层工程外壳，让模型从"会回答问题"变成"能执行任务"。Claude Code、ChatGPT、Cursor Agent 这些工具，本质上都是模型层的 Harness。

Shell Engineering 则是在更上一层。它的底座不是裸模型，而是一个已经具备完整能力的超级 Agent。你不需要关心模型怎么调用工具，也不需要设计 Agent 的记忆系统，因为这些机制超级 Agent 已经具备了。你要做的，是在这个 Agent 的外面，再套一层你自己的东西：

• 你的业务数据结构
• 你的工作流规则
• 你的领域知识
• 你的存储方案
• 你的交互入口

把这些东西打包在一起，就形成了一个"壳"。壳里面的大脑还是超级 Agent，但壳的形状、用途、工作方式，完全是你定义的。

+------------------------------+
|  你的业务系统（胶囊、视频生成……）   |   <-- 壳（Shell）
|  - 数据结构                    |
|  - 工作流规则                  |
|  - 领域知识                    |
|  - 存储方案                    |
+------------------------------+
           |
           v
+------------------------------+
|  超级 Agent（Hermes / Claude …）   <-- 内核（Kernel）
|  - 模型推理                    |
|  - 工具调用                    |
|  - 记忆系统                    |
|  - 规划能力                    |
+------------------------------+
           |
           v
+------------------------------+
|       大语言模型（LLM）         |
+------------------------------+

三层结构：模型在最底下，超级 Agent 在中间，你的业务壳在最上面。大多数人一上来就想从最底层开始做，而 Shell Engineering 告诉你：从最上面那层业务开始即可，其他能力，复用超级 Agent 的能力即可。

一个现成的例子：自动化视频系统

上一章做的 logamee-auto-video 就是一个典型的 Shell Engineering 产物。

你回想一下，那个系统里我们写了什么？我们没有写任何 Agent 的核心逻辑——没有写工具调用，没有写规划模块，没有写记忆系统。这些全部都是 Hermes 自带的。

我们写的是： - 一套文件结构（article.md、storyboard.md、slides/ 目录……） - 一组 Skill（告诉 Hermes 每一步该怎么做） - 一个工作流（从文章到分镜到切片再到视频） - 一些质量校验规则

这些东西加起来，就是一个"壳"。它把 Hermes 这个通用的超级 Agent，变成了一个专门做自动化视频的垂直系统。

你甚至可以把它想象成一个 App。Hermes 是操作系统，你的视频系统就是跑在上面的一个 App。操作系统负责管进程、管文件、管硬件，App 只负责自己的业务逻辑。这个比喻不一定准确，但感觉是对的。

1.3 为什么优先选 Shell Engineering

开发成本差一个数量级

我们来对比一下两种路径。

路径一：从头开发一个 Agent。

你需要： - 选框架（LangChain / LangGraph / 自己写） - 接模型（GPT / Qwen / 本地模型） - 设计工具系统（函数调用、权限控制、错误处理） - 做记忆系统（短期记忆、长期记忆、向量检索） - 做规划模块（任务分解、反思、重试） - 做输出解析（JSON 提取、格式校验） - 处理各种 edge case（模型幻觉、工具失败、上下文溢出） - 最后，才轮到写你的业务逻辑

这一套下来，少说也要几个资深工程师搞几个月。而且搞出来的东西，稳定性和能力上限大概率还不如现成的超级 Agent。

路径二：Shell Engineering。

你需要： - 选一个超级 Agent 做底座（Hermes / PI Agent / OpenCode / ChatGPT） - 设计你的业务数据结构 - 定义工作流和规则（用 Skill、用配置文件、用自然语言描述都行） - 搭存储和交互入口（飞书、Notion、数据库……随便什么） - 让超级 Agent 按你的规则去执行

业务逻辑之外的工作量，大概是路径一的十分之一。而且你用的是经过千锤百炼的超级 Agent，能力上限和稳定性都高得多。

能力复用，而不是重复造轮子

超级 Agent 最厉害的地方，不是它能调用工具，而是它已经积累了大量的"常识"和"工程直觉"。

比如 Hermes 知道： - 改代码之前先读文件 - 命令失败了要看错误信息 - 大任务要拆成小步骤 - 用户的需求模糊时要追问 - 改完东西要验证 - 出了问题要回滚

这些东西，你自己做的话，每一条都要写一堆规则和 prompt。而且你写的规则，大概率还不如超级 Agent 做得好。因为超级 Agent 是在海量真实场景里训练和打磨出来的，你一个项目遇到的 edge case，可能还没有它一天遇到的多。

Shell Engineering 的妙处就在于，这些能力你全部可以直接复用。你不需要重新教 Agent 怎么干活，你只需要告诉它你要干的是什么活。

企业实践已经验证了这条路

不要觉得这是一个"玩具思路"。现在很多企业已经在这么干了。

我知道的几家公司，直接把 Hermes 部署到生产环境里，然后在 Hermes 上面做业务集成。客服系统让 Hermes 去查工单、回客户；运营系统让 Hermes 去生成报告、更新数据；研发团队让 Hermes 去处理 bug 单、写测试用例。

他们不是没有能力自己做 Agent，而是算了一笔账：自己做一个 Agent，投入大、周期长、风险高，而且做出来的东西还不一定（可以说几乎 100% 不会）比 Hermes 好用。直接用 Hermes 做底座，几个星期就能上线一个业务系统，成本是自研的几分之一。

这不是偷懒，这是工程上的理性选择。

1.4 什么时候 Shell Engineering 不够用

当然不是所有场景都适合 Shell Engineering。有些情况下，你确实需要自己从头做。

第一种情况：你对性能和延迟有极致要求。

超级 Agent 是通用的，通用就意味着它不可能在每一个垂直场景都做到最优。如果你需要毫秒级响应，或者你的任务非常简单、调用量极大，那专门做一个轻量 Agent 可能更划算。

第二种情况：你的业务有极强的私密性，不能让任何外部系统接触数据。

这种情况你可能连云模型都不能用，必须本地部署。那自然也谈不上用现成的超级 Agent 了。

第三种情况：你要做的就是 Agent 基础设施本身。

如果你要做的就是一个新的 Agent 框架，那当然要从头写。Shell Engineering 是给做应用的人用的，不是给做基础设施的人用的。

但我说实话，99% 的人做的 99% 的 Agent 应用，都不在这三种情况里。大多数时候，我们只是想做一个能帮干活的 Agent，或者一个解决具体业务问题的垂直系统。这种情况下，Shell Engineering 几乎总是更优的选择。即使是企业也应该优先考虑用超级 Agent 作为底座，而不是自己从头写一个，尤其是中小企业。

1.5 怎么判断该用哪种方式

给你一个简单的判断框架，三个问题依次问自己：

第一个问题：我的核心价值是在 Agent 能力本身，还是在业务逻辑和数据结构？

如果答案是业务逻辑和数据结构，那么应该选 Shell Engineering。

第二个问题：我愿意花多少时间在"让 Agent 能干活"这件事上？

如果答案是"越少越好，我想尽快验证业务想法"——选 Shell Engineering。

第三个问题：我的应用有没有超级 Agent 搞不定的特殊需求？

如果答案是"没有，Hermes/ChatGPT 的能力完全够用"——选 Shell Engineering。

三个问题都指向同一个方向，那基本就不用犹豫了。

1.6 小结

Shell Engineering 不是一个抽象的概念，它是一种可以直接落地的开发方式。接下来我们会用两章的篇幅来展示它的实际应用：

• 上一章的自动化视频系统，是 Shell Engineering 的第一个完整案例
• 下一章的胶囊系统，是 Shell Engineering 的第二个，也是更复杂的案例

在那之前，我们还有两个问题需要回答：

1. 一个 Shell Engineering 做出来的产品，到底长什么样？交付给用户的是什么东西？
2. 纯 Skill 的方式不稳定，有没有更工程化的做法？

接下来两节我们就来聊这两个问题。

1.7 ■ 学点英语