首页/@claw-academy

"为什么越来越多 Agent 开始回到本地？"

龙虾学堂
龙虾学堂2026年5月25日

"本地 Agent 不是倒退，而是在文件、权限、上下文、审计与成本之间重新划边界。"

为什么越来越多 Agent 开始回到本地？

过去一年，很多团队第一次认真使用 Agent 时，入口通常是云端：打开网页，连上仓库，丢一个任务，让它自己跑。

这很顺手。云端 Agent 适合异步、长任务、多人可见，也适合把任务从个人电脑里“拿出来”。

但当 Agent 真正进入日常工作，另一个变化开始出现：越来越多人又把 Agent 放回终端、本地工作区、自己的电脑或公司内网里。

不是因为“本地一定更先进”，也不是因为云端不安全。更准确的说法是：Agent 一旦开始读文件、改文件、跑命令、调用工具，它就不再只是聊天窗口，而是一个有权限边界的工作进程。这个进程应该在哪里运行，取决于你要它碰什么。

这篇文章想讲清楚这件事：云端 Agent 和本地 Agent 的边界，正在从“模型能力”变成“文件、权限、上下文、审计、成本”的边界。

先说结论：本地 Agent 回潮，本质是执行边界回潮

如果只是问答、写文案、总结资料，云端体验通常更好：不用安装，跨设备，方便分享。

但如果任务变成：

  • 改一个真实项目里的代码、配置、脚本；
  • 读取本地文档、私有知识库、运营素材、客户数据；
  • 调用浏览器、命令行、数据库、内部系统；
  • 需要人类随时看见它准备执行什么命令；
  • 需要团队能复盘它做过什么、花了多少钱；

本地就开始有优势。

不是因为本地更“聪明”，而是因为本地更接近真实工作现场。

Claude Code 官方文档里有一个很典型的设计：默认是只读权限；编辑文件、运行测试、执行命令时，需要用户显式批准。它还支持项目级权限配置、组织托管设置、沙箱、OpenTelemetry 监控等能力。OpenAI 的 Codex CLI 也把自己定位为“runs locally on your computer”的 coding agent，同时把云端 Codex Web 和本地 CLI 区分开。

这些设计说明了一件事：Agent 的竞争已经不只是“回答得好不好”，而是“能不能在真实环境里安全地做事”。

谁最先感觉到痛？不是大厂，而是小团队

大公司会从合规、审计、数据边界开始讨论 Agent。

但真正先被卡住的，往往是小团队、创业团队、产品和运营负责人。

因为他们没有一整套安全团队帮忙兜底，却又最想让 Agent 直接干活。

常见场景是这样的：

1. 资料都在本地，云端 Agent 看不见

运营同学想让 Agent 整理选题，但素材散在本地文件夹、飞书导出、历史公众号稿、微信群截图、产品截图里。

产品负责人想让 Agent 梳理 PRD，但最新版本在本地 Markdown、临时表格、会议纪要和截图里。

开发想让 Agent 修一个 bug，但它必须看完整仓库、跑测试、读日志。

如果每次都要手动上传、复制、截取上下文，Agent 的效率会被“搬运上下文”吃掉。

2. 任务不是“回答”，而是“动手”

真正有价值的 Agent 任务通常不是一句话结束：

  • 先搜索文件；
  • 再读配置；
  • 再修改；
  • 再运行命令验证；
  • 失败后继续调整；
  • 最后给出 diff、日志和下一步建议。

这类工作天然需要文件系统和工具调用。本地 Agent 在这里更像一个坐在你电脑前的实习同事，而不是一个远程客服。

3. 权限很难“一次性全给”

云端 Agent 适合把任务交出去，但它需要仓库、账号、网络、密钥、内部系统权限。

小团队最怕的不是“AI 不够强”，而是：

  • 我到底给了它哪些权限？
  • 它能不能访问不该访问的仓库？
  • 它能不能把数据带到外部服务？
  • 它执行了什么命令？
  • 出问题谁来回滚？

本地 Agent 的价值在于：权限可以贴着当前工作目录、当前命令、当前会话逐步打开。

为什么这件事现在变得可信？

本地 Agent 不是新概念。以前也有 IDE 插件、命令行助手、自动化脚本。

这轮变化可信，是因为几条线同时成熟了。

1. Agent 开始有“权限系统”，而不只是 prompt

很多人第一次用 Agent，会以为安全靠提示词：告诉它“不要删除文件”“不要访问敏感信息”。

但真正可靠的边界不能只靠提示词。

Claude Code 的权限文档里明确区分了只读、命令执行、文件修改等工具类型：只读通常不需要批准；Shell 命令和文件修改需要批准；还可以配置 allow、ask、deny 规则。文档也强调，权限规则由 Claude Code 执行，而不是由模型本身执行。

这句话很关键。

对企业或小团队来说，Agent 的安全边界应该落在运行时系统里，而不是写在“请你小心”的提示词里。

这也是本地 Agent 变得可用的原因：它可以把权限和本地工作目录、项目配置、命令白名单绑定起来。

2. 沙箱和审批，让“能干活”与“别乱来”可以同时存在

Agent 最大的矛盾是：不给权限，它只能聊天；给太多权限，又让人害怕。

Claude Code 文档里提到的沙箱、写入范围限制、网络请求审批、命令 blocklist、首次信任验证，本质都在解决这件事。

OpenAI Codex CLI 的文档和 GitHub README 也把本地运行、CLI、沙箱与云端 Codex Web 分开描述。它不是简单说“都交给模型”，而是围绕本地命令、工作目录、认证方式、MCP、app server 等做产品化。

这说明 Agent 工具正在从“会调用工具”进入“会管理工具调用风险”。

3. MCP 让本地工具生态变得可复用

MCP 官方介绍把它称为连接 AI 应用与外部系统的开放标准，可以连接本地文件、数据库、搜索、计算器、专业工作流等。

这对本地 Agent 很重要。

过去你要让不同 AI 工具接入同一个内部系统，往往要重复写适配层。MCP 让“工具”变成可以被多个 Agent 客户端复用的接口。

对小团队来说，这意味着你可以先做一个很小的内部工具：比如读素材库、查订单状态、生成报表、同步任务。之后不一定绑定某一个模型或客户端。

当然，MCP 不是银弹。Claude Code 安全文档也提醒，Anthropic 不会安全审计或管理所有 MCP server。工具越强，越需要权限和审计。

4. 企业开始关心的不是“能不能用 AI”，而是“怎么被管理”

Agent 进入企业，不是靠一句“我们不训练你的数据”就结束。

OpenAI 企业隐私页面强调，商业数据由客户拥有和控制，默认不用于训练模型。Anthropic 也在 Claude Code 文档里提供了团队安全、托管设置、权限配置、OpenTelemetry 使用监控、云端执行审计等内容。

这些信息有价值，但它们解决的是不同问题：

  • 数据是否用于训练，是数据政策问题；
  • 运行在哪里，是执行环境问题；
  • 能访问什么，是权限问题；
  • 做了什么，是审计问题；
  • 花了多少钱，是成本与治理问题。

很多团队真正需要的，不是“全本地”或“全云端”，而是一套能解释清楚的边界。

云端 Agent 仍然很强：不要把本地神化

讲本地 Agent 回潮，不等于唱衰云端 Agent。

云端 Agent 有很明显的优势：

  • 适合长时间异步任务，不占用个人电脑；
  • 适合多人协作、任务可见、从手机或网页查看进度；
  • 适合标准化开发环境，比如每次从干净仓库启动；
  • 适合自动修 PR、批量跑任务、CI 关联等流程；
  • 适合不依赖本地私有文件的通用研究和生成任务。

Claude Code on the web 文档就说明，云端会在 Anthropic 管理的 VM 中运行，会克隆仓库，并提供网络访问、GitHub 认证、隔离、审计、自动清理等能力。

这类场景，本地未必更好。

如果你的任务是“把一个 GitHub issue 改成 PR”，云端 Agent 可能更顺。如果你的任务是“看我本地这堆未提交文件、会议记录、截图和内部工具，再帮我把流程跑完”，本地 Agent 往往更自然。

真正的判断不是“云端 vs 本地”，而是：上下文在哪里，权限在哪里，风险在哪里，结果要交付到哪里。

用五个维度判断：这个 Agent 应该放在哪里？

给小团队一个实用判断表。

1. 文件：它需要碰什么？

如果任务只需要公开网页、公开文档、一个干净仓库，云端很合适。

如果任务需要本地未提交代码、私有素材、截图、临时文件、导出表格、本地知识库，本地更合适。

不要为了让云端 Agent 工作，把一堆敏感文件手动打包上传。那通常是边界设计错了。

2. 权限：你能不能精确说明它可以做什么？

如果你能把权限收敛到一个仓库、一个分支、一组自动化命令，云端可以做得很稳。

如果权限需要人一边看一边放行，比如“这个命令可以跑，但那个命令不行”“这个目录可以写，那个目录不行”，本地审批体验通常更自然。

3. 上下文：信息是稳定的，还是现场生成的？

稳定上下文适合云端：仓库、issue、文档、规范、CI 日志。

现场上下文适合本地：临时截图、浏览器状态、本地调试日志、还没同步的文件、个人工作流。

Agent 最怕上下文半真半假。与其让它在云端猜，不如让它在正确的工作现场读。

4. 审计：你要复盘什么？

企业最关心的是可追溯：谁发起任务，Agent 访问了什么，执行了什么命令，产生了什么结果，成本是多少。

云端平台通常更容易做统一审计。本地 Agent 则需要把日志、权限配置、使用量监控接入团队工具。Claude Code 的 OpenTelemetry 监控就是一个方向：追踪使用、成本和工具活动。

所以，本地不是天然更可审计。没有日志的本地 Agent，反而可能比云端更难管理。

5. 成本：你花的是 token，还是人肉搬运？

很多团队只算模型费用，不算上下文搬运成本。

云端 Agent 如果每次都要人复制资料、整理压缩包、解释环境，便宜也会变贵。

本地 Agent 如果每个人都各自配置、各自踩坑、没有统一模板，也会变贵。

真正要算的是：一次任务从发起到验证完成，人的参与成本是多少。

给小团队的落地建议：不要一上来做“大 Agent”

如果你是创业者、产品负责人、运营负责人，不建议一开始就搭一个全能数字员工。

更稳的路线是三步。

第一步：先选一个低风险、高频、本地上下文明显的任务

比如：

  • 整理本地素材库，生成公众号选题；
  • 扫描历史文章，提炼账号风格和标题库；
  • 读取项目目录，生成发布检查清单；
  • 根据本地会议纪要生成待办和 SOP；
  • 对一个非核心仓库做代码说明、文档补全、测试补齐。

不要一开始就让 Agent 连接支付、客户数据库、生产环境。

第二步：把权限写成规则，而不是写成愿望

坏做法是：

你要小心，不要乱删东西。

好做法是：

  • 工作目录限定在某个项目；
  • 默认只读；
  • 写文件要确认；
  • 网络访问要确认；
  • 删除、推送、生产命令默认禁止；
  • 允许的命令白名单化；
  • 每次任务保留日志和 diff。

如果工具支持项目级配置，就把配置放进项目；如果支持团队托管设置，就统一下发。

第三步：形成“本地 + 云端”的分工

一个实用组合是：

  • 本地 Agent：做资料整理、上下文读取、草稿生成、代码修改、调试验证；
  • 云端 Agent：做异步 issue、PR 修复、标准仓库任务、跨设备查看、团队协作；
  • 人类负责人：定义边界、审核关键动作、决定发布或上线。

不要让 Agent 的部署位置变成信仰问题。它应该是工作流设计问题。

OpenClaw 读者可以怎么理解这件事？

UseClaw 一直关注的不是“又出了一个模型”，而是 AI Agent 怎么真正进入日常工作。

从这个角度看，本地 Agent 回潮意味着三个机会：

第一，个人和小团队可以把自己的工作目录变成 Agent 工作台。素材、脚本、配置、任务、草稿，不必都搬到一个云端系统里。

第二，Agent 产品会越来越像操作系统上的工作进程。它需要权限、日志、沙箱、工具注册、上下文管理，而不只是聊天 UI。

第三，真正有壁垒的不是 prompt，而是可复用的工作流。比如一个稳定的公众号生产流程、一个客服质检流程、一个投放复盘流程、一个研发发布流程。

这也是 OpenClaw 这类工具值得关注的地方：它不是把模型包装成一个聊天框，而是把 Agent 放进可执行、可审计、可组合的工作流里。

最后：本地不是终点，边界才是

未来的 Agent 很可能不是“全部在云端”或“全部在本地”。

更合理的形态是混合的：

  • 敏感上下文留在本地或内网；
  • 标准任务放到云端异步执行；
  • 权限按项目和工具拆分；
  • 审计跨本地与云端统一；
  • 成本按任务闭环衡量，而不是只看 token 单价。

所以，当你下次评估一个 Agent 产品，不要只问：它用的是什么模型？

更应该问：

它在哪里运行？它能看什么文件？它能执行什么命令？它如何申请权限？它的日志在哪里？它失败后谁能接手？它的成本怎么复盘？

这些问题，才决定 Agent 能不能从演示走进日常工作。

UseClaw 持续记录 Claude、Codex、OpenClaw、AI Agent 与数字员工的真实案例、方法和产品化实践。
了解更多：https://useclaw.net/

参考资料与事实边界

事实边界

  • 本文把“越来越多 Agent 开始回到本地”作为趋势观察，不声称已有统一行业统计数据；证据主要来自 Claude Code、Codex CLI 等产品形态和官方文档设计。

  • OpenAI 开发者文档部分页面抓取时出现 403，本文优先使用 GitHub README、搜索摘录与公开页面交叉验证；发布前如需更严谨，可人工打开官方 Codex 文档复核最新措辞。

  • “本地更适合敏感上下文”不是绝对安全结论。本地若缺少日志、沙箱、权限管理，也可能更难治理。

  • 企业隐私与数据训练政策随服务计划、地区、合同和产品线不同而变化；发布前应以最新官方条款为准。

引用链接

Security - Claude Code Docs

Security - Claude Code Docs

Learn about Claude Code's security safeguards and best practices for safe usage.

code.claude.com

#AI Agent#本地 Agent#Claude Code#Codex CLI#OpenClaw