AI 编程框架的约束竞赛：Superpowers、GSD、gstack

当所有人都声称自己解决了 AI 编程的「失控」问题时，真正的失控才刚刚开始。

2026 年 3 月，AI 编程框架的竞争进入了一个诡异的阶段。Superpowers 用「技能强制」约束过程，GSD 用「状态机」约束环境，gstack 用「角色分工」约束视角，OpenAI 的 Harness Engineering 则用「声明式编排」约束意图。它们都在做同一件事：给失控的 Agent 套上缰绳。

但问题在于——约束不是解决方案，而是问题的转移。

据我们了解，Superpowers 在 GitHub 上已积累 3.15 万+ stars¹，gstack 发布数天内即获得约 2 万 stars²，Harness Engineering 相关仓库在 3 个月内激增到 107 个³。然而，一位同时深度使用过这四套系统的资深工程师告诉我们：「它们都在解决同一个症状（Agent 失控），却没人敢碰真正的病因（Agent 不理解）。」

这场「约束竞赛」的本质是什么？各家方法的边界在哪里？以及，为什么它们都离「真正的自主工程」还有距离？

Superpowers：用「强制技能」约束过程，但谁来约束技能？

Superpowers 的思路很直接：既然 Agent 会乱来，那就让它「必须」按规矩来。

这个由 Jesse Vincent（obra）创建的框架⁴，核心机制是「技能强制触发」——在 SKILL.md 文件中写入类似 “You MUST use this before any creative work” 的指令，Agent 在检测到对应意图时，必须优先触发技能，而非直接编码。截至 2026 年 1 月，它已被 Anthropic 官方接入 Claude Code 插件市场⁵。

这套机制的本质是「过程约束」。

它强制 Agent 遵循 RED-GREEN-REFACTOR 的 TDD 循环，强制在编码前完成设计文档，强制通过子 Agent 进行代码审查。一位使用 Superpowers 的 Tech Lead 表示：「它确实减少了『拍脑袋编码』的情况，我们的代码规范遵守率从 60% 提升到了 90%。」

但问题也随之而来。

首先是技能爆炸。当项目复杂度增加，需要的技能文件数量呈指数级增长。一位在大型项目中使用 Superpowers 的开发者向我们抱怨：「我们的项目有 47 个 SKILL.md 文件，维护它们的时间比写代码还长。」

其次是刚性过强。Superpowers 假设所有开发场景都可以被预定义，但现实是——软件工程充满了「未知的未知」。当遇到技能未覆盖的场景，Agent 要么僵住，要么绕过约束直接行动。

最根本的问题是：技能本身的质量谁来保证？

Superpowers 把约束的责任推给了开发者，但开发者写的技能文件可能本身就是错的、过时的、或相互矛盾的。一位框架研究者指出：「Superpowers 解决的是『Agent 不遵守规则』的问题，但无法解决『规则本身就是错的』的问题。」

说到底，过程约束只是转移了失控的风险，而非消除了失控的根源。

GSD：用「状态机」约束环境，但状态机不是工程

GSD（Get Shit Done）走了另一条路：与其约束 Agent 的行为，不如约束 Agent 所处的环境。

这个框架的核心是「上下文工程」（context engineering）⁵。它通过 JSON 配置定义状态机，强制 Agent 在每个状态下只能看到特定的上下文，从而避免「上下文腐烂」（context rot）——即随着对话进行，Agent 被无关信息淹没、决策质量下降的问题。

据其官方文档，GSD 提供 24 个 slash 命令管理项目生命周期，支持多 Agent 编排，每个任务都有独立的上下文，任务完成后上下文自动清理⁶。GSD 的 v2 版本甚至直接内嵌到 Pi SDK，可以直接操作 Agent Harness 本身：清理上下文、注入文件、管理分支、跟踪成本⁷。

这套机制的本质是「环境约束」。

它承认一个残酷的事实：Agent 的上下文窗口是有限的，而代码仓库的信息是无限的。所以与其让 Agent 自己决定「该记住什么」，不如由系统强制「只能看到什么」。

一位使用 GSD 的开发者评价：「它确实延长了 Agent 的有效工作时间。以前 4 小时就失忆，现在能撑 8-10 小时。」

但 GSD 的问题在于——它把软件工程简化成了状态转换。

真正的工程不是状态机。架构决策需要全局视角，重构需要理解历史债务，调试需要跨模块的关联分析。GSD 的「上下文隔离」在保护 Agent 的同时，也剥夺了它进行深度推理的能力。

一位架构师指出：「用 GSD 做 CRUD 应用很爽，但做分布式系统架构时，Agent 因为看不到全局，经常做出局部最优、全局灾难的决策。」

更重要的是，GSD 假设「上下文清理」总是安全的。但现实中，很多关键信息看似无关，实则是决策的隐性依赖。强制清理可能导致 Agent 在不知情的情况下重复之前的错误。

环境约束保护了 Agent，但也囚禁了它。

gstack：用「角色分工」约束视角，但角色不是团队

Garry Tan 的 gstack 提出了一个更诱人的愿景：把 Claude Code 变成「你能管理的虚拟工程团队」⁸。

它的核心机制是「角色约束」——通过 /ceo、/cto、/eng 等命令，强制 Agent 在特定模式下工作。CEO 模式只关注产品目标和用户问题，CTO 模式只关注技术选型和架构，Eng 模式只关注实现细节。每个角色都有明确的边界，不能越界。

这套机制配合 SKILL.md 标准和 Conductor 编排系统，试图模拟真实团队的协作方式。据 Garry Tan 的演示，gstack 可以并行运行多个 Agent，分别负责不同模块，通过标准化的接口协作⁹。

这套机制的本质是「视角约束」。

它试图解决一个根本问题：单个 Agent 无法同时处理战略和战术、产品和工程、长期和短期。通过角色分工，让每个 Agent 只关注一个视角，从而降低认知负荷。

一位早期使用者表示：「角色切换确实让 Agent 的输出更有针对性。CEO 模式下的需求文档比之前清晰多了。」

但 gstack 的问题在于——它混淆了「角色」和「能力」。

真正的工程师之所以能在不同角色间切换，是因为他们具备底层的通用能力：理解业务、权衡取舍、预判风险。gstack 的 Agent 并没有这些能力，它只是被强制「假装」在某个角色中。

结果是：CEO 模式的 Agent 会生成看似合理的产品文档，但缺乏对市场节奏的直觉；CTO 模式的 Agent 会做出技术选型，但无法理解技术债务的隐性成本；Eng 模式的 Agent 会写代码，但不知道为什么要这样写。

角色约束创造了分工的幻觉，但没有创造分工的能力。

一位批评者直言：「gstack 就像让一个人戴上不同的帽子扮演不同的角色，但这个人本身的能力没有变化。真正的团队之所以有效，是因为每个成员都有独特的专长和经验，而不是因为他们戴了不同的帽子。」

此外，gstack 的「平台无关」设计原则¹⁰——技能必须读取项目配置、不能硬编码框架命令——虽然增加了可移植性，但也限制了深度优化。当 Agent 无法充分利用特定平台的特性时，其能力上限就被锁死了。

Harness Engineering：用「声明式编排」约束意图，但声明式不是自主

OpenAI 的 Harness Engineering 把约束提升到了另一个层次：与其约束过程、环境或视角，不如直接约束「意图」本身。

这套系统于 2026 年 2 月 21 日正式发布¹¹，核心是「声明式提示」（declarative prompts）¹¹。工程师定义「想要什么」，而非「怎么做」，Harness 负责将意图分解为任务，分配给 Codex Agent 群执行。它标准化了工作流，减少了对手工脚本和定制工具的依赖。

据 OpenAI 技术员工 Ryan Lopopolo 介绍¹²，Harness 可以执行代码编写、测试生成、可观测性管理等任务，Agent 群基于工程师定义的声明式提示自主协作。

这套机制的本质是「意图约束」。

它试图回答一个终极问题：如果工程师只需要定义「做什么」，而不用管「怎么做」，软件开发会变成什么样？

Harness 的愿景很诱人：工程师成为「系统设计者」和「质量守护者」，从「埋头手写代码」转向「指挥 AI 完成开发」¹²。

但 Harness 的问题在于——它假设意图可以被完整声明。

这是一个根本性的认知谬误。软件工程中的「意图」从来不是静态的、可被完整表达的文档。它是动态的、演进的、充满隐性知识的有机体。为什么这个模块要这样设计？为什么这个技术债现在不能还？为什么这个「丑陋」的实现其实是权衡后的最优解？这些知识往往存在于工程师的直觉中，存在于团队的历史记忆里，存在于无数次失败和重构的教训中——它们无法被声明，只能被体会。

一位在 2026 年 3 月使用过 Harness 的工程师向我们表示：「对于标准任务（如添加一个 REST API），Harness 表现很好。但对于需要深度架构思考的任务，我发现自己花在『调整声明』上的时间，比直接写代码还长。更可怕的是，有时候我以为声明清楚了，Harness 给出的实现却完全偏离了我的真实意图——而我直到代码生成后才发现这一点。」

意图约束的边界，就是可表达性的边界。而软件工程中真正重要的东西，恰恰是不可表达的。

Harness 把「如何做」的决策权交给了系统，但系统并不理解工程的深层约束。它可能生成「正确」的代码——语法正确、测试通过、功能实现——但这段代码是否符合团队的技术哲学？是否考虑了未来的扩展性？是否与现有架构风格一致？这些判断需要「品味」，而品味无法被声明。

Harness 解决了「执行」的问题，但没有解决「判断」的问题。而软件工程的核心，恰恰是判断。不是「能不能做」的判断，而是「应不应该做」的判断。

横向拆解：四种约束的本质与局限

全局来看，这四套框架代表了四种不同的「控制哲学」：

框架	约束对象	核心机制	优势	致命局限
Superpowers	过程	强制技能触发	规范性强，适合标准化流程	技能维护成本高，灵活性差
GSD	环境	状态机+上下文隔离	延长有效工作时间	剥夺全局视角，局部最优风险
gstack	视角	角色分工	模拟团队协作	混淆角色与能力，幻觉严重
Harness	意图	声明式编排	工程师专注高层设计	意图表达不完整，判断缺失

它们都在做同一件事：用某种形式的「约束」来补偿 Agent 的「不理解」。

Superpowers 约束过程，因为 Agent 不会自己按规矩来；GSD 约束环境，因为 Agent 无法处理过多信息；gstack 约束视角，因为 Agent 无法同时处理多个层面；Harness 约束意图表达，因为 Agent 无法自主理解目标。

但约束是补丁，不是解药。

真正的自主工程需要 Agent 具备三种能力，而这四种框架都没有解决：

第一，深层理解能力。不是理解代码的语法，而是理解代码的意图、权衡、历史。为什么这段代码写成这样？当时面临什么约束？未来可能如何变化？

第二，价值判断能力。不是按照规则执行，而是理解规则背后的价值，并在冲突时做出权衡。技术债什么时候该还？什么时候该借？没有标准答案，需要基于对业务和技术的综合判断。

第三，持续学习能力。不是记住上下文，而是从经验中学习，形成可迁移的洞察。这次重构的教训如何应用到下次？这个 bug 的模式是否在其他地方也存在？

一位在 Anthropic 从事 Agent 研究的科学家向我们透露：「当前所有框架都在做『外部约束』——用规则、状态、角色、声明来限制 Agent 的行为。但真正的突破将来自『内部理解』——让 Agent 自己建立工程直觉。这不是 prompt engineering 能解决的，需要根本性的架构创新。」

约束的终极形态是「无约束」

一个值得关注的信号是：最极简的 CLAUDE.md 配置只有两行——“auto-merge PR，post to Slack”。

这个极简配置背后是一个深刻的洞察：不要想着补齐模型的能力缺口，而是要关注如何闭环模型的生产环境。

这与当前四大框架的复杂形成鲜明对比。Superpowers 有 47 个技能文件，GSD 有 24 个 slash 命令，gstack 有 15 个角色模式，Harness 有复杂的声明式语法。它们都在做同一件事：假设模型不够聪明，所以需要外部系统来补偿。

但极简配置的做法假设了相反的事：模型足够聪明，只需要 minimal 的 scaffolding 来闭环。

“With every model you have to add less and less”——这是一个关键预测。不要 over-engineer 当前的架构，因为六个月后大部分都会过时。模型的能力在指数级增长，今天复杂的约束系统，明天可能就成了 technical debt。

这才是 Harness Engineering 会火的真正原因：它不是 over-engineer，是 just enough engineer。不是补齐模型的缺口，而是让模型的能力在生产环境中闭环。

更深层的预见：约束竞赛的终局

如果我们把视野拉长到 12-18 个月，这场约束竞赛可能会走向一个出人意料的方向。

短期（6个月内），我们会看到「约束叠加」的趋势——Superpowers 的技能系统 + GSD 的上下文管理 + gstack 的角色分工 + Harness 的声明式编排，被整合进一个「超级框架」。这个框架会声称解决了所有问题，但它真正的贡献是让我们看清：约束的堆叠有其极限。

中期（12个月内），「约束疲劳」将开始出现。当开发者发现维护约束系统的成本超过收益时，会出现一波「去框架化」的反弹。一些团队会回归简单的「人类主导、AI 辅助」模式，放弃对 Agent 自主性的追求。

长期（18个月+），真正的突破可能来自一个完全不同的方向：神经符号混合架构（Neuro-Symbolic Hybrid）。这种架构将大模型的模式识别能力与符号系统的逻辑推理能力结合，让 Agent 既能「感受」代码的品味，又能「证明」设计的正确性。这不是约束，而是赋能。

一位参与早期原型开发的研究者描述：「在这种架构下，Agent 不再是被约束的对象，而是被赋予『工程良知』的主体。它会自己问自己：『这个设计符合我们的架构原则吗？』『这个实现是否引入了不必要的复杂性？』——不是因为我们强制它问，而是因为它真正理解了这些问题的重要性。」

但这需要跨越两个巨大的鸿沟：从相关性到因果性的跃迁（Agent 不仅知道「什么代码好」，还知道「为什么好」），以及从个体到集体的跃迁（Agent 不仅学习个人经验，还能吸收整个工程社区的集体智慧）。

说到底：约束是拐杖，理解才是腿

2026 年的 AI 编程框架竞赛，本质上是一场「谁能让 Agent 看起来更可靠」的竞赛。更准确地说，是一场「谁能把 Agent 的失控包装得最优雅」的竞赛。

Superpowers、GSD、gstack、Harness 都在用不同的方式掩盖同一个事实：当前的 Agent 并不真正理解软件工程。它们可以生成代码、执行测试、甚至并行协作，但它们不理解为什么要这样做，也不知道什么时候该打破规则。

这是一个残酷的真相：我们造出了能够生成数百万行代码的系统，却造不出能够判断「这行代码该不该写」的系统。

约束机制让 Agent 在「看起来可控」和「实际上可控」之间划上了等号。但这两者的差距，正是当前 AI 编程工具的隐性成本。这种成本不会立即显现——它隐藏在技术债的累积中，隐藏在架构的腐化中，隐藏在团队对 Agent 的过度信任中。等到问题爆发时，往往已经难以挽回。

一位有着 20 年编程经验、曾参与多个大型开源项目的技术负责人告诉我们：「我用这些框架生成了很多代码，但每当我需要做出关键架构决策时，我还是得自己上。Agent 可以帮我写 80% 的代码，但剩下的 20%——决定项目成败的 20%——它帮不了我。更可怕的是，有时候我会误以为它能帮我，直到三个月后才发现那个决策是错的。」

这 20% 是什么？是判断技术债的偿还时机，是权衡性能与可维护性，是预判业务变化对架构的影响，是在没有标准答案时做出选择。这些判断的共同点是什么？它们都需要对「不可量化之物」的感知——对简洁的审美、对风险的直觉、对未来的想象。

这些能力，无法通过约束获得，只能通过理解获得。

当前的框架都在优化「执行效率」，但软件工程的本质是「决策质量」。当 Agent 只能执行、不能决策时，它就是一个工具，而不是一个工程师。工具可以被约束，工程师需要被理解。

真正的突破不会来自更多的约束，而会来自更深的理解。当 Agent 能够像资深工程师一样「读懂」代码背后的故事、「感受」架构的权衡、「预判」变化的影响时，约束才会变得多余。

在那之前，我们只是在用更复杂的约束，管理一个本质上不可控的系统。而历史告诉我们：用复杂系统管理复杂系统，最终只会得到更复杂的复杂系统。

但这不是终点。

约束是拐杖，理解才是腿——而腿的存在，是为了最终能够奔跑。

当前的四大框架，无论它们有多少局限，都在做一件有价值的事：它们在用各自的方式探索 Agent 的边界，暴露 Agent 的缺陷，为真正的突破积累经验和数据。Superpowers 的技能系统让我们看到过程规范化的价值；GSD 的上下文管理让我们意识到信息筛选的重要性；gstack 的角色分工让我们思考协作的本质；Harness 的声明式编排让我们重新审视意图表达的可能性。

这些都是「理解」的前奏。

真正的 Agentic 未来，不是被约束的 Agent，而是拥有「工程良知」的 Agent——它不需要被强制遵守规则，因为它理解规则背后的价值；它不需要被限制上下文，因为它知道什么信息值得记住；它不需要被分配角色，因为它清楚自己在团队中的位置；它不需要被声明意图，因为它能够感知人类真正想要的是什么。

这不是科幻。神经符号混合架构的雏形已经在实验室中运行，多模态大模型正在学会「看」代码而不仅是「读」代码，强化学习让 Agent 能够从反馈中学习而不仅是模仿。这些技术的融合，将在未来 18-24 个月内催生新一代 Agent——不是更快、更听话的工具，而是更理解、更自主的协作者。

一位资深 AI 研究者说：「我们现在的阶段，类似于汽车发明初期的『无马马车』——人们还在用控制马车的思维去设计汽车。真正的汽车，是当设计师不再思考『如何让马跑得更快』，而是思考『机器能做什么马做不到的事』。Agent 的真正突破，也将发生在我们不再思考『如何约束 Agent』，而是思考『Agent 能理解什么』的时候。」

约束竞赛的终点，是理解竞赛的起点。

当 Agent 真正理解软件工程时，约束将不再是必要的拐杖，而是可选的工具。人类工程师可以选择让 Agent 自主运行，也可以选择精细控制——不是因为 Agent 需要被控制，而是因为人类选择控制。

那时的 Agent，将不再是「被约束的对象」，而是「被信任的伙伴」。

这才是 Agentic 的真正含义：不是更多的规则，而是更深的理解；不是更紧的控制，而是更大的自主；不是更复杂的约束系统，而是更简洁的智能本身。

我们正在从「约束时代」走向「理解时代」。这场竞赛的真正赢家，将是第一个跨过这条鸿沟的人。

但也许，赢家不会是那些构建最复杂约束系统的人，而是那些最懂得「做减法」的人。

那个只有两行的 CLAUDE.md 是一个信号：当模型足够强大时，框架的价值不在于「增加什么」，而在于「移除什么」。不是给 Agent 更多规则，而是给它更多信任；不是构建更复杂的控制系统，而是设计更简洁的闭环机制。

AI 一日，地上一年。

今天的 Superpowers、GSD、gstack、Harness，无论它们多么精巧，都是过渡态。它们存在的意义不是成为终点，而是证明：当我们不再需要它们时，Agent 才真正成熟了。

那个时刻可能比我们想象的更近。当模型能够理解代码的意图、感受架构的权衡、预判变化的影响时，所有的约束都会显得多余。不是因为我们设计了更好的约束，而是因为 Agent 已经内化了这些约束背后的价值。

解放双手，只需知道的时代，不远了。

• FIN -

参考