AI 范式雷达：《CodeAct — Agent 执行范式的根本性转移》

如果你正在构建一个需要调用多个工具的 AI Agent，你可能已经注意到一个隐蔽的性能瓶颈：不是模型不够聪明，而是编排开销太高。每个工具调用都是一次独立的模型推理回合——生成 token、网络往返、状态序列化。当任务涉及 10 个工具时，你实际上在等待 10 次完整的推理循环。

Microsoft 在 BUILD 2026 上发布的 CodeAct 正在改变这个局面。它不再让 Agent 逐轮选择工具，而是让模型一次性生成一个完整程序，在隔离的微 VM 中批量执行所有工具调用，然后返回聚合结果。这不是渐进式优化——这是从 ReAct 循环到程序化执行的范式转移。

本文将带你理解 CodeAct 的核心原理、它在实际项目中的表现、以及为什么这可能是 Agent 开发中最值得关注的架构变化之一。

---

目录

• 为什么传统 Agent 编排不够用了
• CodeAct 核心原理：从逐轮推理到程序化执行
• Hyperlight 微 VM：隔离与安全如何做到”几乎零开销”
• 动手试试：5 分钟搭建你的第一个 CodeAct Agent
• 进阶：CodeAct vs ReAct vs Plan-and-Execute
• 实际案例：性能对比与适用边界
• 总结与行动清单

---

为什么传统 Agent 编排不够用了

在深入 CodeAct 之前，我们先看一个具体的场景。假设你要构建一个研究助手，它需要完成以下任务：

1. 搜索最新论文（调用 Web Search API）
2. 下载 PDF 并提取摘要（调用文件操作工具）
3. 分析摘要中的关键发现（调用 LLM 分析工具）
4. 将结果写入文档（调用文件系统工具）

在传统的 ReAct 模式下，这个流程需要 4 次完整的模型推理回合：

用户请求 → [推理1: 选择搜索] → [推理2: 解析搜索结果] → 
[推理3: 选择下载+分析] → [推理4: 写入文档] → 最终结果

每次推理回合包含三个成本层：

• 延迟：模型生成 token 的时间 + 网络往返时间（通常 500ms~2s）
• Token 消耗：每轮都要传递完整的上下文窗口，包括之前的工具调用历史
• 状态管理复杂度：需要维护对话状态、错误恢复逻辑、超时处理

当任务从 4 步扩展到 20 步时，问题不是线性增长——是指数级恶化。因为每一步的错误都会污染后续所有步骤的上下文。

💡 关键洞察：Agent 的性能瓶颈往往不在模型能力，而在编排架构。一个中等质量的模型配合高效的执行模式，通常优于一个强模型配合低效的执行模式。

这就是 CodeAct 要解决的根本问题：减少推理回合数，让一次推理完成多步操作。

---

CodeAct 核心原理：从逐轮推理到程序化执行

CodeAct 的核心思想可以用一句话概括：让 Agent 写代码，而不是写决策。

传统模式 vs CodeAct 模式对比

传统 ReAct 循环（左）：

┌─────────┐     ┌──────────┐     ┌──────────┐
│  Model   │────▶│ Tool A   │────▶│  Model   │
│ (推理)   │◀────│ (执行)   │◀────│ (推理)   │
└─────────┘     └──────────┘     └──────────┘
                                              │
┌─────────┐     ┌──────────┐                ▼
│  Model   │────▶│ Tool B   │          ┌──────────┐
│ (推理)   │◀────│ (执行)   │◀─────────│  Model   │
└─────────┘     └──────────┘          │ (推理)   │
                                      └──────────┘

CodeAct 模式（右）：

┌─────────┐     ┌──────────────────────┐
│  Model   │────▶│ Hyperlight Micro-VM │
│ (一次推理)│     │                      │
│          │     │ call_tool(A)         │
│          │     │ call_tool(B)         │
│          │     │ call_tool(C)         │
│          │     │ write_file()         │
│          │     └──────────┬───────────┘
│          │                ▼
│          │         聚合结果返回
└─────────┘

CodeAct 的三个关键组件

1. 程序化输出（Programmatic Output）

模型不再输出”下一步调用哪个工具”，而是直接生成一个可执行的 Python 程序。这个程序通过统一的 call_tool() API 来调用所有需要的工具：

# CodeAct 生成的程序示例
result_search = call_tool("web_search", query="latest AI agent benchmarks")
result_download = call_tool("file_download", url=result_search[0].url)
result_analysis = call_tool("llm_analyze", 
    text=extract_text(result_download),
    prompt="Extract key findings"
)
write_file("research_summary.md", format_output(result_analysis))

2. 批量执行（Batched Execution）

程序在 Hyperlight 微 VM 中一次性运行完毕。所有工具调用按程序逻辑顺序执行，中间结果通过变量传递，最终返回聚合结果给模型。

3. 隔离沙箱（Isolated Sandbox）

每次 CodeAct 执行都在独立的 Hyperlight micro-VM 中进行。这意味着：

• 恶意代码无法影响宿主系统
• 每次执行的资源消耗可精确计量
• 失败不会影响其他 Agent 会话

⚠️ 注意：CodeAct 目前处于 alpha 阶段（agent-framework-hyperlight 包），生产环境使用前需要评估稳定性。Microsoft 计划在后续版本中将其提升为稳定 API。

---

Hyperlight 微 VM：隔离与安全如何做到”几乎零开销”

CodeAct 的安全模型建立在 Microsoft 的 Hyperlight 项目之上。理解它为什么重要，需要先了解传统沙箱方案的痛点。

传统沙箱 vs Hyperlight micro-VM

维度	Docker 容器	Firecracker micro-VM	Hyperlight micro-VM
启动时间	~2s	~125ms	<10ms
内存占用	~50MB+	~5MB	~1MB
隔离级别	进程级	内核级	用户态库级
适用场景	长期运行服务	无服务器计算	单次工具调用

Hyperlight 的核心创新在于：它不是一个完整的虚拟机，而是一个轻量级的执行隔离库。

传统方案: 宿主 OS → Hypervisor → Guest OS → 容器 → 进程
CodeAct:   宿主 OS → Hyperlight Runtime → 隔离执行环境

这种架构使得每次 CodeAct 执行的额外开销可以忽略不计——启动一个微 VM 的时间比一次模型推理的延迟还要短。这意味着你可以为每个 Agent 任务分配独立的隔离环境，而不必担心资源浪费。

安全边界设计

CodeAct 的安全模型采用最小权限原则：

1. 工具白名单：只有显式注册的工具才能被 call_tool() 调用
2. 网络限制：默认禁止出站网络连接（可通过配置开启）
3. 文件系统隔离：Agent 只能访问预定义的目录
4. 超时控制：每个程序执行有最大运行时间限制

# .NET 中的安全配置示例
var codeActOptions = new CodeActOptions
{
    MaxExecutionTime = TimeSpan.FromSeconds(30),
    AllowedTools = ["web_search", "file_read", "llm_analyze"],
    NetworkAccess = NetworkAccessType.Disabled,
    WorkingDirectory = "/tmp/agent-sandbox"
};

💡 小技巧：在生产环境中，建议将 MaxExecutionTime 设置为任务预期耗时的 2-3 倍。过短会导致正常任务超时，过长则失去安全防护的意义。

---

动手试试：5 分钟搭建你的第一个 CodeAct Agent

下面是一个最小可运行的 CodeAct Agent 示例。我们使用 Microsoft Agent Framework (MAF) 的 Python SDK，它同时支持 .NET 和 Python 两种运行时。

环境准备

# 安装 MAF 核心包
pip install agent-framework

# 安装 CodeAct alpha 包
pip install agent-framework-hyperlight

最小代码实现

from agent_framework import create_harness_agent, create_codeact_executor
from agent_framework.tools import WebSearchTool, FileReadTool

# 1. 创建基础 Agent
agent = create_harness_agent(
    client=openai_client,
    max_context_window_tokens=128_000,
    name="ResearchAgent",
    description="A research assistant that uses CodeAct for efficient tool execution.",
)

# 2. 注册工具
tools = [WebSearchTool(), FileReadTool()]

# 3. 启用 CodeAct 执行器
executor = create_codeact_executor(
    tools=tools,
    max_program_length=500,      # 程序最大长度（字符）
    execution_timeout_seconds=30,
)

# 4. 运行任务
result = agent.run(
    prompt="搜索最新的 AI Agent 基准测试结果，提取 Top 3 发现并写入 summary.md",
    executor=executor,
)

print(result.summary)

执行路径图解

用户请求 → CodeAct Executor
                │
                ▼
        ┌───────────────┐
        │  Model 推理    │  ← 一次完整的推理回合
        │  (生成程序)    │     输出: Python 代码
        └───────┬───────┘
                │
                ▼
        ┌───────────────┐
        │ Hyperlight VM  │  ← 隔离执行环境
        │               │
        │ call_tool()   │  → Web Search API
        │ call_tool()   │  → File System
        │ write_file()  │  → summary.md
        └───────┬───────┘
                │
                ▼
        聚合结果返回给用户

预期输出

与传统 ReAct 模式相比，同样的任务在 CodeAct 模式下：

• 推理回合数：1 次（vs ReAct 的 4+ 次）
• 总延迟：模型生成时间 + VM 执行时间（通常 <3s）
• Token 消耗：约减少 60%（无需重复传递中间状态）

⚠️ 注意事项：CodeAct alpha 版本目前仅支持 Python 工具。.NET 工具的完整支持在后续版本中计划推出。如果你的项目主要使用 .NET，可以先通过 REST API 桥接的方式试用。

---

进阶：CodeAct vs ReAct vs Plan-and-Execute

理解 CodeAct 的价值，最好的方式是把它放在 Agent 编排的演进脉络中来看。

三种执行模式的对比

ReAct（推理-行动循环） — 经典模式：

For each step:
    1. Model reasons about current state
    2. Model selects next tool
    3. Tool executes
    4. Result feeds back to model
    Repeat until done

Plan-and-Execute（规划-执行） — 改进模式：

1. Model generates full plan (list of steps)
2. Execute each step sequentially
   - Each step: select tool → execute → observe
3. If failure, backtrack and retry

CodeAct（程序化批量执行） — 新模式：

1. Model generates complete program
2. Program executes all tools in one batch
3. Aggregated results returned to model
4. If needed, model generates revised program

决策矩阵

场景	ReAct	Plan-and-Execute	CodeAct
简单工具调用（1-2个）	✅ 适合	⚠️ 过度设计	⚠️ 杀鸡用牛刀
中等复杂度（3-5个）	⚠️ 延迟累积	✅ 平衡选择	✅ 推荐
高复杂度（6+个）	❌ 不推荐	⚠️ 仍有多轮开销	✅ 最佳选择
需要动态决策	✅ 灵活	⚠️ 部分支持	❌ 限制较多
探索性任务	✅ 适合	⚠️ 有限支持	❌ 不适合
确定性流水线	⚠️ 可用	✅ 适合	✅ 最佳选择

💡 核心原则：CodeAct 不是 ReAct 的替代品，而是补充。在 Agent 框架中同时支持多种执行模式，让开发者根据任务特性选择最合适的策略。

---

实际案例：性能对比与适用边界

基准测试数据

根据 Microsoft BUILD 2026 发布的数据，在典型的 Agent 任务场景下（5-10 个工具调用）：

指标	ReAct	Plan-and-Execute	CodeAct
平均推理回合数	7.3	2.1	1.0
端到端延迟 (s)	8.5	4.2	2.8
Token 消耗 (K)	12.4	6.8	4.1
错误率 (%)	18.3	12.7	9.4

关键发现：CodeAct 将端到端延迟降低了约 67%，Token 消耗减少了约 67%。更重要的是，错误率也显著下降——因为减少了中间状态传递的环节，出错点更少。

CodeAct 的适用边界

CodeAct 并非万能药。以下场景需要谨慎使用：

不适合的场景：

• 交互式调试：需要根据每次工具返回的结果动态调整策略（如调试代码）
• 人类在环审批：某些步骤需要人工确认后才能继续
• 不确定性的探索任务：如”帮我找一个合适的开源项目”，结果不可预测

适合的场景：

• 数据收集流水线：搜索 → 下载 → 解析 → 存储
• 批量 API 调用：同时查询多个数据源并聚合结果
• 文档生成：基于多源信息自动生成结构化内容

Before vs After：一个真实场景

假设你需要构建一个竞品分析 Agent，需要：

1. 搜索 5 个竞品的最新功能更新
2. 下载各竞品的定价页面
3. 提取关键功能对比
4. 生成 Markdown 报告

ReAct 模式：约 20-30 次推理回合，总延迟 25-40 秒 CodeAct 模式：1-2 次推理回合（可能需要一次修正），总延迟 5-8 秒

⚠️ 注意：实际性能取决于模型质量和工具响应速度。上述数据基于 GPT-4o + 标准 API 的测试环境。使用较小模型时，CodeAct 的程序生成质量可能下降，需要更多修正迭代。

---

总结与行动清单

CodeAct 代表了 Agent 执行从”逐轮决策”到”程序化批量执行”的范式转移。核心收益是：减少 60-70% 的推理开销，同时降低错误率。但这不是银弹——它最适合确定性流水线任务，而非需要动态探索的场景。

你现在可以做的：

1. 评估现有 Agent 架构：列出你项目中所有工具调用链，识别出那些”固定流程、多步骤”的任务——这些是 CodeAct 的最佳候选
2. 在沙箱环境中试用：使用 agent-framework-hyperlight alpha 包搭建一个最小 PoC，验证在你的具体场景下的性能提升
3. 混合策略设计：不要全盘替换 ReAct。设计一个混合架构——简单任务用 ReAct，流水线任务用 CodeAct，复杂探索任务保留 ReAct 的灵活性
4. 关注 A2A 协议的演进：当多 Agent 协作成为常态时，CodeAct + A2A（Agent-to-Agent）协议可能产生新的协作模式。提前了解 Google/Anthropic 的 A2A 规范

References

• Microsoft Agent Framework at BUILD 2026
• Agent Harness in Agent Framework
• Hyperlight GitHub Repository
• LangChain: Best AI Agent Frameworks 2026
• Microsoft Agent Framework Documentation