当AI Agent开始调用工具、操作真实系统，单纯优化Prompt已无法解决信息缺失、状态混乱和权限失控等问题。本文深入探讨Harness Engineering如何成为Agent可靠性的关键，揭示竞争焦点正从提示词转向执行环境的搭建。

过去几年，AI产品出现问题时，团队最常见的解决方式是修改Prompt：回答不准就补背景，输出不稳就加格式，执行跑偏就增加步骤，担心幻觉再强调不得虚构。随着问题不断出现，系统Prompt越来越长，逐渐从任务说明变成一份试图预判所有异常的操作手册。

这种方法在摘要、分类、文案或结构化提取等单轮任务中确实有效。但当Chatbot变成需要调用工具、读取信息并执行操作的Agent，事情开始变化。

Agent可能找不到资料、调用错误工具、忘记目标，也可能重复失败路径，或者未经验证就宣布完成。此时继续补规则无济于事：Prompt无法让缺失的数据凭空出现，无法代替任务状态，也不能成为真正的权限边界。

本文所说的失效，不是Prompt没有价值，而是只要把Prompt写得足够准确，就能让模型稳定完成任务这一假设正在失效。

Prompt只能告诉Agent应该做什么，却不能独立解决信息、工具、状态、失败和权限问题。这些属于模型之外的执行系统，也就是Harness Engineering。

AI Agent的竞争重点正在转移：团队比拼的不再只是谁更会向模型提要求，而是谁能为模型搭建可靠的工作环境，把一次聪明的回答变成一个真正完成的任务。

一、Prompt没有消失，但正在失去独立解释力

Prompt Engineering解决了一个重要问题：如何把人的意图转换成模型更容易理解的指令。生成式AI应用早期，很多任务都可以压缩成一次调用，无论摘要、分类还是信息提取，都没有脱离输入—生成—输出。在这种形态下，Prompt几乎决定模型工作的全部上下文。

一个设计良好的Prompt，可以帮助模型理解目标、限定范围并降低不确定性。同样面对用户访谈，总结内容和提取影响付费决策的因素会得到不同结果；Few-shot示例和结构化要求也能提高稳定性。

这些价值没有因为Agent出现而消失。Agent仍然需要系统Prompt理解角色、任务和行动原则，工具描述本身也需要Prompt Engineering，因为模型能否正确调用工具，与工具名称、参数说明和边界描述密切相关。Anthropic在总结Agent工程经验时提到，他们构建编码Agent时，用于优化工具的时间比优化整体Prompt更多。这说明Prompt Engineering仍然存在，但工程对象已经从写一段总指令扩展到模型与系统之间的交互接口。

Prompt有一个明显特点：它离结果很近。回答不好，修改一句指令，重新运行后就可能看到变化。相比训练模型、改造检索系统或调整工具接口，修改Prompt的成本很低。这种即时反馈容易让团队形成经验判断：既然改Prompt能改善结果，更多问题也应该能通过Prompt解决。

于是，一些本属于系统设计的问题被不断写进Prompt：为了防止工具误用，增加选择规则；为了避免遗漏步骤，要求严格遵循流程；为了处理异常，补充失败后的应对方式；为了限制风险，加入大量禁止事项；为了减少幻觉，反复强调必须真实。

这些规则并非完全无效，但Prompt只能影响模型产生下一步输出的概率，不能替代确定性控制。不得调用未经授权的工具无法代替权限系统；失败后尝试其他方法无法代替重试和回退机制；请确保任务已经完成也无法代替可执行的验收条件。把这些要求全部写入Prompt，相当于把本应由程序保证的行为交给模型临场判断。

Prompt Engineering正在经历的变化，与其说是消失，不如说是基础设施化。Anthropic在Context Engineering实践中提出，系统Prompt应保持清晰、直接，并处于合适的抽象层级；把复杂逻辑过度硬编码进Prompt，会带来脆弱性和维护成本。随着模型能力增强，一些具体格式的重要性也可能逐渐下降。

成熟AI产品仍会拥有经过设计的Prompt，但很少能仅凭它建立长期壁垒。真正难以复制的是业务中的任务结构、工具体系、状态机制、失败处理、权限规则和评价标准。所以，失效指Prompt正在失去对Agent成败的独立解释力和作为核心壁垒的独立价值。它仍是理解任务的入口，却不是完成任务的全部。

二、从Chatbot到Agent，工程对象已经变化

Chatbot的主要任务是生成内容。用户提出问题，模型根据知识和当前上下文给出回答。即使回答不准确，错误通常也会随对话结束而停止。团队关注的是答案质量，包括准确性、相关性、表达方式和格式。

Agent的主要任务则是推动外部状态发生变化。它不仅回答用户，还可能查询资料、调用API、操作软件、修改文件，甚至与其他Agent协作。Anthropic区分了两种架构：工作流按照预设代码路径组织模型与工具，Agent则动态决定处理过程和工具用法。 如果说Chatbot面对的是如何回答，Agent面对的就是下一步应该做什么。

以差旅计划为例。Chatbot可以根据要求生成行程建议，即使某家酒店已经满房，这份内容仍可作为参考。若Agent要直接完成预订，它就必须掌握用户时间、预算和偏好，查询实时航班与酒店，比较方案，读取工具结果，并在支付前获得确认。任务从一次生成变成一条连续决策链：理解目标、获取信息、制定计划、选择工具、执行动作、读取结果、调整计划、验证完成。

模型在每个环节获得的信息都会影响下一步：早期资料错误会污染后续计划，工具失败未被识别会造成假成功，早期约束可能被后续信息淹没，缺少终止条件还会导致重复尝试。更值得警惕的是错误完成：Agent没有达成目标，却判断任务已经结束。对于能发送邮件、修改文件或提交订单的Agent，它会直接影响真实业务状态。

因此，Agent系统不能只判断模型最后说了什么，还要检查它做过什么、每一步得到什么反馈，以及最终状态是否满足验收条件。产品指标也要从回答准确率和满意度，扩展到端到端完成率、执行成本、恢复能力、权限合规与外部结果验证。

过去，模型输出是最终结果；现在，它只是执行循环中的一次决策。真正的结果不是一句已经完成，而是目标系统确实出现预期变化。Anthropic指出，Agent需要通过工具或代码执行获得环境反馈，并设置检查点和停止条件。

所以，从Chatbot走向Agent，并不是给对话模型多接几个工具，而是把工程对象从一次回答变成一套持续运行、能够影响外部世界的任务系统。

三、什么是Harness Engineering

目前行业对Harness尚无完全统一的定义。部分开发者把系统Prompt、工具说明和上下文管理归入Scaffold，把模型调用、工具执行与停止判断归入Harness；Claude Code、Codex等产品则采用更宽泛的用法，把模型之外、支撑Agent运行的整套系统称为Harness。Hugging Face也提醒，不同产品和框架对这些术语的使用并不一致。

本文采用更适合AI产品分析的广义定义：

Harness Engineering，是围绕基础模型设计完整执行环境的工程方法。它负责组织模型能够看到的信息、连接模型可以使用的工具、维持任务状态、控制执行过程，并限制模型的行动边界。

Prompt Engineering关注如何向模型表达任务，主要处理角色、目标、规则、示例和输出要求。Context Engineering关注当前这一轮应该让模型看到什么，除了系统Prompt，还包括用户历史、外部资料、工具说明、中间结果和任务状态。Harness Engineering关注的则是模型理解任务后，系统如何让它继续工作。三者不是相互替代的流行词，而是逐层扩大的工程范围：Prompt设计指令，Context管理信息，Harness组织完整行动系统。

Harness也不等于Agent框架。框架可以提供模型调用、工具注册、流程编排和状态存储等通用组件，却不会自动完成具体业务判断。框架可以提供重试功能，却不知道一次支付失败后应该重试、换卡还是停止；可以提供Memory组件，却不知道哪些信息值得长期保存。框架提供零件，Harness决定这些零件如何围绕具体任务组成一套系统。

OpenAI在Codex工程实践中，将人的工作概括为设计环境、明确意图并建立反馈循环，使Agent能够可靠工作。当Agent遇到问题时，团队不是简单要求模型再次尝试，而是寻找缺失的工具、文档、护栏或可观察信息。 这也是Harness与Prompt优化最本质的区别：它不再试图只通过语言让模型可靠，而是把可靠性落实到模型周围可以设计、执行和验证的系统中。

四、Harness Engineering的五个核心层次

如果Harness是模型运行所依赖的完整环境，它至少要解决五类问题：Agent能够看到什么、能够使用什么、需要记住什么、失败后怎么办，以及哪些事情不能自主决定。这五层共同决定模型能力能否稳定转化为任务结果。

1. 上下文管理：不是给得越多，Agent知道得越多

上下文窗口更像有限的工作记忆，而不是容量越大越好的资料仓库。系统Prompt、工具说明、用户历史、检索结果和执行记录都会争夺注意力，无关信息不断进入时，关键约束反而可能被淹没。

Anthropic将其概括为有限的注意力预算：随着上下文增长，模型对信息的提取和长距离关联能力可能下降。上下文工程的目标不是放入最多的信息，而是用尽可能少的高信号内容支撑当前决策。

对Agent而言，上下文必须动态管理。任务开始时可能只提供目标、边界和资料索引，执行到具体步骤时再按需查询；长任务还要压缩早期过程，保留确认过的决定和关键结果，删除重复输出。产品经理需要明确：哪些信息默认提供，哪些由Agent获取，哪些历史应该保留、压缩或丢弃。

2. 工具与MCP：连接工具，不等于会使用工具

模型只能生成行动意图，真正查询数据、修改文件或调用业务系统，仍要由工具执行。MCP等协议降低了连接外部数据与工具的成本，但协议主要解决如何连接，不会自动解决应该连接什么和怎样让模型正确使用。

一个工具对开发者清楚，不代表对模型也清楚。若名称含糊、功能重叠、参数歧义或返回结果冗长，Agent就容易选错工具或误读结果。

工具设计至少要考虑四件事：名称与功能能否被区分，参数是否明确且难以构造无效输入，返回结果是否包含下一步所需信息，失败时是否提供可理解、可处理的错误状态。Anthropic建议保持工具集合精简，减少功能重叠，并为接口提供明确用途与边界。如果人类都无法迅速判断某个场景该用哪个工具，就很难期待Agent稳定选择。

工具不是挂在模型旁边的能力列表，而是Agent与外部世界的交互界面。Agent产品需要重视Agent-Computer Interface：让模型理解工具、正确调用，并从结果中获得下一步所需信息。

3. Memory与状态：记住聊天记录，不等于记住任务

Memory不只是保存用户历史或偏好。对持续执行的Agent，更重要的是任务状态：当前目标、确认过的约束、已完成步骤、中间结果、失败方法和待解决问题。

如果系统只是把所有对话不断塞回上下文，Agent虽然看见历史，却未必能识别进度。内容变长以后，早期决定可能被忽略，失败路径也可能再次执行。因此，Memory需要结构化：用户长期偏好、当前任务状态、外部系统状态和临时推理记录不应混在同一段文本中，它们的有效期、可信度和修改权限也不同。

尤其要警惕错误记忆：未经验证的推断一旦被保存，后续任务可能持续引用。Memory设计的核心不是能否记住用户，而是哪些信息有资格影响Agent未来行动。

4. 编排、重试、回退与纠错：让失败成为系统状态

Agent会根据当前信息动态决定下一步，执行路径因此更难预测。工具调用失败时，它可能重试、更换参数、改用其他工具或求助。若系统没有明确的失败状态，就可能在没有新信息时不断重试，或轻易放弃可恢复的路径。

可靠Harness至少需要四类机制：一是重试条件，区分网络超时、参数错误和权限不足；二是替代路径，让Agent能够发现备用数据源或执行方式；三是状态回退，保存稳定检查点，避免在错误状态上继续操作；四是停止与升级条件，限制最大步数、次数、Token或时间，并在关键信息缺失或高风险判断时请求人工介入。

可靠Agent不是永不失败，而是知道哪里失败、为何失败、还能尝试什么，以及何时必须停止。评测与可观测性构成支撑层：日志、轨迹和结果指标帮助团队判断问题来自Prompt、上下文、工具还是编排。

5. 权限与沙箱：边界不能依赖模型自觉

当AI只生成内容时，错误主要影响回答质量；当Agent能发送邮件、修改文件、操作账号或发起支付时，错误会直接改变现实状态。

在系统Prompt中写未经同意不得执行高风险操作很有必要，但不能成为唯一防线。Prompt影响输出概率，不是具有强制效力的权限系统。模型可能误解场景，也可能在长任务中忽略早期约束。真正的权限控制必须位于模型之外。

Agent应遵循最小权限原则。读取信息、生成草稿、修改数据和不可逆操作需要不同授权等级：低风险操作可以自动执行，可恢复操作保留撤销能力，高风险操作必须确认，有些动作则完全不开放。

重要任务应在沙箱或隔离环境中运行，删除、覆盖、发布和支付等行为优先采用可撤销机制。OpenAI在Codex实践中为代码修改提供独立环境，并让Agent读取界面、日志和指标，用于复现问题和验证修复。

Prompt负责告诉Agent什么不应该做，权限系统负责确保它确实做不到。至此，五层形成闭环：上下文提供信息，工具赋予行动能力，Memory维持连续性，编排处理过程与失败，权限限定行动边界。任何一层缺失，都可能让一个看起来聪明的模型变成并不可靠的Agent。

五、为什么继续优化Prompt解决不了这些问题

当Agent表现不稳定时，修改Prompt通常是成本最低的第一步。但如果没有先判断故障属于哪一层，Prompt很容易成为所有系统问题的临时补丁。

Agent找不到最新资料，问题可能是知识库未同步、权限错误或检索质量不足；它重复同一操作，问题可能是系统没有记录失败类型与已尝试路径；它声称完成但实际失败，说明缺少外部验收；它执行越权操作，则暴露了权限系统缺口。这些问题都不能靠一句更严厉的指令稳定解决。

Prompt当然仍应优化。如果模型误解目标、工具说明有歧义或输出要求不清，改Prompt就是正确方案。更合理的诊断顺序是：是否理解目标，是否获得正确信息，是否正确使用工具，是否保存状态，是否处理异常，是否拥有合适权限，是否验证最终结果。

只有第一项主要属于传统Prompt Engineering。团队把所有异常塞进系统Prompt，看似在完善规则，实际上是在用概率性的语言约束替代确定性的系统设计。Agent工程需要的不是预判一切的超级Prompt，而是一套能够暴露失败、定位原因并选择处理方式的执行系统。

六、公开产品案例：模型能力如何被系统承接

从Codex、Claude Code等编码Agent的公开实践中，可以看到共同趋势：当模型开始承担长时间、多步骤任务后，团队优化重点会转向工具、环境和反馈机制。编码Agent不能代表所有Agent，但其结果可通过测试验证，适合观察Harness的价值。

OpenAI公开了一项内部实验：团队使用Codex构建并迭代软件产品，人类主要负责设定方向、确定验收标准和验证结果。案例最值得关注的不是代码量，而是团队处理失败的方式。

当Codex无法完成任务时，工程师不是简单换一种Prompt，而是追问系统缺少什么，以及如何让能力对Agent既可理解又可执行。团队让Agent读取界面、日志、指标和评审反馈，在独立环境中复现问题、修改并验证；测试、审查和恢复被逐渐写入系统。

OpenAI也明确提醒，这种表现高度依赖特定仓库结构和工程投入，不能直接推广到所有产品。它更像方向性样本：模型能力只有进入合适环境，才可能被持续释放。

Anthropic的实践提供了另一个例子。在构建用于SWE-bench的编码Agent时，团队发现Agent离开项目根目录后，使用相对路径容易出错。他们没有继续在Prompt中反复提醒注意当前目录，而是修改工具，要求始终使用绝对路径，减少了这类错误。

这个例子揭示了Harness的基本方法：Agent反复犯同一种错误时，不要只教育模型，还要检查系统是否让错误过于容易发生。Prompt提醒提高正确行为的概率，工具约束则直接改变可执行行为的边界。

Hugging Face优化官方命令行工具时，也专门考虑Agent的使用方式。其公开测试显示，在一组Hub任务上，面向Agent优化的CLI和Skill相比自行组合调用，能够减少复杂任务的Token消耗，并降低误报成功。这不是在证明CLI必然优于SDK，而是说明即使模型不变，交互方式也会影响成功率、成本和错误类型。

这些案例没有证明Prompt无关紧要。Codex仍通过Prompt接收任务，Claude仍需要清楚的工具描述，Hugging Face的Skill也包含面向Agent的指引。它们共同证明的是：Prompt决定Agent如何开始，Harness决定它能否继续、纠错并完成。

七、为什么Harness会成为下一个竞争点

说Harness会成为下一个竞争点，不意味着模型不再重要。模型仍决定能力上限，真正变化的是应用层竞争逻辑：当多家产品可以接入相近模型，用户感知到的不是排行榜分数，而是产品能否以可接受成本稳定完成任务。

第一，模型决定能力上限，Harness决定能力兑现率。同一个模型接入不同产品，一种一次塞入全部资料，另一种允许动态检索；一种开放大量重叠工具，另一种只提供最小集合；一种让模型自行判断完成，另一种通过外部系统验证。用户得到的不会是同一种Agent。

第二，Harness更容易形成业务专属性。Prompt可以被模仿，基础模型也能通过API共享，但真实业务中的数据更新机制、工具接口、失败恢复、授权规则、验收标准和评测集合需要长期积累，不会因接入更强模型自动出现。

同样是客服Agent，电商退款、银行挂失和软件故障处理面对的权限与风险完全不同。什么情况下自动处理、什么情况下转人工，仍需团队设计。Harness是模型能力与业务规则之间的连接层。

第三，竞争指标从回答质量转向任务经济性。Agent即使成功，若调用大量无关工具、反复推理或频繁人工接管，仍可能没有商业可行性。成功率、单位任务成本和可控性共同决定它能否从演示进入生产：跑通一次证明可能性，反复跑通才证明工程能力。

第四，清晰的Harness可以降低对单一模型的依赖。如果业务逻辑都隐含在特定模型和庞大Prompt中，更换模型往往要重新调试全部行为；如果上下文、工具、状态、权限和评价标准都有明确接口，团队就更容易比较不同模型，并在升级时验证行为变化。

Harness不能与模型完全解耦，但清晰的结构能让模型差异被观察、测试和管理。它形成的优势不是新名词或更多中间件，而是持续提高模型能力的兑现效率。

八、对AI产品经理意味着什么

Harness Engineering不要求产品经理取代工程师，却会改变定义需求和验收结果的方式。过去，AI功能PRD可能重点描述输入、Prompt、输出和页面；进入Agent阶段，产品经理需要设计一条能够持续执行并接受验证的任务链。

首先，PRD要从功能说明转向任务闭环。以自动生成并发送周报为例，需求还应说明数据来源、统计周期、冲突处理、内容标准、发送前确认、收件人识别、失败处理，以及什么外部状态能够证明完成。

这些内容对应上下文、工具、状态、编排、权限和验证。当Agent可以动态决定路径时，这些机制本身就是产品行为，不能视为纯技术细节。

其次，要同时设计成功和失败路径：哪些错误能自动恢复，最多重试几次，首选工具不可用时是否有替代方案，何时必须询问或人工确认，中断后能否从稳定状态继续。

这里需要避免一种倾向：为了让Agent显得自主，尽量减少用户参与。真正有价值的自主不是Agent从不提问，而是它知道什么时候可以推进，什么时候继续行动会扩大风险。人工确认不是能力不足的临时补丁，而可以是Harness中主动设计的一环。

再次，产品指标要从回答质量升级为任务指标。Agent产品至少需要关注端到端任务完成率、首次成功率、平均执行步数、工具调用失败率、重试与回退比例、人工接管率、错误完成率，以及单次成功任务成本。

其中，错误完成率尤其重要。一个主动承认失败的Agent通常比错误宣称成功的Agent更安全，因为前者能够进入恢复流程，后者会让错误直接流入业务系统。评价一个Agent，也不能只看最终答案，还要观察行动轨迹、工具结果和外部状态。

最后，团队需要建立Agent故障诊断树。线上结果变差时，不应默认让Prompt工程师继续调词，而应依次判断：Agent是否理解目标，是否获得完整且最新的信息，是否选择并正确调用工具，是否保留目标和中间状态，是否识别失败并重试、回退或停止，是否越权，以及是否有外部证据验证结果。

只有第一类问题主要通过修改Prompt解决，其他问题往往要调整数据链路、工具接口、状态结构、执行逻辑或权限规则。这种诊断方式能让团队从“模型为什么又不听话”，转向可验证的系统问题。轻微讽刺地说，如果每次故障都归因于Prompt不够详细，那么系统设计当然显得很完整——承担责任的只剩一段文字和一个不会参加复盘会的模型。

在Harness视角下，AI产品经理需要定义四件事：Agent依据什么判断，拥有哪些行动能力，如何处理失败，以及产品如何证明目标实现。产品经理的价值，在于找到模型概率性与业务确定性之间的边界。

未来，AI产品经理交付的可能不只是一张功能流程图，而是一份Agent运行合同：明确目标、资源、状态、权限、异常和验收方式。Prompt定义Agent应该怎样理解，Harness则定义它如何进入真实业务。

九、Harness也不是新的万能答案

Harness Engineering没有发明上下文管理、工具调用、状态机、权限控制和软件测试。它的价值，是在模型成为行动主体后，把这些能力重新组织起来。因此，不能因为使用框架、接入MCP或增加Memory，就认为已经完成Harness建设。衡量标准不是模块数量，而是它们是否提高成功率、降低成本，并让错误更可控。

不是所有AI功能都需要Agent。对摘要、分类、翻译和信息提取等边界清晰的任务，一次调用或简单工作流通常足够。强行引入自主规划、长期记忆和多Agent协作，只会增加延迟、成本与故障点。Anthropic建议从最简单的可行方案开始，只有复杂机制带来可测量收益时才逐步增加。对步骤可预先定义的任务，确定性工作流通常更稳定。

Harness越复杂，也不代表Agent越可靠。更多工具会增加选择冲突，更多记忆会引入过期信息，更复杂编排会增加调试难度。若没有清晰任务和评测，Harness很容易变成另一种模块堆叠。

合理的建设顺序应是：观察真实失败，判断问题层次，设计最小修复，通过评测验证，再决定是否保留。评测与可观测性之所以是支撑层，正是因为它们能够阻止团队仅凭感觉增加复杂度。

同时，相关概念的边界仍在形成。企业没必要急于设置首席Harness工程师，真正需要改变的是看待Agent失败的方式。

如果团队仍把所有问题归因于模型不够聪明或Prompt不够详细，即使采用Harness这个名称，工程思路也没有变化。反过来，即使从未使用这个词，只要团队持续优化上下文、工具、状态、失败恢复、权限与验证，实际上已经在进行Harness Engineering。

它不是一套标准答案，而是一种工程视角：不再要求模型凭借一段指令独自承担全部可靠性，而是让系统对Agent的行动结果负责。

结语：不要再试图用一段Prompt管理整个世界

Prompt Engineering不会消失，但它正在回到更准确的位置：负责建立模型对任务的初始理解，而不是独自承担Agent在真实环境中的全部可靠性。

当模型只生成内容时，优秀Prompt可能决定结果质量；当它需要获取信息、调用工具、保存状态并影响外部系统时，Prompt只是起点。Agent能否完成目标，还取决于上下文、工具、失败处理、权限和验收条件。

Harness Engineering推动的变化，是把注意力从怎样让模型表现得更聪明，转向怎样让模型能力被可靠使用。对AI产品经理而言，设计单位也从一次回答变成任务闭环：不仅定义Agent做什么，还要定义依据、边界、失败恢复和完成证明。

未来Agent的差异，未必来自更长的Prompt或更强的模型。真正能够长期积累的，是模型周围那套与业务共同生长的执行系统。

Prompt告诉模型应该做什么。

Harness决定它能不能把事情做完。

AI Agent的下一阶段竞争，也将从如何向模型提问，转向如何为模型建立一套真正可以工作的环境。