通过模块化提示转译构建可扩展的AI代理

# 构建可扩展的 AI 智能体：模块化提示词编译 来源：https://developers.googleblog.com/building-scalable-ai-agents-with-modular-prompt-transpilation/ 当你初次构建 AI 智能体时，一个单一、整体的系统提示词通常就足够了。你有一些指令，或许一两个工具定义，所有内容都保存在一个可读的文件中。 但随着你在生产环境中使用它们，这种格式就会彻底失效。团队开始叠加安全策略、领域特定规则、格式要求和升级行为。突然之间，你的整个智能体控制平面都塞进了一个指令文件里，这正是问题的开始。 这是一个经典的软件工程扩展问题。当你把所有关注点都推入一个文件时，你就失去了对系统进行推理的能力。协作变得极为困难，测试变得棘手，而为改进一个工作流所做的微小改动可能会悄然破坏另一个。 在生产规模下，提示词的可维护性就是智能体的可靠性。 ## **为什么整体式提示词会崩溃** 我们通常看到当提示词增长到一定规模时会出现三种主要失败模式： 1. **不明确的影响范围：** 在标准软件工程中，评审者很容易通过模块边界、调用点和测试来推断变更的影响范围。但系统提示词的差异分析更难。添加一个句子可能会在整个智能体中产生意想不到的副作用，这往往难以预测或测试。 2. **复制粘贴导致的漂移：** 随着组织规模扩大，许多团队最终会为各种应用复制共享逻辑，例如内部服务使用说明、PII 处理、安全策略或升级协议。这导致了同一功能的复制粘贴或多个版本，从而产生不一致。 3. **延迟的运行时错误：** 为了管理这种蔓延，团队常常采用临时字符串格式化或简单模板。虽然这有助于编写，但它将错误检测推迟到了运行时。你可能部署了一个提示词，只有当触发某个很少使用的工作流时才会因为缺少变量或无效的导入路径而失败。 模板是一个好的开始，但还不够。生产系统需要确定性构建、静态验证和 CI/CD 集成。 ## **将提示词视为软件制品** 这里的解决方案是将提示词视为构建制品，而不是静态文本。 与其维护一个整体的提示词文件，你可以编写模块化的技能文件。这允许你缩小每个文件的范围并封装特定行为，从而让团队能够分离关注点并独立迭代组件。 一个顶层的智能体提示词模板可能看起来像这样： `` # agents/sre_agent.prompt.md（提示词模板文件） {% include "shared/safety.prompt.md" %} {% include "shared/tool_usage.prompt.md" %} 你是一名 SRE 分类智能体，在 {{ environment }} 环境中运行。 {% if allow_remediation %} 你可以建议补救步骤，但破坏性操作需要人工批准。 {% else %} 你可以检查、总结和解释问题，但不要建议补救操作。 {% endif %} {% macro bullet_section(title, items) %} ## {{ title.rstrip() }} {% for item in items %} - {{ item.rstrip() }} {% endfor %} {% endmacro %} {{ bullet_section("需要调查的步骤", [ "检查最近的部署事件", "查看服务指标中延迟或错误率的变化", "审查日志中重复出现的失败模式" ]) }} `` 纯文本 复制 这让你两全其美。模板层允许你组合共享指令、注入环境特定值以及使用宏。但对于构建系统来说，每个包含项都是一个依赖，每个变量都是一个需求。结果是一个确定性的、完全渲染的制品，你可以在它到达模型之前进行测试、审计和差异比较。然后我们可以使用一个编译器来解析模板导入，生成一个可供智能体使用的文件。 例如，如果 environment = production 且 allow_remediation = true，编译后的制品将如下所示： `` 你是一名 SRE 分类智能体，在 production 环境中运行。 你可以建议补救步骤，但破坏性操作需要人工批准。 ## 需要调查的步骤 - 检查最近的部署事件 - 查看服务指标中延迟或错误率的变化 - 审查日志中重复出现的失败模式 `` 纯文本 复制 一个高层次的编译管道看起来像这样： 图1 ## **构建时验证是强制性的** 生产级别的编译器应该在运行时之前捕获错误。 我们应在构建过程中运行缺失导入、未定义变量和循环依赖的验证检查。依赖图在这里非常有价值，强化了对可靠模板引擎的需求。如果你将每个提示词片段视为有向图中的一个节点，你可以轻松捕获那些会在生产环境中导致静默失败的递归导入。 图2 这还可以实现漂移检查。你可以设置你的 CI 管道，使其能够从源代码（称为黄金文件）重新生成编译后的提示词，并与当前提交的制品进行比较。如果输出不同，构建就会失败。这确保了你的仓库中的代码与生产环境中运行的代码完全一致，消除了源文件与部署制品之间的差距。 图3 ## **动态技能与智能体编写的更新** 随着你的模块化提示词片段技能库不断增长，你未必希望每个智能体每次都加载所有技能。这样做会消耗 token，并引入噪音，可能干扰智能体在特定任务上的表现。 一个更好的架构模式是利用渐进式披露。也就是将稳定的控制平面与任务特定的上下文分离。编译后的基础提示词应强制执行不可协商的行为，如身份和安全边界。然后，在运行时，智能体可以使用一个工具动态检索仅执行当前任务所需的特定技能模块；这有助于减少上下文耗尽，并保持智能体专注于其任务。 图4 一旦你拥有这个模块化系统，你将解锁一个强大的工作流：智能体可以帮助维护它们自己的指令层，从而创建一个自我维持的智能体系统。当智能体解决了一种新类型的事件时，理论上它可以草拟一个新的技能模块，更新相关的导入，并创建一个拉取请求。 智能体并非实时修改其自身指令；它是在提议一个代码变更。然后编译器将该提议提交给与其他任何代码变更相同的验证和审查流程。一名人类评审者可以检查 PR，运行评估，然后合并这个变更。 图5 ## **结论** 生产级的提示词编译器将提示词工程重新定义为构建系统问题。 当我们构建模块化技能文件时，我们可以像对待标准软件基础设施一样解析依赖、验证导入并执行漂移检查。只要这些变更通过我们现有的验证和审查流程，智能体就能够对其自身逻辑提出改进建议。 随着 AI 智能体深度集成到关键工作流中，它们的指令层需要与我们要求软件具有的可靠性标准相同。提示词不应仅仅被编辑，而应被构建、验证、版本化和部署。