一周涨了10万星：编码Agent框架到底在卷什么？

上周刷GitHub Trending，有个项目让我愣了一下------obra/superpowers，一个"给编码Agent加技能"的框架，星标冲到了96000。同一周，LangChain团队的open-swe也在6000星左右稳步攀升。

这不是个别现象。2026年Q1，编码Agent框架赛道突然挤满了玩家。从Superpowers的"技能驱动开发"，到Open SWE复刻Stripe内部编码Agent架构，再到Claude HUD这种给Agent装仪表盘的插件------开发者对"怎么跟AI协作写代码"这件事，显然有了新想法。

我花了几天时间把这几个项目翻了个底朝天。说说我看到了什么。

Superpowers做对了什么

先说结论：Superpowers不是又一个Agent框架。它更像一套方法论，碰巧以代码形式存在。

传统编码Agent的工作方式很简单------你给个需求，它直接开始写代码。写完你发现不对，改需求，它再写。来回几轮，代码越来越乱，Agent越来越不知道你要什么。

Superpowers换了个思路：Agent拿到需求后，先不写代码。

具体流程是这样的：

Agent先跟你对话，把需求掰碎了确认。不是走过场的确认，是真的把每个细节问清楚。
整理出一份设计方案，分成小段给你看。每段都短到你愿意认真读。
方案确认后，拆成一个个小任务。每个任务的描述详细到"一个没有上下文的初级工程师也能照着做"。
然后才启动子Agent，一个任务一个任务地执行。

听起来很笨对不对？但效果出奇地好。按照项目作者的说法，Claude可以在这个流程下自主工作好几个小时，不跑偏。

核心原因是------计划足够细，Agent的自由度就被约束在合理范围内。它不需要理解你的意图，只需要按照明确的步骤执行。这和软件工程里"好的PRD比好的程序员更重要"是一个道理。

代码层面，Superpowers以skill的形式组织能力：

yaml 复制代码

# .claude/skills/test-driven.md
---
name: test-driven-development
trigger: implementation task
---
# 写代码之前先写测试
1. 根据任务描述写失败的测试用例
2. 运行测试确认是红的
3. 写最少的代码让测试通过
4. 重构
5. 确认所有测试仍然通过

每个skill在特定条件下自动触发，不需要你手动选择。Agent在工作过程中自然地切换技能，就像一个熟练工人根据工序切换工具。

Open SWE的企业级思路

如果说Superpowers解决的是"Agent怎么写好代码"，Open SWE解决的是"怎么在公司里安全地用编码Agent"。

LangChain团队做这个项目时，参考了三个标杆：Stripe的Minions、Ramp的Inspect、Coinbase的Cloudbot。这三个都是内部编码Agent------在公司环境里自动修bug、做代码审查、处理技术债。

Open SWE的架构有几个亮点值得说：

沙盒隔离。每个任务在独立的云端Linux环境里运行。仓库clone进去，Agent拿到完整权限，随便折腾。搞砸了？销毁沙盒重来，生产环境毫发无损。

python 复制代码

create_deep_agent(
    model="anthropic:claude-opus-4-6",
    system_prompt=construct_system_prompt(repo_dir),
    tools=[http_request, fetch_url, commit_and_open_pr],
    backend=sandbox_backend,
    middleware=[
        ToolErrorMiddleware(),
        check_message_queue_before_model,
    ],
)

这段代码展示了Open SWE创建Agent的方式。注意middleware参数------ToolErrorMiddleware捕获工具调用异常并优雅处理，check_message_queue_before_model在每次调用模型前检查是否有人工干预消息。

中间件机制。这是我觉得最聪明的设计。在Agent调用LLM之前，可以插入自定义逻辑------比如检查消息队列有没有人工指令、做权限校验、记录审计日志。这套机制让Agent在执行任务的同时保持可控。

自动PR流程。Agent改完代码，自动创建PR、附上修改说明、关联相关的Issue或Linear卡片。代码审查还是人来做，但从"发现问题"到"提交修复方案"这个环节，Agent完全自主完成。

Claude HUD------Agent也需要仪表盘

在这波热潮里，有个7000星的小项目很有意思：claude-hud，一个Claude Code插件。

它做的事情很简单------在你的终端底部显示一行状态栏：

csharp 复制代码

[Opus | Max] │ my-project git:(main*) 
Context █████░░░░░ 45% │ Usage ██░░░░░░░░ 25% (1h 30m / 5h)

上下文消耗了多少、API额度用了多少、有几个子Agent在跑、TODO完成进度------全都一目了然。

这个项目火起来说明一个问题：现在用编码Agent的人越来越在意"可观测性"。Agent不再是用完即走的工具，而是要长时间运行、消耗真金白银的资源。你需要知道它在干什么，干到哪了，还能干多久。

这些项目的共同方向

把这几个项目放在一起看，有三个趋势越来越明显：

从对话到工作流。 早期的编码Agent就是个高级聊天机器人------你说一句，它做一步。现在的Agent框架强调的是自动规划、自主执行、批量完成。你给一个大目标，Agent自己拆任务、排优先级、逐个搞定。

从单体到编排。 一个Agent搞定一切的想法已经被放弃了。Superpowers用主Agent规划、子Agent执行；Open SWE用orchestrator调度多个专项Agent。多Agent协作不是花活，是处理复杂任务的必要手段。

从黑盒到可观测。 Claude HUD走红不是偶然。当Agent任务从"改一行代码"变成"重构整个模块"，你必须能看到中间过程。日志、进度条、资源消耗------这些在传统软件里是基本功，在Agent领域才刚刚被重视起来。

给开发者的实操建议

如果你想在自己的工作中用上这些框架，几个经验分享：

先从Superpowers的方法论开始，不一定用它的代码。 核心思路是------给Agent的指令越具体，产出越稳定。与其花时间调参数，不如花时间写更详细的任务描述。

沙盒环境不是可选项。 特别是在公司项目里。Agent重写了你的数据库迁移文件这种事，发生一次就够了。Docker、Firecracker、或者直接用云端容器，选一个用起来。

控制上下文窗口消耗。 编码Agent最常见的失败模式是上下文溢出------项目大了，Agent读了太多文件，有效信息被淹没。Superpowers的做法是控制每个子任务的scope，避免单个Agent接触太多代码。类似的，open-swe每个任务用独立的Agent实例，上下文互不污染。

监控Agent的API消耗。 一个不小心的循环调用可能在几分钟内烧掉你一个月的额度。Claude HUD这类工具不是锦上添花，是必需品。

写在最后

编码Agent框架的爆发，本质上是开发者从"用AI辅助写代码"进化到"用AI自主交付代码"。这个转变不可能一步到位------Superpowers那套流程之所以管用，恰恰是因为它限制了Agent的自由度。

当下的编码Agent更像是一个纪律性极强的初级工程师：给它清晰的spec、足够的测试、隔离的环境，它能稳定产出。但指望它自己做架构决策、理解业务上下文？还早。

好消息是，框架层面的问题正在被快速解决。半年前我们还在纠结"Agent怎么读文件不出错"，现在讨论的已经是"怎么让十个Agent协同重构一个大项目"。

这个速度，说实话有点吓人。

关注公众号 92year，每天一篇AI工具深度实测