1. 为什么一线团队开始把 Agent 能力拆成 Skills这段时间和不少做 AI 应用的朋友交流大家都有一个共同的感受单纯堆一个 Chatbot 的时代基本过去了。现在比的是谁能更快把大模型能力嫁接到真实业务里而“嫁接”的关键往往不在模型本身而在你给模型配了什么工具、写了什么流程、挂了什么知识。这也是这段时间“Agent”和“Skills”这两个词频繁出现在技术社区的原因。先说清楚一个容易混淆的概念Skill 和 Agent 不是一回事但它们天生是一对。Agent 是那个能感知、能决策、能执行的整体系统它负责理解用户意图、拆解任务、调动资源Skill 则是 Agent 可以调用的具体能力单元相当于给 Agent 配的一把把专用工具。简单类比的话Agent 像一个全能型员工Skills 就是这位员工桌面上的各种专业软件——没有软件的员工只能空谈没有员工的软件没人操作。所以一个可落地的 Agent 项目核心工作往往不是调模型而是设计一组合适的 Skills。腾讯云 AI Skills 平台走的正是这条路子。它把“提示词 工作流 工具调用 知识挂载”整合成标准化的 Skills 单元让开发者可以直接在平台上定义、调试、发布自己的技能再把这些技能挂给前端应用、机器人或自动化流程。相比从零搭一套 Agent 框架这套方案把大量工程细节比如模型路由、上下文管理、函数调用格式、鉴权与限流收敛到平台层你只需要集中精力写好技能本身。这篇文章就围绕“全能 Agent 养成”这条主线把我这段时间在腾讯云 AI Skills 上从零搭起一个可用 Agent 的完整过程拆开来讲。从环境准备、Skills 文件格式设计到具体开发一个“生产提效类”技能再到上传部署、线上监控与迭代每个环节都会给出可复现的步骤和配置。适合两类人看一类是刚接触 Agent 开发、想找一个低门槛切入点的初学者另一类是在多家云平台上比较过、想知道腾讯云这套 Skills 机制到底怎么玩的老手。2. 动手前的三个决定模型选型、Agent 架构和 Skills 边界开始写代码之前有三个决定会影响后面所有步骤我建议先花时间想清楚。2.1 选哪个模型作为 Agent 的“大脑”Agent 的推理能力直接决定 Skill 调用质量。腾讯云 AI Skills 平台本身是模型无关的可以在一个 Agent 里配置多个模型让不同的 Skill 走不同的模型。我实测下来的经验是复杂多步推理任务比如“根据用户需求生成一份部署方案并检查可行性”用推理强一点的模型简单抽取任务比如“从工单文本里提取设备编号”用小模型就够省成本也降延迟。具体选型时可以参考这个分类任务类型推荐模型定位原因多步推理、工具调度、方案生成旗舰/推理增强模型工具调用的格式遵循能力和多步规划能力更强文本抽取、分类、格式化标准/轻量模型响应快、成本低指令遵循足够用长文档理解、知识库问答支持长上下文或带 RAG 的模型减少切片丢失信息检索质量更高平台支持按 Skill 粒度做模型路由所以不要只配一个模型。我在实际项目中就是“旗舰模型负责调度和方案生成轻量模型负责字段抽取”的搭配整体成本下降了大概四成准确率没有明显回落。2.2 Agent 架构编排式比对话式更稳很多第一次做 Agent 的朋友容易掉进一个陷阱想做一个全开放对话式的 Agent希望模型自己决定调什么、不调什么。理论上很美实际很容易失控——模型可能调错技能、漏传参数、或者在多个技能之间反复横跳。我更推荐编排式架构。就是说Agent 的任务入口是一个明确的流程定义每个节点对应一个 Skill节点之间的流转由预定义的规则或者轻量判断条件控制模型只负责在节点内部做理解和生成。举个例子我做的“工单智能助手”流程是这样入口节点识别用户输入类型报障 / 查询 / 申请分类后进入对应 Skill报障走“故障信息抽取 解决方案检索”查询走“知识库问答”申请走“表单生成 审批人匹配”每个 Skill 输出结构化结果最后由一个汇总节点拼装回复这样设计的好处是每个 Skill 的职责单一调试起来非常方便某个环节出了问题直接替换那个 Skill 就行不需要把整个 Agent 推倒重来。2.3 Skills 的粒度怎么切Skills 不是越细越好也不是越粗越好。我总结了一个“完成一个可验收动作”的原则——一个 Skill 至少要做完一件能被用户或下游系统验收的事。比如“提取工单关键信息”可以是一个 Skill“生成周报草稿”也可以是一个 Skill但“调用大模型”不是 Skill“连接数据库”也不是 Skill这些是实现细节应该藏在 Skill 内部。切分过细会导致 Agent 的调度负担变重模型要在大量 Skill 里做选择反而容易出错切分过粗Skill 变成一个大杂烩没法复用和单独调优。我的经验是先列出所有想要的能力然后归并成 58 个一级 Skill每个 Skill 内部再通过工具调用来完成子任务。这个粒度在“开发复杂度”和“调度准确性”之间是比较平衡的。3. Skills 开发全流程拆解从 SKILL.md 到工作流编排腾讯云 AI Skills 的核心承载体是一个结构化的技能定义最上层就是 SKILL.md 文件。这个文件是整个技能的“说明书”平台解析了它才知道怎么调你的技能。3.1 SKILL.md一份能被模型读懂的能力声明SKILL.md 的质量直接决定 Skill 被调用的准确率。它不是写给人看的文档更像是写给“模型调度器”看的接口声明。我刚开始做的时候随便写了一句“用于处理客户问题”结果 Agent 经常把这个 Skill 用于各种奇怪场景后来才意识到描述必须精确到什么情况下用、用什么输入、产出什么格式。这是我经过多轮迭代后总结的一个 SKILL.md 基础模板各位可以直接参考--- name: work_order_assistant description: 用于处理售后服务工单。当用户提供设备故障描述、报修信息或工单编号时调用本技能完成故障分类、信息抽取、解决方案推荐。不适用于销售咨询、产品推荐类问题。 version: 1.0.0 author: your_team tags: - 售后服务 - 工单 - 故障处理 --- # 工单处理助理 ## 功能概述 本技能接收用户的原始工单文本输出结构化的故障信息 JSON并给出推荐解决方案。 ## 输入参数 - work_order_text: 字符串用户的原始故障描述 - device_model: 字符串可选的设备型号不传则从文本中抽取 ## 输出格式 { category: hardware|software|network|other, device_model: string, fault_code: string, solution_list: [string] } ## 调用规则 1. 当输入文本包含设备故障、异常、报错信息时调用 2. 当用户提供工单号且附带故障描述时调用 3. 当用户询问非故障类售后问题时不要调用本技能注意 description 里明确写了“不适用于什么”这个负向约束非常管用能明显减少误调用。3.2 工作流编排把技能内部拆成可调度的节点SKILL.md 声明了技能的对外接口但技能内部怎么执行就需要工作流编排了。腾讯云 AI Skills 支持两种编排方式一种是在控制台上用可视化节点拖拽配置另一种是直接编辑 YAML/JSON 定义工作流。我日常工作流较长时习惯用代码编辑短流程用可视化拖拽更快。一个典型的工作流节点序列大概是输入校验节点检查 work_order_text 是否为空信息抽取节点调用模型输出结构化 JSON这里是 Skills 里最常见的用法——让模型按 JSON Schema 抽取条件判断节点如果 category 为 hardware走“硬件故障方案库检索”否则走“通用方案生成”方案检索节点连接知识库或预设 FAQ 表召回 Top3 方案输出编排节点把结果组装成统一回复结构每个节点可以定义自己的模型参数、工具调用和错误处理策略。这里的核心思路是复杂任务不要靠“让模型一口气想出来”而是拆成多个简单节点每个节点只做一件确定的事最后用代码逻辑而不是模型自由发挥来控制流程走向。3.3 工具调用与知识挂载让 Skill 具备“动手能力”真正让 Skill 从玩具变成生产力工具的是它能调外部工具。我在腾讯云上最常用的三类工具HTTP API 调用比如查订单状态、提交审批流、写企业微信消息数据库/对象存储访问读取历史工单、存储生成结果知识库检索挂载产品的 FAQ、操作手册、故障案例库工具定义时最重要的是输入输出 Schema 的准确度。每一个字段都要写清楚枚举值、格式、是否必填。模型根据这个 Schema 来决定传什么参数Schema 模糊的话模型就只能靠猜。知识挂载这块我强烈建议做“按 Skill 隔离的知识空间”不要所有 Skill 共享一个大知识库。因为不同技能的检索语义差别很大混在一个库里会导致召回结果不相关。例如工单技能挂“故障案例库”方案生成技能挂“产品文档库”各挂各的检索准确率会高很多。4. 实战开发一个“前端变更影响分析” Skills理论讲完上实操。这次我从零开发一个专门给前端团队用的 Skill名字叫“前端变更影响分析”。场景是这样前端项目每次发版前需要判断改动会影响哪些页面、哪些接口、哪些下游系统。以前这个分析靠老开发凭经验费时且容易漏。现在把它做成 Agent 技能让模型结合代码变更和项目结构图来输出影响面报告。4.1 定义输入输出和准备工作这个 Skill 的输入是一个 Git Diff 文本限制在两万字符内输出是一份结构化影响分析报告包含变更文件名清单涉及的组件/路由可能受影响的页面 URL对应调用的后端接口风险等级高/中/低建议回归测试范围准备工作需要三样东西项目结构数据把项目的文件树和路由表转成 JSON 文件API 映射表前端页面 - 调用接口的映射关系数据一份模型 Prompt 模板告诉模型怎么根据 Diff 做推理这些材料作为知识文件挂载到 Skill 里不需要每次传入。4.2 设计核心 Prompt 模板Prompt 是 Skill 的灵魂。我写 Prompt 的习惯是“递给模型一份检查清单而不是一个开放问题”。下面这份模板经过多轮修改效果比较稳定你是一个资深前端架构师。我将给你一份代码变更的 Git Diff以及项目结构、路由表和 API 映射表。请基于这些资料完成影响面分析。 分析要求 1. 从 Diff 中提取所有修改、新增、删除文件的路径。 2. 结合项目结构判断每个文件属于哪个业务模块、哪个页面。 3. 结合路由表判断哪些页面路由会受这些文件变化影响。 4. 结合 API 映射表找出受影响页面所调用的后端接口。 5. 根据改动范围和控制流影响给出风险等级 - 高风险涉及公共组件、全局状态、路由配置、公共 API 封装 - 中风险涉及单个页面的核心逻辑 - 低风险只涉及样式、文案、静态资源 输出必须是严格 JSON格式如下 { changed_files: [], affected_pages: [], affected_apis: [], risk_level: high|medium|low, suggested_tests: [] }这段 Prompt 的关键是给了模型足够的上下文项目结构、路由表、API 映射又用明确的判断规则约束了输出边界。我试过不给规则让模型自由分析结果它把“风险等级”完全猜反了参考价值很低。4.3 配置工作流节点这个 Skill 的工作流分成四步第一步输入校验。判断 Diff 是否为空字符数是否超限超限就截断或提示用户分段提交。第二步调用模型做初步分析。这一步用前面设计的 Prompt模型返回一个 JSON但此时的结果还包含噪声比如把测试文件误判为业务文件、把样式修改当成高危险变更。第三步后处理脚本。写一段 Node.js 脚本做数据清洗过滤掉 test/、mock/、assets/ 目录下的文件把 affected_pages 里的路径做归一化/user/profile 和 /user/profile/ 合并去掉重复项。这个脚本是平台的“代码节点”能直接跑非常实用。第四步输出报告生成。把清洗后的数据拼成一份 Markdown 报告带上可读性更好的说明文字发给用户。这里要说一下第三步有多重要。纯靠模型输出的 JSON字段不稳定的情况很常见同一份 Diff 跑两次可能得到不同结果。加了一层确定性的后处理代码之后输出格式就稳定多了。我的经验是AI 能做的让 AI 做但所有“确定性要求高”的操作一定用代码兜底。4.4 调试中的真实问题和解决记录这个 Skill 上线前后踩过几个坑列出来给大家避雷问题一模型不理解“路由表”的含义导致影响页面判断错误。解决方式在知识文件里把路由表的说明写清楚比如“这是 React Router 的配置对象path 字段为页面路由component 字段为对应组件文件名”并提供两到三行示例。问题二一个 Diff 里包含多个前端模块的改动时模型容易漏模块。解决方式Prompt 里显式加入“请逐个文件分析不要跳过”的指令并把分析步骤编号写死。问题三接口映射表太大几千行导致模型上下文不够用。解决方式预先用脚本按“被修改组件名”过滤映射表只把与改动相关的几行传给模型而不是全量传。这三个问题其实反映出一个共性规律Skill 开发像一个“把模型不擅长的事情用工程手段补掉”的过程。模型擅长的是理解自然语言和做粗略推理但精确的关联查找、大规模数据过滤、格式稳定输出都应该让代码或规则去完成。5. 部署上线把 Agent 真正挂到腾讯云上跑起来本地调试通过之后就要把 Skill 发布到腾讯云并和 Agent 组装上线。这个过程有几个关键节点配错了后面返工很麻烦。5.1 创建并配置腾讯云侧的 AI Skills登录腾讯云控制台后在 AI 相关产品里找到 Skills 服务创建一个新技能。创建时会让你选择“从模板导入”还是“空白创建”。我建议第一次从空白创建并手动贴入 SKILL.md 内容因为模板自带的字段可能和自己的业务不完全匹配改起来反而费劲。填好基础信息后在“工具”页面把外部 API 连接配上。这一步需要填 API 的地址、请求方式、Headers比如鉴权 Token和入参出参的定义。腾讯云支持用一个“API 连接器”统一管理这些外部接口建议把所有依赖的接口先注册到连接器里这样 Skill 里引用时只需选择连接器和方法不用到处写 URL。5.2 部署为可调用的独立服务 or 挂到 Agent 编排腾讯云 AI Skills 支持两种对外形态形态适用场景说明独立服务作为 HTTP 接口被外部应用直接调用每个 Skill 自动生成一个调用端点可以配合网关做鉴权Agent 内嵌作为能力单元挂到某个 Agent 上由 Agent 统一接收用户请求并调度多个 Skill我通常的做法是先用“独立服务”模式发布 Skill拿到稳定的调用地址后再把这个地址填到 Agent 的技能列表里。这样做的好处是 Skill 可以单独做自动化测试不用每次都在 Agent 里层层点进去调试。发布时有一个参数要特别注意超时时间。大模型推理加后处理脚本耗时可能会超过默认的几秒限制。我建议把超时设置为 3060 秒而不是调小否则容易出现“模型还没跑完就判定失败”的假故障。5.3 开放安全访问的三种方式在配置 Skill 对外服务的时候一定会遇到“如何让别人安全地调用它”的问题。结合腾讯云的常用做法有三级方案最基础把服务设定为私密访问只在腾讯云 VPC 内网调用适合后端到后端的场景。进阶给独立服务绑定 API 网关通过网关的密钥鉴权和应用鉴权来控制调用者身份。这种方式适合要暴露给外部合作方使用的场景。高阶在网关层再加一层自定义插件比如把当前登录用户的身份信息转换为自定义请求头传给 Skill让 Skill 内部的逻辑能感知到调用者是谁实现细粒度的权限控制。我的建议是即使目前只是在测试也至少加上一层最简单的密钥鉴权。因为 Skill 调用会产生模型费用不做任何鉴权等于裸奔被扫到之后可能一夜之间被刷爆。5.4 一次上线时遇到的坑跨域与参数丢失我上线“前端变更影响分析”时遇到一个很典型的坑从前端浏览器直接调用 Skill 的独立服务报跨域错误用 Postman 测试却一切正常。排查链路是这样的先怀疑是 Skill 服务本身没开跨域检查腾讯云的配置发现独立服务的域名默认不支持跨域请求需要在 API 网关层配置 CORS 响应头。但光加了 CORS 还不够浏览器预检请求OPTIONS会直接把请求拦截在网关层面还需要在网关的“跨域设置”里显式允许预检。另一个坑是前端调用时如果请求头里带了自定义字段比如 X-User-ID而网关的“允许头”列表里没配上网关会直接丢弃这个头Skill 收到的请求里就取不到用户身份参数。这个问题排查了很久最后把允许头配成匹配符才解决。所以建议凡是遇到“本地测试正常、线上调用异常”的问题先检查网关层的配置而不是急着改 Skill 代码。这类问题八成出在网关的安全策略或参数透传上。6. 线上运营从“能跑”到“好用”的监控与迭代Skill 上线只是开始真正花时间的是上线后的调优和迭代。这个阶段我开始给“全能 Agent”加更多花样让它从“能用”变成“好用”。6.1 日志排查方法论先看调用链再定位环节腾讯云控制台为每个 Skill 请求都会生成一条完整的调用日志记录从收到请求、模型推理、工具调用到返回结果的全过程。遇到问题时我的排查思路分三层第一层看请求和响应摘要判断是不是输入本身的问题比如传了空文本、参数类型不对。第二层看模型推理日志判断模型是否理解了 Skill 描述、有没有错误地跳过工具。第三层看工具调用记录判断外部 API 是否正常返回、后处理脚本有没有报错。这套方法论可以用一个原则概括永远先定位是“哪个环节出的问题”而不是“整个 Skill 出了什么问题”。因为 Skill 内部有多个节点一次失败可能由完全不同的原因造成笼统地看待问题只会让排查效率变得很低。6.2 多版本管理与灰度发布腾讯云 AI Skills 支持保存不同版本这让我可以放心的“改一版上线一版”而不用怕搞砸线上的稳定版本。我的版本管理习惯是小改动比如 Prompt 里加一句约束直接复制当前版本改成 v1.1跑测试集看效果通过后切流量。大改动比如重写工作流节点开一个 v2.0 分支在测试环境完整验证后再发布。灰度发布也很关键。比如“前端变更影响分析”这个 Skill我上线新版后会先切 10% 的流量过去对比新旧版本的输出质量。对比维度包括JSON 解析成功率、用户主动评分如果有的话、关键字段的命中率。确认新版本稳定后才逐步放量到 100%。6.3 Prompt 回归测试防止“改好一个 bug 带崩一片功能”这里要特别提醒一个容易犯的错误经常调整 Prompt 是好事但每次调整都可能影响其他场景的效果。如果没有回归测试机制很可能修了“前端变更影响分析”的误报问题结果把另一个正常场景给改崩了。我现在会给每个 Skill 准备一份固定的测试集大概 2050 条输入覆盖正常场景、边界场景和典型异常场景。每次改完 Prompt 或工作流后先在测试集上批量跑一遍看输出格式是否仍然合法、关键字段是否仍然命中。这一步虽然耗时但长期看回报非常明显——它能避免很多线上事故。6.4 Agent 的横向扩展多 Skill 协同的玩法当基础的“前端变更影响分析”稳定后我开始围绕它搭建更完整的技能矩阵让 Agent 变得真正“全能”变更影响分析已上线输入 Diff输出影响报告接口变更通知监测接口文档变动自动生成受影响的前端页面清单发布检查清单生成根据影响报告自动生成发版前的回归测试项周报摘要器汇总一周的变更分析和发布记录生成项目周报这四个 Skill 各自独立但又通过统一的输出格式形成上下游关系。比如“变更影响分析”的输出可以作为“发布检查清单生成”的输入这其实就是把多个 Skill 串成了一条流水线。这种“小 Skill 复用 编排串联”的方式比做一个包罗万象的超级 Agent 要靠谱得多。7. 几条关于腾讯云 AI Skills 的实在建议写了这么多最后分享几条我觉得最有价值的经验总结供大家参考。第一Skills 的“文件质量”决定了 Agent 的天花板。SKILL.md 里的 description 写得越精确、负向约束越明确模型调度就越不容易出错。不要嫌写描述费时间——这个文件值得反复打磨。第二工作流里要刻意设计“确定性兜底”。凡是必须保证格式正确、字段稳定的地方尽量用代码节点去处理不要让模型自由发挥。尤其注意纯靠模型输出 JSON 时字段缺失和类型漂移是常态一定要做 schema 校验。第三模型成本是可以靠 Skills 设计省下来的。把一个大型 Skill 拆成多个子 Skill 后可以让简单子任务走便宜的模型只把复杂推理留在旗舰模型上。腾讯云平台支持按 Skill 配模型这个能力建议所有人都用起来。第四关注一下 Agent 社区里其他开发者公开的 Skills 文件作为设计参考学会“站在别人肩膀上”。不一定非要自己从零想一套技能结构看看“结构图 skills”“测试用例 skills”这些开源类的设计思路能帮你更快找到自己业务的切分灵感。第五合理看待“上传”和“部署”这些环节的工程配置。域名解析、网关策略、鉴权这些基础设施虽然看起来枯燥但未来的稳定运行全都依赖它们。前期花十分钟配好的安全策略能省下后面无数个加班的夜晚。最后说一句实际体会做 Agent 做到后面会发现模型能力大家都有最后的差距全在 Skills 设计和对业务的理解深度上。腾讯云 AI Skills 的价值是帮你把零零散散的想法快速变成一个能线上提供服务的技能闭环。带着这套方法回去选一个你业务里最繁琐、最有规律可循的场景从写第一份 SKILL.md 开始很快就能看到实际收益。