目录一、Skill0、创建一个SkillStep 1. 基准测试裸机状态下的无助Step 2. 核心操作物理装载 SkillStep 3. 验证测试技能觉醒技术总结为什么 Agent Skills 能引爆开发者生态1、完整的Agent Skills底层执行流程2.2.1 深度思考从“说明书”到“行动”的跨越2.2.2 流程解密四步完成技能闭环2、架构核心三层渐进式加载机制Level 1: 索引层 (Index Layer) - System InitLevel 2: 指令层 (Instruction Layer) - On DemandLevel 3: 执行层 (Runtime Layer) - Execution3、标准协议SKILL.md 解剖4、Agent Skills 系统设计关键点3.1 架构依赖运行时 (Runtime) 与 业务逻辑 (Logic) 的解耦3.2 核心机制动态上下文加载 (Dynamic Context Loading)3.3 能力分层编排层 (Orchestration) vs. 执行层 (Execution)3.4 协议对齐双向接口规范 (Interface Alignment)Skill 不是“多一个 prompt 模板”而是把 Agent 的做事方法变成可沉淀、可复用、可治理的能力模块它很可能是大模型 Agent 从“会推理”走向“会长期工作”的关键中间层。5、两种skill6、Skill vs Tool vs MCP二、MutiAgent1、Building Effective AI Agents解读2、解读Building multi-agent systemswhen and how to use them1什么时候拆分多 Agent when2上面详细分析了 “ when ” 下面开始 “how ”3Claude给的一个拆分示例3、解读三、OpenClaw人格与记忆管理系统1、基础功能2、核心特性一、Skill0、创建一个Skill在 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)顶部定义了name: get_weather。这是技能的身份证Agent 通过它在数千个技能中索引到由于。使用场景 (Trigger)明确告诉 Agent“当用户询问某个城市的天气情况时使用此技能”。这是技能的触发器。执行步骤 (SOP)这是最精彩的部分。它没有写代码而是教 Agent如何使用工具第一步从用户话里提取城市名。第二步调用fetch_url工具。注意这里直接给出了具体的 URL 构造规则https://wttr.in/{城市名}?formatj1。第三步教 Agent 如何看懂返回的 JSON 数据提取温度、湿度、风速。示例 (Few-Shot)给出了一个查询北京天气的标准对话范例。这能极大提升 Agent 执行的稳定性防止它胡乱输出。注意事项 (Constraints)比如“建议使用英文拼写城市名以提高准确性”。这是给 Agent 的兜底策略。Step 3. 验证测试技能觉醒文件放入后无需重启服务器Fufan-OpenClaw 支持热加载我们再次输入同样的指令Agent 最终回复北京天气信息。技术总结为什么 Agent Skills 能引爆开发者生态与传统的软件开发相比它展现出了极低的技术门槛和极高的灵活性。本质Agent Skills 将“编程”降维成了“写文档”。只要你逻辑清晰能把业务流程写成说明书你就能开发 Agent。这使得非技术人员产品经理、法务、运营也能成为 Agent 开发者。极简的“热插拔”架构在 OpenClaw 的架构中Skill 是完全解耦的静态文件。这意味着无需编译修改 Skill 不需要重启服务。无需环境配置只要有通用的工具如 Web Search, Python REPLSkill 就能运行不需要为每个功能单独配置 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 MessagePhase 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 端规范必须具备工具反思能力能够识别何时需要查阅文档调用read_file。必须具备标准化沙箱为 Skill 的执行提供安全的文件读写和网络访问环境。Skills 端规范能力感知SOP 的编写必须基于 Agent 已有的工具集Tools Schema。格式统一必须遵循系统预设的解析标准如 OpenClaw Standard Markdown确保 Agent 能正确提取 Intent意图和 Steps步骤。Skill 不是“多一个 prompt 模板”而是把 Agent 的做事方法变成可沉淀、可复用、可治理的能力模块它很可能是大模型 Agent 从“会推理”走向“会长期工作”的关键中间层。5、两种skill1自然语言 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连接标准协议厨房接口标准规定了“菜刀”如何连接到“手臂”上。它解决了连接问题但不解决“怎么做菜”的问题。二、MutiAgent1、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 systemswhen and how to use them 中文什么时候怎么使用多Agent 拆解 Claude 官方技术博客《 Building multi-agent systemswhen 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只有当上下文可以被真正隔离时拆分才是有效的。理解并遵守这条“以上下文为中心”的分解原则多智能体系统才能避免陷入传话游戏真正发挥它应有的工程价值。3Claude给的一个拆分示例在前两部分讲解了何时采用多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_searchAgent 在回答关于过去决策、日期或特定事实的问题前必须调用的工具。它执行语义搜索返回相关片段。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“快要遗忘旧对话了请将重要信息写入磁盘文件。”这防止了重要细节在压缩过程中丢失。