先说明一点这篇写的是我自己在腾讯云上从零搭一个“带 Skills 的 Agent”的完整过程。不写理论不贴空话就是把踩过的坑、试过能用的方案、最后跑通的步骤全捋一遍。如果你正准备做 Agent 开发或者想搞明白“Skills 到底是个什么东西、怎么用起来”这篇应该能帮你省下不少摸索时间。1. 内容整体设计与思路拆解1.1 为什么先别急着写 Agent 代码而是先想清楚“模型会缺什么”我第一次上手做 Agent 的时候犯过一个特别典型的错误一上来就搭框架、写工具调用、配提示词搞了一个看起来很完整的 Agent 外壳结果一问它“帮我查一下今天某个 API 的限流策略变了没有”它就傻眼了。为什么因为我没有给它获取实时信息的能力也没给它调用外部工具的技能它所有回答都只能靠训练时的旧数据在硬撑。这一步吃了个大亏之后我才真正理解一个关键逻辑Agent 的核心不是“模型有多聪明”而是“模型能不能通过工具触达它不知道的信息”。你让大模型背一本 2023 年的百科全书它背不下来也没必要背。但如果你给它一个搜索工具、一个文档读取工具、或者一个执行特定任务的技能包它就能像人一样“用到哪查到哪”。Skills 的本质其实就是把“某种能力”从 Prompt 里抽离出来做成一个可复用、可单独维护、可被模型按需加载的功能单元。这个概念听起来不复杂但它在实际工程里的影响非常大。我见过很多团队把工具调用逻辑全部塞进 System Prompt 里几百行提示词堆在那每次调一个参数都要小心翼翼地改半天几天之后连自己都分不清哪段逻辑对应哪个函数。Skills 要解决的就是这种混乱。1.2 从“工具”到“技能”的思路转变一个 Skills 就是一个可复用的能力单元做 Agent 开发的人可能都有这种感觉一开始做工具调用脑子里想的全是“我要怎么给模型提供函数”所以写出来的东西都是get_weather(city)、get_stock_price(code)这种散装函数。模型只能在被调用的时候去执行执行完之后返回一个结果这本质上还是“远程函数调用”距离“智能体”还很远。Skills 的思路则不同它不是一个函数而是一个**“完整的技能包”**。技能包里不光有描述“这个技能是干嘛的”的说明文本还有模型调用这个技能时需要遵循的步骤、注意的事项、可用的参数结构、甚至一些示例。模型读到这个技能包之后能组织自己的行为逻辑一步步地去完成任务而不是简单调用完一个接口就结束了。举个我实际做过的例子。我想让 Agent 能帮我从网上收集某个开源项目的 release 信息整理成表格。如果按传统工具函数的方式做我可能得写fetch_release_info(project_name)、parse_release_version(text)、format_release_table(data)三个函数然后还要在 Prompt 里告诉模型“你先调第一个函数调用完了再调第二个……”。这样写不光啰嗦而且只要 release 的页面结构一变我就要回来改代码。但是用 Skills 的方式做我只需要把“如何从 GitHub 获取 release 信息、如何解析版本号、如何整理成表格”的全部逻辑写进一个技能包里模型读完之后自己就知道该先干什么、后干什么遇到异常情况还能尝试别的路径。最关键的是这个技能包我写完一次之后想给其他 Agent 用直接“插过去”就行不用重新写 Prompt。1.3 为什么选择腾讯云 AI 开发平台作为实践入口这次实践我选了腾讯云 AI 开发平台原因有几个不是因为它功能最全而是因为它把几个关键痛点解决得比较省心环境预置了主流的大模型和开发框架不用自己从头配置 GPU 服务器、推理环境、依赖库省掉了大量环境折腾的时间。Agent 编排、Skills 管理、模型调用链路在同一个控制台里能串起来不用在几个平台之间来回切换。它有一套相对成体系的 Skills 规范写好的技能可以统一注册、统一管理方便测试和复用。当然你可以用 OpenAI、Anthropic 或者其他云厂商的类似服务来做同样的事。但如果你和我一样想要一个“能上传、能调试、能部署、能跑通”的闭环环境腾讯云这套是目前体验下来比较顺手的。下面我讲的每一步基本都能在这个平台上直接复现。1.4 我的实践目标做一个“能上网查资料并自动整理”的 Agent这次我不搞那种大而全的“通用智能体”那玩意儿听着厉害落地上手就知道坑有多深。我给自己定了一个足够具体、能够衡量结果的目标做一个能根据用户输入的主题自动搜索相关资料、过滤无效信息、整理成结构化报告的小 Agent。这个目标听起来不大但该踩的坑一个都不会少要让它调用外部搜索服务要让它学会解析网页内容要让它把长文本整理成清晰的报告还要控制它在遇到问题时不会死循环。后面所有的内容都会围绕这个目标展开。你跟着走一遍做完的就是一个能拿得出手、能继续扩展的 Agent 雏形。2. 腾讯云 AI Skills 核心机制拆解与准备2.1 Skill 到底是什么在腾讯云平台上怎么组织这个问题我刚开始研究的时候被各种文档绕得头晕后来自己上手之后才明白它其实就是一个结构化的“技能描述 调用逻辑”的集合。类比一下你把一个会做红烧肉的人叫到厨房你不用一步步告诉他“先倒油、再放肉、加生抽、加老抽、加糖、加水……”你只需要跟他说“你做一个红烧肉”他脑子里已经有一整套做红烧肉的步骤了。Skills 起的作用就是让模型具备这种“被提到技能名就知道整套流程怎么走”的能力。在腾讯云 AI 开发平台上一个完整的 Skill 通常包含这几块内容技能元信息技能名称、用途描述、适用场景。模型就是靠这段描述来决定“什么时候该调用这个技能”。参数定义调用技能时需要传入的参数比如搜索关键词、报告语言、结果条数限制等一般支持格式化的 schema 描述。执行逻辑技能内部具体做什么事。这一步可以对接云函数、API 网关、自定义代码、甚至外部的第三方数据源。返回内容规范技能执行完成后返回给模型的结果是什么格式便于模型分析并组织最终回答。我具体在控制台里创建 Skill 的时候流程大概是这样的进入“技能管理”页面选择“创建技能”。填写技能的基础信息比如名称叫“资料搜索与整理”描述写清楚这个技能是“接收一个主题关键词返回相关的资料列表和摘要”。配置参数 schema我定义了keyword字符串必填、max_results整数默认 5、language字符串默认zh。选择执行方式这一步我接了一个云函数函数内部调用了搜索 API 并解析结果。保存并发布技能就进入可用状态了。2.2 为什么技能的“描述信息”决定了 Agent 的上限这里有个细节我想单独拎出来说因为百分之九十的新手都会栽在这上面很多人以为技能描述写得越复杂越好其实恰恰相反关键是把“什么时候用”和“怎么用”说清楚。腾讯云平台的模型推理逻辑是你给模型一个用户问题模型自己判断需要哪些技能然后根据技能的描述信息决定是否调用。如果你的技能描述写得太宽泛比如写“这个技能可以处理各种信息查询”模型会在不合适的场景下也去调用它白白浪费 token如果你写得太模糊比如只写“搜索工具”模型根本就不知道这个工具的输入输出格式调用的时候容易出错。我后面测试时试过两个版本的搜索技能描述对比非常明显第一个版本我只写了一句“这是一个搜索工具”结果模型调用时经常忘记传关键词甚至把搜索结果当成答案直接返回格式一塌糊涂。第二个版本我详细写了该技能用于根据用户提供的主题关键词在互联网上搜索相关的中英文资料。 输入参数 keyword 必须是具体的主题词比如量子计算、2025年AI趋势不能是完整问题。 技能会返回若干条结果的标题、链接和摘要你可以基于这些信息整理回答。 当用户询问实时信息、最新动态、或者你自己无法确定的内容时优先使用该技能。改完之后模型调用的准确率明显上了一个台阶。这个优化成本几乎为零效果却非常大。2.3 环境准备账号开通、模型选择、权限配置正式开始动手之前我需要把环境准备好。这一步看起来基础但里面的权限坑务必要留个心眼。首先是账号与资源开通。腾讯云 AI 开发平台需要完成实名认证然后在控制台开通对应的服务。这个部分跟着官方引导走就行不赘述。我想强调的是权限配置Skills 在执行时如果需要访问其他云资源比如云函数、对象存储、API 网关你必须在访问管理里给对应的服务角色授权。我有一次卡了足足两个小时技能调用一直报错最后发现是服务角色缺少一个函数调用的权限。其次是模型选择。腾讯云平台提供了多个模型可选我这次选的是一个平衡了推理能力和响应速度的版本既能理解较复杂的技能编排逻辑又不会慢到让人抓狂。如果你只是做简单测试也可以先用轻量版模型跑通流程最后再用更强的模型验证效果。再者如果你是个人开发者最好在本地装好命令行工具或者准备好 API 调试工具。我习惯于先用小流量测试一遍技能确认无误之后再放到正式环境里跑。2.4 快速理解 Platform 上的 Agent 编排链路Agent 编排这块我把它理解成一条流水线用户提问 - 模型理解 - 技能匹配 - 技能执行 - 结果回传 - 模型总结。腾讯云控制台的可视化编排界面把每个环节都用节点画了出来你不需要写太多胶水代码把节点拖拽连接起来就能跑。但这不代表你可以不写代码技能内部还是要靠代码来实现具体功能只是 Agent 层面的调度逻辑交给了平台。我构建的流程里除了“用户输入”和“模型回复”这两个基础节点中间还挂了两个关键技能节点一个负责搜索一个负责信息整理。搜索节点拿到的原始网页内容往往比较杂如果直接丢给模型既费 token又容易让模型抓不住重点。所以我设定搜索节点只返回“标题 链接 摘要”然后由整理节点把摘要按主题聚合最后再由模型生成最终报告。这个分层设计效果很好模型输出质量明显比直接把原始网页全部塞给它要高。3. 实操过程与核心环节实现3.1 第一步在云端创建一个最简单的 Skill代码示例纸上谈兵半天现在开始动手。我先把最基础的技能流程跑通创建一个“返回固定文本”的测试技能确认整条链路是通的。你如果跟着做建议也从这一步开始别一上来就搞复杂的搜索。在腾讯云 AI 开发平台的技能管理页面我选择“创建技能”填了以下内容技能名称hello_skill技能描述测试技能。当用户打招呼或询问你是谁时你可以调用此技能获取欢迎语。参数定义无执行方式云函数云函数里的代码很简单我用的是 Python 运行时# 云函数入口 def main(event, context): return { statusCode: 200, body: 你好呀我是一个全能 Agent可以在你的指令下调用各种 Skills 来完成任务。 }保存、发布、关联到 Agent 之后我在对话窗口中输入“你是谁”模型立刻调用了这个技能并返回了上面的欢迎语。链路通了接下来才敢往里面加真本事。3.2 第二步从零编写一个“资料搜索与摘要”技能接下来我要把核心技能真正做出来。这个技能要做三件事接收主题关键词、调用外部搜索接口、返回结构化结果。我先定义了参数 schema{ type: object, properties: { keyword: { type: string, description: 搜索主题关键词例如AI Agent 开发框架对比 }, max_results: { type: integer, description: 返回结果数量默认 5最大 10, minimum: 1, maximum: 10 } }, required: [keyword] }然后写云函数。这里最省事的方式是调用搜索服务的公开 API我用的方案是对接一个搜索服务的 HTTP 接口让函数直接去请求。伪代码大致是这样的import requests def main(event, context): body event.get(body, {}) # 如果 body 是 JSON 字符串先解析 if isinstance(body, str): import json body json.loads(body) keyword body.get(keyword, ) max_results body.get(max_results, 5) # 调用外部搜索服务以某公开搜索接口为例 search_url https://api.example.com/search params { q: keyword, num: max_results, hl: zh-CN } resp requests.get(search_url, paramsparams, timeout10) data resp.json() results [] for item in data.get(items, [])[:max_results]: results.append({ title: item.get(title, ), link: item.get(link, ), snippet: item.get(snippet, ) }) return { statusCode: 200, body: { keyword: keyword, results: results } }这里有个非常关键的点我吃过亏必须强调外部搜索服务的返回字段名不一定叫title、link、snippet你得先实际调一次接口搞清楚返回结构再写解析逻辑。我最初直接照抄文档里的示例结果返回的字段实际叫heading和href导致解析结果全是空排查了半天才发现是字段名对不上。3.3 第三步让 Skill 不只是一次请求而是一套“带流程的技能包”第一步和第二步做的是“单次调用”的技能但真正的 Agent 不能只会跑一次请求。很多时候它需要根据搜索结果进一步判断、筛选、再搜索。所以我做了一步升级把这个简单技能扩展成“先搜索、再对结果做初步过滤、最后按相关度排序”的完整流程。这里就用到了腾讯云平台 Skills 的一个高级能力多步骤技能编排。我不再写一个单纯的云函数而是把技能分成几个内部节点搜索节点根据 keyword 请求外部搜索服务拿到原始结果。清洗节点去掉明显无关的链接、去重、过滤掉空标题或空摘要的条目。重排节点根据关键词在标题和摘要中出现的频率对结果排序把相关性最高的放在前面。在控制台上这种多步骤技能可以用函数流转来实现。简单来说就是每个节点是一个云函数或者处理单元节点之间用参数传递结果。第一个节点的输出results列表会传给第二个节点的输入第二个节点处理完再传下去。清洗节点的代码大致长这样def clean_results(raw_results): seen set() cleaned [] for item in raw_results: link item.get(link, ) title item.get(title, ).strip() if not title or not link: continue if link in seen: continue seen.add(link) cleaned.append(item) return cleaned看着很简单但实际跑起来很有用。因为搜索 API 经常会把同一个网站的多个页面都返回出来标题还不一样但链接基本一致有些结果只有链接没有标题这种对模型来说基本没用直接在清洗阶段删掉能省很多事。多个节点串起来之后Agent 实际执行一个搜索任务的表现是这样的用户说“帮我整理一下最近一年 AI Agent 框架的对比信息”模型收到指令后决定调用搜索技能技能内部自动完成了搜索、清洗、重排最后返回给模型的是一组已经过滤好的结构化结果模型再基于这些结果组织成一篇通顺的报告。3.4 第四步将 Skill 挂载到 Agent 上并测试效果技能写好并发布之后需要挂载到 Agent 才能生效。在腾讯云 AI 开发平台的 Agent 编排界面里我把“资料搜索与摘要”技能拖到了技能节点区域然后在系统提示词里加了一句说明“当用户需要查询实时信息或最新资料时请使用资料搜索与摘要技能。”这里我踩过一个很典型的坑挂载技能后模型死活不调用它。排查了很久发现原因是系统提示词里少了一句话模型不知道这个技能在什么场景下该用。加上了技能使用说明之后模型才“开窍”。所以再次强调技能的描述信息和系统提示词里的引导缺一不可。挂载完成后我开始了多轮测试。测试用例包括“帮我查一下最近关于多模态大模型的最新研究动态”“找几篇关于 RAG 技术落地的实践文章”“搜索一下 Agent 开发中常见的性能优化手段”每一轮我都观察模型是否能正确调用技能、技能返回的结果是否可用、模型最终回答是否自然。第一轮测试的情况很真实模型确实调用了技能但它在搜索结果里找到几篇相关的就直接把摘要拼在一起输出内容有明显的“拼贴感”。这是非常常见的问题后面我会详细说怎么解决。3.5 第五步部署上线与真实环境验证测试通过之后我把 Agent 发布到了测试环境然后又以“在线服务”的方式部署到了正式可调用的状态。腾讯云平台提供了一键发布到 API 或对话界面的选项我选择了生成一个 Web 对话链接方便自己在手机和电脑上随时测试。部署之后有一个细节值得注意云函数默认超时时间是 3 秒但 Agent 一次技能调用往往涉及到外部搜索耗时可能超过 3 秒导致调用失败。我一开始没有调整超时时间测试时经常看到“技能调用超时”的报错后来把超时时间改成了 30 秒问题立刻消失。如果你也遇到类似问题第一件事就去检查超时时间是不是太短了。真实环境验证这一步我特意找了几个平时不太可能直接背出来的问题去问 Agent比如某本书的出版时间、某个开源项目最近的 star 数变化、某个 API 的最新价格档位。这些都需要实时信息模型如果不调用技能根本答不出来是检验技能是否生效的好方法。结果虽然不能保证百分之百精确但整体信息是完整的、有出处的已经达到可以日常使用的水平。4. 常见问题与排查技巧实录4.1 “模型就是不调用技能”怎么办这个问题我遇到了无数次也是新手问得最多的。排查思路基本按下面这个顺序来先看技能的描述是否具体。如果你的技能描述太笼统模型判断不出来“这个问题该不该用这个技能”。好的描述应该包含“什么情况下用”和“输入什么参数”。再看系统提示词里有没有引导。模型在相当多的时候是看提示词办事的你直接告诉它“当遇到 XX 类问题必须调用 XX 技能”它就会老实照做。最后看技能的测试是否成功。在技能管理页面单独测试技能确认技能本身能正常返回结果。如果技能内部报错模型调用后拿不到有用结果它也会倾向于不调用。我有一次排查了很久发现模型不调用技能的原因竟然是因为技能在“未发布”状态。这听起来很蠢但真的很常见你编辑了技能以为保存就生效实际上不点“发布”是不会对 Agent 生效的。4.2 技能调用成功了但结果质量很差怎么优化技能调用成功、返回了结果但模型整理出来的答案很生硬甚至直接把摘要拼接在一起这通常不是技能的问题而是“模型如何处理技能返回结果”的问题。一个有效的做法是在技能描述里增加一段“使用说明”技能返回的结果是经过筛选的资料标题、链接和摘要。 你在回答时应基于这些资料进行归纳用自己的语言组织回答 不要直接复制粘贴摘要原文也不要列出所有结果 只需要选取最相关的部分结合用户的问题进行提炼。另外还可以在技能内部就把结果做一次“预压缩”。比如在清洗节点后加一个“摘要提取”节点用轻量级的文本摘要算法把每个网页的摘要缩短到一两句话这样模型拿到的信息更精准生成回答的质量也会提高。4.3 外部搜索接口不稳定怎么保证体验Agent 一旦依赖外部接口稳定性就成了一个大问题。我测试时就遇到过搜索服务突然限流、返回 429、或者返回的数据格式变化导致解析失败。我的应对策略有这几个在云函数内部做异常捕获。把请求包裹在 try-except 里出现异常时返回一个带错误信息的结构而不是让函数直接崩溃。这样模型至少知道发生了什么可以给出“当前搜索服务暂时不可用”的回应。设置合理的超时时间。比如外部请求超时设置 8 秒如果 8 秒内没有响应就放弃并返回提示。配置日志监控。腾讯云平台支持查看云函数的调用日志我在日志里打印了每一次外部请求的 URL、状态码、返回前 200 个字符一旦出问题能快速定位。准备一个备用搜索渠道。如果主渠道挂了函数可以自动切换到备用的搜索接口。这个“降级思维”在 Agent 开发里非常重要因为你的 Agent 再怎么聪明底层服务挂了它也使不出力。4.4 多轮对话中Agent 开始“发疯”怎么办多轮对话场景下模型可能会忘掉之前已经调用过的技能或者重复调用同一个技能导致回答越来越啰嗦。这个问题我是在长时间对话测试中发现的前几轮还好好的到第五六轮的时候模型开始反复搜索同一个关键词但对话内容却没有实质推进。排查发现问题是技能调用记录没有被有效地“沉淀”到上下文里。每轮用户提问后模型只看到了当前的问题没有清晰的历史记录告诉它“你已经搜索过这个关键词了”。解决方法是给 Agent 的对话管理加一层摘要机制每完成一次技能调用就把“已获取的信息摘要”追加到上下文里并显式提示模型“这些信息已经确认过不必重复搜索”。在腾讯云平台上这个能力可以借助“记忆”配置来实现。我也手动在提示词里加了一段约束“如果你在当前对话中已经调用过某技能且得到了结果除非用户明确要求再次查询否则不要重复调用。”实测下来效果明显对话的连贯性大大提升。4.5 一次性开放所有端口这个操作千万别碰热词里出现了“腾讯云如何开放所有端口”这样的搜索词我必须专门提醒一句在配置云函数、安全组或 API 网关时绝对不要把端口范围设置为 0-65535 并暴露给公网。这等于把你的服务脱光了放街上任何人都能扫描、探测、甚至攻击。Agent 开发中合理的端口开放思路是只开放业务需要的端口比如云函数通过 API 网关对外提供 HTTPS 访问只需要开放 443 端口功能调试时可以用内网环境不要直接从公网访问云函数内部。腾讯云的访问控制里也支持设置来源 IP 白名单如果你只是自己测试可以把白名单设置为自己的 IP不要嫌麻烦。4.6 常见问题速查表现象可能原因解决方法模型不调用技能技能描述不清晰、未发布、不在提示词引导范围优化技能描述确认技能已发布在系统提示词中加入使用场景说明技能调用超时云函数超时时间太短、外部请求慢调整云函数超时时间至 30 秒以上检查外部接口响应时间返回结果为空解析字段名与接口实际返回不一致先手动请求接口确认字段名再写解析逻辑返回结果重复没有去重逻辑在技能内部维护一个已见链接集合过滤重复项答案生硬、像拼贴模型直接复制摘要在技能描述中明确要求归纳总结增加摘要提取节点预压缩信息多轮对话后重复搜索缺少对话记忆或上下文引导配置记忆机制在提示词中禁止不必要的重复调用接口被限流没有做异常处理和降级增加 try-catch配置备用接口设置合理超时与重试5. 实战复盘一次完整的“提问 - 技能编排 - 报告输出”全流程展示5.1 用户提问与 Agent 的决策过程理论讲得再多不如完整跑一遍真实流程。我在部署好的 Agent 里输入了一个测试性问题“帮我把 2025 年值得关注的 AI Agent 开发框架整理一下要包含它们各自的特点和适用场景。”这是典型的“适合调用搜索技能”的问题。模型收到问题后先对问题做了意图识别这是一个需要实时信息和多来源资料归纳的任务自己无法凭训练数据完成于是决定调用“资料搜索与摘要”技能。这里有个值得关注的地方模型在调用技能前会把问题解析成技能可以吃进去的参数。keyword被提取为“2025 AI Agent 开发框架”max_results被设置为 6。这个参数提取准确与否直接影响搜索结果质量。如果参数提取乱了比如把整个问题原封不动当成关键词搜索效果会大打折扣。5.2 技能内部执行过程逐段拆解技能被调用后内部流程是一步步走的第一步搜索节点。云函数接收参数后向外部搜索服务发起请求拿到了包括标题、链接、摘要等信息的十几条原始结果。这一步实际耗时大约 2.8 秒算是在正常范围内。第二步清洗节点。清洗代码过滤掉了三条无效结果一条标题为空两条链接重复。这一步很快基本是毫秒级。第三步重排节点。重排逻辑把标题和摘要里含有“AI Agent”“framework”“开发框架”等关键词的结果往前排。这一步也不复杂但对后续模型生成报告的质量帮助很大。最终技能返回给模型的结果是一个包含 5 条结构化信息的列表每条信息有标题、链接、摘要。模型拿到这个列表后先快速浏览了一遍摘要然后开始组织回答。5.3 模型如何基于技能结果生成最终报告这是整个流程中“最见功力”的一步。模型不是把五条摘要依次复制过来而是做了以下处理从不同框架的摘要中抽取关键信息比如框架的编程语言、设计理念、适合的应用场景剔除重复观点比如有两个框架都在强调“模块化设计”模型会合并这种信息而不是各写一遍按类别组织内容把逻辑相关的内容放在一起形成一个从“整体趋势”到“具体框架对比”的报告。最终输出的大致结构是这样的2025 年AI Agent 开发框架的演进更加注重模块化和可观测性。以下是一些值得关注的框架……省略具体内容如果你偏向轻量级开发可以重点考虑 A 框架它对 Python 生态的支持比较好如果你需要多 Agent 协作能力B 框架内置的通信机制会更省心如果是生产环境部署C 框架的监控和追踪工具相对更成熟。这个回答质量远高于直接展示搜索结果。这就是模型 Skills 配合的意义模型负责“组织语言、提炼要点”技能负责“提供信息、补充来源”。5.4 耗时与成本分析这么跑一趟到底值不值我把这次完整调用的耗时和消耗记录下来给大家一个参考从用户提问到最终回答展示总耗时大约 9 秒。其中技能调用占了一大半模型生成最后回答反而只花了两三秒。token 消耗方面技能调用过程中使用的 token 远低于模型直接阅读原始网页的消耗。这里算一笔账如果不经技能直接把整个网页内容塞给模型一个网页可能就有几千 token而经过技能清洗后每条结果只有 100 token 左右的摘要五条结果合计才几百 token成本降了一个数量级。这就是为什么我强调“技能内部的数据清洗不是多余的它是控制成本的核心手段”。如果你做的是面向大量用户的 Agent 服务这个成本差异会在月度账单上体现得非常明显。所以我的建议是在技能设计阶段就考虑好“如何让模型只看最必要的信息”这比后期优化模型提示词更管用。6. Skills 的进阶玩法与个人经验总结6.1 把多个技能串联构建“复合型 Agent”单个技能能做到的事有限但把几个技能串起来Agent 就能完成更复杂的任务。我在完成“资料搜索与摘要”这个技能之后又做了一个“报告格式化输出”技能能够把模型整理好的内容转成 Markdown 格式并生成一份带标题层级、列表和引用标记的结构化文档。在实际使用时模型会先调用搜索技能拿到资料然后调用格式化技能把回答整理成规范的报告。两者之间没有直接的数据依赖但模型通过对话上下文把它们自然地串联了起来。这个思路可以继续扩展再加一个“定时提醒”技能、一个“邮件发送”技能、一个“知识库检索”技能你的 Agent 就开始从“聊天机器人”向“数字助手”转变了。6.2 Skill 的颗粒度怎么把握这是我在实践中反复调整的一点。把技能拆得太细模型需要做多次调用才能完成一个任务效率和成本都不划算把技能做得太粗内部逻辑臃肿调试和复用都困难而且模型可能搞不清楚这个技能到底覆盖了什么。我的经验是按“用户意图的最小完备需求”来划分技能。比如“查天气”是一个最小完备需求一个技能就够“查天气并推荐穿衣建议”也是但推荐穿衣建议逻辑比较复杂可以做成搜索技能后面的一个独立技能。关键是不要让用户为了完成一个简单需求被迫让 Agent 连续调用七八个技能这会严重拖慢响应速度。你可以把自己要做的场景画一张表看一下用户每种意图对应一个技能还是多个技能意图之间是否重叠。如果重叠太多就要考虑合并。这个规划做在前面后面就能少走很多弯路。6.3 测试时容易被忽略的“边界输入”问题做 Agent 开发测试时最容易犯的错是只测“正常情况”不测“边界输入”。我在完善技能的过程中专门用了一批刁钻的输入测试搜一个不存在的主题比如“哈哈哈哈不存在的内容”技能返回的结果为空模型能否妥善处理搜一个极其宽泛的主题比如“科技”搜索结果的多样性会非常高模型会不会不知道如何组织答案搜一个含多义词的主题比如“苹果”模型会不会无法判断是指水果还是科技公司这些边界测试非常有用。如果技能的描述信息没有写清楚“当结果为空时返回提示信息”或者“当输入主题过于宽泛时建议用户进一步细化”模型在遇到这些场景时就会显得很笨。好的技能描述应该预判这些情况给模型兜底方案。这也是“最佳实践”和“能用”之间最大的区别。6.4 从“能用”到“好用”Skills 的迭代优化方法论任何一个 Agent 都不是一次就能做到“好用”的它需要一个迭代过程。我在这次实践中总结出了一个比较实用的迭代循环分享出来定义验收标准。做任何技能前先想清楚“用户输入什么样的问题Agent 返回什么样的结果才算合格”。没有验收标准后面所有的优化都是无源之水。跑一批基线测试。每次调整技能后用同一批测试题跑一遍对比效果变化。定位问题归属。回答不好到底是技能的返回信息不够还是模型的总结能力不行还是提示词没有引导对建议先把技能单独测试再把模型单独测试最后组合起来测定位更精准。改一处测一轮。不要同时改技能描述、提示词、代码逻辑改完你不知道是哪个改动起了效果。一次动一点老测试重跑错了才能快速回滚。形成经验文档。每解决一个问题把问题描述、原因、解决方案、测试结果记录下来。时间一长这份文档的价值可能超过技能本身。6.5 从这次实践里学到的几点“深水区”心得最后说点比较“个人向”的体会可能对正在做 Agent 开发的你有一点参考价值。第一Agent 的聪明程度和你的工具设计水平成正比。模型本身就像一个刚入职的新人能力很强但不知道公司的流程和资源在哪里。Skills 就是那本“员工手册”手册写得越清楚新人上手越快。我发现自己在优化技能描述上花的时间最终都会体现在 Agent 的实际表现上。第二数据和信息链路的稳定性比模型选型更重要。很多团队做 Agent 时把大量精力花在“换一个更大的模型”上忽略了底层工具的可靠性。我的实际体验是只要信息链路稳定、结果结构清晰小模型也能做出让人满意的 Agent反过来工具乱成一团模型再强也救不回来。第三少让模型做“背诵题”多让模型做“分析题”。这是我这次实践最大的收获。如果所有目标都靠模型记住那它一定做不好但如果你给它提供检索渠道、搜索技能、知识库让它专注于分析、归纳、决策它就能展现出真正的价值。所谓“全能 Agent 养成”养的不是“一个什么都知道的大脑”而是“一个知道怎么找答案的执行体”。6.6 后续可以怎么扩展这个 Agent 目前已经能完成搜索、清洗、整理、报告生成这条链路后续有很多值得继续做下去的方向接入知识库让 Agent 能基于私有文档回答问题这能极大拓宽应用场景增加定时触发机制让 Agent 定期主动采集并汇报信息做一个自动化情报助手增加多渠道通知能力把生成报告推送到邮件、企业微信或者钉钉让 Agent 从“问答工具”变成“主动服务者”加入用户反馈采集逻辑根据用户的点赞、点踩来动态调整技能调用的优先级。这些方向我都在陆续尝试后面有新进展再写文章补充。如果你按照这篇文章的步骤走了一遍相信你也会感受到Agent 开发没那么玄乎本质上是把“模型能力”和“工程能力”反复对齐的过程。Skill 是最适合切入的对齐工具它足够小、足够独立又能被模型通过自然语言灵活调用。找一个你熟悉的场景动手做第一个 Skill比看十篇文章都有用。