在做騰訊云上的 AI Agent 項(xiàng)目之前我一直以為 Agent 就是一個(gè)更聰明的聊天框。你給它一個(gè)問(wèn)題它給你一個(gè)答案頂多再帶點(diǎn)聯(lián)網(wǎng)搜索。但這個(gè)項(xiàng)目做到后面我發(fā)現(xiàn)真正讓 Agent 從“演示玩具”變成“生產(chǎn)助理”的不是模型智商而是它身邊那套 AI Skills 體系。Skills 決定了 Agent 能不能真正調(diào)用云資源、查監(jiān)控、發(fā)消息、執(zhí)行任務(wù)。這篇文章我會(huì)用自己在騰訊云上從零搭 Agent 的經(jīng)歷把 AI Skills 的劃分、注冊(cè)、調(diào)度、部署和排障講清楚適合已經(jīng)在用大模型 API、想開(kāi)始做 Agent 工程化的人參考。如果你正準(zhǔn)備在騰訊云上跑一個(gè)能穩(wěn)定干活的 Agent這篇應(yīng)該能幫你省掉不少試錯(cuò)成本。1. 先把 Agent 的“身體”搭對(duì)Skills 和騰訊云的分工1.1 單模型 Prompt 的極限逼我轉(zhuǎn)向 Skills我一開(kāi)始的做法特別天真寫(xiě)一個(gè)超長(zhǎng) system prompt把所有功能描述、處理規(guī)則、返回格式全塞給大模型。用戶說(shuō)“幫我看看服務(wù)器磁盤(pán)”我就期待模型在文本里給出答案。但真正跑起來(lái)以后問(wèn)題立刻暴露出來(lái)。一旦任務(wù)涉及多步驟比如“檢查幾臺(tái)服務(wù)器的磁盤(pán)使用情況順手把超過(guò) 80% 的日志清理掉”模型就經(jīng)常出現(xiàn)兩種情況一是只給出建議不真正執(zhí)行動(dòng)作二是返回格式千奇百怪我在后端不得不寫(xiě)一堆正則去猜它到底想干什么。這種方案說(shuō)白了就是把 Agent 當(dāng)成一個(gè)“文本生成器”而不是一個(gè)“任務(wù)執(zhí)行器”。后來(lái)我把思路換了一下模型只負(fù)責(zé)“判斷該調(diào)用什么技能、填什么參數(shù)”具體的動(dòng)作交給一段段獨(dú)立的 Skills 去執(zhí)行。技能可以是 Python 函數(shù)、HTTP 接口、命令行腳本也可以是騰訊云的各種 API 封裝。模型拿到了用戶的請(qǐng)求后先從注冊(cè)表里選一個(gè)最匹配的技能按照預(yù)定 schema 輸出參數(shù)然后我這邊執(zhí)行技能再把結(jié)果返回給模型讓模型整理成用戶能看懂的答復(fù)。這個(gè)循環(huán)就是 Agent 的核心骨架比單純堆 prompt 要可靠得多。1.2 Skills 到底是什么以及它和“工具調(diào)用”的區(qū)別很多框架里已經(jīng)有類似的概念比如 function calling、tool calling甚至 Claude 生態(tài)里的 Skills。本質(zhì)上它們是同一個(gè)東西讓模型不止會(huì)“說(shuō)”還會(huì)“做”。我給 Skills 定的標(biāo)準(zhǔn)是一個(gè)完整的技能必須包含四部分名字、描述、參數(shù)定義、執(zhí)行邏輯。名字和描述是給模型看的參數(shù)定義決定模型怎么填參數(shù)執(zhí)行邏輯才是真正干活的部分。比如說(shuō)“查詢 CVM 實(shí)例列表”這個(gè)技能模型看到描述里寫(xiě)了“可用于查詢?cè)品?wù)器、實(shí)例、CPU 使用情況”之后就會(huì)在合適的時(shí)機(jī)觸發(fā)它并按要求補(bǔ)上地域、數(shù)量這些參數(shù)。Skills 和普通“工具調(diào)用”的區(qū)別我覺(jué)得在于描述方式。工具調(diào)用經(jīng)常只給一個(gè)抽象的函數(shù)名但 Skills 更強(qiáng)調(diào)“使用邊界”。一個(gè)技能描述里不僅要寫(xiě)它“什么時(shí)候用”還要寫(xiě)它“什么時(shí)候不要用”這樣模型才不會(huì)瞎選。例如一個(gè)“查詢實(shí)例列表”的技能描述里就應(yīng)該明確說(shuō)“當(dāng)用戶想查看云主機(jī)、輕量服務(wù)器、實(shí)例 ID、公網(wǎng) IP 時(shí)使用當(dāng)用戶只是解釋概念時(shí)不要用”。這些細(xì)節(jié)看起來(lái)不起眼但對(duì)模型選對(duì)率的影響非常大。我在一次測(cè)試?yán)镏恍薷牧藥讉€(gè)技能描述模型技能選擇的準(zhǔn)確率就從 67% 提到了 91%。1.3 騰訊云在整套體系里提供的其實(shí)是一副“骨架”有人可能會(huì)問(wèn)Agent 開(kāi)發(fā)不是有大模型就行了嗎為什么非要扯上騰訊云我的回答是大模型只能給智慧和決策但 Agent 要真正落地必須有地方跑代碼、有地方存狀態(tài)、有地方暴露接口、有地方看日志。騰訊云在這套體系里提供的不是“現(xiàn)成的 Agent”而是 DevOps 層面的能力云服務(wù)器或輕量服務(wù)器負(fù)責(zé)跑調(diào)度器Redis 負(fù)責(zé)存會(huì)話狀態(tài)API 網(wǎng)關(guān)負(fù)責(zé)把 Agent 暴露給外部調(diào)用方容器鏡像服務(wù)負(fù)責(zé)分發(fā)部署包日志服務(wù)負(fù)責(zé)全鏈路追蹤。我選擇騰訊云并不是因?yàn)樗惺裁刺厥獾?Agent 黑魔法而是因?yàn)樗幕A(chǔ)組件剛好覆蓋了 Agent 工程化最需要的幾塊而且這些組件之間內(nèi)網(wǎng)互通延遲很低。如果你的 Skills 需要頻繁調(diào)用云上的 CVM、監(jiān)控、短信、對(duì)象存儲(chǔ)這類服務(wù)把 Agent 部署在同一個(gè)云環(huán)境里比本地開(kāi)發(fā)打 API 到公網(wǎng)省非常多事情。尤其在做多輪對(duì)話時(shí)Agent 每輪都要讀寫(xiě) Redis如果 Redis 不在同一網(wǎng)絡(luò)環(huán)境延遲會(huì)非常刺眼。所以我的建議是先確定 Agent 要調(diào)用哪些云資源再?zèng)Q定把運(yùn)行時(shí)部署在哪里而不是反過(guò)來(lái)。2. 技能拆分與注冊(cè)表讓 Agent 能“看見(jiàn)”自己的手2.1 技能粒度怎么定從用戶意圖反推而不是按系統(tǒng)模塊技能拆分的粒度是整個(gè)項(xiàng)目里最容易返工的地方。我一開(kāi)始按系統(tǒng)模塊拆創(chuàng)建訂單、查詢訂單、修改訂單、刪除訂單一個(gè)個(gè)列得清清楚楚。但模型經(jīng)常選錯(cuò)。用戶說(shuō)“把這個(gè)訂單換成另一個(gè)規(guī)格”模型就不知道該調(diào)“修改”還是“刪除”還是“重新創(chuàng)建”因?yàn)橛脩舻谋磉_(dá)不會(huì)天然對(duì)齊你后端的模塊劃分。后來(lái)我把技能改成按用戶意圖拆換貨申請(qǐng)、取消訂單、物流查詢。這么一改模型的選擇一下子清晰了很多。我總結(jié)出來(lái)的標(biāo)準(zhǔn)是從用戶一句話里的“目的”出發(fā)而不是從系統(tǒng)的“功能”出發(fā)。你問(wèn)自己如果用戶說(shuō)“我想知道我的服務(wù)器最近狀態(tài)如何”他希望得到的是數(shù)據(jù)列表、告警通知還是操作入口這個(gè)希望對(duì)應(yīng)一個(gè)獨(dú)立動(dòng)作就拆成一個(gè)技能。粒度太細(xì)會(huì)導(dǎo)致模型面對(duì)一堆近義詞技能時(shí)選擇困難太粗又會(huì)導(dǎo)致一個(gè)技能內(nèi)部塞滿一堆分支邏輯維護(hù)成本暴增。我的實(shí)操經(jīng)驗(yàn)是一次用戶請(qǐng)求最多給模型呈現(xiàn) 15 個(gè)技能描述再多模型就開(kāi)始亂選。如果你的需求超過(guò) 15 個(gè)那就用 embedding 檢索先篩一遍而不是一股腦塞給模型。2.2 注冊(cè)表數(shù)據(jù)結(jié)構(gòu)以及模型如何“看到”技能技能注冊(cè)表其實(shí)就是一份結(jié)構(gòu)化的清單我直接用 Python 里的列表加字典來(lái)維護(hù)。每個(gè)技能的核心結(jié)構(gòu)長(zhǎng)這樣SKILLS [ { name: get_cvm_instance_list, description: 獲取騰訊云 CVM 實(shí)例列表。當(dāng)用戶想查看云服務(wù)器、實(shí)例、CPU、內(nèi)存、公網(wǎng) IP 等信息時(shí)使用。注意只負(fù)責(zé)查詢不負(fù)責(zé)創(chuàng)建或刪除實(shí)例。, parameters: { type: object, properties: { region: { type: string, description: 地域如 ap-guangzhou可選默認(rèn) ap-guangzhou }, limit: { type: integer, description: 返回的實(shí)例數(shù)量上限默認(rèn) 20, minimum: 1 } }, required: [] } }, { name: send_sms, description: 發(fā)送短信通知。當(dāng)用戶要求向指定手機(jī)號(hào)發(fā)送驗(yàn)證碼、通知或告警時(shí)使用。禁止用于發(fā)送營(yíng)銷或其他騷擾類內(nèi)容。, parameters: { type: object, properties: { phone: {type: string, description: 接收短信的手機(jī)號(hào)必須為 11 位數(shù)字}, content: {type: string, description: 短信內(nèi)容需匹配審核模板} }, required: [phone, content] } } ]這個(gè)注冊(cè)表要轉(zhuǎn)成大模型 API 能識(shí)別的tools格式我寫(xiě)了一個(gè)小函數(shù)做映射。關(guān)鍵點(diǎn)在于字段名和描述必須穩(wěn)定。我見(jiàn)過(guò)很多人把技能描述寫(xiě)得特別隨意結(jié)果模型才過(guò)一輪就忘了。正確做法是每次請(qǐng)求都把最新注冊(cè)表傳給模型不要只傳一次就讓模型“記住”。模型沒(méi)有記憶每一次用戶消息都要重新提供可選項(xiàng)。對(duì)于技能數(shù)量不多的項(xiàng)目全量注冊(cè)表就夠了。數(shù)量超過(guò) 20 個(gè)后我會(huì)先用標(biāo)題和描述做向量檢索拿出 top 8 到 10 個(gè)技能再傳給模型。這里有一個(gè)容易忽略的細(xì)節(jié)檢索用的是“技能描述文本”而不是“技能代碼”所以描述寫(xiě)得好不好直接影響檢索質(zhì)量。我踩過(guò)坑當(dāng)時(shí)一門(mén)心思優(yōu)化代碼忽略了描述文本結(jié)果很多技能模型根本沒(méi)被檢索到后來(lái)把描述統(tǒng)統(tǒng)重寫(xiě)一遍效果立竿見(jiàn)影。2.3 用 Redis 接管會(huì)話上下文順帶解決一個(gè)重啟故障Agent 的多輪對(duì)話不能只靠模型上下文窗口狀態(tài)必須落到外部存儲(chǔ)。我用騰訊云 Redis 存 session 上下文鍵是session_id值是序列化后的 JSON里面包含歷史消息摘要、最近一次技能執(zhí)行結(jié)果、用戶偏好等。這樣即使 Agent 服務(wù)重啟用戶也能接著上一輪繼續(xù)聊。Redis 在這里不是緩存而是真正的工作存儲(chǔ)所以我會(huì)給每個(gè)鍵設(shè)置合理的 TTL防止內(nèi)存無(wú)限膨脹。說(shuō)到 Redis我 must 分享一個(gè)真實(shí)事故。當(dāng)時(shí)我在云服務(wù)器上裝了 Redis修改了密碼之后重啟 Redis 服務(wù)一直不成功systemctl狀態(tài)顯示 failed但看服務(wù)日志又不像端口占用。最后還是通過(guò)journalctl -u redis看到了NOAUTH Authentication required的報(bào)錯(cuò)。我一度以為是新密碼沒(méi)有生效后來(lái)排查才發(fā)現(xiàn)是 systemd 的 override 文件里通過(guò)環(huán)境變量傳了一個(gè)舊密碼給啟動(dòng)腳本而客戶端連接時(shí)又用舊密碼去認(rèn)證自然過(guò)不去。解決辦法很簡(jiǎn)單把/etc/systemd/system/redis.service.d/override.conf里的密碼改成和redis.conf一致再systemctl daemon-reload重啟。這個(gè)經(jīng)驗(yàn)提醒我改密碼不是改一個(gè)文件就完事所有依賴 Redis 的服務(wù)都得同步檢查尤其是 Agent 的.env、LiteLLM 的配置、還有 systemd 里的啟動(dòng)參數(shù)。2.4 一份可以直接抄的技能注冊(cè)清單為了方便你起步我把一個(gè)真實(shí)項(xiàng)目里常用的技能清單簡(jiǎn)化后放在這里。它不一定適合所有業(yè)務(wù)但字段結(jié)構(gòu)和描述方式可以借鑒。技能名觸發(fā)場(chǎng)景入?yún)⒑蠖瞬僮鞒瑫r(shí)get_cvm_list用戶查詢?cè)品?wù)器、實(shí)例、公網(wǎng) IPregion, limit騰訊云 CVM DescribeInstances API3 秒get_monitor_data用戶查詢 CPU、內(nèi)存、磁盤(pán)監(jiān)控曲線instance_id, metric, start_time, end_time騰訊云云監(jiān)控 API3 秒send_sms用戶要求發(fā)驗(yàn)證碼、通知、告警phone, content騰訊云 SMS API5 秒upload_to_cos用戶上傳附件到對(duì)象存儲(chǔ)bucket, object_key, file_path騰訊云 COS SDK10 秒confirm_operation高風(fēng)險(xiǎn)操作前向用戶確認(rèn)operation, detail生成一次性確認(rèn)令牌2 秒這份清單里每個(gè)技能都必須有明確的后端實(shí)現(xiàn)不能只留一個(gè)空殼。我最開(kāi)始做的時(shí)候很多技能只有一個(gè)“占位符”返回 hardcode 的結(jié)果給模型。小程序演示沒(méi)問(wèn)題一上真實(shí)流量就露餡。所以我的建議是寧可只有 5 個(gè)真實(shí)可用的技能也不要規(guī)劃 20 個(gè)“看起來(lái)有用”但根本沒(méi)實(shí)現(xiàn)的技能。3. Agent 調(diào)度核心從消息到動(dòng)作的完整鏈路3.1 用函數(shù)調(diào)用協(xié)議把模型輸出變成可執(zhí)行動(dòng)作現(xiàn)在主流大模型 API 都支持函數(shù)調(diào)用也就是function calling。這比讓模型輸出 JSON、再自己寫(xiě)解析器要穩(wěn)定得多。做法很簡(jiǎn)單把技能注冊(cè)表映射成 API 的tools模型在合適的時(shí)機(jī)返回tool_calls。以下是我在 Agent 循環(huán)里最核心的一段調(diào)用邏輯response client.chat.completions.create( modelMODEL_NAME, messagesmessages, tools[{type: function, function: skill_to_tool(s)} for s in SKILLS], tool_choiceauto ) message response.choices[0].message if message.tool_calls: for tool_call in message.tool_calls: result execute_skill( tool_call.function.name, tool_call.function.arguments ) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) # 拿到技能結(jié)果后讓模型把結(jié)果“翻譯”成用戶能懂的話 messages.append(message) final_respond client.chat.completions.create( modelMODEL_NAME, messagesmessages, tools[{type: function, function: skill_to_tool(s)} for s in SKILLS], tool_choicenone ) return final_respond.choices[0].message.content我把這個(gè)循環(huán)封裝成一個(gè)run_agent_loop函數(shù)它的職責(zé)很純粹發(fā)消息給模型看模型要不要調(diào)用技能如果要就執(zhí)行然后把結(jié)果塞回去再讓模型繼續(xù)直到模型不再請(qǐng)求技能才把最終文本返回給用戶。這里最容易被忽略的是技能執(zhí)行結(jié)果一定要通過(guò)roletool傳回去而不是直接拼進(jìn) system prompt。我早期偷懶拼接結(jié)果模型經(jīng)?；煜凹寄芊祷氐臄?shù)據(jù)”和“用戶原話”邏輯混亂到?jīng)]法看。3.2 Skills 執(zhí)行器的健壯性設(shè)計(jì)執(zhí)行器是連接模型和后端動(dòng)作的中轉(zhuǎn)站如果它不夠健壯Agent 再聰明也白搭。我寫(xiě)的執(zhí)行器很簡(jiǎn)單但包含了幾條硬性規(guī)則SKILL_MAP {skill[name]: skill for skill in SKILLS} def execute_skill(name, arguments): skill SKILL_MAP.get(name) if not skill: return {success: False, error: no such skill} try: params json.loads(arguments) if isinstance(arguments, str) else arguments handler skill.get(handler) if not handler: return {success: False, error: handler not registered} result handler(**params) return {success: True, data: result} except TypeError as e: return {success: False, error: f參數(shù)錯(cuò)誤: {e}} except Exception as e: return {success: False, error: str(e)}規(guī)則有三條。第一每個(gè)技能必須有超時(shí)控制方法是在 handler 外層加一個(gè)functools.wraps裝飾器或者用asyncio.wait_for超時(shí)后立刻返回錯(cuò)誤不能讓技能調(diào)用卡死整個(gè) Agent 循環(huán)。第二返回給模型的結(jié)構(gòu)必須固定不管成功失敗都要包含success字段失敗時(shí)把錯(cuò)誤信息放在error字段。模型很擅長(zhǎng)把錯(cuò)誤信息翻譯成用戶友好的話但這需要結(jié)構(gòu)化輸入。第三對(duì)未知技能名和未知參數(shù)要寬容處理寧可返回錯(cuò)誤讓模型換一個(gè)技能也不要拋異常把整個(gè)進(jìn)程打掛。這里我還加入了“技能調(diào)用頻控”的概念。比如send_sms這樣的技能我會(huì)在 handler 里檢查同一個(gè)手機(jī)號(hào)在 60 秒內(nèi)是否已經(jīng)發(fā)過(guò)驗(yàn)證碼。如果是就直接返回success: false和提示文本防止用戶手賤連點(diǎn)導(dǎo)致短信費(fèi)用飆升。頻控邏輯我沒(méi)放在模型層因?yàn)槟Ｐ筒豢煽乇仨毞旁趫?zhí)行器或者云服務(wù)層。3.3 把騰訊云 API 封裝成 Skill一個(gè) CVM 實(shí)例查詢的例子下面是一個(gè)完整的技能實(shí)現(xiàn)示例。目標(biāo)很直接用戶問(wèn)“幫我查一下廣州區(qū)域的云主機(jī)列表”模型調(diào)用get_cvm_list執(zhí)行器去騰訊云查數(shù)據(jù)最后把實(shí)例 ID、名稱、IP、狀態(tài)返回給模型整理。from tencentcloud.common import credential from tencentcloud.common.profile.client_profile import ClientProfile from tencentcloud.common.profile.http_profile import HttpProfile from tencentcloud.cvm.v20170312 import cvm_client, models def get_cvm_list(regionap-guangzhou, limit20): # 密鑰從環(huán)境變量讀取不要硬編碼進(jìn)代碼 cred credential.Credential( os.environ[TENCENTCLOUD_SECRET_ID], os.environ[TENCENTCLOUD_SECRET_KEY] ) http_profile HttpProfile() http_profile.endpoint cvm.tencentcloudapi.com client_profile ClientProfile() client_profile.httpProfile http_profile client cvm_client.CvmClient(cred, region, client_profile) req models.DescribeInstancesRequest() req.Limit limit resp client.DescribeInstances(req) instances [] for item in resp.InstanceSet: instances.append({ instance_id: item.InstanceId, name: item.InstanceName, private_ip: item.PrivateIpAddresses[0] if item.PrivateIpAddresses else , public_ip: item.PublicIpAddresses[0] if item.PublicIpAddresses else , status: item.InstanceState, }) return instances然后把 handler 注冊(cè)進(jìn)技能字典skill_entry { name: get_cvm_list, description: 獲取騰訊云 CVM 實(shí)例列表。當(dāng)用戶想看云服務(wù)器、實(shí)例、公網(wǎng) IP、狀態(tài)時(shí)使用不支持創(chuàng)建或者刪除實(shí)例。, parameters: { type: object, properties: { region: {type: string, description: 地域如 ap-guangzhou}, limit: {type: integer, description: 返回?cái)?shù)量默認(rèn) 20} }, required: [] }, handler: get_cvm_list, } SKILLS.append(skill_entry)這套模式的通用性很強(qiáng)。不管你是查監(jiān)控、發(fā)短信、上傳文件還是操作數(shù)據(jù)庫(kù)核心邏輯都一樣模型填參數(shù)執(zhí)行器調(diào) SDK把結(jié)果轉(zhuǎn)成結(jié)構(gòu)體返回。這樣 Agent 不需要知道騰訊云 SDK 里面有多少種請(qǐng)求對(duì)象它只需要知道技能名和描述剩下的全部是確定性代碼。3.4 用 LiteLLM Proxy 統(tǒng)一模型入口降低遷移成本項(xiàng)目做到中期我開(kāi)始嫌直接調(diào)用各家模型 API 太麻煩。不同供應(yīng)商的模型請(qǐng)求格式、超時(shí)定義、錯(cuò)誤碼都不一樣每次換模型都要改一遍 Agent 代碼。后來(lái)我在騰訊云的云服務(wù)器上跑了一個(gè) LiteLLM Proxy把用的幾個(gè)模型全部統(tǒng)一成 OpenAI 兼容格式。Agent 只認(rèn)一個(gè)base_url底層是混元、千問(wèn)還是別的模型對(duì) Agent 透明。LiteLLM 的配置大概長(zhǎng)這樣model_list: - model_name: hunyuan-pro litellm_params: model: tencent/hunyuan-pro api_key: os.environ/HUNYUAN_API_KEY - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY啟動(dòng)之后Agent 的client只需要設(shè)置base_urlhttp://127.0.0.1:4000就能切換模型。這個(gè)組件對(duì)多 Agent 項(xiàng)目很有用尤其是你想對(duì)比不同模型做技能選擇的效果時(shí)一個(gè) Proxy 就能統(tǒng)一入口。它的一個(gè)隱藏坑是模型名稱配置錯(cuò)誤時(shí)會(huì)直接 401排查時(shí)需要看 Proxy 日志而不是只看 Agent 日志。還有一個(gè)和 Redis 類似的問(wèn)題如果 LiteLLM 所在服務(wù)需要連接 Redis 做緩存那么改 Redis 密碼后也要同步更新 LiteLLM 的環(huán)境變量否則全部請(qǐng)求都會(huì)報(bào)認(rèn)證錯(cuò)誤。這個(gè)我在 2.3 節(jié)已經(jīng)踩過(guò)了現(xiàn)在改密碼前會(huì)先列一張“依賴清單”。4. 部署到騰訊云容器鏡像、網(wǎng)關(guān)和實(shí)測(cè)排障4.1 Docker 鏡像構(gòu)建與推送到容器鏡像服務(wù)Agent 服務(wù)我用 Docker 打包。Dockerfile 寫(xiě)得非常簡(jiǎn)單但已經(jīng)能滿足大多數(shù)場(chǎng)景FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . ENV PYTHONUNBUFFERED1 CMD [python, main.py]本地構(gòu)建并推送到騰訊云容器鏡像服務(wù)時(shí)命令大概是這樣的docker build -t ccr.ccs.tencentyun.com/my-namespace/my-agent:latest . docker login ccr.ccs.tencentyun.com --username你的騰訊云賬號(hào)ID docker push ccr.ccs.tencentyun.com/my-namespace/my-agent:latest這里有一個(gè)非常實(shí)用的經(jīng)驗(yàn)云服務(wù)器和鏡像倉(cāng)庫(kù)選同一個(gè)地域然后用內(nèi)網(wǎng)地址推送速度比公網(wǎng)快很多也不容易因網(wǎng)絡(luò)超時(shí)失敗。推送完成后我直接在 CVM 上docker pull再啟動(dòng)。如果用的是騰訊云的容器服務(wù)或輕量云也可以在控制臺(tái)直接創(chuàng)建服務(wù)指定鏡像地址就行。我建議把鏡像打上帶版本號(hào)的 tag而不要只打latest。后期出問(wèn)題要回滾時(shí)你能明確知道線上跑的是哪一版代碼。4.2 API 網(wǎng)關(guān)作為 Skills 的統(tǒng)一出口Agent 服務(wù)如果只是本地跑那還叫演示。要真正接入 App、小程序或運(yùn)維平臺(tái)就要把接口暴露出去。我用騰訊云 API 網(wǎng)關(guān)作為統(tǒng)一入口后端指向運(yùn)行 Agent 的內(nèi)網(wǎng) IP 端口。網(wǎng)關(guān)負(fù)責(zé)了 TLS 證書(shū)、鑒權(quán)、限流和一部分安全防護(hù)Agent 服務(wù)本身可以保持在內(nèi)網(wǎng)環(huán)境不直接暴露到公網(wǎng)。API 網(wǎng)關(guān)在處理 Agent 這種對(duì)話式請(qǐng)求時(shí)有一點(diǎn)需要特別注意接口超時(shí)時(shí)間要設(shè)得足夠長(zhǎng)。大模型推理本身就有延遲Agent 循環(huán)還可能調(diào)用多個(gè)技能如果網(wǎng)關(guān)超時(shí)設(shè)成 10 秒很可能模型還沒(méi)回答完就被網(wǎng)關(guān)截?cái)?。我的做法是把同步?qǐng)求超時(shí)設(shè)在 60 秒以上同時(shí)在前端做流式輸出或者輪詢。如果你做的是實(shí)時(shí)流式 Agent網(wǎng)關(guān)還需要支持 WebSocket 或 SSE否則體驗(yàn)會(huì)很差。我這次項(xiàng)目走的是普通 HTTP 輪詢簡(jiǎn)單可靠夠用就好。4.3 實(shí)測(cè)中三個(gè)最隱蔽的坑第一個(gè)坑就是前面反復(fù)提到的 Redis 密碼不同步。我再補(bǔ)充一個(gè)細(xì)節(jié)如果你用了 systemd 管理 Redis除了 override.conf 之外還要看 Redis 主配置里的bind、protected-mode是否限制了內(nèi)網(wǎng)訪問(wèn)。Agent 服務(wù)在另一臺(tái)機(jī)器上要通過(guò)內(nèi)網(wǎng)連 Redis如果只改密碼沒(méi)改 bind會(huì)連接超時(shí)容易誤判成密碼錯(cuò)誤。排查順序我建議先從客戶端本地redis-cli -a 新密碼 ping試起再沿著服務(wù)端配置逐步查。第二個(gè)坑是技能內(nèi)部超時(shí)缺失。我一開(kāi)始只在執(zhí)行器外層做了一個(gè)全局超時(shí)結(jié)果某個(gè)技能內(nèi)部調(diào)用的第三方 API 卡住了 50 秒把整個(gè) Agent 循環(huán)拖死。后來(lái)我給每一個(gè) handler 單獨(dú)設(shè)置超時(shí)比如查詢類技能 3 秒發(fā)送類技能 5 秒文件上傳類 10 秒。這里沒(méi)有銀彈不同操作的成本和響應(yīng)時(shí)間完全不同必須按技能去調(diào)優(yōu)。第三個(gè)坑是并發(fā)重復(fù)執(zhí)行。用戶在網(wǎng)絡(luò)波動(dòng)時(shí)通常會(huì)對(duì)同一個(gè)操作點(diǎn)多次提交如果技能不是冪等的就會(huì)產(chǎn)生重復(fù)資源或者重復(fù)扣費(fèi)。我后來(lái)在 Redis 里放了一把簡(jiǎn)單的分布式鎖以request_id為 key使用SET NX EX 30保證同一個(gè)請(qǐng)求只執(zhí)行一次。第二次請(qǐng)求進(jìn)來(lái)時(shí)直接返回“該操作正在處理中”而不是再次觸發(fā)技能。就這么一個(gè)簡(jiǎn)單的鎖線上減少了很多重復(fù)告警。有一個(gè)細(xì)節(jié)這個(gè)request_id必須在入口層生成并且透?jìng)鞯剿屑寄苷{(diào)用中否則鎖就沒(méi)有意義。5. 從“能跑”到“好用”我給 Agent 定下的四條規(guī)矩5.1 限定能力域做“專才”而不是“全才”很多 Agent 項(xiàng)目失敗的原因不是能力不夠而是想做的事情太多。我的項(xiàng)目只保留了三類技能云資源查詢、消息通知、文件處理。用戶問(wèn)天氣、問(wèn)八卦、讓寫(xiě)詩(shī)Agent 會(huì)明確說(shuō)“這個(gè)我不會(huì)”。這不是在打壓 Agent 潛力而是減少模型在技能選擇上的錯(cuò)誤空間。技能列表越短模型的選擇準(zhǔn)確率越高用戶體驗(yàn)反而更好。我后來(lái)在 system prompt 里加了一句話“你是一個(gè)云資源運(yùn)維助理只處理與服務(wù)器、監(jiān)控、通知相關(guān)的任務(wù)其余問(wèn)題請(qǐng)禮貌拒絕?！闭w表現(xiàn)立刻穩(wěn)定下來(lái)?！叭堋边@個(gè)詞其實(shí)有另外一層含義不是所有話題都能聊而是在自己負(fù)責(zé)的領(lǐng)域內(nèi)任務(wù)完成的深度和可靠度足夠高。所以我建議你也先列出業(yè)務(wù)里最高頻的 10 個(gè)動(dòng)作把它們的準(zhǔn)確率打磨到 95% 以上再談增加新技能。半吊子的技能越多越容易干擾模型判斷。5.2 技能描述是寫(xiě)給模型看的不是寫(xiě)給人看的這是我在整個(gè)項(xiàng)目里收獲最大的一條經(jīng)驗(yàn)。當(dāng)初我把技能描述寫(xiě)成標(biāo)準(zhǔn)的接口文檔風(fēng)格比如“獲取云服務(wù)器實(shí)例列表返回 JSON 數(shù)組”模型照樣選錯(cuò)。后來(lái)我改成了用戶意圖導(dǎo)向的描述“當(dāng)用戶想查看云服務(wù)器、實(shí)例、CPU、內(nèi)存、公網(wǎng) IP 時(shí)使用當(dāng)用戶只是解釋概念時(shí)不要使用?！蹦Ｐ偷倪x擇準(zhǔn)確率明顯提升。區(qū)別在于前者描述的是“我能做什么”后者描述的是“用戶什么時(shí)候會(huì)想讓我做”。模型本質(zhì)上是在做意圖分類所以描述必須貼近真實(shí)用戶的表達(dá)而不是貼近開(kāi)發(fā)者的技術(shù)文檔習(xí)慣。我整理描述詞的時(shí)候會(huì)先用 50 條典型用戶語(yǔ)句跑一遍看哪些句子匹配錯(cuò)了技能然后針對(duì)錯(cuò)誤反過(guò)來(lái)改描述。比如用戶說(shuō)“我的機(jī)器是不是被攻擊了”我一開(kāi)始把它匹配到了“查詢實(shí)例列表”后來(lái)發(fā)現(xiàn)用戶其實(shí)是想要安全告警于是我把“查詢安全告警”技能的描述改成“當(dāng)用戶懷疑服務(wù)器被入侵、攻擊、異常登錄時(shí)使用”這個(gè)問(wèn)題就解決了。技能描述是需要持續(xù)迭代的數(shù)據(jù)資產(chǎn)千萬(wàn)別當(dāng)成一次性文檔。5.3 給拒絕路徑留好接口一個(gè)穩(wěn)定的 Agent一定要知道什么時(shí)候說(shuō)“不”。比如用戶說(shuō)“把生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)刪了吧”如果模型直接調(diào)用了一個(gè)帶刪除能力的技能后果不堪設(shè)想。我在系統(tǒng)里專門(mén)設(shè)計(jì)了一個(gè)confirm_operation技能。當(dāng)模型識(shí)別到高風(fēng)險(xiǎn)操作時(shí)先調(diào)用這個(gè)技能把一個(gè)二次確認(rèn)鏈接或者確認(rèn)碼發(fā)給用戶用戶確認(rèn)后技能才會(huì)返回允許繼續(xù)的信號(hào)。如果用戶沒(méi)有確認(rèn)后續(xù)執(zhí)行技能會(huì)直接失敗。這套機(jī)制的價(jià)值在于它把“人機(jī)共識(shí)”環(huán)節(jié)顯式化了。模型不需要自己判斷“這個(gè)請(qǐng)求是否危險(xiǎn)”它只需要判斷“這個(gè)請(qǐng)求屬于高風(fēng)險(xiǎn)類別”然后走確認(rèn)流程。我還在描述里寫(xiě)了明確的規(guī)則“涉及刪除、更新生產(chǎn)環(huán)境、發(fā)送短信、產(chǎn)生費(fèi)用等操作必須調(diào)用 confirm_operation 獲得用戶確認(rèn)后才能繼續(xù)。”這樣一來(lái)模型面對(duì)風(fēng)險(xiǎn)請(qǐng)求時(shí)就有了一個(gè)標(biāo)準(zhǔn)動(dòng)作而不是在回答里打嘴炮。5.4 可觀測(cè)性是 Agent 的第五項(xiàng)技能最后我想強(qiáng)調(diào)的是Agent 的調(diào)試比普通后端服務(wù)難得多。因?yàn)橥粋€(gè)用戶請(qǐng)求模型可能走不同的技能分支你很難直接從最終回答判斷它中間經(jīng)歷了什么。所以我在入口層生成一個(gè)全局trace_id然后把它塞進(jìn)所有日志、Redis 鍵、API 調(diào)用上下文里。騰訊云日志服務(wù)里按trace_id搜索就能看到一次完整請(qǐng)求的鏈路模型收到了什么消息、選了什么技能、參數(shù)是什么、技能返回了什么、模型最終怎么回復(fù)的。我在開(kāi)發(fā)階段幾乎每天都查日志。有一次 Agent 老是答非所問(wèn)打開(kāi)日志發(fā)現(xiàn)模型把“查詢 CPU 監(jiān)控”和“查詢實(shí)例列表”兩個(gè)技能都調(diào)用了然后把兩份數(shù)據(jù)混在一起用。發(fā)現(xiàn)問(wèn)題后我把兩個(gè)技能的描述邊界重新寫(xiě)清楚問(wèn)題立刻解決。沒(méi)有可觀測(cè)性這種問(wèn)題只能靠猜。我甚至做了一個(gè)簡(jiǎn)單的告警當(dāng)技能錯(cuò)誤率超過(guò) 10% 時(shí)日志服務(wù)會(huì)發(fā)消息通知我讓我能及時(shí)介入而不是等用戶來(lái)投訴。最后說(shuō)點(diǎn)個(gè)人體會(huì)。把一個(gè) Agent 養(yǎng)成“全能”的過(guò)程其實(shí)跟訓(xùn)練一個(gè)新人很像先給他劃定職責(zé)范圍把操作手冊(cè)寫(xiě)成他能看懂的樣子再給他準(zhǔn)備幾件稱手的工具然后盯著他的每一次操作錯(cuò)了就復(fù)盤(pán)。Skills 就是那本操作手冊(cè)和工具箱。騰訊云上這些組件沒(méi)什么魔法真正花時(shí)間的是把每個(gè)技能定義得足夠清楚把狀態(tài)、超時(shí)、冪等這些細(xì)節(jié)做扎實(shí)。我的建議是先在騰訊云上跑通一個(gè)最小閉環(huán)一個(gè)調(diào)度器、兩個(gè)技能、一個(gè) Redis、一個(gè)容器然后再慢慢加能力。你會(huì)發(fā)現(xiàn)自己培養(yǎng)出來(lái)的不是一個(gè)會(huì)聊天的模型而是一個(gè)真的能幫你干活的下屬。