在 OpenClaw 中，如何正确管理 Token（工程实践篇）

副标题：别再把 API Key 塞进 Prompt 了

为什么 Token 管理是 AI 工程的“地基”

大多数 AI 项目的失败，不是模型不行，而是：

• Token 泄露
• 权限过大
• 无法撤销
• Prompt 被复制即系统失控

Prompt ≠ 配置 ≠ 凭证。

OpenClaw 的核心设计：Agent 不配钥匙

在 OpenClaw 中：

• Agent = 决策者
• Tool = 执行者
• Token = Tool 的私有资产

你永远不需要、也不应该对模型说：

“这是我的 API key，请帮我调用……”

正确姿势（推荐工程实践）

Step 1：把 Token 放进 Secret Store

bash export OPENAI_API_KEY=sk-xxxx

或通过 OpenClaw UI / CLI 注入。

Step 2：Tool 声明能力，而不是 Token

json { "tool": "github.read_repo", "requires": ["GITHUB_READ_TOKEN"] }

Agent 只知道：

“我可以读仓库”

而不知道 Token 长什么样。

Step 3：让 Agent 永远看不到 Key

如果你的 Agent 能“复述”你的 token，

✅ 那不是 feature， ❌ 那是一个 严重安全 bug。

常见反模式（请避免）

• ❌ 把 token 写进 system prompt
• ❌ 让用户在对话中输入 key
• ❌ 一个 key 管所有服务
• ❌ token 和业务逻辑强耦合

一个简单判断标准

如果你愿意把 prompt 发到 Twitter，
那它里面就不该有 token。

总结

OpenClaw 的 Token 管理不是“更安全”，

而是 从结构上避免犯错：

• Agent 负责决策
• Tool 负责执行
• Token 只存在于 Tool / Runtime

当 Prompt 被复制、被分享、被二次利用时，

你的系统依然是安全的。

喜欢这篇文章？
🐦 点击这里一键分享到 X (Twitter)