ai-ticket-platform/docs/product/blueprint.md

AI 工单平台项目蓝图

更新日期：2026-07-27 状态：当前唯一主蓝图
适用范围：产品设计、架构设计、研发排期、阶段验收 评估口径：当前完成情况仅根据仓库代码静态分析得出，不包含运行、联调或业务验证

1. 蓝图结论

本项目定位为面向单企业私有化部署的 Agent-native ToB 技术支持平台。平台以工单为业务载体，以知识资产为处理依据，以原生 Agent、Skill、Tool、MCP 和模型能力为自动化引擎，持续完成以下闭环：

问题受理
  → 智能建单
  → 知识检索与问题排查
  → 形成解决方案和客户回复
  → 工单解决与人工关闭
  → 知识价值判断
  → 知识/排查方案审核发布
  → 重新进入后续问题检索

平台首先解决业务问题、技术问题、数据问题、操作问题以及对接类技术支持工单，核心价值是：

• 减少技术支持在信息整理、重复排查、建单和知识整理上的人力成本。
• 让 Agent 在明确权限内自动建单、补充字段、流转工单、检索知识和生成处理建议。
• 通过人工确认保护发布知识、关闭工单和回复客户等关键动作。
• 将每次有效处理结果沉淀为可审核、可追溯、可复用的组织知识。
• 在模型、检索或外部工具不可用时保留完整人工处理能力。

目标架构不依赖 Dify。本项目自身提供 Agent 运行、Skill 编排、模型调用、工具授权、知识检索和人工确认能力，用于替换现有 Dify 工作流。

当前系统暂时无法获取服务群消息，因此服务群读取和自动回复不进入首个业务版本；所有受理和回复能力必须通过统一渠道接口设计，为后续接入服务群、邮件或外部 API 保留入口。

2. 产品目标与边界

2.1 核心目标

平台接收以下输入：

• 技术支持粘贴的聊天文本。
• 多张聊天截图。
• PDF、TXT、日志和常见 Office 文档。
• 技术支持补充的问题描述或图片说明。
• 系统内历史工单、解决方案、知识条目和排查方案。

平台形成以下输出：

• 结构化工单及完整处理时间线。
• 可引用依据的排查步骤、候选方案和客户回复草稿。
• 在授权条件内自动更新、流转或解决的工单。
• 从已解决工单提炼的知识和排查方案草稿。
• 经人工审核发布并重新进入检索的知识资产。
• 可审计的 Agent 决策、模型调用、工具调用和人工确认记录。

2.2 首个业务版本范围

首个业务版本必须打通：

人工上传聊天材料
  → Agent 解析
  → 自动创建正式工单
  → Agent 检索与排查
  → 生成/复用解决方案
  → 生成客户回复并人工确认已发送
  → Agent 标记已解决
  → 人工关闭
  → 生成知识草稿
  → 审核发布
  → 建立检索索引

首个业务版本不要求：

• 自动读取服务群消息。
• 自动向服务群发送回复。
• 客户登录平台自助查看工单。
• 历史数据迁移。
• 多租户隔离。
• 复杂 BPMN 或自由画布式工作流编排。
• 无人值守执行高风险或生产变更工具。
• 完整生产部署体系；首个业务版本以开发环境可运行作为部署要求。

2.3 后续扩展范围

• 服务群、邮件和外部 API 渠道接入。
• 人工确认后的渠道自动回复及外部消息回执。
• OIDC、LDAP 等企业身份认证。
• stdio MCP 服务。
• 生产部署、监控、告警、备份和恢复演练。
• 后台可配置的多级分类树和更完整的 SLA 策略。

3. 用户与职责

角色	核心职责	关键权限
技术支持	受理问题、补充材料、处理工单、确认客户回复、提交知识审核	建单、修改、接单、流转、标记已解决、编辑知识草稿
支持负责人	管理支持团队、协调工单、处理例外和质量复核	技术支持权限、改派、协作人管理、自动化降级
知识管理员	保证知识和排查方案的准确性与可复用性	审核、驳回、发布、下线、回滚；不得审核本人提交内容
系统管理员	管理用户、角色、模型、Agent、Skill、工具和策略	系统配置、授权、风险策略、全局自动化开关
只读审计员	检查业务变更、AI 与工具调用是否合规	只读查询工单事件、模型调用、知识引用、工具调用和确认记录

首期客户不登录系统。客户沟通仍发生在外部服务群中，由技术支持复制系统生成的话术，并在平台内确认实际已发送。

4. 现行业务流程与目标流程

4.1 现行业务流程

客户在服务群 @技术支持
  → 技术支持人工排查
  → 给出解决方案
  → 回复客户
  → 事后创建工单
  → 填写负责人、分类、描述、方案、机构等字段
  → 完成并关闭工单

该流程存在以下问题：

• 工单在处理结束后才补录，无法承载实时协作和过程追踪。
• 聊天信息、排查依据和关键时间主要依赖人工整理。
• 相同问题重复排查，历史工单和知识资产未形成统一检索入口。
• 解决方案、客户话术和知识沉淀彼此割裂。
• 难以量化 Agent 对建单、排查和知识复用的实际价值。

4.2 目标业务流程

flowchart LR
    A["技术支持上传聊天文本、截图和附件"] --> B["工单受理 Agent 解析"]
    B --> C{"能否形成有效问题描述"}
    C -- "否" --> D["生成待补全任务"]
    D --> B
    C -- "是" --> E["自动创建正式工单"]
    E --> F["支持分析 Agent 检索并排查"]
    F --> G{"满足自动复用条件"}
    G -- "是" --> H["复用已发布方案并标记已解决"]
    G -- "否" --> I["输出排查建议和候选方案"]
    I --> J["人工处理或补充结果"]
    H --> K["生成客户回复草稿"]
    J --> K
    K --> L["技术支持确认已发送"]
    L --> M["人工关闭工单"]
    M --> N["知识沉淀 Agent 评估"]
    N --> O["生成知识和排查方案草稿"]
    O --> P["知识管理员审核发布"]
    P --> Q["切片、向量化并进入检索"]

目标流程将工单从“事后记录”调整为“问题处理对象”。只要 Agent 能形成有效问题描述，即可创建正式工单；机构、负责人、分类和时间等其他字段允许后续补全。

5. 权限与自动化边界

5.1 基本原则

一次 Agent 行为的有效权限取以下条件的交集：

当前用户权限
∩ Agent 被授予的业务权限
∩ Tool/MCP 工具授权
∩ 当前工单或知识状态允许的操作

Agent 不得通过直接写数据库绕过业务服务、状态机、权限校验和审计。

5.2 动作权限矩阵

动作	Agent 自动执行	人工确认	说明
创建工单	是	否	有效问题描述形成后即可创建
修改工单字段	是	否	不得静默覆盖人工修改字段
补充负责人、机构、分类和时间	是	否	必须保存字段来源和置信度
流转到处理中、待确认	是	否	受状态机和权限约束
标记工单已解决	条件允许	否	仅限满足自动解决策略的方案
关闭工单	否	是	由有关闭权限的人员确认
生成客户回复草稿	是	否	草稿不等于已回复
回复客户/确认已发送	否	是	保存最终话术和实际回复时间
生成知识草稿	是	否	生成后进入编辑或审核流程
发布、下线知识	否	是	由知识管理员操作
只读工具调用	授权后允许	可配置	仍需记录输入范围和调用审计
低风险写工具调用	条件允许	可配置	受用户、Agent、工具授权约束
高风险或生产变更	否	是	每次调用单独确认

5.3 人工字段保护

每个可由 Agent 填写的核心字段需要记录：

• 当前值来源：人工、Agent、外部渠道或系统计算。
• 产生该值的运行、步骤和输入证据。
• 置信度和产生时间。
• 是否已被人工修改或锁定。

人工修改后的字段默认进入保护状态。后续 Agent 可以提出修改建议，但不得静默覆盖；只有人工明确采纳或业务规则允许时才能更新。

6. 工单体系

6.1 工单分类

首期保持四个一级分类：

• 业务问题。
• 技术问题。
• 数据问题。
• 操作问题。

对接问题根据实际内容归入业务或技术问题，并保留标签、产品和模块等维度进行细分。后续将分类扩展为后台可配置的多级分类树，但首期不因分类配置阻塞业务闭环。

6.2 工单状态

工单保留现有六个状态：

pending_info
  → pending
  → in_progress
  → pending_confirm
  → resolved
  → closed

状态含义：

状态	含义
pending_info	信息不足，等待技术支持补充材料
pending	已形成有效工单，等待受理
in_progress	正在排查或处理
pending_confirm	已形成候选结论，等待确认、回复或外部验证
resolved	问题已有明确解决结果，可由 Agent 在授权条件下进入
closed	业务确认结束，只能由人工关闭

关闭后如需继续处理，应通过重新打开事件恢复到受控状态，不直接修改历史事件。删除采用软删除或归档，不物理删除业务记录。

6.3 工单核心信息

• 标题、问题描述、一级分类、标签、优先级。
• 提问机构、产品、模块和环境。
• 主负责人、协作人和关注人。
• 当前状态、解决结果、关闭原因。
• 原始聊天记录、截图和附件。
• 知识引用、排查步骤、候选方案和最终采纳方案。
• 客户回复草稿、最终回复话术和发送确认。
• Agent 运行、模型调用、工具调用和人工决定。

6.4 业务时间线

工单需要支持：

• problem_started_at：问题开始时间。
• customer_last_message_at：客户最后一次消息时间。
• support_first_response_at：技术支持首次响应时间。
• support_last_reply_at：技术支持最后回复时间。
• resolved_at：工单解决时间。
• closed_at：工单关闭时间。

从聊天材料提取的时间必须保存原始证据、解析结果和时区。无法可靠确定的时间保持为空并生成补全提示，不使用当前时间冒充业务时间。

6.5 附件策略

首期支持图片、PDF、TXT、日志和常见 Office 文档。默认限制：

• 单文件最大 20 MB。
• 单次最多 10 个文件。
• 单次上传总量最大 100 MB。
• 限制值由后台配置，不硬编码在业务页面。
• 服务端校验扩展名、MIME、文件签名和大小。
• 文件进入解析或模型处理前执行恶意文件扫描。
• 业务表只保存对象引用、摘要、类型和审计信息，实际文件存储在 MinIO。

相同材料重复上传时允许创建多个独立工单。系统只提示相似工单及相似度，不强制合并或阻止建单。

7. 智能受理与多模态建单

7.1 输入处理

技术支持可在一次受理中同时提交：

• 粘贴的聊天文本。
• 多张按顺序排列的聊天截图。
• 文档或日志附件。
• 补充问题描述。
• 对图片、说话人或时间的人工说明。

工单受理 Agent 直接使用文本和视觉模型处理组合输入，不引入 Dify 中间工作流。

7.2 结构化结果

解析结果至少包括：

• 标准消息时间线：说话人、角色、内容、时间、来源材料。
• 建议标题和问题描述。
• 提问机构、分类、产品、模块和环境。
• 问题开始时间、最后客户消息时间、最后支持回复时间。
• 已尝试动作、错误信息、客户诉求和当前结果。
• 每个字段的置信度、来源证据和冲突说明。
• 缺失字段和建议追问内容。

当存在多张截图或多份材料时，Agent 需要进行顺序合并、重复内容识别和时间冲突标记；不能确定的说话人或时间不得伪造。

7.3 建单策略

• 只要能形成有效问题描述，即可自动创建正式工单。
• 其他缺失字段形成站内待补全任务，不阻塞建单。
• 自动建单保存受理输入快照、解析版本和 Agent 运行引用。
• 模型或文件解析失败时，保留全部原始材料并允许人工建单。
• 长任务立即返回运行 ID，前端通过 SSE 展示解析、提取、检索、创建和失败步骤。

8. 支持分析与自动解决

8.1 检索范围

支持分析 Agent 默认检索：

• 已发布知识条目。
• 已发布排查方案。
• 已发布解决方案。
• 已解决或已关闭的历史工单。

草稿、待审核、已驳回、已下线内容不得作为自动解决依据；有权限的人员可以在后台预览，但必须明确标识其非正式状态。

8.2 检索策略

正式检索采用：

PostgreSQL 全文/关键词召回
  + pgvector 向量召回
  → 结果合并和去重
  → 可配置重排模型
  → 权限、状态、分类和适用范围过滤
  → 返回带引用的结果

每条结果必须携带来源类型、版本、标题、片段、相似度、适用范围和引用定位。模型生成的结论与检索到的依据必须在界面中分开展示。

8.3 自动复用与自动解决

默认自动复用条件：

• 综合相似度不低于 0.85。
• 分类和适用范围一致。
• 方案处于已发布状态。
• 方案显式标记为允许自动解决。
• 方案不要求人工操作、外部确认或生产环境变更。
• 当前用户和 Agent 均具有标记已解决的权限。

匹配阈值、适用范围和自动解决开关由后台配置。当多个高分方案冲突、证据不足或风险条件不满足时，必须降级为人工推荐，不得自动解决。

8.4 客户回复

支持分析 Agent 根据问题、处理过程、已采纳方案和引用依据生成客户回复草稿。首期流程：

1. 技术支持查看并编辑回复草稿。
2. 技术支持复制最终话术到服务群。
3. 技术支持在平台确认已发送。
4. 系统保存草稿、最终话术、确认人和实际回复时间。

未来渠道接入后仍保持人工确认边界：确认后由渠道适配器发送，并回写外部消息 ID、发送时间和失败原因。

9. 知识与排查方案体系

9.1 资产类型

平台分别管理：

• KnowledgeArticle：业务规则、产品说明、技术原理和通用知识。
• TroubleshootingPlan：面向问题类型的标准排查步骤、判断条件和分支。
• Solution：可直接应用于具体问题的解决方案和客户话术依据。

三类资产分别建模，但共享版本、审核、引用、检索、适用范围、权限和影响分析能力。

9.2 生命周期

draft
  → pending_review
  → published

pending_review
  → rejected
  → draft

published
  → offline
  → 新版本 draft

• 已发布版本不可原地修改。
• 修改已发布内容时创建新版本。
• 支持版本比较和回滚；回滚本质上发布一个以历史版本为内容的新版本。
• 技术支持可以编辑并提交审核。
• 知识管理员负责审核、驳回、发布和下线。
• 提交人不能审核自己提交的版本。

9.3 知识沉淀

工单进入 resolved 后，知识沉淀 Agent 异步评估：

• 新颖性。
• 复用价值。
• 处理过程完整度。
• 与现有知识的重复度。
• 是否包含可泛化的排查步骤。
• 是否包含敏感信息或只适用于单一客户的内容。

Agent 可以生成知识条目草稿、排查方案草稿以及解决方案草稿。技术支持也可手工标记工单为优先沉淀，不受自动评分限制。

发布后自动执行切片、Embedding、索引更新和引用关系建立。新版本发布时保留旧版本引用，后续检索默认只返回当前有效版本。

10. Agent、Skill、模型与决策轨迹

10.1 内置业务 Agent

Agent	职责
工单受理 Agent	解析聊天和附件、提取字段、创建工单、生成补全任务
支持分析 Agent	检索知识、生成排查步骤、推荐或复用方案、生成客户回复
知识沉淀 Agent	判断知识价值、生成知识/排查方案草稿、准备审核材料

平台采用内置业务场景加可配置步骤链，不建设 Dify 式自由画布。业务动作、检索、回复生成和工具调用以版本化 Skill 步骤实现。

10.2 模型绑定

模型按步骤和能力绑定：

• 文本理解与生成。
• 视觉理解。
• Embedding。
• 重排。

Agent 运行需要保存实际使用的 Agent 版本、Skill 版本、模型部署、提示模板、知识范围、工具授权和关键策略快照，避免配置变化后无法解释历史结果。

10.3 结构化决策轨迹

平台不保存或展示模型原始思维链。对用户可见、可审计的内容限定为：

• 运行目标和步骤状态。
• 输入摘要和数据范围。
• 检索引用和版本。
• 工具调用及结果摘要。
• 关键判断理由。
• 结构化产物。
• 人工修改、采纳、拒绝和确认。
• 最终业务结果。

模型失败、结构化输出不合法或结果不可信时，支持步骤级重试、结构修复和人工降级。

11. Tool 与 MCP 扩展体系

11.1 统一工具目录

以下能力进入统一工具目录：

• 工单、知识、用户和系统中的原生业务动作。
• MCP 同步的外部工具。
• 未来的服务群、邮件和外部 API 渠道动作。

每个工具需要定义：

• 唯一标识、名称、来源和版本。
• 输入输出 Schema。
• 风险等级和是否需要逐次确认。
• 可调用的角色、用户和 Agent。
• 数据访问范围和超时策略。
• 脱敏、审计和失败降级策略。

11.2 风险等级

等级	典型动作	默认策略
只读	查询机构、系统状态、业务配置	明确授权后可自动调用
低风险写	创建内部记录、更新非关键状态	用户、Agent 和工具权限交集满足后执行，可配置确认
高风险写	生产变更、外部发送、删除或不可逆操作	每次调用必须人工确认

首个 MCP 里程碑支持远程 HTTP MCP 服务，并通过一个真实内部只读查询工具完成服务注册、工具同步、Agent 授权、调用、结果展示和审计闭环。stdio MCP 放在后续扩展。

12. 任务中心、审计与数据治理

12.1 站内任务中心

首期任务中心统一承载：

• 待补全工单。
• 待确认客户回复。
• 待人工关闭工单。
• 待审核知识和排查方案。
• 待确认高风险工具调用。
• Agent 运行失败和需要人工接管的步骤。

首期只采集 SLA 数据，不执行自动升级。后续可将任务通知推送到服务群、邮件或企业消息渠道。

12.2 审计要求

以下事件必须可查询并可关联到用户、Agent 运行和业务对象：

• 工单创建、字段修改、负责人和协作人变化、状态流转、解决与关闭。
• 知识提交、审核、发布、驳回、下线和回滚。
• 模型调用、数据范围、用量、错误和结构修复。
• 检索条件、返回引用和最终采纳。
• 工具授权、工具调用、人工确认和执行结果。
• 客户回复草稿修改与发送确认。
• 自动化策略和权限配置变更。

12.3 数据保留

• 原始聊天文本、截图和附件与工单绑定，按权限访问，保留期限可配置。
• 工单、知识版本、引用、人工决定和审计记录长期保留。
• 完整模型输入输出用于诊断，默认保留 90 天，可由管理员配置。
• 超过诊断保留期后仍保留模型、版本、用量、数据范围摘要、结构化产物和最终业务结果。
• 管理员启用的模型渠道视为可信渠道，可接收原始聊天文本和截图，无需每次单独确认；每次调用仍必须记录审计和数据范围快照。

13. 目标系统架构

flowchart TB
    UI["React / Vite 工作台与后台"] --> API["Django Ninja 业务 API"]
    UI --> SSE["SSE 运行进度与任务更新"]

    API --> TICKET["工单与受理域"]
    API --> KNOWLEDGE["知识、排查方案与解决方案域"]
    API --> ADMIN["账号、权限、配置与审计域"]
    API --> AGENT["Agent / Skill 编排域"]
    API --> TOOL["统一 Tool / MCP / 渠道域"]

    AGENT --> QUEUE["Celery / Redis 异步执行"]
    QUEUE --> MODEL["文本、视觉、Embedding、重排模型"]
    QUEUE --> SEARCH["全文检索 + pgvector + 重排"]
    QUEUE --> TOOL

    TICKET --> PG["PostgreSQL"]
    KNOWLEDGE --> PG
    ADMIN --> PG
    AGENT --> PG
    SEARCH --> PG

    TICKET --> OBJECT["MinIO 原始材料与附件"]
    KNOWLEDGE --> OBJECT
    TOOL --> MCP["远程 HTTP MCP"]
    TOOL --> CHANNEL["预留服务群、邮件、外部 API"]

架构继续采用模块化单体，不在首个业务版本拆分微服务。业务写操作必须通过领域服务完成；Celery 任务、Agent 和 Tool 只负责调度或调用领域服务。

长任务统一返回运行 ID，并通过 SSE 提供：

• 当前步骤和总体状态。
• 结构化产物摘要。
• 引用和工具调用。
• 失败原因、可重试步骤。
• 待人工确认任务。
• 断线重连所需的事件序号。

14. 核心公共实体与能力接口

14.1 业务实体

实体	作用
TicketIntake	统一接收人工上传及未来渠道输入
ChatRecord	保存一次受理的原始聊天材料
MessageTimeline	保存规范化后的消息序列
FieldEvidence	记录字段值、来源、置信度和人工保护状态
Ticket	工单当前业务事实
TicketEvent	工单不可变业务事件
TicketCollaborator	协作人和关注人关系
TicketAttachment	工单附件及对象存储引用
KnowledgeArticle	业务和技术知识
TroubleshootingPlan	标准排查流程
Solution	可复用解决方案
CustomerReplyTask	回复草稿、最终话术和发送确认
ConfirmationTask	关闭、发布、回复或高风险工具的人工确认

14.2 Agent 与工具实体

实体	作用
AgentRun	一次业务 Agent 运行及配置快照
AgentStep	运行中的版本化步骤
AgentArtifact	消息时间线、排查建议、方案和回复等结构化产物
AgentReference	产物引用的知识、工单、方案或工具结果
ArtifactDecision	人工采纳、修改、拒绝和确认
UnifiedTool	原生 Tool、MCP 和渠道动作的统一定义
ToolAuthorization	用户、角色和 Agent 的工具授权
ToolCall	工具调用请求、确认、结果和错误
ChannelAdapter	外部渠道接收、发送和消息回执契约

14.3 能力接口约束

• TicketIntake 接口接收文本、附件引用、来源渠道和补充说明，返回受理 ID 与异步运行 ID。
• Agent 运行接口支持查询快照、步骤、产物、引用、错误、重试和取消。
• SSE 接口按运行 ID 输出有序事件，支持客户端按最后事件序号重连。
• 工单变更接口统一执行权限、状态机、人工字段保护和审计。
• 检索接口返回带版本和定位信息的引用，不只返回模型生成文本。
• 知识发布接口必须校验审核权限、自审限制和版本状态，并触发异步索引。
• Tool 调用接口必须先计算有效权限和风险策略；需要确认时只创建确认任务，不立即执行。
• 渠道发送接口只接受已确认的 CustomerReplyTask，并回写外部消息标识和结果。

15. 当前代码完成情况

15.1 评估说明

本节只根据截至 2026-07-27 的仓库代码结构、模型、路由、服务、回归测试和前端实现判断。 阶段 1、阶段 2 工程能力、阶段 3.1～3.3、阶段 3.4 任务/SLA、阶段 4 知识治理和 知识蒸馏、阶段 3 业务指标验收工具、阶段 4 安全文档导入、阶段 5 Tool/MCP 工程闭环与 真实 HTTP Agent 调用，以及阶段 6 通用渠道和生产运维工程基线、工单协作界面和步骤级 模型绑定和企业身份工程基线完成后，整体完成度估计为 95%–97%； 阶段 2/3 的脱敏真实案例业务指标、阶段 3.2 的 PostgreSQL 与真实模型服务指标、 阶段 4 的真实模型知识闭环、真实企业渠道、真实 IdP/LDAP 目录联调和生产告警/异地备份 仍未验收。 仓库已提供统一蓝图就绪报告，将阶段 2～6 的真实案例、真实服务和恢复证据收敛为 9 个 机器可读门槛；当前环境仅隔离一致性恢复通过，其余门槛保持 not_ready，不得用工程回归 替代业务与环境验收。

现有项目已具备较好的后台和 Agent 基础设施，但首个业务闭环仍未完成。后续研发应优先复用已有模型管理、Agent 版本、异步运行和受理草稿能力，避免重新建设一套平行平台。

15.2 模块评估

模块	状态	代码现状	与目标差距
账号、角色和后台管理	工程完成、待企业联调	已有五类默认角色、细粒度权限、OIDC 授权码登录、加密提供方配置、外部身份绑定、受控组织映射和标准化目录同步；LDAP 已定义可信适配器边界	待真实 IdP、LDAP/组织目录和故障降级验收
工单 CRUD 与状态流转	已完成	已统一工单领域服务、解决结果、分派/解决/关闭/归档权限和归档入口，Agent 与 Tool 调用均受有效权限交集约束	待真实业务量验证权限策略
工单草稿与智能建单	工程完成	文本、图片、文档、消息时间线、字段证据、幂等自动建单、待补全任务、SSE 和人工降级已形成闭环	等待脱敏真实案例验证 70% 自动建单率和 90% 字段准确率
附件体系	工程完成	通用材料支持 MinIO、扩展名/MIME/签名/大小校验、ClamAV 扫描、文档解析和失败隔离	后续补充生产扫描容量、保留策略和运维监控
评论与协作	已完成	详情页按作者、时间和可见范围展示完整评论历史；协作人和关注人可从启用账号中受权限控制地添加、移除，只读账号仅查看	待真实业务量验证协作流程
解决方案	工程闭环、待业务验收	TicketResolution 已成为权威结果；方案具备统一版本审核、范围、风险资格、策略开关和受控自动采纳	需要以真实案例验证错误复用率和知识蒸馏方案质量
知识库	工程闭环、待环境验收	知识、排查方案和解决方案共享草稿、独立审核、发布、驳回、下线、比较和回滚；PDF/TXT/LOG/Office 原件可上传并经过格式校验、恶意扫描、异步解析和 pgvector 索引，失败保留原件并可受控重试	待真实 MinIO、ClamAV、Embedding 服务和发布后召回验收
模型管理	工程完成、待生产验收	已有渠道、部署、文本、视觉、Embedding、重排能力配置和凭据加密；Agent 步骤可独立绑定文本或视觉部署并继承默认部署	待生产模型连通性、容量和质量验收
Skill 与 Agent 配置	已完成为主	已有版本化 Skill、Agent、步骤级模型部署和运行配置；草稿克隆保留步骤覆盖关系	需要围绕三个真实业务 Agent 固化输入输出和业务服务调用
Agent 异步运行	已完成为主	Celery 顺序步骤、步骤有效模型冻结、尝试记录、重试、取消、结构修复、运行快照、Agent 动作授权、真实工单支持分析和知识蒸馏已可用；图片只发送给获授权的视觉步骤	需要继续接入更多 Tool/MCP 业务结果并完成生产模型验收
知识蒸馏 Agent	工程闭环、待环境验收	已解决工单自动触发价值评估，冻结去重依据并生成受治理知识、排查方案和可选解决方案草稿；失败进入人工接管	待真实模型验证去标识化、重复判断、草稿质量和发布后召回
支持分析 Agent	工程闭环、待环境验收	真实工单可运行可信混合检索，查看冻结引用；策略满足时受控采纳方案，否则展示降级原因；回复进入人工任务	待真实模型环境和脱敏案例验证召回、自动解决及人工降级指标
检索与引用	工程完成、待环境验收	已接入 pgvector、正式 Embedding、PostgreSQL 全文/向量双路召回、可配置模型重排、历史工单持久化索引和结构化范围过滤；冻结模型、通道、分项分数、降级状态、范围及引用快照	待 PostgreSQL + 真实 Embedding/重排服务完成召回率、延迟与 HNSW 参数验收
Tool 与 MCP	已完成	已有统一目录、HTTP MCP 服务接入/同步/调用、用户/用户组/Agent 授权交集、风险快照、高风险双人确认、幂等、调用审计和管理界面；内部只读工单查询已通过真实 HTTP Agent 调用	生产部署时配置独立令牌并按企业网络边界限制访问
人工确认任务	工程完成为主	客户回复、人工关闭、知识审核和高风险工具调用均有正式任务与独立确认约束	待真实业务量验证处理时效
任务中心与 SLA	工程完成为主	WorkItem 已承载待补全、受理/分析/蒸馏失败、客户回复、人工关闭、知识审核和高风险工具确认；可配置截止时间并汇总 SLA	待真实业务量验证
渠道接入	工程完成、待真实渠道验收	已有加密适配器配置、HMAC 签名入站、消息/会话去重、冻结回复任务版本、Celery 幂等出站、送达/失败回执、失败重试、操作审计和治理页面；只有送达回执才确认客户回复	待至少一个真实企业服务群完成签名、认证、出站和回执联调
审计	已完成为主	已有审计模型、操作人输出及按模块、动作、对象、结果、用户和时间过滤；Agent、知识和 Tool/MCP 均记录业务快照与关联	后续补充生产级归档和报表
部署与运维	工程基线与隔离恢复已完成	已有独立生产 Compose、Gunicorn、Nginx、依赖健康检查、存活/就绪探针、Prometheus/Alertmanager、失败与积压告警规则，以及 PostgreSQL/MinIO 跨平台备份、校验、恢复、调度、安全裁剪和自动隔离演练；工单、附件和对象一致性恢复已通过	待配置真实告警接收方、安装备份调度并执行异地加密保留

15.3 主要结构债务

• 旧知识分块仍保留 JSON 向量用于平滑重建；生产检索已转向 pgvector，确定性哈希只允许 在测试配置中作为 portable 回退。
• CustomerReplyTask 已成为正式回复事实，replied_to_customer 暂保留为旧接口兼容镜像， 后续版本可在客户端全部迁移后移除。
• 文档知识导入已形成原件存储、安全扫描、异步解析、索引、失败重试和管理界面闭环； Agent/Tool 关联和生产部署仍需在真实企业环境验证，知识版本与审核审计仍需真实案例 验证内容去标识化和发布后召回。

16. 分阶段实施路线

阶段 1：数据与领域基线重构

状态：已完成（2026-07-25）

目标：消除会影响后续闭环的权威数据和权限问题。

实施内容：

• 允许清空开发数据库并重新生成迁移，不承担历史数据兼容。
• 统一工单解决结果模型，清理重复解决字段和绕过状态机的写入。
• 所有工单状态变化统一经过领域服务。
• 补齐主负责人、协作人、关注人和软删除归档。
• 建立字段来源、字段证据和人工保护机制。
• 统一 ticket.assign、ticket.resolve、ticket.close 等细粒度权限。
• 扩展审计查询和业务对象关联。

退出条件：

• 工单 CRUD、流转、解决、关闭和归档具有唯一业务入口。
• Agent 无法绕过权限和状态机直接修改核心业务表。
• 人工修改字段不会被后续 Agent 静默覆盖。

阶段 2：多模态智能建单

目标：将人工上传的聊天材料自动转为正式工单。

实施内容：

• 完成统一文件受理、MinIO 存储、格式校验、限制策略和恶意文件扫描。
• 建立聊天记录、标准消息时间线和字段证据模型。
• 组合处理粘贴文本、截图、附件和补充说明。
• 使用视觉和文本模型提取字段、关键时间、已尝试动作和缺失信息。
• 有效问题描述形成后自动创建正式工单。
• 提供相似工单提示、待补全任务和人工降级入口。
• 使用运行 ID 和 SSE 展示实时进度。

退出条件：

• 混合文本和截图可自动创建正式工单。
• 原始材料、解析结果和字段证据可追溯。
• 模型或解析失败后仍可继续人工建单。

阶段 3：智能支持闭环

目标：让真实工单可以使用 Agent 完成检索、排查、方案复用和客户回复。

实施内容：

• 将 PostgreSQL 全文检索、pgvector 和重排接入正式业务。
• 在工单详情展示检索依据、排查步骤、候选方案和 Agent 运行状态。
• 落实 0.85 默认阈值、范围一致性、方案发布状态和风险条件。
• 对满足条件的工单自动复用方案并标记已解决。
• 建立客户回复任务、最终话术和人工发送确认。
• 建设站内任务中心和 SLA 指标采集。

退出条件：

• 支持分析 Agent 连接真实工单，不再使用演示数据。
• 所有建议均能追溯到知识、方案、历史工单或工具结果。
• 自动解决严格受策略、权限和审计约束。

阶段 4：知识审核闭环

状态：工程能力已完成，真实环境闭环待验收（2026-07-27）

目标：将已解决工单持续转化为可复用知识。

实施内容：

• 建立知识、排查方案和解决方案的统一版本审核能力。
• 工单解决后异步执行知识价值评估。
• 生成知识和排查方案草稿，并支持技术支持编辑提交。
• 实现审核、驳回、发布、下线、版本比较和回滚。
• 阻止提交人自审。
• 发布后自动切片、Embedding、索引和引用关系更新。
• 展示知识被工单、方案和 Agent 引用的影响范围。

退出条件：

• 从工单受理到知识发布并重新进入检索的闭环完整可用。
• 发布版本不可原地修改，所有审核和版本变化可追溯。
• 本阶段完成即达到首个业务版本交付目标。

阶段 5：Agent 与 MCP 扩展

状态：已完成（2026-07-27）

目标：形成安全、可配置、可审计的 Agent 扩展体系。

实施内容：

• 固化三个内置业务 Agent 和版本化 Skill 契约。
• 完善步骤级模型绑定与运行配置快照。
• 统一原生业务 Tool、MCP 工具和未来渠道动作。
• 建立工具风险等级、授权交集、确认任务和调用审计。
• 支持远程 HTTP MCP 服务注册和工具同步。
• 接入一个真实内部只读查询工具完成端到端验收。

退出条件：

• 未授权 Tool/MCP 调用全部被拦截。
• 只读 MCP 可被 Agent 调用，并可追溯授权、输入、结果和业务影响。
• 高风险工具没有人工确认时无法执行。

阶段 6：渠道与企业生产化

目标：在业务闭环稳定后接入真实外部渠道和生产运维能力。

实施内容：

• 通过 ChannelAdapter 接入服务群消息读取。
• 对人工确认的客户回复执行渠道发送并保存回执。
• 预留 OIDC、LDAP 和企业组织同步。
• 完善生产 Docker Compose、正式应用服务器、健康检查、监控和告警。
• 建立 PostgreSQL 与 MinIO 每日备份、恢复脚本和定期恢复演练。

当前工程进展：

• 通用 generic_webhook 适配器已完成签名入站、会话/消息去重、冻结回复任务版本、 Celery 幂等出站、回执归档、失败重试、审计和治理页面；送达前不确认客户回复。
• 生产 Compose、Gunicorn、Nginx、依赖健康检查、存活/就绪探针、Prometheus 低基数指标、Alertmanager 和失败/积压告警规则已完成。
• PostgreSQL 与 MinIO 备份、结构校验、SHA-256 校验、受确认保护的恢复、安全裁剪脚本 和 cron 调度示例已完成；Windows PowerShell 入口和独立 Compose 自动恢复演练已补齐， 工单、附件元数据和对象内容一致性恢复在 106.57 秒内通过。
• OIDC 授权码登录、加密提供方配置、外部身份绑定、企业组织映射、标准化目录同步和 LDAP 可信适配器契约已完成，并提供系统治理界面与独立验收手册。
• 真实企业渠道联调、真实 IdP 与 LDAP/组织目录联调、真实生产告警接收方、备份调度安装 和异地加密保留尚未完成， 因此阶段 6 仍处于进行中。

退出条件：

• 渠道接入不改变工单受理和回复任务的领域接口。
• 外部发送失败可重试且不会重复回复。
• 数据库和对象存储可通过演练恢复到一致状态。

17. 成功指标与验收

17.1 业务指标

指标	目标
有效输入自动建单率	≥ 70%
自动建单字段准确率	≥ 90%
已发布方案自动匹配率	≥ 50%
符合自动处理条件的工单自动解决率	≥ 30%
错误自动复用率	≤ 5%
未授权操作拦截率	100%

“有效输入”指至少包含可识别问题描述且文件能够正常读取的受理材料；自动解决率只统计显式允许自动解决且满足范围、相似度和风险条件的工单。

17.2 回归案例集

由技术支持维护脱敏真实案例集，每个案例至少包含：

• 聊天文本、截图和附件。
• 期望消息时间线。
• 期望工单字段和关键时间。
• 正确分类、排查方案和解决方案。
• 允许或禁止自动解决的原因。
• 期望客户回复。
• 应生成或不应生成的知识草稿。

17.3 必测场景

• 文本、单图、多图、文本加图片和文档混合输入。
• 消息乱序、重复截图、缺失说话人、时间冲突和字段缺失。
• 文件解析失败、恶意文件、模型超时和结构化输出不合法。
• 自动建单、相似工单提示和重复材料再次建单。
• 人工字段保护和 Agent 修改建议。
• 检索无结果、错误匹配、多个方案冲突和低置信度降级。
• 自动解决允许、禁止、权限不足和全局开关关闭。
• 客户回复编辑、确认已发送和未确认不可视为已回复。
• 知识提交、驳回、发布、下线、回滚和提交人自审拦截。
• Tool/MCP 无授权、低风险写、高风险确认、超时和失败重试。
• SSE 断线重连、事件补发、任务取消和步骤重试。
• AI、检索和工具不可用时的人工流程。

17.4 自动化启用策略

试运行直接启用满足条件的自动化，不设置纯观察期；同时必须提供：

• 全局自动化开关。
• 单个 Agent 开关。
• 按工单分类控制的自动化开关。
• 自动解决策略开关。

任一层关闭后，系统应降级为生成建议或完全人工处理，不丢失已有输入和运行产物。

18. 风险与控制

风险	控制措施
Agent 错误理解聊天记录	保存原始材料和字段证据；低置信度补全；人工字段保护
错误方案被自动复用	仅使用已发布且允许自动解决的方案；范围过滤；阈值；冲突降级
知识污染	版本审核、自审拦截、发布不可原地修改、下线和回滚
Agent 越权	用户、Agent、工具和业务状态四层权限交集
高风险工具误操作	风险分级、逐次人工确认、幂等和完整审计
外部模型数据风险	管理员信任配置、调用审计、数据范围快照和保留策略
AI 不可用导致业务中断	原始输入持久化、人工入口、步骤重试和人工接管
渠道重复回复	确认任务、幂等发送、外部消息 ID 和发送结果回写
指标失真	明确定义统计口径，使用脱敏真实案例集回归
平台能力先于业务价值膨胀	所有 Agent、Skill、Tool 能力必须服务于已定义业务闭环

19. 已确认约束与默认决策

• 单企业私有化部署，不建设多租户。
• 本地账号和 RBAC 为首期认证方式，预留企业 SSO。
• 不迁移历史数据，现有开发数据库允许清空重建。
• Dify 不进入目标架构，本项目原生能力替换 Dify 工作流。
• 服务群消息读取和自动回复延后，但必须保留渠道适配接口。
• 技术支持是首期工单发起人，并提供聊天材料。
• 问题描述有效即可自动创建正式工单，不要求全部字段齐全。
• 重复材料允许再次建单，只展示相似工单提示。
• 一级分类为业务、技术、数据和操作四类。
• 工单保持六状态，Agent 可自动标记已解决，关闭必须人工确认。
• 发布知识和回复客户必须人工确认。
• 工单采用主负责人加协作人/关注人模式，并使用软删除归档。
• 首期只采集 SLA，不执行自动升级。
• 首期客户回复由技术支持复制，并人工确认已发送。
• 模型渠道由管理员启用后视为可信，可接收原始文本和截图。
• 原始材料受权限和可配置期限控制；完整模型诊断数据默认保留 90 天。
• 正式检索采用全文、pgvector 和重排的混合方案。
• 自动复用默认阈值为 0.85，且必须满足发布状态、范围和风险条件。
• CoT 仅以结构化决策轨迹呈现，不保存或展示原始思维链。
• MCP 首先支持远程 HTTP，并用一个真实内部只读工具验收。
• 首个业务版本只要求开发环境可运行，生产化不作为首期退出门槛。