跳到主要内容

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

3.5 MCP​

对应定位：

  • 这一章更适合放在 工具接入层
  • 它不是替代 tool calling，而是把工具、资源和提示进一步推进到协议化接入

可用官方阅读：

  • Model Context Protocol Docs
  • MCP Architecture
  • OpenAI Remote MCP

为什么这样映射：

  • MCP 最适合放在已经理解工具调用原语之后来学
  • 它帮助你把“单点工具注册”扩展成“统一能力接入”
  • 这一章的重点不是框架 API，而是 Host / Client / Server、能力发现、资源与工具边界

推荐顺序：

  1. 先读 Tool Use / Function Calling
  2. 再读 MCP 入门与实践
  3. 最后再把它映射到具体 SDK 或框架

3.6 A2A​

对应定位：

  • 这一章更适合放在 Agent 互联层
  • 它不是普通工具调用，也不是单纯的 workflow 编排

可用官方阅读：

  • A2A Protocol Specification
  • A2A Agent Skills & Agent Card

为什么这样映射：

  • A2A 适合讨论独立 Agent 系统之间的互操作
  • 它的核心对象不是函数，而是 task、artifact、agent card
  • 这一章更适合和 Workflow vs Agent、Planning Patterns、多 Agent 设计一起看

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 演进史、兼容旧项目、阅读经典模式”位置

4.6 Prompt Injection / Agent 安全​

对应定位：

  • 这章应以 框架无关 的风险模型为主
  • 更适合用官方安全资料和协议安全资料建立底层判断

可用框架 / 官方阅读：

  • OWASP LLM Prompt Injection Prevention Cheat Sheet
  • OWASP Prompt Injection
  • OWASP MCP Top 10
  • OpenAI Computer use

为什么这样映射：

  • 这章主要讲输入、上下文、工具、执行和输出几层风险，不该先被某个框架 API 吞掉
  • 一旦进入 MCP、Browser Agent、Computer Use 或高权限工具，安全边界会明显扩大
  • OWASP MCP Top 10 还提供了协议层常见问题，例如 token 暴露、scope creep 和 server 信任边界

推荐顺序：

  1. 先看 OWASP Prompt Injection
  2. 再看 OWASP LLM Prompt Injection Prevention Cheat Sheet
  3. 涉及 MCP 时补 OWASP MCP Top 10
  4. 涉及图形界面执行时补 OpenAI Computer use

4.7 Memory / RAG Data Governance​

对应定位：

  • 这一章原则上保持 framework-agnostic
  • 适合和 RAG、Memory and State、LlamaIndex、LangGraph 一起看

可用框架 / 官方阅读：

  • LlamaIndex Workflows
  • Google ADK
  • Microsoft Agent Framework 的 session / context providers

为什么这样映射：

  • 这章真正处理的是来源、时效、可信度、清洗、过滤、冲突和更新，而不是“换哪个向量库”
  • LlamaIndex 更适合帮助理解 research / query workflow 下的数据链路
  • Google ADK 和 Microsoft Agent Framework 则更适合帮助理解长期状态、上下文和会话治理

4.8 Latency / Cost / Reliability​

对应定位：

  • 这一章更接近运行治理层
  • 最适合和 tracing、evals、platform observability 一起看

可用框架 / 官方阅读：

  • LangSmith
  • Microsoft Foundry Observability
  • Google ADK 的 logging / metrics / evaluation

为什么这样映射：

  • 这章的核心不是某个 SDK，而是运行指标和治理策略
  • LangSmith 更适合 LangChain / LangGraph 生态
  • Microsoft Foundry 更适合平台化运行与监控视角
  • Google ADK 则覆盖 logging、metrics、traces 和 evaluation，适合补完整运行视图

4.9 Browser / Computer Use​

对应定位：

  • 这章最适合对应 OpenAI Computer use 与 workflow orchestration

可用框架 / 官方阅读：

  • OpenAI Computer use
  • LangGraph
  • CrewAI Flows
  • Mastra Workflows

为什么这样映射：

  • Browser / Computer Use Agent 的重点已经不是普通 tool call，而是界面感知、动作执行、恢复和确认
  • OpenAI Computer use 适合建立最直接的界面代理心智模型
  • LangGraph、CrewAI Flows、Mastra Workflows 更适合承载多步界面任务、失败恢复和人工确认

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. 参考的官方一手资料​