79 篇博文 含有标签「architecture」

一个三人团队花了整整一个季度，为一个日活跃用户仅 200 人的应用实现了事件溯源架构。这套架构技术上无懈可击，运维上却是一场噩梦。设计方案来自 AI 的推荐，团队之所以接受，是因为推理听起来流畅、权衡分析看似严谨，而最终构建出来的系统也完全符合高级工程师架构图上的样子。

这个故事如今已成为一种警示性范式，而非孤例。AI 在特定的、可识别的场景下能够提供真正有价值的架构输入——而在从外部看起来几乎相同的情况下，它也会给出自信满满却大错特错的建议。这两者之间的差距，如果你把 AI 当成答案机器，就几乎无从察觉；但如果你把它当成思维伙伴，则完全可以驾驭。

空乘人员要求你切换到飞行模式。你的团队上季度交付的客服代理正在一个标签页中对话到一半，接下来的用户回合却返回了一个永远无法解决的加载动画。这个智能体并没有以任何有趣的方式崩溃。它只是在一百个未写明的细节中假设了网络是存在的。

这个假设是你的产品团队从未写下的最昂贵的代码行。它支配着你如何存储对话状态、如何调用工具、如何呈现错误、你针对什么进行评估，以及当连接在对用户重要的工作过程中中断时，用户会怎么做。“离线智能体模式”是一种将这一假设从基础架构中抽离出来、审视它，并明确决定当通往托管 API 的往返不可用时应该发生什么的纪律。

大多数公司的第一次 AI 事故都遵循一个剧本：一名提示词工程师发现模型对刚刚开始出现在实际流量中的某个类别进行了错误分类，于是提交了一个 PR，对系统提示词（system prompt）进行了一行微调，然后在模型继续在生产环境中进行错误分类的这 23 分钟里，盯着构建队列。修复手段只是一个字符串。而部署却是一个二进制文件。这种不匹配并不是工具层面的疏忽 —— 而是团队在将系统提示词与应用程序代码一同放入 .py 文件的那天起，就隐含做出的架构决策。

将提示词更改与部署管道耦合是你强加给自己的限制。分布式系统中没有任何定律规定模型的行为契约必须与编排代码封装在同一个制品（artifact）中。运行时提示词热重载模式通过像对待功能开关（feature flags）、路由规则和价格表那样对待提示词，从而切断了这种耦合 —— 即将其视为在请求时从版本化存储中拉取的配置，并辅以短效的本地缓存和定义明确的安全原语（safety primitives）。这样做的好处是事故响应时间从以分钟计的构建时长缩短到以秒计，而代价是你必须正视一个你的发布流程可能忽略的第三个部署平面。

我上个月交流过的一个团队遇到了一个任何资深包管理器用户都能一眼识破的 Bug。他们的智能体中有两个技能（skills）都提供了相同的 search_orders 能力 —— 一个来自计费工具包（billing toolpack），另一个来自 CRM 工具包。最后添加到清单（manifest）中的那个成了生效者。智能体在三周内都在静默地调用错误的能力。退款发到了错误的客户 ID。他们告诉我，修复方法是召集 CRM 和计费工程师开会以“协商命名”。开会。只为了解决两个可安装模块之间的名称冲突。

就在那一刻，我意识到了当前的智能体运行时（agent runtimes）正在发生什么。运行时加载能力模式 —— 技能、工具包、提示词片段、检索提供程序、MCP 服务器 —— 正汇聚到几十年前编程语言通过导入系统（import systems）解决的相同问题上：名称解析、版本锁定、依赖图、冲突检测、延迟加载。而大多数智能体运行时要么在拙劣地重新发明每一项，要么干脆无视，并以“开会”的形式将账单寄给用户。

某个团队此刻正看着他们的 LLM 月支出以 10 倍速度增长，而 p99 延迟徘徊在四秒左右。工程师们增加了更多重试。重试触发了速率限制。速率限制触发了回退。回退也是 LLM 调用。没有人停下来问：这个功能真的需要实时响应吗？

大多数 AI 产品团队都为"幸福路径"设计架构——用户发消息，模型响应，用户看到结果。同步调用模式是 API SDK 在第一个代码示例中演示的内容，因此它就这样上线了。但生产 LLM 工作负载中有相当大一部分与用户坐在键盘前等待毫无关系。它们是文档增强任务、内容分类流水线、向量嵌入生成、夜间摘要生成和后台质量评分。对于这些工作负载，实时推理是错误的工具——而坚持使用它所付出的代价是真实的金钱、级联故障，以及你要花费数月才能理清的运营复杂性。

大多数智能体内存系统将一个四层的问题压缩成两层，然后在出现破绽时表现得大吃一惊。一个是当溢出上下文窗口时会被截断的会话缓冲区（conversation buffer），另一个是旧内容堆放其中的“长期记忆”向量数据库。那不是内存架构。那只是一个队列和一个杂物抽屉。

如果一个智能体连续三个周一向老用户询问同一个新手引导问题，这并不是因为模型不好，而是因为系统中没有一个地方能保存“该用户跨会话告知我的事情”，并且其生命周期不同于“所有用户告知我的关于产品如何运作的事情”。这是不同的记忆。它们有不同的访问模式、不同的隐私契约以及不同的遗忘规则。将它们混为一谈是架构上的错误——而且这是可以修复的。

如今，生产环境中的大多数 “智能体”（agents）其实都是套着对话界面的后台任务。它们不需要用户向其输入内容，而是需要一个触发器、一个状态文件，以及一种在不可避免的超时后恢复运行的方法。对话循环 —— 请求、工具调用、请求、工具调用，无限循环 —— 是为了演示方便而提供的功能，却悄然间成为了默认的执行模型。然而，对于大多数交付的智能体工作负载来说，这其实是一个错误的模型。

这并非一个哲学层面的决定。它直观地反映在账单上、值班告警中，以及任务的运行成功率上。对话循环会在多轮对话中保持模型会话开启，不断累积上下文，一旦链路中任何一环出错，整个过程就会中断。而调度触发则在确定的边界处启动，运行至完成或达到检查点，并在退出前将状态写入持久化存储。前者像是一通电话，而后者则是一个工作队列。将两者混为一谈，会导致一个每月 200 美元的功能在没有任何人修改提示词的情况下，变成每月 4 万美元的负担。

过去，那种“在标签页中运行模型”的故事很容易被忽视：小模型、新奇的演示、在笔记本电脑风扇狂转前只能运行 30 秒的 Whisper 语音转录。现在，那个时代已经结束了。量化技术得到了改进，WebGPU 已经在所有主流浏览器中发布，设备端缓存获得了持久配额，现在 4-bit 3B 模型在价值 500 美元的笔记本电脑上输出 token 的速度，已经快到让用户感到“流畅”。“这是否应该在服务端运行？”不再是一个默认选项 —— 这是一个关键的架构决策，如果你的产品团队每次都直接接受平台团队的第一个方案，那么他们就在无意中做出了这个决定。

随之而来的错误比演示效果变差更严重。团队为整个产品选择一种后端 —— 通常是服务端推理，有时是浏览器推理 —— 然后在每个不匹配的功能上付出错误的代价。对隐私敏感的功能输给了对延迟敏感的功能，因为架构强制给出了单一答案。或者更糟，团队因为演示时的惊艳效果选择了浏览器原生方案，然后发布了一个“机群级”的体验，导致长尾设备群体中 30% 的用户获得了一个性能降级的产品，而仪表盘却无法察觉。

浏览器原生 AI 并不是更快的 TensorFlow.js。它是一个具有不同 SRE 逻辑、不同成本模型以及四个无法坍缩为单一答案的权衡维度的不同运行时。将其视为“API 调用的廉价版本”是 2026 年最典型的架构错误。

这种模式太熟悉了，以至于被视而不见。模型幻觉出了一个事实，于是团队增加了一个检索步骤。三周后，模型从不断增加的工具库中选错了工具，于是他们在工具目录上增加了一个检索步骤。模型的回答感觉太笼统，于是他们在过去的高质量回答上增加了一个检索步骤。一个季度过去了，系统现在变成了一堆检索器拼接在一起的提示词，而本质上，最初的问题依然存在。

改变的不是失败率 —— 而是失败模式的名称。“模型出错了”变成了“检索未命中”，这听起来更易处理，但事实并非如此。评估套件的分数更高了，因为从构造上讲，检索到的上下文对于测试集来说是分布内（in-distribution）的。生产环境的情况则截然不同，但到那时，架构已经有了三个检索层，每一层都有自己的嵌入模型、索引刷新频率和值班轮换，而且没有人想成为那个提议拆除它们的工程师。

这就是检索膨胀（retrieval sprawl）。这是一种架构上的分心：一种将难题（提示词设计、模型能力、模糊的规范）转移到更舒适的问题（信息检索工程）上，而实际上没有解决任何问题的方式。

一个需要 90 秒才能完成任务的后台智能体，其操作基于的是 90 秒前的世界快照。当它返回结果时，用户可能已经导航到了不同的视图，开始了一个新的对话，归档了原始请求，或者完全关闭了标签页。大多数智能体框架无论如何都会交付结果，修改状态以反映结果，并将这次往返视为成功。但这并不是成功。这是智能体在一间空屋子中结束。

这种失败模式比直接丢弃结果更糟糕。丢弃结果只是一次投递失败——虽然烦人但可以恢复。而应用陈旧的结果则是对一个用户不再提出的问题的回答，它是针对不再匹配的状态编写的，往往会覆盖用户已经开始的新工作。用户会注意到发生了他们没有要求的事情，却无法重构原因，从而对系统失去信任，这种信任损失是简单的超时永远不会造成的。

解决办法不是更快的智能体，而是一个交付时的相关性门控，它将返回的时刻视为一个全新的决定，而不是派发时刻预设的定论。

你长期运行的智能体（agent）所做的最危险的事情，也是它做得最自信的事情：根据记忆回答。客户的地址在上周二更改了。智能体认为“开启”的工单在昨天被人工关闭了。智能体拥有整洁解释笔记的产品功能，其实际交付的形式与智能体三周前阅读的规范不同。在教科书定义上，这些都不属于幻觉——模型准确地召回了它存储的内容。只是在智能体看向别处时，世界已经发生了变化。

大多数团队将记忆视为一个写入问题：智能体应该记住什么、我们如何总结、嵌入（embedding）策略是什么、如何防止存储爆炸。这种思维方式产生的架构会随着错误程度的增加而变得更加自信。更难的问题——那个决定你的智能体在第三周后是否仍然有用的问题——是对账（reconciliation）：这是一个明确的、持续的闭环，用于比较智能体认为真实的情况与底层系统当前显示的真实情况。

你账单中最便宜的推理费用，是那些你付了两次的钱。几乎所有主流模型提供商现在都提供批处理层（batch tier），价格大约只有同步推理的一半，代价是接受以小时而非毫秒计的完成窗口。大多数工程团队要么完全忽视这一选项，要么只是随手扔进一个深夜定时任务（cron），然后宣称省下了钱。这两种做法都白白浪费了 30%–50% 的推理总支出——并非因为折扣不够大，而是因为批处理并不是一种代金券。它是一个全新的产品层面，拥有自己的 SLA、重试语义和失败模式。那些仅将其视为计费优化的团队，最终要么使用率低下，要么上线了需要数周才能排查出来的细微回归问题。

技术核心不在于“我们是否应该使用批处理？”，而在于：你系统中的哪些动作在用户感知层面确实是同步的，哪些是工程团队为了开发体验方便而“误当成”同步的，以及哪些可以在下游消费者不预设结果实时性的前提下重新塑造为任务（jobs）。回答这个问题需要进行工作负载审计、从“请求型（request-shaped）”到“任务型（job-shaped）”契约的架构转变，以及根据用户预期而非开发便利性，对每个智能体动作进行延迟层级的诚实映射。