39 篇博文 含有标签「architecture」

大多数工程团队是通过在截止日期前三周收到的一封法律邮件才了解到 GDPR 的。欧盟 AI 法案（EU AI Act）正在重演这一模式，而 2026 年 8 月 2 日针对高风险 AI 系统的强制执行日期已经非常临近，“以后再处理合规问题”已不再是一个可选项。GDPR 与 AI 法案的区别在于，GDPR 的合规大多是关于数据处理政策的。而 AI 法案的合规要求构建新的系统组件——这些组件在大多数生产环境中的 AI 系统中尚不存在。

法规中所谓的“人类监督义务”和“审计追踪要求”，转化为工程语言，就是一个仪表盘、一个事件日志和一个数据血缘系统。本文将欧盟 AI 法案视为一份工程规范而非法律文件，并逐步介绍你实际需要构建的内容。

一个团队在 GPT-4 上构建了一个生产环境功能。几个月后，出于成本考虑，他们决定评估 Claude。他们花了两周时间进行“迁移”——但核心的 API 替换只花了一个下午。剩下的十天都花在了修复损坏的系统提示词（system prompts）、重新测试拒绝服务的边缘情况、调试由于意外文本而崩溃的 JSON 解析器，以及重新调整在不同供应商之间表现迥异的工具调用模式（tool-calling schemas）。原本以为只是简单的连接器更换，结果迁移预算膨胀成了多层重构。

这就是现实中的 LLM 供应商锁定问题。那些受挫的团队并不是因为选错了供应商——而是因为他们没有意识到锁定存在于多个维度，且每个维度都有不同的风险画像。

大多数在大语言模型（LLM）之上构建 SaaS 产品的团队都是通过惨痛的教训才发现多租户问题的：他们利用单一的共享提示词配置快速出海，然后惊恐地发现一个客户的系统提示词泄露到了另一个客户的响应中，或者某个企业级客户耗尽了所有人的速率限制，亦或是当月 AI 账单寄来时，根本无法确定是哪个客户造成了 40% 的支出。这种失败模式并非停留在理论层面——NDSS 2025 的一篇论文证明，vLLM、SGLang、LightLLM 和 DeepSpeed 中的前缀缓存（prefix caching）可以被利用，仅通过时间信号和精心构造的请求，就能以 99% 的准确率重建另一个租户的提示词。

构建多租户 AI 基础设施与传统数据库的多租户化并不相同。共享组件——推理服务器、KV 缓存、嵌入流水线、检索索引——每一个都面临独特的隔离挑战。这篇文章涵盖了你实际必须解决的四个问题：隔离、定制、成本归因以及单租户质量追踪。

2024 年某个时刻，一个规律开始在 AI 团队的事后复盘中反复出现："我们去掉 LangChain 重写了，上线速度明显加快了。"这些团队在采用框架时并没有犯技术错误——犯的是时机错误。LangChain 是原型阶段的对路工具，却是第七个月的错误工具。

同样的故事发生了足够多次，现在它有了一个名字：编排框架陷阱。你采用了一个确实能加速早期工作的框架，生产力提升掩盖了不断累积的结构性债务。等到债务浮出水面，你已经深陷于那些本不该被触碰的内部实现之中。

AI 工程中最昂贵的架构错误不是选错了模型，而是选错了交互范式。本该构建 Agent 的团队花了六个月打磨一个聊天机器人，然后困惑地发现用户什么事也办不成。本该构建 Copilot 的团队接入了完全自主的 Agent，结果用整个季度来扑灭未授权操作和失控成本引发的各种火。

这套分类学在你写下第一行代码之前就至关重要，因为聊天机器人、Copilot 和 Agent 有着根本不同的信任模型、上下文窗口策略和错误恢复需求。选错了不只是产品变差——而是产品无法通过调提示词或换模型来修复。

大多数构建 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 的速率限制而导致静默失败的重试逻辑。直接在单一供应商之上构建系统的团队会无形中积累这种债务，直到收到弃用通知或价格变动通知时，账单才会一次性结清。