微信龙虾系统架构
与阶段二功能需求
先讲清现有系统如何工作，再梳理阶段二要解决的业务问题，最后集中答疑、明确优先级和配合事项。
- 微信龙虾系统架构介绍
- 阶段二功能需求梳理
- 答疑以及建议
节点一架构
沿用原稿的分层架构，说明微信入口、OpenClaw 网关、智能体、资料能力与资源之间的分工。
整体架构
节点一是已经可用的本地资料基础与微信操作；节点二在此基础上讨论语义检索、资料问答、文档处理，以及更适合持续办公的智能体和桌面入口。
节点一留下什么
本地资料、原目录、元数据、关键字检索，以及微信里的检索、取件、上传和模型配置。
只作范围概括，完整交付范围仍以《节点一需求与工作量说明》为主要依据。
节点二增加什么
建设内容分段、知识索引、检索与来源引用的知识库；文档生成与连续工作按扩展需求确认；桌面入口和底座更换作为本次重点讨论项。
独立平台、版本管理、双向同步与高可用不自动打包进节点二。
节点二原方案首期聚焦“可追溯知识检索”：知识片段、关键词＋语义检索、来源引用，以及全量建库和增量同步。生成式问答、文档生成与客户端属于本次额外讨论的扩展，不能与知识库首期范围混为一项。
现有系统怎样运行
Windows 存资料，Mac mini 运行 OpenClaw 网关与智能体，微信负责收发，模型负责理解与生成；资料读取、上传和回传由业务工具完成。
| 组成 | 主要分工 | 需要区分的边界 |
|---|---|---|
| 微信入口 | 每位使用者与自己的助手交互，发送指令、接收结果和附件 | 独立会话不等于每个人拥有一份独立资料副本 |
| OpenClaw 网关 | 在 Mac mini 上接入消息，关联账号与会话，协调智能体运行 | 本地网关与资料服务不是面向公众开放的业务网站；远程访问仍需受控入口 |
| 智能体与模型 | 理解任务、调度工具、整理回复；支持使用已配置的兼容模型 | 手动切换模型不等于按业务自动路由；外部服务可能排队、限流或中断 |
| 资料工具 | 关键字检索、会话编号取件、上传保存与增量处理 | 限定授权目录和发送对象，不授予任意文件操作权限 |
| Windows 资料目录 | 保存原文件及检索辅助信息，沿用现有业务分类 | 元数据与概要仅辅助查找，原文件才是核对依据 |
一条查找与取件流程
新资料则按“微信发送文件 → 保存到授权目录 → 更新元数据 → 再检索与取件”处理。接收成功、保存成功和处理完成是不同状态，不应混成一句“全部完成”。
一期状态与正式结案分开说。一期已完成功能本次不逐项展开。2026 年 10 月验收报告仍记录 8 项已完成、2 项基本达标，并列出结案确认事项；本次不据此代替客户签认或宣布手续已全部完成。
节点一的检索是关键字匹配，不是已完成的向量搜索；扫描登记也不等于每份文件都已全文识别或完成人工校对。
阶段二功能需求梳理
以《阶段一验收报告》第三节的七项安排为基础，结合长文档图片说明与答疑文档补充讨论；知识库按节点二方案单列。已配置待验证、已有基础待补齐和新增建设分别记录。
只读预览 · 当前版本 1 · 刷新页面可查看最新已保存内容。
| 方向 | 本次讨论内容 | 当前口径 | 需要确认 |
|---|---|---|---|
| 知识库建设与可追溯检索 | 建设内容分段、知识片段、关键词＋语义检索、来源引用、全量建库与增量同步。首期返回相关原文及来源，不把自动综合回答或文档生成混入知识检索。 | 拟定制 依据：节点二方案第六至八节；验收报告第四节第6项要求确认语义检索与来源追溯是否实施。 | 确认是否实施及优先级；提供代表性资料、检索问题和预期来源；对齐标准化正文、版本、资料变化及入口等实际前提。 |
| 故障原因提示 | 区分资料盘暂时读不到、模型暂时不可用、联网失败等原因，用中文说明；服务异常不得误报为资料不存在或处理成功。 | 当前能力 验收报告第三节第1项：已配置，待试用验证，阶段二持续完善。不是本次已重新实测通过。 | 复核故障分类与中文提示是否清楚；保留发生时间和截图。微信“正在输入”不等于可以新增任意实时进度提示。 |
| 文件接收与分步反馈 | 收到文件后先确认“已收到”，再说明后续解析进展与失败原因；接收、保存、处理完成分别表达。 | 当前能力 验收报告第三节第2项：已配置，待试用验证；严格即时确认受微信接收机制限制。 | 确认先收件、后发处理指令的流程；用测试文件复核接收与失败反馈，不承诺脱离通道机制的即时确认。 |
| 按模板生成文档 | 按标准模板生成可编辑文档，明确页面设置、样式、字体、表格样式、页码和关键信息完整性要求。 | 拟定制 验收报告第三节第3项：已有页面设置、样式和字体继承基础；表格样式、页码及完整生成排版属于阶段二建设。 | 提供标准模板与合格样稿；确定字体、页边距、标题层级、表格及页码规则、必填字段和人工审核标准。 |
| 持续记忆与项目档案 | 讨论如何保留环境信息、项目结论与档案。原验收安排为全员共享的全局长期记忆和项目档案，不是按个人或项目分别隔离的记忆空间。 | 拟定制 验收报告第三节第4项：安排采用全局记忆与项目档案文件；本次未据此认定独立项目记忆已交付。 | 确认仍采用共享方式，还是需要增加个人或项目隔离；明确可记内容、写入与纠错方式。新增隔离不按原文默认为已有能力。 |
| 投标文件辅助生成 | 在标准投标资料与模板基础上生成可编辑初稿，列出缺失材料和待核对项；最终资料有效性与商业结论由人工确认。 | 拟定制 验收报告第三节第5项：当前可生成初稿，但仍需大量人工补充；完整能力列为阶段二建设，前提是提供标准投标资料。 | 由谁整理企业证照、历史业绩和人员证书，何时提供；确认招标要求、模板、完整性规则及最终审核人，不承诺无人审核的一键定稿。 |
| 连续发送多个文件 | 只有文件、没有处理指令时先回复“已收到”；文件发完且助手确认后，再下指令统一处理。 | 当前能力 验收报告第三节第6项：已配置，待试用验证；仍逐条接收，无法把通道变成一次合并接收。 | 确认使用顺序与一批文件的边界；复核是否收到后即处理，避免因中途指令引发重复工作。 |
| 同一批文件重复核对 | 对已处理的同一文件优先复用结果，减少反复回复“内容一致，无需重复生成”；内容变化后的处理规则另行明确。 | 当前能力 验收报告第三节第7项：已配置，待试用验证；不由此推导已有完整文件版本库。 | 确认“同一文件”和“需要重做”的判断场景；用相同及内容有变化的样本复核，避免误复用。 |
| 长 Word 文档内嵌图片处理 | 统计内嵌图片并分批读取，关联正文位置，汇总看过、未看和看不清的内容；组件完成后先验证流程，再进行模型对比。 | 拟定制 长文档图片识别说明第一、六、八节：目前可能漏看大量扫描图片；少图逐张查看措施仍在实测，专用组件待开发。 | 提供典型长文档与需核对的编号、金额、日期等字段；组件完成前按章节拆分，约20张图片以内作临时建议，关键证件单独发送并人工核对；不承诺20张以内必然识别无遗漏。 |
| 历史会话保存与切换 | 在既有可行性验证基础上讨论正式保存、命名、切换与重启后的恢复；历史记录查看、会话切换与任务中断恢复分别确定。 | 快速验证 demo 答疑文档第二、三章：保存与切换已做快速验证 demo，正式启用需定制开发，效果以实际部署为准。 | 确认保存范围、保留期限、查找方式及访问权限；当前指令操作以节点一测试手册与实际部署为准，不把旧答疑示例自动当作已上线命令。 |
材料所列七项安排已全部保留，不用泛化的构想功能替代。原约定范围内的问题按实际归属处理，不因列入本表就自动计为新增收费；完成情况、优先级、排期与费用仍待确认。智能体底座更换和桌面客户端入口放在第三部分“答疑以及建议”讨论。
本表的材料对应关系
- 故障原因提示、文件接收提示、按模板生成文档、持续记忆、投标文件、连续发送和重复核对：验收报告第三节七项安排。
- 长文档图片组件与临时拆分建议：2026-10-22 专项说明。
- 历史会话保存与切换：答疑文档第二、三章，按快速验证 demo 处理。
- 知识库：此前提供的节点二方案，以及验收报告第四节的语义检索与来源追溯确认项。
- 节点一需求说明和测试手册用于区分已有范围，不能把其旧测试进度覆盖为今天的验收结论。
答疑以及建议
这里集中讨论智能体底座更换与桌面入口、使用边界、正式模型接入及后续配合事项。底座与客户端是建议方案，不直接计入上一部分已列出的业务需求范围。
智能体底座更换：保留业务基础
本次讨论的是把智能体底座由现有 OpenClaw 方案评估更换为 Hermes，不是更换大模型，也不是重做已经部署的本地资料。
应当保留并回归验证
- 原文件、业务目录、已有元数据与检索记录
- 微信中的检索、编号取件、上传与增量处理闭环
- 用户与会话关联、发送对象检查、目录访问限制
- 兼容模型配置、失败提示、运维记录与备份
希望改善的工作体验
- 历史记录更容易找到与管理
- 确认过的偏好、规则和方法能够复用
- 复杂任务可以分解，过程与结果更容易检查
- 为桌面入口与个人助手提供统一基础
“记忆与进化”指保存、整理和复用规则与经验，不是自动训练底层模型，也不保证使用次数越多就越准确。记忆、技能、历史会话是不同对象，需要分别设计与验收。
替换前先核对这几件事
- 渠道适配：原有账号是否能按平台规则接入，文字与文件收发是否正常。
- 工具适配：现有资料工具能否复用，中文路径、编号和增量处理是否保持正确。
- 权限边界：会话分开不等于文件访问硬隔离；仍需操作系统权限、工具目录限制和收件人校验。
- 记录与回退：哪些旧记录能迁移、哪些只能归档；替换失败时怎样回到原系统，先验证再切换。
图中的 OpenClaw 与 Hermes 表示“当前 / 拟替换”的对照，不预设必须同时运行两个网关，更不代表已经完成迁移。
桌面客户端入口：微信保留
微信继续承担随时查询和文件收发；桌面入口用于较长对话、资料核对、成果查看和记录管理。重点是让每个人在一处看到自己的工作，而不是再做一个仪表盘。
构想说明 · 拟定制
复用已完成的八视图灰度原型，非上线产品。
可切换八张既有构想截图。图片内部控件仅用于讨论布局，不执行真实业务操作；每项功能仍需确定实施范围。
先支持的工作方式
聊天为主；自己的微信等渠道会话按来源可见；右侧就近查看资料与成果；记忆与技能可单独管理。
不能从概念图推导的承诺
不默认所有渠道实时同步，不默认桌面回复会自动发回微信，不展示他人私人对话，也不把每个模拟按钮都算作已约定开发项。
客户端如何安全连接 Mac、允许哪些人登录、可读取哪些文件，需要随正式方案确定；不因新增桌面而直接把网关或文件共享开放到公网。
近期反馈与处理
先把资料访问和故障反馈做稳，再补齐复杂文档处理。具体状态以已有材料为依据，未完成现场验证的，不写成“已彻底解决”。
| 反馈 | 已有情况 | 后续处理与配合 |
|---|---|---|
| 资料盘偶发不可读 | 跨设备读写可用，已有巡检与恢复安排；稳定性仍依赖设备与局域网 | 两台设备优先有线连接、固定地址、不休眠；验证断开和恢复，不承诺所有故障自动修复 |
| 等待时间与提示 | 检索、联网、模型调用可能多步等待；微信提示受渠道机制限制 | 优化调用步骤，区分资料盘、模型与网络原因；不承诺新增微信通道无法显示的实时进度 |
| 多文件接收与重复核对 | 验收材料记录“先确认接收、等指令后统一处理”等已配置、待试用验证项 | 按实际对话复现，记录收到、保存和处理各阶段；平台逐条接收不等于可合并接收 |
| 长 Word 内嵌图片漏看 | 正文提取不等于读取了图片；大量图片需要分批处理和汇总核对 | 单独评估组件，输出已看 / 未看 / 看不清的清单；先验证流程，再比较模型 |
| 行为范围与文件发送 | 需同时约束目录、当前会话和收件人；微信附件仍受大小、类型和频率规则约束 | 继续回归越界和误发防护；无法发送时如实提示，不自动替换为公开链接 |
常见问题
把“现有能用”“验证过可行”和“准备建设”分开，避免因为换底座或增加入口，就把原来的边界说成不存在。
资料保存在本地，是不是就不会传到外部？
不是。原文件、元数据与基础索引保存在客户本地，但调用外部模型生成概要、标签或回答时，可能需要发送必要的文本或文件内容。夸克客户端备份也有独立的数据去向，应分别确认模型授权范围、备份目录与账号，不使用“资料绝不外传”的笼统承诺。
更换底座，能解决微信卡片和正在回复时的所有限制吗？
不能这样承诺。现有材料记录，合并转发、公众号文章和视频号等卡片不能按普通文件直接读取；建议另存为文件或发送可处理的正文。消息何时插入、任务能否取消，需要区分微信通道、运行时和具体工具。更换为 Hermes 后要重新实测，不能沿用旧运行时行为，也不能承诺“立即打断并保留全部步骤”。
每个人自己的助手，是否就天然隔离了全部资料？
独立会话用于区分交互和记录，不等于资料物理隔离。节点一复用同一套授权资料服务；阶段二如需个人或项目级访问范围，需要另外明确身份、资料授权、记忆共享与发送校验，不能只靠提示词约束。
历史会话和桌面端，现在是不是都可以正式使用？
历史会话保存与切换已有快速验证 demo，正式启用仍需定制和部署验证。八视图是界面构想，不是已经上线的桌面产品。历史查看、切换会话、任务恢复和跨渠道展示要分别验收，不能互相替代。
能不能一次上传长文档，直接生成最终投标文件？
现阶段不应保证。需要先处理正文与内嵌图片，识别缺项和看不清的内容，再按模板生成初稿；证照、金额、日期、资质与商业判断须由人工核对。标准资料、模板、缺项规则和合格样例是实施前提。
模型、底座和桌面客户端分别是什么？
模型负责理解与生成；智能体底座负责会话、规则与工具调度；客户端负责呈现与交互。切换模型、更换底座和增加客户端是三件不同的事。更强的模型不能代替文件处理流程、权限限制与业务验收。
“越用越聪明”，究竟承诺什么？
应当落到可查看、可修正和可移除的偏好、规则与方法上，而不是训练底层模型或保证准确率不断增长。个人记忆、项目档案、全员规则和技能方法要分开；高风险经验是否采用，仍需审核。
正式模型接入，为什么几份材料的说法不完全相同？
答疑文档描述客户 GPT 账号授权及国产模型 API Key 的后台接入；《模型使用情况及正式上线建议》描述正式调用统一经过中转站，并区分我方号池和客户提供账号两种责任安排。两份文件没有提供明确的替代关系，不能直接认定其一已经作废。上线前需书面统一调用路径、账号责任、额度、套餐和外部数据去向；当前测试资源不等于正式免费或无限额度。
模型切换、新建会话，应当按哪份操作说明？
现场操作优先按节点一快速测试手册及实际配置：斜杠命令单独一条消息发送，先查看可用模型和当前状态，再切换并复核。旧答疑中的自然语言关键词、二次确认和历史切换示例不能自动代替当前指令约定；密钥与账号配置不在普通微信消息中填写。
以后发生故障，或者需要增加功能，怎样划分？
项目代码与配置缺陷由实施方定位修复；设备、网络、模型与微信平台故障按实际原因协助排查。新增渠道、独立客户端、复杂文档组件等按确认后的新增范围评估。维护、内容调优与新功能开发分别记录，不承诺无限增加功能。
建议与现场确认
先选两到三个高频任务，用真实样本说清输入、输出和合格标准，再评估实现方式、工期与费用。
环境与资料先准备好
- 设备与网络：Mac mini 与 Windows 优先接有线网络、固定地址、关闭休眠；授权目录不直接开放公网。
- 授权与备份：明确读写目录、模型可接收的内容与备份去向；备份功能开启不等于已经验证可以完整恢复。
- 文档样本：提供典型长文档、标准模板、正确样稿和关键核对项，避免只讨论抽象的“自动生成”。
- 异常留证：保留出现时间、问题描述和必要截图，发送给授权维护人员，避免在普通群聊或日志中扩散敏感资料与凭据。
会上把这些问题记清楚
| 确认项 | 需要记录的内容 | 当前状态 |
|---|---|---|
| 优先任务 | 谁在什么场景下使用，最希望减少哪一步重复工作 | 待会中确认 |
| 输入与输出 | 提供哪些资料、希望得到什么结果、哪些信息不能发给外部模型 | 待会中确认 |
| 范围与共享 | 哪些个人可见、哪些项目共享；桌面先覆盖哪些渠道和操作 | 待会中确认 |
| 验收方式 | 合格样例、失败判定、审核人，以及更换底座前必须通过的回归用例 | 待会中确认 |
| 实施顺序 | 原范围修复、业务增强、客户端与底座替换如何排序，哪些先验证再决定 | 待会中确认 |
建议顺序：稳定现有资料链路 → 确定业务样本和边界 → 验证底座与工具兼容 → 分批建设并验收。具体安排以双方确认后的书面方案为准。
材料依据
已按本次重新提供的文档复核；两份阶段一验收 PDF 内容相同，合并作为一份依据。第二部分按验收报告七项安排组织，其他材料负责补充范围、操作或边界，不把历史说明当作今天的运行实测。
- 《节点一需求与工作量说明》V0.1，2026-09-07：一期范围、部署分工、关键字检索与风险边界。
- 《龙虾快速测试手册（节点一）》：已有操作及示例的配套参考，不代替完整范围说明。
- 《阶段一验收报告》正式版 V1.0，2026 年 10 月：验收记录、第三节阶段二安排与第四节待确认事项。
- 《微信龙虾 AI 智能体答疑文档》V1.0，2026 年 10 月：历史会话快速验证 demo、部署及办公入口构想；本稿按后续讨论修正全量同步等过满表述。
- 《模型使用情况及正式上线建议》（正文题名《AI 知识库与龙虾系统模型使用说明》）：模型分工、正式中转方案、号池与客户账号责任、套餐与用量评估。与旧答疑的接入路径差异在本页显式列为待确认。
- 《微信龙虾能力边界说明》，2026-10-09：既有微信通道与运行时限制；底座更换后的行为需另行核验。
- 《关于 Word 长文档中图片内容识别的说明》，2026-10-22：图片漏看原因、组件需求和临时使用建议。
- 《节点二：资料知识检索与来源追溯方案》客户审阅稿 V1.0，2026-08-16：知识片段、混合检索、来源引用、全量建库与增量同步；既有平台、版本和正文就绪前提需与节点一实际能力对齐。
- 既有统一八视图灰度原型及需求与事实清单：仅用于说明拟建设界面，不作为上线能力证明。