智能体、框架与沙箱

第 38 章 的智能体架构、第 41 章 的运行框架、第 56 章 的授权模型，在这里汇成一个工程决策：2026 年要发布一个智能体，运行时该选什么、怎样接入。关键不是给库排名，而是选定循环原型、工具协议、沙箱边界，以及一个不容易后悔的默认方案。

智能体运行时由三部分组成。2026 年的许多混乱，都来自把这三块搅在一起：

1. 框架 / SDK 负责控制循环。模型本身只输出 token。要让它调工具、读结果、决定下一步、记住之前的轮次、把活儿交给另一个智能体、停下来等人类、崩溃后能恢复，就需要一个控制循环，以及它周围的那套管道。
2. 模型上下文协议（MCP） 是工具的传输协议。它之于工具集成，正如 OpenAI Chat Completions 之于模型调用：一套公共接口，让一个工具服务器写一遍，就能被每个框架复用。
3. 沙箱（sandbox） 是执行的载体。模型一旦开始跑代码，安全这件事就不再关乎模型，而关乎运行时。沙箱就是那台隔离的计算机，代码在里面跑。

有一条主线贯穿始终：框架、工具、沙箱都把密钥和模型访问留在外面，只通过受治理的接缝伸进来。模型走由网关（gateway）签发的虚拟密钥（virtual key），也就是短时效、限范围的模型密钥替身；对于提供商愿意按需铸造的凭据，走短时效的受限令牌；对于提供商不愿轮换的静态密钥，走出网替换（盒子里放占位符，代理在流量发往允许主机时换入真实值）；网络走默认拒绝加允许列表的出网。把这套纪律做对了，具体选哪个产品就成了可以反悔的决定。

框架：全景

功能清单会掩盖真正的决策点。核心轴是框架如何组织智能体循环，因为它决定了能表达什么、要写多少样板、控制权落在谁手里。五种原型覆盖了整个领域，并且直接对应 第 38 章 讲过的那些循环结构：

1. 图 / 状态机（LangGraph、Google ADK、Pydantic AI 的 pydantic-graph）。声明节点和边，运行时遍历这张图，持久化一个有类型的 State，支持循环、并行分支、条件路由，以及从检查点崩溃恢复。表达能力最强，控制最细，样板也最多，也最适合直接表达「智能体 A 然后 B 再回 A」和「B 与 C 并行」这类拓扑。
2. 线性交接链（OpenAI Agents SDK）。一小组原语，智能体通过交接对话来委派，接收方看到完整的会话记录。环形或并行的拓扑得手工建模。到第一个可用智能体最快。
3. 运行框架 / CLI 引擎（Claude Agent SDK）。循环就是 第 41 章 里的 Claude Code 引擎：内置真实文件系统、bash、网页搜索和自动上下文压缩（把较早的对话轮次摘要或丢弃，好塞进上下文窗口），再用 hook、进程内 MCP 工具和 subagent 来扩展它。做「模型在仓库里干活」这类事，无人能及。
4. 角色 / 团队编排（CrewAI）。定义专门的角色和目标，团队协作完成。当工作天然分解成角色时很顺手，粒度不如图细。
5. 模型优先的自主循环（AWS Strands）。一段系统提示加上工具，由模型驱动。外围结构最少，确定性控制也最少。

工具和记忆的处理是第二条轴，MCP 已经把这块大部分抹平了。工具要么是原生函数工具（一个被装饰的函数，签名直接成为 schema），要么是 MCP 服务器（经 stdio/HTTP 外接，或进程内）。记忆这一头，从「框架每轮重放消息列表」（OpenAI Sessions，最简单）一直到「一个可回退、带检查点的 State」（LangGraph、Pydantic AI 的持久化执行）。决定性的问题是：是否必须在任务中途从一次重启中恢复。如果必须，要的就是检查点机制，而不是消息列表。

选手对比

下表的版本号和许可信息截至 2026 年 6 月，延伸阅读里附了出处。凡「最适合」属于业界松散共识而非厂商事实之处，请当作方向性参考来读。

如何具体地选

• 选 LangGraph：工作流是一张图，有循环、并行分支、审批门、长时运行、必须从崩溃中恢复。为了换取控制，接受那些样板。
• 选 OpenAI Agents SDK：想要到中等复杂度生产智能体的最短路径，并看重一组小而好学的原语。
• 选 Claude Agent SDK：智能体就是 Claude 在文件系统或 CLI 上工作。论编码智能体的工程体验，无出其右。
• 选 CrewAI：问题能干净地分成专才角色，想快速搭一个多智能体原型。
• 选 Pydantic AI：想在 Python 里要类型安全、经校验的结构化输出和持久化执行。
• 选 LlamaIndex：价值在检索和文档解析；拿它做数据层，编排保持轻。
• 选 Mastra：团队以 TypeScript 为先。
• 选 Google ADK 或 AWS Strands：已经押注对应云，想要第一方工具箱。
• 选 Microsoft Agent Framework：身为 .NET/Azure 企业；它是 AutoGen 和 Semantic Kernel 受支持的继任者，那两个现已仅维护。

一个稳妥的默认。 第一次构建正经智能体的产品团队，跟着循环原型走，别认品牌。如果是编码、运维或文件系统智能体，从 Claude Agent SDK 起步：它直接递上一个可用的循环，配真实工具、上下文压缩和 MCP，再用 hook 和 subagent 去扩展。如果是中等复杂度的通用任务/工具智能体，从 OpenAI Agents SDK 起步：那套原语一个下午就能学会，它与提供方无关，还内置了追踪。当工作流长到超出线性链，需要循环、并行分支、审批门或持久的崩溃恢复时，升级到 LangGraph。那次迁移是成长的标志，不是失败。

框架这层库并不是全部。它之上还有两个对比表没覆盖的控制点。一个是编排，也就是那份计划：把一个想法拆成有范围、人能驾驭的任务。另一个是治理，也就是那份记录：让每个智能体动作都可归因，让每次委派出去的权限只能收窄。第 75 章 把两者都当作头等的层来处理，并落到作者自己的 Wallfacer（编排）与 Topos（治理）上；二者都已披露为作者自己的，在那里只是这一模式的一个例证，而非中立之选。落到实处的一点是：所选的框架应当给它们留出位置，一份人可以审阅的计划，以及一个网关和沙箱，其日志日后可供一层治理取用。

MCP：万物之下的工具层

MCP 是这个故事的另一半。它提供一套协议，让一个工具服务器写一遍，就能供上面每个框架使用，所以「框架 X 支持哪些工具」成了一个不成立的问题：答案是「任何 MCP 服务器」。到 2026 年，它已经是表里几乎所有框架之下的默认工具层。

规范现状，截至 2026 年年中：

• 稳定版：2025-11-25。 有状态，带 initialize/initialized 握手以及每会话状态。传输是 stdio（本地子进程）和 Streamable HTTP（远程服务）。

• 候选版 2026-07-28（2026 年 5 月 21 日发布），维护者称它是自发布以来最大的一次修订。重头戏是一个无状态内核：去掉了 init 握手和会话状态，把协议元数据放进 _meta，再加上路由头（Mcp-Method、Mcp-Name），让负载均衡器不读消息体就能路由。意图是在普通 HTTP 基础设施上做横向扩展：任何服务器实例都能服务任何请求。它还把独立版本化的扩展正式化（随附用于服务端渲染 UI 的 MCP Apps 和用于异步工作的 Tasks），加上 12 个月的弃用政策和一套合规套件。相对 2025-11-25，这些是破坏性变更。在依赖无状态行为之前，先确认最终发布日期，以及自己的客户端/服务器是否支持。

• 注册表与发现。 已有一个带命名空间验证的官方 MCP Registry，MCP Server Cards（一种 .well-known 元数据格式）让注册表和爬虫无需活连接就能发现服务器。常被引用的「500+ 个公开服务器」是一个变动的、二手来源的数字。

生产里，不会让每个智能体直接拨号任意 MCP 服务器，而是把 MCP 流量路由经过一个受治理的代理（「MCP 网关」，agentgateway 之类），由它做认证、允许列表和审计，正如模型网关治理 token 流量那样。无论哪种方式，框架说的都是 MCP；一个工具是本地子进程、远程 HTTP 服务还是进程内函数，对智能体代码几乎毫无影响。这种可移植性，正是 MCP 作为传输协议而非库 API 的全部意义。

进程内 MCP 工具模式的一个最小示意，用 Claude Agent SDK 的形态写出。确切的当前 API 请查 SDK 文档。

from claude_agent_sdk import tool, create_sdk_mcp_server, query, ClaudeAgentOptions

@tool("lookup_order", "Look up an order by id", {"order_id": str})
async def lookup_order(args):
    row = await db.fetch_order(args["order_id"])
    return {"content": [{"type": "text", "text": row.summary()}]}

server = create_sdk_mcp_server(name="ops-tools", version="1.0.0", tools=[lookup_order])

async for msg in query(
    prompt="Refund the late order for customer 4471 and explain why.",
    options=ClaudeAgentOptions(
        mcp_servers={"ops": server},
        allowed_tools=["lookup_order", "Read"],
        # 模型访问经由网关 base_url + 虚拟密钥解析，
        # 而非原始的提供方凭据
    ),
):
    print(msg)

同一个智能体也可以改为指向 MCP 网关后面、经 HTTP 接入的外部 MCP 服务器。框架代码几乎不用动。

沙箱：执行的载体

沙箱是一台一次性的、隔离的计算机，交给智能体在里面运行不受信任的代码。模型写下一段 Python、一条 shell 命令、一次 git 操作，或者一整套开发循环，这些代码跑在某个地方：不是开发者的笔记本，不是生产集群，也不与另一个租户的密钥共享内核。

安全理由很直接：智能体一旦能执行代码，网关上的越狱过滤器对 rm -rf、对挖矿程序、对模型被诱导吐出的外泄 curl，统统无能为力。2026 年的安全共识（Firecrawl 等）是：稳健防御依赖代码运行物理环境的隔离，而不是在系统提示里好言相劝。这是 第 56 章 的实战面：执行边界在运行时，而不在提示。

两种隔离模型占主导，二者间的取舍基本就是全部胜负手：

• 微虚拟机隔离（Firecracker、Cloud Hypervisor、Kata）。每个沙箱都是一台真实的、最小化的虚拟机，有自己的来宾内核，靠硬件虚拟化（KVM）与主机隔开。这是对不受信任代码而言最强的常见部署边界，与 AWS Lambda 同一血脉。Firecracker 报告称可在低至约 125 毫秒内启动用户代码，每主机每秒最多创建约 150 个微虚拟机（项目文档，2026 年数据）。

• 用户态内核 / gVisor 隔离。 一个用户态内核拦截系统调用，来宾从不直接和主机内核对话。生产级（Google Cloud Run 用的就是它），用微虚拟机硬件隔离的一丝，换自定义镜像更快的启动。Modal 用这个模型。

第三档更弱，是共享主机内核的普通容器，很常见，但对不受信任的代码应视为软边界，除非在下面垫上 gVisor 或微虚拟机来加固。第四档是 V8 isolate（Cloudflare Dynamic Workers），更快，但只能跑沙箱化的 JS/WASM，跑不了任意操作系统。在普通容器与毫无隔离之间，还有一层操作系统级沙箱：Anthropic 开源的 sandbox-runtime，也就是 Claude Code 底下的那层约束，在 Linux 上用 bubblewrap 加 seccomp、在 macOS 上用 sandbox-exec 把进程关在受限环境里，网络默认拒绝、须经代理放行。这一档适合开发者在自己机器上跑半受信的智能体，不适合多租户的不受信任代码。

选手对比

下表的所有延迟和价格数据截至 2026 年年中，来自厂商或第三方报告，未经独立核验。把这张表当作起点地图，而非价目表，投入前请到各厂商的定价页确认当前费率。

如何具体地选

决策由三条轴主导：隔离强度对启动延迟、临时对持久、以及智能体需要碰什么（shell、GPU，还是浏览器）。

• 选 E2B：想要智能体原生、微虚拟机隔离的流行代码盒，带开源 SDK 和可选的自托管出路，跑短时的 Python/JS 工具调用。
• 选 Modal：智能体既要运行不受信任代码，又要在同一个隔离环境里命中 GPU。
• 选 Fly Machines / Sprites：想要微虚拟机控制权、为可复现评测运行做快照恢复，且空闲零计费。
• 选 Vercel 或 Cloudflare Sandbox：应用已经部署在对应平台里。把 Cloudflare 的边缘分布和 V8 快速路径，与 Vercel 的 Firecracker 盒子和预置内存计费放在一起掂量。
• 选 Runloop：要构建一个编码智能体，想要可挂起/恢复的 devbox，外加内置的 SWE 式基准。
• 选 Browserbase（或 Anthropic Managed Agents）：智能体在浏览器里行动，而不在 shell。
• 在 Firecracker 上自托管：仅当沙箱化本身就是核心业务。

价格对比很棘手。「仅活跃 CPU」的提供商，仍可能对预置内存按整个生命周期计费（Vercel），而平台最低费用或 Durable-Object 费用（Cloudflare）藏在标称 vCPU 费率之下。永远要对自己的运行形态建模（生命周期、空闲占比、并发），而不是看每小时的标价。

空闲占比会拉开两类账单的差距：一种只按活跃 CPU 收费，另一种还对整个生命周期收预置内存。

# 一个突发型智能体：在长时间等待模型的空闲之间，出现短促的 CPU 峰值。
lifetime_s = 600          # 10 分钟的盒子，整个任务期间都存活
cpu_price = 0.000040      # 每活跃 vCPU-秒的美元价
mem_price = 0.0000060     # 每预置 GB-秒的美元价（空闲时也照样计费）
mem_gb = 2.0
for idle in [0.0, 0.5, 0.8, 0.95]:
    active_s = lifetime_s * (1 - idle)
    cpu_cost = active_s * cpu_price
    mem_cost = lifetime_s * mem_gb * mem_price   # 整个生命周期，而非仅活跃时段
    total = cpu_cost + mem_cost
    mem_share = 100 * mem_cost / total
    print(f"idle={idle:>4.0%}  active-CPU=${cpu_cost:.4f}  "
          f"provisioned-mem=${mem_cost:.4f}  total=${total:.4f}  "
          f"mem={mem_share:.0f}% of bill")

结论：空闲占比越高（智能体越多地在等模型），预置内存这一行就越主导账单，哪怕是在一个「仅活跃 CPU」的提供商上也如此。

一个稳妥的默认。 2026 年要构建一个会跑代码的智能体的团队，默认用 E2B 做托管的、微虚拟机隔离的执行：智能体原生、有真正的开源 SDK、有自托管的退路、隔离强（Firecracker），按秒计费也适合突发的工具调用。如果智能体需要盒内 GPU，改默认为 Modal。如果特别想要为可复现评测做快照恢复（第 87 章）且空闲零计费，默认用 Fly Machines / Sprites。对于 Latere 栈，内部的对应物是 Cella，已披露为作者自有基础设施，因而不是中立之选。

安全地接线在一起

智能体框架是消费者，不是枢纽。它经网关调用模型，从检索拉取接地信息，经 MCP 触及工具，在沙箱里跑代码，并发出评测层和可观测层去读的追踪。图 85.3 给出了在生产里站得住的形态。

有三件事让它站得住：

1. 框架从不持有提供方密钥或原始凭据。 它持有的是一个限定在模型允许列表和预算上的网关虚拟密钥，MCP 流量则经过一个掌管工具凭据和允许列表的网关。把一个模型换成另一个，或给失控的循环加封顶，都是一次服务端改动。

2. 状态住在检查点里，不在进程内存里。 一个持久的 State（LangGraph 的检查点、Pydantic AI 的持久化执行），才能让长时运行的智能体承受一次重启，也才能让人类暂停、检查、再恢复。

3. 沙箱把密钥、模型访问和网络都留在盒子外面。 它们只通过狭窄、可审计的通道伸进来：模型走网关虚拟密钥；提供商愿意铸造的凭据走短时效的受限令牌，它不愿轮换的静态密钥走出网替换（第 56 章）；网络走默认拒绝的出网。

一个最小的安全用法配置示意。形态比确切的键名更重要，请按各自的沙箱提供商来调。

sandbox:
  isolation: microvm          # firecracker/gvisor; not a bare container for untrusted code
  lifetime: ephemeral         # destroy after the run: nothing persists, nothing leaks
  timeouts:
    per_tool_call: 30s
    per_task: 10m
    max_lifetime: 30m
  network:
    egress: deny              # default-deny
    allow: ["pypi.org", "api.internal.example.com"]
  secrets:
    inject: none              # no raw provider keys or static secrets in the box
    model_access_via: gateway # short-lived scoped virtual key only
    credentials_via: egress-substitution  # proxy swaps a placeholder for the real secret toward allowed hosts
  audit:
    log: [commands, network_requests, file_writes]   # immutable trail
  approval:
    require_human_for: [payments, production_writes]

这些安全实践在 2026 年的各类来源里反复出现，也以「能力、效率、信任」这一视角为本章收尾：最小权限、短时效凭据；把每个工具或浏览器的输出都当作不受信任的输入，把「思考」和「行动」分开；默认拒绝出网，再配显式允许列表；在工具、任务、沙箱生命周期各级设硬超时；不可变的审计日志；默认临时，好让状态和凭据不堆积；以及对不可逆操作设置人在环关卡。

延伸阅读

框架与 MCP，一手来源：

• OpenAI Agents SDK（docs）：https://openai.github.io/openai-agents-python/；GitHub：https://github.com/openai/openai-agents-python
• OpenAI, "A practical guide to building agents"：https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
• Claude Agent SDK（Python, GitHub）：https://github.com/anthropics/claude-agent-sdk-python；docs：https://platform.claude.com/docs/en/agent-sdk/python
• LangGraph（GitHub）：https://github.com/langchain-ai/langgraph；1.0 announcement：https://www.langchain.com/blog/langchain-langgraph-1dot0
• CrewAI：https://www.crewai.com/；docs：https://docs.crewai.com/
• Pydantic AI（docs）：https://ai.pydantic.dev/；durable execution：https://pydantic.dev/docs/ai/integrations/durable_execution/overview/
• LlamaIndex：https://docs.llamaindex.ai/
• Mastra：https://mastra.ai/
• Google ADK：https://adk.dev/；https://github.com/google/adk-python
• AWS Strands Agents：https://strandsagents.com/
• Microsoft Agent Framework（Microsoft Learn）：https://learn.microsoft.com/en-us/agent-framework/overview/；AutoGen maintenance-mode status：https://github.com/microsoft/autogen/discussions/7210
• AG2（GitHub）：https://github.com/ag2ai/ag2
• MCP specification：https://modelcontextprotocol.io/；2026 roadmap：https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/；2026-07-28 release candidate：https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

沙箱，一手来源：

• E2B pricing and overview：https://e2b.dev/pricing；https://e2b.dev/
• Modal sandboxes（gVisor, GPU pricing）：https://modal.com/resources/best-code-execution-sandboxes-ai-agents
• Fly.io agent sandbox / Sprites：https://fly.io/learn/agent-sandbox/；architecture：https://fly.io/docs/reference/architecture/
• Firecracker project：https://firecracker-microvm.github.io/
• Cloudflare Containers & Sandboxes GA（Apr 13 2026）：https://developers.cloudflare.com/changelog/post/2026-04-13-containers-sandbox-ga/；Dynamic Workers：https://blog.cloudflare.com/dynamic-workers/
• Vercel Sandbox vs E2B（official KB）：https://vercel.com/kb/guide/vercel-sandbox-vs-e2b
• Daytona pricing：https://www.daytona.io/pricing
• Runloop pricing：https://runloop.ai/pricing
• Northflank AI sandbox pricing comparison（2026）：https://northflank.com/blog/ai-sandbox-pricing
• Browserbase + Anthropic Managed Agents：https://docs.browserbase.com/integrations/anthropic/managed-agents/introduction
• Firecrawl, "AI Agent Sandbox: How to Safely Run Autonomous Agents in 2026"：https://www.firecrawl.dev/blog/ai-agent-sandbox
• Cella（latere.ai, author's own product）：https://cella.latere.ai/

二手对比（仅用于佐证；其中的排名与观点未经独立核验）：QubitTool 2026 框架对决；TURION.AI 的 LangGraph vs OpenAI vs Claude Agent SDK；WorkOS 的「Everything your team needs to know about MCP in 2026」；Northflank 的最佳沙箱运行器（2026）。