原因不是提示词不重要。恰恰相反，提示词仍然重要。它是我们和大模型沟通任务、约束、风格和输出格式的第一层语言。一个烂提示词会让再强的模型也表现飘忽。但真实产品的问题从来不只在“怎么让模型说得更好”，而在“怎么让模型把事情稳定做完”。

这两个问题差别很大。

“说得更好”通常发生在一次对话里。你给模型一段材料，让它总结、改写、分类、翻译、写文案。提示词写清楚，结果就会好很多。

“稳定做完”发生在真实业务系统里。用户输入可能缺字段，数据在数据库里，知识在文档里，状态在第三方系统里，动作需要权限，接口可能超时，结果要写回系统，用户还可能中途改主意。模型不只是回答，还要检索、判断、调用工具、处理异常、等待确认、验证结果。

这时候，需要的不是更玄的提示词，而是 Harness 工程。

先说清楚：Harness 工程不是新瓶装旧酒

Harness 在大模型应用语境里，可以理解为“把模型接入真实任务的执行系统”。它包括提示词，但不止提示词；包括 Agent，但不等于某个 Agent 框架；包括工具调用，但不只是把函数丢给模型。

一个像样的 Harness 至少会考虑这些问题：

用户请求进来后，系统怎样判断任务类型？哪些上下文应该给模型？哪些数据不能给模型？模型可以调用哪些工具？工具失败怎么办？模型输出怎样校验？高风险动作要不要用户确认？长任务中断后能不能恢复？线上失败能不能回放？改了提示词以后怎么知道变好了还是变坏了？

这些问题都不是一句“你是一个严谨的 AI 助手”能解决的。

更直白一点说，提示词工程像是在教一个聪明人怎么回答问题；Harness 工程像是在给这个聪明人配办公室、资料柜、工作流、权限卡、审计日志、质检标准和协作流程。没有后者，聪明人也只能靠嘴干活。

OpenAI 最近专门讨论 Harness engineering，重点也在这里：真正有用的 AI 系统，不是把所有智能塞进模型本身，而是用外部结构把模型组织进任务环境。OpenAI 的 Agent 指南、Anthropic 的工具使用文档、LangGraph 的持久工作流、LangSmith 的 tracing 与 evaluation、MCP 的工具和资源协议，其实都在从不同角度回答同一件事：模型要进入真实工作，就需要一套 Harness。

只会提示词，真实产品会卡在哪里

很多 AI 产品原型看起来很顺，是因为演示环境太干净。用户输入是理想的，数据是提前准备好的，任务是短的，失败可以重来，安全风险没人管。一旦进入真实产品，问题会集中冒出来。

第一个问题：模型不知道当前事实。

比如用户问：“帮我看看这个客户下周拜访要准备什么。”模型如果只靠训练知识，最多给一套通用拜访建议。但产品真正需要的是：这个客户是谁，买过什么，最近工单是什么，合同快到期没有，销售上次记录了什么，是否有未解决投诉，同行业最近有什么变化。提示词可以要求“结合客户资料”，但资料在哪里、怎么查、哪些能看、哪些过期，必须由系统解决。

第二个问题：模型不知道能做什么。

一个客服 AI 可以查订单、改地址、退优惠券、创建工单、转人工。不同动作权限不同，风险不同，确认要求不同。你可以在提示词里写“谨慎操作”，但真正可靠的是工具层把只读查询和有副作用操作分开，把权限和确认做成硬约束。

第三个问题：模型输出不等于系统可执行。

模型说“建议创建一个跟进任务”，系统还需要负责人、截止时间、客户 ID、任务类型、提醒规则。自由文本很好读，但不好执行。真实产品内部需要结构化结果，最好能通过 schema 校验。否则就会出现“用户看起来满意，系统却没法落库”的尴尬。

第四个问题：长任务会断。

很多产品一开始只做“一问一答”，后来想做“帮我完成整件事”。比如生成报告、整理知识库、批量处理文件、修复代码、分析投放数据。这些任务可能要跑几十步。任何一步失败，如果没有状态记录，就只能从头再来。用户刷新页面、服务重启、接口超时，任务就丢了。长任务要靠状态和持久执行，不是靠提示词祈祷。

第五个问题：没人知道它为什么错。

AI 产品线上出错时，如果你只保存最终回答，很难查问题。是提示词没写清楚？检索拿错文档？工具返回脏数据？模型没按格式？权限判断漏了？用户输入本身有歧义？没有 trace，就只能猜。团队最后会陷入“再加一句提示词试试”的循环。

第六个问题：体验会暴露工程粗糙。

用户界面上出现“tool_call failed”“RAG top_k=5”“JSON parse error”“agent step retry”，这不是智能感，是半成品感。真实产品应该把内部过程转成用户能理解的话：正在查询、资料不足、需要确认、没有完成、稍后重试。提示词能润色文案，但如果后台没有清楚状态，前台也很难优雅。

Harness 工程到底带来什么价值

它最大的价值，是把 AI 产品从“靠模型临场发挥”变成“模型在系统里工作”。

价值一：把不该模型承担的责任拿出来

模型擅长理解自然语言、综合信息、生成内容、做模糊判断。它不擅长做数据库事务、权限系统、幂等控制、审计日志、网络重试、版本回滚。即使模型能描述这些东西，也不代表应该让它负责这些东西。

比如“这封邮件语气是否太强硬”可以让模型判断；“这封邮件是否真的发出去”应该由产品流程控制。比如“这个工单应该归到哪个问题类型”可以让模型判断；“这个用户能不能查看工单详情”应该由权限系统判断。比如“这段代码可能怎么修”可以让模型分析；“是否覆盖用户未提交文件”必须由工程工具保护。

Harness 的核心思路，就是让模型做模型擅长的事，让系统做系统必须保证的事。

价值二：让任务可以被拆解、追踪和恢复

真实任务不是一句话。它有阶段，有状态，有中间结果。Harness 会把任务拆成入口、理解、检索、计划、执行、验证、确认、输出等阶段。每个阶段都有输入输出，出错时知道卡在哪里。

这听起来像普通软件工程。没错，AI 产品最终还是产品工程。区别只是中间多了一个强大的语义推理组件。不能因为有了大模型，就忘了状态机、队列、日志、权限和测试这些基本功。

LangGraph 强调状态和 durable execution，OpenAI Agents SDK 强调 tracing、guardrails 和工具，LangSmith 强调评估和可观测性，这些工具背后的共同点都是：让 Agent 行为不再是一团黑盒聊天记录，而是可组织、可回放、可改进的执行过程。

价值三：让工具调用更安全

很多人做工具调用时，第一版会很兴奋：模型终于能查数据库、发邮件、改文件了。第二版就开始害怕：它会不会查错？会不会发错？会不会删错？会不会把内部字段说出去？

Harness 不会盲目扩大工具能力，而是给工具加边界。只读工具和写入工具分开；高风险动作需要确认；工具参数用 schema 约束；返回结果只包含必要字段；错误码结构化；每次调用可审计；必要时支持 dry-run。

这不是让 AI 变笨，而是让 AI 变成可信的协作者。一个没有权限边界的“全能 Agent”，在真实产品里不是高级，是危险。

价值四：让评估从“感觉不错”变成“有证据”

提示词调优最容易陷入主观判断。你改了一句话，试三条样例，觉得更好了。但真实用户有一百种问法，真实数据有一百种脏法。没有评估集，就不知道改动是提高了整体表现，还是只让你手里的例子更好看。

Harness 工程会把评估当成基础设施。正常样本、边界样本、失败回放、恶意输入、权限场景、工具异常，都应该进入评估。每次改模型、改提示词、改检索、改工具说明，都跑一遍。这样团队讨论的不是“我感觉”，而是“任务成功率、误调用率、格式失败率、人工接管率、用户确认通过率发生了什么变化”。

评估不是只给研究员用的。做客服、知识库、销售助手、代码助手、数据分析助手，都需要评估。没有评估，AI 产品很难从 demo 进化成稳定工具。

价值五：让用户体验更诚实

真实 AI 产品最怕假完成。明明只是生成了建议，界面却显示“已处理”；明明工具失败，文案却说“已为你完成”；明明需要用户确认，按钮却像已经执行。用户迟早会发现。

Harness 把状态分清楚：草稿、预览、待确认、执行中、已完成、部分完成、失败、需要补充信息。前端就可以用人话展示这些状态。用户知道 AI 做到了哪一步，下一步需要自己做什么，哪些内容来自资料，哪些内容是建议。

这比把一个长长的 Agent 思考过程展示给用户有用得多。用户不需要看内部链路，用户需要清楚、可信、可操作的结果。

一个社区里常见的误判：提示词越长，产品越稳

很多人遇到模型不稳，会继续加提示词。

模型编造，就加“不得编造”。

模型不查资料，就加“必须查资料”。

模型输出错格式，就加“必须严格 JSON”。

模型动作过头，就加“不得擅自执行”。

模型忘了某条规则，就加粗、重复、写三遍。

这在早期调试里可以理解，但长期看会变成提示词债务。提示词越长，规则越多，冲突越多，越难测试。团队甚至会害怕改提示词，因为不知道改动会影响哪里。

更好的做法是问：这条规则应该属于哪里？

“不得编造事实”不应该只是一句提示词，它还应该对应检索依据、引用校验和“不知道就追问”的流程。

“必须严格 JSON”不应该只是一句提示词，它还应该对应结构化输出、schema 校验和失败重试。

“不得擅自执行危险动作”不应该只是一句提示词，它还应该对应工具权限、预览、用户确认和审计。

“必须查资料”不应该只是一句提示词，它还应该对应任务路由、检索工具、上下文装配和来源标注。

提示词里的规则，如果本质上是系统责任，就应该迁移到 Harness。

从一个例子看差异：AI 销售助手

假设你要做一个 AI 销售助手。用户说：“帮我准备明天下午和 A 客户的沟通。”

提示词工程版本可能这样做：把模型设定成资深销售顾问，让它根据输入生成拜访提纲。结果可能也不错：开场、客户背景、痛点、方案、异议处理、下一步。

但真实产品版本会复杂得多。

首先，系统要识别 A 客户是谁。用户说的 A 可能是简称，可能有多个同名客户。Harness 要查询 CRM，并在歧义时让用户选择，而不是让模型猜。

然后，系统要查客户资料。包括行业、规模、联系人、当前商机阶段、历史沟通记录、合同状态、工单、最近使用情况。每个数据源都有权限，不是模型想看就能看。

接着，系统要判断任务目标。用户是要销售拜访提纲，还是续约风险分析，还是技术方案准备？如果信息不足，应该追问。

再然后，模型可以开始综合：客户可能关心什么，风险在哪里，推荐带哪些材料，哪些话题要避免，下一步目标是什么。

如果系统支持动作，还可以生成日程备注、创建跟进任务、草拟会后邮件。但这些动作需要预览和确认。AI 可以建议“创建一个会后 24 小时内跟进任务”，系统要让用户确认负责人和截止时间，不能直接乱建。

最终用户看到的不是一坨内部日志，而是一份清晰的准备卡片：客户重点、沟通目标、建议议程、风险提醒、推荐材料、待确认动作。每条重要事实可以展开来源。

这就是 Harness 的价值。它把“写一份提纲”升级成“围绕真实客户完成准备工作”。

再看一个例子：AI 代码助手

代码助手更能说明问题。因为代码任务天然需要行动和验证。

用户说：“这个登录 bug 帮我修一下。”

只会提示词的系统，会让模型解释可能原因，甚至生成一段代码。看起来很聪明，但离真正修复还很远。

Harness 版本要做的事包括：读取仓库状态，确认用户未提交改动，搜索登录相关文件，理解复现步骤，定位测试，提出修改计划，编辑文件，运行测试，解析失败，必要时继续修改，最后给出变更说明。如果测试跑不过，要明确说哪里没过；如果发现用户文件有未保存改动，要避免覆盖；如果需要联网查库文档，要检索最新官方资料。

这里最重要的不是提示词写得多漂亮，而是整个执行环境是否可靠。代码编辑工具、文件系统权限、测试命令、diff 追踪、错误恢复、最终报告，都是 Harness 的一部分。

也正因为这样，今天很多强代码助手的竞争点已经不只是“模型回答代码题能力”，而是编辑器集成、仓库理解、命令执行、测试反馈、上下文选择和变更审查。

Harness 和 Agent 是什么关系

很多人会问：那 Harness 工程是不是就是 Agent？

答案是：Agent 是 Harness 里的一种执行形态，但 Harness 更宽。

如果任务很短，Harness 可以只是“上下文装配 + 结构化输出 + 校验”。不需要 Agent 循环。

如果任务中等复杂，Harness 可以是固定工作流：先检索，再生成，再校验，再确认。模型在某些节点参与判断。

如果任务复杂、路径不固定，才需要 Agent 自主规划和工具选择。比如调试代码、研究开放问题、处理多步办公流程。

不要为了显得高级而上多 Agent。多 Agent 会带来协调成本、上下文污染、责任不清和调试困难。真实产品里，很多时候一个单 Agent 加好工具、好状态、好评估，比一群互相聊天的 Agent 更稳定。

所以，正确问题不是“我要不要做 Agent”，而是“这个任务需要多少自主决策，哪些环节必须确定性控制”。

本地化、私有化和社区项目为什么更需要 Harness

localaihub.com 这类社区里，很多人关心本地模型、私有部署、统一网关、内网知识库、企业内部工具接入。越是这类场景，越不能只靠提示词。

因为本地和私有化场景通常有更强的系统边界：数据不能外泄，权限要接企业账号，工具要连内网服务，模型能力可能不如最强闭源模型稳定，网络环境也更复杂。你更需要通过 Harness 把上下文、工具和流程设计好，而不是期待模型凭空变强。

比如一个本地知识库问答系统，如果只是“把检索片段塞给模型”，很容易出现答非所问、引用混乱、旧文档覆盖新文档。更好的 Harness 会做文档权限、版本排序、来源展示、冲突处理、无法回答时追问、用户反馈记录。

比如一个统一模型网关，如果只做转发，就很难支撑真实应用。上层 AI 产品还需要模型选择、工具协议、调用追踪、成本统计、失败重试、评估数据、上下文治理。模型网关解决“调用哪个模型”，Harness 解决“怎样让模型完成任务”。

比如内部办公 Agent，如果能访问邮件、日历、文档、工单和审批系统，那就必须有工具分级和动作确认。否则一次错误调用就可能变成真实事故。

社区项目常常资源有限，更应该把工程重点放在高杠杆位置。不要一开始就追求花哨多 Agent，可以先把几个基础能力做扎实：任务状态、工具 schema、结构化输出、引用、确认、trace、评估集。这些比再写十条提示词更值钱。

真实团队里，提示词思维会造成哪些隐性成本

只会提示词的人，通常不是不会努力，而是会把所有问题都理解成“模型没有听懂”。这个视角会带来很多隐性成本。

第一种成本是调试成本。用户反馈“AI 给错了答案”，团队开始看提示词。有人觉得应该加一句“请仔细阅读资料”，有人觉得应该强调“不要编造”，有人觉得应该换模型。讨论半天，没人知道那次回答到底用了哪些资料、有没有查到最新文档、工具是否返回空、用户是否有权限看对应数据。没有 Harness，调试像猜谜。

第二种成本是协作成本。提示词越写越长，变成只有少数人敢改的神秘文本。产品想加规则，后端担心破坏格式，前端不知道哪些状态会出现，测试不知道该怎么验收。最后所有变化都堆到一个系统提示词里，版本管理困难，责任边界模糊。

第三种成本是体验成本。内部没有状态，前端只能显示模糊文案；内部没有结构化动作，用户只能复制粘贴；内部没有确认流程，产品只能在文案里提醒用户小心。结果就是 AI 看起来能说，但用起来不顺。用户会觉得它像一个会写长答案的聊天窗口，而不是能帮自己完成工作的产品。

第四种成本是安全成本。提示词可以写“不要泄露敏感信息”，但如果系统已经把敏感字段塞进上下文，风险已经发生了一半。提示词可以写“不要执行危险操作”，但如果工具没有权限控制和确认机制，模型一旦误判就可能真的执行。安全边界不能只放在模型脑子里。

第五种成本是迭代成本。没有评估集，团队无法判断新版本是否比旧版本好。今天换模型，明天改检索，后天改提示词，每次都靠几个人手测。短期能跑，长期一定乱。AI 产品迭代最怕没有基准，因为模型输出看起来总有道理，退化也会披着流畅语言出现。

所以，Harness 工程并不是“高端团队才需要的复杂架构”。它是在降低长期维护成本。越早把任务状态、工具边界、评估和追踪做起来，后面越少靠玄学调参。

从 MVP 到生产，Harness 可以分阶段做

有人听到 Harness，会担心系统一下变重。其实不必一开始就做全套。更现实的做法是按产品阶段逐步加。

第一阶段，原型期。这个阶段可以用提示词快速验证需求，但要保留基本纪律：记录样例，记录失败，记录用户真正想完成的任务，不要只收藏看起来惊艳的输出。原型期最重要的是判断这个 AI 功能有没有真实使用价值。

第二阶段，内测期。开始引入结构化输出和简单工具。比如分类结果必须有枚举，行动项必须有字段，引用必须指向资料来源。工具先从只读做起，例如查询资料、搜索文档、读取项目状态。这个阶段的目标不是自动执行一切，而是让模型基于真实数据回答。

第三阶段，小范围生产。加入任务状态、错误处理、用户确认和 trace。系统要知道任务走到哪一步，失败在哪里，用户确认了什么。这个阶段尤其要避免假完成。没有执行成功就不要说完成，资料不足就明确追问。

第四阶段，规模化。建立评估集、线上回放、版本对比、权限治理和成本监控。不同模型、不同提示词、不同检索策略，都应该能比较效果。高频失败样本要进入回归集。这个阶段的核心是稳定增长，而不是靠人盯。

第五阶段，平台化。当多个 AI 功能都需要工具、状态、评估和追踪时，就可以抽出通用 Harness 能力。比如统一工具注册、统一审计、统一结构化输出校验、统一任务状态、统一评估面板。平台化不是为了好看，而是为了避免每个团队重复踩坑。

这个分阶段路径适合大多数社区项目。不要一开始追求大而全，也不要在进入生产后还停留在提示词原型。关键是每个阶段都知道自己缺什么，下一步补什么。

对小团队最实用的 Harness 最小集

如果团队人少，资源有限，可以先做一个最小集。这个最小集不复杂，但会明显提高产品稳定性。

第一，任务记录。每次用户请求生成一个任务 ID，记录任务类型、输入摘要、当前阶段、最终状态和错误。哪怕开始只是存在数据库表里，也比只有聊天记录强。

第二，上下文来源标注。给模型的资料要知道来自哪里，什么时间，用户是否有权限。输出涉及事实时，尽量能回到来源。这样用户追问“依据是什么”时，系统能回答。

第三，工具只读优先。早期先让模型查资料、查状态、生成建议。涉及写入、发送、删除、发布的工具，先做预览，不急着自动执行。等评估和确认流程稳定后，再扩大自动化范围。

第四，结构化中间结果。不要一上来就把所有东西做成复杂工作流，但至少让模型在关键节点输出结构化数据。比如意图分类、风险等级、行动项列表、引用列表、需要用户补充的信息。结构化以后，前端和后端都好处理。

第五，失败样本库。每次用户说“这不对”，不要只修当前例子。把输入、上下文、模型输出、期望行为记录下来。一个月后你会拥有最值钱的评估资产。

第六，用户确认。所有对外动作都先做确认。确认界面要展示具体动作内容，不要展示抽象技术过程。用户确认的是“发送这封邮件给张三”，不是“执行工具 send_email”。

第七，面向用户的状态文案。把内部错误翻译成用户能理解的状态。工具超时可以说“暂时没有查询到结果”；权限不足可以说“你当前无权查看这部分资料”；结构化解析失败可以在后台重试，不要把解析错误直接甩给用户。

这七件事做完，很多 AI 功能就会从“演示能用”变成“日常可用”。不需要先引入庞大框架，也不需要一夜之间做出全自动 Agent。

什么样的人适合做 Harness 工程

这个方向对人的要求也和单纯提示词不同。它需要跨越产品理解、工程实现和模型行为观察。

产品能力很重要。因为 Harness 的核心不是把流程做复杂，而是知道用户真正想完成什么。一个任务应该自动完成，还是给出建议？应该一步完成，还是拆成确认？用户需要看到依据，还是只需要结果？这些都是产品判断。

后端能力很重要。工具、状态、权限、队列、审计、重试、幂等、数据建模，都是后端基本功。AI 产品不是绕开后端，而是更依赖后端把现实世界接给模型。

前端能力也重要。很多 AI 产品失败在界面表达。模型内部可能做了很多事，但用户看到的是混乱的卡片、重复的解释、不知道能不能点的按钮。Harness 给前端提供清晰状态，前端再把状态变成自然体验。

测试能力同样重要。传统测试关注确定性输入输出，AI 测试还要关注语义正确性、边界样本和版本退化。会设计评估集的人，在 AI 产品团队里会越来越关键。

最后，还需要对模型有现实感。既不要神化模型，也不要低估模型。模型不是数据库，但能做复杂语义判断；模型不是权限系统，但能理解用户意图；模型不是测试框架，但能参与分析失败。Harness 工程的手感，就在于知道什么交给模型，什么交给系统。

社区项目可以怎么讨论 Harness

如果 localaihub 社区要把这个话题讨论深，建议少讨论“某个提示词神不神”，多讨论真实链路。

比如分享一个知识库项目时，不只贴问答效果，还可以说明：文档怎么入库，权限怎么过滤，引用怎么展示，旧文档怎么处理，回答失败怎么记录，用户反馈怎么进入评估。

分享一个办公 Agent 时，不只贴它能写邮件，还可以说明：邮件发送前怎样确认，联系人怎样消歧义，附件权限怎样检查，失败后怎样恢复，用户取消后是否真的没有执行。

分享一个代码助手时，不只贴它生成的补丁，还可以说明：仓库状态怎样检查，测试怎样运行，失败怎样继续，未提交改动怎样保护，最终 diff 怎样让用户审查。

分享一个模型网关时，不只贴支持多少模型，还可以说明：调用链路怎样追踪，工具协议怎样接入，模型能力怎样评估，不同模型失败时怎样降级，成本和延迟怎样反馈给上层应用。

这种讨论会比“提示词大全”更有价值。提示词可以复制，但任务链路和工程判断很难复制。社区如果沉淀的是这些实践，大家做出来的 AI 产品会更稳。

怎么开始做 Harness 工程

如果你现在手里有一个提示词驱动的 AI 功能，可以按下面路径升级。

第一步，把提示词拆开。

把现有提示词里的内容分为三类：真正需要模型理解的任务说明；应该由系统保证的流程规则；为了修补失败临时加的补丁。第一类保留，第二类迁移到代码和工作流，第三类转成评估样本或删除。

第二步，定义任务状态。

不要只保存一段聊天记录。至少记录任务类型、当前阶段、输入材料、已使用工具、结构化中间结果、用户确认状态、最终结果和错误。状态有了，任务才能恢复，问题才能排查。

第三步，整理工具。

给每个工具写清楚：它做什么，什么时候用，需要哪些参数，返回什么，有没有副作用，需要什么权限，失败怎么表示。把通用内部 API 包成面向任务的工具。能只读就先只读，有副作用就加确认。

第四步，做结构化输出。

内部不要只靠自然语言。分类、路由、行动项、引用、任务创建参数、风险等级，都应该结构化。自然语言适合给用户看，结构化数据适合给系统执行。

第五步，建立小评估集。

不用一开始搞很大。先收集 30 到 100 条真实或接近真实的样本，覆盖正常、缺字段、歧义、工具失败、权限不足、恶意输入。每次改动前后跑一遍。这个习惯会救你很多次。

第六步，加 trace。

记录每次任务的关键步骤：用户输入、选中的上下文、模型结构化输出、工具调用、工具结果、校验失败、最终回复。敏感内容可以脱敏，但链路不能没有。没有 trace 的 AI 产品，很难长期维护。

第七步，设计用户确认。

所有会影响外部世界的动作，都要明确区分草稿、预览、确认和执行。用户确认的应该是具体动作，不是一句笼统的“是否继续”。比如“发送这封邮件给谁，主题是什么，正文是什么”，而不是“AI 将执行操作”。

这些步骤看起来普通，但做完以后，产品质感会完全不同。用户会感觉这个 AI 不只是会聊天，而是真的知道自己在做什么。

什么时候提示词工程仍然够用

不是所有场景都需要重型 Harness。社区讨论不能从一个极端走到另一个极端。

如果你的功能只是离线批量改写文案，没有外部工具，没有权限动作，失败成本低，用户会人工审核，那提示词加少量校验可能就够。

如果你的功能只是单页摘要，输入明确，输出不落库，不触发动作，也许不用 Agent。

如果你还在探索产品需求，先用提示词做原型完全合理。

关键是不要把原型方法误认为生产方法。当功能开始接入真实数据、真实用户、真实工具、真实业务结果时，就要逐步引入 Harness。复杂度应该跟风险和任务长度匹配。

一个实用判断标准

你可以用下面几个问题判断自己是否已经进入 Harness 工程范围。

1. 模型是否需要访问当前数据，而不是只靠用户输入？
2. 模型是否需要调用工具或影响外部系统？
3. 任务是否超过一次回答，需要多个步骤？
4. 输出是否要被系统继续消费或落库？
5. 是否存在权限、隐私、金额、发布、删除、发送等风险？
6. 失败后是否需要重试、恢复或解释？
7. 团队是否需要比较不同提示词、模型或流程版本？
8. 线上问题是否需要回放和定位？

只要有多个答案是“是”，就不要继续把所有复杂度压在提示词里。

社区最该形成的共识

我觉得接下来做 AI 产品，社区需要从“提示词崇拜”转向“系统能力建设”。

会写提示词仍然是基本功，但它不是护城河。真正难复制的是你如何组织数据、工具、状态、评估和用户流程。一个团队的 AI 产品是否可靠，常常不是看它系统提示词有多神，而是看它失败时有没有边界，行动前有没有确认，结果有没有依据，问题能不能回放，版本能不能评估。

这也是为什么很多看似普通的工程细节，在 AI 产品里会变成核心能力。schema、日志、权限、队列、状态机、测试集、引用、审计、灰度、回滚，这些老东西并没有因为大模型出现而过时。它们只是换了一个更智能的中间层。

提示词工程教我们如何让模型理解意图。Harness 工程教我们如何让模型进入生产。

如果你想做一个能长期运行的 AI 产品，不要只问“提示词怎么写”。还要问：

模型该看什么？

模型能做什么？

系统必须保证什么？

用户什么时候确认？

失败怎么恢复？

我们怎么知道它变好了？

这些问题回答清楚，AI 才开始从玩具变成工具。

最后给产品负责人的一句话

如果你负责一个 AI 产品，不要把 Harness 工程看成纯技术话题。它会直接决定产品承诺能不能兑现。用户看到“帮我处理”，就会以为系统真的能处理；用户看到“已完成”，就会以为事情真的完成。后台如果只有一段提示词和一次模型调用，这种承诺就很脆。

更成熟的做法，是先把承诺拆细。哪些场景只承诺生成建议，哪些场景承诺创建草稿，哪些场景在用户确认后执行，哪些场景系统可以自动完成。每一级承诺都要有对应的 Harness 能力。只生成建议，需要好上下文和好表达；创建草稿，需要结构化输出和可编辑界面；确认后执行，需要工具权限、预览和审计；自动完成，需要评估、回滚和监控。

这样拆完以后，路线会清楚很多。产品不必一开始就宣称全自动，也不必停在聊天框。可以先把一个高频任务做深：资料查准，状态清楚，动作可确认，失败能解释，结果能追踪。一个做深的任务，比十个只会回答的入口更有价值。

对用户来说，真正好的 AI 产品不是最会说话的那个，而是最少让人收拾残局的那个。Harness 工程的意义，正是减少残局。

还有一个很现实的判断：当用户开始把真实资料、真实客户、真实项目、真实代码交给系统时，他期待的已经不是“灵感辅助”，而是“可信协作”。可信协作需要清楚边界。系统知道什么，依据来自哪里，准备做什么，哪些需要确认，哪些已经完成，哪些没有完成，都要说得明白。只有把这些能力做进 Harness，提示词里的聪明才不会停留在文本表面，而能变成用户日常工作中可依赖的生产力。它让产品有边界，有节奏，也有长期改进的抓手。

给社区开发者的落地检查表

如果你今天就要检查自己的 AI 功能，可以先问十二个很具体的问题。用户输入不完整时，系统会追问还是硬答？回答涉及事实时，能不能看到资料来源？模型拿到的资料有没有权限过滤？工具失败时，用户看到的是人话还是技术错误？有副作用的动作有没有预览？用户确认的内容是否具体到对象、时间、收件人、金额或文件？任务中断后能不能恢复？线上失败有没有进入样本库？每次改提示词后有没有跑旧样本？前端有没有把内部字段藏起来？模型是否会在不知道时承认不知道？系统是否区分草稿、建议、待确认和已执行？

这张表不复杂，但很能暴露产品成熟度。很多项目并不是模型不够强，而是这些问题没有答案。用户第一次使用时可能只看回答是否流畅，持续使用时一定会看系统是否可靠。可靠来自细节：少编造，能追溯，敢承认失败，行动前确认，失败后能解释，版本变化有评估。把这些细节补上，哪怕模型没有换，产品也会明显更像一个真正能用的助手。

还有一个建议：不要把所有反馈都写成“优化提示词”。社区项目可以建立一个小表格，把反馈分成提示词问题、上下文问题、工具问题、权限问题、界面问题、评估问题。这样排查几轮以后，团队会发现很多所谓提示词问题其实是系统设计问题。分类清楚，修复才会准确。

对开源或小团队项目来说，还可以把这些检查公开成项目约定。比如每个新工具都必须说明是否只读，每个有副作用的能力都必须提供预览，每个知识库回答都必须能返回来源，每个版本发布都至少跑一组回归样本。约定不需要很厚，但要能执行。社区成员参与贡献时，也能知道什么算完成，什么只是演示。这样项目越多人用，质量越容易沉淀，而不是越改越散。长期看，这些约定就是项目的可信基础和协作底线。

参考资料

1. OpenAI: Harness engineering - OpenAI 对 Harness engineering 概念及其与 Agent 工作流关系的说明。
2. OpenAI: A Practical Guide to Building Agents - OpenAI 关于 Agent 组件、工具、护栏和编排的实践指南。
3. OpenAI Agents SDK Docs - OpenAI Agents SDK 关于工具、handoff、guardrails 和 tracing 的项目文档。
4. Anthropic Claude Docs: Prompt engineering overview - Anthropic 关于提示词设计、上下文和示例的官方文档。
5. Anthropic Claude Docs: Tool use - Anthropic 关于工具使用和工具结果处理的官方文档。
6. Google Cloud Vertex AI: Prompt design strategies - Google Cloud 关于提示设计和输出控制的文档。
7. Google Cloud Vertex AI: Evaluate Gen AI models - Google Cloud 关于生成式 AI 评估的官方文档。
8. LangGraph Documentation - LangGraph 关于状态化 Agent、持久执行和人在环路的文档。
9. LangSmith Documentation - LangSmith 关于 tracing、evaluation 和 observability 的文档。
10. Model Context Protocol Documentation - MCP 官方文档，说明模型连接工具、资源和上下文的协议。
11. Microsoft Prompt flow Documentation - Microsoft 关于提示流、评估和生成式 AI 应用工程化流程的文档。
12. LlamaIndex Documentation - LlamaIndex 关于数据连接、RAG、Agent 和工作流的项目文档。
13. CrewAI Documentation - CrewAI 关于 Agent、Task、Tool 和 Flow 编排的项目文档。
14. ReAct: Synergizing Reasoning and Acting in Language Models - 关于语言模型结合推理与行动的经典论文。
15. Toolformer: Language Models Can Teach Themselves to Use Tools - 关于语言模型学习使用外部工具的论文。
16. Reflexion: Language Agents with Verbal Reinforcement Learning - 关于语言智能体通过语言反馈改进表现的论文。