Agent 入职企业，需要一台电脑，也需要一张工牌

AI 生成的概念封面，以电脑和工牌类比 Agent 的执行环境与业务访问权限。

一位新同事入职，企业通常会先为他准备两样东西。

一台电脑，让他能打开文件、运行软件、完成工作。一组账号和权限，让他能进入 OA、查看项目文档、使用 CRM，在职责范围内读取和修改业务数据。

电脑准备好了，账号还没开通，他仍然很难开始工作。账号开通了，没有可用的工作环境，许多任务同样做不下去。

未来 Agent 进入企业，也会遇到这两道门槛。

它需要一个执行任务的环境，也需要一套访问业务系统的授权机制。 前者可以由 sandbox，也就是沙箱提供；后者则是 OpenConnector 这类连接与鉴权网关所解决的问题。

这两层基础设施，决定了一个有能力的 Agent，能否真正进入企业的工作现场。

从回答问题，到承担一份工作

企业里有价值的任务，往往发生在多个系统之间。

假设你让 Agent 为明天的客户会议做准备：看看日历中的参会人，查阅最近几封往来邮件，从 CRM 里整理客户进展，再把需要讨论的问题写进会议文档。

这里既需要理解和判断，也需要实际访问系统。Agent 要知道去哪里找信息，以哪个账号访问，哪些数据可以读取，整理后的结果可以写到哪里。

如果进一步要求它更新客户状态、发出会议邀请，权限问题还会继续变化：能够查阅客户资料，不等于能够修改商机；能够读取邮件，也不等于能够代表公司发送邮件。

我们在讨论 Agent 数据安全时提出过：充分的业务上下文，才能让 Agent 考虑周全。接下来必须回答的是，企业怎样把这些上下文和操作能力交给它。

人类员工通过账号、岗位和权限进入业务系统。Agent 同样需要明确的访问边界。

Sandbox 是 Agent 的工作电脑

人类员工在电脑上运行软件，Agent 则需要相应的执行环境。

它可能要运行一段代码、处理一批表格、生成文件，或者操作浏览器。沙箱为这些任务提供受约束的环境，限制程序能接触哪些文件、进程和网络资源。具体隔离能力取决于实现与配置。Anthropic 的沙箱工程说明介绍了文件系统与网络隔离在 Agent 执行中的作用。

这有点像企业为员工配置电脑：提供工具，也划定设备上的工作边界。

但电脑能运行程序，并不会自动获得财务系统的权限。沙箱能够执行代码，也不会自动取得 CRM 或 OA 的合法访问权。

沙箱回答的是：Agent 在什么环境里执行任务，这个环境允许它做什么？

访问业务系统，则需要另一层基础设施。

鉴权网关是工牌背后的门禁系统

员工的工牌代表身份，门禁系统决定这张工牌能打开哪些门。企业软件中的账号、角色和授权，也在做类似的事。

对 Agent 来说，连接与鉴权网关承担其中一部分职责：管理应用连接和凭据，检查调用权限，并把获准的操作提交给目标系统。

“连上一个应用”只是开始。一条长期可用的访问路径，还需要处理一系列具体问题：

• 这次任务使用谁的账号，代表谁执行？
• 允许读取哪些信息，执行哪些写入操作？
• 第三方账号的凭据存在哪里，由谁保护和刷新？
• 调用失败时，能否查到原因和对应记录？
• 任务结束或职责变化后，怎样收回相应访问能力？

如果把每个应用的密钥都直接放进 Agent 的运行环境里，这些问题就分散到了各个脚本、配置和部署中。模型或执行环境更换一次，团队可能又要重新梳理一遍。

网关提供了一个集中处理连接与授权的边界。Agent 按获准的接口提交请求，第三方账号的原始凭据由网关管理，具体操作在执行时接受检查。

“请只读数据”可以写在任务说明里；“这次调用没有写入权限”需要由系统执行。 这层约束，让企业能把实际操作逐步交给 Agent。

两层边界，保护的是不同的地方

沙箱与鉴权网关可以配合工作。

概念架构示意：展示一种经网关调用应用的路径。沙箱、网关和原应用各自约束不同的边界，实际能力取决于部署与配置。

基础设施	员工入职时的类比	主要解决的问题
沙箱	工作电脑	在哪里运行代码、处理文件和执行任务
连接与鉴权网关	工牌背后的门禁系统	使用哪个账号，获准访问哪些业务接口

一个程序即使始终运行在沙箱里，也可能通过获准的网络连接向外部系统发送请求。假如它持有一个能删除客户记录的凭据，沙箱本身并不会知道这次删除是否符合业务职责。

反过来，即使应用调用经过了网关，Agent 下载到本地的文件、运行的脚本和生成的临时产物，也仍需要执行环境来管理。

因此，企业既要管住执行环境，也要管住进入业务系统的入口。对于需要运行代码、处理文件并跨系统操作的 Agent，这两层尤其重要。

当然，企业落地还需要身份管理、任务编排、审批和结果验收。并非每个 Agent 都需要独立沙箱，一些任务只通过受控 API 就能完成。电脑与工牌这个类比，帮助我们看清的是两种基础能力：执行能力，以及被授予的业务访问能力。

为什么连接与鉴权网关值得长期关注

在演示里，一次成功调用就足以让人看到 Agent 的能力。企业持续使用时，要求会变成：多个 Agent 能否在不同账号、不同职责下，长期稳定地访问同一批系统。

今天可能由一个助手整理客户资料，明天换成另一个模型，后天又增加一个专门处理订单的 Agent。OA、CRM、文档和邮件系统通常仍然存在，连接配置、授权边界和维护工作也会继续存在。

如果每个 Agent 都独立接入这些系统，企业会反复处理类似的工作：适配接口、保存凭据、处理令牌过期、限制操作范围、排查调用失败。

把这一层做成可复用的基础设施，新 Agent 就能沿用已有的连接能力，再根据职责取得所需权限。开发者可以把更多时间用于业务流程，企业也更容易保持一致的访问规则。

这就是我们看重这个方向的原因。当 Agent 开始承担真实工作，连接与授权就成为持续发生的需求。

对开发者，这意味着值得投入的公共工程；对企业，这是值得提前规划的架构边界；对关注 Agent 产业的投资者，这也是一个值得研究的基础设施方向。判断其长期价值，可以看它能否减少重复接入，能否在更多任务中复用，以及能否持续承担连接、权限和运维责任。

OpenConnector 在建设这层基础设施

OpenConnector是 OOMOL 维护的开源连接网关。它管理应用连接与凭据，并通过 SDK、CLI、MCP 和 HTTP 等入口，为 Agent 和应用提供可调用的操作。

一次调用可以这样理解：Agent 或业务后端选择操作与连接，网关检查访问凭证和操作策略，再使用相应账号凭据请求目标应用，返回执行结果。

开发者可以查看操作定义、输入参数和所需授权范围，在自部署环境中配置允许或禁止的操作，并通过脱敏运行记录排查问题。连接运行时、操作定义与可本地执行的处理代码，让团队能够检查和扩展实际调用路径。具体接入与部署方式见 OpenConnector 文档。

这里的边界也应当清楚：网关中的操作策略，需要与原应用的账号权限、授权范围一起生效。某个账号能看到哪些客户记录，还取决于源系统自身的访问规则；是否允许发出一封邮件，也可能需要业务流程中的人工确认。企业完整的身份与审批体系，需要与网关配合。

团队可以按当前需求选择起点：用 OOMOL 托管服务先接通业务，或自部署 OpenConnector，管理自己的网关、凭据和运行环境。托管与自部署的取舍，可以继续阅读这篇部署选择指南。

这层基础设施，值得大家一起建设

企业软件接入是一项长期维护工作。

不同服务有不同的授权方式、参数约定、错误信息和使用限制。接口会变化，令牌会过期，企业还会不断增加新的应用与内部系统。

这些工作中，有很大一部分可以被共同使用。一个连接器修好了分页问题，使用它的其他团队也能受益；一项操作补齐了所需授权范围，后续接入的人就少一次排查；一段执行逻辑公开后，开发者可以检查它、修正它，再把它用于自己的环境。

这也是开源网关的意义：让各家反复承担的连接工作，有机会积累成整个生态都能使用的能力。

开放的连接层，也让开发者和企业有更多选择。Agent 可以演进，模型可以更换，连接能力仍能通过公开的接口和实现继续使用。需要掌控运行环境的团队，也有代码可读、有部署路径可走。

开源提供了检查、修改和共同维护的条件。安全性仍需要代码审查、正确配置和持续运维，第三方 API 的授权与使用条款也仍然适用。共同建设的价值，体现在这些具体工作不断被完成和复用。

为下一位“数字同事”准备好入职条件

如果把一个 Agent 当作即将入职的新同事，我们可以先问：它在哪里工作？它能进入哪些系统？它能读取什么，又能修改什么？

这些问题有了可执行的答案，企业才能逐步交给它更有价值的任务。

我们希望 OpenConnector 成为这套入职基础设施的一部分，也希望更多开发者参与建设。可以从你每天使用的一个应用开始：补充一项真正需要的操作，修复一个授权问题，完善一份参数定义，或把部署中遇到的情况反馈给项目。

访问 OOMOL 官网了解产品与接入方式；希望先验证业务的团队，可以在 OOMOL Console连接一个应用，从一个范围明确的读取操作开始。

Agent 进入企业，需要有人为它准备工作环境，也需要有人把业务系统的门，在合适的权限范围内打开。我们选择从这扇门开始，与社区一起建设。