前言¶
DSH（DeepSeek Harness）的理念是一切皆插件，模型接入也不例外：LLM seam 上挂什么 provider，由 harness composition 决定。实际接入一个新后端时，开发者要处理的通常是三件事——凭据从哪来、token 过期怎么刷新、后端协议细节谁来封装。
如果你已经在用 kiro-cli 或 Kiro IDE，本机其实已经有一套有效的登录凭据。为 DSH 再单独登录一次，不仅多一步操作，还会造成两处 token 状态各自维护、互不同步。
下面介绍 @joshryandavis/dsh-llm-kiro。它是 DeepSeek Harness 的 Kiro（AWS CodeWhisperer/Q successor）provider，思路是拾取既有凭据、静默刷新，再把 Kiro 的 runtime 与 management API 封装成标准的 provider 路由。
这是什么¶
dsh-llm-kiro 由 joshryandavis 维护，MIT 许可证，当前版本 0.1.1。它是一个 standalone Cordis 插件：通过 cordis.yml 挂载到任意 harness composition，在 ctx.llm 上注册 kiro provider 路由，不需要改动 harness 本身。包内带有 cordis.patch.yml，因此也可以作为 profile bundle 挂载。
核心功能¶
复用既有凭据¶
插件会自动拾取两类既有登录，无需二次登录：
1、kiro-cli 登录：读取 kiro-cli SQLite 存储中的 auth_kv 表，覆盖 IDC 与社交 token；
2、Kiro IDE token：读取 ~/.aws/sso/cache/kiro-auth-token.json 及其附带的 OIDC client registration。
对 CI / bot 场景，可以在配置中设置 bearerTokenEnv 引用静态 bearer token，绕过环境凭据发现。
Token 静默刷新¶
token 过期后，插件经 AWS SSO OIDC /token 端点（Builder ID / IAM Identity Center）或 Kiro 桌面 auth 服务（Google/GitHub 社交登录）静默刷新，并回写 kiro-cli store，保证两个消费方保持同步。
流式请求中途收到 403 时，插件先重读共享 store，再回退到 kiro-cli debug refresh-auth-token；最终仍失败则以 MISSING_CREDENTIAL / AUTH 呈现。
后端协议与稳定性¶
region 解析从 SSO region 推导 Kiro API region；管理控制面覆盖 List-Available-Profiles 与 List-Available-Models，目录缓存写入共享的 ~/.kiro-management-models-cache.json。运行时调用走 AWS event-stream 协议上的 generateAssistantResponse（经 @smithy/core 的 Smithy framing），并处理容量退避、首 token 超时与 harness 空闲看门狗。
每个运行时请求携带 harness attribution User-Agent（来自 @deepseek-ai/dsh-llm 的 attributionHeaders()）以及 AWS SDK 风格的 x-amz-user-agent。
模型目录与推理力度¶
插件内置 15 个模型的 bootstrap catalog，包含上下文窗口、输出上限、推理能力与图像模态；dashed harness id 与 dotted wire id 之间做精确解析；管理发现支持 Models 页。
harness 的 off / low / high / max 推理力度词汇会映射到各模型的 authenticated effort schema，系统提示带上 Kiro thinking 标记。
安装与启用¶
包为 ESM，harness 相关包声明为 peer dependencies（dsh 系列包 >=0.0.1-rc.1，cordis 与 schemastery >=3.0.0），由宿主 DSH 安装提供。安装命令：
dsh plugin --profile <profile> add @joshryandavis/dsh-llm-kiro
把 <profile> 换成目标 profile。安装后在 cordis.yml 中挂载：
- id: llm-kiro
name: '@joshryandavis/dsh-llm-kiro'
config:
region: us-east-1 # 可选；省略时以凭据的 region 为准
reasoningEffort: high # 可选；off | low | high | max（默认 high）
对本机已有 kiro-cli 或 Kiro IDE 登录的用户，这就是全部配置：凭据自动拾取、静默刷新并回写。
典型用法¶
经过上面的步骤，插件已经在 ctx.llm 上注册了 kiro 路由。下面是两个常见场景。
CI / bot 使用静态 bearer token¶
- id: llm-kiro
name: '@joshryandavis/dsh-llm-kiro'
config:
bearerTokenEnv: KIRO_BEARER_TOKEN # 经 harness credentials service 存储
这样凭据不来自环境发现，而来自 harness credentials service 中存储的 KIRO_BEARER_TOKEN，适合无人值守环境。
运行时改配置¶
所有配置项均可选。llm-kiro 的 user-settings 段使用同一 schema，可运行时编辑，改动无需重启即作用于下一个请求。
适用场景与注意事项¶
适合两类使用者：
1、本机已有 kiro-cli 或 Kiro IDE 登录的 DSH 用户，希望零额外登录接入 Kiro 后端；
2、CI / bot，通过 bearerTokenEnv 提供静态凭据。
使用前注意：
1、插件不内置交互式登录：无环境凭据时以 MISSING_CREDENTIAL 失败并指向 kiro-cli login 或 Kiro IDE；设备码流程可在 management seam 上后续添加。
2、Legacy inline thinking dialect：推理经原生 thinkingText 事件送达；模型若在内容中输出 <thinking> 标签，会保留在可见文本块中。
3、不发出 replay state；follow-up 时历史以 provider-neutral 内容重发。
4、管理目录刷新为 pull-based（discovery 或缓存年龄触发），非后台预热；目录缓存 ~/.kiro-management-models-cache.json 与 pi-provider-kiro 共享。
5、项目使用 vitest 测试套件，共 95 个测试，凭据测试与宿主机真实的 kiro-cli / Kiro IDE 存储完全隔离。
最后一点安全提醒：插件以当前 dsh 进程的权限运行，安装前建议先检查源码与许可证（本项目为 MIT）。
结语¶
dsh-llm-kiro 解决的是一个具体问题：让 DSH 直接复用你已有的 Kiro 登录，把凭据拾取、token 静默刷新与 Kiro runtime / management API 的协议细节收进一个插件，配置全部可选、运行时可改。如果你同时在用 kiro-cli 或 Kiro IDE 与 DSH，它可以让两者共享同一份凭据状态。
- 社区目录页：https://www.skillhub.cn/plugins/joshryandavis/dsh-llm-kiro
- GitHub 仓库：https://github.com/joshryandavis/dsh-llm-kiro
SkillHub 是社区维护的独立插件目录，与 DeepSeek / 幻方无官方从属关系。
