提示词越来越像代码。早期做一个 Agent，把规则、工具说明、输出格式都写进一个系统提示词里，还能勉强维护；一旦进入生产，安全策略、领域规则、升级行为、格式要求不断叠加，单个大提示词就会变成难审查、难测试、难复用的控制层。
Google Developers Blog 在 2026 年 7 月 16 日发布 Building scalable AI agents with modular prompt transpilation，提出把提示词当成构建产物来管理。文章认为，生产级系统需要确定性构建、静态校验和 CI/CD 集成，而不只是临时拼字符串。
事实梳理
Google 提到，单体提示词在规模化后常见三个问题：变更影响范围不清、复制粘贴导致漂移、模板错误延迟到运行时才暴露。它给出的方向，是把提示词拆成模块化 skill 文件，用模板和 transpiler 解析 include、变量和宏，生成最终给 Agent 使用的完整提示词。
文章还强调构建时校验，包括缺失导入、未定义变量、循环依赖和 golden file 漂移检查。也就是说，提示词变更应该像代码一样进入构建、审查和测试，而不是直接在线上改一段文字。
影响分析
这对 Agent 团队的影响很实际。很多生产问题并不是模型能力不足，而是提示词层混乱：安全规则被复制成多个版本，某个场景新增一句话影响了其他流程，临时变量拼错导致少数任务才失败。
如果把提示词拆成模块，团队就能把稳定控制层、任务技能、工具规则和输出格式分开维护。这和 AI Agent 记忆机制、任务规划、Agent 变更单 都能接上：上下文归上下文，指令归指令，变更归变更。
老达点评
我觉得这篇文章的关键提醒是：提示词工程正在从“写得好不好”变成“能不能维护”。一个团队如果每天都在复制系统提示词、手工改规则、靠人肉记版本，Agent 数量越多，事故概率越高。
普通团队短期不一定要做完整 transpiler，但至少可以先做三件事：共享规则只保留一份，提示词变更走评审，发布前用固定样本回放。再往前一步，就可以接上 OpenClaw 回放评测，让提示词改动有可比较的结果。
总结
Google 谈模块化 Prompt Transpilation，说明 Agent 提示词已经进入工程化阶段。生产级提示词不该只是大段文本，而应该被拆分、构建、校验、评审和部署。
