为AI应用构建可扩展、对智能体友好的API
内容提要
文章探讨如何用微服务原则构建可扩展的AI智能体API。核心问题是：智能体请求密集且需保留对话上下文，传统有状态设计在负载均衡下会静默丢失历史。解决方案包括三项原则：无状态化，将对话状态移入共享存储；隔离（舱壁模式），分离聊天与工具调用资源池；智能端点、哑管道，保持协议简单。数据层建议合并存储，用单一数据库事务保证会话、记忆与向量索引的一致性。
延伸解读
有状态设计的静默失败风险
文章指出，传统有状态API在负载均衡下会静默丢失对话历史。当请求被轮询到不同副本时，模型仍返回HTTP 200，但可能基于不完整上下文回答，用户难以察觉。这种失败在单机部署中不会出现，一旦水平扩展就会暴露。因此，为AI智能体设计API时，必须将对话状态移出进程，存入共享存储，确保任何副本都能处理任意轮次。
舱壁模式隔离工具调用与聊天
文章建议按依赖隔离资源池，而非全局共享。例如，将标准聊天与工具调用路径分开，分别设置并发信号量。基准测试中，若共享同一池，慢速工具调用会阻塞普通聊天请求；隔离后，工具压力不会挤占聊天容量。这种舱壁模式能防止级联故障，让不同组件独立演进，并允许为每个依赖设置独立的超时和并发预算。
数据层合并优于按服务拆分
与微服务“每个服务独立数据库”的常见建议相反，文章认为AI应用应合并数据存储。一次智能体轮次会写入会话、记忆、向量索引和审计日志，若分散在多个存储中，应用需自行处理一致性。而单一数据库事务能保证这些写入原子提交，并利用行锁和版本列协调并发更新。因此，计算层可分解，数据层应收敛。
Q&A
为什么传统的状态化API设计在AI智能体场景下会失败？
因为智能体请求密集且需要保留对话上下文，而传统状态化设计依赖进程本地状态。当请求被负载均衡分发到不同副本时，如果未配置粘性会话，请求可能落到没有历史记录的机器上，导致模型在缺少正确上下文的情况下回答，且失败是静默的（HTTP 200但行为错误）。
构建可扩展的智能体友好API需要遵循哪三项核心原则？
三项原则是：1) 无状态化：将对话状态移出进程，存入共享存储，使任何副本都能处理任意对话的任意轮次；2) 隔离（舱壁模式）：按依赖隔离不同部分（如分离聊天与工具调用资源池），防止级联故障；3) 智能端点、哑管道：保持OpenAI聊天补全协议作为简单稳定的传输层，将智能（路由、预算、记忆工程等）放在其上层。
如何通过舱壁模式隔离聊天和工具调用请求？
使用信号量（semaphore）为不同依赖设置独立的并发预算。例如，为聊天路径设置CHAT_SLOTS（如24个槽位），为工具调用路径设置TOOL_SLOTS（如8个槽位）。这样，当工具调用缓慢时，不会耗尽所有请求池，从而保护标准聊天请求的容量。
为什么在AI应用中建议合并数据存储而不是采用“每个服务一个数据库”？
因为单个智能体轮次会写入多个必须一致的数据（如会话、记忆、向量索引）。如果拆分到不同存储（如Postgres、向量库、Redis），应用需要自行管理一致性。而合并到一个数据库（如Oracle AI Database）可以利用数据库事务保证所有相关写入的原子性，简化一致性管理。
如何利用数据库处理水平扩展API中的并发轮次冲突？
可以使用SELECT ... FOR UPDATE加上版本列（version column）来序列化冲突更新，并实现重试处理，而不是让竞争更新覆盖对话状态。这有助于协调两个副本同时服务同一对话轮次的情况。
在智能体API中，如何保持与OpenAI SDK的兼容性？
保持OpenAI聊天补全协议作为传输层不变，将智能逻辑放在其上层的网关中。这样，官方OpenAI SDK无需修改即可与兼容端点通信，只需将base_url指向网关地址即可。
