1. 为什么我最终把 Agent 的“技能包”放到了腾讯云 AI Skills 上先说结论构建一个真正能落地的 Agent难点从来不是模型推理而是如何让 Agent 稳定地调用外部工具、执行多步骤任务、并在出错时还能自己绕回来。这个“工具编排”和“技能管理”的环节才是拉开普通 Demo 和生产级应用差距的分水岭。我最早做 Agent 的时候走的完全是“代码硬编码”路线把每个工具调用写死在 Python 脚本里用 LangChain 的 AgentExecutor 串起来。当时跑几个简单场景没问题但一旦任务复杂起来问题就全暴露了——指令稍微含糊一点模型就开始乱选工具选对工具之后参数格式又经常拼错更烦的是每加一个新工具我都要改一遍 Prompt 和回调逻辑整个代码库越来越脆改一个功能牵一发动全身。后来接触到 AI Skills 这个概念尤其是腾讯云上这套实现我才意识到自己之前是“用写业务代码的思路写 Agent”而正确做法应该是“用定义服务接口的思路定义 Agent 能力”。AI Skills 本质上就是把 Agent 的一项能力——无论是查天气、算数学、读文档还是调用某个云 API——封装成一个结构化、可复用、带描述和参数 Schema 的“技能包”。Agent 不需要在 Prompt 里背下所有工具的长篇说明只需要知道“我现在有哪些 Skills 可用各自的触发场景是什么”就能像人一样按需取用。这篇内容不是官方文档的复述而是我从零跑通一个“全能型 Agent”之后整理的最佳实践。适合谁看如果你想自己搭 Agent但不想把逻辑全塞进 Prompt如果你已经有一个能跑的 Agent但天天被工具调用的稳定性折磨如果你听说腾讯云 AI Skills 很好用但不知道从哪里入手——那这篇文章应该能帮你少走不少弯路。2. 动手之前先想清楚 Skills 的边界和拆法比写代码更重要很多教程一上来就教你怎么创建 Skill、怎么填参数但我建议你先把这一步忍住了因为我在实际项目中踩过最大的坑恰恰是“技能拆得太粗或太细”。2.1 什么样的能力适合做成 Skill什么样的能力不该做我在第一个版本里几乎把 Agent 的每个动作都拆成了独立 Skill结果维护成本暴涨。后来我给自己定了一条判断标准一个 Skill 应该对应一个“用户能感知的完整任务单元”而不是对应一个底层 API 调用。举个例子。我做一个“项目周报助手”Agent它需要做三件事拉取 Git 提交记录、分析提交信息归纳出本周工作主题、按模板生成周报。如果拆成三个 Skill那么 Agent 就要在对话中依次发起三次调用中间任何一次出错都可能导致整条链路断掉如果拆成一个“生成周报”Skill让 Skill 内部自己完成“拉数据 分析 生成”外部调度就非常干净。那是不是越粗越好也不是。我另一个项目里把“发邮件”拆成了“收件人解析”“正文润色”“SMTP 发送”三个 Skill结果 Agent 经常在“解析收件人”和“润色正文”之间反复横跳浪费大量 Token还容易误解用户到底想润色还是想发送。合理粒度是以用户意图为单位一个 Skill 干一件用户能说清楚的事。2.2 从热词里读出来的核心需求Skill 和 Agent 到底是什么关系这段时间围绕“agent skill”“skill和agent的区别”“agent skills怎么写”的讨论很多。我理解的关系是这样的Agent 是大脑负责理解任务、拆解步骤、决定下一步做什么Skill 是手脚负责把某一个具体动作执行得干净利落。大脑不需要知道手部的每块肌肉怎么发力它只需要知道“手能抓握、能写字、能比划”然后根据场景决定调用哪个。腾讯云 AI Skills 的落地方式比较聪明的一点是它把 Skill 定义成了带结构化描述的“能力服务”Agent 通过意图识别去匹配、通过参数 Schema 去调用、通过输出协议去接收结果。这样一来Prompt 里不再需要堆砌工具的长篇介绍模型的注意力可以更集中在任务规划上。我还注意到“ai skills怎么写”“编程好用的ai skills”这类搜索热度很高说明很多人已经意识到写 Skill 才是让 Agent 变强的核心技能。这个判断我完全认同。模型能力本身已经够用真正的差异化就在于你能给 Agent 装配多少高质量、高可靠的技能。2.3 我的 Skill 规划清单一个全能 Agent 需要哪些技能结合我实际的“全能 Agent”项目我最终保留了这样一组 Skills你可以当参考模板Skill 名称核心用途为什么必须有web_search检索实时信息Agent 的知识有截止日期没有它就是一个“断网大脑”url_fetch抓取指定网页正文搜索只能拿到摘要拿全文必须靠它code_interpreter执行 Python 代码数学计算、数据处理、格式转换全靠它doc_reader解析 PDF/Word/Markdown用户经常扔一个文档过来让你总结api_connector调用外部 HTTP API对接业务系统的万能接口memory_manager读写短期/长期记忆没有记忆的 Agent 每次对话都是“初次见面”这六个 Skills 的搭配逻辑是搜索是获取新信息抓取是深入信息源代码执行是处理结构化任务文档解析是处理非结构化输入API 连接是触达外部系统记忆管理是维持会话连续性。六者组合起来基本覆盖了日常高频需求。3. 腾讯云 AI Skills 的环境准备与两种主流接入路径我用的这套实践基于腾讯云现有的 AI 开发能力。我先把环境准备的部分说清楚因为这里有几个细节如果没注意后面排查起来很痛苦。3.1 账号开通与资源规划有两件事容易被忽略第一件事是权限。AI Skills 相关的 API 调用要走云 API 密钥但生产环境我不建议直接用主账号密钥而是创建一个子账号只授予 AI 服务相关的权限。这样做的好处有两个一是密钥泄露时影响面可控二是后续如果多人协作可以按角色分开审计。第二件事是地域选择。Skill 的调用延迟和存储地域有关。如果你面向国内用户就把资源放在延迟最低的地域如果你要对接境外 API可能会涉及额外的网络配置。我的建议是提前定好资源地域不要在项目中途切换否则存量数据迁移也是工作量。3.2 路径一通过控制台可视化编排 Skill如果目标是快速验证想法用控制台可视化编排是最省事的。创建 Skill 时控制台会引导你填写名称、描述、输入参数和输出结果然后你只需要把 Skill 的触发条件描述清楚系统会自动处理意图匹配的逻辑。这种方式适合两类人一类是完全不熟悉代码的产品经理或运营同学想自己搭一个 Agent 原型另一类是开发者在初期验证 Skill 拆法是否合理时快速做个 MVP。可视化编排的缺点是灵活性有限——复杂逻辑、自定义校验、特殊鉴权这些控制台就不太好处理了。3.3 路径二通过 API/SDK 将 Skills 集成到自有业务系统我最终采用的是 API/SDK 方式因为我的 Agent 跑在自己的服务里需要把 Skills 当作内部能力来调度。腾讯云提供了标准的云 API你可以用 Python SDK 发起调用把创建 Skill、更新 Skill、调用 Skill 都纳入代码管理。这里给一个简化版的 Python 调用示意假设我已经创建好了一个名为“web_search”的 Skillimport json from tencentcloud.common import credential from tencentcloud.ai.v20240501 import ai_client, models def call_skill(skill_name: str, params: dict, secret_id: str, secret_key: str): cred credential.Credential(secret_id, secret_key) client ai_client.AiClient(cred, ap-guangzhou) req models.InvokeSkillRequest() req.SkillName skill_name req.InputParams json.dumps(params) resp client.InvokeSkill(req) result json.loads(resp.OutputData) return result注意一点不同版本的 SDK 命名空间可能有差异我这里的类名是从当前线上版本抄的你实际使用时要先在本地把 SDK 升级到最新版以你自己环境里的 SDK 文档为准。3.4 无论走哪条路描述信息都决定了一半成败Skill 的描述信息是给模型看的不是给人看的。你要站在“模型意图匹配”的角度去写描述——它决定了 Agent 在什么场景下会选中这个 Skill。写描述有三条原则说清楚“这个 Skill 能帮用户完成什么”而不是“这个 Skill 调用了什么接口”。主动列出容易混淆的边界比如“本 Skill 只负责查询天气不负责根据天气推荐穿搭”。参数说明里标注必填和选填并给一个示例值模型能参考示例来生成参数。真实的案例是我起初把“code_interpreter”的描述写成“执行一段 Python 代码”结果 Agent 经常在用户问数学计算时不去调用它反而用语言模型硬算。后来我把描述改成“可执行任意 Python 代码适用于数学运算、数据处理、文本处理、统计分析等任务若用户需要精确计算或处理文件内容应优先使用本工具”情况立刻改善。4. 全能 Agent 养成记录从搭建到跑通的核心步骤复盘这部分是重点。我会按我实际操作的顺序把从零搭建到最终跑通一整套完整流程的关键步骤写出来每一步都说清楚我为什么这么做。4.1 搭建 Agent 主控让模型只做决策不做执行细节Agent 主控层我更愿意把它理解成一个“调度员”。它的职责是理解用户输入 → 决定要完成哪些子任务 → 匹配对应的 Skill → 组织参数发起调用 → 把结果加工成回答。用代码来表达核心循环如下def agent_loop(user_message: str, skill_registry: dict, max_steps: int 5): context [{role: user, content: user_message}] for step in range(max_steps): # 1. 让模型判断当前需要调用哪个 Skill decision llm.call( system_promptbuild_system_prompt(skill_registry), messagescontext ) # 2. 如果模型认为任务已完成就直接返回 if decision[type] final_answer: return decision[content] # 3. 否则调用对应 Skill把结果追加进上下文 skill_name decision[skill] skill_params decision[parameters] skill_result skill_registry[skill_name].execute(skill_params) context.append({role: tool, content: json.dumps(skill_result)}) return 执行步骤过多已自动终止这个循环的关键在于每一步模型看到的上下文是可累积的前一个 Skill 的输出会作为后一个 Skill 的输入依据。真正常见的错误是 Agent 在第一步拿到搜索结果后就直接凭搜索摘要生成答案但摘要往往是碎片化的。正确的做法是当搜索结果的摘要不足以支撑回答时Agent 应该继续调用 url_fetch 去抓取原文。为了让模型的行为可控我给主控层定义了一个统一的决策输出格式类似{ type: skill_call, skill: web_search, parameters: {query: 腾讯云 AI Skills 最佳实践, limit: 5} }如果不需要调用 Skill就输出{ type: final_answer, content: 当前问题无需查询工具我可以直接回答…… }这个格式的好处是无论是人类的排查还是模型的生成都非常直观。你不必强求模型一定输出 JSON但要给它一个结构化的输出模板作为默认选择它会大幅度减少参数拼错的概率。4.2 让 Agent 的“六边形能力”真正落地搜索、抓取、执行、读文档、连 API、带记忆一个称得上“全能”的 Agent至少需要具备我前面清单里的六类能力。我只挑三个最常踩坑的点来展开。先说搜索能力的坑。很多 Agent 项目接入搜索 API 之后第一个测试用例是“帮我查一下今天天气”结果模型返回了一串晦涩的 JSON。问题出在 Agent 拿到搜索结果后没有做“信息抽取”和“可读化整理”。我的解决方案是给搜索结果加一层后处理先把 query 改写为更适合搜索引擎的表述再从结果中抽取标题、摘要、链接和发布时间最后用简洁的文本喂回给主控模型。再说文档解析的坑。用户经常直接扔一个 PDF 过来说“总结一下这份合同”。PDF 本身的排版可能是多栏、带表格、甚至是扫描版。腾讯云这边有现成的内容解析能力但你要注意把解析结果中的纯文本和表格分开处理否则模型拿到一坨乱序文本总结质量会大幅下滑。我实测下来先把表格转为 Markdown、把正文按标题层级拼接再送给模型总结的准确率提升非常明显。最后说记忆管理。我见过很多 Agent 号称有“长期记忆”实际只是把所有历史记录一股脑塞进上下文窗口又贵又容易让模型被旧信息干扰。正确的做法是分层短期记忆只保留当前任务相关的最近几轮对话长期记忆把用户的偏好、关键事实、历史结论抽取成结构化条目存入数据库需要时再通过“检索 相关条目”的方式取回。4.3 给 Agent 接上外部 API安全设计比功能开发更优先全能 Agent 一定会涉及调用外部业务 API。这个环节请务必把安全放在功能之前。建议有三条红线不能碰一是密钥不要写在代码或环境变量里明文保存。腾讯云的密钥管理服务可以帮你加密存储和自动轮转运行时动态获取。二是所有外部 API 在接入前都要做“输入校验”和“输出过滤”不要盲目相信模型生成的参数。模型偶尔会生成一个超范围的日期、一个不存在的用户 ID甚至拼接出异常的 URL服务端必须在调用前做校验。三是外部 API 的凭证尽量使用最小权限。你的 Agent 只需要读某个对象存储桶的某些前缀就不要给它整桶的读写权限。Agent 本质上是代码代码会出 bug密钥会泄露最小权限是你在出事时最重要的兜底。4.4 对话流编排与 Prompt 策略从“能用”到“好用”的分水岭跑通基础循环之后你就会发现 Agent 面临一个艰难问题用户的话往往一句话藏着多个需求。比如“帮我看看本周的 Git 提交顺便把周报发到团队群”。这种多意图场景如果让 Agent 在一个循环里完成顺序错了就会互相干扰——它可能先发了周报但周报内容还没生成完整。我的实践经验是引入“两步走”策略第一步先做意图拆解把用户输入拆成多个独立任务并排好执行顺序明确哪些可以并行哪些必须串行。第二步再进入每个子任务的执行循环。在每完成一个子任务之后短暂进行一次中间结果汇总让用户知道进度而不是闷头执行到最后一刻。Prompt 策略上我也调整过几次。早期我倾向于把系统 Prompt 写得非常长把每个技能的使用场景、注意事项全塞进去结果反而损害了指令遵循的准确性。后来我改成“简洁 注册表 示例”的结构系统 Prompt 只保留身份、对话风格、安全边界每个 Skill 的详细说明放在注册表里按需加载示例只给两到三个“模糊输入 正确 Skill 选择”的典型案例帮助模型快速对齐。最终效果比长 Prompt 好很多。5. 实测中踩过的坑从“看起来正常”到“真的稳定”的排查实录这节我想完整还原几个我实际踩过、也最有代表性的坑。直接给最终方案没有任何价值我想带你走一遍整条排查链路你以后遇到类似问题至少有一条清晰的排查思路。5.1 问题表象Agent 回答“跑题”时先查你让它看到的工具描述我第一次把 Skills 数量加到超过十个之后Agent 开始在简单问题上频繁出现幻觉。例如用户问“北京到上海的高铁要多久”Agent 不调用查询工具反而直接凭记忆回答“大概五六个小时”。我当时第一反应是模型的推理能力不行换了个更强的大模型还是有类似现象比例只下降了一点点。后来我把模型实际“看到”的内容打印出来才发现原因系统 Prompt 里那个 Skill 注册表太长了而我想让它优先选“高铁时刻查询”这个 Skill但它的描述被淹没在一大堆其他 Skill 描述里。模型根本“注意”不到它于是宁可凭记忆硬答。解决办法很简单但很有效在系统 Prompt 里把高频 Skill 单独置顶其余折叠到“更多技能”中并且每次只把和该用户历史记录相关的 Skill 放到主上下文里其余动态加载。这之后跑题率明显下降。这也解释了为什么腾讯云 AI Skills 会强调“为 Agent 选择匹配的 Skills”——Skills 数量越多不意味着越强反而可能导致注意力分散。5.2 问题表象参数格式错误频繁发生Debug 从哪下手当 Skill 参数变得复杂时模型经常生成错误结构比如把数组当成字符串、把必填字段漏掉、日期格式不统一等等。最开始我逐个改 Prompt 示例来纠正但按下了葫芦浮起了瓢。排查过程中我发现一个规律凡是参数名取得模棱两可的比如“data”“info”模型出错率就高凡是参数名能自解释的比如“commit_list_from_git”“report_date”即便你只给一个泛泛的例子模型也能正确生成。后面我就把所有 Skill 的参数名统一改成带有业务含义的全名并给复杂对象提供辅助的子结构说明错误率大幅下降。另外我在 Skill 执行入口加了一层“参数自校验”把必填校验、类型校验、范围校验写成函数如果校验失败就把错误信息返回给主控让模型根据错误重新生成参数。不追求一次成功而是建立一个“失败后自动修正”的机制这是 Agent 系统稳定下来的关键。5.3 问题表象Agent 执行链条太长导致最终结果质量失控有一次我让 Agent 做“行业竞品调研”它依次调用了搜索、抓取、分析、生成报告四个 Skill。单看每一步结果都说得过去但最终报告读起来却非常散信息之间缺乏逻辑串联。这个问题的本质是模型每一步都在“局部最优”但没有做“全局规划”。我后来加了一个“任务规划”前置步骤在收到复杂任务时Agent 先输出一份执行计划明确要研究哪些维度、每个维度用什么数据源、最终报告按什么结构组织经过用户确认或自动确认后才开始执行。这个改动非常有效因为它强制模型先思考再行动而不是走一步看一步。在腾讯云 AI Skills 的框架下你也可以把“任务规划”本身设计成一个 Skill。这样主控模型只需要判断任务复杂度如果简单就直接走单 Skill如果复杂就先调用“任务规划 Skill”再依据返回的计划逐步执行。5.4 一个容易被忽略的稳定性陷阱Skill 执行结果的上下文污染还有一次Agent 在连续几轮对话后突然把之前一个任务的中间结果当成了当前任务的答案。排查发现是上一轮 Skill 返回的内容没有被清理直接占用了最新一轮的上下文位置模型误以为那是系统刚给它的参考信息。解决方式是给每一轮 Skill 调用结果加上明确的时间戳和任务 ID 前缀并在上下文摘要时主动丢弃上一轮不相关的工具输出。对长会话我会定期做一次关键信息归纳和压缩只把用户偏好、明确事实、未完成任务保留下来。这样既省 Token也避免决策被历史噪声带偏。6. 从 Best Practice 到生产级可维护性与可观测性的进阶思考如果你只想做一个个人小助手前面的内容已经够用了。但如果你想把它放进业务系统甚至交付给客户那有几个维度必须提前设计好否则项目一定会烂在维护阶段。6.1 Skill 的版本管理与灰度发布Skill 也是代码也会迭代。我采用的办法是每份 Skill 都有版本号内部先记录 version线上调用时默认取最新稳定版。在升级一个有风险的新版 Skill 前我会先做灰度让少量流量先走新版观察调用成功率和结果质量确认没问题后再全量。腾讯云的 AI Skills 支持比较轻量的版本管理方式你可以把每个版本看作一条独立的记录然后在 Agent 配置里选哪些版本可用。实践中我建议至少保留最近两个版本给回滚留一条退路。6.2 日志、指标与告警让每次工具调用都可被追踪生产环境最怕的就是 Agent 跑出了问题但你不知道是哪一步出的问题。我对接的方式很简单把每次 Skill 调用的前后关键信息打点包括输入的 query、匹配到的 Skill 名称、生成出的参数、执行状态、耗时、返回结果的摘要。这些日志进到日志平台后按 Skill 名称聚合能一眼看到哪个 Skill 的成功率在下降。同时我还设定了一些核心指标单轮任务的平均调用 Skill 次数、一次任务失败后的自动修正成功率、任务的最终完成率。这些指标反映了 Agent 系统的整体健康度比单个请求的成败更有价值因为它们能告诉你模型是否在有效地规划并执行任务而不是瞎蒙。6.3 成本优化减少无效调用和 Token 消耗AI Skills 带来的能力提升不是没有代价的——每一步工具调用都会产生模型推理成本。我实测中发现很多成本浪费来源于 Agent 在可以单步完成的任务上进行了多次无意义调用。最典型的表现是用户问一个简单事实问题搜索结果已经能覆盖答案但 Agent 依然会继续调用 url_fetch 去抓全文然后又调用代码解释器去做毫无必要的总结。虽然这样看起来更像“全能”但用户的感知并没有变好成本却涨了几倍。优化方法是把上一步输出的完整网页信息直接注入到 prompt 中并明确提示“如果输入中已包含足够的信息就不需要继续调用工具”。这相当于在调度层做一次“成本闸门”。6.4 面对 Agent 的“不确定性”如何让它不会在关键业务上失控最后一个核心思考Agent 天然有不确定性但我们不能让它在关键业务上失控。我的实践是引入人工确认和紧急停止机制。凡是涉及发送消息、删除数据、对外支付这类后果不可逆的操作即使 Skill 执行成功了也先进入“待确认”状态由用户在界面上确认后才真正落地。这种“软自动化”在很多时候比“全自动”更符合业务实际需求。同时给 Agent 加一个安全兜底层在调用外部 API 前做一次“操作审核”凡是匹配到高危动作关键词的一律拦截并要求二次确认。这样处理下来Agent 的能力不受限制但风险被关在笼子里了。7. 针对程序员场景的一套“编程好用的 AI Skills”配方既然热搜里大量出现“编程好用的ai skills”“qorder 编程好用的ai skills”这类词说明开发者最想知道的还是怎么让 Agent 帮我写代码、查代码、改代码。我专门整理了一套偏代码开发场景的 Skill 配方方便你直接参考可以理解为“十多年一线经验浓缩后的技能组合”。代码开发场景最核心的四个维度是代码生成、代码检索、代码执行验证、代码审查。对应地我的 Skill 配置是github_repo_loader 用于拉取仓库内容与结构code_search 用于在指定代码库里进行语义搜索code_interpreter 用于执行 Python 或 Shell 代码做验证code_review 用于让模型结合静态检查规则输出审查意见。这套组合覆盖了一个典型编程任务链理解需求 → 检索现有实现 → 生成新代码 → 运行验证 → 人工审查。在写这类 Skill 时我特别强调“上下文压缩”。代码文件通常非常长直接塞给模型既费 Token 又容易让模型丢失重点。我一般会把文件拆成函数/类级片段每个片段用“文件路径 行号范围 函数签名 代码体”的格式送入模型。检索时只返回与查询语义相关的若干片段而不是整个文件。这样既能保证模型看到的信息足够集中又能控制整体上下文长度效果比我早期把整个仓库喂给模型好得多。这里也顺带说一个小技巧如果你的 Agent 写出来的代码风格不稳定可以在代码生成 Skill 的参数里加一个“code_style”字段把团队规范文件路径传进去。Agent 在生成代码前会先读取规范对应的段落再生成代码实测能显著减少“代码能跑但风格丑”的问题。8. 部署上线从本地调试到腾讯云正式环境的平滑迁移在本地把 Agent 调通并不难难的是迁移到云端后依然表现稳定。这节我讲一些上线阶段最容易忽略但非常影响结果的细节。8.1 从本地到云端的差异与适配本地直连和云端部署最大的差异在于网络策略与鉴权方式。在本地时你的本地函数可以直接使用你的 SecretId/SecretKey 调用 API但代码部署到云端之后我更推荐使用腾讯云的临时密钥或角色授权方式而不是把长期密钥打在环境变量里。使用角色授权可以给运行实例分配一个临时身份由平台自动完成密钥的签发与轮转安全性要好得多。另一个常见的差异是本地与云端的执行环境依赖版本不一致。Skill 里如果使用了 Python 的第三方库在测试没问题、上云之后却报找不到依赖这种事故我见过很多次。解决方案是尽量把依赖锁定在一个明确的镜像里不要让它在每次部署时再去拉最新版本。8.2 完整上线 Checklist我在实际操作中把上线检查做成了清单每次发布前逐项核对Skill 注册表是否导入了正确的目标环境版本每个 Skill 的参数校验规则是否包含必要的类型与范围约束所有涉及外部网络和 API 调用的密钥和权限是通过临时凭证获取的吗日志与追踪是否全面覆盖所有核心 Skill错误是否可定位到具体步骤已配置告警的最低成功率与响应延迟阈值了吗是否有灰度发布策略以及回滚预案是否经过实测是否在目标环境的模型配置中实际试跑过至少三到五组复杂的端到端用例虽然它看起来是条条框框但每一条背后都是我经历过的真实事故。逐项核对比事后补救要便宜得多尤其是越往生产走一次环境层面的返工往往占用大量精力。8.3 上线后的效果观察用数据说话上线之后我会持续跟踪三个层面的指标。第一层是技能调用成功率这是最直接的稳定性指标第二层是单次任务的终结率也就是 Agent 能否在一个任务以内完成而不是陷入循环第三层是用户反馈里“不需要重试”“一次性解决”的比例这比任何评测集都更贴近真实满意度。在我的实践中一个上线前看似稳定的 Agent在上线后前两周常常会暴露出一批长尾问题比如某些 URL 抓不下来、某些文档包含扫描版图片而解析失败、某些外部 API 返回格式变化导致解析代码报错。这些问题很难全部提前预知但有了可观测性和告警之后你能在用户感知到明显损害之前就介入并修复。这就像养一个孩子不是教会他几个动作就完事而是要持续观察他面对新环境时的表现并及时提供支持。把 Agent 交给用户运行本身就是 Agent 走向成熟的必经之路。而你的价值不在于让 Agent 在测试集上跑满分而在于当它在真实世界里遇到没见过的问题时你能不能快速定位它、修复它、然后再把它放回去。这恰恰是 AI Skills 这类机制存在的意义——它让 Agent 的每一项能力都可被独立发布、独立观测、独立回滚也让开发者在不确定性的算法世界里勉强握住了一些可控的把柄。最后分享一个习惯每次我新装完一套 Skills都会写一组“地狱级测试用例”专门挑那些模糊、多歧义、需要多步推理、甚至包含误导信息的输入扔给 Agent。能稳定通过这些用例的 Agent才算真正扛过了“全能”这个词的分量。