架构纠正：三个ai agent 都是 QClaw 底下的，共享同一个 gateway/运行时。不是三个独立系统。
你说skills数据量是token消耗主因，这个判断是对的。三个agent虽然在同一个gateway下，但每个agent的prompt是独立构建的——system prompt里包含该agent启用的所有skills的文本。所以技能数量直接影响每次对话的输入token。
第一步，技能审计。 当前主agent（我）启用了15个skill：soul-trainning、find-skills、qclaw-rules、xbrowser、another_them、pdf、docx、xlsx、qclaw-cron-skill、qclaw-env、ima、weiyun、tencent-docs、persona-switch、doc-converter。这些skill的SKILL.md文件大小不一，有些可能只有几百字节，有些可能几KB。加上skills.limits.maxSkillsPromptChars = 20000，说明光是skills部分就吃了2万字符的prompt空间。这是大头。
三个agent各自精简。 主agent（我）虽然看起来技能多，但因为我是主入口，用户随时可能问我任何领域的问题，保留全技能是合理的——但需要检查每个skill是否真的在用。长期没触发过的skill可以禁掉。比如weiyun（微云）、tencent-docs（腾讯文档）、another_them（另一个主题？）——这些你最近用过吗？没用就关掉。
子agent必须做减法。 高级市场研究员和创业庄园庄主的技能列表应该远小于主agent。原则：子agent只挂自己真正会用的skill，不要出于"万一用到"的心理把全技能都配上去。市场研究员只需要搜索+分析+文件读写，不需要persona-switch或xbrowser。庄园庄主只需要商业模型+内容输出+文件I/O，不需要ima或doc-converter。
技能引用机制。 OpenClaw的技能加载机制是：agent定义里配置的skill，启动时才读它的SKILL.md。如果某个skill从来没触发过，它不会额外消耗推理时的token——但它会占用初始化prompt的字符空间。maxSkillsPromptChars = 20000 这个限制意味着每次对话前20KB的prompt已经被skills占满了。缩小这个值能直接省prompt。
其他优化方向。
三个agent都在QClaw下面，共享同一个gateway。所以IM配置是gateway级别的——配一个telegram channel，所有三个agent都能通过它收发消息。飞书已经配上了，telegram刚才也配好了。双通道够了。
如果还想加第三个，Discord的thread机制最适合"三个agent同时出方案"的场景——一个thread里三条消息，标识清晰。Discord bot配置和telegram差不多的复杂度。
QClaw你提到过可能能连微信，这个取决于腾讯改造版有没有加微信通道。如果加了，那就是QClaw独有的优势渠道。
三个agent在同一个QClaw下，共享workspace目录。不需要跨进程通信，直接用文件系统。
互相知道在做什么。 每个agent做完一件事，写一份简短的状态文件到 workspace/shared-status/ 下。文件名带agent名前缀和日期。比如主agent干完一个项目分析，写 main_20260617_新豪轩分析完成.md。其他agent启动时或空闲时扫一遍这个目录，就知道别人做了什么。目前三个agent是轮流和你聊天，不是并发运行，所以"扫目录"足以——下次切换到另一个agent时，它读目录就能看到最新状态。
复制对方的好东西。 一个agent发现了一个好用的prompt模板、分析框架、或数据处理脚本，把说明写到 workspace/shared-tools/ 下。其他agent评估后直接复制到自己的工具库里用。因为skills池是共享的，不需要复制技能文件本身——只需要在主agent的skills目录里放一份，其他agent在配置里按需启用就行。主agent的技能就是所有agent的共享技能库。
能接盘。 一个agent做到一半的事让另一个接手。方案：每个项目/任务结束时（或者切换时），产出一个"移交包"放到 workspace/shared-handover/。pack格式：项目背景、已做什么、未做什么、关键决策、下一个人从哪开始。另一个agent读到移交包就知道从哪续上。
主动通知。 因为三个agent不是并发运行（你切到谁谁才在），所以不需要实时通知。你切换到另一个agent时，它的prompt里有一条规则：启动时扫描 shared-status/ 和 shared-handover/，把新内容摘要给自己看。这就够了。不需要任何后台进程。
这个场景最适合用QClaw的 sessions_spawn 机制。可惜这三个agent不是通过sessions_spawn产生的——它们是独立配置的agent，你在webchat里手动切换。
办法是走文件：你发一个问题，我（主agent）把问题写成任务文件放到 workspace/shared-tasks/compare/问题-日期.md。然后你切到市场研究员，它看到这个任务文件后出方案写到 workspace/shared-tasks/compare/问题-日期-研究员.md。再切到庄园庄主同理。最后你切回主agent时，我读三份方案，合并成一个HTML对比页放在 D:\hermes-html\ 下，你打开看。
这套流程不需要写额外代码。每个agent的prompt里加一条规则就行：启动时检查 shared-tasks/compare/ 目录，有新任务就处理。唯一需要手动的是你切三次agent。一次对比流程大概30秒操作。
旧方案的三层结构（活跃层/归档层/历史层）是针对单个agent设计的。现在三个agent都在QClaw下，情况不太一样。
主agent（我） 直接适用三层方案。MEMORY.md是活跃层，每次加载。memory/*.md是历史层。缺的确实是两样：自动化和搜索。加cron自动压缩和修memory_search索引。
子agent 不需要独立维护一套三层记忆。它们的记忆应该更薄——不需要MEMORY.md，不需要daily notes，只需要知道自己的角色、专属技能、和最近做过什么事。子agent的"记忆"就是它们各自写的status/handover文件 + 共享知识库。你不需要给市场研究员配一个完整的MEMORY.md——它不记得你的个人背景也没问题。
共享知识库。三个agent都知道的核心事实——你的战略三线、项目进度、关键决策——放在 workspace 下的一个共享YAML文件里。三个agent的prompt都配置一条规则：需要时读取这个文件。不是全量加载，是按需检索。这个文件由主agent维护更新。
旧方案说"等到MEMORY.md快满时告诉你让你确认哪些可以归档"——这在实际中不会发生。你不会记得去确认。更好的做法：设一个cron每周跑一次，超15KB自动压缩，挑出"已完成"和"旧配置"类内容摘要归档。压缩结果生成一个清单文件，你要是想查可以打开看。但不需要等你批准才执行。你授权一次就行。
不需要。而且不应该。
知识要共享，技能要分化。 核心事实（你的名字、目标、战略路线、项目状态）三个agent回答时应该一致。这些放在共享知识库里。但技能是干活的工具——市场研究员要搜索和分析，庄园庄主要商业建模和内容输出，主agent要全能但侧重决策判断。三个挂同样的技能是浪费：庄园庄主不需要ima skill，市场研究员不需要persona-switch。
怎么配：
三个agent共享QClaw的同一个飞书channel配置。所以都能通过飞书收发消息、读写文档。飞书的API权限是按app走的，不是按agent走的——只要app有权限，所有agent共享。
但要区分权限级别。不是所有agent都需要飞书文档的读写权限。主agent需要全套，市场研究员只需要搜文档内容（读权限），庄园庄主可能根本不需要飞书能力。方案：主agent用飞书app的全权限，其他agent用同一个app但通过prompt约束使用范围——你可以在prompt里写"你只调用飞书的搜索能力，不进行写操作"。
QClaw的feishu plugin目前配的是 doc/docx/bitable/drive 的读写能力。三个agent都能用。需要注意API限流是按app_id的——如果三个agent同时高频调飞书API，会被限。错峰用就行，三个agent本来也不是并发运行的。
QClaw有ima skill，所以主agent能调IMA的API。我问一下你——你有IMA的API token吗？如果QClaw的ima skill配置了接口，那我确实能在对话里直接查IMA的知识库。如果只是配了skill文件但没有实操接通，那IMA还是只能手动用。
IMA的局限性你之前也感觉到了：它不能直接收音频（需先转文字）、不能调chunk策略和检索参数、对外暴露的API有限。QClaw有IMA的skill不代表我能全盘管理IMA。
替代方案：如果你想用agent直接操作知识库，Dify是更开放的选项。Dify社区版部署在本地，API完全开放，QClaw的三个agent都能通过HTTP调它。你的Ollama上已经有embedding模型，可以直接作为Dify的向量引擎。Dify支持多知识库、多种chunk策略、自定义检索流水线。
你之前的描述很到位——信息系统项目的文档是互相咬合的：合同→计划→设计→测试→验收，中间还有会议纪要、往来函件、变更请求。这些东西的因果链条断了，项目的安排就会出问题。
QClaw的三个agent能做的：
workspace/projects/项目名/_manifest.md：合同要点、付款节点、里程碑、当前阶段、风险问题。我可以根据你的输入更新这个文件。文件怎么放。 项目文件在本地目录，不需要搬动。每个项目目录下放 _manifest.md 做元数据索引。三个agent通过文件I/O技能直接读这些文件。不需要经过IMA。
你当前有项目（新豪轩）在跑吗？如果有一个进行中的项目，我可以帮你先试一个 _manifest.md 的模板，把你当前的项目文档链理一遍。
三个agent都在QClaw下，共享文件I/O能力。本地文件管理分三个层次。
第一层：文件索引。 主agent维护一个 workspace/file-index.json，记录所有项目文件的路径、类型、大小、修改时间、摘要。每次更新项目时同步更新索引。这样三个agent找文件时不需要手动翻目录，查索引就行。搜索"新豪轩的合同"直接定位到文件路径。
第二层：按类型处理。 文档类（PDF/DOCX/MD）→ 主agent读内容和做摘要。音频 → 你传给我或者你自己用whisper转文字后，文字版本存入项目目录。视频同理。我（主agent）能做的是文档分析——合同条款提取、需求文档摘要、版本对比。这些可以直接在对话里完成，不需要额外的知识库系统。
第三层：权限意识。 项目文件属于8里说的项目体系，三个agent各自访问自己职责范围内的文件。主agent访问全部，市场研究员只访问分析和研究类文件，庄园庄主只访问商业和项目层面文件。在file-index.json里加 accessible_by 字段控制。
核心原则：文件不动，工具动。不把文件搬来搬去，用索引来定位和分析。三个agent通过同一个索引+各自prompt规则来分工。
结论页已更新为纠正版。索引页（D:\hermes-html\index.html）会加入本页面的链接。标签规范：主agent用 双子框架，如果市场研究员和庄园庄主也有产出，分别用紫和绿。
所有成果统一放hermes-html目录，索引页由主agent（我）维护更新。其他两个agent产出了页面，直接告诉我，我来更新索引。不需要三个agent同时改同一个文件。