博客权限管理设计
共享 AI Bot 的权限管理：按需查询用户角色
共享 Bot 如何识别请求者、按需查询自然语言角色策略，并把配对、工具审批和资源权限分开？从邮件助手案例看 DeepSeekBot 的设计取舍。
一个 AI Bot 被拉进公司群聊，每位成员都能 @ 它。它既可以通过命令行读取公司邮箱，也能修改代码。问题随之而来：同事 A 可以查询项目邮件，同事 B 只能讨论代码。如果两人发出同样的邮件查询请求，Bot 怎么知道该为谁执行、为谁拒绝？
共享 AI Agent 的权限管理至少要回答四个问题：
- 谁能发起请求？ 识别实际请求者，并判断是否获准与 Bot 对话。
- Bot 应怎样处理这个人的请求？ 根据角色理解行为策略。
- 谁能批准操作？ 检查操作者是否具备相应管理能力。
- 执行进程能接触什么资源？ 看实际凭据和执行环境的边界。
我们的选择是：用程序把守请求入口，让 Bot 按需查询当前角色，用自然语言表达行为策略，再分别处理管理授权和执行资源的边界。
本文基于 DeepSeekBot 的角色与准入设计提案，不是整套功能的发布公告。下面用一个假设的“团队邮件助手”，说明这套方案的取舍。
业界先例：自然语言策略控制了什么？
“用自然语言写权限”已有先例，但不同方案的控制点并不相同：
| 路线 | 文字规则用于什么 | 实际控制位置 |
|---|---|---|
| 主 Agent 行为策略 | 模型读取规则，决定如何处理请求 | 模型行为；文字本身没有确定性的操作拦截 |
| Hermes smart policy | 辅助模型判断危险命令应批准、拒绝还是转交人工 | 命令审批流程；当前输入不包含逐人的可信角色 |
| AWS AgentCore | 自然语言要求转换成 Cedar 策略 | Gateway 在工具调用前执行结构化策略 |
Hermes 的 approvals.smart_policy 是一个已有实现：管理员用文字编写规则，独立的 guardian 模型评估被标记的命令，审批流程使用其判断。它解决的是命令风险，而非共享群聊中的完整逐人角色权限。Hermes 源码
Hermes 社区还有一个接近我们场景的报告：团队把“非管理员不能执行终端”写进主模型 prompt，但模型仍执行了命令，随后他们请求增加逐用户工具限制。这是部署者的反馈，我们没有独立复现。原始讨论 #3897
AWS 则已讨论自然语言授权：先生成并校验 Cedar，运行时由 Gateway 判定。自然语言是编写入口，执行依据是结构化策略。
DeepSeekBot 的这份提案选择另一种组合：把请求准入交给程序，把当前角色提供给 Bot，接受自然语言作为行为策略。需要强制资源授权时，再为实际执行路径建立相应边界。
核心设计：四个边界分别处理
这四部分各自解决一个问题，不能把它们合起来理解成“所有工具都已被强制授权”：
群消息
↓ 程序准入
带可信作者的请求
↓ Bot 按需查询当前角色
模型处理请求
管理动作
→ Host 检查管理能力
Shell 资源访问
→ 凭据和执行环境决定
1. 程序准入与可信身份
请求者身份来自平台认证的消息作者，不能从昵称、自称“我是管理员”或引用的聊天内容中推断。身份还要带上当前 Bot 和应用绑定的作用域：Slack 用户不能自动等同于 Lark 的同名用户，在 Bot A 获准也不意味着在 Bot B 获准。
邮件助手所在的群是受限群。未配对的 A 第一次 @ Bot 时，程序创建或复用申请，并回复固定提示。这一过程不调用 LLM，也不把被拦住的请求排入待执行队列。
管理员审核申请，为 A 指定角色。批准后，系统通知 A 重新提问，不自动执行旧请求。否则，一条几小时前的问题可能在审核结束时突然开始运行。撤销配对后，下一次受限请求应再次在模型入口被拦住。
特定群也可以显式允许访客提问，但访客资格不附带工具审批或角色管理能力。是否收集群消息、是否必须 @、什么时候唤醒 Bot，是另外的设置。
2. 按需查询角色，减少重复上下文
把整个团队的角色目录放进 system prompt，会增加上下文；每次复制一份权限，也可能让历史配置看起来仍然有效。我们选择让每条消息保留可信作者及来源引用，再提供一个只读的单人权限查询 Tool。
普通闲聊不必查角色，但作者身份仍然保留。遇到新的、受角色策略约束的请求时，Bot 查询实际请求者，而不是把背景消息中另一个人的权限借过来。
A 问“今天有哪些邮件需要跟进”，查询结果可以这样表达：
配对状态：已批准
角色：邮件查询员
行为策略：允许查询和整理；不允许编辑或发送
管理能力：空
策略版本：7
查询时间：2026-10-11T09:00:00Z
这是示意结果，不是已发布的 Tool 接口。查询必须在当前 Bot 与应用作用域内读取权威配置，不能靠模型猜身份。管理员修改角色后，下一次查询应返回新版本；历史中的版本 7 仍然只是当时的记录，不会自动更新。
查询提供当前信息，不授予权限，也不保证每次执行都被授权。 模型仍可能漏查或误解；行为指引要求它在身份无法解析或查询失败时暂缓受策略约束的操作。查到别人的角色，不能代替那个人审批；新查询结果也不能单凭自身停止已经运行的任意 Shell 命令。
3. 自然语言策略与结构化管理能力
管理员可以给 A 分配这样的角色：
角色：邮件查询员
行为策略：
允许查询公司邮箱并整理待跟进事项。
不允许编辑草稿或发送邮件。
结构化管理能力：空
文字部分适合表达业务规则，例如“可以汇总项目邮件，但不要输出薪资数字”。模型在处理请求时理解并遵循这些规则。
结构化部分则用于支持的管理动作，例如某人能否接受一项工具审批。Host，也就是运行 Bot 的进程，要按实际操作者和当前授权检查这些动作。没有相应能力的人，即使看到了审批控件或自称管理员，也不能作出有效决定。
这里借用 RBAC 的“用户 → 角色 → 权限”组织方式，但两部分的保证不同：模型遵循行为策略，程序检查管理能力。 A 能查询邮件，不意味着能批准任意 Bash。管理检查也不是对所有业务写操作的一层通用拦截。
4. 自然语言规则无法限制进程已有的凭据
我们的邮件场景希望 Bot 通过 Shell 使用 Himalaya CLI，与邮箱集成保持解耦。这使凭据在哪里、Shell 以什么身份运行，成为另一个必须回答的问题。
如果同一进程能读取邮箱凭据，B 角色中的“禁止查询邮件”不会让操作系统拒绝一次邮箱读取。只限制专用邮件 Tool 也不够：Bash 或另一条执行路径可能接触同一资源。
需要更强保证时，可以缩小 Bot 的凭据范围、使用独立 Bot 或执行环境，或在覆盖相关执行路径的位置实施确定性的授权。AWS Gateway 只检查经过它的调用，执行环境也只隔离配置在边界之外的资源；任何一种方案都要看实际覆盖范围。AgentCore 策略说明、pi-chat 执行环境
第一版接受自然语言行为策略的灵活性，同时保留明确的管理检查。它不会把“模型通常遵守角色”变成“未授权用户无法访问邮箱”的保证。
同群多人：谁提问、谁提供背景、谁看到回复？
假设 B 没有邮件查询资格，但他的普通消息可以保存为群聊背景。后来 A @ Bot 查询邮件，B 不会因为出现在同一轮上下文中就取得 A 的权限。被引用的管理员也不是当前请求者。
Pi 生态中的独立聊天应用 pi-chat 展示了收集与触发分开的先例：它用用户 ID 与原生角色名单判断谁能触发任务，入站路径则先保存消息、后判断是否触发。保存的消息可能成为后续请求的背景。pi-chat 源码
Bot 可以查询三个只读目录：已配对的人及角色、已知的外部会话、在某个会话中观察到的已配对参与者。最后一个是观察记录，不能证明群里所有当前成员都已获准，也不能证明没有发言的人不存在。
还要考虑回复的受众：A 有权提问，不会让群里的回答只对 A 可见。 第一版不做完整成员同步或逐条受众授权。邮件内容应放在合适的私聊或受信任群中；角色目录不能替代平台的阅读权限。
用同一个邮件案例验收
设计是否落地，可以沿着五个行为检查：
- 未知用户 @ Bot：收到固定申请提示，没有启动模型工作。
- 管理员批准 A：A 收到重新提问通知，旧请求没有被重放。
- A 重新查询邮件：Bot 根据 A 的可信身份查询角色，并按策略处理。这验证该次行为，不证明所有命令都被强制授权。
- 角色发生变化：新查询返回新版本，旧结果保留原版本与时间。
- B 没有管理能力却尝试审批：Host 拒绝其决定。撤销配对后，下一次受限请求也在模型入口被拦住。
这五项分别检验准入、审核、模型行为、信息新鲜度和管理授权。分开检查，才能知道每一部分实际提供了什么保证。
常见问题
这是完整 RBAC 吗？ 角色组织参考 RBAC，但自然语言行为策略不等同于对所有工具和资源强制执行的 RBAC。
为什么不每次强制注入权限？ 我们保留逐消息身份，遇到受角色策略约束的新请求再查当前配置，减少目录复制。模型仍可能漏查。
只读查询 Tool 会授予权限吗？ 不会。它返回当前配置；角色修改和管理决定仍需有权操作者通过相应程序执行。