前两篇我们分别解决了两个问题。第一篇把 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 工作身份。创建一个 Profilehermes 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它需要的是TerminalGitIDE编译环境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。不同身份。拥有不同配置SkillsMemorySessionGatewayCron所以Profile 是身份隔离。第二层Workspace 决定现场Workspace 回答的是这个 Agent 从哪里开始工作例如Coder/srv/projectWriter/article_assistantResearcher/srv/researchWorkspace 能减少很多误操作。例如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 隔离的是配置SkillsMemorySessionGateway它不会自动限制系统权限。真正的权限控制仍然需要 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而应该是一组职责清晰、边界明确、能够长期协作的数字团队。