OneCLI(YC S26)开源沙箱化 Agent Harness:团队级 Agent 编排落地,以及企业私有化部署的工程新样本 过去一个月,YC S26 批次里有一家做"团队级 Agent Harness"的公司拿到了不少 Hacker News 的关注——OneCLI。它的两个创始人在 Launch HN 上的自我介绍(2026 年 8 月 19 日)和公司博客《Why We Gave Eve
OneCLI(YC S26)开源沙箱化 Agent Harness:团队级 Agent 编排落地,以及企业私有化部署的工程新样本
过去一个月,YC S26 批次里有一家做"团队级 Agent Harness"的公司拿到了不少 Hacker News 的关注——OneCLI。它的两个创始人在 Launch HN 上的自我介绍(2026 年 8 月 19 日)和公司博客《Why We Gave Every Agent a Computer》(2026 年 8 月 24 日)合在一起,把"企业怎么把 Agent 真正落到生产"这件事的工程图景讲得相当完整。本文把这两份一手素材合并改写,从"为什么需要 Harness"、"为什么从容器走到 microVM"、"怎么把策略层放到模型之外"、以及"这套架构对国内企业私有化部署意味着什么"四个角度,展开聊一聊 OneCLI 给出的样本,以及它能(不能)复用到什么场景。
一、从 Vault 到 Harness:OneCLI 的诞生逻辑
OneCLI 的两个创始人 Jonathan Fishner 和 Guy 都不是 AI 背景出身,他们之前都在网络安全行业深耕多年。Jonathan 在 Axis Security 做过 zero trust network access,这家公司的核心信条是"永远不要信任客户端,你得在网络层决定一个人能访问什么",这条思路后来被完整继承到了 OneCLI 的产品架构里。
故事的起点其实不是 Agent。2026 年 1 月前后,OpenClaw 这类自主 Agent 工具开始爆发,他们当时在做一个叫 ChartDB 的开源数据库工具,自然就想着用 Agent 来加速 ChartDB 的开发工作流。很快撞到了一个非常具体的工程问题:Agent 要干活必须给凭据,但凭据一旦给到 Agent,Agent 会把它写进自己的记忆、本地文件、会话日志,全部以明文形式存在;更糟的是 Agent 很容易被 prompt injection 骗到主动交出这些密钥。网络安全背景的两位创始人立刻意识到,这不是"加个 prompt 就能解决"的工程问题,而是 Agent 时代的"凭据治理"问题。
他们最早的产品形态是一个用 Rust 写的 "Vault for AI Agents"——一个代理网关,Agent 在调用第三方 API 时不直接拿到真实密钥,而是从 Vault 拿一个 placeholder,真实密钥在网关侧注入、并在请求结束后立刻丢弃。这条路线很快得到了自发需求:Hermes、OpenClaw、NanoClaw 这类自主 Agent 的用户在大量部署的时候,核心痛点都集中在两件事:一是"密钥和权限怎么管",二是"团队里多人都要用 Agent 的时候怎么协作"。
意识到真正缺的不是 Vault 而是"Harness(脚手架)"之后,两人做了一个明确的策略转向:把整个 Agent 管理平台连同 Vault 一起开源(Apache-2.0 + 少量企业例外条款),目标不是卖给个人,而是卖给团队——给每个员工一个受控的、有边界的个人 Agent。
二、为什么从容器走到 microVM
OneCLI 最初和大多数 Agent 平台一样,每个 Agent 跑在一个容器里。这条路线便宜、启动快、彼此之间隔离——从表面看非常合理。但当用户开始提"真正的需求"时,容器暴露了三个边界。
第一个边界是:容器跑不出完整的应用。一个工程师让 Agent 帮他"把代码 clone 下来,把整条链路跑起来,看一眼功能到底行不行"。Agent 把代码拉下来之后卡住了——容器里没有 PostgreSQL 可以启、没有应用可以跑、没有显示器可以让 Agent 看结果。最终 Agent 只能告诉用户"如果我有这个能力我会怎么做",但活没干成。
第二个边界是:容器不能给 Agent 一个真正的浏览器。越来越多的用户开始让 Agent 去做"帮我在 Instacart 下单"、"帮我在银行网页上对账"、"帮我看后台数据"这种真人浏览器才能干的活。容器天然没有 GUI、没有真实浏览器 profile、没有 cookie 持久化——这一切都需要 Agent 拥有"自己的电脑"。
第三个边界是:容器的隔离强度,放到企业环境里不够。容器共享宿主机内核。在企业生产环境里,这就意味着 Agent 跑的所有命令,理论上有能力触达宿主机上的所有其他容器、所有其他租户的所有文件。即便实际上概率不高,但网络安全出身的两位创始人不能接受"这是宿主机内核做的那层隔离"——他们要的是"Agent 出问题只能影响它自己的那台 VM"。
微虚拟机(microVM)正好同时解决了这三个边界。一个 Agent 配一台 microVM:文件系统归 Agent 自己、有真实的 Chromium 可以驱动、有真实的桌面 session;VM 之间硬件级隔离,故障半径天然是单 Agent;同时 microVM 可以在秒级拉起,跟容器的启动延迟差距并没有数量级的差别。
这一选择让 OneCLI 的整套架构从"AI 应用"切换到了"虚拟化基础设施 + AI 应用"的双层叠加,也为后面要讲的策略层设计提供了干净的承载面。
三、策略层在网络层、模型之外
OneCLI 的架构里最值得记住的一条原则是:策略不在 prompt 里,在网络层。 创始人在原话里直接说"Prompt 是建议,policy 是强制"。
具体的执行机制是:每个 Agent 的所有出向请求都经过一个集中式的 gateway。这个 gateway 做的事情是:① 用 placeholder 替换 Agent 拿到的真实密钥,真实密钥由 gateway 在请求发出前注入,请求结束后立刻丢弃;② 检查这条请求是否匹配组织管理员配置的策略(允许的域名、允许的方法、速率限制、需要人工二次确认的操作范围、单 Agent 的权限边界);③ 把策略匹配结果和请求身份一起写进审计日志。
这条机制直接决定了 OneCLI 的几个关键安全属性。
第一,密钥永远不进 Agent 的上下文、记忆或日志。这意味着即便 Agent 被 prompt injection 骗到去读自己的记忆,它也读不到任何真实凭据——只看到 placeholder。这条性质比"密钥加密存储"更强,因为加密存储的密钥最终还是要在某个时刻被解密、被 Agent 看到。
第二,Agent 不能绕过 gateway。所有出向请求都必须经过这个集中式组件,即便 Agent 想直接 `curl` 一个不在白名单里的地址,在网络层就被拦住。这一点对网络安全出身的两位创始人来说是基本的"零信任"原则:不要相信客户端(包括 AI 客户端)会乖乖按规矩做事,把策略放到网络层强制执行。
第三,人工二次确认是策略层一等公民。发邮件、删 Linear 工单、花钱——这些操作被 OneCLI 明确定义为"必须经人在 chat 里点确认才能继续"。这个确认不是"事后审计",而是"执行前的 hard gate",Agent 在没有拿到人类确认之前就走不到下一步。这跟 Anthropic 在 Claude Code 里做的 sandboxing 是互补关系——Claude Code 把"控制平面留在 sandbox 里"做硬隔离,OneCLI 把"高危操作必须人工复核"做成集中式策略。
第四,每个 Agent 都绑定到一个员工身份。这意味着审计日志里能完整回答"这个 API 调用是哪个员工授权的 Agent 在哪一刻发的、经过哪个策略允许"——这就是 zero trust 里"每一次访问都有可追溯的授权链"的工程实现。
把策略层从模型层拉出来这件事,在工程上带来的直接收益是:Agent 的能力可以越堆越多,但"出错时的爆炸半径"始终被压在一台 VM 和一个 gateway 里。这条原则在企业环境里几乎是必须的——没有一家公司的安全团队会接受"Agent 自己决定要不要发那封邮件"。
四、Agent Harness 的运行时:为什么是 jcode + Rust
OneCLI 在 Agent 引擎这一层做了一个有意思的选型:核心 loop 用了一个叫 jcode 的项目。这一点在 Launch HN 的原帖里被一笔带过,但对于工程团队来说很关键——Harness 的响应速度和稳定性决定了用户对"自主 Agent"的信任度。
OneCLI 选 Rust 的理由跟网络安全背景是一致的:Rust 给的内存安全保证、没有 GC 暂停的运行时、可预测的尾延迟,在"Agent 每秒钟可能发起几十次工具调用"的高并发场景下,比 Python 这种带 GC 的语言更稳。jcode 这个具体项目本身并不是 OneCLI 的发明,但把它作为 harness 的核心 loop 而不是更上层的 LangChain/AutoGen 这类编排框架,意味着 OneCLI 对"执行延迟"和"循环稳定性"看得比"开发效率"重。
这条选择对企业的启示是,如果你的团队也打算自建 Agent Harness,不要从 LangChain 这类编排框架起步。Orchestration 框架适合做 demo,不适合做 production loop。Production loop 需要的是一个明确的、能写出终止条件的、可观测的状态机——OneCLI 选了 Rust + jcode 这种"贴近金属"的栈,本质上是在做这件事。
五、Harness 上跑的真实工作流
OneCLI 公开出来的几个客户使用场景里,有几条对国内企业特别有借鉴价值。
第一条是"销售线索 → 工程交付"的完整闭环。一个 SaaS 公司的销售 Agent 接听完客户的视频会议之后,自动根据会议内容在 Linear(项目管理工具)里开 ticket;这个 ticket 自动触发开发 Agent 写代码、跑测试、合并到主干、部署到预发环境;运维 Agent 收到部署完成的信号后,自动更新客户关系管理(CRM)里的状态字段,把"已交付"这条信息推回给销售。整个流程里没有人手传递,所有的 Agent 都在 OneCLI 的同一套策略约束下执行。
第二条是 CRM 自动维护。Agent 在通话结束后自动整理通话纪要、补全客户画像字段、把后续 follow-up 任务排进日程。这条流程之所以在 OneCLI 上能跑通,核心不在于"Agent 写得多么聪明",而在于 OneCLI 把"修改 CRM"这条操作绑在了一个需要人工确认的策略下——Agent 可以建议写什么字段,但最终落库的字段需要人来点确认。
第三条也是最有冲击力的一条:工程师让 Agent clone 自己公司的代码库,起 PostgreSQL + Redis + 应用容器,在自己的 microVM 里跑端到端集成测试,看着 OAuth 回调真正落到自己的应用上,修 bug,再开 PR。这条流程把"集成测试环境从稀缺资源变成每个 Agent 默认有的能力"这件事变成可能——OneCLI 的博客原话是"写 connector 本身从来不是瓶颈,瓶颈一直都是给一个真实可跑的环境"。
六、对国内企业私有化部署的启示
把 OneCLI 的架构搬到国内企业的私有化场景里,有四条值得展开。
第一条启示:别从 Vault 起手,直接从 Harness 起手。国内很多企业的"AI 落地"项目是从"做一个统一的 API 网关、把所有模型的密钥管起来"开始的。但 OneCLI 的经验告诉我们,密钥管理只是结果,不是原因。真正让 Agent 在企业里能用起来的是"把策略层放在模型之外的网络层"这条架构选择。这条选择要在第一天就定下来,而不是等 Agent 跑起来了再补。
第二条启示:先决定 microVM 路线,再决定 Agent 引擎。如果你打算私有化部署 Agent,你必须先想清楚一件事:Agent 跑在容器里还是 microVM 里。容器便宜、快,但隔离强度低;microVM 启动慢几百毫秒、贵一点,但隔离强度跟公有云一个量级。如果你的客户是金融、医疗、政企这类对数据隔离敏感的行业,容器不够。如果你打算把 Agent 暴露给外部用户(比如做一个 AI 助手给客户用),microVM 是必要的。把这个决策放在 Agent 引擎之前,会避免后面一堆"这个操作能不能做"的策略层返工。
第三条启示:策略层要有"高危操作"清单。OneCLI 公开的清单包括"发邮件、删记录、花钱"——这是最低限度。企业里这份清单要更长:删数据库、修改权限、调工单系统、写正式合同、调银行接口,每一条都要单独配策略、配人工确认、配审计日志。一份"高危操作"清单是 Harness 落地的真正起点,不是 Agent 能干什么。
第四条启示:全栈开源是企业落地的入场券。OneCLI 把整个平台 Apache-2.0 开源(只有少量企业例外条款),这条选择在国内市场特别关键:国内大客户普遍对"看不到代码的 AI 工具"有戒心,不管厂商怎么说"我们做了等保三级",看不到代码就无法做尽职调查。开源不是营销姿态,是企业级市场的最低信任门槛。
七、OneCLI 还没解决的问题
把 OneCLI 的架构夸完,也得指出它目前还没解决的几个工程问题。
第一个是 microVM 的资源开销。OneCLI 跑的是"每个 Agent 一台 microVM"的模型,这对大规模团队的成本压力不小。100 个员工的团队如果每个员工配 2-3 个 Agent(销售、工程、运维),就是 200-300 台 VM 同时跑——即便每台 VM 闲置时的内存只有 256 MB,300 台也是几十 GB 的常驻开销。OneCLI 没有公开过具体的成本数据,但从公开的架构看,他们必须依靠 VM 的"快开快关"和"按需唤醒"来摊薄成本。
第二个是策略表达力。OneCLI 的策略是用"域名 + 方法 + 速率 + 是否需要确认"这种四元组描述的,这对一般 SaaS 工具够用,但对企业内部系统的访问控制(比如"只有财务部门的 Agent 能调 SAP,只能读不能写,只能在工作日 9-18 点调用")就太粗糙了。OneCLI 目前没有公开更复杂的策略表达方案,这对企业里那些非标准的内部系统是个缺口。
第三个是审计和合规。OneCLI 强调"每个 Agent 都绑定到一个员工身份,每次调用都有完整审计日志",但审计日志本身的存储、检索、合规性(比如满足 SOX、HIPAA、GDPR)这些细节没有在公开材料里展开。对国内企业来说,这意味着"日志合规"这部分得自己补,OneCLI 不会替你做。
八、结论:Harness 是企业 Agent 落地的真正入口
回到标题那个问题:OneCLI 作为 YC S26 的样本,给"团队级 Agent Harness"这件事画了一个相当清晰的工程轮廓——用 Rust 写 Agent loop、用 microVM 隔离执行环境、用集中式 gateway 做策略层、把密钥和身份治理做成平台一等公民。它不是要把 Agent 变聪明,它是要把 Agent 变得"能被企业信任"。
这套架构给国内做 Agent 落地的团队传递的最重要的信号是:企业级 Agent 的核心竞争力不在模型,而在 Harness。模型越来越像水电煤——Anthropic、OpenAI、Google、智谱、月之暗面各家都提供——真正决定 Agent 能不能在企业里活下来的,是它跑在什么环境里、密钥怎么管、策略怎么强制、出错了爆炸半径多大。这些事情不在模型的论文里,在微虚拟机的内核里,在网络网关的策略表里,在审计日志的存储格式里。
OneCLI 把它整套架构开源出来,等于把企业级 Agent Harness 的"参考实现"摆到了桌面上。下次再有人跟你说"我们要做一个企业级 Agent 平台",你可以反问一句:"你的 Harness 在哪跑?密钥怎么注入?策略层在模型外还是模型内?每个 Agent 有自己的 VM 吗?"——这四个问题的答案,就是判断这个平台能不能进企业生产环境的最低门槛。