大模型时代的 Agent 框架，不只是比谁写得快

这篇文章整理自 The Gray Cat 对 GSD 和 OpenSpec 的一次实测对比：同一个中型写作社区产品，同一个 PRD、同一个模型、同一个 Codex CLI。真正值得看的是，它把 Agent 框架到底在约束“改动”还是“项目”这件事，讲得非常清楚。

它真正有价值的地方，不在于给出一个“冠军答案”，而在于把 Agent 框架真正的分水岭暴露了出来。

大多数人聊 Agent 框架，容易停在工具名录和 README 比较：有没有 spec、有没有 subagent、有没有 slash command、星标多少。可一旦你真的把它们扔进一个不算小的真实项目里，问题就变了。

这次测试里，作者拿同一个产品 brief，分别让 GSD 和 OpenSpec 去重建一个叫 NewWriter 的写作社区。功能并不花哨，但足够复杂：登录注册、作者主页、头像、文章草稿与发布、Markdown 渲染、分类、评论、私信、未读数、排行榜、首页模块、seed data，一整套下来，已经足以把“规划—实现—验证—收尾”这条链路压实。

结论很有意思。OpenSpec 明显更快、更省 token，也更像一个你愿意天天用的迭代框架；GSD 更重、更慢，但留下的仓库底子明显更扎实。换句话说，这不是“一个好一个坏”的对比，而是“你到底想把框架用来约束哪一层”。

先看最直观的数据：OpenSpec 赢得很干脆

如果只看时间和 token，OpenSpec 的优势几乎没有悬念。

• OpenSpec：1 小时 52 分钟完成，约 3530 万 tokens，6 个线程
• GSD：6 小时 46 分钟总耗时；即使只算最终成功的 Codex 重跑，也有 5 小时 25 分钟，约 1.26 亿 tokens，38 个线程

作者还按 GPT-5.5 当时的 API 价格做了一个折算：

• OpenSpec 约 27.71 美元 API 等价成本
• GSD 约 103.99 美元 API 等价成本

这里最重要的，不是“GSD 贵”，而是它贵得非常结构性。不是偶然多绕了几步，而是它本来就想管理更多事情：需求、路线图、阶段、研究、验证、状态文件、子代理、工作流切分。你让它上场，它就不是来帮你补几段代码的，它是来接管项目流程的。

所以如果你只把胜负标准定义成“多快做出一个能跑的东西”，OpenSpec 基本已经赢了。

但如果只看浏览器结果，你会错过真正的区别

视频里有个很关键的反转：从浏览器测试看，两边最后做出来的 app 其实很接近。

注册、登录、个人资料、发文、评论、私信、未读消息、排行榜，这些核心功能，两个框架最后都做出来了。甚至一些问题也很像：登录或注册失败后表单值保留得不够好，评论发完之后反馈不够明显，未读私信提示需要补一轮提示式修正。

也就是说，站在最终用户界面前，你未必会觉得两者差了 3 到 4 倍的 token，更不会自然联想到 5 个小时和 1 个多小时之间的差距。

真正把差距拉开的，是作者后来打开代码库时看到的东西。

GSD 留下了更完整的工程地板：

• 有 test、typecheck、lint、build、prisma:generate 这些脚本
• 有真实测试文件，而不只是“以后再补”的口头承诺
• 配置层面使用 DATABASE_URL，不是把 SQLite 路径硬编码进去
• 一些 helper 拆分更干净
• 头像上传这类细节，也用了更稳妥的文件名策略

OpenSpec 那边不是不能用，而是更像“尽快把东西做对、做出来”。能跑，能看，主要流程顺，但工程脚手架明显更轻，很多质量保障没有顺手被建起来。

这恰好呼应了我自己知识库里对这几类框架的一条判断：OpenSpec 更像“规格层”，GSD 更像“执行层”。前者擅长把改动定义清楚、拆成可推进的 change；后者则试图把长任务里的状态管理、并行波次、验证纪律一起吞进去。视频里的实测，并没有推翻这个判断，反而把它落到了最朴素的体验层面。

这不是“快 vs 慢”，而是“改动导向 vs 项目导向”

视频里有一句话特别好：GSD wants to own the project，OpenSpec wants to own the change。

我觉得这几乎就是这次测试最值得记住的核心句。

OpenSpec 的工作单元很清楚：proposal、design、tasks、delta specs，然后 apply，再 archive。它天然适合“我知道要改什么，现在把这次变更讲清楚、做扎实”。这意味着它很适合增量开发，也更适合棕地项目：不是重建世界，而是在已有世界上持续往前走。

GSD 则更像项目经理 + 执行总控。它一上来就建立 .planning/，生成 requirements、roadmap、phase、research、state，再按 phase 讨论、规划、执行、验证、交付。这个思路的好处，是你确实能把一个大块任务拆成大块自治执行；坏处也很明显——框架本身会带来额外的流程惯性。

所以如果你的工作方式偏“先把路线握在手里，然后一小步一小步做”，OpenSpec 很顺手。如果你的问题是“任务太大、上下文太长、经常做着做着就散了”，GSD 那种更重的状态机反而可能正中靶心。

GSD 最有价值的，不是慢，而是把验证当成默认配置

视频里我最认同的一点，不是对 OpenSpec 的夸奖，而是对 GSD 的一种“虽慢但讲道理”的评价。

GSD 并不是那种典型的“多角色扮演型流程框架”。它不是叫几个 Agent 假装 PM、架构师、测试、审查员，然后把一堆文档甩给你确认。作者说得很直白：他不喜欢那种人类一直在回路里按按钮的工作流。GSD 真正比某些旧框架进步的地方，在于它的流程背后确实带了自动化，能够自己跑一大段，然后等你回来验收。

这一点，其实和我知识库里另一条长期判断能接上：AI 编程真正的价值，不是“写得更快”，而是“验证得更深”。如果没有测试、文档、评估结果这些持续抬高质量地板的东西，项目一旦复杂起来，所谓 vibecoding 只会越写越脆。

从这个角度看，GSD 的“笨重”不只是缺点，它也是一种立场：它假设复杂项目里最贵的不是首轮实现，而是后续每一轮改动把旧东西撞坏的成本。所以它宁愿前面慢，也要把 repo baseline 建起来。

这也是为什么作者最后虽然更偏爱 OpenSpec，却仍然承认 GSD 做出了更强的仓库底子。因为它确实在试图把质量门前置，而不是把“以后再补测试”当成一个总会发生、其实很少发生的承诺。

OpenSpec 为什么更讨人喜欢：它更像真实开发节奏

尽管如此，作者最后个人还是选了 OpenSpec。我也完全理解。

原因不是它更“高级”，而是它更符合日常开发的节奏。提一个 change，做掉，检查，归档，再往下一个 change 走。这个 loop 很小，反馈很快，心智负担也低。你不会觉得自己被流程架住，更不会频繁进入“等框架想清楚项目到底是什么”的状态。

视频里一个细节很有代表性：OpenSpec 在第一阶段就更快给出了一个浏览器里看得见、摸得着的产品雏形。哪怕后面还有功能 stub，但人已经能和产品互动了。这种“尽早出现真实物体”的体验，对很多开发者来说很重要。它不是虚荣，而是能显著降低不确定感。

而且 OpenSpec 还有一个很现实的优点：它把“路线图的控制权”更多留给人。作者提到，如果换一种更讲究的用法，完全可以先让一个 LLM 把整项目切成几个 phase，然后每个 phase 变成一个 OpenSpec change。也就是说，它不是不能做更大任务，而是默认不替你把整套大工程机器先开起来。

这也是为什么我一直觉得，OpenSpec 代表的是一种很现代的工程观：先把变更边界收紧，再让工具围绕这次变更工作。它天然更轻，也更接近“规范是一个持续生长的差量系统”，而不是“一次性把全局蓝图拉满”。

真正该问的问题，不是哪一个更强，而是哪一种摩擦更值得付

这次视频最有价值的地方，是它把“Agent 框架对比”从抽象理念，拉回到了很具体的代价交换。

你想省什么？

• 省时间、省 token、省等待中的无聊感，那 OpenSpec 明显更优
• 省后续改坏旧功能的风险、省脚手架补课、省质量门后补的代价，那 GSD 更有说服力

它们都不是免费午餐，只是把成本放在了不同位置。

OpenSpec 把更多控制权和责任留给人，所以更轻、更快，也更依赖你自己能不能稳住 roadmap。GSD 把更多流程吞进框架，所以更重、更慢，但你得到的是一个更像工程系统而不是 prompt 组合的执行底座。

从这个意义上说，这个视频并没有给出一个“最终冠军”，反而给出了一个更重要的提醒：Agent 框架的分野，可能不在生成能力，而在上下文和流程的组织哲学。真正难的不是 while 循环，不是 tool call，也不是命令名字叫 /opsx:propose 还是 $gsd-plan-phase。真正难的，是你到底想让模型在什么边界内思考，又愿意为这种边界付出多少流程成本。

我的判断：先选你受得了的摩擦，再选你崇拜的理念

如果你是个人开发者，或者团队节奏本来就偏快，能自己掌控需求切分，也愿意边走边修，我会更倾向 OpenSpec。不是因为它绝对更好，而是因为多数人真正坚持不下来的，不是工具能力，而是工具摩擦。一个每天都愿意打开的系统，通常比一个理论上更完整、但两周后就懒得用了的系统更有价值。

但如果你面对的是长任务、大仓库、多人协作、必须把验证纪律制度化的项目，那 GSD 的价值会明显抬头。尤其是当项目开始跨过“页面能跑”那条线，进入“以后每次改动都可能带来级联损坏”的阶段，测试、typecheck、lint、状态管理、验证步骤这些东西就不再是洁癖，而是生存条件。

所以我会把这次视频的结论翻译成一句更简单的话：

OpenSpec 像一个高效的改动框架，GSD 像一个愿意替你背项目复杂度的执行框架。

前者更像优秀的日常搭子，后者更像重装备。选哪个，不看谁更酷，看你现在扛的到底是哪一种复杂度。

附：视频里的几个关键信息点

• 视频标题：GSD vs OpenSpec: Speed, Tokens, and Code Quality
• 频道：The Gray Cat
• 时长：约 21 分钟
• 对比对象：同一 PRD、同一模型、同一 Codex CLI 下的双框架实测
• 测试项目：NewWriter，一个中型写作社区产品
• 视频主结论：OpenSpec 更快更省，GSD 更重但 repo baseline 更强
• 作者个人偏好：OpenSpec

作者对 GSD 的保留评价也很关键：它更接近“真正能自治跑工程流程”的框架。