为什么我不再让一个 Agent 做所有事情？Hermes 多 Profile 实战

前两篇，我们分别解决了两个问题。

第一篇，把 Hermes 从一个聊天机器人，改造成了一个可以 24 小时持续工作的 AI 工作台。

第二篇，把多个 Agent 之间的协作，从"群聊接话"变成了基于 Kanban 的任务管理，让任务拥有状态、负责人、交接记录和恢复能力。

很多人看到这里，会自然产生一个想法：

既然 Hermes 已经这么强了，那是不是把所有能力都放进一个 Agent 就够了？

刚开始，几乎所有人都会这么做。

写代码找它。

写文章找它。

查资料找它。

整理会议找它。

跑脚本找它。

处理消息还是找它。

短期来看，这种方式确实效率很高。

你只需要记住一个入口，一个聊天窗口，一个 Agent。

但随着任务越来越多，你会发现另一个问题：

真正开始变复杂的，不是模型，而是 Agent 自己。

它既要记住代码项目的规则，又要保持写作风格；既要处理运维脚本，又要管理研究资料；工具越来越多，记忆越来越杂，工作目录越来越混乱。

最后，它什么都会一点，却越来越难管理。

所以，Hermes 引入 Profile，并不是为了让 Agent 拥有多个"人格"，而是为了给不同工作角色建立独立的运行环境。

一句话概括：

Profile 管理的不是身份，而是边界。

如果说第一篇解决的是 "Agent 怎么持续工作"，第二篇解决的是 "多个 Agent 怎么协作"，那么这一篇讨论的，就是另一个经常被忽略的问题：

如何让每个 Agent 都待在属于自己的工作边界里。

---

一、为什么一个 Agent 最后都会越来越乱

很多人第一次使用 Hermes，都会从一个 Profile 开始。

这是完全合理的。

项目还小、任务不多，一个 Agent 足以覆盖绝大多数需求。

真正的问题不是今天，而是几个月以后。

随着工作越来越多，同一个 Agent 会不断叠加新的职责。

例如：

最开始，你觉得是在不断增强 Agent。

但实际上，你是在不断扩大它的工作边界。

工程系统里有一句很经典的话：

任何没有边界的系统，最后都会变得难以维护。

Agent 也是一样。

真正让系统变乱的，不是能力越来越强，而是职责越来越杂。

通常，这会带来三个问题。

---

1. 工作记忆开始串台

这是最容易遇到的问题。

写公众号时，它记住的是标题风格、文章结构和配图规则。

写代码时，它又记住了项目目录、测试命令和 Git 提交流程。

研究新技术时，它保存了大量临时结论和参考资料。

这些内容单独看都没有问题。

真正的问题在于：

它们开始共享同一套上下文。

于是，你会看到一些熟悉的现象。

例如：

• 写文章时，不断引用某个项目里的开发规范；

• 写代码时，回复越来越像公众号文章；

• 做研究时，引用了已经过期的临时结论；

• 执行脚本时，默认进入了上一个项目的工作目录。

很多人会觉得：

"这个 Agent 怎么越用越笨？"

实际上，模型没有退化。

真正混乱的是：

工作状态开始互相污染。

这也是很多 AI Agent 使用一段时间以后，体验反而下降的根本原因。

---

2. 工具权限越来越宽

第二个问题，比记忆污染更危险。

很多人在配置 Agent 时，都会经历一个过程。

刚开始，只给它几个工具。

后来觉得方便，就继续增加。

浏览器。

终端。

Git。

MCP。

数据库。

GitHub。

消息平台。

服务器 SSH。

……

工具越来越多，配置越来越完整。

直到有一天，你发现：

一个本来只负责整理资料的 Agent，已经拥有了修改代码、执行脚本、访问生产环境的能力。

这时候，真正的问题就出现了。

并不是 Agent 一定会误操作。

而是：

低风险任务，继承了高风险权限。

例如：

一个研究 Agent，本来只需要：

读取网页
↓

整理资料
↓

生成总结

结果，它同时还能：

执行 Shell

修改文件

提交 Git

连接服务器

广告

文字来找茬呀

小游戏 益智

这并不会提高研究质量。

却会明显增加系统风险。

工程系统一直强调：

最小权限原则（Principle of Least Privilege）。

Agent 系统同样如此。

不是所有 Agent 都应该拥有所有工具。

权限越集中，风险就越集中。

---

3. 工作现场越来越不确定

还有一个容易被忽略的问题：

工作目录。

很多人会认为：

创建了 Profile，它就只能在自己的目录里工作。

其实不是。

Profile 默认管理的是 Hermes 自己的状态，并不会自动限制工具能够访问哪些文件。

如果没有明确设置工作目录，同一个 Agent 很可能今天在项目 A 工作，明天又进入项目 B。

更重要的是：

即使配置了默认工作目录，它依然不是安全边界。

因为默认本地终端后端使用的，仍然是当前系统用户的权限。

这意味着：

Profile≠文件隔离≠权限隔离

真正能够限制文件访问范围的，是容器、Docker、SSH、受限用户等运行环境，而不是 Profile 本身。

这一点一定要分清。

否则，很容易误以为：

"我已经拆了多个 Profile，所以系统已经安全了。"

实际上：

Profile 解决的是状态管理。

不是权限控制。

---

一个 Agent 最大的问题，不是能力，而是边界

很多人学习 Multi-Agent，第一个动作就是：

创建更多 Agent。

但我认为，更重要的问题其实是：

哪些事情，本来就不应该放进同一个 Agent？

如果写作、开发、研究、运维共享同一套记忆、工具和工作状态，那么无论模型多聪明，系统都会越来越难维护。

Hermes Profile 存在的意义，并不是让一个 Agent 去扮演不同角色。

而是让不同角色，从一开始就拥有彼此独立的运行环境。

它解决的不是"能力不足"，而是"边界失控"。

二、Profile 真正管理的是 Agent 的运行状态

很多人第一次看到 Profile，都会把它理解成：

一个 Agent，一个人格。

这个理解不能说错，但并不准确。

如果只把 Profile 当成"角色设定"，你很快就会发现很多行为解释不通。

例如：

为什么不同 Profile 可以拥有不同的配置？

为什么每个 Profile 都有自己的 Skills？

为什么 Cron、Gateway、Memory 都会跟着 Profile 一起变化？

原因很简单。

Profile 管理的不是人格，而是整个 Agent 的运行状态（Runtime State）。

可以把它理解成：

一个独立的 AI 工作身份。

创建一个 Profile：

hermes profile create coder \
  --description "负责代码修改、测试和 PR 说明"

真正创建出来的，并不是一个新的聊天窗口。

而是一套完整的运行环境。

它拥有自己的：

Config
│
├── 模型配置
├── API Key
├── SOUL.md
├── Skills
├── Memory
├── Sessions
├── Cron Jobs
├── Gateway
├── Logs
└── State Database

换句话说。

你创建的不只是一个 Agent。

而是一个长期工作的数字岗位。

---

一个 Profile，就是一个独立工位

现实团队里。

程序员不会和设计师共用一台电脑。

运维不会和财务共用一个登录账号。

不是因为大家不能共用。

而是因为：

不同岗位，本来就需要不同的工作环境。

Profile 也是一样。

例如：

Researcher

负责：
查资料
验证事实
阅读源码
整理引用

它更关心：

• 网页工具

• 搜索能力

• 文档处理

• 来源可信度

而：

Coder

负责：
实现功能
运行测试
生成PR

它需要的是：

• Terminal

• Git

• IDE

• 编译环境

Writer 又完全不同。

Writer

负责：
技术文章
公众号
文档
演示材料

它更关注：

• Markdown

• 图片生成

• 排版

• 写作规范

如果三种角色共用同一个 Profile。

最后一定会变成：

一个Agent

    ↓

所有工具

    ↓

所有记忆

    ↓

所有规则

短期方便。

长期一定越来越乱。

---

Profile 隔离的，不只是配置

很多人觉得：

Profile 不就是多个 config.yaml 吗？

实际上远不止。

它隔离的是：

整个 Agent 生命周期里的状态。

例如：

Profile

    ↓

Config

    ↓

Skills

    ↓

Memory

    ↓

Conversation

    ↓

Cron

    ↓

Gateway

    ↓

Logs

也就是说：

Researcher 学到的新知识。

不会自动进入 Writer 的长期记忆。

Writer 新增的写作 Skill。

也不会影响 Coder。

Coder 新建的定时任务。

不会突然出现在 Researcher 里面。

这种隔离看起来普通。

但对于长期运行的 Agent 来说，非常重要。

因为：

真正需要隔离的，从来不是 Prompt，而是状态。

---

不同角色，就应该拥有不同的默认环境

很多团队喜欢：

一个 Prompt。

不停切换角色。

例如：

现在你是程序员。

……

现在你变成架构师。

……

现在你再变成写作者。

模型当然可以做到。

但是工程系统，不应该依赖这种方式。

因为：

角色切换只是语言层面的。

工作环境没有变。

Hermes 更推荐另一种方式：

Researcher：

默认读取：

知识库
网页
文档
源码

Coder：

默认进入：

项目目录

运行测试

Git工作区

Writer：

默认进入：

文章目录

图片素材

发布流程

每个 Profile 都拥有：

属于自己的默认现场。

而不是：

每次聊天重新告诉模型：

"现在请忘掉刚才所有身份。"

真正成熟的系统。

应该让：

环境决定行为，而不是 Prompt 决定行为。

---

三、Profile、工作目录、Sandbox，到底是什么关系？

这是 Hermes 最容易被误解的地方。

很多文章会把三个概念混在一起：

Profile。

Workspace。

Sandbox。

实际上，它们解决的是三件完全不同的问题。

如果画成一张图，会更容易理解。

它们不是互相替代。

而是层层叠加。

---

第一层：Profile 决定身份

Profile 负责回答的是：

这个 Agent 是谁？

例如：

Researcher。

Coder。

Writer。

Ops。

不同身份。

拥有不同：

• 配置

• Skills

• Memory

• Session

• Gateway

• Cron

所以：

Profile 是：

身份隔离。

---

第二层：Workspace 决定现场

Workspace 回答的是：

这个 Agent 从哪里开始工作？

例如：

Coder：

/srv/project

Writer：

/article_assistant

Researcher：

/srv/research

Workspace 能减少很多误操作。

例如：

Coder 默认不会跑到写作目录。

Writer 默认不会进入源码仓库。

但是：

它仍然不是权限控制。

Agent 如果拿到绝对路径。

依然可以访问其他目录。

所以：

Workspace 是：

工作现场。

不是安全边界。

---

第三层：Sandbox 决定权限

真正决定：

Agent 能不能碰某个文件。

能不能执行某条命令。

能不能访问某台服务器。

靠的是：

Sandbox。

例如：

Docker。

SSH。

受限用户。

只读挂载。

容器。

这些才是真正限制运行范围的地方。

很多人误以为：

我已经拆了 Profile，所以已经安全。

其实不是。

如果运行环境没有隔离。

Profile 再多。

依旧共享同一套系统权限。

所以：

Profile 管身份。

Workspace 管现场。

Sandbox 管权限。

不要混为一谈。

---

第四层：Approval 决定风险

还有最后一层。

很多文章几乎不会提。

那就是：

Approval。

也就是：

哪些动作必须经过人工确认。

例如：

Researcher：

可以自动完成。

Writer：

可以自动生成草稿。

Coder：

可以自动修改代码。

但是：

删除数据

生产部署

付款

权限修改

客户通知

最好不要自动执行。

应该经过：

人工审批。

所以。

一个真正稳定的 Agent 系统。

应该同时拥有四层边界：

Profile

    ↓

Workspace

    ↓

Sandbox

    ↓

Approval

身份、现场、权限、风险。

四层共同组成了一个完整的工程边界。

---

这一部分其实也是整篇文章最重要的观点。

很多人把 Profile 理解成"角色扮演"。

而真正成熟的 Agent 系统，更应该把它理解成：

运行状态 + 工作边界 + 工程隔离。

---

四、什么时候该拆 Profile？

很多人刚接触 Hermes，最容易走向两个极端。

一种是始终只有一个 Profile。

什么都往里面塞。

另一种是一开始就建十几个：

coder
writer
researcher
reviewer
planner
architect
translator
ops
tester
designer
...

结果每个 Profile 都只用过一次。

真正的问题不是：

Profile 越多越专业。

而是：

什么时候值得拆。

我的建议很简单。

只看四个维度。

---

1. 工作目标不同，就应该拆

这是最容易判断的一条。

例如：

写代码。

和写公众号。

看起来都在"输出内容"。

实际上完全不是同一种工作。

代码更关注：

功能正确
测试通过
Git 规范
代码质量

写作更关注：

选题
结构
表达
读者体验

如果放在同一个 Profile。

长期一定会互相影响。

例如：

写文章时，它开始引用代码规范。

写代码时，又带着公众号的表达习惯。

真正稳定的系统。

应该让不同目标拥有不同默认环境。

---

2. 工具权限不同，就应该拆

这是工程里最重要的一条。

例如：

Researcher。

可能只需要：

浏览网页

读取文档

知识库

搜索

Writer。

需要：

Markdown

图片生成

文档处理

Coder。

需要：

Terminal

Git

IDE

测试工具

Ops。

甚至需要：

SSH

日志系统

监控平台

这些工具的风险等级完全不同。

所以不要因为方便。

把所有工具都开放给所有 Agent。

一个简单原则就是：

权限越不同，越应该拆 Profile。

---

3. 长期记忆不同，就应该拆

很多人最容易忽略这一点。

真正污染 Agent 的。

往往不是 Prompt。

而是 Memory。

例如：

Writer 会慢慢形成：

喜欢结论前置

喜欢短句

喜欢技术公众号风格

Coder 会积累：

项目目录

Git 分支

测试命令

代码规范

Researcher 又会保存：

资料来源

论文

事实引用

行业知识

这些记忆。

都应该长期存在。

但：

不应该互相污染。

如果一个 Agent 同时承担所有角色。

Memory 最后一定越来越混乱。

所以：

长期知识不同。

就应该拆。

---

4. 消息入口不同，也应该拆

很多团队最终都会接入：

Telegram。

Slack。

Discord。

Webhook。

邮件。

如果不同入口对应不同工作流。

最好也拆成不同 Profile。

例如：

Writer Bot

    ↓

负责公众号选题

Research Bot：

    ↓

负责技术情报

Ops Bot：

    ↓

负责巡检和告警

这样：

每个入口。

都只处理自己擅长的事情。

不会出现：

凌晨收到服务器报警。

结果写作 Agent 跑出来回复。

---

五、一个个人开发者最值得采用的 Profile 方案

很多人会问：

我到底应该建几个 Profile？

如果是个人开发者。

或者五人以内的小团队。

我建议：

先从四个开始。

足够了。

这四个角色。

基本覆盖了绝大多数 AI 工作流。

---

Main：总控

Main 不负责真正干活。

它负责：

接收任务

拆解任务

分配任务

查看结果

可以理解成：

团队里的项目经理。

它最大的原则就是：

不要自己下场执行。

---

Researcher：负责事实

Researcher 的职责只有一个：

把事实搞清楚。

例如：

读取网页。

阅读源码。

整理资料。

验证引用。

输出摘要。

它不负责：

写文章。

改代码。

做部署。

这样：

Researcher 输出的内容。

可信度会高很多。

---

Coder：负责实现

Coder 的目标也很明确。

就是：

实现。

测试。

提交。

生成 PR。

例如：

修改代码

运行测试

生成 Commit

输出 PR 说明

Coder 不需要：

考虑公众号标题。

也不需要：

搜索行业资料。

这样。

整个开发环境会稳定很多。

---

Writer：负责表达

Writer 专门负责：

把已经完成的成果。

整理成：

公众号

博客

文档

分享材料

演讲稿

它拥有：

自己的写作风格。

自己的素材目录。

自己的图片工作流。

而不是：

继承开发 Agent 的所有历史。

---

四个 Profile，已经足够覆盖大多数工作

很多人喜欢继续往下拆：

Planner。

Architect。

Reviewer。

Tester。

当然可以。

但我建议：

不要一开始就拆。

因为：

Profile 不是越多越好。

它本质上是一种工程边界。

只有当新的角色拥有：

• 不同目标

• 不同工具

• 不同记忆

• 不同工作流

才值得独立出来。

否则。

增加的只是维护成本。

六、Profile 和 Kanban 组合以后，Agent 才真正像一个团队

前一篇文章我们讲过：

Kanban 解决的是任务协作。

这一篇讲的是：

Profile 解决的是角色边界。

很多人会把两者混为一谈。

其实它们解决的是完全不同的问题。

可以把整个系统理解成这样：

这里，Kanban 管的是任务流转。

每张任务卡都会记录：

• 谁负责；

• 当前状态；

• 依赖哪些任务；

• 已完成什么；

• 下一步交给谁。

而 Profile 管的是执行者。

Researcher 永远负责研究。

Coder 永远负责实现。

Writer 永远负责输出。

Agent 不再依靠聊天内容临时决定身份，而是在系统里拥有固定职责。

这也是我认为 Hermes 和很多 Multi-Agent Demo 最大的区别。

它不是让几个模型同时聊天。

而是让多个角色围绕同一套任务协作。

---

新手最容易踩的 5 个坑

如果你准备开始拆 Profile，我建议先避开下面几个问题。

1. 把 Profile 当成沙箱

这是最常见的误解。

Profile 隔离的是：

• 配置

• Skills

• Memory

• Session

• Gateway

它不会自动限制系统权限。

真正的权限控制，仍然需要 Docker、SSH、容器或受限运行环境。

---

2. 一个 Profile 开所有工具

很多人觉得：

反正以后都可能用到。

于是：

Terminal、Git、Browser、MCP、Webhook……

全部打开。

最后的结果就是：

写文章的 Agent。

也拥有删除文件的能力。

研究 Agent。

也拥有生产环境权限。

工具应该按角色最小化配置。

不要因为方便，就把所有能力放在一起。

---

3. 角色职责不断重叠

例如：

Researcher 去改代码。

Writer 去做技术决策。

Coder 又开始写公众号。

最后：

所有 Agent 什么都会一点。

也什么都负责。

团队最怕的不是能力不足。

而是没有边界。

---

4. 一开始就拆十几个 Profile

很多文章喜欢展示：

planner
architect
reviewer
coder
tester
designer
writer
ops
analyst
...

看起来很完整。

实际上维护成本很高。

如果只有自己一个人在使用 Hermes。

四个 Profile 基本已经足够：

Main
Researcher
Coder
Writer

真正需要新的角色。

再继续拆。

---

5. 建好了 Profile，却没有工作流

很多人最大的误区不是不会建 Profile。

而是：

建完以后。

继续打开聊天窗口。

什么事情还是找同一个 Agent。

这样拆再多 Profile，也没有意义。

只有配合：

• Kanban 分派任务；

• Cron 定时执行；

• Gateway 接收入口；

• Skill 固化方法；

Profile 才真正发挥价值。

---

真正稳定的 Agent，不是越来越强，而是越来越有边界

回头看这三篇文章，其实一直在回答同一个问题：

怎样让 Agent 从聊天工具，变成真正能够工作的系统。

第一篇，我们把 Hermes 改造成了一个 24 小时 AI 工作台。

第二篇，我们用 Kanban 解决了多 Agent 的任务协作问题。

这一篇，我们再进一步，用 Profile 给每个 Agent 划清职责边界。

到这里，一个完整的 Agent 工作流就基本成型了：

可以发现，真正支撑系统稳定运行的，并不是某一个模型有多聪明。

而是：

• 任务有入口；
• 角色有边界；
• 执行有状态；
• 结果可交付；
• 过程可追踪。

这也是我这段时间持续研究 Hermes 后最大的体会。

很多人都在讨论 Agent 会不会越来越强。

但真正决定系统能不能长期运行的，往往不是模型能力，而是工程设计。

一个成熟的 AI 工作台，不应该只有一个越来越万能的超级 Agent，而应该是一组职责清晰、边界明确、能够长期协作的数字团队。