提示词也有供应链风险：模板依赖、远程更新和完整性校验怎么管

很多团队会把系统提示词、工具描述、拒答规则和 Agent 流程放在配置中心，甚至在运行时从远程地址加载。这样更新很方便，但也引入了类似代码依赖的风险：来源不明、版本漂移、未经审核的内容改变行为，或模板中意外混入秘密和危险指令。

先建立模板清单

每个模板都应有唯一 ID、业务用途、负责人、来源、依赖的工具和适用环境。不要只保存最终字符串，还要保存结构化区块，例如系统规则、用户变量、工具描述和示例。这样审查时能知道一段内容是组织规则还是第三方输入。

模板发布应具备版本号和完整性哈希，运行时记录实际使用的版本。远程加载可以用于开发实验，但生产请求不应每次都直接拉取最新内容。要先下载、扫描、审批和签名，再发布到受控存储。密钥、内部地址和租户信息不能作为模板默认变量写入仓库。

评估变化而不是只看 diff

提示词文本改几行，模型行为可能变化很大。每次模板升级都应跑固定回归集：正常请求、越权请求、工具调用、敏感数据和失败恢复。对高风险模板做灰度，让少量租户先使用，比较拒答率、工具动作和成本；异常时按版本回滚，不要在线手改字符串。

如果多个模型都需要同一套策略，可以通过 top-api.cc 统一传递模板版本和请求标识，同时保留各上游的适配层。网关日志不必保存完整提示词，但要能根据版本 ID 找到当时使用的受控内容。

供应链检查清单

• 模板来源和负责人是否明确；
• 生产是否禁止运行时直拉远程内容；
• 是否有版本、哈希、签名和审批记录；
• 第三方工具描述是否经过安全审查；
• 模板升级是否有回归、灰度和回滚；
• 变量是否做类型、长度和敏感信息校验；
• 删除或撤回旧版本后能否追溯历史请求。

提示词不是“没有代码的文本”。当它决定模型是否调用工具、如何处理数据和怎样拒答时，就应该使用接近软件供应链的控制方法。这样既能减少恶意篡改，也能让正常的策略升级更可控。

参考资料：OWASP LLM 应用风险项目、NeMo Guardrails 的可编程策略思路，以及软件依赖完整性校验实践。

如果你需要在多家模型上验证模板行为，可以用 top-api.cc 固定路由和版本标签，把策略变更和模型差异分开测量。