子代理不应自动继承父代理的权限

子代理通常被描述为一种分解模式：将任务拆分成更小的部分，为每个子代理分配一个角色，让父代理进行协调。这种框架很有用，但它忽略了一个安全问题。子代理不仅仅是一个更简短的提示语，它是一个新的行动者。如果父代理有权访问 Slack、GitHub、Jira、客户记录、内部文档和浏览器，那么它生成的每个子代理都应该继承所有这些权限吗？很可能不应该。那样就把委托变成了权限复制。更糟糕的是，这可能会演变成权限放大。例如：要求一个父代理调查某个客户问题。它会生成以下子代理： * 一个用于搜索日志 * 一个用于检查最近的代码变更 * 一个用于总结支持工单 * 一个用于起草客户回应 * 一个用于检查之前是否发生过类似问题 这些是不同的任务，它们不应该都获得相同的工具、数据、身份、内存和写入权限。工单总结子代理很可能不需要仓库写入权限。代码检查子代理很可能不需要客户沟通工具。客户回应子代理很可能不应该查询原始生产日志。“类似问题”子代理可能只需要对经过脱敏的事件历史进行只读访问。如果所有子代理都继承了父代理的全部权限，那么系统就没有分解风险，反而放大了风险。我认为更合理的模式是弱化委托： 父代理权限： 工具：github, jira, slack, logs, docs 操作：读取、写入、评论、创建工单 范围：customer_issue_123 时长：60分钟 子代理权限： 工具：jira 操作：读取 范围：仅限customer_issue_123 时长：15分钟 父代理可以委派任务，但只能使用比自身更窄的能力集。没有自动继承，没有随处可用的凭据，没有“相同用户、相同会话、一切都相同”。每个子代理都应具备： * 自己的身份 * 明确的工具范围 * 参数约束 * 数据访问限制 * 过期时间 * 审计跟踪 * 父/子关系 * 撤销行为 * 内存边界 这样也使得事件审查不再那么无用。不再看到： > 你可以看到： > 这更接近于安全团队能够推理的东西。 明显的缺点是复杂性。您可能不想为每一个微小的辅助提示构建一个完整的 IAM 系统。但对于能够接触高风险工具、代码、生产数据、客户消息、支付、工单、凭据、部署系统的子代理来说，完全继承似乎是一种错误的默认设置。 我正在思考几个问题： * 目前在构建多代理系统时，人们是否已经单独限定子代理的权限，还是大多数框架只是将父代理的上下文/工具传递下去？ * 当前的代理框架是否容易实现这一点，还是需要自定义编排？ * 子代理是否应该拥有独立的身份，还是父代理身份加上委托范围就足够了？ * 这里最小的实用控制是什么：工具允许列表、参数约束、时间范围限制，还是独立凭据？ * 如果父代理被停止，撤销应如何发生：是否所有子代理和排队的子任务都应自动终止？ * 有没有人在生产环境中遇到过真正的问题，还是这主要是一个设计上的担忧？ 我目前的倾向是：默认情况下，子代理应获得比父代理更少的权限。委托应弱化权限，而不是复制它。