86 篇博文 含有标签「architecture」

大多数智能体内存系统将一个四层的问题压缩成两层，然后在出现破绽时表现得大吃一惊。一个是当溢出上下文窗口时会被截断的会话缓冲区（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）”契约的架构转变，以及根据用户预期而非开发便利性，对每个智能体动作进行延迟层级的诚实映射。

你为了加快上线速度而购买的托管审核 API，现在已经成了你安全关键路径上的一个同步外部依赖。这句话并非观点——而是被如实重绘后的架构图。在供应商服务降级的日子里，你面临两个选择，且两者都很糟糕：故障开启（fail open），此时护栏在最需要的时候恰恰失效了；或者故障关闭（fail closed），护栏的故障直接导致了功能的停摆。大多数团队是在事故发生时才发现自己选了哪一个，而不是在此之前。

团队选择供应商的原因并非因为懒惰。在内部构建内容分类器、提示词注入检测器和 PII 脱敏工具，看起来像是背离实际产品开发的六个月漫长弯路，而供应商通常提供免费额度和五分钟即可完成的集成。这种集成确实很快。但随之而来的架构后果是，第三方现在介入了每一次面向用户的生成请求路径，其可用性、延迟和行为特征是你无法控制且未曾建模的。

这篇文章的主旨是将这一决定视为架构决策，而非采购决策。

针对 Agent 类产品，生产环境下最常见的投诉通常是某种形式的“它忘记了我们刚才说的话”。这种投诉往往出现在第 8 轮、第 15 轮或第 30 轮——绝不会在第 2 轮出现。团队的第一反应往往如出一辙：扩大上下文窗口。但这其实是错误的直觉，因为 Bug 不在模型本身，而在于团队将对话历史视为了终端的滚动回放（scrollback）——追加一行、渲染尾部、满了就截断。实际上，他们不知不觉中构建的是一个读多写少的数据库，具有仅追加写入、热工作集、隐藏在截断规则中的淘汰策略，以及取决于所提问题类型的查询模式。一旦你接受了这一点，整个问题的本质就改变了。

滚动回放模式之所以如此诱人，是因为聊天界面看起来就像一份对话记录。消息向下流动，用户自上而下阅读，而喂给模型的自然方式就是将最新的 N 轮对话拼接到提示词中。这种数据结构感觉是“免费”的：没有 Schema，没有索引，没有查询——只需追加、渲染、重复。在最初的几轮对话中，任何架构都表现良好。模型拥有完整的上下文，费用低廉，演示效果极佳。

我合作过的一个团队在周三下午发布了一个“微小的提示词调整”。同一个 PR 还向智能体注册中心添加了一个新工具——一个对内部管理 API 的便利封装，提示词现在偶尔会调用它。评估套件通过了。金丝雀发布看起来也很正常。到周四早上，由于智能体处理了一个包含提示词注入攻击的支持工单，一名客户的计费记录被修改了。审计追踪显示，管理工具完全按照设计运行。值班工程师的第一反应——回滚提示词——毫无用处，因为凭证已经使用，数据行已经写入。

复盘报告将其定性为安全审查失败。其实不是。这是发布流水线的失败。团队通过相同的审查、相同的关卡和相同的回滚逻辑，发布了两个完全不同的资产类别——对模型的行为引导和授予智能体的新权限，就好像它们是同一种变更一样。它们并不是。一旦你将它们视为两个流水线，大多数关于“智能体治理”的争论就会变得清晰得多。

Temperature 之争是 AI 工程中最具宗教色彩的争论，也是最没效率的争论之一。每个团队都会形成两个阵营：决定论者希望将所有地方的 Temperature 都固定为 0，因为他们无法调试不稳定的系统；而创意论者则希望调高它，因为这样输出结果感觉更“有灵性”。两者都错了，因为他们都在错误的层面上回答这个问题。Temperature 不是一个全局设置。它是一项预算——就像任何预算一样，它应该被分配，而不是被宣告。

高效的框架很简单：系统中每个模型调用都有其目的，随机性要么在那个层面（surface）发挥作用，要么就不该存在。决定下一个调用哪个工具的规划器（planner）无法从变化中获益；选错一个工具就是调试噩梦，而且没有任何创意上的好处。如果一万个用户看到的摘要措辞都一模一样，那么为他们总结搜索结果的响应合成层很快就会显得呆板——SEO 团队最终会标记这些样板内容。一个让模型提出备选方案供人类选择的头脑风暴层，在 Temperature 为 0 时表现反而 更糟；多样性本身就是其核心功能。

如果你无法清晰地说明随机性在特定调用位置的作用，你就不应该为此付费。

一次日历写入返回了 409 Conflict。框架默认的错误处理器开始介入：退避 200ms，重试。同样的冲突。退避 400ms，重试。同样的冲突。退避 800ms，重试。等到智能体放弃并告诉用户“我无法预订会议”时，它已经浪费了三秒钟的延迟预算，去证明第一条响应就已经告诉它的事实：该时段已被占用。世界没有改变。它也不会在 800 毫秒内改变。重试永远不会奏效，因为这个错误中没有任何瞬时性的成分。

这是智能体系统中最为常见的错误处理 bug，而且它就隐藏在当今几乎每一个发布的框架之中。带有指数退避的重试模式是从无状态 HTTP 客户端中照搬过来的——在那里这种模式完全正确——但被引入到有状态的规划循环中时，它就完全错误了。对于智能体中的工具错误，正确的默认处理方式不是重试，而是重新规划。