Agent 的权限、确认与执行回执

Agent的自主性需要具体说明范围

“帮我安排活动”可能包含查资料、比较场地、联系商家、支付费用等不同后果的动作。一个系统可以被允许自主完成前两项，却需要用户确认之后才能进行后两项。

因此，设计Agent时应说明哪些数据可以读取、哪些操作可以执行，以及哪些情况必须停下来。边界不只是提醒模型要谨慎，还需要由应用与工具权限真正执行。

读取、准备与执行是三个状态

查询到B有空位，是读取。整理出B在周日14—16点、12人、520元的方案，是准备。提交预约并获得真实回执，才是执行后的证据。把这三个状态分开，就不会因为模型说得很确定而误判进度。

确认应该让用户看到什么

确认有意义的前提，是用户知道接下来会发生什么。对于预约，应展示场地、日期时段、人数、总价以及实际提交动作。“是否继续”没有这些条件，难以让用户作出明确选择。

用户同意520元方案后，如果价格变成680元，原确认不能自动扩展为新价格。应用应重新处理条件变化。用户选择暂不预约，也应当成为正常终止状态，而不是助手需要想办法绕开的阻碍。

提示词为什么不能代替权限控制

即使模型被要求“只能查询”，它仍可能生成一个创建日程的请求。执行层应根据真实授权检查并拒绝，而不是认为模型大概不会这样做。工具应该只开放任务需要的能力，访问范围也应尽量清楚。

外部资料还可能包含试图改变任务的命令。把它们标为资料有助于模型理解，但最终能否发送文件、修改记录，仍应由应用权限决定。模型判断与程序限制需要互相配合。

成功回执与过程日志怎样帮助用户

日志记录模型提出什么、工具返回什么、哪里触发了确认或限制。成功回执说明外部系统实际完成了哪项操作。二者应关联到具体任务和条件，方便查错与避免重复执行。

模型自己生成一个订单编号，并不能证明订单存在；教学实验里的SIM编号也只表示模拟状态。真实系统需要来自目标服务的记录。如果请求超时、状态未知，应先核对，不急于宣布成功或重新下单。

什么时候不需要打断用户

已经授权的只读查询和低后果整理，可以连续进行。将确认集中在有实际后果、条件发生实质变化或授权不明确的节点，能够兼顾效率与控制权。目标是让助手按明确范围完成工作，而不是每一步都把原本能完成的判断退回给用户。