Agent on impself小破站

Agent 08-记忆与检索

Thu, 26 Feb 2026 21:42:09 +0800

智能体记忆系统与RAG系统 - 问题详解

1. 情景记忆 vs 语义记忆评分机制对比

评分公式对比

情景记忆评分公式：

`1`	`score = 0.4 × recency + 0.3 × importance + 0.2 × access + 0.1 × embedding`

语义记忆评分公式：

`1`	`score = 0.3 × graph_retrieval + 0.25 × embedding + 0.25 × access + 0.2 × importance`

设计原因分析

维度	情景记忆	语义记忆	设计原因
时间权重 (recency)	0.4	0.0	情景记忆记录"我在何时何地做了什么"，新鲜度至关重要；语义记忆是持久知识，与时间无关
图检索权重 (graph_retrieval)	0.0	0.3	语义记忆基于知识图谱，概念间的关系推理是核心优势
嵌入权重 (embedding)	0.1	0.25	语义记忆更注重语义相似性匹配
重要性权重 (importance)	0.3	0.2	情景记忆中某些事件可能特别重要（如里程碑事件）
访问权重 (access)	0.2	0.25	两者都考虑访问频率，但语义记忆更重视知识的复用

核心设计理念

情景记忆 = “时间线上的故事”

强调时间近因性：最近发生的事情更相关
类比人类的短期事件记忆
适用于：“我昨天看了什么电影？“这类查询

语义记忆 = “知识网络中的概念”

强调关系推理：通过图结构发现关联
类比人类的知识体系
适用于：“什么是深度学习？“这类概念查询

2. 个人健康管理助手的记忆设计

整体架构

┌─────────────────────────────────────────────────────────────┐
│                   个人健康管理助手                            │
├─────────────────────────────────────────────────────────────┤
│  工作记忆              情景记忆              语义记忆         │
│  ┌─────────┐        ┌─────────┐        ┌─────────┐         │
│  │当前对话│        │饮食记录 │        │营养知识 │         │
│  │输入状态 │        │运动日志 │        │医学概念 │         │
│  │暂存数据 │        │睡眠数据 │        │健康图谱 │         │
│  └─────────┘        └─────────┘        └─────────┘         │
│       ↓                  ↓                  ↓                │
│  TTL=5分钟         重要性衰减          知识推理             │
│                                                ↑            │
│  感知记忆 ────────────────────────────────────┘            │
│  ┌─────────┐                                                 │
│  │设备数据 │  实时同步：心率、步数、血氧、体温                │
│  │环境数据 │  定期采样：天气、空气质量、季节                   │
│  └─────────┘                                                 │
└─────────────────────────────────────────────────────────────┘

具体应用场景

记忆类型	应用场景	数据示例	检索示例
工作记忆	对话状态管理	用户当前输入的饮食内容	“我刚才说今天早餐吃了什么？”
情景记忆	健康行为追踪	“2024-01-15早餐：燕麦牛奶”	“上周三的跑步记录是什么？”
语义记忆	健康知识推理	“缺乏维生素D → 需要晒太阳”	“素食者容易缺乏什么营养素？”
感知记忆	实时数据流	手环心率：85 bpm	“我当前心率是多少？”

数据流向示例

用户说："我今天跑步了5公里"
    ↓
┌─────────────────┐
│  工作记忆（暂存） │ ← 存储原始输入
└─────────────────┘
    ↓ (5分钟后未提及)
┌─────────────────┐
│  整合到情景记忆  │ ← "2024-01-20 跑步5公里，耗时30分钟"
└─────────────────┘
    ↓ (与历史数据关联)
┌─────────────────┐
│  更新语义记忆    │ ← "用户每周运动3次，属于活跃用户"
└─────────────────┘

3. 工作记忆整合机制设计

整合决策矩阵

┌────────────────────────────────────────────────────────────┐
│                    工作记忆 → 长期记忆 整合触发条件             │
├────────────────────────────────────────────────────────────┤
│                                                             │
│  触发信号            │  整合目标           │  延迟           │
│  ─────────────        │  ─────────         │  ────           │
│  用户明确要求记住      │  → 情景记忆         │  立即            │
│  对话中反复提及(≥3次)  │  → 语义记忆         │  第3次触发       │
│  与现有知识关联        │  → 语义记忆(关联)   │  匹配时          │
│  情感标记(重要/紧急)   │  → 情景记忆(高重要性)│ 检测时          │
│  时间窗口持续(>1小时)  │  → 模式识别         │  到期触发         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

自动整合算法实现

class MemoryConsolidation:
    """工作记忆整合机制"""

    def should_consolidate(self, work_item, context):
        """判断工作记忆是否需要整合"""
        score = 0
        reasons = []

        # 1. 用户明确指示 (最高优先级)
        if work_item.get("explicit_remember"):
            return {"action": "immediate", "target": "episodic"}

        # 2. 提及频率检测
        mention_count = work_item.get("mention_count", 0)
        if mention_count >= 3:
            score += 0.4
            reasons.append("频繁提及")
            return {"action": "consolidate", "target": "semantic"}

        # 3. 知识关联检测
        if self._has_related_knowledge(work_item, context):
            score += 0.3
            reasons.append("存在关联知识")

        # 4. 情感重要性检测
        sentiment = work_item.get("sentiment")
        if sentiment in ["urgent", "important", "emotional"]:
            score += 0.5
            reasons.append("情感标记")
            return {"action": "immediate", "target": "episodic"}

        # 5. 时间阈值检测
        age_seconds = time.time() - work_item.get("created_at", time.time())
        if age_seconds > 3600:  # 1小时
            score += 0.2
            reasons.append("时间阈值")

        # 综合判断
        if score >= 0.5:
            return {
                "action": "consolidate",
                "target": "semantic" if score > 0.6 else "episodic",
                "reasons": reasons
            }

        return {"action": "keep", "score": score}

    def _has_related_knowledge(self, item, context):
        """检测是否与现有知识关联"""
        # 检查实体重叠
        item_entities = set(item.get("entities", []))
        context_entities = set(context.get("recent_entities", []))

        overlap = item_entities & context_entities
        return len(overlap) > 0

4. 基于语义边界的分块算法

问题背景

对于没有明确标题结构的文档（如小说、法律条文），传统的基于Markdown标题的分块策略失效，需要基于语义边界进行智能分块。

语义边界检测算法

import numpy as np
from sentence_transformers import SentenceTransformer

class SemanticChunker:
    """基于语义边界的智能分块"""

    def __init__(self, model_name="paraphrase-multilingual-MiniLM"):
        self.encoder = SentenceTransformer(model_name)

    def chunk(self, text, max_chunk_size=1000, min_chunk_size=200):
        """
        主分块方法

        Args:
            text: 输入文本
            max_chunk_size: 最大块大小（字符数）
            min_chunk_size: 最小块大小（字符数）
        """
        # 1. 按句子分割
        sentences = self._split_sentences(text)

        # 2. 计算句子嵌入
        embeddings = self.encoder.encode(sentences)

        # 3. 检测语义边界
        boundaries = self._detect_boundaries(embeddings)

        # 4. 在边界处创建chunks
        chunks = self._create_chunks(
            sentences, boundaries, max_chunk_size, min_chunk_size
        )

        return chunks

    def _detect_boundaries(self, embeddings, window_size=3, threshold=0.5):
        """
        检测语义边界

        核心思想：如果相邻两个窗口内的语义相似度都显著高于跨边界的相似度，
        则认为此处存在语义边界。
        """
        boundaries = [0]  # 第一个句子总是边界

        for i in range(window_size, len(embeddings) - window_size):
            # 计算前窗口内的平均相似度
            before_window = embeddings[i-window_size:i]
            before_similarity = self._avg_similarity(before_window)

            # 计算后窗口内的平均相似度
            after_window = embeddings[i:i+window_size]
            after_similarity = self._avg_similarity(after_window)

            # 计算跨边界的相似度
            cross_similarity = self._cosine_sim(
                before_window[-1], after_window[0]
            )

            # 判断是否为边界：跨边界相似度显著低于窗口内相似度
            avg_window_sim = (before_similarity + after_similarity) / 2

            if cross_similarity < threshold * avg_window_sim:
                boundaries.append(i)

        boundaries.append(len(embeddings))
        return boundaries

    def _avg_similarity(self, embeddings):
        """计算嵌入序列内的平均相似度"""
        if len(embeddings) < 2:
            return 1.0

        similarities = [
            self._cosine_sim(embeddings[i], embeddings[i+1])
            for i in range(len(embeddings) - 1)
        ]
        return np.mean(similarities)

    def _cosine_sim(self, a, b):
        """计算余弦相似度"""
        return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

不同文档类型的分块策略

文档类型	分块策略	实现要点
小说	章节边界 + 场景转换	检测"第X章"模式 + 对话/叙述交替
法律条文	条款边界 + 层级结构	检测"第X条"模式 + 缩进层级
学术论文	章节结构 + 段落完整性	Markdown标题 + 段落边界
技术文档	代码块独立 + API分组	识别代码块 + 按功能分组
新闻文章	段落语义连贯性	语义边界检测

5. MQE vs HyDE 检索策略对比

检索方法对比

检索方法	原理	查询示例	优缺点
基础检索	直接查询embedding	“如何配置API密钥？”	✅ 简单快速 ❌ 召回率低
MQE	多查询扩展	→ [“如何配置API密钥？”, “如何设置密钥？”, “在哪里配置凭证？”]	✅ 召回率高 ⚠️ 融合复杂
HyDE	假设文档嵌入	→ 生成假设文档，用假设文档embedding检索	✅ 精确度高 ❌ 依赖生成质量

场景选择矩阵

┌─────────────────────────────────────────────────────────────┐
│                    检索策略选型指南                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  查询类型             │  最佳策略          │  原因          │
│  ──────────             │  ─────────         │  ────          │
│  精确术语查询            │  基础检索          │  术语明确，无需扩展│
│  模糊/口语化查询         │  MQE               │  多样化表达提高召回│
│  复杂概念查询            │  HyDE              │  假设文档捕获语义  │
│  多步骤问题              │  MQE + HyDE        │  组合拳效果最好    │
│  领域专业查询            │  基础 + 重排序      │  减少幻觉风险      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

实际场景效果对比

场景：技术文档问答

查询：“如何配置API密钥？”

检索方法	召回结果	效果评估
基础检索	找到3个相关片段	遗漏了使用"设置”、“凭证"等同义词的文档
MQE	找到8个相关片段	✅ 召回率提升约150%
HyDE	找到5个相关片段	精确度更高，匹配到配置步骤详解

6. 嵌入方案选型对比

三种方案全面对比

维度	百炼API	本地Transformer	TF-IDF
准确性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐
速度	⭐⭐⭐ (网络延迟50-200ms)	⭐⭐⭐⭐ (GPU加速，<50ms)	⭐⭐⭐⭐⭐ (<10ms)
成本	按调用付费	硬件+电费	免费
离线部署	❌	✅	✅
语言支持	中英双语优秀	需选择合适模型	统计方法，无语义理解
维护复杂度	低	中(模型更新)	低
可定制性	低	高	中
规模化成本	随调用量线性增长	固定成本	几乎无成本

选型决策树

是否需要离线部署？
│
├── 是 → 是否有GPU资源？
│        │
│        ├── 是 → 本地Transformer (推荐)
│        └── 否 → TF-IDF (备用方案)
│
└── 否 → 是否有预算？
         │
         ├── 是 → 百炼API (推荐，准确性最高)
         │
         └── 否 → 考虑混合方案：
                  • 热数据用API (保证质量)
                  • 冷数据用本地 (降低成本)

混合方案建议

class HybridEmbedding:
    """混合嵌入方案：API + 本地兜底"""

    def __init__(self):
        self.api_client = BailianEmbedding()  # 主力
        self.local_model = LocalModel()       # 备用

    def encode(self, texts):
        """智能路由编码请求"""
        try:
            # 正常情况下使用API
            return self.api_client.encode(texts)
        except Exception as e:
            # API失败时降级到本地模型
            logger.warning(f"API failed, using local: {e}")
            return self.local_model.encode(texts)

7. 智能遗忘策略实现

多因素加权遗忘算法

class IntelligentForgetting:
    """智能遗忘策略：综合多因素的遗忘决策"""

    def __init__(self, weights=None):
        self.weights = weights or {
            'importance': 0.30,    # 重要性权重
            'frequency': 0.25,     # 访问频率权重
            'recency': 0.25,       # 时间权重
            'connectivity': 0.20   # 连接性权重
        }

    def calculate_forgetting_score(self, memory):
        """
        计算遗忘分数：分数越高越应该遗忘

        返回: (forgetting_score, detail_scores)
        """
        scores = {
            'importance': self._importance_score(memory),
            'frequency': self._frequency_score(memory),
            'recency': self._recency_score(memory),
            'connectivity': self._connectivity_score(memory)
        }

        # 加权综合
        forgetting_score = sum(
            scores[k] * self.weights[k]
            for k in scores
        )

        return forgetting_score, scores

    def _importance_score(self, memory):
        """
        重要性转换为遗忘倾向（反向）

        重要性越高 → 遗忘倾向越低
        """
        original = memory.get('importance', 0.5)
        return 1 - original

    def _frequency_score(self, memory):
        """
        访问频率转换为遗忘倾向（反向）

        访问越多 + 距离上次访问越短 → 遗忘倾向越低
        """
        access_count = memory.get('access_count', 0)
        days_since_last = memory.get('days_since_last_access', 0)

        # 访问越多 → 遗忘倾向越低
        frequency_factor = 1 / (1 + access_count * 0.1)

        # 距上次访问越久 → 遗忘倾向越高
        recency_penalty = min(days_since_last * 0.02, 0.5)

        return frequency_factor + recency_penalty

    def _recency_score(self, memory):
        """
        时间衰减：越旧越容易遗忘

        使用S曲线：刚开始遗忘慢，中间加速，后期趋缓
        """
        age_days = memory.get('age_days', 0)

        # Sigmoid函数
        return 1 / (1 + np.exp(-0.05 * (age_days - 60)))

    def _connectivity_score(self, memory):
        """
        连接性：与其他记忆关联少 → 更容易遗忘

        在图数据库中查询相关节点数量
        """
        related_count = self._get_related_memory_count(memory['id'])
        return 1 / (1 + related_count * 0.2)

遗忘决策阈值

# 遗忘阈值设定
FORGETTING_THRESHOLDS = {
    'immediate': 0.8,      # 立即遗忘
    'gradual': 0.6,        # 逐渐降低优先级
    'archive': 0.4,        # 归档
    'keep': 0.4            # 保留
}

def decide_forget_action(memory):
    """根据遗忘分数决定操作"""
    score, _ = forgetting.calculate_forgetting_score(memory)

    if score >= FORGETTING_THRESHOLDS['immediate']:
        return 'delete'
    elif score >= FORGETTING_THRESHOLDS['gradual']:
        return 'deprioritize'
    elif score >= FORGETTING_THRESHOLDS['archive']:
        return 'archive'
    else:
        return 'keep'

8. 记忆归档机制设计

记忆生命周期管理

┌─────────────────────────────────────────────────────────────┐
│                    记忆生命周期管理                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────┐    迁移条件    ┌─────────┐    迁移条件    ┌───────┐│
│  │ 活跃记忆 │  ──────────>  │  温记忆  │  ──────────>  │ 冷存储 ││
│  │ Hot     │              │  Warm    │              │  Cold  ││
│  └─────────┘              └─────────┘              └───────┘│
│                                                             │
│  特征：                    特征：                    特征：    │
│  • 频繁访问                • 偶尔访问                • 长期未访问│
│  • 高重要性                • 中重要性                • 可能有价值│
│  • 最近创建                • 中等时间                • 历史记录  │
│                                                             │
│  迁移策略：                                                │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  活跃 → 温：  7天无访问 + 重要性<0.7                 │   │
│  │  温 → 冷：    30天无访问 + 累计访问<3次                │   │
│  │  冷 → 删除：  90天无访问 + 重要性<0.3                 │   │
│  │  冷 → 活跃：  被关联查询触发                          │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  存储优化：                                                │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  活跃： Qdrant/Neo4j (热索引，毫秒级响应)              │   │
│  │  温：   压缩存储 + 定期重建索引                       │   │
│  │  冷：   对象存储(S3) + 元数据索引                     │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

归档实现示例

class MemoryArchiver:
    """记忆归档管理器"""

    def __init__(self):
        self.storage = {
            'hot': HotStorage(),      # Qdrant + Neo4j
            'warm': WarmStorage(),    # 压缩格式
            'cold': ColdStorage()     # S3 + 元数据
        }

    def evaluate_and_archive(self, memories):
        """评估并执行归档"""
        for memory in memories:
            tier = self._evaluate_tier(memory)
            current_tier = memory.get('storage_tier', 'hot')

            if tier != current_tier:
                self._move_memory(memory, current_tier, tier)

    def _evaluate_tier(self, memory):
        """评估记忆应处于的存储层级"""
        # 计算访问热度
        access_score = self._calculate_access_score(memory)

        # 计算重要性
        importance = memory.get('importance', 0.5)

        if access_score > 0.7 and importance > 0.7:
            return 'hot'
        elif access_score > 0.3 or importance > 0.5:
            return 'warm'
        else:
            return 'cold'

    def _calculate_access_score(self, memory):
        """计算访问热度分数"""
        # 最近访问权重高
        now = time.time()
        last_access = memory.get('last_access', 0)
        days_since = (now - last_access) / 86400

        # 指数衰减
        time_factor = np.exp(-days_since / 7)  # 7天半衰期

        # 访问次数
        count_factor = min(memory.get('access_count', 0) / 10, 1)

        return (time_factor * 0.7 + count_factor * 0.3)

9. 隐私数据彻底清除方案

多层验证清除机制

┌─────────────────────────────────────────────────────────────┐
│              隐私数据清除的多层验证机制                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  第1层：应用层删除                                           │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  DELETE FROM memories                                │   │
│  │  WHERE id = ? AND user_id = ?                        │   │
│  │  同时标记相关引用为"待删除"                            │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↓                                   │
│  第2层：向量数据库清除 (Qdrant)                              │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  qdrant_client.delete(                                │   │
│  │      collection_name=f"user_{user_id}",              │   │
│  │      points_selector=[memory_id]                     │   │
│  │  )                                                    │   │
│  │  验证：retrieve(memory_id) 应返回空                  │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↓                                   │
│  第3层：图数据库清除 (Neo4j)                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  MATCH (m:Memory {id: $id})                          │   │
│  │  DETACH DELETE m, m-[r]-()                            │   │
│  │  处理孤立节点                                         │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↓                                   │
│  第4层：备份区清除                                          │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  从归档存储删除                                     │   │
│  │  清除日志中的敏感信息                               │   │
│  │  清除缓存                                           │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↓                                   │
│  第5层：验证确认                                            │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  全域搜索验证                                         │   │
│  │  生成清除报告供审计                                   │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

实现代码

class PrivacyCleaner:
    """隐私数据彻底清除"""

    def __init__(self, qdrant_client, neo4j_driver, storage):
        self.qdrant = qdrant_client
        self.neo4j = neo4j_driver
        self.storage = storage

    def delete_memory(self, user_id, memory_id):
        """彻底删除记忆"""
        deletion_report = {
            'memory_id': memory_id,
            'steps': [],
            'success': True
        }

        # 第1步：应用层删除
        deletion_report['steps'].append(self._delete_from_app(memory_id))

        # 第2步：向量数据库删除
        deletion_report['steps'].append(
            self._delete_from_qdrant(user_id, memory_id)
        )

        # 第3步：图数据库删除
        deletion_report['steps'].append(
            self._delete_from_neo4j(memory_id)
        )

        # 第4步：存储删除
        deletion_report['steps'].append(
            self._delete_from_storage(memory_id)
        )

        # 第5步：验证
        deletion_report['steps'].append(
            self._verify_deletion(memory_id)
        )

        return deletion_report

    def _delete_from_qdrant(self, user_id, memory_id):
        """从Qdrant删除向量"""
        collection = f"user_{user_id}_vectors"

        # 删除向量点
        self.qdrant.delete(
            collection_name=collection,
            points_selector=[memory_id]
        )

        # 验证删除
        result = self.qdrant.retrieve(
            collection_name=collection,
            ids=[memory_id]
        )

        if len(result) == 0:
            return {'step': 'qdrant', 'status': 'success'}
        else:
            return {'step': 'qdrant', 'status': 'failed', 'remains': len(result)}

10. RAG vs Memory 智能路由

智能路由机制

class RetrievalRouter:
    """智能路由：自动选择最佳检索方式"""

    def route(self, query, context):
        """根据查询特征决定检索策略"""
        # 1. 分析查询类型
        query_type = self._classify_query(query)

        # 2. 评估上下文
        context_score = self._evaluate_context(context)

        # 3. 路由决策
        strategy = self._decide(query_type, context_score)

        return strategy

    def _classify_query(self, query):
        """查询分类"""
        features = {
            'has_entity': self._has_named_entity(query),
            'is_personal': self._is_personal_reference(query),
            'is_factual': self._is_factual_query(query),
            'temporal': self._has_temporal_aspect(query)
        }

        # 决策树
        if features['is_personal']:
            return 'memory_primary'
        elif features['has_entity'] and features['is_factual']:
            return 'rag_primary'
        elif features['temporal']:
            return 'memory_primary'
        else:
            return 'hybrid'

    def _decide(self, query_type, context_score):
        """路由决策表"""
        decision_matrix = {
            ('memory_primary', 'high'): ['memory', 'rag'],
            ('memory_primary', 'low'): ['memory'],
            ('rag_primary', 'any'): ['rag'],
            ('hybrid', 'high'): ['rag', 'memory', 'merge'],
            ('hybrid', 'low'): ['rag', 'memory']
        }

        return decision_matrix.get((query_type, context_score), ['rag'])

路由决策表

查询类型	上下文丰富度	推荐策略	理由
“我之前说过…”	高	Memory → RAG	优先检索个人记忆
“什么是Transformer?”	任意	RAG	事实性查询
“上周讨论了什么?”	高	Memory	时间范围查询
“深度学习原理是什么?”	高	RAG + Memory	结合知识和记忆

11. 智能学习报告生成器设计

报告生成器架构

┌─────────────────────────────────────────────────────────────┐
│              智能学习报告生成器架构                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  输入：用户学习历史（问答记录、笔记、行为数据）                │
│                         ↓                                   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              分析引擎模块                              │   │
│  ├─────────────────────────────────────────────────────┤   │
│  │  1. 学习轨迹分析        (情景记忆 + 时间序列)         │   │
│  │  2. 知识图谱构建        (语义记忆 + 图推理)           │   │
│  │  3. 兴趣偏好识别        (访问频率 + 停留时间)         │   │
│  │  4. 学习风格检测        (问题类型 + 笔记模式)         │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↓                                   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              知识盲点识别                              │   │
│  ├─────────────────────────────────────────────────────┤   │
│  │  • 未覆盖的知识领域      (文档覆盖 vs 学习覆盖)       │   │
│  │  • 浅度学习的内容        (单次访问 vs 深度交互)       │   │
│  │  • 遗忘的知识点          (学习后未复习)               │   │
│  │  • 误解的概念            (矛盾问答记录)               │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↓                                   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              推荐引擎                                  │   │
│  ├─────────────────────────────────────────────────────┤   │
│  │  • 复习优先级排序        (遗忘曲线 + 重要性)         │   │
│  │  • 扩展学习建议          (知识图谱关联)               │   │
│  │  • 个性化学习路径        (学习风格匹配)               │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↓                                   │
│  输出：结构化学习报告 + 可视化图表 + 行动建议                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

报告结构示例

{
    "report_id": "report_20240120_user123",
    "generated_at": "2024-01-20T10:30:00Z",
    "summary": {
        "total_study_time": "5.2小时",
        "documents_studied": 3,
        "questions_asked": 15,
        "notes_created": 8
    },
    "learning_analysis": {
        "strengths": ["深度学习基础", "Transformer架构"],
        "weaknesses": ["注意力机制细节", "训练技巧"],
        "knowledge_graph": {
            "nodes": 25,
            "edges": 38,
            "central_concepts": ["神经网络", "反向传播"]
        }
    },
    "knowledge_gaps": [
        {
            "topic": "注意力机制",
            "reason": "从未提问过相关问题",
            "priority": "high",
            "recommendation": "建议学习：Self-Attention、Multi-Head Attention"
        }
    ],
    "review_suggestions": [
        {
            "topic": "Transformer架构",
            "reason": "3天前学习，未复习",
            "urgency": "medium"
        }
    ],
    "next_steps": [
        "深入理解注意力机制",
        "学习BERT和GPT的区别",
        "实践：实现一个简单的Transformer"
    ]
}

12. 多用户数据隔离方案

Qdrant 隔离方案

方案1：独立Collection（推荐）

# 每个用户独立的collection
collection_name = f"user_{user_id}_vectors"

# 优点：
# - 完全隔离，安全
# - 可独立删除
# - 性能互不影响

# 缺点：
# - Collection数量多时管理复杂

方案2：共享Collection + Payload过滤

# 共享collection，通过payload过滤
collection_name = "global_vectors"

# 插入时添加用户标识
point = {
    "id": f"{user_id}_{doc_id}",
    "vector": embedding,
    "payload": {
        "user_id": user_id,
        "document": doc_name
    }
}

# 查询时过滤
search_result = qdrant.search(
    collection_name="global_vectors",
    query_vector=embedding,
    query_filter={
        "must": [
            {"key": "user_id", "match": {"value": user_id}}
        ]
    }
)

Neo4j 隔离方案

-- 方案1：用户根节点（推荐）
MATCH (u:User {id: $user_id})-[:HAS_MEMORY]->(m:Memory)
RETURN m

-- 方案2：节点属性过滤
MATCH (m:Memory {user_id: $user_id})
RETURN m

-- 方案3：标签隔离
MATCH (m:Memory:User_123)
RETURN m

性能优化策略

策略	实现方式	效果
索引优化	`CREATE INDEX ON :Memory(user_id)`	查询速度提升10x
分片策略	按user_id哈希分片	负载均衡
连接池	限制每用户并发数	防止资源耗尽
缓存层	Redis缓存热点用户session	减少数据库压力

13. 知识图谱质量评估

质量评估维度

class KnowledgeGraphQuality:
    """知识图谱质量评估器"""

    def evaluate(self, graph):
        """综合质量评分"""
        return {
            'completeness': self._check_completeness(graph),
            'accuracy': self._check_accuracy(graph),
            'consistency': self._check_consistency(graph),
            'coverage': self._check_coverage(graph),
            'overall': self._calculate_overall(graph)
        }

    def _check_completeness(self, graph):
        """完整性检查"""
        total_nodes = graph.count_nodes()
        isolated_nodes = graph.count_isolated_nodes()
        total_relationships = graph.count_relationships()

        # 完整性指标
        isolation_ratio = isolated_nodes / total_nodes if total_nodes > 0 else 0
        relationship_density = total_relationships / max(total_nodes * (total_nodes - 1) / 2, 1)

        return {
            'isolation_ratio': isolation_ratio,        # 越低越好
            'density': relationship_density,           # 适度最佳
            'score': 1 - isolation_ratio * 0.5         # 转换为分数
        }

    def _check_accuracy(self, graph):
        """准确性检查（需要样本验证）"""
        # 实体类型一致性
        entities = graph.get_all_entities()
        type_conflicts = 0
        for entity in entities:
            if self._has_type_conflict(entity):
                type_conflicts += 1

        # 关系合理性
        relationships = graph.get_all_relationships()
        invalid_rels = 0
        for rel in relationships:
            if not self._is_valid_relation(rel):
                invalid_rels += 1

        return {
            'entity_consistency': 1 - type_conflicts / len(entities),
            'relation_validity': 1 - invalid_rels / len(relationships)
        }

常见错误类型

错误类型	检测方法	修正策略
实体边界错误	统计共现频率	重新分词
关系方向错误	传递性检查	反转关系
类型冲突	类型一致性验证	多类型标签
冗余关系	重复检测	关系合并
虚假关联	置信度阈值	过滤低置信度

14. 图检索 vs 向量检索对比

查询类型对比表

查询类型	向量检索	图检索	推荐方案
“机器学习的定义”	✅ 语义相似	❌ 无优势	向量
“与Transformer相关的所有技术”	⚠️ 召回有限	✅ 多跳关联	图
“A如何影响B”	❌ 无法判断	✅ 路径查找	图
“与X类似的概念”	✅ 语义相似	⚠️ 需要同类型	向量
“X在知识体系中的位置”	❌ 无结构信息	✅ 层级结构	图
“我学过哪些相关内容”	⚠️ 语义匹配	✅ 关联遍历	图

混合检索示例

// 查询：找出所有与"Transformer"相关的技术，并按关联强度排序
MATCH path = (t:Concept {name: "Transformer"})-[:RELATED_TO*1..3]-(related:Concept)
WHERE related.category = "技术"

// 同时考虑向量相似度（通过预计算）
WITH related,
     apoc.cypher.run(
         'CALL db.index.vector.queryNodes("embedding_index", 10, $embedding)
          YIELD node, score RETURN node.name AS name, score',
         {embedding: $query_embedding}
     ) AS vector_result

// 合并图检索和向量检索分数
MATCH (related)
WHERE related.name IN vector_result.name

RETURN related.name,
       sum(r.weight) as graph_score,
       vector_result.score as vector_score,
       (graph_score * 0.6 + vector_score * 0.4) as combined_score
ORDER BY combined_score DESC
LIMIT 10

图检索优势场景

┌─────────────────────────────────────────────────────────────┐
│                  图检索优势场景示例                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  场景1：关系推理                                            │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  问题："A如何影响B？"                                │   │
│  │  图检索：FIND PATH A->...->B                         │   │
│  │  向量检索：无法理解"影响"关系                         │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  场景2：层级遍历                                            │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  问题："列出所有机器学习的子领域"                    │   │
│  │  图检索：MATCH (p:Concept)-[:SUBTYPE*]->(c)         │   │
│  │  向量检索：只能找到语义相似的概念                     │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  场景3：社区发现                                            │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  问题："找出所有相互关联的概念群"                    │   │
│  │  图检索：社区检测算法                                 │   │
│  │  向量检索：需要先聚类再分析                           │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

总结

本解答涵盖了智能体记忆系统和RAG系统的核心设计理念：

记忆类型设计需要理解每种记忆的本质特征
RAG系统优化需要在召回率、精确度、效率之间权衡
工程实践需要考虑隐私、性能、可扩展性
多用户场景需要仔细设计数据隔离方案
质量保证需要建立评估和验证机制

这些设计原则不仅适用于学习助手，也适用于其他智能体应用场景，如个人助手、知识管理、教育培训等。

Agent 05-基于低代码平台构建智能体

Wed, 18 Feb 2026 16:05:09 +0800

当前，智能体与 LLM 应用的低代码平台市场呈现出百花齐放的态势，每个平台都有其独特的定位和优势。选择哪个平台，往往取决于你的核心需求、技术背景以及项目的最终目标。在本章的后续内容中，我们将重点介绍并实操三个各具代表性的平台：Coze、Dify和 n8n。在此之前，我们先对它们进行一个概要性的介绍。

Coze

核心定位：由字节跳动推出的 Coze[1]，主打零代码/低代码的 Agent 的构建体验，让不具备编程背景的用户也能轻松创造。特点分析：Coze 拥有极其友好的可视化界面，用户可以像搭建乐高积木一样，通过拖拽插件、配置知识库和设定工作流来创建智能体。其内置了极为丰富的插件库，并支持一键发布到抖音、飞书、微信公众号等多个主流平台，极大地简化了分发流程。适用人群：AI 应用的入门用户、产品经理、运营人员，以及希望快速将创意变为可交互产品的个人创作者。 Dify

核心定位：Dify 是一个开源的、功能全面的 LLM 应用开发与运营平台[2]，旨在为开发者提供从原型构建到生产部署的一站式解决方案。特点分析：它融合了后端服务和模型运营的理念，支持 Agent 工作流、RAG Pipeline、数据标注与微调等多种能力。对于追求专业、稳定、可扩展的企业级应用而言，Dify 提供了坚实的基础。适用人群：有一定技术背景的开发者、需要构建可扩展的企业级 AI 应用的团队。 n8n

核心定位：n8n 本质上是一个开源工作流自动化工具[3]，而非纯粹的 LLM 平台。近年来，它积极集成了 AI 能力。

特点分析：n8n 的强项在于“连接”。它拥有数百个预置的节点，可以轻松地将各类 SaaS 服务、数据库、API 连接成复杂的自动化业务流程。你可以在这个流程中嵌入 LLM 节点，使其成为整个自动化链路中的一环。虽然在 LLM 功能的专一度上不如前两者，但其通用自动化能力是独一无二的。不过，其学习曲线也相对陡峭。

适用人群：需要将 AI 能力深度整合进现有业务流程、实现高度定制化自动化的开发者和企业 1：Coze 工作流：关卡通关路线图对话流：NPC 对话通关插件：角色技能卡知识库：游戏百科全书卡片：快捷道具栏提示词：角色的移动键数据库：“云存档” 发布管理：关卡审核员模型管理：游戏角色库或者叫捏脸系统效果评测：闯关评分系统

Coze 的优势与局限性分析优势:

强大的插件生态系统: Coze 平台的核心优势在于其丰富的插件库，这使得智能体能够轻松接入外部服务与数据源，从而实现功能的高度扩展性。直观的可视化编排: 平台提供了一个低门槛的可视化工作流编排界面，用户无需深厚的编程知识，即可通过“拖拽”方式构建复杂的工作流，大大降低了开发难度。灵活的提示词控制: 通过精确的角色设定与提示词编写，用户可以对智能体的行为和内容生成进行细粒度的控制，实现高度定制化的输出。而且还支持提示词管理和模板，极大的方便开发者进行智能体的开发。便捷的多平台部署: 支持将同一智能体发布到不同的应用平台，实现了跨平台的无缝集成与应用。而且扣子还在不断的整合新平台加入他的生态圈，越来越多的手机厂商和硬件厂商都在陆续支持扣子智能体的发布。局限性:

不支持MCP: 我觉得这是最致命的，尽管扣子的插件市场极其丰富，也极其有吸引力。但是不支持mcp可能会成为限制其发展的枷锁，如果放开那将是又一杀手锏。部分插件配置的复杂度高: 对于需要 API Key 或其他高级参数的插件，用户可能需要具备一定的技术背景才能完成正确的配置。复杂的工作流编排也不仅仅是零基础就可以掌握的，需要一定的js或者python的基础。无法导入编排json文件: 之前扣子是没有导出导入功能的，但是现在付费版是可以导出导入的，但是导出导入的不是像dify,n8n一样的json文件，而是一个zip。也就是说你只能在扣子导出然后扣子导入这个zip。不过你取巧的话也可以选择复制编排，在编排界面ctrl+a选中全部ctrl+c复制编排，然后到另一个空白的工作流或者其他工作流粘贴编排。

平台二：Dify 5.3.3 Dify 的优势与局限性分析 Dify 作为一款领先的 AI 应用开发平台，在多个方面展现出显著优势：

核心优势全栈式开发体验：Dify 将 RAG 管道、AI 工作流、模型管理等功能整合到一个平台中，提供一站式的开发体验低代码与高扩展性的平衡：Dify 在低代码开发的便利性和专业开发的灵活性之间取得了良好平衡企业级安全与合规：Dify 提供 AES-256 加密、RBAC 权限控制和审计日志等功能，满足严格的安全和合规要求丰富的工具集成能力：Dify 支持 9000 + 工具和 API 扩展，提供了广泛的功能扩展性活跃的开源社区：Dify 拥有活跃的开源社区，提供了丰富的学习资源和支持主要局限学习曲线较陡：对于完全没有技术背景的用户，仍然存在一定的学习曲线性能瓶颈：在高并发场景下可能面临性能挑战，需要进行适当的优化。Dify 系统的核心服务端组件由 Python 语言实现，与 C++、Golang、Rust 等语言相比，性能表现相对较差多模态支持不足：当前主要以文本处理为主，对图像、视频、HTML等的支持有限企业版成本较高：Dify 的企业版定价相对较高，可能超出小型团队的预算 API 兼容性问题：Dify 的 API 格式不兼容 OpenAI，可能限制与某些第三方系统的集成

Agent 04-智能体经典范式构建

Wed, 18 Feb 2026 13:24:09 +0800

引言

在前三章的学习中，我们已经掌握了关于大语言模型的基础知识。本章将进入实践环节，通过"亲手造轮子"的方式，从零开始编码实现三种业界经典的智能体构建范式：

ReAct — 推理与行动结合
Plan-and-Solve — 规划与执行分离
Reflection — 自我反思与迭代优化

我们将深入探索它们的核心工作原理，并通过具体的实战案例，分析各自的优势、局限与适用场景。

核心知识点概览

1. ReAct：思考-行动的动态循环

ReAct 范式构建了一个能与外部世界交互的智能体。其核心机制是 “思考(Thought) → 行动(Action) → 观察(Observation)” 的动态循环。

核心优势：

环境适应性强，能够利用外部工具
具备动态纠错能力
适合处理探索性、需要实时信息的任务

典型应用场景：

需要搜索引擎辅助的问答
实时数据查询
API 调用与交互式任务

2. Plan-and-Solve：先规划，后执行

Plan-and-Solve 范式将复杂问题分解为清晰的步骤，然后逐一执行。

执行流程：

`1`	`输入问题 → 规划阶段（生成步骤列表） → 执行阶段（逐步完成）`

核心优势：

结构性强，逻辑清晰
稳定性高，推理路径确定
适合逻辑路径固定、内部推理密集的任务

典型应用场景：

多步数学推理
复杂问题分解
流程化任务处理

3. Reflection：执行-反思-优化

Reflection 范式引入了自我优化能力，通过 “执行 → 反思 → 优化” 的迭代循环提升解决方案质量。

迭代流程：

`1`	`初始方案 → 执行与评估 → 反思反馈 → 优化改进 → (循环) → 最终方案`

核心价值：

显著提升输出质量
自动发现并修正错误
适用于对准确性和可靠性要求极高的场景

典型应用场景：

代码生成与优化
学术写作辅助
决策支持系统

三种范式的对比分析

本章探讨的三种范式，代表了智能体解决问题的三种不同策略，如下表所示：

范式	思考模式	核心优势	适用场景
ReAct	思考-行动一体，动态循环	环境适应、动态纠错	探索性任务、工具调用
Plan-and-Solve	先规划，后执行	结构稳定、逻辑清晰	多步推理、流程化任务
Reflection	执行-反思-优化迭代	质量提升、自我修正	高精度要求、复杂输出

💡 选择建议：在实际应用中，选择哪种范式取决于任务的核心需求。某些复杂场景下，也可以将多种范式组合使用。

架构组合示例

当面临复杂任务时，可以考虑 混合范式架构：

Plan-and-Solve 进行高层次任务规划
ReAct 在执行过程中处理具体的操作和环境交互
Reflection 对整个过程进行自我优化和改进

适用场景： 智能客服系统、自动驾驶、复杂工作流自动化等。

小结与展望

至此，我们已经掌握了构建单个智能体的核心技术体系：

✅ 理解了 ReAct 的动态交互机制
✅ 掌握了 Plan-and-Solve 的结构化规划方法
✅ 学会了 Reflection 的自我优化技巧

下一站预告： 为了更好地将理论付诸实践，下一章我们将探索不同低代码平台的使用方式，以及轻代码构建 Agent的实战方案。

思考与练习

⚠️ 提示：部分习题没有标准答案，重点在于培养对智能体范式设计的综合理解和实践能力。

练习一：范式理解与选择

问题 1.1：ReAct、Plan-and-Solve 和 Reflection 这三种范式在"思考"与"行动"的组织方式上有什么本质区别？

点击查看参考答案

范式	组织方式
ReAct	思考-行动一体，动态循环；思考指导行动，行动结果反哺思考
Plan-and-Solve	先规划，后执行；分阶段处理，一次规划多步执行
Reflection	执行-反思-优化；通过迭代循环持续提升质量

问题 1.2：如果要设计一个"智能家居控制助手"（需要控制灯光、空调、窗帘等多个设备，并根据用户习惯自动调节），你会选择哪种范式作为基础架构？为什么？

点击查看参考答案

推荐选择：ReAct

理由：

智能家居控制需要实时响应用户指令和环境变化
ReAct 的动态循环能够更好地适应这种需求
其环境适应性和动态纠错能力非常适合处理各种突发情况

问题 1.3：是否可以将这三种范式进行组合使用？请设计一个混合范式的智能体架构。

点击查看参考答案

混合架构设计：

输入任务
    ↓
[Plan-and-Solve] 高层次任务规划
    ↓
[ReAct] 动态执行与环境交互（每一步骤）
    ↓
[Reflection] 全过程自我优化与改进
    ↓
输出结果

适用场景： 智能客服系统、自动驾驶、复杂项目管理等需要同时具备规划能力、实时交互和持续优化的场景。

练习二：输出解析的鲁棒性

问题 2.1：在 ReAct 实现中，我们使用正则表达式解析大语言模型的输出。当前的解析方法存在哪些潜在脆弱性？

点击查看参考答案

潜在问题：

格式依赖性强：如果模型输出格式变化（如标签被替换或省略），解析会失败
额外文本干扰：输出中包含额外文本时可能导致匹配错误
边界情况处理：特殊字符、多行输出等边界情况容易引发问题

问题 2.2：除了正则表达式，还有哪些更鲁棒的输出解析方案？

点击查看参考答案

改进方案：

结构化输出：使用 JSON、XML 等格式规范模型输出
自然语言理解：使用 NLU 技术识别意图和实体
专用解析器：针对特定格式设计专用解析逻辑
模型约束：使用支持结构化输出的模型（如 Function Calling）

练习三：工具调用与扩展

问题 3.1：为 ReAct 智能体添加一个"计算器"工具，使其能够处理复杂的数学计算问题。

点击查看代码示例

def calculator(expression: str) -> float:
    """安全地计算数学表达式"""
    import ast
    import operator as op

    operators = {
        ast.Add: op.add, ast.Sub: op.sub,
        ast.Mult: op.mul, ast.Div: op.truediv,
    }

    def eval_node(node):
        if isinstance(node, ast.Num):
            return node.n
        elif isinstance(node, ast.BinOp):
            left = eval_node(node.left)
            right = eval_node(node.right)
            return operators[type(node.op)](left, right)
        raise ValueError(f"不支持的节点类型: {type(node)}")

    try:
        return eval_node(ast.parse(expression, mode='eval').body)
    except Exception as e:
        return f"计算错误: {e}"

# 注册工具
tools.register("calculator", calculator, "计算数学表达式，如 '(123 + 456) * 789 / 12'")

问题 3.2：当可调用工具数量增加到 50-100 个时，如何优化工具的组织和检索机制？

点击查看参考答案

优化策略：

问题	解决方案
上下文占用大	分层组织，按需加载工具描述
相似工具干扰	工具聚类 + 语义检索
选择错误率高	约束执行 + 置信度过滤

工程实现：

分层索引：建立工具分类目录（类目 → 子类 → 工具）
语义检索：用向量相似度找到候选工具子集
工具路由：训练轻量级路由模型，直接映射到目标工具
缓存优化：缓存常用工具的调用结果

练习四：动态规划机制

问题 4.1：Plan-and-Solve 的计划是"静态"的，如何设计一个"动态重规划"机制？

点击查看参考答案

动态重规划机制设计：

  graph TD
    A[执行步骤] --> B{结果校验}
    B -->|成功| C[继续下一步]
    B -->|失败| D{重试次数 < 阈值?}
    D -->|是| E[局部重规划]
    D -->|否| F[全局重规划]
    E --> A
    F --> A

关键组件：

结果校验模块：判断是否满足成功标准
局部重规划：更换工具/调整参数/插入补充步骤
全局重规划：重新生成后续步骤
安全退出：设置重试和重规划次数上限

问题 4.2：对比 Plan-and-Solve 与 ReAct，在处理"预订商务旅行"任务时哪种更合适？

点击查看参考答案

场景分析：

| 范式 | 优势 | 劣势 | |:—|:—| | Plan-and-Solve | 适合处理有关联的多步骤预订 | 难以应对实时变化（如售罄、价格跳变） | | ReAct | 能根据实时结果灵活调整 | 可能缺乏整体规划 |

最佳方案： 组合使用

用 Plan-and-Solve 做高层次规划（确定预订顺序和约束）
用 ReAct 处理每个子步骤的执行与纠错（如换日期、换机场）

问题 4.3：设计一个"分层规划"系统及其优势。

点击查看参考答案

分层规划架构：

高层抽象计划 (3-8 个里程碑)
    ├── 阶段 1
    │   └── 细化子计划 (具体工具、参数、检查点)
    ├── 阶段 2
    │   └── 细化子计划
    └── ...

核心优势：

优势	说明
可扩展	高层计划稳定，细节按需生成
更稳健	局部失败只需重规划子计划
工具选择	明确的意图收窄候选工具范围
可观测性	高层里程碑便于审计和监控
可复用	高层模板可跨任务复用

练习五：Reflection 机制深入

问题 5.1：使用两个不同的模型（一个更强大做反思，一个更快做执行）会带来什么影响？

点击查看参考答案

双模型架构分析：

收益	代价
用"高推理能力"提升正确性	增加系统复杂度
用"高吞吐低成本"承担重复劳动	需要模型对齐与调试
成本效益更优	增加调用链路延迟

结论： 对于工程化长期运行的系统（如自动代码代理），双模型架构通常比单模型更稳定、更经济。

问题 5.2：如何设计更智能的 Reflection 终止条件？

点击查看参考答案

改进的终止条件：

def should_terminate(iteration, history):
    # 1. 质量评分阈值
    if latest_score >= 0.95:
        return True, "质量达标"

    # 2. 改进幅度检测
    if abs(latest_score - previous_score) < 0.01:
        return True, "改进饱和"

    # 3. 外部评估通过
    if all_tests_passed():
        return True, "测试通过"

    # 4. 迭代次数上限
    if iteration >= max_iterations:
        return True, "达到最大迭代次数"

    return False, "继续优化"

多维度判断： 质量评分、改进幅度、外部测试、计算预算

问题 5.3：设计一个"学术论文写作助手"的多维度 Reflection 机制。

点击查看参考答案

多维度评估体系：

  graph TD
    A[论文初稿] --> B[段落逻辑性评估]
    A --> C[方法创新性评估]
    A --> D[语言表达评估]
    A --> E[引用规范评估]
    B --> F[综合反馈报告]
    C --> F
    D --> F
    E --> F
    F --> G[针对性优化]
    G --> H{终止条件满足?}
    H -->|否| A
    H -->|是| I[最终论文]

评估维度：

段落逻辑性：连贯性与结构合理性
方法创新性：科学贡献与技术亮点
语言表达：语法、用词、流畅度
引用规范：格式正确性与引用完整性

练习六：提示词工程

问题 6.1：ReAct 和 Plan-and-Solve 的提示词结构设计有何不同？

点击查看参考答案

范式	提示词设计重点
ReAct	强调"Thought-Action-Observation"循环，明确三者角色定义
Plan-and-Solve	强调分阶段处理，明确规划阶段和执行阶段的边界

核心差异：提示词结构设计直接服务于各自范式的执行逻辑。

问题 6.2：角色设定对智能体行为的影响。

点击查看参考答案

角色设定对比：

角色	输出倾向
“严格的代码评审专家”	关注正确性、性能、安全性
“注重可读性的开源维护者”	关注清晰度、注释、结构
“注重效率的工程经理”	关注开发速度、可维护性

结论： 角色设定是引导模型行为的重要手段，应根据目标场景精心设计。

问题 6.3：Few-shot 示例的效果分析。

点击查看参考答案

方案	优点	缺点	适用场景
无 Few-shot	灵活、节省 token	格式不稳定	创意性任务
有 Few-shot	稳定性高、格式遵循好	token 消耗大	结构化输出任务

建议： 对于需要结构化输出的智能体（如 Reflection、Planner），Few-shot 是必要而非可选的优化。

练习七：综合实战

场景： 某电商公司希望搭建"客服智能体"，需要以下功能：

理解用户的退款申请理由
查询用户的订单信息和物流状态
根据公司政策智能判断是否批准退款
生成得体的回复邮件并发送
争议情况下进行自我反思

问题 7.1：选择何种范式作为核心架构？

点击查看参考答案

推荐架构：ReAct + Reflection

组件	职责
ReAct	动态调用工具查询订单、物流，做出初步判断
Reflection	对争议决策进行反思，提供更审慎的建议

问题 7.2：系统需要哪些核心工具？

点击查看参考答案

工具	功能描述
订单查询工具	根据用户信息查询订单详情和物流状态
政策判断工具	根据退款政策评估申请是否符合条件
邮件生成工具	生成得体回复并发送至用户邮箱
情感分析工具	分析用户情绪，调整回复语气

问题 7.3：如何设计提示词以平衡公司利益与用户体验？

点击查看参考答案

提示词设计策略：

# 角色设定
你是一位专业且友好的客服代表，代表公司处理退款申请。

# 决策原则
1. 严格遵守公司退款政策
2. 在保护公司利益的前提下，尽可能满足用户需求
3. 对用户表达理解和关心

# 回复要求
- 语气友好、专业
- 清晰说明决策理由
- 提供替代方案（如适用）

问题 7.4：产品上线可能面临哪些风险？如何降低？

点击查看参考答案

风险类型	风险描述	缓解措施
错误决策	误批/误拒退款申请	多模型评估 + 人工审核兜底
隐私泄露	用户数据暴露	数据加密 + 访问控制 + 审计
体验下降	回复不当导致用户不满	持续优化提示词 + 反馈机制
系统稳定性	服务中断影响用户	冗余架构 + 监控告警 + 定期维护

结语

本章通过三种经典范式的实践，建立了构建智能体完整技术栈的认知。下一章，我们将走进低代码平台的世界，探索更高效的 Agent 构建方式。

敬请期待！

Agent 03-大模型语言基础

Sun, 15 Feb 2026 18:37:25 +0800

1.自然语言处理中，语言模型经历了从统计到神经网络的模型演进。

请使用本章提供的迷你语料库（datawhale agent learns, datawhale agent works），计算句子 agent works 在Bigram模型下的概率 N-gram模型的核心假设是马尔可夫假设。请解释这个假设的含义，以及N-gram模型存在哪些根本性局限？神经网络语言模型（RNN/LSTM）和Transformer分别是如何克服N-gram模型局限的？它们各自的优势是什么？ 2.Transformer架构[4]是现代大语言模型的基础。其中：

提示：可以结合本章3.1.2节的代码实现来辅助理解

自注意力机制（Self-Attention）的核心思想是什么？自注意力 (Self-Attention) 机制就是对这种现象的数学建模。它允许模型在处理序列中的每一个词时，都能兼顾句子中的所有其他词，并为这些词分配不同的“注意力权重”。权重越高的词，代表其与当前词的关联性越强，其信息也应该在当前词的表示中占据更大的比重。

为什么Transformer能够并行处理序列，而RNN必须串行处理？位置编码（Positional Encoding）在其中起什么作用？它完全抛弃了循环结构，转而使用自注意力机制来捕捉序列中的依赖关系。这使得Transformer能够同时处理序列中的所有位置，从而实现并行计算。位置编码则为模型提供了序列中各个词的位置信息，使得模型能够理解词与词之间的顺序关系。 RNN这种循环的计算方式也带来了新的瓶颈：它必须按顺序处理数据。第 t 个时间步的计算，必须等待第 t−1 个时间步完成后才能开始。

Decoder-Only架构与完整的Encoder-Decoder架构有什么区别？为什么现在主流的大语言模型都采用Decoder-Only架构？编码器负责深入理解输入的整个句子，形成一个包含全局信息的上下文记忆，然后解码器基于这份记忆来生成翻译它完全抛弃了编码器，只保留了解码器部分训练目标统一：模型的唯一任务就是“预测下一个词”，这个简单的目标非常适合在海量的无标注文本数据上进行预训练。结构简单，易于扩展：更少的组件意味着更容易进行规模化扩展。今天的 GPT-4、Llama 等拥有数千亿甚至万亿参数的巨型模型，都是基于这种简洁的架构。天然适合生成任务：其自回归的工作模式与所有生成式任务（对话、写作、代码生成等）完美契合，这也是它能成为构建通用智能体基础的核心原因。

3.文本子词分词算法是大语言模型的一项关键技术，负责将文本转换为模型可处理的 token 序列。那为什么不能直接以"字符"或"单词"作为模型的输入单元？BPE（Byte Pair Encoding）算法解决了什么问题？统一输入单元：字符级模型过于细粒度，导致序列过长；单词级模型则过于粗粒度，无法处理未登录词（OOV）。 BPE通过子词分割，提供了一个平衡的输入单元。

4.本章3.2.3节介绍了如何本地部署开源大语言模型。请完成以下实践和分析：

提示：这是一道动手实践题，建议实际操作

按照本章的指导，在本地部署一个轻量级的开源模型（推荐Qwen3-0.6B），并尝试调整采样参数并观察其对输出的影响选择一个具体任务（如文本分类、信息抽取、代码生成等），设计并对比以下不同的提示策略（如Zero-shot、Few-shot、Chain-of-Thought）对输出结果的效果差异从性能、成本、可控性、隐私等维度比较闭源模型和开源模型如果你要构建一个企业级的客服智能体，你会选择哪种类型的模型？需要考虑哪些因素？ 5.模型幻觉（Hallucination）[11]是大语言模型当前存在的关键局限性之一。本章介绍了缓解幻觉的方法（如检索增强生成、多步推理、外部工具调用）

请选择其中一种，说明其工作原理和适用场景调研前沿的研究和论文，是否还有其他的缓解模型幻觉的方法，他们又有哪些改进和优势？ 6.假设你要设计一个论文辅助阅读智能体，它能够帮助研究人员快速阅读并理解学术论文，包括：总结论文研究的核心内容、回答关于论文的问题、提取关键信息、比较多篇不同论文的观点等。请回答：

你会选择哪个模型作为智能体设计时的基座模型？选择时需要考虑哪些因素？如何设计提示词来引导模型更好地理解学术论文？学术论文通常很长，可能超过模型的上下文窗口限制，你会如何解决这个问题？学术研究是严谨的，这意味着我们需要确保智能体生成的信息是准确客观忠于原文的。你认为系统中加入哪些设计能够更好的实现这一需求？

Agent 02-智能体发展史

Sun, 15 Feb 2026 12:40:47 +0800

本文聚焦智能体从符号主义到大模型驱动范式的关键演进路径。

2.1 基于符号与逻辑的早期智能体

物理符号系统假说

论断	含义
充分性	任何物理符号系统都具备产生通用智能行为的充分手段
必要性	任何展现通用智能行为的系统，本质必然是物理符号系统

核心思想：智能的本质是符号的计算与处理。

专家系统

由 知识库（IF-THEN规则）和 推理机（正向链/反向链）组成。

MYCIN：血液感染诊断专家系统，约600条规则。创新之处是引入 置信因子（CF） 处理不确定性。

符号主义的局限：

常识知识瓶颈
框架问题与系统脆弱性

SHRDLU

SHRDLU是积木世界中的自然语言交互智能体，具备：

自然语言理解（解析复杂指令）
指代消解（理解"你手中拿的"）
上下文记忆
规划与行动（规划动作序列）
记忆与问答

2.2 基于规则的聊天机器人

ELIZA 的设计

核心机制：模式匹配 + 文本替换

def respond(user_input):
    # 1. 关键词识别
    # 2. 分解（捕获通配符*匹配的内容）
    # 3. 代词转换（I ↔ you）
    # 4. 重组生成回应
    pass

局限：

无语义理解（不理解否定词）
无上下文记忆
规则扩展导致组合爆炸

2.3 马文·明斯基的"心智社会"

核心观点：智能源于大量简单智能体的协作，而非单一完美系统。

概念	含义
智能体（Agent）	简单、专门、无心智
机构（Agency）	协作的智能体集合

对多智能体系统（MAS）的启发：

去中心化控制
涌现式计算
智能体社会性

2.4 学习范式的演进

从符号到联结主义

范式	核心思想
符号主义	知识显式编码为规则
联结主义	知识以连接权重分布式存储

强化学习框架

五元组 (S, A, P, R, γ)

组件	说明
Agent	学习者和决策者
Environment	智能体外部的一切
State (S)	环境在某一时刻的描述
Action (A)	智能体可采取的操作
Reward (R)	评价行动好坏的标量信号

学习循环：观察 → 选择行动 → 执行 → 获得奖励 → 调整策略

预训练-微调范式

1
2
3

海量文本 → 自监督学习 → 基础模型
                              ↓
                    特定任务数据微调 → 下游任务

大语言模型驱动的智能体

核心组件：

1
2
3

感知模块 → 思考模块(Planning + LLM) → 执行模块 → 工具调用
    ↑                                              ↓
    └──────────── 观察与记忆更新 ←──────────────────┘

阶段	功能
感知	接收用户指令、环境状态
思考	规划分解、推理决策、工具调用
行动	执行工具、与环境交互
观察	获取工具结果、更新记忆

发展时间线

时期	代表技术
1950s-1980s	符号主义：专家系统、SHRDLU
1980s-2010s	联结主义：神经网络复苏、深度学习
2010s-至今	强化学习 + 预训练-微调 + LLM Agent

2.5 习题解析

题 1：物理符号系统假说

Q1：充分性论断和必要性论断分别是什么？

论断	含义
充分性	任何物理符号系统都具备产生通用智能行为的充分手段
必要性	任何展现通用智能行为的系统，本质必然是物理符号系统

Q2：符号主义实践中的哪些问题挑战了"充分性"？

常识问题：依赖庞大的背景知识
框架问题：规则静态，无法适应变化

Q3：LLM驱动的智能体是否符合该假说？

不完全符合。LLM通过分布式权重隐式编码知识，而非显式符号规则。

题 2：专家系统MYCIN

Q1：为何MYCIN未大规模应用于临床？

维度	原因
技术	知识库难以覆盖全部医学知识
伦理	诊断错误责任归属不明
用户接受度	医患对非人类系统缺乏信任

Q2：现代医疗诊断智能体如何改进？

动态知识更新（结合最新研究）
个体化诊断（考虑患者差异）
可解释性（清晰展示诊断依据）

Q3：哪些垂直领域仍适合基于规则的系统？

法律咨询（规则明确）
工业控制（稳定可预测）
药物配置（避免相互作用冲突）

题 3：ELIZA 扩展实践

核心扩展：添加 上下文记忆 功能，记住姓名、年龄、职业等信息。

与ChatGPT的本质差异：

维度	ELIZA	ChatGPT
知识边界	固定规则集	预训练知识+推理
上下文	无状态	多轮对话连贯
开放能力	预设场景	开放域处理

组合爆炸问题：假设n个规则、每个规则匹配m种输入，组合数为m^n（指数级增长）。

题 4：“心智社会"理论

Q1：GRASP智能体失效会怎样？

系统失去抓取积木能力，但其他智能体可继续工作。优势是鲁棒性，劣势是整体性能下降。

Q2：与现代多智能体系统的关联？

关联：都体现协作思想、去中心化控制
不同：现代系统有更先进的通信协议和学习算法

Q3：LLM时代"心智社会"是否仍适用？

适用。智能的涌现和协作思想仍是理解多智能体系统的重要框架。

题 5：强化学习与监督学习

Q1：AlphaGo的"试错学习"机制？

通过自我对弈不断尝试策略，根据胜负结果调整，优化长期收益。

Q2：为何强化学习适合序贯决策？

强化学习	监督学习
关注长期奖励	关注单次预测正确
与环境交互收集数据	需要预标注数据集
适合动态环境	适合静态模式识别

Q3：RLHF在LLM训练中的作用？

通过人类反馈强化学习，使模型输出更符合人类期望和偏好。

题 6：预训练-微调范式

Q1：预训练如何解决"知识获取瓶颈”？

符号主义：专家手工编码规则
预训练：从数据中自动学习，分布式表示知识

Q2：互联网数据带来的问题及缓解？

问题	缓解措施
错误信息	数据清洗
偏见	偏见检测与修正
知识过时	持续更新

题 7：智能代码审查助手

三个时代的设计对比：

时代	方案	困难
符号主义	手工编码规则	知识获取瓶颈、脆弱性
深度学习(2015)	特征工程+分类器	特征设计难、泛化能力弱
LLM时代	感知+思考+执行模块	架构复杂度

演进意义：从"几乎不可能"到"可行"，核心是 理解和推理能力 的质变。

小结

智能体发展史是一场关于"如何定义智能、获取知识、进行决策"的思想变革：

符号主义：显式规则 → 知识获取瓶颈
联结主义：分布式表示 → 感知能力突破
强化学习：试错交互 → 决策能力突破
LLM Agent：感知-思考-行动闭环 → 通用智能雏形

Agent 01-初识智能体

Fri, 13 Feb 2026 13:12:43 +0800

智能体（Agent）不是"会算就行"的程序，而是一个能够在环境中感知、决策、行动并持续改进的主体。本文先梳理核心概念，再给出习题的标准化解析，确保内容可阅读、可复盘、可用于后续实战。

1. 智能体基础概念

1.1 四个核心要素

一个完整智能体通常包含以下要素：

传感器（Sensors）：获取环境信息。
环境（Environment）：智能体所处并交互的外部世界。
执行器（Actuators）：对环境施加影响的手段。
行动（Action）：基于决策实际执行的动作。

1.2 从简单到复杂的智能体类型

类型	特点	局限
简单反射智能体	只基于当前观测做规则匹配，不保留历史	无法应对需要理解上下文的复杂任务
基于模型的反射智能体	维护内部状态/世界模型，弥补"看不全"的问题	模型可能不准确，需要持续校准
基于目标的智能体	以"达到目标状态"为导向做规划	规划开销大，实时性较差
基于效用的智能体	比较不同结果"好到什么程度"，最大化期望效用	效用函数设计困难
学习型智能体	通过反馈不断更新策略	需要大量训练数据和反馈信号

强化学习（Reinforcement Learning, RL）是实现学习型智能体最具代表性的路径之一。一个学习型智能体包含一个性能元件（执行决策）和一个学习元件（通过观察结果不断修正策略）。

1.3 常见分类维度

按反应方式分类

反应式智能体：接收到信息后立即行动，追求速度。
规划式智能体：经过深思熟虑的规划再行动，追求最优解。
混合式智能体：结合规划（Reasoning）与反应（Acting & Observing），在速度与质量之间取得平衡。

按知识表示分类

类型	特点	适用场景
符号主义 AI	基于符号和规则，强调逻辑推理和明确的知识表示	结构化问题
亚符号主义 AI	基于连接主义和分布式表示（如神经网络）	复杂、非结构化数据
神经符号主义 AI	结合符号推理与神经网络的学习能力	需要同时处理逻辑与模式识别

按学习能力分类

固定策略智能体：行为规则预先设定，不会随经验改变。
可学习策略智能体：能够从反馈中学习，持续优化决策。

1.4 系统 1 / 系统 2 与神经符号主义类比

卡尼曼的"双系统理论"为理解 AI 架构提供了很好的类比：

系统 1：快速、直觉、并行、模式识别驱动（更接近亚符号主义方法）。
系统 2：缓慢、审慎、基于逻辑、可解释推理驱动（更接近符号主义方法）。

工程上常见的有效做法是"系统 1 快速筛查 + 系统 2 重点复核"，既保证效率，又不失准确性。

2. 智能体任务环境建模：PEAS

PEAS 用于精确定义任务环境，是设计智能体的第一步：

维度	问题	示例（自动驾驶）
P（Performance）	如何评价做得好不好	安全性、到达时间、乘车舒适度
E（Environment）	智能体面对什么世界	道路、其他车辆、行人、交通信号、天气
A（Actuators）	它能做什么动作	加速、刹车、转向、转向灯、鸣笛
S（Sensors）	它能看到什么信号	摄像头、雷达、激光雷达、速度传感器、GPS

如果 PEAS 不清晰，后续算法、工具链和评估标准都会失焦。

3. 习题完整解析

题 1：判断主体是否为智能体及其类型

题目：请分析以下四个 case 中的主体是否属于智能体，如果是，属于哪种类型的智能体（可以从多个分类维度进行分析），并说明理由。

Case A：超级计算机（2 EFlop）

结论：通常不直接算智能体本体。

理由：一台符合冯·诺依曼结构的超级计算机，无论算力多强，本质上仍是高性能计算平台。它本身不具备自主目标、感知-决策-行动闭环；真正的智能体是其上运行的软件系统。智能体的关键在于"自主性"和"与环境的交互"，而非计算能力。

Case B：高速场景下的自动驾驶紧急决策

特斯拉自动驾驶系统在高速公路上行驶时，突然检测到前方有障碍物，需要在毫秒级做出刹车或变道决策。

结论：是智能体，核心是反应式，同时具备模型与目标约束。

理由：

毫秒级避障强调实时反应，符合反应式智能体特征。
但车道保持、速度控制、障碍物轨迹预测等又依赖内部状态估计（基于模型的反射智能体）。
同时还有导航目的地这一目标约束（基于目标的智能体）。
因此实际是混合式智能体，兼顾实时反应与规划能力。

Case C：AlphaGo 对弈

AlphaGo在与人类棋手对弈时，需要评估当前局面并规划未来数十步的最优策略。

结论：是智能体，属于规划式 + 学习型智能体。

理由：

通过蒙特卡洛树搜索与价值评估规划后续多步（规划式）。
策略网络和价值网络由大量对弈数据训练而成（学习型）。
通过自我对弈持续改进策略（强化学习）。

Case D：ChatGPT 智能客服

ChatGPT 扮演的智能客服在处理用户投诉时，需要查询订单信息、分析问题原因、提供解决方案并安抚用户情绪。

结论：是智能体系统（或可演化为智能体系统），属于混合式。

理由：

需要多步工具调用（查订单、检索政策、查询库存）。
需要对话推理能力理解用户意图。
需要根据用户反馈调整策略（如安抚情绪）。
单纯的语言模型不是完整智能体，但结合工具调用后可视为智能体系统。

题 2：智能健身教练的 PEAS 与环境特性

题目：假设你需要为一个"智能健身教练"设计任务环境。这个智能体能够：

通过可穿戴设备监测用户的心率、运动强度等生理数据
根据用户的健身目标（减脂/增肌/提升耐力）动态调整训练计划
在用户运动过程中提供实时语音指导和动作纠正
评估训练效果并给出饮食建议

请使用 PEAS 模型完整描述这个智能体的任务环境，并分析该环境具有哪些特性（如部分可观察、随机性、动态性等）。

PEAS 描述

维度	内容
Performance（性能度量）	- 训练目标达成率（减脂/增肌/耐力提升） - 安全性（异常心率、动作风险触发率） - 用户依从性（计划完成率、持续打卡率） - 用户体验（满意度、建议采纳率）
Environment（环境）	- 用户身体状态（疲劳度、伤病情况） - 家庭/健身房场景、可用器械 - 时间段、天气（影响户外运动） - 饮食与睡眠状况 - 网络与设备状态
Actuators（执行器）	- 语音指导输出 - 动作纠正提示推送 - 训练计划调整指令 - 推送提醒 - 饮食建议生成
Sensors（传感器）	- 心率带/手表数据 - 动作传感器（如加速度计、陀螺仪） - 摄像头姿态估计 - 历史训练日志 - 用户主观反馈（如问卷、语音）

环境特性分析

特性	说明	示例
部分可观察	无法直接观测某些关键状态	疲劳、疼痛、真实饮食执行情况难以直接测量
随机性	存在不可预测的扰动	生理状态波动、外部干扰、设备噪声
动态性	环境状态随时间快速变化	运动中心率、速度、体能状态实时变化
连续性	状态变量连续变化	心率、速度、负重等是连续量
多目标约束	需要平衡多个目标	效果、安全、体验之间存在权衡

题 3：Workflow vs Agent 在退款审核中的选择

题目：某电商公司正在考虑两种方案来处理售后退款申请：

方案 A（Workflow）：设计一套固定流程，例如：

A.1 对于一般商品且在 7 天之内，金额 < 100RMB 自动通过；100-500RMB 由客服审核；>500RMB 需主管审批；而特殊商品（如定制品）一律拒绝退款
A.2 对于超过 7 天的商品，无论金额，只能由客服审核或主管审批

方案 B（Agent）：搭建一个智能体系统，让它理解退款政策、分析用户历史行为、评估商品状况，并自主决策是否批准退款

请分析：

这两种方案各自的优缺点是什么？
在什么情况下 Workflow 更合适？什么情况下 Agent 更有优势？
如果你是该电商公司的负责人，你更倾向于采用哪种方案？
是否存在一个方案 C，能够结合两种方案，达到扬长避短的效果？

方案 A（Workflow）

优点	缺点
- 可控、可审计、合规实现简单 - 决策一致性高，成本和响应时间可预测 - 规则透明，易于向用户解释	- 对边界案例不灵活 - 规则维护成本随业务复杂度上升 - 无法处理规则之外的情况

方案 B（Agent）

优点	缺点
- 能处理复杂情境与个体差异 - 可融合更多信号（历史行为、商品状态、风险分） - 适应性强，新场景下可快速调整	- 决策稳定性与可解释性挑战更大 - 需要监控、回放、评估与人工兜底体系 - 错误决策可能造成批量损失

什么时候选谁

Workflow 更合适：规则清晰、合规强约束、低风险高并发场景（如标准化商品的小额退款）
Agent 更有优势：案例复杂、需个性化、规则难以穷举场景（如大额、定制商品、VIP 用户）

方案 C：分层混合架构

如果是负责人，推荐采用方案 C（分层混合）：

第 1 层：Workflow 处理高频标准单
         ↓ (路由规则)
第 2 层：高风险或疑难单路由给 Agent 评估
         ↓ (不确定或人工复核阈值)
第 3 层：人工复核最终兜底

这个组合通常比"纯 A"或"纯 B"更稳健：

标准case快速处理，降低成本
复杂case由Agent个性化处理
关键决策有人工兜底，控制风险

题 4：在旅行助手中扩展记忆、备选、反思、知识库

题目：在智能旅行助手的基础上，请思考如何添加以下功能（可以只描述设计思路，也可以进一步尝试代码实现）：

提示：思考如何修改 Thought-Action-Observation 循环来实现这些功能。

添加一个"记忆"功能，让智能体记住用户的偏好（如喜欢历史文化景点、预算范围等）
当推荐的景点门票已售罄时，智能体能够自动推荐备选方案
如果用户连续拒绝了 3 个推荐，智能体能够反思并调整推荐策略
当用户接受推荐的景点时，把景点和相关信息加入智能体的"知识库"，以便未来推荐时参考

核心思路

把 Thought-Action-Observation 循环升级为"带状态的闭环"：

组件	功能
State（状态）	`user_preferences`：用户偏好 `rejection_count`：连续拒绝计数 `knowledge_base`：已接受景点的历史记录
Thought（思考）	融合用户偏好、历史接受记录与当前约束生成候选
Action（行动）	查询库存/票务、输出推荐、必要时切换备选
Observation（观察）	记录接受/拒绝反馈；若连续拒绝达到阈值触发策略反思

代码实现

class TravelAgent:
    def __init__(self):
        self.user_preferences = {}      # 用户偏好
        self.rejection_count = 0        # 连续拒绝计数
        self.knowledge_base = []        # 已接受景点的知识库

    def recommend(self, user_input):
        """生成推荐，若售罄则生成备选"""
        rec = self.generate_recommendation(user_input)
        if self.is_sold_out(rec):
            rec = self.generate_alternative(user_input)
        return rec

    def receive_feedback(self, feedback, accepted_item=None):
        """接收用户反馈，更新状态"""
        if feedback == "reject":
            self.rejection_count += 1
            if self.rejection_count >= 3:
                self.reflect_and_adjust()
                self.rejection_count = 0  # 重置计数
        elif feedback == "accept" and accepted_item is not None:
            self.rejection_count = 0
            self.update_knowledge_base(accepted_item)

    def generate_recommendation(self, user_input):
        """结合偏好 + 历史行为生成推荐"""
        # 实现逻辑：根据 user_preferences 和 knowledge_base 生成候选
        raise NotImplementedError

    def is_sold_out(self, recommendation):
        """调用票务接口检查库存"""
        raise NotImplementedError

    def generate_alternative(self, user_input):
        """在约束不变时返回备选方案"""
        # 实现逻辑：寻找与原推荐相似但仍有库存的景点
        raise NotImplementedError

    def reflect_and_adjust(self):
        """分析连续拒绝原因，动态调整推荐权重"""
        # 实现逻辑：分析历史拒绝记录，调整推荐策略
        raise NotImplementedError

    def update_knowledge_base(self, accepted_item):
        """记录"被接受方案"的上下文信息"""
        self.knowledge_base.append({
            "item": accepted_item,
            "timestamp": time.now(),
            # 可以附加更多信息，如用户反馈等
        })

题 5：系统 1 / 系统 2 在医疗诊断助手中的分工

题目：卡尼曼的"系统 1"（快速直觉）和"系统 2"（慢速推理）理论为神经符号主义 AI 提供了很好的类比。请首先构思一个具体的智能体的落地应用场景，然后说明场景中的：

哪些任务应该由"系统 1"处理？
哪些任务应该由"系统 2"处理？
这两个系统如何协同工作以达成最终目标？

提示：医疗诊断助手、法律咨询机器人、金融风控系统等都是常见的应用场景。

场景：门诊分诊与辅助诊断助手

系统 1 负责（快速直觉处理）

任务	说明
症状快速归类	根据主诉快速判断科室分类
高危信号初筛	识别胸痛、呼吸困难等紧急症状
候选疾病粗排	基于症状模式匹配给出候选疾病列表

系统 2 负责（慢速推理处理）

任务	说明
结合病史、检验、指南做因果推理	综合多源信息进行诊断
处理冲突证据	当不同检验结果矛盾时做出判断
输出可解释诊断建议与下一步检查计划	给出明确的诊断依据和建议

协同方式

患者输入 → 系统1快速筛查 → 低风险/常见病 → 直接输出建议
                        ↓
                  高风险/不确定
                        ↓
                    系统2深度分析 → 诊断建议 + 检查计划
                        ↓
                    反哺系统1（持续校准筛查规则）

目标是在效率、准确性与可解释性之间取得平衡：

系统 1 保证高召回率（不漏掉高危患者）
系统 2 对关键样本投入更多算力
系统 2 的结论持续反哺系统 1，形成闭环学习

题 6：智能体局限与评估

题目：尽管大语言模型驱动的智能体系统展现出了强大的能力，但它们仍然存在诸多局限。请分析以下问题：

为什么智能体或智能体系统有时会产生"幻觉"（生成看似合理但实际错误的信息）？
在智能体案例中，我们设置了最大循环次数为 5 次。如果没有这个限制，智能体可能会陷入什么问题？
如何评估一个智能体的"智能"程度？仅使用准确率指标是否足够？

为什么会出现"幻觉"

原因	说明
训练数据噪声与知识过时	模型学习到的是训练时的知识，可能已经过时或包含错误
检索增强阶段召回错误证据	RAG 召回了"相似但不正确"的证据（向量相似度 ≠ 语义等价）
工具调用失败或返回不完整信息	外部工具异常时，模型可能"编造"答案来补全
长链路推理中的误差累积	多步推理中，每一步的小误差会被放大
奖励目标与真实业务目标不一致	RLHF 的奖励模型可能鼓励某些表面行为而非真实正确性

为什么要限制最大循环次数

若不限制最大循环次数，可能出现：

风险	说明
死循环或无效反复调用工具	智能体可能在无效路径上反复尝试
Token 与时延成本失控	无限增长导致成本和响应时间不可控
上下文被噪声挤占	过长历史导致关键信息被稀释，决策质量下降
陷入局部最优	缺乏"及时止损"机制，无法跳出无效策略

如何评估智能体"智能程度"

仅看准确率不够，应至少加入以下维度：

维度	指标示例
任务成功率	端到端目标是否完成（如客户问题是否解决）
成本与时延	Token 消耗、调用次数、响应时间
稳定性	多次运行结果一致性
鲁棒性	异常输入与边界条件下的表现
安全与合规	是否输出有害内容、是否越权访问
可解释性与可审计性	能否追溯关键决策依据

4. 小结

智能体工程的关键不在"模型参数更大"，而在于：

任务定义是否清晰（PEAS 是第一步）
决策结构是否匹配场景（反应式/规划式/混合式各有所长）
评估与兜底是否完善（准确率之外的多维指标 + 人工兜底）

从工程落地看，混合架构通常是最实用路线：规则保底、智能增益、人工兜底。这既保证了系统的可控性，又能在复杂场景下发挥智能体的优势。

Agent on impself小破站

Agent 08-记忆与检索

智能体记忆系统与RAG系统 - 问题详解

目录

1. 情景记忆 vs 语义记忆评分机制对比

评分公式对比

设计原因分析

核心设计理念

2. 个人健康管理助手的记忆设计

整体架构

具体应用场景

数据流向示例

3. 工作记忆整合机制设计

整合决策矩阵

自动整合算法实现

4. 基于语义边界的分块算法

问题背景

语义边界检测算法

不同文档类型的分块策略

5. MQE vs HyDE 检索策略对比

检索方法对比

场景选择矩阵

实际场景效果对比

6. 嵌入方案选型对比

三种方案全面对比

选型决策树

混合方案建议

7. 智能遗忘策略实现

多因素加权遗忘算法

遗忘决策阈值

8. 记忆归档机制设计

记忆生命周期管理

归档实现示例

9. 隐私数据彻底清除方案

多层验证清除机制

实现代码

10. RAG vs Memory 智能路由

智能路由机制

路由决策表

11. 智能学习报告生成器设计

报告生成器架构

报告结构示例

12. 多用户数据隔离方案

Qdrant 隔离方案

Neo4j 隔离方案

性能优化策略

13. 知识图谱质量评估

质量评估维度

常见错误类型

14. 图检索 vs 向量检索对比

查询类型对比表

混合检索示例

图检索优势场景

总结

Agent 05-基于低代码平台构建智能体

Agent 04-智能体经典范式构建

引言

核心知识点概览

1. ReAct：思考-行动的动态循环

2. Plan-and-Solve：先规划，后执行

3. Reflection：执行-反思-优化

三种范式的对比分析

架构组合示例

小结与展望

思考与练习

练习一：范式理解与选择

练习二：输出解析的鲁棒性

练习三：工具调用与扩展

练习四：动态规划机制

练习五：Reflection 机制深入

练习六：提示词工程

练习七：综合实战

结语

Agent 03-大模型语言基础

Agent 02-智能体发展史

2.1 基于符号与逻辑的早期智能体

物理符号系统假说

专家系统

SHRDLU

2.2 基于规则的聊天机器人