过去两年，不少企业采购了一批"智能体产品"，上线后却发现它们和更早的客服机器人没有本质差别：能聊天、能回答常见问题，但真正要办事的环节，还是得人工去操作一遍。问题出在一个被普遍混淆的概念上——对话能力和执行能力，是两件不同的事。
聊天机器人做的是"回应"，智能体做的是"完成"
ChatBot 的工作是回应。用户提问，它生成一段文字。它的能力边界止于对话框，产出的是一段信息，至于用户拿到这段信息之后要做什么，它不关心，也无从参与。
Agent 的工作是完成。面对一个目标，它需要理解意图、拆解步骤、调用工具，最后在业务系统里把动作真正做完，并留下可以核查的结果。两者的差别不是"更聪明一点"，而是是否对结果负责。
举个具体的例子。客户来问"我上周下的订单什么时候到"：
- ChatBot 的典型回答是："通常 3-5 个工作日送达，您可以联系客服查询具体进度。"这句话没错，但客户还得自己再去找客服。
- Agent 的做法是：识别出客户身份，到订单系统里查到这笔订单，读取物流节点与预计到达时间，把结果直接回复给客户；如果发现物流异常（比如卡在中转仓超过 48 小时），它会标记出来并创建一个工单派给对应的人。
前者输出了一段话，后者完成了一件事。这就是判断的起点。
一个能干活的智能体，需要具备四个条件
1. 能接入企业的知识和数据
通用大模型知道世界上的常识，但不知道你们公司的产品参数、报价边界、售后政策、客户的历史往来记录。没有这些，它只能给出正确但无用的话。
智能体需要连接两类东西：非结构化的知识（制度文档、产品手册、历史工单、邮件）和结构化的数据（订单、库存、客户档案）。前者靠知识库检索，后者靠系统接口。
2. 能做流程判断
真实的业务几乎都有分支：金额超过 5 万要审批、新客户需要额外的资质核验、非工作时间只受理紧急工单。这些判断逻辑原本写在制度里，由人在执行时"心里有数"。智能体要能替代这一层，就必须把这些隐含规则显式地表达出来，并且在判断不确定时选择转人工，而不是猜。
3. 能真正执行动作
这是区分"演示"和"生产"的分水岭。很多产品在演示时表现出色，是因为演示环节只到"生成一段回复"为止。一旦要求它更新 CRM 里的字段、在 ERP 里提交一张单据、给审批人发起点流程，就暴露出没有系统集成能力。
动作执行通常有两条路径：系统开放 API 的直接调用接口，系统不开放的用 RPA 在界面层操作。能用接口就用接口，稳定性和可维护性都更好；只有在系统确实不开放、或者改造成本过高时，才走界面操作。
4. 能被约束和审计
企业环境里，"做对了"和"能证明做对了"同等重要。智能体需要留下完整的执行日志：谁在什么时间、基于什么信息、做了什么动作、结果如何。出了问题要能定位到具体环节，而不是笼统地归结为"AI 判断错了"。
同时要有边界约束：哪些动作可以直接执行，哪些必须人工确认，哪些数据不能对外输出。涉及金额、合同承诺、客户隐私的操作，最终确认权应当始终保留在人手上。
三个可以立刻用上的判断标准
面对供应商的产品演示，不妨从这三个角度提问：
- 它的动作边界在哪里？是只能生成文本，还是能在你们的核心系统里写入数据？
- 它的知识从哪里来？是通用语料，还是接入了你们自己的文档与业务数据？更新知识需要多久？
- 它出错了怎么发现？有没有执行日志、有没有异常告警、有没有人工复核的介入点？
如果第一个问题的答案是"生成文本"，那么它本质上还是一个 ChatBot，无论宣传页上怎么写。
两个常见的误区
误区一：模型越强，智能体就越强。实际上企业场景里的瓶颈很少是模型能力，更多是知识没有整理好、系统没有接口、规则没有说清楚。换一个更贵的模型，解决不了文档混乱和权限缺失的问题。
误区二：先做一个无所不能的助手。试图让一个智能体同时处理销售、客服、财务的所有问题，结果通常是每个场景都做得不深，用户试两次就放弃了。更有效的做法是选定一个具体的岗位任务，做到 90 分以上，让人真正愿意用，再向外扩展。
企业该怎么起步
比较稳妥的路径是：先找一个高频、规则明确、且有人愿意配合的场景，做出一个最小可用的版本，用真实使用数据验证价值。这个阶段的目标不是覆盖所有情况，而是证明"这条路走得通"。
跑通之后再考虑两件事：一是把场景扩展到同一岗位的其他任务，二是把效果指标纳入日常管理，让改进有据可依。很多项目死在"第一个场景就选了最难的那个"，而不是死在技术能力上。
如果你们正在评估该从哪里开始，可以参考我们整理的另一篇文章《企业 AI 落地从哪里开始：场景筛选的四步方法》，那里有一套可以直接打分的筛选流程。