xpander 推出企业级智能体控制平面：应对AI智能体泛滥的治理与可移植性挑战

企业级人工智能面临一个新的基础设施问题：企业积累智能体（agents）的速度，快于其构建治理这些智能体的系统之速度。

Gartner 估计，到 2028 年，全球《财富》500 强企业的平均在用人工智能智能体数量将超过 15 万个， 而这一数字在 2025 年尚不足 15 个。然而，据该研究机构称，仅有 13% 的组织认为其当前已具备恰当的人工智能智能体治理机制。

这一不断扩大的差距正催生一个新市场——一种位于单个模型和智能体之上的基础设施层，它负责处理执行、权限、可观测性、记忆、对企业系统的访问以及生命周期管理，而无需开发者为每个新智能体重新构建这些服务。

xpander.ai是一家由三位前 AWS 首席工程师创立的初创公司，正成为最新一家试图掌控该层的公司。

该公司今日起正式向公众全面推出其企业级人工智能智能体平台， 将其定位为一个供应商中立的控制平面，用于跨不同模型、智能体框架及基础设施环境构建、运行和治理智能体。在 VentureBeat 独家专访中，xpander.ai 首席执行官兼联合创始人 David Twizer 表示，公司日益频繁地从企业客户处听到三大问题：智能体在本地运行而缺乏集中化治理；智能体工作流仍局限于单个用户；基础设施与单一人工智能供应商深度绑定。

Twizer 向 VentureBeat 表示：“第三个问题最为关键：即被锁定于单一供应商。你所做的一切实际上均由你选择合作的那家公司所拥有——他们的工具、他们的产品路线图、他们关于智能体应如何响应你一切操作的政治化观点。”

需注意的是，xpander 的供应商中立性并未消除依赖关系；它只是将依赖关系向上迁移至技术栈更高层级。

企业可在 xpander 底层自由更换模型、框架和基础设施，但 xpander 专有的通用运行时（Universal Harness）与控制平面将成为协调执行、治理、身份认证、记忆及可审计性的核心层。 如果这些配置与运行时状态难以迁移到另一控制平面，则可能催生一种新型锁定。xpander 的公开文档目前尚未说明：若客户终止其企业许可证，该层的可移植性究竟如何。该公司同时宣布完成由 Pico Venture Partners 领投的 750 万美元种子轮融资，Emerge Ventures、Samsung Next 和 SeedIL 参与跟投。

但 xpander 正进入一个已远超简单划分为专有超大规模云平台与中立替代方案的成熟市场。

竞争焦点正向上转移至模型层之上。

模型可移植性在智能体基础设施中正变得日益普遍。

例如，LangChain 的 LangSmith Deployment 提供了用于部署和治理生产环境智能体的基础设施。企业可将其控制平面与智能体服务器完全运行于自有 Kubernetes 基础设施之内，包括适用于空气隔离（air-gapped）及数据驻留敏感型环境的场景。LangChain 还提供混合部署模式，即客户自行运营智能体服务器，而由 LangChain 托管控制平面。

CrewAI 正朝类似方向演进。其企业版包含集中式治理、单点登录（SSO）、基于角色的访问控制（RBAC）、工作负载身份认证及策略管理，并支持在 CrewAI 云、客户虚拟私有云（VPC）或客户自持基础设施上部署。CrewAI 表示，其平台可跨模型与云平台运行，并允许客户保留并修改为其智能体生成的代码。

Temporal 则从另一角度切入该问题。它并未提供端到端的智能体管理环境，而是为长期运行的人工智能工作流提供持久化执行能力，包括崩溃恢复、重试、人工审批以及能在故障中持续保存的状态。其人工智能平台可跨不同模型、工具与系统编排工作流。

与此同时，模型与云服务提供商自身亦正向上拓展至该基础设施层。OpenAI 的 Frontier 平台提供共享的企业上下文、权限、智能体执行与管理功能；而谷歌的 Gemini Enterprise Agent Platform 则将托管运行时基础设施与智能体身份认证、集中式治理、记忆、追踪及针对智能体间交互与智能体-工具交互的策略执行能力相结合。

换言之，xpander 的差异化优势不能仅限于“企业可在某一家模型提供商的云之外运行智能体”——多家竞争对手已提供此类灵活性的版本。

其更大赌注在于：企业将需要一个框架无关的控制平面，该平面位于日益异构化的模型集合、智能体框架及面向员工的人工智能界面之上。

Twizer 的论点部分源于其在 AWS 长达七年的从业经历，期间他目睹了企业曾如何应对上一代基础设施锁定问题。

Twizer 告诉 VentureBeat：“我们的策略是引入名为云计算的伟大事物，然后尝试创建无服务器（serverless）解决方案——而按定义，这类方案必然导致供应商锁定。”但他表示，企业最终要求的是在不同云服务商之间迁移工作负载的能力。 他表示：“我认为人工智能并无不同。多云、多供应商是一项必备战略。” 一种旨在抵御模型更迭的运行时

xpander 平台的核心是其所谓“通用运行时（Universal Harness）”——一种与模型、框架及云平台均无关的运行时，用于将智能体作为可移植的企业级工作负载执行。

企业可采用 xpander 托管环境，或在其企业版下于 Kubernetes 或本地基础设施上自主部署。该公司亦明确列出 AWS、Google Cloud、Microsoft Azure、私有 VPC 及完全空气隔离的本地环境为受支持的部署目标。

其框架兼容性主张同样广泛：xpander 表示客户可接入使用 LangChain、Strands 和 Agno 等框架构建的智能体，以及其现有提示词（prompts）、规则与技能。它支持专有模型、开源权重模型及客户微调模型。

对开发者而言，xpander 提供三条主要集成路径：一种语言无关的 REST API，用于控制平面操作；一个 Python SDK，用于构建智能体与工作流；以及 Model Context Protocol（MCP）支持，使智能体与工具可被 MCP 客户端（如 Claude Desktop 和 Cursor）调用。REST 接口包含智能体、任务与知识库的管理与调用操作；SDK 则额外提供事件处理与智能体生命周期抽象功能。

Twizer 向 VentureBeat 表示：“可将其想象为一个运行于你自有场所、私有云或我们 xpander 云内部的 Kubernetes 环境。这种与供应商无关的运行时可运行任何厂商的智能体。” Twizer 表示，其目标最终是让模型选择更类似于为应用程序选择底层计算资源，而非将整个组织绑定于某一整套软件生态系统。 ——一种与模型、框架及云平台无关的运行时环境，用于将智能体作为可移植的企业级工作负载执行。

企业可使用 xpander 托管的环境，或在其企业版方案下，自行在 Kubernetes 或本地基础设施上部署。该公司还明确列出 AWS、Google Cloud、Microsoft Azure、私有虚拟私有云（VPC）以及完全物理隔离的本地环境为支持的部署目标。

该框架层面的宣称同样宽泛：xpander 表示客户可接入使用 LangChain、Strands 和 Agno 等框架构建的智能体，以及其现有提示词（prompts）、规则和技能。它支持专有模型、开源权重模型（open-weight models）以及客户微调过的模型。

对开发者而言，xpander 提供三条主要集成路径：一种与编程语言无关的 REST API，用于控制平面操作；一个 Python SDK，用于构建智能体与工作流；以及对模型上下文协议（Model Context Protocol，MCP）的支持，使智能体与工具可被 Claude Desktop 和 Cursor 等 MCP 客户端访问。REST 接口包含用于管理与调用智能体、任务及知识库的操作；而 SDK 则增加了事件处理与智能体生命周期抽象功能。

“请将其想象成一个运行于您自有场所、私有云或我们 xpander 云内部的 Kubernetes 环境，”Twizer 向 VentureBeat 表示，“这种与厂商无关的运行时环境可运行任何厂商的智能体。”

Twizer 表示，最终目标是让模型选择更类似于为应用程序选择底层算力，而非让整个组织绑定于某一整套软件生态系统。

‘你可以从 Claude 切换到 ChatGPT，再切换到 Kimi，再到你自己的微调模型，’他说，‘所有这些模型都将像使用 CPU 那样以相同方式被使用。你其实并不关心它们由谁制造，你只希望自己的应用能够运行。’

该架构旨在让底层工作负载可以变更，而编排与运维层则保持相对稳定。

随着企业使用多个 AI 供应商，这一区分可能变得愈发重要。OpenAI 自身指出，企业级 AI 正从辅助功能转向由智能体（agents）执行的委托式任务；其最新企业数据表明，法律、销售、招聘和营销等职能领域中，智能体的使用正迅速增长。

与此同时，谷歌正专门增加集中式智能体治理、身份识别及网关控制功能，以在大规模场景下管理智能体与工具之间的交互。这些来自体量大得多的供应商的投资，进一步印证了 xpander 的基本前提：将智能体投入生产时，管理模型本身正日益仅成为其中一部分。

实践中‘治理’意味着什么

Twizer 认为，本地运行的智能体会使这一运维问题尤为突出。

他告诉 VentureBeat：‘你在员工笔记本电脑上安装 Claude 或 ChatGPT 或 Codex 或任何其他 AI 系统，得到的只是一个黑箱。没有任何东西受到治理，没有任何东西接受审计，也没有任何东西受到控制。’

他的担忧不仅在于智能体可访问本地资源，更在于 AI 产品已迅速从生成文本演进为无需人工干预即可执行操作——而企业未必围绕这些能力同步构建起同等水平的治理基础设施。

Twizer 表示：‘一夜之间，就从“这是一个帮我撰写邮件的聊天机器人”，变成了“这是一个能控制我的机器并执行 API 调用的 AI 智能体”。’

xpander 的文档对该公司所谓将此类活动迁移至受治理环境的具体含义提供了更明确的定义。

控制平面可定义允许谁运行智能体、该智能体可访问哪些资源，以及哪些操作需经人工批准。xpander 表示，智能体拥有命名身份，且所有操作均可追溯至触发该操作的人类用户。工具调用、运行记录、追踪日志、审批记录及失败事件均被记录在案，支出亦可按任务粒度归因。

对安全团队而言，一个尤其相关的架构细节是凭据处理。xpander 表示，凭据仅在工具调用执行时才从密钥库（vault）注入，而非直接向模型暴露。

该公司称其已通过 SOC 2 Type II 认证，并符合 GDPR 规范。其企业版还包含单点登录（SSO）与开放身份认证（OIDC）、私有模型网关，以及支持按团队划分用量归属的子组织功能。

xpander 试图区别于 LangSmith 和 CrewAI 等产品的关键点，在于将底层 智能体框架本身视为另一个可替换组件 ，而非将其自研框架作为主要开发环境。

该公司表示，其运行时环境既可运行 xpander 原生智能体，也可运行基于其他框架构建的自定义智能体。这种更广泛的框架中立性是该公司的一项主张，尚需在实际生产环境中验证；目前这些平台之间的功能重叠已相当显著。

自行构建智能体层的成本

对于希望实现集中管控但又不愿采用另一家供应商基础设施的企业而言，替代方案正日益转向自行组装上述诸多组件。

Twizer 认为，这正是生产级智能体所隐含成本浮现之处。接入基础模型相对简单；但要重建支撑高级托管型智能体的整套运维基础设施，则远非易事。

Twizer 告诉 VentureBeat：‘如果你想以一种受治理且安全的方式实现类似 [Anthropic] Claude Code 的功能，你就需要构建一整套运行框架。你需要构建沙箱、身份认证机制、“人在环路”（human in the loop）机制、存储系统、会话管理以及记忆层。’

他补充道：‘这就相当于投入两年时间建设基础设施，只为以安全方式运行那个智能体。’

该公司文档指出，其运行框架可处理长周期与多工具任务、沙箱化代码执行、持久化记忆，以及任务失败或偏离预期时的恢复能力。这对 Twizer 的论点而言是重要背景：xpander 并非仅仅提供一个用于替换某模型 API 的网关；它正尝试将企业原本必须独立运维的众多运行时服务打包整合进这些 API 之中。

Twizer 表示，xpander 已收到来自正在生产环境中使用其技术的政府机构与金融机构的反馈，称该基础设施负担正阻碍他们以可控方式部署智能体。

该公司官网单独展示了包括联想（Lenovo）、英特尔（Intel）、Workday、西门子（Siemens）、英伟达（Nvidia）、Intuit、SAP、PagerDuty、Mozilla 和 Salesforce 在内的多家组织徽标，并标注为‘被以下团队使用’。

该公司的回应并非建议企业放弃 Anthropic、OpenAI 或其他 AI 提供商的产品。Twizer 反而主张，企业应继续使用这些模型，同时将权限管理、监控与执行移入企业自身掌控的基础设施层。

他说：‘这不是说“不要使用 Claude”，而是说“请使用 Claude，但要以一种你能观察它、保护它、监控它的方式使用”，并对授权技能及特定资源的访问权限实施管控。’

使智能体成为组织级而非个人级

xpander 还正在添加一个名为 多人协作 AI（Multiplayer AI）的功能层。

其基本理念是，企业级智能体日益需要超越单个用户的聊天会话生命周期。一项工作流可能涉及智能体收集数据、另一系统执行操作、员工审批该操作，以及不同团队在数小时甚至数天后重启该流程。

Twizer 认为，本地部署的助手还有另一项劣势：员工通过其智能体积累的专业知识——提示词（prompts）、技能、工作流及上下文——往往仅留存于这些个体自身。

他告诉 VentureBeat：‘你正在让 AI 智能体变得更好，却并未让公司变得更好。你如今在该生态体系中投入的所有数据、所有提示词、所有工作流、所有技能，都被锁定在该供应商内部，极难与同事共享。’

更复杂的企业工作也极少能完美映射到单次聊天会话中。

Twizer 表示：‘工作不是单人游戏，而是多人协作。它跨越数天甚至数周的时间。对企业而言真正重要的工作流，并非聊天机器人。’

xpander 的共享对话功能旨在将这些交互保留在持久化、权限范围限定的线程中。一个智能体只需发布一次，即可供整个组织使用；而员工可通过 Slack、Teams、ChatGPT、Claude 以及 xpander 自有界面与智能体交互。

该公司文档指出，下游操作可通过使用OIDC的端到端身份验证，将自身识别为调用该智能体的人类用户——对于需要在工作流经智能体时持续保留用户级身份与授权的组织而言，这一区分可能至关重要。

对持久化执行的要求并非xpander独有。Temporal已将长期运行、具备容错能力的工作流作为其AI主张的核心，而LangSmith则支持智能体的持久化部署及生产环境可观测性。

xpander试图整合的是：将该运行时基础设施与企业协作及治理能力结合，形成一个单一、可移植、灵活且厂商中立的控制平面。

Omni正在验证‘harness’（智能体运行框架）假说。

该公司还在推进 Omni——其预构建智能体——全面上市。

仅将Omni称为通用型智能体，低估了xpander当前所销售的产品。其文档将Omni描述为一种 AI前向部署工程师 ，可将用户提出的业务目标转化为该公司所称的“智能体应用”（Agentic Application）：即一个后端智能体，搭配一个前端体验界面，该界面可包含聊天功能、交互式UI组件、报告、仪表盘及可视化图表。

用户可描述期望达成的结果，随后Omni将协助构建该应用，连接模型、技能、工具与数据，以受追踪任务形式执行工作，并在“智能体工作区”（Agent Workspace）中维护文件及可复用的上下文。最终生成的应用可与团队成员共享。

例如，xpander的文档展示了一名用户要求Omni构建一个Redshift分析器（Redshift Analyzer）。Omni旨在收集需求、设计界面、构建后端智能体、接入适当的连接器与工具，并生成首个可实时运行的应用界面。

文档还列出Slack、WhatsApp、Telegram和电子邮件作为Omni的通信渠道；而xpander更广泛的平台资料则将Teams、Claude、ChatGPT、API、Webhook、CLI及MCP列为工作可抵达智能体的方式。由于该公司资料中为Omni与更广泛平台所列的渠道集略有不同，企业应核实其特定接口与部署配置是否获得支持。 Omni亦可与桌面端AI产品协同运行，而非取而代之。Twizer表示，员工可继续使用其偏好的桌面端智能体，而Omni则作为一项技能，仅暴露企业批准的数据与连接器。当需要后台执行时，Omni可创建一个由中心管控的智能体来执行任务。

xpander称Omni在GAIA基准测试中得分 90.9%，包括在其最具挑战性的任务上表现强劲。该结果由该公司自行报告，应视作对其更广泛主张的支持性证据，而非对该平台的独立验证。

Twizer表示，公司刻意采用多种模型混合测试该harness框架，而非围绕单一专有系统进行优化。

‘我们采用了Opus、Sonnet、Kimi和GPT，在该基准测试中取得了90.9%的分数，’他告诉VentureBeat。

对Twizer而言，该结果支撑了一种观点：智能体性能正日益取决于基础大模型周边的基础设施。

‘这恰恰证明价值在于harness层，而非模型层，’他表示。‘价值体现在：你如何处理长期运行的任务？如何处理工具调用？如何实现沙箱隔离？如何聚焦？如何让智能体专注于特定任务？’

该基准测试结果已公开，供他人审查该公司方法论，但更广泛的结论仍属xpander对其自身结果的解读。

这一主张在业内正日益获得共识。分歧点在于：该层应由谁掌控。

OpenAI与Google正将其纳入更广泛的AI平台；LangChain与CrewAI正将其开发生态系统拓展至企业级运行时；Temporal则将执行问题作为基础设施加以解决。

xpander押注企业将更希望该控制平面独立于 以下三者：模型、云服务商及智能体框架。

该公司如今需证明：额外增加的这一抽象层，其价值足以证明在本已日趋拥挤的企业AI技术栈中再引入一个平台的合理性。

定价与可用性

xpander平台与Omni现已全面上市，面向使用xpander托管服务的团队与在自有基础设施上运行该平台的企业，提供两种差异显著的商业模式。

自助式 团队版（Team） 不收取席位费，而是按智能体活动量以 积分（credits）计价 。xpander将1积分定义为 1美分，即100美元可购得10,000积分。每次唤醒智能体的事件或消息均消耗1积分（涵盖整个对话轮次），无论该轮次持续时间长短；每次工具或API调用另计1积分。模型token则按所选模型的预设费率，另行以积分计费。

因此，该成本结构比Twizer所描述的按智能体‘输出’付费更为精细。根据已公布的定价方案，长期运行本身似乎不会产生基于时长的收费，但工作流可通过重复调用、工具调用及模型token消耗累积费用。

新注册账户获赠 1,000积分免费额度 ，而非限时免费试用；客户可使用信用卡注册。据xpander称，团队版支持无限数量的智能体、工作流及用户席位。

模型使用可能占总成本的相当大比例，该公司公布了示例以助客户计算该项支出。其定价页面为各模型分别列出了输入与输出token费率，并说明这些模型费用已纳入积分体系，从而为托管客户消除了单独向模型提供商支付账单的环节。因此实际支出高度取决于所选模型、token用量及工具调用次数。

自托管企业客户则适用不同安排。xpander的 企业版（Enterprise） 为年度许可制，起始许可规模为 50个智能体 ，支持部署于客户的Kubernetes基础设施或本地环境中。该版本包含单点登录（SSO）与OIDC支持、带积分池及按团队用量报告的子组织、私有模型网关连接、上线支持及一级技术支持。客户还可自带模型API密钥，并使用其与模型提供商协商确定的费率。

xpander 未公布该年度企业许可的美元价格因此，潜在客户无法仅凭公开信息计算私有部署或空气隔离（air-gapped）部署的总成本。定价资料亦未就50个代理（agent）起订承诺提供公开的美元金额。此类部署需联系xpander获取定制化报价。

Twizer向VentureBeat谈及托管模型时表示：“您只需为代理实际执行的工作付费。没有订阅费、没有席位费、没有构建者席位费，什么都没有。您只为代理的实际输出付费。”

对企业买家而言，这一区别至关重要：xpander“不收取席位费”的主张最直接适用于其按用量计费的托管服务。而需要自主掌控部署环境的组织，则须评估一项未公开的年度许可费用、基础设施成本以及自身向模型提供商支付的费用。

这使xpander面临一个直截了当但正日益受到挑战的主张——当企业直面代理泛滥（agent sprawl）问题时：继续使用员工认为有用的任意模型、框架和接口，但将控制这些代理行为能力的基础设施迁移至一个组织可统一管控的共用层。

企业最终是否希望该共用层来自一家独立初创公司、一家代理框架公司，抑或来自xpander试图抽象化的同一批超大规模云服务商（hyperscalers）及模型提供商，如今正成为企业AI技术栈中的另一处战场。

xpander与其他代理基础设施方案的对比

当各产品直接对比时，重叠之处变得更为清晰。目前多家竞争对手已支持多个模型提供商、客户可控的基础设施，或两者兼备。差异点日益集中于：各平台试图掌控的代理技术栈（agent stack）比例有多大——以及其提供的究竟是代理开发框架、中立运行时（neutral runtime）、持久化工作流基础设施，还是一系列托管云服务。

这种对比使简单的供应商中立性主张变得复杂。例如，AWS AgentCore 支持 Bedrock 之外的模型以及包括 LangGraph、CrewAI 和 Google 的 ADK（Application Development Kit）在内的多种框架，而 LangSmith 则明确自称框架无关（framework agnostic）。CrewAI 提供客户可控的部署方式及广泛的模型选择。Temporal 允许企业完全自托管持久化执行层，尽管它解决的是范围更窄的基础设施问题，而非提供完整的智能体控制平面。

这使得 xpander 的潜在差异化定位更为具体：它试图将框架与模型的可移植性，同企业身份管理、治理、运行时基础设施以及面向员工的协作层结合起来，而非仅在模型切换能力或脱离供应商 SaaS 环境部署能力方面展开竞争。xpander 对其托管平台的定价基于单个智能体唤醒次数（agent wakes）和工具调用次数（tool calls），而非按用户席位（seats）计费；不过，对于需要自托管的企业，其年度许可费用尚未披露，起始门槛为支持 50 个智能体。