1. LLM 基础
首先理解大模型能做什么、不能做什么。
产品经理不需要深入学习模型训练，但需要理解：
Token 和上下文窗口是什么；
Temperature 等参数的大致作用；
模型为什么会产生幻觉；
模型是否真的“理解”内容；
推理模型和普通模型的区别；
模型能力、成本、速度之间的关系。
这一阶段的目标不是会训练模型，而是能够判断：
这个需求到底适不适合用大模型？
2. Prompt Engineering 和 Context Engineering
Prompt Engineering 是：
怎样把任务要求说清楚。
Context Engineering 是：
在当前时刻，应该给模型哪些信息。
例如，做一个用户反馈分析功能，不只是写：
分析一下这些用户反馈。
而是需要提供：
产品背景；
用户类型；
反馈时间范围；
产品版本；
分类标准；
历史需求；
输出格式；
证据要求。
很多所谓 Agent 效果不好，实际问题并不是 Agent 不够智能，而是：
没有给它正确、完整、及时的上下文。
3. 结构化输出
这个模块很容易被忽略，但对产品落地非常重要。
模型不仅要输出自然语言，还要能够输出稳定的数据结构：
{ "category": "视频导出", "priority": "high", "affected_versions": ["3.2.1", "3.2.2"], "evidence": [], "recommendation": "" }
产品经理需要理解：
JSON Schema；
枚举值；
必填字段；
输出校验；
输出失败后的重试；
自然语言输出与结构化输出的区别。
因为只有结构化输出，AI 才容易和业务系统真正连接起来。
4. Tool Calling 与 MCP
Tool Calling 是 Agent 的重要基础。
它解决的是：
让模型不只是生成文字，还能选择和调用外部能力。
例如：
查询用户反馈 查询产品数据 搜索历史需求 创建 Jira 草稿 发送通知 读取网页 执行代码
产品经理需要理解的不是具体代码，而是工具的产品设计：
工具应该完成什么；
输入参数是什么；
返回结果是什么；
工具权限有多大；
哪些工具只能读取；
哪些工具会修改数据；
哪些调用必须人工确认。
5. RAG
RAG 解决的是：
如何让模型使用企业自己的知识和资料回答问题。
例如：
产品文档；
帮助中心；
用户反馈；
公司制度；
历史需求；
客服知识库；
技术文档。
但产品经理不必一开始就深入向量数据库算法，先理解完整链路：
文档切分 → 建立索引 → 根据问题检索 → 把检索结果放进上下文 → 模型生成答案 → 引用证据
重点关注：
检索出来的内容是否正确；
文档是否过期；
是否有权限隔离；
是否能给出引用；
没找到资料时应该怎么办；
RAG 和长期记忆有什么区别。
Tool Calling 和 RAG 的顺序不是绝对的，两者也可以并行学习。
6. Workflow
这是产品经理学习 AI 应用时非常关键的一层。
你需要理解：
怎样把多个模型调用、规则判断、工具操作和人工节点组成一个稳定流程。
例如：
获取用户反馈 → 清洗和去重 → LLM 分类 → 统计数量 → LLM 生成摘要 → 格式校验 → 人工确认 → 保存结果
这一阶段重点学习：
节点；
条件分支；
并行处理；
重试；
超时；
状态；
人工审批；
异常兜底。
很多业务需求做到 Workflow 就已经足够，不需要 Agent。
7. Agent
学完 Workflow，再学习 Agent，会更容易理解二者的真正区别。
Agent 重点不是“用了大模型”，而是：
模型可以根据目标和当前状态，动态决定下一步行动。
产品经理需要重点理解：
Agent 的目标是什么；
它能使用哪些工具；
什么叫任务完成；
最多执行多少步；
什么情况下应该停止；
什么情况下询问用户；
什么情况下请求人工审批；
怎样避免重复调用工具；
怎样避免无限循环；
怎样控制成本。
建议从受约束的单 Agent开始，而不是直接做万能 Agent。
8. Harness Engineering
这一层应该放在 Multi-Agent 之前。
因为 Harness Engineering 解决的是：
怎样给 Agent 建立一个稳定、可控、可观察的工作环境。
包括：
工具系统 上下文管理 记忆 Skills 任务状态 代码执行环境 错误恢复 权限控制 日志 评测 人工审批 成本限制 停止机制
简单来说：
模型决定怎么思考 Harness 决定它在什么环境中工作
没有好的 Harness，即使模型能力很强，Agent 也可能：
调错工具；
重复执行；
丢失任务状态；
无法恢复；
使用错误资料；
执行危险操作；
不知道什么时候停止。
因此，理解 Agent 之后，就应该学习怎样把 Agent 变成一个真正可上线的产品。
9. Multi-Agent
Multi-Agent 应该放到最后。
Multi-Agent 是把复杂任务拆成多个角色，例如：
主管 Agent ├── 用户研究 Agent ├── 数据分析 Agent ├── 竞品研究 Agent └── 报告 Agent
它适合以下情况：
子任务可以独立完成；
子任务需要不同工具；
子任务需要不同上下文；
可以并行执行；
单 Agent 的指令已经过于复杂。
但 Multi-Agent 也会带来很多问题：
Agent 之间信息传递失真；
工作重复；
成本快速增长；
不清楚谁负责最终结果；
调试难度增加；
错误会层层传播。
因此原则应该是：
单 Agent 能解决，就不要上 Multi-Agent。
贯穿以上所有学习节点的能力：
评测
成本
安全
权限
人工介入
评测：
Evaluation 不应该放在学习路线最后。
它应该从第一天就开始。
例如学 Prompt 时，就要比较：
哪个 Prompt 的分类准确率更高；
哪个输出格式更稳定；
哪个模型成本更低；
哪些问题容易出现幻觉。
学习 Agent 时，则需要评测：
任务完成率；
工具选择正确率；
平均调用次数；
证据是否充分；
是否会错误执行；
是否知道何时停止。
所以更准确的图应该是：
Evaluation 持续评测↓ LLM → Prompt / Context → 结构化输出 → Tool Calling → RAG → Workflow → Agent → Harness Engineering → Multi-Agent
一，LLM基础
1，什么是token；
概念：模型处理文本的基本单元，输入和输出都会先被拆成 Token。
计算：
标准模型：token = 输入 + 输出
推理模型：token = 输入 + 推理 + 输出
自然语言：查询近一天的用户数据，只返回用户名和 IP。
token分词：查询｜近｜一天｜的｜用户｜数据｜……
可能是一个字、半个词、完整单词、标点或空格，具体怎样切分取决于模型使用的分词方式。
2，token会对哪些因素有影响？
（1），模型能看到的内容长度（输入）、模型输出的内容长度；
（2），token越多，成本越高，影响的是请求成本；
（3），模型的请求时间；
（4），模型的准确率降低（幻觉增加）；
模型输入的token等于：System Prompt + User Prompt
根据token的概念延伸出一个重要的理论：
提供给模型的信息越多，不一定效果越好，但成本和延迟通常会更高。
原因是：
长上下文会导致模型：
注意力下降：上下文越长，模型越容易”分心”，无法抓住重点；
信息召回能力退化： 模型从你给它的那一大堆输入里，找不到或者漏掉了你想要的答案；
「1」何为大模型的召回能力：
给大模型输入很长的内容，让大模型从输入的这些内容中检索或总结，检索或总结的越准确，说明召回能力越强。
「2」还有一个维度，就是从模型训练数据（模式知识）中回忆（概率选择）起学过的知识。
「3」大模型从输入的长文本中查询的准确率越高，说明大模型的召回率越高。
提供给模型太多的的token或输入内容的时候，重要信息被淹没、模型注意力分散，所以容易出现幻觉，导致输出不够准确或者错误。
所以，在给模型输入的时候，给模型的往往不是更长的上下文，而是有多少有用的上下文。
3，模型是没有记忆的；
模型不是永久记住了某件事，而是应用在下一次请求时，又把相关信息放回了上下文。
所以，上下文窗口通常包含以下内容：
System Prompt + 用户当前的对话 + 对话历史 + 长期记忆 + RAG资料信息(附件/文件内容) + assistant + tool
4，模型的参数；
（1），Temperature：控制模型输出随机程度的数值，数值越低，输出随机程度越低，重复性越高；
通常情况下：
低数值的Temperature，用于内容提取、内容格式化、内容分类；
高数值的Temperature，用于内容生成、创造性较强、不确定性更高的内容生成；
Temperature只是提高模型输出的稳定性，不是内容的真实性。
（2），max_output_tokens，允许模型输出的长度，主要是控制成本和回答长度。
4，模型的幻觉；
（1），什么是模型的幻觉？
模型生成的内容看似合理、表达通顺流畅，但内容错误，答案没有依据。
并且，幻觉率是每个大模型都存在的问题，且不能完全消除；
（2），为什么模型会出现幻觉？
「1」，模型生成内容的时候，是通过训练的知识，有依据的进行概率选择，而不是通过数据库进行查询；这里的一句就是模型训练时的知识。
「2」，如果模型训练的数据本身就是错误的，那么它生成的东西必定有幻觉；
「3」，用户给予模型的上下文信息的缺失，也会导致模型出现幻觉；
「4」，用户给予模型的上下文信息出现歧义或错误；
「5」，模型本身有讨好型风格，所以对于不知道的问题也会进行编造。
（3），如何减少模型的幻觉率？
「1」，提供可靠、全面的上下文；
「2」，要求模型引用证据，给出出处；
「3」，告知模型，允许模型对于不知道的问题回答“不知道”；
个人理解：所以，大模型有一定的理解、逻辑推理能力，让大模型做一些总结、归纳、提炼等这些准确度可能比让大模型去创作一篇文章、写一篇论文更加准确。原因是大模型的对于知识的召回能力总会有误差、大模型也总是有幻觉。