01. Google 提出了什么问题
二零二六年七月十六日，Google Developers Blog 发布了一篇文章，作者是站点可靠性工程师 Simerus Mahesh。文章讨论的是一个很多 Agent 团队都会经历的变化。
02. 从简单提示词到控制平面
刚开始做一个 Agent 时，系统提示词通常很简单：定义它是谁，告诉它有哪些工具，再补几条基本规则。所有内容放在一个文件里，直观，也容易修改。
但 Agent 真正进入生产以后，团队会不断往里面增加内容。安全策略加一段，领域规则加一段，输出格式加一段，遇到高风险操作，再补一段人工审批条件。每一次修改单独看都很合理，但这些内容不断累积以后，系统提示词就不再是一份普通说明，而是在同时控制 Agent 的身份、工具、权限和处理流程。
Google 这篇文章真正要问的是：当这样一套控制逻辑还集中在一个文件里，团队怎样判断下一次修改是不是安全的？
03. 影响范围与规则漂移
一旦走到这一步，修改提示词就不再只是修改文案，而是在改变系统行为。原文把由此产生的问题归纳成三类。
第一类是影响范围不透明。工程师本来只是想改善一个工作流，但加进去的一句话对整个文件都生效，其他任务也可能跟着改变。
第二类是公共规则逐渐漂移。多个 Agent 都需要相同的隐私规则或者工具说明，团队最容易采用的办法就是复制。后来不同项目分别修改，同一条规则慢慢变成几个互相矛盾的版本。
04. 错误为什么拖到线上
第三类是错误发现得太晚。变量漏填、引用路径写错，文件表面上仍然可以生成。只有用户真正进入对应的条件分支，问题才会在线上暴露。
所以，大提示词真正缺少的不是更多写作技巧，而是软件系统原本就有的模块边界、依赖关系和发布前检查。
05. 普通模板为什么还不够
很多人的第一反应是：把重复内容抽成模板，再用字符串拼接，不就可以了吗？
模板确实能减少重复，但它主要解决的是怎么拼，不能保证最后拼得对不对。比如某个变量没有定义，只要对应的条件分支暂时没有触发，文件仍然可能正常生成。等用户真正走进这条流程，错误才会暴露。
两个模块互相引用也是一样。简单模板可以把文字拼在一起，却未必知道依赖关系已经形成了死循环。
所以 Google 提出的核心变化，是不要把 Prompt 当成写完就发布的文本，而要把它当成需要经过构建和验证的源代码。
06. 先把指令拆成模块
文章用了一个站点可靠性智能体来说明这种拆法。
公共安全规则放在一个模块里，工具使用方法放在另一个模块里，智能体自己的角色和排查步骤单独保存。顶层提示词只声明它依赖哪些模块、当前运行在测试环境还是生产环境，以及是否允许给出修复建议。
07. 配置决定行为边界
例如，在生产环境中允许提出修复方案，但破坏性操作必须交给人工批准。在另一种配置下，智能体只能检查和解释问题，不能建议执行修复。过去这些条件都混在一个大文件里，现在每个模块只负责一种行为，顶层文件负责组合它们。
模块化真正带来的，不只是文件变短，而是指令之间第一次有了可以检查的依赖关系。
08. 提示词构建器
模块拆开以后，还不能把这些零散文件直接交给模型。Google 把中间的构建程序称为转译器，可以把它理解成一个提示词构建器。
它读取模块引用、环境变量、条件分支和可复用片段，再生成一份完整、展开后的最终提示词。相同的源文件和构建参数，必须得到完全相同的结果。
09. 部署的是构建产物
团队真正部署的是这份带版本的构建产物。它在进入模型以前就可以被测试、审查和比较。工程师也能明确看到，测试环境与生产环境最终到底多了哪几条指令。
10. 发布前拦住确定错误
有了构建过程，很多过去只能在线上发现的问题，就可以提前拦住。
生产级构建至少要检查三类错误：引用的模块不存在，使用了没有定义的变量，以及模块之间形成循环依赖。把每个提示词片段看成依赖图里的一个节点，构建程序就能发现谁引用了谁，也能识别递归引用。
这里的原则和编译代码一样：只要错误能够在发布前确定，就不应该留给概率模型，更不应该留给线上用户。
11. 审核版本必须等于运行版本
哪怕构建成功了，还有一个关键问题：仓库里的源文件，和线上真正运行的提示词，是不是同一份？
Google 的做法是保存一份基准产物。每次提交代码，自动化流水线都会根据源文件重新构建提示词，再与仓库里已经确认过的产物比较。只要结果不同，构建就会失败。团队必须解释差异，重新完成审查。
这道门禁防的是版本漂移。否则代码审查看到的是一套新模块，线上模型执行的却可能还是旧产物。模块写得再规范，只要审核版本和运行版本对不上，前面的检查就失去了意义。
12. Prompt 模块与 Skill 的关系
讲到这里，我们一直在说怎样把一份大 Prompt 拆成模块，再构建成可以部署的最终产物。但如果每次构建都把所有模块重新塞回 Prompt，文件虽然更容易维护，模型运行时面对的内容还是会越来越多。
所以还要区分两类模块。
第一类是每次运行都必须遵守的稳定规则，例如身份、安全边界和工具权限。它们会被构建进基础 Prompt。第二类只服务于某一种任务，例如数据库排查流程或者部署事故处理方法。Google 把这类任务专用的指令模块称为 Skill。
13. Skill 为什么按需加载
Skill 并不是突然增加的另一套东西。它仍然属于 Agent 的指令层，只是没有必要进入每一次上下文。处理数据库故障时，Agent 通过工具取得数据库排查 Skill；遇到部署事故时，再加载部署处理 Skill。
这样，构建时的模块化负责让稳定规则可以维护、验证和发布；运行时的按需加载负责控制 Token 消耗，避免无关规则争夺模型的注意力。两者处理的是同一套指令在不同阶段的问题。
14. Agent 只能提出修改
把基础 Prompt 和任务 Skill 分开以后，Agent 也可以参与维护自己的指令层。
当它解决了一种过去没有遇到的故障，可以起草一个新的 Skill，更新相关依赖，并发起代码合并请求。但它不能在运行中直接改写自己的指令。新模块仍然要经过构建、静态检查、行为评测和人工审查，才能进入下一个发布版本。
所以所谓自我改进，不是让 Agent 获得在线修改自身指令的权限，而是让它成为指令仓库的贡献者。最终发布权，仍然留在工程门禁之后。
15. 微软补上内容范围
到这里，Google 解决了 Prompt 和 Skill 怎样安全构建、检查和发布。但发布流程再严谨，也不能回答另一个问题：我们准备写进 Skill 的内容，本身真的有必要吗？
二零二六年六月十八日，Microsoft for Developers 发布了一篇文章，作者是 Waldek Mastykarz。它指出，很多团队把接口文档、认证流程、SDK 示例、错误处理和版本说明全部塞进一个 Skill。结果消耗了大量 Token，智能体的表现却没有提高。
原因是其中很多内容，模型本来就已经知道。重复提供这些知识，不但没有帮助，还会挤掉工作区文件、对话历史和其他工具返回的结果。
16. 先测没有 Skill 的基线
微软给出的办法不是凭经验删文档，而是先测基线。
使用同一个模型、同一套运行框架和同一组真实任务，先在没有 Skill 的情况下运行并评分。模型已经能正确完成的增删改查、常见认证和标准 SDK 用法，不要再写进 Skill。只把它稳定做错、没有见过或者容易混淆的部分留下来。
17. 再测效果与 Token 成本
然后重新运行同一组任务，确认这个 Skill 带来的确实是效果提升，而不只是上下文变长。模型或运行框架发生变化以后，基线也要重新测。因为不同模型缺少的知识并不相同。
换句话说，Skill 不应该是一本完整说明书，而应该是一张针对模型盲区的补丁。
18. 找到一个真实缺口
假设一个编程智能体已经会调用某套接口，也能完成常见的增删改查，但它经常选择已经废弃的 SDK 版本，还会漏掉新版认证流程里的一个特殊参数。
按照微软的方法，这份 Skill 只需要记录怎样选择正确版本，以及怎样处理这个特殊参数，不必复制整套接口文档。
19. 把缺口按代码发布
再按照 Google 的方法，把这份 Skill 作为独立模块提交。构建程序生成最终提示词，检查变量和依赖，再用原来失败的任务重新评测。只有效果确实提高、Token 成本可以接受、人工审查通过以后，它才能获得版本号并上线。
运行时，也只有任务涉及这套接口时才加载它。这样一来，这份 Skill 为什么存在、解决什么失败、经过哪些验证、线上正在使用哪个版本，全部可以追踪。
20. 四个必须回答的问题
Google 和微软给出的并不是一套开箱即用的标准工具。模板语言、构建程序和评测系统，仍然需要团队自己实现或者选型。但两篇文章共同划出了一条很清楚的工程边界。
凡是能够改变 Agent 行为的文字，都不应该被随手修改。每一份 Skill 都应该能回答四个问题：模型原来在哪里失败，它为什么需要存在，它通过了哪些验证，线上正在运行哪个版本。
Prompt 和 Skill 的专业化，不是把它们写得越来越长，而是先证明模型到底缺什么，再把那一小部分按照软件工程的标准构建和发布。
参考资料与延伸阅读
本文事实来源
- 发布方：Google Developers Blog
- 发布日期：2026-07-16
- 作者：Simerus Mahesh
- 原始标题：Building scalable AI agents with modular prompt transpilation
- 原文：https://developers.googleblog.com/building-scalable-ai-agents-with-modular-prompt-transpilation/
Microsoft
- 发布方：Microsoft for Developers
- 发布日期：2026-06-18
- 作者：Waldek Mastykarz
- 原始标题：Stop overloading your skills
- 原文：https://developer.microsoft.com/blog/stop-overloading-your-skills/
编辑说明：视频把两篇文章合并为一条工程发布链；“Agent 只能起草变更并提 PR”是对生产变更边界的工程归纳。
相关观看入口
资料核验日期：2026-08-23。