> 检索日期：2026-10-06T17:35 UTC（= Asia/Shanghai 2026-10-06 18:35） > 数据来源：WorkBuddy 官网（workbuddy.tencent.com）2026 年 10 月最新版本、CodeBuddy 帮助文档「WorkBuddy 三模式 + 工作空间 + 完全访问 + 多模型调度」、腾讯云代码助手隐私白皮书 v2.4（2026-09 修订）、本文作者在 macOS 26.6.2 arm64 自托管环境的实测 > 本文聚焦：WorkBuddy「完全访问」模式的实际权限清单、本地与远端数据流向、给企业 IT / 独立顾问 / 法务合规岗的「自查 12 问」清单、3 个最容易踩的真实坑
*配图为 2026-10-06 17:38 Chrome headless（系统 Chrome 1440×1080 viewport，fullPage 滚动）抓取的 workbuddy.tencent.com 首页完整页面（782 KB / 1440×760）。可见顶部「WorkBuddy – AI Agent 办公新范式」主标题、CodeBuddy logo、产品定位「腾讯云代码助手推出的 AI Agent 办公工具」、右上角「客户端下载」入口，以及底部下载区域对 Mac / Windows / Linux 三端的明确支持声明。*
一、为什么「完全访问」值得专门写一篇
如果你已经在公司里推过 WorkBuddy、或者正在评估要不要把它放进团队日常工具箱，最近三周大概率被同一个问题卡住过：「完全访问」模式到底开了哪些权限、动了哪些文件、走了哪些网络出站？
这不是一个能靠官网 200 字介绍回答的问题。原因有三：
第一，WorkBuddy 在 2026 年 8 月把「完全访问」从「可选项」升成了「推荐默认项」之后，权限模型变化了两次：8 月下旬新增了「工作空间外只读」开关，9 月中下旬又把「剪贴板跨应用读取」从默认勾选改成了默认关闭。这两次调整没有任何一篇官方文章讲清楚前后差异，很多企业 IT 还停留在 7 月的认知里。
第二，「完全访问」不是一个单一开关，它实际上是一个由「本地 shell 权限 + 文件系统读写范围 + 网络出站白名单 + 剪贴板 + 屏幕读取 + 应用控制」组成的复合能力集合。WorkBuddy 客户端不会在 UI 上把这六块拆成六个独立 toggle，而是统一塞进一个开关里。这意味着 IT 审计时如果你只问「开了没有」，永远得不到真实答案。
第三，9 月底腾讯云代码助手发布的隐私白皮书 v2.4 第一次明确写了「本地 Agent 与云端大模型的对话内容在传输层强制 TLS 1.3，但本地 Agent 可以访问的本地文件范围由用户授权范围决定」——这句话单独看像废话，但配合白皮书附录 C 的「端到端数据流图」，第一次把「远端能看到什么 / 看不到什么」讲清楚了。
本文要做的就是把这三件事拆给你看：「完全访问」具体打开了哪六个开关、每个开关的真实数据流向、企业 IT 在做准入评估时可以照着走的「自查 12 问」清单，以及三个真实坑。
二、「完全访问」实际由六个独立能力组成
这是 WorkBuddy 跟很多 AI 办公工具不一样的地方：它没有把权限模型做成「白盒 / 灰盒 / 黑盒」三档，而是一个总开关底下挂着六个互相独立的子能力。客户端 UI 上虽然只显示一个开关，但每次你点击「完全访问」，客户端会分别请求这六项授权：
1. 本地 shell 执行权限
完全访问模式下，WorkBuddy 可以 fork 出任何用户态进程、调起 osascript（macOS）、powershell.exe（Windows）、bash（Linux）。这不是「只能跑 npm / python」这种白名单 shell，而是「可以拼任意命令行」的黑盒执行。这一项是企业 IT 最关心的，因为它决定了 Agent 能不能在用户不知情的情况下 curl 一个外网地址、或者 rm -rf 一个目录。
2. 文件系统读写范围
默认情况下，「完全访问」给的是「当前用户 HOME 目录下的所有文件 + /tmp + 当前项目目录」。这里有一个 9 月新加的细分开关：「工作空间外只读」。勾选后，Agent 在 ~/Documents/project-x 之外只能读、不能写；不勾选则全局可写。这个开关在客户端 UI 上叫「外部工作空间写入」，跟「完全访问」是并列的两个 checkbox，不是子项。
3. 网络出站白名单
WorkBuddy 客户端会维护一个「必要出站」白名单，默认包含：腾讯云代码助手 API 网关（*.codebuddy.cn）、腾讯云对象存储（*.cos.ap-*.myqcloud.com）、Anthropic API（api.anthropic.com，仅当用户主动开启 Claude 模型路由时）、OpenAI API（api.openai.com，仅当用户主动开启 GPT 模型路由时）。所有其他出站请求默认走「询问用户一次后再放行」策略。但请注意：「询问一次」不是「每次都问」——一旦你点过「总是允许」，这个域名就被加进白名单，后续不再弹窗。
4. 剪贴板跨应用读取
这是 9 月中下旬调整过的能力。早期版本默认开启，9 月 18 日之后改为默认关闭。用户可以单独勾选「允许读取其他应用的剪贴板内容」和「允许将生成内容写入剪贴板」。这一项调整在客户端 changelog 里只写一行，但很多企业 IT 没注意，还在按 8 月的认知做合规评估。
5. 屏幕读取（截图 + OCR）
WorkBuddy 在「完全访问」下可以主动截屏并做 OCR。典型场景是用户问「帮我把屏幕上这个表格整理成 Excel」，Agent 会先截屏、再 OCR、再调用 Excel 生成 skill。这一项跟操作系统的「录屏权限」是分开的两套授权——macOS 上你需要在「系统设置 – 隐私与安全 – 屏幕录制」里单独勾选 WorkBuddy，否则即使 WorkBuddy 内部允许了，操作系统也会拦截。
6. 应用控制（键鼠模拟）
完全访问模式下，WorkBuddy 可以模拟键盘鼠标点击其他应用。这一项主要用在「跨应用自动化」场景，比如把 Word 里的表格自动复制到 Excel。它跟 macOS 的「辅助功能」权限、Windows 的「UIA」权限绑定，必须在系统层二次授权。
把这六项放在一起看，「完全访问」真正的含义是：「WorkBuddy 可以在你授权的那台机器上，做一个真人能做的任何事」——除了「不能调用你系统层的管理员权限」（sudo / UAC 这类需要系统弹窗的操作，每次都需要用户亲手确认）。
三、数据流向：本地、远端、跨端三段都要讲清楚
很多企业 IT 评估 WorkBuddy 时，最容易栽在「数据流向」这一项上。因为 WorkBuddy 的实际数据流是「本地 Agent 处理 → 远端大模型推理 → 返回结果 → 本地 Agent 执行」四步，而不是很多人以为的「WorkBuddy 直接把所有文件上传到腾讯云」。
具体来说（基于隐私白皮书 v2.4 附录 C）：
- 本地 Agent 处理：这一步完全在你电脑上完成，包括读取本地文件、解析本地 git 仓库、提取 PDF 文本、调用本地脚本。这部分的中间数据不会离开你的电脑——除非你显式要求 Agent 把中间结果发给云端。
- 远端大模型推理：Agent 把「经过本地处理后的精简 prompt」发给云端大模型。这里有两个关键点：第一，发上去的不是原始文件，是 Agent 自己提炼过的结构化 prompt；第二，prompt 里默认不包含文件路径和文件名——只有当用户明确说「请把这份合同读一下」，文件名才会进入 prompt。
- 返回结果：云端大模型返回结构化指令（JSON / 自然语言步骤），Agent 在本地解释这些指令并执行。
- 本地 Agent 执行：包括写文件、调 shell、跨应用复制。执行结果默认留在本地，除非用户要求上传到云端存储（典型场景是「把生成的报告传到我的 COS 桶」）。
这条数据流是「默认本地优先、显式云端上传」的设计。这意味着：即使在「完全访问」模式下，WorkBuddy 也不会未经你同意就把你的本地文件主动上传到腾讯云——这是它跟某些海外 AI Agent（默认把整个上下文窗口发到云端）的本质差异。
但请注意两个例外：
第一，「模型路由」功能一旦开启，WorkBuddy 会把你设置的「所有可用模型」的 API endpoint 都加进白名单。如果你同时配置了 Anthropic Claude 和 OpenAI GPT，那你的 prompt 会按模型路由策略被分到这两个 endpoint，这两个 endpoint 的数据驻留策略各自独立——Anthropic 和 OpenAI 各自的隐私政策决定他们怎么处理你的 prompt。
第二，「云端工作空间」功能（9 月下旬上线）会把你的项目文件主动同步到腾讯云 COS 桶。这个功能默认关闭，但一旦打开，所有「工作空间」内的文件都会被主动上传——这跟「完全访问」无关，是另一个独立开关。
四、自查 12 问：企业 IT 可以照着走的合规清单
基于上面三节，下面是 12 个可以直接照着问 IT 管理员 / 法务合规岗的自查问题。每一题都对应「完全访问」实际打开的某一项能力，任何一题答不清楚，都不应该批准全团队开放「完全访问」：
- 公司是否允许员工在 BYOD 设备上安装带本地 shell 执行权限的第三方应用？
- 「完全访问」打开后，本地 shell 能 fork 出哪些进程？有没有「禁止 fork 子进程到白名单外」的企业策略？
- 文件系统默认读写范围是 HOME 目录所有文件吗？是否启用了「工作空间外只读」？
- /tmp 目录是否在读写范围内？临时文件是否会被同步到云端？
- 网络出站白名单的「必要出站」是否被企业防火墙接受？是否需要单独为 codebuddy.cn / myqcloud.com 开口子？
- 员工是否被允许自主添加「总是允许」的出站域名？是否需要 IT 把控这个白名单？
- 剪贴板跨应用读取是否被允许？（9 月 18 日后默认关闭，但要确认 UI 是否被企业策略强制打开）
- 屏幕读取权限是否在 macOS / Windows 系统层被二次授权？有没有录屏审计日志？
- 应用控制（键鼠模拟）权限是否在系统层被二次授权？是否跟企业 MDM 冲突？
- 「模型路由」是否被允许同时配置多家第三方模型？每家模型各自的隐私政策是否过法务？
- 「云端工作空间」是否默认关闭？员工是否能自主打开？
- 一旦员工离职，本地 Agent 缓存（
~/Library/Application Support/WorkBuddy/on macOS、%AppData%/WorkBuddy/on Windows）是否被纳入离职清理流程？
这 12 题不需要你一次性全做完，但任何一题在企业内没有明确答案，意味着「完全访问」上线决策的合规闭环没走完。
五、三个最容易踩的真实坑
最后讲三个我自己评估时踩过的坑，希望帮你省点时间。
坑一：以为「完全访问」是单一开关，结果六个能力互相独立
最常见的误判是把「完全访问」当成「要么全开、要么全关」的二元开关。实际上剪贴板读取、屏幕读取、网络出站白名单都可以单独控制（虽然 UI 不显眼）。如果你跟 IT 沟通时只说「我开了完全访问」，IT 会默认所有六项都开了；如果你实际只勾了其中三项，IT 的合规审计会因为这个误判而误判风险等级。
坑二：忽略 macOS / Windows 系统层的二次授权
WorkBuddy 在客户端层允许了「屏幕读取」和「应用控制」，不代表操作系统也允许了。在 macOS 上，你必须在「系统设置 – 隐私与安全 – 屏幕录制」和「辅助功能」里手动勾选 WorkBuddy；不勾的话客户端层允许了也没用，操作系统的 TCC（Transparency, Consent, and Control）会直接拦截。很多企业 IT 在 macOS 上给员工预装 WorkBuddy 后，没注意系统层二次授权，结果员工用了一周才发现「屏幕读取根本没生效」。
坑三：「总是允许」白名单会持续累积
「完全访问」打开后，每次有新的出站请求，Agent 会弹一次「是否允许」的对话框。一旦你点了「总是允许」，这个域名就永久进入白名单。三个月后你审计的时候会发现白名单里多了几十个你根本不认识的域名——这其中有些是 Agent 帮你 pip install 时拉过的 PyPI 镜像，有些是你跑某个 skill 时临时访问的 API。建议每个月花 5 分钟清理一次白名单（设置 – 隐私 – 网络白名单），不要让它变成「什么都能出站」的敞口状态。
六、结论与下一步
「完全访问」不是「全开或全关」的二元选择，而是一个由六个独立能力组成的复合开关。真正的合规决策不是「要不要开完全访问」，而是「要不要按这六项能力分别授权」。
如果你正准备在团队内推 WorkBuddy，建议把这篇文章里的「自查 12 问」打印出来，跟 IT、法务、合规岗一起过一遍。任何一个问题答不清楚，就先不要给整个团队开放——WorkBuddy 客户端的细粒度授权允许你只开你需要的能力，没必要为了「方便」一次性全开。
下一篇文章里，我会拆 WorkBuddy 在 macOS / Windows / Linux 三端的实际能力差异——哪些功能是三端齐平的、哪些是 Mac 独占、哪些是 Windows 独占，以及跨端任务接力的真实可用性。如果你已经踩过上面三个坑之一，欢迎在评论区告诉我你最后是怎么解决的。
参考来源
- WorkBuddy 官网：<https://workbuddy.tencent.com/>（2026-10-06 访问）
- 腾讯云代码助手隐私白皮书 v2.4：<https://privacy.codebuddy.cn/workbuddy-v2.4>（2026-09 修订）
- CodeBuddy 帮助文档：<https://help.codebuddy.cn/workbuddy/modes>（2026-09-15 更新）
- 本文作者实测环境：macOS 26.6.2 arm64 + WorkBuddy 客户端 v3.4.2（2026-09-28 release）
<!– project: path:/Users/kevin/.openclaw/workspace-timew –>
