模块化 Prompt 转译：让系统指令可复用可验证

当你第一次构建 AI Agent 时，使用一个单体式 system prompt 通常没什么问题。你只有少量指令，可能再加上一两个工具定义，所有内容都放在一个易于阅读的文件中。

但当你开始将它们用于生产环境时，这种形式很快就会失效。团队会不断叠加安全策略、特定领域的规则、格式要求和升级处理机制。突然之间，整个 Agent 的控制平面都塞进了同一个指令文件，而麻烦也正是从这里开始的。

这是一个典型的软件工程扩展性问题。当你把所有关注点都塞进单个文件时，就会失去对系统进行清晰推理的能力。团队协作变成噩梦，测试变得难以驾驭，原本为了改进某个工作流而进行的一处微小改动，也可能悄无声息地破坏另一个工作流。

在生产规模下，prompt 的可维护性直接决定了 Agent 的可靠性。

为什么单体式 prompt 会失效

当 prompt 增长到一定规模后，我们通常会看到三种主要的失效模式：

影响范围不透明： 在传统软件工程中，审查者可以通过模块边界、调用位置和测试，轻松判断一项变更的影响范围。但 system prompt 的 diff 更难分析。新增一句话，就可能给整个 Agent 带来意料之外的副作用，而这些影响通常很难预测或测试。

复制粘贴导致的漂移： 随着组织规模扩大，许多团队最终会为不同应用重复实现共享逻辑，例如内部服务使用说明、PII 处理方式、安全策略或升级处理协议。这会造成复制粘贴，或者让同一功能出现多个版本，最终导致不一致。

延迟到运行时才暴露的错误： 为了控制不断膨胀的内容，团队往往会采用临时拼凑的字符串格式化方案或简单模板。虽然这能让编写过程更方便，却也把错误检测推迟到了运行时。由于缺少变量或 import 路径无效，你可能部署了一个只有在触发某个极少使用的特定工作流时才会失败的 prompt。

模板是一个不错的起点，但仅有模板还不够。生产系统需要确定性的构建、静态验证以及 CI/CD 集成。

像对待软件制品一样对待 prompt

这里的解决方案，是把 prompt 当作构建制品，而不只是静态文本。

你可以编写模块化的 skill 文件，而不是维护一个单体式 prompt 文件。这样既能缩小每个文件的职责范围，又能封装特定行为，让团队得以分离关注点，并分别迭代各个组件。

顶层 Agent prompt 模板可能如下所示：

# agents/sre_agent.prompt.md (prompt template file)

{% include "shared/safety.prompt.md" %}
{% include "shared/tool_usage.prompt.md" %}

You are an SRE triage agent operating in the {{ environment }} environment.

{% if allow_remediation %}
You may recommend remediation steps, but destructive actions require human approval.
{% else %}
You may inspect, summarize, and explain the issue, but do not recommend remediation actions.
{% endif %}

{% macro bullet_section(title, items) %}
## {{ title.rstrip() }}
{% for item in items %}
- {{ item.rstrip() }}
{% endfor %}
{% endmacro %}

{{ bullet_section("Required investigation steps", [
  "Inspect recent deployment events",
  "Check service metrics for latency or error-rate changes",
  "Review logs for repeated failure patterns"
]) }}

这样一来，你就能兼得两者的优势。模板层允许你组合共享指令、注入特定环境的值，并使用宏。对于构建系统而言，每个 include 都是一项依赖，每个变量都是一项必要条件。最终得到的是一个确定性的、完全渲染完成的制品，你可以在它到达模型之前对其进行测试、审计和 diff。随后，我们可以使用 transpiler 解析模板中的 import，生成可供 Agent 直接读取的文件。

例如，如果 environment = production 且 allow_remediation = true，那么 transpile 后的制品将如下所示：

You are an SRE triage agent operating in the production environment.

You may recommend remediation steps, but destructive actions require human approval.

## Required investigation steps

- Inspect recent deployment events
- Check service metrics for latency or error-rate changes
- Review logs for repeated failure patterns

高层级的 transpilation 流水线大致如下：

构建时验证不可或缺

生产级 transpiler 应当在运行时之前捕获错误。

我们应该在构建过程中执行验证检查，找出缺失的 import、未定义的变量和循环依赖。依赖图在这里非常有价值，也进一步说明了为什么需要一个可靠的模板引擎。如果把每个 prompt 片段视为有向图中的一个节点，就可以轻松发现递归 import，避免它们在生产环境中引发无提示的故障。

这也让漂移检查成为可能。你可以配置 CI 流水线，使其能够根据源文件重新生成 transpile 后的 prompt（称为 golden file），并与当前已经提交的制品进行比较。如果输出不同，构建就会失败。这样可以确保代码仓库中的内容与生产环境中实际运行的内容完全一致，消除源文件与已部署制品之间的差距。

动态 skill 与 Agent 编写的更新

随着由模块化 prompt 片段组成的 skill 库不断增长，你未必希望每个 Agent 每次都加载所有 skill。这样做会消耗 token，并引入可能干扰 Agent 特定任务表现的噪声。

一种更好的架构模式，是利用渐进式披露。也就是把稳定的控制平面与特定任务的上下文分离开来。编译后的基础 prompt 应当强制执行身份和安全边界等不可妥协的行为。随后在运行时，Agent 可以使用工具，动态获取当前任务所需的特定 skill 模块；这既能减少上下文耗尽的问题，也有助于让 Agent 专注于当前任务。

拥有这套模块化系统之后，你就解锁了一种强大的工作流：Agent 可以协助维护自己的指令层，从而帮助构建一个能够自我维持的 Agentic 系统。当 Agent 解决了一种新类型的事故时，理论上它可以起草一个新的 skill 模块、更新相关 import，并创建一个 pull request。

Agent 并不是在实时修改自己的指令，而是在提出一项代码变更。随后，transpiler 会对这项提案执行与其他代码变更同等严格的验证和审查。人工审查者可以检查 PR、运行 eval，并合并变更。

生产级 prompt transpiler 将 prompt engineering 重新定义为一个构建系统问题。

构建模块化 skill 文件后，我们便能像处理标准软件基础设施一样解析依赖、验证 import，并强制执行漂移检查。只要相关变更需要经过现有的验证和审查流程，Agent 就能够为自身逻辑提出改进建议。

随着 AI Agent 深度融入关键工作流，它们的指令层也需要达到我们对软件所要求的同等可靠性标准。prompt 不应该只是被编辑，还应该被构建、验证、版本化和部署。