身边搭过大模型应用的朋友，多半都经历过这种尴尬：单个Agent在一两个简单任务里表现得像模像样，一放进真实业务就原形毕露。任务链条稍微变长，对话上下文开始互相污染；工具调用和文件读写混杂在一起，Agent经常“忘”了刚才自己在干什么；最头疼的是，任何一个环节出错，前面几轮的工作全部作废，只能从头再来。这也是我后来认真去研究OpenClaw多Agent协作的根本原因。
这篇教程不是来堆概念讲广告的，而是把我自己从零部署、角色拆分、Skill开发、并发压测到生产排障的完整过程整理出来。你会看到为什么多Agent比单Agent更适合复杂任务，OpenClaw在安装和使用里有哪些坑，以及如何用策划、执行、质检这类角色分工，把一个真实项目跑通。教程面向已经了解LLM基本概念、想动手搭Agent系统的开发者，也适合对Agent开发感兴趣但还没找到入门路径的人。
1. 多Agent协作的选型逻辑：为什么是OpenClaw
1.1 单Agent系统里我踩过的三个坑
先说单Agent。很多人一开始觉得“一个Agent灌个系统提示词，把工具都挂上去，不就行了吗？”真跑起来会发现，问题全藏在上下文里。
第一是上下文污染。当Agent既要联网搜索、又要读写本地文件、还要调用数据库接口，它每轮都得把前面所有讨论保留在窗口里。搜索到的网页内容、文件列表、中间计算结果，全搅在一条上下文里。对话轮次一多，模型注意力被无关信息稀释，开始答非所问。有一次我让它先查资料再写代码，它把搜索结果当成代码上下文，产出直接没法看。
第二是工具切换容易出错。单Agent频繁切换不同工具，状态容易混乱。上一轮还在读文件，下一轮突然要执行Shell命令，模型需要自行处理工具间的状态同步。没有明确隔离的话，文件路径、权限、环境变量很容易串。
第三是链路缺乏容错。单Agent流程里，任何一步出错，整个对话上下文都已经被污染了。你没法只回滚其中一步，只能整段重来，成本特别高。
1.2 OpenClaw与常见编排框架的核心差异
很多朋友接触过LangChain、CrewAI这类工具。LangChain的定位是Workflow Orchestration，强调用代码把节点串成管道，本质上还是一个链。CrewAI虽然引入了多Agent角色，但Agent之间的协作更多依赖预定义流程，灵活性一般。
OpenClaw更接近“多个Agent共同生活在一个环境里”的思路。它给你的不是一个串行管道，而是一个消息驱动的协作空间。每个Agent有自己的Persona（人设）、Skill（技能）、记忆和模型配置，Agent之间通过消息沟通。你定义的是“谁负责什么”和“消息怎么流转”，而不是把每个步骤硬编码成死链。
这种差异在真实项目里的体验特别明显：流程想调整时，只需要修改某个Agent的职责描述或者换发消息的对象，不需要改动整条链路的代码。多Agent的协作逻辑是从Agent对话里“涌现”出来的，框架主要负责路由、调度和工具沙盒。
1.3 先分清Agent、Skill、Harness、Persona四个核心词
OpenClaw的文档里高频出现的概念，我先用自己的理解翻译一遍：
- Harness：框架的主循环，负责接收消息、维护上下文、决定何时调用Agent、何时调用Skill。你可以理解成一个“调度中枢”。热搜里常见的“harness和agent区别”就在这：Agent是执行者，Harness是中枢神经系统。
- Agent：一个独立角色，有自己的配置、上下文窗口、模型偏好，负责完成具体的子任务。
- Skill：一个可复用的能力单元，比如“搜索网页”“读写指定目录”“调用某个API”。Skill可以被多个Agent共享。
- Persona：Agent的人设和职责描述，决定它在协作里是什么“身份”、遵守什么规则。
我习惯把Harness类比成公司的项目经理，Agent是各个岗位的员工，Skill是员工手头的工具箱，Persona是岗位说明书。多Agent协作本质上就是让不同岗位的员工在项目经理的调度下，用各自工具箱完成一件大工程。
2. 环境准备与安装：Ubuntu、macOS、Windows三条路线一次说清
2.1 前置环境：Node.js运行时与Python
OpenClaw的服务端基于Node.js生态，同时大量Skill会调用Python脚本。所以安装前需要做两件事。
先去官网下载Node.js的LTS版本；Windows用户直接去nodejs.org下载安装包，Linux用户可以用系统包管理器。装完在终端验证：
node -v npm -v版本方面，OpenClaw要求Node.js 20以上，npm跟着新版走就行。
Python方面，建议装3.10以上的版本，因为很多Agent工具链已经放弃3.8以下的老版本。Ubuntu可以用：
sudo apt update sudo apt install python3 python3-pip -y这一步很多人会忽略Python，结果跑通用型Skill的时候报ModuleNotFoundError，回头补依赖特别折腾。
2.2 Linux/macOS下的安装与启动
OpenClaw的部署方式有两种，我推荐优先用官方提供的安装脚本。官方文档首页有一段受管安装命令，复制到终端执行就行。它的作用是帮你把运行目录、默认配置、依赖全部初始化好。
如果公司环境不允许执行线上脚本，就选择手动部署：从官方仓库把代码clone到本地，在项目根目录执行：
npm install npm run build openclaw start初始化完成后，OpenClaw会在你的用户目录下生成一个配置文件夹，里面是config文件、skills目录、agents目录。以后所有自定义配置都在这个目录里改，不需要动仓库源码。
macOS用户如果遇到“无法打开，因为无法验证开发者”的提示，去系统设置的“隐私与安全性”里允许来自开发者来源的应用即可。这条能拦住一半的小白。
2.3 Windows用户：优先处理好WSL 2
Windows上跑OpenClaw，官方支持两条路：原生运行或WSL 2。我的建议是直接用WSL 2。原因是OpenClaw的大量博客、文件读写、进程管理类Skill是为Linux环境设计的，原生Windows下会遇到路径分隔符、权限模型不一致的问题。
WSL 2安装很简单，在PowerShell管理员模式下执行：
wsl --install系统会自动安装并默认打开Ubuntu。之后在Ubuntu终端里继续执行上一小节的安装命令即可。
如果你在PowerShell里看到“无法安全验证”或“WSL 2环境异常”这类提示，不要慌，先执行：
wsl --status看看输出的内核版本和默认版本是不是2。如果是WSL 1，执行wsl --set-default-version 2升级。如果wsl --install之后提示未找到内核，多半是Windows更新没装全，去系统的“可选更新”里安装“WSL内核更新包”，重启后再试一次。这个动作能解决绝大多数Windows侧安装失败的问题。
2.4 配置模型后端：云端API与本地qwen2.5-3b
OpenClaw本身不绑定某一家模型厂商，只要模型服务兼容OpenAI API格式，就能接入。我建议把模型配置写清楚，包括base_url、api_key、model字段。
如果你是轻度试用，用主流云厂商的兼容API就行。只要在配置文件里填上：
{ "llm": { "provider": "openai-compatible", "base_url": "https://your-endpoint.example.com/v1", "api_key": "sk-xxxx", "model": "your-model-name" } }如果把base_url换成你本地Ollama的地址，再指定本地模型名（比如qwen2.5-3b），OpenClaw就能跑完全本地化的推理。步骤是：先在Ollama里ollama pull qwen2.5-3b，然后把base_url配置为：
{ "base_url": "http://127.0.0.1:11434/v1" }这里有个实用细节：多Agent场景下，不同Agent可以用不同模型。策划Agent用大模型做复杂推理，执行Agent用qwen2.5-3b这种轻量模型跑重复劳动，成本能降一大截。OpenClaw支持给每个Agent单独配置LLM提供商，我就试过“大模型+小模型异构协作”，实测下来很稳。
2.5 安装完的自检：你该看到什么
启动完成后，终端会打印一个套接字地址和一组日志。别急着去看Web界面，先跑一遍系统内置的健康检查命令行：
openclaw status正常输出会列出运行中的Agent数量、加载的Skill数量、当前模型连接状态。我看到过很多人安装完直接配一堆Agent，结果模型字段填错了，所有Agent启动报错，其实这一步能提前发现问题。
首次对话测试建议走简单场景：
openclaw chat --message "先简答介绍一下你自己"如果这个命令能正常返回内容，说明安装链路、模型配置、基础对话全通了。之后再进入多Agent配置阶段。
3. 设计你的第一个多Agent协作项目：分工、路由与交接
3.1 拿“内容生产流水线”当第一个实验的场景拆解
理论讲多了没意思，我直接拿自己练过的一个场景举例：一个自动化的内容生产流水线。
需求不复杂：输入一个生活类选题，系统自动输出一篇结构完整、事实准确的短文。但这里面同时涉及搜索资料、组织结构、撰写正文、事实核对四件事，任何一件事的处理方式都不同，用单Agent会把上下文搞乱。
我把流程拆成三段：
- 策划阶段：理解用户需求，把模糊的想法拆成“主题、受众、大纲、查证点”。
- 执行阶段：根据大纲搜索可信资料，组织语言写成初稿。
- 质检阶段：检查事实错误、结构缺失、语病，并输出修改意见或直接修正。
这个拆法几乎是所有多Agent项目的通用模板：一个角色负责“想清楚”，一个角色负责“做出来”，一个角色负责“检查验收”。就算你后期切换到别的业务，这个骨架也能复用。
3.2 Persona的定义：三个角色的职责边界
下面是我为三个Agent写的Persona摘要，你可以直接抄：
- planner_agent：负责用户意图理解和任务拆解。它不写正文，也不调用搜索工具，只产出大纲和任务清单。职责边界要明确：如果它试图碰正文内容，说明Persona定义失败。
- writer_agent：负责把大纲转成正文。它要调用搜索工具查证素材，但不需要做深度决策，只负责把资料组织得通顺、清楚。
- reviewer_agent：负责质检。它把所有输出看作待审稿件，逐段检查事实错误、跑题和格式问题。它有权把任务打回给writer_agent，但自己不改稿。
我踩过的一个重要教训：Persona写得太宽泛，Agent就会“越权”。一开始我让writer_agent“负责输出好内容”，结果它顺手改了自己和策划的分工，流程彻底乱套。后来把“做什么”和“不做什么”同时写清楚，协作就稳定了。
3.3 Agent之间的消息路由与任务交接
多Agent协作最关键的一段是任务交接。OpenClaw的消息路由支持定向发送和广播，实际操作中我几乎全用定向路由。
决策逻辑是这样：
- planner_agent产出大纲后，把消息发给writer_agent，而不是广播给所有人，避免无关Agent收到后产生额外动作。
- writer_agent写完后，把稿件发送给reviewer_agent。
- reviewer_agent如果认为不合格，把修改意见定向返回writer_agent，同时附上“本次初审未通过”的标记，方便系统记录。
消息里还要带上任务ID和上下文摘要。这相当于给每个任务做了一次“状态打包”。接手方看到的不只是一段零散文字，而是“第几轮、谁处理的、现在要求是什么、前序结论是什么”。这种结构的任务消息，能让整个协作闭环可追踪、可回滚。
3.4 最小配置示例与跑通检查
下面是一个简化后的配置骨架，字段名以你当前版本的官方文档模板为准，但结构逻辑是通用的：
agents: - name: planner_agent role: "策划拆解，只输出大纲和任务清单" llm: model: "your-large-model" - name: writer_agent role: "根据大纲搜索资料并撰写正文" skills: ["web_search", "file_write"] llm: model: "your-large-model" - name: reviewer_agent role: "质检稿件，输出修改意见或修正" skills: ["file_read"] llm: model: "local-qwen2.5-3b"配置完成后，从入口给一个简单任务：“写一篇500字的城市公园散步指南。”然后观察日志里的消息流转路径。如果看到planner_agent -> writer_agent -> reviewer_agent的顺序，链路已经通了。
第一次跑通时，先别急着追求任务质量，重点是确认路由不乱、消息不丢、每个Agent都收到了正确格式的输入。链路稳定以后再谈内容优化。
4. Skill实战：从内置技能到自定义技能开发
4.1 Skill到底是个什么东西，为什么是协作的“通货”
Skill是OpenClaw里Agent“动手能力”的载体。Agent本质上是只会思考的模型，没有Skill它就只能输出文字，不能执行任何外部操作。你给它挂上“读取文件”的Skill，它才能读写磁盘；挂上“网页搜索”的Skill，它才能联网取数。
在多Agent协作里，Skill的重要性和Agent同等，甚至更高。因为Agent之间传递的不仅仅是消息，还包括谁“有权限”、“有能力”去执行某类操作。Skill相当于通行证。你不想让质检Agent乱改文件，就不给它挂写文件的Skill，它的能力边界立刻清晰了。
这也回应了很多人的疑问：为什么OpenClaw框架的核心不是Prompt，而是Skill系统。Prompt决定Agent“思考什么”，Skill决定Agent“能做什么”，后者才是可约束、可审计的。
4.2 内置Skill盘点与选择建议
OpenClaw自带一批高频Skill，我用下来最实用的几个：
- web_search：联网搜索并返回结构化结果。适合需要事实查证的Agent。
- web_fetch：抓取具体网页内容，配合搜索使用。
- file_read / file_write：读写本地文件。注意控制Agent能访问的目录范围，别让它扫全盘。
- command_exec：执行系统命令。这个Skill是双刃剑，权限配置不好就是灾难。
- vault_store：操作知识库目录，适合做长期记忆和笔记沉淀。
选择Skill有两个经验：第一，按“最小必要权限”挂载，每个Agent只挂自己业务必需的Skill，不要图省事全挂一遍；第二，跨Agent协作时，同一个Skill的调用参数要保持一致，否则下游Agent拿到的结果格式五花八门，解析必炸。
4.3 三步做出一个能被OpenClaw装载的自定义Skill
自定义Skill没有想象中那么复杂。
第一步，在技能目录下新建一个文件夹，作为技能名。比如要做“给文章批量打标签”的Skill，就建一个bulk_tagging文件夹。
第二步，在里面放两个必要文件：
- 一个
SKILL.md，用来写技能说明、参数定义、依赖环境。OpenClaw会读取这个文件来决定何时调用该技能。 - 一个可执行的脚本，可以是Python或Shell。脚本入口接收标准参数，做完处理后把结果写到标准输出。
第三步，在配置里给目标Agent挂上这个Skill。重启服务或热加载后，测试调用：
openclaw skill run bulk_tagging --input "测试文本"我把一个内部文档归类逻辑封装成Skill之后，三个Agent同时复用它，效果很好。关键是Skill的输入输出必须结构化，不要搞“半成品”。
4.4 多Agent共享Skill的冲突与隔离：一次线上事故
共享Skill有一个容易被忽略的问题：并发调用时状态互相污染。
我遇到过的事故是这样的：writer_agent在调用一个“写临时文件”的Skill时，reviewer_agent也在同一时刻调用同一个Skill，两个Agent操作了同一个临时文件路径，结果一个覆盖了另一个的中间结果，整个任务链崩了。
现在我的习惯是：路径参数必须由调用方显式传入，不允许Skill内部使用固定路径；Skill内部若涉及状态，优先使用临时目录隔离；给不同Agent隔离命名空间，避免全局共用。这些规则写进Skill的文档里，后续维护者必须遵守。
5. Agent间通信、记忆与上下文管理的实战细节
5.1 定向消息和广播消息怎么选
很多初学多Agent的人容易把系统设计成“所有人喊所有人”。我在前面提到，我几乎全程用定向消息，只有两种场景会考虑广播。
一种是全局通知类事件，比如“系统升级”“任务终止”，需要所有Agent同步状态。另一种是“黑盒裁决”场景，比如评审一个方案，需要多个Agent独立给意见再汇总，这是真实的多角色并行评审。
其余场景，一律定向。原因很简单：广播消息进来以后，即便是无关Agent也会因为“消息里提到的关键词”触发部分逻辑，造成额外的上下文物化和不必要的模型调用。钱多倒无所谓，关键是上下文被污染之后，后续任务质量会明显下降。
5.2 短期记忆、长期记忆与存储落点
多Agent协作里，记忆分为两层设计。
短期记忆就是每个Agent自己维护的会话上下文，由Harness统一管理。这个上下文有窗口上限，Agent只保留当前任务相关的最近几轮消息。我的经验是，在发给下游Agent的交接消息中，把“原始需求、已完成步骤、当前结果、待办事项”这几项显式列出，这就是最有效的短期记忆传递。
长期记忆则落在外部的存储里，可以是本地文件系统，也可以是自建的向量库。OpenClaw生态里常见做法是把重要结论写入指定目录的Markdown文档，或者写入SQLite/PostgreSQL等结构化存储。我偏好在任务结束时，由planner_agent总结一份“项目复盘文档”，这个文档就是一个长期记忆单元，后续项目可以随时调用。
5.3 上下文窗口告急时的四个取舍策略
又到了新手最痛苦的部分：上下文窗口不够用。
我在实践中试过这四个方法，按推荐程度排序：
- 交接时只传摘要和关键参数，不传全文。这个策略最有效，把“全文传递”改成“摘要传递”，上下文占用量能降到原来的五分之一。
- 把长文本降级为文件引用。比如把长文章写入临时文件，消息里只带文件路径和开头摘要，下游Agent用读文件Skill取全文。
- 分阶段处理，不要让一个Agent处理所有环节。细化Agent分工，每个Agent只看自己那一段，问题自然缓解。
- 必要时切割长输入，分批处理最后汇总。适用于输入本身特别长的场景，比如一份100页财报。
这些策略配合使用，基本能应对90%以上的长任务。
5.4 追踪一个实际会话的状态流转
最后我把一次真实任务的状态流转写出来，大家对照着体会：
- 用户发送：“生成一篇关于城市公园的散步指南。”
planner_agent接收消息，产出大纲，发送给writer_agent，标记任务ID为T1。writer_agent收到T1后，调用web_search查公园资料，把结果写入临时目录，生成初稿，发送T1给reviewer_agent。reviewer_agent读取初稿，发现缺少“开放时间”信息，把T1连同修改意见返回writer_agent。writer_agent补充信息，再次发送T1给reviewer_agent。reviewer_agent确认无误，标记T1完成，把最终结果写给用户。
这个流程里有件事值得注意：每次消息都带T1标识，任何一个环节出了问题，我们都能直接定位是哪个Agent、哪一轮出的问题，整个链路完全可控。
6. 并发与稳定性：多Agent协作也得扛真实流量
6.1 并发瓶颈到底在哪里
很多人听到“AI Agent怎么扛并发”第一反应是“模型推理太慢”。模型延迟当然是瓶颈，但多Agent系统里还藏着两个更隐蔽的瓶颈：调度瓶颈和上下文读写瓶颈。
调度瓶颈指Harness在处理大量消息时，自身CPU和内存吃紧。默认配置下，Agent的调度串行执行时，慢的那一个会拖住整条链路。上下文读写瓶颈指每次写消息、读历史都涉及存储IO，高并发时磁盘IO和数据库压力可能比模型还先爆。
所以做并发优化，不是只往模型层加机器，而是要同时看调度、存储和消息队列三个层面。
6.2 队列、并发数与优先级：先把流量关进笼子
我最常用的固定配置是给OpenClaw外的入口加一个简单的消息队列。用户请求先进队列，Worker进程以可控并发数消费队列，每个任务拆成子任务后再交给不同Agent。
配置上关注三个参数：
concurrency：同时运行的Agent任务数。起步设4，压测后逐步上调。不能盲目调高，一旦超过模型端点的吞吐上限，响应时间会线性恶化。max_queue_size：最大排队长度。超出就返回“系统繁忙”，比无限排队把整个系统拖垮好。priority：按任务类型分配优先级。比如后台批处理任务优先级低，用户实时交互任务优先级高。
这套“队列+并发数+优先级”的组合，本质上是给系统一个明确的过载保护策略。没有保护机制的多Agent系统，高并发到来时崩得会比单Agent更快，因为多点并发执行，失败面更大。
6.3 超时、重试与错误隔离的配置经验
我习惯给每类任务配置三级超时：
- 单步Agent处理超时。默认90秒，简单查询类任务给30秒。
- 整个任务链路超时。默认10分钟，超过就终止并标记为失败。
- 重试策略。只在“瞬时故障”上重试，比如网络抖动、端点返回5xx、超时；对“确定性的逻辑错误”不重试，直接进入失败流程。
错误隔离是我特别想强调的。多Agent环境里，一个Agent的崩溃不应该拖垮整个Harness。OpenClaw的异常处理能力在于Agent级异常隔离，但我还是会额外做一层：在任务编排层用“互不依赖的Agent并行”“关键路径Agent串行”的方式，避免大面积故障。一个Agent挂了，其他Agent继续跑，任务状态记录在案，等它恢复后处理遗留部分。
经验是：宁可让单个任务失败率上升一点，也要保证系统整体不崩。
6.4 没有日志就没有多Agent调试
多Agent系统的调试难度，比单Agent大了不止一个数量级。Single-agent调试看对话记录即可；多Agent环境里，你要同时看到消息路由、每个Agent的输入输出、Skill调用状态、链路时长。
我的日志习惯是：始终开启结构化日志，把task_id、agent_name、event_type、message_digest、timestamp全记下来；访问Web管理界面时，按task_id筛选全部消息，看消息是从哪个Agent流到哪个Agent。排查慢任务时，重点看每段Agent耗时和各段排队时间。
有一次我定位一个“任务卡住不结束”的问题，就是通过日志发现消息发给了错误的Agent，对方缺失处理逻辑，造成环形等待。没有日志，这种问题只能靠猜，浪费一下午。
7. 踩坑排障实录：我处理过的安装与运行链路问题
7.1 “无法安全验证”与WSL 2环境异常的处理
前面简单提过这个问题，但值得单独说透。Windows用户在PowerShell跑安装脚本，最常出现的提示是“无法安全验证”或“无法加载文件”。这个问题的本质不是安全策略出问题，而是脚本来源没被系统信任。
第一步，先确认WSL状态：
wsl --status确认默认版本确实是2。如果显示为1，执行：
wsl --set-default-version 2如果卡在这一步，去Windows设置搜索“启用或关闭Windows功能”，确认勾选“适用于Linux的Windows子系统”和“虚拟机平台”，重启后再试。
环境正常后，处理脚本信任问题。PowerShell默认执行策略是Restricted，连本地脚本都会拒。正确操作是给当前用户放开执行权限，而不是全局禁掉安全机制：
Set-ExecutionPolicy -Scope CurrentUser RemoteSigned这条命令允许本地脚本和受信任来源的远程脚本运行。执行完再跑安装命令，基本就通了。
我的建议是，Windows部署统一走WSL 2路线，原生运行的路虽然能通，但后续Skill兼容性问题会让你后悔。
7.2 Agent Sandbox执行终止与依赖缺失
热搜词里有“agent execution terminated due to error.”这条，我得说两句。出现这个错误，90%是Skill执行环境里缺少依赖。
特点是：启动、对话都正常，但某个Skill一执行就崩，错误日志里没有任何堆栈信息，只给一句execution terminated。原因通常是Skill依赖的Python包没安装，或者系统命令不存在。
排查思路很简单：找到报错Skill对应的脚本，直接在Shell里手跑一次，看真实报错是什么。比如：
cd /path/to/skill python3 script.py --input "test"手动跑通了，再回到OpenClaw里重试。如果手动跑也报错，把对应依赖装进Skill的requirements文件里，或写入SKILL.md的依赖说明。这个坑在Windows原生运行尤甚，因为部分系统命令在Windows下不存在或行为不同，也是我强烈建议WSL 2的原因。
7.3 模型端点的连接、鉴权与超时
排障时，模型相关报错几乎全部指向三个地方：
- base_url配错。本地Ollama的地址是
http://127.0.0.1:11434/v1，云厂商的地址各不相同，复制时容易多一个/或少一个/v1，直接导致404或连接失败。 - api_key填错或过期。这个好检查，但多人协作时经常把测试环境的key带到生产配置里，导致鉴权失败。我建议配置统一走环境变量，不写死进配置文件。
- 网络不可达。本地模型要确认服务进程在跑；云端端点要确认网络能访问，防火墙有没有拦443端口。
还有一个经验是超时配置。本地小模型推理慢，如果默认超时只有几十秒，大任务必超时。我把本地模型请求的超时调到120秒，云端大模型调到90秒，实测稳定很多。
7.4 端口占用、内存与磁盘暴涨
OpenClaw运行久了，会遇到两类资源问题。
端口占用最典型。默认端口被占用时，实例起不来或行为怪异。先用：
lsof -i :端口号查占用进程，释放端口或改配置。检查所有监听端口时用netstat -tulpn，一次性看清。
内存和磁盘问题更隐蔽。每个Agent的长期记忆、日志文件、临时文件都会累积。我见过一个实例跑了两个月，日志目录占了十几个GB，磁盘满后整个服务开始反复崩溃。现在的维护习惯是：日志按天切割、保留7天；临时目录定期清理；长期记忆只保留关键结论，不保留原始消息全量。多Agent系统不是养宠物，是要定期体检的生产系统。
8. 从演示到生产：权限、持久化与生态扩展
8.1 把Agent的权限关进笼子
Agent有工具权限，就等于多了很多可被利用的攻击面。我在生产环境的安全策略只有一句话：最小权限原则。
具体来说：
- 每个Agent只挂完成任务必需的Skill，不相关的全部不给。
- 对输入做隔离。来自外部的用户输入，先经过一个专门的过滤Agent清洗，再进入主流程。恶意提示词是最常见的攻击方式，Home Agent尤其要注意。
- 敏感操作加审批。涉及删除文件、发送消息、执行系统命令，必须经过人工确认。OpenClaw支持在参数列表里加“人工审批”选项，我全部打开了。
- 密钥管理用环境变量，不写配置文件。这个习惯再强调一次不为过。
8.2 状态持久化与异常恢复
多Agent系统重启后，最怕的是所有任务状态全部丢失。
我的做法是，把任务状态和队列信息落到磁盘或数据库里。配置里开启持久化，把已完成的Agent消息、任务状态、队列内容存下来。重启后Harness会读取持久化状态，继续处理未完成的任务。
生产级建议：数据库放在独立的服务里，跟OpenClaw本体解耦。这样即使OpenClaw实例整个崩溃，任务数据也不会丢。恢复后的任务流里，Agent会通过“任务状态摘要”快速回到之前进度，而不是从零开始。
8.3 三个值得尝试的扩展方向
分享三个我已经跑通的扩展方向，你可以按兴趣选。
- OBSIDIAN知识库助理：把Obsidian的Vault目录暴露给一个Agent，让它读写作。我的配置是，这个Agent的file_read和file_write限定在Vault目录内，再挂一个长期记忆Skill。效果：直接对话就能查笔记、写日记、整理周报，比手动输入效率高很多。
- 定时任务管线：利用任务队列，每天定时触发一个Agent链，自动抓取信息、整理摘要、发送日报。这个方向对后台运维特别友好。
- 本地模型离线工作区：把全部Agent指向本地模型端点，做一个完全离线的小型协作系统。虽然推理质量比云端大模型弱，但胜在数据不出内网、无延迟波动。配合qwen2.5-3b这类轻量模型，跑一些结构化、重复性任务足够了。
8.4 我坚持用OpenClaw做多Agent协作的个人理由
写了这么多，最后说点主观的。
我见过太多项目在“Agent框架选型”上空转。LangChain的链式编排适合确定性流程，但一旦任务形态不确定，代码复杂度会失控。CrewAI的预定义流程灵活度高，但底层抽象还是围绕“角色+任务”，缺少Harness这种中枢调度设计。OpenClaw给人最大的感觉是“松”：Agent之间通过消息协作，Skill是独立单元，Persona可以随时调，不用为了一次小的流程变化去折腾一整套代码。
对我这种一个人要维护多个自动化流程的开发者来说，这种“松”至关重要。它的学习曲线不算平坦，安装也一堆小坑，但一旦架构跑顺，后续扩展基本都是加配置、加Skill的事，很少有推翻重来的时候。
如果你也想做多Agent协作，我的最后一条建议是：不要一开始就追求“什么都自动化”。先跑通一个最小链路，观察消息怎么流转，再逐步加Agent、加Skill。多Agent系统复杂度是线性增长的，但Debug难度是指数级的。把基本功打牢，后面的路会顺畅很多。
