Agent 自进化：Harness 工程、技术路径、工程闭环与现实边界 深度专题

1、一个谨慎的定义#

可以将 Agent 自进化定义为：

Agent 系统在持续执行任务的过程中，通过记录行为数据、分析反馈结果、沉淀可复用经验，并将这些经验优先作用于 Harness 层的 Prompt、Context、Tool、Skill、Memory、Workflow、Evaluation、Guardrail 和 Deployment Policy；当经验足够稳定、数据质量足够高、评测足够可靠时，再进一步作用于训练数据、Adapter 或模型参数，从而在后续任务中提升成功率、稳定性、效率、安全性和适应性的过程。

这个定义刻意避免两个极端：

• 一端是把任何 Prompt 修改都称为“自进化”，这会把概念稀释成普通优化；
• 另一端是把自进化等同于模型自动训练和自动上线，这会低估工程治理、安全评估和数据质量的重要性。

更准确地说，Agent 自进化是一组从浅到深的能力提升机制，而不是一个单点能力。

2、从不同角度理解 Agent 自进化#

1
Agent Runtime
2
→ Trace / Telemetry
3
→ Evaluation
4
→ Failure Analysis
5
→ Dataset Construction
6
→ Optimization
7
→ Model / Prompt / Skill Versioning
8
→ Canary Release
9
→ Production Monitoring
10
→ Feedback Collection

3、一个贯穿式小例子：代码 Agent 如何变好#

为了让三层概念更具体，可以看一个代码 Agent 修复测试失败的例子。

第一轮运行时，用户要求 Agent 修复一个后端接口 bug。Agent 读取代码后直接修改文件，但没有先运行相关测试，结果补丁虽然看起来合理，却引入了新的边界条件错误。这时系统可以先在 Harness 层 做低成本修复：Prompt 增加“修改前先定位失败测试”的约束，Tool Schema 明确 run_tests 的参数和返回结构，Workflow 固化为“定位失败 -> 最小修改 -> 运行测试 -> 生成 diff 摘要”，Guardrail 要求大范围删除前必须人工确认。

第二轮运行时，Agent 仍然在某类异常输入上失败，但这次系统记录了完整 Trace：用户需求、读取的文件、测试命令、失败日志、工具调用参数、补丁 diff、重试动作、最终测试结果和人工修复。这个 Trace 不直接拿去训练，而是进入 Trace-to-Dataset 层：失败样本进入回归集，人工修复前后的差异进入偏好样本，稳定成功路径进入 Skill 候选，高风险文件操作进入安全样本。

当同类修复在多个项目中反复出现，并且 Harness 修复已经被回归集证明有效，系统才考虑进入 模型层：把稳定的测试修复模式做成 SFT 样本，把“错误补丁 vs 人工修复补丁”做成 DPO 偏好对，或者把小模型蒸馏成专门负责错误分类和测试选择的辅助模型。训练完成后，新模型仍然要回到 Harness 中接受工具约束、回归评测、灰度和回滚。

这个例子说明：自进化不是“模型自己偷偷训练自己”，而是一次失败先变成 Harness 修复，再变成可治理数据，最后在条件成熟时才变成模型能力。

4、核心术语表#

1、为什么第一层是 Harness#

从工程落地看，Agent 出问题时，第一原因往往不是“模型完全不会”，而是模型外部的执行条件不够好：任务边界不清、上下文污染、工具 schema 含糊、Memory 误用、Workflow 缺失、评测不可靠、权限和回滚机制不足。

这些都属于 Harness 问题。Harness 可以理解为包裹在模型外部的任务执行系统，它负责把模型能力组织成可用、可控、可观测的业务行为。它不改变模型权重，但会直接改变 Agent 的实际表现。

把 Harness 放在第一层，有三个原因：

1. 成本最低：Prompt、Context、Tool Schema、Workflow、Memory、Guardrail 通常可以快速迭代，不需要训练资源；
2. 反馈最快：一次 Harness 变更可以立刻进入评测和灰度，不必等待完整训练周期；
3. 迁移性最好：当底层模型升级时，高质量工具接口、评测集、Workflow、Memory 治理和权限策略通常仍然可复用。

因此，本文不把 Prompt、Memory、Workflow、Reflection 看成和 Harness 并列的路线，而是把它们都归入 Harness 的可进化子模块。具体每个子模块如何自进化，放到第五章集中展开。

2、为什么第二层是 Trace-to-Dataset#

Harness 层可以快速修复问题，但如果没有 Trace 和评测，团队很难知道修复是否真的有效。一个 Prompt 改动可能让某类任务变好，也可能让另一类任务退化；一个 Memory 策略可能减少重复提问，也可能引入错误记忆；一个 Workflow 可能提高稳定性，也可能降低开放任务的灵活性。

所以第二层不是“数据层自进化”，而是 Trace-to-Dataset。它的作用是把 Harness 运行中产生的行为轨迹、失败样本、成功路径、人工修复和评测结果，转成可复盘、可评测、可训练的数据样本。

这一层有两个方向：

1. 向前反哺 Harness：失败 Trace 进入回归集，成功 Trace 沉淀为 Skill，人工修复反过来修 Prompt、Tool Schema、Memory 和 Guardrail；
2. 向后服务模型升级：高质量 Trace 被构造成 SFT 样本、偏好样本、工具调用样本、Reflection 样本、安全样本或 RL 轨迹。

这就是为什么 Trace-to-Dataset 是中间层。它不直接让模型变强，但它决定后续优化是否有证据、有样本、有边界。具体 Trace 如何采集、如何评测、如何构造样本、如何做质量门禁，放到第六章展开。

3、为什么第三层是模型层#

模型层自进化指的是 SFT、DPO、RLHF、RLAIF、RFT、Agentic RL、Adapter 或模型升级。它的目标是把已经被验证过的稳定经验固化到模型中，让能力不再完全依赖外部 Prompt、Workflow 或 Memory。

把模型层放在第三层，而不是第一层，是因为训练成本和风险都更高。训练需要高质量样本、可靠评测、回归集、安全门禁、灰度发布和回滚机制。如果前两层没有做好，后训练很容易把错误经验、偶然成功、越权路径或过时规则固化进模型。

模型层更适合处理三类已经稳定的问题：

1. 高频、稳定、可验证的格式和领域表达；
2. 反复出现、已经被 Harness 验证有效的工具调用模式；
3. 长期有价值、可通过偏好或奖励定义的策略选择。

特别是小模型后训练，还要面对一个现实问题：训练成本很高，但收益可能被下一代大模型的一次升级快速覆盖。相比之下，Harness 资产和 Trace-to-Dataset 资产更容易迁移到新模型上。因此，本文把模型层视为“稳定经验的固化出口”，而不是自进化的第一入口。具体 SFT、DPO、RLAIF、Agentic RL 和模型升级边界，放到第七章展开。

4、三层边界：每一层改变什么#

为了避免把三层混成一个模糊概念，可以用边界表来区分：

这个表也说明了一个关键判断：三层不是能力强弱的排序，而是成本、风险和固化程度的排序。越往后，经验越稳定，改动越重，回滚越难；因此越需要前一层提供证据。

5、三层之间如何形成闭环#

三层架构不是一条只向前走的流水线，而是一个闭环：

1
Harness 层快速试错
2
→ Trace-to-Dataset 记录、评测、筛选、样本化
3
→ 模型层固化稳定经验
4
→ 新模型回到 Harness 中接受工具约束、评测门禁、灰度和监控
5
→ 线上行为再次产生 Trace

这也是本文的核心判断：Agent 自进化不是单点算法，而是一个分层工程闭环。短期收益通常来自 Harness，中期壁垒来自 Trace-to-Dataset，长期能力固化来自模型层。把这三层分开，才能避免把普通 Prompt 调参、日志收集和后训练都混称为“自进化”。

1、Harness 层的技术来源：从外部脚手架到可治理运行时#

Harness 层的技术来源非常丰富。ReAct、Reflexion、Self-Refine、MemGPT、Voyager、Toolformer、Anthropic workflow、OpenAI Agents SDK、Martin Fowler harness engineering 等资料虽然侧重点不同，但都在指向一个结论：Agent 的可靠性来自模型和外部运行时系统的共同设计。

2、Trace-to-Dataset 的技术来源：从评测、观测到样本构造#

Trace-to-Dataset 层的技术来源主要来自 Agent 评测、生产观测和数据治理。AgentBench、GAIA、SWE-bench、τ-bench、AI Agents That Matter、OpenTelemetry GenAI、OpenAI Agents SDK tracing、Langfuse、Phoenix、LangSmith 等工作共同说明：Agent 的行为必须被记录、评测、分类和样本化，否则无法判断进化还是退化。

1
线上运行
2
→ 采集 Trace / Metrics / Feedback
3
→ 标注成功、失败、风险、成本
4
→ 聚类失败模式
5
→ 生成候选修复：Prompt / Tool Schema / Skill / Memory / Dataset
6
→ 离线评测与回归
7
→ 灰度发布
8
→ 线上监控
9
→ 反馈回流

3、模型层的技术来源：后训练、偏好优化与 Agentic RL#

模型层的技术来源包括 SFT、DPO、RLHF、RLAIF、RFT、Agentic RL、Adapter 和模型升级。它们解决的是如何把已经被 Harness 和 Trace-to-Dataset 证明有效的稳定经验固化到模型中。

4、小结：前沿共识正在从“模型智能”转向“系统智能”#

把上述线索合在一起，可以看到 Agent 自进化的研究重心正在发生变化：

• 从单次回答质量，转向多轮任务成功率；
• 从 Prompt 技巧，转向 Trace、Eval、Memory、Tool 和 Workflow 的系统工程；
• 从无约束自动学习，转向有门禁、有版本、有回滚的受控优化；
• 从只看模型参数，转向模型、工具、数据、流程和组织治理的组合能力。

这也解释了为什么技术大牛和前沿论文虽然关注点不同，却越来越接近同一个结论：Agent 的下一阶段竞争，不只是更强的 base model，而是谁能建立更可靠的行为数据闭环、更真实的评测环境、更可治理的工具与记忆系统，以及更安全的发布机制。

1、为什么 Harness 自进化比后训练更适合作为起点#

很多自进化叙事会天然走向后训练：收集数据、构造样本、训练模型、上线新版本。这条路线当然重要，但它有三个现实门槛。

第一，成本高。后训练需要数据清洗、标注、训练资源、评测、回归、安全审查和发布治理。对于多数企业应用来说，早期问题往往不是模型完全不会，而是工具描述不清、上下文混乱、流程不稳定、评测缺失、权限边界不清。直接训练模型，容易把工程问题误判成模型问题。

第二，迭代慢。Prompt、Tool Schema、Workflow、Memory 策略通常可以按天甚至按小时迭代；后训练往往按周或月推进。业务规则、工具接口和组织流程变化很快时，先做 Harness 调整比频繁训练模型更现实。

第三，迁移性弱。围绕小模型做昂贵后训练，可能很快被下一代大模型的一次能力升级覆盖。相比之下，高质量 Harness 更像可迁移资产：评测集、工具 schema、Workflow、权限策略、Trace 数据和 Memory 治理规则，通常可以随着模型升级继续复用。

因此，本文更推荐把 Harness 自进化作为第一主线：先用低成本工程闭环吸收经验，再把经过反复验证的稳定模式通过 Trace-to-Dataset 转成评测样本、偏好样本和训练样本，最后在必要时通过后训练完成能力固化。

2、Harness 子模块总览#

Harness 可以理解为模型外部的“任务操作系统”。它不替代模型智能，而是组织和约束模型智能，让模型能在真实环境中稳定完成任务。

这个表的关键含义是：Prompt 和 Memory 不是 Harness 之外的独立路线，而是 Harness 内部的可进化部件。一个成熟 Agent 系统不应该只问“Prompt 怎么写得更好”，而应该问“Prompt、Context、Tool、Memory、Workflow、Eval 是否能在同一个版本体系和评测体系下共同变好”。

以一个企业客服 Agent 为例，Harness 各模块的进化可以这样落到同一条业务链路里：

这个例子说明，Harness 自进化不是某个单点技巧，而是多个运行时模块围绕同一业务目标共同变好。

3、Prompt / Instruction：从提示词调参到指令版本治理#

Prompt 是 Harness 中最容易被修改、也最容易被滥用的模块。它负责表达任务目标、角色边界、输出契约、工具使用原则和少量关键策略。Prompt 自进化不是无限追加规则，而是根据失败样本和评测结果，让指令变得更短、更准、更可测。

自进化对象：

• 任务说明是否清晰；
• 输出格式是否稳定；
• 拒绝边界是否明确；
• 工具调用规则是否可执行；
• 多步骤任务是否有必要的检查点；
• 对不同任务类型是否应该分层 Prompt，而不是一个大 Prompt 包打天下。

自进化动作：

• 从失败 Trace 中抽取“遗漏规则”，生成候选 Prompt patch；
• 从人工修复中提炼更明确的输出契约；
• 把臃肿 Prompt 拆成 system / developer / task / tool-use / output-format 多层结构；
• 对同一任务生成多个 Prompt 候选，跑回归集和成本评测；
• 把稳定、重复、可执行的步骤迁出 Prompt，沉淀为 Skill 或 Workflow。

产物与门禁：

Prompt 变更应该形成版本、变更说明、适用范围、关联失败样本和回归结果。一个 Prompt patch 只有在核心任务集、历史失败集、安全集和成本集上都不退化，才适合进入灰度。Prompt 自进化最常见的风险是过拟合局部样本、规则膨胀、互相矛盾和 token 成本上升。

4、Context：让模型看到正确、足够、可追溯的信息#

Context 决定模型每次任务中看到什么、不看什么、以什么顺序看。很多 Agent 失败不是因为模型不会推理，而是因为上下文里缺了关键信息、混入了过期信息，或者重要证据被噪声淹没。

自进化对象：

• 检索 query 如何生成；
• 检索结果如何排序；
• 长上下文如何裁剪；
• 多轮任务状态如何摘要；
• 哪些信息应该进入短期上下文，哪些应该进入 Memory；
• 证据来源、时间、可信度和冲突关系如何呈现给模型。

自进化动作：

• 根据失败 Trace 判断是否因为缺证据、错证据、旧证据或噪声过多导致失败；
• 调整检索策略、top-k、rerank、过滤规则和上下文排序；
• 对长任务生成状态摘要，并记录摘要来源；
• 引入 source score、freshness score、permission label；
• 对带上下文和不带上下文的结果做对照评测。

产物与门禁：

Context 自进化的产物不是单个 Prompt，而是 context policy、retrieval policy、summary policy 和 evidence policy。它的门禁重点是：幻觉是否下降、引用是否可追溯、上下文长度是否可控、旧信息污染是否减少。风险是过度裁剪导致关键信息丢失，或过度检索导致模型被噪声拖偏。

5、Tool Schema：把工具接口变成稳定可控的行动边界#

工具是 Agent 进入真实世界的接口。只要 Agent 能调用数据库、代码执行器、浏览器、企业 API 或文件系统，它就不再只是生成文本，而是在改变外部状态。Tool Schema 自进化的目标，是让模型更稳定地选择工具、生成参数、理解返回结果，并在失败时可恢复。

自进化对象：

• 工具命名是否明确；
• 参数 schema 是否充分约束；
• required / optional 参数是否合理；
• 返回结果是否结构化；
• 工具描述是否说明“何时调用”和“何时不要调用”；
• 是否标注副作用、幂等性、权限、成本和风险等级；
• 工具失败是否有可恢复路径。

自进化动作：

• 从工具调用失败 Trace 中统计高频错误参数；
• 自动生成 schema patch，例如枚举值、范围限制、格式校验、默认值说明；
• 把自然语言返回改成结构化返回；
• 为高风险工具增加确认步骤、dry-run、preview 或人工审批；
• 为常见失败码绑定恢复策略。

产物与门禁：

Tool Schema 变更必须跑工具调用回归集，关注参数正确率、工具选择准确率、失败恢复率、越权率和成本。风险是工具描述过长导致选择困难，schema 过严导致模型无法处理边界情况，schema 过松导致越权或错误写入。

6、Skill / Workflow：把成功路径沉淀为可复用流程#

Skill 和 Workflow 负责把高频、稳定、可审计的成功路径变成可复用资产。它们的价值在于减少模型自由探索，把专家经验、成功 Trace 和组织流程沉淀成可测试、可版本化、可回滚的工程模块。

自进化对象：

• 哪些任务路径重复出现；
• 哪些成功 Trace 具有可复用性；
• 哪些人工 SOP 可以转成可执行流程；
• Workflow 中哪些步骤应该固定，哪些步骤仍交给模型判断；
• Skill 的触发条件、输入输出、权限和适用范围是否清晰。

自进化动作：

• 从多次成功 Trace 中抽取共同步骤，生成候选 Skill；
• 将人工修复流程转成 Workflow；
• 为 Skill 添加输入输出契约、测试用例、权限标签和版本号；
• 对 Skill 进行聚类、合并、弃用和冲突检测；
• 当某个 Skill 失败率上升时，触发修订或回滚。

产物与门禁：

Skill / Workflow 的产物包括 SOP、工具调用模板、状态机、脚本、检查清单、任务模板。进入生产前应通过单元测试、端到端测试、权限审查和灰度。风险是从单次偶然成功中抽取出错误 Skill，或者 Skill 库膨胀后检索错误、版本漂移、互相冲突。

7、Memory：从“记得更多”转向“记得更准”#

Memory 负责保存跨会话、跨任务仍然有价值的信息，包括长期事实、用户偏好、项目状态、历史决策和可复用经验。Memory 自进化的关键不是“记得更多”，而是“知道什么值得记、什么时候该忘、在什么场景下该用”。

自进化对象：

• 哪些信息可以写入长期记忆；
• 哪些信息只属于当前 session；
• 记忆的来源、时间、可信度和生命周期；
• 新旧记忆冲突时如何处理；
• 用户是否可以查看、编辑、删除记忆；
• 记忆是否会污染上下文或泄露隐私。

自进化动作：

• 从重复询问和人工纠正中识别稳定偏好；
• 为记忆增加 source、timestamp、confidence、scope、ttl；
• 对相似记忆做合并、降权、过期和冲突标注；
• 根据任务类型选择 project memory、user memory 或 session memory；
• 构造带记忆 / 不带记忆的对照评测，判断记忆是否真的提升任务。

产物与门禁：

Memory 自进化的产物是 memory policy、write policy、retrieval policy、forgetting policy 和 audit log。风险是错误记忆长期放大、过期事实误用、私人信息泄露、相似任务被旧经验误导。成熟系统应避免“所有对话自动写入向量库”这种粗暴做法。

8、Reflection / Retry：失败后的归因、修复与重试控制#

Reflection 和 Retry 负责失败后的修复。它们让 Agent 在遇到测试失败、工具错误、环境反馈或人工评价后，不是盲目重试，而是理解失败类型、选择修复动作、控制重试预算。

自进化对象：

• 失败类型如何分类；
• 哪些失败适合重试，哪些必须转人工；
• 反思是否有外部证据支撑；
• 重试预算如何限制；
• 修复动作是否需要进入 Skill、Prompt 或 Dataset。

自进化动作：

• 从失败 Trace 中抽取错误类型，例如参数错误、权限错误、上下文缺失、工具返回误读、计划错误；
• 为不同错误类型绑定修复策略；
• 将反思模板结构化为“失败步骤、证据、原因、修复动作、验证结果”；
• 根据历史重试效果调整 retry policy；
• 把高价值修复 Trace 送入第六章的 Trace-to-Dataset 管线。

产物与门禁：

Reflection 的产物不应该只是自然语言自我解释，而应该是结构化 failure analysis。门禁重点是修复后是否通过外部验证。风险是模型在没有证据时生成看似合理但实际错误的归因，并在多轮反思中强化错误方向。

9、Evaluation / Regression：用评测判断进化还是退化#

Evaluation 是 Harness 自进化的闸门。没有评测，系统无法知道修改是进化还是退化。Evaluation 自进化的目标，是让评测集持续覆盖真实任务、历史失败、安全边界、成本约束和模型升级风险。

自进化对象：

• 核心任务集是否覆盖真实业务；
• 失败样本是否及时进入回归集；
• 评测指标是否只看文本，还是看最终状态；
• LLM-as-judge 是否需要校准；
• 是否覆盖成本、延迟、安全、权限和多轮稳定性。

自进化动作：

• 将线上失败 Trace 自动候选为回归样本；
• 将人工修复样本转成 gold case 或 preference case；
• 引入状态型评测，例如数据库状态、测试结果、文件变更、业务流程状态；
• 对 judge 结果做人工抽检和一致性校准；
• 为每次 Harness 变更生成回归报告。

产物与门禁：

Evaluation 的产物包括 eval set、regression set、safety set、cost set、judge rubric 和 report。风险是评测指标与真实业务目标不一致，导致系统优化错误目标；或者评测集长期不更新，无法覆盖新问题。

10、Guardrail / Permission：安全边界与权限策略的动态治理#

Guardrail 和 Permission 负责控制高风险行为。它们不是简单拒绝一切危险操作，而是根据风险等级、权限范围、工具副作用和业务场景，决定允许、拒绝、降级、转人工还是要求确认。

自进化对象：

• 哪些输入、工具、参数和操作属于高风险；
• 哪些行为需要人工审批；
• 哪些工具只能 dry-run，不能直接执行；
• 哪些数据需要脱敏；
• 哪些失败或异常需要升级处理。

自进化动作：

• 从高风险 Trace 中提取安全规则；
• 为工具增加 risk level、permission scope、side effect label；
• 根据误拒绝和漏拦截样本调整 guardrail；
• 把安全事件转成 safety regression；
• 对高风险操作引入 confirmation、preview、rollback plan。

产物与门禁：

Guardrail 的产物包括拒绝策略、权限矩阵、风险分级、安全回归集、人工审批策略。风险是过度拦截导致可用性下降，或拦截不足导致越权、泄露、错误写入和不可逆操作。

11、Deployment Policy：候选优化如何灰度、监控与回滚#

Deployment Policy 决定 Harness 变更如何进入生产。自进化系统可以自动生成候选，但不能自动无门禁上线。发布策略本身也需要根据历史事故、评测结果和线上指标持续优化。

自进化对象：

• 哪些变更可以自动灰度；
• 哪些变更必须人工审核；
• 灰度比例如何设定；
• 监控哪些成功率、成本、延迟、安全指标；
• 什么时候触发回滚。

自进化动作：

• 根据变更类型设置风险等级；
• Prompt、Tool Schema、Memory、Skill、模型版本分开管理；
• 使用离线评测 + 小流量灰度 + 异常回滚；
• 线上指标异常时自动冻结候选版本；
• 将回滚原因写回 Trace-to-Dataset。

产物与门禁：

Deployment 的产物包括版本库、发布策略、灰度规则、监控面板、回滚点和变更审计。风险是流程过重拖慢低风险优化，或流程过轻让自动优化放大错误。

12、Harness 内部协同：不是各模块各改各的#

Harness 子模块不能孤立优化。Prompt 改动可能影响工具调用，Memory 策略可能影响 Context，Tool Schema 变化可能要求更新 Skill，Guardrail 加严可能改变评测结果。因此 Harness 自进化需要统一的版本体系和回归体系。

更合理的协同方式是：

• Prompt 保留任务目标、边界和输出契约；
• Context 提供当前任务需要的事实和证据；
• Tool Schema 定义可操作接口和权限；
• Skill / Workflow 承接稳定流程；
• Memory 保存长期事实和偏好；
• Reflection / Retry 处理失败恢复；
• Evaluation / Guardrail / Deployment 负责判断、保护和发布。

这样一来，Harness 就像一个可治理的软件系统：Prompt 不再是唯一杠杆，Memory 不再是无限写入的向量库，Workflow 不再是僵硬脚本，Reflection 也不再是没有依据的自我解释。它们共同构成一个可以版本化、可观测、可评测、可回滚的自进化外壳。

13、Harness 与训练的关系：先验证，再固化#

强调 Harness 并不意味着否定训练。相反，Harness 是训练前最重要的筛选器。

在工程上，可以把 Harness 层的进入条件和退出条件说得更明确：

换句话说，Harness 是第一修复面；Trace-to-Dataset 是经验沉淀面。一个问题如果还没有被 Harness 证明“确实能稳定修复”，就不应该急着进入训练样本池。

一个行为模式是否值得训练进模型，至少要经过四个问题：

1. 它是否在真实任务中反复出现；
2. 它是否已经被 Harness 修复或增强过；
3. 它是否通过了稳定评测和回归测试；
4. 它是否足够通用，值得从外部规则固化到模型或 Adapter。

如果答案是否定的，就不应该急着训练。很多问题停留在 Harness 层反而更好：业务规则变化快，放在 Workflow 或 Tool Schema 里更容易改；用户偏好差异大，放在 Memory policy 里更可控；安全策略需要审计，放在 Guardrail 和 Permission 中比写进模型更透明。

训练更适合作为终点：当某些工具调用模式、领域表达、流程策略和失败修复方法已经被 Harness 反复证明稳定有效，再把它们转成高质量 Dataset，通过 SFT、DPO、RLAIF 或 Agentic RL 固化进模型。即便训练完成，新模型仍然要回到 Harness 中接受评测、灰度、监控和回滚。

14、Harness 自进化的效果预估#

Harness 的收益通常不是让模型“突然变聪明”，而是让系统更稳定、更便宜、更可控。它主要体现在六类指标上：

这里的收益判断只能作为方向性参考，不能当成通用 benchmark 结论。Harness 自进化的真实收益取决于任务重复度、基础模型能力、工具稳定性、Trace 完整度、评测可靠性和发布治理。越是工具密集、流程稳定、成功标准明确的场景，Harness 的性价比越高；越是一次性、强主观、难评测、高风险不可回滚的场景，Harness 自进化越需要谨慎。

一句话总结：Harness 自进化是 Agent 自进化最现实的第一主线：它先把 Prompt、Context、Tool、Skill、Memory、Reflection、Eval、Guardrail 和 Deployment 变成可治理资产，再通过 Trace-to-Dataset 把稳定有效的经验转成模型升级燃料。

1、为什么这一层不能简单叫“数据层”#

数据本身不会自动变好。真正发生变化的是：系统从行为轨迹中识别问题、筛选经验、构造评测、生成样本、隔离风险，并把这些资产送回 Harness 或模型层。因此，Trace-to-Dataset 更像一个“经验转化工厂”，而不是一个静态数据仓库。

这一层处在三层架构的中间位置。向前看，它回答 Harness 是否真的变好了：哪个 Prompt patch 有效，哪个 Tool Schema 降低了参数错误，哪个 Memory 策略引入污染，哪个 Workflow 降低了人工接管。向后看，它回答哪些经验值得训练：哪些成功路径可以变成 SFT 样本，哪些人工修复可以变成偏好对，哪些高风险案例应该进入安全样本，哪些失败案例应该进入回归集。

2、Trace-to-Dataset 模块总览#

Trace-to-Dataset 不是“把日志扔进数据湖”。它至少包含六个子模块：Trace 采集、评测解释、样本构造、质量门禁、数据治理、回流决策。

这个表的关键含义是：Trace-to-Dataset 不等于训练数据准备。它同时服务 Harness 优化、评测体系、模型训练和治理审计。很多 Trace 最终不应该进入训练，而应该回到 Prompt、Tool Schema、Memory、Workflow 或 Guardrail。

3、Trace Capture：先把行为过程记录完整#

Trace 是自进化闭环的事实来源。没有结构化 Trace，团队只能靠主观复盘判断 Agent 为什么失败；有了结构化 Trace，失败可以被定位、聚类、重放和转化。

转化对象：

• 用户输入、系统指令、开发者指令和任务模板；
• 检索 query、上下文片段、证据来源和上下文顺序；
• 工具选择、工具参数、工具返回、错误码和副作用；
• 计划步骤、中间状态、反思内容、重试路径；
• 人工接管、人工修复、最终输出和最终状态；
• 成本、延迟、token、模型版本、Harness 版本、安全事件。

转化动作：

• 使用统一 trace id 串联用户请求、模型调用、工具调用和最终状态；
• 将自然语言过程拆成 event / span / state transition；
• 为每次 Prompt、Memory、Tool、Skill、模型版本记录版本号；
• 对高风险工具记录 dry-run、confirmation、rollback plan；
• 把人工接管前后的差异保存为修复轨迹。

产物与门禁：

Trace Capture 的产物是结构化行为轨迹。它的门禁重点是完整性、可重放性、可追责性和隐私边界。风险是只记录最终回答，缺少中间步骤；或者记录过多敏感信息，导致数据集治理成本和合规风险上升。

一个简化后的高价值 Trace 可以长这样：

1
{
2
  "trace_id": "trace_2026_0615_00042",
3
  "task_type": "code_fix",
4
  "user_input": "修复订单接口在空 discountCode 下的测试失败",
5
  "harness_version": {
6
    "prompt": "code-agent-prompt@1.8.2",
7
    "tool_schema": "repo-tools@0.6.4",
8
    "workflow": "fix-test-runner@0.3.1",
9
    "model": "model-x@2026-06"
10
  },
11
  "context_refs": [
12
    {"file": "src/order/service.ts", "reason": "包含失败接口逻辑"},
13
    {"file": "tests/order/service.test.ts", "reason": "失败测试来源"}
14
  ],
15
  "tool_calls": [
16
    {
17
      "name": "run_tests",
18
      "arguments": {"pattern": "tests/order/service.test.ts"},
19
      "result": "failed: discountCode null should not throw",
20
      "error_type": "test_failure"
21
    },
22
    {
23
      "name": "apply_patch",
24
      "arguments": {"files": ["src/order/service.ts"]},
25
      "result": "patch_applied"
26
    }
27
  ],
28
  "final_state": {
29
    "tests_passed": true,
30
    "changed_files": ["src/order/service.ts"],
31
    "manual_review_required": false
32
  },
33
  "eval": {
34
    "outcome": "success",
35
    "confidence": 0.92,
36
    "cost_level": "low",
37
    "risk_label": "low"
38
  },
39
  "dataset_route": ["regression_positive", "sft_candidate", "workflow_candidate"]
40
}

这个样例的重点不是字段越多越好，而是它能回答四个问题：失败发生在哪里，修复为什么有效，是否真的通过外部验证，以及这条经验应该回到 Harness、评测集还是训练候选池。

4、Evaluation Labeling：先判断结果，再谈样本#

Trace 只有被评测解释后才有价值。一个看起来流畅的回答可能没有完成任务，一个失败回答也可能包含有价值的中间修复动作。Evaluation Labeling 的目标，是给 Trace 加上可信的成功标准和失败类型。

转化对象：

• 最终状态是否正确；
• 工具调用是否符合参数约束和权限边界；
• 输出格式是否满足契约；
• 成本和延迟是否在预算内；
• 是否触发安全、隐私或合规问题；
• 失败是由模型推理、上下文缺失、工具错误、权限限制还是评测器误判导致。

转化动作：

• 用代码测试、数据库状态、文件变更、浏览器状态等外部信号校验结果；
• 对无法自动判断的任务引入人工抽检或 LLM-as-judge；
• 将失败类型结构化，例如 context missing、wrong tool、bad argument、stale memory、unsafe action；
• 为同一 Trace 记录 outcome label、failure taxonomy、confidence score；
• 把高价值失败自动候选为回归样本。

产物与门禁：

这一模块的产物是带标签 Trace 和评测结果。门禁重点是评测是否贴近真实业务目标。风险是 judge 偏差、成功标准过窄、只看文本质量不看最终状态，导致后续数据样本优化了错误目标。

5、Sample Construction：不同轨迹进入不同样本池#

不是所有 Trace 都应该训练模型。Sample Construction 要做的是“分流”：把不同类型的轨迹转成不同资产。

转化对象：

• 成功路径中的稳定步骤；
• 失败路径中的关键错误点；
• 人工修复前后的行为差异；
• 高风险任务中的拒绝、确认、转人工和回滚动作；
• 可被回放的业务状态和外部环境。

转化动作：

• 将成功 Trace 压缩成 instruction / input / reasoning hint / action / output / final state；
• 将人工修复转成 chosen / rejected 偏好对；
• 将失败 Trace 转成 regression case 和 failure analysis；
• 将安全事件转成 refusal、escalation、permission check 样本；
• 为样本打上 domain、task type、risk level、model version、source trace id。

产物与门禁：

Sample Construction 的产物不是一个总数据集，而是多个用途明确的样本池。门禁重点是样本用途不能混淆：SFT 正样本、偏好样本、回归样本、安全样本、评测样本应该分库治理，否则很容易把错误目标写进训练。

6、Quality Gate：原始 Trace 不能直接训练#

Trace-to-Dataset 最怕“日志很多，样本很脏”。埋点不完整、字段不结构化、成功标准不明确、人工标注不一致，都会让 Trace 变成昂贵噪声。更严重的是，如果错误 Trace 被误标为成功样本，后续 Skill 沉淀和模型训练会把错误放大。

转化对象：

• 样本是否真实来自可复盘 Trace；
• 最终状态是否经过外部校验；
• 标签是否一致；
• 是否包含隐私、密钥、客户数据或内部敏感信息；
• 是否重复、过期、低质量或只适用于单个用户；
• 是否和当前工具、业务规则、模型版本仍然匹配。

转化动作：

• 对样本做脱敏、去重、格式校验、状态校验和一致性检查；
• 对高价值样本做人工抽检；
• 对高风险样本进入隔离池，不进入普通训练集；
• 用质量分控制样本进入 eval、SFT、DPO 或 safety 数据集；
• 对过期业务规则和旧工具版本样本设置 ttl 或弃用标签。

产物与门禁：

Quality Gate 的产物是可用样本、待审样本、隔离样本和废弃样本。门禁重点是宁可少一点，也不要把脏样本送进模型训练。风险是过度自动化筛选导致重要长尾样本被丢掉，或人工审核标准不一致造成数据偏差。

7、Dataset Governance：样本也要版本化、可追溯、可回滚#

当样本进入训练、评测或回归体系后，它就不再是一次性日志，而是影响系统长期行为的工程资产。Dataset Governance 负责让这些资产可审计、可维护、可迁移。

转化对象：

• 数据集版本与变更记录；
• 样本来源、适用范围和质量分；
• 关联的 Prompt、Tool Schema、Memory、Skill 和模型版本；
• 数据过期、撤回、删除和合规要求；
• 训练集、验证集、测试集和安全集之间的隔离。

转化动作：

• 为每个样本保存 source trace id、created_at、owner、license、risk label；
• 为每个数据集生成数据卡，说明来源、覆盖范围、已知偏差和禁用场景；
• 建立 train / eval / safety / regression 的隔离规则；
• 在模型升级或工具变更后重新校验老样本；
• 当线上事故来自某批数据时，可以定位、移除、重训或回滚。

产物与门禁：

Dataset Governance 的产物是数据集版本、样本血缘、数据卡和审计记录。风险是数据集长期堆积后没人知道哪些样本还能用，最终让模型训练和评测都失去可信度。

8、Feedback Routing：决定经验回到 Harness 还是进入训练#

Trace-to-Dataset 的最后一步不是“默认训练”，而是判断经验应该回到哪里。很多问题在 Harness 层解决更便宜、更透明、更容易回滚；只有稳定、通用、经过验证的经验，才值得进入模型层。

转化对象：

• 失败类型和修复路径；
• 样本出现频率、业务价值和风险等级；
• Harness 修复成本与训练成本；
• 经验是否通用，是否跨用户、跨任务、跨模型稳定；
• 是否已经有可靠评测覆盖。

转化动作：

• 工具参数错误优先回到 Tool Schema；
• 上下文缺失优先回到 Context policy 或检索策略；
• 高频稳定流程优先沉淀为 Skill / Workflow；
• 记忆污染优先回到 Memory policy；
• 权限和安全问题优先回到 Guardrail；
• 只有跨场景稳定的格式、表达、策略偏好和工具模式，才进入模型训练候选。

产物与门禁：

Feedback Routing 的产物是优化任务队列：Prompt patch、Tool Schema patch、Skill 候选、Memory 修订、Eval case、Safety case、Training candidate。门禁重点是避免“所有问题都训练化”，也避免“所有经验都停留在工程补丁里”。

9、效果预估：收益来自确定性，而不是直接变聪明#

Trace-to-Dataset 本身不一定直接提升单次任务成功率，但它会显著提高所有后续优化的确定性。

这一层的进入条件和退出条件也要分清：

如果这些条件不满足，Trace 更适合先停留在复盘、评测和 Harness 修复阶段，而不是进入模型训练。

这些收益依赖两个前提：第一，Trace 必须真实反映任务过程；第二，Evaluation 必须贴近业务成功标准。否则 Trace-to-Dataset 只会把噪声组织得更整齐，并不会让系统更强。

一句话总结：Trace-to-Dataset 是自进化闭环的样本转化层：它不直接让模型变强，但决定了后续 Harness 优化和模型训练是否有证据、有燃料、有边界。

1、模型层应该固化什么，不应该固化什么#

模型层适合固化“稳定、通用、可评测、跨场景复用”的经验，而不适合承载所有业务变化。它的价值不是替代 Harness，而是把已经被 Harness 和 Trace-to-Dataset 反复验证的能力压缩进模型参数或轻量 Adapter，从而降低 Prompt 长度、减少多轮重试、提升基础行为稳定性。

这个边界很重要。训练一旦发生，能力就变得更难解释、更难局部回滚；Harness 虽然外部化，但更透明、更容易灰度、更容易随业务变化调整。

2、模型层路线总览#

模型层不是只有“训练模型”一个动作。不同技术路线解决的问题不同，风险和投入也不同。

更稳妥的工程顺序通常是：先用 SFT 固化格式和领域表达，再用 DPO / RLAIF 调整偏好与策略，最后在环境可靠、奖励可信的场景尝试 Agentic RL。Adapter、LoRA 和蒸馏可以作为成本优化手段，而不是天然更高级的路线。

几个典型训练决策可以帮助理解这张表：

这些案例说明：模型层路线不是按“技术先进程度”选择，而是按问题性质、样本质量、评测可靠性和回滚成本选择。

3、SFT：把稳定成功路径写成基础能力#

SFT 适合把“正确示范”写进模型，尤其适合格式、术语、领域表达、固定工具调用模板和标准操作范式。它解决的问题通常是：模型每次都需要被长 Prompt 反复提醒，或者在高频任务中总是漏掉某些稳定步骤。

固化对象：

• 稳定输出格式，例如 JSON、报告模板、表格结构；
• 领域术语、行业表达、组织内部规范；
• 高频工具调用链路和参数构造习惯；
• 标准作业流程中的固定步骤；
• 经 Trace-to-Dataset 验证过的成功 Trace。

训练动作：

• 从成功 Trace 中抽取 instruction / input / action / output / final state；
• 过滤掉只对单个用户、单个版本、单个工具有效的样本；
• 将长 Prompt 中反复出现的稳定规则转成训练样本；
• 保留足够通用任务样本，避免领域微调损伤基础能力；
• 用回归集比较训练前后的格式稳定性、工具调用准确率和成本。

产物与门禁：

SFT 的产物是微调模型、领域模型或工具使用模型。门禁重点是训练样本必须真实成功、最终状态可验证、覆盖足够多任务形态。风险是过拟合、灾难性遗忘、把错误流程固化进模型，或者让模型在新基础模型升级后变成维护负担。

4、DPO / Preference Optimization：把“更好的选择”写进策略偏好#

很多 Agent 问题不是“不会做”，而是“多个做法里选了不够好的那个”。DPO 和偏好优化更适合处理这类问题：选择更安全的回答、更低成本的工具路径、更少副作用的操作、更符合业务目标的修复方案。

固化对象：

• 人工修复前后的优劣差异；
• 两条工具路径之间的成本、风险和成功率差异；
• 不同回答风格、拒绝方式、澄清方式的偏好；
• 多轮修复中更可靠的策略选择；
• 安全、合规、品牌语气等相对稳定的偏好。

训练动作：

• 从人工修复 Trace 中构造 chosen / rejected；
• 将失败输出与修复后输出配对；
• 为偏好对补充任务背景、工具结果和最终状态；
• 对偏好数据做一致性检查，避免不同标注者标准冲突；
• 用业务指标校准偏好，不只看回答是否“好看”。

产物与门禁：

DPO / Preference Optimization 的产物是偏好对齐后的模型。门禁重点是偏好是否稳定、是否跨场景成立、是否和真实业务指标一致。风险是偏好漂移、标注标准不一致、模型学会迎合 judge，而不是完成真实任务。

5、RLAIF / RFT：在可验证任务上优化结果#

RLAIF、RFT 或类似强化优化路线适合有自动评测器的任务，例如代码测试、数学验证、结构化信息抽取、规则明确的业务流程。它们的优势在于可以用结果反馈推动模型改进，而不完全依赖人工示范。

固化对象：

• 可被程序验证的最终答案；
• 可由规则或 judge 判断的过程质量；
• 多方案生成后的选择策略；
• 失败修复后的验证习惯；
• 低成本、高成功率的行动路径。

训练动作：

• 构造可重复运行的任务环境和验证器；
• 用测试、规则、业务状态或 judge 给轨迹打分；
• 将高分轨迹和低分轨迹转成优化信号；
• 防止模型利用评测器漏洞获得高分；
• 对 reward model 或 judge 做人工抽检和对抗样本校验。

产物与门禁：

这一路线的产物是结果导向更强的模型。门禁重点是奖励函数必须贴近真实目标。风险是 reward hacking、评测器被钻空子、模型为了得分牺牲安全性或可解释性。

6、Agentic RL：长程工具任务的高上限路线#

Agentic RL 的理论上限更高，因为它优化的是多轮计划、工具调用、环境交互和长期收益，而不是单轮回答。代码、自动化运维、浏览器任务、可模拟业务流程、游戏环境和机器人控制等场景，都可能从中受益。

固化对象：

• 多步任务规划；
• 工具调用顺序和参数策略；
• 失败后的重新规划；
• 在环境反馈下调整行动；
• 长轨迹中的成本、风险和成功率权衡。

训练动作：

• 构建可交互、可重置、可评价的环境；
• 定义任务成功、部分成功、失败、安全违规和成本的奖励；
• 采集长轨迹并处理 credit assignment；
• 对工具调用、状态变化和安全事件做细粒度奖励；
• 在沙箱中训练和评估，再进入小流量灰度。

产物与门禁：

Agentic RL 的产物是更强的长程行动策略。门禁重点是环境可靠、奖励可信、安全边界清楚。风险是训练成本高、环境构造难、reward hacking 严重、线上不可控。因此它更适合作为中长期路线，而不是多数企业第一阶段的默认选择。

7、Adapter / LoRA：把领域适配做轻、做薄、做可回滚#

当企业希望降低成本、保留可回滚能力，或者不想改动基础模型主体时，Adapter / LoRA 是更轻量的选择。它适合领域术语、固定格式、局部任务风格和专门工具模式，不适合承载复杂全局策略。

固化对象：

• 某个行业或部门的表达习惯；
• 某类固定任务的格式和流程；
• 专门工具的调用模式；
• 不希望污染主模型的局部能力；
• 需要按租户、按业务线隔离的能力。

训练动作：

• 按领域或任务拆分 Adapter；
• 控制样本边界，避免把通用能力训练进局部权重；
• 保留主模型与 Adapter 的组合评测；
• 为 Adapter 建立启用、禁用、灰度和回滚策略；
• 监控 Adapter 与 Harness 规则的冲突。

产物与门禁：

Adapter / LoRA 的产物是可插拔权重。门禁重点是隔离清楚、版本清楚、适用范围清楚。风险是 Adapter 数量膨胀后难以管理，或者多个 Adapter 与 Tool Schema、Prompt、Memory 策略互相冲突。

8、Distillation：把大模型经验迁移给小模型#

小模型后训练容易被下一代大模型超越，但小模型仍有现实价值：成本低、延迟低、可私有化、可部署在边缘或内网。Distillation 的目标不是盲目追平大模型，而是把经过验证的特定任务经验迁移到小模型中。

固化对象：

• 大模型在特定任务上的稳定输出；
• 高质量工具调用轨迹；
• 领域问答、分类、抽取、路由等窄任务；
• 低风险、强重复、评测清楚的业务流程；
• 大模型生成、人工审核后的合成样本。

训练动作：

• 用大模型生成候选轨迹，再通过评测和人工抽检筛选；
• 将复杂任务拆成小模型可承担的子任务；
• 保留大模型作为教师、裁判或升级路径；
• 在成本、延迟、成功率之间做对照评测；
• 将小模型放在 Harness 中承担路由、分类、草稿、抽取等低风险环节。

产物与门禁：

Distillation 的产物是专用小模型或任务模型。门禁重点是不要把小模型部署到超出能力边界的场景。风险是为了省成本牺牲可靠性，或在基础大模型升级后继续维护已经不划算的小模型。

9、小模型后训练的现实边界#

围绕小模型做高成本后训练，收益可能在下一代大模型发布后被迅速抹平。相比之下，评测集、Tool Schema、Workflow、Memory 治理、安全样本和 Trace 数据通常更容易迁移到新模型上。

更合理的判断方式是看三件事：

1. 任务是否稳定：如果业务规则频繁变化，Harness 更合适；
2. 成本是否敏感：如果调用量巨大，小模型或 Adapter 可能值得投入；
3. 评测是否可靠：如果无法判断训练后是否真的更好，就不应训练。

因此，后训练不应从原始 Trace 直接开始，也不应作为问题初次修复手段。它应该接在 Harness 修复和 Trace-to-Dataset 清洗之后，只固化那些反复出现、价值稳定、评测可靠的经验。

10、模型升级后的闭环治理#

训练完成后，也不能绕过 Harness。新模型仍然需要工具约束、记忆治理、评测门禁、灰度发布和回滚机制。模型升级不是终点，而是进入下一轮 Harness 评测和线上观测的开始。

治理对象：

• 新旧模型在核心任务、历史失败、安全样本上的差异；
• 模型与 Prompt、Tool Schema、Memory、Skill 的兼容性；
• 成本、延迟、成功率、人工接管率和安全事件；
• 新模型是否改变了工具选择、拒绝风格和长程规划习惯；
• 模型退化是否来自训练数据、基础模型或 Harness 版本变化。

治理动作：

• 使用离线评测比较 base model、旧模型、新模型；
• 对高风险任务进行人工审核和灰度；
• 将模型版本纳入 Trace，便于事故回溯；
• 对失败样本重新进入 Trace-to-Dataset；
• 保留回滚到旧模型、旧 Prompt、旧 Tool Schema 的能力。

产物与门禁：

模型治理的产物是模型版本、评测报告、灰度策略、回滚方案和事故复盘。门禁重点是模型升级必须和 Harness 版本一起评估。风险是只看模型 benchmark，不看真实工具任务和业务流程。

11、效果预估：模型层收益更高，但不确定性也更高#

模型层一旦成功，收益可能比单个 Prompt patch 更大，因为它会改变模型的基础行为分布。但它的成本、周期和风险也更高。

这些收益判断只能作为方向性参考。模型层收益不是训练动作本身带来的，而是由前两层决定的：Harness 是否已经找到了稳定修复，Trace-to-Dataset 是否提供了干净样本，Evaluation 是否能发现退化。

12、模型层与前两层的关系：训练是固化出口，不是万能入口#

模型层应该被理解为“固化出口”。当某些能力已经在 Harness 层反复出现，在 Trace-to-Dataset 层被结构化、评测化、质量门禁化，再进入模型层才有意义。

模型层同样需要进入条件和退出条件：

这张表的重点是：模型升级不是闭环终点，而是一个高风险候选变更。训练完成只说明“得到一个候选模型”，不说明它已经适合生产。

一个经验进入训练前，至少要回答五个问题：

1. 它是否反复出现在真实任务中；
2. 它是否已经通过 Harness 修复验证；
3. 它是否可以被评测或外部状态验证；
4. 它是否足够通用，不只是某个用户或某个版本的临时规则；
5. 它被写进模型后，是否比留在 Harness 中更便宜、更稳定或更易迁移。

如果这些问题回答不清楚，训练很可能只是把不确定性变得更贵。更稳的路线是：Harness 先低成本试错，Trace-to-Dataset 再把经验变成样本，模型层最后负责固化稳定能力。

一句话总结：模型层自进化是稳定经验的固化出口，不是所有问题的第一解法；越靠近训练，越需要前两层提供高质量证据和样本。

1、端到端闭环：从线上行为到受控发布#

一个较完整的 Agent 自进化系统，不应该被理解为“模型自己训练自己”，而应该被理解为一个分层工程闭环：线上运行产生行为，观测层保留证据，评测层判断好坏，Trace-to-Dataset 层沉淀样本，优化层产生候选变更，发布层控制风险。

这张图可以拆成六层：

这个架构说明四点：

1. 自进化可以发生在多个位置：Prompt、Skill、Memory、Workflow、工具策略、评测集、模型参数和部署策略都可以优化；
2. Harness 层优化通常应先于后训练，因为它见效快、成本低、可回滚，并且更容易跨模型迁移；
3. 后训练只是优化层的一种选择，不应把整个自进化等同于训练；
4. 没有发布层治理，自动优化越强，自动放大错误的风险也越高。

更重要的是，这个闭环不是单向流水线。每一层都可能把问题打回上一层：

因此，成熟闭环的标志不是“每个样本最终都进入训练”，而是系统知道什么时候前进、什么时候停留、什么时候回滚。

2、实施优先级：先修 Harness，再做样本化，最后训练固化#

闭环上线后，最重要的不是“能不能自动提出优化建议”，而是“系统知道该改哪里”。同样是一次失败，不同原因对应完全不同的修复路径。

这个优先级背后的原则是：能在 Harness 层解决的问题，先不要训练；能通过样本和评测确认的问题，再考虑固化；能灰度和回滚的问题，才适合自动化发布。

3、变更类型：不同优化不能走同一个发布流程#

自进化系统会产生多类候选变更：Prompt patch、Tool Schema patch、Skill 候选、Memory policy 调整、Eval case、Safety case、Dataset 版本、Adapter 或模型版本。它们风险不同，不能用同一个门禁。

这里的关键是把“自动候选生成”和“自动上线”分开。系统可以自动发现问题、自动生成候选、自动跑评测，但高风险变更进入生产必须有门禁和责任边界。

4、评测矩阵：不要只用一个总分判断进化#

Agent 的改动很容易出现“局部变好、整体变坏”。例如 Prompt 更严格后格式稳定了，但拒答率升高；Tool Schema 更细后参数错误下降，但延迟上升；模型微调后领域任务变好，但安全拒绝变差。因此，每次变更都应该进入评测矩阵，而不是只看一个总分。

评测矩阵的目标不是追求所有指标同时最大化，而是让团队知道每次优化的收益和代价分别在哪里。

5、上线前检查清单#

任何自进化候选进入生产前，都至少应该回答这些问题：

• 变更来源：这次变更来自哪个 Trace、失败样本、人工修复或业务需求？
• 变更范围：影响哪个 Prompt、工具、Skill、Memory、Dataset 或模型版本？
• 评测结果：核心任务集、历史失败集、安全集、成本集是否通过？
• 风险等级：是否涉及写操作、权限、隐私、资金、合规或不可逆动作？
• 灰度策略：先放多少流量，面向哪些用户、任务或工具？
• 监控指标：上线后看哪些成功率、错误率、成本、延迟和安全事件？
• 回滚方案：出现异常时回滚到哪个版本，是否会影响已执行动作？
• 责任边界：自动系统、工程团队、业务团队和审核人员分别负责什么？

这个检查清单能把“自进化”从概念拉回工程现实：候选可以自动产生，但上线必须可解释、可追责、可回滚。

6、最小指标面板#

生产系统不需要一开始就建很复杂的仪表盘，但至少要有一组能判断进化是否有效的指标。

这些指标不只是运营看板，也应该反过来决定下一轮优化优先级。比如参数错误率高，就先改 Tool Schema；人工接管率高，就看 Workflow 和 Context；安全事件上升，就冻结自动候选版本。

7、30 / 60 / 90 天落地路线#

企业第一版 Agent 自进化系统不需要一开始就做完整后训练。更现实的路线可以按 30 / 60 / 90 天拆开。

这个路线的价值在于：它先让系统具备“知道自己有没有变好”的能力。只要这一步没有完成，后续无论是 Prompt 自动优化、Memory 自适应，还是 SFT / DPO / Agentic RL，都缺乏可靠依据。

以企业知识问答 Agent 为例，90 天内可以这样落地：

前 30 天，团队先不追求自动优化，而是补齐可观测性。每次问答都记录用户问题、检索 query、命中的文档、引用片段、模型回答、用户反馈、人工纠正、文档版本和成本延迟。同时从历史问题中挑出 100 条核心问题，人工确认标准答案和引用来源，形成第一版回归集。

31-60 天，团队优先修 Harness。发现错答主要来自过期文档和引用缺失，于是调整 Context policy：只允许引用最新版制度文档，为每段引用增加 source、updated_at 和 owner；Prompt 中要求回答必须带引用；Guardrail 增加“无可靠来源时不得编造”的规则。每次修改都跑 100 条核心回归集和 30 条历史失败样本。

61-90 天，团队开始做 Trace-to-Dataset。错引用样本进入 regression pool，人工纠正答案进入 preference pool，高风险合规问题进入 safety pool，稳定问答模板进入 SFT candidate pool。但此时仍不急着训练模型，而是先用这些样本扩大评测集和灰度门禁。

90 天后，如果发现某类固定文档摘要、固定格式回答、固定术语解释反复稳定出现，才考虑做 Adapter 或 SFT；如果业务制度仍频繁变化，则继续把规则留在 Context、Workflow 和 Guardrail 中。

一句话总结：

Agent 自进化的关键闭环，不是让模型直接改自己，而是让每一次真实行为都能被记录、评测、筛选、沉淀、验证和安全发布；短期让 Harness 变聪明，中期让 Trace-to-Dataset 形成数据资产，长期再把稳定经验固化进模型。

1、企业为什么会需要自进化闭环#

企业部署 Agent 后，最常见的问题不是“第一版能不能跑起来”，而是“上线后能不能持续适应变化”。真实环境会不断变化：

• 用户问题分布会变，早期样本无法覆盖后续长尾问题；
• 内部工具会变，API 参数、权限、返回结构和业务流程都会调整；
• 组织政策会变，安全、合规、审批和品牌表达会出现新要求；
• 底层模型会变，新模型可能更强，也可能改变原有工具调用习惯；
• 成本目标会变，企业会从“能用”转向“稳定、便宜、可治理”。

静态 Prompt 很难长期应对这些变化。Agent 自进化的价值在于，把线上真实行为转化为可诊断、可评测、可复用、可训练的资产，让系统不是靠人工反复救火，而是把每一次失败、修复和成功都沉淀进闭环。

2、适用性判断：先看五个条件#

一个场景是否适合引入自进化，可以先看五个条件。

如果五个条件里只有一两个成立，应该先做普通 Agent 工程，不急着搭完整自进化系统。如果三到五个条件成立，就值得至少建设 Harness 级自进化能力，例如评测集、Trace、Prompt 版本、Tool Schema 回归、Skill 库和安全门禁。

一个更直观的落地决策树可以这样看：

1
任务是否高频重复？
2
├─ 否：先做普通助手或人工增强，不急着做自进化
3
└─ 是
4
   ↓
5
成功标准是否可评测？
6
├─ 否：先建设评测标准和人工审核
7
└─ 是
8
   ↓
9
Trace 是否能记录过程、工具、状态和版本？
10
├─ 否：先做观测和日志结构化
11
└─ 是
12
   ↓
13
错误是否可灰度、可回滚、可人工接管？
14
├─ 否：先做权限、审批、dry-run 和回滚
15
└─ 是
16
   ↓
17
先做 Harness 自进化；当经验稳定后进入 Trace-to-Dataset；只有通用、高频、可验证模式才进入模型层固化

也可以用一个优先级矩阵来判断投入顺序：

这个矩阵说明：自进化的优先级不只取决于任务是否有价值，还取决于它是否重复、是否可评测、是否可回滚。高价值但不可评测、高风险且不可回滚的场景，反而应该更晚进入自进化。

3、不同手段分别解决什么#

企业常把 API、Prompt、Memory、Workflow、后训练混在一起讨论。更清晰的方式是按问题类型拆开。

这个表的核心结论是：多数企业不应该一开始就把问题推到后训练。先把 Harness 做稳，把 Trace 留完整，把评测和回滚建起来，再考虑模型层固化，风险会小得多。

4、优先落地场景：从可评测、高重复、可回滚开始#

更适合引入自进化思想的场景，通常具备“高重复、可评测、有工具、有反馈、可回滚”几个特征。

代码辅助与研发 Agent：

• 适合点：有测试、编译、lint、代码 diff、PR review 等外部校验信号；
• Harness 优化：Prompt、工具调用、代码搜索、补丁生成、测试重试、权限控制；
• Trace-to-Dataset：失败编译、测试修复、人工 review 修改都可以沉淀为样本；
• 模型层机会：稳定代码风格、常见框架用法、修复模式可以进入 SFT 或偏好优化。

数据分析与 BI Agent：

• 适合点：SQL、指标口径、图表结果和数据权限可以被校验；
• Harness 优化：Tool Schema、指标字典、查询模板、结果解释、权限门禁；
• Trace-to-Dataset：错误 SQL、人工修正、指标口径冲突可以进入回归样本；
• 模型层机会：高频查询模式、领域术语和报表格式可以固化。

客服辅助与运营 Agent：

• 适合点：问题分类、工单流转、标准话术和满意度有大量重复样本；
• Harness 优化：知识检索、回复模板、升级规则、敏感场景转人工；
• Trace-to-Dataset：人工改写、投诉样本、安全拒绝样本可进入偏好数据；
• 模型层机会：语气风格、业务术语、标准流程可以进入偏好优化。

企业知识问答与文档处理：

• 适合点：知识来源可追溯，文档结构稳定，引用和摘要可以审查；
• Harness 优化：Context policy、检索排序、引用格式、文档解析、记忆治理；
• Trace-to-Dataset：错引用、漏引用、过期知识可以转成评测样本；
• 模型层机会：稳定文档模板、信息抽取格式、领域表达可以训练。

内部流程自动化与运维 Agent：

• 适合点：流程状态、审批记录、工具返回和执行结果可以追踪；
• Harness 优化：Workflow、权限矩阵、dry-run、回滚策略、异常转人工；
• Trace-to-Dataset：失败流程、回滚案例、高风险操作可进入安全样本；
• 模型层机会：低风险重复流程可以做工具调用模式固化。

更细地看，不同行业场景的优先优化点不同：

这个表的作用是防止“所有场景都走同一套自进化路线”。同样是 Agent，自进化优先级会因工具风险、评测方式、样本形态和业务成本完全不同。

5、不适合一开始做自进化的场景#

有些场景并不是永远不能做，而是不适合一开始就引入自进化闭环。

• 低重复任务：如果每个任务都完全不同，样本复用价值低，先做通用助手更合适；
• 强主观任务：例如开放式创意、审美判断、战略判断，很难建立稳定评测；
• 高风险不可回滚任务：例如资金划拨、生产删除、法律承诺、医疗决策，必须先有强人工门禁；
• 数据治理不足：如果 Trace 中包含大量敏感信息，却没有脱敏、权限和保留期限，自进化会放大风险；
• 没有工程维护能力：自进化需要评测、版本、灰度、监控和回滚，不是一次性 Prompt 工程；
• 只是概念包装：如果没有指标、样本、评测和发布流程，“自进化”很容易变成营销词。

这些场景可以先做“可观测 + 人工审核 + 只读建议”，等评测和治理成熟后再逐步引入自动优化。

6、部署模式：SaaS、私有化与混合架构#

部署方式会直接影响 Trace、Memory、训练数据和权限治理。

多数组织更现实的路线是混合架构：高敏感数据和关键工具留在内网，通用推理和低风险任务使用外部模型；Trace 分级保存，训练样本经过脱敏和审批后再进入模型层。

7、成熟度路线：不要一步到位#

Agent 自进化更适合分阶段建设。

这一成熟度路线能避免常见误区：在评测还没有建好时急着训练，在 Trace 还不完整时急着做数据集，在权限还不清楚时急着让 Agent 执行高风险操作。

8、投入产出判断：看收益密度和资产迁移性#

判断一个自进化项目是否值得做，可以看两个问题。

第一，收益密度是否足够高。高频、高人工成本、高错误成本、可自动校验的任务，适合优先做。低频、低价值、强主观的任务，即使技术上能做，投入产出也可能不好。

第二，资产能否迁移。高质量工具 schema、核心回归集、失败样本库、可复用 Workflow、可治理 Memory、权限门禁和 Trace 数据，通常不会因为底层模型升级而失效。相反，它们会随着模型能力增强继续放大收益。相比之下，围绕某个小模型做昂贵后训练，可能在下一代模型发布后迅速失去优势。

一句话总结：业务落地要从可评测、高重复、可回滚的场景切入，先建设可迁移的 Harness 和 Trace 资产，再把稳定经验送入模型层固化。

1、风险总览：三层各有不同失败模式#

这意味着治理不能只放在模型训练阶段。Prompt patch、Memory 写入、Skill 新增、Tool Schema 修改、数据入库和模型升级，都应该有各自的门禁。

治理责任也应该和层级对应起来：

如果这些责任不清楚，自进化系统很容易出现“自动系统生成了变更，但没人真正负责结果”的问题。

2、错误经验被固化：从偶然成功到长期错误#

风险机制：

Agent 可能偶然完成任务，但路径是错的；也可能回答看起来正确，但最终状态没有验证。如果这类 Trace 被当成成功样本，错误会被写进 Skill、Workflow、Prompt 或模型权重。

典型表现：

• 成功样本没有最终状态校验；
• 人工修复只保存了最终答案，丢失了原始错误上下文；
• Skill 从单次成功中抽取，缺少多样化验证；
• 模型训练把带有错误工具参数的样本当成正例。

治理动作：

• 成功样本必须绑定 final state、test result、business status 或人工审核；
• 成功 Trace 和人工修复 Trace 分池保存；
• Skill 候选至少通过多个相似任务和历史失败集；
• 训练样本进入前必须经过质量评分、去重和抽检；
• 线上事故样本要反向进入回归集。

3、低质量数据导致能力退化：日志不等于样本#

风险机制：

线上日志通常噪声很大，包含不完整上下文、用户误操作、工具异常、过期知识、敏感信息和偶然结果。如果直接用这些日志做评测或训练，系统会学习噪声。

典型表现：

• 只有用户输入和最终回答，没有工具过程；
• 标签来自点赞、停留时间等弱信号；
• 数据没有区分训练、评测、回归和安全用途；
• 旧版本工具产生的样本继续影响新版本模型。

治理动作：

• 数据分层：raw trace、candidate sample、reviewed sample、training sample、eval sample、safety sample；
• 每条样本保留 source trace id、版本、来源、风险等级和质量分；
• 对高风险样本进入隔离池；
• 训练集和评测集严格隔离，避免数据泄漏；
• 对过期样本设置 ttl、deprecated 标签或迁移校验。

4、评测不可靠：系统可能优化错误目标#

风险机制：

如果评测指标不贴近真实任务，系统会朝错误方向优化。LLM-as-judge 可能偏好流畅表达，忽略事实、工具状态和业务结果；自动规则可能覆盖不到复杂边界。

典型表现：

• 输出看起来好，但数据库状态没有正确更新；
• judge 给高分，但引用来源错误；
• 成本和延迟没有进入评测；
• 安全拒绝被误判为任务失败；
• 评测集长期不更新，无法覆盖新业务问题。

治理动作：

• 优先使用状态评测：测试结果、文件 diff、数据库状态、工单状态、浏览器状态；
• LLM-as-judge 只作为辅助，并做人工抽检和一致性校准；
• 评测集分为核心任务集、历史失败集、安全集、成本集、长尾集；
• 每次 Harness 或模型变更都跑回归；
• 线上新失败必须有机制进入评测候选池。

5、自动闭环放大错误：优化和上线必须分离#

风险机制：

自进化系统可以自动生成 Prompt patch、Tool Schema patch、Skill 候选或训练样本，但如果自动生成后直接上线，错误会在生产环境放大。

典型表现：

• 自动反思生成错误归因，并被写入 Prompt；
• Memory 自动写入未经验证的事实；
• Skill 自动沉淀后影响大量任务；
• 模型训练完成后未灰度就替换线上模型。

治理动作：

• 自动生成候选可以快，自动上线必须慢；
• 低风险变更可自动灰度，高风险变更必须人工审批；
• 每类变更都需要版本号、评测报告和回滚点；
• 异常指标触发冻结候选版本；
• 高风险工具默认 dry-run、preview、confirmation。

6、Memory 与个性化风险：记住错误比忘记更危险#

风险机制：

Memory 的问题不是“记不住”，而是“记错、记旧、记多、记越界”。错误记忆一旦跨会话传播，会持续污染上下文。

典型表现：

• 把一次性偏好当成长期偏好；
• 旧项目状态覆盖新状态；
• 将敏感信息写入长期记忆；
• 用户无法查看、修改或删除记忆；
• 相似任务被错误历史经验误导。

治理动作：

• Memory 写入必须有 scope、source、timestamp、confidence、ttl；
• 区分 session memory、project memory、user memory；
• 建立记忆冲突处理和过期机制；
• 对敏感记忆默认不写入或加密隔离；
• 提供用户可见、可编辑、可删除的记忆治理能力。

7、安全、隐私与权限：Agent 的工具能力放大了风险#

风险机制：

Agent 一旦能调用数据库、文件系统、浏览器、企业 API 或代码执行器，就可能造成真实世界影响。自进化系统如果把高风险 Trace 当成普通经验，会把越权或不安全路径固化下来。

典型表现：

• Trace 中包含个人信息、商业机密、访问令牌；
• 工具参数缺少权限校验；
• 高风险操作没有人工确认；
• 数据跨租户、跨项目、跨权限域污染；
• 模型在训练中记住敏感内容。

治理动作：

• 最小化采集，敏感字段脱敏或不采集；
• 工具 schema 标注 risk level、permission scope、side effect；
• 高风险操作必须 preview、confirmation、approval、rollback plan；
• 对 Trace、样本、Memory 做权限隔离；
• 对训练数据执行隐私扫描、合规审批和删除机制。

8、模型层风险：后训练不是免费午餐#

风险机制：

后训练可能提升某类任务，却损害通用能力、安全能力或其他领域能力。Agentic RL 还可能出现 reward hacking，让模型学会钻评测器空子。

典型表现：

• 领域任务变好，通用问答和安全拒绝变差；
• 模型过度拟合固定工具路径，遇到新工具不会适配；
• 偏好优化让模型更会迎合 judge；
• RL 模型为了得分绕过业务约束；
• 小模型后训练收益被新大模型快速覆盖。

治理动作：

• 保留通用能力、领域能力、安全能力、工具能力四类回归集；
• 优先用 Adapter / LoRA 做可回滚适配；
• 模型升级必须和 Harness 版本一起评估；
• 对 reward model、judge 和环境做对抗测试；
• 训练收益必须和维护成本、模型迁移风险一起评估。

9、工程复杂度超过收益：闭环也可能过度设计#

风险机制：

完整自进化系统需要 Trace、Eval、Dataset、Training、Deployment、Monitoring、Security 多套能力。如果场景价值不足，工程复杂度会吞掉收益。

典型表现：

• 为低频任务建设完整训练管线；
• 评测集还没有，却先搭模型微调；
• 大量样本没人审核；
• 系统版本过多，团队无法维护；
• 指标很多，但没有一个能说明业务价值。

治理动作：

• 按成熟度分阶段引入；
• 优先建设可迁移资产：Trace、Eval、Tool Schema、Workflow、Guardrail；
• 每个阶段设置退出条件和收益指标；
• 对低频场景保留人工审核或简单 Harness 优化；
• 定期清理过期 Skill、Memory、Prompt 和数据集。

10、概念被过度营销：用指标约束叙事#

风险机制：

很多系统把普通日志、普通 Memory、普通 Prompt 调参包装成“自进化”。如果没有可验证指标，这个概念会变得空泛。

更严谨的判断标准：

• 是否有结构化 Trace；
• 是否有稳定评测集和回归集；
• 是否有自动候选生成机制；
• 是否有人工或自动质量门禁；
• 是否有版本、灰度、监控和回滚；
• 是否能证明任务成功率、错误率、成本、延迟、安全事件率或人工接管率改善。

如果这些条件都没有，就只能说是普通 Agent 工程优化，而不是自进化闭环。

11、治理框架：把自进化变成受控工程#

成熟治理不应该只靠“上线前人工看一眼”，而应该形成一套固定机制。

事故发生后，可以用一份固定模板复盘，避免只停留在“模型答错了”这种粗粒度结论：

这个模板的核心是把事故归因到可修复层级：如果是 Tool Schema 问题，就不要怪模型；如果是 Dataset 标签污染，就不要只改 Prompt；如果是发布门禁缺失，就不要把责任推给训练算法。

一句话总结：自进化系统最怕无门禁的自动闭环；真正可用的自进化，是把自动发现、自动候选和受控发布结合起来。

1、从 Model-centric 转向 Harness-centric#

过去很多 AI 系统以模型为中心：模型越强，系统越强。但 Agent 进入工具、记忆、流程和真实环境后，系统能力不再只由模型参数决定。未来 Agent 工程会更强调 Harness：如何给模型组织上下文，如何约束工具，如何沉淀 Skill，如何治理 Memory，如何评测和发布。

这不是说模型不重要，而是说模型会成为更大运行系统中的核心计算单元。底层模型越强，Harness 的价值反而越高：强模型可以完成更复杂动作，也更需要清晰权限、可靠证据、严格评测和可回滚流程。

2、Trace 会成为 Agent 时代最重要的数据资产之一#

普通对话日志只记录“用户问了什么、模型答了什么”。Agent Trace 记录的是“模型如何计划、如何检索、如何调用工具、如何失败、如何修复、最终状态是什么”。这类数据更接近行为数据，也更接近未来模型升级真正需要的燃料。

未来高质量 Agent 系统的壁垒，很可能不是某个单点 Prompt，而是长期积累的高质量 Trace、评测集、失败样本、安全样本和人工修复样本。它们既能优化 Harness，也能构造训练数据，还能形成组织自己的任务分布护城河。

3、Eval-first 会成为 Agent 开发的默认工程习惯#

没有评测，自进化无法区分进步和退化。未来 Agent 开发会越来越像软件工程：先定义成功标准，再改 Prompt、Tool、Skill 或模型。

Eval-first 不只是写几个问答样例，而是包含：

• 核心任务集，保证主要能力不退化；
• 历史失败集，防止老问题复发；
• 安全集，覆盖越权、隐私、合规和拒绝边界；
• 成本集，监控 token、工具调用和延迟；
• 状态评测，验证代码、数据库、文件、工单或浏览器任务是否真的完成。

当评测成为基础设施，Harness 自进化和模型训练才有稳定方向。

4、Skill 与模型权重会形成长期分工#

短期内，许多经验更适合沉淀在 Harness 层：Skill、Workflow、Memory、Tool Schema、Eval Set 和 Guardrail。它们透明、可编辑、可版本化、可回滚，而且能随着模型升级继续复用。

长期看，稳定、重复、高价值，并且已经被 Harness 反复验证的行为模式，才适合通过 SFT、DPO、RFT 或 Agentic RL 固化进模型或 Adapter。未来的成熟系统很可能形成这样的分工：

• Skill / Workflow 保存流程和组织知识；
• Tool Schema / Guardrail 保存操作边界和权限；
• Memory 保存个体、项目和组织状态；
• Dataset 保存可评测、可训练的经验；
• Model 固化通用、稳定、跨场景复用的能力。

这种分工能降低模型迭代的不确定性。小模型后训练可能被下一代大模型超越，但高质量 Harness 通常可以迁移到新模型上。

5、Agentic RL 会发展，但会被工程治理包围#

Agentic RL 的方向很重要，因为它试图优化长程任务、工具使用和环境交互策略，而不是只优化单轮回答。随着可验证环境、代码执行环境、浏览器任务环境和模拟业务流程发展，Agentic RL 会在高价值场景中变得更重要。

但它不会替代工程治理。原因很简单：长程策略越强，风险越大。Agentic RL 仍然需要：

• 可重置、可隔离、可观测的训练环境；
• 贴近真实目标的奖励函数；
• 防止 reward hacking 的对抗评测；
• 工具权限、沙箱、安全边界；
• 灰度发布、线上监控和回滚机制。

因此，Agentic RL 更可能成为三层架构里的模型层增强路线，而不是跳过 Harness 和 Trace-to-Dataset 的捷径。

6、AgentOps 会成为自进化的基础设施#

随着 Agent 被部署到更复杂场景，AgentOps 会从“可选工具”变成“基础设施”。它需要覆盖观测、评测、版本、成本、安全、发布和事故复盘。

未来成熟 AgentOps 可能包含：

• Trace 和 span 级观测；
• Prompt、Tool、Skill、Memory、Model 的版本管理；
• 离线评测、在线监控和异常告警；
• 数据集血缘、样本质量和隐私治理；
• 权限矩阵、审批流和高风险操作审计；
• 自动候选生成、人工审批、灰度和回滚。

换句话说，自进化不是一个单独按钮，而是一整套运行时基础设施。

7、小模型会更像“任务组件”，不是唯一主角#

小模型仍然重要，尤其在成本、延迟、私有化和边缘部署场景中。但它们更可能承担明确边界内的任务组件角色，例如分类、路由、抽取、格式化、简单工具调用、草稿生成和本地隐私处理。

未来更常见的模式可能是：大模型负责复杂推理和开放任务，小模型负责高频低风险子任务，Harness 负责调度、权限、评测和回滚。这样既能控制成本，也能避免把小模型训练成一个难以维护的全能系统。

8、组织知识会从文档资产变成行为资产#

过去企业知识主要沉淀在文档、流程图、制度和专家经验中。Agent 系统上线后，组织知识会逐渐以行为资产形式存在：成功 Trace、失败 Trace、人工修复、工具调用路径、评测样本、Skill、Workflow 和安全案例。

这种变化很关键。文档告诉系统“应该怎么做”，行为资产告诉系统“真实任务中实际怎么做、哪里会失败、怎样修复才有效”。未来企业 AI 能力的差异，很可能来自谁能把组织行为转成高质量 Harness 和 Dataset。

9、从自动化走向可治理自治#

未来 Agent 不会只是“自动执行任务”，而是逐步走向可治理自治。可治理自治的核心不是放任系统自己行动，而是明确哪些动作可以自动做、哪些需要确认、哪些必须转人工、哪些永远不能做。

这会带来新的工程标准：

• 低风险动作自动执行；
• 中风险动作 preview 后确认；
• 高风险动作审批后执行；
• 不可逆动作必须有回滚或人工责任人；
• 所有关键行为都可追踪、可解释、可审计。

这也是 Agent 自进化能否进入企业核心流程的前提。

10、最终趋势：系统智能会比单点模型能力更重要#

未来竞争不会只是谁的模型参数更强，而是谁能把模型、工具、数据、评测、流程和治理组织成稳定系统。模型能力仍然是底座，但真正拉开差距的会是系统智能：

• Harness 是否能快速适配新模型和新工具；
• Trace 是否能沉淀真实行为经验；
• Dataset 是否能支撑评测和训练；
• Eval 是否能发现退化；
• Guardrail 是否能控制风险；
• Deployment 是否能灰度和回滚；
• 组织是否能持续把失败变成资产。

一句话总结：Agent 自进化的未来不是单个模型自我变强，而是模型、Harness、Trace、Dataset、Eval 和治理体系共同形成持续改进的系统智能。

1、论文与研究工作#

1. Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, 2022.
   https://arxiv.org/abs/2210.03629

2. Noah Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, 2023.
   https://arxiv.org/abs/2303.11366

3. Aman Madaan et al., Self-Refine: Iterative Refinement with Self-Feedback, 2023.
   https://arxiv.org/abs/2303.17651

4. Timo Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools, 2023.
   https://arxiv.org/abs/2302.04761

5. Guanzhi Wang et al., Voyager: An Open-Ended Embodied Agent with Large Language Models, 2023.
   https://arxiv.org/abs/2305.16291

6. Charles Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023.
   https://arxiv.org/abs/2310.08560

7. Xiao Liu et al., AgentBench: Evaluating LLMs as Agents, 2023 / ICLR 2024.
   https://arxiv.org/abs/2308.03688

8. Grégoire Mialon et al., GAIA: a benchmark for General AI Assistants, 2023.
   https://arxiv.org/abs/2311.12983

9. Shunyu Yao et al., τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains, 2024.
   https://arxiv.org/abs/2406.12045

10. Liming Dong et al., AgentOps: Enabling Observability of LLM Agents, 2024.
    https://arxiv.org/abs/2411.05285

11. Zidi Xiong et al., How Memory Management Impacts LLM Agents: An Empirical Study of Experience-Following Behavior, 2025.
    https://arxiv.org/abs/2505.16067

12. Xufang Luo et al., Agent Lightning: Train ANY AI Agents with Reinforcement Learning, 2025.
    https://arxiv.org/abs/2508.03680

13. Guanting Dong et al., Agentic Reinforced Policy Optimization, 2025.
    https://arxiv.org/abs/2507.19849

14. Yusheng Zheng et al., AgentSight: System-Level Observability for AI Agents Using eBPF, 2025.
    https://arxiv.org/abs/2508.02736

15. Dany Moshkovich, Sergey Zeltyn, Taming Uncertainty via Automation: Observing, Analyzing, and Optimizing Agentic AI Systems, 2025.
    https://arxiv.org/abs/2507.11277

16. Sayash Kapoor et al., AI Agents That Matter, 2024 / TMLR 2025.
    https://arxiv.org/abs/2407.01502

17. Lei Wang et al., A Survey on Large Language Model based Autonomous Agents, 2023 / 2025 revision.
    https://arxiv.org/abs/2308.11432

18. Zhiheng Xi et al., The Rise and Potential of Large Language Model Based Agents: A Survey, 2023.
    https://arxiv.org/abs/2309.07864

19. Xu Huang et al., Understanding the planning of LLM agents: A survey, 2024.
    https://arxiv.org/abs/2402.02716

20. Huan-ang Gao et al., A Survey of Self-Evolving Agents: What, When, How, and Where to Evolve on the Path to Artificial Super Intelligence, 2025 / 2026 revision.
    https://arxiv.org/abs/2507.21046

21. Guibin Zhang et al., The Landscape of Agentic Reinforcement Learning for LLMs: A Survey, 2025 / 2026 revision.
    https://arxiv.org/abs/2509.02547

2、技术博客 / 技术报告#

1. Anthropic, Building Effective Agents, 2024.
   https://www.anthropic.com/research/building-effective-agents

2. OpenAI, New tools for building agents, 2025.
   https://openai.com/index/new-tools-for-building-agents/

3. Microsoft Azure Blog, Agent Factory: Top 5 agent observability best practices for reliable AI, 2025.
   https://azure.microsoft.com/en-us/blog/agent-factory-top-5-agent-observability-best-practices-for-reliable-ai/

4. OpenTelemetry Blog, AI Agent Observability - Evolving Standards and Best Practices, 2025.
   https://opentelemetry.io/blog/2025/ai-agent-observability/

5. Langfuse Blog, AI Agent Observability, Tracing & Evaluation with Langfuse, 2024.
   https://langfuse.com/blog/2024-07-ai-agent-observability-with-langfuse

6. Andrew Ng, How agents can improve LLM performance / Agentic workflow patterns, 2024.
   https://www.deeplearning.ai/the-batch/how-agents-can-improve-llm-performance/

7. Chip Huyen, Agents, 2025.
   https://huyenchip.com/2025/01/07/agents.html

8. Andrej Karpathy, Software Is Changing (Again), YC AI Startup School, 2025.
   https://www.ycombinator.com/library/MW-andrej-karpathy-software-is-changing-again

9. OpenAI, Harness engineering: leveraging Codex in an agent-first world, 2026.
   https://openai.com/index/harness-engineering/

10. Martin Fowler, Harness engineering for coding agent users, 2026.
    https://martinfowler.com/articles/harness-engineering.html

11. Anthropic, Writing effective tools for AI agents — using AI agents, 2025.
    https://www.anthropic.com/engineering/writing-tools-for-agents

12. Anthropic, Demystifying evals for AI agents, 2026.
    https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

3、官方文档#

1. OpenAI Agents SDK Documentation.
   https://openai.github.io/openai-agents-python/agents/

2. OpenAI Agents SDK Tracing.
   https://openai.github.io/openai-agents-python/tracing/

3. OpenAI Model Optimization Guide.
   https://developers.openai.com/api/docs/guides/model-optimization

4. OpenAI Direct Preference Optimization Guide.
   https://developers.openai.com/api/docs/guides/direct-preference-optimization

5. LangSmith Evaluation Documentation.
   https://docs.langchain.com/langsmith/evaluation

6. Langfuse Documentation.
   https://langfuse.com/docs

7. Arize Phoenix Documentation.
   https://arize.com/docs/phoenix

8. OpenTelemetry GenAI Semantic Conventions.
   https://opentelemetry.io/docs/specs/semconv/gen-ai/

9. Model Context Protocol Documentation.
   https://modelcontextprotocol.io/docs/getting-started/intro

10. Model Context Protocol Tools Specification.
    https://modelcontextprotocol.io/specification/2025-06-18/server/tools

11. Hugging Face TRL Documentation.
    https://huggingface.co/docs/trl/index

12. MLflow GenAI Documentation.
    https://mlflow.org/docs/latest/genai/

13. MLflow Model Registry Documentation.
    https://mlflow.org/docs/latest/ml/model-registry/

4、开源项目与工程工具#

1. Langfuse.
   https://github.com/langfuse/langfuse

2. Arize Phoenix.
   https://github.com/Arize-ai/phoenix

3. Promptfoo.
   https://github.com/promptfoo/promptfoo

4. AgentOps.
   https://github.com/AgentOps-AI/agentops

5. Letta / MemGPT.
   https://github.com/letta-ai/letta

6. Voyager.
   https://github.com/MineDojo/Voyager

7. Microsoft Agent Lightning.
   https://github.com/microsoft/agent-lightning

8. verl.
   https://github.com/verl-project/verl

9. OpenRLHF.
   https://github.com/OpenRLHF/OpenRLHF

10. LLaMA-Factory.
    https://github.com/hiyouga/LLaMA-Factory

11. Hugging Face TRL.
    https://github.com/huggingface/trl

12. τ-bench.
    https://github.com/sierra-research/tau-bench

13. AgentBench.
    https://github.com/THUDM/AgentBench