第一个智能体跑顺了，团队通常很兴奋。
下一个想法很快出现：客服做一个，销售做一个，运营也做一个。三个月后，三个项目都在等数据、等权限、等接口。
问题不是场景选错，而是扩展顺序不对。
先看哪些东西可以复用
第一个场景做得好，不代表第二个能直接复制。
先分清哪些是共享的，哪些是场景独有的。
共享的通常包括：账号体系、知识库结构、权限规则、日志、评测方法。独有的通常是：业务规则、数据源、回答模板、人工接管方式。
扩展前，先把共享部分沉淀下来。否则每做一个新场景，都要重新搭一遍。
补共享知识
第二个场景如果还需要重复整理同一批产品资料、客户信息或政策，说明知识没有复用。
先把知识按主题整理，而不是按项目整理。产品资料、售后政策、销售话术，可以服务多个智能体。
知识条目要有来源、版本和负责人。场景越多，越需要这套基础。
补权限
场景一多，权限就会变复杂。
客服能看客户信息，销售能看报价，运营能看内容数据。不同智能体共用一套账号体系时，要能区分谁能看什么。
如果第一版是全员一个权限，扩到第三个场景前必须改。否则数据边界会越来越模糊。
补评测
第一个场景可能靠人工感觉验收。
扩场景后，要有一套可复用的评测方法：测试集怎么建，指标看什么，人工接管怎么算，谁来复核。
没有统一评测，每个场景都各说各好，管理层无法判断该继续投还是停。
补负责人
每个场景都要有业务负责人。
不能所有智能体都由一个项目组维护。业务负责人决定场景边界和验收标准，项目组负责平台、接口和工具。
负责人不清，场景越多，协调成本越高。
扩展顺序
先扩和第一个场景最接近的，比如从客服常见问题扩到售后流程。
再扩共享知识最多的，比如从产品问答扩到销售资料查询。
最后扩跨部门、跨系统的场景。每扩一个，先跑两周，看使用率和返工率，再决定下一个。
边界
不是所有场景都值得扩。
如果第一个场景使用率还很低，先修第一个，不要急着开新的。如果知识、权限、评测都没沉淀，扩得越快，维护越乱。
智能体应用的价值，不是数量多，而是每个都能稳定工作。扩场景之前，先把能复用的基础补起来。
共享组件要版本化。知识结构、权限规则、评测集改了，要记录改了什么、影响哪些场景。没有版本记录，第三个场景出问题时，很难判断是哪个改动引起的。
扩场景前，先把第一个场景的配置整理成可复制的模板。
如果你在规划智能体应用，可以看我们的企业 AI 与智能体服务，也可以从智能体应用场景排序开始，先排优先级。