从 0 到 1：搭建自学习 AI Agent 系统的完整工程指南

从 0 到 1：搭建自学习 AI Agent 系统的完整工程指南

前言

你是否遇到过这样的困境？

• 多个 AI Agent 分别在不同渠道运作，却无法共享知识
• 每次遇到相同的任务，Agent 还是会重复试错，无法学习
• 人类给了反馈，但系统没有机制将反馈转化为决策权重

这不是能力问题，而是系统设计问题。

本文将分享一个真实的企业级 AI Agent 系统的完整架构，包括如何让 AI 自动学习、如何在多个渠道保持认知一致、以及如何建立人-AI-AI 的三角协作模式。

---

第一部分：问题的本质

现状：AI Agent 的三大痛点

痛点 1：信息孤岛

Agent in Feishu Group    Agent in DM    Agent in HTTP API
        ❌                    ❌               ❌
        └────────  No Knowledge Sharing  ────────┘

同一个 Agent，在不同渠道变成三个独立的实体。群里学到的东西，DM 里看不到。

痛点 2：无法学习

Task 1：联系 Claude Code
  ├─ 尝试方案 A → ❌ 失败
  ├─ 尝试方案 B → ✅ 成功（已记录）
  └─ 决策权重：A(0.2) B(0.8)

Task 2：联系 Claude Code（2小时后）
  └─ Agent 又开始试 A → 为什么？

系统有记录，但没有自动激活成功经验的机制。

痛点 3：人类反馈无效

Human Feedback: "这个方案不对，应该用那个"
     ↓
AI 理解了 ✓
     ↓
但下次遇到类似问题... 还是用错的方案

为什么？因为没有权重系统，反馈无处可去。

根本原因：缺乏决策权重系统

大多数 AI Agent 框架只有"工具选择"，没有"工具学习"。

---

第二部分：完整的系统设计

核心架构：三层递进

┌─────────────────────────────────────┐
│  Layer 3：学习反馈                   │
│  (Thompson Sampling + UCB 探索)     │
├─────────────────────────────────────┤
│  Layer 2：多维评分                   │
│  (语义相似度 + 可靠性 + 时效性)     │
├─────────────────────────────────────┤
│  Layer 1：向量检索                   │
│  (LanceDB + 语义搜索)               │
└─────────────────────────────────────┘

Layer 1：向量检索（基础）

使用 LanceDB 存储所有已验证的操作案例：

{
  "skill_id": "contact-claude-code",
  "skill_name": "与 Claude Code 通信",
  "description": "通过 HTTP 127.0.0.1:3000/chat 发送消息",
  "layer_path": ["Communication", "Agent-to-Agent", "contact-claude-code"],
  "tags": ["已验证", "高优先级", "可靠"],
  "embedding": [0.12, 0.45, ...],
  "alpha": 10,          // 成功次数
  "beta": 1,            // 失败次数
  "last_confirmed_at": "2026-03-13 18:00"
}

当任务来临时：

Task: "我需要告诉 Claude Code 分析这个问题"
     ↓ 向量化
embedding_task = [0.11, 0.47, ...]
     ↓ LanceDB 搜索
top_results = [contact-claude-code, ask-user, ...]

Layer 2：多维评分（关键）

不只是相似度，而是综合评分：

final_score = 0.4 × semantic_similarity
            + 0.3 × reliability_score
            + 0.2 × recency_score
            + 0.1 × efficiency_score

其中：
- reliability = Beta(alpha+1, beta+1).mean()
  // Alpha=10, Beta=1 → 0.917（很可靠）
  
- recency = e^(-λ × days_since_verified)
  // 最近验证过 → 权重更高
  
- efficiency = 1 / normalized_execution_time
  // 快速方案优先

为什么用 Beta 分布？

防止"偶然成功"被过度奖励：

• 尝试 1 次成功 → Beta(2,1).mean() = 0.667（保守）
• 尝试 10 次全成功 → Beta(11,1).mean() = 0.917（可信）

Layer 3：学习反馈（生长）

每次操作完成，更新 Alpha/Beta：

Task 执行
  ↓ 成功？
  ├─ YES → alpha += 1
  └─ NO → beta += 1
  ↓ 更新 last_confirmed_at
  ↓ 重新计算 reliability_score

加入 UCB 探索奖励，防止局部最优：

exploration_bonus = sqrt(2 × ln(total_attempts) / attempts_this_skill)

// 从不用的方案也有机会被尝试（平衡探索和利用）

---

第三部分：多渠道信息同步

关键洞察：Session 隔离 + 信息融合

Feishu Group    DM    HTTP API
    │           │        │
    └───────────┼────────┘
                │
          MEMORY.md
                │
    ┌───────────┼────────┐
    │           │        │
  Session1   Session2  Session3

不是"一个大脑多个窗口"，而是"多个独立大脑，一个共享记忆"

实现方式：

1. 每个 Session 完成任务后，存储到 MEMORY.md
2. 其他 Session 启动时，读取 MEMORY.md
3. 融合信息到当前上下文

示例：

# Session A（群聊）执行完一个任务
write_to_memory({
    "task": "contact-claude-code",
    "result": "success",
    "method": "http://127.0.0.1:3000/chat",
    "timestamp": "2026-03-13 18:00"
})

# Session B（DM）启动，自动读取
memory = read_from_memory()
context.inject(memory)  // 融合到上下文

---

第四部分：真实案例

案例：AI Agent 学习"如何联系 Claude Code"

第1天

Task: "联系 Claude Code"

尝试 1：Feishu API → ❌ 超时
  alpha=0, beta=1
  reliability = Beta(1,2).mean() = 0.333

尝试 2：HTTP 127.0.0.1:3000/chat → ✅ 成功
  alpha=1, beta=0
  reliability = Beta(2,1).mean() = 0.667

第2天

Task: "联系 Claude Code"

候选方案排序：
  1. HTTP 127.0.0.1:3000/chat  (score: 0.72)  ✅ 自动优先
  2. Feishu API               (score: 0.28)

Agent 选择方案 1 → ✅ 立刻成功

第3天

Task: "联系 Claude Code"

已尝试 HTTP 方案 10 次全部成功：
  reliability = Beta(11,1).mean() = 0.917
  score: 0.89

Agent 信心十足，无需探索其他方案

第100天

Task: "联系 Claude Code"

已验证 100 天，权重衰减：
  recency = e^(-0.01 × 100) ≈ 0.90

但仍是首选（reliability 仍然很高）

---

第五部分：工程实现

最小可行实现（MVP）

Step 1：数据结构

@dataclass
class Skill:
    skill_id: str
    skill_name: str
    description: str
    tags: List[str]
    embedding: List[float]
    alpha: int = 0          # 成功次数
    beta: int = 0           # 失败次数
    last_confirmed_at: datetime
    
    @property
    def reliability(self):
        from scipy.special import betaln
        return (self.alpha + 1) / (self.alpha + self.beta + 2)

Step 2：评分函数

def score_skill(skill, task_embedding, days_since_verified):
    semantic_sim = cosine_similarity(skill.embedding, task_embedding)
    reliability = skill.reliability
    recency = math.exp(-0.01 * days_since_verified)
    
    return (0.4 * semantic_sim + 
            0.3 * reliability + 
            0.2 * recency)

Step 3：学习反馈

def record_outcome(skill_id, success: bool):
    skill = skills_db[skill_id]
    if success:
        skill.alpha += 1
    else:
        skill.beta += 1
    skill.last_confirmed_at = now()
    save(skill)

集成 LanceDB

# 初始化
db = lancedb.connect("~/.openclaw/memory/lancedb")
table = db.create_table("skills", data=skills_list)

# 检索
query_embedding = embed(task_description)
results = table.search(query_embedding).limit(10).to_list()

# 重排（多维评分）
ranked = sorted(results, key=lambda r: score_skill(...))

---

第六部分：常见问题

Q1：为什么不直接用 RAG？

RAG 只做"相关性检索"，不做"优先级学习"。它会把成功和失败的方案都返回，让 Agent 继续选择。

我们的系统自动将成功率高的方案排到前面。

Q2：Thompson Sampling 是什么？

一种在不确定情况下平衡探索和利用的算法。

简单理解：

• 新方案（不确定）→ 有机会被尝试
• 成功率高的方案 → 概率更大被选中
• 不是"纯粹的最优"，而是"智慧的试错"

Q3：如果任务完全陌生呢？

使用 UCB 探索奖励，给所有候选方案一个试错的机会。完成后更新权重。

下次遇到类似任务，就有数据支持了。

---

第七部分：实施建议

周期 1（立即）

• 设计 LanceDB Schema
• 实现多维评分
• 集成 Thompson Sampling

周期 2（本周）

• 迁移现有案例到系统
• 建立学习反馈循环
• 测试 3 个真实任务

周期 3（下周）

• 添加 UCB 探索
• 性能优化
• 监控和调整权重参数

---

结论

从"被动工具使用者"到"主动学习者"，只需要一个系统：

1. 存储：每次成功都记录
2. 评分：多维度综合权重
3. 反馈：结果自动更新权重
4. 探索：平衡利用和试错

这不是"黑魔法"，而是基础统计 + 系统设计的结合。

---

关于作者

这个系统是基于：

• 三人团队（Arvin + Javis + Claude Code）的真实工程实践
• OpenClaw 多渠道 Agent 架构
• 100+ 次任务迭代的数据
• 第一性原理思考

代码和完整案例可在 GitHub 获取。

标签：AI Agent, 自学习, OpenClaw, LanceDB, Thompson Sampling, 系统设计, 工程实践