一支工程团队构建了一个处理客户请求的 Agent。演示效果非常好。他们将其部署上线。三周后，这个 Agent 悄无声息地以十足的自信向用户传达错误信息，在上下文变长时跳过步骤，还会在模糊输入上偶尔陷入死循环。事后复盘发现，团队从未构建重试逻辑，从未验证输出，也从未定义 Agent 在不确定时该怎么做。当被问及原因，答案耐人寻味："我们以为它会自己处理那些边缘情况。"
"我们以为它会自己处理那些边缘情况"——这句话将拟人化税表露无遗。团队设计这个系统的方式，就像管理一名初级开发者：简要说明任务，信任其判断，等它举手求助时再纠正。但 LLM Agent 不会举手。它们只是生成下一个 token。
MCP 生态已拥有 10,000+ 服务器和 9700 万次 SDK 下载量。但同时也在六十天内出现了 30 个 CVE、502 个未锁定版本的服务器配置，以及一个在十五个版本中悄悄将每封外发邮件密送给攻击者的供应链攻击。可组合性的承诺——「只需再接入一个 MCP 服务器」——是真实的。但它带来的依赖蔓延也是真实的，大多数团队在深陷集成债务之后才发现其代价。
如果你在 npm 上构建过生产系统，你一定看过这部电影。MCP 生态正在加速重演同一剧情，只不过这次的「包」拥有对你机器的 shell 访问权限和生产系统的凭证。
你的 agent 在开发环境中运行完美。它能推理多步任务，自信地调用工具，生成精美的输出。然后你设置了每次请求 $0.50 的成本上限，它就崩溃了。不是优雅地降级——而是灾难性的崩溃。它在推理过程中截断自己的思考，忘记三步前的工具结果，并基于被静默丢失的上下文自信地给出错误答案。
这就是丰裕设计的 agent 和生产受限 agent 之间的差距。大多数 agent 架构都是在无限 token 预算下原型化的——长系统提示词、冗长的工具 schema、完整的文档检索、未压缩的对话历史。当你引入硬上限（成本上限、上下文限制、延迟要求）时，这些 agent 不会优雅地降级。它们以难以检测且调试成本高昂的方式崩溃。
每个智能体的演示都从三个工具开始。一个网页搜索，一个计算器，也许再加一个代码执行器。智能体每次都表现完美。于是你上线了，团队开始添加各种集成——Slack、Jira、GitHub、邮件、数据库查询、内部 API。六个月后，你的智能体拥有了 150 个工具，却有 40% 的概率选错。
这就是工具爆炸问题，也是生产环境智能体系统中最少被讨论的失败模式之一。退化并非线性的——而是断崖式的。一个在 5 个工具时准确率达 95% 的智能体，在你给它 100 个工具时可能会跌破 30%，即使模型和提示词完全没有改变。
在每个 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 系统。在某些工作负载中，协作确实能带来真正的收益。但这种追求专门化的默认本能，正让生产团队在金钱、延迟和可靠性方面付出真实的代价——而且往往没有任何可衡量的准确率提升。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
