让一个智能体替你完成一件小事，比如点一份午饭，听起来并不复杂。打开应用、选一家店、挑一份餐、确认地址、付款，步骤清晰。可一旦真的交给它，问题就冒出来了：它不知道你今天牙疼不想吃辣，不知道你上周已经连着吃了三次同一家，也不知道你临时改主意时该停下来问一句，还是继续按原计划推进。
这类细节暴露的，不是模型够不够聪明，而是智能体与“助手”之间还隔着一段距离。会调用工具、会拆解任务，只是入场券。
能做事，和知道什么时候不该做
智能体常被描述成能自主规划、调用外部工具、连续执行多步任务的一类系统。它的吸引力在于把“问答”变成“办事”：不只是告诉你哪家餐厅评分高，而是直接下单。工程上，这依赖一套循环——理解目标、拆解步骤、选择工具、观察结果、调整下一步。听起来像一个能自己推进的项目经理。
但真实环境并不配合。网页会改版，接口会超时，验证码会弹出，商家的营业状态可能和页面上写的不一样。人在这些环节里靠常识和临场判断补位，智能体则容易在某个岔路口停下来，或者更糟：它不去确认，而是猜一个看起来合理的答案继续走下去。于是任务“完成”了，结果却是错的。
所以衡量这类系统，不能只看它跑通了多少流程，还要看它在不确定时会不会停、会不会问、会不会承认自己卡住了。一个可靠的智能体，首先得知道自己的操作边界在哪里。
上下文不是越多越好
另一个常被低估的麻烦是上下文。为了让智能体更懂你，人们倾向于把更多信息塞给它：日程、偏好、历史记录、常用地址。信息越全，理论上判断越准。但上下文一多，噪声也进来了。三个月前的一次临时安排，可能被当成长期偏好；一句随口说的抱怨，可能被当成硬性约束。
更现实的问题是权限。让智能体代你发消息、改日程、提交表单，意味着它拿到了你的一部分操作权。它误发一封邮件，代价可能比答错一道题大得多。因此不少落地场景会先把动作限制在可撤回、低风险的范围内，比如草稿、提醒、检索、整理。这不是保守，而是对错误的定价方式不同：生成内容的错误可以改，已经发生的操作往往改不回来。
于是出现一种反差：越是能力强的智能体，越需要在关键节点被人接管。自动化程度和可控程度，并不总是同向变化。
把它当成实习生，而不是替身
我倾向于把当下的智能体看作一个刚入职的实习生：手脚勤快，愿意试，执行速度快，但对业务背景和例外情况不熟。交给它边界清楚、结果可验证的任务，它表现不错；交给它需要揣摩意图、权衡利弊的事，就得盯着。
这也解释了一个现象——很多团队在演示里让智能体跑完一整条链路，看起来很惊艳，真正上线时却把它拆成若干小段，每段之间留一个人工确认。不是技术退步，而是把不可控的部分收回来。对使用者来说，这种“半自动”可能才是现阶段更实际的形态。
回到点外卖这件事。理想的状态或许不是它替你做完全部决定，而是在几个关键点上问你一句：还是那家吗？今天要不要换口味？地址用公司还是家里？它负责执行和记录，你负责偏好和例外。
智能体的价值，未必在于它能独立完成多少事，而在于它能把多少琐碎环节接过去，同时把真正需要你拍板的地方留给你。想清楚这条线画在哪里，比追问它能不能全自动更有意义。