浙大开源HugAgentOS：三引擎一体自进化，每步可归因/回放/回滚

过去一年，Agent的任务执行能力提升很快。但另一个更基础的问题始终没有被解决：Agent不会进行自主积累与自主进化。

同一类任务执行过十次，第十一次仍然从零规划路径。上一次被纠正的错误，下一次照旧出现。用户在交互中投入的调教成本，随会话结束一同清零。

能力在增长，经验却不沉淀。

这不是仅加一个长期记忆模块就能补上的。要让经验真正长成能力，中间至少缺了四个环节：

• 经验沉淀不成能力：系统记得上一次这样做成功过，却无法在下一次自动复用这条路径；

• 单点能力形不成协同：真实任务需要多个能力配合，但协作方式本身从不被保留，每次都要重新规划；

• 自我迭代缺少仲裁：能够迭代自身的模块不止一个，一次失败会同时触发多方修改，产出彼此冲突的结果；

• 进化过程不可审计：改动是否有效、依据是什么、能否回退，全都无从追溯。

浙江大学省部共建协同创新中心开源的HugAgentOS正是沿着这四个环节展开的：把Harness拆成三个可以自我成长的引擎，再为这种成长加上两道关卡。

代码仓库：https://github.com/ZJU-REAL/HugAgentOS

桌面端下载：https://github.com/ZJU-REAL/HugAgentOS/releases

项目官网：https://hugagentos.com

记忆引擎：把每次任务的执行痕迹留存下来，有效经验持续沉淀，重复内容自动融合，过时信息逐步淡出；

技能引擎：把反复奏效的做法蒸馏成一个可复用的Skill，把「蒙对的偶然」变成「复制的必然」；

编排引擎：把多个Skill、工具、子智能体的稳定配合，整体固化成这类任务的默认打法。

另外，为了保证Agent进化能够在可控范围内，HugAgentOS还专门设计了两道关卡来进行防护：

归因关卡：三个引擎共用同一份执行证据，由归因模块统一裁定该不该改、该改哪一层；改动还要通过隔离回放验证、并经用户确认，才会真正生效；

本体关卡：把行业中的概念、关系与硬性约束写成机器可执行的规范，为三个引擎的进化划定边界。

所以HugAgentOS想解决的不只是怎样让Agent记住，而是经验如何长成能力、能力如何自行组队，以及这一切如何在可控的前提下发生。

先看这套机制运转起来是什么效果。

进化前后对照实验

用一个产业链调研任务做对照。让它执行两次，一次关闭系统自沉淀的能力，一次打开，其余参数完全一致。

第一次，关闭。

它凭模型已有的印象直接成文。哪家公司仍在存续、是否上市、专利数意味着什么，全部由模型自行判断。产出停留在对话框内。

第二次，打开。

它的执行路径完全改变：先检索，再逐家核验企业主体，未通过核验的一律不进入正文表格，最后按固定结构成稿，交付一份Word文档。

进化前后对比，除自沉淀能力开关外其余参数完全一致

第二次执行时，智能体身上多挂载了一个技能，名为产业链调研作业手册。

这个技能不是人工编写的，而是系统从自己的历史执行记录中蒸馏出来的。

第一步：从执行记录中蒸馏出技能

蒸馏由记忆引擎和技能引擎接力完成。

记忆引擎在留存的执行痕迹里识别出，同一类调研请求出现过8次，却用了6种不同的做法，每一次都在从零摸索。

技能引擎随即把其中反复奏效的2条路径提炼出来，合并成一套三步流程，每一步带检查点，末尾附上以往的失败记录。

这份蒸馏的技能手册正文中包含这样三条约束：

未核验的企业不得进入正文表格。

舆情检索结果全部为正面，不等于不存在风险，需要标注数据覆盖的盲区。

专利数量不等于技术实力。

三条都不是通用的写作建议，而是从该用户以往的失败案例中归纳出来的判断规则。

蒸馏产物以标准技能的形式落库，与人工编写的Skill走同一套体系：在技能库中可直接编辑；可随时启用或停用；支持分享给其他用户复用。

个人技能蒸馏，从历史会话提炼出可复用的SKILL.md

第二步：把稳定协作固化成默认打法

单个技能不足以覆盖真实任务。

复杂任务往往需要多个能力配合，这时候编排引擎接棒。

当多个技能、工具与子智能体反复以相同方式协作成功，系统会把这一整套组合固化成该类任务的默认打法。

以产业深度报告为例：

检索技能负责找资料；

可视化工具负责画图；

文档生成技能负责成稿；

评审子智能体负责挑刺。

四者的配合一旦被验证有效，会被整体封装成一套默认流程。

下次遇到同类任务，智能体不必从零判断该调用什么、按什么顺序调用，而是直接带着完整装备上场。

这就是三个引擎一体的意义。记忆引擎让经验留存，技能引擎把经验变成单项能力，编排引擎把多项能力变成一套打法。三级接力，构成一个越用越强的飞轮。

HugAgentOS分层架构，三引擎均可自进化，最下层负责划定边界

一次失败

只允许一个责任层

飞轮运转起来之后，新的问题随之出现。

三个引擎都有权修改自身，而一次任务失败会同时向三方发出信号。

举一个具体场景。一份调研报告里混入了一家已经退市的公司。

记忆引擎倾向于把这家公司的状态记录下来。

技能引擎倾向于在手册中追加一条核验步骤。

编排引擎倾向于更换数据源工具。

三方同时动手，得到的是三处互相冲突的修改。

因此HugAgentOS在三个引擎之前设置了归因模块。

它的职责不是找出该改哪里，而是先行裁定这次到底该不该改、该由哪一层负责。一次失败最多只允许一个责任层。

更关键的是，它有权判定任何一层都不需要改。

因为真实失败中有相当一部分内容根因并不在这三个引擎：例如知识库中本就没有这份资料，模型无法产出要求的格式，或者外部接口在前一天变更了返回结构。

这几类失败，修改记忆、技能或编排都没有意义。强行修改的结果，是产出一个永远无法修复该问题的方案，同时污染统计数据。

归因模块因此设定了三条不更新规则：

证据同时指向多个模块、无法区分责任时，不更新；证据强度不足时，不更新；判定根因不在自身时，不更新。

一次失败，只允许有一个责任人

确认需要修改之后，新能力也不会直接生效。

它要先在隔离环境中回放验证：把同一批历史任务重新执行一遍，只替换这一处，其余资产版本全部冻结，比对结果是否真的变好。

通过之后，还需经用户确认，才会进入正式能力体系。

整个过程在进化控制台中全程可见。每一条改动建议的来源、依据了哪几次历史任务、积累了多少条证据，都会完整呈现。用户确认后才生效，且随时可以撤回。

进化控制台，本账号促成的能力进化全程可查

领域本体

为进化划定可执行的边界

自进化的另一半是约束，这一层是领域本体。

团队把一个行业的知识写成一份机器可执行的领域本体库，包含四类内容。

一是概念。例如，企业风险领域本体定义了六个概念：领域实体、企业主体、风险事件、风险等级、证据来源、企业风险报告。每个概念带别名与继承关系，例如企业主体的别名包括公司、经营主体，定义为具有可唯一识别名称或统一社会信用代码的经营主体。

二是关系。例如风险事件需要有证据支持这条关系，支撑的证据最小基数为1，即高风险结论至少需要一个可追溯来源。

三是约束。例如，查询企业风险这个工具被规定必须先完成两步前置：先检索企业获取ID，再核验企业基本信息。

四是工作流，决定该类任务进入哪一档审查。企业风险分析这条流程的风险等级为高，审查档位是本体评审委员会，需要多个评审角色共同裁决。

这些规范位于所有动作之前。智能体若试图跳过核验直接查询风险，一道确定性门禁会当场拦截。

该门禁不经过LLM，命中哪条规范即返回哪条编号，毫秒级响应，不消耗任何Token。它给出的也不是一句拒绝，而是一条可执行的整改路径：先查企业ID，再核验主体，最后用同一个ID查询风险。

规则门禁，毫秒级返回命中的规范与整改路径

更关键的是，这条边界不只约束日常任务，同样约束进化本身。

三个引擎新沉淀出来的记忆、技能与打法，在正式启用之前同样要通过领域本体的校验。概念能否对应、必需工具是否齐备、输出契约是否合规，逐项核对。

开源信息

除自进化这条主线之外，HugAgentOS的基础能力覆盖了智能体从规划到交付的完整链路。

AgentSkills面向Word、Excel、PPT、PDF等办公与专业场景，MCP工具连接联网搜索、网页抓取、图表生成、报告导出等外部服务，Plugins承载更完整的业务流程。三者各自带市场，可持续扩展。

配合子智能体、私有知识库、计划模式、定时任务、自主循环、安全沙箱，一条链路内即可完成规划、协作、工具调用、文件读写与成果交付。

能力总览，子智能体、知识库、技能库、MCP工具库与插件库

项目由浙江大学人工智能省部共建协同创新中心研发维护，提供Docker Compose部署、一键命令安装与桌面客户端三种方式。桌面端覆盖Windows、macOS与Linux，可在本机与云端服务之间自由切换。

回到开头那四个环节：经验能否长成能力，能力能否自行组队，改错了有没有仲裁，改完了能否退回。

一百次任务之后，Agent留下的是一堆越来越长、越来越乱的历史记录，还是一套可沉淀、可归因、可回滚的能力资产，正在成为新的分水岭。

让智能体在可控的范围下越用越强。

参考资料：

https://github.com/ZJU-REAL/HugAgentOS

编辑：LRST