很多人已经开始感觉到，2024年AI Agent的热潮退去之后，剩下的不是泡沫，而是一地没解决的问题。
最典型的一个场景：你花了三天时间调教出来的AI助手，换个系统就废了。让它登录一下企业内部系统，它说“请提供用户名密码”。你给了，下一次对话它又忘了。你写了一段提示词告诉它怎么处理token刷新，它在长对话里开始混淆上下文。
这不是大模型不行，是你的工程化手段没跟上。
行业里最近在密集讨论一个东西——Skills。OpenAI、Anthropic、国内几家头部AI公司都在推。有人把它叫“AI的能力插件”，有人说是“提示词的工程化封装”。叫什么不重要，重要的是：这个东西正在改变AI落地的游戏规则。
今天不聊概念，直接动手。从一个几乎所有系统都绕不开的场景——登录鉴权，把Skill从0到1做出来。
目录
一、现象：你的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换新的。用户无感知。
怎么做：在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各自独立？
