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 的往返不可用时应该发生什么的纪律。
当产品团队第一次需要针对每个用户的智能体（agent）行为时，通常会有人说“我们应该进行微调”或“让我们接入持久化内存”。一周后，他们拥有了向量数据库、反馈循环流水线，以及监控学习状态漂移的路线图项。他们构建了一个机器学习系统来解决一个在十有八九的情况下其实只是配置文件的问题。
看看用户真正想要的是什么：更简洁的回答、要点列表而非散文、免责声明中包含我的公司名称、默认使用我偏好的模型、100 美元以下不要转接到人工、这是我本周正在处理的项目、永远不要使用表情符号。这些都不需要模型去学习任何东西。它需要的是设置（settings）。Dotfile 模式——一个版本化的、声明式的、针对每个用户的配置库——在四十年前就为 shell、编辑器和 CLI 解决了这个问题，而这正是 2026 年 AI 智能体的正确形态。
一家世界 500 强公司的采购主管打开了你的支持智能体，询问为什么 SOC 2 报告中提到的某个合规控制项在你的产品中已不再执行。你的智能体用对待免费版个人用户的语气回答了她——带着三个感叹号、一个表情符号，以及一个“联系我们团队”的愉快建议，既没有升级路径，也没有引用出处。采购主管把这张截图转发给了她的首席信息安全官（CISO），只写了一行字：“这就是他们派来处理我们合规问题的东西。”你失去了续约机会，不是因为答案错了，而是因为语气在那个场合不对。
大多数团队之所以只发布一种智能体人格面具，是因为组织架构中只有一个支持团队。然而，客户群体很少是单一的。企业买家期望正式感、引用来源和明确的人员升级路径。自助服务用户想要快速回答和零摩擦。开发者想要代码，而不是长篇大论。单一的人格面具在某些群体看来是居高临下的，而在另一些群体看来则是不专业的。而“让用户选择语气”则是将一个本不该由用户承担的产品决策推卸给了用户。
Agent 事故发生后的第一个小时总是相似的。有人注意到 Agent 做了一些不该做的事情——给错误的客户开了发票，删除了 CEO 的日历事件，或者在公开的 Slack 频道发布了一段写了一半的道歉信——随后响应团队开始询问一些没人写下答案的问题。哪个下游系统持有审计日志？哪个值班轮换组负责该系统？该调用是否可逆，窗口期是多久？Agent 使用的凭证归谁所有，该凭证是否还允许它触及我们尚未检查的其他系统？编写 Agent 的团队很少掌握这些答案，因为答案存在于 Agent 调用的系统中，而且在发布时没人把它们统一记录在一个地方。
这份文档就是爆炸半径清单 (blast radius inventory)，它是大多数 Agent 团队在第一次事故中才发现缺失的产物。它不是安全检查表，不是工具 schema，也不是操作手册 (runbook)。它是 Agent 可以触及的每个外部系统的详尽列表，以及在该系统遭遇最糟糕状况时你所需的每一项事实。那些在没有这份清单的情况下发布 Agent 的团队，是在赌事故响应的上下文重构速度能超过爆炸蔓延的速度。随着 Agent 拥有的工具越来越多且功能越来越强大，这场赌局的胜算正变得越来越低。
看看大多数智能体框架提供的循环原语：continue、return、retry 以及一个硬性终止运行的步数预算。注意缺失了什么。这里有一条表示“工作成功”的路径，一条表示“模型想继续”的路径，还有一条表示“我们耗尽了资金或耐心，于是强行终止循环”的路径。唯独没有一条头等路径来表达“我正在执行的计划是错误的，我想将其丢弃并开始一个全新的计划”。放弃原语（abandon primitive）——即一种让规划器显式、结构化地宣布当前轨迹无望的方式——是智能体循环语法中缺失的动词。它的缺失导致了一类通常被误诊为“模型需要更多推理”的失败。
一个在注定失败的分支上执行了三步的规划器，会不断优化同一个错误的计划，因为循环唯一的出口是成功、重试上一步或耗尽预算。这些路径都不包含“放弃该策略并尝试另一个”。因此，智能体执行了循环所允许的操作：它就地修改计划、再调用一个工具、再请求一次澄清，并在步数预算耗尽前不断收敛到一个非解决方案。当最终撞墙时，用户看到的是一条礼貌的失败消息，而不是问题的答案。这些浪费的步骤所带来的成本是真实的——生产数据表明，智能体系统 5-10% 的 Token 支出都花在了无法产生任何可用结果的重试上，而这一数字主要由长期的“注定失败分支”占据，而非 孤立的工具错误。
当财务团队第一次要求 AI 产品团队预测单位经济效益（unit economics）时，对话往往如出一辙。团队打开推理仪表盘，指着每月的 token 支出说：“这就是我们的销售成本（COGS）。”CFO 乘以预估业务量，在图表上画出一条线，并询问毛利率曲线何时能跨过 70%。六周后，当实际损益表（P&L）出炉时，仪表盘上的推理数字是正确的，但毛利率却比预测低了 20 个百分点。没人撒谎。推理费用其实只占 Agent 实际成本的一半。
另一半成本分散在 AI 团队中无人负责的各个分项中。向量数据库的账单在悄无声息地增长，因为检索量随使用量增加，而重新索引的成本计入了计算费用，而非存储费用。可观测性平台的发票则从平台团队的预算中支出。嵌入重构（Embedding regeneration）表现为 CI 成本。遥测数据存储被归入数据仓库。人工审核则计入客户成功（customer-success）的人员成本。这些项目单独看都不起眼 —— 这正是为什么整合后的数字会让所有人大吃一惊。
如今，生产环境中的大多数 “智能体”（agents）其实都是套着对话界面的后台任务。它们不需要用户向其输入内容，而是需要一个触发器、一个状态文件，以及一种在不可避免的超时后恢复运行的方法。对话循环 —— 请求、工具调用、请求、工具调用，无限循环 —— 是为了演示方便而提供的功能，却悄然间成为了默认的执行模型。然而，对于大多数交付的智能体工作负载来说，这其实是一个错误的模型。
这并非一个哲学层面的决定。它直观地反映在账单上、值班告警中，以及任务的运行成功率上。对话循环会在多轮对话中保持模型会话开启，不断累积上下文，一旦链路中任何一环出错，整个过程就会中断。而调度触发则在确定的边界处启动，运行至完成或达到检查点，并在退出前将状态写入持久化存储。前者像是一通电话，而后者则是一个工作队列。将两者混为一谈，会导致一个每月 200 美元的功能在没有任何人修改提示词的情况下，变成每月 4 万美元的负担。
安全部门花了十年时间才彻底终结了“全能服务账号”。分限令牌、短期凭据、JIT 访问、逐操作审计——这整套最小权限方案终于落地并稳固下来。然而，AI 团队接入了一个智能体，提示词要求提供工具目录，于是工程师请求了平台所能发放的最广泛的 OAuth 作用域。已被弃用的模式换了一身新衣服又回来了，而这次调用 API 的主体是一个没人确定该如何限定作用域的随机循环。
这个智能体拥有日历、文件存储、CRM 和部署流水线的读写权限，因为 API 表面无法预先枚举。令牌是长效的，因为没人接入刷新路径。审计日志记录的是持有者，而非具体操作。IAM 负责管理人类和服务的身份，平台团队负责工作负载身份，AI 团队负责智能体的实际权限，而这三方集合的交集却无人管辖。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
