浙大开源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，再核验企业基本信息。 四是工作流 ，决定该类任务进入哪一档审查。企业风险分析这条流程的风险等