0.7.0 更新了什么，如何升级

本次配套为 BailingHub Core 0.7.0、MCP / Agent Client SDK 0.5.0、DSH 0.5.0。它延续 0.6 的业务授权与会话能力，让开发者把已接入的多个系统放到同一次受控对话里使用。

一个场景看懂本次更新

“先查保温杯库存。有货就把商城售价改为 59 元并上架；没货先不要上架。”

用户先选择“库存系统 · 华东仓”和“商城系统 · 品牌旗舰店”。Agent 知道该向库存系统搜索查询能力，向商城搜索改价、上架能力。两边商品的对应关系必须已经确认，业务系统也要已经开放这些操作；能力、权限和审批都由原系统规则约束。

本次变化	解决的具体问题
同一会话选择多个系统	不再为了先查库存、再改商城商品而切换整段会话的默认授权。每一步保留对应系统和账户。
首次搜索前获得系统说明	模型先了解“谁负责什么”，再查工具；尚未加载不再被等同于没有能力。
授权成功后显示真实对象名称	用户能分辨哪个旗舰店、仓库或账户；名称由可信业务后端提供，改名不改变原身份。
智能体客户端集中配置	从同一管理入口核对授权地址、workspace、系统说明、允许工具和审批规则。
查询、撤销和追溯更完整	业务侧可以查到本接入方的已授权会话并撤销；管理员从原沟通进入各系统调用。

例如“改价完成、上架待审批”会分别保留状态，不能简化为“全部成功”。选择了库存系统却没有实际调用，也不能把它记成已执行。失败步骤不会自动回滚另一系统已经完成的修改。

谁需要做什么

角色	升级工作
中枢部署者	备份数据与配置，检查现有迁移账本，按正式流程应用缺少的迁移，再启动 Core 0.7.0 并验证健康状态。
本地客户端开发者	升级 SDK/DSH 到 0.5.0，接入系统说明和授权对象显示；保留原固定范围、Session 和归档确认进度。
业务系统开发者	要显示真实对象名时，更新业务侧 SDK/接口，在确认授权时提供 subject_display.name；需要生命周期联动时接入查询与撤销。
已有业务工具开发者	原业务 API、能力声明与审批规则继续生效；不用为了本次更新重写商城改价或库存查询服务。

自托管部署先升级 Core，再升级 Agent Client SDK/DSH。SDK/DSH 是独立项目；只升级其中一个组件不代表完整功能已经接好。

从 Core 0.6.1 升级需要按流程应用尚未执行的 058、059；更早版本还需要相应前序迁移。已应用的迁移不要重复执行，服务启动不会自动替你迁移。以完整 Core 升级步骤为准，保留备份和回滚材料。

升级后这样验证

1. 先复核原同系统 A/B 授权会话仍可使用，未选授权不会收到业务请求。
2. 在测试数据上授权商城和库存，首消息前选择两者，确认模型能说明各自用途。
3. 先查库存，再对明确对应的商品执行允许的低风险修改；分别核对原审批、后台结果与调用轨迹。
4. 为一份旧授权同步名称，确认名称更新后原会话、身份和归档关系仍保留。
5. 原会话断网后恢复，验证补传记录不会重复写操作；任一原授权撤销时整组保持阻断。

当前边界

这次多系统范围限定在同一 Hub 与审计域，不提供跨 Hub 的正文传输授权。系统说明和对象名都不是权限，不保证某个业务工具已经可用。旧会话不自动扩大成全部授权；名称缺失明确显示待同步。各业务系统保留最终裁决，ACC 继续独立维护。

完整来源：Core v0.7.0、SDK v0.5.0、DSH v0.5.0。继续阅读多系统使用流程或开发者接入指南。