Factory 如何将 AI 智能体与运行它的计算环境分离

Nikhil Harithas 负责 Factory 的前沿部署工程。他把这项工作描述为反馈循环：了解复杂客户在部署时遇到的困难，再用这些信息指导产品开发。

他的案例是大型金融机构 Blackstone，其部署受到监管和安全约束。Harithas 说，Factory 的默认方案不适用：客户希望使用自己的计算、推理和身份，并采用单租户部署。

Factory 的编程智能体 Droid 可以通过 Slack 或 Jira 等工具接收委派任务，再返回一个 pull request。这需要权限，因此企业设计反复遇到两个问题：智能体代表谁行动？它在哪里运行？

Harithas 认为，智能体不应无限期借用个人身份。他把智能体看作应用，可以借助已有的软件和身份管理方法，再针对其较不确定的行为进行调整。

不同客户希望使用 Kubernetes、EC2、其他云或沙箱服务商。Factory 早期的自带计算方案把智能体安装到机器上，却让客户自行管理机器生命周期，事实证明这很复杂。

Factory 提出的方案是 Open Compute：一个计划为任意智能体抽象计算生命周期的项目。演讲时它处于私有预览阶段，团队计划在之后几周开源。

目标是让客户选择工作负载的运行位置，并在自己的 VPC 内实施安全约束，同时不一定需要将 Factory 控制层的每个部分都部署到本地。Harithas 将其描述为从控制平面和数据平面中分离出计算平面。

在简化架构中，客户端向 Factory 后端发送会话请求。计算网关要求客户环境中的 Open Compute 控制器创建机器，中继则负责客户端与智能体守护进程之间的通信。

控制器调用封装所选计算服务商的驱动。EC2 驱动可以启动实例；其他驱动可以面向 Kubernetes 或沙箱服务商。智能体不必为每种环境分别实现生命周期管理。

创建出的机器向 Factory 中继发起 WebSocket 出站连接。Harithas 说，设置完成后不需要向客户环境发起入站连接，这对安全团队很重要。

客户端通过中继与运行在客户环境中的智能体通信。模型调用可以单独配置，包括使用客户自己的密钥和推理服务。

Harithas 说，这样客户无需在本地部署完整 Factory 产品，也能控制智能体执行环境。他把客户拥有模型、评估和计算资源描述为长期方向，而不是声称所有组件已经由客户托管。

计划中的接口以计算机为工作单元，支持创建、暂停、恢复和销毁等生命周期操作，并通过模板定义安装的软件和构建要求。

快照和分叉对长任务或委派工作很重要。会话可以保存状态、创建分支，并把子任务交给另一个智能体。Factory 还设想让客户控制快照存储，并接入自己的密钥存储。

Harithas 强调，项目管理的是计算机，而不是 Factory 专属会话，因此这种抽象可以用于其产品之外。驱动负责实现针对不同服务商的接口。

资源供应不只是一次 API 调用：确认消息可能丢失，服务商可能限流，进程也可能重启。控制器必须跟踪期望状态、重试，并把用户路由到正确的机器。

长时间运行的工作带来另一项挑战。Harithas 描述了如何通过快照和恢复替换有时间限制的沙箱，同时让持续数天的多智能体任务继续运行。他还谈到私有预览期间分发带版本基础设施包的经历。

明确的驱动规范可以让新增计算后端及其测试更容易。Harithas 最后提出的目标是让智能体能够运行在客户偏好的不同环境中，而不把智能体本身绑定到单一服务商。