Harness 工程与 AI 工程技能学习笔记
综合 2026-08-23 抓取的四篇文章（千问 AI 平台 Harness 六支柱 / Andrew Ng AI 工程技能图谱 / 阿良单人 AI-native SDLC / Miles Ma Codex 教程）+ Oh My KB 已有知识库整理。
Harness Engineering
AI Engineering Skills Map
Multi-Agent 架构决策
单人 AI-native SDLC
2026-08-23
一、三层范式演进（地基）
一句话总纲：模型决定上限，Harness 决定下限。AI 工程的核心战场已经从"怎么把话说清楚（Prompt）"、"怎么喂对信息（Context）"，转移到"怎么让 Agent 的能力以可控 / 可预测 / 可信任的方式发挥出来（Harness）"。
| 阶段 | 解决的问题 | 天花板 |
|---|
| Prompt Engineering | 怎么让模型理解我想要什么 | 假设只跟模型聊一次，问完即走 |
| Context Engineering | 怎么让模型看到该看的、不被无关信息干扰 | 硬编码规则限制 Agent 自主性 |
| Harness Engineering | 怎么让 Agent 能力以可控 / 可预测 / 可信任的方式释放 | 当前阶段，尚无更高共识范式 |
核心公式：Agent = Model + Harness。Harness Engineering 本身有更凝练的两步公式——先放手（给 Agent 完整工具集和反馈通道，让其自主判断）、再上保险（框定能力边界，确保不失控）。
定量验证
同模型同 Prompt，只换 Harness 配置，任务成功率可从 42% 跃升至 78%（Epsilla）；同一模型不同 Harness 下 solve rate 差异超 60pp（LangChain Terminal Bench 2.0）。
二、Harness 六支柱（千问 AI 平台）
三层架构：身份层（执行前的静态约束）→ 执行层（执行时的动态决策）→ 进化层（执行后的经验沉淀），螺旋上升。
| 支柱 | 定义 | 核心机制 |
|---|
| Identity | 谁有什么能力、什么绝对不能做 | 三层金字塔：超级红线（少而精）> 结构化错误记录 > 操作规则 |
| Orchestration | 按什么顺序执行 | 链路 / 单点双模式并存；无依赖并行、有依赖串行；修改分三级匹配流程重量 |
| Context | 什么信息在 Agent 间流动 | 阶段切分 + CP 检查点摘要 + 渐进式加载 + Spec 文件驱动 |
| Gate | 做得好不好 | 生成者与评估者物理分离；强制检查项不给 Agent"我觉得不需要"的权力 |
| Recovery | 当前在哪、出错怎么恢复 | 显式状态机（12 状态枚举）+ 三档故障分级（可重试 / 需回退 / 必须中止） |
| Evolution | 错误怎么变成经验 | 结构化记录 + 实时触发 + 自动加载 + 约束迭代 |
⚠️ 争议点（已核实）
Context 支柱的"CP 检查点强制压缩"，按已有知识库中「多 Agent 协调模式」概念的关键区分表，实际上落在"三省六部式传文件"（上游写、下游不同角色读、内容是压缩结论 → 推理链断裂）而非"显式外部状态文件"（同一执行体跨 session 读写完整日志 → 推理链连续）一侧——换了个文件载体，没有真正解决信息衰减问题。这套架构合理，但前提是"阶段边界天然清晰、可结构化验证"的场景，不是 Multi-Agent 的万能模板。
三、AI 工程技能图谱（Andrew Ng）
四大顶层技能：构建部署 AI 应用 / 软件工程基础 / 使用 Coding Agent / 塑造构建（Shaping the build）。
"构建部署 AI 应用"展开的六个子技能：
- LLM foundations — tokenize / 生成机制、上下文窗口取舍、cache / reasoning effort / tool calling
- Grounding models with data — 从早期 RAG 扩展成技术菜单：塞进 prompt vs 按需检索、向量索引 / 知识图谱 / 结构化语义层三种表征选型
- Building agentic systems — 光谱从"预定义 workflow"到"agent harness 自主决策"，何时上 multi-agent orchestration，guardrails / adversarial input / data exfiltration 风险
- Evaluation-driven development — 作者称"决定谁擅长构建 AI 系统"的最重要特质：何时用确定性评测 / LLM-as-judge / human-in-loop，还要"评估你的评估"
- Operating in production — 可观测性追踪 drift、应对 adversarial prompt injection、回归测试需要比传统软件更多统计评估
- Machine learning foundations — bias / variance、error analysis、数据工程，是驾驭不确定性输出系统的底层心智模型
四、Multi-Agent 架构决策清单
反模式：三省六部式角色分工
PM / 架构师 / QA / Dev 式流水线——LLM 没有人类的注意力瓶颈 / 专业壁垒，强行贴角色标签只会封死边界处最有价值的推理；且信息在交接中被压缩成结论，推理链断裂，工作流越长偏移越大。
正确原则（Anthropic / OpenAI / Google 共识）
- 推理链只能分叉再合并，不能断
- 显式外部状态（progress.txt / git / spec），不靠模型"记住"
- 多 Agent 价值在并行覆盖，不在分工合理——token 消耗量能解释 80% 性能差异
- 验证 Agent 是否定者，不是接棒者
- 工具 > 角色标签
反向校准（TiDB / siddontang）
能单 Agent 干完就单 Agent 干，实在要拆最多一个 Coordinator + 几个边界清楚的 Agent；五大代价——通信 / 状态 / retry / context 丢失 / 责任归属，通常多花约一倍 token。
任务类型选择
| 任务特征 | 架构选择 |
|---|
| 连续推理 / 高上下文依赖 | 单 Agent + Context Engineering |
| 多方向并行探索（子任务相互独立） | 多 Agent 并行 |
五、单人场景 AI-native SDLC 自查（阿良）
Anthropic 企业级手册六阶段核心只有一条机制：每阶段产物进版本控制，下阶段读它才开始（committed artifact：intent.md → spec.md → plan.md → 代码+测试 → PR+审查 → 事故记录）。
能直接抄的三样
- 每阶段留一份进版本控制的文件
- 动手前写下要证明什么（防事后合理化）
- 检查脚本必须验证会失败（造错误样本喂进去，确认真报错再确认转绿）
结构性抄不了的两样
- 双向审查（没有第二个人，堆检查次数是弱替代不是等价方案）
- 自动化写回（监控异常自动触发下一轮，单人系统通常没有持续监控层）
六个自查问题
- 每阶段有没有留文件，下阶段读它开始？
- 动手前有没有写"怎样算成功"？
- 规则是文件还是习惯（换电脑 / 新会话还生效吗）？
- 自动检查会失败吗（造错误样本测试过吗）？
- 谁在关卡那一头（是自己就承认，别假装等价）？
- 发现问题后改的是这一次还是规则？
六、关联与来源边界
六支柱框架 = Harness Engineering 的产品级实例；Evaluation-driven development = Gate 支柱的具体化；单人 SDLC 的 committed artifact = Context 支柱 Spec 文件驱动在个体场景的应用；Multi-Agent 架构决策清单是 Orchestration 支柱的深化和纠偏。
📚 vault：Harness Engineering / 多 Agent 协调模式 / 评估驱动开发 (EDD) 三个概念页均为真实读取；三省六部反模式定义、正确架构原则、TiDB 反向校准均直接引自文件原文，非训练知识回忆。
🧠 推断：六支柱 Context 支柱的"三省六部风险"判断、六支柱与 Andrew Ng 技能图谱 / 单人 SDLC 之间的映射关系，为本次综合整理，非某一篇原文明文写出的结论。