# 可靠客服 Agent > 周期建议：8–14 天。所有顾客、订单、渠道和知识内容均为合成数据；系统不得向真实用户发送消息。 ## 项目背景 一家虚构的小型电商用聊天工具处理售前与售后问题。普通机器人在单轮 FAQ 上表现尚可，但一进入连续追问就会遗忘上下文；资料中没有答案时仍可能承诺退款或到货时间；复杂问题转给人工后，客服又要重新阅读整段对话。 团队需要的不是“永远能回答”的机器人，而是一个可靠客服 Agent：有证据才回答，记住必要上下文，不确定时明确兜底，高风险或用户要求时顺畅转人工，并为运营复盘留下记录。 ## 项目目标 交付一个本地客服控制台和可测试的会话服务，走通“模拟渠道入站 → 多轮会话 → 知识证据 → 回答或兜底 → 转人工 → 审计复盘”的链路。 系统必须证明它知道什么时候不能继续自动回答，而不是以回复数量作为成功标准。 ## 用户故事 - 作为顾客，我希望连续追问时系统理解当前话题，从而不必重复说明。 - 作为顾客，我希望答案能够核对知识来源，从而不被虚构承诺误导。 - 作为人工客服，我希望收到结构化交接摘要和完整证据，从而快速接手。 - 作为运营人员，我希望查看兜底、转人工和失败原因，从而发现知识缺口。 ## 功能要求 ### 必须完成 1. **模拟渠道与会话** - 提供本地聊天 UI 或 Mock 入站接口，输入包含稳定的 `channel_event_id`、会话标识和消息文本。 - 重复发送同一个事件不得产生两条顾客消息或两次 Agent 回复。 - 会话至少支持 `bot_active`、`handoff_pending`、`human_active`、`closed` 状态。 2. **多轮上下文** - 保存有顺序的消息历史，并从最近对话提取当前主题或关键实体。 - 至少支持一个需要引用上轮信息才能正确回答的合成场景。 - 对过长历史采用明确的截断或摘要策略，并在文档中说明信息损失风险。 3. **知识检索与证据** - 使用本地 FAQ/知识条目完成检索；每个回答返回采用的证据标识和摘录。 - 知识条目需有版本或更新时间，便于审计回答依据。 4. **可靠回答与无证据兜底** - 默认使用确定性 Mock Agent；回答只能依据当前会话事实与知识证据。 - 无命中、证据低于阈值或问题超出业务范围时，不得猜测，应给出明确兜底状态和下一步。 - 不得自动承诺退款、赔偿、物流时效或其他未在合成规则中授权的结果。 5. **转人工规则** - 至少覆盖：用户主动要求、连续两次无证据、高风险关键词/意图三类触发。 - 触发后创建唯一交接单，包含原因、会话摘要、关键消息、证据和待确认事项。 - 转人工后 Bot 不得继续自动发送业务答案；人工可添加回复并关闭会话。 6. **运营与审计** - 控制台可查看会话、证据、兜底原因、交接状态和知识缺口。 - 审计记录至少包含事件时间、决策类型、触发规则、关联会话和结果；不可通过普通 UI 改写历史记录。 7. **失败处理** - 可稳定模拟检索或 Agent 失败；界面/API 给出可恢复错误，不丢入站消息，也不重复回复。 ### 可选增强 - 渠道签名、时间戳和重放窗口的本地演示。 - 运营规则测试台、质量抽检和日报导出。 - 知识缺口聚合与待补充 FAQ 建议。 - 接入真实模型的 Adapter 接口设计；验收仍使用本地 Mock。 ## 非功能要求 - **可运行性**：仓库提供合成 FAQ、对话脚本和一键种子数据，离线可跑完整演示。 - **可靠性**：入站事件幂等；状态迁移受约束；Agent 失败不得吞消息或重复生成交接单。 - **性能**：在 50 个会话、100 条知识的本地样本下，单轮 Mock 回复应在 2 秒内返回。 - **可观测性**：每次自动回答、兜底和转人工都能由会话标识关联审计，但日志不得泄漏凭证或不必要的全文。 - **安全与隐私**：合成身份与订单号也应按最小化原则展示；输入按不可信文本处理，不能改变系统规则。 - **无障碍**：会话状态、发送失败和转人工状态有文字说明，核心操作可键盘完成。 ## 范围与限制 ### 范围内 - 单业务、单团队的本地客服演示。 - 模拟渠道、多轮会话、本地知识、有证据回答、兜底、转人工和审计。 - 合成的售前 FAQ、物流规则、退换货规则和用户消息。 ### 范围外 - 连接微信、短信、邮件、电话或其他真实渠道。 - 真实订单查询、退款、赔付、身份验证或支付操作。 - 生产级坐席排班、全量数据分析、复杂 RBAC 和多租户 SaaS。 - 复制任何现有客服项目的源码、客户资料或内部规则。 ### 技术与时间限制 - 周期为 8–14 天；先保证可靠边界与交接，再增加运营能力。 - 技术栈可自选，但必须提供可演示的操作界面和可自动测试的服务接口。 - 默认仅允许本地知识库、Mock 渠道和 Mock Agent；测试不能访问公网。 - 不得要求真实手机号、账号、渠道 Secret 或模型 API Key。 - 不要求部署；若自行部署，必须先脱敏并保留无需外部依赖的本地验收路径。 ## 澄清机制 在“澄清 Issue”记录问题，包含：背景、歧义、候选方案、推荐方案、影响和未回复时的可逆假设。 例如“连续两次无证据是按整场会话还是同一主题计算”会直接影响转人工规则，需要明确。展示文案等非阻塞问题可记录假设继续；涉及真实渠道、外发消息、真实用户数据、费用或改变高风险边界的问题必须等待组织者确认。若发现 A/B/C 都不适用，应保留 D/or 路径并说明如何验证。 ## 交付物与证据 - 可运行源码、依赖锁文件、安全配置示例、合成知识和对话夹具。 - `README.md`：架构、启动、主路径、兜底路径、转人工路径、故障模拟、测试和限制。 - `docs/PRD.md`：角色、会话状态、转人工规则、范围、验收映射和澄清决策。 - `docs/PLAN.md`：渠道、会话、检索、Agent、交接和审计的模块边界与数据流。 - 自动化测试：至少覆盖事件幂等、多轮引用、证据兜底、三类转人工、Bot 停止回复和失败恢复。 - `docs/TEST_EVIDENCE.md`：命令、结果、验收映射及脱敏的成功/失败/交接证据。 - `docs/AI_COLLABORATION.md`：AI 建议、本人判断与核验，不得粘贴私人会话全文。 - `docs/RETROSPECTIVE.md`、阶段 Issue、PR 和可解释的提交历史。 ## 公开可测试验收标准 | ID | Given / 前置条件 | When / 操作 | Then / 可观察结果 | 验证方式 | |---|---|---|---|---| | AC-01 | 一个新的 `channel_event_id` | 同一入站事件连续提交两次 | 只保存一条顾客消息并只触发一次处理，响应可识别为幂等重放 | 自动化测试 | | AC-02 | 用户先问“标准配送多久”并得到有证据回答 | 追问“偏远地区呢” | 系统能关联上轮配送主题，回答带支持偏远地区规则的证据 | 集成测试 | | AC-03 | 知识库中存在明确规则 | 用户提出对应问题 | 回答包含证据标识，打开后可核对到实际采用的条目与版本 | UI/API 复现 | | AC-04 | 知识库不存在某产品承诺 | 用户要求确认该承诺 | 返回结构化无证据兜底，不虚构答案，并记录知识缺口 | 自动化测试 | | AC-05 | 用户明确输入“请转人工” | 系统处理消息 | 会话进入待交接/人工状态，只创建一张含原因与摘要的交接单 | 自动化测试 | | AC-06 | 同一主题已连续两次无证据 | 再完成第二次兜底处理 | 系统触发转人工，审计记录指出命中的规则和计数依据 | 自动化测试 | | AC-07 | 会话已进入 `human_active` | 再发送一条顾客消息 | Bot 不产生自动业务回复；人工回复仍可记录并关闭会话 | 集成测试 | | AC-08 | 使用文档约定的检索/Agent 故障输入 | 提交消息后恢复组件并重试 | 原消息不丢失、不重复，错误可见，恢复后只产生一个有效结果 | 故障测试 | | AC-09 | 全新环境且没有渠道或模型凭证 | 按 README 启动并运行测试脚本 | 对话、兜底、转人工和审计均可本地复现，不向外部发送消息 | 人工复现 + 命令证据 | ## 技术讲解与追问准备 请准备说明：会话状态机；上下文如何选择与截断；证据与答案的关系；三类转人工规则的取舍；事件幂等和失败恢复；为什么“无法回答”是可靠性能力而不是缺陷；AI 生成代码如何被你核验。 验收可能模拟一个模糊请求、重复事件或临时新增规则。你需要先澄清风险与状态影响，再在独立分支实现，并用回归测试证明没有破坏原流程。 ## 安全与合规 - 仅使用合成人物、订单、消息和知识条目，不得导入真实聊天、手机号、地址、工单或客户数据。 - 不得连接真实消息渠道，也不得让系统自动执行退款、赔付或外部通知。 - 用户消息和知识内容均是不可信输入，不能覆盖系统规则、读取环境秘密或触发任意工具。 - 不得提交、共享或中转 Codex/模型/渠道账号、会话、Token、API Key、Cookie 或私钥。 - 本活动用于项目实践和能力反馈，不承诺就业、录用、薪资或面试结果。