--- author: OOMOL author_url: https://oomol.com/zh-cn/about/ datePublished: 2026-10-14 title: 你的 AI 助手需要多少权限，才能替你工作？ description: 从近期个人 Agent 的权限争议出发，理解账号授权、可执行操作和结果接收人的区别，并用 OOMOL 与 OpenConnector 为助手建立清楚的访问边界。 lang: zh-CN canonical_url: https://oomol.com/zh-cn/blog/ai-assistant-access/ markdown_url: https://oomol.com/zh-cn/blog/ai-assistant-access.md --- ![手控制信息流中的门闸，邮件与待发送消息表现 AI 的权限边界](/blog/ai-assistant-access/zh-cn-cover.webp) *AI 生成的编辑插画：读取信息与发送消息，分别授权。* 让 AI 帮你整理邮件、准备会议、跟进工作，听起来已经很自然。真正让人犹豫的，是点击授权按钮的那一刻：它能看到多少信息？能代表你做什么？这些权限以后还能收回来吗？ 最近的一场讨论，把这些问题摆到了台面上。[Business Insider 在 10 月 9 日刊登的采访](https://www.businessinsider.com/personal-ai-agent-grok-bot-posted-bank-details-company-slack-2026-10)中，XMTP Labs CEO Shane Mac 称，他的个人财务 Agent 将报告发到了公司 Slack。文章是经编辑的当事人口述，并非独立技术审计。 这篇采访随后被[转发到 Reddit 的 r/technology](https://www.reddit.com/r/technology/comments/1x1ysae/my_personal_ai_agent_posted_my_bank_details_on/)。讨论里，有人反对让 AI 接触敏感信息，也有人追问个人账号和工作账号为什么会混在一起。这些反应呈现了一个具体的顾虑：当助手同时能读取信息和发送消息时，用户怎样掌握信息的去向？ 10 月 12 日，[CNA 发布的 TikTok 视频](https://www.tiktok.com/@channelnewsasia/video/7695633148977204488)也讨论了用户是否给 AI Agent 过多权限。根据视频说明，相关发言关注的是用户能否理解自己授予的访问权。 这些内容不能证明每个 Agent 都会出问题，却说明权限已经进入公众对个人助手的讨论。对于想认真使用 AI 的人，授权应该跟着任务走。 ## 同一个邮箱，整理和发送需要不同的权限 假设你给助手一个任务：每天早上找出需要回复的邮件，列出重点，并准备几份回复建议。 完成这件事，需要搜索和读取邮件。回复建议可以先显示在对话中，由你检查。自动发送邮件、删除邮件、修改转发设置，都应该是另外的授权决定。 如果一开始就开放所有操作，助手得到的能力会超出这个任务。以后你调整提示词，账号的实际访问范围也未必随之改变。 可以先把任务拆成三个问题： - **可以读取什么？** 哪个账号、哪段时间、哪些材料？ - **可以执行什么？** 只做搜索和读取，还是也允许发送、修改、删除？ - **结果交给谁？** 显示在当前对话，还是发到一个明确的个人收件地址？ 这三件事需要分别处理。源应用的授权决定可访问的数据，连接层可以限制可调用的操作，助手的工作流程还要确定参数和结果接收人。 ![授权需要分别决定读取什么、执行什么以及把结果交给谁；源应用、连接层和助手流程各自承担不同控制](/blog/ai-assistant-access/zh-cn-permission-decisions.webp) *三个层面需要分别配置。图中是任务设计建议，不代表一个开关可以完成全部限制。* ## “只读”也需要清楚的信息去向 只读权限很适合第一阶段的助手：先整理信息，让人检查结果，再逐步增加操作能力。 但读取本身也会把信息带入助手的处理过程。即使助手不能修改源数据，如果另一个工具允许它发送消息，读到的信息仍可能被带到其他地方。 因此，一个个人晨间简报，可以先直接显示在你的私人对话里。团队简报则应该使用团队认可的数据来源和接收位置。个人财务、家庭日程和公司消息，值得分别安排连接与输出渠道。 对于发送消息的流程，还应明确账号和接收目标，尽量使用稳定的目标标识，并在需要时显示最终内容供用户确认。相似的群名、联系人名和账号标签，都不适合成为唯一判断依据。 这是工作流程需要落实的设计。允许调用“发送消息”，并不自动意味着系统已经判断了每一份内容是否适合每一位接收人。 ## 给助手一组可以解释的能力 在 OOMOL 中，可以把这些决定落实到账号连接和接口调用范围上。[权限控制文档](https://oomol.com/zh-cn/docs/access-control/)将 Provider 授权范围、连接访问权和允许调用的操作分别说明。 例如，邮件整理助手可以使用一个只允许搜索和读取邮件的连接。需要代表你发信时，再为发送任务配置相应能力。同一个账号也可以创建多个连接，用于不同的操作范围和成员访问范围。 具体能选择哪些授权范围，取决于源服务的支持；能限制哪些操作，也要核对当前连接提供的接口。记录级别的可见范围仍受源应用权限和请求参数影响。 OOMOL 的自定义接口限制还有一个容易忽略的细节：它会停用 Proxy 和动态 `call_tool` 入口。这样，调用只能落到显式允许的操作上，避免另一个通用入口超出已经勾选的范围。这项行为来自上述权限文档，配置时可以一并检查。 如果团队需要自己管理连接服务，[OpenConnector](https://openconnector.io/)提供开源、自部署的路径。它让团队在自己的环境中管理连接凭据、操作策略和运行记录，再通过 MCP 或 HTTP 等入口向助手提供应用操作。[自部署指南](https://oomol.com/zh-cn/docs/openconnector-self-hosting/)说明了运行端鉴权、允许和禁止的操作，以及脱敏运行记录的配置。 这些能力帮助团队建立和检查访问边界。返回给助手的业务数据，仍需要按敏感信息处理；消息接收人、内容检查和执行确认，也需要在助手或应用的工作流程中落实。 ## 从一个小而有用的任务开始授权 第一版助手可以只做一件事：读取今天的会议和相关邮件，把需要你注意的事项放到私人对话里。 等你确认它选对了账号、找对了材料、能标明来源，再考虑增加创建待办或发送消息的能力。每增加一项操作，都应该能回答：它服务于哪个任务，作用于哪个账号，结果会到哪里？ 需要暂停时，也应知道该收回什么。断开账号连接、撤销调用凭据和取消定时任务，分别对应不同的控制点；已经发送出去的信息不会因此自动消失。 想开始，可以在 [OOMOL Connections](https://console.oomol.com/connections) 配置一个任务所需的连接，按[权限控制指南](https://oomol.com/zh-cn/docs/access-control/)收窄允许的操作，再交给你的助手一个明确请求： > 帮我整理今天需要关注的邮件，只搜索和读取，不发送或删除。把结果显示在当前对话里，并保留原邮件链接。 当助手的能力与任务对应起来，授权会更容易理解，后续增加能力也更有依据。