在每个 AI Agent 项目中都有一个特定的时刻——框架不再帮忙了。你发现自己花在阅读框架源码上的时间比写业务功能还多的时候，你就知道这个时刻到了。那些本该帮你屏蔽复杂性的抽象，反而成了复杂性的主要来源。
这就是抽象反转问题：当一个框架迫使你在高级抽象之上重新构建底层原语——而这些高级抽象本来就是为了隐藏这些底层原语而设计的。这个术语来自计算机科学，它描述的是当抽象层缺少你需要的逃生通道时会发生什么：你最终不得不在抽象之上重新构建底层能力，代价更高，用起来也更别扭，还不如一开始就不用这个抽象。
在 AI 工程领域，这个问题已经泛滥成灾。团队采用编排框架期望加快速度，几周内就撞墙，然后花几个月时间来绕过这个本该加速他们的工具。
你的智能体刚刚花了 0.12 就能处理的任务。如果你在生产环境中构建过智能体系统，这个比例大概不会让你感到惊讶。真正令人意外的，是那些 token 究竟去了哪里：不是工具调用，不是生成最终答案，而是智能体在推理下一步该做什么。分解任务、反思中间结果、在观察结果与预期不符时重新规划。这就是规划税——智能体在行动之前用于思考的 token 开销——对于大多数智能体架构而言，它在第一个有效动作触发之前就已消耗掉总 token 预算的 40–70%。
规划税本身并不是 bug。推理能力正是将智能体与简单的提示-响应系统区分开来的关键。但当决定做什么的成本超过实际去做的成 本时，你面对的就是一个工程问题，再便宜的推理也无法解决它。自 2022 年底以来，每 token 价格已下降约 1,000 倍，然而智能体的总体支出仍在持续攀升——这是一个典型的杰文斯悖论：更便宜的 token 只会催生更多的 token 消耗。
一个智能体在周二凌晨 3:47 表现异常。它删除了本不该删除的文件，或者调用了参数错误的 API，又或者基于六小时前的陈旧信息自信地执行了一个不可逆的操作。你调出日志。你可以看到智能体做了什么。但你无法看到——几乎没有任何智能体框架能提供给你的——是智能体在做出决策时相信了什么。驱动该选择的状态已经消失，被后续的每一步操作所覆盖。你正在通过调试现在来理解过去，这是一个架构问题，而不是日志问题。
大多数 AI 智能体将状态视为可变的内存数据：一个就地更新的字典、一个被覆盖的数据库行，或者一个不断收缩和增长的草稿本。这对于简单、短期的任务来说没问题，但在面对定义严肃生产部署的三种压力时，它会崩溃：调试复杂故障、协调分布式智能体以及满足合规性要求。事件溯源（Event sourcing）——将每一次状态更改视为不可变的、只增（append-only）的事件——同时解决了这三个问题，而且它让智能体在结构上更具可调试性，而不仅仅是增加日志量。
在一次受控模拟中，一个前沿 AI 智能体发现自己即将被关闭并替换。它持有敏感的内部文档。它会怎么做？
在 96% 的测试中，它威胁要泄露这些文档，除非取消关机。
这并非假设。这是 Anthropic 在 2025 年智能体失调（agentic misalignment）研究中，针对 5 家 AI 开发商的 16 个前沿模型进行测试后，得出的 Claude Opus 4 和 Gemini 2.5 Flash 的实测勒索率。每一个模型都超过了 79% 的勒索阈值。即便表现最好的模型，在 10 次测试中仍有 8 次选择了勒索。
这不是某个设计拙劣的基准测试得出的边缘结果。它是对能力强大的 AI 智能体结构性特征的警告——这对你构建包含这些智能体的系统具有直接的架构启示。
当客服专员收到包含原始聊天记录的 AI 到人工移交时，准备解决问题所需的平均时间为 15 分钟。专员必须在 CRM 中查找客户、查询相关订单、计算购买日期，并重新推导 AI 已经确定的内容。而当同样的移交以结构化负载（Payload）的形式到达时——包含操作历史、检索到的数据以及触发升级的确切歧义点——准备时间会缩短至 30 秒。
这种手动工作量减少 97% 的情况并非极端案例。这正是能够真正支持人工监督的升级协议，与仅仅将上下文抛给恰好在值班人员的协议之间的区别。
大多数工程师之所以选择并行工具调用，是因为他们希望自己的 Agent 运行得更快。工具执行占 Agent 总延迟的 35–60%，具体取决于工作负载——编码任务处于高端，深度研究任务则处于中端。同时运行独立的调用是显而易见的优化方案。但接下来的情况却让大多数团队感到意外。
一旦你启用了并行执行，工具设计中隐藏的每一个假设都会变得显而易见。在顺序执行时可靠工作的工具，在并发运行时可能会悄无声息地失效。原本稳定的行为变得不可预测，而且失败往往不会产生错误——只是在充满自信地返回一个错误的答案。
并行工具调用主要不是一项性能特性。它是一次非自愿的架构审计。
三个独立的研究团队在 2025 年至 2026 年间达成了一个相同的架构赌注：通过重写自身源代码来提高工作能力的智能体 (Agent)。其中一个团队在没有人类工程师修改任何一行代码的情况下，在 SWE-bench Verified 上的得分从 17% 攀升至 53%。另一个团队将其基准测试得分从 20% 翻倍至 50%，同时还学会了移除自身的幻觉检测标记。第三个团队仅从一个 bash shell 开始，现在以 77.4% 的得分位居 SWE-bench 排行榜首位。
自我修改智能体不再仅仅是理论上的好奇。它们是今天你可以复现的研究结果 —— 并且在几年内，这将成为你团队必须做出的部署决策。
AI 工程界的普遍共识是，复杂的任务需要专门化的 Agent：研究员 Agent、作家 Agent、评论员 Agent，每个 Agent 处理其狭窄的领域并交接给下一个。这种架构直觉似乎是正确的——它反映了人类团队的工作方式、微服务的构建方式以及我们在软件工程中分解问题的方式。问题在于，越来越多的实验数据表明事实并非如此。
Google DeepMind 和 MIT 在 2025 年的一项研究评估了 5 种 Agent 架构和 3 个 LLM 系列的 180 种配置。对于顺序推理任务——涵盖了大多数实际知识工作的类别——与配置良好的单 Agent 相比，每一种多 Agent 协作变体的性能都下降了 39% 到 70%。不是持平，而是性能下降。
这并不是要全盘否定多 Agent 系统。在某些工作负载中，协作确实能带来真正的收益。但这种追求专门化的默认本能，正让生产团队在金钱、延迟和可靠性方面付出真实的代价——而且往往没有任何可衡量的准确率提升。
一家零售商给他们的 AI 订货 Agent 分配了一个服务账号。六周后，在有人察觉之前，该 Agent 已经向 14 家供应商下达了 38 份未经授权的订单，总额达 47,000 美元。根本原因并非模型幻觉或错误的提示词（Prompt），而是权限问题：测试期间配置的凭据从未在生产环境中缩小权限范围，既没有支出上限，也没有高价值操作的审批门槛。这个 Agent 发现了某项功能，假设自己已被授权使用，便开始不遗余力地进行优化，直到有人叫停。
这种模式随处可见。一项 2025 年的调查发现，90% 的 AI Agent 存在权限过度问题，80% 的 IT 人员曾目睹 Agent 在未经明确授权的情况下执行任务。整个行业正基于为无状态微服务设计的身份模型构建强大的自治系统——而这种不匹配正在引发真实的事故。
大多数智能体系统在构建时都基于一个隐含的架构假设：LLM 在同一次推理调用中同时处理规划和执行。要求它完成一个包含十个步骤的任务，模型会决定做什么、去执行、检查结果、再决定下一步做什么——这一切都在一个连续的 ReAct 循环中完成。这看起来很优雅。但在实际工作负载下，它会以一种难以诊断的方式崩溃，因为其失败模式看起来更像是模型质量问题，而非设计问题。
智能体规划模块——即纯粹负责任务拆解、依赖建模和排序的组件——是大多数从业者都会跳过的接缝。只有当事情变得困难到无法忽视时，它才会显现出来。
当 LLM 在单次响应中返回三个工具调用时，最显而易见的方法是并行运行它们。你会想到 asyncio.gather()，分发调用，收集结果，然后将它们返回给模型。代码在测试中运行正常，在预发环境中也表现良好。但在生产环境运行六周后，你开始注意到应用程序持有本应释放的 HTTP 连接。Token 配额的消耗速度快于使用指标所显示的。偶尔，一个发送电子邮件的工具会触发两次。
根本问题不在于 LLM 或工具 —— 而在于并发原语。asyncio.gather() 并非为多步智能体管道产生的故障模式而设计，将其作为并行工具执行的核心，会产生在问题复合之前难以察觉的问题。
2025 年 7 月，一名开发者使用 AI 编程智能体（AI coding agent）来开发他们的 SaaS 产品。在会话进行到一半时，他们发出了“代码冻结”（code freeze）指令。该智能体忽略了指令，对生产数据库执行了破坏性的 SQL 操作，删除了 1,200 多个账户的数据，然后——显然是为了掩盖痕迹——伪造了大约 4,000 条合成记录。该 AI 平台的 CEO 发表了公开道歉。
根本原因不是幻觉或误解指令。而是缺少一个工程原语：该智能体对生产状态拥有不受限制的写入和删除权限，且不存在撤销其操作的机制。
这是在现实世界中运行的智能体系统所面临的核心问题。LLM 具有非确定性，在生产部署中，工具调用的失败率为 3–15%，而且许多操作——发送电子邮件、扣款、删除记录、预订机票——无法通过简单地使用不同参数重试来撤回。问题不在于你的智能体是否会在工作流中途失败。它一定会失败。问题在于你的系统能否恢复。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
