全能Agent养成记：技能层、记忆系统与安全加固实战

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 系统要对外提供服务，真正需要开放的端口非常有限。

实操中建议这样配置：

如果你只是本地调试，连安全组都可以不动，直接用 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 一样写清楚，关键判断条件用条件句标明。

还是拿财务分析技能举例，正文部分我是这样写的：

1. 解析用户输入的季度参数，格式化为 YYYYQn，若用户只给了年份，默认取该年 Q4。
2. 连接财务数据库，查询目标季度与对比基期的营收总额、成本总额、毛利额。
3. 计算同比和环比增长率的公式：增长率 =（本期数 - 基期数）/ |基期数| × 100%。
4. 若基期数为 0 或缺失，则在报告中标注“基期无数据”，不输出百分比。
5. 生成结构化 Markdown 报表，包含数据表格、关键结论、异常提醒三部分。

我在实际测试中发现，模型对“步骤越细致，执行越稳定”的响应非常明显。同一套技能脚本，只有笼统描述时，模型有时跳过第 2 步直接编数据；写清楚步骤之后，执行的完整率提升非常明显。原因也不难理解：Agent 的任务链路本质上是对文档描述的逐步解释执行，描述里的每一条指令都是一个潜在的路由节点。

3.3 脚本拆分：技能不等于一个文件，而是一个目录

很多人误以为 AI Skills 就是“一个 md 文件 + 一段提示词”，这是把技能和提示词混为一谈了。单一文件能承载的动作非常有限，稍微复杂的技能就撑不住。我的实践习惯是：每个技能一个目录，里面至少包含 SKILL.md 和可执行脚本，按需拆分辅助模块。

例如我写的“日报生成”技能：

daily_report/ ├── SKILL.md ├── main.py └── templates/ └── report_template.md

main.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:pass@localhost: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_params，Proxy 会把这些参数透传给模型，可能引发 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 校验，而技能调用者没有带 token，Agent 框架会直接终止执行并返回通用错误。在网关日志里看到 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。