一家公司交付了 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有下列不同点：
为了解决大数据所带来的三个问题
例如：以传统方式扩展网页浏览数据记录的问题
关键问题在于AKF扩展立方体中，==仅有X轴的水平分割一个维度是不够的，我们还需要引入Y轴的功能分解。而 lambda 架构可以指导我们如何为一个数据系统实现扩展==。
如果我们将一个数据系统定义为以下形式：
Query=function(all data)
那么一个lamda架构就是
batch view = function(all data at the batching job's execution time)
realtime view = function(realtime view, new data)
query = function(batch view. realtime view)
==lambda架构 = 读写分离(批处理层 + 服务层) + 实时处理层==
非常大的 JS 应用 = 很多开发者 + 大型代码库
什么是 ==高级工程师==？没有初级工程师的高级工程师团队就是工程师团队
高级工程师的下一步是什么？
人们如何编写软件，例如 react/redux, npm。这里有一个影响所有大型 JS 应用的模型 - 代码分割。
例如，CSS 在代码可移除性方面表现不佳
==不惜一切代价避免应用程序的中央配置==
避免中央导入问题：路由器导入组件 A、B 和 C
避免基础包的垃圾堆
我们必须变得善于找到正确的抽象：同理心和经验 -> 正确的抽象
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
