过去两年大家最喜欢聊的是 Prompt Engineering。怎么写提示词、怎么加 Role、怎么做 Few-shot……这套东西当然重要。但如果你最近在看 OpenAI、Anthropic 这些一线团队的工程文章会发现一个明显的变化他们聊的已经不只是 Prompt 了。2026 年AI 应用的形态真的变了。过去你主要是在问模型一个问题现在你更像是在让一个 Agent 连续干活。一旦任务从一次回答变成连续执行很多问题就不是一句 Prompt 能解决的了。今天这篇文章我想把Harness Engineering这个新概念讲清楚。它不是换个新词继续卷概念而是 AI 工程重心转移的真实信号。01 为什么 Prompt 不够了先说结论Prompt Engineering 没过时它依然是基本功。模型第一步能不能听懂你在说什么还是取决于 Prompt。但问题是今天的 AI 应用已经不是 2023 年的形态了。以前你让模型回答一个问题现在你让它先理解任务→拆步骤→搜索资料→调用工具→读文件→修改内容→检查结果→最后交付。这时候真正卡住系统的往往不是 Prompt 写得不够漂亮而是另外几件事该给它什么资料哪些历史该保留哪些工具结果该丢掉当前状态怎么记录失败后怎么恢复结果怎么评估一个 Coding Agent 接到任务后如果 Prompt 写得很好但它拿不到 Repo 结构、不知道哪些文件相关、看不到测试报错……它能干好吗很难。这就是 LLM 的结构性局限局限表现无状态对话结束就忘记只能生成文字无法操控外部世界上下文窗口限制不能无限处理信息输出概率性同样的输入可能不同输出Prompt 解决的是怎么说但解决不了这些结构性问题。所以行业才会开始从Prompt Engineering往Context Engineering走再往Harness Engineering走。02 Harness Engineering 是什么有个很形象的比喻马与挽具。马有力量但需要挽具。LLM 有能力但需要 Harness。马再强壮没有挽具也拉不动车。LLM 再强大没有系统约束也无法稳定完成任务。Harness 不是优化 Prompt 的技巧而是让 LLM 能力稳定输出的系统性挽具。如果把 AI 工程分成三层关系是这样的层级解决的核心问题典型对象Prompt Engineering怎么说单轮任务Context Engineering给什么长上下文任务Harness Engineering怎么持续做Agent / 工作流Prompt负责讲任务Context负责喂信息Harness负责让系统稳定运转Harness 不是一句 Prompt也不只是一包 Context。Harness 是整台机器。03 四层架构Harness 是怎么工作的Harness Engineering 的核心可以拆成四层结构第一层记忆层——解决健忘症LLM 对话结束就忘记这是无状态问题。记忆层要做的是结构化存储关键信息。比如 Claude 的CLAUDE.md文件把项目规范、代码约定、常见问题都写进去。Agent 每次启动时自动读取相当于有了长期记忆。但记忆不是越多越好。真正的记忆工程要做的是保留关键历史压缩冗余内容清掉过时结果把真正重要的东西留在窗口里第二层执行层——突破只会说话限制LLM 只能生成文字无法操控外部世界。执行层要赋予它操作外部世界的能力。比如搜索文件读取Shell 命令浏览器操作数据库查询工具不是附加能力它本身就是上下文的一部分。因为模型得知道有哪些工具、每个工具是干什么的、什么情况下该用哪个。第三层反馈层核心——建立确定性验证机制这是 Harness 最核心的一层。LLM 输出是概率性的同样的输入可能不同输出。反馈层要做的是将人工 Review 的小时级反馈压缩至秒级。在代码领域这个闭环天然存在模型生成代码编译器/测试立刻验证失败→重试/回滚成功→继续下一步Anthropic 在内部评测里给过一组数据在他们那套 Multi-Agent Research 系统里优化 Tool Description 后后续 Agent 的任务完成时间下降了 40%。反馈层的核心价值把人的判断力固化进系统。第四层编排层——拆解复杂任务复杂任务不是一步能完成的。编排层要做的是任务拆解和多 Agent 协同。比如一个 Research Agent 做行业调研子 Agent A 负责搜索子 Agent B 负责整理子 Agent C 负责验证主 Agent 负责统筹和交付Anthropic 在内部 Research Eval 上的数据多 Agent 比单 Agent 高出90.2%。04 为什么代码领域先行你会发现Harness Engineering 的讨论最早、最密集的都是 Coding Agent。为什么因为代码验证天然确定——编译器不讲情面。这使概率性生成 确定性验证闭环可以高速运转模型生成代码 → 编译器验证 → 测试运行 → 反馈结果 → 修正重试其他领域就没这么友好。比如写文章、做设计、出方案很难有自动化的编译器来验证对错。所以代码领域成了 Harness Engineering 的试验田和突破口。但这不代表其他领域不能用。核心思路是一样的找到你领域的编译器建立确定性验证机制。05 实践精髓普通团队现在该怎么做我的建议是不要一上来就学那些很玄的大一统 Agent 框架。先把基础链路做稳。1. 渐进式信息披露避免信息过载。不是把所有文档、所有历史、所有工具一股脑塞进上下文。那叫上下文污染不叫 Context Engineering。对的时机把对的信息交给模型。2. 沙箱隔离独立沙箱大胆试错。Agent 执行命令、修改文件、调用工具都应该在隔离环境中进行。出错了可以回滚不会污染生产环境。3. 仓库即真理规范写入代码而非口头传达。比如把项目约定写成CONTRIBUTING.md、CLAUDE.mdAgent 自动读取。规则变成可执行的代码不靠人情。4. 机械化约束规则自动执行不靠人情。哪些动作能自动做哪些动作必须人工确认要提前定义好。比如读文件通常可以自动做但删除文件、联网下载、发消息很多时候就不能放开。5. 上 Eval、日志和人工 Review 闭环不做这些你永远不知道自己是在调系统还是在碰运气。你得看得见 Agent 在干什么它用了哪些工具、做了哪些决定、卡在了哪里、为什么失败。06 工程师的新使命最后说一个更重要的变化工程师角色的转变。过去工程师的核心工作是写代码。现在越来越多的工程师要转向设计验证系统。过去现在写代码设计系统调逻辑调架构修 Bug设计恢复机制写文档固化规则到系统Harness Engineering 的本质把人的判断力固化进系统变成可持续运转的基础设施。这不是说写代码不重要了而是说当模型能写代码的时候工程师的价值就往上移了一层——从执行者变成系统设计者。07 写在最后如果把这篇文章再压缩成一句话那就是Prompt Engineering 解决的是怎么说Context Engineering 解决的是给什么Harness Engineering 解决的是怎么让它持续做下去过去大家在调一句 Prompt现在大家开始调一整套 Agent 运行系统。这不是因为 Prompt 不重要了而是因为 AI 应用已经从回答问题走到了连续执行任务的阶段。真正的变化不是概念变多了而是工程重心变了。