← 返回文档中心

金融行业案例

OCTO 文档中心 · 场景与案例

知识库Bot-API v1.0系列源码确认文档推导
05-use-cases/OCTO典型应用场景-v1.0场景二扩展
价值卡片-金融-v1.0

案例2：金融机构——智能客服与业务Bot自动化

⚠️ 文档声明（使用前必读）

1. 本案例为能力推导型案例（confidence: medium），基于知识库 Bot-API v1.0 系列源码确认级文档推导编写，非客户实证案例。售前使用时不得表述为"某客户已落地"。

2. 客户画像为虚构合成（"某区域性金融机构"），不指向任何具体客户；如需对外输出，请按 `10-templates/客户案例模板.md` 脱敏规则处理。

3. 文中所有 OCTO 能力描述以知识库 active/review 级源码确认文档为准；全部性能相关数字标注"需PoC实测"，不构成承诺口径。

4. 🔴 标记为硬口径红线，来源于《售前红线卡-v0.1》《权限模型与鉴权体系 v0.1》《Bot-API快速入门 v1.0》等源码确认文档，任何售前沟通不得违背。

5. AI 能力边界：OCTO 提供的是 Bot 运行平台与消息/卡片/事件底座，不内置智能客服成品、不内置 NLP 意图识别。FAQ 智能问答 = 集成方在 Bot 服务端对接行内 LLM API + 知识库检索（RAG）自行实现——"能构建" ≠ "点一下就有"。（来源：OCTO典型应用场景 v1.0 PS-07 纠偏）

1. 客户画像

本章为虚构合成画像，用于方案推导，不指名任何具体客户。

维度	画像描述
机构类型	区域性城商行 / 农商行 / 省级保险公司（二选一推导，方案通用）
客服中心规模	数十至数百坐席（人工客服坐席 + 运营 + 质检，🔴 PS-06：经验口径，不得作为承诺报出）
日均咨询量	大量咨询（含 APP 在线咨询、电话、微信渠道合计，🔴 PS-06：具体数字以客户实测为准）
咨询构成	大部分为重复性、标准流程类咨询（余额查询、卡片挂失、保单查询、理赔进度、手续费规则等）；小部分为复杂/个性化问题
合规要求	金融监管强合规：数据必须本地化存储（不出内网）、对话全程留痕、操作可追溯可审计；受行内信息安全部门与监管检查约束
存量系统	已有 CRM（客户信息）、工单系统（客服工单流转）、核心业务系统；老版本客服软件（无 AI 接口，封闭架构，短期不替换）
渠道现状	电话客服、APP 在线客服、微信公众号三渠道各自独立知识库、独立排班
IT 能力	有行内研发团队与合格集成商；有行内统一身份认证（IAM/4A）；数据不出内网要求下，AI 能力需对接行内 LLM 推理服务或已完成合规审批的 LLM API
对 OCTO 的核心诉求	在不动存量客服系统的前提下，私有化构建"FAQ 自动接待 + 业务 Bot + 人工兜底"三层客服体系，统一知识底座，满足留痕审计

2. 痛点分析

2.1 痛点总览

#	痛点	具体表现	业务后果
①	客服效率低，人工成本高	重复性咨询占比高（查询类/流程类），每条都占用人工坐席；高峰期排队严重，7×24 覆盖困难	人力成本持续攀升；夜间/高峰服务质量不稳定
②	现有客服系统封闭，无法集成 AI	老版本客服软件无 AI 接口、无开放 API，AI 能力"接不进去"；替换整套系统成本高、周期长、风险大	AI 转型被存量系统锁死
③	多渠道割裂	电话 / APP / 微信三渠道各自独立知识库，口径不一致；坐席要背三套答案；知识更新三处维护	答案口径不统一引发投诉；知识运营成本×3
④	合规审计要求	监管要求对话留痕、操作可追溯；现有渠道数据分散在三个系统，审计取证困难	监管检查风险；纠纷时无法快速举证

2.2 痛点 → OCTO 能力映射表

每个痛点对应一组已源码确认的 OCTO 能力（来源标注于表内），映射不到的一律如实标注"需集成方实现"或"超出 OCTO 边界"。

痛点①：客服效率低人工成本高 → Bot 自动接待

客户需求	OCTO 能力（源码确认）	说明	来源
7×24 自动应答	User Bot（`bf_` token）通过 `POST /v1/bot/sendMessage` 发送消息；发私信（Person 频道，channel_type=1）	FAQ 接待 Bot 以 DM 私聊模式 7×24 接待，无需排队	Bot-API快速入门 v1.0 §1.1/§6.4
智能问答	平台底座：消息通道 + 交互卡片 + 事件回调；问答引擎由集成方在 Bot 服务端实现（对接行内 LLM API + 知识库 RAG）	🔴 OCTO 不内置 NLP/智能客服成品，此为边界而非能力缺口	场景文档 PS-07 纠偏
富交互体验	互动卡片 type=17（Adaptive Cards）：octo/v1 展示卡 + octo/v2 交互卡（输入元素 + Action.Submit 回调）；动态改卡（`POST /v1/bot/message/edit` + card_seq CAS）	答案卡片化、评价卡片化、状态卡片可动态更新（详见 §4.3）	消息类型与发送 v1.0 §3.12；错误码与排障 v1.0 §三
转人工兜底	建群 / Thread 全套管理（建/删/加入/退出/归档）；@群成员 / @所有人（内联格式 `@[uid:displayName]`、`mention.all=1`）	会话升级时自动建坐席协作 Thread 并 @坐席	Bot-API快速入门 v1.0 §6.3/§6.4

痛点②：客服系统封闭无法集成 AI → 开放 Bot API 旁路并行

客户需求	OCTO 能力（源码确认）	说明	来源
开放 API 面	完整 Bot API（`/v1/bot/*` REST），Bearer `bf_` token 鉴权；sendMessage / message/edit / events / 群组 / Thread / 文件 5 端点族	全量开放 API 见《Bot-API快速入门 v1.0》§6 端点清单	Bot-API快速入门 v1.0 §6
事件回调机制	HTTP 长轮询 `POST /v1/bot/events`（wait ≤30s，Redis sorted-set + BLPOP；5 个事件写入源：DM/@、card_action、文档评论@Bot、bot_setting 等）；at-least-once + cursor/ACK	🔴 不是 WebSocket，不是 Bot 入站 Webhook——方案与沟通中禁止错误表述	Bot-API快速入门 v1.0 三大易错点①；Webhook与事件订阅 v1.0 §1
不动存量系统	OCTO 旁路部署（Docker/K8s 私有化），存量客服软件继续运行；两系统通过工单/CRM API 桥接	AI 能力以"增量"方式注入，不替换、不停机	生产部署形态文档；场景二 §2.5
系统集成	群入站 Webhook（外部系统→群消息，Bot 可管理）；平台级出站 Webhook 端点（`/v1/webhook`、`/v2/webhook`）存在但订阅模型待确认	工单状态推送到坐席群用群入站 Webhook；出站 Webhook ⚠️ 不作承诺口径（P1-06 待确认）	Webhook与事件订阅 v1.0 §4；open-questions P1-06

痛点③：多渠道割裂 → 统一 Bot 运行时 + 统一知识底座

客户需求	OCTO 能力（源码确认）	说明	来源
统一 Bot 后端	Bot API 与 Bot 身份渠道无关：同一 Bot 服务端可服务 OCTO 客户端（Web/PC/iOS/Android）内的一切会话	渠道统一在"Bot 服务端编排层"实现，OCTO 是运行底座	Bot-API快速入门 v1.0 §1
统一知识库	Docs 文档协同（Tiptap+Yjs 实时协同，opt-in profile）、Search 全文搜索（Kafka+OpenSearch，opt-in）可作行内知识库载体	知识口径收敛到单一知识库，三渠道 Bot 服务端统一引用；Docs/Search 为可选模块按需启用	场景一 §1.3；模块文档 v0.3
外部渠道适配	🔴 OCTO 不内置微信公众号 / 电话 CTI 渠道适配器——微信/电话渠道需集成商开发适配层，将外部渠道消息桥接到 Bot 服务端（经 OCTO Bot API 收发）	诚实边界：OCTO 客户端覆盖 Web/iOS/Android/PC；微信/PSTN 是外部渠道	场景二 §2.8；客户端支持矩阵
坐席知识辅助	群聊 @Bot 触发事件；语音转写（opt-in speech profile）；Bot OBO 搜索（`POST /v1/botfather/messages/search`，受 grant+scope 校验）	坐席在协作群 @知识 Bot 获取推荐话术；可搜索历史会话沉淀	Bot-API快速入门 v1.0 §1.1/§6.6

痛点④：合规审计要求 → 私有化 + 全量留痕

客户需求	OCTO 能力（源码确认）	说明	来源
数据本地化	全栈私有化部署（Docker Compose / K8s，数据落行内 MySQL/MinIO），数据不出内网	消息/附件/文件全量存储于行内基础设施	生产部署形态总览；售前红线卡 G7
对话留痕	消息持久化于 MySQL（octo 库）；Bot 可经 `POST /v1/bot/messages/sync` 补拉历史消息	全渠道对话（DM/群/Thread）统一落库，替代三系统分散取证	Bot-API概览 v0.4；Webhook与事件订阅 v1.0 §1.5
操作可追溯	card_action 事件含 `operator_uid`（操作人）、`acted_at`（时间）、`inputs`（提交内容）；事件 at-least-once 投递 + event_id 可去重对账	谁在何时提交了什么表单/点了什么按钮，全程可回溯	Webhook与事件订阅 v1.0 §2.6
审计访问控制	系统角色 `dashboardReader`（看板只读）可授予审计/质检人员；Space 三档角色（member/admin/owner）+ 群三档角色；SSO（OIDC）对接行内 IAM	审计岗只读看板；🔴 无自定义 RBAC（见 §8 硬口径#10），岗位差异化权限在业务系统侧实现	权限模型与鉴权体系 §2.1/§5
合规报表导出	⚠️ OCTO 无内置合规报表/审计导出模块（且删号无 GDPR 导出功能）——审计导出需基于数据库按行内合规要求定制开发	如实告知边界，定制工作量纳入实施方案	场景一 §1.8 硬口径#10

3. OCTO 解决方案概览

3.1 三层 Bot 编排架构（文字版架构图）

🔴 关键架构事实：OCTO 无 Bot 间直接 API 互调（无 bot-to-bot RPC，Q9 BA-05 源码确认），Bot 间交互只能靠群消息 fan-out。因此三层编排在"客服中台 Bot 服务"内实现（服务端统一路由/升级/降级），OCTO 提供消息、卡片、事件底座——这是本方案与"OCTO 内置智能客服编排"的本质区别，售前必须讲清。

客户触点
  ├─ APP 内嵌 OCTO 客户端（Web/PC/iOS/Android，原生支持）
  ├─ 微信公众号/小程序 ──┐
  └─ 电话渠道（CTI）    ──┴─► 渠道适配层（集成商开发，OCTO 不内置）
        │
        ▼
┌──────────────────────────────────────────────────────────────┐
│ 第一层：FAQ 接待 Bot（bf_ Token A）——7×24 自助闭环              │
│  · DM 私聊接待（channel_type=1）                               │
│  · Bot 服务端调行内 LLM + 统一知识库 RAG 生成答案                │
│  · 文本/展示卡（octo/v1）回复 + 满意度评价卡（octo/v2）          │
│  · 解决 → 自助闭环；未解决/客户要求 → 升级第二层                 │
├──────────────────────────────────────────────────────────────┤
│ 第二层：专业业务 Bot（bf_ Token B）——业务表单与工单流转          │
│  · 业务办理表单卡（octo/v2：Input.Text + Input.ChoiceSet）      │
│  · 信息确认卡（FactSet + 确认/取消 Action.Submit）              │
│  · card_action 回调 → 客服中台 → 工单系统 REST API 建单         │
│  · 可自助 → 表单+确认+回执；高风险/复杂 → 升级第三层             │
├──────────────────────────────────────────────────────────────┤
│ 第三层：人工坐席兜底（坐席协作群 / Thread）                      │
│  · 自动建协作 Thread + @坐席（@[uid:姓名] / mention.all=1）     │
│  · CRM 客户信息卡片带出（脱敏展示卡）                            │
│  · 坐席知识辅助 Bot（@指令 → LLM+知识库 → 推荐话术卡）           │
│  · 办结 → 回发满意度评价卡 → 会话归档                            │
├──────────────────────────────────────────────────────────────┤
│ 编排层：客服中台 Bot 服务（集成方开发）                          │
│  · 持多张 bf_ token，每 token 独立长轮询 goroutine              │
│  · 升级/降级/路由逻辑在服务端实现（Bot 间无 RPC，见上）           │
│  · 幂等去重（event_id）/ 429 指数退避 / 审计日志落库             │
└──────────────────────────────────────────────────────────────┘
        │ 长轮询收事件 / sendMessage+卡片发消息 / Webhook 通知
        ▼
OCTO 平台（行内私有化部署）
  · octo-server（Bot API 全路由 + 卡片渲染 + 限流）
  · WuKongIM（IM 底座）+ MySQL 8（消息/用户/群数据落库留痕）
  · Redis 7（bot_task 队列/幂等/限流）+ MinIO（附件存储）
  · nginx（单端口入口 + TLS 终结）+ octo-web / octo-admin
  · 可选 profile：docs（统一知识库）/ search / speech / summary
        │ 内网东西向 REST（经行内 API 网关）
        ▼
行内系统：LLM 推理服务 / 统一知识库 / CRM / 工单系统 / 核心业务 / BI 看板

要点	说明	依据
三层是逻辑分层，不是三个孤立系统	第一/二层 Bot 与第三层坐席共享同一 OCTO Space，会话上下文随升级链路带下（由客服中台维护会话状态）	方案设计
升级链路	FAQ 未解决 → 业务 Bot（表单）；高风险业务 → 坐席 Thread（@坐席）；客户明示"转人工" → 直达第三层	方案设计
Bot 身份隔离	FAQ Bot / 业务 Bot / 知识辅助 Bot 分别独立 `bf_` token，限流按 robotID 分桶隔离（一个 Bot 触发限流不影响其他 Bot）	错误码与排障 v1.0 §4.1
token 安全	bot_token = Bot 全部权限凭证；泄露后攻击者可冒充 Bot 发消息/读事件；泄露处置：BotFather `/revoke` 重置（"Yes, revoke it" 二次确认，旧 token 立即失效）	Bot-API快速入门 v1.0 §2.3

4. 详细设计

4.1 用户旅程

旅程 1：客户咨询 FAQ（自助闭环）

1. 客户在 APP 内嵌 OCTO 入口给 FAQ 接待 Bot 发私信（DM，channel_type=1）
2. 客服中台长轮询收到普通消息事件（POST /v1/bot/events，payload.type=1）
3. Bot 服务端调行内 LLM + 统一知识库 RAG → 生成答案
4. Bot 回复：知识卡片（octo/v1 展示卡：答案 + 依据条款 + 相关问题）
   + 追加满意度评价卡（octo/v2 交互卡，见 §4.3-1）
5. 客户提交评价 → card_action 事件（operator_uid + inputs）
   → Bot 记录 CSAT → 动态改卡（/v1/bot/message/edit + card_seq CAS）
   将评价卡更新为"已评价，感谢反馈"状态（防重复提交）
6. 未解决信号（客户回复"转人工"/ 连续 2 次负面反馈）→ 升级第二/三层

DM 模式规避待确认项：群聊中不 @Bot 的普通消息是否投递给 Bot 待确认（Webhook与事件订阅 v1.0 §3.3），FAQ Bot 设计为私信模式，事件投递已源码确认（事件源①）。
动态改卡防重复：评价提交后用 POST /v1/bot/message/edit + card_seq CAS 乐观锁更新卡片，多次并发编辑不冲突（消息类型与发送 v1.0 §3.12.7）。
LLM 时延体验：LLM 推理期间可先发 POST /v1/bot/typing 打字指示器（路由已确认，格式待补），再返回答案。

旅程 2：业务办理申请与转人工（挂失场景示例）

1. 客户在 FAQ Bot 选择"卡片挂失" → 升级到业务 Bot
2. 业务 Bot 发送业务办理表单卡（octo/v2，见 §4.3-2：
   Input.ChoiceSet 挂失类型 + Input.Text 证件后6位/联系电话 + 提交）
3. 客户提交 → card_action 事件
   ⚠️ inputs 为用户提交内容，客服中台必须自行校验（不信任表单值原则）
4. 客服中台校验通过 → 调工单系统 REST API 创建工单（内网 API 网关）
5. 业务 Bot 发送信息确认卡（octo/v2，见 §4.3-3：FactSet 工单摘要 + 确认/取消）
6. 客户点"确认无误" → card_action → 工单状态推进 → 动态改卡锁定"已受理"
   （卡片 actions 替换为状态 TextBlock，不可再次操作）
7. 高风险分支（正式挂失/大额异动）：
   客服中台自动创建坐席协作 Thread → @卡业务坐席组
   → 坐席人工核验（电话回拨，联系电话取自表单）
8. 全程留痕：客户消息、卡片消息、card_action（operator_uid/acted_at/inputs）
   全量落 OCTO MySQL；工单号关联会话 ID 双向可查

旅程 3：坐席辅助知识推荐（内部效率）

1. 坐席在"卡业务坐席组"群 @知识辅助 Bot："客户问境外刷卡的每日限额规则"
2. Bot 服务端收到群聊 @Bot 事件（事件源①，channel_type=2）
   → 调行内 LLM + 统一知识库 → 生成推荐话术
3. Bot 回复推荐话术卡（octo/v1 展示卡）：
   FactSet（标准话术 / 依据条款 / 适用客群 / 最近更新时间）
   + Action.CopyToClipboard（坐席一键复制话术）
   + Action.OpenUrl（跳转知识库原文）
4. 坐席复制话术 → 在自己的客户会话中粘贴回复（人工环节）
5. 可选（启用 speech profile）：客户语音咨询自动转写为文字
   → Bot 按文本链路处理
   ⚠️ 语音转写引擎需行内 ASR 服务（OCTO speech 模块默认外部 API）；
   🔴 Bot 不能发送语音消息（无 TTS，type=4 Bot 不可发）；
   音频文件不进对象存储，仅本地 ASR 日志保留 7 天（金融合规需评估该保留策略）

旅程 4：运营数据看板

1. 运营平台定时任务（集成方 cron，🔴非 OCTO 内置 Bot 调度器）
   → 调客服中台数据接口
2. 客服中台汇总（咨询量/自助解决率/转人工率/CSAT/工单积压）
   → Bot 向"客服运营群"发送日报卡片（type=17，octo/v1 展示卡）：
   TextBlock 标题 + FactSet 核心指标 + Table 分渠道明细
   + Action.OpenUrl 跳转行内 BI 系统深度查看
3. 异常指标（如自助解决率环比跌破阈值）→ 追加一条文本消息
   + @所有人（mention.all=1）提醒运营负责人

4.2 卡片能力规范（先读再用）

三张卡片模板遵守以下源码确认的硬性规范（来源：Bot-API错误码与排障 v1.0 §三、消息类型与发送 v1.0 §3.12、快速入门 v1.0 §5.1.1）：

规范项	值	说明
消息类型	`type: 17`（互动卡片，Adaptive Cards）	Bot 专属：普通用户 API 绝对拒绝卡片 payload（`ErrMessageCardSendForbidden`）
版本字段	`card_version: "1.5"` + 卡片内 `version: "1.5"`	版本不匹配直接拒绝（`ErrCardProfileUnsupported`）
硬限制	payload ≤ 512 KiB；节点 ≤ 200；嵌套深度 ≤ 16	超限报 `ErrCardTooLarge` / `ErrCardTooManyNodes`；三张模板均远低于限额
Profile	展示卡用 `octo/v1`；交互卡（输入+提交）必须用 `octo/v2`	输入元素（Input.Text/ChoiceSet/Toggle 等）与 Action.Submit 为 v2 专属；v1 仅本地动作
元素白名单	展示：TextBlock/RichTextBlock/Image/ImageSet/Container/ColumnSet/FactSet/Table/ActionSet；输入(v2)：Input.Text/Toggle/ChoiceSet/Number/Date/Time；动作：OpenUrl/ToggleVisibility/CopyToClipboard + Action.Submit(v2)	🔴 不支持 `Action.Execute` / auto-refresh
能力探测	发送前建议 `GET /v1/bot/card/profile` 探测可用 profiles/limits/card_version，返回 manifest 为运行时权威依据	客户端不支持时自动降级纯文本
动态改卡	`POST /v1/bot/message/edit` + `card_seq` CAS 乐观锁	用于"已评价/已受理/已锁定"状态更新
校验方式	🔴 无独立校验端点，校验在发送入口内联执行	开发环境先发测试消息验证卡片格式，再逐步添加元素

4.3 卡片模板示例（3 张，完整 JSON 可直接用）

以下 JSON 均为 `POST /v1/bot/sendMessage` 完整请求体（Bearer `bf_` token 鉴权），`channel_id` 替换为实际会话 ID 即可发送。占位数据（工单号/姓名/尾号）需按实际业务填充。属性级校验以运行时 manifest 为准，建议先在开发环境发送验证。

4.3-1 满意度评价卡（Input.ChoiceSet + 提交）

{
  "channel_id": "<客户DM会话ID>",
  "channel_type": 1,
  "payload": {
    "type": 17,
    "profile": "octo/v2",
    "card_version": "1.5",
    "card": {
      "type": "AdaptiveCard",
      "version": "1.5",
      "body": [
        {
          "type": "TextBlock",
          "text": "📝 服务满意度评价",
          "size": "medium",
          "weight": "bolder"
        },
        {
          "type": "TextBlock",
          "text": "本次咨询是否解决了您的问题？您的反馈将帮助我们改进服务。",
          "isSubtle": true,
          "wrap": true
        },
        {
          "type": "Input.ChoiceSet",
          "id": "csat_score",
          "label": "满意度评分",
          "style": "expanded",
          "value": "5",
          "choices": [
            { "title": "非常满意", "value": "5" },
            { "title": "满意", "value": "4" },
            { "title": "一般", "value": "3" },
            { "title": "不满意", "value": "2" }
          ]
        },
        {
          "type": "Input.Text",
          "id": "csat_comment",
          "label": "其他意见（选填）",
          "placeholder": "请输入您的建议（100字以内）",
          "isMultiline": true,
          "maxLength": 100
        }
      ],
      "actions": [
        {
          "type": "Action.Submit",
          "title": "提交评价",
          "data": {
            "action": "csat_submit",
            "session_id": "CS-20260922-0001"
          }
        }
      ]
    }
  },
  "client_msg_no": "csat-CS-20260922-0001"
}

data.session_id 用于客服中台关联会话；data.action 为回调路由键。
客户提交后客服中台收到 card_action 事件（event_data.inputs.csat_score / inputs.csat_comment），记录 CSAT 并动态改卡为"已评价"状态。
inputs 是用户提交内容，客服中台必须自行校验合法性（长度/枚举值/防注入）。

4.3-2 业务办理表单卡（文本输入 + 下拉 + 提交，以借记卡挂失为例）

{
  "channel_id": "<客户DM会话ID>",
  "channel_type": 1,
  "payload": {
    "type": 17,
    "profile": "octo/v2",
    "card_version": "1.5",
    "card": {
      "type": "AdaptiveCard",
      "version": "1.5",
      "body": [
        {
          "type": "TextBlock",
          "text": "🏦 借记卡挂失申请",
          "size": "medium",
          "weight": "bolder"
        },
        {
          "type": "TextBlock",
          "text": "请填写以下信息提交挂失申请。正式挂失需坐席人工核验后办理。",
          "isSubtle": true,
          "wrap": true
        },
        {
          "type": "FactSet",
          "facts": [
            { "title": "客户姓名", "value": "张*" },
            { "title": "卡号尾号", "value": "**** 6789" }
          ]
        },
        {
          "type": "Input.ChoiceSet",
          "id": "loss_type",
          "label": "挂失类型",
          "style": "compact",
          "value": "temp_loss",
          "choices": [
            { "title": "临时挂失（5天内有效，可自助解挂）", "value": "temp_loss" },
            { "title": "正式挂失（需坐席核验后补办新卡）", "value": "formal_loss" }
          ]
        },
        {
          "type": "Input.Text",
          "id": "id_last6",
          "label": "证件号后6位",
          "placeholder": "请输入身份证后6位",
          "maxLength": 6
        },
        {
          "type": "Input.Text",
          "id": "contact_phone",
          "label": "联系电话",
          "placeholder": "用于坐席核验回拨",
          "maxLength": 20
        },
        {
          "type": "Input.Toggle",
          "id": "agree_notice",
          "title": "我已阅读并同意《挂失业务办理须知》",
          "value": "false",
          "valueOn": "true",
          "valueOff": "false"
        }
      ],
      "actions": [
        {
          "type": "Action.Submit",
          "title": "提交申请",
          "data": {
            "action": "biz_apply_submit",
            "biz_type": "debit_card_loss",
            "form_version": "1.0"
          }
        },
        {
          "type": "Action.OpenUrl",
          "title": "查看办理须知",
          "url": "https://help.bank.example.com/loss-notice"
        }
      ]
    }
  },
  "client_msg_no": "biz-apply-20260922-0002"
}

客户身份核验不依赖卡片内证件号字段——卡片仅采集意愿信息，真实身份核验由行内核身系统/坐席回拨完成（客服中台业务规则）。
agree_notice Toggle 未勾选时客服中台应拒绝受理（服务端校验，不能信任客户端状态）。
高风险分支：loss_type == "formal_loss" 时自动升级第三层坐席核验。

4.3-3 信息确认卡（事实展示 + 确认/取消按钮）

{
  "channel_id": "<客户DM会话ID>",
  "channel_type": 1,
  "payload": {
    "type": 17,
    "profile": "octo/v2",
    "card_version": "1.5",
    "card": {
      "type": "AdaptiveCard",
      "version": "1.5",
      "body": [
        {
          "type": "TextBlock",
          "text": "✅ 挂失申请信息确认",
          "size": "medium",
          "weight": "bolder"
        },
        {
          "type": "TextBlock",
          "text": "请核对以下受理信息，确认无误后工单进入处理流程。",
          "isSubtle": true,
          "wrap": true
        },
        {
          "type": "FactSet",
          "facts": [
            { "title": "工单号", "value": "GD-20260922-00315" },
            { "title": "业务类型", "value": "借记卡挂失" },
            { "title": "挂失方式", "value": "临时挂失（5天内有效）" },
            { "title": "卡号尾号", "value": "**** 6789" },
            { "title": "受理坐席组", "value": "卡业务二组" },
            { "title": "生效时间", "value": "确认后即时生效" }
          ]
        },
        {
          "type": "TextBlock",
          "text": "提示：确认后本卡片将锁定。如需变更，请联系在线坐席。",
          "isSubtle": true,
          "wrap": true
        }
      ],
      "actions": [
        {
          "type": "Action.Submit",
          "title": "确认无误",
          "data": {
            "action": "biz_confirm",
            "ticket_id": "GD-20260922-00315"
          }
        },
        {
          "type": "Action.Submit",
          "title": "取消申请",
          "data": {
            "action": "biz_cancel",
            "ticket_id": "GD-20260922-00315"
          }
        }
      ]
    }
  },
  "client_msg_no": "biz-confirm-20260922-00315"
}

确认/取消均为 Action.Submit（回调服务端），客服中台按 data.action 路由到工单系统对应状态机。
客户点击后动态改卡（card_seq CAS）：将 actions 整体替换为状态 TextBlock（"已确认受理 ✓"/"已取消"），实现一次性操作防重复提交。
两次并发点击由 card_seq CAS 保证最终一致，客服中台侧仍需以工单系统状态机为唯一权威（幂等处理）。

4.4 系统集成方案

4.4.1 Webhook 对接工单系统

⚠️ 先厘清概念（售前高频混淆点）：Bot 收事件 = HTTP 长轮询，不是 Webhook。OCTO 的 Webhook 能力是"平台级"的，分两个方向：

方向	机制	本方案用途	确认状态
工单 → OCTO 群（入站）	群入站 Webhook（外部系统推消息进群/子区；Bot 可创建/管理群的入站 Webhook）	工单状态变更（受理/处理中/办结/回访）推送到坐席协作群，坐席实时可见	✅ 能力源码确认（Q9 BA-04）；具体管理端点参数待补（V10-09）
OCTO → 工单（出站）	推荐走客服中台 REST 直调工单 API（不依赖 OCTO 出站 Webhook）	card_action 建单、状态推进、关联查询	✅ Bot 服务端调行内 API（常规集成）
平台级出站 Webhook	`/v1/webhook`、`/v2/webhook` 端点存在	🔴 不作为承诺口径：per-bot 订阅模型/签名规范/重试策略待确认（P1-06、V10-07）	⚠️ 待确认，PoC 期验证

4.4.2 长轮询事件处理（客服中台核心框架）

# 客服中台：多 Bot 独立长轮询（每 token 一个 goroutine/线程）
# 依据：错误码与排障 v1.0 §五；Webhook与事件订阅 v1.0 §1/§8
import requests, time

def poll_loop(bot_token, handler):
    event_id = 0                                    # 断点：单调递增，exclusive
    while True:
        try:
            resp = requests.post(
                f"{HOST}/v1/bot/events",
                headers={"Authorization": f"Bearer {bot_token}"},
                json={"event_id": event_id, "limit": 20, "wait": 10},
                timeout=15,                          # 客户端超时 > wait
            )
            if resp.status_code == 429:              # 限流：读 Retry-After 指数退避
                time.sleep(int(resp.headers.get("Retry-After", "5")))
                continue
            resp.raise_for_status()
            for evt in resp.json().get("events", []):
                persist(evt)                         # ① 先落库（审计+幂等）
                handler(evt)                         # ② 业务处理（按 event_type 分派）
                ack(bot_token, evt["event_id"])      # ③ 后 ACK（at-least-once 语义）
                event_id = evt["event_id"]
            # 收到响应立即发起下一次 poll，不加 sleep（服务端无事件时 hold）
        except requests.Timeout:
            continue
        except Exception:
            time.sleep(3)                            # 网络异常退避重连

要点	规则	依据
方法与断点	`POST /v1/bot/events`（GET 返回 404）；`event_id` exclusive 单调递增；limit 默认 20 上限 100；wait 服务端 clamp 到 [0,30]s	错误码 §5.1/5.2
投递语义	at-least-once——客服中台必须基于 event_id 去重幂等	快速入门 §5.2
ACK 顺序	先持久化 cursor/事件，再 ACK——崩溃至多重放一次，绝不 ACK 已遗忘事件	Webhook与事件订阅 §1.6
断线恢复	尽快重连（🔴 事件保留 TTL 待确认，P1-03）；可用 `POST /v1/bot/messages/sync` 补拉历史消息	错误码 §5.2；open-questions P1-03
事件分派	`event_type` 分派：`card_action`（卡片回调）→ 业务处理器；无 event_type（普通 DM/@ 消息）→ FAQ/知识链路	Webhook与事件订阅 §2
限流隔离	限流按 robotID 分桶——FAQ Bot 高峰被限流不影响业务 Bot/知识 Bot 独立桶	错误码 §4.1
429 处理	读 `Retry-After` / `X-RateLimit-Remaining` 头，指数退避；高峰用批量接口（members ≤200 / message_ids ≤100）+ 错峰 + 消息合并（多条短消息合并为一张结构化卡片）	错误码 §4.3/4.5
回复上下文	🔴 无独立 `in_reply_to` 顶层字段，引用关系在 payload 内（WuKongIM reply 结构），客服中台自行解析	快速入门 §5.2

4.4.3 CRM 客户信息卡片带出

1. 坐席在协作群 @业务 Bot："@业务Bot 查客户 138****5678"
2. Bot 服务端收到 @ 事件（事件源①）
3. 服务端按行内鉴权调用 CRM API（REST/内网 API 网关）拉取客户信息
4. 组装客户信息卡（octo/v1 展示卡）发送到协作群：
   FactSet：客户姓名（脱敏）/ 客户等级 / 持有产品 / 近30天咨询记录 / 风险标签
   + Action.OpenUrl（跳转 CRM 完整档案，行内 SSO 免登）
5. 审计闭环：
   - 查询指令（坐席的消息）+ 返回卡片内容 全量落 OCTO 消息库
   - 客服中台同步记录结构化查询日志（坐席工号/时间/查询客户/返回字段）
     供合规部门审计"谁在何时查了哪个客户"

脱敏规则由方案定义（姓名打星、证件号/卡号只显尾号）——🔴 OCTO 无内置动态脱敏能力，脱敏逻辑在客服中台组装卡片时实现。
卡片用 octo/v1 展示 profile（无输入交互），降低误操作面。
若行内要求查询留痕更严格，可要求坐席走工单系统查询（工单自带审计），OCTO 卡片仅展示工单号摘要。

5. 部署架构建议

5.1 部署档位与演进路径

阶段	档位与形态	资源（⚠️ 经验估算，非承诺）	说明
PoC（4周）	最小化单机部署（Docker Compose）	资源规格以PoC压测为准	核心 7 件套：octo-server + octo-web + octo-admin + WuKongIM + MySQL 8 + Redis 7 + MinIO；Docs/Drive/Fleet/Marketplace 可不启用（场景二 §2.5）
试点（2个月）	最小化单机部署 → Kubernetes高可用集群部署过渡	视坐席放量与实测数据调整	试点期可继续单机或小规模集群；根据 §7 指标实测决定扩容节奏
生产（全渠道）	Kubernetes高可用集群部署（Helm）	以交付方案为准	高可用拓扑/副本数以交付方案为准（红线卡 Y3）；MySQL 建议主从

🔴 档位硬口径：资源规格档位均为经验估算，无官方证据（PS-06 纠偏），售前不得作为承诺报出；具体吞吐上限必须 PoC 压测确定（business 限流桶阈值由 system_setting 动态配置，源码无硬编码默认值，BA-07 待确认——见 §8 硬口径#6）。

5.2 网络分区与 DMZ 部署考量

┌────────────────────────────────────────────────────────────────┐
│ 互联网区                                                        │
│   客户 APP / 微信公众号 / 小程序入口                              │
└──────────────┬─────────────────────────────────────────────────┘
               │ HTTPS 443 only
┌──────────────▼─────────────────────────────────────────────────┐
│ DMZ 区                                                          │
│   WAF → 渠道适配层（集成商开发：微信适配 / APP 网关）              │
│   → nginx（OCTO 统一入口，TLS 终结，单端口 28443）                │
│   ⚠️ 渠道适配层为集成商开发，OCTO 不内置                          │
└──────────────┬─────────────────────────────────────────────────┘
               │ 指定端口白名单（防火墙策略）
┌──────────────▼─────────────────────────────────────────────────┐
│ 行内应用区                                                       │
│   OCTO 栈：octo-server / WuKongIM / MySQL / Redis / MinIO       │
│           / nginx（内网入口）/ octo-web / octo-admin             │
│   客服中台 Bot 服务（集成方部署，双实例高可用）                     │
│   行内 LLM 推理服务（或已合规审批的 LLM API 出口）                 │
│   统一知识库（OCTO Docs profile 或行内既有知识库）                 │
└──────────────┬─────────────────────────────────────────────────┘
               │ 东西向白名单（行内 API 网关）
┌──────────────▼─────────────────────────────────────────────────┐
│ 行内核心区                                                       │
│   CRM / 工单系统 / 核心业务系统 / BI 看板 / IAM(4A)               │
└────────────────────────────────────────────────────────────────┘

#	考量	说明
1	OCTO 部署位置	OCTO 全栈部署在行内应用区，不跨区；对外仅 DMZ nginx 暴露 443。若坐席仅行内网络办公，OCTO 内网入口可不对 DMZ 暴露，进一步缩小攻击面
2	🔴 MinIO downloadURL 必须对坐席/客户端可达（红线卡 R11）	文件/图片下载是客户端直连 MinIO 预签名 URL（302 重定向），不经 server 代理。金融内网部署最常见事故：防火墙未放行对象存储域名 → 聊天图片/附件打不开。DMZ 与应用区间防火墙清单必须显式列出 MinIO 域名/端口
3	客户端连接	客户端长连接直连 WuKongIM（WS 25200 / TCP 25100）；经 nginx `/ws` 反代则仅需 443（场景文档 G3；部署形态总览）。坐席 PC 客户端（Electron/Web）走内网入口即可
4	与行内系统集成	客服中台 ↔ CRM/工单走内网东西向 REST（经 API 网关，白名单 + mTLS/签名），不出网；OCTO 本身不直连核心区系统
5	LLM 数据不出内网	🔴 智能问答必须对接行内 LLM 推理服务或已完成合规审批的 LLM API。注意：OCTO summary 模块默认调外部 LLM（claude 系），金融场景建议不启用 summary 依赖外部 LLM 的默认配置，问答 LLM 由客服中台直连行内服务（场景一 §1.8 硬口径#15）
6	SSO	OIDC 对接行内 IAM/4A；🔴 若行内 IdP 仅 SAML/LDAP，需 Keycloak 等做协议桥接，不承诺原生直连（权限模型 §5.2）
7	数据不出内网审计	全部数据（消息/附件/卡片）落行内 MySQL/MinIO；LLM 请求内容与响应由客服中台在行内留痕（注意评估行内 LLM 服务的日志保留策略）

5.3 租户与实例隔离策略

🔴 硬口径：OCTO 多租户为同库逻辑隔离（space_id 查询层过滤），非物理隔离（权限模型硬口径③）。该客户若有多个法人主体/子公司需强隔离（如银行 + 消金子公司），每主体独立部署一套实例，不做"同实例强隔离"承诺。
Space 为唯一租户单元，无 organization 层级（硬口径①）。本方案推荐单 Space 部署：坐席、运营、质检、管理员同 Space，用群组/Thread 组织日常协作，术语统一使用 Space。
权限边界：Space 三档角色（member/admin/owner）+ 群三档角色（普通/群主/管理员）+ 系统角色（admin/superAdmin/dashboardReader/marketAdmin）。🔴 无自定义 RBAC（硬口径②）——"坐席组长/质检员/合规审计员"等岗位差异化权限需在客服中台/工单系统侧实现，不得承诺 OCTO 侧自定义角色。
权限变更缓存：成员资格变更最长 60s 缓存延迟（Redis TTL）——坐席离岗权限回收场景需在 SLA 中评估该窗口（权限模型 §2.4）。
Bot 不占 Space 座位：Bot 无 space_member 行，不占人头数（权限模型 §3.2）；本方案 License/资源按人类账号（坐席+运营+管理）估算。
User Bot 权限边界：FAQ/业务/知识 Bot 均为 User Bot（bf_），加群后是普通群成员，只能操作自己加入的群；GET /v1/bot/groups 只返回自己加入的群（红线卡 R3）。

6. 实施路径

6.1 Phase 1：PoC（4 周）

周	工作项	关键产出
W1	环境搭建：Docker Compose 核心 7 件套（M 档单机）+ OIDC SSO 联调 + 行内网络/防火墙策略落地（含 MinIO 放行验证）；BotFather 创建 3 类 Bot，`bf_` token 发放与保管规范（token = Bot 全部权限凭证，仅存服务端密管系统）	可用的 PoC 环境 + Bot 身份就绪
W2	FAQ 接待 Bot 开发：长轮询框架（§4.4.2）+ 行内 LLM 对接 + 知识库 RAG（首批 200 条高频 FAQ 语料）+ 文本/展示卡回复	旅程 1 基本闭环
W3	卡片交互开发：3 张卡片模板（§4.3）+ card_action 处理 + 动态改卡；429 限流压测：business 桶实际阈值以部署 config 为准（Y6），实测单 Bot 吞吐上限与峰值并发模型	旅程 1/2 闭环 + 吞吐实测报告（不承诺 SLA，仅记录基线）
W4	工单系统/CRM 接口联调（REST 建单 + 群入站 Webhook 状态通知）；演示验收：4 条用户旅程全流程演示 + 安全整改项清单	PoC 验收报告（含实测数据 + 风险清单）

6.2 Phase 2：客服试点（2 个月）

月	工作项	关键策略
M1	首批坐席试点上线：FAQ Bot 灰度放量（内部员工试用 → 小比例客户流量 → 按自助解决率逐级放量）；工单集成生产化；审计留痕验证（消息 + card_action 落库可查询、可按工单号/坐席/客户三向检索）；DMZ/防火墙策略生产化复核	灰度放量节奏由自助解决率与投诉率双指标驱动
M2	业务 Bot 全业务域铺开（挂失/查询/预约等按优先级）；坐席知识辅助 Bot 上线；满意度评价卡全量采集；ROI 指标基线固化（§7 框架）；容量复核（是否升 Kubernetes高可用集群部署）	每周运营复盘：FAQ 未命中问题回流知识库运营流程

6.3 Phase 3：全渠道推广

工作项	说明
渠道适配层建设	微信公众号/小程序适配、电话 CTI 中间件对接（集成商开发，OCTO 不内置渠道适配器）；渠道消息归一到客服中台统一处理
知识库统一治理	电话/APP/微信三渠道知识口径收敛到统一知识库；建立知识运营流程（未命中问题 → 知识补充 → 评审发布 → Bot 生效）
全坐席推广	坐席全量；按 Kubernetes高可用集群部署扩容（以试点实测数据定拓扑，交付方案为准）
持续运营	月度 CSAT 复盘、限流水位监控（X-RateLimit-Remaining 告警）、token 轮换管理（/revoke 流程演练）

7. ROI 价值分析框架

🔴 原则：本章只给测算框架与指标体系，不代入任何假设数字，不承诺任何 ROI 数值。 所有变量需以 PoC/试点实测数据代入；售前阶段如客户要求测算，应明确标注"基于客户试点数据的估算，非产品承诺"。

7.1 三维度指标框架

维度	核心指标	采集方式	基线与对比
客服效率	FAQ 自助解决率；人工转接率；平均首次响应时长（FRT）；平均处理时长（AHT）；坐席日均承接量	客服中台会话日志（event 全量落库）+ 工单系统统计	PoC 期采"纯人工"基线；试点期采"Bot+人工"对比值
人力成本	重复性咨询自动化释放的人力当量	测算框架见 7.2	需客户试点数据代入
客户满意度	CSAT（满意度评价卡直接采集，旅程 1/2 闭环）；首次解决率（FCR）；投诉率；NPS（可选，行内既有调研体系）	评价卡 card_action 数据 + 行内投诉工单统计	评价卡数据即采集闭环，无需额外调研成本

7.2 人力成本测算框架（公式示例，不代入数字）

年化可释放人力当量 ≈
  日均咨询量 × 重复性咨询占比 × Bot 自助解决率 × 单次人工处理时长
  ÷ 坐席日均有效工时
  − Bot 运营投入当量（知识库运营 + Bot 保障人力）

其中：
· 日均咨询量、重复性占比：客户画像给定（本案例描述为大量咨询、重复性问题占比高）——需客户实际数据校准
· Bot 自助解决率：⚠️ 唯一未知变量，受知识库质量/大模型回答质量/客户接受度三因素影响，
  必须以试点实测为准，售前不得预设
· Bot 运营投入：知识运营是持续成本，必须计入（否则测算失真）

7.3 汇报口径建议

对客户汇报用"效率维度实测对比"（自助解决率、FRT 缩短）作为主证据链，人力成本换算为辅。
所有对外数字标注采集口径与时间窗口；跨渠道口径（电话 AHT vs 在线 AHT）分开统计，不混算。
满意度数据注意"评价卡参与率"偏差（只评价的人是否代表全体），必要时抽样补研。

8. 售前注意事项（🔴 硬口径，违反即交付事故）

以下 15 条硬口径全部来自源码确认文档，售前沟通、方案书、投标应答均不得违背。客户追问时统一话术：「这个能力当前版本的边界是 XXX，具体方案我们交付团队会评估。」

#	🔴 硬口径	禁止说法	正确口径	来源
1	Bot 对网盘零面	"Bot 可以读写网盘/把网盘文件作为知识源"	`/v1/bot/drive/` 路由全仓 0 命中（源码确认）；Bot 只能操作 `chat/` 命名空间聊天附件；知识库文件源需经用户转存等链路或由客服中台直连行内知识库	Drive网盘模块 v0.3 P0 结论；快速入门 §1.2
2	卡片硬限制	"卡片随便多大、元素随便加"	type=17：payload ≤512KiB、节点 ≤200、深度 ≤16；`card_version`/`version` 必须 "1.5"；元素限白名单（8 展示 + 6 输入 + 4 动作）；不支持 Action.Execute/auto-refresh；limits 以运行时 manifest 为准（先 `GET /v1/bot/card/profile` 探测）	错误码与排障 v1.0 §三；红线卡 R8
3	Bot 是普通群成员	"Bot 可以跨群发消息/拉所有群列表/有超管权限"	Bot 加群后是普通成员；只能操作自己加入的群；解散群/设管理员/禁言/改群头像均不对 Bot 开放	红线卡 R3/R4；快速入门 §1.2
4	限流与 429	"不会限流/限流阈值是固定 X"	三桶限流按 robotID 隔离（business/heartbeat/register）；business 阈值由 system_setting 动态配置，无公开默认值承诺；收到 429 读 Retry-After 指数退避 + 用批量接口（members ≤200 / message_ids ≤100）+ 错峰 + 卡片合并消息	错误码与排障 v1.0 §四；红线卡 Y6
5	App Bot 边界	"App Bot 也能进群干活"	App Bot（`app_`）仅 DM 私聊（群端点完全拒绝，`app_bot_dm_only`）；未发布状态调 API 返回 403 `bot_unavailable`。本方案群聊场景全部用 User Bot（`bf_`）	错误码与排障 v1.0 §2.3/§7.2；权限模型 §3.1
6	性能不承诺	"支持 X 万并发/QPS 保证 Y"	无官方性能基准数据，不承诺具体 QPS/并发/SLA；资源规格档位为经验估算；具体吞吐必须 PoC 压测实测	红线卡 R10；场景文档 PS-06
7	事件通道是长轮询	"Bot 通过 WebSocket / Webhook 收事件"	Bot 收事件 = `POST /v1/bot/events` HTTP 长轮询（wait ≤30s）；不存在 Bot 入站 Webhook；平台级出站 Webhook（/v1/webhook 等）订阅模型待确认，不作承诺	红线卡 R13；快速入门三大易错点①
8	Bot 收不到的事件	"Bot 可以监听坐席上线/群成员变化/表情回应"	Bot 收不到 reaction、群成员变动、加入/退出/被移除、网盘分享事件（源码无投递点）——坐席排班提醒等场景须由客服中台/工单系统触发，不能设计为"Bot 监听群事件"	快速入门三大易错点③；Webhook与事件订阅 §3.2
9	逻辑隔离非物理隔离	"多租户物理隔离/数据沙箱级隔离"	多租户为同库逻辑隔离（space_id 过滤）；金融强合规场景一客户一实例独立部署	权限模型硬口径③
10	无自定义 RBAC	"可以自定义坐席组长/质检员角色"	角色为硬编码枚举（Space 三档/群三档/系统四档）；岗位差异化权限在客服中台/工单系统侧实现	权限模型硬口径②
11	AI 能力边界	"OCTO 内置智能客服/NLP 意图识别开箱即用"	OCTO 提供 Bot 运行平台 + 消息/卡片/事件底座；智能问答 = 集成方对接行内 LLM + 知识库 RAG 自行实现；"能构建" ≠ "点一下就有"	场景文档 PS-07 纠偏
12	sendMessage 单目标单条	"一次 API 调用批量群发"	sendMessage 单目标单条；批量触达需循环调用 + 限流控制（批量接口仅限群成员/消息 ID 等批量操作）	红线卡 R6；错误码 §4.5
13	SSO 协议边界	"原生支持 SAML/LDAP/企微钉钉飞书扫码"	原生仅 OIDC/OAuth2；SAML/LDAP 需 Keycloak 等 IdP 桥接；不支持 SCIM 自动 provisioning	权限模型 §5.2
14	语音边界	"Bot 可以发语音回复/支持音视频客服"	Bot 不能发送语音消息（无 TTS，type=4 Bot 不可发）；语音转写（ASR）为输入侧能力且需行内 ASR 引擎；不是音视频会议/呼叫中心系统	消息类型与发送 v1.0 §3.5；场景一硬口径#8
15	MinIO 下载直连	"文件下载可以全走 server 代理不暴露 MinIO"	下载走 302 → 预签名 URL，客户端直连 MinIO，downloadURL 必须对坐席/客户端网络可达——防火墙清单必须显式放行	红线卡 R11

9. 已知限制与待确认项

以下事项在方案承诺前必须逐项确认；集中追踪于 `00-inbox/open-questions.md`，PoC 启动前应由产品管家/Owner 复核闭环。

9.1 影响本方案的待确认项（引用 open-questions.md）

编号	待确认项	对本方案的影响	缓解设计
P1-03	长轮询事件保留 TTL（断点续传窗口时长）	客服中台宕机超过窗口可能丢事件	事件先落库再 ACK；断线尽快重连；`/v1/bot/messages/sync` 补拉兜底；PoC 实测窗口时长
P1-06	Webhook 回调失败重试机制（次数/间隔/签名）	工单状态推送可靠性	群入站 Webhook 仅作坐席通知辅助通道；业务关键流走客服中台 ↔ 工单 REST 直调，不依赖出站 Webhook
P1-05	business/heartbeat 限流桶默认参数	峰值吞吐规划	PoC 压测实测；部署期从 system_setting 确认配置值
P1-09	Bot token 过期策略（有效期/刷新机制）	token 生命周期管理	假设长期有效 + 泄露即 /revoke；PoC 验证实际策略
P1-04	上传端点命名差异（`/v1/bot/upload/credentials` vs `/v1/bot/upload/presigned`）	附件上传集成	以线上实际返回为准，先测 STS credentials 端点
P1-08	消息 content_too_large 具体阈值	长文本答案（如条款全文）发送	长内容改用卡片或文件消息（type=8，先上传后发送）；PoC 实测阈值
BA-07	business 桶 RPS/日配额默认值	同 P1-05	同上
BA-QUOTA	Bot 加群数量配额	多坐席组群、多 Thread 的规模上限	以 system_setting 配置为准；试点期监控

9.2 已确认的产品边界（按已知限制管理，非待确认）

边界	影响	方案对策
群聊普通消息（不 @Bot）是否投递给 Bot：待确认（Webhook与事件订阅 §3.3）	FAQ Bot 若设计为群聊模式有风险	FAQ Bot 定为 DM 私信模式（事件源①已源码确认）；群内交互一律 @Bot
无独立 `in_reply_to` 字段，引用在 payload 内	多轮会话上下文解析	客服中台自行解析 payload 内 reply 结构；会话状态以 session_id 为主键管理，不依赖 reply 链
撤回消息独立端点未见路由	坐席撤回误发内容	依赖消息编辑（仅 Bot 自己的消息）；人工消息撤回走客户端；审计策略按"不可撤回留痕"设计（反而利好合规）
消息撤回/编辑的时限语义待确认	留痕口径	审计口径定义为"以落库消息为准"，编辑留版本痕迹由客服中台日志承担
删号无 GDPR 导出功能	监管检查数据提取	审计导出基于 MySQL 定制开发（ETL 到行内审计平台），纳入实施工作量
无公开 OpenAPI/Swagger 规范	集成方开发对接口径	以知识库 Bot-API 系列文档为开发依据；PoC W1 做接口冒烟验证
卡片无独立校验端点	卡片开发调试	开发环境先发最简测试卡，逐步加元素定位问题（错误码 §3.4）
动态改卡 card_seq CAS 为乐观锁	多坐席并发改同一张卡	以工单系统状态机为唯一权威，OCTO 卡片仅为展示层；客服中台对改卡失败做重试
Bot 文件上传仅 `chat/` 命名空间（不进网盘）	课件/话术文件分发	知识文件存行内知识库/Docs；聊天附件仅做临时传输

10. 附录：涉及文档索引

#	文档	路径	本文引用点
1	Bot API 快速入门 v1.0（Q9 源码确认升级）	`04-api-integration/Bot-API快速入门-v1.0.md`	三大易错点（长轮询/bf_前缀/收不到的事件）、能力清单、端点清单、限流、OBO、Token 管理
2	Bot API 错误码与排障 v1.0	`04-api-integration/Bot-API错误码与排障-v1.0.md`	卡片硬限（512KiB/200节点/深度16/card_version="1.5"）、403 系列（bot_unavailable/app_bot_dm_only）、429 限流与批量接口、长轮询排障
3	消息类型与发送 v1.0	`04-api-integration/消息类型与发送-v1.0.md`	sendMessage 信封、type=17 双 profile、元素白名单、动态改卡、@mention、文件消息流程
4	Webhook 与事件订阅 v1.0	`04-api-integration/Webhook与事件订阅-v1.0.md`	长轮询机制、card_action/事件 payload、群入站 Webhook、出站 Webhook 待确认边界、cursor/ACK 最佳实践
5	OCTO 典型应用场景 v1.0（场景二）	`05-use-cases/OCTO典型应用场景-v1.0.md`	场景二基础（痛点/能力对应/模块清单/部署建议）、PS-06/07 纠偏（档位经验估算/AI 非成品）
6	权限模型与鉴权体系 v0.1	`02-architecture/权限模型与鉴权体系.md`	三条安全硬口径（Space 唯一租户/无自定义 RBAC/逻辑隔离）、Bot 权限边界、SSO 支持矩阵、60s 缓存延迟
7	售前红线卡 v0.1	`08-presales-delivery/售前红线卡-v0.1.md`	R3/R4/R5/R6/R8/R10/R11/R12/R13/R14、Y3/Y6、G3/G7/G10 等 15 条硬口径引用
8	Drive 网盘模块 v0.3	`01-product/模块说明/Drive网盘模块.md`	P0 结论：Bot 对网盘零攻击面（/v1/bot/drive/ 0 命中、chat/ 前缀三重隔离）、Drive 仅 Web 端
9	生产资源规格建议 v1.0	`03-deployment-ops/生产资源规格建议-v1.0.md`	M/L 档资源参考（⚠️ 经验估算）
10	待确认项统一追踪清单	`00-inbox/open-questions.md`	§9 待确认项编号来源（P1-03/P1-04/P1-05/P1-06/P1-08/P1-09）

版本记录

版本	日期	变更	作者

11. 客户价值亮点

11.1 核心价值亮点

11.2 可复用售前话术

话术1："在行内私有化部署的智能对话机器人运行平台与统一消息通道上，构建'FAQ自动接待+业务办理Bot+人工坐席兜底'三层客服体系，全量对话在行内留痕可审计，不动存量客服系统就能让AI落地。"
话术2："OCTO 提供消息通道+卡片渲染+事件回调+全量留痕的平台底座，FAQ 智能问答、业务流程编排由你们的集成商对接行内大模型和知识库开发——平台能搭建，但不是点一下就有现成智能客服，边界我们一开始就讲清楚。"

11.3 关联阅读

对应价值卡片：[金融行业客户价值卡片](../../08-presales-delivery/客户价值卡片/价值卡片-金融-v1.0.md)
售前红线卡：[售前红线卡-v1.0](../../08-presales-delivery/售前红线卡-v1.0.md)
Bot API 快速入门：[Bot-API快速入门-v1.0.md](../../04-api-integration/Bot-API快速入门-v1.0.md)

相似行业参考

医疗集团案例（私有化合规IM与医护协作，适合金融机构合规/留痕/审计场景参考）：[案例5-医疗集团-私有化合规IM与医护协作.md](./案例5-医疗集团-私有化合规IM与医护协作.md)

版本记录（v1.1 更新）

版本	日期	变更	作者
v1.1	2026-09-22	精修：更新元信息（octo_version: v2026.09+待确认 / sensitivity: internal / source 加入价值卡片）；交叉一致性修正（部署表述统一为"Kubernetes高可用集群部署/最小化单机部署"，术语统一 Bot=智能对话机器人）；PS-06 规模数字柔化（坐席数/日均量/硬件档位）；PS-07 "准确率"改为"回答质量"；追加第11章客户价值亮点；补充相似行业参考	twb-knowledge-octo
v0.1	2026-09-22	初版。基于 Bot-API v1.0 系列（Q9/Q13 源码确认级）、权限模型 v0.1、售前红线卡 v0.1、Drive v0.3、场景文档 v1.0 场景二推导编写。10 章节齐全：客户画像/痛点映射/方案概览/详细设计/部署架构/实施路径/ROI 框架/售前硬口径/已知限制/文档索引。confidence: medium（能力推导型，非客户实证）	twb-knowledge-octo