周一早上，你把一句话丢给系统：“把下周三位客户的拜访行程排一下，别和团队周会撞车。”几分钟后，一份看起来完整的日程出现了：时间、地址、联系人、交通建议，连午餐空档都留好了。你差点直接转发。再细看，第二天的两个地址跨了半个城市，中间只留四十分钟；一位客户上周刚改过见面偏好，系统没记住；麻烦的是，它顺手把团队周会挪了，却没告诉你。
这不是要否定智能体。恰恰相反，这种“几乎做对”的体验，说明它已经越过只会聊天的阶段，开始接触真实任务。但企业场景里，“几乎”和“完全不会”是两种风险：完全不会，人会自己上手；几乎做对，人会放松检查。
它缺的不是智商，是任务边界
不少人把智能体理解成“一个会动手的模型”。更准确地说，它更像带着工具、记忆和循环流程的执行者：理解目标，拆步骤，调用日历或地图，读取结果，再决定下一步。模型只是其中一环，问题常出在环与环之间。
比如“别和团队周会撞车”，对人类同事意味着“可以提议调整，但要先确认”。对系统来说，如果没有明确约束，它可能直接把“避免冲突”翻译成“修改周会”。目标理解、权限范围、动作后果，只要有一件模糊，任务就会偏。
- 目标是否可验收：是给出建议，还是直接发出邀请？
- 工具权限到哪一层：只读日历，还是可以改期、发消息、下单？
- 失败如何收场：遇到冲突时停下来问，还是自行找替代方案？
这些不是提示词能完全解决的。产品设计里要写清楚：哪些动作可逆，哪些必须二次确认，哪些要留下操作记录。一个可靠的智能体，不一定是动作多的那个，但应该知道什么时候停。
“我做不到”是能力，不是缺陷
我们习惯用完成率衡量工具，却容易忽略拒绝的质量。真实办公里，靠谱的同事不是有求必应，而是会说“这个信息我没权限查”“这个时间我不能替你改”“这个判断需要你确认”。智能体要学会类似表达，前提是系统允许它承认不确定。
这听起来反直觉。企业采购时常常想看它一口气完成多少步，演示里连续调用工具也确实好看。但生产环境和演示环境隔着一层：真实数据会缺字段，真实权限会过期，真实任务会中途变卦。若系统把“继续尝试”当成默认策略，小错误会在多步执行里滚大；及时停下、说明卡点，反而把可控性拉回来。
所以我看这类产品时，会特别留意失败提示。它是笼统地说“任务失败”，还是能讲清楚“缺少哪项权限、哪条信息冲突、建议谁来处理”？前者只适合演示，后者才接近协作。
先别问能替代谁，先问怎么验收
企业引入这类系统，容易从“能省几个人”开始算账。这个问法太早，也容易把讨论带偏。更实际的问题是：这类任务原来怎么验收，现在还能不能验收？如果答案是“看结果差不多就行”，风险已经埋下了。
可以把试用拆小一点。选一类可回滚、低风险、结果容易检查的任务，比如整理会议纪要、生成行程草案。先只给只读权限，要求它输出“建议”而不是“执行”。观察三件事：它是否会主动提问；它是否能把依据和不确定点分开写；它是否在信息不足时停下来。稳定之后，再逐步放开写入类动作。
还有一个常被忽略的成本：人机交接。它做完一半，人接手时能不能看懂做过什么、为什么这么做？如果过程不可读，省下的操作时间会变成排查时间。操作日志、步骤摘要、失败原因，这些不显眼的部分，往往决定它能不能进入日常流程。
回到开头那份行程。理想状态下，它不该悄悄改掉周会，而应该说：“第二天两个地址距离较远，当前安排可能来不及；我可以把第二场挪到下午，或者把周会改到上午，你选哪个？”这句话没有多高的技术含量，却把主动权还给了人。这类系统真正的进步，也许不是替人做更多决定，而是把“该谁决定”分得更清楚。