PRD: AI Case Management System

产品需求文档 — Schema + Workflow 双原语驱动的 AI-native Case 管理系统

AI Case Management System — 产品需求文档

Version: 6.8 Date: 2026-02-25

1. 重新定义问题

传统方案的根本瓶颈

流程可配但不可适应：规则引擎能处理”超过 30 天→拒绝退货”，但无法处理”超期 4 天、有质量检测报告、客户价值高”这类需要综合权衡的灰色地带。非标个案在实际业务中占比 20-30%，却消耗 60% 以上的人工处理时间。
人依赖经验兜底：真正有价值的判断发生在”模糊、冲突、不完整”的信息里，而这些判断高度依赖个人经验。骨干员工离职意味着隐性知识流失，新人面对同类场景只能重新摸索，团队处理水平随人员变动剧烈波动。
个案无法规模化复用：两个相似投诉可能因为不同客服处理而得到完全不同的结果。系统没有机制将”什么条件下用什么方案、效果如何”结构化沉淀并在后续案件中检索复用。
系统只管理状态，不管理不确定性：能记录”工单到了待审核”，但不知道审核需要哪些信息、当前缺什么、下一步该找谁补。人需要自己跨系统拼凑上下文、判断信息缺口、决定推进路径。

产品要达成的变化

AI 不只提建议，而是驱动流程推进：在不确定上下文中生成可执行动作。
人从”流程搬运工”变为”审批节点”：在关键门禁做确认与例外裁决。这一转变与 AI Coding 的演进路径一致——从 Copilot 辅助人写代码，到 Agent 模式下 AI 写代码、人 review，角色关系已经反转。
个案处理可复用：AI 将每次处理中的判断依据沉淀为可检索经验。
流程从固定分支升级为自适应决策链：同一 Workflow 能处理大量个性化路径。

2. 核心范式

从确定性编程到不确定性计算

传统流程系统本质上是确定性编程——if/else、规则引擎、状态机，能覆盖的是规则编写者预见到的路径。超出预设分支的场景只能交给人兜底，这是传统方案在非标个案上的根本瓶颈。

AI 带来的根本变化不是"更聪明的规则"，而是一种新的计算范式：不确定性计算。AI 能在信息不完整、规则冲突、上下文模糊的条件下生成合理判断——这恰好是确定性编程失效、人工成本最高的地带。

这一范式能够规模化的关键在于：AI 不需要在所有场景都正确，只需要在特定场景类型上达到足够高的可靠性。一旦某类决策跨过可靠性阈值，规模化自然成立——剩余的不确定性可以通过系统化手段管理：QA 抽检校验输出质量、冗余计算（多次独立推理取一致结果）降低单次误判概率、人工门禁兜底高风险场景。

这是 AI 原生流程系统区别于传统自动化的根基：传统系统要求 100% 规则覆盖才敢自动化；AI 原生系统接受不确定性，用概率决策能力加系统级校验机制，将原本只有人工才能完成的判断规模化。

核心不是渠道，而是 Schema + Workflow + AI

语音与聊天是标准输入通道：它们负责”把信息送进来”，不是系统核心能力。
Schema：定义案件事实模型——每个案件类型声明必需字段、校验约束、证据来源映射（哪个字段从哪个系统获取）和置信度要求。Schema 既是 AI 抽取的目标结构，也是 Workflow 推进的前置条件：字段未达标时流程不会盲目前进。
Workflow：定义状态机与转移条件。每个状态节点标注 AI 可自主推进的条件、需要人工审批的门禁规则、超时与异常的降级路径。同一 Workflow 支持因上下文不同而走出不同实际路径——分支不是预先穷举的，而是 AI 在约束范围内动态选择的。
AI：在每个状态节点执行 sense → think → act → reflect 循环（详见 §5.2），完成信息补全、方案生成、风险评估与动作执行。AI 的决策边界由 Schema 约束和 Workflow 门禁共同限定。

AI 驱动工作流，人类作为审批节点

AI 负责：信息抽取、意图识别、冲突消解、动作选择、自动执行。
人类负责：高风险审批、政策例外授权、责任确认。
系统默认：AI 先走通流程，人类只在门禁节点介入。与 AI Coding 工具的权限模型同构——AI 自主执行常规操作，仅在高风险变更时请求人工确认。
人机边界是动态的：随着某类决策的 AI 准确率持续达标，该类决策的门禁阈值可逐步下调（更多自动化）；反之，若某段时间人工覆盖率上升，系统自动收紧该类决策的门禁。边界不是一次划定的，而是随运行数据持续校准的。
人工决策反哺 AI：每次人工审批的选择（批准/驳回/修改方案）及其理由，作为标注数据回流到经验记忆，使 AI 在同类场景的后续判断更贴近业务预期。这一机制确保系统不只"跑流程"，而是在运行中持续逼近组织的真实决策标准。

底线思维

AI 有误判概率，设计必须可回退、可追溯、可接管。
每个关键动作要有依据快照（输入、判断、阈值、执行结果），支持事后审计与争议回溯。
低置信度自动降级为人工，避免”错误自动化”。置信度处于灰区时，AI 仍给出建议但明确标注不确定因素，由人做最终判断（详见 §5.5）。
人工覆盖 AI 决策时，覆盖原因和结果作为反馈信号回流，持续校准模型在同类场景的判断边界。
AI 服务不可用时，系统降级为传统工作流模式——流程推进、审批、通知等基础能力不依赖 AI 即可运行。

3. 可行性论证：AI Coding 领域的实证

§2 提出的核心范式——不确定性计算、AI 驱动流程、人类审批门禁——需要回答一个关键问题：凭什么相信这条路走得通？答案不在理论推演，而在实证：AI 在软件工程领域已经走通了一条高度同构的路径。同样的能力跃迁、人机协作模型和规模化逻辑，已被数百万开发者和数千家企业验证。本章用 AI Coding 的演进事实论证本系统方案的可行性。

3.1 演进路径的可重复性

AI Coding 工具在过去四年经历了清晰的四阶段跃迁，每个阶段的核心突破都不是 Coding 领域独有的，而是 AI 自主能力的通用演进规律。Case Management 正在经历同一规律的展开：

阶段	AI Coding（已发生）	Case Management（正在发生）	核心突破
辅助补全	Copilot 逐行补全代码，人决定是否采纳	传统系统推送 KB 文章和 SOP，人自行判断	AI 开始参与，但不承担决策责任
上下文理解	Chat 模式下 AI 理解整个文件甚至仓库，生成完整代码块	AI 理解案件全量上下文，生成结构化分析和方案建议	AI 具备全局理解力，但仍由人驱动流程
自主执行	Agent 模式下 AI 读代码→规划→编辑→测试→迭代，人在关键节点 review	AI 驱动案件流程 sense→think→act→reflect，人在门禁节点审批	AI 驱动流程，人从执行者变为审批者
规模化自主	AI 并行处理多个代码任务，人管理优先级和验收	AI 并行处理批量案件，人管理例外和质量审计	AI 独立处理标准场景，人聚焦治理和例外

本系统的设计目标对应第三阶段（自主执行），并为第四阶段（规模化自主）预留演进空间。第三阶段在 AI Coding 领域已大规模落地（Claude Code Agent 模式、Cursor Agent 等），技术可行性和用户接受度均已得到验证——这不是我们对未来的预测，而是对已发生事实的复用。

3.2 核心能力已在 AI Coding 中验证

两个领域表面差异大（代码 vs 业务流程），但本系统所需的每一项核心能力，都已在 AI Coding 中被证明可行：

上下文管理——已验证。AI Coding 从单文件补全进化到全仓库理解——读取目录结构、依赖关系、测试用例、git 历史，在完整上下文中做出准确变更。Case Management 需要的是同一能力的领域实例化：从单工单处理到跨案件组织记忆——聚合客户历史、关联案件、业务规则、处理经验。核心挑战相同：信息散落在多个来源，AI 必须主动聚合而非等人喂入。AI Coding 已证明这一能力可以工程化实现。

工具调用——已验证。AI Coding agent 不只生成文本，而是调用真实工具——文件编辑、终端命令、搜索引擎、浏览器。每个工具原子化、可审计、有权限控制。本系统的 MCP Tool 设计直接复用这一架构：case.update、ext.query、channel.suggest 等原子工具通过标准协议暴露，AI 在 Skill 编排下按需调用。MCP 协议本身就是从 AI Coding 工具生态中生长出来的标准，协议成熟度和生态支持已经过验证。

分级授权——已验证。AI Coding 工具的权限模型已高度成熟——读操作自动放行，写操作按风险分级：编辑文件可自动执行、删除分支需确认、force push 到 main 需显式授权。本系统的门禁机制是同一模式在业务领域的实例化：低风险操作（发通知、更新状态）AI 直接执行，高风险操作（退款、生产变更、超额补偿）触发人工审批。风险定义不同，但分级授权架构的有效性已被证明。

从反馈中持续学习——已验证。AI Coding agent 在一次会话内通过测试反馈迭代（跑测试→看报错→改代码→重跑）；跨会话通过持久化记忆积累项目知识。本系统的经验记忆将这一能力扩展到组织维度——不只是单个 agent 的会话内迭代，而是整个组织处理案件的经验沉淀和复用。反馈信号的形态不同（测试通过/失败 vs 方案效果/人工覆盖），但"从执行结果中学习"的闭环机制已被验证可行。

3.3 信任建立模型的可复用性

技术可行只是一半。AI 自主执行业务流程还需要解决信任问题——用户凭什么敢让 AI 自动处理？AI Coding 领域已经验证了一套有效的信任建立模型：

初始阶段：逐一审查。用户对每一行 AI 生成的代码都要逐行审查。对应 Case Management 初期，每个 AI 方案都需要人工逐一审批。
信任积累：按类型放开。随着 AI 在特定任务类型上持续表现良好（如单元测试生成、代码格式化），用户逐渐允许自动执行。对应 Case Management 中，特定案件类型的 AI 决策准确率持续达标后，该类门禁阈值逐步下调。
分级授权：按风险管控。用户不是"完全信任"或"完全不信任"，而是按任务风险分级——低风险自动执行、中风险快速确认、高风险仔细审查。Case Management 的门禁机制（§5.5）复用完全相同的设计。
信任可撤回：双向调整。如果 AI 在某类任务上出现退化（如模型更新后某些场景准确率下降），用户随时可以收紧权限。本系统的动态门禁机制（§2 AI 驱动工作流）同样支持信任的双向调整。

这条从"逐一审查"到"分级自主"的信任演进路径，不是设计出来的理论，而是数百万开发者在实际使用中自然形成的行为模式。本系统将这一经过验证的信任模型直接应用于 Case Management——这意味着我们不需要从零说服用户接受 AI 自主执行，而是复用一套已被证明有效的信任建立机制。

4. 真实场景

以下十个场景覆盖不同业务领域和系统能力维度。前五个围绕单案件处理的完整循环（接入→应变→决策→记忆→规模化），后五个展示系统在合规、协同、预警、反馈学习、动态调度等扩展维度的能力。

场景一：实时来电 —— 接入层与工作流匹配

角色：一线客服 Agent

客户来电反馈耳机有电流噪音，已过退货期。传统系统的典型响应：弹出客户档案、推送 KB 文章和 SOP 链接，Agent 需要一边接听一边从多个信息源中自行判断处理路径。

本系统的处理逻辑不同。Contact center 按接口协议推送实时转写流，系统将每段话语标准化为 Case 事件。AI 根据 Schema 做定向抽取——产品型号、故障描述、购买时间——自动关联订单和历史 Case；Workflow 引擎匹配到「退货」流程，定位当前卡点”已过时效但有质量主张”，并计算出推进流程还缺什么信息。Agent 屏幕上显示的不是一堆文章，而是一条精确引导：”请确认客户是否有第三方检测报告，这是走例外通道的关键证据。”

Agent 的角色从判断者转为审核者。客户在聊天窗口补传检测截图，AI 自动 OCR 并关联到同一 Case。信息收齐后，AI 生成方案：例外退货 + 延迟寄回，附结构化依据——超期天数在例外通道容许范围内、客户信誉评分达到合格线、检测报告与故障描述匹配度达标、例外退货成本低于投诉升级风险。每项依据附具体数值和对应阈值，供审批人直接比对。Agent 将方案转交主管审批，主管确认后 AI 自动执行退货标签发放和财务通知。

侧重点：Schema 定义所需事实，Workflow 定义推进路径，AI 执行流程推进，人在门禁节点确认。核心区别是系统主动驱动流程，而非向人推送信息等待人判断。

场景二：症状漂移 —— 动态诊断与重规划

角色：技术支持工程师

客户报”登录失败，502 错误”。两小时后追加”其实部分账号能登录，但报表页超时”。传统流程中，这意味着之前的排查方向可能完全偏离——工程师需要重读所有上下文，推翻假设，重新排查。升级到 L2 后，L2 需要再读一遍。每次新信息到达都是一次上下文重启。

本系统不重启上下文。每条新消息作为事件写入同一 Case，自动触发新一轮 sense → think → act → reflect 循环——与 AI Coding agent 的调试循环同构（跑测试→看报错→改代码→重跑），不是从头开始，而是在已有上下文上继续推理。第一轮，根据”502 + 登录失败”，AI 倾向认证服务异常，执行只读健康检查——正常。第二轮新信息到达，AI 把”认证服务正常”作为已知约束，结合”部分可登录 + 报表超时”重排根因：报表是重查询，部分超时意味着资源竞争，根因切换到数据库连接池耗尽。执行连接池监控查询，活跃连接数接近上限，确认瓶颈。

修复方案根据风险评级自动分档：临时限流慢查询（低风险，AI 直接执行）和扩容连接池（生产参数变更，触发人工审批门禁）。工程师无需重读历史或手动切换排查方向，只在生产变更环节介入审批。修复完成后，AI 验证指标恢复、生成事故摘要，并将这条诊断路径写入经验记忆，下次类似症状组合出现时直接复用。

侧重点：sense → think → act → reflect 循环的实际运作。新信息到达时 AI 在已有上下文上继续推理，而非重启流程。

场景三：规则冲突 —— 结构化多路径决策

角色：部门主管

员工申请采购 1.5 万元设备，预算只剩 1.2 万元。但这个设备关联本周的客户交付，延误一天违约金 5,000 元。传统流程中，主管需要电话确认项目紧急度、手动查询预算余额、凭经验权衡超预算与违约风险，再在审批系统中撰写理由。瓶颈不在审批本身，而在信息收集与整合。

AI 将分散的信息结构化。通过 MCP 暴露的标准工具拉取申请单、项目交付节点和实时预算余额，基于 Schema 约束计算出三条路径：

方案 A：直接批准，超支 3,000 元，需财务特批，交付风险消除
方案 B：跨部门分摊，本部门用完 1.2 万，协作部门出 3,000 元（对方预算充裕），无需特批，审批链路短一级
方案 C：短租替代，月租 4,500 元在预算内，但供应商确认需 2 个工作日，可能触发违约

主管无需手动收集数据，直接在量化方案中选择并确认，AI 自动通知采购、财务和项目负责人。

侧重点：Schema 驱动的结构化决策。AI 将分散在多系统中的决策依据聚合为可比较的量化路径，将信息收集到决策的周期从小时级压缩到分钟级。

场景四：信息断层 —— 跨案件记忆与上下文重建

角色：客服主管

客户第三次投诉。前两次的工单分别只写了”已解释”和”已安抚”——客户的具体诉求、客服的承诺内容、未解决原因均缺失。传统流程中，主管需要回放三次通话录音，手动重建完整诉求，再从头制定方案。

本系统在记忆层维护组织级上下文，不依赖个人的记录习惯。AI 从前两次的录音转写中自动提取结构化事实：第一次客户要求退运费 25 元，客服口头承诺 48 小时回复但没建跟进任务；第二次诉求升级到退运费 + 补偿券，客服给了 10 元券但客户没接受。到第三次来电时，主管屏幕上看到的不是三条残缺的工单，而是一条完整的事实时间线和逐步升级的诉求轨迹。

基于完整上下文，AI 给出补偿方案，标注依据：累计处理成本已超过补偿成本、客户年度消费价值、同类投诉升级后的历史流失风险。主管审批后，AI 执行补偿发放、生成复盘报告，并将这次的判断依据和处理结果写入经验记忆——下次同类投诉升级，系统从第二次就能命中这条经验，直接建议更高补偿档位，避免拖到第三次。

侧重点：经验沉淀与跨案件记忆。处理经验从个人记忆和零散工单备注转化为系统级组织知识，支持同类案件的自动检索与复用。

场景五：批量积压 —— 个案判断的规模化

角色：运营主管

周一早上，大量”发票异常”工单积压。表面同类，成因散布在税号格式错误、抬头变更未同步、跨主体开票、金额不符等多种根因。传统流程两种选法：逐单人工处理，耗时巨大；或按标签批量操作，一刀切，大概率误处理。前者保质量但无效率，后者有效率但易误处理。

AI 的方案兼顾两者。逐单基于 Schema 提取根因字段后按成因聚类——最大一群是税号格式错误（正则匹配即可修复），其次是抬头变更未同步（ERP 与开票系统字段对比），还有一部分是跨主体开票（需关联合同验证），其余散布在几种低频根因。每群各自的修复策略。

低风险群 AI 自动修复并通知。高风险群打包成审批包，主管按群审批而不是逐单审批。少量置信度低于阈值的工单，AI 不做强制归类，标记为”需人工研判”并附上已排除的候选原因。主管处理完这些工单后，AI 将判例写入经验记忆并更新分群模型，后续同类覆盖率进一步提升。

侧重点：规模化不以牺牲判断精度为代价。AI 将批量问题拆解为个案级分析，逐单提取根因后按成因聚合处理，兼顾质量与效率。

场景六：合规校验 —— 规则密集场景下的自动审计

角色：保险理赔审核员

客户提交车险理赔：追尾事故。传统审核流程中，审核员需要逐项核对：保单有效期、出险时间是否在承保范围内、驾驶人与被保险人关系、事故责任认定书与报案记录是否一致、维修项目是否与事故损伤匹配、单项工时费和配件价格是否超出区域指导价。审核时间绝大部分花在信息核对上，真正需要专业判断的环节只占一小部分。

AI 将核对工作自动化。通过 MCP 工具拉取保单信息、交警责任认定书、维修明细、区域指导价数据库，基于 Schema 定义的校验规则逐项比对：保单状态有效、出险时间在承保期内、驾驶人为被保险人配偶（符合家庭共用条款）、责任认定为对方全责。维修明细中绝大部分项目匹配指导价自动通过，少数项目标注异常：某项工时费明显超出指导价、某配件价格偏高、有一项"全车抛光"与追尾损伤无关联。

AI 生成审核报告：通过项和异常项分别列示，异常项附偏差幅度和触发规则。审核员聚焦异常项做专业判断——工时费偏高因为该车型需要拆卸传感器组件（合理）、配件价格偏高但在浮动允许范围内（通过）、全车抛光与事故无关（剔除）。审核结论附完整校验轨迹，每一项通过/异常的判定依据均可追溯，满足监管审计要求。

侧重点：规则密集场景下 AI 把审核员从逐项核对中释放出来，聚焦真正需要专业判断的异常项。Schema 校验规则提供结构化的合规框架，完整审计轨迹满足监管可追溯要求。

场景七：跨团队协作 —— 多方联动的流程编排

角色：SRE 值班经理

凌晨 2:17，监控告警：核心交易链路 P99 延迟从 200ms 飙升到 3.2s，错误率从 0.1% 升到 8.7%。这不是单一组件故障——API 网关、支付服务、风控引擎、数据库四个团队都可能相关。传统流程：值班经理拉群，逐个 @ 各团队 oncall，等回复，手动汇总排查进展，协调修复顺序。瓶颈不在技术排查，而在协调开销——四个团队各自排查，信息散落在不同聊天窗口，谁先查完、谁被阻塞、修复顺序怎么排，全靠值班经理人脑追踪。

AI 自动创建事故 Case 并启动并行排查工作流。通过 MCP 工具同时拉取四个组件的健康指标：API 网关正常；支付服务线程池 92%（接近饱和）；风控引擎规则执行耗时从 15ms 升到 800ms；数据库慢查询数量从每分钟 3 条飙到 120 条。AI 基于服务依赖链推断根因传导路径：数据库慢查询→风控引擎等待查询结果→支付服务线程阻塞→链路整体延迟飙升。

AI 为每个团队生成针对性的排查指令和修复建议，按依赖顺序编排：DBA 优先处理慢查询（已定位到一条未走索引的新上线 SQL）；风控团队准备降级预案（临时切换到缓存规则）；支付团队待上游恢复后验证线程池回落。值班经理在一个面板上看到四条并行工作流的实时进展，只在 DBA 执行 SQL 变更（生产操作）时介入审批。恢复时间相比传统流程大幅缩短——核心差异不在排查速度，而在消除了团队间的等待和协调空转。

侧重点：Workflow 编排跨团队并行排查，AI 基于依赖关系自动排序修复顺序。核心价值不在技术排查本身，而在消除多团队协调的信息损耗和等待空转。

场景八：主动预警 —— 从个案处理中发现系统性问题

角色：质量经理

日常运转中，AI 持续处理退货案件。在 reflect 阶段的聚合分析中，AI 发现一个统计异常：某款蓝牙音箱近期的退货率显著偏离历史均值，且退货原因高度集中在"配对失败"——该症状在历史退货中占比很低，但近期突然成为主要退货原因。进一步交叉分析显示，异常集中在某一批次出货，其他批次正常。

AI 主动创建预警 Case，附结构化分析：异常批次编号、退货率偏差幅度、故障症状分布、受影响的已售和在途订单数量。同时检索经验记忆，命中一条历史判例——此前某款耳机出现过类似批次性配对问题，根因是固件版本回退，最终通过 OTA 推送修复，召回成本为零。

质量经理收到预警时看到的不是一个模糊的"退货率偏高"警告，而是：问题定位（具体批次 + 具体症状）、影响范围（已发生的退货 + 在途订单的预估影响）、历史参照（类似问题的处理先例和结果）、建议动作（联系工厂确认该批次固件版本、暂停该批次发货、准备 OTA 修复方案）。质量经理确认后，AI 自动通知供应链暂停发货、向工厂发送排查请求、对已购客户标记主动关怀标签。

侧重点：AI 不只被动处理到达的案件，还在 reflect 阶段对已处理案件做聚合分析，从个案模式中识别系统性问题。从"等客户投诉再处理"到"比客户先发现问题"。

场景九：人工覆盖 —— 从否决中学习

角色：客服组长

AI 给一个退款申请生成了"拒绝退款"方案——商品已拆封使用 15 天，超出 7 天无理由退货期，不符合质量问题退货条件。从规则角度，这个判断完全正确。但客服组长否决了 AI 方案，改为"全额退款 + 赠送 50 元券"。

传统系统到这里就结束了——人覆盖了机器的决策，仅此而已。本系统不同。门禁要求组长填写覆盖理由，组长选择"客户身份特殊"并补充：该客户是某企业采购负责人，企业账户是高价值大客户，个人订单是试用评估，退款体验直接影响企业续约决策。

这条覆盖记录被结构化写入经验记忆：场景特征（个人订单 + 关联企业大客户 + 试用评估性质）、原方案（拒绝退款）、覆盖方案（全额退款 + 补偿）、覆盖原因（客户关系价值远超订单金额）。下次类似模式出现——个人订单但关联高价值企业账户——AI 在 think 阶段命中这条经验，主动将客户关系维度纳入决策，而非机械套用退货规则。

随着同类覆盖记录的积累，AI 在该类场景的判断逐步对齐业务实际，人工覆盖率持续下降——AI 逐步学会了"规则之外的判断"不是例外，而是业务常态的一部分。

侧重点：门禁不只是安全网，更是 AI 的学习信号源。每次人工覆盖都是一次高质量标注——告诉系统"这类情况下，正确答案和规则答案不一样"。系统通过覆盖反馈持续校准判断边界。

场景十：SLA 倒计时 —— 时效压力下的动态优先级

角色：客服团队主管

队列里几十个待处理工单。其中一个看起来普通的物流查询工单即将触碰 SLA 时限，但因为没有"紧急"标签，一直排在常规队列里。传统系统按提交时间排序或按标签分优先级，无法动态感知 SLA 实时状态。

AI 持续计算每个 Case 的时效风险。所有工单的优先级不是静态标签，而是动态分数——综合剩余 SLA 时间、预估处理耗时、违约成本、客户价值四个维度。那个物流查询被提升到高优先级——不是因为它复杂，而是因为它简单且即将违约：快速处理即可消除一个确定的违约成本。

同时，一个刚提交不久的工单也被提前——虽然 SLA 时间充裕，但 AI 识别到该客户短期内多次提交工单且情绪逐步升级，按经验记忆中的同类模式，延迟处理有较高的客户流失风险。另有一批低风险、SLA 充裕的简单咨询类工单被自动处理——AI 直接生成回复并发送，无需人工介入。

团队主管看到的不是一个静态排序的工单列表，而是一个实时更新的优先级面板：每个工单附带 SLA 倒计时、预估处理时间、排序理由。主管可以接受 AI 排序，也可以手动调整——调整动作同样被记录为反馈信号，校准优先级模型。

侧重点：优先级不是工单创建时的静态标签，而是基于实时状态持续计算的动态决策。AI 同时考虑 SLA 时效、处理成本、客户风险等多维因素，将"先来先服务"升级为风险驱动的动态调度。

5. Agent 技术设计与实现

5.1 Agent Tools（MCP 暴露）与插件体系

Agent 通过 MCP 暴露原子能力，每个 Tool 可独立调用并可审计。MCP 已成为 AI Coding 工具和自主 Agent 的标准集成协议（OpenClaw 等开源 Agent 框架已验证了基于 MCP 的 Skill 动态加载与持久记忆机制），本系统复用同一协议层。

Tool 分为两层：核心工具和插件工具。核心工具是平台运行的基础能力，与 Case 生命周期、Schema 引擎、Workflow 引擎、记忆系统、审计链路和通道系统深度耦合，插件系统无法替代。插件工具是可动态加载的外围能力——文档处理、外部系统适配、风险评估等——不同行业、不同部署环境可按需组合，通过插件机制注册到 MCP 层即可被 Agent 调用。

核心工具（平台内置，不可替代）：

分类	Tool	功能描述
案件操作	`case.get` / `case.create` / `case.update`	读取、创建、更新案件
结构校验	`schema.validate`	验证字段、约束、证据完整性
工作流	`workflow.next_step` / `workflow.trigger`	计算候选动作并推进状态
知识与记忆	`kb.search` / `memory.search_experience` / `memory.upsert_case_memory`	知识库检索、经验匹配与沉淀
审计	`audit.query`	查询操作时间线与决策依据链
通道	`channel.list` / `channel.read` / `channel.suggest` / `channel.ack`	通道发现、消息读取、建议发送（需审批）、消息确认

通道操作（channel.*）是核心工具而非插件，因为通道是系统 I/O 的基础抽象（§5.6）。Agent 通过 channel.list 发现当前部署中有哪些通道可用，通过 channel.read 读取消息历史，通过 channel.suggest 建议发送消息（进入人工审批），通过 channel.ack 确认消息已处理。无论底层是邮件、短信、聊天还是语音，Agent 使用同一组操作——通道差异在 Channel 适配器层吸收。

插件工具（通过插件系统动态加载）：

分类	Tool（示例）	功能描述
文档处理	`doc.ocr` / `doc.extract`	OCR 识别与结构化信息抽取
外部系统	`ext.query` / `ext.execute`	通过适配器查询或操作外部系统（ERP、CRM、财务等）
风险评估	`risk.score_case`	输出风险分和风险因子

插件工具遵循与核心工具相同的 MCP 协议规范和设计原则，对 Agent 而言调用方式完全一致。不同行业可开发各自的插件（如医疗行业的影像识别工具、金融行业的征信查询工具），通过同一接口注册即可融入系统。

设计原则（核心工具与插件工具均适用）：

Tool 幂等，重复调用不产生额外副作用。
所有写操作返回 diff 并写入 timeline，支持变更追溯和回滚。
Tool 不做策略，策略只在 Skill/Workflow 层。Tool 本身不判断"该不该做"，只负责"怎么做"。
每次 Tool 调用携带 trace_id，支持跨系统的端到端调用链追踪与性能分析。
Tool 具备超时控制和熔断机制：外部系统响应超时或连续失败时自动降级，不阻塞工作循环。
插件工具须声明自身的能力描述、入参出参规格和权限要求，由平台在加载时校验。

5.2 Agent Work Loop

采用 sense → think → act → reflect 循环。该模式与 AI Coding agent 的工作方式同构（读代码→规划变更→执行编辑→验证测试），已在软件工程领域大规模验证：

sense：聚合多通道输入（语音转写、聊天消息、文档上传、系统事件），基于 Schema 做定向抽取而非全量解析，补全当前 Case 的事实快照。若关键字段缺失，生成定向追问。
think：枚举候选动作，逐一评估风险与置信度。存在多条可行路径时生成结构化对比（如场景三的三方案并列）。命中经验记忆时，将历史判例作为参考依据纳入推理。
act：置信度达标且未触发门禁→AI 直接执行并记录 diff；触发门禁→生成审批包转人工，附依据摘要与推荐选项。所有写操作支持回滚。
reflect：对比预期与实际结果，提取可复用的判断模式（根因→方案→效果三元组），写入经验记忆供后续检索。人工覆盖的决策单独标记，用于校准后续同类判断。

终止条件：

到达终态（解决/关闭）
进入人工等待（审批/补件）
达到最大循环次数（默认 10）

上下文组装：每轮循环开始前，系统根据当前 Case 状态动态组装上下文窗口：

Case 事实快照（Schema 字段当前值与置信度）
最近 N 条事件（按相关性排序，非简单时间序）
命中的经验记忆（相似历史判例的摘要，详见 §5.7）
当前 Workflow 状态与可选转移

上下文超过模型窗口限制时，按优先级截断：当前事实 > 近期事件 > 经验记忆 > 历史事件。确保 AI 始终基于最关键的信息做决策。

异步事件处理：工作循环不要求所有信息同步到达。Case 进入人工等待状态后，新事件（如客户补传材料、外部系统回调）到达时自动唤醒下一轮循环，无需人工触发。Channel 层对高频消息做 debounce——短时间窗口内的连续消息聚合后统一触发一次工作循环（§5.6），Agent 通过 channel.read 批量拉取后在同一轮 sense 中处理，避免逐条触发的循环风暴。

5.3 Skill：可动态加载的领域技能

Skill 是 Agent 能力的知识型扩展。每个 Skill 封装一类场景的处理知识：什么条件下该采取什么策略、调用哪些工具、按什么顺序、如何处理异常。与 MCP Tool 的关系是：Tool 提供原子能力（查、写、发、评估），Skill 在 Tool 之上封装领域知识——知道”在什么条件下，用哪些 Tool，按什么策略组合”。Tool 是手和眼，Skill 是操作经验。

Skill 的核心特征是可动态加载与演化。系统上线时预置一组基础 Skill（如 信息抽取、方案评估），运行过程中 AI 可基于经验记忆生成候选新 Skill，经人工审核后纳入系统。Agent 的能力边界不是开发时固定的，而是随运行持续扩展。

Skill 定义——每个 Skill 声明式配置以下要素：

触发条件：什么案件类型、什么状态下激活。如”退货类案件 + 已过时效 + 有质量主张”激活 退货例外评估 Skill。
工具链：按顺序或条件调用哪些 Tool。如先 schema.validate 校验完整性 → risk.score_case 评估风险 → 生成方案。
置信度要求：Skill 声明自身输出的置信度下限，低于此值时标记为”需人工确认”。该置信度供 Workflow 门禁机制评估是否触发人工审批（门禁规则本身在 Workflow 层定义，详见 §10.1）。
降级策略：Tool 调用失败或超时时的备选路径。如 OCR 失败时降级为人工录入而非阻塞整个流程。

Skill 组合：复杂场景可串联多个 Skill。如场景一中，退货例外评估 Skill 完成后自动触发 退货执行 Skill（发退货标签 + 通知财务 + 更新库存）。前一个 Skill 的输出作为后一个 Skill 的输入上下文。

Skill 演化：AI 在处理新场景时，若现有 Skill 均无法匹配，可基于已有 Skill 组合生成候选新 Skill，经人工审核后纳入系统。Skill 的知识还可从经验记忆中持续校准——当某类场景的人工覆盖率持续偏高时，系统提示该 Skill 的处理策略需要调整。

插件体系：Tool、Skill、Channel、Agent 四个层次均支持通过插件机制扩展：

Tool 插件：提供可动态加载的工具能力（如文档处理、外部系统适配器、风险评估引擎，详见 §5.1）。
Skill 插件：行业或业务方将领域处理知识封装为 Skill 插件发布，其他组织按需加载——例如保险行业的 理赔合规校验 Skill、电商行业的 退货例外评估 Skill。
Channel 插件：新通道接入只需实现 InputAdapter 和/或 OutputAdapter 标准接口（§5.6）并注册。Channel 插件无需定义自己的工具——channel.read/suggest/ack 是平台核心工具，自动适用于所有注册的 Channel。不同 Contact Center 平台、不同消息平台的差异在 Channel 插件的适配器层吸收，平台核心无需修改。
Agent 模板插件：预配置面向特定场景的 Agent 模板（预绑定 Skill 组合、Workflow 和 Channel），降低新业务上线成本。

四个层次的插件通过统一的注册与审核机制管理，支持版本控制和权限隔离。

5.4 示例链路：新信息进入后的自适应推进

输入来自语音或聊天并不重要，都会标准化为 Case 事件。
AI 基于 Schema 补齐事实，基于 Workflow 选择下一动作。
若置信度高且未触发门禁，AI 自动执行；否则转人工审批。
执行结果与依据沉淀到记忆层（详见 §5.7），提升下一次同类案件的处理质量。

5.5 置信度与门禁机制

置信度是 AI 决定"自主执行还是转人工"的核心依据，贯穿整个工作循环。

置信度结构——不是单一数值，而是多维评估：

事实完整度：Schema 要求的关键字段填充率。如退货场景需要订单号、故障描述、时效判定三项齐备，缺一项即降级。
判断确定度：AI 对当前根因或方案的确信程度，基于信息一致性和历史判例命中率。
执行风险度：该动作的业务影响范围与可逆性。发送通知与执行退款的风险等级不同，门禁阈值也不同。

门禁触发规则：

任一维度低于阈值即触发人工审批，不做加权平均式的模糊通过。
门禁在 Workflow 层声明（§10.1），不同业务场景可配置不同阈值（财务类门禁严于通知类）。
门禁触发时，AI 生成审批包：推荐方案 + 备选方案 + 依据摘要 + 风险提示，降低审批人的认知负担。

灰区处理：置信度不在"明确通过"或"明确拦截"区间时，AI 仍执行推理并输出建议，但标记为"建议方案，需人工确认"，避免流程停滞也避免静默误判。

5.6 Channel：标准化的信息流

Channel 是系统与外部世界之间的有序信息流。每个 Channel 实例（一个邮箱、一个聊天窗口、一个语音通话）是一条独立的消息流（message stream），Agent 通过统一的 channel.read / channel.suggest / channel.ack 操作与之交互——读取消息、建议发送、确认处理，不需要了解底层通道的协议差异。

这一模型与 Unix 的文件描述符类似但有一个关键差异：Unix 进程对 fd 的 read / write 都是直接操作；Channel 的 read 和 ack 是直接操作，但 suggest 是间接操作——AI 只能建议发送，实际发送权在人。这个不对称是有意为之的：它反映了系统的权力结构（§2 "AI 驱动流程，人类作为审批节点"），确保 AI 无法绕过人直接触达客户。

Channel 核心模型：

Channel（信息流）
├── id                  string         通道实例标识（如 "email-main", "chat-web"）
├── type                ChannelType    voice | chat | email | sms | api | internal
├── direction           inbound | outbound | bidirectional
├── inputAdapter?       InputAdapter   输入侧：将通道原始消息标准化为 CaseEvent（inbound/bidirectional 通道实现）
├── outputAdapter?      OutputAdapter  输出侧：将待发送消息格式化为通道特定载荷并投递（outbound/bidirectional 通道实现）
└── messageSchema       object         该通道消息 metadata 的扩展字段规格（如邮件的 subject/cc，语音的 voice_id）

InputAdapter（输入侧——推模型）
├── connect()                          建立连接（实时通道）或注册监听（异步通道）
├── onRawInput(raw) → RawMessage       接收原始输入
├── normalize(raw) → CaseEvent         标准化为 Case 事件（核心契约）
└── supportedInputTypes                text | file | audio_stream | structured

OutputAdapter（输出侧——suggest 审批通过后触发）
├── format(message) → ChannelPayload   将待发送消息格式化为通道特定载荷
├── deliver(payload) → DeliveryResult  投递并返回回执
└── supportedOutputTypes               text | rich_text | file | audio_synth | structured

Channel 唤醒与批量处理：Channel 有新消息到达时不会逐条唤醒 Agent，而是 debounce 后批量唤醒——InputAdapter 将短时间窗口内到达的消息聚合（如聊天连续几条消息、邮件批量到达），达到时间窗口或数量阈值后统一触发一次 Agent 工作循环。Agent 被唤醒后通过 channel.read 一次拉取该批消息，在同一轮 sense 中处理，处理完后通过 channel.ack 批量确认。这避免了高频消息场景下的循环风暴。

Agent 通过三个标准操作与所有 Channel 交互（详细接口见 §11.6）：

channel.read：批量读取通道的未处理消息。Agent 在 sense 阶段聚合上下文时使用——如一次拉取多封新邮件、读取聊天窗口的最近消息、获取语音转写的多段文本。纯读操作，无需审批。
channel.suggest：向通道建议发送一条消息。suggest 不直接投递，而是产出 PendingMessage，进入人工审批流。人类 Agent 在工作台看到待发送内容的预览（邮件草稿、TTS 预听、聊天消息预览），批准后 OutputAdapter 才执行实际投递。命名为 suggest 而非 write，因为 AI 只是提出建议，发送权在人。
channel.ack：批量确认消息已处理。接受消息 ID 数组，一次确认多条。用于关闭消息流中的待处理项（如标记一批邮件已回复、标记多条聊天消息已处理），维护消息流的处理状态。

channel.suggest → 审批 → 投递流程：

Agent 调用 channel.suggest(channel_id, message)
    │
    ▼
系统创建 PendingMessage（status: pending_approval）
    │
    ▼
人类 Agent 工作台显示待审批消息
  ┌──────────────────────────────────────────┐
  │ AI 建议发送邮件给 customer@example.com     │
  │ 主题：退货申请确认                          │
  │ 内容：尊敬的客户，您的退货申请已批准...      │
  │                                            │
  │ [✓ 批准]  [✎ 编辑后批准]  [✗ 拒绝]        │
  └──────────────────────────────────────────┘
    │
    ├── 批准 → OutputAdapter.format() → deliver() → 写入 timeline
    ├── 编辑后批准 → 人工修改内容 → deliver() → 写入 timeline
    └── 拒绝 → 写入 timeline（记录拒绝原因）→ Agent 在下轮 reflect 中学习

审批策略可按通道类型和消息类型配置。初始默认所有 channel.suggest 需人工批准；随 AI 准确率提升和信任积累，可逐步放宽：模板化消息（如收件确认）可配置为自动批准，自由文本消息仍需人工审核。这与门禁机制（§5.5）共享同一个审批基础设施，但 channel.suggest 的审批是消息级的（"这条邮件能不能发"），门禁审批是动作级的（"这个退款方案能不能执行"）。

核心设计原则：

标准化契约：所有 Channel 的 normalize() 输出同一结构的 CaseEvent（完整数据结构见 §9.2），所有 Channel 的 format() 接收同一结构的消息。通道差异在适配器层吸收，Agent 工作循环完全不感知通道类型。
能力声明：每个 Channel 声明方向（inbound/outbound/bidirectional）和支持的消息类型。Agent 通过 channel.list 发现可用通道，据此决定交互方式——例如向不支持文件上传的通道发送文字引导而非"请上传文件"。
Channel 即插件：Channel 是插件系统（§5.3）的自然实例。新通道接入只需实现 InputAdapter 和/或 OutputAdapter 标准接口并注册。平台内置基础 Channel（在线聊天），其余通道通过插件加载。Channel 插件无需定义自己的工具——channel.read/suggest/ack 是平台核心工具，自动适用于所有注册的 Channel。
Direction 决定能力：inbound 通道只能 read/ack（如纯接收的 webhook），outbound 通道只能 suggest（如纯发送的 SMS），bidirectional 通道支持全部操作。Agent 调用 channel.list 即可知道每个通道支持哪些操作。

通道能力矩阵：

通道类型	方向	输入特征	输出特征	典型接入方
语音（voice）	bidirectional	实时音频流 → ASR 转写	TTS 语音合成 / Agent 屏幕文本	Contact Center
在线聊天（chat）	bidirectional	离散文本消息 + 附件	富文本 + 按钮 + 卡片	消息平台 webhook
邮件（email）	bidirectional	异步到达 + 结构化附件	格式化邮件（模板渲染）	邮件服务
短信（sms）	outbound	—	短文本	短信网关
API/Webhook	inbound	已结构化事件	—	外部业务系统
内部操作（internal）	bidirectional	结构化表单 + 自由文本	Agent 工作台 UI 组件	内部操作界面

CaseEvent 标准格式：所有通道的输入经 normalize() 后统一为 CaseEvent，核心字段：

id：事件唯一标识
case_id：关联的案件 ID（新案件则由系统自动创建）
type：事件类型（input / ai_reasoning / ai_action / human_decision / system）
source：来源通道与会话标识
timestamp：事件发生时间
content：原始内容（文本 / 文件引用）
extracted_facts：AI 预抽取的结构化字段（可为空，由后续 sense 阶段补全）
trace_id：端到端追踪 ID

事件写入 Case 后即触发工作循环的下一轮 sense。

Case 与 Session 的关系：

Session 是单次交互会话（一通电话、一段聊天对话、一封邮件往来），Case 是业务实体（一个退货申请、一次故障排查）。两者是多对一关系：

一个 Case 可跨多个 Session。客户第一通电话报障，挂断后补传材料触发第二次聊天 Session，次日来电跟进进度是第三个 Session——三个 Session 的事件全部写入同一 Case，AI 在完整上下文上持续推理（场景二、场景四的核心能力）。
一个 Session 通常对应一个 Case，但也可能在单次会话中涉及多个 Case（客户一通电话同时咨询退货和发票问题）。此时 Channel 的 InputAdapter 负责按意图将事件路由到不同 Case。
Session 携带通道上下文：每个 Session 记录 channel_type、session_id、起止时间。CaseEvent 的 source 字段（如 voice:session_abc123）关联到具体 Session，支持按 Session 回溯单次交互的完整对话。
Session 是短暂的，Case 是持久的。Session 结束后归档为 Case timeline 的一段；Case 的生命周期跨越所有 Session，直到业务闭环。

示例：Contact Center 语音通道

以场景一（客户来电反馈耳机有电流噪音）为例，展示一个语音 Channel 的完整 I/O 链路。

输入侧——从音频流到 CaseEvent：

客户说话（音频流）
  → Contact Center 的 ASR 引擎实时转写
    → Voice Channel InputAdapter 接收转写流
      → 断句聚合：按语义边界将连续转写片段合并为完整语句
        → normalize(): 每条完整语句生成一个 CaseEvent
          {
            type: "input",
            source: "voice:session_abc123",
            content: "耳机有电流噪音，买了大概一个多月了",
            metadata: {
              channel: "voice",
              asr_confidence: 0.92,
              speaker: "customer",
              segment_index: 3
            }
          }

输入侧的关键处理：

断句聚合：ASR 输出是词级或短语级的流式片段，InputAdapter 按语义边界（停顿、语气词、话题切换）聚合为完整语句再生成事件，避免碎片化事件淹没工作循环。
说话人分离：区分客户和 Agent 的话语，分别标记 speaker 字段。Agent 的话语也写入 Case timeline，确保上下文完整。
ASR 置信度传递：转写的置信度写入 metadata，sense 阶段据此决定是否需要对关键信息做二次确认（如客户报出的订单号 ASR 置信度偏低时，建议 Agent 口头复述确认）。
跨通道关联：同一通话中客户在聊天窗口补传检测截图时，Chat Channel 生成的 CaseEvent 自动关联到同一 case_id。多个 Channel 可同时服务同一 Case。

输出侧——从 AI 响应到通道交付：

AI 工作循环产出结构化响应后，Voice Channel 的 OutputAdapter 将其分发到两个目标：

AI 结构化响应
  ├── → Agent 屏幕（OutputAdapter.format → 工作台 UI 组件）
  │     显示：事实面板更新 + 建议动作 "请确认客户是否有第三方检测报告"
  │
  └── → 语音合成（可选，OutputAdapter.format → TTS 引擎）
        播放：自动语音提示或 IVR 导航

Agent 屏幕输出是主路径——场景一中 Agent 看到的"一条精确引导"就是 OutputAdapter 将 AI 的建议格式化为工作台 UI 组件。语音合成是辅助路径，适用于 IVR 自助场景或 AI 直接与客户对话的场景（Phase 3）。

Channel 生命周期事件：

除了业务内容，Channel 还上报生命周期事件，系统据此管理 Case 状态：

生命周期事件	转换为 CaseEvent	系统响应
通话接入	`type: system, content: call_started`	创建或关联 Case，启动工作循环
客户保持（hold）	`type: system, content: call_hold`	工作循环暂停实时处理，继续后台分析
通话转接	`type: system, content: call_transfer`	更新 `assigned_to`，保持 Case 上下文连续
通话结束	`type: system, content: call_ended`	触发 reflect 阶段，生成通话摘要
连接断开（异常）	`type: system, content: call_dropped`	标记为异常中断，按配置自动外呼回拨或转异步跟进

Integration 模式：

Contact Center 与本系统的集成不要求替换现有电话基础设施（§7.4 Scope Out）。集成方式为标准 API 对接：

Contact Center 负责：电话接入、ACD 排队、ASR 转写、通话录音、TTS 播放
本系统负责：接收转写流、AI 处理、向 Agent 屏幕推送建议、向 Contact Center 回传控制指令（如转接、保持）
集成接口：Contact Center 通过 WebSocket 推送实时转写流和生命周期事件，本系统通过 REST API 回传控制指令
适用于主流 Contact Center 平台（Genesys、Amazon Connect、Twilio Flex 等），各平台差异在 Voice Channel 插件层吸收

5.7 记忆与经验体系

经验记忆是系统从"每次从头处理"进化到"持续学习"的核心机制。

记忆层次：

案件内记忆（Case Context）：单个案件生命周期内的所有事件、AI 推理过程、人工决策和执行结果。随案件关闭归档，供审计和回溯。
组织级经验（Experience Memory）：跨案件沉淀的判断模式，供新案件的 think 阶段检索参考。这是系统"越用越准"的基础。

经验结构——每条经验记录包含：

场景特征：触发条件的结构化描述（案件类型、关键字段组合、异常模式）。
判断路径：根因 → 方案 → 执行动作的完整链路。
效果反馈：方案执行后的结果（成功 / 失败 / 部分成功）和关键业务指标变化。
来源标记：AI 自主决策 or 人工覆盖，以及覆盖原因。

检索与匹配：新案件进入 think 阶段时，系统基于当前场景特征对经验记忆做相似性检索。命中的经验作为参考依据纳入推理——不是机械套用历史方案，而是在相似上下文中提供历史参照，AI 根据当前具体条件做适应性调整。如场景四中，第三次投诉命中了"同类投诉升级"的经验，直接建议更高补偿档位。

经验生命周期：

新经验初始权重较低，随成功复用次数递增而增强。
被人工覆盖的经验标记为"需校准"，触发定期审查。
长期未命中或多次失效的经验自动降权，避免过时知识干扰判断。

6. Agent 能力矩阵

核心能力

能力	描述	作用于不确定性
上下文融合	合并语音、聊天、文档、历史记录	解决信息碎片化
事实建模	从非结构化输入抽取结构化事实+置信度	解决信息不完整
路径规划	在多个可行动作中选择最优路径	解决流程分叉
风险分层	自动识别高风险并触发门禁	控制自动化失误
动态重规划	新信息到来后实时调整处理步骤	解决场景漂移
经验沉淀	将个案策略沉淀为可复用知识	解决”每次从头来”
冲突消解	多规则/多约束冲突时生成结构化权衡分析	解决规则矛盾
主动补全	识别缺失信息并生成定向追问或自动查询	解决信息缺口

运行约束

单次推理延迟预算 < 3s（不含外部系统 IO）。
低置信度必须降级人工，不允许”带病自动执行”。
所有自动动作必须具备可追溯证据链。
channel.suggest 审批通过后的投递必须有回执与失败重试（最多 3 次指数退避），重试仍失败写入 timeline 并告警。
同一 Case 的并发事件处理须串行化，避免竞态写入导致状态不一致。
涉及客户个人信息的 AI 推理遵循数据最小化原则，仅传入当前决策必需的字段。
经验记忆检索延迟 < 500ms，不显著增加单轮循环耗时。
上下文窗口超限时按优先级截断，确保当前事实和近期事件不被丢弃。

成功标准

自动化率：标准案件全自动处理率 > 80%；非标案件中 AI 独立完成的步骤占比 > 60%。
处理效率：非标个案平均处理时长较传统流程下降 50% 以上（含人工审批等待时间）。
决策质量：AI 自主决策的事后质检合格率 > 95%；人工覆盖率（AI 建议被人推翻的比例）逐月下降。
经验复用：同类非标问题复发时，首轮方案命中率逐月提升；经验记忆的检索命中对处理时长的缩短效果可量化追踪。
系统韧性：AI 服务降级时，基础工作流功能不受影响；恢复后自动补偿降级期间积压的 AI 处理任务。

7. 分期规划与范围边界

§4 的十个场景覆盖了从单案件处理到批量调度、从单团队到跨团队的完整能力谱。不可能一步到位全部实现。分期策略的核心逻辑是：先跑通最小闭环证明范式可行（Phase 1），再叠加智能层扩展能力边界（Phase 2），最后追求规模化自主（Phase 3）。每一期的范围由"能独立交付业务价值"划定，而非按技术模块切分。

7.1 Phase 1 — 核心流程闭环（MVP）

目标：跑通单案件从接入到关闭的完整 AI 驱动流程，验证 sense→think→act→reflect 循环的工程可行性。

范围：

Schema 引擎：支持声明式字段定义、类型校验、必填约束、证据来源映射
Workflow 引擎：基础状态机（接入→信息收集→方案生成→审批→执行→关闭），支持超时和降级
Agent 工作循环：完整的 sense→think→act→reflect 实现
核心 MCP Tools：case.*、schema.validate、workflow.*、kb.search、audit.query、channel.*（list/read/suggest/ack）
内置插件工具：ext.query、ext.execute（退货执行等写操作所需）
插件加载机制：支持通过配置注册插件工具，Phase 1 以内置插件为主
单通道接入：内置 Chat Channel（bidirectional），Agent 通过 channel.suggest 提交回复，人类 Agent 审批后投递
channel.suggest 审批：所有 AI 产出的客户触达消息需人工批准，基础审批 UI 集成于 Agent 工作台
人工门禁：基础审批流（固定阈值，按金额和置信度触发）
案件内记忆（Case Context）：单案件生命周期内的事件流和 AI 推理轨迹
Skill 逻辑以硬编码方式实现（信息抽取、方案评估等核心处理逻辑内置于 Agent 工作循环）
支持 2-3 个案件类型：退货申请、客户投诉
Agent 工作台和审批视图的基础实现

不含：组织级经验记忆、多通道接入、风险评分引擎、动态优先级、声明式 Skill 编排系统、批量处理、插件市场

7.2 Phase 2 — 智能层与多通道

目标：引入经验记忆实现跨案件学习，扩展接入通道，支持更复杂的业务场景。

范围：

组织级经验记忆（Experience Memory）：沉淀、检索、复用（§5.7）
多通道接入：Voice Channel（语音转写流，bidirectional）、Email Channel（邮件收发，bidirectional）、SMS Channel（outbound）、API/Webhook Channel（inbound），Agent 通过统一的 channel.* 操作与所有通道交互
插件系统正式化：标准插件 SDK、插件注册/发现/版本管理、权限隔离
插件工具扩展：risk.score_case（风险评分）、doc.ocr/doc.extract（文档处理）
声明式 Skill 系统：Skill 配置、触发条件匹配、多 Skill 串联，支持以 Skill 插件形式发布和加载
动态门禁：基于 AI 历史准确率持续校准阈值
批量处理能力（场景五的分群+批量审批模式）
主管面板：基础优先级队列、团队指标看板
扩展至 5-10 个案件类型

7.3 Phase 3 — 规模化与自主演进

目标：系统具备自适应、自演化能力，支持大规模并发和跨团队协作。

范围：

动态优先级调度（场景十）：多维实时计算
主动预警（场景八）：从个案聚合中识别系统性问题
跨团队编排（场景七）：并行工作流与依赖排序
Skill 自动演化：AI 基于已有 Skill 组合生成候选新 Skill，经人工审核后纳入
插件市场：第三方开发者可发布 Tool 插件、Skill 插件、Channel 插件和预配置 Agent 模板，组织按需订阅
高级分析与运营仪表盘

7.4 范围边界（Scope Out）

以下能力不在本产品范围内：

不做	原因
自建 Contact Center / 电话基础设施	通过接口对接现有 PBX/CTI 系统，语音通道由外部 Contact Center 提供实时转写流
替代 CRM / ERP / 财务系统	通过 MCP `ext.*` 工具集成现有业务系统，不重复建设
AI 模型训练	使用现有 LLM API（如 Claude），不自建训练管线；经验记忆通过 RAG 而非微调实现
终端客户界面	本系统服务内部操作人员（Agent、主管、管理员），不直接面向终端客户
知识库内容管理	不替代已有 KB 系统，通过 `kb.search` 工具对接

8. 用户角色与权限

§2 提出"AI 驱动流程，人类作为审批节点"，但"人类"不是一个角色——场景一的一线 Agent、场景三的部门主管、场景八的质量经理，他们看到的界面不同、能做的操作不同、承担的责任也不同。本节定义系统中的六类用户角色，明确每类角色的职责边界和权限等级。

8.1 角色定义

角色	职责	系统权限	对应场景
一线 Agent	接听客户、跟随 AI 引导完成信息收集、执行低风险操作	查看案件详情、确认 AI 建议、触发低风险动作（发通知、更新状态）、转交审批	场景一
团队主管 / 组长	审批中风险方案、处理 AI 无法覆盖的例外、管理队列优先级	审批案件（金额阈值内）、覆盖 AI 决策（需填写理由）、调整队列优先级、查看团队指标	场景四、九、十
部门主管	高风险审批、政策例外授权、跨部门资源协调	审批高金额操作、授权政策例外、跨部门工作流协调	场景三
技术支持工程师	技术类案件的诊断与修复执行	查看系统指标、执行只读诊断工具、提交修复方案审批	场景二、七
质量 / 合规人员	事后审计、质检抽检、系统性问题跟踪	查看完整审计轨迹、执行质检抽检、查看聚合分析报告、标记经验为"需校准"	场景六、八
系统管理员	配置 Schema、Workflow、Skill、门禁阈值	全部配置权限、系统监控、AI 降级 / 恢复切换、用户权限管理	—

8.2 权限模型

权限按操作风险分级，与 §2 门禁机制和 §5.5 置信度机制对齐：

权限级别	操作示例	可执行角色
只读	查看案件、查看审计轨迹、查看指标	所有角色
低风险写入	更新案件字段、发送通知、确认 AI 建议	一线 Agent 及以上
中风险审批	退款 ≤ ¥5,000、补偿发放、例外通道审批	团队主管及以上
高风险审批	退款 > ¥5,000、生产参数变更、政策例外授权	部门主管及以上
系统配置	Schema / Workflow / Skill 定义、门禁阈值调整	系统管理员

审批金额阈值为示例值，实际部署时按业务需求配置。

9. 数据模型

9.1 Schema 定义结构

场景一中，客户来电反馈耳机有电流噪音。系统需要知道：订单号、产品型号、购买时间、退货原因、故障描述、检测报告。这些"系统需要知道什么"就是 Schema 的字段定义。"超时效但有质量主张 → 走例外通道"就是约束规则。"检测报告从客户上传获取、订单号从订单系统自动拉取"就是来源映射。Schema 将这三者统一为一个声明式定义——AI 在 sense 阶段依照 Schema 做定向抽取，Workflow 依照 Schema 的完整度判断能否推进。

Schema 由以下部分组成：

组成部分	说明
`fields`	字段定义：名称、类型、是否必填、数据来源、抽取置信度阈值
`computed_fields`	计算字段：基于已有字段通过公式推导，不需要外部输入
`constraints`	约束规则：基于字段值的条件判断，决定流程走向（通过 / 升级 / 拒绝）
字段级 `source`	证据来源映射：每个字段通过 `source` 属性声明数据从哪个通道或外部系统获取（见下方 YAML 示例）

示例：退货申请 Schema

schema:
  id: return_request
  name: 退货申请
  version: 1

  fields:
    - name: order_id
      type: string
      required: true
      source: customer_input
      validation: "^ORD-\\d{10}$"

    - name: product_sku
      type: string
      required: true
      source: ext.query(order_service, {order_id})  # 从订单系统自动关联

    - name: purchase_date
      type: date
      required: true
      source: ext.query(order_service, {order_id})

    - name: return_reason
      type: enum[quality_issue, wrong_item, changed_mind, not_as_described, other]
      required: true
      source: ai_extract(customer_input)             # AI 从客户描述中抽取
      confidence_threshold: 0.85                      # 低于此值标记为待确认

    - name: fault_description
      type: text
      required: true
      source: ai_extract(customer_input)

    - name: evidence_documents
      type: file[]
      required_when: "return_reason == quality_issue"
      accepted_types: [image/jpeg, image/png, application/pdf]

    - name: customer_value_tier
      type: enum[standard, silver, gold, enterprise]
      source: ext.query(crm_service, {customer_id})   # 从 CRM 自动拉取

  computed_fields:
    - name: days_since_purchase
      formula: "datediff(now(), purchase_date)"

    - name: within_return_period
      formula: "days_since_purchase <= policy.return_period_days"

    - name: exception_eligible
      formula: >
        !within_return_period
        AND return_reason == quality_issue
        AND len(evidence_documents) > 0

  constraints:
    - id: standard_return
      when: "within_return_period"
      then: proceed

    - id: exception_channel
      when: "exception_eligible"
      then: escalate(gateway: exception_approval)

    - id: reject_no_basis
      when: "!within_return_period AND !exception_eligible"
      then: reject(reason: "超出退货时效且不满足例外条件")

Schema 字段的 source 声明了数据来源——AI 在 sense 阶段据此决定是从客户输入中抽取、从外部系统查询、还是通过计算推导。confidence_threshold 告诉 AI：如果抽取置信度低于此值，该字段标记为"待确认"而非直接采用。

9.2 Case 模型

Case 是系统的核心实体，承载一个案件从创建到关闭的完整生命周期。

Case
├── id                  string         全局唯一标识
├── schema_id           string         关联的 Schema 定义（决定案件类型）
├── status              CaseStatus     pending | processing | awaiting_human | resolved | closed
├── facts               Map<string, FactValue>   Schema 字段的当前值与置信度
├── timeline            CaseEvent[]    按时间排序的完整事件流
├── workflow_id         string         关联的 Workflow 定义
├── workflow_state      string         当前所在状态节点
├── assigned_to         string?        当前负责人（人工）
├── priority_score      float          优先级分数（Phase 1 静态值，Phase 2 基础排序，Phase 3 多维实时计算）
├── sla_deadline        timestamp?     SLA 截止时间
├── parent_case_id      string?        关联的父案件（用于案件关联，如场景四）
├── sessions            Session[]      关联的交互会话列表（§5.6 Case 与 Session 的关系）
├── tags                string[]
├── created_at          timestamp
├── updated_at          timestamp
└── resolved_at         timestamp?

Session——单次交互会话，一个 Case 可跨多个 Session（§5.6）：

Session
├── id                  string         会话唯一标识
├── case_id             string         所属案件
├── channel_type        ChannelType    voice | chat | email | api | internal
├── channel_id          string         通道实例标识
├── started_at          timestamp      会话开始时间
├── ended_at            timestamp?     会话结束时间（进行中为空）
└── status              SessionStatus  active | ended | dropped

CaseEvent 的 source 字段（如 voice:session_abc123）关联到具体 Session，支持按 Session 维度回溯单次交互。

FactValue——Schema 字段的值不是裸值，而是带置信度和来源的结构：

FactValue
├── value               any            字段值
├── confidence          float          0.0 ~ 1.0，AI 抽取的置信度
├── source              string         来源：ai_extract | ext_query | human_input | computed
├── extracted_at        timestamp      获取时间
└── verified_by         string?        人工确认者（如有）

CaseEvent——Case 的 timeline 由事件组成，每个事件不可变：

CaseEvent
├── id                  string
├── case_id             string
├── type                EventType      input | ai_reasoning | ai_action | human_decision | system
├── source              string         来源通道或组件标识
├── timestamp           timestamp
├── content             any            事件内容（结构因 type 而异）
├── extracted_facts     Map<string, FactValue>?   sense 阶段抽取的事实
└── trace_id            string         端到端追踪 ID

9.3 Experience 模型

经验记忆的存储结构，对应 §5.7 中描述的组织级经验。

Experience
├── id                  string
├── scenario_signature                 用于相似性检索的场景特征
│   ├── case_type       string         Schema ID
│   ├── key_features    Map<string, any>   触发该经验的关键字段组合
│   └── anomaly_pattern string?        异常模式描述（如"批次性配对失败"）
├── judgment_path                      判断路径
│   ├── root_cause      string         根因
│   ├── solution        string         方案
│   └── actions_taken   string[]       执行的具体动作
├── outcome                            效果反馈
│   ├── result          ResultType     success | failure | partial
│   └── business_impact Map<string, number>   关键指标变化
├── provenance                         来源标记
│   ├── type            SourceType     ai_autonomous | human_override
│   ├── override_reason string?        人工覆盖理由（场景九）
│   └── original_suggestion string?    AI 原始建议（被覆盖时保留）
├── weight              float          初始 1.0，成功复用 +0.1，失效 -0.2
├── hit_count           int            被检索命中的次数
├── last_hit_at         timestamp
├── status              ExperienceStatus   active | needs_calibration | deprecated
└── created_at          timestamp

scenario_signature 用于新案件的相似性检索——进入 think 阶段时，系统将当前案件的 (case_type, key_features) 与经验库做向量 + 结构化混合检索，返回 top-k 匹配结果作为推理参考。

10. Workflow 状态机详细设计

§5.2 描述了 Agent 在每个状态节点执行 sense → think → act → reflect 循环，但没有回答：状态从哪来？转移条件是什么？什么时候该拦住让人审批？这些是 Workflow 的职责。Schema 定义"需要知道什么"，Workflow 定义"按什么路径推进"——两者共同构成 AI 的决策约束框架。

10.1 Workflow 结构定义

Workflow
├── id                  string         唯一标识
├── name                string         流程名称
├── schema_id           string         适用的 Schema（案件类型）
├── states              WorkflowState[]   状态节点列表
├── transitions         Transition[]      状态转移规则
├── global_timeout      duration          全流程超时（如 7d）
└── timeout_action      string            超时处置：escalate | auto_close

WorkflowState
├── id                  string         状态标识
├── name                string         显示名称
├── type                StateType      start | ai_processing | gateway | human_review | terminal
├── available_skills    string[]       AI 在此状态可执行的 Skill 列表
├── entry_conditions    Condition[]    进入此状态的前置条件（Schema 字段要求）
├── max_duration        duration?      状态级超时
└── timeout_action      string?        超时处置：escalate | auto_transition | notify

Transition
├── id                  string
├── from_state          string         起始状态
├── to_state            string         目标状态
├── trigger             TriggerType    auto | event | human_approval | timeout | condition
├── conditions          Condition[]    触发条件
└── gateway             GatewayRule?   如需人工审批

GatewayRule
├── trigger_when        Condition      门禁触发条件（如 amount > 5000）
├── approval_role       string         审批角色（如 team_lead、department_head）
├── approval_package    string[]       审批包必含字段
├── sla                 duration       审批时限
└── timeout_action      TimeoutAction  超时处置：escalate | auto_reject | auto_approve

10.2 示例：退货流程状态机

以场景一为基础，展示完整的 Workflow 定义。下方状态节点中的"可用 Skill"描述的是目标态能力——Phase 1 中这些 Skill 逻辑以硬编码方式内置于 Agent 工作循环（§7.1），Phase 2 引入声明式 Skill 系统后迁移为可配置的 Skill 插件。

状态流转图：

[接入] → [信息收集] → [方案生成] → <门禁判断> ─┬─ AI 直接通过 ──→ [执行] → [验证] → [关闭]
              ↑                                 │
              │                            门禁触发
              │                                 ↓
              └──── 要求补充信息 ←── [人工审批] ──┘
                                         │
                                    降级 / 驳回
                                         ↓
                                    [人工接管]

状态节点定义：

状态	类型	可用 Skill	进入条件	超时策略
接入	start	`信息抽取`	新案件创建	5min → 自动分配
信息收集	ai_processing	`信息抽取`、`信息补全`、`定向追问`	自动进入	24h → 通知客户催办
方案生成	ai_processing	`方案评估`；`风险评分`（Phase 2+）	必需字段完整度 ≥ Schema 阈值	30min → 降级人工
门禁判断	gateway	—	方案生成完成	—
人工审批	human_review	—	门禁触发	4h → 升级上级
执行	ai_processing	`退货执行`、`通知发送`（via `channel.suggest`）	审批通过或门禁未触发	10min → 告警
验证	ai_processing	`结果校验`	执行完成	1h → 人工验证
关闭	terminal	`经验沉淀`	验证通过	—
人工接管	terminal	—	任意状态降级	—

门禁触发规则（本 Workflow）：

条件	审批角色
退款金额 > ¥500	团队主管
退款金额 > ¥5,000	部门主管
例外通道（超时效退货）	团队主管
AI 方案置信度 < 0.7	团队主管

10.3 Skill 与 Workflow 的协同关系

Workflow 和 Skill 职责不同，边界清晰：

职责划分：

Workflow 管"在哪、该不该"：定义案件当前处于什么状态、下一步可以往哪走、是否需要人工审批。Workflow 是状态机，关注状态流转和门禁控制。
Skill 管"怎么做"：封装特定场景的处理知识——调用哪些 Tool、按什么策略、如何应对异常。Skill 是可动态加载的领域技能，关注知识编排。

协作方式：

Workflow 的每个 ai_processing 状态节点声明可用的 Skill 列表。AI 在工作循环的 act 阶段根据当前上下文选择并执行合适的 Skill。Skill 执行完成后将结果反馈给 Workflow 引擎，由 Workflow 判断是否满足状态转移条件。

Workflow（状态流转层）
  └── State: 方案生成
        ├── 可用 Skill: [方案评估, 风险评分]
        └── AI 选择 Skill → Skill: 方案评估
              └── Tool 调用链: schema.validate → risk.score_case → workflow.next_step
              └── 输出: 方案 + 置信度 → 回传 Workflow → 判断是否触发门禁

复用关系：一个 Skill 可被多个 Workflow 的不同状态复用。例如 信息抽取 Skill 同时用于退货流程和投诉流程的信息收集阶段，因为底层 Tool 调用链相同，差异由 Schema 定义吸收。

11. 接口规格（MCP Tool）

§5.1 将 Tool 分为核心工具（平台内置）和插件工具（动态加载）。本节定义各 Tool 的入参、出参和关键约束——§11.1-§11.6 为核心工具（含通道操作），§11.7-§11.9 为插件工具示例。接口为早期版本，随实现迭代细化。

11.1 案件操作

case.create

参数	类型	必填	说明
schema_id	string	是	案件类型（对应 Schema ID）
source	string	是	来源通道标识
initial_facts	Map	否	初始字段值

返回：{ case_id, workflow_id, initial_state }

case.get

参数	类型	必填	说明
case_id	string	是	案件 ID
include	string[]	否	可选包含：facts, timeline, experience_hits

返回：完整 Case 对象（§9.2）

case.update

参数	类型	必填	说明
case_id	string	是	案件 ID
facts	Map<string, FactValue>	是	要更新的字段
reason	string	是	变更原因（写入 timeline）

返回：{ diff: FieldDiff[], validation: ValidationResult }

幂等约束：同一 (case_id, field, value, timestamp) 重复调用不产生新 timeline 事件。

11.2 结构校验

schema.validate

参数	类型	必填	说明
schema_id	string	是	Schema ID
facts	Map	是	待校验的字段值

{
  valid:        boolean       // 是否全部通过
  completeness: float         // 必需字段填充率 0.0~1.0
  errors:       [{ field, rule, message }]   // 校验失败项
  missing:      string[]      // 缺失的必需字段
}

11.3 工作流

workflow.next_step

参数	类型	必填	说明
case_id	string	是	案件 ID

{
  current_state:           string
  available_transitions:   Transition[]    // 当前可走的转移
  blocked_by:              string[]?       // 阻塞原因（如缺失字段）
  recommended:             string?         // AI 推荐的转移
}

workflow.trigger

参数	类型	必填	说明
case_id	string	是	案件 ID
transition_id	string	是	要触发的转移
reason	string	是	触发理由

返回：{ success, new_state, gateway_triggered, approval_request_id? }

11.4 审计

audit.query

参数	类型	必填	说明
case_id	string	否	按案件查询
actor	string	否	按操作者查询
time_range	object	否	时间范围 { from, to }
action_type	string	否	按操作类型过滤

返回：{ events: CaseEvent[] }（按时间排序，支持分页）

11.5 知识与记忆

kb.search

参数	类型	必填	说明
query	string	是	检索文本
case_type	string	否	限定案件类型
top_k	int	否	返回条数，默认 5

返回：{ results: [{ id, title, content, relevance }] }

memory.search_experience

参数	类型	必填	说明
scenario_signature	object	是	场景特征（case_type + key_features）
top_k	int	否	返回条数，默认 3

返回：{ experiences: Experience[] }（按相关性排序）

检索延迟约束：< 500ms（§6 运行约束）。

memory.upsert_case_memory

参数	类型	必填	说明
case_id	string	是	来源案件
experience	Experience	是	要写入的经验记录（§9.3）

返回：{ experience_id, merged_with? }

如果新经验与已有经验的 scenario_signature 高度相似，系统合并而非创建新条目。

11.6 通道操作

Agent 通过以下四个核心工具与所有 Channel 交互（Channel 模型见 §5.6）。

channel.list

参数	类型	必填	说明
case_id	string	否	过滤与特定案件关联的通道
direction	string	否	按方向过滤（inbound / outbound / bidirectional）
type	string	否	按通道类型过滤（email, sms, chat, voice 等）

{
  channels: [
    {
      id:            string       // 通道实例标识，如 "email-main"
      type:          string       // 通道类型
      direction:     string       // inbound | outbound | bidirectional
      status:        string       // active | degraded | offline
      operations:    string[]     // 可用操作：["read", "suggest", "ack"] 的子集
      message_schema: object      // 该通道 metadata 扩展字段规格
    }
  ]
}

Agent 在 act 阶段需要通信时，先调用 channel.list 发现可用通道及其方向，再决定通过哪个通道发送。

channel.read

参数	类型	必填	说明
channel_id	string	是	通道实例标识
case_id	string	否	过滤特定案件的消息
since	timestamp	否	起始时间
limit	int	否	返回条数上限，默认 20

{
  messages: [
    {
      id:          string       // 消息标识
      direction:   string       // inbound | outbound
      content:     string       // 消息内容
      metadata:    object       // 通道特定字段（如邮件主题、发件人）
      timestamp:   string       // 时间戳
      status:      string       // received | sent | pending_approval | rejected
    }
  ]
}

纯读操作，无需审批。Agent 在 sense 阶段用于聚合通道上下文（如回看邮件往来、聊天历史）。

channel.suggest

参数	类型	必填	说明
channel_id	string	是	目标通道实例标识
case_id	string	是	关联案件（写入 timeline）
content	string	条件	消息内容（template_id 为空时必填）
template_id	string	否	消息模板标识
metadata	object	否	通道特定字段（如邮件主题/收件人、短信签名、TTS voice_id）

{
  pending_id:    string       // PendingMessage 标识
  status:        string       // pending_approval（默认）| auto_approved
  preview:       string       // 格式化预览（供人类 Agent 审批时查看）
  channel_type:  string       // 目标通道类型
}

channel.suggest 不直接投递消息。它创建一个 PendingMessage，进入人类 Agent 的审批队列。人类 Agent 可批准、编辑后批准或拒绝。批准后由 Channel 的 OutputAdapter 执行实际投递。审批策略可按通道和消息类型配置——模板化消息（如收件确认）可配置为自动批准，自由文本消息默认需人工审核（详见 §5.6）。

channel.ack

参数	类型	必填	说明
channel_id	string	是	通道实例标识
message_ids	string[]	是	待确认的消息标识数组（支持批量）
case_id	string	是	关联案件

返回：{ acked: int, failed: string[] }

批量标记消息已处理。Agent 在一轮 sense 中通过 channel.read 拉取一批消息并处理后，通过 channel.ack 一次性确认整批，避免逐条确认的开销。

以下为插件工具的接口规格示例（§11.7-§11.9）。实际部署中，插件工具通过插件 SDK 按相同规范实现并注册。

11.7 文档处理

doc.ocr

参数	类型	必填	说明
file_ref	string	是	文件引用（来自 CaseEvent 的附件）
language_hint	string	否	语言提示，默认 auto

返回：{ text, confidence, regions: [{ bbox, text, confidence }] }

doc.extract

参数	类型	必填	说明
file_ref	string	是	文件引用
schema_id	string	是	目标 Schema（决定抽取哪些字段）

返回：{ extracted_facts: Map<string, FactValue>, raw_text }

doc.extract 基于 doc.ocr 的输出做结构化抽取，将文档内容映射为 Schema 字段。如场景一中客户上传检测报告，doc.ocr 识别文字后 doc.extract 抽取出检测结论、检测机构、日期等字段。

11.8 外部系统

ext.query

参数	类型	必填	说明
system	string	是	目标系统标识（如 order_service, crm）
operation	string	是	查询操作（如 get_order）
params	Map	是	查询参数
timeout	int	否	超时毫秒数，默认 5000

返回：{ data, cached, latency_ms }

ext.execute（写操作）

参数	类型	必填	说明
system	string	是	目标系统
operation	string	是	写操作（如 issue_refund）
params	Map	是	操作参数
idempotency_key	string	是	幂等键
approval_id	string	否	审批记录 ID（高风险操作必填）

返回：{ success, result, rollback_id }

rollback_id 用于需要回滚时调用逆操作。

11.9 风险评估

risk.score_case

参数	类型	必填	说明
case_id	string	是	案件 ID

{
  overall_score:              float         // 0.0~1.0
  risk_factors:               [{ factor, score, explanation }]
  recommended_gateway_level:  string        // auto | supervisor | manager
}

12. 界面与交互要求

场景一中，Agent 屏幕上显示的"不是一堆文章，而是一条精确引导"；场景三中，主管"直接在量化方案中选择并确认"；场景十中，主管看到的是"实时更新的优先级面板"。这些描述勾勒了界面的设计意图，但没有定义具体信息架构。本节将场景中的交互愿景落地为四个核心界面的功能要求。视觉设计交由 UI/UX 设计阶段细化。

12.1 Agent 工作台

一线 Agent 处理案件的主界面。核心设计原则：AI 引导，人确认——Agent 不需要从多个系统拼凑信息，系统主动推送结构化建议。

信息架构：

区域	内容	交互
案件事实面板	Schema 字段当前值、置信度指示（高/中/低）、缺失字段高亮	点击字段可手动修正值
对话 / 事件流	按时间展示客户消息、AI 推理摘要、系统事件；AI 推理过程可展开查看详情	滚动浏览，展开/折叠 AI 推理
AI 建议面板	当前推荐动作、依据摘要（结构化）、备选方案（如有）	一键确认 / 选择备选 / 手动修改后确认
待发送消息队列	AI 通过 `channel.suggest` 提交的待审批消息，按通道类型分组显示格式化预览	批准 / 编辑后批准 / 拒绝（§5.6）
快捷操作栏	确认建议、转人工、补充信息、关闭案件	按钮操作

关键行为：

AI 识别到缺失字段时，在建议面板显示定向追问话术，Agent 可直接复制发送或改写
客户上传文件后自动触发 doc.ocr + doc.extract，结果填充到事实面板，Agent 可修正
案件状态变化时实时更新，无需手动刷新
多案件切换时保持各案件独立上下文

12.2 审批视图

审批人处理门禁拦截的界面。核心设计原则：快速决策，留痕追溯——审批人能在最短时间内理解案件并做出判断。

审批包内容：

组成	说明
案件摘要	案件类型、客户信息、核心诉求（一句话）
AI 推荐方案	推荐方案 + 理由（结构化，非大段文字）
依据对比	每项判断依据附具体数值和对应阈值，如"超期 4 天 / 例外阈值 7 天"
备选方案	如有多个可行方案，并列展示差异对比（如场景三）
历史参照	经验记忆命中的类似案件及其处理结果（Phase 2）
风险提示	不同选择的风险说明

操作选项：批准 / 驳回 / 修改方案 / 要求补充信息——每项操作均要求填写理由（回写 timeline，供 reflect 阶段学习）。

12.3 主管面板

团队主管的队列管理与监控界面。

核心功能：

功能	说明
优先级队列	按动态优先级排序的案件列表，每个案件附 SLA 倒计时、预估处理时间、排序理由
团队指标	当前积压量、平均处理时长、AI 自动化率、人工覆盖率
异常告警	SLA 即将违约的案件、AI 置信度持续偏低的案件类型、人工覆盖率异常上升的场景
队列干预	手动调整优先级、重新分配案件、批量审批（Phase 2）

主管对优先级的手动调整作为反馈信号回流，校准动态优先级模型（Phase 3）。

12.4 配置界面

系统管理员配置 Schema、Workflow、Skill 和门禁的界面。

配置项	形式	说明
Schema 编辑器	表单式字段定义	添加/修改字段、设置校验规则、配置来源映射和置信度阈值
Workflow 编辑器	可视化状态机	拖拽式状态和转移编辑，节点上配置门禁规则和超时策略
Skill 配置	声明式表单	配置触发条件、Tool 调用链、降级策略
门禁阈值管理	参数面板	按案件类型和风险等级配置阈值，展示当前 AI 准确率作为调参参考

配置变更需经过审核流程（至少一人 review），变更历史可追溯。

13. 部署与运维

早期阶段简要描述架构原则和关键运维要求，详细部署方案在技术设计阶段细化。

13.1 架构原则

无状态服务：Agent 工作循环实例无状态，Case 上下文从存储层按需加载，支持水平扩缩容。单实例故障不影响其他案件处理。
存储分层：Case 数据使用关系型数据库（事务一致性）；事件流使用追加写入存储；经验记忆使用向量数据库 + 结构化索引（支持混合检索）。
AI 服务隔离：LLM 调用通过独立的 AI Gateway 层，支持多模型切换、请求限流、成本追踪、熔断降级。AI 服务不可用不影响基础工作流运行。

13.2 降级策略

AI 服务不可用时，系统自动切换为传统工作流模式：

保持运行：状态流转、人工审批、通知发送等基础功能正常工作
暂停功能：AI 自动方案生成、经验检索、动态优先级计算暂停，案件自动进入人工处理队列
恢复补偿：AI 服务恢复后，自动补处理降级期间积压的 AI 任务，优先处理 SLA 紧迫的案件

13.3 关键监控指标

指标	告警阈值（参考）
AI 推理延迟 P95	> 5s
MCP Tool 调用成功率	< 99%
门禁触发率（按案件类型）	突变 ±20%
人工覆盖率（周趋势）	连续上升 3 周
经验记忆检索延迟 P95	> 800ms
SLA 达标率	< 95%

13.4 数据安全

客户个人信息加密存储，AI 推理时按数据最小化原则仅传入当前决策必需字段
审计日志不可篡改（追加写入），支持合规审查
角色权限控制（§8），敏感操作需二次认证
外部系统集成通过 MCP 标准协议，凭证统一管理，不在 Tool 层面暴露