Agent 的能力上限——它能写出多精妙的算法、多优雅的架构——取决于模型本身。这不是你能控制的。但 Agent 的交付质量下限——它会不会静默交付错误代码、会不会绕过约束、会不会虚报完成——取决于流程。这是你能控制的。所以问题的本质是如何把 Agent 交付从不可观测的黑盒变成每一步可追溯、可验证、可回退的工程实践答案是 Harness Engineering——一套四层递进防线。四层递进防线从软约束到硬校验第一层Rules — 告诉它什么必须做Rules 是最直觉的防线把规则写进 .mdc 文件通过 glob 模式限定作用域Agent 在相关上下文中自动加载。比如harness-core.mdc管全局纪律code-standards.mdc管编码规范workflow-discipline.mdc管流程纪律。它们有4种激活模式Always 模式下始终注入上下文。但必须清醒认识到 Rules 的固有局限它是自然语言指令Agent 对规则的遵守度随上下文复杂度而衰减。你写再多规则上下文一长中间部分的规则就像不存在一样。Rules 是第一层防线但不能是唯一一层。第二层Skills — 告诉它具体怎么做Rules 定义了什么必须做但 Agent 经常临场发挥——每次执行的步骤不一样遗漏和偏差在所难免。Skills 把固定步骤封装成 SOPbuild-test构建测试、post-verify事后验证、code-review代码审查、test-e2eE2E 验收、systematic-debug系统化调试。以 Dev 的典型调用链为例先调build-test再调post-verify全部通过才收工。不是我觉得应该这么跑而是必须按这个顺序跑。把临场发挥变成固定步骤这是第二层对第一层的弥补。第三层Agents Workflow — 让它不能自己给自己放行即使有了 Rules 和 Skills如果同一个 Agent 既写代码又做测试自审失效的问题依然存在。第三层引入了 7 个 Agent 角色核心设计是产出者不等于验收者PM是调度中枢只读结论、发 Task、处理回退不写需求、不定方案BA把需求翻译成结构化格式且需求中绝对不允许出现实现层信息SA把需求翻译成技术方案如果发现需求夹带实现层就打回 BARR是开发前最后一道校验检查完整性、纯净度、覆盖度Dev按 TDD 三步法开发先写测试→红→实现→绿→重构CR以需求为基准审查代码但不允许自行修改代码只能 REJECTTE独立跑 4 类测试且不看 CR 的结论写代码的人不能自己判合格判合格的人不能自己改代码。这就是角色制衡。但第三层仍有局限Agent 之间的互审是语义级的无法发现字节级错误比如文件路径写错、版本号不对。所以需要向下递进。第四层Scripts — 退出码说了算Agent 说了不算这是最硬的一层。核心原则交付判定不依赖 Agent 自述依赖程序退出码。三个核心脚本verify.sh— 17 项交付检查分 A/B/C 三类。A 类查代码规范B 类查构建C 类查工程一致性含文档硬校验——架构有变更文档必须同步修订baseline.sh— 开发前拍快照开发后做对比。新增 FAIL 项就阻塞交付check-harness.sh— 80 项框架完整性自检还有一个关键的时序级防护Cursor Hook。Dev 停止时自动跑验证TE 停止时自动跑对比propose 入口拦截脏源码。Agent 忘记跑验证Hook 自动补跑。Agent 试图跳过入口拦截。第四层对第三层的弥补是根本性的它不信任 Agent 会自觉做对而是用退出码做硬判。四层的递进逻辑Rules 设定约束 → Skills 标准化执行 → Agents 角色制衡 → Scripts 硬性验证 (遵守度衰减) (临场发挥→固定步骤) (自审失效) (虚报完成)每一层兜住上一层的漏洞层层递进、层层兜底。三段式研发流程人在关键卡点说不四层防线需要在具体的研发流程中运作。Harness 的流程是三段式propose → apply → archive中间有两道人工审批。propose想清楚再动手propose 段的目的是想清楚BA 把需求翻译成结构化格式SHALL GWTSA 输出技术方案RR 做就绪评审最后人工审批1。这里有一个关键铁律propose 段绝对禁止碰源码。需求没想清楚之前不允许任何人包括 Agent动代码。声明层、Hook、check-harness 三重防护确保这条铁律不被违反。apply按规矩做做完验证apply 段是自动化开发Dev TDD 实现 → build-test Skill 验证 → verify.sh 硬校验 → CR 代码审查 → TE 四类测试 → 人工审批2。每个环节都有明确的验证标准不是 Agent 说完成了就算完成而是退出码为 0、文档齐全、角色交叉校验通过才算完成。archive确认后归档archive 段PM 执行 Spec Merge → 移动 deliverables → 标记 DONE → check-harness 终检。为什么 propose 和 apply 必须隔离这是很多人会问的问题为什么不能让 Agent 一口气从头做到尾因为需求级缺陷不得在 apply 内偷偷修掉。如果 Agent 在写代码时发现需求有问题唯一正确的做法是停下来、打回去、重新走 propose——而不是自己理解一下就继续往下做。propose → apply 的隔离是人对 AI 保持控制权的关键卡点。没有这个隔离Agent 会在你以为它在修 bug的时候实际上在改需求。根据任务复杂度选择流程强度不是所有任务都需要走完整流程。Harness 提供了三档 Profilequickbug fix、纯 UI 小调、文案变更。跳过 RR省 1 个 Task 回合standard默认新功能。走完整 BA → SA → RRrefactor跨域重构。BA 前增加 impact-analysis 阶段拿不准时默认用 standard——宁可过度不可不足。需求描述的革命从口头描述到可验证的结构化规范Harness 在需求描述上做了一件很巧妙的事OpenSpec R/S 体系。Requirement用 SHALL 说话每条需求用 SHALL 关键字表达带一个 R-xxx 编号。强度词分级SHALL强制 SHOULD推荐 MAY可选。关键约束需求中绝对不允许出现实现层信息。不能写使用 Redis 缓存只能写系统 SHALL 缓存用户会话。前者是实现后者是业务意图。ScenarioGiven-When-Then 零翻译成测试每条场景用 GWT 格式描述带一个 S-xxx 编号S-001 Given 用户在登录页面 When 用户输入正确的用户名和密码并点击登录 Then 系统 SHALL 在3秒内跳转到首页GWT 格式的最大价值是需求到测试零翻译成本——Scenario 直接就是测试用例不需要额外的翻译步骤。Specs系统能力的唯一真相.harness/specs/ 始终反映系统当前已部署的全部能力。后续任务不需要从代码逆向推断这个系统到底能做什么直接看 specs 就行。每次交付后BA 声明 Spec DeltaADDED / MODIFIED / REMOVEDPM 在 archive 阶段执行 merge。这是一个完整的闭环。三层不信任叠起来才够用