Agent自进化：从DeepSeek Harness看可回滚的脚手架工程

Agent 的能力提升，未必首先意味着重新训练一个更大的模型。很多时候，真正影响结果的是模型周围的脚手架：上下文如何组织，工具如何调用，规则如何执行，失败如何恢复，以及一次改动能不能被准确评估和安全撤销。

一场围绕 DeepSeek Harness 的技术分享，讨论了 Agent 自进化的难点、脚手架优化路径和工程落地方法。本文将会议内容重新整理为一套更适合工程实践的框架，重点关注一个核心问题：如何让 Agent 持续改进，同时不把线上服务变成不可控的实验场。

文中关于具体项目版本、实验效果和业界方案的描述，主要来自分享中的会议纪要。部分结论属于经验总结或方案解读，不应视为项目官方文档或确定的生产承诺。

一、Agent 自进化，究竟在进化什么

“自进化”容易被理解成模型自己训练自己，但在 Agent 系统中，至少存在三种不同的进化对象：

1. 模型权重：通过监督微调、强化学习或其他训练方法改变模型本身；
2. 脚手架配置：修改 Prompt、工具说明、路由规则、上下文模板和流程约束；
3. 运行时状态：在任务执行过程中积累经验、调整上下文或选择不同工具路径。

工程实践中，第二类通常更容易快速验证，也更适合做受控迭代。它不需要每次都重新训练大模型，但依然可能显著影响 Agent 的执行质量。

flowchart TD
    A[用户任务] --> B[Agent脚手架]
    B --> C[模型推理]
    C --> D[工具调用与环境交互]
    D --> E[执行轨迹]
    E --> F[评测与问题定位]
    F --> G[修改Prompt、工具说明或规则]
    G --> H{离线验证通过?}
    H -->|否| I[保留旧版本并分析失败样本]
    H -->|是| J[小流量线上实验]
    J --> K{业务指标改善?}
    K -->|否| I
    K -->|是| L[发布新版本]

这里的关键不是“让 Agent 自动修改自己”这句口号，而是建立一个可观测、可验证、可回滚的变更系统。

二、自进化为什么比普通 Prompt 优化难

1. 任务集必须足够大且覆盖均匀

如果只用少量任务验证一次改动，Agent 很容易在局部样本上变好，却在其他场景中退化。理想的评测集需要覆盖：

• Agent 支持的主要任务类型；
• 不同难度和输入分布；
• 常见成功路径与异常路径；
• 工具调用、文件操作、网络访问等不同能力；
• 真实用户任务和人工构造任务。

任务规模越大，评估成本越高；任务分布越复杂，越难判断一次提升究竟来自真正的能力改进，还是来自对评测样本的过拟合。

2. 低质量 Query 会污染优化方向

真实用户提交的 Query 并不天然适合训练或评测。有些请求缺少上下文，有些只包含模糊意图，还有些无法判断结果是否正确。

如果把这些数据不加筛选地投入自进化流程，可能导致：

• Agent 过度适应低信息量输入；
• 评测结果噪声增大；
• 优化方向被偶然样本带偏；
• 规则越来越多，但整体能力没有提升；
• 某些场景变好后，其他场景出现退化。

因此，数据治理本身就是 Agent 自进化系统的一部分。至少应保留任务来源、任务类型、可验证目标、执行轨迹和最终评价，而不是只保存一条自然语言 Query。

3. Reward 很难覆盖完整执行过程

Agent 的结果通常不是一步生成的，而是经历理解任务、规划、调用工具、读取结果、修正策略和提交答案等多个阶段。

如果只奖励最终文本，系统可能无法区分：

• 过程正确但最终输出格式错误；
• 结果碰巧正确但执行路径危险；
• 使用了过高权限工具；
• 修改了不该修改的文件；
• 花费大量 Token 和时间后才得到结果。

这使得 Agentic RL 的 Reward 设计难度很高。奖励函数不仅要衡量最终结果，还要考虑过程质量、安全边界、资源成本和可复现性。

三、Agent 自进化的两条主路径

路径一：Agentic RL

Agentic RL 通过强化学习训练模型，使其在 Agent 环境中获得更好的任务表现。它的理论上限较高，但工程门槛也更高：

• 需要大量高质量任务和环境；
• 需要设计覆盖执行过程的奖励函数；
• 需要控制训练成本和样本效率；
• 需要防止模型为了奖励投机取巧；
• 需要验证新能力是否损害旧能力。

它更像是一项完整的训练系统工程，不适合作为所有团队的第一步。

路径二：脚手架分析与迭代

另一条路径是直接分析 Agent 的执行轨迹，从失败样本中归纳问题，再修改：

• System Prompt；
• 工具描述；
• 任务路由规则；
• 上下文拼接方式；
• 计划与执行流程；
• 错误处理和重试策略。

这条路径的优点是反馈快、改动可解释、上线成本相对低。缺点是容易陷入局部最优：针对某一批失败样本不断加规则，最终得到一个越来越复杂却不一定更强的脚手架。

因此，脚手架迭代必须配合固定验证集、回归测试和版本化管理，不能只看单个 Case 是否修好。

四、DeepSeek Harness 的设计启发

根据分享内容，DeepSeek Harness 的定位并不是已经实现完整的 Agent 自进化，而是为“安全修改 Agent 脚手架”提供一个标准化底座。

它的核心思路可以概括为：把容易变化的部分从极简内核中拆出来，把每次变更变成可登记、可追踪、可撤销的插件操作。

1. 极简内核与插件分离

内核只保留 Agent 运行所必需的基础能力，其他上下文管理、规则逻辑和策略模块都以插件形式实现。

flowchart LR
    A[极简内核] --> B[插件调度]
    B --> C[上下文插件]
    B --> D[工具规则插件]
    B --> E[任务路由插件]
    B --> F[错误处理插件]
    C --> G[追加式事件日志]
    D --> G
    E --> G
    F --> G
    G --> H[评测、审计与回滚]

这样做的直接收益是：

• 优化某个规则时不必修改内核；
• 不同插件可以独立测试和版本管理；
• 变更影响范围更容易界定；
• 可以针对不同任务组合不同插件；
• 出现问题时能定位到具体插件版本。

插件化并不自动带来安全性。真正重要的是插件边界、权限模型、依赖关系和生命周期都必须被明确描述。

2. 强制登记撤销方法

一个很有价值的设计是：每个插件修改必须同时登记对应的撤销方法。

可以把一次变更抽象为：

Change = {
  target: 被修改的插件或规则,
  apply: 如何应用变更,
  undo: 如何撤销变更,
  metadata: 变更原因、版本、评测结果和操作者
}

如果只有 apply 没有 undo，系统就无法保证快速恢复。强制撤销登记相当于把“可回滚”从运维承诺变成上线前的结构化约束。

在实际系统中，撤销方法还需要满足几个条件：

• 能够幂等执行；
• 不依赖已经被新版本删除的数据；
• 回滚后状态可被验证；
• 能恢复配置、路由、工具权限和上下文策略；
• 能关联到具体的变更版本和实验批次。

3. 上下文只追加，不原地修改

如果 Agent 的历史上下文可以被任意覆盖，问题发生后很难回答：当时 Agent 看到了什么？哪个插件追加了哪段信息？哪一次修改改变了决策？

追加式上下文的基本思想是：

• 原始事件只写入，不覆盖；
• 新信息以新事件或新版本追加；
• 当前视图由事件重放或投影得到；
• 历史记录可用于审计、回放和问题定位。

sequenceDiagram
    participant U as 用户
    participant R as Agent运行时
    participant P as 插件
    participant L as 事件日志
    U->>R: 提交任务
    R->>L: 追加用户输入
    R->>P: 触发插件
    P->>L: 追加上下文事件
    P->>L: 追加工具调用事件
    L-->>R: 重放当前上下文视图
    R->>U: 返回结果
    Note over L: 历史事件不覆盖，变更可审计

这与传统“直接修改一份上下文对象”的方式不同。它会增加存储和投影复杂度，但换来了更强的可追溯性。

4. Waterfall 式事件接力

插件按照明确顺序接力执行，每个阶段消费前一阶段的结果，并生成新的事件或状态。

这类 Waterfall 机制适合强调：

• 执行顺序；
• 阶段边界；
• 输入输出契约；
• 依赖关系；
• 全链路观测。

它不一定适合所有 Agent。对于需要并行探索的任务，可能还需要并行分支、合并节点和超时控制。但即使采用并行执行，也应保留清晰的事件关系，而不是让插件之间互相读写共享状态。

5. 状态与处理逻辑隔离

会话状态统一存储在独立日志层，插件主要负责读取和处理数据，不直接修改底层历史状态。

这可以降低几类风险：

• 插件误删上下文；
• 不同插件互相覆盖结果；
• 回滚时无法恢复原始状态；
• 一个任务的临时修改泄漏到其他任务。

真正落地时，还需要进一步设计租户、会话和任务级隔离，不能只依靠插件开发者自觉遵守约定。

五、线上自进化必须先解决控制问题

在线自进化的吸引力在于：Agent 可以边服务边学习，甚至在单个任务执行过程中动态调整策略。但它也带来更高风险。

至少要同时解决三件事：

1. 服务可用性：优化过程不能阻塞或破坏正常请求；
2. 变更可回滚：出现退化时能快速恢复稳定版本；
3. 任务互不干扰：一个会话的实验状态不能污染其他会话。

因此，线上自进化不应直接修改全局生产配置。更稳妥的流程是：

flowchart TD
    A[线上执行轨迹] --> B[脱敏与质量筛选]
    B --> C[离线问题归因]
    C --> D[生成候选脚手架变更]
    D --> E[固定评测集回归]
    E --> F{是否出现能力退化?}
    F -->|是| G[拒绝候选变更]
    F -->|否| H[沙箱或小流量实验]
    H --> I{线上指标是否改善?}
    I -->|否| J[撤销并记录原因]
    I -->|是| K[扩大流量并保留回滚点]

“在线”更适合指数据和反馈在线产生，而不是允许 Agent 不经审核地在线修改所有生产行为。

六、从执行轨迹到可落地闭环

一个可运行的 Agent 优化系统，至少需要以下数据链路：

1. 采集完整执行轨迹

只保存最终答案是不够的。应尽量记录：

• 用户任务和任务类型；
• 每一步模型输入输出；
• 工具调用参数和返回值；
• 上下文版本和插件版本；
• 延迟、Token、资源消耗；
• 错误、重试和中断原因；
• 最终结果与评价。

采集时要注意隐私、权限和敏感数据脱敏，不能为了可观测性无限制保留原始用户内容。

2. 自动归因，而不是只统计成功率

成功率只能告诉你结果是否变好，不能说明为什么变好或变坏。可以按以下维度对失败轨迹分类：

• 任务理解错误；
• 计划不完整；
• 工具选择错误；
• 参数或权限错误；
• 上下文缺失；
• 中间结果未验证；
• 重试失控；
• 最终输出不符合验收标准。

归因之后，才能判断应该改 Prompt、工具描述、上下文结构还是验证器。

3. 固定集与线上 A/B 双重验证

AI 生成的优化方案不能直接全量发布。建议至少经过：

1. 固定验证集回归；
2. 关键场景和历史失败样本复测；
3. 沙箱或小流量 A/B 实验；
4. 线上业务指标对比；
5. 版本冻结和回滚点保留。

线上指标也不应只看任务成功率，还可以观察 P95 延迟、Token 成本、工具错误率、人工接管率和安全告警数。

七、当前方法的边界

1. 从低水位到中水位更容易

当 Agent 还有明显的基础缺陷时，修复工具调用、上下文缺失或流程遗漏，往往能带来较明显的提升。但当系统已经达到较高准确率后，剩余错误通常更分散、更难归因。

从 90% 提升到 95%，不只是多修几个 Bug，可能意味着需要更细的任务分层、更可靠的验证器和更严格的数据治理。

2. 经验优化不等于全局最优

当前的脚手架进化，大多是从轨迹中发现问题，再尝试一组修改。这是一种有效的工程迭代方式，但并不能证明已经找到全局最优方案。

因此，工程团队应保留：

• 改动假设；
• 对照实验；
• 未生效的尝试；
• 适用范围和副作用；
• 仍未解决的失败样本。

把一次优化写成可复盘的实验，而不是只保留“最终版本”，有助于避免系统不断重复无效尝试。

3. 插件化也会引入复杂度

插件拆分可以降低单点修改风险，但插件数量增加后，也会出现：

• 插件依赖关系复杂；
• 新增和删除插件需要大量配套配置；
• 调试链路变长；
• 多 Agent 之间的隔离更难；
• 版本组合数量快速增长。

因此，插件化的目标不是把所有逻辑都拆成插件，而是把变化频繁、边界清晰、值得独立验证的部分拆出来。

八、给 Agent 工程师的实践建议

1. 先把单 Agent 的基本链路做扎实

不需要一开始就追逐多 Agent、动态工作流等复杂范式。更值得先理解：

• 上下文如何构建；
• 工具如何注册和调用；
• 任务如何规划和执行；
• 错误如何反馈给模型；
• 结果如何验证；
• 日志如何记录和回放。

当单 Agent 的执行链路和失败边界足够清楚后，再讨论多 Agent 协作，才不会把问题隐藏在更复杂的编排中。

2. 做一个可回放的最小 Harness

个人练习可以从一个小型 Harness 开始，至少具备：

• 一个明确的任务集合；
• 一个版本化的 Prompt 和工具描述；
• 一份追加式执行日志；
• 一个固定验证集；
• 一个简单的插件加载机制；
• 一个可执行的撤销操作；
• 一份变更前后的对比报告。

即使只支持本地文件分析或代码测试，也足以训练 Agent 工程所需的系统思维。

3. 面试中不要只讲“用了什么模型”

更有价值的项目表达方式是：

我遇到了什么问题？如何通过轨迹和指标定位？修改了哪个环节？为什么选择这个方案？结果如何验证？有没有引入新的风险？

即使负责的不是核心模块，也可以从模块边界、接口设计、失败处理和业务价值出发，把自己的工作讲清楚。

结语

Agent 自进化真正困难的地方，不是让模型生成一段“自我优化”的代码，而是让每一次变化都具备可观测性、可验证性和可逆性。

DeepSeek Harness 带来的重要启发，是把 Agent 脚手架当成一个可以版本化、插件化和审计的系统：

• 内核保持稳定，变化放进边界清晰的插件；
• 上下文只追加，原始事件可回放；
• 每个变更都登记撤销方法；
• 离线评测和线上实验分层进行；
• 任何自动优化都必须保留回滚点。

当这些基础设施建立起来后，Agent 的“自进化”才不会停留在概念演示，而会逐步变成一种可以被团队管理、被数据验证、也能在出现问题时及时收回的工程能力。