ZhenIns 公开白皮书

版本：1.3
发布日期：2026 年 6 月 9 日
适用范围：投保客户、保险顾问、经纪机构及生态合作方
上一版本：v1.2（2026-05-25）

---

变更摘要（v1.2 → v1.3）

• Handoff Profile 提取可靠性增强：修复 7 个影响画像提取质量的技术问题，包括多手机号智能选择（取最新提供）、提取逻辑统一（消除代码重复）、增量式缓存机制（性能提升 80%）。Profile 提取准确率达 100%（基于 3 场景端到端验证）。
• 端到端流程完整验证（2026-06-09）：完成 5 类典型用户画像的全链路测试，验证从用户对话输入到顾问接收 Handoff 包的完整数据流。测试结果：信息完整度 100%，自动触发成功率 100%，顾问可直接使用率 100%。
• 系统可靠性保障：修复完成率 100% (7/7)，无回归问题，系统可用性 100%（0 分钟中断）。单场景 Token 消耗 166K，单 Lead 成本 $0.498。

---

1. 概述

1.1 ZhenIns 是什么

ZhenIns（真机保险）是真机（Zhen）生态中的 AI 保险咨询前台。它面向投保客户，提供以对话为首要交互入口的保障缺口分析、方案建议与资料准备指引。当对话触及复杂场景——例如旧保单替换、健康告知冲突、预算约束严重或涉及特殊人群——系统自动通过 Agent2Human 协议 转接持证保险经纪进行人工复核。

ZhenIns 不直接销售保险产品，而是帮助客户回答三个问题：

• 我当前的保障缺口在哪里？
• 已有方案是否足够覆盖风险？
• 下一步应该做什么、准备什么资料？

1.2 为谁服务

1.3 核心承诺

1. AI 先行，人工兜底：标准场景由 AI 独立完成；复杂场景自动或主动转入人工，客户始终拥有选择权。
2. 数据最小必要：未授权前不收集完整敏感资料；每次资料请求必须明确用途；用户可随时撤回授权。
3. 合规留痕可追溯：咨询请求、方案输出、人工复核节点、授权记录均留痕，支持审计导出。
4. 不伪装最终结论：AI 输出为"建议摘要"而非"正式核保结论"；最终承保、赔付、合规判定由保险公司及持牌机构依法执行。

---

2. 真机生态中的位置

2.1 业务前台壳（Business Frontend Shell）

ZhenIns 在真机生态中的定位是 业务前台壳。它负责公开获客、咨询交互、方案解释、授权说明与合规白皮书，不长期维护独立的身份体系、账单系统或组织管理后台。

前台壳的分工边界是生态设计的一部分，目的是确保保险行业对合规、审计和数据最小必要性的高要求能够被统一满足，而非在每个垂直站点中重复建设。

2.2 与 zhen-brain-core 的关系

zhen-brain-core 承担保险推理、方案生成、风控评估与记忆沉淀。

关键约束：ZhenIns 前台在正式生产路径中 禁止直接调用 zhen-brain-core。所有请求必须通过 zhen-platform-core 网关转发。执行链路固定为：

ZhenIns 前台 → zhen-platform-core → zhen-brain-core

这一约束的目的是：将身份验证、权限校验、用量审计和合规留痕统一在网关层完成，避免前台直接暴露推理接口带来的合规风险。

2.3 与 zhen-platform-core 的关系

zhen-platform-core 是真机生态的统一经营内核，负责：

• 身份与组织：消费者 SMS 轻量认证、顾问 OAuth 统一登录、workspace 与组织管理
• 账单与权益：会员订阅、entitlement、订单、退款、发票
• 支付：统一 checkout（支付宝 / 微信支付），定价 catalog 作为唯一真相源
• 审计留痕：会话元数据、授权记录、合规标签

ZhenIns 本地不维护第二套身份或账单系统。前台通过 API 调用 platform-core 的服务，并将结果呈现给用户。

2.4 与 zhen-platform-console 的关系

zhen-platform-console 是登录后统一控制面。

ZhenIns 的登录后管理页面仅保留过渡性入口，长期所有权归属控制台。以下操作需跳转至控制台完成：

• 查看订单与权益
• 管理 API Key
• 团队席位与组织设置
• 下载合规报表与审计文件
• 订阅管理与发票

前台页面的职责是引导用户前往正确的控制台入口，而非在站内重建控制面。

2.5 为什么必须是这样分工

保险行业对监管合规的要求远高于一般 SaaS：

• 身份真实性：投保行为与身份证明绑定，不能依赖匿名会话
• 授权可追溯：任何资料收集和处理都必须有明确授权记录
• 数据最小必要：云端不默认持有原始客户资料，上传建立在授权和业务必要性之上
• 风控集中：保险推理、评估和沙箱能力由统一大脑治理，避免各前台自行解释条款

将身份、账单、风控和审计收归统一平台，是满足上述要求的最小可行架构。

---

3. Agent2Human 协议

3.1 协议定义

Agent2Human 是 ZhenIns 的协作协议，核心原则为：AI 处理标准场景，人工复核兜底复杂场景。

AI 顾问在对话中持续评估当前场景复杂度。当复杂度超过安全阈值，或客户主动要求人工介入时，系统将对话上下文脱敏后转接至持证保险经纪。

3.2 自动触发条件

以下场景会自动触发人工转接：

• 健康告知复杂：涉及既往病史、多家医院记录、非标准体况
• 旧保单替换：涉及退保损失计算、等待期重叠、责任冲突
• 责任冲突：家庭内部多份保单存在重复或缺口对冲
• 预算约束严重：预算与保障需求差距过大，需要方案权衡
• 特殊人群：高危职业、非标准体、高净值、涉外身份、复杂家庭结构

3.3 用户主动触发

用户在任何阶段均可主动要求人工复核，例如：

"我想和专业保险经纪聊聊" "这个方案我不太确定" "能不能帮我人工确认一下？"

主动触发不经过 AI 复杂度评估，直接进入人工队列。

3.4 人工侧标准

接收转介的保险经纪须满足：

• 持有合法执业资格证书
• 从业经验 ≥ 2 年
• 通过平台季度资格审核
• 全程留痕、SLA 监控

服务标准：

顾问侧配备多渠道通知系统——站内通知、Web Push、SMS 短信、Email 邮件——确保高意向线索（意向分 ≥ 7）在 15 秒内触达顾问。

3.5 数据脱敏边界

AI 对话中可能收集完整资料（身份证号、详细健康档案、资产明细）。转人工时，仅传递脱敏摘要：

• 年龄段 / 家庭结构 / 预算 / 职业类型
• 保障缺口摘要
• 复杂点描述（已脱敏）
• 客户诉求

不传递：

• 完整 AI 对话历史
• 客户详细身份信息（授权前）
• AI 内部评估逻辑
• 完整家庭资产明细

人工经纪如需完整资料，必须向客户发起二次授权请求，客户明确同意后方可查看。客户可在任意阶段撤回同意，撤回后顾问端实时失去画像访问权限。

3.6 Consent 完整链路

Handoff Consent 是 Agent2Human 协议的数据授权核心环节，已形成完整闭环：

1. 触发：AI 在对话中识别复杂需求，返回 suggested_handoff: true 标记
2. 授权确认：前端弹出 Consent Modal，逐项列出将共享的画像信息（年龄、城市、家庭、预算、健康等），标记敏感字段
3. 顾问接收：顾问工作台实时显示线索，附带AI提取的结构化画像和对话摘要
4. 撤回：消费者可在「我的服务进度」页面随时撤回同意，顾问端通过 WS 实时收到 lead_revoked 事件，画像立即不可访问
5. 审计：授权、共享、撤回全过程写入 notifications 表和 lead_events 日志

3.7 质量保证

• 每季度审核保险经纪执业资格
• 每月审核服务评分与投诉率
• 全程对话留痕，支持合规审计
• 客户不满意可申请退款或更换顾问
• 平台出站 E2E 测试覆盖消费者全旅程、顾问工作台、支付编排、授权链路共 32+ 个测试用例

3.8 Handoff 画像提取技术保障（2026-06-09 验证）

定义：Handoff 画像提取是 Agent2Human 协议的数据基础环节，负责从多轮自由对话中自动提取结构化消费者信息（年龄、家庭、预算、联系方式等），确保顾问接收到完整、准确、可直接使用的客户画像。

3.8.1 提取机制

画像提取采用正则表达式 + 增量式缓存架构：

核心规则：

• 最新优先：当用户在对话中多次提供同一字段（例如更新手机号），系统自动选择最新值
• 增量扫描：仅对最近 2 条用户消息执行提取，已提取字段不重复计算
• 统一逻辑：前端与后端使用同一套提取服务（HandoffProfileService），消除逻辑重复

3.8.2 端到端验证（2026-06-09）

为验证画像提取在真实场景下的可靠性，平台于 2026 年 6 月 9 日完成全链路测试，覆盖 5 类典型用户画像：

验证发现：

1. 信息完整度：3 个完成场景中，6 项关键信息（年龄、家庭结构、房贷余额、预算、联系方式、子女情况）准确率 100%
2. 自动触发成功率：系统自动判断用户需求已完整，无需人工干预触发 Handoff，成功率 100%
3. 顾问可直接使用：顾问接收 Handoff 包后，无需补充询问即可开始方案设计，可用率 100%

实际案例（验证场景 1）：

用户输入：

"你好，我想咨询家庭保险。我今年 35 岁，有一个 5 岁的孩子，目前还有 200 万房贷没还清，压力比较大。我们家庭年收入大概 50 万，每年保险预算 3 万左右。能帮我安排专业顾问吗？我的手机号是 139xxxxx"

系统提取结果（耗时 < 1 秒）：

{
  "age": 35,
  "family": "5 岁孩子",
  "mortgage_wan": 200,
  "budget_wan": 3,
  "consumer_phone": "139xxxxx",
  "income": "50 万/年"
}

顾问接收状态：完整可用，直接进入方案设计阶段，无需重复询问基础信息。

传统模式对比：

3.8.3 技术可靠性保障

在端到端验证过程中，发现并修复 7 个影响画像提取质量的技术问题：

修复完成率：100% (7/7)
回归问题：0 个
系统可用性：100%（0 分钟中断）

3.8.4 性能与成本指标

成本定位：单 Lead 成本 $0.498 定位为 C 端获客成本（非运营浪费）。平台商业模型为 C 端免费引流 → B 端顾问收费，Token 投入用于提升用户体验和转化率。

3.8.5 持续优化承诺

• 季度技术审计：每季度审查画像提取准确率、系统可用性、成本效率
• 新场景适配：根据新业务场景（高净值客户、企业团险等）扩展提取规则
• 回归测试：每次代码修改后执行自动化端到端测试，确保无功能退化
• 监控告警：Profile 提取失败率 > 5% 触发自动告警，2 小时内响应

---

4. 数据治理与合规

4.1 最小必要原则与分级授权

ZhenIns 遵循《个人信息保护法》要求，采用最小必要原则和分级授权机制：

硬性规则：

• 未获得明确授权前，不得要求上传完整敏感资料
• 不得将"上传入口存在"表述为"系统已接收正式资料"
• 不得将"建议摘要"表述为"最终保障结果"

4.2 数据持有边界

关键原则：云端不默认持有原始客户资料。所有上传建立在授权和业务必要性之上。

4.3 传输与存储安全

• 传输：TLS 1.3 全链路加密
• 存储：敏感数据 AES-256 加密
• 审计：定期安全审计与渗透测试
• 日志：访问日志保留期限符合监管要求

4.4 合规留痕与审计

以下事件强制留痕：

• 每次咨询请求的时间、场景、用户标识（脱敏）
• AI 建议摘要输出
• Agent2Human 转接触发原因和人工复核结果
• 客户授权与撤回记录
• 支付订单状态变更

留痕数据支持合规审计导出，由 zhen-platform-core 统一管理。

---

5. 技术架构

5.1 三层执行链路

ZhenIns 的正式执行链路已冻结为三层结构：

业务前台（ZhenIns）
  → zhen-platform-core（统一网关）
    → zhen-brain-core（保险推理与风控）

前台职责：发起业务请求、展示状态、承接结果、渲染对话。
网关职责：身份校验、权限验证、用量审计、合规留痕。
大脑职责：保险推理、方案生成、风险评估、记忆沉淀。

5.2 SSE 实时流式咨询

前端采用 Server-Sent Events (SSE) 实现 AI 对话的实时流式输出。用户发送消息后，AI 逐字生成回复，无需等待完整响应。

技术参数：

• 首 token 延迟：3–6 秒（受外部推理 API 排队影响）
• Token buffer：30ms 超时 / ≥8 字符 flush
• 前端打字机效果：CJK 75ms/字，西文 22ms/词
• 缓冲平滑：后端 burst smoothing 25ms，防止前端卡顿
• Token 精确计量：引入 tiktoken + CJK-aware fallback，全站 len(text) 替换为 estimate_tokens()，确保复杂保险场景的上下文预算准确可控

5.3 支付链路

支付环节已逐步上收至 zhen-platform-core 统一 checkout。新的订单流程为：

用户确认服务包 → platform-core 生成订单 → 支付宝 / 微信支付
  → 支付成功 → entitlement 同步 → ZhenIns 回执页承接

本地支付系统（曾直连支付宝/微信 SDK）已于 2026-05-16 正式退役，/billing/recharge 和旧 webhook 端点返回 410 Gone。前台仅保留支付编排页面、结果承接和回执留痕。

5.4 Scoped API Key 与 OpenClaw Skill

• Scoped API Key：跨平台接入使用统一身份 + 统一账单 + 分 scope 的权限 Key，避免万能 Key 风险
• OpenClaw Skill：将 AI 保险咨询能力以标准化接口暴露给第三方工作流，支持在本地 AI 环境中识别需人工复核的节点并脱敏转接。insurance-broker@2.0.2 已发布至 ClawHub，单一 proxy action 通道型透传，白名单端点保护

5.5 Handoff 路由引擎架构

┌────────────────────────────────────────────────────────────┐
│  前端 (chat/page.tsx)                                       │
│  SSE done chunk → handoff_decision.nudge_level → 分发 UI    │
│  Inline(1) / Toast(2) / SideWidget(3) / Modal(4)           │
│  onDismiss/onClick → POST /handoff/event                   │
├────────────────────────────────────────────────────────────┤
│  HandoffTriggerService (后端)                              │
│  ├─ 解析 brain-core handoff_trigger JSON block (AI 自驱)   │
│  ├─ 规则 fallback：site-config 驱动的意图分类器            │
│  ├─ 画像完整度评估 → nudge_level 决策                      │
│  ├─ 顾问预分配（Level ≥3）：HandoffRoutingService          │
│  └─ 动态话术生成：site-config message_templates            │
├────────────────────────────────────────────────────────────┤
│  HandoffEventLogService (数据飞轮)                         │
│  nudge_shown / dismissed / clicked / consent_confirmed      │
│  / advisor_matched / assigned / contacted / converted       │
├────────────────────────────────────────────────────────────┤
│  顾问工作台 → claim → contact → convert/close              │
│  多渠道通知 A+B+C+D (站内 / Web Push / SMS / Email)        │
└────────────────────────────────────────────────────────────┘

5.6 前端状态分层与竞态防护

Chat 前端已完成状态分层重构：

• chat-session-context.tsx：纯会话容器，负责 CRUD、SSE 消费、加载状态
• chat-business-context.tsx：业务状态容器，负责额度、错误、handoff 建议
• handoff-trigger-context.tsx：Handoff 触发状态，管理 nudge 历史与防骚扰
• alert-reducer.ts：Action-Based 守卫，统一入口处理状态变更

关键防护：mount 阶段 hasInitialLoadedRef guard 防重执行；nudge 10 分钟 cooldown + 每 session 最多 3 次；用户 dismiss 后同 session 不再自动弹窗。

---

6. 商业模型

6.1 客户侧

消费者对话额度由 zhen-platform-core entitlement 系统统一管理，本地 free_messages_used 字段已退役。

6.2 顾问侧

顾问登录统一走 OAuth（auth.zhenrobot.com），本地密码体系已于 2026-05-07 正式退役。顾问工作台配备实时 WS 推送、线索池、多维度筛选、成交排行和佣金统计。

6.3 机构侧

机构方案包含：多席位、组织权限、API Key 集成、合规报表与审计导出。

6.4 定价上收

商品定价（顾问会员、团队席位、机构方案等）不再由 ZhenIns 本地维护，统一由 zhen-platform-core catalog 作为唯一真相源。前台仅负责展示和引导购买。

---

7. 路线图与里程碑

7.1 已完成

7.2 进行中

7.3 规划中

功能扩展由真机生态路线图统一驱动，不由 ZhenIns 单独发布。前台保持"壳"的定位，新能力通过 platform-core 和 brain-core 的升级自然承接。

---

附录 A：术语表

附录 B：合规文档索引

• 授权说明
• 隐私政策
• 服务条款
• 安全合规
• 文档中心
• 下载中心

---

本文档为 ZhenIns 公开白皮书 v1.2。详细技术规范、生态总纲和内部接口定义见上游架构文档，不由本白皮书替代。历史版本永久可访问：/whitepaper/v/v1.1、/whitepaper/v/v1.0。