通用智能体退潮后，企业该先定义哪三类专业工作？

一个能回答所有问题的智能体，听起来很省事；可一旦它要查询订单、判断退货资格、调用退款工具，问题就变成：它究竟该按谁家的规则、在哪一步停下、出了例外交给谁？9月14日，Zendesk 发布行业和自定义专业智能体，明确把行业知识、企业自身流程与已连接系统放进具体工作流，而不是继续追求一个“万能客服”。这不是单一厂商的命名变化，而是企业智能体从“会聊天”走向“能签收一段工作”的信号。

我的判断是：专业化不等于把智能体做得更窄，而是把一段业务交付拆成可复用的共同部分、必须保留本企业差异的部分，以及必须由人接管的例外部分。

先把“行业共性”做成作业包，而不是宣传词

Zendesk 首批将专业智能体落在零售服务：购物、订单管理、退换货、配送问题和退款。它连接 Shopify、Narvar、Stripe、Riskified 等系统来取数和执行动作。发布方称，这类智能体可以自动化最多 80% 的工作流；这只是其产品表述，不该被当成所有企业都能取得的平均效果。但它给出了一个很实用的拆分法：高频、步骤相对稳定、所需系统明确的工作，最适合被打成“行业作业包”。

企业不必从“做一个客服智能体”开始。不妨从“核对订单状态—比对退货条件—收集材料—发起申请—通知客户”这样的完整工作单元开始。每个单元写清输入、可查系统、完成标准和交付物。这样，业务部门讨论的就不再是模型聪不聪明，而是这段工作哪些步骤已经稳定到可以交付给机器。

再把“企业差异”留给本地规则，而非塞进一个大提示词

同样是退款，品牌的会员权益、人工审批额度、欺诈信号和补货政策都不一样。Zendesk 把这部分留给 Custom Agents：企业定义智能体拥有的工作、可使用的系统、允许的动作以及何时需要人工批准。其披露称，产品推出七周内，客户已运行超过 100 万次自定义智能体执行；部分客户的自动解决率在部署后提高 10%。这些数字同样属于厂商案例，但至少提醒我们：行业模板只能缩短起跑线，真正决定能否上线的仍是本企业规则。

Salesforce 近期提出的 Enterprise AI Harness 也指向同一层：上下文、行动、治理、安全和模型不该被每个智能体各自重建。尤其值得注意的是，它把“开放式推理”与“确定性业务执行”分开：模型可以给出候选判断，合同、库存、权限和政策决定什么能真正发生。企业要沉淀的不是一篇越写越长的提示词，而是可版本化的本地规则包——字段口径、工具权限、条件判断、承诺边界与负责人。

最后给例外留一条“人能接住”的交接线

专业智能体并不是把每一步自动化。真正有价值的专业化，是它知道什么时候不该继续。高价值客户的补偿、疑似欺诈、规则冲突、跨部门承诺，都应触发带上下文的升级：已核对过什么、依据哪版规则、卡在哪个条件、建议给谁确认。这样人工接手的不是一张空白工单，而是一份已经完成大半的业务交接。

我建议团队为每类专业工作建立一张“专业作业卡”：第一栏写行业共性流程；第二栏写企业独有政策、系统和动作权限；第三栏写不可自动处理的红线、接管人和交接信息。它比“给智能体一份知识库”更接近真正可运营的工作设计。

STARBOX视角：让专业经验成为组织资产

在 STARBOX 的组织—BOX—智能体三层里，专业作业卡不应只属于某个机器人。组织层负责确定哪些承诺不能自动给、谁拥有规则改动权；BOX 保存行业流程、企业知识、连接说明和已确认的例外处理；智能体才在这些条件内完成某一段明确的工作。DDABC 闭环则把人工接管原因、客户追问和规则冲突回流：先 Define 作业边界，再 Deploy 到真实场景，随后 Analyze 哪些例外反复出现，用 Benchmark 看时效和返工，最后 Calibrate 新版本。

通用模型会越来越强，但企业的竞争力不会是“谁先接上一个更强的聊天框”。更可能是：谁先把专业人员脑中的流程、例外与交接，整理成下一位人类和下一台智能体都能复用的作业系统。先挑一条高频又边界清楚的工作，做出第一张专业作业卡，通常比急着扩充十个通用智能体更值得。

来源：Zendesk《Specialized AI Agents》（2026-09-14）；Salesforce《Trusted Enterprise AI Harness》（2026-09-11）。文中成效数字均按发布方披露表述，不外推为行业平均。