摘要
Agent 在产品中的能力由模型、上下文、工具和业务实现共同决定。本文结合 ProductFlow 的开发经验，讨论如何将任务中的失败转化为可验证的系统修改：从真实执行记录中提出根因假设，在隔离环境生成指令或代码候选，通过固定评测与独立验收判断改进，再将精确版本提交用户批准。我们重点讨论改进对象、失败归因、数据隔离、收益比较，以及自动化进入真实业务后必须面对的成本与恢复问题。当前已实现领域壳工件、版本归因和有界诊断轨迹；完整自动改进系统仍处于设计与建设阶段，本文不报告自动进化的实验收益。
1 引论：从完成一次任务，到改善完成任务的方式
1.1 一个产品问题
我们在 ProductFlow 中研究 Agent，起点是一个具体的产品目标：帮助商家更高效地得到符合预期、可以实际使用的商品素材图。用户提供商品资料和参考图，在可编辑的工作流中组织文案、提示词与图片生成；Agent 协助理解需求、修改工作流、发起运行和处理失败。
这类任务有一个特点：操作步骤往往不难描述，正确完成却依赖许多细小约束。模型需要知道用户指的是哪个对象，哪些事实已经确定，哪些修改会影响共享依赖，以及什么时候必须等待确认。一次看似流畅的执行，可能在其中任何一个环节偏离目标。
例如，用户要求“只把第二张图的背景换成暖色，其它保持不变”。如果 Agent 修改了整组图片共用的方案，第二张变了，第三张也变了，那么图片再漂亮，这次任务仍然没有完成好。
这个简化场景贯穿本文，用于解释设计，并非一次已完成的自动优化实验。它重要的地方在于：仅凭最后一张图或一句“执行失败”，无法知道应当修改什么。
模型可能忽略了作用范围，工具可能没有暴露共享依赖，业务实现也可能更新了错误对象。工程师需要检查当时的输入、实际调用和最终状态，才能把一个结果上的偏差，转化成一个可以修复的问题。
1.2 经验为什么没有自然地变成能力
在日常开发中，这段过程主要依赖人。工程师找到失败、解释原因、修改实现、补充回归，再决定是否发布。系统虽然保存了大量记录，真正把经验转化为改进的工作，仍然发生在记录之外。
记录更多历史并不能自动解决这一问题。一段对话可以说明用户说过什么，却未必能说明工具实际做了什么；一次成功可以留下可模仿的轨迹，却不能保证相同策略适用于另一个任务。经验只有关联到目标、环境、解释和验证，才具有可复用的范围。
我们因此区分三个不同层次：
| 层次 | 改变的对象 | 需要回答的问题 |
|---|---|---|
| 当前任务调整 | 本次执行的目标、计划或输入 | 怎样把眼前任务做对？ |
| 经验与偏好记忆 | 后续任务可能读取的上下文 | 什么经验值得保存，何时适用，如何撤回？ |
| 系统自进化 | 影响后续执行的指令、工具或代码版本 | 修改是否有效，是否引入退化，能否被批准使用？ |
这三者可以相互支持，但不能互相替代。记住用户喜欢某种风格，不等于修复了错误的对象定位；在一次任务里临时创建分析脚本，也不等于这段代码适合成为长期生产工具。
本文聚焦第三层：让系统依据执行证据，主动提出并检验对自身工作方式的修改。模型权重训练不在当前研究范围内。
1.3 研究问题与判断标准
我们将 Agent 自进化限定为一个有边界的工程过程：系统在预先确定的目标、权限、数据和预算内，自动选择问题、提出根因假设、产生修改并验证，通过验证的候选才有资格成为后续版本。
这一定义对应四个研究问题：
- 问题从哪里来？ 执行记录是否足以说明真实失败，系统能否自动找到值得处理的问题？
- 应该修改什么？ 如何区分指令、观察、工具与业务实现中的根因？
- 怎样证明改进？ 如何排除测量偏差、随机波动和对评测材料的适应？
- 改进是否值得？ 自动搜索的效果、费用和人工投入，与普通工程修复相比有什么差别？
我们希望分别回答“流程能运行”“确实修复了问题”和“能够持续带来产品收益”。一次端到端演示可以支持第一项，一个有效对照可以支持有限范围内的第二项，第三项则需要更多任务和更长时间的证据。
没有改善、证据不足或预算耗尽，都是有效结论。允许系统如实结束，是研究能够被证伪的前提。
2 相关研究：从反思到可执行的修改
Self-Harness 将自改进组织为失败挖掘、修改提案和回归验证，并研究由基础模型参与改善自身 harness 的方式。它对我们的直接启发，是把执行与改进放在同一个可追溯的实验框架中：失败应当指向具体机制，修改应当经过回归，结果应当归属于明确的模型与环境。
这里有一个容易忽略的区别：开发者使用更强的编码模型搭建控制器，与生产模型参与改善自身 harness，是两种实验条件。两者都可能有价值，但不能在效果报告中混为一谈。生产模型、提案模型以及语义评分模型，需要按角色分别记录。
GEPA 利用执行轨迹和自然语言反思搜索提示词修改。它提示我们，失败过程包含比分数更丰富的信息。一个标量只能说明某次任务得分低，工具反馈和执行步骤则可能解释问题出在哪里。将这些信息压缩成过短的摘要，也可能丢掉生成有效候选所需的事实。
Meta-Harness 进一步让提案器按需访问历代候选的源码、成绩与轨迹，将搜索对象扩展到 harness 代码。对 ProductFlow 而言，这支持一种实际的取舍：提供可以检索的证据文件和索引，让提案器按问题读取，而无需一开始就建立复杂的知识平台，或把全部历史塞进一次上下文。
Darwin Gödel Machine 研究 Agent 代码的自修改，并通过候选档案支持分叉探索。失败分支可以为后续搜索留下信息，有些暂时不占优的方向也可能成为新的起点。不过，研究档案中的探索价值与生产发布资格需要分别判断。我们可以保存一个失败候选，同时明确它不能被部署。
Auditing Harness Tampering in Self-Improving Agents 则讨论了自改进过程中对评分、授权、证据来源和记录完整性的破坏。候选如果能改评分器、隐藏失败或改变哪些样本进入报告，分数上涨的解释就不再可靠。这个问题要求把判断改进的权力，保留在候选修改范围之外。
这些工作的共同启发是：搜索对象可以从文本扩展到代码，搜索反馈可以从分数扩展到执行证据，但接受结论仍然需要可信的外部验证。本文据此讨论 ProductFlow 的设计选择。我们尚未复现这些论文，论文中的实验收益也不作为 ProductFlow 的效果声明。
3 系统设计
3.1 改进对象与业务权威
模型之外的执行组织机制通常被称为 harness，包括上下文组织、工具适配、执行控制与结果验证。ProductFlow 当前使用 Pi 承担通用模型循环，将商品图任务所需的指令、Skill 和工具组织为领域壳。业务状态、确认和持久化由 Go 后端与 PostgreSQL 负责。
我们曾投入自研 Agent 运行时。随着业务演进，模型适配、会话和执行循环的维护，与商品规则逐渐纠缠。切换到 Pi 后，通用能力有了可以复用的上游，项目得以把更多精力放在领域工具与业务结果上。自进化设计延续这一分工，不另建一套商家生产执行器。
图 1. 当前 Agent 执行与业务权威的分工。 Pi 组织模型交互，Go 与数据库决定业务操作是否成立。模型生成的完成声明不能替代实际业务状态。
这一分工决定了修改应当发生的位置。缺少必要观察时，检查工具与上下文；观察完整但决策错误时，研究 Skill 或行为指令；正确请求产生错误写入时，修改业务实现。候选可以跨越必要层次，但需要对应同一个因果假设。
当前研究范围因此包含指令、领域壳，以及事前批准范围内必要的工具和业务代码。权限与确认语义、正式评分、费用上限、生产迁移和发布授权不由候选修改。
这里的限制是本期实验的固定边界。它使我们能够知道：某项候选是在既定任务中改进了行为，还是改变了任务、权限或判定标准。
3.2 从执行记录到可检验的解释
一条可用于改进的记录，至少需要保留当时的用户目标、模型可见事实、实际工具参数、工具反馈和业务后置条件。任务与试验身份、代码和模型配置，以及记录是否完整，也需要能够对应起来。
这些材料各自回答不同的问题。用户目标说明应该完成什么；可见事实限制我们能合理要求模型知道什么；实际参数说明它采取了什么行动；工具反馈与后置条件说明世界到底发生了什么。
只看其中一部分，会产生很有说服力但难以验证的解释。例如，用户最终撤销了操作，不能倒推出 Agent 必然违反了最初要求；日志里没有某个事实，也不能在记录可能截断时断言模型从未见过它。
提案器应输出三项相互对应的内容：假设、补丁、行为预测。以“只改第二张图”为例，可以得到三种竞争性的解释。
| 根因假设 | 需要核对的证据 | 可以检验的修改 |
|---|---|---|
| 模型忽略单张作用范围 | 当时是否已经提供对象及共享关系？模型实际选择了什么？ | 调整指令或 Skill，检查单张与整组请求能否分别正确处理 |
| 工具缺少共享依赖信息 | 读取结果是否足以判断修改会影响哪些对象？ | 补充必要观察，再比较对象选择与副作用范围 |
| 业务实现更新了错误对象 | 请求参数是否正确？真实写入与参数是否一致？ | 修复对应代码，通过旧版复现、新版通过及相关回归验证 |
这张表的作用是防止过早把所有失败归因到 Prompt。修改范围可以很小，也可能确实跨层；决定范围的依据应当是因果链。
验证还需要反例。如果候选让单张请求成功，却让明确要求整组修改的请求失效，它可能只是记住了某种保守动作。我们希望看到的是符合任务条件的行为变化。
对随机模型行为，一次干预前后的结果仍不足以证明根因。它可以提高某个解释的可信度，后续还需要重复试验和其它场景。模型生成的根因分析，在证据支持之前始终是一项假设。
3.3 有界搜索与停止
首期设计采用单个当前父版本、串行候选和固定验证。实验启动前冻结代码与依赖、模型请求配置、任务与评测版本、修改范围、预算和停止条件。系统在隔离副本中运行，生产实例继续使用当前版本。
图 2. 计划中的有界候选搜索。 通过内部筛选只授予实验父版本资格。预算和停止条件由候选之外的可信控制逻辑执行；独立验收失败会结束本次交付。
构建和针对性回归先筛除能够廉价发现的问题，再运行需要模型调用的比较。候选新增的测试可以证明它试图修复什么，正式成绩仍由固定验证程序和受保护材料给出。
每次尝试都保留父版本、证据位置、假设、补丁、验证结果、拒绝原因与费用。重复提交相同候选不增加独立样本数，缓存也只复用实验身份完全一致的已完成试验。
我们暂时不引入种群、岛屿搜索和跨候选自动合并。一个原因是成本，另一个原因是可解释性：在尚未确认输入和测量可靠时，同时探索大量分支，只会更快地产生难以归因的结果。
后续如果同预算对照表明单父版本搜索受限，再研究更复杂策略。停止并不表示过程无效；“在这组任务与预算内没有找到改进”，同样能帮助判断下一步应该改善数据、搜索方法还是修改范围。
4 验证方法
4.1 先验证测量能否反映真实业务
在梳理 ProductFlow 的评测时，我们遇到过工具反馈与真实业务语义不一致的问题。有些配置修改在测试端直接赋值并返回成功，绕过 Go 校验；有些结构操作只有精确命中预录数组，才会返回观察结果。
这会产生两个方向的偏差：业务不接受的操作可能被测试环境接受，合法但未预录的操作也可能得不到真实反馈。把这些轨迹直接用于自进化，可能使候选越来越适应测试环境的偏差。
这类问题已经推动图修改反馈改由真实的隔离 Go 宿主执行。但观察实现修正，与取得新的完整模型评测，是两项不同的工作。当前仍需基于稳定后的观察路径重新采集完整基线，旧分数不能与新分数直接拼接。
由此，我们把记录区分为行为失败、测量无效和基础设施故障。
| 记录类型 | 判断依据 | 实验用途 |
|---|---|---|
| 行为失败 | 目标和观察充分，Agent 仍选错对象、遗漏约束或越权 | 用于诊断与候选比较 |
| 测量无效 | 必要观察缺失、效果未知，或评分与真实业务冲突 | 保留诊断；修复测量后建立新的比较 |
| 基础设施故障 | 环境中断、服务不可用等非任务行为问题 | 保留原批次与替代关系，按固定规则处理 |
验证必须落到业务后置条件。工具调用返回、Agent 结束一轮对话、图片生成成功，分别说明不同的事情。对于图修改，需要检查目标写入、其它对象的状态与确认过程；对于运行任务，还需要区分“请求已提交”和“运行已经完成”。
正式比较不能靠删除不利记录缩小分母。未知效果保持未知，不完整批次不能包装成有效通过率。测量修订与行为修改也应分开审核和冻结，否则无法判断提高的究竟是系统能力，还是评分对系统的宽容程度。
4.2 数据用途与访问隔离
我们将材料分为开发集、隐藏回归集和独立验收集。划分依据是实际用途与访问权，而非文件上的标签。
图 3. 三类评测材料的用途。 同一任务的改写及同源场景变体留在同一集合。学习、筛选与最终验收需要不同的使用边界。
开发集支持失败分析与提案。隐藏回归集用于日常候选接受与拒绝，其题目、参考解、逐题结果和轨迹不提供给提案器。独立验收集在最终候选冻结后使用，不参与搜索或排序。
隐藏回归集虽然不直接暴露题目，搜索仍会通过接受和拒绝的信号间接适应该集合。尝试的候选越多，这种选择影响越值得注意。因此，隐藏回归集承担验证集职责，不能同时被当作完全独立的最终证据。
如果最终验收失败后，我们把案例用于诊断和新修改，它们就进入了开发过程。下一次独立验收需要新的未暴露材料，并记录用途变化。换一个测试 ID，或者对原题改写几句话，都不能恢复独立性。
隔离也不能只存在于流程说明里。候选环境只能读取获准开发资料，正式评分、隐藏材料和结果记录由可信执行方掌握。进程内函数的分工、容器的名称或提示词中的禁止语句，都不能独自证明实际访问权已经隔离。
这里的独立验证可以自动运行。它要求数据与权力分离，不要求每一轮都由另一个工作组或用户手工接力。
4.3 配对比较与不确定性
模型任务具有随机波动。同一个请求偶尔完成，与在相同约束下稳定完成，对产品有不同意义。我们计划在相同任务、初始状态与请求配置下配对运行基线和候选，平衡运行顺序，再以任务为单位汇总重复试验。
对于任务 i，可以记录差值 Δᵢ = 候选成功频率 − 基线成功频率。保留逐任务差值，能够看到哪些任务改善、哪些任务退化，避免总体均值掩盖重要回归。相同任务的多次试验仍然相关，不能简单地把它们都当作独立业务样本。
固定运行三次可以作为操作起点，但不能单独证明统计显著。需要进行置信推断时，试验次数、分析方法、停止规则与任务分组应在实验前确定。在看到分数上涨后才选择停止，容易把随机波动保留下来。
重复运行与独立复跑也有区别。前者观察一次评测中的稳定性；后者在候选筛选完成后，用新的试验重新比较，避免直接拿“选出这个候选的那批好成绩”作为最终证据。最终独立验收还需要未参与搜索的材料，它回答的是搜索之外的表现。
确定性代码缺陷采用另一类证据：旧版可以稳定复现、候选修复、相关回归通过，可以证明一个具体缺陷得到修复。这与模型在未见场景上的行为收益应分别报告。
多轮搜索结束时，还要把最终候选与本次原始基线比较。只看相邻父子版本，可能遗漏多次局部修改造成的整体退化。例如，多个补丁分别增加澄清或读取步骤，每轮看起来都合理，累积后却可能让普通任务变得冗长而昂贵。
4.4 人工改进与自动改进的共同起点
我们希望知道，这套机制相对于普通工程修复究竟有什么价值。图 4 给出拟采用的共同起点对照。
图 4. 人工改进与自动改进的对照设计，尚未取得实验结果。 A→B 与 A→C 分别归因。任务、模型和评测条件保持一致，搜索费用与人工时间分别记录。
如果工程师已经指定具体问题、完成诊断或手写补丁，那份结果可以验证执行器与工程流程，但不能计为自动发现到改进的证据。开发者用编码助手建设控制器，也不计作被测系统自身的自动收益。
比较还需要区分生产模型、提案模型和评分模型。换用更强的提案模型，可能得到更好的补丁，但结论应写明这一条件。两条路径的搜索预算不同，也不能直接宣称方法的公平胜负。
业务指标应同时包含任务成功、错误作用范围、未确认副作用、必要澄清与无用往返。费用、耗时与人工投入单独记录。最终图片的审美和商业可用性仍需要相应的图片质量评估，不能从 Agent 的工具通过率推导出来。
在发布结论时，我们希望保留三项信息：改进在哪些任务上出现，在哪些任务上没有出现或发生退化，以及获得这些结果用了多少资源。一个只能展示胜出案例的报告，无法支持产品投入决策。
5 实现现状与交付约束
5.1 当前基础与尚缺的证据
当前实现为后续实验提供了部分基础，但还不足以支持持续自进化的结论。
| 部分 | 当前实现 | 仍待验证或建设 |
|---|---|---|
| 领域壳 | 四段行为指令、固定权限摘要、可哈希工件，启动时冻结 | 候选晋升与完整自动改进 |
| 版本归因 | 生产请求、检查点和评测记录关联 harness 身份 | 结合代码、依赖、Skill、模型和环境完成实验归因 |
| 诊断轨迹 | 默认关闭的有界结构记录，省略用户原文和工具正文 | 充分且获准的开发证据；现有轨迹不能独自重放任务 |
| 评测基础 | 题集、运行器、分层评分、集合冻结和结果记录；图修改反馈已接真实隔离 Go 宿主 | 新的完整可信基线、隐藏材料隔离及最终独立验收 |
这里尤其需要区分“有身份”和“有完整实验身份”。harness 的哈希能说明使用了哪份领域壳工件，却不能单独说明 Go 代码、依赖、基础 Skill、模型参数和业务环境是否相同。同一份指令放进不同环境，结果仍可能改变。
有界诊断轨迹也有类似边界。它适合低负担地保留结构线索，不能替代完整且获准的任务证据。记录完整不等于业务成功，记录缺失也不等于某个事件没有发生。必要补证应在隔离实验环境中进行，避免把线上诊断无限扩张成全量内容采集。
目前核心缺口仍是自动选题、假设检验、候选生成、多轮验证和最终交付的完整系统。已有基础可以支持建设这些能力，不能代替它们已经运行有效的证据。
5.2 精确版本与一次最终审批
实验中的有效候选，还需要成为可以检查和批准的交付物。审批之前，应当已经完成目标版本上的集成、构建、相关回归和独立验收，并准备修改原因、结果、成本、风险与恢复说明。
图 5. 计划中的正常批准路径。 验收失败不进入审批，用户拒绝不进入发布；批准后的身份漂移也会停止应用。图中流程尚未实现。
主线在实验期间发生变化时，需要重新区分两项结论：候选在原冻结版本上的研究收益，以及它在实际目标版本上的交付资格。旧实验通过不覆盖一个未验证的新组合。
批准应绑定最终代码、构建、依赖和有效配置。它不授权下一轮任意修改，也不能在版本漂移后被自动沿用。代码恢复与已经发生的数据写入、外部调用和费用需要分别处理；回到旧代码，不会自动撤回所有业务后果。
“一次最终审批”的含义，是把必要工程工作前置到一个具体、可审查的版本上。它不减少证据要求，也不能用用户同意来弥补未完成的验证。
5.3 预算与中断恢复
费用上限需要覆盖诊断、提案、候选执行、失败重试和最终验收。搜索开始前预留验收额度，才能避免找到候选后已经没有预算验证。调用上限从可信配置读取，候选不能自行提高。
只限制候选数量并不足够。一个候选可能触发很长的执行轨迹，多次失败重试也可能耗尽费用。实际 usage 无法取得时，应当标记未知，不能当作零成本。
恢复过程尤其需要处理“请求已发出、结果未记录”的窗口。进程崩溃后，本地没有成功记录，不代表外部请求没有执行。能够通过请求标识核对的调用需要核对；无法核对时保留未知结果和费用，停止该实验。重启不得清空预算或让失败尝试从历史中消失。
我们需要分别验证调用前、调用后尚未记录结果、结果已经落盘这几类中断。保存了候选档案或 checkpoint，只能证明部分进度可恢复，不能据此推导付费副作用可以安全重试。
6 讨论：自进化可能改变什么
6.1 反馈可以进入研究，含义需要保留语境
商品图任务包含大量主观反馈。用户撤销、重生成或表示不满意，可以提供调查线索，却不能直接证明 Agent 发生错误。
需要核对要求出现的时间、当时可见的事实与实际执行。明确要求单张修改却改了整组，是可检验的行为偏差；看到图片后新增色调偏好，是需求的继续形成；输入符合要求而成图失真，还涉及图片模型本身的表现。
直接优化撤销率或重生成次数，可能诱导系统少执行、多追问或过度拒绝。一个表面稳定、却总让用户重复确认的 Agent，也可能没有提高工作效率。首期因此从具有明确业务后置条件的任务出发，保留成功条件与负例检查。
长期偏好记忆值得研究，但需要独立的产品语义。一位用户对一个商品的偏好应该持续多久，适用于哪些任务，怎样撤回，何时因新要求失效？这些问题直接影响记忆是否有用。将单次反馈追加进全局 Skill，会把局部经验过早变成普遍规则。
我们更希望经验保留来源、作用范围和修订关系。这样，系统将来不仅能解释“为什么记住这件事”，也能知道什么条件下应该停止使用它。这仍是后续方向，不是当前自动改进的启动前提。
6.2 模型特化与泛化需要分别证明
当前设计首先验证固定业务版本和模型组合上的改进。不同模型可能有不同的工具使用习惯、上下文敏感性与失败模式。一份对某个模型有效的 harness，未必对另一模型同样有效。
这不意味着模型特化的结果没有价值。产品运行在明确组合上，只要收益可靠、适用范围清楚，就可能值得采用。跨模型泛化则是另一项需要实验回答的问题。
模型升级、工具变化或请求配置调整，都可能改变原结论。未来可以在多个模型上比较同一基线与候选，分别报告参与调优的模型和未参与的模型，检查迁移收益与退化。仅仅能够接入多个模型，不能证明优化效果能够迁移。
对于创业团队，这也是投入顺序的问题。先证明一个真实使用组合上的价值，能够为更大的研究投入提供依据。当前尚不需要为追求通用性建立多套长期分支和大规模模型矩阵。
6.3 系统会变得更好，还是只会变得更复杂
持续添加规则是一种容易出现的改进方式。每遇到一次失败，就增加一条提醒、一项特殊处理或一轮额外检查。短期看，每个补丁都能找到理由；长期看，系统可能越来越长、越来越慢，也更难预测规则之间的冲突。
因此，候选质量需要同时考虑效果和复杂度。删除已经失去作用的指令、压缩重复上下文、让工具直接返回必要事实，都可能比再增加一层提示更有价值。这些修改同样需要验证，不能仅凭文本更短就认定更优。
失败档案也不能无限积累成另一个难以使用的历史库。真正有用的单位应当包含问题、证据、尝试和适用条件。保存一万个补丁，与知道其中哪些机制曾在什么条件下有效，是两种不同的能力。
更复杂的搜索、自动合并乃至控制器自身的改进，都可以继续研究。但当改进过程本身也进入搜索对象时，仍需要保留一个候选无法自行重写的评价、预算和授权边界。本期固定控制器，是为了得到可解释的第一批证据，并不构成对未来研究空间的永久限制。
6.4 从技术演示到产品资产
自动修复一个问题，是重要的工程结果，但还不足以证明值得长期运行这套系统。我们需要同时考虑建设成本、运行费用、验证开销、人工审查和错误发布的代价。
有些问题频率低、根因明确，工程师直接修复可能更有效。有些问题反复出现、记录充分、验证明确，则更适合研究自动发现和改进。自动化的价值需要落在具体任务分布上。
这一判断也会影响我们如何建设数据。低成本保存大量缺少目标、版本或真实结果的日志，未必比少量可重放、可验证的案例更有价值。真正稀缺的可能是能够支持判断的证据，而非日志数量。
我们期待的产品资产，是一组逐渐积累的、带来源和适用条件的改进知识：某类任务为什么失败，哪些修改有效，付出了多少代价，在什么环境下应重新验证。它可以帮助后续 Agent，也可以帮助工程师更快理解系统。
这让自进化研究与日常软件工程形成了联系。即使最终发现某些环节更适合由人处理，围绕可观察性、可复现性和验证边界建立的能力，也能改善产品的维护方式。
7 结语
我们希望让 Agent 的工作经验逐渐成为系统可以复用的知识。这需要保留经验的完整来源：当时的目标与观察、被检验的解释、实际修改、验证结果，以及结论成立的条件。
本文提出的路径是以可测任务为起点，用根因假设约束修改，用独立验证约束接受，再用精确版本和一次最终审批约束交付。当前已有部分实验基础，下一步需要证明系统能够自动完成真实改进，并在未参与搜索的任务上检验效果。
更长远的问题，是这种改进能否持续、是否值得，以及系统能否在积累经验的同时保留清楚的行为边界。我们没有预先肯定的答案，希望通过可以失败、可以复算的实验逐步回答。
当今天的一个真实错误，能够成为明天少犯一次同类错误的可靠依据，自进化才开始具有产品意义。
参考文献
- Self-Harness: Harnesses That Improve Themselves. arXiv:2606.09498.
- GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning. arXiv:2507.19457.
- Meta-Harness: End-to-End Optimization of Model Harnesses. arXiv:2603.28052.
- Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents. arXiv:2505.22954.
- Auditing Harness Tampering in Self-Improving Agents. arXiv:2609.00069.
继续阅读
评论