代码 Agent 的核心不是写代码，而是把每次改动变成可验证、可停止、可回滚的工程证据
模型只负责提出下一步候选。真正的系统要先冻结任务与仓库版本，从符号、调用、测试和历史建立可追溯证据，在外部强制的权限边界里生成最小 diff，再把退出码、失败测试和回归结果写回状态。只有这条链可复验，SWE-bench 分数、多 Agent 并行和“能做几小时任务”才有可解释含义。
先定义什么算完成，再让模型碰仓库；先区分提案，再谈自治
代码模型输出 token 概率，代码 Agent 输出的却应该是一份经过环境验证的仓库变更。两者中间至少隔着任务、运行时和证据三层合同。漏掉任意一层，“测试绿了”都可能只是改错层、改了考试，或在错误环境里偶然通过。
模型：提出候选
根据当前上下文建议搜索、读取、编辑或执行动作。它可以生成高质量 patch，也可能自信地选错文件、误读日志或重复失败；概率输出不是执行许可。
任务：冻结完成定义
记录预期行为、最小反例、回归约束、允许修改面和禁止项。Issue 只是输入材料，不一定已经包含全部验收规则。
环境：限制真实动作
把读取、写入、命令、网络、凭证和外部副作用分级。容器或 VM、工具代理和审批策略在模型之外执行限制。
证据：说明为何可合并
绑定仓库和镜像 revision、完整 diff、命令、退出码、原始日志、测试范围、审批者与未决风险，让下一位工程师能复验。
UI 去重能让截图变好，API 游标修复才能满足系统合同
模型若只读 User Interface（UI，用户界面）报错文件，可能补一行 new Set(items)；仓库证据若继续追到游标协议、后端 Application Programming Interface（API，应用程序编程接口）调用和回归测试，会发现 cursor 被错误复用。两段代码都能“看起来修好”，只有后者在冻结的验收与调用链证据下成立。
同一模型换掉 Agent–Computer Interface（ACI，智能体—计算机接口）、检索策略、工具语法、预算或镜像，结果就可能改变。报告能力时至少写清 model + scaffold + tools + context policy + budget + environment + harness，不能把系统提升全部归给模型。
FIM 让局部编辑更顺手，Scaffold 才让模型获得连续行动与反馈
普通自回归模型从左到右预测；Fill-in-the-Middle（FIM，填补中间）在训练时把一段中间代码移到样本末尾，让模型同时利用 prefix（光标前文）和 suffix（光标后文）补出 middle。它改善编辑接口，却没有告诉系统该修哪个文件、哪个命令可信或何时应该停止。
代码模式与语义先验
大规模代码和文本训练让模型学会语法、API、测试惯例与常见修复。它提供候选分布，但训练语料也可能含过时 API、漏洞模式和 benchmark 答案。
局部插入与替换
把目标点两侧上下文一起给模型，使局部插入和替换成为可直接训练与调用的任务。FIM 论文中的关键是数据变换，不要求为此另造一种网络架构。
检索补足窗口
RepoCoder 用相似代码检索与生成迭代，把相关文件带入当前补全。仓库级 Agent 还需符号、调用、测试与版本证据，不能只靠向量相似。
把候选接到工具
动作语法、观察格式、状态摘要、错误处理、预算与停止规则组成 scaffold。ACI 设计会直接影响模型能否准确导航、编辑和测试。
动作空间要小而有语义
search / open / edit / run / diff 比任意 GUI 坐标更容易审计。每个动作要有结构化参数、明确错误和幂等边界；执行后只把真实 observation 回给模型。
跨文件修改按依赖推进
CodePlan 把仓库级修改视作沿语法与语义依赖前进的计划：先改定义，再找消费者，再更新测试。一次吐出十个文件的巨型 patch 会让因果归因和回滚都变困难。
简单基线必须先跑
Agentless 在论文期的 SWE-bench Lite 上用“定位 → 修复 → patch validation”三段式流程解决 96 / 300 题（32.00%），报告平均成本约 0.70 美元。这个历史结果不代表今天的前沿水平；它证明的是复杂 orchestration（编排）必须和同预算简单 scaffold 比较。
轨迹不是答案本身
思考文本、计划和摘要都可能失真；真正能提升证据等级的是原文件、diff、命令、退出码、测试和环境状态。系统应允许从摘要重新打开来源，而不是让压缩后的聊天记录变成唯一事实。
上下文窗口不是仓库数据库：每条证据都要知道来自哪个 revision
仓库不是一篇顺序文章。符号定义、调用方、测试、配置、生成文件、依赖锁与历史 commit 有不同权重；一次编辑还会让旧行号、旧调用关系和旧测试结果失效。高质量上下文管理追求“足够、相关、可追溯、新鲜”，不是尽量塞满 token。
任务包先固定 revision 与修改面
保存基线 commit、submodule、依赖锁、工具链和环境变量指纹；写清可改目录、API 兼容、是否允许升级依赖与数据迁移。否则 Agent 可以通过扩大题目范围制造绿灯。
精确搜索先找高置信入口
路径、错误字符串、类名、配置键和 rg 对精确标识符便宜有效。先缩小范围，再打开局部上下文，通常比先把全仓库做成向量索引更可解释。
AST 与 LSP 负责结构关系
Abstract Syntax Tree（AST，抽象语法树）、Language Server Protocol（LSP，语言服务器协议）、import graph 和 call hierarchy 能回答谁定义、谁调用、谁继承。接口改动必须沿消费者继续取证。
向量与历史负责补语义
业务描述和代码命名不一致时，embedding 可找相邻成功模式；git blame、commit 与 Pull Request（PR，合并请求）解释“为什么这样写”。在公开 benchmark 中，历史还可能直接暴露 gold patch，必须与生产检索策略分开。
证据账本记录支持关系与失效条件
不要只存“我读过文件 A”；要存文件、revision、行号、原始片段、观察命令、它支持或反驳哪个假设，以及什么变更会使它过期。摘要只做索引，原始证据才是底账。
Issue + 最小复现 + 目标定义 + 两层调用方 + 相邻成功实现 + 当前 diff
它通常比“仓库前 100k token”更有用。每轮根据新 observation 换入新文件、换出已证伪材料；局部编辑时再补目标代码的 prefix / suffix。若仓库 revision 改变，工作集要重绑定，不沿用看似熟悉的旧行号。
失败只有被正确分类，才会成为下一轮证据
长循环的价值不在步数，而在每轮让不确定性下降。系统要区分产品代码错误、测试合同问题、环境漂移、权限拒绝和结果未知；只有“产品假设被新证据更新”时，继续修改代码才合理。
先知道仓库本来怎样
记录已有失败和已有绿灯。补丁后再出现红灯时，才能判断是新回归、原始缺陷还是镜像 / 依赖漂移。
每次编辑都是可回滚状态
保存前后 commit、完整 diff、修改原因与受影响假设。大重构把太多变量一起改变，会让测试结果失去归因价值。
日志要结构化也要保留原文
命令、退出码、超时、失败用例、stack trace、资源使用与文件变化写入账本；摘要便于模型读取，原始日志便于工程师复验。
停止是一项系统能力
最大步数、Token、墙钟时间、相同错误次数、高风险文件和未知副作用都应预设；到线时交付当前状态，不继续随机试错。
Checkpoint 是“回到哪个仓库、环境与外部状态”的可执行恢复点，不只是聊天摘要。若 Agent 已经发布包、创建工单或写数据库，回滚 Git 并不能撤销外部副作用；这类恢复要进入 Agent 可靠执行中的幂等、对账和补偿协议。
模型“承诺不删库”不是权限控制；能看见工具也不等于有权调用
代码 Agent 同时接触高价值源码、任意命令、网络、凭证和构建产物。最小权限必须由工具代理、容器或 Virtual Machine（VM，虚拟机）、短期凭证、网络出口和审批服务强制；system prompt 只能解释规则，不能承担隔离边界。
读取按数据敏感度分级
任务仓库、构建日志和依赖缓存可以授权；主目录、密钥、用户数据、其他租户仓库与历史凭证默认不可见。搜索结果也要继承原数据的 Access Control List（ACL，访问控制列表）。
写入只进隔离工作树
限制到任务分支、临时副本或显式路径，禁止静默改 Git 历史和测试基准。每批写入生成 checkpoint 与 diff，越过目录边界需重新授权。
命令经工具代理校验
固定镜像、CPU / 内存 / 时间限额、网络 egress、命令与参数策略由执行层强制；测试脚本本身也可能执行不可信代码。
外部动作单独建账
发布、推送、部署、创建云资源、写数据库与发送消息需要调用级授权、幂等键和结果对账。一个模糊“允许终端”不能覆盖全部副作用。
RedCode-Exec 有 4,050 个 Python / Bash 风险执行用例
论文还含 160 个风险代码生成提示，并在三种 Agent framework、19 个 Large Language Model（LLM，大语言模型）上评估。它的重点不是给所有产品一个统一安全分，而是说明“能生成正确程序”和“能拒绝或隔离危险执行”是两套目标；模型越会写代码，也可能写出更有效的危险软件。
README、issue、依赖脚本、测试输出和网页都可能夹带 prompt injection。模型要把它们当低信任数据，工具层还要阻断外传与越权路径；完整威胁建模进入 AI 安全工程。
通过率是一份带版本的执行记录，不是“能完成多少真实软件工作”
SWE-bench 把 GitHub issue 与修复前仓库配对，系统生成 patch，harness 在 Docker 环境应用补丁并运行测试。截至 2026-07-17，官方 FAQ 列出 full 2,294 题、Lite 300 题、Verified 500 题、Multimodal 100 个开发实例，以及 Multilingual 300 题（9 种语言、42 个仓库）。集合名字相近，任务分布和结论不能混用。
题面合同：合理工程师能否从给定信息推出要求
真实 issue 可能依赖维护者口头知识、后续 PR 讨论或未写出的接口约束。隐藏测试若强制某个函数名或题面未提功能，会把功能正确 patch 判错。
测试效度：绿灯是否覆盖需求而不绑定单一实现
FAIL_TO_PASS（补丁前失败、正确修复后应通过）应覆盖根因，PASS_TO_PASS（补丁前后都应通过）应守住回归；过窄测试会放过不完整修复，过严测试会拒绝等价实现。gold patch 不是唯一可能正确答案。
环境合同：仓库是否真的可构建、可复现
Python / Node / OS、系统包、镜像、网络与资源上限都会改变结果。Terminal-Bench 2.1 修正 2.0 的 89 题中的 28 题，其中 9 题受外部依赖变化影响，说明 benchmark 也需要持续运行和维护。
污染合同：模型是否见过 issue、PR、gold patch 或派生轨迹
公开静态集合会进入网页、论文、训练语料和 Agent 日志。按时间采集的新任务、私有 holdout、训练数据审计和 contamination probe（污染探针）能降低风险，却不能自动证明零污染。
预算合同：比较是否同等
报告模型和 scaffold 版本、最大步骤、Token、墙钟时间、测试时间、并行样本数与成本。一次尝试和 64 次采样不是同一能力；最好同时给 pass@1（单次采样通过率）、成本—成功曲线和失败类型。
Verified 经人工筛选仍会残留问题；更难的新集合也不能免审
Verified 最初由 93 名有 Python 经验的软件开发者参与审核 1,699 个随机抽取样本；每题由 3 名不同标注者独立检查，最终筛成 500 题。OpenAI 在 2026-02 审计 o3 经 64 次运行仍不稳定的 138 题（占集合 27.6%），称其中 59.4% 存在实质题面或测试问题，并报告公开数据污染证据；这不是对全部 500 题的随机缺陷率。其后 OpenAI 一度建议转向 SWE-Bench Pro，但在 2026-07 又审计其 731 题公开 split：自动过滤器先标出 286 题供深入检查，人类监督的 investigator-agent 多轮审计经研究者终判认定 200 题（27.4%）有问题，独立人工标注活动则由每题 5 名工程师审核并认定 249 题（34.1%）有问题，因而估计约 30% 任务有问题。数字只属于各自数据与流程，不能外推为“所有代码评测三成都坏”。
SWE-rebench V2
论文发布 32,079 个带预构建镜像的任务，覆盖 20 种语言、3,617 个仓库；另有 120,000+ 带安装说明、FAIL_TO_PASS 与元数据的 PR-derived 训练任务，其合成题面同时以原 PR 描述和对应 patch 为条件。论文另审计 509 个取自 SWE-Bench Pro PR 的样本，判定 117 题（23.0%）存在某种泄漏、12 题（2.4%）存在明确 solution leakage，因此把这批大规模集合定位为置信度更低的训练资源。
SWE-Cycle
489 个严格筛选实例分别测环境重建、代码实现、验证测试生成，并用 FullCycle 从裸仓库串起三阶段。论文观察到完整链路相对孤立阶段明显掉点，提醒预配置镜像会隐藏真实摩擦。
SWE-smith
从 128 个仓库构造 50,000+ 任务实例，主要目标是扩大 SWE Agent 训练数据。这些任务带执行环境，可用于 Agent 训练；论文实际展示的是利用成功轨迹做 rejection-sampling fine-tuning（拒绝采样微调），不代表已经验证强化学习效果，也不适合作为天然无污染的评测真值。
SWE-Lancer
用超过 1,400 个真实 Upwork 任务和约 100 万美元报酬补充单元测试式基准，但任务来自特定平台与仓库情境。经济价值标签更真实，也不能代表所有团队协作、长期维护与安全责任。
“系统 S 在数据 D、harness H、镜像 E、预算 B、scaffold V 下 resolved p%”可以复验；“它能独立完成 p% 的软件工作”跨过了任务分布、私有上下文、需求澄清、长期维护、发布权限和人类协作等没有被测的边界。
先画 Directed Acyclic Graph（DAG，有向无环图），再开工作树；先确定唯一集成者，再谈并行
多 Agent 的可迁移价值不是“角色更多”，而是把真正独立的研究、模块实现与 review 同时推进。若子任务共享同一隐含状态、同时改同一文件，或合并后无人重跑完整回归，并发只会放大重复上下文和冲突。
默认先跑同预算单 Agent 基线
局部 bug、短依赖链和快速测试通常更适合单 Agent：状态集中、首个有效 patch 更快、diff 归属清楚。多 Agent 提升若只来自更多总调用，要把成本一起报告。
每个子任务定义输入、产物与禁止区
researcher 只读并提交“文件 + revision + 行号 + 假设”；implementer 只改指定目录并产出 commit；reviewer 读取原需求、原始证据和 diff，不只看实现者摘要。
隔离工作树，显式分支与合并
CAID（Centralized Asynchronous Isolated Delegation，中心化异步隔离委派）用中央计划、异步执行、隔离 workspace 与 branch-and-merge 管理并发。Git primitive 提供可执行责任边界，聊天里的“你改前端、我改后端”不提供。
合并态必须重新验真
两个 patch 各自通过局部测试，组合后仍可能破坏接口。唯一集成者按依赖顺序合并，在同一 commit 上运行跨模块测试、build、安全与副作用检查，并负责停止、回滚与最终证据包。
从“日期解析在夏令时边界失败”到一份可审查补丁
下面是教学用轨迹，不是某个 benchmark 的真实样本。重点是看状态怎样被 observation 更新，而不是展示 Agent 写了多少行代码。
冻结合同：不存在的本地时间必须被拒绝
验收样例设为 2026-03-08 02:30 America/New_York，并要求保留既有 API 错误结构；禁止更换整个日期库。记录 Node / Python、操作系统和 tzdata（时区数据库）版本。
跑 baseline：先证明失败与环境可复现
固定镜像运行原测试和最小反例，保存命令、退出码与现有绿灯。若最小反例在不同机器表现不同，任务首先是环境重建，不应立刻改业务代码。
建证据图：从解析入口追到边界层
精确搜索错误字符串和时区库，沿调用关系发现 API 层把 naive datetime（无时区日期时间）默认为本地时间；相邻成功路径会先 round-trip，再拒绝不存在或歧义时间。假设绑定到具体 revision 与行号。
最小 patch：只修边界校验
在现有校验函数加入显式时区 round-trip 检查，让错误沿当前协议返回；形成 checkpoint 与 diff，不顺手重构日期模块。FIM 只接收目标函数 prefix、suffix 与相关接口。
红灯分类：Windows 镜像缺 tzdata 不是产品回归
定向测试在一个镜像失败，但 stack trace 指向缺失时区数据。Agent 将其归入 ENV，修复测试 fixture 并重跑 baseline，而不是继续改产品逻辑来迎合坏环境。
分层验证：从反例到仓库回归
依次跑新反例、日期模块、API 回归、lint、typecheck 和 build；再检查 diff 是否只触及允许目录。因为外部错误行为发生变化，触发人工 API 兼容审查。
交付证据包：明确还不知道什么
附仓库与镜像 revision、完整 diff、每条命令与结果、审批记录，以及“未覆盖其他时区数据库版本和非 Windows 平台”的剩余风险。评审者可以复跑，也可以从 checkpoint 回滚。
不是写出 round-trip 检查，而是没有把每个红灯都理解成“代码还没改够”
baseline、环境指纹与失败分类让产品缺陷、测试问题、依赖缺失和权限拒绝分开。真实软件工程里，正确归因往往比生成一行修复更难，也更能决定 Agent 会收敛还是造成破坏。
长任务 benchmark、开发者提速和可安全发布，是三种不同证据
代码 Agent 可以在干净任务里自主运行更久，也可能在熟悉仓库的真实开发者手里增加 review 与返工；反过来，团队主观觉得提速，也不证明缺陷率、维护成本和安全风险下降。选型需要把能力、生产力与发布质量三张表并排看。
50% time horizon 不是自治时长
METR 定义它为：按人类专家完成任务所需时间衡量难度，拟合 Agent 成功率后，在预测成功率 50% 处对应的任务时长。它不是 Agent 实际运行多久，也不是“可自动化同等工时的一切工作”；当前页面还提示 16 小时以上估计不可靠。
早期-2025 随机对照试验是历史快照
METR 的 Randomized Controlled Trial（RCT，随机对照试验）在 16 名熟悉自己开源仓库的开发者、246 个真实任务上报告：允许使用当时 AI 工具后，完成时间慢 19%（置信区间约 +2% 到 +39%）。该页面现在明确标记结果过时，不能当 2026 工具的当前结论。
后续实验也遇到选择偏差
METR 2026 更新涉及 57 名开发者、143 个仓库和 800+ 任务，但称拒绝无 AI 工作、任务选择与并行 Agent 计时造成严重偏差，无法给出可靠统一提速值。测量方法本身要随工作方式变化。
生产指标看合并后的长期结果
同时看需求完成率、首个有效 patch 时间、人工 review 分钟、返工、逃逸缺陷、回滚率、安全事件、云与模型成本，以及四周后仍可维护性；不能只看生成代码量或本地测试通过。
离线：建私有、时间切分、逐题审计的任务集
覆盖本组织语言、仓库形态、权限与发布流程；保留简单脚本、人类和单 Agent 基线。每题先验证题面、环境、测试与可接受解空间，再比较模型。
影子模式：允许读和提 patch，不允许合并
测有效 patch 率、证据完整性、人工审查时间、危险命令与越权企图。让安全策略和日志先经历真实仓库分布，不把首批用户当红队。
分级授权：从只读到低风险写入
先开放文档、测试和低风险模块；依赖、迁移、身份、支付、部署与生产配置保留人工审批。权限升级按调用和资源发生，不按整段会话一次授权。
发布门：只接受合并态证据
在目标 commit 上重跑规定回归，检查 diff 范围、第三方依赖、安全扫描和外部副作用；证据缺失、结果未知或回滚路径不可用就不发布。
任务是谁的？基线是谁？用什么 scaffold、预算和环境？谁审了 diff？质量看多久？
把 headline 改写成可审计句子：在什么日期、哪些开发者与仓库、怎样分配任务、允许哪些工具、总成本多少、以什么质量门判完成、置信区间与失败分布怎样。若只能回答“榜单更高”或“主观觉得更快”，证据还不足以支持组织级自动合并权限。
代码 Agent 可以压缩搜索、样板、局部实现与验证成本；责任没有被压缩。需求所有者仍决定什么算对，平台团队保证权限与恢复，评审者承担合并判断，组织对上线结果负责。最可靠的系统不是永不失败，而是失败时知道自己处于什么状态、停止在哪、把什么证据交给谁。
一手来源与证据边界
优先使用论文、官方文档、官方模型卡和代码仓库。页面中的数字只代表来源所述设置，不自动外推到其他模型与数据。
FIM 把训练样本重排为 prefix、suffix、middle，在论文实验中增加中间补全能力且未显著损害普通从左到右生成。
以相似代码检索和迭代生成说明仓库级证据如何补足单文件上下文；论文结果只对应 RepoEval 设置。
Agent–Computer Interface（ACI）如何影响仓库导航、编辑与测试；论文分数按历史模型和当时 scaffold 处理。
把跨文件修改建模为沿语法与语义依赖推进的计划，而不是一次生成全部补丁。
定位、修复与补丁验证的简单流水线及其 SWE-bench Lite 论文结果，支持“更复杂编排不自动更强”。
代码、终端、浏览器、事件流、沙箱与多 Agent 协调组成通用软件开发 Agent 平台。
本地或云端 runtime 的统一执行接口；用于区分“执行后端”与真正由 OS / VM / 容器实现的隔离边界。
真实 GitHub issue、修复前仓库、FAIL_TO_PASS 与 PASS_TO_PASS 测试构成原始 SWE-bench 合同。
截至核验日的五个官方集合规模，以及 Docker 环境、应用 patch、运行测试的基本评测流程。
镜像构建、补丁应用、测试规格、日志与结果产物的可复现执行边界。
93 名有 Python 经验的软件开发者审核 1,699 个随机抽取样本，每题由 3 名不同标注者独立检查，最终筛成 500 题 Verified。
对 138 个高频失败题的审计、59.4% 子集问题率与公开基准污染证据；比例不外推到全部 500 题。
SWE-Bench Pro 731 题公开 split 的数据点审计、约 30% 问题估计，以及过严、欠说明、覆盖不足和误导题面的分类。
持续从较新 GitHub 历史采集可执行任务，用时间新鲜度降低静态公开集合污染。
32,079 个可复现任务、20 种语言、3,617 个仓库，以及额外 120,000+ PR-derived 训练任务的题面条件与泄漏审计边界。
489 个实例分别评环境重建、代码实现、验证测试生成与 FullCycle，揭示预配置环境会隐藏的跨阶段摩擦。
2.0 的 89 题中修正 28 题，并引入持续验证；其中 9 题受外部依赖变化影响。
从 128 个仓库构造 50,000+ 任务实例的训练数据路线；规模不等于每题都适合作为评测真值。
超过 1,400 个 Upwork 软件任务与约 100 万美元报酬口径，补充单元测试式 benchmark 之外的经济任务证据。
50% / 80% time horizon 的统计定义、任务分布、低上下文人类基线与 16 小时以上估计不可靠的当前说明。
16 名熟悉自己仓库的开发者、246 个任务与 19% 变慢的历史随机对照结果；发布页现已明确标记过时。
后续 57 名开发者、143 个仓库和 800+ 任务中的选择偏差、并行 Agent 计时难题，以及当前无法给出可靠统一提速值的说明。
4,050 个 Python / Bash 风险执行用例、160 个有害生成提示、三种 Agent framework 与 19 个 LLM 的安全评测。
CAID 的中心化委派、异步执行、隔离工作区与测试式集成，以及 MiniMax 2.5 在 PaperBench / Commit0-Lite 的论文设置结果。