每个租户的提示词编译:当你的系统提示词变成构建产物时
当一个多租户 SaaS 团队在其系统提示词(system prompt)中添加第三个 if tenant_industry == "healthcare" 分支时,那一刻他们其实已经在不经意间为自己聘请了一位编译器工程师。没有人申请过这个人头(headcount),也没有人事先规划过这项工作。团队以为自己在交付一个功能,实际上交付的是一套构建系统,而这套系统仅靠 f-strings 勉强维系。
任何试图将 AI 功能推广到具有哪怕轻微差异的客户群体的团队,最终都会撞上同一堵墙。租户 A 属于医疗行业,需要符合 HIPAA 标准的回答框架。租户 B 属于法律行业,需要严格的引用规范。租户 C 是购买了自定义安全准则的大型企业。租户 D 是免费层级用户,使用默认设置。最直觉的做法是用运行时条件语句(runtime conditionals)处理差异,这些条件不断嵌套,直到除了作者之外没人能读懂这个提示词。第二种直觉——也是大多数团队在撞墙后得出的方案——是提示词编译(prompt compilation):规范的“提示词”不再是一个字符串,而是一个源 码产物(source artifact),最终触达模型的则是编译后的输出。
从字符串到源码产物的转变在代码层面改动很小,但在运维层面影响巨大。你已经构建了一个编译器。你现在拥有了编译器所拥有的一切:无法直接对应到编译后差异的源码级 diff、上游模板更改时必须正确失效的构建缓存,以及一套极其复杂的调试方案——当客户反馈输出错误时,你必须重建出产生该输出的精确编译后的提示词。大多数团队只为“编译”这一功能标了价,却忘记了为“编译器”本身买单。
瓶颈:当租户超过三个,条件语句便不再奏效
第一个针对租户的变动是无伤大雅的。第二个也还好。但到了第三个,提示词就开始扭曲了。到第五个时,系统提示词已经变成了一堵谁也无法审计的嵌套条件墙。我观察过每个陷入这种困境的团队,其模式如出一辙:有人在 if 后面添加了一段特定于租户的内容,有人添加了一个功能开关(feature toggle)的标志,安全团队添加了特定行业的免责声明,于是提示词开始产生“人格分裂”。
这种方法失效的原因并非审美问题,而是运维问题。每一个条件分支都是提示词运行时行为的一个分支,而你的评估集(eval set)必须覆盖所有分支组合,才能确保改动不会引起退化。当提示词有八个独立的条件时,你的评估覆盖范围问题是组合爆炸式的,而非线性增长。大多数团队会悄悄停止评估那些罕见的分支, 并在六个月后发现医疗行业的租户一直在接收法律行业的引用规则,因为预发布环境下没人触发过那个分支。
编译是结构化的解决方案。你不再拥有一个带分支的提示词,而是拥有模板化的章节、特定租户的覆盖层(overlays)、基于能力标志(capability-flagged)的包含项以及 A/B 测试分支,这些内容在配置部署时组合成特定于租户的最终提示词。编译后的产物是针对每个租户的扁平字符串。评估的重点变成了编译后输出的矩阵,而不是源码级分支的笛卡尔积。
你真正构建的东西:一个背负所有技术债的编译器
编译流水线解决了条件爆炸的问题,但它也继承了真实编译器所带来的全部使用成本,而大多数团队直到出问题时才会察觉到这一点。
源码到二进制的调试。 客户反馈助手说了错话。工程师拉取了提示词源码却无法复现故障,因为源码并不是实际运行的内容。运行时运行的是由源码、租户配置、当时激活的功能开关以及编译缓存状态共同衍生的编译产物。复现失败意味着需要重建这一切。如果你不随追踪记录(trace)一起存储编译后的产物,你就是在通过阅读源码并猜测 LLVM 优化过程来调试 Rust 二进制文件。
构建缓存失效。 当一个共享的基础模板发生变化时,每一个依赖该模板的租户编译提示词都需要重新编译和重新评估。如果缓存键(cache key)出错了,你可 能会给一个租户发送过时的提示词,而其他租户则得到了新的——而你会在客户投诉中而不是在 CI 中发现这一点。缓存失效是计算机科学领域著名的两大难题之一,而你刚刚在提示词领域继承了它。
租户级评估面。 评估集必须对编译后的输出进行评分,而不是源码模板,因为源码在脱离编译上下文时毫无意义。这意味着评估流水线需要每个租户的固定配置(fixture):针对你支持的每个租户,在特定租户的编译提示词和预期行为下运行评估集。一个支持 40 个租户的团队现在拥有 40 套必须保持全绿的评估套件,对共享模板的任何修改都会引发 40 次重新验证。
版本控制现在是二维的。 请求的精确行为取决于组合在一起的模板版本和租户配置版本。如果你的追踪记录只记录了其中之一,你只能回答一半的“为什么会发生这种情况”。大多数团队只记录代码版本,因为那是传统软件开发的肌肉记忆,而当法务要求他们复现三周前某个特定租户的行为时,他们才会发现这个鸿沟。
未定价的成本:账单究竟是如何送达的
那些将租户间差异仅视为“配置”的团队,在第一天是不会收到账单的。账单会在第六个月到来,并以三种形式呈现。
- https://agenta.ai/blog/cicd-for-llm-prompts
- https://agenta.ai/blog/prompt-versioning-guide
- https://latitude.so/blog/ci-cd-for-llms-best-practices
- https://www.braintrust.dev/articles/what-is-prompt-management
- https://langwatch.ai/blog/what-is-prompt-management-and-how-to-version-control-deploy-prompts-in-productions
- https://www.confident-ai.com/knowledge-base/best-ai-prompt-management-tools-with-llm-observability-2026
- https://dspy.ai/
- https://github.com/stanfordnlp/dspy
- https://arxiv.org/html/2507.03620v1
- https://aws.amazon.com/blogs/machine-learning/build-a-multi-tenant-generative-ai-environment-for-your-enterprise-on-aws/
- https://dev.to/chen115y/how-id-build-a-multi-tenant-digital-employee-platform-multi-llm-routing-approval-gates-mcp-and-3fg0
- https://brimlabs.ai/blog/why-mcp-is-crucial-for-building-multi-user-multi-tenant-llm-applications/
- https://www.langchain.com/articles/llm-evals
- https://hamel.dev/blog/posts/evals-faq/
- https://learn.microsoft.com/en-us/azure/machine-learning/prompt-flow/how-to-integrate-with-llm-app-devops
