31 篇博文 含有标签「architecture」

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

这就是 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 时代的负载均衡器，如果你在生产环境中运行模型，你要么已经有了一个，要么正在不知不觉中构建一个。

你的智能体 v1 能用。它很丑，靠提示词胶带勉强维持，每次打开代码都让你皱眉。但它能处理 90% 的情况，用户很满意，每天都在创造价值。于是你自然而然地决定：从头重写。

六个月后，重写版本仍未上线。你迁移了两次框架，为一个根本不需要的问题搭建了多智能体编排层，评估套件测试的全是那些从不出错的地方，真正容易崩溃的地方一个没测。与此同时，v1 依然在跑——依然很丑，依然好用。

这就是第二系统效应，它在我们大多数人出生之前就已经摧毁了无数软件项目。

多智能体系统（Multi-agent systems）是基于一个承诺而诞生的：多个并行的专业化智能体协同工作，产生的结果会优于任何单个智能体。但这个承诺隐藏了一个前提——当智能体给出不同答案时，你知道如何调解它们。大多数团队在发现自己无法调解时，往往为时已晚。

天真的做法是取输出的平均值，或者选择多数票答案，然后继续。在实践中，如果所有智能体共享相同的训练分布，多智能体系统会通过多数表决放大它们的共同错误，而不是抵消错误。一个总是听从最有信心智能体的系统，会盲目跟随那个最过度自信的智能体。而一个将所有分歧都交给 LLM 裁判（LLM judge）处理的系统，会继承该裁判的 12 种已被记录的偏差类型。仲裁问题比看起来要难，如果处理不当，你可能会在一周内遇到四次生产事故。

一个能够总结合同、起草产品规范和编写 SQL 查询的通用 AI 智能体确实令人印象深刻——直到你将其部署到放射科，并发现它建议了听起来合理但却与患者实际药物过敏史相冲突的剂量。这种失败并非幻觉问题，而是架构问题。

大多数智能体演示中隐含的假设是：足够强大的基础模型加上广泛的工具集，就等于在任何领域都胜任的智能体。而在实践中，这一假设与生产现实之间的差距，正是导致患者受伤、诉讼产生以及实验结果不可复现的根源。通用智能体是一个合理的起点，而非终点。