Agent 工程对照
← 返回框架对照

进化 · 第 6 章

评估与自改进

Harness 自己怎么变好?有没有外循环?

openJiuwen 与 Codex 让系统自己改自己,DeepSeek 与 Pi 把判断权留给人。

谁有权改 Harness

系统改自己

判断留给人

场景建议

编辑判断

按你的需求,倾向哪种做法

借鉴的是那一家的设计,不等于选用那个框架。

场景

先能量出每次改动的效果

它把评估做成仓库内的一等包,在隔离目录里跑真实会话,目标就是比较不同 Harness 配置。

场景

要从历史会话里沉淀记忆

两阶段流水线:先从历史 rollout 抽结构化记忆并脱敏,再加锁合并成记忆目录。

场景

要让系统自动改自己的配置

rsi/ 自成一套闭环:evaluator 跑用例、分析失败、规划并执行改动、迭代爬坡。

容易踩的坑

  • 没有可靠评估的自改进,分不清是改进还是漂移——先有尺子,再谈闭环。

四家怎么做

差异与源码

openJiuwen

把递归自我改进做成一级子系统 rsi/

规模最大的一份,而且正在迁移中:教学基线上的顶层 auto_harness/ 在当前跟踪 commit 已被掏空(只剩 __init__.py),实际编排器搬进了 rsi/auto_harness/orchestrator.py。rsi 下自成一套闭环——evaluator 跑用例、evaluation_result_analyzer 分析失败、member_optimizer 规划并执行改动(action_planner / action_executor)、single_harness/iterative.py 做迭代爬坡。另一条线 agent_evolving 管经验:experience 有 lifecycle / scorer / archive / tracker,optimizer 分别针对 llm_call、memory_call、skill_call、tool_call 四类调用做优化。

适合
有稳定评估集、想让 Harness 自动迭代配置的团队。
代价
闭环很重(评估、分析、规划、执行、爬坡),而且仍在迁移中,结构不稳定。

此后的变化

  • 2026-W38 →

    evolution 消息重建(trajectory_to_messages)不再用文本重叠猜测合并请求 prompt 与历史,而是从可观测层提交的 context window 直接取消息,按 message_id 去重;取消 _longest_overlap/_merge_prompt,压缩请求不贡献内容,缺失提交窗口的请求标记为 missing_context_window。这是本格 rsi 闭环里「轨迹如何变成训练/评估用消息」这一步的重建,标为 BREAKING CHANGE。

  • 2026-W37 →

    本格描述的 rsi 闭环,评估端与产出端同时变厚:evaluator/judger/ 新增 llm_as_judge、judge_evidence、judge_runtime、scoring 与 judge_prompt.md,构成带证据的 LLM 裁判;新增的 data_loader/grading_contract.py 强制评分契约——评分项须显式标注 [weight N%] / [deduct N%],不从任务内容推断规则,正向权重之和不为 100% 直接报错且不静默缩放。产出端由 symphony/flow/ 的经验蒸馏(distill/packager/codegen)产出技能包,rsi 侧补上最终 harness 发布测试。

  • 2026-W36 →

    新增 symphony 图谱演化机制:静态图谱不被改写,运行观测以独立版本叠加;证据分级,仅强验证成功或可归因到 orchestration 的失败参与 runtime_adjustment,弱证据只留审计。

Codex

两阶段记忆流水线,从历史会话里长出记忆

没有做「优化 Harness 配置」的外循环,但有一条跨会话学习的流水线。它在根会话启动时后台异步触发,且带明确的准入条件(非临时会话、特性开启、不是子代理会话、状态库可用)。Phase 1 从状态库领取一批到期的历史 rollout,逐个交给模型抽出结构化记忆(raw_memory + rollout_summary + slug),做密钥脱敏后写回;带并发上限、租约防重复、失败退避重试。Phase 2 拿全局锁做合并,按 usage_count 与最近使用时间排序筛选,落成 raw_memories.md 与 rollout_summaries/,并把整个记忆目录维护成一个 git 基线,每轮写出 workspace diff。

适合
想让助手跨会话「记住」用户与项目习惯的产品。
代价
后台流水线要处理并发、租约、脱敏与 git 基线,运维面不小。
DeepSeek Harness

只收集人类反馈,且明确不回灌模型

四家里最克制的一份:没有自动优化循环,只有一个 feedback 插件族,把人类评价分成两条刻意分开的契约——写进规范会话日志的不可变备注,和挂在某条助手消息上、存本地边车文件的可编辑反馈。README 里有一句关键约束:两种形式都不进入模型对话。也就是说反馈是给人和离线分析用的,不构成运行时自改进闭环。基准测试则完全在仓库外,靠 Python SDK 跑(BENCHMARK.md),要求每个任务用独立工作区与会话 id。

适合
对自动改动持谨慎态度、先要把人类反馈收集起来的团队。
代价
没有运行时闭环,反馈要靠人和离线分析消化。
Pi

内置 evals 包,直接拿来横向比 Harness 配置

唯一把「评估」做成仓库内一等包的实现,而且目标写得很直白:用来比较 prompt、工具、skills、模型或其他 harness 配置。做法是把真实的 AgentSession 适配到 vitest-evals,在隔离的临时项目目录与 agent 目录里跑,并附上原生的 Pi 会话产物。运行时经由 Pi 正常的 ModelRuntime 取凭据,provider 与 model 必须成对给出。这不是自动优化循环,而是把「改一版 Harness 就能量出差异」这件事变成一条 npm 命令——对应课程第 6 章的自建评估 Harness。

适合
想量化「改一版 Harness 到底好没好」的团队。
代价
只给尺子不给优化器,改进本身仍靠人。
横向读这一行

这一行把四家分成了两派。openJiuwen 和 Codex 让系统自己改自己——前者有完整的 rsi 闭环(评估→分析→规划改动→执行→迭代),后者从历史会话里自动长出记忆并合并;DeepSeek 和 Pi 则把判断权留给人——DeepSeek 收集人类反馈但明确不回灌模型对话,Pi 只提供一把尺子(evals 包),让人自己去比不同 Harness 配置的好坏。openJiuwen 的编排器已从顶层 auto_harness/ 迁进 rsi/。

设计空间分析

四家在「谁有权改 Harness」上分成两派:openJiuwen 与 Codex 让系统改自己,DeepSeek 与 Pi 把判断权留给人。

openJiuwen 走得最远:rsi/ 是一级子系统,evaluator 跑用例、结果分析器定位失败、成员优化器规划并执行改动、iterative.py 做迭代爬坡;另一条线 agent_evolving 管经验的生命周期、打分与归档,并分别针对 LLM、记忆、技能、工具四类调用做优化。它也是这一行里唯一还在迁移中的实现——编排器已从顶层 auto_harness/ 搬进 rsi/。

Codex 不优化 Harness 配置,而是让助手跨会话长记忆:根会话启动时后台触发两阶段流水线,先从到期的历史 rollout 里抽取结构化记忆并脱敏,再加全局锁合并、按使用次数与最近使用时间筛选,最后把记忆目录维护成一个 git 基线,每轮写出 diff。准入条件写得很具体:非临时会话、非子代理会话、特性开启、状态库可用。

另外两家刻意不闭环。DeepSeek 只收集人类反馈,并在 README 里写明两种反馈形式都不进入模型对话;Pi 则把评估做成仓库内的一等包,在隔离目录里跑真实会话,目标就是横向比较 prompt、工具、skills、模型等 Harness 配置。

编辑判断

自改进能走多远,取决于评估有多可信。Pi 的做法看似保守,其实是另外三家闭环的前置条件:没有一把可以重复使用的尺子,自动改动与漂移无法区分。建议的顺序是先有 Pi 式的评估包,再考虑 Codex 式的记忆沉淀,最后才是 openJiuwen 式的配置自优化。

还没有定论:openJiuwen 的 rsi 闭环在真实任务上能带来多大提升,仓库内没有公开的基准数据;所以只能比较结构,不能比较效果。

这个问题为什么存在

第 6 章

Harness 工程深入

评估、进化与二阶控制:让 Harness 自己变好