夜雨聆风过去两年，很多人对 AI 的理解，停留在一个很自然的阶段：提示词写得好，AI 就干得好。
于是大家开始研究各种 prompt 模板。
怎么给角色，怎么拆任务，怎么写约束，怎么让模型一步一步思考，怎么让它输出更像专家。
这当然有用。
但如果你最近真的在用 AI Agent 写代码、跑流程、改系统、查日志、处理复杂任务，就会发现一个现实：提示词很快会碰到天花板。
不是因为提示词不重要，而是因为 Agent 要完成的任务已经变了。
以前我们让 AI 生成一段文字、写一个函数、总结一份材料，提示词就是主要界面。现在我们让 Agent 进入真实工作环境：读仓库、改代码、跑测试、看日志、修 bug、开 PR、接收反馈、再迭代。
这时候，真正决定结果的，不只是你对它说了什么。
而是它身处什么样的环境。
它能看到什么上下文？能调用哪些工具？有哪些边界不能越过？如何知道自己做错了？失败后怎么恢复？谁来验收？什么规则会被自动执行？
这些东西加起来，才是 AI Agent 真正的工作台。
现在国外工程圈开始用一个词来描述这件事：Harness Engineering。
我更愿意把它翻译成：AI Agent 的“工程牵引系统”。
先讲一个特别有代表性的案例。
OpenAI 在 2026 年 2 月发布了一篇文章，标题就叫 Harness engineering。里面提到，他们做了一个实验：用 Codex 构建并发布一个内部 beta 产品，约束是人类不直接写代码。
不是让 AI 写一点辅助代码，而是从应用逻辑、测试、CI 配置、文档、可观测性到内部工具，全部由 Codex 生成。
几个月下来，这个仓库已经接近百万行代码，开了大量 PR，并且真的有内部用户在使用。
这件事最有意思的地方，不是“AI 写了很多代码”。
真正有意思的是，人类工程师的工作被重新定义了。
他们不再把主要时间花在亲手敲代码上，而是去设计环境、表达意图、建立反馈回路，让 Agent 能可靠地工作。
这就是 Harness Engineering 的起点。
当 Agent 变成执行者，人类的价值不再只是“会不会写代码”，而是“能不能让 Agent 在正确的系统里持续产出正确结果”。
换句话说，人类从司机变成了道路、交通规则和仪表盘的设计者。
很多人听到这里，第一反应可能是：这不就是更高级的 Prompt Engineering 吗？
不是。
Prompt Engineering 关注的是“怎么跟模型说话”。
Context Engineering 关注的是“给模型什么信息”。
Agent Engineering 关注的是“怎么设计一个能行动的智能体”。
Harness Engineering 更往外一层。它关注的是：这个 Agent 要在什么环境里行动，如何被约束，如何获得反馈，如何被持续改进。
举个简单例子。
你让一个 Agent 修复前端页面 bug。
只写一句“请修复这个 bug”，当然不够。
好一点的提示词会描述 bug、期望行为、相关文件、验收标准。
但真正能让 Agent 稳定工作的 harness，会包括更多东西：
它能不能自己启动应用？
能不能打开浏览器复现问题？
能不能拿到 DOM 快照和截图？
能不能看运行时日志？
能不能跑测试？
能不能读 lint 报错？
能不能知道哪些架构边界不能破坏？
能不能在修完后自动验证用户路径？
如果测试失败，它能不能继续定位原因，而不是把问题丢回给人？
这些东西不是 prompt，而是工作环境。
提示词是方向盘，Harness 是车、路、仪表盘、安全带和维修站。
OpenAI 那篇文章里有一个判断很关键：当代码吞吐量上来之后，瓶颈变成人类 QA 能力。
这句话放到企业里也成立。
过去，企业担心 AI 不够聪明。现在更现实的问题是：AI 太能产出了。
它可以一天写出过去一个人一周写的代码，也可以同时开很多任务。但如果你的测试、审查、日志、权限和验收机制没跟上，速度越快，风险越大。
这就是为什么 Harness Engineering 会突然重要起来。
因为 AI Agent 的产能不是线性提升，而是把原来被人工速度限制住的问题一下子放大。
以前一个开发一天只改一点代码，架构边界偶尔松一点，问题还不明显。
现在 Agent 可以连续工作几个小时，批量修改几十个文件。如果没有机械化约束，它会把坏模式复制得很快。
以前文档过期，只是新员工上手慢一点。
现在文档过期，Agent 会把过期知识当成真理执行。
以前测试不完整，只是上线前多靠人肉检查。
现在测试不完整，Agent 会以为自己已经完成任务。
所以 AI 不是降低工程纪律要求，而是提高了工程纪律要求。
越想让 Agent 自主，越要把规则、边界和反馈做硬。
这也是为什么 OpenAI 在那个项目里，特别强调“让代码库对 Agent 可读”。
他们后来发现，一个巨大的 AGENTS.md 不好用。把所有规则都塞进一个长文件里，看起来很完整，实际很容易腐烂，也会占满上下文，让 Agent 分不清什么最重要。
更好的方式，是把 AGENTS.md 变成一张地图。
入口要短，指向要清楚，真正的知识放在仓库里的结构化文档中，比如架构说明、设计决策、执行计划、产品规格、质量记录、技术债清单。
这点对企业非常重要。
很多公司的关键知识并不在系统里，而在会议纪要、聊天记录、某个老员工脑子里。
对人来说，这已经很痛苦；对 Agent 来说，这等于不存在。
Agent 看不到的知识，就不会参与决策。
如果一个接口为什么这样设计，只存在于半年前某个群聊里；如果一个客户场景为什么不能碰，只靠业务负责人记得；如果一条合规红线没有写进规则和工具里，那么 Agent 不可能自动理解。
AI 时代，企业知识管理不是行政工作，而是生产力基础设施。
知识必须结构化、版本化、可检索、可验证。
否则你不是在使用 Agent，而是在让 Agent 猜公司。
Cursor 的实践也很有意思。
他们在文章里说，不同模型需要不同的 agent harness。每个模型都有自己的工具偏好、指令理解方式和行为习惯。
比如有些模型更适合 patch 形式的文件编辑，有些模型更熟悉字符串替换；有些模型指令跟随更字面，有些模型对不精确指令更宽容。Cursor 会为不同模型配置不同工具、提示、上下文和评测方式。
这给企业一个提醒：未来不是“买一个最强模型”就完事。
企业真正需要的是模型和工作环境的匹配。
客服 Agent、财务 Agent、研发 Agent、法务 Agent、销售 Agent，不应该共享同一套粗糙工具箱。
它们需要不同的数据权限、工具接口、验收标准、风险阈值和人工介入机制。
研发 Agent 可以读仓库、跑测试、提交 PR；财务 Agent 可能只能生成分析，不能自动付款；客服 Agent 可以草拟回复，但高风险投诉必须人工确认；法务 Agent 可以检索合同，但不能自行修改正式条款。
这不是“提示词写严一点”能解决的。
这是组织和系统设计问题。
Thoughtworks 最近也讨论了一个很好的概念：AI coding sensors。
如果说 prompt 和技能是给 Agent 的前置信息，那么 sensor 就是 Agent 工作后的反馈信号。
测试是 sensor。
Lint 是 sensor。
类型检查是 sensor。
覆盖率是 sensor。
安全扫描是 sensor。
日志、指标、链路追踪也是 sensor。
这些传感器告诉 Agent：你刚才做的事到底有没有成功。
没有传感器的 Agent，就像蒙着眼睛开车。它可能很聪明，也可能很努力，但它不知道自己撞没撞墙。
企业上 AI 最容易忽略的，就是这件事。
大家愿意花钱买模型、买工具、买账号，却不愿意补测试体系、日志体系、数据质量、权限治理、评测基准。
结果就是：AI 看起来接入了，真正能放心交给它的事却很少。
因为没有反馈系统，就没有信任。
没有信任，就没有授权。
没有授权，Agent 只能停留在“帮我生成建议”的阶段。
而 Agent 真正的价值，恰恰在于它能从建议走向执行。
所以，如果把 Harness Engineering 拆开看，它至少包含五个部分。
第一，是上下文。
Agent 要知道业务目标、系统结构、关键规则、历史决策和当前状态。不是把所有东西一次性塞给它，而是让它知道去哪里找。
第二，是工具。
Agent 必须能用正确工具完成任务。读文件、查数据、跑测试、看日志、调用 API、开工单、提交变更，这些都需要清晰接口。
第三，是边界。
哪些动作可以自动做，哪些动作必须审批？哪些数据可读，哪些数据不可碰？哪些系统只能查询，不能写入？这些边界必须硬编码进权限和流程。
第四，是反馈。
Agent 做完之后，系统要能告诉它是否成功。测试、监控、评测、人工审核、用户反馈，都要回到循环里。
第五，是治理。
谁创建 Agent，谁维护 Agent，谁审核它的权限，谁处理事故，谁更新知识库，谁对结果负责。
这五件事加起来，才是一套最小可用的 Agent Harness。
回到企业视角，我觉得 Harness Engineering 会成为未来两年很重要的新能力。
原因很简单：AI Agent 会越来越便宜，模型能力会越来越接近，但企业把它用好的能力差距会越来越大。
就像云计算时代，真正拉开差距的不是“谁买了服务器”，而是谁建立了 DevOps、可观测性、弹性架构和安全治理。
AI Agent 时代也一样。
人人都能调用模型，人人都能买 Agent 平台。差距会出现在模型之外：你的流程是不是清楚，数据是不是干净，权限是不是合理，反馈是不是及时，知识是不是可读，组织是不是愿意把规则沉淀成系统。
这也是为什么我觉得，企业不要再把 AI 落地理解成“提示词培训”。
提示词培训有用，但它只是入口。
真正的 AI 落地，是把企业变成一个适合 Agent 工作的环境。
让 Agent 能看懂你的业务。
能安全地调用你的工具。
能在边界内自主行动。
能通过反馈持续改进。
能在出问题时停下来、回滚、交给人。
做到这一步，AI 才不是一个聪明的对话框，而是一个可以进入生产系统的数字员工。
我越来越相信，AI Agent 时代会催生一种新的工程角色。
这个人不一定是最会写提示词的人，也不一定是最懂某个模型细节的人。
他更像是 AI 时代的系统工程师。
他懂业务流程，也懂软件工程；懂权限和风控，也懂测试和可观测性；能把人的经验转成文档，把文档转成规则，把规则转成工具，把工具接入反馈循环。
他的工作不是让 AI “看起来更聪明”，而是让 AI “可靠地完成工作”。
这就是 Harness Engineering 的价值。
下一阶段，企业之间的 AI 差距，很可能不在于谁更会问问题。
而在于谁更早意识到：问题问完之后，真正困难的部分才刚刚开始。
AI Agent 不缺大脑。
它缺的是工作环境、行动边界和反馈系统。
别再只卷提示词了。
该开始搭 Harness 了。
