目录
从旧模式痛点到 Harness 闭环
引言：比的不是模型，是工程系统
一、为什么要变？旧模式的两层天花板
1.1 传统软件开发：人驱动，经验难沉淀
1.2 Copilot++：Agent 裸奔的四类失效
AI 身份与边界如何约束执行
二、新范式是什么？Harness 核心闭环
2.1 四步飞轮：Specify → Execute → Verify → Compound
2.2 五大技术组件
2.3 核心原则
Harness 全景：分层架构 × 自动化工作流
三、Harness 全景：分层架构与工作流如何咬合
3.1 四层架构（L0 → L3）
3.2 自动化开发工作流
AI 能力层：L0 运营组件与 Context 记忆并行
四、AI 能力层：Coding Agent 之下缺的不是工具，是记忆
4.1 顶层：Coding Agent
4.2 左侧：L0 运营组件
4.3 右侧：Context 层（NEW）
Context Engineering：三层记忆 + 五层防漂移
五、Context Engineering 深潜：用工程化记忆对抗 AI 失忆
5.1 三层渐进式加载
5.2 四步使用方式
5.3 五层 Auto-sync
L2 机械化护栏：Verify 如何成为质量门禁
六、How：四条解法与量化成效
6.1 交付：约束 = 生产力
6.2 知识：Repo = 记忆
6.3 验证：机械护栏替代人肉 Review
6.4 进化：错误 = 信号
6.5 量化参考
落地路线图：从 Phase 0 到飞轮转起来
七、落地路线图
Phase 0：先有一条硬护栏（1–2 周）
Phase 1：Context 上库（2–4 周）
Phase 2：执行层标准化（持续）
Phase 3：闭环与 GC（持续）
工程地图
结语：工程师的新分工是设计 Harness，不是堆砌 Prompt
从旧模式痛点到 Harness 闭环
图注：左栏为旧模式两类天花板；中栏为 Harness 四步飞轮；右栏为 How 三条收益，共同指向可规模化的 Agent 交付。
简要说明：模型越来越强，交付却没有等比例变好。根因往往不是 prompt 不够巧，而是 Agent 运行在缺少护栏、缺少记忆、缺少验证的工程真空里。Harness Engineering 把讨论从「谁更会写代码」转向「谁更会设计 Harness」——一套以 Repo 为唯一事实来源、以机械验证为质量门禁、以 Context Engineering 对抗失忆与熵增的工程闭环。
引言：比的不是模型，是工程系统
过去两年，Coding Agent 从补全工具进化到能独立完成多文件改动的执行体。Cursor、Claude Code、Codex、Windsurf 等产品把「自然语言 → 代码」的链路做得越来越短。
但很多团队的体感是反直觉的：长任务做到一半开始跑偏；生成代码能跑，但架构越来越乱；Review 压力不降反升；同类错误在不同迭代里反复出现。
这说明一件事：裸 Agent 的天花板，不在模型能力，而在工程系统。
AI 工程化的核心命题，不是再造一个「更强的 Copilot」，而是构建 Harness——围绕 Agent 运转的工程操作系统。
一、为什么要变？旧模式的两层天花板
1.1 传统软件开发：人驱动，经验难沉淀
在人驱动的开发模式里，架构决策、历史坑点、隐性规范往往存在于资深同学的脑子里、即时通讯的一次性讨论里、没人维护的文档页面里。
结果是：复用成本高、onboarding 慢、同类坑反复踩。 质量高度依赖 Code Review 和 checklist 的「人肉密度」——能撑住一个团队，很难撑住规模化 Agent 产出。
1.2 Copilot++：Agent 裸奔的四类失效
| 问题 | 表现 |
|---|---|
上下文断裂 | 长任务丢记忆，窗口膨胀反而中途失败 |
缺少约束边界 | 无架构护栏，Agent 越界调用、依赖混乱 |
无法「考古」 | 历史教训、隐性规范进不了执行路径 |
熵不可控 | AI 生成物堆积，文档与代码同步腐化，无 GC 机制 |
过渡：如果第一层天花板是「人记不住」，第二层是「Agent 看不见、管不住、忘得快」。Harness Engineering 要做的，就是把知识写进 Repo、把规则写进机器、把错误写进免疫系统。
AI 身份与边界如何约束执行
AI 治理层 → 精准执行 → 预期成果
图注：与「裸 prompt」不同，Harness 在执行前先把身份、边界、拒绝策略工程化；执行不是自由发挥，而是在治理约束下的精准交付。
二、新范式是什么？Harness 核心闭环
2.1 四步飞轮：Specify → Execute → Verify → Compound
- Specify（定意图）：把「要做什么」写成可执行的 Spec / PRD / 约束
- Execute（执行）：Agent 在 Harness 内调用 Skill、MCP、脚本生成与修改代码
- Verify（验证）：Linter、结构测试、CI 门禁做机械化验收
- Compound（沉淀）：把经验、规则、上下文回填 Repo，形成永久免疫力
验证失败时，箭头应回到 Specify 或 Harness 本身——不是默认「再跑一遍 Agent」，而是定位缺口、补约束、补上下文、补工具。
2.2 五大技术组件
- Context Engineering：分层知识库 + 路由表，渐进加载
- Architectural Constraints：Linter、结构测试、依赖分层等机械护栏
- Entropy Management：GC Agent 定期巡检，对抗文档/代码腐化
- Feedback Loops：Hooks、CI/PR、自验证，让错误成为信号
- Tool & Data Access：MCP 统一协议 + 可观测性
2.3 核心原则
Repo = Single Source of Truth
Agent 看不见的不存在；Agent 违反的不合入。
Harness 全景：分层架构 × 自动化工作流
图注：左侧为四层 Harness 能力；中部为任务流转；Verify 失败不走「重试 prompt」，而是经反馈循环回填 L1/L2/L3；GC Agent 全局对抗熵增。
三、Harness 全景：分层架构与工作流如何咬合
3.1 四层架构（L0 → L3）
| 层级 | 名称 | 职责 |
|---|---|---|
L0 | Human Engineer | 设计意图、定义约束、提供反馈——不写代码 |
L1 | Context Engineering |
|
L2 | Architectural Constraints | Custom Linter、Structural Test、CI Gate、Rules |
L3 | Execution Infrastructure | Skills、Commands、MCP、Scripts、Hooks |
贯穿全局的还有 Entropy Management（GC Agent）：定期巡检、文档清理、约束更新、代码 GC。
L2 要点：不是 README 里的「建议」，而是 CI 里的 No。Custom Linter 让报错即教学；Structural Test 守住依赖分层；CI Gate 硬拦截；Rules 与代码同版本。
3.2 自动化开发工作流
任务输入 (L0)
→ Context 加载 (L1)
→ PRD & Brainstorm (L3)
→ Agent 执行 (Skill → MCP → Scripts)
→ Verify (L2)
→ PR / 自动 Review
→ Compound 回填 L1
过渡：闭环和全景回答了「系统长什么样」。下一问是：Coding Agent 之下，能力层具体怎么长？答案是——在传统 L0 能力层之外，并行补上 Context 层。
AI 能力层：L0 运营组件与 Context 记忆并行
图注：仅有 Agents/Skills/MCP 解决「能做什么」；并行建设 Context 层，才解决「这个项目记得什么」。
四、AI 能力层：Coding Agent 之下缺的不是工具，是记忆
4.1 顶层：Coding Agent
Cursor、Claude Code、Codex、Windsurf 等是编排入口——接收任务、规划步骤、调用下层能力。它们强在推理与执行，但不等于工程系统本身。
4.2 左侧：L0 运营组件
| 组件 | 作用 | 示例 |
|---|---|---|
Agents | 角色化子 Agent | Architect、Code-reviewer、Tdd-guide |
Commands | 任务指令集 |
|
Rules | 行为治理 | Coding-Style、Git-workflow、Security |
Scripts | 自动化脚本 | Hooks 脚本、工具脚本 |
Skills | SOP 知识单元 | Tdd-workflow、Security-review |
Hooks | 事件触发 | pre-commit、CI/PR |
MCP | 统一工具协议 | GitHub、Filesystem、Database |
4.3 右侧：Context 层（NEW）
.context/
├── constitution.md # 原则 + 路由表
├── architecture/ # 技术架构
├── business/ # 业务领域
├── experience/ # 踩坑教训
└── Auto-Sync # 防漂移
双箭头含义：没有 L0，Context 无法被执行；没有 Context，L0 在陌生项目里等同失忆。
Context Engineering：三层记忆 + 五层防漂移
图注：热/温/冷三层控制 Token 预算；路由表决定「本次加载什么」；五层 Sync 保证 Context 与代码同步演进。
五、Context Engineering 深潜：用工程化记忆对抗 AI 失忆
5.1 三层渐进式加载
| 层级 | 名称 | 策略 | 内容 | 规模参考 |
|---|---|---|---|---|
Tier 1 | 热记忆 | 始终加载 |
| ~150 行 |
Tier 2 | 温记忆 | 按任务加载 |
| 200–500 行/文件 |
Tier 3 | 冷记忆 | 按需加载 |
| 不限 |
5.2 四步使用方式
- 复制
.context/、AGENTS.md等到项目根 /bootstrap-context扫描仓库、生成初版上下文- Agent 读路由表，只拉当前任务相关文件
- Hooks + CI + 定期对账，防止漂移
5.3 五层 Auto-sync
Context 写一次不够。代码在变，Context 不变，就会从资产变负债。 五层机制从「每会话入口」到「每周全量对账」，打断「漂移 → 质量下降 → 更难维护」的恶性循环。
过渡：Context 解决「看得见」；L2 解决「做错了进不来」；L3 解决「手够得着」。三层齐备，才构成可运行的 Harness。
L2 机械化护栏：Verify 如何成为质量门禁
图注：L2 不是软性建议，而是合入前的强制关卡；失败不触发「重试 prompt」，而触发 Harness 回填。
六、How：四条解法与量化成效
6.1 交付：约束 = 生产力
缩小搜索空间，提升 Agent 输出质量与一致性。有边界的 Agent 比裸奔 Agent 更稳。
6.2 知识：Repo = 记忆
版本化的.context/、Rules、Skills 替代口口相传。人机读同一套 Repo。
6.3 验证：机械护栏替代人肉 Review
Linter + 结构测试 + CI 拦截机械性问题，人审意图与权衡。
6.4 进化：错误 = 信号
Agent 犯错 → 定位缺口 → 回填 Harness → 永久免疫。
6.5 量化参考
| 案例 | 数据 |
|---|---|
OpenAI 相关实践 | 5 个月 3→7 人，约百万行代码，手写接近 0 |
LangChain（同模型） | 成功率 52.8% → 66.5% |
TerminalBench 2.0 | Top 30 → Top 5 |
落地路线图：从 Phase 0 到飞轮转起来
图注：先有一条红线能拦住，再建记忆，再标准化执行，最后跑通闭环与 GC。
七、落地路线图
Phase 0：先有一条硬护栏（1–2 周）
- 选 1 条最高频架构违规，写 Structural Test + CI 硬拦截
- 建
AGENTS.md与最小constitution.md（含路由表骨架）
Phase 1：Context 上库（2–4 周）
/bootstrap-context生成architecture/、business/、conventions/- 接入 pre-commit + PR 校验
Phase 2：执行层标准化（持续）
- 高频任务沉淀为 Skills / Commands
- 关键系统接 MCP；Hooks 串联写后检查
Phase 3：闭环与 GC（持续）
- Verify 失败走回填 SOP
- 定期 GC：过期 experience、僵尸 Rules
工程地图
图注：治理层约束执行；L1/L2/L3 分工协作；Repo 居中；Verify 失败走回填；GC 对抗腐化——这是全文架构图合一后的「工程地图」。
结语：工程师的新分工是设计 Harness，不是堆砌 Prompt
全文八张流程图，串起同一条叙事链：
| 图序 | 回答的问题 |
|---|---|
① | 为什么要从 Copilot 走向闭环 |
② | 治理层如何约束「精准执行」 |
③ | Harness 分层与工作流如何咬合 |
④ | L0 能力与 Context 记忆为何必须并行 |
⑤ | Context 如何分层加载与防漂移 |
⑥ | L2 如何把 Verify 变成硬门禁 |
⑦ | 团队如何分阶段落地 |
⑧ | 全图合一后的工程飞轮 |
一句话收束：
Harness Engineering 不是更好的代码生成器，而是围绕 Agent 的工程操作系统。
Repo 是唯一事实来源，机械护栏是质量门禁，Context Engineering 是对抗失忆与熵增的基础设施。
模型会换代，写在 Repo 里的约束、上下文和教训会留下。
