早上九点，邮箱里多了一封“已替你回复”的邮件。发件人是团队刚接入的 AI Agent。它读了三封往来邮件，把会议时间挪到周四，还顺手把附件放进了共享目录。事情办得不算离谱，但收件人里有一位外部合作方，而共享目录的权限范围，没人说得清。
先把权限说清楚，再谈能力
讨论这类系统时，演示常从“它能做什么”开始：查资料、改表格、发消息、调用接口。真正进入日常协作，问题会反过来：它被允许做什么，做到哪一步需要停下来问人。权限不是一句“只读”或“可写”就能覆盖。邮件可读，不代表附件可外发；日程可改，不代表能替人答应邀约；数据库可查，不代表能把结果贴进公开文档。
把这些边界写进配置，听起来像工程细节，实际是产品设计的一部分。一个 AI Agent 如果无法说明自己调用了哪些工具、碰过哪些文件、在哪个环节等待确认，使用者就很难建立稳定预期。可解释在这里不是抽象口号，而是操作记录：看见了什么，改了什么，为什么改。
被省掉的往往不是动作，是上下文
自动化的吸引力在于省事。人写一封邮件要回想前因后果，系统代写时，省掉的是敲键盘，还是理解关系？这两件事差别很大。客户上周提过预算收紧，同事昨天在群里补了一句“先别承诺交付日期”，这些信息散落在不同地方。AI Agent 如果只读到邮件线程，可能给出一个语法通顺、语气得体、却踩到边界的回复。
所以，上下文交接比工具数量难处理。工具可以逐个接入，上下文却需要判断哪些该带、哪些不该带。带多了，可能把内部讨论泄露出去；带少了，回复看似礼貌，实则缺少前提。一个可行的做法，是让系统在跨出原任务范围时显式提示，而不是默默补全。提示不必长篇大论，一句“这封回复将引用内部排期，是否继续”就够。
失败时谁来停手
系统执行到一半卡住，常见反应是重试。重试本身没问题，问题在于重试的代价由谁承担。重复发邮件、重复下单、重复修改文档，都会把一个小故障放大。对 AI Agent 的期待里，应当包含“停下来”的能力：遇到权限不明、收件人异常、金额或时间超出预设范围，先暂停，留下可读的原因，等人接手。
这也解释了为什么不少团队从低风险环节开始试用，而不是一上来就交出完整流程。试用不是保守，而是给边界留出被观察的机会。人需要看见系统在哪一步犹豫、在哪一步自作主张，才能决定下一轮把权限放宽还是收紧。
人留下的判断，不该只是兜底
如果人的角色只剩“出问题时点一下确认”，那更像是守在机器旁边。人的判断应前置到规则设计：哪些任务可以自动完成，哪些必须双人确认，哪些干脆不交给系统。这个分工不需要宏大叙事，它藏在一次日程调整、一封邮件回复、一份文件归档里。
AI Agent 的讨论容易滑向两种极端：一种把它当成万能助手，一种把它当成随时闯祸的黑箱。日常使用大概落在中间——它能接手一段流程，但需要清楚的权限、可追溯的记录和随时停下的开关。技术会继续变化，这几件事不会因为模型变强就自动消失。