docs(kb-dsh): 优化知识服务清单注入与错误处理提示

- 补查型工具(service_find)确认不暴露服务清单，避免与catalog冲突
- 清单内容策略扩展，0服务时注入明确禁止猜测id的提示
- 工具描述保持静态，上下文消息注入带source的UserMessage实现动态清单
- bl命令及安装提示仅在动态文本中出现，避免静态描述频繁消耗token
- 错误处理中4xx刷新并追加服务清单，0服务状态下明确提示不重试须创建部署
- service-catalog新增无服务提示及刷新服务列表构建函数
- service-context调整使用新清单构建逻辑，缓存空时注入无服务通知
- tools调整描述文案，提示来自上下文消息且拒绝猜测
- README补充bl CLI安装使用说明
- 测试补充无服务情况注入提示及刷新列表文本内容校验

docs/kb-dsh/runtime-behavior.md

@@ -67,6 +67,8 @@ settings 注册是**手写**的，没有用 `installSettingsSection`：需要两
 
 模型要判断"该不该检索"，靠的是看到本 workspace 部署了哪些检索服务。插件内部经 `/api/v1/indices/rag/app/list` 拉取该清单并缓存，**不对模型暴露服务发现工具**（`kb_service_list` 不会回归：它会把"先 list 再 search"的额外一轮重新引入）；管理面仍用 bl。
 
+补查型工具（"只按关键词查、不列全部"的 `service_find`）也评估过，同样不做。理由不是成本而是**收益已被占掉**：唯一能支撑它的论据是"兜底走 bash + bl 不一定可用"，而管理面本来就以 bl 为前提；catalog 那条通道是零轮次、无条件注入、且带截断告知与默认收敛策略，再开第三个入口只会跟它抢事实源。真正要补的是兜底路径本身——见下面两小节。
+
 ### 载体：上下文消息，不是工具描述
 
 两个工具的 **description 保持静态**（不含任何服务 id）。清单经 `agent/pre-step` 注入为一条带 source 的 `UserMessage`（`{ kind: 'plugin', plugin: 'tool-bailian-kb/services', form: 'catalog' }`），而不是烘进 tool description。两个原因：
@@ -78,15 +80,29 @@ settings 注册是**手写**的，没有用 `installSettingsSection`：需要两
 
 ### 清单内容策略
 
-| 情形                     | 注入内容                                              |
-| ------------------------ | ----------------------------------------------------- |
-| 配了默认服务             | 只列该服务 + "另有 N 个" 提示                         |
-| 未配默认，deployed ≤ 10  | 全量 `agent_id` + 名称                                |
-| 未配默认，deployed > 10  | 按 `modify_time` 倒序取 10 条，**显式标明截断**与总数 |
-| 0 个 / 拉取失败 / 无缓存 | 不注入（工具仍可用）                                  |
+| 情形                     | 注入内容                                                                             |
+| ------------------------ | ------------------------------------------------------------------------------------ |
+| 配了默认服务             | 只列该服务 + "另有 N 个" 提示                                                        |
+| 未配默认，deployed ≤ 10  | 全量 `agent_id` + 名称                                                               |
+| 未配默认，deployed > 10  | 按 `modify_time` 倒序取 10 条，**显式标明截断**与总数                                |
+| 缓存里 0 个服务          | 注入 `buildNoServiceNotice()`：禁止编 id，并给出建服务/部署服务的路径（控制台或 bl） |
+| 无缓存文档（含拉取失败） | 不注入（工具仍可用）                                                                 |
 
 英文框架 + 服务名原样保留；空 scene 整节省略；截断必须告知（静默截断会让模型把清单当全集，进而断言"没有对应知识库"）。
 
+最后两行的差别是**能不能下断言**：缓存里有文档但 0 条，是权威的"这个 workspace 没有可调服务"，说出来比沉默好——`agent_id` 恒必填，沉默只会让模型编一个 id（换来服务端裸报错）或静默放弃检索，两者在用户看来都像插件坏了。没有文档则意味着首拉还没落地或一直失败，此时任何断言都是猜，交给后台刷新在后续 step 自愈。
+
+注意这与"空 scene 整节省略"不冲突：空的**节**是噪音（另一节仍在给 id），空的**清单**是模型手里一个 id 都没有。
+
+### bl 引导只出现在动态载体上
+
+工具描述是静态的，每次请求都付；而"怎么进一步查"取决于当下部署了什么。所以 `agent_id` 的参数描述**只指向上下文清单**，不写 `bl` 命令；`bl` 出现在两处动态文本里，且**每次出现都带安装方式**（`npm install -g bailian-cli`）：
+
+- catalog 中真正推荐了命令的分支（截断、收敛到默认服务）；
+- 4xx 之后追加的服务清单（`buildRefreshedSceneList`）。
+
+带安装行是必需的：插件走 API 直连、从不 shell out，所以一个凭据齐全的部署完全可能没装 `bl`。而安装引导原本只写在 `skills/bailian-kb/SKILL.md` 的前置检查里，那是二阶决策——要模型先决定加载 skill 才读到，恰好漏掉走工具描述兜底的那个模型。
+
 ### 缓存与刷新
 
 落点：`${DSH_HOME:-~/.dsh}/cache/bailian-kb/services-<workspaceId>.json`（临时文件 + `rename()` 原子发布，目录 `0o700`）。按 workspace 分文件是必需的：api key 只能访问自己的 workspace，而"自动获取"按钮就是为了切账号。
@@ -108,7 +124,7 @@ settings 注册是**手写**的，没有用 `installSettingsSection`：需要两
 
 ## 错误语义
 
-- HTTP 错误：4xx 时刷新服务缓存并把当前可用服务追加进错误消息（这两个接口上 `agent_id` 是唯一的调用方标识符，所以 4xx 大多是 id 已失效）；5xx 与刷新本身失败则原错误透传；
+- HTTP 错误：4xx 时刷新服务缓存并把当前可用服务追加进错误消息（这两个接口上 `agent_id` 是唯一的调用方标识符，所以 4xx 大多是 id 已失效）；刷新后该 scene **一个服务都没有**时也照样追加说明（明确"别换 id 重试"+ 建服务路径），而不是放裸错误过去——裸的 `invalid agent_id` 读起来就是"再试一个"；5xx 与刷新本身失败则原错误透传；
 - 凭证缺失：指向 `~/.dsh/.env` / `.credentials.yaml` 配置方式与控制台取 key 页面；
 - chat 超时：说明服务端多轮检索特性，建议重试或改用 `kb_search`；
 - 服务端错误体截断至 500 字符进入错误信息（优先 `code: message`）。