想象一个再普通不过的下午：你把一份采购申请的流程交给智能体，它自己读邮件、填表、点提交，前几次都顺顺当当。第十次，它把某一栏填错了——这时候，谁会先发现？
这个问题听上去琐碎，却几乎是所有团队把它从演示搬进日常时都会撞上的那道墙。
它做的是一连串动作
聊天机器人给的是一段话，看完你可以选择信或不信。智能体不一样，它把观察、判断、调用工具、再看结果连成一个循环，循环会自己往下走。工具调用、记忆、任务拆解这些说法背后，无非是同一件事：它开始连续地做事，而做事是有后果的。
一旦承认这一点，评价它的重心就会挪位置。不是“它有多聪明”，而是“它做完之后，痕迹留在哪里”。
错误会沿着链条自己走路
单步回答错了，人扫一眼就能看出别扭。多步操作里，一个错会被下一步当成前提接着用，等到结果不对时，已经离源头很远了。所以流程设计里真正要紧的，不是保证每一步都对，而是提前标好哪一步必须停下来等人。
- 不可逆的动作，比如删除、对外发送、修改他人权限，应当由人按下确认；
- 可逆但影响面大的动作，要留得住日志，能回退，能中途掐断；
- 会让权限放大的操作，单独走一次审批，而不是混在日常流程里。
这些做法不新鲜，甚至有点笨。但它们决定了这个系统是能长期开着，还是只能关在演示环境里。
卡住人的往往不是模型
讨论大多集中在能力上，落地时真正磨人的却是权限、审计和责任划分。给智能体的账号权限越大，省下的人工越多，可能捅的窟窿也越大。最小权限、全程可追溯、随时可中断，这三件事听起来像老派的管理要求，实际是它能被信任的前提。
还有一层容易被忽略：当结果由人和智能体共同完成时，出错的归因会变得模糊。是流程没写清，还是执行时理解偏了？如果没有留痕，这个讨论根本没法进行。所以我更愿意把日志看成产品的一部分，而不是运维的附属品。
值得用的边界
判断标准其实很朴素：关键不在“它能不能做”，而在“做错了以后，修起来贵不贵”。重复、边界清楚、结果可校验的活儿，交出去风险有限；结果模糊、反馈周期长、一旦出错就要牵动很多人的活儿，人还是得在场。这不是对技术悲观，只是对成本诚实。
回到开头那个下午。真正需要先想清楚的，也许不是它能替你做多少事，而是它填错那一栏的时候，这条链上有没有人接得住。