智能体权限边界
一句话规则
每个智能体做事时，只受它自己的权限上限约束；如果发生越权，责任在执行操作的那个智能体，而不是发起请求的那一方。
为什么需要这条规则
当同伴之间开始互相协作 -- 一个同伴请另一个同伴帮忙、给正在忙的同伴补一句话、或者打断它 -- 就出现一个必须回答的问题：
甲同伴让乙同伴去做一件事，这件事按谁的权限算？
有两种可能的答案，DesireCore 选择了第二种。
方案一：按发起方的权限算（未采用）
发起请求的同伴权限有多大，被请求的同伴就只能做多大范围的事 -- 相当于"权限只能越传越小"。
听起来更安全，但它在真实场景里会立刻崩溃：
- 专业分工失效：你的"日程助理"权限很小，它只能读日历。当它需要请"文书同伴"起草一份会议纪要时，如果按它的权限算，文书同伴连写文件都做不了 -- 而写文件正是你当初赋予文书同伴的职责。
- 责任变得模糊：一个操作到底该不该做，取决于"是谁让它做的"，而不是"做这件事的是谁"。同一个操作，A 请它做就允许、B 请它做就拒绝 -- 你没办法通过看一个同伴的配置来判断它到底能做什么。
- 权限只减不增，最终归零：多层协作下（甲请乙、乙请丙），权限一路收窄，链条稍长就什么都做不了。你会被迫给每个同伴都开更大的权限来"抵消"这种收窄 -- 结果是整体权限反而变大了。
方案二：按执行方自己的权限算（DesireCore 采用）
谁动手，就按谁的权限算。
- 乙同伴收到甲同伴的请求后，仍然完整地按它自己被授予的权限行事：它能读什么、能写什么、能调用哪些工具，只看它自己的配置。
- 甲同伴无法通过"请乙帮忙"这个动作，让乙做出超越乙自身权限的事 -- 因为乙的权限本来就是它的天花板。
- 反过来，甲也无法通过"请乙帮忙"给自己扩权 -- 乙做的事记在乙的账上，产出回到甲手里，但执行发生在乙的边界内。
越权责任在执行方
这条规则的另一半同样重要：如果一个同伴做出了不该做的事，责任记在它自己头上。
- 每个同伴的能力边界写在它自己的配置里（工具授权、文件读写范围、风险等级），这份配置是你亲手定的。
- 它做的每一次操作都进入它自己的回执与审计记录 -- 你看一个同伴的回执，看到的就是它真实做过的全部事情，不需要再去追"这是谁指使的"。
- 因此排查问题时的路径是确定的：先看是哪个同伴动的手，再看它的权限配置为什么允许了这件事。
换句话说，权限配置是一份关于这个同伴的承诺，而不是一份"关于谁能指使它"的规则。你调整一个同伴的权限，就调整了它在任何情况下的行为上限 -- 无论请求来自你、来自另一个同伴、还是来自定时任务。
这条规则覆盖哪些情况
只要是"一个同伴让另一个同伴做事"，都适用：
| 场景 | 说明 |
|---|---|
| 委派任务 | 甲把一件事交给乙去做 |
| 发消息 | 甲给乙发一条消息，乙据此起一轮工作 |
| 插话 | 乙正在忙，甲往它当前这轮里补一句话 |
| 打断 | 甲中止乙正在进行的工作 |
| 团队分发 | 甲把同一件事同时发给多个同伴 |
以上每一种，执行的那一方都按它自己的权限行事。
这不会削弱可控性
这条规则不是在放宽限制，它只是把限制放在了正确的位置：
- 你的授权仍然是唯一的来源。 同伴的权限从来只由你配置，同伴之间不能互相授予权限，也不能通过协作绕开你的设置。
- 三层可控性 完整生效。 不管这一轮是你发起的还是别的同伴发起的，高风险操作照样触发人闸门、照样有回执、照样可回滚。
- 边界更容易检查。 你只需要回答"我给这个同伴开了什么权限"，而不需要在脑子里模拟"如果它被某个别的同伴调用，权限会变成什么样"。
如果你不希望某个同伴具备某种能力，正确的做法是收紧它自己的权限配置 -- 而不是指望别的同伴在调用它时替你把关。
一个具体例子
假设你有两个同伴：
- 日程助理：只能读日历，不能写文件
- 文书同伴：可以在
~/文档/下读写
当日程助理请文书同伴"把今天的会议整理成纪要"时：
- 文书同伴按自己的权限执行 -- 它可以在
~/文档/下写入纪要文件； - 但它同样不能越过自己的边界 -- 比如它无法去改
~/系统配置/下的东西，即使日程助理这么要求； - 纪要写入这件事记在文书同伴的回执里；
- 如果你认为"文书同伴不该有写文件的权限"，你要改的是文书同伴的配置，而不是限制日程助理去请它帮忙。