基础模型演进将不断重塑 Skills 的边界

2024年初，你精心设计了一个基于GPT-4的代码审查Skill，它依赖精巧的检索增强生成（RAG）流水线，先从知识库拉取编码规范，再分段提交给模型审查。效果不错，团队刚把它集成进CI/CD流程。然而不到半年，Claude 3.5 Sonnet带着20万token的上下文窗口横扫而来，你突然意识到：那些为了适应8k窗口而拆得七零八落的知识块、那些复杂的检索逻辑，可能在一个“全量塞入上下文”的动作面前失去了意义。

这就是Skills开发者面临的现实——基础模型的每一次跃迁，都不是简单的“性能提升”，而是对现有Skill架构边界的直接重塑。长上下文、多模态感知、增强推理，这三个维度的演进正在重新定义什么是一个“好的Skill”、什么环节值得投入工程精力、以及哪些曾经的最佳实践正在变为技术债务。

本章将直面这个动态博弈：我们不讨论“模型会变得多强”，而是聚焦“当模型变强时，你的Skill架构应该如何响应”。结论先行——

基础模型演进不是让Skills变得无关紧要，而是让Skills的价值锚点从“弥补模型短板”转向“放大模型长板”。

长上下文窗口降低了对检索 Skill 的依赖？

GPT-4于2023年3月发布时，8k token的上下文窗口是常态，32k版本需要特殊申请。到2024年底，128k窗口已成为旗舰模型的标配。截至当前调研资料，GPT-5.4已支持100万token的上下文窗口。这意味着，一份300页的技术文档、一个中等规模代码库的核心文件，或者长达数月的对话历史，理论上可以被完整放入一次调用中。

这引发了一个核心问题：当模型能“一口气读完”所有资料时，我们还需要RAG Skill吗？

答案不是简单的“是”或“否”，而是一个成本-效果权衡矩阵。以下表格基于当前调研资料中的一线实践和社区讨论，给出可操作的判断依据。

决策矩阵：何时使用长上下文 vs RAG Skill

从当前调研资料看，一个确定的趋势是：长上下文并没有“消灭”RAG，而是改变了RAG的设计目标。 过去RAG的首要任务是在极小的上下文窗口内塞入最相关的信息；现在RAG的使命变成了降低成本和延迟、提高信噪比。

具体来说，出现了两种新的Skill架构模式：

模式一：长上下文为主，RAG为辅
适用于代码库分析、合同审查等场景。将整个代码仓库或合同放入上下文让模型建立全局理解，同时用RAG快速检索特定条款或代码片段进行精确核对。这相当于“先泛读，再查字典”。

模式二：RAG为主，长上下文兜底
适用于客服知识库、法律条文查询等场景。正常查询走RAG，但当检索结果不足以解决用户问题，或用户明确要求“全面审查”时，退回长上下文模式。Anthropic的Extended Thinking功能出现后，这种“按需深入”的模式变得尤为实用——模型可以在发现信息不足时主动触发更全面的上下文加载。

一个真实的踩坑记录（根据调研素材中的社区讨论复现）：
某团队将原本依赖10个检索Skill的法律文档分析系统，改为将全量资料放入128k上下文。结果发现：

• 优点：分析质量显著提升，模型能发现跨文档的矛盾条款，这是分段检索无法做到的。
• 代价：单次查询成本从$0.15飙升至$3.2，延迟从3秒增加到25秒。
• 最终方案：保留全量上下文用于“初审”生成全局摘要，后续的细节核查回退到RAG Skill。

核心判断：长上下文是能力，RAG是策略。Skill开发者不应问“用哪个”，而应设计“何时切换”的决策逻辑。

多模态模型如何扩展 Skills 的感知能力

GPT-4o于2024年5月发布，首次将文本、图像、音频的理解与生成统一到一个模型中。截至当前调研资料，GPT-5.4已原生集成计算机使用（computer-use）能力，这意味着模型的“感官”从视觉、听觉扩展到了操作能力。多模态不是“模型能看图了”这么简单——它对Skill架构的冲击在于：曾经需要一串专用工具才能完成的任务，现在可能只需要一个统一的接口。

技能感知能力的三级跃迁

一个具体的例子：设计一个“竞品分析Skill”。

在纯文本时代，你需要先写一个网页抓取工具下载竞品页面截图，再调用OCR提取文字，然后调用布局分析工具识别页面结构，最后提交给LLM生成分析报告——这是4个Skills的串联流水线。

多模态模型出现后，你只需要截一张图，直接提交给模型，配上Prompt：“分析这个竞品页面的信息架构、视觉重心和转化策略。” 一条API调用替代了4个Skills的编排。

设计统一的工具接口

面对这种变化，Skill开发者应该做的是设计感知能力的抽象层，而不是为每个新模态写一套独立的Skill。具体模式如下：

# 不是这样设计（每个模态独立Skill）
class ImageAnalysisSkill:
    def process(self, image: Image) -> Analysis

class AudioTranscriptionSkill:
    def process(self, audio: Audio) -> Text

# 而是设计统一的感知接口
class PerceptionSkill:
    """
    统一的多模态感知Skill。
    根据输入类型自动路由到最佳处理策略，
    同时保留降级到专用工具的能力。
    """
    def perceive(self, input: Union[Image, Audio, Video, File]) -> Perception:
        if self.model_supports(input.type):
            return self.model.direct_analyze(input)
        else:
            return self.fallback_tool.process(input)

关键在于保留降级路径。 当模型的原生多模态能力不足时（例如需要超精细OCR的表格提取），Skill应自动回退到专用工具。这种“能力感知的自适应架构”是多模态时代Skills的设计核心。

从当前调研资料中的实践反馈看，开发者在多模态Skill开发中主要踩了三个坑：

1. 过度依赖原生能力：GPT-4o的图像理解虽强，但对复杂图表中的微小数字提取准确率仍不稳定。将关键数据的提取完全交给它而不做校验，可能引入错误。

2. 接口设计过于抽象：把所有模态的输入都塞进一个data: bytes参数会让模型的意图理解变差。应为不同模态保留语义化的参数名（如screenshot、audio_clip），让模型能通过函数名本身推断Skill用途。

3. 忽略模态间的协同：多模态真正的威力在于“跨模态推理”——让模型同时看视频画面、听旁白、读字幕。但很多Skill开发仍陷在“一次处理一个模态”的思维中。设计Skill时应显式支持多模态并行输入。

增强推理与自主能力对编排的简化

2024年底，OpenAI发布o1系列推理模型，随后Anthropic推出Extended Thinking功能。这些“会思考”的模型不再只是“给定指令→生成输出”，而是能够主动规划步骤、反思错误、调整策略。对Skills架构而言，这引发了最深层的冲击：如果模型自己能规划和执行多步任务，我们还需要复杂的多Agent编排吗？

推理模型时代，你的编排代码可能在帮倒忙

先看一组对比：

当GPT-5.4的推理效率比前代提升数倍且能自主搜索工具时，很多多Agent编排的复杂性实际上是“过度工程”。

社区中已出现一个显著趋势：从“多Agent架构”向“单Agent+技能组合”回归。

根据调研素材中来自一线的实践观察，某团队原本使用LangGraph构建了包含规划Agent、执行Agent、校验Agent的三Agent系统来处理数据分析任务。切换到支持Extended Thinking的Claude后，他们发现：

• 将三个Agent的职责合并为一个配备了丰富Skill库的单Agent后，任务完成质量持平
• 系统延迟降低了60%（消除了Agent间通信开销）
• 代码量从~800行缩减到~200行
• 但失去了对每个步骤的精细审计日志

何时编排仍然必要？

增强推理不是万能药。以下场景下，外部编排仍然优于依赖模型自身的推理：

核心判断：增强推理让“简单编排”成为可能，但“编排思维”依然重要。 区别在于，过去你编排的是“模型该怎么做”，现在你编排的是“哪些事情不能只让模型决定”。

一个具体的设计原则：

• 如果你的编排图中有超过3个Agent，且每个Agent只是简单调用另一个LLM，那么很可能可以用一个推理模型+多个Skill替代。
• 如果你的编排图中包含外部系统交互、人工审批、安全校验节点，这些编排逻辑仍应保留，因为它们实现的是“环境约束”，而非“推理替代”。

全局结论：Skills架构的演化方向

综合上述三个维度的分析，基础模型演进对Skills架构的影响可以总结为以下趋势：

这些趋势不意味着Skills变得不重要。相反，Skills的价值锚点正在转移：

• 过去：Skill的价值 = 弥补模型能力短板（检索它看不到的知识、处理它无法理解的模态、规划它无法拆解的任务）
• 现在：Skill的价值 = 封装领域决策逻辑（在模型能看到的上下文中标注重点、在模型能规划的路径中设定边界、在模型能执行的步骤中注入专家判断）

你不再需要教模型怎么找信息，但你需要教它怎么看信息。

当基础模型的能力边界不断外扩，Skills的竞争壁垒将从“工程复杂度”转向“领域知识的封装质量”。这意味着一个Skill的好坏，不再取决于它调用了几次检索、串联了多少工具，而取决于它能否将专家的隐性判断转化为模型可执行的明确指令。

这一转变必然导向一个更开放的问题：如果高质量的Skills来自对领域知识的深度理解，那么封闭的单体开发模式必然被社区协作模式超越。 下一章，我们将探讨如何构建一个鼓励高质量Skills贡献与共享的开源生态——从单体到生态，社区贡献是Skills繁荣的关键。