arXiv 每日速递 2026-04-30

今日总结

今天 cs.SE 集中放出 4 篇高度相关的论文，主线不是"LLM 又能写多复杂的代码"，而是 LLM-as-coder 已经够用之后，工程化的边际收益怎么挖：[24] 把 coding agent 的 harness 当成可演化对象，10 轮自动迭代把 Terminal-Bench 2 从 69.7% 推到 77.0%（超过人工设计的 Codex-CLI 71.9%）；[49] 把 instruction-driven code editing 拆成 Planner/Editor/Verifier 三 agent，跨 5 种语言把 EditBench TSR 从单 agent 60% 拉到 68.6%；[15] 在 SWE-Bench-Verified/Pro/Multilingual 的 800 个 GitHub issue 上跑多 LLM pipeline，91.7% 成功率提取出 734 条 root-cause→solution→implementation 三段式 trajectory；[7] 则在另一个轴上压缩——CTT 把代码任务模型在保留 ~98% clone-detection 准确率的前提下减少 49× 内存、81% CO2。今天 4 篇论文，恰好对应 agent 工程化的四个层次：harness（[24]）、架构解构（[49]）、训练数据（[15]）、部署压缩（[7]）。 对在做"agent 边际价值量化"和"小模型 for code"的我们来说，这是少有的"四篇全相关"日。

今日全览

论文	方向	核心贡献	与我们的相关度
Agentic Harness Engineering	coding agent harness	用 observability 把 harness 编辑变成可证伪契约，10 轮自演化把 Terminal-Bench 2 推到 77.0%，跨模型族 +5.1~10.1pp 迁移	⭐⭐⭐
SAFEdit	code editing agent	Planner/Editor/Verifier 多 agent + Failure Abstraction Layer，EditBench TSR 68.6% (+8.6pp over ReAct)，迭代 refinement 单独贡献 17.4pp	⭐⭐⭐
SWE-MIMIC-Bench	issue trajectory dataset	5-LLM pipeline 从 GitHub 讨论中提取 root cause / solution plan / implementation 三段式 trajectory，91.7% 成功率 / 734 条	⭐⭐⭐
Carbon-Taxed Transformers	green compression for SE LLMs	多架构压缩流水线，clone detection 上 49× 内存、81% CO2 削减、98% 准确率保留；generation 上 pass@1 仅保 68%	⭐⭐

今日主题：LLM 已经会写代码，剩下的全是工程

过去两年 LLM × SE 的论文几乎都在回答同一个问题：**给定 LLM，怎么让它的"原始能力"在某个 task 上发挥得更好。**今天这 4 篇论文却在向后退一步：

• [24] AHE 说：如果模型不动，只动 harness（agent 与环境的接口层），就能在 Terminal-Bench 2 上拿到 +7.3pp，超过 OpenAI 自家 Codex-CLI。也就是说，过去我们以为属于"模型能力"的提升，其中一大块其实属于 harness 设计。
• [49] SAFEdit 说：如果你不能换模型，只动 agent 架构（Planner/Editor/Verifier 解构 + 结构化 failure feedback），能再拿 +8.6pp，还能减少 instruction-level hallucination。
• [15] SWE-MIMIC 说：如果你想让 agent 真的"像人", 得先有人类专家发病现场的高保真数据——它把 GitHub issue 里散乱的 root cause / solution / implementation 三股线索拆出来，喂给 agent 训练。
• [7] CTT 说：哪怕你拿到了最强模型 + 最好 harness + 最干净的数据，部署到工业环境时还得砍掉 49× 内存和 81% 排放，否则就是 demo。

这四篇把 "AI for SE 的工程价值链" 拆得很完整：Harness → Agent 架构 → 训练数据 → 部署压缩。这与我们的 marginal value 主线完全契合——LLM 已经 work 之后，每个工程动作的真实贡献到底是多少。这种实证拆解，比再造一个 SWE-bench SOTA 有用得多。

值得警惕的反面是：[7] 的 generation 任务 pass@1 只能保 68%，[24] 的 AHE 评估完全依赖 Terminal-Bench 2 的 task 集，[49] 的 EditBench 多语言子集本身可能不平衡。"工程化收益"本身也需要被 marginal value 框架审视。

---

Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses

推荐理由：与"agent 单个设计动作的边际价值"主线高度同构。它把 harness 工程从 trial-and-error 变成"自带 prediction-vs-outcome 验证的封闭循环"，直接给 marginal value 实证一种新的 study 形式：每次编辑都有 falsifiable contract。

📌 论文信息：Jiahang Lin, Shichun Liu, Chengjun Pan, Lizhi Lin, Shihan Dou | arXiv:2604.25850 | cs.CL, cs.SE

TL;DR

把 coding agent 的 harness（命令模板、tool 描述、错误处理代码、prompt 片段……）当成可显式编辑的"组件文件"，给每次编辑配一份"预测—验证"契约，让一个外层 agent 在 10 轮内自动把 Terminal-Bench 2 从 69.7% 演化到 77.0%。重点不在分数，而在它把"harness 工程"从经验技艺变成了可观测、可证伪的 search 过程。

问题是什么？

任何认真做过 SWE-bench / OpenHands 的人都知道一件事：**最终分数有相当大的比例不是来自模型，而是来自 harness。**怎么截断长 stack trace、tool description 的 wording、bash 输出怎么 chunk、retry 策略、错误格式化模板，每一个都能轻松搬动几个百分点。但问题是：

1. action space 异构：你能改的东西从 prompt template 到 retry 代码，从 schema 到 tool 描述，没有统一表示。
2. 评估信号噪声大：单 task 通过率本身有方差，单次编辑的"是否提升"很难判定。
3. trajectory 极长：harness 改一次要重跑数百万 token 的 trace，无法人肉对照。
4. 归因困难：跨多 task 跑下来，"这次编辑导致 +0.5pp 还是噪声"无法区分。

结果是：实践上，harness 进化基本靠 "trial-and-error + 直觉"，迁移性极差，新模型来了基本要从头调。

他们怎么做的？

核心 Insight：把"harness 编辑—验证—决策"这个闭环里每一环都加上 file-level 可观测载体，再让外层 agent 在每次编辑前写下自己的预测，下一轮训练完后再核对预测是否成立——这样 harness 进化不再是黑箱试错，而是可证伪的科学实验。

具体方法分三个 observability pillar：

1. Component observability：把 harness 拆成可编辑文件（每个 tool 描述、每段 prompt、每条 retry 逻辑），让 action space 显式且可回滚。
2. Experience observability：把上一轮跑出的几百万 token trajectory 蒸馏成"分层、可下钻"的证据语料，让外层 agent 真正能消化历史。
3. Decision observability：每次编辑都附一份"我预测下一轮会发生 X"的声明，下一轮跑完用 task 级 outcome 验证。

跟之前方法的本质区别：ACE / TF-GRPO 那一类自演化方法把 harness 当成黑箱参数；AHE 把它当成可显式枚举、可解释、可证伪的代码工件。这是从"参数搜索"换到了"工程实验"的范式。

关键结果

Benchmark	指标	AHE	Codex-CLI (人工)	差异
Terminal-Bench 2	pass@1	77.0%	71.9%	+5.1pp
Terminal-Bench 2	pass@1 (seed)	69.7%	—	起点
SWE-bench-verified	aggregate success	顶	seed 持平	-12% token
Terminal-Bench 2 跨模型族	pass@1 增益	—	—	+5.1~10.1pp

结果解读：

• 7.3pp（69.7→77.0）的提升完全来自 harness，模型一行代码没动。这给"AI4SE 论文中模型贡献占比有多大"提供了一个新的实证下界。
• SWE-bench-verified 上"-12% token"特别有价值——说明 AHE 不是靠堆 retry/重采样换分数，而是真在做有效率的工程优化。
• 跨模型族 +5.1~10.1pp 是这篇最强的论据：harness 学到的不是"对某个模型的过拟合调参"，而是通用工程经验。这意味着 harness engineering 是个有"知识资产"价值的方向，而非一次性炼丹。

局限性与开放问题

• 局限 1：Terminal-Bench 2 的 task 集不大（论文未给出 task 数总览），77.0% 的提升里有多少来自对该 benchmark 的隐式过拟合，AHE 自己的预测—验证机制无法消除——因为预测本身就是基于这个 benchmark 的 outcome。
• 局限 2：10 轮迭代，每轮都跑 SWE-bench-verified / Terminal-Bench 2 全集，这个外环的算力开销在论文里被略过了。"自动 harness 工程比人工更便宜"这个隐含假设需要验证。
• 开放问题：Decision observability 里的"自声明 prediction"是 LLM 写的；如果它系统性地 over-claim 或 under-claim，整个 falsifiability 机制就退化为 "事后合理化"。论文里没有充分校准这一点。

💡 对我们的启发

1. 直接可用的技术点：在我们公开 SWE-bench / OpenHands trace 大规模事后分析的 pipeline 中，可以借用 AHE 的 component file-level 抽象——把每条 trace 用到的 harness 配置（tool 描述版本、retry 策略 hash、prompt 模板 hash）作为元数据存下来，这样后续做 "test execution 边际价值 1.25pp" 这种分析时，可以控制 harness 维度，剥离掉 harness 差异带来的混淆。
2. 具体实验想法：在我们已有的 OpenHands / Aider / SWE-agent 的 trace 集合上，跑一个只换 harness、不换模型的反事实实验。固定 GPT-4o-mini，把 OpenHands 的 harness 拆成 57 个组件（tool 描述、错误格式化、retry 阈值、状态摘要长度、bash chunk 大小……），逐个替换成另一框架的等价组件，看 SWE-bench-verified 上每个组件的边际贡献。预期：和 AHE 论点一致，单个 harness 组件的边际值在 13pp，但总和远大于 7pp（说明组合非加性，符合我们 atomicity 系列工作的口味）。1~2 周内可做完。
3. 研究趋势判断：harness engineering 正从 "无名英雄" 走向"显式研究对象"。下一个值得做的论文是 "harness marginal value 的分布是怎样的"——参考我们之前对 test execution 1.25pp 的处理方式，做一个针对 harness 组件的 atomicity benchmark。这正好与我们已有的 SE evaluation methodology 工作打通。

---

SAFEdit: Does Multi-Agent Decomposition Resolve the Reliability Challenges of Instructed Code Editing?

推荐理由：和我们 program repair 的"职责切分哲学"完全同构——static analysis 做定位 / LLM 只负责修复。SAFEdit 把这套思路推到 code editing：Planner 做计划 / Editor 做最小改动 / Verifier 跑真实测试。论文里 "Failure Abstraction Layer" 的设计也直接呼应我们对 static signal 的偏爱。

📌 论文信息：Noam Tarshish, Nofar Selouk, Daniel Hodisan, Bar Ezra Gafniel, Yuval Elovici | arXiv:2604.25737 | cs.SE, cs.AI

TL;DR

把 instruction-driven code editing 拆成三个独立 agent：Planner 写出 visibility-aware 编辑计划、Editor 只做最小字面修改、Verifier 跑真实 test。失败时由 Failure Abstraction Layer (FAL) 把 raw test log 转成结构化诊断 feedback，Editor 据此迭代。EditBench 上 5 种语言、445 个 case，TSR 68.6%，比单 model baseline +3.8pp，比 ReAct 单 agent +8.6pp，迭代 refinement 这一项就贡献了 17.4pp。

问题是什么？

EditBench 上 40 个被评估的 LLM 里，39 个 TSR 不到 60%。问题不在生成代码——这些模型在 HumanEval / LiveCodeBench 上都很强。问题在 instructed editing 这个任务本身有一对天然矛盾：

• 模型理解指令需要"放飞"：揣摩用户意图、补全 context、改名字让代码更"统一"。
• 但 editing 要求"克制"：只动该动的那几行，别动 import、别改 docstring、别重构。

放飞和克制是同一个 prompt 控制不住的两件事。结果就是测试通过率很低，且很多失败不是"逻辑错"，而是"动了不该动的"。这个观察和我们做 compatibility migration 时遇到的痛点几乎一模一样。

他们怎么做的？

核心 Insight：把"理解"和"动手"在 agent 层面物理隔离——Planner 只负责想清楚改哪几处、为什么改；Editor 接到 plan 之后只允许做字面级最小改动，连改函数名都不行；Verifier 跑测试。失败时不是把 raw stack trace 倒回去（信息密度太高，模型不会用），而是用 FAL 翻译成"哪个 assertion 在哪一行 fail，期望值 vs 实际值"。

具体流程：

1. Planner Agent：读 instruction + code + test，产出一份显式的 edit plan，标注每处 visibility（公开 API / 内部实现）。这一步把"编辑边界"从隐含约束变成显式契约。
2. Editor Agent：只看 plan，不看 instruction。接收"在 line 42 把 + 改成 -"这种 atomic 指令，禁止 refactor。
3. Verifier Agent：跑实际 test。失败 → 进入 FAL。
4. Failure Abstraction Layer：raw log → 结构化（fail 的 test ID、location、expected/actual）→ 喂回 Editor 做下一轮。

跟之前方法的本质区别：ReAct 把 think/act/observe 都放在同一个 agent 的同一个 prompt 里循环；SAFEdit 把 think 和 act 物理分开，act 阶段只有最弱版本的语境（只看 plan），从机制上就剪掉了"过度修改"这个失败模式。这是结构上的隔离，不是 prompt 上的劝告。

关键结果

配置	EditBench TSR	相对基线
单 model baseline	64.8%	—
ReAct 单 agent	60.0%	-4.8pp
SAFEdit	68.6%	+3.8 / +8.6pp
SAFEdit w/o iterative refinement	51.2%	-17.4pp

跨语言（英语 / 波兰语 / 西班牙语 / 中文 / 俄语）445 case，统一 spatial context variant。

结果解读：

• 17.4pp 来自 iterative refinement 这一发现非常重要——意味着单次输出的 LLM 性能其实远没饱和，关键在于有没有结构化的 feedback 让它"再试一次"。这和我们对 test execution as repair signal 的研究是同一类发现。
• ReAct 比单 model baseline 更差 4.8pp 是个有趣的反直觉点。说明朴素地把 reasoning + acting 缝在一起反而引入了不稳定性，多 agent 的胜利不是"agent 多就好"，而是"职责清晰"。
• 5 种语言的稳定性（论文称"varying spatial context variants"）说明这个收益不是英语 prompt 优化带来的，更像是结构红利。

局限性与开放问题

• 局限 1：EditBench 本身仍然是 "task description + test" 形式的合成 benchmark，与真实 PR 的"模糊意图 + 不完整 test"差距不小。SAFEdit 在 visibility 维度的 plan 标注会不会在真实 GitHub PR 上崩，论文没回答。
• 局限 2：FAL 把 test log 结构化的具体规则没披露。如果 FAL 本身用 LLM 做的解析（很可能），那它就成了一个隐藏的 Verifier，整个三 agent 实际上是 3.5 agent，且"Editor 只做最小改动"的约束部分依赖 FAL 的解析质量。
• 局限 3：iterative refinement 贡献 17.4pp，但论文没说迭代轮数上限，也没给出每轮的边际收益曲线——这正是"agent 边际价值量化"应该回答的问题。

💡 对我们的启发

1. 直接可用的技术点：在我们做 Python 版本演化兼容性修复时，可以直接套用 Planner/Editor 解构。Planner = static analysis 给出"哪些 API 需要替换、哪些 import 需要改"的精确计划（这个我们已经做得很好）；Editor = LLM 只接 plan，不接 traceback；Verifier = 我们既有的 pytest 跑测试。这个映射几乎一一对应，只需要把 plan 表示形式从我们当前的 dict 改成 SAFEdit 那种"line-level visibility-annotated plan"。预期：能把目前 LLM "改飞"导致的 false positive 直接砍掉一半。
2. 具体实验想法：在 PyMigrationBench / Cangjie compat 数据集上做一个 "plan 颗粒度 ablation"：分别给 LLM 喂①完整 instruction、②文件级 plan、③line-level plan、④token-level diff suggestion。看每多加一层"约束"对 TSR 和"unrelated change rate"（无关改动占比）的影响。预期：line-level plan 是甜点，token-level 反而会因为 plan 本身错误率高而拉低 TSR。这个实验 1 周可跑完，直接构成一篇"compat repair 的 plan colocation 边际值"短文。
3. 研究趋势判断：multi-agent decomposition 在 SE 任务上的胜利不是 agent 数量的胜利，而是 prompt 内职责切分的胜利——和我们 program repair 的职责切分哲学完全同构。下一个值得探索的是："职责切分到什么颗粒度边际收益反转"？SAFEdit 三个 agent 已经接近上限，但 4 个 / 5 个会不会因为 communication overhead 反而变差？这是个非常具体且 publishable 的小问题。

---

From Threads to Trajectories: A Multi-LLM Pipeline for Community Knowledge Extraction from GitHub Issue Discussions

推荐理由：这是一份针对我们最熟悉的 SWE-Bench-Pro / Multilingual / Verified 的"上游数据集"——它从 issue 讨论里把 root cause / solution plan / implementation 拆出来，正是 agent trace 分析需要的"专家行为高保真数据"。如果做得好，能直接喂给我们 small model for code 的 fine-tuning。

📌 论文信息：Nazia Shehnaz Joynab, Soneya Binta Hossain | arXiv:2604.25880 | cs.SE

TL;DR

用 5 个不同的闭源 LLM 配合做不同子任务（label 分类 / inline code summary / external link summary / comment analysis / trajectory synthesis），从 SWE-Bench-Verified/Pro/Multilingual 的 800 个 issue 里提取 734 条结构化 trajectory（root cause → solution plan → implementation progress），成功率 91.7%。这不是 summarization 论文，是一个 "把 GitHub 讨论变成 agent 训练数据"的数据工程论文。

问题是什么？

如果你想训练一个 agent "像 senior 开发者那样思考"，你需要 senior 开发者真实诊断、设计、实施的 trace。这种 trace 哪里有？GitHub issue 里有——但格式极脏：

• 一个 issue 几十条 comment，掺杂吐槽、跑题、转发外链。
• root cause 经常被埋在第 17 楼某段 stack trace 下面。
• solution plan 可能跨几条 comment 才出现（"先这样、再那样、然后……"）。
• implementation 引用的代码块可能是外部 PR / gist / Stack Overflow。

直接把整个 thread 丢给 LLM 做 summarization，会得到平庸的"事件时间线"，但训练 agent 需要的是"专家诊断流"——这两者结构完全不同。

他们怎么做的？

核心 Insight：不要让一个 LLM 干所有活。把"提取诊断流"这个复合任务拆成 5 个 atomic 子任务，每个子任务可以用最便宜也最稳的 LLM 配置去做，最后再合成。这是 LLM-pipeline 工程的范式，对应到他们的实现：

1. Label classification LLM：对 comment 打标签（root cause discussion / proposed solution / impl progress / off-topic / external ref）。
2. Inline code summarization LLM：把 comment 里贴的代码片段总结成一句话。
3. External link summarization LLM：解析 issue 里贴的外部 PR、gist、SO、文档链接，提炼相关内容。
4. Comment analysis LLM：综合上下文给每条 comment 提取语义角色字段（root cause / solution plan / implementation progress）。
5. Trajectory synthesis LLM：拼出 label-aware narrative trajectory。

跟之前方法的本质区别：传统 issue 数据集（SWE-bench 系列）只保留"final commit + test"，把讨论过程全扔了。SWE-MIMIC-Bench 第一次把"讨论过程的语义结构"作为产物，不是为人读的，是为 agent 训练读的。

关键结果

来源 benchmark	issue 总数	成功提取 trajectory	成功率
SWE-Bench-Verified	~部分	—	—
SWE-Bench-Pro	~部分	—	—
SWE-Bench-Multilingual	~部分	—	—
总计	800	734	91.7%

论文未在摘要中给出 per-benchmark 成功率拆分，需要看正文表 1。

结果解读：

• 91.7% 成功率说明这个 pipeline 的鲁棒性比 end-to-end 单 LLM 高得多——单 LLM 直接生成 trajectory 通常 hallucinate 严重、格式漂移。多 LLM 拆解的稳定性优势是论文最有价值的工程贡献。
• 但论文摘要里没有任何"trajectory 质量"的人工评估或者下游 task 实证（例如：用这 734 条 trajectory fine-tune 一个 7B 模型，在 SWE-bench 上提升多少 pp），这是它最大的隐忧——可能只是"看起来漂亮的合成数据"。

局限性与开放问题

• 局限 1：5 个闭源 LLM 配合的成本和复现性都不可控。社区想用这个 pipeline 自建数据集，5 个 API key 摆在那儿，trajectory 质量怎么校准？
• 局限 2：下游验证缺失。摘要里没有"用这个数据集训出来的 agent 在 SWE-bench-verified 上比基线提升 X pp" 这种 endpoint。这种数据集论文不带 downstream 验证，本质上就是一个 demo。
• 局限 3：91.7% 是不是"格式上成功"而非"语义上正确"？没有第二组评估者一致性数据，无法判断这是 syntactic 91.7% 还是 semantic 91.7%。

💡 对我们的启发

1. 直接可用的技术点：我们想做的 "OpenHands / Aider trace 的事后大规模分析"，可以直接用 SWE-MIMIC-Bench 的 5-LLM pipeline 模板——只需要把输入从 GitHub issue 换成 agent trace、把 label 集换成（thinking / tool call / observation / re-plan / give-up），就能拿到结构化 trace。这比我们之前用单一大模型解析 trace 节省 token 50%+，且更稳定。
2. 具体实验想法：用这套 pipeline 在我们已经收集的 SWE-bench OpenHands trace 上做一个**"专家 vs agent 行为差异"实证**——同一个 issue，SWE-MIMIC 给出的 human trajectory vs OpenHands 跑出的 agent trajectory，逐字段对比 root cause / solution plan / implementation。预期能直接量化"agent 在哪一步偏离专家最严重"——大概率是 root cause localization 阶段，这又能直接接到我们 fault localization 职责切分的工作上。1~2 周可做。
3. 研究趋势判断：social-trace-driven dataset construction 会成为 agent 训练数据的下一个主流来源，远远比合成 task 更有价值。但评估这种数据集的标准还不存在——论文里"91.7% 成功率"基本是凭直觉报的。这正是我们 benchmark methodology 主线最适合切入的角度：写一篇 "trajectory dataset 评估三段论"——syntactic fidelity / semantic fidelity / downstream utility。

---

Carbon-Taxed Transformers: A Green Compression Pipeline for Overgrown Language Models

推荐理由：和我们"小模型 / local LLM for code 是否能替代商业 API"主线高度相关。CTT 给出的不是新算法，而是一个**多架构（encoder-only / encoder-decoder / decoder-only）**的统一压缩流水线，并且在 3 类典型 SE 任务上做了量化报表——正是我们做"工业可部署性"决策时缺的那种数据。

📌 论文信息：Ajmain Inqiad Alam, Palash Roy, Chanchal K. Roy, Banani Roy, Kevin A. Schneider | arXiv:2604.25903 | cs.SE, cs.LG

TL;DR

把"碳定价"这个经济学比喻当作压缩流水线的排序原则——给每个压缩动作（量化 / 剪枝 / 蒸馏 / 低秩分解）一个"碳税"，按惩罚低、收益高的顺序串成 pipeline，跑在 clone detection / summarization / code generation 三类任务、三种架构上。报表很硬：clone detection 上 49× 内存、8~10× 速度、81% CO2 削减、保 98% 准确率；但 generation 上 pass@1 只能保 68%。

问题是什么？

LLM × SE 论文的 "我们用 GPT-5.4 + 14 个 agent 把 SWE-bench 推到 92%" 现状下，部署侧的现实是：

• 这种方案在线上几乎跑不动——延迟 30s+、成本 / req 数美元。
• 个体开发者 / 小团队没有 GPU，更没有商业 API 月预算。
• Carbon footprint 在欧盟和北美一些机构已经成为 IRB / sustainability committee 的硬约束。

但压缩研究本身又非常分散——量化是一篇、剪枝是一篇、蒸馏是一篇——没人系统地说"对一个 SE 任务，这些压缩动作应该怎么 sequence"。

他们怎么做的？

核心 Insight：把压缩 pipeline 的设计当成"碳税最小化下的优先级排序"问题——每个压缩 op 有一个"penalty"（精度损失）和"reward"（资源减免），按 reward/penalty 排序后流水线串起来，跨架构通用。

具体动作：

1. 给每个压缩 op 计算 carbon-cost score（kWh, CO2, latency 三维加权）。
2. 按 score 从大到小排序，依次叠加。
3. 每加一步做一次 holdout 评估，到 accuracy 落到阈值以下就停。
4. 在 encoder-only（CodeBERT 类）/ encoder-decoder（CodeT5 类）/ decoder-only（StarCoder 类）三种架构上分别跑，得到三套 sequence。

跟之前方法的本质区别：以往 SE 压缩论文要么针对一类架构（"我们压 CodeBERT"），要么针对单一压缩动作（"我们对 StarCoder 做量化"）。CTT 给出的是架构与任务交叉表——这种 systematic empirical map 才是工业界真正用得上的。

关键结果

任务	内存削减	速度提升	CO2 削减	准确率保留
Code clone detection	up to 49×	8~10×	up to 81%	~98%
Code summarization	—	up to 3×	—	~89%
Code generation	—	4~7×	—	91% (textual) / 68% (pass@1)

"—" 表示论文摘要未明确给出该单元格数字。

结果解读：

• Clone detection 49× / 81% / 98% 的三联组合非常诱人——意味着 clone detection 这种判别式任务根本不需要"完整版"模型，工业界完全可以用压缩模型替代。
• Generation 的 pass@1 跌到 68% 是诚实的负面结果——说明压缩对生成任务的容忍度远低于判别任务。这与社区对 distillation 在 code generation 上效果不佳的体感一致。
• Ablation 显示 pipeline ordering 有显著影响，证明"碳税排序"不是噱头，是真有信号。

局限性与开放问题

• 局限 1：碳税 reward/penalty 的权重选择没有充分 ablation——论文里这是个固定比值，但实际部署中不同公司的 cost function 不同（例如电力成本 vs 延迟成本）。
• 局限 2：摘要里没说与 mainstream 压缩 baseline（如 GPTQ / SmoothQuant + LoRA distillation 朴素串联）的对比。"碳税排序" vs "经验排序"的真实增量不清楚。
• 局限 3：68% pass@1 retention 在 code generation 上意味着还不能直接替代原模型，但论文标题听起来像是"我们解决了 SE LLM 部署问题"。读者要小心这种语气差。

💡 对我们的启发

1. 直接可用的技术点：在我们 ArkTS / Cangjie 工具链里，已经有"用 7B 模型做 lint 修复"和"用 14B 模型做 patch 生成"两条线。CTT 的 clone detection 表给出一个明确信号——判别式任务（lint 类、style 检测、cross-version compat 检测）应该激进压缩；生成式任务（patch 生成、补全）保持原模型。这直接指导我们工具链里的模型选型策略。
2. 具体实验想法：在我们自己的"小模型 vs 商业 API"对比研究里，加入一个**"压缩等量比较"实验**——把 DeepSeek-Coder 7B 用 CTT 流水线压到 1B 等效内存，看 compat repair 任务上 pass@1 落多少。预期：判别子任务（API existence check）落 < 2pp；生成子任务（patch synthesis）落 510pp。然后报告"在哪些子任务上压缩 7B = 不压缩 1B"——这是工业界真正缺的指南。1 周内可做。
3. 研究趋势判断：SE 任务的"压缩—精度"权衡正在被精细化，但目前研究都是 task-level 报表。下一个 publishable 角度是 subtask-level / failure-mode-level——例如，code generation 的"语法正确率"和"语义正确率"在压缩下落得不一样快；compat repair 的"API 存在性检查"和"参数顺序修复"对压缩的敏感度也不同。这正是把我们 atomicity 系列工作的方法论搬到 efficiency 维度的好机会。

---

方法对比

维度	AHE [24]	SAFEdit [49]	SWE-MIMIC [15]	CTT [7]
核心抽象	harness as evolvable code	agent role decomposition	issue thread → trajectory	compression as carbon-tax pipeline
改的是什么	模型外的 wiring	agent 架构	训练数据	模型本身
评估 benchmark	Terminal-Bench 2 / SWE-bench-verified	EditBench (5 lang)	SWE-Bench-V/P/M	code clone / summary / gen
模型贡献 vs 工程贡献	工程 +7.3pp（模型不动）	工程 +8.6pp（同模型解构）	数据→未跑 downstream	工程 -32pp（gen pass@1 损失）
主要风险	对 benchmark 过拟合	EditBench 与真实 PR 差距	缺 downstream 验证	gen 任务下落严重
与我们主线的接点	agent 边际价值方法论	program repair 职责切分	trace 数据集构建	small model for code 部署

四篇组合起来恰好覆盖 harness → 架构 → 数据 → 部署 全链条。如果只能挑两篇精读，选 [24] AHE（方法论同构）和 [49] SAFEdit（直接可迁移到 compat repair）。