Continue 破坏性变更检测用.continue/agents评审代理系统性排查改名与失效引用【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue本文围绕 Continue 仓库中自带的评审代理定义 breaking-change-detector.md 展开完整解读它对 CLI 命令、公共 API、配置 schema 与硬编码 URL 四类破坏性变更Breaking Change的判定标准与处置规则并结合 cn review 命令 的源码实现说明该代理如何被自动发现、加载与执行。读完后你将能够在自己的 Continue 代码库中定义、运行同类审查代理并理解“哪些该修、哪些该标注、哪些不该报”的工程边界。一、它是什么一个 Markdown 定义的代码评审代理breaking-change-detector.md 是 Continue 项目自用的一个评审代理review agent文件由 YAML frontmatter 加 Markdown 正文构成--- name: Breaking Change Detector description: Flag renamed commands, APIs, or config options with stale references ---正文开头一句话即代理的任务目标“Analyze this pull request for breaking changes that may leave stale references elsewhere in the codebase”分析本次 PR 中可能让代码库其他位置遗留失效引用的破坏性变更。它不是脚本而是一份写给 LLM 的结构化审查规程定义“什么算破坏性变更”“发现问题该怎么办”“哪些情况不该报”。Continue 仓库在.continue/agents/目录下还并列维护了同类型的代理如 test-coverage.md、dependency-security-review.md、error-message-quality.md、input-validation.md共同构成一套 PR 自检体系。该代理的运行载体是 Continue CLI 的review子命令。从源码看review命令支持--review-agents agents...参数来指定要运行的具体审查代理注册位置见 index.ts 中的 review 子命令program .command(review) .description(Run AI-powered reviews on your changes) .option(--base ref, Base git ref to diff against (default: auto-detect)) .option(--format format, Output format) .option(--fix, Automatically apply suggested fixes) .option(--patch, Show patches) .option(--fail-fast, Stop on first failure) .option(--review-agents agents..., Specific review agents to run)当代理来源是本地 Markdown 文件时isLocalPath会把以.md结尾的路径识别为本地代理因此可以显式指向该文件运行cn review --review-agents .continue/agents/breaking-change-detector.md二、四类破坏性变更的判定标准与排查清单这是该代理的核心资产它把“破坏性变更”拆成四个可操作的类别每个类别都附带一份“必须核对的引用点”清单。以下完整继承原文档内容并结合仓库结构说明每个检查点的实际落点。1. CLI 命令的重命名或移除原文档规定如果注册在extensions/cli/src/commands/下的命令被重命名、移除或改动了 flag必须核对五类位置——docs/中的文档已反映新命令名.continue/agents/中的代理定义没有引用旧命令skills/中的技能已同步更新README 与 CONTRIBUTING.md 保持最新GitHub Actions 工作流没有再调用旧命令这份清单的针对性来自本仓库的真实命令结构。从源码看CLI 入口 extensions/cli/src/index.ts 使用commander构建名为cn的程序程序初始化子命令注册在 extensions/cli/src/commands/ 目录下当前包含子命令源文件说明根命令chat.ts默认进入交互式会话-p/--print为无头输出lsls.ts列出最近会话serveserve.ts启动带/state、/message端点的 HTTP 服务隐藏命令checkschecks.ts查看 PR 的 CI check 状态reviewreview.ts对变更运行 AI 评审除子命令外会话内的斜杠命令集中定义在 commands.ts 的SYSTEM_SLASH_COMMANDS表help、resume、fork、export等。这正是代理清单中“flag 变化”要覆盖的范围一旦--print、--review-agents这类 flag 或ls、review这类命令名变更文档、skills/ 目录下的技能如 skills/cn-check/、代理定义与 CI 工作流都可能留下指向旧名称的失效引用。2. 公共 API 变更原文档规定core/或packages/下导出的函数、接口或类型被重命名或签名变化时必须核对——gui/、extensions/、binary/中的所有调用方已同步更新packages/config-types/中的类型定义保持一致这一点与仓库的分层结构吻合core/ 承载核心能力如 core/protocol/ 定义的通信协议、core/config/ 的配置加载packages/config-types/ 提供对外暴露的配置类型定义而 gui/、extensions/、binary/ 是消费这些 API 的三大端。由于这几个模块分属不同包重命名一个导出符号很容易只改定义、漏改某一端的调用方——这正是该代理要求逐一核对的原因。3. 配置 schema 变更原文档规定配置文件格式YAML 或 JSON被修改时必须核对三点——校验逻辑能同时处理新旧两种格式或提供了迁移路径文档示例使用新格式默认配置已更新仓库中对应着真实的校验与迁移实现packages/config-yaml/ 承担 YAML 配置的解析与校验core/config/validation.ts 负责配置合法性检查而 core/config/migrateSharedConfig.ts 的存在说明项目确实有“schema 演进需要迁移逻辑”的实践。文档侧则由 docs/ 下的配置参考如 docs/reference/yaml-migration.mdx承担示例更新。代理清单要求“校验逻辑兼容或提供迁移”正是防止只改新格式解析、却让存量用户配置直接失效的典型事故。4. URL 变更原文档规定任何硬编码 URL例如hub.continue.dev、api.continue.dev发生变更时需要全仓库扫描失效引用。从仓库实际内容看这类 URL 并非孤例至少出现在 extensions/cli/src/env.ts、extensions/cli/src/version.ts、extensions/cli/src/util/apiClient.test.ts 等文件以及 packages/continue-sdk/ 的 SDK 代码中还散见于 BUILD_DEPENDENCIES.md、extensions/cli/docs/ 等文档。跨端引用面决定了改一个域名必须全局检索而非只改单一实现文件。三、处置规则修、标注、还是放过代理的第二部分定义了发现问题的处置边界直接决定其作为自动化审查者的行为收敛程度。What to Do该做什么发现失效引用时直接修复fix them directly——即代理被授权产出补丁而非仅提意见若某个破坏性变更没有迁移路径且可能影响用户添加评论标注该担忧但不阻断 PRdo not block只关注本次 PR 引入的变更Focus only on changes introduced in this PR不报告历史遗留问题pre-existing issues。What NOT to Flag不该报什么同一 PR 内已把所有引用一并更新的内部重构仅测试代码test-only code的变更不影响用户、只涉及开发工具链的变更。这套规则的设计意图很明确自动评审的第一死敌是误报。通过“同 PR 内已同步更新则豁免”“只看增量不看存量”“测试与开发工具链免检”三条负面清单把代理的输出收敛到“本次 PR 引入的、跨模块遗留的失效引用”这一高信噪比区间上——既能配合cn review --fix自动落补丁又不会因陈年问题刷屏导致审查被忽略。四、执行机制代理如何被发现、加载与运行理解代理被cn review消费的方式可以完整闭合本文。核心逻辑在 resolveReviews.ts按三级优先级决定运行哪些审查CLI--review-agents标志最高优先级接受 Hub slug 或本地路径Hub API源码注释说明该来源已移除当前 resolveFromHub 恒返回空数组本地回退扫描当前目录下.continue/agents/*.md与.continue/checks/*.md且同名文件 agents 目录优先于 checks 目录见 resolveFromLocal 实现。代理显示名由文件名派生去掉扩展名后把连字符、下划线替换为空格agentDisplayName所以breaking-change-detector.md在报告中显示为 breaking change detector。确定代理后review.ts 的runReviewInWorker会为每次评审 fork 一个带--internal-review-worker标志的子进程在独立 git worktree 中运行并设置 5 分钟超时worker 从本地 Markdown 文件加载代理指令见 reviewWorker.ts。当仓库中没有任何本地代理时review命令会提示创建入口“Create .continue/agents/my-review.md with agent instructions”见 review.ts 中的提示信息——breaking-change-detector.md 正是这条建议的成品示例。五、可迁移的方法论该文件示范了一套可复用的“破坏性变更审查规程”写法要点可直接搬到其他仓库按变更类别枚举检查点而不是泛泛说“检查引用”CLI 命令 → 文档/代理/技能/README/CIAPI → 各消费端 类型包schema → 校验兼容 文档示例 默认值URL → 全局扫描。每类检查点都落到具体目录。正面规则与负面清单成对出现既定义“发现即修复、只报增量”也明确三类豁免控制误报率。用 frontmatter 的name/description声明代理身份使其能被resolveReviews的本地扫描机制自动发现并生成可读的显示名。结合 extensions/cli/src/commands/ 的命令结构、packages/config-yaml/ 的配置校验层与 .continue/agents/ 的代理目录这份 Markdown 把“破坏性变更审查”从一个口头约定变成了cn review可执行、可复现的工程流程。【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Continue 破坏性变更检测：用 `.continue/agents` 评审代理系统性排查改名与失效引用
Continue 破坏性变更检测用.continue/agents评审代理系统性排查改名与失效引用【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue本文围绕 Continue 仓库中自带的评审代理定义 breaking-change-detector.md 展开完整解读它对 CLI 命令、公共 API、配置 schema 与硬编码 URL 四类破坏性变更Breaking Change的判定标准与处置规则并结合 cn review 命令 的源码实现说明该代理如何被自动发现、加载与执行。读完后你将能够在自己的 Continue 代码库中定义、运行同类审查代理并理解“哪些该修、哪些该标注、哪些不该报”的工程边界。一、它是什么一个 Markdown 定义的代码评审代理breaking-change-detector.md 是 Continue 项目自用的一个评审代理review agent文件由 YAML frontmatter 加 Markdown 正文构成--- name: Breaking Change Detector description: Flag renamed commands, APIs, or config options with stale references ---正文开头一句话即代理的任务目标“Analyze this pull request for breaking changes that may leave stale references elsewhere in the codebase”分析本次 PR 中可能让代码库其他位置遗留失效引用的破坏性变更。它不是脚本而是一份写给 LLM 的结构化审查规程定义“什么算破坏性变更”“发现问题该怎么办”“哪些情况不该报”。Continue 仓库在.continue/agents/目录下还并列维护了同类型的代理如 test-coverage.md、dependency-security-review.md、error-message-quality.md、input-validation.md共同构成一套 PR 自检体系。该代理的运行载体是 Continue CLI 的review子命令。从源码看review命令支持--review-agents agents...参数来指定要运行的具体审查代理注册位置见 index.ts 中的 review 子命令program .command(review) .description(Run AI-powered reviews on your changes) .option(--base ref, Base git ref to diff against (default: auto-detect)) .option(--format format, Output format) .option(--fix, Automatically apply suggested fixes) .option(--patch, Show patches) .option(--fail-fast, Stop on first failure) .option(--review-agents agents..., Specific review agents to run)当代理来源是本地 Markdown 文件时isLocalPath会把以.md结尾的路径识别为本地代理因此可以显式指向该文件运行cn review --review-agents .continue/agents/breaking-change-detector.md二、四类破坏性变更的判定标准与排查清单这是该代理的核心资产它把“破坏性变更”拆成四个可操作的类别每个类别都附带一份“必须核对的引用点”清单。以下完整继承原文档内容并结合仓库结构说明每个检查点的实际落点。1. CLI 命令的重命名或移除原文档规定如果注册在extensions/cli/src/commands/下的命令被重命名、移除或改动了 flag必须核对五类位置——docs/中的文档已反映新命令名.continue/agents/中的代理定义没有引用旧命令skills/中的技能已同步更新README 与 CONTRIBUTING.md 保持最新GitHub Actions 工作流没有再调用旧命令这份清单的针对性来自本仓库的真实命令结构。从源码看CLI 入口 extensions/cli/src/index.ts 使用commander构建名为cn的程序程序初始化子命令注册在 extensions/cli/src/commands/ 目录下当前包含子命令源文件说明根命令chat.ts默认进入交互式会话-p/--print为无头输出lsls.ts列出最近会话serveserve.ts启动带/state、/message端点的 HTTP 服务隐藏命令checkschecks.ts查看 PR 的 CI check 状态reviewreview.ts对变更运行 AI 评审除子命令外会话内的斜杠命令集中定义在 commands.ts 的SYSTEM_SLASH_COMMANDS表help、resume、fork、export等。这正是代理清单中“flag 变化”要覆盖的范围一旦--print、--review-agents这类 flag 或ls、review这类命令名变更文档、skills/ 目录下的技能如 skills/cn-check/、代理定义与 CI 工作流都可能留下指向旧名称的失效引用。2. 公共 API 变更原文档规定core/或packages/下导出的函数、接口或类型被重命名或签名变化时必须核对——gui/、extensions/、binary/中的所有调用方已同步更新packages/config-types/中的类型定义保持一致这一点与仓库的分层结构吻合core/ 承载核心能力如 core/protocol/ 定义的通信协议、core/config/ 的配置加载packages/config-types/ 提供对外暴露的配置类型定义而 gui/、extensions/、binary/ 是消费这些 API 的三大端。由于这几个模块分属不同包重命名一个导出符号很容易只改定义、漏改某一端的调用方——这正是该代理要求逐一核对的原因。3. 配置 schema 变更原文档规定配置文件格式YAML 或 JSON被修改时必须核对三点——校验逻辑能同时处理新旧两种格式或提供了迁移路径文档示例使用新格式默认配置已更新仓库中对应着真实的校验与迁移实现packages/config-yaml/ 承担 YAML 配置的解析与校验core/config/validation.ts 负责配置合法性检查而 core/config/migrateSharedConfig.ts 的存在说明项目确实有“schema 演进需要迁移逻辑”的实践。文档侧则由 docs/ 下的配置参考如 docs/reference/yaml-migration.mdx承担示例更新。代理清单要求“校验逻辑兼容或提供迁移”正是防止只改新格式解析、却让存量用户配置直接失效的典型事故。4. URL 变更原文档规定任何硬编码 URL例如hub.continue.dev、api.continue.dev发生变更时需要全仓库扫描失效引用。从仓库实际内容看这类 URL 并非孤例至少出现在 extensions/cli/src/env.ts、extensions/cli/src/version.ts、extensions/cli/src/util/apiClient.test.ts 等文件以及 packages/continue-sdk/ 的 SDK 代码中还散见于 BUILD_DEPENDENCIES.md、extensions/cli/docs/ 等文档。跨端引用面决定了改一个域名必须全局检索而非只改单一实现文件。三、处置规则修、标注、还是放过代理的第二部分定义了发现问题的处置边界直接决定其作为自动化审查者的行为收敛程度。What to Do该做什么发现失效引用时直接修复fix them directly——即代理被授权产出补丁而非仅提意见若某个破坏性变更没有迁移路径且可能影响用户添加评论标注该担忧但不阻断 PRdo not block只关注本次 PR 引入的变更Focus only on changes introduced in this PR不报告历史遗留问题pre-existing issues。What NOT to Flag不该报什么同一 PR 内已把所有引用一并更新的内部重构仅测试代码test-only code的变更不影响用户、只涉及开发工具链的变更。这套规则的设计意图很明确自动评审的第一死敌是误报。通过“同 PR 内已同步更新则豁免”“只看增量不看存量”“测试与开发工具链免检”三条负面清单把代理的输出收敛到“本次 PR 引入的、跨模块遗留的失效引用”这一高信噪比区间上——既能配合cn review --fix自动落补丁又不会因陈年问题刷屏导致审查被忽略。四、执行机制代理如何被发现、加载与运行理解代理被cn review消费的方式可以完整闭合本文。核心逻辑在 resolveReviews.ts按三级优先级决定运行哪些审查CLI--review-agents标志最高优先级接受 Hub slug 或本地路径Hub API源码注释说明该来源已移除当前 resolveFromHub 恒返回空数组本地回退扫描当前目录下.continue/agents/*.md与.continue/checks/*.md且同名文件 agents 目录优先于 checks 目录见 resolveFromLocal 实现。代理显示名由文件名派生去掉扩展名后把连字符、下划线替换为空格agentDisplayName所以breaking-change-detector.md在报告中显示为 breaking change detector。确定代理后review.ts 的runReviewInWorker会为每次评审 fork 一个带--internal-review-worker标志的子进程在独立 git worktree 中运行并设置 5 分钟超时worker 从本地 Markdown 文件加载代理指令见 reviewWorker.ts。当仓库中没有任何本地代理时review命令会提示创建入口“Create .continue/agents/my-review.md with agent instructions”见 review.ts 中的提示信息——breaking-change-detector.md 正是这条建议的成品示例。五、可迁移的方法论该文件示范了一套可复用的“破坏性变更审查规程”写法要点可直接搬到其他仓库按变更类别枚举检查点而不是泛泛说“检查引用”CLI 命令 → 文档/代理/技能/README/CIAPI → 各消费端 类型包schema → 校验兼容 文档示例 默认值URL → 全局扫描。每类检查点都落到具体目录。正面规则与负面清单成对出现既定义“发现即修复、只报增量”也明确三类豁免控制误报率。用 frontmatter 的name/description声明代理身份使其能被resolveReviews的本地扫描机制自动发现并生成可读的显示名。结合 extensions/cli/src/commands/ 的命令结构、packages/config-yaml/ 的配置校验层与 .continue/agents/ 的代理目录这份 Markdown 把“破坏性变更审查”从一个口头约定变成了cn review可执行、可复现的工程流程。【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
