OpenClaw 多 Agent 协作系统实践报告

1. 引言

作为一名量子化学研究者，我的日常工作包括算法开发、计算模拟和论文写作。与许多同行一样，我发现自己每天都在几种任务之间频繁切换：编写代码实现新的计算方案、查阅最新文献追踪领域进展、指导学生完成课程作业，以及处理各种琐碎的办公事务。

早期接触过对话式 AI 时，我对它的期望很高。确实，它能回答问题、生成代码片段、甚至帮忙润色文字。但很快我发现，每次开始新的任务时，我都需要重新向它解释背景。每次对话像是一次新的邂逅，AI 没有记忆，我无法建立连续的协作关系。

这种体验让我思考：对话式 AI 的局限在哪里？真正能融入工作流的 AI 应该是什么样子？

我开始尝试引入 Agent 的概念。这不是简单的功能叠加，而是从”会回答问题的助手”到”有专业分工的协作系统”的认知转变。一周多以来，我逐步搭建起包括代码开发、教学辅助、论文监测和联网搜索在内的多个 Agent，它们各自负责特定领域，通过 Leonard 这个主 Agent 来协调工作。

这一周的实际感受可以总结为一句话：不是 AI 变得更聪明了，而是系统变得更有序了。

如果你也是研究者或教育工作者，也在考虑是否要搭建类似的 AI 协作系统，我希望这篇分享能为你提供真实的参考。

首先，报告会帮助你判断 AI Agent 是否适合你的工作场景。我会详细描述几个我实际在用的场景：教学辅助、论文监测、代码开发——不是展示能力清单，而是告诉你这些工具在实际中是如何使用的，什么情况下有用，什么情况下显得多余。

其次，如果你对技术细节感兴趣，报告会介绍搭建一个多 Agent 系统大致需要什么。但请注意，我不会深入技术实现或架构设计，而是聚焦在你需要关注的问题上：模型配置、网络访问、数据备份、记忆管理等实际挑战。

最重要的是，报告记录了这段时间的真实使用体验——哪些功能真正帮到了我、哪些还需要改进、什么心态最重要。这些经验能帮你避免一些不必要的误区，更理性地评估是否值得投入这个方向。

最后要说明的是，这份报告没有暴露系统的全部设计细节。有些架构考虑是未来的计划，目前还在实现中的功能也没有展开。我所分享的，都是已经落地并在日常工作中使用的部分——毕竟，对实际工作最有价值的从来不是理论完美的设计，而是真正解决问题的工具。

2. OpenClaw 是什么

OpenClaw 是一个支持多 Agent 协作的本地化 AI 系统框架。它允许你创建多个具有特定职责的助手（Agent），通过一个主 Agent 来协调它们的工作，同时提供记忆管理、定时任务、跨设备访问等支撑功能。

一个典型的 OpenClaw 系统中，有几个核心概念需要理解：

Agent 是系统的基本单元，每个 Agent 都像一个特定领域的专家。它有自己清晰的职责边界——知道什么能做什么不能做，有自己的记忆和工作空间。比如代码开发交给专门的 Agent，教学任务交给另一个 Agent，它们各司其职。

Skill 是一种能力定义文件，描述一个 Agent 或者一组工具能完成什么任务。它可以被多个 Agent 复用，也可以专属于某个 Agent。好的 Skill 设计应该模块化、可组合，而不是把所有功能都硬编码进 Agent 里。

Memory 让 Agent 具备了连续性。通过定期记录日常工作和长期记忆，Agent 在每次启动时都能了解到之前的上下文：之前讨论过什么方案，遇到什么问题，用户的偏好是什么。没有记忆，AI 永远从零开始；有记忆，它才能真正积累经验。

Cron 是定时任务机制。它可以自动执行某些工作，比如每天的论文监测简报、定期的数据备份等。这让你可以放手让 AI 完成重复性、周期性的任务。

Session 是一个会话机制支持多 Agent 并行运行。你可以同时与多个 Agent 交互，它们在不同的”房间”里工作互不干扰，而主 Agent 负责整合它们的输出并给用户清晰的反馈。

当时我在考虑搭建自己的 AI 系统时，有几个核心需求：

首先是本地部署和数据隐私。我处理过一些未公开的科研数据和学生作业信息，这些数据不适合传到第三方 API。OpenClaw 支持完全本地运行，所有配置、记忆、会话历史都保存在本地机器上。

其次是多模型支持。不同任务适合不同的模型——代码生成用 Claude，快速问答用轻量级模型，联网搜索用其他模型。OpenClaw 允许我在各种模型之间切换，既可以根据任务效果选择最合适的，也可以控制成本。

最后是多通道通信的支持。我希望能在不同设备上使用这个系统：在办公室用飞书，在家里用 QQ，有时还需要网页端访问。OpenClaw 同时支持这些渠道，而且通过 Gateway 机制，局域网内的其他设备也能通过 HTTPS 安全访问整个系统。

实际使用下来，这些设计确实带来了便利。特别是本地部署这一点，从一开始就避免了数据隐私的顾虑——我可以直接编辑配置文件、查看记忆内容、备份整个系统，没有黑箱操作。

3. 我的 Agent 体系

一开始我也曾想构建一个”全能助手”：让它既能写代码，又能讲电动力学，还能查论文、联网搜索。但很快我就意识到这是个错误的设计思路。

首先，职责边界模糊。当一个任务出现时，我不确定它会在内部如何处理——是直接回答还是调用某个工具？如果它回答错了，我很难知道是哪个环节出了问题。其次，专业度难以保证。让一个 Agent 承担太多职责，意味着它必须在短时间内切换不同领域的思维方式，这显然不如专门训练或配置过的专家可靠。

因此，我现在的原则是：每个 Agent 专注于一个明确的专业领域。代码开发有专门的 Agent，电动力学教学有专门的 Agent，联网搜索也是独立的 Agent。这个原则带来了实际收益：

· 问题排查更简单：如果代码生成了错误的输出，我知道这是 Claude Code Agent 的问题；如果是教学回答不准确，问题是出在 Maxwell Agent。

· 配置和维护独立：每个 Agent 可以有自己的配置文件、记忆内容、工具集合，互不干扰。

· 效果更可预测：因为边界清晰，我对每个 Agent 的能力范围有了更明确的认知。

目前我的系统中活跃着以下 Agent：

这些 Agent 不是并列关系，而是一个有层级的协作体系。Leonard 作为主 Agent 负责接收用户请求，判断任务类型，然后启动相应的子 Agent。子 Agent 完成任务后，会将结果返回给 Leonard 进行整合输出。

用一个真实例子说明整个流程：

某天我需要为电动力学课程准备一节关于”高斯定理应用”的讲座材料。这个任务可以分解为几个子问题：

1. “我想讲解高斯定理的应用场景，需要概念解释和物理直觉”

2. “还需要一个实际例题，最好是电磁场中的具体例子”

3. “最后生成三道练习题给学生做”

当我在 Leonard 处发起这个请求时，Leonard 识别出这是 Maxwell 的职责范围，将任务描述传递过去。Maxwell 自动处理概念解释、例题生成和习题设计，最终输出一份连贯的教学材料，由 Leonard 返回到我的对话框中。

整个过程我只需要用一句话描述需求，具体的执行由专业的 Agent 来完成。

4. 使用体验

在科研工作中，写代码是家常便饭。有时候是为了验证一个理论想法写个小脚本，有时候是给教学演示准备一个可视化程序，还有的时候是快速原型开发。这类任务的共同特点是：需求明确、结构清晰，但需要花时间敲代码。

Claude Code Agent 的定位很明确：它是专门负责代码开发任务的子 Agent。它通过 ACP（Agent Client Protocol）集成 Claude Sonnet 4 模型，能够理解项目上下文，读取相关代码文件，生成符合项目规范的代码，并在遇到错误时分析问题并修复。

一个具体例子：洛伦兹吸引子可视化

有一次我需要一个洛伦兹吸引子的可视化程序用于教学演示。我给 Claude Code 的指令是：“用 Python 实现洛伦兹吸引子的数值模拟，使用 scipy 的 odeint 求解微分方程，用 matplotlib 绘制三维轨迹图，参数取经典值 sigma=10, rho=28, beta=8/3。”

几分钟内，Claude Code 就完成了整个程序： - 实现了洛伦兹方程组 - 使用 scipy.integrate.odeint 进行数值积分 - 用 matplotlib 绘制了三维相空间轨迹 - 生成了多个初始条件下的轨迹对比图

我对代码做了一些微调（主要是调整了绘图风格和颜色方案），直接就能用。如果从头写这个程序，大概需要 30-40 分钟，而现在只需要几分钟。

这种协作模式的实际感受：

Claude Code 不是替代我写代码，而是帮我处理那些结构清晰但重复性高的开发任务。比如数据处理脚本、可视化程序、测试用例等。我可以把精力放在更有创造性的工作上。

另一个好处是，因为 Claude Code 有自己的工作空间，它可以同时处理多个项目。当我一边在教学演示上需要调整代码，一边在科研项目中需要写测试脚本时，两个任务可以并行进行，互不干扰。

作为研究者，我也承担部分教学工作。电动力学是物理专业的基础课程，学生往往面临两大难点：数学推导复杂，物理直觉薄弱。传统的教学方式中，我需要花大量时间准备例题和习题，确保难度适合学生水平。

我搭建了一个专门的教学 Agent（代号 Maxwell），用于辅助电动力学课程的教学工作。

它能做什么： - 根据主题生成完整的教学材料：概念解释、物理直觉、数学推导、例题和练习题 - 根据学生水平动态调整难度 - 当学生在练习中遇到困难时，自动降低难度或回到例题讲解阶段

实际效果：

最明显的感受是节省了材料准备时间。过去我需要 1-2 小时准备的习题和例题，现在能在几分钟内生成一份结构完整的初稿。当然，最终的内容审核仍然需要我来把控，但它确实大大减少了重复劳动。

更有意思的是它还支持学生端的习题练习。当学生在练习中连续出错时，系统不会简单地让他重做同一道题，而是会回退到例题讲解阶段重新梳理概念，然后再回到练习。这种动态调整是传统静态作业难以实现的。

改进过程：

最初的设计比较死板，按固定流程推进教学环节。但在实际测试中发现，学生的错误类型千差万别：有的是公式用错，有的是概念混淆，还有的只是粗心。单一的处理方式无法覆盖所有情况。经过迭代，系统逐步增加了对学生状态的更细粒度追踪，以及更灵活的补救路径。

这个改进过程让我意识到：AI 辅助教学不是一个静态工具，而是一个需要根据实际使用反馈持续迭代的系统。

我的研究方向涉及量子化学和计算量子力学，领域的文献更新速度快到令人咋舌。每天需要浏览 arXiv 上的大量预印本，这本身就是一种重复劳动——大部分论文与我当前的研究课题并无直接关联。

早先我尝试过手动浏览各期刊的目录，但很快发现这种方式不可持续：一天只有 24 小时，而文献增长的速度远超我的阅读能力。Scholar Agent 的出现解决的就是这个具体的痛点：自动化筛选、去重、生成摘要简报。

Scholar 的工作方式：

Scholar Agent 是一个独立运行的子 Agent，工作在后台。它每天固定时间启动（通过 cron 定时任务），执行以下操作： - 监测指定领域：arXiv 的 physics.chem-ph（计算化学）和 quant-ph（量子物理）板块，以及 JCP、JCTC、PCCP 等几本期刊的最新论文 - 过滤匹配：基于关键词和主题分类，筛选出与我研究领域相关的论文 - 去重与摘要：对相似或重复的预印本进行聚合，生成简洁的摘要和核心贡献说明 - 推送报告：通过飞书（Lark）将日报发送给我，包含标题、链接、摘要以及相关性评分

实际体验：

每天早晨醒来，我会收到一份 20-30 篇论文的简报，其中大部分是我需要关注的。这种体验有几个好处：

1. 信息获取效率提升：过去可能花 1-2 小时浏览目录，现在 5 分钟就能知道哪些论文值得深入阅读。

2. 降低遗漏率：有些论文虽然标题不直观，但内容与方法论相关（如某个计算方法被应用在新的分子体系）。Scholar 的摘要和标签系统帮助我不错过这类”边缘但重要”的研究。

3. 持续学习触发点：简报中的某些论文会引发我的好奇心或思考，成为后续研究的起点。比如上周的一篇关于溶剂化模型优化的文章，让我联想到当前研究中的一个瓶颈问题。

重要的是，Scholar Agent 的推送方式非常克制——它不会在我休息时打扰，也不会把信息轰炸当成职责完成。这份日报是我一天工作的”背景噪音”，而不是打断我的工具。

我并没有在这里展开具体脚本如何实现（比如如何解析 HTML、如何调用 LLM 生成摘要、如何通过飞书 API 推送等），因为这些对实际用户来说属于工程细节而非设计要点。但有一点值得提：整个过程不需要我手动干预，Scholar Agent 的内存状态会记录最近处理过的论文 ID 和标签，确保不重复推送。

如果你有自己的研究方向，可以考虑类似的自动化监测方案——核心不是完美覆盖所有文献，而是精准识别那部分对你有价值的信息。

早期使用时，我发现对话式 AI 在回答实时信息问题时常常出错——它要么编造一个不存在的新闻事件，要么引用过时的数据。而对我来说，这类问题并不少见：“今天上海的天气如何？”、“某篇论文的作者单位是什么？”、某个会议的最新动态等。

为什么做成独立 Agent：

最初我考虑过创建一个”联网搜索 Skill”——即所有 Agent 都可以调用的共享能力。但很快就放弃了这个想法，转而将其作为独立子 Agent（代号 Hermes）：

1. 职责单一性：独立的 Agent 意味着它可以专注于搜索策略的优化，比如如何处理复杂查询、如何整合多个来源的信息。

2. 错误隔离：如果联网搜索功能出现问题，不会影响到其他 Agent 的工作流程。

3. 成本控制：使用轻量级模型处理搜索任务，避免消耗昂贵的主模型 Token。

使用方式：

当需要实时信息时，我通过命令 /hermes <搜索词>直接发起请求。例如：“上海今天的天气和上海未来一周的天气预报”、“量子计算在药物设计中的应用最近有哪些进展”等。

Hermes 返回的结果通常是结构化的摘要，包括几个关键来源的信息和链接。对于新闻类查询，它还会标注信息来源的可靠性和时效性。

实际体验：

使用频率不算高（一天几次），但在关键时刻确实有用。某个下午我需要在小组讨论中引用某篇最近的论文方法，但文章不在我的文献库中。通过 Hermes 搜索作者主页和 arXiv 记录，我快速确认了论文的细节和相关链接。

Hermes 的局限也显而易见：搜索结果不精确控制、无法返回原始链接列表、对深网页内容的提取能力有限。但这在当前阶段是合理的权衡——如果追求完美支持所有可能的搜索需求，系统会变得非常复杂，维护成本也会剧增。

5. 基础设施搭建

接入多个 LLM 提供商是我在搭建初期就考虑的问题。不同任务适合不同的模型——有些需要高质量输出（如代码生成、文本写作），但消耗 Token 较多；有些则可以用轻量级模型快速响应。

通过 OpenClaw，我接入了以下几个/providers： - 智谱（Z.ai）：glm-4-flash（快速搜索）、glm-edge-plus（中等复杂度任务）、glm-5-turbo（高质量输出） - Ollama：本地部署的 qwen3.5 模型（数据隐私场景） - 其他 API 提供商：根据需要接入不同模型

实际操作中，在 OpenClaw 配置里添加新模型需要完成两个步骤：先在 openclaw.json 的 models.providers.zai.models 数组中添加模型参数；然后在 agents.defaults.models 中为子 Agent 设置默认使用的模型。重启 Gateway 后，所有 Agent 都能使用新注册的模型了。

根据任务复杂度选择模型是一个持续优化的过程： - 联网搜索、简单查询：glm-4-flash（便宜、快速） - 代码生成、复杂推理：claude sonnet 4（通过 OpenClaw 调用外部 API） - 数据隐私敏感的任务：本地 Ollama 模型

我粗略统计过，一个中等长度的对话大概消耗 Token：输入 10k tokens、输出 2-3k tokens。使用智谱模型的计费是每千 token 几分钱，整体成本在可控范围内。

我希望能在任何设备上通过 HTTPS 安全访问 OpenClaw Dashboard。这需要通过反向代理来实现。

使用 Caddy 作为反向代理的几个要点： 1. 自签名证书：采用 tls internal自动生成本地证书，在浏览器接受一次后就不再提示安全性问题。 2. WebSocket 支持：Caddy 默认支持 WebSocket 反向代理，无需额外配置。OpenClaw Dashboard 使用的 websocket 连接可以正常通信。 3. 设备配对机制：新设备访问 Dashboard 前需要先完成设备配对（在本地机器上批准该设备的访问权限）。

启动 Caddy 后，我可以通过 https://openclaw.bsuooffice.ai 在任何有权限的设备上访问 Dashboard。

配置和记忆文件是我整个系统的基石。通过 Git + NAS 的自动化备份机制，确保不会因为本地故障导致数据丢失。

具体方案： 1. 远程仓库：使用群晖 NAS 作为 Git remote（nas:/home/user/work/back/bsuoclaw.git）。这个存储位于局域网内，速度快且安全性高。 2. 定时任务：通过 cron 每天凌晨 3:00 执行一次备份。 3. 手动触发：随时可以用相同命令进行手动备份。

一个需要特别注意的问题是：我的群晖 NAS SSH 服务可以支持 RSA 密钥类型，ed25519 类型的密钥无法使用。需要使用 ssh-keygen -t rsa -b 4096生成合适的密钥文件，并将公钥复制到 NAS 上实现免密登录。

同时接入飞书和 QQ 让我可以在不同场景下使用这个系统：工作时用飞书收到推送报告，在家时可以通过 QQ 与 Agent 对话。OpenClaw 的消息路由机制确保了消息分散到正确的 Agent、跨通道的会话保持、以及统一输出格式。

6. 记忆管理：让 AI 有连续性

最初的版本中，我没有给 Agent 设置长期记忆。每次开始新的对话时，AI 都是一张白纸——它不知道我之前讨论过什么方案、遇到过什么问题、用户的偏好是什么。

这导致每次对话都需要重复背景信息：“上次那个问题我们讨论了三种方法，你推荐第二种是因为…”

AI 没有记忆，就无法积累经验和上下文。

经过一段时间的使用，我建立了一套分层的记忆管理方式：

1. 长期记忆（MEMORY.md） 这个文件包含了高价值的、可复用的信息：用户画像（我是 Wolfbing，量子化学研究者）、Agent 注册表（有哪些 Agent、职责是什么、如何调用)、系统设计偏好（委派原则、输出规范）、技能清单等。这些内容会在每次 Agent 启动时加载，让它快速了解当前的协作环境和历史决策。

2. 每日记录（Daily Notes） 在 memory/YYYY-MM-DD.md文件中，我记录当天实际发生的工作：发生了什么任务、调用了哪些 Agent、使用了什么方法、遇到了什么问题。这些不是精炼后的信息，而是原始的工作日志。一周结束后，我会从中提取有价值的内容更新到 MEMORY.md，并删除过时的细节。

3. 想法捕捉（Ideas） 在记忆模块中，我专门留出了一个区域用于记录临时想法：可能是某个 Agent 的功能增强建议、系统架构的改进方向、或者是对某个问题的新认识。这些想法不会马上实现，但会在后续工作中被回顾和考虑。

这种分层结构既保证了记忆的完整性（所有重要信息都有地方可查），也避免了过度管理带来的维护负担。

7. 一些思考

这段时间的使用体验让我意识到：AI Agent 不是替代研究者，而是增强研究者的能力边界。它无法进行深度的科学判断、无法提出原创性的研究构想，但在以下方面确实发挥了作用：

重复性任务的自动化：如文献监测、代码模板生成、数据格式化等。这些工作本身不需要太多创造力，但占用时间；通过 Agent 处理，可以把精力集中在核心研究上。

知识调用的效率提升：当需要快速查询某个概念的应用场景、查找特定算法的最新实现时，Agent 能在几秒内给出结构化的信息摘要。这比在多个网站上逐次浏览更高效。

教学材料的辅助生成：为学生准备例题和习题是一项耗时但必要的工作。Agent 能生成初步版本，我再根据学生水平调整。这种协作模式比完全手工制作效率高得多。

代码开发的效率提升：对非核心算法部分的实现（如接口定义、配置文件、测试脚本等），Agent 可以快速生成基础代码，我再进行优化和校验。

从实际使用来看，我的判断是：对于研究者的工作场景，多 Agent 的复杂度是值得的

多 Agent 的优势包括： - 职责清晰：每个问题的输出格式更一致（代码生成总是由 Claude Code 处理，教学问答总是 Maxwell） - 维护简单：某个 Agent 需要更新时不影响其他模块 - 可扩展性强：未来可以独立添加新的专业 Agent（如数据分析 Agent、实验设计 Agent）

单 Agent 的局限： - 当任务超出其能力范围时，AI 的回答质量明显下降 - AI 在扮演多重角色时会变得不稳定（一会儿是代码开发者，一会儿是教学顾问，一会儿又去处理办公事务） - 每次对话都需要重新适应 AI 的角色切换成本较高

什么时候值得上多 Agent？我认为核心标准是：你的工作需求是否涉及多个专业领域、这些领域是否有稳定的协作模式。如果只需要解决单一类型的问题（比如仅用于写代码），那么简单的工具可能就足够了。但像我这样需要处理多样化任务的研究者，多 Agent 的价值在于提供了一个清晰的分层框架。

如果你正在考虑搭建类似系统，我想分享几点经验：

从哪里开始： 1. 先明确最痛的点是什么：是文献太多看不完？代码生成反复调试？还是教学材料准备耗时？找到一个具体的切入点比全面铺开更易成功。 2. 从最简单的 Agent 开始测试：比如论文监测 Scholar Agent，它工作相对独立，不需要太多交互，容易验证效果。 3. 渐进式扩展：当第一个 Agent 稳定运行后，再添加下一个功能模块。不要一开始就追求完整的多 Agent 体系框架。

什么心态最重要：- 不是替代工具，而是协作伙伴。我对 AI Agent 的预期是”帮我处理特定任务”,而不是”解决所有问题”。 - 接受不完美输出。Agent 生成的内容需要人工校验和改进，这本身就是价值体现——你获得了初稿，自己完成最终把关。 - 持续迭代的过程。实际使用中会发现各种设计上的不足，这些反馈反过来指导了系统的持续优化。

什么不需要过度设计： - 不要一开始就追求完美架构。保持简单、单一职责的 agent 反而更实用。 - 技术细节不必纠结于最优解。比如使用哪个 LLM 模型、具体的代码规范格式等，都是可以根据实际需求调整的。关键是整体协作模式的可用性。

我想对同行们说：这个方向值得尝试。哪怕你最初只搭建一个简单的 Agent，也能为你的工作节奏带来一些微妙的变化。随着你对系统的理解加深，自然会知道如何扩展和改进。不要追求一步到位，重要的是开始行动、保持迭代。

科研工作的核心永远是提出好问题、做出有意义的结论。AI 可以是我们的助手，帮我们处理那些繁琐的部分，让我们有更多时间专注于思考和创新。这已经足够有价值了。

附录