--- title: 'Harness工程拆解:从选工具到编排多会话' video_id: ulNsa0sD8N0 url: https://youtu.be/ulNsa0sD8N0 title_en: "Harness Engineering: What Separates Top Agentic Engineers Right Now" channel: Cole Medin published: 2026-05-28 duration: "17:08" topics: [Agent 工程, 多 Agent 协作] noted: 2026-07-05 value: S views: '6.4万' --- [![封面](https://i.ytimg.com/vi/ulNsa0sD8N0/maxresdefault.jpg)](https://youtu.be/ulNsa0sD8N0) > Cole Medin · 17:08 · 发布 2026-05-28 · 6.4万次观看(截至抓取) · [观看原视频](https://youtu.be/ulNsa0sD8N0) > 🔥 观众最高回放 [09:15](https://youtu.be/ulNsa0sD8N0?t=555) — 演示一条命令把 Agent 部署到 Google Cloud ## 主旨 Cole 把 [[Harness]] 工程拆成一副可拼装的解剖图:任何 agent 都是"底层模型 + 外面的包装",而包装分两层——你选的编码工具(Claude Code/Codex 本身就是别人搭的 harness)是第一层,你亲手搭的 AI 层(规则、skills、MCP、代码检索、hooks、subagents 六件组件)是第二层。它相对 Context Engineering 的唯一新增维度是"控制"——把多个编码会话编排起来自动跑,顶点就是 [[Ralph Loop]]。 ## 核心论点 1. **选编码工具就等于选了一层 harness**——Claude Code、Codex 是公司围绕模型搭好的包装,你没定义任何东西却已经做了 harness 选择。([[#1-两层包装选工具就是选-harness-0048|→ 详解1]]) 2. **你真正能搭的是 AI 层**,它由六件几乎每个编码助手都内置的组件构成,所有规则和流程都从这六个口子注入。([[#2-ai-层的六件组件-0306|→ 详解2]]) 3. **Harness 工程是 context engineering 的直接演进,唯一真正不同的是"控制"**——编排多会话、Ralph loop 这类跳出单会话的能力。([[#3-与-context-engineering-的分野唯一的新东西是控制-0523|→ 详解3]]) 4. **每个错误都该变成一条规则**:别怪模型、别等下一版,把纠错写回 harness,让系统随用随强(Cole 称之为 系统进化)。([[#4-系统进化心智每个错误都变成一条规则-0633|→ 详解4]]) 5. **单会话吞不下大任务,得把工作拆给多个聚焦的会话再自动编排**,这才是能动工程的顶点。(→ 详解6、7) ## 知识点详解 ### 1. 两层包装:选工具就是选 harness [00:48](https://youtu.be/ulNsa0sD8N0?t=48) Harness 工程的本质是"给模型搭外面那层包装"。任何 agent 都是底层大模型(GPT、Claude 这类负责推理的核)加上外圈的包装,后者负责喂上下文、定义流程。 第一层包装不是你搭的,而是你选的那个编码工具。Claude Code、Codex、Pi——所有编码助手其实都是某家公司围绕自家模型工程出来的 harness。有人觉得 Claude Code 是最好的编码 harness,有人押 Codex,行业还在吵。 关键在于:这层"不像 harness 工程",因为你没定义任何东西,但你在选工具的那一刻[就已经挑了一副 harness](https://youtu.be/ulNsa0sD8N0?t=138)。裸模型连文件系统都碰不到、命令都跑不了,这些能力全靠工具自带的第一层包装桥接过来。 ### 2. AI 层的六件组件 [03:06](https://youtu.be/ulNsa0sD8N0?t=186) 比选哪个编码工具更重要的,是 AI 层——包在任何编码会话最外面、由你亲手搭建的终极包装。它就是你为编码 agent 定义的全部上下文与流程。 Cole 把 AI 层拆成六件几乎每个编码助手都内置的组件:全局规则(global rules)、skills、MCP servers、代码库检索(LSP 或知识图谱)、hooks、subagents。无论你想注入什么规则或流程,都只能从这六个口子之一进去。 可以把这些组件想成一座座桥:裸模型能力有限,工具的第一层桥让它能读写文件、跑命令当上编码助手;AI 层的下层桥则由你定义——你要用哪些 MCP、搭哪些 skills、加什么规则,一直延伸到最外层的多会话编排。 ### 3. 与 context engineering 的分野:唯一的新东西是"控制" [05:23](https://youtu.be/ulNsa0sD8N0?t=323) 房间里的大象是:这不就是 context engineering 吗?Cole 的回答是"某种程度上确实是"——这正是 harness 工程沦为 buzzword 的原因,多数人没看懂它到底演进在哪。 大部分 harness 内容——上下文注入、通过工具/MCP 行动、持久化、可观测性——确实就是 Context Engineering。真正不同的只有一样:**控制**。Ralph loop、编排不同编码会话、subagent 之间的调度,这才是相对 context engineering 的真演进。 换句话说,别把 harness 工程当成全新学科,它是 context engineering 长出了"编排与自动化"这条新肢体。这也解释了为什么下半段的重头戏全落在多会话编排上。 ### 4. 系统进化心智:每个错误都变成一条规则 [06:33](https://youtu.be/ulNsa0sD8N0?t=393) Harness 工程不只是技能,更是一种心态重构。Cole 引用文章里的一个反面模式:agent 干了蠢事,工程师就怪模型,把锅甩给"等下一个版本"——Claude 出错就等 Opus 5,GPT 拉胯就等 GPT6。 Harness 工程心态拒绝这个默认反应。失败通常是可读的:agent 不知道某个约定,你就把它写进 agents.md;agent 跑了破坏性命令,你就加个 hook 挡住它。**每个错误都变成一条规则**,或者说变成改进 harness 的一次机会。 Cole 把这叫 系统进化:你在自己控制的 AI 层上,持续改进你所选编码助手的表现。这本质是[夺回主动权、为系统负责](https://youtu.be/ulNsa0sD8N0?t=426)——出问题时不再无助地甩锅,而是当那个"驾驭系统、把反馈前馈回去"的人。初代生成靠你喂的原则和上下文,hooks、review agent、skills 则是自我纠错的传感器,让 AI 层随时间进化。 ### 5. hooks 的三种实战用法 [11:31](https://youtu.be/ulNsa0sD8N0?t=691) Cole 认为 hooks 被严重低估,他主要用在三处。第一是安全:pre-tool-use hook 是一段在编码 agent 执行任何工具调用(写文件、跑命令)之前触发的代码,可以拦下"别读某些不该进上下文的文件""别用破坏性方式删目录"。 第二是[收尾验证](https://youtu.be/ulNsa0sD8N0?t=714):stop validation hook 在 agent 声称"实现完成"时确定性地跑一整套检查——单测、lint、类型检查是否全绿;不绿就强制 agent 继续迭代到绿为止。 第三是每次改完文件就跑一次快速 lint,保持代码库整洁,这反过来也让后续的编码 agent 更可靠。三种 hook 分别对应 pre-tool-use(动作前)、stop(收尾)、post-edit(每次编辑后)三个触发时机。 ### 6. PIV 基础循环:三个独立会话 + artifact 交接 [10:47](https://youtu.be/ulNsa0sD8N0?t=647) AI 层的地基是规则(约束、约定、你的模式,以 global rules 加按需加载的 markdown/Confluence 文档形式存在)加 skills(你给编码 agent 的工作流,比如"该怎么规划、实现、验证")。 Cole 强烈建议把规划、实现、验证拆进三个独立的编码会话,让每个都保持 token 高效且聚焦。每个 skill 输出一份 artifact 作为交给下一会话的交接物——这已经是"把编码会话串起来",但此处还是手动串:你用 plan skill 跑出一份 markdown,再亲手把它喂给另一个会话的 implement skill,验证策略也一并写进那份 markdown。 这套 plan-implement-validate(PIV)循环是能动工程的入门形态,不依赖任何自动化就能立刻上手。它与 [[2026-06-25-Harness为王的能动工程大师课]] 里"规划与实现拆两个独立会话防 [[Context Rot]]"是同一条工程纪律。 ### 7. 顶点:编排多会话与 Ralph loop 自动化 [13:07](https://youtu.be/ulNsa0sD8N0?t=787) Harness 工程的峰值是编排多个编码会话。核心洞见:别把一个庞大任务或 PRD 塞进单个会话——那既不 token 高效,底层模型也会被彻底淹没,**无论你的 AI 层搭得多好都救不回来**。 正确做法是给每个会话一个高度聚焦的任务:探索需求 → 一个 agent 写计划 → 计划 artifact 传给实现 → 多个 code review agent 并行跑(一个盯安全、一个盯正确性、一个盯是否够简单)→ 全过就开 PR,不过就迭代。这套既能手动串,也能自动化——自动化版本就是 [[Ralph Loop]]。 Cole 把 Ralph 归功于[先驱 Jeffrey Huntley](https://youtu.be/ulNsa0sD8N0?t=882):一个简单的 Python/bash 脚本,吃进一份大 PRD,自己把它拆成一个个任务,逐个开编码会话处理,边跑边累积日志,直到自认为做完就产出一个 done.txt 之类的完成标记——while 循环唯一的退出条件就是这个标记存在且验证齐备。收尾他还推了自家开源 harness 构建器 [Archon](https://youtu.be/ulNsa0sD8N0?t=1000),这属于 Meta Harness 一路(编排层而非单会话优化)。 ## 可执行步骤 - [ ] 盘点你当前项目的 AI 层:按六件组件(全局规则 / skills / MCP / 代码检索 / hooks / subagents)逐项列出你已经配了什么、哪一格还是空的。 - [ ] 给项目加一个 pre-tool-use 安全 hook(挡破坏性命令/敏感文件)和一个 stop validation hook(agent 声称完成时自动跑测试+lint+类型检查,不过则强制迭代)。 - [ ] 把下一个功能拆成 plan / implement / validate 三个独立会话:先跑规划产出一份 markdown artifact,再另开干净会话喂给实现,验证策略写进同一份 markdown。 - [ ] 下次 agent 犯错时别只改代码:追问"我们的规则或 hook 该怎么改才能让这类问题以后少出现",把这次纠错写回 harness(系统进化)。 - [ ] 面对超大任务先别塞单会话:把它拆成探索→规划→实现→并行 review 的多会话流程,评估要不要用 Ralph loop 自动串起来。 ## 关联 - 深化 [[Harness]] 概念页与 [[2026-06-25-Harness为王的能动工程大师课]]:大师课给的是"harness 占 90%、模型占 10%"的纲领性战略视角,本片补上**解剖图**——两层包装(选工具=第一层、AI 层=第二层)、AI 层的六件组件、以及 hooks 的三种具体配方(pre-tool-use / stop / post-edit),是同一主题更偏"零件与接线"的一层。 - 印证并命名 系统进化:大师课把"每次纠错写回 harness"讲成心智,本片是 Cole 明确给它起名 system evolution、并把它锚定为"harness 工程相对 context engineering 的心态重构"的地方。 - 深化 [[Ralph Loop]]:此概念首见于 [[2026-01-19-Claude Code 完全解读]],本片补上出处(Jeffrey Huntley 是先驱)与退出机制(拆 PRD 为任务、done.txt 作为 while 循环唯一退出条件)。 - 印证 Meta Harness([[2026-06-15-Omnigent编排多个AI编码助手的元Harness]]):本片"编排多会话、Archon 作为 harness 构建器"与元 harness 是同一层思想——优化的是编排层而非单个 agent。 ## 术语 - Harness engineering(harness 工程,围绕模型搭建可控包装层的工程实践) - AI layer(AI 层,你亲手搭的终极包装,由六件组件构成) - Context engineering(上下文工程,harness 工程的前身) - LSP(Language Server Protocol,给编码 agent 做代码库结构化检索的能力之一) - Ralph loop(自动串联多个编码会话跑完大 PRD 的循环脚本,得名于其创造者 Jeffrey Huntley) - pre-tool-use / stop / post-edit hook(工具调用前 / 收尾 / 每次编辑后触发的三类钩子) ## 金句 > "You're not defining anything, but you're picking the harness when you choose the tool." → 选 Claude Code 还是 Codex,本身就是一次没被意识到的 harness 决策。 > "Every mistake becomes an opportunity to improve your harness." → 把 agent 的每次犯错从"怪模型"翻译成"改系统",这就是系统进化的全部。 ## 立场与利益 赞助商是 Google Cloud 的 agent CLI(视频中段有一整段贴片演示可跳过,与核心框架无关)。收尾推荐的 Archon 是 Cole 自家的开源 harness 构建器,免费但属于自我推广,认知框架本身不依赖它成立。 本片核心概念(两层包装、AI 层六件组件、控制是相对 context engineering 的新增维度、系统进化心态)引自两篇第三方 harness 工程文章(视频称已放在描述区,但抓取的 meta 无描述、原文标题未在口播中点名,故不收录链接以免误引);Ralph 归 Jeffrey Huntley,属可核验的社区共识。整体是行业通识梳理而非厂商话术。 ## 价值定位 面向想成为顶尖 agentic 工程师、系统化自己 harness 能力的人: - 适合谁:已经在用 Claude Code/Codex 写代码、但还停在"提需求点下一步"、想把零散配置升级成一套可迭代系统的人。 - 解决什么:给出一张可照着盘点的 harness 解剖图——你到底能动哪几个部件(六件组件)、每个错误怎么沉淀成规则、大任务怎么拆成多会话。 - 认知 vs 实操:偏认知框架,但 hooks 三配方与 PIV 三会话拆分是可当天照做的实操。 - 与 [[2026-06-25-Harness为王的能动工程大师课]] / [[Harness]] 重叠,但**本片独有**:把 harness 拆成"选工具的第一层 + 你搭的 AI 层第二层"两层结构、AI 层六件组件的完整枚举、以及"控制是 harness 相对 context engineering 唯一新增维度"这一句判据——这三点在大师课与概念页里都没有。 ## 自检问题 1. Cole 说的 harness 两层分别是什么?第一层为什么"不像 harness 工程"却依然是一次 harness 决策? **答案**:第一层是你选的编码工具(Claude Code/Codex 本身就是公司搭的 harness),第二层是你亲手搭的 AI 层;第一层"不像"是因为你没定义任何东西,但选工具就是在挑一副 harness。见详解1 [00:48](https://youtu.be/ulNsa0sD8N0?t=48) 2. AI 层由哪六件组件构成? **答案**:全局规则、skills、MCP servers、代码库检索(LSP/知识图谱)、hooks、subagents。见详解2 [03:06](https://youtu.be/ulNsa0sD8N0?t=186) 3. Harness 工程相对 context engineering 唯一真正不同的维度是什么? **答案**:控制——编排多会话、Ralph loop、subagent 调度这类跳出单会话的能力;其余(上下文注入、工具行动、持久化、可观测性)基本还是 context engineering。见详解3 [05:23](https://youtu.be/ulNsa0sD8N0?t=323) 4. "系统进化"心智具体要求你在 agent 犯错时做什么? **答案**:不甩锅给模型、不等下一版,而是把这次失败沉淀成一条规则或一个 hook(如把约定写进 agents.md、加 hook 挡破坏性命令),让 harness 越用越可靠。见详解4 [06:33](https://youtu.be/ulNsa0sD8N0?t=393) 5. 为什么不能把一份大 PRD 直接塞进单个编码会话?正确做法是什么? **答案**:既不 token 高效,底层模型也会被淹没,AI 层再好也救不回;应给每个会话一个聚焦任务,拆成探索→规划→实现→并行 review 的多会话流程,再用 Ralph loop 自动串联。见详解7 [13:07](https://youtu.be/ulNsa0sD8N0?t=787) > [!quote] 💬 热门评论 top-14 主 + 6 回(抓取 2026-07-07) > > [2] **@youanded**:我喜欢把规划阶段再推进一步，让一个运营代理、一个业务代理、一个“技术主管”代理，还有一个魔鬼代言人（质疑一切！）等等，一起审查计划，直到没有问题，就像理想的现实世界一样。我也不会让编码代理自己编写测试，我严格划清界限：只有编码代理可以更新源代码，只有测试代理可以编辑测试。这样可以避免产生大量无价值或误报的测试。 👍 16 >   ↪ **@ColeMedin(UP)**:听起来你为自己打造了一个很棒的框架，我喜欢！ > [3] **@مدارالعقول**:解释得很好。对我来说，框架往往是演示和可靠工作流之间的区别。模型很重要，但杠杆作用在于规则、钩子、评估和编排。 👍 2 > [4] **@seanolivas9148**:你能深入讲解一下 ICM 类型的系统吗？使用文件夹和文件来引导代理，而不是让多个代理拥有自己的记忆。如果这确实是方向，那它比框架更重要。它是框架无关的。 👍 1 > [5] **@gregben**:对我来说，框架工程就是设计和实现一个框架。为什么？因为所有框架都是其创建者的选择、偏见和哲学的产物。我有兴趣设计自己的框架，从小处着手，逐步添加功能，最终得到一个我完全理解、包含所需功能且没有多余东西的框架。 👍 5 > [6] **@مدارالعقول**:说得好。尤其是在法律科技领域，我认为框架往往是令人印象深刻的演示和真正可信赖的东西之间的区别。 👍 1 > [7] **@مدارالعقول**:对我来说，在法律科技领域，价值不仅仅在于模型。还在于工作流、验证、检索、交接和审计追踪。 👍 5 >   ↪ **@richard-social8125**:编码领域也一样。我认为任何行业都应该有每个工作流对应的框架。我发现 codex/claude code 倾向于一种编码范式。 > [9] **@kirkydaturkey**:感谢描述中的参考资料！也喜欢看到人们把仓库当作“实验室”来测试概念。我建议每个人都熟悉 Docker 来测试框架——测试完框架后，只需关闭 Docker 容器即可。 👍 2 >   ↪ **@ColeMedin(UP)**:谢谢！确实，Docker 非常适合为专用框架创建容器。 > [11] **@VASTimages**:是的，这完全取决于你每个新会话要加载多少 token……在我的专业订阅中，我使用大约 30-40%，加载我的框架、技能、知识库、编码规则等等。就像以前一样，每个东西都有一个代理。现在，你只需一次性加载整个系统。 > ——其他 5 条:感谢/夸赞([8]@XxP4R4B0L4xX、[10]@AustinBoes-g6x、[12]@fiftyghoststrading8500、[13]@hardcorebyjoshely、[14]@ramonnassaralla5181);1 条 spam 已略 >
英文原文[1] @ColeMedin(UP):The Dynamous Agentic Coding Course is FULLY released - learn how to build reliable and repeatable systems for AI coding: https://dynamous.ai/agentic-coding-course 👍 3
[2] @youanded:I like to take the planning phase a step farther and have an operations agent, a business agent, a "tech lead" agent, and a devil's advocate (question EVERYTHING!), among others, all review the plan until there are no issues, just like the ideal real world. I also don't have the coding agent implement it's own tests, I draw strict lines where the coding agent is the only one that can update source and the test agents are the only ones that can edit tests. Keeps from getting lots of worthless or false positive tests. 👍 16
  ↪ @ColeMedin(UP):Sounds like an impressive harness you have built for yourself, I love it!
[3] @مدارالعقول:Good explanation. For me, the harness is often the difference between a demo and a reliable workflow. The model matters, but the leverage is in the rules, hooks, evals, and orchestration. 👍 2
[4] @seanolivas9148:Can you do a deep dive on ICM type systems? Using folders and files that point agents instead of having multiple agents make their memory. If this is actually the direction it's more important than the harness. It's harness agnostic 👍 1
[5] @gregben:To me, harness engineering is literally designing and implementing a harness. Why? Because all harnesses are the result of the choices, biases, and philosophies of their creator. I'm interested in engineering my own harness, starting small and adding features as I go to come up with one that I fully understand and has what I need in it and not much else. 👍 5
[6] @مدارالعقول:Strong point. For legal-tech especially, I think the harness is often the difference between an impressive demo and something you could actually trust. 👍 1
[7] @مدارالعقول:For me, in legal-tech especially, the value is not just the model. It is the workflow, validation, retrieval, handoffs, and audit trail around it. 👍 5
  ↪ @richard-social8125:same in coding. I think for any industry there should be harnesses per workflow. I find codex/claude code to favor one paradigm of coding
[8] @XxP4R4B0L4xX:A problem well defined is a problem half solved. ~Charles Kettering 👍 2
[9] @kirkydaturkey:Appreciate the references in the description! Also love to see people building repos as like a "lab room" for people to test out concepts. I recommend everyone get familiar with Docker for testing harnesses — once you're done testing out the harness, just shut down the Docker container. 👍 2
  ↪ @ColeMedin(UP):I appreciate it! And yeah Docker is great for having containers for dedicated harnesses for sure
[10] @AustinBoes-g6x:I was struggling to understand- but your visuals helped a lot! Thanks! 👍 2
  ↪ @ColeMedin(UP):Glad it helped!
[11] @VASTimages:yes, and it all depends on how much tokens you want to load in each new session... in my pro subscription i use ~30-40%, loading my frameworks, skills, knowledgebases, coding-rules, etc etc. just like back in the day, where you had a agent for everything. NOW, you just load your whole system upfront.
[12] @fiftyghoststrading8500:This is MUCH better than I expected! Great work! 👍 1
  ↪ @ColeMedin(UP):Thank you! :D
[13] @hardcorebyjoshely:wicked one, dude. 👍 1
[14] @ramonnassaralla5181:the best explanation I saw regard the topic ever. 👍 2
  ↪ @ColeMedin(UP):I appreciate it man, thank you!