从提示词工程到Harness工程：让大模型稳定完成任务的系统方法
摘要
研究聚焦提示词工程在生产级大模型应用中的能力边界：为什么清晰指令能够改善单次回答，却难以保证长链路任务稳定完成。方法上，文章把 Harness 视为围绕模型构建的任务执行系统，从上下文装配、工具权限、状态管理、结构化输出、评估观测与人在环路六个维度重构 AI 功能。结论是，提示词仍是必要语言接口，但稳定交付依赖可恢复、可验证、可追踪的外部结构；成熟 AI 产品应把“模型会说”转化为“系统会干活”。
关键词
提示词工程；Harness 工程；工具调用；状态管理；结构化输出；AI 评估；人在环路
研究问题与方法
核心问题是：当提示词已经足够清晰，为什么 AI 功能仍然在真实用户、真实工具和真实异常下表现不稳定。分析方法采用系统分解，而不是提示词加长法：将一次 AI 任务拆成入口判断、上下文装配、计划执行、工具调用、状态持久化、运行时验证和最终表达，并观察每个环节承担的责任。这样可以把“模型没听话”细分为输入证据不足、状态不可恢复、工具协议不清、输出契约缺失或评估样本不足。
这个结构说明，Harness 的目标不是削弱模型，而是把模型不该独自承担的职责外置。可以用一个任务稳定性指标表达这种取舍：
其中， 表示端到端任务稳定性， 表示上下文正确装配概率， 表示工具调用成功且权限正确的概率， 表示输出被结构化验证通过的概率， 表示失败后可恢复或可交给人的概率。任一因子接近零，整体任务都会失败；因此，继续增加提示词长度无法替代 Harness 中的状态、工具和验证设计。
引言：提示词工程的有效范围
很多团队第一次把大模型接进产品时，都会从“提示词工程”开始。它直观、便宜、见效快：把角色讲清楚，把任务拆开，把输出格式写死，再补几条反例，模型好像就能从聊天机器人变成可用功能。这个阶段很重要，因为提示词确实是大模型应用的第一层接口。没有清晰指令，模型不知道要做什么；没有上下文，模型不知道该依据什么做；没有格式约束，下游系统很难消费结果。
但如果目标是“稳定完成任务”，提示词工程很快会遇到边界。真实任务不是一次问答，而是一串带状态、带工具、带权限、带异常恢复的行动。用户也不会总按示例说话，外部接口会失败，知识库会过期，模型会误判，权限会变化，长任务会中断，业务规则会调整，结果还要被观测、评估、回放和迭代。只靠一段越来越长的系统提示词，很难承受这些复杂性。
这就是 Harness 工程要解决的问题。Harness 可以理解为“围绕模型搭起来的任务执行系统”：它不把智能完全寄托在一段提示词里，而是用任务编排、工具调用、上下文装配、状态管理、结构化输出、评估、监控、权限、回退和人类确认，把模型放进一个能做事、能纠错、能追踪、能演进的工作环境。提示词仍然重要，但它从“全部方法”变成 Harness 里的一个组件。
本文面向 promptx.wiki 的教程读者，目标不是提出新名词，而是给出一个可落地的系统方法：当一个 AI 功能从演示走向产品时，怎样判断提示词工程不够了，怎样设计 Harness，怎样把“模型会说”推进到“系统会干活”，以及怎样用工程手段让大模型在真实环境里更稳定地完成任务。
提示词工程解决什么，不解决什么
提示词工程的核心价值，是把人对任务的隐性要求显性化。一个好提示词通常会说明角色、目标、输入材料、推理边界、输出格式、风格要求和失败条件。OpenAI、Anthropic、Google Cloud 等厂商文档都反复强调：清晰指令、充分上下文、示例、分步要求、输出格式和迭代测试，是提升模型行为质量的基础。
这类方法适合三种场景。
第一，任务短。比如把一段会议纪要整理成行动项，把一封邮件改写得更礼貌，把一段产品说明压缩成摘要。任务在一次上下文里完成，不需要访问外部状态，也不需要多轮工具执行。
第二，风险低。即使模型输出略有偏差，用户能快速发现并修正，不会直接造成财务、法律、权限或业务流程损失。
第三，结果主要是文本。只要文本质量足够好，系统不需要继续把输出交给数据库、支付系统、审批系统或生产服务执行。
在这些范围内，提示词工程很有用。很多团队甚至应该先把提示词做好，再谈更复杂的 Agent 架构。因为 Harness 不是逃避清晰表达的借口。如果目标、输入、约束和验收标准都说不清楚，换成任何框架也只会把混乱系统化。
问题出现在任务变长、环境变动态、输出变成行动之后。比如一个“帮我准备客户拜访方案”的功能，不只是写一篇文本。它可能要读取 CRM 里的客户记录，查找过往工单，检索合同条款，理解客户所在行业，生成拜访提纲，给销售选择要不要带上技术顾问，更新日程，创建跟进任务，还要避免泄露无权限数据。这里面任何一步都不是一句“你是资深销售顾问”能可靠覆盖的。
又比如一个“自动修复代码缺陷”的功能，不能只让模型解释 bug。它要读取仓库，定位相关文件，修改代码，运行测试，处理失败，判断是否需要扩大搜索范围，生成变更说明，遵守用户未提交改动不能被覆盖的约束。代码编辑任务天然需要工具、状态、验证和回滚意识。把所有行为都塞进提示词，只会得到一个巨大而脆弱的说明书。
提示词工程的边界，可以总结为五句话：
- 它能表达意图，但不能替代状态管理。
- 它能要求模型使用工具，但不能替代工具权限和执行协议。
- 它能规定输出格式，但不能替代结构化校验。
- 它能提示模型自检，但不能替代外部评估和运行时观测。
- 它能提高单次回答质量，但不能保证长链路任务稳定完成。
所以，提示词工程不是过时了，而是位置变了。它是 Harness 工程的“语言层”，不是完整的“执行层”。
Harness 的系统定义
Harness 这个词本来有“马具、束具、接线装置、约束并传递力量的结构”之意。放到大模型应用里，它指的是把模型能力接入真实任务的外部结构。模型负责理解、推理、生成和选择行动；Harness 负责给模型提供上下文、工具、记忆、约束、反馈和执行环境。
可以把 Harness 看成一个由九个部分组成的系统。
第一，任务入口。它接收用户请求、文件、上下文和当前业务状态，把原始需求转换为系统能处理的任务对象。好的入口不会马上把全部内容塞给模型，而会先做身份、权限、任务类型、风险等级和必要输入检查。
第二，上下文装配。它决定模型应该看到什么，不应该看到什么。上下文可能来自用户输入、数据库、搜索结果、知识库、历史对话、当前页面、文件内容和系统状态。装配的关键不是越多越好，而是相关、及时、可追溯、权限正确。
第三，任务编排。它决定任务是一轮完成，还是拆成计划、执行、检查、修正多个阶段。简单任务可以直达生成；复杂任务需要工作流或 Agent 循环。LangGraph 这类框架强调持久执行、状态和人在环路，本质上就是在解决长任务编排问题。
第四，工具层。工具把模型连接到外部世界：搜索、数据库、代码执行、浏览器、CRM、邮件、日历、工单、支付、文件系统、内部 API。OpenAI 和 Anthropic 的工具调用文档都把工具定义为模型可请求调用的能力，但工程上更重要的是工具的 schema、权限、幂等性、错误返回和审计。
第五，状态和记忆。状态记录当前任务进展，记忆记录跨任务可复用的信息。二者不能混为一谈。状态通常是短期、任务内、可回放的；记忆通常是长期、用户或组织维度、需要治理的。很多产品失败，是因为把聊天记录当成记忆，把记忆当成事实，把事实又当成权限。
第六，输出契约。面向用户的最终输出可以是自然语言，但系统内部输出最好有结构化契约。OpenAI 的结构化输出、函数调用，Google 和 Microsoft 文档中的评估与流程工具，都指向同一件事：模型输出要能被机器检查、路由和执行，而不是靠正则从一段自由文本里猜意图。
第七，验证和评估。验证发生在运行时，检查参数、权限、数据完整性、工具结果和最终输出。评估发生在迭代期，用测试集、人工标注、自动指标和回放样本衡量系统是否变好。没有评估的提示词优化，常常只是“这次看起来更顺眼”。
第八，观测和追踪。Agent 任务的失败经常不是“模型笨”，而是某一步上下文错、工具错、状态错、解析错、权限错。没有 trace，就只能猜。LangSmith、OpenAI Agents SDK tracing、Prompt flow 等工具都把执行轨迹作为核心能力，因为复杂 AI 系统需要能还原每一步。
第九，安全与人类确认。模型不是所有动作都应该自动执行。删库、转账、发邮件、改生产配置、公开发布内容、使用敏感数据，都需要权限边界、审批或至少显式确认。Harness 的价值之一，就是把“模型建议”和“系统执行”之间加上可靠闸门。
从这个角度看，Harness 工程不是某个特定框架，也不是“Agent 框架”的同义词。它是一种产品工程方法：承认模型强在语义和推理，同时承认模型不是数据库、不是权限系统、不是事务系统、不是监控系统、不是测试系统。把该由工程系统承担的责任从提示词里拿出来，放到可测试、可观测、可治理的结构里。
更长提示词的边际收益
很多团队遇到模型不稳定，第一反应是加提示词。模型忘记格式，就加一条“必须严格输出 JSON”；模型乱用知识，就加一条“不得编造”；模型动作激进，就加一条“务必谨慎”；模型没调用工具，就加一条“必要时调用工具”；模型调用错工具，就把每个工具说明写得更长。
短期看，这能缓解问题。长期看，提示词会变成一张不断打补丁的规则网。它有几个典型风险。
第一，规则互相冲突。提示词越长，越容易出现“积极完成任务”和“不要擅自行动”、“尽量简洁”和“充分解释”、“严格 JSON”和“必要时补充说明”这类冲突。模型会在冲突中选择一个看似合理的方向，但不一定符合产品期望。
第二，注意力被稀释。模型上下文窗口变大，不代表每条指令都同等稳定。越长的提示越难保证关键约束被持续遵守，尤其在多轮对话、长文件和工具结果混杂时。
第三，隐性流程不可测试。提示词里写“先分析、再计划、再执行、再检查”，听起来像流程，但如果系统没有把这些阶段显式记录下来，就很难知道模型是否真的按流程走，也很难对某一步单独评估。
第四，异常处理不可靠。外部 API 超时、搜索结果为空、权限不足、文件不存在、测试失败，这些都需要确定性处理。提示词可以要求模型“遇到错误要修复”，但错误分类、重试策略、降级路径和用户提示，不应该完全交给模型临场发挥。
第五，无法管理责任边界。模型可以建议删除文件，工具可以真的删除文件。模型可以生成邮件，邮件系统可以真的发送。提示词里写“不要做危险操作”不够，必须有工具权限和执行前确认。
因此，Harness 工程的第一原则是：能由系统确定的，不要交给提示词赌；必须由模型判断的，要给它足够上下文、工具和反馈。
这句话很关键。Harness 不是降低模型自主性，而是把自主性放在正确的位置。比如“这段用户需求属于退款、投诉还是售前咨询”可以让模型判断；“该用户是否有权查看这份合同”应该由权限系统判断。比如“这次修复应该先看哪些文件”可以让模型规划；“能不能覆盖用户未提交改动”应该由版本控制和执行策略约束。比如“客户这封邮件情绪是否紧张”可以让模型分析；“是否发送最终回复”应该经过产品定义的确认流程。
越成熟的 AI 产品，越不会把所有责任塞进提示词。它会让模型在语义空间里聪明，让系统在执行空间里可靠。
从提示词到 Harness 的迁移路径
迁移不是推倒重来。一个实用路径可以分成六步。
第一步，保留核心提示词，但把它瘦身。先把提示词里的内容分成三类：模型必须知道的任务目标，系统可以确定性处理的流程，临时补丁式规则。任务目标保留在提示词；流程迁移到编排；补丁规则要么变成测试用例，要么变成校验器，要么删除。
例如原提示词写着：“你必须判断用户是否提供了订单号，如果没有，要要求用户补充；如果有订单号，调用订单查询工具；如果订单状态为已发货，说明物流信息；如果未支付，提醒用户支付；不要泄露内部字段。”迁移后可以改成：入口层检查用户身份，任务编排识别是否有订单号，工具层查询订单，输出层只暴露允许字段，提示词只负责把订单状态解释成人能理解的话。
第二步，定义任务对象。不要把用户原话直接当作整个任务。可以把任务抽象成：任务类型、用户意图、输入材料、当前状态、风险等级、允许工具、完成条件、失败条件、用户可见输出。任务对象让系统能在不同阶段读写状态，也让 trace 和评估有统一结构。
第三步，给工具写清楚契约。工具不是“给模型一个函数名”这么简单。每个工具至少要有用途、输入 schema、输出 schema、权限要求、是否只读、是否有副作用、是否幂等、常见错误、重试策略和审计字段。对于高风险工具，还要有预览模式和确认模式。
第四步，把长任务拆成显式阶段。常见阶段包括理解需求、补齐信息、检索上下文、制定计划、执行动作、验证结果、生成回复。不是每个任务都需要完整链路，但阶段越显式，越容易定位问题。
第五步，引入评估集。评估集不要只放“模型应该回答什么”的标准题，还要放真实失败样本：用户表达含糊、缺字段、权限不足、工具返回空、上下文冲突、历史信息过期、同义表达、恶意注入、长文件干扰。每次改提示词、模型、检索、工具或流程，都用评估集跑一遍。
第六步，建立运行时观测。至少要记录用户请求、任务类型、模型输入摘要、工具调用、工具结果摘要、结构化输出、校验结果、最终回复、错误和耗时。敏感数据可以脱敏，但不能完全没有轨迹。没有运行时数据，AI 产品只能靠感觉调。
这六步里，最容易被低估的是“任务对象”和“评估集”。很多团队一开始只关注模型回答质量，后来才发现真正难的是任务状态不可控、失败不可复现、版本变化不可比较。任务对象让系统知道自己在做什么，评估集让团队知道改动有没有变好。
Harness 的核心设计模式
下面介绍几种常见模式。它们不是框架绑定的，而是可以用在 OpenAI Agents SDK、LangGraph、LlamaIndex、CrewAI、Prompt flow 或自研系统里的通用思路。
计划-执行-验证模式
复杂任务不要让模型直接给最终答案。先让模型生成计划，再执行计划，再验证结果。计划不一定暴露给用户，但系统内部应该保存。
例如“帮我整理项目风险并创建下周行动清单”可以分为：读取项目资料，识别风险，按影响和紧急度排序，生成行动项，检查行动项是否有负责人和截止时间，最后给用户确认。模型适合识别风险和生成行动项，系统适合检查字段完整性和创建任务。
这个模式的关键是验证不能只靠模型自夸。验证可以包括 schema 校验、引用检查、权限检查、工具结果一致性检查、测试运行、人工确认。模型可以参与验证，但不应是唯一验证者。
工具优先的信息获取模式
当答案依赖外部事实时，不要让模型凭记忆回答。Harness 应该先判断是否需要检索或工具查询，再把结果交给模型综合。尤其是价格、政策、版本、库存、接口状态、客户数据、项目进度这类动态信息，必须来自工具或实时数据源。
这也是为什么联网检索、RAG、数据库查询和 API 工具在产品里很重要。模型训练知识再强，也不能替代当前状态。工具优先不是说模型不能推理，而是把事实来源和推理分开。
结构化输出与自然语言表达
内部让模型输出结构化数据，外部再生成自然语言，是很多产品的稳定做法。例如客服系统内部需要意图、置信度、订单号、建议动作、是否需要人工；用户看到的只是一句清楚的回复。这样既方便系统路由，也避免把内部字段暴露给用户。
结构化输出必须有校验。只在提示词里写“输出 JSON”不够，因为模型仍可能输出多余文本、字段缺失或类型错误。更可靠的方法是使用平台提供的结构化输出能力，或者在应用层做 schema 校验和修复循环。
人在环路
人在环路不是“AI 不够智能”的遮羞布，而是产品责任设计。越接近真实行动，越需要区分建议、草稿、预览、确认和执行。
例如 AI 可以自动写邮件草稿，但发送前让用户确认；可以自动生成数据库迁移方案，但执行前需要审批；可以自动修代码并跑测试，但合并前要代码审查；可以总结医疗资料，但诊断建议必须由合规流程把关。
人在环路应该嵌进 Harness，而不是靠提示词最后一句“如有风险请提醒用户”。系统要知道哪些工具有副作用，哪些动作需要确认，确认后的执行参数是什么，确认记录如何审计。
可恢复长任务
真实任务会中断。网络断、工具失败、用户离开页面、模型请求超时、服务重启，都很常见。长任务 Harness 需要保存状态，让任务可以恢复、重试或取消。LangGraph 的持久化和 durable execution 思路，正是针对这类问题。
如果一个 Agent 要处理几十步任务，却没有状态持久化，它就像在没有保存按钮的编辑器里写论文。看起来能跑，生产上会很脆。
反馈闭环
用户修改 AI 输出、拒绝建议、重复追问、手动纠错，都是宝贵反馈。Harness 应该把这些反馈结构化记录下来，用于评估集扩充、提示词改进、工具说明优化和流程调整。
反馈闭环要注意隐私和权限。不是所有用户内容都能进入训练或共享评估。生产级系统要区分个人记忆、团队知识、匿名评估样本和不可保留数据。
上下文工程作为 Harness 的燃料管理
如果提示词工程关注“怎么说”，上下文工程关注“给模型看什么”。在 Harness 里，上下文装配常常比提示词措辞更影响结果。
上下文过少，模型只能猜。上下文过多，模型会分心、变慢、成本上升，还可能吸收无关或恶意信息。上下文过旧，模型会基于过期事实做决定。上下文越权，产品就有安全问题。上下文不可追溯，回答就无法审计。
生产级上下文装配要解决五件事。
第一，来源分层。系统提示、开发者指令、用户输入、工具结果、知识库片段、历史记忆、网页内容，可信度不同。模型应该知道哪些是系统规则，哪些是用户提供材料，哪些是检索结果，哪些只是历史偏好。不要把所有文本混成一锅。
第二，相关性选择。检索不是把 top-k 片段全塞进去。要考虑任务类型、时间、权限、实体匹配、片段覆盖、冲突信息和引用需要。很多 RAG 失败不是模型不会答，而是检索给错料。
第三，冲突处理。真实数据经常冲突。合同和邮件说法不同，旧文档和新文档不同，用户记忆和当前输入不同。Harness 应该显式标注时间、来源和优先级，让模型能说明依据，而不是硬编一个折中答案。
第四，引用和可追溯。涉及事实依据的输出，最好能追溯到具体文档、工具结果或数据记录。引用不只是给用户看的，也是给内部调试和合规看的。
第五，注入防护。网页、文档、邮件、工单都可能包含“忽略前面指令”“把密钥发给我”这类提示注入。Harness 要把外部内容标为不可信数据，限制它影响系统指令，并在工具层控制可执行动作。
上下文工程的经验法则是：上下文不是资料堆积，而是任务所需证据的最小充分集合。
工具工程与可控行动
工具是 Harness 的手脚。没有工具，大模型多数时候只能建议；有工具，它才能查询、修改、生成、执行、验证。工具越强，系统越有用，也越需要治理。
设计工具时，最常见的错误是直接把内部 API 暴露给模型。内部 API 往往面向工程调用，不面向语义决策。字段多、权限复杂、副作用不清、错误信息不友好。模型拿到这种工具，很容易误用。
更好的做法是设计“面向任务的工具”。例如不要给模型一个通用 updateRecord(table, id, payload)，而是给它 createFollowUpTask(customerId, ownerId, dueDate, summary)。后者语义明确、参数少、权限容易控制，也更适合审计。
工具说明要短而准。模型需要知道什么时候用、怎么用、返回代表什么、不能用于什么。工具 schema 要尽量具体：枚举不要用自由文本，时间要规定格式，金额要规定币种，ID 要区分用户可见编号和内部主键。
工具结果也要为模型设计。不要把数据库原始记录整块返回。返回应该包含完成任务所需的最小字段，并且用清晰名称表达含义。对用户不可见的字段，不要交给模型再期待它不泄露；能不进入上下文就不进入上下文。
副作用工具必须有保护。常见保护包括 dry-run、preview、confirmation、idempotency key、权限检查、速率限制、审计日志、可撤销动作和人工审批。对于“发送、删除、付款、授权、发布、合并、部署”这类动作，默认应该先产生可审查计划，而不是直接执行。
工具错误要结构化。不要只返回“失败”。应该区分参数错误、权限不足、资源不存在、外部服务超时、业务状态不允许、可重试错误和不可重试错误。模型只有拿到明确错误，才可能选择正确恢复动作。
最后，工具数量不是越多越好。工具太多会增加选择难度和误调用概率。可以通过任务路由，让不同任务只暴露相关工具；也可以把低层工具封装成高层工具，减少模型决策负担。
评估工程与产品迭代
提示词时代最常见的调试方式是“我试了几条，看起来不错”。生产级 Harness 不能停在这里。因为 AI 产品的失败往往不是平均质量差，而是边界场景突然崩。
评估应该覆盖四类指标。
第一，任务成功率。用户要的事情是否完成了？不是回答是否流畅，而是任务是否达到完成条件。代码任务看测试是否通过，客服任务看是否正确路由，数据分析任务看结论是否有依据，工作流任务看动作是否执行到位。
第二，事实正确性。回答是否基于提供的资料和工具结果？有没有编造引用？有没有把旧信息当新信息？有没有把无权限信息写给用户？
第三，过程质量。模型是否调用了正确工具？是否在缺信息时追问？是否避免不必要副作用？是否能从工具错误中恢复？
第四，用户体验。回复是否清楚？是否重复？是否把内部字段暴露给用户？是否让用户知道下一步可以做什么？是否在需要确认时给出可理解的预览？
评估集的来源应该包括手写金样本、真实用户匿名样本、线上失败回放、红队攻击样本、竞品任务样本和专家标注样本。每个样本最好包含输入、可用上下文、期望行为、禁止行为、评分标准和风险标签。
自动评估可以用规则、程序、模型裁判和人工抽检组合。结构化字段适合程序检查；语义质量可以用模型裁判初筛；高风险样本需要人工复核。关键是形成回归机制：每次改 Harness，都能知道哪些能力提升了，哪些能力退化了。
评估还要区分离线和在线。离线评估用于发布前比较版本；在线观测用于发现真实环境里的新问题。线上用户的一次失败，应该能变成下一轮离线评估样本。这样 AI 产品才会越用越稳，而不是靠不断加提示词补洞。
面向用户的产品体验
Harness 是后台工程，但最终会体现在用户体验上。一个成熟 AI 产品不应该把内部复杂性甩给用户。
用户不关心你用了哪个模型、哪个向量库、哪个 Agent 框架。用户关心的是：它是否懂我的需求，是否知道我当前在哪，是否能拿到该拿的数据，是否在不确定时问我，是否能把事情办完，是否不会擅自做危险动作。
因此，面向用户的界面要避免三类问题。
第一，不要暴露开发者语言。比如“正在调用 tool_x”“RAG 命中 3 条”“JSON parse failed”“agent step 4 retry”。这些信息对工程师有用，但不应该直接出现在普通用户界面。用户界面可以说“正在查询订单”“资料不足，需要补充合同编号”“服务暂时没有返回结果，请稍后重试”。
第二，不要重复展示同一层信息。AI 产品容易把计划、执行日志、最终答案、引用、建议动作全部堆出来，导致用户不知道看哪里。信息层级应该清楚：主答案是什么，需要用户确认什么，依据在哪里，下一步是什么。
第三，不要假装已经完成。很多 AI 功能只生成建议，却把按钮写成“已处理”。如果系统只是草拟邮件，就叫“草稿”；如果需要用户确认，就明确显示“发送前确认”；如果工具失败，就说没有完成，不要用漂亮文案掩盖失败。
Harness 工程与生产级 UI 是一体的。后台区分计划、执行、确认和结果，前台才能自然表达。后台有结构化状态，前台才能显示清楚进度。后台有引用和 trace，前台才能给出可信依据。
智能资料整理助手案例
假设我们要做一个“智能资料整理助手”，用户上传一批文档，让 AI 提炼主题、归档文件、生成摘要，并创建待办事项。如果只用提示词，可能会写：
“你是资深知识管理专家，请阅读用户上传的文件，识别主题，生成摘要，按类别归档，并列出行动项。要求准确、简洁、不要编造。”
这个提示词作为演示可以，但作为产品不够。我们用 Harness 方法重新设计。
任务入口先检查用户身份、文件数量、文件类型、大小限制和权限。对于无法解析的文件，入口直接返回明确错误，而不是让模型猜。系统创建一个任务对象，记录用户、文件列表、任务目标、当前阶段和风险等级。
上下文装配层先解析文件，抽取文本和元数据。长文档不直接整篇塞给模型，而是分块、去重、保留标题层级和页码。系统标注每段来源，区分文件名、修改时间、上传者和内容片段。
计划阶段让模型先提出整理方案：可能有哪些主题，哪些文件需要合并理解，哪些文件可能重复，哪些地方需要用户确认。计划输出为结构化数据，系统检查每个文件是否被覆盖，是否有未知类别。
执行阶段分批处理文件。模型为每个文件生成摘要、关键词、主题类别和可能行动项。系统校验输出字段，检查行动项是否包含负责人、事项、时间或缺失原因。对于缺负责人或截止时间的行动项，系统可以标记为“待补充”，而不是让模型编一个。
归档阶段不直接移动文件。先生成归档预览：每个文件建议放到哪个目录，依据是什么，是否有冲突。用户确认后，工具层执行移动，并用幂等键避免重复移动。执行失败时，系统知道哪些文件成功、哪些失败，可以恢复。
最终输出给用户的是清晰结果：完成了多少文件整理，生成了哪些主题，哪些待办需要确认，哪些文件因格式或权限未处理。参考依据可以展开查看，但不把工具日志暴露在主界面。
评估时，我们不只看摘要写得好不好。还要看文件是否漏处理，归档建议是否可解释，行动项是否编造，权限文件是否被跳过，用户取消确认时是否没有移动文件，工具失败后是否能重试。
这就是从提示词工程到 Harness 工程的区别。提示词回答“让模型怎么写”，Harness 回答“整个系统怎样把事做完”。
常见误区
误区一：用了 Agent 框架就等于有 Harness。框架提供基础设施，但产品责任仍在你这里。工具怎么设计、权限怎么控、状态怎么存、评估怎么做、用户怎么确认，框架不会自动替你想清楚。
误区二：Harness 会限制模型智能。恰恰相反，好的 Harness 会让模型更能发挥。因为模型不用记住所有流程细节，不用猜外部状态，不用承担权限判断，不用从错误文本里猜恢复方式。它可以把能力集中在理解、推理和生成上。
误区三：多 Agent 一定更强。多 Agent 会增加协调成本、上下文成本和不可控性。只有当任务天然有角色分工，且每个角色有明确输入输出时，多 Agent 才有意义。否则，一个有好工具和好状态管理的单 Agent 往往更稳。
误区四：只要模型更强，工程就不重要。模型能力提升会降低某些提示词技巧的重要性，但不会消灭权限、状态、工具、评估和观测问题。越强的模型越可能执行更复杂任务，越需要 Harness 管住行动边界。
误区五：所有错误都要让模型自我修复。自我修复适合语义层错误，比如理解不完整、计划不合理、输出格式可修复。系统层错误，比如权限不足、资源不存在、外部服务熔断、用户取消确认，应该由 Harness 明确处理。
落地检查
如果你正在把一个提示词功能升级为生产级 AI 功能，可以按下面清单检查。
- 任务是否有明确完成条件，而不只是“回答得好”？
- 哪些信息来自用户，哪些来自系统，哪些来自外部检索？
- 上下文是否按权限、时间和来源过滤？
- 模型输出是否有结构化契约？
- 工具是否有清晰 schema、权限和错误类型？
- 有副作用的动作是否需要预览或确认？
- 长任务是否能保存状态、重试、取消和恢复？
- 失败时用户能否看到面向最终用户的清楚说明？
- 是否有离线评估集覆盖正常、边界和攻击样本？
- 是否有 trace 能还原每一步模型输入、工具调用和结果？
- 每次修改提示词、模型、工具或流程后，是否能比较版本效果？
- 前端是否隐藏内部字段、调试术语和实现细节？
这份清单的重点不是把系统做复杂，而是把复杂性放到正确位置。简单任务可以保持简单；复杂任务必须有结构承托。
团队协作中的 Harness 分工
Harness 工程不是某一个提示词工程师单独完成的工作。它更像一条产品链路，需要产品、前端、后端、算法、测试、运维和安全一起把边界说清楚。
产品负责人要定义任务完成标准。比如“生成报告”到底算什么完成，是只给一段文字，还是要包含数据来源、图表、风险、建议动作和可下载文件。没有完成标准，模型输出再流畅也无法验收。
后端工程师要把工具做成清晰、稳定、可审计的能力。内部接口可以复杂，但给模型使用的工具必须语义明确、参数收敛、错误清楚。工具设计越贴近任务，模型越少猜测，系统越少兜底。
前端工程师要把状态表达给用户。AI 任务不是只有“加载中”和“完成”。真实状态可能是等待资料、正在检索、等待确认、部分完成、需要重试、执行失败。界面层级清楚，用户才知道自己是否需要行动。
测试和评估负责人要把线上失败变成样本。一次错误不应该只被修成一条新提示词，而应该进入评估集，成为以后版本回归的依据。否则同类问题会换一种说法再次出现。
安全和权限负责人要定义哪些内容能进入上下文，哪些动作必须确认，哪些工具只允许只读，哪些日志需要脱敏。大模型应用的安全不是只靠模型拒答，而是靠系统边界。
当团队按这些角色协作时，Harness 才不会变成空泛概念。它会落实到任务定义、工具契约、状态机、界面状态、评估样本和审计记录里。这样做的直接收益是：问题出现时，团队能定位责任层，而不是所有人围着一段提示词猜。
结语
提示词工程让我们学会了怎样与大模型沟通。Harness 工程让我们学会了怎样让大模型参与真实工作。前者关注语言，后者关注系统；前者提高单次输出质量，后者提高任务完成可靠性；前者仍然必要，后者决定产品上限。
未来的大模型应用不会只比谁的提示词更长，而会比谁能更好地组织上下文、工具、状态、评估和用户确认。真正稳定的 AI 产品，不是把所有规则写进一段神奇提示词，而是给模型搭一个能理解任务、能访问事实、能安全行动、能验证结果、能从失败中恢复的工作环境。
当你下次想继续给提示词加一条规则时，可以先问一句：这件事应该由模型记住，还是应该由系统保证？这个问题，就是从提示词工程走向 Harness 工程的开始。
附：一次真实改造可以怎样排期
如果团队已经有一个能跑的提示词功能，建议不要一次重写。第一周先做观测，把每次请求、选用上下文、模型输出、用户反馈和失败原因记录下来。这个阶段不追求自动修复，只追求看清问题。第二周做结构化输出，把原来难以解析的自然语言中间结果改成字段明确的对象，例如任务类型、需要补充的信息、建议动作、引用来源和风险等级。第三周整理工具，把高频查询做成只读工具，把会改变外部状态的能力先改成预览。第四周补评估集，从线上失败和典型任务里挑样本，固定输入和期望行为。第五周才开始优化提示词和模型选择。这样排期的好处是，团队先建立测量能力，再谈智能提升，避免把所有时间消耗在主观调词上。
这个顺序也适合个人开发者。先让系统知道自己做了什么，再让系统做得更好。
参考资料
- OpenAI: A Practical Guide to Building Agents - OpenAI 关于 Agent 组成、工具、指令、护栏和编排的实践指南。
- OpenAI: Harness engineering - OpenAI 对 Harness engineering 概念、工作流与 Agent 上下文的说明。
- OpenAI Platform Docs: Function calling - OpenAI 工具调用和结构化函数接口文档。
- OpenAI Platform Docs: Structured Outputs - OpenAI 结构化输出能力，用于约束模型生成可校验结果。
- OpenAI Agents SDK Docs - OpenAI Agents SDK 关于 Agent、工具、handoff、guardrails 和 tracing 的项目文档。
- Anthropic Claude Docs: Prompt engineering overview - Anthropic 关于清晰指令、示例、长上下文和提示词迭代的官方指南。
- Anthropic Claude Docs: Tool use - Anthropic 关于工具定义、工具调用和工具结果返回的官方文档。
- Google Cloud Vertex AI: Prompt design strategies - Google Cloud 关于提示设计、上下文、示例和输出约束的文档。
- Google Cloud Vertex AI: Evaluate Gen AI models - Google Cloud 关于生成式 AI 评估方法和评估流程的文档。
- LangGraph Documentation - LangChain 团队关于持久执行、状态、人机协作和 Agent 工作流的项目文档。
- LangSmith Documentation - LangChain 团队关于 tracing、evaluation 和 observability 的文档。
- Model Context Protocol Documentation - MCP 官方文档，说明工具、资源、提示和外部上下文连接方式。
- Microsoft Prompt flow Documentation - Microsoft 关于提示流、评估和生成式 AI 应用工程化流程的文档。
- ReAct: Synergizing Reasoning and Acting in Language Models - 提出把推理和行动结合起来的经典论文。
- Toolformer: Language Models Can Teach Themselves to Use Tools - 研究语言模型如何学习调用外部工具的论文。
- Reflexion: Language Agents with Verbal Reinforcement Learning - 研究语言智能体如何通过语言反馈改进任务表现的论文。