← 课程地图

第 01 章 · 概念骨架

一个 PR 的旅程

从一段真实的代码改动，到 Agent 解题与评估——整个课程最核心的骨架，一条线讲完。每个环节都能点进讲义深挖。

① 题从哪来 PR · 真实代码改动

→

② 题长什么样 SWE-bench 题目

→

③ 谁来解 Agent · harness+LLM

→

④ 怎么解 LLM 协议 · 工具调用

→

⑤ 解得怎样 结果 + 过程 双维度

按 → 开始 · 一次只看一件事 · 节点可点击直达

赶时间？直接进实战篇 · 真实 PR 全程 →

第 1 站 · 题从哪来

一个 PR 是什么

1

一次「请把我的代码改动合并进去」的提议 开发者不直接写主干，而是请维护者审查后再合并——开源协作的最小单元

2

代码进入主干前的一道审查关卡 review 通过、CI 变绿才 merge——代码质量由流程保证，不靠自觉

3

里面装着 commits + diff + 讨论与审批 后来造题要用的三个「宝贝」——题面、答案、测试——全都藏在 PR 里

4

不会自动合并——review 通过、CI 变绿才 merge 这保证了每道「真题」背后都有人类维护者把关

每一个 PR，都自带 4 个「题目元素」——下一屏见

深挖 PR 详解 ↗ Git 与 GitHub ↗

第 1 站 · 题从哪来

PR 里藏着一套完整考题

ISSUE BODY 题面 用户报告的问题原文——Agent 将读到的一切背景信息

PR DIFF 答案 开发者写下的修复——评分时的标准对照

TEST 改动 评测 判对错的测试——通过与否由它说了算

BASE COMMIT 起点 从哪个仓库状态开始改——环境快照，hash 锁死

题面、答案、评测、起点——正好是一道题的 4 个字段

深挖 PR 全解 ↗ 从 PR 造题 ↗

第 1 站 · 题从哪来

为什么用 PR 造题

1

题面真实——issue 是真用户写的 真实场景、真实报错、真实表达——不是出题人坐在办公室编的

2

答案独立——报 bug 的人 ≠ 写修复的人 避免了「自问自答」：题面不知道答案长什么样

3

评测独立——测试是 PR 自带的，不是事后编的 测试先于题目存在，且经过维护者 review，难以被「应试」

4

不可篡改——commit hash 锁死了事实 任何人、任何时候都能检出同一快照，复现同一道题

这样的题才够格当 Agent 的「真题」——看它长什么样

深挖 从 PR 造题 ↗

第 2 站 · 题长什么样

一道题的 4 个字段

字段	角色	来自 PR 的哪里
problem_statement	题面	issue 正文——Agent 读到的问题原文
patch	答案	PR 的代码 diff——评分时的标准对照
test_patch	评测	PR 的测试 diff——判分合约
base_commit	起点	PR 的合并基点——仓库快照

其中 test_patch 定义了两组测试——判分的全部秘密

深挖 数据 Schema ↗ SWE-bench 入门 ↗

第 2 站 · 题长什么样

F2P 与 P2P

1

F2P：修好前挂、修好后必须过——证明「修对了」 如实战篇 sympy 题新增的 test_immutable：修复前必然失败，修复后必须通过

2

P2P：本来就要过、修完不能挂——证明「没改坏」 全部原有测试防回归——改了 A 处弄坏 B 处，照样判负

3

两组全过，这道题才记 FULL %Resolved = FULL 题数 ÷ 总题数——整个基准的计分方式

合约有了——谁来解题？下一站认识 Agent

深挖 评测与判分 ↗

第 3 站 · 谁来解

Agent = 大脑 + 身体

1

LLM 是大脑——思考、决策下一步 读什么文件、改哪一行、先跑哪个测试——每一步都是它在判断

2

harness 是身体——跑工具、记历史、驱动循环 Claude Code、DeepSeek Harness 都是 harness——模型之外的整个工程系统

3

Agent ≠ LLM——光有大脑，不会动手 模型不会自己读文件、跑命令；这些能力由 harness 的工具层提供

大脑和身体怎么配合？一个循环讲清

深挖 Agent 循环详解 ↗

第 3 站 · 谁来解

解题循环：看 → 想 → 做

1

observe 观察——读文件、看报错 收集证据：代码结构、错误栈、测试输出

2

think 思考——LLM 决定下一步 定位问题、提出假设、规划行动——推理发生在这一步

3

act 行动——改代码、跑测试 验证假设：改完立刻测，测试结果回流成下一轮的观察

4

循环往复，直到问题解决 测试全绿 → 结束；步数/预算用尽 → 强制停止

循环的每一步，底层都在和 LLM「说话」——下一站拆开看

深挖 Agent 循环详解 ↗

第 4 站 · 怎么解

LLM 对话的核心字段

字段	含义	为什么重要
model	用哪个模型	决定能力上限与调用成本
messages	全部对话历史	「记忆」都在这——最关键的一个
choices	模型回给你的话	含文本回复与工具调用请求
finish_reason	它为什么停下	stop = 说完了；tool_calls = 等你执行工具

其余字段都是加料——4 个里 messages 最关键

深挖 协议五件事 ↗ API Schema 速查 ↗

第 4 站 · 怎么解

messages 的 3 种角色

SYSTEM 设定 你是谁、守什么规则、有哪些工具可用——一次设定，全程生效

USER 指令 任务与上下文——SWE-bench 的题面就装在这一条里

ASSISTANT 回复 文本 + tool_calls——模型解题的每一步都记在这里

会说话还不够——Agent 真正动手，靠工具调用

深挖 消息结构详解 ↗

第 4 站 · 怎么解

工具调用 3 步

1

你声明 tools——告诉模型「能做什么」 名称 + 功能描述 + 参数 schema——像一份菜单

2

模型回 tool_calls——它决定「要做这个」 点菜：给出函数名与实参，等待执行

3

你执行、结果塞回对话——它接着想 结果以 tool 角色消息回传，进入下一轮思考

一道题往往嵌着几十次工具调用——历史怎么延续？

深挖 工具调用实战 ↗

第 4 站 · 怎么解

多轮对话的真相

1

服务端不保存对话——每次都像初次见面 API 是无状态的：没有对话 ID，没有服务端记忆

2

每轮把整个 messages 重发一遍——记忆全靠客户端 第 40 轮的请求里包含前 39 轮的全部内容

3

历史越长 token 越贵——「模型失忆」多半是截断没做好 上下文窗口有限，塞不下就得裁剪——裁错地方就丢关键信息

会说话、会动手——解完题，怎么判它做得好不好？

深挖 对话协议指南 ↗

第 5 站 · 解得怎样

%Resolved：做对了没有

1

FULL = F2P 全过 ∧ P2P 全过 单题通过标准：修对新测试，且不弄坏任何旧测试

2

%Resolved = FULL 题数 ÷ 总题数 比如 300 题做出 87 题 → 29%——一个数字概括整个基准的成绩

3

单题 100% 只代表这一道做对 泛化能力要靠大量互不相同的题来检验

但做对了，就等于做得好吗？

深挖 评测与判分 ↗

第 5 站 · 解得怎样

做对了 ≠ 做得好

1

结果维度只回答「对不对」 测试绿了就是绿了——一个布尔值

2

同样做对——可能直给，也可能绕十条弯路蒙对 结果维度完全无法区分这两种过程

3

过程维度回答「怎么做出的」——弯路、浪费都要抓 步数、token、重复度、无效动作——可量化、可比较、可改进

过程，就藏在 Agent 解题的轨迹里

深挖 轨迹怎么读 ↗

第 5 站 · 解得怎样

过程，藏在轨迹里

1

一条轨迹 = 一串「读 → 想 → 改 → 测」的循环 Agent 解题的完整时间线——append-only，只增不改

2

看节奏——循环是否高效推进 每步的工具选择、步与步之间的推进逻辑

3

抓弯路——重复、无效、绕路都是浪费 可分类、可计数、可折算成 token 成本

至此闭环：题从哪来 → 长什么样 → 谁来解 → 怎么解 → 解得怎样 · 按 ← 回看

深挖 轨迹怎么读 ↗

进入实战篇 · 一个真实 PR 的三段旅程 →