智能体设计模式（五）人机协同-知识检索RAG-智能体间通信

智能体设计模式（五）人机协同-知识检索RAG-智能体间通信

本文是"智能体设计模式"系列的第五篇，涵盖第13-15章：人机协同、知识检索RAG、智能体间通信。

系列文章：

• 智能体设计模式（一）提示链-路由-并行化
• 智能体设计模式（二）反思-工具使用-规划
• 智能体设计模式（三）多智能体协作-记忆管理-学习与适应
• 智能体设计模式（四）模型上下文协议-目标设定与监控-异常处理与恢复
• 智能体设计模式（五）人机协同-知识检索RAG-智能体间通信（本文）
• ...

---

第13章：人机协同 ------ AI与人类的"双人舞"

一句话定位：人机协同就是让AI和人类跳一支"双人舞"，AI负责快速计算，人类负责关键决策，两者配合才能跳出最美的舞步。

---

一、秒懂定位（30秒版）

这个知识解决什么问题：

AI再聪明，也有"翻车"的时候
关键决策不能全交给机器
人机协同 = AI干活 + 人类把关
确保AI不会"好心办坏事"

一句话精华：

人机协同 = AI的效率 + 人类的智慧
就像自动驾驶需要人类随时接管一样

适合谁学 ：开发高风险AI应用（金融、医疗、法律）的开发者
不适合谁：只做简单自动化、不涉及关键决策的场景

---

二、核心框架（知识骨架）

生活化比喻：AI的"实习生"模式

想象你是一家公司的老板，招了一个超级聪明的实习生（AI）：

🤖 实习生（AI）的特点：
   - 干活超快，一天能处理1000份文件
   - 但有时候会"想当然"，犯低级错误
   - 遇到复杂情况可能"懵圈"

👨‍💼 老板（人类）的角色：
   - 制定规则和标准
   - 审核关键决策
   - 处理特殊情况
   - 最终拍板

🤝 最佳配合：
   - 简单任务：实习生独立完成
   - 复杂任务：实习生做初稿，老板审核
   - 关键决策：老板亲自处理，实习生辅助

关键概念速查表

概念	大白话解释	生活比喻	一句话记忆
Human-in-the-Loop	人类在决策环路中	老板审批	关键节点人类把关
Human-on-the-Loop	人类在环路之上监督	老板定规则	人定策略AI执行
上报机制	AI遇到难题找人帮忙	实习生请示	不懂就问，别瞎搞
决策增强	AI提供建议，人类决定	参谋出主意	AI是参谋，人是将军
反馈学习	人类纠正AI的错误	师傅带徒弟	错了就改，越来越好
优雅降级	AI出问题时平稳过渡	备用方案	主力不行，替补上场

知识地图

用户请求 → [AI初步处理]
              ↓
         简单任务？ ─是→ [AI直接完成] → 输出结果
              ↓ 否
         [AI生成建议]
              ↓
         需要人工审核？ ─是→ [人类审核决策]
              ↓ 否                    ↓
         [AI执行]              [人类反馈]
              ↓                      ↓
         输出结果 ←──────────────────┘

---

三、深入浅出讲解（教学版）

开场钩子

"你敢让AI帮你做手术吗？敢让AI帮你判案吗？敢让AI帮你管理核电站吗？------如果你犹豫了，恭喜你，你已经理解了人机协同的必要性！"

核心讲解

【概念1：Human-in-the-Loop ------ 人类在"环路中"】

一句话是什么：在AI的决策流程中，关键节点必须有人类参与。

生活化比喻：

想象一条自动化生产线：
- 大部分工序由机器完成
- 但质检环节必须有人把关
- 发现问题立即叫停

AI系统也是这样：
- 日常任务AI自动处理
- 关键决策人类审核
- 异常情况人类介入

引经据典：

"三个臭皮匠，顶个诸葛亮" ------ 中国谚语

但在AI时代，我们要说：
"一个AI加一个人类，胜过十个纯AI"

因为AI有计算力，人类有判断力
两者结合，才是最强组合！

技术要点：

# Human-in-the-Loop 的核心模式
class HumanInTheLoopAgent:
    def process_request(self, request):
        # 1. AI先做初步分析
        ai_analysis = self.ai_analyze(request)
        
        # 2. 判断是否需要人工审核
        if self.needs_human_review(ai_analysis):
            # 3. 上报给人类审核
            human_decision = self.escalate_to_human(ai_analysis)
            return human_decision
        else:
            # 4. 简单任务AI直接处理
            return self.ai_execute(ai_analysis)
    
    def needs_human_review(self, analysis):
        # 判断条件：风险高、金额大、情况复杂
        return (analysis.risk_level > 0.7 or 
                analysis.amount > 10000 or
                analysis.complexity == "high")

常见误区（幽默版）：

❌ 误区："AI够聪明，不需要人类"
   真相：AI再聪明也会"幻觉"，关键时刻还得人类把关
   
❌ 误区："人机协同就是给AI加个审批流程"
   真相：不只是审批，还包括反馈、学习、持续改进

❌ 误区："人机协同会降低效率"
   真相：短期可能慢一点，但避免了大错误，长期更高效

---

【概念2：Human-on-the-Loop ------ 人类在"环路之上"】

一句话是什么：人类制定规则和策略，AI负责执行。

生活化比喻：

想象你是一个基金经理：
- 你制定投资策略："科技股不超过30%，遇到暴跌自动止损"
- AI按照你的策略自动交易
- 你不需要每笔交易都审批
- 但你随时监控，必要时调整策略

这就是Human-on-the-Loop：
- 人类定规则
- AI执行规则
- 人类监督结果
- 必要时人类介入

对比Human-in-the-Loop：

Human-in-the-Loop（人在环中）：
- 每个关键决策都要人类参与
- 适合：高风险、低频率的决策
- 例如：大额贷款审批、医疗诊断

Human-on-the-Loop（人在环上）：
- 人类定规则，AI自动执行
- 适合：中等风险、高频率的决策
- 例如：自动交易、内容推荐

---

【概念3：上报机制 ------ AI的"求助热线"】

一句话是什么：当AI遇到超出能力范围的问题时，自动上报给人类处理。

生活化比喻：

想象一个智能客服：
- 简单问题："你们几点营业？" → AI直接回答
- 复杂问题："我要投诉你们经理！" → 转人工
- 敏感问题："我想自杀..." → 立即转专业人员

上报机制就是AI的"求助热线"：
- 知道自己的能力边界
- 遇到难题不硬撑
- 及时寻求人类帮助

代码示例：

def escalate_to_human(issue_type: str) -> dict:
    """
    将问题上报给人类专家处理
    """
    # 记录上报原因
    log_escalation(issue_type)
    
    # 通知人类专家
    notify_human_expert(issue_type)
    
    # 返回上报状态
    return {
        "status": "escalated",
        "message": f"已将{issue_type}问题转交给人类专家处理",
        "estimated_response_time": "24小时内"
    }

# 使用示例
technical_support_agent = Agent(
    name="技术支持专员",
    instruction="""
    你是技术支持专员，负责处理用户问题。
    
    处理规则：
    1. 简单问题：直接回答
    2. 复杂问题：使用troubleshoot_issue工具分析
    3. 超出能力范围：使用escalate_to_human上报
    
    上报条件：
    - 用户情绪激动
    - 涉及法律问题
    - 需要退款超过1000元
    - 你不确定如何处理
    """,
    tools=[troubleshoot_issue, create_ticket, escalate_to_human]
)

---

四、实践示例

示例1：智能客服的人机协同

"""
一个带人机协同的智能客服系统
"""
from google.adk.agents import Agent
from google.adk.tools.tool_context import ToolContext

# 定义工具函数
def troubleshoot_issue(issue: str) -> dict:
    """分析问题并提供解决方案"""
    return {
        "status": "success", 
        "report": f"针对'{issue}'的故障排除步骤..."
    }

def create_ticket(issue_type: str, details: str) -> dict:
    """创建工单"""
    return {
        "status": "success", 
        "ticket_id": "TICKET-2024-001"
    }

def escalate_to_human(issue_type: str) -> dict:
    """上报给人类专家"""
    return {
        "status": "success", 
        "message": f"已将{issue_type}问题转交给人类专家"
    }

# 创建智能客服Agent
customer_support_agent = Agent(
    name="智能客服小助手",
    model="gemini-2.0-flash",
    instruction="""
    你是一位专业的技术支持专员。
    
    处理流程：
    1. 首先检查用户的历史记录
    2. 对于技术问题，使用troubleshoot_issue工具分析
    3. 如果问题无法解决，使用create_ticket创建工单
    4. 对于以下情况，必须使用escalate_to_human上报：
       - 用户要求与人工客服对话
       - 涉及退款金额超过500元
       - 用户情绪非常激动
       - 涉及法律或安全问题
    
    保持专业但有同理心的态度。
    """,
    tools=[troubleshoot_issue, create_ticket, escalate_to_human]
)

示例2：金融风控的人机协同

"""
金融交易风控系统 - Human-on-the-Loop模式
"""

class TradingRiskControl:
    def __init__(self):
        # 人类定义的风控规则
        self.rules = {
            "max_single_trade": 100000,      # 单笔最大金额
            "daily_limit": 1000000,          # 日交易限额
            "stop_loss_threshold": 0.1,      # 止损阈值10%
            "high_risk_sectors": ["加密货币", "期货"],
        }
        self.daily_total = 0
    
    def check_trade(self, trade):
        """
        AI自动检查交易是否符合规则
        """
        alerts = []
        
        # 检查单笔金额
        if trade.amount > self.rules["max_single_trade"]:
            alerts.append(f"单笔金额{trade.amount}超过限额")
        
        # 检查日限额
        if self.daily_total + trade.amount > self.rules["daily_limit"]:
            alerts.append("将超过日交易限额")
        
        # 检查高风险行业
        if trade.sector in self.rules["high_risk_sectors"]:
            alerts.append(f"涉及高风险行业：{trade.sector}")
        
        return alerts
    
    def process_trade(self, trade):
        """
        处理交易请求
        """
        alerts = self.check_trade(trade)
        
        if not alerts:
            # 无风险，AI自动执行
            return self.execute_trade(trade)
        elif len(alerts) == 1 and "高风险行业" in alerts[0]:
            # 中等风险，需要人工确认
            return self.request_human_approval(trade, alerts)
        else:
            # 高风险，直接拒绝并通知人类
            return self.reject_and_notify(trade, alerts)
    
    def request_human_approval(self, trade, alerts):
        """请求人工审批"""
        return {
            "status": "pending_approval",
            "trade": trade,
            "alerts": alerts,
            "message": "交易已提交人工审批，请等待"
        }

---

五、精华提炼（去废话版）

核心要点

1. Human-in-the-Loop = 关键节点人类把关

   • 高风险决策必须人类审核
   • AI提供建议，人类做决定
   • 适合低频、高风险场景

2. Human-on-the-Loop = 人定规则AI执行

   • 人类制定策略和边界
   • AI在规则内自动执行
   • 适合高频、中等风险场景

3. 上报机制 = AI的"求助热线"

   • AI要知道自己的能力边界
   • 遇到难题及时上报
   • 宁可多问，不可乱来

砍掉的废话

• 各种学术定义和分类（知道核心概念就够了）
• 复杂的数学模型（实际开发用不上）
• 过多的行业案例（理解原理后自己能推导）

必须记住的

人机协同三原则：
1. AI干活，人类把关 ------ 效率与安全兼顾
2. 简单自动，复杂上报 ------ 分级处理
3. 持续反馈，不断改进 ------ 越用越好

---

六、行动清单

立即可做（5分钟内）

• 理解Human-in-the-Loop和Human-on-the-Loop的区别
• 思考你的AI应用哪些环节需要人类参与

本周实践

• 为你的AI Agent添加上报机制
• 设计一套分级处理规则（什么情况AI处理，什么情况上报）

进阶挑战

• 实现人类反馈的学习机制
• 设计完整的人机协同工作流

---

七、常见误区

误区1："人机协同会拖慢效率"

真相：

短期看：确实会增加一些审核时间
长期看：避免了重大错误，总体效率更高

就像开车系安全带：
- 每次多花2秒
- 但关键时刻能救命

人机协同也是一样：
- 日常多花一点时间
- 关键时刻避免灾难

误区2："AI越来越强，以后不需要人类了"

真相：

AI的局限性：
- 缺乏真正的理解和判断
- 可能产生"幻觉"
- 无法处理全新情况
- 不具备道德责任

人类不可替代的价值：
- 创造力和直觉
- 道德判断
- 承担责任
- 处理例外情况

误区3："上报机制就是推卸责任"

真相：

上报机制的真正目的：
- 确保问题得到正确处理
- 让专业的人做专业的事
- 保护用户利益
- 持续改进AI能力

不是推卸责任，而是负责任的表现！

---

八、学习检查

基础知识

• 能解释Human-in-the-Loop和Human-on-the-Loop的区别
• 理解上报机制的作用和实现方式
• 知道什么情况下需要人类介入

实践能力

• 能为AI Agent设计上报规则
• 能实现基本的人机协同工作流
• 能处理人类反馈并改进AI

进阶理解

• 理解人机协同对AI安全的重要性
• 能设计适合不同场景的协同模式
• 能平衡效率和安全的关系

---

九、金句收藏

原文金句：

"人机协同的核心原则是确保AI在道德约束下运行，
遵守安全协议，并以最佳效率实现其目标。"

我的总结金句：

"AI是最强的员工，但不是最好的老板；
人机协同，让AI干活，让人类决策。"

---

十、画龙点睛（收尾）

总结升华

人机协同不是对AI能力的不信任，而是对AI应用的负责任态度：

• AI擅长处理大量数据和重复任务
• 人类擅长判断、创造和承担责任
• 两者结合，才能发挥最大价值

就像一支交响乐团：

• AI是演奏家，技术精湛
• 人类是指挥家，把控全局
• 配合默契，才能奏出美妙乐章

悬念预告

学会了人机协同，AI能和人类配合了。但AI怎么获取最新的知识？怎么回答训练数据之外的问题？下一章"知识检索（RAG）"，我们来揭秘！

一句话带走

人机协同 = AI的效率 + 人类的智慧
让AI干活，让人类把关，这才是AI应用的正确姿势！

---

十一、延伸资源

想深入学习

• Google ADK 官方文档：Human-in-the-Loop 实现
• LangChain 的人机交互工具

想教给别人

• 用"实习生与老板"的比喻解释人机协同
• 用"自动驾驶需要人类接管"的例子说明必要性

---

第14章：知识检索（RAG）------ AI的"外挂大脑"

一句话定位：RAG就是给AI装上一个"外挂大脑"，让它能随时查阅最新资料，而不是只靠"死记硬背"的训练数据来回答问题。

---

一、秒懂定位（30秒版）

这个知识解决什么问题：

AI的知识有"保质期"------训练数据截止到某个时间点
问它最新的事？不知道！
问它公司内部文档？不知道！
问它专业领域细节？可能瞎编！

RAG = 让AI先"查资料"，再回答
就像开卷考试，不用全靠记忆

一句话精华：

RAG = 检索（Retrieval）+ 增强（Augmented）+ 生成（Generation）
先查后答，有据可依

适合谁学 ：需要让AI回答最新信息、专业知识、企业内部数据的开发者
不适合谁：只需要AI做简单对话、不涉及专业知识检索的场景

---

二、核心框架（知识骨架）

生活化比喻：AI的"开卷考试"

想象你是一个学生，面对两种考试：

📚 闭卷考试（传统LLM）：
   - 只能靠脑子里记住的知识
   - 考试范围之外的？不会！
   - 最新发生的事？不知道！
   - 容易"编答案"凑字数

📖 开卷考试（RAG）：
   - 可以带资料进考场
   - 遇到不会的先翻书
   - 找到相关内容再作答
   - 答案有出处，可验证

RAG就是让AI从"闭卷"变成"开卷"！

关键概念速查表

概念	大白话解释	生活比喻	一句话记忆
Embedding（嵌入）	把文字变成数字向量	给每个词一个"GPS坐标"	文字的数学表示
向量数据库	存储和搜索向量的仓库	智能图书馆	按"意思"找内容
语义搜索	按意思而非关键词搜索	理解你想要什么	懂你的搜索引擎
文档分块	把长文档切成小段	把书拆成章节	方便检索的预处理
上下文增强	把检索结果加到提示词里	给AI递小抄	让AI有据可依
幻觉（Hallucination）	AI编造不存在的信息	信口开河	RAG要解决的问题

知识地图

用户提问 → [查询向量化]
              ↓
         [向量数据库搜索]
              ↓
         找到相关文档片段
              ↓
         [组装增强提示词]
         "根据以下资料回答：
          资料1: xxx
          资料2: xxx
          问题: xxx"
              ↓
         [LLM生成回答]
              ↓
         输出（带引用来源）

---

三、深入浅出讲解（教学版）

开场钩子

"你问ChatGPT：'今天股市怎么样？'它说：'抱歉，我的知识截止到2023年...' 你问它公司内部的报销流程，它一脸懵逼。这时候你就需要RAG了------让AI学会'先查资料，再回答'！"

核心讲解

【概念1：Embedding ------ 文字的"GPS坐标"】

一句话是什么：把文字转换成一串数字（向量），让计算机能理解文字的"意思"。

生活化比喻：

想象一个神奇的地图：
- 每个词都有一个坐标位置
- 意思相近的词，位置也相近
- "猫"和"小猫"挨得很近
- "猫"和"汽车"离得很远

Embedding就是给文字分配这样的坐标：
- "猫" → [0.2, 0.8, 0.1, ...]
- "小猫" → [0.21, 0.79, 0.12, ...]  // 很接近！
- "汽车" → [0.9, 0.1, 0.7, ...]     // 很远！

引经据典：

"名不正则言不顺" ------ 孔子

在AI世界里，我们要说：
"向量不准则搜索不灵"

Embedding的质量，直接决定了RAG的效果！

技术要点：

# Embedding示例
from openai import OpenAI

client = OpenAI()

# 把文字变成向量
response = client.embeddings.create(
    model="text-embedding-3-small",
    input="什么是人工智能？"
)

# 得到一个1536维的向量
vector = response.data[0].embedding
print(f"向量维度: {len(vector)}")  # 1536
print(f"前5个数字: {vector[:5]}")  # [0.023, -0.012, ...]

---

【概念2：向量数据库 ------ 智能图书馆】

一句话是什么：专门存储和搜索向量的数据库，能快速找到"意思相近"的内容。

生活化比喻：

传统数据库 vs 向量数据库：

📚 传统图书馆（关键词搜索）：
   - 你说"猫"，只能找到标题带"猫"的书
   - 你说"毛茸茸的小动物"，找不到！
   - 只认字，不懂意思

🧠 智能图书馆（向量搜索）：
   - 你说"毛茸茸的小动物"
   - 它理解你想找什么
   - 推荐《猫咪百科》《宠物护理》
   - 懂意思，不只认字

常见向量数据库：

开源方案：
- Chroma DB：轻量级，适合入门
- Milvus：高性能，适合大规模
- Qdrant：Rust写的，性能好

云服务：
- Pinecone：托管服务，开箱即用
- Weaviate：功能丰富

传统数据库扩展：
- PostgreSQL + pgvector
- Elasticsearch + 向量插件

---

【概念3：文档分块 ------ 把大象装进冰箱】

一句话是什么：把长文档切成小段，方便检索和处理。

生活化比喻：

想象你要在一本500页的书里找答案：

❌ 不分块：
   - 把整本书塞给AI
   - AI说："太长了，处理不了！"
   - 或者处理了，但找不到重点

✅ 分块后：
   - 把书按章节切成小段
   - 每段200-500字
   - 用户问问题时，只找相关的几段
   - AI处理起来轻松，答案也精准

分块策略：

# 常见分块方法
from langchain.text_splitter import CharacterTextSplitter

# 方法1：按字符数分块
splitter = CharacterTextSplitter(
    chunk_size=500,      # 每块500字符
    chunk_overlap=50     # 块之间重叠50字符（保持上下文）
)

# 方法2：按段落分块
# 方法3：按语义分块（更智能）

# 分块原则：
# 1. 不要太大（超过LLM上下文限制）
# 2. 不要太小（丢失上下文）
# 3. 保持语义完整（别把一句话切两半）

---

【概念4：RAG工作流程 ------ 完整的"开卷考试"】

完整流程：

第一阶段：准备资料（离线）
┌─────────────────────────────────────┐
│  原始文档 → 分块 → Embedding → 存入向量数据库  │
└─────────────────────────────────────┘

第二阶段：回答问题（在线）
┌─────────────────────────────────────┐
│  用户问题 → Embedding → 向量搜索 →     │
│  找到相关块 → 组装提示词 → LLM生成答案   │
└─────────────────────────────────────┘

代码示例：

# 简化的RAG流程
class SimpleRAG:
    def __init__(self, vector_db, llm):
        self.vector_db = vector_db
        self.llm = llm
    
    def answer(self, question):
        # 1. 搜索相关文档
        relevant_docs = self.vector_db.search(question, top_k=3)
        
        # 2. 组装提示词
        context = "\n".join([doc.content for doc in relevant_docs])
        prompt = f"""
        根据以下资料回答问题。如果资料中没有相关信息，请说明。
        
        资料：
        {context}
        
        问题：{question}
        
        回答：
        """
        
        # 3. 生成答案
        answer = self.llm.generate(prompt)
        
        # 4. 返回答案和来源
        return {
            "answer": answer,
            "sources": [doc.source for doc in relevant_docs]
        }

---

【概念5：Agentic RAG ------ 智能升级版】

一句话是什么：给RAG加上"智能体"，让它能判断、筛选、多步推理。

生活化比喻：

普通RAG vs Agentic RAG：

📖 普通RAG（普通学生）：
   - 找到什么资料就用什么
   - 不管资料新不新、对不对
   - 有时候答非所问

🎓 Agentic RAG（学霸）：
   - 找到资料后先判断：这个靠谱吗？
   - 发现矛盾会选择更权威的来源
   - 信息不够会继续搜索
   - 复杂问题会分步骤解决

Agentic RAG的能力：

# Agentic RAG的智能行为

class AgenticRAG:
    def answer(self, question):
        # 1. 检索相关文档
        docs = self.retrieve(question)
        
        # 2. 【智能判断】评估文档质量
        validated_docs = self.validate_sources(docs)
        
        # 3. 【冲突处理】如果有矛盾，选择更可靠的
        if self.has_conflicts(validated_docs):
            validated_docs = self.resolve_conflicts(validated_docs)
        
        # 4. 【信息补充】如果不够，继续搜索
        if not self.is_sufficient(validated_docs, question):
            more_docs = self.search_external(question)
            validated_docs.extend(more_docs)
        
        # 5. 生成答案
        return self.generate_answer(validated_docs, question)

---

四、实践示例

示例1：使用Google Search做RAG

from google.adk.tools import google_search
from google.adk.agents import Agent

# 创建一个能搜索的Agent
search_agent = Agent(
    name="research_assistant",
    model="gemini-2.0-flash-exp",
    instruction="你是一个研究助手。当被问到问题时，使用Google搜索工具获取最新信息。",
    tools=[google_search]
)

# 现在这个Agent可以回答最新的问题了！
# 比如："今天的新闻头条是什么？"

示例2：使用LangChain构建完整RAG

from langchain_community.document_loaders import TextLoader
from langchain.text_splitter import CharacterTextSplitter
from langchain_community.embeddings import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA

# 1. 加载文档
loader = TextLoader('./company_docs.txt')
documents = loader.load()

# 2. 分块
text_splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = text_splitter.split_documents(documents)

# 3. 创建向量数据库
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(chunks, embeddings)

# 4. 创建RAG链
llm = ChatOpenAI(model="gpt-4")
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vectorstore.as_retriever()
)

# 5. 提问
answer = qa_chain.run("公司的报销流程是什么？")
print(answer)

---

五、精华提炼（去废话版）

核心要点

1. RAG = 检索 + 增强 + 生成

   • 先查资料，再回答
   • 解决AI知识过时、幻觉问题
   • 让AI能访问私有数据

2. Embedding是基础

   • 把文字变成向量
   • 意思相近的向量也相近
   • 质量决定检索效果

3. 向量数据库是核心

   • 存储和搜索向量
   • 按"意思"而非"关键词"搜索
   • 选择适合自己的方案

4. Agentic RAG是进阶

   • 加入智能判断
   • 能处理冲突和不足
   • 多步推理更可靠

砍掉的废话

• 复杂的数学公式（知道原理就够了）
• 各种向量数据库的详细对比（用的时候再查）
• 过多的学术定义（实用为主）

必须记住的

RAG三步走：
1. 准备阶段：文档 → 分块 → 向量化 → 存储
2. 检索阶段：问题 → 向量化 → 搜索 → 找到相关内容
3. 生成阶段：相关内容 + 问题 → LLM → 答案

---

六、行动清单

立即可做（5分钟内）

• 理解RAG的基本流程：检索→增强→生成
• 了解Embedding的作用：把文字变成可计算的向量

本周实践

• 用LangChain搭建一个简单的RAG系统
• 尝试不同的分块策略，观察效果差异

进阶挑战

• 实现Agentic RAG，加入来源验证
• 优化检索效果：混合搜索、重排序

---

七、常见误区

误区1："RAG能解决所有AI幻觉问题"

真相：

RAG能减少幻觉，但不能完全消除：
- 如果检索到的内容本身有错，AI还是会出错
- 如果检索不到相关内容，AI可能还是会编
- 需要配合其他手段（如来源验证、置信度评估）

误区2："分块越小越好"

真相：

分块太小的问题：
- 丢失上下文，AI理解不完整
- 检索到的片段可能断章取义
- 需要检索更多块，增加成本

分块太大的问题：
- 超过LLM上下文限制
- 包含太多无关信息
- 检索精度下降

最佳实践：根据内容类型调整，通常200-1000字符

误区3："向量搜索一定比关键词搜索好"

真相：

各有优势：
- 向量搜索：理解语义，适合模糊查询
- 关键词搜索：精确匹配，适合专有名词

最佳实践：混合搜索（Hybrid Search）
- 结合两者优势
- 先向量搜索找语义相关
- 再关键词搜索精确匹配

---

八、学习检查

基础知识

• 能解释RAG的三个字母分别代表什么
• 理解Embedding的作用和原理
• 知道向量数据库和传统数据库的区别

实践能力

• 能搭建一个基本的RAG系统
• 能选择合适的分块策略
• 能评估RAG系统的效果

进阶理解

• 理解Agentic RAG的优势
• 能处理RAG中的常见问题（幻觉、检索不准等）
• 能优化RAG系统的性能

---

九、金句收藏

原文金句：

"RAG使LLM能够访问并整合外部的、当前的、特定上下文的信息，
从而增强其输出的准确性、相关性和事实基础。"

我的总结金句：

"AI不是万能的，但RAG让它学会了'不懂就查'；
与其让AI瞎编，不如让它先翻书再回答。"

---

十、画龙点睛（收尾）

总结升华

RAG不仅仅是一个技术方案，更是一种思维方式：

• 承认AI的局限性（知识有限、可能幻觉）
• 用工程方法弥补（检索增强）
• 让AI从"记忆型"变成"学习型"

就像一个聪明的学生：

• 不是什么都记在脑子里
• 而是知道去哪里找答案
• 找到后能理解、整合、表达

悬念预告

学会了RAG，AI能查资料了。但如果有多个AI智能体，它们之间怎么沟通协作？下一章"智能体间通信（A2A）"，我们来揭秘！

一句话带走

RAG = 让AI学会"开卷考试"
先查资料，再回答，有据可依，减少瞎编！

---

十一、延伸资源

想深入学习

• LangChain官方文档：RAG最佳实践
• Pinecone学习中心：向量数据库入门

想教给别人

• 用"开卷考试vs闭卷考试"的比喻解释RAG
• 用"智能图书馆"的比喻解释向量数据库

---

第15章：智能体间通信（A2A）------ AI的"社交网络"

一句话定位：A2A协议就是AI智能体之间的"社交网络"，让不同框架、不同公司开发的AI能够互相认识、互相合作，一起完成复杂任务。

---

一、秒懂定位（30秒版）

这个知识解决什么问题：

一个AI智能体再强，也有局限
复杂任务需要多个专家协作
但不同框架的AI"语言不通"！

A2A = Agent to Agent（智能体到智能体）
让不同AI能互相沟通、协作
就像给AI建了一个"联合国"

一句话精华：

A2A = AI之间的通用语言
不管你是用LangChain还是ADK开发的
都能互相对话、协作完成任务

适合谁学 ：需要构建多智能体系统、跨框架协作的开发者
不适合谁：只用单个AI完成简单任务的场景

---

二、核心框架（知识骨架）

生活化比喻：AI的"联合国"

想象一个国际项目需要多国专家协作：

🌍 没有A2A之前（各说各话）：
   - 中国专家说中文
   - 美国专家说英文
   - 法国专家说法语
   - 互相听不懂，无法协作

🤝 有了A2A之后（统一语言）：
   - 大家都用"联合国官方语言"
   - 每个专家有"名片"介绍自己能做什么
   - 需要帮助时，知道找谁
   - 任务可以分工、协作、交接

A2A就是AI世界的"联合国官方语言"！

关键概念速查表

概念	大白话解释	生活比喻	一句话记忆
A2A协议	AI之间的通信标准	联合国官方语言	让不同AI能对话
Agent Card	智能体的"名片"	个人简历	介绍自己能做什么
Client Agent	发起请求的AI	甲方	需要帮助的一方
Server Agent	提供服务的AI	乙方	提供能力的一方
Task	一个工作单元	工单	要完成的具体事项
Skill	智能体的能力	专业技能	能做什么事

知识地图

用户请求 → [Client Agent]
              ↓
         发现可用的Server Agents
         （通过Agent Card）
              ↓
         选择合适的Agent
              ↓
         发送Task请求
              ↓
         [Server Agent处理]
              ↓
         返回结果
              ↓
         [Client Agent整合]
              ↓
         输出给用户

---

三、深入浅出讲解（教学版）

开场钩子

"你用LangChain开发了一个AI，我用Google ADK开发了一个AI，他用CrewAI开发了一个AI。现在老板说：'把这三个AI组成一个团队！'------怎么办？这就是A2A要解决的问题！"

核心讲解

【概念1：A2A协议 ------ AI的"普通话"】

一句话是什么：Google推出的开放标准，让不同框架开发的AI智能体能够互相通信。

生活化比喻：

想象一个国际公司：
- 研发部用Python
- 财务部用Excel
- 销售部用CRM系统
- 大家数据格式都不一样！

怎么协作？
- 定义统一的数据交换格式
- 大家都按这个格式来
- 不管内部用什么，对外统一

A2A就是AI世界的"统一数据格式"：
- 不管你用什么框架开发
- 对外都用A2A协议通信
- 这样不同AI就能协作了

支持A2A的公司：

Google、Microsoft、Atlassian、Box、
LangChain、MongoDB、Salesforce、SAP、ServiceNow...

这不是一家公司的私有协议
而是行业共同认可的开放标准！

---

【概念2：Agent Card ------ AI的"名片"】

一句话是什么：一个JSON文件，描述智能体的身份、能力、如何联系它。

生活化比喻：

想象你参加一个行业大会：
- 每个人都有名片
- 名片上写着：姓名、公司、职位、联系方式、擅长什么

Agent Card就是AI的名片：
- 我叫什么（name）
- 我能做什么（skills）
- 怎么联系我（url）
- 我支持什么功能（capabilities）

Agent Card示例：

{
  "name": "天气助手",
  "description": "提供准确的天气预报和历史数据",
  "url": "http://weather-service.example.com/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "get_current_weather",
      "name": "获取当前天气",
      "description": "查询任意地点的实时天气",
      "examples": [
        "北京今天天气怎么样？",
        "上海现在的温度是多少？"
      ]
    },
    {
      "id": "get_forecast",
      "name": "获取天气预报",
      "description": "获取未来5天的天气预测",
      "examples": [
        "深圳这周末会下雨吗？",
        "广州未来三天的天气"
      ]
    }
  ]
}

---

【概念3：智能体发现 ------ 找到合适的"专家"】

一句话是什么：Client Agent如何找到能帮忙的Server Agent。

三种发现方式：

方式1：Well-Known URI（公开名片）
- Agent把名片放在固定位置
- 比如：/.well-known/agent.json
- 任何人都能访问
- 适合公开服务

方式2：注册中心（人才市场）
- 有一个集中的"人才库"
- Agent注册自己的能力
- Client去人才库搜索
- 适合企业内部

方式3：直接配置（内部通讯录）
- 直接告诉Client：这个Agent在这里
- 不需要动态发现
- 适合固定的协作关系

---

【概念4：通信方式 ------ 怎么"说话"】

A2A支持多种通信模式：

模式1：同步请求/响应（打电话）
- Client发请求，等着Server回复
- 适合快速、简单的任务
- 例如：查个天气

模式2：异步轮询（发邮件）
- Client发请求，Server说"收到，处理中"
- Client过一会儿再来问"好了没"
- 适合耗时较长的任务
- 例如：生成一份报告

模式3：流式更新（直播）
- Server一边处理，一边推送进度
- Client实时收到更新
- 适合需要实时反馈的任务
- 例如：实时翻译

模式4：推送通知（短信通知）
- Client留个回调地址
- Server完成后主动通知
- 适合很长时间的任务
- 例如：训练一个模型

代码示例：

// 同步请求示例
{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "sendTask",
  "params": {
    "id": "task-001",
    "message": {
      "role": "user",
      "parts": [
        {
          "type": "text",
          "text": "美元兑欧元的汇率是多少？"
        }
      ]
    }
  }
}

---

【概念5：A2A vs MCP ------ 两个协议的区别】

一句话区分：

MCP（Model Context Protocol）：
- AI和工具之间的通信
- 让AI能使用外部工具
- 比如：AI调用数据库、API

A2A（Agent to Agent）：
- AI和AI之间的通信
- 让多个AI能协作
- 比如：规划Agent调用执行Agent

形象比喻：

MCP = 人和工具的关系
- 你用锤子钉钉子
- 你用电脑写代码
- 工具听你指挥

A2A = 人和人的关系
- 你和同事协作
- 你委托别人做事
- 双方都有自主性

---

四、实践示例

示例1：创建一个A2A Server

from google.adk.agents import LlmAgent
from google.adk.tools.google_api_tool import CalendarToolset

async def create_calendar_agent(client_id, client_secret):
    """创建一个日历管理Agent"""
    
    # 初始化日历工具
    toolset = CalendarToolset(
        client_id=client_id, 
        client_secret=client_secret
    )
    
    # 创建Agent
    return LlmAgent(
        model='gemini-2.0-flash-001',
        name='calendar_agent',
        description="帮助用户管理日历的智能体",
        instruction="""
        你是一个日历管理助手。
        用户会请求查看日历或修改日程。
        使用提供的工具与日历API交互。
        """,
        tools=await toolset.get_tools(),
    )

示例2：定义Agent Card和启动服务

from a2a import AgentCard, AgentSkill, AgentCapabilities
from a2a.server import A2AStarletteApplication

# 定义技能
skill = AgentSkill(
    id='check_availability',
    name='检查空闲时间',
    description="检查用户在某个时间段是否有空",
    examples=['我明天上午10点到11点有空吗？'],
)

# 定义Agent Card
agent_card = AgentCard(
    name='日历助手',
    description="帮助管理用户日历的智能体",
    url='http://localhost:8000/',
    version='1.0.0',
    capabilities=AgentCapabilities(streaming=True),
    skills=[skill],
)

# 启动A2A服务
app = A2AStarletteApplication(
    agent_card=agent_card,
    http_handler=request_handler
)

示例3：多Agent协作场景

"""
场景：旅行规划
- 用户说："帮我规划下周去上海的出差"
- 需要多个Agent协作：
  1. 日历Agent：检查用户时间
  2. 航班Agent：搜索航班
  3. 酒店Agent：预订酒店
  4. 天气Agent：查询天气
"""

class TravelPlannerAgent:
    def __init__(self):
        # 发现可用的Agent
        self.calendar_agent = discover_agent("calendar")
        self.flight_agent = discover_agent("flight")
        self.hotel_agent = discover_agent("hotel")
        self.weather_agent = discover_agent("weather")
    
    async def plan_trip(self, destination, dates):
        # 1. 检查日历
        availability = await self.calendar_agent.call(
            "check_availability", 
            {"dates": dates}
        )
        
        # 2. 搜索航班
        flights = await self.flight_agent.call(
            "search_flights",
            {"destination": destination, "dates": dates}
        )
        
        # 3. 搜索酒店
        hotels = await self.hotel_agent.call(
            "search_hotels",
            {"destination": destination, "dates": dates}
        )
        
        # 4. 查询天气
        weather = await self.weather_agent.call(
            "get_forecast",
            {"location": destination, "dates": dates}
        )
        
        # 5. 整合结果
        return self.compile_plan(availability, flights, hotels, weather)

---

五、精华提炼（去废话版）

核心要点

1. A2A = AI之间的通用语言

   • 让不同框架的AI能协作
   • Google推出的开放标准
   • 行业广泛支持

2. Agent Card = AI的名片

   • 描述身份、能力、联系方式
   • 让其他Agent知道你能做什么
   • JSON格式，易于解析

3. 多种通信模式

   • 同步：快速简单任务
   • 异步：耗时任务
   • 流式：实时反馈
   • 推送：超长任务

4. A2A vs MCP

   • MCP：AI和工具
   • A2A：AI和AI
   • 两者互补，不是替代

砍掉的废话

• 协议的详细技术规范（用的时候再查）
• 各种边缘情况的处理（先掌握主流程）
• 过多的安全细节（知道要注意就行）

必须记住的

A2A三要素：
1. Agent Card：告诉别人你是谁、能做什么
2. 发现机制：找到能帮忙的Agent
3. 通信协议：用统一的方式交流

---

六、行动清单

立即可做（5分钟内）

• 理解A2A解决的问题：让不同AI能协作
• 理解Agent Card的作用：AI的"名片"

本周实践

• 创建一个简单的Agent Card
• 尝试用A2A协议让两个Agent通信

进阶挑战

• 构建一个多Agent协作系统
• 实现不同框架Agent的互操作

---

七、常见误区

误区1："A2A会取代MCP"

真相：

两者是互补关系，不是替代关系：

MCP解决：AI如何使用工具
- AI调用数据库
- AI调用API
- AI执行代码

A2A解决：AI如何协作
- AI委托任务给另一个AI
- 多个AI分工合作
- 跨框架AI通信

一个完整的系统可能同时需要两者！

误区2："所有AI都需要A2A"

真相：

A2A适合的场景：
- 多个AI需要协作
- 不同框架的AI需要通信
- 需要动态发现和调用AI服务

不需要A2A的场景：
- 单个AI就能完成任务
- 所有AI都用同一个框架
- 固定的、简单的调用关系

误区3："A2A很复杂，学不会"

真相：

A2A的核心其实很简单：
1. 定义一个Agent Card（JSON文件）
2. 暴露一个HTTP端点
3. 按照协议格式通信

就像学HTTP一样：
- 不需要理解所有细节
- 先会用，再深入
- 有现成的库可以用

---

八、学习检查

基础知识

• 能解释A2A是什么、解决什么问题
• 理解Agent Card的作用和结构
• 知道A2A和MCP的区别

实践能力

• 能创建一个Agent Card
• 能搭建一个简单的A2A Server
• 能让两个Agent通过A2A通信

进阶理解

• 理解不同通信模式的适用场景
• 能设计多Agent协作的架构
• 能处理A2A中的错误和异常

---

九、金句收藏

原文金句：

"A2A协议是旨在实现不同AI智能体框架之间通信与协作的开放标准。
它确保了互操作性，允许使用不同技术开发的AI智能体协同工作。"

我的总结金句：

"一个AI再强，也比不上一群AI协作；
A2A让AI从'单打独斗'变成'团队作战'。"

---

十、画龙点睛（收尾）

总结升华

A2A不仅仅是一个技术协议，更代表了AI发展的趋势：

• 从单一AI到多AI协作
• 从封闭系统到开放生态
• 从各自为战到统一标准

就像互联网的发展：

• 早期各个网络互不相通
• 有了TCP/IP协议后，全球互联
• A2A可能成为AI世界的"TCP/IP"

悬念预告

学会了A2A，多个AI能协作了。但AI运行需要资源，怎么在有限的预算和时间内做出最好的决策？下一章"资源感知优化"，我们来揭秘！

一句话带走

A2A = AI的"联合国语言"
让不同框架、不同公司的AI能够互相认识、互相协作！

---

十一、延伸资源

想深入学习

• Google A2A官方文档
• A2A示例代码库：github.com/google-a2a/a2a-samples

想教给别人

• 用"联合国"的比喻解释A2A
• 用"名片"的比喻解释Agent Card

---