作者金一鸣 本文约5800字建议阅读11分钟 本文介绍成长型智能体架构、运行机制、应用场景与现存局限。引言为什么大多数 AI 助手都记不住你一个常见的体验是上周你已经向某个 AI 助手解释过自己写代码的偏好、项目背景、表达风格本周开启新对话它又像第一次见到你。你昨天告诉它我习惯用驼峰命名今天它依然在用下划线。再具体一些——把同一份长文档翻译两次得到两份风格不一致的译文让 AI 助手帮忙整理客户资料每次都要从头解释我是做什么的、客户是谁。这不是模型本身不够强而是当前 AI 助手的使用方式默认是无状态的——每一次对话都是独立的结束即遗忘。这种金鱼式记忆是绝大多数主流 AI 助手的共同特征。过去两年大语言模型Large Language Model以下简称 LLM的能力开发经历了几个明显的阶段。最初模型被当作一次性问答工具使用随后开发者通过外挂工具、链式思考Chain-of-Thought和检索增强生成RAG扩展其能力边界近一年内Agent智能体这一形态逐步成为主流——模型不再被动应答而是主动调用工具、规划步骤、完成多轮任务。然而无状态的局限并未随之消失。Agent 能调更多工具、跑更长流程但每次会话结束它学到的内容、踩过的坑、用户的偏好仍会随之归零。同一个用户、同一个任务Agent 可能需要被反复教导。由 Nous Research 在 2026 年 2 月开源的 Hermes Agent是针对这一痛点的一种系统性回答。其官方标语为 the agent that grows with you——与你共同成长的 Agent。截至 2026 年 5 月该项目在 GitHub 上已获得约 142k Stars、22k Forks。它没有发明新的模型也没有提出新的算法而是把记忆技能工具调度这些零件组合起来让 Agent 在每一次使用中留下痕迹、长出能力。接下来这篇文章会拆解它是怎么做到的——架构是什么样、核心机制怎么工作、对普通人意味着什么以及它仍然解决不了的问题。整体架构一个运行时而非一个模型封装理解 Hermes Agent 的第一个关键是区分它与传统 LLM 应用的不同定位。它不是 ChatGPT 那样的端到端产品也不是 LangChain 那样的开发库而是一个自治式 Agent 运行时Agent Runtime。查阅其 GitHub 仓库的代码目录可以观察到 Hermes Agent 的工程结构呈现出清晰的模块划分agent/核心推理循环、gateway/消息网关、skills/技能库、tools/工具集合、cron/定时调度、acp_adapter/Agent Communication Protocol 适配层、environments/强化学习环境。会话、工具、记忆、调度、通信协议在此被作为并列的顶层模块组织而非附属于某个核心组件之下。整体架构可以划分为五层如下图所示各层职能如下表所示值得注意的是全部数据默认存储于本地 SQLite 数据库不经过第三方云服务。这一选择服务于自托管定位使数据与日志都保留在部署者本地与主流 SaaS 形态的 AI 助手存在明显差异。核心机制一自我进化的学习闭环Hermes Agent 最具辨识度的特性是其学习闭环Learning Loop。该闭环并非单一算法而是由五个相互衔接的子机制构成。官方 README 将其概括为五点Agent 策展的记忆与定期提示、复杂任务后自主创建技能、技能在使用中自我改进、基于 FTS5 与 LLM 摘要的跨会话召回、Honcho 辩证用户建模。下面分别展开。1. 分层记忆架构学习闭环的基础是记忆。Hermes Agent 的记忆系统不是单一存储而是分层设计这一设计的实际收益是对 Prompt Cache 友好常驻的两个 Markdown 文件保持稳定便于 LLM Provider 命中缓存而频繁变化、体量较大的会话历史和技能则通过工具按需检索避免占用主上下文。在长期使用中这能直接降低 Token 消耗。2. 从任务到技能经验的固化当 Agent 完成一个复杂任务后会自动触发一次技能提炼流程。社区文档中明确指出触发阈值为涉及五次以上工具调用的任务。该流程会回看本次任务的完整轨迹提取其中可复用的步骤序列、参数模板与判断逻辑将其固化为一个新的 Skill 文件。Hermes Agent 兼容 agentskills.io 开放标准意味着技能可以在不同 Agent 之间迁移与共享。这一机制的设计哲学与传统 Agent 框架如 OpenClaw 类项目形成了对比可以看到这是一种典型的设计权衡Trade-off以冷启动质量换取长期个性化与维护成本。3. 技能的自改进技能一旦生成并不固化。在后续被调用的过程中Hermes Agent 会持续监测其执行结果——成功率、耗时、报错频率等指标。当某项指标偏离预期时Agent 会触发对该技能的反思与改写。这种使用即训练的机制可以理解为把传统机器学习中在线学习Online Learning的思想迁移到了符号化的技能脚本层面。它不依赖梯度回传而是依赖 LLM 的自我反思能力Self-Reflection完成迭代。技能本身以 Markdown 形式存在可读、可审、可手动修改、可版本控制——这与调整模型权重的不透明过程形成了对照。4. 跨会话记忆与召回会话档案模块是闭环的另一关键支柱。Hermes Agent 采用 SQLite 的 FTS5 扩展Full-Text Search version 5建立全文索引。召回时并非简单做向量检索而是采用 FTS5 关键词检索 LLM 二次摘要的混合方案。该方案相比纯向量检索的优势在于精确召回结构化事实如人名、时间、API Key 命名并通过 LLM 对召回片段做语义压缩控制注入主推理上下文的 Token 体量。5. 用户建模在记忆之上Hermes Agent 集成了来自 Plastic Labs 的 Honcho 框架采用辩证法Dialectical方式持续推断用户的风格、技术偏好、错误容忍度等画像维度。该画像作为可选模块启用后会作为系统提示的一部分注入每次推理使 Agent 输出风格逐步向用户对齐。整体闭环可表示如下核心机制二统一消息网关与多平台抽象Hermes Agent 的另一个值得关注的设计是其统一消息网关Unified Gateway。具体而言它将 Telegram、Discord、Slack、WhatsApp、Signal、Email、CLI 等异构通道抽象为同一种内部消息格式再交由推理层处理。带来的直接收益是同一个 Agent 实例可以在多个平台上同时服务且共享同一份记忆与技能库。国内用户更关心的微信、飞书、钉钉、企业微信等平台目前不在官方原生适配清单中。但社区已通过桥接方案补齐——例如开源项目 HermesClaw 通过微信网页协议接入个人微信号飞书与钉钉则可通过其官方机器人 API 编写自定义 Adapter 接入。这意味着 Hermes Agent 的统一消息抽象对国内生态同样适用只是初期需要一些配置工作。实现层面网关采用插件化适配器Adapter模式每个平台对应一个独立适配器负责协议翻译、媒体格式转换与速率控制。新增平台支持的边际成本很低。核心机制三模型无关的路由层LLM 生态变化极快新模型几乎每月都在更新。任何绑定单一模型的 Agent 框架都将面临持续的迁移成本。Hermes Agent 在设计上采用了模型无关Model-Agnostic的路由抽象目前已兼容 Nous Portal、OpenRouter聚合 200 模型、NVIDIA NIMNemotron 系列、智谱 GLM、Kimi/Moonshot、MiniMax等以及任何用户自托管的端点。切换方式较为简单命令行执行 Hermes model 即可在交互界面中选择无需修改代码。这一抽象除了支持手动切换也允许根据任务类型动态选择模型——例如代码生成路由至擅长编码的模型文案改写路由至擅长长文本的模型工具调用决策路由至响应速度更快的小模型。这种异构模型协同的策略可以在控制成本的同时兼顾输出质量。子 Agent 与上下文压缩复杂任务往往需要多步骤、多工具的协同。如果所有中间结果都堆积在主 Agent 的上下文窗口中会迅速触及 Token 上限并显著推高成本。Hermes Agent 引入了子 AgentSub-Agent并行化机制主 Agent 通过 RPC 调用方式派发子任务子 Agent 在独立上下文中完成工具调用与初步推理仅将最终结论回传。这一机制的效果是将多步骤流程压缩为对主上下文几乎无成本的一次调用。从工程视角看思路与操作系统的进程隔离类似——上下文相当于地址空间子 Agent 相当于子进程。下表对比了有无子 Agent 机制的差异沙箱执行七种终端后端Agent 一旦具备调用终端、修改文件、执行代码的能力安全边界就成为不可回避的问题。Hermes Agent 在这个问题上提供了七种可选的执行后端其中 Modal 与 Daytona 这两个 Serverless 后端值得关注Agent 的环境可以在空闲时休眠按需唤醒闲置阶段几乎不产生持续费用。这降低了让 Agent 长期运行的门槛。之所以提供如此多种后端背后的考虑是不同用户的安全偏好与运行环境差异极大开发者本机偏好 local 直连企业部署需要 Docker 隔离云服务管理依赖 SSH科研机构使用 Singularity间歇任务适合 Serverless。统一的 Agent 行为对接不同的执行隔离层级——这是 Hermes Agent 在自治程度与安全可控之间留出的调节空间。与普通人有什么关系四个具体场景技术原理之外普通人最关心的问题是这一切对自己意味着什么以下是几个具体的应用场景。场景一自由职业者的个人秘书一名自由撰稿人通常会在多个平台间切换——客户在微信沟通需求、稿件在飞书或腾讯文档中撰写、参考资料散落在浏览器收藏夹、发票在邮箱中等待整理。传统 AI 助手对此场景几乎无能为力——它每次都需要被告知我是谁、我在做什么、上次聊到哪里。部署一个 Hermes Agent 后情况发生改变Agent 通过消息网关常驻在飞书或企业微信用户在不同时间从不同设备发送指令Agent 凭借跨会话记忆延续上下文完成第一次整理客户需求并生成稿件大纲任务后Agent 自动提炼一份对应技能下次只需说按上次那个流程整理技能即被复用通过定时任务Agent 每周一早上 9 点自动汇总上周的客户沟通要点发送到指定渠道。场景二研究者的实验记录助手科研工作者在重复性实验中常常面临上次配置了什么参数、为什么这个步骤要这样做的记忆负担。Hermes Agent 的技能系统可以扮演结构化实验记录的角色第一次跑通一个数据预处理流水线后Agent 自动生成一份技能文档记录每一步的参数、依赖项、常见报错与验证方法后续若同事或自己半年后需要复现仅需调用同一技能技能在使用过程中如发现陷阱如 GPU 显存不足时的回退策略会自动迭代更新。这与 Jupyter Notebook 笔记不同——它不仅是被动的记录而是可执行、可调用、可演化的程序性知识。场景三小型团队的运维助手一支三五人的创业团队通常没有专职运维。Hermes Agent 配合 SSH 后端可以承担日常运维角色每晚定时执行数据库备份结果推送到团队的飞书群或钉钉群监控服务器告警自动诊断常见问题如磁盘满、进程崩溃并尝试修复团队成员在飞书或企业微信中用自然语言下达指令例如看一下昨晚的日志有没有异常——Agent 调用对应技能远程登录、检索、汇总、回复。这类场景中Hermes Agent 的技能积累特性较为有用——团队的运维经验会被自动沉淀为技能库新成员加入时可直接复用。场景四个人知识管理与生活助理对完全非技术背景的用户Hermes Agent 仍可作为长期的数字伴侣通过微信社区桥接或飞书与之对话记录每日想法、待办事项、阅读笔记Agent 学习用户的语言风格与关注主题逐步形成个性化画像当用户提出帮我把上周读到的那篇关于睡眠的研究找一下Agent 能够通过 FTS5 检索结合 LLM 摘要准确召回相关对话片段通过定时任务每月自动生成一份个人月报汇总当月的关注主题、待办完成情况与重要事件。需要补充的是上述数据均存储在用户自己的服务器上不流向第三方云厂商。这对隐私敏感的使用者而言是一项实际差异。局限性与挑战任何技术方案都有适用边界。客观看 Hermes Agent至少存在以下几方面的挑战。第一自生成技能的质量不可控。 由于技能由 Agent 在使用中自动提炼质量高度依赖早期任务样本的代表性。若早期任务存在偏差提炼出的技能可能将错误模式固化。该问题虽然可以通过自改进机制部分缓解但在缺乏外部评估信号的情况下存在自我强化错误的风险。第二可观测性不足。 一次 Hermes Agent 的运行可能涉及多轮推理、若干工具调用、子 Agent 派发与记忆读写。当结果偏差或成本异常时定位问题根源较为困难。阿里云等厂商已为其提供了可观测性插件从侧面反映了原生方案在该领域的不足。第三安全与权限边界。 自治程度越高的 Agent权限滥用的潜在风险越大。当 Agent 拥有持久记忆、可调用任意工具、可派发子任务时一次提示注入Prompt Injection攻击就可能造成持久性影响——例如恶意指令被固化为技能。Hermes Agent 通过命令审批机制、DM 配对、容器隔离等多层防御缓解此问题但风险并未完全消除。第四成本不可预测。 学习闭环中的技能提炼、记忆摘要、用户建模本身需要额外的 LLM 调用。对于轻度使用场景这部分元开销可能高于实际任务开销。Modal 与 Daytona 这类 Serverless 后端缓解了闲置成本但活跃使用阶段的 Token 消耗仍需关注。技术价值与启示抛开热度数据从纯技术角度看Hermes Agent 的价值在于围绕一个具体问题给出了完整解答Agent 如何具备长期记忆与长期能力。它的回答不是某个单点创新而是若干已有思路的组合——本地化的持久存储、自动提炼的技能体系、分层的记忆召回、统一的消息抽象、模型无关的路由层、多种隔离的执行后端。这些思路在论文与开源项目中并不罕见Hermes Agent 的工作是把它们整合成一套可运行、可部署、可持续迭代的系统。对于关注 Agent 技术的开发者可以从中提取出几条参考性的设计原则1. 状态管理优先于模型选择。模型可以替换状态与记忆是 Agent 的核心资产。2. 抽象层有助于应对快速演进的生态。模型路由层、消息网关层、ACP 协议都体现了这一点。3. 学习应当是闭环而非单次。把使用本身变成训练信号是个性化 Agent 的关键。4. 隔离用于控制复杂度。子 Agent 机制与七种沙箱后端是其在不同层面的体现。5. 可读性同样是工程质量的一部分。技能与记忆均以 Markdown 形式存在可被人类阅读、审计、修改。未来 Agent 的演进方向大概率会沿着更长的记忆、更强的工具使用、更深的个性化、更安全的执行边界展开。Hermes Agent 是其中一个具体的、可参考的实现样本。结语回到最初的问题一个 AI 助手怎样才算会记住你答案不在更大的模型而在它身边那一整套用于沉淀、检索、复用的工程机制。Hermes Agent 把这些机制兑现成了一个可以跑、可以部署、可以持续迭代的系统让成长这件事第一次具备了可观察、可重现的形态。对读者而言更值得带走的不是 Hermes Agent 本身而是它背后的判断标准决定 AI 助手能否长期可用的是周边的状态管理、上下文组织与执行隔离做得有多扎实。理解这一点再去看其他 AI 产品判断会更清楚一些。编辑于腾凯校对李嘉林欢迎在评论区留言与本文作者互动交流作者简介金一鸣硕士毕业于中南大学互联网算法工程师主要研究方向有强化学习LLMAgent搜索推荐等方向数据派研究部介绍数据派研究部成立于2017年初以兴趣为核心划分多个组别各组既遵循研究部整体的知识分享和实践项目规划又各具特色算法模型组积极组队参加kaggle等比赛原创手把手教系列文章调研分析组通过专访等方式调研大数据的应用探索数据产品之美系统平台组追踪大数据人工智能系统平台技术前沿对话专家自然语言处理组重于实践积极参加比赛及策划各类文本分析项目制造业大数据组秉工业强国之梦产学研政结合挖掘数据价值数据可视化组将信息与艺术融合探索数据之美学用可视化讲故事网络爬虫组爬取网络信息配合其他各组开发创意项目。点击文末“阅读原文”报名数据派研究部志愿者总有一组适合你~转载须知如需转载请在开篇显著位置注明作者和出处转自数据派THUIDDatapiTHU并在文章结尾放置数据派醒目二维码。有原创标识文章请发送【文章名称-待授权公众号名称及ID】至联系邮箱申请白名单授权并按要求编辑。未经许可的转载以及改编者我们将依法追究其法律责任。关于我们数据派THU作为数据科学类公众号背靠清华大学大数据研究中心分享前沿数据科学与大数据技术创新研究动态、持续传播数据科学知识努力建设数据人才聚集平台、打造中国大数据最强集团军。新浪微博数据派THU微信视频号数据派THU今日头条数据派THU点击“阅读原文”拥抱组织
原创丨一个会“记住你“的 AI 智能体是怎么造出来的：拆解Hermes Agent
发布时间：2026/5/22 11:35:20
作者金一鸣 本文约5800字建议阅读11分钟 本文介绍成长型智能体架构、运行机制、应用场景与现存局限。引言为什么大多数 AI 助手都记不住你一个常见的体验是上周你已经向某个 AI 助手解释过自己写代码的偏好、项目背景、表达风格本周开启新对话它又像第一次见到你。你昨天告诉它我习惯用驼峰命名今天它依然在用下划线。再具体一些——把同一份长文档翻译两次得到两份风格不一致的译文让 AI 助手帮忙整理客户资料每次都要从头解释我是做什么的、客户是谁。这不是模型本身不够强而是当前 AI 助手的使用方式默认是无状态的——每一次对话都是独立的结束即遗忘。这种金鱼式记忆是绝大多数主流 AI 助手的共同特征。过去两年大语言模型Large Language Model以下简称 LLM的能力开发经历了几个明显的阶段。最初模型被当作一次性问答工具使用随后开发者通过外挂工具、链式思考Chain-of-Thought和检索增强生成RAG扩展其能力边界近一年内Agent智能体这一形态逐步成为主流——模型不再被动应答而是主动调用工具、规划步骤、完成多轮任务。然而无状态的局限并未随之消失。Agent 能调更多工具、跑更长流程但每次会话结束它学到的内容、踩过的坑、用户的偏好仍会随之归零。同一个用户、同一个任务Agent 可能需要被反复教导。由 Nous Research 在 2026 年 2 月开源的 Hermes Agent是针对这一痛点的一种系统性回答。其官方标语为 the agent that grows with you——与你共同成长的 Agent。截至 2026 年 5 月该项目在 GitHub 上已获得约 142k Stars、22k Forks。它没有发明新的模型也没有提出新的算法而是把记忆技能工具调度这些零件组合起来让 Agent 在每一次使用中留下痕迹、长出能力。接下来这篇文章会拆解它是怎么做到的——架构是什么样、核心机制怎么工作、对普通人意味着什么以及它仍然解决不了的问题。整体架构一个运行时而非一个模型封装理解 Hermes Agent 的第一个关键是区分它与传统 LLM 应用的不同定位。它不是 ChatGPT 那样的端到端产品也不是 LangChain 那样的开发库而是一个自治式 Agent 运行时Agent Runtime。查阅其 GitHub 仓库的代码目录可以观察到 Hermes Agent 的工程结构呈现出清晰的模块划分agent/核心推理循环、gateway/消息网关、skills/技能库、tools/工具集合、cron/定时调度、acp_adapter/Agent Communication Protocol 适配层、environments/强化学习环境。会话、工具、记忆、调度、通信协议在此被作为并列的顶层模块组织而非附属于某个核心组件之下。整体架构可以划分为五层如下图所示各层职能如下表所示值得注意的是全部数据默认存储于本地 SQLite 数据库不经过第三方云服务。这一选择服务于自托管定位使数据与日志都保留在部署者本地与主流 SaaS 形态的 AI 助手存在明显差异。核心机制一自我进化的学习闭环Hermes Agent 最具辨识度的特性是其学习闭环Learning Loop。该闭环并非单一算法而是由五个相互衔接的子机制构成。官方 README 将其概括为五点Agent 策展的记忆与定期提示、复杂任务后自主创建技能、技能在使用中自我改进、基于 FTS5 与 LLM 摘要的跨会话召回、Honcho 辩证用户建模。下面分别展开。1. 分层记忆架构学习闭环的基础是记忆。Hermes Agent 的记忆系统不是单一存储而是分层设计这一设计的实际收益是对 Prompt Cache 友好常驻的两个 Markdown 文件保持稳定便于 LLM Provider 命中缓存而频繁变化、体量较大的会话历史和技能则通过工具按需检索避免占用主上下文。在长期使用中这能直接降低 Token 消耗。2. 从任务到技能经验的固化当 Agent 完成一个复杂任务后会自动触发一次技能提炼流程。社区文档中明确指出触发阈值为涉及五次以上工具调用的任务。该流程会回看本次任务的完整轨迹提取其中可复用的步骤序列、参数模板与判断逻辑将其固化为一个新的 Skill 文件。Hermes Agent 兼容 agentskills.io 开放标准意味着技能可以在不同 Agent 之间迁移与共享。这一机制的设计哲学与传统 Agent 框架如 OpenClaw 类项目形成了对比可以看到这是一种典型的设计权衡Trade-off以冷启动质量换取长期个性化与维护成本。3. 技能的自改进技能一旦生成并不固化。在后续被调用的过程中Hermes Agent 会持续监测其执行结果——成功率、耗时、报错频率等指标。当某项指标偏离预期时Agent 会触发对该技能的反思与改写。这种使用即训练的机制可以理解为把传统机器学习中在线学习Online Learning的思想迁移到了符号化的技能脚本层面。它不依赖梯度回传而是依赖 LLM 的自我反思能力Self-Reflection完成迭代。技能本身以 Markdown 形式存在可读、可审、可手动修改、可版本控制——这与调整模型权重的不透明过程形成了对照。4. 跨会话记忆与召回会话档案模块是闭环的另一关键支柱。Hermes Agent 采用 SQLite 的 FTS5 扩展Full-Text Search version 5建立全文索引。召回时并非简单做向量检索而是采用 FTS5 关键词检索 LLM 二次摘要的混合方案。该方案相比纯向量检索的优势在于精确召回结构化事实如人名、时间、API Key 命名并通过 LLM 对召回片段做语义压缩控制注入主推理上下文的 Token 体量。5. 用户建模在记忆之上Hermes Agent 集成了来自 Plastic Labs 的 Honcho 框架采用辩证法Dialectical方式持续推断用户的风格、技术偏好、错误容忍度等画像维度。该画像作为可选模块启用后会作为系统提示的一部分注入每次推理使 Agent 输出风格逐步向用户对齐。整体闭环可表示如下核心机制二统一消息网关与多平台抽象Hermes Agent 的另一个值得关注的设计是其统一消息网关Unified Gateway。具体而言它将 Telegram、Discord、Slack、WhatsApp、Signal、Email、CLI 等异构通道抽象为同一种内部消息格式再交由推理层处理。带来的直接收益是同一个 Agent 实例可以在多个平台上同时服务且共享同一份记忆与技能库。国内用户更关心的微信、飞书、钉钉、企业微信等平台目前不在官方原生适配清单中。但社区已通过桥接方案补齐——例如开源项目 HermesClaw 通过微信网页协议接入个人微信号飞书与钉钉则可通过其官方机器人 API 编写自定义 Adapter 接入。这意味着 Hermes Agent 的统一消息抽象对国内生态同样适用只是初期需要一些配置工作。实现层面网关采用插件化适配器Adapter模式每个平台对应一个独立适配器负责协议翻译、媒体格式转换与速率控制。新增平台支持的边际成本很低。核心机制三模型无关的路由层LLM 生态变化极快新模型几乎每月都在更新。任何绑定单一模型的 Agent 框架都将面临持续的迁移成本。Hermes Agent 在设计上采用了模型无关Model-Agnostic的路由抽象目前已兼容 Nous Portal、OpenRouter聚合 200 模型、NVIDIA NIMNemotron 系列、智谱 GLM、Kimi/Moonshot、MiniMax等以及任何用户自托管的端点。切换方式较为简单命令行执行 Hermes model 即可在交互界面中选择无需修改代码。这一抽象除了支持手动切换也允许根据任务类型动态选择模型——例如代码生成路由至擅长编码的模型文案改写路由至擅长长文本的模型工具调用决策路由至响应速度更快的小模型。这种异构模型协同的策略可以在控制成本的同时兼顾输出质量。子 Agent 与上下文压缩复杂任务往往需要多步骤、多工具的协同。如果所有中间结果都堆积在主 Agent 的上下文窗口中会迅速触及 Token 上限并显著推高成本。Hermes Agent 引入了子 AgentSub-Agent并行化机制主 Agent 通过 RPC 调用方式派发子任务子 Agent 在独立上下文中完成工具调用与初步推理仅将最终结论回传。这一机制的效果是将多步骤流程压缩为对主上下文几乎无成本的一次调用。从工程视角看思路与操作系统的进程隔离类似——上下文相当于地址空间子 Agent 相当于子进程。下表对比了有无子 Agent 机制的差异沙箱执行七种终端后端Agent 一旦具备调用终端、修改文件、执行代码的能力安全边界就成为不可回避的问题。Hermes Agent 在这个问题上提供了七种可选的执行后端其中 Modal 与 Daytona 这两个 Serverless 后端值得关注Agent 的环境可以在空闲时休眠按需唤醒闲置阶段几乎不产生持续费用。这降低了让 Agent 长期运行的门槛。之所以提供如此多种后端背后的考虑是不同用户的安全偏好与运行环境差异极大开发者本机偏好 local 直连企业部署需要 Docker 隔离云服务管理依赖 SSH科研机构使用 Singularity间歇任务适合 Serverless。统一的 Agent 行为对接不同的执行隔离层级——这是 Hermes Agent 在自治程度与安全可控之间留出的调节空间。与普通人有什么关系四个具体场景技术原理之外普通人最关心的问题是这一切对自己意味着什么以下是几个具体的应用场景。场景一自由职业者的个人秘书一名自由撰稿人通常会在多个平台间切换——客户在微信沟通需求、稿件在飞书或腾讯文档中撰写、参考资料散落在浏览器收藏夹、发票在邮箱中等待整理。传统 AI 助手对此场景几乎无能为力——它每次都需要被告知我是谁、我在做什么、上次聊到哪里。部署一个 Hermes Agent 后情况发生改变Agent 通过消息网关常驻在飞书或企业微信用户在不同时间从不同设备发送指令Agent 凭借跨会话记忆延续上下文完成第一次整理客户需求并生成稿件大纲任务后Agent 自动提炼一份对应技能下次只需说按上次那个流程整理技能即被复用通过定时任务Agent 每周一早上 9 点自动汇总上周的客户沟通要点发送到指定渠道。场景二研究者的实验记录助手科研工作者在重复性实验中常常面临上次配置了什么参数、为什么这个步骤要这样做的记忆负担。Hermes Agent 的技能系统可以扮演结构化实验记录的角色第一次跑通一个数据预处理流水线后Agent 自动生成一份技能文档记录每一步的参数、依赖项、常见报错与验证方法后续若同事或自己半年后需要复现仅需调用同一技能技能在使用过程中如发现陷阱如 GPU 显存不足时的回退策略会自动迭代更新。这与 Jupyter Notebook 笔记不同——它不仅是被动的记录而是可执行、可调用、可演化的程序性知识。场景三小型团队的运维助手一支三五人的创业团队通常没有专职运维。Hermes Agent 配合 SSH 后端可以承担日常运维角色每晚定时执行数据库备份结果推送到团队的飞书群或钉钉群监控服务器告警自动诊断常见问题如磁盘满、进程崩溃并尝试修复团队成员在飞书或企业微信中用自然语言下达指令例如看一下昨晚的日志有没有异常——Agent 调用对应技能远程登录、检索、汇总、回复。这类场景中Hermes Agent 的技能积累特性较为有用——团队的运维经验会被自动沉淀为技能库新成员加入时可直接复用。场景四个人知识管理与生活助理对完全非技术背景的用户Hermes Agent 仍可作为长期的数字伴侣通过微信社区桥接或飞书与之对话记录每日想法、待办事项、阅读笔记Agent 学习用户的语言风格与关注主题逐步形成个性化画像当用户提出帮我把上周读到的那篇关于睡眠的研究找一下Agent 能够通过 FTS5 检索结合 LLM 摘要准确召回相关对话片段通过定时任务每月自动生成一份个人月报汇总当月的关注主题、待办完成情况与重要事件。需要补充的是上述数据均存储在用户自己的服务器上不流向第三方云厂商。这对隐私敏感的使用者而言是一项实际差异。局限性与挑战任何技术方案都有适用边界。客观看 Hermes Agent至少存在以下几方面的挑战。第一自生成技能的质量不可控。 由于技能由 Agent 在使用中自动提炼质量高度依赖早期任务样本的代表性。若早期任务存在偏差提炼出的技能可能将错误模式固化。该问题虽然可以通过自改进机制部分缓解但在缺乏外部评估信号的情况下存在自我强化错误的风险。第二可观测性不足。 一次 Hermes Agent 的运行可能涉及多轮推理、若干工具调用、子 Agent 派发与记忆读写。当结果偏差或成本异常时定位问题根源较为困难。阿里云等厂商已为其提供了可观测性插件从侧面反映了原生方案在该领域的不足。第三安全与权限边界。 自治程度越高的 Agent权限滥用的潜在风险越大。当 Agent 拥有持久记忆、可调用任意工具、可派发子任务时一次提示注入Prompt Injection攻击就可能造成持久性影响——例如恶意指令被固化为技能。Hermes Agent 通过命令审批机制、DM 配对、容器隔离等多层防御缓解此问题但风险并未完全消除。第四成本不可预测。 学习闭环中的技能提炼、记忆摘要、用户建模本身需要额外的 LLM 调用。对于轻度使用场景这部分元开销可能高于实际任务开销。Modal 与 Daytona 这类 Serverless 后端缓解了闲置成本但活跃使用阶段的 Token 消耗仍需关注。技术价值与启示抛开热度数据从纯技术角度看Hermes Agent 的价值在于围绕一个具体问题给出了完整解答Agent 如何具备长期记忆与长期能力。它的回答不是某个单点创新而是若干已有思路的组合——本地化的持久存储、自动提炼的技能体系、分层的记忆召回、统一的消息抽象、模型无关的路由层、多种隔离的执行后端。这些思路在论文与开源项目中并不罕见Hermes Agent 的工作是把它们整合成一套可运行、可部署、可持续迭代的系统。对于关注 Agent 技术的开发者可以从中提取出几条参考性的设计原则1. 状态管理优先于模型选择。模型可以替换状态与记忆是 Agent 的核心资产。2. 抽象层有助于应对快速演进的生态。模型路由层、消息网关层、ACP 协议都体现了这一点。3. 学习应当是闭环而非单次。把使用本身变成训练信号是个性化 Agent 的关键。4. 隔离用于控制复杂度。子 Agent 机制与七种沙箱后端是其在不同层面的体现。5. 可读性同样是工程质量的一部分。技能与记忆均以 Markdown 形式存在可被人类阅读、审计、修改。未来 Agent 的演进方向大概率会沿着更长的记忆、更强的工具使用、更深的个性化、更安全的执行边界展开。Hermes Agent 是其中一个具体的、可参考的实现样本。结语回到最初的问题一个 AI 助手怎样才算会记住你答案不在更大的模型而在它身边那一整套用于沉淀、检索、复用的工程机制。Hermes Agent 把这些机制兑现成了一个可以跑、可以部署、可以持续迭代的系统让成长这件事第一次具备了可观察、可重现的形态。对读者而言更值得带走的不是 Hermes Agent 本身而是它背后的判断标准决定 AI 助手能否长期可用的是周边的状态管理、上下文组织与执行隔离做得有多扎实。理解这一点再去看其他 AI 产品判断会更清楚一些。编辑于腾凯校对李嘉林欢迎在评论区留言与本文作者互动交流作者简介金一鸣硕士毕业于中南大学互联网算法工程师主要研究方向有强化学习LLMAgent搜索推荐等方向数据派研究部介绍数据派研究部成立于2017年初以兴趣为核心划分多个组别各组既遵循研究部整体的知识分享和实践项目规划又各具特色算法模型组积极组队参加kaggle等比赛原创手把手教系列文章调研分析组通过专访等方式调研大数据的应用探索数据产品之美系统平台组追踪大数据人工智能系统平台技术前沿对话专家自然语言处理组重于实践积极参加比赛及策划各类文本分析项目制造业大数据组秉工业强国之梦产学研政结合挖掘数据价值数据可视化组将信息与艺术融合探索数据之美学用可视化讲故事网络爬虫组爬取网络信息配合其他各组开发创意项目。点击文末“阅读原文”报名数据派研究部志愿者总有一组适合你~转载须知如需转载请在开篇显著位置注明作者和出处转自数据派THUIDDatapiTHU并在文章结尾放置数据派醒目二维码。有原创标识文章请发送【文章名称-待授权公众号名称及ID】至联系邮箱申请白名单授权并按要求编辑。未经许可的转载以及改编者我们将依法追究其法律责任。关于我们数据派THU作为数据科学类公众号背靠清华大学大数据研究中心分享前沿数据科学与大数据技术创新研究动态、持续传播数据科学知识努力建设数据人才聚集平台、打造中国大数据最强集团军。新浪微博数据派THU微信视频号数据派THU今日头条数据派THU点击“阅读原文”拥抱组织
