AI Coding 进阶：从 Vibe/Plan/Spec 到 Harness Engineering 与 Agent Teams

摘要

本次分享由阿里云工程师徐劲峰（岛风）主讲，探讨了 AI Coding 从基础到进阶的演变。核心内容涵盖了 Web/Plan/Spec 三种工作流模式的区别与应用场景，强调了 AI 编程范式的快速迭代。同时，深入解析了“驾驭工程（Harness Engineering）”的核心理念——通过地图式导航、嵌入式知识管理、机械化自动验证等实践来提升 AI 编码的可靠性，并对比了不同 Agent Teams 架构在编码任务中的优势。

亮点

💡 工作流选择之道：Web 模式适合快速迭代，Plan 模式平衡了效率与控制，而 Spec 模式则最适合处理复杂系统级任务或异步的长程开发任务 [16:03]。
🗺️ 地图式导航原则：Agent 配置文件（如 .md 文档）应保持简洁，作为“地图”而非“手册”，通过目录引用按需加载上下文，避免模型因信息过载而迷失 [26:08]。
⚙️ 机械化验证取代人工：AI 编程不应止于编译通过，应通过引入自动化测试脚本（如 curl 脚本、接口校验）实现代码的迭代自愈，最大限度减少人工介入 [30:17]。
🏗️ 嵌入而非外挂：企业知识库应直接嵌入到代码仓库中而非通过外部链接外挂，利用模型极简指令完成检索，从而提升 AI 对工程上下文的理解深度 [29:10]。
⚖️ 架构与模型的共生：Harness Engineering 并非银弹，其本质在于模型能力与 Agent 架构的协同进化；在编码场景中，经过调教的专家 Agent 架构通常优于通用的多 Agent 网状架构 [45:25]。

#AICoding #HarnessEngineering #AgentTeams #编程效率 #软件架构

思考

Q: 为什么现有的开发模式中，Spec（规格说明书）文档通常不建议直接提交到 Git 仓库？
- A: 目前 Spec 文档主要定位是帮助开发者与 Agent 校准意图。若强制提交到 Git，会带来沉重的维护成本；若后续需求变更，不仅要更新代码，还需同步维护 Spec，且在当前 Token 成本较高的情况下，过度沉淀会导致上下文压力，除非团队有严格的 Spec Review 机制。

Q: 在使用多 Agent 或多对话窗口时，如何避免上下文切换导致的效率降低？

A: 多开窗口（如打开 3-6 个对话）是提升单兵作战能力的朴素方法。为了降低心智负担，建议利用 Worktree 进行并行开发，或通过预设的任务分发让 Agent 异步执行；同时，保持每个 Agent 的职责单一，利用分层 Agent 结构（如 Sub-agent）隔离上下文空间。

术语解释

Web Coding: 一种“一句话”开发模式，模型直接理解需求并完成从设计到执行的全过程，人类仅介入一次。
Harness Engineering: 指通过构建一套规范、围栏及反馈回路，为 AI 编程工程提供稳定支持的工程方法，核心在于设计生产线而非单纯手写代码。
Agent Teams: 指由多个不同角色的 Agent 协同工作的架构，通过扁平通信或主从通信模式，解决单一 Agent 在复杂编码任务中的性能瓶颈。
Sub-agent: 一种嵌入式工具调用架构，模型在遇到特定任务（如编写代码或查阅文档）时会自动拉起独立的 Agent 窗口，避免占用主对话的上下文空间。
迭代自愈: 指 AI 系统在验证环节发现故障时，能够基于上下文自主修正并重新测试，直到任务成功，减少人类在验证过程中的重复操作。

视频章节总结｜ AI 编程深度实战：从 Vibe/Plan/Spec 工作流到 Harness Engineering 与多智能体团队

本视频由阿里云工程师徐劲峰（花名岛风）分享其在 AI 编程（AI Coding）领域的进阶实践与思考。他基于个人经验，详细剖析了从 Vibe/Plan/Spec 等不同工作流模式到 Harness Engineering 与 Agent Teams 的演进路径。核心观点认为，AI 辅助编程的范式正在快速迭代，开发者应根据任务复杂度、需求澄清程度等场景，灵活选择 Vibe（一句话指令）、Plan（生成技术方案文档）或 Spec（完整需求 - 设计 - 任务列表流程）等模式。分享重点解读了 OpenAI 提出的 Harness Engineering（驾驭工程）理念，并探讨了 Spec 文档是否应提交 Git 等实践难题。同时，对比分析了以 Coder Quest/Experts 为代表的集中式多智能体架构与 Claude Code 的扁平化 Agent Teams 架构的优劣。最后，讲者强调，AI 时代程序员的持久护城河在于持续更新的认知、对工具的深刻理解以及精准选择适合自己工作流的“品味”。

00:00 - 🎤 开场与个人实践演进

演讲者徐劲峰开场，并幽默地展示了三位嘉宾使用不同 AI 工具（包括其自己贡献的 CodeWork 技能）制作 PPT 的现象，以此引出“品味”这一关键词。他强调本次分享的“进阶”是其个人认知在 AI 编程快速发展背景下的不断迭代与自我推翻，而非优于他人。他提到自己几乎每两个月就会更新一次对 AI 编程范式的认知，并鼓励现场听众也积极刷新自己的理解。

03:22 - 📊 工作流进化五阶段与能力叠加

讲者将 AI 编程工作流划分为五个阶段，从传统的逐步审批（Stage 2-3）到以 Agent 为主导的 Quest 模式（Stage 4），再到纯终端的 Claude Code 类工具（Stage 5）。他指出，这些阶段并非线性进化，而是根据场景选择不同方案。同时，他将 Plan、Spec、Harness Engineering 和 Agent Teams 视为可在任何阶段“叠加”的能力层，它们与具体工作流形式（如使用哪个工具）解耦，旨在为特定问题寻找最优解。

06:24 - 🔍 深度辨析：Vibe、Plan 与 Spec 模式

本章深入澄清了三个核心概念。Vibe Coding 是“一句话”模式，Agent 自行理解需求、设计方案并执行，人类仅在最初介入。Plan 模式（如 Coder 中的 Quest /spec 或 Edit 中的 /plan）则在技术方案阶段加入“刹车”，生成一个 Markdown 文档供人类校准，通常伴有需求澄清卡片。Spec 模式（如 Kiro 的 Spec）最为重量级，会依次产出需求文档、设计文档和任务列表，每一步都需要人类确认。讲者结合自身实践，认为 Plan 模式适用于白天大多数的中等复杂度开发任务，而 Spec 模式则非常适合“睡前设计、醒来验收”的大型系统级异步任务。

13:04 - 🤔 实践之辩：Spec 文档应否提交 Git？

讲者抛出一个引发思考的实践问题：Spec 文档是否应该提交到代码仓库？反方观点认为，Spec 文档目前主要用于人类校准意图和 Agent 在长任务中校准方向，是临时性的，无需保存。正方观点（如 AWS Kiro 团队）则认为 Spec 代表了设计模式，未来可能演变为“Spec Review”，其重要性不亚于代码。然而，讲者指出，在当前 Token 成本仍较高的国情下，将 Spec 文档沉淀到仓库会带来沉重的维护负担（需随需求变更而更新），因此他个人认为现阶段并不适合。

16:37 - 🛠️ 解读 Harness Engineering（驾驭工程）

Harness Engineering 的核心是人类角色从“手工匠人”转变为“生产线设计师”，负责连接、编排和设计反馈回路。讲者提炼出四个关键实践：1. 地图式导航：Agent 的约束文档（如 agents.md）应简洁（建议不超过 300 行），采用渐进式披露和目录引用，而非手册式堆砌。2. 嵌入而非外挂：项目知识应嵌入代码仓库，而非依赖外部文档系统（如飞书），以利用模型强大的原生检索能力。3. 机械式验证而非人工检查：让 AI 自动运行测试脚本（如 curl）、连接数据库验证数据，甚至使用浏览器智能体进行前端测试，实现闭环。4. 迭代自愈：当验证失败时，让 Agent 尝试自行修复并重新验证，多次失败后再引入人类兜底。

27:04 - ⚔️ Harness Engineering 的思辨：模型与架构之争

讲者指出业界对 Harness Engineering 存在两种倾向：模型厂商（如 Claude Code 主创）认为模型足够强大，外围脚手架应尽可能薄；而框架厂商则强调需要 Harness 来弥补上下文不足。讲者认为，最终效果是“模型能力 × Agent 架构”的乘积，两者需协同进化。他个人认同 Harness 的实践理念，但提醒要警惕教条主义，应根据实际情况灵活应用。

29:41 - 👥 多智能体团队：从单兵到军团

探讨多智能体（Agent Teams）的演进。第一步是朴素的多开会话窗口，但受限于人脑上下文切换能力（讲者自述极限为 3-6 个并行对话）。第二步是专业化的多智能体架构。讲者对比了 Coder Quest/Experts（集中式，有预制角色和中心 Leader）与 Claude Code Agent Teams（去中心化，子 - 子通信）两种模式。他认为在编码任务上，Coder Experts 因其专门调教而更具优势；而 Claude Code 的架构可能更适合探索性任务。他引用谷歌的 Benchmark 说明，规划类任务适合单 Agent，垂直严谨任务适合集中式多 Agent，创造性探索任务则适合去中心化网状结构。

39:35 - 💎 核心总结：AI 驾驶员的永恒护城河

在快速变化的 AI 工具浪潮中，讲者认为有三点是相对不变的护城河：1. 认知：持续尝试新工具，理解他人实践，以校准自身方向。2. 理解：深入理解工具底层逻辑，从而能看清边界并形成自己的笃定想法。3. 品味：根据不同的任务、场景和个人 / 企业情况，精准选择最适合自己的工具和工作流。这种“选择的分寸感”是 AI 时代开发者的核心能力。最后，他通过两个实操演示（CodeWork 的信息图生成技能和 Harness Creator Skill）展示了这些理念的具体实践。

AI Coding 进阶：从 Vibe/Plan/Spec 到 Harness Engineering 与 Agent Teams

作者: Qoder

原视频链接: https://www.bilibili.com/video/BV1MJXZBgE32

润色版链接: https://bibigpt.co/video/BV1MJXZBgE32&tab=Article&article=TextArticle

🎤 开场与个人实践演进

时间段: 00:00 - 03:22

大家好，我先自我介绍一下。我是来自阿里云云智能的，也是个工程师，但是我不是 Coder 的团队的，我的名字叫徐劲峰，我的花名是岛风。后面两个维护的就是我个人参与的开源项目，一个是 High-GR，一个是 High-Market，我不知道有没有人听过。

Ok，在今天我在分享之前的话，我也想聊一下我的感受，就是感觉很有意思。你看第一位演讲的嘉宾分享的是偏传统的 PPT 对吧？第二位嘉宾使用的是我感觉应该是通过那个 Coder，他的 Quest 或者是那个 Edit 里面好像都有个 Skill 叫做那个 Front-end Design，应该是通过那个去生成的，对吧？

我的 PPT 的话，我的 PPT 的话就是通过那个，也是我自己给那个 Code-Work 去贡献的 Skill。他是能看到风格的话，应该就能发现他是通过谷歌的那个模型对吧？他们一般不让说名字，但是大家应该都知道的那个模型去生成的。所以说感觉我一直喜欢、很喜欢说品味词，你看现在我们分享的三位嘉宾就用了三个方案来制作 PPT。所以有的时候我们说 AI 帮我们提效、帮我们重构，它并不是说帮我们制作更好的 PPT，它用另外一种形式，就是诞生出来了，无论是 HTML 还是图片，我感觉现象很有意思，所以顺时说一下。

Ok，我的话今天主要分享的话题的话是 AI Coding 进阶，挑了一些最近容易蹭到热点的词，Spec、Harness 还有 Agent Teams，对吧？刚才另外嘉宾也讲了一下 Agent Teams，待会我也聊聊感受。首先左下角是我的公众号，里面会分享一些 AI Coding 的实践。但不过大家如果感兴趣的话可以关注一下，里面我的一些文章，刚包括这里发了三篇，还有一些其他的都记录在这上面。我也是咨询过，可以放我自己的那个公众号。

Ok，我这里想分享的是什么？就是说我的 AI Coding 的认知，或者我刚才标题里面那个“进阶”两个字，并不是说我比你进阶，而是我个人比我个人进阶了。我总结了一下，你看我文章的顺序很有意思。我去年是 2023 年 11 月份，我是那个时候大概用了 2 到 3 个月的 Coder，写了一篇总结文章；再到了后面的两个月，我又写了另外一篇，就是他们的 Quest 发布了，我又写了一篇文章；再到最近三月份，我又写了一篇文章。

我感觉我每一次每过两个月，我自己的 AI Coding 编程的范式都发生了变化。 我每两个月我都会去推翻我过去两个月的我的认知。所以说我感觉 AI 发展真的很快，我们的认知也是不断的去通过我们所接触到的事物和个人在 AI Coding 中的实践所被刷新的。 就像大家这么在工作日来到了我们 Coder 分享的现场，肯定也是希望自己的认知能够获得更高的一步提升的，我也希望我今天的分享能给大家一点收获。

首先我喜欢让现场的同学来举手。

📊 工作流进化五阶段与能力叠加

时间段: 03:22 - 06:24

我相信第一阶段就是我们工作流的进化模式。

第一阶段我相信来场子的应该至少都是中手，对吧？第一阶段肯定大家没有人对吧？那二三阶段联合起来，问是偏 Yes/No 逐步审批的 Low-code 模式，还是偏 Agent 体的协同方式？我不知道如果是你的主要工作流的话，方便能不能举个手让我看一下，对二三两个阶段。

Ok，那剩下的看来都很高。那有多少人开始已经用 Cursor 了，它里面不是也有 Composer 对吧？大家用过 Cursor 都知道，Composer 它整个 Agent 的成为了主舞台，都不太关注文件数了，就习惯用 Composer，能不能方便举个手让我看一下？好像比刚才多一点。不知道剩下的人是都在最后阶段，还是说是害羞，还是说在第一阶段用 Cursor CLI 或者是 Cloud Code 纯终端的方式？有多少同学方便能举个手吗？看来现场还是高手多一点，剩下的我相信你们的工作流没有被我包含，并不是你们在第一阶段或者你们害羞。

Ok，我个人认为从第一阶段到第五阶段，说实话我有时候也都在用，只不过待会我也会介绍。我并不是说我进化到了某工作流就停在那儿了，而是我在不同的场景里面我会用不同的方案，但是整体而言的话，肯定是越往上的话，你的工作流或者叫心流能保持得更好。我个人的感受是这样，也保不齐两个月后我又来推翻我自己的认知。

接下来下面这三个，我把它列为了叫能力叠加，也就是上面是工作流的展示形式，但是下面是我们在无论是 1 到 5 当中，我都可以叠加进去的能力。就包括我们会在使用 Web 模式时，有的时候去触发 Plan，有的时候去触发一些包括你可以说是配合 Cursor，包括 Cloud Code 可以去搭配像 Superpower 或者是 Open Interpreter 等等很多开源的外接的一些工作流或者是 Skill，你都可以跟你的现有的工具搭配得很好，也算是一种能力的叠加。

包括 OpenAI 提出来了最近火的 Harness Engineering，我认为它也是一种能力的叠加。它跟你上面用什么是没有太大的区别的，待会我也会有演示。包括 Agent Teams，它也是在你现有能力的基础之上叠加。我们并不是说哪种能力就取代了上面的哪种形式，而是说我们在合适的场景里面去挑选到解决问题的最优解，这是我的认知。

我的第一个话题的话，会首先围绕 Web Coding，包括 Plan 和 Spec 这三个容易被混淆的概念。

🔍 深度辨析：Vibe、Plan 与 Spec 模式

时间段: 06:24 - 13:04

包括我一开始也混淆了这些概念，但是现在，在我不懈地与 AI 专家团的同学深度交流、并向美团负责 AI Coding 的朋友多方求证后，我总结出了一套经验。关于 Web、Plan、Spec 这三个名词在 AI Coding 大框架下的区别，我将其归纳如下。

首先，我将它们分为三个模式，横轴对应需求澄清、技术方案（Design MD）以及任务执行这三个阶段。

Web Coding 模式的特点是“一句话完成任务”，它包含了需求澄清、技术方案和任务执行全流程。在这个模式下，人类只介入一次，剩下的如何理解需求、制定技术方案以及最终执行，完全依靠 Agent 自行处理。

而 Plan 模式需要特别澄清一下。大家在 Cursor 无论是 Edit 模式里的 --plan，还是 Composer 里使用的功能，在我看来都属于 Plan 模式。它的核心是在“技术方案”这一环加入了一道“刹车”。系统会先产出 .md 文档，你可以在文档阶段与 AI 进行校准。现在很多工具在出 Plan 文档前，会有“Ask User Question”环节，通过弹出卡片让你做选择题，这主要取决于 Agent 的设计品味和模型对需求的理解深度。Plan 模式是目前大多数开发者日常工作流的首选，因为在处理中等维度的 Feature 时，我可以把细节交给模型决策。

至于 Spec 模式，我认为像 Cursor 的 Composer、OpenAI 的 Spec 等，才真正符合其定义。它的核心在于每个环节都会产出文档，包括 requirements.md、design.md 以及 task list 等，流程比前两者更重。很多人觉得它不实用，其实是因为没有找到合适的场景。

我发现 Spec 模式非常适合系统级的复杂任务。虽然它在收集需求、对齐上下文、生成设计文档以及确认任务列表时，每一轮交互都很慢，显得非常繁琐。但它有一个极佳的异步应用场景：利用“睡前设计、醒来验收”的模式来处理大块需求。我在睡觉前花 30 到 40 分钟与 AI 梳理清楚需求，点击开始后让它运行一两个小时。对于超长流程的任务，借助于顶尖模型，第二天醒来时它已经把工作梳理得非常好了。我花了 40 分钟的时间，换取了整个晚上的自动开发效率。

总结来说，Web、Plan 和 Spec 并非优劣之分，而是针对不同任务复杂度与需求澄清精细度的选择：

Web 模式：适用于快速修复 Bug 或简单任务；
Plan 模式：适用于日常开发需求或中等难度的 Feature，兼顾了效率与人工干预；
Spec 模式：极其适合系统级的复杂任务，或是白天设计、晚上由 AI 异步执行的场景。

🤔 实践之辩：Spec 文档应否提交 Git？

时间段: 13:04 - 16:37

我不会简单地跟大家聊阶梯，我还是更想跟大家（探讨）。我看今天提问题的同学里，很多人提到的词是“超级个体”，说明对于 AI 的了解深度还是不错的。

我跟大家探讨的话题是：Spec 文档应不应该提交到 Git？ 我不知道大家有没有思考过，这个问题会引发出哪些思考。

反方的话是说，像现在大多数的设计，我就不谈大多数了，它默认的情况下 Spec 文档，包括 Markdown，是不保存到你的仓库里面的。我不知道大家有没有想过这是为什么？因为它目前来说只有两个定位：第一定位是帮助人类去校准意图的文档；第二个定位是帮助 Agent 去校准的作用。

就比如说刚才有位同学提了问题，在执行一些长任务的时候，模型发生了上下文的溢出，比如达到 200K 了对吧？那我要压缩，通常所有的 Agent 基本上都会做设计，就是当我有 Spec 的时候，我在模型压缩以后，Agent 会再做一件事：把你的 Spec 文档重新注入上下文，这就是相当于强提醒。这就是它的第二个作用，即帮助 Agent 在长程任务当中去校准他的方向。 所以说它只做这两个定位的话，是不需要被保存下来的。

但是也有些人认为 Spec 文档应该要保存到 Git，为什么？因为 Spec 就代表了你的设计模式，就代表了你的代码。未来我们说，包括现在 AI 这么牛了对吧？那我们不需要去再去 Code Review 了——当然还是要 Code Review 的——更推崇的是什么？是 Spec Review。就是说你去 Review 别人的代码的时候，不会去一行一行过那么多的细节，我会去 Review 你的 Spec。

包括我也有朋友跟 AWS 的架构师去做过交流，就是关于在 AWS 内部，Spec 应不应该提交到 Git 上面，他们那边是非常推崇要提交到代码仓库的。但是这里会带来什么问题？就是说你一旦把 Spec 文档沉淀到你的代码仓库，你就会带来维护成本。你的新需求如果对你存量的 Spec 发生了变更了，那你是不是要去调整过去的 Spec，或者是去找到你过去的 Spec 进行修正？因为你一旦把它引入到你的上下文里面，你的 Agent 就要为之而去进行修复。那对于产品的设计和你团队的要求就非常高了对吧？

如果你是在企业里面，就是说所有人都推 Spec、强制执行，那我相信还能跑得下去。但如果是当下你买了那个企业版 API，Token 不够用，那别的人跑去用其他的了，你怎么去限制他？你要不然给他足够的 Credits，让所有人都去用 Spec 并沉淀下来。那你如果做不到，那不好意思，你不能限制你的员工不使用其他的 AI。

所以我认为在当下阶段，特别是中国的 AI 环境，大家还普遍觉得 Token 贵的情况下，不太适合把 Spec 提到 Git 里面，这是我的个人观点。

🛠️ 解读 Harness Engineering（驾驭工程）

时间段: 16:37 - 27:04

OK，那我们快速聊到下一个话题，就是什么是 Harness Engineering。

说实话，一开始我英语不太好，我都不知道 Harness 是什么意思。后来搜了一下才知道，这个词一般在国内翻译成“马鞍”或者叫“驾驭”，这个工程听起来挺“咋呼”的。我当时也是去看了 OpenAI 那篇原文，看以后说实话，第一感受就是：如果这篇文章不是 OpenAI 的工程师发出来的，我就在想这东西好像我也会，好像没什么新东西。当然，这并不是对他们不尊敬，OpenAI 还是很牛的，但是一旦它带了 OpenAI 或者是 Anthropic 的前缀，我就开始审视了，是不是里面有什么细节是我没有品味到的。

所以说，我也在尝试跟很多同学去交流，Harness Engineering 是不是每个人从中读出来的那一层感悟是不一样的。所以说今天分享的也不光是我的一家之谈，我跟很多同学在阿里内部都有过这种 Harness Engineering 的交流。

首先先介绍一下，有些同学还不太了解，或者说只听过名字，什么是 Harness Engineering？它的核心倡导原则就是：负责连接、编排和设计反馈回路，给你的 AI 工程套上围栏，或者说去更驾驭好它。

这里我画了两个图，很简单，就是说未来我们在 Harness Engineering 里面，我们的人不再是一行一行手写代码的手工匠人，而是 设计生产线的工厂设计师。你关注的是整个工程，怎么让 AI Agent 把代码写得很好，还能测试，甚至能直接产出，还要把性能把控得很好。

我自己总结出来，Harness Engineering 那篇文章说实话更偏向是一篇博客，而不是非常系统地把观点梳理好给你。所以这里我结合自己的感悟，提炼出了四个实践：

第一，地图式导航

什么意思？这跟现在大家都很懂的理念很像，叫做“渐进式披露”。Skill 当时火的时候大家都对这个词不陌生了，Harness Engineering 那篇文章也提到了。但当时他说的除了 Skill 要渐进式加载之外，也提倡你的 agent.md 不应该是把所有的约束都放进去，而是说 你的 md 里面应该是不超过 300 行的地图导航。

刚才有一位同学也提到了，你应该把架构约束和系统性设计分拆到不同的文档里面。那怎么样去注入你的上下文？一种方式是 Skill 触发，另外一种是你在 agent.md 里面，比如我开发了 A 项目，它依赖了 B 这个很大的工程，那我只需要在 agent.md 里说“当需要时，去查阅 B 的工程手册”，只需这样一段话。等模型决策要去探索时，它会以目录引用的方式进行下一步，而不是把所有信息都内化进去。所以 agent.md 不应该超过 300 行，如果嫌短，总之不要超过 500 行。你给的东西越多，模型就觉得什么都不重要；你只有给出短的约束，它才能知道重点在哪儿。

第二，嵌入而非外挂

我知道很多企业在落地 AI Coding 时存在实践不足。很多传统企业说我们的 Copilot 不太好用，因为文档存在钉钉、飞书或者自己内部的仓库里，连 MCP 都没有。这里单纯聊技术的话，我觉得他们犯了个错：知识应该是嵌入到你的仓库，而不应该是外挂在外面。

为什么有的工具很强？因为它通过 grep 以及极简化的指令，就把过去那种偏 IDE 型的产品给打败了。提倡这一点的核心在于：因为我的模型已经足够强大，我只需要极简的工具就可以达到检索目标。如果你还是靠外挂，本质上还是达不到嵌入仓库的效果。你可以结合第一点，在 agent.md 里告诉它外部仓库在什么时机应该去读。

第三，机械式验证而非人工检查

我觉得这是一个进化理论。很多同学在写完代码后，止于 Maven Build 或 Maven Compile 通过，或者止于 Lint 检测通过，然后就交给人类去 npm run dev 或启动 Java 程序。

什么叫机械式验证？就是既然你在写完代码后需要验证，那为什么不能让 AI 自己去验证？让 AI 去跑你的系统检测脚本。比如你写了 Java 项目，它有代码仓库的上下文，它知道接口报文怎么组织。那是不是可以让他自己帮你把仓库拉起来，通过极简的脚本把功能测一遍？它甚至可以连开发库的数据库，校验脚本产生的数据格式对不对。原本需要人去检查的过程，被 AI 取代了，如果发现问题它还可以进行自我循环，这比单纯的 Build 通过要好得多。

甚至我现在的实践是：我不满足于后端验证，我甚至会让他写完前端后，通过内置的 Agent Browser 把前端点一遍。虽然目前浏览器智能体烧算力有点厉害，但在调试复杂前端问题时，无论是异步调用、控制台报错还是渲染问题，它依然能帮我发现。所以大家要结合任务复杂度去随机组合。

第四，迭代自愈

意思就是模型会有幻觉，特别是在长任务上下文压缩之后。OpenAI 提出的理念是：如果失败了（比如你发现接口不通），代码写得有问题，它就开始去重新写代码，重复刚才把项目启动起来并验证的环节。当它尝试三次之后还不通过，那时候才让人类介入。也就是说，尽它最大的 effort 去努力解决问题，最后实在不行人作为兜底。

聊到这儿可以看出，我并不是严格的“Harness 派”。包括业界在 Harness 词提出来以后，也不乏有一些自媒体在第一时间进行吹捧，就跟当年我们说 Prompt Engineering 跟 Context Engineering 那个一样。你作为人类，才是 Agent 的方向舵，而不是你在被 AI 写。

⚔️ Harness Engineering 的思辨：模型与架构之争

时间段: 27:04 - 29:41

很多没有自己认知或者没有实践的同学，就会觉得 Harness 是银弹，对吧？那我这里先抛出一些外部大流的观点。

很多模型厂商，包括 Cursor 的主创、OpenAI 的另外一位研究员，他们都认为说：“我愿意把一切都交给模型，模型是最强大的。” Cursor 主创一天到晚在博客里说：“我们的 Cursor 什么两个月就会完全重写一次，我没有任何的秘诀，所有的秘诀全部在模型里面。”

这说明什么？他认为 Harness 也好，你在外围搭建的任何脚手架也好，本质上是随着模型不断的进化，而随之应该是最薄的那一层，不需要为它构建什么。

当然也有一些框架厂商，包括我搜了一些资料，像 LlamaIndex 的创始人，他就说：“模型已经足够强大了，是框架我们为之构建的上下文不够，所以说我要推 Harness。”

所以说你发现没有？模型厂商在说模型很厉害，不需要 Harness；而那些框架厂商说 Harness 很重要，模型已经足够强大了。本质上我觉得有点像当年的微服务之争：微服务应该要不要拆？怎么拆？拆两个、三个还是拆一大堆？有一点我觉得他是有点利益相关的，就是说所有人都很激进，但真相往往是在中间的。

这是我的观点，所以在我这里我画了公式，我觉得这一定是对的：你的产品能力或者你达到的效果，一定是模型能力乘以 Agent 的架构。

就像刚才第二位同学分享的，为什么他只把 Agent Team，就是那个 Expert 专家团，把极致模式和 Auto 放出来了？他为什么有些人说：“我能不能用便宜的模型也用？” 那是你的模型能力不够，那你不是等于浪费时间吗？所以说这里一定是模型能力和 Agent 的架构，我觉得是两边要一起去进化的。

我个人的实践待会也可以给大家去分享一下，我现在就先不切换屏幕了，我会以我这边在维护的开源项目为例，分享我在 Harness 之前有哪些观点，我也会分享那些能够从 OpenAI Harness 文章里面获得共鸣的内容。

👥 多智能体团队：从单兵到军团

时间段: 29:41 - 39:35

就是具体用 Harness，就是说我们也是为他打造了两个 skill，是 Harness Creator 还有 Harness Executor。他可以把这两个 skill 给融合到你现有的工作流当中，也是实验性阶段的事情。我最终的个人观点是什么？就是我认同 Harness 的实践，但是要警惕教条。

下面就不废话了，最后给大家分享的是 Agent Teams。就是说，我一直觉得无论我们 AI 的这种工具无论怎么样的演进，你掌握了 Spec 也好，掌握了各种各样的 Agent Teams 也好，还是说有什么上下文优化，提升效率最大的点也是最朴素的点，很多人都忽略了，就是你多开几个会话窗口。

就是最朴素的多 Agent 的，对吧？你可以是三个工程，每个工程都开 Coder 里面去开始对话，这也是多 Agent 的，为什么瞧不起人家多会话，对不对？你也可以通过内置的这种 Git worktree 来做相同代码仓库的多个分支的这种并行开发。一些一边跑单测或者是两个无关的需求，我甚至有的时候连 worktree 我都不拉，我就看两个会话让他去跑，我就控制一下他的边界，大部分情况下他能工作得很好。所以说开多会话，你打开多几个会话窗口，多开几个 Cursor 的会话，都是可以证明你在用多 Agent 的。为什么只有把产品显性化的那才叫 Agent Teams 呢？ 所以说本质上是在解决单 Agent 的瓶颈的问题。

也就是说未来东西怎么说，多开会话上限是人脑。我自己自从看了那个 Open Claude 的那个主创，他那个图很惊人对吧？他一天提了多少个 PR，还有个截图很触目惊心。Peter 人左边屏幕、右边屏幕、左下角笔记本，一看他打开了 20 个 Claude Code 的那个会话窗口，人家就开始吹捧说：“我靠，你看我们就是程序员的就应当如此。” 对吧？就打开那么多会话窗口。我也尝试了一下，我有一天下午什么会我都拒绝了，我就在那疯狂的给我的项目去提交 PR，我发现我的上限是 17 个 PR。不好意思，虽然我觉得我还是有一点实践了，但是我的脑袋年纪大了真的跟不上上下文切换的那个速度。所以我不知道大家能最多开多少个窗口，反正我最多开 3 到 6 个，那已经是我人类的极限了。我指的多开是指我同时进行 6 个会话的对话。

我觉得在多开会话的整个过程中最复杂的点在哪儿？就当我要同时设计 6 个 Spec 时，钉钉弹窗说任务完成了，我开始切换过去，这会话当时讲了啥？我不好意思，我要重新，我的人脑要漏的一次快崩溃。会话它的上下文，我相信大家如果但凡是用那个会话窗口或者是用这种多会话，我相信大家如果做个尝试一定会遇到我痛点。那怎么说？就是说你如果是让你分发好了一些任务，让他一直在那跑着，那还好。但是如果真的是并行的、多会话同时去管理那么多的窗口，我觉得我还是老老实实上班吧。我感觉 Coding 说是在提效，我感觉我每天工作更累了。所以说这是第一点，就是从单兵走向作战军团的第一步，就是你可以尝试去多开多个会话窗口。

到了第二步就开始有意思了，就开始上点强度了。我也是好好的为这次演讲做了一些功课。说实话，这块因为不是专业写 Agent 的，大家希望大家理解一下。就是说对于底层的一些细节肯定还不是像 Cursor 团队研发那样那么深刻的理解的。我也是凭借自己的认知和去向他们团队的研发团同学去进行了请教。我相信大家我能感觉到大家的热情，就是说第二个嘉宾在分享的时候大家眼睛都在放光，就 Cursor Composer 作为那个专家团一开始很性感，大家的提问也很踊跃。

我一开始也很激动，我靠，上了以后好像这比 Claude Code Agent Teams 还要牛。刚才那个测试结果也是如此，但我后来审视了一下，发现的确挺牛的。那这里的话我是尝试去对比了一下，我不知道大家刚才有没有人提问想就是有这种疑问，就是说 Coder 的 Composer 模式里面，它已经是优化过后的 Agent 的架构。什么是 Sub-Agent？如果有同学不太理解的话我可以简单去澄清一下。就是说 Agent 它本质上是脱耦的，它是内置的工具，它就是占独立的上下文。当我的主 Agent 在内置了工具之后，我的模型说：“我有一段编码任务，会有一段 Expert Agent 或者是 Plan Agent 我需要去工作的时候”，那是模型自类似于像 MCP 一样，像 Tool 调用一样，我会自动的去把 Sub-Agent 给拉起来，它是独立的、干净的会话。而最后 Sub-result 的结果最后是传递给 Main Agent，就是那个主 Agent，它很少地就占用了主 Agent 的上下文空间，并且它本身也是可以做成异步的。

Sub-Agent 的这套架构是目前为止最经典的，就是我刚才提到的所有的 Agent 里面，就你们刚才所听到的那些名词里面，什么 Cursor、Claude 之类的工具里面，包括 Coder 的自身，所有的是都会支持这种 Sub-Agent 的这种结构。它的优势我觉得是什么？因为它没有内置角色，我处理一些通用任务的时候它足够灵活。比如我有的时候我拿 Coder 的 Composer 模式，我不仅仅是拿它来写代码，我还用来做 PPT，我还用来写文章。所以说如果是一些预制好角色的或者是偏 Workflow 的，就不太适合我去做一些通用任务。

而 Coder Expert 它也很领先，我觉得它是比 Claude Code Agent Teams 更加适合这种代码任务，因为我们大多数用 Coder 还是去写代码的。它确实比 Claude Code Agent Teams 更有优势。我是完全站在自己的立场，我的所有的观点都来自于我自己实测过后的感受。但是我觉得也得给那个 Claude Code 说句公平话，就是说他的多 Agent 的设计目前是开放了子子通信的。就是我们在编码场景里面，我觉得的确是 Coder Expert 架构更优秀。Claude Code 里面跟那个 Coder Expert 最大的区别就是所有的节点都是扁平通信的。

我当时大概对比了六七个点，的确 Expert 比之前的模式要大概在四五个点上面会有优势。也推荐大家在 Expert 出现之后多去做一些尝试，就至少去拥抱，强制自己去用这么几天，可以获得跟之前自己更多的认知。我相信今天分享过后我的观点都不重要，你的感受最重要。

这里是我刚才所说的要再去继续分享的点，就是这张图是什么。左边是谷歌的 Benchmark，它就是说 Multi-Agent，包括当时大家所了解的非 Coding 场景的这种 A-to-A 协议，谷歌这边的 Benchmark 还是非常多的。他就把这种多 Agent 的架构去处理不同的任务类型，这四种场景分别代表我们不同的任务类型。如果是规划类型的这种工作任务，适合用 Single Agent，就不涉及到那么多的工具调用；如果是垂直严谨模式的，它适合中心化的这种新型通信，也就是现在的 Expert 这套实现。

💎 核心总结：AI 驾驶员的永恒护城河

时间段: 39:35 - 50:32

如果 Leader Agent 的思路跑偏了，那是不是他把整个团队都给带偏了？所以说，主 Agent 自身的聪明程度是非常重要的。

那如果是一些偏探索性的任务，本身就没有正确答案，就需要所有的人都是平等的 Pair 去做探索，这时候这种去中心化网状的结构，Claude 的这种架构及支持通信就会表现得更加优秀。当然，你的钱包也烧得更快。我自己做过测试，完成了任务，当时用 Cursor 400 多次请求完成了那需求；Claude 我也用了 Claude Agent Teams，就是跑了一下，还没咋跑，就感觉它已经开始跑偏了。所以说，实有的时候还是要看你的具体场景的。如果是现在编码任务场景，有 Cursor 这种专门给你调教过的专家，肯定比你自己去探索使用非常散的 Agent Teams 要更加好。

右上角又是我的二维码了，刚才没扫的同学可以再扫一下。OK，最后我说一下，大家先等一下。讲完以后我还有实操，大家先别急着结束，我先说一下，稍微给我的演讲升华一下。

对，就是说 AI 驾驶员的永久护城河是什么？我觉得我再回到我刚才一开始给大家讲的，就我每两个月就会推翻我过去的认知。你看我现在说了这么多我的观点，再过两个月，我可能就说“两个月前我在胡说八道”，那也是有的。但是我也在总结，就是这两每两个月我对自己的认知做一次升级的过程当中，有哪些观点是不变的？

第一，我觉得认知就是我需要不断的去尝试这些工具厂商、模型厂商所推出来的这些最新的工具。就像我不会只用 Cursor，我会用很多其他的工具来弥补我视野的缺失。理解工具，包括 AI Coding，我们今天为什么要来听分享？了解别人怎么想的、了解别人怎么实践的，可以更好的去帮助自己去校准自己的方向。理解清楚别人的观点和自己的尝试，以及再加上对这些工具底层逻辑有了一些了解之后，更容易让我们去看透一些边界，以及我们自己会有一些想法，我们会更加笃定。

另外就是个人的品味，就是我刚刚提到的，无论我们不同的嘉宾选择不同的方式去做我们的 PPT，都借助于 AI 辅助，但大家有不同的辅助方式。有人用生图，有人用 HTML，有些人用生图以后插入 HTML 再插入 PPT，都是不同的品味。包括我们什么样的任务选择用 Web 模式，什么样的任务选择用 Plan 或者 Spec，包括大家每个企业到底是采购 Cursor 还是个人自费等等，这都是在 AI 场景下不同的选择。根据不同的任务、不同的场景去选择到底应该用哪一套工作流，这就是人的品味。

OK，就是精准的选择最适合自己的分寸，稍微升华一下。

最后稍微带一点实操，因为担心翻车，所以我就不现场演示了，但是我把我的一些实践给大家分享一下。

第一，大家可以去试用一下 Cursor 里面的 Notion，就是信息图的生成，是我贡献的（虽然它没写我的名字）。整个 PPT 看起来有点像 NotebookL 生成的对吧？但我大体底层调的是一样的模型，我是通过 Cursor 直接去生成的。我是直接写好我的大纲，一键生图。包括我发现我们内部的很多同事，在我们内部也推广了很多，人的文章里面开始出现这种插图，我感觉很高兴。所有人都是在写文章以后让自己的文章更加亮眼，写 PPT 都会用一种根据文稿去生成插图的这种方式，来提升自己汇报的高度，或者更适合去传播。

第二个是刚才提到的那个 Harness，昨天晚上跟 Cursor 团队的同学一起去调了 Harness。这是他们最近上线的功能，叫 Create Skill UI，它可以让你的 Skill 执行可视化，是挺炫酷的功能。我先介绍一下，可以看到这里我是让他给我的 Harness Create 去创建了 UI，未来你去执行 Skill 的时候，它就有表单了，还是挺有意思的一件事。

在执行的时候，它会为你的系统构建围栏，包括给你的项目去优化你的 agents.md，去生成你的架构规约文档，包括校验，还有 CI Config，就是说你这一套项目怎么样去跑 CI/CD 流程，包括你的 Makefile 以及可观测性。可观测性其实是借鉴了 OpenAI 的思想，就是说我不仅仅是要把我的项目跑起来，我还要构建 Protocol 把性能观测出来。

这里还有一个很有意思的点，就是它引入了动态的垃圾回收机制，就是说你的代码越堆越多，存量的项目是不是有一些已经过时了？通过勾选的方式，你觉得你要什么程度的 Harness，都可以通过 Harness Create Skill 去创建出来，把思想通过 Skill 的形式去表达出来了。

它跑了很久，我印象非常深刻，昨天晚上我等了他大概二十多分钟。跑完以后，它为我的项目构建了非常多的文档。这里有一些认证的体系，包括一些事件的触发机制，还有 Gateway Operator，它会把你 Harness Execute 执行过程当中的记录都保存下来，包括技术债。它在 Harness Create 过程当中就发现了你的项目里面出现了哪些反模式，并在你以后涉及到相关改造的时候进行修复。

它还会为你项目生成架构文档，跟我们的 Readme 有点像，只不过是更加精简化的架构以及开发范式。它也会把你项目里面怎么样去启动、怎么获取 Token、数据库信息等都沉淀在这儿。它的架构非常有意思，就是“地图而非手册”，当你的任务不需要去读架构的时候，它不会去阅读里面的详细文章，等需要的时候，它会按需去索引。

总之，它也能精准识别到过去我的项目里面的启动脚本和构建脚本。文档我昨天跑了一下，的确还有一些问题，比如说在整个项目拉起的过程当中还会遇到一些阻塞点。大家可以关注一下 Cursor 的公众号，或者关注我，后续我们会把这两个 Skill 开源出来。

其他的，我的分享就到这儿。

本文章 AI 技术总结由 BiliGPT 完成：

如果你感觉好的话请与其合作，我们共同进步

AI Coding 进阶：从 Vibe/Plan/Spec 到 Harness Engineering 与 Agent Teams

摘要

亮点

思考

术语解释