# AI 工单平台项目蓝图 更新日期：2026-07-28 状态：当前唯一主蓝图 适用范围：产品设计、架构设计、研发排期、阶段验收 评估口径：当前完成情况仅根据仓库代码静态分析得出，不包含运行、联调或业务验证 ## 1. 蓝图结论 本项目定位为面向单企业私有化部署的 **Agent-native ToB 技术支持平台**。平台以工单为业务载体，以知识资产为处理依据，以原生 Agent、Skill、Tool、MCP 和模型能力为自动化引擎，持续完成以下闭环： ```text 问题受理 → 智能建单 → 知识检索与问题排查 → 形成解决方案和客户回复 → 一次批准发送、送达后解决与策略化关闭 → 知识价值判断 → 知识/排查方案审核发布 → 重新进入后续问题检索 ``` 平台首先解决业务问题、技术问题、数据问题、操作问题以及对接类技术支持工单，核心价值是： - 减少技术支持在信息整理、重复排查、建单和知识整理上的人力成本。 - 让 Agent 在明确权限内自动建单、补充字段、流转工单、检索知识和生成处理建议。 - 正常工单只保留一次“批准方案并发送”；发布知识和高风险操作继续独立确认。 - 将每次有效处理结果沉淀为可审核、可追溯、可复用的组织知识。 - 在模型、检索或外部工具不可用时保留完整人工处理能力。 目标架构不依赖 Dify。本项目自身提供 Agent 运行、Skill 编排、模型调用、工具授权、知识检索和人工确认能力，用于替换现有 Dify 工作流。 当前系统暂时无法获取服务群消息，因此服务群读取和自动回复不进入首个业务版本；所有受理和回复能力必须通过统一渠道接口设计，为后续接入服务群、邮件或外部 API 保留入口。 ## 2. 产品目标与边界 ### 2.1 核心目标 平台接收以下输入： - 技术支持粘贴的聊天文本。 - 多张聊天截图。 - PDF、TXT、日志和常见 Office 文档。 - 技术支持补充的问题描述或图片说明。 - 系统内历史工单、解决方案、知识条目和排查方案。 平台形成以下输出： - 结构化工单及完整处理时间线。 - 可引用依据的排查步骤、候选方案和客户回复草稿。 - 在授权条件内自动更新、流转或解决的工单。 - 从已解决工单提炼的知识和排查方案草稿。 - 经人工审核发布并重新进入检索的知识资产。 - 可审计的 Agent 决策、模型调用、工具调用和人工确认记录。 ### 2.2 首个业务版本范围 首个业务版本必须打通： ```text 人工上传聊天材料 → Agent 解析 → 自动创建正式工单 → Agent 检索与排查 → 生成/复用解决方案 → 技术支持一次批准方案并发送 → 送达后自动标记已解决 → 客户确认立即关闭 / 24 小时无异议自动关闭 → 生成知识草稿 → 审核发布 → 建立检索索引 ``` 首个业务版本不要求： - 自动读取服务群消息。 - 自动向服务群发送回复。 - 客户登录平台自助查看工单。 - 历史数据迁移。 - 多租户隔离。 - 复杂 BPMN 或自由画布式工作流编排。 - 无人值守执行高风险或生产变更工具。 - 完整生产部署体系；首个业务版本以开发环境可运行作为部署要求。 ### 2.3 后续扩展范围 - 服务群、邮件和外部 API 渠道接入。 - 人工确认后的渠道自动回复及外部消息回执。 - OIDC、LDAP 等企业身份认证。 - stdio MCP 服务。 - 生产部署、监控、告警、备份和恢复演练。 - 后台可配置的多级分类树和更完整的 SLA 策略。 ## 3. 用户与职责 | 角色 | 核心职责 | 关键权限 | |---|---|---| | 技术支持 | 受理问题、补充材料、处理工单、确认客户回复、提交知识审核 | 建单、修改、接单、流转、标记已解决、编辑知识草稿 | | 支持负责人 | 管理支持团队、协调工单、处理例外和质量复核 | 技术支持权限、改派、协作人管理、自动化降级 | | 知识管理员 | 保证知识和排查方案的准确性与可复用性 | 审核、驳回、发布、下线、回滚；不得审核本人提交内容 | | 系统管理员 | 管理用户、角色、模型、Agent、Skill、工具和策略 | 系统配置、授权、风险策略、全局自动化开关 | | 只读审计员 | 检查业务变更、AI 与工具调用是否合规 | 只读查询工单事件、模型调用、知识引用、工具调用和确认记录 | 首期客户不登录系统。客户沟通仍发生在外部服务群中，由技术支持复制系统生成的话术，并在平台内确认实际已发送。 ## 4. 现行业务流程与目标流程 ### 4.1 现行业务流程 ```text 客户在服务群 @技术支持 → 技术支持人工排查 → 给出解决方案 → 回复客户 → 事后创建工单 → 填写负责人、分类、描述、方案、机构等字段 → 完成并关闭工单 ``` 该流程存在以下问题： - 工单在处理结束后才补录，无法承载实时协作和过程追踪。 - 聊天信息、排查依据和关键时间主要依赖人工整理。 - 相同问题重复排查，历史工单和知识资产未形成统一检索入口。 - 解决方案、客户话术和知识沉淀彼此割裂。 - 难以量化 Agent 对建单、排查和知识复用的实际价值。 ### 4.2 目标业务流程 ```mermaid 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["送达后解决；客户确认或 24 小时无异议关闭"] M --> N["知识沉淀 Agent 评估"] N --> O["生成知识和排查方案草稿"] O --> P["知识管理员审核发布"] P --> Q["切片、向量化并进入检索"] ``` 目标流程将工单从“事后记录”调整为“问题处理对象”。只要 Agent 能形成有效问题描述，即可创建正式工单；机构、负责人、分类和时间等其他字段允许后续补全。 ## 5. 权限与自动化边界 ### 5.1 基本原则 一次 Agent 行为的有效权限取以下条件的交集： ```text 当前用户权限 ∩ Agent 被授予的业务权限 ∩ Tool/MCP 工具授权 ∩ 当前工单或知识状态允许的操作 ``` Agent 不得通过直接写数据库绕过业务服务、状态机、权限校验和审计。 ### 5.2 动作权限矩阵 | 动作 | Agent 自动执行 | 人工确认 | 说明 | |---|---:|---:|---| | 创建工单 | 是 | 否 | 有效问题描述形成后即可创建 | | 修改工单字段 | 是 | 否 | 不得静默覆盖人工修改字段 | | 补充负责人、机构、分类和时间 | 是 | 否 | 必须保存字段来源和置信度 | | 流转到处理中、待确认 | 是 | 否 | 受状态机和权限约束 | | 标记工单已解决 | 是 | 一次批准内 | 回复明确送达后按冻结结论记录 | | 关闭工单 | 是 | 否 | 客户认可立即关闭；24 小时无异议自动关闭 | | 生成客户回复草稿 | 是 | 否 | 草稿不等于已回复 | | 回复客户/确认已发送 | 确认后执行 | 是（唯一主动作） | 一次冻结方案、结论、回复版本和风险检查 | | 生成知识草稿 | 是 | 否 | 生成后进入编辑或审核流程 | | 发布、下线知识 | 否 | 是 | 由知识管理员操作 | | 只读工具调用 | 授权后允许 | 可配置 | 仍需记录输入范围和调用审计 | | 低风险写工具调用 | 条件允许 | 可配置 | 受用户、Agent、工具授权约束 | | 高风险或生产变更 | 否 | 是 | 每次调用单独确认 | ### 5.3 人工字段保护 每个可由 Agent 填写的核心字段需要记录： - 当前值来源：人工、Agent、外部渠道或系统计算。 - 产生该值的运行、步骤和输入证据。 - 置信度和产生时间。 - 是否已被人工修改或锁定。 人工修改后的字段默认进入保护状态。后续 Agent 可以提出修改建议，但不得静默覆盖；只有人工明确采纳或业务规则允许时才能更新。 ## 6. 工单体系 ### 6.1 工单分类 首期保持四个一级分类： - 业务问题。 - 技术问题。 - 数据问题。 - 操作问题。 对接问题根据实际内容归入业务或技术问题，并保留标签、产品和模块等维度进行细分。后续将分类扩展为后台可配置的多级分类树，但首期不因分类配置阻塞业务闭环。 ### 6.2 工单状态 工单保留现有六个状态： ```text pending_info → pending → in_progress → pending_confirm → resolved → closed ``` 状态含义： | 状态 | 含义 | |---|---| | `pending_info` | 信息不足，等待技术支持补充材料 | | `pending` | 已形成有效工单，等待受理 | | `in_progress` | 正在排查或处理 | | `pending_confirm` | 已形成候选结论，等待确认、回复或外部验证 | | `resolved` | 问题已有明确解决结果，可由 Agent 在授权条件下进入 | | `closed` | 客户明确认可或送达后无异议窗口结束；保留系统关闭原因 | 24 小时内收到明确负向反馈时恢复到 `in_progress`；已关闭后出现新的负向问题时创建关联后续工单，不修改原关闭历史。删除采用软删除或归档，不物理删除业务记录。 ### 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 建单策略 - 只要能形成有效问题描述，即可自动创建正式工单。 - 普通缺失字段只降低资料完整度，不阻塞分析；只有影响问题对象、现象或方案适用环境的 `blocking_missing_fields` 才暂停并合并为一次追问。 - 自动建单保存受理输入快照、解析版本和 Agent 运行引用。 - 模型或文件解析失败时，保留全部原始材料并允许人工建单。 - 长任务立即返回运行 ID，前端通过 SSE 展示解析、提取、检索、创建和失败步骤。 ## 8. 支持分析与自动解决 ### 8.1 检索范围 支持分析 Agent 默认检索： - 已发布知识条目。 - 已发布排查方案。 - 已发布解决方案。 - 已解决或已关闭的历史工单。 草稿、待审核、已驳回、已下线内容不得作为自动解决依据；有权限的人员可以在后台预览，但必须明确标识其非正式状态。 ### 8.2 检索策略 正式检索采用： ```text PostgreSQL 全文/关键词召回 + pgvector 向量召回 → 结果合并和去重 → 可配置重排模型 → 权限、状态、分类和适用范围过滤 → 返回带引用的结果 ``` 每条结果必须携带来源类型、版本、标题、片段、相似度、适用范围和引用定位。模型生成的结论与检索到的依据必须在界面中分开展示。 ### 8.3 自动复用与自动解决 默认自动复用条件： - 综合相似度不低于 0.85。 - 分类和适用范围一致。 - 方案处于已发布状态。 - 方案显式标记为允许自动解决。 - 方案不要求人工操作、外部确认或生产环境变更。 - 当前用户和 Agent 均具有标记已解决的权限。 匹配阈值、适用范围和自动解决开关由后台配置。当多个高分方案冲突、证据不足或风险条件不满足时，必须降级为人工推荐，不得自动复用。没有正式依据但结构合法的结果标记为 `manual_only`，可生成排查建议和回复，但不能自动采纳方案。 ### 8.4 客户回复 支持分析完成时必须同步生成正式 `CustomerReplyTask`。正常流程只保留一次确认： 1. 技术支持查看并可编辑解决结论与最终回复。 2. 点击“批准方案并发送”，同时冻结方案版本、结论、回复版本和风险检查。 3. 有渠道时进入幂等发送队列；无渠道时复制话术并在同一确认窗确认外部已发送。 4. 明确送达后系统记录解决结果；客户认可立即关闭，24 小时无异议自动关闭。 发送失败保持 `pending_confirm` 并允许重试；生产变更和高风险工具仍需既有独立授权。 ## 9. 知识与排查方案体系 ### 9.1 资产类型 平台分别管理： - `KnowledgeArticle`：业务规则、产品说明、技术原理和通用知识。 - `TroubleshootingPlan`：面向问题类型的标准排查步骤、判断条件和分支。 - `Solution`：可直接应用于具体问题的解决方案和客户话术依据。 三类资产分别建模，但共享版本、审核、引用、检索、适用范围、权限和影响分析能力。 ### 9.2 生命周期 ```text 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. 目标系统架构 ```mermaid 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 | 工程闭环、待环境验收 | 自动编排进入处理并启动分析；冻结引用、低相关过滤、`manual_only` 降级和正式回复任务已接通，一次批准后才采纳方案 | 待真实模型环境和脱敏案例验证召回、自动解决及人工降级指标 | | 检索与引用 | 工程完成、待环境验收 | 已接入 pgvector、正式 Embedding、PostgreSQL 全文/向量双路召回、可配置模型重排、历史工单持久化索引和结构化范围过滤；冻结模型、通道、分项分数、降级状态、范围及引用快照 | 待 PostgreSQL + 真实 Embedding/重排服务完成召回率、延迟与 HNSW 参数验收 | | Tool 与 MCP | 已完成 | 已有统一目录、HTTP MCP 服务接入/同步/调用、用户/用户组/Agent 授权交集、风险快照、高风险双人确认、幂等、调用审计和管理界面；内部只读工单查询已通过真实 HTTP Agent 调用 | 生产部署时配置独立令牌并按企业网络边界限制访问 | | 生命周期自动编排 | 工程闭环、默认关闭 | `TicketAutomationRun` 串联建单、非阻塞补全、支持分析、一次批准、渠道送达、解决与 24 小时关闭；有序事件支持 SSE 和幂等恢复 | 启用前须通过 Agent、模型、Celery、对象存储就绪检查并完成真实渠道验证 | | 人工确认任务 | 工程完成为主 | 正常工单合并为一次“批准方案并发送”；知识审核和高风险工具仍保持独立确认 | 待真实业务量验证处理时效 | | 任务中心与 SLA | 工程完成为主 | `WorkItem` 承载真正阻塞补全、受理/分析/蒸馏失败、客户意图确认、知识审核和高风险工具确认；自动关闭接管后不再制造人工关闭待办 | 待真实业务量验证 | | 渠道接入 | 工程完成、待真实渠道验收 | 已有加密适配器配置、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 工作流。 - 服务群消息读取和自动回复延后，但必须保留渠道适配接口。 - 技术支持是首期工单发起人，并提供聊天材料。 - 问题描述有效即可自动创建正式工单，不要求全部字段齐全。 - 重复材料允许再次建单，只展示相似工单提示。 - 一级分类为业务、技术、数据和操作四类。 - 工单保持六状态，由生命周期编排自动推进；送达后自动解决，客户认可或 24 小时无异议后 由系统关闭。 - 发布知识必须人工审核；回复客户合并为一次“批准方案并发送”确认。 - 工单采用主负责人加协作人/关注人模式，并使用软删除归档。 - 首期只采集 SLA，不执行自动升级。 - 无平台渠道时技术支持复制回复，并在同一个批准窗确认已发送；有渠道时由幂等队列投递。 - 模型渠道由管理员启用后视为可信，可接收原始文本和截图。 - 原始材料受权限和可配置期限控制；完整模型诊断数据默认保留 90 天。 - 正式检索采用全文、pgvector 和重排的混合方案。 - 自动复用默认阈值为 0.85，且必须满足发布状态、范围和风险条件。 - CoT 仅以结构化决策轨迹呈现，不保存或展示原始思维链。 - MCP 首先支持远程 HTTP，并用一个真实内部只读工具验收。 - 首个业务版本只要求开发环境可运行，生产化不作为首期退出门槛。