Kimi Code CLI 的kimi acp子命令基于 ACP 协议的多会话 Agent 服务器接入指南【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-clikimi acp是 Kimi Code CLI 内置的 ACPAgent Client Protocol服务器启动命令它让 JetBrains、Zed 等 IDE 与自定义客户端能够以标准协议方式接入 Kimi 的 Agent 能力。本文将围绕该命令的启动方式、认证机制、会话生命周期、能力协商与工具集成展开并结合仓库源码说明其底层实现原理帮助读者完成从IDE 配置到自定义 ACP 客户端开发的完整接入。一、ACP 与kimi acp概览1.1 什么是 ACPACPAgent Client Protocol是一种标准化协议允许 IDE 和其他客户端与 AI Agent 进行交互。它基于 JSON-RPC 2.0包含请求/响应方法以及单向通知。从 ACP 集成说明 可以看到典型的调用流程initialize - 可选 authenticate - session/new 或 session/load - session/prompt期间客户端会收到session/update通知并可根据需要发起session/cancel。Kimi Code CLI 通过这一协议把自身的 Agent 会话能力暴露给外部客户端而客户端IDE则负责提供终端、文件系统读写等宿主能力。1.2 启动命令在终端中直接运行kimi acp该命令会启动一个支持多会话的 ACP 服务器并通过标准输入输出stdio与客户端通信。在 CLI 入口 中acp子命令被定义为cli.command() def acp(): Run Kimi Code CLI ACP server. from kimi_cli.acp import acp_main acp_main()而 acp_main 入口 的核心逻辑是def acp_main() - None: Entry point for the multi-session ACP server. import asyncio import acp from kimi_cli.acp.server import ACPServer from kimi_cli.app import enable_logging from kimi_cli.utils.logging import logger enable_logging() logger.info(Starting ACP server on stdio) asyncio.run(acp.run_agent(ACPServer(), use_unstable_protocolTrue))也就是说kimi acp使用 ACP SDK 的run_agent在 stdio 上运行ACPServer实例。服务器启动后会持续从 stdin 读取客户端的 JSON-RPC 请求并通过 stdout 返回响应与推送通知。注意kimi acp是多会话服务器。CLI 还保留了一个被标记为 Deprecated 的--acp参数单会话模式官方提示应改用kimi acp见 CLI 参数定义。二、使用场景从 kimi-acp 参考文档 出发kimi acp主要面向三类场景2.1 IDE 插件集成JetBrains、Zed在 Zed、JetBrains 系列 IDE 的 AI 插件中把 Kimi Code CLI 注册为一个 ACP Agent Server即可在编辑器内直接使用 Kimi 的 Agent 能力包括多轮对话、文件读写、命令执行与审批流程。具体配置方式见本文「在 IDE 中使用」一节也可直接参考 在 IDE 中使用。2.2 自定义 ACP 客户端开发开发者可以基于 ACP 协议自行实现客户端连接kimi acp暴露的 stdio 通道完成initialize握手后创建会话、发送 prompt、接收流式更新。ACP 协议本身与语言无关任何能进行 JSON-RPC 通信的语言都可以实现客户端。2.3 多会话并发处理多会话服务器意味着一个kimi acp进程可以同时维护多个独立会话每个会话拥有独立的session_id、工作目录与上下文适合需要并行处理多个任务或由 IDE 同时打开多个工作区的场景。三、认证机制3.1 认证时机与AUTH_REQUIREDACP 服务器在创建会话session/new或加载会话session/load之前会检查用户的认证状态。如果未登录服务器会返回AUTH_REQUIRED错误错误码-32000并携带可用的认证方式信息。在 server.py 中认证检查由_check_token_usable与_check_auth实现staticmethod def _check_token_usable() - str | None: Return None if the persisted OAuth token is usable, else a reason string. ref OAuthRef(storagefile, keyKIMI_CODE_OAUTH_KEY) token load_tokens(ref) if token is None or not token.access_token: return no valid token found if token.expires_at and token.expires_at time.time() and not token.refresh_token: # Token expired and no refresh token — background refresh cannot help. return token expired and no refresh token available return None def _check_auth(self) - None: Check if Kimi Code authentication is complete. Raise AUTH_REQUIRED if not. reason self._check_token_usable() if reason: auth_methods_data: list[dict[str, Any]] [] for m in self._auth_methods: if m.field_meta and terminal-auth in m.field_meta: terminal_auth m.field_meta[terminal-auth] auth_methods_data.append({...}) logger.warning(Authentication required, {reason}, reasonreason) raise acp.RequestError.auth_required({authMethods: auth_methods_data})从源码可以看出认证状态取决于持久化的 OAuth tokentoken 不存在、缺少 access_token、或已过期且没有 refresh_token 时都会被判定为需要认证。token 由 auth/oauth.py 管理对应文件存储键KIMI_CODE_OAUTH_KEY。3.2 认证方式信息与kimi login在握手阶段initialize服务器会构建并缓存认证方式AuthMethod核心是terminal-auth终端认证self._auth_methods [ acp.schema.AuthMethod( idlogin, nameLogin with Kimi account, description( Run kimi login command in the terminal, then follow the instructions to finish login. ), field_meta{ terminal-auth: { command: command, # 当前进程的可执行文件路径 args: terminal_args, # [login] label: Kimi Code Login, env: {}, type: terminal, } }, ), ]对应的单元测试 tests/acp/test_server_initialize.py 验证了无论通过kimi、kimi-code、kimi-cli还是任意包装脚本启动terminal-auth中的command都会正确反映入口可执行文件args均为[login]。因此客户端收到AUTH_REQUIRED错误后应引导用户在终端中执行kimi login命令完成登录。登录成功后后续的 ACP 请求创建/加载会话、prompt 等即可正常执行。3.3 运行期的认证失效处理认证检查不仅发生在会话创建/加载时prompt执行过程中若遇到 401 也会触发重新认证。在 ACPSession.prompt 中LLM 未设置LLMNotSet→ 抛出auth_requiredOAuth 会话遇到 API 401APIStatusError→ 抛出auth_required提示用户重新登录其他 LLM/Provider 错误 → 抛出internal_error这保证了即使长时间运行导致 token 过期客户端也能收到明确的认证错误并引导用户重新登录。四、能力协商与会话生命周期4.1 初始化与版本协商initialize是 ACP 握手的第一个方法负责协议版本协商与能力宣告。版本协商实现在 version.py服务器支持协议版本 1对应 ACP specv0.10.8、SDK0.8.0会选择不超过客户端请求版本的最高受支持版本若客户端版本低于最低要求服务器仍返回自身当前版本由客户端决定是否断开。握手响应中宣告的 Agent 能力包括能力项值说明load_sessiontrue支持加载历史会话prompt_capabilitiesembedded_contexttrue, imagetrue, audiofalse支持内嵌上下文与图片输入mcp_capabilitieshttptrue, ssefalse支持 HTTP 传输的 MCP 服务器session_capabilitieslistresume支持会话列表与恢复auth_methods1 个login终端认证见上文认证章节握手时还会通过 telemetry 记录客户端信息名称与版本见 server.py。4.2 会话创建session/newnew_session(cwd, mcp_servers)的流程如下server.py执行_check_auth()认证检查通过Session.create(KaosPath.unsafe_from_local_path(Path(cwd)))在工作目录创建持久化会话将客户端传入的 MCP 服务器配置经acp_mcp_servers_to_mcp_config转换为内部 MCP 配置见 mcp.py以ui_modeacp创建KimiCLI实例并构建ACPSession若客户端声明了terminal能力则通过replace_tools用 ACP 终端工具替换原 Shell 工具见「工具集成」一节向客户端推送AvailableCommandsUpdate通知携带可用的斜杠命令列表返回会话响应包含会话模式状态当前仅default模式与模型状态可用模型列表、当前模型。模型列表由_expand_llm_models生成对于模型名包含thinking/reason的始终思考模型只提供一个 ID对于支持思考的普通模型则额外追加model_key,thinking变体见 server.py。_ModelIDConv负责在内部(model_key, thinking)与 ACP 模型 ID 字符串带,thinking后缀之间转换。4.3 会话加载与恢复session/load 与 session/resumeload_session(cwd, session_id)按工作目录与会话 ID 通过Session.find查找历史会话重建KimiCLI与ACPSession并调用acp_session.replay_history(wire_file)向客户端重放持久化的 wire 历史用户消息、文本、思考、工具调用等让客户端恢复完整的会话展示。resume_session(cwd, session_id)若会话尚未加载则先执行_setup_session随后返回模式与模型状态。会话查找失败时返回invalid_params错误{session_id: Session not found}。4.4 会话列表session/listlist_sessions(cwd)通过Session.list(work_dir)列出指定工作目录下的会话返回每个会话的session_id、标题与更新时间ISO 8601 格式。当前实现不做分页next_cursor恒为None若未提供cwd则返回空列表。4.5 提示与取消session/prompt 与 session/cancelprompt将 ACP 内容块list[ACPContentBlock]转发给ACPSession.prompt后者把KimiCLI.run()产出的内部事件流转换为 ACP 的流式更新见「流式输出」一节最终返回PromptResponse其中stop_reason可能为end_turn正常结束max_turn_requests达到最大步骤数MaxStepsReachedcancelled用户取消RunCancelled。cancel通过设置当前 turn 的cancel_eventasyncio.Event来中断正在执行的 prompt见 session.py。4.6 模型切换session/set_modelset_session_model支持在会话内切换模型将 ACP 模型 ID 解析为(model_key, thinking)在配置中查找模型与 Provider通过create_llm重建 LLM 实例并替换运行时 LLM同时把default_model/default_thinking持久化到默认配置文件见 server.py。模式切换set_session_mode目前仅接受default。说明fork_session会话分叉与自定义扩展方法ext_method/ext_notification当前抛出NotImplementedError属于尚未实现的能力见 AGENTS.md 的 Current gaps 一节。五、流式输出与内容映射ACP 以session/update通知实现流式输出Kimi Code CLI 将内部 wire 事件映射为 ACP schema核心映射关系如下见 session.py内部事件ACP 更新说明TextPartAgentMessageChunk文本增量ThinkPartAgentThoughtChunk思考过程ToolCallToolCallStart工具调用开始标题形如tool_name: 关键参数ToolCallPartToolCallProgress流式参数追加标题实时更新ToolResultToolCallProgress状态置为completed或failedTodoDisplayBlockAgentPlanUpdate计划/TODO 条目状态pending/in_progress/completedNotificationAgentMessageChunk以[Notification] 标题文本形式发送工具调用的 ID 会以 turn ID 为前缀如{turn_id}/{tool_call_id}避免跨轮次出现 ID 冲突见_ToolCallState.acp_tool_call_id。工具参数通过streamingjson.Lexer流式解析用于生成带关键参数子标题的实时标题。输入方向的转换在 convert.py 中完成TextContentBlock→ 文本部分ImageContentBlock→ 转换为data:{mime_type};base64,{data}的 data URL 图片部分EmbeddedResourceContentBlock文本资源→ 包裹为resource uri...文本ResourceContentBlock链接引用→ 转换为resource_link uri... name... /引用文本不支持的块类型记录日志并忽略。工具结果的DiffDisplayBlock会转换为FileEditToolCallContenttype: diffIDE 可据此渲染文件差异视图HideOutputDisplayBlock则用于抑制输出展示终端工具专用。六、工具集成与权限审批6.1 文件系统ACPKaosACP 会话使用 ACPKaos 作为 KAOS 后端当客户端声明了fs.readTextFile/fs.writeTextFile能力时文件的读写通过 ACP 的fs/*方法路由到客户端即 IDE 的文件系统否则回退到本地local_kaos。追加写模式modea在客户端同时支持读写时会先读取现有内容再整体写回。终端执行能力同样按需路由客户端声明terminal时由ACPProcess通过terminal/create、轮询terminal_output、wait_for_terminal_exit与release_terminal完成命令执行与输出增量推送含截断通知与轮询间隔 0.2s 的默认参数。6.2 终端工具替换若客户端声明了terminal能力replace_toolstools.py会用 ACP 版Terminal工具替换工具集中的原始 Shell 工具。该工具复用原 Shell 工具的name、description与params执行时请求审批approval.request通过create_terminal创建终端并推送携带TerminalToolCallContent含terminal_id的ToolCallProgress等待退出支持超时 kill、信号与退出码判定释放终端句柄。由于终端输出直接以TerminalToolCallContent流式推送给用户工具结果中会附带HideOutputDisplayBlock以避免重复展示。6.3 审批桥接Agent 内部的工具审批请求会被桥接到 ACP 的session/request_permissionsession.py向客户端提供三个选项option_id名称kindapproveApprove onceallow_onceapprove_for_sessionApprove for this sessionallow_alwaysrejectRejectreject_once审批请求会附带工具调用更新含 diff 内容或描述文本用户拒绝/取消或发生异常时请求以reject收尾。这样 IDE 用户可以直接在编辑器内完成文件修改、命令执行等敏感操作的授权。6.4 MCP 服务器透传客户端在创建/加载会话时可以传入 MCP 服务器列表服务器通过 acp_mcp_servers_to_mcp_config 将其转换为内部 MCP 配置支持三种形态HTTPtransport: http、SSEtransport: sse与 stdiocommandargsenv。配置无效时会抛出MCPConfigError。七、在 IDE 中使用7.1 前置准备在配置 IDE 之前请确保已安装 Kimi Code CLI 并完成kimi login登录这也是 ACP 服务器认证检查的前提。详细步骤见 在 IDE 中使用。7.2 在 Zed 中使用Zed 是支持 ACP 的现代 IDE。在 Zed 配置文件~/.config/zed/settings.json中添加{ agent_servers: { Kimi Code CLI: { type: custom, command: kimi, args: [acp], env: {} } } }配置说明type固定值customcommandKimi Code CLI 的命令路径如果kimi不在 PATH 中需要使用完整路径args启动参数acp启用 ACP 模式env环境变量通常留空即可保存配置后在 Zed 的 Agent 面板中就可以创建 Kimi Code CLI 会话了。7.3 在 JetBrains IDE 中使用JetBrains 系列 IDEIntelliJ IDEA、PyCharm、WebStorm 等通过 AI 聊天插件支持 ACP。如果你没有 JetBrains AI 订阅可以在注册表中启用llm.enable.mock.response来使用 AI 聊天功能连按两次 Shift 搜索注册表即可打开。在 AI 聊天面板的菜单中点击 Configure ACP agents添加以下配置{ agent_servers: { Kimi Code CLI: { command: ~/.local/bin/kimi, args: [acp], env: {} } } }command需要使用完整路径可以在终端中运行which kimi获取。保存后在 AI 聊天的 Agent 选择器中就可以选择 Kimi Code CLI 了。7.4 IDE 中的实际体验接入后IDE 内可以获得完整的 Agent 交互体验多会话管理会话列表、加载历史会话、恢复会话流式输出文本、思考过程实时展示工具调用以卡片形式呈现并实时更新参数与状态审批交互文件写入、命令执行等操作弹出 Approve once / Approve for this session / Reject 选项差异展示文件编辑以 diff 形式渲染便于审阅图片输入支持在提示中附带图片imagetrue。八、限制与注意事项基于源码与集成说明AGENTS.md以下几点需要开发者注意尚未实现的能力fork_session会话分叉、ext_method/ext_notification自定义扩展方法当前抛出NotImplementedError模式切换set_session_mode仅接受defaultkimi acp目前只提供单一模式认证方式当前只提供终端认证kimi loginauthenticate方法为完整性而实现Zed 等客户端并不会直接调用它见 AGENTS.md 的 Zed 相关说明工作目录要求ACP 文件路径均为绝对路径行号从 1 开始会话按工作目录cwd组织创建/加载/列表都需要提供正确的cwd配置位置约束kimi acp必须使用默认配置位置源码断言config.is_from_default_location模型切换会持久化写入默认配置协议版本当前支持协议版本 1specv0.10.8自定义客户端应实现版本协商逻辑正确处理低于最低版本的情况。九、小结kimi acp把 Kimi Code CLI 的完整 Agent 能力封装为标准 ACP 服务器通过initialize协商能力、以kimi login完成终端认证、以session/new/session/load/session/prompt/session/cancel管理多会话生命周期并将文本、思考、工具调用、计划与审批全部映射为 ACP 的流式更新。无论是配置 Zed/JetBrains 的现成方案还是基于 JSON-RPC 自研客户端都可以从 server.py 与 session.py 的实现中获得完整的协议行为参考。【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kimi Code CLI 的 `kimi acp` 子命令：基于 ACP 协议的多会话 Agent 服务器接入指南
Kimi Code CLI 的kimi acp子命令基于 ACP 协议的多会话 Agent 服务器接入指南【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-clikimi acp是 Kimi Code CLI 内置的 ACPAgent Client Protocol服务器启动命令它让 JetBrains、Zed 等 IDE 与自定义客户端能够以标准协议方式接入 Kimi 的 Agent 能力。本文将围绕该命令的启动方式、认证机制、会话生命周期、能力协商与工具集成展开并结合仓库源码说明其底层实现原理帮助读者完成从IDE 配置到自定义 ACP 客户端开发的完整接入。一、ACP 与kimi acp概览1.1 什么是 ACPACPAgent Client Protocol是一种标准化协议允许 IDE 和其他客户端与 AI Agent 进行交互。它基于 JSON-RPC 2.0包含请求/响应方法以及单向通知。从 ACP 集成说明 可以看到典型的调用流程initialize - 可选 authenticate - session/new 或 session/load - session/prompt期间客户端会收到session/update通知并可根据需要发起session/cancel。Kimi Code CLI 通过这一协议把自身的 Agent 会话能力暴露给外部客户端而客户端IDE则负责提供终端、文件系统读写等宿主能力。1.2 启动命令在终端中直接运行kimi acp该命令会启动一个支持多会话的 ACP 服务器并通过标准输入输出stdio与客户端通信。在 CLI 入口 中acp子命令被定义为cli.command() def acp(): Run Kimi Code CLI ACP server. from kimi_cli.acp import acp_main acp_main()而 acp_main 入口 的核心逻辑是def acp_main() - None: Entry point for the multi-session ACP server. import asyncio import acp from kimi_cli.acp.server import ACPServer from kimi_cli.app import enable_logging from kimi_cli.utils.logging import logger enable_logging() logger.info(Starting ACP server on stdio) asyncio.run(acp.run_agent(ACPServer(), use_unstable_protocolTrue))也就是说kimi acp使用 ACP SDK 的run_agent在 stdio 上运行ACPServer实例。服务器启动后会持续从 stdin 读取客户端的 JSON-RPC 请求并通过 stdout 返回响应与推送通知。注意kimi acp是多会话服务器。CLI 还保留了一个被标记为 Deprecated 的--acp参数单会话模式官方提示应改用kimi acp见 CLI 参数定义。二、使用场景从 kimi-acp 参考文档 出发kimi acp主要面向三类场景2.1 IDE 插件集成JetBrains、Zed在 Zed、JetBrains 系列 IDE 的 AI 插件中把 Kimi Code CLI 注册为一个 ACP Agent Server即可在编辑器内直接使用 Kimi 的 Agent 能力包括多轮对话、文件读写、命令执行与审批流程。具体配置方式见本文「在 IDE 中使用」一节也可直接参考 在 IDE 中使用。2.2 自定义 ACP 客户端开发开发者可以基于 ACP 协议自行实现客户端连接kimi acp暴露的 stdio 通道完成initialize握手后创建会话、发送 prompt、接收流式更新。ACP 协议本身与语言无关任何能进行 JSON-RPC 通信的语言都可以实现客户端。2.3 多会话并发处理多会话服务器意味着一个kimi acp进程可以同时维护多个独立会话每个会话拥有独立的session_id、工作目录与上下文适合需要并行处理多个任务或由 IDE 同时打开多个工作区的场景。三、认证机制3.1 认证时机与AUTH_REQUIREDACP 服务器在创建会话session/new或加载会话session/load之前会检查用户的认证状态。如果未登录服务器会返回AUTH_REQUIRED错误错误码-32000并携带可用的认证方式信息。在 server.py 中认证检查由_check_token_usable与_check_auth实现staticmethod def _check_token_usable() - str | None: Return None if the persisted OAuth token is usable, else a reason string. ref OAuthRef(storagefile, keyKIMI_CODE_OAUTH_KEY) token load_tokens(ref) if token is None or not token.access_token: return no valid token found if token.expires_at and token.expires_at time.time() and not token.refresh_token: # Token expired and no refresh token — background refresh cannot help. return token expired and no refresh token available return None def _check_auth(self) - None: Check if Kimi Code authentication is complete. Raise AUTH_REQUIRED if not. reason self._check_token_usable() if reason: auth_methods_data: list[dict[str, Any]] [] for m in self._auth_methods: if m.field_meta and terminal-auth in m.field_meta: terminal_auth m.field_meta[terminal-auth] auth_methods_data.append({...}) logger.warning(Authentication required, {reason}, reasonreason) raise acp.RequestError.auth_required({authMethods: auth_methods_data})从源码可以看出认证状态取决于持久化的 OAuth tokentoken 不存在、缺少 access_token、或已过期且没有 refresh_token 时都会被判定为需要认证。token 由 auth/oauth.py 管理对应文件存储键KIMI_CODE_OAUTH_KEY。3.2 认证方式信息与kimi login在握手阶段initialize服务器会构建并缓存认证方式AuthMethod核心是terminal-auth终端认证self._auth_methods [ acp.schema.AuthMethod( idlogin, nameLogin with Kimi account, description( Run kimi login command in the terminal, then follow the instructions to finish login. ), field_meta{ terminal-auth: { command: command, # 当前进程的可执行文件路径 args: terminal_args, # [login] label: Kimi Code Login, env: {}, type: terminal, } }, ), ]对应的单元测试 tests/acp/test_server_initialize.py 验证了无论通过kimi、kimi-code、kimi-cli还是任意包装脚本启动terminal-auth中的command都会正确反映入口可执行文件args均为[login]。因此客户端收到AUTH_REQUIRED错误后应引导用户在终端中执行kimi login命令完成登录。登录成功后后续的 ACP 请求创建/加载会话、prompt 等即可正常执行。3.3 运行期的认证失效处理认证检查不仅发生在会话创建/加载时prompt执行过程中若遇到 401 也会触发重新认证。在 ACPSession.prompt 中LLM 未设置LLMNotSet→ 抛出auth_requiredOAuth 会话遇到 API 401APIStatusError→ 抛出auth_required提示用户重新登录其他 LLM/Provider 错误 → 抛出internal_error这保证了即使长时间运行导致 token 过期客户端也能收到明确的认证错误并引导用户重新登录。四、能力协商与会话生命周期4.1 初始化与版本协商initialize是 ACP 握手的第一个方法负责协议版本协商与能力宣告。版本协商实现在 version.py服务器支持协议版本 1对应 ACP specv0.10.8、SDK0.8.0会选择不超过客户端请求版本的最高受支持版本若客户端版本低于最低要求服务器仍返回自身当前版本由客户端决定是否断开。握手响应中宣告的 Agent 能力包括能力项值说明load_sessiontrue支持加载历史会话prompt_capabilitiesembedded_contexttrue, imagetrue, audiofalse支持内嵌上下文与图片输入mcp_capabilitieshttptrue, ssefalse支持 HTTP 传输的 MCP 服务器session_capabilitieslistresume支持会话列表与恢复auth_methods1 个login终端认证见上文认证章节握手时还会通过 telemetry 记录客户端信息名称与版本见 server.py。4.2 会话创建session/newnew_session(cwd, mcp_servers)的流程如下server.py执行_check_auth()认证检查通过Session.create(KaosPath.unsafe_from_local_path(Path(cwd)))在工作目录创建持久化会话将客户端传入的 MCP 服务器配置经acp_mcp_servers_to_mcp_config转换为内部 MCP 配置见 mcp.py以ui_modeacp创建KimiCLI实例并构建ACPSession若客户端声明了terminal能力则通过replace_tools用 ACP 终端工具替换原 Shell 工具见「工具集成」一节向客户端推送AvailableCommandsUpdate通知携带可用的斜杠命令列表返回会话响应包含会话模式状态当前仅default模式与模型状态可用模型列表、当前模型。模型列表由_expand_llm_models生成对于模型名包含thinking/reason的始终思考模型只提供一个 ID对于支持思考的普通模型则额外追加model_key,thinking变体见 server.py。_ModelIDConv负责在内部(model_key, thinking)与 ACP 模型 ID 字符串带,thinking后缀之间转换。4.3 会话加载与恢复session/load 与 session/resumeload_session(cwd, session_id)按工作目录与会话 ID 通过Session.find查找历史会话重建KimiCLI与ACPSession并调用acp_session.replay_history(wire_file)向客户端重放持久化的 wire 历史用户消息、文本、思考、工具调用等让客户端恢复完整的会话展示。resume_session(cwd, session_id)若会话尚未加载则先执行_setup_session随后返回模式与模型状态。会话查找失败时返回invalid_params错误{session_id: Session not found}。4.4 会话列表session/listlist_sessions(cwd)通过Session.list(work_dir)列出指定工作目录下的会话返回每个会话的session_id、标题与更新时间ISO 8601 格式。当前实现不做分页next_cursor恒为None若未提供cwd则返回空列表。4.5 提示与取消session/prompt 与 session/cancelprompt将 ACP 内容块list[ACPContentBlock]转发给ACPSession.prompt后者把KimiCLI.run()产出的内部事件流转换为 ACP 的流式更新见「流式输出」一节最终返回PromptResponse其中stop_reason可能为end_turn正常结束max_turn_requests达到最大步骤数MaxStepsReachedcancelled用户取消RunCancelled。cancel通过设置当前 turn 的cancel_eventasyncio.Event来中断正在执行的 prompt见 session.py。4.6 模型切换session/set_modelset_session_model支持在会话内切换模型将 ACP 模型 ID 解析为(model_key, thinking)在配置中查找模型与 Provider通过create_llm重建 LLM 实例并替换运行时 LLM同时把default_model/default_thinking持久化到默认配置文件见 server.py。模式切换set_session_mode目前仅接受default。说明fork_session会话分叉与自定义扩展方法ext_method/ext_notification当前抛出NotImplementedError属于尚未实现的能力见 AGENTS.md 的 Current gaps 一节。五、流式输出与内容映射ACP 以session/update通知实现流式输出Kimi Code CLI 将内部 wire 事件映射为 ACP schema核心映射关系如下见 session.py内部事件ACP 更新说明TextPartAgentMessageChunk文本增量ThinkPartAgentThoughtChunk思考过程ToolCallToolCallStart工具调用开始标题形如tool_name: 关键参数ToolCallPartToolCallProgress流式参数追加标题实时更新ToolResultToolCallProgress状态置为completed或failedTodoDisplayBlockAgentPlanUpdate计划/TODO 条目状态pending/in_progress/completedNotificationAgentMessageChunk以[Notification] 标题文本形式发送工具调用的 ID 会以 turn ID 为前缀如{turn_id}/{tool_call_id}避免跨轮次出现 ID 冲突见_ToolCallState.acp_tool_call_id。工具参数通过streamingjson.Lexer流式解析用于生成带关键参数子标题的实时标题。输入方向的转换在 convert.py 中完成TextContentBlock→ 文本部分ImageContentBlock→ 转换为data:{mime_type};base64,{data}的 data URL 图片部分EmbeddedResourceContentBlock文本资源→ 包裹为resource uri...文本ResourceContentBlock链接引用→ 转换为resource_link uri... name... /引用文本不支持的块类型记录日志并忽略。工具结果的DiffDisplayBlock会转换为FileEditToolCallContenttype: diffIDE 可据此渲染文件差异视图HideOutputDisplayBlock则用于抑制输出展示终端工具专用。六、工具集成与权限审批6.1 文件系统ACPKaosACP 会话使用 ACPKaos 作为 KAOS 后端当客户端声明了fs.readTextFile/fs.writeTextFile能力时文件的读写通过 ACP 的fs/*方法路由到客户端即 IDE 的文件系统否则回退到本地local_kaos。追加写模式modea在客户端同时支持读写时会先读取现有内容再整体写回。终端执行能力同样按需路由客户端声明terminal时由ACPProcess通过terminal/create、轮询terminal_output、wait_for_terminal_exit与release_terminal完成命令执行与输出增量推送含截断通知与轮询间隔 0.2s 的默认参数。6.2 终端工具替换若客户端声明了terminal能力replace_toolstools.py会用 ACP 版Terminal工具替换工具集中的原始 Shell 工具。该工具复用原 Shell 工具的name、description与params执行时请求审批approval.request通过create_terminal创建终端并推送携带TerminalToolCallContent含terminal_id的ToolCallProgress等待退出支持超时 kill、信号与退出码判定释放终端句柄。由于终端输出直接以TerminalToolCallContent流式推送给用户工具结果中会附带HideOutputDisplayBlock以避免重复展示。6.3 审批桥接Agent 内部的工具审批请求会被桥接到 ACP 的session/request_permissionsession.py向客户端提供三个选项option_id名称kindapproveApprove onceallow_onceapprove_for_sessionApprove for this sessionallow_alwaysrejectRejectreject_once审批请求会附带工具调用更新含 diff 内容或描述文本用户拒绝/取消或发生异常时请求以reject收尾。这样 IDE 用户可以直接在编辑器内完成文件修改、命令执行等敏感操作的授权。6.4 MCP 服务器透传客户端在创建/加载会话时可以传入 MCP 服务器列表服务器通过 acp_mcp_servers_to_mcp_config 将其转换为内部 MCP 配置支持三种形态HTTPtransport: http、SSEtransport: sse与 stdiocommandargsenv。配置无效时会抛出MCPConfigError。七、在 IDE 中使用7.1 前置准备在配置 IDE 之前请确保已安装 Kimi Code CLI 并完成kimi login登录这也是 ACP 服务器认证检查的前提。详细步骤见 在 IDE 中使用。7.2 在 Zed 中使用Zed 是支持 ACP 的现代 IDE。在 Zed 配置文件~/.config/zed/settings.json中添加{ agent_servers: { Kimi Code CLI: { type: custom, command: kimi, args: [acp], env: {} } } }配置说明type固定值customcommandKimi Code CLI 的命令路径如果kimi不在 PATH 中需要使用完整路径args启动参数acp启用 ACP 模式env环境变量通常留空即可保存配置后在 Zed 的 Agent 面板中就可以创建 Kimi Code CLI 会话了。7.3 在 JetBrains IDE 中使用JetBrains 系列 IDEIntelliJ IDEA、PyCharm、WebStorm 等通过 AI 聊天插件支持 ACP。如果你没有 JetBrains AI 订阅可以在注册表中启用llm.enable.mock.response来使用 AI 聊天功能连按两次 Shift 搜索注册表即可打开。在 AI 聊天面板的菜单中点击 Configure ACP agents添加以下配置{ agent_servers: { Kimi Code CLI: { command: ~/.local/bin/kimi, args: [acp], env: {} } } }command需要使用完整路径可以在终端中运行which kimi获取。保存后在 AI 聊天的 Agent 选择器中就可以选择 Kimi Code CLI 了。7.4 IDE 中的实际体验接入后IDE 内可以获得完整的 Agent 交互体验多会话管理会话列表、加载历史会话、恢复会话流式输出文本、思考过程实时展示工具调用以卡片形式呈现并实时更新参数与状态审批交互文件写入、命令执行等操作弹出 Approve once / Approve for this session / Reject 选项差异展示文件编辑以 diff 形式渲染便于审阅图片输入支持在提示中附带图片imagetrue。八、限制与注意事项基于源码与集成说明AGENTS.md以下几点需要开发者注意尚未实现的能力fork_session会话分叉、ext_method/ext_notification自定义扩展方法当前抛出NotImplementedError模式切换set_session_mode仅接受defaultkimi acp目前只提供单一模式认证方式当前只提供终端认证kimi loginauthenticate方法为完整性而实现Zed 等客户端并不会直接调用它见 AGENTS.md 的 Zed 相关说明工作目录要求ACP 文件路径均为绝对路径行号从 1 开始会话按工作目录cwd组织创建/加载/列表都需要提供正确的cwd配置位置约束kimi acp必须使用默认配置位置源码断言config.is_from_default_location模型切换会持久化写入默认配置协议版本当前支持协议版本 1specv0.10.8自定义客户端应实现版本协商逻辑正确处理低于最低版本的情况。九、小结kimi acp把 Kimi Code CLI 的完整 Agent 能力封装为标准 ACP 服务器通过initialize协商能力、以kimi login完成终端认证、以session/new/session/load/session/prompt/session/cancel管理多会话生命周期并将文本、思考、工具调用、计划与审批全部映射为 ACP 的流式更新。无论是配置 Zed/JetBrains 的现成方案还是基于 JSON-RPC 自研客户端都可以从 server.py 与 session.py 的实现中获得完整的协议行为参考。【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考