背景与约束分析

原文文章核心观点提取

文章背景

Jason Zuo 在 X 平台分享的技术分析文章（发布于 2026 年 3 月 29 日）深入对比了当前 AI Agent 开发领域的三种主流工具：gstack、Superpowers 和 Compound Engineering (CE)。作者的核心论点是：CE 比拥有 120k stars 的 Superpowers 更具架构深度，尤其是其独有的知识积累机制。

文章的关键洞察在于：不是简单对比功能列表，而是引入 Anthropic 官方 Harness 架构框架作为评价基准，从”如何让 agent 跨多个 context window 持续工作”的角度审视各工具的优劣。

Anthropic Harness 架构框架

Anthropic 在 2025 年 11 月和 2026 年 3 月发布的两篇工程博客中，提出了让 Agent 持续工作的核心架构——Harness，包含四个关键角色：

flowchart TD
    A[用户任务] --> B[Planner Agent]
    B --> C[Task List]
    C --> D[Coding Agent]
    D --> E[Feature 1]
    D --> F[Feature 2]
    D --> G[Feature N]
    E --> H[结构化笔记]
    F --> H
    G --> H
    H --> I[Evaluator Agent]
    I --> J{审查通过?}
    J -->|否| D
    J -->|是| K[Progress File]
    K --> L[跨 Session 桥接]
    L --> M[Session B 继续]
    
    style I fill:#f96
    style K fill:#9f6

四个核心角色详解：

1. Planner Agent：将大任务拆分成可执行的 feature list，是决策中枢
2. Coding Agent：每次只执行一个 feature，完成后留下结构化笔记
3. Evaluator Agent：独立审查代码，不让 builder 评价自己的工作（避免过度乐观偏差）
4. 跨 Session 桥接：通过 progress file 传递上下文，实现 session 间连续性

2026 年 3 月的更新引入了 Generator-Evaluator 分离原则：Agent 评价自己的工作会过度乐观（over-optimism bias），因此将”做事的”和”评价的”分成两个独立 agent，效果显著提升。Anthropic 用这套架构让 agent 自主开发了一个完整的项目，包含 200 多个可验证的 feature。

三种工具在 Harness 框架下的定位

gstack：决策层 + 测试层的最佳实践

gstack 由 YC CEO 开发，其哲学是 “Boil the Lake”——AI 时代做完整的事边际成本趋近于零，永远做完整版。

在 Harness 框架下，gstack 覆盖了：

• Planner 角色：/plan-ceo-review（产品视角）和 /plan-eng-review（架构视角）
• Evaluator 角色：/qa 打开浏览器跑 staging URL，像真实用户一样测试

但 gstack 的定位是决策和测试层，没有结构化的增量执行 workflow，也没有知识积累机制。

Superpowers：标准化的流程但缺乏深度

Superpowers 由 Jesse Vincent 开发，拥有 120k stars，几乎是 Claude Code 的标配。其流程是标准化的：

flowchart LR
    A[Brainstorm] --> B[Plan]
    B --> C[Execute]
    C --> D[Review]
    D --> E[完成]

Superpowers 实现了 Generator-Evaluator 分离：独立的 spec-reviewer + code-quality-reviewer。这比很多 skill 要好，但对比 CE，在三个维度存在深度差距：

1. Plan 阶段：在当前 context 里直接写 plan，缺乏项目历史知识
2. Review 阶段：仅 2 个 reviewer（spec + quality），覆盖面有限
3. 知识积累：完全没有知识积累机制，做完就完了，下次 session 从零开始——这是作者替换 Superpowers 的根本原因

Compound Engineering：完整的 Harness 实现 + 知识复利

CE 覆盖了 Harness 的所有角色，并在每个环节做了深度增强：

Compound Engineering (CE) 定义

核心理念

Compound Engineering 的核心理念是 “compound”（复利）：每次工作的产出不只是代码，还有下次能复用的知识。用得越久，agent 越懂你的项目。

这个理念回应了 AI Agent 领域的一个根本问题：“永续” agent 的核心并不是 24/7 不停工作，而是通过持续不断的工作，同时做到持续不断的自我改进、自我优化，避免重复的错误和重复的浪费，做到真正的 self-improving。

核心命令解析

/ce:plan - 知识感知的规划

不同于传统的 plan，CE 的 planning 阶段会并行 spawn 多个 research agents：

flowchart TD
    A[用户任务] --> B[/ce:plan]
    B --> C1[Research Agent 1<br/>搜索历史经验]
    B --> C2[Research Agent 2<br/>扫描 codebase patterns]
    B --> C3[Research Agent 3<br/>读取 git history]
    C1 --> D[综合分析]
    C2 --> D
    C3 --> D
    D --> E[结构化 Plan]
    E --> F[包含历史 learnings]

关键差异：Plan 基于项目历史知识，不只是当前 prompt。这意味着 agent 会主动规避之前踩过的坑。

/ce:work - 增量执行

按 plan 增量执行每个 feature，保持专注和结构化。

/ce:review - 多维度审查

并行 spawn 6 到 15 个专项 reviewer：

• correctness：逻辑正确性
• security：安全性审查
• performance：性能影响
• testing：测试覆盖
• maintainability：可维护性
• adversarial：对抗性测试（50+ 行 diff 触发）
• learnings-researcher：搜索历史相关 learnings
• project-standards：项目规范符合性

每个 reviewer 独立产出 P0-P3 级别的报告，确保全面覆盖。

/ce:compound - 知识积累的核心

这是 CE 最具创新性的功能。完成一个功能或修复一个 bug 后，运行 /ce:compound，它会并行 spawn 三个 agent：

flowchart TD
    A[Session 完成] --> B[/ce:compound]
    B --> C1[Context Analyzer<br/>提取问题类型/组件/症状]
    B --> C2[Solution Extractor<br/>记录有效/无效尝试<br/>Root Cause/预防措施]
    B --> C3[Related Docs Finder<br/>查重现有文档]
    C1 --> D[Orchestrator 汇总]
    C2 --> D
    C3 --> D
    D --> E{重复度判断}
    E -->|高度重复| F[更新旧文档]
    E -->|新知识| G[创建新文档]
    F --> H[docs/solutions/]
    G --> H
    H --> I[所有未来 session<br/>可搜索的知识库]

文档结构：

每个文档包含 YAML frontmatter，便于搜索和分类：

---
category: runtime-compatibility
tags: [edge-runtime, bug-fix, fetch-api]
components: [api-routes, middleware]
date: 2026-03-29
---

内容结构：

1. Problem：一两句话问题描述
2. What Didn’t Work：排查过程中试了什么没用的（避免后人重复踩坑）
3. Solution：最终解法和代码
4. Prevention：以后怎么避免

关键洞察：这个文档会被未来所有 /ce:plan 的 learnings-researcher 搜到。不是给”下一个 session”用，是给”所有未来 session”用。

设计哲学：为什么 /lfg 不自动 compound

/lfg 是 CE 的全自动模式（plan 到 PR 一条龙），但有趣的是：它没有自动 compound 步骤。

作者解释这是有意的设计：

不是每个 session 都值得 compound。改个 typo、调个 CSS、跑个 migration，这些不产生新知识。只有真正 debug 了一个坑、发现了一个 pattern、踩了一个雷的 session 才值得。自动 compound 每个 session 会产生噪音，docs/solutions/ 被低价值文档淹没，反而降低 learnings-researcher 的搜索质量。

但这也带来问题：人会忘记。作者提出的解决方案是 “compound janitor”：每天 end of day 自动扫当天所有 session 的 git diff 和 conversation，判断哪些值得 compound，筛选后批量跑。

Superpower 模式定义

核心理念

Superpowers 的核心理念是 标准化 workflow：将 AI 辅助开发从”瞎聊”升级为”有流程地用 AI”。其流程简洁明了：

brainstorm → plan → execute → review

流程详解

Brainstorm 阶段

与 AI 进行开放式讨论，探索可能的解决方案。这个阶段比较自由，目的是充分发散思维。

Plan 阶段

将 brainstorm 的结果转化为可执行的计划。关键局限：在当前 context 内直接写 plan，不主动搜索项目历史知识。

Execute 阶段

按 plan 执行代码生成。支持 subagent-driven-development，可以 spawn 子 agent 处理特定任务。

Review 阶段

实现 Generator-Evaluator 分离：

• Spec Reviewer：审查是否符合需求规格
• Code Quality Reviewer：审查代码质量

优势与局限

优势：

• 上手简单：流程清晰，易于理解和使用
• 跨工具兼容：原生支持 Claude Code、Cursor、Codex CLI 等多种工具
• 标准化：帮助团队建立统一的 AI 辅助开发流程
• 社区认可：120k stars 证明了其质量和普适性

局限（对比 CE）：

• Plan 缺乏深度：不主动挖掘项目历史知识
• Review 覆盖面有限：仅 2 个 reviewer，对比 CE 的 6-15 个
• 关键缺陷：完全没有知识积累机制——做完就完了，下次 session 从零开始

为什么仍有 120k stars

Superpowers 的流行证明了：对于绝大多数用户，标准化的 workflow 比深度的架构更重要。很多开发者需要的只是”比瞎聊更好”的体验，Superpowers 完美满足了这一点。

此外，其跨工具兼容性也是一大优势：同一套 skill 可以在不同 AI 编程工具间无缝切换。

两种模式的核心差异总结

参考资料

1. Jason Zuo on X - 原始分析文章
2. Anthropic Engineering Blog - Building effective agents (Nov 2024)
3. Anthropic Engineering Blog - Generator-evaluator framework (Mar 2026)
4. Compound Engineering - GitHub Repository
5. gstack - YC CEO’s Claude Code Skills
6. Superpowers - Jesse Vincent’s Claude Code Skills