智能体是什么？企业该选 AI Agent，还是工作流？

四种能力，分别解决什么问题

用“帮客户查售后”理解智能体

假设客户发来一句“上周买的设备一直没修好，帮我看看”。聊天模型可以组织安抚用语，但不知道订单属于谁、维修走到哪里。知识库能解释售后政策；业务接口才能提供这张订单的当前状态。

如果系统能在校验身份后，查订单、判断是物流问题还是维修问题、选择对应接口，再生成带状态依据的说明，就有了智能体式的任务处理能力。若还要创建升级工单，应先让客户或客服确认处理内容，再调用写入接口。

在这个示例中，“生成建议”和“执行操作”需要分开验收：前者检查依据和表达，后者检查业务系统是否完成了正确的动作。

• 读数据：身份和数据范围由业务系统校验。
• 做判断：模型说明依据，缺信息时补问。
• 执行动作：系统记录请求、结果和操作者。

步骤确定时，工作流通常更容易验收

例如“收到表单 → 检查必填项 → 主管审批 → 发通知”，路径已经明确，规则和工作流就能完成。可以让模型辅助总结材料，但不必让它决定审批人或跳过审批。

相反，设备故障排查可能需要根据上一步结果，选择继续查手册、问用户还是查运行记录，这类路径不固定的任务才更值得评估智能体。Anthropic 的工程文章也区分了预定义工作流与模型动态决定步骤的智能体。

• 优先画出当前流程，再标出真正需要判断的节点。
• 把金额、权限、库存等确定性规则交给系统。
• 遇到目标不清或工具不可用时，允许停止并交给人。

第一个项目，挑可观察、能回退的场景

建议先选择高频、输入相对集中、有负责人审核结果的任务。例如内部售后手册问答、工单分类建议、销售跟进记录整理。先测出是否节省实际处理时间，再决定扩展到多少部门。

准备一组代表日常工作的脱敏样本，并保留一部分用于验收。样本里既要有正常问题，也要有缺资料、身份不匹配、接口报错和用户改变需求的情况。验收应检查完成情况、引用是否对应、是否越权和能否顺利交接。

• 明确一个业务负责人、一个入口和一种主要产出。
• 约定哪些动作只能建议、哪些动作可以执行。
• 首版先接少量必要工具，效果稳定后再扩展。

多智能体要为明确分工服务

把角色命名为“销售专家”“运营专家”并不会自动提高效果。如果一个模型加少量工具就能完成任务，增加角色还会增加交接、延迟和排查成本。

只有在职责、上下文或权限需要明确隔离时，再评估多个智能体协作。例如资料整理与执行审核可以独立，但最后的操作授权仍应由系统规则和负责人控制。采购时应要求演示失败样本与完整运行记录，而非只展示顺畅对话。

• 要求说明每个角色的输入、输出和存在理由。
• 核对信息如何交接，以及错误由谁发现。
• 用同一批任务比较简单方案与复杂方案。

让试点能够证明“不需要智能体”

选型试点应同时保留原流程、固定规则方案和智能体方案的对照记录。用相同输入核对任务是否完成、人工修改到什么程度，以及从收到任务到业务确认完成用了多久；不能只比较模型生成文字的速度。

• 事先写明停止条件：关键权限不成立、错误无法被发现，或维护投入超过业务可承受范围。
• 把人工复核与异常返工计入处理成本；样本规模和通过阈值由真实试点确定。
• 若规则方案已经满足验收，交付结论可以是保留工作流，只在资料理解环节使用模型。