12万封邮件之后，企业AI该先接管哪一步？

一条客户邮件进入企业，常常不是“回答它”这么简单：先判断属于哪类事项，再补齐信息，再决定交给哪个系统、哪个团队，必要时还要升级人工。这个不起眼的分流环节，决定了后面的自动化会不会跑偏。

10月1日，Barclays披露其全球市场业务正使用 Claude 对客户来信做分类、信息补全和处理路径判断，平台每日处理约12万封邮件。它没有把故事包装成“AI替代整个运营团队”，而是把模型放在一项更具体的工作上：让运营同事更快看到该处理什么、缺什么、该由谁接手。这个切口，值得每个准备上线智能体的企业认真看一眼。

真正适合先交给AI的，是“有限选项的下一步”

很多企业一开始就问：“能不能让智能体把客服、销售或运营流程全做完？”这会把项目拉到最难的终局。更可执行的问题应当是：在这条流程里，哪一个判断可以被写成有限选项？比如“补材料、转产品专家、进入人工复核、关闭为重复请求”，每一种结果都有明确的去处、责任人和时限。

OpenAI在9月29日发布的 Decisions API，正是把模型能力压进这类边界：开发者先定义问题和有限的候选答案，再由模型结合文本或图片上下文做分类、路由或选择智能体下一动作。它传递的不是“模型只能做简单事”，而是一条落地次序：先把可验收的选择做稳定，再逐步扩大可自主处理的范围。

企业最先要规模化的，不是“AI回答了多少”，而是“每次分流是否把正确的人、正确的信息和正确的下一步接到了一起”。

分流不是一个模型能力，而是一份可运营的流程契约

要把分流做好，企业至少要先补齐三样东西。第一是选项表：允许哪些去向，哪些场景必须人工接管，不能让“其他”成为一个没有主人负责的黑洞。第二是证据表：模型为何这样判断，引用了邮件里的哪些信息，哪些字段仍缺失。第三是回流表：被人工改路、被退回或超时的案例，应回到规则与知识库，而不是只留在某位员工的收件箱里。

这也是为什么“接一个模型”很快，“把它运营起来”更难。AWS在近期关于规模化智能体的实践中提醒，大型企业会自然形成多模型、多框架、多供应商并存的环境。此时最稀缺的并不是统一所有工具，而是让不同团队都能遵守同一套任务分类、交接和治理规则；否则每个智能体各自聪明，组织反而更难协作。

从一张“分流卡”开始，而不是从一场大改造开始

我建议企业选一类高频、去向有限、已有人工处理记录的请求，先做一张分流卡：输入是什么；可选去向不超过几类；每一类的最少信息；谁签收；多久必须处理；模型置信不足时如何升级；人工改路怎样记录。上线后别只看节省了多少点击，更要看转错率、缺件率、人工改路率和闭环时长。

Barclays的案例还提示了另一点：同一家企业可以同时让AI帮助员工检索知识、协助工程团队改造遗留系统、处理运营邮件，但这些能力并不需要以同一种自主程度运行。适合知识问答的工作，未必适合自动路由；适合自动路由的工作，也未必适合自动承诺。把“下一步”设计清楚，才有资格讨论更大范围的自动化。

STARBOX视角：让每次分流成为组织可复用的判断

在STARBOX的组织—BOX—智能体三层结构里，分流不该藏在一段提示词里。组织层应定义客户承诺、可选路径、人工签收与升级责任；BOX沉淀分类标准、历史案例、字段说明和已验证的改路记录；智能体则只在这张分流卡允许的范围内提取信息、给出建议或执行已授权的路由。

更关键的是把DDABC闭环接上：Deploy让分流进入真实工作；Analyze观察改路与超时；Benchmark比较不同规则版本；Calibrate把高频例外变成下一版标准。这样，12万封邮件不是一串令人焦虑的规模数字，而是一批持续训练组织判断力的真实样本。

企业AI的第一步，不妨少问一点“它最终能替我干多少”，多问一句“它这一次应该把谁送到哪里”。当这件事可解释、可签收、可回流，智能体才真正开始成为流程的一部分。

参考来源：Anthropic：Barclays scales Claude；OpenAI：DevDay 2026 Recap；AWS：Scaling agentic AI。