在 Windsurf 上落地 Dependency Sweeper 循环：loop-engineering 依赖清扫模式的 Cascade Workflow 实战

人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务【免费下载链接】loop-engineeringPractical patterns, starters CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址https://gitcode.com/gh_mirrors/lo/loop-engineering点击查看免费下载导读本文围绕 loop-engineering 仓库中为 Windsurf 补齐 Dependency Sweeper 示例这一落地任务展开系统讲解如何用 Windsurf 的 Cascade Workflow.windsurf/workflows/把依赖清扫循环Dependency Sweeper Loop映射到没有原生调度器的 Windsurf 上。读完你将掌握第一周 report-only 的依赖审计与升级建议流程、L2 阶段 patch-only 自动修复 熔断器 人工门闸的完整配置以及状态文件、预算与验证策略的维护方法。一、这个示例要解决什么问题在 examples/README.md 的 Pattern coverage 矩阵中每个模式都按工具Grok、Claude Code、Codex、Cursor、Windsurf 等展开示例。其中Dependency Sweeper × Windsurf一度是空缺单元格需要新增一份可复制、可粘贴的 Windsurf 示例来补全矩阵。仓库中对应的 issue 说明scripts/issue-bodies/windsurf-dependency-sweeper-example.md把这份工作明确为一个可验收的落地任务Goal目标新增一个Windsurf Dependency Sweeper示例填补覆盖矩阵中 Windsurf × Dependency Sweeper 的空白。Files涉及文件新建 examples/windsurf/dependency-sweeper.md在 examples/windsurf/README.md 中登记链接在 examples/README.md 中填充 Dependency Sweeper × Windsurf 单元格。Estimated time约 40 分钟采用 Comment Ill take this to get assigned 的认领式协作。验收标准Acceptance criteria共四条也是本文展开的技术主线第一周report-only输出 audit/outdated 摘要 仅补丁patch-only的升级建议笔记升级 major 版本必须升级给人类绝不静默执行 major bump对 L2可修改文件的修复级循环必须提及熔断器 / 预算机制整体语气与 examples/cursor/dependency-sweeper.md 保持一致同模式、不同工具仅调度与调用方式不同。截至当前仓库上述三个文件均已就位示例正文、Windsurf README 表格中的 Dependency Sweeper | 6h–1d (manual/dependency-sweeper; external reminder optional) | Medium 一行以及 examples 覆盖矩阵中指向 examples/windsurf/dependency-sweeper.md 的单元格。本文即以这份落地成果为骨架深入其实现原理与扩展细节。二、先理解模式本身Dependency Sweeper 循环Windsurf 示例只是某个通用模式在特定工具上的投影。在动手之前必须先掌握模式本体——patterns/dependency-sweeper.md 定义了循环的完整形态Goal模式目标发现过期或有漏洞的依赖应用最小的安全更新在隔离环境中用测试/构建验证并把任何高风险动作major bump、破坏性变更、高危漏洞升级给人类。建议调度方式Grok/loop 6h dependency-sweeper或工作时间内每日运行Claude Code/loop 12h /sweep-deps/goal keep the dependency surface clean and greenCodex按 4–12 小时周期调度 triage minimal-fix 流程GitHub ActionsDependabot 定时或 workflow_dispatch 触发的清扫器见 examples/github-actions/。必需技能dependency-triage——解析 lockfile / 包清单按风险patch/minor/major 已知 CVE分组产出带建议目标版本与理由的短清单minimal-fix——只做最小的改动通常只是版本号提升 lockfile 更新绝不顺手重构loop-verifier或项目测试脚本——在干净 worktree 中跑测试/构建/lint确认改动没有引入回归。典型循环周期7 步扫描清单与 lockfile、安全通告Dependabot/OSV/npm audit→ 分成安全patch 且无 CVE/谨慎minor/高风险major 或高危 CVE→ 对安全项开 worktree、用 minimal-fix 做最小版本与 lock 更新、跑 verifier → verifier 通过则开小 PR或在依赖分支上提交并记入状态 → 谨慎/高风险项写入状态并标注 needs human 与上下文 → 更新状态文件、可选地在依赖 PR 上评论 → 下一轮重新评估、关闭过期或冲突条目。该模式是可修复的 L2 模式因此loop-init会自动为其搭好loop-guard技能和种子化的loop-ledger.json。在仓库中你可以看到配套的 starterstarters/dependency-sweeper/内含 LOOP.md、README.md 与状态文件示例以及独立的 triage 技能实现 starters/dependency-sweeper-opencode/skills/dependency-triage/SKILL.md。三、Windsurf 的映射策略Cascade Workflow 外部触发器Windsurf没有原生/loop调度器或内置 cron这是与 Grok、Claude Code 最大的差异。仓库给出的映射策略是把循环映射到一个Cascade Workflow.windsurf/workflows/dependency-sweeper.md用/dependency-sweeper手动调用如果需要无人值守的节奏如 6h–1d就配合外部提醒或触发器GitHub Actions cron、launchd、cron或 systemd由外部调度器提醒人类运行该 workflow。注意这里的边界外部调度器只负责提醒/触发不应自动合并或操作 PR——合并动作永远保留给人类或显式白名单。这一调度与执行分离的设计也体现在 examples/windsurf/README.md 的说明中外部提醒可以提供节奏但不能代替人来合并。另一个关键限制来自 Windsurf README 原话目前还没有loop-init --tool windsurf。因此 Windsurf 的接入方式是从任意 starter如 starters/minimal-loop复制SKILL.mdSTATE.md再按示例手工接线 Cascade Workflow。这一点与 Grok/Claude/Codex 可通过loop-init --tool ...一键生成不同需要在方案选型时纳入考量。复制完成后可用 tools/loop-audit 审计项目现状npx cobusgreyling/loop-audit . --suggest四、环境准备把共享技能与状态文件复制进 Windsurfexamples/windsurf/dependency-sweeper.md 给出的 Setup 命令是把仓库中的共享技能与状态模板复制到 Windsurf 的项目本地路径mkdir -p .windsurf/rules/dependency-triage \ .windsurf/rules/minimal-fix \ .windsurf/rules/loop-verifier cp starters/dependency-sweeper/.claude/skills/dependency-triage/SKILL.md \ .windsurf/rules/dependency-triage/SKILL.md cp templates/SKILL.md.minimal-fix \ .windsurf/rules/minimal-fix/SKILL.md cp templates/SKILL.md.verifier \ .windsurf/rules/loop-verifier/SKILL.md cp starters/dependency-sweeper/dependency-sweeper-state.md.example \ dependency-sweeper-state.md命令背后的仓库依据dependency-triage技能的实际实现可在 starters/dependency-sweeper-opencode/skills/dependency-triage/SKILL.md 中看到完整定义扫描源覆盖npm outdated/npm audit、cargo outdated/cargo audit、pip list --outdated与 lockfile 分析分类规则为Patch / Minor 自动修复候选Major 升级人类CVE 高危升级人类、低/中危仅补丁输出统一写入dependency-sweeper-state.md的优先级清单并明确第一周默认仅补丁、遵守状态文件中的 denylist、批准前先跑npm ci npm test或等价命令。minimal-fix的模板定义见 templates/SKILL.md.minimal-fix它要求只修一个具体问题、产出能工作的最小 diff涉及超过 5 个文件或需要设计变更时停止并升级命中路径 denylist.env、auth/、payments/、密钥等时停止并升级且禁止削弱测试或断言来变绿。loop-verifier的模板见 templates/SKILL.md.verifier对应模式的验证者子代理职责。此外始终开启的路径 denylist、包 denylist 与自动升级限制除了写进.windsurf/rules/也要写进 workflow 的提示词中形成双重约束。五、第一周 WorkflowReport-Only验收标准 1创建.windsurf/workflows/dependency-sweeper.md内容如下即示例文档给出的完整 workflow# Dependency Sweeper **Description:** Audit package manifests/lockfiles for outdated dependencies and vulnerabilities. Report only, no auto-fix. 1. Read dependency-sweeper-state.md and .windsurf/rules/dependency-triage/SKILL.md. 2. Run the dependency-triage skill on package manifests and lockfiles. 3. Group findings by risk level (patch, minor, major, known CVEs). 4. Update dependency-sweeper-state.md with top findings and patch-only proposal notes. 5. Week one is report-only: - do not edit package manifests (package.json, etc.) or lockfiles; - do not open pull requests or push commits; - escalate major version bumps (no silent major bumps) and high-severity CVEs to a human.然后在 Cascade chat 中用/dependency-sweeper调用。这一阶段严格对应验收标准 1只审计、只输出 patch-only 升级建议不改清单、不开 PR、不推送提交。这样做的工程理由在于在循环被信任之前人类必须先亲自阅读状态文件若干轮确认 triage 的分类质量——这正是 patterns/dependency-sweeper.md 中Start with patch-level only known CVE fixes on a single repo for 1-2 weeks的落地方式。对于无人值守节奏Windsurf 保持人工审阅/triage 面仅用外部调度器提醒人类或触发执行每次运行后都要审阅状态文件。权限边界请参见 docs/safety.md。六、L2 进阶Patch-Only 自动修复 熔断器验收标准 3当 report-only 的 triage 输出持续准确后可以允许对安全更新做 patch-only 自动修复。这是本模式的关键风险跃迁examples/windsurf/dependency-sweeper.md 给出了 5 步渐进方案第 1 步每个尝试都开全新 worktree。绝不直接改主工作树npx cobusgreyling/loop-worktree create --run-id run-id --pattern dependency-sweeperloop-worktree是仓库中独立的 CLI 工具见 tools/loop-worktree/它把每包一次更新尝试对应一个 worktree固化为硬约束starters/dependency-sweeper/LOOP.md 同样规定每个包更新尝试一个 worktreeREJECT 或升级人类后丢弃该 worktree。第 2 步仅对白名单内的 patch 更新应用minimal-fix最小版本更新不碰任何其他代码。第 3 步在独立会话/验证步骤中运行loop-verifier.windsurf/rules/loop-verifier/SKILL.md跑测试与构建。第 4 步熔断器与预算。每次对同一包重试之前先运行熔断器检查npx cobusgreyling/loop-context --check --ledger loop-ledger.json \ --budget-from-pattern dependency-sweeper --budget-level L2熔断器来自 tools/loop-contextcobusgreyling/loop-context其 package.json 描述为带熔断器的有状态记忆管理器遇到停滞或无进展的运行就升级而不是烧 token。当尝试次数达到上限或熔断器触发时模式中默认同一依赖失败 2 次后升级见 patterns/dependency-sweeper.md 的 Escalate after 2 tries命令以非零码退出——此时停止重试并升级给人类而不是继续循环。同时必须尊重 loop-budget.md 中定义的每日 token 上限建议500k tokens。第 5 步major bump 永远需要人工批准。任何 major 版本升级在提出合并建议前都必须先获得人类同意绝不静默应用 major 升级对应验收标准 2。这一整套report-only → patch-only 熔断器的渐进路径与同仓库的 examples/cursor/dependency-sweeper.md 完全同构——Cursor 示例同样要求worktree per attempt、verifier gate、human gate for majors、max 3 fix attempts per package per run。这正是验收标准 4语气对齐的实现同一模式骨架只换工具映射层。七、状态文件循环的唯一事实源循环的持久化与人类协作都围绕dependency-sweeper-state.md展开。种子模板见 starters/dependency-sweeper/dependency-sweeper-state.md.exampleWindsurf 示例给出了一个运行中的状态示例# Dependency Sweeper State Last run: 2026-07-11 06:00 UTC Mode: report-only ## Pending updates ### lodash 4.17.20 → 4.17.21 (patch) - Severity: low - Loop action: report-only (week one). Candidate for patch-auto next cycle. - Attempts: 0 / 3 ### react 18.2.0 → 19.0.0 (major) - Severity: high (breaking changes in hooks API) - Loop action: escalated to human. Do not auto-apply major bump. ## Denylist - webpack (frozen at 5.x per team decision)patterns/dependency-sweeper.md 对状态文件的维护有两条硬性要求保持紧凑记录进行中的更新、上次动作与人类决策如package.json (lodash): 4.17.21 → 4.17.21 (CVE-2021-23337) — applied patch, tests green这类条目并附Last:时间戳与Human:决策每轮清理合并/关闭的条目要在每次运行时剪除。状态文件同时承担三类角色进行中更新的账本、denylist循环永不触碰的包如 auth、支付、核心基础设施、大型内部 monorepo 包的载体、以及 needs human 通知清单——模式规定只对状态中 needs human 部分通知人类其余静默或按日汇总避免通知轰炸。八、验证策略与人工交接点模式的验证铁律在 patterns/dependency-sweeper.md 中明确写出绝不让实施子代理宣布成功——verifier 必须独立于 implementer始终在隔离 worktree中运行 verifier 子代理或显式npm test npm run build循环只提出变更或 PR真正的合并由人类或已知安全补丁白名单执行安全更新优先采用能解决通告的最小补丁。人工交接点Human Handoff Points包括任何 major bump、一次触及超过 N 个包 lockfile 的变更、高危/严重 CVE即使已有补丁、denylist 上的包、同一依赖自动尝试 N 次仍无进展、verifier worktree 中测试或类型检查失败。九、失败模式与缓解patterns/dependency-sweeper.md 用一张表总结了循环最常见的失败形态与对策失败形态缓解措施循环应用了安全更新却在生产环境弄坏构建worktree 中强 verifier 无显式白名单绝不自动合并 patch 以外一律人工审阅无限更新循环A 依赖 B、B 又回滚每包每 24h 限制尝试次数状态中记录上次尝试的版本失败 2 次后升级安全补丁在别处引入新漏洞verifier 在变更后必须包含npm audit或等价检查一次更新触及几十个传递依赖视为高风险minimal-fix 步骤只允许触碰直接依赖通知轰炸只对状态中 needs human 条目通知人类其余静默或每日汇总十、成本画像与预算依赖清扫是典型的验证贵于修复型循环——verifier 的npm ci npm test占绝对大头。模式给出了 token 成本画像场景Tokens/次说明无操作无需升级约 5k扫描干净即退出Triage / 扫描约 60kAudit Dependabot lockfile 扫描Patch 验证L2约 300kWorktree 全量测试套件Cadence节奏6h–1d ·Tier层级medium ·建议每日上限500k tokens。可用 loop-cost 查询npx cobusgreyling/loop-cost --pattern dependency-sweeper --level L2starters/dependency-sweeper/LOOP.md 还定义了运行级预算护栏每次运行最多 3 个子代理派发、每天最多 5 个自动 PR、token 预算超限即暂停预算模板见 templates/loop-budget.md.template。由于 verifier 运行是成本主导项模式建议在loop-budget.md中限制每包的验证尝试次数。十一、验收标准对照与成功度量回到 issue 的四条验收标准逐条核对仓库中的落地成果Week-one report-only✅ 见 examples/windsurf/dependency-sweeper.md 的 Workflow (week one — report only) 小节与示例状态文件Escalate majors; no silent major bumps✅ workflow 步骤 5 与 L2 步骤 5 均显式规定 major bump 必须升级人类Circuit-breaker / budget mention for L2✅ 见 L2 第 4 步的loop-context --check命令与 500k token 上限Follow tone of cursor example✅ 两份文档均采用 week one report-only → patch-only worktree verifier gate human gate for majors 的相同叙事结构。模式还定义了长期成功度量可用于评估循环上线后的效果从漏洞发布 / Dependabot PR 打开到合并的中位时间开放超过 48h 的高危/严重漏洞数量目标趋近于零纯LGTM循环处理了 bump 并验证的依赖 PR 占比以及 Slack/Linear 中 can you bump X? 消息的减少量。十二、小结Windsurf × Dependency Sweeper 的落地本质是同模式、换工具层模式本体triage → minimal-fix → verifier → 熔断器 → 人工闸门由 patterns/dependency-sweeper.md 统一定义Windsurf 侧只需解决两件事——用 Cascade Workflow 承接手动调用、用外部调度器补足节奏。通过 examples/windsurf/dependency-sweeper.md 这份可复制示例一个团队可以在约 40 分钟内完成从空矩阵单元格到第一周 report-only、第二周起 patch-only 熔断器的完整接线并借助 docs/primitives-matrix.md 中六段式循环形状discovery/triage → minimal fix → verify → propose → merge → state update将同一模式平移到任意其他工具。更完整的运行实录可参考 stories/dependency-sweeper-week-one.md 与 docs/loop-design-checklist.md。赞分享人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务【免费下载链接】loop-engineeringPractical patterns, starters CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址https://gitcode.com/gh_mirrors/lo/loop-engineering点击查看免费下载相关推荐在 Windsurf 中落地 CI Sweeper基于 Cascade Workflow 的 CI 故障清扫循环实战在 Windsurf 中落地 CI Sweeper基于 Cascade Workflow 的 CI 故障清扫循环实战 CI Sweeper 是 loop en人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务在 Windsurf 上搭建 Loop Engineering用 Cascade Workflows 落地 7 个可复制的 Agent 循环模式在 Windsurf 上搭建 Loop Engineering用 Cascade Workflows 落地 7 个可复制的 Agent 循环模式 本指南聚焦人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务Zed 扩展上手指南3 种安装方式 5 步开发Zed 扩展上手指南3 种安装方式 5 步开发 Zed 扩展系统让你以插件的形式给 Zed 编辑器加装语言支持、主题、命令等新能力无需改动主程序。如果你人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务上一篇SQLFluff 团队落地指南如何高效推行 SQL 代码规范工具下一篇Box2D物理引擎常见问题深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考