作者：Lei阅读 --

Agent 部署架构全景：五种宿主形态、两条横切层，和背后同一个冲突

云基础设施默认计算是短时、无状态、可信、调用图静态的——Agent 把四个假设同时打破。本文结合 AIOS、Parrot、Autellix、部署综述（arXiv:2412.13437）等论文，把当前 Agent 部署方式整理成"五种宿主形态 + 两条横切层"的分层地图：进程内嵌入、沙箱化执行、托管运行时、Agent OS、端侧协同，以及 serving 调度层与 MCP/A2A 互联层，并给出选型决策表。

AIAgentAI Infra论文深读

云基础设施的三十年，建立在四个很少被说出口的假设上：计算是短时的（请求毫秒级返回）、无状态的（实例随便杀随便起）、可信的（跑的代码是你自己写的）、调用图是静态的（服务间怎么调用，架构图上画得出来）。Agent 把这四个假设同时打破：一个任务跑八小时、会话状态必须活过实例重启、执行的代码是模型现场生成的、下一步调用什么工具没人能提前知道。当前每一种 Agent 部署架构，本质上都是在回答同一个问题：你选择在栈的哪一层，修复这四个断裂。

如果你只带走一个模型，带走这个：Agent 部署不是”选一个框架”，而是一个四层栈上的组合题——宿主层（agent 循环跑在哪）、隔离层（不可信行为的爆炸半径多大）、推理服务层（GPU 上谁先跑）、互联层（agent 之间怎么发现和追责）。市面上看似混战的几十个产品，放到这张图上，各自的位置和权衡立刻清晰。

graph TB
    subgraph L4["互联层 — 跨组织的发现、通信、追责"]
        P["MCP · A2A · ACP · ANP"]
    end
    subgraph L3["宿主层 — Agent 循环跑在哪（五种形态）"]
        A["① 进程内嵌入<br/>LangGraph · AutoGen · CrewAI"]
        B["② 沙箱化执行<br/>E2B · Modal · Daytona"]
        C["③ 托管运行时<br/>AgentCore · Agent Engine · Foundry"]
        D["④ Agent OS<br/>AIOS · UFO2"]
        E["⑤ 端侧/端云协同<br/>UI-TARS · Mobile-Agent-E"]
    end
    subgraph L2["隔离层 — 不可信执行的爆炸半径"]
        I["容器 → gVisor → Firecracker microVM"]
    end
    subgraph L1["推理服务层 — GPU 时间怎么分"]
        S["vLLM → Parrot → Autellix"]
    end
    L4 --- L3
    L3 --- L2
    L2 --- L1

这张图有一篇论文可以作为学术锚点：IEEE Communications Surveys & Tutorials 上的综述 Deploying Foundation Model Powered Agent Services: A Survey（arXiv:2412.13437）。它把 agent 服务部署拆成执行层、资源层、模型层、应用层的多层优化框架——和上图的分法殊途同归：部署问题天然是分层的，任何单层的”银弹”叙事都值得警惕。

下面先讲五种宿主形态（回答”有哪几种、代表是谁”），再讲两条横切层（它们不是形态之一，而是每种形态都绕不开的公共问题）。

形态一：进程内嵌入——Agent 是你应用里的一个库

最朴素的方式：agent 循环（LLM 调用 → 工具执行 → 观察 → 再调用）作为一个库，直接跑在你自己的应用进程里。

技术代表：LangGraph、微软 AutoGen、CrewAI、OpenAI Agents SDK、Claude Agent SDK。它们的共同点是：框架管编排（状态机、多 agent 协作、工具路由），运行时问题全部留给你——持久化自己接数据库，扩缩容自己上 K8s，隔离自己想办法。

这是四个断裂一个都不修的选择，也因此是迭代最快的选择。原型阶段、内部工具、工具集完全可信（只查数据库、只调内部 API）的场景，它就是正确答案——为一个查报表的 agent 上 microVM，是把机会成本花在不存在的威胁上。

它的失效边界也清晰：第一次让 agent 执行自己生成的代码，或者第一个任务跑超过负载均衡器的超时上限，你就会被迫向下面几种形态迁移。

形态二：沙箱化执行——为”不可信的手”建牢房

Agent 一旦要执行生成的代码（数据分析、软件工程、浏览器操作），“可信代码”假设就碎了。这一形态的全部设计，围绕一个问题：模型写出 rm -rf 或者试图逃逸时，边界在哪里？

行业在这里有一个明确的技术收敛：普通容器不够，microVM 成为共识。Docker/runc 与宿主共享内核，内核漏洞即逃逸路径；而 Firecracker 这类 microVM 用硬件虚拟化划界，VMM 只有约 5 万行 Rust（对比 QEMU 超过 140 万行 C），攻击面缩小两个数量级（对比分析见 MechCloud 的架构比较）。中间态是 gVisor（用户态内核拦截系统调用），适合威胁模型较松的场景。

技术代表：E2B（每次执行一个独立 Firecracker microVM，预热快照池把启动压到约 150ms）、Modal、Daytona、Fly.io Machines、Cloudflare Agents、Vercel Sandbox（landscape 见 Spheron 的对比指南）。两个工程数字值得记住：microVM 冷启动已进入 90–200ms 区间，“为了快而放弃隔离”的理由基本消失；Firecracker 的快照恢复只要 5–30ms，这让多轮会话的”暂停-恢复”变得便宜——长时有状态计算的断裂，在这里用快照修复。

学术界对这一层的批评也值得听：PlanTwin（arXiv:2603.18377）指出，沙箱约束的是 agent 能做什么，但云端的规划模型依然看得见一切——文件原文、代码语义、项目元数据。隔离层解决爆炸半径，不解决隐私，这是它的适用边界。

形态三：托管 Agent 运行时——把四个断裂打包卖给你

如果说形态二是”自己租牢房”，形态三就是云厂商把牢房、状态持久化、身份、观测、治理打包成一个 PaaS：你交一个 agent 定义，剩下全托管。2025 年 10 月到 2026 年第一季度，三大云的产品在六个月内先后 GA（时间线见 AgentMarketCap 的对比）——这个密度本身说明市场判断：多数企业不想自己组装这个栈。

技术代表：

  • AWS Bedrock AgentCore（2025-10-13 GA）：定位”自带框架”——LangGraph、CrewAI 或自写代码都能包进去，每会话独立沙箱、最长 8 小时执行窗口。注意这个 8 小时：它就是”短时假设”被正面修复的样子。
  • Azure AI Foundry Agent Service：原生支持 LangGraph、Claude Agent SDK、OpenAI Agents SDK 多框架部署，主打 M365/Teams 生态整合。
  • Google Vertex AI Agent Engine（现归入 Gemini Enterprise）：托管执行 + 会话 + 记忆，配套 Agent Development Kit（ADK），后者到 2026 年 Q1 下载量达 700 万。
  • 框架原生阵营：LangGraph Platform、OpenAI AgentKit——框架方自己做托管，控制力更强，治理面板更弱。

选它的真实驱动力往往不是技术而是治理：OutSystems 对 1900 名 IT 负责人的调查显示，96% 的企业已有 agent 在生产环境，只有 12% 认为自己管得住（引自 linesNcircles 的企业平台分析）。代价同样真实：供应商锁定，以及为托管便利支付的溢价。

形态四：Agent OS——把运行时问题内核化

前三种形态把 agent 当”应用”部署；这一支的主张更激进：agent 是一类新的进程，应该有自己的操作系统。

技术代表与论文：AIOS: LLM Agent Operating System（arXiv:2403.16971，COLM 2025）。它的核心动作是把 LLM 调用、工具、内存、存储、访问控制从 agent 应用里抽出来，下沉成一个 AIOS kernel 提供的系统服务——调度、上下文管理、并发、访问控制，正是传统 OS 内核对进程做的事。效果：多框架 agent 混跑时端到端提速最高 2.1 倍。桌面场景的对应物是微软的 UFO2: The Desktop AgentOS（arXiv:2504.14603），把 Windows 桌面变成多 agent 的受管执行环境。

为什么需要”内核”？因为当一台机器上跑多个 agent、抢同一个 LLM 和同一组工具时，无管制的资源访问会互相踩踏——这是 AIOS 论文的出发点，也是单机版的”队头阻塞”问题（集群版见下文 serving 层）。这一形态目前更多活在研究和早期系统里，但它指出的方向很难反驳：形态三的托管运行时，商业上做的正是同一件事。

形态五：端侧与端云协同——数据不出端的那条线

前四种都默认 agent 在云里。但有一类需求天然属于设备端：操作你的手机和桌面 GUI、隐私敏感数据、离线可用、毫秒级响应。

技术代表：字节的 UI-TARS（arXiv:2501.12326，原生 GUI agent 模型）、Mobile-Agent-E（arXiv:2501.11733，自进化移动助手）、AgentCPM-GUI 等（全景见 GUI Agents: A Survey，arXiv:2412.13501）。

端侧的硬约束是算力装不下大模型，于是主流答案是端云协同：端侧小模型处理感知和低敏操作，云端大模型接管复杂规划。这条路线已有系统性综述：Cognitive Edge Computing（arXiv:2501.03265）梳理大模型与 agent 的普适部署优化；Edge SLM 与 Cloud LLM 协同推理综述（arXiv:2507.16731）专门整理”什么任务留在端、什么上云”的算法与执行机制。注意它和形态二的互补：沙箱修不了的隐私问题，端侧部署用”数据不出端”来修——这正是 PlanTwin 批评所指向的解法。

横切层一：推理服务层——GPU 不认识”agent”，只认识请求

五种形态无论选哪个，最后都要落到 GPU 上做推理。而这里有一个被大多数架构讨论忽略的断裂：serving 系统看到的是一个个孤立请求，但 agent 是一个程序——几十次 LLM 调用组成的动态调用图，彼此有依赖、有先后。

两篇系统论文把这个问题变成了可度量的损失：

  • Parrot（OSDI’24，arXiv:2405.19888）：公共 LLM 服务只暴露请求级 API，应用级信息全部丢失，只能盲目优化单个请求。它提出 Semantic Variable 抽象，让 serving 端看见请求间的数据流依赖，从而做流水线隐藏、依赖感知调度、公共前缀去重——端到端最高 11.7 倍加速。
  • Autellix（arXiv:2502.13965）：把 agent 当作一般程序对待，用程序级累计服务时间做调度（PLAS/ATLAS 算法），不需要预知工作流结构，在 vLLM 之上消解调用级与程序级的队头阻塞——同等延迟下吞吐提升 4–15 倍。

这两个数字的含义超出性能本身：“agent 感知”正在从应用层下沉进基础设施层。就像当年数据库把事务调度从应用手里接走一样，serving 系统正在把 agent 调度接走。选宿主形态时值得问一句：它的推理后端，是把你的 agent 当程序，还是当一串孤立请求？

横切层二：互联层——当 agent 走出你的边界

单个组织内的部署，前面几层就够了。但 agent 的终局形态是跨组织交互：你的 agent 调用别家的 agent，替你订票、谈判、下单。这时需要的不再是运行时，而是协议。

当前的协议格局（系统比较见 A Survey of Agent Interoperability Protocols，arXiv:2505.02279，及更广的 A Survey of AI Agent Protocols，arXiv:2504.16736）：

协议解决什么一句话定位
MCP（Anthropic）agent ↔ 工具/数据JSON-RPC 的工具调用标准接口
A2A（Google，2025-04 开源）agent ↔ agent用 Agent Card 声明能力、点对点外包任务
ACPagent ↔ agentRESTful、多模态消息、会话管理
ANP开放网络W3C DID 去中心身份 + 开放发现

该综述给出的采纳路径务实：先 MCP 打通工具，再逐步引入 agent 间协议。而治理视角上，Infrastructure for AI Agents（arXiv:2501.10114，TMLR）把跨组织 agent 基础设施归纳为三大功能：归因（哪个 agent/谁该负责）、交互塑形（协议约束行为）、检测与补救——部署架构走到互联层，问题就从”跑得起来”变成了”出了事找得到人”。

选型决策表

灰度地说：五种形态不是竞争关系，是不同约束下的局部最优，而且经常组合出现（托管运行时内部就是 microVM 沙箱；端侧 agent 的云端部分可能跑在 AgentCore 上）。

你的场景首选形态决定性约束
原型 / 内部工具，工具集可信① 进程内嵌入迭代速度
Agent 执行自己生成的代码② 沙箱化执行爆炸半径
企业多租户、合规、8 小时级长任务③ 托管运行时治理与责任转移
单机多 agent 抢同一个 LLM④ Agent OS / 调度层资源踩踏
隐私敏感、离线、GUI 操作⑤ 端侧协同数据不出端
自托管推理 + 高并发 agent 流量横切层：agent 感知 serving队头阻塞
跨组织 agent 调用横切层：协议 + 归因信任与追责

一个常见的反对意见值得正面回应：“这些不就是 FastAPI + K8s 换了个名字？“——是，直到你撞上四个断裂中的任何一个：第一个 8 小时任务撞上负载均衡器超时；第一次模型生成的代码碰了不该碰的文件；第 100 个并发 agent 把 LLM 队列打满、短任务全部饿死；第一次需要调用组织外的 agent 却无法回答”这个动作是谁授权的”。每一个断裂对应一层专门修复——这就是这套栈存在的理由，也是它不多不少正好四层的理由。

收尾：往哪个方向收敛

回看这张地图，三个趋势已经可见：隔离在收敛（microVM 成为不可信执行的事实标准）、调度在下沉（agent 感知从框架进入 serving 引擎和内核）、协议在分层（MCP 管工具、A2A 管协作的分工初步成型）。而最大的未解问题不在技术层——96% 已部署、12% 能治理的缺口，说明这个栈的最上层（归因、审计、责任）还远未建成。

下一次再看到一个新的”Agent 部署平台”发布，不妨用这张图问三个问题：它坐在哪一层？它替我修复了哪个断裂？它把哪些断裂留给了我自己？

参考来源

arXiv 论文

工程实践