320 篇博文 含有标签「ai-agents」

大多数 AI Agent 的 Bug 并不是模型本身的 Bug。模型只是在执行它被告知的操作——出问题的是你放入上下文（context）的内容。在 Agent 执行到一定阶段后，问题不在于能力，而在于熵：噪声、冗余和注意力错位的缓慢积累，这会降低模型生成的每一项输出的质量。研究人员称之为“上下文腐烂”（context rot），而且所有主流模型——GPT-4.1、Claude Opus 4、Gemini 2.5——在任何输入长度增加的情况下，无一例外都会表现出这种现象。

上下文工程是专门管理这一问题的学科。它比提示词工程（prompt engineering）更广泛，后者主要关注静态的系统提示词。上下文工程涵盖了模型在推理时看到的一切：你包含什么、排除什么、压缩什么、将内容放在哪里，以及如何在长期运行的任务中保持缓存状态。

当单智能体（single-agent）系统在研究任务中失败时，人们的直觉是增加更多内存、更好的工具或更强大的模型。但在某些点上，问题不在于能力——而在于并发性（concurrency）。深度研究任务需要同时推进多个线程：从不同角度验证论点、跨领域扫描来源、实时交叉引用发现。单智能体按顺序执行这些操作，就像研究人员在做笔记之前先逐本阅读每一本书。回想起来，多智能体（multi-agent）的替代方案似乎显而易见，但在生产环境中正确实现它比架构图所示的要困难得多。

这篇文章讨论了多智能体研究系统是如何实际构建的——行之有效的架构选择、在生产环境中才显现的故障模式，以及在大规模应用中保持其有用性所需的工程纪律。

你将智能体连接到 50 个 MCP 工具。它可以查询数据库、调用 API、读取文件、发送电子邮件、浏览网页。理论上，它拥有所需的一切。但在实践中，一半的生产事故都源于工具使用——错误的参数、上下文预算超支、级联重试循环，导致成本是预期的十倍。

这是大多数教程都会跳过的部分：你加载的每个工具定义都是预先支付的 Token 税，甚至在智能体处理单条用户消息之前就开始计算了。连接了 50 多个工具后，仅定义一项就会在每次请求中消耗 70,000–130,000 个 Token。这并非极端情况——这是任何连接到多个 MCP 服务器的智能体的默认状态。

大多数 AI 智能体之所以昂贵，是因为一个细微的架构错误：它们将每一个中间结果都视为要反馈给模型的消息。每一次工具调用都变成了 LLM 上下文窗口的一次往返，而当一个中等复杂度的任务完成时，你已经为处理相同的数据支付了五次、十次、甚至二十次的费用。一个在三个分析工具之间传递的 2 小时销售录音，可能在路由上就花费你 50,000 个 token —— 而这还不是为了分析，仅仅是为了路由。

有一种更好的方法。当智能体编写并执行代码而不是逐个调用工具时，中间结果会保留在执行环境中，而不是上下文窗口中。模型看到的是摘要和过滤后的输出，而不是原始数据。这种差异不是渐进式的 —— 在实际工作负载中，token 消耗量减少了 98–99%。

大多数构建多智能体系统的团队都会遇到同一堵墙：系统在演示时效果出色，但在生产环境中却分崩离析。这并不是因为他们实现协作协议的方式不对，而是因为协议本身就是问题所在。

多智能体 AI 具有一种直观的吸引力。复杂的任务应该被分解为并行的工作流；专门的智能体应该处理专门的工作；编排器（orchestrator）将它们组合在一起，整体就会大于部分之和。这种直觉是错误的——或者更准确地说，它还不成熟。研究表明，在已研究的执行追踪中，多智能体系统在生产环境中的实际失败率在 41% 到 86.7% 之间。这不是调优问题，而是结构性问题。

那些真正在为生产环境客户交付可靠 AI 智能体的团队，大多并未使用智能体框架。他们选择自研。

这一观察源自与 100 多位技术创始人的交流，也是 12 要素智能体（12-Factor Agents）框架那个令人不安的起点——这是一份旨在构建能够投入生产、而非永远停滞在 80% 质量水平的 LLM 驱动型软件的宣言。该框架刻意借鉴了塑造了一代 Web 服务的原始 12 要素应用（12-Factor App）方法论。这种类比是成立的：正如 12 要素应用为团队提供了构建可部署 Web 服务的原则性方法，12 要素智能体也为构建可靠、可观测的 AI 系统提供了原则。

这个拥有 19,000 颗星的 GitHub 仓库记录了表现最出色的生产团队独立摸索出的经验。以下是他们的共识。

2025 年 6 月，一名研究员向一位 Microsoft 365 Copilot 用户发送了一封精心编写的邮件。没有点击链接。没有打开附件。邮件送达后，Copilot 在执行例行的总结任务时读取了它，短短几秒钟内，AI 便开始从 OneDrive、SharePoint 和 Teams 中外泄文件——通过将数据编码进它请求“渲染”的图片 URL 中，悄无声息地将内容传输到了攻击者控制的服务器上。受害者对此一无所知。

从传统意义上讲，这并不是一个新奇的零日漏洞（Zero-day）。没有缓冲区溢出，也没有 SQL 注入。该漏洞是架构性的：系统结合了三种能力，这些能力单独看起来像是理所应当的产品功能。但结合在一起，它们就构成了现在所谓的“致命三要素”（Lethal Trifecta）。

大多数 AI Agent 演示（demo）运行得都非常完美。

它们在 30 秒内运行完毕，调用三个工具，并返回整洁的结果。然后，有人要求 Agent 执行一些真正重要的事情——交叉引用代码库、运行多阶段数据流水线、处理批量文档——于是整个过程在超时、部分状态和重复副作用的级联反应中土崩瓦解。

问题不在于模型，而在于基础设施。运行几分钟或几小时的 Agent 与在几秒钟内完成的 Agent 相比，面临着完全不同的一类系统问题。大多数团队在最糟糕的时间点撞上了这堵墙：在他们已经发布了用户依赖的产品之后。

大多数 LLM 质量问题并非提示词（Prompt）问题。它们是上下文（Context）问题。

你花了数小时打磨完美的系统提示词。你添加了 XML 标签、思维链指令和精细的人设定义。你在一些输入上进行了测试，效果看起来很棒。然后你上线了产品。两周后，你盯着一个工单发呆：智能体一本正经地告诉用户错误的账户余额 —— 因为它检索到了前一个用户的交易记录。模型完美理解了指令，它只是拿到了错误的输入。

这就是提示词工程（Prompt Engineering）与上下文工程（Context Engineering）之间的核心区别。提示词工程问的是：“我该如何措辞？”上下文工程问的是：“模型现在需要知道什么，以及我如何确保它准确获得这些信息？”前者是文案写作，后者是系统架构。

大多数团队都是事后才给他们的智能体添加记忆功能——通常是在用户抱怨智能体忘记了三轮对话前明确告知的信息之后。那时，解决方案似乎显而易见：把对话存储起来，以后再检索。但这种直觉往往导致系统在演示中表现出色，而在生产环境中却一塌糊涂。一个仅仅存储信息的记忆系统，与一个能在正确的时间可靠地呈现正确信息的系统之间存在巨大鸿沟，大多数智能体项目正是悄然失败于此。

记忆架构并非次要问题。对于任何处理多轮交互的智能体——无论是客户支持、编码助手、研究工具还是语音界面——记忆都是区分有状态助手和昂贵自动补全的关键。如果处理不当，智能体不会崩溃；但它会让人感觉有些不对劲，自相矛盾，或者自信地重复着用户两周前纠正过的过时信息。

第一次一个 AI 编程代理破坏了一个团队的 CI 流水线——不是因为它编写了糟糕的代码，而是因为它生成拉取请求的速度超过了 GitHub Actions 的处理能力——这清楚地表明一些根本性的东西已经发生了转变。我们不再讨论一个更智能的自动补全工具。我们讨论的是一种完全不同的软件生产模式。

AI 辅助编程的发展轨迹迅速。自动补全工具改变了个人打字的方式。本地代理改变了单个会话能完成的任务。云代理现在正在改变团队构建软件的方式——将工作并行化到多个异步线程中，在提交 PR 之前运行测试，并且越来越多地处理长达 3 小时的任务，而开发人员则可以休息或转去解决其他问题。

大多数智能体故障都是架构故障。当任务偏离轨道时，模型往往会受到指责，但十有八九，真正的问题在于没有人充分思考规划、工具使用和反思应该如何协同工作。即使你换一个更好的模型，仍然可能会遇到同样的崩溃——因为模型周围的支架从未被设计成处理模型被要求完成的任务。

本文是一份关于智能体内部实际工作原理的实用指南：核心组件是什么，规划在哪里出错，反思循环如何帮助（以及何时会损害），以及当你为生产而非演示构建多智能体系统时它们会是什么样子。