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