1. 先把一个概念掰开Agent 是调度者AI Skills 才是底气“全能 Agent”听起来很唬人但真拿一个模型 API 去跑复杂任务你会发现模型再聪明没有一摞趁手的 AI Skills它就是个空有文凭的新员工。纸上谈兵头头是道一落到信息检索、文件解析、固定格式输出、多步工具操作就开始自由发挥结果每次都不一样。这段时间我在腾讯云上反复折腾 Agent最终把重心从“调更好的模型”转移到“写更好的 AI Skills”项目才真正跑起来。这篇腾讯云 AI Skills 最佳实践就是我把一个宣传意义上的“全能 Agent”从演示 Demo 养成到能稳定承接真实任务的全过程记录。1.1 为什么我把重心放在 AI Skills 上刚接触 Agent 开发那阵我以为只要把 OpenAI 风格的 function calling 接上再丢给一个强大的大模型什么问题都能解决。实际跑下来发现模型解决问题靠的是“临场推理”它从来不会觉得累但会把同一个操作做出几个版本。比如让它做“今日热点汇总”第一次是抓取网络信息再总结第二次可能就凭训练数据里的旧闻编了一篇。问题不在模型笨而在于我把太多不该让它自由发挥的环节全部交给了它自己。AI Skills 的定位就是把这个局面翻过来。所谓 Skill不是一个函数也不是一段提示词而是“能被 Agent 识别、按统一契约调用、返回可解析结果”的一组能力包。它强调从 Agent 视角出发技能叫什么、什么时候用、需要什么入参、输出什么结构、失败怎么表现都要描述清楚。你可以把它理解成给 Agent 配了一排专用工具箱模型负责决定“当前用哪个工具、怎么用”但执行和产出标准由工具本身保证。我后来在腾讯云上重新梳理了一套技能层把“网页抓取、正文提取、知识库检索、风格改写、标题生成、图片素材收集”等动作做成独立 Skills。效果立刻不一样原来一个 30 分钟还会出错的任务拆成几步后误差点被锁在每个技能内部外层 Agent 只需要判断调用顺序。真正让我意识到问题的是某次部署后统计结果不拆技能时模型输出格式错误率可能高达 20%拆成 Skills 后直接降到 3% 以内。这份可靠性的提升比换更强模型来得更快。1.2 腾讯云 AI Skills 和传统后端服务差在哪这个问题很多朋友问过我直接在腾讯云上写个云函数再暴露一个 HTTP 接口不就是 Skill 吗从执行角度看确实很像但从“模型能不能正确使用”的角度看还差着一大截。传统后端服务的调用方是前端或定时任务参数怎么传、响应结构在哪里代码里写死就行。AI Skills 的调用方是大模型模型不会去读你的接口文档它只能看到你在 Schema 里写的那段 description。举个例子你做一个“网页正文提取”服务传统接口可能会叫/api/v1/extract前端代码里 type 写死就行。但作为 AI Skill你必须让模型在遇到“帮我看看这篇文章讲了什么”这句话时能意识到要调用这个接口。如果技能的 description 只写“网页正文提取”模型可能根本想不到用它。你得写成“当用户提供文章 URL、或希望获取某个网页正文内容时调用此技能返回纯文本正文”。这看起来像文字游戏却决定了模型是否会真正调用。腾讯云上最适合承接 AI Skills 的形态目前我主要用三类云函数 SCF 处理轻量原子技能对象存储 COS 保存中间文件和大块素材日志服务 CLS 把每次技能调用过程串起来。SCF 的优势是天然支持事件触发和 API 网关集成单个技能就是一个函数能做到按调用计费冷启动也能靠配置平滑处理。相比传统后端它还少了“我要养一台服务器专门跑一个抓网页脚本”的心理负担。说到底传统服务和 AI Skills 核心差异有三点第一技能描述写给人看还是写给模型看第二返回结构是否做到稳定 JSON让模型和下游流程都能直接消费第三有没有把版本、超时、错误码、观测日志这些“可运维属性”考虑到技能生命周期里。把这三点想明白再往腾讯云上写后面不管 Agent 框架怎么换技能层都可以稳定复用。2. 动手前先这样规划腾讯云资源从账号准备到第一个技能发布2.1 云上资源别乱开先按能力地图选服务不少新手一上来就说“我要全栈上云”结果把云函数、容器、数据库、消息队列全开通账单翻了倍绝大多数资源在闲置。我建议你先画一张能力地图这个 Agent 需要哪些原子能力对应需要哪些腾讯云服务再按需开通。以我做内容类 Agent 为例最常用的就五类函数计算、对象存储、日志服务、向量检索、大模型接口。需要跑 Python 或 Node.js 脚本的开通云函数 SCF。需要存储爬下来的网页快照、生成文件的开通对象存储 COS。需要把技能调用链路和报错记录下来的开通日志服务 CLS。需要给 Agent 做私域知识库问答的开通向量数据库或兼容 PostgreSQL 的实例。需要模型规划与生成的开通腾讯云大模型服务把密钥配到环境变量里。这里有个原则能不开就不开。比如早期测试单技能不一定要用数据库日志可以先让函数直接返回给调用方。用 CLS 是因为后面技能数量上来后日志能按 request_id 串联否则你真的会在一堆 print 输出里找瞎眼。另外不要把密钥写死在代码里。SCF 支持环境变量把 SecretId、SecretKey 放到环境变量里比硬编码安全得多。哪怕只是个人项目也要养成这个习惯否则代码一旦上传到仓库密钥就等于裸奔了。COS 的作用容易被低估。刚开始我以为它只是存文件后来做长文本处理才发现有些 Skill 输入是一张 20 页的 PDF函数直接解析容易超时正确做法是先上传 COS再让技能通过临时链接分段读取。这样函数不保存大文件出问题也好排查。资源规划的核心不是“越大越全越好”而是“Agent 要动什么我就准备什么”。2.2 设计并发布第一个可复用技能网页正文提取我建议你的第一个 AI Skills 选“网页正文提取”。原因很简单它不依赖复杂模型却能演示 Schema、函数执行、JSON 返回、超时处理这些关键环节。先看技能声明也就是模型能读到的契约{ skill: webpage_fetch_and_extract, description: 当用户提供文章URL、要求获取某个网页正文内容时调用此技能。输入需为完整URL返回纯文本正文与字符数适合后续做总结、改写或信息抽取。, version: 1.0.0, parameters: { type: object, properties: { url: { type: string, description: 待抓取网页的完整地址必须包含http或https协议头。 }, max_chars: { type: integer, description: 返回正文的最大字符数默认5000超过部分会被截断。, minimum: 100, maximum: 20000 } }, required: [url] } }这段声明看着简单坑不少。description 一定要写清楚“什么时候用”。我的经验是动词开头、带触发场景模型才知道该在哪个环节选它。参数只保留必要的url 必填max_chars 有默认值且限定了上下界。如果不限范围模型可能传一个 100 万字符的数值你的函数就会傻乎乎地处理半天。再看 SCF 函数主体。用 Python 写一个最小可用版本核心逻辑是读取 API 网关传过来的 JSON、校验 URL、抓取网页、去标签返回正文import json import urllib.request from bs4 import BeautifulSoup def main_handler(event, context): # 统一处理事件格式兼容不同触发器 body event.get(body) or {} if isinstance(body, str): body json.loads(body) # 兼容两种传参外层参数或parameters字段 params body.get(parameters) or body url params.get(url, ) if not url.startswith((http://, https://)): return {code: 400, message: url must start with http(s)} max_chars int(params.get(max_chars, 5000)) req urllib.request.Request(url, headers{User-Agent: Mozilla/5.0}) with urllib.request.urlopen(req, timeout10) as resp: html resp.read().decode(utf-8, ignore) soup BeautifulSoup(html, html.parser) for tag in soup([script, style, nav, footer]): tag.decompose() text .join(soup.get_text().split()) return { code: 0, data: { url: url, content: text[:max_chars], content_length: min(len(text), max_chars) } }创建 SCF 函数时运行时选 Python 3.9 以上版本内存选 256MB 足够超时我建议先设 30 秒。创建好后重点配置 API 网关触发器路径随意比如/skill/webpage_fetch。发布后你会拿到一个 HTTP 地址这就算接入点了。测试时直接把 url 放到请求体里能返回 JSON 就说明技能通了。这里我要特别提示一个关键点API 网关接入云函数时不要用默认的“透传模式”就完事。你需要确认函数返回的格式是 API 网关能识别为标准 HTTP 响应的 JSON否则前端 Agent 可能收到一个被包了一层字符串的结果后面解析 JSON 直接失败。对应到 SCF你可以在函数里返回带 headers 和 body 的结构或者调试到输出裸 JSON 可用为止这一步不值得省。2.3 写模型能“看懂”的 Schema是我总结出的核心细节第一个技能跑通后我专门花时间整理了写 Schema 的细节。模型调用技能不是靠猜而是看到描述后做意图匹配。很多 Agent 效果不好根因就在这里。以下七条是我实测下来最管用的经验缺一条都可能让你在调试时多耗半天。描述里明确触发场景不只写功能名。例如“写周报”比“文本处理”好一百倍。参数带格式说明。string 类型要写清是 URL、日期还是普通文本number 类型要写范围。必填项能少则少。凡是能给默认值的都给默认值降低模型调用的心理负担。返回结构固定。我的习惯是统一包一层 code 和 data模型和流程代码不需要每个技能单独判断。长耗时任务不要硬等。先返回“任务已接受”再通过异步结果接口查询。技能版本写在描述之外但要在配置里保留。方便后面对比新旧行为。一个技能只做一件事。别设计“全能技能”让模型填一堆参数模型会填错函数也不好维护。这七条看似简单却是我排障时反复遇到的点。比如有段时间模型经常调用错技能我就把所有 description 打印出来逐条读发现好几条描述写得像内部注释比如“parsing utility”“extract helper”。模型看到这种词根本不知道触发条件。把它们改成用户任务视角后调用准确率立刻提升了一截。说白了Schema 是你和模型之间的“合同”合同写不清楚执行人一定会出错。3. 一个“内容全能 Agent”的 AI Skills 设计全过程3.1 从一条真实任务反推技能树设计 AI Skills 最忌讳拍脑袋。你脑子里想“这个 Agent 要全能”于是列了三十个技能结果一半没人用另一半覆盖不到真实需求。我建议从一个真实任务出发反推它的技能树。以我最近做的内容全能 Agent 为例用户常提的需求是“看看今天技术圈有什么热点围绕它写一篇适合公众号的初稿再给三个备选标题。”如果不拆技能模型接到这个指令会自己编“我今天的热点”因为它的训练数据不是实时更新的。即便它有联网能力你也没法保证它每次都按同一条路径去搜索、抓取、总结、改写。于是我把这条任务拆成五段每段对应一个或两个技能今日热点追踪对应hot_search输入领域/时间范围输出结构化热点列表。正文读取对应webpage_fetch_and_extract输入热点链接输出纯文本正文。内容总结对应summarize输出摘要与核心观点。知识库补充对应knowledge_retrieval把摘要作为 query检索私域资料。风格改写与标题生成对应style_rewrite和title_suggest。拆完之后你会发现这套技能不只服务“写公众号”这一条需求。明天你想让它做“竞品分析日报”同样可以用 hot_search、webpage_fetch、summarize、knowledge_retrieval 组合只是最后的 style_rewrite 改成固定模板输出而已。这就是拆技能的核心价值一个技能能被多个任务复用而不是每次需求都从零写一个新函数。3.2 五类高频 AI Skills写法各有门道在腾讯云上做 Agent 半年多我把常用技能归成五类每类的入参、出参和注意事项有比较明显的差异。信息检索类技能比如搜索热榜、搜索新闻、搜索内部文档。入参建议增加时间范围、地域或领域限定出参统一为列表结构每条包含标题、来源、链接、发布时间、摘要。这里最容易犯的错是不控制搜索结果数量模型一次要 50 条既费时间又费 token建议默认 5 到 10 条并在 Schema 里写上“最多返回20条”。文档解析类技能处理 PDF、Word、HTML。入参最稳妥的是“文档的 URL 或对象存储路径”不要直接传大段 Base64 文本否则函数入参容易被 API 网关限制。出参尽量返回纯文本和页数复杂的排版信息如果要保留可以用结构化 JSON但会增加模型理解成本前期不建议做太复杂。知识库检索类技能核心是向量检索加关键词召回。入参是 query、top_k、过滤条件出参要包含内容片段、来源文档、相似度分数。我在腾讯云上搭知识库时会另建一个集合记录每次检索的 query方便后续分析用户到底在问什么。生成创作类技能严格说不用做成函数更应该做成“固定输出模板 提示词”。如果你希望 Agent 生成特定风格的文案可以把风格写成技能内部的一段系统提示词再把入参设为“主题、字数、语气、目标读者”。这样生成结果比直接让 Agent 自由发挥稳定因为你把可变项约束住了。外部动作类技能比如发邮件、发企微通知、提交工单。这类技能要格外小心因为一旦调用就产生真实影响。我实践中的做法是所有外部动作类技能默认带一个 preview 参数先预览再执行如果是不可逆操作就需要人工确认节点。Schema 里加一个confirm_required字段Agent 执行前会停下等用户确认。开发初期这套机制救过我很多次有次技能误把测试消息群发给了真实用户还好预览节点拦住了。3.3 用技能编排把简单动作串成长流程单个技能解决的是“点”上的问题Agent 的价值体现在把技能串成“面”。我个人不太喜欢把所有流程写死在代码里那样就退化成普通工作流失去了 Agent 的灵活性。更推荐的方式是让 Agent 根据用户任务动态生成技能调用序列框架只负责顺序执行、超时处理和错误回退。我用一个简化示例说明这个思想。中间编排层收到用户请求后生成一个如下的执行计划workflow [ {skill: hot_search, params: {scope: 科技, limit: 5}}, {skill: webpage_fetch_and_extract, params: {url: {hot_search.0.url}, max_chars: 8000}}, {skill: summarize, params: {content: {webpage_fetch_and_extract.data.content}}}, {skill: style_rewrite, params: {content: {summarize.data.summary}, style: 公众号文章}}, {skill: title_suggest, params: {content: {style_rewrite.data.content}, count: 3}} ]注意里面那个{hot_search.0.url}意思是从上一步的返回结果中取值。这块我在工程上强烈建议不要用正则手写模板解析很容易出错。更可靠的做法是让模型每次只输出“调用哪个技能 参数对象”然后代码把参数对象传给对应函数再拿真实返回结果给模型看。等模型做好决策框架再去执行整个过程可观测。流程串起来后错误处理也要跟上。我的策略是对普通技能失败Agent 可以自动重试一次对不可逆动作失败直接停止并报告。还有一条高层原则写进系统提示词任何技能连续失败两次后必须向用户说明不能为了让任务看起来成功就编造结果。这条原则不多花一分钱却让整个 Agent 的“可信度”提升了一个档次。技能编排本质上是在做两件事让模型做擅长的事让代码做确定的事。4. 上线环节的最佳实践部署、权限、评测与回滚4.1 为什么我默认选 Serverless而不是租一台云服务器不少 Agent 项目一到部署就纠结是不是该买台服务器装个 FastAPI 跑所有技能我最早也这么干后来发现大部分技能属于低频触发可能一个函数每天只被调用几十次。为这几十次调用养一台服务器CPU 和内存长期闲置还要考虑操作系统补丁、环境依赖、进程守护纯属给自己找事。在腾讯云上做 AI Skills我的默认方案是 SCF 云函数加 API 网关。用一张表格说明我为什么放弃单机方案对比项单机后端Serverless 技能空闲成本需要支付固定费用基本无费用按调用计费扩容手动加配置或扩机器自动扩容但要设并发上限运维补丁、进程守护、日志轮转主要关注函数日志与版本单技能更新经常要重启整个服务按函数版本发布互不影响调试粒度看整体日志按技能/request_id 查日志配置方面我的个人经验是轻量技能内存 128MB 到 256MB重量级文档处理给到 512MB超时时间根据任务性质区分。网页抓取、格式转换这类同步技能设 30 秒足够涉及长文档解析或大模型多次调用的建议拆成异步流程函数先返回“处理中”再通过结果接口轮询。并发上限务必设置否则某个技能被大量调用时费用会像坐火箭一样涨。我在测试阶段曾经把一个抓取技能并发跑起来日账单比预期高了三倍从那以后每次发布前都会检查并发上限。4.2 密钥与权限管理是 AI Skills 里最容翻车的暗坑代码不出错、模型也能正确调用不代表技能就安全了。密钥和权限问题在 AI Skills 这个场景里特别隐蔽因为一个技能往往是独立函数、独立触发器配置的人一多很容易出现“某个技能权限过大”的情况。第一原则是函数代码里不得出现任何长期密钥。腾讯云 SCF 本身支持用角色授权你可以给函数绑定一个服务角色角色只具备它需要的权限。比如网页抓取技能需要写 COS 某个临时目录就给这个角色授该存储桶的cos:PutObject权限不给整个账号的管理权限。测试阶段我也嫌麻烦直接把 SecretId 放进环境变量图省事结果又一次不小心把代码提交到仓库吓得我连夜轮换密钥。环境变量虽然隔离了代码但也不是终点最小权限才是最终解。第二原则是必须校验用户传入的外部参数。AI Skills 暴露在互联网天然就是被扫描的对象。你要尤其小心 URL 类参数如果直接让函数请求任意 URL攻击者可以把云函数变成“跳板”去访问内网资源这就是典型的 SSRF 风险。我在技能里会加一层校验只允许 http/https 协议限制目标 host不解析内网 IP 段。不要嫌麻烦外网暴露的 AI Skills 只要有一两个技能存在这种漏洞你的账号安全就会被打穿。第三原则是敏感操作必须留痕。外部动作类技能执行前记录操作人、目标对象和参数摘要执行后再记结果。平时你用不上这些日志一旦出了问题它能帮你快速判断是误触发还是恶意请求。我把这些日志统一送到 CLS单独建一个 topic按日期分区查询效率高费用也可控。4.3 发布前做评测升级时保留回滚路径AI Skills 上线不是写完函数就结束还要有一套验收和发布流程。我在项目中形成了一份简单的“技能验收单”核心字段是技能名、版本、测试用例数、成功率、平均耗时、单次调用成本、异常类型。每个技能上线前我会准备至少 20 个变体输入覆盖正常场景和边界场景比如 URL 缺协议头、参数类型不对、远端服务器超时。典型边界用例不用太复杂参数齐全且合法验证主流程正常。缺少必填参数验证是否返回清晰错误。外部服务超时或返回 5xx验证函数是否妥善处理。返回内容超过长度限制验证是否按约定截断。统计成功率时我会把“模型是否正确识别技能”也算进去而不是只看函数本身有没有报错。有时候函数成功率是 100%但模型就是不在该调用的时候调用这同样算失败。于是我会额外记录一个指标技能被调用的触发率。如果某个技能有 30 次理想触发场景但实际只在 10 次里被调用说明 description 还需要优化。版本升级也要留后路。SCF 本身支持版本与别名我会把线上稳定版本固定成一个别名新代码先发布成新版本再用 API 网关指向别名进行小流量灰度。发现问题时直接把别名切回旧版本整个过程可以控制在分钟级。我见过一些团队没有版本意识直接在线编辑函数代码一旦改出 bug连旧代码都找不回来。个人项目可能觉得无所谓但如果你同时维护多个 Agent版本混乱只会让问题雪上加霜。5. 腾讯云 AI Skills 排障实录几个典型坑和对应解法5.1 模型就是不调用技能怎么调都没用这类问题在 Agent 开发里出现频率极高。最典型的场景是技能函数已经发布测试接口也通但 Agent 面对该用技能的任务时偏要自己生成答案。我遇到过一个真实案例网页抓取技能描述写的是“网页正文提取”模型看到“帮我看看这篇文章”时根本没意识到这是正文提取需求直接凭训练数据里的背景知识开始总结用户要是拿今天的新闻去试结果就是一本正经的胡说八道。解法分成两层第一层把技能描述改成用户任务视角例如“当用户提供文章URL、要求读取网页正文、分析链接内容时调用此技能。如果用户没有给出URL先询问URL。” 这句话把触发条件和前置动作都讲清了模型命中率明显提升。第二层在 Agent 的系统提示词里加技能清单和适用边界比如“如果任务是查看某个 URL 的内容不得直接回答必须调用 webpage_fetch_and_extract 后再总结”。这种“硬约束”能救回不少漏调用的情况。如果你已经按上面改了还是不行还有一个排查技巧把模型实际发起的调用请求记录下来。你会看到有时候模型根本没有返回 function call而是直接返回普通文本有时候它返回了 function call但参数里 url 是空的因为它压根没理解“必须提供 URL”这个约束。这两种情况处理方法不同前者改描述后者改参数说明、把 url 设成必填。所以别急着怀疑模型能力先看日志日志会告诉你真相。5.2 技能调用经常超时前端等不到结果AI Skills 超时是我上线初期被折磨最多的问题。原因是多方面的云函数默认超时可能只有几秒网页抓取对象又慢又重API 网关同步请求有最长响应时间不支持无限等待函数冷启动也会让第一次调用额外多出几百毫秒到几秒。如果只是把超时时间调大治标不治本。我的排查顺序是先打开 CLS 日志看函数到底卡在哪个环节。如果是网络请求慢就换更可靠的请求地址、增加超时设置、限制重定向次数。如果是函数冷启动导致的偶发超时可以给函数配置并发实例保留或者把“冷启动可接受”改成后台异步预热。如果任务本身要处理三十秒以上比如长文档解析、大模型多次生成建议把技能设计成异步任务接口立刻返回 task_idAgent 拿着 task_id 查询结果而不是干等 HTTP 响应。异步技能改造并不复杂函数里先创建一个任务记录状态是 pending然后把真正的处理逻辑放到后台队列或另一个函数主函数返回 task_id。前端 Agent 拿到 task_id 后轮询结果接口直到 status 变为 success 或 failed。这样用户感知到的等待时间变短系统也不会被慢请求拖垮。我在一个 PDF 解析技能上做了这个改造之前动不动 50 秒超时后来主接口 200 毫秒响应处理结果 3 秒内可查体验天差地别。5.3 JSON 解析报错和中文乱码问题定位在这一层另一个高频坑是技能返回值明明看着正常Agent 端却解析失败。你会发现报错信息往往不是“字段不存在”而是 JSONDecodeError或者中文变成一堆\uXXXX。十年前写后端踩过乱码坑的人现在做 Agent 又会再踩一轮只是载体从网页换成了 AI Skills。核心原因通常是 API 网关和云函数集成时没有设置正确的响应格式。SCF 返回的字符串如果被 API 网关再包了一层模型拿到的就不是纯 JSON。解决办法是让函数显式返回标准 HTTP 响应结构例如return { statusCode: 200, headers: {Content-Type: application/json; charsetutf-8}, body: json.dumps({code: 0, data: {...}}, ensure_asciiFalse) }注意这里用了ensure_asciiFalse能避免中文被转成\u开头的一长串。开发时我用 curl 直接调 API 网关地址检查返回头里的 content-type 是否携带 charset不然模型解析时容易按默认编码处理。还有一种情况是函数内部逻辑写错了返回的 data 本身不是一个 JSON 对象而是字符串嵌套模型二次解析也会失败。我的建议是所有技能在入口处做一次“参数校验”出口处做一次“结构校验”保证无论中间发生了什么最终落到 Agent 手上的都符合 Schema。这层防御看起来多余但在技能数量超过十个之后它的价值会无限放大。5.4 日志满天飞但串联不起来技能一多排查问题的最大障碍不再是“没有日志”而是日志太多、没有关联。以前我每个函数自己打印请求参数和结果真出问题时需要在云控制台一个个函数翻效率极低。尤其是 Agent 一次任务会调用三四个技能失败可能发生在任何一个环节没有全局视角根本看不出来。后来我养成了一个习惯把云函数自动生成的 request_id 在整个链路里传递。Agent 发起任务时先生成一个任务级 trace_id之后每次技能调用都把 trace_id 放进 HTTP Header函数里把它打到日志里。CLS 就能按 trace_id 把一次任务的多个环节串起来查看顺序是“Agent 先调了什么、哪个技能报错、错误信息是什么”。查询方式很简单比如cls search trace_id:xxxx AND skill_name:webpage_fetch这比在控制台肉眼筛选日志高效得多。我也建议给每个技能打一个固定的 skill_name 字段不要只在日志里写函数名。因为同一个云函数可能承载多个版本只有技能名加版本号才能对准问题代码。日志这件事没有技术难度纯粹是习惯问题但它在排障效率上的回报远超你的投入。6. 我踩过这些坑之后对 AI Skills 的新理解6.1 技能多不等于强收敛才是真“全能”我最初做技能规划时总想把所有能做的东西都做成技能以为技能越多 Agent 越全能。结果技能库膨胀到几十个后模型的选择压力急剧上升调用准确率反而下降。模型在几十个相似选项里找目标比在五个技能里找目标要难得多。这个结论让我重新理解了“全能 Agent”的养成方式——它不是功能的堆砌而是能力的收敛。我开始每隔两周做一次技能下架评估看每个技能的历史调用次数、成功率、被模型误调用次数。连续一个月没被调用或者总是被模型混淆的技能就先下线不在主技能列表里出现。把高频技能留在“热区”把低频能力收进“冷区”需要时再通过技能描述动态加载。这样 Agent 在正常任务中看到的技能清单不会过于臃肿模型意图识别也干净很多。想清楚“不做什么”比“做什么”更重要这套思路对个人项目和团队项目都适用。6.2 我接下来会在这个 Agent 上继续做的三件事如果只停留在这里这套方案能帮你在腾讯云上搭出可用的 Agent但离“全能”还有距离。接下来我会继续完善三块内容第一增加多模态 AI Skills比如截图理解、图片素材筛选、语音转文字让 Agent 不只是处理文字还能看懂图片和音频第二把知识库更新做成独立技能让 Agent 能定时抓取新资料并写入向量库避免私域知识越用越旧第三给技能加更细粒度的可观测面板统计每次调用消耗的 token、延迟和成本方便做长期优化。另外我还想提醒一点技能工程不是一次性工作。你写完一个 Skill它要跟着模型升级、用户需求变化而调整。每次大模型更新后我都会拿旧评测用例重新跑一遍因为模型行为变了原来能正确调用的技能可能就失灵了。这是 Agent 开发比较独特的地方你的依赖不只有代码还有模型这个“不确定因素”。用确定性的工程方法去驯服不确定性让每次任务都尽可能有稳定预期这可能就是 AI Skills 最佳实践最核心的含义。最后分享一个小技巧别一开始就追求大而全的 Agent先给它配三个解决高频问题的核心技能把一个具体场景做到 90 分再复制这套打法去扩展下一个场景。全能从来不是一步到位的它是一轮一轮“拆解—落地—复用”迭代出来的结果。