为什么你的AI Agent像个傻子？因为你没给它装“Skill”

今年刚开年，AI Agent的热度又上来了。

Cursor 让不少人觉得编程要变天，Claude Code 被捧成“最强打工人”，OpenClaw 这类开源项目更是让动手能力强的人直接开始折腾自动化。

但身边真正用起来的人，最近普遍开始烦躁。

让 Agent 跑个测试用例，它在登录页卡了二十分钟。让它分析一份日志，它把时间戳当成错误码。让它修复一个已知 bug，它改了三轮，每一轮都引入新问题。

很多人已经开始感觉到：AI Agent 演示的时候像天才，一到真实任务就像个只会复读的傻子。

不是模型不行。是你压根没教它怎么干活。

目录

• 一、AI Agent 正在批量翻车：能聊不能干，是当前最大瓶颈
• 二、本质变化：Prompt 解决不了执行问题，缺的是能力单元
• 三、核心机制拆解：Skill 到底是什么，跟 Function Call 有什么不同
• 四、典型案例对比：一个登录场景，两种结果
• 五、工程落地启示：测试团队现在就能做的三件事
  
  

一、AI Agent 正在批量翻车：能聊不能干，是当前最大瓶颈

先说几个真实翻车现场。

某测试团队用 Cursor 辅助写自动化脚本。需求很简单：“从 Jira 拉取今天修复的 bug 编号，到测试环境验证，把结果贴回 Jira”。

Cursor 生成的代码看起来挺完整。跑起来才发现：它不知道 Jira 的字段映射规则，不知道测试环境的数据库密码存在哪个密钥服务里，更不知道验证失败后应该在 Jira 评论里@谁。

另一个案例来自 OpenClaw 的讨论群。有人想让它自动登录公司后台，指令是“用测试账号登录，然后截图”。Agent 打开页面、输入账号密码、点击登录，然后卡住了——验证码图片它识别不了，等了三秒就以为登录失败，直接 abort。

Claude Code 也类似。你让它“检查代码里所有未捕获的异常”，它会认真扫一遍，把 try-catch 缺失的地方列出来。但你要它“顺便把修复 PR 发到团队群里”，它就懵了，因为它不知道你们用飞书还是钉钉，不知道 webhook 地址在哪。

这些问题的表象各不相同。本质只有一个：Agent 手里只有一张嘴，没有手，没有工具包，没有操作手册。

当前主流 AI Agent 产品，核心能力集中在“理解意图”和“生成文本”。完成一个真实任务，需要的是可执行、可复用、可组合的操作单元。

这就是为什么你感觉它在聊天的场景很聪明，一动手就变傻。

二、本质变化：Prompt 解决不了执行问题，缺的是能力单元

很多人还在用 Prompt 工程的思路做 Agent。

写好一段系统提示词：“你是资深测试工程师，遵循以下步骤执行回归测试……”然后期待 Agent 自己搞定一切。

这个思路有一个根本性缺陷：LLM 是语言模型，不是操作系统的内核。

它可以告诉你“应该先登录再查询”，但面对一个动态验证码、一个偶尔超时的 API、一个需要滑动解锁的按钮，LLM 的纯文本推理能力完全不够用。

真实世界的任务执行，依赖的是确定性的、可复用的、经过验证的操作流程，而不是每次让模型重新推理一遍。

Prompt 是说明书，Skill 是手和脚。

说明书告诉你“拧开螺丝”。Skill 知道螺丝刀在哪个抽屉、顺时针拧三圈半、遇到滑丝怎么处理、拧完要不要做力矩标记。

放到技术架构里看，Skill 的本质是把一系列原子操作封装成一个能力单元。这个单元对外暴露清晰的输入输出，对内包含确定性的执行逻辑、错误处理、重试机制、日志上报。

Agent 要做的事情变得非常简单：在合适的场景下，决定调用哪个 Skill，然后把 Skill 的执行结果返回给用户或者继续下一步。

这个设计解决了三个核心问题：

可靠性：Skill 内部是确定性逻辑，不会像 LLM 那样每次输出都飘。可复用性：写好的登录 Skill，所有需要登录的场景都能直接用。可观测性：Skill 的执行过程可以打日志、埋点、做异常监控，Prompt 做不到这一点。

观点句 1：Prompt 是说明书，Skill 是手和脚。你给 Agent 只装说明书，它当然干不了活。

三、核心机制拆解：Skill 到底是什么，跟 Function Call 有什么不同

先做一个技术概念的区分。

Function Call 是模型调用外部函数的能力。你给模型定义一堆函数签名，模型根据用户意图决定调用哪个。但 Function Call 本身不包含执行逻辑，真正的实现代码需要你自己写。

MCP 是模型和外部工具之间的通信协议。它解决了“模型怎么发现工具”“怎么传递参数”“怎么获取结果”这些标准化问题。

Skill 是在这之上的能力封装层，面向任务而非函数。

一个完整的 Skill 包含三个部分：

定义层：Skill 的名称、描述、输入参数格式、输出格式。这部分给 LLM 看，让它知道什么时候该调用这个 Skill。

执行层：具体的操作逻辑。可以是代码、脚本、API 调用、工作流编排。这部分是确定性的，不走模型。

反馈层：执行结果、错误码、状态变更、结构化数据。这部分返回给 LLM，作为下一步决策的依据。

看一个具体例子。你要封装一个“分析测试报告”的 Skill。

定义层告诉模型：这个 Skill 接收一个测试结果文件路径（JSON 或 XML），输出通过率、失败用例列表、前三的崩溃堆栈。

执行层写 Python 脚本，解析 JUnit XML，计算指标，过滤 flaky 用例。

反馈层把结果格式化成 JSON，同时附加一个字段 has_critical_failure。

Agent 调用这个 Skill 的流程：

没有 Skill 的情况下，Agent 拿到测试报告文件，自己读内容，自己用正则匹配通过失败，自己猜哪些是严重崩溃。每次都要重新理解格式、重新计算、重新推理。报告格式一变，整个流程就崩。

有了 Skill，Agent 只需要知道“什么时候该调用分析报告”，具体怎么分析是 Skill 内部的事情。

观点句 2：Function Call 是函数，Skill 是能力。函数解决“怎么调用”，能力解决“怎么把事情干成”。

四、典型案例对比：一个登录场景，两种结果

拿最经典的登录场景做对比。这个场景测试同学每天都要面对。

没有 Skill 的 Agent

你告诉它：“用测试账号 test_user/pass123 登录系统，如果遇到验证码就等待 5 秒，登录成功后截图。”

Agent 的理解是：打开页面 → 输入账号密码 → 看有没有验证码 → 有就等 5 秒 → 截图。

但它不知道：你们系统的验证码是滑块还是图形验证码。等待 5 秒够不够（实际需要 8-15 秒）。截图是全屏还是只截错误区域。登录成功后要不要等页面完全加载再截。

结果往往是：遇到滑块验证码直接卡死。或者等了 5 秒验证码还没出现就放弃。或者截了一张白屏图。

装了 Skill 的 Agent

你先封装三个 Skill。

Skill A：通用登录。输入账号密码，输出登录状态和 session token。内部处理了滑块验证码（调用 OCR + 模拟拖拽）、动态等待（轮询页面状态）、重试（遇到网络抖动自动重试 3 次）。

Skill B：环境检测。判断当前是测试环境、预发还是生产，自动切换对应的认证方式。

Skill C：智能截图。输入截图类型（全屏/视口/元素），输出图片路径。内部做了等待页面稳定、高亮错误元素、自动打时间戳。

Agent 的逻辑变成：

调用 Skill A 登录 → 拿到 session token → 调用 Skill C 截图（全屏）→ 返回结果。

如果登录失败，Skill A 会自动重试并记录失败原因（验证码错误/账号锁定/网络超时）。Agent 只需要把失败原因告诉用户。

这个模式在 OpenClaw、Claude Code 的插件系统、LangChain 的 Tool 封装里都能看到。叫法不同，核心思想一致：把能力拆成可独立测试、独立版本管理的单元。

观点句 3：一个 Skill 解决一个问题，一百个 Skill 解决一类岗位。Agent 的核心竞争力，不是模型多大，而是 Skill 多全。

五、工程落地启示：测试团队现在就能做的三件事

不扯概念，说三个马上能做的事。

第一，盘点你每天重复的“手工作业”

打开你的终端，看看历史命令。cd 到某个目录、执行某个脚本、解析某个日志、发一条消息到群里。

凡是做过五次以上的操作，都值得封装成 Skill。

标准很简单：输入输出清晰、步骤固定、不需要每次重新思考。比如“拉取昨天失败的用例”“重新部署测试环境”“把测试报告发到飞书群”。

第二，设计 Skill 的三层结构

不要只写一个函数就完事。

定义层要给 LLM 清晰的触发条件。写清楚“当用户提到登录失败分析时调用此 Skill”，而不是模糊的“处理登录问题”。

执行层要带完整的错误处理。网络超时怎么办、文件不存在怎么办、权限不足怎么办。把这些分支写死在代码里，不要指望 LLM 临场发挥。

反馈层要返回结构化数据，而不是自然语言。固定格式的 JSON，包含 status、data、error_code、message。Agent 解析这个 JSON 做决策，稳定性会提升一个数量级。

第三，为 Skill 写单元测试

这一点经常被忽略。

你给 Agent 写的 Prompt 没法自动化测试，但 Skill 可以。因为 Skill 是确定性代码。

写测试用例，验证 Skill 在正常输入、边界输入、错误输入下的行为。Skill 稳定了，Agent 的整体表现就稳定了八成。

一个工程实践：把 Skill 单独放在一个目录，用 CI 跑测试。Skill 版本和 Agent 配置解耦，可以独立升级、回滚、A/B 测试。

Claude Code 的插件机制越来越像 Skill 市场。用户上传的插件本质就是 Skill。

Cursor 的自定义指令和 Rules，雏形也是 Skill。

OpenClaw 已经把 Tool 系统作为核心设计，最新的版本里 Tool 可以依赖其他 Tool，形成能力组合。

更关键的是行业需求的变化。去年大家都在问“哪个 Agent 最强”，今年问的是“怎么让 Agent 在我们业务里跑通”。

模型能力的差距在缩小。GPT-4 和 Claude 3.5 到 Claude 4 再到其他竞品，说实话日常使用体感差距没那么大。但工程化能力的差距在急剧拉大。

谁能更快地把业务知识、操作流程、领域经验沉淀成可复用的 Skill，谁就能在 Agent 落地这件事上跑在前面。

Skill 不是新概念。Plugin、Tool、Action、Skill，叫法不同，底层逻辑一样：把 LLM 不擅长的确定性执行剥离出去，让模型专注做它最擅长的推理和决策。

这件事迟早会成为标配。就像三年前没人知道 Prompt Engineering，现在已经是基本功。再过一年，不会设计和封装 Skill 的 Agent 开发者，会像今天只会写 SQL 不会建索引的 DBA 一样被动。

最后一个问题，留给你自己判断：

你现在的测试流程里，有哪些重复了三遍以上的操作，还没被封装成 Skill？