企业官网建设流程全解析

先说明一点：这篇写的是我自己在腾讯云上从零搭一个“带 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 的时候，流程大概是这样的：

1. 进入“技能管理”页面，选择“创建技能”。
2. 填写技能的基础信息，比如名称叫“资料搜索与整理”，描述写清楚这个技能是“接收一个主题关键词，返回相关的资料列表和摘要”。
3. 配置参数 schema，我定义了keyword（字符串，必填）、max_results（整数，默认 5）、language（字符串，默认"zh"）。
4. 选择执行方式，这一步我接了一个云函数，函数内部调用了搜索 API 并解析结果。
5. 保存并发布，技能就进入可用状态了。

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, params=params, timeout=10) 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 的一个高级能力：多步骤技能编排。我不再写一个单纯的云函数，而是把技能分成几个内部节点：

1. 搜索节点：根据 keyword 请求外部搜索服务，拿到原始结果。
2. 清洗节点：去掉明显无关的链接、去重、过滤掉空标题或空摘要的条目。
3. 重排节点：根据关键词在标题和摘要中出现的频率对结果排序，把相关性最高的放在前面。

在控制台上，这种多步骤技能可以用函数流转来实现。简单来说，就是每个节点是一个云函数或者处理单元，节点之间用参数传递结果。第一个节点的输出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 常见问题速查表

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 都不是一次就能做到“好用”的，它需要一个迭代过程。我在这次实践中总结出了一个比较实用的迭代循环，分享出来：

1. 定义验收标准。做任何技能前，先想清楚“用户输入什么样的问题，Agent 返回什么样的结果，才算合格”。没有验收标准，后面所有的优化都是无源之水。
2. 跑一批基线测试。每次调整技能后，用同一批测试题跑一遍，对比效果变化。
3. 定位问题归属。回答不好，到底是技能的返回信息不够，还是模型的总结能力不行，还是提示词没有引导对？建议先把技能单独测试，再把模型单独测试，最后组合起来测，定位更精准。
4. 改一处，测一轮。不要同时改技能描述、提示词、代码逻辑，改完你不知道是哪个改动起了效果。一次动一点，老测试重跑，错了才能快速回滚。
5. 形成经验文档。每解决一个问题，把问题描述、原因、解决方案、测试结果记录下来。时间一长，这份文档的价值可能超过技能本身。

6.5 从这次实践里学到的几点“深水区”心得

最后说点比较“个人向”的体会，可能对正在做 Agent 开发的你有一点参考价值。

第一，Agent 的聪明程度和你的工具设计水平成正比。模型本身就像一个刚入职的新人，能力很强，但不知道公司的流程和资源在哪里。Skills 就是那本“员工手册”，手册写得越清楚，新人上手越快。我发现自己在优化技能描述上花的时间，最终都会体现在 Agent 的实际表现上。

第二，数据和信息链路的稳定性，比模型选型更重要。很多团队做 Agent 时把大量精力花在“换一个更大的模型”上，忽略了底层工具的可靠性。我的实际体验是：只要信息链路稳定、结果结构清晰，小模型也能做出让人满意的 Agent；反过来，工具乱成一团，模型再强也救不回来。

第三，少让模型做“背诵题”，多让模型做“分析题”。这是我这次实践最大的收获。如果所有目标都靠模型记住，那它一定做不好；但如果你给它提供检索渠道、搜索技能、知识库，让它专注于分析、归纳、决策，它就能展现出真正的价值。所谓“全能 Agent 养成”，养的不是“一个什么都知道的大脑”，而是“一个知道怎么找答案的执行体”。

6.6 后续可以怎么扩展？

这个 Agent 目前已经能完成搜索、清洗、整理、报告生成这条链路，后续有很多值得继续做下去的方向：

• 接入知识库，让 Agent 能基于私有文档回答问题，这能极大拓宽应用场景；
• 增加定时触发机制，让 Agent 定期主动采集并汇报信息，做一个自动化情报助手；
• 增加多渠道通知能力，把生成报告推送到邮件、企业微信或者钉钉，让 Agent 从“问答工具”变成“主动服务者”；
• 加入用户反馈采集逻辑，根据用户的点赞、点踩来动态调整技能调用的优先级。

这些方向我都在陆续尝试，后面有新进展再写文章补充。如果你按照这篇文章的步骤走了一遍，相信你也会感受到：Agent 开发没那么玄乎，本质上是把“模型能力”和“工程能力”反复对齐的过程。Skill 是最适合切入的对齐工具，它足够小、足够独立，又能被模型通过自然语言灵活调用。找一个你熟悉的场景，动手做第一个 Skill，比看十篇文章都有用。