openbkn-ai/bkn-dsh#openbkn-business-context

本修订 0.2.1-rc.3-openbkn.0.2.1-2 采用无上界准入：DSH 0.2.1-rc.3 及所有更高版本（含 alpha、rc、正式版和更高大版本）均允许尝试加载，另保留 0.2.0-rc.2。准入不等于已验证兼容；构建和实测锚点独立固定，现有接口、权限及依赖实例检查继续保留。

私有平台自动登录 rc 修订。点击CLI登录后，在独立Chrome/Edge配置中完成官方浏览器授权。自动观察并锁定平台证书，地址或证书变化后自动更新记录并要求重新授权；不要求手工选择CA。维护者已明确接受首次及变化后的自动信任：这里用观测指纹替代公共CA/主机名身份验证，不声称具备公共PKI首次身份保证。不改Host或系统全局信任，官方CLI文件不改，仅在专用子进程加载受限dispatcher。旧的附加CA配置不作为前置条件。本轮CLI/平台基线仍0.2.0，版本串OpenBKN0.2.1仍为发布标识。

本增量沿用已安装的兼容 OpenBKN CLI（本轮实测 0.2.0），授权浏览器需本机 Chrome 或 Edge。原生 MCP 的连接级 fetch 回补随插件交付，只用于插件管理的连接，不要求手工安装 companion 或修改 Host。普通 access token 到期由官方 CLI 刷新；平台撤销或拒绝续期仍须重新授权。证书有效期检查保留，过期/尚未生效的服务端证书不记作通过。

为 DeepSeek Harness 提供 OpenBKN 业务知识、网络范围治理、诊断与溯源。

English

把经过治理的企业业务知识带入 DeepSeek Harness 会话。

0.2.1 版本与兼容范围

本线发布版本为 0.2.1-rc.3-openbkn.0.2.1-2，准入范围为官方 DSH 0.2.0-rc.2 或 >=0.2.1-rc.3，不设版本上界。版本串中的 OpenBKN 0.2.1 为维护者指定的版本标识；当前实际平台证据来自保留的正式 OpenBKN 0.2.0 与 CLI 0.2.0，不声明已在尚未发布的 OpenBKN 0.2.1 平台验收。具体测试覆盖和已知限制以对应 GitHub Release 的验收记录为准。

本修订的原生 MCP 同源保护随插件交付并由业务模块自动加载，无需另装 profile companion 或修改官方 Host。较早基础版的 companion 说明仅适用于其历史包；冻结 -30/-31/-32 及历史判定保持原样。

历史开发检查点

本分支当前兼容目标为官方 DSH 0.2.0-rc.2 与 0.2.1-rc.3，平台仍采用正式 OpenBKN v0.2.0 和 CLI 0.2.0，保留旧构建生成器。当前 -32 为本地开发候选，尚非最终 CI 候选或正式验收结果；冻结的 -30/-31 及其 rc.2 交接证据保持原样，不作为 rc.3 验收。

本地开发版在宿主提供文件服务时使用受会话约束的 openbkn_export_csv 交付已有平台 CSV：校验后将原始 UTF-8 字节（最多512 KiB）保存为当前 DSH 工作区的新文件。导出要求当前绑定的 Interaction 和工作区写权限；只读会话会拒绝。导出成功后可打开返回的本地文件链接。Host read/grep/present 仍不开放。受管指引要求回答和 CSV 序列化保留来源精度，并避免 Python 默认通用格式的六位有效数字截断；仅按用户或平台明示规则取整。模型回答和文件内容仍须独立验证。

导出结果返回已验证的 markdown_link，最终回答须在结束 Interaction 后一并给出答案、口径和该链接，避免折叠进度消息造成漏链。统计范围与所请求计算的符号依平台合同；插件不重算业务结果。

正式版关闭采集时仍返回 managed Conversation/Interaction ID：业务调用继续携带所要求的 bkn_context，finish 使用当前 Interaction ID。溯源保留已披露身份，明确标注未记录证据并显示本地时间线；旧部署显式无身份降级保留为独立兼容路径。插件不重算业务结果、不改模型回答。

源码测试、官方 npm 包集合受控运行、固定 CI 候选、真实平台调用及人工验收分开记录。两个 DSH × Mac/Windows × Desktop/npm 的八个组合，仍待固定 CI 候选实机验收。不会自动升级现有安装。

为什么需要 bkn-dsh

通用 AI 可以流畅地推理，但通常缺少真实业务决策所需的可信上下文。企业知识分散在系统、规则、流程、指标和业务关系中，同时其访问必须始终符合当前用户的身份和权限。

OpenBKN 将这些分散知识组织为可治理的业务知识网络。bkn-dsh 则让用户可以在日常分析和行动发生的地方——DeepSeek Harness 会话中——直接使用这些知识网络。

它做什么

bkn-dsh 连接 DeepSeek Harness 与 OpenBKN，使经过授权的用户可以：

• 登录 OpenBKN，同时不影响 DSH 本地工作；
• 选择自己有权访问的业务知识网络；
• 基于该网络中的业务对象、关系、规则和指标分析业务问题；
• 让每个会话始终限定在一个明确的业务上下文中；
• 查看每轮结果的分层溯源视图：恒可渲染的本地执行时间链、独立降级的平台执行事实（Request/Trace/Receipt）与企业业务图、以及带 CLI 核验指引的回执清单。

该能力以 DSH 增量插件的方式集成，保留 DSH 原生会话体验；OpenBKN 继续负责身份、权限、业务语义和可追踪证据。

普通回答使用工具结果与 DSH 原生模型输出。插件负责访问与 Interaction 边界，不改写回答、不强制报表格式，也不因自然语言一致性自动重试或拒绝回合。完成状态表示执行结束；事实正确性通过独立评测核对。

面向谁

• 业务用户：无需学习查询语言或平台 API，也能获得可靠业务分析。
• 分析师与决策者：不仅需要答案，还需要理解背后的业务对象、关系、指标和证据。
• 企业 AI 平台团队：希望在不向用户或模型开放无限制数据接口的前提下，提供受治理的知识访问。
• 知识网络所有者：希望沉淀的业务语义能在日常 AI 工作流中被一致、准确地使用。

业务价值

• 提高分析准确性：回答建立在明确业务语义和当前授权数据之上。
• 降低企业应用风险：用户和模型始终受所选知识网络及平台权限边界约束。
• 支持可解释决策：每轮分析都可以追溯到业务上下文、执行事实和可用证据。
• 降低交互成本：用户可以自然提问，不必在多个系统间切换或编写技术查询。
• 复用组织知识：经过治理的知识网络成为跨会话、跨团队共享的决策语义层。

安装并开始使用

使用未打补丁的官方 DeepSeek Harness >=0.2.1-rc.3 或保留的旧版 0.2.0-rc.2（新版本均允许尝试加载）：官方桌面版、对应版本 npm 命令行或构建后的源码检出。在 DSH 的插件页面选择添加插件，填写 @openbkn/dsh-business-context@0.2.1-rc.3-openbkn.0.2.1-2 并选择安装源。也可以停止 DSH 后执行：

dsh plugin --profile <desktop|web> add @openbkn/dsh-business-context@0.2.1-rc.3-openbkn.0.2.1-2

Windows 上使用 dsh.cmd。源码构建从 DSH 源码根目录执行 node apps/cli/lib/bin.js plugin --profile web add @openbkn/dsh-business-context@0.2.1-rc.3-openbkn.0.2.1-2。请使用实际启动的 Host 的 profile 与 DSH_HOME，desktop 和 web 是独立的 profile。安装下载包时，把包名替换为 .tgz 的绝对路径。

对本次实测的正式 OpenBKN 0.2.0，使用官方 CLI @openbkn/bkn-sdk@0.2.0；其他平台须选择其兼容 CLI。已有可用 CLI 保留，不自动升级。配置插件前不必先登录，面板会启动官方授权。npm 版 DSH 还需要 PATH 中有 pnpm（pnpm@11.7.0），桌面版自带。自动信任的范围和首次身份限制见上方说明。

配置、授权、提问

1. 启动 DSH，点击侧栏底部的 OpenBKN。未设置地址是正常的待配置状态，诊断仍可打开。配置前，插件不会连接 OpenBKN，也不会读取它的 CLI 凭据。
2. 填写绝对 http:// 或 https:// 平台地址，点击保存并继续。非法输入会被拒绝，不改动已保存配置。地址通过 DSH 配置编辑器保存到当前 profile，按正常组件重载应用；保存地址不代表连接或授权已经成功。
3. 展开高级设置检测 CLI，默认命令是 openbkn。检测到可用 CLI 后会显示版本并填入实际路径，点击保存并继续应用。未检测到时，检测并安装 CLI会先复查，再通过本机 npm 的安装源和全局目录安装所选 SDK 版本（0.1.5 或 0.2.0），请按平台版本选择；本机需已有 Node.js 22.19+ 和 npm。已有可用 CLI 保留，不自动升级；损坏安装或自定义路径错误需先修正，不自动覆盖。Windows 上的绝对路径包含 shim 文件名，如 C:/Users/<你>/AppData/Roaming/npm/openbkn.cmd。以后可从右上角设置编辑；业务回合运行时先等它结束。
4. 点击使用 OpenBKN CLI 登录并同步，在浏览器完成授权，再回到 DSH。已有凭据被拒绝时，也使用这个入口重新登录。403 可能需要管理员授予权限，同账号重新登录不能保证恢复。
5. 选择有权限的知识网络，新建或继续其工作区，在新会话中保持标准模式再提问。暂不支持 PTC 模式。完成的回答提供查看业务溯源。

表单保留其他配置字段；更高优先级的覆盖阻止设置生效时，会明确报告。临时网络/TLS 失败不会清空已保存地址。已有会话保留原平台与网络绑定，改地址不会自动改绑。这条流程无需编辑 YAML，也不需要手动粘贴 Token；凭据仍由 OpenBKN CLI 与 DSH 凭证管理，不要把 Token 写进配置文件。

关闭面板后，旧请求完成不会重新打开它；这不代表已取消正在进行的浏览器授权。完整步骤及目录选择器说明见仓库 README。

卸载

在 DSH 的插件页面移除整包。宿主若要求停止 profile，先停止再重试。也可以停止 DSH 后执行：

dsh plugin --profile <desktop|web> remove @openbkn/dsh-business-context

卸载会卸载包组件、移除 profile 包依赖，保留用户 profile 配置、DSH/OpenBKN 凭据、CLI 安装与登录状态、会话、网络/工作区绑定和工作区文件。CLI 是独立安装的工具，卸载插件不会移除它，也不会退出账号或清空数据。不要删除整个 node_modules/@openbkn 目录，其中可能还有其他包。重装后可复用保留的配置与绑定。

当前版本不向 DSH 会话日志添加插件事件，因此卸载后会话仍可读。最早的 0.2.0-rc.2-openbkn.0.2.0 版本另有会话日志限制，见仓库历史说明。插件安装期间可能清理对应会话已不存在且记录至少七天的绑定；卸载不会执行全量清理。

包入口结构（-7 起调整）

包根是最小引导插件，仅保证宿主持续下发本包的浏览器端。业务 API 请从 @openbkn/dsh-business-context/business 导入；Remote 边界类型在 @openbkn/dsh-business-context/types。诊断入口仍为 @openbkn/dsh-business-context/diagnostics。

升级 -7：name 断言配置需迁移

宿主把 profile override 里的 name 字段当作对目标 row 的断言。从已发布的 <= -4 版本升级到 -7 时 业务 row 的加载路径变为 @openbkn/dsh-business-context/business，保留旧 裸包名的 override 会被整条跳过，其 config（如 baseUrl、cliPath） 不会生效：

# 升级到 -7 后不再匹配 —— baseUrl/cliPath 会丢失：
- id: openbkn-business-context
  name: '@openbkn/dsh-business-context'
  config: { baseUrl: ..., cliPath: ... }

修复方式：删除 name 行（仅用 id 定位 row），或把断言改为新子路径名 '@openbkn/dsh-business-context/business'。仅用 id 的配置不受影响。

诊断

遇到问题时，点击侧边栏底部的 OpenBKN，再点击弹出面板右上角的 诊断 并导出报告。侧边栏只有一个 OpenBKN 入口。即使业务组件导入失败或服务尚未就绪，面板外框和诊断按钮仍可用；诊断服务作为独立插件行运行，不依赖业务服务。诊断实现无法启动时，面板会明确提示诊断服务不可用。导出的 JSON 只包含白名单事实——阶段、分类代码、受限证据（HTTP 状态、退出码等）与覆盖说明，绝不包含令牌、原始错误文本、URL 或文件内容。把导出的文件发给支持人员即可。

诊断基础信息中的 win32 显示为 Windows，不表示 32 位系统。无法确认的运行形态和版本会说明“未识别”或“未采集”的原因；这不代表检查失败。磁盘版本与已加载版本保持独立，导出 JSON 保留原始平台标识和空值。

License

Apache License 2.0