2026年7月16日 当你首次建立一个AI代理时，单个的、庞大的系统提示通常是可以的。你有一些指令，或许还有一两个工具定义，所有内容都集中在一个可读的文件中。但当你开始将它们用于生产目的时，这种格式就会出现问题。团队开始在上面增加安全政策、特定领域的规则、格式要求和升级行为。突然间，你的整个代理控制面就都集中在一个指令文件中，这正是麻烦的开始。这是一个经典的软件工程扩展问题。当你把所有问题放到一个文件中时，你失去了对系统进行推理的能力。协作变得极其困难，测试也变得繁琐，而为了改善一个工作流程而进行的小更改可能会悄然破坏另一个工作流程。在生产规模下，提示的可维护性变成了代理的可靠性。 单体提示为何会失效 当提示超过某个大小时，我们通常会看到三种主要的失败模式： 1. 干扰半径模糊：在标准的软件工程中，审查者很容易通过模块边界、调用点和测试来推理更改的范围。然而，系统提示的差异更难处理。添加一句话可能会对整个代理产生意想不到的副作用，而这往往难以预测或测试。 2. 复制粘贴漂移：随着组织的扩展，许多团队最终会为各种应用（如内部服务使用说明、个人身份信息处理、安全政策或升级协议）重复共享逻辑。这会导致复制粘贴或相同功能的多个版本，从而导致不一致。 3. 延迟的运行时错误：为了管理这种扩张，团队通常采用临时字符串格式化或简单模板。虽然这有助于编写，但将错误检测推迟到运行时。你可能会部署一个提示，仅在触发特定的、很少使用的工作流程时才出现故障，因为缺少变量或无效的导入路径。模板是一个良好的开端，但不够。生产系统需要确定性的构建、静态验证和CI/CD集成。 将提示视为软件构件 解决方案是在对待提示时，将其视为构建工件，而不仅仅是静态文本。与维护一个单一的庞大提示文件不同，你可以编写模块化的技能文件。这使你能够减少每个文件的范围并封装特定行为，从而允许团队分离关注点并单独迭代组件。一个顶层代理提示模板可能如下所示： # agents/sre_agent.prompt.md (提示模板文件) {% include "shared/safety.prompt.md" %} {% include "shared/tool_usage.prompt.md" %} 你是一个在{{ environment }}环境中工作的SRE分流代理。 {% if allow_remediation %} 你可以推荐修复步骤，但破坏性行为需要人工批准。 {% else %} 你可以检查、总结并解释问题，但请不要推荐修复措施。 {% endif %} {% macro bullet_section(title, items) %} ## {{ title.rstrip() }} {% for item in items %} - {{ item.rstrip() }} {% endfor %} {% endmacro %} {{ bullet_section("所需调查步骤", ["检查最近的部署事件", "检查服务指标以获取延迟或错误率变化", "审查日志以查找重复故障模式"]) }} 这使你可以兼顾两全之利。模板层让你可以组合共享指令，注入特定环境的值，并使用宏。但对于构建系统来说，每个包含项都是一个依赖，每个变量都是一个要求。结果是一个确定性、完全渲染的工件，你可以在其到达模型之前进行测试、审计和差异比较。然后我们可以使用转译器来解析模板导入，生成一个准备好被代理摄取的文件。例如，如果环境=生产且allow_remediation=true，则转译的工件如下所示： 你是一个在生产环境中工作的SRE分流代理。你可以推荐修复步骤，但破坏性行为需要人工批准。 ## 所需调查步骤 - 检查最近的部署事件 - 检查服务指标以获取延迟或错误率变化 - 审查日志以查找重复故障模式 高层次的转译管道大致如下所示： 构建时验证是必需的。生产级转译器应该在运行时之前捕捉错误。我们应该在构建过程中运行验证检查，以查找缺失的导入、未定义的变量和循环依赖。在这里，依赖图是无价的，加强了对稳固模板引擎的需求。如果将每个提示片段视为有向图中的一个节点，则可以轻松捕捉到可能在生产中导致静默故障的递归导入。这也使漂移检查成为可能。你可以设置CI管道，以便能够重新生成转译提示。