Authsome
面向 AI 代理的开源凭证网关：通过 OAuth2 或 API Key 一次登录，所有代理持续保持认证、无头运行——代理永远接触不到你的凭证。
证据显示：凭据由网关持有、代理注入，skill 明确禁止 agent 接触或打印凭据，尊重 403 策略错误并要求用户确认 OAuth 端点，数据流披露较好。扣分：透明 MITM 代理架构对所有出站 HTTPS 生效，权限范围偏大；skill 未说明凭据存储位置/加密细节与撤销回滚的完整边界；依赖含 posthog（遥测）与 browser-cookie3（读取浏览器 cookie），隐私流向披露不完整；发布者未验证。
证据显示：SKILL.md 结构自洽，含登录流程、401/403 决策树、安装回退与内置 help 引导；evals. 定义了 7 个场景。扣分：静态审读无执行证据，测试套件未覆盖 skill 关键路径；feedback.md 自身记录了 NO_PROXY 绕过代理导致约 8 次失败尝试的真实故障案例，说明 happy-path 声明与实际行为存在偏差，故障反馈成本曾转嫁给用户。
证据显示：目标场景（agent 访问 Gmail/GitHub/Stripe 等）与触发描述（任何出站 HTTP 调用）清晰，evals 覆盖触发与多种连接状态。扣分：核心功能依赖本地代理守护进程/远程 daemon 及海外 OAuth 提供方，对中国大陆网络可达性无任何说明；无非适用边界声明；无中文支持考量。
证据显示：MIT 许可明确（Copyright Manoj Bajaj），版本号存在（skill 0.2.0），有 references 分层文档、反馈路径、issue 模板与 CI 工作流，README 有安装与自托管说明。扣分：无 changelog，skill 版本（0.2.0）与包版本（0.7.2）脱节且无说明；关键注册指南依赖外部 raw.githubusercontent URL，稳定性存疑；维护责任与更新路径部分依赖未验证的发布者。
证据显示：价值主张明确（凭据不进入 agent、免重复配置 auth），evals 描述了可用的输出路径。扣分：静态审读无法验证输出可直接使用；feedback.md 中的失败案例表明实际使用仍可能需要大量调试；相对 gh CLI 等替代方案的边际收益在已认证场景下有限（eval 4 本身也承认 gh 可直接完成）。
证据显示：evals. 与报告生成脚本构成可审计的评测框架，README 引用 PyPI/CI/codecov 徽章。扣分：仓库内无已提交的评测结果或第三方执行证据，徽章为声明而非静态可验证材料；核心安全声明（凭据不可见、代理注入）无法从文件独立复现。
- 静态审读，未执行；所有分数置信度低。
- 该 skill 将 agent 的全部出站 HTTPS 流量导向透明代理，安装前应确认你接受这一网络层变更及其回滚方式。
- 依赖含 posthog 遥测与 browser-cookie3（可读取浏览器 cookie），隐私敏感用户应先审查上游代码。
- 核心功能依赖本地守护进程/远程 daemon 与海外 OAuth 提供方，中国大陆网络可达性未说明，可能不可用。
- feedback.md 记录的真实故障（NO_PROXY 绕过代理）表明声明的'透明代理'在特定环境下会静默失效。
- skill 版本 0.2.0 与包版本 0.7.2 不一致，无 changelog，升级行为不可预期。
这个 Skill 能做什么，适合哪些场景？
Authsome 是一个位于 AI 代理与其调用的外部服务之间的凭证网关。你只需通过 OAuth2（浏览器 PKCE、设备码或浏览器桥接）或 API Key 完成一次认证，Authsome 会加密存储凭证，并通过 HTTP 代理把凭证注入到出站请求中。代理只需在命令前加 `authsome run --`，网关就会在请求时自动附加正确的认证头，子进程环境中不会暴露任何密钥。它内置大量服务商（Gmail、GitHub、Google 日历/云端硬盘、Stripe 等），支持令牌自动刷新、每个服务商多账号，并可通过 Docker 自托管。采用 MIT 许可，要求 Python 3.13+。
提供 CLI 工具 authsome，具体包括：通过一次性 authsome login <provider> 浏览器流程将 OAuth2 令牌和 API Key 存入加密存储；对以 authsome run -- 包装的命令透明代理出站 HTTPS 流量，按服务商 api_url 匹配并注入认证头；在令牌过期前自动刷新，并按 401（重新登录）与 403（用 --scopes 重新登录）处理失败；通过 authsome provider list/remove/revoke 和 authsome connections 管理服务商与连接；还可以 Docker + Postgres 方式以守护进程自托管。
- 使用 Claude Code 或 Codex 的开发者，想让代理读取 Gmail、查询 Stripe 余额或调用 GitHub API，而不必把令牌粘贴进对话或环境变量。
- 在 CI、定时任务、SSH 或后台 worker 中运行代理的团队，初次配置后需要无需人工、无浏览器的持续 API 访问。
- 注重安全的工程师，希望所有代理凭证集中在一个加密存储中，可轮换密钥、查看各代理活动，而不是在各个项目里散落硬编码的环境变量令牌。
- 自托管基础设施的运维人员，想要一个可掌控 TLS 和备份的集中式凭证守护进程（Docker + Postgres）。
- 代理因缺少 OAuth scope 遇到 403 的开发者，需要在既有服务商上用 `--scopes` 重新登录而不是重新注册。
这个 Skill 有哪些优点和局限？
- 代理永远看不到凭证值——认证在代理进程之外处理，杜绝凭证外泄风险和环境变量中的密钥。
- 令牌自动刷新，内置 OAuth2/API Key 服务商，免去每个项目重复搭建认证逻辑。
- 初次登录后完全无头运行，适合 CI、定时任务和后台 worker。
- 支持每个服务商多账号，提供连接/服务商管理命令，并有清晰的 401/403 故障处理决策树。
- MIT 开源、可用 Docker 自托管，并为 Claude Code、Codex、Cursor、OpenCode、LangChain、LlamaIndex 及 OpenAI/Anthropic SDK 提供集成。
- 要求 Python 3.13+，版本门槛较新。
- 初次配置需要浏览器和人工操作，并非完全零接触。
- 所有出站流量都经过网关/守护进程代理，多了一个需要信任和维护的环节。
- 内置服务商之外的新服务商接入需按 references/adding-provider.md 操作，SKILL.md 正文未内联说明流程。
- 来源未说明 Windows 下的具体行为，也没有安全审计或性能数据佐证。
如何安装这个 Skill？
要求 Python 3.13+。安装 CLI：uv tool install authsome（备选：pipx install authsome，或沙箱/一次性场景用 uvx authsome@latest <command>）。首次设置：authsome onboard（连接远程守护进程时加 --base-url https://...）。为代理添加技能：npx skills add agentrhq/authsome。可选自托管：设置 AUTHSOME_POSTGRES_PASSWORD、AUTHSOME_MASTER_KEY、AUTHSOME_UI_SESSION_KEY 后运行 Docker Compose，并通过 http://localhost:7998/health 检查。
如何使用这个 Skill？
每个服务商登录一次：authsome login github（浏览器在用户机器上打开，用户完成 OAuth，无需与代理共享凭证）。用 authsome provider list 确认连接。之后在任何出站调用前加网关前缀，例如：authsome run -- curl -s "https://api.github.com/user/repos?per_page=10" 或 authsome run -- python my_agent_script.py。curl、git、requests、axios、Go net/http 等标准 HTTP 客户端会自动遵循 HTTPS_PROXY，无需手动设置认证头。遇到 401 时先 authsome provider revoke <provider> 再重新登录；遇到 403 时带 --scopes 重新登录。具体参数请查看 authsome --help 及各子命令帮助。
这个 Skill 与同类方案有什么区别？
README 自身将 Authsome 与硬编码环境变量令牌和自建认证方案对比：后者需要自行实现令牌刷新、OAuth 流程和密钥隔离；也区别于让用户手动开浏览器操作的方式。与硬编码令牌不同，Authsome 自动刷新令牌、支持每个服务商多账号，并让凭证完全不进入代理进程。