企业官网建设流程全解析

做 Agent 开发这段时间，我最大的感受是：真正难的从来不是模型能力，而是工程化落地。你让一个大模型开口说话很容易，但要让它在生产环境里稳定地查订单、调接口、写工单、判异常，每一步都是细节。腾讯云 AI Skills 我用了几个月，它把 Agent 开发里最繁琐的技能注册、调度编排、工具接入、知识库管理这些脏活都接管了，让我能把精力集中在最核心的业务逻辑上。今天这篇就不整虚的，把我从设计思路到踩坑记录完整摊开，全程围绕“怎么在腾讯云 AI Skills 上把一个 Agent 从想法养成可用产品”这条主线来讲。

先说清楚这文章适合谁：已经在做 Agent 相关开发，想找一个更省心的平台承载业务；或者刚从提示工程转向 Agent 开发，需要一套完整的落地思路。如果你只是想看概念科普，那这文章会显得信息密度有点高，但如果你真要上手干，我建议边读边打开控制台对照着操作。

1. 项目整体思路：为什么选腾讯云 AI Skills 做 Agent

1.1 Agent 开发的第一道坎根本不是模型

去年我第一次带团队做一个客服 Agent 项目时，选了当时最流行的开源框架，结果光是把环境搭起来就花了一周。向量库要自己部署，嵌入模型要自己接，工具调用的回调逻辑要自己写，每加一个新工具就得改一遍调度层代码。做到中期，团队一大半时间都在跟基础设施搏斗，真正用来优化业务逻辑的时间少得可怜。

这就是我后来转向腾讯云 AI Skills 的核心理由。Agent 工程化的复杂度是幂次增长的：模型推理只是其中一环，前面有意图识别、技能路由，后面有工具执行、结果校验、记忆管理、上下文裁剪。自建方案意味着每一环都要自己造轮子，而且这些轮子相互之间的兼容性还得自己维护。对一个想把 Agent 尽快送到生产环境的团队来说，这是在消耗最宝贵的资源。

AI Skills 的定位恰好卡在“模型之上、业务之下”这一层。它不是一个模型 API，而是一套 Agent 运行时：你定义好技能（Skill），声明清楚这个技能是干什么的、输入什么、输出什么，平台负责在模型和技能之间做路由和调度。这就像你雇了一个能力很强的前台，客户说什么需求，他立刻知道该转给哪个部门。

1.2 AI Skills 到底做了什么

我理解 AI Skills 的价值可以拆成四块，每一块都对准自建方案里最疼的点。

第一是自然语言定义技能。传统工具调用需要写一堆函数签名、schema 映射、类型转换，在 AI Skills 里你只需要用自然语言描述技能职责，再定义好输入输出的 JSON Schema，剩下的解析和映射平台自己处理。这极大降低了技能接入的门槛，也让非资深后端的人能参与到 Agent 开发中。

第二是编排与路由。多个技能之间的调度在自建方案里是写代码做 if-else，技能多了以后维护成本爆炸。AI Skills 的模型调度层会根据用户意图自动匹配技能，匹配不上时还能走兜底逻辑或者多轮澄清，这套东西我自己写至少得一个月。

第三是侧载知识与上下文管理。Agent 要回答业务问题，光靠模型记忆肯定不行。AI Skills 内置知识库能力，你现在可以把业务文档切好传上去，平台负责向量化和检索。上下文窗口的管理它也会自动处理，历史消息怎么裁剪、关键信息怎么保留，这些在自建方案里非常头痛的事情，平台都有了默认策略。

第四是配套的调试和观测能力。每个技能被触发了几次、模型怎么理解用户意图、哪一步响应超时，控制台里都有链路追踪。这些在生产环境里属于保命功能，自建方案要做到同等水平，又是好几个人月的投入。

1.3 什么时候该用平台，什么时候该自建

我不是说所有项目都应该无脑用平台方案。经过这段时间实践，我的判断标准大概是这样的：

• 业务验证期、快速原型期，无脑选平台。你需要的是快速验证 Agent 有没有商业价值，而不是在基础设施上浪费时间。
• 业务逻辑复杂、技能数量大、多人协作开发，平台的调度和观测价值会成倍放大。
• 已有完整后端体系和工具注册中心的大厂，如果内部已经沉淀了成熟的 Agent 框架，就没必要迁移。
• 对数据主权极度敏感、所有推理必须私有化部署的行业，平台方案可能不适合，但这部分场景在中小团队里占比其实没想象中高。

我个人的选择逻辑很朴素：凡是没有硬性合规要求拦住我的项目，默认先用平台方案把业务跑通，等量级和复杂度真的上来了，再做架构迁移。用最低成本验证价值，比一开始就搞大而全的架构重要得多。

2. Agent 能力设计：先想清楚再动手

2.1 明确 Agent 的定位和边界

很多 Agent 项目扑街，不是技术不行，是定位没想清楚。你要做的 Agent 到底是个什么角色？是 7x24 小时无人值守的自动处理员，还是辅助人工提效的副驾驶？边界在哪里？哪些事它绝对不能干？

我这里用一个具体的例子来串后面所有内容。假设我们要做一个电商售后 Agent，它的核心任务是处理用户的售后请求：查订单、查物流、提交退货申请、解释退货政策，这些是它的职责范围。但它不做复杂的客诉安抚，用户情绪激烈或者要求超出政策范围的赔偿时，它会主动升级给人工客服——这就是边界。

边界这东西一定要在设计阶段写死，而不是等 Agent 上线后出了问题再打补丁。没有边界的 Agent 就是一个什么都不会拒绝的答非所问机器，它会把模型幻觉放大十倍，因为它在能力不足的时候也不会说“我做不到”。

定义边界有两件事必做：第一，明确技能的触发条件，只有命中条件才让 Agent 接管；第二，明确拒绝策略，条件不满足时直接说明并转人工，而不是硬着头皮瞎编。

2.2 技能拆解：从业务需求到原子能力

边界定完之后，核心工作就是把业务能力拆成一份技能清单。我的习惯是用一个表格来管理：

做这个拆解的时候，我有一条经验：技能的粒度必须控制在“一次对话能完成闭环”的范围内。太粗的技能（比如“处理售后”），模型根本不知道该怎么处理；太细的技能（比如“验证手机号”“查询商品编号”），会让 Agent 在单次请求里跳来跳去，既慢又容易出错。

还有一个容易忽略的点——技能之间的优先级和互斥关系。比如用户问“我上周买的鞋能退吗”，Agent 先要搞清楚他买了什么，这可能需要先触发订单查询技能，再触发政策问答技能。这种跨技能协作在 AI Skills 里可以通过配置技能依赖实现，但前提是你设计时就把依赖关系画清楚。

2.3 知识库设计：让 Agent 说“有根据”的话

Agent 要回答业务问题，光靠模型内置知识远远不够。以售后场景为例，退货政策、运费规则、特殊品类处理办法，这些内容每天可能都在变，模型显然不可能及时更新。把这类信息放进知识库，让模型在回答时先检索再生成，是目前最稳妥的方案。

知识库的使用有几点实操心得。第一，文档要先清洗再上传。我在第一次接入时直接把产品手册的 PDF 传了上去，结果很多表格被切得七零八碎，检索命中率惨不忍睹。后来改成先转成 Markdown，人工把表格拆成条目式描述，再分段上传，效果立刻不一样。

第二，切分粒度直接影响检索质量。切太大了，检索到的内容不精准，浪费上下文窗口；切太小了，语义完整性又会被破坏。我测试下来，按语义段落切分，每段控制在 300 到 500 字比较合适。也可以按章节结构切，但要保证每个切块内是完整表达一个意思。

第三，知识库不是一次建完就完事的。售后政策改一次，知识库就得跟着更新一次，而且旧版本会产生干扰。我现在的做法是给知识库文档加版本号，更新时直接替换整个文档，不清除旧版会导致模型检索到互相冲突的内容，这点我后面吃了大亏。

3. 实操过程：从零搭建一个售后 Agent

3.1 环境准备与基础配置

这里我默认你已经有了腾讯云账号，并且开通了 AI Skills 服务。第一次进入控制台可能会觉得选项很多，但其实整个搭建流程可以压缩成四个步骤：创建应用、配置模型、定义技能、接入知识库。

创建应用时最关键的选择是模型配置。AI Skills 支持多个模型，你需要根据场景做取舍。我最早用的是效果最强的旗舰模型做测试，发现响应确实好，但成本和延迟都偏高。后来我把应用拆成两条链路：日常咨询走快速模型，复杂判断走增强模型。平台支持这种配置，这也是一个很重要的省钱技巧。

关于模型参数，我直接给一套经过验证的初始值：温度（temperature）0.2 到 0.4 之间，top_p 0.8 左右。Agent 场景和闲聊场景完全不同，它做的是确定性任务，回答必须贴近事实、格式稳定，温度太高会让技能参数抽取这种关键环节变得飘忽不定。我自己测试时把温度调到 0.7，结果模拟用户说“帮我退一下上周买的那双鞋”，模型居然把鞋子的颜色也当成参数抽了出来，出现了幻觉。

3.2 技能定义与逻辑实现

技能定义是整个 Agent 的核心。我们拿“物流跟踪”这个技能来走一遍。

首先在控制台创建一个新技能，技能名称我用的是track_logistics，描述我写的是“根据订单号查询物流轨迹，返回包裹当前节点、预计到达时间和最近几条物流记录”。描述看起来简单，其实非常关键——它是模型做意图路由的主要依据，描述写得含糊，模型就可能把“查物流”的请求错误路由到“订单查询”技能上。

然后是输入参数。物流跟踪技能只需要一个订单号，它的 JSON Schema 大致长这样：

{ "type": "object", "properties": { "order_id": { "type": "string", "description": "用户提供的订单编号，一般为 20 位数字" } }, "required": ["order_id"] }

order_id 的描述要写清楚格式要求，“20 位数字”这个信息会帮助模型从用户的话里更准确地抽取。如果不写，用户说“帮我查一下 JD123456 的物流”，模型可能连前缀带数字一起填进 order_id，到了后端就查不到。

技能的后端实现，AI Skills 支持用云函数承载。我的做法是写一个云函数接收order_id，调用公司现有的物流查询 API，然后把结果格式化成平台要求的 JSON 返回。这里有一个非常重要的点：返回结构一定要规范，字段名要自解释，因为模型要根据返回内容生成面向用户的回答。字段如果是a、b这种缩写，模型根本猜不出含义。

def main(event, context): order_id = event.get("order_id", "") if len(order_id) != 20 or not order_id.isdigit(): return {"code": 400, "msg": "订单号格式不正确"} # 调用物流 API 查询 result = query_logistics_api(order_id) return { "code": 0, "data": { "status": result["status"], "current_node": result["current_node"], "eta": result["eta"], "track_records": result["records"] } }

从这段代码能看出一个原则：技能的参数校验要在函数里做，不能依赖模型。模型抽取参数偶尔会漏、会错，函数必须兜住这层，格式不对就直接返回错误信息，由 Agent 引导用户重新提供。

3.3 知识库接入与多轮对话调优

知识库接入在控制台操作很直观，但有几个细节值得展开。文档上传后，平台会自动做切片和向量化，但默认的切分策略不保证适合你的业务文本。我建议在接入前自己做一轮预处理：

• 把 PDF/Word 转成纯文本或 Markdown；
• 删除页眉页脚、目录、重复水印这些噪声；
• 把表格转成“字段：值”的条目式描述；
• 长段落按语义拆开，每段不超过 500 字。

这些预处理能显著提升检索命中率。我经历过一次对比，同样一份退货政策文档，预处理后用户的“电源适配器坏了能单独退吗”这类问题，检索命中准确率提高了将近三成。

知识库接入后，要做一轮很关键的测试：把常见的用户问题准备成一批测试集，挨个问，看 Agent 的回答是否引用了知识库内容。我见过不少 Agent 项目上线后用户反馈“回答得挺好但和事实有出入”，原因就是模型没有强制走知识库，用自己的内置知识回答了。AI Skills 中这点可以通过设置“优先检索再回答”的提示词策略来解决，但前提是你得测试验证。

多轮对话的调优是另一个隐蔽的深坑。Agent 开发早期的典型问题是：单轮对话效果都很好，但一旦用户在一次会话里连续问好几个问题，Agent 就开始丢上下文。比如用户说“帮我查一下订单 123 的物流，对了我还想退了这个商品”，模型如果没理解好，可能调用了物流技能却把退货请求忘掉。

这种情况下，技能设计要帮助模型管理状态。我现在的做法是在技能描述里写清楚“如果用户在同一句话里表达了多个意图，请分别调用对应技能”。触发了多轮对话以后，每个技能的输入参数都要设计为自包含的，不依赖上一个技能的输出。

3.4 测试验证与灰度发布

测试环节的经验我浓缩成一句话：别在控制台里跟 Agent 瞎聊，要建一套可复现的测试用例集。

我把售后场景的测试用例分成三类。正常流程：订单能查到、物流能跟踪、退货能提交；边界流程：订单号不存在、订单已超过退货期、用户要求退还超出政策的金额；对抗流程：用户故意输错订单号、用户给的信息不完整、用户连续追问和政策无关的问题。每一类准备 10 组以上对话，可以把每次会话导出来，这样改一轮提示词就能快速回归。

灰度发布是我强烈建议做的环节。新技能或者新知识库上线前，先切 5% 到 10% 的流量观察一段时间，看准确率和转人工率的变化。Agent 和传统代码不一样，它的问题不会在发布时立刻暴露，大概率会在某些刁钻的用户表达上翻车，灰度就是为了给这种不确定性留缓冲。

4. 常见问题与避坑指南

4.1 意图识别与路由阶段的典型问题

做售后 Agent 这几个月，我在意图识别与技能路由阶段遇到的坑，排第一位的永远是技能描述写得太泛。最典型的表现是多个技能描述里出现同一个关键词，比如“订单查询”写了“查订单”，“物流跟踪”也写了“查订单”，模型路由时就会纠结——它可能随机选一个，也可能两个都不选，走兜底逻辑。解决方式很简单，给每个技能限定严格和唯一的触发场景，关系统一调整。

第二个高发问题是用户输入不完整时 Agent 直接崩溃。用户说“帮我退货”，但没有订单号，也没有商品信息。如果技能参数里把 order_id 设成了必填，模型可能会强行编造一个订单号填进去。规避这个问题的做法是：在技能描述里写明“如果用户没有提供订单号，请先向用户询问，不要臆造”，并且在参数校验里做好必填判断。

这类问题排查起来很依赖日志。AI Skills 控制台的调试链路里能看到模型当前调用时用到的完整提示词、参数抽取的中间结果和技能执行结果，每一步的中间状态都有记录，发生路由错误时直接看链路日志，比靠猜靠谱一个量级。

4.2 API 调用与外部系统对接的坑

Agent 技能一旦对接真实业务系统，问题就从“模型层”转移到了“工程层”。我遇到过的第一个坑是响应超时：物流查询 API 偶尔需要 3 秒以上才返回，而技能默认的超时时间不够，导致模型侧显示调用失败，用户侧看到的就是“Agent 没有回答”。如果你的外部接口稳定时延偏高，一定要在技能配置里把超时时间调大，或者改成异步查询模式。

第二个坑是对端接口异常时的错误处理。真实业务接口不可能永远稳定，限流、返回空数据、内部错误都是常态。如果技能函数里不做容错，任何一次上游抖动都会直接暴露给用户。我的做法是在技能函数里统一捕获上游异常，返回一个带有code字段的错误结构，并且把错误原因写清楚。这样模型看到错误结构后，会知道该说“系统暂时繁忙”还是“订单不存在”，而不是自己脑补一个答案。

还有个小事故值得提一下：有一次我把生产物流接口的响应里加了一个字段，结果知识库里的旧文档也在描述这个字段的旧含义，两边的信息冲突直接导致模型回答自相矛盾。这让我养成了一个习惯：技能返回的数据结构和知识库描述，必须放到同一个版本控制体系里管理，改动任何一方都要检查另一方是否需要同步。

4.3 成本与性能优化心得

Agent 项目的成本结构很容易被忽视。上线第一个月我看账单时吓了一跳，钱主要烧在三个地方：模型调用、知识库检索、技能函数的执行。每个环节单独看都不算贵，但乘上用户会话量，数字就非常可观。

我的成本优化经验可以总结成四条：

• 会话复用。同一用户短时间内多次提问，建议复用上下文，而不是每次都从头开始。平台支持会话级配置，设置好之后能省掉不少 token。
• 模型分级。复杂的技能用强模型，简单的技能用轻量模型。售后场景里，“查物流”这种简单查询完全可以用快速模型，只有“退货资格综合判断”这种复杂逻辑才需要旗舰模型。
• 知识库精准召回。检索时设置好返回的片段数，别把整个知识库里相关的内容全部塞进上下文。我默认设的是返回 3 个片段，每个片段不超过 500 字，足以回答问题，又不会让上下文爆炸。
• 技能函数冷启动优化。云函数如果长时间没有被调用，会有冷启动延迟。对核心技能，开启函数的常驻预热，能显著降低第一个请求的响应时间。

性能优化的核心观察指标，我建议盯住两个：端到端响应时间和意图路由准确率。前一个决定用户体验，后一个决定业务效果。每个版本上线后都对比这两个数字，变化趋势能告诉你改动方向对不对。

4.4 排查问题的系统方法论

Agent 出问题时，别急着改提示词。我总结了一套排查顺序，这个顺序可以帮你少走很多弯路：

• 第一步，看链路日志。确认模型调到的到底是哪个技能，有没有路由错。这一步能排查一半以上的“Agent 乱回答”问题。
• 第二步，看参数抽取结果。模型从用户话里抽出来的参数对不对。抽错了，问题在提示词；抽对了但结果不对，问题在后端。
• 第三步，看技能返回结果。云函数有没有报错，返回的 JSON 结构是不是符合预期。
• 第四步，看知识库召回。如果 Agent 回答的内容里应该引用政策但答错了，大概率是知识库没召回正确的内容，去检查文档切片质量和更新状态。
• 第五步，回归测试。修复后把所有历史测试用例跑一遍，防止“修一个旧 bug 引出新 bug”。

这套流程我称为“由外到内定位法”，核心思路是先从模型侧检查，再逐步深入业务侧。Agent 问题的表象往往在模型，但根因经常在工程。只会调提示词的人，遇到工程问题会越调越乱；能把链路一层层剥开看的人，才能定位到真正的根因。

其实“养 Agent”这个说法还挺准确的。它和带一个新员工很像：一开始你得很详细地告诉它边界在哪、什么该做什么不该做，遇到做错的事你得纠正，做得好要给它更明确的正向反馈。AI Skills 这几个月用下来，我最大的体会是它的价值不只体现在把基础设施做好了，更在于那套完整的观测和排查体系，让 Agent 的成长过程可以被审视、被修正。如果你正准备开一个 Agent 项目，我的建议是从一个边界清晰的小场景切入，把技能拆到最细，从最简单的查单机器人开始，一步步养成一个真正可信赖的 Agent。