企业AI别再重造智能体：8个案例给出的规模化答案

一个部门做了客服智能体，另一个部门又从头做销售助手，第三个部门重新接了一遍同样的知识库和审批接口——这恐怕是企业AI最昂贵、也最常见的重复劳动。每个演示都能跑通，组织却始终无法形成规模效应。

IBM在7月16日梳理了8个生产环境中的智能体部署，横跨保险、招聘、法律、医疗、IT服务与公共采购。它们的共同难题不是“模型够不够聪明”，而是如何让智能体接入真实业务流程、在可信上下文中工作，并把已验证的智能体、工具连接和集成模式带到下一个场景。这个信号很值得企业重视：智能体规模化的单位，不该是一段新提示词，而应是一份可复用的业务能力包。

从“能回答”到“能交付”，先把工作流做成边界清楚的产品

在IBM列出的案例里，效果较好的做法都没有把聊天窗口当作最终产品。保险审核要先确定损失类型、调取保单、必要时做OCR，再按固定问题表输出证据；招聘流程要协调邀请、提醒、排期、完成追踪和例外；法律研究则把问题分类、资料检索、条款比对和专业复核拆开。智能体只在需要理解语言、归纳信息或匹配路径的环节发挥作用，规则明确的步骤仍由流程和系统兜底。

一项可复用能力，应先说明它解决什么业务动作、需要哪些证据、能调用什么工具、何时必须升级给人，以及结果写回哪里。

这和“做一张任务卡”还不完全一样。任务卡解决的是单次任务是否可委派；能力包则进一步解决：当同类任务出现在不同团队、不同入口和不同系统里时，哪些部分可以原样拿走，哪些部分必须按业务边界重配。先把这个接口讲清楚，复用才不会变成把一段不透明的提示词复制到更多地方。

真正值得沉淀的，是三类“可拼装件”

第一类是流程骨架：触发条件、处理顺序、证据要求、人工审批点和系统记录点。第二类是受治理的连接件：谁可调用哪个数据库、CRM、工单或文档接口，读写权限如何授予、撤销和记录。第三类是可信上下文包：知识来源、适用范围、更新时间、引用要求与不适用情形。

例如，IBM案例中的Dynamiq把已经跑通的多智能体法律研究工作流作为外部智能体接入，让获授权用户能从新的入口调用同一能力，而不用为每个团队重建研究逻辑。CrushBank则把分类、定级、上下文补全和路由能力放在同一编排层，并把相同基础延展到遗留应用现代化、保险理赔和医疗计费。前者说明专业能力可以跨入口复用，后者说明通用流程能力可以跨场景迁移。两者都不是简单复制“一个机器人”，而是复用经过验证的结构。

给新智能体加一道“先找再造”的发布门槛

我建议企业把立项顺序反过来：业务团队提出需求后，先检索现有能力目录——有没有可复用的流程骨架、已批准的工具连接或相近知识包；只有缺失的部分才新建。一个新能力发布前，至少应补齐五项信息：业务负责人、适用任务、输入输出约定、权限与审批边界、版本和退役规则。这样，目录不只是“存了多少智能体”的台账，而会变成让复用比重造更容易的交付入口。

衡量方式也该随之变化。除了单个智能体的使用次数，还要追踪复用率、接入新场景所需时间、因复用减少的连接开发量，以及复用后是否引入新的例外或人工接管。规模化不是把智能体数量做大，而是让每一次新交付都能继承上一轮已经验证过的组织能力。

STARBOX视角：把能力包放进BOX，而不是散落在个人项目里

在STARBOX的组织 → BOX → 智能体三层架构中，组织层应决定哪些能力值得统一沉淀、谁批准跨团队复用；BOX层承载流程骨架、行业知识、客户旅程、工具连接规范和成功样例；智能体层则按已定义的边界执行和组合。每次人工接管、异常处理与新场景适配，都可以通过DDABC闭环回写到能力包中。

这带来一个很实际的判断：企业的AI资产不只是“某个智能体有没有上线”，而是它是否留下了别人可以安全继承的工作方法。真正有复利的智能体，会让下一个团队少接一次接口、少踩一次权限坑、少从零验证一遍流程。

当你的团队准备再做一个新智能体时，不妨先问一句：我们是在增加一个孤岛，还是在给组织的能力库添一块能继续拼装的积木？答案，决定了AI投入会不会越做越快。

信息来源：IBM《How customers build practical agentic AI with IBM watsonx Orchestrate》（2026年7月16日）。文中客户成效为IBM披露的个案数据，不应直接视为普遍基准。