早上九点，群里跳出一句“昨天的异常报表谁看一下”。几秒后，一个挂着助手名字的账号回了“我先查”，随后拉取记录、列出可能原因，还问要不要直接改配置。办公室里安静了一下：让它查没问题，让它改，谁签字？
这类场景正在变多。把智能体放进日常流程，最先暴露的往往不是能力上限，而是边界。它会拆任务、调工具、等结果，再决定下一步。演示时这叫自动化，真用起来，问题变成：什么时候该停，停之前要不要请示，出了偏差谁来收尾。
它像同事，但不是同事
一个能自己拆任务的执行者，看起来像多了一个同事。区别在于，同事知道“这事不该我定”，也会在不确定时先问一句。智能体没有这种默认的社交分寸，它倾向于沿着目标往下走。目标写得越顺，越容易把“能做”误当成“该做”。
所以权限要切碎，不要给一把万能钥匙。查询、起草、提交、修改、对外发送，最好分开。能读的不一定能写，能写的不一定能发。每一步都留下可回看的记录，事后解释“它为什么这么做”时才有依据。记录不必复杂，时间、动作、输入、结果，够用就行。
先设计停下来的地方
很多讨论喜欢问智能体能不能独立完成长任务。我更关心它能不能在合适的时候停下来。停下来的条件要提前写清楚：信息不足时停，涉及外部承诺时停，动作不可逆时停，连续失败时停。停不是失败，是把判断交还给人。
还有一点常被忽略：交接。一个任务从人转到智能体，再从智能体转回人，中间要有可读的上下文。只留一句“已完成”不够，至少要说清做了什么、还缺什么、下一步建议是什么。否则人接手时等于重新开局，省下的时间又还回去了。
我不觉得智能体会很快取代一整条业务链。现实的变化是，它先把流程里那些重复的、可拆的、结果可验证的片段接过去。人退后半步，做目标设定、边界判断和异常处理。这个分工不新鲜，只是现在多了一个会自己往前走的执行者。
真要让它在团队里待得住，评价标准也得换。别只看它省了多少步，还要看它有没有制造新的返工、新的解释成本、新的风险口子。一个安静的、知道何时停下的智能体，往往能减少后续的解释成本。