1. 校園數(shù)字化為什么需要智能體而不是又一個App先拋一個我自己的觀察過去五年幾乎每所高校都在做“智慧校園”但真正被師生高頻使用的系統(tǒng)少得可憐。原因不復(fù)雜——傳統(tǒng)校園信息化的思路是“把線下流程搬到線上”于是有了教務(wù)App、后勤App、圖書館App、一卡通App每個App解決一個孤立的場景學生要辦事得先想“這事歸哪個部門管”再去翻對應(yīng)的入口。信息是數(shù)字化的但體驗是割裂的。YO Agent智能體要解決的正是這個割裂問題。它不是再做一個新App而是把校園里分散的服務(wù)能力封裝成一個個可被自然語言調(diào)用的“技能”由一個統(tǒng)一的智能體來理解意圖、編排任務(wù)、跨系統(tǒng)執(zhí)行。學生說一句“我下周要請假三天順便查下那幾天有沒有考試”智能體需要同時對接請假審批流、教務(wù)考試安排、輔導(dǎo)員通知三個系統(tǒng)最后給出一個合并后的答復(fù)。這才是“校園數(shù)字化新范式”的實質(zhì)從“人找服務(wù)”變成“服務(wù)找人”。這篇文章適合三類人看一是高校信息化部門的工程師正在評估智能體落地的可行性二是做教育行業(yè)產(chǎn)品的開發(fā)者想搞清楚校園場景下智能體和普通對話機器人的區(qū)別三是對智能體架構(gòu)感興趣的技術(shù)人想通過一個真實場景理解意圖識別、工具調(diào)用、多輪狀態(tài)管理這些概念怎么落地。我會盡量把架構(gòu)決策背后的“為什么”講透而不是只丟一堆名詞。需要提前說明的是下面涉及的具體實現(xiàn)細節(jié)部分是基于校園場景的常見工程實踐做的合理推演因為原始資料只給了標題和方向沒有給完整技術(shù)文檔。但推演的邏輯我會講清楚你可以對照自己學校的實際情況做調(diào)整。2. 拆解YO Agent的核心設(shè)計思路2.1 為什么選“智能體”而不是“超級App”很多人第一反應(yīng)是既然問題是入口太多那做一個超級App把所有功能集成進去不就行了這個思路在技術(shù)上可行但在校園場景里幾乎必然失敗。原因有三個。第一集成成本極高且不可持續(xù)。校園系統(tǒng)往往是不同廠商在不同年份建設(shè)的數(shù)據(jù)庫、接口協(xié)議、鑒權(quán)方式五花八門。做一個超級App意味著要把所有系統(tǒng)的接口重新對接一遍任何一個系統(tǒng)升級都可能讓集成層崩潰。而智能體的思路是“不搬數(shù)據(jù)只調(diào)能力”——通過工具調(diào)用Tool Calling的方式按需訪問各系統(tǒng)已有的接口耦合度低得多。第二需求是長尾的。學生的問題千奇百怪“幫我看看上學期績點夠不夠保研”“宿舍樓下那臺洗衣機現(xiàn)在有空位嗎”“補辦學生證要帶什么材料”。超級App的菜單結(jié)構(gòu)沒法窮舉這些組合但智能體可以通過意圖理解加工具編排來動態(tài)應(yīng)對。第三交互范式變了?，F(xiàn)在的大學生是伴隨著對話式交互長大的一代他們更習慣“說一句話”而不是“點五層菜單”。智能體天然適配這種交互習慣。所以YO Agent的定位不是替代現(xiàn)有系統(tǒng)而是在現(xiàn)有系統(tǒng)之上加一層“意圖理解與任務(wù)編排層”。這個定位決定了它的技術(shù)選型必須支持靈活的工具注冊機制、必須能處理多輪對話中的狀態(tài)、必須對校園專有名詞有足夠的理解能力。2.2 整體架構(gòu)的分層邏輯我把YO Agent的架構(gòu)理解成四層從下往上說。最底層是校園能力層也就是已有的教務(wù)、后勤、圖書館、一卡通等系統(tǒng)的API。這一層不需要大改只需要把關(guān)鍵能力包裝成標準化的工具描述工具名、參數(shù)、返回值說明注冊到智能體的工具庫里。第二層是工具編排層負責根據(jù)用戶意圖選擇合適的工具、填充參數(shù)、處理調(diào)用結(jié)果。這一層是智能體的“手腳”核心挑戰(zhàn)是工具選擇的準確性和多工具串聯(lián)時的參數(shù)傳遞。第三層是對話管理與狀態(tài)層維護多輪對話的上下文。比如用戶先說“我要請假”智能體問“請幾天”用戶說“三天”這個“三天”要能正確關(guān)聯(lián)到請假工具的時長參數(shù)上。這一層還負責處理意圖切換、話題回溯等復(fù)雜情況。最上層是交互層對接微信公眾號、企業(yè)微信、校園門戶、小程序等入口。學生從哪個入口進來都能獲得一致的體驗。這個分層的好處是每一層可以獨立演進。比如學校新上了一個系統(tǒng)只需要在能力層注冊新工具上層的編排邏輯不用動。又比如想換一個更強的底層模型只需要替換對話管理層的模型調(diào)用工具庫和交互層不受影響。2.3 和通用聊天機器人的本質(zhì)區(qū)別這里要特別說清楚一個容易混淆的點YO Agent和那種“問答式校園客服”不是一回事。問答式客服的本質(zhì)是“檢索加匹配”——把常見問題做成知識庫用戶問什么就匹配最相似的答案。它只能回答不能辦事。智能體的本質(zhì)是“理解加執(zhí)行”。它需要具備三個能力意圖識別用戶到底想干什么、任務(wù)規(guī)劃要完成這個意圖需要調(diào)用哪些工具、按什么順序、執(zhí)行與反饋調(diào)用工具、處理異常、把結(jié)果組織成自然語言回復(fù)。舉個例子。用戶問“我學生證丟了怎么辦”。問答式客服會返回一段“補辦流程說明”。而智能體應(yīng)該做的是識別出這是“補辦學生證”意圖調(diào)用“查詢補辦所需材料”工具再調(diào)用“查詢補辦地點和辦公時間”工具如果用戶表示要預(yù)約還要調(diào)用“預(yù)約辦理”工具。最后回復(fù)的是“你需要帶身份證和一張一寸照片到行政樓302本周三下午還有預(yù)約名額要幫你約嗎”。這就是回答和辦事的區(qū)別。3. 核心細節(jié)解析與實操要點3.1 意圖識別校園場景的特殊挑戰(zhàn)意圖識別是智能體的第一道關(guān)卡校園場景有幾個特殊難點。難點一是專有名詞多。每個學校都有自己的簡稱和黑話比如“三教”指第三教學樓、“大活”指大學生活動中心、“一卡通”可能叫“校園卡”也可能叫“飯卡”。通用模型對這些詞的理解能力有限需要做領(lǐng)域適配。難點二是意圖邊界模糊。學生說“我想換宿舍”這到底是“咨詢換宿舍政策”還是“提交換宿舍申請”需要結(jié)合上下文和用戶身份來判斷。如果這個學生之前已經(jīng)提交過申請那大概率是查詢進度如果是第一次提可能是咨詢政策。難點三是多意圖混合。一句話里可能包含多個意圖“幫我查下這學期還有幾門課沒修完順便看看下學期選課什么時候開始”。這需要做意圖拆分分別處理后再合并回復(fù)。實操上我建議的做法是先用通用模型做初步意圖分類再針對高頻意圖訓練輕量級的分類器做二次校驗。同時維護一個校園專有名詞詞典在意圖識別前做一次實體歸一化把“三教”統(tǒng)一映射成“第三教學樓”。這個詞典不需要很大覆蓋高頻的幾百個詞就夠用但效果提升很明顯。注意意圖識別不要追求一次到位。實際運行中允許智能體在置信度低的時候主動追問“你是想咨詢政策還是提交申請”比強行猜測然后做錯事要好得多。3.2 工具注冊把校園系統(tǒng)包裝成智能體能調(diào)用的能力工具注冊是智能體落地的關(guān)鍵工程環(huán)節(jié)。每個工具需要定義清楚四樣東西工具名、功能描述、參數(shù)schema、返回值說明。工具名要語義清晰比如query_exam_schedule比get_data_001好得多因為模型是靠工具名和描述來選擇工具的。功能描述要用自然語言寫清楚“這個工具能做什么、什么時候該用”這是模型做工具選擇的主要依據(jù)。參數(shù)schema要嚴格定義類型和必填項。比如請假工具的參數(shù)可能是start_date日期必填、end_date日期必填、reason字符串必填、course_ids數(shù)組選填表示受影響的課程。參數(shù)定義得越清晰模型填充參數(shù)的準確率越高。返回值說明容易被忽略但很重要。如果工具返回的是一堆原始JSON模型很難從中提取有用信息組織成自然語言。更好的做法是在工具層做一次結(jié)果格式化返回結(jié)構(gòu)化的、帶字段說明的數(shù)據(jù)。我踩過的一個坑是早期把工具描述寫得太簡略結(jié)果模型經(jīng)常選錯工具。后來把每個工具的描述擴充到兩三句話明確寫出“適用場景”和“不適用場景”工具選擇的準確率從七成左右提升到了九成以上。這個投入非常值得。3.3 多輪狀態(tài)管理讓對話不“斷片”多輪對話的狀態(tài)管理是很多智能體項目的薄弱環(huán)節(jié)。常見的問題是用戶在第一輪說了“我要請假”第二輪說了“三天”第三輪問“那幾天有課嗎”智能體就忘了前面在聊請假的事。解決思路是維護一個對話狀態(tài)對象記錄當前活躍的意圖、已收集的參數(shù)、待補充的參數(shù)。每一輪用戶輸入進來先判斷是延續(xù)當前意圖還是開啟新意圖。如果是延續(xù)就把新信息合并到已有參數(shù)里如果是新意圖就把舊意圖暫存等新意圖處理完再決定是否恢復(fù)。這里有個實用技巧給每個意圖設(shè)置一個“超時輪數(shù)”。比如請假意圖如果連續(xù)三輪沒有被提及就認為用戶已經(jīng)放棄從活躍狀態(tài)里移除。這樣可以避免狀態(tài)對象無限膨脹。另外參數(shù)收集要支持“槽位填充”的靈活順序。用戶可能先說時長再說開始日期也可能反過來甚至一次說全。智能體需要能處理任意順序的參數(shù)輸入而不是死板地按固定順序提問。3.4 容錯與降級校園場景不能“一問三不知”校園智能體面對的是真實用戶不能像實驗室demo那樣只處理理想情況。容錯設(shè)計要覆蓋幾個層面。工具調(diào)用失敗如果教務(wù)系統(tǒng)接口超時智能體不應(yīng)該直接報錯而應(yīng)該告訴用戶“教務(wù)系統(tǒng)暫時繁忙我先把你的請求記下來稍后重試”或者引導(dǎo)用戶走備用渠道。意圖識別失敗如果模型對用戶意圖的置信度低于閾值應(yīng)該主動澄清而不是瞎猜。澄清話術(shù)要具體比如“你是想查詢考試安排還是想申請緩考”而不是籠統(tǒng)的“我沒聽懂”。參數(shù)缺失如果用戶說“幫我請假”但沒給任何其他信息智能體應(yīng)該按優(yōu)先級逐個追問而不是一次性拋出所有問題。先問最關(guān)鍵的“請哪幾天”再問“什么原因”。越權(quán)訪問學生只能查自己的成績不能查別人的。這需要在工具層做權(quán)限校驗智能體在調(diào)用工具時攜帶用戶身份信息由工具層決定是否放行。智能體本身不應(yīng)該承擔權(quán)限判斷的邏輯否則容易出漏洞。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 從零搭建一個校園智能體的完整流程假設(shè)你現(xiàn)在要在一所學校落地類似YO Agent的智能體我建議按下面的順序推進。第一步場景盤點與優(yōu)先級排序。不要一上來就想著覆蓋所有場景。先把校園服務(wù)按“高頻程度”和“實現(xiàn)難度”兩個維度做個矩陣優(yōu)先做高頻且實現(xiàn)難度低的。通?！罢n表查詢”“成績查詢”“考試安排”“請假申請”“一卡通余額”這幾個是性價比最高的切入點。第二步工具接口梳理。針對選定的場景找到對應(yīng)的后端系統(tǒng)確認接口是否可用、鑒權(quán)方式是什么、返回數(shù)據(jù)格式是什么。如果某些系統(tǒng)沒有現(xiàn)成接口需要評估是推動對方開放接口還是用其他方式比如數(shù)據(jù)庫只讀視圖來獲取數(shù)據(jù)。第三步工具封裝與注冊。把接口包裝成智能體可調(diào)用的工具寫好工具名、描述、參數(shù)schema。這一步建議寫單元測試確保每個工具在給定參數(shù)下能正確返回結(jié)果。第四步對話流程設(shè)計。針對每個場景畫出理想的對話流程圖包括正常流程和異常分支。比如請假場景正常流程是“收集起止日期→收集原因→確認→提交”異常分支包括“日期格式不對”“請假天數(shù)超過限制”“審批人不在”等。第五步聯(lián)調(diào)與測試。用真實用戶可能說的各種表達方式來測試包括口語化表達、錯別字、多意圖混合等。記錄失敗案例迭代優(yōu)化意圖識別和工具選擇邏輯。第六步灰度發(fā)布與監(jiān)控。先在小范圍用戶中試用收集真實對話日志重點關(guān)注意圖識別準確率、工具調(diào)用成功率、用戶滿意度。根據(jù)數(shù)據(jù)持續(xù)優(yōu)化。4.2 關(guān)鍵參數(shù)的計算與選擇智能體落地過程中有幾個參數(shù)需要仔細權(quán)衡。意圖識別的置信度閾值。這個閾值決定了智能體什么時候自己處理、什么時候追問用戶。設(shè)得太高智能體會頻繁追問體驗很差設(shè)得太低智能體會經(jīng)常猜錯做錯事。我的經(jīng)驗值是對于“查詢類”意圖閾值可以設(shè)低一些比如0.6因為查錯了用戶能立刻發(fā)現(xiàn)并糾正對于“操作類”意圖比如提交申請、扣款閾值要設(shè)高一些比如0.85因為做錯了后果更嚴重。對話上下文的保留輪數(shù)。保留太多輪會消耗大量token且容易引入噪聲保留太少又會導(dǎo)致“斷片”。一般建議保留最近5到8輪對話同時對更早的對話做摘要壓縮。如果底層模型支持長上下文可以適當放寬但要注意成本和延遲。工具調(diào)用的超時時間。校園系統(tǒng)接口的響應(yīng)時間參差不齊有的很快有的很慢。建議給每個工具單獨設(shè)置超時時間查詢類工具可以設(shè)3到5秒操作類工具可以設(shè)10到15秒。超時后要有降級策略不能直接讓用戶干等。并發(fā)處理能力。開學季、選課季是校園系統(tǒng)的高峰期智能體的調(diào)用量會激增。需要評估后端系統(tǒng)的承載能力必要時在智能體層做限流和排隊。我見過一個案例智能體本身沒問題但因為它調(diào)用太頻繁把教務(wù)系統(tǒng)打掛了這個教訓要記住。4.3 一個完整的請假場景實現(xiàn)示例下面用請假場景串一遍完整流程讓你對智能體的工作方式有個具體感受。用戶輸入“我下周三要請假一天家里有事”。意圖識別識別出意圖是“請假申請”置信度0.92超過操作類閾值0.85進入?yún)?shù)收集流程。參數(shù)提取從輸入中提取到start_date為下周三、end_date為下周三一天、reason為“家里有事”。缺少的參數(shù)是course_ids受影響的課程但這個參數(shù)是選填的可以自動查詢。工具調(diào)用先調(diào)用query_course_schedule工具查詢下周三該用戶的課程安排發(fā)現(xiàn)有兩門課。然后調(diào)用submit_leave_application工具提交請假申請參數(shù)包括日期、原因、受影響課程。結(jié)果處理工具返回“申請已提交審批人為輔導(dǎo)員張老師預(yù)計24小時內(nèi)處理”。智能體組織回復(fù)“你的請假申請已提交下周三的兩門課高等數(shù)學、大學英語會標記為請假。審批人是輔導(dǎo)員張老師預(yù)計24小時內(nèi)處理。需要我?guī)湍惆颜埣贄l發(fā)給任課老師嗎”后續(xù)處理如果用戶說“好”智能體調(diào)用notify_teacher工具發(fā)送通知。如果用戶說“不用了”流程結(jié)束。這個流程看起來簡單但背后涉及意圖識別、參數(shù)提取、工具編排、結(jié)果組織、多輪跟進等多個環(huán)節(jié)。每個環(huán)節(jié)都需要仔細打磨。4.4 和現(xiàn)有系統(tǒng)的對接策略校園智能體不可能脫離現(xiàn)有系統(tǒng)獨立存在對接策略直接影響落地難度。對于有標準API的系統(tǒng)直接封裝成工具即可。需要注意的是鑒權(quán)智能體調(diào)用時需要攜帶用戶身份通常用OAuth或者JWT來實現(xiàn)。對于只有數(shù)據(jù)庫訪問權(quán)限的系統(tǒng)可以做一個只讀的數(shù)據(jù)訪問層把查詢封裝成工具。但寫操作要謹慎最好還是走應(yīng)用層的接口避免繞過業(yè)務(wù)邏輯。對于完全沒有接口的老系統(tǒng)可以考慮用RPA機器人流程自動化的方式模擬人工操作。但這種方式穩(wěn)定性差只適合作為過渡方案。對于多個系統(tǒng)需要協(xié)同的場景智能體的編排能力就體現(xiàn)出來了。比如“退宿”這個場景可能涉及后勤系統(tǒng)、財務(wù)系統(tǒng)、圖書館系統(tǒng)還書、一卡通系統(tǒng)退余額智能體可以按順序調(diào)用各個工具最后匯總結(jié)果。5. 常見問題與排查技巧實錄5.1 意圖識別不準怎么辦這是最常見的問題。排查思路是分層定位先看是模型能力問題還是數(shù)據(jù)問題。如果是模型對校園專有名詞不理解補充詞典和few-shot示例通常能解決。如果是意圖邊界模糊需要重新梳理意圖分類體系把容易混淆的意圖合并或者加更明確的區(qū)分特征。如果是訓練數(shù)據(jù)不足可以先用規(guī)則兜底同時積累真實對話數(shù)據(jù)用于后續(xù)優(yōu)化。一個實用技巧是把識別錯誤的案例收集起來每周做一次bad case復(fù)盤看看是共性問題還是個案。共性問題優(yōu)先解決個案可以暫時用兜底話術(shù)處理。5.2 工具調(diào)用失敗怎么降級工具調(diào)用失敗的原因很多網(wǎng)絡(luò)超時、接口變更、參數(shù)錯誤、權(quán)限不足。不同原因需要不同的降級策略。失敗原因降級策略用戶感知網(wǎng)絡(luò)超時重試一次仍失敗則告知稍后再試“系統(tǒng)繁忙請稍后再試”接口變更記錄日志觸發(fā)告警引導(dǎo)用戶走人工渠道“該功能暫時不可用請到XX窗口辦理”參數(shù)錯誤重新追問缺失或格式錯誤的參數(shù)“請確認日期格式比如2026-03-15”權(quán)限不足告知用戶無權(quán)限引導(dǎo)走授權(quán)流程“你暫時沒有權(quán)限請聯(lián)系輔導(dǎo)員開通”注意降級話術(shù)要具體不要用“系統(tǒng)錯誤”這種籠統(tǒng)表述。用戶需要知道下一步該做什么。5.3 多輪對話“斷片”怎么修斷片的根本原因是狀態(tài)管理沒做好。排查時先看對話狀態(tài)對象是否正確更新再看意圖切換邏輯是否合理。常見的一個bug是用戶在一個意圖中途切換到另一個意圖處理完新意圖后沒有正確恢復(fù)舊意圖。修復(fù)方法是在狀態(tài)對象里維護一個意圖棧新意圖入棧處理完后出棧恢復(fù)到上一個意圖。另一個常見問題是參數(shù)覆蓋。用戶先說“請假三天”后來說“從下周三開始”如果參數(shù)合并邏輯寫得不對可能會把“三天”覆蓋掉。正確的做法是區(qū)分“新增參數(shù)”和“修改參數(shù)”修改時需要明確用戶是在修正之前的輸入。5.4 性能與成本怎么平衡智能體的運行成本主要來自模型調(diào)用。如果每輪對話都調(diào)用大模型成本會很高。優(yōu)化思路有幾個。緩存高頻意圖對于“查課表”“查成績”這類高頻且答案相對固定的意圖可以緩存結(jié)果減少模型調(diào)用。分級處理簡單意圖用輕量模型或規(guī)則處理復(fù)雜意圖才調(diào)用大模型。比如“查余額”這種明確的操作用關(guān)鍵詞匹配就能識別不需要大模型。上下文壓縮對歷史對話做摘要只保留關(guān)鍵信息減少token消耗。異步處理對于不需要實時返回的操作比如提交申請后的通知可以異步處理不阻塞主對話流程。5.5 安全與隱私的底線校園智能體涉及學生個人信息安全是底線。幾個必須做到的點所有工具調(diào)用都要做權(quán)限校驗確保學生只能訪問自己的數(shù)據(jù)對話日志要脫敏存儲不能明文記錄敏感信息模型調(diào)用要評估數(shù)據(jù)合規(guī)性敏感數(shù)據(jù)不能傳給第三方模型要有審計機制記錄誰在什么時候調(diào)用了什么工具、返回了什么結(jié)果。我個人的經(jīng)驗是安全設(shè)計要在架構(gòu)階段就考慮不要等上線了再補。補安全措施的代價往往比一開始就設(shè)計好要高得多。6. 落地后的效果評估與持續(xù)迭代6.1 用什么指標衡量智能體好不好用上線只是開始持續(xù)運營才是關(guān)鍵。我建議關(guān)注四個維度的指標。任務(wù)完成率用戶發(fā)起的意圖中有多少被成功完成。這是最核心的指標直接反映智能體的實用價值。意圖識別準確率識別正確的意圖占總意圖的比例。這個指標影響任務(wù)完成率但更細粒度便于定位問題。平均對話輪數(shù)完成一個任務(wù)平均需要幾輪對話。輪數(shù)越少說明智能體越高效但也不能一味追求少該追問的時候還是要追問。用戶滿意度可以通過對話結(jié)束后的評分、投訴率、重復(fù)使用率來間接衡量。6.2 從數(shù)據(jù)中發(fā)現(xiàn)優(yōu)化機會對話日志是金礦。我習慣每周做一次日志分析重點看三類對話任務(wù)失敗的、輪數(shù)特別多的、用戶明顯不滿的。任務(wù)失敗的對話往往暴露工具調(diào)用或參數(shù)提取的問題。輪數(shù)特別多的對話可能是意圖識別不準或者追問策略有問題。用戶不滿的對話比如出現(xiàn)“不是”“你搞錯了”這類表述需要逐條看理解用戶的真實需求。一個實用做法是把失敗案例按原因分類統(tǒng)計每類原因的出現(xiàn)頻率優(yōu)先解決高頻問題。通常解決前三個高頻問題就能顯著提升整體效果。6.3 智能體的能力擴展路徑當基礎(chǔ)場景跑通后可以考慮擴展能力邊界。從單場景到跨場景比如把“請假”和“調(diào)課”打通學生請假后自動觸發(fā)調(diào)課流程。從被動響應(yīng)到主動服務(wù)比如檢測到學生即將錯過選課時間主動推送提醒。從個體服務(wù)到群體服務(wù)比如輔導(dǎo)員可以用智能體批量處理學生的常見問題提高工作效率。從校內(nèi)到校外比如對接實習就業(yè)信息、校友服務(wù)等擴展服務(wù)范圍。擴展時要保持架構(gòu)的靈活性新能力以工具的形式注冊進來不要破壞已有的編排邏輯。6.4 我踩過的幾個坑最后分享幾個實際踩過的坑希望能幫你少走彎路?？右贿^度依賴大模型。早期所有意圖都用大模型識別成本和延遲都很高。后來把高頻簡單意圖用規(guī)則處理成本降了一半以上響應(yīng)速度也快了很多。坑二工具描述寫得太技術(shù)化。一開始工具描述是給工程師看的用了很多技術(shù)術(shù)語結(jié)果模型選工具經(jīng)常出錯。后來改成用自然語言描述“這個工具能幫用戶做什么”準確率明顯提升。坑三忽視異常流程。demo階段只測了正常流程上線后發(fā)現(xiàn)大量異常情況沒處理比如用戶輸入亂碼、中途放棄、連續(xù)追問同一個問題。后來專門花時間梳理了異常分支體驗才穩(wěn)定下來?？铀臎]有做灰度。有一次直接全量上線新版本結(jié)果意圖識別邏輯有bug導(dǎo)致大量用戶請求被錯誤路由。后來改成先放量10%觀察一天沒問題再逐步擴大?？游宓凸懒诉\營工作量。以為上線就完事了實際上線后每天都要看日志、處理bad case、優(yōu)化話術(shù)。智能體是一個需要持續(xù)運營的產(chǎn)品不是一次性交付的項目。這些經(jīng)驗歸結(jié)成一句話校園智能體的難點不在技術(shù)而在對校園場景的理解和對真實用戶需求的把握。技術(shù)方案可以借鑒但場景理解必須自己下功夫。多和輔導(dǎo)員聊、多和學生聊、多泡在真實對話日志里比看一百篇論文都有用。