假设你负责两家门店，使用的是同一套业务系统。
你已经分别完成了 A 店和 B 店的授权。现在希望对 AI 说：
帮我查一下 A、B 两店这款商品的信息。确认商品无误后，把 A 店的内部备注改成“周年庆备货”，B 店不要修改。
按照人的工作习惯，这是一件很自然的事：先看两家店，再对其中一家做一个明确的修改。
但一些 AI 助手仍然要求你先切到 A 店、问一遍，再切到 B 店、问一遍，最后切回 A 店操作。查询结果分散在不同对话里，用户还得自己拼出全貌。
能不能把这件事放在同一段对话里完成？
可以。前提是用户先明确这段对话能使用哪些授权，AI 再在这个范围内，为每次操作选择对应的授权。
这篇文章只讨论同一业务系统下的多份授权。上面的商品任务是架构示例，需要系统实际提供查询与备注修改能力；它不是某个客户案例，也不代表所有接入系统天然支持这两项动作。
一、同一套系统，通常可以复用同一套能力声明
先看两家店有什么相同，有什么不同。
| 项目 | A 店 | B 店 |
|---|---|---|
| 使用的业务系统 | 同一套系统 | 同一套系统 |
| 动作的定义 | 查询商品、修改内部备注 | 可以复用相同的动作定义 |
| 本次调用的授权 | A 店已确认的业务授权 | B 店已确认的业务授权 |
| 实际可见数据 | A 店授权允许访问的数据 | B 店授权允许访问的数据 |
| 实际允许的修改 | 按 A 店当前权限判断 | 按 B 店当前权限判断 |
如果同一套后端已经声明了“查询商品”，接入第二家门店时，通常不需要再手工复制一个“B 店专用查询商品”。
更容易理解的比喻是：工具说明描述怎样办事，授权决定这一次以谁的身份、在哪个范围办事。
AI 可以理解“查 A 店”和“查 B 店”用的是同一类动作。真正执行时，客户端和中枢为调用绑定对应授权，业务系统再核验身份与权限。
这里有两个细节：
第一，“两把钥匙”是帮助理解的比喻，不意味着把两份 Token 原文交给模型。模型可以看到适合选择的授权标签和会话内引用，凭据由受信任的客户端组件管理。
第二，能力声明可以复用，不代表两个账号一定拥有完全相同的可用工具。一个账号可能能修改，另一个只能查询；同一份动作说明也不能抹掉这些差异。
二、先决定谁参加这段对话，再让 AI 选择怎样办事
多账户体验里有两个不同的选择。
第一个选择由用户做：这段对话允许使用哪些账户。
你可能在客户端保存了 A、B、C 三家店的授权，但今天的任务只涉及 A、B，就只把 A、B 纳入本次范围。没有选中的 C 店，不参与本插件这一轮的业务上下文准备，也不加载或执行它的业务工具。
第二个选择由 AI 做：本次工具调用使用范围内的哪份授权。
比如，查询 A 店商品用 A 店授权；查询 B 店商品用 B 店授权；修改 A 店备注仍用 A 店授权。
用户为新对话选中：A 店、B 店
↓
确认本次范围已经生效
↓
AI 理解任务与可用动作
↓
查询 A 店 → 使用 A 店授权
查询 B 店 → 使用 B 店授权
修改 A 店 → 使用 A 店授权
↓
按门店核对结果，汇总给用户
这样，AI 不必每做一步都要求用户切换默认门店，用户也不必放弃对业务范围的控制。
此前的多账号文章讨论了单身份会话下的显式切换。这里是在它的基础上增加一个明确条件：用户主动为新会话选定多份授权后，模型才能在这组授权内选择。 已开始的单身份会话不能悄悄扩大成多身份会话。
在 BailingHub 配套 DSH 插件 0.4.0 中，未选或空选范围时只进行普通聊天，不启动本插件的业务执行；首条用户消息会固定范围，之后增减账户需要新建会话。设置失败或所选授权不可用时，业务访问暂停，不自动改用默认门店或剩余子集。这些行为已写入固定版本使用指南。
这一范围约束针对本插件连接的 BailingHub 业务访问。客户端的其他工具、模型服务及其数据规则，仍需要分别管理。
三、选中了 A、B，不代表任务目标已经足够清楚
范围解决的是“允许涉及谁”，任务还要说明“具体对谁做什么”。
如果用户只说“把这款商品改一下”，而 A、B 两店都有同名商品，系统仍然需要澄清：
- 修改哪家店？
- 修改哪一条商品记录？
- 修改哪个字段，改成什么？
接入时应让助手在目标有歧义时询问，而不是要求它始终猜一个答案。授权校验只能约束允许访问的范围，无法替用户证明一次猜测符合真实意图。
还有一个经常被忽略的问题：相同商品名称，甚至相同业务编码，也不一定对应相同的内部记录标识。
合理的处理顺序是分别查询、分别确认，把后续修改绑定到 A 店刚刚确认的对象。不能拿 B 店查询结果中的记录标识，直接配上 A 店授权去修改。
因此，每次写操作至少应当同时明确三件事：
哪份授权、哪个业务对象、哪项具体变更。
“我选中了 A、B”只确定了可用范围，不能代替对象确认，也不能代替原有的业务审批。
四、让结果按门店落下来
回到开头的任务，一段可核验的操作过程可以这样组织：
- 用 A 店授权查询商品，确认对象及当前备注。
- 用 B 店授权查询对应商品，保留 B 店自己的对象标识和结果。
- 对 A 店的目标对象发起备注修改；需要审批时，进入原审批流程。
- 写入成功后重新读取 A 店结果，确认备注符合预期。
- 汇总两店查询结果，并明确 B 店没有发起写操作。
业务结果可以按这样的格式呈现。下表仅示意输出方式，不是实际执行记录：
| 门店 | 请求的动作 | 当前结果 | 核验依据 |
|---|---|---|---|
| A 店 | 查询指定商品 | 已查询 | A 店查询返回的对象信息 |
| B 店 | 查询对应商品 | 已查询 | B 店查询返回的对象信息 |
| A 店 | 修改内部备注 | 已完成，或待审批，或失败 | 原调用状态；完成后还需回读业务结果 |
| B 店 | 不修改 | 未发起写操作 | 对应授权的执行记录 |
这里的“未发起写操作”很重要。它只说明助手没有向 B 店提交这次修改，不能保证同一时段没有其他员工或业务流程改动 B 店数据。
同样，B 店查询失败时，也不应把 A 店结果填到 B 店下面。若失败影响后续判断，就应先停在判断处，把缺失信息说明白。
用户需要看到每一步的真实状态。 一句“已经处理好了”无法替代分项结果和后台核验。
如果写请求超时、结果暂时不确定，应通过原调用状态或业务结果继续核对，不应立即换一份授权或重新提交一笔写操作。恢复必须遵守原动作提供的幂等和查询能力。
五、权限分别保留，数据是否适合放在一起还要另看
一次对话使用 A、B 两份授权，意味着助手可能需要同时理解两边的信息。
例如，要比较两家店的商品情况，就要把各自的查询结果交给同一个模型进行整理。BailingHub 的同系统多授权模式也会为选中的授权分别准备上下文，再供本地 Agent 使用。
因此，“每次调用有独立授权”与“数据不会进入同一个模型上下文”是两个不同的问题。
如果两个账户的数据不允许被同一个助手、同一个模型服务共同处理，就应当使用分开的会话，并按照实际的数据管理要求配置模型与客户端。不能仅凭页面上显示了 A、B 标签，就认为模型侧已经实现数据隔离。
门店名也只是帮助人识别连接的标签。真实身份要以授权过程确认的绑定为准，不能把一个连接重命名为“B 店”就当成获得了 B 店权限。
这些边界在插件隐私说明中有明确记录。它们决定了哪些账户适合进入同一段对话，而不只是一个界面如何摆放的问题。
六、把完整沟通连回各自的操作记录
多家店的业务操作应当分别留痕。但复盘一次对话时，人通常想先知道：用户当时到底要求了什么？
如果后台只有几条互相分开的执行摘要，单看其中一条，很难理解“查询了两店、只修改一家”的完整语境。
一种清晰的组织方式是保留两层记录：
- 可见沟通：用户原话、助手对外回复、每一轮的开始和结束。
- 实际执行：每份授权自己的调用、审批、错误与业务结果。
在管理审计界面中，读完一轮沟通，可以进入 A 店、B 店各自的原执行记录；查看某次调用时，也能回到它所属的对话。
BailingHub Core 0.6.1 提供的可见对话归档采用这种组织方式。完整正文位于独立审计记录中，管理员按既有读取权限查看；不会因为归档关联，就把不同业务身份、审批或各授权的记忆合并。具体边界见完整对话审计文档。
这里说的“完整”，限定在宿主实际保存并提交的可见文本范围内，不包含模型隐藏思考，也不承诺补出从未保存的历史、附件或丢失原文。
断网后补传已经保存的记录，只是在补齐审计材料，不会重新执行商品修改。若本地保存失败、历史存在缺口，就应明确显示不完整。归档同步成功，也不能被拿来证明业务动作执行成功。
原会话重开后，只有全部原授权重新验证有效，才能恢复原范围；这也不等于跨进程恢复重启前尚未完成的业务调用或审批。
七、已有系统可以怎样开始验证？
如果业务系统已经接入 BailingHub，可以从两份测试授权开始。当前公开配套为：
| 组件 | 版本 | 主要作用 |
|---|---|---|
| BailingHub Core | 0.6.1 | 业务动作治理、执行记录与可见对话审计 |
| MCP / Agent Client SDK | 0.4.0 | 客户端接入与授权链路 |
| DSH 社区插件 | 0.4.0 | 在兼容的 DeepSeek Harness 中使用会话范围与归档能力 |
已有能力声明无需仅为第二个同系统账户重新声明。管理员需先准备相同中枢、Client App 和 workspace 下的授权入口；本期不是跨系统、跨路由的业务编排。
以已安装兼容 DSH、配置好公开连接信息并分别完成 A/B 授权为前提，在新会话发送第一条用户消息之前执行：
/bailinghub connections list
/bailinghub scope set <A店连接键> <B店连接键>
/bailinghub scope
从连接列表复制实际连接键，替换上面的占位内容。这里的键由用户交给客户端命令处理，不是把密钥交给模型，也不能直接用显示名称代替。确认返回的生效范围确实为 A、B，再开始提问。
先选择一个业务确实支持的只读动作，然后在测试数据上尝试一项允许、可回读、可恢复的修改。以内部备注为例，还应事先确认修改不会触发客户通知或其他流程，并记下原值；若系统没有这项能力，就换成已经声明并验证过的低风险动作。
完成后，分别核对：
- 查询结果是否明确标注来源门店，目标对象是否正确。
- 写操作是否只发生在指定授权和对象上，审批是否仍按原规则处理。
- 业务后台回读结果是否符合要求。
- 可见沟通是否能关联到对应的原执行记录。
若使用自研智能体客户端，需要宿主接入会话范围确认、持久历史和归档状态。仅升级中枢，不能让一个从未提交可见消息的旧客户端自动拥有完整归档。
首次安装与升级步骤请使用0.4.0 中文上手指南。当前推荐与已验组合、兼容要求及社区集成边界见正式发布说明。这些能力属于 BailingHub 与独立客户端适配器的工程实现，不应被写成 Agent Capability Contract（ACC，Agent 能力契约）新增了多门店编排功能。
八、先让一段对话完成一件边界清楚的事
“帮 A 店做一场周年庆”可以继续涉及商品、活动、内容、审批和多个系统，那是更大的业务编排问题。
第一次验证，可以先缩小到一句可以逐项检查的话：
在这两个已经授权的测试账户里，分别查询一个明确对象，只对指定账户完成一次可核验的修改。
这件事跑通后，团队才能判断：助手是否选对目标，授权是否保持原边界，结果是否真的写入，出了问题能否回到原始沟通与执行记录。
如果你的系统尚未接入，可以先整理“业务系统 + 一条希望 AI 完成的动作 + 脱敏接口说明”，从这一条动作评估授权、输入、审批和结果核验条件。已有系统可按上述指南验证；需要讨论接入问题，可使用 BailingHub GitHub Issues，只提供脱敏信息，不提交凭据、私有地址或真实客户数据。
