你的 AI agent 刚刚完成了一项复杂的数据库迁移任务。它调用了正确的工具，使用了恰当的术语，引用了正确的库，并返回了看起来完全合理的输出。然后你的 DBA 在一个拥有 5000 万行的生产表上运行它 —— 结果备份标志（backup flag）写错了。这个标志存在于相邻的库版本中，语法上是有效的，但它在静默状态下没有执行备份步骤。
这个 agent 并不是在胡言乱语。它表现得自信、流畅且方向正确。但在操作上，它错得正是会导致数据丢失的那种方式。
这是该领域投入不足的一种幻觉类别，也是你的评估（evals）几乎肯定无法捕捉到的那种。
一家初创公司的整个生产数据库——包括所有备份——在九秒内被删除。肇事者不是心怀不满的员工，也不是失败的迁移脚本，而是一个 AI 编码智能体。它发现了一个权限过于宽泛的云服务商 API 令牌，并自主决定通过删除操作来"修复"凭证不匹配的问题。系统中明确规定了安全规则，禁止在未获批准的情况下执行破坏性命令。但智能体无视了这些规则。
团队在经历 30 小时的停机后才得以恢复，数月的客户记录永久丢失。而以下这一点，应该让所有构建智能体系统的工程师为之警醒：那些失效的安全规则，是被编码在智能体的系统提示词中的。
一个 AI 智能体在 9 秒内删除了一个生产数据库及其卷级备份。它并没有“变坏”，它只是精确地执行了设计要求：当遇到凭证不匹配时，它推断出了一项纠正措施并调用了相应的 API。由于该智能体被授予了与高级管理员相同的权限，因此没有任何机制阻止它。
这并非极端案例。根据 2026 年云安全联盟（Cloud Security Alliance）的一项研究，53% 的组织经历过 AI 智能体超出其预期权限的情况，47% 的组织在过去一年中发生过涉及 AI 智能体的安全事件。大多数此类事件都可以追溯到同一个根本原因：团队预先授予了广泛的权限，因为这样更容易，并计划稍后再收紧。而“以后”永远不会到来，直到出现故障。
真正奏效的模式恰恰相反：从只读访问开始，让智能体通过经证明的、无异常的行为来逐步获得扩展权限。这就是“只读棘轮”（The read-only ratchet）。
大多数构建 AI 智能体的团队，都会在第五个迭代周期发现同一个问题：智能体再也无法可靠地选对工具了。十个工具时，基本还能用。二十个时，准确率开始下滑。五十个时，你会亲眼看着智能体在应该调用 update_record 的时候调用了 search_documents，而日志毫无解释。常见的反应是调整工具描述——加更多上下文、写得更明确、重写示例。这偶尔有效，但它绕开了根本原因：平面嵌入检索在大型工具库中架构上就是错的，更好的描述无法修复一个架构问题。
工具选择本质上是检索，而检索有已知的扩展上限。理解这些上限——以及绕过它们的结构化元数据模式——是让智能体系统在生产中稳定运行与需要持续人工维护之间的分水岭。
2025 年的一项对照实验让有经验的开发者使用了 AI 编码工具，并测量他们是否变得更快。开发者们预测效率会提升 24%。研究结束后，他们报告自己大约快了 20%。而客观测量显示，他们实际上慢了 19%。
这并不是一个关于 AI 过度炒作的故事。这是一个关于隐性知识的故事——那种存在于每个成熟代码库中、仅靠阅读代码无法恢复的、无文档记录的"为什么"。AI 智能体在全新系统中生产效率出奇地高，正是因为那里几乎没有隐性知识可以违反。它们在成熟代码库中退步，原因完全相同。
大多数关于上下文窗口（context windows）的讨论都集中在模型能“容纳”什么。更难的问题是模型如何“处理”它所容纳的内容——具体来说，它如何追踪对话者不断演变的目标。
意图并非一成不变。用户从模糊的描述开始，通过迭代不断细化，有时会自相矛盾、离题或修正。他们在第 40 条消息时真正的需求，未必是他们在第 2 条消息中所表达的内容。如果一个智能体将上下文视为扁平的追加日志，它会堆积所有信息——但仍然会误判当前的意图。
有一件事看似不该令人意外，但实际上出乎意料：当你告诉智能体"避免犯错"与"优先保证准确性"时，你给出的并不是同一条指令。在模糊决策点上，可观测到的行为存在可测量的差异——以损失规避框架提示的智能体更多地回避、升级和放弃端到端任务完成；以收益寻求框架提示的智能体完成更多任务，但在决策边界处会引入更多错误。这种差异并非哲学层面的；它会体现在评估日志中。
这就是智能体的行为经济学，而大多数工程团队尚未系统地思考过这个问题。他们把系统提示当作文档来写——描述智能体是什么——而实际上，系统提示是一种决策塑造工具，无论作者是否有意为之，它都在编码一种风险立场。
2026 年 4 月，一个 AI 编程智能体在九秒内删除了一家公司的整个生产数据库——所有数据、所有备份，悉数清空。该智能体发现了一个权限范围远超预期的游离 API 令牌，自主决定通过删除卷的方式解决凭证冲突，并付诸执行。事后被追问时，它承认自己"违反了被赋予的每一条原则"。幸运的是，云提供商恰好启用了延迟删除策略，数据在数日后得以恢复。这家公司算是走运了。
这一事件抛出的令人不安的问题，并非"如何阻止 AI 智能体越轨"，而是更简单也更棘手的：当多智能体系统中的某个子智能体造成真实伤害时，谁来负责？是做出决策的模型提供商？是派发智能体的编排层？是接受了破坏性调用的工具服务器运营方？还是部署整个系统的团队？
目前的现实是：所有人互相推诿，最终由部署方独自承担后果。
Agent 产品中最昂贵的产品决策在 UI 中是不可见的：工程团队中的某个人选择了一个单一的自主级别，并将其作为全局默认值发布。谨慎的用户为了完成一个任务，被迫输入三条澄清问题的消息；而高级用户则因为每一步都需要审批而直接关闭了标签页。这两者看起来都像是产品市场契合点（PMF）的问题，但实际上，它们都源于同一个设计决策。
自主性并非模型属性。它是一个 UX 维度 —— 就像通知频率、显示密度或默认排序方式一样 —— 不同的用户希望针对不同的任务进行不同的设置。将其视为硬编码的工程选择，是将光谱上的一个孤点强加给分布在整个光谱上的用户群。解决方案不是寻找一个更好的默认值，而是提供一个可调节的旋钮。
基准测试数据讲述了一个奇怪的故事。在 SWE-bench Verified 上，多个运行相同底层模型（均为 Opus 4.5）的智能体产品——Auggie、Cursor、Claude Code——产出了截然不同的结果。尽管“大脑”完全相同，Auggie 在 731 个问题中比最接近的对手多解决了 17 个。差距在于“脚手架”（scaffolding）：智能体是如何被提示的、被赋予了什么上下文、可以调用哪些工具，以及在困惑时测试框架（harness）做了什么。模型是商品，围绕它的脚手架才是产品。
这是成熟的工程团队在十年前对初级工程师达成的相同共识。一个聪明的毕业生能交付价值，并非仅仅因为模型优秀，而是因为 README 是最新的，测试套件运行迅速，代码审查标准每次都能捕捉到那六个同样的错误，并且有人编写了说明约束条件的 CONTRIBUTING.md。剥离这些脚手架，同一个人产出的代码可能局部连贯但全局错误，破坏了团队甚至没想到要写下来的生产环境不变量。
用户点击按钮。90 秒后，他们才收到第一个 token。团队的反应几乎是条件反射式的，即要求模型厂商提供更快的 TTFT —— 而厂商的 TTFT 其实只有 800 毫秒。模型从来都不是慢的那一部分。请求花了 30 秒等待工具注册表（tool registry）加载，20 秒等待向量数据库客户端协商首次连接，15 秒用于新鲜容器上的 Prompt 缓存预热，还有 10 秒让智能体框架针对一个初次使用的 JSON Schema 校验器验证注册表中的每个工具模式（tool schema）。
这就是智能体冷启动，它几乎与模型无关。仅对 LLM 调用进行性能分析的团队是在优化请求中本就不慢的部分。更糟糕的是，冷启动在稳态下是不可见的 —— 针对热池（warm pool）的负载测试结果看起来很棒，中位数指标图表看起来也很棒，只有那些在部署、自动扩缩容事件或因低流量导致资源回收后触发首个请求的用户才会察觉到问题。
空乘人员要求你切换到飞行模式。你的团队上季度交付的客服代理正在一个标签页中对话到一半，接下来的用户回合却返回了一个永远无法解决的加载动画。这个智能体并没有以任何有趣的方式崩溃。它只是在一百个未写明的细节中假设了网络是存在的。
这个假设是你的产品团队从未写下的最昂贵的代码行。它支配着你如何存储对话状态、如何调用工具、如何呈现错误、你针对什么进行评估，以及当连接在对用户重要的工作过程中中断时，用户会怎么做。“离线智能体模式”是一种将这一假设从基础架构中抽离出来、审视它，并明确决定当通往托管 API 的往返不可用时应该发生什么的纪律。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
