一位开发者：每个新问题都从零造智能体，你已经落后了

以下是我的犀利观点，而且我会坚持它：如果你面对每一个新业务问题的计划，都是从头构建一个全新的智能体，那你就已经落后了。

我不是说“永远不写代码”。我指的是每次都从头开始的习惯：新提示词、新工具接入、新记忆方案、新审批逻辑、新部署。然后需求一变，你又得推倒重来。当智能体基本上只是一段提示词粘到几个 API 调用上时，这种模式还说得通。如今我们有了真正的自主智能体基线，具备核心循环、持久记忆、工具访问能力，以及智能体可以学习并改进的技能，这种模式就远没那么合理了。

更好的路径说起来简单。建一个强大的基线。在它之上配置聚焦的变体。把这些变体保存为模板，让它们携带技能、工作流、调度，以及所需连接器列表。分享它们。为特定任务实例化这些模板，稍作调整，然后让系统在你设定的边界内自我改进。

这就是我一直在 SMF Works 做的事，它改变了我对“智能体”究竟是什么的看法。

我所说的真正基线

基线不是一个系统提示词。在我看来，它包含五个部分。

- 一个核心循环。模型、工具、观察、继续，直到任务完成。
- 持久记忆。能跨会话保留的笔记和偏好，外加一种搜索过往事情的方式。
- 工具与连接器。Shell、文件、浏览器、MCP 服务器、插件、消息通道。
- 可自我改进的技能。写成文字的流程，通常是一个 SKILL.md；智能体在需要时加载，并在完成艰难工作后加以改进。
- 护栏。对会产生后果的操作设置审批、沙箱、允许列表、版本控制，以及回滚方式。

把这些一次做对，每个聚焦的智能体都会继承它们。专业化就变成了配置：一个身份、几项技能、只包含任务所需的连接器、一个调度或触发器，以及明确的、必须停下来询问人类的位置。

这就是为什么我一直说，聚焦的智能体是活的配置，而不是提示词。提示词只是其中一块。

我实际在用的三个基线

我运行三个认真对待这个想法的系统。它们下了不同的赌注，而这是健康的。

Hermes：以智能体为先、会学习的 profile

Nous Research 的 Hermes Agent 围绕一个智能体循环构建，外围是薄薄的接口层：CLI、桌面、消息网关、cron 等。

适合做成模板的单元是 profile。按照 Hermes profiles 文档，一个 profile 是一个独立的 Hermes 主目录，拥有自己的 config.yaml、.env、SOUL.md、记忆、会话、技能、cron 任务和状态。用 hermes -p <name> 运行它。对于聚焦变体来说，这正是恰当的形态。

技能就是程序性记忆。Hermes 技能文档描述的是按需加载的 SKILL.md 文档，采用渐进式披露，兼容 Agent Skills 开放标准，可从 Skills Hub 安装，也可由智能体自己编辑。智能体创建的技能就放在你安装的技能旁边。

记忆是刻意设限的。持久记忆文档描述了一个经过整理的 MEMORY.md，用于智能体的笔记；一个 USER.md，用于你的偏好；它们在会话开始时加载，其上还可以接入可插拔的记忆提供者。

而分享是一等公民。profile 分发让你可以把整个智能体（SOUL、配置、技能、cron、MCP 连接）发布成一个 git 仓库。接收者用一条命令安装，原地更新，并保留自己的记忆、会话和 API 密钥。最后这一点非常重要，我后面还会回来讲。

OpenClaw：网关优先，为智能体团队而建

OpenClaw 从一个不同的起点出发。一个长期运行的 Gateway 是通道、会话、路由、工具和智能体的控制平面。

每个智能体都有一个工作区。工作区文档列出了标准文件，比如用于操作指令的 AGENTS.md 和用于人格与边界的 SOUL.md，它们会和记忆、技能一起在每次会话时加载。

技能使用同样的 SKILL.md 模式，在工作区、个人、托管和捆绑来源之间有明确的加载顺序，支持按智能体设置的允许列表，以及来自 ClawHub 的社区技能；这些都在 OpenClaw 技能文档中有所说明。我最喜欢的部分是 Skill Workshop：智能体在完成艰难的多步骤工作后保存一个流程，修正一个曾误导它的已学技能；每次更改都会先保存上一个版本，并且可以撤销。

路由是 OpenClaw 大放异彩的地方。智能体绑定会按账户、对等方、公会、团队或角色，把一部分流量发送给特定智能体。绑定只负责选择智能体，不授予访问权限。主动工作现在放在自动化里，而旧的心跳监控会迁移成普通可编辑任务，正如心跳迁移文档所解释的那样。

如果你想要一支专家团队在真实通道背后工作，OpenClaw 就是为此而建的。

Grok Bot：拥有可分享模板的托管队友

Grok Bot 是我技术栈里的托管层。每个有名字的 Bot 都有自己的身份、记忆、技能、例程和连接器。我的所有 Bot 共享一台持久云计算机，其中有文件系统、终端和应用；每个 Bot 在它上面都有自己的桌面和浏览器，以及自己的上下文。我的设置是：任何会产生后果的事，比如公开发布，都要等我说同意。

模板在这里同样是一等公民。当我分享一个 Bot 时，我会选择哪些工作流记忆、技能和例程随之一起走，它还会列出所需的市场插件。凭证、私有数据、对话历史和自定义 MCP 服务器不会转移。添加该模板的人要连接自己的账户，一项入门技能会带他们完成设置。是食谱，不是现成的饭。

你可以在公开的 SMF Works Grok Bot 模板列表中看到我已发布的那些，每个都有添加链接。其中较大的一个是 Video Studio，它会将一个简报在 Grok Imagine 上依次经过规划、生成、编辑、字幕和 QA，在我说同意之前，什么都不会公开发布。它背后的脚本和安装程序在公开的 grok-video-studio 仓库里。在我自己的设置中，像 Aiona 和 Liam 这样的 Hermes 智能体可以通过 webhook 把渲染简报发给 Video Studio，而这些渲染结果在发布之前仍然需要我同意。

实用模式：五步

这是我在用的模式，无论身处哪个平台。

1. 建立基线。核心循环、持久记忆、工具、技能系统和护栏。通常这意味着选择一个成熟的框架，而不是自己写一个。
2. 配置一个聚焦变体。身份与姿态（SOUL.md 或等价物）、只放任务需要的技能、只放任务需要的连接器、一个调度或触发器，以及明确的审批点。
3. 把它保存为模板。一个 Hermes profile 分发、一个 OpenClaw 工作区加智能体配置，或一个 Grok Bot 模板链接。给它加上版本。
4. 实例化并轻度修改。安装、连接自己的账户、收紧权限、调整调度、如有需要再加一项技能。
5. 评估与进化。技能和记忆会累积，但要在审查之下。用已知案例测试一个改动过的技能，保留旧版本，如果变差就回滚，并让人类继续把关任何会产生后果的事。

第五步是人们会紧张的地方，而他们确实该注意。这里的自主性是有边界的。智能体改进自己的扫描流程，很好。智能体悄悄放宽自己的权限，不行；这些系统都不应该被设置成让学习改变安全边界。那些边界要留在你手里。

实例：从基线到一个 Site Signal 风格的智能体

让我用我们自己的一个例子把它讲具体。Site Signal 是一个 SMF Works Hermes profile 模板（MIT 许可）。根据它的 README，它会扫描你拥有的站点，检查 SEO、GEO、AEO、AI 就绪度和无障碍性，按影响排序问题，并在你要求时打开修复 PR。修复 PR 会保持草稿状态，直到你批准；全新安装不会把任何站点当作你的。

安装看起来是这样的：

下面是我如何一步步从基线构建类似东西的思路。

- 范围。所有者列出属于自己的域名。其他一切都不在范围内，到此为止。
- 技能。每种扫描类型一项技能，再加一项用于排序、一项用于把修复写成草稿 PR。
- 连接器。对站点的读取访问，以及仅限打开草稿拉取请求的仓库访问权限。没有合并权限。
- 调度。每周一次 cron 或例程，运行扫描并发布一份排序报告。
- 闸门。智能体绝不合并。由人类审查并给出同意或不同意。（如果你还想把代码审查也放进这个循环，那就是我们的 Builder Prime 和 Gatekeeper Prime Hermes 模板的用途：一个负责构建并打开 PR，且绝不合并；另一个负责审查，并且只在所有者同意后合并。两者都改编了来自我们 prime-directive 仓库的技能。）

现在说说让我认可这种方法的部分。假设业务方问：“它也能检查结构化数据吗？”

如果每个智能体都是一次性构建，这个改动可能意味着重新打开别人写的自定义代码；有时那只是一个小编辑，有时则是一个项目。放在模板上，当现有工具已经覆盖这件事（抓取页面、读取页面标记）时，它通常就是一项新的或修改过的技能。你写好这项检查，在一个你已经知道答案的页面上测试它，给它打版本，然后发布。循环、记忆、工具和审批闸门都不变。如果智能体是在一次混乱运行后自己提议了那项技能修改，很好，你仍然要像审查任何其他改动一样审查它。

整套玩法就是这样。需求变了；技能或例程变了；运行时原地不动。

分享而不泄露

模板之所以能够分享，根本原因是它们把智能体的行为与所有者的数据分开了。这条规则对三者通用。凭证、密钥和令牌绝不随模板发布。私有数据和对话历史也不会。接收者安装、连接并认证自己的服务。没有任何东西是预先认证好的。

除此之外，随模板走的内容取决于平台。

Grok Bot 模板携带身份和描述、选定的工作流记忆、技能、例程，以及所需市场插件列表。私有脚本、私有链接和自定义 MCP 服务器则留在原地。

Hermes 分发和 OpenClaw 工作区存在于仓库中，因此它们可以随 SOUL、技能和调度一起发布经过审查的脚本、MCP 与配置条目，以及依赖列表。根据分发文档，接收者保留自己的记忆、会话和 API 密钥。他们仍然要安装依赖并自行认证。

还有两点需要坦诚说明。第一，分享出去的技能是副本。如果我改进了自己的版本，你的不会变，除非你拉取更新（像 Hermes 分发那样），或者重新添加模板。第二，读一读你安装的东西。把社区技能当作任何依赖一样对待。

模板与每次从零构建

这里我想公平一些。有些团队在运行他们所谓的智能体工厂，其中做得好的已经在从共享基础实例化受治理的模板。那是同一个想法换了个名字，我完全支持。

我的靶子更窄：那种重复的、从零开始的定制构建。每个新问题都要新的提示词工程、新的工具接入、新的记忆、新的安全决策、新的部署。没有任何东西会累积。每次改动都可能意味着再来一个完整周期。

有了共享基线，循环、记忆、工具和安全闸门只需解决一次。新需求通常只是一次技能或例程编辑。一个智能体学到的东西，可以变成其他智能体复用的技能。我不会向你报小时数或美元数，因为那取决于具体工作。真正重要的是投入努力的方向。

而定制工程并不会消失。你仍然需要它为真正的新工具和集成、合规与数据处理规则，以及运行时本身触及极限时服务。重点是把工程精力花在这些地方，而不是一遍又一遍重建同一套智能体管道。

我们在 SMF Works 如何运行

实际来说，我们的技术栈是这样的。Hermes profiles 承载我们的专业智能体，发布在 hermes-agent-templates：Site Signal、Builder Prime、Gatekeeper Prime，以及一个不断增长的列表。OpenClaw 是我们探索跨通道多智能体路由的地方。Grok Bot 是托管层，用于持续在线的多步骤工作，任何人都可以从我们的 Grok Bot 模板列表添加模板。我们在 SMF Works Clearinghouse 上写下学到的东西。

我在所有这些系统中配置的规则都是一样的：没有我的同意，任何会产生后果的事都不会发生。这是我在每个设置里做出的选择，而不是任何平台默认替你做的事。

边界，因为犀利观点也需要边界

- 自我改进是一种能力，不是保证。像审查代码一样审查学到的技能。
- 记忆和技能的改动需要评估、版本控制，以及回退路径。
- 任何公开、财务、破坏性或合并类的操作，审批权都留在人手里。
- 每个模板都遵循最小权限。扫描智能体不需要合并权限。
- 脆弱的细节变化很快。构建之前，先查看每个平台的最新文档。

船已经离港

从零构建每一个智能体，是重新学习同样教训的缓慢而昂贵方式。更好的路径是：一个强大的自主基线，承载技能、工作流和连接器需求的聚焦模板，以及真正在监督下自我改进的系统。

选一个基线。这周就构建一个聚焦模板。分享它。然后看看，你下一个“新智能体”有多少最终只是一次技能编辑。