自我进化Agent自改规则，谁来审批？

AI Agent 正在学会修改自己的规则。近期两篇论文将「Agent Harness」——包括提示词、记忆、工作流、工具和代码片段在内的软件脚手架——从静态配置升级为可进化的对象。模型权重保持不变，变化的是承载它的这层软件，而且这种变化会在多次运行之间持久保留。这带来一个运营层面的核心问题：谁来决定哪些变更可以沉淀下来？

Agent Harness 成为进化目标

传统上，Agent 的 harness 被视为一次性配置：写好 prompt、接上工具、设计好工作流，然后部署运行。即便模型不换，这套外围结构也在悄悄积累经验——比如某次成功的工具调用顺序、某段被验证有效的记忆片段。论文正式把这种「边跑边改」的过程当作研究对象：模型固定，进化的是定义 Agent 看什么、调什么、怎么决策的软件层。

状态变更 vs. 结构修订

Self-Evolving Agent Harness（arXiv:2610.18813）区分了两类改动：一类是状态层面的，比如修改 prompt、更新记忆内容；另一类是结构层面的，比如修订工具定义、调整仓库逻辑、重新组合插件。前者像改参数，后者像改规则。论文提出用带独立验证的「准入机制」来把关，并讨论了当任务分布和评估器本身也在变时，泛化边界会变得模糊。

「Agent Harness」这个说法借自软件测试与仿真领域，原指包裹被测对象、提供运行环境与记录能力的外壳。在 LLM Agent 语境下，它泛指模型权重之外、由工程团队编写和维护的全部外围软件：系统提示词、上下文拼接逻辑、记忆的写入与检索策略、工具（函数调用）的 schema 与实现、多步工作流的编排代码、重试与解析逻辑等。区分「模型能力」与「harness 能力」是理解自进化研究的前提：同一个模型在精心调校的 harness 下与在粗糙 harness 下表现可以相差很大，因此 harness 本身是一个值得优化的对象。传统 harness 由人类工程师离线迭代，自进化研究则让 Agent 在运行中自动产生 harness 修改提案。

「状态」与「结构」的区分在计算机系统里由来已久：状态是运行期可变的数据（内存内容、缓存、会话记录），结构是定义系统如何行为的代码与规则（函数定义、类型、协议）。映射到 Agent harness，prompt 文本和记忆条目属于状态，改错了影响有限且容易回滚；工具定义、评估器实现、插件组合方式属于结构，一旦被改写，影响的是后续所有运行的行为逻辑与判断标准。这种区分之所以重要，是因为两者的风险与审批要求并不对等：状态变更可以用较宽松的自动化门控，结构修订则需要更强的独立验证，甚至人类签字。类似的思想在数据库 schema 迁移、基础设施即代码的变更管理中都有对应实践。

双层递归：Harness² 的野心

Harness²（arXiv:2610.14224）把自进化推到第二层：既可以在当前任务执行过程中递归地编辑正在运行的 harness，也可以在「改进 harness 的 harness」层面递归，把每次编辑中积累的经验用于下一轮。论文报告称，在专业基准测试中，仅一步演化就让 GLM-5 和 Gemini 3.5 Flash 的配置在基础 harness 之上取得了性能提升。

这一结果的意义不在于「自进化能不能跑通」，而在于它把问题从研究假设变成了生产部署的现实选项。

「递归自我改进」的思想可追溯到古德（I. J. Good）1965 年提出的智能爆炸假说，以及施密德胡贝尔（Jürgen Schmidhuber）关于自指改进系统的形式化工作，其核心是系统把改进自身的能力也作为改进对象。Harness² 的「双层」正是这一结构在工程层面的轻量版本：第一层是任务执行期间就地编辑正在使用的 harness，第二层是维护一个专门负责改进 harness 的元过程，把历次编辑的成败经验沉淀为下一轮编辑的先验。需要强调的是，这里被递归优化的是软件脚手架而非模型权重，因此不涉及梯度更新或再训练，成本与可控性都远低于模型层面的自改进，但也意味着改进上限受限于 harness 的表达能力。

生产能力开放给 Agent 的风险

对跑生产 Agent 的团队来说，真正要回答的问题不是自进化是否有效，而是谁拥有持久化变更的审批权。一次成功运行总结出的「经验」，可能固化成为永久规则——包括那条用来评判下一轮变更的规则本身。如果变更提案和验收标准都留在同一个循环里，系统就在事实上开始自我治理，而没有清晰的人类审批链路。

这并非危言耸听。论文讨论的准入机制和独立验证，本质上就是在回应这个治理缺口。放到工程实践中，持续验证、回归预算、以及「Agent 可以提议什么」与「Agent 可以写入共享 harness 什么」之间的分离，从研究细节变成了工程必需。

落地清单：三条硬性要求

第一，清点 harness 中哪些部分允许被重写。不是所有组件都应该向自进化开放，工具定义和评估逻辑尤其需要保护。第二，在将变更持久化之前，要求新鲜证据和独立验证——不能用旧数据或同一循环内的判断来批准新规则。第三，保留回滚能力和版本标识，确保下一次运行时 Agent 继承的是明确版本，而非来历不明的累积修改。

「谁批准变更」在软件工程中已有成熟对应物：代码评审与合并权限。Git 等版本控制系统的核心设计之一，就是把「提出修改」与「批准合入」分成两个角色，并通过分支隔离保证主干始终处于已知良好状态。把 Agent harness 视为受版本控制的代码仓库，可以自然推导出几条工程惯例：变更需以补丁或 PR 形式提交并留痕、合并前需通过独立于提案者的测试、主干保留可回退的历史版本、敏感文件（如评估逻辑）设置保护分支。此外，业界常说的「评估器污染」风险在此同样适用——若 Agent 能修改用于评判自己的测试或评分脚本，任何性能提升数字都将失去意义，这也是要求验收标准与提案路径分离的根本原因。

关键要点

• 近期研究将 Agent Harness（提示词、记忆、工具、工作流）作为可进化对象，模型本身保持固定。
• Self-Evolving Agent Harness 区分状态变更与结构修订，并引入独立验证的准入机制。
• Harness² 实现双层递归，一步演化即在 GLM-5 和 Gemini 3.5 Flash 配置上带来性能提升。
• 生产风险在于变更提案与验收标准同处一个循环，人类审批链路缺失。
• 工程上需限定可重写范围、要求新鲜验证证据、保留回滚与版本标识。

没有这些边界，Agent 就在没有负责人签字的条件下修改游戏规则。