核心 GUIDE
Customer Support Copilot
Support Copilot 应通过 Retrieval Evidence、Case Structuring 与 Action Drafting 提升 Operator Leverage，同时让 Source Authority 与高后果 Decision 保持显式。
核心心智模型
Copilot 是 Full Automation 之前的 Decision Support。它负责组装 Verified Context 并提出 Bounded Next Step，但 Approval、Exception 与 High-impact Action 仍由 Human 或 Runtime Policy Ownership。
为什么重要
Customer Support 很适合 AI，因为工作重复且 Knowledge-heavy，但真实 Ticket 同时包含 Exception、Account State 与 Policy Consequence。直接跳到 Autonomous Resolution，会掩盖系统究竟有没有检索正确 Policy、识别 Uncertainty 与正确 Escalate。Copilot Stage 可以先创造 Operational Value，同时积累决定“哪些环节未来能安全自动化”的 Evidence。
01
围绕 Support Decision 建立 Leverage
从 Classification、Account-context Retrieval、Knowledge Search、Case Summary 与 Response Draft 开始。向 Operator 展示 Controlling Source 与 Uncertainty，把 State-changing Tool 留在显式 Policy 后。测量 Acceptance、Edit、Retrieval Failure、Escalation Reason 与 Resolution Outcome。只有当低风险 Action 的 Postcondition 与 Exception Rate 被充分理解后，才把它移动到 Automation Boundary 另一侧。
02
例子：带 Policy Exception 的 Refund Request
Copilot 识别 Customer Plan，检索 Current Refund Policy 并生成 Reply Draft，但发现购买发生在 Special Migration Period，而且两份 Guidance 存在冲突。它展示两个 Source 并建议 Escalation，而不是自行编造 Definitive Answer 或直接发钱。
常见失败模式
- 隐藏 Source Evidence，只让 Agent 相信 Generated Support Summary。
- 还没理解 Exception / Reconciliation Path 就自动化 Refund。
- 只测 Draft Speed，不测 Operator Edit 与 Wrong-source Retrieval。
工程启发
- Proposed Support Action 旁边展示 Controlling Evidence。
- 利用 Copilot Telemetry 找出哪些 Decision 稳定到足以自动化。
- Consequential Action 保持在显式 Tool、Policy 与 Escalation Boundary 后。
关键结论
- 01Copilot 是有价值的 Intermediate Operating Model，不是“自动化失败”。
- 02Support Quality 依赖 Current Knowledge 与 Account State。
- 03Measured Human-assisted Workflow 会揭示真实 Safe Automation Boundary。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。