┌───────────────────────────────────────────────────────────────────┐
│ 消费者层││┌──────────┐┌──────────┐┌──────────┐┌───────────────────┐│
││ kimi-web││kimi-inspect│ │pi-tui ││kimi-code CLI ││││ (Web UI)││ (调试面板)││ (TUI) ││(web/daemon) ││
│└─────┬─────┘└─────┬─────┘└────┬────┘└─────────┬─────────┘││││││ │
││ HTTP WebSocket│ process.fork()││└──────────────┴──────────────┘│ │
│ ││ ││ ▼▼ │
│┌─────────────────────────────────┐┌──────────────────────────┐ │││kap-server ││kimi-code CLI │ │
││ FastifyHTTPServer WS││(Embedding Host via SDK)│ │││││startServer({hostIdentity,...})│
││ ┌──────────────────────────┐│└──────────────────────────┘ │││ │ agent-core-v2 (Core) │││
││ │ DI × Scope 容器│││││ └──────────────────────────┘││
│└─────────────────────────────────┘│└───────────────────────────────────────────────────────────────────┘
```kap-server 是 **kimi-web**（Web 前端）与 **kimi-inspect**（调试面板）背后的服务端支撑。CLI 中的 `kimi web` 命令，本质上就是启动一个 kap-server 实例，并把 Web 静态资源挂载进去。用户无论是在浏览器中打开 Web UI、提交 Prompt、查看历史会话，还是在调试面板中通过 RPC 调用引擎内部服务，请求都会先到达 kap-server。### 1.2 核心职责* **会话管理**：创建、查询列表、更新、归档、fork、compact、undo、abort 等会话操作* **Prompt 提交**：接收用户输入、图片附件和文件引用，并转发给引擎执行调度
* **事件广播**：通过 WebSocket 实时推送会话事件，包括 token 流、工具调用、审批请求等* **文件操作**：支持上传、下载以及工作空间文件系统浏览
* **审批与问题交互**：处理工具审批流程与 Agent 提问交互* **配置与模型管理**：对外提供 provider、model 目录以及用户配置读写能力
* **认证与安全控制**：实现 Bearer Token 认证、Host/Origin 校验与速率限制## 2. 技术栈全景### 2.1 核心依赖| 技术 | 角色 | 说明 || ---------------------------- | ------------ | ------------------------------------------------------------------------------------ |
| **Fastify**| HTTP 框架| 高性能 Node.js Web 框架，内置日志（Pino）、Schema 验证与插件系统 || **agent-core-v2**| 引擎核心 | DI x Scope 容器，提供 ISessionLifecycleService、IAgentPromptService 等核心引擎服务 |
| **transcript** | 会话数据层 | 提供 TranscriptStore 分级存储、WireRecord 持久化与实时增量投影|| **@fastify/swagger** | API 文档 | 基于 Zod Schema 自动生成 OpenAPI 3.0 文档，并暴露 /openapi.json|
| **WebSocket (ws)** | 实时通道 | 基于 `ws` 库构建 WebSocket 服务，采用 noServer 模式与 Fastify 共享 HTTP Server|| **ulid** | ID 生成| 用于生成连接 ID、Server ID 等全局唯一标识|
| **Zod**| 验证层 | 提供类型安全的请求/响应 Schema 校验，并驱动 Swagger 文档生成 |### 2.2 defineRoute：声明式路由定义kap-server 没有直接使用 Fastify 原生 AJV 校验，而是通过自研的 `defineRoute` 中间件构建了一套声明式路由系统：在一个对象中同时定义 Zod Schema（运行时校验）和 OpenAPI Schema（Swagger 文档）。```Typescript// packages/kap-server/src/routes/prompts.ts
const submitRoute = defineRoute({
method: 'POST',path: '/sessions/{session_id}/prompts',
body: promptSubmissionSchema,// Zod — 运行时验证params: sessionIdParamSchema,
success: { data: promptSubmitResultSchema },// 成功响应errors: {
40001: { detailsSchema: z.array(/* ... */) },// 校验失败40401: {},// 会话不存在
},description: 'Submit a prompt to a session',
tags: ['prompts'],},
async (req, reply) => {// req.body→PromptSubmission (自动推断)
// req.params → { session_id: string }// ...
},);
app.post(submitRoute.path, submitRoute.options, submitRoute.handler);```
这套机制带来的优势包括：
* **类型安全**：在 Handler 中，`req.body` 和 `req.params` 会自动推断为正确的 Zod 类型
* **错误格式统一**：200 响应通过 `oneOf` 同时描述成功信封与所有可能的错误信封* **文档即代码**：在定义 route 的同时，也完成了 OpenAPI 文档声明
* **低运行时开销**：校验仅在 preHandler 阶段执行一次### 2.3 统一信封格式所有 REST API 响应都会封装在统一的信封结构中：```Typescript// packages/kap-server/src/protocol/envelope.ts
interface Envelopecode: number;// 0 = 成功，4xxxx/5xxxx = 业务错误
msg: string; // 'success' 或错误描述data: T | null;// 业务数据
request_id: string; // 请求追踪 IDdetails?: unknown;// 结构化错误详情
stack?: string; // 堆栈信息（仅错误时）}
```其中 `code=0` 表示请求成功，非零值表示业务错误码。这一机制与 HTTP 状态码解耦——**所有 kap-server 响应统一返回 HTTP 200**，真正的处理结果通过信封中的 `code` 字段表达。因此，Fastify 默认 access log 被关闭，改由 kap-server 自身的请求日志体系接管。## 3. REST API 路由体系### 3.1 路由注册总览所有接口路由都通过 `registerApiV1Routes` 统一注册，并挂载在 `/api/v1` 前缀下。```Typescript// packages/kap-server/src/routes/registerApiV1Routes.ts
export async function registerApiV1Routes(app, core, opts) {await app.register(async (apiV1) => {
registerHealthRoute(apiV1); // /healthzregisterMetaRoute(apiV1); // /meta
registerAuthRoute(apiV1, core); // /auth/*registerOAuthRoutes(apiV1, core); // /oauth/*
registerConfigRoutes(apiV1, core);// /config/*registerModelCatalogRoutes(apiV1);// /models, /providers
registerSessionsRoutes(apiV1, core);// /sessionsregisterPromptRoutes(apiV1, core);// /sessions/:id/prompts
registerMessagesRoutes(apiV1, core);// /sessions/:id/messagesregisterApprovalsRoutes(apiV1, core); // /sessions/:id/approvals
registerQuestionsRoutes(apiV1, core); // /sessions/:id/questionsregisterWorkspacesRoutes(apiV1);// /workspaces
registerFilesRoutes(apiV1, core); // /filesregisterFsRoutes(apiV1, core);// /fs
registerToolsRoutes(apiV1, core); // /toolsregisterTasksRoutes(apiV1, core); // /sessions/:id/tasks
registerTerminalsRoutes(apiV1, core); // /terminalsregisterSkillsRoutes(apiV1, core);// /skills
registerTranscriptRoutes(apiV1);// /sessions/:id/transcriptregisterSearchRoutes(apiV1, core);// /search
// ... 调试、快照、shutdown 等}, { prefix: '/api/v1' });
}```
### 3.2 核心路由详解
#### 会话管理 — `/api/v1/sessions`
会话相关路由是 kap-server 中最复杂、也是最核心的模块之一，实现了 v1 的完整 wire contract：
| 方法 | 路径 | 功能|
| ------ | ------------------------ | --------------------------------------------------------------------------- || POST | /sessions| 创建新会话（需要 workspace_id 或 metadata.cwd）|
| GET| /sessions| 查询会话列表（支持 before_id/after_id 游标分页、workspace_id/status 过滤） || GET| /sessions/:id| 获取单个会话详情|
| POST | /sessions/:id/profile| 更新标题、metadata、agent_config || GET| /sessions/:id/children | 获取子会话列表|
| POST | /sessions/:id/children | 创建子会话（fork tag）|| POST | /sessions/:id/fork | Fork 会话（复制上下文到新会话） |
| POST | /sessions/:id/compact| 触发上下文压缩|| POST | /sessions/:id/undo | 撤销最近 N 轮对话 |
| POST | /sessions/:id/abort| 中止当前正在执行的 turn || POST | /sessions/:id/archive| 归档会话|
| POST | /sessions/:id/restore| 恢复归档会话|| POST | /sessions/:id/btw| 启动后台 Agent（side-channel）|
这类 action 路由统一通过 `/sessions/{tail}` 模式进行处理，`parseActionSuffix` 会从 tail 中解析出 `{ session_id, action }`，再分发到对应的引擎服务。
#### Prompt 提交 — `/api/v1/sessions/:id/prompts`
Prompt 提交路由负责处理用户输入到引擎执行的完整流程：
1. **会话恢复**：调用 `resumeSessionById` 获取或冷加载会话 Scope
2. **图片处理**：提取 ContentPart 中的 base64 图片，解析 `kimi-file://` URL，并压缩至模型可接受尺寸3. **权限与策略控制**：应用 `IAgentPermissionModeService` 与 `IAgentToolPolicyService`
4. **Profile 绑定**：通过 `IAgentProfileService` 解析系统提示、工具集和 Skills5. **调度执行**：调用 `IAgentPromptService.prompt()` 启动一次 turn
6. **事件广播**：引擎产生的 token 流、工具调用和执行结果，通过 WebSocket 实时推送到前端#### 工作空间管理 — `/api/v1/workspaces`工作空间管理路由负责目录注册与文件浏览功能：* `GET /workspaces` — 获取所有已注册工作空间列表（从 `IWorkspaceService` 读取）* `POST /workspaces/register` — 将新目录注册为工作空间
* `GET /workspaces/:id/files` — 浏览工作空间目录树（folder picker）## 4. WebSocket 实时通信### 4.1 WebSocket 端点与升级流程kap-server 在 `/api/v1/ws` 端点提供 WebSocket 实时通信能力。与传统独立 WebSocket 服务不同，它基于 `ws` 库的 **noServer 模式**实现——WebSocket 服务不单独监听端口，而是挂载在 Fastify 的 HTTP Server 上，通过监听 `upgrade` 事件处理 WebSocket 握手。```Typescript// packages/kap-server/src/start.ts
const wssV1 = registerWsV1(core, {validateCredential,
registry: connectionRegistry,broadcaster,
fsWatchBridge,logger,
});app.server.on('upgrade', (req, socket, head) => {void handleUpgrade(req, socket, head).catch((error) =>
logger.error({ err: error }, 'ws upgrade handler failed'),);
});```
在升级过程中，会执行与 HTTP 路由相同的安全校验逻辑，包括 Host/Origin 校验和 Bearer Token 认证。只有全部检查通过后，WebSocket 连接才会正式建立。
### 4.2 WsConnectionV1：连接级协议
每一个 WebSocket 连接都由 `WsConnectionV1` 实例负责管理。该实例实现了 `BroadcastTarget` 接口，能够接收 `SessionEventBroadcaster` 分发的事件，并转发给客户端。
连接建立后，服务端会立即发送 `server_hello` 帧：
```Typescript
// packages/kap-server/src/transport/ws/v1/wsConnectionV1.tsthis.sendImmediateFrame(
buildServerHello({ws_connection_id: this.id,
protocol_version: WS_PROTOCOL_VERSION,max_event_buffer_size: this.maxBufferSize,
capabilities: { event_batching: false, compression: false },}),
);```
### 4.3 控制帧协议
客户端通过 JSON 帧与服务器通信，支持以下控制帧类型：
| 帧类型| 方向 | 说明 |
| ------------------- | ---------------- | ------------------------------------------------------------------------ || server_hello | Server→Client | 连接建立后立即发送，用于声明协议版本与能力 |
| client_hello | Client→Server | 客户端握手，可携带 initial subscriptions 和 cursors|| subscribe | Client→Server | 订阅会话事件，指定 session_id agents 事件游标 |
| subscribe_v2 | Client→Server | v2 订阅方式：按 transcript grade 分级订阅（text、tool_call、thinking 等） || unsubscribe | Client→Server | 取消指定会话的订阅 |
| unsubscribe_v2 | Client→Server | 取消 v2 分级订阅 || ack | Server→Client | 确认客户端事件序列号 |
| resync_required| Server→Client | 服务端无法继续增量补齐事件，客户端需执行全量重同步 || watch_fs_add| Client→Server | 请求监听文件系统变更 |
| watch_fs_remove | Client→Server | 取消文件系统监听 |### 4.4 事件广播机制`SessionEventBroadcaster` 是 kap-server 事件分发体系的核心组件。它维护持久化事件日志（`SessionEventJournal`），每个会话事件写入日志后，都会被广播给所有订阅该会话的连接。事件分发主要分为两个通道：* **Global 通道**：全局事件，如 session created/deleted、workspace 变更、配置更新，会推送给**所有**已连接客户端，无需单独订阅* **Subscription 通道**：会话级事件，如 token 增量、工具调用、审批请求，仅推送给订阅了该会话的连接
### 4.5 事件缓冲与背压控制
高频事件，尤其是 token 级文本增量，如果逐帧发送会造成大量小包，影响网络性能。为此，WsConnectionV1 设计了发送缓冲机制：
* 订阅事件采用 **16ms 刷新间隔**（约 60fps），单次最多支持 64 帧批量发送
* 立即帧（公共事件、控制帧响应）作为 FIFO 屏障，会优先刷新缓冲区中的订阅帧* 当 `socket.bufferedAmount` 超过 1 MiB 时，触发背压控制，延迟发送直到缓冲区回落
```Typescript
// 默认参数const DEFAULT_FLUSH_INTERVAL_MS = 16; // 刷新间隔（约 60fps）
const DEFAULT_MAX_BATCH_SIZE = 64; // 单批最大帧数const DEFAULT_HIGH_WATER_MARK_BYTES = 1 << 20; // 1 MiB
const DEFAULT_BACKPRESSURE_RETRY_MS = 5;```
### 4.6 Transcript 增量同步
connect_v2 中的 `subscribe_v2` 帧引入了基于 **Transcript Grade** 的分级订阅能力。客户端可只订阅自己关心的 Grade，例如 `text`、`tool_call`、`thinking`，服务端则只推送对应类型事件。这在长对话和高频输出场景下，能够显著减少不必要的数据传输。
`TranscriptService` 会为每个活跃会话维护一个 `TranscriptStore`。引擎产生的每一条 WireRecord 都会实时投影到 Store 中。当 WebSocket 客户端订阅某个 Grade 时，Store 会从客户端游标位置开始执行增量推送；如果游标落后过多，则返回 `resync_required`，要求客户端进行全量重同步。
5. 会话生命周期管理
### 5.1 会话创建流程
会话创建是 kap-server 中最关键的处理流程之一。从 REST 请求进入，到引擎实例化完成，中间涉及多个步骤：
```Typescript
// packages/kap-server/src/routes/sessions.ts — POST /sessionsasync (req, reply) => {
// 1. 解析 cwd：从 workspace_id 或 metadata.cwd 中获取工作目录const workDir = workspaceId ? workspace.root : body.metadata.cwd;
// 2. 注册工作空间（createOrTouch 是幂等的）
const touched = await core.accessor.get(IWorkspaceService).createOrTouch(workDir);// 3. 获取工作空间的生命周期 handlerconst handler = await core.accessor.get(IWorkspaceLifecycleService).handlerFor({ root: workDir });
// 4. 通过 handler 的 SessionLifecycleService 创建会话
const handle = await handler.accessor.get(ISessionLifecycleService).create({ workDir });// 5. 设置标题、读取元数据await handle.accessor.get(ISessionMetadata).setTitle(body.title);
const meta = await handle.accessor.get(ISessionMetadata).read();// 6. 发布 session.created 事件（WebSocket 广播）core.accessor.get(IEventService).publish({
type: 'event.session.created',payload: { agentId: 'main', sessionId: session.id, session },
});}
```### 5.2 Session Store 持久化kap-server 的会话数据持久化完全委托给 agent-core-v2 引擎处理。在 `bootstrap()` 阶段，引擎会通过 `IFileSystemStorageService` 把存储根路径设置为 `* **会话索引**：`ISessionIndex` 维护 `FileSessionIndex`，并按 recency 排序
* **Wire Records**：每个 Agent 的消息、工具调用、任务状态等，以 JSONL 格式写入 `agents//wire.jsonl`* **二进制数据**：上传文件、图片等通过 `IBlobStorageService` 保存
会话的 `cwd` 保存在 `ISessionMetadata` 的自定义字段中（gap G3 已关闭）。即使工作空间后续被注销，会话仍可依赖自身的 cwd 信息继续被列出和访问。
### 5.3 多 Agent 支持
kap-server 的会话模型天然支持多个 Agent 并存：
* **Main Agent**：每个会话默认包含一个主 Agent，负责接收用户 Prompt 并生成回复
* **Subagents / Side-channel**：通过 `POST /sessions/:id/btw` 启动后台 Agent，在不影响主会话的情况下执行独立任务* **Children Sessions**：通过 `POST /sessions/:id/children` 创建子会话（fork parent_tag）
每个 Agent 都对应一个独立 Scope 实例，拥有自己的上下文记忆（`IAgentContextMemoryService`）、工具集和生命周期。WebSocket 的 `subscribe` 帧可通过 `agents` 字段指定订阅哪些 Agent 事件，而全局搜索会扫描所有 Agent 的 WireRecord。
### 5.4 会话的暂停、恢复与 Fork
kap-server 中的会话并不会始终常驻内存。当连接断开或会话长时间空闲时，会话 Scope 可以被释放；当客户端再次访问时，再通过 `resumeSessionById` 从磁盘恢复重建。
Fork 操作在 `ISessionLifecycleService.fork()` 中实现——它会创建一个新的会话，并复制源会话的上下文历史（以系统消息形式注入），从而让新会话继承完整上下文，但拥有独立的后续对话路径。
6. V2 引擎集成
### 6.1 引擎初始化
kap-server 在 `startServer()` 中，通过 `agent-core-v2` 的 `bootstrap()` 方法创建 Core Scope：
```Typescript
// packages/kap-server/src/start.tsconst { app: core } = bootstrap(
{homeDir,
configPath,clientIdentity: opts.hostIdentity,
},[
...logSeed(logging),// 日志配置...hostRequestHeadersSeed(kimiHeaders), // HTTP 请求头
...skillCatalogRuntimeOptionsSeed(skillDirs), // Skill 目录...hostIdentitySeed(opts.hostIdentity),// 宿主身份
...(opts.seeds ?? []), // 额外配置],
);```
bootstrap() 返回的 core 是一个 App 级 Scope，其中注册了全部引擎服务。kap-server 的每个路由 handler，都会通过 core.accessor.get(ISomeService) 的方式获取所需的引擎服务实例。
### 6.2 DI x Scope 在服务层的应用
kap-server 本身并不直接持有引擎状态，所有状态都存在于 Scope 层级结构中：
```
App Scope (core)├── ISessionIndex — 全局会话索引
├── IWorkspaceService — 工作空间注册表├── IConfigService — 配置读写
├── IEventService— 事件总线├── IProviderDiscoveryService — Provider 发现
├── IWorkspaceLifecycleService│└── handlerFor(root) → Workspace Scope
│ ├── ISessionLifecycleService — 会话的创建/fork/归档│ │└── create({ workDir }) → Session Scope
│ │ ├── ISessionMetadata — 会话元数据│ │ ├── ISessionContext — cwd、workspaceId
│ │ ├── IAgentLifecycleService — Agent 生命周期│ │ │└── createMainAgent() → Agent Scope
│ │ │ ├── IAgentPromptService— Prompt 处理│ │ │ ├── IAgentContextMemoryService — 对话历史
│ │ │ ├── IAgentToolPolicyService — 工具策略│ │ │ ├── IAgentLoopService — Agent 循环
│ │ │ └── ...│ │ └── ...
│ └── ...└── ...
```这种三级嵌套 DI 的含义是：App 级服务是全局单例，Workspace 级服务在同一工作空间下的多个会话之间共享，而 Session 与 Agent 级服务则是每个会话、每个 Agent 独立拥有。kap-server 路由 handler 从 App Scope 进入，再通过 `handlerFor`、`resumeSessionById`、`ensureMainAgent` 等函数逐层下沉到更细粒度的 Scope。### 6.3 请求 → Agent → 响应的完整路径以用户提交一个 Prompt 为例，其完整请求链路如下：```POST /api/v1/sessions/abc/prompts(HTTP)
│▼
registerPromptsRoutes → defineRoute (Zod 验证 body/params)│
▼resumeSessionById(core.accessor, sessionId)— 获取/冷加载 Session Scope
│▼
ensureMainAgent(session)— 获取 Main Agent Scope│
▼IAgentPromptService.prompt(content, options)— 调度执行
│├─→ IAgentLoopService— Agent 循环（think → act → observe）
│ ││ ├─→ LLM 调用→ token 流
│ ├─→ Tool 调用→ Bash / File / Search ...│ └─→ 事件发射→ IEventService.publish(...)
│▼
SessionEventBroadcaster— 事件持久化 广播│
├─→ SessionEventJournal— 写入事件日志└─→ WebSocket 推送— 分发给所有订阅客户端
│▼
kimi-web / kimi-inspect— 实时渲染```
### 6.4 引擎事件的 WebSocket 转发
引擎中的 `IEventService` 是事件源头。kap-server 的 `SessionEventBroadcaster` 会订阅引擎事件总线中 `session.*` 前缀的事件：
* **agent.***：如 `agent.turn_started`、`agent.turn_ended`、`agent.text_delta`、`agent.tool_call` 等 —— 推送给订阅该会话的 WebSocket 连接
* **session.***：如 `session.created`、`session.meta.updated`、`session.archived` —— 执行全局广播* **workspace.***：如 `workspace.created`、`workspace.deleted` —— 执行全局广播
`TranscriptService` 会在这些事件基础上构建 TranscriptStore，把原始事件转换为结构化 Transcript 操作（upsert、reset），供 REST transcript 接口与 WebSocket 的 `subscribe_v2` 使用。
7. 多引擎支持
### 7.1 V1 与 V2 的架构差异
kap-server 是 agent-core-v2 的 HTTP 服务层，但 kimi-code 历史上还存在一个基于 `agent-core`（V1）的服务端实现（`packages/server`）。两者在架构设计上的差异非常明显：
| 对比维度 | V1 Server (agent-core) | V2 Server (kap-server) |
| ------------ | ---------------------------------- | -------------------------------------------------- || DI 容器| IInstantiationService（扁平 DI） | DI × Scope（三级嵌套 DI） |
| 事件模型 | EventEmitter wsGatewayService| IEventService SessionEventBroadcaster|| 会话存储 | SessionService（单文件） | ISessionMetadata FileSessionIndex WireRecord |
| Agent 模型 | 单一 Agent | 多 Agent（main subagent children） || Transcript | 无标准 Transcript| TranscriptStore Grade 分级订阅 |
| 路由定义 | Express 风格 | defineRoute（Zod → Swagger）|### 7.2 引擎切换机制在 kimi-code CLI 中，引擎切换通过以下配置项控制：* **KIMI_CODE_USE_V2**：环境变量，设置为 `"1"` 时启用 V2 引擎* **config.json**：配置文件中的 `engine_version` 字段
* **CLI flag**：命令行参数 `--use-v2`当 V2 引擎启用后，CLI 的 `kimi web` 命令会调用 `startServer` 启动 kap-server；否则仍然启动 V1 Server。两者对外保持相同的 `/api/v1` 接口兼容性，因此 kimi-web 前端无需感知底层后端版本，始终通过同一套 API 与引擎通信。### 7.3 开发模式下的双引擎调试在开发环境中，可以同时运行 V1 与 V2 两套引擎服务：* V1 Server 默认使用 58627 端口* V2（kap-server）默认也使用 58627 端口，并支持 **port 1 重试机制**：若端口被占用，则自动尝试 58628、58629……最多重试 100 次
* 两个服务通过 `instanceRegistry` 分别注册到 `2. 服务绑定在 loopback 地址（127.0.0.1）
3. 请求中携带有效的 Bearer Token```Typescript// packages/kap-server/src/start.ts
const debugEndpoints = exposureClass === 'loopback' && opts.debugEndpoints === true;// ...
if (debugEndpoints === true) {registerDebugRoutes(apiV1, core);
}```
这些限制确保调试接口不会在不安全环境中暴露——因为它允许调用方访问引擎内部几乎所有 Service，属于高权限管理入口。
### 8.2 DI 容器反射
Debug 路由实际注册的是 `registerServiceDispatcherRoutes`，它本质上是一个基于 DI 反射能力实现的 Service 调度器：
```Typescript
// packages/kap-server/src/transport/registerDebugRoutes.tsexport function registerDebugRoutes(app, core) {
registerServiceDispatcherRoutes(app, core, '/debug', {lookup: resolveAnyScopedServiceId,// 跨所有 Scope 查找 Service
describe: describeAllChannels, // 列出所有可用的 RPC 通道});
}```
resolveAnyScopedServiceId 不仅可以在 App Scope 中查找 Service，还支持深入 Session 与 Agent Scope：通过 session_id 和 agent_id 参数先定位对应嵌套 Scope，再从中获取目标 Service 实例。
`describeAllChannels` 会暴露所有可调用服务通道的完整清单，包括每个通道的输入/输出 Schema 与描述信息。这实际上相当于一个运行时 DI 容器反射 API。
### 8.3 Service 面板
kimi-inspect 调试面板正是通过这套 Debug RPC 接口与 kap-server 交互。它主要提供两类核心操作：
* **数据查询（GET）**：读取 Service 当前状态，例如 `IAgentContextMemoryService` 的对话历史、`ISessionMetadata` 的元数据、`IConfigService` 的当前配置
* **触发操作（POST）**：调用 Service 方法，例如触发 compaction、重置上下文、切换 permission mode典型的调试请求路径格式为 `/api/v1/debug/2. **选中 Service 时**：自动调用该 Service 的只读方法，填充数据面板
3. **用户点击按钮时**：发送 POST 请求调用相应 RPC 方法4. **实时更新**：通过 WebSocket 订阅会话事件，实现面板数据实时刷新
这种设计让 kimi-inspect 成为一个完全动态的调试工具——无需硬编码任何 Service 名称或方法，所有能力都通过运行时 DI 反射自动发现。
","createTime":1786588964,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"fa vNum":0,"html":"","isOriginal":0,"likeNum":0,
