MerCry
/
ai-robot-core
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ai-robot-core/spec/intent-driven-script/solution-python-mid-platfor...

6.4 KiB
Raw Blame History

AI客服智能体增强改造方案（仅中台侧）

1. 改造定位

中台侧承担“智能决策与会话编排核心”角色，负责在不改变渠道发送机制的前提下，输出可被渠道稳定消费的分段回复与可观测信息。

本次文档范围仅覆盖中台侧，并以渠道侧协同接口为边界。

核心目标

  • 统一中台对外响应为 segments[] 协议，支撑渠道侧分段发送与打断重入。
  • 构建“Agent 主链路 + Micro-flow 护栏兜底”的双轨决策。
  • 仅基于“已送达历史”做上下文推理，避免上下文污染。
  • 完整沉淀可观测字段，支持回放、归因与灰度治理。

非目标（Out of Scope）

  • 不定义渠道侧发送节奏实现细节（队列、重试、UI 展现）。
  • 不新增渠道侧状态机实现要求（仅声明协同接口语义）。
  • 不扩展 Python 代码级任务与语言实现细节。

2. 中台侧能力边界

2.1 中台负责

  1. 接收会话请求并执行策略路由（agent / micro_flow / fixed / transfer）。
  2. 组织工具调用（KB/Intent/Flow/Prompt/Memory）并生成结果。
  3. 返回分段回复 segments[] 与追踪信息 trace。
  4. 接收并落库全量消息上报（含人工阶段消息与模式切换事件）。
  5. 提供会话模式状态接口（机器人/人工）。

2.2 中台不负责

  1. 渠道消息发送调度与本地打断取消逻辑。
  2. 渠道本地“已送达历史”缓存实现。
  3. 渠道端展示层节奏控制。

3. 协同契约（与渠道侧）

3.1 请求协议（渠道 -> 中台）

{
  "session_id": "sess_123",
  "user_message": "孩子五年级，数学不好",
  "history": [
    {"role": "user", "content": "你好"},
    {"role": "assistant", "content": "您好"}
  ],
  "interrupted_segments": [
    {"segment_id": "seg_2", "content": "稍等，我查一下"}
  ]
}

约束：

  • history 必须是已送达历史，不得包含未送达片段。
  • interrupted_segments 为可选协同信息，中台可用于上下文修正与日志归因。

3.2 响应协议（中台 -> 渠道）

{
  "segments": [
    {"segment_id": "seg_3", "text": "好的，请问孩子具体是哪个知识点薄弱？", "delay_after": 800},
    {"segment_id": "seg_4", "text": "比如分数应用题还是几何？", "delay_after": 0}
  ],
  "trace": {
    "mode": "agent",
    "intent": "course_consult",
    "tools_used": ["get_knowledge_bases", "recall_memory"]
  }
}

约束：

  • 中台必须保证 segments[] 可直接消费，不依赖渠道二次改写。
  • trace.mode 必须返回，便于渠道侧与观测平台统一归因。

4. 中台核心架构

4.1 决策总线

  • policy_router：根据意图、风险级别、置信度决定执行模式：
    • agent（默认）
    • micro_flow（高风险/强SOP）
    • fixed（固定答复）
    • transfer（转人工）

4.2 Agent 执行层

  • Agent Orchestrator 执行 ReAct 循环（思考-行动-观察）。
  • 通过 Tool Registry 调用工具（含 MCP 扩展能力）。
  • 输出统一分段结构，受输出护栏二次校验。

4.3 微流程护栏层

仅保留高风险场景的最小流程集：

  • 退款/退费
  • 投诉升级
  • 隐私与敏感承诺
  • 转人工

4.4 记忆与元数据层

  • 记忆读取：按 user_id/session_id 注入长期与短期上下文。
  • 元数据检索：严格执行 intent -> target_kbs -> metadata_filter -> vector_search -> rerank。
  • 标签规范遵循既有方法论（grade/subject/scene/flow_step/intent_type 等）。

5. 中台执行时序

5.1 正常对话

  1. 接收渠道请求（含已送达历史）。
  2. policy_router 决策模式。
  3. 进入 agent 或 micro_flow。
  4. 工具调用 + 护栏校验。
  5. 返回 segments[] + trace。
  6. 异步写入会话日志与观测事件。

5.2 打断重入

  1. 渠道发送中断后发起新请求。
  2. 中台接收新的 history 与可选 interrupted_segments。
  3. 丢弃旧 generation 的输出影响，仅以最新请求生成结果。
  4. 返回新的 segments[]，保证语义连续。

5.3 人工接管

  1. 渠道触发模式切换接口，标记 HUMAN_ACTIVE。
  2. 中台停用机器人主链路输出。
  3. 持续接收并记录人工消息上报。
  4. 必要时支持 HUMAN_ACTIVE -> BOT_ACTIVE 回切。

6. 关键治理与门禁

6.1 质量门禁

  • 输出必须可分段消费（结构合法、字段完整）。
  • 高风险场景必须命中 micro-flow，不允许 agent 直出。
  • 低置信度或工具异常必须降级（fixed 或 transfer）。

6.2 可观测性字段（必须）

  • mode
  • intent_id/intent
  • target_kbs
  • applied_metadata_filters
  • tool_calls（参数摘要、耗时、状态）
  • fallback_reason_code
  • guardrail_triggered
  • session_id/request_id/generation_id

6.3 关键指标（建议）

  • 响应时延 P50/P95
  • 工具超时率
  • fallback 触发率
  • micro-flow 接管率
  • 误转人工率
  • 无召回率

7. 分阶段落地（仅中台）

Phase 1：协议与主链路打通

  • 固化 segments[] 对外响应协议。
  • 打通 policy_router + Agent Orchestrator 最小闭环。
  • 上线基础观测字段。

Phase 2：护栏与记忆增强

  • 上线高风险 micro-flow 最小集。
  • 接入记忆读写与 metadata 过滤检索全链路。
  • 完善降级与回退策略。

Phase 3：稳定性与治理

  • 完善 generation 级并发与乱序治理。
  • 强化工具治理（超时、重试、熔断、错误映射）。
  • 建立灰度策略与回滚开关。

8. 主要风险与应对

  1. 打断竞态导致旧响应污染
  • 应对：按 generation_id/request_id 只认最新请求结果。
  1. 工具调用抖动影响时延
  • 应对：工具超时上限 + 快速降级 + 结果摘要缓存（可选）。
  1. 元数据质量不一致导致召回偏差
  • 应对：统一 metadata 枚举、入库校验、周期巡检。
  1. 智能体自由度过高引发合规风险
  • 应对：policy_router 前置约束 + 输出护栏 + micro-flow 强接管。

9. 最终结论

本方案坚持“仅中台侧改造”：

  • 以统一分段协议承接渠道可打断发送能力。
  • 以 Agent 主链路提升效果，以 Micro-flow 护栏保证可控。
  • 以观测与治理机制保障可回放、可归因、可灰度演进。

在不扩展渠道实现细节与不引入语言实现绑定的前提下，可支撑中台能力平滑升级。