假设你负责两家门店，使用的是同一套业务系统。

你已经分别完成了 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 店授权。

```text
用户为新对话选中：A 店、B 店
            ↓
确认本次范围已经生效
            ↓
AI 理解任务与可用动作
            ↓
查询 A 店 → 使用 A 店授权
查询 B 店 → 使用 B 店授权
修改 A 店 → 使用 A 店授权
            ↓
按门店核对结果，汇总给用户
```

这样，AI 不必每做一步都要求用户切换默认门店，用户也不必放弃对业务范围的控制。

此前的多账号文章讨论了单身份会话下的显式切换。这里是在它的基础上增加一个明确条件：**用户主动为新会话选定多份授权后，模型才能在这组授权内选择。** 已开始的单身份会话不能悄悄扩大成多身份会话。

在 BailingHub 配套 DSH 插件 0.4.0 中，未选或空选范围时只进行普通聊天，不启动本插件的业务执行；首条用户消息会固定范围，之后增减账户需要新建会话。设置失败或所选授权不可用时，业务访问暂停，不自动改用默认门店或剩余子集。这些行为已写入[固定版本使用指南](https://github.com/bailinghub/bailinghub-dsh-plugin/blob/v0.4.0/docs/GETTING_STARTED.zh-CN.md)。

这一范围约束针对本插件连接的 BailingHub 业务访问。客户端的其他工具、模型服务及其数据规则，仍需要分别管理。

## 三、选中了 A、B，不代表任务目标已经足够清楚

范围解决的是“允许涉及谁”，任务还要说明“具体对谁做什么”。

如果用户只说“把这款商品改一下”，而 A、B 两店都有同名商品，系统仍然需要澄清：

- 修改哪家店？
- 修改哪一条商品记录？
- 修改哪个字段，改成什么？

接入时应让助手在目标有歧义时询问，而不是要求它始终猜一个答案。授权校验只能约束允许访问的范围，无法替用户证明一次猜测符合真实意图。

还有一个经常被忽略的问题：**相同商品名称，甚至相同业务编码，也不一定对应相同的内部记录标识。**

合理的处理顺序是分别查询、分别确认，把后续修改绑定到 A 店刚刚确认的对象。不能拿 B 店查询结果中的记录标识，直接配上 A 店授权去修改。

因此，每次写操作至少应当同时明确三件事：

> 哪份授权、哪个业务对象、哪项具体变更。

“我选中了 A、B”只确定了可用范围，不能代替对象确认，也不能代替原有的业务审批。

## 四、让结果按门店落下来

回到开头的任务，一段可核验的操作过程可以这样组织：

1. 用 A 店授权查询商品，确认对象及当前备注。
2. 用 B 店授权查询对应商品，保留 B 店自己的对象标识和结果。
3. 对 A 店的目标对象发起备注修改；需要审批时，进入原审批流程。
4. 写入成功后重新读取 A 店结果，确认备注符合预期。
5. 汇总两店查询结果，并明确 B 店没有发起写操作。

业务结果可以按这样的格式呈现。下表仅示意输出方式，不是实际执行记录：

| 门店 | 请求的动作 | 当前结果 | 核验依据 |
|---|---|---|---|
| A 店 | 查询指定商品 | 已查询 | A 店查询返回的对象信息 |
| B 店 | 查询对应商品 | 已查询 | B 店查询返回的对象信息 |
| A 店 | 修改内部备注 | 已完成，或待审批，或失败 | 原调用状态；完成后还需回读业务结果 |
| B 店 | 不修改 | 未发起写操作 | 对应授权的执行记录 |

这里的“未发起写操作”很重要。它只说明助手没有向 B 店提交这次修改，不能保证同一时段没有其他员工或业务流程改动 B 店数据。

同样，B 店查询失败时，也不应把 A 店结果填到 B 店下面。若失败影响后续判断，就应先停在判断处，把缺失信息说明白。

**用户需要看到每一步的真实状态。** 一句“已经处理好了”无法替代分项结果和后台核验。

如果写请求超时、结果暂时不确定，应通过原调用状态或业务结果继续核对，不应立即换一份授权或重新提交一笔写操作。恢复必须遵守原动作提供的幂等和查询能力。

## 五、权限分别保留，数据是否适合放在一起还要另看

一次对话使用 A、B 两份授权，意味着助手可能需要同时理解两边的信息。

例如，要比较两家店的商品情况，就要把各自的查询结果交给同一个模型进行整理。BailingHub 的同系统多授权模式也会为选中的授权分别准备上下文，再供本地 Agent 使用。

因此，“每次调用有独立授权”与“数据不会进入同一个模型上下文”是两个不同的问题。

如果两个账户的数据不允许被同一个助手、同一个模型服务共同处理，就应当使用分开的会话，并按照实际的数据管理要求配置模型与客户端。不能仅凭页面上显示了 A、B 标签，就认为模型侧已经实现数据隔离。

门店名也只是帮助人识别连接的标签。真实身份要以授权过程确认的绑定为准，不能把一个连接重命名为“B 店”就当成获得了 B 店权限。

这些边界在[插件隐私说明](https://github.com/bailinghub/bailinghub-dsh-plugin/blob/v0.4.0/PRIVACY.md)中有明确记录。它们决定了哪些账户适合进入同一段对话，而不只是一个界面如何摆放的问题。

## 六、把完整沟通连回各自的操作记录

多家店的业务操作应当分别留痕。但复盘一次对话时，人通常想先知道：用户当时到底要求了什么？

如果后台只有几条互相分开的执行摘要，单看其中一条，很难理解“查询了两店、只修改一家”的完整语境。

一种清晰的组织方式是保留两层记录：

- **可见沟通**：用户原话、助手对外回复、每一轮的开始和结束。
- **实际执行**：每份授权自己的调用、审批、错误与业务结果。

在管理审计界面中，读完一轮沟通，可以进入 A 店、B 店各自的原执行记录；查看某次调用时，也能回到它所属的对话。

BailingHub Core 0.6.1 提供的可见对话归档采用这种组织方式。完整正文位于独立审计记录中，管理员按既有读取权限查看；不会因为归档关联，就把不同业务身份、审批或各授权的记忆合并。具体边界见[完整对话审计文档](https://github.com/bailinghub/bailinghub/blob/v0.6.1/docs/AGENT_CONVERSATION_AUDIT.md)。

这里说的“完整”，限定在宿主实际保存并提交的可见文本范围内，不包含模型隐藏思考，也不承诺补出从未保存的历史、附件或丢失原文。

断网后补传已经保存的记录，只是在补齐审计材料，不会重新执行商品修改。若本地保存失败、历史存在缺口，就应明确显示不完整。归档同步成功，也不能被拿来证明业务动作执行成功。

原会话重开后，只有全部原授权重新验证有效，才能恢复原范围；这也不等于跨进程恢复重启前尚未完成的业务调用或审批。

## 七、已有系统可以怎样开始验证？

如果业务系统已经接入 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 授权为前提，在**新会话发送第一条用户消息之前**执行：

```text
/bailinghub connections list
/bailinghub scope set <A店连接键> <B店连接键>
/bailinghub scope
```

从连接列表复制实际连接键，替换上面的占位内容。这里的键由用户交给客户端命令处理，不是把密钥交给模型，也不能直接用显示名称代替。确认返回的生效范围确实为 A、B，再开始提问。

先选择一个业务确实支持的只读动作，然后在测试数据上尝试一项允许、可回读、可恢复的修改。以内部备注为例，还应事先确认修改不会触发客户通知或其他流程，并记下原值；若系统没有这项能力，就换成已经声明并验证过的低风险动作。

完成后，分别核对：

- 查询结果是否明确标注来源门店，目标对象是否正确。
- 写操作是否只发生在指定授权和对象上，审批是否仍按原规则处理。
- 业务后台回读结果是否符合要求。
- 可见沟通是否能关联到对应的原执行记录。

若使用自研智能体客户端，需要宿主接入会话范围确认、持久历史和归档状态。仅升级中枢，不能让一个从未提交可见消息的旧客户端自动拥有完整归档。

首次安装与升级步骤请使用[0.4.0 中文上手指南](https://github.com/bailinghub/bailinghub-dsh-plugin/blob/v0.4.0/docs/GETTING_STARTED.zh-CN.md)。当前推荐与已验组合、兼容要求及社区集成边界见[正式发布说明](https://github.com/bailinghub/bailinghub-dsh-plugin/releases/tag/v0.4.0)。这些能力属于 BailingHub 与独立客户端适配器的工程实现，不应被写成 Agent Capability Contract（ACC，Agent 能力契约）新增了多门店编排功能。

## 八、先让一段对话完成一件边界清楚的事

“帮 A 店做一场周年庆”可以继续涉及商品、活动、内容、审批和多个系统，那是更大的业务编排问题。

第一次验证，可以先缩小到一句可以逐项检查的话：

> 在这两个已经授权的测试账户里，分别查询一个明确对象，只对指定账户完成一次可核验的修改。

这件事跑通后，团队才能判断：助手是否选对目标，授权是否保持原边界，结果是否真的写入，出了问题能否回到原始沟通与执行记录。

如果你的系统尚未接入，可以先整理**“业务系统 + 一条希望 AI 完成的动作 + 脱敏接口说明”**，从这一条动作评估授权、输入、审批和结果核验条件。已有系统可按上述指南验证；需要讨论接入问题，可使用 [BailingHub GitHub Issues](https://github.com/bailinghub/bailinghub/issues)，只提供脱敏信息，不提交凭据、私有地址或真实客户数据。


帮我查一下 A、B 两店这款商品的信息。确认商品无误后，把 A 店的内部备注改成“周年庆备货”，B 店不要修改。

一个 AI 助手，如何在同一对话里管理维护多家门店？

人工智能

客户端

后端

同一系统多授权下，AI可同段对话查询A/B两店商品并仅修改A店备注。通过会话预设范围，授权分别校验，结果分店呈现并关联执行记录。

数据管理

代码解释

智能体

路由

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

一个 AI 助手，如何在同一对话里管理维护多家门店？-腾讯云开发者社区-腾讯云

一个 AI 助手，如何在同一对话里管理维护多家门店？

一个 AI 助手，如何在同一对话里管理维护多家门店？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐