# 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 请求协议（渠道 -> 中台）
```json
{
  "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 响应协议（中台 -> 渠道）
```json
{
  "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` 只认最新请求结果。

2. 工具调用抖动影响时延
- 应对：工具超时上限 + 快速降级 + 结果摘要缓存（可选）。

3. 元数据质量不一致导致召回偏差
- 应对：统一 metadata 枚举、入库校验、周期巡检。

4. 智能体自由度过高引发合规风险
- 应对：policy_router 前置约束 + 输出护栏 + micro-flow 强接管。

---

## 9. 最终结论

本方案坚持“仅中台侧改造”：
- 以统一分段协议承接渠道可打断发送能力。
- 以 Agent 主链路提升效果，以 Micro-flow 护栏保证可控。
- 以观测与治理机制保障可回放、可归因、可灰度演进。

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