设想一个很日常的任务：你告诉一个智能体，“周六下午去杭州，靠窗，别太晚到”。它打开日历、查车次、填订单，中途回头问你一句“下午三点这班行不行”。整个过程看起来顺滑。真正决定它能不能被托付的，往往不是它会不会查票，而是它知不知道自己查得对不对。
能调用工具，还只是在入门
聊天机器人给你答案，智能体给你动作。动作意味着它要把目标拆成步骤，挑工具，读返回值，再决定下一步。这里有个常被忽略的缺口：工具的返回值不是结论，只是线索。接口显示“有票”，不等于“能锁定座位”；页面跳转成功，不等于订单已经成立。很多演示看起来顺，是因为演示者站在旁边，替它把这些缺口补上了。
第一个问题：它怎么知道自己做完了
任务需要可验证的收尾信号。订票的收尾信号是订单号和支付状态，不是“页面提示成功”。如果拿不到这类信号，它就只能靠语言自我确认，把“看起来完成”当成“完成”。所以在布置任务前，可以先问一句：成功的样子，机器读得到吗？读不到，就给它一个能读到的凭据，或者安排人工确认。
第二个问题：做错了，退得回来吗
读取类动作错了，代价是重来；写入类动作错了，代价可能不可逆。发消息、下单、改配置、删文件，这些权限给不给，取决于有没有确认和回滚。一个土办法是把动作分级：只读、可撤销写入、不可撤销写入，分别对应不同的确认点。这不是不信任模型，而是承认它会犯错。把失败的成本设计得低一些，比在提示词里反复叮嘱“小心”有用。
第三个问题：它记得的东西，什么时候过期
上下文是它的工作台，不是档案柜。上一轮读到的价格、库存、时间，过一会儿可能就变了。如果把旧信息当现状，后面的动作就会偏。需要明确：哪些信息每次重取，哪些可以短暂缓存，缓存多久。这个细节不起眼，却决定它在真实环境里稳不稳。
演示与生产之间，隔着一堆琐事
演示里任务边界清楚、环境干净、失败可以重来；生产里接口会超时，页面会改版，权限会过期。差距常常不在模型能力，而在这些边角。看一个智能体值不值得用，可以观察它失败时的反应：是停下来问人，还是硬着头皮编一个结果。前者可以商量，后者很难收拾。
所以不必急着把整条流程交出去。先挑一件低风险、可回滚、结果可验证的小事，让它做，观察它怎么确认、怎么求助、怎么收尾。这件小事稳了，再谈更长的链条。它不太像魔法，更像一个需要交接文档的新同事——你得先告诉它，什么算做完。