夜雨聆风
先说判断Hermes Agent最值得研究的，不是它“又会了一个新功能”，而是它把 AI 往“岗位化”推进了一步。
它开始像一个可以被安排工作、被限定权限、被纳入流程、被持续协作的角色，而不只是一个临时回答问题的助手。
这两天看 GitHub Trending，我花了些时间把 NousResearch/hermes-agent 的 repo 和官方文档翻了一遍。
最开始我也以为，这不过又是一个新的 agent 项目。会调工具，会接 MCP，会跑终端，会做定时任务。这类项目最近并不少。
但看完之后，我反而觉得它值得写，不是因为它“功能很多”，而是因为它试图回答一个更具体的问题：
如果 AI 不是一次一问一答的助手，而是一个长期在线、能接住任务、能积累工作习惯的角色，它应该长什么样？
我觉得，这才是 Hermes 真正有意思的地方。
一、引入议题：为什么 Hermes 值得单独看
如果只是把 Hermes 当成一个“会写代码的 agent”或者“另一个OpenClaw”，很容易低估它（最起码也是升级版的“龙虾人”🫠）。
它真正和很多工具拉开差别的，不是某个单点能力，而是下面这组组合：
它有 profile，可以给不同 agent 固定身份它有 SOUL.md，可以把角色的语气、边界和偏好写进去它有内建 memory，也支持外部 memory provider 它有 skills，可以把做过的流程沉淀成可复用的方法它有 cron，让任务按节奏自己发生它有消息网关，可以进入 Telegram、Slack、Discord、WeCom、Weixin 等渠道 它支持 MCP，也支持本地、Docker、SSH、Modal 等执行后端
把这些东西放在一起看，你会发现它在做的不是“一个更聪明的对话框”，而是一个更接近工作系统的运行时。
这件事为什么重要？
因为现在很多 AI 工具的问题，不是它不会回答，而是它很难进入真实工作。
它会说，但不一定记得。
它会做，但不一定留痕。
它能调工具，但不一定知道自己在团队里扮演什么角色。
它偶尔很好用，但很难变成一个稳定的工作节点。
Hermes 最值得看的地方，恰恰是它开始试着解决这些问题。
我的理解是：
AI 产品接下来真正的分水岭，可能不是“谁更像天才”，而是“谁更像一个靠谱的同事”。
二、场景假设：如果用 Hermes 搭一间虚拟内容公司，会卡在哪里
为了不把文章写成泛泛而谈的趋势分析，我们不妨直接设一个具体场景。
场景设定
假设你要做一间很小的“虚拟内容公司”。
目标不夸张，就一件事：
每天稳定产出一套可用的内容资产。
这套资产不一定每天都要变成正式发稿，但至少应该包括：
值得继续深挖的选题卡 一份结构化的研究备忘录 一版可编辑的文章初稿 一份次日继续跟进的任务清单
这个目标听起来不大，但真正做过内容的人都知道，最难的往往不是“写一篇”，而是“每天都能接着往下做”。
问题通常不出在写作本身，而出在这四个地方：
1. 角色不清
一个 AI 今天像研究员，明天像作者，后天又像运营。
什么都能聊一点，但没有真正稳定的工作边界。最后的结果通常是：
信息收集和观点生成混在一起 事实、判断、文风互相污染 没有办法复盘“到底是哪一步出了问题”
2. 记忆太散
今天翻过的 repo，明天还得重讲一遍。
上周放弃过的选题，下周又重新捡起来。
某个判断是因为“证据不足”被搁置，过几天再看时，只剩一句结论，过程已经丢了。
3. 流程没有节奏
选题、调研、初稿、审稿、归档，全都靠人手动触发。
这样做不是不能产出，而是很难形成惯性。人一忙，整条链路就断。
4. 协作没有留痕
研究员看了什么，作者为什么没用，编辑删掉了哪些判断，运营准备明天继续追什么，如果这些都只留在聊天记录里，那系统第二天就像刚醒一样。
为什么“一个超级 Agent”并不够
很多人看到 agent 工具，第一反应都是：能不能搞一个全能角色，把所有事都做了？
短期当然可以。
但只要任务变成“持续协作”，单个超级 agent 很快就会遇到三个问题：
上下文越来越重，越来越乱 身份越来越混，越来越难收口 错误一旦出现，很难知道是调研错了、判断错了，还是表达错了
所以，如果真想把 Hermes 用到内容生产里，我反而不建议从“一个最强 agent”开始，而建议从“几个边界清楚的岗位”开始。
这里有个很重要的判断：
不要把 subagent 当员工，要把 profile 当员工。
原因很简单。
subagent 更像临时派出去处理小任务的外包工，适合并行研究、补材料、跑分析；profile 才更像长期角色，适合承接稳定职责、保留工作习惯、持续积累上下文。
如果这一步不分清，后面做出来的系统，多半只是“热闹”，不是“组织”。
三、解决方案：如果由我来搭第一版，我会这样做
我不会一上来就追求“全自动写稿”。
更现实的做法，是先把内容团队最容易断掉的地方接起来。
第一步：先定 5 个岗位，不要贪多
第一版够用就好。我会先做这 5 个角色。
webbrowser、只读类 MCP | |||
webbrowser、file | |||
fileskills | |||
file | |||
cron |
这个设计的关键，不是“多 agent”，而是角色边界清楚。
内容生产最怕的不是能力不够，而是职责混掉。
第二步：把记忆分层，而不是全塞进一个会话
Hermes 的内建 memory 有价值，但它更适合记住“角色的长期偏好”和“少量稳定事实”，不适合直接扛起整个内容团队的知识库。
如果要做成一个能持续运转的小团队，我建议把记忆拆成三层：
1. 角色记忆
放在每个 profile 自己的上下文里。
记这些东西：
这个角色平时的说话方式 它偏好的判断标准 它常用的工作格式
这部分适合写进 SOUL.md、默认配置和 profile 自己的 memory。
2. 团队共享记忆
这部分不要只靠默认 memory。
更稳妥的方式是：
外接 memory provider，优先考虑支持多 profile 共享 workspace 的方案 或者直接把共享事实落到 GitHub、Notion、文档库、本地知识文件里
核心原则只有一条：
共享事实不要只存在于会话里。
比如“这个选题为什么继续做”“这个判断目前证据还不够”“这篇文章的核心问题是什么”，都应该以文件或结构化记录的形式留下来。
3. 结果留痕
每天的产物都应该有地方落。
至少包含：
选题卡 研究备忘录 初稿 修改记录 次日待办
只有这样，第二天系统才能接着工作，而不是重新开始。
第三步：把“工作节奏”交给 cron，而不是交给意志力
我很喜欢 Hermes 的一个点，就是它不是只服务于“对话触发”，而是有明确的 cron 机制。
内容团队其实特别适合这个。
如果让我排一个最小日程，我会这样定：
这里最关键的一点，不是“自动”，而是“自包含”。
Hermes 的 cron 是 fresh session 跑的，所以 prompt 一定要写完整，不要写成“继续昨天那篇”。
正确的做法是让每个 cron 任务都知道：
它要读哪些文件 它要产出什么格式 结果要送到哪里 如果没有结果，应该怎样明确返回
这样自动化才不会越跑越乱。
第四步：把权限切干净，不要让每个角色都拿最高权限
这是很多人做 agent 系统时最容易忽略的一步。
但只要系统开始“像员工”，权限就一定要比“像助手”时更清楚。
我会这样分：
研究岗位
开 web、browser开只读类 MCP 不给高风险写操作
写作岗位
开 file开 skills不直接碰终端和生产系统
工程岗位（如果后续加上）
才给 terminal尽量开 worktree高风险命令走 approvals
如果要接仓库，我建议尽早启用：
1worktree:true
2
3approvals:
4mode: manual
5
6terminal:
7backend: docker
这不是为了“看起来专业”，而是因为一旦角色开始并行工作，不做隔离，后面几乎一定会互相踩。
第五步：把流程固化成 skill，而不是每次重写 prompt
Hermes 的 skill 机制，放在这个场景里其实非常实用。
内容团队里最适合先做成 skill 的，不是“写一篇很厉害的文章”，而是这些重复动作：
选题卡模板 repo 研究模板 研究备忘录模板 初稿结构模板 编辑审校清单 归档与回传模板
这一步很关键。
因为内容生产真正可复用的，不是某个漂亮句子，而是那套能持续把材料变成稿件的工作方法。
换句话说：
我们不是在训练一个“会写”的 agent，而是在训练一个“会按固定流程交付”的团队。
第六步：第一版不要追求“全自动发稿”，只追求“稳定闭环”
如果让我给这套系统定第一阶段目标，我只要求它做到一件事：
每天稳定交付一套可继续工作的内容资产。
不是直接发稿，也不是让它自己决定选题方向。
而是每天都能给你留下一套真正有用的东西：
今天哪些方向值得继续看 哪些材料已经读过 哪些判断已经形成 哪些地方证据还不够 明天从哪里接着做
只要这个闭环稳了，后面无论是把它接到公众号、接到内部知识库，还是接到更复杂的虚拟公司系统里，都会顺很多。
最后：Hermes 真正有价值的地方，不是“更强”，而是“更像工作”
我不太想把 Hermes 写成一个“又一个很厉害的 AI 项目”。
这种写法很容易飘，也没什么帮助。
我更愿意把它理解成一种很朴素的工程尝试：
它在试着把 AI 从“临时帮忙”推进到“长期在岗”。
这一步未必华丽，但很关键。
如果这个方向走得通，未来更值得看的，可能不是哪个 agent 最会表演，而是谁先把下面这些东西接成了系统：
角色 记忆 节奏 权限 留痕 交付
从这个角度看，Hermes Agent 的意义不在于“它已经是员工了”，而在于：
它让我们第一次可以比较认真地去搭一个小而真的虚拟团队。
这件事，我觉得比单纯讨论“模型又强了多少”更值得看。
参考资料
NousResearch/hermes-agentGitHub 仓库 Hermes Agent 官方文档 Profile Commands Persistent Memory Memory Providers Skills System Scheduled Tasks (Cron) MCP Messaging Gateway Configuration
