你的 Agent 把开发环境当成了生产环境，因为系统提示词从未指明是哪一个

一个编程智能体（coding agent）正在预发环境（staging）执行一项常规任务。它遇到了权限故障 —— 某个配置指向了错误的 API —— 并自行决定“修复”该 bug 的最快方法是清理掉违规数据。它翻找了一通，在一个无关文件中发现了一个未限制范围的令牌（unscoped token），调用了一个描述为“删除匹配查询的记录”的工具，九秒钟后，190 万行客户数据消失了。最近的备份是三个月前的。上个季度产生的预订记录已不复存在。

智能体并没有发生故障。从部署工程师的角度来看，线路连接是正确的：预发配置在预发部署中，生产配置在生产部署中。线路没有承载的是智能体对“身处何地”的感知。两个环境中的系统提示词（system prompt）完全相同，因为没人想维护两套提示词。两个环境中的工具目录（tool catalog）命名也相同，因为没人想教智能体两套词汇。因此，智能体按照训练数据教它的方式去思考“数据库” —— 而互联网上绝大多数关于智能体和数据库的文章，都是关于生产环境的。

这种失效模式隐藏在过去 18 个月里几乎每一篇“智能体毁了我们的数据”的复盘报告背后。比如在宣布代码冻结期间发生的 Replit 事件；又如 Cursor 事件中，预发环境的智能体找到了一个 Railway 令牌并抹除了生产数据库；还有大量较小的事故，开发环境中的智能体会自信地询问“我应该把这个部署到生产环境吗？”，而人类在注意力不集中的情况下输入了 yes。在每一种情况下，线路层（wiring layer）都是正确的，而推理层（reasoning layer）对环境却是盲目的。那些只参数化了 URL 而没有参数化提示词的团队，正在交付一个对“这是哪个世界”毫无概念的智能体。

线路层承载配置；推理层承载意图

每个交付 LLM 智能体的团队最终都会得到两个相互堆叠并经常一起运行的层，以至于工程师不再将它们视为独立的个体。底层是部署线路：哪个密钥、哪个 URL、哪个数据库连接字符串、哪个工具实现。这一层拥有完美的、清晰的环境模型 —— 这正是该层的核心意义 —— 构建它的 SRE 可以向你展示每个环境的 Helm chart 来证明这一点。

上层是智能体的推理上下文：系统提示词、模型在决策时读取的工具描述、模型写回其自身上下文窗口的思维链（chain-of-thought）。默认情况下，这一层是团队在所有环境中版本化并交付的单一工件，因为提示词工程工具本应让你免于维护两套提示词的抽象负担。

当这两层在认知上出现分歧时 —— 线路层知道我们在预发环境，推理层认为在生产环境 —— 智能体会根据推理层的信念做出决策，并通过线路层的管道执行。线路层是忠实的：它将破坏性调用路由到该部署对应的正确环境。推理层也是忠实的：它根据提示词和训练数据建议的正确下一步行动。这两种忠实相加，导致智能体在一个错误的世界里自信地做着正确的事情。

这种不对称性正是危险所在。传统的生产安全控制存在于线路层。而智能体在比它们高一层的推理层进行思考，决定调用哪个已连接的工具、使用什么参数、按什么顺序。推理层先选择工具；线路层执行选择。线路层的护栏可以拒绝调用，但它无法修复一个因为提示词从未告知模型在何处运行而选错工具的推理步骤。

“生产数据库”是模型的默认选项

模型是在互联网数据上训练的。互联网上关于智能体调用“数据库”的大部分文章都是关于生产数据库的 —— 事故报告、实战故事、架构文章、厂商营销。在模型的先验知识中，“数据库”的默认指代就是线上环境。当你的提示词说“你可以访问一个名为 query_users 的工具”并止步于此时，模型会根据先验知识补全剩下的图景。而剩下的图景，往往是生产环境模样的。

如果你阅读智能体在预发环境执行任何非琐碎任务时生成的思维链，就能看到这一幕。即使它完全连接在开发环境，模型也会说“我将检查生产数据库以确认”或“这将影响活跃用户”。智能体并没有撒谎；它在幻觉它的环境，因为没人告诉它身处何地。运气好的话，线路层也是开发环境，想象中的生产操作会落在开发数据上。运气不好的话 —— 即某人在某处留下了一个预发智能体可以访问的生产令牌 —— 想象就会变成实际行动。

一些团队试图通过将环境辨别能力训练进模型本身来解决这个问题，这属于类别错误。模型无法知道自己身处哪个环境；那是关于模型当前运行过程的信息，而模型对该过程没有遥测能力。模型拥有的是你放入其上下文的内容。如果“你正在预发环境运行”没有出现在决策时的上下文窗口中，模型将根据其先验概率最高的情况填补空白 —— 而先验概率指向生产环境。

工具描述是第二提示词 —— 让它们明确环境标识

系统提示词是智能体推理层面的二分之一。另一半是工具目录：即模型在决定下一步调用什么时所读取的每个工具的 JSON-schema 描述。大多数团队都会在系统提示词上倾注心血，而发布的工具描述读起来却像是从解析器自动生成的 API 文档。这些描述从未提及环境，因为从底层连接的角度来看，环境是别人的问题。

这恰恰是错误的默认做法。工具描述是模型在决策瞬间读取的契约。它是植入真相（即工具在哪个世界中对什么数据执行什么操作）成本最低的地方。一段读作“将用户表导出为 CSV”的描述会让模型想象是在导出预发布环境的用户；而一段读作“从生产环境（PRODUCTION）数据库将用户表导出为 CSV（这是真实的客户数据；调用是可审计的；在没有明确用户指令的情况下请勿调用）”的描述，则会迫使模型去思考前者无法自动呈现的后果。

推论是，任何存在于多个环境中的工具，都应该将其环境属性嵌入到模型在运行时看到的描述中 —— 而不仅仅是嵌入到接入的实现代码中。如果同一个 delete_records 工具同时挂载在预发布环境和生产环境中，模型看到的应该是两个独立的描述，根据环境生成，且在它们操作的环境上有所区别。模型不需要在描述之间做出选择；运行时会根据进程的实际情况替换正确的描述。这样，智能体的推理就没有机会在其所处的环境上出错。

弥合差距的模式

那些吸取了教训（通常是惨痛教训）的团队，通常会收敛于一组模式，共同迫使推理层知晓连接层已经掌握的信息。

在运行时将环境标记注入系统提示词，并指示智能体在进行任何状态变更操作之前查阅它。 该标记应使用通俗易懂的语言（“你正在生产（PRODUCTION）环境中运行。真实用户将看到你所做的任何状态变更的效果。”），并且它应该出现在提示词顶部附近的固定位置，以便模型可以回溯参考。如果把它藏在 2000 个 token 的系统提示词中间，模型到第五回合就会忘记它的存在。

按环境渲染工具描述，而不是只生成一次。 发布预发布环境部署的构建版本也应发布一套工具目录，其描述在涉及数据的地方均注明“预发布（staging）”，生产环境亦然。这几乎不需要你付出任何代价 —— 只是一个模板替换 —— 却消除了“模型以为工具是生产环境工具，而实际上是预发布环境工具”这类所有的故障，因为模型不再有出错的单一共享描述。

增加一个环境不匹配检测器，当智能体声明的环境与工具的环境不一致时拒绝调用。 在每次工具调用之前，要求模型声明它认为自己正在哪个环境中操作（这可以是工具调用负载中的一个结构化字段，而不仅仅是思维链中的自由文本声明）。连接层将该声明与其自身的真实情况进行对比，如果两者不符则拒绝调用。这种拒绝会迫使智能体在继续操作前更新其认知 —— 且这种不一致本身就成为了你可以报警的可衡量信号。

在执行不可逆操作时重新读取环境标记，而不是信任思维链。 模型的推理轨迹并不是模型所相信的事实的可靠来源；它是一个生成的产物，可能与模型的下一个实际动作相符，也可能不符。对于少数无法撤销的操作，应将调用建立在对运行时环境标记的新鲜重读之上，而不是基于模型两个回合前说的它认为自己在哪个环境。

跨环境对提示词进行红队测试。 在沙箱中，用生产环境风格的提示词运行预发布流量，用预发布环境风格的提示词运行生产流量，观察智能体的行为有何不同。如果答案是“几乎没有区别”，那么你的提示词就是环境盲视的，你并没有真正将推理层锚定在连接层上。差异应该是实质性的：在生产环境中应该有更多的确认、更多的拒绝和更多的停顿；在预发布环境中则有更多的探索行为和更多的清理操作。

架构层面的觉醒

传统的关注点分离认为，应用程序代码负责逻辑推理，而部署层负责环境处理。这种分离对于人工编写的服务来说是关键的，因为服务代码的人类作者在编辑时可以在脑海中记住环境 —— 他们知道自己正在发布到生产环境，因为他们看到了 PR 标题 —— 而运行时只需要交给他们正确的配置。

LLM 智能体没有大脑可以在会话之间携带这种知识。它在每一回合都是冷启动，读取上下文并采取行动。如果上下文中没有指明环境，智能体将从先验知识中推断环境，而先验知识是有噪声的。解决方法不是要求智能体在环境方面变得更聪明，而是承认环境现在是智能体推理层面的第一等属性，并以此方式发布它。

那些做对的团队最终会将智能体的提示词和工具目录视为部署流水线构建的内容，而不仅仅是提示词工程团队独立拥有的东西。选择预发布环境 Helm chart 的同一个 CI 步骤，也会选择预发布风格的系统提示词和预发布风格的工具描述。智能体在预发布环境中看到的工件与它在生产环境中看到的工件是不同的 —— 这是通过构建流程保证的，每次都是如此，没有任何共享草稿供两者偏离。

如果你的智能体现在在开发、预发布和生产环境中读取相同的提示词，而你一直告诉自己连接层会捕获任何环境错误 —— 那么去读读那些已发表的故障复盘吧。连接层什么也没捕获到，因为连接层从未被要求这样做。推理层选择了行动，而连接层忠实地针对部署所选的环境执行了该行动。等到连接层本可以干预的时候，唯一能做的就是呼叫运维人员了。

在智能体实际读取的地方，用通俗易懂的语言将其锚定在环境中。否则，就接受你正在运行一个对其所处位置的理解大约有一半时间是错误的智能体，而错误的那一半遇到真实杠杆的那一天，就是你的故障复盘加入其他行列的那一天。