一个人干不了所有活

单个智能体再强，也有能力边界。它不可能同时是代码专家、财务分析师、法律顾问和设计师。于是多 Agent 协作成为自然选择——让不同专长的 Agent 各司其职，协同完成复杂任务。

听起来很美好，实战中却是一地鸡毛。

Medium 上有一篇被广泛引用的文章，标题就很直白：《Multi-Agent AI 的黑暗心理学：30 种能摧毁你整个系统的失败模式》。30 种可能是夸张了，但核心观点不虚——多 Agent 系统的复杂度不是线性增长，而是指数增长。2 个 Agent 的协调问题比 1 个 Agent 多不止一倍。

三种协作架构

先理清多 Agent 协作有哪几种模式，再分析各自的问题。

模式一：Orchestrator-Worker（中心调度）

一个"主管" Agent 负责理解任务、分解子任务、分派给专业 Worker Agent，最后汇总结果。

[Orchestrator] → 分派 → [代码 Agent]
              → 分派 → [财务 Agent]
              → 分派 → [设计 Agent]
              ← 汇总 ← 各 Agent 结果

优点：逻辑清晰、责任划分明确 缺点：Orchestrator 成为单点瓶颈——它既要理解全局，又要管理分发，还要处理冲突

模式二：Pipeline（流水线）

Agent 按照固定顺序串联执行，前一个的输出是后一个的输入。

[需求分析 Agent] → [设计 Agent] → [编码 Agent] → [测试 Agent] → [部署 Agent]

优点：简单、可预测 缺点：无反馈回路——如果测试 Agent 发现问题需要返回设计阶段，流水线很难回溯

当智能体的"手"不听使唤

如果说幻觉是智能体"脑子"的问题，那工具调用失败就是"手脚"的问题。智能体不仅要思考，还要行动——调用 API、查询数据库、操作文件系统。而但凡涉及外部系统交互，失败的维度比纯文本幻觉要多得多。

Arize AI 2026 年对生产环境智能体的故障分析指出：工具相关失败占 Agent 异常的 40% 以上，其中最危险的不是"调用失败"本身，而是失败后的错误处理——智能体对错误的理解和处理能力，往往比工具调用本身更不可靠。

三大失败模式

模式一：静默错误——最危险的失败

工具返回了错误信息，但智能体没有正确解读，把错误响应当做正常结果继续推理。

典型场景

// 智能体调用天气 API
{"tool": "get_weather", "arguments": {"city": "北京", "date": "2026-07-01"}}

// API 返回错误
{"error": "city_not_found", "message": "City name must be in English: Beijing"}

// 智能体把 json 当成了天气数据继续推理
"根据返回的数据，北京7月1日的湿度和 error 字段显示..."

这比调用直接报错更危险——至少报错时智能体知道出错了，还能重试。静默错误时，智能体浑然不知，把垃圾数据当成金子继续加工。

为什么会发生？

1. 错误格式不统一：不同 API 的错误响应结构不同（HTTP 状态码、JSON error 字段、HTML 错误页……），智能体难以用统一逻辑识别
2. Prompt 缺少错误处理指令：很多人在 system prompt 里只写了"使用 XX 工具查询"，没写"如果工具返回错误，你应该……"
3. 模型倾向"继续完成任务"：遇到异常数据时，模型的训练倾向是给用户一个答案，而不是停下来讨论 API 报错

模式二：参数构造错误——最常见的失败

智能体理解了要调什么工具，但构造参数时出错。

常见错误类型

• 格式错误：日期传 2026/07/01 而 API 要 2026-07-01
• 类型错误：传字符串 "5" 而 API 要整数 5
• 枚举错误：传 "medium" 而有效值只有 ["low", "mid", "high"]
• 遗漏必填参数：忘了传 currency 字段
• 语义错误：传了合法格式但语义不对，比如把 page_size=100 传给了限制最大 50 的分页接口

根因分析

模型对 API 的理解来自 prompt 中的工具描述（Function Schema）。如果描述不够精确——比如某个参数的合法值只写了 string 没有枚举——模型就只能"猜"。

幻觉：智能体最顽固的问题

如果只能用一个词概括当前 AI 智能体最致命的问题，行业里多数人会选"幻觉"（Hallucination）。通用大模型写诗写周报文采斐然，但让它分析"上季度 A 产品线毛利率下降的原因"，它可能编造一串子虚乌有的数据，还附上看起来很专业的百分比。更糟糕的是——语气越自信，越难被非专业用户识破。

Fiddler AI 2026 年的报告给出了一个残酷的数字：生产环境智能体失败率 70%-95%，幻觉是头号杀手。BetterYeah 的调研发现，68% 的企业在 AI 落地中遭遇幻觉问题，其中 32% 因错误累积导致系统性风险。

这不是"模型还不够聪明"的问题。这是智能体的结构性挑战。

从单步错误到幻觉累加

单步幻觉：模型不确定时仍"自信输出"

LLM 的核心训练目标是"合理续写"，而不是"如实回答"。当训练数据中缺少相关信息时，模型不会说"我不知道"——它会生成一段看起来连贯但实际上没有事实支撑的文字。

这是因为：

1. 训练数据偏差：互联网文本中，自信断言远多于谦虚声明"我不确定"
2. 采样机制：模型采样概率最高的 token 序列，不受事实约束
3. 缺乏不确定性建模：模型内部没有显式的"置信度"信号传递给输出层

结果：模型在信息不足时的行为是"编造"，而非"沉默"。

多步累加：小偏差滚雪球

当智能体执行多步任务时，单步幻觉的破坏力被指数放大。看一个典型场景：

步骤 1：检索客户信息 → 幻觉：编造了不存在的客户 ID
步骤 2：用该 ID 查询订单 → 返回空结果
步骤 3：智能体"推断"该客户是新客户 → 编造注册时间
步骤 4：基于虚假注册时间做客户画像分析 → 输出错误结论
步骤 5：基于错误结论撰写运营建议 → 决策偏离

每一步都"合乎逻辑"，但起点就是一个虚构的事实。这就是幻觉累加效应——错误在推理链中不断传播和放大，最终输出和现实南辕北辙。

2025 年 Q1 某金融机构的案例就是典型：智能体在财报分析中第一次幻觉了一个营收数字，后续所有财务比率、趋势判断、投资建议全部基于这个错误数字展开。表面看报告专业完整，实际结论完全失真。

为什么传统 NLP 时代的幻觉没那么致命？

传统 QA 系统也幻觉，但影响范围有限——一次问答的错误不影响下一次。智能体截然不同：它是一个持续运行的闭环系统，前一步的输出是后一步的输入。一个幻觉 token 就像生物学中的基因突变，在后续"转录"过程中被不断放大。

三类幻觉的根源

1. 事实性幻觉

模型编造不存在的事实。典型表现：

从 luck-agent 到 Hermes-lite，我花了两年时间才想清楚这个问题：80% 的请求不需要"思考"，只需要"路由"。

回顾：ReAct 控制器模式的困境

2024 年做 luck-agent 的时候，我采用的是经典的 ReAct 模式（Reasoning + Acting）：

用户输入 → 大模型推理（意图识别 → 规划 → 工具选择 → 执行）→ 输出

所有请求，不管简单还是复杂，都走同一个推理链。一个"查 QPC 里有没有 VPS 相关的记录"的请求，也要经过：

1. 理解自然语言
2. 判断意图类别
3. 选择工具（search_qpc）
4. 构造查询参数
5. 执行并解释结果

问题很明显：

• Token 消耗大：每次推理要带上完整的 system prompt + 工具定义，光上下文就吃掉 3000-5000 token
• 延迟高：一个简单查询要等模型完成完整推理链，响应时间 3-8 秒
• 上下文窗口压力：随着工具数量增加（现在 Hermes-lite 有 20+ 个工具），system prompt 越来越大

我当时就在知识库里记了一条：

“对于个人助理场景，相比最初的 ReAct 控制器模式，Skill 技能路由更适合当前 luckagent：80% 请求是固定模式，不需要复杂推理，技能比 Agent 更稳定，成本更低，响应更快。”

Skill 路由的核心思想

一句话：预定义技能映射，轻量分类先路由，只加载需要的工具和 prompt。

用户输入 → 轻量路由（关键词/意图 → 技能）→ 加载专用 prompt + 工具 → 执行

路由表设计

# 简化版路由逻辑
ROUTING_RULES = {
    "qpc": {
        "keywords": ["QPC", "知识库", "记一下", "记录"],
        "skill": "qpc",
        "tools": ["feishu_bitable_read", "feishu_bitable_write"],
        "prompt": "qpc_skill_prompt"  # 只加载 QPC 相关的 prompt
    },
    "vps": {
        "keywords": ["VPS", "服务器", "防火墙", "Docker"],
        "skill": "gcp-vps-ops",
        "tools": ["terminal", "read_file"],
        "prompt": "vps_skill_prompt"
    },
    "blog": {
        "keywords": ["博客", "文章", "Hugo", "发布"],
        "skill": "hugo-blog",
        "tools": ["terminal", "read_file", "write_file"],
        "prompt": "blog_skill_prompt"
    }
}

对比：同样"查 QPC"操作

Hermes-lite 的 Skill 实现

Hermes-lite 的 skill 系统是这样工作的：

人类 chatbot 最尴尬的瞬间：第二次见面完全不认识你。Agent 的记忆系统怎么同时做到持久化、低成本、不丢上下文？我深入 Hermes-Lite 源码写了一个月，拆解出 5 层架构。

从「鱼的难题」开始

用过 ChatGPT 的人都知道一个痛：下次打开，它完全不记得你了。

对一次性聊天这没问题。但对个人助理——帮你管理 200 条知识库、追踪几个项目的进度、记住你的偏好——这等于每次都要把整段友情重来。

我做 QPC（个人知识库）时就被这个问题卡过。后来折腾 Hermes-Lite、nanobot，逐步摸到一条可行的路。这篇文章从 Hermes-Lite 的实际源码出发，拆解它的 5 层记忆架构，看看一个 Agent 是怎么解决「鱼的难题」的。

总览：5 层架构

┌─────────────────────────────────────────────┐
│  Layer 1: 持久记忆 (MEMORY.md / USER.md)     │  ← 跨会话，纯文本
├─────────────────────────────────────────────�
│  Layer 2: 会话压缩 (ContextCompressor)       │  ← 长对话不爆
├─────────────────────────────────────────────┤
│  Layer 3: 会话检索 (session_search + FTS5)   │  ← 历史不丢
├─────────────────────────────────────────────�
│  Layer 4: 增量写入门控 (Nudge 机制)           │  ← 该记就记
├─────────────────────────────────────────────�
│  Layer 5: 原子性保障 (fcntl + 临时文件)       │  ← 不丢不坏
└─────────────────────────────────────────────┘

每一层解决一个独立问题，层与层之间不耦合。下面逐层拆解。

为什么要裁剪

完整版 Hermes Agent（Nous Research）功能丰富：多平台网关、浏览器自动化、语音 TTS/STT、多 Agent 协作、Kanban 看板等。但这些功能对资源要求不低——在我的测试里，完整配置更适合至少 2GB 内存的机器。

我有一台 GCP e2-micro（2 vCPU / 954MB RAM），想用它跑一个 24/7 在线的 AI Agent 接入飞书。完整版装不下，于是有了这个裁剪实践。

三阶段渐进式裁剪

裁剪不是一步完成的，而是三阶段递进：

第一阶段：本地 Codex 完成初期核心裁剪

在本地电脑上，利用 Codex（OpenAI） 作为辅助分析工具，对完整版 Hermes 进行全面"解剖"：

• 逐一扫描 ~/.hermes/ 目录结构，识别每个模块的职责
• 分析 67 个技能的依赖关系，标记哪些是核心链路的、哪些是边缘功能
• 梳理 config.yaml 中每个配置项的实际作用，搞清楚"关掉会怎样"
• 输出一份裁剪清单：哪些 toolset 可以禁、哪些 skill 可以删、哪些配置可以收紧

这一阶段的核心价值：把"能不能关"这个判断做对。Codex 帮助理解了代码间的依赖关系，避免直接关某个功能导致连锁崩溃。

第二阶段：大 VPS 上跑完整版 + 压测验证

在一台大内存 VPS 上安装完整版 Hermes，作为"对照基准"：

• 记录完整版的实际内存占用（idle / 高负载两种状态）
• 逐个关闭非核心功能，观察内存变化和稳定性
• 跑压测：模拟长时间运行、多轮对话、工具调用密集场景
• 确认裁剪后系统在资源充足环境下依然稳定

这一阶段的目的：建立性能基线 + 验证裁剪组合的安全性。在大 VPS 上翻车无所谓，在小 VPS 上翻车就是服务宕机。