你的 Agent 还在裸奔调 API？这篇文章可能会改变你的做法。
2026 年 3 月底，飞书开源了飞书 CLI，一个多月拿了 1 万+ star。这个项目的意义不只是"把飞书功能搬到命令行"——它第一次系统性地展示了企业系统如何以「Agent 友好」的方式开放能力。文档、审批、日历、消息，全变成可组合的命令，大模型直接当函数调用。
但当你真想把企业内部的业务 CLI 接入 Claude Code、OpenClaw 这些 Agent 框架时，第一个撞上的墙不是接口不够用，而是——鉴权。
货拉拉技术团队最近公开了他们的解法：一套面向 Agent Skill 的 CLI/SSO 鉴权体系。核心卖点三个：Token 不落盘不暴露、多用户隔离、飞书一键授权无感知。我读完了他们的技术方案，觉得这套架构的设计思路值得每个在做 Agent 集成的人认真看看。
在 Web 时代，SSO 鉴权天然是"人在浏览器前"的模式：跳转到 SSO 平台 → 用户手动登录 → 回调拿 Token → 后续请求带着 Token。整个流程依赖人类的交互能力。
Agent 不行。Agent 没有浏览器，不会点按钮，无法完成交互式登录。
早期实践中最常见的做法是"预置 Token"：开发者手动完成 SSO 登录，把长期 Token 写进环境变量、配置文件、甚至硬编码到代码里。这在个人玩具项目里没问题，但在企业环境下是灾难：
问题一：Token 大面积暴露。Token 以明文形式存在于 .env、config.yaml、shell history、/proc/*/environ 等任何你能想到的地方。任何能读取文件系统的攻击者都能拿到。
问题二：多人共享沙箱身份混乱。一个团队的 Agent 沙箱里，产品同事 A 登录后存了 A 的 Token，研发同事 B 紧接着调用——没有用户隔离的话，B 的请求用的是 A 的身份。审计日志显示是 A 在操作，但实际是 B。权限控制形同虚设。
问题三：无法追溯具体 Agent 行为。当 Agent 代替人做了某个操作，审计系统只知道"这个 Token 做了这件事"，不知道是哪个用户、在什么对话上下文中、让哪个 Agent 执行的。出了问题，根本没法溯源。
这三个问题指向同一个结论：必须为 Agent 设计一套原生的、脱离浏览器依赖的、多人隔离且防泄露的 SSO 鉴权体系。
货拉拉的方案把鉴权拆成四个组件，各司其职：
MERMAID_BLOCK_0
sso-cli：独立的命令行工具，负责 SSO 登录编排、凭证安全存储、多用户隔离。不提供 Token 直接读取接口——你没法通过它拿到明文 Token。
业务 CLI：各业务团队开发的命令行工具（abtest-cli、trade-cli 等），Agent 实际调用的就是这些。它们不直接处理 Token，而是依赖 sso-sdk。
sso-sdk：内部私有包（Go），只有授权的模块才能引用。封装了从本地安全存储读取、解密 Token 的逻辑。
SSO 平台：公司统一单点登录服务，新增了 Agent 场景的 poll 授权模式——支持下发一次性 code，客户端轮询换 Token。
一次典型调用流：
这是整套方案里我觉得最精巧的部分。
主密钥（Master Key） 存储在操作系统的原生密钥链中：
- macOS → Keychain
- Linux → Secret Service / gnome-keyring
- Windows → Credential Manager / DPAPI
主密钥不落在任何普通文件里，读取受操作系统用户权限保护。sso-cli 只在需要加解密时从 keychain 取出主密钥，用完立即从内存擦除。
Token 存储走的是"密文文件"路线：用户通过 SSO 登录拿到 Token 后，sso-cli 将 user → token 的映射序列化、用主密钥加密、写入本地文件。没有主密钥，拿到密文也解不开。
这个设计的核心假设是：沙箱环境可能被任何人读取文件系统，但攻击者通常无法直接访问运行中进程的操作系统密钥链（除非已经提权）。这就形成了两道防线：
攻击者拿到密文文件 → 没有主密钥 → 无法解密
攻击者拿到主密钥 → 需要操作系统 keychain 权限 → 需要提权
攻击者同时拿到两者 → 文件内多用户 key 粒度隔离 → 只能解密特定用户的 Token
对比传统方案把 Token 塞进 .env 文件或者 export TOKEN=xxx——差距不是一点半点。
这是解决"多人共用沙箱"问题的关键设计。
每一轮 Agent 对话对应一个"当前用户"。Agent 框架启动子进程时，注入一组加密的临时环境变量来标识用户身份——不是明文用户名，而是经过对称加密的 salt。只有持有派生密钥的组件（sso-sdk）才能解密还原。
这组环境变量的安全属性：
/proc 的全局视图并发控制通过文件锁保护：读操作并发（解密幂等），写操作加排他锁（避免登录写入竞态）。
这个设计的巧妙之处在于：它把"用户隔离"和"Token 隔离"合并在了一套机制里——同一个加密文件，通过 key 粒度区分不同用户，而不是每个用户一个文件。简化了并发控制，也减少了密文数量。
安全做到位了，但初版的登录体验极其生硬：Agent 提示用户去浏览器登录 → 用户登录后回来说"好了" → Agent 触发轮询 → 拿到 Token 继续。
问题很明显：打断对话流，依赖用户主动告知，经常因为忘记触发轮询而超时。
Hook 模式彻底改变了这个体验：
用户唯一要做的就是点一下飞书卡片。整个流程对用户来说几乎是透明的。
降级方案也考虑了：飞书卡片不可用时，退化为普通文本消息发登录链接。消息可能留在聊天记录里，但链接本身不包含 Token，风险可控。
传统 SSO 只支持实时 Web 回调，无法适配 Agent 的异步场景。货拉拉推动了 SSO 平台的关键迭代——Agent Poll 授权模式。
流程是这样的：
安全设计要点：
这个 poll 模式的价值不只是服务于 Agent——它让 SSO 平台具备了支撑任何异步授权场景的通用能力。
业务 CLI 开发者不需要关心主密钥、加密文件、环境变量这些复杂细节。引入 sso-sdk，调用一个方法拿 Token，完事。
import "internal.example.com/sso-sdk"
func main() {
token, err := sso_sdk.GetToken()
if err != nil {
// Token 不存在或过期，返回特定退出码
// Agent 感知后触发 sso-cli 登录
os.Exit(42)
}
// 用 token 调用业务 API
callBusinessAPI(token)
}
sso-sdk 的权限控制是编译期的：包托管在内部 Go Module Proxy，仓库权限仅对授权模块开放。未经审查的业务 CLI 连 import 都做不到，编译直接失败。这比运行时控制更前置、更绝对。
存储与获取分离也是有意为之：sso-cli 负责登录（交互重、状态多、易出错），sso-sdk 负责读取（精简、可靠、无 IPC）。读取过程不经过网络，不经过进程间通信，纯本地解密，安全且快速。
逆向防护方面，团队也在考虑把 Token 获取逻辑编译为共享库（.so/.dylib）动态加载，或者用 CGO + 静态库内嵌并剥离符号，提升逆向分析成本。目前主要以私有包权限保证安全边界。
| 维度 | 传统 API Key / 预置 Token | 货拉拉 CLI/SSO 方案 |
|---|---|---|
| Token 存储 | 明文 .env / config / 环境变量 | Keychain 主密钥 + 加密文件 |
| Token 可见性 | 任何能读文件的人都能看到 | 常规途径完全不可见 |
| 用户隔离 | 无（共享同一 Token） | 加密环境变量 + key 粒度隔离 |
| 审计追溯 | 只知道"这个 Token"做了什么 | 每次调用绑定真实用户身份 |
| 登录体验 | 手动登录后复制 Token | 飞书卡片一键点击，无感知 |
| Token 过期 | 手动刷新或等报错 | 自动检测 + 触发重新登录 |
| 权限控制 | 运行时检查 | 编译期仓库权限控制 |
| 泄露风险 | 高（多处明文暴露） | 低（纵深防御，多层保护） |
核心差距在安全模型上：传统方案假设"环境是可信的"，货拉拉方案假设"环境是不可信的"——沙箱可能被任何人读取，Token 必须在任何常规载体中都不可见。这是一个根本性的思维转变。
你的 Agent 鉴权还在用 API Key 硬编码？评论区聊聊你踩过的坑。觉得有参考价值就点个赞，让更多人看到这套方案。
原始文章
- 货拉拉技术 - 面向 Agent Skill 的 CLI/SSO 鉴权体系 — 掘金原文，完整技术细节
相关项目与背景
- 飞书 CLI 开源项目 — 飞书 CLI 将文档、审批、日历等能力封装为 Agent 友好的命令
- Claude Code — Anthropic 的 Agent CLI 框架，Skill 机制是其核心扩展方式
- OpenClaw — 开源 Agent 框架，支持通过 Skill 调用外部 CLI 工具
安全技术参考
- OAuth 2.0 Device Authorization Grant — IETF RFC 8628，设备授权流程，Poll 模式的理论基础
- OWASP API Security Top 10 — API 安全风险清单，包含 Broken Authentication 等核心威胁
- macOS Keychain Services — Apple 官方密钥链文档
- Linux Secret Service API — Linux 密钥管理标准
Agent 安全相关
- Anthropic: Building effective agents — Agent 架构设计最佳实践
- GitHub: addyosmani/agent-skills — Agent Skill 设计模式和最佳实践集合
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。