AI Agent 框架的"特性分化"：从代码审计看学术与工业的特性需求差异¶

TL;DR

我审计了 12 个主流 Agent 框架的源码（OpenAI Agents SDK、Claude Agent SDK、Codex CLI、OpenCode、Kimi CLI、Gemini CLI、Qwen Code、SWE-agent、OpenManus、Aider、Goose、OpenHands），发现一个反直觉的事实：各框架的核心循环（Agent Loop）逻辑高度相似。真正的差异不在于"用了什么算法"，而在于工程特性的组合选择——状态管理、安全控制、协议支持等 30+ 个特性的不同实现。这种"特性分化"导致学术界难以使用最先进的 Agent 能力，形成了一道隐形的鸿沟。

Stars 排名（截至 2026-02-27）：OpenCode (112K) > Gemini CLI (95.9K) > Claude Code (70.8K) > OpenHands (68.3K) > Codex CLI (62.2K) > Aider (41K) > Goose (31.4K) > OpenAI Agents SDK (19.2K)

阅读导航

第 1-3 节：代码审计观察（事实层）
第 4 节：学术与工业特性需求差异的具体表现（事实 + 推断）
第 5 节：未来收敛趋势（作者判断）
第 6 节：选型与实践建议（行动层）
详细框架对比矩阵
各框架深度源码分析

一、破除迷思：Agent 的核心循环高度稳定¶

重要限定

本文聚焦单 Agent 工具调用范式（Single-Agent Tool-Calling Pattern）。这是当前 12 个开源框架的主流架构。Multi-Agent 编排（如 Planning、Agent 间通信）、Planner-Executor 分离等范式不在本文讨论范围。

1.1 12 个框架的核心循环：统一的底层逻辑¶

基于对 12 个框架源代码的深度审计，一个反直觉的事实浮现出来：尽管实现语言、设计哲学和应用场景千差万别，所有框架的核心控制流（Agent Loop）遵循着高度相似的范式。这种相似性如此稳定，以至于可以追溯到 2022 年 ReAct 论文发表时的基本结构。

本节将 12 个框架归纳为 4 种架构模式，展示它们如何在同一底层逻辑上进行差异化实现。

模式一：标准同步循环模式二：异步事件驱动模式三：三层 Actor 模型模式四：增强型循环

代表框架：OpenAI Agents SDK、SWE-agent、OpenManus、Aider

这是最经典、最直观的实现方式。一个 while 循环持续运转，直到满足终止条件。

OpenAI Agents SDK（Python，600+ 行生产级实现）：

# src/agents/run.py:637（实际源码位置）
while True:
    # 包含状态恢复、guardrails、handoffs 等复杂逻辑
    turn_result = await run_single_turn(agent, tools, ...)
    if isinstance(turn_result.next_step, NextStepFinalOutput):
        break
    # 处理 handoffs、工具执行等

详见 GitHub 源码

SWE-agent（Python，学术研究导向）：

# sweagent/agent/agents.py:350（实际源码位置）
while not step_output.done:
    step_output = self.step()
    if step_output.done:
        self._rloop.on_submit(...)

详见 GitHub 源码

OpenManus（Python，轻量级实验框架）：

# app/agent/base.py:116-154（实际源码位置）
async def run(self, request: Optional[str] = None) -> str:
    async with self.state_context(AgentState.RUNNING):
        while (self.current_step < self.max_steps and 
               self.state != AgentState.FINISHED):
            self.current_step += 1
            step_result = await self.step()
            if self.is_stuck():
                self.handle_stuck_state()

详见 GitHub 源码

Aider（Python，对话式编码助手）：

# aider/coders/base_coder.py:876（实际源码位置）
while True:
    user_message = self.get_input()
    self.run_one(user_message)

详见 GitHub 源码

共同特征：显式 while 循环、同步/异步单线程执行、直接的状态管理。

代表框架：OpenHands

OpenHands 采用了完全不同的架构哲学：没有显式循环，只有事件流。

# openhands/controller/agent_controller.py（核心逻辑）
class AgentController:
    async def _step(self) -> None:
        """单步执行，由 EventStream 驱动"""
        action = self.agent.step(self.state)
        if action is None:
            return
        await self.event_stream.add_event(action, ...)

    async def on_event(self, event: Event) -> None:
        """事件回调触发下一步"""
        if event.source == EventSource.AGENT:
            await self._step()

架构特点：

EventStream：所有状态变更通过事件流传播
回调驱动：无需 while True，事件自然触发下一步
松耦合：Agent、Runtime、Controller 通过事件而非直接调用交互

详见 GitHub 源码

代表框架：Codex CLI

Codex CLI 使用 Rust 的 Actor 模型实现了三层嵌套循环，将复杂度分层管理：

第一层：Submission Loop - 消息分发中心

// codex-rs/core/src/codex.rs:3685-3855
async fn submission_loop(sess: Arc<Session>, ...) {
    while let Ok(sub) = rx_sub.recv().await {
        match sub.op {
            Op::UserInput { ... } => handlers::user_input_or_turn(...).await,
            Op::ExecApproval { ... } => handlers::exec_approval(...).await,
            Op::Interrupt => handlers::interrupt(...).await,
            Op::Shutdown => break,
        }
    }
}

第三层：Sampling Loop - LLM 流式处理

// codex-rs/core/src/codex.rs:6220-6554
async fn try_run_sampling_request(...) {
    let mut stream = client_session.stream(prompt, ...).await?;
    let mut in_flight: FuturesOrdered<...> = FuturesOrdered::new();

    loop {
        match stream.next().await {
            ResponseEvent::OutputItemDone(item) => {
                if let Some(tool_future) = output_result.tool_future {
                    in_flight.push_back(tool_future);  // 并行执行
                }
            }
            ResponseEvent::Completed { ... } => break,
        }
    }
}

设计哲学：

关注点分离：用户交互、回合管理、LLM 调用分层
高并发：Rust 的 FuturesOrdered 支持并行工具执行
可中断：每一层都可独立处理中断信号

详见 GitHub 源码 | Deep Dive

代表框架：OpenCode、Kimi CLI、Gemini CLI、Qwen Code、Goose

这类框架在标准循环基础上，嵌入了特定的工程能力，体现为代码中的特定检查点和处理逻辑。

OpenCode（上下文压缩与权限检查）：

// packages/opencode/src/session/prompt.ts:347-738
export async function loop(sessionID: string, options?: LoopOptions) {
  let step = 0
  while (true) {
    // 过滤已压缩消息
    let msgs = await MessageV2.filterCompacted(MessageV2.stream(sessionID))

    // 上下文溢出检查
    if (await SessionCompaction.isOverflow({ tokens: lastFinished.tokens })) {
      await SessionCompaction.create({ sessionID, auto: true })
      continue
    }

    // 正常处理
    const result = await processor.process({ user: lastUser, tools, model })
    if (result === "stop") break
  }
}

Kimi CLI（D-Mail 时间旅行机制）：

# src/kimi_cli/soul/kimisoul.py:206-275
async def _agent_loop(self) -> TurnOutcome:
    step_no = 0
    while True:
        step_no += 1
        if step_no > self._loop_control.max_steps_per_turn:
            raise MaxStepsReached(...)

        # 创建检查点
        await self._checkpoint()

        try:
            step_outcome = await self._step()
        except BackToTheFuture as e:  # 时间旅行异常
            await self._context.revert_to(e.checkpoint_id)
            await self._context.append_message(e.messages)
            continue

Gemini CLI（自动继续与循环检测）：

// packages/core/src/core/client.ts:360-450
async *sendMessageStream(request, signal, prompt_id, turns): AsyncGenerator<...> {
  // 循环检测
  if (this.loopDetector.addAndCheck(event)) {
    yield { type: GeminiEventType.LoopDetected }
    return
  }

  // 自动继续
  if (!turn.pendingToolCalls.length) {
    const nextSpeakerCheck = await checkNextSpeaker(...)
    if (nextSpeakerCheck?.next_speaker === 'model') {
      const nextRequest = [{ text: 'Please continue.' }]
      yield* this.sendMessageStream(nextRequest, signal, prompt_id, boundedTurns - 1)
    }
  }
}

Qwen Code（SubAgents 嵌套）：

// packages/core/src/core/client.ts:261-384
async *sendMessageStream(request, signal, prompt_id, options): AsyncGenerator<...> {
  // SubAgents 系统提醒
  const systemReminders = []
  if (hasTaskTool && subagents.length > 0) {
    systemReminders.push(getSubagentSystemReminder(subagents))
  }

  // 递归调用实现自动继续
  if (nextSpeakerCheck?.next_speaker === 'model') {
    yield* this.sendMessageStream([{ text: 'Please continue.' }], ...)
  }
}

Goose（MCP-Native 流式处理）：

// crates/goose/src/agents/agent.rs:575-700+
async fn reply_internal(...) -> Result<BoxStream<'_, Result<AgentEvent>>> {
    Ok(Box::pin(async_stream::try_stream! {
        loop {
            // MOIM 注入
            let conversation_with_moim = super::moim::inject_moim(...).await

            // 从 LLM 提供商流式响应
            let mut stream = Self::stream_response_from_provider(...).await?

            while let Some(next) = stream.next().await {
                // 处理消息、工具调用等
            }
        }
    }))
}

共同特征：

标准 while 循环骨架
在关键节点嵌入工程能力检查（压缩、权限、循环检测等）
流式处理成为标配

统一视图：Agent Loop 的本质¶

无论哪种架构模式，它们都实现了相同的抽象控制流：

flowchart TD
    Start([开始]) --> Input[接收输入]
    Input --> Context[构建上下文]
    Context --> LLM[调用 LLM]
    LLM --> Process[处理响应]
    Process --> Action[执行动作]
    Action --> Check{满足终止条件?}
    Check -->|否| Context
    Check -->|是| Output[返回结果]
    Output --> End([结束])

核心抽象： 1. 接收输入 → 用户请求、系统事件或前一轮的反馈 2. 构建上下文 → 组装历史消息、工具定义、系统状态 3. 调用 LLM → 与语言模型交互（单次或流式） 4. 处理响应 → 解析、验证、转换 LLM 输出 5. 执行动作 → 可能包括：调用工具、修改状态、生成回复、触发 Handoff 等 6. 终止判断 → 循环继续直到满足任意终止条件： - LLM 直接返回最终答案（无进一步动作） - 达到最大迭代次数 - 用户显式中断 - 遇到错误或异常 - 任务完成标记

关键洞察

实际实现中，步骤 4-6 可能有复杂的内部逻辑（并行工具、状态检查、安全检查等），但宏观上都是这个循环结构的变体。

关键洞察

算法层高度稳定：ReAct、Function Calling、Tool Use 的本质都是这个循环
差异在工程实现：状态管理、安全检查、流式处理、压缩策略
架构选择反映场景：研究追求简单可解释，生产追求鲁棒可扩展

这就是 Agent Loop——自 2022 年 ReAct 论文发表以来，本质逻辑保持高度稳定。

1.2 那么，差异到底在哪里？¶

如果核心循环相同，为什么这些框架在实际使用中感觉如此不同？

答案是：特性（Capabilities）的组合选择。

就像一个操作系统，内核（Loop）大家都用 Linux，但发行版（框架）的差异在于： - 用什么包管理器？（工具系统） - 用什么桌面环境？（UI/交互方式） - 用什么安全机制？（权限控制） - 用什么文件系统？（状态管理）

Agent 框架也是如此。核心循环是"内核"，而特性是"发行版定制"。

二、特性的四层分化¶

基于代码审计，我将 Agent 框架的差异归纳为四层特性体系：

Layer 1：核心循环（Core Loop）- 所有框架相同¶

这是不可见的基础设施。无论用哪个框架，你都在用同样的逻辑： - 维护消息历史（Message History） - 调用 LLM（LLM API Call） - 解析输出（Output Parsing） - 执行工具（Tool Execution） - 重复直到完成（Iteration）

重要结论

选择框架时，不要被"用了什么算法"迷惑。所有框架都支持 ReAct、Function Calling、甚至 Tree-of-Thoughts（只是 prompt 不同）。

Layer 2：工程特性（Engineering Capabilities）- 差异化竞争¶

这是真正影响使用体验的层面。基于代码审计，我将关键工程特性归纳为 5 个核心维度：

2.1 状态管理特性（State Management）¶

特性：会话持久化（Session Persistence）

框架	实现方式	代码位置
OpenAI Agents SDK	SQLite / Redis / 自定义（Protocol-based）	`src/agents/memory/session.py:14-55`
OpenCode	SQLite（Drizzle ORM）	`src/storage/database.ts`
Codex CLI	JSONL 文件 + SQLite 元数据	`codex-rs/core/src/state_db.rs`
Kimi CLI	JSONL 文件	`src/session.py:context_file`
SWE-agent	仅 Trajectory 文件（研究用）	`trajectory.jsonl`
OpenManus	❌ 无（In-memory only）	-

为什么重要

生产环境必须支持对话历史持久化。如果 Agent 崩溃了，用户期望能恢复对话，而不是从头开始。

学术困境

SWE-agent 和 OpenManus 缺少通用的生产级 Session 管理（SWE-agent 以 trajectory 持久化为主），导致研究代码难以直接用于生产。

特性：状态序列化与 HITL（Human-in-the-Loop）

这是生产级框架的标志。

OpenAI Agents SDK 的实现（最完整）：

# src/agents/run_state.py:2384 lines
class RunState(Generic[TContext]):
    """可序列化的运行状态，支持中断恢复"""
    input: list[TResponseInputItem]
    output: list[RunItem]
    _current_step: NextStep  # 当前执行步骤
    _last_processed_response: ProcessedResponse

    def approve(self, interruption: Interruption) -> None:
        """人工审批后继续"""

    def to_state_dict(self) -> dict:
        """序列化为 JSON，可存储/恢复"""

使用场景： 1. Agent 提议执行 rm -rf /，系统暂停等待人工确认 2. 用户审查后，选择"拒绝"或"修改后执行" 3. 从暂停点恢复，无需重新运行

采用率：目前仅 OpenAI SDK 提供完整的内置支持。Claude SDK 通过 Hooks 可部分实现，其他框架多需自行补齐。

特性：上下文压缩（Context Compaction）

OpenCode 的代表性实现：

// src/session/prompt.ts:274-724
if (await SessionCompaction.isOverflow(sessionID)) {
    // 自动触发压缩
    await SessionCompaction.create({
        sessionID,
        reason: "token_limit_approaching"
    });
    continue;  // 重新循环，使用压缩后的上下文
}

为什么重要

Long-context LLM（如 Gemini 1M tokens）虽然出现，但 cost 仍是问题。OpenCode 的 Smart Compaction 在长会话场景下有助于降低 token 消耗（具体收益取决于任务与配置）。

学术困境

学术界通常使用短对话（< 10 轮），对 compaction 需求较低；但生产环境的长对话（> 50 轮）往往更需要此特性。

2.2 安全控制特性（Security Controls）¶

这是企业级框架的核心差异点。5 种安全模型并存：

模型 1：无安全模型 2：Guardrails模型 3：Hooks模型 4：策略引擎模型 5：沙箱隔离

OpenManus：依赖运行环境安全
适用场景：受控的学术研究环境

OpenAI Agents SDK：

@input_guardrail
async def check_pii(context, input_items):
    """检查是否包含个人信息"""

@output_guardrail  
async def check_sensitive_output(context, output):
    """检查输出是否敏感"""

@tool_guardrail
def dangerous_tool_guardrail(context, tool_call):
    """检查工具调用是否危险"""

特点：三层防护（输入/输出/工具），Python 装饰器实现
局限：纯软件层，无法阻止底层系统调用

Claude Agent SDK（代表性实现）：

# 10+ 个钩子事件
hooks = {
    "PreToolUse": [check_safety],           # 工具执行前
    "PostToolUse": [log_result],            # 工具执行后
    "UserPromptSubmit": [check_prompt],     # 用户提交时
    "SubagentStart": [init_subagent],       # 子代理启动
    "SubagentStop": [cleanup_subagent],     # 子代理停止
    # ... 更多
}

特点：极致灵活，可在任何步骤介入
代价：需要开发者深度参与，学习成本高

OpenCode（Wildcard Pattern）：

{
  "permission": {
    "bash": {
      "rm *": "deny",
      "rm -rf /": "deny",
      "*": "ask"
    }
  }
}

Gemini CLI（TOML Policy）：

[policy]
approval_mode = "manual"
trusted_folders = ["/home/user/safe"]

[[policy.rules]]
tool = "shell"
pattern = "sudo *"
action = "deny"

特点：声明式配置，Last Match Wins
优势：非开发者也能理解和修改

Codex CLI（代表性实现）：

// codex-rs/core/src/seatbelt.rs (macOS)
// codex-rs/core/src/landlock.rs (Linux)  
// codex-rs/core/src/windows_sandbox.rs (Windows)

pub struct SandboxPolicy {
    pub policy_type: PolicyType,
    pub writable_roots: Vec<PathBuf>,  // 可写目录白名单
    pub network_access: bool,          // 网络访问控制
}

// 三层安全
1. Platform Sandbox（OS-level 进程隔离）
2. Approval Policy（.rules 文件，命令级控制）
3. Network Control（协议/主机/端口级控制）

特点：在本次调研框架中提供最完整的 OS-level 隔离能力
代价：Rust 实现，配置复杂，性能开销

安全特性总结：

安全级别	代表框架	适用场景	侵入性
Level 0	OpenManus	学术研究	无
Level 1	OpenAI SDK	一般应用	低（装饰器）
Level 2	Claude SDK	需要灵活控制	中（Hooks）
Level 3	OpenCode, Gemini	策略可配置	低（配置文件）
Level 4	Codex CLI	企业/金融/医疗	高（Sandbox）

学术困境

学术界通常使用 Level 0-1，但工业界（尤其金融、医疗）需要 Level 3-4。这导致学术代码难以直接部署。

2.3 工具系统特性（Tooling System）¶

特性：MCP（Model Context Protocol）支持深度

深度级别	框架	实现
Level 0	SWE-agent	❌ 不支持
Level 1	OpenAI SDK	⚠️ 可通过 tools 接入外部 MCP
Level 2	OpenCode, Kimi, Gemini, Qwen	✅ MCP Client（连接外部服务器）
Level 3	OpenManus	✅ MCP Client + Server（FastMCP）
Level 4	Claude SDK	✅✅✅ SDK MCP（In-Process，零开销）
Level 5	Codex CLI	✅✅✅✅ 双角色（Client + Server）

Claude SDK 的 SDK MCP（创新）：

# 在 Python 进程中运行 MCP 服务器，无需子进程
@tool("fibonacci", "Calculate fibonacci", {"n": int})
async def fibonacci(args):
    return {"content": [{"type": "text", "text": f"fib({args['n']})"}]}

server = create_sdk_mcp_server("math-tools", tools=[fibonacci])

为什么重要

传统 MCP 常需启动子进程（npx, python 等），会带来额外启动与通信开销。Claude 的 SDK MCP 直接在进程中运行，可显著降低这部分开销。

特性：并行工具执行（Parallel Tool Execution）

OpenAI Agents SDK：

# 自动并行（asyncio.gather）
await asyncio.gather(
    *[execute_tool(tc) for tc in response.tool_calls]
)

SWE-agent/OpenManus：

# 串行执行
for tool_call in response.tool_calls:  # 一个一个执行
    result = execute_tool(tool_call)

性能差异：如果 Agent 需要同时"查询天气、查日历、搜索邮件"，并行执行快 2-3 倍。

学术困境

学术研究通常用串行（易于分析执行顺序），但生产环境往往更需要并行。

2.4 可观测性特性（Observability）¶

特性：结构化追踪（Structured Tracing）

OpenAI Agents SDK（最完整）：

# 6 种 Span 类型
AgentSpan        # Agent 执行
GenerationSpan   # LLM 调用
FunctionSpan     # 工具调用
HandoffSpan      # Agent 切换
GuardrailSpan    # 安全检查
CustomSpan       # 自定义

# 导出到 6+ 平台
set_trace_processors([
    LogfireProcessor(),      # Logfire
    AgentOpsProcessor(),     # AgentOps
    BraintrustProcessor(),   # Braintrust
    # ...
])

为什么重要

You can't improve what you can't measure。生产环境通常需要知道：

每个 LLM 调用花了多少钱？
哪个工具最慢？
为什么 Agent 陷入循环？

采用率：仅 OpenAI SDK 提供较完整的内置结构化 Tracing；其他框架多为实验性 telemetry、hooks 或基础日志。

学术困境

学术界用 Trajectory 文件（SWE-agent），但那是给人类读的，不是给机器分析的。

2.5 项目上下文特性（Project Context）¶

特性：Project Memory Files（项目记忆文件）

新兴标准：CLAUDE.md、AGENTS.md、GEMINI.md

Gemini CLI 的实现：

# GEMINI.md - 项目级 Agent 配置

## 项目概述
这是一个 Python Web 应用，使用 FastAPI 框架。

## 编码规范
- 使用 PEP 8 风格
- 所有函数必须包含类型注解
- 异步函数使用 async/await

## 常用命令
- 运行测试：`pytest tests/`
- 启动服务：`uvicorn main:app --reload`
- 代码检查：`ruff check .`

## 关键文件
- `app/models.py` - 数据模型定义
- `app/routers/` - API 路由
- `tests/conftest.py` - 测试配置

为什么重要

知识沉淀：将项目知识从人脑转移到文件
跨会话记忆：Agent 重启后仍能读取项目上下文
团队协作：团队成员共享相同的 Agent 配置

采用情况： - Claude Code: CLAUDE.md - OpenCode: AGENTS.md - Gemini CLI: GEMINI.md - Codex CLI: AGENTS.md - Warp: 读取所有记忆文件（CLAUDE.md、AGENTS.md、GEMINI.md）

Warp 的创新：自动检测并读取所有主流记忆文件，实现"如果切换 Agent，它自动理解你的项目"。

Layer 3：协议支持（Protocol Support）- 生态兼容性¶

这一层不是单个框架能决定的，而是行业标准。

3.1 MCP（Model Context Protocol）¶

什么是 MCP

MCP（Model Context Protocol）是 Anthropic 于 2024 年 11 月提出的开放协议标准，旨在为 AI Agent 与外部工具、数据源之间的通信建立统一规范。其设计哲学类似于计算机硬件的 USB 接口——标准化连接器，即插即用。

核心架构：

flowchart LR
    Host["Host\n(Agent)"] <-->|"stdio"| Client["Client\n(Transport)"]
    Client <-->|"MCP协议"| Server["Server\n(Tools)"]

设计原则： 1. Transport 无关：支持 stdio、HTTP、WebSocket 等多种传输层 2. 能力协商：Client 与 Server 动态协商支持的功能（tools/resources/prompts） 3. 双向通信：不仅是 Tool Call，还支持 Resource 订阅、Prompt 模板等 4. 类型安全：基于 JSON-RPC 2.0，严格的 schema 定义

生态现状（截至 2026-02）：

维度	数据
官方 Server 数量	30+（GitHub、Slack、PostgreSQL、Puppeteer 等）
社区 Server	1000+（mcp.so 等第三方注册表）
框架支持率	11/12（仅 SWE-agent 不支持）
IDE 集成	Claude Desktop、Cursor、Zed、VS Code 等

深度差异分析：

不同框架对 MCP 的支持深度存在显著差异（见 2.3 节表格）：

Level 1-2（Client-only）：OpenCode、Gemini、Kimi 等通过外部进程启动 MCP Server，通过 stdio/SSE 通信
Level 3（Client + Server）：OpenManus、Codex 既能连接外部 MCP Server，也能自身暴露 MCP 接口
Level 4（SDK MCP）：Claude SDK 的独有创新——在 Python 进程中直接运行 MCP Server，消除子进程开销
Level 5（MCP-Native）：Goose 将所有工具抽象为 MCP，通过统一接口调用，实现真正的工具无关架构

为什么 MCP 如此重要

打破工具孤岛：以前每个框架有自己的工具格式（OpenAI Function、LangChain Tool、Google Tool），现在统一为 MCP
生态网络效应：开发者写一次 MCP Server，所有支持的框架都能使用
降低迁移成本：企业可以将内部 API 包装为 MCP Server，在不同 Agent 框架间无缝切换
学术可复现性：benchmark 工具 MCP 化后，不同框架能在相同条件下公平对比

学术机会：将 SWE-Bench、HumanEval 等评估工具的沙箱环境封装为 MCP Server，让工业级框架（OpenAI SDK、Codex）也能在标准环境下评估，消除"我的框架比你强"这类不可比结论。

MCP 的局限与替代方案

引用

本节基于业界实践观察，特别是 Lynxe 作者的系列文章（2025）中的深入分析。

尽管 MCP 提供了标准化的协议层，但在实践中它并非唯一选择，甚至可能存在更轻量的替代方案：

1. MCP 的局限性 - 协议转换开销：MCP 需要在 Client 和 Server 之间进行 JSON-RPC 协议转换，对于简单的工具调用而言，这一层可能是"过度设计" - 生态依赖：虽然标准化降低了单次集成成本，但仍需要维护 MCP Server 的运行时（Node.js/Python 进程） - 学习曲线：开发 MCP Server 需要理解协议规范，对于只想快速暴露一个 shell 脚本的场景来说，门槛仍然较高

2. 替代方案：直接函数/命令行调用 事实上，工具集成的核心需求很简单：函数名 + 参数 + 描述。基于这一前提，业界出现了多种轻量级替代方案：

直接命令行调用：通过 bash 或 curl 直接调用本地脚本或远程 API，无需额外的 MCP Server 封装层
函数接口（Func-Agent）：如 Lynxe 框架所实践的，将 Agent 能力直接暴露为函数接口，让既有系统可以通过标准函数调用方式使用 Agent
技能文件（Skills）：Claude 提出的方案，通过 SKILL.md 文档描述工具使用流程，配合 Function Calling 直接执行 shell 命令

3. 方案对比

维度	MCP	直接函数/命令行	Skills
复杂度	需要实现 MCP Server	无需额外协议层	需要编写 SKILL.md
适用场景	需要跨框架复用的标准化工具	快速集成既有系统	复杂流程的文字化描述
灵活性	受限于协议规范	完全自由	依赖模型理解文档
生态兼容	所有支持 MCP 的框架	需为每个框架单独集成	仅限支持 Skills 的客户端

关键洞察

MCP 和直接函数调用并非对立关系，而是解决不同问题的方案。MCP 适合需要广泛复用的工具（如 GitHub、Slack 集成），而直接函数调用更适合快速集成内部系统。未来可能是两者并存的混合模式。

3.2 ACP（Agent Client Protocol）¶

什么是 ACP

ACP（Agent Client Protocol）是 Moonshot AI（Kimi）于 2024 年提出的协议标准，专注于解决 Agent 与 IDE 之间的通信标准化问题。如果说 MCP 解决的是"Agent 如何调用工具"，ACP 解决的就是"IDE 如何控制 Agent"。

核心能力： - 会话管理：创建、恢复、持久化 Agent 会话 - 消息传输：标准化的用户输入、Agent 输出格式 - 工具协调：在 IDE 和 Agent 之间同步工具定义与执行结果 - 上下文传递：编辑器状态（光标位置、选中代码）传递给 Agent

当前支持情况： - Kimi CLI：最完整的 ACP Server 实现，支持 ACP 1.0 规范 - OpenCode：部分 ACP 支持，主要用于 IDE 插件通信 - IDE 端：VS Code、JetBrains 通过插件接入（仍在演进）

与 MCP 的关系：

flowchart TD
    IDE["IDE (VS Code/Zed)"] -->|"ACP (Agent 控制协议)"| Agent["Kimi/OpenCode\n(Agent Host)"]
    IDE -->|"MCP (工具协议)"| Tools["External Tools\n(MCP Servers)"]
    Agent -->|"MCP"| Tools

ACP 和 MCP 是互补关系：ACP 管"人-Agent 交互"，MCP 管"Agent-工具交互"。

3.3 协议层的战略意义：生态锁定 vs 开放性¶

为什么协议比 API 更重要

在软件工程中，协议（Protocol）比 API 具有更强的锁定效应： - API 可以被模仿、封装、适配 - 协议一旦被生态采纳，就会形成网络效应，难以替换

历史类比： - HTTP/TCP：互联网基础设施，30 年未变 - SQL：数据库查询标准，所有数据库都支持 - USB：硬件接口标准，一统外设江湖

MCP 的潜在影响力：

方面	短期（1-2 年）	中期（3-5 年）	长期（5 年以上）
工具生态	官方 + 社区 Server 爆发	主流 SaaS 都提供 MCP	MCP 成为默认集成方式
框架竞争	支持深度是差异化点	基础 Client 成为标配	MCP-Native 架构胜出
学术影响	benchmark MCP 化提案	标准化评估环境	论文可复现性大幅提升
商业格局	Anthropic 领先	OpenAI 跟进	去中心化工具市场

关键洞察

协议标准化不可阻挡：Agent 生态需要互操作性，封闭协议终将被开放标准取代
先发优势明显：Anthropic 推动 MCP，其他厂商（OpenAI、Google）已跟进支持
工具供应商的福音：写一次 MCP Server，对接所有 Agent 框架，ROI 远高于适配每个框架的私有 API
企业的迁移成本降低：内部工具 MCP 化后，Agent 框架可自由替换，避免 vendor lock-in

对框架选型的启示： - 优先选择 MCP 支持完善的框架（Level 3+），确保工具生态兼容性 - 关注框架的 MCP Server 能力（能否对外暴露 Agent 能力） - 自建工具时，直接实现 MCP Server 而非私有 API

Layer 4：交互方式（Interaction Mode）- 最表层¶

这是用户直接感知的差异：

模式	框架	适用场景
Python SDK	OpenAI SDK, Claude SDK	嵌入应用、Jupyter Notebook
CLI TUI	OpenCode, Codex, Kimi	终端重度用户
Web UI	Kimi, Qwen	桌面用户
IDE Plugin	Gemini, Qwen	开发者工作流

注意：这只是"前端"，背后的 Layer 2-3 特性才是核心。

三、特性的"不统一性"分析¶

3.1 没有"标准特性集"¶

以下是各项目特性的采用热力图（✅ = 完整支持，⚠️ = 部分支持，❌ = 不支持）：

特性	OpenAI SDK	Claude SDK	OpenCode	Codex	Kimi	Gemini	Qwen	SWE-agent	OpenManus	Aider	Goose	OpenHands
Session Persistence	✅	❌	✅	✅	✅	✅	⚠️	⚠️	❌	✅	✅	✅
HITL State	✅	⚠️	❌	❌	❌	❌	❌	❌	❌	❌	❌	❌
Context Compaction	❌	❌	✅	❌	✅	❌	❌	❌	❌	❌	❌	✅
OS Sandbox	❌	❌	❌	✅	❌	❌	⚠️	✅	❌	❌	⚠️	✅
Docker Sandbox	❌	❌	❌	❌	❌	❌	❌	❌	❌	❌	✅	✅
Policy Engine	❌	❌	✅	✅	❌	✅	❌	❌	❌	❌	⚠️	⚠️
10+ Hooks	❌	✅	❌	⚠️	❌	❌	❌	❌	❌	❌	⚠️	❌
MCP Client	⚠️	❌	✅	✅	✅	✅	✅	❌	✅	❌	✅	✅
MCP Server	❌	✅	❌	✅	❌	❌	❌	❌	✅	❌	✅	✅
SDK MCP	❌	✅	❌	❌	❌	❌	❌	❌	❌	❌	❌	❌
Parallel Tools	✅	❌	✅	✅	✅	✅	✅	❌	❌	⚠️	⚠️	✅
Tracing	✅	❌	⚠️	⚠️	❌	⚠️	❌	❌	❌	❌	⚠️	⚠️
LSP Support	❌	✅	✅	❌	❌	⚠️	❌	❌	❌	⚠️	❌	⚠️
Repo Map	❌	❌	⚠️	❌	❌	❌	❌	❌	❌	✅	❌	❌
Project Memory	❌	✅	✅	✅	❌	✅	❌	❌	❌	❌	⚠️	❌
Checkpoints	❌	⚠️	❌	❌	❌	✅	❌	❌	❌	❌	❌	⚠️
Smart Caching	❌	❌	❌	❌	❌	❌	❌	❌	❌	❌	❌	❌

观察： 1. 各框架的特性组合呈现高度差异化 2. Stars 排名（截至 2026-02-27）： - OpenCode (112K): 开源替代 Claude Code，75+ 提供商支持 - Gemini CLI (95.9K): 最慷慨免费层（1000 请求/天） - Claude Code (70.8K): 功能最丰富，深度 IDE 集成 - OpenHands (68.3K): 平台化领军，Docker 沙箱 - Codex CLI (62.2K): Rust 高性能，OS-level 沙箱 - Aider (41K): Git-native, Repo Map（首创） - Goose (31.4K): MCP-Native 架构 - OpenAI Agents SDK (19.2K): HITL State, 完整 Tracing 3. 每个框架都有相对独特的侧重特性： - OpenAI SDK: HITL State, 完整 Tracing - Claude SDK: SDK MCP, 10+ Hooks - OpenCode: Context Compaction, Permission Ruleset - Codex: OS Sandbox, Approval Policy - Kimi: ACP Server - Qwen: Context Variable Templating - SWE-agent: Trajectory Recording - OpenManus: MCP 双角色（Client+Server） - Aider: Git-native, Repo Map（首创） - Goose: MCP-Native 架构 - OpenHands: Docker 沙箱平台, SWE-bench 评估

3.2 低采用率特性（机会点）¶

以下特性在本次调研范围内尚未看到成熟内置实现，但生产环境可能需要：

Circuit Breaker（熔断器）：防止级联故障
Tool Result Cache：避免重复调用
Semantic Memory：长期记忆（不是简单的消息历史）
Multi-Modal Tool：统一处理文本/图像/音频工具
Voice Input（语音输入）：Gemini CLI 实验性支持，Aider、Goose 等社区框架正在探索
Advanced Repo Map：除 Aider 外，大多数框架缺乏代码库级语义理解

学术机会：这些是有价值的研究/工程方向。

四、学术与工业的特性需求差异：基于审计的观察¶

范围说明

本节基于代码审计与对比表的事实观察，分析学术场景与工业场景对 Agent 框架特性的不同需求模式。这种差异可能导致学术成果向工业迁移时的摩擦。

4.1 学术界的"最小可行实现"¶

学术界倾向于选择特性较少的框架：

SWE-agent（研究首选）： - ✅ ReAct Loop（易于分析） - ✅ Trajectory Recording（论文素材） - ❌ Session（不需要持久化） - ❌ Security（受控环境） - ❌ MCP（自成体系） - ❌ Parallel Tools（串行易于分析）

OpenManus（快速实验）： - ✅ 简单 ReAct 链 - ✅ MCP 双角色（探索性） - ❌ 其他大多数特性

为什么？ - 论文关注算法创新（新的 Planning 策略） - 不需要工程特性（Session, Security, Tracing） - 简化实验环境（易于复现）

4.2 工业界的"生产级要求"¶

工业界需要完整特性栈：

金融/医疗行业（选择 Codex CLI）： - ✅ OS Sandbox（数据隔离） - ✅ Approval Policy（人工审批） - ✅ Network Control（防止数据泄露） - ✅ Audit Trail（可审计）

SaaS 产品（选择 OpenAI Agents SDK）： - ✅ Session（用户对话历史） - ✅ HITL（人工介入） - ✅ Tracing（监控成本） - ✅ Provider-agnostic（避免 lock-in）

为什么？ - 生产环境不能崩溃、不能泄露数据、不能失控 - 需要可观测性（知道发生了什么） - 需要成本控制（Token = 钱）

4.3 差异可能导致的问题¶

基于上述特性对比，可以推断以下潜在问题：

场景 1：论文复现的摩擦 - 论文用 SWE-agent 实现了一个新算法 - 工业界想用 OpenAI SDK 复现，发现： - 没有 Trajectory Recording（无法直接对比） - 需要添加 Session、Security、Tracing（额外工程工作） - 可能结果：算法创新好，但迁移到生产环境需要额外工程投入

场景 2：Benchmark 可比性挑战 - SWE-Bench 使用 SWE-agent 的工具（str_replace_editor） - 其他框架（OpenAI SDK, Codex）难以在相同工具条件下运行 - 可能结果：论文对比的可比性受限，"我的框架比你强"这类结论的可信度可能不足

场景 3：先进能力的可用性差异 - Claude Code（闭源）有强大的 Coding Agent 能力 - 学术界无法使用（不可复现） - Claude Agent SDK（开源）有 SDK MCP、10+ Hooks - 但依赖闭源 CLI，学术界可能犹豫 - 可能结果：学术界可能倾向于使用特性较简单的框架（SWE-agent, OpenManus），而非工程特性最完善的框架

五、未来预测：特性会收敛吗？（作者判断）¶

免责声明

本节为趋势判断，基于前文事实推演，不等同于已被数据验证的结论。

5.1 Layer 2（工程特性）：短期内难以收敛¶

原因： 1. 差异化竞争：框架通过独特特性建立护城河 - Codex: "我们最安全的 Agent" - Claude SDK: "最强大的 Hooks 系统" - OpenCode: "100% 开源 + 最强权限控制"

场景分化：不同场景需要不同特性组合
研究：简单 + 可解释
SaaS：成本 + 可观测性
企业：安全 + 合规
技术栈绑定：语言选择限制了特性实现
Rust（Codex）：适合 Sandbox，但不适合快速迭代
Python（OpenAI SDK）：适合 AI 生态，但性能受限
TypeScript（OpenCode）：适合 Web，但 ML 库少

5.2 Layer 3（协议支持）：更可能收敛¶

MCP 正在成为事实标准： - 8/9 框架支持（仅 SWE-agent 不支持） - Anthropic 推动，OpenAI 也接受 - 一旦工具生态 MCP 化，不支持 MCP 的框架竞争力将明显受限

预测： - 2 年内，MCP Client 可能成为基础能力 - 3 年内，MCP Server 成为差异化竞争力（类似现在）

5.3 未来关键特性预测¶

Tier 1：即将成为高优先级（1-2 年）Tier 2：企业级高优先级（2-3 年）Tier 3：前沿探索（长期）

Context Compaction：Long-context LLM 虽强，但 cost 敏感
Structured Tracing：可观测性成为生产高优先级能力
HITL State Management：人工介入是安全底线

Smart Caching：Tool Result Cache（尚未实现）
Multi-Modal Tool：统一处理文本/图像/音频
Semantic Memory：长期记忆（非简单历史）

Self-Reflection：自动改进（类似 Reflexion，但生产级）
Multi-Agent Protocol：标准化 Agent 间协作

六、结论与行动建议：评估 Agent 框架的新范式¶

6.0 Meta 结论：Agent 框架竞争的本质¶

基于对 9 个框架的代码审计，本文的核心洞察是：

核心洞察

Agent 框架的竞争，本质上是工程系统的竞争，而不是推理算法的竞争。

在 2022-2026 年间，Agent 领域经历了从"算法创新驱动"到"系统工程驱动"的转变：

算法创新（2022-2023）：ReAct、Reflexion、Tree of Thoughts 等新推理范式
工程系统（2024-2026）：Session、Tracing、Sandbox、MCP 等基础能力建设

这一转变的标志性事件是 OpenAI Agents SDK 的发布（2025）：它没有提出新的推理算法，而是将 Swarm 的工程实践产品化，提供标准化的 Session、Tracing、Guardrails 能力。

对学术界和工业界的启示： - 学术界如果仍停留在"提出新推理算法"，可能低估工程特性的重要性 - 工业界如果忽视工程系统建设，再好的算法也难以落地生产 - 未来的突破可能来自算法与工程的协同创新（如 Learned Context Compaction、Adaptive Tool Selection 等）

6.1 先避免这三类低信息量问题¶

低信息量问题

"用没用 Function Calling？" -- 只是解析方式，不是架构差异
"支持不支持 MCP？" -- 在本次调研中 8/9 支持，深度不同才是关键
"Stars 多少？" -- 人气不等于适合你的场景

6.2 再用这四组问题做场景化选型¶

高价值选型问题

"Layer 2 特性组合是否符合我的场景？"

做研究？-- 选 Stateless + Trajectory（SWE-agent）
做 SaaS？-- 选 Session + Tracing（OpenAI SDK；若是长会话可补充 compaction 能力）
做企业？-- 选 Sandbox + Policy（Codex）

"是否需要 HITL？"

如果涉及危险操作（删数据、转账），应优先选择支持 HITL 状态管理的框架（如 OpenAI SDK）

"安全需求级别？"

Level 1-2：OpenAI SDK（Guardrails）
Level 3：OpenCode/Gemini（Policy Engine）
Level 4：Codex（Sandbox）

"Provider Lock-in 容忍度？"

零容忍 -- OpenAI SDK（Provider-agnostic）
只用 Claude -- Claude SDK

给学术界给工业界

6.3 给学术界的建议（可执行）¶

选择 OpenAI Agents SDK 作为基准：
- Provider-agnostic（可对比 GPT-4/Claude/Gemini）
- 完整特性（Session, Tracing, Guardrails）
- 生产就绪（易于迁移到工业界）
将评估工具 MCP 化：
- 把 str_replace_editor 等工具发布为 MCP 服务器
- 让所有框架能在相同条件下对比
- 提高论文的可比性和影响力
关注未实现的特性：
- Tool Result Cache（Caching）
- Circuit Breaker（Fault Tolerance）
- Semantic Memory（Long-term Memory）
- 这些是有价值的工程/研究贡献

6.4 给工业界的建议（可执行）¶

不要重新造轮子：
- 核心循环都一样，直接用成熟框架（OpenAI SDK, Codex）
- 把精力放在业务逻辑，而非基础设施
根据场景选择合适的工具集成方案：
- MCP 模式：如果需要跨框架复用的标准化工具，用 MCP Server 暴露内部 API
- 直接函数/命令行：如果仅需快速集成内部系统，可直接通过函数接口或 shell 脚本调用
- 不要 fork 框架代码，保持框架的可升级性
投资可观测性：
- 从 Day 1 就接入 Tracing（OpenAI SDK 的 Logfire/AgentOps）
- 你不知道自己会踩什么坑，直到监控告诉你

定位说明

本节用于定位本文与已有公开文章的关系：哪些观点已有讨论、哪些是本文的增量。

A. 框架选型与工程能力对比（高相关）¶

1. Choosing the Right AI Framework（Enhancial, 2025-10）

https://enhancial.substack.com/p/choosing-the-right-ai-framework-a

覆盖 OpenAI Agents SDK、Claude Agent SDK、LangGraph、MCP 的选型框架。
与本文相似点：强调工程能力（session、guardrails、tracing）比“模型名气”更重要。

2. How to build AI agents with MCP: 12 framework comparison（ClickHouse, 2025-10）

https://clickhouse.com/blog/how-to-build-ai-agents-mcp-12-frameworks

以 MCP 为主线横向比较 12 个框架，提供可运行示例。
与本文相似点：讨论 MCP 深度差异与安全/工具治理。

3. OpenAI AgentKit vs Claude Agents SDK（Bind AI, 2025-10）

https://blog.getbind.co/openai-agentkit-vs-claude-agents-sdk-which-is-better/

聚焦平台化（AgentKit）与 SDK 化（Claude + MCP）的治理差异。
与本文相似点：将差异落在权限、可观测性、控制面，而非"谁更聪明"。

B. CLI Agent 生态横评（中高相关）¶

4. EVERY CLI CODING AGENT, COMPARED（Michael Livshits, 2026-02）

https://michaellivs.com/blog/cli-coding-agents-compared/

对 Codex/Gemini/Qwen/Kimi/OpenCode/SWE-agent 等进行全景比较。
与本文相似点：重视 sandbox、hooks、memory files、MCP 等工程特性。

5. The 2026 Guide to Coding CLI Tools: 15 AI Agents Compared（Tembo, 2026-02）

https://www.tembo.io/blog/coding-cli-tools-comparison

从"供应商绑定、自治度、成本、模型灵活性"维度做系统分类。
与本文相似点：强调工具选型要看约束条件与场景，而非单一指标。

6. The Ultimate Comparison of Claude Code Alternatives（Kevnu, 2025-11）

https://www.kevnu.com/en/posts/the-ultimate-comparison-of-claude-code-alternatives-a-complete-analysis-of-the-10-strongest-cli-ai-programming-tools

覆盖 OpenCode、Qwen、Kimi、Codex、Gemini 等 CLI 工具的能力矩阵。
与本文相似点：提供多工具横向能力对照。

C. 官方方法论与单框架深挖（中相关）¶

7. Building agents with the Claude Agent SDK（Anthropic, 2025-09）

https://claude.com/blog/building-agents-with-the-claude-agent-sdk

提出 gather → act → verify → repeat 的 agent loop 与 compaction/subagent/MCP 实践。
与本文相似点：支持"核心循环高度稳定、差异在工程实现"的观察。

8. I tested 5 AI CLI tools（LogRocket, 2025-12）

https://blog.logrocket.com/tested-5-ai-cli-tools/

以统一任务对多个 CLI 进行可用性和质量对比。
与本文相似点：强调工程可用性与真实工作流表现。

D. 框架实现原理与集成模式深度解析（高相关）¶

9. AI Agent系列｜什么是 ReAct Agent？（沈询，阿里云开发者，2025-02）

https://mp.weixin.qq.com/s/KyWIEX_8oj5lcXjX5Co7Kw

Lynxe 作者深入浅出解析 ReAct Agent 核心原理：观察-思考-行动循环。
与本文相似点：支持"核心循环高度稳定"的观察，详细阐述 ReAct 的 5 个关键要素。

10. AI Agent系列｜深入了解智能体工作流核心（沈询，阿里云开发者，2025-02）

https://mp.weixin.qq.com/s/KE4UWEpoMYiIseykT7_Skw

对比传统编程、Workflow 与 Agent 的本质差异：谁在做决策？
与本文相似点：同样关注工程实现差异，但侧重点在于开发范式与集成方式。

11. AI Agent系列｜深入解析Function Calling、MCP和Skills的本质差异与最佳实践（沈询，阿里云开发者，2025-02）

https://mp.weixin.qq.com/s/dAnNHayrE49FEl8TcLII2Q

提出 MCP 与 Skills 是"竞争关系"而非"互补关系"的深刻观点。
与本文的互补性：本文在 3.1 节引用了该文对 MCP 局限性的分析，以及直接函数/命令行调用作为替代方案的讨论。

12. 从 ReAct 到 Ralph Loop：AI Agent 的持续迭代范式（丹坤，阿里云开发者，2025-02）

https://mp.weixin.qq.com/s/K4ZUGBzT0s9RwFlaYcuHiA

介绍源自 Claude Code 社区的 Ralph Loop 范式，作为 ReAct 的增强模式，通过 Stop Hook 和外部验证解决 LLM "过早退出"问题。
核心机制：用文件系统持久化（progress.txt, prd.json, Git）替代上下文窗口记忆，解决"上下文腐烂"。
与本文的关联：补充了 Agent Loop "何时终止"这一控制策略维度，与本文的"上下文压缩"特性形成技术对照。

本文的增量定位¶

本文增量

用统一的 Layer 1-4 框架整理 12 个项目
将差异系统化到 session/security/policy/MCP/tracing/compaction 等工程维度
明确提出“学术实现到工业落地”之间的特性迁移成本问题

附录：12 个框架的核心代码位置¶

框架	核心循环文件	特性文件	总代码规模
OpenAI Agents SDK	`src/agents/run.py:396-1329`	`src/agents/handoffs/`, `src/agents/tracing/`, `src/agents/memory/`	~15k lines
Claude Agent SDK	`_internal/query.py`	`_internal/query.py:286-299` (Hooks)	SDK ~3k lines
OpenCode	`src/session/prompt.ts:274-724`	`src/permission/next.ts`, `src/session/compaction.ts`	~47k lines
Codex CLI	`codex-rs/core/src/codex.rs`	`codex-rs/core/src/exec_policy.rs`, `codex-rs/core/src/seatbelt.rs`	Core ~10k lines
Kimi CLI	`src/kimi_cli/soul/kimisoul.py`	`src/kimi_cli/acp/`, `src/kimi_cli/session.py`	未统计
Gemini CLI	`packages/core/src/core/client.ts`	`packages/core/src/policy/`, `packages/core/src/tools/mcp-client.ts`	~866 files
Qwen Code	`packages/core/src/core/client.ts`	`packages/core/src/subagents/`, `packages/core/src/skills/`	未统计
SWE-agent	`sweagent/agent/agents.py:1265`	`sweagent/tools/`, `sweagent/agent/`	Agent ~1.3k lines
OpenManus	`app/agent/react.py:11-38`	`app/mcp/`, `app/flow/`	未统计
Aider	`aider/coders/base_coder.py`	`aider/repomap.py` (Repo Map), `aider/git_repo.py`	~8k lines
Goose	`crates/goose-core/src/agent.rs`	`crates/goose-core/src/mcp/client.rs` (MCP-Native)	Core ~3k lines
OpenHands	`openhands/controller/agent_controller.py`	`openhands/runtime/docker/exec_box.py` (Docker Sandbox), `openhands/evaluation/`	~15k lines

参考¶

深度调研文档：deep-dive/*-DEEP-DIVE.md（~400 KB 代码审计，12 个框架）
GitHub 仓库：见各框架链接
MCP 规范：https://modelcontextprotocol.io/
相关博客：
Michael Livshits: Every CLI coding agent, compared (2026-02) - 36 个 CLI Agent 全景对比
ClickHouse: How to build AI agents with MCP: 12 framework comparison (2025-10) - MCP 深度对比

作者与致谢¶

AI 辅助：本研究及博客撰写过程中使用了 Opencode 进行代码审计、架构分析和内容撰写。Opencode 是一个 AI 驱动的软件工程助手，帮助完成了约 400KB 源代码的分析和文档生成。

研究方法：所有技术细节均基于实际源代码审计，具体文件路径和行号可在 deep-dive/ 目录下的各框架深度调研报告中查证。

反馈与贡献：如发现错误或希望补充其他框架分析，欢迎提交 Issue 或 PR。

版本：2026-02-27

许可证：MIT

AI Agent 框架的"特性分化"：从代码审计看学术与工业的特性需求差异¶

一、破除迷思：Agent 的核心循环高度稳定¶

1.1 12 个框架的核心循环：统一的底层逻辑¶

统一视图：Agent Loop 的本质¶

1.2 那么，差异到底在哪里？¶

二、特性的四层分化¶

Layer 1：核心循环（Core Loop）- 所有框架相同¶

Layer 2：工程特性（Engineering Capabilities）- 差异化竞争¶

2.1 状态管理特性（State Management）¶

2.2 安全控制特性（Security Controls）¶

2.3 工具系统特性（Tooling System）¶

2.4 可观测性特性（Observability）¶

2.5 项目上下文特性（Project Context）¶

Layer 3：协议支持（Protocol Support）- 生态兼容性¶

3.1 MCP（Model Context Protocol）¶

3.2 ACP（Agent Client Protocol）¶

3.3 协议层的战略意义：生态锁定 vs 开放性¶

Layer 4：交互方式（Interaction Mode）- 最表层¶

三、特性的"不统一性"分析¶

3.1 没有"标准特性集"¶

3.2 低采用率特性（机会点）¶

四、学术与工业的特性需求差异：基于审计的观察¶

4.1 学术界的"最小可行实现"¶

4.2 工业界的"生产级要求"¶

4.3 差异可能导致的问题¶

五、未来预测：特性会收敛吗？（作者判断）¶

5.1 Layer 2（工程特性）：短期内难以收敛¶

5.2 Layer 3（协议支持）：更可能收敛¶

5.3 未来关键特性预测¶

六、结论与行动建议：评估 Agent 框架的新范式¶

6.0 Meta 结论：Agent 框架竞争的本质¶

6.1 先避免这三类低信息量问题¶

6.2 再用这四组问题做场景化选型¶

6.3 给学术界的建议（可执行）¶

6.4 给工业界的建议（可执行）¶

Related Work（已发表相关文章）¶

A. 框架选型与工程能力对比（高相关）¶

B. CLI Agent 生态横评（中高相关）¶

C. 官方方法论与单框架深挖（中相关）¶

D. 框架实现原理与集成模式深度解析（高相关）¶

本文的增量定位¶

附录：12 个框架的核心代码位置¶

参考¶

作者与致谢¶