基于腾讯云AI Skills的Agent开发实战：从技能抽象到多工具编排

做 Agent 开发这段时间我踩过最大的坑不是模型能力不够而是让 Agent 真正“干成事”。模型再聪明如果不知道怎么调用工具、不知道在什么场景下该执行什么动作最后产出的多半是一堆看似合理但根本不能落地的“幻觉方案”。后来我把整套流程迁移到腾讯云上结合 AI Skills 重新梳理了一遍 Agent 的构建方式效果提升非常明显。这篇就聊聊我在腾讯云 AI Skills 上做 Agent 开发时的完整思路、实操过程和一些值得注意的细节希望能给正在折腾 Agent 的朋友一些参考。先说一个背景我这里说的 Agent不是简单套一个 Prompt 的聊天机器人而是具备“感知、决策、执行、反馈”闭环的智能体程序。也就是说它要有能力根据用户输入拆解任务、调用外部工具或接口、拿到结果后再继续推进下一步。这个过程中最容易出问题的环节就是“工具调用”。模型生成一段调用参数很简单但怎么定义工具、怎么传参数、怎么让模型稳定选择正确的工具非常考验工程功底。所以腾讯云 AI Skills 这套机制出来后我第一反应是这正好能解决工具调用标准化的问题。它把“技能”抽象成一个可复用的单元让 Agent 不用从零去学和适配每个 API而是直接挂载技能就能干活。这里我结合自己的实际项目把从设计到部署的完整路径拆开讲讲。1. Agent 构建的第一步为什么先定技能再选模型1.1 我之前做 Agent 的错误示范最早我做 Agent 的时候习惯先去选模型模型定完再开始写 Prompt最后才考虑工具调用。这个顺序倒过来做问题特别多模型能力很强但工具调用格式一复杂模型就开始“自由发挥”参数名能给你变出好几个版本更别提多轮调用时的上下文错乱。后来我意识到Agent 的核心骨架是“能力边界”也就是这个 Agent 到底能做什么事。能力边界要先定下来模型反而成了可以随时替换的执行引擎。和我一样从聊天机器人转过来做 Agent 的人最容易忽略的就是这一点聊天机器人是模型为主Agent 是能力为主。1.2 AI Skills 如何作为 Agent 的能力单元腾讯云 AI Skills 的核心是把一个具体能力包装成标准化的技能单元。每个技能单元包含能力描述、输入参数定义、调用方式和返回结果格式。Agent 在运行时可以根据用户意图动态匹配并调用这些技能。这相当于给 Agent 装了一套“标准化接口”。我不用再为每个新功能单独写工具调用逻辑只需要新增一个技能然后在 Agent 的策略层加一个匹配规则就行。技能做多了之后复用性优势非常明显。举个例子我做了一个“代码审查 Agent”里面会用到“获取代码差异”“扫描敏感信息”“生成审查报告”三个技能。这三个技能是完全解耦的后续做“CI 机器人”的时候前两个技能直接复用不用重写。注意AI Skills 不是一个“所有工具一把梭”的魔法箱。它的价值在于标准化和复用而不是替代你的业务流程。技能定义得好不好直接决定 Agent 后期能走多远。1.3 哪些场景适合用 AI Skills 构建 Agent不是所有 Agent 都值得用 AI Skills 这套体系。这里我根据实际接触过的项目整理了一个粗略的判断标准强工具依赖型Agent 需要频繁调用外部系统、数据库、API 的场景AI Skills 的价值很大。规则相对明确技能输入输出可以标准化不需要太多模糊处理的场景特别适合。高频复用的能力沉淀你有很多项目公用一套基础能力比如内容审核、数据查询、文件解析沉淀成技能收益最高。纯对话型应用如果只是陪聊、写文案、做翻译不太需要复杂的工具调用那 AI Skills 可能有点杀鸡用牛刀。2. AI Skills 的核心设计逻辑从工具到技能的抽象2.1 技能声明的信息结构要把一个能力变成技能需要做一次完整的信息结构化。我在腾讯云 AI Skills 里定义技能时通常包含以下核心要素技能名称简短、无歧义最好动词开头比如“查询订单状态”“生成周报数据”。能力描述说清楚这个技能是干什么的、适合什么场景、什么时候不该用。描述越准确模型理解越到位。输入参数 Schema结构化的参数定义包括类型、必填项、取值范围、示例值。这一步直接决定模型能不能生成正确的调用参数。执行逻辑技能被调用后执行的操作可能是调用云函数、请求内部接口或者运行一段固定的数据处理流程。输出格式定义统一返回结构方便 Agent 做后续解析。2.2 为什么参数 Schema 是技能的“命门”如果你用过 Function Calling应该知道模型有时候会“一本正经地瞎填参数”。比如日期格式你要求 YYYY-MM-DD它能给你传“昨天”“明天”这种相对时间。参数 Schema 定义得好能极大减少这类问题。我的建议是给每个参数都写清楚格式要求、取值范围以及一个示例值。如果参数之间存在依赖关系也要在描述中显式说明。比如创建服务器实例时“实例规格”和“可用区”往往有关联不说明的话模型很容易生成一个某个可用区根本不支持的规格组合。实操心得参数描述并不怕啰嗦怕的是含糊。我给技能写参数描述时的准则是——假设使用这个技能的人完全不懂业务看了描述也能填对参数。2.3 技能执行逻辑的封装方式技能不只是定义接口真正干活的逻辑也包含在内。在腾讯云上我通常有两种封装方式云函数方式把执行逻辑封装成云函数技能调用时触发云函数运行。适合逻辑相对独立、需要一定计算资源的场景。API 网关方式把技能映射到已有的 HTTP API技能定义好后直接绑定网关地址。适合已有后端服务的场景。两种方式我都实际用过。云函数适合快速落地、想省去运维麻烦的场景API 网关适合公司内部已经有很多现成服务、想直接暴露给 Agent 使用的场景。没有绝对的好坏看你的基础设施选型。3. 在腾讯云上搭建完整 Agent 的实操步骤3.1 环境准备工作我在腾讯云上的 Agent 环境包含这几部分一台云服务器作为 Agent 运行载体我用的轻量应用服务器2C4G 配置跑日常实验足够。一个对象存储桶用来存放 Agent 运行时产生的临时文件和日志。云函数服务用于承载 AI Skills 的执行逻辑。API 网关把技能和外部请求统一接入。这里有个小建议一开始不用把环境搞得太复杂。先用云服务器 云函数这套最小组合把流程跑通后面再逐步加入网关、日志、监控这些服务。3.2 从零定义第一个技能我拿“服务器状态巡检”练手我定义的第一个技能是“服务器状态巡检”。这个技能输入一个 IP 或服务器 ID输出 CPU、内存、磁盘使用率和关键服务运行状态。定义过程如下在腾讯云控制台进入 AI Skills 管理页面创建新技能。填写技能声明信息名称定为“server_status_check”。写好能力描述重点说明此技能用于检查指定云服务器的资源使用情况和关键进程状态输入服务器 ID输出结构化状态数据。配置输入参数这里我只定义了一个参数server_id字符串类型必填。选择执行方式我用云函数承载编写了一段 Python 代码调用云监控 API 拉取数据。Python 核心逻辑大致长这样import json from tencentcloud.common import credential from tencentcloud.monitor.v20180724 import monitor_client, models def main(event, context): server_id event.get(server_id, ) if not server_id: return {code: 400, msg: server_id is required} cred credential.Credential(secret_id, secret_key) client monitor_client.MonitorClient(cred, ap-guangzhou) req models.DescribeBaseMetricsRequest() # 这里省略具体监控指标拼装逻辑 result client.DescribeBaseMetrics(req) return {code: 0, data: json.loads(result.to_json_string())}补充说明这段代码主要是演示结构生产环境需要把密钥放到腾讯云的密钥管理服务中不要明文写在代码里。定义好技能后我在测试面板里模拟调用了一次传入一个测试用的 server_id返回结果符合预期。第一个技能跑通之后后面的技能基本就是复制这个模板继续扩展。3.3 把技能接入 Agent 的策略层技能定义好之后就要让 Agent 知道“什么场景下调用什么技能”。这一层我管它叫策略层。在腾讯云 AI Skills 的框架下我是这样设计的Agent 接收用户请求后先做意图识别。如果识别为“查询类”意图进入技能匹配模块从技能库里选出最匹配的技能填充参数触发调用如果识别为“操作类”意图则先做权限校验再触发技能执行链。这里我最想强调的是意图识别和技能匹配要分开做。一开始我图省事让模型一步到位直接返回技能调用指令结果就是模型经常在意图不明确的时候强行选一个技能。现在我会先做一次意图分类再让模型基于分类结果做技能匹配准确率明显更高。3.4 多技能编排把简单技能组合成复杂能力单技能只能完成单一动作真实 Agent 往往需要多个技能配合。比如我的“服务器异常排查 Agent”完整流程涉及四个技能获取服务器基础信息确认服务器 IP、地域、镜像、配置信息。拉取监控指标获取 CPU、内存、磁盘、网络等时序数据。查询最近变更记录检查是否有近期配置变更或代码部署操作。生成排查报告汇总以上信息输出结构化报告给用户。技能的编排逻辑是写在一个工作流定义里的Agent 根据用户的请求动态走完这个流程。这种设计的好处是每个技能都能单独测试和复用编排层只管流程。4. 常见问题与排查技巧实录4.1 模型选不对技能或参数乱传怎么办这个问题在 Agent 开发中几乎一定会遇到。我的排查思路是按这几点来检查技能描述是否足够具体。描述里不要只说“查询服务器状态”要说清楚“用服务器 ID 查看云服务器的 CPU、内存、磁盘使用率以及进程存活状态”。模型对描述的敏感度远超你想象。检查参数 Schema 是否约束到位。取值范围、格式、示例值都要写清楚。模型对枚举值的遵循度很高但对开放性的字符串参数容易出问题。检查是否有技能互相干扰。如果两个技能的功能边界模糊模型确实会来回选错。此时建议合并技能或者把边界条件在描述中显式写出来。4.2 技能调用超时和限流怎么处理技能执行不是瞬间完成的尤其是涉及云函数冷启动、外部 API 请求时耗时可能不可控。我在腾讯云上遇到最多的是两类问题函数冷启动导致的首次调用超时。解决办法是给函数配置并发预留或者写一个定时触发器做“预热”。外部 API 限流导致技能执行失败。解决办法是在技能执行逻辑里增加重试机制并设置退避策略。我的经验重试不是无脑重试要设置最大重试次数和退避间隔。通常 3 次重试、指数退避就够了再多反而会加重下游系统的压力。4.3 Agent 多轮对话中的上下文丢失问题这是 Agent 开发里最让人头疼的问题之一。用户在第一轮让 Agent“查一下 A 服务器的状态”第二轮说“顺便看看磁盘”如果上下文处理不好Agent 可能完全不知道“磁盘”指的是哪台服务器的磁盘。我采用的方案是把关键上下文以结构化的“会话记忆”形式保存下来每轮对话结束后更新一次。这个记忆里记录的不只是聊天内容还包括已调用的技能、关键参数和返回结果摘要。这样下一轮 Agent 在理解意图时就不会“失忆”。4.4 技能测试不能只看成功路径最后分享一个我在测试环节强调很多次的点一定要覆盖失败路径。包括参数缺失、参数格式错误、目标资源不存在、外部服务不可用等。我在每个技能里都加了异常返回的分支代码保证技能在出错时返回结构化错误信息而不是直接抛异常。这样处理之后Agent 拿到错误信息就可以继续做下一步决策比如告诉用户“查询失败请检查服务器 ID 是否正确”而不是整个流程中断。5. 几个能直接提升 Agent 质量的经验5.1 技能库要定期做“减法”技能太多也会让模型犯选择困难症。我每两周会看一次技能调用日志把一周内都没被调用过的技能先下线整理。不是删除是暂时下线。下线之后模型的选择空间变小匹配准确率会提升。5.2 日志结构化是后期排查的基石Agent 跑起来之后最怕的就是出问题不知道怎么查。我从一开始就把日志做了结构化处理每条日志包含时间戳、会话 ID、意图分类结果、命中技能、参数信息、返回状态和耗时。排查问题的时候直接按会话 ID 拉时间线非常高效。5.3 人机协作的分级设计不是所有请求都需要 Agent 自动完成。我的设计里有一个“分级策略”低风险操作查询、分析、生成Agent 自动完成。中风险操作数据修改、配置调整Agent 生成方案用户确认后执行。高风险操作删除资源、变更线上配置Agent 只做方案建议不自动执行。这个分级策略帮我在测试阶段避免了很多次“差点酿成大祸”的操作。做 Agent 的人一定要记住不是越自动化越好而是越可控越好。6. 一次完整的复盘从需求到落地我做了一个自动化运维 Agent为了更直观地展示整个流程我复盘一个最近做的“自动化运维 Agent”。它的需求很简单用户用自然语言描述需求Agent 自动完成服务器信息查询、日志分析和基础异常判断最终输出一份运维报告。我落地这款 Agent 的步骤是先定义技能清单一共定义了四个技能服务器信息查询、日志检索分析、监控指标拉取、报告生成。逐个开发并测试每个技能确保独立调用都返回正确结果。设计编排流程让 Agent 能够根据用户描述自动决定执行哪些技能以及执行顺序。接入企业微信机器人作为交互入口用户可以随时发起请求并接收报告。上线后持续观察日志针对覆盖不到的场景迭代技能描述和编排策略。这个 Agent 上线后帮我省掉了大量重复性的运维信息收集工作。原来手工查一遍要二十分钟的事现在一两分钟就能出结果。而且因为报告结构一致后续做周报汇总也轻松很多。7. 后续扩展方向这套基于腾讯云 AI Skills 的 Agent 架构跑顺之后后续的扩展方向其实很清晰。一个是把技能库做得更丰富比如接入消息队列、容器编排、数据库运维等能力让 Agent 的覆盖面更广。另一个方向是让 Agent 具备一定程度的自学习能力比如根据历史调用记录动态优化技能描述和参数默认值。还有一个我很看好的方向是把 Agent 的“经验”沉淀成技能。比如解决过一次线上故障之后把整个排查过程固化成技能模板下次遇到类似问题时Agent 可以直接按模板处理。这相当于把人的经验持续转化为系统的能力越用越聪明。虽然这个方向要做得足够好还需要不少工程打磨但方向本身是非常值得投入的。最后分享一个小技巧。如果你也在做 Agent 技能定义写完技能描述之后先别急着上线拿几个典型用户问题跑一遍测试看看模型理解是否和你预期一致。哪怕只调整几个词实际效果都会有明显差别。这个细节我试过很多次每次都有效。