Skill、SubAgent、Memery

在 OpenClaw（以及 Claude Code、Cursor 等现代架构）中，“教会”AI 一项新技能，往往只需要一份 Markdown 文档。本小节我们将通过一个名为 FuFan-OpenClaw 的教学环境（基于 OpenClaw 深度定制），从零开始演示如何让一个原本“甚至不知道今天是几号”的 Agent，瞬间掌握实时天气查询的能力。

Step 1. 基准测试：裸机状态下的无助

为方便示例，这一步给的是一个简单任务，虽然可以用单个工具完成，但仍可以展示 skill 的整个创建流程。

Step 2. 核心操作：物理装载 Skill

接下来，进行“技能注入”。操作非常原始且直观——文件拖拽。

找到目标技能文件夹 get_weather。
将其直接拖入 OpenClaw 后端的 /skills 目录下。

打开 get_weather 文件夹，发现里面只有一个 SKILL.md 文件。让我们看看它的内容（如下图）：

这就是 Agent Skills 的核心秘密——用自然语言编程。这份文档其实就是写给 Agent 看的“SOP 操作手册”，它包含以下五个关键部分：

元数据 (Metadata)：
1. 顶部定义了 name: get_weather。这是技能的身份证，Agent 通过它在数千个技能中索引到由于。
使用场景 (Trigger)：
1. 明确告诉 Agent：“当用户询问某个城市的天气情况时使用此技能”。这是技能的触发器。
执行步骤 (SOP)：
1. 这是最精彩的部分。它没有写代码，而是教 Agent 如何使用工具：
  - 第一步：从用户话里提取城市名。
  - 第二步：调用 fetch_url 工具。注意，这里直接给出了具体的 URL 构造规则 https://wttr.in/{城市名}?format=j1。
  - 第三步：教 Agent 如何看懂返回的 JSON 数据（提取温度、湿度、风速）。
示例 (Few-Shot)：
1. 给出了一个 查询北京天气 的标准对话范例。这能极大提升 Agent 执行的稳定性，防止它胡乱输出。
注意事项 (Constraints)：
1. 比如“建议使用英文拼写城市名以提高准确性”。这是给 Agent 的兜底策略。

Step 3. 验证测试：技能觉醒

文件放入后，无需重启服务器（Fufan-OpenClaw 支持热加载），我们再次输入同样的指令，Agent 最终回复北京天气信息。

技术总结：为什么 Agent Skills 能引爆开发者生态？

与传统的软件开发相比，它展现出了极低的技术门槛和极高的灵活性。

本质：Agent Skills 将“编程”降维成了“写文档”。只要你逻辑清晰，能把业务流程写成说明书，你就能开发 Agent。这使得非技术人员（产品经理、法务、运营）也能成为 Agent 开发者。

极简的“热插拔”架构

在 OpenClaw 的架构中，Skill 是完全解耦的静态文件。这意味着：

无需编译：修改 Skill 不需要重启服务。
无需环境配置：只要有通用的工具（如 Web Search, Python REPL），Skill 就能运行，不需要为每个功能单独配置 Docker 或依赖库。

结论：

Function Calling 是底层的“零件”，它是给机器看的。
MCP 是连接的“管道”，它是给系统用的。
Agent Skills 则是**“说明书”**，它是给 AI 大脑看的。

Agent Skills 之所以能大范围普及，正是因为它屏蔽了底层的零件和管道，让开发者可以直接通过“写说明书”来驱动 AI。这就是为什么我们说：在 Agent 时代，最好的编程语言就是你的母语。

1、完整的Agent Skills底层执行流程

2.2.1 深度思考：从“说明书”到“行动”的跨越

在上一节中，我们看到只需把文件夹一拖，Agent 就像《黑客帝国》里的 Neo 一样瞬间学会了“功夫”。但这看似简单的“魔法”背后，其实隐藏着一系列精密的工程设计。

这里我想请大家暂停一下，思考几个关乎系统生死的工程问题：

上下文爆炸问题 (Context Window)：如果我们有一万个 Skills，每个 Skill 的说明书都有 2KB，难道我们要把这 20MB 的文字全部塞进 System Prompt 吗？显然不行，Token 会瞬间溢出，费用会爆炸。那么 Agent 是怎么知道 get_weather 存在的？
知识与能力的鸿沟： SKILL.md 里写着“去访问 wttr.in 网站”，但这只是一行文字。文字本身是没有执行力的。Agent 最终必须通过代码去发起 HTTP 请求。那么，它是如何把“文档里的文字指令”转化为“实际的代码执行”的？

要回答这些问题，我们不能只看聊天界面，必须打开 FuFan-OpenClaw 的**“后台原始消息队列” (Raw Message Logs)**，看看在那个 0.5 秒的瞬间，Agent 的大脑里到底发生了什么。

2.2.2 流程解密：四步完成技能闭环

我们以刚才的“查询北京天气”为例，通过 FuFan-OpenClaw 的调试后台，还原这一次 Skill 调用的全过程。

Phase 1: 意图识别与技能加载 (Turn 1 - Skill Loading)

当用户输入指令后，当前上下文（Context）中包含了 System Prompt（内含 Skill 简要索引）和 User Message。当我们把 get_weather 文件夹拖入系统时，OpenClaw 并没有立即读取 SKILL.md 的全文。为了节省上下文，它只读取了文件名和元数据。我们在系统日志中可以看到这样一条 System Message：

Phase 2: 技能注入与上下文增强 (Turn 2 - Context Injection)

这是最关键的一步。OpenClaw 后端接收到 read_file 请求，读取磁盘上的 Markdown 文件，并将文件内容封装为标准的 Function Response Message，回填至消息队列中。

Phase 3: 基于 SOP 的工具执行 (Turn 3 - Execution)

此时，消息堆栈中已经包含了完整的技能说明书。模型发起第二轮推理，严格遵循刚刚注入的 content 中的指示（SOP），构造具体的业务请求。模型并不是自己“编造”了 URL，而是根据 Phase 2 中注入的上下文（Markdown 中的步骤 2），进行了 In-Context Learning（上下文学习），完成了从自然语言指令到结构化参数的映射。

Phase 4: 最终响应 (Final Response)

最后，fetch_url 的返回结果（JSON）再次以 role: tool 的形式进入消息队列。模型综合所有上下文，输出最终的自然语言回复。

2、架构核心：三层渐进式加载机制

Agent Skills 系统设计的最大挑战在于 Context Window（上下文窗口）的限制。为了在有限的 Token 预算内实现无限的能力扩展，Anthropic 提出了一套 “渐进式披露” (Progressive Disclosure) 的加载机制。

这套机制将 Skill 的生命周期划分为三个层级：

Level 1: 索引层 (Index Layer) - System Init

加载内容：仅加载 Skill 的 元数据 (Metadata)，通常只有 name 和 description。
位置：常驻于 System Prompt。
作用：建立 “能力目录”。此时，Agent 知道自己“能做什么”（比如“能查天气”），但完全不知道“具体怎么做”。
Token 消耗：极低（每个 Skill 约消耗 20-50 Tokens）。

Level 2: 指令层 (Instruction Layer) - On Demand

加载内容：SKILL.md 的完整正文（包含 SOP 和 Examples）。
触发机制：当 Agent 的意图识别（Router）命中某个 Metadata 时，系统触发 Function Calling (read_file)。
位置：动态注入到 Current Context（当前对话上下文）。
作用：JIT (Just-in-Time) 知识注入。Agent 在这一刻才真正“学会”了该技能的业务逻辑。

Level 3: 执行层 (Runtime Layer) - Execution

加载内容：具体的原子工具调用（Function Arguments）和外部资源。
触发机制：Agent 阅读指令层后，根据 SOP 发起具体的 Tool Calls。
作用：物理执行。调用 API、运行 Python 脚本或查询数据库，获取最终结果。

3、标准协议：SKILL.md 解剖

在 Agent Skills 范式中，SKILL.md 是承载业务逻辑的核心载体。它采用 Markdown + YAML Frontmatter 的混合格式。一个符合规范的 SKILL.md 必须包含以下结构：

---
name: skill_name_id  # [必填] 技能唯一标识符，建议使用 snake_case
description: A concise description of what this skill does. # [必填] 用于路由匹配的关键语义信息
version: 1.0.0 # [选填] 版本控制
---

# [技能名称]

## Usage (使用场景)
明确描述在什么情况下应该激活此技能。这有助于模型进行自我反思和意图确认。

## Steps (执行步骤)
这是 Skill 的灵魂。使用自然语言编写的算法逻辑（SOP）。
1. 第一步做什么...
2. 第二步调用哪个工具...
3. 第三步如何处理数据...

## Examples (示例)
User: [用户输入]
Assistant: [期望的思考过程和工具调用]
System: [工具返回结果]
Assistant: [最终回复]

## Considerations (注意事项)
边界条件处理、错误重试机制或安全合规要求。

4、Agent Skills 系统设计关键点

从工程视角来看，Agent Skills 并非简单的文档堆砌，而是一种“高内聚、低耦合”的系统架构设计。

要构建一个企业级可用的 Agent Skills 系统，我们需要从系统工程的角度，重新审视 Agent（宿主环境）与 Skill（业务逻辑）之间的交互协议。以下是系统设计的五大核心要素：

3.1 架构依赖：运行时 (Runtime) 与业务逻辑 (Logic) 的解耦

首先，我们需要在架构层面明确 Agent 与 Skills 的依存关系。

Skill 的本质：它是静态的业务逻辑定义（Static Logic Definition）。无论是 Markdown 还是 YAML，它本质上是一组“未被执行的代码”或“待处理的 SOP”。
Agent 的本质：它是动态的执行运行时（Dynamic Execution Runtime）。它提供了推理引擎（LLM）、记忆模块（Memory）和工具接口（Interfaces）。
系统设计难点：Skill 离开了 Agent 只是文本文件，无法产生价值；而 Agent 离开了 Skill 只是一个通用的聊天机器人。系统设计的核心，在于构建一个能够标准化解析、加载并执行这些静态逻辑的“Agent Runtime”。

3.2 核心机制：动态上下文加载 (Dynamic Context Loading)

在 Skill 系统设计中，最关键的技术挑战在于 Token 效率与信息完备性的平衡。这本质上是一项精密的上下文工程 (Context Engineering)。

如果预置了海量的 Skills，直接全部注入 System Prompt 会导致两个致命问题：

Context Window 溢出：Token 消耗指数级增长，成本不可控。
Attention Dilution（注意力稀释）：过长的上下文会导致模型推理能力下降（Lost in the Middle 现象）。

因此，成熟的系统设计必须采用**“索引-按需加载” (Index-Lazy Loading)** 策略：

索引层：在 System Message 中仅保留极简的元数据索引（Name + Description）。
加载机制：利用 Function Calling (read_file) 作为触发器，实现 Skill 内容的 Just-in-Time (JIT) 注入。
生命周期管理：在任务结束后，需及时清理上下文，防止 Token 堆积。

3.3 能力分层：编排层 (Orchestration) vs. 执行层 (Execution)

在定义 Skill 时，必须严格区分“指导”与“执行”的边界。

Skill (编排层)：负责指导。它定义了任务的 SOP（标准作业程序）、决策树和数据处理逻辑。但请注意，Skill 文档本身不具备操作系统的权限。
Agent (执行层)：负责落地。Agent 必须原生集成一系列原子工具 (Tools)，如 network_client (联网)、code_interpreter (代码执行)、database_connector (数据库连接)。

设计原则：Skill 是对 Agent 原子能力（tool）的高阶编排。如果 Skill 定义了“查询天气”的步骤，Agent 的执行层必须预先挂载了 fetch 或 search 工具。若底层原子能力缺失，上层的编排逻辑将无法闭环。

3.4 协议对齐：双向接口规范 (Interface Alignment)

基于上述分层，Agent Skills 系统的设计必须遵循**“双向协议对齐”**：

Agent 端规范：
1. 必须具备工具反思能力：能够识别何时需要查阅文档（调用 read_file）。
2. 必须具备标准化沙箱：为 Skill 的执行提供安全的文件读写和网络访问环境。
Skills 端规范：
1. 能力感知：SOP 的编写必须基于 Agent 已有的工具集（Tools Schema）。
2. 格式统一：必须遵循系统预设的解析标准（如 OpenClaw Standard Markdown），确保 Agent 能正确提取 Intent（意图）和 Steps（步骤）。

Skill 不是“多一个 prompt 模板”，而是把 Agent 的做事方法变成可沉淀、可复用、可治理的能力模块；它很可能是大模型 Agent 从“会推理”走向“会长期工作”的关键中间层。

5、两种skill

1）自然语言 skill
以说明文档、步骤模板、触发规则为主，优点是便于写和编辑，缺点是执行不够严格。

2）代码 skill

直接把技能写成可执行代码或脚本。Voyager 就是典型代表。优点是可复现、可验证，缺点是环境依赖重。
当一个 skill 所使用的工具不常用较冷门，或者是某个 skill 专门所使用，那么就可以把它放到skill的配置中，而不放入整个agent中，给agent可以获得该工具的执行权限，但看不到源代码。

6、Skill vs Tool vs MCP

在系统架构中，必须清晰界定 Skill (技能)、Tool (工具) 和 MCP (模型上下文协议) 的边界：

概念	定义	形象比喻	职责
Skill	业务逻辑封装 (SOP)	菜谱	告诉 Agent “先切菜，再热油，最后炒”。它不直接操作物理世界，而是编排工具的使用顺序。
Tool	原子能力接口 (API)	菜刀/炒锅	执行具体的物理动作（如 `fetch_url`, `execute_sql`）。它没有业务逻辑，只有功能。
MCP	连接标准协议	厨房接口标准	规定了“菜刀”如何连接到“手臂”上。它解决了连接问题，但不解决“怎么做菜”的问题。

二、MutiAgent

1、Building Effective AI Agents解读：

多智能体系统确实能让复杂任务性能暴增，但他带来的任务复杂度，Token开销和调试黑洞，会让大多数团队陷入泥潭，这部分内容参考：

Anthropic 《Building Effective AI Agents》深度解读-多智能体系统90%性能提升背后的真实代价?

下面将展示多智能体到底解决什么问题，什么时候必须用，以及他会带啦哪些真实代价。

多智能体架构的本质是分而治之，把一个复杂任务拆解成多个子任务，分发给不同专长的Agent执行，最后综合结果。

为什么要这么做？因为一个大模型的注意力是有限的，当你让单个模型在同一个上下文里，既要处理医学知识，又要审核法律条文。不同领域的信息会互相污染，推理能力会断崖式下降。对于需要独立推进多个独立方向的复杂任务，多智能体性能比单体高出90.2%。类似于不会让一个全栈工程师独自做出一个复杂的软件，而是让前端、后端、测试的敏捷团队分工协作才能突破单体的物理极限。

但性能提升不是免费的。

第一个代价是Token消耗，呈指数级增长，多个Agent之间互相传递上下文，每次通信都在烧钱。如果逻辑没写好，几个Agent陷入无意义的循环对话，可能会消耗大量的API资源，所以简单查询绝对不能出发昂贵的多体工作流，正确做法是设置前置的轻量级路由节点。只有真正复杂的高价值任务，才允许流入多智能体系统。

第二个代价更致命，调试变成了噩梦，传统开发遇到Bug可以打断点排查，但Agent的推理本身就带有随机性，而且是动态变化的，在多智能体系统里，这种不确定性会指数级放大，举个形象的比喻，单体Agent出错就像一辆爆胎，看轮胎就好了，就像城市交通网络全黑导致三千辆车连环相撞，这时候盯着一辆车的油门线没有任何意义。你必须掌握整个交通系统在那一刻的全局调度录像。所以可观测性成了生死攸关的命脉。必须建立完整的追踪系统，不只记录每个Agent的输出，还要记录他们的决策模式、交互结构、任务委派链路。只有具备这些全局透视，你才能在涌现行为失控时找到根本原因。

那什么时候必须用多智能体，有3条判别准则：

第一，问题极度开放，无法提前写死步骤需要在执行过程中灵活转向，探索旁支路线。
第二，存在领域冲突，当混淆领域达到两个及以上时，单体模型会因为注意力稀释而表现下滑。这时候必须物理隔离不同专业的推理上下文。
第三，需要多方向并行，任务天然要求同时沿多条独立路径推进，并行处理能带来显著性能收益。

只有满足这三条中的至少一条，多智能体才有存在的必要。

接下来是架构选型。

多智能体有两大基础模式：

第一种是层级委派模式。核心结构是一个主管负责分析请求，把任务委派给专家Agent，然后汇总结果，就像公司里的老板和员工，这种模式责任链清晰。流程可控，但致命弱点是上下文管理会爆炸，所有历史信息都要经过主管，很容易上下文窗口溢出，推理质量下降，应对方法是做上下文编辑，搭建外部Memory，对工具响应做分页过滤，严格控制单次返回规模，

第二种是去中心化协作模式，没有中心指挥，多个Agent点对点通信，动态协商角色，依靠群体互动完成任务，这种模式更灵活，但通信复杂度会持续上升。而且涌现行为不可预测，Agent越多，群体互动产生的意外情况就越多，行为越难稳定复现，这里的关键是必须提前定义清晰的分工框架和问题求解方式，设定Effort Budget，并设置冲突解决机制，避免任务在Agent之间无限踢皮球。

实际生产中经常是混合架构，用多种模式组合去匹配具体的业务约束，不要迷信某一种架构，重要的是从一开始就模块化和可扩展性来设计。别把业务逻辑全部硬编码绞死在一起，今天你可能只用三个Agent，但明天可能会扩展到一个拥有几十个Agent节点的数字帝国，如果架构设计时没有预留热插拔接口，当想扩容时，只能把整个系统推倒重来。

最后，

多智能体是能力放大器，不是默认选项，他能让复杂任务性能飙升90%，但代价是系统复杂度、运营成本和调试难度的同步暴增，只有当单体真正撞上了能力天花板，并且任务价值能覆盖增量成本时，才能引入多体架构，而且必须从一开始就建立全链路可观测性。否则随时会失控。

2、解读Building multi-agent systems：when and how to use them

（中文：什么时候怎么使用多Agent ）

拆解 Claude 官方技术博客《 Building multi-agent systems：when and how to use them 》

（1）什么时候拆分多 Agent ？ when？

什么时候该使用多agent呢？下面拆解 Claude 官方技术博客。

这片文章不是在教我们如何构建多智能体，而是在教我们如何尽量不使用它，有很多真实的教训是，有些团队投入数月时间构建复杂的多智能体架构，结果发现，仅仅改进单智能体的提示词就能达到同等效果，多智能体系统，在现有的条件下，本质上是一种“代价昂贵的工程权衡”。而不是对单智能体的能力升级，是在用 “成本” 换取 “能力” 。

为什么这么说：下面是一个举例！

想象一下，你在经营一家小餐馆。原本你一个人就是主厨，切菜/炒菜/摆盘样样精通，这就是单体agent，虽然忙一点，但你心里非常有数，所有信息都在你脑子里，没有任何沟通成本，现在，你听说多智能体很火，于是你招了3个助手，一个专门切菜，一个专门炒菜，一个专门摆盘。看起来很豪华，对吧。但现实是，你需要花大量的时间去协调他们，那个洋葱是切丁不是切丝，菜炒好了盘子怎么还没来？这就是通信开销，Claude的工程师在实战中发现，盲目上多体的代价是非常昂贵的。首先是Token成本，每个 agent 都要维护自己独立的上下文，这就像每个人都要发一份完整的 “员工手册”，消耗通常是单体的 3 到 10 倍。其次是“延迟”，多一个 agent ，就多一次网络请求，也就多了一个潜在的故障点。所以第一个原则就是，尽量先使用单 agent ，如非必要，勿增实体，除非使用多 agent 有明确的正收益。

原文总结了 3 种 “多智能体能持续跑赢单体” 的特定场景，能获取明确的正收益。第一，上下文保护，解决的是“噪音”问题；第二，并行化，解决的是“覆盖度”问题；第三，专业化分工，解决的是“能力稀释”问题。接下来，我们逐一拆解这三类情况，并且明确，他们成立的前提条件是什么。

第一类正收益场景，叫上下文保护

这个模式解决的是一个非常现实的问题：上下文污染，下面是一个例子：

这是一个客户服务的例子，假设你的 agent 需要处理一个用户的技术故障，为了搞清楚状况，他需要先去查询用户的历史订单，结果，API一下子返回了五千字的完整日志——包含每一次下单、每一个物流节点、每一条退换货记录。如果你把这几千个Token的“高噪声材料”直接塞进上下文，Agent的注意力瞬间就被冲散了，她可能本来要解决“无法登陆”的问题，结果看完日志后，开始一本正经地分析为什么上个月的快递慢了。

这一类的场景要成立，必须同时满足3个硬性条件：

条件一：字任务回产生大量的上下文内容。通常是指，单词工具调用，或一次检索操作，返回的内容动辄超过1000个Token。
条件二：这些信息大部分与主线任务无关。这些信息可能是正确的、真实的，但对当前的主线决策来说，并不相关。
条件三：这些信息在被使用前，必须先经过筛选或过滤。

这满足这3个条件的前提下，我们可以设计一个独立的子智能体，他的任务是过滤，他负责读取那5000个字的日志，然后只提取出核心结论：“订单号12345，状态：已发货。”，最后，只把几十到一两百Token量级的关键信息传递给主agent，在这里，多agent的价值，是为核心大脑保留一片净土，保护他的上下文不受污染。

第二类场景，是并行化

这里有一个常见的误解，很多人以为并行是为了“快”，但在 agent 领域，并行的核心收益，其实是“全”，比如，你需要回答一个极其复杂的研究问题，如果你只用一个 agent ，受限于上下文窗口，她只能按顺序看前几页的搜索结果，这就像一个人在图书馆找书，能翻阅的数量其实是极其有限的，在并行架构中，我们可以同时启动十个子智能体，他们相互独立，互不干扰，agent-1负责收集市场数据，agent-2 负责挖掘竞品动态，agent-3 负责查找学术论文，同时出发，分头行动，虽然总Token消耗通常会上升到3-10倍量级，但换来的是对搜索空间的“全覆盖”，这一类场景成立，也需要满足明确条件：

条件一：问题天然可以拆解为多个彼此独立的子问题，这些子问题之间不需要共享中间的推理结果，也不存在强顺序依赖。
条件二：信息空间足够大，单智能体难以覆盖。典型任务是deep-research，在这类任务中，漏掉一个重要角度，往往比慢几秒钟更不可被接受。
条件三：你能够接受明确的成本交换，并行多智能体，几乎必然带来 3-10 倍的 Token 消耗。因此，这种模式不适合对延迟极度敏感，或者对成本高度约束的场景。

第三类场景，是专业化

在一些任务中，当一个agent被赋予过多、且彼此差异很大的工具、指令或知识域时，系统的整体可靠性，反而会下降。这里面又可以细化为三种情况：

第一种是工具集专业化，当一个agent同时挂载了大量工具——尤其是当工具数量来到了 15-20 个以上，并且这些工具跨越多个不相关领域时，模型在“选对工具”这件事上的表现，往往会明显变差，在这种情况下，问题不在于模型“不会用工具”，而在于它需要花费大量上下文和注意力，去理解和区分这些选项，实践中，一个常见信号是：新增工具，不仅没有提升能力，反而会削弱他在原有任务上的表现，将工具拆分给职责明确的专业化agent，往往能显著提升工具选择的准确定性和整体稳定性。
第二种是系统提示词专业化。除了工具，系统提示词本身，也可能成为冲突源，不同任务，对agent的行为模式有着完全不同、甚至相互冲突的要求。例如，一个客户支持agent，需要保持共情、耐心和克制；而一个代码审查 agent，则需要严格、挑剔，并坚持规则优先。当同一个agent被迫在这些冲突的行为模式之间频繁切换时，输出结果往往会出现不一致，甚至在同一个任务中表现出摇摆和混乱。在这种情况下，将不同的行为模式，拆分到拥有不同系统提示词的专业化agent中，通常能带来更稳定、更可预测的结果。
第三种是领域专长专业化。有些任务本身就需要极强、且长期稳定的领域上下文。例如法律分析、医疗研究或金融合规。在这些场景中，如果试图把大量领域知识与通用能力一并塞进同一个agent，不仅会带来沉重的上下文负担，也会影响它处理其他任务时的表现。通过将这些神领域任务交给专门承载对应领域知识的agent，可以让每个agent都在自己最擅长的上下文中工作。但专业化并不是免费的，他引入了额外的路由和协调成本，因此，专业化只有在一下前提下，才会产生正收益，任务边界清晰，职责划分明确，且路由决策本身不模糊，如果连人都很难判断一个请求该交给谁，那么多智能体的专业化结构，往往会放大混乱，而不是减少错误。

在上面的讨论中，我们讨论的都是：在什么问题结构下，多智能体在长期来看是正收益的，但这仍然没有回答一个更现实的问题：你现在，是否已经被这些问题结构逼到必须使用多智能体？

接下来，我们就从问题结构，转向系统状态。可以检查一下系统是否出现了以下三个具体的“信号”：

信号一：上下文触顶。如果只是觉得记性不够用，但还没到必须隔离的地步，可以先别急的拆agent，先试试上下文工程技术，如上下文压缩。
信号二：工具过载。如果你只是觉得工具多，但职责并没有冲突。先试用“工具检索”。也就是让agent在运行时自己去搜“该用什么工具”。官方数据显示，光是这一招，就能减少85%的token消耗，同时还能提高准确率。
信号三：任务天然可并行。在任务天然独立的前提下，并行架构确实能带来显著的速度提升。

最后总结一下。构建agent系统，不要一上来就做“多agent”，默认先从单体出发，如果遇到瓶颈，先检查是否可以通过 Tool Search 或者上下文工程技术来解决。如果不能，再考虑多agent，只有当你确认你的问题符合我们刚才拆解的那三个多agent正收益的场景——上下文需要强隔离、任务需要高覆盖、或者职责发生强冲突时，再最终切换到多智能体架构。

（2）上面详细分析了 “ when ” ，下面开始 “how ”

在已经决定使用多智能体的前提下，Agent的边界到底应该怎么划分？

在真实工程中，多智能体系统失败的原因，往往是拆分边界拆错了，一个最常见、也最容易出问题的拆法，就是本能地模仿人类公司的组织结构和角色划分。

一个Agent负责产品规划，一个Agent负责写代码，一个Agent负责测试或审查。把他们串成一条看起来很清晰的流水线。从“分工”的角度看，这似乎很合理。但Claude明确指出：这种按职能、按工作类型划分Agent的方式，在多智能体系统中往往是低效的，甚至会抵消多智能体本应带来的收益。问题的根源在于：上下文在Agent之间被反复切段和传递。原文把这种架构形容为一个经典问题：“传话游戏”。在这种结构下：写测试的Agent并不知道Agent当初为什么这么写；做审查的Agent，也不了解前面已经探索过、排除过哪些方案。结果就是，Agent之间不得不反复解释背景、补充来龙去脉。Claude在一次实验中发现，在这种“以问题类型为中心”的拆分方式下，Agent之间为了协调和沟通所消耗的Token，甚至超过了真正用于完成任务的Token。

那多智能体里的“正确拆分维度”是什么？Claude在原文中给出了一个非常明确的答案：多智能体的拆分，必须以“上下文”为中心。只有当上下文可以被真正隔离时，工作才能被拆分，这句话非常关键，它意味着在设置Agent边界时，首要考虑的不是任务类型，而是这些任务是否依赖同一套上下文信息。

下面是一个正确的拆分示例：假设一个Agent负责开发某个功能X，在这种情况下，它通常也应该同时负责这个功能的设计取舍、具体实现、以及与之对应的测试逻辑。原因很简单，这些工作高度依赖同一套上下文。如果强行把他们拆给不同的Agent，就会产生大量不必要的解释和同步成本。

如何分辨一个拆分边界是“好边界”还是“坏边界”，基于“以上下文为中心”的原则，Claude在原文中给出了非常实用的判断信号。

红灯部分，这些拆分边界通常是有问题的：

第一，同一工作的连续阶段。例如同一个功能的规划、实现和测试。他们共享大量上下文，不适合拆分。
第二，紧密耦合的组件。如果两个模块需要频繁来回确定细节、同步理解，那他们本质上属于同一个上下文单元。
第三，需要持续共享状态的任务。如果多个Agent必须不断对齐，当前系统理解到哪一步，拆分只会把算力浪费在同步上。

绿灯部分，这些拆分边界通常是有效的：

第一，独立的研究路径。例如一个Agent研究亚洲市场，另一个研究欧洲市场，它们之间几乎没有共享上下文。
第二，拥有清晰接口的组件。只要接口定义明确，Agent不需要了解彼此的内部实现细节。
第三，黑盒验证任务。如果一个Agent只需要运行验证、汇报结果，而不需要理解实现过程，这类任务是可以独立拆分的。

所以说，不要为了模仿人类的组织结构去拆分Agent。按职能拆分往往会放大上下文切换和协调成本，从而抵消多智能体本应带来的收益。应该以上下文为中心去拆分agent，只有当上下文可以被真正隔离时，拆分才是有效的。理解并遵守这条“以上下文为中心”的分解原则，多智能体系统才能避免陷入传话游戏，真正发挥它应有的工程价值。

（3）Claude给的一个拆分示例

在前两部分，讲解了何时采用多Agent架构，以及Agent边界应该如何拆分。如果已经决定要买箱多Agent，那么最安全、最不容易翻车的“第一刀”，到底应该切在哪里？Claude并没有推荐哪些花哨的协作模式，而是强调了一个看起来“没那么聪明”的角色：验证Agent。

为什么验证Agent是最稳的拆分点？先看它的典型模式，这里有两个角色，一个是主Agent，它负责真正干活：写代码、生成内容。它拥有完整的上下文，理解“为什么要这么做”。另一个就是验证Agent，它完全不关心过程。它不需要理解这个结果是怎么来的，它只需要回答一个问题：结果是否满足预先定义的标准？

到这里，有一个巨大的疑问：上面说：把“测试”拆分出去是错误的“传声筒架构”，而这里又说拆分验证是最安全的，这里不是矛盾了吗？

这个问题的答案，正是多Agent设计的精髓所在。上面反对拆分的，是拆分“编写测试”；而今天我们推荐的，是拆分“执行验证”。编写测试是白盒任务，要写出好的测试代码，Agent必须理解业务逻辑，理解代码结构，理解开发者为什么要这么实现。这就需要大量的上下文。如果强行拆分，测试Agent就会变成瞎子，必须不断问开发Agent，这就掉进了传声筒陷阱。但在“执行验证”时，时黑盒任务。验证Agent不需要知道代码是怎么写的，也不需要知道这行代码为什么用 for 循环。它只需要拿到产物，对照标准，机械地执行检查。

打个比方，“写测试”就像学生写作文，必须自己构思，不能让别人替你写，这叫上下文内聚。“执行验证”就像老师判卷子。老师根本不在乎你写作时的心理活动，只看你字数够不够，有没有跑题。这种标准客观、独立的工作，最适合拆分给子Agent。

所以，验证任务天然符合“以上下文为中心”的分解原则。它是上下文最干净的一类工作。

验证Agent不仅仅能用来测代码，任何“标准明确、不需要理解过程”的工作都能交给它。

比如合规检查，主Agent写合同，验证Agent拿着“公司法务手册”去核对。他不用懂法律逻辑，只看条款在不在。

比如事实核查，主Agent写文章，验证Agent专门去搜Google，验证每一个数据的真实性。

比如格式校验，验证Agent专门检查输出的Json格式对不对。它是你系统中成本最低、但收益最高的守门员。

在验证Agent的实践中，有一个巨大的陷阱：“过早胜利问题”。Claude发现验证子Agent往往有“偷懒”的倾向。因为LLM倾向于顺从用户，想尽快结束对话。经常出现的情况是：验证者只跑了一两个最简单的测试，发现通过了，就立刻宣布“大功告成”，但这其实是假象，一旦上线，遇到复杂的边界情况，系统就会崩溃。

怎么防止Agent偷懒？官方给出了四条“防偷懒铁律”，建议直接写进系统prompt：

第一，具体标准。不要说“确保能运行”，要说“运行完整的测试套件，并报告所有失败项”。
第二，全面检查。强制要求覆盖边界情况，比如空值、超长文本。
第三，负向测试。你要指令验证者：“试着输入一些会导致失败的数据并确认系统真的报错了”，如果无论输入什么它都说“成功”，说明测试是假的。
第四，显示指令。使用强祈使句，比如：“你必须运行完所有测试才能标记为通过”。

至此，解析完毕，Claude在结尾给出了“落地检查清单”。在动手写代码前，再次检查3个问题：

第一，真的有物理限制吗？单体能解决的，坚持用单体。

第二，是按上下文拆分的吗？拆分边界是基于“知识需求”，还是盲目模仿流水线？

第三，有清晰的验证点吗？你能否定义出明确的标准，让子Agent进行黑盒验证？

总结，从单体开始；只在真实约束出现时引入多Agent，而多Agent最稳的拆分起点，是验证子Agent，而不是更复杂的思考Agent。

3、解读

三、OpenClaw人格与记忆管理系统

OpenClaw 的记忆系统设计非常独特且具有高度的工程实用性。它放弃了传统的云端数据库，转而采用**“本地 Markdown 文件 + 嵌入式 SQLite 向量库”**的混合架构。

1、基础功能

OpenClaw 的记忆系统旨在解决 LLM 上下文窗口有限和会话易失性的问题，将记忆分为“短期上下文”和“长期持久化记忆”。

双层存储架构：
- 每日流水账 (Layer 1 - Daily Logs)：存储在 ~/clawd/memory/YYYY-MM-DD.md。这是仅追加（Append-only）的每日笔记，Agent 会在这里记录当天的临时想法、任务进度和观察。
- 长期知识库 (Layer 2 - Long-term Memory)：存储在 ~/clawd/MEMORY.md。这是经过策划的持久知识，包含用户偏好、重要决策、项目核心事实等。
主动检索工具：
- memory_search：Agent 在回答关于过去决策、日期或特定事实的问题前，必须调用的工具。它执行语义搜索，返回相关片段。
- memory_get：在搜索到相关文件路径后，Agent 使用此工具读取文件的具体行内容。
显式写入：
- 没有专门的“写入记忆”工具，Agent 使用标准的文件操作工具（write, edit）直接修改上述 Markdown 文件。系统会自动监测文件变化并更新索引。

2、核心特性

OpenClaw 的设计哲学是“透明性”和“本地优先”，这使其区别于大多数封装好的 AI 产品。

Markdown 原生：
- 记忆就是普通文本文件。这意味着用户可以直接打开 IDE 编辑记忆，进行版本控制（Git），或者手动修正 Agent 的错误记忆。
混合搜索策略：
- 为了解决单一搜索的缺陷，OpenClaw 采用了 70% 向量搜索 + 30% BM25 关键词匹配 的加权策略。
- 优势：既能通过语义找到“那个数据库相关的决定”（向量优势），也能精准定位特定的 ID 或变量名（关键词优势）。
多智能体隔离：
- 不同的 Agent 拥有完全独立的 Workspace 和索引文件。默认情况下，它们无法读取彼此的记忆，实现了上下文的物理隔离。
上下文压缩与“刷盘” ：
- 当对话接近 Token 极限时，系统会触发压缩，将旧对话总结为摘要。
- 关键特性：在压缩发生前，系统会触发**“记忆刷盘” (Pre-compaction Flush)**，提示 Agent：“快要遗忘旧对话了，请将重要信息写入磁盘文件。”这防止了重要细节在压缩过程中丢失。