做 AI agent 开发的人应该都有这个体验系统提示词写在一个巨大的文本块里改一次提心吊胆一次。一个生产环境的 agent提示词动辄几百行。里面塞了角色设定、工具描述、输出格式约束、few-shot 示例、安全限制、异常处理……但凡多一个工具或少一个参数就得在那一大坨文本里翻来找去。更可怕的是多人协作的时候两个开发者改了同一个提示词的不同部分合并时直接冲突——而且没有 diff 可看。Google Cloud 最新的一篇博客提出了一个方案Prompts-as-Code把提示词当代码管理。过去的问题在哪先说清楚为什么传统的提示词管理会出问题。AI agent 进生产之后系统提示词不再是写一次就不动的东西。它会随着 agent 功能的迭代、工具接口的变化、安全策略的调整而频繁改动。在一个典型的 agent 项目里提示词改动的频率可能比业务代码还高。但问题是提示词的存储形式是一个巨大的文本文件。没有模块化、没有依赖管理、没有类型检查。改了一行你不知道会不会影响其他部分的功能。更糟的是很多团队直接把提示词写在代码里或者数据库里版本控制全靠手动标记。怎么说呢这种做法在 demo 阶段没问题但进了生产就是定时炸弹。我见过一个真实的案例某个 agent 因为系统提示词里一个工具的描述文本少了一个参数说明导致 agent 反复调用错误的 API每次调用都返回 400但 agent 不报错只是重试——白白烧了三个小时的 API 费用。这就是配置漂移configuration drift的典型表现。没人注意到那行描述被改过因为改的人只是顺便调整了一下格式。模块化的思路Prompts-as-Code 的核心想法其实不复杂把提示词拆成模块化的 skill 文件每个文件负责一个功能然后用构建时的 transpiler 把它们组合起来。举个例子一个客服 agent 的提示词可以拆成一个是角色定义文件role.prompt描述 agent 的身份和沟通风格。一个是工具描述文件tools.prompt列出所有可用 API 的定义。一个是安全约束文件safety.prompt规定 agent 不能做什么。还有一个是输出格式文件format.prompt控制返回结构。每个文件独立维护独立版本控制。改工具描述的时候不会影响到角色定义。这看起来基本到不值得说但说实话大部分团队连这步都没做到。构建时校验的价值真正有意思的是后面的部分。Google Cloud 的方案里transpiler 在构建时会做静态验证——检查 prompt 里引用的工具是否都存在、参数是否匹配、有没有未闭合的模板变量。翻了下原文发现了一个有意思的细节这种构建时校验能捕捉到运行时才能发现的问题。比如一个 tool 的 description 里写了一个 JSON schema但这个 schema 和实际 API 的 schema 不一致——按以前的写法agent 会构造出错误的参数直到调用失败才发现。用了 transpiler 之后构建阶段就能警告你 schema 不对齐。这里容易被忽略的是这种验证不是简单的文本匹配。它需要理解 prompt 里引用的工具、参数、约束之间的关联关系。本质上是在提示词层引入了编译的概念。CI/CD 集成模块化之后下一步就是把提示词纳入 CI/CD 流程。一个常见的做法是每个 prompt 文件变更都触发 review - 构建时校验 - staging 环境的 agent 测试 - 灰度发布 - 全量上线。整个过程和普通代码发布的流程一致。但事情没有这么简单。提示词的测试比代码测试难搞得多。你没法写一个断言这个 prompt 输出正确的单元测试因为 agent 的行为是概率性的。Google Cloud 的方案提到的是用 EvalOps 来做评估——在 staging 环境跑一组测试用例对比前后两个版本的 agent 输出质量。不过真正的问题不在技术而在习惯。很多团队把 prompt 当成配置而不是代码所以不会用代码的流程来管理它。Prompts-as-Code 改变的不只是工具链还有开发者的 mindset。对开发者的实际影响对个人开发者来说这套方案看起来有点重。你一个人维护一个 agent搞什么 CI/CD、模块化 prompt确实有点过。但如果是团队协作差别就很大了。几个关键收益一个是 code review 终于有意义了。以前 review prompt 的改动就是看一个几百行的文本 diff根本看不出改了哪里。模块化之后diff 只显示你真正改的那个文件。另一个是回滚变得简单。某个 prompt 改坏了直接把那个文件 revert 到上一个版本就行不会影响其他部分。还有就是多人协作不会踩到彼此。两个开发者可以同时分别改 role 和 tools 文件merge 的时候不会有冲突——因为根本不在一个文件里。还没解决的问题那问题来了这套方案有没有边界Prompts-as-Code 方向是对的但有几个边界情况还没见到好的方案。一个是动态 prompt 怎么办很多 agent 的提示词是运行时拼接的根据用户输入动态插入上下文。这种动态部分怎么模块化另一个是多模态 prompt 的管理——图片、音频、视频输入的描述怎么和文本 prompt 统一管理这些问题等更多实践出来了再看看。但起码现在提示词不再是一坨无法管理的大文本了。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版