1. Agent 卡在“演示即巅峰”的根因技能层缺失先聊一个我最近越来越强烈的感受很多开发者的 Agent 项目Demo 演示时惊艳全场一上真实业务场景就露馅。不是模型不够强不是框架选得不好而是整个项目缺了最关键的“技能层”。所谓技能层就是把模型的能力和具体的工具、流程、业务逻辑焊接在一起的那层胶水。模型知道“应该调用某个函数”但函数写在哪、怎么描述、参数怎么传、异常怎么兜底全靠技能层承担。没有这层Agent 就是一台没有驱动程序的硬件看着全须全尾实际上什么都干不了。我在腾讯云上折腾 AI Skills 的时候把这个问题彻底想明白了。AI Skills 本质上提供了一种标准化的技能封装方式用 SKILL.md 声明技能用途和参数用脚本或 API 实现具体动作再把技能挂载到 Agent 的运行时里。这套思路和 Anthropic 的 Claude Skills、社区里流行的 SKILL.md 规范是一脉相承的但落到了腾讯云的基础设施上意味着技能可以享受云端的算力、存储和网关能力而不是每台机器各自为政。这个项目的核心目标很朴素把一个只会“聊天”的通用 Agent养成一个能在真实业务里干活的“全能选手”。它能查数据库、能调内部接口、能按规范生成代码、能处理文件、能回答具体领域的问题。养成路径分三步先写明白技能描述再让 Agent 学会调用技能最后通过真实用例反复打磨。这篇文章就是我踩完坑之后的最佳实践复盘。如果你也在做 Agent 开发或者正准备给现有 Agent 接入工具链这篇内容可以当一份工程参考。我不会只讲“怎么写 SKILL.md”还会把域名、网关、模型服务路由、记忆设计、安全边界这些真正决定成败的细节一并说清楚。2. 腾讯云环境里最容易被新手搞砸的三件事域名、端口与网关不管是自建 Agent 平台还是接入现成框架第一步永远是环境。但腾讯云这套环境有很多隐性约束文档里写得含含糊糊搜到的教程又各说各话我一度在这里耗了整整一个下午才把三件事彻底理清。2.1 二级域名申请不是为了好看是为了技能回调很多人不理解Agent 跑得好好的为什么要申请二级域名原因在于 Agent 的技能不只是“本地执行”很多时候需要暴露成 Webhook让云端服务或者外部系统回调。比如一个“每日自动生成报表”的技能定时器触发之后要调用 Agent 的接口这个接口就必须有公网可访问的地址。腾讯云上申请二级域名的路径不复杂域名解析控制台里添加一条 A 记录或 CNAME 记录即可。但要注意两个细节。第一域名必须完成备案否则解析能用80 和 443 端口的访问会被拦截第二建议单独建一个子域名给 Agent 系统用比如 agent.example.com不要跟主站混在一起后面做证书管理、流量治理都会省心很多。我在实际项目中踩过一个坑图省事把 Agent 的回调地址指向了主域名的一个路径结果主站发版时把那个路径覆盖了Agent 的定时任务静默失败了两天。后来单独拎出 agent.example.com通过网关层做路由分发再没出过类似问题。2.2 开放端口的安全组策略不能直接“全部放通”“腾讯云如何开放所有端口”是很多人搜过的问题我不建议这么做。安全组里放通 0.0.0.0/0 的所有端口等于把整台服务器裸奔。Agent 系统要对外提供服务真正需要开放的端口非常有限。实操中建议这样配置端口用途放通范围443HTTPS 回调入口全网或指定 IP22SSH 登录管理仅限办公网 IP9090内部监控面板仅限管理网段如果你只是本地调试连安全组都可以不动直接用 SSH 隧道转发端口就行没必要为了临时调试把端口敞到公网。腾讯云服务器还有个容易被忽略的地方安全组之外操作系统自带的防火墙也可能拦截端口例如 firewalld 或 ufw。两者都要放行否则安全组明明写了允许外部照样连不上排查起来极其绕。正确做法是先确定“最小暴露面”再逐层放行。HTTP 服务尽可能用 HTTPS 终结在网关层Agent 的后端端口绑定 127.0.0.1只让网关访问这样即使被扫到端口也无法直接触达应用。2.3 网关层是 Agent 系统的“门卫”不是可有可无的代理很多 Agent 框架自带路由能力可以直接把回调打到某个服务端口上。但真实项目里你一定会遇到这些需求请求鉴权、流量限制、多技能路由、灰度发布、日志记录。如果这些逻辑全部写进 Agent 应用里代码很快会失控。腾讯云上可以用 Nginx 或 API 网关承担这层职责。以 Nginx 为例配置一个 /v1/skills/ 前缀的 location把请求反向代理到本地的 Agent 服务端口同时在 server 块里挂载 SSL 证书。网关层做掉 HTTPS 终结后后端服务内部全部走 HTTP 明文减少了证书配置的复杂度也方便在网关层统一注入认证逻辑。这里有一个重要的工程决策API 网关和 Agent 框架的认证体系要打通不要搞两套鉴权。我在网关层配置了统一的 Bearer Token 校验所有技能回调必须带合法 token 才能到达后端Agent 框架内部再按用户维度做细粒度权限控制。两层鉴权一层管流量一层管数据边界清晰很多。3. AI Skills 的编写规范SKILL.md、frontmatter 与脚本拆分的工程化写法技能层的核心是 AI Skills 的编写。这一节是全文的硬核区适合边看边动手。我会按“描述—参数—动作—兜底”的链路拆开讲每一层都有具体的写法示例和我在实践中总结的边界条件。3.1 SKILL.md 是技能的名片更是 Agent 决策的路由表一个技能文件通常以 SKILL.md 为核心里面用 YAML frontmatter 声明元信息用正文描述使用场景和步骤。模型在收到用户请求时会先扫描所有可用的 SKILL.md根据名称、描述、适用场景来判断要不要采用该技能。所以这份文档的措辞质量直接决定 Agent 能不能在正确的时机调用到正确的技能。看一个实际的项目案例。我在做财务数据查询 Agent 时写了一个“季度营收分析”的技能frontmatter 长这样--- name: quarterly_revenue_analysis description: 分析指定季度的营收数据生成同比/环比变化报告。适用于用户询问营收、业绩、季度财务数据等场景。 arguments: 季度: type: string required: true description: 目标季度格式为 YYYYQn例如 2025Q1 同比基准: type: string required: false default: 去年同期 description: 可供选择的同期对比基准默认去年同期 ---这里的 argument 命名要用中文还是英文我的经验是不要用复杂英文关键词直接用业务语言“季度”“同比基准”就很好。模型对中文语义的理解更稳定而且参数名直接暴露给用户可读性也会拉满。每个参数务必写明格式和默认值否则模型会自由发挥传进来的值千奇百怪。3.2 正文步骤写得越具体Agent 执行的稳定性越高SKILL.md 的正文部分很多人只写两三句话就完事这是大忌。模型不是人它不会“领悟”你的意图只会按文字提示推断执行路径。一份好的技能文档应该把执行步骤像 SOP 一样写清楚关键判断条件用条件句标明。还是拿财务分析技能举例正文部分我是这样写的解析用户输入的季度参数格式化为 YYYYQn若用户只给了年份默认取该年 Q4。连接财务数据库查询目标季度与对比基期的营收总额、成本总额、毛利额。计算同比和环比增长率的公式增长率 本期数 - 基期数/ |基期数| × 100%。若基期数为 0 或缺失则在报告中标注“基期无数据”不输出百分比。生成结构化 Markdown 报表包含数据表格、关键结论、异常提醒三部分。我在实际测试中发现模型对“步骤越细致执行越稳定”的响应非常明显。同一套技能脚本只有笼统描述时模型有时跳过第 2 步直接编数据写清楚步骤之后执行的完整率提升非常明显。原因也不难理解Agent 的任务链路本质上是对文档描述的逐步解释执行描述里的每一条指令都是一个潜在的路由节点。3.3 脚本拆分技能不等于一个文件而是一个目录很多人误以为 AI Skills 就是“一个 md 文件 一段提示词”这是把技能和提示词混为一谈了。单一文件能承载的动作非常有限稍微复杂的技能就撑不住。我的实践习惯是每个技能一个目录里面至少包含 SKILL.md 和可执行脚本按需拆分辅助模块。例如我写的“日报生成”技能daily_report/ ├── SKILL.md ├── main.py └── templates/ └── report_template.mdmain.py 负责从数据库拉取数据并填充模板SKILL.md 负责告诉模型“什么时候该用这个技能、参数是什么、输出格式是什么、异常怎么处理”。模型不会去读 Python 代码它只读 SKILL.md代码细节对模型是黑盒。这种目录化结构还有一个额外的好处可以在 templates 里放多个模板按部门维度生成不同版式的日报不需要改代码改模板即可。如果你写的是纯工具型技能比如“把这段 HTML 转成 Markdown”那一个脚本文件就够了不需要硬套目录结构。技能拆分粒度要控制在“职责单一、上下文完整”的范围内太粗会让模型难以复用太细会让技能列表爆炸反而增加模型的选择成本。3.4 参数约束与输出约束让 Agent 学会“说不”这是我踩坑最深的一个环节。早期我写的技能文档没有约束输出边界模型经常发挥“创造力”让它查数据它找不到就自己编让它生成代码它在代码里加注释解释人生道理。后来我养成了一个习惯在 SKILL.md 里专门加一段“执行边界”。执行边界 1. 所有数据必须来自真实查询结果禁止根据记忆或推测生成数据。 2. 若查询无结果必须明确输出“未查询到相关数据”不得使用近似值代替。 3. 本技能仅处理数据库查询与分析任务不回答与此无关的问题。 4. 生成的报表中所有百分比保留两位小数金额单位为万元。这段边界说明对模型行为的约束力比系统提示词里的“请务必准确”强得多。因为系统提示词是全局的模型很容易在长上下文里遗忘而技能文档是在调用那一刻被加载进来的属于“局部强提示”情境相关性极高。4. 把 Agent 接到模型服务LiteLLM Proxy 与工具调用框架的整合细节技能写好了Agent 还需要一个真正能干活的“大脑”——模型服务。这一节讲讲我调用模型服务时最常用的一个开源中间件LiteLLM Proxy以及它在 Agent 工具调用链路里扮演的角色。4.1 为什么中间要套一层 LiteLLM Proxy 而不是直连模型 API很多教程让你直接在 Agent 代码里写模型 API 的 base_url 和 key这在小 Demo 里没问题但稍微正经一点的项目痛点立刻会出现。第一个痛点是多模型路由。财务场景可能用便宜的轻量模型做分类代码生成场景用强模型翻译场景可能又是另一个模型。Agent 框架往往只支持配置一个模型端点每次切换都要改配置重启服务。LiteLLM Proxy 可以充当统一入口对外暴露一个兼容 OpenAI Protocol 的地址内部按模型名路由到不同厂商的模型。第二个痛点是成本与限流。你不想每次改模型配置都动 Agent 代码更不想让调用方直接持有厂商 API 的密钥。LiteLLM Proxy 把密钥统一收在服务端客户端只认 Proxy 的 key权限收口之后安全责任清晰很多。第三个痛点是工具调用参数的兼容性。不同厂商的 function calling 格式存在细节差异直接接进 Agent 框架容易在参数解析上踩坑。LiteLLM Proxy 的协议转换层会把各家格式统一成 OpenAI 风格我在实际项目中直接用这套方案对接过不同模型工具调用参数没有发生截断或错位。4.2 在腾讯云上跑 LiteLLM Proxy 的配置模板环境准备上我建议把 Proxy 和 Agent 服务部署在同一台腾讯云服务器的内网段这样访问不走公网延迟和安全性都有保障。不需要太高配置2C4G 的实例足够支撑日常负载重点监控内存占用。下面是我实际在用的 config.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 litellm_settings: drop_params: true set_verbose: false general_settings: master_key: sk-your-master-key database_url: postgresql://user:passlocalhost:5432/litellm启动命令我用的是litellm --config config.yaml --port 4000然后 Agent 框架里的 base_url 填写http://127.0.0.1:4000/v1即可模型名写 config 里定义的 model_name例如gpt-4o-mini或deepseek-chat。所有模型相关变更都通过修改 config.yaml 完成Agent 服务不需要重启。这里特别提醒一下drop_params: true的用途。不同模型对参数的支持范围不同例如某些模型不支持temperature为 0 或者不响应top_p。如果不开启 drop_paramsProxy 会把这些参数透传给模型可能引发 400 错误。开启之后 Proxy 会自动丢弃目标模型不支持的参数虽然会损失部分控制粒度但换来的是调用稳定性这在工具调用场景里优先级更高。4.3 工具调用链路上的上下文管理接入模型服务之后另一个容易忽略的问题是“工具调用链路里的消息堆积”。Agent 每调用一次技能都会产生新的工具结果消息多轮工具调用之后上下文很容易超过模型的窗口限制。我的做法是给 Proxy 和 Agent 之间加一层上下文压缩逻辑。可以在 Agent 代码里维护一个“消息清单”前面的历史消息按 token 数裁剪只保留最近的系统提示、最近的用户问题、最近几轮工具调用记录。裁剪的边界依据是模型窗口的 70%超过就触发压缩。实践下来“把历史消息摘要化”比“硬截断”效果更好。每一次技能调用结束后让模型生成一条当前任务状态的简短摘要塞进下一轮上下文。这样 Agent 既不会丢失前面的决策依据又不会让上下文无限膨胀。这也是后面第 5 章“记忆设计”的地基。5. 记忆系统设计让 Agent 从“每次都重新认识你”到“越用越懂你”“全能 Agent 养成”不仅仅是技能堆叠更关键的是记忆系统。没有记忆的 Agent每个会话都是新人有记忆的 Agent才会越用越顺手。这一节我会讲一套轻量但完整的记忆分层方案不需要引入重型向量数据库也能跑起来。5.1 会话记忆 vs 长期记忆不要混为一谈很多开发者一上来就上向量数据库把聊天记录全部向量化结果查询效果差维护成本高。问题的根源是把两种记忆混在一起了。会话记忆是短期记忆只服务于当前对话轮次。它保持的是最近几轮的原始消息用于维持上下文的连贯性。长期记忆则要经过“提炼—存储—检索”三个环节存储的不是原始流水而是结构化的事实和偏好。例如用户在一个会话里说“我习惯报表里金额显示成万元”这属于长期偏好应该提炼后存入长期记忆而不是让模型每次从聊天记录里翻。我建议把长期记忆分为两类事实记忆用户的身份、业务偏好、项目背景、格式习惯程序记忆用户对技能使用的偏好例如“日报生成到钉钉群而不是邮件”会话记忆用列表存内存即可长期记忆可以落库。对于大多数业务场景一张带 JSON 字段的 Postgres 表足够不需要单独引入向量数据库。等到记忆条目涨到几千条以上再考虑用 embedding 做语义检索。5.2 记忆写入的时机会话结束前做一次“记忆提炼”我不建议在每轮对话都写长期记忆成本和噪音都太高。我的做法是在一个任务链路结束时做一次提炼。所谓“任务链路”就是从用户提出需求到 Agent 交付结果的过程可能跨多轮对话。触发提炼的信号可以是用户明确结束当前任务例如“就这样吧”“好的谢谢”技能调用返回成功且输出被用户确认连续 N 轮对话后上下文即将被压缩提炼动作本身也是一个 AI Skills 技能负责从对话历史中抽取“值得长期记住的事实”。这个技能的 SKILL.md 里要定义清楚抽取范围只抽取事实性、偏好性信息不抽取过程性信息。例如“用户提到了 2025 年计划扩展海外市场”值得记“用户说今天天气不错”不值得记。我实际测试下来让模型做记忆提炼的效果远远好于直接存原始对话。原因在于提炼过程本身是一次语义压缩模型判断过哪些信息值得保存比无差别的全量存储精准得多。5.3 检索注入把记忆放到模型看得见的地方记忆系统的另一半是“读”。每次用户发起新对话时Agent 会根据用户标识拉取相关的长期记忆注入系统提示词。这里的注入模板我打磨了很久最终长这样以下是该用户的长期记忆 - 用户偏好金额以万元为单位展示 - 用户负责华东区业务重点关注渠道周转率 - 用户每周一上午需要一份上周渠道简报 请你在回答时结合上述记忆若记忆与当前对话冲突以当前对话为准。最后一句“以当前对话为准”非常关键否则用户临时改了需求模型还抱着旧记忆不放很容易产生混乱。另外记忆的注入量要受控我一般限制在 20 条以内超出就按时间排序只保留最近 20 条。记忆不是越多越好过量的记忆会让模型不知道该以哪条为准反而降低回答质量。5.4 记忆冲突的处理让模型自己“确认覆盖”长期记忆难免会过时。用户在早期说“我不用钉钉”三个月后说“把报表发钉钉”这时旧记忆和新需求冲突。我处理冲突的方式是显式的覆盖确认而不是让模型自己加权判断。当提炼技能发现新事实与旧记忆冲突时主动向用户确认一次“检测到您之前不使用钉钉现在需要改为钉钉接收报表吗”。确认后更新记忆条目并把旧条目标记为已废弃。这套流程看起来简单但对 Agent 的“可信度”影响很大。用户能明显感受到 Agent 是“记得”他的而且“改口”之后 Agent 会立刻适应不再闹出“又说不用钉钉又把报表发钉钉”的笑话。养成记里的“越用越懂你”本质上就是这么一点一滴积累出来的。6. 真实部署踩坑实录从报错到稳定的完整排查链路这一章记录我在腾讯云上一路踩过的坑。搜索热词里出现的“腾讯云注册网络环境异常”“agent execution terminated due to error”这些关键词我在实践里几乎都撞过一遍。把这些排查链路写清楚希望能帮你少走几趟弯路。6.1 注册时提示“网络环境异常无法进行注册”怎么办这个报错我遇到过当时挺懵的网络明明没问题浏览器也正常但注册页一直提示“您所处的网络环境异常无法进行注册”。后来排查下来大概率是触发了账号注册环节的异常访问保护。这类保护通常与 IP 信誉、访问频率、浏览器指纹相关不一定是你真正干了什么坏事。我的处理经验是先彻底清理浏览器缓存和 Cookie关闭插件确认没有启用任何代理或流量转发工具后重试。如果仍然不行换一个网络环境例如用手机热点访问注册页面往往能绕过本网络环境下被标记的 IP 信誉度问题。最后一种方案是联系腾讯云客服说明情况后走人工审核通道一般都能解决。不要尝试用技术手段绕过注册风控这既不安全也没有必要。6.2 Agent 执行报“terminated due to error”的完整排查链路刚开始部署 Agent 技能时日志里频繁出现类似 agent execution terminated due to error 的报错。这类错误很笼统最初我以为是代码问题反复检查脚本都没毛病。后来才发现它是上游问题的“症状”要往下面逐层找。排查链路我按这个顺序走第一步确认技能入口的鉴权。如果你在网关层加了 Bearer Token 校验而技能调用者没有带 tokenAgent 框架会直接终止执行并返回通用错误。在网关日志里看到 401/403 就说明问题在这层。第二步确认请求能否到达后端服务。用 curl 模拟一次技能回调观察返回状态码和响应体。如果 curl 直接超时或拒绝连接问题很可能出在网络层检查安全组和服务器防火墙是否放行对应端口。第三步确认模型服务的连通性。Agent 调用技能脚本前通常要先和模型服务交互例如判断调用哪个技能、生成参数。如果模型服务的 API key 配置错误或者 Proxy 没启动也会产生 “terminated” 报错。检查 LiteLLM Proxy 的日志看有没有 model not found 或 authentication error 的记录。第四步检查技能脚本自身的异常处理。脚本抛出未捕获异常时Agent 框架往往只能给出一句笼统错误信息。建议在所有技能脚本入口包一层 try-except把异常堆栈写回日志文件。这样反馈链路的可观测性会大幅提升。这四步里的 80% 问题都集中在第一层和第二层尤其是网关鉴权配置错误。很多人一看到 “terminated due to error” 就以为是代码问题调脚本调了半天其实请求根本没进到后端白费力气。6.3 端口“开放了但连不上”的经典连环坑“端口明明开了为什么在外面还是连不上”是个老生常谈的问题但在腾讯云上有它特有的坑。我复盘一下自己的排查过程。第一次遇到检查安全组入站规则443 端口已放通用腾讯云控制台的“一键检测”也提示正常但在本机浏览器访问 https://agent.example.com 却直接超时。后来才发现域名解析记录指向的 IP 是另一台已销毁的旧服务器流量全跑到不存在的地址上与端口无关。第二次遇到域名解析没问题443 端口也通但仍然超时。排查到最后一层才发现是 Nginx 配置的 proxy_pass 目标端口写错了8080 写成了 8081导致网关转发失败。这类问题用curl -v看响应头很容易定位但如果不看日志光盯安全组和解析记录能白折腾半天。总结下来一个端口连不上要按“域名解析 → 安全组 → 系统防火墙 → 服务监听 → 网关转发”五层链路逐一排查每一层都有对应的验证命令。不要跳步也不要凭经验猜测是某一层的问题。7. 安全加固与权限边界Agent 上生产之前必须做的事Agent 的能力越强安全风险越高。一个能调数据库、能发消息、能操作文件的 Agent一旦被攻破破坏半径远大于普通 Web 应用。我在项目从 Demo 走向生产时按下面几个维度做了加固。7.1 密钥管理把密钥从代码里彻底摘出去最常见的低级错误是把 API key 硬编码在脚本里这对 Agent 项目来说尤其致命因为 Agent 技能脚本往往是模型动态生成和修改的密钥一旦混入代码很容易在上下文或日志中泄露。我在腾讯云上使用密钥管理服务保存各类密钥技能脚本运行时通过环境变量或 SDK 从密钥管理服务读取不落盘、不进代码库。LiteLLM Proxy 的 config.yaml 里也不要直接写明文 key用os.environ/xxx的方式引用环境变量再把环境变量托管到进程管理器中。7.2 技能执行的最小权限原则每一个技能脚本都应该运行在“刚好够用”的权限边界内。比如数据库查询技能使用的数据库账号只授予 SELECT 权限不给 INSERT/UPDATE/DELETE除非技能明确需要写入。文件操作技能只允许读写指定目录禁止访问系统目录。消息推送技能只允许调用指定的接口不允许自由指定收件人。这个原则执行起来不难难在克制。很多开发者为了调试方便给技能统一配了一个“管理员账号”结果就是一个技能被注入整个系统沦陷。最小权限会带来一些部署时的额外操作成本但这是 Agent 上生产的底线。7.3 输出过滤与日志审计Agent 的输出不能无条件信任。模型可能被诱导输出敏感信息也可能因上下文混乱输出错误数据。我建议在 Agent 的出口加一层输出过滤规则可以先用关键词和正则做基础过滤再叠加人工审核流程处理高风险输出。日志审计对 Agent 项目来说比传统项目更重要因为 Agent 的执行链路是多跳的发现问题时需要回放“模型当时看到了什么、做了哪个判断、调用了哪个工具、返回了什么结果”。所有技能调用的输入输出、模型生成的中间思考、工具返回的原始数据都应该记录在案。我在腾讯云上把日志写入了日志服务按天分桶查询和回放都很方便。7.4 对话注入的防御思路所谓对话注入就是用户通过构造特殊的输入试图让 Agent 执行非预期操作。传统安全测试关注的是接口参数注入而 Agent 面临的是“提示词注入”这一新维度。防御思路不能只靠系统提示词里的“你是安全的”我实践下来有三层有效手段。第一层是在技能调用前做参数白名单校验例如“查询季度的参数必须匹配 YYYYQn 格式”格式不对直接拒绝不给模型自由发挥的空间。第二层是敏感操作二次确认删除操作、发送外部消息、涉及资金变动的操作必须让用户明确确认后才执行。第三层是上下文隔离用户输入中的“指令”和技能执行的“动作”分离存储避免用户构造的内容被误解析为新指令。8. 把 Agent 养成“全能”的几个工程习惯走到这里你已经有了一整套可运行的 Agent 技能系统。但要真正实现“全能”还差一些工程习惯上的打磨。这一节分享几个我在实践里觉得收益最高的习惯。8.1 技能目录命名与版本管理技能多了以后目录结构如果不规范会变成一场灾难。我的命名规范是动词_对象例如query_revenue、generate_report、send_email。一个技能目录做好三件事SKILL.md 是当前版本说明changelog.md 记录改动历史examples/ 目录放典型输入输出样例。版本管理不只是为了回溯更关键的是给模型提供参考样例。examples 目录里放 2-3 个高质量的真实案例模型调用技能时如果遇到模糊需求会参照样例输出稳定度比没有样例时有明显提升。8.2 自动化评测让技能越改越稳技能迭代最怕的是“修好一个 bug毁了另一个功能”。我给技能建立了一套自动化评测本质上就是一组预置的测试用例每个用例写清楚输入和期望输出。技能改动后跑一遍评测观察通过率和输出质量再决定是否发布。评测用例的构造思路是覆盖正常路径、边界参数和异常输入。例如季度营收分析技能测试用例包括正常季度查询、跨年季度查询、基期无数据查询、参数格式错误查询。这套用例跑下来技能的稳定性就有了量化指标。8.3 渐进式开放工具不要一步到位新手最容易犯的错误是先给 Agent 挂满十个八个工具然后祈祷模型每次都能选对。模型的工具选择能力与工具的“辨识度”密切相关工具描述写得含糊时模型的选择几乎是随机的。我的习惯是渐进式开放先挂 3-4 个核心工具跑通流程观察模型的调用准确率准确率稳定后再逐步增加工具。新增工具后连续监控一段时间的调用分布如果发现某个工具长期不被调用就去检查它的描述是否清晰或者考虑合并进其他工具。8.4 记录每次“翻车”形成技能的负例集这个习惯是我个人最看重的。每次 Agent 在真实使用中翻车数据错误、工具调用不当、生成无用内容我都会把当时的对话链路保存下来标记为负例并在 SKILL.md 的“执行边界”里补充对应的约束条件。例如有一次Agent 在查询“今年一季度营收”时把去年一季度的数据当成了今年一季度。复盘发现是脚本里的时间解析逻辑写死了去年而 SKILL.md 里没有明确“今年”的判定规则。后来我补了一条边界“季度参数中的年份不得硬编码必须从当前系统时间动态推导。”类似这样的负例积累多了技能的健壮性会有质变。写在最后Agent 养成的底层心法这一整套系统跑通之后我最深的体会是Agent 的“全能”不是模型单方面赐予的而是靠技能层、记忆层、安全层和评测层一点点垒出来的。模型负责的是“聪明”技能层负责的是“可靠”记忆层负责的是“懂你”安全层负责的是“不出事”评测层负责的是“越改越好”。如果你正准备动手我的建议是先从一个高频、重复、规则明确的业务场景切入写好第一个技能跑通“技能调用—工具执行—结果输出—记忆沉淀”的完整闭环。不要一上来追求大而全Agent 的成长和人的成长一样是一步步迭代出来的。最后再分享一个小技巧给每一个技能准备一个“人话版”说明放在技能的 examples 里。当模型因为描述太抽象而选错技能时把这个人话版的例子发给模型做参考往往比反复修改 SKILL.md 的效果来得更快。实践出真知祝你早日养成属于自己的全能 Agent。