架构

单模型的问题 大多数 Agent 框架使用单个 LLM 完成所有工作：理解指令、规划任务、调用工具、生成回复、总结经验。这带来三个问题： 成本高：用 GPT-4o 做经验总结是大材小用，总结任务用 Llama 3 8B 就够了 延迟高：任务执行完后还要等同一个模型完成总结才能返回 质量妥协：为了省成本用便宜模型，执行质量打折；用好模型，总结又太贵 Hermes 的解法是双 LLM 架构：一个主模型负责"干活"，一个轻量复盘模型负责"学习和记忆"。 架构全景 用户消息 │ ▼ ┌──────────────┐ │ 主 LLM │ ← GPT-4o / Claude / Qwen（强大但昂贵） │ (执行层) │ │ │ │ · 任务理解 │ │ · 规划决策 │ │ · 工具调用 │ │ · 结果生成 │ └──────┬───────┘ │ │ 同步返回结果给用户 ▼ 用户收到回复 │ │ 异步触发（不阻塞用户） ▼ ┌──────────────┐ │ 复盘 LLM │ ← Llama 3 8B / Qwen 7B（轻量但够用） │ (学习层) │ │ │ │ · 经验总结 │ │ · 技能提炼 │ │ · 记忆更新 │ │ · 画像修正 │ └──────────────┘ 关键点：复盘 LLM 完全异步执行，用户不需要等待学习过程完成。 ...

为什么需要 LLM API 网关 当你的团队同时使用 OpenAI、Anthropic、本地模型等多个 LLM 提供商时，直接在业务代码中调用各家 API 会带来一系列问题：密钥散落各处、无法统一限流、缺乏调用审计、模型切换成本高。LLM API 网关就是解决这些问题的中间层。 ┌──────────────────────────────────────────────────────┐ │ 业务服务层 │ │ (Chat UI / RAG / Agent / Code Gen) │ └──────────────────┬───────────────────────────────────┘ │ 统一 API: POST /v1/chat/completions ┌──────────────────▼───────────────────────────────────┐ │ LLM API Gateway │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌────────────┐ │ │ │ 路由引擎 │ │ 限流器 │ │ 缓存层 │ │ 审计日志 │ │ │ └─────────┘ └─────────┘ └─────────┘ └────────────┘ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 密钥管理 │ │ 重试器 │ │ 负载均衡│ │ │ └─────────┘ └─────────┘ └─────────┘ │ └──────┬──────────┬──────────┬──────────┬─────────────┘ │ │ │ │ ┌────▼────┐┌───▼────┐┌───▼─────┐┌───▼──────┐ │ OpenAI ││Claude ││ Llama ││ Qwen │ │ API ││ API ││ Local ││ API │ └─────────┘└────────┘└─────────┘└──────────┘ 多模型路由 路由引擎是网关的核心。它根据任务复杂度、成本预算、延迟要求将请求分发到最合适的模型。 ...

Agent Loop：龙虾的大脑 OpenClaw 的核心是一个称为 Agent Loop 的执行循环。这不是简单的 while(true) 轮询，而是一个融合了感知、决策、行动、记忆的完整认知架构。 ┌─────────────────────────────────────────┐ │ Agent Loop │ │ │ │ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │ 感知 │───▶│ 决策 │───▶│ 行动 │ │ │ │Perceive│ │Decide│ │ Act │ │ │ └──┬───┘ └──────┘ └──┬───┘ │ │ │ │ │ │ │ ┌──────┐ │ │ │ └────│ 记忆 │◀───────────┘ │ │ │Memory│ │ │ └──────┘ │ └─────────────────────────────────────────┘ 每一轮循环包含四个阶段，下面逐一拆解。 1. 感知层（Perceive） 感知层负责接收和解析输入信号，包括： 用户消息：来自 Telegram、WhatsApp、Discord 等 50+ 渠道 定时触发：cron 任务、心跳轮询 系统事件：文件变更、进程状态、设备传感器 Agent 间通信：多 Agent 协作时的消息传递 interface Perception { source: "user" | "cron" | "system" | "agent"; channel: string; // "telegram", "webchat", "cron" ... rawContent: string; // 原始内容 metadata: { timestamp: number; priority: "low" | "normal" | "high" | "urgent"; context?: Context; // 上下文继承 }; } 感知层的关键设计是多路复用。OpenClaw 可以同时监听多个渠道的消息，通过消息网关统一格式后送入决策层。这就像龙虾的触角——同时感知水流、温度、化学信号。 ...

1. Transformer 的诞生与核心思想 2017 年 Google 发表《Attention Is All You Need》，Transformer 彻底取代了 RNN/LSTM 的序列建模范式。其核心创新：完全基于注意力机制，消除循环结构，实现高度并行化训练。 Transformer 的三大设计支柱： 组件 作用 解决的问题 Self-Attention 捕捉序列内任意位置间的依赖 RNN 长距离梯度消失 Positional Encoding 注入位置信息 注意力本身是排列不变的 Residual + LayerNorm 稳定深层网络训练 深层网络梯度退化 2. 自注意力机制（Self-Attention） 2.1 公式推导 给定输入序列 $X \in \mathbb{R}^{n \times d}$，通过三个线性投影得到 Query、Key、Value： $$Q = XW_Q, \quad K = XW_K, \quad V = XW_V$$ 注意力计算公式： $$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$ 其中 $\sqrt{d_k}$ 是缩放因子，防止内积值过大导致 softmax 梯度饱和。 为什么除以 $\sqrt{d_k}$？ 当 $d_k$ 较大时，$QK^T$ 的方差为 $d_k$（假设 $Q, K$ 各分量独立标准正态），softmax 输入过大时梯度趋近于零。缩放后方差恢复为 1。 ...

超越朴素 RAG 朴素 RAG 的流程是：用户提问 -> 检索 top-K 文档 -> 拼接到 Prompt -> LLM 生成。这对简单问题够用，但面对复杂问题力不从心。本文介绍 6 种高级 RAG 架构模式。 模式一览 模式 核心思想 适用场景 复杂度 多跳检索 分步检索，每步基于前步结果 多跳推理问题 中 递归检索 先粗后细，分层检索 层级结构文档 中 自适应检索 LLM 决定是否检索/检索什么 不确定是否需要检索 高 Self-RAG LLM 自我反思检索质量 高质量要求 高 CRAG 检索质量评估+Web兜底 知识库覆盖不全 高 模块化 RAG 可插拔模块组合 生产环境灵活部署 高 1. 多跳检索（Multi-Hop Retrieval） 面对"张三所在公司的CEO毕业于哪所大学？“这种问题，单次检索无法回答。需要： Hop 1: 检索"张三" -> 得到所在公司"ABC公司" Hop 2: 检索"ABC公司 CEO" -> 得到"李四" Hop 3: 检索"李四 教育背景" -> 得到"清华大学" class MultiHopRetriever: def __init__(self, llm_client, vector_store): self.llm = llm_client self.store = vector_store self.max_hops = 4 async def retrieve(self, query: str) -> list[dict]: all_docs = [] current_query = query for hop in range(self.max_hops): docs = await self.store.search(current_query, top_k=3) all_docs.extend(docs) prompt = f"""问题: {query} 已知信息: {self._format_docs(all_docs)} 如果已有足够信息回答问题，回复"SUFFICIENT"。 如果需要更多信息，生成下一个检索查询（只输出查询）。""" resp = await self.llm.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], temperature=0 ) next_action = resp.choices[0].message.content.strip() if next_action == "SUFFICIENT": break current_query = next_action return all_docs def _format_docs(self, docs): return "\n".join(f"[{i}] {d['content']}" for i, d in enumerate(docs)) 2. 递归检索（Recursive Retrieval） 适用于层级结构文档。先检索章节级别（粗粒度），再在选中章节内检索段落级别（细粒度）： ...