OneCLI 相关的核心要点是什么？

本文围绕 OneCLI、Agent Harness、YC S26、沙盒化、团队协作、安全、Rust Gateway 展开，OneCLI 是 YC S26 批次的开源沙盒化 Agent Harness，专为团队协作设计。Rust 网关做凭据注入、一人一 Agent、策略外部强制、Slack 原生集成，Apache-2.0 协议。。详细解读见正文。

OneCLI：YC S26 的团队级 Agent Harness，给每个员工一个安全沙盒

2026-08-20T12:00:00+08:00

OneCLIAgent HarnessYC S26沙盒化团队协作安全Rust Gateway

OneCLI：YC S26 的团队级 Agent Harness，给每个员工一个安全沙盒

看完你会发现，企业级 Agent 的安全问题和这个项目的解法，值得收藏。

所有 Agent 框架都在解决"一个人用"的问题。Claude Code 是一个人的终端助手，DeepSeek Harness 是一个人的 CLI，Hermes 是一个人的自治 Agent。它们都很好用。

但企业里的真问题不是"一个人能不能用 Agent"，而是"一百个人同时用 Agent 时，谁来管密钥、谁来控权限、谁来保证那个实习生不会让 Agent 把生产库删了"。

OneCLI（GitHub 3,266 星，Apache-2.0，YC S26 批次）就是冲着这个来的。它的定位一句话：给每个员工一个安全的、沙盒化的个人 Agent，团队统一管理。

本文提纲

为什么不是"又一个 Coding Agent CLI"
一人一 Agent：从 IdP 到沙盒
Rust Gateway：密钥永不离开保险箱
策略不是建议，是外部强制
六组件架构拆解
Agent 的七个组成部分
与同类方案对比
开源策略与自托管

为什么不是"又一个 Coding Agent CLI"

OneCLI 的 README讲了一个很坦诚的起源故事：它最初是用 Rust 写的"Agent 凭据保险箱"（credential vault）。做着做着发现，跑自治 Agent（Hermes、OpenClaw、NanoClaw）的人都在问同一个问题--密钥和权限怎么管？

单用户场景下，你把 API key 塞进 .env 就完事了。但团队场景立刻出问题：

每个员工都要起一个 Agent，谁来统一部署？
每个 Agent 该能做什么、不该做什么，怎么定义？
谁的 Agent 是谁的？
密钥怎么分发才不会泄露？

文档原话："Every autonomous agent out there is built for one person. The moment you need to replicate that across a team, it gets messy."

于是项目转向，做了 OneCLI v2--不是又一个 Agent CLI，而是团队级 Agent 基础设施。

一人一 Agent：从 IdP 到沙盒

OneCLI 的核心模型是"每个员工一个 Agent"。但这个"一个"不是开个终端就完了，而是一条完整的链路：

graph LR
    IdP[Identity Provider
Okta/Google/Entra] --> |provision| Agent[Agent per Person]
    Agent --> |runs in| Sandbox[Isolated Sandbox
filesystem + shell]
    Sandbox --> |outbound only| Gateway[Rust Gateway
MITM HTTPS]
    Gateway --> |inject credentials| Tools[Tools & APIs]
    Gateway --> |enforce policy| Policy[Team Policy]

    style IdP fill:#FF6B6B,color:#000000
    style Agent fill:#4ECDC4,color:#000000
    style Sandbox fill:#45B7D1,color:#000000
    style Gateway fill:#FFEAA7,color:#000000
    style Tools fill:#96CEB4,color:#000000
    style Policy fill:#DDA0DD,color:#000000

从 IdP 出发：Agent 基于公司 IdP 的员工身份自动 provision。你入职，你的 Agent 就在那了；你离职，Agent 跟着回收。

每个 Agent 一个隔离沙盒：每个 Agent 有自己的文件系统和 shell。沙盒的唯一出口是 Gateway--它只能访问你授予的东西，别的什么都碰不到。

多种触达方式：Agent 在 dashboard 里有自己的页面，也可以接 Slack，在自己的频道和 DM 里以自己的名字和头像回答。删掉 Agent，对应的 Slack app 跟着消失。

Rust Gateway：密钥永不离开保险箱

这是整个架构里最精巧的部分。

所有 Agent 的出站请求都经过一个 Rust 写的 Gateway。Gateway 做 HTTPS MITM（中间人拦截），在请求发出前注入凭据。Agent 用 access token 通过 Proxy-Authorization header 认证。

密钥存储用 AES-256-GCM 加密，只在请求时解密，按 host 和 path pattern 匹配后，以 header 或 query parameter 形式注入。

关键点：Agent 自己永远看不到真实密钥。

它拿到的只是"你被授权了"，Gateway 在请求层面帮你加凭据。这意味着即使 Agent 被注入了恶意指令、或沙盒被攻破，攻击者也拿不到任何真实凭据--因为密钥根本不在沙盒里。

更进一步，OneCLI 接了 Bitwarden 和 1Password 的按需注入（on-demand injection），服务端什么都不存。密钥留在你的密码管理器里，Gateway 在需要时去取。

这条设计回应了企业 Agent 部署最大的恐惧："Agent 拿到生产密钥跑了怎么办？" OneCLI 的答案是：它压根拿不到。

策略不是建议，是外部强制

OneCLI 对安全有一个我很认同的判断：告诉 AI 要守规矩是请求，在模型外部加硬限制才是执行。

LLM 遵守指令是概率性的，prompt 里写"不要删数据库"拦不住一个被精心构造的输入绕过。OneCLI 把策略放在 Gateway 层，用代码而非 prompt 执行：

策略类型	行为
禁区操作	删 repo、发付款、清客户记录，"the answer is always no"--模型再怎么请求也没用
失控防护	Agent 重复自己或操作太快时自动减速或暂停
人审批门	敏感操作暂停，等人确认后才继续。审批就在聊天里完成
权限范围	Agent 能碰的工具和账号不超过其所属员工的已有权限。客服的 Agent 碰不了工资表

审批门（Human-in-the-loop）的设计特别实用：不是"Agent 发邮件问你"，而是"在 Slack 对话里直接 approve/reject"。Agent 跑到敏感步骤自动暂停，你在 Slack 里点确认，它继续。这种确定性审批是生产环境敢用 Agent 的前提。

六组件架构拆解

OneCLI 的架构由六个组件构成：

graph TB
    subgraph ControlPlane["Control Plane"]
        Web[Web Dashboard
Next.js]
        API[API Server
owns DB + work queue]
    end
    subgraph DataPlane["Data Plane"]
        Runner[Runner
outbound-only, no DB access]
        Sandbox[Sandbox Supervisor
vendor-neutral harness]
        Gateway[Rust Gateway
MITM + credential injection]
        Adapter[Channel Adapter
Slack daemon, one per agent]
    end
    SecretStore[(Secret Store
AES-256-GCM)]
    DB[(PostgreSQL)]

    Web --> API
    API --> DB
    Runner --> |polls work queue| API
    Runner --> |starts/parks/reaps| Sandbox
    Sandbox --> Gateway
    Gateway --> SecretStore
    Adapter --> API

    style Web fill:#FF6B6B,color:#000000
    style API fill:#4ECDC4,color:#000000
    style Runner fill:#45B7D1,color:#000000
    style Sandbox fill:#96CEB4,color:#000000
    style Gateway fill:#FFEAA7,color:#000000
    style Adapter fill:#DDA0DD,color:#000000
    style SecretStore fill:#FFF9E6,color:#000000
    style DB fill:#FFF9E6,color:#000000

Web Dashboard（Next.js）：创建 Agent、聊天、编辑记忆和 Skills、管理连接和授权。

API Server：控制面。持有数据库、会话管理、Runner 轮询的工作队列。

Rust Gateway：拦截出站请求（包括 HTTPS，用 MITM），注入凭据。Agent 用 access token 经 Proxy-Authorization header 认证。

Runner：启动、停放、回收 Agent 沙盒。纯出站，不持有入站端口--笔记本、家庭实验室、NAT 后的 VPC 都能跑，不需要 ingress 或隧道。

Sandbox Supervisor：跑在每个沙盒内部，说一套 vendor-neutral 的 harness 接口，让 Agent runtime 可替换。

Channel Adapter：Slack daemon，每个 Agent 一个 app。

两个关键设计决策值得注意：

Runner 不碰数据库。 它只通过 API 轮询工作队列。这意味着 Runner 可以部署在不可信或网络隔离的环境中，即使被攻破也拿不到数据库里的任何东西。

Sandbox Supervisor 是 vendor-neutral 接口。 Agent runtime 可替换--不绑死在某个 LLM 或某个 agent 实现上。这和之前拆过的 deepagents"一切皆插件"是同一个方向，OneCLI 在沙盒层做了这件事。

Agent 的七个组成部分

OneCLI 对 Agent 的定义不是"一次 prompt"，而是一个持久实体：

组成	说明
Computer	隔离沙盒，自己的文件系统和 shell。唯一出口是 Gateway
Conversation	dashboard 或 Slack 里自己的页面。工作时发消息会直接重定向而非排队
Memory	Agent 学到的东西由平台保存，永不丢失。可读可编辑
Skills	你写一次的指令和助手，Agent 永远可用
Schedule	Agent 可以规划未来的工作，平台在正确的时间唤醒它
Credentials	只拿到你授予的访问，Gateway 每次请求强制执行
Slack App	接一次就以自己的名字和头像在频道和 DM 里回答

这里有几个值得注意的设计：

工作时发消息直接重定向，不排队。这解决了 Agent 长任务的一个痛点：你中途想改方向，不用等它跑完。

Schedule 能力让 Agent 真正变成"自治"的：它可以自己规划"明天早上 9 点检查 CI 状态"，平台到点唤醒它。这比"用户发消息才动"的被动 Agent 高一个层次。

Memory 平台级持久意味着 Agent 跨会话、跨重启都记得你。不是每次对话从零开始。

与同类方案对比

把 OneCLI 放到当前的 Agent Harness 谱系里定位：

项目	定位	安全模型	团队能力	语言
OneCLI	团队级沙盒 Agent 基础设施	Gateway 凭据注入 + 外部策略强制	一人一 Agent，IdP 集成	TypeScript + Rust
Claude Code	个人 coding CLI	本地权限确认	无	TypeScript
DeepSeek Harness	个人 Agent harness，一切皆插件	danger-full-access / sandbox	无	TypeScript
Pi	极简 Agent，原语不功能	手动配置	无	TypeScript
LangChain deepagents	开发者框架，中间件 + Backend	声明式 permission + sandbox	无	Python

OneCLI 是这个谱系里唯一把团队管理和企业安全作为一等公民的。其他项目解决"怎么跑好一个 Agent"，OneCLI 解决"怎么安全地给一百个人跑一百个 Agent"。

从技术栈看，Rust 写 Gateway 是个聪明的选择--凭据注入这种对性能和安全都敏感的路径，Rust 的零成本抽象和内存安全都很合适。主体用 TypeScript 保持迭代速度。

开源策略与自托管

OneCLI 用的是 Apache-2.0，但有一个例外：ee/ 目录下的企业功能用 OneCLI Enterprise License，开发/测试/评估免费，生产使用需要订阅。其他全部 Apache-2.0，可自由自托管生产环境。

这是当前开源基础设施项目流行的"Open Core"模式--核心开源，企业增值功能收费。对比纯 Apache-2.0 的 deepseek-harness 和 MIT 的 Pi，OneCLI 的商业化路径更清晰。

自托管步骤很简单：

git clone https://github.com/onecli/onecli.git && cd onecli
pnpm install
pnpm run setup

打开 http://localhost:10254 就能跑。pnpm run setup 会处理 PostgreSQL、迁移、依赖的一切。也有云端托管版（onecli.sh），7 天免费试用送 $5 AI credits，客户列表里有 Docker、Zoho、Coralogix、Kakao Entertainment、Cleo、Optibus--从开发工具到交通科技，跨行业验证。

这对 Agent 基础设施的启示

OneCLI 的设计揭示了 Agent 基础设施正在发生的三个趋势：

第一，从单用户到多租户。 单个 Agent 做得好是入门题，团队级隔离、权限、审计才是企业落地的硬门槛。OneCLI 的 IdP 集成和一人一 Agent 模型直接回答这个问题。

第二，安全从 prompt 挪到基础设施。 "在 prompt 里告诉 Agent 别做坏事"是权宜之计，生产环境必须用 Gateway 和策略引擎在模型外部强制。OneCLI 的 Rust Gateway + 外部策略就是这个思路的工程实现。

第三，Agent 从一次性 prompt 变成持久实体。 Memory、Schedule、Slack 原生集成，Agent 变成一个长期存在的"数字员工"而非用完即弃的工具。这个心智模型的转变，可能比技术实现本身更深远。

这三个趋势指向同一件事：Agent 基础设施正在从"开发者工具"变成"企业 IT 基础设施"。 OneCLI 抓住了这个转折点。

参考文档与链接

GitHub: onecli/onecli - Apache-2.0（ee/ 目录企业许可），3,266 星，TypeScript + Rust
OneCLI 官网 - 云托管版，7 天免费试用，客户含 Docker/Zoho/Kakao Entertainment 等
OneCLI 文档 - 完整文档，含 vault 集成、开发指南
OneCLI 架构图 - 六组件架构：Web/API/Gateway/Runner/Sandbox/Adapter
OneCLI Discord - 社区讨论
Y Combinator S26 - OneCLI 所属批次

作者: itech001 来源: 公众号：AI人工智能时代网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。

OneCLI：YC S26 的团队级 Agent Harness，给每个员工一个安全沙盒

OneCLI：YC S26 的团队级 Agent Harness，给每个员工一个安全沙盒

本文提纲

为什么不是"又一个 Coding Agent CLI"

一人一 Agent：从 IdP 到沙盒

Rust Gateway：密钥永不离开保险箱

策略不是建议，是外部强制

六组件架构拆解

Agent 的七个组成部分

与同类方案对比

开源策略与自托管

这对 Agent 基础设施的启示

参考文档与链接

相关阅读

OpenBot：CopilotKit 开源 AI 同事框架，每个 Agent 配一台独立电脑

OneCLI：2.8K Star，给 AI Agent 装上网络层安全阀

把 AI Agent 从 Demo 推向生产：7 个维度的完整落地指南

NVIDIA 开源 SkillSpector：在安装 AI Agent 技能之前，先问问它安不安全