AI 工程的下一个战场：Harness Engineering 全景解析

最近有一个词在 AI 工程圈里频繁出现：Harness Engineering。

如果你没听过这个词，不奇怪——它还很新。但如果你现在在构建任何 AI 系统，或者你的团队正在评估如何把 LLM 引入真实业务，你迟早要面对它解决的那些问题：Agent 出错怎么办？上下文怎么组织？工具调用怎么管控？知识怎么沉淀？执行怎么可追溯？

这篇文章是我对这个话题的系统梳理，试图把当前业界最前沿的工程实践，翻译成一套可以落地的认知框架。

一、三次范式跃迁：从"对模型说话"到"给模型搭脚手架"

要理解 Harness Engineering 是什么，得先搞清楚它从哪里来。

AI 工程的演化，大概经历了三个阶段，每个阶段的核心问题都不一样。

第一阶段：Prompt Engineering（2022–2024）

这个阶段的核心问题是：怎么和模型说话？

模型能力还在成长期，输出质量高度依赖你怎么写指令。Few-shot 示例、Chain of Thought、Role Setting——工程师花大量时间打磨 Prompt，因为同一个问题，措辞不同，输出可以差距悬殊。

这个阶段的工程师，更像是在学一门"与 AI 沟通的艺术"。

第二阶段：Context Engineering（2025）

模型变强之后，瓶颈转移了。

当模型本身足够聪明，影响输出质量的关键因素不再是你怎么说话，而是你给它看什么。私域知识、垂直领域信息、历史对话记录——这些必须有效组织后才能传递给模型。谁的上下文质量高，谁的 AI 就更聪明。

Anthropic 的 Claude Code 源码里有一句话被很多人引用：Context Engineering 的重要性大于 Prompt Engineering。这不是夸张，是对工程实践的如实描述。

Context Engineering 要解决的核心问题：

• 渐进式加载：不把所有信息一股脑塞进去，而是按需、按阶段加载
• 避免 Lost in Middle：模型对上下文中间位置的信息注意力较弱，重要信息要放对位置
• 知识分类存储：不同类型的知识（用户偏好、项目规范、外部资料）要分开管理

第三阶段：Harness Engineering（2026 起）

Harness 这个词来自驾驭马匹的缰绳系统。引申到 AI 工程，它的含义是：给 Agent 搭一个可控的脚手架，让它在有护栏的环境里自主运行。

核心问题从"怎么说话"、“给什么信息”，变成了：怎么让 Agent 稳定、可靠、可追溯地自主工作？

OpenAI、Anthropic、Cursor 分别从不同角度定义了这个概念：

• OpenAI：关注人机交互层的瓶颈。多个 Agent 并行跑起来后，人 review 不过来，人成了最大的吞吐量瓶颈。
• Anthropic：关注 Agent 长时间运行的稳定性。怎么在跑几个小时后依然可靠？怎么管理运行时产生的纠缠状态？
• Cursor：侧重代码自治和 Agent 规模化扩展。

三家的定义各有侧重，但有三个共识：

1. 程序级约束 > 语言 Prompt：代码结构约束比自然语言指令更可靠
2. 完美主义是吞吐量的敌人：不能要求每个输出完美，要追求系统整体能处理的信息量最大化
3. 环境应为 Agent 设计，而非为人设计：所有工作应最大化 Agent 的效果，让人提供有效反馈

▲ AI 工程范式的四个演化阶段：Prompt → Context → Harness → Environment

还有人提出了下一个可能的演化方向——Environment Engineering：不再只是控制单匹 Agent，而是构建整个"交通体系"——围栏、道路、红绿灯，让环境本身具备确定性，以承载大规模 Agent 并行运行。类似自动驾驶领域的 V2X（车路协同）。这个方向目前还在概念阶段，但方向感是对的。

二、解剖 Claude Code：一个 Harness Engineering 的标杆实现

Anthropic Claude Code 的源码泄露，给了整个行业一个难得的机会，直接看顶级团队是怎么实现 Harness 的。

多层记忆系统

Claude Code 没有把记忆当成一个单一的文件或数据库来处理。它明确把记忆分成三类：

• 用户偏好记忆：跨会话的个人习惯、语言风格偏好
• 项目级全局记忆：项目规范、代码风格、架构决策
• 外部引用知识记忆：文档、API 说明、第三方资料

三类记忆各自独立存储，独立触发条件，独立管理策略。这不是过度工程——这是真实需要。不同的记忆有不同的生命周期、不同的更新频率、不同的访问模式。混在一起反而会互相干扰。

记忆整合机制（“晚上做梦”）

对话过程中会产生大量零散信息：这次用户说要用 tabs 不用 spaces，上次说函数命名要用驼峰，还有一次提到不用 Lodash……

这些信息如果直接堆积，上下文会越来越臃肿，还会产生矛盾和重复。

Claude Code 的解法是：通过后台进程在不活跃时自动激活，对历史信息进行整理——去重、丢弃过时的、合并相关的——形成精炼的新记忆。这个机制被形象地称为"晚上做梦"：就像人类睡眠时的记忆固化过程，把短期记忆转化为长期记忆。

Prompt Cache 机制

对重复或相似的提示词请求进行缓存，降低 token 消耗，提升响应速度。在大规模使用场景下，这不是优化项，而是成本控制的必要手段。

Sub-agent 上下文隔离

子 Agent 之间做严格的上下文隔离。这解决了两个问题：一是信息串扰（A 任务的上下文不应该影响 B 任务的判断）；二是上下文膨胀（子任务不需要父任务的全部历史，只需要相关部分）。

6 层安全防护

源码中对 API 来源验证做了 6 层纵深防御：

1. 编译期死代码消除
2. DRM Attestation
3. 消息指纹
4. 反蒸馏体系
5. 反调试与 Token 保护
6. Gateway 检测

这些细节只有在源码级别才能看到，反映了 Anthropic 对安全工程的极高重视程度。

▲ Claude Code 源码中体现的 6 大核心 Harness 机制

三、Harness 的分层架构模型

如果要用一个统一的框架来描述 Harness Engineering，我认为可以分成三层：

传统 Agent = LLM + Memory + Action

Harness Agent = LLM + Harness
              （Harness 统一协调 Memory / Action / 编排 / 反馈 / 安全）

信息层

目标：让模型知道"有什么"和"能做什么"

包含内容：

• Memory 系统（分层记忆）
• Context Engineering（上下文组织与加载策略）
• Skill/Tool 的静态描述（工具的能力说明本身，属于信息）

信息层的核心挑战是质量而非数量。把所有相关信息都塞进去不是答案，甚至会适得其反。关键是：在正确的时机，把正确的信息，以正确的格式，放到正确的位置。

执行层

目标：把决策转化为可靠的行动

包含内容：

• 工具调用（函数调用、API 请求、代码执行）
• 编排（任务分解、子任务调度、并发控制）
• 运行环境（沙箱、资源管控、超时机制）
• 安全边界（权限最小化、危险操作拦截）
• 故障恢复（重试策略、降级方案、错误传播控制）

执行层是最容易出问题的地方。模型决策可能正确，但执行环节的任何一个细节出问题，都会导致结果不可靠。

反馈层

目标：让结果可信、可追溯、可解释

包含内容：

• 结果评估（输出是否满足预期）
• 验证机制（多模型交叉验证、规则检查）
• 可观测性记录（执行链路日志、状态快照）
• 行为溯源（出问题能找到是哪一步出的偏差）

反馈层是建立信任的基础。模型是概率性的，你没办法保证每次输出都对，但如果整个执行过程是可见的、可回放的，即便某步出了偏差，也能快速定位和修复。

核心公式：

模型决定"如何思考"，Harness 决定"看到什么、用什么工具、出错怎么办"

▲ Harness 分层架构：信息层 / 执行层 / 反馈层，以及各层的核心目标

四、确定性 vs 不确定性：Harness 要解决的根本矛盾

有一个问题很值得深思：传统软件框架约束的是确定性系统中人的行为；但 Harness 要约束的是概率性的 AI——这从根本上就是矛盾的，该怎么处理？

传统软件的确定性

传统程序有可重入性：同样的输入 + 同样的上下文 = 确定的输出。程序逻辑固定，执行路径可预测，测试可以覆盖所有分支。

AI 系统的概率性

大模型的幻觉、不确定性，不是 Bug，是本质属性。即使是最强的模型，给定完全相同的 Prompt，多次运行也可能得到不同的结果。

Harness 的解法：可追溯性建立信任

Harness 不承诺消除不确定性——那做不到。真正可行的目标是：通过全程可追溯，让整体结果获得足够的信任度。

“只有可以被看见的，才可以被信任。”

从问题输入，到模型理解、任务拆解、行为转化、工具调用、结果输出，整条链路如果都是可见的、可回放的，那么即便某步出了概率性的偏差，也能快速定位和纠正。

这意味着 Harness Engineering 的一个核心设计原则是：可观测性优先。不是出了问题再去查，而是从设计阶段就把可观测性当成一等公民来对待。

五、知识工程：模型越强，它越重要

这是我认为整个 AI 工程话题里最被低估的部分。

为什么知识工程是护城河

有人问：AI 越来越强的时代，什么是不变的护城河？

答案不是模型（都在用 API），不是 Prompt 技巧（可以复制），而是企业在垂直领域的知识积累深度。

原因很直接：通用大模型掌握的是公开知识，但企业竞争力来自私域定义、隐性规则、历史决策。模型智力达到临界点之后——而这个临界点，很可能已经过了——谁在垂直领域的知识沉淀更深，谁就能让 AI 产出更好的结果。

隐性知识的价值

举一个很具体的例子：

假设代码里处理了三种账号类型（A/B/C），逻辑看起来完全没问题，AI 审查也通过了。但如果你的业务知识告诉你，账号类型总共有五种——那缺失的两种就是潜在的 Bug。

这种知识，通用模型永远学不会，因为它是你公司内部的私域定义，从没出现在任何公开资料里。

这就是隐性知识的价值——它不在代码里，不在文档里，它在人脑子里。而一旦人离开，这些知识就消失了。

知识漏斗：真正的损耗在哪里

有一个"信息漏斗"的模型值得仔细思考：

脑子里想的
    ↓（大量信息没被表达出来）
说出来的
    ↓（大量口头表达没被记录）
写下来的
    ↓（大量文字没被结构化）
被 AI 可以使用的知识

今天所谓的知识工程沉淀的，都是整个漏斗最下游的那一点点东西。越往上游，信息量越大，但损耗也越大。如果这些东西都没有系统地沉淀下来，所谓的"AI 复利效应"就无从谈起。

三种知识结构与存储策略

知识按结构可以分成三类，每类需要不同的存储方式：

在当前实践中，Markdown + JSON 是最务实的选择。上下文窗口仍然昂贵，多模态成本更高，纯文本摩擦最低、组织最灵活。这不是最优解，而是"没有办法的办法"中最好的那个。

Local First 原则

在知识沉淀的实践上，有一个值得坚守的原则：Local First，纯文本优先。

不在快速变化的线上产品中沉淀核心上下文——因为 AI 工具还处于早期阶段，产品形态变化太快，今天用的工具明天可能就换了。把核心知识分散在各处的线上工具里，摩擦成本极高。

本地存储的纯文本文件，才是最稳定、最可控、最容易迁移的知识载体。

▲ 知识信息漏斗：从脑子里想的到 AI 可用的知识，层层损耗

六、“开发变便宜了"是一个危险的幻觉

现在流行一种叙事：AI 让开发成本大幅下降了，人力可以大幅缩减了。

这个判断需要非常小心。

局部优化 ≠ 全局优化

AI 确实让代码生成变便宜了。一个需求，过去需要工程师写几个小时，现在可能十几分钟就有初稿。

但软件工程不只是代码生成。还有：

• 代码审查：AI 生成的代码看起来功能正确，但可能隐含安全漏洞、性能问题、技术债务
• 测试与验证：生成越快，需要验证的就越多
• 维护与迭代：0→1 的阶段感觉飞速，但产品迭代三年后，如果上下文工程做得不好，AI 根本改不动
• 认知成本：发现一个问题，需要把 AI 生成的全部代码都过一遍，人的认知负担反而上升了

复杂性没有消失，只是转移到了别的地方。局部的优化不等于全局的优化，“出来混早晚得还”。

让一线工程师大规模滥用是一种风险

有一个具体的风险值得警惕：让一线工程师大规模使用 AI Coding 工具，但不建立相应的审查机制和质量管控体系——这种做法在短期内看起来效率很高，但生产级大型事故的风险正在累积。

AI 生成的代码质量参差不齐，有时候能跑通但存在边界 Case 没处理，有时候依赖了不应该引入的第三方库，有时候在并发场景下有竞态条件……这些问题，在简单的 0→1 项目里不明显，在复杂的生产系统里会以各种意想不到的方式爆发。

正确的用法：脚手架由人搭，砖头交给 AI

理解了这个问题，正确的用法就清楚了：

人的责任是架构设计：把整个系统拆解到类级别、函数级别，明确每个模块的边界、接口和约束条件。脚手架是人搭的，而且最好是细粒度的脚手架。

AI 的职责是实现细节：具体的函数实现、模板代码、重复性工作——交给模型。

这样即使模型在某个细节上出了偏差，不影响整体架构的正确性。你的能力边界被锁在了架构设计上，这才是真正有护城河的部分。

七、实战执行策略：从 ReAct 到 Plan-Execute

三种执行策略的对比

面对复杂任务，Agent 的执行策略大概有三种选择：

Fixed Workflow（固定工作流）

优点：稳定可控，结果可复现。 缺点：缺乏灵活性，面对预期外的情况无法自适应。 适用场景：模型能力较弱时，或者任务流程完全已知的情况。

ReAct（Reasoning + Acting）

核心思路：让模型边思考边行动，每步根据当前状态动态决策。 优点：灵活，能处理预期外情况。 缺点：token 成本高、执行路径不可控、结果难以复现，且对小任务过于"重”。 适用场景：粒度较小的探索性任务。

Plan → Battle → Execute（计划-辩论-执行）

这是目前最推荐用于大型、复杂任务的策略。具体流程：

1. 动态规划：让模型先制定计划，明确目标、分解步骤、识别依赖
2. 辩论验证：用另一个模型角色（或多轮对话）对计划进行攻击——找出漏洞、质疑假设、识别风险
3. 迭代打磨：根据辩论结果修改计划，经过 N 轮后计划质量达到可接受水平（比如 70 分以上）
4. Human-in-the-loop：人做最终确认，这是关键的控制节点
5. 确定性执行：把经过验证的计划交给模型执行

关键转变是：从"过程确定性"到"结果确定性"。

传统工程思维追求过程确定性：每一步都要对，每个函数都要符合规范。但在 Agent 时代，我们只需要告诉 AI 终点线在哪里——让 AI 自己找路，自己验证，自己纠错。人的角色从"写每一行代码"变成了"画终点线 + 验收结果"。

幻觉的本质

理解了这个框架，AI 幻觉的本质也变得清晰了：

AI 为什么会输出错误内容？因为它不知道那是错的。为什么它不知道？因为你没有告诉它。

幻觉的根本原因不是模型不够聪明，而是上下文不够充分。Context Management 做得越好，AI 犯错的概率就越低。这也是为什么知识工程如此重要。

管线思维

任何复杂的工作都是一条管线（Pipeline）的产物，而不是单点的产出。

一个好的 AI 应用的核心竞争力，不在于用了多强的模型，而在于编排设计的质量：

• 信息怎么流动？
• 任务怎么分解？
• 各步骤的验证条件是什么？
• 错误怎么传播和处理？
• 人介入的节点在哪里？

Architect / Conductor 正在成为 AI 时代最关键的工程师角色，核心工作是 Orchestration。

▲ 三种执行策略对比，以及推荐的 Plan → Battle → Execute 五步流程

八、Harness 中的安全防护：用 AI 检测 AI

随着 Agent 的能力越来越强，安全边界的设计变得越来越重要。

单一大 Prompt 检测的问题

最直觉的方案是用一个大 Prompt 做全部安全检查：把所有安全规则写进去，让模型自己判断。

这个方案有一个根本性的问题：上下文一长就容易"中间遗忘"（Lost in Middle）。安全规则越多，越重要的规则越容易被模型忽略。用来保证安全的机制本身，反而成了安全的短板。

多模型并行检测架构

更可靠的设计是：把检测任务拆分给多个专职小模型并行执行。

用户输入
    ↓
[前置小模型] 恶意度评分 → 超阈值直接拦截
    ↓
[核心模型] 处理任务
    ↓
[并行检测层]
├── 检测模型 A：安全性检查
├── 检测模型 B：内容合规检查
├── 检测模型 C：政治敏感检查
├── 检测模型 D：敏感词过滤
└── 检测模型 E：其他风险维度
    ↓
[汇总判断] → 安全输出

每个检测模型只负责一个维度，上下文短，注意力集中，准确率高，而且各模型并行运行，总时延可控。

权限最小化原则

Claude Code 源码中所有工具调用都遵循权限最小化原则——每个工具只申请完成本次任务必须的最低权限，不多申请，不保留不用的权限。

这是一个基础的安全工程原则，在 AI 系统中尤为重要。因为 Agent 的行为路径是动态生成的，你事先无法完全预知它会调用哪些工具、以什么顺序调用——在这种情况下，每个工具的权限边界就成了最后一道防线。

用 AI 检测 AI

传统安全机制依赖规则：关键词黑名单、正则表达式匹配、固定模式检测。

但 AI 生成的内容天然会绕过规则——因为规则是静态的，而语言是无限变体的。

更有效的做法是用 AI 来检测 AI 的问题：训练专门用于安全检测的小模型，让它理解语义、识别意图，而不是匹配字面。这是"用魔法打败魔法"。

▲ Harness 安全防护架构：前置拦截 + 核心处理 + 并行多模型检测

九、Skill 生态：开源的理想与利益的现实

Harness Engineering 中有一个重要的组件：Skill（技能）。

Skill 是预定义的、可复用的行为模式——类似于函数，但针对 AI Agent 的行为。比如"如何调用某个 API"、“如何处理某类文档”、“如何与某个系统交互”。

Skill 的价值

做工程最大的浪费，是知识的浪费——做过一次就忘记了，下次遇到同样的问题要重新解决。Skill 的本质价值是复利：把一次性的经验沉淀成可复用的能力模块，每次调用都在享受过去投入的回报。

现在甚至出现了"Skill of the Skill"——你只要描述你想要什么能力，就有工具帮你自动生成 Skill。这意味着 Skill 的生产成本正在急剧下降。

Skill 生态面临的挑战

但随之而来的是几个严峻的问题：

质量参差不齐：生产成本下降意味着数量会爆炸式增长，而质量管控跟不上。大量低质量 Skill 充斥生态，拉高了人们对 Skill 的预期，但实际上帮倒忙。要让 Skill 生态健康发展，必须建立评估标准和质量分层机制。

利益分配问题：简单的 Skill 分享没有心理负担，但复杂的 Skill 几乎是一个产品——有工程设计、有上游依赖，投入了大量心血。如果要求开发者无偿贡献核心 Skill，动力严重不足。健康的生态需要利益体系：通过 Token/Credit 机制追踪调用量，基于结果让创建者从共享中获利。

企业内部的悖论：企业让员工上交 Skill 这件事，需要谨慎对待。员工手头最有价值的 Skill，往往是结合了业务知识和个人经验的"私有知识晶体"，这也是员工最核心的竞争力之一。强制要求上交，不仅会遭遇阻力，也可能破坏员工的创作积极性。

十、AI 时代工程师角色的真实变化

什么会被替代

能被低成本快速验证的、有明确输入输出的、重复性高的——这些会被 AI 替代。

代码的具体实现、模板文件的生成、文档的初稿撰写、简单的数据处理……这些工作，AI 已经做得不比人差了。

什么难以被替代

两类东西很难被替代：

需要非共识判断的决策：模型可以枚举所有观点，但需要有人在不确定性中做出判断，并愿意为这个判断承担后果。这种"选择 + 负责"的能力，是 AI 没有的。

需要隐性知识的工作：业务上下文、历史决策、未文档化的规范——这些只存在于人的记忆中，AI 无从得知。掌握这些知识的人，在 AI 时代反而变得更有价值。

新的核心能力

AI 时代，工程师最稀缺的能力变了：

系统思考能力：模型会用你的认知边界来回答你。你能想到多复杂的问题，它就能给出多深的答案。小学生和博士用同一个模型，差距不在工具，在认知层次。

清晰的表达：以前产品经理的模糊需求，背后有工程师帮忙翻译和补充。现在 AI 不会帮你补充——你说什么，它就理解什么。把需求描述清楚、把验收条件定义清楚，成了一种稀缺的生产力。

上下文架构设计：你的上下文组织得好不好，直接决定 AI 的输出质量上限。这是新时代的系统设计能力——不是设计代码架构，而是设计知识架构。

真实问题意识：工具越来越强，但工具本身不创造价值——解决真实问题才创造价值。最危险的状态不是不会用 AI，而是"给了你算力、配好了环境，你却不知道要解决什么问题"。

十一、给从业者的行动建议

现在就可以开始做的事

建立个人知识体系：不要等到有"完美的工具"再开始沉淀知识。今天就把你的项目规范、踩过的坑、重要的决策记录下来。Markdown 文件，够了。

动手做，不要只看：理解 Harness Engineering 最快的方式是自己搭一个简单的 Agent 系统，跑起来，出错，修复，再跑。看博客看视频是没用的，必须通过做来学。

关注底层原理，不追工具：框架会变，工具会迭代，但设计模式相对稳定。搞清楚 ReAct 的原理、Plan-Execute 的本质、Context Window 的限制——这些知识的半衰期比任何具体工具都长。

从真实问题出发：选一个你日常工作中真实的、具体的、让你头疼的问题，用 Harness Engineering 的思路去解决它。有真实问题，工具才有意义。

中长期值得投入的方向

• 知识工程系统：建立团队或个人的知识沉淀机制，把隐性知识显性化
• 可观测性基础设施：为你的 Agent 系统建立完整的日志、追踪、监控体系
• Human-in-the-loop 设计：识别你的业务中哪些决策节点需要人介入，并在系统设计阶段就把它们显式化

常见问题

Harness Engineering 和 Agent Framework 是同一件事吗？

不完全是。Agent Framework（如 LangChain、AutoGen 等）是工具层，提供实现 Agent 的组件和接口。Harness Engineering 是工程范式层，关注的是如何系统性地设计、构建和管理 AI Agent 的运行环境——包括但不限于选择什么框架。你可以用任何框架来实践 Harness Engineering，也可以不用任何框架。

小团队有必要关注 Harness Engineering 吗？

有，而且越早越好。Harness 的核心思想——可追溯、可控、知识沉淀——在任何规模的项目中都有价值。小团队现在建立好习惯，比大团队事后重构要容易得多。而且 Harness Engineering 的很多实践并不需要复杂的基础设施，一套结构化的 Markdown 文件就能覆盖大量需求。

如何衡量一个 Harness 设计得好不好？

两个核心维度：对使用者无感（好的 Harness 不需要用户感知它的存在，体验流畅）；出问题能快速定位（任何异常都能在执行链路里找到根因，不是黑盒）。如果你的系统出了问题，工程师需要猜"应该是哪一步出的"，那 Harness 设计得还不够好。

知识沉淀从哪里开始？

从最痛的地方开始。你们团队每次都会重复犯的错误是什么？每次新人上手都要问的问题是什么？每次发布前都会忘记检查的东西是什么？把这些写下来，结构化，放进你的 Agent 上下文——这就是知识工程的起点。

如果 26 年底还在手写代码是什么意思？

这不是说手写代码本身不好，而是说如果你在 26 年底还在用手写代码解决所有问题、没有任何 AI 辅助工作流，那很可能说明你对 AI 工具的掌握程度还不够。就像 2010 年还在用记事本写代码而不用任何 IDE，不是不行，但效率差距是实实在在的。

Harness Engineering 不是一个革命性的颠覆，它是一个自然的演化——当我们开始严肃地把 AI 当成工程系统的一部分来对待时，我们自然会需要这些实践。

有意思的预言是：最好的 Harness Engineering，就是以后不再提 Harness Engineering 了——它变成了标准化的工程实践，就像今天没人会专门说"我用了版本控制"一样，它只是工程的一部分，理所当然地存在。

那个时候，不是 Harness 消失了，而是它变成了基础设施。

如果你对 Agent 架构设计、知识工程体系建设或者具体的 Harness 实践方案有问题，欢迎在评论区交流，我也在持续摸索和迭代这些东西～