引言 如果您曾观察过一只虾在复杂环境中努力工作，却发现它的能力有限，那么您就会明白这种局限性。但是，想象一下，如果您能训练一整支由不同虾组成的团队，每个虾都有自己的专长，它们可以协同工作，完成比单只虾更复杂的任务，那会是什么样的场景？ 这就是我们从 “单只虾独斗” 到 “协作作战” 的多 Agent 系统工作系统技术 V1.0 的开发故事。 单 Agent 系统的局限性 让我告诉你我在使用 OpenClaw 进行复杂数据分析工作时遇到的几个问题： - 上下文记忆丢失：当处理长篇文章或多步推理时，我经常会在后半部分忘记前半部分，导致逻辑断裂。 - 工具集固定：内置的模板或预置插件往往无法跟上社区最新功能的发展，如果想要引入新的数据源或计算方法，必须等待官方更新。 - 单线程执行：即使任务可以并行（如同时获取多只股票的财报），单个 Agent 也只能串行处理，导致整体响应时间线性增长。 这些瓶颈在产品化需求面前尤为突出 —— 产品说明书往往需要同时融合技术数据、市场解读和用户故事，单靠一个 Agent 难以兼顾深度与广度。 技术体系 V1.0 的整体架构 在多次试错后，我终于梳理出了一套相对稳定的多 Agent 协作框架，命名为工作系统技术体系 V1.0，其核心包括以下几部分：

1. 统一网关（Gateway） 负责对外提供统一的入口（WebSocket、HTTP、飞书等），并做基本的鉴权、限流和路由。所有外部请求首先到达网关，再根据任务类型分发给后端的不同 Agent。 扩展点： - 网关不仅做简单的转发，还会根据请求的敏感程度分配不同的权限级别（例如，仅允许 Hermes Agent 访问公开网页，而禁止它直接读取本地配置文件）。 - 通过插件化的路由规则，可以快速添加新的入口方式（如企业微信、Slack）而不需要修改核心代码。
2. 编排器（Orchestrator） 这是体系的 “大脑”。它不直接执行具体任务，而是负责： - 任务解析：把用户输入的复杂需求拆解成可执行的子任务。 - 角色分配：根据子任务的特性（如需要长记忆、需要快速响应、需要访问私有数据）分配给最合适的 Agent。 - 结果汇总：收集各 Agent 的返回结果，进行必要的合成、过滤和格式化后返回给用户。 编排器采用轻量级的 Python 脚本实现，内部使用 Redis 作为消息中介，实现任务发布 / 订阅解耦。 扩展点： - 编排器内置了工作流模板库，常见的任务类型（如 “因子筛选报告”、“回测结果解读”）可以直接套用预定义的步骤，大幅减少手动配置。 - 通过插件机制，可以在不改动核心编排器的情况下加入新的角色分配策略（例如基于历史成功率的动态权重）。
3. Agent 角色分工 体系内部目前主要有四种角色，分别对应不同的能力侧重： 罗辑（Logic Agent） 负责严格的逻辑推理、数学计算和规则校验。它擅长处理需要精确确定性的任务，如因子计算、回测回撤统计、逻辑表达式求值。 写作情况：罗辑的技能插件多来自社区开源的量化库（如 Tushare、Choice 的封装），我主要负责将这些能力包装成统一的调用接口，并为其加上记忆持久化层（使用 SQLite 存储中间结果）。 扩展： - 引入了自定义的中间值缓存机制，使得复杂因子的多步骤计算能够在不同子任务之间复用，避免重复查询。 - 为罗辑加入了断言检查插件，在每一步计算后自动验证结果是否在合理范围内，若异常则触发告警并回滚到上一个已知良好状态。 大史（History Agent） 负责长期记忆和历史数据检索。它挂载了向量数据库（FAISS）和全量的历史行情、财报、指标数据，能够基于语义相似度快速定位过去的类似事件。 写作情况：大史的构建花费了我大量时间在数据清洗和向量化上。我首先把 Tushare 的日线数据导入 Milvus，然后为每只股票构建特征向量（包括基本面、技术面和情感面），最后通过 FAISS 构建索引。检索时，大史会返回最相似的 K 条历史快照，供后续 Agent 参考。 扩展： - 构建了分层索引：粗层用于快速过滤（如行业、市值），细层用于精确相似度计算，显著提升检索速度。 - 加入了时间衰减函数，使得越近期的历史事件在相似度计算中权重更高，更符合 “最近趋势” 的直觉。 智子（Wisdom Agent） 负责创造性思考、方案生成和不确定性下的决策。它擅长写报告、提出假设、设计实验路径。智子通常使用更大的上下文窗模型（如深度模型），能够处理长篇指令。 写作情况：智子的提示词工程是我下的最苦功夫。我为不同的任务类型（如 “因子筛选报告”、“回测结果解读”、“市场热点追踪”）设计了专门的系统提示，并在每次调用前动态注入最近的对话历史和相关检索结果。 扩展： - 引入了 “思维链” 自动生成模块：在智子开始撰写报告前，编排器会先让它列出关键论点和数据支撑点，形成一个大纲，然后再根据大纲逐段展开，这样能够保证逻辑连贯且不易跑偏。 - 为智子加入了自我反思环节：在完成初稿后，智子会再次阅读自己的输出，检查是否存在重复、矛盾或过度推测的地方，并给出修改建议。 赫尔墨斯（Hermes Agent） 负责轻量级的交互和快速响应。它内置了丰富的技能插件（如网页抓取、文件操作、消息发送），适合处理需要即时反馈的任务，比如查询最新新闻、发送飞书通知、生成简单的 Markdown 报告。 写作情况：赫尔墨斯的技能库我基本没做太多改动，主要是根据实际使用场景调整了技能的调用频率和超时参数，以防止其在处理长文本时被上下文窗口截断。 扩展： - 为赫尔墨斯加入了 “快捷技能” 库，将常用的组合操作（如 “抓取网页→提取关键表格→生成图表”）封装为单一可调用的技能，减少交互轮次。 - 引入了速率限制感知：当检测到目标网站返回 429 或延迟异常时，赫尔墨斯会自动降低请求频率并切换到备用数据源（如从网页抓取切换到本地缓存或 API）。
4. 共享工作空间（Shared Workspace） 所有 Agent 通过挂载的目录（如 /home/ubuntu/.openclaw/workspace/）共享中间产物和临时文件。该目录下有子目录划分： - agents/hermes/agent/：赫尔墨斯的运行时配置和技能插件。 - delegation-mechanism/：编排器和任务监控系统脚本。 - runs.json：全局任务执行日志，供审计和回溯使用。 - data/：各 Agent 产生的结构化数据缓存（如因子计算结果、回测净值曲线）。 扩展： - 在 data / 目录下引入了版本化存储：每次写入都会自动生成时间戳子目录，便于追溯历史中间产物，同时保留最近的 N 个版本作为快速回滚点。 - 加入了文件锁机制（基于 flock），防止多个 Agent 同时写入同一文件导致数据竞争。
5. 自愈与监控机制（Self-Heal & Monitoring） 为了让体系能够长期稳定运行，我加装了以下自治能力： 模型守护（Model Guard） 每 2 小时检查一次大模型 API 的健康状况，若出现速率限制或失联，自动切换到备用模型或降级到更小的专用模型。 搜索索引自愈（Search Index Self-Heal） 每日检查向量数据库的完整性，若发现损坏则从备份重建。 网站备份与同步 每日自动备份 Hugo 站点并同步到生产服务器，确保内容发布不中断。 只读巡检（Read-Only Check） 每日三次对系统关键进程、端口监听和文件权限进行只读扫描，异常时上报但不自动修改，避免误伤。 扩展点： - 模型守护不仅监控 API 响应时间，还会分析返回内容的质量（如是否出现大量重复或无意义的文本），一旦判定为低质量响应，则触发降级。 - 搜索索引自愈加入了增量更新逻辑：在检测到索引损坏时，仅重建受影响的分片，而不是全量重建，大幅缩短恢复时间。 - 只读巡检的结果会被写入一个专用的监控看板（如 Grafana），并配置阈值告警，当连续三次检测到同类异常时，自动触发一次轻量级的自愈脚本（如重启特定服务）而不需要人工干预。 各角色的写作情况与分工实录 在开发《云养虾・第一款多角色产品尝试》这篇文章时，我正是让多 Agent 系统全程参与的。整个过程可以分为以下几个阶段：
6. 需求拆解（由编排器完成） 我输入了一个较为模糊的需求：“写一篇关于云养虾产品的技术交流文章，要体现多 Agent 系统的开发思路和功能特点，重点介绍各个角色的分工和写作情况。” 编排器首先将其拆解成六个子任务： - 产品概述与特点列举 - 多 Agent 系统架构图解说明 - 各 Agent 角色（罗辑、大史、智子、赫尔墨斯）的职责描述 - 写作协作过程回顾（谁写了什么、如何交互） - 创新点与探索精神的提炼 - 结尾呼吁与标签建议
7. 信息检索与数据准备（由大史完成） 编排器把 “产品概述与特点列举”、“各 Agent 角色职责描述” 两个子任务交给了大史。大史先从内部的知识库中检索了过去关于 OpenClaw、Hermes、模板养鱼、原生部署的历史笔记和报告；随后从本地挂载的数据目录读取了最近的系统监控日志（如 logs/s32_csd.log、logs/s32_expectation.log），提取出关键指标（如已拉取的期数、配额使用情况）。
8. 逻辑推理与结构框架（由罗辑完成） 大史检索到的原始信息交给了罗辑。罗辑负责把零散的事实组织成逻辑连贯的大纲：先定义产品定位，再分点阐述技术体系的五大模块（网关、编排器、四大 Agent、共享工作空间、自愈机制），最后在每个模块下填入对应的技术细节和实证数据。罗辑还完成了全文的事实核验工作 —— 例如确认 “93 期已拉取数据”、“剩余 83 期需要再跑一天” 之类的数字是否与日志一致。
9. 创意润色与语言润色（由智子完成） 罗得到的初稿框架交给了智子。智子的任务是： - 将技术描述转化为富有叙事感的段落（如把 “编排器使用 Redis Pub/Sub” 写成 “编排器像是个调度员，把任务贴在公告栏上，各 Agent 按需来取”）。 - 加入比喻和亲身经历（“当初我跳过环境校验跑安装脚本，结果一路上 ’ 权限错误 ‘、’ 版本不兼容 ‘、’ 库缺失报错 ’ 轮番招呼……"）。 - 在每个小结后留下思考句，以激发读者的共鸣（“模板里的龙虾更像标准化宠物…… 而 Linux 原生部署驯养出来的龙虾呢？它更像你的一位同事……"）。 - 确保全文语气与之前《AI 架构师》系列保持一致 —— 第一人称、略带自嘲但不失专业。
10. 格式化与输出（由赫尔墨斯完成） 智子润色后的稿件交给了赫尔墨斯。赫尔墨斯负责把最终的 Markdown 文稿写入到指定的路径（content/posts/ 技术交流 / 云养虾・第一款多角色产品尝试 /index.md），并在文件头部自动补全标准的 front matter（包括标题、日期、标签等）。写入完成后，赫尔墨斯还会调用一下本地的 hugo version 检查，确保站点能够正常渲染。
11. 全链路自检与发布（由编排器与自愈机制联合完成） 文件写入完成后，编排器触发了一次 “只读巡检 + 自愈” 流程： - 首先检查目录权限是否为写入者可写，避免因权限问题导致后续 Hugo 构建失败。 - 然后调用站点部署脚本（./deploy.sh --force）进行构建与同步。 - 在部署过程中，若出现 Nginx 配置错误或同步中断，自愈机制会尝试重新拉取最新的备份并重试一次；若仍然失败，则仅记录错误并终止流程，防止无限循环。 - 最终站点成功发布后，编排器会向日志文件写入一条成功记录，并通过飞书 Bot 发送一条提醒消息：“已发布 🦞"。 创新点与探索精神 在整个开发过程中，我始终牢记 “不断创新的探索精神”。具体体现在以下几个方面： - 角色能力的细粒度划分：与之前把 Agent 看作 “一刀切” 的通用助手不同，我根据任务的本质（逻辑、记忆、创造、交互）将能力拆解到四个角色，使得每个 Agent 都能在自己擅长的领域发挥最大效率。 - 编排器作为中枢而非中央控制器：编排器不直接执行任务，而是像指挥家一样安排乐手。这种设计避免了单点故障，也让新角色的加入变得低成本 —— 只要告诉编排器 “我能做什么、需要什么资源”，它就会自动找到合适的位置。 - 数据与能力的闭环共享：通过共享工作空间和向量数据库，各 Agent 的产出能够被其他 Agent 二次利用。例如，罗辑算出的因子值会写入工作空间，供大史做历史相似度检索；智子写出的报告草稿会被赫尔墨斯直接排版输出。 - 自治能力的下沉：而不是把所有容错逻辑堆在编排器里，我将模型守护、索引自愈、权限检查等下沉到各个子系统，使得即使编排器暂时不可用，体系的关键功能仍能部分运行。 - 从 “用” 到 “造” 的心态转变：整个过程让我从最初的 “按下回车看答案” 转变为 “我来定义问题、设计工具、验证结果”。这种心态的转变才是真技术积累的根本。

请参阅 AI 架构师系列文章：《100天，从AI小白到双智能体架构师》