1. 从提示词到技能Agent开发正在经历的范式拐点今年上半年我在社区讨论里关注到一个明显的趋势越来越多团队在复现同一个问题——同一个Agent在演示Demo里表现还不错一放到生产环境里跑上几天就开始频繁掉链子。要么是同样的指令今天能执行、明天就飘了要么是模型在复杂任务里顾此失彼把该做的步骤漏掉。大家一开始都以为是提示词写得不够好于是一版一版地调system prompt从几百行调到上千行结果边际收益越来越低。直到我接触了agent-skills这个项目思路才意识到问题可能出在抽象层次上我们一直试图用“提示词”这种文本指令去约束模型行为却忽略了Agent应该像人一样把重复性的、流程固定的工作封装成“技能”需要的时候直接调用而不是每次临场发挥。这个思路在2025年的AI应用圈里已经不算冷门了很多前沿团队都在往这个方向转。这篇文章想聊清楚几件事为什么Agent Skills会成为新的开发范式它的内部结构到底是什么样核心技术点尤其是Sliding Window和双通道经验沉淀是怎么运作的以及如果你想在自己的项目里落地这套思路应该从哪下手、有什么坑要避。适合正在做Agent应用开发、写复杂提示词写到想吐、或者在做个人AI工具的读者参考。我不打算写成一个通用理论科普更多是把自己实践里的理解和判断倒出来。先说一个最核心的判断agent-skills解决的不是“模型能不能够”的问题而是“应用层怎么组织能力”的问题。它把工程重心从模型调教转移到了技能设计上。2. Agent形态演进的内在逻辑以及它为什么停在提示词层面2.1 从RAG到Function CallingAgent能力演进其实一直在补“上下文”的窟窿回顾一下过去三年Agent能力的演进路线你会发现一条很清晰的线索。最初大家做问答机器人本质是RAG——把文档切片、向量化、检索、拼接进上下文让模型基于检索结果回答。这个阶段解决的是“模型不知道”的问题但它本质上没有“做事”的能力只能被动应答。接着是ReAct范式和Function Calling出现模型终于能“动”了遇到问题可以自主决定调用哪个工具、传什么参数、看什么返回结果。API接口、数据库查询、浏览器操作都能被纳入Agent的执行链路。这个阶段解决的是“模型动不了”的问题。再到后面大家发现单纯的工具调用还是不够。因为工具的粒度太细了一次用户请求往往要串起五六个工具调用Agent需要在每一步做决策而每一步决策都是误差的放大机会。于是大家开始往system prompt里塞工作流描述、塞约束规则、塞输入输出规范试图用文本把Agent的决策空间压缩到一个可控范围内。这条演进路径看起来很合理但它埋下了一个隐患所有约束都是用提示词文本承载的而提示词本质上是一种“运行时软约束”。模型每次读到这段文本都需要重新理解、重新内化理解稍有偏差执行结果就飘了。这也是为什么复杂prompt的Agent在生产环境里那么不稳定。2.2 上千行system prompt的失控现场提示词的边际收益已经见顶我自己写过一份接近1200行的system prompt当时觉得每一段都有用有角色设定、有业务流程、有错误处理规范、有few-shot示例、有格式要求、有输出JSON的schema说明。结果呢三个问题非常要命。第一个问题是上下文窗口被大量占用。1200行prompt差不多对应3万多个token留给真实任务输入的空间少了一半。模型在处理复杂任务时早期信息会被后续内容稀释注意力分布越来越散很多规则写是写了模型根本没“看见”。第二个问题是规则之间互相打架。比如我在prompt里既要求“在不确定的时候一定要向用户提问澄清”又要求“尽量独立完成整个流程减少交互轮次”。这两条规则在某些场景下是矛盾的模型每次都靠“猜”来决定哪个优先级更高结果就是行为不可控。第三个问题是维护成本失控。每次业务规则调整都要从那1200行里找到对应位置、小心翼翼改写还要担心改动会不会影响其他规则。改一行字整个行为可能大变。这不是个别现象。很多团队在做Agent时都有这种感受复杂提示词的边际收益已经见顶了。你往里加再多的约束规则模型的执行稳定性和可控性也不会继续提升反而可能因为规则冲突而进一步劣化。这正是agent-skills要解决的痛点——把约束从“运行时文本”提前到“定义时结构”。2.3 技能工程与提示词工程本质上是两种抽象思维我后来想明白一件事提示词工程和技能工程的差异不是简单地把prompt换个格式保存而是对Agent能力组织方式的根本性重构。提示词工程的思维是“一次性把标准写清楚让模型每次照着发挥”。技能的思维是“把一段能力固化成独立模块让模型不需要理解内部实现就能调用”。打个比方前者是给外包员工写一份超长SOP期望他每次都能严格执行后者是让外包员工把某类工作练成肌肉记忆以后再接到这类任务不需要重新读SOP直接进入执行状态。这两种模式的对比很鲜明单元粒度不同提示词是线性的、整体性的技能是模块化的、可独立迭代的。交付物不同提示词交付的是“文本”技能交付的是“结构化的能力包”包含代码、说明、样本、配置。维护方式不同提示词调整是全局性的牵一发动全身技能调整是局部性的改一个技能不影响其他能力。抽象级别不同提示词面向模型“理解”技能面向任务“匹配”——模型先判断这个任务对应哪个技能再调用。思维转变之后Agent开发的重心就从“怎么写prompt”变成了“怎么设计技能”如何拆任务、如何定边界、如何写样本、如何做能力分层。这也是为什么我会觉得agent-skills不是一个小工具而是一种新范式的具体呈现。3. agent-skills的核心结构能力被固化之后模型只是执行者3.1 一个技能包的目录拆解manifest、code、README、样本如果你拿到一个基于agent-skills思路构建的Agent项目它的技能目录结构大概是这样的skills/ ├── web-search/ │ ├── manifest.json │ ├── code/ │ │ ├── search_client.py │ │ └── result_parser.py │ ├── README.md │ └── sample.kts ├──>