Agentic AI 的下一步，不只是打造一个更强的单体智能体，而是让数百乃至数千个专业化智能体协同开展调查、

Agentic AI 的下一步，不只是打造一个更强的单体智能体，而是让数百乃至数千个专业化智能体协同开展调查、测试、批判与改进。当一项任务可以被拆分为并行的假设、实验、评审和领域角色时——从科学与数学到工程运维和企业分析——这种协作模式就会产生价值。

Oracle 工程团队在官方博客发布了在 Oracle 云基础设施（OCI）上运营大规模智能体集群的系列文章开篇，聚焦于在 Oracle Kubernetes Engine（OKE）上开通并管理 1000 个常驻智能体，并以 OCI 文件存储服务（FSS）作为持久化 POSIX 工作空间层。在一次公开的端到端实测中，平台面向固定的 1000 个智能体完成了 6000 个请求中的全部 6000 个，客户端零重试。

从单体智能体到协作系统

单个智能体可以规划任务并调用工具，而大规模智能体集群可以并行推进独立假设、比较候选方案、验证工作成果并为后续阶段保留证据。更多智能体本身并不必然带来更好的结果，真正的收益来自协作模型，以及一个能够保持身份、状态与访问边界的底层设施。

参考架构使用 OKE 承载工作智能体 Pod，用 FSS 提供持久化共享 POSIX 工作空间，公共入口是一个无状态的模型上下文协议（MCP）网关，网关与执行器之间采用异步投递。在位于 Ashburn 数据中心的实测中，1000 个常驻智能体在六个并发阶段各收到一个短只读提示，6000 个请求全部成功且客户端零重试。最快的整批成绩出现在 500 并发时：每秒 18.4 个成功请求；而 50 到 100 并发时，p99 端到端延迟约为 10 秒。

为什么智能体集群是集群级问题

智能体数量较少时，把所有运行时放在一个节点、使用本地磁盘看似可行。但当智能体同时执行模型调用、工具、代码和数据处理时，CPU、内存、I/O、网络套接字与隔离性都会在同一台主机上竞争，一次主机故障也可能打断过多智能体。

当规模达到 100 或 1000 个智能体时，平台必须把工作分布到多个节点，并在不丢失身份与工作空间的前提下重建单个工作进程。这是一个集群级的生命周期问题。OKE 提供了所需的基础原语：工作 Pod、健康检查、资源请求与限制、Service 以及跨工作节点的调度。Agent Manager 通过命名空间级 RBAC 创建和删除执行器，公共网关则保持无状态：新的客户端请求可以到达任意健康的网关副本，执行器的调度由 OKE 独立管理。

持久化与共享工作空间不可或缺

智能体不是传统的无状态运行时。它需要持久的工作空间保存任务产物、工具输出、代码变更、本地指令和中间结果。Pod 根文件系统会在重建时消失，对于必须跨越重调度与维护存活的智能体工作来说，这是错误的生命周期。

在集群中，每个智能体需要私有状态，相关智能体又需要对公共材料与交付物的受控访问。FSS 提供持久、可扩展、并发的 POSIX 兼容文件访问，OKE 可以通过 CSI 卷插件挂载 FSS 支持的持久卷。工作空间采用受限挂载模型：/workspace/private/ 为单个智能体私有的读写区；/workspace/files/ 为账户参考文件与已安装技能的只读区；/workspace/projects/ 为同账户共享的项目产物读写区。执行器不会拿到存储根目录、其他账户或兄弟私有工作空间的访问权，正是这种范围化挂载让共享存储在不牺牲隔离性的前提下发挥作用。

对于数据密集型智能体工作流，如果并行 I/O 成为实测瓶颈，可以评估 OCI File Storage with Lustre——面向 AI/ML 与 HPC 负载的托管并行文件系统，可被 OKE 挂载。是否采用应基于实测 I/O 行为、容量、区域可用性、客户端兼容性与成本，而不是默认替代 FSS。

1000 智能体基线的实测证据

公开客户端测试在 Ashburn 使用固定的 1000 个常驻智能体，每个智能体在每阶段收到一个短只读提示。测试并发梯度为 10、50、100、200、500 与 1000，每个请求使用独立 Bearer 认证，无 MCP 会话 ID，无客户端重试。

实测数据方面：1000 并发时 1000/1000 完成，总耗时 155.53 秒，每秒 6.41 个请求，p99 延迟 111.53 秒；500 并发时 1000/1000 完成，总耗时 54.27 秒，每秒 18.44 个请求，p99 延迟 48.92 秒；200 并发时每秒 16.51 个请求，p99 延迟 8.25 秒；100 并发时每秒 15.51 个请求；50 并发时每秒 9.4 个请求，p99 延迟 9.54 秒；10 并发时总耗时 516.98 秒，每秒 1.91 个请求。

全部 6000 个请求均成功完成。结果揭示了一个运行层面的权衡：500 并发时整批完成最快（每秒 18.4 个成功请求），但 p99 延迟达 48.92 秒；50 和 100 并发时 p99 稳定在 10 秒左右；1000 并发时批处理仍能完成，但 p99 飙升至 111.53 秒。换言之，提高并发可以更快完成整批任务，却会让排在队尾的请求显著变慢。

集群扩展可评估的 OCI 能力

随着智能体规模增长，Oracle 列出了后续阶段可评估的架构选项：高可用运营状态可用 Oracle Database、MySQL HeatWave 或 Autonomous AI Database 承载身份、租约、任务状态、检查点与审计记录；异步工作交付可评估 OCI Queue，在客户端、控制器、执行器与审计系统之间实现托管解耦；共享上下文与向量检索可使用 Autonomous AI Database 的向量能力，在元数据与访问控制之下检索已批准文档与语义记忆；动态图编排可评估 Oracle Property Graph 建模智能体、任务、来源与产物之间的关系；私有模型服务则可在 OCI Compute 或 OKE 上自管 vLLM，或通过 OCI 生成式 AI 的 OpenAI 兼容 API 与专用模型端点进行私有访问。

结论

这项工作提出并验证了一套在 OCI 上运营 1000 个常驻智能体的实用架构：OKE 负责集群级放置、生命周期管理与恢复，FSS 提供持久且范围受限的 POSIX 工作空间，无状态 MCP 网关、私有网络路径、基于队列的交接与私有模型服务将公共请求接入与智能体执行相互分离。该工作是 JAPAC 卓越中心 AI-First 计划的一部分，目标是验证在 OCI 上运营 1000 及以上规模协作智能体集群的可行性与架构方向。下一阶段将补充节点与 Pod 遥测、FSS 延迟、队列深度、模型服务延迟与重启事件等度量，为更大规模的智能体集群与更复杂的负载寻找最优路径。