ARTICLE · 1115975
第六讲:编程与软件开发智能体(中)
第六讲:编程与软件开发智能体(中)
这是我精读卡耐基梅隆大学（CMU）公开课「AI Agents（11-768）」系列的第六篇中集。在往下读之前，先快速回顾前五讲和第六讲的上集 —— 每一讲我都写了中文精讲，建议连起来看： 第一讲：AI Agents 概述和工作原理—— Agent = 一个跑在循环里的模型（a model in a loop）。 第二讲：语言模型智能体的工具调用——工具，是让模型从「只会说」跨到「能做」的接口。 第三讲：智能体的长上下文建模—— 单个任务内历史越堆越长，系统怎么既用得动、又供得起。 第四讲：智能体的记忆与技能—— 别让 Agent 每次从零开始，把有价值的经验沉淀成可复用的外部产物。 第五讲：智能体的规划与任务分解 —— 规划是一份「打算怎么做」的显式表示，带来模块化、反馈、长时程与控制。 第六讲：编程与软件开发智能体（上）—— 讨论了编程智能体的第一块地基 —— 会写代码的模型（三步训练、分词、Infilling）与代码评估。 先用一句话，把整个第六讲的世界观接起来： 上集解决了第一样「会写代码的模型」。中集就把它放进真正的智能体循环里 —— 让它自己定位问题、编辑代码、跑测试验证；并讲清楚让这个循环跑通的关键：工具集、diff 格式，以及支撑训练的 SWE-bench 评测环境。
智能体化编程和单步的最大区别：是迭代式的工具调用。 最常见的设定是修 bug 或加功能（在 GitHub / 代码仓库里），典型分三步： 
Localize（定位）→ Edit（编辑）→ Verify（验证），然后放进一个循环里：验证失败就回去迭代，直到全过。 以一个真实例子贯穿 —— 「retries 在值为 0 时没有正确默认」： 
定位：用 rg（ripgrep）找到 config.get("retries") or 3 这行，跑测试复现出「0 被错误地当成了默认值 3」 —— 因为 0 在 Python 里是 falsy，or 会把它当空。 
编辑：把 or 3 改成 3 if value is None else value —— 只在真正为 None 时才默认，显式的 0 就能保住。 
验证：跑全部测试，确认修好了、也没引入回归（regression）。失败就用失败信息指导下一步。 
有个不走智能体循环的替代方案 —— Agentless（作者 Steven Xia，CMU 新任助理教授）：不让智能体自己调工具定位，而是拆成固定步骤（先预测要改的文件 → 类/函数 → 具体行，再用单步模型生成补丁）。 Neubig 说这个方法曾一度好用得让人沮丧—— 当时很多模型这套流程比用智能体还强，因为模型被大量训练成擅长单步代码解决，而不擅长智能体式的工具调用和验证循环。不过现在大家基本都用智能体了。 编程工具集：从「只给一个 shell」说起 
怎么把智能体用到这上面？ 一个答案是只给智能体一个工具：跑 bash 命令。 mini-SWE-agent就是只用 bash 命令解决问题的智能体：用 rg/grep/cat/find 定位、用 sed/Python/patch 编辑、用 pytest/build 命令验证。理论上这就够实现一个编程智能体了。 但为什么这样不理想？ 
问题在于：如果只给 bash，智能体每次编辑文件都要纠结用 sed 还是 Python 还是 patch；而且 sed 遇到有一堆反斜杠的内容，就得反复数反斜杠数量，很容易出错。所以几乎所有有竞争力的编程智能体都会至少加一个「文件编辑工具」。 
文件编辑工具通常有两种：写整个文件（简单但要重复未改的代码）或搜索/替换（紧凑，但需要无歧义匹配）。 还有diff / patch格式。 
一种是标准 unified diff（带行位置+上下文） —— 但你让智能体报行号，它总会搞错、导致 patch 应用失败。 所以更典型的是长得像 diff、但不含行号的格式（Codex 的 *** Begin Patch 语法就是），大量编程智能体在用。 
格式差异能决定成败：在 Aider 的重构 benchmark 上，同一个 GPT-4 Turbo，用 SEARCH/REPLACE 只有 20%，用简化版 unified diff 高达 61%—— 因为它训练数据里见过更多这种格式。 找到相关代码（定位） 
定位从搜索症状开始（rg 是最流行的工具），然后跟着值走。 也有更复杂的方法： 
LocAgent给智能体一个能顺着依赖路径跳转的工具（找到 config.py 后能自动跳到相关文件）。但 Neubig 的经验是：这类复杂方法很难做得比简单方法更好（后面有实证）。 评测与训练：SWE-bench 家族 
评估编程智能体最流行的 benchmark 是 SWE-bench。 它的构造方式：从 GitHub issue（问题）出发，取 issue 解决时的代码库状态（即 PR 之前），再找和这个 issue 一起引入的测试。 
因为在 Django、NumPy 这类大仓库上跑整个测试套件极贵（一个样本可能 5–10 分钟甚至更多），SWE-bench 挑了必须通过的一小撮测试子集来判定 issue 是否解决。（注意这里的 harness 指测试 harness，和智能体 harness 不是一回事。） 
好消息：评估是现在做更好智能体的最大问题之一—— 因为只要能大量生成评测环境，就能在上面做 RL 训练智能体。 一个可运行任务需要：起始状态（文件+依赖+测试命令）、issue（请求行为）、checks（测试）。 
Neubig 团队早期的 SWE-Gym给 SWE-bench 额外造了训练环境（SWE-bench 本身只有评估环境），证明一个原本只有 ~11% 准确率的模型，用哪怕 500 个样本也能明显变强。 这里的 RL 难点是信用分配：终端奖励只告诉你「修好没」，一个晚期失败无法定位是早期哪个决定错了。 
还展示了推理时扩展：生成大量输出再用学到的验证器重排，能做得更好。 Neubig 提到规模最大的努力是SWE-rebench—— 不断从新的 PR（2024 年 12 月到 2026 年 6 月）造更多 SWE-bench 环境，有训练集和开发集，是目前最大规模、公开可用的编程智能体数据之一。 更轻量的造数据方式：注入 bug 
SWE-bench 式数据的问题是每个训练样本都需要一个真实 PR。 SWE-smith换了个思路 —— 不靠 PR，而靠人工注入 bug：准备可执行基线 → 变异代码但保留测试 → 保留那些让测试失败的变异。 这灵感来自软件工程里的 mutation testing（变异测试）：如果你不确定测试套件好不好，就故意给代码做小改动（应该破坏功能），看测试抓不抓得到 —— 抓不到说明测试不够好。 
具体地：把 if value is None 变异成 if not value，零就又被当默认了，某个测试挂掉 —— 这就自动造出一个「请修复我」的样本。 好处是：极其轻量、能生成近乎无限的数据； 坏处是：这些不一定是你真正想解决的自然样本。 
这套框架能扩展到多种语言（Multi-SWE-bench、SWE-bench Multilingual），唯一的麻烦是不同语言的约定不同（用哪个 build/test 命令） —— 但现在的编程智能体处理这个很轻松。 
前面说过，编辑格式不匹配会让模型在没训过的 harness 上变差。 所以现在语言模型厂商普遍在多个 harness 上训练（OpenHands、OpenCode、Codex 等）。例如 Nemotron（Nvidia）故意在 5 个以上 harness 上训，做出对多种 harness 都友好的模型。
如果你也想认真啃一啃「Agent 到底怎么造出来、又怎么越用越聪明」，这门课的全部材料都免费公开： 朋友们，我们下一讲再见！
本文首发于 Haowen.AI 微信公众号。如果这篇分享对你有启发，欢迎点赞、收藏、转发给同样在学习路上的朋友。
要造一个好的编程智能体，你需要三样东西：一个会写代码的模型、一套定位/编辑/验证的工具与循环、以及一批可运行的评测环境来训练和检验它。三者缺一不可。
三、智能体化编程（Agentic coding）
Fail → Pass：PR 前失败、PR 后通过的测试（测的是这次真正实现的功能）。 Pass → Pass：PR 前后都要通过的相关测试（确保没有回归、没弄坏别的）。
中集小结 & 下集预告
中集我们讲清楚了编程智能体的第二块地基：定位/编辑/验证的循环与它的训练场：
- 定位—编辑—验证循环：这是智能体化编程区别于单步生成的本质 —— 迭代式工具调用；也有不走智能体循环的固定工作流（Agentless）作为对照。
- 工具集与 diff 格式：从「只给一个 shell」到必配的文件编辑工具；diff 格式能决定成败（同一个模型 20% vs 61%），编辑格式不匹配是让智能体失灵的巨大瓶颈。
- SWE-bench 家族：从 GitHub issue 造评测（Fail→Pass / Pass→Pass），到 SWE-Gym 造训练环境、SWE-smith 靠注入 bug 造近乎无限的数据、多语言与多 harness 训练。
有了「会写代码的模型」和「定位/编辑/验证的循环」，下集就把视野放宽 —— 看看这套能力在前端开发、更广义的软件开发（开发者 85% 时间不在写代码）里怎么延伸，以及一个更前沿的方向：让模型预测代码的行为。
课程主页：https://cmu-agents.com本讲视频：https://www.youtube.com/watch?v=1BWeH1oOM7k&list=PLSN0qpDfUvTM