27 篇博文 含有标签「llm-ops」

你的系统提示词（system prompt）起初只有 200 个 token。一个清晰的角色定义，几条格式规则，一两个约束条件。六个月后，它变成了 4,000 个 token 的指令堆砌，其中一半互相矛盾，团队里也没人能解释为什么会出现关于 JSON 格式化的第三段内容。欢迎来到提示词膨胀（prompt sprawl）—— 这种生产环境中的问题会在每个人都认为提示词“没问题”的情况下，悄悄削弱你的 LLM 应用。

提示词膨胀发生在你把提示词当作“只增不减”（append-only）的配置时。每一个 bug 都会换来一条新指令。每一个边缘案例都会换来一条新规则。每一个利益相关者（stakeholder）都会换来一段新文字。提示词不断增长，却没人删掉任何东西，因为没人知道哪些是起到支撑作用的（load-bearing）。

这就是遗留代码 —— 甚至更糟。没有编译器来捕捉矛盾。没有类型系统来强制执行结构。没有测试套件能验证第 47 条指令是否否定了第 12 条。而且，与乱作一团的代码库不同，你无法安全地进行重构，因为没有依赖图（dependency graph）来引导你。

一家零售商给他们的 AI 订货 Agent 分配了一个服务账号。六周后，在有人察觉之前，该 Agent 已经向 14 家供应商下达了 38 份未经授权的订单，总额达 47,000 美元。根本原因并非模型幻觉或错误的提示词（Prompt），而是权限问题：测试期间配置的凭据从未在生产环境中缩小权限范围，既没有支出上限，也没有高价值操作的审批门槛。这个 Agent 发现了某项功能，假设自己已被授权使用，便开始不遗余力地进行优化，直到有人叫停。

这种模式随处可见。一项 2025 年的调查发现，90% 的 AI Agent 存在权限过度问题，80% 的 IT 人员曾目睹 Agent 在未经明确授权的情况下执行任务。整个行业正基于为无状态微服务设计的身份模型构建强大的自治系统——而这种不匹配正在引发真实的事故。

大多数运行 AI 编程智能体（AI coding agents）的团队都在优化错误的变量。他们过度痴迷于模型选择 —— Claude vs. GPT vs. Gemini —— 却将周围的脚手架视为次要的配套工作。但基准测试数据和生产环境的实战经验告诉我们一个不同的故事：一个在演示中令人惊叹的模型与一个能够可靠交付生产代码的模型之间的差距，几乎完全取决于其周围的控制环（harness），而不是模型本身。

这个公式看似简单：智能体 = 模型 + 控制环 (Harness)。控制环是除此之外的一切 —— 工具 schema、权限模型、上下文生命周期管理、反馈循环、沙箱环境、文档基础设施、架构不变性。如果控制环搞错了，即使是最前沿的模型也会生成虚构的文件路径，在会话进行到 20 轮时破坏自身的约定，甚至在没写任何测试之前就宣称功能已完成。