最近社区里聊 Agent 的人越来越多但说实话大部分教程都停留在“调接口、拼 Prompt”的层面真正能把 Agent 落到生产环境、让它稳定干活的内容很少。我花了大概三周时间在腾讯云上把一个带技能体系AI Skills的 Agent 从零搭到可用中间踩了容器推送、二级域名、Redis 密码、模型网关配置一堆坑。这篇文章就是那次完整实践的复盘重点讲清 AI Skills 的设计思路以及在腾讯云上部署时那些文档里不会写清楚的细节。这篇内容适合两类人一类是已经在做 Agent 开发、想给机器人增加“干活能力”的工程师另一类是刚把 Agent 概念接入项目、准备上云部署但不确定基础设施怎么选的团队。文章不绕弯子直接从“为什么需要 Skill”讲起到腾讯云服务器、容器镜像服务、Redis、域名解析、模型网关一步步展开最后是所有坑的排查清单。你看完可以直接照着抄。1. 先想清楚Agent 为什么需要 Skill而不是靠 Prompt 硬撑1.1 从“聊天机器人”到“能干活的人”我先说一个观察很多团队做 Agent 的第一版本质上就是把大模型的 Prompt 写长了一点让模型“看起来”会调用几个 API。这种方案做 Demo 没问题但一旦进入真实业务马上会遇到三个麻烦第一Prompt 越长模型越容易在关键步骤上“自由发挥”。你让它调两个接口完成一个流程它可能会跳过第二个或者把参数传错。第二所有逻辑都堆在 Prompt 里运维和排错极其痛苦。线上出问题你根本不知道是模型理解错了还是接口返回的数据格式变了。第三你想给 Agent 加一个新能力比如“查一下订单物流”就得重新改写 Prompt反复调优改完还可能影响原本稳定的功能。Skill 解决的就是这个问题。它的本质是给 Agent 预装一套“操作手册”把某个能力的调用方式、参数约束、输出格式、异常处理都固化下来。Agent 在运行时会根据用户需求去检索和调用合适的 Skill而不是靠模型现场“猜”。我自己的体会是把 Agent 从“聊天”变成“干活”分水岭就在于有没有一套结构化的 Skill 体系。没有 Skill 的 Agent就像一个新员工只有一堆口头叮嘱干不干得好全看悟性有了 Skill等于给这个员工配了标准作业流程和工具说明书。1.2 Skill 到底是什么给 Agent 预装的操作手册Skill 可以理解为一段结构化的能力描述加执行逻辑。它通常包含三个部分触发条件、调用接口的方式、结果处理规则。举个具体的例子。我给 Agent 注册了一个“查询腾讯云服务器监控数据”的 Skill。它的触发条件是用户在对话中提到“服务器负载”“CPU 使用率”“监控”等关键词接口调用方式固定为调用腾讯云监控 API参数从用户对话中抽取实例 ID、时间范围结果处理则是把返回的 JSON 数据整理成易于阅读的指标趋势并给出简单的阈值判断。有了这个 SkillAgent 不需要每次都从零推理“如何查监控”它只需要做两件事判断当前需求是否命中了这个 Skill然后按 Skill 里定义的规则去执行。关键点在于Skill 更像是“约定”而不是“提示”。它不是告诉模型“你可以这样想”而是告诉模型“你必须这么做”。这种确定性带来的好处是同样的输入每次执行的结果都是稳定可控的。1.3 Skill 和普通 Prompt、插件、Workflow 的边界在哪很多人问 Skill、插件Plugin、工作流Workflow到底有什么区别。我自己的理解是这样的Prompt 是给模型的指令它是“软的”模型可以自由解释插件是给 Agent 的工具调用接口它解决的是“能用什么工具”的问题Workflow 是把多个步骤编排成固定流程解决的是“按什么顺序做”的问题Skill 则是在插件之上再加一层“怎么用、什么时候用、结果怎么处理”的经验封装。打个比方。插件相当于给你一把电钻Workflow 是告诉你先量尺寸、再打孔、最后拧螺丝而 Skill 是告诉你“在什么场景下用电钻、遇到墙面太硬要怎么处理、打出来的孔偏差超过多少就该换方案”。Skill 包含了触发判断、执行步骤、异常处理和经验规则它是插件 使用经验 兜底逻辑的组合体。所以在实际架构里Skill 通常会调用一个或多个插件能力但 Skill 本身携带了更多上下文与决策信息。这也是为什么 Skill 能让 Agent 更接近“专家”而不是“工具集合”。2. 腾讯云上搭 Agent 的基础设施选型2.1 服务器配置怎么选才不浪费又不卡先说结论一个面向内部团队测试和中等并发几十个用户同时使用的 Agent 服务2 核 4G 的轻量应用服务器就能跑起来如果还要在里面运行向量库做长期记忆、跑模型网关建议直接上 4 核 8G。我最早用 1 核 2G 试过Agent 本身跑得动但一旦启动 Redis、模型网关和 Agent 主服务三个进程内存直接见底系统开始疯狂交换分区响应延迟飙升到十几秒。如果你计划生产部署我给个参考配置表用途推荐配置说明轻量测试 / Demo2核4GAgent 服务 Redis 可以共存模型调用走云端 API 没问题正式环境 / 对外服务4核8G起步需要跑容器、网关、Redis、日志收集建议再加 50G 以上 SSD 数据盘高并发 / 多租户8核16G或更高考虑多副本部署、负载均衡Redis 独立实例做好容器资源限制腾讯云的服务器地域选哪里也值得说一句。如果用户群主要在国内选离你最近的可用区就好如果你的业务涉及跨境访问就要考虑合规和网络延迟的问题这个按实际业务场景来定我不展开。实际操作时我建议系统盘买大一点。Agent 的依赖镜像特别占空间一个 Python 基础镜像加若干依赖就两三个 G再加上 Docker 镜像、日志文件50G 系统盘很快就紧张了。2.2 容器镜像服务把 Agent 打包推上云的正确姿势我部署 Agent 的方式是全部容器化用腾讯云的容器镜像服务TCR来托管镜像。很多人第一步就卡在“本地构建好镜像但推送不上去”。腾讯云容器镜像服务的推送逻辑是这样的先在控制台创建命名空间和镜像仓库然后用 docker login 登录再把本地镜像 tag 成腾讯云仓库的格式最后 docker push。以腾讯云广州地域的个人版 TCR 为例命令大概是这样的# 登录用户名是你的腾讯云账号 ID密码是控制台临时登录指令生成的密钥 docker login ccr.ccs.tencentyun.com --username your_account_id --password your_temporary_token # 给本地镜像打标签格式ccr.ccs.tencentyun.com/[命名空间]/[仓库名]:[版本] docker tag agent-server:latest ccr.ccs.tencentyun.com/mynamespace/agent-server:latest # 推送 docker push ccr.ccs.tencentyun.com/mynamespace/agent-server:latest这里最容易踩三个坑第一个登录用的密码不是账号密码。个人版 TCR 的登录密码需要在控制台“容器镜像服务 - 个人版 - 实例信息”里生成临时登录指令或者用 API 密钥。直接拿登录密码去 docker login百分之百失败。第二个命名空间必须提前在控制台建好而且命名空间有地域属性。你在控制台建的是广州的命名空间就只能推送到广州的镜像地址。第三个镜像版本管理要养成习惯。每次构建都打上日期或 git commit 号比如 agent-server:20250521-abc1234这样线上出了问题能精确定位到是哪个代码版本。2.3 二级域名和 HTTPS让 Agent 服务有正式入口Agent 服务跑在服务器上总要给用户一个访问入口。用裸 IP 加端口号虽然能访问但特别不方便而且很多现代浏览器对非 HTTPS 的接口权限限制越来越多比如音频、摄像头、部分剪贴板 API。所以给 Agent 配一个二级域名和 HTTPS 证书是必须的。腾讯云上申请二级域名的操作其实很简单就是给主域名添加一条 DNS 解析记录。比如你的主域名是 example.com想让 Agent 服务通过 agent.example.com 访问就在 DNS 解析面板加一条记录主机记录agent 记录类型A 记录值你的服务器公网 IP如果你有多台服务器建议用 CNAME 记录指向负载均衡域名而不是直接写 IP这样以后扩容不用改解析。记录加完之后需要给这个域名申请 SSL 证书。腾讯云有免费的证书额度申请之后下载 Nginx 格式的证书然后在服务器 Nginx 配置里加段server { listen 443 ssl http2; server_name agent.example.com; ssl_certificate /etc/nginx/ssl/agent_example_com.pem; ssl_certificate_key /etc/nginx/ssl/agent_example_com.key; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }有个地方我一开始没注意如果是国内服务器部署对外服务域名需要按相关要求完成合规备案流程。建议在配置解析之前就确认好备案状态否则域名虽然解析通但 80 和 443 端口的访问会被拦截。这个是实际部署中的硬门槛做之前一定要先查清楚自己的域名和服务器是否符合接入要求。2.4 Redis 安装和密码修改一个让我折腾半天的坑Agent 的会话记忆、缓存、临时状态都离不开 Redis。我直接在服务器上用 Docker 跑了一个 Redis 容器本来以为很省事结果在“修改 Redis 密码”这个操作上栽了个大跟头。事情是这样的默认安装的 Redis 没有密码我打算加一个强密码。第一次操作我直接修改了容器里的 redis.conf把 requirepass 加进去然后执行 redis-cli shutdown 再启动容器。结果启动之后连不上了报错信息是 NOAUTH Authentication required 或者连接被拒绝。排查了很久问题出在三个方面这里直接列出来给大家避坑第一用 Docker 启动 Redis 时如果通过命令行指定了 redis-server 启动参数比如常见的 --appendonly yes那么配置文件里的 requirepass 会被命令行参数覆盖或者根本没有被加载。我后来直接用环境变量和命令行参数来管理配置干净的写法是这样docker run -d \ --name redis-agent \ -p 6379:6379 \ -v /data/redis:/data \ redis:7-alpine \ redis-server --requirepass 你的强密码 --appendonly yes第二修改密码之后旧连接不会自动断开导致新请求还会用旧密码去访问。我改了密码后 Redis 进程还活着旧客户端连接仍然有效但新连接全部失败看起来就像“Redis 坏了”其实是需要把客户端连接全部重置。第三如果你用 systemd 管理 Redis 服务而不是容器那么修改配置文件后必须 systemctl daemon-reload 再重启服务。很多人直接改完配置文件重启服务但 systemd 读取的还是旧的 unit 文件改了等于白改。密码这东西也要注意别用纯数字或弱密码。我生成随机强密码时用了一段带特殊字符的字符串结果在连接 URL 里没做转义又把服务搞挂了一次。正确做法是把 Redis 密码单独放环境变量文件里代码里用环境变量拼接连接串避免特殊字符地狱。3. AI Skills 的核心设计思路与最佳实践3.1 一个标准 Skill 应该长什么样我用了很多种 Skill 设计方式之后最终沉淀下来一套相对固定的模板。每个 Skill 包含元信息、触发条件、输入参数、执行逻辑、输出处理和异常兜底六块内容。以“查询腾讯云服务器监控”这个 Skill 为例它的标准结构是skill_name: query_tcloud_monitor description: 查询腾讯云服务器 CPU、内存、磁盘、带宽等监控指标 triggers: - 关键词匹配: [服务器负载, CPU, 内存使用率, 监控] - 语义匹配: 用户想查看某台云服务器当前或历史的资源使用情况 parameters: instance_id: type: string required: true description: 服务器实例 ID格式如 ins-xxxxxxxx extraction: 从对话中抽取抽取不到时向用户询问 start_time: type: datetime required: false default: 最近1小时 description: 监控数据起始时间 metric_names: type: array required: false default: [CPUUsage, MemUsage] description: 需要查询的指标列表 execution: api: TencentCloud.Monitor.GetMonitorData http_method: POST timeout_ms: 5000 retry: 2 output: format: markdown_table include_threshold_alert: true exception_handling: invalid_instance_id: 提示用户实例 ID 不存在并列出当前账号下的实例列表供选择 api_error: 返回错误信息并建议稍后重试 timeout: 提示查询超时引导用户缩小时间范围这个结构的核心好处是模型只需要做“填空”和“选择”不需要做“创造”。参数怎么抽、调哪个接口、出错怎么办在 Skill 定义里全部写清楚了模型根本不需要发挥。3.2 技能拆分“最少够用”原则刚开始设计 Skills 时我犯过一个典型错误把 Skill 拆得太细。比如我拆出了“查 CPU”“查内存”“查磁盘”“查带宽”四个独立 Skill看起来职责单一但运行起来发现 Agent 经常不知道该调哪个而且用户说“服务器有问题”这种模糊话术时模型会同时匹配多个 Skill导致冲突。后来我把同类操作合并成一个 Skill“查服务器各项指标”通过参数 metric_names 来区分具体查什么。合并之后匹配准确率明显提升误调用的情况大幅减少。这就是我想说的“最少够用”原则Skill 的数量不是越多越好而是刚好覆盖用户的高频需求就行。判断标准很简单——如果两个 Skill 的触发条件和参数几乎一样只是返回值不同那就应该合并如果两个 Skill 触发条件差异很大、执行逻辑完全不同再拆开。一般来说一个初版 Agent 有 5 到 8 个 Skill 就足够覆盖大部分场景了。超过 15 个 Skill 之后模型的召回准确率会明显下降因为匹配空间越大迷惑性越强。你要做的是控制 Skill 数量而不是无限制地增加。3.3 参数抽取与错误回退Skill 好不好用很大程度取决于参数抽取做得好不好。设计 Skill 参数时我总结出三条经验第一每个参数都要有明确的抽取来源和兜底策略。比如 instance_id 这种必填参数如果用户没说Agent 应该主动询问而不是猜一个默认值。我见过很多 Agent 在参数不全时硬跑出错用户体验极差。第二参数类型要尽量严格。把所有参数都当字符串处理看似省事但到了 API 调用环节全是坑。比如时间参数用户说“昨天”“凌晨”“这周”如果你不换算成标准时间格式传给云监控 API 直接报错。我现在的做法是在 Skill 定义里写清楚每个参数需要转换成的标准类型以及在对话中如何提取。第三给每个参数设置一个合理的取值范围或校验规则。比如时间范围不能超过 30 天端口号必须在 1 到 65535 之间。参数校验放在 Skill 执行前可以拦截大量无效请求。错误回退也很关键。当 Agent 调用的 API 返回错误时不要直接把错误堆栈抛给用户而是按 Skill 里定义好的异常处理逻辑给出友好提示。例如实例 ID 不对时主动列出用户账号下的所有实例供选择接口超时时建议缩小查询范围重试。这些回退逻辑能极大提升 Agent 的“靠谱感”。3.4 技能的注册与召回Skill 在系统里通常通过两种方式被 Agent“看到”一种是在每次对话时把所有 Skill 的描述塞给模型让模型自己选择另一种是把 Skill 的描述做成向量索引通过检索召回相关技能。前者的缺点是Skill 一多上下文窗口消耗太大而且模型容易受到无关 Skill 干扰。后者的优点是扩展性好但需要一套检索系统。我实际用的方案是两者结合核心高频 Skill 常驻在系统 Prompt 里长尾 Skill 做成向量检索。每次用户输入进来先做语义检索把相关 Skill 找出来再连同常驻 Skill 一起拼接成当前会话可用的技能列表。这样做的原因很直接核心 Skill 随时能调召回速度快不会因为检索问题导致“明明有技能却没用上”长尾 Skill 靠向量召回数量再多也不占上下文窗口。如果你已经用了腾讯云的向量数据库产品可以直接把 Skill 描述向量化放进去没有的话用 Redis 配 embedding 也能实现轻量版。4. 完整实操在腾讯云上部署带 Skills 的 Agent4.1 实操前需要准备的东西动手之前先列一个清单避免我在部署时那种“发现少了这个又少了那个”的尴尬一台腾讯云服务器我用的 4 核 8G系统 Ubuntu 22.04开放 80、443、22 端口一个已备案的域名DNS 解析面板可以操作腾讯云容器镜像服务已开通建好命名空间一个模型 API Key我这次主要用的 DeepSeek 和腾讯混元通过 LiteLLM 网关统一接入Docker 和 Docker Compose 已安装在服务器上Redis 镜像已拉取到本地建议提前把域名解析加了因为 DNS 解析生效需要时间。我因为等解析浪费了将近二十分钟本来可以并行做的事情排成了串行。4.2 服务编排主服务、模型网关、Redis 一次拉起我习惯用 Docker Compose 管理整套服务把 Agent 主服务、LiteLLM 网关、Redis 三个服务编排在一起。Compose 文件核心部分是这样写的services: agent-server: image: ccr.ccs.tencentyun.com/mynamespace/agent-server:20250521 ports: - 8000:8000 environment: - REDIS_URLredis://:${REDIS_PASSWORD}redis-agent:6379/0 - LLM_GATEWAY_URLhttp://litellm-gateway:4000 depends_on: - redis-agent - litellm-gateway litellm-gateway: image: ghcr.io/berriai/litellm:main-latest ports: - 4000:4000 volumes: - ./litellm_config.yaml:/app/config.yaml command: [--config, /app/config.yaml, --port, 4000] environment: - LITELLM_MASTER_KEY${LITELLM_MASTER_KEY} - DEEPSEEK_API_KEY${DEEPSEEK_API_KEY} redis-agent: image: redis:7-alpine command: [redis-server, --requirepass, ${REDIS_PASSWORD}, --appendonly, yes] volumes: - redis_data:/data这套编排的好处是服务之间通过 Docker 内部网络通信不需要对外暴露 Redis 端口Redis 密码和模型密钥都通过环境变量注入不会明文写进代码库。LiteLLM 网关统一管理模型调用Agent 主服务访问模型只需要记一个地址切换模型厂商时不用改业务代码。LiteLLM 的配置文件也很简单把要用的模型供应商和模型名注册进去就行model_list: - model_name: deepseek-chat litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY - model_name: hunyuan-pro litellm_params: model: tencent/hunyuan-pro api_key: os.environ/HUNYUAN_API_KEY用网关还有两个隐藏收益一是可以在网关层做统一的重试、超时和限流单模型 API 抖动时不会把 Agent 主流程打崩二是可以通过网关的日志功能记录每一次模型调用的 token 消耗月底算成本一目了然。4.3 从本地 Docker 构建到服务器拉取部署本地的镜像构建好推送之后在服务器上要把整套服务拉起来。服务器本身不需要装代码仓库只需要从腾讯云镜像仓库拉取镜像。顺序是这样的# 1. 在服务器上登录腾讯云镜像仓库 docker login ccr.ccs.tencentyun.com --username your_account_id --password your_temporary_token # 2. 拉取镜像 docker pull ccr.ccs.tencentyun.com/mynamespace/agent-server:20250521 # 3. 准备 Compose 文件和环境变量文件 vim docker-compose.yml vim .env # 写入 REDIS_PASSWORD、LITELLM_MASTER_KEY、DEEPSEEK_API_KEY 等 # 4. 启动服务 docker compose up -d启动之后用 docker compose ps 看三个服务的状态。我建议等十几秒再访问接口因为 Agent 主服务启动时要加载技能定义、初始化 Redis 连接LiteLLM 网关也要做健康检查。第一次访问 http://agent.example.com 时如果页面打不开或者返回 502先别慌按顺序检查Nginx 配置里 proxy_pass 指向的后端端口是否对上防火墙是否放行了 80 和 443证书是否绑定正确。我遇到过的 502 大多数是 Nginx 配置里端口写错或者主服务还没完全启动起来导致的。4.4 验证 Skill 是否真正生效服务跑起来后最关键的验证是测试 Skill 会不会被正确触发。我有一个固定的测试集快速提问“我的服务器 CPU 负载高不高”——期望 Agent 匹配到查询监控的 Skill并返回当前 CPU 使用率以及是否有异常提示。对比测试先直接问“你好”再问“帮我看看现在系统状态怎么样”——前者应该走普通对话不应该误触发监控 Skill后者才应该触发。模糊测试只说“我感觉服务有点慢”——这种情况下模型可能不会触发任何 Skill而是反问用户是否需要检查服务器资源。这也是合理的因为触发条件没有完全命中。测试中如果发现 Skill 没有被正确触发通常是三个原因技能描述写得太泛和多个 Skill 描述重叠触发关键词没覆盖常见说法向量检索的阈值设得太高召回不到。定位时可以先在日志里看模型最终收到的技能列表如果列表里就没有这个技能那么要么是召回问题要么是描述重叠问题如果列表里有了但模型还是没用那就可能是上下文里技能描述不清楚需要调整描述措辞。5. 常见问题排查与避坑速查5.1 Redis 修改密码后重启失败完整排查思路这是我这次部署里最典型的“看起来简单但搞了很久”的问题专门拿出来详细说。现象是修改 redis.conf 添加 requirepass 后重启 Redis服务要么起不来要么起来了连不上。第一步先确认 Redis 到底起来没有。执行 docker ps 看容器状态如果容器反复重启用 docker logs redis-agent 看日志。日志里如果出现# Warning: config file ... cant be parsed或者Bad directive or wrong number of arguments说明配置语法有错误重点检查 requirepass 这一行有没有多余空格、是否写在了错误的配置段下。第二步如果你用的是 Docker 启动且同时给了命令行参数要明白命令行参数的优先级。我之前遇到过配置文件里写了 requirepass但 docker run 命令里又追加了 redis-server --appendonly yes导致部分配置被覆盖。最保险的做法是全部配置都用命令行参数或者全部用配置文件不要混用。第三步如果 Redis 起来了但客户端报 NOAUTH检查你的客户端连接串是否正确。连接 URL 里密码包含特殊字符时必须 URL 编码。比如密码是Abc123在 URL 里要写成Abc%40123。我用 Python 的 redis 库时习惯用 redis.Redis(host..., password..., port6379) 显式传 password绕开 URL 编码问题。第四步别忘了一个隐藏问题修改密码后Redis 的主从复制如果配置了老密码从节点会一直认证失败。如果你有从库必须同步修改所有节点的密码配置否则数据同步会中断。5.2 Docker 推送到腾讯云镜像仓库失败推送失败的常见情况分两种登录失败和上传超时。登录失败先确认账号和密码来源。腾讯云 TCR 的登录账号通常是账号 ID 而不是自定义用户名密码是临时登录指令或 API 密钥。去控制台重新生成一次临时登录指令复制时注意不要把换行符带进去。上传超时多半是镜像太大或网络不稳定。解决方案有两个如果是单个镜像太大检查 .dockerignore把本地缓存、模型文件、测试数据都排除掉如果是网络问题可以在 docker 配置里设置适合国内环境的镜像加速地址腾讯云控制台有官方加速器配置照着设置就行。另外镜像分层也很重要。每次构建时把不变的依赖层写在前面、频繁改动的代码层写在后面这样推送增量时速度会快很多。我自己重建镜像时依赖层只要不变推送基本在几十秒内完成。5.3 模型调用超时与网关返回 429Agent 上线后最常遇到的线上问题就是模型调用变慢、报 429。原因通常有两类一类是单一模型服务商限流另一类是网关层没有做重试与排队。用 LiteLLM 网关之后可以在配置里开启重试与限流参数。通用建议是单次请求超时设置为 30 到 60 秒重试最多 1 到 2 次重试间隔用指数退避。如果 Agent 是面向多用户服务的建议再加上 per-user 级别的限流避免某个用户刷接口把额度吃光。我还习惯给不同优先级的请求设置不同的模型路由。比如实时对话走快速模型离线分析走强模型。这种策略在网关配置里实现非常容易只需要在 model_list 里增加一个模型别名并指向不同后端的模型即可。5.4 Skill 不生效从日志定位召回和选择问题Skill 已经注册到系统里但模型就是“视而不见”这种情况我遇到过好几次。定位路径是这样的打开 Agent 主服务的日志查看每次请求时系统最终发送给模型的技能列表。如果技能列表里没有目标 Skill说明召回失败。检查 Skill 描述是否太具体、用户提问用词和描述差异太大或者向量检索阈值太高。解决方法可以是增加同义词触发词或者把 Skill 描述改写得更通用。如果技能列表里有但模型没调用说明模型“判断不需要”。这种情况要么是 Skill 描述和用户意图匹配度不够要么是技能描述太长被模型忽略了。试着把 Skill 描述精炼到 50 字以内把最重要的触发条件放在最前面。还有一种情况是并发冲突两个 Skill 同时被召回模型犹豫再三选了一个不合适的。这种情况可以在 Skill 定义里加互斥逻辑描述里明确写“当用户询问 X 时请勿使用本技能”。虽然略带粗暴但实测有效。5.5 一套每天都要做的“健康自检”Agent 这类系统最怕的不是出了大故障而是小问题积累成大坑。我给自己定了一个每日检查清单内容不多但很管用用三到五条标准测试用例跑一遍核心 Skill确认召回和执行都正常检查 Redis 内存使用量确认 key 没有无限增长我会给会话键设置过期时间看一眼模型网关日志统计请求成功率并且在低于 95% 时排查原因检查服务器磁盘占用清理旧的 Docker 镜像和容器日志确认 SSL 证书剩余有效期提前一个月更换这套检查做完大约十分钟但能避免大多数“突然线上挂了”的窘境。我在这次部署中最深的感受是Agent 本身的技术框架已经不是稀缺资源真正拉开差距的是 Skill 的设计质量和基础设施的稳定程度。Skill 设计得好不好直接决定 Agent 是“看起来很聪明”还是“真的能干活”基础设施稳固不稳固决定这个 Agent 能走多远。别急着加各种炫酷技能先把核心场景打磨透再逐步扩展这才是做全能 Agent 的稳妥路径。