S03 Harness for Coding 全景
S03 Harness for Coding 全景
当你在选型会上把 Cursor、Claude Code、TRAE、Copilot 摆在一起，第一反应往往是”比模型”——谁家底层是 Claude Opus、谁家是 GPT-5.5、谁家 SWE-bench 分数更高。这一节要解决的问题是：为什么”比模型”几乎注定选错。 同一个 Claude Opus 4.8 装进不同的工具，开发体验、可靠性、可控性天差地别——差异不来自模型权重，来自包裹模型的那层工程：控制循环、工具集、沙盒、验证、可观测性。这层工程，业界叫它 harness。本节用 S03 Harness Engineering 全景（0411 专题）已建立的”harness ≠ 模型”通用框架，把镜头对准 coding 这个最成熟、竞争最白热的垂直场景，给出一个可以贴在选型会墙上的解剖图。
判断主轴一句话:harness 而非模型，是 coding 工具的真实差异源。 谁能调到同一梯队的 frontier 模型，几乎人人都能（Aider、TRAE 国际版都能挂 Claude）；真正分水岭在于 harness 的五个子系统谁做得扎实。
§0 为什么是”harness 五件套”框架，而不是”feature list”
读者脑中的默认框架通常是产品官网的 feature 清单：Tab 补全、多文件编辑、Agent 模式、MCP 支持……这个框架的致命缺陷是把不同抽象层的东西平铺在一起——“Tab 补全”是交互形态，“沙盒隔离”是安全基础设施，二者根本不在一个层级，并列比较等于比较苹果和水管。
0411 的 S03 Harness Engineering 全景 已经把通用 harness 拆成六维度（控制流、工具层、上下文、记忆、验证、可观测）。本节做的不是复述，而是针对 coding 场景做一次”维度重切”：coding harness 有它自己的承重墙——代码不是文本，它有 AST、有类型系统、有可执行的测试、有不可逆的文件写入和 git push。所以本节把 coding harness 收敛为五件套：
- 控制循环（Control Loop）——agent 怎么决定”下一步读哪个文件、跑哪个测试、改哪一行”。
- 工具集（Tools）——读/写/执行/检索代码的原语，以及编辑如何”落地”。
- 沙盒（Sandbox）——在哪执行、爆炸半径多大、
rm -rf能不能真把你的盘删了。 - 验证（Verification）——改完怎么知道没改坏，测试/类型/lint 怎么闭环。
- 可观测性（Observability）——出了问题能不能 replay、能不能回滚、人在环里看得见什么。
[!note] 框架级辨析 为什么不用 0411 的六维度原样套？因为通用 harness 的”记忆”维度在 coding 里被代码库本身部分吸收了——repo 就是外部记忆，AST/repo-map 就是记忆的索引结构；而通用 harness 不太强调的”沙盒”和”编辑落地”在 coding 里是承重墙（一次错误的文件写入是不可逆的）。这就是”同一抽象框架在不同垂直场景重新承重”的具体例子，详见 Harness 词义辨析。
§1 控制循环:从”补全”到”agentic loop”的代际跃迁
coding harness 的控制循环有一条清晰的演化轴：单次补全 → 编辑建议 → ReAct 式 agentic loop → 多 agent 并行。
| 控制形态 | 代表 | 循环结构 | PM 含义 |
|---|---|---|---|
| 行内补全 | Copilot 早期、Cursor Tab | 无循环，单次预测 1–3 行 | 延迟敏感（Cursor Tab 宣称 <100ms，来源：deployhq.com，2026） |
| 编辑建议 | Copilot NES（Next Edit Suggestions） | 预测下一处编辑位置 | 仍是”人主导、AI 提示” |
| Agentic loop | Claude Code、Cursor Agent、Aider | 读→改→跑测试→读错误→再改，自循环 | AI 主导、人审批 |
| 多 agent 并行 | Claude Code Subagent、Cursor 3 Subagent、Copilot Fleet Mode | 主 agent 分派子任务并行 | 编排成本上升 |
agentic loop 的本质就是 c10 - Agent 技术栈与工具调用 里讲的 Agent 循环（思考→行动→观察），coding 场景把”行动”具体化为 Function Calling 调用文件/终端工具，把”观察”具体化为测试输出和编译错误。这一节对 c10 的升级是：c10 把 agent loop 当作 G3 截面的通用快照，本节展示 coding 场景下这个 loop 如何被”测试可执行性”这一特性重新塑形——代码 agent 之所以能自循环纠错，是因为测试给了它一个廉价、客观、可自动判定的奖励信号，这是写作 agent、客服 agent 都不具备的奢侈品。
判断主轴的第一个落点在这里:很多人以为”Agent 模式”是一个开关，开了就更强。错。 agentic loop 的可靠性取决于循环里每一步的工具质量和验证信号——loop 本身不创造能力，它只是放大器。放大一个没有沙盒、没有验证闭环的工具栈，结果是放大灾难（见 §3、§4）。
§2 工具集:编辑如何”落地”才是真正的护城河
agent 想清楚”把第 42 行的 “ 改成 =”只是第一步，怎么把这个意图可靠地写进文件才是 coding harness 最被低估的工程难题。这里有一张关键的对照表（来源：Morph Edit Formats 指南、DEV Community 基准测试，2025–2026；准确率为各家私有评测，⚠️ 缺第三方独立复现）：
| 编辑格式 | 准确率（口径：Morph 自评，volatile） | 典型失效 | 代表工具 |
|---|---|---|---|
| Unified diff（行号 patch） | 80–85% | LLM 对行号极敏感，偏移即失败 | 早期 SWE-agent |
| 整文件重写 | 60–75% | token 爆炸 + “中段遗忘”导致内容静默消失 | 部分新文件场景 |
| Search/Replace block（精确字符串匹配） | 84–96% | 字符串变化即失配 | OpenHands、SWE-agent、Codex CLI、Claude Code |
| Semantic / Fast Apply（专用模型） | ~98% | 需专门模型基础设施 | Cursor、Morph、Relace |
行业收敛点：精确字符串 search/replace（str_replace_editor）已成为多数主流 agent 的共同选择——比行号 diff 鲁棒，比整文件重写省 token。这是一个反直觉的 PM 洞察：最强的编辑机制不是”最聪明的”，而是”最不依赖模型聪明”的。
更深一层是 Fast Apply 专用模型这条岔路。Cursor 在 2024-08 公开的 Speculative Edits（来源：Fireworks × Cursor 工程博文）把”开发者提供的原文件”当作 speculation，服务端找最长匹配前缀、温度=0 确定性验证，达到约 1,000 tok/s，比 vanilla Llama-3-70B 快 13×。Morph Fast Apply（2025）用 7B 专用模型 + 定制 CUDA kernel 做到 10,500 tok/s、声称 98% 准确率（来源：Morph 产品页，⚠️ 自评，volatile，无第三方验证），已被 JetBrains、Vercel 采用。
[!note] 一手洞察 · Claude Code 与 Cursor 的工具哲学分歧（E02/E03 带回） Rick 作为 Claude Code 深度用户应该有体感：Claude Code 没有 Fast Apply 专用模型这条路，它用 frontier 模型直接产 search/replace block，慢但透明——每一处改动你都能在终端看到精确的 old/new。Cursor 走相反方向：用 7B 小模型在后台把”意图”瞬间 apply 成代码，快但你看不到中间过程。这是 CLI 工具与 IDE 工具在工具集设计上的哲学分歧：Claude Code 赌”可审计 > 速度”，Cursor 赌”心流 > 透明”。对求职字节 字节 TRAE 团队人物图谱 方向的人，这是个值得带进面试的判断：TRAE 国内版作为 VS Code fork，工具落地路线更接近 Cursor 派系，但其差异化筹码在合规与中文场景而非 apply 速度。
工具集还有一个常被忽略的维度:检索原语。是给 agent embedding 向量检索（Embedding + RAG），还是给它 grep + 文件系统导航？arXiv 2603.20432（2026-03）一个反直觉发现是：coding agent 把长上下文问题转化为文件系统导航问题，给它额外配 RAG 工具并不稳定提升性能，有时反而降低——agent 会减少更有效的 grep 而依赖向量检索，策略退化。这直接挑战了”coding 工具必须有强 RAG”的共识（详见本专题 03 架构剖面的检索相关节点）。
§3 沙盒:爆炸半径决定你敢不敢开 auto mode
沙盒是 coding harness 里最不性感但最致命的子系统。它回答一个问题：当 agent 自主执行 bash 命令时，最坏能坏到什么程度？
权限模式构成一条信任光谱（来源：Claude Code 官方权限模式文档，code.claude.com/docs/en/permission-modes，WebFetch 2026-06-07）:
default(仅读) → acceptEdits(读+改文件) → plan(先出计划) → auto(分类器兜底) → bypassPermissions(无检查·仅限隔离容器)Claude Code 的 bypassPermissions 模式官方明确标注”所有操作无检查，专用于隔离容器/VM”；GitHub Copilot CLI 的 /yolo（/allow-all 别名）授予完整访问后不可切换回（来源：GitHub Docs，WebFetch 2026-06-07）。这暴露了沙盒设计的核心张力:自主度越高，沙盒隔离就越是从”可选”变成”刚需”。
Anthropic Engineering Blog《How we built Claude Code auto mode》（2026-03-25，WebFetch 核实）给了一个让我后背发凉的数字:用户批准了 93% 的权限请求——手动审查已实质沦为橡皮图章。auto mode 用模型分类器替代人工，实测假阳性率 0.4%、假阴性率 17%（测试集：10,000 真实动作 + 52 已知风险行为 + 1,000 合成外泄尝试）。官方默认阻断 curl | bash、生产部署、强制推送 main、删除会话前已存在文件等不可逆动作，但坦白标注此功能为 research preview，“reduces prompts but does not guarantee safety”。
判断主轴第三落点:90% 的人把沙盒当成”安全合规部门的事”，错。 沙盒直接决定产品的自主度上限——没有强沙盒，你永远不敢让 agent 真正自主，于是 agentic loop 退化成”每步弹窗确认”，心流被打断（m207 - Agent 产品化：场景推演与失败模式 里讲的失败模式在这里具体化）。真实反例：2025 年 10 月业内有过无确认模式下 rm -rf 误删的事故报道，正是缺沙盒 + 高自主的组合爆炸。正确做法是把”自主度”和”沙盒强度”绑定升降，而不是独立调节。
§4 验证:测试闭环是 coding harness 独有的奢侈品
这是 coding harness 区别于一切其他垂直 agent 的结构性优势，也是判断主轴最锋利的一刀。
代码有一个客服对话、文案生成永远没有的东西:客观、可自动判定、廉价的验证信号。改完代码，跑测试，pass/fail 一目了然；跑类型检查器，编译错误精确到行；跑 lint，风格问题立刻暴露。Aider 的设计哲学就建立在这上面——自动运行 lint/test，失败自动修复，自动生成描述性 git commit（来源：Aider 官网）。Claude Code 已接入原生 LSP（Function Calling 之外的语义层），语言服务器在每次编辑后自动分析变更、回传 type error/undefined variable 等诊断，agent 同一回合内即可修复（来源：Claude Code Docs · code intelligence/LSP plugins，WebSearch 2026-06-07；具体首发版本号〔待核实〕）。
| 验证层 | 信号 | 谁在用 | 局限 |
|---|---|---|---|
| 测试执行 | fail-to-pass | Aider、SWE-agent、Claude Code | 测试覆盖不足则假通过 |
| 类型检查 / 编译 | 编译错误 | LSP 集成工具 | 动态语言弱 |
| Lint | 风格/静态缺陷 | 多数工具 | 不保证逻辑正确 |
| LSP 诊断 | 跨文件引用、rename | Claude Code（2025-12 起） | 需语言服务器 |
但验证信号本身有个致命陷阱，这正好是对手框架要打的点：SWE-bench 这套评测体系把”测试通过”当作能力的代理指标，而 OpenAI 在 2026-02-23 弃用 SWE-bench Verified 时审计发现，其难题子集中 59.4% 的题目测试用例有实质问题（来源：OpenAI blog，详见规划中的评测专题）。症状：harness 自循环跑通了测试，PM 以为任务完成了。为什么会错：测试本身可能过窄（拒绝功能正确但实现不同的解）或过宽（根本没检测到错误）。正确做法：把”测试通过”理解为必要不充分信号，harness 的验证质量上限受制于代码库测试质量本身。真实反例：SWE-MERA 分析约 31% 的”通过”系因测试覆盖不充分（来源：本专题接地简报，⚠️ 待查原始 arXiv）。
[!note] 对手框架回应 · 接受 + 边界 业界有一种强势反方立场（可追溯到 METR 2025-07 的 RCT，arXiv:2507.09089）:agentic coding 工具让有经验的开发者反而慢了 19%——验证闭环再漂亮，元认知负担（审查 AI 生成代码）可能吃掉收益。接受：这个 RCT 设计严谨（16 名资深开发者、246 任务、成熟项目），它对的部分是”在成熟代码库、资深开发者、复杂任务”这个特定组合下，harness 的验证闭环救不了协调成本。边界：但 METR 自己标注 n=16、仅限成熟项目；对照 JetBrains 2025 调查（n=24,534）近 90% 开发者每周至少省 1 小时。我赌的是——harness 的验证质量越高，METR 那条负曲线越往”绿地项目/初中级开发者”区间收缩，但这条边界目前无共识定论，是个需要持续观测的开放赌注。
§5 可观测性:能 replay 和回滚，人才敢放手
最后一件套常被当成”运维细节”，实则是信任校准的物理基础。RedMonk 2025-12 调研（Kara Holterhoff 撰）里开发者对 agentic IDE 的明确需求中，回滚能力（检查点 + 即时回滚）和细粒度权限 + 清晰审计轨迹双双进入前列——“回滚通常更好：节省 token 并减少幻觉”（Denis Volkhonskiy 引述，来源：RedMonk）。
coding harness 的可观测性有三个抓手：(1) 会话 transcript——每一步 think/act/observe 可回看（Claude Code 的 CLI 输出天然就是 transcript；Claude Code 2026-05-11 的 Agent View 把多后台 session 统一成仪表盘，来源：本专题接地简报）；(2) 检查点 / 回滚——把文件系统状态做快照，错了能退回；(3) 多 agent 看板——Devin Desktop 的 Agent Command Center、Cursor 3 的 Background Agent 管理都在解决”并行 agent 的可见性”问题。
判断主轴第五落点:人们以为可观测性是”出了 bug 再去查日志”。错——它的真正作用是前置的信任校准。 Smashing Magazine（2026-02-11）总结的 agentic UX 模式里，“Action Audit & Undo”创造的是”委托而不恐惧”的心理安全感，目标回滚率 <5%。为什么会错：没有 replay/回滚，开发者要么因恐惧不敢开自主模式（harness 投资浪费），要么盲目信任（auto-accept 悖论：能力越强越倾向跳过审查，永远建不起对系统的理解）。正确做法：可观测性投入应与自主度同步，作为放手的前提条件，而非事后补救。
§6 产品 PM 视角补盲:三个工程视角看不到的坑
- 用户心理模型错位：CLI（Claude Code、Aider）对非终端用户门槛极高；IDE fork（Cursor、TRAE）降低门槛但绑定编辑器习惯；插件（Copilot）零迁移成本但能力受宿主限制。harness 再强，交付形态错了就触达不到用户。
- 商业模式与 harness 耦合：Fast Apply 这类专用模型基础设施是重资产，决定了 Cursor 必须做信用额度/Credit 制（2025-06 从”500 次包月”改为 Credit 制，$20 约折 225 次高级请求，来源：本专题接地简报，⚠️ volatile）；而 Aider 把 harness 完全开源、只让用户付 API token，是另一种 harness 商业模式。harness 的工程选择直接约束定价模型。
- 合规边界：TRAE 2025-07 的遥测争议（Unit 221B 研究、The Register 2025-07-28 报道：关闭遥测后仍每 30 秒回传数据）说明——可观测性这把双刃剑，对厂商是”产品可观测”，对用户可能是”我被观测”。国产工具的本地化/私有化部署正是把这个合规边界当差异化筹码。
§7 跨域呼应:Polanyi 默会知识与”测试可验证性”的认识论边界
Polanyi 默会知识与提示工程的认识论张力 在这里有一个精确的落点。Polanyi 的命题是”我们知道的比我们能说出的多”——大量工程判断是默会的、无法完全编码的。coding harness 的验证闭环（§4）表面上是个反例：测试似乎把”代码对不对”这个判断完全显式化、可自动判定了，仿佛默会知识被消解了。
但这恰恰是认识论陷阱所在:测试只能验证”被显式写成测试的那部分意图”，无法验证”开发者心里那个没写成测试的整体设计意图”。SWE-bench 测试质量审计（§4）暴露的 59.4% 问题率，本质就是 Polanyi 张力的工程显现——人能默会地判断”这个解法虽然过了测试但实现得很丑/会埋下技术债”，而 harness 的自动验证信号对此完全失明。这改变了一个具体的技术判断:harness 验证越强，越要警惕”测试通过=任务完成”的认识论越界，因为可验证的永远只是默会判断的冰山一角。这也是为什么 §5 的人在环可观测性不可被验证闭环替代——它正是默会判断重新进场的接口。
§8 PM 决策启示
- 面试怎么用：被问”怎么评价 Cursor vs Claude Code vs TRAE”，不要比 feature list，比五件套。一句话杀手锏:“三家都能挂同梯队模型，差异在 harness——Claude Code 赌可审计的 search/replace + LSP 验证，Cursor 赌 Fast Apply 心流 + Background Agent，TRAE 赌合规沙盒 + 中文场景；模型只是入场券。”
- 选型怎么用：把五件套做成评分卡，对每个候选工具逐项打分。重点压测沙盒（爆炸半径）和验证（测试闭环质量），这两项决定你敢开多高的自主度。
- 复现怎么用：自己搭最小 coding agent，先把”工具集（str_replace）+ 验证（跑测试自循环）“做扎实，再加沙盒和可观测，最后才考虑 Fast Apply 这类优化——顺序错了等于给没刹车的车装涡轮。
§9 与已有节点的关系
- 对 S03 Harness Engineering 全景（0411）：升格 + 垂直化。0411 建立”harness ≠ 模型”的通用六维框架，本节点不复述其维度定义，而是把镜头收敛到 coding 场景，论证通用六维如何被”代码可执行性 / 文件不可逆性”重新承重为五件套（控制循环/工具/沙盒/验证/可观测）。
- 对 Harness 词义辨析：具体化。词义辨析解决”harness 这个词指什么”，本节点提供 coding 场景的一个完整能指实例。
- 对 c10 - Agent 技术栈与工具调用：深化。c10 把 agent loop 当 G3 通用快照，本节点展示 coding 场景下测试信号如何重塑这个 loop，不复述 c10 的 Function Calling 基础。
- 对 m207 - Agent 产品化：场景推演与失败模式：对话。m207 讲通用 agent 失败模式，本节点把”沙盒缺失""验证假通过""可观测缺位”落地为 coding 场景的三类具体失败。
§10 关联节点
核心（必读）
- S03 Harness Engineering 全景 —— 本节点的通用母框架，升级对照源
- Harness 词义辨析 —— harness 词义的入口辨析
- c10 - Agent 技术栈与工具调用 —— agent loop 与 Function Calling 基础
- Claude Code —— 五件套的一手实例（Rick 自用工具）
- m207 - Agent 产品化：场景推演与失败模式 —— 失败模式的通用框架
延伸（可选）
- m208 - AI 基础设施与中间件选型 —— 沙盒/Fast Apply 属于中间件选型
- Polanyi 默会知识与提示工程的认识论张力 —— §7 跨域呼应
- RAG —— §2 检索原语之争
- Embedding —— 向量检索的底层
- Function Calling —— 工具调用原语
- Agent —— agentic loop 的概念卡
- 字节 TRAE 团队人物图谱 —— TRAE 工具哲学的人物背景
- Anthropic / Claude —— Claude Code 的厂商与模型
- AI PM 知识图谱·总索引 —— 全库入口
修订日志
- R1（2026-06-07）：首稿。建立 coding harness 五件套框架（控制循环/工具/沙盒/验证/可观测），完成判断主轴四件套（症状→为什么错→正确做法→真实反例）于 §1/§3/§4/§5，接入 METR 对手框架（接受+边界），落地 Polanyi 跨域呼应于 §7，带入 Claude Code vs Cursor 工具哲学一手洞察。待 WebSearch 复核 volatile 数字。