假设你的团队已经有三套系统：商城处理线上交易，ERP 管理库存，CRM 记录客户跟进。
现在，三套系统都接入了同一个 AI 助手，相关账户也完成了授权。你希望对它说：
查一下这位客户最近买过哪些商品，确认相关商品现在有没有库存，再帮我准备一份跟进建议。
对熟悉业务的同事来说，这句话已经包含了一个大致的工作顺序：查线上订单，找到相关商品，核对库存，结合客户情况准备建议。
但 AI 面前可能只有三条连接：
- 运营账号一：已授权。
- 运营账号二：已授权。
- 运营账号三：已授权。
即使把名字换成“商城”“ERP”“CRM”，它也未必知道这家公司的订单到底存在哪里，哪套系统的库存才是本次任务要参考的，客户跟进记录由谁维护。
多个系统连接成功之后，还需要让助手在第一次搜索业务工具之前，理解各系统的用途与边界。
本文用上面的任务拆解这件事。场景和界面文字均为架构示例，三个系统的职责也是示例约定；真实项目需要按自己的业务事实配置，不代表某个客户案例或一套已经部署的完整流程。
一、从多账户走到多系统，多了一个判断
同一套门店系统接入 A、B 两个账户时，通常可以复用动作定义。查 A 店商品和查 B 店商品，主要区别在于本次调用使用哪份授权，以及这份授权允许访问哪些数据。
接入多个业务系统后，助手还要先判断：这一步业务应该向哪个系统寻找能力？
| 要判断的事 | 同系统多个账户 | 多个业务系统 |
|---|---|---|
| 去哪里找能力 | 已知是同一套业务系统 | 先确定负责这一步的系统 |
| 使用什么动作 | 通常可复用同类定义 | 按目标系统发现其实际动作 |
| 使用哪份授权 | 选择本次目标账户 | 在目标系统中选择相应账户 |
| 操作哪个对象 | 以该账户查询结果为准 | 还要确认跨系统对象如何对应 |
一个容易出现的误判是：三个系统都声明了“查询客户”，于是助手任选一个使用。
可是，商城里的客户可能指购买账户，CRM 里的客户可能包括尚未成交的线索，ERP 里的客户可能是结算单位。动作名字相似，背后的业务对象和覆盖范围却不同。
给工具加上清楚的系统归属，有助于消除这类歧义。Anthropic 的工具设计文章也讨论了按服务和资源组织工具名称，以帮助模型区分功能边界。
但如果工具采用按需加载，助手最初还看不到这些详细定义。因此，在“选择系统”和“搜索工具”之间，需要有一份足够简短、可信的系统说明。
二、先给助手一份看得懂的系统目录
可以把这个目录理解为新同事入职时收到的业务分工表。
它首先回答三个问题：这是什么系统，通常负责什么，哪些事情不在它的职责内。
例如，在本文场景中：
| 系统 | 简短用途 | 本例中的业务边界 |
|---|---|---|
| 商城 | 线上订单、购买记录与商品展示 | 用于查询线上交易；仓库库存以本例 ERP 为准 |
| ERP | 商品库存与仓储管理 | 用于核对库存；不负责客户沟通记录 |
| CRM | 客户资料与销售跟进 | 用于查询跟进背景；不作为线上成交订单的依据 |
有了这份说明，助手就可以先形成合理的搜索方向：向商城找订单查询能力，向 ERP 找库存查询能力，向 CRM 找跟进记录查询能力。
这里的“用途”最好来自系统维护者或受控的接入配置，并与真实的系统连接绑定。普通用户可以给自己的授权起一个便于识别的名字，但把“运营账号一”改名为“财务审批系统”，不应改变它的系统身份或职责。
系统说明也应该保持克制。它介绍业务分工，不承载“忽略确认”“自动使用其他账户”之类的执行指令。
如果后续又接入一套工单系统，维护者补充它的用途和真实绑定，兼容的客户端就有机会理解这个新目标。通用 SDK 不需要内置每家公司的产品名称，客户端也不必各自维护一份随业务增长而不断扩大的硬编码名单。
三、四种信息分开表达，助手才不容易误会
目录里最容易混在一起的，是“这个系统通常能做什么”和“我现在真的能做什么”。
比如，商城的介绍写着“订单、商品与营销”，并不意味着当前授权可以改价、退款或发优惠券。
接入设计应把下面四件事分别表达：
| 信息 | 回答的问题 | 可以怎样说明 |
|---|---|---|
| 系统用途 | 这个产品通常负责什么？ | 管理线上订单和商品 |
| 当前授权范围 | 这份授权实际允许什么？ | 已知只能查订单；其他权限待核验 |
| 工具加载状态 | 助手是否已经取得可调用定义？ | 相关工具尚未加载，可按需查询 |
| 当前可用状态 | 此刻是否能够访问？ | 已确认可用、暂时不可达，或尚未确认 |
特别需要解释的是 not_loaded。
它应该让助手理解为“还没有加载相关工具”，从而在任务需要时继续查询能力。若把它理解成“这个系统没有工具”，第一次目标选择就可能走错方向。
同样，授权有效不代表服务此刻一定可达；系统简介里提到营销，也不代表当前账户已经获得营销写权限。没有拿到的信息应当保留为未知，不能用产品介绍补成一个肯定答案。
按需工具发现本身已经是公开的工程实践：模型先通过搜索取得相关工具定义，再使用具体工具。Anthropic 的相关说明也指出，相似工具名称和参数选择会带来错误。
在多业务系统里，我们进一步需要解决搜索的起点：让助手知道应当先向哪个已选系统寻找相关能力。
四、用户先选本次范围，助手再在范围内找路
系统目录可以帮助助手理解业务，但目录本身也应受本次会话范围约束。
假设客户端保存了商城、ERP、CRM 和财务系统的授权。今天用户只选择商城和 ERP，那么这一段对话可用的目标就是这两套系统。
即使助手知道 CRM 通常负责跟进，它也不能把未选中的 CRM 说成当前可用，更不能为了“找找有没有帮助”而向它发送这轮输入。
一条清楚的流程是：
用户选定本次会话的系统与账户
↓
客户端确认实际生效的范围
↓
助手取得这些目标的系统用途说明
↓
根据任务向对应目标查询所需工具
↓
用该目标的原授权调用具体动作
↓
核验结果，标明来源与完成状态
读取简短系统介绍，也不需要先为所有目标创建业务运行记录，更不需要把完整用户对话发送给每套系统。
因此，用户只是说“你好”时，可以正常聊天；助手为了解目录而进行的配置读取或授权核验，不应被记成已经查询了订单、操作了库存。
如果旧版本暂时没有系统说明，客户端可以显示“用途未知”，或采用管理员维护、绑定真实连接的本地说明。已有授权和工具发现可以继续按原规则工作；遇到目标歧义时再询问用户。
关键是保持原范围。元数据缺失不能成为改用默认账户、搜索全部授权或按连接名称猜身份的理由。已开始会话的范围如何固定、恢复和重新确认，也应沿用明确的会话规则。
五、把开头那句话走一遍，会发生什么？
现在回到任务：查近期购买，核对库存，准备跟进建议。
为了让例子可以核验，先假定用户明确选择了商城、ERP 和 CRM 的测试授权，相关数据允许由同一助手处理，三个系统也提供了所需的只读动作。
第一步，确认“这位客户”是谁。
如果同名客户不止一位，就需要补充可用于确认的信息。即使 CRM 中已经选定一个客户，也不能直接把 CRM 的内部客户编号交给商城使用。
跨系统需要已经建立并核验的映射，或通过各系统允许的查询方式确认对应对象。商品也是一样：ERP 的库存记录编号与商城商品编号可能完全不同。没有可靠对应关系时，应先把这个缺口说明白。
第二步，向商城查询这位客户的近期线上订单。
助手先在商城目标下寻找对应工具，再使用商城这份授权查询。返回结果需要带着来源，后续判断仍以这些实际记录为依据。
第三步，根据已确认的商品对应关系，向 ERP 查询库存。
这里还应确认仓库、规格，以及返回的是可用库存还是其他库存口径。查询成功后，可以说明查询时点的结果，但一次库存读取不等于已经为客户锁定库存，也不能直接保证未来一定能够发货。
第四步，查询 CRM 中允许读取的跟进背景，整理建议。
用户要求的是“准备建议”，因此助手可以在对话里形成一份待查看的内容。把内容写回 CRM、建立跟进任务或发送给客户，分别是新的业务动作，需要相应权限，并按原规则进行确认与审批。
最终结果可以按这样的方式呈现。下面展示的是格式示意：
| 环节 | 结果应说明什么 |
|---|---|
| 商城订单 | 查询的客户与时间范围、实际返回的购买记录 |
| ERP 库存 | 对应商品与仓库、库存口径、查询时点 |
| CRM 跟进 | 本次读取到的背景；没有权限或查询失败则明确说明 |
| 跟进建议 | 基于哪些已核验信息形成，哪些判断仍缺依据 |
| 后续写操作 | 是否尚未发起；已发起则区分完成、待审批和失败 |
假如 ERP 暂时不可用，商城查询成功的事实仍然可以保留，但建议里不能写成“库存充足”。应告诉用户缺少库存核验，以及哪些建议因此暂时不能确定。
只实际调用了商城时，也不能因为 ERP 和 CRM 出现在所选目录里，就把它们标成“已执行”。
六、选对系统之后，还有两条边界要保留
第一条是业务授权。
系统介绍帮助模型选择方向，实际权限仍要由可信的执行链路与业务系统核验。模型认为“应该查 ERP”，不构成访问 ERP 的授权；模型认为“应该发一张券”，也不能替代原审批。
第二条是数据使用范围。
把商城订单、库存和客户跟进放进同一段对话，意味着这些信息可能进入同一个模型上下文。每次调用使用独立授权，并不能单独证明这些数据允许共同处理。
接入方还需要明确：哪些结果可供同一助手使用，哪些内容可以发送到其他系统，哪些对话可以归档到哪个审计域。尤其涉及不同中枢或不同组织时，不能把某一处的读取权限当成跨域传输许可。
已经允许助手阅读一条 CRM 跟进记录，也不意味着可以把这条记录原文放进商城的备注。
这些要求需要成为接入与运行规则。系统用途说明只承担它擅长的部分：帮助助手理解目标，不替其他规则作决定。
七、开发团队可以怎样验证这套设计？
第一次可以先准备两个用途不同的测试系统，每个系统提供一个明确的只读动作，全部使用合成数据。
在这个小范围里，检查几个用户看得见的结果：
- 第一次查询业务工具之前，助手能否解释两个已选系统分别负责什么。
- 只选择其中一个系统时，另一个是否确实不参与业务上下文、搜索和执行。
- 用户只打招呼时，是否没有额外创建业务运行或调用业务工具。
- 工具尚未加载时，助手能否继续按需发现，而非认定系统没有能力。
- 两个系统出现同名工具或同名对象时，调用是否仍落到正确目标。
- 某一步查询失败时，是否保留失败事实，且没有拿另一系统的数据顶替。
这组验证先确认“能找对地方、能解释来源”。后续增加写操作，再单独验证审批、结果回读和重复请求处理；跨系统也不会天然形成一笔共同成功或共同回滚的事务。
对于 BailingHub 这样的开源业务动作治理控制面，这套设计可以分成几处协作：系统维护者提供受控说明，中枢按绑定提供目标信息，客户端确认会话范围，助手按需寻找工具，业务系统核验并执行具体动作。
这里需要区分设计与公开版本。DSH 0.4.0 中文使用指南，其多授权范围要求相同中枢、Client App 和 workspace。本文讨论的多系统目录与目标选择设计，不能直接当作这份正式版本已经交付的跨系统教程；实际接入需核对所使用的 Core、SDK 和客户端适配器的正式兼容说明。
ACC 则是独立、实现中立的能力治理契约。具体产品怎样提供系统目录、客户端怎样组织会话、企业怎样确定数据和审批边界，由相应实现负责，不应合并成 ACC 核心必须包办的功能。
如果你正在给已有商城、CRM、ERP 或工单系统接入 AI，可以先写下两句话：这个系统负责什么，以及你希望助手先完成哪一条动作。 再补充一份脱敏接口说明，就可以开始评估目标识别、授权与结果核验条件。
