先把部门需求拆成具体任务
“给销售部门做一个智能体”无法直接用于选型。销售工作包含产品资料查询、客户记录整理、报价计算和合同承诺，各环节的数据与责任不同。应先把需求写成“谁在什么条件下，使用什么输入，得到什么结果”，再判断是否需要模型参与。
以售前答复为例，理解客户的自然语言、查找相关产品资料和生成初稿适合评估AI；价格折扣是否获批，应由现有权限和规则控制。一个流程可以同时包含模型、传统程序与人工，并不需要整体改成自主执行。
用四个维度筛选候选场景
任务频率决定改善是否值得投入，但高频不代表一定适合。如果输入与规则完全固定，普通接口或工作流通常更直接。模型更适合处理存在语言理解、文档理解或非固定表达的部分。
数据条件决定结果有没有依据。资料是否有效、是否存在负责人、权限是否可识别，都比文件总量更关键。流程边界决定任务是否可结束：无法说明成功与失败的任务，很难建立可靠验收。错误成本则决定自主程度，答错一条内部说明与误发付款指令不能采用相同控制。
一张判断表应该记录什么
对每个候选任务记录月发生量、当前平均处理时间、输入类型、权威数据源、涉及接口、人工复核时间与失败后果。可以采用高、中、低标记，但不要把没有实测的主观分数当成精确收益预测。
例如，“检索设备说明书并定位故障代码”有明确资料来源，适合作为只读试点；“自动判断维修责任并批准赔偿”涉及合同与责任，宜保留授权人员判断。前者的成功经验不能直接证明后者也能全自动实现。
哪些情况应该暂缓开发
资料本身错误、业务规则尚未统一、系统没有可用接口，或无法获得授权样本时，应先解决基础条件。让模型猜测缺失数据，并不能替代制度梳理和系统建设。
对于极低频且每次高度特殊的任务，单独开发可能难以覆盖维护成本。对于固定计算和明确判断，先评估规则引擎或现有软件配置；不要仅因为需求包含文本就默认使用Agent。
从两个候选任务中选择试点
假设团队同时提出“定位售后政策”和“自动确定赔偿金额”。前者可先提供问题与适用产品，从正式政策返回引用，由坐席确认；后者还涉及合同、个案证据和审批。即使两者都频繁发生，也应分别评估，不把它们打包为一个自动客服项目。可以先测前者的资料覆盖与复核负担，再判断是否值得扩展到赔偿申请草稿。
- 有没有明确且持续维护的权威来源。
- 是否能写出成功、拒绝与转人工的条件。
- 失败能否在产生业务后果前被发现。
- 当前任务是否其实更适合固定规则。
用小范围验证决定是否扩大
选择一个业务负责人愿意参与、资料可获取、失败可转人工的任务，建立一组真实问题和正常处理记录。比较处理前后的总耗时，并把核对答案、修正结果与维护资料的时间计入。
只有任务完成质量、权限隔离和业务收益都能被验证，才适合扩展范围。试点结论也可以是继续使用人工或传统自动化；能排除不合适的投入，本身就是有效的技术决策。
业务范围与项目沟通入口：企业AI Agent解决方案与定制开发服务。