feat: init commint

docs/development/ai-platform-demo-acceptance.md

@@ -24,7 +24,7 @@ AI 平台配置演示版固定验收已完成。该结论只覆盖模型、Skill
 ## 固定端到端脚本
 
 1. 管理员登录空白环境，确认 AI 能力菜单包含 Agent、运行记录、Skill 和模型渠道。
-2. 打开 `#/modelhub/providers`，创建渠道并在密码输入框录入真实凭证；保存后确认页面只显示末四位脱敏值。
+2. 打开 `#/modelhub/providers`，在“渠道 / 模型 / 调用记录”三个页签中创建渠道并录入真实凭证；保存后确认页面只显示末四位脱敏值。
 3. 创建文本模型配置并执行连通测试，等待状态变为“成功”；记录测试 UUID、Token 是否由渠道提供以及耗时。
 4. 在后端执行 `python manage.py seed_ai_demo --deployment-id <模型配置 ID>`，确认生成三个已发布 Skill 和一个技术支持分析 Agent 草稿。
 5. 打开 `#/skills`，进入每个 Skill，校验并格式化输入/输出 Schema；编辑草稿后发布。
@@ -34,6 +34,9 @@ AI 平台配置演示版固定验收已完成。该结论只覆盖模型、Skill
 9. 修改配置并创建新版本，回看旧运行，确认旧运行仍显示原 Agent、Skill、模型和参数快照。
 10. 创建一个不具备 `model.manage`、`skill.manage`、`agent.manage`、`agent.use`、`agent.run.view` 的账号，确认入口隐藏，直接请求相应 API 返回 403。
 11. 查看操作审计，确认存在渠道、模型测试、Skill/Agent 发布回滚、运行启动/结束和取消记录；确认审计中不存在明文密钥、完整 Prompt、完整输入或完整模型响应。
+12. 使用超级管理员对未使用模型执行删除，确认结果为永久删除；对存在调用或 Agent 引用的模型执行相同操作，确认结果为归档且历史调用仍可查询。
+13. 归档渠道，确认活跃子模型联动归档、凭证和图片出境授权被清除；恢复后确认渠道与联动归档模型均保持停用，且单独归档模型不会被恢复。
+14. 在“调用记录”中验证分页和筛选；普通 `model.manage` 用户只能查看摘要，具备 `model.invocation.view` 的用户才能加载保留期内的输入输出诊断。
 
 ## 失败路径抽查
 

docs/operations/production-runbook.md

@@ -76,6 +76,11 @@ MINIO_SECRET_KEY=<应用访问密钥>
 AI_CREDENTIAL_ENCRYPTION_KEY=<稳定 Fernet 密钥>
 INTERNAL_MCP_TOKEN=<独立随机令牌>
 METRICS_TOKEN=<独立随机令牌>
+
+TICKET_AUTOMATION_ENABLED=false
+TICKET_AUTOMATION_MAX_RETRIES=2
+TICKET_AUTO_CLOSE_HOURS=24
+SUPPORT_REFERENCE_MIN_SCORE=0.35
 ```
 
 Fernet 密钥生成：
@@ -91,6 +96,10 @@ python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().d
 
 - `KNOWLEDGE_EMBEDDING_ALLOW_HASH_FALLBACK=false`
 - `TICKET_AUTO_RESOLVE_ENABLED=false`，完成真实案例验收后再按策略开启
+- `TICKET_AUTOMATION_ENABLED=false`，完成受理 Agent、支持分析 Agent、模型部署、
+  Celery、MinIO 和至少一种回复送达方式的就绪检查后再开启
+- `TICKET_AUTO_CLOSE_HOURS=24` 是无异议窗口；变更前应完成客户通知与合规评审
+- Celery Beat 必须保持单实例运行，否则虽有数据库幂等保护，仍会制造无意义的重复调度
 - 使用正式 Embedding 部署并保持向量维度与数据库字段一致
 - 根据数据保留政策设置 Agent 运行和临时受理保留周期
 - 默认管理员仅用于初始化，随后创建实名管理员并停用或轮换默认账号

docs/operations/ticket-support-lifecycle-experience-2026-07-27.md

@@ -0,0 +1,440 @@
+# 技术支持工单全流程体验记录（2026-07-27 旧流程）
+
+## 1. 文档目的
+
+本文面向一线技术支持人员，说明如何在 AI 工单平台中完成以下闭环：
+
+1. 提交客户问题材料并创建工单。
+2. 补全信息、接管和进入处理。
+3. 运行支持分析并核对引用依据。
+4. 记录内部排查和客户沟通。
+5. 提交客户确认、填写解决结论并关闭工单。
+6. 评估知识沉淀价值并复核运行审计。
+
+本文同时记录 2026-07-28 使用真实浏览器完成的一次端到端体验。实测产生的工单是
+`TK202607280003`，工单 ID 为 `18`。文中的客户、组织和故障场景均为本地演练数据。
+
+## 2. 流程总览
+
+```mermaid
+flowchart LR
+    A["提交材料"] --> B["AI 智能受理"]
+    B --> C["待补充 pending_info"]
+    C --> D["待处理 pending"]
+    D --> E["处理中 in_progress"]
+    E --> F["待确认 pending_confirm"]
+    F --> G["已解决 resolved"]
+    G --> H["知识价值评估"]
+    H --> I["已关闭 closed"]
+    B -. "模型或受理失败" .-> J["人工表单/人工接管"]
+    E -. "分析无可信引用" .-> K["人工排查"]
+    J --> D
+    K --> F
+```
+
+标准原则：
+
+- AI 输出是排查辅助，不替代技术支持对事实、风险和解决结论的确认。
+- 支持分析没有正式引用时，只能用于人工排查，不允许自动复用或自动解决。
+- 内部备注和客户可见记录用途不同；客户可见记录也不等同于渠道已经发送。
+- 工单关闭前必须有明确的解决方案、客户确认和处理说明。
+- 知识沉淀只能进入受治理流程，不能绕过审核直接发布。
+
+## 3. 操作前准备
+
+| 检查项 | 要求 |
+|---|---|
+| 登录身份 | 具备工单创建、编辑、状态流转、支持分析和关闭权限 |
+| 后端服务 | Django API 可用 |
+| 异步服务 | Redis 和 Celery Worker 可用，否则智能受理与 Agent 运行会停在排队状态 |
+| 模型配置 | 智能受理 Agent 和支持分析 Agent 已发布，模型渠道连通 |
+| 知识配置 | 如需知识沉淀，知识蒸馏 Agent 必须已发布 |
+| 材料安全 | 不上传令牌、Cookie、密码、完整会话标识或未脱敏日志 |
+
+本次实测环境：
+
+| 项目 | 实际值 |
+|---|---|
+| 日期 | 2026-07-28，Asia/Shanghai |
+| 前端 | `http://localhost:5173` |
+| 浏览器 | Codex 内置真实浏览器，桌面视口 1440 × 1000 |
+| 登录身份 | 本地管理员演示账号 |
+| 创建方式 | 智能受理，仅提交文本材料 |
+| 演练工单 | `TK202607280003` / ID `18` |
+| 受理运行 | Agent 运行 `#56` |
+| 支持分析运行 | `1e2f4b06-b786-4916-97f0-69e4b9ceed96` |
+
+## 4. 标准操作步骤
+
+### 4.1 登录并进入创建页
+
+1. 打开平台登录页并登录。
+2. 在工作台点击“新建工单”。
+3. 默认选择“智能受理”；需要完全人工录入时切换到“普通表单”。
+
+检查点：
+
+- 页面应显示“提交材料、智能解析、补全事实、正式建单”四个阶段。
+- 桌面端应允许输入和上传材料；移动端当前仅支持查看。
+
+![智能受理创建页](images/ticket-lifecycle/01-create-intake.jpg)
+
+### 4.2 提交问题材料
+
+在“聊天记录或补充说明”中尽量提供：
+
+- 发生时间。
+- 业务系统、模块和环境。
+- 问题表现与错误信息。
+- 影响范围。
+- 已尝试动作。
+- 期望结果和客户诉求。
+
+本次演练材料：
+
+> 生产环境单点登录回调后持续白屏，影响上海财务团队约 25 人；控制台报
+> `OIDC_STATE_MISMATCH`，清理缓存并重新登录仍复现。
+
+点击“开始智能受理”后，不要重复提交。运行页应依次展示材料解析、事实提取、结构化字段、
+创建工单和完成事件。
+
+![智能受理运行中](images/ticket-lifecycle/02-intake-running.jpg)
+
+异常处理：
+
+- 长时间没有事件：检查 Celery Worker、Redis 和 Agent 运行记录。
+- 模型或解析失败：保留原材料，使用“转人工”或普通表单继续。
+- 信息不足：按页面追问补充，不要重复创建另一张工单。
+
+### 4.3 核对自动建单结果
+
+智能受理成功后会自动进入正式工单详情。技术支持必须核对：
+
+- 标题是否准确、简洁。
+- 问题描述是否忠实于材料。
+- 环境、对象、系统和影响范围是否正确。
+- 优先级是否与业务影响匹配。
+- 是否存在缺失字段和字段证据冲突。
+
+本次实测自动提取结果：
+
+| 字段 | 结果 |
+|---|---|
+| 标题 | 财务系统单点登录回调白屏 |
+| 状态 | 待补充 |
+| 优先级 | 高 |
+| 环境 | 生产环境 |
+| 对象 | 财务系统 Web 端 |
+| 影响范围 | 上海财务团队约 25 人 |
+| 错误信息 | `OIDC_STATE_MISMATCH` |
+| 缺失信息 | 客户最后消息时间、问题开始时间、关联系统、支持首次响应时间、支持最后回复时间 |
+
+![自动创建的待补充工单](images/ticket-lifecycle/03-ticket-pending-info.jpg)
+
+### 4.4 补全信息并人工接管
+
+1. 点击页头主操作“立即补全”。
+2. 只填写能够从材料或沟通中确认的事实；不确定的时间保持为空。
+3. 保存后确认缺失数量下降，活动流出现字段修改记录。
+4. 信息足够时进入“更多工单操作”，选择“转为待处理”。
+5. 流转说明应解释已确认的事实、仍需排查的内容和接管原因。
+
+推荐流转说明：
+
+> 已核对问题描述、环境、影响范围与错误码，现由人工接管进入待处理，后续核对认证回调、
+> 会话 Cookie 和服务端日志。
+
+### 4.5 分派并开始处理
+
+标准流程应先完成处理人分派，再开始排查：
+
+1. 在待处理状态点击“分派处理人”。
+2. 选择责任人并保存。
+3. 确认页头显示处理人。
+4. 点击主操作“开始处理”，或在“更多工单操作”中选择“开始处理”。
+5. 填写处理计划后提交，状态变为“处理中”。
+
+建议处理计划至少包含：
+
+- 首轮排查范围。
+- 需要核对的日志、配置或依赖。
+- 是否需要客户补充材料。
+- 生产变更风险和回滚要求。
+
+### 4.6 运行支持分析
+
+在“处理中”状态点击“开始支持分析”。运行中需要关注：
+
+- Agent 发布版本。
+- 冻结依据数量。
+- 开始时间。
+- 是否禁止重复启动。
+- “运行轨迹”是否可打开。
+
+![支持分析运行中](images/ticket-lifecycle/04-support-analysis-running.jpg)
+
+分析完成后按以下顺序阅读：
+
+1. 分析结论。
+2. 建议排查顺序。
+3. Agent 推荐方案和自动化策略。
+4. 客户回复任务。
+5. 正式引用依据和全部冻结候选。
+
+可信边界：
+
+- 只有 `citations` 指定的冻结依据才是本次输出的正式引用。
+- 没有正式引用时，页面应明确提示“仅供人工排查，不允许自动复用”。
+- 推荐方案必须来自本次冻结依据中的 `candidate_solution_ids`。
+- 涉及生产变更、匹配度不足或策略未通过时，必须人工处理。
+
+本次分析未引用任何冻结依据，最终被标记为失败并要求人工接管。系统仍保留了分析摘要、
+5 个排查步骤和回复草稿，未推荐解决方案，也没有执行自动解决。
+
+![支持分析安全降级](images/ticket-lifecycle/05-support-analysis-degraded.jpg)
+
+### 4.7 记录人工排查结果
+
+点击“继续人工排查”，在活动流顶部添加“内部备注”。内容建议使用以下结构：
+
+```text
+复现结果：
+检查范围：
+根因判断：
+已执行动作：
+验证结果：
+风险与回滚：
+下一步：
+```
+
+本次演练记录的根因是回调域名变更后，Cookie Domain 与 SameSite 配置未覆盖新域；
+测试环境修正后复测通过，生产变更等待确认。
+
+保存后检查：
+
+- 活动流按时间倒序显示。
+- 记录标记为“仅内部”。
+- 系统事件和人工备注能够区分。
+
+### 4.8 记录客户沟通
+
+1. 将“记录可见范围”切换为“客户可见记录”。
+2. 记录已经向客户说明的进展、验证请求和下一次反馈时间。
+3. 保存后检查活动流标记为“客户可见”。
+
+注意：
+
+- 客户可见记录只表示业务记录的可见范围。
+- 实际编辑、发送和送达确认应由正式 `CustomerReplyTask` 完成。
+- 不应以客户可见记录代替渠道发送。
+
+### 4.9 提交客户确认
+
+完成技术验证和客户沟通后：
+
+1. 打开“更多工单操作”。
+2. 选择“提交确认”。
+3. 填写已执行修复、技术复测结果以及需要客户确认的事项。
+4. 提交后状态变为“待确认”。
+
+![等待客户确认](images/ticket-lifecycle/06-pending-customer-confirmation.jpg)
+
+标准情况下，此阶段应出现正式客户回复任务，可编辑回复、发送到渠道并确认送达。
+
+### 4.10 标记解决
+
+客户确认恢复后点击“标记解决”，填写：
+
+- 解决方案：具体配置、代码、数据或操作变更。
+- 处理说明：客户确认、验证范围、监控和回滚信息。
+- 已回复客户：确认实际已完成客户回复后再开启。
+
+本次解决方案：
+
+> 将认证回调新域名加入 Cookie Domain 范围，并将回调 Cookie 调整为
+> `SameSite=None; Secure`；清理旧会话后重新登录，生产复测正常。
+
+提交后状态变为“已解决”，支持分析结果转为只读。
+
+### 4.11 知识沉淀
+
+在已解决状态展开“知识沉淀”：
+
+1. 查看是否已经自动生成知识价值评估。
+2. 如尚未生成，点击“评估知识价值”。
+3. 评估通过后只生成受治理草稿。
+4. 草稿必须经过审核和发布，才能重新进入检索。
+
+本次环境未发布知识蒸馏 Agent，因此评估没有启动。页面给出了明确失败原因，没有伪造
+知识草稿。
+
+![知识价值评估降级](images/ticket-lifecycle/07-knowledge-governance.jpg)
+
+### 4.12 关闭工单
+
+只有满足以下条件后才关闭：
+
+- 客户已经确认恢复。
+- 解决方案完整。
+- 客户回复状态明确。
+- 监控、风险和回滚信息已记录。
+- 知识沉淀已完成，或已明确登记后续人工任务。
+
+点击“关闭工单”，补充必填的处理说明并提交。关闭后：
+
+- 状态为“已关闭”。
+- 页头不再显示重新分析等处理动作。
+- 支持分析、活动流和运行轨迹保持只读可查。
+- 页面当前任务变为复核关闭记录与知识资产。
+
+![已关闭工单](images/ticket-lifecycle/08-ticket-closed.jpg)
+
+### 4.13 复核运行审计
+
+从支持分析区域点击“运行轨迹”，检查：
+
+- 运行 ID、Agent 版本和终态。
+- 每个步骤的模型、能力和执行结果。
+- 输入、结构化输出和调用尝试。
+- Token、耗时和重试。
+- 配置快照、检索策略和冻结依据。
+- 失败代码与安全降级原因。
+
+本次支持分析审计结果：
+
+| 项目 | 实际值 |
+|---|---|
+| 运行 ID | `1e2f4b06-b786-4916-97f0-69e4b9ceed96` |
+| Agent | 支持分析 Agent，发布 v6 |
+| 模型 | `gpt-5.6-terra`，`vision_chat` |
+| 冻结依据 | 3 条 |
+| 输入 / 输出 Token | 1847 / 502 |
+| 总 Token | 2349 |
+| 总耗时 | 13109 ms |
+| 步骤状态 | `analyze` 成功 |
+| 运行终态 | 失败 |
+| 失败代码 | `untrusted_support_output` |
+| 失败原因 | 支持分析结果必须引用至少一条检索依据 |
+
+步骤成功但运行失败并不矛盾：模型成功返回了结构化结果，但业务信任校验发现
+`citations` 为空，因此拒绝将结果视为可信支持结论。
+
+![Agent 运行审计](images/ticket-lifecycle/09-agent-run-audit.jpg)
+
+## 5. 本次真实浏览器实测记录
+
+| 时间 | 操作 | 状态或结果 |
+|---|---|---|
+| 19:00 | 提交文本材料并启动智能受理 | 运行事件持续更新 |
+| 19:00 | 自动创建正式工单 | `TK202607280003`，状态“待补充” |
+| 19:01 | 补充关联系统并尝试保存业务时间 | 关联系统保存成功，4 个时间字段未保存 |
+| 19:03 | 从更多菜单人工转为待处理 | 成功 |
+| 19:05 | 从更多菜单开始处理 | 成功，但处理人仍未设置 |
+| 19:05 | 启动支持分析 | 冻结 3 条依据，禁止重复启动 |
+| 19:05 | 支持分析结束 | 可信校验失败，安全降级为人工排查 |
+| 19:06 | 保存内部排查结论 | 成功，活动流标记“仅内部” |
+| 19:08 | 保存客户可见进展 | 成功，活动流标记“客户可见” |
+| 19:08 | 提交客户确认 | 状态变为“待确认” |
+| 19:09 | 填写解决方案并标记解决 | 状态变为“已解决” |
+| 19:10 | 启动知识价值评估 | 因未发布知识蒸馏 Agent 而未启动 |
+| 19:12 | 填写关闭说明并关闭工单 | 状态变为“已关闭” |
+| 19:12 | 查看支持分析运行轨迹 | 输入、输出、Token、耗时、快照和失败原因可追溯 |
+
+## 6. 实测发现的问题
+
+### LIFE-01：业务时间填写后未保存
+
+- 严重度：高。
+- 复现：在“补全工单信息”中填写 4 个 `datetime-local` 字段并保存。
+- 实际：表单关闭后 4 个时间字段仍为待补全，没有错误提示。
+- 影响：缺失任务无法自动完成，技术支持容易误以为信息已保存。
+- 建议：修复前端时间序列化或后端字段映射；保存失败时保持表单打开并显示字段级错误。
+
+### LIFE-02：“分派处理人”打开了错误表单
+
+- 严重度：阻断。
+- 复现：待处理状态点击页头主操作“分派处理人”。
+- 实际：打开的是“补全工单信息”，且没有处理人字段。
+- 影响：技术支持无法通过主操作完成责任人分派。
+- 建议：提供独立分派弹窗或在表单中加入处理人字段，并在保存后更新页头。
+
+### LIFE-03：未分派也能进入处理中
+
+- 严重度：高。
+- 复现：处理人未设置时，从“更多工单操作”选择“开始处理”。
+- 实际：状态成功变为“处理中”，页头继续显示“处理人：未设置”。
+- 影响：责任归属与业务状态不一致，工作台和 SLA 统计可能失真。
+- 建议：状态机在进入 `in_progress` 前强制校验处理人，或将当前操作者自动设为处理人并记录事件。
+
+### LIFE-04：正式客户回复任务未生成
+
+- 严重度：高。
+- 复现：支持分析结束后进入待确认状态。
+- 实际：页面长期显示“正在生成正式回复任务”，没有可编辑、发送或确认送达的任务区域。
+- 影响：页面要求使用正式回复任务，但用户只能记录客户可见活动，回复闭环不完整。
+- 建议：失败分析也应创建人工回复任务；任务生成失败要显示重试或人工创建入口，并阻止在未确认回复状态时直接解决。
+
+### LIFE-05：智能受理等待时间显示不准确
+
+- 严重度：中。
+- 实际：受理已经运行数十秒，页面仍显示“已等待 0 秒”；最初长时间停在“准备受理…”。
+- 影响：用户无法判断是否卡住或需要转人工。
+- 建议：以服务端运行时间或稳定的客户端计时器显示耗时，并设置超时、重试和转人工提示。
+
+### LIFE-06：支持检索候选与问题无关
+
+- 严重度：中，属于知识和检索质量问题。
+- 实际：OIDC 回调白屏问题冻结的 3 条依据均为采集账号密码或采集进度内容。
+- 正面表现：可信校验拒绝了无引用输出，没有自动推荐或自动解决。
+- 建议：加强关联系统、模块和错误码的过滤权重；低相关候选不足时明确返回“无可靠依据”。
+
+### LIFE-07：知识沉淀环境未就绪
+
+- 类型：环境配置阻塞。
+- 实际：点击“评估知识价值”提示“尚未发布知识蒸馏 Agent”。
+- 影响：已解决工单不能进入知识草稿流程。
+- 建议：部署验收清单增加知识蒸馏 Agent 发布检查，并在工作台提供配置就绪状态。
+
+### LIFE-08：结束状态仍显示“继续人工排查”
+
+- 严重度：中。
+- 实际：工单已解决或已关闭后，失败的支持分析仍显示“继续人工排查”按钮。
+- 影响：与“结果只读保留”的文案冲突，容易让用户误以为还能修改已结束工单。
+- 建议：结束状态仅保留分析结论、引用和运行轨迹，隐藏所有处理型按钮。
+
+## 7. 当前版本的人工降级路径
+
+当自动能力不可用时，按以下顺序确保工单仍可完成：
+
+1. 智能受理失败：保留材料，切换普通表单或人工接管。
+2. 时间字段无法保存：在内部备注记录已确认时间，并登记缺陷，避免重复建单。
+3. 无法分派：由有权限的支持人员从更多菜单接管；修复前需在线下明确责任人。
+4. 支持分析失败：保留冻结依据和运行 ID，点击“继续人工排查”并记录实际结果。
+5. 正式回复任务缺失：记录客户可见进展，并通过既有受控渠道发送；在活动流记录送达和确认。
+6. 知识评估未启动：在关闭说明中登记原因，后续由知识管理员人工创建草稿。
+
+人工降级不得绕过权限、生产变更审批、客户确认或审计要求。
+
+## 8. 关闭前检查清单
+
+- [ ] 工单标题、描述、环境、系统和影响范围准确。
+- [ ] 处理人明确，责任归属可追溯。
+- [ ] 支持分析结论已核对，引用可信边界清楚。
+- [ ] 实际排查结果已经写入内部备注。
+- [ ] 客户沟通内容和实际送达状态已经记录。
+- [ ] 客户已经确认恢复。
+- [ ] 解决方案、验证范围、风险和回滚信息完整。
+- [ ] “已回复客户”与真实情况一致。
+- [ ] 知识沉淀已完成，或已登记未完成原因与后续责任人。
+- [ ] Agent 运行 ID、配置快照和失败原因可查询。
+
+## 9. 本次实测结论
+
+当前版本能够通过真实浏览器完成：
+
+`智能受理 → 自动建单 → 人工接管 → 处理中 → 支持分析安全降级 → 内部排查 →
+客户可见记录 → 待确认 → 已解决 → 已关闭 → 运行审计`。
+
+状态主线和统一活动流已经具备连续处理能力，支持分析在没有可信引用时也能安全降级。
+但“处理人分派、业务时间保存、正式客户回复任务、知识蒸馏 Agent”仍存在阻断或环境缺口。
+在这些问题关闭前，不建议把本次结果解释为生产业务闭环已经完全通过。

docs/operations/ticket-support-lifecycle-manual.md

@@ -1,440 +1,163 @@
-# 技术支持工单全流程操作手册
+# 技术支持工单“一次确认”操作手册
 
-## 1. 文档目的
+更新日期：2026-07-28
 
-本文面向一线技术支持人员，说明如何在 AI 工单平台中完成以下闭环：
+适用对象：一线技术支持、支持负责人、平台管理员
+功能状态：工程实现完成；真实模型、企业渠道和脱敏案例仍待环境验收
 
-1. 提交客户问题材料并创建工单。
-2. 补全信息、接管和进入处理。
-3. 运行支持分析并核对引用依据。
-4. 记录内部排查和客户沟通。
-5. 提交客户确认、填写解决结论并关闭工单。
-6. 评估知识沉淀价值并复核运行审计。
+## 1. 正常流程
 
-本文同时记录 2026-07-28 使用真实浏览器完成的一次端到端体验。实测产生的工单是
-`TK202607280003`，工单 ID 为 `18`。文中的客户、组织和故障场景均为本地演练数据。
-
-## 2. 流程总览
-
-```mermaid
-flowchart LR
-    A["提交材料"] --> B["AI 智能受理"]
-    B --> C["待补充 pending_info"]
-    C --> D["待处理 pending"]
-    D --> E["处理中 in_progress"]
-    E --> F["待确认 pending_confirm"]
-    F --> G["已解决 resolved"]
-    G --> H["知识价值评估"]
-    H --> I["已关闭 closed"]
-    B -. "模型或受理失败" .-> J["人工表单/人工接管"]
-    E -. "分析无可信引用" .-> K["人工排查"]
-    J --> D
-    K --> F
-```
-
-标准原则：
-
-- AI 输出是排查辅助，不替代技术支持对事实、风险和解决结论的确认。
-- 支持分析没有正式引用时，只能用于人工排查，不允许自动复用或自动解决。
-- 内部备注和客户可见记录用途不同；客户可见记录也不等同于渠道已经发送。
-- 工单关闭前必须有明确的解决方案、客户确认和处理说明。
-- 知识沉淀只能进入受治理流程，不能绕过审核直接发布。
-
-## 3. 操作前准备
-
-| 检查项 | 要求 |
-|---|---|
-| 登录身份 | 具备工单创建、编辑、状态流转、支持分析和关闭权限 |
-| 后端服务 | Django API 可用 |
-| 异步服务 | Redis 和 Celery Worker 可用，否则智能受理与 Agent 运行会停在排队状态 |
-| 模型配置 | 智能受理 Agent 和支持分析 Agent 已发布，模型渠道连通 |
-| 知识配置 | 如需知识沉淀，知识蒸馏 Agent 必须已发布 |
-| 材料安全 | 不上传令牌、Cookie、密码、完整会话标识或未脱敏日志 |
-
-本次实测环境：
-
-| 项目 | 实际值 |
-|---|---|
-| 日期 | 2026-07-28，Asia/Shanghai |
-| 前端 | `http://localhost:5173` |
-| 浏览器 | Codex 内置真实浏览器，桌面视口 1440 × 1000 |
-| 登录身份 | 本地管理员演示账号 |
-| 创建方式 | 智能受理，仅提交文本材料 |
-| 演练工单 | `TK202607280003` / ID `18` |
-| 受理运行 | Agent 运行 `#56` |
-| 支持分析运行 | `1e2f4b06-b786-4916-97f0-69e4b9ceed96` |
-
-## 4. 标准操作步骤
-
-### 4.1 登录并进入创建页
-
-1. 打开平台登录页并登录。
-2. 在工作台点击“新建工单”。
-3. 默认选择“智能受理”；需要完全人工录入时切换到“普通表单”。
-
-检查点：
-
-- 页面应显示“提交材料、智能解析、补全事实、正式建单”四个阶段。
-- 桌面端应允许输入和上传材料；移动端当前仅支持查看。
-
-![智能受理创建页](images/ticket-lifecycle/01-create-intake.jpg)
-
-### 4.2 提交问题材料
-
-在“聊天记录或补充说明”中尽量提供：
-
-- 发生时间。
-- 业务系统、模块和环境。
-- 问题表现与错误信息。
-- 影响范围。
-- 已尝试动作。
-- 期望结果和客户诉求。
-
-本次演练材料：
-
-> 生产环境单点登录回调后持续白屏，影响上海财务团队约 25 人；控制台报
-> `OIDC_STATE_MISMATCH`，清理缓存并重新登录仍复现。
-
-点击“开始智能受理”后，不要重复提交。运行页应依次展示材料解析、事实提取、结构化字段、
-创建工单和完成事件。
-
-![智能受理运行中](images/ticket-lifecycle/02-intake-running.jpg)
-
-异常处理：
-
-- 长时间没有事件：检查 Celery Worker、Redis 和 Agent 运行记录。
-- 模型或解析失败：保留原材料，使用“转人工”或普通表单继续。
-- 信息不足：按页面追问补充，不要重复创建另一张工单。
-
-### 4.3 核对自动建单结果
-
-智能受理成功后会自动进入正式工单详情。技术支持必须核对：
-
-- 标题是否准确、简洁。
-- 问题描述是否忠实于材料。
-- 环境、对象、系统和影响范围是否正确。
-- 优先级是否与业务影响匹配。
-- 是否存在缺失字段和字段证据冲突。
-
-本次实测自动提取结果：
-
-| 字段 | 结果 |
-|---|---|
-| 标题 | 财务系统单点登录回调白屏 |
-| 状态 | 待补充 |
-| 优先级 | 高 |
-| 环境 | 生产环境 |
-| 对象 | 财务系统 Web 端 |
-| 影响范围 | 上海财务团队约 25 人 |
-| 错误信息 | `OIDC_STATE_MISMATCH` |
-| 缺失信息 | 客户最后消息时间、问题开始时间、关联系统、支持首次响应时间、支持最后回复时间 |
-
-![自动创建的待补充工单](images/ticket-lifecycle/03-ticket-pending-info.jpg)
-
-### 4.4 补全信息并人工接管
-
-1. 点击页头主操作“立即补全”。
-2. 只填写能够从材料或沟通中确认的事实；不确定的时间保持为空。
-3. 保存后确认缺失数量下降，活动流出现字段修改记录。
-4. 信息足够时进入“更多工单操作”，选择“转为待处理”。
-5. 流转说明应解释已确认的事实、仍需排查的内容和接管原因。
-
-推荐流转说明：
-
-> 已核对问题描述、环境、影响范围与错误码，现由人工接管进入待处理，后续核对认证回调、
-> 会话 Cookie 和服务端日志。
-
-### 4.5 分派并开始处理
-
-标准流程应先完成处理人分派，再开始排查：
-
-1. 在待处理状态点击“分派处理人”。
-2. 选择责任人并保存。
-3. 确认页头显示处理人。
-4. 点击主操作“开始处理”，或在“更多工单操作”中选择“开始处理”。
-5. 填写处理计划后提交，状态变为“处理中”。
-
-建议处理计划至少包含：
-
-- 首轮排查范围。
-- 需要核对的日志、配置或依赖。
-- 是否需要客户补充材料。
-- 生产变更风险和回滚要求。
-
-### 4.6 运行支持分析
-
-在“处理中”状态点击“开始支持分析”。运行中需要关注：
-
-- Agent 发布版本。
-- 冻结依据数量。
-- 开始时间。
-- 是否禁止重复启动。
-- “运行轨迹”是否可打开。
-
-![支持分析运行中](images/ticket-lifecycle/04-support-analysis-running.jpg)
-
-分析完成后按以下顺序阅读：
-
-1. 分析结论。
-2. 建议排查顺序。
-3. Agent 推荐方案和自动化策略。
-4. 客户回复任务。
-5. 正式引用依据和全部冻结候选。
-
-可信边界：
-
-- 只有 `citations` 指定的冻结依据才是本次输出的正式引用。
-- 没有正式引用时，页面应明确提示“仅供人工排查，不允许自动复用”。
-- 推荐方案必须来自本次冻结依据中的 `candidate_solution_ids`。
-- 涉及生产变更、匹配度不足或策略未通过时，必须人工处理。
-
-本次分析未引用任何冻结依据，最终被标记为失败并要求人工接管。系统仍保留了分析摘要、
-5 个排查步骤和回复草稿，未推荐解决方案，也没有执行自动解决。
-
-![支持分析安全降级](images/ticket-lifecycle/05-support-analysis-degraded.jpg)
-
-### 4.7 记录人工排查结果
-
-点击“继续人工排查”，在活动流顶部添加“内部备注”。内容建议使用以下结构：
+技术支持在提交问题材料后，通常只需要完成一次人工操作：
 
 ```text
-复现结果：
-检查范围：
-根因判断：
-已执行动作：
-验证结果：
-风险与回滚：
-下一步：
+提交文字、图片或文档
+→ 系统自动建单
+→ 系统判断真正阻塞信息
+→ 自动进入处理并启动支持分析
+→ 自动生成解决建议和正式回复任务
+→ 技术支持批准方案并发送
+→ 回复送达后自动标记解决
+→ 客户认可立即关闭 / 24 小时无异议自动关闭
+→ 异步评估知识沉淀
 ```
 
-本次演练记录的根因是回调域名变更后，Cookie Domain 与 SameSite 配置未覆盖新域；
-测试环境修正后复测通过，生产变更等待确认。
+普通字段缺失、未分派处理人和知识蒸馏失败都不阻塞正常关闭。只有无法确认问题对象、
+问题现象、方案适用环境，或模型、存储、权限与风险检查失败时，才需要人工接管。
 
-保存后检查：
+## 2. 提交问题材料
 
-- 活动流按时间倒序显示。
-- 记录标记为“仅内部”。
-- 系统事件和人工备注能够区分。
-
-### 4.8 记录客户沟通
-
-1. 将“记录可见范围”切换为“客户可见记录”。
-2. 记录已经向客户说明的进展、验证请求和下一次反馈时间。
-3. 保存后检查活动流标记为“客户可见”。
+1. 进入“工单中心”，选择“创建工单”。
+2. 粘贴客户原始描述，可同时上传图片、PDF、TXT、日志或 Office 文档。
+3. 点击“提交材料并开始受理”。
+4. 页面通过 SSE 展示解析、提取与建单进度；形成有效问题描述后自动跳转正式工单。
 
 注意：
 
-- 客户可见记录只表示业务记录的可见范围。
-- 实际编辑、发送和送达确认应由正式 `CustomerReplyTask` 完成。
-- 不应以客户可见记录代替渠道发送。
+- 问题描述是唯一建单门槛。
+- 标题缺失时系统生成“待补全问题：……”。
+- 优先级缺失时采用“中”，分类无法确认时保持为空。
+- 页面重复提交、Agent 重试和 Celery 重复执行不会创建第二张正式工单。
 
-### 4.9 提交客户确认
+## 3. 查看自动处理进度
 
-完成技术验证和客户沟通后：
+工单详情只展示三个业务阶段：
 
-1. 打开“更多工单操作”。
-2. 选择“提交确认”。
-3. 填写已执行修复、技术复测结果以及需要客户确认的事项。
-4. 提交后状态变为“待确认”。
-
-![等待客户确认](images/ticket-lifecycle/06-pending-customer-confirmation.jpg)
-
-标准情况下，此阶段应出现正式客户回复任务，可编辑回复、发送到渠道并确认送达。
-
-### 4.10 标记解决
-
-客户确认恢复后点击“标记解决”，填写：
-
-- 解决方案：具体配置、代码、数据或操作变更。
-- 处理说明：客户确认、验证范围、监控和回滚信息。
-- 已回复客户：确认实际已完成客户回复后再开启。
-
-本次解决方案：
-
-> 将认证回调新域名加入 Cookie Domain 范围，并将回调 Cookie 调整为
-> `SameSite=None; Secure`；清理旧会话后重新登录，生产复测正常。
-
-提交后状态变为“已解决”，支持分析结果转为只读。
-
-### 4.11 知识沉淀
-
-在已解决状态展开“知识沉淀”：
-
-1. 查看是否已经自动生成知识价值评估。
-2. 如尚未生成，点击“评估知识价值”。
-3. 评估通过后只生成受治理草稿。
-4. 草稿必须经过审核和发布，才能重新进入检索。
-
-本次环境未发布知识蒸馏 Agent，因此评估没有启动。页面给出了明确失败原因，没有伪造
-知识草稿。
-
-![知识价值评估降级](images/ticket-lifecycle/07-knowledge-governance.jpg)
-
-### 4.12 关闭工单
-
-只有满足以下条件后才关闭：
-
-- 客户已经确认恢复。
-- 解决方案完整。
-- 客户回复状态明确。
-- 监控、风险和回滚信息已记录。
-- 知识沉淀已完成，或已明确登记后续人工任务。
-
-点击“关闭工单”，补充必填的处理说明并提交。关闭后：
-
-- 状态为“已关闭”。
-- 页头不再显示重新分析等处理动作。
-- 支持分析、活动流和运行轨迹保持只读可查。
-- 页面当前任务变为复核关闭记录与知识资产。
-
-![已关闭工单](images/ticket-lifecycle/08-ticket-closed.jpg)
-
-### 4.13 复核运行审计
-
-从支持分析区域点击“运行轨迹”，检查：
-
-- 运行 ID、Agent 版本和终态。
-- 每个步骤的模型、能力和执行结果。
-- 输入、结构化输出和调用尝试。
-- Token、耗时和重试。
-- 配置快照、检索策略和冻结依据。
-- 失败代码与安全降级原因。
-
-本次支持分析审计结果：
-
-| 项目 | 实际值 |
+| 阶段 | 技术支持需要做什么 |
 |---|---|
-| 运行 ID | `1e2f4b06-b786-4916-97f0-69e4b9ceed96` |
-| Agent | 支持分析 Agent，发布 v6 |
-| 模型 | `gpt-5.6-terra`，`vision_chat` |
-| 冻结依据 | 3 条 |
-| 输入 / 输出 Token | 1847 / 502 |
-| 总 Token | 2349 |
-| 总耗时 | 13109 ms |
-| 步骤状态 | `analyze` 成功 |
-| 运行终态 | 失败 |
-| 失败代码 | `untrusted_support_output` |
-| 失败原因 | 支持分析结果必须引用至少一条检索依据 |
+| 受理完成 | 通常无需操作；真正阻塞时一次补充关键信息 |
+| 自动处理中 | 查看当前步骤和运行状态，不手动分派、开始处理或启动分析 |
+| 确认与结束 | 批准方案并发送；随后观察送达、客户反馈与关闭倒计时 |
 
-步骤成功但运行失败并不矛盾：模型成功返回了结构化结果，但业务信任校验发现
-`citations` 为空，因此拒绝将结果视为可信支持结论。
+顶部自动化区域会显示当前步骤、重试次数、下一动作和阻塞原因。引用依据、完整策略检查和
+运行轨迹默认折叠，排查需要时再展开。
 
-![Agent 运行审计](images/ticket-lifecycle/09-agent-run-audit.jpg)
+## 4. 补充真正阻塞的信息
 
-## 5. 本次真实浏览器实测记录
+只有 `blocking_missing_fields` 会暂停流程。系统会把多个问题合并为一次追问：
 
-| 时间 | 操作 | 状态或结果 |
-|---|---|---|
-| 19:00 | 提交文本材料并启动智能受理 | 运行事件持续更新 |
-| 19:00 | 自动创建正式工单 | `TK202607280003`，状态“待补充” |
-| 19:01 | 补充关联系统并尝试保存业务时间 | 关联系统保存成功，4 个时间字段未保存 |
-| 19:03 | 从更多菜单人工转为待处理 | 成功 |
-| 19:05 | 从更多菜单开始处理 | 成功，但处理人仍未设置 |
-| 19:05 | 启动支持分析 | 冻结 3 条依据，禁止重复启动 |
-| 19:05 | 支持分析结束 | 可信校验失败，安全降级为人工排查 |
-| 19:06 | 保存内部排查结论 | 成功，活动流标记“仅内部” |
-| 19:08 | 保存客户可见进展 | 成功，活动流标记“客户可见” |
-| 19:08 | 提交客户确认 | 状态变为“待确认” |
-| 19:09 | 填写解决方案并标记解决 | 状态变为“已解决” |
-| 19:10 | 启动知识价值评估 | 因未发布知识蒸馏 Agent 而未启动 |
-| 19:12 | 填写关闭说明并关闭工单 | 状态变为“已关闭” |
-| 19:12 | 查看支持分析运行轨迹 | 输入、输出、Token、耗时、快照和失败原因可追溯 |
+- 有已接入渠道：系统发送追问，收到客户补充后恢复自动处理。
+- 无渠道：任务中心只创建一个补充任务。
 
-## 6. 实测发现的问题
+普通机构、分类、时间、负责人等缺失字段只显示为紧凑提示，不占据当前任务区域，也不
+阻止支持分析。
 
-### LIFE-01：业务时间填写后未保存
+## 5. 审核支持分析
 
-- 严重度：高。
-- 复现：在“补全工单信息”中填写 4 个 `datetime-local` 字段并保存。
-- 实际：表单关闭后 4 个时间字段仍为待补全，没有错误提示。
-- 影响：缺失任务无法自动完成，技术支持容易误以为信息已保存。
-- 建议：修复前端时间序列化或后端字段映射；保存失败时保持表单打开并显示字段级错误。
+分析成功后优先查看：
 
-### LIFE-02：“分派处理人”打开了错误表单
+1. 分析结论。
+2. 建议排查顺序。
+3. Agent 推荐方案与业务化风险摘要。
+4. 正式客户回复任务。
+5. 实际引用依据和运行审计。
 
-- 严重度：阻断。
-- 复现：待处理状态点击页头主操作“分派处理人”。
-- 实际：打开的是“补全工单信息”，且没有处理人字段。
-- 影响：技术支持无法通过主操作完成责任人分派。
-- 建议：提供独立分派弹窗或在表单中加入处理人字段，并在保存后更新页头。
+结果类型：
 
-### LIFE-03：未分派也能进入处理中
+- `trusted`：存在正式冻结依据，可继续进行方案版本、范围、权限和风险校验。
+- `manual_only`：没有可复用的正式依据，但分析结构合法；只允许作为人工排查和回复建议。
+- 失败：系统默认自动重试最多 2 次；仍失败时只产生一个“支持分析待人工接管”任务。
 
-- 严重度：高。
-- 复现：处理人未设置时，从“更多工单操作”选择“开始处理”。
-- 实际：状态成功变为“处理中”，页头继续显示“处理人：未设置”。
-- 影响：责任归属与业务状态不一致，工作台和 SLA 统计可能失真。
-- 建议：状态机在进入 `in_progress` 前强制校验处理人，或将当前操作者自动设为处理人并记录事件。
+“无可复用依据”不是系统失败。生产变更、高风险工具或证据冲突继续要求独立授权。
 
-### LIFE-04：正式客户回复任务未生成
+## 6. 唯一人工动作：批准方案并发送
 
-- 严重度：高。
-- 复现：支持分析结束后进入待确认状态。
-- 实际：页面长期显示“正在生成正式回复任务”，没有可编辑、发送或确认送达的任务区域。
-- 影响：页面要求使用正式回复任务，但用户只能记录客户可见活动，回复闭环不完整。
-- 建议：失败分析也应创建人工回复任务；任务生成失败要显示重试或人工创建入口，并阻止在未确认回复状态时直接解决。
+自动化状态为“等待批准”时，点击“批准方案并发送”：
 
-### LIFE-05：智能受理等待时间显示不准确
+1. 核对或编辑解决结论。
+2. 核对根因（可选）。
+3. 核对最终客户回复。
+4. 有平台渠道时选择渠道和外部会话 ID；无渠道时复制回复，并勾选“已在外部渠道完成发送”。
+5. 提交确认。
 
-- 严重度：中。
-- 实际：受理已经运行数十秒，页面仍显示“已等待 0 秒”；最初长时间停在“准备受理…”。
-- 影响：用户无法判断是否卡住或需要转人工。
-- 建议：以服务端运行时间或稳定的客户端计时器显示耗时，并设置超时、重试和转人工提示。
+一次提交同时冻结：
 
-### LIFE-06：支持检索候选与问题无关
+- 解决方案及其版本。
+- 解决结论和根因。
+- 客户回复版本。
+- 权限、范围、阈值和风险检查结果。
+- 批准人和批准时间。
 
-- 严重度：中，属于知识和检索质量问题。
-- 实际：OIDC 回调白屏问题冻结的 3 条依据均为采集账号密码或采集进度内容。
-- 正面表现：可信校验拒绝了无引用输出，没有自动推荐或自动解决。
-- 建议：加强关联系统、模块和错误码的过滤权重；低相关候选不足时明确返回“无可靠依据”。
+重复点击不会产生重复回复、重复解决记录或重复外发消息。渠道发送失败时工单保持
+`pending_confirm`，页面会显示失败原因和“重试自动处理”；重试复用原外发消息、回复版本
+和幂等键。
 
-### LIFE-07：知识沉淀环境未就绪
+## 7. 送达、解决与关闭
 
-- 类型：环境配置阻塞。
-- 实际：点击“评估知识价值”提示“尚未发布知识蒸馏 Agent”。
-- 影响：已解决工单不能进入知识草稿流程。
-- 建议：部署验收清单增加知识蒸馏 Agent 发布检查，并在工作台提供配置就绪状态。
+- 平台渠道收到明确送达回执后，系统自动记录解决结果并进入 `resolved`。
+- 无渠道时，“确认已在外部发送”视为人工送达证据。
+- 客户明确回复“已解决、恢复了、可以了”等正向表达时立即关闭。
+- 客户没有回复时，送达满 24 小时由系统关闭。
+- 24 小时内明确回复“未解决、仍然不行、继续报错”等负向表达时，取消关闭计划并恢复
+  `in_progress`。
+- 工单已经关闭后再收到明确负向反馈时，系统创建一张关联后续工单并把渠道会话切换到
+  新工单；原工单历史保持只读。
+- 无法可靠判断客户意图时暂停关闭，只创建一个客户反馈确认任务。
 
-### LIFE-08：结束状态仍显示“继续人工排查”
+自动关闭事件使用 `source=system`，审计中保存批准人、回复版本、送达证据、策略版本和
+关闭原因。
 
-- 严重度：中。
-- 实际：工单已解决或已关闭后，失败的支持分析仍显示“继续人工排查”按钮。
-- 影响：与“结果只读保留”的文案冲突，容易让用户误以为还能修改已结束工单。
-- 建议：结束状态仅保留分析结论、引用和运行轨迹，隐藏所有处理型按钮。
+## 8. 异常处理
 
-## 7. 当前版本的人工降级路径
+| 页面状态 | 建议操作 |
+|---|---|
+| 等待关键信息 | 一次补充系统列出的合并问题，然后恢复 |
+| 自动分析重试中 | 等待系统完成最多 2 次重试，不重复启动 |
+| 自动处理失败 | 先“重试自动处理”；确认不可恢复后“转人工处理” |
+| 正式回复任务缺失 | 页面会明确显示失败，不会无限显示“正在生成”；重试或接管 |
+| 渠道发送失败 | 保持待确认，查看失败原因后点击“重试自动处理”；幂等键防止重复发送 |
+| 客户反馈不明确 | 在任务中心确认意图，再决定关闭或恢复处理 |
+| 知识蒸馏失败 | 交由知识治理任务处理，不回退已解决或已关闭工单 |
 
-当自动能力不可用时，按以下顺序确保工单仍可完成：
+转人工处理后，系统才突出处理人和 SLA，并恢复原六状态兼容操作。人工处理不能绕过权限、
+状态机、字段保护和审计。
 
-1. 智能受理失败：保留材料，切换普通表单或人工接管。
-2. 时间字段无法保存：在内部备注记录已确认时间，并登记缺陷，避免重复建单。
-3. 无法分派：由有权限的支持人员从更多菜单接管；修复前需在线下明确责任人。
-4. 支持分析失败：保留冻结依据和运行 ID，点击“继续人工排查”并记录实际结果。
-5. 正式回复任务缺失：记录客户可见进展，并通过既有受控渠道发送；在活动流记录送达和确认。
-6. 知识评估未启动：在关闭说明中登记原因，后续由知识管理员人工创建草稿。
+## 9. 关闭后复核
 
-人工降级不得绕过权限、生产变更审批、客户确认或审计要求。
+已关闭工单只读展示：
 
-## 8. 关闭前检查清单
+- 最终解决结论和根因。
+- 冻结方案与支持分析版本。
+- 客户回复版本与送达证据。
+- 客户反馈或无异议超时原因。
+- 完整工单事件、自动化事件和 Agent 运行轨迹。
 
-- [ ] 工单标题、描述、环境、系统和影响范围准确。
-- [ ] 处理人明确，责任归属可追溯。
-- [ ] 支持分析结论已核对，引用可信边界清楚。
-- [ ] 实际排查结果已经写入内部备注。
-- [ ] 客户沟通内容和实际送达状态已经记录。
-- [ ] 客户已经确认恢复。
-- [ ] 解决方案、验证范围、风险和回滚信息完整。
-- [ ] “已回复客户”与真实情况一致。
-- [ ] 知识沉淀已完成，或已登记未完成原因与后续责任人。
-- [ ] Agent 运行 ID、配置快照和失败原因可查询。
+知识沉淀异步执行，生成的知识和方案仍必须由知识管理员审核发布。
 
-## 9. 本次实测结论
+## 10. 上线前检查
 
-当前版本能够通过真实浏览器完成：
+- [ ] `TICKET_AUTOMATION_ENABLED` 仍保持关闭，直到真实环境就绪检查通过。
+- [ ] 受理 Agent、支持分析 Agent 和有效模型部署均已发布启用。
+- [ ] Celery Worker、Celery Beat、Redis、MinIO 正常。
+- [ ] 至少一种送达方式可用：企业渠道回执，或受控人工确认。
+- [ ] `TICKET_AUTOMATION_MAX_RETRIES`、`TICKET_AUTO_CLOSE_HOURS` 和检索阈值经过评审。
+- [ ] 使用脱敏真实案例验证正常路径人工操作不超过 1 次。
+- [ ] 重复建单、重复回复、重复解决和重复关闭均为 0。
+- [ ] 所有自动解决均有正式解决记录、批准记录和送达证据。
 
-`智能受理 → 自动建单 → 人工接管 → 处理中 → 支持分析安全降级 → 内部排查 →
-客户可见记录 → 待确认 → 已解决 → 已关闭 → 运行审计`。
+未完成真实模型、企业渠道和脱敏案例验收前，不得宣称生产自动解决准确率已经达标。
 
-状态主线和统一活动流已经具备连续处理能力，支持分析在没有可信引用时也能安全降级。
-但“处理人分派、业务时间保存、正式客户回复任务、知识蒸馏 Agent”仍存在阻断或环境缺口。
-在这些问题关闭前，不建议把本次结果解释为生产业务闭环已经完全通过。
+## 11. 历史体验记录
+
+改造前的真实浏览器全流程、逐步截图、耗时与缺陷记录保留在
+[2026-07-27 旧流程体验记录](ticket-support-lifecycle-experience-2026-07-27.md)，用于对比
+从约 6～8 次平台操作缩减为一次确认的目标。

docs/product/blueprint.md

@@ -1,6 +1,6 @@
 # AI 工单平台项目蓝图
 
-更新日期：2026-07-27
+更新日期：2026-07-28
 状态：当前唯一主蓝图  
 适用范围：产品设计、架构设计、研发排期、阶段验收
 评估口径：当前完成情况仅根据仓库代码静态分析得出，不包含运行、联调或业务验证
@@ -14,7 +14,7 @@
   → 智能建单
   → 知识检索与问题排查
   → 形成解决方案和客户回复
-  → 工单解决与人工关闭
+  → 一次批准发送、送达后解决与策略化关闭
   → 知识价值判断
   → 知识/排查方案审核发布
   → 重新进入后续问题检索
@@ -24,7 +24,7 @@
 
 - 减少技术支持在信息整理、重复排查、建单和知识整理上的人力成本。
 - 让 Agent 在明确权限内自动建单、补充字段、流转工单、检索知识和生成处理建议。
-- 通过人工确认保护发布知识、关闭工单和回复客户等关键动作。
+- 正常工单只保留一次“批准方案并发送”；发布知识和高风险操作继续独立确认。
 - 将每次有效处理结果沉淀为可审核、可追溯、可复用的组织知识。
 - 在模型、检索或外部工具不可用时保留完整人工处理能力。
 
@@ -63,9 +63,9 @@
   → 自动创建正式工单
   → Agent 检索与排查
   → 生成/复用解决方案
-  → 生成客户回复并人工确认已发送
-  → Agent 标记已解决
-  → 人工关闭
+  → 技术支持一次批准方案并发送
+  → 送达后自动标记已解决
+  → 客户确认立即关闭 / 24 小时无异议自动关闭
   → 生成知识草稿
   → 审核发布
   → 建立检索索引
@@ -136,13 +136,13 @@ flowchart LR
     C -- "是" --> E["自动创建正式工单"]
     E --> F["支持分析 Agent 检索并排查"]
     F --> G{"满足自动复用条件"}
-    G -- "是" --> H["复用已发布方案并标记已解决"]
+    G -- "是" --> H["冻结可复用的已发布方案"]
     G -- "否" --> I["输出排查建议和候选方案"]
     I --> J["人工处理或补充结果"]
     H --> K["生成客户回复草稿"]
     J --> K
-    K --> L["技术支持确认已发送"]
-    L --> M["人工关闭工单"]
+    K --> L["技术支持一次批准方案并发送"]
+    L --> M["送达后解决；客户确认或 24 小时无异议关闭"]
     M --> N["知识沉淀 Agent 评估"]
     N --> O["生成知识和排查方案草稿"]
     O --> P["知识管理员审核发布"]
@@ -174,10 +174,10 @@ Agent 不得通过直接写数据库绕过业务服务、状态机、权限校
 | 修改工单字段 | 是 | 否 | 不得静默覆盖人工修改字段 |
 | 补充负责人、机构、分类和时间 | 是 | 否 | 必须保存字段来源和置信度 |
 | 流转到处理中、待确认 | 是 | 否 | 受状态机和权限约束 |
-| 标记工单已解决 | 条件允许 | 否 | 仅限满足自动解决策略的方案 |
-| 关闭工单 | 否 | 是 | 由有关闭权限的人员确认 |
+| 标记工单已解决 | 是 | 一次批准内 | 回复明确送达后按冻结结论记录 |
+| 关闭工单 | 是 | 否 | 客户认可立即关闭；24 小时无异议自动关闭 |
 | 生成客户回复草稿 | 是 | 否 | 草稿不等于已回复 |
-| 回复客户/确认已发送 | 否 | 是 | 保存最终话术和实际回复时间 |
+| 回复客户/确认已发送 | 确认后执行 | 是（唯一主动作） | 一次冻结方案、结论、回复版本和风险检查 |
 | 生成知识草稿 | 是 | 否 | 生成后进入编辑或审核流程 |
 | 发布、下线知识 | 否 | 是 | 由知识管理员操作 |
 | 只读工具调用 | 授权后允许 | 可配置 | 仍需记录输入范围和调用审计 |
@@ -230,9 +230,9 @@ pending_info
 | `in_progress` | 正在排查或处理 |
 | `pending_confirm` | 已形成候选结论，等待确认、回复或外部验证 |
 | `resolved` | 问题已有明确解决结果，可由 Agent 在授权条件下进入 |
-| `closed` | 业务确认结束，只能由人工关闭 |
+| `closed` | 客户明确认可或送达后无异议窗口结束；保留系统关闭原因 |
 
-关闭后如需继续处理，应通过重新打开事件恢复到受控状态，不直接修改历史事件。删除采用软删除或归档，不物理删除业务记录。
+24 小时内收到明确负向反馈时恢复到 `in_progress`；已关闭后出现新的负向问题时创建关联后续工单，不修改原关闭历史。删除采用软删除或归档，不物理删除业务记录。
 
 ### 6.3 工单核心信息
 
@@ -303,7 +303,8 @@ pending_info
 ### 7.3 建单策略
 
 - 只要能形成有效问题描述，即可自动创建正式工单。
-- 其他缺失字段形成站内待补全任务，不阻塞建单。
+- 普通缺失字段只降低资料完整度，不阻塞分析；只有影响问题对象、现象或方案适用环境的
+  `blocking_missing_fields` 才暂停并合并为一次追问。
 - 自动建单保存受理输入快照、解析版本和 Agent 运行引用。
 - 模型或文件解析失败时，保留全部原始材料并允许人工建单。
 - 长任务立即返回运行 ID，前端通过 SSE 展示解析、提取、检索、创建和失败步骤。
@@ -347,18 +348,18 @@ PostgreSQL 全文/关键词召回
 - 方案不要求人工操作、外部确认或生产环境变更。
 - 当前用户和 Agent 均具有标记已解决的权限。
 
-匹配阈值、适用范围和自动解决开关由后台配置。当多个高分方案冲突、证据不足或风险条件不满足时，必须降级为人工推荐，不得自动解决。
+匹配阈值、适用范围和自动解决开关由后台配置。当多个高分方案冲突、证据不足或风险条件不满足时，必须降级为人工推荐，不得自动复用。没有正式依据但结构合法的结果标记为 `manual_only`，可生成排查建议和回复，但不能自动采纳方案。
 
 ### 8.4 客户回复
 
-支持分析 Agent 根据问题、处理过程、已采纳方案和引用依据生成客户回复草稿。首期流程：
+支持分析完成时必须同步生成正式 `CustomerReplyTask`。正常流程只保留一次确认：
 
-1. 技术支持查看并编辑回复草稿。
-2. 技术支持复制最终话术到服务群。
-3. 技术支持在平台确认已发送。
-4. 系统保存草稿、最终话术、确认人和实际回复时间。
+1. 技术支持查看并可编辑解决结论与最终回复。
+2. 点击“批准方案并发送”，同时冻结方案版本、结论、回复版本和风险检查。
+3. 有渠道时进入幂等发送队列；无渠道时复制话术并在同一确认窗确认外部已发送。
+4. 明确送达后系统记录解决结果；客户认可立即关闭，24 小时无异议自动关闭。
 
-未来渠道接入后仍保持人工确认边界：确认后由渠道适配器发送，并回写外部消息 ID、发送时间和失败原因。
+发送失败保持 `pending_confirm` 并允许重试；生产变更和高风险工具仍需既有独立授权。
 
 ## 9. 知识与排查方案体系
 
@@ -631,11 +632,12 @@ flowchart TB
 | Skill 与 Agent 配置 | 已完成为主 | 已有版本化 Skill、Agent、步骤级模型部署和运行配置；草稿克隆保留步骤覆盖关系 | 需要围绕三个真实业务 Agent 固化输入输出和业务服务调用 |
 | Agent 异步运行 | 已完成为主 | Celery 顺序步骤、步骤有效模型冻结、尝试记录、重试、取消、结构修复、运行快照、Agent 动作授权、真实工单支持分析和知识蒸馏已可用；图片只发送给获授权的视觉步骤 | 需要继续接入更多 Tool/MCP 业务结果并完成生产模型验收 |
 | 知识蒸馏 Agent | 工程闭环、待环境验收 | 已解决工单自动触发价值评估，冻结去重依据并生成受治理知识、排查方案和可选解决方案草稿；失败进入人工接管 | 待真实模型验证去标识化、重复判断、草稿质量和发布后召回 |
-| 支持分析 Agent | 工程闭环、待环境验收 | 真实工单可运行可信混合检索，查看冻结引用；策略满足时受控采纳方案，否则展示降级原因；回复进入人工任务 | 待真实模型环境和脱敏案例验证召回、自动解决及人工降级指标 |
+| 支持分析 Agent | 工程闭环、待环境验收 | 自动编排进入处理并启动分析；冻结引用、低相关过滤、`manual_only` 降级和正式回复任务已接通，一次批准后才采纳方案 | 待真实模型环境和脱敏案例验证召回、自动解决及人工降级指标 |
 | 检索与引用 | 工程完成、待环境验收 | 已接入 pgvector、正式 Embedding、PostgreSQL 全文/向量双路召回、可配置模型重排、历史工单持久化索引和结构化范围过滤；冻结模型、通道、分项分数、降级状态、范围及引用快照 | 待 PostgreSQL + 真实 Embedding/重排服务完成召回率、延迟与 HNSW 参数验收 |
 | Tool 与 MCP | 已完成 | 已有统一目录、HTTP MCP 服务接入/同步/调用、用户/用户组/Agent 授权交集、风险快照、高风险双人确认、幂等、调用审计和管理界面；内部只读工单查询已通过真实 HTTP Agent 调用 | 生产部署时配置独立令牌并按企业网络边界限制访问 |
-| 人工确认任务 | 工程完成为主 | 客户回复、人工关闭、知识审核和高风险工具调用均有正式任务与独立确认约束 | 待真实业务量验证处理时效 |
-| 任务中心与 SLA | 工程完成为主 | `WorkItem` 已承载待补全、受理/分析/蒸馏失败、客户回复、人工关闭、知识审核和高风险工具确认；可配置截止时间并汇总 SLA | 待真实业务量验证 |
+| 生命周期自动编排 | 工程闭环、默认关闭 | `TicketAutomationRun` 串联建单、非阻塞补全、支持分析、一次批准、渠道送达、解决与 24 小时关闭；有序事件支持 SSE 和幂等恢复 | 启用前须通过 Agent、模型、Celery、对象存储就绪检查并完成真实渠道验证 |
+| 人工确认任务 | 工程完成为主 | 正常工单合并为一次“批准方案并发送”；知识审核和高风险工具仍保持独立确认 | 待真实业务量验证处理时效 |
+| 任务中心与 SLA | 工程完成为主 | `WorkItem` 承载真正阻塞补全、受理/分析/蒸馏失败、客户意图确认、知识审核和高风险工具确认；自动关闭接管后不再制造人工关闭待办 | 待真实业务量验证 |
 | 渠道接入 | 工程完成、待真实渠道验收 | 已有加密适配器配置、HMAC 签名入站、消息/会话去重、冻结回复任务版本、Celery 幂等出站、送达/失败回执、失败重试、操作审计和治理页面；只有送达回执才确认客户回复 | 待至少一个真实企业服务群完成签名、认证、出站和回执联调 |
 | 审计 | 已完成为主 | 已有审计模型、操作人输出及按模块、动作、对象、结果、用户和时间过滤；Agent、知识和 Tool/MCP 均记录业务快照与关联 | 后续补充生产级归档和报表 |
 | 部署与运维 | 工程基线与隔离恢复已完成 | 已有独立生产 Compose、Gunicorn、Nginx、依赖健康检查、存活/就绪探针、Prometheus/Alertmanager、失败与积压告警规则，以及 PostgreSQL/MinIO 跨平台备份、校验、恢复、调度、安全裁剪和自动隔离演练；工单、附件和对象一致性恢复已通过 | 待配置真实告警接收方、安装备份调度并执行异地加密保留 |
@@ -868,11 +870,12 @@ flowchart TB
 - 问题描述有效即可自动创建正式工单，不要求全部字段齐全。
 - 重复材料允许再次建单，只展示相似工单提示。
 - 一级分类为业务、技术、数据和操作四类。
-- 工单保持六状态，Agent 可自动标记已解决，关闭必须人工确认。
-- 发布知识和回复客户必须人工确认。
+- 工单保持六状态，由生命周期编排自动推进；送达后自动解决，客户认可或 24 小时无异议后
+  由系统关闭。
+- 发布知识必须人工审核；回复客户合并为一次“批准方案并发送”确认。
 - 工单采用主负责人加协作人/关注人模式，并使用软删除归档。
 - 首期只采集 SLA，不执行自动升级。
-- 首期客户回复由技术支持复制，并人工确认已发送。
+- 无平台渠道时技术支持复制回复，并在同一个批准窗确认已发送；有渠道时由幂等队列投递。
 - 模型渠道由管理员启用后视为可信，可接收原始文本和截图。
 - 原始材料受权限和可配置期限控制；完整模型诊断数据默认保留 90 天。
 - 正式检索采用全文、pgvector 和重排的混合方案。

docs/product/stage-plan.md

@@ -236,6 +236,34 @@ ESLint 与 Vite 生产构建全部通过。
 阶段 3.2 的真实 PostgreSQL/Embedding/重排环境验收和本里程碑的脱敏真实案例指标
 尚未满足，因此阶段 3 继续保持“进行中”。
 
+### 3.5 一次确认自动闭环
+
+状态：**工程实现完成，真实环境验收待执行（2026-07-28）**
+
+- [x] 新增持久化 `TicketAutomationRun` 与有序事件；同一工单只允许一个活动运行，Celery、
+  Agent 回调、页面恢复和重复确认保持幂等。
+- [x] 智能受理提交后自动核对阻塞字段；普通缺失信息不阻塞，系统自动进入 `in_progress`
+  并启动支持分析。
+- [x] 支持分析过滤低相关候选；无正式依据但结构合法时标记 `manual_only`，允许人工排查与
+  回复，但禁止自动采纳方案。
+- [x] 支持分析同步生成唯一正式回复任务；运行失败最多自动重试 2 次，最终只生成一个明确
+  的人工接管任务。
+- [x] 新增“一次批准并发送”领域命令，同时冻结方案、解决结论、回复版本和风险判断；有
+  渠道时进入幂等队列，无渠道时在合并确认窗确认外部已发送。
+- [x] 回复送达后自动记录解决结果；客户明确认可立即关闭，24 小时无异议自动关闭，负向
+  反馈恢复处理，含糊反馈进入唯一确认任务。
+- [x] 工单详情折叠为“受理完成、自动处理中、确认与结束”三个业务阶段，自动处理时不再
+  展示分派、开始处理、开始分析和人工关闭等主操作。
+- [x] 增加 `GET /tickets/{id}/automation`、`POST /tickets/{id}/approve-and-send`、
+  异常动作接口及支持断线续传的生命周期 SSE。
+- [x] 增加自动化静态就绪检查和默认关闭配置；依赖未就绪时新工单保留现有人工流程。
+- [ ] 使用真实脱敏案例和真实模型、Celery、MinIO、企业渠道完成 P95、重复事实为零及
+  单次人工操作指标验收。
+
+本里程碑改变阶段 3.3 的默认执行边界：支持分析不再在人工批准前直接解决工单；原六状态
+接口继续兼容，但由编排自动推进。当前仅完成工程与自动化测试，不宣称真实自动解决准确率
+或企业渠道闭环已达标。
+
 ## 阶段 4 里程碑
 
 ### 4.1 统一知识资产治理