人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载本文围绕 19-when-to-scrap-and-start-over.md 展开系统讲解编码 AgentCoding Agent在自主长时任务中如何判定当前方案是否该被推倒重来以及如何通过接口契约、测试套件与 git worktree 隔离让重写的成本趋近于零。你将掌握四大失效信号的具体形态、一次聚焦 LLM 重新评估调用的完整触发方式以及 Gemini沉没成本启发式与 Grok并行实验两种跨模型方法论在 GSD-2 项目中的真实落地路径。一、为什么推倒重来必须被制度化为可执行协议长期自主运行的编码 Agent 面临一个根本矛盾做得越久沉没成本越高越不愿意承认当前架构走错了方向。当复杂度开始滚雪球时Agent 的自然倾向是继续叠加补丁而不是止损并重建。GSD-2 的研究文档将这一难题拆解为三个可操作的部分如何尽早识别需要推倒重来的信号而不是等架构崩溃如何评估当前方案是否真的不可挽回而不是凭直觉放弃如何让重写本身足够便宜使推倒重来从高风险赌博变成低成本常规操作。其中第三点正是 GSD-2 的架构核心。项目通过 ADR-001 分支无关 worktree 架构 与其后续演进把每个主要方案放在一个可随时丢弃的分支上从理念变成了默认实现——这为本文讨论的Scrap and Start Over提供了工程基础。二、四大信号跨模型共识何时判定当前方案失效原文档给出的核心成果是Four Signals这是多个前沿模型在交叉验证后收敛出的共识——以下任一信号的持续出现都意味着复杂度正在累积而非被解决。信号具体表现迭代次数呈上升趋势任务 13 次迭代任务 25 次任务 38 次。复杂度在叠加而不是在收敛。测试闪断flakiness增加之前通过的测试开始间歇性失败——隐藏耦合正在被拉紧。同一文件被反复修改每个任务都触碰同一个核心模块——上帝对象吸收了过多职责。验收标准开始需要例外出现除 X 场景外都能工作或忽略测试 Y 就能通过——Agent 正在与验收标准讨价还价。2.1 信号一迭代次数上升趋势这是最直观也最容易量化的信号。正常收敛的任务迭代次数应当持平或下降而当连续多个任务的迭代次数单调上升3 → 5 → 8说明每次新增需求都在撬动更多既有代码Agent 的每次尝试都在制造新的修复点。GSD-2 的自主循环恰好内置了这类迭代观测能力在 auto-mode.md 中auto 循环通过.gsd/journal/记录unit-start、unit-end、iteration-end等事件每次迭代结束都会留下可追溯的失败类与原因字段——这些正是计算迭代次数趋势的第一手数据源。2.2 信号二测试闪断增加测试从稳定绿变成间歇红通常不是测试本身的问题而是被测模块之间的隐式依赖正在被改动撑裂。闪断的本质是隐藏耦合被拉紧某个模块的副作用经由非契约路径泄漏到另一个模块的测试环境。该信号在 GSD-2 中同样有对应的制度性响应artifact-verification-retry这类可归因的重试被明确记录而无法自证的闪断会被滑动窗口检测器捕获详见第五节的 stuck-loop 机制。2.3 信号三同一文件被反复修改如果每个任务都必然触碰同一个核心模块说明该模块承担了过多职责——典型的上帝对象god object反模式。反复修改该文件 每次改动都在同一片泥潭里打转边际成本持续上升。GSD-2 的 长期重构计划2026-05-03 中把这类复杂度热点作为重构的首要对象并主张复杂度热点应被显式拆分而不是继续吸收职责——这正是对上帝对象信号的正向回应。2.4 信号四验收标准出现例外当 Agent 开始用除 X 外都能工作、忽略测试 Y 就能通过来修饰交付结果时它实际上正在与验收标准谈判——降低标准以适配一个结构上错误的实现。这是最危险的信号因为它意味着 Agent 的自我评估已经失真。原文档的处置建议是此类措辞一旦出现在任务摘要中就应视为需要触发重新评估协议见第三节。值得注意单一信号出现一次不足以判定方案失效四个信号是趋势指标判断依据是持续性而非偶发性。三、重新评估协议The Reassessment Protocol当上述信号的阈值被跨越时原文档规定了一个明确的触发动作发起一次聚焦的 LLM 调用focused LLM call而不是让 Agent 继续埋头修补。该调用的输入必须是结构化的共四类材料manifest当前方案的清单/契约清单原始 spec最初的规格说明用于对照我们到底要解决什么任务摘要已执行任务的汇总用于呈现实际进展信号数据四大信号的量化证据用于呈现失败模式。对应的提示词模板原文如下Is the current approach viable or would a different architecture serve better? If different, what and why?当前方案是否可行抑或不同的架构能做得更好若需改变是什么、为什么这一协议的价值在于三点成本受控它是一次调用不是无限次自我怀疑循环视角切换输入包含原始 spec迫使评估回归最初目标而不是被当前实现细节绑架可审计评估的输入输出都有记录后续可回溯为什么做出重写决策。从 GSD-2 的实际机制看类似的聚焦评估调用已有雏形在 auto-mode.md 中GSD 检测到 stuck loop 后会retry once with a deep diagnostic prompt以深度诊断提示重试一次——失败后再次失败才停止。这套重试一次深度诊断的节奏与重新评估协议一次聚焦调用定生死的思路高度一致区别在于前者面向单次循环卡死后者面向整个架构方向。四、关键架构使能器让重写变得便宜Make Rewrites Cheap这是原文档中最重要的工程结论推倒重来的决策是否正确取决于重写的成本是否足够低。如果一次重写意味着数小时的迁移与回归风险那么即使信号已经亮起理性的 Agent 也会选择继续打补丁——这正是沉没成本陷阱的根源。原文档给出了四条使重写变便宜的原则清晰的接口契约 良好的测试套件→ 重写内部实现而保留接口风险极低测试用同一套验收标准验证新旧实现→ 重写不改变行为期望接口契约保证下游不被破坏→ 调用方无需感知内部被替换每个主要方案都放在一个分支上→ 可随时丢弃而不影响其他任何部分。4.1 GSD-2 的落地分支无关的 worktree 架构最后一条原则在 GSD-2 中被贯彻得最为彻底。项目的 ADR-001 分支无关 worktree 架构 及其 PRD 描述了一次典型的重写决策旧的slice-branch-per-slice模型产生了 770 行合并/冲突/自愈代码、15 次 bug 修复最终被判定为架构性问题无法通过修补解决——这正是本文讨论的Scrap and Start Over在真实项目中的完整案例。重写的目标架构极其简洁main ──────────────────────────────────────────── main │ ↑ └─ worktree (milestone/M001) │ │ │ commit: feat(M001): context roadmap │ commit: feat(M001/S01): research │ commit: feat(M001/S01/T01): implement │ commit: feat(M001): milestone complete │ │ │ └──────────── squash merge ─────────────────┘worktree 隔离每个活跃里程碑一个独立 worktree.gsd/worktrees/MID/文件系统级隔离单一分支顺序提交worktree 内只有一个milestone/MID分支不存在分支切换squash merge里程碑完成时一次性 squash 合并回main。从源码看worktree 的创建、解析与回收由 src/resources/extensions/gsd/worktree-manager.ts 负责其注释明确写着创建git worktree add .gsd/worktrees/name -b worktree/name完成后git worktree remove 分支清理。这套机制让跑一个实验性方案、看效果、不行就整体丢弃的成本降到了接近一次git worktree remove的水平。4.2 接口契约GSD-2 重构的安全内胆重写内部而保留接口在 GSD-2 的长期重构中体现为契约包优先策略。2026-05-03 的 重构计划 中Phase 1A建立packages/contractsgsd-build/contracts把 RPC 命令/事件/响应信封、会话状态、bash 结果、UI 载荷统一为规范契约runtime 与 rpc-client 都从同一契约包导入并用 golden JSONL fixtures 锁定行为Phase 5DB 拆分时明确保持单写入者不变式single-writer invariant将gsd-db.ts保留为兼容门面内部按仓库拆分导出名不破坏既有调用方。这两步的本质都是契约在外、实现在内重写实现不动契约。测试则通过用同一套验收标准验证新旧实现来兜底——契约 fixtures 与 prompt golden fixtures 一旦回归即阻断合并。五、跨模型方法论一Gemini 的沉没成本启发式Gemini 对何时止损给出了可量化的两个阈值统称Sunk-Cost Heuristic其核心是持续监控一个指标任务重入率Task Re-entry Rate。触发白板会议Whiteboard Session的条件有两个满足其一即触发触发条件含义同一组 3 个测试被尝试超过 5 次反复在同一批测试上失败说明修复方向本身可能错误重构-特性比refactor-to-feature ratio超过 4:1为交付一个特性所付出的重构工作量超过特性本身 4 倍投入产出严重失衡白板会议即回到第三节的重新评估协议把信号数据打包做一次聚焦评估而非继续执行第 6 次尝试。GSD-2 的自主循环为这套启发式提供了天然的检测基建。在 auto-mode.md 中滑动窗口 stuck-loop 检测不是简单的同一单位派发两次计数而是分析近期派发历史中的重复模式可捕获A→B→A→B这类循环。检测到后先以深度诊断提示重试一次再次失败才停止同单位连续派发上限complete-milestone、validate-milestone、research-slice允许同一阶段连续派发两次第三次触发 repeat-cap 警告并停止产物验证重试上限每个单位完成后验证预期产物artifact是否存在缺失则带失败上下文重派上限 3 次仍缺失则暂停 auto 模式并报Artifact still missing...。这些上限本质上是把 Gemini 的重试 N 次即止损阈值制度化——只不过 GSD-2 将其落在了派发与产物验证层面而文档将同样的逻辑推广到测试尝试与重构投入层面。二者的互补关系是项目层面的启发式决定是否重写整个方案循环层面的上限决定是否继续尝试当前补丁。六、跨模型方法论二Grok 的并行实验Parallel ExperimentationGrok 的方法论补上了 Gemini 启发式缺失的一环仅仅判定该重写了还不够还要避免把整条主路堵死去赌一个未经证实的方案。Grok 的做法是并行实验创建一个Rewrite Branch 子图独立的实验分支/工作区在干净起点上用同一个愿景跑一条垂直切片one vertical slice即挑选一个代表性功能完整地在新架构上实现一遍对比新旧方案的指标测试通过率、迭代次数、代码复杂度等只有指标优于原方案才合并否则整个实验被丢弃。其成本分析是因为实验与主线并行运行且失败即丢弃所以成本近乎为零near-zero——真正昂贵的只有让实验污染主线。这一理念在 GSD-2 中有两处直接呼应并行里程碑编排。parallel-orchestrator.ts见 src/resources/extensions/gsd/parallel-orchestrator.ts为每个里程碑创建独立 worktree 并派生独立 worker 进程多个里程碑可同时运行由项目根目录的 SQLite/WAL 运行时协调心跳、租约与派发归属。虽然当前主要用于独立里程碑并行而非同一方案的竞争性对比但其每个实验在独立 worktree 中运行、互不污染的隔离模型正是 Rewrite Branch 所需的执行容器。milestone 内 reassess。GSD-2 在里程碑推进中内置了 reassess 机制源码与测试见 src/resources/extensions/gsd/tests/reassess-detection.test.ts在完成每个切片后重新评估路线图——这与跑完一条垂直切片再对比、再决定是否继续的节奏同构。值得强调的边界是Grok 的成本近乎为零有一个隐含前提——必须有独立、可丢弃、可并行的执行环境。如果没有 worktree/branch 级隔离并行实验就会变成主线污染。因此第四节的架构使能器是本节方法论成立的前提。七、为你的 Agent 落地这套机制的实操清单综合原文档与 GSD-2 的实践将Scrap and Start Over制度化需要五个步骤建立信号数据源在 Agent 的循环中记录每个任务的迭代次数、测试闪断率、被修改文件清单、验收标准措辞。GSD-2 的做法可参考journal 事件unit-start/unit-end/iteration-end逐条记录事后可用/gsd forensics做异常定位与相关性分析见 auto-mode.md。设定量化阈值把四大信号翻译成可执行规则。可借鉴的阈值包括任务重入率同一组测试尝试 5 次、重构-特性比4:1、同单位连续派发上限3 次、产物验证重试上限3 次。预留聚焦评估调用确认触发后仅做一次 LLM 调用输入为 manifest 原始 spec 任务摘要 信号数据提示词采用原文档模板见第三节输出要么继续要么给出替代架构及理由。让重写便宜这是前置工程投入包括①接口契约层保证下游不感知内部替换GSD-2 的packages/contracts是现成范例②同一套验收标准的测试套件③分支/worktree 级隔离每个主要方案独立分支GSD-2 的worktree-manager.ts管理整个生命周期。允许并行验证新架构不直接替换主线而是先在独立 worktree 中跑一条垂直切片指标优于原方案才合并——否则丢弃实验分支成本仅是一次 worktree 清理。需要说明的适用前提本文的阈值与机制源自 GSD-2 的自主编码循环设计其他项目落地时应按自身任务规模调整具体数字但信号 → 聚焦评估 → 低成本重写 → 并行验证的链路本身是可迁移的方法论骨架。八、结语把放弃变成一等公民能力GSD-2 的经验表明何时推倒重来不是一个哲学问题而是一组可观测信号、一次受控评估调用和一套低成本重写基建的组合。从 ADR-001 放弃 slice-branch 模型到 2026-05-03 重构计划 中按契约包、workflow kernel、DB 拆分顺序逐步重写GSD-2 反复实践着重写内部、保留接口、测试把关、分支兜底的范式。对任何希望 Agent 长期自主运行的团队而言值得复制的不是某条阈值而是这套让决策可量化、评估受控、重写可逆的完整机制。延伸阅读本系列文档入口见 docs/dev/building-coding-agents/README.md与本文最相关的邻篇包括 15-legacy-code-brownfield-onboarding.md遗留代码接管与 17-irreversible-operations-safety-architecture.md不可逆操作安全。赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐WinFsp代码重构重构风险评估与规避WinFsp代码重构重构风险评估与规避 1. 引言 在软件开发过程中代码重构是一项至关重要的活动它旨在改进代码质量、提高可维护性和可扩展性同时不改变软件存储驱动开发JTAppleCalendar代码重构度量评估重构效果的指标JTAppleCalendar代码重构度量评估重构效果的指标 重构指标体系构建 代码重构效果评估需建立多维度度量体系结合静态代码分析与动态行为验证。JTAp移动开发UI组件从0到10brpc协议栈如何支撑多协议通信架构从0到10brpc协议栈如何支撑多协议通信架构 你是否遇到过服务端需要同时处理HTTP、Redis、Thrift等多种协议的场景是否为不同协议需要独立部RPC框架后端微服务网络通信上一篇Semi Design 与 TailwindCSS 集成实战CSS Layer 优先级治理与 Design Token 原子化下一篇Video2X解决方案用AI技术实现视频无损放大与帧率提升创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考