2026：当 OpenCode / Claude Code 已经很好用时，底层 Agent 框架还有多大意义？

Open Table of contents

1. 背景与问题
2. 核心概念
3. 主体内容
4. 实践案例
5. 核心结论
6. 可继续长大的问题
7. 参考资料

1. 背景与问题

最近几个月，很多开发者会自然产生一个判断：

既然 OpenCode、Claude Code 这类 AI coding agent 已经支持 Skills、MCP、Plan、上下文压缩、规则管理、子 Agent，而且能在 CLI / IDE / Desktop 里直接干活，那么那些面向开发者的底层 Agent 框架（如 LangGraph、Google ADK、Microsoft Agent Framework、AgentScope、CrewAI 等）是不是正在快速失去意义？

这个判断有一半是对的：

对低到中复杂度需求，框架的“默认入口地位”确实下降了。
对高复杂度、长生命周期、强工程化系统，框架反而更重要了，因为真正剩下来的都是“产品层封装不掉的硬问题”。

换句话说，行业变化不是：

“框架没用了”

而是：

“大量轻量需求已经被产品化 Coding Agent 吃掉，框架开始更聚焦在复杂系统底座的位置上。”

📡 扩展
OpenCode 官方文档已经把自己的能力明确做成“产品级 agent runtime”：它提供 Agents、Skills、MCP servers、server、desktop、IDE integration 等能力，说明它并不是一个单纯的 prompt 工具，而是一个可直接工作的 coding agent 产品。与此同时，LangGraph 官方文档仍然把 durable execution、human-in-the-loop、memory 作为核心卖点，说明框架层关注点仍然是“复杂运行时问题”，而不是只做简单工具调用。¹ ² ³

2. 核心概念

2.1 什么是“产品层 Agent”

这里的“产品层 Agent”，指的是已经封装好的、可直接使用的 Agent runtime / tool：

典型代表：OpenCode、Claude Code
常见入口：CLI / TUI / IDE / Desktop
常见能力：
- 代码库理解
- Plan / 执行分离
- 子 Agent / specialized agents
- Skills
- MCP 工具接入
- 上下文裁剪与管理
- 规则系统 / 权限系统
- 本地文件系统与 shell 操作

这类产品的核心价值不是“让你搭 Agent 系统”，而是“让 Agent 直接替你干活”。

2.2 什么是“底层 Agent 框架”

这里的“底层 Agent 框架”，指的是为开发者提供的编排、状态管理、工作流控制与部署底座：

典型代表：LangGraph、Google ADK、Microsoft Agent Framework
常见关注点：
- graph / workflow orchestration
- checkpoint / resume
- durable execution
- session state
- 多 Agent 协作
- human-in-the-loop
- telemetry / observability
- 可部署、可恢复、可审计

这类框架的核心价值不是“让模型更会写代码”，而是“让系统更可控地运行”。

📡 扩展
Google ADK 官方把自己定义为“flexible and modular open-source framework for developing and deploying AI agents”，强调兼容其他框架、强调开发、调试、部署与 orchestration；Microsoft Agent Framework 官方则直接把自己定义为 AutoGen 与 Semantic Kernel 路线的继承者，强调 session-based state、type safety、filters、telemetry 与 multi-agent workflows。这说明它们针对的核心问题不是“IDE 里怎么让模型帮我改文件”，而是“如何构建能稳定运行的 agent system”。⁴ ⁵

2.3 什么是“平台层 Agent”

还有一类容易混淆的中间层：平台。

典型代表：Dify
核心特征：
- 可视化 workflow
- RAG pipeline
- Agent 编排
- 模型管理
- 部署与监控
- 团队协作

它既不是纯 SDK，也不是单个终端 Agent 工具，更像“带管理后台和交付能力的 Agent 应用平台”。

📡 扩展
Dify 官方把自己定位为 “production-ready platform / agentic workflow builder”，强调 workflow、RAG、integration、monitoring、deployment。这说明 Dify 更适合“团队快速交付 AI 应用”，而不是只做本地 coding agent。⁶ ⁷

2.4 为什么 Skills / MCP / Plan 会让人觉得“框架不重要了”

因为它们确实在吃掉一部分框架过去承担的表层价值。

Skills

用于把可复用行为封装成结构化能力。

MCP

用于把工具接入标准化、可发现化。

Plan

用于把“先分析再执行”的行为模式产品化。

Context 压缩 / 管理

用于提升长会话和复杂任务时的可持续性。

这些能力叠加后，很多过去需要自己写 agent glue code 的事情，今天在产品层就能直接完成。

📡 扩展
OpenCode 官方文档明确写了：Skills 是可按需发现和加载的行为模块，Agents 支持 primary agents / subagents，并特别提到 plan agent 用于“只分析不改代码”。模型接入方面，OpenCode 也明确说明自己使用 AI SDK 与 Models.dev 来支持多模型与本地模型。也就是说，很多“轻量编排 + 工具接入 + 能力模块化”的需求，今天已经在产品层被系统性封装。² ¹ ⁸

3. 主体内容

3.1 一个更准确的分层认知

flowchart TD
  A([用户需求]) --> B{需求落在哪一层?}

  B -->|本地 coding / repo 自动化<br>个人提效| C[产品层<br>Agent OpenCode · Claude Code]
  B -->|团队交付 / 可视化流程<br>RAG 平台| D[平台层 Dify]
  B -->|长生命周期 / 可恢复<br>多分支编排 / 企业治理| E[框架层<br>LangGraph · Google ADK<br>Microsoft Agent Framework]

  C --> C1[Skills]
  C --> C2[MCP]
  C --> C3[Plan]
  C --> C4[Context 管理]
  C1 ~~~ C2
  C2 ~~~ C3
  C3 ~~~ C4

  E --> E1[Durable Execution]
  E --> E2[Checkpoint / Resume]
  E --> E3[Session State]
  E --> E4[Human-in-the-loop]
  E --> E5[Telemetry / Observability]
  E1 ~~~ E2
  E2 ~~~ E3
  E3 ~~~ E4
  E4 ~~~ E5

  style B  fill:#fffde7,stroke:#f9a825,stroke-width:2px
  style C  fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
  style C1 fill:#e3f2fd,stroke:#90caf9,stroke-width:1px
  style C2 fill:#e3f2fd,stroke:#90caf9,stroke-width:1px
  style C3 fill:#e3f2fd,stroke:#90caf9,stroke-width:1px
  style C4 fill:#e3f2fd,stroke:#90caf9,stroke-width:1px
  style D  fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
  style E  fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
  style E1 fill:#f3e5f5,stroke:#ce93d8,stroke-width:1px
  style E2 fill:#f3e5f5,stroke:#ce93d8,stroke-width:1px
  style E3 fill:#f3e5f5,stroke:#ce93d8,stroke-width:1px
  style E4 fill:#f3e5f5,stroke:#ce93d8,stroke-width:1px
  style E5 fill:#f3e5f5,stroke:#ce93d8,stroke-width:1px

解读

这张图表达的不是“谁取代谁”，而是“不同层级解决不同问题”：

产品层：把 Agent 直接做成可使用工具
平台层：把 Agent 应用做成团队可交付系统
框架层：把 Agent runtime / workflow / state 管理做成可编程底座

很多讨论之所以混乱，是因为把这三层混成了一个“Agent 框架大盘”。

3.2 最近几个月发生了什么变化

过去的默认路径

以前很多人一想到要做 Agent，就会先问：

用哪个框架？
怎么写 tool calling loop？
怎么处理 memory？
怎么写 plan + execute？

现在的默认路径

现在很多人的默认路径变成：

先用 OpenCode / Claude Code
接上 Skills
再加 MCP
用规则系统与 context 管理控制行为
只有在产品层不够时，才下沉到框架层

这本质上说明：

框架的默认入口地位下降了，但不是框架价值消失了。

而是“产品层把简单需求接走了，框架层留下来解决更难的问题”。

3.3 哪些需求已经被产品层覆盖得很好

下表适合当作实践判断的第一版清单。

需求类型	只用 OpenCode / Claude Code 通常就够	备注
单仓库代码理解与修改	是	尤其适合 repo 内重构、修 bug、补测试
通过 MCP 接常见工具	是	例如文档、搜索、数据库、内部 API
将固定行为封装成 Skills	是	很适合团队约定、模板化操作
Plan 后执行	是	产品层已封装“先分析后落地”的体验
轻量 CI / 本地自动化	大多是	复杂失败恢复场景除外
单人或小团队提效	是	这是产品层最强势的适用区
复杂多分支工作流	不一定	一旦状态多、路径多，框架价值显著上升
长时间任务恢复执行	通常不够	需要 checkpoint / durable execution
人工审批插入流程	通常不够	简单确认可以，严肃审批流仍偏框架/平台
企业级审计与可观测	通常不够	需要更明确的 runtime 与治理能力

3.4 底层框架现在真正解决的是什么

不是：

“让模型多调几个工具”
“把 prompt 拆成几个模块”
“支持子 Agent”

而是：

任务失败后从哪里恢复
中断后如何继续执行
多步骤状态怎么持久化
人工审批如何插入并可追踪
复杂控制流如何显式编码
不同节点失败时如何区分重试 / 回滚 / 终止
如何做 telemetry、审计、会话治理、多租户隔离

这类问题，本质上都不是“模型能力”问题，而是“系统工程”问题。

📡 扩展
LangGraph 官方把 durable execution 单独拿出来解释，强调每个执行步骤的状态都可以保存到持久化存储中，并在中断后恢复；Microsoft Agent Framework 则把 workflow、state management、type safety、filters、telemetry 放在框架核心位置。它们瞄准的是运行时可靠性，而不是仅仅把 LLM 调起来。⁹ ⁵

3.5 一个常见误区：把“Plan”误认为“Workflow”

这是一个特别值得单独记住的点。

Plan 的本质

Plan 更像是：

让模型先想清楚
把任务拆成步骤
降低盲目执行概率

Workflow / Graph 的本质

Workflow / Graph 更像是：

让系统按可控逻辑运行
显式定义节点、边、状态与分支
支持暂停、恢复、审批、重放、观察

二者不是同义词。

flowchart TD
    A([用户任务]) --> B[Plan: 先分析任务]
    B --> C[执行步骤 1]
    C --> D[执行步骤 2]
    D --> E([完成])

    F([系统级工作流]) --> G{状态与条件判断}
    G -- 通过 --> H[调用工具 / 子 Agent]
    G -- 待审批 --> I[人工介入]
    G -- 失败可恢复 --> J[Checkpoint / Resume]
    H --> K{结果检查}
    K -- 成功 --> L([继续下一节点])
    K -- 失败 --> M[重试 / 回滚 / 分支处理]

    style A fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style B fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style F fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
    style G fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
    style K fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
    style J fill:#fce4ec,stroke:#d81b60,stroke-width:2px
    style I fill:#fce4ec,stroke:#d81b60,stroke-width:2px
    style L fill:#e8f5e9,stroke:#43a047,stroke-width:2px

记忆句

Plan 解决“怎么想”，Workflow 解决“怎么跑”。

3.6 为什么说框架的意义“没有变小，而是变窄且更硬核”

因为框架今天留下来的适用区，不再是“人人都需要”，而是：

真正需要长期运行
真正需要复杂状态控制
真正需要审计、恢复、治理
真正需要跨系统业务流程

这部分场景的量可能比“写代码提效”小，但复杂度更高、替代难度更大。

也就是说，框架不是从“重要”变成“不重要”，而是从：

通用提效工具

变成了：

复杂 Agent 系统基础设施

3.7 一个工程上更实用的判断流

flowchart TD
    A([准备做一个 AI Agent 能力]) --> B{主要目标是什么?}
    B -- 个人提效 / 代码库自动化 --> C[优先用 OpenCode / Claude Code]
    B -- 团队快速交付 AI 应用 --> D[优先看 Dify 这类平台]
    B -- 需要长期运行且可恢复 --> E[优先考虑 Agent 框架]

    C --> F{是否已出现复杂边界?}
    F -- 否 --> G([继续在产品层迭代])
    F -- 是 --> H[下沉到框架层]

    E --> I[LangGraph / Google ADK / Microsoft Agent Framework]
    D --> J[Workflow + RAG + Integration + Monitoring]

    H --> H1[Checkpoint]
    H --> H2[State]
    H --> H3[审批流]
    H --> H4[可观测]

    style C fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style D fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
    style E fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
    style H fill:#fce4ec,stroke:#d81b60,stroke-width:2px
    style G fill:#e8f5e9,stroke:#43a047,stroke-width:2px

建议的执行原则

默认先从产品层起步：更快、更便宜、反馈更直接。
在边界处再下沉到框架层：不要过早工程化。
把产品层与框架层看成连续体，而不是二选一。
真正的分界线不是“能不能调工具”，而是“是否需要系统级可控运行”。

4. 实践案例

案例一：个人开发者做仓库自动化

场景

你希望 AI 帮你：

理解 monorepo 结构
根据团队约定生成代码
读文档、查 API、跑测试
用 MCP 接内部工具
用 Skills 固化团队工作流

合适方案

优先用：

OpenCode / Claude Code
配合 Skills + MCP + repo rules + context 管理

原因

因为这个场景的核心是：

在已有代码仓上下文内工作
重视交付效率
对持久化工作流、复杂状态机、审批流要求不高

此时框架层通常不是第一优先级。

案例二：企业内部审批 + 数据处理 Agent

场景

你要做一个系统：

读取工单
调多个内部系统
根据规则决定是否进入人工审批
审批通过后再执行写操作
失败后能恢复到中间状态
每一步都可追踪与审计

合适方案

优先用：

LangGraph / Google ADK / Microsoft Agent Framework
视情况叠加平台层

原因

因为这里的核心不是“模型能不能完成任务”，而是：

状态怎么管
中断怎么恢复
审批怎么插入
审计怎么做
重放与治理怎么做

这已经是典型的“框架层问题”。

案例三：团队快速上线一个可视化 AI 应用

场景

你要给业务团队上线一个：

带 RAG
带工具调用
带工作流
带运营监控
能快速迭代的 AI 应用

合适方案

优先用：

Dify 这类平台

原因

因为此时重点是：

快速交付
团队使用
可视化管理
部署与监控一体化

平台层会比纯框架层更高效。

5. 核心结论

5.1 最终判断

底层 Agent 框架在最近几个月并没有失去意义；它们只是失去了“所有人默认都要先碰它”的位置。

更准确地说：

个人 / 小团队 / coding automation：产品层已经覆盖了大量需求
复杂系统 / 长生命周期 / 企业治理：框架层仍然是刚需

5.2 一句最值得记住的话

Plan、Skills、MCP 解决的是“让 Agent 更会做事”；框架解决的是“让系统更可控地运行”。

5.3 实用选型原则

优先选产品层（OpenCode / Claude Code）

当你满足以下多数条件时：

主要在代码仓内工作
主要诉求是提效
任务生命周期较短
不要求复杂恢复与审批
更重视快速反馈而非完整系统治理

优先选框架层（LangGraph / ADK / Microsoft Agent Framework）

当你满足以下多数条件时：

需要长时间运行
需要 checkpoint / resume
需要明确状态机或 graph
需要人工审批插点
需要审计、可观测、会话治理
需要跨多个系统稳定编排

优先选平台层（Dify）

当你满足以下多数条件时：

需要快速上线 AI 应用
需要 workflow + RAG + integration 一体化
需要给团队或业务方使用
需要低门槛运维和可视化配置

6. 可继续长大的问题

Plan 与 Workflow 的边界
MCP 是否正在吃掉一部分 Agent 框架价值
Coding Agent 与通用 Business Agent 的 runtime 差异
Context Engineering 与 State Management 的区别
为什么企业级 Agent 最终仍会回到 workflow / graph / session 模型

7. 参考资料

OpenCode Docs, “Agents”. https://opencode.ai/docs/agents/ ↩ ↩²
OpenCode Docs, “Agent Skills”. https://opencode.ai/docs/skills/ ↩ ↩²
LangGraph Docs, “Overview”. https://docs.langchain.com/oss/python/langgraph/overview ↩
Google Cloud / ADK Docs, “Overview of Agent Development Kit”. https://docs.cloud.google.com/agent-builder/agent-development-kit/overview ↩
Microsoft Docs, “Microsoft Agent Framework Overview”. https://learn.microsoft.com/en-us/agent-framework/overview/ ↩ ↩²
Dify Official Site. https://dify.ai/ ↩
Dify GitHub Repository. https://github.com/langgenius/dify ↩
OpenCode Docs, “Models”. https://opencode.ai/docs/models/ ↩
LangGraph Docs, “Durable execution”. https://docs.langchain.com/oss/python/langgraph/durable-execution ↩

2026：当 OpenCode / Claude Code 已经很好用时，底层 Agent 框架还有多大意义？

Table of contents

1. 背景与问题

2. 核心概念

2.1 什么是“产品层 Agent”

2.2 什么是“底层 Agent 框架”

2.3 什么是“平台层 Agent”

2.4 为什么 Skills / MCP / Plan 会让人觉得“框架不重要了”

Skills

MCP

Plan

Context 压缩 / 管理

3. 主体内容

3.1 一个更准确的分层认知

解读

3.2 最近几个月发生了什么变化

过去的默认路径

现在的默认路径

3.3 哪些需求已经被产品层覆盖得很好

3.4 底层框架现在真正解决的是什么

不是：

而是：

3.5 一个常见误区：把“Plan”误认为“Workflow”

Plan 的本质

Workflow / Graph 的本质

记忆句

3.6 为什么说框架的意义“没有变小，而是变窄且更硬核”

3.7 一个工程上更实用的判断流

建议的执行原则

4. 实践案例

案例一：个人开发者做仓库自动化

场景

合适方案

原因

案例二：企业内部审批 + 数据处理 Agent

场景

合适方案

原因

案例三：团队快速上线一个可视化 AI 应用

场景

合适方案

原因

5. 核心结论

5.1 最终判断

5.2 一句最值得记住的话

5.3 实用选型原则

优先选产品层（OpenCode / Claude Code）

优先选框架层（LangGraph / ADK / Microsoft Agent Framework）

优先选平台层（Dify）

6. 可继续长大的问题

7. 参考资料

Footnotes