1. 为什么大家都在聊“AI Skills”和“Agent”最近后台收到不少读者留言问的最多的一个问题就是“搞 Agent 到底难不难那些看起来能自动写代码、自动查数据、自动处理文档的智能体到底是怎么做的”说实话单独做一个 Agent 原型并不难市面上有大量框架LangChain、AutoGPT、MetaGPT 一抓一大把跑通一个 demo 可能一个下午就够了。但问题在于当你真正想把 Agent 从玩具变成生产力工具你会发现一个绕不开的坎Agent 的“能力边界”到底怎么定义谁来告诉 Agent 能做什么、不能做什么、做某件事的完整步骤是什么、有哪些行业规范必须遵守这就是“技能”要解决的问题。在业界这个概念的叫法很多OpenAI 叫 Function Calling字节系叫 Tool而在腾讯云的体系里它被包装成了一整套产品化的方案——腾讯云 AI Skills。说白了AI Skills 就是给 Agent 准备的一套“标准化外挂能力”让智能体能按你定义的规则去调用工具、查询数据、执行任务而不是每次都靠大模型自己脑补。这篇文章我就结合自己近半年折腾 Agent 项目的经验把从“怎么设计 AI Skills”到“怎么让 Agent 真正可靠地跑起来”这条链路完整拆一遍。内容偏实践不会给你堆一堆听不懂的术语每个步骤我都会解释清楚背后的逻辑——毕竟踩过的坑不写出来太可惜了。2. 先拆清楚 Agent 的内部结构才知道 Skills 该放哪2.1 Agent 不是大模型而是一个“小团队”很多人对 Agent 有个误解觉得 Agent 就是 GPT 这类大模型换了层皮。其实不是。一个完整的 Agent 系统更像是一支分工明确的小团队大脑规划器负责理解用户目标拆解任务步骤。这块通常由大模型担任比如腾讯云的混元大模型或者你接的 DeepSeek、Llama 之类都可以。手工具调用层负责实际执行动作比如调 API、读数据库、发请求、操作文件。眼睛感知层/上下文管理器负责把执行结果反馈给大脑让大脑决定下一步动作。记忆Memory短期记忆保存当前对话的上下文长期记忆保存用户偏好、历史任务结果等信息。AI Skills 就工作在“手”这一层。它的核心价值是让“手”的动作不是临时拼凑的而是预先设计好、被反复验证过、可被 Agent 稳定复用的标准化流程。2.2 没有 Skills 的 Agent为什么会翻车我最早做 Agent 的时候根本不知道有 Skills 这个概念所有能力都是通过一大段提示词硬塞给模型的。效果怎么样“薛定谔的稳定”——同一个任务这次跑通了下次换个表述方式就挂了。举个例子。我让 Agent 去查腾讯云某个 CVM 实例的监控数据提示词里写了“请调用云监控 API 获取 CPU 使用率”。看起来没问题对吧但真实情况是调用云监控 API 需要知道实例 ID、命名空间、指标名称、时间粒度、地域等一堆参数大模型在对话式场景下根本记不全这些约束经常会编一个根本不存在的参数名出来。轻则请求报错重则拿到错误数据还一本正经地分析给你看。AI Skills 解决的就是这个问题把“查某个实例的 CPU 使用率”这个动作封装成一个定义清晰、参数明确、校验严格的可执行模块。Agent 只需要说自己想干什么剩下的参数补全、协议组装、异常处理都由 Skills 完成。这就是为什么微软、OpenAI、腾讯云都在推技能化、工具化的 Agent 开发范式——让大模型做决策让代码做执行。2.3 Skill 和 Agent 到底是什么关系这个很多人会搞混。我打个比方Agent 是一个厨师Skill 是他的菜谱。厨师Agent负责看客人点单、判断做什么菜、安排上菜顺序但具体每道菜怎么切、怎么调味、怎么控制火候靠的是菜谱里写好的流程Skill。没有菜谱的厨师只能自由发挥做出来的菜时好时坏有了标准菜谱哪怕换个帮厨换个模型底座做出来的菜也能保持在一个稳定水准上。所以 Skill 和 Agent 的关系不是包含关系而是被调用关系。一个 Agent 可以挂载多个 Skills同一个 Skill 也可以被多个 Agent 复用。设计得好的 Skill 库本身就是你团队最值钱的知识资产。3. 腾讯云 AI Skills 的核心设计和适用场景3.1 腾讯云 AI Skills 到底是什么腾讯云 AI Skills 是腾讯云上一套面向 Agent 场景的技能开发与托管方案。它允许你把自己业务里的接口、数据、操作流程按照一套标准规范封装成“技能”然后通过统一的协议暴露给 Agent 调用。我在实际使用时对它的定位是这样理解的它本质上是一个Agent 与业务系统之间的中间层。这个中间层做了三件很重要的事协议标准化不管你后端是 REST API、gRPC 还是内部 RPCAI Skills 都把它们统一包装成对大模型友好的自然语言描述让 Agent 知道什么情况下该用哪个技能。能力注册与发现你可以在平台上登记自己有哪些技能、每个技能的作用是什么、参数怎么填、返回什么样的结果。Agent 在需要时会自动检索并匹配最适合的技能。执行治理与审计技能被谁调了、调了多少次、参数是什么、结果是否异常都有日志可查。这在企业场景里极其关键——Agent 不再是一黑盒每一次动作都可以被追溯。3.2 为什么说“先设计 Skills再开发 Agent”这是我在实践里最大的一个认知转变。早期我做 Agent脑子里想的是“我要做一个能查工单的 Agent。”然后就开始搭流程、接模型、写提示词。结果搞到一半发现Agent 根本不知道怎么可靠地查工单——查工单可能要查不同系统的数据要按优先级过滤要按状态流转要通知相关人员……这一堆逻辑塞在提示词里提示词爆炸模型也崩溃。后来换成“Skills 优先”的思路就不一样了。先不想 Agent而是先列清单我的业务里有哪些原子能力可以被复用比如“查询工单列表”“获取工单详情”“更新工单状态”“给工单添加评论”“通知负责人”……这些就是技能的最小单元。先写清楚每个能力的输入、输出、调用方式把它们都沉淀成 Skills然后才设计 Agent 的决策流程。这样做的收益非常明显Agent 的提示词变短了模型只需要在技能列表里做选择不需要自己推理怎么调用接口。技能可以被测试每个技能单独跑一遍是稳定的Agent 整体就不会出什么大乱子。团队可以并行工作后端同学负责写技能算法同学负责调模型互不阻塞。3.3 腾讯云 AI Skills 的最佳使用场景我根据自己的实践把最适合用 AI Skills 的场景归了归类场景类型典型举例使用 AI Skills 的理由数据查询类查订单、查库存、查监控指标参数多、条件多靠提示词容易出错流程触发类创建工单、发起审批、执行发布有严格的参数校验和权限管控需求内容生产类生成日报、周报、营销文案需要稳定接入企业模板和风格规范知识检索类查产品文档、查内部 Wiki需要对知识库做向量化并统一召回逻辑操作执行类上传文件、发送通知、批量处理需要跟踪执行状态并且可审计当然这不是说所有场景都必须上 AI Skills。如果你的任务极其简单比如就是问模型一句“帮我翻译这句话”那直接用大模型本身的能力就够了没必要封装技能反而画蛇添足。我的原则是一次交互超过两步操作或者涉及外部系统调用就值得做成 Skills。4. 从 0 到 1 写一个 AI Skills完整实操过程4.1 技能设计的准备工作在动手写代码之前建议先回答三个问题这个技能解决什么问题一句话说清楚模糊的话就拆分。输入是什么输出是什么写清楚参数和返回结构这是 Agent 正确调用的基础。异常情况怎么处理参数非法怎么办下游服务超时怎么办权限不足怎么办这些必须在技能里兜住。我自己的习惯是用一个简单的表格来整理比如我做过一个“上传文件到 COS 并生成临时链接”的技能项目内容技能名称上传文件到对象存储并生成下载链接功能描述接收本地文件路径或二进制内容上传到指定存储桶返回临时下载 URL输入参数file_path字符串、bucket_name字符串、expires整数可选默认 3600输出结果file_url字符串、etag字符串异常处理文件不存在返回错误码 40001上传失败返回 50001 并附带原因整理清楚这些后面写代码就很顺了。别嫌这一步麻烦我见过太多人上来就写代码写到一半才发现参数设计不合理返工成本极高。4.2 创建 AI Skills 的完整步骤腾讯云 AI Skills 目前是以云上资源的形式创建的整个流程走下来大致是这几步第一步在腾讯云控制台进入 AI Skills 服务页面。如果你是第一次用需要先开通服务。这个过程很快按引导操作即可不需要提交什么复杂的申请材料。第二步创建一个新的技能。选择“创建技能”后系统会让你填写基本信息包括技能名称、技能描述、所属分类等。这里有一个坑我要专门提醒技能描述不要写得太泛。比如“处理文件”这种描述Agent 根本不知道什么时候该用你。正确的写法是“把上传的文件保存到对象存储并生成一个可访问的临时链接供下载”这样 Agent 在遇到相关任务时才能精准匹配。第三步定义技能的输入输出协议。这一步是 AI Skills 的核心。你需要声明技能接受哪些参数、每个参数的类型和约束、返回结果的结构。腾讯云 AI Skills 支持多种协议格式用 JSON Schema 是最直观的{ name: upload_file_to_cos, description: 上传文件到对象存储并生成临时下载链接, parameters: { type: object, properties: { file_path: { type: string, description: 待上传文件的本地路径 }, bucket_name: { type: string, description: 目标存储桶名称 }, expires: { type: integer, description: 链接有效期秒默认 3600, default: 3600 } }, required: [file_path, bucket_name] }, returns: { type: object, properties: { file_url: { type: string, description: 临时下载链接 }, etag: { type: string, description: 文件校验值 } } } }这里的 description 字段非常关键它会直接影响大模型对技能的理解准确度。我自己测试过描述写得具体完善的技能Agent 选中它的准确率能高出不少。第四步编写技能的执行逻辑。腾讯云 AI Skills 支持在云端直接编写执行代码相当于一个 serverless 函数。你可以在里面调用腾讯云的各种服务也可以请求自建的外部接口。核心逻辑和上面定义的协议对应上就好。import os from qcloud_cos import CosConfig, CosS3Client def run(event, context): # 从请求参数中解析入参 file_path event.get(file_path) bucket_name event.get(bucket_name) expires event.get(expires, 3600) # 校验文件是否存在 if not os.path.exists(file_path): return {code: 40001, message: ffile not found: {file_path}} # 初始化 COS 客户端按实际区域填写 config CosConfig( Regionos.environ.get(COS_REGION), SecretIdos.environ.get(COS_SECRET_ID), SecretKeyos.environ.get(COS_SECRET_KEY), ) client CosS3Client(config) # 上传文件 file_name os.path.basename(file_path) with open(file_path, rb) as f: response client.put_object( Bucketbucket_name, Bodyf, Keyfile_name, ContentTypeapplication/octet-stream ) # 生成临时下载链接 file_url client.get_presigned_url( MethodGET, Bucketbucket_name, Keyfile_name, Expiredexpires ) return { code: 0, data: { file_url: file_url, etag: response.get(ETag, ) } }注意上面这段代码里把 SecretId 和 SecretKey 放在环境变量里了。这是云上开发的基本素养——绝对不要把密钥写死在代码里。腾讯云本身提供了密钥管理服务更稳妥的方式是把敏感信息存到那里运行时动态获取。第五步调试技能并发布。发布之前一定要在控制台里做一轮完整的调试分别测试正常入参、异常入参、边界条件。我习惯把常见场景都录成用例每次改完代码先回归一遍确认没问题了再发布。4.3 从“能用”到“好用”的细节优化技能能跑通只是及格线。想让 Agent 整体效果更稳下面这几个细节值得花时间打磨参数默认值能设默认值的都设上减少 Agent 需要向用户追问的次数。比如过期时间默认 3600 秒用户没提就不用问。同义词扩展在技能描述里把可能的同义表达都写上。比如技能是“查询库存”描述里最好带上“库存”“剩余数量”“available stock”这类变体能显著提升匹配率。结果结构化返回结果不要是一段自由文本尽量用结构化的 JSON。这样 Agent 拿到结果后可以直接解析不需要再让模型“理解”一次减少出错空间。错误信息要带原因很多人的技能失败时只返回一个错误码“500”这等于没返回。正确做法是把失败原因也带出来比如“bucket not found: xxx”Agent 看到后能自己调整参数重新调用而不是直接摆烂。5. Agent 实战把 AI Skills 接入到你的智能体中5.1 配置 LLM 与模型底座litellm proxy 的经验写好了 Skills下一步就是让 Agent 真正能用上它。在这个环节我强烈建议你引入一个轻量级的模型网关层。我自己用的是 litellm proxy它的思路很简单把各种模型供应商OpenAI、Anthropic、通义、混元、DeepSeek 等的统一接口都代理到同一个 OpenAI 兼容的接口上。Agent 只跟 litellm 通信litellm 再转发到实际模型。这样做的好处是模型切换无感今天用 DeepSeek明天想换混元改一行配置就行Agent 代码完全不用动。统一计费和限流所有模型的调用都走同一个出口方便统计成本和控制并发。接口兼容AI Skills 平台对接的是标准协议litellm 天然兼容不用额外写适配层。配置起来也比较简单一个 YAML 文件就够了model_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY - model_name: deepseek-chat litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY - model_name: hunyuan-lite litellm_params: model: zhipu/chatglm_turbo api_key: os.environ/ZHIPU_API_KEY然后启动服务litellm --config config.yaml --port 4000。Agent 的 base_url 指向http://localhost:4000就能用 OpenAI 的 SDK 直接访问所有模型。这里有个经验日常跑 Agent 不要用最强的模型。我一开始迷信大模型所有任务都走 GPT-4 级别结果成本爆表速度还慢。后来换成了“两条腿走”——决策类任务用中档模型复杂推理或生成任务才用高档模型成本降了一个数量级效果差别不大。litellm proxy 做模型路由刚好能支持这种策略。5.2 用代码调用 AI Skills 的完整链路现在假设你已经在腾讯云上发布了一个“上传文件并生成链接”的技能接下来就是怎么在 Agent 里调用它。这部分我用一个 Python 示例来讲import requests import json class TencentCloudSkillsClient: def __init__(self, base_url, token): self.base_url base_url self.headers { Authorization: fBearer {token}, Content-Type: application/json } def invoke_skill(self, skill_name, params): 调用指定的 AI Skills payload { skill_name: skill_name, parameters: params } resp requests.post( f{self.base_url}/v1/skills/invoke, headersself.headers, datajson.dumps(payload) ) resp.raise_for_status() return resp.json()然后在 Agent 的执行逻辑里根据 LLM 的意图识别结果调用不同的技能from openai import OpenAI client OpenAI(base_urlhttp://localhost:4000/v1, api_keydummy) def run_agent(user_input: str): # 第一步让 LLM 决定调用哪个技能 tools [ { type: function, function: { name: upload_file_to_cos, description: 上传文件到对象存储并生成临时下载链接, parameters: { type: object, properties: { file_path: {type: string, description: 待上传文件的本地路径}, bucket_name: {type: string, description: 目标存储桶名称}, expires: {type: integer, description: 链接有效期秒} }, required: [file_path, bucket_name] } } } ] response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: user_input}], toolstools, tool_choiceauto ) # 第二步如果 LLM 决定调用工具就调用我们的技能 if response.choices[0].message.tool_calls: tool_call response.choices[0].message.tool_calls[0] args json.loads(tool_call.function.arguments) skill_client TencentCloudSkillsClient( base_urlhttps://ap-shanghai.skills.api.tencentyun.com, tokenyour_skill_token ) result skill_client.invoke_skill(upload_file_to_cos, args) # 第三步把技能结果返回给 LLM生成最终回复 messages [ {role: user, content: user_input}, response.choices[0].message, { role: tool, tool_call_id: tool_call.id, content: json.dumps(result) } ] final_response client.chat.completions.create( modelgpt-4o-mini, messagesmessages ) return final_response.choices[0].message.content # 如果不需要调用工具直接返回 LLM 的文本回答 return response.choices[0].message.content这段代码看起来简单但包含了几个非常关键的细节工具定义和 Skills 协议要保持一致。如果两边参数名对不上LLM 会生成错误的调用参数技能自然会执行失败。把工具结果作为新的消息传入第二轮对话。这步很多人在自己搭 Agent 的时候容易漏掉。LLM 只有看到工具返回的实际结果才能生成有价值的下游回复。面向不确定性的兜底。如果 LLM 决定不调用任何工具tool_calls为空代码要有一个 fallback 分支直接返回文本回答。5.3 技能编排多个 Skills 如何协作单个技能只能完成一个原子动作真实业务往往需要多个技能配合。比如“帮我整理今天的订单并生成日报”这个需求至少会拆成三步用“查询订单数据”的技能获取今天的订单列表。用“数据分析”的技能对订单做统计汇总。用“生成日报”的技能产出最终文档。多技能协作有两种常见模式模式一Agent 自主编排。把多个技能的定义都声明给 LLM让模型根据用户需求自动决定调用的先后顺序。这种方式灵活但需要模型的推理能力足够强否则容易出现中间步骤缺失的问题。模式二工作流编排。在 AI Skills 平台或者你自己的代码里预先定义好固定的步骤顺序Agent 只需要触发一次后面的流程由代码控制。这种方式确定性高适合步骤固定、容错要求高的场景。从工程稳健性的角度我的建议是核心业务链路用工作流编排外围探索性任务用 Agent 自主编排。两者并不冲突可以混合使用稳定性与灵活性兼得。6. 我踩过的坑AI Skills 实战中的常见问题6.1 技能调用失败Agent 直接“摆烂”这是我见过最普遍的问题。技能返回了一个错误Agent 不是尝试修复参数重试而是直接跟用户道歉“抱歉我无法完成这个任务。”这种体验真的很糟糕。原因在于很多人写的技能错误信息不够友好Agent 拿到之后不知道发生了什么、也不知道怎么修。解决办法是在技能设计阶段就加一层“错误恢复提示”比如返回这个结构{ code: 40001, message: file not found: /tmp/xxx.pdf, suggestion: 请检查文件路径是否正确或者先调用 list_files 技能查看可用的文件列表 }加上 suggestion 字段之后LLM 看到错误就知道下一步该怎么办了。这基本上是零成本的改动但效果立竿见影。6.2 参数描述不精确LLM 瞎传参AI Skills 平台对参数类型有校验但 LLM 在生成参数值时经常出现不符合预期的情况。比如技能要求file_path是绝对路径LLM 却传了相对路径技能要求expires是整数LLM 传了字符串 “one hour”。这个问题没法完全靠代码兜住更有效的做法是在参数描述里把格式写得极其明确。比如{ file_path: { type: string, description: 文件的完整绝对路径例如 /data/files/report.pdf不支持相对路径 } }实测下来把约束条件写进 description 比写在校验规则里更有用。因为 LLM 是“先读描述再生成参数”的描述写得清楚模型从一开始就不会犯错。6.3 上下文太长模型把技能调用忘了Agent 在多轮对话中如果历史消息过长模型可能会在后续轮次中忘记自己已经调用过某个技能或者忘记技能返回过什么结果。解决这个问题有两个方向上下文压缩把历史消息做摘要把无关过程信息丢弃只保留用户核心诉求和最近一次技能结果。短期记忆显式化在每轮 LLM 调用前把最近一次技能的结果作为“系统提示”插入消息中确保模型始终能看到关键信息。我自己更推荐第二种简单直接不需要引入额外的摘要模型效果也稳定。6.4 别让技能“幻觉”——给 Skills 加上反馈校验大模型有幻觉这个大家都知道。但其实技能也可能“幻觉”——执行成功了但结果本身就不对。比如查询接口本身有 bug返回了错误的数据Agent 拿着错误数据继续推理就会产生连环错误。针对这类问题我习惯在每个技能的输出部分加一个“自查建议”。比如查询类技能返回数据时加上查询条件和时间范围Agent 可以自己判断这个结果是否符合用户的问题预期。不需要做太复杂只是给模型一个校验线索就能明显降低下游错误率。7. 成本、性能与安全Agent 落地绕不开的三件事7.1 模型成本怎么控制做 Agent 项目模型 token 成本是逃不开的。我看到很多团队一个月烧几万块的 token 费用最后效果还一般。他们大多犯了一个错误所有请求都走同一个高档模型。控制成本的核心思路是分级路由任务类型推荐模型档位说明意图识别、技能选择轻量级模型如 mini 版任务简单不需要深度推理数据分析、代码生成中档模型需要一定推理能力但不是极限挑战复杂规划、长文档理解旗舰模型只用于高价值、高复杂度的任务litellm proxy 支持按模型名称路由你可以配置多个模型然后在代码里指定不同的任务用不同的 model 名称。这样一套代码成本能降一半以上。7.2 性能优化响应时间怎么压下来Agent 的交互延迟通常由三部分构成LLM 推理时间、技能执行时间、网络往返时间。想优化响应速度可以逐一排查LLM 推理时间用流式输出streaming让用户先看到部分结果感官上会快很多。技能执行时间优先用 serverless 函数而不是常驻容器冷启动时间短如果技能内部有大量 I/O 操作考虑异步化。网络往返把 Agent 服务和 AI Skills 部署在同一个地域减少跨地域的网络延迟。这些优化单独看都是小改动叠加起来响应时间能缩短一半体验完全不一样。7.3 安全合规Agent 的每一次动作都要留痕企业级 Agent 和玩具 demo 最大的区别就是对安全和合规的要求。AI Skills 在执行敏感操作时必须做到权限最小化技能本身只申请完成任务所需的最低权限比如“查询订单”的技能就只给只读权限绝不顺便给删除权限。敏感操作二次确认对于删除、修改、发布这类动作技能里应该强制设置一个确认机制Agent 必须拿到用户明确的确认信号才能执行。全链路审计所有技能调用都记录日志包含调用方、参数、结果、时间。这样出了问题才能回溯。腾讯云 AI Skills 平台本身就带审计能力把日志打开别嫌麻烦。出了安全事故再补日志那就晚了。8. 一个真实的完整案例企业内部“文档问答 自动归档” Agent为了让你更直观地理解前面讲的东西怎么串起来我分享一个刚做完的案例。需求方是一家做产品咨询的公司他们内部积累了大量项目文档、会议纪要、客户方案想做一个能回答“XX 项目的关键结论是什么”“去年代客户方案里关于数据迁移的报价是多少”这类问题的内部助手同时还要能自动把新生成的会议纪要归档到正确的位置。这个需求拆解下来核心是四个 Skills技能名称功能关键参数search_documents向量化检索内部文档keyword关键词、top_k返回条数、date_range可选时间范围get_document_detail获取文档全文doc_id文档 IDparse_meeting_notes解析会议纪要提取结论和待办file_path会议纪要文件路径archive_document把文档归档到指定项目目录doc_id文档 ID、project_name项目名称Agent 的工作流程是用户提问 - LLM 判断是知识问答还是归档任务 - 调用对应技能 - 技能返回结果 - LLM 组织最终回答。这个项目最大的难点不在 Skills 本身的开发而在于第一版上线后遇到了两个问题。一是跨项目检索的结果不准很多来自不同项目的文档内容很像比如都提到了“数据迁移”这个词。后来我们在 search_documents 技能里加了一个project_name可选参数提示 LLM 在用户明确提到某个项目的时候带上这个参数检索精度一下子提升了不少。二是会议纪要解析技能面对不同模板的纪要效果不稳定我们灌了一批不同格式的样例进去通过 few-shot 的方式让技能学会了识别各种表格结构这部分也花了不少时间调。从投入产出比来看这类企业内部的“文档问答 归档”场景非常适合用 AI Skills 来做。原因很简单文档格式相对固定查询逻辑清晰流程稳定很适合标准化沉淀。9. 继续折腾的方向从“能用”到“好用”的几个进阶思路写到这里基础的 AI Skills 开发流程和 Agent 集成方法已经讲得差不多了。最后聊几个我最近在琢磨的、觉得值得继续折腾的方向。第一个是Skills 的自动扩缩容与弹性调度。AI Skills 本质上是无状态的服务完全可以按调用量动态扩缩容。目前我是在腾讯云上配置了按请求数触发的弹性伸缩规则高峰期自动扩容低峰期自动缩容成本能省不少。如果你也遇到流量波动大的场景这个方向值得研究。第二个是跨 Agent 的技能共享与市场机制。把 Agent 生产的技能还有另一个思路值得尝试把提示词调优和技能发布的流程做成自动化的流水线。我现在是把技能的版本管理接入了 Git 仓库每次改动走 CI/CD 流程自动跑测试、自动发布。这样多人协作的时候技能的变更历史一目了然出问题也能快速回滚。一开始觉得这套流程重真跑起来之后发现省心太多了。我自己的体会是Agent 开发的终局大概率不会是“每个人从头写一个 Agent”而是“大家在一个共享的技能生态里各取所需”。AI Skills 现在的样子虽然还有很多不完善的地方但方向是对的。希望这篇文章能给你一些灵感和可落地的参考少走一些我走过的弯路。