智能客服

客服场景里重复问题占比确实高，看起来是自动化的理想标的。但它也是最容易出事的地方——答错一句承诺，可能直接变成投诉甚至纠纷。

真正的难点不是能不能答，是划清"哪些能自动答、哪些必须转人工"。这条线画得太保守，系统没价值；画得太激进，迟早出事。

把已解决工单整理成问题—答复对，用通用知识库的问答拆分方式处理；标准话术、服务承诺、时效规定另行建库。

工单里的问法是用户真实的问法——口语、错别字、说不清楚的描述都在里面。自己编的 FAQ 总是用规范表述，恰恰和真实提问差得最远，检索命中率会明显偏低。

工作流第一步用问题分类节点：定义「产品咨询」「售后处理」「投诉」「其他」等类别，为每类写清判定边界和典型示例。它输出固定的 class_name，后接条件分支节点分流。

投诉类直接走转人工，不进自动应答分支。这是风险控制的设计，不是能力不足——投诉场景里用户要的往往不是答案，是有人负责。

角色设定里划死边界：涉及金额承诺、时效承诺、责任认定的问题一律转人工。

宁可转人工率高一些。机器在有法律含义的问题上表态，一次就够你受的。这条收口线建议由法务参与确定，而不是由做系统的人拍。

智能体发布后既可在 Cowork 内直接使用，也可通过连接器接入既有业务系统或企业 IM。让用户为了问一句话去开一个新系统，这事大概率不会发生。

上线后重点看转人工的会话——它准确标出了自动应答的能力边界在哪。定期复盘这批记录，决定是补知识库、调分类边界，还是就维持现状。