Harness Engineering 实战：从分享经验到工程化约束

灵感来源：4月2日分享《Skill 编排调优技巧与踩坑实战》后的复盘与提炼

核心问题

AI Agent 的能力在飞速提升，但一个尴尬的现实是：模型越强，犯错的「档次」越高。早期模型连 API 参数都填不对，现在模型能写出看起来完美但逻辑有微妙错误的代码。问题不在模型，在环境。

Harness Engineering 的核心主张是：与其花精力优化模型，不如花精力设计环境——让模型在结构化的约束中运行，错误被自动捕获，正确性被自动验证。环境设计 > 模型能力。

从踩坑经验到黄金原则

今天的分享总结了 10 条 Skill 编排调优经验，每一条都来自真实的踩坑教训。但如果只停留在经验分享层面，它们只是「知识」。Harness Engineering 的关键一跃是把这些知识编码成可执行的约束。

经验 1：编排顺序就是安全网

踩坑场景：跳过余额查询直接提交请假，结果余额不足被服务端打回。

传统做法：写在文档里，新人来了读一遍，实战中忘了就犯错。

Harness 做法：把「步骤必须按顺序执行」编码成 Skill 编排的硬约束，任何跳步都会被拦截。这不是文档，是可执行的规则。

经验 2：update 前必须 get

踩坑场景：用旧缓存数据提交，用户中间手动改了值，覆盖掉了。

Harness 做法：数据时效性铁律——任何 write 操作前必须先 read 最新状态。可以编码成「write 前自动触发 read + diff 检查」。

经验 3：只改目标字段

踩坑场景：顺手改了户口所在地（不走审批字段直接生效），用户不知道值被改了。

Harness 做法：字段边界铁律——入参中只包含用户明确要求修改的字段。可以编码成「入参白名单」——不在白名单里的字段自动剔除。

经验 4：混合审批字段必须提示

踩坑场景：走审批和不走审批的字段一起改，不走审批的字段提交即生效，用户以为还在审批中。

Harness 做法：提交前自动检查入参中是否有「立即生效」的字段，有则显式提示用户。可以编码成「字段审批元数据 + 提交前检查」。

Harness Engineering 的三层架构

从上面的例子可以抽象出 Harness Engineering 在 Agent 场景中的三层架构：

第一层：知识层（Knowledge Layer）——踩坑经验、最佳实践、团队共识。这是人类智慧的沉淀，但本身不可执行。
第二层：编码层（Encoding Layer）——把知识转成结构化约束：编排规则、前置校验、字段白名单、时效性检查。这是可执行的规则。
第三层：执行层（Execution Layer）——Agent 在编码层的约束下运行，任何违反都被自动拦截和修正。这是运行时保障。

三层之间有明确的因果关系：没有知识层的踩坑经验，编码层就没有来源；没有编码层的结构化约束，执行层就是裸奔。

关键洞察

知识编码是 AI 工程化的核心能力

在传统软件工程中，架构师的核心能力是把业务需求翻译成技术方案。在 AI Agent 工程中，核心能力变成了把人类经验翻译成可执行的约束。这不是写文档，是写代码——只不过代码约束的对象不是计算机，是 AI。

踩坑成本决定了编码优先级

不是所有经验都需要编码。只有那些「踩了坑会造成不可逆损失」的经验才值得投入编码成本。余额不足→可恢复（撤销重来），但改了不走审批的字段→立即生效不可撤回。后者的编码优先级远高于前者。

渐进式编码：从文档到硬约束

不需要一步到位把所有经验编码成硬约束。一个务实的路径是：1）先写在 SKILL.md 里（软约束，Agent 读了可能不遵守）；2）写入系统文件 AGENTS.md（中约束，每次会话加载）；3）编码成可执行规则（硬约束，运行时拦截）。根据踩坑频率和后果严重性，选择合适的编码层级。

引发思考

这篇分析的价值在于：它把 Harness Engineering 从一个学术概念拉到了工程实践层面。不是在讨论「环境设计比模型能力更重要」这个论断对不对，而是在展示「怎么把这句话落地」。

对行业的启示：AI Agent 工程化的瓶颈不是模型能力，而是「知识编码」的能力。谁能更快地把团队经验转化为可执行的 Agent 约束，谁就能更安全、更高效地利用 AI。这是一个新的工程角色的雏形——Agent Constraint Engineer（Agent 约束工程师）。

对分享者的启示：你的分享经验不只是「知识」，它是 Harness Engineering 的原材料。每次踩坑、每次纠正、每次规则更新，都是在为 AI Agent 积累可编码的知识资产。这比任何 prompt engineering 都有价值。

Harness Engineering 实战：从分享经验到工程化约束