企业官网建设流程全解析

基于 Strangler Fig 模式的 Legacy Modernizer：Claude 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 是什么：一个“安全升级”型专家 Agent

Legacy 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

从中可以看到几个关键事实：

1. 命名空间前缀code-refactoring-：Agent 名称在插件内全局唯一，其它文件或命令（如 legacy-modernize.md 中通过subagent_type="framework-migration-legacy-modernizer"引用同名前缀的 Agent）依赖该命名方式做子代理调度；
2. 触发策略（Use PROACTIVELY）：当用户提出“遗留系统升级、框架迁移、技术债削减”类诉求时，该 Agent 应被主动唤醒，而非等待显式调用；
3. 模型规格model: sonnet：这是一个声明式配置，供上层 Harness（Claude Code、Codex、Cursor、OpenCode、Copilot 与 Antigravity 等）在运行时据此选择合适的推理模型，其作用由工具链解析（仓库根目录可查看 tools/adapters 下各类适配器对元信息的消费方式）；
4. 角色内核一句话：“focus on safe, incremental upgrades”——安全、增量地完成升级。

值得注意的是，仓库中 framework-migration 插件内存在一个内容几乎相同的同族 Agent（名为framework-migration-legacy-modernizer），二者共享同一套 Focus Areas / Approach / Output 方法论，差异在于所属领域不同：前者服务通用“代码重构”，后者专门服务“框架迁移”。这也解释了为什么legacy-modernize编排命令会用subagent_type="framework-migration-legacy-modernizer"直接作为执行 Agent。

二、六大聚焦领域：Legacy Modernizer 的职责边界

Agent 文档用 “Focus Areas” 明确划定了它管什么、不管什么。六大领域为：

这份清单与 tech-debt.md 中的“技术债清册”分类一一呼应（Code Debt / Architecture Debt / Technology Debt / Testing Debt / Infrastructure Debt）。可以这样理解协作关系：tech-debt命令负责“体检与排期”，Legacy Modernizer Agent 负责“执行手术”——前者产出按 ROI 排序的债务清单，后者按图索骥做渐进替换。

三、五步方法论：Strangler Fig 安全渐进式现代化

Agent 文档的 “Approach” 定义了必须遵守的五步节奏，这是整份文档的灵魂，任何调用它的编排命令都以此为准绳：

1. Strangler Fig pattern —— 渐进式替换：像绞杀榕缠绕宿主树一样，新系统在旧系统外围逐步生长，而非推倒重建；
2. Add tests before refactoring —— 重构前先补测试：把“当前行为”先固化为测试（characterization tests），作为重构的回归安全网；
3. Maintain backward compatibility —— 维持向后兼容：任何阶段都不能破坏现有调用方；
4. Document breaking changes clearly —— 清晰记录破坏性变更：弃用、迁移路径、时间线必须成文；
5. 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 文档规定，完成一次现代化任务后必须产出六类可交付物：

“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 PROACTIVELY），Legacy Modernizer 被选中并加载，随后它可以自行调用 tech-debt.md（做债务量化）或 refactor-clean.md（执行清理重构）来获取输入与指导。

场景 B：被 framework-migration 编排命令作为子代理调度legacy-modernize.md 在 Step 1（遗留系统分析）与 Step 12（下线规划）中分别以subagent_type="framework-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