察元桌面版与 WPS 加载项协作拓扑

上个月帮法规科做内网部署科长指着屏幕问我你们这到底装了几个服务为什么端口监听里 62581 和 62588 都有当时我一时没答利索回家把拓扑画了一遍才算彻底讲清楚。这篇就把这两个端口的分工掰开说说也当给准备部署察元AI文档助手的同学留个底。先交代科长为什么起疑内网机器装完任务管理器多了常驻进程安全科例行来问端口用途答不上来就得写书面说明。所以我干脆整理了一张对照卡贴在科室群里谁在监听、干什么活、要不要联网一目了然。先分清62581 是引擎62588 是智能体62581知识库引擎。这是察元桌面版/网络版chayuan-desktop的地盘负责知识库 RAG 检索。单机版最省心http://127.0.0.1:62581免登录直接用网络版带 JWT 登录多人共享一套知识库系统间对接走 HMAC 应用态鉴权。你在 WPS 里调kb_retrieve做 RAG 检索背后干活的就是它。62588MCP 智能体服务。这是 WPS 加载项带起来的 sidecar对外说 Streamable HTTP 的 MCP 协议挂了 46 个文档工具读正文、写批注、批量替换、插表格行列、多文档交叉校对都在这儿。Claude Code、Codex CLI、Cursor 连的就是这个端口。一句话记**检索归 62581改文档归 62588。**落到实际用法让 agent 校对一份规程先kb_retrieve查知识库里的术语规范再proofread_run出问题清单两边互相印证——术语口径以知识库为准错字以校对为准各管各的。这种检索加校对的组合拳正是两个端口各司其职的价值。为什么拆成两个端口刚开始我也觉得两个服务麻烦用久了才体会到解耦的好处。知识库引擎升级换版本文档工具链照常干活加载项更新知识库的索引和权限体系原封不动。职能不同的东西分进程部署本来就是运维常识只是很多一体化产品为了装完就能用把所有东西糊在一个进程里出问题时一倒全倒。还有一层实际好处排查故障时责任边界清楚——校对有问题查 62588检索不出结果查 62581两边日志分开翻不会搅成一锅粥。那天安全科来问我拿分工卡对着端口监听记录讲了三分钟就过了关两个端口都只监听本机回环地址不对外发起连接这正是他们最关心的点。给科室落地的典型拓扑是这样一台内网机器跑网络版当知识库底座各人电脑上的 WPS 加载项通过 MCP 干文档活需要查资料时走 62581 检索。检索、校对、写回全链路都在内网闭环文档数据一个字节不出域——这正是数据安全不出域这个话题在 2026 年被反复强调之后内网用户最在意的一点。一套引擎四档用法察元的引擎是同一套按规模分四档文档助手就是本项目这个 WPS 加载项个人装机即用桌面版单机安装包知识库落在本机服务版Docker 网络版全科室共用一套知识库至臻版浏览器工作空间覆盖数百到上万人。科室场景一般停在第三档就够用了。第四档是给更大规模组织的个人用户不用纠结。选型经验从第一档用起觉得知识库有用再上第二档多人共享需求明确时直接第三档一步到位比跳来跳去折腾少。日常检查两件套排查时两个端口各验各的。MCP 侧健康检查curlhttp://127.0.0.1:62588/healthz返回online说明文档工具链在线。给 Claude Code 注册 MCP 也是一行claude mcpadd--transporthttp chayuan-wps-mcp http://127.0.0.1:62588/mcp知识库侧连不上时先确认 62581 服务起没起、网络版的话登录态过没过期再查 HMAC 对接参数。边界与提醒两个端口都只监听 127.0.0.1本机即信任边界所以日常不用配 Token真要远程访问走代理或者用CHAYUAN_MCP_PORT调整端口规划别图省事直接把端口暴露出去。另外 RAG 检索结果是参考不是权威涉及定密的材料检索命中了也要按本单位流程人工核验。拓扑清楚了出了问题才知道该去敲哪台机器的门。