不少从业者已经明显察觉到，2024年AI Agent的热潮逐渐降温后，留下的并非泡沫，而是一系列尚未解决的难题。

最具代表性的场景莫过于：你耗费数天精心调试的AI助手，换一个系统环境就彻底失效了。让它登录企业内部系统，它只会回复“请提供用户名密码”。你输入了，下一轮对话它又忘得一干二净。你撰写了一段提示词指导它处理token刷新，结果在长对话中它开始混淆上下文信息。

问题根源不在于大模型能力不足，而是你的工程化手段未能及时跟进。

行业内近期正在密集探讨一个概念——Skills。OpenAI、Anthropic以及国内多家头部AI企业都在积极布局。有人将其称为“AI的能力插件”，也有人定义为“提示词的工程化封装”。名称并不重要，关键在于：这一机制正在彻底改变AI落地的游戏规则。

今天我们不谈抽象概念，直接动手实践。从一个几乎每个系统都会遇到的场景——登录鉴权入手，完整构建一个Skill。

目录
一、现象：你的AI助手为何连基础登录都无法完成
二、本质变化：能力封装正在替代传统提示词工程
三、核心机制拆解：一个Skill的内部结构究竟如何
四、典型案例对比：有Skill与无Skill的体验差异
五、工程落地启示：现在不做哪些布局将来会后悔
六、结尾：一个绕不开的关键问题

一、现象：你的AI助手为何连基础登录都无法完成

先来看一个真实场景。

你让AI助手查询CRM系统里今天的客户订单。你提供了账号密码，它提示登录成功。接着你问“帮我查看订单A的状态”，它开始胡乱输出，因为实际上它根本没有获取到真实的订单数据，只是假装完成了登录。

你换了一种方法，在提示词中写死了curl命令并附带了cookie。这次能够正常工作了。但切换到测试环境，cookie立即失效。你手动更新了新的cookie，又得重新修改一遍提示词。

更复杂的情况是，系统采用了OAuth2.0认证协议，此时你可能会感到崩溃。

这并不是你一个人遇到的困境。市场上存在大量类似案例：超过30个团队在开发内部AI应用时，都卡在了同一个问题上——AI无法胜任有状态的操作。每一次对话对AI来说都是独立的，它既无法记住上一轮获取的token，也不清楚何时需要刷新。

许多人尝试用提示词来弥补。写了一大段“请牢记你登录后获得的token，后续请求必须在header中添加Authorization: Bearer xxx”。结果token过期了，AI完全不知道发生了什么，只会回复“看起来出现了认证异常，请您重新登录”。

根本原因在于：提示词是静态的，而系统交互本质上是动态的。

二、本质变化：能力封装正在替代传统提示词工程

过去一年，大家的竞争焦点是谁写的提示词更长、更细致、更像代码。有人甚至把提示词写到了两万字，里面包含了“如果遇到403错误，请尝试重新登录”之类的分支逻辑。

这本质上是在用自然语言去模拟编程语言。效率低下，且可靠性不足。LLM对精确逻辑的执行能力天生弱于代码。

Skills的思维方式完全不同：将AI不擅长处理的事情剥离出来，用代码实现，然后为AI提供一个调用入口。

拿登录鉴权来说，核心逻辑是什么？是凭借凭证换取token、是token过期后自动刷新、是处理各种认证异常。这些逻辑用代码编写，三五十行就能实现得很健壮。用提示词来写，写到三千字该出错还是出错。

因此，Skill的本质并非“更好的提示词”，而是为AI挂载了一个可执行的工具函数。AI负责理解用户意图、决定何时调用这个工具、并将调用结果转化为自然语言。工具本身则负责执行精确的操作。

这样一来，AI不需要记住你的token，不需要理解OAuth2.0的授权码流程，也不需要知道如何处理refresh_token。它只需要知道“有一个工具叫login，传给我用户名和密码，我来调用它”。

这就是能力封装对提示词工程的替代：把逻辑还给代码，把理解留给模型。

三、核心机制拆解：一个Skill的内部结构究竟如何

直接上代码结构。一个标准的登录鉴权Skill包含四个组成部分：

入口定义：Skill的名称是什么，需要哪些参数。例如用户名、密码、可选的环境标识。

执行函数：真正执行任务的核心代码。发送登录请求、解析响应、提取token。

状态管理：将获取到的token存储起来，后续请求能够随时调用。同时跟踪记录过期时间。

错误处理：登录失败怎么处理、token过期如何自动续期、网络超时怎样重试。

通过一个流程图，可以清晰了解Skill的工作方式：

核心在于状态存储。很多实现方式把token保存在内存变量中，对话一轮结束就丢失了。正确的做法是将token存储在Skill的上下文中，确保跨对话轮次持久保留。同时还要存储issued_at和expires_in信息，下次调用时先判断是否需要刷新。

另一个关键设计是“静默刷新”。用户发起一个需要认证的请求，Skill发现token还有30秒过期，此时不应该返回“token即将过期请重新登录”，而应该自动使用refresh_token换取新的token。用户完全无感知。

具体实现方式：在Skill内部维护一个ensure_valid_token函数，每次真实请求前先调用它。这个函数检查token状态，如果还有效就直接返回，即将过期就自动刷新，彻底失效了才要求用户重新登录。

四、典型案例对比：有Skill与无Skill的体验差异

用一个实际场景进行对比。假设我们要构建一个AI助手，能够查询公司工单系统里的数据。该系统采用JWT认证，有效期2小时。

没有Skill的做法：

用户在对话中输入账号密码。AI回复“好的，已记录”。接下来每一次查询，AI都要在自己的上下文中翻找之前埋下的token。如果对话太长，token信息被挤出了上下文，AI就会说“请重新提供登录信息”。用户几乎崩溃。

更糟糕的是，2小时后token过期了。AI完全没有过期概念，只会发现请求返回401。它可能会说“看起来系统拒绝了您的请求，可能是权限不足”。用户又得手动解释“因为token过期了，请你重新登录”。

有Skill的做法：

用户说“登录工单系统”，AI自动调用Login Skill并传入参数。Skill发出请求获取JWT，保存下来，同时记录过期时间。AI回复“登录成功”。

2小时后用户问“查询工单#1234”。AI再次调用工单查询的Skill，这个Skill内部先调用Login Skill的ensure_valid_token。Login Skill发现token已过期，自动使用refresh_token换取新token，获取成功后继续执行查询。整个过程用户完全不知道发生了token刷新。

体验差异：前者对话随时可能中断，用户需要理解认证机制。后者用户只需登录一次，后续全部自动化完成。

Skill解决的从来不是“能不能做到”，而是“能否稳定做到、能否让用户无感”。

五、工程落地启示：现在不做哪些布局将来会后悔

第一个启示：别再往提示词里塞逻辑了。

有人甚至把整个状态机的逻辑都写进提示词，用自然语言描述“当前状态是logged_in，下一步如果收到401应该切换到refreshing”。这条路走到黑就是死胡同。LLM不是状态机引擎。

第二个启示：Skill的设计要围绕“失效边界”展开。

在登录鉴权场景中，token会失效、会话会过期、网络会抖动。一个健壮的Skill必须定义清楚：什么情况下自动恢复，什么情况下需要用户介入。自动恢复的部分尽量多，用户介入的部分尽量少。

第三个启示：Skill之间可以相互组合。

登录鉴权Skill不应该孤立存在。更合理的架构是：有一个底层的HTTP请求Skill，它内置了认证能力；其他所有需要联网的Skill都通过它来发送请求。这样登录逻辑只编写一次，所有Skill共享使用。

对于初入行的测试人员来说，这是理解“分层设计”理念的好机会。对于中级工程师，这是重构现有AI应用架构的切入点。

对于在校学生，看懂这个方向，你就明白为什么现在企业招聘的是“AI工程化”岗位，而不是“提示词工程师”。

六、结尾：一个绕不开的关键问题

上面讲述的这套方案，用不到200行代码就能实现一个可用的版本。

但有一个问题值得深入思考，今天抛出来：

当Skill数量越来越多（几十个甚至上百个），AI如何准确判断用户意图对应哪个Skill？尤其是当多个Skill的输入参数和功能描述高度相似时，仅靠提示词里的描述来区分，边界究竟在哪里？

你现在的团队里，如果有人提出了一个“做一个万能登录Skill”的需求，你会如何判断这个Skill的职责边界？是做一个通用的支持所有认证协议的Super Skill，还是拆分为BasicAuthSkill、OAuthSkill、JwtSkill各自独立？