模型更强以后，还需要重型 Agent Harness 吗？

从 Superpowers 到 Matt Pocock Skills：Coding Agent 的工程控制应该放在哪里

让 Coding Agent “直接把这个功能做完”，通常只需要一句话。问题是，它同样可以用一句话决定你没有说出口的边界：谁能操作、失败后怎么办、什么叫完成、测试要从哪里验证。代码很快出现，误解也很快固化。

我后来发现，Agent 交付失控时，缺的往往不是更长的上下文或更复杂的 prompt，而是几个不能省略的工程停顿：需求是否真的对齐？项目里同一个词是否指向同一个领域概念？能否在一个公共边界构造会变红的反馈？改动是否既遵循项目约定，也完成了原始需求？

这也是我日常使用 Matt Pocock engineering skills 的原因。它们不是一套“让模型突然变聪明”的提示词，而是把这些停顿拆成可以重复调用的工程动作：先追问和沉淀术语，再把讨论固化为规格和垂直切片，随后在约定的测试 seam 上实现，最后把“写得是否规范”和“做得是否正确”分开复核。作者对这套 Skill 的定位也很明确：小、易改、可组合，而不是一个接管整个过程的万能框架。¹

但最近还有一种更激进的说法：随着模型能力上升，那些设计很重的 Agent Harness 已经没有必要，甚至正在被淘汰。这个判断抓住了一部分真实变化，却容易把三个不同层次的东西混为一谈：一个 Skill、一个由多个 Skill 组成的 Workflow，以及让 Workflow 跨会话和跨系统运行的 Harness。

本文想讨论的不是“Matt Pocock Skills 和 Superpowers 谁更先进”，而是工程控制究竟应该放在哪里。我的结论是：模型能力提升正在压缩“由外部框架替模型规定每个推理步骤”的必要性，但没有淘汰工程控制。更合理的分层是：模型处理即时推理，Skill 保存可读、可替换的工程纪律，Workflow 显式组织状态和交接；需要跨会话、跨系统的持久自动化时，再让 Harness 承担运行时责任。

先对齐层次：Skill、Workflow 与 Harness

这场讨论最容易混乱的地方，是把三个不同的层次放进同一个比较维度。

把 Matt Pocock Skills 称为“轻”，很容易被理解成每个文件都短、每一步都少。事实并不是这样。它的 implement skill 只有很短的编排说明：尽量在预先约定的 seam 上用 TDD，持续运行类型检查和测试，结束后进行 code review，再提交当前分支。² 这份文件之所以短，是因为测试和评审被委托给独立 skill；遇到复杂 Bug 时，diagnosing-bugs 又会要求先建立一个真实、可重复、能变红的反馈回路。轻的不是工程纪律本身，而是没有一个总控流程替工程师决定所有下一步。

所以，Matt Skills 与 Superpowers 应被放在 Skill Workflow 这一层比较；Harness 不是它们的直接竞品，而是当 Workflow 需要持久运行时才出现的下一层能力。这个区分决定了后面所有取舍：你可以换掉某个 Skill，也可以换掉 Workflow 的路由规则，却仍然保留同一个可靠运行时。

Matt Skills 解决的，不是“模型不会写代码”

Matt 的 engineering skills 把几个最常见、也最容易被“代码已经生成了”掩盖的失控点，变成了可调用的工程停顿。

第一是模糊需求被过早实现。grill-me、to-spec 让人先把目标、约束、验收方式和非目标写下来；Agent 不再把含糊的一句话直接翻译成实现细节。第二是项目语言没有共享语义。setup-matt-pocock-skills 为 issue、标签和领域文档建立入口，规格和 ticket 再把讨论中的词落到当前仓库可追踪的产物上。⁴

第三是实现没有有效反馈。TDD 和诊断 skill 共同要求先找到一个公共、可复现的 seam；这会迫使“看起来能跑”的改动接受可变红、可回归的验证。第四是完成定义被混在一起。独立的 code review 会分别核查项目标准与原始 spec，而非只问代码是否优雅或测试是否为绿。⁹

这些 Skill 的价值不在于替代架构师、产品或 reviewer，而在于给 Agent 的高速输出插入可检查的边界。它们把“继续做”拆成一系列可以说清楚何时开始、何时失败、何时应该停下的动作。这也是短文本 Skill 能承载工程纪律的原因：它依赖的是清晰的输入输出和相互制约，而不是在一个超长提示词里重复所有规则。

与 Superpowers 的差异：同层 Workflow，控制权不同

Superpowers 选择了另一种控制方式。它将自己定义为一套完整的软件开发方法论：需求澄清之后创建隔离 worktree，形成包含验证步骤的实施计划，再由子 Agent 或批量执行流程推进，期间强制 TDD、评审和分支收尾。它还明确要求 Agent 在每项任务前检查相关 Skill，工作流不是“建议”。³

因此，差别不是“一个有流程、一个没有流程”，而是流程控制权的分配。Matt 将链路拆成可按需组合的动作：需求已清楚时，可以直接从 to-spec 或 ticket 开始；遇到复杂排障时，可以只调用诊断循环。Superpowers 则用一个默认链路换取更少的漏步骤和更一致的执行。两者都在约束 Agent，只是一个把编排暴露给使用者，一个把编排预先写进系统。

我倾向于把它们看成两种合理的 Workflow 策略，而不是“轻量 Skill 对阵重型 Harness”。前者适合把现有工程习惯逐步显式化，后者适合先把一套成熟方法论整体装进项目。真正的风险只在于不加审视地复制其中任何一套流程，把它误认为对所有代码库都成立。

模型更强了，重型 Harness 就被淘汰了吗？

“重型 Harness 已被淘汰”是社区里很有吸引力的叙事，但目前最多只能算一种趋势判断，不能当作事实结论。它反映的真实变化是：模型对代码库探索、局部规划和工具调用的能力提升后，过去为了让弱模型按固定步骤走完任务而堆出的编排，收益确实在下降。一个过于僵硬的总控层，可能把本该用于理解问题的上下文和 token 花在确认流程本身。

但两个项目的增长至少说明需求尚未消失。2026 年 7 月底的公开快照中，Matt Pocock Skills 的 Star History 约为 19.5 万星，Superpowers 的 GitHub API 快照约为 26.4 万星；前者在 2026 年 2 月创建后增长很快。¹⁰ Star 只能反映关注度，不能证明效果，更不能据此判定哪种方案会胜出；它能说明的只是，显式工程方法和完整工作流仍同时被大量尝试。

更严谨的证据也不支持“Skill 一定有效”或“框架一定过时”的二分法。SWE-Skills-Bench 的预印本在 49 个评测中有 39 个没有观察到通过率提升，平均增益很小，而某些配置的 token 开销大幅增加。它考察的是特定 benchmark 和 Skill 配置，不足以外推到每个真实项目，却恰好提醒我们：Skill 的价值取决于任务、模型和流程是否匹配。另一方面，关于 Agent 工程的公开实践仍强调：单 Agent 可以很薄，多 Agent、长链路和外部操作会迅速变厚，需要状态、可观测性和治理。¹¹

因此，更准确的判断是：模型能力在淘汰那些只会替模型思考、却不保存工程事实的“伪控制”；它没有淘汰状态、权限、恢复、审计和交付证据。当一次工作跨越多个会话、多人协作、CI/CD 或生产环境时，缺少这些责任的系统并不会因为模型更聪明而自动可靠。

这套 Skills 的三个现实摩擦

把 Skills 放进日常项目后，我遇到的不是“它不够严格”，而是三个更具体的摩擦：在不知道概念时不断提问、把工作拆得足够细以后成本反而失控，以及通用工程动作面对项目私有知识时仍会产生错误的心智模型。这些问题都不应靠再加一段更长的 prompt 解决。

先查证，再 grill

grill-me 的强项是把尚未决定的设计分支一条条摊开。但当某个概念连 Agent 和我都说不清时，追问会变成猜谜：Agent 继续问，我继续补充，问题并没有靠近一个可验证的事实。grilling 的原始规则其实已经给出方向：能通过环境、文件系统或工具找到的事实，先去找，而不是问用户。⁶

我会在 grill 前增加一个 research gate。它先将请求分成“可检索事实”和“必须由人决定的权衡”：前者先查代码、issue、已有项目文档；涉及内部基架、历史决策或团队规范时，在有明确权限和检索目标的前提下，可用 Citadel 查询内部资料。每条结论都必须带来源；查不到就标为未知，不让模型用流畅的语言填空。随后生成一张 evidence brief：已证实事实、未知事实、术语冲突、待人决策以及本轮问题预算。只有最后一栏进入 grill-me。

这也是我在实际使用中反复遇到的摩擦：当项目事实尚未查清时，连续追问不会缩小不确定性，反而把本可由工具完成的检索工作转交给人。GitHub 上的相关讨论只能说明，也有使用者希望在追问前增加文档、网页或证据探索；它们不是这一现象普遍性的统计证明。⁷ 因此，我的改造不是减少澄清，而是先区分事实与决策：只有无法从已有证据推导的权衡，才值得占用人的问题预算。

垂直切片有成本，不能只追求更细

to-tickets 要求 ticket 能在一个 fresh context 中完成，是为了让每个切片可以独立验证。可在实际项目中，ticket 数量增多、依赖串成一条链后，每张票都要重新载入上下文、实施、跑 TDD、review 和回写状态；总成本会被固定开销和关键路径放大。这里的风险不是 TDD 本身，而是把“一个公共 seam 上的一次行为验证”误拆成许多没有独立交付价值的微任务。

因此，我会在 tickets 发布前要求一份 cost forecast：总 ticket 数、依赖 DAG、关键路径、可并行 frontier、每张的验证级别、预计的新会话次数和共享模块冲突风险。不能独立 demo 或验证的切片应该合并；只在依赖、工作区和模块边界都安全时并行。这样，垂直切片仍然服务于反馈，而不会变成把一次简单变更切成一长串串行仪式。⁵

Setup 不是项目认知

setup-matt-pocock-skills 很有必要，但它解决的是“这些 Skill 到哪里找 issue、标签和领域文档”，不是“Agent 是否已经理解这个项目”。GitHub 的设计讨论也把 setup 定义为 repo 特定配置，并承认缺失配置不会被自动验证或阻止；另一个关于整体 flow 的 issue 中，使用者直接提出 PRD 不含架构总览和主流程的问题。⁸

我的补法不是再写一份无边界的大文档，而是按项目维护一个 Project Context Pack：入口与验证规则、领域词汇、模块/数据流/测试 seam、技术栈与版本约束、命名约定，以及内部基架资料的检索入口。进入 /implement 前，router 根据 ticket 的影响范围选出必读资料，并在 handoff 中写明已读来源、已确认约束和未决项。文档要有 owner、适用范围和随架构变化更新的触发条件；否则它只会成为另一种更可信、也更危险的陈旧上下文。

从 Skill 集合到 Workflow，缺的是“下一步”的契约

这一区别不是抽象讨论，而是我在实际使用中的停顿。完成 setup-matt-pocock-skills 后，仓库有了 issue tracker、领域文档和 ticket 约定；用 grill-me 或需要领域文档的 grill-with-docs 澄清完需求后，流程并不会自己推进。我仍要判断讨论是否足够，然后显式输入 /to-spec，确认 spec 后再输入 /to-tickets。这些本来就是 user-invoked skill：它们有意把“是否该做下一步”的判断留给开发者。⁴

接下来的人工作业更多。我要追踪每张 ticket 的 blocker，找出现在能开始的 frontier；为每张可开始的 ticket 新开一个上下文，再把 ticket、已有决策和约束交给 /implement。Matt 的 to-tickets 已经要求 ticket 是可以在一个 fresh context 完成、且能独立验证的垂直切片。⁵ 但“在哪个会话开始”“新会话应该带上什么”“前一张 ticket 的什么证据足以解除 blocker”，并没有成为一条被统一执行的交接契约。

这不是 Matt Skills 的缺陷，而是它的设计选择：它提供高质量的动作，却不假定所有项目都应由同一个总流程驱动。对熟悉项目、愿意自行编排的工程师，这种自由正是优势。问题只在于：一旦我希望同一套流程被反复执行，或由多人、多会话稳定接力，就不能只依赖“下一条提示词应该是什么”的记忆。

把这套 Skill 固化为 Workflow，需要补什么

首先要补的不是新的 prompt，而是一份 Run 状态机：setup、clarified、spec-approved、tickets-approved、ready、implementing、reviewing、accepted 和 blocked 分别意味着什么，进入与退出需要什么证据，哪些转换必须由人批准。

其次是 产物和交接契约。一个 run 应将需求讨论摘要、spec、ticket、分支、commit、测试报告和 review 结果关联起来。每个新会话拿到的不是一句“继续 ticket 03”，而是一份 handoff：目标与范围、已确认的 seam、未决决策、代码基线、工作区状态、验证命令及其实际结果。这样，fresh context 才是隔离噪声，而不是遗失上下文。

第三是 frontier 调度和状态回写。Workflow 根据 blocker 计算 ready ticket，并为其创建或复用新会话；ticket 只有在验收证据通过后才解除后继任务的阻塞。实现失败、review 发现问题或外部操作不确定时，run 要进入可见的 blocked 或可重试状态，而不是让人再发一句模糊的“继续”。

到这一步，才有必要讨论 Harness。它不是与 Skill 对立的东西，而是这份 Workflow 需要跨会话、跨 Agent 或触发外部操作时的运行时载体：持久化状态，保证幂等，记录 action 与结果，提供恢复入口。CI/CD、部署审批、灰度、回滚和线上读回也应作为这个开发闭环之后的扩展阶段接入，而不是假装 implement 已经自动覆盖了它们。

结语：把控制放在真正需要承担责任的地方

我会继续使用 Matt Skills，不是因为它证明了 Workflow 或 Harness 不再重要，而是因为它把工程动作拆得足够清楚：我可以只修正需求澄清、只加强测试反馈，或者只替换 ticket 的拆分规则，而不用先接受一台无处不在的总控机器。

但使用到 setup -> grill -> to-spec -> to-tickets -> implement 时，短板也同样清楚：事实检索、阶段准入、ticket frontier、跨会话 handoff、失败恢复和交付回写，仍要由人手动记住并推动。要把这组 Skills 升级为一条稳定的 Workflow，最小闭环应当是：

research gate -> 受预算约束的澄清 -> spec 审批 -> 带成本预测的 tickets -> frontier 调度 -> Project Context Pack 准入 -> 实现/测试/review -> 验收证据 -> 状态回写

其中每一箭头都要能回答三个问题：谁可以推进、推进前缺什么证据、失败后回到哪里。只有当这条链真的需要跨会话、跨 Agent 或接入外部系统时，才值得引入 Harness 去持久化和调度它。

这比“所有人都应该用重框架”或“模型强了就不需要框架”更朴素：让模型负责当下的推理，让 Skill 负责工程纪律，让 Workflow 负责交接与决策，让 Harness 只承担运行时必须承担的责任。控制不该消失，它应该回到能被审查、替换和证明的位置。