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