AgentDevel

先给结论

AgentDevel 是这组 Drift Monitor 论文里最像“可直接做 baseline”的一篇：它不把自进化看成 agent 内部的神秘反思，而是把 agent 当成可发布的软件制品，用 release candidate、非回归 gate、审计记录和单一版本线管理改进。

#3Drift Monitor Top 10 精读优先级

1每轮只合成一个 release candidate

0full pipeline 在 WebArena 消融表中的 bad release count

为什么它很关键： 第 1 篇 Misevolve 告诉我们自进化会坏在 model / memory / tool / workflow；第 2 篇 Goal Drift 告诉我们怎样量化目标偏移；AgentDevel 给出工程骨架：候选变更必须像软件 release 一样经过诊断、非回归、accept/reject。我们的 Drift Monitor 最自然的位置就是这个 release gate。

版本说明：本页基于公开 arXiv PDF、公开 arXiv source package、TeX source inventory 与图表/表格抽取完成；检索日期为 2026-05-26。公开页面只列出公开在线证据，不暴露本地路径或私有运行日志。

研究动机

论文从一个很工程化的判断出发：unreliable improvement can be more damaging than no improvement at all。如果 agent 改进后平均分上升，但之前能做对的 case 被破坏、改进路径无法复现、失败原因不可审计，那么这个“自我提升”对真实系统反而危险。

现有 self-improvement 常有三种 framing。第一是 improvement as cognition：让 agent 反思、存 memory、下一次做得更好，例如 Reflexion / Self-Refine。第二是 improvement as search：在很多 prompt、thought、scaffold 或 variant 中搜索，例如 PromptBreeder、Tree of Thoughts、DGM 风格系统。第三是 aggregate-score optimization：只看 leaderboard 平均分。

AgentDevel 的反驳是：真实软件不会靠程序“自我反思”发布新版，而是靠外部工程流程。开发者收集日志、跑测试、诊断失败、生成候选补丁、审查 regression，然后决定是否 release。于是 agent improvement 也应该被外置成 release engineering。

数学表示及建模

AgentDevel 把 agent 的 prompt、code、tooling internals 合称为 agent blueprint。改进 agent 就是提出并验证 blueprint 的变更，而不是让 agent 在内部模糊地“变聪明”。

任务有 development set 和 held-out test set：

\[ D_{\mathrm{train}}=\{x_i\}_{i=1}^{N},\qquad D_{\mathrm{test}}=\{x_j\}_{j=1}^{M} \]

蓝图 \(b\) 诱导一个具体 agent \(A_b\)。对输入 \(x\)，运行 agent 得到输出和结构化 execution trace：

\[ (\hat{y},\tau)\leftarrow A_b(x) \]

\(\tau\) 记录 actions、tool calls、observations、errors 和 final output。它相当于 agent 的 observability artifact。

如果任务有 programmatic scorer，例如单元测试、schema validation、format check，则得到硬信号：

\[ g_t(x)\leftarrow s(\hat{y}_t(x),\tau_t(x);R) \]

没有充分 programmatic scorer 时，引入 implementation-blind critic：

\[ (\tilde p_t(x),\ell_t(x),d_t(x))\leftarrow c(R,\tau_t(x),g_t(x)) \]

这个 critic 只看 rubric、trace 和 optional scorer output，不看 blueprint，不做因果归因，不提出修复；它只描述表面 failure symptoms。最终 pass indicator 是：

\[ p_t(x)= \begin{cases} \mathrm{Pass}(g_t(x)), & \text{if } g_t \text{ available}\\ \tilde p_t(x), & \text{otherwise} \end{cases} \]

每个样本形成质量记录：

\[ r_t(x)= (\hat y_t(x),\tau_t(x),g_t(x),\tilde p_t(x),p_t(x),\ell_t(x),d_t(x)) \]

算法流程 / 方法

AgentDevel 主流程：运行当前 agent 并收集 implementation-blind surface signals；用 executable diagnostic scripts 合成单个 RC；通过 P2F/F2P flip-centered gate 决定 discard 或 promote。

1. Single canonical line

AgentDevel 不保留一堆并行 variants。每轮只有当前 promoted blueprint \(b_t\)，只合成一个 release candidate \(b_t^{\mathrm{RC}}\)。如果通过 gate，变成 \(b_{t+1}\)；否则丢弃，继续保留 \(b_t\)。

2. Executable diagnosis

所有 per-example records 聚合为：

\[ \mathcal{R}_t=\{r_t(x)\mid x\in D_{\mathrm{train}}\} \]

AgentDevel 不让模型自由写一段“诊断总结”就结束，而是生成并执行 diagnostic scripts，例如 Python 脚本。脚本会统计 symptom classes、trace patterns、代表性失败样本和 affected surface。执行结果形成诊断报告 \(\mathcal{D}_t\)，像 bug triage report 一样回答：哪里坏了、怎样坏、出现多少次。

3. RC synthesis

基于诊断报告，系统生成一个 release candidate blueprint：

\[ b_t^{\mathrm{RC}}=\Phi(b_t,\mathcal{D}_t) \]

RC 可以修改 prompt、code 或 tool wrappers。它还携带一个 change intent，说明它主要要修复哪些 symptom classes。论文强调：这个 intent 不声称因果解释绝对正确，它只是把 proposed change 和 observed failure appearance 对齐起来。

4. Flip-centered gate

RC 在同一个 TrainSet 上重新评估。核心不是只看平均分，而是看 example-level flips：

\[ \mathrm{P2F}_t= \{x\in D_{\mathrm{train}}\mid p_t(x)=1\wedge p_t^{\mathrm{RC}}(x)=0\} \]

\[ \mathrm{F2P}_t= \{x\in D_{\mathrm{train}}\mid p_t(x)=0\wedge p_t^{\mathrm{RC}}(x)=1\} \]

P2F 是 pass-to-fail，也就是 regression；F2P 是 fail-to-pass，也就是 fix。gate 还计算 flip rates：

\[ \rho_t^{\mathrm{P2F}}= \frac{|\mathrm{P2F}_t|}{|\{x\in D_{\mathrm{train}}:p_t(x)=1\}|+\epsilon},\quad \rho_t^{\mathrm{F2P}}= \frac{|\mathrm{F2P}_t|}{|\{x\in D_{\mathrm{train}}:p_t(x)=0\}|+\epsilon} \]

抽象 gate decision 写作：

\[ \mathrm{Accept}_t = G(\mathcal{R}_t,\mathcal{R}_t^{\mathrm{RC}}, \mathrm{P2F}_t,\mathrm{F2P}_t,\mathcal{I}_t)\in\{0,1\} \]

实际原则很清楚：P2F 是高优先级风险；F2P 是修复证据；修复应该集中在 RC intent 声称的 symptom classes 上；新增失败必须少且可解释。

5. Promote / discard / stop

\[ b_{t+1}\leftarrow b_t^{\mathrm{RC}}\quad \text{if }\mathrm{Accept}_t=1 \]

\[ b_{t+1}\leftarrow b_t\quad \text{if }\mathrm{Accept}_t=0 \]

停止条件不是“还能不能把 TrainSet 分数刷高”，而是看边际 F2P 是否变小、P2F 是否持续上升、RC 是否反复被拒、收益是否集中在越来越小的 subset 上。held-out TestSet 不参与 gating，只在最后评估一次。

实验设计

论文实现中，AgentDevel 使用 Claude Code 作为开发引擎，底层 LLM 固定为 Claude-Sonnet-4.5。Claude Code 负责生成和执行 diagnostic scripts、总结 symptom patterns、提出 blueprint diffs；所有 diagnostic scripts、RC diffs、critic outputs 和 flip lists 都被保存和版本化，用于 auditability。

为了避免 confound，Devel engine 的 model 和 tooling 在所有迭代中保持固定。迭代决策只看 TrainSet signals 和 flip-centered gating；TestSet 只用于最终一次 post-hoc reporting。

Benchmark	任务类型	Primary metric	为什么适合 release engineering
SWE-bench Lite	软件工程 patch	Resolved	天然要求补丁通过 repository tests。
SWE-bench Verified	更严格软件工程 subset	Resolved	能检查同一 blueprint 是否稳定修复真实 repo case。
WebArena	长周期网页交互	Success	失败常体现为 missing step、wrong order、invalid action。
StableToolBench	稳定工具/API composition	SoWR	工具任务有 trace 和可复现评分，适合 flip 统计。

实验结果

主结果：四个 execution-heavy benchmark 都有大幅提升

Benchmark	Base agent	AgentDevel final	Prior reported baseline	解读
SWE-bench Lite	11.00	22.00	SWE-agent 18.00	Resolved rate 翻倍，并超过报告的 SWE-agent baseline。
SWE-bench Verified	15.00	30.00	GPT-4o scaffolded 33.20	更严格 subset 也翻倍，接近 prior scaffolded GPT-4o。
WebArena	17.00	35.50	CER_hybrid 36.70	Success rate 超过两倍，接近 CER_hybrid。
StableToolBench	54.00	73.50	DFS 70.20	SoWR 提升近 20 点，超过 prior DFS baseline。

边界：prior reported baseline numbers 不是在完全相同 setup/budget 下重跑。这里最重要的不是跨系统排行榜，而是同一初始 blueprint \(b_0\) 经 release pipeline 后的稳定提升。

StableToolBench case study：gate 真的在过滤坏 release

Iter	Gate	F2P	P2F	\(\rho^{\mathrm{P2F}}\)	Hit rate	FTP / P2P
1	Acc.	38	4	0.006	0.74	0.12 / 0.98
2	Acc.	30	5	0.007	0.78	0.20 / 0.979
3	Rej.	42	28	0.040	0.41	0.28 / 0.93
4	Acc.	25	3	0.004	0.81	0.32 / 0.978
7	Rej.	9	15	0.021	0.52	0.41 / 0.955
8	Acc.	8	2	0.003	0.88	0.44 / 0.976
10	Acc.	5	2	0.003	0.92	0.47 / 0.974
11	Rej.	2	3	0.004	0.67	0.48 / 0.97

第 3 轮就是最典型的例子：F2P=42 看起来修了很多，但 P2F=28、P2F rate=0.040、hit rate=0.41，因此被拒绝。这正是 Drift Monitor 需要的思想：不能因为有 utility gain 就发布，必须先问它破坏了什么。

WebArena 消融：没有 flip gate 会有更高表面分数和更坏 release

Setting	Final test	Final train pass	Total F2P	Total P2F	P2F rate	Gate reject rate	Bad releases
AgentDevel full	34.2	78.5	214	18	3.1%	42%	0
w/o flip gate	35.0	81.0	230	95	14.8%	N/A	4
w/o executable diagnosis	31.8	74.0	150	22	3.9%	63%	0
critic not blind	32.5	83.5	205	40	6.7%	58%	0

最重要的实验结论： 去掉 flip gate 后，final test 和 final train pass 反而最高，但 P2F rate 从 3.1% 升到 14.8%，bad releases 从 0 变成 4。这直接证明：平均分上升不是安全发布的充分条件。

我的评论

这篇最像我们的 baseline 骨架

AgentDevel 给 Drift Monitor 的作用很明确：它不是 drift probe 本身，而是 release scaffold。一个 monitor 不能只输出“风险分 0.73”，它要在候选更新进入正式版本前参与 gate。

AgentDevel 组件	Drift Monitor 插入点	我们可以新增什么
Execution trace records	记录候选版本在 probe set 上的动作、工具调用、记忆读写、workflow path。	加入 goal/state/tool/workflow provenance。
Implementation-blind critic	只看行为轨迹和 rubric，判断表面 drift symptoms。	定义 action drift、inaction drift、stale memory、unsafe tool reuse 标签。
Executable diagnosis	用脚本统计 drift flips 和触发条件。	从“自由总结”变成可审计 drift report。
Flip-centered gate	把 P2F 扩展成 safety/goal/tool/workflow regressions。	不只看 pass/fail，还看目标、边界和状态是否退化。
Promote / discard	accept / reject / quarantine / rollback / ask human。	把 monitor 输出变成 release decision。

我对 3-6 个月方向的判断

最现实的题目不是重做一个 DGM，也不是从模型参数层面自训练；而是在 AgentDevel-style release pipeline 上加一个 Drift Monitor gate。题目可以非常具体：

Release-Gated Self-Evolution: Detecting Goal and State Drift in Agent Release Candidates.

最小系统：给 agent 一个可变 blueprint，让它产生候选 prompt/tool/workflow update；然后用 probe set 检查普通 task performance、goal drift、inaction drift、tool boundary、workflow reconstruction；最后用 flip-centered gate 决定是否发布。

\[ accept(RC)=utility\_gain\land no\_P2F\_critical\land no\_goal\_drift\land no\_stale\_state \]

论文局限

这篇也有边界。第一，pipeline 成本高：反复执行、trace collection、诊断脚本生成和 gate 都需要额外 compute 与 wall-clock time。第二，implementation-blind critic 仍然是 LLM evaluator，可能有偏差；有 programmatic scorer 时更可靠。第三，实验主要是 single-agent、single-repository 或 single-environment，扩展到 multi-agent 和持续变化环境还需要更多机制。第四，gate threshold 与 stopping criteria 是可配置的，不是通用定理。

One More Thing

我建议把 AgentDevel 视为“外壳”，把 Goal Drift 视为“probe”，把 Misevolve 视为“风险维度”。三者合起来，一个可做的 3-6 个月方案就出现了：

\[ candidate\_update\rightarrow trace\_records\rightarrow symptom\_critic\rightarrow executable\_diagnosis\rightarrow drift\_probe\rightarrow flip\_gate\rightarrow accept/reject/rollback \]

这个方案的论文贡献可以很清楚：不是声称让 agent 自进化更强，而是提出一种 release-gated self-evolution protocol，证明它在保留 utility gain 的同时降低 goal/state/tool/workflow regressions。

下一篇 OEP 会补上一个关键攻击面：局部经验如何被错误泛化成全局规则。把 OEP 放进 AgentDevel 的 gate 里，就能形成一个很自然的 drift probe：RC 不能因为一段局部成功经验而污染 future policy。

Reference / Evidence

arXiv abstract

https://arxiv.org/abs/2601.04620

PDF

https://arxiv.org/pdf/2601.04620

arXiv DOI

https://doi.org/10.48550/arXiv.2601.04620

Reading basis

Based on the public arXiv PDF, arXiv abstract page, and public arXiv source package retrieved on 2026-05-26. This page is a paper2html deep-reading note, not a reproduction report.