企业官网建设流程全解析

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 Calling，Agent能力演进其实一直在补“上下文”的窟窿

回顾一下过去三年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 ├──>