46 篇博文 含有标签「architecture」

大多数构建 LLM 流水线的团队几乎立刻就会选择链式架构。复杂任务被拆分为多个步骤——提取、分类、摘要、格式化——每个步骤都有自己的提示词。这感觉很自然：更小的提示词更容易编写、调试和迭代。但很少有人会问：链式调用真的比在一次调用中完成所有工作更准确吗？在我见过的大多数代码库中，没有人测量过。

单体 vs. 链式的权衡是 AI 工程中最关键的架构决策之一，但几乎总是凭直觉做出的。本文将梳理实证依据，说明分解何时真正有帮助、何时会悄然使事情变得更糟，以及在生产环境中需要关注哪些信号。

几乎每家持续交付 AI 功能的公司都会出现这样一种架构：流水线中的每一次转换、每一个路由决策、每一次分类、每一个格式化步骤，全都经过 LLM 调用。它通常始于一个合理的场景——LLM 确实解决了一个棘手问题。然后团队内化了这个模式，开始反复套用。直到整个系统变成一条 LLM 接 LLM 的链条：一串文字从一端进入，另一串从另一端出来，中间经历了十二次 API 调用，全程没有任何确定性可言。

这就是 AI 泛滥反模式，它现在已成为构建一个缓慢、昂贵且无法调试的生产系统的最可靠方式。

大多数 AI 功能的架构都大同小异：用户输入发送到 API，云端 GPU 进行处理，然后响应返回。这种往返过程已经如此常态化，以至于工程师们很少对其产生质疑。但它带有一个隐藏的“税”：每次交互都有 200–800 ms 的网络延迟，API 密钥必须存放在某个可访问的地方（因此容易受到攻击），而且你无法控制系统运行时间的硬性依赖。

通过 WebGPU 实现的浏览器原生 LLM 推理打破了这三个假设。模型在用户的 GPU 上运行，位于浏览器沙箱内，没有网络往返。这并非未来的功能 —— 截至 2025 年末，WebGPU 已在 Chrome、Firefox、Edge 和 Safari 中默认出货，覆盖了全球约 82.7% 的浏览器流量。工程问题已从“我们能做到吗？”转向“它何时能击败云端，以及我们如何在两者之间进行智能路由？”

大多数团队在做“云端 vs. 边缘”的决策时往往凭直觉：因为云端更简单，所以他们默认选择云端。直到 HIPAA 审计来袭，或者延迟 SLO 下降了 400 ms，亦或是收到了当月的账单。只有到那时，他们才会反思是否某些推理本来就应该在本地完成。

答案几乎永远不会是“全云端”或“全边缘”。大规模运行生产级 AI 的团队已经达成共识，采用了分层架构：由设备端或本地模型处理大部分请求，而云端前沿模型则负责处理小模型无法应对的情况。正确处理这种路由是一个工程决策，而不是一种直觉。

这就是进行严谨决策的决策框架。

大多数构建 AI 流水线的工程师都会孤立地评估每个组件：检索成功的频率是多少，LLM 做出正确判断的频率是多少，下游工具调用成功的频率是多少。如果每个答案都是"95%"，系统看起来相当稳固。

然而事实并非如此。三个各为 95% 的组件组合在一起，只能给你一个 86% 可靠的系统。再加第四个 95% 的组件，降到 81%。加第五个，低于 77%。那些看起来质量很高的独立组件，在你发布任何功能之前，就会组成一条五次请求中就有一次失败的流水线。

这就是复合故障问题——大多数 AI 工程团队在用户开始提交工单之前从未去做的那道数学题。

当 OpenAI 在 2024 年 1 月停用 text-davinci-003 时，那些将该模型名称织入业务逻辑的团队花了数周时间才将其解耦。并不是因为更换模型在技术上有多难——毕竟只是一个字符串和一次 API 调用——而是因为该模型与一切都纠缠在一起：提示词构建、响应解析、错误处理、重试逻辑，所有这些都交织在一个特定的供应商会提供答案的假设中。对于中等规模的生产系统，这类迁移的工程成本估计在 5 万至 10 万美元之间，外加一个月或更长时间的工程注意力分散。

解决方案并不新奇。这是每个后端工程师都已经熟悉的模式：依赖注入。核心洞察是，你的业务逻辑应该依赖于语言模型的抽象，而不是来自 OpenAI 或 Anthropic 的具体客户端。在启动时注入具体的实现。代码的其余部分永远不需要知道接口背后是哪个供应商。

一家医疗初创公司从某个主流前沿模型迁移到了同一供应商提供的新版本。结果是：为了恢复功能对等（feature parity），耗费了 400+ 个工程小时。新模型每次响应生成的 token 数量是原来的五倍，抵消了预期的成本节省。它开始提供未经请求的诊断建议——这带来了合规性风险。而且它破坏了下游的所有 JSON 解析器，因为它把响应包裹在了 Markdown 代码块语法中。同一供应商，不同的模型，却是推倒重来。

这就是供应商抽象税（provider abstraction tax）：它不是切换供应商的成本，而是不为此做规划所产生的累积成本。它不是一次性的迁移事件，而是一个持续的消耗——你在升级三周后发现的行为退化、无法跨模型迁移的提示词工程工作，以及因为某个供应商分别计算输入和输出 token 的速率限制而导致静默失败的重试逻辑。直接在单一供应商之上构建系统的团队会无形中积累这种债务，直到收到弃用通知或价格变动通知时，账单才会一次性结清。

你的摘要步骤判断出客户投诉是关于账单的。你的提取步骤提取出了“订阅层级：Pro”。你的生成步骤写了一封跟进邮件，提到了他们的“Enterprise 方案”。三次 LLM 调用，一个流水线，一个完全错误的输出 —— 而且整个过程中没有触发任何错误。

这就是多模型一致性失效：复合 AI 系统的无声杀手。它看起来不像是一个异常。它不会触发你的错误率 SLO。它只是自信地向用户发布错误的内容。

大多数构建 LLM 驱动科学工具的团队都犯了同一个架构错误：他们直接套用编码 Agent 框架，换上领域专用工具，便将其称作研究型 Agent。事实并非如此。编码 Agent 与研究型 Agent 在表面机制上颇为相似——两者都调用工具，都反复迭代——但它们对成功标准、状态管理和终止条件的底层假设几乎截然相反。将编码 Agent 架构部署到科学工作流中，不仅会产生更差的结果，还会产生看似自信却实为错误的结论，而且这类错误事后几乎无从发现。

这一区别如今尤为紧迫——研究型 Agent 的基准测试正在激增，各团队竞相构建科学 AI，而"直接用编码 Agent"的捷径正在催生大量表面上可信的工具，它们在真实科学场景中失效，而构建者往往并不完全理解失效的原因。

用LLM智能体替换所有Zapier流程和RPA脚本的团队，往往在六个月后发现了同一件事：他们用"脆弱但可审计"换来了"灵活但难以维护"。Zapier流程以可预测的方式崩溃——第14步因API变更而失败。LLM工作流则悄无声息地出错——模型悄悄地将支持工单路由到错误的队列，直到客户升级投诉才被发现。审计日志只记录着"AI决策"，这用律师的话来说就是"没人知道发生了什么"。

答案不是回避在自动化中使用LLM，而是要有意识地判断哪些任务交给哪个系统，并架构好两者之间的接缝，使故障不会相互传染。

大多数 AI 产品把单个功能做对了，却把产品整体做错了。搜索返回了合理的结果，摘要表述连贯，对话助手给出了合理建议。但当用户搜索"小团队最佳方案"、在侧边栏看到推荐、向助手追问后续问题，再阅读自动生成的选项摘要——而这四者相互矛盾时——没有一个功能还能让人信任。这就是环境 AI 一致性问题：不是孤立的幻觉，而是产品层面的矛盾。

这种失败模式足够隐蔽，以至于团队往往完全忽视它。单个功能的评估指标看起来还不错。搜索团队衡量召回率和精确率，摘要团队衡量忠实度，对话团队衡量任务完成率。但没有人衡量产品各 AI 功能之间是否在讲述同一个事实的同一个故事。

每个上线 LLM 功能的团队都会经历相同的演变曲线。一开始，你硬编码一个 OpenAI API 调用。然后加上重试逻辑。然后有人问你花了多少钱。然后某个周五下午供应商宕机了，于是你开始构建网关。

这并非偶然。推理网关是一种自然涌现的架构模式——应用与 LLM 提供商之间的中间件层，将限流、故障转移、成本追踪、提示词日志和路由整合到一个统一的关卡中。它是 AI 时代的负载均衡器，如果你在生产环境中运行模型，你要么已经有了一个，要么正在不知不觉中构建一个。