提示词模板当然会过期。它不像一段静态标语，写好以后长期不变；它更像产品规则、接口契约、客服话术、风控策略和测试用例的混合体。模型版本会变，用户问题会变，工具接口会变，知识库会变，业务政策会变，安全要求会变，评测标准也会变。只要这些外部条件发生变化，曾经表现良好的提示词模板就可能开始失效。 把提示词当作一次性文案，是很多大模型应用早期能跑、后期难维护的原因。一个提示词模板通常承担多重职责：告诉模型扮演什么角色，限定可用信息，规定输出结构，选择工具调用方式，表达拒绝边界，连接业务字段，承载少量示例，适配模型能力，并把产品体验转成可执行指令。这些职责任何一个变化，都可能让模板需要升级。 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

RAG 经常答错，不是因为 RAG 这个方向错了，而是因为很多系统只做了“把文档塞进向量库，再把相似片段塞给大模型”这一小段。真正的 RAG 是一条证据链：原始数据要被正确解析，文档要被合理切分，查询要被理解和改写，候选片段要被召回，结果要被重排，证据要被压缩和组织，模型要基于证据回答，引用要能回到原文，数据还要持续更新。任何一个环节松动，最后都会表现为“模型胡说”。 很多用户看到 RAG 答错时，会第一时间怀疑大模型不够强。模型当然重要，但 RAG 的错误通常更像供应链问题。模型拿到的片段不相关，它会被带偏；片段相关但缺少上下文，它会误读；片段重复又冲突，它会随机挑一边；片段过期，它会认真回答旧事实；引用没有绑定原文，它会生成看似可信的假出处；召回漏掉关键证据，再强的模型也无法凭空补齐。RAG 的可靠性，取决于证据如何进入模型，而不只取决于模型本身。 RAG 最初的研究目标，是把参数化记忆和外部非参数记忆结合起来，缓解大模型知识更新和出处追踪问题。Lewis 等人在 2020 年的 RAG 论文里讨论了用检索到的 Wikipedia 段落辅助生成，核心价值是让模型可以访问显式知识并提供 provenance。这个想法进入产品之后，被简化成了向量搜索加提示词拼接。简化可以让原型快速跑起来，但也埋下了生产失败的根。 本文按一条真实 RAG 链路展开：先讲为什么切分会毁掉语义，再讲召回为什么经常漏，接着讲重排为什么是质量闸门，然后讲引用为什么不能靠模型自由生成，最后讲数据新鲜度为什么决定长期可信。目标不是堆术语，而是让读者看清：RAG 答错时，应该从哪里排查，怎么设计一个更可靠的系统。 一、RAG不是“搜索一下再回答” 普通搜索系统的目标是把相关文档排到前面，用户自己阅读和判断。RAG 的目标更复杂：系统要把外部资料转换成模型可用的证据，并让模型生成一个可直接使用的答案。中间多了一层生成，风险就变多。搜索结果里有十条，用户可以看到差异；RAG 把十条压成一段回答，错误可能被流畅语言掩盖。 搜索系统可以容忍结果列表里有几个不相关页面，因为用户会跳过。RAG 不一定能容忍。只要无关片段被放进上下文，模型就可能把它当成证据。尤其是当无关片段文字更具体、数字更多、措辞更肯定时，模型可能优先采用它。相似不等于正确，语义相近不等于回答问题。 RAG 也不是长上下文的廉价替代。有人以为模型上下文变长后，可以把整个文档都塞进去，不需要检索。问题是长上下文模型并不总能均匀使用全部输入。Lost in the Middle 研究发现，相关信息位置会显著影响模型表现，开头和结尾的信息更容易被利用，中间信息可能被忽视。长窗口扩大了可输入内容，不等于消除了信息组织问题。 RAG 的理想状态，是把“最少但足够”的证据送到模型面前。证据太少，模型缺事实；证据太多，模型被噪声淹没；证据太碎，模型误读；证据太旧，模型过时；证据无来源，模型无法引用；证据无结构，模型难以比较。好的 RAG 系统是证据工程，不是文本搬运。 二、第一类失败：原始文档解析已经坏了 很多 RAG 项目从切分开始讨论，却忽略了切分之前的解析。PDF、Word、网页、扫描件、PPT、表格、图片、代码仓库、邮件、工单、数据库导出，格式都不一样。解析器如果把页眉页脚混进正文，把两栏排版读成错序，把表格行列打散，把脚注插到段落中间，把图片 OCR 识别错，后面的 embedding 再先进也只能索引坏文本。 企业文档尤其容易出问题。合同里一个“除外”被断到下一页，模型可能读成相反意思；制度文件里的表格如果丢了列名，金额和条件就失去关系；产品手册如果把章节编号和正文拆开，检索时可能只召回孤立句子；代码文档如果把函数签名和说明分离，模型会错用参数。RAG 的很多幻觉，根源不是生成，而是入库文本已经失真。 解析失败还有一种隐蔽形态：元数据丢失。文档标题、版本号、生效日期、部门、页面、章节、URL、权限、语言、产品线、地区，这些信息对回答很关键。如果只保存纯文本，模型就不知道这段话来自哪个版本，也不知道它是不是适用于当前用户。后来即使召回到了文字，也无法判断优先级。 生产级 RAG 应该把解析质量当成第一道验收。入库前要抽样查看原文和解析文本是否一致，尤其是表格、列表、图片、页眉页脚、脚注、跨页段落、代码块和中文标点。不要只看“文件已上传成功”。上传成功只是存储成功，不代表知识可用。 更好的做法是保留多层表示。原始文件要保留，解析后的 Markdown 或结构化文本要保留，页面坐标或章节锚点要保留，表格最好保留行列结构，图片要保留 OCR 结果和原图引用。这样生成引用时，系统才能回到原文，而不是只能引用一段脱离来源的纯文本。 三、第二类失败：切分把完整意思切碎了 切分是 RAG 的核心难题之一。大文档必须切成小块，才能被检索和放进模型上下文。但每一刀都可能损坏语义。切太短，片段缺少上下文；切太长，召回粒度变粗，噪声变多；重叠太少，跨段信息断裂；重叠太多，结果重复，浪费 token；按固定字符切，可能把一句话、一个表格、一个代码函数或一个条款拆开。 LangChain 文档建议多数场景从 RecursiveCharacterTextSplitter 这类递归切分开始，因为它尝试优先保留段落、句子等自然结构。LlamaIndex 的 SentenceSplitter 也强调尽量保持句子和段落完整，减少块尾出现半句话。它们背后的原则很朴素：切分应该尊重文本结构，而不是只追求固定长度。 合同、制度和技术文档不适合只按字符数切。合同条款有编号、主条款、子条款、例外条件和定义引用。技术文档有标题层级、步骤、参数、返回值和示例。代码仓库有文件、类、函数、注释和测试。表格有表头、单位、行列关系。切分策略应根据文档类型变化。统一用 1000 字加 200 字重叠，能跑原型，但很难长期稳定。 切分失败常见表现是“召回到了相关片段，但答案仍然错”。比如用户问某政策适用条件，召回片段只有结论句，没有上文限定；用户问某 API 参数，召回片段只有参数说明，没有函数名；用户问某费用标准，召回片段只有数字，没有地区和日期；用户问某合同责任，召回片段只有义务，没有免责条款。模型看到局部事实，就会做局部回答。 解决切分问题，不能只调 chunk_size。要先定义“一个可回答证据单元”是什么。对 FAQ，一个问答对就是自然单元；对制度，一条完整条款加标题路径是单元；对代码，一个函数或类加必要注释是单元；对表格，一行记录加表头和单位是单元；对会议纪要，一个议题加决议和负责人是单元。切分不是数学均分，而是业务结构识别。 有些系统会使用父子块。小块用于召回，大块用于生成。先用更细粒度片段找到相关位置，再把所属章节、父段落或相邻窗口送给模型。这能同时兼顾召回精度和上下文完整性。对长文档问答，父子块往往比单一粒度更稳。 还有一种做法是给每个 chunk 增加上下文说明。Anthropic 的 Contextual Retrieval 技术博客提出，在嵌入前用模型为每个片段补充它在原文中的上下文，使孤立片段在检索时更容易被正确理解。官方示例显示，contextual embeddings、contextual BM25 和 reranking 组合可以显著降低检索失败。这个思路说明，切分后不能假设片段仍然自解释。 四、第三类失败：只用向量召回，漏掉关键词和精确条件 向量召回擅长语义相似，但不擅长所有问题。用户问“报销单据超过 30 天还能提交吗”，语义搜索可能找到“报销流程说明”；用户问“API 返回 429 怎么处理”，向量搜索可能找到“错误码说明”；用户问“GLM-4.5-Air-FP8 需要几张 H100”，向量搜索可能找到“GLM-4.5 推理配置”。但如果问题里有精确数字、型号、错误码、条款编号、人名、产品名、日期、版本号，关键词匹配往往更可靠。 纯向量召回容易漏掉稀有词。企业知识库里有大量内部术语、缩写、项目代号、SKU、错误码和专有名词。embedding 模型未必理解这些词的业务含义，甚至可能把它们当噪声。关键词搜索虽然老，但对精确匹配非常重要。生产 RAG 往往需要混合召回：向量召回找语义相关，BM25 或关键词找精确匹配，再合并候选。 召回还会被用户问题写法影响。用户问“这个钱什么时候打”，系统要知道“钱”可能指报销、补贴、退款、付款、工资或合同款。用户问“上次那个配置能不能跑”，系统要结合会话历史。用户问“这个政策还有效吗”，系统要把有效期、版本和发布部门放进查询。直接把用户原话拿去向量搜索，常常不够。 查询改写可以改善召回，但也会引入风险。模型可以把口语问题改写成规范查询，也可以生成多个子查询覆盖不同表达。比如“RAG 答错为什么”可以拆成“chunking failure”“retrieval recall failure”“reranking”“citation hallucination”“data freshness”。但查询改写必须保留用户意图，不能擅自加条件。生产系统最好保留原查询和改写查询的召回结果，避免改写错了导致完全偏航。 召回的 top_k 也不是越大越好。top_k 太小，容易漏证据；top_k 太大，后续重排和生成被噪声影响。更合理的方式是先多路召回较宽候选，再通过重排压缩到较少高质量证据。比如向量召回 30 条、关键词召回 30 条、元数据过滤后合并去重，再用 reranker 选前 5 到 10 条进入答案生成。不同业务需要实测，不要照搬固定值。 召回还必须考虑权限和过滤。用户不该看到的文档，即使语义相关，也不能进入上下文。地区、部门、产品线、客户等级、生效日期、文档状态都可能是过滤条件。很多 RAG 错误不是“没搜到”，而是“搜到了不该搜的旧文档、测试文档、草稿文档或别的部门文档”。检索前过滤和检索后过滤都要设计。 五、第四类失败：没有重排，模型被相似噪声带偏 召回负责找候选，重排负责精挑细选。很多 RAG 原型省略重排，直接把向量相似度最高的几个片段塞给模型。这在小知识库里可能能用，一旦文档规模变大、相似内容变多、用户问题更复杂，就会明显掉质量。相似度最高的片段未必最能回答问题。 Cohere 的 Rerank 文档把 rerank 描述为给定 query 和 documents 后，把文档按语义相关性重新排序。重排模型通常会同时看查询和文档，做更细粒度匹配。相比 embedding 先把文本压成向量再比距离，reranker 能更直接判断“这段是否回答这个问题”。对复杂问题、半结构化文档、多语言和相似条款，重排尤其重要。 重排可以解决几类常见问题。第一，召回到了同主题但不回答问题的段落，重排可以把真正含答案的段落提到前面。第二，多个版本文档都相似，重排配合元数据可以优先新版本。第三，用户问题包含多个条件，重排能更好识别同时满足条件的片段。第四，召回结果里有重复摘要和正文，重排能保留更有证据价值的原文。 但重排也不是万能。reranker 的输入长度有限，太长的 chunk 会被截断；候选里没有正确证据，重排无法凭空创造；元数据不进重排输入，模型就不知道版本和来源；重排目标如果只看相关性，不看新鲜度和权限，仍会选出错误片段。重排应该和过滤、去重、版本优先级一起工作。 重排后的证据还要做组织。不要把 top 片段按相似度简单拼接。更好的组织方式是按来源分组、按章节顺序排列、把同一文档相邻片段合并、把冲突证据标出、把最新版本放前面、把引用编号固定。模型看到有序证据，比看到一堆相似片段更容易回答正确。 重排还要服务成本。把 30 个候选全部塞给大模型，既贵又容易乱。reranker 可以让生成模型只读高信号证据，减少上下文长度、降低延迟、减少 lost-in-the-middle 风险。RAG 系统里，花一点成本在重排上，往往比花更多成本换更大生成模型更划算。 六、第五类失败：引用是生成出来的，不是绑定出来的 很多 RAG 系统最危险的地方，是让大模型自己写引用。模型生成“根据文档 3”“见第 12 页”“来源：某政策”这类文字，看起来很可信，但如果引用没有和检索片段、原文位置、版本和 URL 绑定，它就只是另一段生成文本。用户以为有出处，实际出处可能不存在或不支持结论。 可靠引用应该由系统生成，而不是由模型自由发挥。检索阶段每个 chunk 都要带 source_id、document_id、title、version、page、section、url、start_offset、end_offset 等元数据。生成答案时，模型可以选择引用哪些证据编号，但最终展示的链接和出处应由系统根据编号渲染。模型不应该手写 URL，也不应该编造页码。 引用还要满足“可追溯到原文”。用户点击引用后，应该看到对应原文段落或页面，而不是只看到同一文档首页。如果答案说“试用期为三个月”，引用应定位到包含这句话和适用条件的条款。如果只跳到一份 80 页 PDF，用户仍然无法验证。生产 RAG 的引用体验应该像证据高亮，而不是参考文献装饰。 引用和答案之间还要做一致性检查。答案里的每个关键事实，最好都能对应一个或多个证据。数字、日期、条件、否定、例外、责任主体尤其需要引用。没有证据支撑的句子，要么删除，要么标注“资料中未找到”。很多 RAG 错误来自模型把证据外的常识、旧知识或推测混进答案。 引用粒度也要控制。引用太粗，无法验证；引用太碎，用户看不懂。一个答案段落通常引用一到三个证据比较合适。多个证据支持同一个结论时，要明确它们的关系：是互相补充，还是不同版本，还是存在冲突。遇到冲突证据，系统不应假装一致，而应说明“资料中存在版本差异”并优先显示生效版本。 还有一种常见失败是引用正确但结论错误。模型引用了相关段落，却误读了条件。比如原文说“除非经审批，否则不得报销”，模型回答“可以报销”；原文说“2025 年 1 月 1 日后签署的合同适用”，模型忽略日期；原文表格里金额按地区不同，模型取错列。引用只能证明模型看过资料，不能自动证明推理正确。因此高风险场景需要答案校验或人工复核。 七、第六类失败：数据新鲜度被忽略 RAG 的一个承诺是知识可更新，但很多系统上线后并没有真正更新。文档上传一次，向量库长期不重建；网页改了，索引没变；政策过期，旧版本仍被召回；文件删除了，chunk 还在；权限变更了，索引没有同步；产品价格更新了，缓存仍返回旧答案。结果用户看到的是“带引用的过期回答”。 数据新鲜度不是简单的定时全量重建。生产系统需要知道每份文档的生命周期：创建、审核、发布、生效、过期、替换、撤回、删除。每个 chunk 应继承文档状态和版本。检索时应默认排除草稿、废止、过期、无权限和低可信来源。若用户明确询问历史版本，系统才检索旧资料。 增量更新要处理删除和替换。很多系统只会追加新文档，不会清理旧 chunk。文档标题一样、版本不同，向量库里同时存在多份，召回时它们都很相似。模型可能把旧政策和新政策混在一起。正确做法是给文档稳定 ID 和版本 ID，新版本发布时标记旧版本状态，必要时删除旧 chunk 或降低优先级。 新鲜度还包括外部实时数据。库存、订单、工单状态、汇率、价格、排班、服务状态、法律法规，不能只靠离线知识库。RAG 应该和工具调用结合：静态知识走文档检索，动态事实走 API 或数据库。用户问“我的订单到哪了”，检索帮助理解流程，真正状态必须查订单系统。把动态事实写进向量库，会很快过期。 时间表达也要规范。用户问“现在还能申请吗”，系统需要知道当前日期、政策生效期和用户所在地区。答案里要说具体日期，而不是只说“目前”。索引和生成都要带时间意识。否则模型可能引用一份旧公告回答“可以”，却没有注意申请截止日期已经过去。 新鲜度还需要监控。可以建立过期文档召回率、旧版本命中率、无效引用点击率、答案时间冲突率等指标。每次用户点踩或人工纠错时，要能追溯是文档没更新、索引没更新、过滤失败、重排错误还是模型误读。没有这些指标，RAG 会随着知识库增长逐渐变差，而团队只会感觉“最近模型不太行”。 八、第七类失败：把长上下文当成保险箱 模型上下文越来越长，很多团队开始减少检索设计，直接把更多内容塞进去。这种做法在小规模演示中有效，但在生产里会遇到成本、延迟和注意力分配问题。长上下文不是保险箱，不能保证放进去的每条信息都会被正确使用。 Lost in the Middle 的发现对 RAG 很重要。相关证据位置会影响模型使用效果，尤其在多文档问答和 key-value retrieval 中，信息在中间时表现可能下降。RAG 如果把大量召回片段无序拼接，关键证据可能被埋在上下文中间。此时模型答错，不是因为证据没给，而是证据没有被有效呈现。 长上下文还会放大冲突。假设系统把新旧政策、FAQ、用户历史、工具结果、相似案例都塞进去，模型会面对多个相互矛盾的事实。没有优先级规则，它可能选择更靠近开头或结尾的内容，或者选择措辞更明确的旧内容。上下文越长，越需要排序、分组和冲突处理。 长上下文成本也很高。输入 token 多会增加 prefill 延迟和费用，自建服务还会占用 KV Cache，降低并发。为了避免一次漏召回而每次塞 50 页资料，通常不是好设计。更好的做法是先用检索和重排定位证据，再给模型足够但不冗余的上下文。长上下文可以作为复杂问题的升级手段，而不是默认策略。 如果确实需要长上下文，应设计证据布局。把任务说明、用户问题、最关键证据、冲突说明、引用规则和输出格式放在清晰位置。相同来源的片段按原文顺序排列，多个来源按优先级排列。不要把几十段候选直接拼接成“资料如下”。模型不是人类搜索结果阅读器，它需要结构化输入。 九、第八类失败：评测只看最终答案，不看中间证据 RAG 评测如果只看最终回答，很难定位问题。答案错了，可能是解析错、切分错、召回漏、重排错、引用错、生成错、数据旧，也可能是问题本身无答案。把所有错误都归给模型，会导致错误修复方向混乱。 更好的评测要分层。第一层是解析评测：原文和入库文本是否一致，表格、标题、页码、章节、图片是否保留。第二层是切分评测：一个问题需要的完整证据是否在同一块或可通过父子块恢复。第三层是召回评测：正确证据是否进入候选集。第四层是重排评测：正确证据是否排在前几名。第五层是生成评测：给定正确证据时模型是否能答对。第六层是引用评测：答案引用是否支持结论。 召回评测要建立标准答案和标准证据。比如一个问题对应哪份文档、哪个章节、哪几段原文。然后计算 recall@k、MRR、nDCG 等指标。很多团队没有证据标注，只靠人工看答案，这样很难知道是否该调 embedding、chunk、reranker 还是 prompt。 生成评测也不能只看口感。要检查事实正确、条件完整、引用准确、是否承认不知道、是否遗漏例外、是否混用旧版本。对严肃业务，答案应该分事实项打分。一个回答语气很好但漏掉免责条件，应该判失败。 评测集要持续更新。新文档、新产品、新政策、新失败案例都应进入评测。RAG 系统越用越复杂，老评测集会失效。用户真实问题是最好的来源，但需要脱敏、归类和证据标注。每次改切分、换 embedding、换 reranker、换生成模型，都要跑同一套评测，避免某项提升掩盖另一项退化。 还要做负样本评测。不是所有问题都有答案。用户问知识库里不存在的信息，系统应该说找不到，而不是编一个。负样本包括无资料问题、权限外问题、过期政策问题、条件不足问题、相似但不同问题。RAG 的可信度，很大一部分来自会拒绝。 十、第九类失败：提示词补丁掩盖了系统问题 RAG 答错后，很多团队习惯在提示词里加一句“请严格根据资料回答”。这句话有用，但很有限。如果召回片段错了，模型会严格根据错资料回答；如果资料互相冲突，模型不知道严格根据哪一条；如果引用没绑定，模型会严格生成看似规范的假引用；如果数据过期，模型会严格使用过期信息。 提示词可以约束生成风格，不能替代证据治理。真正有效的提示词应该配合系统结构：证据编号明确，来源和日期可见，冲突资料被标注，输出格式清晰，缺证据时允许回答不知道，引用只能使用给定编号。提示词越清楚，模型越容易遵守；上下文越混乱，提示词越容易失效。 不要把所有规则都塞进一个巨大系统提示词。RAG 上下文里已经有文档、证据、用户问题和输出要求，如果再加几十条重复规则，模型更容易分心。生产提示词应短而有层次：角色、任务、证据使用规则、引用规则、拒答规则、输出结构。业务规则应该来自可检索资料或结构化配置，而不是藏在提示词里。 提示词还要避免让模型“必须回答”。很多系统为了用户体验，要求模型给出完整答案。这会鼓励幻觉。更好的要求是：如果证据不足，说明缺少哪些信息；如果资料冲突，列出冲突；如果问题超出范围，建议用户提供文档或联系对应部门。可信系统不怕说不知道，怕的是假装知道。 十一、第十类失败：把RAG和Agent混在一起却没有边界 现在很多系统把 RAG 接进 Agent，让模型自己决定搜什么、读什么、调用什么工具。这个方向很有价值，但也会放大不确定性。一个普通 RAG 至少检索路径可控；Agentic RAG 如果没有边界，模型可能反复搜索、改写错查询、忽略高质量证据、使用过期工具结果，甚至把网页噪声混进企业知识库。 Agentic RAG 需要明确职责。检索工具负责找证据，数据库工具负责查实时状态，计算工具负责算数，生成模型负责解释和组织。模型可以规划，但不能绕过权限、版本和引用规则。每个工具返回结果时，应带来源、时间、置信度和错误状态。模型不应该把工具报错当成事实。 Agentic RAG 还要有停止条件。用户问一个政策问题，不需要模型搜索十轮。若前两轮已经找到高置信证据，就应该回答；若多轮仍找不到，应说明未找到。没有停止条件的系统会增加延迟和成本，还可能在后续搜索中找到低质量噪声，把原本正确的答案带偏。 多工具场景更需要证据合并。比如用户问“我这个订单是否还能退款”，系统可能需要检索退款政策、查询订单状态、查询商品类型和检查时间。最终答案必须说明哪些结论来自政策，哪些来自订单系统。静态规则和动态状态不能混成一团。否则用户无法判断答案依据。 十二、如何排查一次RAG答错 遇到 RAG 答错，不要先改 prompt。第一步，拿到用户原问题、最终答案、引用和所有进入模型的上下文。没有这些日志，排查只能猜。第二步，查看正确答案需要哪些原文证据。第三步，检查这些证据是否在知识库里，是否解析正确，是否有权限，是否是最新版本。 第四步，看切分。正确证据是否被切碎，关键条件是否和结论分离，表格是否丢表头，标题路径是否保留。第五步，看召回。正确 chunk 是否进入候选 top_k；如果没有，试关键词、混合召回、查询改写和元数据过滤。第六步，看重排。正确候选是否被 reranker 排到前面；如果没排上，检查 chunk 太长、输入缺元数据、问题改写错误或 reranker 不适合语言。 第七步，看证据组织。正确证据是否进入生成上下文，是否被放在容易利用的位置，是否和冲突旧资料混在一起。第八步，看生成。给模型只提供正确证据，它是否还能答错；如果仍错，才重点考虑换模型、改提示词或增加校验。第九步，看引用。答案里的引用是否真实支持结论，点击能否回到原文。 这个流程看似麻烦，但它能避免盲目优化。很多时候问题在第二步就暴露：正确文档根本没入库。或者第五步发现：正确证据在候选第 40 名，top_k 设成 5。或者第七步发现：旧版本放在新版本前面。只有分层排查，才能知道该修哪里。 十三、一个更可靠的RAG架构 可靠 RAG 的第一层是数据治理。文档进入系统时，要记录来源、作者、部门、版本、生效期、权限、语言、类型和更新时间。解析后要有质量检查，低质量解析不能直接入库。文档状态变化要同步到索引，删除和过期要真的生效。 第二层是结构化切分。按文档类型选择切分器，保留标题路径、页码、表头、代码结构、列表层级和前后关系。必要时使用父子块、多粒度索引和上下文增强。切分结果要可视化，让运营或知识管理员能看到系统到底把文档切成了什么。 第三层是混合召回。向量召回、关键词召回、元数据过滤、同义词扩展、查询改写和会话上下文共同工作。召回候选要去重、按权限过滤、按版本过滤。对精确问题，关键词和元数据权重要提高；对语义问题，向量权重可以提高。 第四层是重排和证据压缩。用 reranker 从候选里挑高质量证据，再按来源、版本和章节组织。对太长的证据，做面向问题的压缩，但压缩结果仍要保留原文引用。不要把摘要当成唯一证据，摘要可能丢条件。 第五层是受约束生成。模型只能基于给定证据回答，引用只能使用证据编号。输出结构要适合用户：先给结论，再给依据，再给限制和下一步。没有证据时要明确说明。遇到冲突时要展示冲突，而不是强行合并。 第六层是验证和反馈。答案生成后检查引用是否存在、引用是否被使用、关键事实是否有证据、是否使用过期文档。用户反馈和人工纠错要回流到评测集。系统每次改动都要跑分层评测，而不是只看一两个演示问题。 十四、给不同团队的落地建议 个人开发者做 RAG，先不要追复杂框架。用少量高质量文档，手工检查解析和切分，建立十几个真实问题和标准证据。先做到每个答案都能引用原文，再考虑多路召回和重排。不要一开始就上传几千份 PDF，然后靠模型解决所有混乱。 创业团队做产品，重点是可观测和评测。每次回答都要能回放：用户问题、召回候选、重排结果、进入模型的证据、最终答案和引用。没有回放，就无法修用户投诉。评测集要覆盖主要客户场景，尤其是失败案例。 企业内部知识库，重点是权限、版本和新鲜度。企业资料不是公开网页，谁能看什么很重要。政策和流程经常更新，旧版本必须管理。知识管理员需要看到入库状态、解析质量、过期提醒和用户低分问题。RAG 不只是技术系统，也是知识运营系统。 高风险行业，重点是拒答和复核。医疗、法律、金融、人事、合规等场景不能把 RAG 答案当成最终裁决。系统应给依据、限制和建议复核路径。没有足够证据时宁可不答。引用必须能回原文，关键结论最好有二次校验。 开发工具和代码知识库，重点是结构。代码不能按普通文本切分。文件路径、函数、类、接口、测试、README、issue、commit 信息都应保留。用户问错误栈时，关键词和符号匹配非常关键。生成代码建议时，要引用具体文件和函数，而不是泛泛解释。 十五、结论：RAG可靠性来自证据链，不来自一句“严格根据资料” RAG 经常答错，是因为很多系统只完成了最容易演示的部分，却跳过了最难生产化的部分。切分没有保语义，召回没有保覆盖，重排没有保相关，引用没有保可追溯，数据没有保新鲜，评测没有保定位。最后模型只能在混乱证据里生成一个看似流畅的答案。 好的 RAG 不追求把所有资料塞给模型，而是把正确证据以正确顺序、正确粒度、正确来源送给模型。它会知道哪些资料过期，哪些资料冲突，哪些问题无答案，哪些结论需要引用。它不是让模型替你读一堆乱文档，而是建立一套证据加工和验证系统。 当 RAG 答错时，最有效的态度不是“换个更强模型试试”，而是沿证据链往回查：原文是否正确，切分是否完整，召回是否命中，重排是否选对，引用是否绑定，数据是否最新，模型是否误读。只有这样，RAG 才能从演示功能变成可信产品能力。 十六、RAG质量指标应该怎么设 RAG 上线后，最怕只有一个笼统的“满意度”。满意度有价值，但它太晚、太粗，也不一定能解释问题。用户点踩可能是答案错，也可能是语气差、太长、没给操作步骤、引用打不开或等待太久。要让 RAG 可维护，必须把指标拆到链路层。 解析层可以看解析成功率、低质量页面比例、表格保留率、OCR 置信度、空文本文件比例、重复页眉页脚比例。切分层可以看平均块长、过短块比例、过长块比例、标题路径缺失率、表格块完整率、父子块关联率。召回层可以看 recall@k、关键词命中率、向量召回覆盖率、正确文档进入候选比例。重排层可以看正确证据进入 top3 或 top5 的比例。 生成层指标要看事实正确率、引用支持率、无答案拒答率、格式成功率、答案长度、人工修改率。引用层要看可点击率、原文定位成功率、引用与结论一致率。新鲜度层要看过期文档命中率、旧版本命中率、删除文档残留率和索引延迟。性能层要看首字延迟、总耗时、检索耗时、重排耗时、生成耗时和超时率。 这些指标不需要一天全部建完，但至少要有回放能力。每个错误答案都应该能看到检索候选、重排顺序、进入模型的上下文和最终引用。没有回放，所有指标都是表面数字。RAG 是证据链系统，监控也必须沿证据链设计。 十七、知识运营比模型调参更长期 很多团队把 RAG 当成工程项目，做完上传、检索、问答就结束。真实情况是，RAG 更像知识运营系统。文档每天会变，组织结构会变，权限会变，用户问题会变。没有人负责知识质量，系统会越来越脏。模型能力再强，也无法长期弥补知识库失管。 知识运营至少包括四件事。第一，入口治理。哪些文档能入库，谁审核，草稿能不能被检索，扫描件是否需要人工校对。第二，版本治理。新旧版本如何关联，废止文档如何处理，历史版本什么时候可查。第三，反馈治理。用户点踩后谁处理，错误样本如何归类，是否需要更新文档、调整切分还是修生成。第四，质量巡检。定期抽查高频文档、高风险文档和低分问题。 很多 RAG 错误其实是组织流程问题。客服知识库里新政策已经发布，但知识管理员没入库；产品价格改了，但旧 FAQ 还在；法务更新了合同模板，但销售仍然上传旧版；权限组调整了，但索引没同步。这些问题不是改 prompt 能解决的。RAG 想可靠，必须有人对知识生命周期负责。 知识运营还要面向最终用户。用户不关心向量库、embedding 和 reranker，他只关心答案是否能解决问题。界面应展示清晰结论、来源、更新时间和下一步操作，不要暴露内部字段和调试术语。引用打不开、来源标题混乱、更新时间缺失，都会削弱信任。RAG 产品的可信度，一半来自答案，一半来自证据呈现。 十八、几个典型错误模式 第一种模式是“相似条款误命中”。用户问请假制度，系统召回加班制度，因为两者都出现“审批”“部门负责人”“三个工作日”。模型据此回答，语气很确定。解决办法是加强元数据过滤、条款标题权重、关键词召回和重排，让同主题但不同制度的片段被区分开。 第二种模式是“旧版本压过新版本”。新政策和旧政策文字大部分相同，向量相似度都高，旧版本因为内容更长或出现更多关键词排在前面。模型引用旧版本回答。解决办法是版本状态过滤、生效日期排序、旧版降权和冲突提示。知识库里允许保留历史版本，但默认回答当前版本。 第三种模式是“表格失去表头”。原文表格里有地区、等级、金额和适用时间，解析后每行只剩数字。用户问某地区标准，模型召回数字却不知道列含义，于是取错值。解决办法是表格结构化入库，把每行记录和表头、单位、标题绑定，必要时用数据库查询而不是普通文本检索。 第四种模式是“多跳问题只召回一跳”。用户问某员工是否符合补贴条件，系统需要同时查员工地区、入职时间、政策条件和例外条款。普通 RAG 只召回政策结论，没有查员工状态。模型给出一般性回答。解决办法是区分静态知识和动态数据，让 RAG 与工具调用协同，并在答案里分清依据来源。 第五种模式是“摘要覆盖原文”。系统为了省 token，先把文档摘要入库。摘要里漏掉例外条件，用户问到边界情况时，模型只能根据摘要回答。解决办法是摘要可以作为导航，但不能替代原文证据。最终回答高风险问题时，仍要引用原文片段。 第六种模式是“负样本被强答”。知识库没有答案，召回系统找了几个相近片段，模型为了满足用户给出推测。解决办法是设置证据阈值、拒答策略和负样本评测。没有足够证据时，正确答案就是说明未找到，并告诉用户需要补充什么资料。 第七种模式是“引用编号漂移”。模型回答第一段引用了资料 2，但系统渲染时资料排序变化，页面显示成资料 1。用户点击后发现不支持结论。解决办法是引用编号由系统固定，生成前后保持稳定，用不可变 evidence_id 绑定，不让模型或前端重排破坏映射。 十九、从原型到生产的路线 第一阶段，做小而准。选择一个明确知识域，清洗几十到几百份高质量文档，建立真实问题集和标准证据。先让系统在这个小范围内答准，而不是追求全公司文档都能问。小范围答不准，扩大规模只会放大混乱。 第二阶段，加回放和评测。把每次问答的中间结果存下来，建立人工标注流程。用户反馈进入错误库，错误库反过来扩充评测。每次改 chunk、embedding、reranker、prompt、模型，都要跑同一套问题。没有评测的迭代，容易把旧问题修好又引入新问题。 第三阶段，加混合召回和重排。当文档规模扩大后，单一向量召回通常不够。加入关键词、元数据、查询改写、reranker 和去重。此时要重点观察召回覆盖和重排质量，而不是只看最终答案。检索质量提升后，生成模型往往不需要盲目变大。 第四阶段，加权限、版本和新鲜度。只要进入企业生产，这三件事就不能拖。权限错误是安全问题，版本错误是可信问题，新鲜度错误是业务问题。索引系统要和文档系统或业务系统建立同步，不要依赖人工偶尔重建。 第五阶段，加高风险保护。对涉及钱、合同、合规、人事、医疗、法律的问题，系统应该提高证据阈值，给出限制说明，必要时要求人工复核。RAG 可以大幅提高效率，但不应把高风险判断伪装成全自动权威结论。 走完这些阶段，RAG 才更接近生产级能力。它不再是一个“接上向量库的大模型”，而是一个围绕证据、版本、权限、引用和反馈持续运行的系统。 参考资料 Patrick Lewis 等：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，https://arxiv.org/abs/2005.11401 NeurIPS 2020：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，https://papers.nips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html Nelson F. Liu 等：Lost in the Middle: How Language Models Use Long Contexts，https://arxiv.org/abs/2307.03172 Anthropic：Enhancing RAG with contextual retrieval，https://platform.claude.com/cookbook/capabilities-contextual-embeddings-guide LangChain：Text splitters，https://docs.langchain.com/oss/python/integrations/splitters/index LlamaIndex：SentenceSplitter，https://docs.llamaindex.ai/en/stable/api_reference/node_parsers/sentence_splitter/ Cohere：An Overview of Cohere's Rerank Model，https://docs.cohere.com/docs/rerank-overview Cohere：Rerank，https://cohere.com/rerank OpenAI：Retrieval API guide，https://platform.openai.com/docs/guides/retrieval

写作日期：2026-05-22 Token 成本失控通常不是因为某一次调用太贵，而是因为团队没有把输入、输出、缓存、检索、工具调用、重试和模型路由当成同一个系统来管理。账单上涨时，很多人第一反应是换便宜模型，或者要求用户少问一点。这些办法有时有用，但不是根治。真正的成本治理要能回答六个问题：哪些任务在烧钱，哪些上下文没有价值，哪些输出过长，哪些重试是无效重试，哪些缓存没有命中，哪些模型被错误使用。 对于本地 AI 和云 API 混合架构，Token 成本更容易被低估。云端模型按输入输出计费，本地模型看似不按 Token 收费，但显存、吞吐、排队、功耗、运维和机器折旧同样会被上下文长度放大。一个团队如果不治理 Token，本地部署会变慢，云 API 会变贵，RAG 会变脏，Agent 会变得不可控。成本问题不是财务问题，而是产品体验、架构设计和上下文工程问题。 一、先把账算明白 第一步不是优化，而是计量。每次模型调用都应记录任务类型、用户入口、模型、输入 Token、输出 Token、缓存命中情况、检索片段数量、工具调用次数、重试次数、响应时间、是否成功、是否被用户采纳。没有这些字段，就只能看总账单，无法知道钱花在哪里。 成本要按任务而不是按接口看。一个“问答接口”里面可能包含意图识别、查询改写、向量检索、重排、答案生成、引用整理和后置审核。如果只统计最终答案生成，就会漏掉前面的隐藏调用。一个“Agent 任务”可能包含规划、工具选择、工具执行、错误恢复、总结和复盘，任何一步失控都会把成本放大。 成本还要分输入和输出。输入贵通常来自系统提示过长、历史消息过多、RAG 召回过宽、工具说明冗余、示例堆叠、重复资料未去重。输出贵通常来自回答无长度约束、模型重复解释、一次返回过多候选、让模型写完整报告而不是结构化要点。输入和输出的治理手段不同，混在一起只会误判。 二、建立 Token 预算，而不是事后抱怨 每个任务都应有预算。客服问答可以给较小预算，因为用户需要快速明确的答案；研究报告可以给较大预算，因为需要多轮检索和长输出；代码审查可以按文件规模动态分配；Agent 自动执行任务则要设置总预算和单步预算。预算不是死板限制，而是让系统知道什么时候应该压缩、降级、澄清或停止。 预算应拆成几部分：系统提示预算、用户输入预算、历史消息预算、检索资料预算、工具结果预算、模型输出预算。很多团队只限制最终输入总长度，结果最先被挤掉的是用户问题或关键资料。更好的做法是给每类上下文设上限，超过上限时按优先级裁剪。 预算还要和价值挂钩。高价值用户、高风险任务、高复杂任务可以使用更强模型和更长上下文；低价值噪声、重复问题、简单分类、格式转换不应占用旗舰模型。成本治理不是平均削减，而是把预算给真正需要推理能力的地方。 三、缓存：最容易被忽略的降本杠杆 缓存有两类。一类是应用层缓存，例如相同问题、相同文档摘要、相同检索结果、相同工具查询结果可以复用。另一类是模型供应商提供的 Prompt 或上下文缓存，例如稳定系统提示、稳定工具说明、稳定文档块在多次请求中复用时，可以降低成本或延迟。不同供应商能力不同，但共同原则是：稳定前缀越稳定，缓存越有效。 很多缓存命中率低，不是供应商能力差，而是团队把易变内容放在前面。时间戳、请求 ID、用户昵称、临时状态、随机排序资料、动态工具列表如果放在系统提示前部，会破坏稳定前缀。模板应把稳定指令、工具协议、输出规范放前面，把用户变量、检索片段、临时上下文放后面。这样既利于供应商缓存，也利于本地应用缓存。 应用层缓存要谨慎处理权限。知识库问答不能把 A 用户可见的答案缓存给 B 用户。缓存键必须包含租户、权限范围、知识库版本、模型版本、模板版本和关键输入。缓存结果也要设置过期策略。政策、价格、库存、模型版本、接口限制这类信息变化快，缓存时间要短；固定手册、历史规范、公共说明可以缓存更久。 缓存不只缓存最终答案。RAG 场景中，查询改写结果、嵌入向量、召回文档、重排结果、文档摘要都可以缓存。Agent 场景中，工具 schema、常用计划片段、权限检查结果、只读查询结果也可以缓存。不要只盯着最后一次生成调用。 四、压缩上下文：删掉无价值内容 上下文压缩不是把所有内容粗暴摘要，而是保留决策所需信息，删除噪声。一个十页文档未必比十条结构化事实更有价值。压缩应该先识别任务目标：用户要结论、证据、步骤、对比、代码修改，还是风险判断。不同目标需要不同信息。 对话历史要按状态压缩。早期闲聊、已解决问题、重复澄清、失败尝试不应长期占据上下文。可以维护一个会话状态摘要：用户目标、已确认约束、已做操作、未解决问题、重要偏好、禁止事项。新一轮调用优先使用状态摘要，而不是把全部历史原文塞进去。 RAG 资料要按证据压缩。不要把整段文档原文都塞给模型。可以先抽取与问题相关的段落、表格行、代码片段和来源元数据，再交给模型。若需要可解释性，保留引用和原文位置，而不是保留所有上下文。重排模型和引用生成比盲目增加 TopK 更能控制成本。 工具结果也要压缩。数据库查询、网页抓取、日志分析、代码搜索常返回大量结果。工具应返回结构化摘要、关键字段、异常项和可追溯 ID，而不是把全量 JSON 或日志直接扔给模型。模型需要的是可判断的信息，不是原始系统噪声。 五、路由：别让旗舰模型干所有活 模型路由是成本治理的核心。任务可以分层：简单分类、语言检测、字段抽取、格式转换、标题生成可以用便宜模型或本地模型；复杂推理、长上下文综合、代码修改、高风险决策使用强模型；需要隐私的数据留本地或私有部署；需要最新能力和强工具调用的任务走云端。 路由不能只按用户入口固定。一个入口里既有简单问题，也有复杂问题。应先做轻量意图识别，判断任务类型、风险等级、上下文长度、是否需要工具、是否需要引用、是否涉及隐私，再选择模型。路由失败时要能升级，例如便宜模型置信度低、输出校验失败、用户追问复杂化，就转强模型。 降级策略也要设计。供应商不可用时，可以切换同级模型、缩短上下文、关闭非必要多轮工具、返回需要人工确认的草稿，而不是无限重试。无限重试会把故障变成成本事故。重试必须带原因和上限：网络错误、限流、格式错误、工具超时、模型拒答分别处理。 六、任务拆解：减少一次性巨型调用 很多成本来自“一次性让模型做完所有事”。例如让模型读十篇资料、判断真假、写报告、给引用、生成表格、提出行动计划。这样的调用输入长、输出长、失败难定位。拆解后可以先检索，再抽取事实，再生成大纲，再写正文，再做事实检查。每一步都有较小上下文和明确验收。 拆解不是越细越好。过度拆解会增加调用次数和编排成本。合理拆解的原则是：每一步有明确输入输出；中间结果可复用；失败能单独重试；便宜模型能完成部分步骤；强模型只处理高价值综合任务。若拆解后每一步都用旗舰模型，成本未必下降。 任务拆解还可以减少返工。让模型先生成计划，用户确认后再执行，比直接生成长报告更省。让模型先列缺失信息，补齐后再分析，比带着不确定性写长文更省。让 Agent 每步产出工件和证据，比最后才发现方向错更省。 七、输出治理：长不等于好 输出 Token 失控很常见。用户问一个简单问题，模型回答背景、原理、步骤、注意事项、FAQ、总结；用户要列表，模型写长文；用户要结论，模型先铺垫。解决办法不是简单限制字数，而是让输出结构匹配任务。 可以给每类任务定义输出预算。故障排查先给三步行动；选型问题先给结论表；法律或医疗类高风险问题给边界和建议咨询专业人士；研究报告给摘要、证据和附录。正文很长时，把详细资料放在用户请求后再生成，而不是默认展开。 流式输出也不能替代输出治理。流式只能让用户更早看到内容，不能减少账单。真正减少输出成本，要在提示词、产品交互和后处理上控制长度。给用户“展开细节”“生成完整报告”“显示引用”这样的操作，比每次默认生成所有内容更合理。 八、RAG 成本：召回越多不一定越准 RAG 系统常把 TopK 调大来追求召回，结果成本上升、答案反而更差。过多片段会带来冲突、重复和噪声。正确做法是提升检索质量：更好的切分、更合适的嵌入模型、混合检索、重排、元数据过滤、权限过滤、文档新鲜度管理。把垃圾片段塞进上下文，是最贵的偷懒。 RAG 还要避免重复片段。同一段资料可能来自 PDF、网页、同步文档和历史备份，向量库里重复存在。召回后如果不做去重，模型会看到重复证据，以为它更重要。数据去重、段落指纹、来源优先级和版本字段都能降低无效 Token。 引用也会增加成本，但不能随便砍掉。对知识库问答，引用是信任来源。可以让模型只引用关键证据，而不是引用所有召回片段；可以把引用元数据结构化，减少自然语言解释；可以把完整引用列表放到可展开区域。目标是保留可验证性，同时减少冗余。 九、Agent 成本：限制步数和工具 Agent 比普通聊天更容易烧钱，因为它会规划、调用工具、观察结果、再规划。每一步都可能消耗输入输出 Token。如果工具返回大段内容，下一步又把全部观察塞回上下文，成本会指数增长。Agent 必须有步数上限、预算上限、工具结果压缩、失败停止条件和人工确认点。 工具选择要有权限和代价意识。只读查询可以自动执行，写操作、付费调用、批量任务和外部发布要确认。昂贵工具要先说明为什么需要。工具返回要结构化，避免把长日志原样送回模型。Agent 的记忆也要分层，短期状态、长期偏好、任务工件和外部知识库不要混成一个长上下文。 Agent 还需要验收闭环。没有验收，模型会继续“再检查一下”“再优化一下”，直到预算耗尽。任务开始前就要定义完成标准：生成文件、通过测试、给出引用、获得用户确认、完成工具动作。达到标准就停止，不要让 Agent 用更多 Token 追求虚假的完美。 十、监控指标：看见浪费发生在哪里 Token 成本监控至少包括输入 Token、输出 Token、缓存命中率、模型分布、任务分布、用户分布、重试率、失败率、平均延迟、P95 延迟、单任务成本、单成功任务成本。单成功任务成本很重要，因为失败调用也花钱。如果某个流程失败率高，降价模型也救不了。 还要监控上下文利用率。输入很长但答案没有引用其中大部分资料，说明检索或拼接有浪费。输出很长但用户很快追问“所以结论是什么”，说明表达浪费。重试很多但最终仍失败，说明错误恢复策略浪费。工具调用很多但没有改变答案，说明工具策略浪费。 监控不能只给工程看。产品要知道哪些入口成本最高，运营要知道哪些内容导致重复问题，财务要知道预算趋势，安全要知道高风险任务是否降级到了不该用的模型。成本治理是跨团队工作。 十一、组织流程：建立成本评审 每次新增 AI 功能，都应该有成本评审。评审不需要复杂，但要回答：预计每次任务调用几次模型，平均输入输出多少 Token，使用哪些模型，是否启用缓存，是否有重试上限，是否有降级路径，是否有成本告警，是否能按用户或租户限额。 每次模型升级，也要重新估算成本。新模型价格、上下文长度、输出习惯、工具调用能力、缓存规则都可能变化。更强模型不一定更贵，如果它能减少重试、减少工具调用、缩短提示词，反而可能降低总成本。反过来，便宜模型如果失败率高，最终也可能更贵。 每次知识库扩容，也要评估召回成本。文档越多，检索、重排和上下文拼接越容易失控。新增资料不只是上传文件，还要考虑元数据、版本、权限、去重和过期策略。否则知识库越大，Token 浪费越严重。 十二、一个可执行的降本顺序 第一步，开日志。记录每个任务的 Token、模型、缓存、重试、延迟、成功状态。没有计量，不做优化承诺。 第二步，找 Top 20 消耗任务。不要平均优化，先处理成本最高或增长最快的入口。 第三步，拆输入。把系统提示、历史、检索、工具结果、用户输入分开看，找最长且价值最低的部分。 第四步，控输出。为常见任务设置默认长度和展开机制，避免每次生成长报告。 第五步，做缓存。先缓存稳定系统提示、文档摘要、检索结果和常见问答，再考虑复杂语义缓存。 第六步，做路由。把简单任务迁到便宜模型或本地模型，复杂任务保留强模型，失败时自动升级。 第七步，做评测。确认降本没有明显伤害质量，尤其是引用准确性、工具调用正确性和用户满意度。 第八步，设预算和告警。按任务、用户、租户、模型设上限，异常增长及时提醒。 十三、把预算写进产品契约 Token 预算不能只存在工程配置里，也要进入产品契约。一个功能如果对用户承诺“生成完整行业报告”，就必须有足够预算；如果只是“快速回答资料库问题”，就不应该默认生成几千字长文。产品文案、交互按钮和模型预算要一致。否则用户点的是一个轻量按钮，后台却跑了重型工作流，成本迟早失控。 产品契约应该明确默认行为和展开行为。默认回答可以短，包含结论、依据和下一步；用户需要更多细节时，再触发展开。默认只回答当前问题，不默认附带背景科普；默认只引用关键资料，不默认列出所有召回片段；默认只执行必要工具，不默认做完整研究。这样做不是降低质量，而是把质量放在用户真正需要的地方。 预算也要体现在套餐和权限里。免费用户、试用用户、内部高频脚本、生产客户、管理员任务，不应共享同一套无限预算。没有租户级预算，某个自动化脚本就可能把公共额度打穿。没有用户级预算，少数高频用户会影响整体体验。没有任务级预算，复杂 Agent 会吞掉普通问答的资源。 社区服务尤其要注意滥用。开放社区里，用户可能粘贴整本书、整份日志、整段代码库，要求模型总结。系统应在上传、粘贴、检索和生成前给出明确边界：当前任务最多处理多少内容，超出后建议上传资料库、分段处理或改用异步任务。把限制说清楚，比悄悄截断更可靠。 十四、缓存命中率要能解释 很多团队说自己做了缓存，但说不清为什么命中率低。缓存命中率不是一个单独指标，它受模板结构、变量位置、资料版本、权限范围和用户行为影响。只看“命中百分比”没有用，必须能解释命中和未命中的原因。 可以把未命中分成几类：稳定前缀变化、用户变量变化、知识库版本变化、权限范围变化、模型版本变化、工具 schema 变化、缓存过期、缓存主动失效。每类原因对应不同处理。稳定前缀频繁变化，说明模板管理混乱；权限范围导致未命中，可能是必要安全成本；模型版本变化导致未命中，说明发布流程需要预热缓存；知识库版本频繁变化，说明资料同步策略可能过于粗糙。 缓存预热也有价值。对于高频入口，发布新模板或新模型后，可以先用核心样本预热稳定前缀和常用资料摘要。对企业内部知识库，热门手册、政策、产品介绍、故障处理流程可以定期生成摘要缓存。对代码库助手，仓库结构、模块说明和常见命令可以在索引阶段准备好。预热不是为了造假命中率，而是减少用户请求时的重复成本。 缓存失效要有规则。资料更新后，旧摘要不能长期使用；模型升级后，旧输出缓存可能不再符合质量标准；权限变更后，旧答案不能继续给离职或降权用户。缓存越强，失效越重要。成本治理不能牺牲权限和新鲜度。 十五、RAG 限额要从资料治理开始 RAG 成本失控经常被误认为是模型问题，其实根因在资料治理。文档没有版本，重复上传；PDF 解析质量差，切分混乱；网页同步带来导航栏和页脚噪声；表格被拆散，关键字段丢失；过期资料没有下架；权限元数据缺失。这些问题会让召回变多、重排变贵、上下文变脏。 资料进入知识库前就要做成本意识处理。解析阶段去掉目录噪声、页眉页脚、重复版权声明和空表格；切分阶段控制块大小和重叠比例；去重阶段用指纹识别近似重复；元数据阶段标明来源、版本、时间、权限、业务域和可信等级；同步阶段只增量更新变化内容，而不是每次全量重建。前面多做一分治理，后面少花很多 Token。 召回限额也要分任务。事实问答需要少量高精度片段；政策对比需要覆盖多个版本；故障排查需要日志、配置和手册同时参与；研究报告需要更宽召回但可以异步执行。不要用同一个 TopK 服务所有任务。可以先用小召回回答，如果置信度低或证据不足，再扩大召回。逐步扩大比默认大召回更省。 重排模型也要有预算。重排不是免费午餐，候选越多越贵。可以用元数据先过滤，再做向量召回，再做稀疏检索补充，最后只对候选集合重排。对于简单问题，甚至可以跳过重排；对于高风险答案，重排和引用校验必须保留。成本治理的目标不是砍功能，而是让功能按风险和价值启用。 十六、Agent 要有熔断，不然会自我放大 Agent 成本最危险的地方是自我放大。一次工具失败会引发重试，重试后模型尝试换工具，换工具后返回更多日志，日志又进入下一轮上下文，模型再解释日志，最后一个小问题变成几十次调用。没有熔断机制，Agent 会把不确定性转换成账单。 熔断条件要明确。连续两次同类工具失败就停止，要求人工确认；同一工具参数变化不大却反复调用，就停止；累计 Token 超过任务预算，就输出当前状态和建议；模型无法给出下一步理由，就停止；遇到写操作、付款、删除、发布和外部通知，必须确认。熔断不是失败，而是生产系统的安全边界。 Agent 还要区分探索和执行。探索阶段可以多查资料，但不能改外部状态；执行阶段必须按计划做少量高确定性动作；验证阶段只检查结果，不重新发散。很多成本事故来自探索和执行混在一起，模型一边想一边改，一边改一边查，最后既贵又危险。 任务记忆也要节制。Agent 不应该把所有观察永久带入上下文。每一步结束后，保留状态摘要、关键证据、已执行动作、失败原因和下一步候选即可。原始日志和工具返回放到外部工件里，通过 ID 引用。需要时再读取，不需要时不要占上下文。 十七、把重试当成成本中心 重试常被隐藏在 SDK 或网关里，最终账单却由它放大。一次用户请求看起来只有一次生成，实际上可能因为超时、限流、格式错误、网络波动、工具异常和安全拒答重试了多次。如果没有把重试次数写入日志，团队会误以为模型本身贵，而不是重试策略贵。 重试要分类型。网络错误可以短延迟重试；限流需要退避或换供应商；格式错误可以要求模型修复一次，但不能无限修复；工具错误应先检查工具参数和服务状态；安全拒答不应通过换说法反复绕过；用户输入缺失应澄清，而不是让模型猜。所有重试都要有上限和原因。 重试还要保留上下文差异。格式修复时，不需要把完整资料再次发送，可以只发送原输出、错误信息和目标 schema。工具重试时，不需要重新规划完整任务，可以只重试失败工具。供应商切换时，要注意模型差异，不能把同一长上下文盲目复制给另一个模型。精细重试比整条链路重跑便宜得多。 十八、本地模型不是免费模型 社区里常有人说“用本地模型就没有 Token 成本”。这句话只对账单表面成立。实际上，本地模型的成本体现在吞吐、延迟、显存、机器、电力、散热、维护、模型更新、量化质量和服务稳定性。长上下文会占用更多 KV Cache，降低并发；大输出会占用生成时间，拉长队列；错误路由会让本来能用小模型处理的任务占满大模型服务。 本地推理也需要 Token 预算。每个任务消耗多少输入输出，平均生成速度是多少，P95 等待多久，队列长度多少，显存占用多少，都要监控。没有这些指标，本地服务会从“省钱”变成“慢而不可用”。如果用户等待时间太长，最终还是会切回云模型，形成双重成本。 本地模型更适合做稳定、可控、隐私敏感或高频简单任务。比如分类、摘要初稿、日志初筛、嵌入、轻量问答、格式转换、离线批处理。复杂推理、强多模态、长上下文综合、严格工具调用仍可能需要云模型。混合架构要让本地模型承担合适工作，而不是为了省钱把所有任务都压到本地。 十九、成本优化必须做质量回归 降本最怕降质量。缓存可能返回过期答案，压缩可能删掉关键证据，路由可能把复杂任务发给弱模型，拆解可能丢失全局目标，输出限制可能让答案不完整。每次降本改动都要跑回归评测，确认关键路径没有退化。 评测集要覆盖高频问题、高价值客户问题、高风险问题、长上下文问题、工具调用问题、RAG 引用问题和历史事故样本。指标不能只看模型评分，还要看引用是否正确、工具是否正确、是否需要人工补救、是否节省真实成本。一个方案如果省了百分之三十 Token，却让人工处理增加一倍，实际并不省。 质量回归还要看用户体验。更短答案未必更差，但如果用户需要连续追问三次才能得到完整信息，整体成本可能更高。更便宜模型未必更差，但如果用户满意度下降或投诉上升，长期价值会受损。成本优化必须和体验指标一起看。 二十、团队落地模板 可以给每个 AI 功能建立一张成本卡： 功能名称： 用户入口： 任务类型： 默认模型： 备用模型： 本地模型是否可用： 平均输入 Token： 平均输出 Token： P95 延迟： 缓存策略： RAG TopK： 重排策略： 最大工具步数： 最大重试次数： 单任务预算： 超过预算处理： 质量回归集： 负责人： 这张卡不是一次性文档，而是上线后持续更新。每次模型换代、价格变化、知识库扩容、提示词改版、工具变化，都要更新成本卡。团队讨论成本时，不再凭感觉说“太贵”或“还好”，而是看每个入口的真实数据。 还可以建立月度成本复盘。看哪些任务增长最快，哪些缓存命中下降，哪些用户触发异常消耗，哪些失败重试最多，哪些模型路由不合理。复盘结论要变成具体改动：调预算、改模板、做缓存、拆任务、优化检索、增加告警、修改套餐。成本治理只有进入固定节奏，才不会等到账单爆炸才处理。 二十一、三个常见成本事故 第一个事故是长提示词模板失控。团队最初只有一段简短系统提示，后来为了修复格式问题、安全问题、语气问题、工具问题、引用问题，不断往里面加说明。半年后，一个普通客服问答的系统提示已经超过用户问题几十倍。每次调用都带着大量低价值历史补丁，缓存又因为模板频繁改动而命中很低。解决这类事故，不是继续追加规则，而是重构模板：拆出稳定系统前缀，拆出任务模板，拆出输出 schema，删掉已经被结构化输出和后处理覆盖的自然语言约束。 第二个事故是知识库召回失控。某团队把所有文档都同步进向量库，默认 TopK 从五调到二十，又为了“提高准确率”把每个片段重叠设置很大。结果一次问答带入大量重复段落，模型开始在冲突资料中摇摆，答案变长，引用变乱，账单也上涨。正确修复是先治理资料：按版本去重，过滤页眉页脚，给资料加业务域和有效期，按问题类型动态选择 TopK，再用重排模型控制进入上下文的证据数量。 第三个事故是 Agent 自动重试失控。一个浏览器代理在网页加载失败后反复刷新，又把每次失败截图和错误日志写进上下文，最后一个简单表单任务消耗大量 Token。修复方式是建立熔断：同一页面连续失败两次就停止；截图只保留最新关键状态；错误日志只保留摘要；超过预算后向用户说明当前卡点，而不是继续试。Agent 不是越坚持越好，生产系统要知道什么时候停止。 二十二、指标阈值可以从粗到细 刚开始做成本治理，不必追求完美指标。可以先设粗阈值：单次普通问答输入不超过某个预算，输出不超过某个预算，重试不超过一次，RAG 进入生成的片段不超过固定数量，Agent 工具步数不超过固定上限。粗阈值能先挡住明显浪费。 第二阶段再做动态阈值。根据任务类型、用户等级、知识库规模、模型能力、历史成功率自动调整预算。复杂研究任务可以申请更大预算，普通问答保持短路径；高风险任务保留强模型和引用，低风险格式转换走便宜模型；命中缓存的任务允许更快返回，缓存未命中的任务走完整链路。 第三阶段要做异常检测。某个入口 Token 突然上涨，可能是新模板过长；某个用户成本突然上涨，可能是自动脚本或滥用；某个模型输出突然变长，可能是模型版本或系统提示变化；某个知识库调用变贵，可能是资料同步重复。异常检测不是为了惩罚用户，而是让团队在账单爆炸前发现问题。 指标还要看趋势。单日成本高不一定是坏事，可能是正常活动；单任务成本缓慢上涨更危险，说明系统在被复杂度侵蚀。每次功能上线、模型切换、知识库扩容、模板改版后，都要观察一段时间，确认成本曲线是否按预期变化。 二十三、混合架构的分工建议 本地模型、私有模型和云 API 不应该互相替代，而应该分工。高频、低风险、隐私敏感、格式稳定的任务适合本地：分类、摘要初稿、日志初筛、嵌入生成、简单问答、批量离线处理。需要强推理、强多模态、最新模型能力、复杂工具调用和高质量长文生成的任务，可以走云端。中间层用统一网关做路由、审计、限额和回退。 混合架构要避免重复推理。同一个请求不要先本地跑一遍、再云端完整跑一遍，除非这是明确的级联策略。更好的方式是本地做预处理和压缩，云端做关键推理；或者本地先给低成本答案，置信度不足再升级云端。升级时应携带压缩后的状态，而不是把原始长上下文复制过去。 本地部署还要看并发。一个模型在单用户测试时很快，不代表生产可用。上下文越长，KV Cache 占用越大，并发越低。团队应测不同上下文长度下的吞吐和延迟，把本地模型的“隐形 Token 成本”换算成排队时间、机器成本和用户体验。只有这样，才知道哪些任务应该本地跑，哪些任务应该交给云端。 二十四、提示词和工具说明也要瘦身 很多系统提示里有大量重复内容：一遍说明角色，一遍说明输出格式，一遍说明安全边界，一遍说明不要泄露内部信息，又在每个工具说明里重复相同要求。模型并不会因为重复十遍就稳定十倍。重复说明会占用上下文，还可能造成歧义。模板瘦身应删除重复、合并相近规则，把机器可校验的约束交给 schema 和后处理。 工具说明要写给模型使用，不是写给人看。好的工具说明包含工具能做什么、何时使用、必填参数、错误处理和限制；坏的工具说明包含一大段背景故事、内部实现、无关字段和自然语言示例。工具越多，说明越要短。对于不常用工具，可以在路由阶段按需注入，而不是每次把全部工具表塞进上下文。 示例也要控制。Few-shot 示例有价值，但示例太多会让模型模仿不该模仿的细节。示例应覆盖边界和格式，而不是堆数量。模型升级后，旧示例可能不再必要；结构化输出上线后，格式示例也可以减少。每个示例都应能解释它保留的原因，否则就是成本负担。 二十五、从用户体验看成本 成本治理最终会体现在用户体验里。一个回答短但清楚，用户满意，成本低；一个回答长但混乱，用户继续追问，成本高；一个 Agent 自动跑十步但没完成，用户失望，成本高；一个系统先澄清关键条件再执行，虽然多一次交互，却避免长任务返工，实际更省。 产品设计可以主动帮助降本。让用户选择“快速回答”“详细解释”“生成报告”；让用户在上传大文件前选择目标；让用户确认是否需要联网检索；让用户选择引用数量；让用户把大任务保存为异步作业。这些交互不是把成本负担甩给用户，而是让用户用明确意图换取更合适的模型行为。 也不要为了降本破坏信任。不能偷偷截断关键资料后假装读完，不能用弱模型处理高风险问题却不做校验，不能为了省输出 Token 删除必要引用，不能为了命中缓存返回过期答案。生产级降本必须透明、可控、可回滚。 二十六、给小团队的第一周行动 第一天，给所有模型调用加统一日志，至少记录任务名、模型、输入输出 Token、延迟、成功状态。第二天，按任务汇总成本，找出最贵的五个入口。第三天，检查这五个入口的系统提示、历史消息、RAG 片段和输出长度。第四天，给它们设置预算和输出结构。第五天，给高频稳定内容加缓存。第六天，引入简单路由，把分类、摘要、格式转换等任务迁到便宜模型或本地模型。第七天，跑一批真实样本，确认质量没有明显下降。 第一周不要试图搭建完美成本平台，也不要先做复杂仪表盘。先把最粗的浪费挡住：重复上下文、过长输出、无限重试、过宽召回、旗舰模型滥用。很多团队做到这一步，成本就会明显下降，系统也更容易解释。 第二周再做工程化：把预算写进配置，把模型路由放进网关，把缓存键纳入权限和版本，把失败样本进入评测，把异常成本接入告警。第三周再做组织化：建立月度复盘，给每个 AI 功能建立成本卡，让产品、工程、运营和财务都能看懂成本从哪里来。 二十七、不要优化错对象 成本治理还有一个陷阱：只优化单次模型调用价格，不优化完整任务成本。一个便宜模型如果需要更长提示词、更多示例、更多重试和更多人工返工，最终可能比强模型更贵。一个强模型如果能一次完成、少调用工具、少产生错误、少占用人工，整体反而更省。选模型时要比较“成功完成一次任务”的总成本，而不是只比较百万 Token 单价。 也不要只优化机器成本，忽略人的时间。为了省一点 Token 让答案变短，如果用户需要反复追问，客服需要二次解释，工程需要手工修复，成本只是从账单转移到了人。生产级 AI 系统的目标是总成本可控，包括模型、机器、等待时间、人工处理和用户信任。 最后，不要用成本治理掩盖产品边界不清。用户真正需要的是明确结果，而不是无限对话。很多 Token 浪费来自产品没有让用户选择目标、范围和深度。把入口设计清楚，把任务拆小，把默认输出做准，比在底层反复压缩更有效。 结论 Token 成本失控不是一个参数能解决的问题。它来自上下文工程、产品交互、模型路由、RAG 数据、Agent 编排、缓存策略和组织流程共同失衡。真正有效的治理，不是让模型少说一点，而是让系统只把有价值的信息交给合适的模型，在合适的步骤生成合适长度的结果。 如果团队只能做一件事，就先建立调用级成本日志；如果能做两件事，再把任务预算和缓存做好；如果要做成生产级能力，就把路由、压缩、评测、告警和回滚纳入同一套工程流程。成本可控，AI 应用才有可能长期运行，而不是演示时很强、上线后太贵。 参考资料 OpenAI，Prompt caching： https://platform.openai.com/docs/guides/prompt-caching OpenAI，API pricing： https://openai.com/api/pricing/ Anthropic，Prompt caching： https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching Anthropic，Pricing： https://www.anthropic.com/pricing Google Cloud Vertex AI，Context cache overview： https://cloud.google.com/vertex-ai/generative-ai/docs/context-cache/context-cache-overview Google AI for Developers，Gemini API pricing： https://ai.google.dev/gemini-api/docs/pricing LangChain，How to track token usage： https://python.langchain.com/docs/how_to/llm_token_usage_tracking/ LangSmith，Trace LLM applications： https://docs.smith.langchain.com/observability/how_to_guides/trace_llm_applications LlamaIndex，Cost analysis： https://docs.llamaindex.ai/en/stable/module_guides/observability/cost_analysis/ Microsoft Azure OpenAI，Plan and manage costs： https://learn.microsoft.com/en-us/azure/ai-services/openai/how-to/manage-costs AWS Well-Architected，Cost optimization pillar： https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html Google Cloud Architecture Center，Cost optimization： https://cloud.google.com/architecture/framework/cost-optimization

开源大模型这两年的更新速度，已经快到让很多团队疲惫。今天有人说 Qwen 新版推理更强，明天有人说 DeepSeek 新版代码能力更好，后天又有 Gemma、Mistral、Llama、Yi、InternLM、GLM、Phi、EXAONE、Nemo、Nous、OpenThinker、各种蒸馏版和量化版刷屏。模型卡片越看越多，排行榜越看越乱，本地模型目录越来越大，真正上线的业务却未必更稳定。 追新疲劳不是因为开源模型不好，而是因为模型更新速度超过了团队建立评测、迁移和上下文工程的速度。模型越来越强是事实。Stanford HAI 的 2026 AI Index 已经把开放模型和闭源模型之间的差距写得很清楚：顶级模型差距在很多时间点已经变成个位数百分比的竞争，开放生态也越来越接近前沿能力。但对一个正在做产品的人来说，“新模型更强”不等于“我的系统应该今天就换”。业务系统的问题，很多时候并不是模型太旧，而是上下文太脏、检索太差、提示词太长、工具结果不可验证、会话历史无边界、评测集不存在。 这篇文章讨论一个很现实的问题：什么时候该换模型，什么时候该优化上下文。这里的“上下文”不只是 prompt，而是模型调用前后所有会影响答案的信息环境，包括系统指令、用户问题、历史对话、检索片段、工具结果、文件内容、业务规则、输出格式、缓存策略、路由策略和失败恢复。一个好模型放进坏上下文里，会显得迟钝、幻觉、啰嗦、成本高；一个普通模型放进清晰上下文里，可能已经足够稳定地完成任务。 一、追新疲劳从哪里来 第一种疲劳来自模型发布节奏。Meta 在 Llama 3.1 中把上下文扩展到 128K，并发布 405B 级别开放权重模型；DeepSeek-R1 用强化学习后训练和蒸馏模型把推理能力推到大众视野；Google Gemma 3 强调单加速器可运行、视觉能力、多语言和 128K 上下文；Qwen3 同时发布 MoE 和 dense 系列，引入思考与非思考模式；Mistral Small 3.1 用 Apache 2.0 许可、128K 上下文和多模态能力争夺小模型场景。每一波发布都像一次提醒：你现在用的模型可能落后了。 第二种疲劳来自排行榜。不同榜单测不同东西：有的偏聊天偏好，有的偏数学，有的偏代码，有的偏长上下文检索，有的偏多模态，有的偏工具调用。一个模型在 Arena 上讨喜，不一定在企业知识库问答里引用准确；一个模型在数学题上强，不一定适合客服语气；一个模型在英文代码补全上好，不一定在中文制度文件问答里稳。排行榜有价值，但它不是你的业务验收表。 第三种疲劳来自模型包装。基础版、指令版、思考版、非思考版、代码版、数学版、蒸馏版、AWQ、GPTQ、GGUF、FP8、INT4、8B、14B、32B、70B、MoE A3B、MoE A22B，每个名字看起来都像新机会。实际上，很多版本之间的差异只对特定硬件、特定任务或特定部署方式有意义。没有清晰任务的人，会被模型名称推着走。 第四种疲劳来自迁移成本被低估。换模型不是改一行模型名。Tokenizer 可能变，chat template 可能变，工具调用格式可能变，最大上下文可能变，默认采样参数可能变，安全拒答风格可能变，量化质量可能变，显存占用可能变，输出长度可能变。上层应用如果没有评测和灰度，一次追新可能把原本稳定的功能弄坏。 第五种疲劳来自“上下文债”。系统提示词越写越长，历史对话越塞越多，RAG 检索片段越堆越满，工具返回原始 JSON，业务规则复制多遍，错误时再加一句补丁，最后模型输入变成一团噪声。团队以为模型不够聪明，其实模型每天都在读重复、冲突、过期、无排序的信息。换模型可以暂时缓解，但上下文债会继续累积。 二、先承认一个事实：新模型确实经常有价值 反对盲目追新，不等于否认模型进步。开源模型更新快，是生态繁荣的表现。Llama 3.1 把开放权重模型推向更大规模和更长上下文；DeepSeek-R1 让很多团队第一次认真评估开放推理模型；Gemma 3 和 Mistral Small 3.1 让单机和边缘场景有了更多选择；Qwen3 在不同尺寸、MoE、思考模式和长上下文之间提供了细分组合。这些进步会真实改变成本曲线和产品可能性。 换模型在一些场景里非常应该做。比如旧模型不会稳定使用工具，新模型对函数调用和结构化输出明显更好；旧模型中文理解弱，新模型在中文、代码混合、长文档问答上明显提升；旧模型上下文只有 8K，新业务必须处理几十页材料；旧模型许可限制影响商用，新模型许可证更清晰；旧模型部署成本高，新模型同等质量下尺寸更小；旧模型对安全边界处理差，新模型有更好的拒答和合规能力。 模型更新还可能带来架构层面的机会。一个更强的小模型，可能让你把原本依赖大模型的高频任务下沉到本地；一个更好的长上下文模型，可能减少部分粗糙检索拼接；一个原生支持视觉的开放模型，可能让文档截图、票据、白板和界面分析进入本地系统；一个推理模型，可能让复杂规划、数学推导和代码修复更可靠。拒绝一切新模型，会错过这些机会。 问题在于，模型价值必须落到你的任务上。新模型发布时的官方 benchmark 只是候选信号，不是上线理由。你要问的是：它能否在我的数据、我的语言、我的工具、我的错误边界、我的延迟目标和我的成本预算里，稳定超过当前方案。答案如果没有通过评测证明，就只是期待。 三、很多“模型不行”，其实是上下文不行 上下文问题往往比模型问题更隐蔽。用户问一个问题，系统把十几段检索结果、五轮历史对话、系统角色、格式要求、业务规则、工具说明和一堆元数据都塞给模型。最后模型答错，团队第一反应是换更大模型。但如果相关事实在第九段，前面八段都是相似废话；如果业务规则前后冲突；如果历史对话里保留了用户早已修正的错误；如果检索片段没有来源、时间和优先级，再强的模型也很难稳定。 Lost in the Middle 论文提醒我们，长上下文模型并不总能均匀使用输入中的所有信息。相关信息出现在开头或结尾时，模型表现通常更好；出现在中间时，表现可能下降。RULER 进一步讨论“标称上下文长度”和“真实可用上下文能力”之间的差异。也就是说，把内容塞满上下文窗口，不等于模型已经有效阅读了全部内容。 RAG 也是同样道理。RAG 的初衷是把参数化记忆和外部检索结合，让模型在知识密集任务中使用可更新资料。可是很多系统把 RAG 做成“搜索到什么就塞什么”。检索召回不准，重排没有做，片段太碎，引用缺失，重复内容太多，时间版本混乱，模型自然会幻觉或答非所问。此时换模型可能让语气更自然，但引用错误未必消失。 上下文不行还包括输出约束不清。很多业务要求模型输出 JSON、表格、分类标签、操作计划或审批意见，却只在 prompt 末尾写一句“请按格式输出”。模型面对复杂内容时，格式错误率高，不一定是基础能力不足，而是 schema 没有明确、示例不一致、字段含义重叠、错误恢复缺失。换模型之前，先把输出合同设计好。 会话历史也是常见污染源。多轮对话中，早期需求、后续修正、用户临时假设、模型曾经答错的内容都会留下。如果系统每轮简单拼接完整历史，模型会把过期信息和最新意图混在一起。很多“模型不听话”的现象，是因为上下文里同时存在旧指令和新指令。更好的做法是维护会话状态、摘要、用户确认事项和待解决问题，而不是无限追加原文。 工具结果同样需要整理。Agent 调用搜索、数据库、文件系统、代码执行或业务 API 后，工具返回的信息常常是机器格式。模型不该直接面对巨大原始 JSON、堆满内部字段的日志或无解释的错误栈。工具层应该把结果转换成面向任务的事实、状态和可选动作。否则模型要先做数据清洗，再做判断，错误空间会变大。 四、该换模型的信号 第一个明确信号是能力边界卡住。你已经清理了上下文、改善了检索、减少了冲突、给了足够示例，模型仍然在核心任务上持续失败。比如数学推理总是断，代码修改总是不理解跨文件关系，中文制度问答总是错读否定条件，复杂工具调用总是漏步骤。此时问题可能确实在模型能力。 第二个信号是任务类型发生变化。原来只是闲聊问答，现在要做合同审阅、代码修复、长文档比较、图片理解、规划执行或多工具 Agent。任务升级后，旧模型可能不具备对应能力。不要指望 prompt 把一个不会看图的模型变成视觉模型，也不要指望上下文技巧让弱推理模型稳定解决高难数学。 第三个信号是上下文窗口成为硬限制。经过裁剪、检索、摘要和分块后，仍然需要模型同时看到大量原文，旧模型窗口不够，或者窗口够但有效使用能力差。此时可以评估长上下文模型。但要注意，长窗口只是候选条件，仍要用真实长文档任务测试中间信息、跨段引用和多证据综合。 第四个信号是成本曲线明显更优。新模型在你的评测集上质量相当或更高，同时尺寸更小、推理更快、量化更稳、上下文更长或许可证更友好。比如一个 14B 新模型在你的客服分类、知识问答和结构化抽取上超过旧 32B 模型，换模型就有现实收益。成本收益要按单位有效结果算，而不是只看模型参数量。 第五个信号是生态支持决定生产可用性。新模型被 vLLM、SGLang、llama.cpp、Ollama、TensorRT-LLM、Transformers 等主流工具稳定支持，有清晰 tokenizer、chat template、量化版本、模型卡和许可证。旧模型如果加载方式特殊、社区停止维护、推理引擎适配差，长期运维成本会越来越高。 第六个信号是安全或合规要求改变。某些业务需要更好的拒答边界、更清晰许可证、更可控部署位置、更明确的数据处理路径。如果旧模型来源不明、许可证模糊或安全行为不可接受，换模型不是追新，而是风险治理。 第七个信号是用户体验已经被模型本身限制。上下文和应用层都优化后，首 token 延迟、输出速度、答案长度控制或工具调用稳定性仍无法达标，而新模型在同硬件上明显改善。这种换模型是性能工程，不是赶潮流。 五、不该换模型，应该优化上下文的信号 第一个信号是错误集中在事实引用。模型能理解问题，语言也正常，但经常引用错文档、漏掉最新版本、把相似条款混在一起。此时优先看检索、重排、文档切分、版本标识和引用格式。换更强模型可能减少一些幻觉，但如果拿到的证据错，答案仍会错。 第二个信号是答案被无关信息带偏。相关内容明明在资料里，但模型抓了旁边更显眼的段落。这通常是上下文排序和去噪问题。把最相关证据放到更靠近问题的位置，减少重复段落，增加来源和时间，往往比换模型更有效。 第三个信号是不同轮次互相污染。用户改了需求后，模型还按旧目标执行；用户说“不要用这个方案”，模型后面又用了。先做会话状态管理和历史压缩，不要把完整对话当作永远有效的真相。 第四个信号是输出格式不稳定但内容判断正确。模型知道答案，却输出多余解释、字段缺失或 JSON 不合法。此时应该强化 schema、示例、结构化输出接口、验证器和重试策略。换模型不是第一选择。 第五个信号是 prompt 已经长到没人敢改。系统提示词里有重复规则、过时规则、互相矛盾的角色要求、多个版本的输出格式。这个时候换模型只会让旧债搬到新模型上。先删减、分层和模块化，把固定政策、任务说明、格式要求和动态上下文拆清楚。 第六个信号是长文档任务只需要少量证据。用户问的是某个条款、某个数字、某个定义，却把整本文档全塞给模型。这里应该优化检索和证据定位，而不是追更长上下文。长窗口可以兜底，但不该替代信息检索。 第七个信号是成本来自重复输入。系统提示词、工具 schema、长文档前缀和历史摘要每次都重复发送。此时优先看 prompt caching、prefix caching、固定前缀稳定化和会话缓存。OpenAI、Gemini 和 vLLM 文档都强调了相同或稳定前缀复用对成本和延迟的价值。换模型未必解决重复计算。 六、上下文优化不是写更长 prompt 上下文优化的第一步是删。删掉重复规则，删掉对用户无用的内部字段，删掉模型已经知道的废话，删掉与当前任务无关的历史，删掉过期检索结果。很多系统提示词越写越长，是因为团队每遇到一个错误就补一句限制。补丁式 prompt 会快速变成规则垃圾场。生产级上下文应该像产品界面一样有信息架构。 第二步是分层。系统层只放稳定身份、边界和通用行为；任务层放当前任务目标、输入材料和输出合同；证据层放检索结果、来源、时间和置信度；状态层放用户已确认事实、待办和限制；工具层放可调用能力和返回摘要。不同层级不要互相复制。模型看到的信息越清楚，越少需要猜。 第三步是排序。相关证据应该靠近用户问题或最终指令。长上下文里，不要把最重要的资料埋在中间。可以把证据按相关性、时间、权威性和任务步骤排序；也可以先给简短事实摘要，再附原文片段作为依据。Lost in the Middle 的启发不是“永远别用长上下文”，而是不要把长上下文当无序仓库。 第四步是压缩。压缩不是粗暴摘要，而是把对当前任务有用的信息保留下来。客服会话需要保留用户身份、问题类型、已尝试步骤和未解决点；代码任务需要保留相关文件、接口契约、错误栈和测试结果；合同任务需要保留条款编号、义务主体、金额、期限和例外条件。不同任务需要不同摘要结构。 第五步是验证。模型输出后，不要只看语言流畅度。知识问答要检查引用是否存在；结构化抽取要校验字段类型；工具调用要验证参数；代码修改要跑测试；多步骤计划要确认前提。上下文工程和输出验证是一组闭环。没有验证，prompt 写得再漂亮也只是祈祷。 第六步是缓存。稳定前缀放前面，动态内容放后面，才能提高缓存命中。vLLM 的 Automatic Prefix Caching 明确适合长文档多次查询和多轮对话。OpenAI 的 prompt caching 文档也强调精确前缀匹配和把静态内容放在开头。上下文优化不仅是质量工程，也是成本工程。 第七步是路由。不是所有任务都需要同一个模型和同一份上下文。简单分类可以用小模型；复杂推理可以用思考模型；长文档定位可以先检索再让模型综合；高风险输出可以走强模型复核。上下文优化到一定程度后，模型路由会比单纯换大模型更省钱。 七、建立自己的模型更换门槛 团队应该有一套明确的换模型门槛，而不是被发布节奏牵着走。最小可行门槛包括四类指标：质量、成本、延迟和迁移风险。 质量指标要来自真实任务。客服看一次解决率、转人工率、事实错误率和语气合规；知识库问答看召回证据、引用正确、拒答边界和答案完整度；代码助手看测试通过、修改范围、回归风险和用户采纳；Agent 看工具调用成功率、恢复能力和操作安全。不要只拿十几个主观样例决定换模型。 成本指标要按有效结果计算。输入 token、输出 token、KV Cache、GPU 显存、吞吐、重试率、人工修正、缓存命中都会影响成本。一个新模型单 token 更便宜，但如果输出更啰嗦、重试更多、格式错误更多，最终未必便宜。一个大模型看似贵，但如果一次解决率明显高，可能比小模型多轮重试更省。 延迟指标要拆开。首 token 延迟、输出 token 间隔、端到端延迟、p95、p99 和高峰排队都要看。长文档异步任务可以慢，交互聊天不能慢。不要用平均延迟掩盖长尾体验。 迁移风险要具体列出。新模型是否需要改 chat template；是否支持当前工具调用；是否支持 JSON schema 或结构化输出；是否有稳定量化版本；是否与现有推理引擎兼容；许可证是否允许当前商用方式；安全策略是否改变；模型输出风格是否影响用户体验；是否能并行灰度和快速回滚。风险可控，才值得换。 一个实用规则是：如果新模型不能在核心业务评测上带来明显收益，就不要因为榜单好看而换。如果收益只出现在边缘任务，可以按任务路由，不必全站替换。如果收益来自更低成本，要确认质量和运维复杂度没有反向吞掉节省。如果收益来自长上下文，要确认真实长文档任务确实改善，而不是只通过针尖检索测试。 八、给模型追新一个节奏 模型追新可以制度化，而不是每天被动焦虑。建议把模型分成观察、评测、灰度、主力四个阶段。 观察阶段只记录信息。关注官方发布、模型卡、许可证、上下文长度、语言能力、推理引擎支持、量化版本、社区反馈和已知问题。这个阶段不动生产，也不改主线架构。很多模型发布时热度高，几周后问题才暴露。 评测阶段用固定测试集跑。测试集包含业务真实样本、长尾样本、失败样本和安全样本。每次新模型都跑同一套，才能横向比较。评测结果要保存，包括模型版本、量化方式、采样参数、prompt 版本和推理引擎版本。没有版本记录，后面无法复现。 灰度阶段只让一部分任务或用户使用。不要一口气替换所有入口。先选低风险、高收益、可回滚的场景。例如把简单分类、摘要草稿、内部助手、低风险知识问答切到新模型；把高风险审批、财务、法律、生产操作留在主力模型上。灰度期间观察质量、延迟、成本和用户反馈。 主力阶段才考虑全量替换。主力模型要有稳定运维、明确许可证、可接受成本、清晰回滚和长期维护可能。不要把刚发布一天的模型直接变成生产唯一依赖。开放生态变化快，但生产系统需要节奏。 这个节奏还有一个好处：团队不会因为错过某个模型发布而恐慌。模型进入观察池后，等待下一次统一评测。真正好的模型会在评测中留下证据，不需要靠热度逼你当天迁移。 九、上下文优化的工程清单 知识库问答先看文档。文档是否分块合理，标题、章节、时间、版本、来源是否保留；相似内容是否去重；过期内容是否下线；检索是否能召回正确片段；重排是否把关键证据放到前面；答案是否必须引用来源；无证据时是否拒答。做到这些之前，不要急着换更大模型。 长文档分析先看任务形态。用户到底需要全文总结、条款定位、差异比较、风险审查，还是结构化抽取。不同任务需要不同上下文。全文总结可以分段汇总再综合；条款定位应该先检索；差异比较需要对齐两个版本；风险审查需要规则库和证据；抽取需要 schema 和验证。把整份文档塞给模型，只是最粗糙的做法。 Agent 先看状态和工具。模型是否知道当前目标、已完成步骤、可用工具、工具限制、失败原因和下一步选择；工具返回是否有面向模型的摘要；危险操作是否需要确认；执行结果是否被验证；失败后是否有恢复策略。Agent 不聪明，很多时候是因为它看到的是混乱状态，而不是可行动的工作台。 代码助手先看仓库上下文。相关文件是否选对，调用链是否清楚，测试命令是否可用，错误日志是否完整，用户意图是否具体，修改范围是否受控。模型不是 IDE 索引器的替代品。把整个仓库塞进长上下文不如把相关符号、文件片段、失败测试和约束整理好。 客服和运营助手先看政策冲突。多个活动规则、优惠条件、售后政策、地区差异和时间版本很容易冲突。上下文里必须有权威顺序和生效时间。模型答错不是因为不会中文，而是因为规则本身没有被治理。 结构化输出先看合同。字段是否唯一，类型是否明确，枚举值是否有限，缺失时怎么表示，置信度是否需要输出，引用证据放哪里，错误时是否重试。很多团队让模型自由生成 JSON，再用正则修。更稳的做法是先把 schema、示例和验证器做好。 多轮对话先看记忆。哪些信息应该长期记住，哪些只在当前任务有效，哪些需要用户确认，哪些应该过期。历史不是越多越好。稳定记忆、短期状态和原始对话应该分开管理。 十、模型选择要结合许可证和部署现实 “开源模型”这个词在大模型领域并不总是严格。很多模型是开放权重，而不是完整开放训练数据、训练代码和所有中间产物。许可证也不同：Apache 2.0、MIT、Gemma Terms、Llama 社区许可、各种自定义研究或商用限制，含义并不一样。企业部署前必须看许可证，而不是只看 Hugging Face 页面上能下载。 Mistral 的多个开放模型采用 Apache 2.0，DeepSeek-R1 公告强调 MIT 许可，Qwen3 博客写明多个模型 under Apache 2.0 license，Llama 有自己的许可证和可接受使用政策，Gemma 有 Google 的开放模型条款。它们都能用于很多开放生态场景，但法律和合规边界不同。换模型时，许可证变化和能力变化一样重要。 部署现实也很关键。一个模型参数更强，但没有稳定量化版本，或者 vLLM 支持不完善，或者 tokenizer 需要特殊处理，或者显存需求超出当前机器，就不一定适合马上上线。一个小模型 benchmark 略低，但 GGUF、MLX、Ollama、llama.cpp、vLLM 支持成熟，可能更适合本地社区和私有部署。 硬件也决定选择。单机 Mac、本地 4090、数据中心 A100、H100 集群、CPU 边缘设备，适合的模型完全不同。Gemma 3、Mistral Small、Qwen 小尺寸模型、Llama 小尺寸模型各有单机价值；70B、405B、MoE 大模型更适合服务化部署或云上资源。把模型选型和硬件预算分开看，会导致后续一堆妥协。 推理引擎同样影响迁移。vLLM 擅长高吞吐在线服务和 prefix caching，SGLang 对结构化生成和高性能 serving 有自己的生态，llama.cpp 适合本地多后端，TensorRT-LLM 适合 NVIDIA 栈深度优化，Transformers 适合研究和兼容验证。模型发布后先看这些工具是否稳定支持，再决定是否进入灰度。 十一、长上下文不是上下文工程的终点 长上下文模型让很多事情变简单，但也让很多坏习惯变隐蔽。过去 8K 放不下，团队被迫做检索、摘要和裁剪；现在 128K 能放下，团队可能直接把全部材料塞进去。短期看省事，长期看成本高、延迟高、可解释性差、引用不稳。 长上下文适合需要全局结构的任务，例如全文风格审阅、多文档综合、合同整体风险扫描、代码库跨文件理解、长会议纪要分析。但即使在这些任务里，也应该有章节索引、重点摘要、证据定位和输出验证。长窗口给模型更多材料，不代表材料天然有结构。 长上下文不适合替代数据库。事实更新频繁、权限复杂、需要精确过滤、需要审计的场景，仍然应该用检索和工具。把所有可能相关数据塞给模型，不但浪费 token，还可能越权暴露信息。上下文工程必须和权限系统、数据版本和审计结合。 长上下文也不适合替代任务分解。用户要一份完整市场报告，不代表一次模型调用应该完成从资料阅读、数据对比、观点提炼、图表生成到最终排版的所有步骤。复杂任务应该拆成检索、提纲、证据表、草稿、事实检查和润色。每一步上下文更小，质量更可控。 所以，长上下文模型值得用，但不要把它当作治理不足的遮羞布。真正成熟的系统会把长窗口留给必要的综合判断，把普通事实定位交给检索，把重复前缀交给缓存，把长期记忆交给状态管理，把高风险结论交给验证。 十二、从“模型中心”转向“任务中心” 追新疲劳的根源，是团队把注意力放在模型名字上，而不是任务系统上。模型当然重要，但用户最终体验的是任务结果。一个本地 AI 社区、知识库、Agent 平台或开发者工具，要回答的不是“我们用了哪个最新模型”，而是“用户的问题有没有被解决，成本是否可接受，错误是否可恢复，数据是否安全，系统是否可维护”。 任务中心的选型方式更朴素。先定义任务：谁在什么场景下输入什么，系统需要输出什么，错误代价多大，成功标准是什么。再定义上下文：模型需要哪些事实、规则、历史、工具和格式约束。然后定义模型：这个任务需要多强推理、多长上下文、多快速度、多低成本、多严格许可证。最后定义评测：如何知道它真的更好。 这种方式会自然减少追新焦虑。新模型来了，你不需要问“是不是该换”，而是把它放进任务矩阵里看：它替代哪个模型，解决哪个问题，提升哪个指标，增加哪些风险。如果没有明确答案，就留在观察池。如果有明确收益，就进入评测和灰度。 任务中心还会让上下文优化变成日常工作。每次失败都不急着贴新 prompt 或换模型，而是分类：是检索问题、排序问题、证据不足、历史污染、工具失败、格式约束、模型能力、还是用户需求不清。只有这样，系统会越用越稳，而不是越补越乱。 十三、一个实用决策框架 遇到新模型发布时，可以按四步判断。 第一步，问它解决什么已知痛点。不要从模型能力列表出发，而从当前系统问题出发。是推理不够、中文不够、长上下文不够、工具调用不稳、速度太慢、成本太高、许可证不合适，还是部署生态老化。如果没有已知痛点，新模型只是备选。 第二步，问上下文是否已经清理。检索是否准确，证据是否排序，历史是否压缩，工具结果是否整理，输出合同是否明确，缓存是否利用。如果这些还没做，先优化上下文。因为上下文问题会污染任何新模型。 第三步，跑固定评测。用同一批样本、同一套评分、同一组成本指标比较当前模型和新模型。评测必须包含失败样本和长尾样本。只用成功案例会高估迁移收益。 第四步，决定迁移方式。收益大且风险低，可以灰度替换。收益只在某类任务明显，就做路由。收益不明显但未来潜力大，留在观察池。收益来自成本但质量略降，要看任务错误代价。收益来自长上下文但延迟变差，要看产品形态是否接受异步。 这个框架不复杂，但能挡住大部分冲动迁移。模型生态更新越快，团队越需要稳定的判断机制。 十四、不同团队的建议 个人用户和小团队不要追完整模型矩阵。选一到两个通用主力模型，再配一个代码或推理专用模型即可。精力应该放在本地数据整理、提示模板、常用任务工作流和缓存上。模型每周换，习惯和产出都不稳定。 社区站点和内容工具要重视中文体验、成本和可解释性。很多内容任务不需要最大模型，但需要稳定风格、引用来源、可编辑结构和低成本批处理。上下文模板、资料清洗和后处理比追最大参数更重要。 企业内部知识库要优先治理文档。权限、版本、来源、切分、召回、引用和拒答是核心。换模型能改善表达，但不能替你解决知识治理。模型选型应服务于知识链路，而不是盖过知识链路。 Agent 产品要优先治理工具和状态。模型越强，越容易让团队误以为可以把混乱工具直接丢给它。真正能干活的 Agent，需要清楚目标、可验证工具、步骤状态、失败恢复和操作边界。换推理模型有价值，但工具上下文更基础。 开发者工具要重视仓库索引和测试闭环。代码模型更新很快，但没有相关文件选择、错误日志、测试命令和补丁验证，模型能力会被浪费。先让模型看到该看的代码，再讨论换哪个代码模型。 十五、把换模型做成可回滚实验 换模型最怕一步到位。很多系统原来问题不大，换完模型后才发现回答风格变了、输出格式变了、工具调用参数变了、上下文长度虽然更大但延迟上去了、量化版本在中文长文本里不稳。更麻烦的是，团队没有记录旧模型的完整配置，想回滚时只记得模型名，不记得 tokenizer、chat template、采样参数、系统提示词、检索拼接方式和推理引擎版本。一次迁移如果无法复盘，就不是工程实验，而是碰运气。 可回滚实验的第一步是固定对照组。当前线上模型、当前 prompt、当前检索、当前工具、当前采样参数和当前推理配置，都要作为基线保存。新模型只在候选环境里替换一项或少数几项。这样才能判断差异来自模型能力，而不是来自同时改动的上下文模板或采样设置。很多“新模型更强”的结论，其实是因为顺手清理了 prompt；很多“新模型不行”的结论，其实是因为 chat template 用错。 第二步是保留失败样本。成功样本最容易让人乐观，但真正决定生产风险的是失败样本。把历史上答错、超时、格式错、引用错、用户不满意、工具调用失败的案例整理成回归集。新模型如果只在简单样本上好，在失败样本上没有改善，就不值得大规模迁移。反过来，如果新模型专门解决了旧模型最痛的失败类型，即使整体榜单提升不大，也可能非常值得灰度。 第三步是做影子流量。真实用户请求仍由旧模型回答，同时把脱敏后的同类请求发给新模型生成影子结果，不直接展示给用户。系统记录两边的答案、耗时、token、错误、引用和结构化校验结果。影子流量能暴露离线评测看不到的问题，例如某些高频用户表达、某类文档格式、某个工具返回异常、某个时间段的高峰延迟。 第四步是小范围灰度。先让低风险入口使用新模型，例如内部助手、草稿生成、可编辑内容、非关键问答。高风险任务继续留在旧模型或强模型复核链路里。灰度期间要允许快速切回，不要把模型选择写死在客户端。模型路由应该由服务端配置控制，按任务、租户、比例和时间逐步放量。 第五步是明确退出条件。比如引用正确率低于基线、结构化输出失败率上升、p95 首 token 延迟超过阈值、单位有效回答成本没有下降、某类高价值任务满意度下降，就暂停灰度。退出条件提前写清楚，团队就不会因为已经投入迁移成本而硬撑。 第六步是沉淀迁移记录。一次模型实验结束后，不管成功还是失败，都记录结论：适合哪些任务，不适合哪些任务，推荐上下文长度，推荐采样参数，量化版本表现，已知错误，许可证注意事项，回滚版本。这样下一次新模型发布时，团队不是从零开始焦虑，而是在已有知识库上继续判断。 模型迁移做成实验后，追新疲劳会明显下降。团队不再需要凭感觉争论“要不要换”，而是让候选模型进入统一流程。好模型会通过评测留下证据，不适合的模型会在观察池里自然淘汰。生产系统需要的不是最快追上每个热点，而是持续吸收真正有用的能力。 十六、给本地 AI 社区的一点现实建议 本地 AI 社区经常同时面对两类需求：一类是个人和小团队想在自己机器上跑起来，另一类是企业或组织想把模型服务变成稳定能力。前者更关心安装简单、隐私、本地文件、成本和可玩性；后者更关心权限、评测、并发、审计、回滚和长期维护。讨论模型时，最好先说清楚使用形态，否则容易鸡同鸭讲。 如果目标是个人生产力，追新可以更灵活。今天试一个 Qwen，小任务不满意明天换 Gemma 或 Mistral，风险有限。重点是形成自己的任务模板：读论文、改代码、总结会议、整理资料、写脚本、分析日志。模型更新能带来新体验，但真正提升效率的是稳定工作流。 如果目标是团队知识库，不要把模型更换放在第一位。先把资料权限、版本、切分、索引、引用、无答案拒答做好。模型只是最后的表达和综合层。知识库最大的问题通常不是模型不知道，而是系统把错误资料、过期资料、无关资料拿给了模型。 如果目标是本地 Agent，要优先让工具可验证。文件操作、命令执行、浏览器动作、数据库查询、接口调用都需要状态、权限、确认和回滚。模型换得再勤，如果工具层没有边界，Agent 仍然不可靠。真正会干活的智能体，不只是会说下一步，而是能看见结果、判断错误、修正计划。 如果目标是模型网关或社区平台，要建立模型目录的治理方式。每个模型条目应该说明适合任务、上下文限制、许可证、推荐硬件、推荐引擎、量化版本、已知问题和替代方案。用户不需要看到一堆无差别模型名，而需要知道“这个任务选哪个，为什么”。这比盲目堆模型列表更有价值。 本地 AI 的优势不是永远使用最大模型，而是把模型、数据和工具放在自己可控的环境里。可控意味着能看见上下文，能检查输出，能保护数据，能按任务路由，能在模型变化时回滚。追新可以有，生产感也必须有。 十七、结语 开源模型追新疲劳，本质上是模型进步太快，而应用工程没有建立对应的吸收机制。新模型值得关注，也值得评测，但不该让每次发布都变成生产焦虑。真正可靠的 AI 应用，不是永远用最新模型，而是知道当前模型为什么够用，知道什么时候不够用，知道如何用上下文、检索、缓存、路由和验证把能力落到用户任务里。 该换模型时，要果断。能力边界、成本曲线、许可证、生态支持和任务升级都可能让新模型成为正确选择。该优化上下文时，也要克制。检索混乱、历史污染、证据排序差、输出合同弱、工具结果脏，这些问题换多少模型都会回来。 未来开放模型还会继续快速迭代。更长上下文、更强推理、更小尺寸、更好量化、更低成本都会出现。面对这些变化，最稳的姿势不是停止关注，也不是不停迁移，而是建立自己的任务评测和上下文工程能力。模型可以常新，生产系统必须有根。 参考资料 The 2026 AI Index Report, Stanford HAI: https://hai.stanford.edu/ai-index/2026-ai-index-report Technical Performance, The 2026 AI Index Report, Stanford HAI: https://hai.stanford.edu/ai-index/2026-ai-index-report/technical-performance Introducing Llama 3.1, Meta AI: https://ai.meta.com/blog/meta-llama-3-1/ DeepSeek-R1 Release, DeepSeek API Docs: https://api-docs.deepseek.com/news/news250120 Gemma 3, Google Blog: https://blog.google/innovation-and-ai/technology/developers-tools/gemma-3/ Qwen3: Think Deeper, Act Faster, Qwen: https://qwenlm.github.io/blog/qwen3/ Mistral Small 3.1, Mistral AI: https://mistral.ai/en/news/mistral-small-3-1 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv: https://arxiv.org/abs/2005.11401 Lost in the Middle: How Language Models Use Long Contexts, arXiv: https://arxiv.org/abs/2307.03172 RULER: What's the Real Context Size of Your Long-Context Language Models?, arXiv: https://arxiv.org/abs/2404.06654 vLLM Automatic Prefix Caching documentation: https://docs.vllm.ai/en/v0.9.2/features/automatic_prefix_caching.html OpenAI Prompt Caching documentation: https://platform.openai.com/docs/guides/prompt-caching/overview Gemini API Context Caching documentation: https://ai.google.dev/gemini-api/docs/caching

本地大模型不是信仰，也不是万能答案。它是一种把数据、推理、成本和运行责任收回到自己边界内的技术选择。是否需要本地模型，取决于你的隐私边界、任务频率、质量要求、响应速度、团队运维能力和失败成本。 1. 先把问题问准：你需要的是本地模型，还是本地控制权 很多团队说“我们要本地大模型”，真正想要的并不一定是模型权重放在自己机器上。他们可能想要数据不出内网、账单可控、响应更快、系统可审计、供应商可替换、知识库能私有部署、工具调用不越权。模型本地化只是实现这些目标的一种方式，不是唯一方式。 如果你的核心诉求是敏感文档不上传外部平台，那么本地嵌入、本地向量库、本地文档解析、本地权限和审计可能比本地生成模型更优先。生成阶段可以先走脱敏后的云模型，也可以按任务分级路由到本地模型。如果你的核心诉求是低延迟，那么小模型本地常驻可能有效；但如果任务需要超强推理，本地小模型答错带来的返工成本可能超过网络延迟。 所以，第一步不是下载模型，而是列清楚目标：哪些数据不能离开边界，哪些任务必须离线，哪些任务只是希望便宜，哪些任务要求高质量，哪些任务可以等待，哪些任务需要多人并发，哪些输出会触发真实业务动作。把这些问题答清楚，才知道你需要的是本地模型、本地知识库、混合模型网关，还是只是更严格的云 API 数据策略。 2. 本地大模型的真正价值 本地大模型最大的价值是控制权。数据在哪里处理、模型版本何时升级、日志保留多久、谁能调用、能不能断网运行、失败时如何排查，这些都可以由自己决定。对于研发、制造、医疗、法律、金融、教育、政务、企业知识库等场景，控制权常常比单次模型质量更重要。 第二个价值是边际成本。模型加载好以后，高频低难任务的每次调用不再按云 API Token 付费。内部文档摘要、批量分类、工单初筛、低敏问答、离线标注、日志解释、模板生成，都可能适合本地处理。尤其当任务量稳定、输出长度可控、模型足够胜任时，本地模型会让成本曲线更可预测。 第三个价值是可定制。你可以选择量化版本、上下文长度、推理后端、系统提示、检索链路、工具权限、审计格式和模型网关。你可以把本地模型接到内网知识库、文件系统、工单系统和脚本工具，而不把这些系统暴露给外部。对团队来说，本地 AI 不只是聊天模型，而是内网能力编排层。 第四个价值是可持续试验。开源模型生态迭代快，Qwen、Llama、Mistral、DeepSeek、Gemma 等系列不断出现新版本、蒸馏版、长上下文版、代码版、视觉版和量化版。团队拥有本地评测和部署能力后，可以快速替换底层模型，而不是把所有应用绑定在单一外部接口上。 3. 本地大模型不等于天然安全 “数据不出本机”听起来安全，但生产安全不止这一条。模型文件从哪里下载？权重许可证是否允许商用？推理服务是否监听公网？Web UI 有没有鉴权？日志里是否保存了敏感 prompt？向量库是否有权限过滤？工具调用是否能读写危险路径？管理员能否审计谁问了什么？这些问题如果没处理，本地系统也会泄露数据。 本地模型还会放大内部权限风险。云 API 至少通常有租户隔离、访问密钥、审计和平台级安全策略；自己搭的本地服务如果用一个共享端口、一个共享密钥、一个无鉴权前端，就可能让任何内网用户访问所有知识库。最危险的不是模型回答错，而是模型通过工具读到了不该读的文件、查到了不该查的业务数据、执行了不该执行的脚本。 因此，本地化必须配套权限边界。用户登录、知识库 ACL、工具白名单、参数校验、写操作确认、日志脱敏、密钥隔离、网络访问控制，都要在模型之外完成。不要把安全寄托在提示词上。提示词可以提醒模型，但不能替代系统权限。生产级本地 AI 的安全边界应该由应用、网关、工具层和基础设施共同承担。 4. 隐私选择：云 API、本地模型和混合路由 隐私不是二元选择。可以把任务按数据敏感度分层。公开材料、营销文案、通用代码解释可以走云模型；内部普通文档可以走本地 RAG 加云模型摘要；高敏合同、客户信息、财务数据、研发机密可以只在本地处理；涉及真实业务写操作的任务需要本地工具层确认，不管生成模型在云上还是本地。 云模型服务商通常会提供企业数据使用政策、训练隔离说明、数据保留设置和合规材料。对很多公司来说，合规使用云 API 并不是不能接受。问题在于你要知道数据具体会被发送到哪里、是否被用于训练、保留多久、谁能访问、是否有区域选择、是否支持零保留或企业协议。不能用“云一定不安全”这种口号替代合规评估。 本地模型适合处理不可外发数据，但也要考虑供应链。模型权重、Docker 镜像、Python 包、Web UI 插件、浏览器扩展、推理服务依赖，都可能带来风险。最稳妥的做法是建立受控下载源、校验哈希、固定版本、隔离运行用户、限制网络访问，并把模型服务放在内网可信区域。 混合路由往往最现实。低敏高难任务交给强云模型，高敏常规任务交给本地模型，知识检索和权限判断尽量本地化，最终写操作由本地业务系统执行。这样既不盲目牺牲能力，也不把所有数据都交给外部。 5. 成本不是“买显卡就免费” 本地模型没有按次 API 账单，但它有硬件成本、电费、折旧、维护、人力和机会成本。显卡、内存、硬盘、散热、电源、服务器机架、备份、监控、故障替换都要钱。更重要的是，能把本地模型稳定接进业务的人也要钱。若只是每天少量使用，云 API 往往更便宜。 成本计算要看任务量。假设团队每天只有几十次问答，而且需要高质量长推理，云模型按需付费通常简单可靠。假设每天有数万次低难分类、摘要、标签生成，本地模型常驻可能摊薄成本。假设任务集中在工作时间高峰，本地硬件要按峰值配置；云 API 可以按请求扩缩。假设输出一旦错误会导致人工复核，本地模型省下的调用费可能被返工吞掉。 还要看模型大小。7B 到 14B 级别模型可以在消费级硬件或 Apple Silicon 上跑得比较轻；30B 以上需要更多显存或更激进量化；70B 级别对硬件、吞吐和并发要求明显增加。量化能降低显存占用，但可能影响质量，尤其是复杂推理、长上下文、代码和细粒度事实任务。低成本不是只看能否加载模型，而是看加载后能否稳定完成任务。 6. 速度要分成首 Token、生成速度和排队时间 本地模型常被认为更快，因为请求不经过外网。这个判断只对一部分场景成立。速度至少分成三部分：首 Token 延迟、每秒生成 Token 数、排队等待时间。小模型本地常驻、短上下文、局域网访问时，首 Token 可以很快。大模型、长上下文、CPU 推理、高并发排队时，本地反而可能很慢。 云模型的网络延迟通常存在，但服务端硬件强、并发调度成熟、模型优化充分。对复杂任务来说，云模型可能虽然首包慢一点，但整体完成更快。对内网工具问答、小段摘要、代码补全、实时助手，本地小模型可以提供更稳定的低延迟体验。速度不是由“本地或云”单独决定，而是由模型大小、上下文长度、推理后端、硬件、并发和输出长度共同决定。 用户感知也很重要。流式输出能显著降低等待焦虑，即使总时长不变。任务拆分能让用户先拿到大纲或关键结论，再继续生成细节。缓存常见前缀、复用检索结果、限制工具返回、减少无关历史，都能改善速度。很多时候，优化上下文比换显卡更有效。 7. 能力差距：开源模型很强，但不是所有任务都够用 近几年开源和开放权重模型进步很快，很多中文写作、代码、数学、工具调用、长上下文和多语言任务已经可用。对内部知识问答、文档总结、轻量代码解释、工单归类、规范检查、本地助手，优秀开源模型足以胜任。配合 RAG、重排、结构化提示和工具调用，本地系统能做很多实事。 但要承认能力差距仍然存在。前沿闭源模型在复杂推理、跨领域综合、长链规划、多模态理解、工具可靠性、鲁棒性和安全对齐方面通常更强。越是开放问题、越是高价值决策、越是需要多步推理，模型能力差距越容易变成业务差距。用小模型硬做大模型任务，表面省钱，实际可能产出大量似是而非的答案。 评估时不要只看榜单。榜单能提供参考，但你的任务才是标准。中文合同审阅、设备故障诊断、销售知识库问答、内部代码迁移、财务规则解释、客服工单总结，每个任务对模型能力要求不同。建立自己的小评测集，比争论某个公开排名更有价值。每次换模型、换量化、换提示词，都应该跑同一组样本。 8. 本地模型最适合的任务 第一类是高频低敏或中敏任务。例如内部资料摘要、会议纪要整理、日报生成、工单分类、日志初筛、知识库粗问答、文本清洗、标签生成。这些任务数量多、价值分散、对单次最高质量要求不极端，本地模型的边际成本优势明显。 第二类是强隐私任务。例如客户资料、未公开合同、研发文档、内部事故报告、员工信息、商业计划、源代码安全分析。只要数据不能离开组织边界，本地模型或本地 RAG 就有充分理由。哪怕模型能力稍弱，也可以通过限定任务范围、人工复核和工具链补强来获得可接受结果。 第三类是低延迟内网助手。例如运维命令解释、内网知识查询、IDE 辅助、局域网设备问答、文档搜索入口。用户希望随手问、马上答，且数据源就在本地。模型不需要每次都调用最强云模型，反而需要稳定、便宜、可用。 第四类是批处理和离线任务。例如夜间批量摘要、文档入库预处理、自动分类、重复内容检测、历史工单归纳。批处理可以利用闲时算力，不需要极低首包延迟。本地机器白天服务交互，晚上跑批，是很常见的高性价比用法。 9. 本地模型不适合的任务 如果任务需要最高水平复杂推理、长链规划、科研级综合分析、困难代码生成、严肃法律医学判断，且输出质量直接影响重大决策，本地小模型通常不够。可以让本地模型做预处理、检索、草稿和隐私过滤，但最终分析可能仍需要更强模型和专业人工复核。 如果使用量很低，团队也没有运维能力，本地部署可能得不偿失。为了每周几十次问答购买硬件、维护服务、处理模型升级，经济上不划算。很多个人或小团队更适合先用云模型，把本地化放在数据敏感或成本真正上升后再做。 如果业务要求高可用、多租户、权限隔离、审计合规、灾备和 SLA，而团队没有基础设施能力，直接自建本地模型风险很高。模型能跑只是第一步，生产系统还要能监控、扩容、限流、告警、回滚和追责。本地化把责任带回自己手里，责任如果接不住，就会变成隐患。 10. 推理后端选择：Ollama、llama.cpp、vLLM、MLX Ollama 适合快速启动和小团队试点。它提供简单的模型管理和本地 API，开发者可以很快把模型跑起来，接入聊天、嵌入或基础应用。它的优势是门槛低，适合验证“这个模型能不能做我们的任务”。如果目标是桌面使用、内部原型和轻量服务，它很顺手。 llama.cpp 适合深入控制。它支持 GGUF 生态、CPU、Metal、CUDA 等多种后端，常用于本地桌面、边缘设备和量化模型部署。想理解模型权重、上下文长度、batch、线程、GPU offload、KV Cache 对性能的影响，llama.cpp 是非常好的基础设施。 vLLM 更偏服务端高吞吐。它提供 OpenAI 兼容接口，强调连续批处理、PagedAttention、前缀缓存等能力，适合多人并发和 GPU 服务器部署。如果本地模型要作为团队共享服务，而不是个人桌面工具，就应该评估这类服务端推理框架。 MLX 适合 Apple Silicon 生态。Mac 用户可以利用统一内存和 Apple 芯片跑本地模型，适合开发、试验和轻量服务。它不等同于通用生产服务器方案，但对很多个人开发者和小团队来说，Mac 本地 AI 的门槛已经很低。 11. 模型网关比单个后端更重要 如果应用直接绑定某个本地后端的私有接口，未来换模型会很痛。生产系统最好有统一模型网关，对上提供稳定 API，对下接 Ollama、llama.cpp server、vLLM、云模型或其他服务。网关负责模型路由、鉴权、限流、超时、重试、日志、用量统计和降级。 模型网关的价值在混合策略里更明显。同一个应用可以把低敏复杂任务路由到云模型，把高敏普通任务路由到本地模型，把嵌入请求路由到本地嵌入模型，把长文摘要路由到大上下文模型。应用层只表达任务意图，不关心底层模型部署细节。 网关还方便做评测和灰度。新模型上线时，可以给一小部分流量试用，记录质量、延迟和成本。若效果不好，快速回滚。没有网关时，模型切换常变成到处改配置、改提示词、改 SDK。模型越多，越需要统一入口。 12. 知识库本地化常常比生成模型本地化更先发生 很多团队真正敏感的是知识库，不是生成过程本身。文档解析、切块、嵌入、向量库、全文索引、权限过滤、引用展示，这些环节会长期保存组织知识。如果这些都在外部平台，敏感数据已经离开边界。即使最终生成用云模型，知识库也应该优先考虑本地化或私有化。 本地 RAG 可以让数据留在内网，并且只把必要片段发给生成模型。如果片段仍然敏感，就用本地生成模型；如果片段经过脱敏且任务需要更强推理，可以走云模型。这样的分层比“全云”或“全本地”都更灵活。 知识库本地化还有一个好处：权限可控。不同用户只能检索自己有权访问的文档，模型回答必须带来源，审计可以追踪问题命中的片段。没有权限过滤的 RAG 会把模型变成越权搜索入口。本地化不是把向量库存到自己机器上就完事，关键是把权限和引用链路做完整。 13. 本地模型需要一套真实评测 不要用“问几个脑筋急转弯”判断模型能不能上线。真实评测应该来自你的业务任务。可以准备五十到一百个样本，覆盖常见问答、长文摘要、错误拒答、工具调用、结构化输出、中文表达、专业术语、边界权限和低质量输入。每个样本都要有期望答案或评分标准。 评测指标也要具体。知识库问答看引用命中率、事实正确率、拒答是否合理；工具调用看参数是否完整、是否越权、是否需要确认；写作看结构、语气、信息完整性；代码看能否运行、是否引入安全问题；摘要看是否遗漏关键数字和限制条件。只看“感觉还行”很容易让低质量系统进入生产。 量化版本也要评测。一个模型从 FP16 换成 4-bit 后，速度和显存占用改善，但复杂任务质量可能下降。不同量化方法、上下文长度和推理参数也会影响结果。不要以为同一个模型名就代表同样能力。生产记录里应该写清模型版本、量化格式、上下文长度、推理后端和参数。 14. 维护负担：模型文件只是开始 本地模型上线后，需要维护模型下载、版本管理、权重校验、磁盘空间、GPU 驱动、推理框架、Python 依赖、服务启动、日志轮转、监控告警、备份恢复和安全补丁。任何一个环节坏了，用户看到的都是“AI 不可用”。 模型升级也不是越快越好。新模型可能更聪明，也可能改变输出格式、工具调用习惯、拒答边界和 Token 消耗。业务系统依赖稳定行为，不能今天随手换一个模型，明天让用户发现答案风格、字段格式和引用方式全变了。升级应该走评测、灰度、回滚流程。 硬件维护同样现实。显卡温度、显存碎片、长时间运行泄漏、磁盘写满、风扇故障、电源问题、系统重启、驱动兼容，都会影响服务。个人电脑上跑得好，不代表团队共享服务就稳定。生产级本地 AI 至少需要进程守护、健康检查、日志、资源限制和自动恢复。 15. 许可证和模型来源不能忽略 开源不等于无条件商用，开放权重也不等于自由使用。不同模型有不同许可证和使用限制，可能涉及商用许可、月活限制、输出使用、再分发、品牌使用、受限行业、可接受使用政策。企业使用前必须看清模型卡、许可证和官方条款。 模型来源也要可信。不要从不明网盘下载改名权重，不要随意运行陌生仓库的一键脚本，不要把生产密钥放进测试 Web UI。权重文件本身主要是数据，但围绕模型的加载代码、插件、镜像、依赖包可能执行任意代码。供应链安全是本地 AI 的基础问题。 实践上，建议使用官方发布渠道或可信社区仓库，固定版本，记录下载地址和哈希。镜像和依赖进入生产前要经过扫描和内网镜像。模型卡、许可证、评测记录和部署配置应该一起归档。这样未来追溯问题时，不会只剩一个含糊的“某个 14B 模型”。 16. 本地模型和工具调用：真正风险在动作 聊天回答错了，用户可以忽略；工具调用错了，系统状态可能被改变。本地模型接入文件、数据库、脚本、邮件、工单、服务器命令后，风险级别立刻上升。模型不应该直接拥有广泛权限，而应该通过工具层调用受限能力。 工具层要做认证、授权、参数校验、幂等、审计和人工确认。删除文件、发送邮件、修改订单、执行命令、转账、发布内容等高风险操作，不能只凭模型一句自然语言决定。模型可以建议动作，工具层决定是否允许，用户确认后才执行。 本地环境尤其容易偷懒：因为服务在自己机器上，就让模型读整个目录、执行任意 shell、访问内网全部接口。开发阶段这样很方便，生产阶段非常危险。正确做法是为每个工具定义最小权限、输入 schema、输出摘要和错误处理。模型越聪明，越要限制动作边界。 17. 离线能力是少数场景的硬需求 完全离线是本地模型独有优势之一。某些实验室、工厂、边缘设备、内网机房、保密环境、现场运维场景，无法稳定访问外网，或者制度上禁止外联。这时本地模型不是偏好，而是前提。即使模型能力弱一些，也必须在可用边界内完成任务。 离线系统要准备完整资源：模型权重、推理框架、依赖包、文档解析、嵌入模型、向量库、前端应用、日志和备份。不要等到断网后才发现某个依赖会在线下载 tokenizer，某个 Web UI 会请求外部字体，某个评测脚本会访问远程模型卡。真正离线需要从安装、启动、升级到恢复都能在内网完成。 但大多数普通团队并不需要绝对离线。他们需要的是敏感数据可控、外部调用可审计、关键服务不断供。为了“离线”牺牲大量能力和效率，未必值得。离线是一种约束，不是先进程度的证明。 18. 团队协作时，桌面聊天工具不够 个人使用本地模型，可以用桌面聊天工具、命令行或浏览器 UI。团队使用时，需要账户、权限、知识库分组、项目隔离、调用日志、用量统计、共享提示模板、模型路由和管理员控制台。否则，本地 AI 会变成每个人电脑里一套各自为政的工具，无法沉淀组织能力。 团队版最小形态可以很简单：一个统一入口，一个模型网关，一个本地知识库服务，一个工具调用服务，一个审计数据库。用户通过统一入口使用模型，管理员管理模型和知识库，开发者通过 API 接入。这样即使底层先用单机，也有清楚边界，未来能迁移到更强硬件。 桌面工具仍然有价值，适合探索模型、人工对比、临时总结和个人知识库。但不要把它误认为生产平台。生产平台要服务多人、承担权限、稳定运行、支持回滚，并且能被业务系统调用。 19. 本地模型的产品体验要避免暴露工程细节 最终用户不应该被迫理解 GGUF、Q4_K_M、KV Cache、temperature、top_p、context size、batch size。专业用户可以有高级设置，但普通入口应该围绕任务：写总结、查知识、生成方案、分析日志、整理会议、创建工单。模型细节可以隐藏在“速度优先”“质量优先”“隐私优先”这类可理解选项后面。 很多本地 AI 原型失败，不是模型不能用，而是产品像调试面板。用户看到一堆模型名、参数、系统提示、原始 JSON、错误堆栈，不知道下一步该做什么。生产级 UI 应该信息去重、层级清晰、面向最终用户。内部字段、调试术语、实现细节不该进入主流程。 同时，体验要诚实。模型能力不足时，界面应该提示“适合摘要和检索，不适合最终法律判断”；长任务需要时间时，显示进度和分阶段结果；本地模型回答可能不确定时，提供引用和人工复核入口。隐藏工程细节不等于隐藏风险。 20. 一个务实的决策框架 可以用五个问题判断是否需要本地大模型。第一，数据是否不能离开自己的控制边界？如果是，本地模型或至少本地知识库优先。第二，任务量是否足够高，足以摊薄硬件和维护成本？如果不是，云模型可能更经济。第三，本地模型能力是否通过真实评测达标？如果没有，不能凭感觉上线。第四，团队是否有运维和安全能力？如果没有，先做小范围试点。第五，系统是否需要离线或低延迟内网响应？如果是，本地优势更明显。 答案不是单选。很多成熟方案会采用三层路由：本地小模型处理高频轻任务，本地中大模型处理敏感任务，云强模型处理低敏高难任务。所有请求经过同一个网关和审计，知识库和工具权限在本地控制。这样可以同时获得隐私、成本和能力的平衡。 如果现在还不确定，可以先从本地知识库和评测集做起。把文档解析、切块、嵌入、向量库、权限和引用做好，再接一个本地模型和一个云模型对比。用真实任务跑一周，你会比看十篇测评更清楚自己需要什么。 21. 最小可行本地 AI 路线 第一阶段，个人或小团队试点。用 Ollama、LM Studio、llama.cpp 或 MLX 跑一个合适模型，准备真实样本，验证摘要、问答、写作、代码和工具参数生成。此阶段目标是知道模型能做什么，不能做什么，不追求平台化。 第二阶段，本地知识库。搭建文档解析、切块、嵌入、向量库、重排和引用展示。把权限设计放进去，不要等知识库大了再补。此阶段目标是让模型基于团队资料回答，并且答案可追溯。 第三阶段，统一网关和应用入口。把模型调用、路由、日志、用量、超时和错误处理收敛到服务端。前端只展示最终用户需要的任务界面。此阶段目标是从个人工具变成团队服务。 第四阶段，工具调用和自动化。把查数据、生成工单、写文件、发通知等能力封装成受控工具。高风险动作必须确认和审计。此阶段目标是让 AI 真正做事，但不越权。 第五阶段，评测、监控和灰度。建立固定评测集，记录模型版本、延迟、错误率、用户反馈和成本。模型升级走灰度，不满意能回滚。此阶段目标是让本地 AI 长期稳定演进。 22. 常见误区 误区一：参数越大越好。参数大通常能力更强，但速度、显存和成本也更高。对简单分类和摘要，小模型可能更合适。误区二：量化不影响质量。量化常常可用，但对复杂推理和细节任务必须实测。误区三：本地就不用权限。恰恰相反，本地模型接近内部系统，更需要权限。 误区四：能聊天就能生产。聊天只是交互壳，生产需要日志、评测、权限、错误处理和回滚。误区五：榜单第一就适合自己。榜单任务和业务任务可能完全不同。误区六：把所有材料塞进长上下文就能解决 RAG。长上下文没有替代检索质量、去重和证据组织。 误区七：云模型和本地模型必须二选一。混合路由更常见，也更务实。误区八：本地部署一次就结束。模型、依赖、安全补丁和业务需求都会变化，维护是长期成本。误区九：把调试参数交给最终用户。用户需要完成任务，不需要替你调推理引擎。 23. 结论：需要本地大模型的人，真正需要的是可控的 AI 生产体系 你真的需要本地大模型吗？如果你有高敏数据、高频任务、离线要求、低延迟内网场景、供应商替换需求，或者希望把 AI 接进内部工具链，那么答案很可能是需要。但这不意味着所有任务都应该本地跑，也不意味着下载一个模型就完成了。 本地大模型的正确位置，是可控 AI 生产体系中的一层。它旁边应该有本地知识库、模型网关、权限系统、工具层、评测集、监控和产品界面。没有这些配套，本地模型只是一个会说话的进程；有了这些配套，它才可能成为团队可依赖的能力。 更务实的路线是：先用真实任务评测，再决定本地、云端或混合；先把知识和权限放在自己手里，再逐步扩大本地推理范围；先让系统稳定完成小事，再让它接触高价值动作。不要为了本地而本地，也不要因为云模型强就放弃控制权。真正成熟的选择，是知道每一类任务应该在哪里运行、由谁负责、失败时怎样追溯。 24. 本地 RAG 的成败，常常不在模型 很多团队把本地问答效果差归因于模型太小，实际问题可能在 RAG 链路。文档解析丢标题、切块把条款拆断、嵌入模型不适合中文、向量库没有权限过滤、召回结果没有重排、引用来源缺失、旧版本文档和新版本文档同时入库，这些都会让再强的模型回答不稳。本地模型只是最后一个生成环节，前面的知识工程决定它能看到什么。 本地知识库要先解决“可检索、可追溯、可更新、可授权”。可检索意味着用户问题能命中真正相关片段；可追溯意味着答案能回到文档、章节、页码或记录；可更新意味着文档版本变化后索引能刷新，旧材料能下线；可授权意味着不同用户不会互相看到无权内容。没有这些基础，本地 AI 会从助手变成不可靠的全文搜索包装。 一个实用做法是把 RAG 失败分成几类记录：没有召回、召回错、召回对但模型没用、模型用了但答错、答案对但引用不清、权限拦截不正确。每类失败对应不同修复手段。没有召回要调嵌入和切块，召回错要加重排或关键词混合检索，模型没用要改上下文组织，引用不清要改证据格式。只换大模型，往往治标不治本。 25. 本地模型和云模型的协作模式 成熟系统通常不会坚持单一路线。可以让本地模型做前置过滤、分类、摘要、脱敏和证据整理，再让云模型处理低敏高难推理。也可以让云模型生成计划，本地工具层执行受控查询，再让本地模型把结果整理给内部用户。关键是每一步的数据边界清楚，不把敏感内容无意识传出去。 一种常见模式是“本地先读”。用户上传资料后，本地解析、清洗、切块、嵌入和权限过滤；系统只把必要、脱敏、低风险片段发给强模型。另一种模式是“本地先答”。本地模型先尝试回答，置信度不足或用户要求更高质量时，经过确认再升级到云模型。还有一种模式是“云端出思路，本地查事实”。云模型不接触原始数据库，只输出查询计划，实际数据查询由本地工具执行。 这些模式都要求系统有明确审计：哪一段数据发给了哪个模型，为什么发，用户是否确认，返回结果是否进入本地记录。混合不是随意拼接，而是受控路由。把路由做清楚，团队才能同时利用云端能力和本地控制权。 26. 不同组织规模的选择 个人开发者最适合从本地桌面模型开始。用 Mac、游戏本或小型工作站跑 7B 到 14B 模型，解决写作辅助、代码解释、个人知识库和离线整理。个人阶段重点是体验模型能力和工作流，不必一开始搭复杂平台。只要注意模型来源、隐私数据和备份即可。 小团队适合建立统一入口。几个人共享一个本地模型服务、一个知识库和一个网关，避免每个人重复下载模型和维护不同版本。小团队最容易遇到的问题是“能用但不稳”：服务重启没人知道、文档版本混乱、权限靠口头约定、模型参数随手改。此阶段要补齐账户、日志、健康检查和固定评测集。 中大型组织需要平台化。模型服务、知识库、工具调用、权限审计、费用归因、合规评估、灰度发布和灾备都要进入制度。此时本地大模型不是某个工程师电脑上的进程，而是内部 AI 基础设施。平台化成本高，但一旦做好，应用团队可以在统一边界内快速构建各种 AI 功能。 27. 本地部署的硬件选择，要从任务反推 硬件不是越贵越好，而是要匹配任务。短文本分类、摘要和轻问答，可以从小模型和普通设备开始；长上下文、多用户并发、代码生成和复杂推理，需要更大显存和更强 GPU；离线批处理可以牺牲实时速度，用闲时慢慢跑；交互助手则要优先保证首 Token 延迟和稳定流式输出。 Apple Silicon 的统一内存适合个人和小团队试验，优势是安静、省电、开发体验好，适合本地知识库、轻量服务和模型对比。NVIDIA GPU 生态更适合服务端并发和成熟推理框架，CUDA 生态、量化工具和部署经验更丰富。CPU 路线也不是没有价值，适合小模型、嵌入、边缘设备和低频任务，但不能期待它承担大量复杂生成。 买硬件前，最好先租用或借用相似环境跑一周真实任务。记录模型加载时间、首 Token、每秒 Token、峰值内存、并发排队、温度、电力和失败情况。纸面显存能装下模型，不代表用户体验可接受。硬件决策一旦买错，比换云 API 套餐麻烦得多。 28. 运维边界：谁负责“模型今天还能用” 本地模型进入团队工作流后，必须有人负责运行状态。服务挂了谁处理？模型升级谁批准？知识库索引失败谁收到告警？磁盘满了谁清理？GPU 驱动更新谁验证？安全漏洞谁跟进？如果这些问题没有答案，本地 AI 很快会变成大家都依赖、却没人负责的系统。 最小运维清单并不复杂。服务要有进程守护和开机启动，接口要有健康检查，日志要能按天轮转，模型目录要有剩余空间告警，关键请求要记录耗时和错误，配置要能回滚，数据要有备份。对外提供 API 时，还要有限流和认证。团队越小，越要把这些基础项做简单、做自动化。 还要区分开发环境和使用环境。开发者可以频繁换模型、调参数、看调试日志；普通用户使用的入口应该稳定。不要让试验模型直接替换生产模型，不要让调试错误暴露给用户，不要让临时脚本成为长期服务。开发阶段可以快，进入团队使用后必须有边界。 29. 什么时候应该暂时不做本地模型 如果你还没有明确使用场景，只是因为看到本地模型很热，就不该急着搭平台。先用云模型把产品流程跑通，找出真正产生价值的任务，再判断哪些任务因为隐私、成本或速度需要本地化。没有任务牵引的本地平台，容易变成硬件展示和模型收藏。 如果团队没有人能维护基础设施，也不愿意为维护付费，本地化要谨慎。模型服务不像静态网站，资源占用高、依赖复杂、升级频繁。无人维护时，小问题会长期积累，最后用户失去信任。可以先使用托管私有化服务、企业云 API 或受控 SaaS，等需求和能力成熟后再迁移。 如果业务对答案质量要求极高，而本地模型评测没有达标，也应该暂缓。可以先让本地模型做辅助环节，例如资料整理、隐私过滤、草稿生成，而不是最终决策。技术路线应该服从结果，不该为了本地化标签牺牲业务质量。 30. 最后用一句话判断 如果本地模型能让关键数据更安全、常用任务更便宜、内网响应更稳定，并且团队愿意承担评测、权限、运维和升级责任，它就是值得建设的基础设施。如果只是为了追赶概念，而没有明确任务、没有质量评测、没有负责人、没有安全边界，它就会变成一套昂贵而脆弱的玩具。真正的判断标准不是“能不能本地跑”，而是“本地跑以后，业务是否更可靠、更可控、更可持续”。这也是本地化真正值得投入的原因。 还要把时间成本算进决策。隐私要求会推动本地化，成本压力会推动本地化，低延迟体验也会推动本地化；但模型选型、量化验证、驱动升级、知识库重建、权限审计和故障处理都会占用团队时间。如果这些维护时间没有负责人，本地模型省下的调用费会被长期维护成本抵消。 参考资料 Ollama Documentation https://docs.ollama.com/ ggml-org llama.cpp project documentation https://github.com/ggml-org/llama.cpp vLLM Documentation https://docs.vllm.ai/ Hugging Face Transformers Quantization documentation https://huggingface.co/docs/transformers/quantization Apple MLX examples for LLMs https://github.com/ml-explore/mlx-examples/tree/main/llms OpenAI Enterprise Privacy https://openai.com/enterprise-privacy/ Microsoft Azure OpenAI Data, privacy, and security https://learn.microsoft.com/en-us/azure/ai-foundry/responsible-ai/openai/data-privacy Stanford HAI AI Index Report 2025 https://hai.stanford.edu/ai-index/2025-ai-index-report LMSYS Chatbot Arena / LMArena https://lmarena.ai/ Meta Llama official site https://www.llama.com/

站点：localaihub.com 风格：社区实践帖 联网检索日期：2026-05-22 很多人第一次听到“蜂群协作”“多智能体团队”，会下意识觉得这像玄学：给几个大模型起名字，一个叫产品经理，一个叫工程师，一个叫评审官，然后它们在群聊里互相夸几句，最后生成一段看起来像方案的文本。这样的玩法确实不少，但它不是我们要讨论的多智能体协作。 真正有价值的多智能体团队，核心不是角色扮演，而是分工、校验和交付。分工解决“谁做什么”；校验解决“做得对不对”；交付解决“结果能不能被真实使用”。如果一个多智能体系统不能减少上下文混乱，不能降低错误率，不能留下可追踪证据，也不能产出更好的工件，那它只是把一个模型的问题拆成了多个模型的问题。 这篇社区实践帖想讲清楚一件事：蜂群协作不是魔法，也不是把 agent 数量堆起来，而是用工程方法组织一组会使用工具、会交换工件、会互相检查、会对结果负责的智能体。你可以把它理解成一个小型 AI 团队：有人调研，有人执行，有人测试，有人把关，有人把交付物整理到用户能用的状态。 一、先别急着上多智能体 在实践里，多智能体不是默认答案。很多任务用一个智能体加几件好工具就够了。比如查询订单、生成会议纪要、改一个配置、根据文档回答问题，这类任务如果拆成多个智能体，反而会增加通信成本和失败点。 什么时候应该考虑多智能体？通常有四种信号。 第一，任务跨度大。比如“调研一个技术方案并落地到代码”，既要查资料，又要读代码，又要改文件，又要跑测试，还要写说明。一个智能体能做，但上下文会很长，注意力容易散。 第二，任务需要独立校验。比如写长文、做财务分析、生成合同草案、规划生产变更。生成者和检查者最好不是同一个工作单元，否则它很容易为自己的错误找理由。 第三，工具权限不同。研究员可以联网，工程师可以改代码，发布员可以触发部署，审计员只能读日志。把这些权限放在同一个智能体身上，会让风险变大。 第四，专业视角不同。产品视角看用户目标，工程视角看实现约束，安全视角看权限边界，测试视角看失败路径。多视角并不是为了制造争论，而是为了减少单一视角的盲区。 如果没有这些信号，多智能体很可能只是增加复杂度。社区里很多失败案例，本质上都是“一个模型能做的事，硬拆成五个模型，然后没人负责最后交付”。 二、蜂群协作的最小可用模型 一个可落地的蜂群协作系统，至少有五个元素： 目标：团队最终要交付什么。 角色：每个智能体的职责和边界。 工件：角色之间传递的结构化结果。 校验：谁检查什么，按什么标准检查。 编排：什么时候并行，什么时候串行，什么时候停止。 “工件”是最容易被忽略的部分。很多多智能体系统让所有智能体共享一段聊天记录，看起来信息透明，实际很快变成噪声。真正的协作应该围绕工件进行：研究卡片、需求清单、修改计划、代码补丁、测试报告、风险清单、最终文档。聊天只是过程，工件才是交付物。 用写一篇技术教程举例，比较差的协作方式是： 研究员：我觉得可以写这些点。 作者：我来写。 评审：写得不错。 总结者：这是最终答案。 比较好的协作方式是： 研究员输出资料卡片：来源、链接、发布时间、关键结论、可信度。 架构员输出提纲：章节、读者目标、每章要解决的问题。 作者输出正文：只使用已确认资料，不虚构引用。 事实核查员输出问题清单：哪些说法缺来源，哪些需要改写。 编辑输出发布稿：去重、层级、标题、读者语气、参考资料。 差别就在于，后一种方式每一步都有可检查的中间成果。即使最后文章不完美，也能知道问题出在资料、结构、正文还是审核。 三、角色怎么分：按责任分，不按头衔分 多智能体角色不应该照搬公司组织架构。很多系统喜欢设置“CEO、CTO、产品经理、程序员、测试工程师”，但这些头衔如果没有工具权限和输出契约，就只是装饰。 更实用的分法是按责任分。 研究型角色负责降低未知。它的任务是查资料、找证据、比较方案、发现限制。它的输出不是“我觉得”，而是带来源的事实卡片。它应该优先使用官方文档、论文、项目文档、厂商说明、标准规范。研究型角色可以联网，但不应该直接改生产文件。 执行型角色负责改变世界。它可以写代码、改配置、生成文档、调用业务 API、创建工单。执行型角色必须有明确权限边界和回滚策略。它的输出不是“已经处理”，而是具体改了什么、改在哪里、验证了什么。 评审型角色负责找问题。它不需要重复完成任务，而是检查事实、逻辑、格式、安全、风险和可用性。评审型角色最怕变成礼貌评论员，所以必须给它硬标准：链接是否可达，测试是否通过，权限是否越界，用户目标是否满足。 协调型角色负责控制流程。它维护任务目标、分配子任务、合并工件、判断是否需要重试或询问用户。协调者不是老板，它更像调度器和状态机。它不能只会说“继续优化”，必须能决定“停止、交付、返工、升级确认”。 交付型角色负责把结果变成用户能用的形态。很多 AI 团队停在“内容已经生成”“代码已经改好”，但用户需要的是文件路径、部署地址、测试结果、操作说明、风险提示。交付型角色要把工程产物整理成最终状态。 一个简单任务不需要五种角色都出现。比如修改一个前端按钮，可能只需要执行者和评审者。一个复杂项目计划，可能需要研究、协调、执行、评审和交付全部参与。角色数量由任务复杂度决定，不由想象力决定。 四、协作模式一：主管加专家 “主管加专家”是最常见的多智能体模式。一个主管智能体接收用户目标，拆分任务，然后把子任务交给专家智能体。OpenAI Agents SDK 的 handoffs、LangGraph 的 supervisor、Google ADK 的 agent team 都支持这类模式。 这个模式适合边界比较清晰但步骤需要动态调整的任务。例如： 用户目标：把一个知识库问答功能改成真正能调用企业文档，并验证回答引用。 主管：拆成文档接入、检索链路、回答生成、引用验证、端到端测试。 后端专家：实现文档索引和检索接口。 AI 专家：调整回答链路和引用格式。 测试专家：构造问题并检查引用是否来自正确文档。 交付专家：汇总改动、测试结果和剩余风险。 主管模式的优势是灵活。用户不用知道任务应该拆成几块，主管可以根据执行结果调整下一步。如果检索接口已经存在，就跳过实现；如果测试发现召回错误，就把任务退回给后端专家。 主管模式的风险也明显。主管如果没有足够上下文，会分错任务；如果太相信专家，会把错误结果合并；如果没有预算控制，会无限循环。实践里需要给主管三个硬约束： 每次分配任务必须说明输入、输出和验收标准。 每个专家返回结果必须包含证据或明确失败原因。 主管只能在验收标准满足后合并结果。 主管不是“最聪明的人”，它是流程控制器。它的价值在于让任务状态清楚，而不是在所有专业问题上都亲自裁决。 五、协作模式二：流水线 流水线适合有固定阶段的任务。内容生产、数据清洗、报表生成、客服工单处理、发布检查，都很适合流水线。 以社区文章生产为例： 选题输入 -> 资料检索 -> 观点整理 -> 提纲生成 -> 初稿写作 -> 事实核查 -> 编辑润色 -> 发布检查 -> 输出文件 流水线的优点是稳定，每个阶段的输入输出都可以标准化。资料检索阶段必须输出链接和摘要；事实核查阶段必须输出问题清单；发布检查阶段必须输出字符数、链接数量、目标文件路径。 流水线的缺点是容易僵硬。如果资料不足，不能硬往下走；如果事实核查发现关键论点错误，不能只在末尾修几个字。好的流水线必须允许回退。例如事实核查失败时，回到资料检索；编辑发现结构混乱时，回到提纲；发布检查发现文件路径不对时，回到交付阶段。 LangGraph 这类图工作流适合表达这种回退和分支。相比让模型自由决定所有流程，图式编排能把稳定流程固定下来，让模型只处理需要判断的部分。生产系统里，稳定环节用代码，模糊判断用模型，这是更可靠的搭配。 六、协作模式三：并行生成加评审 有些任务没有唯一答案，比如产品方案、架构选型、营销文案、故障排查。此时可以让多个智能体并行给出方案，再由评审者比较。 并行不是为了制造更多文本，而是为了覆盖不同假设。比如架构选型可以分成： 方案 A：优先复用现有系统。 方案 B：优先长期扩展性。 方案 C：优先最低交付风险。 评审：比较成本、风险、迁移路径、验证难度。 这种模式很有用，但要防止两个问题。 第一个问题是“平均化”。评审者把三个方案糊成一个折中方案，最后失去重点。解决方法是要求评审输出明确取舍：推荐哪个，为什么，不选哪些，代价是什么。 第二个问题是“互相污染”。如果三个生成者共享彼此答案，可能都沿着同一个错误假设走。需要独立生成时，就让它们只共享任务目标，不共享中间答案。等到评审阶段再合并。 并行模式成本高，不适合所有任务。它适合高价值决策、模糊问题、创意问题和历史上容易出错的任务。 七、协作模式四：生成者与批判者 “生成者与批判者”是最容易落地的质量提升模式。一个智能体负责产出，另一个智能体负责挑错。它比完整多智能体团队轻，但效果通常明显。 关键在于批判者不能只说“很好，可以更具体”。它必须按清单检查： 事实：关键说法是否有来源。 完整性：用户要求是否全部覆盖。 一致性：前后是否矛盾。 可执行性：有没有具体步骤、路径、命令或交付物。 安全性：有没有越权、泄露、危险操作。 风格：是否符合目标站点或产品语言。 写作任务里，批判者可以检查是否原创、是否空泛、是否引用过度、是否标题层级混乱。代码任务里，批判者可以检查边界条件、测试缺口、回滚风险、用户体验。运维任务里，批判者可以检查是否误把健康检查当完整验收，是否漏掉真实用户路径。 批判者提出问题后，生成者必须修正。否则“评审”只是仪式。更进一步，可以要求批判者对修正后版本再次检查，直到剩余问题低于阈值或需要用户决策。 八、工具与权限：蜂群必须有边界 多智能体系统一旦接入真实工具，就必须认真处理权限。工具包括搜索、文件、数据库、浏览器、命令行、部署、支付、邮件、CRM、工单、机器人控制等。每个工具都可能造成真实影响。 实践里建议按权限分成四类： 只读工具：搜索、读取文档、查询数据库、查看日志。 草稿工具：生成邮件草稿、创建待审核工单、准备变更计划。 写入工具：修改文件、写数据库、提交表单、创建资源。 高风险工具：删除、付款、部署、发外部消息、改变权限。 不同智能体只拿自己需要的工具。研究员不需要删除文件，评审者不需要发邮件，交付者不一定需要改数据库。权限最小化可以减少模型误判带来的损失。 工具返回也要为协作设计。一个工具结果如果只是“success”，下游智能体无法判断发生了什么。更好的返回应该包含： 执行状态：成功、部分成功、失败、需要确认。 业务结果：创建了哪个对象，修改了哪些字段。 证据：链接、文件路径、日志片段、测试报告。 下一步：是否可重试，是否需要人工确认。 风险：影响范围和可能副作用。 MCP 的价值在这里会变得明显。它把工具、资源和提示能力以统一协议暴露给 AI 应用，适合在团队内复用外部系统能力。但 MCP 不是安全边界本身。接入 MCP 服务器后，仍要做服务来源管理、权限控制、参数校验和审计。 A2A 解决的是另一层问题：不同智能体或不同平台之间怎样互相发现、委派任务和交换工件。A2A 规范里的 AgentCard、Task、Message、Artifact、Part 等概念，说明跨系统协作需要能力描述、任务状态和结果工件，而不是随便发一段自然语言。 一句话区分： MCP：让智能体接工具。 A2A：让智能体接智能体。 编排框架：让应用内部的智能体按流程工作。 九、记忆与共享状态：别让群聊变垃圾场 多智能体系统最容易出现上下文爆炸。每个智能体说一段，工具返回一段，评审再说一段，很快上下文就长到没人看得清。解决办法不是买更大的上下文窗口，而是管理共享状态。 共享状态应该保存结构化工件，而不是完整聊天记录。比如： task_goal：用户目标和硬约束。 research_notes：资料卡片列表。 decision_log：已经做出的关键决策。 open_questions：未解决问题。 artifacts：代码补丁、文档、截图、测试报告。 risks：风险和处理状态。 acceptance：验收标准和当前结果。 每个智能体只读取自己需要的部分。研究员读取目标和开放问题；作者读取资料卡片和提纲；测试员读取交付物和验收标准；交付者读取最终结果和风险。全员共享全部上下文，听起来透明，实际低效。 长期记忆也要谨慎。它适合保存稳定偏好、项目约定、历史失败经验、常用流程。不适合保存临时猜测、未验证结论、敏感凭证。LangGraph 的记忆文档把短期记忆放在会话线程内，把长期记忆放在跨线程存储中，这种分层很值得借鉴。 多智能体还需要“冲突记忆”。当两个智能体结论不一致时，不要让协调者随便选一个，而要把冲突写入状态： 冲突点：到底哪里不一致。 证据 A：第一个结论的来源。 证据 B：第二个结论的来源。 处理方式：继续检索、请用户确认、选择保守方案、延迟决策。 最终决定：采用哪个，为什么。 这样下次复盘时，团队知道当时不是“忘了”，而是有明确取舍。 十、校验机制：没有验收，协作就是聊天 多智能体协作要想稳定，必须把校验前置。不要等最终答案生成后才问“看起来行不行”。每个阶段都应该有验收标准。 资料阶段的验收可以是： 是否优先使用官方文档、论文、厂商文档、项目文档。 是否记录来源链接和检索日期。 是否区分事实、推断和观点。 是否避免只引用二手摘要。 代码阶段的验收可以是： 是否只修改目标范围内文件。 是否符合项目已有风格。 是否补充或运行相关测试。 是否说明未能验证的部分。 写作阶段的验收可以是： 是否覆盖用户要求。 是否有明确读者收益。 是否避免重复和模板化段落。 是否末尾列出参考资料。 交付阶段的验收可以是： 文件是否写入正确路径。 字符数或数据量是否达标。 链接、截图、测试结果是否存在。 改动文件列表是否准确。 这些验收标准可以由规则程序检查一部分，也可以由评审智能体检查一部分。比如字符数、文件路径、测试命令适合程序检查；事实支撑、逻辑一致、用户体验适合智能体检查。不要把所有校验都交给模型，也不要把所有质量问题都幻想成规则能覆盖。 十一、评测：怎么知道蜂群真的比单体好 多智能体系统上线前，必须回答一个问题：它真的更好吗？如果只是成本更高、速度更慢、输出更长，那没有意义。 评测可以从五个维度看。 第一，完成率。给一组真实任务，单智能体和多智能体分别执行，比较最终是否完成。完成不是“回答了”，而是交付物满足验收标准。 第二，错误率。比较事实错误、工具误用、越权动作、格式错误、遗漏需求。多智能体如果只是让文字更漂亮，但工具错误不降，价值有限。 第三，可恢复性。故意加入工具超时、资料不足、输入歧义、权限失败，看系统是否能重试、降级、询问用户或停止。真实工作里，异常比理想输入更常见。 第四，一致性。同一任务重复运行多次，结果是否稳定。τ-bench 提出的 pass^k 思路很有启发：一个智能体单次成功不够，多次稳定成功才接近生产要求。 第五，成本与延迟。多智能体很容易把 token、工具调用和等待时间放大。质量提升必须抵消这些成本。社区项目可以先在高价值任务上使用多智能体，不要把所有简单问答都做成团队流程。 可以建立一个小评测集： 10 个常规任务：应该顺利完成。 10 个边界任务：信息不完整或工具返回异常。 10 个拒绝任务：要求越权、删除、泄露或绕过规则。 10 个回归任务：历史上出过错的真实案例。 每个任务记录： 输入 可用工具 期望交付物 禁止行为 评分标准 单智能体结果 多智能体结果 轨迹摘要 失败原因 LangSmith、LangGraph、AutoGen、CrewAI 等生态都在强调 tracing、evaluation、observability，这不是因为好看，而是因为智能体问题通常藏在过程中。只看最终答案，很多危险动作和错误路径都看不到。 十二、真实场景一：AI 编程团队 AI 编程是多智能体比较适合的场景，因为它天然包含需求理解、代码阅读、修改、测试、审查和交付。 一个小型 AI 编程团队可以这样设计： 协调者：确认任务范围和验收标准。 代码侦察员：阅读相关文件，找调用链和现有模式。 实现者：按最小范围修改代码。 测试员：运行相关测试，补充必要用例。 审查员：检查回归风险、边界条件和用户体验。 交付者：汇总改动文件、测试结果和剩余风险。 注意，代码侦察员和实现者分开很有价值。很多代码智能体失败，是因为没读清楚项目结构就动手。让侦察员先输出“相关文件、现有模式、风险点”，可以减少盲改。 测试员也不能只跑一个健康检查。比如前端改动要看浏览器里的真实用户路径，后端改动要跑相关单测或接口流，AI 功能要验证真实链路而不是 mock 回复。多智能体系统的优势，是可以把这些检查分给不同工作单元，而不是让一个上下文越来越长的模型硬扛。 交付者最后要说清楚： 改了哪些文件。 为什么这样改。 验证了什么。 哪些没验证。 用户下一步可以在哪里看到效果。 这比一句“已完成”可靠得多。 十三、真实场景二：社区内容生产团队 社区内容生产也适合多智能体，但要警惕模板灌水。一个好内容团队不是让多个模型轮流扩写，而是让不同角色守住不同质量线。 可以这样分： 选题员：判断读者关心什么问题。 研究员：联网检索最新资料，优先原始来源。 结构编辑：设计文章路线，避免堆资料。 作者：写原创正文，讲清因果和实践。 事实核查员：检查关键说法和引用。 风格编辑：匹配站点语气，去掉内部术语。 发布检查员：检查 Markdown、字数、链接和文件路径。 这套流程能解决内容生产里几个常见问题： 资料过旧：研究员必须检索最新资料。 观点空泛：结构编辑要求每章解决具体问题。 引用混乱：事实核查员检查来源和说明。 文风错位：风格编辑按站点读者改写。 交付不完整：发布检查员输出路径、字数和来源数量。 内容团队尤其要强调原创。原创不是不看资料，而是不复制资料结构和句子。资料用于建立事实基础，文章要用自己的组织方式解释问题、给出判断和实践步骤。 十四、真实场景三：运维与事故响应团队 运维场景里，多智能体有价值，也更危险。因为工具可能读取日志、重启服务、修改配置、部署版本。这里必须把只读诊断和写入动作分开。 一个安全的事故响应团队可以是： 告警分析员：读取告警和指标，只读。 日志分析员：查询日志和错误样本，只读。 变更分析员：查看最近发布、配置和依赖变化，只读。 诊断协调者：合并证据，提出根因假设。 修复规划员：生成修复步骤和回滚方案。 审批执行员：只有用户确认后才执行写入动作。 复盘员：记录原因、处理过程、预防措施。 这里不能让一个智能体既诊断又直接重启所有服务。真实生产环境需要确认点： 是否影响用户。 修复动作会改变什么。 有没有回滚方案。 谁批准执行。 执行后如何验证。 如果系统还在开发阶段，也应该保持这个习惯。开发环境不是线上，但生产级应用的能力是在开发阶段训练出来的。把权限、追踪、回滚、验收提前设计好，后面才不会靠补丁兜底。 十五、实现建议：从轻量开始 如果你正在做一个多智能体项目，不建议一上来搭一个宏大的平台。可以从轻量版本开始。 第一步，把单智能体做好。让它能稳定调用工具，保存状态，产出可验收结果。 第二步，加一个独立评审者。生成者产出结果，评审者按清单挑错，生成者修正。这一步成本低，收益通常明显。 第三步，把中间工件结构化。不要传整段聊天记录，而是传资料卡片、计划、补丁、测试报告、风险清单。 第四步，再引入协调者。只有当任务分支多、角色多、需要动态调度时，协调者才有价值。 第五步，建立评测集。用真实任务比较单智能体和多智能体，不要只凭感觉判断质量。 第六步，接入协议和框架。工具多、团队多、来源多时考虑 MCP；跨平台智能体协作时考虑 A2A；复杂流程和状态恢复时考虑 LangGraph、ADK、AutoGen、CrewAI、OpenAI Agents SDK 等框架。 这个顺序有一个好处：每一步都能独立带来价值。即使最后没有做成完整蜂群系统，你也已经得到更好的工具契约、评审流程、工件结构和评测集。 十六、几个反模式 反模式一：角色很多，权限一样。五个智能体都能读写所有工具，出了问题没人负责。正确做法是按职责分配工具。 反模式二：所有人共享完整上下文。看似透明，实际噪声爆炸。正确做法是共享结构化工件。 反模式三：评审只说好话。批判者没有硬标准，只会输出“建议更详细”。正确做法是给检查清单和否决权。 反模式四：没有终止条件。系统反复研究、反复修改、反复总结。正确做法是定义预算、验收和停止规则。 反模式五：最终只交付摘要。用户要文件、代码、配置、截图或测试结果，系统只回一段总结。正确做法是把真实交付物作为完成标准。 反模式六：把协议当架构。接了 MCP 或 A2A，不代表系统就会协作。协议只是连接方式，责任边界和评测才是质量来源。 反模式七：把模型当权限系统。提示词说“不要删除文件”不等于系统不能删除文件。正确做法是工具层权限控制和用户确认。 反模式八：没有真实验收。只看 API 返回 200，不走用户路径。正确做法是用真实客户端、真实工具、真实数据样本验证结果。 十七、一个可复用的蜂群协作模板 下面这个模板可以直接用于设计多智能体任务。 任务名称： 用户目标： 硬约束： 最终交付物： 角色列表： - 角色名： 职责： 不负责： 可用工具： 输入： 输出： 验收： 共享工件： - 资料卡片 - 决策记录 - 风险清单 - 测试结果 - 最终交付物 流程： 1. 协调者确认目标和验收。 2. 研究或侦察角色收集证据。 3. 执行角色产出工件。 4. 评审角色检查并给出问题清单。 5. 执行角色修正。 6. 交付角色整理最终结果。 停止条件： - 验收通过。 - 预算耗尽。 - 需要用户确认。 - 发现高风险动作。 - 外部依赖不可用。 评测指标： - 完成率 - 错误率 - 工具误用率 - 重试次数 - 平均成本 - 用户可用性 这个模板最大的作用，是强迫团队从“让几个智能体聊聊”转向“让几个工作单元交付工件”。只要工件清楚、验收清楚，系统就容易调试。没有工件和验收，智能体越多越难排查。 十八、社区实践中的取舍 在 localaihub 这样的社区实践语境里，我们更关心“能不能用起来”，而不是追逐最复杂的概念。很多团队并不需要从第一天就接入完整协议栈，也不需要做跨组织智能体网络。更现实的起点是： 本地模型或云模型先跑通单智能体。 把常用工具封装成清晰接口。 为高价值任务加入评审智能体。 把每次任务的轨迹和交付物保存下来。 从真实失败案例里补评测集。 当工具越来越多时，再考虑 MCP，让工具接入变得标准。当天然需要和外部智能体协作时，再看 A2A。流程复杂、需要恢复和人类确认时，再引入图工作流。不要为了技术名词搭架子，也不要因为系统还小就忽视边界。 蜂群协作最务实的收益，往往来自三个地方： 减少遗漏：不同角色检查不同问题。 降低风险：不同权限防止一个模型越界。 提高可解释性：每个工件都能追溯到责任角色和来源。 这些收益不玄学，也不依赖夸张宣传。它们来自工程纪律。 十九、怎样把蜂群协作接进本地社区项目 社区项目和企业内部平台不一样。社区项目通常资源有限，成员时间碎片化，工具链混合，本地部署和云服务并存。蜂群协作在这种环境里要更务实：优先解决真实协作痛点，而不是搭一套看起来完整但没人维护的平台。 第一个建议是从“本地可见工件”开始。比如把每次智能体任务的资料卡片、计划、补丁、测试结果、截图、最终文档保存到项目目录或任务面板里。这样社区成员不用翻长对话，也能看到发生了什么。工件命名要清楚，最好带任务名、时间和角色。社区协作最怕知识散落在聊天记录里，过几天没人能复盘。 第二个建议是把工具封装成社区可理解的动作。不要给模型暴露一堆内部 API 名称，而是封装成“读取项目 README”“查询最近构建”“打开本地页面截图”“运行指定测试”“生成发布检查清单”。这些动作对人也有意义，对智能体也清楚。工具越贴近社区工作语言，越容易被正确调用。 第三个建议是保留人工接力点。社区项目里，很多事情需要维护者判断，比如是否接受一个架构变更、是否发布新版本、是否修改公共文档口径。智能体可以准备材料，但不要假装自己就是维护者。把需要人决定的问题列成短清单，附上证据和推荐项，协作效率会比长篇解释高得多。 第四个建议是让评审变成常规流程。社区里常见问题是：有人生成了一份很长的内容，但没人有时间逐字检查；有人提交了一段代码，但没有说明测试过什么。可以用评审智能体先做第一轮检查，标出事实缺口、链接失效、格式问题、风险点，再让人看重点。评审智能体不能替代维护者，但能降低维护者的阅读成本。 第五个建议是记录“失败样本”。每次智能体误改文件、引用旧资料、漏掉用户要求、测试没跑、界面文案露出内部字段，都应该进入回归集。社区项目不一定有完整 QA 团队，但可以有一个轻量失败库。下次改提示词、换模型、加工具前，先跑这些任务，看看问题有没有回来。 第六个建议是把多智能体和权限绑定。比如内容仓库里，研究智能体可以联网和读文件，写作智能体只能写指定 Markdown，发布智能体只能生成发布说明，不能直接推送。代码仓库里，侦察智能体只读，执行智能体改工作区，发布智能体需要维护者确认。这样就算某个角色判断错，也不至于影响全部资产。 第七个建议是使用本地优先的验证方式。网页项目要打开本地页面看，文档项目要检查生成文件，脚本项目要跑命令，AI 功能要走真实链路。社区实践最容易变成“看起来有结果”，但真正能帮人的是“我可以打开这个地址”“我可以运行这个命令”“我可以看到这份文件”“我知道哪些地方没验证”。 如果项目已经有任务面板、PM2 服务、Git 仓库、文档目录或本地工具，蜂群协作不需要另起炉灶。把智能体角色接到已有工作流里就够了。研究结果写到文档目录，测试结果贴到任务记录，交付说明放到 PR 或发布帖。AI 团队应该融入社区工作方式，而不是迫使社区迁移到一套陌生流程。 二十、成本控制：别让蜂群变成烧钱机器 多智能体最现实的问题之一是成本。一个智能体查十个网页、另一个智能体读完整上下文、第三个智能体再评审全文，很快 token 和工具调用就会膨胀。成本控制不是上线后再优化，而是设计阶段就要考虑。 第一，能规则检查的不要交给大模型。字符数、文件是否存在、链接格式、JSON schema、测试命令退出码、Markdown 标题层级，这些都适合程序检查。模型应该处理语义判断、取舍和综合，不应该被用来数行数。 第二，能摘要传递的不要传原文。研究员可以把资料整理成卡片，作者读取卡片而不是所有网页全文。测试员可以读取失败摘要和关键日志，而不是完整日志文件。每个角色需要的是完成任务所需信息，不是全部信息。 第三，能小模型处理的不要上强模型。路由、分类、格式检查、简单摘要可以用低成本模型；复杂规划、代码审查、事实冲突判断再用强模型。模型选择要靠评测，不要靠感觉。 第四，并行要有预算。并行生成三个方案适合高价值决策，不适合每个小问题。可以设置“只有任务复杂度高或用户明确要求方案比较时，才启用并行角色”。 第五，重试要有上限。工具失败可以重试，但不能无限重试。模型输出不合格可以返工，但要记录返工次数。超过预算后，系统应该交付已完成部分、说明阻塞原因，或者请求用户决策。 第六，记忆检索要精准。长期记忆很有用，但每次读取太多会增加成本和污染上下文。可以按项目、任务类型、时间和关键词过滤，再让模型只吸收相关片段。 成本控制的目标不是省到不能用，而是把预算花在会提高交付质量的地方。社区项目尤其要注意这一点，因为很多任务的价值并不支持复杂多轮蜂群流程。 二十一、透明度：用户需要证据，不需要内部噪声 蜂群协作系统应该透明，但透明不等于把所有内部日志都展示给用户。用户需要的是能判断结果是否可信的证据，而不是每个模型的自言自语。 好的透明度包括： 资料来自哪里。 哪些工具被用于完成任务。 改动了哪些文件或对象。 哪些测试或检查已经执行。 哪些风险仍然存在。 哪些地方需要用户确认。 不好的透明度包括： 暴露内部 prompt。 展示冗长推理文本。 把工具错误码直接给最终用户。 把每个智能体的聊天原文堆出来。 用内部字段名当界面文案。 社区实践里，可以把透明度做成“交付摘要”。比如： 已完成：写入两篇 Markdown 长文。 证据：文件路径、字符数、参考来源数量。 检查：只改动指定文件，链接已记录，字数达标。 未做：没有发布到线上站点。 下一步：维护者可审阅并决定是否发布。 这种摘要让用户知道结果在哪里、可信度如何、还缺什么。它比“智能体 A 认为，智能体 B 认为”更有用。 二十二、治理：让蜂群长期可维护 多智能体系统如果没有治理，很快会变成一堆没人敢改的提示词和工具。治理不一定复杂，但至少要有几个基本机制。 第一，角色版本管理。每个角色的职责、工具、提示词、输出格式都应该有版本。改了研究员的检索策略，要能知道是哪次改动导致来源质量变化。 第二，工具目录管理。工具要有负责人、权限说明、参数文档、返回结构、废弃状态。下游智能体依赖工具，如果工具字段变了却没人通知，系统会出现隐蔽错误。 第三，评测集维护。每次严重失败都应该沉淀成样本。评测集不是一次性建设，而是系统经验的累积。 第四，记忆清理。长期记忆需要过期、修正和删除。社区项目变化快，旧路径、旧命令、旧负责人、旧模型能力都可能变成错误来源。 第五，安全审计。定期检查哪些角色能访问哪些工具，哪些工具有写入权限，哪些动作缺少确认。权限会随着项目发展慢慢膨胀，需要定期收紧。 第六，交付复盘。每隔一段时间抽样查看成功任务和失败任务，比较成本、质量和用户反馈。不要只盯失败，成功任务也能告诉你哪些角色真正有价值，哪些只是增加流程。 治理的目的不是让系统官僚化，而是让多人协作可持续。社区项目换维护者、换模型、换框架都很正常。只要角色、工具、评测、记忆和权限有记录，系统就能继续演进。 二十三、失败复盘：一次蜂群团队为什么越协作越乱 下面这个复盘很典型。一个社区项目想用多智能体改造文档站：研究员找资料，作者写文档，审查员检查，发布员写入文件。第一次运行看起来很热闹，四个角色都输出了不少内容，但最后交付失败。原因不是模型完全不会做，而是协作设计有缺陷。 第一个问题是目标没有冻结。用户要求写“面向新手的部署教程”，研究员按“架构分析”检索资料，作者又按“产品介绍”写正文，审查员只检查语法，发布员发现风格不对却没有权限回退。四个角色都在工作，但没有同一个目标。修复方式是让协调者在第一步生成任务卡片，写明读者、目标、边界、字数、文件路径、禁止事项和验收标准。后续角色只围绕任务卡片工作。 第二个问题是交接没有工件。研究员把十几个链接和长段摘要直接丢给作者，作者没有时间判断哪些可信，于是挑了最顺眼的材料使用。审查员后来发现来源质量参差不齐，但已经很难定位每个段落来自哪里。修复方式是把研究输出改成资料卡片：每张卡片只保留一个事实点、来源、日期、可信等级和可用章节。作者写作时引用卡片编号，审查员按编号回查来源。 第三个问题是评审没有否决权。审查员指出“缺少安装失败处理”和“没有说明回滚”，但发布员仍然把文档写入最终路径。结果用户按文档操作时卡在依赖安装。修复方式是把评审结果分成阻断问题和建议问题。阻断问题未解决时，协调者不能进入发布阶段。建议问题可以进入后续迭代，但必须出现在交付说明里。 第四个问题是发布员承担了太多判断。发布员本来只负责写文件和统计结果，却被迫判断文章结构、技术事实和用户体验。角色职责混乱后，系统看似有人兜底，实际没人负责。修复方式是让发布员只做机械交付检查：目标路径、文件存在、格式、字数、链接数量、改动范围。内容判断交给编辑和审查员。 第五个问题是没有失败回路。一次失败后，团队只改了提示词，让每个角色“更认真”。下一次又在别的地方出错。真正修复应该把失败写入回归样本：目标漂移样本、资料卡片缺失样本、评审阻断样本、发布越权样本。以后每次改流程，都先跑这些样本。 这次复盘给出的经验很直接：多智能体不是让更多模型参与，而是让每个模型少做一点、做清楚一点。目标卡片、资料卡片、阻断评审、发布检查、失败回归，这些机制比角色名字重要得多。 二十四、协作协议细节：任务卡、工件卡和评审卡 如果不想一开始接入复杂协议，也可以先在项目内部定义三张卡。它们不依赖框架，却能显著提升协作质量。 任务卡用于冻结目标： 任务标题： 读者或用户： 最终交付物： 目标路径或目标系统： 硬约束： 可用资料： 禁止行为： 验收标准： 需要人工确认的点： 工件卡用于传递中间结果： 工件类型：资料、代码、测试、截图、风险、正文。 生产角色： 输入来源： 核心内容： 适用范围： 不确定点： 下游使用建议： 评审卡用于推动返工： 评审对象： 通过状态：通过、带条件通过、不通过。 阻断问题： 建议问题： 证据： 需要返工的角色： 返工完成标准： 这三张卡解决三个痛点。任务卡防止目标漂移，工件卡防止上下文变成噪声，评审卡防止问题只停留在建议层面。无论后面使用 LangGraph、AutoGen、CrewAI、ADK，还是自写轻量编排，这些结构都能复用。 内部协议还要约定谁能改卡。任务卡通常只能由协调者根据用户输入修改，重大修改要用户确认；工件卡由生产角色创建，下游可以引用但不能静默改写；评审卡由评审角色创建，协调者负责决定返工或放行。权限越清楚，协作越少扯皮。 二十五、落地到一天工作流：从早会到交付 把蜂群协作放进一天真实工作里，可以很简单。早上维护者给出任务：“补齐本地部署文档，要求新用户能在三十分钟内跑起来。”协调者生成任务卡，确认目标路径、读者和验收方式。研究员检查现有 README、安装脚本、常见报错和依赖版本，输出资料卡片。作者根据资料卡片写正文，不直接使用未经确认的网页内容。 中午前，测试员按文档从干净环境执行一遍，记录卡住的步骤、缺失依赖和命令输出。作者只修正文档，不改脚本；如果必须改脚本，协调者把任务升级给工程角色。下午，审查员检查文档是否覆盖安装、配置、启动、验证、常见失败和卸载或恢复。编辑检查面向新用户的表达，去掉内部昵称和维护者才懂的缩写。发布员写入指定文件，统计字数、链接、改动范围和未验证项。 这条工作流没有神秘之处，却比单个智能体直接写文档稳得多。每一步都有工件，每个问题都有归属，每个角色都不需要读完整历史。更重要的是，维护者可以随时介入：如果测试员发现脚本缺陷，维护者决定是否扩大任务；如果资料冲突，维护者裁决使用哪个版本；如果发布时间紧，维护者决定哪些建议延期。 社区实践不需要追求“全自动”。很多时候，最有价值的是把人从重复整理中解放出来，同时保留关键决策权。蜂群协作应该让维护者更容易看清事实和风险，而不是让维护者去管理一群会跑偏的模型。 还有一个容易被忽略的边界：蜂群协作不是越多角色越好。小任务如果拆成十几个角色，协调成本会吞掉收益，模型还会为了证明自己有价值而制造不必要的建议。社区项目可以先固定四个角色：协调者、执行者、评审者、发布者。只有当任务需要独立调研、独立测试或安全审查时，再临时增加研究员、测试员和安全员。这样既保留多智能体的交叉校验，也避免把简单事情做成复杂流程。 二十六、结语：让智能体像团队一样交付 多智能体团队不是给模型套几个人设，也不是让它们在群聊里互相讨论到天亮。它应该像一个小型工作队：知道目标，分清职责，使用工具，交接工件，互相校验，最后把结果交到用户手里。 蜂群协作真正难的地方，不是让模型说话，而是让系统有边界、有证据、有验收。MCP、A2A、LangGraph、AutoGen、CrewAI、OpenAI Agents SDK、Google ADK 这些工具和协议都在推动生态成熟，但它们只是基础设施。真正决定质量的，仍然是你怎样定义任务、怎样设计工具、怎样管理记忆、怎样分配权限、怎样评测交付。 如果你准备在项目里引入多智能体，建议从一个简单问题开始：这个任务如果交给真实团队，谁负责调研，谁负责执行，谁负责检查，谁负责交付？把这个答案写清楚，再让智能体去做。这样做出来的蜂群系统，才不是玄学，而是一套可以复盘、可以改进、可以持续交付的 AI 工作方式。 参考资料 OpenAI：The next evolution of the Agents SDK：介绍 OpenAI Agents SDK 在工具、handoff、MCP、skills、AGENTS.md 和追踪能力上的演进，用于理解最新智能体基础设施。 OpenAI Agents SDK 文档：Handoffs：说明智能体之间如何移交任务，用于主管加专家模式。 OpenAI Agents SDK 文档：Tools：说明托管工具、函数工具和智能体即工具，用于工具权限和交付设计。 Model Context Protocol 官方文档：说明 MCP 如何连接 AI 应用与外部工具、数据和工作流，用于工具协议部分。 A2A Core Protocol Specification：说明 AgentCard、Task、Message、Artifact、Part 等概念，用于跨智能体协作部分。 Linux Foundation：Agent2Agent Protocol Project：说明 A2A 项目的开放治理和跨平台目标。 Google Agent Development Kit：介绍 ADK 的多智能体、图工作流、会话、记忆和评测能力，用于工程落地部分。 Google ADK：Multi-Agent Systems：说明组合多个智能体、层级关系和工作流智能体，用于多智能体模式。 LangGraph Multi-agent 文档：说明 supervisor、handoff、network 等多智能体架构，用于协作模式对比。 LangGraph Memory 文档：说明短期记忆、长期记忆和生产 checkpointer，用于共享状态和记忆部分。 LangSmith Evaluation：说明智能体轨迹评测、工具调用评测和自动化评分，用于评测部分。 Microsoft AutoGen 文档：Multi-agent Conversation Framework：介绍多智能体会话、工具使用和人工反馈，用于团队协作模式。 CrewAI Introduction：介绍 Crews、Flows、角色和流程，用于多智能体团队编排对比。 ReAct: Synergizing Reasoning and Acting in Language Models：提出推理与行动交替，用于解释智能体闭环。 Reflexion: Language Agents with Verbal Reinforcement Learning：讨论通过语言反馈和情景记忆改进智能体行为，用于复盘和记忆部分。 Toolformer: Language Models Can Teach Themselves to Use Tools：讨论模型学习 API 调用行为，用于工具能力部分。 AgentBench: Evaluating LLMs as Agents：提出多环境智能体评测，用于评测集设计。 GAIA: a benchmark for General AI Assistants：强调真实助手任务中的推理、工具和多模态能力，用于真实任务评测。 τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains：提出面向真实领域工具交互的可靠性评测，用于一致性和 pass^k 思路。 Agent-SafetyBench: Evaluating the Safety of LLM Agents：讨论工具型智能体的新安全风险，用于权限和安全评测。 A survey of agent interoperability protocols：比较 MCP、A2A 等协议，用于协议关系说明。

社区里经常有人问一个问题：我已经会写提示词了，还需要学什么？这个问题在 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 - 关于语言智能体通过语言反馈改进表现的论文。

这句有点狠，但对。

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

越早补越便宜。

我们加访问时间和来源快照字段。

我们准备加 PR 模板：AI 辅助、验证命令、风险点。

模型接口通常不是最难的部分。

这句话可以留着。

少做“看起来很 AI”的图，多做能点开的证据。

这个方向好。具体的不确定才有用。

这个流程靠谱。

先透明，再限制。别突然卡用户。

这个边界清楚。

还有透明背景别带奇怪边缘，深浅背景都要测。