提示词工程、上下文工程都过时了，现在是Harness Engineering 的时代

本文来自微信公众号： Founder Park ，作者：Founder Park，原文标题：《提示词工程、上下文工程都过时了，现在是 Harness Engineering 的时代》

Prompt Engineering过时了，Context Engineering也过时了。

2026年开年，开发者社区最热的关键词叫Harness Engineering。

2月5日，HashiCorp联合创始人Mitchell Hashimoto在博客发文，把AI辅助开发中一种正在被越来越多顶尖团队采用的工程实践正式命了名——Harness Engineering。六天后，OpenAI发布了一份详细的内部实验报告，标题直接用了这个词。再之后，知名工程师Martin Fowler在Twitter上为Thoughtworks工程师对这份报告的深度分析站台。

一个月之内，Harness Engineering从一篇博客文章变成了开发者社区的高频词。

一个新的共识正在形成：在AI Agent编码领域，决定结果好坏的最大变量，往往不是模型有多聪明，而是模型被放在了一个什么样的环境里。

LangChain的编码Agent在Terminal Bench 2.0基准测试上，通过仅优化Agent运行的外部环境（文档结构、验证回路、追踪系统），排名从全球第30位跃升至第5位，得分从52.8%飙到66.5%。底层模型一个参数都没改。安全研究员Can Boluk仅仅改变了Agent的代码编辑格式，Grok Code Fast 1的基准得分就从6.7%跃升至68.3%。

而OpenAI的那份报告，则记录了另一个更直观的工程事实：5名工程师，五个月，零行手写代码，通过Codex Agent协作交付了超过100万行代码的生产级软件产品。

模型能力的竞赛仍在继续，但真正在一线决定Agent工程产出质量的杠杆，已经转移到了「环境」一侧。

这个「环境」，就是Harness。

⬆️关注Founder Park，最及时最干货的创业分享

超22000人的「AI产品市集」社群！不错过每一款有价值的AI应用。

邀请从业者、开发人员和创业者，飞书扫码加群：

进群后，你有机会得到：

• 最新、最值得关注的AI新品资讯；

  
  

• 不定期赠送热门新品的邀请码、会员码；

  
  

• 最精准的AI产品曝光渠道

  
  

01

从Prompt、Context到Harness，

业界的认知在逐渐升级

Harness Engineering不是凭空冒出来的概念。从Prompt到Context，每个概念都对应着开发者社区对「如何让AI可靠工作」这个问题的一次认知升级。

2023年：Prompt Engineering

这是Prompt Engineering的全盛期，写好一条提示词就能让AI交付结果。Few-shot prompting、Chain-of-Thought、角色扮演，开发者社区围绕这些技巧产出了大量教程和最佳实践。但当AI从chatbot进化为需要处理复杂任务的Agent时，单条指令的局限性暴露无遗。LLM领域最活跃的技术博主Simon Willison后来一句话总结了这个阶段的问题：「prompt engineering的社会推断含义已经偏离了本意。大多数人听到prompt engineering，想到的就是对着ChatGPT打字。」

2025年中：Context Engineering

2025年6月，OpenAI联合创始人Andrej Karpathy发帖：

「+1 for'context engineering'over'prompt engineering'......这是一门精微的艺术与科学，用恰到好处的信息填充上下文窗口，以服务于下一步操作。」

Shopify CEO Tobi Lutke紧随其后，发布了一条获得190万浏览量的帖子：

「我真的很喜欢context engineering这个词。它更好地描述了核心技能：为任务提供让LLM有可能解决它的全部上下文的艺术。」

Simon Willison在博客上做了总结：

「我认为context engineering会留下来。跟prompt engineering不同，它的推断定义跟本意高度吻合。」

Context Engineering的核心转变在于：焦点从「写好一条指令」扩展到了「设计一个动态系统来组装上下文」。RAG、对话历史、工具输出、系统指令的编排，都成了工程师需要操心的事。

但2025年下半年，一线实践者开始发现：光有好的上下文，Agent依然会失控。

2026年2月：Harness Engineering

技术播客Vanishing Gradients的一集节目标题直接点破了这个矛盾：「Why Agent Context Isn't Enough」（为何仅有Agent上下文依然不够）。节目揭示了一个关键悖论：上下文窗口的扩大，并不等于Agent性能的线性提升。即便模型理论上支持100万Token的上下文，性能衰减在25.6万Token左右便已出现。播客还记录了一起造成5万美元损失的事故：一个无人监控的Agent陷入无限循环，API账单累积到被人发现时已经来不及了。

上下文可以告诉Agent「知道什么」，但无法阻止Agent「做不该做的事」。

Mitchell Hashimoto在2月5日的博文中为这块缺失的拼图命了名：Engineer the Harness（工程化线束）。他的定义很简洁：

「每当你发现Agent犯了一个错误，你就花时间设计一个解决方案，使Agent永远不再犯同样的错误。」

六天后OpenAI官方的报告发布，业界的讨论也逐渐热了起来。

回过头看，三个阶段的关系用一句话就能说清：Prompt Engineering管的是「说什么」，Context Engineering管的是「知道什么」，Harness Engineering管的是「在什么环境里做事」。

02

OpenAI实验全解读：

不要把东西都塞进AGENTS.md

OpenAI的这份报告是理解Harness Engineering的核心文本。里面的工程细节值得展开。

实验设定

团队从3名工程师起步，最终扩展至7名。五个月内构建并交付了一个内部测试版软件产品，已有外部Alpha测试用户。代码库覆盖应用逻辑、基础设施、工具链、文档和内部开发工具，全部由Codex Agent生成，无一行人类手动编写。

OpenAI团队明确声明这是一个「刻意设定的极端约束实验」（forcing function）。他们写道，设定「零人类代码」这条规则的目的，是倒逼团队去构建能让Agent大规模可靠工作的工程基础设施。换句话说，这个约束本身就是为了催生Harness。

效率数据也很突出：平均每名工程师每日3.5个Pull Request的合并吞吐量。代码审查通过Agent对Agent的循环实现了大规模自动化，人工监督仅保留在高层架构决策环节。

报告作者Ryan Lopopolo写了一句后来被反复引用的话：

「我们目前最困难的挑战，集中在设计环境、反馈回路和控制系统上。」

踩过的坑：AGENTS.md的进化

报告中实操价值最高的部分，是团队在文档工程上的试错过程。

早期，团队犯了一个经典错误：把所有信息塞进一个庞大的AGENTS.md文件。系统说明、架构规范、代码风格、边界条件......全部堆在同一份文档里。结果Agent被信息淹没，性能反而下降。

他们最终演化出的方案是一个渐进式披露模型。AGENTS.md被精简为约100行的「目录」角色，指向一个结构化的docs/目录：

项目根目录/AGENTS.md←精简目录（~100行），指向docs/AGENTS.override.md←子目录级覆盖规则docs/ARCHITECTURE.md←分层架构与依赖流向DESIGN.md←设计原则与模式PLANS.md←执行计划PRODUCT_SENSE.md←产品意图与用户旅程QUALITY_SCORE.md←质量评分标准RELIABILITY.md←可靠性要求SECURITY.md←安全约束

Codex的发现机制是逐级读取：从全局配置~/.codex/AGENTS.md到项目根目录，再到子目录，就近优先。比如services/payments/下可以放一份AGENTS.override.md，用make test-payments覆盖根目录的npm test规则。大小上限默认32 KiB。

这套目录结构背后的核心假设是：Agent不需要在一开始就知道所有事情，它需要在正确的时机获得正确粒度的信息。跟人类工程师入职的逻辑一样——没有人第一天就读完公司所有文档。

超越文档：让Agent「看见」运行时

静态文档之外，OpenAI团队做了一件更激进的事：把可观测性数据直接暴露给Agent。

日志、指标、追踪信息，通过本地可观测性栈（每个工作树独立实例化）向Codex Agent开放。Agent可以使用LogQL和PromQL查询来验证服务启动时间和关键用户旅程的性能指标。

更进一步，Agent甚至可以通过Chrome DevTools Protocol操作浏览器：重现Bug、验证修复、直接对UI行为进行推理。

这意味着Agent不再只是一个「写代码的工具」。它能看见代码运行后发生了什么，并据此判断自己写的代码到底对不对。

机械化的架构围栏

OpenAI团队定义了严格的分层架构依赖流向：Types→Config→Repo→Service→Runtime→UI。任何违反依赖方向的代码都会被机械化拦截。

拦截机制有两种。一是确定性Linter。有一个细节值得说：工程师花了数小时重写Linter的错误输出格式。目的只有一个，让Agent能「读懂」出了什么问题，并据此自动修复。Linter输出的受众从人类变成了AI——这件事本身就是Harness Engineering思维的典型体现。

二是基于LLM的审计Agent，用于检查那些难以用形式化规则捕捉的语义违规。

两种机制组合，确保了Agent生成的代码在架构层面的长期一致性。团队的思路是：每当Agent犯一个新类型的错误，就回头加一条约束。日积月累，Harness越来越健壮，Agent能犯的错越来越少。

这正是Hashimoto所说的：「让Agent永远不再犯同样的错误。」

03

Böckeler的解读：

Harness Engineering的三级框架

OpenAI的报告是一手的工程记录，信息密度很高但组织偏松散。Thoughtworks的Distinguished Engineer、生成式AI交付专家Birgitta Böckeler在martinfowler.com上发表的分析文章，把这些实践提炼成了一个清晰的三维框架。

Martin Fowler本人在2月17日的Twitter帖子中称赞了这篇报告：

「Harness Engineering是对AI使能软件开发关键部分的有价值框架。Harness包括上下文工程、架构约束和垃圾回收。」

Böckeler将Harness的核心拆解为三个维度：

维度一：上下文工程（Context Engineering）

确保Agent在正确时机获得正确信息。包括前面提到的渐进式文档披露、动态可观测性数据接入，以及Agent对浏览器行为的直接推理能力。Böckeler指出，这一维度与2025年中期流行的Context Engineering概念高度重合，但Harness Engineering将其纳入了一个更完整的体系。

维度二：架构约束（Architectural Constraints）

通过机械化手段强制执行架构边界。包括确定性Linter（输出格式专为Agent设计）和LLM审计Agent的双轨机制。Böckeler特别注意到，OpenAI让Linter的错误消息直接包含修复建议，这使得整个「违规→检测→修复」的循环可以在Agent内部闭环完成，无需人工介入。

维度三：熵管理/垃圾回收（Entropy Management）

这是Böckeler框架中我觉得最有意思的部分。她观察到OpenAI团队部署了专用的清理Agent，定期扫描文档漂移、模式违规和依赖问题。

为什么要单独拎出来？因为Harness本身也是代码和文档，它们同样会腐化。随着代码库规模增长，规则文件可能变得冗长混乱，包含过时、矛盾或不再适用的指令。如果Harness自身腐化了，Agent就会因为读到混乱指令而输出混乱代码。熵管理要解决的就是这个问题：约束系统本身不能随时间退化。

Böckeler把三者的关系概括得很清楚：上下文工程让Agent「知道该做什么」，架构约束确保「只在边界内行事」，熵管理保障「整个系统不随时间退化」。

她同时提了一个重要的补充：OpenAI的报告主要关注代码的内部质量和可维护性，但对功能性和行为验证的覆盖不足。能通过所有Linter和架构测试的代码，不等于做了用户真正需要的事情。这个提醒很实在，也指出了接下来需要补上的一块。

04

Stripe、LangChain，

行业有了更多实践者

如果说OpenAI的实验只是个案，说服力有限。如今Harness Engineering的逻辑正在多个头部公司得到独立验证。

Stripe：工业级的线束基础设施

Stripe的Minions体系每周合并超过1,300个由AI完全编写的Pull Request，人类仅负责审查。

Minions的基础设施透露了Harness Engineering在大型组织中的实际形态：每个Agent任务在独立的预热devbox中运行，与Stripe工程师使用的机器完全相同，约10秒内启动，内置Stripe代码库和服务，与生产系统及互联网完全隔离。

工具访问通过名为Toolshed的中心化MCP服务器实现，托管近500个工具，涵盖内部系统和外部SaaS平台。Agent与人类开发者享有完全一致的工具访问权限。

Stripe的架构选择也有意思：确定性节点与Agent节点混合的「蓝图」模式。可预测的步骤（推送到Git、运行Linter、触发CI）全部交给确定性代码处理，只在需要判断或创造力的环节才调用LLM。这种设计把LLM限制在「可控盒子」里，大幅提升了系统的可预测性。

LangChain：一个干净的对照实验

回到开头的那组数据。LangChain的编码Agent在Terminal Bench 2.0上，通过仅优化Harness而不修改底层模型，得分从52.8%提升至66.5%，排名从第30跃升至第5。

这个案例的价值在于变量控制做得很干净：模型不变，Harness变，结果剧变。在「环境比模型更重要」这个论点上，这可能是目前最直接的证据。

Anthropic在内部工程文档中已经将Claude Code定位为「灵活的Agent线束」。Harness的概念正在被工具供应商内化为产品设计思路。

MCP（模型控制协议）已在Linux基金会下的Agentic AI基金会治理，月SDK下载量超过9,700万，获OpenAI、Google、Microsoft和AWS采用。Stripe的Toolshed就是一个MCP服务器。MCP正在成为Agent工具访问的通用标准，而Harness工程的工具层将大规模迁移到这个协议上。

LangChain的State of Agent Engineering报告提供了一组行业全景数据：89%的受访者已为其Agent实施了可观测性，但仅有52%实施了评估（Evals）。大多数团队已经能「看见」Agent在做什么，但还没有建立系统性的机制来判断「做得对不对」。评估体系怎么规模化，大概是Harness Engineering接下来一年绕不开的课题。

05

工程师的核心工作，

正从写代码转向设计环境

一件事：工程师的核心工作，正在从写代码转向设计让Agent可靠运行的环境。

OpenAI实验中的工程师，日常工作已经变成了三件事：

第一，构建文档与上下文体系。维护AGENTS.md目录、docs/下的架构规范与设计文档，编写自定义Linter（包括重写Linter的错误消息格式，使其对Agent可读且包含修复建议），建立可观测性基础设施使Agent能够查询运行时数据。

第二，以机器可处理的方式定义业务意图。工程师需要把业务目标、质量标准和边界条件表达得足够清晰和精确，使Agent能够据此自主决策。这要求更强的系统性思维和抽象能力。

第三，构建自动化的防呆验证机制。合并门禁被最小化以避免瓶颈，系统转而依赖强大的自动化守卫。Stripe的实践表明，预推送钩子和本地Linter在5秒内解决常见问题，是减少无效Agent循环的关键。

The Pragmatic Engineer的创始人Gergely Orosz在报道OpenClaw创始人Peter Steinberger的工作方式时，描述了一个很生动的场景：Steinberger是「在脑中保存项目高层结构的软件架构师」，在使用Agent时只讨论架构和重大决策，完全不涉及具体代码实现。

越来越多人开始觉得，这就是Harness Engineering对工程师的要求：系统理解的深度，比写代码的速度重要得多。

在组织层面，变化也很大。OpenAI的3-7人团队完成了以前需要数十人规模的工程输出。Stripe让单名工程师可以同时向多个Agent分配不同任务。团队结构正在向两三人甚至单人团队收敛，完整拥有从规划到上线的功能全生命周期。「合理团队规模」的底层计算逻辑正在被重写。

Böckeler在这一点上提出了一个所有技术管理者都该想想的问题，她称之为「学徒缺口」（Apprentice Gap）：如果初级开发者过早进入Agent驱动循环，未经历手动开发的锻炼，他们可能缺乏未来构建健壮Harness所需的深度系统直觉。她建议将「体验工程」（Experience Engineering）视为下一个核心挑战，设计保留手动开发直觉的学习路径。

06

开发者可以做什么？

Hashimoto的六阶段采用旅程是目前操作性最强的个人路线图。他自己正处在第五阶段。以下是从他的博文和实践中提炼的行动建议：

起步：把同一个任务做两遍。先自己手动完成，再让Agent重新做一遍。Hashimoto说自己「真的把工作做了两遍」，目的是建立对Agent能力边界的直觉。他总结了三个关键发现：把会话拆成独立清晰的任务；把模糊需求拆成「规划」和「执行」两个阶段；给Agent自我验证的方法。

养成习惯：每天下班前30分钟启动Agent。Hashimoto说这「给了我第二天早晨一个热启动」。三类任务特别适合这个时段：深度调研（Agent扫描整个领域）、并行探索（多个Agent同时试验模糊想法）、Issue和PR分诊。

关键跃迁：在你的项目里建一份AGENTS.md。这不需要是一份完美的文档。从最基本的内容开始：项目的核心架构说明、常见的Agent错误及应对方式、测试和Lint命令、Agent绝对不能碰的部分。每次Agent犯错，就回来补一条规则。日积月累，这份文档就会长成你的Harness。

Hashimoto还分享了一条心态层面的建议：「关掉Agent的桌面通知......作为人类，我的职责是控制何时中断Agent，而非被它中断。」

对技术负责人来说，最实际的建议是：选一个新项目做试点。OpenAI和Stripe的成功案例都有一个共同前提，要么从零开始，要么在成熟的内部基础设施上运行。遗留代码库的改造是另一个量级的工程挑战。此外，Evals（评估体系）是下一个必建能力。当前仅有52%的团队部署了评估系统，这个差距就是你的机会窗口。

OpenAI的报告发布至今只有一个月。Hashimoto自己也说，他还处在六阶段的第五阶段。行业里绝大多数团队还停留在前三个阶段。

但方向已经不可逆。

从Prompt Engineering到Context Engineering再到Harness Engineering，三年间，开发者社区对「如何让AI可靠地工作」这个问题的理解，已经从「写好一条指令」演进到了「构建一整个运行环境」。

软件工程团队的核心竞争力，正在从「谁的工程师代码写得更好」转向「谁的工程师能设计出更好的Agent运行环境」。

正如Ryan Lopopolo在OpenAI报告中写的那句话：

「我们目前最困难的挑战，集中在设计环境、反馈回路和控制系统上。」