为什么你的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 做不到这一点。观点句 1Prompt 是说明书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 拿到测试报告文件自己读内容自己用正则匹配通过失败自己猜哪些是严重崩溃。每次都要重新理解格式、重新计算、重新推理。报告格式一变整个流程就崩。有了 SkillAgent 只需要知道“什么时候该调用分析报告”具体怎么分析是 Skill 内部的事情。观点句 2Function 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