基于 Strangler Fig 模式的 Legacy ModernizerClaude Code 插件体系中的旧代码渐进式现代化方案【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文对应的插件本体位于 legacy-modernizer.md它是本仓库 Codex / Claude Code 多形态 Agent 插件市场中code-refactoring领域的一枚“旧代码现代化专家”。导读code-refactoring插件提供了一类专门应对**遗留系统Legacy System**的 Agent 角色——Legacy Modernizer。它不是一次性的“重写大师”而是一位坚持Strangler Fig绞杀榕模式、以先补测试、再渐进替换为纪律的现代化专家。阅读完本文你将掌握该 Agent 在仓库中的定位与触发方式、它所覆盖的六大聚焦领域、五步渐进式现代化方法论以及它与同插件tech-debt、refactor-clean等命令、framework-migration插件之间的协作关系并能在你自己的多 Agent 工作流中复用它。一、Legacy Modernizer 是什么一个“安全升级”型专家 AgentLegacy Modernizer 是 code-refactoring 插件agents/目录下的一个角色定义文件。文件以 YAML frontmatter 声明其元信息name: code-refactoring-legacy-modernizer description: Refactor legacy codebases, migrate outdated frameworks, and implement gradual modernization. Handles technical debt, dependency updates, and backward compatibility. Use PROACTIVELY for legacy system updates, framework migrations, or technical debt reduction. model: sonnet从中可以看到几个关键事实命名空间前缀code-refactoring-Agent 名称在插件内全局唯一其它文件或命令如 legacy-modernize.md 中通过subagent_typeframework-migration-legacy-modernizer引用同名前缀的 Agent依赖该命名方式做子代理调度触发策略Use PROACTIVELY当用户提出“遗留系统升级、框架迁移、技术债削减”类诉求时该 Agent 应被主动唤醒而非等待显式调用模型规格model: sonnet这是一个声明式配置供上层 HarnessClaude Code、Codex、Cursor、OpenCode、Copilot 与 Antigravity 等在运行时据此选择合适的推理模型其作用由工具链解析仓库根目录可查看 tools/adapters 下各类适配器对元信息的消费方式角色内核一句话“focus on safe, incremental upgrades”——安全、增量地完成升级。值得注意的是仓库中 framework-migration 插件内存在一个内容几乎相同的同族 Agent名为framework-migration-legacy-modernizer二者共享同一套 Focus Areas / Approach / Output 方法论差异在于所属领域不同前者服务通用“代码重构”后者专门服务“框架迁移”。这也解释了为什么legacy-modernize编排命令会用subagent_typeframework-migration-legacy-modernizer直接作为执行 Agent。二、六大聚焦领域Legacy Modernizer 的职责边界Agent 文档用 “Focus Areas” 明确划定了它管什么、不管什么。六大领域为聚焦领域典型场景风险特征框架迁移Framework migrationsjQuery→React、Java 8→17、Python 2→3高危语法/语义双破坏面数据库现代化Database modernization存储过程→ORM高危数据一致性单体→微服务拆分Monolith to microservices decomposition巨型单体按边界切分高危分布式事务/调用链依赖升级与安全补丁Dependency updates and security patches过期库、CVE 修复中危隐性兼容破坏遗留代码测试覆盖Test coverage for legacy code无测试老代码补 characterization tests作为“安全网”前置条件API 版本化与向后兼容API versioning and backward compatibility接口演进、弃用策略贯穿始终的约束这份清单与 tech-debt.md 中的“技术债清册”分类一一呼应Code Debt / Architecture Debt / Technology Debt / Testing Debt / Infrastructure Debt。可以这样理解协作关系tech-debt命令负责“体检与排期”Legacy Modernizer Agent 负责“执行手术”——前者产出按 ROI 排序的债务清单后者按图索骥做渐进替换。三、五步方法论Strangler Fig 安全渐进式现代化Agent 文档的 “Approach” 定义了必须遵守的五步节奏这是整份文档的灵魂任何调用它的编排命令都以此为准绳Strangler Fig pattern —— 渐进式替换像绞杀榕缠绕宿主树一样新系统在旧系统外围逐步生长而非推倒重建Add tests before refactoring —— 重构前先补测试把“当前行为”先固化为测试characterization tests作为重构的回归安全网Maintain backward compatibility —— 维持向后兼容任何阶段都不能破坏现有调用方Document breaking changes clearly —— 清晰记录破坏性变更弃用、迁移路径、时间线必须成文Feature flags for gradual rollout —— 特性开关灰度放量流量按 5% → 25% → 50% → 100% 的节奏切换随时可熔断回退。这套五步法在 framework-migration/commands/legacy-modernize.md 中被落成了可执行的 13 步编排工作流是理解“方法论如何落地”的最佳源码证据Phase 1: Legacy Assessment and Risk Analysis (Step 1–3) └─ 01-legacy-assessment.md 技术债盘点/复杂度评分(1-10) └─ 02-dependency-map.md 依赖图与集成点目录 └─ 03-business-impact.md 风险矩阵 (业务价值×0.4 技术风险×0.3 快速见效×0.3) 加权排序 → PHASE CHECKPOINT 1必须等待用户显式审批禁止自行续跑 Phase 2: Test Coverage Establishment (Step 4–6) └─ 04-test-coverage.md 对 40% 覆盖率的组件生成 characterization tests └─ 05-contract-tests.md 消费者驱动契约测试 P95 性能基线 └─ 06-test-data.md 并行运行期数据一致性监控与脱敏 → PHASE CHECKPOINT 2 Phase 3: Incremental Migration Implementation (Step 7–9) └─ 07-infrastructure.md API 网关路由 特性开关 熔断器 双系统可观测 └─ 08-first-wave.md 首批“快速见效”组件现代化依赖注入/SOLID/适配层/双写 └─ 09-security.md OAuth2/JWT、RBAC、OWASP Top 10 加固 → PHASE CHECKPOINT 3 Phase 4: Performance Validation and Rollout (Step 10–11) └─ 10-performance.md 压测对比P95 须在基线 110% 以内 └─ 11-rollout.md 5%→25%→50%→100% 放量 自动回滚触发器错误率1% / 延迟2x → PHASE CHECKPOINT 4 Phase 5: Migration Completion and Documentation (Step 12–13) └─ 12-decommission.md 0% 流量观察 ≥30 天后下线旧组件 └─ 13-documentation.md 架构图、API 迁移指南、双系统运行手册、经验总结该编排命令还规定了若干CRITICAL BEHAVIORAL RULES它们正是对五步方法论的程序化强制步骤必须按序执行、每步产物落盘到.legacy-modernize/不依赖上下文窗口记忆、到达 PHASE CHECKPOINT 必须停等用户审批、任何一步失败立即暂停汇报。也就是说“安全”不是靠自觉而是靠流程硬约束。四、可交付物清单Output一次现代化会话该交什么Agent 文档规定完成一次现代化任务后必须产出六类可交付物交付物内容要点分阶段迁移计划Migration plan with phases and milestones里程碑与阶段切分、时长与成功标准保功能重构代码Refactored code with preserved functionality行为等价靠测试证明遗留行为测试套件Test suite for legacy behavior重构安全网兼容层Compatibility shim/adapter layers新旧格式互转的垫片弃用警告与时间线Deprecation warnings and timelines明确弃用节奏各阶段回滚预案Rollback procedures for each phase每阶段独立可回退“Rollback procedures for each phase”是区分专家级现代化与莽撞重写的分水岭——这也是为何 code-refactoring/commands/refactor-clean.md 在讲授代码重构时同样强调“If breaking changes are introduced先给 Step-by-Step Migration再用临时 Adapter 保平滑迁移”。例如它给出的LegacyOrderProcessor兼容适配器正是本 Agent “compatibility shim/adapter layers”交付物在方法级的具体形态# 临时适配器保证迁移期间老调用方不受影响 class LegacyOrderProcessor: def __init__(self): self.processor OrderProcessor() def process(self, order_data): # 将旧格式转换为新领域模型 order Order.from_legacy(order_data) return self.processor.process(order)五、典型应用场景调用链与协作图综合仓库内文档Legacy Modernizer 在两类场景中被激活场景 A用户直接向code-refactoring领域的 Agent 求助当会话命中“遗留系统更新 / 框架迁移 / 技术债削减”意图时对应 frontmatter 中的Use PROACTIVELYLegacy Modernizer 被选中并加载随后它可以自行调用 tech-debt.md做债务量化或 refactor-clean.md执行清理重构来获取输入与指导。场景 B被 framework-migration 编排命令作为子代理调度legacy-modernize.md 在 Step 1遗留系统分析与 Step 12下线规划中分别以subagent_typeframework-migration-legacy-modernizer引用同族 Agent——由主 Agent 派发任务、收取落盘产物、继续推进 13 步流水线。这种“专家 Agent 编排命令”的解耦方式体现了本仓库插件市场的通用设计模式命令负责流程纪律Agent 负责领域判断。六、风险控制红线Agent 文档以一句话收束其哲学Focus on risk mitigation. Never break existing functionality without migration path. 聚焦风险缓释。在没有迁移路径的前提下绝不破坏现有功能。这条“红线”在仓库各关联文档中被反复强化编排层checkpoint 硬停、失败即停、.legacy-modernize/state.json断点续跑测试层先 characterization tests、后 contract tests、再性能基线发布层特性开关灰度、24 小时观察窗、自动回滚阈值治理层refactor-clean.md 的 Code Quality Checklist 与 tech-debt.md 的质量门禁复杂度 ≤10、方法 ≤20 行、覆盖率 ≥80%共同构成“防新增债务”的护栏。结语把“大胆重构”变成“小步快跑的安全工程”从 legacy-modernizer.md 这份不足百行的 Agent 定义可以看出真正专业的遗留代码现代化不在于一蹴而就的勇气而在于Strangler Fig 渐进替换 测试先行 兼容兜底 灰度放量 随时回滚的系统性纪律。这份方法论既封装为可被 Claude Code、Codex、Cursor、OpenCode、Copilot、Antigravity 等多 Harness 复用的插件 Agent又通过 framework-migration 的 13 步工作流给出了可直接运行的工程骨架——无论是想要一位“随身的老代码医生”还是想搭建一条端到端的现代化流水线本仓库都已给出可复制的答案。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
基于 Strangler Fig 模式的 Legacy Modernizer：Claude Code 插件体系中的旧代码渐进式现代化方案
基于 Strangler Fig 模式的 Legacy ModernizerClaude Code 插件体系中的旧代码渐进式现代化方案【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文对应的插件本体位于 legacy-modernizer.md它是本仓库 Codex / Claude Code 多形态 Agent 插件市场中code-refactoring领域的一枚“旧代码现代化专家”。导读code-refactoring插件提供了一类专门应对**遗留系统Legacy System**的 Agent 角色——Legacy Modernizer。它不是一次性的“重写大师”而是一位坚持Strangler Fig绞杀榕模式、以先补测试、再渐进替换为纪律的现代化专家。阅读完本文你将掌握该 Agent 在仓库中的定位与触发方式、它所覆盖的六大聚焦领域、五步渐进式现代化方法论以及它与同插件tech-debt、refactor-clean等命令、framework-migration插件之间的协作关系并能在你自己的多 Agent 工作流中复用它。一、Legacy Modernizer 是什么一个“安全升级”型专家 AgentLegacy Modernizer 是 code-refactoring 插件agents/目录下的一个角色定义文件。文件以 YAML frontmatter 声明其元信息name: code-refactoring-legacy-modernizer description: Refactor legacy codebases, migrate outdated frameworks, and implement gradual modernization. Handles technical debt, dependency updates, and backward compatibility. Use PROACTIVELY for legacy system updates, framework migrations, or technical debt reduction. model: sonnet从中可以看到几个关键事实命名空间前缀code-refactoring-Agent 名称在插件内全局唯一其它文件或命令如 legacy-modernize.md 中通过subagent_typeframework-migration-legacy-modernizer引用同名前缀的 Agent依赖该命名方式做子代理调度触发策略Use PROACTIVELY当用户提出“遗留系统升级、框架迁移、技术债削减”类诉求时该 Agent 应被主动唤醒而非等待显式调用模型规格model: sonnet这是一个声明式配置供上层 HarnessClaude Code、Codex、Cursor、OpenCode、Copilot 与 Antigravity 等在运行时据此选择合适的推理模型其作用由工具链解析仓库根目录可查看 tools/adapters 下各类适配器对元信息的消费方式角色内核一句话“focus on safe, incremental upgrades”——安全、增量地完成升级。值得注意的是仓库中 framework-migration 插件内存在一个内容几乎相同的同族 Agent名为framework-migration-legacy-modernizer二者共享同一套 Focus Areas / Approach / Output 方法论差异在于所属领域不同前者服务通用“代码重构”后者专门服务“框架迁移”。这也解释了为什么legacy-modernize编排命令会用subagent_typeframework-migration-legacy-modernizer直接作为执行 Agent。二、六大聚焦领域Legacy Modernizer 的职责边界Agent 文档用 “Focus Areas” 明确划定了它管什么、不管什么。六大领域为聚焦领域典型场景风险特征框架迁移Framework migrationsjQuery→React、Java 8→17、Python 2→3高危语法/语义双破坏面数据库现代化Database modernization存储过程→ORM高危数据一致性单体→微服务拆分Monolith to microservices decomposition巨型单体按边界切分高危分布式事务/调用链依赖升级与安全补丁Dependency updates and security patches过期库、CVE 修复中危隐性兼容破坏遗留代码测试覆盖Test coverage for legacy code无测试老代码补 characterization tests作为“安全网”前置条件API 版本化与向后兼容API versioning and backward compatibility接口演进、弃用策略贯穿始终的约束这份清单与 tech-debt.md 中的“技术债清册”分类一一呼应Code Debt / Architecture Debt / Technology Debt / Testing Debt / Infrastructure Debt。可以这样理解协作关系tech-debt命令负责“体检与排期”Legacy Modernizer Agent 负责“执行手术”——前者产出按 ROI 排序的债务清单后者按图索骥做渐进替换。三、五步方法论Strangler Fig 安全渐进式现代化Agent 文档的 “Approach” 定义了必须遵守的五步节奏这是整份文档的灵魂任何调用它的编排命令都以此为准绳Strangler Fig pattern —— 渐进式替换像绞杀榕缠绕宿主树一样新系统在旧系统外围逐步生长而非推倒重建Add tests before refactoring —— 重构前先补测试把“当前行为”先固化为测试characterization tests作为重构的回归安全网Maintain backward compatibility —— 维持向后兼容任何阶段都不能破坏现有调用方Document breaking changes clearly —— 清晰记录破坏性变更弃用、迁移路径、时间线必须成文Feature flags for gradual rollout —— 特性开关灰度放量流量按 5% → 25% → 50% → 100% 的节奏切换随时可熔断回退。这套五步法在 framework-migration/commands/legacy-modernize.md 中被落成了可执行的 13 步编排工作流是理解“方法论如何落地”的最佳源码证据Phase 1: Legacy Assessment and Risk Analysis (Step 1–3) └─ 01-legacy-assessment.md 技术债盘点/复杂度评分(1-10) └─ 02-dependency-map.md 依赖图与集成点目录 └─ 03-business-impact.md 风险矩阵 (业务价值×0.4 技术风险×0.3 快速见效×0.3) 加权排序 → PHASE CHECKPOINT 1必须等待用户显式审批禁止自行续跑 Phase 2: Test Coverage Establishment (Step 4–6) └─ 04-test-coverage.md 对 40% 覆盖率的组件生成 characterization tests └─ 05-contract-tests.md 消费者驱动契约测试 P95 性能基线 └─ 06-test-data.md 并行运行期数据一致性监控与脱敏 → PHASE CHECKPOINT 2 Phase 3: Incremental Migration Implementation (Step 7–9) └─ 07-infrastructure.md API 网关路由 特性开关 熔断器 双系统可观测 └─ 08-first-wave.md 首批“快速见效”组件现代化依赖注入/SOLID/适配层/双写 └─ 09-security.md OAuth2/JWT、RBAC、OWASP Top 10 加固 → PHASE CHECKPOINT 3 Phase 4: Performance Validation and Rollout (Step 10–11) └─ 10-performance.md 压测对比P95 须在基线 110% 以内 └─ 11-rollout.md 5%→25%→50%→100% 放量 自动回滚触发器错误率1% / 延迟2x → PHASE CHECKPOINT 4 Phase 5: Migration Completion and Documentation (Step 12–13) └─ 12-decommission.md 0% 流量观察 ≥30 天后下线旧组件 └─ 13-documentation.md 架构图、API 迁移指南、双系统运行手册、经验总结该编排命令还规定了若干CRITICAL BEHAVIORAL RULES它们正是对五步方法论的程序化强制步骤必须按序执行、每步产物落盘到.legacy-modernize/不依赖上下文窗口记忆、到达 PHASE CHECKPOINT 必须停等用户审批、任何一步失败立即暂停汇报。也就是说“安全”不是靠自觉而是靠流程硬约束。四、可交付物清单Output一次现代化会话该交什么Agent 文档规定完成一次现代化任务后必须产出六类可交付物交付物内容要点分阶段迁移计划Migration plan with phases and milestones里程碑与阶段切分、时长与成功标准保功能重构代码Refactored code with preserved functionality行为等价靠测试证明遗留行为测试套件Test suite for legacy behavior重构安全网兼容层Compatibility shim/adapter layers新旧格式互转的垫片弃用警告与时间线Deprecation warnings and timelines明确弃用节奏各阶段回滚预案Rollback procedures for each phase每阶段独立可回退“Rollback procedures for each phase”是区分专家级现代化与莽撞重写的分水岭——这也是为何 code-refactoring/commands/refactor-clean.md 在讲授代码重构时同样强调“If breaking changes are introduced先给 Step-by-Step Migration再用临时 Adapter 保平滑迁移”。例如它给出的LegacyOrderProcessor兼容适配器正是本 Agent “compatibility shim/adapter layers”交付物在方法级的具体形态# 临时适配器保证迁移期间老调用方不受影响 class LegacyOrderProcessor: def __init__(self): self.processor OrderProcessor() def process(self, order_data): # 将旧格式转换为新领域模型 order Order.from_legacy(order_data) return self.processor.process(order)五、典型应用场景调用链与协作图综合仓库内文档Legacy Modernizer 在两类场景中被激活场景 A用户直接向code-refactoring领域的 Agent 求助当会话命中“遗留系统更新 / 框架迁移 / 技术债削减”意图时对应 frontmatter 中的Use PROACTIVELYLegacy Modernizer 被选中并加载随后它可以自行调用 tech-debt.md做债务量化或 refactor-clean.md执行清理重构来获取输入与指导。场景 B被 framework-migration 编排命令作为子代理调度legacy-modernize.md 在 Step 1遗留系统分析与 Step 12下线规划中分别以subagent_typeframework-migration-legacy-modernizer引用同族 Agent——由主 Agent 派发任务、收取落盘产物、继续推进 13 步流水线。这种“专家 Agent 编排命令”的解耦方式体现了本仓库插件市场的通用设计模式命令负责流程纪律Agent 负责领域判断。六、风险控制红线Agent 文档以一句话收束其哲学Focus on risk mitigation. Never break existing functionality without migration path. 聚焦风险缓释。在没有迁移路径的前提下绝不破坏现有功能。这条“红线”在仓库各关联文档中被反复强化编排层checkpoint 硬停、失败即停、.legacy-modernize/state.json断点续跑测试层先 characterization tests、后 contract tests、再性能基线发布层特性开关灰度、24 小时观察窗、自动回滚阈值治理层refactor-clean.md 的 Code Quality Checklist 与 tech-debt.md 的质量门禁复杂度 ≤10、方法 ≤20 行、覆盖率 ≥80%共同构成“防新增债务”的护栏。结语把“大胆重构”变成“小步快跑的安全工程”从 legacy-modernizer.md 这份不足百行的 Agent 定义可以看出真正专业的遗留代码现代化不在于一蹴而就的勇气而在于Strangler Fig 渐进替换 测试先行 兼容兜底 灰度放量 随时回滚的系统性纪律。这份方法论既封装为可被 Claude Code、Codex、Cursor、OpenCode、Copilot、Antigravity 等多 Harness 复用的插件 Agent又通过 framework-migration 的 13 步工作流给出了可直接运行的工程骨架——无论是想要一位“随身的老代码医生”还是想搭建一条端到端的现代化流水线本仓库都已给出可复制的答案。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考