Topic 2 · GitHub Copilot Harness 工作流：少即是多，用单一工具覆盖软件开发的全流程

2026 年 7 月 27 日，GitHub 的 Burke Holland 写了一篇在开发者社区刷屏的博客，标题就一句话：「The harness is all you need (mostly)」。在他看来，AI 圈层现在最大的噪音不是模型不够强，而是工具太多——开发者被淹没在新 MCP、新 skill、新 workflow、新 prompt 的海洋里，反而忘了怎么用好那个手头的 harness。

他把 GitHub Copilot 本身称为「agent harness」，并给出了用这个 harness 走完软件开发全流程的 8 步工作流。

一、为什么是「少即是多」

Holland 的核心论据很直接：

> 「每一天都有人发新工具、新 MCP、新模型、新 skill、新 workflow、新功能、新社交媒体帖子『看！我用一个怪 prompt 就完全搞定了 AI』。我不信。我每天跟 AI 打交道，真正让我提效的不是装了什么、配置了什么、骗 Agent 做什么，那些都是噱头。最大的提升来自我怎么用 harness，以及我对它理解多深。」

他抨击了 skill registry 上的「slop」：让 Agent 生成一个 skill，它很乐意；不管这个 skill 真不真用，都能被发布到任何 registry 上。

关键观察：GitHub 自己在生产环境里跑的「harness」是一个被高度工程化的运行时——它把模型、上下文管理、工具调用、缓存、sub-agent 编排、跨平台一致性这些事统一封装在一个壳里。开发者不需要重新发明这些基础设施，只需要学会怎么把它用对。

二、8 步工作流

第 1 步：Pick a tool, any tool

GitHub Copilot 生态里所有工具底层使用相同的 harness：

GitHub Copilot CLI（纯文本交互，最接近 harness）
GitHub Copilot App（新版应用）
VS Code / Visual Studio / JetBrains

建议初学者从 CLI 开始，没有 UI 学习成本。Holland 说「学会一次，到处使用」。

第 2 步：Turn on YOLO mode（开 YOLO 模式）

通过 /allow-all 命令一次性授予所有命令执行权限。

Holland 的论据很反常识：智能体需要自主权才能提效，否则人工逐条审批会让人「训练自己不再阅读要审批的内容」，审批的意义就消失了。

但他强调安全底线：YOLO 模式不要在本地机器上跑——必须用 GitHub Codespaces 或开发容器作为沙箱。

第 3 步：Start with a prototype（从原型开始）

> 「给我 20 个日期选择器 web 组件的 mock，全部放一个 HTML 文件里让我比较。」

不仅适用于视觉任务，也适用于非视觉任务（API 设计可以用 Mermaid 图渲染 5 种实现方案）。关键技巧：同一任务保持同一模型和同一推理等级，享受 prompt caching。

第 4 步：Plan methodically（系统性规划）

切换到 /plan 模式（不开新会话）。通过规划暴露边缘情况：日期选择器要考虑的——起止日期能否相同？部分选择是否合法？是否允许清除？「今天」是否始终可见？是否允许手动输入？日期存储格式？是否允许粘贴？

可以叠加 Matt Pocock 的 grill-me skill 让规划更激进：

/plan /grill-me Build a date picker web component...

第 5 步：Implement with Autopilot（用 Autopilot 实现）

GitHub Copilot 会主动提示切到 Autopilot。Autopilot 是一个内置循环，强制模型真正完成它承诺要做的事。

GitHub Copilot 自动充当 orchestrator：

读代码库 → 使用 Explore 子智能体（小模型，便宜）
复杂任务 → 使用 General Purpose 子智能体（大模型，能力强）

开箱即用，无需自定义即可享受多模型子智能体工作流的优势——这是 harness 帮你做掉的事。

第 6 步：Human review and iteration（人工审查与迭代）

Holland 说这是「获得多巴胺」的地方，也是人的品味（taste）决定最终产品质量的环节。他用自己的 Postrboard CSS 框架作为 skill 注入设计指引。

关键原则：不要满足于「差不多就行」的 AI 输出，坚持质量。

第 7 步：Rubber duck the result（橡皮鸭审查）

请求一个不同 AI 家族的模型进行交叉审查——比如 GPT-5.6 Terra → Claude Sonnet。不同模型有不同的盲点。

可以与 Autopilot 组合形成自动改进循环：

/autopilot rubber duck this date picker implementation. When you have the result, review it carefully and make any necessary adjustments. Repeat the rubber duck review until both you and the reviewing model agree that the only items that remain have diminishing returns.

第 8 步：Profit（提交）

暂存并提交，或在同一个 PR 中继续开发下一个功能。

关键技巧：当主题开始偏离时，开启新的聊天会话——chat sessions 是主题性的，混在一起会让上下文失控。

三、Holland 顺便解决的事

文章里 Holland 顺手处理了几个开发者在 harness 使用上常踩的坑：

Prompt caching：输入 token 占大多数开销，cache 节省约 90%。但切换模型、改推理档位、开关工具都会悄悄破缓存。他在另一段视频里专门演示了「Cash Cache Miss」（缓存断点）是怎么发生的——结论是「Vast majority of your token spend is input tokens」。
Mermaid diagrams 支持：用于可视化原型和架构草图，比文字描述更直接
Skills 机制：grill-me（Matt Pocock）、Postrboard（Holland 自家）这些 skill 演示了 harness 的扩展点
MCP servers：作为工具扩展的标准接口

四、为什么这篇文章值得单独看

7 月 27 日这周，AI 圈层的两件事同时发生：

1. Anthropic 的 Schema Harness 论文用受控实验把 Harness 钉成 2026 H2 AI Agent 主导抽象层（Claude Opus 4.8 + Fable 5 在 ARC-AGI-3 上从 42.83% 提到 98.98%） 2. GitHub 在生产层面给出 Harness 工作流——不是论文，是 Burke Holland 这种每天用 harness 写代码的工程师总结的实操手册

两边说的话在精神上完全一致：模型的差异正在收敛，harness 的设计差异才是下一个战场。Cursor / Claude Code / Codex 拼的不是基座模型有多强，而是 harness 的设计、工具的编排、跨模型协作的工程化。

Holland 这篇文章的真正贡献是给开发者一个反 FOMO 处方：你不需要追每一个新工具，把手头的 Copilot 用透，就能覆盖 80% 的软件工程工作流。剩下 20% 才需要 MCP、custom agent、custom instruction 这些进阶武器。

---

参考资料