支持将 Kimi Code 作为 VS Code 原生 Chat Session Target（Experimental）

[groot-guo]

What feature would you like to see?

希望 Kimi Code 可以作为 VS Code 原生 Chat 的 Session Target / Agent Harness 被选择，而不再只能通过左侧 Activity Bar Webview 使用。

用户应能在原生 Chat composer 底部、默认显示为 Local 的 harness 选择器中选择 Kimi Code。选择后，后续任务由 Kimi Code 自己的 session、Agent loop、工具调用、权限、Plan Mode 和子 Agent 能力执行；VS Code 使用原生 Chat UI 展示对话、工具调用、审批、问题和 session 历史。

这不是“在模型选择器中加入 Kimi 模型”的需求。目标是选择完整的 Kimi Code Agent Harness，类似选择 Claude Code 或 Codex。

首期范围是普通 VS Code 窗口中的原生 Chat；独立 Agents Window 的支持将在普通 Chat 稳定后单独跟进。

Additional information

背景与参考

当前 apps/vscode 扩展以 Activity Bar Webview 为主。它已经拥有 KimiHarness、Kimi session、历史恢复、事件订阅、审批和问题处理能力，因此具备实现原生 Chat adapter 的基础。

参考实现：

https://github.com/kalynnka/vscode-deepseek-harness

该项目使用 VS Code chatSessions proposed API，将 DeepSeek Harness 注册为原生 Chat 的 Session Target。用户可在 Chat 底部的 harness 选择器中选择 DeepSeek Harness；它不是第二个 Webview，也不是仅注册一个语言模型。

Kimi Code 应参考其“原生 Chat Session Target”的路径，但直接复用 Kimi Code 的 Node SDK 和 Kimi session，而不是复用 DSH 的 HTTP/WebSocket 协议。

用户体验目标

1. 用户安装 Kimi Code 的 Experimental VSIX，并按文档授予所需 proposed APIs。
2. 用户在 VS Code 原生 Chat 新建会话。
3. 用户在 Session Target 选择器中选择 Kimi Code。
4. 用户在原生 Chat 内使用完整 Kimi Code：
   • 新建、打开、恢复 Kimi session
   • 流式查看回答、thinking、工具调用和文件修改
   • 回答 Kimi 问题、批准或拒绝操作
   • 取消和 fork session
   • 切换 Kimi 模型、thinking effort、Plan Mode 和权限模式
5. 现有 Kimi Code 左侧 Webview 继续可用。

架构方向

功能应实现于现有 apps/vscode 代码中，并与 Webview 共存：

KimiHarness / Kimi session registry
├── 现有 KimiWebviewProvider
└── 新增 KimiChatSessionProvider

两种 UI 共用登录态、模型目录、session 持久化、workdir 校验和权限语义，但不共用 UI bridge 协议。

Native Chat adapter 负责：

• Kimi session summary / resume state -> VS Code Chat session list 与历史
• Kimi prompt / steer -> 原生 Chat request handler
• Kimi text / thinking / tool / file-change event -> ChatResponseStream
• Kimi question / approval -> VS Code 原生 question / confirmation UI
• Kimi cancel / fork / model / thinking / plan / permission -> 原生 session controls

现有 Webview 侧已能从 Kimi SDK resume state 回放历史，可作为 transcript 映射的实现参考。

发布策略

首期不等待 stable API。

由于 chatSessions 目前是 proposed API，建议先为当前扩展增加 Experimental build profile：

• Experimental VSIX 与正式扩展使用相同 extension id；
• Experimental 包同时包含现有 Webview 和新的 Native Chat Session Target；
• 用户安装 Experimental VSIX 时替换 Marketplace 正式版；
• Marketplace 正式构建不包含 proposed API，不受影响；
• API 稳定后，再将该功能纳入正式发布包。

不建议首期创建可与正式扩展同时安装的第二个 extension id，因为两个 extension host 同时管理同一批 Kimi session 会增加 session 所有权、事件重复和配置冲突风险。

里程碑

M0：Experimental 基础

• 确定最低 VS Code 版本与 proposal API types
• 增加 Experimental manifest/build profile
• 增加 proposed API runtime probe
• 编写 VSIX 安装和 argv.json 授权文档
• 验证 Kimi Code 出现在原生 Chat 的 Session Target 选择器

M1：只读 session

• 列出和打开当前 workspace 的 Kimi sessions
• 从 Kimi resume state 恢复原生 Chat transcript
• 显示历史回答、thinking、工具调用、错误和变更
• 校验 workdir / workspace 一致性
• 在这一阶段保持只读，先验证 session 与 transcript 映射

M2：原生 Chat 对话

• 新建 Kimi session
• 原生 Chat prompt 映射到 Kimi prompt
• 流式渲染文本、thinking、工具调用、文件修改和错误
• 支持重新打开运行中的 session
• 支持取消 turn
• 支持最小可用的 selection、文件和图片上下文

M3：交互与控制

• Kimi question -> 原生 question UI
• Kimi approval -> 原生 confirmation UI
• Kimi session 状态 -> running / needs input / completed / failed
• 新建、重命名、fork、恢复 session
• 模型、thinking effort、Plan Mode、permission mode picker
• 抽取当前 Webview reverse-RPC，使 Webview 和 Native Chat 共用 Kimi 交互语义

M4：普通 Chat 稳定化

• 为恢复、取消、问题、审批、fork、模型切换补测试
• 验证多 root / remote workspace / 未登录行为
• 发布 Experimental VSIX 并收集反馈
• 文档化支持范围、版本要求和降级行为

后续：Agents Window

普通 VS Code Chat 稳定后，单独创建 follow-up issue：

支持 Kimi Code Session Target 在 VS Code Agents Window 中运行

该后续项将验证：

• extensions.supportAgentsWindow 下的扩展激活
• Chat 与 Agents Window 间的 Kimi session 恢复和切换
• 原生问题、审批、工具调用与文件修改渲染
• 已知限制和所需用户配置

不把独立顶层 Kimi tab 作为承诺；第三方 session type 目前受 VS Code 内置 allowlist 限制。

希望确认的事项

1. 是否接受以 proposed chatSessions API 作为 Experimental 首期技术路线？
2. 是否接受“当前扩展 + Experimental build profile”的发布策略？
3. apps/vscode 的 Native Chat adapter 是否应优先抽取为 host-neutral Kimi session 层？
4. 请指定 Kimi SDK / session runtime 边界的 reviewer。

[groot-guo]

@wbxl2000 @Grapedge

我参考了 apps/vscode 现有的 Node SDK / session 架构，并希望将 Kimi Code
接入 VS Code 原生 Chat 的 Session Target 选择器，同时保留现有 Webview。

我看到：

• @wbxl2000 主导了 VS Code 扩展迁入 monorepo 和 Node SDK session 集成（feat(vscode): migrate extension to Node SDK #1769）；
• @Grapedge 近期维护了 VS Code session/runtime，并合并了近期 VS Code PR（feat(vscode): engine-backed @ file suggestions #3453）。

能否请两位帮助确认：

1. 这个 chatSessions Experimental 路线是否符合 roadmap；
2. 谁适合作为该 feature 的 primary owner / reviewer；
3. Kimi SDK、session runtime、VS Code extension 三个边界是否需要分别指定 reviewer；
4. 若接受该方向，后续 M0–M4 分阶段 PR 应由谁持续 review 和合并。