夜雨聆风
由于 Coding Agent 的成功，各大 AI 公司都希望把编码工具做一些改动，使它适合普通员工办公。这样企业内除了开发者，其他员工也可以拥有一个真正"能干活"的 AI 助手。这一潮流随着鹅厂的下场，狂推 WorkBuddy 达到了一个新的顶峰。
这些"Buddy"配置大量 Skill、能生成并执行代码、访问本地文件和外部服务，能力比被禁锢在"缸中"的 Chatbot 类要强很多。想要把企业内 Token 消耗大户从开发者扩展到所有人，这是厂商们的愿望。
作为企业客户来说，在考虑给员工规模配置各种 Buddy 之前，需要考虑得更多一点：
当一个具备高权限、能自主行动的 AI 助手被安装到员工的工作电脑上时，我们如何确保它的行为始终处于可控范围？ 员工是否有足够的信息判断 AI 的每一次操作是否安全？ 版本更新、Skill 管理、审计追溯又该如何统一进行？ 更进一步，员工与 AI 之间那些真实发生的交互——他们如何提问、如何修改、如何拒绝、如何补充上下文——这些过程数据最终会沉淀在哪里？它们能否成为企业持续优化 AI、沉淀业务知识的宝贵资产？
后面这个问题比前面其实更关键。因为 AI 产品、框架、模型、形态还在不断城头变幻大王旗，你方唱罢我登场。但是企业真正难以被复制的，是用户与 AI 交互过程中产生的、带有强烈业务语境的意图轨迹与偏好数据。
为什么企业应用最终选择了 B/S？
给大量员工的电脑上多安装一个客户端软件，是一件难度较高的事情，涉及安全和管理。
可以先回顾一下为什么在企业应用领域，B/S（浏览器/服务器）最终取代了 C/S（客户端/服务器），成为主流形态。
早期的企业软件大都采用 C/S 架构，后来问题逐渐暴露：部署和升级成本高、版本碎片化严重、权限和审计难以统一、数据容易分散在终端。B/S 模式用浏览器作为统一入口，把复杂逻辑和数据放在服务端，换来了集中管控、统一升级、完整审计和数据天然回流的能力。这使得通过 Web 浏览器的 B/S 架构成为企业应用的主流。
这点和移动设备上的 App 有本质不同。大量移动设备上的 App，数据归属、风险承受和决策主体是同一人，用户可以自己权衡便利与风险。但是，很多企业对员工在移动设备上使用企业 APP 也设置了相当多规则和限制。
Agent 客户端与传统软件是不一样的物种
传统软件的功能边界相对固定，输入输出大体可预测，权限模型也经过长期打磨。当要安装到员工电脑前，也要进行复杂的安全评估。这是因为电脑上有大量属于公司的数据，而且一些电脑加入域控，具有较高权限能够访问公司内部其他资源。
那么一个具有自主智能、可以生成任意代码和脚本、可以执行工具调用、访问本地资源的客户端，要安装到员工电脑上，需要进行的评估要更加慎重。它和传统的功能单一的客户端应用是不一样的物种，它的行为和能力边界是不可预测的。
很多 Agent 会强调 HITL（Human in the Loop），在进行某些操作之前需要用户审批。但是 Agent 的目标是"自主完成任务"，它的能力会随着模型和工具的变化而增强，行为路径也更难以穷尽。在这种情况下，如果把"操作是否安全"的最终判断完全交给员工，其实是在要求他们先成为安全专家——而这既不现实，也不公平。
就像自动驾驶系统在复杂路况下突然把方向盘交还给司机，看起来给了人控制权，实际上是把系统设计的边界问题转嫁给了最不适合即时决策的人。
浏览器经过几十年的安全演进，本身就是一个天然的沙箱。它为不可信代码的执行划定了相对清晰的边界，也让统一的权限策略、操作审计和数据回流变得更容易实现。统一部署、集中升级、按角色精细授权、完整的操作日志……这些要求通过 Web 应用可以比较低成本地实现。
Coding Agent 的成功，并不意味着它适合所有员工
再扩展开一点：Coding Agent 的形态并不一定适合其他员工。为程序员准备的产品形态，并不一定适合大部分的其他用户。
Coding Agent 之所以能够成功，有一个重要原因是它获得了很高的权限——它能访问代码库、执行本地命令、使用浏览器等等。而之所以这种操作相对安全，是因为开发者本身对"安全"和 Agent 行为的理解要超越其他员工。
再次，代码数据其实没有那么敏感。开发者编写的代码大部分是系统的一部分，而且一般都并非关键业务系统，这些代码通常也不包含公司运营的核心业务数据。哪怕泄露，造成的危害也相对有限。还有，Coding Agent 功能其实相对单一，只是为开发而准备。用户是专业的用户，他们通常可以对系统进行大量的配置使 Agent 用起来更顺手。
但是给普通员工同样的 Coding Agent，事情就完全不同。Agent 访问的目录可能包含有隐私的文档，它可以通过系统访问 CRM、财务或客户数据。一旦 Agent 越权或被提示注入利用，造成的危害会比 Coding Agent 大得多。普通员工既没有开发者那样的安全判断能力，也没有相应的技术直觉去识别异常行为。
另外，普通员工要求系统是开箱即用，如果让他们去做大量的配置，安装各种 Skill，显然会极大提高使用门槛。因此，把为开发者验证过的高权限本地 Agent 形态，是无法直接平移到普通员工的。
真正的关键：交互过程数据归谁？
即便安全与管理的问题都能通过额外的管控手段逐步解决，还有一个更根本的问题值得认真对待：员工与 AI 之间那些真实发生的交互过程，最终会沉淀在哪里？
模型会快速迭代，框架会不断更替，客户端形态也会你方唱罢我登场。真正难以被竞争对手快速复制的，是员工与 Agent 的交互数据——这些交互数据带着丰富的业务语境、意图轨迹、习惯用语、拒绝原因和长期偏好。
它远不止是"聊天记录"。
每一次员工提出需求、如何一步步澄清、如何修改 Agent 的输出、在哪些地方表示不满或直接重写、长期形成的沟通习惯与决策偏好，都在真实刻画这家企业的工作方式与隐性知识。这些数据可以被深度挖掘：发现高频但未被正式文档记录的业务场景、识别流程中的摩擦点、捕捉不同角色的真实诉求优先级，甚至提前洞察新的业务机会。
更重要的是，这些交互过程本身就是 Agent 未来进化最宝贵的训练数据。
它很像具身智能里机器人的真实世界交互数据。机器人在实验室里学到的动作可以迁移，但真正让它适应复杂环境、形成稳健策略的，是大量真实场景下的试错、反馈与纠正。同理，通用大模型可以提供基础能力，但让一个企业级 Agent 真正"懂这家公司"、越用越准、越用越贴合业务习惯的，正是员工与它在真实工作中产生的交互轨迹。
如果这些数据长期留在员工本地或外部服务中，企业得到的可能只是阶段性的效率提升，而不是可以持续复利的资产。反过来，当交互过程被有效采集并沉淀在企业可控的环境中时，它就能不断反哺模型对齐、优化 Agent 策略、沉淀组织知识，形成"越用越懂自己"的飞轮。
这种积累是缓慢的，却也是最难被外部获取的。模型可以采购，Skill 可以借鉴，但"你们自己团队与 AI 协作时产生的意图轨迹与偏好信号"，几乎无法从外部复制。
反过来，如果交互数据长期游离在企业掌控之外，那么无论本地客户端做得多强大，企业得到的更多是工具的短期红利，而不是属于自己的长期护城河。
怎么做到既安全能力又强
Agent 之所以"能干活"，除了模型越来越聪明以外，还在于它拥有操作电脑的权限——读文件、写文件、执行命令、调用浏览器、访问内部系统。权限越大，能力越强，但是风险也越高。这是目前所有高能力 Agent 必须面对的根本矛盾。
目前业界大致走了三条路：
第一条路：沙箱内运行代码和脚本
给 Agent 一个隔离的代码执行环境，所有代码和操作都在沙箱里完成。这是相对稳妥的做法，安全边界清晰。但需要解决这个沙箱如何访问用户的工作"上下文"，例如读写工作文件、连接内部系统等。一般这个沙箱是一个容器或者一台虚拟机，并不完全是一台电脑。这是目前大多数 Agent 的选择。
第二条路：给 Agent 一台"电脑"
给 Agent 操作一台云电脑，让它拥有这台电脑的完整操作能力。Agent 可以在这台专属电脑里自由安装软件、读写文件、执行命令。以 Manus 等为代表。
第三条路：让 Agent"寄生"在电脑里
Agent 直接运行在一台电脑上，成为这台电脑的"主人"。它拥有最高权限，能力最强，也最接近"真正能干活"的体验。它取代了操作系统界面，成为了一个新的 OS。以 OpenClaw 等为代表。
在企业场景下，这三种路径都可以选择，真正的难点并不在于"选哪一种形态"，而在于：如何让 Agent 的"电脑"（无论是沙箱、虚拟机还是真实终端）能够安全、可控地访问企业的文件和系统，并且整套机制支持集中管控。
具体来说，企业必须回答几个现实问题：
Agent 能看到哪些目录、哪些系统？权限如何按角色、按任务动态授予和回收？ 当 Agent 需要访问 CRM、知识库、内部 API 时，凭证如何安全注入，而不是直接暴露在员工终端或 Agent 上下文中？ 版本、Skill、策略能否集中下发和更新，而不是依赖每位员工自行维护？ 交互过程数据是否默认回流到企业可控环境，而不是散落在本地或外部服务？
如果这些问题没有系统性的答案，那么无论选择沙箱、云电脑还是本地高权限客户端，都只是把风险从一种形态转移到另一种形态，并没有真正解决"既要能力强，又要安全可控"的矛盾。
这也是为什么单纯追求"给 Agent 更大的权限"在企业里往往走不远。真正可持续的路径，是在能力与安全之间建立清晰的责任边界和管控机制，让 Agent 的"手"足够灵活，同时让企业始终握有最终的控制权。
企业真正需要什么样的系统？
企业真正需要的，或许不是"能力最强的本地 Buddy"，而是一个能力足够强、同时把"数据可控"和"过程可沉淀"放在优先位置的系统。它应该支持丰富的 Skill 与复杂工作流，但交互数据默认回流、权限与升级可集中管理、操作过程可审计，并且这些交互过程能够持续用于优化模型和沉淀业务知识。
在评估是否大规模为员工配置这类本地 AI 助手时，除了看它当下能做多少事，或许也可以多问几句：
交互过程最终沉淀在哪里？ 这些数据能否被我们持续使用？ 安全边界是由系统设计清晰界定，还是主要依赖个人判断？
· · ·
模型会变，工具会变，形态也会变。而那些带着真实业务语境的交互轨迹，一旦真正属于企业，就会成为越用越深、越用越懂自己的独特优势。
这或许才是"用户和 AI 的交互过程是企业的最大资产"这句话，最值得认真对待的地方。
