Google DeepMind 在 2025 年末发布的一项研究分析了 5 种架构和 3 个大语言模型（LLM）家族中的 180 种多智能体配置。在讨论部分被掩盖的一个发现是：与单智能体基准相比，非结构化多智能体网络将错误放大了高达 17.2 倍。不是修复错误——而是放大错误。智能体们自信地在彼此的幻觉基础上进行构建，创造出回声壁效应，使每个独立模型的失败模式显著恶化。
这是多智能体对话框架核心的悖论。赋予它们强大力量的特性——智能体进行协商、批判、委派和修订——如果缺乏周密设计，也正是让它们变得危险的原因。理解基于对话的编排（orchestration）与传统流水线链式调用（pipeline chaining）之间的区别，是正确使用这两者的第一步。
2024 年，90% 的智能体 RAG（Agentic RAG）项目在生产环境中失败了。原因并非技术本身存在缺陷，而是工程师们仅仅将向量搜索、提示词（prompt）和大语言模型（LLM）组合在一起，称之为检索管道并直接发布——却忽略了从查询到回答之间每一层累积的失败成本。
经典的 RAG 是一个确定性函数：嵌入查询 → 向量搜索 → 填充上下文 → 生成。它单向运行一次，没有反馈循环。当查询是针对分块良好的语料库进行简单的单步查找时，这种方式很有效。但当用户询问“比较这五份合同中的责任条款”或“总结自第三季度事故以来我们的基础设施配置发生了哪些变化”，或者任何需要先综合多份文档中的证据才能形成答案的问题时，它就会惨遭失败。
那些真正在为生产环境客户交付可靠 AI 智能体的团队，大多并未使用智能体框架。他们选择自研。
这一观察源自与 100 多位技术创始人的交流，也是 12 要素智能体（12-Factor Agents）框架那个令人不安的起点——这是一份旨在构建能够投入生产、而非永远停滞在 80% 质量水平的 LLM 驱动型软件的宣言。该框架刻意借鉴了塑造了一代 Web 服务的原始 12 要素应用（12-Factor App）方法论。这种类比是成立的：正如 12 要素应用为团队提供了构建可部署 Web 服务的原则性方法，12 要素智能体也为构建可靠、可观测的 AI 系统提供了原则。
这个拥有 19,000 颗星的 GitHub 仓库记录了表现最出色的生产团队独立摸索出的经验。以下是他们的共识。
一家公司交付了 7,949 个 AI Agent。其中只有 15% 能够正常工作。其余的要么静默失败，要么陷入死循环，或者在执行任务中途前后矛盾。这并非个别现象——企业级分析一致发现，88% 的 AI Agent 项目从未进入生产阶段，95% 的生成式 AI 试点项目以失败告终或表现严重不及预期。引人入胜的演示 (Demo) 与可靠系统之间的差距并非模型问题，而是架构问题。
那些成功交付了实际可用 Agent 的工程师们，在架构决策上达成了一系列共识，而这些决策与框架教程中的玩具示例截然不同。本文将探讨这些决策：层级如何划分、故障集中在哪里，以及为什么最难的问题从来不是提示词 (Prompt)。
大多数团队都是事后才给他们的智能体添加记忆功能——通常是在用户抱怨智能体忘记了三轮对话前明确告知的信息之后。那时，解决方案似乎显而易见：把对话存储起来，以后再检索。但这种直觉往往导致系统在演示中表现出色，而在生产环境中却一塌糊涂。一个仅仅存储信息的记忆系统，与一个能在正确的时间可靠地呈现正确信息的系统之间存在巨大鸿沟，大多数智能体项目正是悄然失败于此。
记忆架构并非次要问题。对于任何处理多轮交互的智能体——无论是客户支持、编码助手、研究工具还是语音界面——记忆都是区分有状态助手和昂贵自动补全的关键。如果处理不当，智能体不会崩溃；但它会让人感觉有些不对劲，自相矛盾，或者自信地重复着用户两周前纠正过的过时信息。
大多数在生产环境中部署的多智能体 LLM 系统，在几周内就会失败 — 失败并非源于基础设施中断或模型退化，而是因为从一开始就存在的协调问题。对七个开源框架的 1,642 条执行轨迹进行全面分析后发现，在标准基准测试中，其故障率在 41% 到 86.7% 之间。这不是模型质量问题，而是系统工程问题。
令人不安的发现是：约 79% 的故障可追溯到规范和协调问题，而非计算限制或模型能力。即使你换一个更好的模型，你的多智能体管道仍然会以同样的方式崩溃。要理解其原因，你需要仔细审视故障分类。
大多数智能体故障都是架构故障。当任务偏离轨道时，模型往往会受到指责，但十有八九，真正的问题在于没有人充分思考规划、工具使用和反思应该如何协同工作。即使你换一个更好的模型，仍然可能会遇到同样的崩溃——因为模型周围的支架从未被设计成处理模型被要求完成的任务。
本文是一份关于智能体内部实际工作原理的实用指南：核心组件是什么，规划在哪里出错，反思循环如何帮助（以及何时会损害），以及当你为生产而非演示构建多智能体系统时它们会是什么样子。
大多数多智能体系统的失败，不是因为模型出了问题，而是因为"管道"存在漏洞。智能体在任务执行中途丢失上下文，将任务移交给错误的专家，或者因为不知道如何退出而陷入无限循环。根本原因几乎总是相同的：系统设计只关注每个智能体能做什么，却没有清晰定义工作如何在它们之间流转。
两个原语可以解决大部分问题：例程（routines）和交接（handoffs）。它们看似简单，但把它们做对，是一个能演示的系统和一个能上线的系统之间的关键区别。
具体来讲，Lyft 的广告投放要服务如下特点
主要的挑战是：难以规模化管理跨地域营销中的各个环节，广告竞标、预算、素材、激励、选择受众、测试等等。下图是营销者的一天：
我们可以发现“执行”占去了大部分的时间，而更少的时间花在了更重要的“分析和决策”上。规模化意味着减少繁复的操作，让营销人员专注于分析与决策。
为了降低成本，提高做实验的效率，需要
数据由 Lyft 的 Amundsen 系统做增强学习。
自动化的部分包括：
技术栈：Apache Hive, Presto, ML platform, Airflow, 3rd-party APIs, UI.
用户的终身价值是衡量渠道的重要标准，预算由 LTV 和我们愿意为该地区的获客付出的价格共同决定。
我们对新用户的认知有限，随着交互的增多，所提供的历史记录会更准确地预测。
一开始的特征值：
随着历史上的交互记录的积累，做出的判断就会越准确：
搞定了 LTV，接下来是根据价格定预算。拟合出 LTV = a * (spend)^b 形式的曲线以及周围的区间里类似参数的曲线。为了找到全局最优，需要付出一些随机性的代价。
分为两部分，一部分是调参者，一部分是执行者。调参者根据定价，设定基于渠道的具体的参数；执行者把这些参数执行到具体的渠道上。
有很多流行的投放策略，在各色的渠道中，是共通的：
要注意人的经验在系统中的重要性，否则会 garbage in, garbage out. 当人从繁琐的投放任务解放出来，专注于理解用户、理解渠道、理解自身要传达给受众的信息之后，就能够获得更好的投放效果——花更少的时间达到更高的 ROI。
构架是软件系统的形状。拿建筑物来举例子：
他们共同服务于一个特定的目的，就像医院治疗病人，学校教育学生一样。
每一个软件系统提供两个不同的价值给利益相关者：行为与结构。软件开发者必须确保这两项价值都要高
==由于其工作的需要，软件架构师更多地聚焦于系统的结构而不是特性和功能。==
架构服务于软件系统的整个生命周期，使其易于理解，开发，测试，部署和操作。 其目标是最小化每个业务用例的人力资源成本。
O’Reilly 出版的《软件架构》一书很好地介绍了这样五种基本的构架。
分层架构是被广泛采用，也是被开发者所熟知的一种架构。因此，它也是应用层面上事实上的标准。如果你不知道应该使用什么架构，用分层架构就是不错的选择。
示例
优缺点：
任何一个状态的改变都会向系统发出一个事件。系统组件之间的通信都是经由事件完成的。
一个简化的架构包含中介(mdiator)，事件队列(event queue)和通道(channel)。下图所示即为简化的事件驱动架构：
示例
软件的功能被分散到一个核心和多个插件中。核心仅仅含有最基本的功能。各个插件之间互相独立并实现共享借口以实现不同的目标。
示例
大型系统被解离成众多微服务，每一个都是单独部署的单位，他们之间通过RPCs进行通信。
示例
“基于空间的架构”这一名称来源于“元组空间”，“元组空间“有”分布式共享空间“的含义。基于空间的架构中没有数据库或同步数据库访问，因此该架构没有数据库的瓶颈问题。所有处理单元共享内存中应用数据副本。这些处理单元都可以很弹性地启动和关闭。
示例：详见 Wikipedia
result = pairs.map((pair) => (morePairs)).reduce(somePairs => lessPairs)一样简单。若要用商业机器来满足以上的需求，有这些热门的分布式系统架构……
| 架构 | Storm | Storm-trident | Spark | Flink |
|---|---|---|---|---|
| 模型 | 原生 | 微批量 | 微批量 | 原生 |
| Guarentees | 至少一次 | 一次 | 一次 | 一次 |
| 容错性 | 记录Ack | 记录Ack | 检查点 | 检查点 |
| 最大容错 | 高 | 中 | 中 | 低 |
| 延迟 | 非常低 | 高 | 高 | 低 |
| 吞吐量 | 低 | 中 | 高 | 高 |
移动开发人员会在以下三个层面上评估一个架构的好坏：
| 职责分配的均衡性 | 易测试性 | 易用性 | |
|---|---|---|---|
| 紧耦合MVC | ❌ | ❌ | ✅ |
| Cocoa MVC | ❌ V和C 是耦合的 | ❌ | ✅⭐ |
| MVP | ✅ 独立的视图生命周期 | ✅ | 一般：代码较多 |
| MVVM | ✅ | 一般：视图（View）存在对UIKit的依赖 | 一般 |
| VIPER | ✅⭐️ | ✅⭐️ | ❌ |
举一个例子，在一个多页面的网页Web应用程序中，当你点击一个链接导航至其他页面的时候，该页面就会被全部重新加载。该架构的问题在于视图（View）与控制器（Controller）和模型（Model）是紧密耦合的。
Cocoa MVC 是苹果公司建议iOS开发者使用的架构。理论上来说，该架构可以通过控制器（Controller）将模型（Model）与视图（View）剥离开。
然而，在实际操作过程中，Cocoa MVC 鼓励大规模视图控制器的使用，最终使得视图控制器完成所有操作。
尽管测试这样的耦合大规模视图控制器是十分困 难的，然而在开发速度方面，Cocoa MVC是现有的这些选择里面表现最好的。
在MVP中，Presenter与视图控制器（view controller）的生命周期没有任何关系，视图可以很轻易地被取代。我们可以认为UIViewController实际上就是视图（View）。
还有另外一种类型的MVP：带有数据绑定的MVP。如下图所示，视图（View）与模型（Model）和控制器（Controller）是紧密耦合的。
MVVM与MVP相似不过MVVM绑定的是视图（View）与视图模型（View Model）。
不同于MV(X)的三层结构，VIPER具有五层结构（VIPER View, Interactor, Presenter, Entity, 和 Routing）。这样的结构可以很好地进行职责分配但是其维护性较差。
相较于MV(X)，VIPER有下列不同点：
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
