Holo4 这类计算机使用代理怎样划分工具权限

Holo4 这类计算机使用代理能在桌面、网页和移动端连续完成任务，真正难的不是“能不能点击”，而是“点击之前到底授予了什么权力”。如果浏览器、文件系统和 Shell 共用一个全量开关，模型一次错误判断就可能把读取资料、修改文件和发送请求混在同一条执行链里。

更稳妥的做法是把权限拆成四层：工具能力决定能调用什么，资源范围决定能碰什么，动作审批决定什么时候必须停下来问人，隔离运行环境负责兜底。Holo4 官方说明页可作为该类模型的背景资料：

官方地址：https://hcompany.ai/newsroom/holo4

最小权限不是把代理锁死，而是让它只拿到完成当前任务所需的工具、资源和动作权限；只读工作流可以自动化，高风险副作用必须有明确的确认门和可追溯记录。

权限不要只做成一个总开关

“允许计算机使用”只回答了能力是否存在，没有回答权限边界。一个整理项目资料的任务，可能需要打开网页和读取本地文档，却不需要发送邮件、删除文件或执行任意命令。把这些能力塞进同一个开关，后续就无法区分正常工作和越权动作。

可以先用下面四个问题给每个工具定边界：

• 工具能力：它是只读查询、文件写入、网页交互，还是能运行命令？
• 资源范围：允许哪些域名、目录、仓库、表或数据类型？
• 动作等级：哪些调用没有副作用，哪些调用会写入、发送、删除或改变外部状态？
• 运行环境：即使策略判断失误，进程还能影响到哪些真实资源？

第一层：按工具能力授予最小集合

工具清单应从任务倒推，而不是从模型能力倒推。网页资料整理通常只需要导航、读取页面和提取文本；文件归档可能增加指定目录的写权限；Shell 则应拆成命令白名单或专用函数，避免直接暴露一个可以执行任意字符串的入口。

// 只为“整理资料”任务打开必要能力，默认不提供删除和任意 Shell。
const toolPolicy = {
  browser: { enabled: true, mode: "read", origins: ["https://docs.example.com"] },
  filesystem: { enabled: true, mode: "read-write", roots: ["/workspace/inbox"] },
  shell: { enabled: false, commands: [] },
  mail: { enabled: false, actions: [] }
};

// 工具网关先查能力开关，再把请求交给资源和动作策略。
function canCall(toolName, requestedAction) {
  const rule = toolPolicy[toolName];
  return Boolean(rule?.enabled && rule.mode !== "disabled" &&
    (rule.actions ?? ["read"]).includes(requestedAction));
}

这里的重点不是字段名，而是“工具能力”和“具体动作”分开。即使开启了文件系统，也不代表允许删除；即使开启了浏览器，也不代表允许向任意站点提交表单。

第二层：把资源范围收窄到可解释的边界

同一个工具的风险，往往来自资源范围过大。浏览器至少要区分允许访问的 origin；文件系统要限制根目录，并拒绝通过路径拼接跳出根目录；Shell 要限制工作目录、命令集合、网络出口和执行时长。策略越能解释，后续审计越容易判断“为什么这次调用被允许”。

资源范围建议采用显式清单，而不是依赖模型自己遵守提示词。比如“读取资料”可以只挂载一个临时目录，访问文档站点可以只开放几个来源；需要写入时使用任务专属输出目录，避免把整个用户主目录作为工作区。

OpenAI 的 sandbox 文档把文件、命令、包和端口放在隔离执行环境中，并强调把控制面与执行面分开。对自建代理来说，这对应一个很实用的原则：模型可以提出工具调用，但真正能访问哪些资源，由外部策略网关和运行时边界决定。

第三层：只读动作自动放行，高风险动作进入确认门

权限判断不能只看工具名，还要看动作的副作用。打开网页、读取文本、列出目录通常属于低风险动作；保存文件、发送邮件、提交表单、删除记录、执行会改变系统状态的命令，则应进入确认流程。确认内容要包含目标资源、完整参数、预期影响和有效期，而不是只显示一个模糊的“是否继续”。

网站来源审批和单次动作确认也不是一回事。允许代理访问某个站点，只说明这个来源在范围内；它不等于自动同意购买、发送、删除等具体动作。确认门应该放在动作即将产生外部副作用的位置。

// 只读请求直接走策略；会产生外部副作用的动作必须停下来确认。
function decision(request) {
  const risky = new Set(["write", "send", "delete", "submit", "execute"]);

  // 先拒绝未声明的工具和资源，避免用“默认允许”扩大权限。
  if (!policyAllowsResource(request.tool, request.resource)) {
    return { effect: "deny", reason: "resource-out-of-scope" };
  }

  // 高风险动作不由模型自己确认，交给宿主应用展示给用户。
  if (risky.has(request.action)) {
    return { effect: "ask-user", expiresInSeconds: 120 };
  }
  return { effect: "allow", audit: true };
}

第四层：用隔离环境承接剩余风险

策略层做得再细，也不能假设模型永远正确。计算机使用代理会根据屏幕、网页内容和工具结果继续规划，外部内容可能诱导它改变目标。因此执行层仍然需要隔离：临时工作区、非生产账号、短时凭据、受限网络、资源配额和可终止进程都应该成为默认配置。

凭据不要放进提示词、任务文件或生成的文章中。需要访问外部服务时，可由宿主在运行时注入窄权限身份，并让代理只能调用经过封装的函数。任务完成、超时或用户拒绝后，立即撤销这次运行的令牌和工具绑定。

一份可落地的权限速查表

上线前可以用一张“动作—资源—审批—日志”矩阵逐项检查：每个工具是否有默认拒绝路径？每个写操作是否能说明影响对象？用户拒绝后代理是否会停止或改走只读方案？每次调用是否记录了工具名、参数摘要、策略决定、审批人和结果？这些问题比“模型是否足够聪明”更直接地决定系统是否可控。

常见误区

• 只限制提示词，不限制运行时：提示词是行为约束，不是文件系统、网络和进程权限。
• 把来源批准当成动作批准：能访问站点不等于能提交表单，能读目录不等于能删除文件。
• 给 Shell 一个全能入口：优先改成固定函数、白名单参数和临时工作区。
• 只记录成功结果：被拒绝、被用户取消和超时的调用同样需要审计，才能复盘代理为何反复尝试。

相关问题

计算机使用代理是否应该默认关闭 Shell？

如果任务不需要命令执行，应默认关闭。需要 Shell 时优先提供完成单一任务的专用函数，再按命令、目录、网络和时长逐层收窄。

用户确认能不能替代沙箱？

不能。确认只能覆盖已经被发现的高风险动作，沙箱和资源隔离负责限制未知错误、恶意页面内容和模型规划漂移造成的影响。

权限什么时候可以收回？

任务完成、用户拒绝、运行超时、身份切换或策略命中异常时都应收回。短时令牌和任务级工具绑定比长期全局权限更容易做到自动撤销。

总结一下，Holo4 这类计算机使用代理的权限设计应从“模型能做什么”改成“这个任务允许它在什么范围内做什么”。先按工具能力拆分，再限制资源范围，把写入和对外副作用放进确认门，最后用隔离环境、短时凭据和完整审计兜底，才能在保留自动化效率的同时控制失败成本。