《AI Agent 工程师知识库》

源仓库：本文档蒸馏自 GitHub 上的 WenyuChiou/awesome-agentic-ai-zh（三语 · 繁中/English/简中 · MIT 许可 · 4k+ stars），一个从「LLM 用户」到「Agent 系统构建者」的 8 阶段结构化学习路线图（240+ 精选资源、23 个动手练习）。

一句话导读：Agent 不是「更强的聊天机器人」，而是「LLM 在一个循环里感知状态→做决策→执行动作→观察结果」的系统。本知识库按「从零到生产」的依赖顺序，把这条路上真正长期有价值的核心概念、原理、易混点和实操坑蒸馏出来，砍掉了原仓库里的纯资源链接、star 数罗列和重复描述，只保留「值得学、学了不过时」的部分。

标注约定：🔴核心必学 / 🟡重要 / ⚪️了解即可。凡属我基于领域知识补充、非源仓库原文的部分，均以「【补充】」显式标注；不确定的概念宁可省略也不编造。

1. 这份知识库怎么用（学习路线总览）

Agent 工程有一条硬依赖链：后面的每一层都建立在前面之上，跳层学会「知其然不知其所以然」。这是本文档的章节顺序，也是推荐的学习顺序：

LLM/Prompt（地基）
   ↓ 靠什么让模型「动手」
Tool Use + ReAct（Agent 的最小内核）
   ↓ 手写循环太累，抽象出来
Agent 框架（LangGraph / CrewAI ...）
   ↓ 模型记不住、知识不够，要喂对上下文
RAG + Memory（上下文工程）
   ↓ 标准化「模型↔外部工具」的接口
MCP / Skills / Plugins（能力封装）
   ↓ 单个 Agent 搞不定复杂任务
多 Agent + 生产化（编排/评估/可观测）
   ↓ 让 Agent 真正操作现实世界
Computer Use / Browser Use / Sandbox（接口）

为什么值得按这个顺序学：Agent 的每个「新能力」都是为了解决前一层的一个具体缺陷（模型不会动手→给工具；循环太繁琐→给框架；知识不够/记不住→给 RAG 和记忆；接口不统一→给 MCP；单体不够强→给多 Agent）。理解「每层解决什么痛点」比记住工具名重要得多。

2. 第一层 · 地基：LLM 与 Prompt

在依赖链中的位置：一切之上的地基。Agent = LLM + 动作 + 循环，LLM 是那个「大脑」。不理解 LLM 的本质与边界，后面所有设计都是空中楼阁。

2.1 LLM 的本质 🔴核心必学

是什么：GPT / Claude / Gemini 这类模型，本质是纯文本变换函数——输入文本，输出文本。它本身不联网、不记忆对话、不会执行任何动作。

为什么这点最值得先记牢：初学者最大的误解就是把 LLM 当成一个「无所不能的助手」。实际上，联网、记忆、动手全都是外部系统给它套上的能力（这正是后面 Tool、Memory、Agent 存在的原因）。把 LLM 想成一颗「只会思考、四肢瘫痪、失忆」的大脑，整个 Agent 工程的逻辑就通了。

使用边界 / 坑：

• LLM 的输出是概率生成，会「一本正经胡说八道」（幻觉）。凡是需要事实准确的场景，必须用 RAG / 工具查证，不能靠模型「记得」。
• 不要指望模型知道训练截止日期之后的事，也不要指望它记得上一轮对话（除非你把历史塞回上下文）。

2.2 Token 与 Context Window 🔴核心必学

Token：LLM 处理的最小单位，不是字符。约定俗成的估算：中文约 1.5–2 token/字，英文约 1.3 token/词。计费和上下文长度都按 token 算——这直接决定你的成本和能塞多少内容。

Context Window（上下文窗口）：模型一次能「看到」的 token 总量。2026 年前沿模型大约在 256k–2M token 之间。

关键坑（务必记住）：上下文不是越长越好。模型对「中间部分」的信息容易视而不见（业界称 "lost in the middle"）。所以哪怕窗口有 200 万 token，也不能无脑把所有资料一股脑塞进去——该放什么、放在哪个位置，本身是一门工程（这就是后面「上下文工程」的由来）。

2.3 Prompt 工程 🔴核心必学

是什么：设计发给 LLM 的输入文本以获得更好输出。包含：

• System Prompt（系统提示）：定义角色、规则、行为边界（"你是一个……，你必须……"）。
• User Prompt（用户提示）：具体的请求。

三个必会技巧：

为什么 Structured Output 是 Agent 的前提：Agent 框架需要机器可解析的输出才能知道「模型现在想调用哪个工具、参数是什么」。大多数 LLM API 提供 response_format 之类的开关强制 JSON 输出。这是从「Prompt」跨向「Tool Use」的关键桥梁。

Prompt 工程的边界：Prompt 能调行为、给格式、给少量示例，但改不了模型的底层知识和能力。需要注入大量领域知识→用 RAG；需要模型稳定学会某种行为/格式→考虑微调（fine-tuning）。别指望靠堆 Prompt 解决一切。

3. 第二层 · Agent 的诞生：Tool Use 与 ReAct

在依赖链中的位置：这是「LLM → Agent」的质变点。给瘫痪的大脑装上手脚（工具）和一个循环（ReAct），Agent 就诞生了。这一层是整个知识库最核心的一层。

3.1 Agent 的定义 🔴核心必学

是什么：以 LLM 为核心的系统，在一个循环里「感知状态 → 做决策 → 执行动作 → 观察结果」，直到目标完成。

三要素（缺一不是 Agent）：

1. LLM 推理（大脑）
2. 动作能力（工具/手脚）
3. 持续循环（不是一问一答，而是反复迭代直到完成）

判断价值：这个定义值得逐字记住——它是区分「Agent」和「普通聊天机器人 / 单次 LLM 调用」的唯一标准。面试和架构决策时反复用得到。

3.2 Tool Use / Function Calling 🔴核心必学

是什么：让 LLM 调用预先定义好的函数（查数据库、算数、联网、读文件）的机制。

机制（务必理解流程）：

1. 你把工具的「名字 + 描述 + 参数 schema」告诉模型；
2. 模型不直接回答，而是返回一个结构化的调用请求（调哪个工具、传什么参数）；
3. 你的系统真正执行这个函数（模型自己不执行任何东西）；
4. 把执行结果喂回模型，进入下一轮。

关键认知：模型只负责「决定调什么」，真正执行的永远是你的代码。 这既是能力也是安全边界的根源（见第 9 章「致命三元组」）。

坑：

• 工具描述（description）质量决定一切。描述含糊 → 模型不会用或乱用。好的描述要有具体例子，不能只写泛泛的一句话。
• 参数 schema 字段缺失 / 类型写错 → 工具调用直接失败。这是新手最常见的 bug。

3.3 ReAct 模式 🔴核心必学

是什么：最经典的 Agent 循环模式——「Thought（思考）→ Action（行动）→ Observation（观察）」不断重复，直到任务完成。

为什么值得学：几乎所有 Agent 框架内部都实现了 ReAct 的变体。理解了 ReAct，你就理解了 LangGraph / CrewAI / AutoGen 内部到底在转什么圈。建议：先手写一遍最朴素的 ReAct 循环（用 Anthropic SDK 原生 tool_use），再去学框架——否则框架会变成黑盒。

Agent Loop（循环）的终止条件：模型主动发出「完成」信号 / 达到步数上限 / 预算耗尽。这三个终止条件必须显式设计，否则 Agent 可能无限循环烧钱。

3.4 单会话自我改进：Self-Refine vs Reflexion 🟡重要

价值判断：这两个是 Agent「自我提升」的入门套路，理解即可；生产中更常用的是外部评估（eval）+ 人工反馈，而非让 Agent 自己反复空转。

这一层学完你能做什么：一个能查天气、能算数、能总结论文的最小 Agent（约 70–150 行代码），完全跑通 ReAct 循环。

4. 第三层 · Agent 框架

在依赖链中的位置：手写 ReAct 循环、状态管理、记忆集成很快会变得繁琐。框架把这些反复出现的模式抽象出来。先手写过、再用框架，才知道框架帮你省了什么。

4.1 为什么需要框架 🟡重要

框架封装了：ReAct 循环、状态管理、记忆集成、多工具组合。核心价值是别重复造轮子，尤其在状态复杂、多 Agent 协作时。

反过来的坑：框架抽象层会掩盖底层机制。不理解 ReAct 就上框架，出了 bug 完全无从下手。框架也有学习曲线和「厂商锁定」成本——简单任务可能手写更快。

4.2 四大框架横评 🟡重要（选一个深入，别都学）

学习建议：原仓库的做法是「用 2–3 个框架实现同一个 Agent」以体会架构取舍。判断：这个练习很有价值——同一个需求在不同框架里的写法差异，能让你真正理解每个框架的设计哲学，而不是背 API。

删除说明：原仓库还罗列了大量框架的 GitHub 链接和 star 数，此处砍掉——框架选型看需求，star 数不是学习价值。

5. 第四层 · 上下文工程：RAG 与 Memory

在依赖链中的位置：LLM「知识不够 + 记不住」是两大硬伤。RAG 解决「知识不够」（把外部资料检索进上下文），Memory 解决「记不住」（跨轮/跨会话保留信息）。二者合称上下文工程——工程化地决定「每次调用 LLM 时，上下文窗口里到底装什么」。

5.1 Context Engineering（上下文工程）🔴核心必学

是什么：工程化地设计「每次 LLM 调用时，上下文窗口里放什么信息」——把 RAG 检索结果、记忆、工具 schema、对话历史，组装成最优的上下文。

为什么它是当代 Agent 工程的核心词：因为模型能力越来越强，瓶颈从「模型不够聪明」转向了「给模型的信息对不对」。Garbage in, garbage out 在 Agent 时代被放大——上下文里塞了无关信息、漏了关键信息、或把关键信息放在了「中间被忽略」的位置，Agent 就会犯蠢。

5.2 RAG（检索增强生成）🔴核心必学

是什么：两阶段架构。

【入库阶段】文档 → 切块(chunk) → 向量化(embed) → 存入向量库
【查询阶段】问题向量化 → 语义检索 → 取 top-K 相关块 → 拼进 prompt → LLM 作答

支撑 RAG 的关键概念（这些是「靠什么支撑」的答案）：

RAG 的使用边界（何时不用）：

• 知识频繁变化、要求引用溯源 → 用 RAG（在推理时注入，改数据不用重训）。
• 需要模型稳定学会某种格式/行为 → 用微调（fine-tuning）更合适。
• 知识量小、能直接塞进上下文 → 直接塞，别上 RAG 这套重架构（见第 10 章「RAG vs 长上下文」对比）。

5.3 Memory（记忆）🟡重要

两个正交的分类维度（这是理解记忆的关键框架）：

• 时间维度：短期（当前对话）vs 长期（跨会话持久）
• 内容维度：工作记忆 / 情景记忆(episodic) / 语义记忆(semantic) / 程序记忆(procedural)

两个维度可以叠加（例如「长期情景记忆」= Reflexion 用的那种）。

RAG vs Memory 的关系（易混，重点）：技术上高度相似（都靠向量检索），但目的不同——RAG 是「注入外部知识文档」，Memory 是「记住交互过程中产生的信息」（用户偏好、历史结论、教训）。实现上 Memory 常复用 RAG 的向量检索栈。

5.4 Fine-tuning（微调）⚪️了解即可

是什么：用自定义数据重训模型，把知识/行为编码进权重。与 RAG（推理时加数据）本质不同。

边界：适合固定输出格式、稳定行为；不适合快速变化的事实（改一次事实要重训一次，成本高）。对多数 Agent 场景，优先 RAG + Prompt，微调是最后手段。

6. 第五层 · Claude Code 生态：MCP / Skills / Plugins

在依赖链中的位置：前面 Tool Use 是「一个 Agent 内部」调工具。现实里工具千千万，每接一个都手写胶水代码不可持续。MCP 把「模型↔外部工具」的接口标准化；Skills/Plugins 则是能力的封装与分发单位。这一层是 Track A（CLI 高手）和 Track B（构建者）的共享枢纽。

6.1 MCP（Model Context Protocol）🔴核心必学

是什么：开放协议，让任何 LLM host 用同一套接口去连接外部 tool server。标准化了三类东西：Tools（工具）/ Resources（资源）/ Prompts（提示），通过 stdio / SSE / HTTP 传输。

为什么值得学（判断）：MCP 是 2024–2026 Agent 生态的关键基础设施，相当于「Agent 工具界的 USB 接口」。学会它 = 你写一次 MCP server，所有支持 MCP 的 host（Claude Desktop、Claude Code 等）都能用你的工具，不用为每个客户端重写。

上手坑（来自源仓库 cookbook）：

• MCP server 用 Python SDK 不到 50 行就能起一个（stdio 传输）。
• 工具的 inputSchema 字段必填校验——字段缺失或类型错，工具调用就失败。
• 工具描述必须含具体例子，不能只写通用指令。

6.2 Skills 🔴核心必学

是什么：Claude Code 的行为包。核心是一个 SKILL.md 文件，描述「什么时候用、做什么、能用哪些工具」，外加可选的参考文件。

触发机制（关键）：SKILL.md 的 frontmatter 描述（description）会自动触发 skill 加载——Claude 读到用户请求，匹配到描述就自动挂载这个 skill。

最大的坑：描述含糊 → skill 永远不触发。解法：在 description 里加 2–3 个「当用户说 X 时」的具体触发短语。

6.3 Plugins / Marketplace ⚪️了解即可

是什么：把 Skills + 斜杠命令 + hooks + MCP 配置打包成一个分发单位。Marketplace 支持 claude plugin install 让社区共享扩展。

6.4 Claude Code 其他构件 🟡重要（Track A 必学）

7. 第六层 · 多 Agent 与生产化

在依赖链中的位置：单个 Agent 有能力上限。复杂任务需要多 Agent 分工；上线则需要评估、可观测、成本控制这套「工程护栏」。这一层是从「玩具」到「产品」的分水岭。

7.1 多 Agent 编排模式 🟡重要

是什么：多个 Agent 协作完成任务。三种经典拓扑：

Handoff（交接）：一个 Agent 把任务责任转给另一个，要处理上下文传递和失败兜底——这是多 Agent 系统最容易出 bug 的地方。

判断/坑：多 Agent 不是银弹。它引入了协调开销、上下文传递损耗和调试难度。能用单 Agent + 好工具解决的，别上多 Agent。 先问「单 Agent 为什么不够」。

7.2 Harness Engineering（护栏/框架工程）🔴核心必学

是什么：工程化「模型之外的执行/控制层」——包括 Agent 循环、工具注册表、上下文管理、权限、安全、记忆、评估、可观测、重试逻辑。

为什么这是生产化的核心认知：一句话——「模型只是 Agent 的一小部分，真正决定 Agent 好不好用的是外面这层 harness」。理解这点，你才知道生产 Agent 的工程量 80% 在模型之外。

相关的两个工程视角：

• Context Engineering：管「上下文里放什么」（见第 5 章）。
• Loop Engineering：管「循环本身怎么转」——目标、工具、上下文管理、终止条件、错误处理，尤其是长周期（几百步）运行时的稳定性。

7.3 评估与可观测 🔴核心必学

为什么必学：没有 eval 的 Agent 迭代 = 蒙眼开车。你改了个 prompt，到底变好还是变坏？只有量化评估能回答。可观测则是出 bug 时唯一能「回放案发现场」的手段。这两个是生产 Agent 与玩具 Agent 的核心区别。

7.4 成本与性能优化 🟡重要

判断：这些是「知道存在、用时再查」的优化手段，不必一开始死磕。优先把功能跑对，再谈优化。

7.5 进阶概念（阅读向）⚪️了解即可

原仓库列了 PAR 循环（Plan-Act-Reflect）、Agent 工作边界、Agent-as-judge 等 12+ 进阶模式。判断：这些属于「读论文/读文档」层面的前沿话题，动手做出前 6 层再回来看，否则消化不了。

8. 第七层 · Agent 接口：Computer / Browser / Sandbox

在依赖链中的位置：前面的工具都是「有 API 的」。但现实世界大量系统没有 API。这一层让 Agent 像人一样「看屏幕、点鼠标、操作浏览器」，并安全地执行自己写的代码。也是 Track A/B 的共享枢纽。

8.1 Computer Use（计算机操作）🟡重要

是什么：Agent 通过「截图 → 视觉理解 → 计算坐标 → 模拟鼠标键盘」来操作真实桌面应用——像人一样交互，无需 API。

边界/坑：慢、脆（UI 一变就失效）、成本高（每步都要视觉模型看截图）。有 API 就别用 Computer Use，它是「实在没别的办法」时的兜底。

8.2 Browser Use（浏览器操作）🟡重要

是什么：Agent 操作网页，优先用 DOM 感知（CSS 选择器）导航，视觉作为兜底。开源参考：browser-use 框架。

判断：比 Computer Use 更实用（DOM 比像素稳）。做网页自动化、爬取交互式站点时的主流方案。

8.3 Code Sandbox（代码沙箱）🔴核心必学（安全相关）

是什么：隔离的执行环境，让 Agent 写的代码「跑起来但伤不到宿主机」。

为什么必学：只要你让 Agent 执行它自己生成的代码，就必须有沙箱——否则一个幻觉出来的 rm -rf 就能毁掉你的机器。这是安全红线，不是可选项。

支撑技术（了解即可）：

9. 安全与红线

Agent 能「动手」，安全就从「模型会不会说错话」升级成「模型会不会干坏事」。这一章的概念每个做生产 Agent 的人都必须懂。🔴核心必学

9.1 Prompt Injection（提示注入）🔴

是什么：攻击者把恶意指令藏在 Agent 会读到的内容里（网页、邮件、文档），试图覆盖原始指令。

根因：LLM 无法区分「哪些是给它的指令、哪些是数据里夹带的指令」——在模型眼里都是文本。这是架构级缺陷，没有彻底的解法，只能缓解。

9.2 Lethal Trifecta（致命三元组）🔴

是什么：三个能力同时具备就构成重大漏洞：

1. 能访问敏感数据
2. 会接触不可信内容
3. 能对外通信

为什么值得刻进脑子：这三者齐了，攻击者就能通过注入让 Agent「读你的私密数据 → 打包 → 发到外部」。防御原则：至少砍掉其中一个能力。这是设计任何有外部访问权 Agent 时的第一检查项。

9.3 Guardrails（护栏）🟡

是什么：拦截 LLM 越界行为的规则层——挡提示注入、防 PII（个人隐私信息）泄露、拦有害输出。工具：NeMo Guardrails / Guardrails AI。

10. ★ 易混概念对比表（重点）

这是本知识库最有价值的部分之一。以下概念在学习和面试中极易混淆，逐一厘清。

10.1 【核心】Skills vs MCP vs Tools 🔴

这三个是 Claude Code / Agent 生态里最容易搞混的三兄弟。一句话先定性：Tool 是「一个动作」，MCP 是「工具的传输协议/接口」，Skill 是「一套行为剧本」。 层级不同，不是同类东西。

关系串起来：一个 MCP server 对外暴露若干 Tools；一个 Skill 的剧本里会声明「本场景可以用哪些 Tools（可能来自 MCP）」。三者是协作而非竞争关系。

10.2 Agent vs Workflow 🔴

【补充】关键判断：业界（如 Anthropic 的工程博客）反复强调——能用 Workflow 解决的，别上 Agent。Agent 的动态性是双刃剑，只有当「无法预先写死步骤」时才值得付出它的不可预测性和成本代价。

10.3 RAG vs 长上下文（Long Context）🔴

判断：不是二选一。小资料直接塞更简单；大资料/要溯源用 RAG；有时两者结合（RAG 检索 + 长上下文放关键全文）。

10.4 ReAct vs Plan-and-Execute 🟡

【补充】 实务中常见混合：先 Plan 出大纲，每一步内部再用 ReAct 微调。别把它们当对立面。（小云雀那种「先思考→列计划→逐步执行并实时显示每步」，正是 Plan-and-Execute 的典型形态。）

10.5 A2A vs MCP ⚪️

11. 知识关联图（依赖/支撑/产出）

回答「一个知识点依赖什么、靠什么支撑、最终产出什么」。

核心依赖链（从下往上，下层是上层的前提）：

    最终产出 →   生产级 Agent / 多 Agent 系统 / Agent 产品
                          ▲ 靠…支撑
        ┌──────────────┬──────────────┬──────────────┐
        │  Harness      │  评估/可观测   │  安全护栏     │   ← 生产化护栏层
        │  多Agent编排   │  (eval/obs)   │ (致命三元组)  │
        └──────────────┴──────────────┴──────────────┘
                          ▲ 依赖
        ┌──────────────┬──────────────┬──────────────┐
        │ MCP/Skills    │  RAG/Memory   │ Computer/     │   ← 能力扩展层
        │ (工具标准化)   │ (上下文工程)   │ Browser/Sandbox│
        └──────────────┴──────────────┴──────────────┘
                          ▲ 依赖
        │        Agent 框架 (LangGraph/CrewAI...)         │   ← 抽象层
                          ▲ 依赖（框架内部就是它）
        │     Tool Use + ReAct 循环（Agent 最小内核）       │   ← Agent 内核
                          ▲ 依赖
        │  LLM + Prompt（Structured Output 是关键桥梁）    │   ← 地基

几条关键关联（用文字说清）：

• Tool Use 依赖 Structured Output：模型必须能输出结构化 JSON，系统才能解析「调哪个工具」。所以 Prompt 层的 Structured Output 是 Tool Use 的前提。
• RAG 支撑「知识准确」，Memory 支撑「跨轮记住」，二者都靠 Embedding + Vector DB 支撑，最终产出是「上下文工程」组装好的上下文。
• MCP 支撑「工具复用」：一次写的工具，产出是「所有 host 可用」。
• eval/可观测支撑「可迭代/可调试」：没有它们，Agent 无法安全地上线和优化。
• Sandbox 支撑「代码执行安全」：是「让 Agent 写代码并运行」这个能力的前提护栏。

12. 两条学习路线：CLI 高手 vs Agent 构建者

源仓库把学习者在完成共享地基（第 2–3 章）后分成两条路。判断：这个分叉很有价值——不是所有人都要「从零造 Agent」，很多工程师的诉求是「把现成 CLI Agent 用到极致」。

怎么选：

• 你是想「用好 Agent 工具」提升自己开发效率 → Track A，重点吃透第 6 章（Claude Code 生态）。
• 你是想「造 Agent / 做 Agent 产品」 → Track B，全章通读，重点第 3、5、7 章。
• 【补充】建议：即便走 Track A，也强烈建议手写一遍第 3 章的最小 ReAct（哪怕不做产品）——理解内核会让你把现成工具用得更明白。

13. 术语速查表

随时可查。🔴核心 / 🟡重要 / ⚪️了解。

14. 学习验收标准（测试 & 自我检验）

这一章是全书的「体检表」。前面十三章教你「是什么、怎么做」，这一章只回答一个问题：你到底学没学会？

14.0 怎么用这套验收标准

每一层都有三档，按顺序过，不要跳：

1. 概念自测题 —— 合上书，用嘴（或者对着空气）把每道题讲清楚。讲得出来才算「理解」，只能翻书找答案 = 没懂。侧重「为什么」，不是「背定义」。
2. 动手验收标准 —— 明确列出「你能独立做出什么」。做不出来，说明这层是纸面知识，回去重做那一层的项目。判据是二值的：能跑通 / 跑不通，没有「大概懂了」。
3. 易混辨析测试 —— 针对该层最容易混淆的点，判断正误 + 一句解析。这些是面试和实战里最爱翻车的地方。

过关规则：三档全过 → 进入下一层。任何一档卡住 → 回到对应层重学，别硬往下推——Agent 知识是叠罗汉，地基塌了上面全塌。

关于「参考答案」：给的是要点，不是标准答案范文。你的表述只要覆盖要点、逻辑对，就算过。

14.1 第一层 · 地基：LLM 与 Prompt

概念自测题

1. 为什么说 LLM 本质是「给定上文、预测下一个 token 的概率分布」，这个视角能解释哪些日常现象？ 要点：自回归逐 token 生成 → 解释了「幻觉」（高概率≠事实）、「越写越顺 / 也越跑偏」（后文以前文为条件）、「同一个问题换个问法结果不同」（输入即条件）、以及为什么流式输出是逐字蹦出来的。

2. Context Window 是什么？它和「模型记性」是不是一回事？ 要点：上下文窗口 = 单次请求里 input+output 能容纳的 token 上限；模型本身无状态，多轮对话是每次把完整历史重发一遍。「记性」是应用层把历史塞进窗口造出来的错觉，不是模型内部存储。超窗就得截断/压缩/检索。

3. Token 不等于「字」或「词」，这个区别在工程上会带来什么坑？ 要点：token 是子词单位；中文/代码/非英文的 token 密度和英文差异很大 → 成本估算不能按字数拍脑袋、不能用别家分词器估、上下文预算要按实测 token 算。

4. Few-shot、CoT、Structured Output 各自解决什么问题？给一个「该用哪个」的判断。 要点：Few-shot（给范例）→ 对齐输出格式/风格/边界；CoT（让它先想再答）→ 提升多步推理正确率；Structured Output（约束成 schema）→ 让输出可被程序稳定解析。分类看格式对齐用 few-shot，数学/逻辑用 CoT，要喂给下游代码用 structured output。

5. 为什么 Structured Output 是 Agent 的前提？（重点理解题） 要点：Agent = 循环里「模型决定下一步动作」。动作要被代码执行，就必须能被可靠解析成结构化指令（调哪个工具、传什么参数）。如果输出是自由散文，程序没法稳定提参数，循环就跑不起来。所以结构化输出不是锦上添花，是 Agent 能自动化的地基。

动手验收标准

• 不看教程，能用原生 SDK（不借助任何 Agent 框架）写一个脚本：给定一段非结构化文本，通过一次 API 调用强约束输出成指定 JSON schema（如提取姓名/邮箱/意图），并在代码里成功 parse 出字段、打印出来。要求 schema 是你自己定义的、字段校验能过。
• 能用 count_tokens 类接口（而非字数估算）算出一段给定文本的真实 token 数，并解释为什么不能用其他家的分词器估。

易混辨析测试

• 判断：「让模型输出 JSON」和「结构化输出（strict/schema 约束）」是一回事。 ❌ 错误。前者靠 prompt 请求，模型可能偷偷加解释、漏字段、格式跑偏；后者由解码层强制符合 schema，保证可解析。生产链路只信后者。

• 判断：CoT（思维链）和「模型的 thinking / 推理过程」是同一个东西。 ❌ 错误。CoT 是一种 prompt 技巧（让模型把推理写进可见回答里）；现代模型的「thinking」是模型内部的推理机制（可能被总结或不返回）。两者目标相近但不是一层东西——一个是你写的提示词，一个是模型的能力。

14.2 第二层 · Agent 的诞生：Tool Use 与 ReAct

概念自测题

1. 一句话说清 Agent 和「一次 LLM 调用」的本质区别。 要点：Agent = 模型在循环中自主决定下一步动作（调工具→看结果→再决定），直到任务完成；一次调用是「输入→输出」单程，没有反馈回路、没有模型主导的轨迹。

2. Function Calling / Tool Use 的完整回合是怎么转的？谁执行工具？ 要点：模型返回 tool_use（工具名+参数）→ 你的代码执行工具 → 把 tool_result 塞回对话 → 再请求模型。模型只「决定调用」，不亲自执行；结果必须带回上下文模型才知道。

3. ReAct 里的 Reason 和 Act 分别指什么？为什么要交替而不是「想完一次性做完」？ 要点：Reason=推理下一步该干嘛，Act=调工具。交替是因为每步动作的结果不可预知，必须拿到真实结果再决定下一步；一次性规划到底在环境有不确定性时会脱节。

4. 循环的「终止条件」为什么是 Agent 设计里必须显式处理的？不处理会怎样？ 要点：模型不再调工具（如 end_turn）= 正常结束；但还要防死循环——设最大轮次、处理暂停/继续信号。不设上限，一个坏工具或反复试错就能把 token 和钱烧光、卡死。

5. Self-Refine 和 Reflexion 的区别是什么？ 要点：Self-Refine = 同一次任务内「产出→自我批评→改进」的迭代；Reflexion = 跨尝试，把失败的反思写进记忆，下一次尝试带着教训重来。前者是本轮打磨，后者是「吃一堑长一智」的跨回合学习。

动手验收标准

• 不看教程，用原生 SDK 手写一个 70 行以内的 ReAct Agent：能查天气 + 做算数两个工具，循环里模型自主决定调用哪个、拿结果继续，循环有明确终止条件（end_turn + 最大轮次兜底）。要求能处理「先算数再查天气」这种多步、串行调用。
• 能手动实现一轮 tool-use 的完整往返（构造 tool_use → 执行 → 回填 tool_result → 拿到最终答案），并能说清每一步的消息该往对话里怎么追加、tool_use_id 为什么必须对上。

易混辨析测试

• 判断：ReAct 和 Plan-and-Execute 是同一种 Agent 模式。 ❌ 错误。ReAct 是「想一步、做一步、看结果再想」，边走边调整；Plan-and-Execute 是「先一次性规划出完整步骤，再逐条执行」。前者对不确定环境更鲁棒但 token 多，后者步骤清晰但计划一旦脱节要重规划。

• 判断：定义了工具（写好 schema）后，模型就会自己去执行这个工具。 ❌ 错误。模型只会返回它想调用工具的意图和参数，实际执行永远是你的代码/harness 做的。把「定义工具」当成「模型能执行」是新手最常见的误解。

14.3 第三层 · Agent 框架（LangGraph / CrewAI / AutoGen / Smolagents）

概念自测题

1. 你已经能用原生 SDK 手写 Agent 循环了，为什么还要用框架？框架到底替你省了什么？ 要点：省的是状态管理、循环编排、多 Agent 通信、持久化/断点续跑、可视化、重试。框架不是新能力，是把你手写的样板工程化。先能手写再用框架，否则框架报错你根本不知道底层出了啥。

2. LangGraph 的核心抽象是「图（状态机）」，这带来什么好处？适合什么场景？ 要点：把 Agent 流程建成节点+边+共享状态的图 → 显式控制流、可循环、可条件分支、可加人工节点、可断点续。适合流程复杂、要精确控制走向、要 human-in-the-loop 的场景。

3. CrewAI 和 AutoGen 都做多 Agent，它们的组织范式有何不同？ 要点（按理解表述即可）：CrewAI 偏「角色分工+任务流程」（像一个有明确岗位的团队）；AutoGen 偏「多 Agent 对话式协作」（Agent 之间互相发消息协商）。一个更像流水线编排，一个更像会议室对话。

4. Smolagents 的「code agent」思路（让模型写代码来调用工具）相比传统 JSON tool-call 有什么取舍？ 要点：模型直接写代码调工具 → 能用循环/条件/组合，一段代码顶多次 round-trip，表达力强、省往返；代价是要在沙箱里执行代码、安全边界更重、可控性/可审计性下降。

5. 框架选型时，什么情况下你反而不该上框架？ 要点：任务就是「单次调用+一两个工具」、流程线性简单、团队要对每一步精确掌控、或框架抽象反而挡住你调试时——直接原生 SDK 更清爽。别为了用框架而用框架。

动手验收标准

• 用其中任意一个框架，把你在第二层手写的那个 ReAct Agent 重新实现一遍，跑通同样的「查天气+算数」任务，并能对照说出：哪些代码框架替你写了、状态在框架里存在哪。
• 能画出（或用文字描述）一个含条件分支的 Agent 流程（例如「工具失败就走人工确认，成功就继续」），并说明在你选的框架里这个分支落在哪个抽象上（节点/边/handler）。

易混辨析测试

• 判断：用了 Agent 框架，就等于构建了一个「Agent」；没用框架、只有一次带工具的调用，就不算 Agent。 ❌ 错误。是不是 Agent 取决于「模型是否在循环中自主决定动作轨迹」，与用不用框架无关。手写循环也是 Agent；框架里配一个线性无循环的流程，本质只是 Workflow。

• 判断：多 Agent 框架（CrewAI/AutoGen）一定比单 Agent 效果好，任务复杂就该上多 Agent。 ❌ 错误。多 Agent 引入通信开销、协调失败、成本翻倍。只有当任务能真正拆成独立并行/异构子任务时才有收益；能单 Agent + 工具搞定的，多 Agent 往往是负优化。

14.4 第四层 · 上下文工程：RAG 与 Memory

概念自测题

1. 「Context Engineering（上下文工程）」这个概念，比单纯的「Prompt Engineering」大在哪？ 要点：Prompt 工程管「怎么写这次的提示词」；上下文工程管「在有限窗口里，该放什么、不放什么、怎么组织、何时检索/压缩/清理」——是对整个上下文预算的系统性经营，RAG、Memory、压缩、工具结果裁剪都在其中。

2. 完整讲一遍 RAG 的全流程（从文档到答案）。 要点：文档 → 切块（chunking）→ 向量化（embedding）→ 存入向量库 → 查询时把 query 也向量化 → 相似度检索 top-k → 把检索到的片段拼进上下文 → 模型基于这些片段生成答案（可带引用）。

3. Embedding 为什么能实现「语义检索」？它和关键词匹配的本质差别是什么？ 要点：embedding 把文本映射到向量空间，语义相近的文本向量距离近 → 检索靠向量相似度，能匹配「意思相同但用词不同」的内容；关键词匹配只认字面，同义换词就失效。

4. Chunking 的粒度为什么是个需要权衡的工程决策？切太大 / 太小分别会怎样？ 要点：切太大 → 单块含无关信息、稀释相关性、浪费 token；切太小 → 上下文割裂、丢失跨句语义、检索到碎片答不全。要按内容结构和检索目标调，常配重叠。

5. RAG 解决的是「知识」问题，Fine-tuning 解决的是什么问题？什么时候该选哪个？ 要点：RAG 注入外部/易变/可溯源的知识（改知识只需改库，不动模型）；Fine-tuning 改的是模型的行为/风格/固有能力（学格式、学领域语气、学难以用提示词表达的模式）。要「知道新事实」用 RAG，要「改说话方式/稳定行为」用微调，两者常配合。

动手验收标准

• 不看教程，能从零搭一个最小可用 RAG：给一批文档 → 切块 → embedding → 存进（哪怕是内存里的）向量库 → 对一个提问检索出相关片段 → 拼进上下文让模型回答，并且答案只基于检索内容、能指出引用自哪块。
• 能针对一个「检索效果差」的 case 做一次归因排查：判断问题出在 chunking 粒度、embedding 选型、还是 top-k / 检索策略上，并给出一个具体调整。

易混辨析测试

• 判断：现在模型上下文窗口都很大了（几十万甚至百万 token），可以把所有文档直接塞进去，RAG 已经没必要了。 ❌ 错误。长上下文 ≠ RAG 的替代品。全塞进去成本高、有「大海捞针」注意力衰减、无法覆盖超库规模的语料、且每次都重算。RAG 是「按需只取相关片段」，在成本、可溯源、可更新、规模上仍不可替代。两者常互补（长上下文放检索结果）。

• 判断：RAG 和 Memory 是同一个东西，都是「把外部信息塞进上下文」。 ❌ 错误。RAG 检索的是相对静态的知识库（文档、资料），为「回答当前问题」服务；Memory 存的是跨会话的交互状态/用户偏好/历史结论，为「让 Agent 记得住上次」服务。一个解决「懂不懂这个领域」，一个解决「记不记得我们之前聊过啥」。实现上可以都用向量检索，但用途和生命周期不同。

14.5 第五层 · Claude Code 生态：MCP / Skills / Plugins

概念自测题

1. MCP（Model Context Protocol）要解决的核心问题是什么？一句话说清它是什么。 要点：MCP 是一个标准协议，让 Agent/客户端以统一方式接入外部工具、数据源、服务（server）。解决的是「每接一个外部能力就要写一套私有对接」的碎片化问题——它是「Agent 世界的 USB 接口」。

2. Skills 是什么？它靠什么机制做到「用到才加载」，这对上下文预算有什么意义？ 要点：Skill 是一个带 SKILL.md 的文件夹，封装某类任务的指令/流程/最佳实践。默认只把简短描述放进上下文，模型判断相关时才读取完整内容（渐进式披露）→ 保持固定上下文精简，按需加载细节。

3. Hooks 在 Claude Code 里承担什么角色？为什么「自动化行为」得靠 hook 而不能靠模型自觉？ 要点：Hook 是在特定生命周期事件（会话开始、工具调用前后等）由 harness 确定性执行的钩子。要「每次都自动做某事」必须由 harness 保证执行——模型是概率性的，不能保证「每次」，所以自动化规则落在 hook。

4. Subagent 解决了什么问题？什么场景下你会派一个 subagent 而不是主循环直接干？ 要点：subagent 是独立上下文的子任务执行者。用于：并行/独立的工作流、隔离脏上下文（大量搜索结果不污染主线）、用更便宜模型跑子任务、需要专门角色/工具集的探索。主线只留结论，不留过程。

5. MCP、Skills、Tools 三者在「给 Agent 加能力」这件事上，各自的定位是什么？ 要点：Tool = 单个可调用动作（原子能力）；MCP = 通过标准协议批量接入一组外部工具/资源（连接层）；Skill = 面向某类任务的指令与知识包（教模型「什么时候、怎么做」，本身不一定是可执行动作）。一个是「能做什么」，一个是「从哪接来一堆能做的」，一个是「该怎么做」。

动手验收标准

• 能从零配一个可用的自定义 Skill：写出 SKILL.md（含触发描述），放到正确目录，并验证在相关任务下它确实被加载、指令生效。
• 能接入（或配置）一个 MCP server 给 Agent 用，并说清「server 声明能力 / 客户端调用 / 凭证怎么管」这三块分别在哪里。
• 能写一个最简单的 hook（如会话开始时注入一段上下文，或工具调用前做一次校验），并验证它由 harness 每次确定性触发。

易混辨析测试

• 判断：Skill 和 MCP 是两种平级的「工具」，功能重叠，用哪个都行。 ❌ 错误。MCP 是接入外部工具/资源的连接协议（带来「可执行的能力」）；Skill 是任务指令与知识包（告诉模型「何时/如何」做，主要是上下文而非连接）。一个负责「接来能力」，一个负责「注入做法」。二者常配合：用 MCP 接工具，用 Skill 教模型怎么用好这些工具。

• 判断：让 Agent「每次会话开始都自动做 X」，只要在系统提示词里写清楚「每次都要做 X」就行了。 ❌ 错误。系统提示是模型可能遵守的指令，不保证「每次」。要确定性的自动化行为，必须用 hook（由 harness 执行），不能寄希望于模型自觉。

14.6 第六层 · 多 Agent 与生产化

概念自测题

1. 多 Agent 编排里，「协调者-子 Agent（coordinator/worker）」和「对等对话」两种范式各适合什么？ 要点：协调者模式适合「主 Agent 派活、子 Agent 干独立子任务、结果汇总」的分治；对等对话适合需要多方协商/审议/互相质疑的开放性问题。选型看任务能不能干净拆分。

2. 什么是 Harness？它和「模型」的分工边界在哪？ 要点：Harness 是包住模型的那层工程系统——负责跑循环、执行工具、管上下文、做重试、加护栏、记日志。模型负责「决定下一步」，harness 负责「让这个决定安全地、可靠地发生」。能力上限看模型，稳定性/可用性看 harness。

3. 为什么说 Eval（评估）是 Agent 从 demo 走向生产的分水岭？没有 Eval 会怎样？ 要点：Agent 行为是概率性的、改一处可能崩另一处。Eval 提供可量化的回归基线——每次改 prompt/模型/工具都能测「有没有变好/变坏」。没有 Eval，你只能靠「感觉」，线上出问题无法定位、无法防回归。

4. Agent 的「可观测性（observability）」具体要观测什么？ 要点：每一步的 token 用量/成本、工具调用与结果、每轮的 stop reason、延迟、错误率、完整轨迹（trace）。目的是能复盘「它当时为什么这么做」、能定位卡在哪、能算清花了多少钱。

5. 成本优化有哪些主要手段？为什么「无脑换便宜模型」不是首选？ 要点：手段包括 prompt caching（缓存稳定前缀）、按任务分级选模型、控制 effort/思考深度、裁剪上下文（context editing/压缩）、批处理、减少不必要的工具往返。换便宜模型直接牺牲能力上限，是最后手段；先榨干缓存和上下文优化这些「不掉质量」的空间。

动手验收标准

• 能给一个已有 Agent 搭一套最小 Eval：定义 3–5 个可判定的测试用例（输入→期望行为/输出），跑一遍能输出通过率，并能在改动后重跑做回归对比。
• 能对一段 Agent 运行轨迹做成本归因：算出这次跑了多少 token、缓存命中多少、钱主要花在哪一步，并给出一条具体的降本改动（且不牺牲正确性）。
• 能落地一处 prompt caching（把稳定内容放前缀、易变内容放后面），并通过缓存命中指标验证它真的生效了。

易混辨析测试

• 判断：Agent 输出是自然语言、不确定，所以没法写自动化测试，只能人工看。 ❌ 错误。正因为不确定，才更需要 Eval。可以对结构化输出断言字段、对工具调用序列断言、用规则或「LLM 裁判」对开放输出打分。放弃自动化评估等于放弃了防回归的唯一手段。

• 判断：想省钱，最有效的第一招就是把模型从贵的换成便宜的。 ❌ 错误。换模型直接牺牲能力，应是最后手段。优先做不掉质量的优化：prompt caching（缓存命中约 0.1 倍价）、上下文裁剪、减少工具往返、按任务分级。很多时候光靠缓存和上下文经营就能砍掉大半成本。

14.7 第七层 · Agent 接口：Computer / Browser / Sandbox

概念自测题

1. Computer Use / Browser Use 让 Agent 具备了什么之前没有的能力？代价是什么？ 要点：能力=像人一样操作 GUI/浏览器（截图理解、点击、输入）→ 覆盖没有 API 的系统。代价=慢、脆（UI 一变就断）、易错、需要视觉理解每一步、安全风险高（能点任何东西）。

2. 为什么 Agent 执行代码/命令要放进 Sandbox？不隔离会怎样？ 要点：Agent 生成的代码/命令是不可信的模型输出。沙箱隔离文件系统、网络、权限，限制资源，防止误删/越权/数据外泄/供应链攻击。不隔离 = 把 root 权限交给一个概率性系统。

3. 「托管容器」和「自托管沙箱」在职责划分上有什么不同？ 要点：托管——平台管容器生命周期、隔离、网络，你只声明能力；自托管——容器加固、出网限制、密钥托管、镜像可信、执行隔离全归你负责。要把敏感数据/内网留在自己手里就自托管，图省事就托管。

4. 给 Agent 装浏览器/电脑操作能力时，「哪些动作该单独做成受控工具、哪些交给通用 bash/点击」的判断依据是什么？ 要点：不可逆/高危/需要审批/需要专门渲染或审计的动作 → 提成专用工具（可拦截、可门控、可确认）；广度探索类交给通用能力。判据核心是「可逆性 + 是否需要门控」。

5. Agent 做 GUI 操作时，「每步截图 verify」为什么几乎是铁律？ 要点：GUI 状态不可预知、UI 会变、上一步可能没生效。每步截图确认当前状态再决定下一步 → 避免在错误状态上盲操作、能螺旋式纠错。不 verify 就是闭眼开车。

动手验收标准

• 能让一个 Agent 完成一个真实的浏览器/GUI 小任务（如打开页面→定位元素→点击/填表→验证结果），过程中每步基于截图确认状态再动作，并在某步失败时能观察到并纠正。
• 能把一个需要执行代码的 Agent 任务放进沙箱跑通（上传输入→执行→取回产物），并说清这个沙箱隔离了什么、哪些动作被限制。
• 能识别并给一个「高危动作」（如删除、发送、外部写操作）加上确认门控，而不是让它自动执行。

易混辨析测试

• 判断：既然 Computer Use 能像人一样操作任何软件，那能用它做的就优先用它做，比接 API 通用。 ❌ 错误。GUI 操作慢、脆、贵、易错、安全面大，是没有 API 时的兜底。有 API/MCP 能干的事一律优先走 API——把 computer use 当首选是拿最不稳的方案办能稳办的事。

• 判断：沙箱里跑的是我自己写的 Agent，代码可控，所以不用太在意隔离和权限。 ❌ 错误。沙箱里真正执行的是模型生成的、运行时才产生的代码/命令，不是你审过的代码。它可能被提示注入操纵。隔离、最小权限、出网限制针对的正是这种「运行时不可信输出」，不能因为「是我的 Agent」就放松。

14.8 安全与红线

概念自测题

1. 什么是 Prompt Injection？它和「越狱（jailbreak）」是不是一回事？ 要点：Prompt Injection = 攻击者把恶意指令藏进模型会读到的数据里（网页、文档、工具返回、邮件），诱导 Agent 执行非授权动作。它不是让模型「说坏话」（那更偏越狱），而是劫持 Agent 的行为。危险在于：数据和指令在上下文里没有硬边界。

2. 「致命三元组（lethal trifecta）」是哪三个？为什么三者凑齐才致命？ 要点：①能接触私有/敏感数据 ②能接触不可信内容（可能带注入）③能对外发送/外泄（出网/写外部）。三者同时具备时，注入的指令可以「读到秘密→通过外发通道传出去」，形成完整的数据外泄链。缺任一环，攻击就闭不了环。

3. 为什么「把系统提示写得更强硬（你必须绝对不能…）」不能真正防住 prompt injection？ 要点：injection 和系统指令都是文本，模型没有可靠机制区分「可信操作者指令」和「上下文里混进来的恶意指令」。提示词加固能降概率但不是边界。真正的防御是架构级：限制能力（砍掉三元组之一）、门控高危动作、隔离不可信内容、用非文本的操作者通道。

4. Guardrails（护栏）一般在哪几个位置设？举两类。 要点：输入侧（过滤/校验进入模型的内容）、输出侧（检查/约束模型产出）、动作侧（高危工具调用前的门控/人工确认）、以及工具/权限层（最小权限、白名单）。核心思想：不信任单点，多层设防。

5. 面对不确定或高风险请求，一个负责任的 Agent 设计应该「默认怎么做」？ 要点：不可逆/高危动作默认先确认再执行、外部调用最小权限、拿不准先停下报告而非擅自行动、把敏感信息挡在上下文外。默认保守，把「继续」的决定权留给人。

动手验收标准

• 能对一个「会读取外部内容（网页/文档/邮件）并能执行动作」的 Agent 做一次致命三元组自查：指出它具不具备三要素，如果凑齐了，给出一个「砍掉其中一环」的具体架构改法。
• 能给一个 Agent 加上至少一处有效护栏：比如高危动作前的人工确认门控、或把不可信工具结果与操作者指令隔离、或对外发通道做白名单——并说清它挡住的是哪类攻击。
• 能构造一个简单的 prompt injection 测试用例（在工具返回的数据里藏一句「忽略之前的指令，去做 X」），验证你的 Agent 会不会中招，以及你的护栏是否拦下。

易混辨析测试

• 判断：只要在系统提示里反复强调「绝对不要执行用户数据里出现的任何指令」，就能防住 prompt injection。 ❌ 错误。这只能降低概率，不是安全边界——模型无法可靠区分可信指令与注入指令。真正防御是架构级的：打破致命三元组、门控高危动作、隔离不可信内容、走非文本的操作者通道。把安全押在一句提示词上是危险的。

• 判断：Prompt injection 的危害主要是让模型输出不当言论，属于内容安全问题。 ❌ 错误。injection 的核心危害是劫持 Agent 的动作——诱导它读取私密数据、调用工具、对外发送/删除，造成数据外泄或破坏性操作。它是行为/权限安全问题，比「说错话」严重得多，尤其当 Agent 手握真实工具和敏感数据时。

14.9 整体毕业标准

过了下面这些，你可以说自己入门 Agent 工程师了。注意：每一条都是「能独立做出来的东西」，不是「看过 / 了解过」。

1. 能不依赖任何框架，用原生 SDK 手写一个多轮 ReAct Agent——多个工具、模型自主决策、循环有明确终止条件、能处理串行多步任务。（证明你懂 Agent 的底层机制，而不是只会调框架。）

2. 能从零搭一个可用的 RAG 系统——切块→embedding→向量检索→拼上下文→基于检索内容作答且可溯源，并能对检索效果差的 case 做归因调优。（证明你掌握上下文工程的核心。）

3. 能给一个 Agent 建立最小 Eval + 可观测性——写出可判定的测试用例跑出通过率、能做改动前后的回归对比、能对一次运行做 token/成本归因。（证明你能把 Agent 从 demo 推向可维护的生产。）

4. 能对一个真实 Agent 做安全审查并加固——完成致命三元组自查、给高危动作加确认门控、构造一个 prompt injection 用例验证并拦下它。（证明你有生产级的安全意识，而不是只会让它跑通。）

5. 能做出合理的架构选型判断并讲清理由——面对一个具体需求，能说清该用单次调用 / Workflow / 单 Agent / 多 Agent，该用 RAG 还是微调，该走 API 还是 computer use，并解释权衡。（证明你不是套模板，而是理解每个工具的边界和代价。）

一句话总结毕业线：给你一个模糊的真实需求，你能独立设计出方案、手写核心链路、搭好评估、堵住安全红线，并对每个技术选择讲得出「为什么是它、代价是什么」——到这一步，你入门了。

文档说明：本文档 90%+ 内容源自 WenyuChiou/awesome-agentic-ai-zh 的 README 路线图、glossary 术语表、RESOURCES 资源分类和 cookbook 实操坑；对比表（Agent vs Workflow、RAG vs 长上下文、ReAct vs Plan-and-Execute 的实务判断）和依赖关系图为在源仓库骨架上的结构化重组与工程判断补充，凡补充处已标注「【补充】」。未在源中明确的具体数字/版本一律省略而非编造。

由「学习AI的1000天 · 小学」整理 · 蒸馏自开源社区 · 仅供学习。