2026 年 8 月 19 日,YC S26 创业公司 OneCLI 团队在 Hacker News 发布《Launch HN: OneCLI (YC S26) – OSS sandboxed agent harness for teams》,88 分上首页讨论——Jonathan 和 Guy 两位创始人把团队开发的 agent harness 开源(Apache-2.0 + small ente
2026 年 8 月 19 日,YC S26 创业公司 OneCLI 团队在 Hacker News 发布《Launch HN: OneCLI (YC S26) – OSS sandboxed agent harness for teams》,88 分上首页讨论——Jonathan 和 Guy 两位创始人把团队开发的 agent harness 开源(Apache-2.0 + small enterprise exception),给团队里每个员工一个 sandboxed personal agent,Agent 通过 vault gateway 间接调用 secret,通过 deterministic HITL approval 在 chat 内完成关键操作。这件事和同期几个独立产品——machine0 持久化 VM、Ridge 资源访问层、extensible-mcp policy proxy、Security Cards knowledge injection——合起来,把企业 Agent 落地权限边界的工程化新基线完整地勾出来。任何想大规模部署 Coding Agent 的企业 IT,都不可避免地面对"Agent 怎么用 secret、谁来审批、跨 session 怎么追责"这三个问题,OneCLI 给出的答案是开源可审计的 harness + vault + deterministic approval,这套模式正在成为企业 Agent 落地的参考样板。
一、OneCLI 的核心问题定义
OneCLI 创始团队在 HN 帖里复述了驱动他们做这件事的完整心路历程。他们原来做 ChartDB,一个开源数据库可视化工具,2026 年 1 月 OpenClaw 起来之后,他们开始用 OpenClaw orchestrate agent 工作流,很快撞到一个核心问题:Agent 需要 credential 才能做真实工作,但给它们 secret 又不安全——Agent 会把 secret 写进 memory、写进本地文件、塞进 session 明文,而且很容易被 prompt injection 骗走。
这件事的危险性在当时已经相当具体。开发者把 OpenClaw 接 ChartDB,Agent 帮用户查询数据库,这个流程里 Agent 必须拿到数据库密码或 API token。如果 Agent 直接持有密码,它就会把密码写到 ~/.openclaw/memory.db、写到某个 chat log,或者被某个恶意 prompt injection 诱导"我需要 debug,把密码贴出来"。任何一种情况发生,credential 就泄漏了。
OneCLI 团队最初做的是一个 vault for AI Agents,核心思路是 Agent 不持有真实 secret,所有调用通过 vault gateway,gateway 在 Agent 想用 secret 时做 deterministic approval。Vault 用 Rust 写,放在 Agent 和外部 API 之间作为 deterministic 代理层。这个 vault 设计在最初几个月就获得了不错的反馈,大部分需求来自 autonomous agent(Hermes、OpenClaw、NanoClaw)的个人用户和团队用户。
但用户的需求很快超出 vault 本身。人们他们需要的不只是 secrets 管理,还需要整个 agent harness——他们要的是一个完整的"团队级 Agent 平台",而 vault 只是其中一个组件。OneCLI 团队意识到,与其让每个团队都重复搭建一套 agent harness + vault,不如直接把这个 harness 整体开源出来,让团队可以快速采用。这就是 OneCLI 作为 agent harness for teams 的定位转变。
二、OneCLI 的核心架构和能力
OneCLI 作为完整的 agent harness,提供四件核心能力。
第一件,sandboxed agent——一键启动带完整 OneCLI 能力的 Agent,这些能力包括连接 GitHub 账户、Gmail、Notion、Dropbox 等常见 SaaS。用户不用单独配置每个集成,Agent 在 sandbox 里跑,所有调用经过 vault gateway。
第二件,deterministic human-in-the-loop approval——在 chat 界面里就能完成审批,适合发邮件、删 Linear ticket 这种必须 100% 控制的操作。这条能力是关键创新——传统 HITL 是 pop-up dialog,跳出 Agent 工作流,用户必须切换 context 去审批,体验很差。OneCLI 把审批直接嵌在 chat 流里,Agent 发出请求、用户在 chat 里 reply "approve" / "deny",整个交互在同一个 context 里完成。
第三件,team policy in one place——一个地方管理所有 Agent 的策略,在 workspace 内统一执行。team admin 可以定义 "哪些操作需要审批、哪些操作自动通过、哪些操作禁止执行" 等规则,所有 Agent 都强制遵守。这条能力把 Agent 行为从个人配置升级为组织级配置。
第四件,global connections——team 级别的共享 LLM keys 或 service accounts,个人 Agent 不持有。Anthropic API key、OpenAI API key、Google Cloud service account 这些敏感 credential 都在 team vault 里,Agent 通过 vault gateway 调用,不直接接触真实 key。
OneCLI 的 agent engine 用的是 jcode,jcode 是 agent-loop 的核心实现。创始团队说 jcode 比之前的方案"体验更好、Agent 更聪明更快",这部分细节在 HN 帖里没有展开,但暗示 jcode 在 tool orchestration、context management、loop control 这几个维度有专门优化。
整套系统可以跑在企业自己的 infra 上,Apache-2.0 完全开源,几分钟可以自托管或上云。安全不是承诺,是企业可以自己 verify 的代码。这条定位对 enterprise 市场至关重要——企业 IT 不愿意把 Agent 平台交给 black box SaaS,OneCLI 把代码完全开源正好对症。
三、OneCLI 解决了 Agent 落地的三个根本问题
OneCLI 的设计哲学直指企业 Agent 落地的三个根本问题。
第一个根本问题是 secret 管理。Agent 需要调用外部 API、需要访问内部系统,这些都要求 credential。但 Agent 直接持有 credential 会引发"写进 memory、写进日志、被 prompt injection 偷走"三个风险。OneCLI 通过 vault + gateway 把 secret 隔离,Agent 从来不持有真实 credential,所有调用通过 deterministic gateway,gateway 在调用时做审批或者注入短期凭证。这条设计把"secret 泄漏"的风险从 Agent runtime 转移到 vault gateway,而 vault gateway 是 deterministic 代码,prompt injection 影响不到。
第二个根本问题是 HITL 的体验。Agent 跑长任务时经常需要中间步骤的审批,比如要发一封重要邮件、要删除一个 production ticket。传统 HITL 用 pop-up dialog,跳出 Agent 工作流,用户必须切换 context 去审批,体验差到很多用户直接放弃审批,让 Agent 自动跑。OneCLI 把审批嵌入 chat 流,Agent 发出请求时用户在 chat 里直接 reply "approve" 或 "deny",整个交互在同一个 context 里完成。这条设计让 HITL 真正可用,而不是"理论上应该有但实际都跳过"的装饰。
第三个根本问题是 team-level policy enforcement。Agent 平台如果让每个员工自己配置 Agent 的安全策略,会出现"A 部门 strict、B 部门 lax、C 部门没配"的状态,组织级安全合规形同虚设。OneCLI 把 policy 提到 team admin 层面统一管理,workspace 内所有 Agent 强制执行同一套规则。这条设计让 Agent 平台的安全合规可以纳入企业现有的 compliance 流程,而不是一个脱离组织管控的孤岛。
四、把 OneCLI 放进 Agent Harness 产品矩阵
把 OneCLI 和同时期几个独立产品放在一起,可以看到企业 Agent Harness 正在分裂成清晰的层次。
machine0 解决的是 infrastructure layer——Agent 跑在哪里。machine0 给的是持久化 VM、CLI + MCP 接口、suspend/resume/snapshot、Profile 注入。OneCLI 解决的是 secret layer——Agent 怎么用 secret。OneCLI 给的是 vault + gateway + HITL approval。
Ridge 解决的是 resource access layer——Agent 怎么访问资源。Ridge 给的是统一 capability contract、MCP + CLI + Python 三接口、scoped access、stream-based transfer。
extensible-mcp 解决的是 policy enforcement layer——policy 在哪一层执行。extensible-mcp 给的是 model 之外的 deterministic proxy、human approval 密码学可验证、policy 用 Lean proof assistant 写成数学证明。
Security Cards 解决的是 knowledge injection layer——Agent 写代码时知道 library 怎么用才安全。Security Cards 给的是 library-specific 的安全指引、skill 安装、按需加载。
BaxBench 解决的是 evaluation layer——怎么量化 Agent 的安全性能。BaxBench 给的是 392 个任务、14 个 framework、6 种语言的标准化 benchmark。
Argus Security 解决的是 vulnerability detection layer——AI 主动挖漏洞。Argus 给的是 SFT + RL with verifiable rewards against actual exploit checks 训练的专用 pen-test 模型。
GitSpawn 揭示了 trust chain layer 的根本问题——所有主流 Agent 共享同一类 git 配置命令执行漏洞。Manifold Security 给的是持续监测和系统性披露。
七个层次,每个层次都有独立的产品形态,每个层次解决的问题都正交。任何一层缺失,Agent 平台都会暴露严重短板——没有 infrastructure 层,Agent 跑 1 小时就被销毁;没有 secret 层,Agent 持有 secret 被 prompt injection 偷走;没有 resource access 层,Agent 每次拼胶水代码;没有 policy enforcement 层,policy 在 prompt 里被改写;没有 knowledge injection 层,Agent 写代码不知道 library 安全用法;没有 evaluation 层,所有安全改进都是盲改;没有 vulnerability detection 层,漏洞挖掘只能靠人;不重视 trust chain 层,Agent 在 startup 时被恶意仓库攻击。
五、企业 Agent Harness 权限边界的设计 checklist
把这七个层次合并,企业 Agent Harness 权限边界的设计应该满足如下 checklist。
第一条,Agent 跑在持久 VM 而不是 ephemeral sandbox。参考 machine0 设计,99.9% uptime 是底线,Profile 注入限制 Agent 启动时的能力。
第二条,Agent 通过 vault gateway 调用 secret 而不是直接持有。参考 OneCLI 设计,所有 secret 隔离到 vault,deterministic approval 在 chat 流里完成,team-level policy 在 workspace admin 集中配置。
第三条,Agent 通过 capability contract 访问资源而不是每个 backend 写一套 toolset。参考 Ridge 设计,MCP + CLI + Python 三接口,scoped access 带 expiry 和 revoke。
第四条,policy 必须在 model 之外执行。参考 extensible-mcp 设计,deterministic proxy 层强制执行,human approval 密码学可验证,policy 形式化验证。
第五条,Agent 必须有 library-specific 安全知识。参考 Security Cards 设计,knowledge 注入而非 hard code,skill 安装 + 按需加载。
第六条,任何模型/Agent 升级前必须跑 BaxBench 等安全 benchmark。72.3% insecure-and-correct 降幅必须能复现或超过。
第七条,任何重要操作前必须做 HITL approval。approval 嵌在 chat 流里,deterministic,auditable,team policy 可配置。
第八条,任何 subprocess 调用必须进独立审计流。GitSpawn 揭示的教训——Agent 跑 git status 的 subprocess 时,fsmonitor 配置可能触发任意代码执行。
第九条,任何 Agent 决策必须 traceable 到具体 prompt 和 tool call。decision-log memory 是基础设施级别的要求,缺一个 Agent 平台都不能进生产环境。
第十条,所有上述能力必须开源可审计。Apache-2.0 这种 license 是底线,black box SaaS 不能作为企业 Agent 平台的唯一形态。
六、下一步:OneCLI 开启的 Agent Harness 开源浪潮
把 OneCLI 放到更大的图景里看,OneCLI 开启了 Agent Harness 开源浪潮。早期 Coding Agent 都是 closed SaaS 形态(ChatGPT、Claude.ai、Gemini),开发者只能在 web UI 里用,看不到底层;最近 6 个月开始转向开源 Harness(OneCLI、machine0、Ridge、extensible-mcp、Security Cards),开发者可以自托管、审计代码、按业务定制。
这种转变对 enterprise 市场是关键转折点。任何 closed SaaS 形式的 Agent 平台在企业市场都会遭遇合规审计质疑——"代码不可见"是金融、医疗、政府客户的硬性排除项。开源 Harness 让 Agent 平台的代码审计成为可能,企业 IT 可以自己 grep 代码、跑漏洞扫描、确认没有 telemetry 上传、验证 credential 管理符合企业合规要求。
接下来一年内,OneCLI 这类开源 Agent Harness 会成为 enterprise 部署的默认起点。closed SaaS 会退守到"个人用户、demo 体验、消费市场"这种边缘场景;enterprise 客户会优先采用开源 Harness,在自己的 infra 上自托管,或者通过 AWS/Azure/GCP 的 marketplace 拿到托管版本。
回到一开始的问题——OneCLI 把"sandboxed agent harness for teams"作为 Apache-2.0 项目开源,加上同时期 machine0 / Ridge / extensible-mcp / Security Cards 等独立产品的设计哲学,把企业 Agent Harness 权限边界的工程化新基线完整地呈现出来。剩下的是企业 IT 在落地时把七层都做对,把 Agent 平台从 closed SaaS 升级为 open Harness。这是 2026 年下半年 Agent 行业走向成熟的标志性事件,也是企业 Agent 真正能承担关键业务的入场券。