运营、决策、安防、门户四个场景差异极大，想用一套架构装下，难点不在堆 AI，而在于5️⃣个取舍：
- 单 Agent 还是多 Agent、
- 用框架还是自建、
- 数据靠数仓还是直查、
- 快还是准、
- 不同人群怎么区别对待？
作者 | 听风
编辑/排版 | MM77
翠鸟AI技术漫研 — 拓新AI边界、探索技术增量
结论概述
☝️这样的一套架构能成立，从"运营事务"单场景切入风险最低。
💡核心是把"快慢双通道"做成系统脊椎——常见事务走预制工具、毫秒级响应；疑难问题交给 AI 慢推理求准。
🗨️框架只当脚手架、业务全自建，安防绝不让 AI 进实时链路。
3️⃣大风险在设计阶段钉死，不留给后期
01. 一张图看懂这套架构
系统分六层。
最该记住的是第二层 Router（分诊层）——它是整套设计的脊椎：它替每个请求决定"走快通道还是慢通道"。
L0 · 接入层
打字 / 语音 / 电话三种入口，统一成一种内部消息；进门就标好"这人是决策层还是一线"。
L1 · 分诊路由层（脊椎
替每个请求做分流判断——常见事务走快通道，疑难/跨域走慢通道。安防告警强制走最快路径。
快通道 → 预制工具直接执行（<0.8 秒） | 慢通道 → AI 推理（求准，可慢）
L2 · 智能体编排层
1 个总调度 + 4 个专职智能体（运营 / 决策分析 / 安防研判 / 对外门户），各管一摊、互相隔离。
L3 · 能力层（工具 / 技能库）
快通道的"弹药库"。报修、查工单、缴费查询等都是预制好的标准动作。该走规则的事不上 AI。
L4 · 数据层
数仓管历史与分析，实时库管"现在怎么样"；中间加一层"语义层"统一口径，这是数据质量的胜负手。
L5 · 权限与人群差异化层
一套机制实现"决策层 vs 一线"的差别：能看多少数据、给报告还是给工单、主动推送还是被动应答。
02. 五个纠结点&结论
设计这套架构时绕不开的五个争议，或是整套设计的关键取舍。
① 单个万能 AI，还是多个专职 AI？
结论
多个专职 AI + 一个总调度
四个场景差异太大，一个 AI 什么都管会又慢又不稳。
但关键纪律是反过来的：能用固定规则办的事（算钱、门禁授权、消防联动）一律不上 AI——加 AI 不是越多越好。
② 用开源框架（OpenClaw 等），还是自己搭？
结论
不二选一：框架管"地基"，业务全自建
编排、工具调用这些通用地基用成熟框架，省时间少踩坑；但业务逻辑、权限规则、数据口径、安防链路必须自建。
把框架当脚手架，别把业务写进框架里，否则将来换框架会一地鸡毛。
③ 数据靠现有大数据平台，还是 AI 直接查？
结论
两个都要，再加一层"翻译层"
历史分析查数仓（准、可信），实时状态直查业务库（快）。
真正的胜负手是中间的语义层：让 AI 查"空置率"这种业务指标、而不是自己写数据库语句——口径才统一、数字才不会算错。
④ 求准还是求快？
核心原则
分流：常见的求快，疑难的求准
这是整套架构的第一性原则，已硬化成 L1 分诊层。
报修、查工单这类有标准答案的走快通道（<0.8 秒、不经过 AI）；投诉分析这类需要判断的走慢通道（AI 推理，可慢但准）。
快通道办不了会自动转慢通道兜底。
⑤ 决策层和一线员工怎么区别对待？
结论
一套机制，四个维度自动分
不做两套系统。同一套机制按身份自动区分：
看多少数据（决策层看全局、一线看自己片区）、给什么（决策层要结论趋势建议、一线要动作和工单）、主动还是被动（决策层收日报推送、一线被派单）、从哪进（大屏报告 vs 微信电话）。
03. 反例：这套架构故意"不做"什么
好架构看它拒绝了什么。
下面这些是常见的踩坑做法，我们刻意避开。
| 常见做法（坑） | 我们的选择 | |
| 什么都塞给 AI | 算钱、授权、消防联动走固定规则， | AI 只管该判断的事 |
| 深度绑定一个框架 | 框架只做地基，业务自建，可随时替换 | |
| 让 AI 直接写数据库查询 | AI 查"业务指标"，口径由语义层统一管控 | |
| 安防也让 AI 实时决策 | 安防实时处置走规则引擎（秒级），AI 只做事后研判报告 | |
| 决策层和一线做两套系统 | 一套机制按身份自动差异化，省一半维护成本 |
04. 三大风险，已在设计阶段钉死
不回避风险。
三个最大的雷点已有明确应对，写进架构、不留给后期。
风险一 · 安防要秒级，AI 推理天然慢
应对：
安防实时处置（告警→派人→开单）走纯规则引擎，AI 绝不进这条关键链路，只做事后研判报告。
这条边界在架构阶段写死，不许业务方以后模糊进来。
风险二 · 快慢两通道可能给出互相矛盾的答案
应对：
快通道答案标注"数据截至 X 时刻"，慢通道处理前强制拉最新状态，会话层检测到前后矛盾会主动提示用户。
风险三 · 数据"翻译层"可能成单点、口径走样
应对：
高可用部署 + 关键指标缓存兜底；
指标定义变更须走审批，把它当"数据合同"管，不是随便改的配置。
05. 怎么落地：从运营事务切入
2026 年这个领域最真实的一句话是：
没有哪个模型样样第一。所以别问「哪个最好」，问「我这件该用谁」。
为什么先做"运营事务"（报修 / 访客 / 工单）？
- 意图最清晰，能最快验证"快慢分流"这个核心机制是否成立。
- 只依赖现有业务库，不用先啃数仓和语义层，启动最轻。
- 一次就能跑通三大机制：快通道（查工单）+ 慢通道（投诉分析）+ 多渠道（微信、电话）。
- 失败代价最低——出问题传统系统能兜底，不像安防、财务那样输不起。
后续推进顺序：
① 运营事务→② 决策分析→③ 对外门户→④ 安防（最后）
安防技术不难，但失误代价最高，等统一架构在低风险场景跑稳了再接管。
写在最后
这套架构最值得借鉴的不是"用了多少 AI"，而是三条克制：
能用规则办的事不上 AI、框架只当脚手架不绑死业务、安防这种输不起的场景让 AI 退到事后。
先在运营事务这种低风险场景把快慢分流跑通，再逐步接管决策、门户，安防压到最后——是风险最低的扩张路径。