多 Agent 协作的权限边界任务不能替人越权多 Agent 最容易把“能调用”误写成“有权限调用”。规划 Agent 把任务交给执行 Agent并不代表执行 Agent 获得了发消息、删文件或提交订单的权力。任务描述是建议授权应是单独的系统状态。权限跟工具和资源走给每个工具定义动作、资源范围和调用身份。例如“查订单”只读、“修改收货地址”只允许当前用户自己的订单“退款”则需要额外确认。把这些约束放在工具服务端校验不能只依赖 prompt 里的一句“请谨慎”。Agent 之间传递的上下文也不该自动继承高权限凭据。下游如果确实需要执行敏感动作应该拿到一次性、范围受限的授权而不是复用上游的长期 token。转交要保留可审计的意图记录谁发起了请求、哪个 Agent 提议动作、实际调用了什么工具、参数摘要和结果。日志里避免直接写入密钥或完整隐私字段但要能把一次工具调用追溯回用户请求。测试时故意让低权限 Agent 尝试读取越界资源、伪造上游转交信息或重复提交敏感操作。它们应得到明确拒绝而不是靠模型“恰好听话”。多 Agent 系统像办公室传话谁能说什么、谁能盖章必须分开。 多 Agent 协作的权限边界任务不能替人越权多 Agent 最容易把“能调用”误写成“有权限调用”。规划 Agent 把任务交给执行 Agent并不代表执行 Agent 获得了发消息、删文件或提交订单的权力。任务描述是建议授权应是单独的系统状态。权限跟工具和资源走给每个工具定义动作、资源范围和调用身份。例如“查订单”只读、“修改收货地址”只允许当前用户自己的订单“退款”则需要额外确认。把这些约束放在工具服务端校验不能只依赖 prompt 里的一句“请谨慎”。Agent 之间传递的上下文也不该自动继承高权限凭据。下游如果确实需要执行敏感动作应该拿到一次性、范围受限的授权而不是复用上游的长期 token。转交要保留可审计的意图记录谁发起了请求、哪个 Agent 提议动作、实际调用了什么工具、参数摘要和结果。日志里避免直接写入密钥或完整隐私字段但要能把一次工具调用追溯回用户请求。测试时故意让低权限 Agent 尝试读取越界资源、伪造上游转交信息或重复提交敏感操作。它们应得到明确拒绝而不是靠模型“恰好听话”。多 Agent 系统像办公室传话谁能说什么、谁能盖章必须分开。 
