带过第一版Agent之后我发现一个很残酷的事实代码写得再漂亮跑不起来等于零跑起来了换一个场景就崩等于白干。真正拉开差距的不是模型选得多大、Prompt写得多么花哨而是你愿不愿意沉下心把一个个技能梳理成可复用、可编排、可观测的能力块。这篇文章是我在腾讯云上把一个Agent从能聊天养成能干活的完整记录涉及AI Skills的拆解方式、云资源准备、模型网关接入、记忆层落地以及一堆我实际踩过、也帮身边朋友填过的坑希望对正在做Agent落地的你有参考价值。1. Skill 与 Agent 的边界先想清楚全能是怎么来的很多人一上来就追求全能 Agent恨不得一个系统把所有事都干了。我的观点可能不太一样Agent 本身不该是万能工具箱它更应该像一个聪明的调度员——真正干活的是它手里那一堆 Skill。理解这两者的区别是后面所有设计的前提。1.1 skill 和 agent 到底差在哪我见过不少团队把 Skill 写成 Agent 内部的一大段Prompt或者反过来把 Agent 的对话逻辑硬塞进 Skill 里最后代码边界糊成一团。按我的理解它们的分工其实很清楚Agent 负责思考理解用户意图、拆解目标、决定下一步调用哪个 Skill、观察结果并决定是否继续。Skill 负责执行一个 Skill 对应一类具体能力输入输出定义明确内部可以调用工具函数、外部API、甚至其他模型请求。用一个生活化的类比Agent 是餐厅里的经理Skill 是后厨里一个个灶台。经理不会自己颠勺但他知道客人点了什么菜、应该交给哪个灶台、出菜时间大概多久。灶台也不需要关心客人为什么点这道菜它只负责把菜做好。把点菜逻辑塞进灶台或者让经理亲自炒菜都会出问题。1.2 为什么腾讯云上的 Skill 实践值得单独讲腾讯云在这套体系里提供的不是某个单独的 Skill而是一整套能让 Agent 跑起来的云底座计算资源、容器镜像服务、对象存储、数据库缓存、以及模型服务的接入通道。这些恰好是一个 Agent 从开发到上线最容易被忽视的隐性成本。我在本地把 Agent 跑通只花了半天但真正让它稳定地在云上服务反而花了两天。一部分时间耗在环境差异上更多时间耗在技能依赖的外部资源上。Skill 一旦涉及文件处理、数据存储、模型调用就必须依赖云端的稳定环境。腾讯云的好处在于这些资源都能在同一个控制台里管理权限、密钥、网络策略能统一收口省掉了跨平台来回切来切去的麻烦。所以这篇内容我不会只停留在Skill 怎么写的层面还会把服务器准备、容器镜像推送、模型网关配置、Redis 记忆层这些都串起来讲。毕竟一个全能 Agent之所以全能是因为它背后有一整套能支撑它工作的基础设施。2. 腾讯云服务器与镜像服务的准备先把房子盖好在写任何 Skill 代码之前我建议先把云上环境准备好。这一步看似简单但很多人恰恰是在这里浪费了大量时间。我按自己的操作顺序整理出来你跟着走基本不会出大问题。2.1 服务器选型与系统初始化Agent 服务的压力一般不大除非你要在本地跑大模型否则不需要顶配机器。我用的是一台 2核4G 的云服务器带宽按量付费日常跑一个 Agent 服务加 Redis 完全够用。系统我选了 Ubuntu 22.04原因很实际Docker 支持最好、Python 环境干净、遇到问题能在网上找到大量现成方案。初始化阶段我做了三件事# 更新系统 sudo apt update sudo apt upgrade -y # 安装基础工具 sudo apt install -y git curl vim ufw # 配置防火墙只放开必要端口 sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable把防火墙开好很重要。很多 Agent 服务被人扫到漏洞不是代码问题而是端口裸奔。我习惯只开 SSH、HTTP、HTTPS其他端口一律不放行应用层服务通过反向代理暴露。2.2 Docker 推送镜像到腾讯云容器镜像服务的完整流程Agent 服务我用 Docker 打包部署镜像托管在腾讯云的容器镜像服务里。第一次操作的时候我遇到一个不算坑但很烦的问题本地打好镜像之后推送命令总是失败。后来才意识到登录凭证和镜像仓库的完整地址必须严格匹配。步骤其实很简单在容器镜像服务控制台创建命名空间和镜像仓库记住仓库地址比如ccr.ccs.tencentcloud.com/my-namespace/my-agent。本地用 Docker 登录docker login ccr.ccs.tencentcloud.com --username 你的账号ID这里注意登录用户名不是你的微信昵称而是腾讯云的账号 ID一般是一串数字。密码也不是登录密码而是你在控制台里专门为容器镜像服务设置的访问凭证。给本地镜像打标签并推送docker tag my-agent:latest ccr.ccs.tencentcloud.com/my-namespace/my-agent:latest docker push ccr.ccs.tencentcloud.com/my-namespace/my-agent:latest在服务器上拉取镜像并运行docker pull ccr.ccs.tencentcloud.com/my-namespace/my-agent:latest docker run -d --name my-agent -p 8080:8000 --env-file .env ccr.ccs.tencentcloud.com/my-namespace/my-agent:latest把配置放在.env文件里传进去而不是烧进镜像这样换环境部署时就不用重新打镜像。这个习惯我在早期没养成每次改个密钥都要重建镜像既慢又容易把敏感信息泄露在镜像历史里。2.3 二级域名申请与 HTTPS 配置Agent 服务对外提供 API 时直接用 IP 加端口不仅难看还容易被各种扫描器盯上。我在腾讯云上给服务配了一个二级域名流程非常简单在域名解析控制台添加一条 A 记录将二级域名解析到服务器 IP。这一步做完之后强烈建议配 HTTPS。原因不只是现在的网站都要 HTTPS而是 Agent 服务通常会携带 API 密钥、用户数据明文传输的风险太高。我用 Caddy 做反向代理配置很简单agent.example.com { reverse_proxy localhost:8080 }Caddy 会自动申请和续期证书省去了手动处理证书的麻烦。我第一次用时很惊讶原来 HTTPS 可以这么省心。之后就再也没手动改过 Nginx 证书配置。3. 技能树设计把全能 Agent 拆成可以维护的 Skill环境准备好之后最核心的工作来了设计你的 Agent 到底拥有哪些技能。这一步直接决定了后期维护成本和用户体验。我的建议是不要一开始就追求大而全而是先搭一个能覆盖核心场景的技能骨架然后逐步丰富。3.1 技能树的结构设计我把技能按领域分组每组对应一个目录每个技能独立成文件夹。整体结构大概是这样的skills/ ├── system/ │ ├── server_status/ # 服务器状态查询 │ ├── log_analysis/ # 日志分析 │ └── process_manage/ # 进程管理 ├── data/ │ ├── csv_processor/ # CSV 文件处理 │ ├── redis_helper/ # Redis 操作封装 │ └── http_request/ # HTTP 请求工具 ├── ai/ │ ├── deepseek_chat/ # 接入 DeepSeek 对话 │ ├── text_summary/ # 长文本总结 │ └── embedding_search/ # 向量检索 └── productivity/ ├── timer_reminder/ # 定时提醒 ├── weather_query/ # 天气查询 └── meeting_notes/ # 会议纪要整理每个技能文件夹里至少包含三个文件一个描述文件说明这个技能是干什么的、什么时候该用它、一个输入输出定义文件、一个具体的实现代码文件。这样的好处是Agent 的调度逻辑可以完全基于描述文件不需要硬编码每种技能的处理方式。3.2 Skill 描述文件怎么写才有用Skill 描述文件是最容易被低估的部分。很多人把它当成给开发者看的注释写得又长又模糊。实际上Agent 的调度核心就是靠这段描述来决定这个技能适不适合当前任务。我推荐用结构化的格式清晰地表达出以下几个要素。下面是我常用的一个技能描述模板name: server_status description: 查询云服务器当前 CPU、内存、磁盘使用情况。当用户询问服务器负载、资源占用、是否卡顿时使用。适合系统异常排查场景。 version: 1.0.0 author: your-name params: type: object properties: duration: type: string description: 统计时长可选 5m/1h/24h默认 5m required: []描述部分我特意写了当用户询问...时使用这比单纯的查询服务器状态效果好得多因为 Agent 需要的是触发条件不是功能罗列。我自己测试下来描述越具体调度准确率越高。3.3 为什么技能要小而专而不是大而全这是我踩过最大的坑。早期我图省事把一个数据分析的技能写了 800 行既能处理 CSV、又能画图表、还能跑 SQL 查询。表面上看功能强大实际用起来问题很大参数定义越来越复杂Agent 经常传错参数。调试困难一个功能出问题整个技能都无法使用。难以扩展想加新功能必须小心翼翼怕破坏已有逻辑。后来我把这个超级技能拆成了几个小技能CSV 处理、图表生成、SQL 查询。单个技能代码量降下来了但整体表现反而提升了一大截。这就像工具箱里不能只有一把瑞士军刀而是要有扳手、螺丝刀、钳子各司其职。4. 核心 Skill 实战写一个真正能用的技能空谈设计原则没有意义我拿一个实战技能来完整演示实现一个服务器状态查询技能。这个技能虽然简单但涉及了参数解析、Shell 命令执行、结果格式化、异常处理等完整环节可以作为你开发其他技能的模板。4.1 环境准备与依赖在服务器上我需要先确认系统监控工具已经安装sudo apt install -y sysstat这个工具提供mpstat、iostat等命令可以拿到 CPU 和磁盘的详细信息。没有它很多监控数据拿不到。4.2 技能核心实现创建一个skills/system/server_status/main.py文件#!/usr/bin/env python3 服务器状态查询技能实现 import argparse import json import subprocess def run_cmd(cmd): 安全执行Shell命令并返回输出 try: result subprocess.run( cmd, shellTrue, capture_outputTrue, textTrue, timeout30 ) return result.stdout.strip() except subprocess.TimeoutExpired: return 命令执行超时 except Exception as e: return f命令执行出错: {str(e)} def get_cpu_usage(duration5m): 获取CPU使用率 if not (duration.endswith(m) or duration.endswith(h)): duration 5m cmd fmpstat 1 1 output run_cmd(cmd) # 从mpstat输出中解析idle值 lines output.splitlines() for line in lines: if %idle in line or 平均时间 in line: continue parts line.split() if len(parts) 12 and parts[-1].replace(., ).isdigit(): idle float(parts[-1]) return round(100 - idle, 2) return None def get_memory_usage(): 获取内存使用情况 output run_cmd(free -m) lines output.splitlines() # 解析Mem行 for line in lines: if line.startswith(Mem:): parts line.split() total int(parts[1]) used int(parts[2]) return {total_mb: total, used_mb: used, usage_percent: round(used / total * 100, 2)} return None def get_disk_usage(): 获取磁盘使用情况 output run_cmd(df -h /) lines output.splitlines() if len(lines) 2: parts lines[1].split() return { mount_point: parts[5] if len(parts) 5 else /, total: parts[1], used: parts[2], usage_percent: parts[4], } return None def main(): parser argparse.ArgumentParser(description服务器状态查询) parser.add_argument(--duration, default5m, help统计时长 5m/1h/24h) args parser.parse_args() result { cpu_usage_percent: get_cpu_usage(args.duration), memory: get_memory_usage(), disk: get_disk_usage(), duration: args.duration, } print(json.dumps(result, ensure_asciiFalse, indent2)) if __name__ __main__: main()这段代码的逻辑很直接调用系统命令采集数据解析关键信息最后输出为 JSON。Agent 拿到 JSON 后将其转换成自然语言回答给用户。4.3 异常处理与边界情况我特意在run_cmd函数里处理了超时和异常这一点非常重要。你永远不知道 Agent 会在什么时候、以什么参数调用技能。如果技能本身没有充分的异常处理一次偶发的超时足以让整个 Agent 会话中断而且问题还很难复现。还有一个细节参数校验。duration参数我只接受以m或h结尾的值其他一律回退到默认值防止 Agent 传入奇怪参数导致 Shell 命令拼接出安全隐患。虽然我用了shellTrue但在这个场景下参数是有限枚举风险可控如果你要传更复杂的参数强烈建议改用shlex.quote或直接使用列表形式的命令避免命令注入。4.4 测试技能在本地先用几个边界情况测一下# 正常查询 python3 main.py --duration 5m # 不传参数测试默认值 python3 main.py # 传非法参数测试回退逻辑 python3 main.py --duration abc输出符合预期后再把技能挂到 Agent 上做联调。我建议每一个技能都写一个简单的测试脚本这样后续改动时能快速回归不用每次手工验证。5. 模型接入与 Agent 编排LiteLLM Proxy、Redis 与多模型切换技能有了下一步就要解决Agent 的大脑问题。这里涉及两件事模型怎么接入、记忆怎么存。如果你只接一个固定模型场景又很简单那么直接调用模型 API 就够了但如果你想给 Agent 换模型、做限流、统一日志我建议上一套 LiteLLM Proxy。5.1 为什么我选择 LiteLLM Proxy 作为模型网关市面上有很多模型网关工具我选择 LiteLLM Proxy 不是因为它功能最全而是因为它足够轻、社区活跃、兼容 OpenAI 格式。这意味着你在 Agent 代码里只需要面对一个统一的 OpenAI 兼容接口后面换模型时完全不用改业务代码。它的部署方式也简单Docker 一行命令就能跑起来docker run -d \ --name litellm-proxy \ -p 4000:4000 \ -v $(pwd)/litellm_config.yaml:/app/config.yaml \ ghcr.io/berriai/litellm:main-latest \ --config /app/config.yaml配置文件里可以声明多个模型后端model_list: - model_name: deepseek-chat litellm_params: model: deepseek/deepseek-chat api_key: ${DEEPSEEK_API_KEY} - model_name: deepseek-reasoner litellm_params: model: deepseek/deepseek-reasoner api_key: ${DEEPSEEK_API_KEY} - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: ${OPENAI_API_KEY}这样做的好处是Agent 代码里只认deepseek-chat、deepseek-reasoner这样的别名至于背后调的是哪个厂商、哪个版本完全由配置文件决定。某天模型服务升级或切换供应商只改配置就行业务代码一行不动。5.2 Agent 框架与技能编排的落地打法有了模型网关和技能集合之后Agent 的编排逻辑就是整个系统里最核心的部分了。我把编排理解为三层第一层是意图识别。用户的输入进来后让模型判断用户到底想干什么。这一步的输出是结构化的包括意图类型和关键参数。比如用户说帮我看看服务器现在卡不卡意图就是server_status参数是默认值。第二层是技能调度。根据意图匹配到具体的 Skill。我的做法是让模型自己选择我会把所有 Skill 的描述文件内容都给它让它根据描述去匹配。实测下来效果不错尤其是技能数量多了之后模型比人更容易记住每个技能的存在。第三层是结果整合。技能返回的 JSON 需要转成自然语言但这不是简单地把 JSON 翻译成中文而是要结合上下文。用户问的是服务器卡不卡所以回答时要强调 CPU 使用率、内存是否饱和而不是把磁盘闪存信息也一股脑丢出来。我用一个简单的 Python 伪代码来说明这个过程from openai import OpenAI client OpenAI(base_urlhttp://localhost:4000, api_keydummy) def run_agent(user_input, available_skills): # 第一步让模型解析意图并选择技能 planning_prompt f 用户输入: {user_input} 可用技能: {available_skills} 请选择要调用的技能并给出参数。以JSON格式输出。 plan client.chat.completions.create( modeldeepseek-reasoner, messages[{role: user, content: planning_prompt}], ).choices[0].message.content # 第二步解析并执行技能 import json plan_json json.loads(plan) skill_name plan_json[skill] params plan_json.get(params, {}) # 调用对应的技能函数 result execute_skill(skill_name, params) # 第三步将结果整理成自然语言回答 response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是服务器运维助手请用简洁的语言回答用户问题。}, {role: user, content: f用户问: {user_input}\n技能返回: {result}}, ], ) return response.choices[0].message.content值得注意的是意图解析和结果整理我用了不同的模型deepseek-reasoner更擅长复杂推理适合规划deepseek-chat更便宜更快适合生成回答。这种大小模型协作的思路算是低成本提升 Agent 体验的实用技巧。5.3 Redis 密码修改与重启问题的排查记录Agent 的记忆层我选了 Redis主要用来存会话历史、短期记忆和缓存。这里有一个很多人都会踩的坑我必须拿出来说修改 Redis 密码后重启服务一直连不上。现象是这样的我按照文档在redis.conf里改了requirepass然后执行sudo systemctl restart redis再用客户端连接结果报NOAUTH Authentication required。我确认密码没输错重启也没报错就是连不上。排查过程是这样的先确认 Redis 是否真的在运行sudo systemctl status redis——发现服务状态是 active说明进程没问题。测试本地连接redis-cli ping——结果返回NOAUTH说明密码已经生效。用密码登录试试redis-cli -a 新密码 ping——结果还是NOAUTH。到这一步我基本排除了配置问题怀疑是 Redis 加载了多个配置文件。排查发现系统里同时存在两个配置/etc/redis/redis.conf和/etc/redis/redis.conf.d/目录下的一些片段。而我改的是主配置但某些配置片段里又设置了requirepass导致新密码被后面的配置覆盖了。解决办法是检查所有相关的配置文件统一密码设置。如果你也在类似场景下遇到这个问题可以试试grep -r requirepass /etc/redis/把输出结果仔细看一遍确保只有一处设置了密码而且是你想要的那个。这个问题不算复杂但排查思路很典型服务正常不代表配置正确可能只是你没找到真正生效的配置文件。遇到疑难问题先全局搜索关键词、再看进程实际加载了哪些文件这个顺序能省下很多时间。5.4 记忆层设计的几个要点把 Redis 作为 Agent 记忆层时我建议认真思考以下几个要点短期会话记忆以会话 ID 为 key存最近几十轮对话内容避免上下文超出模型窗口。长期事实记忆用户的一些关键偏好、常用配置单独存为结构化记录不要混在会话历史里。缓存策略高频的查询结果如服务器状态、天气可以设置过期时间不必每次都重新计算。记忆清洗定期清理过期 key防止 Redis 内存膨胀导致性能下降。我用 Redis 的 Hash 结构存用户偏好用 List 结构存会话历史再用定时任务清理过期数据。这套方案在数据量不大的场景下非常稳定完全没必要一上来就上专门的向量数据库。6. 本地调试与云端部署把能用变成稳定在本地把 Agent 跑通只是个开始上云之后才是真正的考验。这个阶段我总结了几个关键点涵盖了从本地到云端、从测试到上线的完整链路能让你少走很多弯路。6.1 本地调试的三个层次我习惯把调试分成三个层次一层一层来每层都有不同的重点。第一层是技能单测。不上 Agent直接执行技能脚本验证输出是否符合预期。这个阶段最好写自动化测试因为技能多了之后手动回归的效率太低。第二层是 Agent 编排测试。把几个技能挂到 Agent 上用真实的用户语句去触发。我会准备一组刁钻输入比如服务器好像有点慢帮我看看是不是内存不够了这种句子没有直接出现技能名需要模型测试理解能力。第三层是端到端压测。模拟多个用户同时使用 Agent看服务会不会崩溃、响应会不会变得不可接受。这一步我用的工具很简单就是 Apache Bench 或者 Python 脚本发并发请求。你不需要上重型压测平台先把最基础的并发问题暴露出来就够了。6.2 云端部署后的第一件事看日志部署到腾讯云之后第一件事不是测试功能而是配置日志。我见过太多人上了云才发现没有日志可看出了问题完全懵。我的做法是Docker 容器统一把日志打到标准输出然后用 Docker 自带的日志驱动收集。查询时直接docker logs -f --tail 200 my-agent如果日志量比较大建议加--log-opt max-size10m --log-opt max-file3限制日志文件的大小和数量防止日志占满磁盘——这个坑在云服务器上比想象中更常见。6.3 上线后的稳定性保障部署完成之后有两件事我雷打不动第一件事保活。Docker 的restart策略必须设置为always或unless-stopped这样服务挂了会自动拉起。我见过不少人的服务因为 OOM 被系统杀掉然后一直没人发现直到用户报障。第二件事监控。不用上特别复杂的监控系统但至少要解决一个问题服务不可用的时候你自己能第一时间知道。我用的方案很简单Cron 定时任务每分钟访问一次健康检查接口如果连续几次失败就通过通知渠道发消息到手机上。这样不用时刻盯着控制台服务出问题能被动感知。6.4 面对奇怪问题的排查思路前面提到 Redis 配置文件那个坑其实代表了一种典型的排查思路先确认进程状态再确认实际生效的配置最后才怀疑代码。这个思路可以推广到很多场景。举一个更常见的例子镜像推送到腾讯云后在服务器上拉取总是超时。很多人第一反应是网络问题但我排查后发现其实是本地镜像标签写错了推到了不存在的仓库路径而 Docker 客户端没有立即报错。我建议遇到这类莫名其妙的问题时先冷静下来把操作链条一步步拆开逐层确认确认你在哪台机器上执行命令。确认你引用的镜像地址是否和推送地址完全一致。确认登录凭证对应的权限是否包含该镜像仓库。确认目标机器的 DNS 和网络是否正常。大多数问题都逃不过这四步。先别急着重装、重启、换方案把链路捋一遍往往比盲目尝试要快得多。7. 进阶玩法从单 Agent 到多 Agent 协作与成本控制当你的 Agent 技能越来越丰富你可能会开始遇到新的瓶颈单 Agent 承担太多职能上下文容易被占满、决策链路过长、单个技能卡住影响整体响应。这个阶段有几个进阶思路可以考虑。7.1 多 Agent 分工管家的管家我的做法是把大的 Agent 拆成几个专职 Agent再有一个主 Agent 负责调度。比如一个主 Agent 面对用户内部有运维 Agent、数据分析 Agent、日程管理 Agent。用户说了一句话后主 Agent 判断该转交给谁子 Agent 处理完毕把结果传回来。这样做的好处是上下文隔离。不同领域的对话历史不会互相污染长度可控。故障隔离。某个子 Agent 调用外部服务超时不会拖垮整个对话。权限控制。运维相关的操作只能通过运维 Agent 执行安全边界更清晰。代价是要多花一些转发、编排的时间还会消耗额外的模型 token因为它相当于多了一次模型调用。7.2 成本控制让每一分钱都花在刀刃上模型 API 的成本是 Agent 上线的长期支出我总结了几条控制成本的经验意图识别用小模型。很多情况下不需要gpt-4o或最强的推理模型来做意图判断用便宜快速的模型足够。长文本总结用分段再合并。一次把几万字喂给模型很贵先分段总结、再合并总结效果不一定差成本却能降不少。缓存高频结果。用户反复问同一个问题很常见设置合理过期时间的缓存能显著减少重复调用。设置调用限额。在 LiteLLM Proxy 里做预算控制避免某次异常循环导致账单失控。7.3 安全与权限Agent 越强约束越要明确最后想聊一个容易被忽略的话题安全。Agent 的技能越强大潜在风险就越高。尤其是那些能执行 Shell 命令、能操作数据库、能发外部请求的技能一旦被恶意利用后果会非常严重。我给自己定了几条铁律技能默认拒绝所有非白名单操作。执行命令的技能只允许调用预先定义好的命令模板禁止自由拼接。所有外部请求经过统一出口便于审计。敏感信息密钥、令牌不随对话上下文传递给模型。每个关键技能操作都记录审计日志至少保留一段时间。这些安全约束可能会让 Agent 看起来笨一点——有些操作不能做、要反复确认——但长远来看这是值得的。一个稳定的、可控的 Agent比一个什么都敢干但随时可能失控的 Agent更有价值得多。8. 最后分享几个让我受益的习惯文章写到这儿核心内容基本都覆盖了。最后我想分享几个实际操作中沉淀下来的习惯不系统、不全面但确实让我在后续迭代中少吃了很多苦头。第一个习惯是给技能写版本号。任何 Skill 升级后接口、描述、行为都可能变化Agent 的调度逻辑和用户预期都要跟着调整。有了版本号至少能知道线上跑的是哪一版排查问题时不会陷入代码改了但没生效的困惑。第二个习惯是每个技能都准备一个离线模式。断网、模型服务不可用时技能至少要能返回一个明确的错误信息而不是无限等待。这个在部分远程调试场景下尤其好用能让我快速定位是模型问题还是执行链路问题。第三个习惯是定期回顾技能调用日志。我会看看哪些技能用得多、哪些技能从来没有被触发过。用得多说明价值高值得继续优化从不被触发的技能要么是描述写得不到位要么是根本没必要存在。隔一段时间做一次技能瘦身对保持 Agent 的响应速度和调度准确率都有好处。将一个 Agent 从会聊天养到能干活再从能干活养到稳定可靠这个过程没有捷径只有持续打磨技能设计、调优云上资源、完善安全边界。希望这篇记录能让你少走一些我走过的弯路。