📢 本文是「108张AI知识卡片·大模型通关手册」系列第 9 篇。上一篇把 Agent 的 6 个核心概念（Agent/ReAct/Memory/Skills/插件/MCP）讲透了——一个 Agent 能自己干活了。但现实中的任务往往太复杂，一个 Agent 搞不定：规划、执行、校验需要不同专长，跨系统数据需要不同接口。这篇讲的是"从单打独斗到团队协作"——Agent 之间怎么对话、怎么分工、怎么跟数据打交道，以及 AI 怎么帮你写代码。
目录
- TL;DR 太长不看
- 一、A2A协议：给Agent装上对讲机
- 二、多智能体：从单打独斗到团队协作
- 三、NL2SQL：自然语言直接查数据库
- 四、对话状态跟踪：多轮对话的记忆管理员
- 五、Vibe Coding：告诉AI你想要什么感觉
- 六、Spec Coding：把需求写清楚，AI照着蓝图造房子
- 七、一张图串起Agent进阶链路
- 八、代码：多Agent协作 + NL2SQL 实战
- 写到最后
- 系列导航 & 持续更新
TL;DR 太长不看
⚡30 秒版：先记这 7 条，细节往下翻。
- 🔴A2A：Agent-to-Agent Protocol，Agent 之间的"通用语言"——不同框架的 Agent 能互相对话，就像给 AI 装上了对讲机。
- 🟠多智能体：多个 Agent 分工协作——规划者调度、执行者干活、校验者把关，1+1>2 的组织智慧。
- 🟡NL2SQL：自然语言直接查数据库——"上个月销量最高的产品是什么？"→自动生成 SQL→返回结果。
- 🟢对话状态跟踪：多轮对话的"记忆管理员"——谁说了啥、聊到哪了、当前意图是什么，全靠它记着。
- 🔵Vibe Coding：用意图驱动代码生成——跟 AI 说"我想要这种感觉"，它就帮你写，探索阶段最快。
- 🟣Spec Coding：用规格说明驱动编码——把需求写清楚，AI 照着蓝图造房子，交付阶段最稳。
- 🎁进阶口诀：A2A 通语言 → 多智能体分角色 → NL2SQL 接数据 → 对话状态跟踪管记忆 → Vibe Coding 快探索 → Spec Coding 稳交付。
一、A2A协议：给Agent装上对讲机
LangChain 的 Agent 和 AutoGen 的 Agent 想协作——但一个说"JSON-RPC"，一个说"REST API"，互相听不懂。A2A 就是给它们装上对讲机，统一通信语言。
A2A（Agent-to-Agent Protocol）解决的核心问题：不同框架的 Agent 之间无法直接通信。每个 Agent 框架有自己的消息格式、调用方式、状态管理——跨框架协作就像两个说不同语言的人合作，中间需要翻译。A2A 定义了一套标准通信协议，让任何框架的 Agent 都能互相对话。
它到底在干嘛（机制层）：A2A 协议定义了 Agent 间通信的三个核心标准。Agent Card（名片）：每个 Agent 发布一张"名片"，声明自己的能力（“我能做数据分析”）、接口格式（“接受 JSON 输入”）、安全要求（“需要 OAuth 鉴权”）。其他 Agent 通过读名片知道"这个 Agent 能做什么、怎么调用"。Task（任务）：Agent 之间的交互以"任务"为单位——发起方创建一个 Task（“帮我分析这份数据”），接收方接受并执行，双方通过 Task 状态（pending/running/completed/failed）同步进度。Message（消息）：Task 执行过程中，Agent 之间通过标准格式的 Message 交换信息——请求、结果、中间状态、错误信息。关键点：A2A 不规定 Agent 内部怎么实现，只规定 Agent 之间怎么说话——就像 HTTP 不规定服务器用什么语言写，只规定请求和响应的格式。
你能感受到什么（体感层）：没有 A2A：你想让 LangChain Agent 调用 AutoGen Agent 的能力，要写一个适配器——理解 AutoGen 的消息格式、转换成 LangChain 能理解的格式、处理错误和超时。每加一个新框架，就多一套适配。有 A2A：两个 Agent 都说 A2A 协议，直接通过标准 Task/Message 通信——零适配代码，即插即用。
| 无A2A | 有A2A | |
|---|---|---|
| 跨框架通信 | 需写适配器 | 标准协议直连 |
| 新Agent接入 | 写新适配 | 读Agent Card即可 |
| 生态 | 框架孤岛 | 互通网络 |
| 复杂度 | O(N²)适配 | O(N)接入 |
🎛️ 动手感受：手动适配 vs A2A 通信
操作：让两个不同框架的 Agent 协作一个任务，分别用手动适配和 A2A 协议。
你会看到：
- 手动适配：写适配代码→调试格式→处理超时→终于能通信，耗时数小时。
- A2A：两个 Agent 交换 Agent Card→创建 Task→标准 Message 通信，几分钟搞定。
- 变化说明了什么：A2A 把"Agent 间通信"从"写代码"变成"配协议"——就像 HTTP 让任何浏览器能访问任何网站一样。
🤔 想一想
A2A 目前还是 Google 提出的草案，不是行业标准——就像早期的 HTTP 也有竞争对手（Gopher）。如果 A2A 没有成为唯一标准，而是出现了多个竞争协议呢？Agent 生态可能再次碎片化。协议的标准化需要时间和生态支撑，不是技术好就能赢。
🔗 顺着他想：A2A 解决了"Agent 之间怎么说话"，但多个 Agent 组成团队后，谁指挥谁？怎么分工？这就是多智能体协作要解决的问题。
二、多智能体：从单打独斗到团队协作
一个 Agent 又规划又执行又校验——什么都干，什么都不精。多智能体就是让每个 Agent 专精一件事：规划者只管调度，执行者只管干活，校验者只管把关——专业分工，1+1>2。
多智能体解决的核心问题：单 Agent 能力有限，复杂任务需要不同专长的 Agent 协作。多智能体把任务拆分给多个专精 Agent，通过协调机制让它们高效配合。
它到底在干嘛（机制层）：多智能体系统的核心是角色分工+协调机制。常见架构有三种。主从式（Orchestrator-Worker）：一个"主 Agent"负责任务拆分和调度，多个"从 Agent"各干各的活——主 Agent 把"规划旅行"拆成"查航班"“订酒店”"查天气"三个子任务，分给三个从 Agent 并行执行。对等式（Peer-to-Peer）：没有主从，Agent 之间平等协作——A2A 协议就是为这种架构设计的，Agent 通过协商决定谁做什么。流水线式（Pipeline）：任务按顺序流过多个 Agent——Agent1 做需求分析→Agent2 写代码→Agent3 做测试→Agent4 做部署，每个 Agent 只负责一个阶段。协调的关键挑战：任务分配（谁干什么）、信息共享（Agent 之间怎么传递中间结果）、冲突解决（两个 Agent 的输出矛盾怎么办）、错误恢复（某个 Agent 失败了怎么补救）。
你能感受到什么（体感层）：单 Agent：你让它"写一个网页"，它自己写 HTML+CSS+JS，写完自己检查——代码质量一般，因为它不专精。多 Agent：规划 Agent 拆任务→前端 Agent 写 HTML/CSS→后端 Agent 写 JS→测试 Agent 跑测试→每个 Agent 只做自己最擅长的事，代码质量明显更高。代价是协调成本——Agent 之间的通信延迟、任务分配的决策开销、冲突解决的时间。
🎛️ 动手感受：单 Agent vs 多 Agent
操作：同一个复杂任务（如"写一个待办清单App"），分别用单 Agent 和多 Agent（规划+编码+测试）执行。
你会看到：
- 单 Agent：一次性生成全部代码，但测试逻辑薄弱，Bug 多。
- 多 Agent：规划 Agent 拆出模块→编码 Agent 逐模块实现→测试 Agent 逐模块测试→Bug 少，代码更规范。
- 变化说明了什么：多 Agent 的优势不在"更快"，在"更专"——每个 Agent 只做自己最擅长的事，整体质量更高。
🤔 想一想
多 Agent 的协调成本不可忽视——3 个 Agent 之间的通信延迟、任务分配的决策时间、冲突解决的开销，可能比单 Agent 直接干还慢。什么时候该用多 Agent？任务足够复杂、子任务之间足够独立、每个子任务需要不同专长——三个条件都满足时，多 Agent 才值得。
🔗 顺着他想：多 Agent 协作时，经常需要查数据库——“查一下上个月的销量数据”。但 Agent 不会写 SQL，怎么跟数据库打交道？这就是 NL2SQL 要解决的问题。
三、NL2SQL：自然语言直接查数据库
你问 Agent"上个月销量最高的产品是什么"，Agent 不会 SQL——它要么编一个答案，要么让你自己去查。NL2SQL 就是让 Agent 能听懂自然语言、自动生成 SQL、直接查数据库。
NL2SQL 解决的核心问题：Agent 和数据库之间有"语言障碍"——用户说自然语言，数据库只认 SQL。NL2SQL 把"上个月销量最高的产品"翻译成SELECT product FROM sales WHERE month='last' ORDER BY amount DESC LIMIT 1，Agent 就能直接查数据了。
它到底在干嘛（机制层）：NL2SQL 的流程分四步。① Schema 理解：大模型先理解数据库结构——有哪些表、每个表有哪些字段、字段之间的关联关系。② 问题解析：把自然语言问题映射到数据库结构——"销量最高"对应ORDER BY amount DESC，"上个月"对应WHERE month='last'。③ SQL 生成：根据映射结果生成 SQL 语句——SELECT product FROM sales WHERE month='last' ORDER BY amount DESC LIMIT 1。④ 执行+结果解读：执行 SQL，拿到结果，用自然语言回答用户——“上个月销量最高的产品是 iPhone 15 Pro，销量 12,345 台”。难点在 Schema 理解——如果数据库有 100 张表、每张表 50 个字段，大模型需要在海量 Schema 中精准定位相关表和字段，这和 RAG 的"检索"问题本质相同。
你能感受到什么（体感层）：没有 NL2SQL：你问"上个月销量最高的产品"，Agent 说"我无法访问数据库"，你只能自己打开数据库写 SQL。有 NL2SQL：Agent 自动生成 SQL→执行→告诉你"iPhone 15 Pro，12,345 台"——从"问人"到"问数据"，零门槛。简单查询（单表单条件）准确率 90%+，复杂查询（多表 JOIN+嵌套子查询）准确率降到 60-70%——复杂 SQL 的生成还是个开放问题。
🎛️ 动手感受：简单查询 vs 复杂查询的 NL2SQL
操作：分别输入简单查询（“查所有北京的用户”）和复杂查询（“查每个城市上个月销量前3的产品及其同比增幅”），看 NL2SQL 的生成质量。
你会看到：
- 简单查询：生成的 SQL 准确，
SELECT * FROM users WHERE city='北京'，执行结果正确。 - 复杂查询：生成的 SQL 可能漏了 JOIN 条件、或同比增幅的计算逻辑写错——需要人工校验。
- 变化说明了什么：NL2SQL 对简单查询已经相当可靠，但复杂查询仍需"人在回路"——AI 生成 SQL，人审核后执行。
🤔 想一想
NL2SQL 生成的 SQL 如果有错，直接执行可能改错数据（如DELETE误生成）——安全性怎么保证？只读权限（只允许 SELECT）、SQL 审核机制（生成的 SQL 需人工确认后执行）、沙箱执行（在测试环境先跑一遍）是三条基本防线。NL2SQL 的"安全执行"比"准确生成"更关键。
🔗 顺着他想：Agent 查完数据库，用户追问"那前个月呢？"——这是一个多轮对话，Agent 需要知道"上个月"的上下文才能理解"前个月"指的是什么时候。多轮对话的状态管理，是对话状态跟踪的事。
四、对话状态跟踪：多轮对话的记忆管理员
你跟 Agent 聊了 5 轮：订机票→改时间→加行李→问餐食→改座位。到第 5 轮，Agent 还记得你订的是哪趟航班吗？对话状态跟踪就是干这个的——记住"聊到哪了、当前状态是什么"。
对话状态跟踪（Dialogue State Tracking, DST）解决的核心问题：多轮对话中，Agent 需要持续追踪对话状态——用户意图、已收集的槽位信息、当前任务进度。没有 DST，Agent 在第 5 轮就忘了第 1 轮说了什么。
它到底在干嘛（机制层）：DST 维护一个对话状态（Dialogue State），每轮对话更新一次。对话状态通常包含三部分。意图（Intent）：用户当前想做什么——“订机票”“改时间”“加行李”。槽位（Slots）：完成任务需要收集的信息——订机票需要：出发城市、目的城市、日期、舱位。每轮对话可能填充一个或多个槽位。状态（Status）：任务进度——哪些槽位已填充、哪些还缺、当前处于哪个阶段。DST 的核心挑战是槽位更新——用户说"改成后天"，DST 需要把日期槽位从"明天"更新为"后天"，而不是新开一个日期槽位。这需要理解"改成"是"修改"而非"新增"。
你能感受到什么（体感层）：没有 DST：你说"订去上海的机票"→Agent 问"哪天？“→你说"明天"→Agent 问"几点的？“→你说"下午"→你说"改成后天"→Agent 不知道"改成"是修改日期，又问"哪天出发？”——用户体验崩溃。有 DST：每轮对话后 DST 更新状态：{目的:上海, 日期:明天→后天, 时间:下午}，Agent 直接确认"好的，已改为后天下午去上海的机票”——流畅自然。
🎛️ 动手感受：开/关 DST 的多轮对话
操作：同一个多轮订票对话，分别用无 DST 和有 DST 的 Agent，看第 5 轮时 Agent 还记得什么。
你会看到：
- 无 DST：第 5 轮时 Agent 忘了之前收集的信息，反复问同样的问题。
- 有 DST：每轮对话状态自动更新，Agent 始终知道当前已收集的信息和待完成的步骤。
- 变化说明了什么：DST 不是"记忆"，是"结构化记忆"——它不只是记住说了什么，还记住"这些信息意味着什么、当前任务到哪一步了"。
🤔 想一想
DST 的槽位是预定义的——订机票有"出发/目的/日期/舱位"，但如果用户说了预定义之外的信息呢？“我要带宠物”——宠物不是标准槽位，DST 怎么处理？开放域对话的 DST 是个开放问题——要么扩展槽位定义（穷举所有可能），要么用大模型做非结构化状态跟踪（灵活但不可控）。
🔗 顺着他想：Agent 能对话、能协作、能查数据——那 Agent 能帮你写代码吗？当然能，而且有两种风格：一种是"跟 AI 说感觉"（Vibe Coding），另一种是"把需求写清楚"（Spec Coding）。
五、Vibe Coding：告诉AI你想要什么感觉
“帮我做一个那种……很科技感的仪表盘，深色背景，数据要会动。”——你没写一行代码，没给一个具体需求，但 AI 就能帮你做出来。这就是 Vibe Coding：用意图和感觉驱动代码生成。
Vibe Coding 解决的核心问题：不是所有开发者都能写出精确的需求文档——有时候你只有一个模糊的想法、一种感觉、一个方向。Vibe Coding 让你用自然语言描述"我想要什么感觉"，AI 帮你生成代码，快速探索可能性。
它到底在干嘛（机制层）：Vibe Coding 的核心是意图驱动的迭代生成。你用自然语言描述意图（“做一个科技感仪表盘”）→AI 生成第一版代码→你看了觉得"不够科技感"→补充"加一些发光效果和动态数据"→AI 修改代码→反复迭代直到满意。和传统编程的区别：传统编程是"先想清楚再写代码"，Vibe Coding 是"先写出来再调整"——探索阶段，速度比精确更重要。AI 在这里的角色不是"代码生成器"，是"快速原型工具"——你负责方向，AI 负责实现，两者配合快速迭代。
你能感受到什么（体感层）：传统编程：写需求文档→设计 UI→写 HTML/CSS/JS→调试→2 天后看到第一版。Vibe Coding：跟 AI 说"科技感仪表盘"→30 秒看到第一版→"加发光效果"→10 秒更新→"数据要动态"→10 秒更新→5 分钟内迭代到满意。代价：生成的代码可能不规范、难维护、有隐藏 Bug——Vibe Coding 适合探索，不适合交付。
| 传统编程 | Vibe Coding | |
|---|---|---|
| 驱动方式 | 需求文档 | 意图+感觉 |
| 迭代速度 | 慢（天级） | 快（秒级） |
| 代码质量 | 高（人工把控） | 中（AI 生成） |
| 适合阶段 | 交付 | 探索/原型 |
🎛️ 动手感受：用 Vibe Coding 迭代一个页面
操作：跟 AI 说"做一个个人博客首页"，看第一版→补充"加暗色主题"→补充"加动画效果"→观察迭代过程。
你会看到：
- 第 1 版：基础博客布局，白底黑字，能用但丑。
- 加暗色主题后：深色背景+浅色文字，科技感初现。
- 加动画后：标题淡入、卡片悬浮效果，体验提升明显。
- 变化说明了什么：Vibe Coding 的核心是"快速迭代"——你不需要一次想清楚所有需求，边看边调，每轮 10 秒。
🤔 想一想
Vibe Coding 生成的代码，你真的理解每一行吗？如果出了 Bug，你能定位吗？如果需求变了，你能改吗？Vibe Coding 的"快"建立在"你不需要理解代码"的假设上——但交付阶段，你必须理解代码。所以 Vibe Coding 适合探索，不适合生产。
🔗 顺着他想：Vibe Coding 用"感觉"驱动，快但不可控——如果换成"规格说明"驱动呢？把需求写清楚，AI 照着蓝图造房子，代码更规范、更可维护。这就是 Spec Coding。
六、Spec Coding：把需求写清楚，AI照着蓝图造房子
Vibe Coding 快但糙，生成的代码像毛坯房——能用但没法交付。Spec Coding 是精装修：先把需求写清楚（规格说明），AI 照着蓝图造房子，每一面墙、每一根管子都有据可查。
Spec Coding 解决的核心问题：Vibe Coding 生成的代码不可控、不可维护。Spec Coding 用精确的规格说明（Spec）驱动代码生成——先写清楚"要什么"，再让 AI 生成，代码质量、可维护性、可测试性都远高于 Vibe Coding。
它到底在干嘛（机制层）：Spec Coding 的核心是规格驱动开发（SDD, Spec-Driven Development）。流程是：① 写 Spec：用结构化的自然语言或伪代码描述需求——功能、接口、数据结构、边界条件、错误处理。② AI 生成代码：根据 Spec 生成代码——因为 Spec 精确，生成的代码也更精确。③ 验证：对照 Spec 验证生成的代码——功能是否实现、接口是否匹配、边界是否处理。④ 迭代：Spec 不对就改 Spec，代码不对就重新生成——改 Spec 而非改代码。和 Vibe Coding 的本质区别：Vibe Coding 改"感觉"，Spec Coding 改"规格"——改规格是可控的（你知道改了什么），改感觉是不可控的（"更科技感"到底是多科技？）。
你能感受到什么（体感层）：Vibe Coding：“做一个用户登录页"→AI 生成了，但没做密码强度校验、没做错误提示、没做防暴力破解——因为"登录页"这个描述太模糊。Spec Coding：Spec 写了"密码至少8位含大小写数字”“错误提示显示在输入框下方”"5次失败锁定15分钟"→AI 照着生成，每个细节都有。Spec Coding 的代价：写 Spec 的时间可能比 Vibe Coding 迭代 10 轮还长——但交付阶段，这个时间是值得的。
| Vibe Coding | Spec Coding | |
|---|---|---|
| 输入 | 感觉/意图 | 精确规格说明 |
| 代码质量 | 中 | 高 |
| 可维护性 | 低 | 高 |
| 适合阶段 | 探索/原型 | 交付/生产 |
| 写需求时间 | 短 | 长 |
🎛️ 动手感受：Vibe Coding vs Spec Coding 生成同一个功能
操作：同一个功能"用户注册"，分别用 Vibe Coding（“做一个注册页”）和 Spec Coding（写详细 Spec）让 AI 生成。
你会看到：
- Vibe Coding：生成了基本注册表单，但缺少邮箱格式校验、密码强度提示、重复密码校验、服务端校验。
- Spec Coding：Spec 里写了所有校验规则→AI 生成的代码每个校验都有，错误提示完整，边界条件处理到位。
- 变化说明了什么：Spec Coding 的代码质量不取决于 AI，取决于 Spec 写得多清楚——"垃圾进垃圾出"同样适用。
🤔 想一想
写 Spec 本身就是一项技能——写得好，AI 生成得好；写得差，AI 生成的代码比 Vibe Coding 还烂。而且 Spec 也有"维护成本"：需求变了，Spec 也要同步更新，否则 Spec 和代码就会脱节。Spec Coding 的核心不是"AI 更强"，是"人更严谨"。
🔗 顺着他想：Vibe Coding 和 Spec Coding 不是非此即彼——探索阶段用 Vibe Coding 快速验证想法，交付阶段用 Spec Coding 确保质量。两种风格结合，才是 AI 辅助编程的完整工作流。
七、一张图串起Agent进阶链路
6 个概念串成一条从"通信"到"编程"的 Agent 进阶链路：
Agent团队 │ ① A2A协议 ← 统一通信语言，跨框架Agent互相对话 │ ② 多智能体协作 ← 规划者/执行者/校验者分工，1+1>2 │ ③ NL2SQL ← 自然语言查数据库，Agent和数据打交道 │ ④ 对话状态跟踪 ← 多轮对话状态管理，记住聊到哪了 │ ⑤ Vibe Coding ← 意图驱动快速探索，30秒出原型 │ ⑥ Spec Coding ← 规格驱动精确交付，代码有据可查进阶口诀：
- A2A通语言——不同框架 Agent 零适配对话。
- 多智能体分角色——专业分工，整体质量更高。
- NL2SQL接数据——自然语言直接查数据库。
- 对话状态跟踪管记忆——多轮对话不迷路。
- Vibe Coding快探索——意图驱动，秒级迭代。
- Spec Coding稳交付——规格驱动，代码有据可查。
八、代码：多Agent协作 + NL2SQL 实战
fromopenaiimportOpenAI client=OpenAI(api_key="你的KEY",base_url="https://api.openai.com/v1")# ① 模拟数据库db={"sales":[{"product":"iPhone 15","month":"2024-01","amount":8900},{"product":"MacBook Pro","month":"2024-01","amount":5600},{"product":"iPhone 15","month":"2024-02","amount":12345},{"product":"MacBook Pro","month":"2024-02","amount":6100},]}# ② NL2SQL Agent：自然语言→SQL→执行defnl2sql_agent(question:str)->str:schema="表sales: product(str), month(str), amount(int)"resp=client.chat.completions.create(model="gpt-4o-mini",messages=[{"role":"system","content":f"根据数据库Schema生成Python过滤代码。{schema}\n只输出一行Python列表推导式，用db['sales']作为数据源。"},{"role":"user","content":question}])code=resp.choices[0].message.content.strip()try:result=eval(code)returnstr(result[:5])except:returnf"生成代码执行失败:{code}"# ③ 规划Agent：拆任务defplanner_agent(task:str)->list:resp=client.chat.completions.create(model="gpt-4o-mini",messages=[{"role":"system","content":"把任务拆成子任务列表，每个子任务一句话描述。输出JSON数组。"},{"role":"user","content":task}])returnresp.choices[0].message.content# ④ 多Agent协作task="分析上个月销量最高的产品，并给出推广建议"plan=planner_agent(task)print(f"[规划]{plan}")# 执行数据查询子任务query_result=nl2sql_agent("上个月销量最高的产品是什么")print(f"[数据查询]{query_result}")# 生成建议resp=client.chat.completions.create(model="gpt-4o-mini",messages=[{"role":"user","content":f"根据数据：{query_result}，给出推广建议"}])print(f"[建议]{resp.choices[0].message.content}")这段代码实现了多 Agent 协作的核心逻辑：规划 Agent 拆任务→NL2SQL Agent 查数据→生成 Agent 给建议。生产环境要做的升级：加 A2A 协议做 Agent 间通信、加 DST 做多轮对话状态管理、加 Spec 做代码生成质量控制。
写到最后
从单 Agent 到多 Agent 协作，从"能干活"到"能协作"，从 Vibe Coding 的快探索到 Spec Coding 的稳交付——Agent 的进阶不是"更聪明"，是"更专业、更可控、更可协作"。A2A 让 Agent 能对话，多智能体让 Agent 能分工，NL2SQL 让 Agent 能查数据，DST 让 Agent 能记住对话状态，Vibe/Spec Coding 让 Agent 能帮你写代码——6 个概念串起来，就是 Agent 从"工具"到"团队"的进化路径。
下一篇我们换个视角，从"用大模型"跳到"懂大模型"——打开 GPT 的"胸腔"，看看 Transformer、Attention、MoE 这些架构组件到底长什么样。
如果你读下来觉得真有用：
- 👍点个赞，让我知道 Agent 进阶篇这种"通信→协作→编程"一条线的写法值得继续；
- ⭐收藏起来，A2A/NL2SQL/DST 这些概念在 Agent 实战中回来翻的概率很高；
- 💬关注一下，下一篇"大模型架构篇"会讲 Transformer/Attention/MoE，关注了就不会错过。
有问题评论区直接说，我会逐条回。
系列导航 & 持续更新
📚系列第 9 篇｜上一篇：6张图搞懂AI Agent——从ChatBot到数字员工 ｜下一篇预告：Transformer+Attention｜大模型的心脏解剖图
如果这篇对你有帮助，点个👍收藏，Agent 进阶概念在实战中回来翻的概率很高。有问题欢迎在评论区交流，我会逐条回复。
