《AI Agent原理与实战》2026版 第15课 Agent 框架全景与选型

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

本文收录于专栏 《AI Agent原理与实战》2026版 —— 专栏系统覆盖 AI Agent 的记忆、工具、插件与实战，点击订阅可跟踪后续更新。

本课定位：机制层（7-14 课）完工，进入工程选型。本课是阶段 3 的地图课：工具栈四类（开发框架/harness/低代码/企业平台）、选型五维度、跨类目总横评（Claude Code/Codex/OpenCode/DSH/Hermes/WorkBuddy…）与场景决策表。带着这张地图进后面五课，不会再迷路。

阶段 3｜框架与协议 ｜ 来源：【微·2 + 补充】

关键字： Agent框架全景、框架选型、开发框架、Agent harness、低代码平台、企业IM平台、工具栈地图、选型决策

本节目录

• 15.1 框架解决什么、不解决什么
• 15.2 类目地图四分：框架、harness、低代码、企业平台
• 15.3 选型维度
• 15.4 常见 Agent 产品总横评与场景选型（跨类目）
• 15.5 案例前置：同一需求在四类技术栈下的实现路径
• 15.6 案例：三个判定练习（选型决策演练）

概念讲解

15.1 框架解决什么、不解决什么

回顾第 6 课（参见第 6 课《动手：从零写一个最小 Agent Loop》）：一个 Agent 的核心不过是一个 while 循环——模型决策、执行工具、结果回传、判断终止。100 行 Python 就能写出来。那么框架的价值在哪里？

框架真正解决的问题：

框架不解决的问题（防框架崇拜）：

• 不提升模型能力。框架是调度层，推理仍然来自模型。工具选择错误、规划混乱的根因多在模型，换框架救不了（本课案例会实证这一点）。
• 不替代业务判断。“什么任务该用 Agent”（参见第 4 课）、工具怎么设计（参见第 8 课）仍是人的决策。
• 不自动解决安全。权限分级、沙箱、人工确认闸门（参见第 25 课）框架只给机制，策略要自己定。

一个实用的判定：如果你的 Agent 是单工具或少工具、流程可枚举、无持久化需求，裸 API 循环（第 6 课）可能比框架更简单可靠。框架的收益随工具数量、编排复杂度、生产化要求增长。

15.2 类目地图四分：框架、harness、低代码、企业平台

微软课程思想（源自微软原课第 2 课《Explore AI Agent Frameworks》）：微软把"为什么需要 Agent 框架"回答为三层递进——AI 框架做个性化/自动化/体验增强，而 Agent 框架在此之上做三件事：多 Agent 协作协调（Collaboration & Coordination）、多步任务的自动化管理（Task Automation & Management）、情境理解与适应（Contextual Understanding & Adaptation）；并主张用"模块化组件 + 协作工具 + 实时反馈学习"三件套快速原型迭代。本课的类目地图与选型五维度正是对这个思想的工程化展开——先问框架解决什么（微软三能力），再问控制粒度归属（代码/低代码/企业平台）。

Agent 工具栈不是两大阵营，而是四类（2026-10 口径）：

harness 与框架的本质区别：harness（如 DSH、Claude Code）是"能干活的 Agent 产品"——你给它 API key 和一个工作目录，它自己就能读文件、跑命令、管会话；框架（如 LangGraph）是"造 Agent 的库"——你用它的原语组装自己的循环。用户视角完全不同：harness 是使用者工具（配置即用），框架是开发者工具（写代码）。DeepSeek 官方对 DSH 的定位表述即"Agent = 模型 + harness：模型只输出文本，harness 给它工作区、工具、权限、会话记忆和持续推进的循环"。

企业 IM 平台（④）是 2026 年国内增量最大的类目：Agent 不再是独立网页，而是钉在企业微信/钉钉/飞书会话里，非技术同事直接对话调用——腾讯 WorkBuddy 原生支持 MCP 接入（第 18、20 课展开）。

低代码（③）与企业平台（④）的分界：③是你自己搭应用给用户用，④是平台方搭好 Agent 你往里接工具/知识。

15.3 选型维度

五个维度（按权重排序，2026-10 检索口径）：

当日实查数据（GitHub API，2026-10）。来头一栏补全球欢迎度语境——star 数是热度不是质量，但"谁在用、被谁维护"是选型的真实信号：

注意版本口径：star 数是热度指标不是质量指标；低代码平台 star 普遍更高（n8n 20 万+）因为用户基数大，不代表它比代码框架“更好”。另外 Microsoft Agent Framework 的 star 数（1.4 万）远低于前身 AutoGen（61.2k，已转维护）和 Semantic Kernel（28.6k），因为仓库是 2025 年新建的，历史积累少。

15.4 常见 Agent 产品总横评与场景选型（跨类目）

上面的类目地图展开成一张总横评表——读者最常问的"DSH、Claude Code、WorkBuddy、Hermes 这些到底选哪个"，答案取决于你落在哪一行：

① 开发框架（造 Agent 的库，第 16 课实战）

② 编码向 harness（用 Agent 写代码）

③ 个人助理向 harness

④ 低代码平台（第 20 课）：Dify（开源自托管/RAG 强）/ Coze（字节，上手最快）/ n8n（自动化编排之王）

⑤ 企业 IM 平台（第 20 课 20.5 节）：腾讯 WorkBuddy（原生 MCP）/ 钉钉 / 飞书（Coze 同源）

场景 → 选型决策表（先回答"你要用还是要造"）：

时效提醒：harness 市场 2026 年变动剧烈（收购、免费层调整、模型合作断裂时有发生——Cursor 收购案、Gemini CLI 免费层结束都发生在数月内），本表结论按 2026-10-01 检索口径，选型前务必核当日官方公告；跨类目的稳定判据仍是"用 vs 造、个人 vs 组织、云端 vs 自托管"三问。

15.5 案例前置：同一需求在四类技术栈下的实现路径

需求：“查询北京天气，如果气温低于 20°C 推荐穿搭”——一个两步任务（查工具 → 条件判断 → 生成建议）。

四条路径：

路径 B、C、D 的完整实现分别是第 16 课（代码框架实战 + DSH harness 节）和第 20 课（低代码 + 企业平台）的案例实战内容，本课先建立“同一需求、不同栈、不同成本”的心智地图。

案例实战

15.6 案例：三个判定练习（选型决策演练）

目标：给定 3 个真实感场景（示意），练习用 15.3 的五维度做选型，并给出理由。

场景 1：个人开发者，想做一个“每天早 8 点自动汇总 GitHub 通知并邮件发送”的脚本。

• 判定：不需要 Agent 框架。定时任务 + 一次 LLM 调用（甚至不用工具循环），cron + 50 行脚本即可。若想省事可直接用 n8n（有现成 GitHub/邮件节点）。
• 关键理由：流程固定、无动态决策——这正是第 4 课“何时不该用 Agent”的典型。

场景 2：创业公司，做客服 Agent，需接入订单/物流/退款 3 个内部 API，要求会话可恢复、支持人工转接。

• 判定：代码框架。LangGraph（持久化 + 中断恢复是原生能力）或 OpenAI Agents SDK（handoff 原语天然适合转接）。不适合低代码：内部 API 要自定义工具封装，平台拖拽反而绕远。
• 关键理由：生产化要求（持久化/恢复）+ 自定义工具多。

场景 3：市场团队（无工程师），想搭一个“上传竞品资料 → 生成分析报告”的内部工具，数据不能出域。

• 判定：自托管低代码平台。Dify（开源自托管 + RAG 内置）是首选；Coze 是云端封闭平台不满足数据不出域；n8n 偏自动化编排，RAG 能力弱。
• 关键理由：使用者是非工程师 + 私有化部署硬约束。

预期输出：三个场景各自的技术栈判定 + 一句话理由。练习的重点不是“标准答案”，而是把五维度（控制粒度/生产成熟度/生态/学习曲线/社区）走一遍——实际选型中权重最大的是控制粒度和团队构成（有没有工程师维护）。

小结

• 框架解决工具接入/持久化/可观测/编排/失败恢复五类工程问题，不解决模型能力和业务判断——防框架崇拜。
• 工具栈四类：开发框架（造 Agent 的库）/ harness（能干活的 Agent 产品，DSH、Claude Code、Hermes）/ 低代码平台 / 企业 IM 平台（WorkBuddy、钉钉、飞书）——harness 与框架的区别是"用"与"造"。
• 总横评+场景决策（15.4）：选型三问=“用 vs 造、个人 vs 组织、云端 vs 自托管”；harness 市场月度级变动，结论须核当日公告。
• 选型五维度：控制粒度 > 生产成熟度 > 生态 > 学习曲线 > 社区活跃度；star 数是热度不是质量。
• 2026-10 实查：n8n 206k / Dify 158k / LlamaIndex 52k / LangGraph 43k / smolagents 30k stars；LangGraph 1.2.x 与 MAF 1.x 是当前生产成熟度标杆。
• 同一需求在裸 API / 开发框架 / 低代码 / harness 四条路径下的成本结构完全不同——下一课用真实代码对比前两条并附 DSH 对照。

参见：第 4 课《何时需要 Agent：决策框架》、第 6 课《动手：从零写一个最小 Agent Loop》、第 16 课《主流代码框架实战》、第 20 课《低代码 Agent 平台》。

扩展阅读

🌐 网络提示：anthropic.com 需代理（核心结论已摘进本课正文）；huggingface.co 走镜像：export HF_ENDPOINT=https://hf-mirror.com；框架文档站（GitHub Pages/Cloudflare）可达性波动，打不开时稍后重试。详见总纲附录《国内网络访问与国产适配指南》。

• 微软原课第 2 课（框架总览）：https://microsoft.github.io/ai-agents-for-beginners/（仓库主索引，2026-10 可达）
• LangGraph 官方文档：https://langchain-ai.github.io/langgraph/
• smolagents 官方文档：https://huggingface.co/docs/smolagents/index
• Anthropic《Building Effective Agents》（框架无关的工程原则）：https://www.anthropic.com/research/successful-agent

我的专栏