在 AI 工程领域，一直存在一种固有的假设：获得更好输出的路径是更好的模型。更大的上下文窗口、更新的训练数据、更高的基准测试分数。在实践中，交付最强大 AI 产品的团队通常在做一些不同的事情：他们正在构建流水线（pipelines），由多个专门的组件——检索器（retriever）、重排序器（reranker）、分类器（classifier）、代码解释器（code interpreter）以及一个或多个语言模型——协同工作，处理任何单一模型都无法独立可靠完成的任务。
这种架构模式有一个名字——复合 AI 系统（compound AI systems）——它现在是生产级 AI 的主导范式。了解如何正确构建这些系统，以及在构建不当时它们会在哪里失效，是当今应用 AI 工程中最重要的技能之一。
每个生产级智能体系统最终都会遭遇一个没有人预料到的故障：智能体订好了机票，却找不到酒店，留给用户的是半张已确认的行程单，以及毫无头绪的后续。这不是崩溃，也不是拒绝执行，只是一个停止运行的智能体——带着真实的副作用，却没有任何后续计划。
对智能体故障的标准认知是二元的——要么成功，要么中止。重试逻辑、指数退避、回退提示词——这些机制都假设"任务运行中"与"任务完成"之间存在清晰的边界。但真实的智能体会在中途失败，而当这种情况发生时，缺乏部分完成设计本身就是 bug。你不需要更智能的模型，你需要的是一个任务状态机。
大多数 AI 工程团队都有着相同的故事。他们从一个真正需要 LLM 的难题开始。然后，一旦 LLM 基础设施到位，每一个新问题在他们眼中都成了那把锤子下的钉子。六个月后，他们甚至在调用 GPT-4o 来检查电子邮件地址是否包含 “@” 符号 —— 并且还在为此付费。
这种 “直接用模型” 的本能反应现在是 AI 应用中不必要的复杂性、虚高成本和脆弱生产系统的主要驱动力。这并不是因为工程师们粗心大意。而是因为 LLM 确实令人印象深刻，工具链降低了使用门槛，而且一旦你构建了 LLM 流水线，增加另一次调用感觉成本极低。事实并非如此。
大多数团队选择 LLM 的方式就像选择数据库引擎一样：在架构评审时选一次，然后再也不改。你选了 GPT-4o 或 Claude 3.5 Sonnet，把它写进配置文件，然后上线。这个选择感觉无法逆转，因为更改它需要重新部署、跨服务协调，以及针对本周 eval 的回归测试。
这种思维方式是错误的。你的流量并不是同质的。"总结这篇文档"和"调试这个神秘堆栈跟踪"两个请求同时打到同一个接口，对能力的需求天差地别——但从静态模型选择的基础设施视角来看，两者毫无区别。你要么对其中一个过度供给，要么对另一个供给不足，而且每一个请求都是如此。
模型路由将 LLM 的选择视为运行时分发决策。每个进入的查询都会根据能预测该请求最合适模型的信号进行评估，并据此进行分发。路由层不存在于配置文件中——它运行在你的请求路径上。
这是一个几乎出现在每个生产 AI 部署中的模式：团队发布了一个能够处理 90% 查询的功能。然后开始收到投诉。某用户提了一个超出训练分布的问题，模型自信地给出了错误答案。RAG 流水线检索到一份过时文档，模型却将其当作最新信息来回答。一个法律查询触及了提示没有覆盖的边缘情况，模型靠猜测蒙混过关。在每一种情况下，修复方案都不是换一个更好的模型，而是让系统学会说"我不知道"。
弃权——有原则地决定不回答——是 AI 系统设计中最难、最被低估的能力之一。几乎所有产品工作都致力于让答案更好，几乎没有任何工作致力于让系统可靠地知道何时该拒绝作答。这种不对称是一种在生产环境中不断累积的设计债务。
你的 AI Agent 运行得一切正常，直到某一刻它彻底不行了。某个工具宕机——也许是搜索 API 触发了限流，也许是数据库响应迟缓，也许是代码执行沙箱超时——整个 Agent 随之崩溃。不是部分答案，不是降级响应，而是彻底失败。要么一片空白，要么满是幻觉。
这不是一个 Bug，而是一个设计选择——而且几乎没有人是刻意做出这个选择的。我们今天所构建的 Agent 架构隐式地选择了"彻底失败"，原因只有一个：没有人设计过部分可用路径。如果你有分布式系统的经验，这个模式应该让你感到似曾相识。这正是 CAP 定理，以一副新的面孔出现了。
大多数部署 AI Agent 的团队在实现了提示词缓存 (Prompt Caching)，或许再加上语义缓存之后，就认为大功告成了。但他们实际上错失了 40-60% 的潜在节省空间。原因并非在于懒惰 —— 而是 Agent 工作负载产生的缓存问题在简单的请求-响应式 LLM 调用中并不存在，其解决方案需要从传统 Web 缓存从未涉及的层级进行思考。
单个 Agent 任务可能涉及一个 4,000 Token 的系统提示词、三个分别返回不同结构数据的工具调用、一个在结构上与昨天完全相同的多步计划，以及一个需要在对话中持久化但绝不能跨用户共享的会话上下文。其中每一项都代表了不同的缓存机会，具有不同的 TTL (生存时间) 要求、不同的失效触发机制，以及在缓存失效时不同的故障模式。
大多数团队都是以同样的方式发现请求合并的：收到一张出乎意料的大额账单。他们上线了基于 LLM 的功能，使用量增长，然后账单仪表板显示他们每天为五万个请求付费，而仔细观察后发现其中大约三万个请求在问同一件事，只是措辞略有不同。每一个"总结这份文档"的改写都单独命中了模型。每一个近乎重复的请求都触发了完整的推理周期。成本随流量规模线性增长，而不是随用户实际想要的语义多样性增长。
请求合并正是解决这一问题的模式。它不是单一技术，而是一种分层架构：用于防止并发重复的飞行中去重、用于重复相同提示的精确缓存，以及用于捕捉中间改写变体的语义批处理。顺序很重要，阈值很重要，理解该模式何处会失效——尤其是围绕流式传输——是可用实现与那种在暂存服务器上节省了钱但在生产中引发隐蔽 bug 的实现之间的差别所在。
在 2024 年 12 月 11 日，OpenAI 发生了一次灾难性的故障，使 ChatGPT、他们的 API 和 Sora 中断了超过四个小时。虽然故障发生在每家公司身上，但这次故障特别引人注目，因为它揭示了现代系统设计的一个关键教训：有时我们添加的工具以防止故障，反而成为故障的根源。
有趣的是：这次故障并不是由于黑客攻击、部署失败，甚至不是他们的 AI 模型中的错误引起的。相反，它是由于一个旨在提高可靠性的工具引起的。OpenAI 正在添加更好的监控以防止故障时，意外地造成了他们有史以来最大的故障之一。
这就像雇佣一个保安，结果他把所有人都锁在了楼外。
事件的经过如下：
但最有趣的部分不是故障本身，而是多个保障系统同时失败：
遥测服务在测试中工作得很好。问题只在部署到数千个节点的集群时出现。这突显了现代系统设计中的一个基本挑战：一些问题只在规模上出现。
OpenAI 的 DNS 缓存，旨在提高可靠性，实际上通过掩盖问题使情况变得更糟，直到为时已晚。他们的 Kubernetes 控制 面板，旨在管理集群健康，成为了单点故障。
最令人震惊的部分？工程师无法修复问题，因为他们需要正常工作的系统来修复损坏的系统。这就像需要一把梯子才能够到你需要的梯子。
OpenAI 的响应计划揭示了系统设计的未来走向：
即使你不是在 OpenAI 的规模下运营，这些教训依然适用：
可靠系统的未来并不是防止所有故障，而是确保我们能够快速而优雅地从故障中恢复。
记住：最危险的问题不是我们能预见到的，而是那些从我们构建的保障系统中突然冒出来的。
Optimism 是一种 EVM 等效的乐观汇总协议，旨在扩展以太坊。
乐观汇总通过将多个交易打包成一个单一交易来工作，然后由以太坊网络上的智能合约进行验证。这个过程被称为“汇总”，因为单个交易被组合成一个更大的交易，并提交到以太坊网络。术语“乐观”指的是系统假设交易是有效的，除非有证据证明相反，这使得交易的处理更快、更高效。
.png "Optimism 架构")
汇总节点可以以验证者或排序者模式运行：
批量提交者，也称为 批处理器，是将 L2 排序者 数据提交到 L1 的实体，以使其对验证者可用。
提议者生成并提交 L2 输出检查点到以太坊上的 L2 输出预言机合约。在最终确认期结束后，这些数据使提款成为可能。
批处理器和提议者都将状态提交到 L1。为什么它们被分开？
批处理器收集并将交易数据批量提交到 L1，而提议者将承诺（输出根）提交到 L2 的状态，从而最终确定 L2 账户状态的视图。它们是解耦的，以便可以并行工作以提高效率。
各种合约用于 L2 与 L1 进行交互：
理解 OP 堆栈可能会很具挑战性，原因有很多。其中一个因素是许多组件在代码和文档中多次以略微不同的名称被提及。例如，术语“op-batcher”和“批量提交者” / “验证者”和“验证器”可能可以互换使用，这导致混淆和理解每个组件的确切功能的困难。
理解 OP 堆栈的另一个挑战是不断发展的架构，这可能导致某些设计元素随着时间的推移而被弃用。不幸的是，文档可能并不总是更新以反映这些变化。这可能导致进一步的混淆和理解系统的困难，因为用户可能正在使用过时或不准确的信息。
为了克服这些挑战，重要的是仔细审查所有可用文档，保持概念在各个地方的一致性，并随时了解 OP 堆栈的任何变化或更新。这可能需要额外的研究和与其他用户或开发者的合作，但这是完全理解和有效利用这个复杂系统的必要条件。
分布式 系统有两种实现方式：
因为前提条件是节点之间不大信任，所以选择 P2P 的形式。具体到如何组织 P2P 的网络呢？一个典型的去中心化的节点和网络是这样保持连接的：
我们可以利用既有的库，比如 libp2p，来实现网络模块。网络协议的选择见Crack the System Design Interview: Communication.
在互相不大信任的分布式系统中，一笔转账如何在不泄漏自己秘密信息的同时证明这个转账是自己发起的呢？非对称加密：一对公钥和私钥对应一个”所有权”。Bitcoin 选择 secp256k1 参数的 ECDSA 椭圆曲线加密算法，为了兼容，其他链也基本选择同样的算法。
为什么不直接把公钥作为转账的地址呢？隐私问题，交易的过程应该尽可能少地泄漏信息，用公钥的哈希作为“地址”可以避免接收方泄露公钥。甚至，人们应该避免反复使用同一个地址。
具体到账本的账户，有两种实现方式 UTXO vs. Account/Balance
值得一提的是 “区块 + 链” 的数据结构本质上来讲，就是 append-only 的 Merkle tree，也被称为 hash tree.
因为本身 UTXO 或者 MPT 这种结构就充当了索引，加上分布式的时候，为了让每个节点运维更加简单，一般做 data persistence 的时候倾向于选择 in-process database 随着节点的程序能够直接跑，比如 LevelDB, RocksDB。
因为这种索引并不是通用的，所以你并不能像是 SQL 数据库那样查询，这也为数据分析提高了门槛，优化时需要专门做一个 indexer 服务，比如 etherscan。
现在我们有了可以操作的基础层后，在这层之上，我们需要一个比较通用的逻辑操作的协议层。根据这个区块链的使用需求，可以像是微内核构架那样，插拔具体的逻辑处理模块。
比如最常见的记账：在最新的 block 高度收到了一些 transaction，组织起来建立如上一层构架所说的数据结构。
为每一个业务逻辑写一个原生模块然后更新所有节点的代码不大现实，用虚拟化的方法解耦这一层？答案是能够执行 smart contract 代码的虚拟机。在互不可信的环境中，不能让客户白执行代码，所以这个虚拟机最独特的功能可能是计费。
基于 contract 的 token 比如 ERC20 和 native token 的区别，导致在不同的 token 捣腾的时候很麻烦，于是就出现了 Wrapped Ether 这种 token.
协议层算出来执行的结果之后，如何跟其他的节点达成一致呢？有如下一些常见的激励大家合作的机制：
在激励机制的基础上，节点中谁的链最长听谁的，两群人互不待见就分叉。
同时，有这样一些一致性协议让大家达成共识（也就是大家要么一起都干，要么一起都不干）
在具体的应用中，关系数据库大多用 2PC 或者 3PC ；Paxos 的变种有 Zookeeper 的实现，Google Chubby 分布式锁的实现，Spanner 的实现；区块链中，Bitcoin, Ethereum 是 POW，新的 Ethereum 是 POS，IoTeX 和 EOS 是 DPOS。
如果问硅谷的公司跟中国最大的不同是什么，我想答案很可能正如吴军所言，硅谷公司的产品大多面向全球市场。陈志武说的好，创造财富能力有三个衡量维度：深度，即生产力，同样的时间提供更好产品或服务的能力；长度，即利用金融杠杆，跨越时间和空间交换价值的能力；广度，即市场大小，开创跨越地域的市场或者新行业的能力。而国际化，也就是产品和服务在语言和文化上的本地化，正是跨国公司征战全球市场的战略要地。
Internationalization 因为字母 i 后面跟了 18 个字母然后以 n 结尾，所以被称为 18n，我们这次设计的 i18n 工程方案主要是解决网站和移动 App 开发过程中的如下问题：
语言的本质是把消息交付给受众的媒介，不同的语言就是不同的媒介，不同的媒介面向不同的受众。比如，我们要对用户显示文字：“你好，小丽！”，显示的过程就是查一下语言表，根据用户的语言，和当前需要的插值，比如姓名，显示相应的消息：
| Message Codes | Locales | Translations |
|---|---|---|
| home.hello | en | Hello, ${username}! |
| home.hello | zh-CN | 你好, ${username}! |
| home.hello | IW | !${username}, שלום |
| … | … | … |
不同语言在细节上略有不同，比如一个物品的单数和复数的形式；比如第三人称，在称呼上男性和女性的区别。
这些都是简单的查表无法应对的问题，需要更复杂的逻辑处理。在代码中你可以无脑地使用条 件语句去处理这些特例。此外有一些国际化的框架会发明 DSL (domain specific language) 来专门应对这种情况。以 The project fluent 为例：
还有一个新手容易忽略的问题是行文的方向。中文和英文等常用语言是从左至右的，但是还有一些语言，是从右往左的，比如希伯来文和阿拉伯文。
行文方向的不同不仅仅会影响到文字本身，还会影响到输入的方式。中国人如果从右至左输入会觉得非常的奇怪；而我的一位犹太同事就觉得英文和犹太文混着输入轻而易举。
还有一种情况就是布局。整个 UI 的布局、视觉元素比如箭头的方向。都可能会根据语言的方向的不同而发生变化。你的 HTML 需要设置好相应的 dir 属性。
你可能会问，我们如何知道用户当前的语言设置呢？如果是浏览器的话。在用户请求网页的时候，会有一个 header Accept-Language 标注接受的语言。这些设置来自于用户的系统语言，以 及浏览器的设置。移动 App 情况下，通常都会有获取 locale 变量或者常量的 API。还有一种方式是根据用户的IP 或者 GPS 信息知道用户的位置，然后显示相应的语言。如果是跨国公司，用户在注册的时候，通常会标注出用户注册时候的语言习惯、地理区域。
如果用户想要改换语言，网站的做法各有千秋，移动 App 会有相对固定的 API。网页有这样几种方法：
新手在做网站的时候容易忘记在 HTML 上标注 lang 标签。
当你注意到如上种种细节。小心翼翼的实现了文字语言的显示之后。你会发现，翻译库的建立和管理，也是一个麻烦的过程。
通常开发者并不会有多语言的功底。这时候就需要引入外部的翻译官或者是别人已经建立好的翻译库。而这里的难点在于，翻译官往往并不是技术人员。如果让他们直接改代码、或者直接跟开发人员沟通，会极大的增加翻译的成成本。所以在硅谷的公司，这种提供给翻译官使用的翻译管理系统 (translation management system)，往往是有一个团队专门来做，或者直接采购现有的方案，比如说，闭源收费的 lokalise.co ，或者是开源的 Mozilla Pontoon。翻译管理系统可以统一管理翻译库、项目、审核、任务分配。
这样一来，开发的流程就会变成，首先设计师根据不同的语言和文化习惯，在设计的时候标志出需要注意的地方，比如这个按钮虽然在英文里很短，但是在俄文里面会非常长，要注意不要溢出。然后，开发者开发团队根据设计的需求实现具体的代码逻辑，并在翻译管理系统中提供消息码、上下文的背景、以及一个开发者熟悉的语言写成的例子。再然后，翻译官团队在管理系统中填上各种语言的翻译。最后，开发团队把翻译库拉回代码库中，发布到产品中。
其中，上下文的背景是容易被忽视而且不容易做好的地方。这个需要翻译的消息在UI界面的什么地方？用作什么用途，如果消息过短的话，还应该进一步的解释这个消息是什么意思。那么翻译官有了这个背景知识之后，就能够更加精准地加上其他语言的翻译。如果翻译官对想要表达的信息。无法透彻的理解。他们还需要拥有一个提供反馈的渠道，能够找到产品的设计和开发者询问问题。
这么多的语言和文字，通常都不是由一个翻译官来解决的，这通常需要很多个国家语言身份的人一起来为这个翻译库添砖加瓦。整个过程耗时耗力，所以翻译官通常是有专门的团队来负责的，比如外包给 smartling。
现在我们已经有了代码逻辑和翻译库。接下来的问题是：如何把翻译库的内容搬到产品中？
具体可以有很多不同的实现方式，最直接的就是，静态的做法，每次更新的时候。 交一个 diff，然后在 merge 到代码当中。这样在构建的时候，就会有就已经有了相关的翻译资料在代码里面。
还有一种做法是动态地做。一方面，可以去远程的翻译库“拉取”内容，这种情况在网站流量大的时候，可能会有性能问题。但是好处是，翻译永远是最新的。另一方面，想要做优化的话，可以采取“推送”的方式，每次翻译库有新改动，触发一个 webhook 来把内容推到服务器上。
在我看来，维护翻译会比添加翻译更加的繁琐。我曾经看到一些很大的项目，因为更新翻译之后没能够及时的删除老的翻译，导致翻译库过于的庞大，整个项目变得乱七八糟。这个时候如果有一个好的工具，能够保证数据的一致性。会对清洁的代码，有非常大的帮助。
阿里巴巴的 Kiwi 国际化全流程解决方案就做了 linter 和 VS Code 插件来帮助你检查和抽取代码中的翻译。
谈完了语言，接下来是时间和时区问题。因为是全球化的公司，所以说有很多数据是来自于全球、显示给全球的用户的。举个例子。国际航班在设置开始时间结束时间的时候如何保证这个时间在全局是一致的，并且在不同的时区会相应的显示。这非常的重要。同样的情况还应用于一切跟时间有关的事件，比如预定酒店、预定餐馆、安排会议。
首先时间有这样几种典型的表现形式。
07:23:01, 星期一 28, 十月 2019 CST AM/PM15722186682019-10-27T23:24:28+00:00，这是带时区信息的。我对这些形式没有大的偏好，你如果有相关经验，欢迎留言讨论。
具体在显示的时候。有两个可能出现的转化，一个是，从服务器存储的时区转化成当地时区显示的形式；另外一个是，语言上会由机器代码转换成自然语言。后一步流行的做法是使用强大的处理时间和日期的库，比如 moment.js 和 dayjs。
不同国家区域对于数值的显示，其实是天差地别的。数值中间的逗号和点，在不同的国家，有不同的含义。
(1000.1).toLocaleString("en")
// => "1,000.1"
(1000.1).toLocaleString("de")
// => "1.000,1"
(1000.1).toLocaleString("ru")
// => "1 000,1"
阿拉伯数字并不是在所有区域都通用的，比如 Java 的 String.format 中 1、2、3这种数字在真正的阿拉伯语言里，使用的数字是١、٢、٣。
价格方面，同样的货物，在不同的国家地区，是否要显示成当地货币的价值？货币的符号是什么？货币能够精确到哪一位？这些问题统统要先做好准备。
本文提到的国际化工具有，翻译管理系统，开源的 Mozilla Pontoon、闭源收费的 lokalise.co，POEditor.com 等等。代码上的一致性 阿里巴巴 Kiwi 国际化全流程解决方案。UI 显示上的 moment.js, day.js。
如同一切软件系统的开发一样，国际化这件事情没有银弹，好的作品都是靠基本功一点一滴磨出来的。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
