别再维护一份巨型 Prompt:智能体指令也要进入构建流水线章节1×0:08今日事件:提示词从文本变成软件制品1:19为什么单体 Prompt 会成为控制面风险2:48把 Agent 指令编译成可检查的控制面4:21这怎样改变 Agent Loop5:57工程落地:先建最小闭环7:22一句话带走0:008:110:08主持人早上好,这里是 AI Loop Engineering 每日深度播客。今天我们不聊一个新模型,而聊智能体最容易被低估的一层:它到底该怎样维护自己的指令。 七月十六日,谷歌开发者博客发布了一篇文章,题目可以概括成「用模块化提示词转译,让智能体规模化」。文章的核心判断很直接:当智能体从实验走向生产,单一、庞大的系统提示词会开始失效。安全策略、领域规则、输出格式、升级路径,全都堆在同一个文件里,最后得到的不是一个清晰的控制面,而是一块谁也不敢轻易改动的黑箱。 谷歌给出的方向,是把提示词当成软件构建产物。团队维护多个模块化的技能文件,用模板组合共享规则,注入环境变量,再由转译器解析依赖,生成确定性的最终提示词。也就是说,模型真正拿到的内容,不再是开发者手工复制出来的一大段文本,而是可以测试、审计、比较和发布的构建结果。 这就是今天的主题:当 Agent 的循环越来越长,真正需要工程化的,可能不只是模型调用和工具调用,还有驱动这一切的指令层。1:19主持人先看问题本身。实验阶段,一份系统提示词很方便。角色、工具说明和几条安全规则放在一起,改起来快,也容易读懂。但生产系统通常会不断加东西:不同环境的权限边界、个人信息处理要求、领域术语、异常升级策略,还有不同工作流的输出格式。 这些内容一旦全部写进同一个文件,会出现三个工程问题。 第一,变更的影响范围不清楚。你只是想调整一个工作流的语气,可能无意间改变了另一个流程的安全判断。软件代码里,我们可以通过模块边界、调用关系和测试定位影响;巨型提示词里,一句话的影响常常要到线上才暴露。 第二,共享规则会发生复制漂移。不同团队各自复制一份隐私处理规则,半年以后,文件看起来相似,细节却已经不一致。智能体遇到同一种数据,在不同应用里给出不同处理方式,问题不在模型,而在指令资产失去了单一来源。 第三,错误被推迟到运行时。为了让大文件可维护,团队会开始使用临时字符串拼接和简单模板。变量漏传、导入路径写错、模块互相循环引用,往往要等到某个很少触发的工作流真正运行,才会变成故障。 所以,提示词的可维护性,最后会直接变成智能体的可靠性。这里的关键不是把提示词写得更长,而是让它像代码一样有边界、有依赖,也有构建时的失败方式。2:48主持人谷歌文章给出的方案,可以拆成一条很熟悉的软件工程流水线。 第一步是模块化。把安全边界、工具使用、领域规则和具体任务拆成不同的技能文件。每个文件只负责一个相对清晰的行为,团队可以独立评审,也能知道一次改动大致影响什么。 第二步是声明式组合。顶层提示词通过包含关系引用共享模块,通过变量注入环境信息,还可以用宏复用格式化结构。比如,一个运维智能体在生产环境允许提出修复建议,但破坏性操作必须经过人工批准;在测试环境,它可能拥有更宽的实验范围。这些差异不应该靠两份几乎一样的长 Prompt 手工维护,而应该由配置和模板明确表达。 第三步是构建和校验。转译器把所有引用解析成一份完整的最终产物,同时检查缺失导入、未定义变量和循环依赖。这里最重要的变化,是错误发生在智能体运行之前,而不是发生在一次真实事故里面。 第四步是漂移检查。每次构建都从源文件重新生成一份基准产物,再和仓库里提交的版本比较。如果两者不一致,持续集成就失败。这样团队才能回答一个很实际的问题:仓库里审查过的指令,是否就是线上智能体真正使用的指令。 这条链路和普通软件的编译、测试、发布很像。差别只是,最后的可执行对象不再是二进制文件,而是模型会据此决定下一步行动的上下文。4:21主持人把指令层做成构建产物,最直接的收益,不是让模型突然变聪明,而是让循环里的控制点变得可见。 先说上下文管理。文章建议采用渐进披露:基础提示词只保留身份、安全边界和不可违反的规则;任务开始后,智能体再通过工具按需加载当前需要的技能。这样做有两个好处。一个是减少上下文消耗,另一个是减少无关规则之间的干扰。对于长任务来说,少加载一部分噪声,可能比再塞进一个更大的模型更有效。 再说评估。模块化以后,评估不必只问「这个智能体最后答对了吗」。团队可以针对某一个技能模块建立测试集,检查它是否正确拒绝危险操作,是否在生产环境要求审批,是否把工具结果转换成规定格式。最终还可以把模块版本、构建版本和运行轨迹关联起来,定位一次失败究竟来自模型、工具、数据,还是刚刚改过的指令。 最后是自我改进。谷歌文章提出,智能体可以帮助维护自己的指令层。它可以根据一次新事故起草技能模块、修改引用关系,并提交一个代码变更。但这里有一个很重要的边界:智能体不能在运行时直接改写自己的指令。它只能提出变更,随后接受转译器校验、人类审查和评估,通过后才进入下一次部署。 这其实把「自我改进」从一个危险的实时行为,改造成一个可以审查的反馈循环:运行产生经验,智能体提出补丁,构建系统验证补丁,人类决定是否合并,新的指令再进入下一轮运行。5:57主持人如果团队今天要落地,不建议一上来就设计一套复杂的提示词语言。可以从四个最小动作开始。 第一,建立单一来源。把重复出现的安全规则、工具调用规则和审批规则从业务 Prompt 里抽出来,每个模块只保留一个维护位置。先解决复制漂移,再追求更复杂的模板能力。 第二,给每份模块补依赖和版本。不要让智能体在运行时临时拼接字符串。构建阶段就解析引用,并输出一份带版本信息的最终提示词。每次线上 trace 都至少记录它使用的构建版本。 第三,把三类错误放进持续集成:缺失导入、未定义变量和循环依赖。再加一条基准产物漂移检查。它们看起来很基础,但正是最容易被巨型 Prompt 隐藏的故障。 第四,按技能而不是按整条 Agent 做评估。比如工具选择、隐私脱敏、升级人工和结果格式,分别建立可以重复运行的用例。这样一次改动只影响一个模块时,团队才有机会快速知道它改好了什么,又破坏了什么。 这里也要保留一个判断:模块化不是把所有规则拆成更多文件就结束了。如果基础控制面过于庞大,运行时仍然把所有技能全部加载,系统一样会陷入上下文膨胀。真正有效的目标,是稳定边界和任务上下文分层,再让加载、构建、评估和发布各自有清晰责任。7:22主持人今天的判断是:生产级 Agent 的 Prompt,不应该只是模型前面的一段文字,而应该是循环控制面里的软件制品。它要能够被拆分、被构建、被验证、被版本化,也要能够在需要时按技能加载。 如果一个智能体已经能自己提出代码修改,却还不能告诉你自己正在使用哪一版指令、这版指令经过了哪些检查,那么它的自我改进还没有进入工程闭环。 通勤路上可以留一个问题给自己:你们团队现在审查的,究竟是 Prompt 源文件,还是智能体真正运行时拿到的最终产物? 感谢收听 AI Loop Engineering 每日深度播客。明天见。