OneCLI 这玩意儿解决的痛点很具体
几个落地细节值得注意：
一、网关层做强制策略，不是靠提示词乞求
管理员在控制台配策略：哪个员工能调哪个 endpoint、速率限制多少、删除 Linear ticket 必须人工批准、发邮件要二次确认。这些规则编译成网关层的 WASM 插件或 Rust 规则引擎，请求过网关时强制匹配，模型层面完全绕不开。Demo 里那个「在聊天框里弹批准按钮」的交互，本质是网关把需要审批的动作挂起、回写会话上下文，用户点确认后网关再放行——全程 Agent 只看到「等待审批」状态，根本拿不到真凭证。
二、团队级连接池，避免重复授权
公司级配一次 GitHub App、Google Workspace service account、共享 LLM Key，下面每个员工的 Agent 复用，权限边界靠网关按身份切。不用每人去 OAuth 一遍，也不用把 refresh token 分发到几十个沙箱里。
三、自托管部署真·开箱即用docker compose up -d 起控制平面 + 网关 + Postgres + Redis，配个域名加 TLS，几分钟跑通。没强制绑定他们的云，数据全在自己 VPC。企业版只加了 SSO/审计日志/高可用部署模板，核心能力全在社区版。
四、Agent 引擎用 jcode（原 OpenClaw 核心循环）
他们没重造轮子，直接接 jcode 做规划+工具调用循环。实测比自己裸写 ReAct 循环稳，工具调用失败重试、上下文压缩、多步规划都有现成实现。
踩过的坑提醒下：
- 网关层自定义策略目前只能写 Rust/WASM，Go/Python 插件机制还在规划，想接自家内部系统得会改网关代码
- 沙箱默认用 gVisor，启动冷启动 1.2-1.8s，高频调用场景建议预热池
- 审批流目前只支持同步阻塞等待，异步回调（Slack/钉钉推送审批）还没合并主分支
源码在这：github.com/onecli/onecli（别光看 README，直接进 gateway/ 和 policy/ 目录看规则引擎实现更直观）
有同学在生产环境跑过类似「网关注入凭证 + 策略强制」架构的？想听听你们怎么处理审批流的异步化、以及网关层可观测性怎么做的。
