第25章 主流Agent框架与协议：Agent Harness、MCP、A2A全解析
AI产品经理实战训练营 · 章节 25/44 · 60 学时
25.1 2025-2026年Agent技术栈全景
25.1.1 从"框架之争"到"协议之治"
2023-2024年，AI Agent领域的焦点是"哪个框架更好用"——LangChain、AutoGPT、MetaGPT、BabyAGI……各种框架层出不穷，开发者在框架选型上耗费大量精力。但到了2025-2026年，行业格局发生了根本性变化：
过去两年，行业焦点集中在"哪个模型的智商更高"和"哪个框架更好用"；而到了2026年，答案变成了"哪些协议能让不同Agent协同工作"。
Agent技术栈从"框架之争"进入了"协议之治"的新时代——MCP给了Agent手，A2A给了Agent同事，AG-UI给了Agent脸，一个完整的智能体互联新基建正在形成。
理解这个转变，对AI产品经理至关重要。你设计的Agent产品不再是孤立的应用，而是整个智能体生态中的一个节点，需要与其他Agent、工具、系统进行标准化互联。
25.1.2 Agent技术栈四层架构
2026年的Agent技术栈已经形成了清晰的四层架构：
| 层级 | 协议/技术 | 定位 | 类比 | 推出时间 |
|---|---|---|---|---|
| 工具接入层 | MCP（Model Context Protocol） | Agent与外部工具/数据源的标准接口 | USB-C接口 / Agent的"手" | Anthropic 2024.11 |
| 智能体协作层 | A2A（Agent2Agent Protocol） | 不同Agent之间的通信与协作标准 | HTTP协议 / Agent的"同事" | Google 2025.04 |
| 用户交互层 | AG-UI（Agent Graphical User Interface） | Agent与前端UI的交互标准 | HTML / Agent的"脸" | 2025年 |
| 网络发现层 | ANP（Agent Network Protocol） | 开放网络中Agent的发现与安全协作 | DNS / Agent的"通讯录" | W3C标准 |
ACP（Agent Communication Protocol）曾经是与A2A并列的第三协议，但已于2025年被合并到A2A中，由Linux基金会的Agentic AI Foundation统一管理。如果你在课程或文章中还看到ACP作为独立协议，那已经是过时信息了。
同样，AutoGPT、BabyAGI等2023年火爆的"自主Agent框架"，在2025年后热度大幅下降，其核心能力已被LangGraph、CrewAI等新一代Agent Harness吸收。
25.1.3 什么是Agent Harness（智能体运行时）
"Agent Harness"（智能体运行时/智能体框架）是2025年后流行的新概念，指的是为Agent提供运行环境、状态管理、工具接入、流程编排的基础软件框架。
如果说Agent是一辆汽车，Agent Harness就是汽车的底盘和发动机——它提供了动力系统（大模型调用）、转向系统（规划与决策）、刹车系统（错误处理与安全）、仪表盘（可观测性），让你可以专注于设计"去哪里"（业务逻辑），而不是从零造一辆车。
Agent Harness与传统"AI框架"的区别：
- 传统框架（如早期LangChain）：侧重Chain链式调用，流程固定，状态管理弱，适合简单的LLM应用
- Agent Harness（如LangGraph、CrewAI）：侧重有状态的图/流程编排，支持循环、分支、人工干预、持久化，适合复杂的Agent应用
25.2 主流Agent Harness框架对比
25.2.1 LangGraph——生产级有状态工作流的首选
背景：LangGraph是LangChain团队于2024年推出的开源框架，专注于构建具备状态管理和多步骤处理能力的复杂工作流。它解决了传统LangChain在动态流程控制（如循环、分支）方面的局限性，已成为LangChain生态的核心。
核心架构：
- 有向图（Graph）：用节点（Node）表示计算步骤，用边（Edge）表示状态转移，支持条件分支、循环、并行执行
- 状态管理（State）：全局共享状态对象，每个节点可以读取和修改状态，通过Reducer函数处理状态合并
- 持久化执行（Checkpointer）：支持任务中断后从断点恢复，支持人工审批节点插入
- 人机协作（Human-in-the-loop）：原生支持在流程中插入人工干预节点
优势：
- 模型无关，支持100+大模型（OpenAI、Anthropic、DeepSeek、通义、文心等）
- 生产级稳定性，大量企业在生产环境使用
- 生态丰富，与LangChain工具生态无缝集成
- 可���测性好，支持LangSmith追踪和调试
劣势：
- 学习曲线中等偏高，需要理解图论和状态管理概念
- 代码量相对较多，简单场景可能显得"重"
- 多Agent协作需要自行设计，不如CrewAI直观
适用场景：金融、医疗、工业制造等流程可控性要求高、状态持久化需求强的复杂业务场景。
某股份制银行2025年用LangGraph构建了企业信贷审批Agent，流程包括：客户信息采集→征信查询→财务分析→风险评估→人工审批→放款决策。
选择LangGraph的原因：
1. 信贷审批流程有明确的状态流转（待审批→审批中→已通过/已拒绝），需要持久化状态
2. 流程中有人工审批节点，需要Human-in-the-loop
3. 审批过程可能中断（如等待客户补充材料），需要断点恢复
4. 银行对稳定性要求极高，LangGraph生产级特性能满足要求
实施效果：审批时间从平均3天缩短到4小时，审批效率提升80%，不良率下降15%。
25.2.2 CrewAI——角色化团队协作的最佳选择
背景：CrewAI是2024年崛起的开源框架，核心理念是"团队合作"，将Agent抽象为具有特定角色（Role）和目标（Goal）的团队成员，通过Crew（小组）组织多个Agent协作完成任务。2025年市场占有率已达20%，增长迅速。
核心架构：
- Agent（角色）：定义执行者，包括角色、目标、背景故事、工具、模型
- Task（任务）：定义具体任务，包括描述、预期输出、分配的Agent、上下文
- Crew（小组）：组织Agents和Tasks，定义协作流程
- Process（流程）：Sequential（顺序执行）和Hierarchical（层级管理，有管理者Agent分配任务）两种模式
优势：
- API非常直观易懂，非技术人员也能快速上手
- 角色化抽象符合人类团队协作直觉，适合业务场景建模
- 原生支持多Agent协作，Sequential和Hierarchical两种流程
- 支持短期记忆和长期记忆，支持RAG集成
- 社区活跃，文档完善，学习资源丰富
劣势：
- 复杂流程控制（如循环、条件分支）不如LangGraph灵活
- 状态持久化和断点恢复能力较弱
- 生产级大规模部署的案例相对较少
适用场景：客服、零售、电信、内容创作、市场研究等角色分工明确、协作流程标准化的场景。特别适合创业公司MVP和快速原型。
来自r/LLMDevs的开发者反馈："CrewAI非常适合与非技术PM一起做原型。我们两周就有了MVP。对于简单智能体，LangChain感觉太重了。"
这正是CrewAI的核心价值——降低多Agent协作的门槛，让业务人员也能参与Agent设计。
25.2.3 AutoGen——对话式多Agent研究框架
背景：AutoGen是微软于2023年推出的开源框架，主打对话式多Agent协作，Agent之间通过自然语言对话完成任务。2025年发布了v0.4版本，重构了架构，增强了生产可用性。
核心架构：
- Conversable Agent：可对话的Agent基类，支持发送和接收消息
- Assistant Agent：AI助手，调用大模型生成回复
- User Proxy Agent：用户代理，代表用户执行代码、调用工具、提供反馈
- Group Chat：多Agent群聊，支持轮询、手动选择、自动选择等发言管理方式
优势：
- 对话式协作自然灵活，适合探索性任务
- 原生支持代码执行，适合数据分析、编程任务
- 微软背书，研究资源丰富
- v0.4版本增强了异步支持和生产可用性
劣势：
- 对话式协作可能导致流程不可控，Agent容易"跑偏"
- 生产级状态管理和持久化能力较弱
- 学习曲线中等，Group Chat的发言管理需要调优
- 企业级合规和安全特性不如LangGraph
适用场景：互联网、科研、数据分析、编程辅助等探索性、实验性多Agent场景。
25.2.4 OpenAI Agents SDK——OpenAI生态的极简选择
背景：OpenAI于2025年3月推出的官方Agent框架，主打极简API和Runtime托管，是OpenAI生态的原生选择。
核心特性：
- 极简API：几行代码就能跑起来一个Agent，Runtime细节全托管
- 内置工具生态：网页浏览、文件搜索、代码解释器等开箱即用
- Handoff机制：Agent之间可以互相移交任务，支持层级协作
- Guardrails（护栏）：内置输入/输出护栏，支持内容安全过滤
- Tracing（追踪）：与OpenAI平台集成，支持完整的执行追踪
优势：
- 开发效率最高，几行代码跑通Agent
- 与OpenAI模型和工具生态深度集成
- Handoff机制设计优雅，适合多Agent层级协作
- 官方维护，更新及时
劣势：
- 黑盒——看不到内部状态转移和决策日志，精细调优受限
- 模型被OpenAI生态绑定，不支持其他厂商模型
- 私有化部署受限，数据需要经过OpenAI
- 复杂流程控制能力不如LangGraph
适用场景：简单Agent、OpenAI技术栈团队、快速原型验证、对模型厂商绑定不敏感的场景。
25.2.5 框架对比总结与选型建议
| 对比维度 | LangGraph | CrewAI | AutoGen | OpenAI Agents SDK |
|---|---|---|---|---|
| 架构范式 | 有向图/状态机 | 角色化团队 | 对话式协作 | 命令式Handoff链 |
| 最适合 | 生产级有状态工作流 | 快速原型/业务自动化 | 研究/实验多Agent | 简单Agent/OpenAI生态 |
| 学习曲线 | 中高 | 低 | 中 | 低 |
| 模型支持 | 模型无关（100+） | 模型无关 | 模型无关 | 仅OpenAI模型 |
| 状态持久化 | 强（Checkpointer） | 弱 | 弱 | 中 |
| 人工干预 | 原生支持 | 支持 | 支持 | 支持 |
| 多Agent协作 | 需自行设计 | 原生支持（角色化） | 原生支持（对话式） | 支持（Handoff） |
| 生产就绪度 | 高 | 中 | 中（v0.4提升中） | 中 |
| 典型行业 | 金融/医疗/工业 | 客服/零售/内容 | 互联网/科研 | 创业公司/原型 |
1. 复杂业务流程+高合规要求→选LangGraph，状态管理和持久化是刚需
2. 多角色协作+快速原型→选CrewAI，角色化抽象让业务人员也能参与设计
3. 探索性研究+代码执行→选AutoGen，对话式协作灵活，代码执行能力强
4. 简单Agent+OpenAI生态→选OpenAI Agents SDK，开发效率最高
5. 不确定时→先选CrewAI做原型验证，验证后如需生产级再迁移到LangGraph
关键原则：框架只是工具，业务价值才是核心。不要为了用某个框架而设计产品，要根据业务需求选择最合适的框架。
25.3 MCP协议——Agent的"手"
25.3.1 MCP是什么
MCP（Model Context Protocol，模型上下文协议）由Anthropic于2024年11月推出，2025年捐赠给Linux Foundation托管，目前已成为AI工具调用的事实标准。截至2026年8月，全球已有超过200个MCP服务器实现，覆盖数据库、API、文件系统、SaaS工具等各类场景。
MCP就像AI领域的"USB-C接口"——在MCP之前，每个AI应用都要为每个工具单独写适配代码，就像每个电器都要有自己的专用插头。有了MCP，工具和数据源的接入方式标准化了，就像USB-C让所有外设都能用同一个接口一样，实现了"即插即用"。
MCP解决的核心问题：
- 碎片化：每个AI应用都要单独集成工具，重复开发，维护成本高
- 安全性：AI应用直接访问工具和数据，权限难以管控，安全风险大
- 可移植性：工具集成代码与特定AI应用绑定，难以迁移和复用
- 上下文管理：工具返回的数据格式不统一，难以有效注入大模型上下文
25.3.2 MCP核心架构
MCP采用客户端-主机-服务器三层架构：
- MCP Client（客户端）：集成在AI应用（如Claude、Cursor、Agent框架）中，负责向主机发送请求，接收响应
- MCP Host（主机）：管理客户端与服务器之间的连接，负责安全认证、权限控制、请求路由
- MCP Server（服务器）：封装具体的工具和数据源，如数据库MCP服务器、GitHub MCP服务器、文件系统MCP服务器等
MCP定义了三大原语：
| 原语 | 说明 | 类比 | 示例 |
|---|---|---|---|
| Tools（工具） | 可执行的函数，Agent可以调用 | USB设备的功能 | 查询数据库、发送邮件、创建日历事件 |
| Resources（资源） | 可读取的数据源，Agent可以获取内容 | U盘里的文件 | 文档、知识库条目、API数据 |
| Prompts（提示模板） | 预定义的工作流模板，Agent可以使用 | 设备的预设模式 | 代码审查模板、数据分析模板 |
25.3.3 MCP的产品意义
对AI产品经理来说，MCP的出现具有深远的产品意义：
- 工具生态标准化：不需要为每个工具单独开发集成，只要支持MCP协议就能接入整个生态，大幅降低开发成本
- 安全可控：MCP Host层可以统一管理权限，企业可以精确控制Agent能访问哪些工具、哪些数据，满足合规要求
- 用户体验一致：用户在不同AI应用中使用相同的MCP工具，体验一致，学习成本低
- 商业模式创新：MCP服务器可以作为独立产品收费，工具提供商可以通过MCP生态触达更多用户
- 企业级集成：企业内部系统（ERP、CRM、数据库等）只要封装成MCP服务器，就能被任何支持MCP的Agent调用，实现企业知识和能力的AI化
某大型制造企业2025年启动了"企业AI能力平台"建设，核心思路是用MCP协议标准化企业内部系统的AI接入：
1. 将ERP系统封装为MCP服务器，提供订单查询、库存查询、生产进度查询等工具
2. 将MES系统封装为MCP服务器，提供设备状态查询、工艺参数查询、质量数据查询等工具
3. 将企业知识库封装为MCP服务器，提供文档检索、标准查询、案例查询等资源
4. 将OA系统封装为MCP服务器，提供审批流程、日程管理、消息通知等工具
效果：
• 任何支持MCP的Agent（如用LangGraph或CrewAI开发的Agent）都能直接调用这些企业系统能力
• 不需要为每个Agent单独开发系统集成，开发效率提升5倍以上
• MCP Host层统一管理权限，确保Agent只能访问授权范围内的数据和功能
• 企业内部系统的AI化改造从"项目制"变成了"平台化"，可持续演进
25.4 A2A协议——Agent的"同事"
25.4.1 A2A是什么
A2A（Agent2Agent Protocol，智能体间协议）由Google于2025年4月9日在Google Cloud Next上发布，初始有50+创始合作伙伴。2025年6月，Google将完整规范、SDK和开发者工具捐赠给Linux基金会，到2026年4月A2A v1.0达到GA时，已有150+组织支持，包括AWS、Microsoft、Salesforce、SAP、ServiceNow、Workday、IBM等巨头。
A2A就像Agent世界的"HTTP协议"——HTTP不管你后端是Rails还是Go，它只定义"请求-响应"的标准格式；A2A不管你的Agent是用LangGraph还是CrewAI开发的，它只定义Agent之间"发现对方、商量事情、把活派出去、把结果拿回来"的标准格式。
有了A2A，任何框架、任何厂商、任何公司开发的Agent都能互相协作，而且彼此不用共享内存、不用共享工具、不用暴露内部逻辑。
A2A解决的核心问题：
- Agent孤岛：不同厂商、不同框架开发的Agent无法互相通信，形成一个个孤岛
- 重复建设：每个企业都要从零构建完整的Agent能力，无法复用外部Agent的专业能力
- 协作复杂：Agent间协作需要定制化开发，接口不统一，维护成本高
- 安全风险：Agent间直接通信缺乏标准的安全认证和权限控制机制
25.4.2 A2A核心架构
A2A的核心结构包括：
- Agent Card（智能体名片）：JSON格式的元数据文档，发布在
/.well-known/agent.json，描述Agent的身份、能力、技能、端点、认证要求。其他Agent通过Agent Card发现和了解这个Agent能做什么。 - Task（任务）：Agent间协作的基本单位，一个Agent向另一个Agent发送Task请求，对方执行后返回结果。支持多轮状态编排，Task可以有状态（pending、working、completed、failed等）。
- Push Notifications（推送通知）：支持实时推送，Agent可以主动向其他Agent推送状态更新和结果通知，不需要轮询。
- Artifacts（产物）：Agent执行任务产生的输出结果，可以是文本、文件、结构化数据等。
A2A的通信模式：
- 请求-响应模式：一个Agent发送Task请求，另一个Agent同步返回结果
- 异步任务模式：一个Agent发送Task请求，对方返回Task ID，发起方可以后续查询Task状态或接收推送通知
- 流式输出模式：支持流式传输，Agent可以边执行边返回中间结果
25.4.3 A2A的产品意义
对AI产品经理来说，A2A的出现开启了"Agent经济"的新篇章：
- 能力市场化：企业可以将自己的专业能力封装为A2A Agent，对外提供服务，形成新的商业模式。例如：法律事务所提供合同审查Agent、会计师事务所提供财务分析Agent、咨询公司提供行业研究Agent
- 组合创新：产品经理可以像搭积木一样，组合不同专业领域的Agent，创造全新的产品和服务。例如：市场研究Agent+数据分析Agent+报告生成Agent=智能咨询产品
- 跨组织协作：企业间的Agent可以通过A2A安全协作，不需要暴露内部系统和数据。例如：品牌方的营销Agent可以直接调用代理商的投放Agent，实现跨组织的自动化营销
- 专业化分工：就像人类社会有专业分工一样，Agent世界也会形成专业化分工——有的Agent擅长法律、有的擅长财务、有的擅长编程，通过A2A协作完成复杂任务
- 安全可信：A2A v1.2引入了加密签名的Agent Card（JWS签名文档），确保Agent身份可信，防止伪造和钓鱼
2026年，某汽车制造商与上游零部件供应商构建了基于A2A协议的供应链协同系统：
• 汽车制造商的"采购Agent"通过A2A发现零部件供应商的"库存Agent"和"报价Agent"
• 采购Agent向报价Agent发送Task："请提供1000件某型号零件的报价和交货期"
• 报价Agent调用内部ERP系统计算价格和库存，返回报价结果
• 采购Agent比较多家供应商的报价后，向选中的供应商下单Agent发送采购订单Task
• 下单Agent创建内部销售订单，返回订单确认和预计交货期
• 生产过程中，供应商的"生产进度Agent"通过A2A Push Notifications主动向采购Agent推送生产进度
效果：
• 采购周期从平均7天缩短到4小时
• 不需要EDI等传统系统集成，新供应商接入时间从2周缩短到2天
• 双方不需要暴露内部系统，通过A2A Agent安全协作
• 整个过程可追溯、可审计，满足合规要求
25.5 AG-UI与ANP——Agent的"脸"和"通讯录"
25.5.1 AG-UI——Agent的用户交互标准
AG-UI（Agent Graphical User Interface）是专为Agent与前端UI交互设计的开放标准，解决了Agent输出如何在前端渲染的问题。
核心问题：传统的聊天UI只能展示文本消息，但Agent的输出可能是复杂的结构化数据（表格、图表、表单、卡片、按钮等），每个应用都要自己定义渲染逻辑，导致体验不一致、开发重复。
AG-UI的解决方案：
- 标准化消息格式：定义Agent输出的标准化消息格式，支持文本、结构化数据、UI组件等多种类型
- 组件化渲染：前端可以根据消息类型自动渲染对应的UI组件，不需要为每个Agent单独开发
- 交互反馈：支持用户对Agent输出进行交互（如点击按钮、填写表单、确认操作），交互结果反馈给Agent
- 状态同步：Agent的执行状态（思考中、执行中、等待输入等）可以实时同步到前端UI
产品意义：AG-UI让Agent产品的前端开发标准化，产品经理可以专注于交互设计，而不是纠结于技术实现。
25.5.2 ANP——Agent的网络发现协议
ANP（Agent Network Protocol，智能体网络协议）支持开放网络中Agent的发现和安全协作，基于W3C的去中心化标识符（DIDs）和JSON-LD图。
核心功能：
- 去中心化发现：Agent可以在开放网络中发现其他Agent，不需要中心化目录
- 安全身份：基于DIDs的去中心化身份，确保Agent身份可信、不可伪造
- 信任网络：Agent之间可以建立信任关系，形成信任网络，支持基于信誉的协作
- 隐私保护：Agent可以选择性地暴露能力和数据，保护隐私和商业机密
ANP与A2A的关系：A2A定义了Agent间通信的协议，ANP定义了Agent在开放网络中发现和建立信任的机制，两者互补，共同构成Agent互联的基础设施。
25.6 技术选型与产品设计建议
25.6.1 2026年Agent产品技术栈推荐
基于最新技术发展，AI产品经理在设计Agent产品时，推荐采用以下技术栈：
| 层级 | 推荐技术 | 选择理由 |
|---|---|---|
| Agent Harness | LangGraph（生产级）/ CrewAI（原型） | LangGraph生产就绪、状态管理强；CrewAI上手快、适合原型验证 |
| 工具接入 | MCP协议 | 事实标准，生态丰富，安全可控，避免重复开发 |
| Agent间协作 | A2A协议 | 开放标准，跨框架跨厂商，支持能力市场化和组合创新 |
| 前端交互 | AG-UI兼容组件 | 标准化渲染，体验一致，开发效率高 |
| 大模型 | 多模型策略 | 根据任务选择最合适的模型，避免厂商绑定，控制成本 |
| 可观测性 | LangSmith / OpenTelemetry | Agent执行追踪、调试、性能监控、成本分析 |
| 部署运行 | 容器化 + 云原生 | Docker/K8s部署，弹性伸缩，高可用 |
25.6.2 产品设计原则
1. 协议优先，框架其次
不要一开始就纠结选哪个框架，先想清楚你的Agent需要接入哪些工具（MCP）、需要与哪些Agent协作（A2A）。框架可以换，但协议决定了你的产品能不能融入生态。
2. 能力封装，标准化输出
将你的产品核心能力封装为标准的MCP工具和A2A Agent，让其他Agent也能调用。这不仅是技术选择，更是商业模式——你的能力可以通过Agent生态触达更多用户。
3. 人机协同，不要追求全自动
复杂业务场景中，完全自动化的Agent往往不可靠。设计时要考虑Human-in-the-loop，在关键节点引入人工审批和干预，LangGraph的Checkpointer和人工节点特性很好地支持这一点。
4. 可观测性是生产级的前提
Agent的执行过程是黑盒，如果没有完善的追踪和监控，出了问题无法排查。从第一天就要设计可观测性，包括执行追踪、状态监控、成本分析、错误告警。
5. 安全合规，从设计开始
Agent能访问企业数据和系统，安全风险巨大。MCP Host层的权限控制、A2A的身份认证、数据脱敏、操作审计等安全机制，要从产品设计阶段就考虑，而不是事后补丁。
25.6.3 过时技术避坑指南
1. AutoGPT / BabyAGI等"自主Agent"框架——2023年火爆，但2025年后热度大幅下降，核心能力已被LangGraph、CrewAI等新一代Harness吸收。新项目不要再用。
2. 传统LangChain的Chain抽象——SequentialChain、LLMChain等链式调用已被LangGraph的图编排取代。如果用LangChain生态，直接用LangGraph。
3. 自定义Function Calling集成——不要再为每个工具单独写Function Calling集成，用MCP协议标准化接入。
4. 自定义Agent间通信协议——不要自己设计Agent间通信接口，用A2A标准协议，融入生态。
5. ACP协议——已被合并到A2A，不要再作为独立协议使用。
6. 单一模型绑定——不要把产品绑定在单一模型上，2026年模型迭代极快，多模型策略才能保持竞争力和成本优势。
25.7 本章小结与实践思考
本章系统介绍了2025-2026年AI Agent技术栈的最新发展，包括Agent Harness框架（LangGraph、CrewAI、AutoGen、OpenAI Agents SDK）、MCP协议（Agent的手）、A2A协议（Agent的同事）、AG-UI（Agent的脸）、ANP（Agent的通讯录）。Agent技术已经从"框架之争"进入了"协议之治"的新时代，标准化的协议栈让Agent能够像微服务一样互联互通，开启了"Agent经济"的新篇章。
下一章我们将学习工具调用（Function Calling）原理与实战，深入了解Agent如何通过MCP等标准协议调用外部工具。
📝 本章练习（11题）
答案与解析请在 互动学习看板 中作答查看。
📚 AI产品经理实战训练营 课程目录（44 章）
- 第1章 AI产品经理是做什么的？和传统PM有什么区别？
- 第2章 2026年AI产品经理就业市场：哪些行业在招？薪资多少？
- 第3章 零经验转行AI产品经理的3条路径
- 第4章 AI产品全景图：从聊天机器人到Agent，一文搞懂
- 第5章 AI产品经理能力模型：你需要掌握哪些技能？
- 第6章 实战：拆解3个你每天在用的AI产品
- 第7章 大模型是什么？用大白话讲清楚
- 第8章 主流大模型对比：GPT-4o、Claude、DeepSeek、豆包、Kimi怎么选？
- 第9章 Prompt入门：写好提示词的5个原则
- 第10章 Prompt进阶：System Prompt、COT思维链、Few-shot示例
- 第11章 结构化输出：让大模型返回JSON、表格、代码
- 第12章 Prompt优化实战：从垃圾Prompt到高质量Prompt
- 第13章 大模型的"幻觉"问题：产品经理怎么应对？
- 第14章 实战：为一个智能客服设计完整Prompt体系
- 第15章 RAG是什么？为什么企业都在做知识库？
- 第16章 RAG工作原理：文档→分块→向量→检索→生成
- 第17章 向量数据库选型：Milvus、Pinecone、Chroma、pgvector怎么选？
- 第18章 Embedding模型选型：OpenAI、BGE、M3E、GTE对比
- 第19章 Reranker重排序：让检索结果更精准
- 第20章 查询改写与混合检索：提升召回率的实战技巧
- 第21章 知识库运营：文档治理、更新机制、效果监控
- 第22章 实战：从零搭建一个企业知识库（完整流程）
- 第23章 Agent是什么？和聊天机器人有什么区别？
- 第24章 Agent核心能力：感知、规划、工具调用、记忆
- 第25章 主流Agent框架与协议：Agent Harness、MCP、A2A全解析
- 第26章 工具调用（Function Calling）原理与实战
- 第27章 Agent记忆系统：短期记忆、长期记忆、向量记忆
- 第28章 多Agent协作：多个智能体怎么分工配合？
- 第29章 Agent评估体系：成功率、成本、延迟怎么监控？
- 第30章 实战：设计一个制造业生产异常处理Agent
- 第31章 AI产品需求分析：怎么识别真需求还是伪需求？
- 第32章 AI产品竞品分析：怎么调研和拆解竞品？
- 第33章 AI产品PRD撰写：技术可行性、数据需求、评估指标
- 第34章 AI产品原型设计：对话流、状态机、异常处理
- 第35章 AI产品数据指标体系：从DAU到模型准确率，全面监控
- 第36章 AI项目管理：从需求到上线的全流程管控
- 第37章 实战项目1：从零搭建制造业AI智能质检系统
- 第38章 实战项目2：从零搭建企业级AI知识库（RAG系统）
- 第39章 AI产品经理简历优化：让HR一眼看中你
- 第40章 项目经验包装：把普通项目讲成亮眼案例
- 第41章 AI产品经理面试常见问题：提前准备，从容应对
- 第42章 案例分析面试：用结构化思维征服面试官
- 第43章 薪资谈判：拿到你应得的报酬
- 第44章 入职前3个月：快速站稳脚跟，建立信任