Hermes会计系统80%架构可重用！技能孤岛困住每个开发者
内容提要
该文讨论Hermes Agent智能体框架的局限。其“技能”和“记忆”功能虽能自动生成操作文档并跨会话召回，但技能间无法组合共享，记忆仅存内容而非设计结构，导致会计系统85%架构重复生成。开源共享也因定制化难以剥离通用层，生态缺乏可验证的完整配方，最终“不让智能体失忆”未解决“不让人类重复劳动”的生态问题。
延伸解读
技能孤岛：命名与现实的错位
文章指出Hermes Agent的“技能”功能虽能自动生成操作文档，但技能之间无法组合或共享逻辑，每个技能都是独立孤岛。这种命名暗示了可积累、可组合的能力体系，实际却更像书签，只能存储和回放流程。这种能指与所指的错位，导致生态内沟通成本上升，开发者误以为技能可复用，实则只是孤立文档。
记忆的局限：内容 vs 结构
Hermes的记忆系统能跨会话召回对话片段，但仅记录内容，不记录设计决策和思维路径。MEMORY.md等文件容量有限，装不下“为什么选A方案”这类关键信息。因此，即使智能体记住了环境事实，也无法传递架构设计的逻辑，导致他人难以复用其设计结构，重复劳动依然存在。
开源困境：定制化与通用化的矛盾
传统开源依赖显式代码共享，但智能体生成的内容高度定制，难以直接剥离通用层。开发者不愿花时间抽象和打包，因为受益者是陌生人，而自己业务紧迫。这导致公共仓库堆满单点技能，却缺乏完整可验证的架构蓝图，生态难以形成有效共享。
可重用率与实际行动的落差
会计系统案例显示85%-90%架构可重用，但通用层未被剥离发布。原因在于剥离工作本身耗时费力，且不直接产生个人价值。文章强调“造系统的人没空抽象，有空抽象的人没造过系统”，揭示了生态中缺乏激励和角色分工，导致可重用资源被闲置，重复劳动持续发生。
Q&A
Hermes Agent是什么？它的核心设计是什么？
Hermes Agent是Nous Research在2026年2月开源发布的自主智能体框架，采用MIT许可证。其核心设计是“闭环学习回路”，即每次任务完成后自动生成可复用的操作文档，并为对话历史建立跨会话召回索引，使智能体不会像普通聊天机器人那样忘记前文。
Hermes Agent的“技能”功能存在什么问题？
Hermes Agent的“技能”功能存在技能孤岛问题：每个技能都是独立的，不能互相调用、共享代码或逻辑，没有组合机制、继承关系或依赖管理。这导致同一逻辑被反复复制粘贴，无法形成可组合的能力体系，与“技能”一词暗示的可积累、可组合的含义不符。
Hermes Agent的“记忆”功能有哪些局限？
Hermes Agent的“记忆”功能主要记住对话内容，但无法记住设计结构。它通过MEMORY.md和USER.md等文件记录环境事实和用户偏好，但受限于字符数（如2200字符），无法存储设计决策和思维路径。因此，它不能帮助用户共享架构设计，导致不同用户的智能体无法互相借鉴。
为什么开源方式没有解决智能体生成代码的重复问题？
传统开源通过共享显式代码实现协作，但智能体生成代码是黑盒过程，共享媒介变成了模型而非代码本身。生成的代码高度定制化，难以直接作为通用方案，且剥离通用层需要额外工程，导致公共仓库中只有零散技能文件，缺乏完整架构蓝图。
Hermes Agent在哪些方面做得不错？
Hermes Agent在防止智能体失忆方面做得很好，其记忆系统、技能自动生成和跨会话召回功能都硬核地实现了“不让智能体失忆”。例如，一个不会写代码的人能在30小时内用其生成一套能跑通的会计系统，这在三年前难以想象。
为什么开发者没有将通用层剥离并共享？
剥离通用层需要识别通用与定制部分、抽象接口、编写文档和测试，工作量不亚于从零开发。但造系统的人忙于解决自己的问题，没空抽象；有空抽象的人又缺乏实际系统经验，导致抽象结果不实用。因此，尽管85%的架构可重用，但通用层始终未被发布。
会计系统重复生成的具体数据是什么？
一份对某套完整会计系统的生成文件统计显示：72个文件中42个是系统模板，29个是年度实例，其中22个年度实例除了年份数字外结构完全一致。85%到90%的架构是重复的，真正承载业务差异的只有6个文件。
有开发者提出了什么解决思路？
有开发者提出用版本化的、带测试的完整配方代替散装的技能文件，即包含示例输入输出、预期行为、权限清单、迁移说明的完整包，用户安装后先跑测试确认兼容。类似Docker、Homebrew的机制，使“能跑”成为可验证状态。但该思路尚未在智能体生态中落地。
