目录

一、大模型基础

1. 什么是大模型（LLM）？

2. 大模型的训练过程是怎样的？（预训练 → 微调 → RLHF）

3. 大模型的"涌现能力"是什么意思？

4. Token 是什么？为什么大模型有上下文长度限制？

5. Temperature、Top-P 等参数是什么意思？

6. 大模型的"幻觉"问题是什么？怎么缓解？

7. 大模型能记住之前的对话吗？（记忆 vs 上下文窗口）

8. 开源模型 vs 闭源模型有什么区别？各有什么代表？

9. 大模型相关概念

10. 大模型应用到B端、C端的异同

二、Prompt（提示词）

10. 什么是 Prompt？为什么 Prompt 很重要？

11. Prompt Engineering 有哪些常用技巧？

12. System Prompt vs User Prompt 的区别？

13. Few-shot、Zero-shot、Chain-of-Thought 分别是什么？

三、Agent（智能体）

14. 什么是 AI Agent？和普通对话机器人有什么区别？

15. Agent 的核心架构是什么？（感知→规划→执行→反馈）

16. Agent 是怎么调用工具的？（Function Calling / Tool Use）

17. 单 Agent vs 多 Agent 协作有什么区别？

18. Agent 的"记忆"机制有哪些？（短期/长期/外部存储）

19. Agent 的规划能力是怎么实现的？（ReAct、Plan-and-Execute）

20. Agent 有哪些典型应用场景？

21. Agent 的可靠性问题：为什么 Agent 有时会"跑偏"？

四、Skill（技能）

22. 什么是 Skill？和 Plugin/Tool 有什么区别？

23. Skill 的典型结构包含哪些部分？

24. Skill 和 Prompt 的本质区别是什么？

25. Skill 是怎么被触发/匹配的？

26. 一个 Skill 能调用另一个 Skill 吗？

27. 如何开发一个自己的 Skill？

28. Skill 的安全性怎么保障？

五、三者关系与协作

29. 大模型、Agent、Skill 三者是什么关系？

30. 一个完整的 AI 应用是怎么把三者串起来的？

31. 没有 Skill 的 Agent 和有 Skill 的 Agent 差别在哪？

32. Skill 是否可以脱离 Agent 单独使用？

33. 为什么说"大模型是大脑，Skill 是手脚，Agent 是完整的人"？

六、实际应用与选型

34. 企业落地 AI Agent 有哪些常见模式？

35. 什么场景适合用 Prompt 解决？什么场景需要上 Skill/Agent？

36. Agent 平台/框架有哪些？（LangChain、AutoGPT、Dify、Coze 等）

37. 如何评估一个 Agent/Skill 的效果好不好？

38. AI Agent 目前的局限性是什么？未来方向在哪？

---

一、大模型基础

1. 什么是大模型（LLM）？

大模型（Large Language Model，简称 LLM）是一种基于深度学习的人工智能模型，通过在海量文本数据上训练，学会了理解和生成人类语言。

核心特点：

特征	说明
参数规模大	通常包含数十亿到数万亿个参数（可理解为"神经连接"的数量）
训练数据多	学习了互联网上大量的书籍、网页、代码等文本
通用能力强	不是为单一任务设计，而是具备多种语言能力

类比理解： 如果把传统 AI 比作"专科医生"（只会看一种病），大模型就是"全科医生"——它什么都懂一点，而且很多事情做得还不错。

大模型能做什么？

• 文本生成：写文章、写代码、写邮件

• 理解分析：总结文档、分析情感、提取信息

• 对话交互：像人一样聊天、回答问题

• 推理判断：逻辑推理、数学计算、方案比选

常见代表：

模型	比别人强在哪	比别人弱在哪	最适合干啥
GPT-5/4o	综合最均衡，没有明显短板；插件和工具生态远超其他所有模型	贵，中文不如国产模型地道	什么都要做、要求生态完善
Claude 4	代码质量比GPT还高，写作比所有模型都优雅，最听话（给啥指令照做）	不能生成图片，比GPT还贵，通用聊天没GPT灵活	专业写代码、写长文
Gemini 3.1 Pro	推理能力超过Claude和GPT，多模态（图/视频/音频）理解最强，价格只有GPT的1/14	中文表达不如国产，创意写作不如Claude和GPT	看图看视频、复杂推理、要省钱
豆包 2.0 Pro	国产综合第一（SuperCLUE全球前五），多模态最全面（文/图/音/视频），免费额度多，响应快，月活最高	数学和代码不如DeepSeek，深度推理不如Claude	日常办公、中文对话、内容创作、轻量任务
Kimi K2.6	长文本处理国产第一（200万字），Agent自动化能力超过GPT，代码能力开源最强	通用问答和闲聊不如GPT/Claude，知名度和生态不如头部	超长文档、自动化流水线、长程编码
DeepSeek-R1	数学/推理比GPT强，价格只有GPT的1/10	不擅长看图/生成图，日常聊天不如GPT自然	解题、逻辑推理、预算有限
DeepSeek-V3	综合能力接近GPT，但价格是GPT的1/30+，开源可自己部署	英文和创意不如GPT/Claude	要GPT级能力但不想花那么多钱
Qwen-Max	中文理解和表达比所有海外模型都好，代码接近Claude水平	英文和创意不如GPT，海外工具集成少	中文为主的工作场景
Llama 3.1	最自由（完全开源、随便改），社区资源最多	性能已被DeepSeek-V3和Kimi超过，中文远不如国产	想自己魔改模型的技术团队

选型口诀： 全能但贵选GPT → 写码选Claude → 推理强且省钱选Gemini → 长文本选kimi → 开源通用选DeepSeek-V3 → 中文选Qwen → 研究微调选Llama

大模型之所以引发行业变革，核心在于它改变了 AI 的使用方式——从"每个任务训练一个模型"变成了"一个模型适配多种任务"，大幅降低了 AI 应用的门槛。

---

2. 大模型的训练过程是怎样的？（预训练 → 微调 → RLHF）

大模型的训练通常分为三个阶段，就像培养一个人才：先通识教育，再专业深造，最后社会实践。

阶段一：预训练（Pre-training）—— "读万卷书"

• 用海量文本（数万亿 Token）训练模型

• 核心任务：预测下一个词（Next Token Prediction）

• 类比：婴儿通过大量"听"来学会语言规律

• 耗时最长、成本最高（可能花费数千万美元）

阶段二：有监督微调（SFT / Fine-tuning）—— "专业培训"

• 用人工标注的高质量问答对进行训练

• 让模型学会"怎么好好回答问题"，而不是只会"续写文本"

• 类比：毕业生进入公司后的岗前培训，学习规范化的输出方式

阶段三：RLHF（Reinforcement Learning with Human Feedback，人类反馈强化学习）—— "社会打磨"

• 人类对模型的多个回答进行排序打分

• 训练一个"奖励模型"来代表人类偏好

• 用强化学习（Reinforcement Learning, RL，通过试错的方式来学习）让模型输出更符合人类期望的内容

• 类比：新员工根据用户反馈不断优化服务态度和质量

三阶段对比：

阶段	目标	数据量	成本
预训练	学习语言知识	万亿 Token	极高
微调	学习任务格式	万~十万条	中等
RLHF	对齐人类偏好	千~万条标注	较高

这三个阶段缺一不可：预训练给了模型"知识"，微调给了"技能"，RLHF 给了"价值观"。

---

3. 大模型的"涌现能力"是什么意思？

涌现能力（Emergent Abilities）是指当模型规模（参数量）达到某个临界点时，突然表现出小模型完全不具备的能力。这种现象不是线性增长的，而是"量变引起质变"。

类比理解：

• 水加热到 99°C 还是液态，到 100°C 突然变成蒸汽——这就是涌现

• 小孩认识了足够多的字之后，突然能"自己读懂故事"——不是教的，是涌现的

涌现能力的典型表现：

能力	说明	小模型表现
思维链推理	分步骤解题	完全不会
代码生成	写出能运行的代码	胡乱拼凑
多步数学	解复杂应用题	基本随机
类比迁移	在新领域举一反三	无法实现

为什么会涌现？

目前学界还没有完全统一的解释，主流观点包括：

1. 信息压缩理论：大模型在压缩海量信息的过程中，被迫学会了深层的抽象规律

2. 组合效应：大量简单能力的组合在某个规模节点产生了质的飞跃

3. 评测阈值假说：能力一直在渐进增长，但评测方式有阈值，导致看起来像"突然出现"

对从业者的启示：

• 不要用小模型的表现推断大模型能做什么

• 大模型的能力边界仍在探索中，保持开放心态

• 涌现能力也意味着不可预测性，需要做好安全防护

---

4. Token 是什么？为什么大模型有上下文长度限制？

Token 是什么？

Token 是大模型处理文本的最小单位。它不完全等于"字"或"词"，而是模型自己学到的一种分割方式。

Token 切分示例：

文本	Token 数（约）	说明
"Hello world"	2	常见词各算 1 个
"我爱北京天安门"	4-7	中文通常 1-2 字一个 Token
"GPT-4"	3	特殊字符会额外切分

经验法则：

• 英文：1 个 Token ≈ 0.75 个单词（约 4 个字符）

• 中文：1 个 Token ≈ 1-2 个汉字

为什么有上下文长度限制？

大模型使用 Transformer （神经网络模型，主要用于自然语言处理任务）架构，其核心的"注意力机制"（Attention，重点关注文本中关联性强的部分，同时支持并行计算）需要计算每个 Token 与所有其他 Token 的关系：

1. 计算复杂度：注意力计算量与 Token 数量的平方成正比（O(n²)），上下文越长，计算资源消耗越大

2. 显存限制：每个 Token 的注意力权重都要存在 GPU 显存里，长度翻倍，显存消耗翻 4 倍

3. 训练限制：模型训练时使用固定长度，超出训练长度的推理效果会急剧下降

常见模型的上下文窗口：

模型	上下文长度
GPT-3.5	4K / 16K
GPT-4	8K / 128K
Claude 3	200K
Gemini 1.5	1M+

对实际使用的影响：

• 对话轮次多了，早期内容会被"遗忘"（超出窗口）

• 长文档分析需要分段处理或使用长上下文模型

• Token 数直接影响 API 调用费用

---

5. Temperature、Top-P 等参数是什么意思？

这些参数控制模型生成文本时的"随机性"和"创造性"，就像调节一个人说话时的"放飞程度"。

Temperature（温度）

控制输出的随机程度：

值	效果	适合场景
0	完全确定性，每次输出一样	数据提取、事实问答
0.3-0.7	适度多样性	日常对话、文本改写
1.0+	高度随机、更有创意	创意写作、头脑风暴

类比： Temperature 就像给 AI 灌酒——越高越"放飞自我"，越低越"一板一眼"。

Top-P（核采样）

从概率最高的 Token 中，累积概率达到 P 值时截断：

• Top-P = 0.1：只从最可能的少数几个词中选

• Top-P = 0.9：从很多可能的词中选（更多样）

• Top-P = 1.0：考虑所有可能的词

Temperature vs Top-P：

两者都控制随机性，但方式不同：

• Temperature 改变整个概率分布的"平坦程度"

• Top-P 直接砍掉低概率的候选词

实际建议：通常调一个就够了，不建议同时大幅调整两个。

其他常见参数：

参数	作用
Max Tokens	限制输出最大长度
Frequency Penalty	降低重复词出现的概率
Presence Penalty	鼓励模型谈论新话题
Stop Sequences	遇到特定文本时停止生成

选参建议：

• 需要精准答案 → Temperature=0，Top-P=1

• 需要创意输出 → Temperature=0.8-1.2，Top-P=0.9

• 需要稳定又不死板 → Temperature=0.4，Top-P=0.95

---

6. 大模型的"幻觉"问题是什么？怎么缓解？

什么是幻觉（Hallucination）？

大模型"幻觉"是指模型生成的内容看起来很流畅、很自信，但实际上是错误的、编造的或与事实不符的。就像一个很会"编故事"的人，说得头头是道但内容是假的。

幻觉的典型表现：

类型	例子
编造事实	杜撰不存在的论文、人物、事件
张冠李戴	把 A 的成就安到 B 头上
数据错误	编造统计数字、日期
逻辑矛盾	前后说法不一致
伪引用	生成格式正确但内容虚构的引用

为什么会产生幻觉？

1. 训练目标：模型的核心目标是"生成流畅文本"而非"保证正确"

2. 概率本质：模型是基于概率选下一个词，不是从知识库查询事实

3. 知识截止：训练数据有时间截止点，之后的信息一无所知

4. 过度泛化：模型有时会把多个概念错误地"混搭"在一起

缓解方法：

方法	说明	效果
RAG（检索增强）	先检索相关文档，再让模型基于文档回答	⭐⭐⭐⭐⭐
设定角色约束	Prompt 中明确要求"不确定时说不知道"	⭐⭐⭐
多轮验证	让模型自我检查或多模型交叉验证	⭐⭐⭐⭐
降低 Temperature	减少随机性，让输出更保守	⭐⭐⭐
结构化输出	要求附来源、加置信度	⭐⭐⭐
人工审核	关键场景下人类把关	⭐⭐⭐⭐⭐

核心原则： 不要盲信大模型的输出，尤其是涉及事实、数据、法律、医疗等领域。把大模型当"实习生"——能力强但需要 review。

---

7. 大模型能记住之前的对话吗？（记忆 vs 上下文窗口）

简短回答：大模型本身没有记忆，但可以通过工程手段实现"记忆"效果。

本质原理：

大模型是"无状态"的——每次调用都是一次全新的推理。它"记住"之前对话的方式，是把历史对话作为输入的一部分重新发送给模型。

类比理解：

• 大模型像一个每 5 分钟就失忆的天才

• 每次对话时，助手都会把"之前聊了啥"的笔记递给他

• 他不是真的记住了，而是看了笔记后"假装"记住了

上下文窗口 ≠ 记忆：

对比项	上下文窗口	真正的记忆
容量	有限（几千到几十万 Token）	理论上无限
持久性	单次会话内	跨会话持久
选择性	被动接收全部内容	主动筛选重要信息
消耗	越长越贵、越慢	检索成本相对固定

工程方案让模型"有记忆"：

1. 滑动窗口：保留最近 N 轮对话，丢弃更早的

2. 摘要压缩：把早期对话压缩成摘要放在上下文开头

3. 向量数据库：把历史对话存入向量库，需要时检索相关片段

4. 显式记忆文件：像 OpenClaw 这样，用文件记录重要信息，每次启动时读取

对产品设计的启示：

• 不要假设用户知道"AI 记不住"——要做好预期管理

• 长对话场景需要设计记忆策略，否则早期信息会丢失

• 跨会话记忆是差异化体验的关键，但要注意隐私合规

---

8. 开源模型 vs 闭源模型有什么区别？各有什么代表？

核心区别：

维度	开源模型	闭源模型
代码/权重	公开可下载	仅提供 API
部署方式	可本地/私有化部署	只能调用厂商接口
数据安全	数据不出本地	数据发送到厂商服务器
定制能力	可自由微调	受限于厂商提供的接口
使用成本	硬件投入高，推理成本可控	按 Token 付费
性能水平	追赶中，部分场景已持平	通常领先（尤其推理能力）
迭代速度	社区驱动，百花齐放	厂商主导，节奏可控

闭源模型代表：

模型	厂商	特点
GPT-4o	OpenAI	综合能力最强之一
Claude 3.5	Anthropic	长文本、安全对齐
Gemini 1.5	Google	超长上下文
文心 4.0	百度	中文优化

开源模型代表：

模型	厂商	特点
LLaMA 3	Meta	生态最完善
Qwen2	阿里	中文能力强
DeepSeek	DeepSeek	推理/代码突出
Mistral	Mistral AI	小而精，推理快
GLM-4	智谱 AI	中英双语

选型建议：

• 选闭源：追求最佳效果、快速验证 MVP、团队无 GPU 资源

• 选开源：数据安全要求高、需深度定制、大规模调用成本敏感

• 混合策略：简单任务用开源降本，复杂任务用闭源保效果

趋势： 开源模型与闭源模型的差距在快速缩小，2024-2025 年开源模型在很多场景已经"够用"了。

---

9. 大模型相关概念

概念	本质
Prompt Engineering（提示工程）	研究如何组织指令、上下文、约束条件，让模型输出更准确、更有用。 常见技巧： 明确角色：「你是一个资深数据分析师…」 给出约束：「用表格形式输出，不超过 200 字」 分步引导：「第一步…第二步…」 提供示例（这就涉及 Few-shot 了 👇）
Few-shot（少样本提示）	给几个例子，让 AI 学会你想要的格式/逻辑
Context Window（上下文窗口）	模型的"工作台"大小。可以理解为 AI 的"工作记忆容量"——你发的消息、历史对话、系统指令，全都要塞进这个窗口里。超出部分模型就"看不见"了。
RAG（Retrieval-Augmented Generation，检索增强生成）	给模型配一个"外部图书馆"。先从外部知识库"搜"相关内容，再喂给模型生成回答。解决的核心问题：模型知识有截止日期，且 Context Window 有限，不可能把所有资料都塞进去。
Function Calling（函数调用）	给模型装上"手"去执行操作。模型本身只能生成文字，但通过 Function Calling，它可以决定调用哪个工具、传什么参数，由外部系统执行后把结果返回给它。
Memory Mechanism（记忆机制）	给模型一个"笔记本"跨对话记事，实现方式：对话历史拼接、摘要记忆、外部存储
Chain of Thought（CoT）	让模型"一步步想"，提升推理能力
Multi-modal（多模态）	模型能处理文本+图片+音频+视频
Vector Database（向量数据库）	在大模型语境下，向量就是一段文本被转换成的一串数字（通常几百到几千维），用来表示这段文本的"语义含义"。 代码块 "今天天气真好" → [0.12, -0.45, 0.78, 0.33, ..., 0.56] （比如1536个数字） "今日阳光明媚" → [0.11, -0.44, 0.77, 0.34, ..., 0.55] （跟上面很接近！） "数据库性能优化" → [0.89, 0.23, -0.61, 0.02, ..., -0.33] （跟上面差很远） 意思相近的文本 → 向量在空间中距离近 意思无关的文本 → 向量在空间中距离远
MCP（Model Context Protocol，模型上下文协议）	是一个开放标准协议，用来解决一个核心问题：让大模型能够标准化地连接外部数据源和工具。 Skill 定义了"什么时候用、怎么用"，MCP 定义了"怎么连接和通信"

---

10. 大模型应用到B端、C端的异同

维度	共性
底层技术	都基于同样的 LLM 能力（理解、生成、推理）
核心价值	都是用 AI 替代/辅助人的重复性脑力劳动
关键挑战	都面临幻觉、延迟、成本控制问题
交互形式	都倾向对话式/自然语言交互
评估难度	输出质量难量化，都需要人工+自动评估体系

🔀 核心差异

① 用户预期与容错度

	C 端	B 端
用户	普通消费者	企业员工/专业人员
容错度	相对宽容，"好玩"就行	极低，错一次可能影响业务决策
预期	快、好用、有趣	准确、可控、可追溯
典型反应	"AI说错了，算了"	"这个数据不对，谁负责？"

② 产品设计重心

	C 端	B 端
核心指标	DAU、留存、互动时长	效率提升、准确率、覆盖率
设计重心	体验流畅、降低门槛、情绪价值	流程嵌入、权限管控、审计留痕
交互模式	开放式对话为主	结构化任务为主（表单+AI辅助）
失败处理	给个兜底回复就行	必须明确告知"不确定"或降级人工

③ 知识与数据

	C 端	B 端
知识来源	通用知识（互联网）	企业私有知识（文档、流程、数据）
数据敏感性	用户隐私（合规即可）	商业机密+用户隐私（双重约束）
RAG 需求	弱（通用知识够用）	强（必须接企业知识库）
时效性	中等	高（业务数据实时变化）

④ 部署与成本

	C 端	B 端
并发量	巨大（百万级用户）	可控（几百~几万员工）
成本敏感度	极高（单次调用×海量用户）	相对可承受（按工位/license收费）
模型选择	倾向轻量/蒸馏模型控成本	可用更强模型追求质量
部署方式	公有云 API	私有化部署需求强（数据安全）

⑤ 落地路径

	C 端	B 端
切入点	独立AI产品（ChatGPT、豆包）	嵌入现有工作流（Copilot模式）
价值验证	用户增长、付费转化	人效提升可量化（省了多少人/时）
推广方式	病毒传播、社交裂变	自上而下推行+培训
迭代节奏	快速AB测试	需求调研→POC→灰度→全量

---

🎯 一句话总结

C端追求"让用户爽"，是"锦上添花" B端追求"让业务对"，是"流程再造"

---

二、Prompt（提示词）

10. 什么是 Prompt？为什么 Prompt 很重要？

Prompt 就是你给大模型的输入指令——你怎么"问"，决定了模型怎么"答"。

类比理解：

• Prompt 就像给一个超级实习生布置任务——你说得越清楚，他做得越好

• 同一个大模型，不同的 Prompt 可能产出天壤之别的结果

为什么 Prompt 很重要？

1. 大模型是"被动"的：它不会主动猜你要什么，你的 Prompt 就是它唯一的信息来源

2. 决定输出质量：同样的问题，换个问法，答案质量可能翻倍

3. 替代传统编程：Prompt 本质上是一种"自然语言编程"，用语言控制 AI 行为

4. 成本最低的优化手段：不需要训练模型、不需要写代码，改几个字就能大幅提升效果

Prompt 的基本组成：

元素	说明	示例
角色设定	告诉模型"你是谁"	"你是一位资深产品经理"
任务描述	告诉模型"做什么"	"请分析以下需求的优先级"
上下文	提供背景信息	"我们是一个 B2B SaaS 产品..."
输出格式	规定回答形式	"请用表格形式输出"
约束条件	限制边界	"不超过 200 字"

一个事实： 目前行业中，很多"AI 效果不好"的问题，本质是"Prompt 写得不好"的问题。学会写好 Prompt，是每个互联网从业者的必备技能。

---

11. Prompt Engineering 有哪些常用技巧？

Prompt Engineering（提示词工程）是系统化地设计和优化 Prompt 的方法论。以下是最实用的技巧：

核心技巧：

技巧	说明	示例
明确角色	给模型一个身份	"你是10年经验的数据分析师"
分步指令	把复杂任务拆成步骤	"第一步...第二步...第三步..."
提供示例	给出期望的输入输出样本	"例如：输入 X → 输出 Y"
限定格式	指定输出结构	"用 JSON/表格/Markdown 格式输出"
设定约束	明确边界和限制	"如果不确定，请说'我不确定'"

进阶技巧：

1. Chain-of-Thought（思维链）：加一句"请一步步思考"就能显著提升推理能力

2. Few-shot 示例：给 2-3 个标准样例，模型就能学会你要的模式

3. 负面约束：告诉模型"不要做什么"往往比"要做什么"更有效。如"不要编造数据，不确定时明确说明"

4. 输出前置：让模型在回答前先"思考"或"列出关键信息"

5. 迭代优化：先写一个基础版 Prompt → 看输出效果 → 针对性改进 → 反复迭代

常见反模式（要避免的）：

• ❌ 太模糊："帮我写点东西"

• ❌ 太长没重点：信息堆砌但缺乏结构

• ❌ 矛盾指令：同时要求"简洁"和"详细"

• ❌ 假设模型知道上下文：不提供必要背景

实践建议：建议团队建立 Prompt 模板库，把验证有效的 Prompt 沉淀下来复用。

---

12. System Prompt vs User Prompt 的区别？

在大模型 API 调用中，消息通常分为三种角色：System、User、Assistant。其中 System Prompt 和 User Prompt 的区别至关重要。

直观对比：

维度	System Prompt	User Prompt
谁设置	开发者/产品设计者	终端用户
目的	定义 AI 的角色、行为规范	提出具体问题或任务
可见性	通常对用户隐藏	用户直接输入
持久性	整个会话保持不变	每轮都会变化
优先级	通常更高（但非绝对）	在 System 框架内发挥

类比理解：

• System Prompt = 公司给员工的《岗位手册》和《行为准则》

• User Prompt = 客户每次提出的具体需求

System Prompt 的典型内容：

你是一位美团的客服助手，你需要：
1. 使用友好、专业的语气
2. 只回答与美团服务相关的问题
3. 不确定时引导用户联系人工客服
4. 不讨论政治、宗教等敏感话题
5. 回答控制在 200 字以内

实际应用建议：

1. System Prompt 要稳定：不要频繁修改，它定义了 AI 的"人格"

2. 权限边界：用 System Prompt 设置"不能做什么"比"能做什么"更重要

3. 安全防护：在 System Prompt 中设置防注入规则（防止用户通过巧妙 Prompt 突破限制）

4. 不要过度依赖：System Prompt 不是"万能防线"，用户仍可能通过各种方式绕过

---

13. Few-shot、Zero-shot、Chain-of-Thought 分别是什么？

这三个是最常用的 Prompt 策略，掌握它们能显著提升模型输出质量。

Zero-shot（零样本）

直接问，不给示例：

请判断以下评论的情感是正面还是负面：
"这个产品太难用了，浪费我时间"

• 优点：简单快速

• 缺点：复杂任务效果不稳定

Few-shot（少样本）

先给几个示例，再提出问题：

示例1：评论"超好吃！" → 正面
示例2：评论"等了一小时" → 负面
示例3：评论"还行吧" → 中性

请判断：评论"包装很精致，味道一般" → ?

• 优点：模型能精准理解你的"标准"

• 缺点：占用上下文空间、需要准备示例

Chain-of-Thought（思维链 / CoT）

要求模型"展示思考过程"：

请一步步思考：
小明有5个苹果，给了小红2个，又买了3个，最后有几个？

第一步：小明原有5个
第二步：给了小红2个，剩5-2=3个
第三步：又买了3个，变成3+3=6个
答案：6个

三者对比：

策略	是否需要示例	适用场景	效果
Zero-shot	不需要	简单任务、常识问题	⭐⭐⭐
Few-shot	需要 2-5 个	分类、格式化、风格模仿	⭐⭐⭐⭐
CoT	不强制	推理、数学、复杂判断	⭐⭐⭐⭐⭐

组合使用效果更佳：

• Few-shot + CoT：给出带思考过程的示例，效果最好

• Zero-shot CoT：只加一句"Let's think step by step"就能显著提升推理能力

---

三、Agent（智能体）

14. 什么是 AI Agent？和普通对话机器人有什么区别？

一句话理解： AI Agent 是一个能自主思考、做决策、采取行动的"AI 员工"，而普通对话机器人只是一个"问答窗口"。

核心区别：

维度	普通对话机器人	AI Agent
交互模式	一问一答	接受目标，自主完成
能否使用工具	不能	能调用搜索、数据库、API等
有无记忆	通常没有	有短期/长期记忆
能否规划	不能	能拆解任务、分步执行
典型场景	客服FAQ	自动写报告、管理日程、数据分析

打个比方：

• 普通聊天机器人 = 前台接待（你问什么答什么）

• AI Agent = 项目经理（你给个目标，它自己拆任务、找资源、推进度）

举个例子：

你对普通机器人说"帮我订周五的会议室"，它只会告诉你怎么操作。

你对 Agent 说同样的话，它会：查你的日历空闲时间→搜索可用会议室→预订→发会议邀请→告诉你结果。

Agent 的本质是从"回答问题"升级到"解决问题"。它不仅有大脑（大模型），还有手脚（工具调用）和记忆（上下文管理），能像一个真正的助手一样端到端完成任务。

---

15. Agent 的核心架构是什么？（感知→规划→执行→反馈）

Agent 的运作逻辑可以类比为一个人接到任务后的思考过程，核心是四个环节的循环：

感知（Perception）→ 规划（Planning）→ 执行（Action）→ 反馈（Observation）
         ↑                                                    |
         └────────────────────────────────────────────────────┘

四个环节详解：

环节	做什么	类比
感知	接收用户指令、读取环境信息	听懂老板说了什么
规划	拆解目标、制定步骤、决定先做什么	列出 To-Do List
执行	调用工具、查数据、写文档等具体操作	动手干活
反馈	观察执行结果，判断是否完成、是否需要调整	检查成果，决定下一步

关键点：这是一个循环，不是单次流程。

比如你让 Agent "帮我分析上周的用户活跃数据并写成报告"，它的实际运行可能是：

1. 感知：理解目标是"分析+写报告"

2. 规划：拆成"取数→分析→生成报告"三步

3. 执行：调用数据查询工具拉数据

4. 反馈：发现数据有异常值，决定先排查原因

5. 再规划：增加"异常排查"步骤

6. 再执行：查询相关日志...

这种"思考-行动-观察"的循环，是 Agent 区别于简单 Bot 的核心能力。

---

16. Agent 是怎么调用工具的？（Function Calling / Tool Use）

核心机制：Function Calling（函数调用）

大模型本身只能输出文本，但通过 Function Calling 机制，它可以输出一段"我想调用某个工具"的结构化指令，由外部系统真正执行。

运作流程：

用户："帮我查一下明天北京天气"
   ↓
大模型思考：需要调用天气API
   ↓
大模型输出：{"function": "get_weather", "params": {"city": "北京", "date": "明天"}}
   ↓
系统执行：真正调用天气API，拿到结果
   ↓
结果返回给大模型：{"temp": "28°C", "weather": "多云"}
   ↓
大模型生成最终回答："明天北京28°C，多云，建议带把伞以防万一。"

类比理解：

大模型就像一个很聪明但没有手的大脑。Function Calling 相当于给它装了一双手——它知道该做什么，然后通过"手"去实际操作。

常见的工具类型：

工具类型	示例
搜索引擎	查实时信息
数据库查询	拉业务数据
文件操作	读写文档
API 调用	发消息、订会议室
代码执行	跑 Python 脚本

关键细节： 大模型决定"调用什么工具、传什么参数"，但不直接执行。执行由外部系统完成，结果再喂回大模型做最终判断。这种设计既发挥了大模型的推理能力，又保证了安全可控。

---

17. 单 Agent vs 多 Agent 协作有什么区别？

单 Agent： 一个 Agent 处理所有事情，适合简单、线性的任务。

多 Agent： 多个 Agent 各司其职、协同完成复杂任务，像一个团队。

维度	单 Agent	多 Agent 协作
架构复杂度	低	高
适用场景	单一任务、流程清晰	复杂任务、需要多种专业能力
优势	简单直接、调试方便	专业分工、并行处理、可扩展
劣势	能力有限、容易过载	协调成本高、可能出现冲突
类比	全栈工程师一人干	产品+设计+开发+测试团队协作

多 Agent 的典型协作模式：

1. 主从模式：一个"管理者 Agent"分配任务给"执行者 Agent"

2. 流水线模式：Agent A 完成后传给 Agent B，再传给 Agent C

3. 辩论模式：多个 Agent 对同一问题给出不同方案，由裁判 Agent 选择最优

实际例子：

让 AI 自动完成一篇深度分析报告：

• Agent A（研究员）：搜索和整理资料

• Agent B（分析师）：做数据分析和归因

• Agent C（写手）：把分析结论写成报告

• Agent D（审稿人）：检查质量、提出修改意见

目前行业趋势是：简单场景用单 Agent，复杂场景用多 Agent 编排。但多 Agent 的可靠性和调试成本仍然是挑战。

---

18. Agent 的"记忆"机制有哪些？（短期/长期/外部存储）

Agent 要像人一样工作，就必须有"记忆"。否则每次对话都从零开始，无法处理连续任务。

三种记忆类型：

类型	作用	实现方式	类比
短期记忆	当前对话的上下文	对话历史（Context Window）	工作记忆/便签纸
长期记忆	跨对话的持久信息	向量数据库、文件存储	笔记本/日记
外部存储	超大规模的知识库	RAG、数据库检索	图书馆/档案室

短期记忆的局限：

大模型的上下文窗口有限（比如 128K tokens），对话太长就会"忘记"前面的内容。解决方案包括：摘要压缩、关键信息提取、滑动窗口等。

长期记忆的实现：

• 把重要信息存到外部（如向量数据库）

• 每次对话开始时，检索相关记忆注入上下文

• 类似人类"回忆"的过程

实际应用场景：

• 记住用户的偏好（"你上次说喜欢简洁风格"）

• 记住项目进度（"上周你说方案还在评审"）

• 记住历史决策（"之前讨论过这个指标用UV口径"）

核心挑战： 什么该记、什么该忘、什么时候该想起来——这和人类记忆面临的问题一模一样。目前的实现还比较粗糙，是 Agent 领域的活跃研究方向。

---

19. Agent 的规划能力是怎么实现的？（ReAct、Plan-and-Execute）

规划是 Agent 最核心也最困难的能力。目前主流有两种实现范式：

1. ReAct（Reasoning + Acting）

核心思路：边想边做，每一步都是"思考→行动→观察"的循环。

思考：用户要查上周活跃数据，我需要先确定数据源
行动：调用数据查询工具
观察：拿到了数据，但发现有异常值
思考：需要排查异常原因...
行动：查询相关日志...

优点：灵活，能根据中间结果调整方向

缺点：容易"走一步看一步"，缺乏全局视角

2. Plan-and-Execute（先规划后执行）

核心思路：先想清楚再动手，制定完整计划后按步骤执行。

规划阶段：
  Step 1: 确定数据源和时间范围
  Step 2: 拉取数据
  Step 3: 做趋势分析
  Step 4: 生成报告

执行阶段：按计划逐步执行，遇到问题可以修改计划

优点：有全局视角，不容易跑偏

缺点：如果初始计划有误，可能浪费执行时间

实际应用中的选择：

场景	适合的范式
简单、步骤少的任务	ReAct
复杂、多步骤的任务	Plan-and-Execute
不确定性高的探索任务	ReAct
目标明确的流程化任务	Plan-and-Execute

很多现代 Agent 框架会混合使用：先做高层规划，每一步内部用 ReAct 灵活执行。

---

20. Agent 有哪些典型应用场景？

Agent 的价值在于自动化端到端的复杂任务，以下是按领域分类的典型场景：

办公效率类：

• 自动写周报/日报（读日历+整理产出）

• 会议纪要整理+待办分发

• 邮件分类和自动回复

• 数据取数+分析+报告生成

软件开发类：

• 自动写代码+调试+测试

• Code Review 辅助

• 自动处理 Bug 工单

• 文档自动生成

数据分析类：

• 自然语言查询数据库

• 自动归因分析

• 竞品监控和报告

• 异常指标预警+初步排查

客服/运营类：

• 智能客服（不只回答问题，能实际操作退款等）

• 用户流失预警+自动触达

• 内容审核+处理

个人助理类：

• 日程管理（帮你协调时间、订会议室）

• 信息整理（帮你读长文、做摘要）

• 学习助手（根据你的水平定制学习计划）

关键判断标准： 如果一个任务是"重复的、有明确目标的、涉及多步操作的"，就很适合用 Agent 来自动化。反之，如果任务需要大量创造力和人类判断（如产品决策），Agent 目前只能辅助，不能替代。

---

21. Agent 的可靠性问题：为什么 Agent 有时会"跑偏"？

Agent "跑偏"是目前最大的落地障碍之一。主要原因包括：

1. 规划失误（想错了）

• 对任务理解有误，拆解出错误的步骤

• 高估自己的能力，选了不合适的工具

• 类比：员工理解错了需求，方向就错了

2. 累积误差（一步错步步错）

• 每一步都有出错概率，多步串联后错误放大

• 第 3 步基于第 2 步的错误结果继续执行

• 类比：传话游戏，传得越多偏得越远

3. 幻觉问题（编东西）

• 大模型"虚构"了不存在的工具调用结果

• 或者对中间结果做了错误解读

• 类比：员工没查到数据，自己编了一个交上来

4. 无限循环（卡住了）

• 执行遇到失败，反复重试同一个错误策略

• 没有"知道自己不行"的元认知能力

• 类比：一直在同一个死胡同里转

当前的应对策略：

策略	做法
人机协作	关键步骤让人确认
护栏/约束	限制工具权限、设置操作白名单
自我反思	让 Agent 检查自己的输出
回退机制	发现错误能回到上一个正确状态
可观测性	记录每一步的思考和行动日志

现实态度： Agent 不是万能的，目前最适合"出错成本低、有人兜底"的场景。把它当"能力很强但需要监督的新人"来用，是比较合理的预期。

---

四、Skill（技能）

22. 什么是 Skill？和 Plugin/Tool 有什么区别？

一句话理解： Skill 是一套"完整的能力包"，包含了解决特定问题所需的全部指令、工具调用逻辑和知识。

和 Plugin/Tool 的区别：

维度	Tool（工具）	Plugin（插件）	Skill（技能）
粒度	单个函数/API	一组相关API	完整的解决方案
包含内容	接口定义	接口+简单描述	Prompt+工具+流程+知识
智能程度	被动调用	被动调用	包含决策逻辑
类比	一把螺丝刀	一个工具箱	一个手艺人的全套本领

举个例子：

• Tool：query_database(sql) —— 执行一条 SQL

• Plugin：数据查询插件 —— 提供查询、导出、可视化等多个 API

• Skill：数据分析技能 —— 知道什么时候该查什么表、怎么分析、怎么呈现结果、遇到异常怎么处理

Skill 的本质是"封装了专业能力"：

它不只是工具的集合，而是把"一个专业人士处理某类问题的完整思路"打包成了 AI 可执行的方案。包括：

• 什么时候该启动这个能力

• 具体的执行步骤和分支逻辑

• 需要调用哪些工具

• 输出格式和质量标准

这就是为什么同样接入了数据库工具，有 Skill 的 Agent 能做出专业分析报告，没有 Skill 的只能返回原始查询结果。

---

23. Skill 的典型结构包含哪些部分？

一个完整的 Skill 通常包含以下组成部分：

Skill/
├── SKILL.md          # 技能说明书（何时触发、如何使用）
├── prompt/           # 核心 Prompt（指令模板）
├── tools/            # 依赖的工具定义
├── knowledge/        # 内置知识（规则、文档）
└── config/           # 配置信息

各部分详解：

组成	含义
SKILL.md（核心文件）	Skill 的"说明书"，定义了： 触发条件：什么时候激活这个 Skill（关键词、场景描述） 执行流程：一步步怎么做 工具调用方式：调什么 API、用什么命令 输入/输出规范：需要什么参数，返回什么格式 错误处理：出问题了怎么办
Description（描述/摘要）	一段简短的文字，告诉 AI "这个 Skill 干什么用的"，用于匹配用户意图。相当于 Skill 的"标签"。
脚本/工具（可选）	有些 Skill 会附带： CLI 命令行工具（如 oa-skills calendar-mcp） Python 脚本 Node.js 模块 配置文件
依赖与鉴权（可选）	需要哪些前置条件（如 SSO 登录、token） 依赖哪些外部服务或其他 Skill

好的 Skill 的特征：

1. 触发精准：该用的时候能被激活，不该用的时候不乱入

2. 流程完整：覆盖正常路径和异常处理

3. 输出稳定：每次执行结果格式一致、质量可控

4. 边界清晰：知道自己能做什么、不能做什么

类比理解：Skill 就像一份"岗位 SOP"——不只是告诉你有哪些工具可用，而是完整描述了"这个岗位的人应该怎么干活"。

---

24. Skill 和 Prompt 的本质区别是什么？

很多人觉得 Skill 就是"写得更好的 Prompt"，这个理解不完全对。

本质区别：

维度	Prompt	Skill
本质	一段指令文本	一套可执行的能力系统
包含内容	文字描述	Prompt + 工具 + 流程 + 知识 + 配置
能否调用工具	不能（纯文本）	能（绑定了具体工具）
能否被管理	难（散落在各处）	能（独立安装/更新/卸载）
可复用性	复制粘贴	标准化分发
执行确定性	低（每次可能不同）	高（有明确流程约束）

打个比方：

• Prompt = 口头交代一句"帮我把数据分析一下"

• Skill = 给你一本完整的《数据分析操作手册》+ 配套工具 + 数据权限

为什么需要 Skill 而不只是更好的 Prompt：

1. Prompt 有长度限制：复杂的业务逻辑写不下

2. Prompt 没有工具绑定：说"请查数据库"没用，得真的有接口

3. Prompt 难以标准化分发：每个人自己写，质量参差不齐

4. Prompt 缺乏版本管理：改了什么、谁改的、能不能回退

Skill 的出现，本质上是把"AI 的专业能力"从"个人经验"变成了"组织资产"——可以被开发、测试、分发、更新、复用。

---

25. Skill 是怎么被触发/匹配的？

当用户发出一条消息时，系统需要判断"该不该启动某个 Skill"。这个匹配过程通常有以下几种机制：

1. 关键词/规则匹配

• 最简单直接：用户消息包含特定关键词就触发

• 例：消息含"审批""工单""待办" → 触发审批 Skill

• 优点：快速、确定性高

• 缺点：容易误触发或遗漏

2. 意图识别（语义匹配）

• 用大模型理解用户真实意图，匹配最合适的 Skill

• 例：用户说"帮我看看那个单子走到哪了" → 理解为"查询审批进度"

• 优点：覆盖面广，自然语言友好

• 缺点：有延迟，可能判断错

3. 显式调用

• 用户明确指定使用某个 Skill

• 例：@审批助手 帮我查一下...

• 优点：零歧义

• 缺点：用户需要知道有哪些 Skill

4. 上下文推断

• 根据对话历史和当前状态自动判断

• 例：上一轮在讨论数据问题，这轮说"帮我看看原因" → 触发数据分析 Skill

实际系统通常是多种机制组合：

用户消息 → 规则预筛选 → 语义精排 → 确认触发 → 执行 Skill

Skill 开发者需要关注的：

• description 写清楚：让匹配系统理解这个 Skill 能做什么

• trigger 词设全：覆盖用户可能的各种表达方式

• 边界明确：说清楚"什么不归我管"，避免误触发

---

26. 一个 Skill 能调用另一个 Skill 吗？

可以，这叫 Skill 的嵌套调用或编排。

典型场景：

用户："帮我分析上周活跃率变化，然后写成 KM 文档"

触发流程：
1. 主 Skill（数据分析）先完成数据取数和分析
2. 分析完成后，调用「学城文档」Skill 创建 KM 文档
3. 最终返回文档链接给用户

调用方式：

方式	说明	适用场景
顺序调用	A 完成后触发 B	流水线式任务
条件调用	根据 A 的结果决定是否调用 B	分支逻辑
并行调用	A 和 B 同时执行	互不依赖的子任务
委托调用	A 把部分工作完全交给 B	专业分工

设计原则：

1. 单一职责：每个 Skill 做好一件事

2. 松耦合：Skill 之间通过标准接口通信，不直接依赖内部实现

3. 可独立使用：被调用的 Skill 也能单独工作

4. 避免循环：A 调 B、B 又调 A 会死循环

现实中的注意事项：

• 嵌套层级不宜过深（通常不超过 2-3 层）

• 每次跨 Skill 调用都有延迟和失败风险

• 需要做好错误传播和回退处理

这种组合能力让 Agent 的能力像乐高积木一样可以灵活拼装，是 Skill 体系设计的核心优势。

---

27. 如何开发一个自己的 Skill？

开发一个 Skill 的门槛并不高，核心是把你的专业知识结构化。以下是通用流程：

Step 1：定义能力边界

• 这个 Skill 解决什么问题？

• 什么时候应该触发？什么时候不应该？

• 输入是什么？输出是什么？

Step 2：设计执行流程

触发 → 理解用户意图 → 调用工具 → 处理结果 → 格式化输出

Step 3：编写核心文件

文件	内容
SKILL.md	技能描述、触发条件、使用说明
Prompt	系统指令、角色设定、约束规则
工具定义	需要调用的 API/CLI 描述
示例	输入输出样例

Step 4：测试与迭代

• 用各种边界情况测试

• 检查是否会误触发

• 验证输出质量是否稳定

一个最小可用 Skill 的示例结构：

# SKILL.md - 周报生成助手

## 描述
根据用户提供的本周工作内容，自动生成标准格式周报。

## 触发词
周报、写周报、本周总结

## 工具依赖
- 日历查询（获取本周会议记录）
- 文档创建（输出到 KM）

## 执行步骤
1. 收集用户提供的工作内容
2. 查询本周日历补充会议信息
3. 按【本周完成/下周计划/需要协调】格式生成
4. 输出结果或创建文档

核心建议： 从简单开始，先让 Skill 在一个场景下稳定工作，再逐步扩展能力。

---

28. Skill 的安全性怎么保障？

Skill 本质上赋予了 AI "动手操作"的能力，安全性至关重要。主要从以下维度保障：

1. 权限控制

层级	措施
工具权限	Skill 只能调用被授权的工具，不能越权
数据权限	只能访问用户有权限的数据
操作权限	写操作需要额外确认，不能静默执行

2. 输入验证

• 校验用户输入，防止注入攻击

• 对 Skill 的参数做类型和范围检查

• 防止通过构造特殊输入绕过安全规则

3. 行为约束

• 明确 Skill 的"红线"（绝对不能做的事）

• 设置操作频率限制（防止滥用）

• 高风险操作需要人工确认

4. 审计与可观测

• 记录 Skill 每次执行的完整日志

• 监控异常调用模式

• 支持事后追溯和回退

5. 供应链安全

• 只使用官方可信来源的 Skill

• Skill 更新需要审核

• 防止恶意 Skill 混入（类似 npm 包投毒）

实际案例：

一个"审批 Skill"的安全设计：

• ✅ 能做：查询审批状态、提交审批

• ❌ 不能做：绕过审批流程直接通过、修改他人的审批单

• ⚠️ 需确认：批量审批操作（先展示列表让用户确认）

核心原则： 最小权限原则——Skill 只获得完成任务所必需的最小权限，不多给一分。

---

五、三者关系与协作

29. 大模型、Agent、Skill 三者是什么关系？

一个比喻就够了：

概念	类比	作用
大模型	大脑	理解、推理、生成语言
Agent	完整的人	感知、思考、行动的统一体
Skill	专业技能	特定领域的能力包

它们的层级关系：

Agent（智能体）
  ├── 大模型（负责思考和决策）
  ├── Skill A（数据分析能力）
  ├── Skill B（文档写作能力）
  ├── Skill C（审批处理能力）
  └── 记忆系统（维持上下文）

用一句话描述关系：

Agent 是大模型穿上了 Skill 装备后的"完全体"。

三者缺一不可的原因：

• 只有大模型：很聪明但"手无缚鸡之力"（只能聊天，不能做事）

• 只有工具没有大模型：有手有脚但"没有大脑"（不知道该干什么）

• 只有 Agent 框架没有 Skill：有躯壳没有能力（知道要做但不知道怎么做）

协作方式：

1. 用户发出请求

2. Agent 接收，用大模型理解意图

3. Agent 匹配合适的 Skill

4. Skill 指导大模型调用工具、执行流程

5. Agent 整合结果，返回给用户

这三者的关系不是"三选一"，而是"三合一"才能发挥最大价值。

---

30. 一个完整的 AI 应用是怎么把三者串起来的？

以一个实际场景为例："用户说'帮我分析一下上周用户活跃率下降的原因，写成文档发到群里'"

完整执行链路：

Step 1: Agent 接收任务
  └─ 大模型理解意图：需要 数据分析 + 文档写作 + 消息发送

Step 2: Agent 规划步骤
  └─ Plan: 取数 → 分析 → 写文档 → 发消息

Step 3: 执行 Skill A（数据分析）
  ├─ 大模型决定查什么数据
  ├─ 调用数据查询工具拉数据
  ├─ 大模型分析数据，找出原因
  └─ 输出分析结论

Step 4: 执行 Skill B（文档写作）
  ├─ 大模型根据分析结论组织内容
  ├─ 调用文档创建工具生成 KM
  └─ 输出文档链接

Step 5: 执行 Skill C（消息发送）
  ├─ 调用消息工具发到群里
  └─ 附上文档链接和摘要

Step 6: Agent 汇总
  └─ 回复用户："分析完成，文档已发到群里，主要原因是..."

架构图解：

用户请求
   ↓
[Agent 层] —— 任务理解、规划、调度
   ↓
[Skill 层] —— 数据分析 Skill / 文档 Skill / 消息 Skill
   ↓
[工具层] —— 数据库 API / 文档 API / 消息 API
   ↓
[大模型] —— 贯穿全程提供推理能力

关键设计原则：

1. 大模型是"胶水"：串联各环节的决策全靠它

2. Skill 是"模块"：各自独立、可插拔

3. Agent 是"指挥官"：负责全局调度和异常处理

---

31. 没有 Skill 的 Agent 和有 Skill 的 Agent 差别在哪？

维度	无 Skill 的 Agent	有 Skill 的 Agent
能力范围	只能基于大模型通用知识	拥有领域专业能力
执行质量	泛泛而谈	精准专业
一致性	每次可能不同	稳定可复现
可扩展性	靠改 Prompt	装新 Skill 即可
类比	刚毕业的通才	有多年经验的专家

具体例子对比：

用户："帮我查一下上周工单复盘率"

无 Skill 的 Agent：

"好的，要查工单复盘率，你可以打开XX系统，在XX页面筛选上周日期……"

（只能告诉你怎么做，不能替你做）

有 Skill 的 Agent：

"上周工单复盘率为 78.3%，环比上升 2.1pp。其中自营业务 82%，外包业务 71%。下降最多的是XX职场（-5pp），主要原因是……"

（直接查数据、做分析、给结论）

为什么差别这么大？

Skill 带来的不只是"能调用工具"，更重要的是：

1. 知道查哪个接口/数据源（领域知识）

2. 知道用什么口径（业务规则）

3. 知道怎么呈现（输出规范）

4. 知道异常怎么处理（经验积累）

这就好比：给一个新人一台电脑（工具）和给一个老员工一台电脑，产出天差地别。差的不是电脑，是经验和方法论——这正是 Skill 封装的东西。

---

32. Skill 是否可以脱离 Agent 单独使用？

可以，但能力会受限。

单独使用 Skill 的场景：

• 直接在对话中触发某个 Skill（无需 Agent 的规划和调度）

• 类似于调用一个"专用工具"

• 适合单一、明确的任务

对比：

场景	单独用 Skill	通过 Agent 用 Skill
"帮我查审批状态"	✅ 直接触发审批 Skill	✅ Agent 匹配后触发
"查审批状态，如果通过了就发通知"	⚠️ 需要手动串联	✅ Agent 自动编排
"分析数据+写文档+发群里"	❌ 需要多个 Skill 配合	✅ Agent 统一调度

类比：

• Skill 单独用 = 用计算器算个数（专用工具，做一件事）

• Skill + Agent = 让会计帮你做财务报表（专业人士用多个工具完成复杂任务）

实际设计建议：

1. 简单任务：直接调用 Skill 即可，不需要 Agent 的开销

2. 复杂任务：让 Agent 来编排多个 Skill 的执行顺序

3. 好的 Skill 设计：既能被 Agent 调用，也能独立运行

结论： Skill 可以独立工作，但和 Agent 结合才能发挥最大价值——就像一个优秀的程序员可以独立干活，但在一个好团队里能做出更大的事。

---

33. 为什么说"大模型是大脑，Skill 是手脚，Agent 是完整的人"？

这个比喻精准地表达了三者的关系：

大模型 = 大脑 🧠

• 负责：理解语言、逻辑推理、生成内容、做决策

• 特点：很聪明，但只能"想"不能"做"

• 局限：没有手脚的大脑，再聪明也只能纸上谈兵

Skill = 手脚 🦾

• 负责：实际操作——查数据、写文档、发消息、订会议室

• 特点：能力具体、专业，但需要"大脑"来指挥

• 局限：没有大脑指挥的手脚，只会机械执行

Agent = 完整的人 🧍

• 负责：感知环境、思考规划、采取行动、反思调整

• 特点：大脑+手脚+记忆+目标=一个能独立工作的实体

• 本质：是一种"组装方式"，把大模型和 Skill 组合成一个有自主性的整体

为什么这个比喻重要？

它帮助我们理解几个关键点：

1. 大模型不等于 Agent：很多人以为 ChatGPT 就是 Agent，其实它只是"大脑"部分

2. 工具不等于 Skill：Skill 不只是工具，还包含"怎么用工具"的智慧

3. 三者缺一不可：

• 有脑无手 = 知道该做什么但做不了

• 有手无脑 = 能做事但不知道该做什么

• 有脑有手但没有协调 = 手脚不听使唤

延伸思考：

如果把企业类比成一个人——

• 大模型 = CEO 的决策力

• Skill = 各部门的专业能力

• Agent = 组织运转的机制

三者协同，才能把事情做成。

---

六、实际应用与选型

34. 企业落地 AI Agent 有哪些常见模式？

从简单到复杂，企业落地 Agent 通常经历以下几个阶段：

模式一：Copilot（副驾驶）

• 特点：AI 辅助人类，人做最终决策

• 示例：代码补全、文档润色、数据查询助手

• 适用：高风险场景、需要人类判断的场景

• 难度：⭐⭐

模式二：自动化流程 Agent

• 特点：固定流程的端到端自动执行

• 示例：自动处理审批、自动生成日报、自动回复简单工单

• 适用：规则明确、重复性高的场景

• 难度：⭐⭐⭐

模式三：智能助手 Agent

• 特点：理解自然语言，灵活完成多种任务

• 示例：企业内部 AI 助手（查数据、写文档、管日程）

• 适用：任务多样但风险可控的场景

• 难度：⭐⭐⭐⭐

模式四：自主决策 Agent

• 特点：AI 自主做决策和执行，最少人工干预

• 示例：智能客服（自主判断并执行退款）、自动化运营

• 适用：决策链路短、容错空间大的场景

• 难度：⭐⭐⭐⭐⭐

企业选型建议：

阶段	建议
刚起步	从 Copilot 开始，建立信任
有经验	选几个明确流程做自动化
成熟期	逐步扩展到智能助手
愿景期	探索自主决策（谨慎推进）

核心原则： 先在"出错成本低"的场景验证，逐步扩展到高价值场景。不要一上来就追求"全自动"。

---

35. 什么场景适合用 Prompt 解决？什么场景需要上 Skill/Agent？

决策框架：

任务复杂度 低 ────────────────────── 高
           │                         │
      纯 Prompt    Prompt + Tool    Skill    Agent
           │                         │
需要工具   否 ────────────────────── 是

详细对照表：

判断维度	用 Prompt	上 Skill	上 Agent
是否需要外部数据	否	是	是
是否需要多步执行	否	可能	是
是否需要调用工具	否	是	是
是否需要记忆	否	否	是
是否需要自主决策	否	否	是
执行频率	偶尔	经常	高频/自动

场景举例：

纯 Prompt 即可解决：

• 帮我润色这段文案

• 把这段英文翻译成中文

• 帮我想 5 个活动主题

• 解释一个技术概念

需要 Skill：

• 帮我查上周活跃数据（需要工具）

• 帮我创建一篇 KM 文档（需要 API）

• 帮我查审批进度（需要系统对接）

需要 Agent：

• 帮我分析数据并写成文档发到群里（多步、多工具）

• 每天早上帮我汇总待办事项（需要记忆、定时）

• 帮我处理这个工单（需要理解、判断、操作）

核心判断标准：

如果任务只需要"想"→ Prompt 如果任务需要"做"→ Skill 如果任务需要"想+做+记+判断"→ Agent

---

36. Agent 平台/框架有哪些？（LangChain、AutoGPT、Dify、Coze 等）

当前主流的 Agent 平台/框架可以分为几类：

一、开发框架（面向开发者）

框架	特点	适合谁
LangChain	最流行的 Agent 开发框架，生态丰富	有 Python 基础的开发者
LangGraph	LangChain 团队出品，支持复杂流程编排	需要多 Agent 协作的场景
CrewAI	多 Agent 协作框架，角色分工明确	多角色协作场景
AutoGen	微软出品，强调多 Agent 对话	研究探索型项目

二、应用平台（低代码/无代码）

平台	特点	适合谁
Dify	开源，可视化编排，支持私有化部署	企业内部落地
Coze（扣子）	字节出品，中文生态好，入门简单	快速搭建 Bot
FastGPT	开源，强调知识库能力	知识问答场景
百度千帆	百度生态，国内合规	使用文心大模型的场景

三、自主 Agent（实验性）

项目	特点	状态
AutoGPT	最早的自主 Agent 项目，目标导向	实验性，可靠性待提升
BabyAGI	简洁的任务驱动 Agent	教学/概念验证
MetaGPT	模拟软件公司多角色协作	代码生成场景

选型建议：

• 想快速体验：Coze / Dify（拖拖拽拽就能用）

• 想深度定制：LangChain / LangGraph（代码级控制）

• 企业私有化：Dify / FastGPT（可本地部署）

• 想了解前沿：AutoGPT / CrewAI（理解 Agent 边界）

---

37. 如何评估一个 Agent/Skill 的效果好不好？

评估 Agent/Skill 不能只看"能不能跑通"，需要从多个维度系统性评估：

核心评估维度：

维度	衡量什么	关键指标
准确性	结果对不对	任务成功率、答案准确率
稳定性	每次执行是否一致	同一输入多次执行的结果方差
效率	快不快	端到端耗时、工具调用次数
覆盖度	能处理多少种情况	支持的场景数/边界情况处理
安全性	会不会出问题	越权操作率、敏感信息泄露率
用户体验	用着舒不舒服	用户满意度、重复使用率

评估方法：

1. Benchmark 测试（标准测试集）

• 准备一批标准问题+预期答案

• 自动执行并对比结果

• 适合量化评估准确性

2. A/B 测试

• 新旧版本对比

• 看用户选择哪个结果更好

• 适合评估用户体验

3. 人工评审

• 专家逐条打分

• 适合复杂任务的质量评估

• 成本高但最可靠

4. 线上监控

• 追踪实际使用数据

• 成功率、异常率、用户留存

• 最贴近真实效果

实用评估 checklist：

• [ ] 正常路径能跑通吗？（Happy Path）

• [ ] 边界情况怎么处理？（用户没给完整信息）

• [ ] 出错时的表现？（工具不可用时）

• [ ] 和人工对比差多少？（有没有实际价值）

• [ ] 用户愿意再用吗？（体验好不好）

---

38. AI Agent 目前的局限性是什么？未来方向在哪？

当前的主要局限：

1. 可靠性不足

• 复杂任务成功率通常在 60-80%，远未达到"可信赖"水平

• 多步骤执行时累积误差明显

• 现状：适合"有人兜底"的场景，还不能完全自主

2. 规划能力有限

• 面对开放性、模糊性任务时容易跑偏

• 长期规划和全局最优决策仍然困难

• 现状：适合步骤明确的任务，探索性任务需要人工介入

3. 成本和延迟

• 多次大模型调用 = 高 token 消耗 = 高成本

• 复杂任务可能需要几十秒甚至几分钟

• 现状：适合对时效性要求不高、价值密度高的任务

4. 安全和可控性

• Agent 有"自主权"意味着有"出格"的风险

• 如何确保 Agent 不做危险操作是未解难题

• 现状：需要完善的权限和监控体系

5. 评估困难

• 缺乏统一的评估标准

• 同一个 Agent 在不同场景表现差异大

• 现状：主要靠人工抽检和线上数据

---

未来方向：

方向	描述	预期影响
更强的推理能力	大模型本身推理能力提升（如 o1、Claude 3.5）	规划更准确，出错更少
多模态 Agent	不只处理文本，还能看图、听音、操作屏幕	能力范围大幅扩展
Agent 间协作标准化	统一的 Agent 通信协议（如 MCP）	生态互通，能力可组合
自我学习/进化	Agent 从历史执行中学习改进	越用越好
更好的人机协作	不是替代人，而是和人更好地配合	1+1 > 2
垂直领域深耕	针对特定行业深度优化	在特定场景达到专家水平

总结判断：

AI Agent 目前处于"能用但不够稳"的阶段——类似智能手机 2008 年的状态。核心技术已经 ready，但生态、可靠性、用户习惯还需要 2-3 年的成熟期。现在入场学习和探索，是最好的时机。

轻量：参数量小、推理快、成本低的模型

蒸馏模型：是制造轻量模型的一种核心方法——让小模型"学"大模型的能力