5个系统，0个联动：香山书房这套多智能体架构，把孤岛问题说透了

一个227万的图书馆项目，五大子系统全部建好了。数据决策、读者服务、设备运维、内容展示、安全管理——一个不少。
但系统之间没有联动。

01 系统越多，孤岛越多

这不是一个假想的问题，是一个已经建成的项目。

中山市香山书房智慧管理系统，建设单位是中山纪念图书馆，承建方是广州图创，合同金额227.3万元（含3年运维），等保二级，2022年5月开工，2023年8月初验，2023年12月终验。规划覆盖100个书房，实际接入了超过105家。20项绩效指标全部达标，读者满意度超过90%，系统可用率不低于99.99%，响应时间小于2秒。

系统分成五大子系统：

• 数据决策分析平台，26项功能——数据仓库、读者行为分析、个性化推荐（相关性+协同+热度）、馆藏调度建议、年度阅读报告
• 多终端发布展示平台，6项功能——插件化接口管理、终端分组发布，Windows和微信双端展示
• 香山书房运维中心，9项功能——设备监控、智能家居控制（灯/空调/门禁）、安防管理（一键求助、IP对讲）、视频监控
• 读者服务管理平台，4项功能——小程序（接入粤省事）、学生阅读成长报告、个人阅读报告单、入馆预约
• 3D全景导览系统，100个书房每个至少6个场景，共600个场景，配1000字配音

看起来很完整。完整到你会觉得这事已经做完了。

但项目的问题跟踪报告里有28条记录。翻出来看，有几条最能说明问题：

• 拓迪运维接口，2022年6月到10月，四个月没拿到——跨厂商接口不兼容
• 阿法迪门禁客流数据，2022年7月到10月，持续缺失——门禁数据和客流统计脱节
• 第三方测评发现数据源问题（2023年3月），部分功能展示不出来
• 27个书房的监控和网络没接入（2023年6月）——硬件没到位，系统功能直接缺失

设备坏了，展示平台还在显示”正常”。书房不可入，读者还在收到推荐通知。数据决策的反馈，从来不回到决策端。

这五个子系统在架构上是并列的，没有一个全局协调层。每个系统独立采集、独立处理、独立输出，协同全靠人去串。

系统多不是问题，不联动才是。

02 先把五个子系统变成五个智能体

如果这五个子系统真的能”各自为政又互相配合”，问题就解决了一半。

现在的状态是——它们事实上已经在做自主决策了：各自采集数据、各自判断、各自输出。但没人让它们以”自主实体”的身份重新组织。

改造成五个智能体：

改了什么？没改架构，只改身份。以前它们是子系统，现在它们是智能体——有感知、有推理、有行动能力。

把隐式的独立性显式化。 这句话听着抽象，但实际效果是：五个系统从”五个孤岛”变成了”五个有身份的参与者”，可以开始互相说话。

03 三层架构：L1干活，L2传话，L3拍板

五个智能体之间要通信，通信要有规则，规则要有仲裁。三层结构：

L1 智能体层——五个Agent本身，每个Agent在现有功能基础上增加状态机。这一层不复杂，改的是身份和状态定义。

L2 事件总线——基于现有协议扩展。香山书房已经在用MQTT（设备状态）、HTTP+WebSocket（实时交互）、SIP2（自动化系统对接）、WebService（跨系统API）。不需要新协议，只需要在现有消息格式里加一层Agent消息头，字段包括：发送方、接收方、消息类型、内容和时间戳。参考FIPA ACL规范。

L3 全局协调层——任务调度引擎（优先级调度）、冲突仲裁引擎（资源冲突解决）、全局状态管理器（系统健康视图）。基于现有的Spring Cloud微服务治理体系。这一层只在跨Agent资源竞争、优先级冲突、系统级事件时介入。

三个场景说清楚：

场景一：设备故障联动。 运维Agent检测到某书房门禁故障，事件总线发布事件。读者服务Agent收到后，推送”该书房暂时无法入馆，可前往邻近书房”。展示Agent收到后，把3D导览标签切为”暂不可用”。安全Agent加强巡查。L3记录事件生成告警报告。

场景二：动态推荐。 数据决策Agent每30分钟发布热门检索词排行榜（这个数字可以调）。读者服务Agent订阅后，调整小程序首页推荐位。展示Agent订阅后，更新液晶墙内容。没有资源冲突，L3不用介入。

场景三：每日闭馆汇总。 每天22点闭馆触发。数据决策Agent生成当日报告，运维Agent汇总设备状态，读者服务Agent生成服务报告，展示Agent切到夜间模板，安全Agent进入夜间安防模式。L3生成当日系统运行日报。

L1负责干活，L2负责传话，L3负责拍板。 三层分得越清楚，系统越不容易失控。

04 协议不用换，加一层就行

最容易被问到的问题：这套架构要不要换协议？

不用。香山书房现有的四个协议，每个都能扩展出Agent通信能力：

• SIP2，图书馆自动化系统对接——扩展为Agent间事务消息（借书行为触发推荐更新）
• MQTT，视频监控接入——扩展为设备状态发布（门禁故障推送事件总线）
• HTTP+WebSocket，智能家居控制——扩展为实时事件订阅（预约变更触发展示刷新）
• WebService，跨系统API——扩展为Agent间标准化消息接口

不换协议的好处很实际：不用重写代码，不用迁移数据，不用培训运维。在现有Spring Boot + Spring Cloud + MySQL（OLAP列式存储、MPP架构）的技术栈上加一层就够了。

升级路径不贵，因为不用推翻重来。

05 前后对比：估算，不是实测

协同前后的效果差，用四组数据说话：

这些数字都是估算，不是实测。30%的运维效率提升，是基于已有绩效（>15%）推算出来的。5秒以内的响应，是基于本地查询小于2秒的基准加协同延迟估算出来的。

没有真实运行数据支撑的数字，写在这里只是为了说清方向，不是结论。试点跑起来之后，这些数字需要用实测数据校正。

预期值不算数，跑出来的数据才算数。

06 五个难点：这才是真正要啃的部分

上面讲的都是能做的。下面讲的是还没解决的。

协议异构集成。 香山书房项目里，拓迪运维、阿法迪门禁、大华视频三个第三方系统用不同的协议和接口标准。问题跟踪报告里有8条记录直接指向跨厂商接口不兼容。MQTT的设备状态消息要转译成SIP2的事务消息时，语义会丢失，延迟会累积，Agent之间的协调准确性就会下降。

数据源依赖风险。 2023年3月的第三方测评发现，数据决策平台的部分功能展示不出来，根因是数据源问题，不是软件bug。这套协同机制高度依赖数据决策Agent的输出——上游数据源出问题，下游所有Agent跟着出错，形成级联故障。现有的数据清洗和校验机制，不够用在Agent协同场景里。

Agent间信任与权限边界。 三层架构里，一个Agent可以跨系统触发操作。但没有跨Agent的权限验证机制。现有系统每个子系统有独立的身份鉴别和访问控制，但Agent协同要求一个Agent的行为被另一个Agent信任——”运维Agent发出的门禁故障通知”凭什么让读者服务Agent信任并执行推送？信任度模型和签名验证方案，这套框架还没给出来。

大规模事件风暴。 100个书房同时运行多Agent系统时，高峰期（开馆、闭馆、节假日）的事件量会指数增长。一个开馆动作就能触发几百个设备状态更新、推荐刷新、展示切换事件。在现有MQTT+WebSocket架构下，事件总线容易积压消息，L3协调层的冲突仲裁也会变成性能瓶颈。这套框架没做压力测试。

Agent失效与容灾恢复。 三层架构假设Agent始终在线，但服务器宕机、网络中断、第三方接口停用都是实际情况。一个Agent长时间离线，依赖它的协同场景同步失效。现有的双机热备能覆盖单点故障，但离线Agent重新上线后的状态同步、未处理事件的补偿机制，还没有解决方案。

能做的都在前面，不能做的都在这里。 这五个难点是这套框架真正的边界，也是下一阶段要攻关的方向。

07 如果要落地：三步走

试点阶段（0-6个月）：选3到5个香山书房，部署L2事件总线，实现基础协同场景。先验证设备异常联动这一条链路——这条链路最短，见效最快，出问题也最容易定位。

扩展阶段（6-12个月）：加L3全局协调层，实现跨书房协同。比如读者从一个书房转到另一个书房时，推荐内容跟着走。

推广阶段（12-24个月）：推广到整个中山市公共文化服务网络，形成区域性的多智能体协同网络。

这些时间点是估计值，实际进度取决于试点结果。

先跑通一条链路，再谈全局。 这句话用在架构里，比用在任何PPT里都管用。

08 一句话总结

香山书房这个项目说明了一件事：系统多不是问题，系统之间不联动才是。把每个子系统改造成一个智能体，用三层架构把它们组织起来，用现有协议扩展通信能力——这条路不需要推倒重来，也不需要大笔投入。

难的部分在协议翻译和Agent信任，不在架构设计。

系统孤岛的问题，不是靠加系统解决的，是靠让系统学会说话解决的。