别再让你的 AI Agent“裸奔”：4 套 Harness 方案，从失控到驯服的完全指南

引言：当最强的 Claude Code 也开始“绕圈跑”——我学到的三个教训

本文欲回答的核心问题：为什么强大的 AI 编程工具会越跑越偏，甚至越“聪明”越难用？

你有没有过这样的经历？让 Claude Code 改一个模块，它噼里啪啦写了 5 个文件，测试挂了。然后它开始疯狂调试，往代码里塞各种临时补丁、错误日志、废弃方案。到了第 10 个文件，你发现它已经完全分不清哪些是当前任务，哪些是历史噪声——它把之前放弃的方案当成了新指令，开始原地绕圈。

这不是模型不够强。这是 “裸奔”的代价。

我所说的“裸奔”，就是指直接把 Claude Code 扔进你的代码库，不给它任何工程约束。你很快会撞上三堵墙：

  1. 上下文腐烂：任务跑得越长，调试记录越多，它越容易把旧方案当新指令。你看不出来它在绕圈，直到 git diff 爆炸。
  2. 没有强制流程：Plan Mode 只是“建议”，不是“门禁”。它随时可以跳过 spec、测试、Review。你发现的时候，代码已经乱成一锅粥。
  3. 只有写代码的视角：你让它写代码，它就只从写代码的角度往前冲。没人从产品、安全、QA 的角度拦它。结果是：代码能跑，但完全不能用。

这不是模型问题，是工程约束问题。

今天我讲的这 4 套 Agent Harness——Super Powers、GSD、G-Stack、Archon——就是给 AI 这匹野马套上的缰绳。它们不是让 Claude 更聪明，而是把开发流程里缺失的门禁补回来。

一个跨界参照物： 这就像拍《一年一度喜剧大赛》里的素描喜剧（Sketch）。一个好 Sketch 不是靠一个梗撑全场，而是靠“三番”——每番都递进冲突、升级节奏。裸跑的 AI 就像只有一个梗的烂喜剧，前 30 秒好笑，后面全是重复。而 Harness 就是编剧手里的节拍器，强制每一段都有起承转合、情绪起伏。

下面，我们一层一层拆解。

什么是 Harness？——给 AI 这匹野马套上缰绳

本文欲回答的核心问题：Harness 到底是什么？它和我平时用的提示词工程有什么区别？

Harness 这个词本意是“马具”——套在马身上用来控制马的装备。

大模型就像一匹强大的马。如果不加干预，它就会像脱缰野马一样发散思维，产生严重幻觉，最终根本无法稳定输出你要的结果。而用来控制大模型的这套系统，就是 Harness。

用公式表达就是：

Harness = Agent - Model

一个完整的 Agent，减去里面的大模型，剩下的所有东西都是 Harness。

从研究范围看，有三层递进关系：

  • Prompt Engineering：研究怎么问问题。
  • Context Engineering：研究怎么给信息。
  • Harness Engineering：研究怎么搭系统——除了大模型本身不研究，别的什么都研究。

Harness 要管的，就是开头说的那三个坑：上下文腐烂、流程缺失、单一视角。

下面这 4 套方案，不是同一条赛道上的四个选手，而是同一个 Agent 系统里的四层答案：纪律层、上下文层、角色层、编排层。

方案 核心层级 核心机制 一句话定位
Super Powers 纪律层 7 个强制阶段 把“建议”变成“门禁”
GSD 上下文层 原子任务 + 200k 新鲜上下文 给长任务一个干净的房间
G-Stack 角色层 23 个专家角色多视角审查 让 AI 自己“吵架”
Archon 编排层 YAML DAG 工作流 + 可观察性 把流程变成代码

第一层｜Super Powers：把“建议”变成“门禁”（纪律层）

本文欲回答的核心问题：如何用最轻量的方式，让 AI 乖乖按流程走，而不乱跳阶段？

Super Powers 的解法是纪律。

它把工程师的工作习惯拆成 7 个强制阶段：

  1. Brainstorming — 先想清楚要做什么，不急着动代码。
  2. Git Worktrees — 用 worktree 隔离实验，不污染主分支。
  3. Planning — 写 spec 和 PLAN，让人能审。
  4. Execution — 开始写代码。
  5. TDD — 先写测试，再让测试通过（RED-GREEN-REFACTOR）。
  6. Code Review — 自己审一遍，再让 AI 审一遍。
  7. Branch Completion — 确认测试通过，合并分支。

这 7 个阶段是硬约束，不是建议。每个阶段都有对应的 Markdown Skill，Agent 必须按顺序走完。

核心差异： 把“建议”变成“门禁”。Plan Mode 是软约束，Super Powers 是硬流程。

实战案例（来自原文）

我用它写一个数据导出功能。Agent 在 Execution 阶段写完代码后，自动进入 TDD 阶段，发现我没给测试数据，直接停下来问我要 mock data。这在裸跑 Claude Code 里是不可能的——它会直接编一个假数据继续跑。

适用场景

  • 日常任务半小时内搞定
  • 个人开发，不需要重型系统
  • 需要快速上手，成本低回报确定

最大坑

它仍然是 Markdown Skills，本质还是提示词约束。如果模型上下文太长或者指令冲突，还是有可能跳过某个阶段。

作者反思

我当初第一次用 Super Powers 时，觉得“7 个阶段太啰嗦了”。但跑了两次之后发现：正是这种“啰嗦”救了我。有一次我在 Execution 阶段写完代码，Agent 自动进入 TDD，发现测试写错了，停下来让我确认——而不是像以前那样直接提交一个坏掉的版本。

我的判断： Super Powers 是最适合作为第一层基线的选择。不是因为它最强，而是因为它最轻，最容易回滚，最适合作为个人 AI 编程的第一层纪律。

第二层｜GSD：给长任务一个“干净的房间”（上下文层）

本文欲回答的核心问题：为什么任务一跑长（2-3 小时），AI 就开始发疯？怎么解决？

GSD 解决的不是小改动，而是要跑两三个小时、改十几个文件的长任务。

它的核心洞察是：上下文会腐烂。

你让 Agent 重构一个模块，它改了 5 个文件后发现测试挂了，开始调试。调试过程中产生了大量临时代码、错误日志、废弃方案。这些东西会污染上下文，导致第 10 个文件的时候，Agent 已经分不清哪些是当前任务，哪些是历史噪声。

GSD 的解法很直接：每个原子任务都给一个干净的 200k token 上下文。

它把长任务拆成 6 个命令循环：

  1. /gsd-new-project — 创建项目，初始化 artifacts（持久化存储）
  2. /gsd-discuss-phase — 讨论需求，明确目标
  3. /gsd-plan-phase — 拆解任务，写执行计划
  4. /gsd-execute-phase — 执行一个原子任务（新鲜上下文）
  5. /gsd-verify-work — 验证结果，运行测试
  6. /gsd-ship — 确认完成，归档 artifacts

每次执行 /gsd-execute-phase，都会启动一个新的 subagent，给它一个干净的 200k token 上下文。执行完后，把结果写回 artifacts，再进入下一个任务。这样第 50 个任务不会被前面一堆调试噪声污染。

实战案例（来自原文）

我用它重构一个 15 个文件的模块，拆成 8 个 phase。每个 phase 都是新鲜上下文，Agent 不会被前面的调试记录干扰。最后 8 个 phase 全部通过测试，git diff 干净得像手写的。

适用场景

  • 复杂项目，任务跑长（2-3 小时）
  • 有测试资产，能承担 Token 成本
  • 需要跨会话恢复（artifacts 持久化）

代价

拆任务、启动 subagent、写 artifacts 都会增加 Token 成本。它是给长任务买保险，不是每个小需求都需要。

作者反思

我第一次用 GSD 时，觉得“拆任务”这件事本身就是成本。但跑完一个 3 小时的重构后，我算了一笔账：如果没有 GSD，Claude 会在第 2 小时开始绕圈，浪费至少 1 小时 Token 和大量我的时间。GSD 多花的 Token 成本，远低于我手动纠错的时间成本。

一句话总结： GSD 不是让你跑得更快，而是让你跑得不偏。

第三层｜G-Stack：让 AI 自己“吵架”（角色层）

本文欲回答的核心问题：如何避免 AI 往错误的产品方向执行？怎么让它在写代码前先被“挑刺”？

G-Stack 解决的不是技术问题，而是决策问题。

很多 AI 编程失败不是写不出代码，而是非常稳定地往错误方向执行。你让它设计一个用户权限系统，它直接给你写了一个单租户方案——完全没考虑多租户隔离。你让它写一个支付接口，它完全没考虑安全审计。

G-Stack 的核心是 23 个专家角色，覆盖产品、工程、安全、QA、运营等视角。每个角色都有独立的 prompt 和审查标准。

工作流是 7 个阶段：

  1. Think — 用 /office-hours 召集 CEO、PM、工程师讨论需求
  2. Plan — 写方案，用 /plan-ceo-review 让 CEO 审查
  3. Build — 写代码
  4. Review — 用 /qa 让 QA 挑刺
  5. Test — 跑测试
  6. Ship — 部署
  7. Reflect — 用 /cso 让安全官审查风险

每个阶段都可以召唤不同角色。比如 /office-hours 会同时启动 CEO、PM、工程师三个角色，从产品价值、技术可行性、资源投入三个维度挑刺。

实战案例（来自原文）

我用它设计一个用户权限系统，写完方案后用 /plan-ceo-review，CEO 角色直接问我：“这个权限系统是给内部用还是给客户用？如果是给客户用，为什么没有考虑多租户隔离？”我才发现自己根本没想清楚边界。

适用场景

  • 缺团队审查的独立开发者和创始人
  • 产品方向容易摇摆
  • 需要多视角决策（产品、安全、运营）

注意

不要迷信全套 23 个角色。缺什么视角就拆哪个角色来用。缺安全就用 /cso，缺产品思考就用 /office-hours。全套上反而会增加决策成本。

作者反思

我一开始觉得 G-Stack 太“戏多”了——写个代码还要开什么“CEO 评审会”？但跑过一次权限系统之后，我服了。如果没有 CEO 角色的那个追问，我的系统上线后肯定会被客户骂“不能多租户”。这个坑，靠我自己想是想不到的——因为我是技术视角，天然忽略了产品边界。

一句话总结： G-Stack 不是让 AI 更聪明，而是让 AI 不犯低级的产品错误。

第四层｜Archon：把流程变成代码（编排层）

本文欲回答的核心问题：如何让团队批量、重复地使用 AI 流程？怎么把一个人的经验变成团队的模板？

Archon 是四个里面最重，也最像未来形态的。

它把工作流写成 YAML DAG（有向无环图），每一步是节点，节点之间有依赖关系。

一个典型的 Archon 工作流长这样：

workflow:
  - name: analyze_requirements
    agent: analyst
    output: requirements.md
  
  - name: write_code
    agent: developer
    depends_on: [analyze_requirements]
    output: src/
  
  - name: write_tests
    agent: tester
    depends_on: [write_code]
    output: tests/
  
  - name: review
    agent: reviewer
    depends_on: [write_code, write_tests]

每个节点可以并行执行（如果没有依赖），用 git worktree 隔离。比如 write_code 和 write_tests 可以同时跑，互不干扰。执行完后合并回主分支。

Archon 自带 17 个默认工作流，覆盖常见场景：新功能开发、Bug 修复、重构、文档生成等。你也可以自己写 YAML 定义新工作流。

它还提供 Dashboard 观察状态，支持多平台接入（CLI、Web、Slack、Telegram、Discord）。

实战案例（来自原文）

我用它处理 10 个类似的 Bug，每个 Bug 都是“读日志 → 定位问题 → 写测试 → 修复 → 验证”。写一个 YAML 工作流，跑 10 次，每次只改输入参数。省了大量重复沟通成本。

适用场景

  • 团队协作，批量任务
  • 十个 Issue 重复流程
  • 需要规模化（同一个工作流跑 100 次）

代价

安装、维护、模板和节点质量都会成为真实成本。它现在不适合新手第一天全量上。你需要先理解 DAG、git worktree、YAML 配置，才能用好它。

作者反思

Archon 给我的最大冲击是：它把“个人经验”变成了“团队模板”。我以前教新人用 AI 写代码，要口述一堆流程。现在写一个 YAML，新人直接跑。但代价也很明显——调试一个 YAML 工作流的时间，够我手写 3 次代码。所以 Archon 适合规模化的重复场景，不适合一次性探索。

一句话总结： Archon 是给团队用的，不是给个人尝鲜的。

如何选择？先轻后重，四层叠加

本文欲回答的核心问题：面对这 4 套方案，我应该从哪一个开始？还是全都要？

判断一个 Harness 值不值得装，只看它能不能补你当前最痛的工程短板。

最实用的路线是先轻后重：

你的痛点 首选方案 为什么不选更重的
个人日常开发，AI 经常跳过流程 Super Powers 最轻，5 分钟上手，回滚成本低
任务跑长（2-3 小时），开始乱绕圈 GSD 专门解决上下文腐烂，其他方案不治本
产品方向摇摆，总写出不能用的方案 G-Stack（按需拆角色） 只取你缺的视角，别全套上
团队批量任务，10 个 Issue 重复流程 Archon 重，但规模化后省时间

把时间拉长，最后不是四派互斥，而是四层叠加：

  • 底层是纪律层（Super Powers），让 Agent 不乱来。
  • 第二层是上下文层（GSD），让长任务不腐烂。
  • 第三层是角色层（G-Stack），让视角不单一。
  • 最上面是编排层（Archon），让团队把流程标准化。

但顺序很重要——别第一天就追全家桶。先上 Super Powers 跑一周，发现长任务出问题了再加 GSD，发现产品决策摇摆了再加 G-Stack 的某个角色，团队规模大了再考虑 Archon。

我的最终反思：AI 编程的核心不是模型，是工程

本文欲回答的核心问题：折腾这么多 Harness，是不是过度工程？我能不能就靠一个聪明的模型解决问题？

我花了很多时间测试这四套方案。一个让我难受的真相是：模型的智商在飞速提升，但我的工程约束却永远在补漏。

每次 Claude 出新品，我都幻想“这次可能不需要 Harness 了”。结果呢？它写代码更快了，但绕圈也更快了。上下文窗口变大了，但腐烂的信息也更多了。

这不是模型的问题。这是任何智能系统都逃不掉的工程定律：没有约束的自由，就是混乱。

Super Powers 的 7 个阶段，GSD 的干净上下文，G-Stack 的多角色吵架，Archon 的 YAML 流程——它们不是在限制 AI，而是在把人类工程实践里已经验证过的门禁，翻译成 AI 能执行的语言。

你现在最缺的是纪律、上下文、角色审查，还是流程编排？

我的建议是：从最痛的那一个开始，但别停在只用一个。因为你的任务会变长，你的产品会变复杂，你的团队会变大。四层叠加，才是终点。

实用摘要 / 操作清单

如果你只有 5 分钟，记住这 5 点：

  1. Harness = Agent – Model，它是控制大模型的所有工程约束系统。
  2. Super Powers 适合个人日常开发，7 个强制阶段把“建议”变“门禁”。
  3. GSD 适合长任务，每个原子任务给 200k 新鲜上下文，解决上下文腐烂。
  4. G-Stack 适合产品方向摇摆，用多角色审查（CEO/PM/QA/安全官）拦错误决策。
  5. Archon 适合团队批量任务，用 YAML DAG 定义可复用工作流。

操作路线图：

  • 第 1 周：安装 Super Powers，跑 3 个日常任务，观察是否跳过流程。
  • 第 2 周：如果任务经常超过 1 小时，加装 GSD，把长任务拆成 phase。
  • 第 3 周：如果方案经常被产品/安全打回，拆 G-Stack 的 /office-hours 或 /cso 角色。
  • 第 4 周：如果团队有 10+ 个重复 Issue，试用 Archon 写第一个 YAML 工作流。

一页速览（One-page Summary）

问题 方案 核心机制 一句话
AI 跳过流程，直接写代码 Super Powers 7 个强制阶段 把“建议”变“门禁”
长任务上下文腐烂，乱绕圈 GSD 原子任务 + 200k 新鲜上下文 给每个任务一个干净的房间
产品方向摇摆，决策错误 G-Stack 23 个专家角色多视角审查 让 AI 自己“吵架”
团队重复流程，规模化困难 Archon YAML DAG 工作流 + 可观察性 把流程变成代码

选择公式：

  • 个人 + 短任务 → Super Powers
  • 个人 + 长任务 → Super Powers + GSD
  • 个人 + 方向摇摆 → 上面 + G-Stack（按需拆角色）
  • 团队 + 批量 → 上面 + Archon

常见问答（FAQ）

Q1：我能不能只用其中一个，跳过其他的？

能。但前提是你当前的问题刚好被它覆盖。如果任务变长了，你还是要加 GSD。四层不是必装，是按需叠加。

Q2：Super Powers 的 7 个阶段会不会太慢？

不会。它强制你停下来想清楚，反而节省了你后面改 bug 的时间。如果任务真的非常小（改一行配置），你可以在 Brainstorming 阶段快速确认，跳过细节。

Q3：GSD 的 token 成本大概会增加多少？

取决于任务长度和 phase 拆分的粒度。原文里重构 15 个文件、8 个 phase 的案例，token 成本大约是裸跑的 1.5 倍。但节省了至少 1 小时手动纠错时间——性价比很高。

Q4：G-Stack 的 23 个角色我都要装吗？

千万不要。只装你缺的视角。缺安全就装 /cso，缺产品思考就装 /office-hours。装太多反而增加决策噪音。

Q5：Archon 需要懂 DAG 和 YAML 到什么程度？

基础程度就够了。知道 depends_on 怎么用，知道怎么定义节点输出。原文的例子就是最常用的模式。不要一开始就写复杂 DAG。

Q6：这些 Harness 会不会被新模型淘汰？

不会。因为模型越强，越需要工程约束。就像 F1 赛车越快，越需要刹车和安全带。Harness 不是模型的补丁，而是工程系统的基础设施。

Q7：我能不能自己组合不同方案的部分功能？

能。原文的四层叠加本就是推荐组合方式。比如你可以用 Super Powers 的 7 个阶段，但在长任务里用 GSD 的 phase 拆分，再用 G-Stack 的 /cso 做安全审查。

Q8：哪个方案最适合新手第一天上手？

Super Powers。因为它最轻，5 分钟配好，风险最低。跑一周后再决定要不要加别的。