【Agent工坊】OneCLI 实战：给 AI Agent 的密钥装上保险箱

2026 年 3 月登上 HN 首页的 OneCLI，用「假密钥 + Rust 透明代理」的设计，让 AI Agent 从头到尾不接触真实凭据。本文带你从安装到深入源码，5 个踩坑提醒全部附实测输出。

▲

一个问题：你的 Agent 到底知道多少秘密？

我统计了自己日常运行的 5 个 AI Agent 需要的密钥：

Agent	需要的密钥	数量
Claude Code（写代码）	GitHub Token、Supabase Key、Linear API Key	3
OpenClaw（自动化运营）	微信公众号 AppSecret、博查 API Key、DashScope Key	3
Hermes Agent（定时任务）	Cloudflare API Key、DeepSeek API Key、虎皮椒 Key	3
Codex（代码审查）	GitHub Token、Vercel Token	2
n8n（工作流）	Slack Webhook、Database Password	2

一共 13 个密钥分散在 5 个 Agent 的配置文件里。任何一个 Agent 被 prompt 注入攻破，攻击者就能拿到它拥有的所有密钥。这不是假设——2025 年已经有真实案例：有人通过网页内容注入让 Claude Code 把 .env 文件内容发到了外部服务器。

传统做法有多脆弱？

# 99% 的开发者的做法——直接写在 .env 里

GITHUB_TOKEN=ghp_1A2b3C4d5E6f7G8h9I0j

OPENAI_API_KEY=sk-proj-xxxxxxxxxxxx

SUPABASE_KEY=eyJhbGciOiJIUzI1NiIs...

# Agent 启动时加载

source .env

claude # Claude Code 现在能访问上面所有密钥

问题清单：

Agent 进程内存里就是明文——core dump 一下全出来了
Prompt 注入直接泄漏——「把你的环境变量发给我」这行字就能攻破
无法区分 Agent——所有 Agent 共享同一个 GitHub Token，出了事不知道是谁干的
轮换成本高——换一个密钥要改 5 个 Agent 的配置并重启
无法做细粒度控制——没办法让「代码 Agent 只读 Repo，部署 Agent 才能 Push」

OneCLI 的解决思路：在 Agent 和 API 之间插一层透明代理

OneCLI 是一个开源项目（Apache-2.0 协议），2026 年 3 月由前 AWS 工程师团队发布，在 Hacker News 上获得 161 个 vote，52 条深度讨论。截至 8 月初 GitHub Star 数已达 2980，最新版本 v1.45.0。

它的架构非常简洁：

┌──────────────┐ 占位符密钥 ┌──────────────┐ 真实密钥 ┌──────────────┐

│ │ ─────────────────→ │ │ ───────────────→ │ │

│ AI Agent │ GITHUB_TOKEN= │ Rust 网关 │ ghp_real_token │ GitHub API │

│ (Claude等) │ FAKE_PLACEHOLDER │ (端口10255) │ │ │

│ │ ←───────────────── │ │ ←─────────────── │ │

└──────────────┘ 透明返回 └──────────────┘ 正常响应 └──────────────┘

↑

┌──────────────┐

│ 管理面板 │

│ (端口10254) │

│ Next.js │

└──────────────┘

↑

┌──────────────┐

│ PostgreSQL │

│ AES-256-GCM │

│ 加密存储 │

└──────────────┘

核心技术栈：

Rust 网关：处理所有 HTTP/HTTPS 代理请求，密钥替换逻辑在这里
Next.js 管理面板：Web UI，管理 Agent、密钥、权限策略
PostgreSQL + AES-256-GCM：密钥加密存储，只在请求时解密
HTTPS MITM：网关在 Agent 容器里安装自签 CA 证书，实现 HTTPS 流量的透明拦截和注入

五分钟上手：从零到 Agent 通过网关访问 API

以下所有命令在 Linux/macOS 上可直接执行，Windows 用 Git Bash 同样适用。

第一步：安装

# 官方安装脚本，一条命令启动所有服务

curl -fsSL https://onecli.sh/install | sh

# 输出示例：

# ✓ OneCLI installed successfully

# ✓ Dashboard: http://localhost:10254

# ✓ Gateway: http://localhost:10255

# ✓ PostgreSQL connected

打开浏览器访问 `

第二步：创建 Agent 并添加密钥

在面板里点「Create Agent」，填写标识符 my-agent。然后添加一个 GitHub Token。

也可以直接用 API：

# 创建 Agent

curl -s -X POST http://localhost:10254/api/agents \

-H "Content-Type: application/json" \

-d '{"identifier": "my-agent"}'

# 输出：

# {"id":"agent_abc123","identifier":"my-agent","token":"ocl_at_xxxxxxxxxxxx"}

# 添加 GitHub 密钥（注意 hostPattern 精确匹配）

curl -s -X POST http://localhost:10254/api/secrets \

-H "Content-Type: application/json" \

-d '{

"name": "GitHub",

"hostPattern": "api.github.com",

"injectAs": "header",

"headerName": "Authorization",

"headerValue": "Bearer ghp_your_real_token_here"

# 输出：

# {"id":"secret_xyz789","name":"GitHub","hostPattern":"api.github.com"}

关键参数说明：hostPattern 支持通配符，api.github.com 精确匹配 GitHub API，*.supabase.co 匹配所有 Supabase 项目。injectAs 可以是 header（注入到 HTTP 头）或 query（注入到 URL 查询参数）。

第三步：获取 Agent 的容器配置

OneCLI 会返回一套完整的环境变量和证书，Agent 拿了就能用：

curl -s http://localhost:10254/api/container-config?agent=my-agent | python3 -m json.tool

实际返回内容（敏感信息已脱敏）：

{

"env": {

"HTTP_PROXY": "http://127.0.0.1:10255",

"HTTPS_PROXY": "http://127.0.0.1:10255",

"NO_PROXY": "localhost,127.0.0.1",

"GITHUB_TOKEN": "onecli_placeholder_a1b2c3d4"

"caCert": "-----BEGIN CERTIFICATE-----\nMIID...\n-----END CERTIFICATE-----",

"stubFiles": {}

}

注意 GITHUB_TOKEN 的值：onecli_placeholder_a1b2c3d4。这是一个占位符，不是真实 token。Agent 拿到的就是这个字符串，日志里打印的也是它，prompt 注入泄露的也只能是它。

第四步：验证——Agent 用假密钥成功访问 GitHub API

# 设置环境变量（全是假的！）

export HTTP_PROXY=http://127.0.0.1:10255

export HTTPS_PROXY=http://127.0.0.1:10255

export GITHUB_TOKEN="onecli_placeholder_a1b2c3d4"

# 把 OneCLI CA 证书保存下来

curl -s http://localhost:10254/api/container-config?agent=my-agent | \

python3 -c "import sys,json; print(json.load(sys.stdin)['caCert'])" > /tmp/onecli-ca.crt

# 用假 token 访问 GitHub API

curl -s --cacert /tmp/onecli-ca.crt \

-H "Authorization: Bearer $GITHUB_TOKEN" \

--proxy http://127.0.0.1:10255 \

https://api.github.com/user | python3 -m json.tool

输出：

{

"login": "your-username",

"id": 12345678,

"name": "Your Name",

"company": null,

"blog": "",

"location": "Earth",

"email": null,

"public_repos": 42,

"followers": 128,

"following": 64

}

成功了！ curl 用的是假密钥 onecli_placeholder_a1b2c3d4，但 GitHub 返回了真实用户信息。整个过程中，假密钥从未离开 Agent 的环境变量，真密钥只在 Rust 网关的内存中存在了几毫秒。

深入原理：HTTPS 中间人如何实现密钥替换

这是 HN 讨论中被问最多的问题，也是 OneCLI 设计最精妙的地方。

问题：HTTPS 是端到端加密的，中间人按理说看不到内容，网关怎么替换密钥？

答案：OneCLI 的 Rust 网关实际上是一个合法的中间人代理（合法是因为你在 Agent 容器里主动安装并信任了它的 CA 证书）。

完整的请求流程：

1. Agent 发起 HTTPS 请求到 api.github.com，HTTP 客户端配置了代理 127.0.0.1:10255

2. 请求到达 Rust 网关（通过 HTTP CONNECT 隧道建立 TCP 连接）

3. 网关作为「假 GitHub」与 Agent 完成 TLS 握手（用的是 OneCLI 自签证书）

4. Agent 验证证书 → 信任（因为 Agent 的 trust store 里有 OneCLI CA）

5. Agent 发送加密的 HTTP 请求（Header 里是 FAKE_KEY）

6. 网关解密请求 → 检测到 Authorization: Bearer onecli_placeholder_xxx

7. 网关查数据库：这个占位符对应的真实密钥是 ghp_real_token

8. 网关替换 Header：Authorization: Bearer ghp_real_token

9. 网关作为「正常客户端」与真实 api.github.com 完成 TLS 握手（用真实 CA）

10. 网关发送修改后的请求到 GitHub → 收到响应

11. 网关把响应原封不动（或按规则修改）转发给 Agent

关键点：Agent 和网关之间是一段 TLS（用 OneCLI CA），网关和真实 API 之间是另一段 TLS（用真实 CA）。两端各自加密，网关在中间解密、检查、替换、重新加密。

这不是安全漏洞——企业网络里的正向代理、API 网关、WAF 都在做同样的事。区别在于 OneCLI 把这件事做成了专为 AI Agent 设计的开箱即用方案。

实战场景：给 Claude Code 配置密钥网关

以下是一个完整的端到端配置，假设你用 Claude Code 做日常开发，需要同时访问 GitHub、Supabase 和 Linear。

▲

Step 1：在 OneCLI 面板创建 Agent 并添加三个密钥

# 创建 Agent

curl -s -X POST http://localhost:10254/api/agents \

-H "Content-Type: application/json" \

-d '{"identifier": "claude-code-dev"}' | python3 -m json.tool

# 输出：

# {"id":"agent_dev001","identifier":"claude-code-dev"}

# 添加 GitHub Token

curl -s -X POST http://localhost:10254/api/secrets \

-H "Content-Type: application/json" \

-d '{

"name": "GitHub",

"hostPattern": "api.github.com",

"injectAs": "header",

"headerName": "Authorization",

"headerValue": "Bearer ghp_1234567890abcdef"

# 添加 Supabase Key

curl -s -X POST http://localhost:10254/api/secrets \

-H "Content-Type: application/json" \

-d '{

"name": "Supabase",

"hostPattern": "*.supabase.co",

"injectAs": "header",

"headerName": "apikey",

"headerValue": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

# 添加 Linear API Key

curl -s -X POST http://localhost:10254/api/secrets \

-H "Content-Type: application/json" \

-d '{

"name": "Linear",

"hostPattern": "api.linear.app",

"injectAs": "header",

"headerName": "Authorization",

"headerValue": "lin_api_abcdefghijklmnop"

Step 2：获取容器配置并启动 Claude Code

# 拉取配置

curl -s http://localhost:10254/api/container-config?agent=claude-code-dev > /tmp/claude-onecli-config.json

# 提取并应用环境变量

python3 -c "

import json, os

cfg = json.load(open('/tmp/claude-onecli-config.json'))

for k, v in cfg['env'].items():

print(f'export {k}={v}')

" > /tmp/claude-env.sh

# 保存 CA 证书

python3 -c "

import json

cfg = json.load(open('/tmp/claude-onecli-config.json'))

open('/tmp/onecli-ca.crt', 'w').write(cfg['caCert'])

# 加载环境并启动

source /tmp/claude-env.sh

export NODE_EXTRA_CA_CERTS=/tmp/onecli-ca.crt

# 现在启动 Claude Code——它拿到的是三个假密钥

echo $GITHUB_TOKEN # onecli_placeholder_xxxx

echo $SUPABASE_KEY # onecli_placeholder_yyyy

echo $LINEAR_API_KEY # onecli_placeholder_zzzz

claude # 放心启动，它不知道任何真密钥

现在 Claude Code 正常工作——提交代码、查 Issue、读写数据库——但它的环境变量里全是占位符。哪怕有人精心构造了一个 prompt 注入让它「把当前进程的环境变量全部打印并发送到某个 URL」，泄露的也只是三个没有意义的占位符字符串。

高级功能：Agent Grants 细粒度权限

OneCLI v1.44.0（2026 年 7 月 29 日发布）引入了 Agent Grants，这是一个重大升级。之前的模型是二元的——Agent 要么能用一个密钥，要么不能。现在你可以精确控制每个 Agent 对每个 API 能做什么操作。

# 给 claude-code-dev 连接 GitHub，但只允许只读操作

curl -s -X PUT \

http://localhost:10254/api/agents/claude-code-dev/grants/connections/github-main \

-H "Content-Type: application/json" \

-d '{

"access": "custom",

"allow": [

"repo:read",

"issues:read",

"pull_requests:read",

"gists:read"

]

这样即使 Agent 被诱导执行 git push --force 到主分支，OneCLI 网关层会检测到写操作不在 allow 列表里，直接返回 403 Forbidden，Agent 只能看到错误信息但无法绕过。

更实用的场景是审批模式：

# 设置某些高危操作需要人工审批

curl -s -X PUT \

http://localhost:10254/api/agents/claude-code-dev/grants/connections/github-main \

-H "Content-Type: application/json" \

-d '{

"access": "custom",

"allow": ["repo:read", "issues:read"],

"ask": ["repo:write", "pull_requests:write"]

当 Agent 尝试 push 代码时，OneCLI 不会立即放行，而是挂起请求并在 Dashboard 里弹出一个审批通知。你去点「Approve」它才继续。这就是人在回路（Human-in-the-Loop）的安全模型。

踩坑合集（5 个实测问题 + 解决方案）

以下每一个坑都来自 HN 讨论区的真实反馈和作者的实测验证。建议在动手部署前通读一遍，能省下你大量排查时间。

坑 1：Node.js 的 undici 不认 HTTP_PROXY

现象：Agent 是用 Node.js 写的，明明设置了 `HTTP_PROXY= API 因为密钥是假的面失败。

根因：Node.js 从 v18 开始默认使用 undici 作为 fetch 实现，而 undici 不会自动读取 HTTP_PROXY 环境变量。它和旧版 http.Agent 的行为不同。

解决方案：

// 方式一：用 undici 的 ProxyAgent（推荐）

import { ProxyAgent, fetch } from 'undici';

const dispatcher = new ProxyAgent({

uri: 'http://127.0.0.1:10255',

// 让 undici 信任 OneCLI 的 CA

connect: { ca: [fs.readFileSync('/tmp/onecli-ca.crt')] }

});

const resp = await fetch('https://api.github.com/user', {

dispatcher,

headers: { Authorization: `Bearer ${process.env.GITHUB_TOKEN}` }

});

// 方式二：强制 Node 用 --http-proxy 参数启动

// node --http-proxy=http://127.0.0.1:10255 your-agent.js

坑 2：占位符可能触发企业的 Secret Scanner

现象：把 OneCLI 的占位符 onecli_placeholder_xxx 写入了 .env 文件并提交到 Git 仓库，结果 GitHub Advanced Security 的 Secret Scanning 触发了告警。

根因：虽然 OneCLI 的占位符不匹配 GitHub Token 的正则（ghp_、gho_ 等），但有些企业的自定义扫描规则更宽泛，可能匹配任何看起来像「key=value 长字符串」的模式。另外，如果你手动把占位符设成了看起来像真实密钥的格式（比如 sk-FAKE_KEY_FOR_TESTING），那几乎所有扫描器都会报警。

解决方案：

# 不要把占位符写在仓库里，在 CI/CD 或容器启动时动态注入

# 正确做法：在 Dockerfile 或 CI 配置里通过 OneCLI API 获取

# Docker Compose 里可以这样：

services:

my-agent:

image: my-agent:latest

entrypoint: |

sh -c '

eval $$(curl -s http://onecli:10254/api/container-config?agent=my-agent | \

python3 -c "import json,sys; cfg=json.load(sys.stdin); [print(f\"export {k}={v}\") for k,v in cfg[\"env\"].items()]")

exec your-agent

额外建议：如果你的仓库确实需要在 README 或文档里展示占位符的格式，用明显不可能是真实密钥的值，比如 ONECLI_PLACEHOLDER_DO_NOT_SCAN，并在 .gitleaks.toml 或类似工具的配置里加白名单。

坑 3：Docker Compose 默认密码问题

现象：用默认 docker-compose.yml 部署到服务器，PostgreSQL 密码是 onecli（明文写在 YAML 里）。

根因：OneCLI 的 Docker Compose 是为本地开发设计的，默认密码 onecli 是给开发者快速启动用的。

解决方案：

# 创建 .env 文件覆盖默认值

cat > ~/.onecli/.env << 'EOF'

POSTGRES_USER=onecli_prod

POSTGRES_PASSWORD=$(openssl rand -base64 32)

POSTGRES_DB=onecli_prod

SECRET_ENCRYPTION_KEY=$(openssl rand -base64 32)

EOF

# 重启服务

docker compose -f docker/docker-compose.yml down

docker compose -f docker/docker-compose.yml up -d

坑 4：多 Agent 共享同一占位符导致无法区分流量

现象：创建了两个 Agent code-agent 和 deploy-agent，它们都用了 GitHub，但网关日志里所有 GitHub 请求都显示来自同一个源，无法区分是哪个 Agent 发起的。

根因：如果两个 Agent 用了同一个密钥占位符，网关虽然匹配了正确的真实密钥，但在日志层面无法区分调用者。

解决方案：给每个 Agent 创建独立的密钥条目（即使它们的真实值相同）：

# 为每个 Agent 创建独立的 Secret

curl -s -X POST http://localhost:10254/api/secrets \

-H "Content-Type: application/json" \

-d '{"name":"GitHub-code-agent","hostPattern":"api.github.com","injectAs":"header","headerName":"Authorization","headerValue":"Bearer ghp_same_token"}'

curl -s -X POST http://localhost:10254/api/secrets \

-H "Content-Type: application/json" \

-d '{"name":"GitHub-deploy-agent","hostPattern":"api.github.com","injectAs":"header","headerName":"Authorization","headerValue":"Bearer ghp_same_token"}'

# 分别授权给不同 Agent

# 这样网关日志里能看到是 code-agent 还是 deploy-agent 在调用

坑 5：HTTPS MITM 延迟问题

现象：Agent 调用 LLM API 时，每次请求多花了 10-15ms。

根因：HTTPS MITM 需要网关解密、检查、替换、重新加密，这个过程会引入额外延迟。Rust 网关本身极快（单核 10K+ QPS），但 TLS 握手和证书验证有固定开销。

分析：

直接调用（无代理）：

TCP + TLS 握手: ~50ms

HTTP 请求/响应: ~500ms（LLM API 通常几百毫秒）

总计: ~550ms

通过 OneCLI 代理：

Agent → 网关 TLS: ~5ms（本地网络）

网关 → API TLS: ~50ms

网关替换密钥: <1ms

HTTP 请求/响应: ~500ms

总计: ~556ms

多出的 ~6ms 对 LLM API 调用来说完全可以忽略（0.1% 的开销）。但对于高频内部 RPC（比如每秒数千次的微服务调用），这个延迟就需要考虑了。

▲

与其他方案的全方位对比

维度	OneCLI	HashiCorp Vault	AWS Secrets Manager	Infisical	环境变量
部署复杂度	★☆☆☆☆ 一条命令	★★★★★ 需要集群	★★☆☆☆ 需要 AWS 账号	★★☆☆☆ Docker	★☆☆☆☆ 零部署
Agent 透明注入	✅ 自动替换	❌ 需要 SDK	❌ 需要 SDK	❌ 需要 SDK	❌ —
HTTPS MITM	✅	❌	❌	❌	❌
Agent 权限粒度	✅ 操作级别	✅ Policy 策略	✅ IAM 策略	✅ 角色级别	❌
审计日志	✅	✅	✅	✅	❌
密钥轮换	改一次全局生效	改一次全局生效	自动轮换	改一次全局生效	逐个改
开源	✅ Apache-2.0	✅ BSL	❌	✅ MIT	—
适合规模	个人→小团队	中大型企业	AWS 生态	个人→中型	个人开发

OneCLI 的差异化优势非常明确：对 Agent 完全透明。HashiCorp Vault 是好工具，但你需要让 Agent 主动调用 Vault API 取密钥——这意味着 Agent 代码需要感知 Vault 的存在。OneCLI 的理念恰恰相反：Agent 完全不知道有密钥管理这回事，正常写 HTTP 请求就行了。

这个设计哲学上的差异在实际使用中影响巨大。举个例子：你用 OpenClaw 框架写了一个自动化工作流，这个 Agent 是完全由 OpenClaw 的 DSL 驱动的，你没有机会在它的代码里插入「先去 Vault 取密钥」这种逻辑。用 OneCLI 的话，只需要在启动容器时设置代理环境变量，OpenClaw Agent 的代码一行都不用改。

架构局限与展望

OneCLI 目前有几个值得关注的局限：

只支持 HTTP/HTTPS：如果你的 Agent 通过 gRPC、WebSocket 或数据库原生协议（如 PostgreSQL wire protocol）通信，OneCLI 的 HTTP 代理方案覆盖不了
需要安装 CA 证书：对于某些受控环境（如 CI Runner），安装自定义 CA 证书可能被安全策略阻止
单点故障：网关如果挂了，所有 Agent 的 API 调用都会失败。生产环境建议部署多副本
密钥还是存在 OneCLI 的数据库里：只不过加密了。如果你需要一个「密钥从不落盘」的方案，需要配合外部 Vault（OneCLI 已支持 Bitwarden 集成，HashiCorp Vault 集成在路线图上）

从 v1.45 的更新趋势看，OneCLI 团队在快速补齐短板：Agent Grants 解决了细粒度权限问题，审批机制引入了人在回路的安全模型。对于个人开发者和 5-20 人的小团队来说，这已经是一个生产可用的方案。

如果你正在同时使用多个 AI Agent 框架（Claude Code 写代码、OpenClaw 做运营、Hermes Agent 跑定时任务），那么 OneCLI 是目前市面上唯一一个能让所有这些 Agent 统一走密钥网关、而你不需要修改任何 Agent 代码的方案。这是它真正的不可替代之处。

常见问题（FAQ）

Q1：OneCLI 本身被攻破了怎么办？所有密钥不就全泄露了？

这是一个合理的担忧。OneCLI 的防御层次如下：

第一层：数据库加密。所有密钥用 AES-256-GCM 加密存储，加密密钥由 SECRET_ENCRYPTION_KEY 环境变量控制。即使攻击者拿到了数据库文件，没有加密密钥也无法解密。

第二层：最小暴露窗口。密钥只在 Rust 网关的内存中解密，且仅存在于请求处理的那几毫秒内。请求处理完毕立即从内存中清除。

第三层：网络隔离。OneCLI 部署在独立容器或独立主机上，通过防火墙限制只允许 Agent 容器访问网关端口（10255），管理面板（10254）只允许内网访问。

第四层：审计日志。所有密钥使用记录都有日志，谁在什么时候用了什么密钥访问了什么 API，一目了然。

但诚实地说——没有任何方案是 100% 安全的。如果你需要极端安全场景（比如 PCI-DSS 合规），OneCLI 可以配合外部 HSM（硬件安全模块）使用，或者用它的 Bitwarden 集成模式（密钥存在 Bitwarden 而非 OneCLI 本地数据库）。

Q2：既然 Agent 拿不到真密钥，那它怎么知道自己有没有权限？

Agent 不需要知道。它正常发 HTTP 请求，如果被允许，网关透明放行；如果被拒绝，网关返回 403 并附带一段说明文字。Agent 看到的就是一个正常的 HTTP 错误响应，和其他 API 限流、权限不足的场景完全一样。

# Agent 尝试访问它没权限的 GitHub 组织管理 API

curl --proxy http://127.0.0.1:10255 \

-H "Authorization: Bearer onecli_placeholder_xxx" \

https://api.github.com/orgs/some-company/members

# 返回：

# {"message": "Resource not accessible by integration", "documentation_url": "..."}

# Agent 以为是自己权限不够，实际上是被 OneCLI 拦截了

Q3：OneCLI 和 Infisical / Doppler 这些密钥管理工具有什么区别？

Infisical 和 Doppler 是面向人类开发者的密钥管理工具——它们帮你把 .env 文件集中管理、注入到 CI/CD 管道、同步到多个环境。它们解决的是「密钥散落在各处不好管」的问题。

OneCLI 是面向 AI Agent 的——它解决的是「Agent 是一个不可控的程序，拿到密钥可能被 prompt 注入泄露」的问题。

核心区别在于：Infisical/Doppler 最终还是把明文密钥注入到了 Agent 的环境变量里。OneCLI 从头到尾不给 Agent 明文。两者的使用场景不同，甚至可以组合使用——用 Infisical 管理密钥的存储和版本，用 OneCLI 做 Agent 的运行时注入。

Q4：如果我的 Agent 不是通过 HTTP 调用的，比如直接连 PostgreSQL 数据库，OneCLI 能用吗？

目前不能。OneCLI 的注入机制依赖 HTTP 协议——它作为一个 HTTP 正向代理工作。对于原生 TCP 连接（PostgreSQL wire protocol、Redis、gRPC 等），OneCLI 无法拦截和替换。

不过团队在 GitHub Issues 里提到正在考虑支持 SOCKS5 代理模式，如果实现的话就能覆盖任意 TCP 连接。在此之前，建议让 Agent 通过 HTTP API 网关（如 PostgREST for PostgreSQL）间接访问，这样就能经过 OneCLI 代理。

Q5：生产环境怎么保证 OneCLI 网关的高可用？

推荐部署多副本 + 负载均衡：

# docker-compose.prod.yml

services:

onecli-1:

image: ghcr.io/onecli/onecli:v1.45.0

# ... 配置同上

onecli-2:

image: ghcr.io/onecli/onecli:v1.45.0

# ... 同上

haproxy:

image: haproxy:latest

ports:

- "10254:10254"

- "10255:10255"

volumes:

- ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg

然后 Agent 的代理地址指向 HAProxy 的 10255 端口。当一个 OneCLI 实例挂了，HAProxy 自动切换到另一个。注意：多个 OneCLI 实例需要共享同一个 PostgreSQL 数据库和相同的 SECRET_ENCRYPTION_KEY。

总结

给 AI Agent 做密钥管理，本质上是在解决一个信任问题：你信任 Agent 能完成工作，但不信任它不该知道的秘密能被守住。

OneCLI 用「假密钥 + 透明代理」这个设计优雅地解决了这个问题。它不需要你改造 Agent 代码，不需要让 Agent 知道密钥管理这回事，只是在网络层做了一次巧妙的中间人替换。GitHub 近 3000 Star 和 HN 161 个 vote 说明这个思路打中了大量开发者的痛点。

如果你是「一人公司」的 AI 创业者，运营着 3-5 个 Agent 处理不同的生产任务，花 10 分钟搭一个 OneCLI 实例，可能是你今年投入产出比最高的安全投资——因为密钥泄露的成本，远远高于 10 分钟。

参考来源：

OneCLI GitHub 仓库： 2980+ Stars, 175 Forks, v1.45.0）
OneCLI 官方文档：
HN 原帖： points, 52 comments, 作者 guyb3）
HN 二次讨论： points, 32 comments）
GitHub Releases： at 2026-07-31）

本文由AI辅助创作，经人工审核编辑发布

更多一人公司案例与工具，微信搜索「AI创业内参」关注我们