从提示词到工作制度：Superpowers Skill 的结构上下文哲学
我一开始把 Superpowers skill 理解成一组“给 Agent 用的好习惯”：
先 brainstorm
先写测试
用 worktree 隔离
写 skill 要验证
完成前要 review这当然没错，但还停在表层。
它真正有意思的地方，不是把软件工程流程写进 Markdown，也不是给模型多塞几段 prompt。它更像是在回答一个更底层的问题：
当一个 LLM Agent 的工作记忆不稳定、注意力会漂移、行动又会真实改变文件系统时，
我们应该怎样组织它的上下文？我的理解是：
Superpowers skill 的本质，是把 Agent 的上下文从“聊天记录”改造成“工作制度”。这里的“制度”不是大词。它指的是一组很具体的东西：触发条件、阶段顺序、硬门槛、证据要求、禁止动作、外部产物、验收标准和恢复路径。
普通 prompt 只告诉模型“你应该怎么做”。Superpowers 更进一步：它试图让 Agent 在一个结构化工作场里行动。模型不再只是读一段建议，而是被放进一个有入口、有阶段、有检查点、有退出条件的流程里。
这就是它对“结构上下文管理”的哲学。
1. 问题不是上下文不够长，而是上下文没有形状
长上下文很容易让人产生一个错觉：
只要把足够多的信息塞进去，Agent 就会稳定变聪明。但实际使用里，失败经常不是信息缺失，而是结构缺失。
比如一个 coding agent 明明看到了“先写测试”，还是可能直接改实现。明明看到了“不要污染当前分支”，还是可能在用户工作区里直接动手。明明看到了“先澄清需求”，还是可能马上生成一套过度设计。明明看到了“验证后再结束”，还是可能在测试没跑完时给出完成报告。
这不是模型完全不知道规则，而是规则在长上下文里只是软信息。它和用户消息、历史工具输出、模型自己的计划、错误日志、代码片段混在一起，没有足够强的结构地位。
所以 Superpowers 的目标不是简单增加信息量，而是重塑信息的权重和顺序。
一个真正有用的 skill，至少要回答这些问题：
什么时候触发？
进入后第一步必须是什么？
哪些行为在这个阶段禁止？
什么证据能证明可以进入下一阶段？
产生什么外部产物？
失败后回到哪里？
什么时候才算完成？这就是结构上下文。它不是“上下文里有什么”，而是“上下文怎样组织行动”。
2. Superpowers 不是教程，而是 Agent 的过程接口
看几个 Superpowers skill 的设计，就能看到这层哲学。
brainstorming 的核心不是“多问几个问题”。它真正做的是在实现前建立一个硬门槛：
没有理解项目上下文，不进入设计
没有提出方案权衡，不进入定稿
没有用户确认设计，不进入实现这等于把“需求理解”从模型的内心活动，变成一个必须显式经过的外部阶段。
test-driven-development 更明显。它不只是说“写测试比较好”，而是要求：
先写失败测试
亲眼确认它以正确原因失败
再写最小实现
再确认通过
再重构关键不是 TDD 这个口号，而是“看见测试失败”这个证据门槛。没有这个门槛，测试可能只是实现之后的装饰；有了这个门槛，测试就变成了行为约束。
using-git-worktrees 管的是另一类上下文：工作区状态。它让 Agent 先判断自己是不是已经在隔离环境里，再决定是否创建 worktree。这里的“上下文”已经不是文本，而是文件系统、分支、未提交修改、测试基线。
writing-skills 最能体现 Superpowers 的自反性。它说写 skill 本身也要像 TDD：先设计压力场景，看没有 skill 时 Agent 会怎样失败；再写 skill；再验证 Agent 是否真的改变行为。
这句话很关键：
skill 不是一篇流程文档，而是一种可被压力测试的行为补丁。如果一个 skill 不能改变 Agent 在失败场景里的行为，那它只是写得很好看的说明书。
3. arXiv 上已经有一条高度相关的研究线
我查了一圈，arXiv 上没有看到一篇“专门研究 Superpowers”本身的论文。但高度相关的论文已经很多，而且它们几乎都在逼近同一个问题：
Agent 的能力不只来自模型权重，也来自运行时怎样组织记忆、技能、工具、协议和反馈。最直接的一篇是 Agent Skills for Large Language Models。它把 agent skill 定义成一种可组合的能力包，里面可以包含 instructions、code 和 resources，并强调 progressive disclosure：先用元数据决定是否加载，再按需展开详细资源。这和 SKILL.md 的实际使用非常接近。
Externalization in LLM Agents 给了更大的框架：Agent 系统正在从“只改模型权重”，转向把能力外部化到 memory、skills、protocols 和 harness。按这个框架看，Superpowers skill 就是典型的 procedural expertise externalization：把做事方法从模型临场发挥里拿出来，放到可读、可改、可复用的外部结构中。
SkillsBench 则给了一个很实用的提醒：curated skills 平均提高 pass rate，但不是所有 skill 都有正收益；focused skills 往往比大而全的文档更有效，self-generated skills 平均并不可靠。这个结果和我的体感一致：skill 的价值不在“写得多”，而在“抓住会改变行为的最小结构”。
更靠近“结构上下文”的，是 From Skill Text to Skill Structure。这篇提出 Scheduling-Structural-Logical 表示，把 skill 拆成调度信号、执行结构和逻辑层动作证据。它想解决的问题很清楚：今天很多 SKILL.md 还是文本重、结构轻，机器要真正搜索、审计和组合 skill，需要更显式的结构。
再往前一步，是 Harnessing LLM Agents with Skill Programs 和 Formal Skill。它们都不满足于“skill 是文本建议”。HASP 把 skill 升级成能在 agent loop 中触发并干预下一步动作的 Program Function；Formal Skill 则把 reusable procedure 放进 JSON schema、executor、hook、routing metadata 和 skill-local state 里。
这说明一件事：
SKILL.md 可能不是终点，而是中间形态。今天的 Superpowers 把流程写成 Markdown，是因为 Markdown 最容易被人写、被模型读、被版本管理。但研究方向已经很明确：真正稳定的 agent skill，会逐渐从“自然语言流程”走向“可执行协议”。
4. Superpowers 和 Parametric Skills 是两条相反但互补的路
Parametric Skills 很值得一起看。它指出文本 skill 在长上下文里有一个天然问题：模型不一定能持续定位并遵守关键指令。它提出的办法是把自由文本 skill 在 test time 转成 LoRA adapter，让 skill 不再作为上下文文本被读，而是变成参数层面的行为倾向。
这和 Superpowers 形成一个很好的对照：
| 路线 | 核心动作 | 优点 | 代价 |
|---|---|---|---|
| Superpowers / SKILL.md | 把过程外部化成可读文本和硬门槛 | 易写、易改、可审计、可共享 | 仍然依赖模型遵守文本 |
| Formal Skill / HASP | 把过程外部化成 runtime 可执行结构 | 可触发、可拦截、可记录、可治理 | 作者门槛更高，需要 runtime 支持 |
| Parametric Skills | 把 skill 编译进参数或 adapter | 不占上下文，长任务里更稳 | 可审计性下降，更新和治理更复杂 |
所以问题不是哪条路“赢”。更可能的未来是分层：
稳定、高频、可训练的操作习惯，会逐渐参数化
需要审计、权限、证据、组织约束的流程，会继续外部化
需要强保证的门槛，会从 Markdown 迁移到 runtime hook 和 executable policy这也是为什么我不认为 skill 会被模型完全内化掉。
模型可以学会“通常要先写测试”，但当前 repo 的测试命令、当前失败日志、当前未提交修改、当前用户授权范围，不应该靠模型记忆解决。它们必须是外部状态。
模型可以学会“修 bug 要复现”，但“是否已经复现成功”应该由真实测试、命令输出、文件 diff 和记录下来的证据决定。
模型可以学会“写 skill 要覆盖失败模式”，但“这个 skill 是否真的让 Agent 在压力场景里改行为”，仍然需要 eval harness 或可重复任务验证。
5. 和 SWE-agent 的关系：界面会塑造 Agent 的行为
还有一篇看似不讲 skill、但哲学上很接近的论文：SWE-agent。它提出 Agent-Computer Interface，核心判断是：LM agent 不是人类用户，不能假设它用人类 shell / editor / GUI 就天然高效。给 Agent 设计合适的动作空间和反馈格式，会显著改变它的表现。
这句话放到 Superpowers 上也成立。
Superpowers 不是 Agent-Computer Interface，而更像 Agent-Process Interface：
ACI 设计 Agent 怎样操作计算机
Superpowers 设计 Agent 怎样操作一个工程流程一个好的工程流程对人类也有价值，但 Agent 更需要它。因为 Agent 的弱点不是不会说出正确原则，而是在长任务中维持原则、区分阶段、记住未完成义务、抵抗临场捷径。
所以 Superpowers 真正改造的不是模型知识，而是模型的行动环境。
6. 结构上下文到底包含什么
我现在会把结构上下文拆成七层：
| 层 | 问题 | Superpowers 里的对应物 |
|---|---|---|
| 触发 | 什么时候应该加载这套方法？ | frontmatter description |
| 阶段 | 当前处于哪个工作阶段？ | brainstorming / TDD flow |
| 门槛 | 没满足什么条件不能前进？ | hard gate、RED/GREEN 验证 |
| 证据 | 用什么证明阶段完成？ | 测试输出、设计确认、baseline |
| 边界 | 哪些状态不能被污染？ | worktree、sandbox、权限、git status |
| 产物 | 哪些上下文要离开聊天流？ | spec、plan、test、skill、commit |
| 复盘 | 失败模式怎样进入下一次流程？ | writing-skills 的压力测试循环 |
普通上下文管理关注“怎么压缩、怎么检索、怎么塞更多”。结构上下文管理关注的是：
哪些信息必须变成阶段？
哪些阶段必须有证据？
哪些证据必须外部化？
哪些外部化结果会反过来约束下一步行动？这就是 Superpowers 的本质。
7. 它的局限也很清楚
Superpowers 不是银弹。
第一，文本 skill 仍然是软约束。它可以强烈要求 Agent 遵守，但如果 runtime 不提供 hook、工具过滤、状态机和 completion gate，最终还是模型在解释文本。
第二，skill 会把坏习惯制度化。一个写错的流程，比一次错误回答更危险。因为它会跨项目、跨任务重复生效。
第三，门槛有成本。探索性任务、一次性草稿、非常小的改动，如果全部套完整流程，可能让 Agent 变慢。真正成熟的 skill 应该知道什么时候收缩，而不是永远铺满流程。
第四，skill 不是证据。skill 可以要求跑测试，但测试输出才是证据；skill 可以要求读论文，但论文内容和引用才是证据；skill 可以要求用户确认，但确认本身要被记录成下一步行动的前提。
第五，自生成 skill 不能天然信任。SkillsBench 的结果已经提醒过：模型会消费 curated skill，但不代表它能稳定写出同等质量的 skill。写 skill 需要压力测试、失败样本和验证器。
8. 我的最终判断
如果用一句话概括：
Superpowers skill 不是 prompt engineering，而是轻量级 harness engineering。它做的不是给模型“补知识”，而是给模型“补工作结构”。它承认当前 LLM Agent 的真实限制：会忘、会漂、会抢跑、会自证完成、会把建议当可选项。然后它用一种便宜但有效的方式，把这些弱点压进流程边界里。
再往本质说：
LLM 的上下文窗口是工作记忆；
Superpowers skill 试图把工作记忆改造成工作台。工作记忆是流动的、线性的、容易被新信息覆盖。
工作台有分区、有工具、有待办、有半成品、有验收区、有不能乱动的东西。
这就是结构上下文管理的核心隐喻。
未来有些 skill 会被参数化，有些会被编译成 Formal Skill，有些会变成 runtime hook，有些会沉淀为团队内部的流程资产。但 Superpowers 这类 Markdown skill 的价值不会因此消失。它是最低成本的表达层：人可以写，模型可以读，版本系统可以追踪，失败后可以修改。
真正重要的不是 Markdown 这个载体，而是它背后的哲学：
不要把 Agent 的可靠性寄托在一次聪明回答上。
把可靠性拆成可触发、可执行、可验证、可复盘的结构。这才是 Superpowers skill 最值得学的地方。
延伸阅读
- Agent Skills for Large Language Models
- Externalization in LLM Agents
- SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks
- From Skill Text to Skill Structure
- Harnessing LLM Agents with Skill Programs
- Formal Skill: Programmable Runtime Skills for Efficient and Accurate LLM Agents
- Parametric Skills
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering
- ExpeL: LLM Agents Are Experiential Learners