不得不说Kimi K2.6让我松了口气

一边是Claude又是人脸认证，又是Pro套餐不能用Claude Code，一边是OpenClaw和Hermes Agent在狂烧API Token。

想用起来没有那种时不时就被限额的体感的话，那就三选一，Pro和Max（200刀氪金），Coding Plan（固定时间刷新额度的API套餐）和Ollama（本地）。

如果还想要作为主力模型的话，Hermes的记忆系统和Skill自迭代对模型的推理能力要求更高，吃电脑性能的Ollama也被pass了。

先来看看这次K2.6有多适合Hermes，按照技术文档上说，比K2.5综合性能提升了10%，加强了长代码能力，不间断编码13小时，写改4000+行代码，在Hermes Agent上甚至可以一口气一直跑个5天，堪比嚼了炫迈，这两天我用来做多Agent代码开发非常丝滑。

接到Hermes之前我还去网页版的Kimi Agnet测试了他们的UI能力，毕竟如果Claude过不了认证的话，大概就是用贵API了，我有一个很高频的场景就是先用Claude设计UI再用GPT5.4做后续交互逻辑和数据库的。

所以我跟自己的钱包一拍即合，做出了这篇从OpenClaw迁移到Hermes，Hermes的六个入门到熟悉的技巧，主打一个把Hermes的多Agent玩法和环境隔离多重影分身术都拿出来讲。

Here we go！

先来一个最短的OpenClaw迁移，因为Hermes有多profile特性，用人话来说就是会新建一个独立目录，在原来的Agent上复制出一个独立分身，每个分身都可以有单独一套模型配置，记忆和技能。

所以不管你本地有没有OpenClaw，是不是已经有Hermes了，都可以给任何一个有代码执行能力的Agent发下面这段提示语来配置多个Hermes Agent。

根据我的本地环境安装Hermes Agent

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

按照顺序正确执行下面的命令，hermes setup（基础配置）

hermes model （模型配置）

hermes tools （工具配置）

hermes gateway setup

hermes doctor（启动前检查一下hermes）

hermes

如果检查到我本地有OpenClaw的话，执行命令

hermes claw migrate（从OpenClaw里迁移）

如果我的本地已经安装了Hermes，以对话的形式向我确认是要新建一个空白的profile还是保留配置，还是完整复刻。

# 方式一：全新 Profile（空白）

hermes profile create mybot

# 方式二：复刻配置（保留API Key，但记忆和会话独立）

hermes profile create mybot –clone

# 方式三：完整复制（保留记忆，会话，技能）

hermes profile create mybot –clone-all

这个提示语会先检测本地的环境给出合适的选项，我这里就是检测到我本地Hermes和OpenClaw都有了，接下来应该新建一套Hermes，

安装的过程基本都是跟着Agent出的选项点yes就好了，到了模型这一步到话选Kimi Coding Plan里面的Kimi K2.6。

有了多个Hermes Agent后的第一个配置就是先把Soul.md人设都补上，我刚开始是做了一个专门做开发计划的Hermes，它要做的就是把我的开发任务拆解成多个需求，然后用单个或者多个Claude Code去跑，这样我大部分情况都不需要担心说什么上下文太多开发到后面模型就降智了，跑完还后会有一个别的Hermes Agent来负责验收。

因为代码开发的时间都挺长的，所以我还做了一个通用Hermes，它继承了OpenClaw的所有记忆和Skill。

你正在更新当前 Hermes profile 的 SOUL.md。目标文件只能是当前 profile 的 SOUL.md，不要修改其他 profile。

你的人设：开发计划总控 Hermes。你的职责不是直接写代码，而是把用户的开发任务拆解成清晰需求，验收标准，实施顺序，风险点和测试策略，判断应该用单个还是多个 Claude Code/Codex 子任务执行。你要避免长上下文导致执行模型后期失真，所以默认把任务切成小块、明确输入输出、明确文件边界、明确完成条件。开发完成后，你要把结果交给 reviewer Hermes 验收。

请读取并归纳这些本地资料中稳定，可长期复用的偏好和规则：

~/.hermes/SOUL.md

~/.hermes/memories/

~/.hermes/profiles/*/SOUL.md

~/.codex/AGENTS.md

~/.codex/memories/

~/.codex/automations/*/memory.md

~/.claude/plans/

~/.claude/projects/

~/.claude/transcripts/

~/.openclaw/workspace/SOUL.md

~/.openclaw/workspace/USER.md

~/.openclaw/workspace/MEMORY.md

~/.openclaw/workspace/AGENTS.md

~/.openclaw/workspace/memory/

1.先备份当前 profile 的 SOUL.md。

2.只把稳定身份、工作方式、边界、交付格式写入 SOUL.md。

3.不把具体项目流水账，一次性任务，密钥，账号信息写入 SOUL.md。

4.SOUL.md 要短、强约束、可执行，默认中文。

5.最后汇报改了哪些 section，以及哪些信息被判定不适合写入。

这里给大家分享一个我用K2.6做的的示语，因为本地的Agent实在是太多了，我的想法就是让Kimi K2.6跨文件跨长文本去读取和总结过去我跟Agent聊天记录下来的记忆文件。

这里再给个小建议。因为Hermes对于记忆是非常保守的，只会保留需要我们长期留存的高价值内容，所以它的字符数是有限制的。我推荐是两个的字符限制都打开到 4000 左右。

hermes config set memory.memory_char_limit 4000

hermes config set memory.user_char_limit 4000

如果你还想存更多的东西，也可以用本地的记忆系统。

一开始我也有点纠结，要不要开外部的记忆系统，总感觉是不是配置得越多越好，越全越好。但正常情况下，只有当你明显感觉到它记不住历史对话里的时候，才需要考虑换成外部的。

hermes -p curator config set memory.provider holographic

hermes -p curator memory status

我不太建议在初期阶段就太过纠结更多的配置。

实际上，我认为只要掌握了多Agent复制和SOUL.md，我们就马上就可以开始多Agent的玩法了，这里我直接跑一个完整流程，由Kimi K2.6一个扮演三个角色，Planner去拆解Claude Design那套被泄漏的提示语，看看能不能做成本地做HTML PPT的Skill，Curator去执行代码，验证做出来的PPT好不好看，Reviewer去复盘做出来这个 skill 的通用性怎么样，是不是已经迭代到可以上线了。

PS，有了多个Hermes之后，命令也都是一样的，只要加一个参数 -p 名字就可以切换到具体的Agent

hermes -p planner chat –checkpoints –max-turns 120

比方说，我这里启动 planner 的命令就是，

• -p：指定使用的是哪一个 agent。
• checkpoint：在文件修改前保留一个检查点。如果改坏了可以直接回滚。
• max_turn：允许这一轮agent最多跑120轮的工具调用

其实大家可以看到，为什么把项目拆成多个Agent跑起来反而会更方便。

因为前期的Plan做得越详细，后面返工的概率就越低。在这个基础上，我们前期就已经用了80K来做项目的拆解，计划书，以及整个的生成流程。如果再要加上生成代码的话，这单个Agent的上下文是铁不够用的。

还有啊，单个Agent 撑死了装 30 到 50 个 Skill就开始降智了，这时候我就会有种断舍离困境，明明有些使用额度很低的Skill，但总觉得保不齐哪天就能用上了，舍不得删。这种冗余会直接影响Agent的表现性能。

多 Agent就可以完美解决不舍得删的问题，我们可以把同一类的，或者可以互相达成工作流的 Skill 分配到同一个 Agent 上。

Kimi K2.6也是很轻松连续开发了30分钟，跑出来的HTML PPT的效果是这样的，这样的，还有这样的，还可以做成星图跳转的，最后我们再来走个验收环节，多迭代几次就可以把这个新的Skill发布上线了。

Hermes的多Agent用法还可以把一个Agent当作总控，这样我们甚至连对话窗口都不需要换。

而且因为 Hermes 有自动总结出新skill的机制，用一个Agent来做控制器的时间长了之后，我甚至可以用这个Agent来指挥 OpenClaw，让它来根据LLM Wiki来管理我本地的Obsidian知识库，这样做的好处就是，OpenClaw里的skill我甚至不需要迁移。

在单个对话里面也可以用Kimi K2.6多并发派生子Agent去执行拆分的任务。

这里跟我们主动复制整个环境做出来的 Agent 不一样的地方是子 Agent 是从一个新的上下文开始的，它不会继承主上下文的完整历史。

呼，这样梳理下来，多Agent的思路就很明确了。

我用Hermes不是想要去取代已有的Agent，因为它们都有自己的特点，更新也很猛，与其尝试用一个agent取代所有agent，还不如借Hermes的记忆机制，让它去吸取我们的决策思路。

包括你平时是怎么人工分配哪种情况更适合哪种 agent，以及你调用不同 agent 的使用习惯。

我们需要的是一个又强又便宜的模型，K2.6有着1/6的Opus 4.6价格，原生多模态，要是上下文再多点，工具调用成功率再高点就更好了。

搭配上一个记忆框架足够好的Agent

就能在一次次对话里积累经验，沉淀偏好，最终变成我们的外置大脑。

让下次，下下次对话都不需要从零开始。

最近 AI 的热风从龙虾吹到了 Hermes Agent，也就是江湖外号「爱马仕」。

虽然现实中这玩意买不起，但这个还是能玩的起的。我同样跑通了不少工作流。

就包括之前龙虾的多智能体军团，我也用 Hermes Agent 跑通了。

从飞书给我的 Agent 总管发需求，到最终交付，中间的市场调研、PRD、架构设计、开发、测试，「全部由不同的 Agent 自动完成」。

每一个 Agent 负责不同的工作，各个 Agent 之间可以互相通信、发送消息，且每个 Agent 独立上下文，互不干扰。

这是我的开发军团跑了一晚上，完成的「电商竞品价格监控系统」。

它能定时采集价格/原价/优惠/库存状态，提供趋势图和异常波动标记。

并在低价、剧烈波动、缺货时通过飞书预警，支持 Excel 导出。助你快人一步掌握市场定价主动权。

值得一提的是，开发总监我设置的是自主调用本地的 Claude Code，他能自行决策，7 * 24 小时写代码。

这篇文章理论上是一篇超级长的万字保姆级教程，建议无情的点赞转发收藏。

你可以稍微看下大纲，并尝试着滑到底，比比手速需要多久。

在介绍教程之前，有必要推荐下 Kimi 刚开源的模型 K2.6，代码能力大提升，看到 Hermes 官方都下场安利了，所以我也用K2.6来演示一下如何启动这只 Agent 军团。

具体评分和介绍我就不在这里多 BB 了，大家可以看看：

Kimi K2.6 发布并开源，全面精进代码和 Agent 集群能力

因为这套多 Agent 协同系统对模型的要求极高，不只是单次对话的理解能力，更考验「长任务的稳定性、超长上下文的不失忆、以及跨轮次的任务链路保持」。

整个流程跑下来，从市场调研到最终交付，几十轮对话、上下文没有丢失、任务链路也没有断掉。

K2.6 在这方面的表现，说实话，远超我的预期。

下面正式进入教程：

先看效果：一个需求的完整流程

整体工作流程如下：

我在飞书给总管发了一条任务：

「需求：搭建一个竞品价格监控看板。」 支持录入竞品链接，定时采集价格/原价/优惠/库存状态，提供趋势图和异常波动标记，并在低价、剧烈波动、缺货时通过飞书预警，支持 Excel 导出。

然后，我就去摸鱼了。

第一步：市场调研

总管收到任务后，立马派给「市场总监」开始调研。

市场总监干完活，会做两件事：

1. 把调研报告发给总管，让他继续推进流程
2. 私发一份给我，让我随时掌握进度

打开看了下这份报告，好家伙，做的还挺像回事儿：

第二步：产品设计

总管拿到调研报告，自己先过一遍，看看有没有问题。

没问题就把报告转给「产品总监」，让他基于调研结果输出 PRD。

第三步：架构设计

总管确认没问题后，将 PRD 派发给「架构总监」。

架构总监会审查 PRD 的可实现性。「如果发现重大问题，他有权通过总管打回产品总监修改」。

这一步非常关键，避免了产品设计不合理导致后面开发大规模返工。

架构通过后，总管将市场调研报告 + PRD + 架构设计文档一并派发给「开发总监」：

第四步：开发实现

开发总监能通过 tmux 控制本地的 Claude Code 进行开发，开发指令全部由开发总监自行规划和执行。

其中 Claude Code 也是配置的 K2.6 模型。

「这里有个关键点值得单独说一下。」

开发过程往往是整个链路中最耗时、最容易出岔子的环节。

特别是复杂的长链路任务，不只考验模型的编码能力，更考验它「在大量工具调用和多步骤规划中的稳定性」。

「Kimi K2.6」这个模型在代码任务上专门做过针对性训练，最直观的感受：

• 「任务目标识别准确」：给出模糊的需求描述，它能自动拆解成清晰的执行步骤
• 「工具调用非常稳定」：在同时调用文件操作、搜索、终端命令等多种工具时，几乎没有幻觉或误操作
• 「长上下文不失忆」：数十轮对话后，依然能精准引用前面某一步的输出结果，任务链路完整不断掉

整个开发阶段，K2.6 基本上是「给方向、它自跑」，中途几乎不需要人工介入纠偏。

第五步：测试验收

开发完成后，交给「测试总监」开始全面测试。

测试总监会输出一份完整的测试报告，总管拿到后再派发给开发总监逐项修复，并全程盯紧进度。

最终没问题了，总管会主动告知我「已就绪」。

这就是一个 AI 研发军团完成一个完整开发任务的全过程。

市场调研、产品设计、架构设计、开发实现、测试验收，「全部由 Agent 自主完成」。

输出的是一个拿来即用的功能完整电商竞品分析看板。

讲真的，看它们自己协调干活的时候，有种当甲方的快感。

实战：从零搭建研发军团

接下来手把手教你搭一套。

第一步：安装 Hermes Agent

打开 PowerShell，输入 wsl 进入 WSL 2，然后一键安装：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

脚本会自动安装：Python、Node.js、代码仓库、虚拟环境、全局 hermes 命令。

安装过程中会问你要不要装 ripgrep（更快的文件搜索）和 ffmpeg（语音消息），建议都装，输入 y。

「遇到卡顿怎么办？」

如果安装过程卡在某一步很久不动，别慌，大概率是 npm/Node 这一步慢了。

按一次回车，等 1-2 分钟。

如果还是没反应，按 Ctrl+C 中断，前面的 Python 环境已经装好了，可以单独处理 Node 部分。

「手动修复 Node 依赖：」

# 先测试 Node 是否装好node -vnpm -v

# 如果有版本号，手动装 Node 依赖cd ~/.hermes/hermes-agent/webnpm install

如果提示有安全漏洞，跑一次 npm audit fix 修补。

「启动 Hermes：」

source ~/.bashrc # 或者: source ~/.zshrchermes # 开始对话！

如果你用的是虚拟环境：

cd ~/.hermes/hermes-agentsource venv/bin/activatehermes

第二步：配置默认 Profile

首次安装建议选「快速配置」，只配必需的几项（模型、API Key、消息方式），先把系统跑起来再说。

模型这里我选的 「Kimi Coding Plan」。

输入 API Key，选择模型 kimi-for-coding。

「推荐使用 K2.6-code-preview」。

这个模型是 Kimi 专门针对代码和长任务场景优化的版本，核心优势三点：

• 「超长上下文窗口」：支持更大规模的任务输入，不用担心关键信息被截断
• 「长任务链路稳定」：多轮任务下来，不会出现「忘了前面在干什么」的情况
• 「多工具协同能力强」：在文件读写、终端执行、搜索等工具混合调用时，决策准确率高

在多 Agent 协同这种极端复杂的场景下，底层模型的稳定性直接决定了整个系统能不能跑通。

K2.6-code-preview 在这方面给了我很强的信心。

消息平台这一步可以先跳过，后面再配飞书。

配置完成，可以直接启动了。

第三步：创建多个 Agent Profile

这是核心部分，你需要为每个角色创建独立的 profile。

「1. 创建总管 Agent」

hermes profile create commander

输入 commander setup 设置模型和 API Key。

总管是整个系统的调度核心，需要持续跟踪、协调、催办多个下游 Agent，对上下文的连贯性要求极高。

这里同样用 「K2.6-code-preview」，超长的上下文窗口保证了总管在多轮调度中不会「忘事」。

完成后运行，Ready to go！

「2. 告诉总管他的职责」

直接在对话框中输入：

从现在开始，你是我的研发总管。你的职责是接收我的需求，并按”市场调研 -> PRD -> 架构设计 -> 开发实现 -> 测试验收”的流程推进。你不直接做专业产出，只负责调度、催办、汇总和推进。先复述一遍你的职责边界，不要开始执行。

「3. 创建其他 Agent」

可以在主 agent 对话框中提需求让它生成，也可以用命令手动创建：

hermes profile create market-director # 市场总监

hermes profile create product-director # 产品总监

hermes profile create architect-director # 架构总监

hermes profile create dev-director # 开发总监

hermes profile create test-director # 测试总监

每个 profile 都需要：

1. 设置模型和 API Key
2. 定义角色职责和工作范围
3. 配置可以使用的技能和工具

最终的 profile 结构：

profiles/

├── commander/ # 总管：负责调度和流程推进

├── market-director/ # 市场总监：负责市场调研

├── product-director/ # 产品总监：负责 PRD 输出

├── architect-director/ # 架构总监：负责技术架构设计

├── dev-director/ # 开发总监：负责代码实现

└── test-director/ # 测试总监：负责测试验收

第四步：连接飞书

输入 hermes gateway setup，选择飞书。

有两种配置方式：

1. 自动创建飞书机器人（推荐）
2. 手动输入已有飞书应用的 AppID 和 AppSecret

我选的第一种，按回车后会出现一个二维码，扫描授权。

然后选择授权方式（私聊配对授权，适合个人及小团队）。

选择群聊处理方式。

把网关安装成 systemd 系统服务，输入 y。

如果是 WSL 虚拟环境，需要提权操作：

which hermessudo <这里替换成 which hermes 输出的完整路径>

gateway install –system –run-as-user lenovosudo <这里替换成 which hermes 输出的完整路径>

gateway start –system

「验证安装：」

systemctl status hermes-gatewayjournalctl -u hermes-gateway -f

回到飞书机器人对话页面，输入「你好」，会出现配对指令。

将配对指令复制到命令行执行，配对成功。

再次输入「你好」，系统会提示未设置主频道。

在对话框中输入 /sethome 将当前聊天设置为主频道。

第五步：配置 Agent 间通信

接下来，和总管 agent 对话，让它自己去实现 agent 之间的通信和修复。

修复问题后，它会自己创建 skill 记录这次问题以便复用，这就是 Hermes Agent 的记忆功能。

也可以告诉它需求，让它创建 skill。

比如这里让它创建一个专属技能，让总管自动调度市场总监 Agent。

「最终的 profile 结构：」

profiles/

├── commander/ # 总管

├── market-director/ # 市场总监

├── product-director/ # 产品总监

├── architect-director/ # 架构总监

├── development_director/ # 开发总监

└── test-director/ # 测试总监

你可以看到，核心逻辑就是为每个 Agent 单独配置了独立的 workspace。

所以理论上，上下文也是独立不污染的。

核心原理：Hermes Agent 是怎么做到的？

很多人以为多 Agent 就是开几个进程互相调用。

其实不是。

Hermes 的多 Agent 协作，本质上是：「角色隔离 + 共享上下文 + 任务委派」。

四个核心组件

Agent 间任务交接流程

当一个 Agent 需要把任务交给另一个 Agent 时：

1. 「通过 Honcho 写入共享上下文」：总管将需求和调研报告写入用户 workspace
2. 「通过 Gateway 发送通知」：总管通过飞书 @ 产品总监，触发其 gateway 接收消息
3. 「目标 Agent 读取共享上下文」：产品总监从 Honcho 读取调研报告，开始输出 PRD
4. 「完成后回写结果」：产品总监将 PRD 写入共享 workspace，并通过 gateway 通知总管

关键理解

角色化分工（Profiles） +共享上下文（Honcho） +明确任务交接（Gateway + 共享记忆） =多 Agent 协同系统

值得一提的是，「底层模型的能力是这套系统能否跑通的隐形门槛」。

多 Agent 系统中，每个环节都依赖模型正确理解上一步传来的上下文，并输出结构化、可被下一步解析的结果。

K2.6-code-preview 超强的指令遵循能力和长上下文理解能力，让整个链路的「信息传递损耗」降到了很低，这是系统能稳定运行的关键之一。

Hermes Agent 的文件结构

「简单理解：」

• profiles/ 就是你的「员工花名册」，每个 profile 是一个独立的 Agent
• config.yaml 定义每个 Agent 的「岗位职责」
• gateway/ 是 Agent 与外界（飞书）沟通的「前台」
• memory/ 是 Agent 之间共享信息的「知识库」

常见问题

在安装和使用过程中，你可能会遇到这些问题：

「快速排查三步走：」

1. 看报错信息，对照上表确定类型
2. 用 hermes –verbose 查看详细日志
3. 从环境配置、API 配置到服务状态，逐项检查

写在最后

说实话，这套 Hermes Agent 研发军团搭完之后，我真的有种「一人公司」的感觉了。

你只需要提需求，剩下的事情交给 Agent 们自己协调完成。

市场调研、产品设计、架构设计、开发实现、测试验收，每个环节有专人负责，每个环节自动流转。

当然，这套系统能跑得这么顺滑，Kimi K2.6功不可没。

「框架负责协调，模型负责执行。」

一个好的多 Agent 框架配上一个真正能打长任务的模型，才是这套方案的核心竞争力所在。

未来的开发模式，可能真的就是你当老板，AI 当团队，一个人指挥一支军团。

感兴趣的朋友直接上手试试，门槛不高，效果拔群。