Continue core 协议消息扩展指南新增 Message Type 的检查清单与跨端路由解析【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continuecore/rules.md是 Continue 开源仓库open-source coding agent面向贡献者与二次开发者的核心开发规范它界定了在core/protocol/目录下新增协议消息Message Type时必须遵守的检查项直指本项目三大进程Core、Webview/GUI、IDE之间消息路由的最关键约定。读完本文你将掌握 Continue 消息协议目录的组织结构、webview↔core 双向消息为何必须“双端登记”于透传列表、四种实现落地位置分别适用何种消息方向以及新增一条消息类型时的完整自查流程可直接用于插件开发、协议扩展与代码评审。一、规则文档速览四步检查守住消息路由边界在 core/rules.md 中项目为所有向protocol/目录提交新协议消息的开发工作规定了固定检查清单可归纳为以下四条类型type定义正确—— 新消息必须拥有精确、符合现有约定的类型声明webview↔core 方向必须双向登记—— 若该消息在 Webview 与 Core 之间传递必须同时加入 core/protocol/passThrough.ts 与extensions/intellij/.../constants/MessageTypes.kt的对应常量列表实现位置遵循路由矩阵—— 按消息方向落入core/core.ts、GUI 的useWebviewListener、VsCodeMessenger.ts或 JetBrains 的IdeProtocolClient.kt之一不重复造轮子—— 不得与既有消息类型功能重叠。规则本身精炼但每一条背后都是整个 Continue 多端消息架构的具体映射。下面结合仓库源码逐条展开。二、背景core/protocol/的目录结构与类型组合规则要求新消息进入 core/protocol 目录该目录是消息类型的“唯一事实来源”。目录下分布着按“发送方 → 接收方”划分的类型文件core.tsCore 与 IDE/Webview 之间的消息类型ToCoreFromIdeOrWebviewProtocol等coreWebview.ts专门承载 Webview 到 Core、以及 Core 到 Webview 的协议类型例如ToCoreFromWebviewProtocol、ToWebviewFromCoreProtocolwebview.ts、ide.ts、ideCore.ts、ideWebview.ts分别定义 Webview 与 IDE、Core 与 IDE 等方向的消息集合index.ts将所有片段组合为对外统一的巨型协议类型。核心聚合逻辑可见于该文件export type ToIdeProtocol ToIdeFromWebviewProtocol ToIdeFromCoreProtocol; export type FromIdeProtocol ToWebviewFromIdeProtocol ToCoreFromIdeProtocol ToWebviewOrCoreFromIdeProtocol; export type ToWebviewProtocol ToWebviewFromIdeProtocol ToWebviewFromCoreProtocol ToWebviewOrCoreFromIdeProtocol; export type FromWebviewProtocol ToIdeFromWebviewProtocol ToCoreFromWebviewProtocol; export type ToCoreProtocol ToCoreFromIdeProtocol ToCoreFromWebviewProtocol ToWebviewOrCoreFromIdeProtocol; export type FromCoreProtocol ToWebviewFromCoreProtocol ToIdeFromCoreProtocol;从该文件可以推断协议中每个消息类型都表示为一个元组[请求参数类型, 返回结果类型]见IProtocol Recordstring, [any, any]这正是整个消息系统的“类型即契约”基础。这就是“规则 1类型定义正确”的落点—— 新消息必须在这组按方向拆分的类型文件中找到正确归属并被组合进对应协议同时其载荷签名入参/出参必须符合[payload, response]的元组形态否则 TypeScript 编译器会在所有消费方Messenger、GUI、各 IDE 客户端直接报错。三、规则 2webview↔core 消息必须在两处“透传白名单”同时登记Continue 的 WebviewGUI与 Core 运行在跨进程/跨线程环境中两者之间的消息并非每一条都被本地直接消费——相当一部分需要“原样透传”pass-through给另一端甚至第三方。因此项目维护了两份必须手工同步的透传名单。3.1 第一处core/protocol/passThrough.ts该文件导出两个数组WEBVIEW_TO_CORE_PASS_THROUGHWebview 发起、需直达 Core 的消息类型keyofToCoreFromWebviewProtocol例如ping、abort、history/*、config/addModel、config/deleteRule、mcp/reloadServer、autocomplete/complete、nextEdit/*、tools/call、models/fetch等CORE_TO_WEBVIEW_PASS_THROUGHCore 发起、需送达 Webview 的消息类型keyofToWebviewFromCoreProtocol例如configUpdate、indexProgress、indexing/statusUpdate、addContextItem、sessionUpdate等。文件注释明确要求Note: If updating these values, make a corresponding update inextensions/intellij/.../ContinueBrowser.kt也就是说改动该名单时JetBrains 侧的ContinueBrowser.kt负责承载 Webview 的浏览器桥同样需要同步。3.2 第二处JetBrains 常量 MessageTypes.ktcore/rules.md中第二条要求将消息加入 JetBrains 插件的常量类。实际源码中该 Kotlin 文件在companion object内维护了IDE_MESSAGE_TYPES所有指向 IDE 能力的消息名列表readRangeInFile、getDiff、runCommand、applyToFile、showToast等PASS_THROUGH_TO_WEBVIEW与CORE_TO_WEBVIEW_PASS_THROUGH对应的 JetBrains 版本列表并在注释中反向声明Note: If updating these values, make a corresponding update incore/protocol/passThrough.ts这份 Kotlin 常量存在的根因在于JetBrains 插件通过独立的 Kotlin 代码桥接 Continue 的 GUI无法直接复用 TypeScript 侧导出的字符串数组。因此任何新增的 webview↔core 透传消息都必须在TS 与 Kotlin 两处登记否则在某一端 IDE 上消息会被静默丢弃或无法透传。实操要点当你新增的消息在 Webview 与 Core 之间流动时请同时修改 passThrough.ts 与 MessageTypes.kt。至于 VS Code 端可观察 VsCodeMessenger.ts 已直接从core/protocol/passThrough导入两组常量WEBVIEW_TO_CORE_PASS_THROUGH、CORE_TO_WEBVIEW_PASS_THROUGH因此 VS Code 会自动保持一致无需二次登记。四、规则 3四种实现位置与消息方向路由矩阵core/rules.md要求每条消息都必须有唯一明确的处理器归属具体取决于消息的目标端。综合规则文本与源码可整理为如下矩阵消息目标端实现位置文件消息来源示例Corecore/core.ts 的registerMessageHandlers()内以on(messageType, handler)注册Webview / IDE 发来的业务消息GUIWebviewGUI 组件中的useWebviewListenergui/src/hooks/useWebviewListener.tsCore / IDE 推送至界面层的事件VS Code IDEVsCodeMessenger.tsonWebview/onCore/onWebviewOrCore需调用 VS Code API 的能力请求JetBrains IDEIdeProtocolClient.kt见 extensions/intellij/.../continue/IdeProtocolClient.kt需调用 JetBrains API 的能力请求4.1 目标为 Core注册进core/core.tscore/core.ts 的Core类在构造函数末尾调用registerMessageHandlers(ideSettingsPromise)核心注册入口随后通过const on this.messenger.on.bind(this.messenger)批量注册各消息处理器。仓库中可见大量遵循该模式的真实用例例如on(ping)返回pong用于探活校验on(abort)依据msg.data ?? msg.messageId触发对应AbortController取消请求on(history/list)通过historyManager.list()查询会话记录并按limit截断on(config/addModel)会先检查模型是否已存在于config.modelsByRole中已存在则showToast提示并打开配置文件否则调用addModel(model, role)再reloadConfig。从这些实现可以看出“类型即契约”的落地效果每个on(...)的回调参数与返回值都受ToCoreProtocol元组强约束处理器只关心本消息的业务逻辑。4.2 目标为 GUI使用useWebviewListenerGUI 侧的注册方式为 React HookuseWebviewListenerT extends keyof ToWebviewProtocol(messageType, handler, dependencies?, skip?)见 useWebviewListener.ts。其内部在useEffect中监听window的message事件命中event.data.messageType messageType后执行handler(event.data.data)并通过ideMessenger.respond(messageType, result, event.data.messageId)把处理结果回发给请求方。组件卸载时自动移除监听。因此凡是 Core 或 IDE 需要“推送”给界面渲染的数据更新类消息都应以这种方式在对应 GUI 组件/页面中注册处理器。4.3 目标为 VS Code / JetBrains IDEVS CodeVsCodeMessenger.ts 提供了一个介于 Core 与 Webview 之间的共享 Messenger 类暴露onWebview(...)、onCore(...)、onWebviewOrCore(...)三个注册方法使同一处理器可同时服务于来自 Webview 与 Core 的请求。其onWebview委托给webviewProtocol.on(...)onCore委托给InProcessMessenger.externalOn(...)这样 IDE 能力如showFile、runCommand的消息统一在扩展侧处理。JetBrains对应实现位于IdeProtocolClient.kt负责响应发往 JetBrains IDE 的消息并调用 IDE API。判断口诀新增消息时先问“这条消息最终要让谁干活”——Core 的逻辑处理放core/core.ts界面渲染/交互放 GUI 的useWebviewListener必须触碰编辑器原生 API 的能力请求则放 VS Code 的VsCodeMessenger.ts或 JetBrains 的IdeProtocolClient.kt。五、规则 4先查重再动手规则最后一条强调“不重复已有功能”。结合上一节列举的真实消息类型可以发现项目已通过路径式命名空间对消息进行了归类例如history/*会话、config/*配置、mcp/*、autocomplete/*、nextEdit/*、indexing/*、context/*、llm/*、tools/*、stats/*等。新增消息前建议在 passThrough.ts 的透传名单中检索是否存在语义相同的消息在 core/core.ts 的on(...)处理器区段按命名空间前缀定位相近实现检查FromWebviewProtocol/ToWebviewProtocol/ToCoreProtocol等聚合类型中是否已有可复用能力。例如凡历史记录操作均已存在history/list、history/load、history/save、history/delete、history/clear、history/share等细粒度类型新增会话操作时应优先复用而非另起炉灶。六、端到端示例config/addModel的完整生命周期以现有消息config/addModel为模板可直观看到符合上述全部规则的消息是如何工作的类型层消息进入ToCoreFromWebviewProtocol的 key 集合见 coreWebview.ts 组合出的协议类型载荷携带{ model, role }透传登记config/addModel出现在WEBVIEW_TO_CORE_PASS_THROUGHpassThrough.ts中表示它属于从 Webview 原样透传给 Core 的类型同时需在 JetBrains MessageTypes.kt 相关列表登记实现落地在 core/core.ts 中以on(config/addModel, ...)实现完整业务查重模型 → 提示/写入 →reloadConfig查重该消息专门承载“添加模型”这一原子操作与config/deleteModel、config/updateSharedConfig等职责边界清晰。同样的流程可以反向复制到任何你希望新增的消息类型上。七、总结新消息提交前的一页式自查清单基于 core/rules.md 及上述源码佐证可将最终检查收敛为如下清单消息是否已在core/protocol/对应方向类型文件coreWebview.ts/ideCore.ts/ideWebview.ts/webview.ts中正确定义载荷满足[入参, 出参]元组签名若为 webview↔core 消息是否同时加入 passThrough.ts 的WEBVIEW_TO_CORE_PASS_THROUGH/CORE_TO_WEBVIEW_PASS_THROUGH以及 JetBrains MessageTypes.kt 对应常量涉及 JetBrains 浏览器桥时还须检查ContinueBrowser.kt处理器是否已落到唯一正确位置Core 逻辑 → core/core.tsregisterMessageHandlers内on(...)GUI → 组件内useWebviewListenerVS Code 能力 → VsCodeMessenger.tsJetBrains 能力 →IdeProtocolClient.kt是否已按命名空间前缀检索确认不与history/*、config/*、mcp/*、autocomplete/*等既有类型功能重复关联的测试与契约如 binary/test/binary.test.ts 中针对协议消息二进制编解码的用例是否同步更新。遵守这份检查清单既能保证新消息在 VS Code、JetBrains、GUI 三端表现一致也能让整个协议层长期保持“类型明确、路径唯一、功能不重叠”的可维护状态。【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Continue core 协议消息扩展指南：新增 Message Type 的检查清单与跨端路由解析
Continue core 协议消息扩展指南新增 Message Type 的检查清单与跨端路由解析【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continuecore/rules.md是 Continue 开源仓库open-source coding agent面向贡献者与二次开发者的核心开发规范它界定了在core/protocol/目录下新增协议消息Message Type时必须遵守的检查项直指本项目三大进程Core、Webview/GUI、IDE之间消息路由的最关键约定。读完本文你将掌握 Continue 消息协议目录的组织结构、webview↔core 双向消息为何必须“双端登记”于透传列表、四种实现落地位置分别适用何种消息方向以及新增一条消息类型时的完整自查流程可直接用于插件开发、协议扩展与代码评审。一、规则文档速览四步检查守住消息路由边界在 core/rules.md 中项目为所有向protocol/目录提交新协议消息的开发工作规定了固定检查清单可归纳为以下四条类型type定义正确—— 新消息必须拥有精确、符合现有约定的类型声明webview↔core 方向必须双向登记—— 若该消息在 Webview 与 Core 之间传递必须同时加入 core/protocol/passThrough.ts 与extensions/intellij/.../constants/MessageTypes.kt的对应常量列表实现位置遵循路由矩阵—— 按消息方向落入core/core.ts、GUI 的useWebviewListener、VsCodeMessenger.ts或 JetBrains 的IdeProtocolClient.kt之一不重复造轮子—— 不得与既有消息类型功能重叠。规则本身精炼但每一条背后都是整个 Continue 多端消息架构的具体映射。下面结合仓库源码逐条展开。二、背景core/protocol/的目录结构与类型组合规则要求新消息进入 core/protocol 目录该目录是消息类型的“唯一事实来源”。目录下分布着按“发送方 → 接收方”划分的类型文件core.tsCore 与 IDE/Webview 之间的消息类型ToCoreFromIdeOrWebviewProtocol等coreWebview.ts专门承载 Webview 到 Core、以及 Core 到 Webview 的协议类型例如ToCoreFromWebviewProtocol、ToWebviewFromCoreProtocolwebview.ts、ide.ts、ideCore.ts、ideWebview.ts分别定义 Webview 与 IDE、Core 与 IDE 等方向的消息集合index.ts将所有片段组合为对外统一的巨型协议类型。核心聚合逻辑可见于该文件export type ToIdeProtocol ToIdeFromWebviewProtocol ToIdeFromCoreProtocol; export type FromIdeProtocol ToWebviewFromIdeProtocol ToCoreFromIdeProtocol ToWebviewOrCoreFromIdeProtocol; export type ToWebviewProtocol ToWebviewFromIdeProtocol ToWebviewFromCoreProtocol ToWebviewOrCoreFromIdeProtocol; export type FromWebviewProtocol ToIdeFromWebviewProtocol ToCoreFromWebviewProtocol; export type ToCoreProtocol ToCoreFromIdeProtocol ToCoreFromWebviewProtocol ToWebviewOrCoreFromIdeProtocol; export type FromCoreProtocol ToWebviewFromCoreProtocol ToIdeFromCoreProtocol;从该文件可以推断协议中每个消息类型都表示为一个元组[请求参数类型, 返回结果类型]见IProtocol Recordstring, [any, any]这正是整个消息系统的“类型即契约”基础。这就是“规则 1类型定义正确”的落点—— 新消息必须在这组按方向拆分的类型文件中找到正确归属并被组合进对应协议同时其载荷签名入参/出参必须符合[payload, response]的元组形态否则 TypeScript 编译器会在所有消费方Messenger、GUI、各 IDE 客户端直接报错。三、规则 2webview↔core 消息必须在两处“透传白名单”同时登记Continue 的 WebviewGUI与 Core 运行在跨进程/跨线程环境中两者之间的消息并非每一条都被本地直接消费——相当一部分需要“原样透传”pass-through给另一端甚至第三方。因此项目维护了两份必须手工同步的透传名单。3.1 第一处core/protocol/passThrough.ts该文件导出两个数组WEBVIEW_TO_CORE_PASS_THROUGHWebview 发起、需直达 Core 的消息类型keyofToCoreFromWebviewProtocol例如ping、abort、history/*、config/addModel、config/deleteRule、mcp/reloadServer、autocomplete/complete、nextEdit/*、tools/call、models/fetch等CORE_TO_WEBVIEW_PASS_THROUGHCore 发起、需送达 Webview 的消息类型keyofToWebviewFromCoreProtocol例如configUpdate、indexProgress、indexing/statusUpdate、addContextItem、sessionUpdate等。文件注释明确要求Note: If updating these values, make a corresponding update inextensions/intellij/.../ContinueBrowser.kt也就是说改动该名单时JetBrains 侧的ContinueBrowser.kt负责承载 Webview 的浏览器桥同样需要同步。3.2 第二处JetBrains 常量 MessageTypes.ktcore/rules.md中第二条要求将消息加入 JetBrains 插件的常量类。实际源码中该 Kotlin 文件在companion object内维护了IDE_MESSAGE_TYPES所有指向 IDE 能力的消息名列表readRangeInFile、getDiff、runCommand、applyToFile、showToast等PASS_THROUGH_TO_WEBVIEW与CORE_TO_WEBVIEW_PASS_THROUGH对应的 JetBrains 版本列表并在注释中反向声明Note: If updating these values, make a corresponding update incore/protocol/passThrough.ts这份 Kotlin 常量存在的根因在于JetBrains 插件通过独立的 Kotlin 代码桥接 Continue 的 GUI无法直接复用 TypeScript 侧导出的字符串数组。因此任何新增的 webview↔core 透传消息都必须在TS 与 Kotlin 两处登记否则在某一端 IDE 上消息会被静默丢弃或无法透传。实操要点当你新增的消息在 Webview 与 Core 之间流动时请同时修改 passThrough.ts 与 MessageTypes.kt。至于 VS Code 端可观察 VsCodeMessenger.ts 已直接从core/protocol/passThrough导入两组常量WEBVIEW_TO_CORE_PASS_THROUGH、CORE_TO_WEBVIEW_PASS_THROUGH因此 VS Code 会自动保持一致无需二次登记。四、规则 3四种实现位置与消息方向路由矩阵core/rules.md要求每条消息都必须有唯一明确的处理器归属具体取决于消息的目标端。综合规则文本与源码可整理为如下矩阵消息目标端实现位置文件消息来源示例Corecore/core.ts 的registerMessageHandlers()内以on(messageType, handler)注册Webview / IDE 发来的业务消息GUIWebviewGUI 组件中的useWebviewListenergui/src/hooks/useWebviewListener.tsCore / IDE 推送至界面层的事件VS Code IDEVsCodeMessenger.tsonWebview/onCore/onWebviewOrCore需调用 VS Code API 的能力请求JetBrains IDEIdeProtocolClient.kt见 extensions/intellij/.../continue/IdeProtocolClient.kt需调用 JetBrains API 的能力请求4.1 目标为 Core注册进core/core.tscore/core.ts 的Core类在构造函数末尾调用registerMessageHandlers(ideSettingsPromise)核心注册入口随后通过const on this.messenger.on.bind(this.messenger)批量注册各消息处理器。仓库中可见大量遵循该模式的真实用例例如on(ping)返回pong用于探活校验on(abort)依据msg.data ?? msg.messageId触发对应AbortController取消请求on(history/list)通过historyManager.list()查询会话记录并按limit截断on(config/addModel)会先检查模型是否已存在于config.modelsByRole中已存在则showToast提示并打开配置文件否则调用addModel(model, role)再reloadConfig。从这些实现可以看出“类型即契约”的落地效果每个on(...)的回调参数与返回值都受ToCoreProtocol元组强约束处理器只关心本消息的业务逻辑。4.2 目标为 GUI使用useWebviewListenerGUI 侧的注册方式为 React HookuseWebviewListenerT extends keyof ToWebviewProtocol(messageType, handler, dependencies?, skip?)见 useWebviewListener.ts。其内部在useEffect中监听window的message事件命中event.data.messageType messageType后执行handler(event.data.data)并通过ideMessenger.respond(messageType, result, event.data.messageId)把处理结果回发给请求方。组件卸载时自动移除监听。因此凡是 Core 或 IDE 需要“推送”给界面渲染的数据更新类消息都应以这种方式在对应 GUI 组件/页面中注册处理器。4.3 目标为 VS Code / JetBrains IDEVS CodeVsCodeMessenger.ts 提供了一个介于 Core 与 Webview 之间的共享 Messenger 类暴露onWebview(...)、onCore(...)、onWebviewOrCore(...)三个注册方法使同一处理器可同时服务于来自 Webview 与 Core 的请求。其onWebview委托给webviewProtocol.on(...)onCore委托给InProcessMessenger.externalOn(...)这样 IDE 能力如showFile、runCommand的消息统一在扩展侧处理。JetBrains对应实现位于IdeProtocolClient.kt负责响应发往 JetBrains IDE 的消息并调用 IDE API。判断口诀新增消息时先问“这条消息最终要让谁干活”——Core 的逻辑处理放core/core.ts界面渲染/交互放 GUI 的useWebviewListener必须触碰编辑器原生 API 的能力请求则放 VS Code 的VsCodeMessenger.ts或 JetBrains 的IdeProtocolClient.kt。五、规则 4先查重再动手规则最后一条强调“不重复已有功能”。结合上一节列举的真实消息类型可以发现项目已通过路径式命名空间对消息进行了归类例如history/*会话、config/*配置、mcp/*、autocomplete/*、nextEdit/*、indexing/*、context/*、llm/*、tools/*、stats/*等。新增消息前建议在 passThrough.ts 的透传名单中检索是否存在语义相同的消息在 core/core.ts 的on(...)处理器区段按命名空间前缀定位相近实现检查FromWebviewProtocol/ToWebviewProtocol/ToCoreProtocol等聚合类型中是否已有可复用能力。例如凡历史记录操作均已存在history/list、history/load、history/save、history/delete、history/clear、history/share等细粒度类型新增会话操作时应优先复用而非另起炉灶。六、端到端示例config/addModel的完整生命周期以现有消息config/addModel为模板可直观看到符合上述全部规则的消息是如何工作的类型层消息进入ToCoreFromWebviewProtocol的 key 集合见 coreWebview.ts 组合出的协议类型载荷携带{ model, role }透传登记config/addModel出现在WEBVIEW_TO_CORE_PASS_THROUGHpassThrough.ts中表示它属于从 Webview 原样透传给 Core 的类型同时需在 JetBrains MessageTypes.kt 相关列表登记实现落地在 core/core.ts 中以on(config/addModel, ...)实现完整业务查重模型 → 提示/写入 →reloadConfig查重该消息专门承载“添加模型”这一原子操作与config/deleteModel、config/updateSharedConfig等职责边界清晰。同样的流程可以反向复制到任何你希望新增的消息类型上。七、总结新消息提交前的一页式自查清单基于 core/rules.md 及上述源码佐证可将最终检查收敛为如下清单消息是否已在core/protocol/对应方向类型文件coreWebview.ts/ideCore.ts/ideWebview.ts/webview.ts中正确定义载荷满足[入参, 出参]元组签名若为 webview↔core 消息是否同时加入 passThrough.ts 的WEBVIEW_TO_CORE_PASS_THROUGH/CORE_TO_WEBVIEW_PASS_THROUGH以及 JetBrains MessageTypes.kt 对应常量涉及 JetBrains 浏览器桥时还须检查ContinueBrowser.kt处理器是否已落到唯一正确位置Core 逻辑 → core/core.tsregisterMessageHandlers内on(...)GUI → 组件内useWebviewListenerVS Code 能力 → VsCodeMessenger.tsJetBrains 能力 →IdeProtocolClient.kt是否已按命名空间前缀检索确认不与history/*、config/*、mcp/*、autocomplete/*等既有类型功能重复关联的测试与契约如 binary/test/binary.test.ts 中针对协议消息二进制编解码的用例是否同步更新。遵守这份检查清单既能保证新消息在 VS Code、JetBrains、GUI 三端表现一致也能让整个协议层长期保持“类型明确、路径唯一、功能不重叠”的可维护状态。【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考