Harness Engineering 真正开始落地时，为什么一定会长出分层

Harness Engineering 真正开始落地时，为什么一定会长出分层

这段时间 Harness Engineering 被提得很多，但不少讨论还停在理念层。大家都知道 AI 开发不能只靠一段 prompt，也不能把模型当成更聪明的自动补全。真正麻烦的地方是，项目一旦往前做，问题就不再是“模型会不会”，而是“它会不会每次都按同一套方式做”。这时候你会发现，所谓 Harness，并不是一个额外的新名词，而是工程现场迟早会长出来的一组层。

先长出来的通常不是 Agent，而是规矩。很多团队一开始会兴奋地写 Sub Agent、接 MCP、配 workflow，最后越做越乱，原因往往不是功能不够，而是底线没立住。哪些文件不能乱改、改完以后哪些验证必须跑、什么情况下必须停下来等人确认，这些东西不先写清楚，后面所有自动化都会变成把不稳定放大。规则看起来不酷，但它负责把混乱压住。

再往下一层，才是固定动作。真正做过项目的人都知道，很多动作表面上看是“去编译一下”“去跑测试”“去查日志”，实际每一步都带着环境、顺序、输出位置和后续判断。你如果每次都让 AI 临场发挥，它当然有机会做对，但也会不停地换一种做法。这个时候就会长出 skill、脚本模板或者命令封装。它们的作用不是让模型更聪明，而是让高频动作别每次都重新猜。

分工也会比很多人想得更早出现。一个 Agent 从头包到尾当然很省事，但任务一复杂，它就会同时扮演需求方、方案设计、开发、QA 和 reviewer。这个结构在人类团队里本来就容易出问题，放在 AI 身上只会更明显。所以很多项目走到后面，都会开始把分析、实现、审查、验证拆开。名字可以叫 Sub Agent，也可以叫 worker、reviewer、planner，本质都一样，是把不同判断放回不同角色，减少同一个执行者自己给自己打分的情况。

工作流这一层更像接力规则。不是有几个人干活就叫有流程，而是要把谁先上、什么时候交棒、哪种情况必须打回、打回以后回到哪一步重新做写清楚。AI 项目里这一层特别容易被忽略，因为大家会下意识觉得模型已经够灵活了，流程别写太死。现实通常相反，越是灵活的系统，越需要把前进、暂停和重跑条件写明白，不然最后谁都在做事，却很难说清楚一件事到底做到哪了。

MCP 则是更靠外的一层。很多人一听到 Harness 就先想到 MCP，其实它更像连接层，不是主体。它负责把仓库之外的系统、数据、工作流和工具接进来，但什么时候该接、接到什么粒度、能做读还是能做写，还是要被前面的规则、技能和门禁管住。没有这些约束，MCP 很容易从能力增强变成风险扩散。

所以 Harness Engineering 真正落地时，一定会长出分层。先有底线，再有固定动作，再有分工和流程，最后才是更大的外接能力。它看起来不像一个炫目的新功能，更像项目做着做着不得不补上的骨架。也正因为这样，Harness 真正值钱的地方不在概念，而在它能不能让 AI 在项目里持续、稳定、可复查地做事。