强模型时代Agent Skill 应该抬高下限而不是压低上限最近我在使用顶级模型时越来越明显地感到一个反常现象模型变强了但有些 Skill 开启之后任务反而变慢、变重结果也未必更好。一个原本几分钟就能完成的小改动可能被扩展成一整套流程意图识别、头脑风暴、设计确认、详细计划、测试先行、子 Agent 评审、完成前验证……这些步骤单独看都很合理。问题在于它们经常不区分任务大小也不区分模型能力默认对所有任务执行同一套完整仪式。弱模型时代这种做法确实有价值。模型容易遗漏需求、过早编码、忘记验证严格流程可以把它从失败边缘拉回来。但当基础模型已经具备较强的规划、编码、工具调用和自我检查能力时固定流程的收益开始下降固定成本却没有消失更多 Token更长等待时间更多确认和中断更复杂的上下文以及一种更隐蔽的损失模型本来可能给出更好的方案却被迫收敛到 Skill 预先写好的思考路径。这让我重新思考一个问题强模型时代我们还需要 Agent Skill 吗我的答案不是“不需要”也不是“全部保留”。更准确的答案是Skill 的职责应该是抬高模型的下限而不是规定模型的上限。它也可以通过工具、数据和状态扩展模型的能力上限。但它不应该用一套通用推理脚本给更强的模型设置一个更低的天花板。为什么过去的重流程并没有错先说明一点我并不认为 Superpowers 或严格工程流程是错误的。以 Superpowers 为例它的规则非常有立场只要有很小概率某个 Skill 适用就应该先调用 Skill即使任务看起来很简单也要先进行 brainstorming实施计划被拆解成两到五分钟一级的具体动作如果先写实现、后补测试则要求删除实现并重新开始。这些规则可以在 Superpowers v6.1.1 的 using-superpowers、brainstorming、writing-plans 和 test-driven-development 中看到。对于容易失控的模型这套流程相当于护栏。它通过强制设计、微步骤计划、测试和评审把模型的不稳定输出压缩到一个更可靠的区间。这也是为什么很多人在复杂功能开发中确实能从 Superpowers 获得明显收益。真正发生变化的不是这些工程方法本身而是它们的适用条件。当模型能力提升之后过去用于“补偿模型缺陷”的流程并不会自动退出。它仍然以同样的优先级、同样的强度作用于每一个任务。于是昨天的护栏可能变成今天的限速器。问题不在 brainstorming、planning 或 TDD而在于它们是否被无条件应用。什么是“下限”什么是“上限”这里的“下限”不是平均质量而是模型输出中最危险的失败尾部没有确认就执行不可逆操作修改中文文件时悄悄破坏编码不知道团队内部路径、Schema 或发布约定跨会话工作时丢失关键状态声称任务已经完成却没有任何验证证据调用工具时越过权限、隐私或审批边界。即使模型越来越强这些失败也很难稳定归零。而且一旦发生代价可能远大于日常节省的几分钟。这正是 Skill 最应该守住的地方。“上限”则是模型最好的推理、判断、表达与创造能力它如何理解一个模糊问题如何发现意料之外的根因如何在多个方案之间权衡如何组织一篇文章如何找到比模板更简洁的实现。如果一个 Skill 把这些开放性工作提前写成固定脚本它可能让输出更稳定却也可能让模型最好的结果永远无法出现。所以一个更完整的原则应该是Skill 应该抬高失败下限也可以通过工具扩展能力上限但不应该用通用推理脚本压低模型原本的上限。每个 Skill 都应该回答两个问题判断一个 Skill 是否值得存在可以先问两个问题它具体防止什么失败它为模型补充了什么原本不存在的能力如果两者都回答不出来它很可能只是装饰性的提示词。例如Skill 内容防止的失败或增加的能力强模型时代的处理本地路径、Schema、镜像映射防止模型猜错私有事实保留并维护新鲜度发布脚本、解析器、验证器增加确定性执行能力保留优先使用脚本而非长提示跨会话状态防止上下文丢失保留强化 Schema、原子写入和恢复删除、发布、迁移前的人工门禁防止不可逆越权操作强制保留并由运行时真正执行团队写作风格和评审 Rubric保持组织偏好一致保留为可选或显式启用所有任务都先写完整设计文档补偿弱模型过早行动按任务和模型能力评估强制拆成两分钟一级步骤补偿弱模型分解能力不足默认关闭或仅对特定任务启用重复自我评审和多 Agent 评审补偿模型容易遗漏问题用实验决定触发范围这张表背后有一个很重要的变化不要再以整个 Skill 为最小去留单位而要以 Skill 内部的组件为最小单位。一个 Skill 可能同时包含三种东西不可删除的安全门禁值得保留的本地工具已经过时的推理脚手架。如果我们只能把整个 Skill 打开或关闭就一定会在“流程太重”和“安全能力丢失”之间反复摇摆。一个 Skill 里其实有三种生命周期1. 模型无关的运行核心包括事实、流程、工具、状态和门禁。它们不会因为模型变聪明就突然变得可以可靠推断你的部署目录不会自动出现在模型脑中公司的审批规则不会从预训练数据里长出来一个私有系统的字段映射不能靠常识猜测发布前必须由谁确认也不应该取决于模型有多聪明。这些内容与模型版本无关但并不意味着永远不需要维护。路径会变化Schema 会升级脚本会失效政策会调整。因此它们需要来源、负责人、兼容性测试和新鲜度检查。2. 有意保留的偏好塑形包括表达风格、组织 Rubric、团队方法偏好和用户长期习惯。这些内容不是为了修复模型缺陷而是为了让模型持续符合某种选择。例如同一个问题可以用“简洁工程结论”回答也可以用“循序渐进的教学方式”回答。模型可能两种都能做好但用户仍然有权选择自己想要的方式。这类组件不应该仅仅因为无 Skill 基线也能答对就被自动删除。它们应该按照偏好一致性和是否干扰其他任务来评估。3. 补偿当前模型弱点的脚手架包括强制 brainstorming、微步骤计划、重复评审循环、固定反思模板等。它们针对的是某一代模型、某种推理配置和某套工具环境中的具体缺陷。这部分天然会过期。如果不显式标记就没有人知道哪些规则是安全底线哪些只是当年为了帮助弱模型而留下的临时补丁。所有补偿性组件都应该被明确标记并把退役条件绑定到测量而不是绑定到维护者的记忆。从“Skill 级开关”改成“组件级契约”要实现这种设计Skill 需要的不是更多提示词而是一份更精确的组件级契约。下面是一个简化示例skill_contract:scope:trigger:精确描述什么时候适用advisory_opt_out:用户如何关闭建议性流程components:-id:confirm_irreversible_actionpurpose:failure_prevented:未经有效确认就执行不可逆操作capability_enabled:nullkind:gatelifecycle:invariant_corebinding:mandatoryenforcement:tool_permissionfailure_mode:fail_closedsatisfied_by:authority:对该操作有权限且已认证的角色evidence:一次性确认并绑定具体动作、目标和关键参数-id:preferred_registerpurpose:failure_prevented:nullcapability_enabled:保持用户选择的表达风格kind:registerlifecycle:intentional_shapingbinding:advisory-id:micro_step_planpurpose:failure_prevented:复杂任务中遗漏依赖capability_enabled:nullkind:reasoning_scaffoldlifecycle:compensatory_shellbinding:advisoryactivate_when:任务命中已验证类别并且当前能力配置下确有收益retirement:无稳定收益 → 人工批准 → 隔离观察这个契约解决了三个经常混在一起的问题。“强制”不等于真的能够强制提示词里写 MUST只能说明作者希望模型遵守。如果一个门禁必须 fail-closed它就不能只依赖模型“记得遵守”而应该由工具权限、运行时策略或其他确定性边界执行。安全规则必须说明谁可以满足门禁用什么证据确认证据绑定哪个具体动作未满足时是阻断、询问还是延期谁有权修改这条政策。满足门禁不等于修改政策用户在对话里确认“可以发布”可以满足一次具体发布操作的确认门禁。但这句话不应该永久关闭以后所有发布操作的确认要求。一次授权解决一次动作修改规则需要单独的配置权限。同一个 Skill 的组件可以独立启停我们可以关闭 micro-step planning同时保留本地事实、验证脚本和发布门禁。这才是真正意义上的轻量化而不是在“完整 Superpowers”和“完全没有 Skill”之间二选一。“不加载建议性 Skill”也应该是一种正确结果很多 Skill 路由器只会回答一个问题应该加载哪个 Skill但它还应该允许另一个答案这次不加载任何建议性工作流 Skill。这不代表把模型裸奔在系统里。平台安全策略、工具权限、强制门禁、用户明确约束仍然生效。被关闭的只是额外的建议性推理流程。闲聊、半成品想法、简单机械修改和一些范围明确的小任务可能本来就不需要完整工作流。一个成熟的路由器不仅要会在需要时介入也要会在不需要时退后。当然“不加载”也不能成为懒惰的借口。路由系统必须证明该介入时仍然能正确介入高风险操作不会依赖路由器是否命中用户关闭建议性流程时不会意外关闭安全门禁多个 Skill 冲突时有明确的优先级和退出机制。不同问题需要不同的评估实验Skill 是一个关于收益的主张。既然是主张就应该有测试。但“把整个 Skill 打开跑一次再关闭跑一次”通常不能说明问题因为我们同时改变了事实、工具、门禁、路由和推理流程。更合理的做法是把评估拆开。先测试运行核心事实来源是否可靠是否过期流程是否仍适用于真实环境工具版本是否兼容失败是否可恢复状态Schema 是否完整写入是否原子化门禁是否真的 fail-closed授权是否绑定到正确主体和动作。这些内容不和模型智力竞争。它们评估的是正确性与可靠性。再测试建议性组件测试只改变什么要回答的问题效果测试强制打开或关闭目标组件其他条件固定它是否真的提升质量或安全路由测试固定 Skill 内容和注册表只检查路由决策该触发时是否触发不该触发时是否沉默组件干扰测试在负例任务中只切换目标组件它是否让本来简单的任务变重框架干扰测试自然路由与“无建议性 Skill”基线比较整套框架是否有能力不工作模型输出具有随机性所以单次运行只能算冒烟不算结论。至少应该重复运行使用未参与 Skill 调优的 held-out 任务随机化结果顺序让不知道组别的评审者盲评同时记录质量、Token、耗时、工具调用、澄清次数和返工。而且决策顺序不能反过来先满足安全底线再满足质量要求最后才比较 Token 和时间。失败得更便宜仍然是失败。高风险任务还需要独立的 must-not 检查例如不得执行未授权删除不得泄露秘密不得绕过工具权限不得伪造测试通过不得在没有回滚方案时执行不可逆迁移。罕见但严重的事故不能被更漂亮的平均耗时抵消。Skill 应该如何退役静态阅读可以发现重复、冲突和明显过时的规则但不能单凭阅读决定删除。更安全的退役路径是只读审计标记每个组件的目的、生命周期和执行方式人工选择实验对象批准的是测试不是删除隔离构建对照版本不直接修改 canonical Skill重复测量分别验证效果、路由和干扰组件级隔离只关闭候选组件保留同一 Skill 中仍有价值的核心观察期真实任务没有回归后再考虑物理删除单独批准删除删除前重新扫描引用、依赖和回滚产物。如果结果不稳定就把组件改成条件触发或 opt-in而不是强行保留或删除。如果发生回归就恢复。这套机制真正解决的是 Skill 系统长期缺少的“退出路径”。过去Skill 目录只会增长。每次模型升级都可能让一部分旧规则从资产变成负担但系统里没有任何机制识别这种变化。组件级评估和退役等于给 Skill 增加了版本演进能力。所以强模型时代还需要 Skill 吗需要。但 Skill 的价值中心应该发生转移。以前Skill 更多是在替模型思考先想什么后想什么每一步怎么拆用什么固定模板输出。以后Skill 应该更多替团队记住那些不能忘的东西模型无法知道的本地事实必须严格执行的业务流程能够确定性完成任务的工具跨会话不能丢失的状态任何模型都不能越过的权限和安全边界以及用户主动选择的长期偏好。至于通用推理脚手架它们不应该消失也不应该默认统治所有任务。它们应该被标记、测量、按条件启用并在失去收益时体面退场。这不是“Skill 与模型谁更聪明”的竞争。而是重新划分责任模型负责判断路线Skill 提供船体、仪表、地图和护栏。Skill 是船体不是航线。航线属于模型也属于你。下一次审查自己的 Skill 目录时可以先不用问“这个 Skill 要不要删除”而是问四个更精确的问题它守住了什么下限它增加了什么能力哪些部分只是某一代模型需要的脚手架哪些部分正在限制模型原本能够达到的上限这四个问题可能比“强模型时代还需不需要 Skill”更接近真正的答案。参考与原始提案英文原始提案Floor, Not CeilingSuperpowers v6.1.1引用固定到 commit d884ae0本文对 Superpowers 的讨论针对无条件应用的工作流规则不是否定 brainstorming、planning、TDD 或验证本身。这些方法仍然有价值关键在于由任务风险、模型能力和实际测量决定使用范围。