跳转至

万字干货！Harness Engineering如何工程化落地？

Ch05.029 万字干货！Harness Engineering如何工程化落地？

📊 Level ⭐⭐ | 16.1KB | entities/harness-engineering-jk-launcher-baijiajie.md

万字干货！Harness Engineering如何工程化落地？

核心结论

  • Harness Engineering = Rule + Skill + Sub Agent + Workflow + Scripts + MCP 六层串联
  • JK Launcher 真实工程案例：从0到1搭Harness，第一步做什么，按什么顺序逐步补齐
  • 核心问题：AI开发不能只靠提示词，不能把模型当"更聪明的代码补全"

六大核心概念

概念 回答什么问题 工程角色
Rule 什么事绝对不能乱来 基础规矩/红线/底线
Skill 这件事具体应该怎么做 固定动作标准操作手册
Sub Agent 复杂任务由谁分工处理 不同阶段专业角色
Workflow 这些角色按什么顺序接力 前进/暂停/打回/重跑规则
Scripts 最后谁来判断做没做好 统一门禁和事后验证
MCP AI怎么安全接上外部工程系统 外接能力与工具链

Rule（软约束工程规矩）

  • 给AI写工程规矩，不是需求/设计/脚本，是带新人的基础原则
  • 典型：改完代码必须编译+测试+事后验证，三步不全过不算完成
  • Rule是团队"研发制度"：减少混乱而非创造价值
  • 只软约束非硬门禁，模型可能无视

Skill（标准操作手册）

  • 固定步骤防止临场发挥。例：编译Skill = 找MSBuild + 输出日志 + 看错误模式
  • Rule告诉"必须做"，Skill告诉"怎么做"

Sub Agent（多角色分工）

  • 解决单一Agent自解释/自打分/硬推任务问题
  • 需求分析/方案设计/开发/QA分离，产出写文档交接给下一Agent

Workflow（接力赛规则）

  • 三层：给人看整体链路/给系统看阶段迁移/给角色看接棒交棒文档
  • 核心：前进/暂停/打回/重跑有明确依据
  • 上下文纪律：每棒只给当前该看的材料

Scripts（最硬门禁）

  • 直接检查而非告诉AI
  • 典型门禁：XAML中文/C#8语法/MessageBox.Show/硬编码UI/测试数量异常
  • 成熟Harness越来越依赖脚本而非提示词

MCP（外接能力接口）

  • 标准方式把仓库外能力（CI/签名/制品/发布/回写状态）接入AI链路
  • Unity工程：对接Editor编译/场景/日志/受控命令
  • 当Harness从开发闭环推到交付闭环时，MCP是关键层

六层串联

  • Rule → 底线（什么事不能乱来）
  • Skill → 高频动作标准化
  • Scripts → 判断结果对不对
  • Sub Agent → 多角色分工
  • Workflow → 按顺序接力
  • MCP → 往外部工程系统延伸

深度分析

Harness Engineering的本质：从"模型调用"到"工程系统"

Harness Engineering的提出直指当前AI开发范式的核心误区——把大模型当作"更聪明的代码补全工具"。这种理解导致无数团队在落地AI辅助开发时浅尝辄止：写了几条提示词，跑了几个demo，发现效果不稳定，就得出"AI不可靠"的结论。

真正的问题在于：AI辅助开发不是找一个好模型、写一套好提示词就能解决的事。它本质上是一套工程系统的构建问题。就像传统软件开发需要需求分析→架构设计→编码→测试→发布的完整流程，AI辅助开发同样需要一套完整的工程化体系来确保：输入清晰、过程可控、输出可靠。

Harness Engineering的六层架构正是为了解决这个问题。

六层之间的动态关系

很多人误以为六层是静态的六选一，实际上它们是动态串联的关系。让我解释这个串联是如何工作的：

第一层：Rule（工程规矩层） 定义整个系统的基础约束。这不是技术规则，而是"团队纪律"——比如"所有代码改动必须通过编译和测试"、"不允许硬编码UI文案"、"测试数量不能异常减少"。Rule解决的是"什么事绝对不能乱来"的问题，为整个系统划定红线。

第二层：Skill（操作手册层） 在Rule划定的红线内，定义具体操作的标准流程。Rule告诉AI"必须做"，Skill告诉"怎么做"。典型的Skill包括：编译Skill（找MSBuild→输出日志→解析错误模式）、代码审查Skill（扫描特定模式→输出报告）、测试执行Skill（运行测试→收集结果→比对baseline）。

第三层：Sub Agent（角色分工层） 解决的是"复杂任务由谁来处理"的问题。单一Agent容易陷入自解释、自评分、硬推任务的陷阱。通过引入多个专业角色（需求分析Agent、方案设计Agent、开发Agent、QA Agent），每个角色专注于自己的阶段，产出文档化结果交给下一角色，实现真正的接力而非包办。

第四层：Workflow（流程规则层） 定义角色之间的接力规则。关键不是"有四个跑得快的人"，而是"接棒规则明确"。Workflow解决的是：什么时候前进、什么时候暂停、什么时候打回、什么时候重跑。每棒只给当前该看的材料，避免上下文过长导致重点散失。

第五层：Scripts（验证门禁层） 直接检查结果而非告诉AI该怎么做。这是六层中最"硬"的一层，因为Script直接判定对错，不接受解释。比如检查XAML是否存在中文、C#代码是否使用了C#8语法、是否存在MessageBox.Show调用、测试数量是否异常减少。

第六层：MCP（外部接口层） 把AI工作链路延伸到仓库外的能力。没有MCP，AI只能做分析、改代码、跑本地验证；有了MCP，AI可以接入CI系统、触发签名流程、操作制品库、执行发布、回写状态。当Harness从开发闭环扩展到交付闭环时，MCP成为关键瓶颈。

JK Launcher案例的工程启示

JK Launcher是白家杰在文章中给出的真实工程案例，展示了一个Harness从0到1的搭建过程。这个案例的核心启示在于：第一步做什么、按什么顺序逐步补齐。

很多团队在搭建Harness时犯的错误是：试图一步到位构建一个完美的六层系统。结果要么是系统过于复杂难以维护，要么是在某个单点过度设计而忽视其他环节的配合。

JK Launcher的正确做法是：先跑通最小闭环，再逐步补齐层次。具体来说： 1. 先定义最基本的Rule（如"代码改动必须编译通过"） 2. 编写最基本的Skill（如编译执行流程） 3. 用Scripts验证输出是否满足基本门禁 4. 在此基础上逐步引入Sub Agent分工 5. 添加Workflow定义阶段迁移 6. 最后接入MCP对接外部系统

这种渐进式构建的好处是：每个层次都能快速验证效果，一旦某个层次出问题可以立即定位和修复，而不是面对一个庞大的黑箱系统无从下手。

Scripts为何越来越"硬"

文中一个重要趋势值得注意：真正成熟的Harness越来越依赖脚本而非提示词。这背后有一个深刻的工程逻辑：

提示词是软约束，脚本是硬门禁。AI模型的行为有一定的随机性和不可预测性，同样的提示词在不同时间、不同上下文下可能产生不同结果。但脚本检查是确定性的——检查项通过就是通过，不通过就是不通过，不存在中间地带。

这意味着，当Harness进入生产级应用时，Scripts层必须足够硬、足够全面，才能保证输出质量的可控性。典型的高价值检查项包括： - XAML中是否存在中文字符（本地化问题） - C#代码是否使用了版本不兼容的语法 - 是否存在硬编码的UI文案 - 测试数量是否异常减少（可能遗漏测试用例） - .cs文件是否被意外排除在.csproj之外

这些检查项都是规则性的、非黑即白的，任何一条不通过都意味着代码存在质量问题。

实践启示

启示一：从小闭环开始，不要追求一步到位

对于初次接触Harness Engineering的团队，最重要的建议是：从小闭环开始。不要试图一开始就构建一个覆盖所有场景、支持所有工具链的完整系统。

具体的操作建议： 1. 选择一个高频场景：比如代码审查、编译验证、测试执行 2. 定义最基本的Rule：比如"所有代码必须通过编译" 3. 编写最简单的Skill：覆盖这个场景的标准操作步骤 4. 写几个核心Scripts：验证最关键的检查项 5. 跑通这个最小闭环：验证整个流程是否work

只有在最小闭环稳定运行后，才考虑扩展到更多场景、引入Sub Agent分工、添加Workflow规则。一句话：先让系统跑起来，再让系统跑得更好。

启示二：区分软约束和硬门禁，合理分配工程资源

Harness Engineering的六层中，Rule和Skill是软约束，Scripts是硬门禁。理解这个区别很重要，因为它决定了在不同层次上应该投入多少工程资源。

软约束层次（Rule/Skill） 需要投入的是： - 清晰的文档和示例 - 持续的prompt优化 - 上下文管理的维护

硬门禁层次（Scripts） 需要投入的是： - 可靠的检查脚本 - 全面的覆盖范围 - 快速的执行速度

很多团队犯的错误是在软约束层次过度设计（比如花大量时间优化提示词），而忽视了硬门禁层次的建设（脚本不全、执行慢）。结果是：AI输出的质量无法被有效控制，错误漏到生产环境。

正确的做法是：优先建设硬门禁层次。先把Scripts检查项写全面，确保任何明显问题都能被脚本抓住；在此基础上，再优化软约束层次提升AI输出的质量上限。

启示三：Sub Agent分工要克制，Workflow要有明确的接棒规则

引入Sub Agent分工时最常见的过度设计是：为每个小任务都创建一个专门的Agent。结果是整个系统变得过于复杂，Agent之间的通信成本超过实际收益。

正确的做法是： 1. 只在真正需要专业分工的地方引入Sub Agent：比如需求分析和开发执行确实需要不同视角，可以分离 2. 保持Agent数量克制：能用一个Agent解决的问题不要拆成两个 3. Workflow的接棒规则要明确：每个阶段完成什么、交付什么、下一阶段接受什么，都要有明确的文档

"上下文纪律"是关键原则：每棒只给当前该看的材料。不要在交接文档中塞入过多细节，让接棒Agent能够快速聚焦在核心任务上。

启示四：MCP接入要有制度，初期从简单场景切入

MCP是Harness延伸到外部工程系统的关键，但接入MCP必须有明确的制度约束。没有约束的MCP接入会带来安全风险：AI可能触发不应该触发的操作、回写不应该回写的状态。

制度建设包括： - 明确哪些操作可以通过MCP触发 - 明确什么条件下允许触发外部动作 - 明确谁有权限批准MCP接入新系统 - 明确MCP调用的审计和回滚机制

对于初建Harness的团队，建议：初期只在本地验证场景使用MCP，不要直接对接生产系统。等Harness稳定运行一段时间后，再逐步扩展MCP的使用范围。

启示五：持续演进，让Harness跟随团队能力成长

Harness Engineering不是一个"建成即完美"的系统，而是一个需要持续演进的工程系统。随着团队对AI辅助开发的理解加深，Harness的各个层次都需要相应升级。

具体的演进路径： - Rule层：随着团队对常见错误的理解加深，持续补充新的Rule - Skill层：随着高频场景的识别，持续编写新的Skill覆盖这些场景 - Scripts层：随着质量问题模式的发现，持续扩展检查项 - Sub Agent层：随着任务复杂度的提升，考虑引入新的Agent角色 - Workflow层：随着流程优化点的识别，持续调整接棒规则 - MCP层：随着外部系统对接需求的明确，逐步扩展接入范围

演进的关键是：保持系统可测试、可验证。每次调整后都要运行完整的验证流程，确保改动没有引入新的问题。

启示六：Harness不是银弹，理性看待AI辅助开发的天花板

最后需要提醒的是：Harness Engineering是AI辅助开发的工程化保障，但不是银弹。它解决的是"如何让AI辅助开发更可靠"的问题，而不是"AI辅助开发能否解决所有问题"的问题。

AI辅助开发有其固有的局限性： - 对于完全创新、没有历史模式可循的任务，AI难以提供有效帮助 - 对于需要深度业务理解的高层决策，AI只能辅助不能替代 - 对于涉及多方利益协调的组织问题，AI无能为力

Harness Engineering的作用是：在AI能力所及的范围内，通过工程化手段确保输出质量的稳定性和可控性。对于AI能力所不及的领域，还是需要人类来判断和决策。

总结

Harness Engineering的六层架构（Rule/Skill/Sub Agent/Workflow/Scripts/MCP）提供了一套系统化的方法论来解决AI辅助开发的工程化落地问题。这套方法论的核心启示是：AI开发不能只靠提示词，不能把模型当"更聪明的代码补全"。

从实践角度，团队应该： 1. 从小闭环开始，逐步扩展 2. 优先建设硬门禁（Scripts）再优化软约束（Rule/Skill） 3. Sub Agent分工要克制，Workflow要有明确接棒规则 4. MCP接入要有制度，初期从简单场景切入 5. 持续演进，让Harness跟随团队能力成长 6. 理性看待AI辅助开发的天花板

最终，Harness Engineering的目标是：在AI能力边界内，通过工程化手段最大化AI辅助开发的效率和质量；在AI能力边界外，清晰识别需要人类判断的领域并合理分配资源。

相关实体

→ 原文存档