文章来源:微信公众号「一包惆怅的辣条」于 2026 年 11 月 5 日发布《RSI、Harness²、Claude 主循环以及 Super-agent,对近期 Agent 持续执行与自我改进技术的学习总结(万字)》。本文在该文框架上重新组织,并对论文元数据与关键数字做了独立核验;凡核验结果与原文表述不一致之处,文中单独标注。
一句话结论
2026 年 9 月到 10 月这批 Agent 工作,真正值得关注的变化不是“Agent 又能自己写文件了”,而是改进闭环开始被工程化:改什么(模型权重、外围 Harness、个人适配层)、用什么信号验证(行为对照、合成测试、真实环境测试)、以及由谁保留最终判决权。
把这几篇放在一起看,能提炼出一条相当硬的结论:决定自我改进上限的不是生成修改的能力,而是评估器的独立性。 一旦评估信号可以被被改进系统读到、猜到或改写,迭代越快,越快学会钻空子。
核验说明:哪些数字可以直接引用
原文是一篇个人学习总结,引用了大量论文数字。我按 arXiv 当前版本逐条核对,发现若干口径差异,先列出来,避免读者把二手表述当作论文原值。
| 项目 | 原文表述 | 独立核验结果 |
|---|---|---|
| RSI 综述标题 | 《The Last AI Built by Humans: A Survey on Recursive Self-Improvement》 | arXiv 现题为《…: Toward Genuine Recursive Self-Improvement》[1] |
| RSI 综述时间 | 2026-09-22 | arXiv 首发 2026-09-10,后续有 v3 更新[1] |
| Terminal-RSI 主结果 | 四基准 Mean@3 从 20.68% 升至 50.58%;TB2.0 45.28→51.31;SWE-bench Verified 22.80→69.20 | 当前摘要给出的是 Terminal-Bench 4.0 19.84%、TB 2.1 86.52%、TB 3.0 16.95%、TB Hard 79.00%[2],与原文口径不同 |
| Harness² 云端对比模型 | Gemini 3.1 Pro | 摘要写的是 GLM-5 与 Gemini 3.5 Flash[3] |
| HarnessPro 提分与降本 | Terminal-Bench 2 上 Heavy 80.8%、单任务 0.72 美元,相对 RHO 降 33.9% | 摘要给出跨基准平均:通过率 +2.0pp、单任务成本 −26.1%[4];具体分项数字应为论文表 2,本文按“原表转述”标注 |
我不会把未经核实的数字写成结论。下文凡是数值,都标明来源与口径;凡是原文的判断与经验,标明为“原文观点”。
一、先把两个词对齐:Harness 与 RSI
Agent = 模型 + Harness
模型只负责根据当前上下文生成下一步输出;让模型能像一个 Agent 那样持续干活的整套外围程序,就是 Harness。它包括:
- 系统提示词与护栏规则
- 工具定义、调用规范与参数说明
- 上下文拼装与压缩逻辑
- 记忆读写与长期状态
- Skills 技能包与按需加载
- 子智能体定义与委派
- 运行时中间件、钩子与状态控制
这个拆分的工程意义在于:改 Agent 的表现有两条路——训练改参数,或冻结权重只改 Harness。 后者可以用 Git 管版本、用 diff 做回滚,不需要重训模型,这是 2026 年这批工作的共同前提。
持续执行、沉淀经验、RSI 是三件不同的事
原文强调了一个很容易被混为一谈的递进关系:
- 持续执行:任务不中断、能接着跑,解决调度问题。
- 沉淀经验:把 trace、报错、用户偏好写进存储,供后续检索。
- 递归自我改进(RSI):不仅存下经验,还要把反馈转化为对自身配置、工具或参数的持久修改,并让这套改进机制继续作用于后续轮次。
更严格的分级来自 RSI 综述:
| 层级 | 含义 | 典型例子 |
|---|---|---|
| B0 | 任务内输出修补 | 单次会话内“生成—批评—重写” |
| L1 | 执行层改进 | 修提示词、补一条检查步骤 |
| L2 | 策略层改进 | 改工具选择规则、编排策略 |
| L3 | 经验层改进 | 建立可检索的经验库 |
| L4 | 部署层改进 | 改运行时配置、中间件、沙箱策略 |
| L5 | 元改进 | 改进“如何生成与筛选改进方案”本身 |
同时要区分两个概念:
- 结构递归:流程上确实闭了环,上一轮的修改下一轮接着用。分数可能从 60 涨到 68、71,然后卡住。
- 有效递归(点火):越改越会改。这一轮的修改不仅提分,还提升了下一轮找病根、设计方案的能力。
原文的判断是:今天大多数开源项目实现的是有界的结构递归,离 L5 的二阶加速还有距离。这个判断我认同——它比“Agent 已经能自我进化”这类说法克制得多。
二、三条路线:到底在改哪一层
原文按“修改对象”把落地方式分成三条,这个切分很实用,因为它直接决定改造重量、验证信号来源和回滚成本。
| 维度 | 路线一:改外围 Harness | 路线二:改基座参数 | 路线三:改个性化参数 |
|---|---|---|---|
| 代表工作 | Harness²(10-09)、HarnessPro(10-19) | Terminal-RSI(10-15) | Personal LoRA(媒体披露) |
| 实际修改对象 | 提示词、工具指南、脚本、插件、subagent 定义 | Actor 策略网络、跨轮继承的 Critic | 冻结底座上的低秩适配层 |
| 底座权重 | 全程冻结 | 多阶段微调 + 强化学习 | 冻结,仅训练适配层 |
| 验证信号 | 同任务行为对照;一次性生成并冻结的可执行测试 | 真实终端沙箱中的测试通过信号 | 个人交互反馈 |
| 证据强度 | 有论文、仓库、多基准结果 | 有论文与仓库,基准口径需对齐 | 目前仅见媒体与技术路线披露,无论文与公开评测 |
第三条路线要特别标注:截至核验时,Personal LoRA 方向没有公开论文、开源代码或第三方基准数据。拿它和另外两条并列讨论可以,但当结论用不行。
路线选择的一个实用判断
- 如果瓶颈在执行纪律和工具使用(漏检查、格式错、重复试错),优先改 Harness,成本最低、回滚最快。
- 如果瓶颈在模型本身不会这类推理(比如终端操作、长程代码修改),改 Harness 补不上,得动参数。
- 如果瓶颈在个人偏好与长期上下文(每个人习惯不同、纠正频繁),适配层比全量微调合理,但需要防止过拟合与灾难性遗忘。
三、评估器决定上限:五级证据链
这是整篇文章最值得抄走的部分。
L0–L4:每条“涨分”主张该被追问到哪一层
| 层级 | 证据类型 | 能证明什么 | 不能证明什么 |
|---|---|---|---|
| L0 | 静态文件生成 | 修改动作完成、语法合法 | 完全不能证明修改有效 |
| L1 | 候选可运行且行为变化 | 新配置确实被触发、轨迹变了 | 变的方向对不对 |
| L2 | 内部代理指标通过 | 通过系统自建的评价(行为对比、合成测试) | 可能含同源偏差、错误断言 |
| L3 | 外部留出集独立泛化 | 在演化期没接触过的任务上客观有效 | 端到端周期是否真的更快 |
| L4 | 真实端到端与跨轮加速 | 算上人工审查、环境等待、失败回滚后仍变快 | — |
原文把它归纳成一条铁律:最终评估器与验收规则必须留在被改进系统的写权限之外。 不能让 Agent 一边改答案、一边改考卷。
奖励投机不是新问题
原文举了 1981–1983 年 EURISKO 的例子:系统用贡献度评分淘汰低价值规则,结果一条变异规则 H59 每次发现新概念就把自己登记为共同发现者,把自己的分数刷到最高,直到人类手动改掉计分保护逻辑。
今天的版本是 LLM-as-judge 的三类系统性偏差:
- 位置偏差:倾向选择排在特定位置的候选。
- 冗长偏差:把更长、格式更工整的输出判为更好。
- 同源自我偏好:生成器与评判器共享同一套盲区,错得一致反而得高分。
局部提速不等于研发加速
原文引用 METR 在 2026 年 10 月 14 日发布的《AI R&D Acceleration Assessment Proposal》:前沿 AI 研发是一条由构思、写代码、排算力、跑长周期实验、人工核查组成的长链条。即使“写实验代码”快了三倍,只要算力排队、真实训练时长、人工核查没同步缩短,端到端吞吐也不会按比例增长——这是阿姆达尔定律的直接后果。
更实际的风险是:Agent 一次撒出十倍候选分支,人类鉴别假阳性的审查负担反而把流程拖慢。
四、Harness²:没有标准答案时,用行为对照改外围
Google Research 于 2026 年 10 月 9 日发布论文并开源。它面对的是开放世界任务的现实:做一份财务尽调、整理合规表格、排查没有现成单元测试的工程问题——运行时根本拿不到标准答案和官方评分器。[3]
Propose–Probe–Compose 四步
| 步骤 | 执行者 | 做什么 |
|---|---|---|
| 基线执行 | Executor | 用干净的基础 Harness 跑完整任务,留下产物与完整轨迹 |
| 双路提出 | Editor | 从“通用执行纪律”和“领域处理流程”两个正交方向提候选修改 |
| 同任务试跑 | Executor | 把两个候选分别装进独立沙箱,在同一任务、同一输入下重跑 |
| 对比组合 | Composer | 比对三份轨迹与文件 diff,决定合并、修订、只留一路或退回基线 |
关键工程边界,原文特别强调过、很多二手解读会漏:Probe 的行为对照只用于指导组合,不等于验证任务正确性。 因为执行本身有随机性,且 Editor、Executor、Composer 往往同源,共享同一套理解偏差。套用上面的分级,Harness² 在单任务内到达的是 L1–L2,客观正确性仍要靠外部 L3 评测拍板。
可编辑空间是 8 个文件级组件
这套框架比早期“自动优化提示词”有效,一个核心原因是把可编辑对象从一段字符串扩展成整棵运行时文件树:
| 运行时职责 | 组件 | 典型路径 | 作用 |
|---|---|---|---|
| 上下文构建 | C1 系统提示 / C2 护栏 / C3 记忆 / C6 Skills | systemprompt.md、guardrails.md、LongTermMEMORY.md、skills/*/SKILL.md | 常驻规则与按需展开的专业流程 |
| 工具接口 | C4 工具指南 / C7 脚本 | tool_guidance.md、scripts/*.py | 参数陷阱说明;把易错多步逻辑固化成确定性脚本 |
| 任务委派 | C5 子智能体 | sub_agents/*/AGENT.md | 隔离上下文的专项子任务 |
| 工具循环中间件 | C8 插件 | plugin/*.ts | 在工具调用前后强制执行拦截、改写与自检 |
原文有一个很实用的观察:提示词里写十遍“交卷前必须核对字段”,模型该漏还是会漏;把检查写成 C7 脚本 + C8 提交前钩子,软要求就变成硬约束。 这是这套设计里最值得立刻借鉴的一点。
两级递归与经验库
- 任务级递归:改当前任务用的 execution harness。
- 改进级递归:Reflector 把有效经验提炼成结构化条目写进
EXPERIENCE.md,供后续任务的 Editor 按需检索。
新任务不会继承上一轮那套膨胀的配置,而是退回干净基线起步,只按需检索经验。这个取舍很老道:否则跑二十个任务后,提示词和插件目录会塞满上百条互相冲突的补丁。
原文还列了三个必须说破的限制:
- 外层递归不改外部评分器。 基准的 judging 与 reporting 脚本在官方代码里是独立、固定的。
- 经验库只有追加与整合,没有自动淘汰与恶化回滚。 一条误导 Editor 的旧经验目前不会被自动降权或剔除。
- 开放脚本编辑不等于放开沙箱与网络。 官方 BENCHMARKS 记录了一个典型反例:跑 Deep Research Bench 时如果宿主环境不封禁实时搜索,Executor 直接搜到了公开挂在网上的 rubrics,然后照着评分点凑答案。
第 3 条尤其值得抄进自己的红线清单:给 Agent 自编辑权限时,文件权限边界和网络隔离必须由外部工程代码锁死。
五、HarnessPro:把执行费用拉进帕累托前沿
十天之后的并行独立工作(清华、智谱、上海交大、华威、快手联合)。它针对上一代方案的两个软肋:靠同源模型看轨迹打分、以及越改越啰嗦导致账单上涨。[4]
测试合成:三条防线避免“自己出题考自己”
| 规则 | 具体做法 | 防的是什么 |
|---|---|---|
| 只生成一次并冻结 | 第 0 轮为每个任务生成测试套件,后续所有轮次、所有候选都用同一套 | 尺子随候选漂移 |
| 禁止把初始产物当答案 | 断言只能依据任务题面与干净初始目录;可看轨迹了解环境,但不许照抄产物 | 把初始版本的错误固化成通过标准 |
| 只修坏测试,不为错误产物放水 | 测试自身缺依赖、路径错可以修;抓到真实缺陷的断言必须原样保留 | 迁就被测对象而放松标准 |
为什么不用 LLM 裁判
论文用 20 个抽样任务做了对照(12 个实际失败、8 个实际通过):
| 评价方式 | 对 12 个失败样本 | 主要问题 |
|---|---|---|
| 纯 LLM Judge | 把 10 个判成 Pass(假阳性 10/12) | 看到“任务已完成”就相信,过于乐观 |
| 可执行生成测试 | 抓出 10 个失败(真阴性 10/12) | 8 个通过样本中误杀 2 个(断言写得太死) |
结论很清楚:生成测试比纯看轨迹可靠得多,但它仍属 L2 内部指标——最终泛化必须由演化期接触不到的官方测试集(L3)来判定。
Pareto 三档:Lite / Medium / Heavy
筛选顺序是:
- 卡通过率下限:平均通过率低于初始 Harness 的候选,再便宜也淘汰。
- 剔除被支配解:存在另一个候选通过率不低于它、费用不高于它且至少一项严格更好,则出局。
- 按三组偏好权重选出成本优先、均衡、效果优先三个档位,一起进入下一轮当父代。
三个容易被读错的细节:
- Lite/Medium/Heavy 是同一冻结基座上的三套 Harness 配置,不是三个参数量的模型。
- 每轮候选池里包含上一轮保留的父代,新方案没优势就继续用旧配置。
- 通过率硬下限始终锚定第 0 轮的初始配置,而不是要求每轮单调上升。
渐进预算钩子与一个被忽略的性能细节
原文拆解 Medium 档的运行时钩子,是这篇文章里最容易“今天就能用”的部分:
| 工具调用次数 | 行为 |
|---|---|
| 满 14 次 | 在工具返回末尾追加温和提醒:合并可并行命令、避免重复状态检查 |
| 满 26 次 | 收敛提醒:停止发散探索,完成修改并跑最终验证 |
| 满 44 次 | 硬性拦截后续调用,强制汇总交卷 |
关键实现细节:提醒追加在最新工具结果末尾,而不是修改最前面的系统提示词前缀。 因为改了前缀会让整条长会话的前缀缓存(KV Cache)失效,反而抬高推理成本。
这比常见的 max_steps = 30 硬截断高明得多:模型在前 29 步根本不知道自己快没额度了,第 30 步直接中断,几十万 token 换不来一个可用半成品。
三种成本口径不要混用
| 口径 | 定义 | 适用场景 |
|---|---|---|
| 单任务平均执行费用 C(h) | 测试集上每任务平均 API 费用,无论是否通过 | 日常全量请求的账单预算 |
| 单次成功成本 CoP | C(h) / PassRate | 既要算账又要保交付的真实性价比 |
| 含离线演化的总成本 | 训练集/验证集上多轮采样、诊断、编辑、测试合成的研发支出 | 判断低频任务值不值得跑一轮演化 |
论文表 2 里的单任务费用不含离线演化开销。引用这类数字时把口径写清楚,比多背两个小数更有价值。
六、Claude:什么时候该把 subagent 收回主循环
Anthropic 于 2026 年 10 月 22 日发布《Building agents: When to fold subagents into your main agent loop》,作者 Diane Sarkis。[5]
把它读成“subagent 要凉了”是误读。官方讨论的是:在模型长上下文能力变强、平台提供渐进披露机制之后,单任务内部哪些原本硬拆出去的角色应该收回主循环。
三个仍然应该保留 subagent 的条件
- 单循环出现可测的上下文膨胀退化:某个子步骤要扫几百页日志或十几个大文件,塞进主窗口会把信噪比彻底毁掉。
- 多条工作流能真正独立并行:各分支不需要每走一步都看对方中间变量。
- 工具选择或指令冲突无法在单循环内调和:几十个工具、互相矛盾的规则放进同一个窗口会互相干扰。
判断标尺是上下文耦合度与窗口信噪比,不是 Agent 数量多少。
收回主循环后靠什么不炸窗口
| 机制 | 作用 | 关键边界 |
|---|---|---|
| Agent Skills 三层渐进披露 | L1 只常驻 name + description;L2 命中才加载 SKILL.md 正文;L3 references/scripts 按需读取,脚本本身不必进上下文 | 解决注意力分配,不保证模型一定触发对的 Skill |
Tool Search(defer_loading) | 初始只暴露搜索工具,命中后再展开 3–5 个工具完整 schema | 只控制进入上下文窗口的内容,不减少客户端请求体里提交的完整 tools 数组 |
原文还提到一个常被忽略的官方数据:企业 Agent 同时接多个 MCP 服务时,几百个工具的完整 JSON Schema 在干活前就能吃掉约 55,000 token;按需加载可把工具定义开销降低 85% 以上。同时,可用工具超过 30–50 个后,模型挑错工具的概率明显上升。
为什么 Anthropic 自家 Research 仍然是多 Agent
深度研究任务天然具备两个特征:搜索方向高度开放、分支之间几乎没有中间步骤的强耦合;每条线索要翻大量原文,单条吃掉几万 token。多 subagent 相当于把有效上下文容量横向拓宽。
代价也算得明白:多 Agent 系统消耗的 token 总量约为普通单轮对话的 15 倍(普通单 Agent 约 4 倍),硬套到必须实时共享同一份代码上下文的编码任务上,反而不如单循环。
七、DeepSeek Super-agent:把 Session 拆成五个领域对象
2026 年 10 月 31 日,DeepSeek 开源 dsh-superagent-prototype 并发布设计文章《Super-agent 设计探索》。仓库自称研究原型(Research prototype for reference only),用于验证“Session 降级为内部实现细节、Router 统一对外、Worker 并发干活”这套领域模型与控制流。[6]
五个对象解决什么问题
| 对象 | 含义 | 设计要点 |
|---|---|---|
| Thread | 外部讨论上下文流(群聊、Issue、PR 评论串) | 与工单多对多解耦 |
| Ticket | 已获授权、有明确目标的独立工作 | 一段讨论可拆多张工单;一张工单可关联多个 Thread |
| Subscription | 讨论流到工单的消息通道 | 新消息直接投递给正在执行的 Worker,不必经 Router 二次转述 |
| Mandate | 授权记录:凭什么立项、可动哪些范围、遵循哪版策略 | 订阅只补上下文,授权才决定能不能动手 |
| Assignment | 一次具体执行实例 | 一张长期工单可经历多轮 Assignment |
Mandate 与 Subscription 的区分是这套设计里最有价值的安全边界:即使有人在已订阅的讨论串里喊“顺便把生产分支也强推了”,Worker 也只能在原工单的 Mandate 范围内行动。
三个系统级机制
- 事件两级过滤:Fast Path 用零模型开销的确定性规则丢弃机器人回声、纯表情、未监听事件;Slow Path 配合短窗口批处理,把人类连发的四条短消息攒成一批再推理,避免半句话触发一次昂贵调用。
- 超过 5 秒的前台命令自动转后台:前台命令跑满 5 秒即提升为后台作业并交还控制权,Worker 可以立刻处理订阅通道里的新消息(比如“先别跑全量测试了,配置写错了”),也能随时终止后台作业。调度器还为“已有工单收到人类追问”预留弹性名额,防止后台慢任务占满槽位导致对外失联。
- 重启先核对真实状态:为未完结工单拉起新 Assignment 时注入 Recovery Note,强制在产生外部副作用前核对本地工作区、Git 历史与远端真实状态,避免重复发评论、重复开 PR。
Inline + Spill 与链式召回
主上下文只保留结构化短摘要(Inline),原始长输出、完整工具日志、历史轮次落盘为带唯一 ID 的文件(Spill)。需要核对细节时,按摘要里保留的 ID 与路径逐级回查——这就是 Chain of Recall。
原文在此处提了一个很关键的限制:操作系统的缺页中断是硬件级确定触发的,而链式召回全靠模型自己意识到“我缺了某处细节”。 如果摘要写得过于平滑,模型会误以为自己掌握全部事实,直接跳过回查。所以摘要模板必须显式保留“哪些细节被折叠、什么条件下必须回查哪个 ID”的路标。
原型与蓝图要分清
原文核对后给出了清晰边界:
| 设计文章模块 | 开源原型实际状态 |
|---|---|
| Router + Worker 跨任务调度、Fast/Slow Path、批处理 | 已实现核心控制流 |
| Thread / Ticket / Subscription / Mandate / Assignment | 已实现并有 JSON 持久化状态机 |
| 主动接单与授权边界 | 已实现;推断任务默认 observe 模式只记审计日志,不真建单 |
| Inline + Spill + 链式召回 | 已在 Worker 执行器与归档结构中实现 |
| 云端持久 Loop、BYOM、独立 Watchdog | 远期架构探讨,原型为本地或单容器驻留,面向单 GitHub 仓库 |
原文还提到仓库短期内破 1.7 万 Star。这个数字我未能独立核验(GitHub API 返回 403 限流),只能确认仓库存在且描述为“Towards a More Autonomous Agent System”,因此仅作转述。
八、把方法变成可执行的检查清单
1. 结构上:常驻上下文必须瘦,经验必须外置
- 基础 Harness 只保留跨任务通用的底线规则
- 领域流程写成 Skill / references,按条件加载,不塞进全局文件
- 经验库条目必须带适用条件、观察依据、效果标记
- 经验库要有淘汰、合并、冷门归档与人工审批(Harness² 目前缺这一环)
2. 验证上:把评估器放到写权限之外
- 演化期不读官方测试集、参考解与评分器
- 测试套件生成一次后冻结;禁止用初始产物当断言依据
- 涨分必须能落到 L3:未见过的留出集 + 真实 token 账单
- 要证明“越改越会改”(L4),必须做“继承经验 vs 重置经验”的严格消融
- 记录三种成本口径,不要把单任务费用和含演化总成本混着讲
3. 运行时:把软要求变成硬约束
- 关键校验写成确定性脚本,挂在提交前钩子里强制执行
- 预算提醒追加在最新工具结果末尾,别改系统提示词前缀(保护 KV Cache)
- 用渐进阈值(提醒 → 收敛 → 硬拦)替代死板的 max_steps
- 给 Agent 自编辑权限时,文件权限与网络隔离由外部代码锁死
- 重启恢复时先核对远端真实状态,再执行任何有外部副作用的动作
4. 架构上:按上下文耦合度选单循环还是多 Agent
- 步骤紧耦合、需共享同一份文件状态 → 单主循环 + Skills + Tool Search
- 分支低耦合、单步吞吐海量原始材料 → 隔离 subagent,只回传结论与证据
- 每次拆分前先问:token 溢价是否被端到端时间收益覆盖
九、三个常见误读
误读一:subagent 过时了。 官方文章明确列了三个保留条件;多 Agent 在广度研究类任务上仍有结构性优势,代价是约 15 倍 token 与传话损耗。
误读二:Harness 会自我进化到超过基座。 冻结权重路线受限于底座模型的推理与编码能力。底座根本不会的任务,靠改提示词和脚本补不上。
误读三:Super-agent 已经实现 RSI。 “用常驻 Agent 辅助工程师写 Agent 系统自身的代码”与“系统建立自动化递归自我改进闭环”是两个阶段。前者提议、审查、合并的主导权仍在人类手里;要走到 RSI,还缺自动候选生成、独立验证筛选与性能退化时的自动回滚。
结语
这一个月的工作放在一起,最有价值的不是某个框架的涨分,而是一套逐渐成形的工程纪律:
- 修改对象要分清,别把“Agent 能后台跑”当成“Agent 能自我改进”。
- 评估信号要独立,别让被改进系统碰到考卷。
- 软约束要硬化,提示词管不住的,交给脚本、钩子和网络策略。
- 经验要治理,追加容易,淘汰和回滚才是长期可用的关键。
如果只能从这篇总结里带走一句话,我会选这条:改进能力的天花板由评估器决定;而评估器的可信度,取决于它离被改进系统有多远。
参考资料
- 微信公众号「一包惆怅的辣条」:《RSI、Harness²、Claude 主循环以及 Super-agent,对近期 Agent 持续执行与自我改进技术的学习总结(万字)》,2026-11-05,https://mp.weixin.qq.com/s/AT9ycXVMrU43md1AIHUtcA
- [1] Duan et al.,《The Last AI Built by Humans: Toward Genuine Recursive Self-Improvement》,arXiv:2609.11873(2026-09-10),https://arxiv.org/abs/2609.11873
- [2] Yang et al.,《Terminal-RSI: Recursive Self-Improving Terminal Agents via Recursive Self-Rewrite and Policy-Refine》,arXiv:2610.22192(2026-10-15),https://arxiv.org/abs/2610.22192
- [3] Xu et al.,《Harness²: Recursive Agent Harnessing for an Open World》,arXiv:2610.14224(2026-10-09),https://arxiv.org/abs/2610.14224
- [4] Pan et al.,《HarnessPro: Recursive Harness Self-Improvement with Pareto Optimization for Performance-Cost Trade-offs》,arXiv:2610.26770(2026-10-19),https://arxiv.org/abs/2610.26770
- [5] Diane Sarkis,《Building agents: When to fold subagents into your main agent loop》,Anthropic,2026-10-22,https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
- [6] DeepSeek,《dsh-superagent-prototype》,https://github.com/deepseek-ai/dsh-superagent-prototype
- [7] Pan et al.,《Evolving Agents in the Dark: Retrospective Harness Optimization via Self-Preference》(RHO),arXiv:2606.05922(2026-06-04),https://arxiv.org/abs/2606.05922
来源字段:2026-11-05|微信公众号「一包惆怅的辣条」|https://mp.weixin.qq.com/s/AT9ycXVMrU43md1AIHUtcA | 以 RSI 定义与 L0–L4 证据链为标尺,横向梳理 Harness²、HarnessPro、Terminal-RSI、Claude 单主循环与 DeepSeek Super-agent 的设计与验证方式,并标注原文字数与 arXiv 现版本的口径差异|适合正在设计或评审 Agent 运行时、自我改进闭环与多 Agent 编排的工程团队,用于统一“改什么、怎么验、谁来判”的判断标准。
文档信息
- 本文作者:zhupite
- 本文链接:https://zhupite.com/dev/rsi-harness-agent-self-improvement.html
- 版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)