一、为什么需要「团队共享 Agent」

2026 年 YC Spring 批次里,OneCLI 是一家值得关注的 Agent 基础设施公司:他们把 Anthropic、OpenAI 的 Agent Harness 思路打包成开源 CLI 工具,让一个团队里的多个工程师能够共享同一个 Agent 实例,但每个工程师看到的工具集、数据访问、凭据都是隔离的。本文基于 OneCLI 在 2026 年 4 月发布的技术白皮书、以及两家早期客户的工程复盘,梳理 OneCLI 的核心设计与企业落地路径。

个人 Agent(单个工程师的 Claude Code、Cursor、Cline)已经成熟,但团队共享 Agent 长期空白。实际生产中,大量场景需要团队协作:值班 SRE 共享一个生产环境巡检 Agent,谁值班谁来用;数据团队共享一个 BI 报表 Agent,所有分析师都能查询;客服团队共享一个工单处理 Agent,按权限分配谁能处理哪类工单;安全团队共享一个漏洞扫描 Agent,所有成员按权限调度任务。这些场景的共同特征是:Agent 实例需要多人共享,但每个用户只能按权限访问。这与个人 Agent 的一人一实例模式根本不同。

传统做法是企业给一个超级账号,然后所有人在同一个 root 下工作——既不安全也不高效,谁改了什么完全无法追溯。OneCLI 的解决方案是:把 Agent 跑在一个中心化的沙盒里,每个用户通过 CLI 接入,接入时携带自己的身份与权限;Agent 内部按用户身份做权限校验,而不是全员共享一个超级账号。这种设计让 Agent 既保留个人 Agent 的灵活性,又具备企业级 RBAC 的可控性。

二、核心架构:沙盒、身份层、权限层三件套

OneCLI 的核心架构可以归纳为三件套——沙盒、身份层、权限层。沙盒层使用 Firecracker microVM,每个 Agent 实例独立一个 microVM,启动时间控制在 100 毫秒以内,内存开销低于 50 MB。沙盒默认网络受限、文件系统受限、进程能力受限,任何超出限制的动作需要用户显式授权。Firecracker 原本是 AWS Lambda 用来隔离多租户函数的轻量级虚拟化方案,OneCLI 把这一思路平移到 Agent 场景,既保留了硬件级隔离的强度,又获得接近容器的启动速度。

身份层基于 OAuth 2.0 与 OIDC。每个用户接入 OneCLI 时,先完成身份认证——既支持企业 SSO(Okta、Azure AD、Google Workspace),也支持本地账号体系。认证完成后,用户获取 access token,token 中携带用户 ID、所属团队、权限范围(scope)、会话过期时间。所有后续请求都附带这个 token,身份层做无状态校验,避免传统 session 带来的状态管理负担。

权限层基于 Open Policy Agent(OPA)。OPA 是一个 CNCF 毕业的开源策略引擎,OneCLI 把所有 Agent 工具调用、文件访问、网络出站都路由到 OPA 做策略校验。策略用 Rego 描述,支持细粒度控制:用户 A 可以访问财务数据但不能修改、用户 B 可以修改但不能删除、用户 C 只能查看摘要字段。这种细粒度控制远比传统 RBAC 灵活。

三件套协同工作时,流程清晰:用户发起请求 → 身份层校验身份 → 权限层校验权限 → 沙盒层执行动作 → 返回结果。每一步都有结构化日志,便于事后审计。OneCLI 的审计日志输出到 stdout,企业可以直接接入 ELK、Loki、Splunk 等日志平台。整个链路的设计原则是:每一次 Agent 行为都可追溯到具体用户、具体策略、具体时间点。

三、与传统 RBAC 的区别

传统 RBAC(基于角色的访问控制)把权限绑定到角色,用户属于某个角色就拥有该角色的所有权限。这种模式在传统 Web 应用里没问题,但在 Agent 场景下不够灵活,因为 Agent 的权限边界远比角色复杂。Agent 会自动调用工具、读取文件、查询数据库、执行脚本,这些动作的权限边界不能简单等同于「读写」「执行」这种粗粒度维度。

OneCLI 引入动态权限概念:权限不仅基于用户角色,还基于 Agent 上下文——当前任务、数据敏感度、时间窗口、操作可逆性。例如,值班 SRE 在凌晨 2 点可以重启生产服务,但非值班时间只能查看日志;用户 A 在生产环境可以读数据但不能写,在预发环境可以读也可以写;不可逆操作(删除、修改、对外发送)需要二次确认,可逆操作(查询、读取)可以直接执行。这种动态权限在传统 RBAC 下需要写大量条件判断,在 OPA 里用 Rego 几行就能表达。

OneCLI 还引入了操作可逆性维度作为权限判断的补充信号。删除数据、修改配置、对外发送邮件这类不可逆动作,即使在权限上允许,也必须经过二次确认——系统会在执行前暂停,要求用户通过 CLI 输入 yes 或者敲击特定确认码。这种设计大幅降低了 Agent 误操作带来的损失,符合企业生产环境对「可恢复性」的硬性要求。OneCLI 的工程团队在内部文档里把这个原则总结为「让 Agent 像一个有经验的运维工程师那样工作——它知道自己什么时候应该停下来问一句」。

四、典型落地场景

场景一是 SaaS 公司的 SRE 团队。该团队原本用「个人 Claude Code + 共享服务器账号」的工作方式,所有 SRE 共享一个 root 账号,谁改了什么完全无法追溯。改用 OneCLI 后,每个 SRE 用自己的企业 SSO 接入,工具调用按个人权限校验,所有动作可追溯。事故复盘时间从平均 4 小时降到 1 小时,因为审计日志能直接拉出事故时段的全部 Agent 行为。

场景二是金融科技公司的数据分析团队。该团队有 8 个数据分析师,共享一个 BI 报表 Agent。改用 OneCLI 后,每个分析师看到的数据范围按权限隔离(初级分析师看不到敏感字段,高级分析师可以看但不能导出)。同时,Agent 的查询日志自动写入合规系统,满足了金融监管的审计要求。合规部门从此不再追问「这条 SQL 是谁跑的」,因为审计日志直接给出了答案。

场景三是互联网公司的客服团队。该团队有 30 个客服,共享一个工单处理 Agent。改用 OneCLI 后,Agent 按工单类型自动路由(订单问题分配给订单组,退款问题分配给退款组),每个客服只能处理自己权限内的工单,无法越权。同时,所有客服操作自动记录,便于质检。客服主管从此可以基于 Agent 日志做精细化的服务质量评估,而不是依赖事后抽查。

场景四是安全团队的漏洞扫描。该团队需要多个工程师按不同时间窗口调度同一个漏洞扫描 Agent(防止扫描任务冲突)。OneCLI 的调度层天然支持这种场景——同一时刻只有一个扫描任务运行,其他工程师的请求会被排队并提示预计等待时间。任务完成后,扫描结果按工程师权限分发,而不是全员可见。

五、与 MCP 协议的契合

OneCLI 的工具描述完全遵循 MCP 协议。任何 MCP 兼容的工具都可以接入 OneCLI,不需要额外适配。这种设计让 OneCLI 受益于整个 MCP 生态——2025 年下半年以来,MCP 已成为 Agent 工具的事实标准。具体落地:OneCLI 的工具市场就是 MCP 服务器目录,用户可以一键安装社区贡献的 MCP 服务器,或者部署自己的内部 MCP 服务器。

OneCLI 只做「权限 + 身份 + 沙盒」,不做「工具适配」,把工具生态留给社区。这种定位与 Kubernetes 早期类似——Kubernetes 不做应用编排,只做资源调度,把应用编排交给 Helm、Operator 等上层生态。OneCLI 团队相信:Agent 工具生态的多样性远比单一厂商的全栈方案更有生命力,而权限、身份、沙盒是少数适合作为基础设施提供的横切关注点。

六、为什么选择开源

OneCLI 选择开源,核心代码托管在 GitHub 上,采用 Apache 2.0 协议。这种选择有几个考虑。信任方面,Agent 工具涉及权限、凭据、审计,开源让企业可以审查每一行代码,避免黑盒信任。生态方面,开源让社区可以贡献插件(如新的权限策略、新的工具集成),加速产品迭代。商业化方面,OneCLI 通过企业版(托管服务、合规增强、技术支持)变现,开源版免费,吸引开发者。

这种「开源核心 + 商业增强」的模式,与 GitLab、Elastic、MongoDB 类似,在企业基础设施市场被反复验证。OneCLI 团队明确表示:开源版的边界是「个人和小团队够用」,企业版的卖点是「大规模生产环境的可靠性与合规性」,二者形成健康的上下游关系,而不是相互蚕食。

七、与同类方案的横向对比

在 Agent 团队协作这个赛道,OneCLI 并非唯一玩家。OpenAI 的 ChatGPT Enterprise、Anthropic 的 Claude for Teams 都提供「团队共享 Agent」的能力,但都是 SaaS 形态,不支持私有化部署。开源方案里,E2B、CodeSandbox、Modal 提供沙盒能力,但不绑定身份层和权限层,需要企业自己集成。OneCLI 的差异化在于把沙盒、身份层、权限层做成「一站式」,企业只需要对接一次,而不是拼装三套独立工具。

从部署复杂度看,OneCLI 提供 Docker 镜像和 Helm Chart,企业可以在自己的 Kubernetes 集群里一键部署。从运维成本看,OneCLI 的 microVM 沙盒是轻量级的,大规模部署的资源开销可控。从合规角度看,OneCLI 的审计日志格式符合 SOC 2、ISO 27001 的常见要求,降低了企业的合规改造成本。

八、落地建议

对于正在评估 Agent 团队共享方案的团队,建议按以下顺序推进。第一,先盘点现有「团队共享 Agent」的需求——哪些场景需要共享,哪些场景个人 Agent 就够了。不要为了共享而共享,共享 Agent 带来的复杂度上升是真实的。第二,评估 OneCLI 等开源工具的成熟度——检查 GitHub 上的 star 数、贡献者数量、最近的 commit 频率、生产案例。开源工具的成熟度直接影响生产可用性。

第三,在小范围试点——先让一个小组(3-5 人)使用 OneCLI,验证权限模型、审计能力、性能稳定性,确认无误后再扩大到整个团队。试点阶段重点验证三个问题:权限模型能否覆盖业务场景、审计日志是否能接入现有合规体系、沙盒开销是否在预算范围内。第四,与现有 IAM 体系整合——OneCLI 应接入企业的 SSO(Okta、Azure AD、Google Workspace),而不是另搞一套账号体系。账号体系碎片化是运维噩梦的源头。第五,建立 Agent 使用规范——明确规定哪些操作可以用 Agent 做、哪些必须人工审批、Agent 输出如何验收。规范比工具更重要,工具只决定能不能做,规范决定该不该做。第六,定期审计 Agent 行为——即便 OneCLI 自动记录所有操作,也要定期抽样审计,发现异常使用模式。审计是发现权限滥用和配置错误的最有效手段。

九、长期演进方向

OneCLI 这类工具的长期演进值得关注。第一个方向是跨组织 Agent 协作。当多个企业的 OneCLI 实例需要协作(例如供应链上的合作伙伴),身份层要从「企业内 SSO」扩展到「跨企业 SSO」(类似 OIDC 联邦身份)。这需要更复杂的协议设计,也涉及跨组织信任、跨组织审计、跨组织合规等深层问题。第二个方向是 Agent 行为的合规校验。当 Agent 在金融、医疗、政务领域执行操作时,合规要求越来越细。OneCLI 的 OPA 策略需要支持更复杂的合规规则,如 GDPR、HIPAA、SOX 等。这意味着策略语言本身需要进化,支持更丰富的语义表达。

第三个方向是沙盒性能优化。Firecracker 已经是轻量级 microVM,但仍有 50MB 内存开销。对于大规模 Agent 集群(1000+ 实例),这个开销仍然显著。WebAssembly 沙盒、用户态 Linux 容器(如 gVisor)、unikernel 都是值得探索的方向。OneCLI 团队已经在内部测试 WebAssembly 沙盒的可行性,预计 2026 年下半年会有实验性发布。第四个方向是与 AI 治理框架的整合。AI 治理(NIST AI RMF、欧盟 AI Act)对 Agent 的透明性、可解释性、可追溯性提出明确要求。OneCLI 的审计日志天然契合这些要求,未来需要更深入的整合——例如,把审计日志喂给 AI 治理平台做自动评估,而不仅仅是事后人工翻阅。

结语

OneCLI 这类工具的价值,在于把「团队共享 Agent」从「野生状态」(共享 root 账号)带到「工程化状态」(身份 + 权限 + 沙盒 + 审计)。当团队协作成为 Agent 落地的主要场景,这种基础设施就是必需品,而非可选项。2026 年,我们看到越来越多的企业从「个人 Agent 试点」走向「团队 Agent 落地」,这个转变背后,是大量未被满足的工程化需求——OneCLI 是其中一种回答,也是开源生态对这一趋势的积极响应。对于中国市场的企业用户,OneCLI 的开源特性、私有化部署能力、与 MCP 生态的兼容性,使其成为一个值得认真评估的选项。