在本页面
设想商品目录周一更新，助手的提示中却仍是周五的清单。团队更新提示，但旧清单的另一份副本还在训练模型的示例里。于是助手在同一次对话中，给出一个当前答案和一个过时答案。
这是示例性失败，但机制很常见：同一事实被放在了不止一个地方。
关于提示、检索和模型权重的讨论划出有用的边界。提示告诉助手如何行事；检索把当前且可引用的知识带入具体任务；模型调整能教会稳定模式。若把三者看作一架梯子，从提示到检索，答案仍错就微调，就会误诊事实错误。
提示不是好的目录
提示很吸引人，因为容易编辑。加一段，下一次请求就带上它。这种方便掩盖两个成本：即使无关，每次调用都要发送这个事实；提示越长，越难知道模型用了规则的哪份副本。
“发送营销活动前先请求批准”之类持久指令应该靠近代理。某个商店当前的自定义字段列表则不该如此。管理员新增属性后，它可能改变；不同租户可能不同；一个工作区可以看，另一个工作区可能被禁止。
Brevo 连接器指南说明字段定义对联系人同步为何重要。如果目标账户未声明某属性，仅凭名称看似合理的映射也可能无法产生预期字段。代理应查看账户当前的契约，而不是回忆训练中通用的字段列表。
有用的检索结果应小到可以质疑。它要说明适用的账户或租户、读取时间、描述的操作或字段。如果两个检索片段互相矛盾，系统应暴露冲突，而不是悄悄选措辞更流畅的一份。下一步可能是重新查询或审核，不是更强硬地改写提示。
带着范围检索事实
有用的知识记录不只有文字。它还需要来源、版本或检索时间、账户范围，以及清楚的删除或替换方式。不能把一个商家账户的字段定义变成另一个商家的通用规则。
关于联系人属性的问题，可以检索回答它的最小片段：字段名、类型及其所在账户。答案能指回来源。若映射失败，团队可追问事实是否过时、是否返回了错误账户的结果，或模型是否误解了正确片段。
这些问题的修法不同。修改提示修不好跨越租户边界的检索过滤器。更大的模型也无法提供无人检索过的属性定义。
MCP 说明介绍代理如何查询工具。工具应返回相关契约，应用负责强制谁可查看。“不要泄露其他租户”的文字指令不能替代限定范围的查询。
这样的分工也让修复更快。目标字段改名，就更新模式来源并使受影响映射失效。代理反复误解稳定指令，就修改指令或测试有针对性的训练。若检索器选错账户，修改模型权重只会错过原因。每类错误都有不同的负责人和修复路径。
- 持久指令
助手应如何行事
- 限定范围的检索 账户 · 版本 · 时间
现在什么是真实的
- 映射决策
为本任务使用当前事实
- 受约束的写入
代码检查许可与范围
模式稳定后再教给模型
合理的反对意见是：“如果某个事实一直用，为什么不训练进更小的模型？”仅有重复还不够。事实必须在两次模型更新之间一直正确，模型还必须能区分不同场景。
稳定的分类风格最终可能值得调整。供应商当前字段列表却不适合。即使很少变化，一次过时答案也可能把错误映射施加到许多记录。让事实留在可供人检查和更新的地方。
来源讨论还警告，别用检索解决每一种推理失败。如果模型无法正确比较两份相关文档，再加五十份也教不会它推理。先问正确片段是否到达，再问对片段的判断是否合理。
对集成构建者，这形成一套修复顺序：找出错误说法；检查检索到的字段或 API 片段；核对账户和版本；必要时修正来源或检索；重新测试决策。只有之后才考虑换模型。
维护真实知识层有成本：来源更新、访问检查、引用。但收益是事实可以在一处更正。
变化的契约不该等待模型把旧的忘掉。
常见问题
代理提示应该放什么？
少量关于行为与边界的持久指令。变化的目录、租户专属字段列表或当前供应商规则，应在需要时从获准来源检索。
为什么不根据当前文档微调模型？
微调可能把变化的事实写入难以检查和更新的权重。先保证决策时检索并引用了正确文档。
事实答错后应该如何修复？
检查来源文档及其版本、检索过滤器和返回片段。修改模型之前，先更正事实或检索路径。