1. 為什么我把 Agent 的技能單獨(dú)拎出來做先說個(gè)背景。我手上有好幾個(gè) Agent 項(xiàng)目最早做的時(shí)候走了不少?gòu)澛?。起初的想法很?jiǎn)單把大模型的對(duì)話能力接上工具調(diào)用讓 Agent 能查天氣、能算數(shù)學(xué)、能調(diào)數(shù)據(jù)庫(kù)。但真正跑起來才發(fā)現(xiàn)模型輸出是概率性的同一個(gè)功能今天能用明天抽風(fēng)是常態(tài)更別提把工具邏輯、提示詞、參數(shù)校驗(yàn)、失敗重試全堆在一個(gè) Agent 工程里代碼很快就爛成一鍋粥。后來我梳理了一下問題就出在技能和Agent沒有分層。打個(gè)比方Agent 像一個(gè)廚師技能就是他的刀工、火候、調(diào)味手法。你不能讓廚師每次做菜的時(shí)候再去現(xiàn)學(xué)刀工那樣出菜質(zhì)量極不穩(wěn)定。正確做法是先把刀工練成肌肉記憶廚師只管根據(jù)菜單調(diào)配。這個(gè)肌肉記憶落到工程上就是 AI Skills。騰訊云的 AI Skills 本質(zhì)上是把 Agent 的一個(gè)完整能力閉環(huán)——從意圖識(shí)別、參數(shù)抽取、工具執(zhí)行到結(jié)果規(guī)整——封裝成獨(dú)立可復(fù)用的單元。它不只是簡(jiǎn)單的函數(shù)調(diào)用而是一套帶描述、帶輸入輸出協(xié)議、帶錯(cuò)誤處理策略的能力包。我最初在本地用 LangChain 搭過類似的東西但每次都要自己處理服務(wù)發(fā)現(xiàn)、鑒權(quán)、可觀測(cè)性、版本管理這些問題累得夠嗆。遷到騰訊云 AI Skills 之后這些基礎(chǔ)設(shè)施層面的活兒基本都能省掉我可以把精力集中在技能本身的邏輯打磨上。這篇文章就圍繞我在騰訊云上從零構(gòu)建全能 Agent的完整過程展開目標(biāo)是讓你看完之后能照著搭出一套自己的技能體系。會(huì)涉及技能怎么設(shè)計(jì)、Agent 怎么跟技能配合、服務(wù)怎么部署、上線后怎么調(diào)優(yōu)排障以及我在實(shí)測(cè)中踩過的那些文檔里不會(huì)寫的坑。先給一個(gè)整體視角一個(gè)完整的 Agent 項(xiàng)目在騰訊云上大概分四層——接入層負(fù)責(zé)對(duì)話與權(quán)限調(diào)度層負(fù)責(zé)意圖路由技能層負(fù)責(zé)具體能力執(zhí)行數(shù)據(jù)層負(fù)責(zé)記憶與狀態(tài)。AI Skills 落在第三層但它的設(shè)計(jì)質(zhì)量直接決定第二層能不能把意圖分清楚。所以這篇文章把重點(diǎn)放在技能層和它跟調(diào)度層的銜接上。2. 技能設(shè)計(jì)先想清楚三個(gè)問題再做很多人的做法是拿到需求就開始寫代碼結(jié)果技能做出來要么太寬泛什么都接不住要么太窄換個(gè)場(chǎng)景就廢了。我在動(dòng)手之前會(huì)先回答三個(gè)問題這三個(gè)問題基本決定了技能的邊界和質(zhì)量。2.1 這個(gè)技能的最小職責(zé)單元是什么技能不能貪大。我見過有人把一個(gè)文檔處理技能做成能讀取、轉(zhuǎn)換、摘要、翻譯、問答、對(duì)比的六合一模塊結(jié)果每個(gè)子功能都是半吊子意圖一多模型就糊涂。我的實(shí)踐是一個(gè)技能只解決一件事但這件事要做得深入。舉個(gè)例子如果 Agent 需要處理 Excel 報(bào)表我不會(huì)做一個(gè)通用的報(bào)表技能而是拆成報(bào)表數(shù)據(jù)校驗(yàn)報(bào)表指標(biāo)計(jì)算報(bào)表格式標(biāo)準(zhǔn)化報(bào)表異常標(biāo)注四個(gè)技能。每個(gè)技能只吃一種輸入、產(chǎn)一種輸出、只依賴一類工具。這樣做的直接好處是Agent 路由意圖時(shí)非常清晰模型只需要根據(jù)技能描述和輸入?yún)?shù)判斷調(diào)用哪個(gè)幾乎不會(huì)歧義。另一個(gè)隱藏好處是排障方便——某個(gè)技能出問題時(shí)影響面被局限在一個(gè)小模塊里不會(huì)拖垮整個(gè) Agent。2.2 技能的輸入輸出協(xié)議怎么定輸入輸出協(xié)議是技能設(shè)計(jì)的核心也是跟大模型交互的契約。騰訊云的 AI Skills 支持自定義參數(shù)結(jié)構(gòu)和返回結(jié)構(gòu)我的建議是參數(shù)盡量扁平類型盡量明確描述盡量帶示例。因?yàn)槟Ｐ妥鰠?shù)抽取時(shí)依賴的是參數(shù)名和描述文字描述里帶示例能大幅提升抽取準(zhǔn)確率。我當(dāng)時(shí)設(shè)計(jì)一個(gè)圖表生成技能時(shí)最初的參數(shù)結(jié)構(gòu)是嵌套的{ data: { xAxis: [一月, 二月], series: [ {name: 銷量, values: [100, 150]} ] }, chartType: bar, title: 月度銷量 }實(shí)測(cè)下來模型抽取這種嵌套結(jié)構(gòu)時(shí)經(jīng)常漏填或者填錯(cuò)層級(jí)成功率只有七成左右。后來我把參數(shù)結(jié)構(gòu)改成扁平化并給每個(gè)字段加了示例值{ series_names: [銷量, 利潤(rùn)], x_labels: [一月, 二月, 三月], series_values: [[100, 150, 130], [30, 45, 40]], chart_type: bar, title: 月度經(jīng)營(yíng)數(shù)據(jù) }成功率直接干到九成半以上。核心原因在于文本型大模型對(duì)平鋪的、自上而下填充字段這件事的把握度遠(yuǎn)高于遞歸地構(gòu)造嵌套對(duì)象。這個(gè)經(jīng)驗(yàn)我后來在多個(gè)技能里反復(fù)驗(yàn)證過結(jié)論一致。2.3 技能要不要帶狀態(tài)這是個(gè)容易被忽略的問題。技能默認(rèn)應(yīng)該是無狀態(tài)的——每次調(diào)用都是獨(dú)立的輸入、執(zhí)行、返回完事兒。但有些場(chǎng)景確實(shí)需要跨多次調(diào)用的狀態(tài)比如多輪對(duì)話里用戶先問我上個(gè)月電費(fèi)多少再問那這個(gè)月呢兩個(gè)問題如果被路由到同一個(gè)查詢技能模型需要知道這個(gè)月指的是哪個(gè)月份這其實(shí)是對(duì)話上下文的職責(zé)不應(yīng)該由技能自己記狀態(tài)。我的原則是技能本身不做記憶只接收上下文參數(shù)。如果 Agent 需要連續(xù)對(duì)話調(diào)度層負(fù)責(zé)維護(hù)會(huì)話上下文并把相關(guān)的歷史摘要作為參數(shù)傳給技能。這樣技能還是無狀態(tài)的但用戶體驗(yàn)上是有狀態(tài)的。這個(gè)分工特別重要否則技能一多狀態(tài)管理就會(huì)變成一場(chǎng)災(zāi)難。3. 在騰訊云上把技能跑起來從云端配置到本地聯(lián)調(diào)騰訊云的 AI Skills 功能在云端控制臺(tái)里就能完成技能的生命周期管理——?jiǎng)?chuàng)建、配置、發(fā)布、監(jiān)控。但我不建議直接在頁(yè)面上寫完所有東西更順滑的方式是本地開發(fā)調(diào)試好邏輯再同步到云端。這樣迭代速度快出問題也容易定位。3.1 創(chuàng)建技能的第一步描述文檔比代碼重要后端邏輯再完備如果技能描述文檔寫得稀爛Agent 也調(diào)不對(duì)。我把技能描述當(dāng)成跟大模型溝通的說明書寫清楚這幾個(gè)要素這個(gè)技能是干什么的一句話盡量包含動(dòng)作和對(duì)象什么情況下應(yīng)該調(diào)用它正例和反例都寫反例尤其重要輸入?yún)?shù)的定義和示例輸出的格式約定出錯(cuò)時(shí)可能返回的狀態(tài)碼和含義騰訊云控制臺(tái)里有一個(gè)技能描述編輯區(qū)支持 Markdown 格式。我強(qiáng)烈建議在這里寫一份結(jié)構(gòu)化描述不要隨手糊兩行。你花在描述上的時(shí)間會(huì)在線上意圖識(shí)別準(zhǔn)確率上十倍賺回來。我當(dāng)時(shí)寫在線查詢技能的描述反例部分幫了大忙。我寫的是本技能僅用于查詢不用于計(jì)算和匯總。若用戶詢問總計(jì)、平均值、同比增長(zhǎng)等計(jì)算類需求請(qǐng)調(diào)用【指標(biāo)計(jì)算】技能不要調(diào)用本技能。就這么一句話把查詢和計(jì)算兩類技能的誤調(diào)用率從 25% 壓到了不足 5%。3.2 本地腳手架用騰訊云 SDK 把技能邏輯跑通云端的技能函數(shù)最終是要被執(zhí)行引擎調(diào)用的對(duì)應(yīng)到代碼層面就是一個(gè)標(biāo)準(zhǔn)的 HTTP 服務(wù)接收技能請(qǐng)求參數(shù)執(zhí)行邏輯返回結(jié)構(gòu)化結(jié)果。我習(xí)慣用 Python FastAPI 寫這個(gè)服務(wù)框架。from fastapi import FastAPI, Request from pydantic import BaseModel from typing import List, Optional app FastAPI() class ExcelQueryRequest(BaseModel): sheet_id: str row_range: Optional[str] None filters: Optional[List[dict]] None class QueryResult(BaseModel): success: bool rows: Optional[List[dict]] None message: Optional[str] None error_code: Optional[str] None app.post(/excel/query, response_modelQueryResult) async def query_excel(req: ExcelQueryRequest): try: # 具體查詢邏輯連接騰訊云對(duì)象存儲(chǔ)、讀取 Excel、執(zhí)行過濾 result execute_query(req) return QueryResult(successTrue, rowsresult) except Exception as e: return QueryResult(successFalse, messagestr(e), error_codeQUERY_FAILED)這個(gè)腳手架有兩個(gè)好處一是本地起服務(wù)就能用 Postman 直接打接口測(cè)試不需要每次都推上云端二是后續(xù)把服務(wù)打包成容器鏡像推到騰訊云容器服務(wù)或者在云函數(shù)里托管都是同一套代碼遷移成本極低。3.3 聯(lián)調(diào)階段最容易忽略的鑒權(quán)問題騰訊云的 AI Skills 在遠(yuǎn)程調(diào)用技能時(shí)默認(rèn)會(huì)做身份校驗(yàn)。聯(lián)調(diào)時(shí)最常見的問題是配置了技能服務(wù)地址但請(qǐng)求一直返回 401 或者 403。原因不外乎兩類一類是簽名問題。云端調(diào)用時(shí)會(huì)在請(qǐng)求頭帶上簽名信息你的服務(wù)端必須用騰訊云提供的 SDK 或密鑰對(duì)簽名做校驗(yàn)。如果你只是想先聯(lián)調(diào)通建議先在技能配置里選開發(fā)模式該模式下云端會(huì)附帶一個(gè)調(diào)試用的憑證服務(wù)端拿這個(gè)憑證校驗(yàn)即可。另一類是網(wǎng)絡(luò)隔離問題。如果你的技能服務(wù)部署在私有網(wǎng)絡(luò)里云端執(zhí)行引擎訪問不到。解決辦法是把服務(wù)通過負(fù)載均衡暴露到云端可訪問的入口或者打通內(nèi)網(wǎng)通道。很多人在這一步卡一整天其實(shí)檢查一下安全組的入站規(guī)則、負(fù)載均衡的后端服務(wù)健康檢查是否通過就能找到問題。我當(dāng)時(shí)卡在健康檢查上——負(fù)載均衡配好了后端服務(wù)也起來了但技能調(diào)用還是報(bào)服務(wù)不可達(dá)。查了半天才發(fā)現(xiàn)是健康檢查路徑配錯(cuò)了我寫的是/healthFastAPI 默認(rèn)沒這個(gè)路由負(fù)載均衡判定后端不健康流量自然進(jìn)不來。4. Agent 與技能的協(xié)同路由、編排與上下文傳遞技能只是零件Agent 才是整機(jī)。技能設(shè)計(jì)得再完美如果 Agent 不知道怎么路由、不會(huì)編排多技能協(xié)作照樣發(fā)揮不出戰(zhàn)斗力。4.1 意圖路由的兩種策略各有適用場(chǎng)景訓(xùn)練 Agent 路由意圖業(yè)界基本是兩條路線基于模型分類和基于語義檢索?；谀Ｐ头诸愡m合意圖數(shù)量少10 個(gè)以內(nèi)、邊界清晰的場(chǎng)景。你可以讓大模型從技能列表里選一個(gè)返回這種方案實(shí)現(xiàn)簡(jiǎn)單但意圖一多模型容易混淆相近技能。基于語義檢索適合技能數(shù)量多、意圖邊界模糊的場(chǎng)景。把每個(gè)技能的描述向量化存入向量數(shù)據(jù)庫(kù)用戶請(qǐng)求先做向量檢索召回 Top3 技能再交給模型做精排。騰訊云的向量數(shù)據(jù)庫(kù)和 AI Skills 能直接打通不用自己維護(hù)整套檢索服務(wù)。我實(shí)際項(xiàng)目里技能超過 15 個(gè)之后純模型分類的準(zhǔn)確率明顯下降尤其是我上面提到的查詢和計(jì)算這類語義相近的技能。后來切到向量召回 模型精排的混合方案整體意圖路由準(zhǔn)確率提升了將近 20 個(gè)百分點(diǎn)而且新增技能只需更新向量索引舊技能完全不用動(dòng)。如果你的技能清單在持續(xù)生長(zhǎng)我建議一步到位用混合方案。4.2 多技能協(xié)作把順序依賴設(shè)計(jì)成顯式狀態(tài)機(jī)單技能調(diào)用好處理難的是多個(gè)技能協(xié)作完成一個(gè)復(fù)雜任務(wù)。比如分析上季度各區(qū)域銷售數(shù)據(jù)并生成可視化看板拆開就是查詢技能取數(shù) → 計(jì)算技能匯總 → 圖表技能畫圖 → 報(bào)告技能排版。我早期實(shí)現(xiàn)多技能協(xié)作是純提示詞驅(qū)動(dòng)讓大模型自己決定先調(diào)哪些技能。結(jié)果就是經(jīng)常漏調(diào)步驟或者數(shù)據(jù)還沒算完就開始畫圖最終輸出牛頭不對(duì)馬嘴。后來我改成顯式狀態(tài)機(jī)的方案Agent 維護(hù)一個(gè)任務(wù)狀態(tài)每完成一個(gè)技能就更新狀態(tài)下一個(gè)技能依賴前一個(gè)技能的產(chǎn)出。調(diào)度層根據(jù)狀態(tài)決定現(xiàn)在該調(diào)用哪個(gè)技能而不是讓模型自由發(fā)揮。這個(gè)改動(dòng)直接把我這邊的復(fù)雜任務(wù)成功率從四成拉到了八成以上。class ReportPipelineState: def __init__(self): self.current_step query self.steps { query: excel_query_skill, aggregate: metric_calc_skill, chart: chart_generate_skill, report: report_layout_skill, } def next_step(self): order list(self.steps.keys()) idx order.index(self.current_step) if idx len(order) - 1: self.current_step order[idx 1] return self.steps[self.current_step] return None這個(gè)設(shè)計(jì)模式說白了就是流水線每個(gè)技能是工位狀態(tài)機(jī)是傳送帶產(chǎn)品經(jīng)過一個(gè)工位處理完就流動(dòng)到下一個(gè)。缺點(diǎn)是需要預(yù)先定義好流水線的節(jié)拍和順序但好處是每一步都可觀測(cè)、可回滾、可重試對(duì)于生產(chǎn)環(huán)境來說這些特性比靈活性重要得多。4.3 上下文傳遞不要一股腦全塞給技能多技能協(xié)作必然涉及上下文傳遞。最常見的錯(cuò)誤是把所有歷史對(duì)話、中間數(shù)據(jù)全部拼到技能請(qǐng)求里導(dǎo)致請(qǐng)求體越來越大模型處理速度越來越慢費(fèi)用也越來越高。我的經(jīng)驗(yàn)是在傳給技能之前調(diào)度層先做上下文裁剪只保留當(dāng)前步驟必需的參數(shù)和上一步的可驗(yàn)證輸出摘要其余全部丟棄。比如圖表生成技能我就傳給它維度列表、指標(biāo)數(shù)值和圖表類型不傳對(duì)話歷史和用戶原話。這樣技能自己處理得干凈Agent 路由得也快。上下文傳遞有個(gè)要注意的細(xì)節(jié)技能 A 的輸出作為技能 B 的輸入時(shí)字段名必須對(duì)得上。騰訊云的技能描述里對(duì)輸入輸出字段做了很嚴(yán)格的類型約定如果技能 A 返回的是字符串型數(shù)字123技能 B 聲明接收整數(shù)型 123調(diào)度層需要做一次顯式類型轉(zhuǎn)換。我在調(diào)度層加了個(gè)字段映射的配置項(xiàng)避免每次更換技能都要改代碼。5. 上線后的問題排查與進(jìn)階調(diào)優(yōu)技能上線只是開始真正花時(shí)間的是上線后根據(jù)監(jiān)控反饋持續(xù)調(diào)優(yōu)。這里分享幾個(gè)我踩過的坑和反復(fù)驗(yàn)證有效的優(yōu)化手段。5.1 一次完整的排查鏈路從日志到根因有一次我發(fā)現(xiàn)某個(gè)技能的生產(chǎn)成功率從 95% 掉到了 80%界面上的錯(cuò)誤提示只有兩個(gè)字超時(shí)。直接看日志發(fā)現(xiàn)日志里技能執(zhí)行耗時(shí)在 15 秒到 30 秒不等而我配置的技能超時(shí)時(shí)間是 10 秒。第一反應(yīng)是后端服務(wù)變慢了。但看服務(wù)本身的監(jiān)控CPU、內(nèi)存都正常慢查詢也沒有。后來把日志粒度打到調(diào)用鏈級(jí)別才發(fā)現(xiàn)慢的不是我自己的邏輯而是技能里調(diào)用的下游 API 響應(yīng)變慢了——某個(gè)第三方接口從原來的平均 200ms 漲到了 8 秒。排查鏈路走到這里根因就清楚了第三方接口因?yàn)樯嫌捂溌窊矶马憫?yīng)時(shí)間出現(xiàn)長(zhǎng)尾。解決辦法是在技能代碼里給下游調(diào)用加超時(shí)熔斷from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10)) def call_downstream_api(data): response requests.post(DOWNSTREAM_URL, jsondata, timeout3) response.raise_for_status() return response.json()加上超時(shí)重試之后單個(gè)下游調(diào)用最多等 3 秒就失敗重試三次累計(jì)最長(zhǎng)等待約 15 秒。雖然沒有完全消除超時(shí)但至少不會(huì)再無限期等下去而且重試大概率能等到下游恢復(fù)。這個(gè)調(diào)整讓成功率回到了 93% 左右。剩余 2% 的失敗率主要是因?yàn)槟承┑谌浇涌诔掷m(xù) 10 秒以上不恢復(fù)這屬于上游的穩(wěn)定性問題不是我能完全解決的。這個(gè)案例給我的啟示是技能排查要有從請(qǐng)求入口到下游依賴的全鏈路追蹤能力否則你根本不知道時(shí)間花在哪個(gè)環(huán)節(jié)。騰訊云的自定義監(jiān)控和日志服務(wù)配合調(diào)用鏈追蹤基本能把每個(gè)技能的耗時(shí)打點(diǎn)做出來強(qiáng)烈建議早點(diǎn)把這塊配好別等出事再搭。5.2 Token 消耗優(yōu)化的三招實(shí)操Agent 跑起來之后成本大頭基本是模型調(diào)用。尤其是多技能協(xié)作場(chǎng)景每個(gè)步驟都要跟模型交互Token 消耗像流水一樣。我實(shí)測(cè)下來以下三個(gè)招數(shù)對(duì)降本立竿見影。第一招技能描述做精簡(jiǎn)。技能描述太長(zhǎng)會(huì)占用大量 Token而且模型處理冗長(zhǎng)描述時(shí)反而抓不住重點(diǎn)。我之前有個(gè)技能描述寫了 1200 字精簡(jiǎn)到 400 字之后每次調(diào)用的 Token 消耗直接少了三分之一意圖識(shí)別準(zhǔn)確率反而還升了。精簡(jiǎn)的原則是保留調(diào)用場(chǎng)景、參數(shù)示例、反例砍掉各種跟調(diào)用決策無關(guān)的背景介紹。第二招模型分級(jí)調(diào)用。不是所有技能調(diào)用都需要最強(qiáng)的模型。我配了模型路由簡(jiǎn)單技能如格式轉(zhuǎn)換、字段抽取用更快更便宜的模型復(fù)雜技能如多條件檢索、報(bào)告生成用強(qiáng)模型。粗算一下這招能省下 20% 到 30% 的調(diào)用成本。第三招結(jié)果緩存。對(duì)確定性輸出的技能比如查詢歷史統(tǒng)計(jì)數(shù)據(jù)、獲取靜態(tài)配置加上一層 Redis 緩存相同參數(shù)的請(qǐng)求直接命中緩存。我這邊幾個(gè)高頻查詢技能加了緩存之后調(diào)用量減少了將近一半后端壓力也小了兩全其美。5.3 技能安全輸入校驗(yàn)和敏感信息治理Agent 的每個(gè)技能入口本質(zhì)上就是一個(gè)可被外部請(qǐng)求觸發(fā)的 API。安全這塊我在上線前重新過了一遍重點(diǎn)是兩點(diǎn)。第一點(diǎn)是輸入校驗(yàn)。騰訊云不太希望你技能里出現(xiàn)任意代碼執(zhí)行或者超長(zhǎng)文本注入所以我自己額外加了輸入白名單和長(zhǎng)度限制。所有技能入口都做兩輪校驗(yàn)第一輪是結(jié)構(gòu)校驗(yàn)字段類型、枚舉值、長(zhǎng)度必須符合協(xié)議第二輪是語義校驗(yàn)比如日期必須晚于 2020 年、金額不能為負(fù)數(shù)。這樣就算大模型被用戶提示詞帶偏了技能層面也能兜底。第二點(diǎn)是敏感信息治理。Agent 在調(diào)用技能時(shí)可能會(huì)在日志中記錄業(yè)務(wù)數(shù)據(jù)這些數(shù)據(jù)里可能混有用戶隱私或內(nèi)部業(yè)務(wù)信息。我做的配置是日志脫敏匹配手機(jī)號(hào)、身份證號(hào)、銀行賬號(hào)、密鑰的字段在落盤前打星號(hào)。這個(gè)配置在騰訊云的日志服務(wù)里可以直接設(shè)置不用自己改代碼。6. 我養(yǎng)成的全能 Agent最終長(zhǎng)什么樣說了這么多方法論最后用一個(gè)實(shí)際的工程快照收尾。我的這個(gè) Agent 上線跑了快三個(gè)月目前接了 23 個(gè)技能覆蓋數(shù)據(jù)查詢、統(tǒng)計(jì)分析、圖表生成、報(bào)告撰寫、信息檢索、任務(wù)提醒六大類。架構(gòu)上是典型的接入層 調(diào)度層 技能層 數(shù)據(jù)層四層結(jié)構(gòu)。接入層是微信公眾號(hào)和網(wǎng)頁(yè)端兩個(gè)入口共用一套鑒權(quán)和會(huì)話管理。調(diào)度層用的就是前面說的向量召回 模型精排混合路由配合顯式狀態(tài)機(jī)做多技能編排。技能層跑在騰訊云容器服務(wù)上每個(gè)技能獨(dú)立部署、獨(dú)立伸縮技能之間互不影響。數(shù)據(jù)層用的騰訊云數(shù)據(jù)庫(kù)存會(huì)話記憶和技能執(zhí)行記錄Redis 做結(jié)果緩存。上線以來我監(jiān)控了幾個(gè)核心指標(biāo)意圖路由準(zhǔn)確率做到了 92%技能執(zhí)行成功率做到了 94%端到端平均響應(yīng)時(shí)長(zhǎng)控制在 3 秒以內(nèi)。這個(gè)結(jié)果肯定不算完美但已經(jīng)能穩(wěn)定支撐日常業(yè)務(wù)使用?；仡^看整個(gè)搭建過程我最深的體會(huì)是Agent 的能力邊界不是模型決定的是技能體系的完善度決定的。模型再聰明沒有扎實(shí)的技能支撐就像一個(gè)智商很高但沒有任何生活經(jīng)驗(yàn)的人聊什么都頭頭是道真讓他干點(diǎn)實(shí)事就露餡了。技術(shù)選型上如果你已經(jīng)決定用騰訊云生態(tài)那 AI Skills 幾乎是必選項(xiàng)——它跟賬號(hào)體系、日志、監(jiān)控、容器服務(wù)之間的打通能省下大量自研中間件的時(shí)間。如果你還在觀望我的建議是先拿一兩個(gè)業(yè)務(wù)場(chǎng)景做試點(diǎn)把技能設(shè)計(jì)和意圖路由這兩塊的感覺找到再逐步擴(kuò)大技能清單。這套方法論即使以后換平臺(tái)核心思路也是通用的。