最近组里又在聊 share skill。我越想越觉得，小龙虾这类 local agent 很有价值，但它未必是公司级 Agent 系统的最终形态。
这句话如果只说一半，容易被误解成“本地 Agent 不重要”。我不是这个意思。对个人用户来说，本地 Agent 的优势非常明显。我的文件在本机，我的浏览器登录态在本机，我的开发环境在本机，我的很多真实 context 也只在本机。Manus 这样的 cloud agent 再强，也拿不到这些东西。它后来推出 My Computer，本质上就是承认 cloud sandbox 有本地上下文缺口。
但一旦把场景换成公司，这个判断就要反过来看。
公司的电脑名义上在员工手里，但资产、权限、知识和审计链路并不在员工手里。Wiki 在云上，Slack 在云上，GitHub 在云上，SharePoint 在云上，数据仓库在云上，CRM、工单、日程、邮件也大多在云上。员工只是被授权访问这些系统，不是这些系统的所有者。
所以企业 Agent 的真正问题，不是“云端好还是本地好”。
更正确的问题是：组织上下文在哪里，权限在哪里，审计在哪里，执行在哪里。
个人的 local 优势，到了公司会变成治理问题
个人使用 local agent 的优势很直接：它离真实工作现场最近。
你让它改一个本地项目，它能读文件、跑测试、看日志。你让它整理一堆桌面文件，它不用申请复杂权限。你让它操作浏览器，它可以借用你已有的登录态。对个人来说，这种“贴身”就是生产力。
但公司看同一件事，视角会完全不同。
本地 Agent 读了哪些文件？有没有读到不该读的目录？它调用了哪个 MCP？这个 MCP 是谁写的？有没有把数据发到外部网络？它生成的结果有没有被评测？失败日志在哪里？离职以后这些 skill 和上下文归谁？
个人觉得便利的地方，企业会看成治理盲区。
这不是保守，而是组织的基本责任。公司不是一个放大的个人。公司里存在团队边界、密级边界、地区边界、合规边界、系统边界、岗位边界。Agent 越能跨系统行动，越不能只靠个人本地自由配置。
云端不是因为更先进，而是因为更接近组织上下文
很多人讨论 cloud agent 时，会默认它和“模型更强”“算力更大”“异步执行”绑定在一起。这些当然重要，但不是企业场景里最本质的部分。
企业 cloud agent 真正的优势，是它天然更靠近组织系统。
公司里的上下文越来越少存在于某台电脑里，而是存在于一组 SaaS 和平台中：代码在 GitHub，文档在 SharePoint 或 Google Drive，沟通在 Slack 或 Teams，项目在 Jira，客户在 CRM，数据在 warehouse，指标在 BI，知识在 wiki，流程在工单系统。
如果 Agent 要回答一个真实业务问题，它需要穿过这些系统。它不是读一个本地文件就够了。它要知道这个人有没有权限，某个文档是不是最新，某个数据指标有没有认证，某个 Slack 讨论是不是只在小范围频道里，某个代码仓库是不是内部可见。
这也是为什么 OpenAI Company Knowledge、Microsoft 365 Copilot Agent Builder、GitHub Copilot Spaces 都在强调同一件事：尊重已有权限模型。OpenAI 说 Company Knowledge 只访问用户已经有权查看的内容；Microsoft 写到 agents respect existing Microsoft 365 permissions；GitHub Spaces 也说 follows the same role/visibility model。
这些表述背后是同一个判断：企业 Agent 的产品价值，不只是能不能把答案生成出来，而是能不能在组织边界内生成答案。
Local Agent 在企业里的新角色：受管数据面
如果只看到上面这一点，很容易得出另一个过头结论：企业都应该用 cloud agent，本地 agent 没价值。
这也不对。
Manus 的 My Computer 很有代表性。它原来完全活在 cloud sandbox 里，但后来仍然要进入用户桌面。原因不是 cloud sandbox 不好，而是很多真实工作就是发生在本地：项目文件、开发环境、桌面应用、本地算力、已登录浏览器、内网资源。
企业也是一样。开发者的 IDE 和 terminal 在本地，很多内网工具只能从公司网络访问，某些系统有 IP 白名单，某些文件不允许上传到 SaaS，某些操作必须在受控终端执行。
所以 local agent 不会消失。它会改变角色。
它不再应该是一个完全自治的个人外挂，而应该变成企业 Agent 系统里的受管数据面。它负责进入端点，云端负责下发策略。它可以读取本地，但要遵守本地目录范围。它可以调用工具，但工具来自企业 registry。它可以执行任务，但关键动作要审批。它可以产生结果，但 trace、日志、产物和 eval 要回传。
Cloud 是控制面，Local 是执行面之一。
控制面决定谁能做什么，能连什么，能读什么，结果如何评测，风险如何审计。执行面负责在具体环境里完成任务，包括云端浏览器、Slack bot、IDE 插件、本地 CLI、桌面 Agent、私有网络 runner。
Share skill 的重点，也要从“共享文件”升级成“共享能力供应链”
这个判断会改变 share skill 的 big picture。
如果 Agent 是个人工具，那么 share skill 很容易被理解成：我写了一个好用的 prompt 或 markdown，发给你，你放到本地目录里用。
这在早期很有价值，因为启动成本低。团队可以快速把经验沉淀下来，也能形成示范效应。
但公司级 skill sharing 不能停在这里。
Anthropic 对 Agent Skills 的定义是 instructions、scripts、resources 的组合，而且 Agent 可以动态加载。它还提醒用户只安装可信来源的 skill，低信任来源要审计。这其实已经说明 Skill 不只是文档，而是软件资产。
既然是软件资产，就不能只靠群文件传播。它需要 owner、版本、依赖、适用范围、测试样例、评测分数、变更记录、审批、回滚。
OpenAI 关于 skill eval 的文章也给了一个重要信号：真正成熟的 Skill，不应该只靠“感觉更好用”。它应该有 prompt、captured run、trace、artifacts、checks、score。也就是说，Skill 要能被回归测试。
这是个人经验和组织能力的分水岭。
个人经验可以靠体感。组织能力必须靠可复现证据。
企业 AI-native org 的三层结构
把这些放在一起，我更倾向于把企业内部 Agent 系统设计成三层。
第一层是 local agent。它负责个人实践、私有上下文、本地工具、桌面文件、IDE、终端、浏览器登录态和快速试验。它是创新的前线，也是 Skill 的生产入口。
第二层是团队 skill repo。这里放的不是散乱 prompt，而是版本化的 skills、scripts、references、examples、evals、metadata。每个 Skill 要有 owner，有适用场景，有验收标准，有变更记录，有失败案例。它应该像代码一样走 review，而不是像资料一样到处转发。
第三层是企业治理面。这里负责 registry、权限、MCP allowlist、审计、eval dashboard、发布、回滚、数据边界和生命周期管理。它解决的是组织级问题：哪些能力可以被发现，哪些工具可以被调用，哪些数据不能出界，哪些动作需要审批，哪些 skill 已经过期。
这三层都少不了。
只有 local agent，会形成个人英雄主义和治理盲区。只有 cloud agent，会丢失端点上下文和真实执行力。只有 skill 文件，会变成高级 prompt 仓库，很难形成稳定的组织能力。
真正要画的四条线
所以，我不太想把这个问题继续表述成“小龙虾这样的 local agent 是不是公司里的最佳形式”。这个问法容易让人陷入工具对工具的比较。
更好的问法是四条线。
第一，上下文线。哪些 context 属于个人工作现场，哪些属于组织系统？个人现场可以本地优先，组织系统应该云端优先。
第二，权限线。哪些权限来自用户本人，哪些权限来自 Agent 专属身份？用户能看，不代表 Agent 就应该自动用。企业需要 agent-specific scope。
第三，审计线。哪些动作必须留痕，哪些产物必须可回放，哪些失败必须进入 eval dataset？只要涉及组织资产，就不能只存在本机日志里。
第四，执行线。哪些任务需要云端异步执行，哪些任务必须在本地、内网或私有运行时执行？执行位置可以多样，但控制规则要统一。
这四条线比“云端 vs 本地”更重要。
我的结论
如果一个团队正在推进 share skill，我会建议不要一上来就追求大而全的企业平台，也不要停留在本地目录同步。
更务实的路径是：先让 local agent 成为个人工作流试验场。让真正高频使用 AI 的人，把自己的流程跑通，把有效方法沉淀成 Skill。然后把高频 Skill 提升到团队 repo，要求每个 Skill 至少包含说明、脚本、示例、适用边界和最小 eval。最后再接企业治理面，把可复用 Skill 纳入 registry，把 MCP server 纳入 allowlist，把运行 trace 和 eval 接起来，把版本发布和回滚建立起来。
这条路不性感，但更像组织能力。
AI-native org 不是每个人都装一个更强的 Agent。
AI-native org 是组织能把自己的隐性知识、判断标准、工具边界和执行流程，持续封装成 Agent 可调用、可验证、可审计、可演化的能力。
本地 Agent 是很好的起点。云端控制面是组织化的必经之路。真正的分水岭，不在云端和本地之间，而在个人效率和组织能力之间。