如何构建可扩展且适配人工智能代理的 API？

依赖代理的人工智能应用需要采用不同于传统 Web 接口的设计，这不一定是因为需要新的协议，而是因为其流量模式本身不同。一次对话可能延续数十个独立请求，而代理会以自动化速度持续工作，不会出现能够减轻基础设施压力的人类等待间隔。

文章发表于 The New Stack，属于 Oracle 赞助内容。文章建议重新采用微服务中的既有原则，构建兼容 OpenAI 且能够扩展的接口，并以 Oracle AI Database Free 为概念验证模型提供基础。

为什么代理的流量不同于 Web 应用？

浏览器可以通过路由黏性和用户思考间隔，在单个服务器上维持会话。而代理可能连续执行 40 个循环，每个循环都会作为独立的 HTTP 请求到达，协议并不能保证将其路由到同一台服务器。如果对话记录留在本地进程内存中，那么请求一旦转移到服务的另一个实例，下一个请求就可能丢失上下文。

工具调用也可能以不可预测的方式分支；一个请求可能不会调用任何额外服务，也可能触发多次调用，其中包括可能耗时 400 毫秒的向量搜索。代理还会通过自身的重试策略增加压力，而流量则会以连续批次的形式出现，其规模更多由并发限制和硬件决定，而不是由用户行为决定。

初始设计中的隐性问题

作者展示了一个原型：它将对话历史保存在进程内字典中，使用单一集合控制并发，并在请求路径内执行工具调用。该设计在测试中能够运行，但实际上依赖于对话的所有消息角色都能访问同一台设备。

当将 200 个对话（每个对话包含四个消息角色）交替分配到多个实例时，服务器可能仍然返回 HTTP 200 状态码，但模型却会在没有正确对话记录的情况下作答。因此，故障未必会表现为明显的技术错误，而可能表现为用户视角下的不正确行为。

处理这一问题的三项原则

• 将状态移出进程：将对话状态和工具调用记录存储在共享存储中，使任意服务实例都能处理对话中的任何消息角色。
• 隔离或设置隔离舱：为不同的路径和依赖项（例如对话补全和工具执行）分别设置并发限制与超时，防止其中一项发生故障而耗尽整个系统。
• 智能端点与简单管道：让 OpenAI-compatible 协议继续作为稳定的传输层，同时在其上实现路由逻辑、预算管理、记忆管理和工具调用策略。

实际会发生哪些变化？

该概念验证模型将系统划分为：使用 OpenAI 协议且不保存状态的网关；拥有对话记录和审计功能的记忆服务；具有独立并发限制和专用超时的工具服务；以及作为共享存储的 Oracle AI Database Free。该设计使用独立的控制信号，例如为对话并发设置 24 个槽位，为工具调用设置 8 个槽位。

这种划分使系统能够在不依赖本地文件系统或请求路由黏性的情况下进行水平扩展。只要协议保持兼容，OpenAI 的官方客户端也可以无需修改 SDK 便使用该接口。

编辑性结论是，人工智能代理的可扩展性不能仅靠增加实例数量来解决。真正的考验在于保持状态、控制缓慢依赖项，并防止重试或工具调用将代理批次转化为连续故障。由于该文章属于 Oracle 赞助内容，它呈现的是一种架构方法和概念验证模型，而不是数据库之间的独立比较，也不是对所有环境中特定性能的保证。