跳到主要内容

AI Agent 专题章节与框架映射

做 AI Agent 专题时，一个很常见的问题是：

是不是每一章都应该配一个框架来学？

答案通常是否定的。

因为很多章节讲的是：

  • 概念边界
  • 能力拆分
  • 系统结构
  • 失败模式
  • 工程判断

这些内容如果过早被某个框架“包住”，反而更容易把问题理解窄了。

所以这篇文档不做“框架排行榜”，而是只回答一件事：

当前 AI Agent 专题里的主要章节，分别更适合借助哪些框架 / SDK / 官方阅读来学习与落地？

我会尽量坚持一个原则：

  • 先看能力边界，再看框架
  • 先看官方原语，再看高层抽象
  • 先做最小闭环，再决定是否需要重框架

1. 先看一个最重要的结论​

不是每一章都需要框架。

更准确地说，AI Agent 专题里的章节，大致可以分成两类：

1.1 主要在教“原理和判断”的章节​

例如：

  • Prompt Engineering
  • Context Engineering
  • Workflow vs Agent
  • Harness Engineering
  • Agent Observability and Debugging 里的很多诊断思路

这类章节的重点，不是“用哪个 SDK 调起来”，而是：

  • 你是否知道问题边界在哪里
  • 你是否能分清该用普通 workflow 还是 agent
  • 你是否知道系统失败时该先查哪一层
  • 你是否能把评估、日志、回归和运行底座拆开理解

这类内容应该尽量保持 framework-agnostic。

1.2 主要在教“如何把系统跑起来”的章节​

例如：

  • Tool Use / Function Calling
  • 最小 Agent
  • Tool-Using Agent
  • Research Agent
  • RAG Agent
  • 多步编排 / 状态管理 / 多 Agent

这类章节就很适合映射到具体框架，因为它们已经进入：

  • API 原语
  • 工具注册
  • 状态传递
  • graph / flow 编排
  • tracing / eval 接入

也就是说：

不是先给每一章找框架，而是先判断这章到底在讲“能力本身”，还是已经进入“工程承载层”。

2. 推荐的整体学习顺序​

如果你是按章节一路往下学，我更推荐下面这个顺序：

  1. 先学 OpenAI 官方原语
  2. 再学 LangChain / LangGraph 这种偏通用编排层
  3. 再按需求接触 Microsoft Agent Framework、CrewAI 这类更偏完整工程承载的平台
  4. 把 AutoGen 放在“历史脉络 + 现有存量项目理解”位置，而不是新项目默认首选

原因很简单：

  • OpenAI 官方文档最适合理解工具调用、结构化输出、会话状态、Agent SDK 这些底层能力
  • LangChain / LangGraph 最适合理解“从单次 tool call 走向状态化编排”的过渡
  • Microsoft Agent Framework 更像把 AutoGen 与 Semantic Kernel 路线统一后的企业级工程底座
  • CrewAI 更适合把“agent / crew / flow / tracing / memory / knowledge”快速组织成一套完整运行系统
  • AutoGen 官方现在已经明确说明进入 maintenance mode，并建议新用户优先使用 Microsoft Agent Framework

所以全文默认采用下面这条推荐逻辑：

先能力 -> 再编排 -> 再工程平台 -> 最后再看历史框架脉络。

3. 基础能力章节​

这一组章节的重点，是先把模型、上下文、检索和工具这几层能力拆清楚。

3.1 Prompt Engineering​

对应定位：

  • 这一章应以 框架无关 为主
  • 不建议一开始绑定 LangChain、CrewAI 或其他 Agent 框架

可用官方阅读：

  • OpenAI Prompt engineering
  • OpenAI Structured Outputs

为什么这样映射：

  • Prompt Engineering 的核心是指令设计、示例设计、输出约束，而不是 agent graph
  • OpenAI 官方文档已经直接覆盖了提示策略、结构化输出、模型快照固定和配套 eval 的基本做法
  • 如果这一章一上来就进入某个框架的 prompt 模板，学习者很容易只记住框架写法，而没真正理解 prompt 设计本身

推荐顺序：

  1. OpenAI Prompt engineering
  2. OpenAI Structured Outputs
  3. 再回到你自己的最小代码骨架里手写 prompt

更适合在这一章避免的事：

  • 过早学“某框架的 prompt DSL”
  • 把 prompt 问题误当成 agent 架构问题

3.2 Context Engineering​

对应定位：

  • 这一章也应以 框架无关 为主
  • 框架只适合作为“承载上下文装配”的工具，而不是学习主体

可用官方阅读：

  • OpenAI Conversation state
  • OpenAI Structured Outputs
  • Microsoft Agent Framework 的 agent session / context providers 相关定位

为什么这样映射：

  • Context Engineering 本质上是在解决“调用模型前，到底给它看什么”
  • OpenAI 官方会帮助你理解：模型调用本身是无状态的，多轮状态需要你显式传递或管理
  • Microsoft Agent Framework 官方则更适合帮助你看到：当系统进入工程阶段后，session、context providers 这些抽象怎样承载状态和上下文

推荐顺序：

  1. 先用 OpenAI 理解会话状态是怎么被手动构造出来的
  2. 再看 Microsoft Agent Framework 如何把状态管理收敛成统一抽象
  3. 最后再在具体项目里决定要不要交给 LangGraph 或 CrewAI Flow 承载

更适合在这一章避免的事：

  • 把 memory 神化成万能方案
  • 还没分清“工作记忆 / 历史摘要 / 检索知识”就直接接入重框架

3.3 RAG​

对应定位：

  • RAG 应以 检索能力本身 为主，框架为辅
  • 这一章适合先学检索原语，再学 orchestration

可用框架 / 官方阅读：

  • OpenAI Retrieval
  • OpenAI File search
  • CrewAI Knowledge
  • LangChain 的 retrieval / agent 相关官方文档

为什么这样映射：

  • OpenAI 官方已经把 vector store、语义检索、file_search 这些原语讲得比较直接，适合先建立“检索不是魔法，而是一套可控输入能力”的理解
  • 如果你想快速得到“带知识访问能力的 agent”，OpenAI File search 是最轻量的托管起点之一
  • CrewAI Knowledge 更适合在你已经接受“知识源是系统一部分，而不是单次外挂”之后再引入
  • LangChain 更适合当你需要把 retrieval 和 agent loop 组合到一起，而不是只做单次问答

推荐顺序：

  1. OpenAI Retrieval
  2. OpenAI File search
  3. LangChain 的检索与 agent 结合能力
  4. CrewAI Knowledge

这一章最该坚持的原则：

  • 先理解 chunk / search / rerank / grounding
  • 再决定是否需要框架帮你接管知识访问

3.4 Tool Use / Function Calling​

对应定位：

  • 这是第一批非常适合明确映射框架的章节
  • 但首选仍然应该是 OpenAI 官方原语，而不是先上重型 agent framework

可用框架 / 官方阅读：

  • OpenAI Function calling
  • OpenAI Tools / Remote MCP
  • OpenAI Agents SDK
  • LangChain agents
  • Microsoft Agent Framework

为什么这样映射：

  • 工具调用本质上是 agent 工程最底层、最关键的原语之一
  • OpenAI 官方已经把工具 schema、调用生命周期、多轮 tool call 流程讲得很清楚
  • OpenAI Agents SDK 适合在你已经理解 tool call 原语后，再进一步接入 handoff、tracing、guardrails 这类 agent 运行能力
  • LangChain agents 更适合你想快速搭一个“会调工具的单 agent”
  • Microsoft Agent Framework 则更适合你已经明确要把工具调用放进更长期、可扩展、可插 middleware 的工程体系里

推荐顺序：

  1. OpenAI Function calling
  2. OpenAI Agents SDK
  3. LangChain agents
  4. Microsoft Agent Framework

不建议的顺序：

  • 还没理解 tool schema，就直接学多 agent
  • 还没搞清 tool result 回注，就直接引入复杂 crew / graph

4. Agent 工程章节​

这一组章节开始进入“怎么让系统多步跑起来、怎样保持状态、什么时候需要 workflow、什么时候需要 agent”。

4.1 Workflow vs Agent​

对应定位：

  • 这章应保持 框架无关，但非常适合配官方定位来帮助建立判断标准

可用框架 / 官方阅读：

  • Microsoft Agent Framework Overview
  • LangGraph overview
  • CrewAI Flows

为什么这样映射：

  • Microsoft Agent Framework 官方给出了一个非常实用的判断：如果任务可以直接写成函数，就优先写函数，而不是默认用 agent
  • 它还明确区分了 Agents 和 Workflows：开放式、对话式、需要自主工具使用时更适合 agent；步骤明确、执行顺序要强控制时更适合 workflow
  • LangGraph 官方强调自己是面向长时、状态化 agent orchestration 的低层框架，这正好能帮助读者理解“workflow 与 agent 的边界，不只是多步与否，而是是否把下一步决策交给模型”
  • CrewAI Flows 则适合补足“事件驱动工作流怎样承载真实自动化流程”这部分实践感

推荐顺序：

  1. 先读 Microsoft Agent Framework Overview 里的 agents vs workflows
  2. 再读 LangGraph overview
  3. 再看 CrewAI Flows

这一章要学到的不是框架 API，而是：

  • 什么任务真的值得 agent 化
  • 什么任务继续保持 workflow 反而更稳

4.2 最小 Agent​

对应定位：

  • 这一章最适合先手写，再借助轻量 SDK
  • 不建议一开始就直接上多 agent 平台

可用框架 / 官方阅读：

  • OpenAI Agents SDK
  • LangChain agents
  • Microsoft Agent Framework

为什么这样映射：

  • OpenAI 官方把 agent 定位成：模型可以使用上下文和工具，可以 handoff，可以 tracing 的应用运行时，这很适合做“最小 agent”第一跳
  • LangChain agents 官方明确说：如果你想快速构建 agent 和 autonomous applications，可以先从它的高层 agent abstraction 开始；同时它又建立在 LangGraph 之上，方便后续下探
  • Microsoft Agent Framework 则更适合作为“最小 agent 进入企业工程形态”的下一步，而不是起手第一步

推荐顺序：

  1. 手写最小 loop
  2. OpenAI Agents SDK
  3. LangChain agents
  4. Microsoft Agent Framework

这章不建议起手就用：

  • CrewAI 的多 agent 组织能力
  • AutoGen 的历史多 agent 模式

因为最小 agent 阶段最重要的是：

  • 看清 loop
  • 看清 state
  • 看清 stop condition

4.3 Tool-Using Agent​

对应定位：

  • 这是从“最小 agent”迈向“真实可做事 agent”的关键章节
  • 适合开始引入 framework，但仍然应该优先透明度高的选择

可用框架 / 官方阅读：

  • OpenAI Agents SDK
  • LangChain agents
  • Microsoft Agent Framework
  • CrewAI Agents / Tasks

为什么这样映射：

  • OpenAI Agents SDK 把 tools、handoffs、streaming、tracing 放在同一套 agent 运行模型里，非常适合作为单 agent 工具编排的第一站
  • LangChain agents 对“给模型一组工具，让它自己选择何时调用”这类模式非常直接
  • Microsoft Agent Framework 更适合当你要引入 middleware、session、MCP clients、workflow coordination
  • CrewAI 适合在你已经不满足于“一个 agent + 一组工具”，而开始想把工具任务组织成角色协作时再进入

推荐顺序：

  1. OpenAI Agents SDK
  2. LangChain agents
  3. Microsoft Agent Framework
  4. CrewAI

4.4 Research Agent / RAG Agent​

对应定位：

  • 这类章节已经进入“持续补资料、反复判断、累积证据”的状态化 agent
  • 这里最适合引入 LangGraph，其次再看平台型方案

可用框架 / 官方阅读：

  • LangGraph overview
  • LangGraph durable execution
  • OpenAI Agents SDK
  • CrewAI Flows + Knowledge + Memory
  • Microsoft Agent Framework

为什么这样映射：

  • Research Agent 和 RAG Agent 的关键，不只是会调工具，而是会围绕目标持续迭代，并在中途保存状态、等待人工介入、从失败处恢复
  • LangGraph 官方对自己的定位正是：面向 long-running, stateful agents 的低层 orchestration framework，并强调 durable execution、human-in-the-loop、memory 等能力
  • OpenAI Agents SDK 可以胜任较轻量的 research loop，但当任务变成长时、可恢复、可插入人工审查的执行流时，LangGraph 的优势会更明显
  • CrewAI 更适合当 research 不再只是单个 agent 的状态循环，而是要变成 researcher / analyst / reviewer 这种 crew 协作
  • Microsoft Agent Framework 则更适合把这类长时任务纳入更稳的 enterprise workflow / checkpointing 体系

推荐顺序：

  1. LangGraph overview
  2. LangGraph durable execution
  3. OpenAI Agents SDK
  4. Microsoft Agent Framework
  5. CrewAI

4.5 Multi-Agent / 角色协作​

对应定位：

  • 这不是 AI Agent 专题最应该最先学的部分
  • 只有当前面单 agent、tool use、state、stopping 已经稳定，才建议进入

可用框架 / 官方阅读：

  • CrewAI
  • Microsoft Agent Framework
  • OpenAI Agents SDK handoffs
  • AutoGen

为什么这样映射：

  • CrewAI 的官方定位非常明确：围绕 agents / crews / flows 来构建协作式 agent 系统，并把 memory、knowledge、observability 一起纳入
  • Microsoft Agent Framework 则提供 Agents + Workflows 的统一建模，更适合那些既需要多个 agent，又需要显式图编排、checkpoint、human-in-the-loop 的系统
  • OpenAI Agents SDK handoffs 适合较轻量的“把会话或任务转交给专门 agent”场景
  • AutoGen 在官方当前定位里更应该被理解为：多 agent 研究与历史模式的重要来源，但新项目默认不再是首选

推荐顺序：

  1. OpenAI Agents SDK handoffs 先理解“轻量 agent 转交”
  2. CrewAI 学协作角色与团队式组织
  3. Microsoft Agent Framework 学更正式的多 agent workflow 编排
  4. AutoGen 作为历史脉络和存量项目阅读

关于 AutoGen 的特别说明：

  • AutoGen 官方文档当前明确写明其处于 maintenance mode
  • 官方同时建议新用户优先从 Microsoft Agent Framework 开始
  • 所以在本专题里，AutoGen 更适合放在“理解多 agent 演进史、兼容旧项目、阅读经典模式”位置

5. 评估与观测章节​

这一组章节已经不只是“让 agent 跑起来”，而是在回答：

  • 怎么知道它变好了
  • 怎么知道它坏在哪
  • 怎么做回归
  • 怎么做线上可观测

5.1 Agent Observability and Debugging​

对应定位：

  • 这章的方法论应保持 框架无关
  • 但落地层非常适合映射到 tracing / observability 平台

可用框架 / 官方阅读：

  • OpenAI Agents SDK Tracing
  • OpenAI Trace grading / Agent evals
  • Microsoft Foundry Observability
  • Microsoft Foundry Agent tracing
  • CrewAI Tracing
  • LangSmith 相关官方定位可作为 LangGraph / LangChain 生态补充

为什么这样映射：

  • OpenAI Agents SDK 官方已经把 tracing 作为内建能力，并明确可记录 LLM 生成、tool calls、handoffs、guardrails 和自定义事件
  • OpenAI 平台还把 trace grading 和 agent evals 直接衔接起来，这很适合教“不要只看最终答案，而要看整条轨迹”
  • Microsoft Foundry 官方则把 observability 明确成 evaluation + monitoring + tracing 的组合，这很适合配合 Harness Engineering 一起理解
  • CrewAI Tracing 更适合那些已经在 crew / flow 语境里做排障的人，因为它直接暴露 agent 决策、任务时间线、工具使用和 LLM 调用

推荐顺序：

  1. 先学“该看哪些日志和轨迹”这套框架无关方法
  2. OpenAI Agents SDK Tracing
  3. Microsoft Foundry Observability
  4. CrewAI Tracing
  5. 如已使用 LangChain / LangGraph，再补 LangSmith

5.2 Harness Engineering​

对应定位：

  • 这章原则上应保持 框架无关
  • 但它天然需要映射到“谁来承载运行、记录、评分、回归”

可用框架 / 官方阅读：

  • OpenAI Evals
  • OpenAI Agent evals
  • OpenAI Trace grading
  • Microsoft Foundry Evaluate your AI agents
  • Microsoft Foundry Agent evaluators
  • LangGraph + LangSmith 组合

为什么这样映射：

  • Harness 关注的是任务集、运行配置、轨迹记录、打分、对比和回归，不等于单个 agent framework
  • OpenAI 官方已经把 evals、agent evals、trace grading 分层铺开，很适合帮助读者理解：最终输出评测和过程轨迹评测不是一回事
  • Microsoft Foundry 官方在 agent 评估里也明确把 task adherence、tool call accuracy、intent resolution、task completion 这些 agent-specific evaluator 单独列出来
  • 如果你的 agent 主体本来就建在 LangGraph 上，那么 LangSmith 一类运行与观测配套会更自然，但它仍然应该被理解成 harness 的一部分，而不是 harness 的全部

推荐顺序：

  1. 先理解 Harness != Agent Framework
  2. OpenAI Evals
  3. OpenAI Agent evals + Trace grading
  4. Microsoft Foundry agent evaluation
  5. 已在 LangGraph 生态内时，再补生态化运行与对比工具

6. 代码实践章节​

这一组章节关心的是：

  • 第一版代码到底怎么搭
  • 目录结构怎么演进
  • 什么时候该手写，什么时候该上框架

6.1 最小可运行项目结构​

对应定位：

  • 以 框架无关 为主
  • 以手写项目骨架为首选
  • 只在“你已经知道每层职责”之后，再引入框架目录约定

可用框架 / 官方阅读：

  • OpenAI Agents SDK
  • LangChain agents
  • CrewAI 项目结构
  • Microsoft Agent Framework 工程化能力

为什么这样映射：

  • 项目结构这章最怕的，就是把“像框架”误当成“工程合理”
  • 第一版目录更应该服务于：配置、tools、state、prompts、agent loop、scripts、evals 能不能清楚分层
  • 等结构已经稳定后，再看框架怎样组织项目，价值才会更大

推荐顺序：

  1. 手写最小目录
  2. 以 OpenAI Agents SDK 或 LangChain agents 包一层运行入口
  3. 需要角色协作时再看 CrewAI
  4. 需要更重的 workflow / session / middleware 时再看 Microsoft Agent Framework

6.2 代码实现示例章节​

包括：

  • Minimal Agent
  • Tool-Using Agent
  • Research Agent
  • RAG Agent

整体推荐映射如下：

  1. Minimal Agent：手写 -> OpenAI Agents SDK
  2. Tool-Using Agent：OpenAI Agents SDK -> LangChain agents
  3. Research Agent：LangGraph -> Microsoft Agent Framework / CrewAI
  4. RAG Agent：OpenAI Retrieval / File search -> LangGraph -> CrewAI Knowledge

这样安排的原因是：

  • 先看清最小闭环
  • 再引入工具决策
  • 再引入状态化长流程
  • 最后再把知识层、角色层、观测层组织成更完整系统

7. 哪些章节应保持框架无关​

这是全文最重要的收束部分。

如果你希望这个专题真正帮助读者建立长期可迁移的理解，那么下面这些章节，最好都尽量保持 framework-agnostic：

  1. Prompt Engineering
  2. Context Engineering
  3. Workflow vs Agent
  4. Harness Engineering 的概念边界
  5. Agent Observability and Debugging 里的诊断方法论
  6. 最小项目结构 里的职责拆分原则

原因不是这些章节“不需要落地”，而是：

  • 这些章节讲的是判断力
  • 判断力一旦被某个框架绑定，就很容易变成 API 记忆
  • 真正稳定的工程能力，来自你知道这层问题本来是什么，而不是只知道某个框架按钮在哪里

可以把原则记成一句话：

凡是主要在回答“为什么”和“怎么判断”的章节，优先保持框架无关；凡是主要在回答“系统怎么跑起来”的章节，再引入框架映射。

8. 一份可直接执行的章节映射清单​

如果你要把当前 AI Agent 专题快速映射成学习与实践路线，我建议直接采用下面这版：

  • Prompt / Context：以 OpenAI 官方原语为主，不绑定 Agent 框架
  • RAG：先 OpenAI Retrieval / File search，再 LangChain / LangGraph，最后按需补 CrewAI Knowledge
  • Tool Use / Function Calling：先 OpenAI Function calling，再 OpenAI Agents SDK
  • Workflow vs Agent：先看 Microsoft Agent Framework 的边界判断，再看 LangGraph 与 CrewAI Flows
  • 最小 Agent：手写优先，之后补 OpenAI Agents SDK 或 LangChain agents
  • Tool-Using Agent：OpenAI Agents SDK 优先，复杂后补 LangChain 或 Microsoft Agent Framework
  • Research Agent / RAG Agent：LangGraph 优先，长时与协作场景再考虑 CrewAI 或 Microsoft Agent Framework
  • Observability / Debugging：先学方法，再接 OpenAI Tracing、Microsoft Foundry Observability、CrewAI Tracing
  • Harness / Evals：先学概念，再接 OpenAI Evals / Agent evals / Trace grading 与 Microsoft Foundry agent evaluation
  • Multi-Agent：CrewAI、Microsoft Agent Framework 为主；AutoGen 放在历史与存量项目理解位置

9. 参考的官方一手资料​