Harness Engineering — 数据研发 Multi-Agent 架构实践
Harness Engineering — 数据研发 Multi-Agent 架构实践
原文：阿里技术 — 数据研发Multi-Agent架构的Harness工程实践 关键词：Harness Engineering, Multi-Agent, 约束体系, Orchestrator+Specialist, Spec文件驱动
核心公式
Agent = Model + Harness模型定上限，Harness 定下限模型再强，没有 Harness 兜底，照样不敢放进生产系统。反过来 Harness 做得好，哪怕模型差一点，也能跑出靠谱的产品。
AI 工程范式三代演进
| 代次 | 范式 | 核心问题 | 局限 |
|---|---|---|---|
| 第一代 | Prompt Engineering | 怎么让模型理解我想要什么 | 只适用于单次问答，长程任务不够 |
| 第二代 | Context Engineering | 怎么让模型决策时看到该看的 | Agent 仍会在某些路径犯低级错误 |
| 第三代 | Harness Engineering | 怎么让 Agent 可控制、可预测、可信任 | 工程投入大，需要持续迭代 |
三大分层 + 六大支柱
身份层 (Identity) — 「谁、能做什么、绝不能做什么」
角色定义：采用 Orchestrator+Specialist 架构。协调者不写代码，只负责调度、把关、评审、汇报；子专家各司其职（需求拆解、方案设计、SQL开发、测试验证）。
约束分层（三层金字塔）：
- 超级红线（违反即事故）——Human in the loop、禁止编造数据、禁止越界调用、信息分舱隔离
- 错误记录（历史教训）——格式化记录踩坑史，强制回顾
- 操作规则（最佳实践）——知识库检索流程、文档模板等
执行层
Orchestration（流程编排）：
- 机器自动完成埋点、版本检查、MCP依赖检查等机械环节
- 三种执行路径：全链路（新需求）→ 快案（需求清晰）→ 快码（口头需求直接写）
- 无依赖并行 + 修改三级自适应（轻量改主Agent直接改，中等改调子专家，重大改走全链路）
Context（上下文工程）：
- 流程阶段切分：只有跑到那一步，才读那一步的东西
- CP 检查点摘要：每阶段结束强制压缩为固定格式摘要，不透传对话历史
- 渐进式加载：涉及哪类规范才读哪个文件（核心层+详情层两级）
- Spec 文件驱动：Agent 之间靠写结构化文件传信息，不靠对话历史
Gate（门禁检查）：
- 关键路口设卡（MCP可用性、Agent产出review、SQL语法校验等）
- 取消 Agent 「我觉得不需要检查」的权力——必须检查
- 生成评估分离：子专家产出 → 协调者拿 checklist 验收
Recovery（故障恢复）：
- 12 个明确的状态枚举值，状态追踪文件持久化
- 三级故障：可重试（自动自愈）→ 需回退（退到上一存档点）→ 必须中止（坦诚告知用户）
- 协调者身上挂「重试员」角色专职恢复
进化层 (Evolution)
- 每个专家 Agent 有自己的「踩坑记录本」（编号 + 日期 + 一句话错误描述 + 正确做法）
- 实时记录 → 自动加载到上下文 → 反复出现的错误升级为红线
- 让错误成为系统进化的燃料
实践启示
- 【马上能用】：约束分层设计（红线→错误记录→规则），在任何 Agent 系统中都可移植
- 【马上能用】：Spec 文件驱动 Agent 协作，不挑模型不挑框架，可追溯可审计
- 【避坑】：不要让一个 Agent 干所有事；不要让它决定「要不要检查」
- 【避坑】：修改不能一刀切全走重流程，按影响范围分级
未来判断
两条路径并存：
- 路径一（当前）：Harness 成为 AI 时代的 DevOps，沉淀方法论+标准+工具链
- 路径二（长期）：最终被更强的模型原生能力吸收消解
短期积累工程能力，长期保持模块化让每个支柱可独立移除。