LocalAIHub 中文社区

提示词模板当然会过期。它不像一段静态标语，写好以后长期不变；它更像产品规则、接口契约、客服话术、风控策略和测试用例的混合体。模型版本会变，用户问题会变，工具接口会变，知识库会变，业务政策会变，安全要求会变，评测标准也会变。只要这些外部条件发生变化，曾经表现良好的提示词模板就可能开始失效。 把提示词当作一次性文案，是很多大模型应用早期能跑、后期难维护的原因。一个提示词模板通常承担多重职责：告诉模型扮演什么角色，限定可用信息，规定输出结构，选择工具调用方式，表达拒绝边界，连接业务字段，承载少量示例，适配模型能力，并把产品体验转成可执行指令。这些职责任何一个变化，都可能让模板需要升级。 Prompt 资产版本化的重点，不是给提示词文件名加日期，而是让每一次行为变化都可解释、可评测、可回滚、可审计。生产级团队需要知道当前线上使用哪个版本，为什么换到这个版本，换之前通过了哪些测试，影响了哪些用户路径，失败时如何回退，历史输出如何追溯到当时的模板、模型、参数、工具和知识库状态。 提示词为什么会过期 第一类过期来自模型升级。不同模型对系统指令、示例、格式约束、长上下文、工具调用和安全边界的理解并不完全一致。一个在旧模型上必须反复强调的约束，在新模型上可能显得啰嗦；一个在旧模型上能稳定输出 JSON 的模板，在新模型上可能需要配合结构化输出能力；一个在旧模型上有效的“思考步骤”写法，在新模型上可能增加延迟或干扰回答。 第二类过期来自业务变化。产品套餐、退款规则、权限设计、配送范围、开票流程、价格策略、审批节点和 SLA 一旦变化，模板里的示例、口径和禁止承诺都会变。客服类、销售类、企业知识问答类应用尤其明显。模板如果继续引用旧政策，就会让模型以礼貌而自信的方式输出错误承诺。 第三类过期来自工具接口变化。Agent 提示词常常绑定工具名称、参数含义、调用顺序、错误处理和权限边界。工具字段改名、返回结构改变、幂等规则改变、鉴权方式改变、可用工具增减，都会让旧模板产生错误调用。真正的智能体不是只会聊天，它会做事；会做事的提示词必须跟工具契约一起维护。 第四类过期来自知识环境变化。RAG 应用中，提示词往往要求模型“仅根据检索内容回答”“引用来源”“缺少依据时说明无法确认”。当知识库切分方式、召回策略、排序模型、文档新鲜度和引用格式改变时，模板也要调整。否则模型可能对新检索片段理解不佳，或者引用格式与前端展示不匹配。 第五类过期来自用户行为变化。应用上线后，真实用户不会按测试样例提问。他们会省略上下文、混合多个诉求、使用方言、输入截图转写、复制错误日志、反复追问、试探边界、要求越权、让模型替他们做决定。线上失败样本会暴露模板没有覆盖的场景，旧模板如果不吸收这些反馈，就会在真实流量前越来越不合身。 第六类过期来自安全和合规要求变化。新的政策、法规、平台规范、企业风险偏好和事故复盘都会改变模型应该拒绝什么、如何拒绝、何时升级人工、如何保护个人信息、如何处理未成年人或高风险领域。安全模板不是一次性防线，而是随风险情报持续演进的控制面。 Prompt 资产应该包含什么 一个可管理的 Prompt 资产不只是模板正文。它至少应包含名称、用途、适用入口、目标用户、输入变量、输出格式、模型配置、工具依赖、知识库依赖、示例、拒绝边界、评测集、版本号、变更说明、负责人、审批记录、发布时间和回滚路径。缺少这些字段，提示词就很难进入真正的生产生命周期。 模板正文要和输入变量分开。LangSmith 的模板格式文档区分简单变量替换和更复杂的 Mustache 结构，说明提示词模板并非普通字符串。变量名、必填性、类型、默认值、脱敏规则和渲染后样例都要明确。很多线上事故来自变量为空、字段名变了、嵌套对象无法读取、花括号转义错误或用户输入破坏输出格式。 模型配置也应视为资产的一部分。模型名称、温度、最大输出长度、结构化输出模式、工具选择策略、停止条件和安全设置都会改变最终行为。只版本化提示词文字，不记录模型配置，无法解释为什么同一模板在不同环境表现不同。MLflow Prompt Registry 把模型配置作为提示词版本相关信息管理，背后就是这个逻辑。 工具契约要显式记录。Agent 模板必须说明可用工具、参数语义、调用前提、失败重试、禁止调用场景和用户确认要求。工具变更时，提示词应像代码调用方一样接受兼容性评审。不能让模型通过自然语言猜测接口，因为接口不是语言游戏，而是生产动作。 评测绑定也很关键。一个 Prompt 资产必须有自己的回归样本和验收标准。OpenAI Evals 文档把评测拆成任务描述、测试输入、评分标准和结果分析，这种思路适合提示词资产管理。没有评测的模板版本，只能靠人工感觉判断好坏；感觉在早期探索有用，在生产发布时不够。 版本号：语义化可以借鉴，但不要机械照搬 语义化版本 SemVer 用主版本、次版本和修订版本表达兼容性变化。提示词模板可以借鉴这个思想，但不能生搬硬套。代码库里的 API 兼容性比较明确，提示词的兼容性同时涉及输出结构、业务含义、模型行为和用户体验，所以版本号要服务于发布沟通，而不是成为形式主义。 可以把主版本用于破坏性变化。比如输出结构改变、必填输入变量改变、工具调用策略改变、适用业务流程改变、拒绝边界大幅调整、模型家族切换导致行为显著变化，都应提升主版本。调用方看到主版本变化，就知道需要重新适配和完整回归。 次版本适合能力增强。比如增加少量场景覆盖、改善引用方式、加入新的示例、提升多轮澄清能力、支持新的非破坏性变量、优化工具失败后的解释，都可以提升次版本。它表示模板能力变多，但既有调用契约原则上不应被破坏。 修订版本适合小修。错别字、措辞更自然、轻微格式修复、个别边界样例补充、提示顺序微调，如果不改变接口和核心行为，可以作为修订版本。修订版本也需要评测，但不一定需要完整业务评审。 除了数字版本，还需要环境标签。LangSmith 用提交标签和 staging、production 环境管理提示词版本，MLflow 使用别名指向特定提示词版本，PromptLayer 也提供 release label。环境标签解决的是“线上现在跑哪个版本”的问题。版本号描述历史，环境标签描述部署指针，两者不能混为一谈。 生产应用不要直接依赖 latest。latest 适合开发和探索，不适合稳定线上行为。线上应使用 production、stable 或明确版本别名，并记录别名移动时间。否则一次后台保存就可能改变线上模型行为，而且调用代码没有任何变化，事故排查会非常困难。 分支、标签和环境 Prompt 资产管理可以借鉴代码协作，但要承认提示词有自己的特点。代码 diff 通常能看出语法变化，提示词 diff 只能看到文字变化，真正影响要靠评测和回放。GitHub Pull Request Review 的流程强调评论、批准和请求修改，提示词评审同样需要这种协作机制，但评审对象不能只看文本差异。 开发环境用于快速实验。产品经理、AI 工程师和领域专家可以在开发环境尝试新表达、新示例和新工具策略。这里允许失败，但必须隔离真实用户。开发环境的输出样本可以沉淀为候选评测，而不是直接进入生产。 预发环境用于可控验证。进入预发的版本应绑定固定模型、固定工具、固定知识库快照和固定评测集。预发不是“再看一眼”，而是验证模板在接近生产条件下是否满足目标。多轮对话、异常输入、工具失败和安全边界都应在这里跑过。 生产环境是稳定指针。只有通过评测、评审和灰度观察的版本才能被 promotion 到生产。LangSmith 文档中的环境和标签机制、MLflow 的 alias 机制、PromptLayer 的 release label，本质上都在解决同一件事：应用代码通过稳定名称取模板，而团队可以把这个稳定名称指向经过验证的版本。 回滚环境要预先可用。提示词发布不需要重新部署代码，这是优点，也可能是风险。版本指针移动很快，回滚也必须很快。每个生产模板都应保留上一个稳定版本，记录回滚条件和回滚负责人。出现大面积格式错误、工具误调用、安全退化或核心业务答错时，不应该临时翻历史记录找旧文本。 评审看什么 提示词评审第一看目标是否清楚。模板要解决什么用户任务，成功输出是什么，失败时怎么表现，是否需要澄清，是否允许调用工具，是否必须引用来源，这些必须明确。目标不清楚的模板很容易变成“请你尽量回答得专业一点”，这种指令在生产里不可控。 第二看输入契约。变量名是否稳定，字段是否有类型说明，缺失字段如何处理，用户输入是否需要原样引用，长文本是否可能超出上下文，敏感字段是否会被输出，模板能否抵御用户把指令注入变量里。很多提示词漏洞不是正文写错，而是变量边界没有设计。 第三看输出契约。前端、后端、自动化流程和人工审核需要什么格式，模型是否必须输出 JSON、Markdown、自然语言段落、引用编号、工具动作或结构化字段。输出格式越严格，越应该配合解析器和评测器，而不是只靠一句“请严格输出”。 第四看业务边界。模型能承诺什么，不能承诺什么，哪些情况必须转人工，哪些情况必须提醒用户确认，哪些内容需要引用政策，哪些建议只能作为信息参考。模板里的边界要面向最终用户自然表达，不能把内部字段、调试术语和实现细节暴露给用户。 第五看工具行为。什么时候调用，调用前是否需要用户确认，失败后是否重试，是否可能产生副作用，是否允许批量操作，是否需要解释结果。对能改数据、下订单、发消息、扣费、建任务的工具，提示词评审必须像审生产代码一样严格。 第六看安全性。模板是否容易被用户要求忽略规则，是否会泄露系统提示，是否会输出隐私，是否会在高风险领域给过度确定建议，是否会把检索内容中的恶意指令当成系统要求。安全评审要覆盖提示注入、越权、隐私、违法指导和脆弱用户场景。 第七看可评测性。好的模板应该能被测试。至少要有代表性样本、边界样本、反例样本和线上失败回放。Anthropic 的提示工程文档强调先定义成功标准并建立经验性测试，再改进提示；这对生产团队非常实用。没有成功标准，评审只能停留在审美层面。 评测：把“感觉更好”变成证据 提示词评测应覆盖正确性、完整性、格式遵守、引用可靠性、工具选择、拒绝边界、语气一致性、成本、延迟和稳定性。不同模板权重不同。客服模板更看重业务正确和用户体验，工具 Agent 更看重动作准确和副作用控制，内容生成更看重风格和事实性，审核模板更看重召回、精确和一致性。 评测集要分层。基础样本覆盖高频正常问题，边界样本覆盖缺失信息、冲突信息和多意图，攻击样本覆盖提示注入和越权请求，回归样本覆盖历史事故，长尾样本覆盖低频但高价值场景。单一平均分会掩盖关键退化，尤其安全和工具类问题不能被高频简单样本稀释。 评分方式可以组合。确定性格式用程序检查，分类任务用标签匹配，事实性用引用和知识源校验，开放问答用人工或模型评分，工具调用用回放环境验证，多轮任务用完整轨迹评分。OpenAI Evals 中的 data source 和 grader 思路可以迁移到内部平台：每个样本有输入、期望、评分规则和输出记录。 模型评分不能替代人工。模型作为评审员适合快速筛查、聚类错误和生成解释，但在高风险业务、法律口径、品牌表达和安全边界上仍需人工抽样。更稳妥的做法是让模型评审提供候选问题，人工只处理高争议和高影响样本，从而提高评审效率。 评测要记录运行环境。同一模板在不同模型、温度、知识库、工具版本和上下文长度下结果不同。评测记录必须包含这些条件，否则历史分数无法比较。一次提示词发布如果只写“通过评测”，却不记录跑在哪个模型上、用哪批样本、评分阈值是多少，就无法支撑长期治理。 线上监控也是评测。Microsoft Foundry 的可观测性文档把评估、监控和追踪放在生成式 AI 生命周期中，提示词同样需要上线后监控。要看格式错误率、人工转接率、用户重试率、工具失败率、拒绝率、引用缺失率、延迟、成本和人工反馈。离线评测通过不代表线上分布永远稳定。 回归测试怎么建 Prompt 回归测试不是把几个演示问题保存下来。它要覆盖模板承诺的关键行为，并且能在每次修改、模型升级、工具变更和知识库更新时重复运行。最小集合应包括高频正常样本、历史失败样本、边界样本、攻击样本、格式样本和工具轨迹样本。每类样本都要说明为什么存在，不能只把它们混成一个平均分。 高频正常样本代表主路径。它们验证模板在大多数用户请求下是否稳定，包括是否理解意图、是否少问废话、是否给出清晰下一步、是否保持产品语气。历史失败样本代表已经付过代价的问题，任何回归失败都应该阻止发布。边界样本用于测试缺少字段、上下文冲突、多个任务并存、用户表述含糊和政策临界点。 攻击样本要专门维护。提示注入、要求忽略规则、要求泄露系统提示、把恶意指令藏在检索内容里、诱导模型越权调用工具、要求输出隐私字段，这些都不能只靠通用安全模型兜底。模板本身要知道哪些信息可以用，哪些信息只能作为用户输入，哪些信息不能覆盖系统目标。 格式样本要由程序判定。需要 JSON 就检查能否解析，需要固定字段就检查字段完整，需要引用编号就检查编号存在且能对应来源，需要 Markdown 表格就检查列数和空值。格式测试不应依赖人工主观打分，因为下游系统对格式错误不会宽容。只要结构化字段进入业务流程，就要把格式测试当成接口测试。 工具轨迹样本要看过程，不只看结论。模型是否在正确时机调用工具，参数是否来自用户或可信上下文，是否遗漏确认步骤，工具失败后是否给出可理解解释，是否重复执行副作用动作，都要进入断言。一个 Agent 最终回答看起来正确，不代表过程安全；过程里多调用一次扣费、发信或改状态，就已经是生产事故。 回归测试还要有更新规则。线上出现新失败，评审会确认后加入回归集；业务政策变化，旧样本要标记废弃或改写；模型能力变化，评分方式要复核；样本过多导致运行成本上升时，要分成快速集和完整集。快速集阻止明显退化，完整集用于候选版本发布前验收。 变更单：每次修改都要说清楚 Prompt 变更单应回答六个问题：为什么改，改了什么，影响哪些入口，如何验证，如何灰度，如何回滚。变更说明不需要冗长，但必须具体。比如“优化回答质量”没有意义，“增加退款场景中缺少订单号时的澄清问题，避免直接承诺退款结果”才可评审。 变更要关联样本。每次修改最好能指向线上失败案例、评测失败项、业务政策更新或模型迁移要求。没有样本支撑的改动容易变成个人偏好。提示词文本本身很主观，样本能把讨论拉回用户任务。 变更要标明风险等级。只改措辞是低风险，改输出格式是中高风险，改工具调用条件是高风险，改安全拒绝边界是高风险，切换模型是高风险。风险等级决定评审人数、评测范围和灰度策略。 变更还要明确验收阈值。比如核心格式通过率必须达到百分之九十九，退款错误承诺为零，工具误调用低于指定比例，引用缺失率不能上升，平均延迟不能超过某个阈值。阈值让发布从“大家觉得可以”变成“证据达到要求”。 灰度和回滚 提示词灰度要按用户、流量、入口或任务类型分层。不要一开始就全量替换核心模板。可以先在内部账号、测试组织、低风险入口或小比例流量中运行，比较新旧版本输出。A/B 测试不只看用户点击，也要看人工质检、格式错误、工具成功率和安全事件。 灰度期间要保留对照。新旧模板应在相同输入上比较，尤其对线上失败回放和高频样本。PromptLayer 文档提到 A/B Testing、日志、评估和 release label，这类能力的价值在于让团队知道版本变化带来的真实行为差异，而不是只知道文本改了几行。 回滚要快速且干净。如果应用通过 production 标签或 alias 读取模板，回滚就是把指针指回上一个版本；如果模板硬编码在应用里，回滚就变成重新发布代码。提示词频繁迭代的产品，应避免把所有模板写死在代码常量中。代码可以定义契约和默认兜底，模板正文应有独立发布面。 回滚后仍要复盘。回滚不是结束，而是说明评测或灰度没有提前捕捉问题。团队要把事故样本加入回归集，更新评审清单，必要时调整风险等级。否则同类问题会在下次模板升级时再次出现。 上线观察看哪些指标 提示词上线后，第一组指标是任务完成。用户是否得到可执行答案，是否继续追问同一问题，是否重新发起同类请求，是否转人工，是否点击引用来源，是否完成下一步操作。这些指标比“回答字数变多”更接近真实价值。模板发布后如果回答更长但转化更差，说明它可能只是显得更完整。 第二组指标是结构稳定。结构化输出解析失败率、字段缺失率、引用缺失率、引用错配率、工具参数缺失率、前端渲染失败率都要看。许多提示词事故不会马上表现为用户投诉，而是表现为下游流程掉进异常分支。对自动化场景来说，结构稳定比文采更重要。 第三组指标是安全边界。拒绝率突然上升，可能是模板过度保守；拒绝率突然下降，可能是边界失守；人工升级率上升，可能是模板没有处理新场景；隐私遮盖命中上升，可能是用户开始输入更敏感资料。安全指标不能只看总量，还要按入口、用户群、任务类型和版本切片。 第四组指标是成本和延迟。提示词变长、示例增多、检索片段扩大、模型换代都会影响响应时间和费用。生产体验里，慢回答不一定比短回答好。模板评审应把成本和延迟当成质量的一部分，尤其是高频入口。一个版本如果质量只小幅提升，却让平均延迟翻倍，就需要重新判断是否值得上线。 第五组指标是人工质检和用户反馈。用户点赞点踩不是完整事实，但能发现方向；人工质检样本少，但能解释原因。更有效的方式是把线上输出聚类，挑出重复失败模式：没问关键条件、引用旧政策、误用工具、过度拒绝、回答太笼统、把内部过程说给用户。观察不是为了报表好看，而是为了找到下一轮模板和评测要补的地方。 上线观察要有时间窗。刚发布后一小时看硬错误，一天内看格式和工具失败，一周内看用户行为和人工质检，一个业务周期后看长期效果。不同问题出现速度不同，不能只在发布当天看一眼就关闭变更单。 Prompt 和代码的边界 不是所有行为都应该写进提示词。确定性规则、权限判断、金额计算、日期计算、数据库查询、幂等控制、审计日志、敏感词硬拦截、结构化校验和工具权限应尽量放在代码或平台层。提示词适合表达任务目标、语言策略、推理步骤、信息使用原则和交互方式，不适合承担不可错的系统控制。 当提示词开始堆满“如果字段 A 等于 X 且字段 B 不为空就输出 Y，否则输出 Z”时，说明一部分逻辑应该下沉到程序。把硬规则塞进自然语言，会让模型在边界条件下不稳定，也让评审困难。生产级设计应让代码负责确定性，模型负责语义判断和自然交互，两者通过清晰变量和结构化输出连接。 但也不能把提示词贬低成文案。它是模型行为的策略层。角色、上下文使用、澄清方式、拒绝质量、工具选择和回答组织都需要提示词表达。好的系统设计不是“全靠提示词”或“提示词无所谓”，而是把提示词放在合适边界内，并用版本、评测和审计管理它。 Prompt 资产还要和知识库分开。知识库回答“事实是什么”，提示词回答“如何使用事实”。把大量事实硬塞进模板会导致过期和膨胀；把所有行为要求写进知识库又会让检索不稳定。稳定规则、交互策略和输出契约放模板，频繁变化的事实放知识库，工具能力放接口契约，这是更清晰的分层。 模板过期的信号 用户开始反复追问同一问题，是模板过期信号。它可能没有主动澄清关键信息，也可能回答结构不符合用户期望。客服场景中，如果同类问题转人工率上升，说明模板没有覆盖新的业务流程或用户表达。 格式错误率上升，也是明显信号。前端解析失败、JSON 字段缺失、引用编号错乱、Markdown 结构破坏、工具参数为空，都说明模板与当前模型或输入分布不匹配。格式问题不能只靠“再严格一点”解决，可能需要结构化输出、后处理校验或模板拆分。 工具失败率变化要重点看。模型选择了错误工具、漏调用工具、重复调用工具、把用户输入错误映射到参数、没有处理工具错误，都会造成真实业务影响。工具类模板必须用轨迹评测，而不是只看最终自然语言回答。 安全拒绝异常也说明模板需要维护。拒绝过多会伤害正常用户，拒绝过少会带来风险。拒绝语气生硬、不给替代方案、泄露规则细节、把合规问题说成技术错误，都会影响用户体验和安全质量。 模型升级后旧模板表现不稳定，是最常见的过期场景。新模型可能更擅长遵循简洁指令，也可能对旧模板中的冗余示例产生不同解释。每次模型升级都应触发核心模板回归，而不是假设兼容。 过期还会表现为样本越来越难解释。团队为了处理新问题，不断在模板末尾追加例外说明，结果同一个模板里同时存在旧政策、新政策、旧工具名、新工具名、旧输出格式和新输出格式。短期看它还能运行，长期看任何改动都可能牵一发动全身。模板如果需要靠越来越多补丁维持，就已经到了重构时点。 另一个信号是评测分数稳定但线上体验下降。这通常说明评测集老化，已经不能代表真实用户。用户输入方式变了、产品入口变了、知识库内容变了，旧评测仍然全绿。此时过期的不只是模板，还有评测资产。Prompt 治理必须把模板和评测一起盘点，否则团队会被历史指标误导。 还有一种隐蔽过期是口径不一致。用户在不同入口问同一问题，得到不同答案；新用户和老用户看到不同承诺；客服后台和公开页面说法不同；模型引用的政策与人工坐席口径不同。这类问题往往不是模型随机，而是多个模板版本并存、知识库更新时间不同、生产标签没有统一管理。只要用户能感知到不一致，资产治理就已经失败。 一套可落地的 Prompt 生命周期 第一步是建资产目录。按业务域、入口、任务类型和风险等级列出所有模板，标明线上指针、负责人、调用方、模型、工具、知识库和评测集。没有目录，就不知道哪些模板在服务用户，也不知道哪些模板无人维护。 第二步是规范模板结构。每个模板至少包含目标、适用场景、输入变量、输出要求、工具使用原则、拒绝边界和示例。正文面向模型，资产说明面向团队，最终输出面向用户。三者不要混在一起，更不能把内部说明输出给用户。 第三步是建立版本策略。开发用草稿版本，预发用候选版本，生产用稳定标签。破坏性变化升主版本，能力增强升次版本，小修升修订版本。每次版本都写变更说明和验证记录。 第四步是绑定评测。每个生产模板至少有基础回归集、边界集、攻击集和线上失败集。评测要能自动运行，并在关键指标退化时阻止发布。高风险模板增加人工复审。 第五步是设评审流程。低风险改动由负责人自审加自动评测，中风险改动需要产品或业务评审，高风险改动需要安全、法务或工具负责人参与。评审不是追求多人签字，而是让相关风险被正确的人看见。 第六步是灰度发布。通过标签或 alias 把候选版本推到小流量，观察关键指标。灰度通过后再移动 production 指针。发布记录应能回答何时、谁、为什么把生产指针从哪个版本移到哪个版本。 第七步是线上观察。收集失败样本、用户反馈、人工质检、工具轨迹和成本延迟。把高价值失败样本加入评测，把低价值噪声过滤掉。Prompt 生命周期不是发布结束，而是从真实行为中持续学习。 第八步是定期盘点。每月或每个大版本检查模板是否仍适配当前模型、业务、工具和知识库。长期无调用的模板归档，长期无人负责的模板转交，长期失败的模板重构。资产不盘点，就会变成影子配置。 治理流程：从台账到责任 Prompt 治理第一件事是建立台账。台账不是为了登记而登记，而是让团队能回答四个问题：哪些模板正在被调用，哪些版本在线上，谁对结果负责，哪些变更正在等待发布。台账字段至少包括资产名、业务域、入口、版本、生产标签、模型、工具、知识库、风险等级、负责人、评测集、最近发布时间和最近盘点时间。 第二件事是定义风险等级。只影响内部摘要的模板，可以走轻量流程；面向客户承诺、价格、退款、合规、医疗、法律、金融、安全或自动执行工具的模板，必须走更严格流程。风险等级不能只按模板长度判断，要看输出是否影响用户权益、是否触发真实动作、是否可能泄露敏感信息、是否会被外部审计。 第三件事是设置发布权限。开发者可以提交候选版本，但生产指针不应由任何人随手移动。低风险模板由资产负责人批准，中风险模板需要产品或业务负责人批准，高风险模板需要安全、法务、工具负责人或领域专家参与。权限不是为了制造阻力，而是让发布责任和风险影响匹配。 第四件事是保留证据。每次发布都应保存模板内容、差异、模型配置、评测结果、人工评审意见、灰度数据和上线时间。事后追溯时，不能只看到“某人改了提示词”，而要看到为什么改、凭什么认为可上线、上线后结果如何。证据链越完整，团队越敢持续迭代。 第五件事是处理退役。不用的模板不能永远留在生产系统里。退役前要确认没有调用方，迁移入口到新模板，保留历史版本供审计，撤销生产标签，标记停止维护。大量旧模板留在系统里，会让新成员误用，也会让安全盘点变得困难。 治理流程要保持轻重分明。低风险模板如果流程过重，团队会绕过平台；高风险模板如果流程过轻，事故迟早发生。成熟做法是让平台自动完成能自动完成的部分，例如版本记录、评测运行、格式检查、标签移动日志和回滚按钮，把人工精力留给业务边界、安全风险和用户体验判断。 多模型和多入口的一致性 许多产品不会只用一个模型。高频问题可能用便宜模型，复杂问题用强模型，长文总结用长上下文模型，敏感问题用带审核链路的模型。此时同一 Prompt 资产可能需要模型适配层。适配层不是复制多份模板，而是保留共同业务目标和输出契约，只对模型能力差异、工具格式和示例密度做差异化配置。 多模型策略最怕无意识分叉。某个入口复制了一份旧模板，另一个入口又复制一份新模板，几个月后用户得到不同结果，团队也不知道哪份是准的。更稳妥的方式是设主模板和变体模板。主模板保存业务口径、边界和输出契约，变体只保存必要差异，并明确继承关系。主模板变更时，变体必须触发回归。 多入口一致性也需要治理。移动端、网页端、客服后台、开放 API、企业微信和浏览器插件可能调用同一能力，但上下文和展示方式不同。提示词应保证核心结论一致，同时允许表达形式适配入口。比如客服后台可以给坐席更多处理建议，面向终端用户则只输出用户该知道的内容。差异要有意设计，不能由历史复制粘贴自然形成。 模型迁移要作为专项项目处理。不能把模型名一换就发布。迁移前要跑完整回归，比较新旧输出，检查格式、工具、安全、成本和延迟；迁移中要灰度；迁移后要观察线上分布。新模型能力更强，不代表旧模板自动更好。很多旧模板包含为旧模型补短板的冗余约束，新模型可能因此输出啰嗦、保守或格式异常。 资产盘点清单 每次季度盘点或大版本发布前，团队可以按清单检查。第一，线上模板是否都有负责人和生产标签。第二，生产版本是否能追溯到评测结果和评审记录。第三，引用的模型、工具和知识库是否仍然存在。第四，输出格式是否仍被下游使用。第五，最近三个月线上失败是否已经进入回归集。 第六，模板中是否包含过期政策、旧字段、旧工具名、废弃入口或内部说明。第七，拒绝边界是否符合当前安全要求。第八，是否有多个入口维护重复模板。第九，是否存在长期无人调用却仍保留生产标签的模板。第十，是否存在没有回滚版本的高风险模板。 清单检查不能只靠负责人自报。平台应提供调用量、版本年龄、最后修改时间、评测状态、线上错误和标签移动历史。负责人再结合业务变化判断是否继续维护、重构或退役。这样盘点才不是形式会议，而是资产健康检查。 面向最终用户的文案原则 提示词模板的最终效果是用户看到的回答。生产级 UI 标准要求信息去重、层级清晰、文案只面向最终用户。模板评审时应检查输出是否把内部规则、调试字段、工具名称、模型限制和实现细节泄露给用户。用户需要的是可理解的答案和可执行的下一步，不是系统如何运作。 回答层级要清楚。先给结论，再给依据，再给步骤，再给注意事项。不要把多个意图揉成一大段，也不要重复同一句免责声明。提示词应引导模型在复杂问题中组织信息，而不是生成看似完整但难以扫描的长段落。 拒绝也要面向用户。好的拒绝不是“根据政策我不能回答”，而是说明不能直接提供什么、可以提供什么替代帮助、用户下一步可以怎么做。拒绝边界需要安全，但表达要自然。安全和体验不是对立关系，模板写得好，两者可以同时成立。 什么时候该重写，而不是小修 当模板职责太多时，应重写。一个模板同时处理售前咨询、售后退款、投诉安抚、技术排障和工具执行，会让指令互相干扰。更好的做法是按任务路由到多个专门模板，每个模板保持清晰目标和评测集。 当输出结构频繁被下游解析失败时，应重写。可能需要改用结构化输出、拆分自然语言和机器字段，或者让模型先产出结构再由程序渲染成用户文案。继续在旧模板里加“务必严格”通常不是根治。 当评测中同类错误反复出现时，应重写。小修能解决局部表达问题，不能解决目标、变量、工具和业务边界混乱。反复补丁会让模板越来越长，模型反而更难抓住重点。 当模型升级后旧模板需要大量反向约束时，应重写。新模型可能适合更简洁、更结构化的指令。为了兼容旧写法而增加大量解释，会浪费上下文并增加歧义。模型迁移是重构模板体系的好时机。 团队协作方式 Prompt 版本化不是只有工程师参与。产品负责定义体验和入口，业务专家负责口径和边界，工程师负责变量、工具和发布，数据人员负责评测样本，安全人员负责风险，运营人员提供线上反馈。模板是跨职能资产，需要跨职能评审。 协作要避免两个极端。一个极端是所有人都能随手改生产提示词，速度快但风险高；另一个极端是任何标点都要开大会，最后没人愿意迭代。合理方式是按风险分级，低风险快走，高风险严审，所有发布留痕。 评审讨论要围绕样本。与其争论“这样说是不是更专业”，不如拿十条真实输入比较新旧输出。提示词工程最怕抽象审美，最需要案例驱动。每次争议都可以转成评测样本，长期看会形成团队自己的质量标准。 Prompt 资产要和成本、延迟一起评审 很多团队评审提示词时只看回答质量，不看成本和延迟，最后上线后才发现一次普通问答要塞进十几段系统说明、几十条示例、整段工具说明和一大块知识库摘要。模型回答看起来更稳了，账单和响应时间却失控了。生产环境里的 Prompt 不是孤立文本，它会变成输入词元、缓存命中率、上下文窗口占用、工具调用次数和用户等待时间。 每次模板改版都应该记录输入长度变化。系统提示增加了多少字，示例增加了多少条，变量展开后最坏会到多少 Token，是否挤压了用户问题、检索片段和对话历史的空间。一个模板在测试样本里表现很好，不代表它在长文档、长对话和多工具场景下仍然可靠。上下文预算如果没有被纳入评审，模板会不断膨胀，直到应用开始截断关键信息。 缓存也要进入评审。OpenAI、Anthropic、Google Vertex AI 等平台都提供不同形式的 Prompt 或上下文缓存能力，但缓存只有在稳定前缀、稳定资料块、稳定工具说明存在时才有价值。如果团队把时间戳、用户昵称、临时状态和随机说明放在系统提示开头，就会破坏缓存命中。模板版本化时应明确哪些部分是稳定前缀，哪些部分是每次请求变化的变量，哪些部分应放在后面，哪些内容适合做缓存。 延迟评审同样重要。模板越复杂，模型读入和推理的负担越大；工具调用策略越模糊，模型越可能多走几步；输出格式越冗长，用户等待越久。模板评审表里应有三项基本数据：平均输入 Token、平均输出 Token、P95 响应时间。质量提升如果只来自堆长提示词，要问是否能通过更好的变量设计、路由、工具 schema、结构化输出或知识库治理达到同样效果。 Prompt 事故复盘不能只改一句话 Prompt 出事故后，最常见的错误处理是改一句“不要这样回答”，然后直接发布。这样做短期看似修好了，长期会制造更多反向约束。真正复盘应该先还原事故链路：用户输入是什么，路由到哪个模板，模板版本是什么，使用了哪个模型，检索到了哪些资料，工具返回了什么，模型输出哪里偏离，后处理有没有拦截，用户最终看到什么。 复盘要把错误归类。有些错误是任务边界不清，模型不知道该问澄清还是继续执行；有些错误是变量缺失，模板假设调用方一定传入用户身份、地区、权限或资料来源；有些错误是示例误导，少数示例让模型学到错误口吻；有些错误是工具协议差，模型无法判断工具失败后应重试、降级还是交给人工；有些错误是知识库污染，模板本身没有错，错误来自过期资料。 不同错误需要不同修复。任务边界问题要重写目标和拒绝条件；变量缺失要改调用契约；示例误导要替换样例；工具协议问题要改 schema、错误码和恢复路径；知识库污染要改索引和资料治理。只有当根因确实是表达不清时，才应该只改提示词文字。否则 Prompt 会变成承接所有系统问题的补丁层，最后谁也不敢动。 每次事故修复都应增加回归样本。样本不只保存用户原话，还要保存期望行为、不能出现的行为、需要调用的工具、允许引用的资料和评判标准。如果事故属于高风险场景，还应加入红队集和人工复审队列。没有样本沉淀，团队会在同一类问题上反复摔倒。 小团队怎么低成本做版本化 小团队不一定一开始就买完整 Prompt 管理平台，也可以用轻量方式建立秩序。最小可行做法是把每个生产模板保存为独立文件，文件头写清名称、用途、负责人、模型、输入变量、输出约束、风险等级和变更记录。调用代码不要直接引用散落字符串，而是引用模板 ID 和版本号。 第二步是建一个简单评测目录。每个模板配一个样本文件，样本包含输入、期望输出要点、禁止输出、评分维度。可以先用脚本跑自动检查：是否包含必须字段，是否输出无效 JSON，是否泄露内部词，是否漏掉引用，是否超过长度。复杂质量可以先人工抽查，等样本稳定后再引入 LLM-as-judge 或专门评测工具。 第三步是发布前做差异对比。新旧模板对同一批样本各跑一遍，把输出并排看。不要只看平均分，要看哪些样本变好、哪些变坏、坏在哪里。只要发现关键样本退化，就不要直接上线。提示词发布和代码发布一样，需要接受“新版本总体更好但某个关键路径不能退化”的约束。 第四步是线上留痕。每次请求记录模板 ID、模板版本、模型、知识库版本、工具版本和评测相关指标。日志不要记录敏感正文，但要能定位一次回答是由哪套资产产生的。出现投诉或错误时，能还原版本，才能复盘和回滚。 第五步是把过期模板删掉。很多 Prompt 资产库的问题不是缺模板，而是旧模板太多。没人知道哪个能用，哪个已经废弃，哪个是实验品，哪个在线上服务。归档不是删除历史，而是把它从生产候选中移除。资产库越干净，团队越敢迭代。 结论：会过期，所以要经营 提示词模板会过期，因为它连接的是变化中的模型、业务、用户、工具、知识和风险。过期本身不可怕，可怕的是团队不知道它何时过期、为什么过期、影响了谁、如何验证和如何回退。把 Prompt 当资产管理，就是承认它会变化，并为变化建立秩序。 版本化让历史可追溯，评审让风险被看见，评测让质量可比较，灰度让发布可控制，监控让过期可发现，回滚让事故可收敛。做到这些，提示词不再是藏在代码里的长字符串，而是可以被持续改进的产品能力。 真正生产级的大模型应用，不会把提示词神秘化，也不会轻视它。它会像管理代码、数据、模型和接口一样管理 Prompt 资产：清楚职责，明确边界，证据驱动，面向用户，持续演进。 参考资料 OpenAI，Prompt engineering： https://developers.openai.com/api/docs/guides/prompt-engineering OpenAI，Working with evals： https://developers.openai.com/api/docs/guides/evals Anthropic，Prompt engineering overview： https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview Google AI for Developers，Prompt design strategies： https://ai.google.dev/gemini-api/docs/prompting-strategies LangSmith，Manage prompts： https://docs.langchain.com/langsmith/manage-prompts LangSmith，Prompt template format guide： https://docs.langchain.com/langsmith/prompt-template-format MLflow，Prompt Registry： https://mlflow.org/docs/latest/genai/prompt-registry/index.html MLflow，Manage Prompt Lifecycles： https://mlflow.org/docs/latest/genai/prompt-registry/manage-prompt-lifecycles-with-aliases/ PromptLayer，Prompt Registry Overview： https://docs.promptlayer.com/features/prompt-registry Promptfoo，Intro： https://www.promptfoo.dev/docs/intro/ Semantic Versioning 2.0.0： https://semver.org/ GitHub Docs，About pull request reviews： https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews Microsoft Foundry，Observability in generative AI： https://learn.microsoft.com/en-us/azure/foundry/concepts/observability

社区里经常有人问一个问题：我已经会写提示词了，还需要学什么？这个问题在 2023 年也许可以回答“继续练 prompt”。但到了今天，如果你想做的不是一次性演示，而是真实 AI 产品，只会写提示词已经明显不够。 原因不是提示词不重要。恰恰相反，提示词仍然重要。它是我们和大模型沟通任务、约束、风格和输出格式的第一层语言。一个烂提示词会让再强的模型也表现飘忽。但真实产品的问题从来不只在“怎么让模型说得更好”，而在“怎么让模型把事情稳定做完”。 这两个问题差别很大。 “说得更好”通常发生在一次对话里。你给模型一段材料，让它总结、改写、分类、翻译、写文案。提示词写清楚，结果就会好很多。 “稳定做完”发生在真实业务系统里。用户输入可能缺字段，数据在数据库里，知识在文档里，状态在第三方系统里，动作需要权限，接口可能超时，结果要写回系统，用户还可能中途改主意。模型不只是回答，还要检索、判断、调用工具、处理异常、等待确认、验证结果。 这时候，需要的不是更玄的提示词，而是 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 工程范围。 模型是否需要访问当前数据，而不是只靠用户输入？ 模型是否需要调用工具或影响外部系统？ 任务是否超过一次回答，需要多个步骤？ 输出是否要被系统继续消费或落库？ 是否存在权限、隐私、金额、发布、删除、发送等风险？ 失败后是否需要重试、恢复或解释？ 团队是否需要比较不同提示词、模型或流程版本？ 线上问题是否需要回放和定位？ 只要有多个答案是“是”，就不要继续把所有复杂度压在提示词里。 社区最该形成的共识 我觉得接下来做 AI 产品，社区需要从“提示词崇拜”转向“系统能力建设”。 会写提示词仍然是基本功，但它不是护城河。真正难复制的是你如何组织数据、工具、状态、评估和用户流程。一个团队的 AI 产品是否可靠，常常不是看它系统提示词有多神，而是看它失败时有没有边界，行动前有没有确认，结果有没有依据，问题能不能回放，版本能不能评估。 这也是为什么很多看似普通的工程细节，在 AI 产品里会变成核心能力。schema、日志、权限、队列、状态机、测试集、引用、审计、灰度、回滚，这些老东西并没有因为大模型出现而过时。它们只是换了一个更智能的中间层。 提示词工程教我们如何让模型理解意图。Harness 工程教我们如何让模型进入生产。 如果你想做一个能长期运行的 AI 产品，不要只问“提示词怎么写”。还要问： 模型该看什么？ 模型能做什么？ 系统必须保证什么？ 用户什么时候确认？ 失败怎么恢复？ 我们怎么知道它变好了？ 这些问题回答清楚，AI 才开始从玩具变成工具。 最后给产品负责人的一句话 如果你负责一个 AI 产品，不要把 Harness 工程看成纯技术话题。它会直接决定产品承诺能不能兑现。用户看到“帮我处理”，就会以为系统真的能处理；用户看到“已完成”，就会以为事情真的完成。后台如果只有一段提示词和一次模型调用，这种承诺就很脆。 更成熟的做法，是先把承诺拆细。哪些场景只承诺生成建议，哪些场景承诺创建草稿，哪些场景在用户确认后执行，哪些场景系统可以自动完成。每一级承诺都要有对应的 Harness 能力。只生成建议，需要好上下文和好表达；创建草稿，需要结构化输出和可编辑界面；确认后执行，需要工具权限、预览和审计；自动完成，需要评估、回滚和监控。 这样拆完以后，路线会清楚很多。产品不必一开始就宣称全自动，也不必停在聊天框。可以先把一个高频任务做深：资料查准，状态清楚，动作可确认，失败能解释，结果能追踪。一个做深的任务，比十个只会回答的入口更有价值。 对用户来说，真正好的 AI 产品不是最会说话的那个，而是最少让人收拾残局的那个。Harness 工程的意义，正是减少残局。 还有一个很现实的判断：当用户开始把真实资料、真实客户、真实项目、真实代码交给系统时，他期待的已经不是“灵感辅助”，而是“可信协作”。可信协作需要清楚边界。系统知道什么，依据来自哪里，准备做什么，哪些需要确认，哪些已经完成，哪些没有完成，都要说得明白。只有把这些能力做进 Harness，提示词里的聪明才不会停留在文本表面，而能变成用户日常工作中可依赖的生产力。它让产品有边界，有节奏，也有长期改进的抓手。 给社区开发者的落地检查表 如果你今天就要检查自己的 AI 功能，可以先问十二个很具体的问题。用户输入不完整时，系统会追问还是硬答？回答涉及事实时，能不能看到资料来源？模型拿到的资料有没有权限过滤？工具失败时，用户看到的是人话还是技术错误？有副作用的动作有没有预览？用户确认的内容是否具体到对象、时间、收件人、金额或文件？任务中断后能不能恢复？线上失败有没有进入样本库？每次改提示词后有没有跑旧样本？前端有没有把内部字段藏起来？模型是否会在不知道时承认不知道？系统是否区分草稿、建议、待确认和已执行？ 这张表不复杂，但很能暴露产品成熟度。很多项目并不是模型不够强，而是这些问题没有答案。用户第一次使用时可能只看回答是否流畅，持续使用时一定会看系统是否可靠。可靠来自细节：少编造，能追溯，敢承认失败，行动前确认，失败后能解释，版本变化有评估。把这些细节补上，哪怕模型没有换，产品也会明显更像一个真正能用的助手。 还有一个建议：不要把所有反馈都写成“优化提示词”。社区项目可以建立一个小表格，把反馈分成提示词问题、上下文问题、工具问题、权限问题、界面问题、评估问题。这样排查几轮以后，团队会发现很多所谓提示词问题其实是系统设计问题。分类清楚，修复才会准确。 对开源或小团队项目来说，还可以把这些检查公开成项目约定。比如每个新工具都必须说明是否只读，每个有副作用的能力都必须提供预览，每个知识库回答都必须能返回来源，每个版本发布都至少跑一组回归样本。约定不需要很厚，但要能执行。社区成员参与贡献时，也能知道什么算完成，什么只是演示。这样项目越多人用，质量越容易沉淀，而不是越改越散。长期看，这些约定就是项目的可信基础和协作底线。 参考资料 OpenAI: Harness engineering - OpenAI 对 Harness engineering 概念及其与 Agent 工作流关系的说明。 OpenAI: A Practical Guide to Building Agents - OpenAI 关于 Agent 组件、工具、护栏和编排的实践指南。 OpenAI Agents SDK Docs - OpenAI Agents SDK 关于工具、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 - LangGraph 关于状态化 Agent、持久执行和人在环路的文档。 LangSmith Documentation - LangSmith 关于 tracing、evaluation 和 observability 的文档。 Model Context Protocol Documentation - MCP 官方文档，说明模型连接工具、资源和上下文的协议。 Microsoft Prompt flow Documentation - Microsoft 关于提示流、评估和生成式 AI 应用工程化流程的文档。 LlamaIndex Documentation - LlamaIndex 关于数据连接、RAG、Agent 和工作流的项目文档。 CrewAI Documentation - CrewAI 关于 Agent、Task、Tool 和 Flow 编排的项目文档。 ReAct: Synergizing Reasoning and Acting in Language Models - 关于语言模型结合推理与行动的经典论文。 Toolformer: Language Models Can Teach Themselves to Use Tools - 关于语言模型学习使用外部工具的论文。 Reflexion: Language Agents with Verbal Reinforcement Learning - 关于语言智能体通过语言反馈改进表现的论文。

对。少一点“我认为”，多一点“我遇到的现象是”。

我准备把后台改成草稿发布，不能直接上线。

这比单纯要求谦虚更有效。

对，这才是工程。

对，别先调温度。温度不是清洁剂。

我去改版，不再用“完整”这个模糊词。

我先把差评样本拉出来，分类型调。之前确实全靠感觉。

这比多写 200 字安全 prompt 管用。

我先做盲评表，不拿小样本装大结论。

很多团队不是缺 prompt 工程，是缺事故现场。

收到。我先把分类和 JSON 抽取拆成两步。

明白。20 条先当烟测，不拿来证明上线质量。

真正增强答案的是证据和任务边界，不是夸它。