The New Stack：用微服务原则重构 Agent 友好 API，单体部署扩到 3 台机器会丢 75% 上下文
来源The New Stack查看原文
速览
- Agent 流量与 Web 流量有四点不同：请求无状态但对话有状态、工具扇出不可预测、重试激进、负载突发且机器驱动
- 单体 OpenAI 兼容端点在单机正确，扩到 3 台机器后上下文丢失率达 75%
- 失败是静默的：HTTP 仍返回 200，但模型可能拿不到历史上下文
- 修复方案来自 2014 年微服务原则：无状态、舱壁隔离、智能端点加哑管道
- 解耦为 gateway、memory、tools 加共享数据库后，3 台机器上下文丢失率降到 0.0%
- 舱壁把 32 个槽位拆成 24 个聊天加 8 个工具，避免慢工具调用拖垮普通聊天
- 反直觉结论：计算要拆，数据要合，一个事务提交替代跨库一致性协调
- 单个 Agent 轮次写入四类必须一致的数据，拆库会引入应用层一致性负担
The New Stack 发布一篇技术分析文章，讨论如何为 AI Agent 构建可扩展的 API。文章指出，Agent 流量与浏览器流量有四点本质差异：对话有状态但单个 HTTP 请求无状态、工具调用扇出不可预测、Agent 会激进重试、负载呈突发且机器驱动。作者用一个最小 OpenAI 兼容端点做 POC 基准测试：200 个对话、每个 4 轮共 800 轮请求，在轮询分发到多副本的情况下，单体部署从 1 台机器扩到 3 台机器时，上下文丢失 600 次，丢失率 75%；而拆分为 gateway、memory、tools 加 Oracle AI Database Free 的解耦架构在 3 台机器上丢失率为 0.0%。文章主张用 2014 年微服务文献中的无状态、舱壁隔离、智能端点加哑管道三条原则来重构，并提出一个反直觉结论：计算要拆、数据要合。
关键事实
- POC 基准测试驱动 200 个对话、每个 4 轮，共 800 轮请求，每轮轮询发送到下一个可用副本
- 单体部署 1 台机器时上下文丢失 0 次，丢失率 0.0%；扩到 3 台机器时丢失 600 次，丢失率 75.0%
- 解耦部署在 1 台和 3 台机器上上下文丢失均为 0 次，丢失率 0.0%
- 单体架构的失败是静默的：可观测性仍显示 HTTP 200，但模型可能在没有正确上下文的情况下作答
- 解耦架构分为四个部分：gateway（只说 OpenAI 协议、不持有状态、水平扩展）、memory（独占会话状态与工具审计轨迹）、tools（独立进程执行工具，有自己的并发预算和超时）、Oracle AI Database Free（共享底座）
- 舱壁对比测试中，两种架构每副本各有 32 个准入槽位；单体从一个请求池支出，gateway 拆成 24 个给普通聊天、8 个给带工具的请求
本站视角
这篇文章对国内做 Agent 产品的团队有直接的工程参考价值。第一，它指名了一个非常容易被忽视的坑：很多团队在单机或单副本上跑通了 OpenAI 兼容端点，就以为架构没问题，但一旦上负载均衡扩到多副本，会话状态留在进程内就会静默丢上下文。75% 这个丢失率虽然来自作者自己的 POC，但足以说明问题的严重性——而且失败是静默的，监控上全是 HTTP 200，用户却拿到答非所问的结果，这类 bug 在线上极难定位。第二，文章提出的「计算要拆、数据要合」是一个值得认真对待的判断。国内不少团队在搭 Agent 基础设施时，习惯性地把会话状态放 Redis、向量放专用向量库、审计日志放另一个库，结果在应用层自己实现分布式一致性，代码复杂度陡增。文章主张把会话状态、工具调用记录、记忆事实、幂等账本放在同一个数据库的一个事务里提交，这个思路在工程上确实更省事，尤其对中小团队而言。第三，需要提醒的是，这篇文章本质上是 Oracle 的软文，架构建议和产品推荐是绑定的。它给出的方案并非唯一解——用 Postgres 加 pgvector 同样可以在一个事务里完成关系、JSON 和向量数据的写入，国内团队完全可以用自己熟悉的技术栈复现这套思路，不必被引导到特定产品上。真正值得带走的是那三条原则和那个 75% 的数字，而不是文末的下载链接。
背景与影响
这篇文章的出发点是：如今大多数人与前沿 AI 模型的交互其实都建立在某种协议之上，通常由模型厂商自己创建，比如 OpenAI 和 Anthropic 各自提供的推理系统 API。一种常见做法是使用 OpenAI 兼容 API 来服务多轮 Agent，把官方 OpenAI SDK 指向兼容的推理端点，在多个轮次间使用同一接口。文章要回答的问题是：当流量增长或子 Agent 生成时，系统如何在不被用户察觉的情况下扩展。作者认为，这些问题在 2010 年代的微服务文献中已经被讨论过，只是当时的请求形态还不存在。文章用 Oracle AI Database Free 作为共享底座重建了一个 Agent 友好 API 并做了测量。需要指出的是，这是一篇带有明确厂商导向的技术文章，文末引导读者下载 Oracle AI Database Free、安装 Oracle AI Agent Memory Python 包并访问 Oracle AI Developer Hub，因此其基准测试的架构选择与数据库选型之间存在利益关联。文章引用的微服务原则本身是公开的行业共识，但 POC 的具体数字只有单一来源，读者在参考时应意识到这一点。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。
