这项目最初很功利——我就是不想一遍遍回答群里同样的问题“昨天的会议纪要谁整理”“这个待办谁跟了”“下周三的材料什么时候发”每件事单独拆开都不难但一件件堆在一个人身上时间就这么被吃干净了。于是我用了一个周末的“冲动”开始搭一个团队内部的 AI Agent指望它能接住这些日常杂务。等真正动手才发现接大模型 API 只是进门第一步要让 Agent 从“特别能聊”变成“真能干活”背后牵扯到任务拆解、技能封装、上下文记忆、失败恢复、成本控制每一个都是能让人写代码写到凌晨三点的坑。这篇文章就把我当时从 0 到 1 养大这个 Agent 的完整过程记录下来重点写我最后沉淀出来的“腾讯云 AI Skills”最佳实践形态以及我踩坑后总结的经验。如果你也在做 Agent 开发、AI 应用落地或者单纯好奇“Agent 到底是怎么从 Demo 变工具的”希望这篇能给你省几晚上的折腾时间。1. 这项目怎么来的杂务太多才决定养个“什么都会一点的助手”先交代一下背景。我们团队很小但日常沟通链路特别长开会、录音、形成纪要、整理待办、写计划、同步给不同的人。每个人都在说“AI 能提效”可真正落到我们自己身上模型生成的文字再多也没有人愿意去手动把纪要里的每一条待办誊进任务系统。我需要的不只是“会总结的聊天机器人”而是一个能感知任务、拆解动作、调用真实系统并把事情执行完的 Agent。但这个认知也不是一开始就有的。我最开始的雏形特别原始调一个文本生成模型把会议记录粘贴进去让它总结再把总结结果人工复制进表格。用了两天我就受不了了——总结得再好后续动作全是我自己动手等于我写了个程序帮别人做作业作业还是我来交。于是我把方向改成“Agent”让它自己决定调用哪些工具比如读文件、写待办、设置提醒、生成周报。从这一版开始它才算真正“接手”了工作流而不是只当一个高级文本处理管道。围绕这个需求结合“全能 Agent”这个目标我这里先给一个总览性的能力分层后面每个模块我都会讲到。1.1 从“调用模型”到“Agent”中间隔着的不只是代码量很多人误以为 Agent 就是“模型 函数调用工具包”这个理解在 Demo 阶段没错但往生产走会立刻撞墙。我在最初的版本里让模型可以调 3 个工具代码写得很爽当工具到 20 个以后模型经常选错或者参数填得牛头不对马嘴整个执行链路就像一团乱麻。这里需要区分开几个概念。聊天机器人Chatbot只需要一次生成你问一句它答一句输出完就结束。Agent 则是一个“运行循环”理解目标用户这句话背后到底要什么结果拆解计划把目标拆成几步可执行动作调用工具/技能执行真实动作如建待办、拉资料、写文档观察反馈如果调用失败或中间结果异常决定重试还是调整策略更新记忆把新信息和任务进度存下来供后续使用。我整理了一个简单的对照当时给我团队解释很有用维度ChatbotAgent输出边界生成一段文字就算完成完成真实业务动作才叫完成执行流程单次问答规划-执行-观察-修正的循环状态保持基本无需要会话状态、任务状态、记忆失败处理换个说法重新生成需要重试、改路、降级到人工对工具要求不需要或很少依赖大量经过良好封装的工具带着这个模型回看项目我的结论是Agent 的真正难点不是让 LLM 说得准而是让“动作闭环”能稳定跑起来。想让动作闭环稳定核心手段就是把所有可执行能力都封装成高质量的 AI Skill。1.2 Skill 不是函数也不是插件概念边界要先理清项目做到后期我被问得最多的问题是你说的 AI Skill到底跟我代码里写的 function、跟某某框架里的 plugin 有什么区别我的理解是这样的函数Function最底层是代码里一个可以被显式调用的单元。它没有“自我描述”不知道自己在什么场景下被使用。插件Plugin通常在宿主应用里打包了一组能力。但插件往往是为 UI 或特定集成场景设计的不一定给模型的可发现性。AI Skill是面向 Agent 的可执行能力单元它的特点是具备完整的“语义自描述”。简单说一个 AI Skill 里不仅包含执行逻辑还包含它适合处理什么任务、需要哪些参数、返回什么结构甚至在什么情况下不该用它。举个例子我代码里写一个add_todo()函数名字简短只有开发者能理解它。而 AI Skill 的注册描述像是一个“岗位说明书”{ name: todo_add_item, description: 向待办清单中添加一个任务。适合用户说‘记得提醒我’‘帮我安排一下’‘加一条待办’等场景。如果用户没有明确交代截止时间不要填写该字段。, input_schema: { type: object, properties: { title: { type: string, description: 待办事项标题3-40个字符去掉表情和多余符号 }, due_time: { type: string, description: ISO8601格式的截止时间例如2025-09-30T18:00:00 }, priority: { type: string, enum: [high, medium, low], description: 优先级默认medium } }, required: [title] } }这个 job description 不是写给人看的是给模型做“技能选择”和“参数补全”用的。这也是我在这个项目里最核心的顿悟技能的代码决定了“能不能执行”技能的描述决定了“会不会被正确调用”。两者同等重要。2. 为什么选“腾讯云 AI Skills”而不是自己撸一套工具注册中心我一开始当然没想用云服务觉得“就一个内部工具自己写一套工具注册表也没多难”。但真正把 20 多个工具接进来之后我开始频繁处理工具本身的版本管理、权限差异、并发控制、日志收集问题它们正在把我拖进“业务逻辑优化”的反方向。每天都在写元代码真正该做好的会议纪要、待办整理反而没有时间迭代。这时候我开始研究云上的托管形态最后落到了腾讯云 AI Skills。把它作为项目主载体以后整个人从“自己造轮子维护工具框架”里解放出来了。2.1 “会调用工具”和“技能可管理”是两码事“会调用工具”只是技术路径的一环。真正难的是“技能可管理”。技能多了以后不同技能需要不同部署资源、不同数据权限、不同更新节奏你不可能全用一套代码里的 if-else 管过来。我在本地做工具的日常问题包括技能版本不一致同一个功能我更新了新的测试环境用的还是旧的权限没法收敛为了让所有技能都能读文件我只好给服务开一个大而全的存储权限违背了最小权限原则日志分散每个工具自己打自己的日志出了错很难把一次任务的完整过程串起来接入新场景成本高业务方想复用能力得复制代码改参数而不是直接引用一个技能。这些都是基础设施问题不是我这个团队应该花几周去自己解决的。腾讯云 AI Skills 的核心价值在于把“技能”作为云上的一等公民来管理声明、部署、鉴权、调用、版本、观测都被平台承接了。这对我这种“要写业务而不是维护 Agent 框架”的人来说太重要了。2.2 AI Skills 的隐藏价值版本、复用与多种模型评估说起来有点讽刺真正让我坚定选型的是一些最开始没在介绍文档里注意到的“隐藏价值”。第一点技能与执行逻辑解耦。我可以在云上注册一个叫“会议纪要生成”的 Skill让它指向某个云函数。之后哪怕我把底层函数重写、迁移、换语言只要对外接口的 schema 不变所有依赖这个 Skill 的 Agent 都不用改。这让我能持续重构而不必担心破坏面扩散。第二点横向复用能力。团队内另外一个机器人服务需要“添加待办”它不用再拉我的代码仓库只需要在它的 Agent 声明里写上“允许调用 todo_add_item”这个 Skill。技能变成了团队内可流通的“积木”。这跟我自己维护一套代码库有本质区别因为积木之间不需要共享进程。第三点对模型选择和评估特别有帮助。因为我所有技能已经在云端模块化我可以建两个 Agent一个用模型 A一个用模型 B把它们接到同一组 Skill 上跑同样的测试用例比较哪套组合对用户意图理解更准、参数填得更稳。如果没有这层封装每次换模型我就得重新适配一遍工具调用格式那是劝退级的力气活。2.3 云端跑通一个 Skill 的最少步骤从写代码到联调这里记录我在项目里第一次把 Skill 跑通的流程尽量精简但完整。不同团队基础设施不一样但路径是通用的部署执行服务。Skill 背后需要真实逻辑我用腾讯云函数承载。你可以用已有 HTTP 服务或容器都需要一个能被云端调用的入口地址。部署好后先单独测一下确认你的服务本身没毛病。在云端登记 Skill 元数据包含技能名、作用描述、输入输出 JSON Schema、调用超时时间等等。这一步我称之为“给能力的说明书盖章”。配置访问方式和鉴权。把 Skill 可调用的范围控制好这一步不能省Agent 的权限边界很大程度由这里决定。云端做一次联调测试。直接把用户的话术丢给 Agent观察它是否会选中这个 Skill、生成正确的入参、拿到预期结果。发布并记录版本号。首次发布后如果迭代建议保留旧版本方便回滚。有一个环境准备的常见坑不少人喜欢把 Skill 的“执行逻辑”也写在一个巨大的云函数里所有技能共用一个入口然后靠代码里一个超大 switch-case 分发。这样造成的后果是改一个技能必须重新部署整个函数某个技能因为上下文太长导致内存溢出时会拖垮全部能力。我建议每个 Skill 对应独立的执行单元至少也做到按领域隔离不要所有蛋放一个篮子。到这一步我的 Agent 已经从“一堆函数”变成了“一组 Skill 的组合”。下一步就是真正开始把日常业务拆碎、装进这些技能里。3. 我把“会议纪要、资料整理、待办跟进”拆成了什么样的技能碎片“全能”是个形容词落到工程上必须翻译成一组清晰的边界。我这个 Agent 第一个跑通的场景是团队内部很痛的“会议闭环”从一场几十分钟的语音或文稿到一份结构清晰的纪要和一行行可以跟进的待办。这也是我认为做 Agent 最佳实践最容易切入的高频场景——它不是酷炫吹牛型需求而是每天都在发生、浪费大量人力的工作。这个场景拆到最后我并不是做一个笼统的“会议处理大技能”而是拆成了四个可以独立复用的 AI Skillmeeting_material_prepare读取用户上传的音频、文档、链接统一成后续可处理的纯文本块meeting_outline_generate基于会议文本生成结构化摘要包含议题、结论、风险、待办todo_batch_add把摘要里的待办批量写入任务系统template_apply按用户常用格式把纪要排版输出。你可能马上会反问这个流程串行跑不就行了吗为什么不合并成一个 Skill 一次执行完这正是我在实践里踩过的坑值得展开讲讲。3.1 从业务流程倒推技能边界而不是“把大函数拆小”一开始我把“会议一键处理”写成一个巨大的技能上传材料 → 总结 → 建待办 → 按模板发周报全在函数里顺序执行。第一版 Demo 看着很省事但用了几天问题全出来了。首先是复用场景不兼容。有人并不想生成纪要只想让 Agent“帮我把这份文档里的任务导进周计划”也有人只想对录音做一个速记摘要不想同步到任务系统。一个“大而全”的技能无法只满足其中一个片段硬拆参数会让用户侧 API 非常难用。其次是失败边界模糊。如果这个全流程在“生成摘要”步骤成功了但在“批量写待办”步骤因为某个字段缺失失败了整个任务就得大回滚——已经生成的纪要怎么办已经写入的一部分任务怎么处理技能内部状态复杂到我没法写清楚“幂等”和“可恢复”。后来我换了个思路不是“把大函数拆小”而是从业务流程反推“哪几个环节会有独立使用者、哪几个环节可能被替换”。拆分技能时我用的规则是如果一个动作会被多个场景单独调用就该独立成一个 Skill如果多个动作之间有强先后依赖且总是捆绑出现可以封装成一个流程型 Skill如果存在不确定的第三方调用必须分成独立步骤否则故障恢复无从下手如果两个动作的操作对象权限范围不同要拆开方便单独控制权限。按这个规则上面“会议处理”的四个技能边界就清晰了前两个属于“加工资粮”后两个属于“把结果搬到外部系统”。它们的用户意图、依赖和权限都不同拆开后整个系统的可维护性高了一个量级。3.2 一个典型 Skill 的输入输出约定长什么样有了边界下一步是定义接口。这里我最想强调的心得是Skill 的输入输出 schema 不只是“数据约束”它同时也是“给模型看的语义说明”。比如meeting_outline_generate的输入项“会议背景”如果只写“会议的背景”模型根本不知道该填什么最后还是生成一堆空话。我实际写的是{ name: meeting_outline_generate, description: 基于会议原始文本生成面向团队的会议纪要。输出包含议题、讨论要点、结论、风险、待办事项必须保持客观不能臆造未提到的结论。, input_schema: { type: object, properties: { meeting_text: { type: string, description: 会议转写文本或文档提取内容最长不超过约2万字 }, background: { type: string, description: 用户提供的会议背景信息。如果会议文本本身能推断背景则可以不填推断不出来时不要编造留空即可 }, focus: { type: array, items: {type: string}, description: 用户重点关注的议题列表例如[\预算\, \排期\]。没有则留空 } }, required: [meeting_text] } }注意这个 schema 里的几个说明全部是给模型“填参数”时看的。模型在面对这类结构化输入时如果看到background是选填且注明“无法推断时留空”就能有效减少幻觉——它不会硬编一个背景出来。返回值方面我把“机器可处理的结构化数据”和“给用户看的话术”分开了。Skill 返回给模型的不应该是一大段散文而是一个结构清晰、可以继续被下游 Skill 使用的 JSON同时可以带一个summary_for_user字段用于最终回复。这样 Agent 在把纪要落进待办系统时可以直接遍历todos数组传参而不是又要从大段文字里重新抽取任务。3.3 技能描述怎么写决定了 Agent 什么时候把这个技能派上用场这个标题可能听起来很虚但它是这个项目里最让我“啊哈”的部分。同一个技能描述写得差和写得好实际调用准确率差距可能超过一半。技能描述负责告诉模型两件事什么时候触发我什么时候不要触发我。很多人只写了前半句忽略了后半句导致 Agent 频繁误用技能。比如todo_add_item的描述我在早期的写法是“添加待办事项”这个描述基本没用。因为模型不太清楚“设置提醒”“安排一下”“别忘了”这些口语是否等价于“添加待办”。我后来的写法就详细了很多“当用户表达‘记一下’‘安排个任务’‘提醒我’‘把这个加到我的待办’等意图时将该内容解析为一个待办项并写入清单。如果用户只是在描述待办而没有要求保存记录不要调用此技能。”这样的描述实际效果远好于简版。原因在于LLM 在做工具选择时不是阅读你的代码而是通过语义判断哪个技能最匹配当前任务。描述提供的信息密度就是它做判断的全部依据。我当时还做过一个实验把一个技能的中文描述改成“因为技能执行后有副作用所以不要让用户重复确认默认执行即可但如果是删除类操作必须向用户二次确认”结果删除操作的安全性显著提升正常操作的确认次数也降低了。可见技能描述不仅影响触发率还能充当 Agent 行为策略的调节器。这个发现后来成了我评审所有技能描述时的必检项。4. 让 Agent 记住事短期会话、长期用户画像、工作记忆分开处理Agent 真正用起来后很快会碰到一个场景第一周用户问“帮我按周二那次的形式整理财经晨报”它不知道“周二那次”到底是什么格式或者说“你不是昨天已经给我生成过了吗怎么又忘了”解决这类问题的技术词叫记忆Memory“agent记忆”也一直是 Agent 开发讨论里的高频关键词。我的实践是把所有需要“记住”的信息拆成三类来存千万别一锅粥全倒进上下文。短期记忆当前会话里未完成的信息工作记忆正在执行的多步骤任务进度长期记忆跨会话需要保留的用户画像、格式偏好、历史选择。4.1 短期记忆与工作记忆别再把整个聊天记录无脑塞给模型第一版实现里我把用户最近的所有对话和系统执行结果一次性塞进上下文。刚开始对话短效果挺好一旦对话超过 20 轮模型开始“遗忘”最初的需求而且每次请求的 token 支出肉眼可见地涨。这种感觉就像你不断地往一只小背包里塞东西最后连拉链都拉不上还指望背包自己把最上面的东西记住。后来我改成了“近 N 轮原文 更早历史的滚动摘要”结构对话超过一定轮数后用一个轻量模型把早期内容压缩成摘要下一次请求只带摘要加最近几轮完整内容同时在每轮结束时把“本次任务的关键状态”提取到工作记忆表里。工作记忆是很容易被忽略的一层。一个复杂的 Agent 任务往往需要执行多步很可能因为调用的第三方服务超时中断在中间某一步。如果系统没有状态记录用户问“刚才那个任务完成到哪一步了”Agent 根本答不上来。我在项目里用一张任务状态表保存每个任务的进度当前步骤、已完成步骤、下一步计划、失败原因。这样 Agent 重启后也能从断点继续而不是把已经做完的步骤重复执行一遍。4.2 长期记忆用户配置用结构化存储文档碎片才放进向量库关于长期记忆我踩过一个大坑一开始我看到大家都提“向量数据库 语义检索”就试着把所有历史纪要统统向量化然后每次交互都做语义召回。结果发现对于“用户偏好用某种表格风格”“上次选择的是PDF格式”这类确定性问题向量检索的命中率和稳定性反而不如一张简单的配置表。于是我把长期记忆分成了两层显式配置类信息 → 结构化存储。用户明确说“以后会议纪要只给我要点不要全文”“周报默认用简洁模板”这种信息直接作为 key-value 或数据库字段写入。它是确定性的适合查询不适合用向量相似度“猜”。历史内容类信息 → 向量库。比如过去的会议纪要、项目文档内容这些非结构化内容适合切块后向量化等用户说“参考我上次的格式”时召回相似片段。这里可以给一个简单的对比帮你快速决策记忆类型典型内容推荐存储原因短期对话记忆正在聊的上下文内存 / 缓存 / 会话存储要求低延迟工作记忆任务当前状态、断点带状态的数据库表需要精确读写与恢复显式偏好用户明确设置的格式、频率结构化表 / KV查询准确、无需猜测内容型记忆历史纪要、文档、邮件向量库适合语义相似度召回长期记忆还有一个绕不开的问题什么该记、什么不该记。我给 Agent 定了一套很朴素但有效的默认规则默认不主动记忆用户的隐私敏感信息不做跨用户共享记录。用户说“记住”才记能记格式就好不要记内容原文涉及会议纪要和客户信息的只保留执行摘要并设置定期清理周期。这不仅是用户信任问题也直接影响安全合规。你可以把“某次不记某类内容”做成一个技能开关而不是让 Agent 自己决定哪些要永久保存。4.3 实践案例跨会话续做未完成任务的完整链路举个例子某次用户在周二说“把这份项目周报整理成精简版发我。”Agent 在第一步生成了摘要但在发送时因为文件转 PDF 失败中断了。此时状态表里写着task_step: generate_summary - donetask_step: export_pdf - failedpickup_snapshot: { original_text_trace_id: xxx }周三用户再问“昨天那份周报整理好了吗”Agent 没有从零开始理解而是先查工作记忆发现存在未完成任务从失败节点恢复只重试export_pdf这次动作并将恢复结果告知用户。同时因为周二生成摘要时已经知道了用户偏好“精简版、要点式、带数据表格”周四再处理下一份周报时格式直接命中无需重复询问。这就是三类记忆协同工作的日常状态。在这个例子里最让我有成就感的一点是用户感受到的不是“一个会重复劳动的词法工具”而是一个能主动衔接上下文的承办人。但这份体验得益于前面拆分技能时的清晰日志与状态保存不是模型自动变聪明了。5. 多技能编排手把手驯服 Agent 不跑偏技能有了记忆也有了接下来就是最考验工程水平的环节编排。如果把 Agent 比作人技能是他手里的工具记忆是他的经验而编排层就是他的工作习惯和方法论。一个工作习惯不好的人拿再好的工具也会把事情办砸。我的 Agent 每天的典型执行链路大概是这样的接收用户自然语言请求调用“意图理解 计划生成”模块判断需要调用哪几个技能按什么顺序调用逐个执行技能每步校验返回值如果某一步失败决定是重试、换技能还是放弃全部执行完后回想是否有用户偏好要保存是否有任务状态要更新。听起来简单但这中间全是细节。5.1 预设工作流为主自由规划为辅一个混合编排策略最开始我试着完全让模型自主规划每一步该调什么技能也就是业界常说的“全动态编排”。实验结果并不理想模型会为了一个简单提问规划出四步多余动作每一步都增加失败概率用户等待时间也变长。后来我改成混合模式这个模式对我这种“要保证随时可用”的内部工具非常合适常见高频路径直接固化预设工作流比如会议一句话处理材料准备 → 摘要生成 → 待办写入 → 模板输出这四步是固定的Agent 不需要重新发明轮子。固定路径的好处是可预期、好测试、前端可以展示进度。只有遇到预设矩阵没覆盖的“开放式请求”时才让模型动态选择技能。典型场景比如“帮我把最近两周所有客户反馈里的高频问题归纳出来并生成一个改进建议文档”这种请求没有固定模板模型才有必要自主规划。为什么这个策略更适合生产环境因为高复用路径用预设工作流能够大幅降低 token 开销和响应延迟而自由规划永远只发生在真正需要它的复杂度上。每次让模型做决策都是在消耗概率空间里的稳定性能省则省。5.2 防死循环、防重复执行超时、上限、幂等一个都不能少多步骤 Agent 另一个逃不掉的坑是“它会反复尝试”。曾经用户让 Agent“把刚才生成的计划再生成一版 PDF”模型不知为何把自己陷入“尝试导出—失败—再尝试”的内循环白白跑了十分钟费用也在烧。我称之为 Agent 的倔强期。真正上生产必须用工程手段治住它。我在编排层加了四道约束单次任务最大步数默认 8 步超过立刻停止并如实告知用户“任务太复杂需要拆开来做”每步技能调用超时默认 5 秒超时后记录失败原因不让 Agent 无限等待关键操作前的确认点删除、群发、对外发送文件等不可逆操作绝不默认执行。执行前必须调用一个确认技能询问用户幂等令牌批量写待办这类有副作用的技能调用方必须携带 request_id。如果 Agent 因为超时重试了同一请求后端检测到相同 request_id 就直接返回上一次结果而不是再写一遍重复数据。后端实现幂等也不算复杂下面是简化思路 从0到1打造团队AI Agent：腾讯云AI Skills最佳实践与踩坑总结
这项目最初很功利——我就是不想一遍遍回答群里同样的问题“昨天的会议纪要谁整理”“这个待办谁跟了”“下周三的材料什么时候发”每件事单独拆开都不难但一件件堆在一个人身上时间就这么被吃干净了。于是我用了一个周末的“冲动”开始搭一个团队内部的 AI Agent指望它能接住这些日常杂务。等真正动手才发现接大模型 API 只是进门第一步要让 Agent 从“特别能聊”变成“真能干活”背后牵扯到任务拆解、技能封装、上下文记忆、失败恢复、成本控制每一个都是能让人写代码写到凌晨三点的坑。这篇文章就把我当时从 0 到 1 养大这个 Agent 的完整过程记录下来重点写我最后沉淀出来的“腾讯云 AI Skills”最佳实践形态以及我踩坑后总结的经验。如果你也在做 Agent 开发、AI 应用落地或者单纯好奇“Agent 到底是怎么从 Demo 变工具的”希望这篇能给你省几晚上的折腾时间。1. 这项目怎么来的杂务太多才决定养个“什么都会一点的助手”先交代一下背景。我们团队很小但日常沟通链路特别长开会、录音、形成纪要、整理待办、写计划、同步给不同的人。每个人都在说“AI 能提效”可真正落到我们自己身上模型生成的文字再多也没有人愿意去手动把纪要里的每一条待办誊进任务系统。我需要的不只是“会总结的聊天机器人”而是一个能感知任务、拆解动作、调用真实系统并把事情执行完的 Agent。但这个认知也不是一开始就有的。我最开始的雏形特别原始调一个文本生成模型把会议记录粘贴进去让它总结再把总结结果人工复制进表格。用了两天我就受不了了——总结得再好后续动作全是我自己动手等于我写了个程序帮别人做作业作业还是我来交。于是我把方向改成“Agent”让它自己决定调用哪些工具比如读文件、写待办、设置提醒、生成周报。从这一版开始它才算真正“接手”了工作流而不是只当一个高级文本处理管道。围绕这个需求结合“全能 Agent”这个目标我这里先给一个总览性的能力分层后面每个模块我都会讲到。1.1 从“调用模型”到“Agent”中间隔着的不只是代码量很多人误以为 Agent 就是“模型 函数调用工具包”这个理解在 Demo 阶段没错但往生产走会立刻撞墙。我在最初的版本里让模型可以调 3 个工具代码写得很爽当工具到 20 个以后模型经常选错或者参数填得牛头不对马嘴整个执行链路就像一团乱麻。这里需要区分开几个概念。聊天机器人Chatbot只需要一次生成你问一句它答一句输出完就结束。Agent 则是一个“运行循环”理解目标用户这句话背后到底要什么结果拆解计划把目标拆成几步可执行动作调用工具/技能执行真实动作如建待办、拉资料、写文档观察反馈如果调用失败或中间结果异常决定重试还是调整策略更新记忆把新信息和任务进度存下来供后续使用。我整理了一个简单的对照当时给我团队解释很有用维度ChatbotAgent输出边界生成一段文字就算完成完成真实业务动作才叫完成执行流程单次问答规划-执行-观察-修正的循环状态保持基本无需要会话状态、任务状态、记忆失败处理换个说法重新生成需要重试、改路、降级到人工对工具要求不需要或很少依赖大量经过良好封装的工具带着这个模型回看项目我的结论是Agent 的真正难点不是让 LLM 说得准而是让“动作闭环”能稳定跑起来。想让动作闭环稳定核心手段就是把所有可执行能力都封装成高质量的 AI Skill。1.2 Skill 不是函数也不是插件概念边界要先理清项目做到后期我被问得最多的问题是你说的 AI Skill到底跟我代码里写的 function、跟某某框架里的 plugin 有什么区别我的理解是这样的函数Function最底层是代码里一个可以被显式调用的单元。它没有“自我描述”不知道自己在什么场景下被使用。插件Plugin通常在宿主应用里打包了一组能力。但插件往往是为 UI 或特定集成场景设计的不一定给模型的可发现性。AI Skill是面向 Agent 的可执行能力单元它的特点是具备完整的“语义自描述”。简单说一个 AI Skill 里不仅包含执行逻辑还包含它适合处理什么任务、需要哪些参数、返回什么结构甚至在什么情况下不该用它。举个例子我代码里写一个add_todo()函数名字简短只有开发者能理解它。而 AI Skill 的注册描述像是一个“岗位说明书”{ name: todo_add_item, description: 向待办清单中添加一个任务。适合用户说‘记得提醒我’‘帮我安排一下’‘加一条待办’等场景。如果用户没有明确交代截止时间不要填写该字段。, input_schema: { type: object, properties: { title: { type: string, description: 待办事项标题3-40个字符去掉表情和多余符号 }, due_time: { type: string, description: ISO8601格式的截止时间例如2025-09-30T18:00:00 }, priority: { type: string, enum: [high, medium, low], description: 优先级默认medium } }, required: [title] } }这个 job description 不是写给人看的是给模型做“技能选择”和“参数补全”用的。这也是我在这个项目里最核心的顿悟技能的代码决定了“能不能执行”技能的描述决定了“会不会被正确调用”。两者同等重要。2. 为什么选“腾讯云 AI Skills”而不是自己撸一套工具注册中心我一开始当然没想用云服务觉得“就一个内部工具自己写一套工具注册表也没多难”。但真正把 20 多个工具接进来之后我开始频繁处理工具本身的版本管理、权限差异、并发控制、日志收集问题它们正在把我拖进“业务逻辑优化”的反方向。每天都在写元代码真正该做好的会议纪要、待办整理反而没有时间迭代。这时候我开始研究云上的托管形态最后落到了腾讯云 AI Skills。把它作为项目主载体以后整个人从“自己造轮子维护工具框架”里解放出来了。2.1 “会调用工具”和“技能可管理”是两码事“会调用工具”只是技术路径的一环。真正难的是“技能可管理”。技能多了以后不同技能需要不同部署资源、不同数据权限、不同更新节奏你不可能全用一套代码里的 if-else 管过来。我在本地做工具的日常问题包括技能版本不一致同一个功能我更新了新的测试环境用的还是旧的权限没法收敛为了让所有技能都能读文件我只好给服务开一个大而全的存储权限违背了最小权限原则日志分散每个工具自己打自己的日志出了错很难把一次任务的完整过程串起来接入新场景成本高业务方想复用能力得复制代码改参数而不是直接引用一个技能。这些都是基础设施问题不是我这个团队应该花几周去自己解决的。腾讯云 AI Skills 的核心价值在于把“技能”作为云上的一等公民来管理声明、部署、鉴权、调用、版本、观测都被平台承接了。这对我这种“要写业务而不是维护 Agent 框架”的人来说太重要了。2.2 AI Skills 的隐藏价值版本、复用与多种模型评估说起来有点讽刺真正让我坚定选型的是一些最开始没在介绍文档里注意到的“隐藏价值”。第一点技能与执行逻辑解耦。我可以在云上注册一个叫“会议纪要生成”的 Skill让它指向某个云函数。之后哪怕我把底层函数重写、迁移、换语言只要对外接口的 schema 不变所有依赖这个 Skill 的 Agent 都不用改。这让我能持续重构而不必担心破坏面扩散。第二点横向复用能力。团队内另外一个机器人服务需要“添加待办”它不用再拉我的代码仓库只需要在它的 Agent 声明里写上“允许调用 todo_add_item”这个 Skill。技能变成了团队内可流通的“积木”。这跟我自己维护一套代码库有本质区别因为积木之间不需要共享进程。第三点对模型选择和评估特别有帮助。因为我所有技能已经在云端模块化我可以建两个 Agent一个用模型 A一个用模型 B把它们接到同一组 Skill 上跑同样的测试用例比较哪套组合对用户意图理解更准、参数填得更稳。如果没有这层封装每次换模型我就得重新适配一遍工具调用格式那是劝退级的力气活。2.3 云端跑通一个 Skill 的最少步骤从写代码到联调这里记录我在项目里第一次把 Skill 跑通的流程尽量精简但完整。不同团队基础设施不一样但路径是通用的部署执行服务。Skill 背后需要真实逻辑我用腾讯云函数承载。你可以用已有 HTTP 服务或容器都需要一个能被云端调用的入口地址。部署好后先单独测一下确认你的服务本身没毛病。在云端登记 Skill 元数据包含技能名、作用描述、输入输出 JSON Schema、调用超时时间等等。这一步我称之为“给能力的说明书盖章”。配置访问方式和鉴权。把 Skill 可调用的范围控制好这一步不能省Agent 的权限边界很大程度由这里决定。云端做一次联调测试。直接把用户的话术丢给 Agent观察它是否会选中这个 Skill、生成正确的入参、拿到预期结果。发布并记录版本号。首次发布后如果迭代建议保留旧版本方便回滚。有一个环境准备的常见坑不少人喜欢把 Skill 的“执行逻辑”也写在一个巨大的云函数里所有技能共用一个入口然后靠代码里一个超大 switch-case 分发。这样造成的后果是改一个技能必须重新部署整个函数某个技能因为上下文太长导致内存溢出时会拖垮全部能力。我建议每个 Skill 对应独立的执行单元至少也做到按领域隔离不要所有蛋放一个篮子。到这一步我的 Agent 已经从“一堆函数”变成了“一组 Skill 的组合”。下一步就是真正开始把日常业务拆碎、装进这些技能里。3. 我把“会议纪要、资料整理、待办跟进”拆成了什么样的技能碎片“全能”是个形容词落到工程上必须翻译成一组清晰的边界。我这个 Agent 第一个跑通的场景是团队内部很痛的“会议闭环”从一场几十分钟的语音或文稿到一份结构清晰的纪要和一行行可以跟进的待办。这也是我认为做 Agent 最佳实践最容易切入的高频场景——它不是酷炫吹牛型需求而是每天都在发生、浪费大量人力的工作。这个场景拆到最后我并不是做一个笼统的“会议处理大技能”而是拆成了四个可以独立复用的 AI Skillmeeting_material_prepare读取用户上传的音频、文档、链接统一成后续可处理的纯文本块meeting_outline_generate基于会议文本生成结构化摘要包含议题、结论、风险、待办todo_batch_add把摘要里的待办批量写入任务系统template_apply按用户常用格式把纪要排版输出。你可能马上会反问这个流程串行跑不就行了吗为什么不合并成一个 Skill 一次执行完这正是我在实践里踩过的坑值得展开讲讲。3.1 从业务流程倒推技能边界而不是“把大函数拆小”一开始我把“会议一键处理”写成一个巨大的技能上传材料 → 总结 → 建待办 → 按模板发周报全在函数里顺序执行。第一版 Demo 看着很省事但用了几天问题全出来了。首先是复用场景不兼容。有人并不想生成纪要只想让 Agent“帮我把这份文档里的任务导进周计划”也有人只想对录音做一个速记摘要不想同步到任务系统。一个“大而全”的技能无法只满足其中一个片段硬拆参数会让用户侧 API 非常难用。其次是失败边界模糊。如果这个全流程在“生成摘要”步骤成功了但在“批量写待办”步骤因为某个字段缺失失败了整个任务就得大回滚——已经生成的纪要怎么办已经写入的一部分任务怎么处理技能内部状态复杂到我没法写清楚“幂等”和“可恢复”。后来我换了个思路不是“把大函数拆小”而是从业务流程反推“哪几个环节会有独立使用者、哪几个环节可能被替换”。拆分技能时我用的规则是如果一个动作会被多个场景单独调用就该独立成一个 Skill如果多个动作之间有强先后依赖且总是捆绑出现可以封装成一个流程型 Skill如果存在不确定的第三方调用必须分成独立步骤否则故障恢复无从下手如果两个动作的操作对象权限范围不同要拆开方便单独控制权限。按这个规则上面“会议处理”的四个技能边界就清晰了前两个属于“加工资粮”后两个属于“把结果搬到外部系统”。它们的用户意图、依赖和权限都不同拆开后整个系统的可维护性高了一个量级。3.2 一个典型 Skill 的输入输出约定长什么样有了边界下一步是定义接口。这里我最想强调的心得是Skill 的输入输出 schema 不只是“数据约束”它同时也是“给模型看的语义说明”。比如meeting_outline_generate的输入项“会议背景”如果只写“会议的背景”模型根本不知道该填什么最后还是生成一堆空话。我实际写的是{ name: meeting_outline_generate, description: 基于会议原始文本生成面向团队的会议纪要。输出包含议题、讨论要点、结论、风险、待办事项必须保持客观不能臆造未提到的结论。, input_schema: { type: object, properties: { meeting_text: { type: string, description: 会议转写文本或文档提取内容最长不超过约2万字 }, background: { type: string, description: 用户提供的会议背景信息。如果会议文本本身能推断背景则可以不填推断不出来时不要编造留空即可 }, focus: { type: array, items: {type: string}, description: 用户重点关注的议题列表例如[\预算\, \排期\]。没有则留空 } }, required: [meeting_text] } }注意这个 schema 里的几个说明全部是给模型“填参数”时看的。模型在面对这类结构化输入时如果看到background是选填且注明“无法推断时留空”就能有效减少幻觉——它不会硬编一个背景出来。返回值方面我把“机器可处理的结构化数据”和“给用户看的话术”分开了。Skill 返回给模型的不应该是一大段散文而是一个结构清晰、可以继续被下游 Skill 使用的 JSON同时可以带一个summary_for_user字段用于最终回复。这样 Agent 在把纪要落进待办系统时可以直接遍历todos数组传参而不是又要从大段文字里重新抽取任务。3.3 技能描述怎么写决定了 Agent 什么时候把这个技能派上用场这个标题可能听起来很虚但它是这个项目里最让我“啊哈”的部分。同一个技能描述写得差和写得好实际调用准确率差距可能超过一半。技能描述负责告诉模型两件事什么时候触发我什么时候不要触发我。很多人只写了前半句忽略了后半句导致 Agent 频繁误用技能。比如todo_add_item的描述我在早期的写法是“添加待办事项”这个描述基本没用。因为模型不太清楚“设置提醒”“安排一下”“别忘了”这些口语是否等价于“添加待办”。我后来的写法就详细了很多“当用户表达‘记一下’‘安排个任务’‘提醒我’‘把这个加到我的待办’等意图时将该内容解析为一个待办项并写入清单。如果用户只是在描述待办而没有要求保存记录不要调用此技能。”这样的描述实际效果远好于简版。原因在于LLM 在做工具选择时不是阅读你的代码而是通过语义判断哪个技能最匹配当前任务。描述提供的信息密度就是它做判断的全部依据。我当时还做过一个实验把一个技能的中文描述改成“因为技能执行后有副作用所以不要让用户重复确认默认执行即可但如果是删除类操作必须向用户二次确认”结果删除操作的安全性显著提升正常操作的确认次数也降低了。可见技能描述不仅影响触发率还能充当 Agent 行为策略的调节器。这个发现后来成了我评审所有技能描述时的必检项。4. 让 Agent 记住事短期会话、长期用户画像、工作记忆分开处理Agent 真正用起来后很快会碰到一个场景第一周用户问“帮我按周二那次的形式整理财经晨报”它不知道“周二那次”到底是什么格式或者说“你不是昨天已经给我生成过了吗怎么又忘了”解决这类问题的技术词叫记忆Memory“agent记忆”也一直是 Agent 开发讨论里的高频关键词。我的实践是把所有需要“记住”的信息拆成三类来存千万别一锅粥全倒进上下文。短期记忆当前会话里未完成的信息工作记忆正在执行的多步骤任务进度长期记忆跨会话需要保留的用户画像、格式偏好、历史选择。4.1 短期记忆与工作记忆别再把整个聊天记录无脑塞给模型第一版实现里我把用户最近的所有对话和系统执行结果一次性塞进上下文。刚开始对话短效果挺好一旦对话超过 20 轮模型开始“遗忘”最初的需求而且每次请求的 token 支出肉眼可见地涨。这种感觉就像你不断地往一只小背包里塞东西最后连拉链都拉不上还指望背包自己把最上面的东西记住。后来我改成了“近 N 轮原文 更早历史的滚动摘要”结构对话超过一定轮数后用一个轻量模型把早期内容压缩成摘要下一次请求只带摘要加最近几轮完整内容同时在每轮结束时把“本次任务的关键状态”提取到工作记忆表里。工作记忆是很容易被忽略的一层。一个复杂的 Agent 任务往往需要执行多步很可能因为调用的第三方服务超时中断在中间某一步。如果系统没有状态记录用户问“刚才那个任务完成到哪一步了”Agent 根本答不上来。我在项目里用一张任务状态表保存每个任务的进度当前步骤、已完成步骤、下一步计划、失败原因。这样 Agent 重启后也能从断点继续而不是把已经做完的步骤重复执行一遍。4.2 长期记忆用户配置用结构化存储文档碎片才放进向量库关于长期记忆我踩过一个大坑一开始我看到大家都提“向量数据库 语义检索”就试着把所有历史纪要统统向量化然后每次交互都做语义召回。结果发现对于“用户偏好用某种表格风格”“上次选择的是PDF格式”这类确定性问题向量检索的命中率和稳定性反而不如一张简单的配置表。于是我把长期记忆分成了两层显式配置类信息 → 结构化存储。用户明确说“以后会议纪要只给我要点不要全文”“周报默认用简洁模板”这种信息直接作为 key-value 或数据库字段写入。它是确定性的适合查询不适合用向量相似度“猜”。历史内容类信息 → 向量库。比如过去的会议纪要、项目文档内容这些非结构化内容适合切块后向量化等用户说“参考我上次的格式”时召回相似片段。这里可以给一个简单的对比帮你快速决策记忆类型典型内容推荐存储原因短期对话记忆正在聊的上下文内存 / 缓存 / 会话存储要求低延迟工作记忆任务当前状态、断点带状态的数据库表需要精确读写与恢复显式偏好用户明确设置的格式、频率结构化表 / KV查询准确、无需猜测内容型记忆历史纪要、文档、邮件向量库适合语义相似度召回长期记忆还有一个绕不开的问题什么该记、什么不该记。我给 Agent 定了一套很朴素但有效的默认规则默认不主动记忆用户的隐私敏感信息不做跨用户共享记录。用户说“记住”才记能记格式就好不要记内容原文涉及会议纪要和客户信息的只保留执行摘要并设置定期清理周期。这不仅是用户信任问题也直接影响安全合规。你可以把“某次不记某类内容”做成一个技能开关而不是让 Agent 自己决定哪些要永久保存。4.3 实践案例跨会话续做未完成任务的完整链路举个例子某次用户在周二说“把这份项目周报整理成精简版发我。”Agent 在第一步生成了摘要但在发送时因为文件转 PDF 失败中断了。此时状态表里写着task_step: generate_summary - donetask_step: export_pdf - failedpickup_snapshot: { original_text_trace_id: xxx }周三用户再问“昨天那份周报整理好了吗”Agent 没有从零开始理解而是先查工作记忆发现存在未完成任务从失败节点恢复只重试export_pdf这次动作并将恢复结果告知用户。同时因为周二生成摘要时已经知道了用户偏好“精简版、要点式、带数据表格”周四再处理下一份周报时格式直接命中无需重复询问。这就是三类记忆协同工作的日常状态。在这个例子里最让我有成就感的一点是用户感受到的不是“一个会重复劳动的词法工具”而是一个能主动衔接上下文的承办人。但这份体验得益于前面拆分技能时的清晰日志与状态保存不是模型自动变聪明了。5. 多技能编排手把手驯服 Agent 不跑偏技能有了记忆也有了接下来就是最考验工程水平的环节编排。如果把 Agent 比作人技能是他手里的工具记忆是他的经验而编排层就是他的工作习惯和方法论。一个工作习惯不好的人拿再好的工具也会把事情办砸。我的 Agent 每天的典型执行链路大概是这样的接收用户自然语言请求调用“意图理解 计划生成”模块判断需要调用哪几个技能按什么顺序调用逐个执行技能每步校验返回值如果某一步失败决定是重试、换技能还是放弃全部执行完后回想是否有用户偏好要保存是否有任务状态要更新。听起来简单但这中间全是细节。5.1 预设工作流为主自由规划为辅一个混合编排策略最开始我试着完全让模型自主规划每一步该调什么技能也就是业界常说的“全动态编排”。实验结果并不理想模型会为了一个简单提问规划出四步多余动作每一步都增加失败概率用户等待时间也变长。后来我改成混合模式这个模式对我这种“要保证随时可用”的内部工具非常合适常见高频路径直接固化预设工作流比如会议一句话处理材料准备 → 摘要生成 → 待办写入 → 模板输出这四步是固定的Agent 不需要重新发明轮子。固定路径的好处是可预期、好测试、前端可以展示进度。只有遇到预设矩阵没覆盖的“开放式请求”时才让模型动态选择技能。典型场景比如“帮我把最近两周所有客户反馈里的高频问题归纳出来并生成一个改进建议文档”这种请求没有固定模板模型才有必要自主规划。为什么这个策略更适合生产环境因为高复用路径用预设工作流能够大幅降低 token 开销和响应延迟而自由规划永远只发生在真正需要它的复杂度上。每次让模型做决策都是在消耗概率空间里的稳定性能省则省。5.2 防死循环、防重复执行超时、上限、幂等一个都不能少多步骤 Agent 另一个逃不掉的坑是“它会反复尝试”。曾经用户让 Agent“把刚才生成的计划再生成一版 PDF”模型不知为何把自己陷入“尝试导出—失败—再尝试”的内循环白白跑了十分钟费用也在烧。我称之为 Agent 的倔强期。真正上生产必须用工程手段治住它。我在编排层加了四道约束单次任务最大步数默认 8 步超过立刻停止并如实告知用户“任务太复杂需要拆开来做”每步技能调用超时默认 5 秒超时后记录失败原因不让 Agent 无限等待关键操作前的确认点删除、群发、对外发送文件等不可逆操作绝不默认执行。执行前必须调用一个确认技能询问用户幂等令牌批量写待办这类有副作用的技能调用方必须携带 request_id。如果 Agent 因为超时重试了同一请求后端检测到相同 request_id 就直接返回上一次结果而不是再写一遍重复数据。后端实现幂等也不算复杂下面是简化思路