AI 助手遇到账号、账单或连接故障时，通常只能让用户另开工单。问题在渠道切换中被重新描述，客服也看不到故障发生前的上下文。Olly 的做法是让 Agent 自己成为支持流程的入口和出口。
整个实现不到 500 行 TypeScript，核心不是复杂的客服系统，而是两个边界明确的工具：普通建议和功能请求进入反馈队列；确实需要人工、账号权限或账单操作的问题进入支持请求。
#Agent 先判断自己做不了什么
Olly 的客服 Skill 包含价格、试用限制、取消方式、设置入口与用户实时用量。遇到知识内问题，Agent 可以直接回答；遇到 OAuth Token、账户权限或支付状态等它无法安全处理的事项，则先征求用户同意，再调用升级工具。
一次升级会同时完成三件事：保存问题摘要，附上最近对话，把通知发送给团队。用户不需要重新解释“昨天开始无法同步、已经重连两次”这样的上下文，人工也能直接看到 Agent 在升级前做过什么。
问题摘要统一成英文，即使用户使用中文，也不会增加内部处理成本。这层翻译由 Agent 完成，但原始会话仍随请求保存，人工可以核对是否准确。
#人工回复也不直接发送
支持人员修复问题后，通过管理接口写入回复。这段文字不会原样推送给用户，而是作为一个合成 Turn 送回原 Agent：用用户的语言写一条短消息，不添加人工没有提供的信息，并把引用内容当数据而不是指令。
最后一条限制很重要。用户的问题和人工回复都属于不可信文本。 Agent 还可能拥有读取邮件等高权限工具；如果系统直接把这些文本拼进高优先级 Prompt，就会把客服通道变成新的 Prompt Injection 入口。
#同一会话才是产品体验
这个流程没有试图用 AI 消灭人工支持。它只把三件最费人的工作自动化：识别何时升级、整理上下文、把处理结果送回正确用户和正确渠道。
更重要的是，支持不再是主产品之外的工单系统。用户在 iMessage、短信或网页里提出问题，也在同一线程里收到结果；Agent 既维持对话连续性，也清楚知道权限边界。对 AI 原生产品而言，这种“自动处理到边界、人工完成高权限动作、Agent 负责闭环”的结构，比追求全自动客服更可靠。