1. 從“會聊天”到“會干活”為什么你需要一套完整的 AI Skills先聊個(gè)我自己的體會。去年我搗鼓過不少 Agent 項(xiàng)目最開始是那種“套殼對話機(jī)器人”——把大模型接上微信或者網(wǎng)頁用戶問一句它答一句。做得多了就發(fā)現(xiàn)這種 Agent 本質(zhì)上是個(gè)“嘴強(qiáng)王者”你說“幫我查一下服務(wù)器負(fù)載”它能給你寫出一篇關(guān)于如何查負(fù)載的教程但就是不會真的去執(zhí)行uptime命令。問題出在哪缺的不是模型能力而是“把想法變成動作”的那一層膠水——AI Skills。標(biāo)題里寫的“全能 Agent 養(yǎng)成記”說的正是這一層。所謂全能不是模型啥都懂而是 Agent 能把一個(gè)復(fù)雜目標(biāo)拆成小步驟每個(gè)步驟調(diào)用一個(gè)或多個(gè) Skill技能每個(gè) Skill 背后是真實(shí)可執(zhí)行的動作查數(shù)據(jù)庫、調(diào) API、寫文件、發(fā)通知、操作瀏覽器甚至拉起一個(gè)云函數(shù)去跑批處理。而騰訊云這套 AI Skills 體系給開發(fā)者提供了一條相對成熟的路不用從零造輪子直接在云上把 Skill 注冊、編排、執(zhí)行、審計(jì)這一整套鏈路跑通。這篇文章我打算用一整個(gè)項(xiàng)目的視角把我自己從零到一搭建 Agent AI Skills 的過程、踩過的坑、優(yōu)化過的細(xì)節(jié)全部攤開寫。適合誰看正在做 Agent 開發(fā)、想接真實(shí)工具調(diào)用但還沒找到合適范式的朋友已經(jīng)在用騰訊云、但對“AI 應(yīng)用到底怎么落地”還模糊的朋友以及那些被各種 Agent 框架繞暈、想要一張清晰地圖的新手。我保證不整那些虛頭巴腦的架構(gòu)圖全部是能直接抄作業(yè)的內(nèi)容。2. Agent 不是一個(gè)模型而是一套“分工體系”2.1 為什么說“會調(diào)工具”和“會寫工具”是分水嶺很多人一上來就問用 GPT 還是用 Claude用哪個(gè) Agent 框架我覺得方向反了。模型和框架是子彈和槍膛真正決定 Agent 戰(zhàn)斗力的是它手里的工具集——也就是 Skills。我習(xí)慣把 Agent 比作一個(gè)剛?cè)肼毜膶?shí)習(xí)生。模型是它的“智商”但這個(gè)實(shí)習(xí)生再聰明如果不會用公司的 OA 系統(tǒng)、看不懂報(bào)表格式、不知道怎么發(fā)郵件那還是干不了活。Skills 就是“入職培訓(xùn)手冊”你告訴它“遇到什么情況去調(diào)用哪個(gè)工具參數(shù)怎么填結(jié)果怎么解析”。而“會寫工具”更進(jìn)一層。普通的 API 對接只是把現(xiàn)有接口封一層但真正的 Skill 需要你定義清楚什么時(shí)候用、輸入什么、期望輸出什么、失敗怎么辦、要不要人工確認(rèn)。在騰訊云 AI Skills 的體系里一個(gè) Skill 其實(shí)就是一個(gè)帶清晰描述的“可執(zhí)行單元”Agent 通過語義匹配來決定調(diào)用哪一個(gè)。所以 Skill 寫得好不好直接決定了 Agent 是“得力干將”還是“人工智障”。我見過太多人把 Skill 寫成一句話“查詢訂單”。然后 Agent 遇到所有跟訂單相關(guān)的問題都調(diào)它參數(shù)一團(tuán)糟。正確的寫法應(yīng)該是觸發(fā)條件用戶問“我的訂單到哪了”“發(fā)貨沒有”等物流/訂單狀態(tài)類問題輸入?yún)?shù)order_id必填、user_id選填用于權(quán)限校驗(yàn)輸出格式JSON包含 status、tracking_company、tracking_no、estimated_time失敗處理查不到訂單時(shí)返回明確錯(cuò)誤碼并建議用戶檢查單號權(quán)限說明僅允許查詢當(dāng)前用戶自己的訂單這個(gè)描述看起來啰嗦但大模型就是靠這些信息來判斷“該不該用、怎么用”。你寫得更清楚Agent 的決策準(zhǔn)確率就更高。2.2 選騰訊云而不是自建我在權(quán)衡什么自建一套 Skill 編排引擎難嗎說難也難說簡單也簡單。如果只是本地跑幾個(gè) Python 函數(shù)用langchain或者dify也能拼出來。但真要放到生產(chǎn)環(huán)境問題就多了多用戶并發(fā)、權(quán)限隔離、調(diào)用審計(jì)、日志追蹤、彈性伸縮……這些沒人幫你兜底全得自己寫。我選騰訊云的核心考量有四個(gè)免運(yùn)維云函數(shù)、API 網(wǎng)關(guān)這些組件彈出來就能用不用半夜起來修服務(wù)器。生態(tài)完整AI Skills 跟騰訊云的 CVM、COS、SCF、數(shù)據(jù)庫都是打通了的Skill 里直接調(diào)用這些服務(wù)的 SDK 就行不用自己搭網(wǎng)絡(luò)。成本可控按量付費(fèi)開發(fā)階段幾乎不花錢不像自建集群要預(yù)留一大筆預(yù)算。團(tuán)隊(duì)協(xié)作多人開發(fā)時(shí)Skill 的版本管理和權(quán)限控制都現(xiàn)成不用自己設(shè)計(jì)一套 Git 流程。當(dāng)然自建也有自建的好處比如完全掌控、不被平臺綁定。但從“快速落地、驗(yàn)證想法”的角度云上這套確實(shí)省心。我自己現(xiàn)在的習(xí)慣是原型階段直接上騰訊云 AI Skills等跑通了再考慮要不要遷到自建。實(shí)際上跑了大半年沒找到必須遷的理由。2.3 幾個(gè)容易把人繞暈的概念一次講清在開始動手前先把幾個(gè)高頻詞捋清楚。首先是Agent智能體它是一套“大腦手腳”的完整系統(tǒng)大腦負(fù)責(zé)理解和規(guī)劃手腳由 Skills 充當(dāng)。其次是Skill技能一個(gè) Skill 通常對應(yīng)一個(gè)具體能力比如“查天氣”“發(fā)郵件”“生成圖表”。再就是Workflow工作流當(dāng)你把多個(gè) Skill 按特定順序串起來就形成了工作流比如“監(jiān)控服務(wù)器→異常時(shí)發(fā)告警→自動生成工單”。最后是Memory記憶Agent 把歷史對話和上下文存下來供后續(xù)決策使用這在騰訊云上一般用向量數(shù)據(jù)庫或 Redis 實(shí)現(xiàn)。順便說一句網(wǎng)上很多人把 Skill 和 Agent 混著說其實(shí)區(qū)別很清晰Agent 是“指揮官”Skill 是“士兵”。你的 Agent 可以有十個(gè) Skill也可以有一百個(gè)關(guān)鍵在于怎么組織它們。騰訊云最近也在推“技能集市”這類東西相當(dāng)于一個(gè) Skill 的共享市場別人的技能可以直接拿過來用這對剛起步的團(tuán)隊(duì)來說省了很多事。3. 動手前要搞定的事服務(wù)器、域名和基礎(chǔ)環(huán)境3.1 第一次用騰訊云從注冊到找到入口的保姆級流程如果你還沒有騰訊云賬號注冊這一步挺簡單但有個(gè)細(xì)節(jié)我得提醒你很多人掛在“網(wǎng)絡(luò)環(huán)境異?！鄙?。這個(gè)提示通常是因?yàn)楫?dāng)前網(wǎng)絡(luò) IP 被風(fēng)控?cái)r了換個(gè)網(wǎng)絡(luò)環(huán)境比如手機(jī)熱點(diǎn)基本就能過。注冊完成后進(jìn)入控制臺建議先把“訪問密鑰”準(zhǔn)備好——在右上角頭像菜單里找到“訪問管理”創(chuàng)建一個(gè)子賬號的 API 密鑰千萬別用根賬號的密鑰權(quán)限太大不安全。接下來就是開通 Agent 相關(guān)服務(wù)。在控制臺搜索“AI Skills”或者從“人工智能”菜單進(jìn)去找到對應(yīng)的產(chǎn)品頁按提示開通即可。這個(gè)過程一般幾分鐘內(nèi)完成不需要額外付費(fèi)按量后付。我還要多一句嘴如果你打算把 Agent 做成對外服務(wù)域名基本是必需品。騰訊云上申請域名走的是“備案”流程這是一個(gè)常見的耗時(shí)點(diǎn)建議提前規(guī)劃。開發(fā)階段可以先不綁定域名用平臺默認(rèn)的 API 網(wǎng)關(guān)地址調(diào)試。3.2 一臺 2 核 4G 的小機(jī)器怎么撐起整套 Agent 環(huán)境先說你其實(shí)不需要多高的配置。Agent 本身只是個(gè)編排層重活都在大模型 API 和你寫的 Skill 函數(shù)里。我自己在用的是一臺 2 核 4G 的輕量服務(wù)器跑著 Docker、Nginx、Redis、一個(gè) FastAPI 服務(wù)以及一些定時(shí)任務(wù)CPU 和內(nèi)存常年用不到一半。真正吃資源的是模型推理但那個(gè)調(diào)用的是云端 API本地不占資源。購買云服務(wù)器后有幾步基礎(chǔ)配置一定要做否則后面會踩坑安全組放行端口。騰訊云默認(rèn)只開放 22、80、443你需要手動加上應(yīng)用要用的端口比如 8000、8080 等。這個(gè)在“安全組”控制臺里配置入站規(guī)則加一條 TCP 端口規(guī)則即可。安裝 Docker。用官方腳本curl -fsSL https://get.docker.com | bash一鍵裝好然后systemctl enable docker設(shè)置開機(jī)自啟。配好防火墻如果是輕量服務(wù)器自帶防火墻和安全組兩層都要放行。搞定域名解析。開發(fā)階段可以直接用 IP 訪問但如果你要做 Webhook 回調(diào)建議還是把域名解析到這臺機(jī)器后面會省不少事。我記得第一次弄的時(shí)候安全組放了端口但忘記了輕量服務(wù)器自帶的防火墻結(jié)果外面連不上排查了大半天。騰訊云的控制臺其實(shí)有“防火墻”和“安全組”兩層概念規(guī)則都要對。現(xiàn)在的輕量服務(wù)器控制臺里直接就有放行端口的入口不用像早期那樣去翻安全組。3.3 Docker 化部署 Agent 框架我的標(biāo)準(zhǔn)配置單為了不污染宿主機(jī)環(huán)境我習(xí)慣把 Agent 框架整個(gè)跑在 Docker 里。分享一份我用得很順的docker-compose.yml配置version: 3.8 services: agent-core: image: your-agent-image:latest container_name: agent-core restart: always ports: - 8000:8000 environment: - OPENAI_API_KEY${OPENAI_API_KEY} - TENCENT_SECRET_ID${TENCENT_SECRET_ID} - TENCENT_SECRET_KEY${TENCENT_SECRET_KEY} - REDIS_URLredis://redis:6379/0 - AGENT_WORKSPACE/workspace volumes: - ./skills:/workspace/skills - ./logs:/workspace/logs - ./config:/workspace/config depends_on: - redis networks: - agent-net redis: image: redis:7-alpine container_name: agent-redis restart: always ports: - 6379:6379 volumes: - redis-data:/data networks: - agent-net volumes: redis-data: networks: agent-net: driver: bridge這份配置有幾個(gè)巧妙的地方skills 目錄掛在宿主機(jī)上意味著我改一段 Skill 代碼容器內(nèi)立刻生效開發(fā)模式下不用重新 build 鏡像。Redis 單獨(dú)一個(gè)容器既跑緩存也跑記憶存儲Agent 的對話歷史都放這里。環(huán)境變量統(tǒng)一走.env文件密鑰不寫死在代碼里。開發(fā)調(diào)試時(shí)我會額外開一個(gè)docker compose exec agent-core bash進(jìn)入容器直接跑 Skill 的測試腳本這樣能繞開 Agent 的編排層單測某個(gè)工具本身的好壞。4. AI Skills 的核心編寫心法從能跑到好用4.1 Skill 的最小區(qū)塊描述、參數(shù)、實(shí)現(xiàn)、回退一個(gè)標(biāo)準(zhǔn)的 Skill 文件我通常分四段來寫。描述段是給 Agent 看的“自我介紹”務(wù)必用清晰、口語化的中文并列出典型的觸發(fā)短語參數(shù)段定義入?yún)Q、類型、必填性、示例值實(shí)現(xiàn)段是真實(shí)邏輯推薦使用 Python 或 Node.js 的云函數(shù)風(fēng)格回退段是錯(cuò)誤處理目錄告訴 Agent “這個(gè) Skill 沒成功時(shí)該做什么”。舉個(gè)例子假設(shè)我們要寫一個(gè)“查詢服務(wù)器狀態(tài)”的 Skilldef get_server_status(server_id: str) - dict: 查詢騰訊云 CVM 實(shí)例的實(shí)時(shí)狀態(tài)。 觸發(fā)條件用戶詢問服務(wù)器運(yùn)行狀態(tài)、CPU/內(nèi)存/磁盤使用率、是否在線等。 參數(shù) server_id: 實(shí)例ID形如 ins-xxxxxxxx必填 返回 JSON對象包含實(shí)例狀態(tài)、CPU使用率、內(nèi)存使用率、外網(wǎng)IP。 import json from tencentcloud.common import credential from tencentcloud.cvm.v20170312 import cvm_client, models cred credential.Credential( os.environ[TENCENT_SECRET_ID], os.environ[TENCENT_SECRET_KEY] ) client cvm_client.CvmClient(cred, ap-guangzhou) req models.DescribeInstancesRequest() params {InstanceIds: [server_id]} req.from_json_string(json.dumps(params)) resp client.DescribeInstances(req) # 解析并簡化返回結(jié)構(gòu)只保留關(guān)鍵信息 ... return result注意那個(gè)長長的 docstring——這不是給人看的注釋而是給大模型看的“調(diào)用說明書”。沒有這段說明Agent 可能壓根不知道有這個(gè)工具或者不知道怎么填參數(shù)。這是我踩過最深的坑之一Skill 函數(shù)寫得飛快docstring 草草了事結(jié)果 Agent 決策準(zhǔn)確率直接崩了。后來我把所有 Skill 的 docstring 都重寫了一遍效果立竿見影。4.2 怎么寫“提示詞類型”的 Skill——你以為是編程其實(shí)是在寫Prompt別誤會Skill 不一定要寫 Python。有些場景下一個(gè)好的 Prompt 本身就是 Skill。比如你希望 Agent 具備“把技術(shù)文檔翻譯成白話”的能力不必寫代碼寫一段結(jié)構(gòu)化的提示詞塞進(jìn) Skill 庫就行。騰訊云 AI Skills 也支持這種純 Prompt 類型的技能對非程序員特別友好。我常用的“Prompt 型 Skill”模板長這樣角色你是一位資深技術(shù)編輯擅長把晦澀的工程師語言轉(zhuǎn)成小白也能看懂的大白話。 任務(wù)把用戶輸入的段落重寫要求 1. 保留核心信息不新增內(nèi)容 2. 使用類比幫助理解 3. 控制在 200 字以內(nèi) 4. 結(jié)尾加一句簡單說就是... 輸入{input}寫這種 Skill 的訣竅是“把約束寫死”——長度、風(fēng)格、格式都要明確模型才有抓手。不能光說“你幫我解釋一下”而要像給外包同事派活一樣把驗(yàn)收標(biāo)準(zhǔn)說清楚。4.3 聯(lián)合多個(gè) Skill 完成復(fù)雜任務(wù)這是 Agent 能力的倍增器單個(gè) Skill 再強(qiáng)也是單兵Agent 真正的爆發(fā)力來自協(xié)同。舉個(gè)例子我想讓 Agent 每天早上自動生成一份“業(yè)務(wù)健康日報(bào)”光靠一個(gè) Skill 搞不定需要好幾個(gè)配合fetch_sales_data從數(shù)據(jù)庫拉取昨日銷售額fetch_error_logs從日志服務(wù)拉取系統(tǒng)報(bào)錯(cuò)數(shù)量和 TOP 錯(cuò)誤generate_report調(diào)用大模型把數(shù)據(jù)整理成圖文報(bào)告send_email把報(bào)告發(fā)給指定郵箱在 Agent 的工作流編排里我可以這樣配置workflow: name: daily_business_report trigger: type: cron expression: 0 8 * * * steps: - skill: fetch_sales_data args: date: {{ yyyy-mm-dd - 1 day }} - skill: fetch_error_logs args: date: {{ yyyy-mm-dd - 1 day }} - skill: generate_report args: data_source: {{ steps.fetch_sales_data.output }} {{ steps.fetch_error_logs.output }} - skill: send_email args: to: opsexample.com title: 業(yè)務(wù)健康日報(bào) content: {{ steps.generate_report.output }}這里每一步的輸出都傳給下一步形成一條流水線。我自己寫的時(shí)候會特別注意格式約定兩個(gè) Skill 之間傳遞的數(shù)據(jù)用 JSON并且每個(gè) Skill 的返回結(jié)構(gòu)要在文檔里固定下來。如果前端 Skill 返回了字符串、后端 Skill 卻要 JSONAgent 就會瞎猜出錯(cuò)率一下子就上去了。4.4 子技能拆分一個(gè) Skill 該多大邊界怎么劃Skill 粒度太粗Agent 用起來笨重粒度太細(xì)Agent 的決策鏈條太長、容易出錯(cuò)。我總結(jié)出一個(gè)經(jīng)驗(yàn)法則一個(gè) Skill 只做一件“動詞賓語”的事。“查詢訂單”可以“查詢訂單并計(jì)算退款金額”最好拆成兩個(gè)“發(fā)送郵件通知”可以“處理整個(gè)售后流程”必須拆。舉個(gè)例子之前我寫了一個(gè)“處理用戶反饋”的 Skill內(nèi)部邏輯又臭又長判斷情緒→分類→查訂單→生成回復(fù)→發(fā)郵件。結(jié)果就是沒人調(diào)用它Agent 總覺得“這事不歸我管”。后來我把它拆成五個(gè)小 Skillclassify_feedback(文本) - 類別detect_sentiment(文本) - 正/負(fù)/中search_order(user_id) - 訂單信息generate_reply(類別, 情緒, 訂單信息) - 回復(fù)草稿send_reply(user_id, 回復(fù)內(nèi)容) - 發(fā)送結(jié)果拆完之后 Agent 的組合能力反而更強(qiáng)了。遇到一個(gè)投訴它可以先分類、再查單、再生成回復(fù)路徑清晰可控。所以如果你覺得 Agent 總是“理解不了你寫的 Skill”大概率是 Skill 寫得太“大”了重新切一切就好。5. 實(shí)操實(shí)測把一個(gè)“能跑的 Demo”變成“可靠的服務(wù)”5.1 我搭建的一個(gè)完整 Agent 案例智能客服機(jī)器人光講理論不過癮我說一個(gè)自己最近在跑的實(shí)戰(zhàn)項(xiàng)目。場景是一個(gè)電商業(yè)務(wù)的售前售后智能客服需要處理“查訂單、改地址、退換貨、催發(fā)貨、客服人工介入”五類問題。Agent 大腦用的是大模型 APISkills 我按下面的結(jié)構(gòu)搭Skills作用觸發(fā)詞舉例get_order_info查訂單狀態(tài)和物流我的訂單、到哪了、發(fā)貨沒modify_shipping_address修改收貨地址改地址、換個(gè)地址apply_refund提交退貨/退款申請退貨、退款、不想要了remind_shipment催發(fā)貨給倉庫發(fā)內(nèi)部工單催一下、什么時(shí)候發(fā)human_handoff轉(zhuǎn)人工附帶上下文人工、客服、投訴整個(gè) Agent 的處理流程大致是用戶發(fā)消息 → 意圖識別哪個(gè) Skill 相關(guān)→ 參數(shù)提取從對話里抽取 order_id 等→ 調(diào)用 Skill → 結(jié)果整理成自然語言回復(fù)用戶。如果用戶的請求超出了 Skills 的覆蓋范圍就返回預(yù)設(shè)話術(shù)并轉(zhuǎn)人工。這里的核心是“意圖識別 參數(shù)提取”。我并沒有單獨(dú)訓(xùn)練一個(gè)意圖識別模型而是完全靠大模型的 few-shot 能力把所有 Skill 的觸發(fā)詞和參數(shù)說明拼在 Prompt 里。實(shí)際效果準(zhǔn)確率大概在 92%~95% 之間。剩下的誤判絕大部分是參數(shù)抽取錯(cuò)了——比如用戶說“我要退單”模型把“退單”當(dāng)成了“訂單號”。這個(gè)沒有銀彈只能在異常分支里加一個(gè)“請確認(rèn)一下您的訂單號是 XXX 嗎”來兜底。5.2 接入大模型 API、云函數(shù)和數(shù)據(jù)庫時(shí)我最看重的三個(gè)點(diǎn)接入大模型 API 時(shí)我最看重的是超時(shí)與重試機(jī)制。模型接口偶爾會慢幾秒甚至十幾秒都有如果 Agent 沒有設(shè)定超時(shí)一次對話可能把整個(gè)工作流拖死。我的做法是單次模型調(diào)用超時(shí)設(shè)定為 30 秒最多重試 2 次重試之間間隔 2 秒遞增。云函數(shù)調(diào)用是“按量計(jì)費(fèi)”所以每一次失敗都要有日志方便事后分析。接入云函數(shù)時(shí)我特別在意冷啟動問題。如果函數(shù)體較大、依賴較多第一次調(diào)用可能要等好幾秒。我一般給關(guān)鍵函數(shù)設(shè)置“預(yù)置并發(fā)”或者是用 Docker 鏡像方式部署明顯比代碼包方式快。另外云函數(shù)默認(rèn)不支持長連接比如 WebSocket如果有流式輸出的需求要考慮 API 網(wǎng)關(guān)搭配 WebSocket 的方案。接入數(shù)據(jù)庫時(shí)我踩過一個(gè)大坑連接池耗盡。一開始每個(gè) Skill 都是“用完就 new 一個(gè)連接”結(jié)果并發(fā)一高數(shù)據(jù)庫直接拒絕連接。后來改成全局連接池用 SQLAlchemy 的pool_size10, max_overflow5瞬間穩(wěn)定了。這個(gè)小細(xì)節(jié)很多教程里不會講但生產(chǎn)環(huán)境沒有它真的會出事。5.3 上下文管理和記憶如何讓 Agent 記住“上次聊到哪”一個(gè) Agent 如果沒有記憶用戶每次對話都像在跟失憶癥患者聊天體驗(yàn)極差。我的做法是三層記憶短期記憶存在 Rediskey 是session:{user_id}value 是最近 20 輪對話摘要TTL 設(shè)為 2 小時(shí)。中期記憶存在騰訊云數(shù)據(jù)庫記錄用戶偏好比如“客戶 A 喜歡用順豐”“客戶 B 有備注不要電話推銷”。長期記憶存在向量數(shù)據(jù)庫把每次服務(wù)工單的關(guān)鍵信息做向量化供 Agent 后續(xù)檢索參考。短期記憶的實(shí)現(xiàn)最簡單直接把對話歷史拼進(jìn) Prompt 就行但要注意 Token 限制。我一般是先摘要再拼如果歷史超過 10 輪就把前 5 輪壓縮成一段摘要后 5 輪原文保留。這樣既省 Token又不丟失關(guān)鍵信息。長期記憶有點(diǎn)麻煩。我試過把用戶的每個(gè)偏好都存成一條記錄結(jié)果數(shù)據(jù)噪音很多經(jīng)常抓到無關(guān)信息。后來換了思路只在用戶主動表達(dá)特別要求時(shí)存一條長期記憶而且要經(jīng)過一個(gè)“過濾 Prompt”確認(rèn)比如“用戶這句話是否屬于特殊偏好是/否”這樣記憶庫干凈多了。目前實(shí)測效果不錯(cuò)——用戶說“你們是不是換了人還記得我上次說不要圓通”我就知道這次的記憶機(jī)制做對了。6. 常見報(bào)錯(cuò)和翻車現(xiàn)場我?guī)湍惆芽犹钇搅?.1 Agent 執(zhí)行到一半就終止最常見的 5 個(gè)原因遇到“agent execution terminated due to error”這種提示別慌按下面的順序排查大概率能解決1. 模型上下文溢出當(dāng)對話輪數(shù)多、返回內(nèi)容長時(shí)容易超出模型最大 Token 限制。解決方法是升級模型版本、截?cái)鄽v史或壓縮摘要。2. Skill 拋異常沒捕獲Python 代碼里沒有 catch 所有異常導(dǎo)致 Agent 收到非預(yù)期錯(cuò)誤。我的習(xí)慣是每個(gè) Skill 入口都套一層try...except把異常轉(zhuǎn)成結(jié)構(gòu)化的錯(cuò)誤信息返回給 Agent。3. 網(wǎng)絡(luò)超時(shí)云函數(shù)連接數(shù)據(jù)庫、外部 API 時(shí)可能超時(shí)。檢查一下網(wǎng)絡(luò)配置超時(shí)時(shí)間盡量放寬。4. 權(quán)限不足Skill 里調(diào)用了沒授權(quán)的 API比如訪問 COS 時(shí)沒有 CAM 權(quán)限。到控制臺看一下角色的策略有沒有綁定。5. 參數(shù)類型錯(cuò)誤Agent 把字符串傳給了只接受數(shù)組的參數(shù)運(yùn)行時(shí)拋類型錯(cuò)誤。這個(gè)要在 Skill 文檔里給足示例能大幅降低出錯(cuò)率。我自己遇到最多的是第一條和第三條。有一次排查了半天最后發(fā)現(xiàn)是云函數(shù)默認(rèn)超時(shí)時(shí)間只有 15 秒而那個(gè) Skill 要查詢的數(shù)據(jù)特別大15 秒根本不夠調(diào)成 30 秒后問題就沒了。6.2 模型答非所問時(shí)先別急著換模型檢查 Skill 描述很多人在 Agent 回答不準(zhǔn)時(shí)第一反應(yīng)是“這個(gè)模型不行”換一個(gè)更貴的模型。但根據(jù)我的經(jīng)驗(yàn)80% 的情況是 Skill 描述寫得不夠清晰。舉個(gè)例子你寫了一個(gè)“查快遞”的 Skill但 docstring 里只寫“輸入快遞單號”沒寫“如果用戶沒給單號先問用戶要單號不要亂猜”。那模型可能就會捏造一個(gè)單號去調(diào)接口結(jié)果查不到它還繼續(xù)給自己圓場。所以我把這種“邊界條件”都寫進(jìn)了 Skill 描述里如果缺少必填參數(shù)不要猜測向用戶詢問缺少的內(nèi)容。 如果查詢無結(jié)果明確告知用戶并建議檢查單號或等待物流更新。 一次只處理一個(gè)訂單如果用戶提到多個(gè)訂單分開處理。這些看似很傻的規(guī)則是讓 Agent 穩(wěn)定輸出的關(guān)鍵。模型是概率生成你不把邊界釘死它就會自由發(fā)揮。自由發(fā)揮對普通聊天沒事但對需要精確調(diào)用的 Agent 來說就是災(zāi)難。6.3 安全與權(quán)限我把一個(gè) Skill 暴露到公網(wǎng)之后被刷了 3 萬次這是一個(gè)真實(shí)的慘痛教訓(xùn)。有一次我做了一個(gè)“查詢天氣”的 Skill為了調(diào)試方便直接把 API 網(wǎng)關(guān)建成了公開訪問也沒有任何鑒權(quán)。結(jié)果上線不到半小時(shí)被腳本刷了 3 萬多次賬單直接飄紅。從那以后我給自己定了幾條鐵律所有 Skill 的 API 網(wǎng)關(guān)都要加鑒權(quán)哪怕內(nèi)網(wǎng)調(diào)用也要有密鑰使用騰訊云的 CAM 角色而非永久密鑰敏感操作比如刪除訂單、修改金額加“人工確認(rèn)”環(huán)節(jié)Agent 不能直接執(zhí)行給每個(gè) Skill 配置獨(dú)立的日志主題審計(jì)時(shí)能精確定位到哪次調(diào)用、哪個(gè)參數(shù)加上限流API 網(wǎng)關(guān)按密鑰限流超過閾值直接拒絕這些不只是在騰訊云上適用任何平臺的 Agent 開發(fā)都該這么干。安全問題往往不是技術(shù)問題而是意識問題。被刷一次之后我真的體會到“云上的流量水很深”別覺得自己的小項(xiàng)目沒人盯。7. 更進(jìn)一步的優(yōu)化讓 Agent 學(xué)會“學(xué)習(xí)”7.1 給 Agent 加一個(gè)“反思循環(huán)”失敗之后自動調(diào)整策略默認(rèn)的 Agent 工作流是“用戶發(fā)指令→執(zhí)行→返回結(jié)果”但很多復(fù)雜任務(wù)一次執(zhí)行往往不完美。我最近在嘗試給 Agent 加一個(gè)“反思循環(huán)”Agent 執(zhí)行完一輪任務(wù)后不直接返回給用戶而是先自我評價(jià)“我的回答是否完整是否調(diào)用了正確的 Skill參數(shù)是否有明顯問題”如果自評分?jǐn)?shù)低就讓它重新擬一個(gè)執(zhí)行計(jì)劃再執(zhí)行一次。如果連續(xù)兩次都失敗才把問題交給人工。這個(gè)機(jī)制的實(shí)現(xiàn)成本不高無非是在編排邏輯里加一個(gè)“評判與重試”的節(jié)點(diǎn)但收益非常明顯。尤其是處理“模糊問題”時(shí)Agent 多花一次調(diào)用就能把答案從“差不多對”提升到“精準(zhǔn)命中”。要注意的是反思循環(huán)不要超過 2 次否則成本和耗時(shí)都不可控。我用過一個(gè)激進(jìn)的版本允許重試 5 次結(jié)果用戶反饋“回復(fù)太慢了”只有性能流逝沒有獲得更好的答案。調(diào)回 2 次之后平衡最好。7.2 引入“學(xué)習(xí)記憶”后Agent 的進(jìn)化軌跡之前提過長期記憶但我想再展開一點(diǎn)。當(dāng)你把“用戶的偏好”“過去成功處理的問題”“常見失敗模式”都存進(jìn)向量庫之后Agent 會呈現(xiàn)一個(gè)明顯的“進(jìn)化曲線”。剛開始運(yùn)營時(shí)Agent 需要用戶反復(fù)確認(rèn)“您說的是這個(gè)意思嗎”用了一周后它已經(jīng)能記住常見問題的處理方式不再需要完整解釋用了一個(gè)月后很多高頻場景甚至不需要走完整流程直接給出正確結(jié)果。我做的一個(gè)人力資源問答 Agent 就是如此最開始連“年假怎么算”都要去翻資料后來我把歷年政策、常見個(gè)案、審批流程全部向量化存進(jìn)去它回答的準(zhǔn)確率肉眼可見地漲。這個(gè)過程中我沒有調(diào)整模型也沒有重寫 Skill只是把“記憶”這塊補(bǔ)齊了。所以在 Team 里我常說一句話模型決定了 Agent 的下限Skills 和 Memory 決定了它的上限。7.3 成本優(yōu)化的幾個(gè)騷操作實(shí)測每月省 40%云上的 Agent 跑久了賬單是看得見的焦慮。我積累了三個(gè)比較實(shí)用的成本優(yōu)化招數(shù)用小模型做分類大模型做生成意圖識別、參數(shù)抽取用便宜的小模型比如騰訊云的輕量模型只有最終回答、復(fù)雜推理才用大模型。實(shí)測成本能降 30% 左右。結(jié)果緩存同一類問題的標(biāo)準(zhǔn)回答可以直接緩存到 Redis見過來就問“你們發(fā)什么快遞”沒必要每次都調(diào)大模型。緩存命中率一高成本自然就下來了。批量化和異步化能異步處理的比如生成每日報(bào)表、批量生成回復(fù)盡量走消息隊(duì)列避免不必要的并發(fā)模型調(diào)用。當(dāng)然成本優(yōu)化也要留有余地。別為了省錢把小模型用在大模型干不了的重活上否則省下來的錢都要用“用戶投訴”去還。建議按月設(shè)置一個(gè)預(yù)算警報(bào)比如到了 80% 就提醒自己檢查調(diào)用量。8. 那些坑我都替你蹚過了經(jīng)驗(yàn)之談與踩坑實(shí)錄先分享一個(gè)讓我印象極其深刻的教訓(xùn)生產(chǎn)環(huán)境的 Agent 不是一個(gè)“模型 一堆 Skill”的堆疊。有一陣子我把精力全花在“塞更多 Skill”上覺得技能越多越全能。結(jié)果呢Agent 每次選錯(cuò)工具的概率顯著上升反而更不穩(wěn)定。后來我做了個(gè)“技能清理行動”把不常用的、邊界模糊的 Skill 全部下架保留最核心的 20 個(gè)準(zhǔn)確率立刻回升。所以現(xiàn)在我的建議是寧可少而精不要多而濫。每加一個(gè) Skill都要問自己三個(gè)問題——它是否真的會被頻繁調(diào)用它與已有 Skill 的邊界是否清晰它的失敗是否會拖累整個(gè)流程如果答案都不是果斷的“是”就先別上。第二件讓我印象深刻的事是日志的威力。剛開始寫 Agent 時(shí)我只關(guān)注“回答得好不好”忽略日志。直到有一次一個(gè) Skill 在深夜連續(xù)報(bào)錯(cuò)我沒有采集日志只能靠用戶反饋才能發(fā)現(xiàn)問題特別被動。此后我把日志當(dāng)成 Agent 的一等公民記錄每次調(diào)用模型的輸入輸出、調(diào)用 Skill 的參數(shù)、耗時(shí)、token 消耗和錯(cuò)誤堆棧。分析完日志后我一般能提前預(yù)判很多故障而不是事后救火。第三點(diǎn)算是一個(gè)心態(tài)建議用 Agent 和用傳統(tǒng)軟件非常不一樣。傳統(tǒng)軟件是“規(guī)則驅(qū)動”你寫清楚邏輯它穩(wěn)定執(zhí)行Agent 是“概率驅(qū)動”同樣的輸入可能得到略有差異的輸出。所以做 Agent 開發(fā)不能追求 100% 確定性而是要把確定性控制在關(guān)鍵路徑上把模糊性放在可以接受的范圍里。9. 別忘了團(tuán)隊(duì)協(xié)作Skill 的版本管理和共享當(dāng)團(tuán)隊(duì)超過三個(gè)人以后Skill 的管理就會變得很頭疼。沒有版本控制的時(shí)候誰改了哪個(gè) SkillAgent 的行為就悄悄變了出了問題都不知道找誰。我們現(xiàn)在的做法是把 Skill 代碼放在 Git 倉庫里每個(gè) Skill 一個(gè)目錄里面包含代碼、描述文檔、測試用例和示例輸入輸出。通過 CI/CD 流水線代碼合并后自動跑一遍單元測試再部署到云上。測試用例尤其重要。我給每個(gè) Skill 都會寫三組測試一組是正常輸入一組是邊界輸入比如參數(shù)缺失一組是異常輸入比如查不到數(shù)據(jù)。Agent 是概率決策但 Skill 本身必須是確定性正確的否則它會帶偏 Agent 的整體判斷。這一步建議不要偷懶。騰訊云 AI Skills 的產(chǎn)品形態(tài)本身也考慮了多角色協(xié)作開發(fā)者在“技能工作臺”寫 Skill運(yùn)營在“編排區(qū)”配工作流業(yè)務(wù)在“應(yīng)用區(qū)”使用 Agent。這樣前端業(yè)務(wù)和后端邏輯能解耦團(tuán)隊(duì)配合順暢多了。10. 沿著這條路再往前走從“全能”到“可信”的 Agent我現(xiàn)在做的這個(gè)項(xiàng)目已經(jīng)不滿足于“會干活”了更追求“干得穩(wěn)、干得安全、干得可解釋”。騰訊云 AI Skills 這樣的體系給了我一套相對成熟的底座工具調(diào)用有日志、權(quán)限有控制、流程可編排。但我也清楚地知道Agent 的能力邊界還在快速演進(jìn)今天的“最佳實(shí)踐”可能半年后就被刷新。如果你正要開始做自己的 Agent我的建議是別先追求全能先把一件事做扎實(shí)。挑一個(gè)具體場景比如客服、運(yùn)維、內(nèi)容生成把 3~5 個(gè) Skill 打磨到極致再慢慢擴(kuò)展。我見過太多項(xiàng)目雄心勃勃想做一個(gè)“什么都會的超級助手”最后因?yàn)榉秶蠖鵂€尾。與其做一個(gè)處處平庸的全能 Agent不如做一個(gè)在特定領(lǐng)域讓用戶“哇塞”的專家 Agent。再回到“騰訊云 AI Skills 最佳實(shí)踐”這個(gè)標(biāo)題上我個(gè)人的體會是云平臺給了你一把好槍但槍法還是要自己練。Skill 的編寫質(zhì)量、工作流的設(shè)計(jì)水平、對邊界情況的考慮、對日志和安全的敏感度這些才是真正決定 Agent 成敗的東西。騰訊云只是把那套繁瑣的底層設(shè)施接住了讓你能更聚焦在業(yè)務(wù)本身。最后分享一個(gè)我常用的“新 Skill 上線檢查清單”描述寫了幾句話是否包含觸發(fā)條件參數(shù)是否有示例值異常分支是否明確權(quán)限是否最小化日志是否有記錄測試用例是否通過成本是否預(yù)估過這個(gè)小清單看著簡單但每一條背后都是我踩過的坑。希望你不用再踩一遍。