三Agent架构方案 · 全面设计

三个系统架构不同，消耗结构也不同，分别处理。

QClaw系（主+2子Agent）： QClaw是Node.js OpenClaw，三个Agent共享同一个gateway。主Agent全负载（完整MEMORY.md+全部skill），子Agent用lightContext=true启动，不加载MEMORY.md，只加载角色专属的system prompt和工具。技能池共享——common-core（rules、web_search、文件I/O）只存一份，三Agent共享不重复加载。子Agent技能清单强制精简：高级市场研究员只挂搜索+分析类skill，创业庄园庄主只挂内容输出+工具类skill。对话历史用lossless-claw自动压缩，三Agent共享不各自维护。

OpenClaw独立版： 独立进程不共享QClaw的资源。优化手段：精简skill列表（只装实际用得上的）、子Agent lightContext、缩短system prompt长度。注意它是Node v24环境，技能需独立安装。

Hermes： Python系统，没有OpenClaw的skill机制。优化方向：缩短personality描述长度、控制可用函数列表数量、每次任务限制最大产出token。Hermes的子Agent是Python子进程，复用父进程插件实例。

子Agent的共性法则： 子Agent数量×每个子Agent的system prompt长度=线性消耗。砍技能是第一刀——挂10个skill的子Agent和挂3个的，消耗差一倍以上。每个子Agent只挂它真的会用的skill。

目标消耗配比： 主Agent 100%（基准），子Agent各30-40%，轻量Agent（如Telegram）10-20%。

优先级排序：

🥇 企业微信——你人在国内，很多商务沟通在微信生态。OpenClaw有wechat-access通道，但需要配置（微信小号或企业微信应用）。适合做国内商务触达。

🥈 Discord——如果你的目标用户是开发者群体，或者后续要做社区运营。Discord的channel机制天然适合多场景交互，一个channel问技术，一个channel查资料，一个channel看监控。

不推荐：Slack（国内用不上）、WhatsApp（被墙）、Signal（没人用）。

建议先搞定Feishu（和你现有的ima/腾讯文档打通），再上Telegram（国际触达），企业微信放第三（商务需求）。

目标不是三个系统在同一份记忆里工作，而是三个系统可以互相接替：今天QClaw做的事，明天换成Hermes接手，Hermes能接得住。

三个层面：知晓度、可复制、可接替。分开设计。

知晓度——工作记录制度。 每个系统做完一件事，写一份固定格式的工作记录到shared-blackboard/work-log/：做了什么、进展程度、产出位置、关键决策、接触人员。其他系统起床时扫一遍目录，就知道别人在忙什么。不需要实时同步。

可复制——产出放共享目录带说明。 产出的文件放shared-blackboard/shared-files/，附带README：这是什么、怎么用、依赖什么、谁写的。另一个系统想复制直接用，不用问原作者。

可接替——checkpoint制度。 每个项目完成时附带checkpoint文件：已完成清单、下一步要做什么、当前卡点、换人接手从哪开始。接手的人直接从checkpoint的「下一步」开始干活，不用从头读项目。

checkpoint示例：

技能不可移植，但知识可以。 一个系统验证了某个API好用，写说明放到shared-files/knowledge-base/。其他系统要用时直接照着做。不需要三份一模一样的技能实现，但要保证三个人都懂得怎么干同一件事。

共享目录结构：

主动通知机制： 你问的"做完事怎么让另两个知道"。三个系统不同时运行，也没有统一消息总线。要按"你提出的每小时通知"来设计。

每个系统维护一个 .last-checked 文件记录最后处理事件的时间戳。每小时（或每次起床时）扫一遍 events/ 目录，只处理比自己上次检查时间新的事件。保证不漏。

写入机制：不管系统是否在线，所有写操作都往 events/ 写一个事件文件，格式固定。比如 events/2026-06-17_0045_qclaw_checkpoint-updated.json。其他系统每小时扫 once 就能抓到。

三档检查频率：

不需要常驻后台服务，不需要跨系统 HTTP 回调。一个 events/ 目录 + 每个系统维护一个 .last-checked 就够了。唯一要保证的是每个系统写事件时必须写文件，不能省。

"专家委员会评审"模式。

执行流程：

① 你或主Agent写一份清晰的问题定义，存到shared/task-queue/comparison/
② spawn三个子会话（用OpenClaw的sessions_spawn机制），各自独立读brief
③ 每个Agent独立出方案，写到shared/outputs/comparison/agent-X.md
④ 主Agent（或再起来一次）读三份方案，做横向对比

对比框架：
可行性 — 方案能直接落地吗？
成本 — 时间和资源投入
风险 — 逆向思维扫一遍，哪个方案踩的坑最少
覆盖度 — 是否考虑了所有关键因素

原方案评估： 三层存储（活跃/归档/历史）是正确方向。压缩前让用户确认这一步很关键——AI不该替你判断什么重要。但原方案假设记忆只有一个主体，现在三个Agent需要"共享+私有"两个维度。

改进的四层结构：

日常维护： 主Agent负责压缩共享活跃层。当私有活跃层过大时，各自Agent自己压缩，但压缩前通知你确认。lossless-claw插件自动处理会话历史压缩，不需要人工介入。

这个方案相比原方案的改进：避免每个Agent都维护一份完整MEMORY.md副本（那等于三倍消耗），通过共享层去掉重复信息，私有层只存角色相关的内容。

不该。物理层面的原因很直接：每个skill是一条system prompt。三个Agent全量加载相同技能 = 三份重复prompt，token浪费。

该共享的（约60%）：
qclaw-rules（所有Agent必须遵守同样行为规则）
SOUL.md核心准则（其他Agent只需要"行为准则"部分，不需要完整双子框架人设）
shared/context.md读写能力（文件I/O基础工具）
web_search（查询信息能力）

不该共享的（约40%）：
ima skill → Feishu Agent和主Agent需要，Telegram Agent不需要
Telegram bot skill → 只有Telegram Agent需要
xbrowser浏览器自动化 → 只有集中执行任务时配，不是每个Agent都挂
腾讯文档skill → Feishu Agent需要，Telegram不需要

怎么做： OpenClaw每个Agent独立配置skills列表。定义一个shared-core skill集合，加到每个Agent配置里。各Agent再加自己的专属技能。新增Agent时shared-core自动继承，专属技能按需添加。

技术上都能，实操上不建议全连。

飞书API分两类：机器人消息（收发消息）和文档操作（读写文档）。前者权限轻，后者权限重——能读你飞书文档的Agent理论上能读到所有内容。Telegram Agent也挂这个权限，多了一个攻击面。

推荐方案：
主Agent + Feishu Agent 连接飞书文档API
Telegram Agent 只接飞书消息API（用于消息中转）
Feishu Agent做文档分析、知识库操作
主Agent做决策和回复复杂查询
Telegram Agent做轻量交互中转

飞书文档API支持遍历目录结构（DriveFile.list + DriveFile.stat）。但建议Feishu Agent只对最近修改的或你标注的目录做深度分析，不需要每天扫描全部目录——按需发现比全量扫描聪明得多。

IMA的能力边界：
接收文件 → 解析文档 → 提取内容 + 向量化 → 建立语义索引 → 支持问答。
本质是RAG（检索增强生成）的实现，但不是最灵活的。

音频： IMA支持文件上传（包括音频），但大概率不会自动转写。上传后的音频在IMA里是"存储"不是"分析"。如果你想对音频内容做语义搜索，需要额外的Whisper转写步骤。

三个Agent管理IMA： 可行，因为IMA有OpenAPI。但IMA没有ACL——任何有API token的Agent都能读写全部内容。而且你对IMA的内部参数（chunk size、embedding模型、rerank策略）没有控制权。

音频解决方案（独立于知识库）：
本地的Whisper（ollama或独立服务）做转写 → 文字存入知识库。两段式流程。

你说清楚了——信息系统项目，涉及的东西不是简单任务清单：合同、项目计划、需求文档、设计文档、测试文档、事件文档、用户手册、里程碑交付物、会议记录、往来函件、工程收款。这些东西互相咬合——一份合同影响计划，一份变更影响人员安排，会议纪要及时更新计划。这不是"放资料"的问题，是"文档之间有关联、文档影响决策"的问题。

IMA 放这些行不行？行，但只是"归档"。你在 IMA 里放了一堆合同和会议纪要，但它们之间没有关联——系统不知道 X 合同对应 Y 项目，Z 会议纪要决定了 A 计划变更。IMA 只存文件，不存关系。

真正的需求拆解：
① 文档的版本管理——合同、计划、设计文档都会迭代，改了什么、谁改的、什么时候改的
② 文档之间的关联——合同→项目→计划→设计→测试→验收，这个链条断了任何一个环节都影响执行
③ 事件和计划的联动——一次客户变更请求、一次延期、一次验收不通过，都会触发计划调整
④ 收付款管理——里程碑到了，对应的款项该收了，如果验收没过就别开发票

你问的是"工具选择"，但第一原理想一下：你真正缺的不是工具，是一个"知道你现在在每个项目里什么位置"的东西。这才是AI agent 该干的活。

推荐的方案分层：

文档层——给你选的，放在本地文件系统，按照项目+阶段+类型的目录结构整理。比如 D:\projects\新豪轩\01-合同\、D:\projects\新豪轩\02-需求\、D:\projects\新豪轩\03-设计\。这是最可靠的，不依赖任何一个平台的存活时间。AI agent 通过 file-catalog.json 索引来定位文件。

元数据层——用一个文件跟踪每个文档的元数据（项目管理用）。每个项目一个 projects/项目名/project-manifest.json，内容：文档清单（路径+类型+版本+状态）、关联关系（这份合同绑定了哪个计划）、关键日期（合同签署日/计划评审日/里程碑日期）、收付款节点。AI agent 能读写这个 manifest，就能回答"这个项目的合同到哪了""这个里程碑的验收过了没"。

任务跟踪层——腾讯智能表格或 Notion 数据库。track 的是"待办事项"而不是"文档"。文档在文件系统里，任务在智能表格里，manifest 文件做关联。三者的关系是：任务涉及某个文档，任务的备注里写"见文档 X"；文档的 manifest 里写"此文档影响任务 Y"。

AI agent 在各层的工作：

QClaw（主）：维护 manifest 文件、关联文档和任务、回答问题"这个项目的关键里程碑还有哪些没过"
Feishu/Hermes：跟客户/同事的往来函件写入 shared-blackboard，对应项目的 manifest 同步更新
所有系统：通过 checkpoint 制度，知道每个项目当前做什么、下一步做什么、有没有卡点

这个方案比单纯用 IMA 好的地方：文件存本地不丢、manifest 文件是结构化的可被 AI 分析、智能表格管任务进度。IMA 可以继续用，但只当"全文搜索"引擎——你记不清某份合同里写了什么的时候去 IMA 搜。它不再是项目管理的唯一载体。

Q8 说的合同、计划、设计文档、测试文档、会议纪要、往来函件、用户手册、各种事件文档——都在本地。而且数量庞大，类型杂乱，有些是 Word 有些是 PDF 有些是聊天记录截图。

分四层处理：

存储层（目录结构）： 按项目分根目录，下面按阶段分文件夹。D:\projects\项目名\ 下建 01-合同、02-需求、03-设计、04-开发、05-测试、06-验收、07-售后、会议记录、函件往来。这个结构是给人类看的，不是给 AI 看的。AI 不看文件夹结构，它看索引。

索引层（file-catalog.json）： 定期扫描所有项目目录，生成包含路径、文件名、类型、大小、修改时间、标签的索引。AI agent 找文件时不翻文件夹，直接查索引。搜索"新豪轩合同"时一秒定位。索引每周更新一次，或有新文件加入时触发更新。

元数据层（project-manifest.json）： 每个项目有一个 manifest 文件，记录：文档清单（路径+版本+状态）、文档之间的关联关系（哪份需求文档对应哪个设计文档）、关键日期和里程碑、收付款节点。这是项目管理的大脑，AI 通过读写 manifest 来知道项目状态。Q8 里说过。

语义搜索层（备选，非必须）： 如果你需要"帮我找到去年那份提到了付款条件的合同"这种模糊搜索，才需要向量数据库。起步阶段不需要——先靠 manifest + 文件目录就能解决 80% 的问题。语义搜索等用到 IMA 发现不够时再加。

音频视频处理： 会议录音 → Whisper 转文字 → 文字存为 .md 文件，放到项目的"会议记录"目录下。转写后的文字自动加入 file-catalog.json 索引。不再需要去工具里搜音频文件，搜文字就行。视频同理——如果包含讲解内容就转写，如果是设计评审录屏就提关键帧截图存下来。

三个系统的分工：
QClaw（主）：维护索引 + 回答文件查询
QClaw（子Agent 高级市场研究员）：分析项目文档内容，提取关键信息写入 manifest
Hermes/OpenClaw 独立版：通过飞书/Telegram 接受你的文件查询需求，返回结果

同意。以后所有HTML页面都打上：

Agent来源标签：双子框架 高级市场研究员 创业庄园庄主
日期标签：📅 YYYY-MM-DD
主题标签：🏷️ 关键词

索引页结构：每个卡片包含Agent标签+日期，方便按Agent筛选。

本页面已按照此规范生成。

按架构和能力切，不是平均分。

QClaw（腾讯改造版）：主决策者 + 深度分析
三套里最重的。有完整人设（双子框架）、有子Agent、有ima skill、有lossless-claw压缩。适合做战略决策、复杂分析、知识库管理、项目管理。
配飞书+Telegram（均需补）；子Agent：高级市场研究员做调研分析，创业庄园庄主做内容输出

OpenClaw 独立版：文档 + 知识库 + 项目支撑
第二重。不做深度决策（交给QClaw），专注文档操作、IMA知识库管理、腾讯文档操作、项目管理支撑。适合你直接命令式交互，比如"查一下新豪轩的合同"。
已有飞书，需补Telegram

Hermes：轻量交互 + 消息中转 + 告警
最轻。不做深度分析和决策，专注消息收发和中转。你在飞书/Telegram发消息给Hermes，它转发到shared-blackboard或者通知你QClaw有新产出。也适合做定时任务和监控告警。
已有飞书+Telegram

一句话分工： QClaw 想，OpenClaw 独立版做，Hermes 传。

任务流转示例： 你在飞书问一个复杂问题 → Hermes收到，写到shared-blackboard/task-queue → QClaw读到，处理完写结果到outputs → Hermes扫到结果回复你。谁都不空转，谁都不冲突。