跳到主要内容

交付面:单二进制 TUI、CLI、SDK 与编辑器(ACP)

30 秒导读: 前五章(见 index)讲的是引擎——回合循环、Agent 主机、工具、provider、v2 再工程化。这一章讲引擎怎么被人和程序摸到:装一个 kimi 命令后,同一个二进制里其实塞了好几副"皮套"——终端交互界面(TUI)、跑一句就退的无头模式(kimi -p)、给外部程序调用的 TypeScript SDK、以及让 Zed/JetBrains 直接驱动的编辑器协议(ACP)。本章只讲这些接触面,不重复引擎内部。

1. 这是什么(零基础也能懂)​

1.1 先说清楚"交付面"这个词​

交付面(delivery surface)= 用户或外部程序接触这套 agent 引擎的那层皮。 引擎本身(会读代码、会调工具、会跟大模型对话)是一个内核;但内核不能直接被人用——人要么在终端里敲字看它干活,要么写脚本让它跑一句就吐结果,要么在编辑器里点两下就用上。每一种"用法"就是一个交付面。

一句类比:引擎是发动机,交付面是方向盘、油门、和车载 App——同一台发动机,可以装进轿车(TUI)、装进赛车(无头 CLI)、也可以把接口暴露给别的车厂(SDK)。

1.2 Kimi Code 一共有几个面​

主交付面全部由一个可执行文件 kimi 提供(单二进制,见 §4),按"谁在用、怎么用"分成四类:

交付面谁在用长什么样入口
TUI(终端 UI)人,交互式长会话敲 kimi,进一个全屏终端界面apps/kimi-code/src/tui/
CLI 无头模式脚本 / CI / 管道kimi -p "...",跑完打印就退apps/kimi-code/src/cli/run-prompt.ts
SDK 门面外部 TS 程序import { createKimiHarness }packages/node-sdk/
ACP 编辑器桥Zed / JetBrains 等kimi acp,走 stdio JSON-RPCpackages/acp-adapter/

外围还有三个独立应用级交付面(不在 kimi 二进制里,§6):浏览器 Web UI(apps/kimi-web)、VS Code 插件(apps/vscode)、调试检查器(apps/kimi-inspect)。

1.3 用起来什么样​

最小三种触法,直观感受一下:

# 1. 交互式 TUI —— 进全屏界面,像聊天一样干活
$ cd my-project
$ kimi

# 2. 无头模式 —— 跑一句,把回答打到 stdout 就退(可进管道 / CI)
$ kimi -p "解释这个仓库的主要目录" --output-format stream-json

# 3. 编辑器集成 —— 让 Zed 通过 stdio 驱动一个 kimi 会话
$ kimi acp

1.4 一句话直觉​

把 kimi 想成一个"多头插座":插座内部是同一套电(引擎),但面板上开了 TUI、CLI、SDK、ACP 四个不同形状的孔,谁需要哪种就插哪个。 本章就是把这四个孔各自怎么接线讲清楚。

2. 顶层全景(它大概怎么转)​

2.1 一张图看清所有面怎么连回引擎​

怎么读这张图:左边是各交付面(皮套),中间是公共门面 SDK,右边是两代引擎。 关键在于——除了 v2 的两条原生路径,几乎所有面都收敛到 @moonshot-ai/kimi-code-sdk 这个公共门面,再由门面接进引擎。

   交付面(皮套)                    公共门面                引擎(01-05 章)
 ┌───────────────────┐
 │ TUI  (kimi)        │──┐
 ├───────────────────┤  │
 │ CLI -p  (v1 默认)  │──┤      ┌────────────────────┐      ┌──────────────┐
 ├───────────────────┤  ├────► │ node-sdk           │────► │ agent-core   │
 │ ACP  (kimi acp)    │──┤      │ KimiHarness/Session│      │ (v1 引擎)    │
 ├───────────────────┤  │      │ 进程内 RPC 门面     │      └──────────────┘
 │ VS Code 插件        │──┘      └────────────────────┘
 ├───────────────────┤
 │ CLI -p  (v2 实验)  │──────────────────────────────────► ┌──────────────┐
 ├───────────────────┤              原生 DI 服务,不经门面   │ agent-core-v2│
 │ kimi web (kap-svr) │──────────────────────────────────► │ (v2 引擎)    │
 └───────────────────┘              REST/WS 服务器          └──────────────┘
       ▲                                                      ▲
       │ Web UI / Inspector 经 REST+WS 连 kap-server ─────────┘
       └── apps/kimi-web · apps/kimi-inspect

2.2 部件一句话职责​

部件干什么在哪
main()进程入口:装崩溃/代理钩子,建 commander 程序,分流apps/kimi-code/src/main.ts:135
commander 程序解析参数 + 注册所有子命令apps/kimi-code/src/cli/commands.ts:19 createProgram
runShell启动 TUI 交付面apps/kimi-code/src/cli/run-shell.ts:35
runPrompt启动无头交付面,并在 v1/v2 间分叉apps/kimi-code/src/cli/run-prompt.ts:97
node-sdk公共门面:进程内 RPC,抹掉引擎细节packages/node-sdk/src/index.ts
acp-adapter把 ACP 协议桥到 SDKpackages/acp-adapter/src/server.ts:1069 runAcpServer
kap-serverv2 引擎的 REST/WS 服务器(kimi web 启动)apps/kimi-code/src/cli/sub/web/run.ts

2.3 主线走一遍(不进代码)​

一次 kimi ... 从敲下到落到引擎,只走三步:

  1. 入口装钩子。 main() 先装崩溃处理、全局 HTTP 代理、原生模块加载钩子,再判断是不是"跑一次原生资源自检就退",然后建 commander 程序(main.ts:135-221)。
  2. 参数分流。 commander 解析出:是子命令(acp / web / login / export / upgrade …)就走对应子命令;否则走默认命令 handleMainCommand,由它按"有没有 -p"决定 uiMode——print 走 runPrompt(无头),否则走 runShell(TUI)(main.ts:54-84、options.ts:62 validateOptions)。
  3. 接进引擎。 除 v2 原生路径外,每个面最终都拿到一个 KimiHarness(SDK 门面),再用它 createSession / prompt 驱动引擎。

3. 核心原理(逐个交付面)​

3.1 入口分流:一个 kimi 如何变成五种行为​

要解决的小问题: 同一个二进制,既要能进 TUI、又要能无头跑、还要能当 ACP 服务器——靠什么把一行命令劈成不同行为?

思路: 全交给 Commander.js(Node 的命令行解析库)。createProgram 一次性挂上所有子命令和顶层选项,再挂一个"默认命令"兜底(没匹配到子命令时走它)。

真实实现:createProgram 注册子命令的段落很直白——

// apps/kimi-code/src/cli/commands.ts:89 —— 每个子命令一行注册
registerExportCommand(program);
registerProviderCommand(program);
registerAcpCommand(program);   // kimi acp
registerWebCommand(program);   // kimi web
registerLoginCommand(program);
registerDoctorCommand(program);
registerVisCommand(program);

默认命令在 commands.ts:114 的 program.argument('[args...]'):它把顶层选项(-p / -S / --yolo / --auto / --plan / --model …)收成一个 CLIOptions,交给 onMain(即 main.ts 里的 handleMainCommand)。

关键细节——uiMode 由 -p 单点决定。 validateOptions 做完一堆互斥校验(比如 -p 不能和 --yolo/--auto/--plan 同用),最后一行 uiMode: promptMode ? 'print' : 'shell'——有 -p 就是无头 print,否则就是交互 shell(options.ts:98)。这个 uiMode 会一路带到引擎,让 v1 core 对 print 模式套用不同的默认配置。

3.2 无头 CLI(kimi -p):跑一句就退,还要退得干净​

要解决的小问题: 脚本和 CI 要"给一句 prompt,拿到回答,进程干净退出、退出码正确"。这里有两个真难点:双引擎分叉、和怎么保证 print 跑完真能退出。

双引擎分叉:v1 默认,v2 实验​

runPrompt 第一件事就是查实验开关:开关开则整条路由到 v2 原生 runner,否则走 v1 门面路径。

// apps/kimi-code/src/cli/run-prompt.ts:102 —— 开关开则整条切到 v2
if (isKimiV2Enabled()) {
  const { runV2Print } = await import('./v2/run-v2-print');  // 懒加载,v2 模块图不污染 v1 路径
  await runV2Print(opts, version, io);
  return;
}
  • 开关是什么: 环境变量 KIMI_CODE_EXPERIMENTAL_FLAG,直接读 env、不依赖 core 的 flag 注册表(experimental-v2.ts:14 KIMI_V2_ENV、:25 isKimiV2Enabled)。
  • 两条路的差别: v1 路径把引擎藏在 PromptHarness/PromptSession 这组窄接口后面(prompt-session.ts:35-66),v1 的 KimiHarness/Session 天然满足这组接口,无需适配器。v2 路径(v2/run-v2-print.ts:92 runV2Print)则直接 bootstrap() v2 的 DI app 作用域,用原生服务 IAgentPromptService.enqueue() 驱动一个回合,订阅 per-agent 的 IEventBus 渲染事件——不经 SDK 门面、不做 v2→v1 事件翻译(见 05-v2-architecture)。

同一个 print driver 能骑两匹马,靠的是"面向窄接口编程"这一层间接。

这是 print 模式最反直觉的坑:print 模式从不主动调 process.exit(),它靠 Node 事件循环自然排空后退出。 万一有一个赖着不走的 ref'd 句柄(被防火墙黑洞掉的 socket、没清的定时器、子进程管道没关),循环永远排不空,进程就挂住。

解法是"先排空 stdio,再武装一个 unref'd 的兜底强杀定时器":

// apps/kimi-code/src/cli/headless-exit.ts:88 —— 完成后收尾:先冲刷,再兜底
export async function finalizeHeadlessRun(proc, streams, getExitCode, options = {}) {
  await drainStdio(streams, ...);                 // 先把在途的合法输出写完
  scheduleHeadlessForceExit(proc, getExitCode, options.graceMs);  // 再武装 unref'd 强杀
}

scheduleHeadlessForceExit 里 timer.unref?.()(headless-exit.ts:37)是精髓:健康的 run 会在定时器触发前自然退出(行为不变),定时器本身不会拖住循环;只有真正泄漏句柄的 run 才被它强杀。这个收尾由入口在 outcome.headlessCompleted 时调用(main.ts:166-172)。

退出码也要对。 main() 的 catch 里第一行就是 process.exitCode = 1,而且是在任何 await 之前同步设置——否则失败的 run 在 await 期间把循环排空,Node 会用默认码 0 退出,导致无头失败"随机退出 0"(main.ts:184 及其上方长注释)。

3.3 TUI:建在 pi-tui 之上,靠反向 RPC 问人​

要解决的小问题: 终端里要渲染一个能滚动、能弹审批框、能问问题、能跑斜杠命令的全屏界面,还要在崩溃时把终端恢复原样。

思路: UI 层不自己造轮子,建在 pi-tui 之上(README 致谢:"Our TUI is built on top of pi-tui",README.md:128)。KimiTUI 这个大类把 pi-tui 的组件(Component/Focusable,kimi-tui.ts:16-22)组装成聊天流、审批面板、会话选择器等。

反向 RPC:引擎回头问人​

普通 RPC 是"客户端问服务端"。但 agent 干活时会反过来找人:要不要批准这次工具调用?这道题选哪个?这叫反向 RPC(reverse-RPC)。TUI 把引擎发来的审批/提问请求,翻译成屏幕上的模态框:

引擎(要审批 / 要提问)
      │  ApprovalRequest / QuestionRequest
      ▼
ReverseRpcModalCoordinator ── 协调"同一时刻只弹一个模态"
      │
      ├─► ApprovalController ─► 审批面板组件(approve once / always / reject)
      └─► QuestionController ─► 提问对话框组件

registerReverseRPCHandlers 把两个 controller 的 UI 钩子都接到一个 ReverseRpcModalCoordinator 上(reverse-rpc/index.ts:13-44),由它保证审批框和提问框不会同时弹出来打架。审批的选项 id(approve_once/approve_always/reject)在 SDK/ACP 侧是同一套字面量,见 §3.5。

斜杠命令与优雅退出​

  • 斜杠命令:一张注册表列出所有内建命令(/model、/plan、/mcp、/web、/login …,共 40 来个),见 tui/commands/registry.ts:137 起。技能和插件命令再动态并进去。
  • 终端恢复:TUI 抓了 raw 模式和 XON/XOFF,一旦没走正常 stop() 就崩溃,run-shell.ts:162 的 emergencyExit 会同步冲刷崩溃日志、restoreTerminalModes() + restoreStty(),再退出——保证用户的 shell 事后还能用。

3.4 SDK 门面:外部程序消费引擎的公共门脸​

要解决的小问题: CLI 自己、VS Code 插件、ACP 适配器、以及任何第三方 TS 程序,都需要一个稳定、干净的方式驱动引擎,而不该直接依赖 agent-core 内部。

思路: packages/node-sdk 就是这个公共门面。它导出 createKimiHarness / KimiHarness / Session 三件套(index.ts:1-5),内部用进程内 RPC(createRPC<CoreAPI, SDKAPI>())把调用转成对 KimiCore 的消息——即使是进程内直连,也走 RPC 抽象,这样将来换成守护进程/远程 core 时门面不变。

// packages/node-sdk/src/sdk-rpc-client.ts:77 —— 进程内建立双向 RPC,再造 core
const [coreRpc, sdkRpc] = createRPC<CoreAPI, SDKAPI>();
this.core = new KimiCore(coreRpc, { /* homeDir, headers, oauth, telemetry, uiMode ... */ });
this.ready = sdkRpc(new ClientAPI(this));

外部程序拿到 harness 后的典型用法:createSession 拿到 Session,session.onEvent(...) 订阅事件、session.setApprovalHandler(...) 挂审批回调、session.prompt(...) 发一轮(session.ts:52 class Session、:87 onEvent、:96 setApprovalHandler、:106 prompt)。

注意架构红线: apps/kimi-code 只准依赖 @moonshot-ai/kimi-code-sdk,不准直接依赖 @moonshot-ai/agent-core(依据:仓库 AGENTS.md 项目地图)。SDK 就是那道墙。

SDK 还兼作 provider 门面。 KimiForCodingProvider(kimi-code-model-provider.ts:36)实现 kosong 的 ModelProvider 接口,把 Kimi 托管 OAuth 封装成一个可被引擎直接用的大模型 provider——这是 SDK 的另一副面孔(见 04-providers)。

3.5 ACP:让编辑器直接驱动一个 kimi 会话​

要解决的小问题: Zed、JetBrains 这类编辑器想内嵌 agent,但不该懂 kimi 的内部;需要一个标准协议在编辑器和 agent 之间说话。

思路: 实现 Agent Client Protocol(ACP)——一套基于 stdio 的 JSON-RPC 协议。kimi acp 子命令启动一个 ACP 服务器,packages/acp-adapter 把 ACP 的方法翻译成 SDK 门面的调用。

数据流(编辑器 ⇄ kimi):

Zed / JetBrains
   │  stdio 上的 JSON-RPC(ndjson)
   ▼
runAcpServer  ── 先把 rogue console.* 重定向到 stderr(保护 stdout 这条 JSON 通道)
   │
   ▼
AcpServer(implements Agent)
   │  initialize / session.new / session.prompt / session.cancel ...
   ▼
KimiHarness(SDK 门面) ─► 引擎

AcpServer 逐个实现 ACP 的方法并映射到 harness(server.ts:221 class AcpServer):

ACP 方法映射到说明
initialize通告能力声明支持 image/embeddedContext、MCP over http/sse、session list/resume,并广告 terminal-auth 登录法(server.ts:305)
session/newharness.createSessionACP 的 cwd 映射到 SDK 的 workDir;ACP 传的 MCP server 一并转发(server.ts:341)
session/load / resumeharness.resumeSessionload 会重放历史,resume 故意不重放(server.ts:448、:484)
session/promptAcpSession.prompt内容块转 PromptPart,图片按需压缩(convert.ts acpBlocksToPromptParts)
session/cancelAcpSession.cancel通知型,不能返回错误,只能 log

几处巧妙:

  • stdout 是命令通道,必须干净。 runAcpServer 一进来就 redirectConsoleToStderr()(server.ts:1108),防止任何依赖 console.log 污染 JSON-RPC。
  • 审批经协议桥接。 引擎的审批请求转成 ACP 的 PermissionOption,选项 id 复用 approve_once/approve_always/reject 这套字面量(approval.ts:20-22),与 TUI(§3.3)保持同一套语义。
  • 登录不在协议内做。 stdio 通道没有 TTY 渲染不了设备码,所以 ACP 只广告一个 terminal-auth 方法,让客户端自己 spawn kimi login 子进程完成登录,再回来确认 token 落盘(server.ts:654 authenticate 及注释)。这也是 kimi acp --login 存在的原因(sub/acp.ts:47)。
  • 优雅收尾。 SIGINT/SIGTERM 触发一次性 harness.close() 排空在途会话,finally 里先卸载 handler 再收尾,好让第二次 Ctrl-C 直达默认 handler 强杀(server.ts:1114-1162)。

4. 单二进制打包:如何做到"免装 Node"​

要解决的小问题: README 承诺"一条命令装好,无需 Node.js"(README.md:14、:61)。但这是个 TypeScript/Node 项目——怎么让没装 Node 的机器也能跑?

思路: 用 Node 官方的 SEA(Single Executable Application,单可执行应用)——把整个 JS bundle 和资源塞进一份 blob,再注入到一份 Node 运行时可执行文件里,产出一个自带运行时的 kimi。

打包流水线(scripts/native/build.mjs 串起五步):

01-bundle   把 src 打成单个 JS bundle(tsdown)
02-sea-blob 收集原生资源 + web 资产,生成 SEA 配置与 blob
03-inject   复制一份 node 可执行,用 postject 把 blob 注进去
04-sign     签名(macOS codesign / Windows signtool)
05-verify   校验产物

两个关键机制:

  1. 原生 .node 模块怎么办? SEA 里不能直接 require 磁盘上的 .node。构建期把这些原生资源(如 pi-tui 的终端原生助手、node-pty)作为 SEA 资产打包;运行期 installNativeModuleHook() 拦截对 pi-tui 原生助手的绝对路径 require,重定向到从 blob 解出、缓存到本地的副本(native/module-hook.ts:25 的 PI_TUI_NATIVE_PATTERN、native/native-assets.ts)。启动时还会 queueMicrotask 后台清理过期缓存(main.ts:146)。
  2. 版本号从哪来? getVersion() 优先读构建期注入的 KIMI_BUILD_INFO.version,否则回退读 package.json(cli/version.ts:41)。

除单二进制外,也支持 npm 安装(bin.kimi → dist/main.mjs,package.json)和 Homebrew;kimi upgrade 提供自更新(main.ts:211 → handleUpgradeCommand),日常启动还有一次被动更新预检 runUpdatePreflight(main.ts:69、cli/update/preflight.ts),按 rollout 分桶决定要不要提示/自动装新版。

5. 生态呈现:插件、技能、MCP、登录、遥测​

交付面不止"怎么进",还包括"进来后能装什么、连什么"。这些生态入口大多以会话式方式呈现,而非手改 JSON。

  • 插件市场。 plugins/marketplace.json 列出可装插件,每条带 tier(official/curated)和来源(本地目录或 GitHub repo);官方插件放 plugins/official/(如 kimi-datasource)。TUI 里 /plugins 命令管理(registry.ts:242),安装时把每个来源的信任级别先摆到台面上(README.md:66)。
  • MCP 会话式配置。 /mcp-config 不是普通注册表命令,而是一个内建技能(packages/agent-core-v2/.../skillCatalog/builtin/mcp-config.md),用户在对话里说"加个 server / 登录",由这个技能引导完成——避免手写 JSON。/mcp 命令则只看状态(registry.ts:235)。
  • OAuth 登录。 packages/oauth(@moonshot-ai/kimi-code-oauth)封装设备码登录、托管 token、provider 模型刷新等;kimi login(sub/login.ts:15)与 TUI 的 /login、ACP 的 terminal-auth 都汇到它。
  • 遥测。 packages/telemetry(@moonshot-ai/kimi-telemetry)提供崩溃处理、上下文、track;各交付面启动时 installCrashHandlers()、按 uiMode 打点(main.ts:137、run-shell.ts、run-v2-print.ts 的 cloud appender)。

6. 其他交付面(独立应用)​

这三个不装进 kimi 二进制,是围绕引擎的独立 App:

应用是什么怎么连引擎依据
apps/kimi-webVue3 + Vite 的浏览器 Web UI,TUI 的平级替身经 REST + WebSocket 连 /api/v1(由 kimi web 启的 kap-server)apps/kimi-web/package.json(vue/vue-i18n)、sub/web/run.ts
apps/vscode官方 VS Code 插件("Kimi Code")进程内直接消费 SDK:createKimiHarness(webview UI + bridge RPC)apps/vscode/src/runtime/kimi-runtime.ts:2
apps/kimi-inspect调试检查器,浏览 kap-server 的 /api/v1/debug RPC 面连一个带 --debug-endpoints 的 kap-server,反射式加载整套 Serviceapps/kimi-inspect/src/connection.tsx:3

其中 kimi web 是关键枢纽:它在当前进程前台启动 kap-server(v2 引擎的 REST/WS 服务器),把 token 放进 URL 的 #token= 片段后打开浏览器(sub/web/run.ts:103 buildWebUrl,片段不发给服务端、不进访问日志)。Web UI 和 Inspector 都靠它。注意:kimi web 总是启 v2 引擎的 kap-server,不看 KIMI_CODE_EXPERIMENTAL_FLAG 那个开关(experimental-v2.ts:9-12 注释)。

VS Code 插件是"SDK 作为公共门面"最直接的证据:它不碰引擎内部,直接 createKimiHarness 就把整套能力接了进来。

7. 边界与局限(诚实)​

  • -p 与交互开关互斥。 --prompt 不能和 --yolo/--auto/--plan 同用,--continue 不能和 --session 同用等(options.ts:77-91)——无头模式刻意收窄了交互语义。
  • v2 CLI 仍是实验。 kimi -p 走 v2 需显式开 KIMI_CODE_EXPERIMENTAL_FLAG,默认仍是 v1 门面路径(run-prompt.ts:102)。TUI 的默认引擎不由这个开关切。
  • ACP 里不做登录。 stdio 无 TTY,ACP authenticate 只复查 token,不触发真正 OAuth 流;要登录得靠客户端另起 kimi login 子进程(server.ts:654)。
  • ACP 扩展面是桩。 extMethod/extNotification 一律回 MethodNotFound(server.ts:839、:854),槽位留着但未接。
  • Inspector 无推送。 kimi-inspect 没有 Service 事件推送通道,面板按需拉取/轮询;连不上就整屏"Debug surface unavailable"(依据:仓库 AGENTS.md 项目地图)。
  • 单二进制受平台限。 SEA 注入/签名分平台(darwin/win32),原生模块靠运行期路径重定向,一旦 pi-tui 的原生助手路径形状变了就需要同步改 PI_TUI_NATIVE_PATTERN(native/module-hook.ts:25)。

8. 代码地图(导航索引)​

主题文件路径符号 / 锚点
进程入口 + 分流apps/kimi-code/src/main.tsmain、handleMainCommand、handleUpgradeCommand
commander 程序 + 子命令注册apps/kimi-code/src/cli/commands.tscreateProgram
选项校验 + uiMode 判定apps/kimi-code/src/cli/options.tsvalidateOptions、resolveOutputFormat
TUI 启动 + 终端恢复apps/kimi-code/src/cli/run-shell.tsrunShell、emergencyExit
无头 print + v1/v2 分叉apps/kimi-code/src/cli/run-prompt.tsrunPrompt、raceWithTimeout
v2 实验开关apps/kimi-code/src/cli/experimental-v2.tsKIMI_V2_ENV、isKimiV2Enabled
v2 原生 print runnerapps/kimi-code/src/cli/v2/run-v2-print.tsrunV2Print、applyPrintBackgroundPolicy
无头干净退出apps/kimi-code/src/cli/headless-exit.tsfinalizeHeadlessRun、scheduleHeadlessForceExit
print 会话窄接口apps/kimi-code/src/cli/prompt-session.tsPromptHarness、PromptSession
自更新预检apps/kimi-code/src/cli/update/preflight.tsrunUpdatePreflight
TUI 主类apps/kimi-code/src/tui/kimi-tui.tsKimiTUI
TUI 反向 RPCapps/kimi-code/src/tui/reverse-rpc/index.tsregisterReverseRPCHandlers、ReverseRpcModalCoordinator
TUI 斜杠命令表apps/kimi-code/src/tui/commands/registry.ts内建命令数组
SDK 公共门面导出packages/node-sdk/src/index.tscreateKimiHarness、KimiHarness、Session
SDK 进程内 RPCpackages/node-sdk/src/sdk-rpc-client.tsSDKRpcClient、createKimiHarness
SDK Session APIpackages/node-sdk/src/session.tsSession、onEvent、prompt、activateSkill
SDK 作为 providerpackages/node-sdk/src/kimi-code-model-provider.tsKimiForCodingProvider
ACP 服务器packages/acp-adapter/src/server.tsAcpServer、runAcpServer
ACP 会话 + 内容转换packages/acp-adapter/src/session.ts、convert.tsAcpSession、acpBlocksToPromptParts
ACP 审批/提问桥packages/acp-adapter/src/approval.ts、question.tsAPPROVE_ONCE_OPTION_ID 等
kimi acp 子命令apps/kimi-code/src/cli/sub/acp.tsregisterAcpCommand
kimi web 前台服务器apps/kimi-code/src/cli/sub/web/run.tsbuildWebCommand、buildWebUrl
单二进制打包apps/kimi-code/scripts/native/build.mjs5 步流水线
原生模块运行期重定向apps/kimi-code/src/native/module-hook.tsinstallNativeModuleHook、PI_TUI_NATIVE_PATTERN
SEA 资产解包/缓存apps/kimi-code/src/native/native-assets.tsNativeAssetManifest
插件市场清单plugins/marketplace.jsonplugins[](tier/source)
VS Code 插件引擎绑定apps/vscode/src/runtime/kimi-runtime.tscreateKimiHarness

想往下看引擎内部,回到 index 的阅读地图:回合循环见 01-loop,Agent 主机见 02-agent,v2 引擎与 kap-server 见 05-v2-architecture。