background-agents Provider Accounts机制详解多账号管理与无人值守模式完全指南【免费下载链接】background-agentsAn open-source background agents coding system项目地址: https://gitcode.com/GitHub_Trending/ba/background-agents background-agentsOpen-Inspect是一个开源的后台编码智能体系统而它的Provider Accounts供应商账号机制正是多账号管理与无人值守运行的核心你可以在设置页面连接多个 ChatGPT / SuperGrok 订阅账号为 Web、Slack、GitHub、Linear 和定时自动化Automations分别指定使用哪个账号或 API Key从而让 AI 编码智能体在你不在电脑前时也能确定性地跑起来。本文用大白话讲清楚这套机制的设计思路与上手方法。一、background-agents 是什么background-agents 提供的是一个托管式后台编码智能体你在 Web 界面、Slack、GitHub PR 或 Linear 工单里丢一个任务它就会在独立沙箱里完整运行Node.js、Python、git、浏览器自动化、VS Code 环境后台默默写代码、提 PR。它的一大亮点是模型自由既可以用 Anthropic ClaudeAPI Key 或订阅也可以用 OpenAI CodexChatGPT 订阅、xAI GrokSuperGrok 订阅。问题来了——当你同时拥有多个订阅账号还希望 Slack 机器人或定时任务无人值守地调用模型时系统到底该用哪个账号付费这就是 Provider Accounts 机制要解决的问题。二、为什么需要多账号管理过去OpenAI 和 xAI 的 OAuth 凭据是以固定密钥的形式存放在全局/仓库/环境的通用密钥库里一个作用域只能有一份凭据。这意味着❌ 无法在同一作用域下连接多个账号❌ 没有稳定的账号 ID无法追溯是哪个账号跑了这次会话❌ 无法显示账号名称、连接状态也没有重连流程❌ 创建会话时无法选择账号❌ Slack / GitHub / Linear 等无人值守入口没有确定性的账号策略❌ 用逗号分隔堆多个凭据会导致令牌轮换歧义还可能发生隐式计费切换Provider Accounts 机制用一条独立的设计原则回答这些问题把模型连接建模为供应商账号而不是分隔符拼接的密钥池或负载均衡池。每个账号有稳定 ID、可验证、可轮换、可禁用、可归档且全程可审计。三、五个核心概念30秒看懂概念一句话解释Provider account供应商账号全安装范围内一个稳定的账号连接如Team ChatGPT PlusProvider credential供应商凭据该账号对应的加密认证状态与账号一一对应Provider default默认账号每个供应商至多一个全范围默认账号Session provider auth会话账号绑定会话创建时固定下来的账号/API Key 模式创建后不再变化Automation provider auth自动化账号绑定可固定到某个自动化任务上的账号或 API Key 模式理解这套机制的关键就一句话会话创建时一次性解析并固定账号之后绝不因为默认值或凭据变化而悄悄跳到别的付费账号上。四、快速上手连接你的第一个 ChatGPT 账号打开Settings Provider Accounts按以下步骤操作详见 docs/OPENAI_MODELS.md点击Add account ChatGPT设备授权Device Authorization流程自动启动通过Open ChatGPT Settings为 Codex 启用设备码授权点击Open Device Authorization输入界面显示的授权码保持对话框打开OpenAI 确认连接后新账号即出现在列表中用Rename改个有意义的显示名例如 Team ChatGPT Plus 账号连接后设置页面会展示账号的外部门户 ID、默认账号标记、连接状态、最近验证时间和最近使用时间。所有凭据值都是只写的——浏览器永远看不到已存储的凭据。xAI GrokSuperGrok账号的连接流程完全相同参见 docs/GROK_MODELS.md。五、无人值守模式让机器人确定性地花钱这是本机制最实用的一部分。Slack、GitHub、Linear 和未固定账号的自动化任务都是无人值守入口——没有人坐在旁边选择账号。每个供应商的默认配置里都有一个Unattended mode无人值守模式开关Use default account无人值守启动也走订阅账号Use API key交互会话用订阅默认值但 Slack / GitHub / Linear / 未固定的自动化任务继续走按量计费的 API Key这样你可以实现一个很合理的策略白天在 Web 上用 ChatGPT 订阅跑会话夜里的定时自动化继续用 API Key 按量付费互不干扰。账号解析顺序从高到低每个供应商账号的确定都遵循同一个确定性顺序优先级策略说明1️⃣显式选择创建会话/自动化时明确指定的账号或 API Key 模式2️⃣无人值守策略无人值守启动Slack/GitHub/Linear/未固定自动化应用unattended_mode3️⃣默认账号使用全安装范围的 active 默认账号4️⃣遗留兼容以上都不适用时回落到legacy_scoped_oauth⚠️ 注意两条铁律绝不隐式故障转移某个账号配额用尽或认证失败时系统不会悄悄换到另一个付费账号——那会改变计费身份、掩盖凭据故障会话绑定不可变会话运行中不会因默认值变更而移动到别的账号子会话Child Session完整继承父会话的账号绑定且智能体自身无权为子会话指定账号六、安全设计凭据去哪儿了这是新手最容易担心的部分答案很干净长期凭据只存在于控制平面Control Plane沙箱永远拿不到。设备授权结果用专用密钥PROVIDER_ACCOUNTS_ENCRYPTION_KEY加密存储浏览器与沙箱均不可见会话里只存账号 ID不存任何凭据沙箱需要模型访问时通过会话身份认证的 Broker 端点POST /sessions/:id/provider-auth/:provider/access-token换取短时效访问令牌账号模式下控制平面会主动从沙箱环境中移除对应供应商的 API Key防止绕过订阅选择多个控制平面进程并发刷新令牌时通过原子 SQL 租约exchange_state/exchange_owner/exchange_generation保证同一时刻只有一个进程执行轮换交换且宁可要求重连、绝不复用已消耗的轮换令牌相关实现集中在 packages/control-plane/src/model-provider-accounts/数据库结构由 0064_provider_accounts.sql 与 0065_provider_account_authorizations.sql 定义。七、账号生命周期一个账号的一生账号支持完整的状态管理动作添加、重命名、验证Verify、重连Reconnect、设为默认、禁用Disable、启用Enable、归档Archive。几个值得记住的细节禁用 ≠ 立即断网已签发给运行中沙箱的访问令牌在其有效期内仍可用禁用只阻止后续刷新归档是软删除历史会话仍引用该账号元数据但归档账号不能用于新会话身份变更必须新建账号重连流程会校验外部账号 ID如果换了 OpenAI 身份需要创建新账号并显式更新默认值与自动化固定项八、延伸阅读与核心资料想深入这套机制推荐按这个顺序阅读完整架构设计文档provider-accounts.md ——数据模型、Broker 架构、并发轮换、故障语义全都有可用模型与选择器说明docs/AVAILABLE_MODELS.mdOpenAI 账号配置与共存细节docs/OPENAI_MODELS.md密钥管理体系docs/SECRETS.md项目整体架构README.md总结Provider Accounts 机制用五个概念账号、凭据、默认、会话绑定、自动化绑定 一条确定性解析顺序解决了 background-agents 最棘手的工程问题多个付费订阅账号如何被清晰、安全、可审计地用于有人值守和无人值守两种场景。它的设计哲学值得借鉴——解析一次、固定到底让每一次模型调用都能回答这钱是谁付的。【免费下载链接】background-agentsAn open-source background agents coding system项目地址: https://gitcode.com/GitHub_Trending/ba/background-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考