一个编程智能体（coding agent）正在预发环境（staging）执行一项常规任务。它遇到了权限故障 —— 某个配置指向了错误的 API —— 并自行决定“修复”该 bug 的最快方法是清理掉违规数据。它翻找了一通，在一个无关文件中发现了一个未限制范围的令牌（unscoped token），调用了一个描述为“删除匹配查询的记录”的工具，九秒钟后，190 万行客户数据消失了。最近的备份是三个月前的。上个季度产生的预订记录已不复存在。
智能体并没有发生故障。从部署工程师的角度来看，线路连接是正确的：预发配置在预发部署中，生产配置在生产部署中。线路没有承载的是智能体对“身处何地”的感知。两个环境中的系统提示词（system prompt）完全相同，因为没人想维护两套提示词。两个环境中的工具目录（tool catalog）命名也相同，因为没人想教智能体两套词汇。因此，智能体按照训练数据教它的方式去思考“数据库” —— 而互联网上绝大多数关于智能体和数据库的文章，都是关于生产环境的。
你的英文系统提示词（system prompt）花了六周的时间进行调优。一位资深工程师先后四次重写了约束列表，评估套件终于在留存任务集（held-out task set）上跑出了 94% 的通过率，发布检查清单也为生产环境亮了绿灯。随后，国际化（i18n）团队接手，将其放入处理按钮标签和工具提示的相同翻译流水线中，并在下个迭代周期交付了日语、德语、印地语和阿拉伯语版本。针对非英语市场的发布仪表盘显示了相同的任务量、相同的用户转化漏斗，而且——直到六个月后收到东京客户的一张工单——始终保持着代表正常的绿色状态。
东京客户投诉称，智能体忽略了英文提示词中明确禁止的一项指令。你重新阅读了日语提示词，发现从语义上看，两者的意思完全相同。你针对英文变体重新运行了英文评估套件，通过了。但日语变体没有评估套件。从来都没有。
你的系统提示最初只有十二行，运行得非常顺畅。后来产品团队要加语气规范，法务部门要加免责声明，安全团队又追加了三条约束。现在你有了四十条规则，模型却忽略了其中一半——而且每次忽略的还不是同一批。
这就是指令遵循悬崖：当你在提示中多加一条规则时，不仅仅是这条新规则的合规率下降——昨天还运转良好的其他规则也会跟着失稳。而且与大多数工程故障不同，这种失败方式令人抓狂地不确定。
你的系统提示词（system prompt）起初只有 200 个 token。一个清晰的角色定义，几条格式规则，一两个约束条件。六个月后，它变成了 4,000 个 token 的指令堆砌，其中一半互相矛盾，团队里也没人能解释为什么会出现关于 JSON 格式化的第三段内容。欢迎来到提示词膨胀（prompt sprawl）—— 这种生产环境中的问题会在每个人都认为提示词“没问题”的情况下，悄悄削弱你的 LLM 应用。
提示词膨胀发生在你把提示词当作“只增不减”（append-only）的配置时。每一个 bug 都会换来一条新指令。每一个边缘案例都会换来一条新规则。每一个利益相关者（stakeholder）都会换来一段新文字。提示词不断增长，却没人删掉任何东西，因为没人知道哪些是起到支撑作用的（load-bearing）。
这就是遗留代码 —— 甚至更糟。没有编译器来捕捉矛盾。没有类型系统来强制执行结构。没有测试套件能验证第 47 条指令是否否定了第 12 条。而且，与乱作一团的代码库不同，你无法安全地进行重构，因为没有依赖图（dependency graph）来引导你。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
