1. 從單Agent到多Agent我們?yōu)楹我胺艞墶痹贏I驅(qū)動(dòng)的3D建模領(lǐng)域單Agent方案曾是我們的起點(diǎn)也是很多團(tuán)隊(duì)的舒適區(qū)。一個(gè)模型一個(gè)任務(wù)邏輯清晰調(diào)試簡(jiǎn)單。我們?cè)缙诘腍iCAD 2.0版本就是典型的單Agent架構(gòu)輸入一段自然語言描述比如“設(shè)計(jì)一個(gè)帶圓角的長(zhǎng)方體底座上面有一個(gè)圓柱形支柱”模型會(huì)嘗試?yán)斫獠⒅苯由蓪?duì)應(yīng)的3D建模指令序列。聽起來很美好對(duì)吧但實(shí)際跑起來準(zhǔn)確率就像過山車時(shí)高時(shí)低尤其是在處理復(fù)雜、多約束的建模任務(wù)時(shí)成功率很難穩(wěn)定突破70%。問題出在哪里我們花了大量時(shí)間復(fù)盤。一個(gè)核心發(fā)現(xiàn)是3D建模是一個(gè)高度結(jié)構(gòu)化、多步驟、強(qiáng)邏輯依賴的復(fù)合任務(wù)。它不像圖像生成那樣是“一錘子買賣”。一個(gè)簡(jiǎn)單的杯子就包含了草圖繪制、輪廓約束、拉伸/旋轉(zhuǎn)成型、倒角/圓角處理、抽殼等多個(gè)子步驟。讓一個(gè)“全能型”Agent去同時(shí)處理幾何理解、空間關(guān)系推理、參數(shù)計(jì)算、操作順序規(guī)劃就像讓一個(gè)程序員同時(shí)寫前端、后端、算法和運(yùn)維腳本雖然可能有人能做到但效率和出錯(cuò)率是硬傷。具體來說單Agent方案的瓶頸體現(xiàn)在三個(gè)層面注意力分散與任務(wù)混淆模型在理解“創(chuàng)建一個(gè)半徑為50mm高度為100mm的圓柱并在其一端創(chuàng)建一個(gè)深10mm的M6螺紋孔”時(shí)需要同時(shí)識(shí)別幾何實(shí)體圓柱、參數(shù)半徑、高度、布爾操作打孔、以及特定工藝特征螺紋。在生成長(zhǎng)序列指令時(shí)模型很容易在某個(gè)環(huán)節(jié)“分心”例如把螺紋孔的深度參數(shù)錯(cuò)誤地關(guān)聯(lián)到圓柱高度上或者忘記了先執(zhí)行“打孔”再執(zhí)行“螺紋”的順序。錯(cuò)誤傳播與累積3D建模步驟環(huán)環(huán)相扣。第一步草圖繪制如果定位有1mm的偏差后續(xù)所有基于此草圖的特征都會(huì)放大這個(gè)錯(cuò)誤。單Agent方案一旦在早期產(chǎn)生一個(gè)細(xì)微的誤解這個(gè)錯(cuò)誤會(huì)像滾雪球一樣貫穿整個(gè)生成過程導(dǎo)致最終模型完全偏離預(yù)期且調(diào)試起來異常困難你很難定位是哪個(gè)“思維環(huán)節(jié)”出了錯(cuò)。專業(yè)知識(shí)難以深度融合3D建模涉及大量領(lǐng)域知識(shí)如工程制圖標(biāo)準(zhǔn)、制造工藝約束最小壁厚、拔模角、裝配關(guān)系等。我們希望HiCAD不止能“畫出來”還要能“畫得對(duì)”、“畫得好”。試圖將所有專業(yè)知識(shí)壓縮進(jìn)一個(gè)模型的提示詞Prompt或通過微調(diào)讓一個(gè)模型掌握全部會(huì)導(dǎo)致知識(shí)沖突和遺忘模型表現(xiàn)會(huì)變得不穩(wěn)定。所以“放棄”單Agent不是否定其價(jià)值而是在特定問題復(fù)雜度下的必然選擇。當(dāng)任務(wù)可以被清晰地分解為多個(gè)專業(yè)子任務(wù)且子任務(wù)間存在明確的輸入輸出關(guān)系時(shí)多Agent分工協(xié)作的架構(gòu)優(yōu)勢(shì)就凸顯出來了。這就像從“手工作坊”升級(jí)到“現(xiàn)代化流水線”每個(gè)工位Agent只專注于自己最擅長(zhǎng)的環(huán)節(jié)通過一套精密的調(diào)度系統(tǒng)編排框架串聯(lián)起來最終實(shí)現(xiàn)效率與質(zhì)量的躍升。2. HiCAD 3.0 的核心架構(gòu)Harness 如何扮演“總指揮”確定了多Agent的方向下一個(gè)關(guān)鍵問題是如何讓多個(gè)Agent高效、可靠地協(xié)同工作這就是引入編排Orchestration框架的必要性。我們?cè)u(píng)估了多個(gè)方案最終選擇了Harness作為HiCAD 3.0的“中央神經(jīng)系統(tǒng)”。它不是唯一的選項(xiàng)但它的設(shè)計(jì)哲學(xué)與我們的需求高度契合。為什么是Harness市面上常見的多Agent協(xié)作模式有基于LangChain的簡(jiǎn)單鏈?zhǔn)秸{(diào)用或者更復(fù)雜的AutoGen等框架。Harness吸引我們的核心在于它對(duì)復(fù)雜工作流Workflow的原生支持和對(duì)狀態(tài)管理的精細(xì)化控制。LangChain更適合構(gòu)建清晰的、順序執(zhí)行的鏈Chain但在處理3D建模這種帶有大量條件分支“如果這里是通孔則...否則...”、循環(huán)“陣列這個(gè)特征5次”以及異?；赝恕吧弦徊讲紶栠\(yùn)算失敗嘗試替代方案”的場(chǎng)景時(shí)表達(dá)起來會(huì)顯得笨拙代碼可讀性和可維護(hù)性下降。AutoGen提供了強(qiáng)大的多Agent對(duì)話能力但對(duì)于需要嚴(yán)格步驟控制、結(jié)構(gòu)化數(shù)據(jù)傳遞的生產(chǎn)級(jí)任務(wù)流其對(duì)話式的松散耦合有時(shí)會(huì)引入不確定性。Harness則采用了“工作流即代碼”的理念。它將整個(gè)3D建模任務(wù)定義為一個(gè)有向無環(huán)圖DAG圖中的每個(gè)節(jié)點(diǎn)是一個(gè)專業(yè)化Agent邊代表了數(shù)據(jù)流和依賴關(guān)系。這讓我們可以直觀地設(shè)計(jì)和監(jiān)控整個(gè)建模過程。HiCAD 3.0 的Harness工作流設(shè)計(jì)在我們的架構(gòu)中一個(gè)典型的建模工作流被分解為以下幾個(gè)核心Agent節(jié)點(diǎn)2.1 自然語言理解與任務(wù)規(guī)劃 Agent (NLU Planner Agent)這是工作流的起點(diǎn)。它接收用戶的自然語言描述例如“請(qǐng)?jiān)O(shè)計(jì)一個(gè)連接板中間有一個(gè)φ20的通孔四角有4個(gè)φ8的沉頭孔用于安裝板材厚度10mm?！甭氊?zé)進(jìn)行深度語義解析識(shí)別出所有幾何實(shí)體、尺寸參數(shù)、約束關(guān)系同心、平行等、特征類型拉伸、切除、孔、倒角等以及工藝要求通孔、沉頭。輸出一個(gè)結(jié)構(gòu)化的任務(wù)計(jì)劃清單。這個(gè)清單不是最終的CAD命令而是一個(gè)高級(jí)別的、順序化的操作列表。例如創(chuàng)建基準(zhǔn)面Top Plane。在該面上繪制一個(gè)矩形草圖長(zhǎng)寬待參數(shù)Agent確定完全定義。拉伸草圖厚度10mm生成基體。在基體上表面中心創(chuàng)建草圖點(diǎn)生成φ20的通孔特征。在基體四角創(chuàng)建草圖點(diǎn)生成φ8的沉頭孔特征深度、角度待參數(shù)Agent確定。技術(shù)實(shí)現(xiàn)我們基于微調(diào)后的Code Llama或DeepSeek-Coder構(gòu)建此Agent重點(diǎn)強(qiáng)化其對(duì)于工程圖紙語言的理解能力和步驟分解的邏輯性。2.2 幾何與參數(shù)解析 Agent (Geometry Parameter Agent)這個(gè)Agent接收任務(wù)計(jì)劃清單。它的核心工作是“填空”將模糊的描述轉(zhuǎn)化為精確的、可計(jì)算的數(shù)值和幾何關(guān)系。職責(zé)參數(shù)計(jì)算如果用戶說“四角有4個(gè)孔”它會(huì)根據(jù)矩形板的尺寸自動(dòng)計(jì)算出四個(gè)角點(diǎn)的精確坐標(biāo)。如果用戶說“沉頭孔”它會(huì)根據(jù)標(biāo)準(zhǔn)件庫或默認(rèn)規(guī)則補(bǔ)充出沉頭直徑、深度、角度等未明說的參數(shù)。約束推理“中間的孔”會(huì)被解析為與矩形中心同心約束?！坝糜诎惭b的孔”可能會(huì)被自動(dòng)添加“螺紋”或“過盈配合”的標(biāo)記傳遞給下游Agent。幾何可行性檢查初步判斷參數(shù)是否合理例如孔的直徑是否大于板厚導(dǎo)致無法生成通孔。輸出一個(gè)參數(shù)化、完全定義的草圖與特征描述集。每個(gè)草圖都有確定的尺寸、每個(gè)特征都有明確的類型和參數(shù)。技術(shù)實(shí)現(xiàn)這個(gè)Agent集成了符號(hào)計(jì)算和幾何推理引擎。我們使用了OpenCASCADE的內(nèi)核進(jìn)行一些底層的幾何關(guān)系驗(yàn)證同時(shí)用一個(gè)輕量級(jí)的規(guī)則引擎來處理參數(shù)推理邏輯。2.3 CAD 指令生成 Agent (CAD Command Agent)這是將抽象計(jì)劃轉(zhuǎn)化為具體行動(dòng)的關(guān)鍵環(huán)節(jié)。它接收參數(shù)化描述集。職責(zé)根據(jù)目標(biāo)CAD平臺(tái)如SolidWorks, Fusion 360, Onshape API生成對(duì)應(yīng)的、可執(zhí)行的API調(diào)用序列或腳本如Python宏。輸出一段針對(duì)特定CAD軟件的、無歧義的指令代碼。例如對(duì)于Fusion 360可能是調(diào)用adsk.fusionAPI創(chuàng)建草圖、繪制矩形、添加尺寸約束、執(zhí)行拉伸命令的Python腳本。技術(shù)實(shí)現(xiàn)我們?yōu)槊總€(gè)支持的CAD平臺(tái)訓(xùn)練了一個(gè)專門的代碼生成模型。這個(gè)模型的訓(xùn)練數(shù)據(jù)是“參數(shù)化描述”到“CAD API代碼”的配對(duì)數(shù)據(jù)。由于輸入已經(jīng)是結(jié)構(gòu)化的大大降低了代碼生成的難度和錯(cuò)誤率。2.4 仿真驗(yàn)證與優(yōu)化 Agent (Simulation Validation Agent)這是我們的“質(zhì)量檢查員”。在指令生成后、正式提交給CAD軟件前它會(huì)被觸發(fā)。職責(zé)語法與邏輯校驗(yàn)檢查生成的代碼是否有語法錯(cuò)誤API調(diào)用順序是否合理。輕量級(jí)幾何驗(yàn)證通過調(diào)用一個(gè)“無頭模式”Headless的CAD內(nèi)核或簡(jiǎn)化仿真器快速執(zhí)行生成的指令檢查是否能成功生成實(shí)體是否存在自相交、零厚度等幾何錯(cuò)誤。設(shè)計(jì)規(guī)則檢查DRC驗(yàn)證模型是否符合預(yù)設(shè)的規(guī)則如最小壁厚、最小孔徑、是否存在銳邊等。輸出驗(yàn)證報(bào)告。如果通過工作流繼續(xù)如果失敗報(bào)告會(huì)包含錯(cuò)誤類型和可能出錯(cuò)的步驟并將問題反饋給上游的Planner或Parameter Agent進(jìn)行自動(dòng)重規(guī)劃Re-planning。技術(shù)實(shí)現(xiàn)結(jié)合靜態(tài)代碼分析和一個(gè)容器化的、輕量級(jí)CAD內(nèi)核如Open CASCADE的TKCAF模塊來實(shí)現(xiàn)快速仿真。DRC規(guī)則用YAML文件配置易于擴(kuò)展。Harness的核心價(jià)值就在于它優(yōu)雅地管理了上述所有Agent的生命周期、執(zhí)行順序、數(shù)據(jù)傳遞和異常處理。它允許我們定義只有當(dāng)NLU Agent成功輸出計(jì)劃后Parameter Agent才會(huì)啟動(dòng)Parameter Agent和CAD Command Agent可以并行處理多個(gè)獨(dú)立特征Simulation Agent失敗后可以自動(dòng)觸發(fā)一個(gè)預(yù)設(shè)的“修復(fù)子流程”或者通知人工干預(yù)。這種顯式的、可視化的編排使得整個(gè)系統(tǒng)的可觀測(cè)性、可調(diào)試性得到了質(zhì)的提升。3. 多Agent協(xié)同下的30%準(zhǔn)確率提升從何而來數(shù)字不會(huì)說謊30%的準(zhǔn)確率提升是經(jīng)過大量基準(zhǔn)測(cè)試Benchmark驗(yàn)證的結(jié)果。這里的“準(zhǔn)確率”我們定義為對(duì)于給定的自然語言描述系統(tǒng)能生成一個(gè)幾何正確無錯(cuò)誤、語義匹配符合描述、可直接用于下游流程如仿真、制造的3D模型的成功率。那么這30%具體是怎么來的3.1 分而治之帶來的專業(yè)化紅利這是最直接的收益。每個(gè)Agent只需要專注于一個(gè)相對(duì)狹窄的子任務(wù)因此我們可以用更精準(zhǔn)的數(shù)據(jù)對(duì)它進(jìn)行微調(diào)或設(shè)計(jì)更有效的提示工程。NLU Agent我們不再需要它懂CAD API語法只需全力提升其從工程語言中提取意圖和結(jié)構(gòu)的能力。我們使用了大量公開的工程圖紙說明書和維修手冊(cè)進(jìn)行微調(diào)使其對(duì)“沉頭孔”、“退刀槽”、“加強(qiáng)筋”等術(shù)語的理解遠(yuǎn)超通用大模型。CAD Command Agent它的輸入是干凈的、結(jié)構(gòu)化的參數(shù)描述因此生成正確API代碼的任務(wù)變得像“翻譯”一樣直接。我們?yōu)椴煌珻AD軟件準(zhǔn)備了高質(zhì)量的“描述-代碼”配對(duì)數(shù)據(jù)集訓(xùn)練出的模型在代碼生成準(zhǔn)確率上比單Agent時(shí)代提高了40%以上。這種專業(yè)化避免了“知識(shí)干擾”。在單Agent中關(guān)于“螺紋標(biāo)注規(guī)范”的知識(shí)可能會(huì)干擾它對(duì)“草圖輪廓”的判斷。在多Agent中這些知識(shí)被隔離在相應(yīng)的Agent里各司其職。3.2 閉環(huán)驗(yàn)證與自動(dòng)糾錯(cuò)機(jī)制在單Agent流程中生成即結(jié)束對(duì)錯(cuò)全靠最終輸出結(jié)果判斷調(diào)試是黑盒。而在Harness編排的多Agent流程中我們嵌入了多個(gè)驗(yàn)證和反饋環(huán)節(jié)形成了設(shè)計(jì)閉環(huán)。參數(shù)Agent的初步校驗(yàn)在規(guī)劃階段就進(jìn)行基本的幾何可行性檢查提前過濾掉約15%的明顯不可能實(shí)現(xiàn)的描述如“在厚度5mm的板上開一個(gè)直徑10mm的盲孔深度8mm”。仿真Agent的最終把關(guān)這是攔截錯(cuò)誤的最重要防線。我們統(tǒng)計(jì)發(fā)現(xiàn)約有25%的首次生成指令會(huì)在仿真環(huán)節(jié)暴露出問題例如特征重建失敗、約束沖突導(dǎo)致模型過定義等。在單Agent方案中這些問題會(huì)導(dǎo)致直接失敗。但現(xiàn)在Harness可以依據(jù)錯(cuò)誤類型啟動(dòng)不同的修復(fù)策略局部重試如果是某個(gè)特征如倒角失敗可以只讓CAD Command Agent重新生成該特征的指令。參數(shù)調(diào)整如果是因?yàn)槌叽绺缮婵梢苑答伣oParameter Agent讓其在一個(gè)合理范圍內(nèi)微調(diào)參數(shù)例如將孔距邊緣的距離從2mm調(diào)整為2.5mm然后重新生成指令。計(jì)劃重構(gòu)如果是根本性的順序錯(cuò)誤則將錯(cuò)誤信息反饋給Planner Agent讓其重新規(guī)劃步驟順序。 這個(gè)“生成-驗(yàn)證-反饋-再生成”的循環(huán)將很多原本會(huì)導(dǎo)致整體失敗的錯(cuò)誤轉(zhuǎn)化為了可以自動(dòng)修復(fù)的局部問題這是提升整體成功率的關(guān)鍵。3.3 復(fù)雜任務(wù)處理能力的質(zhì)變對(duì)于簡(jiǎn)單任務(wù)如“創(chuàng)建一個(gè)長(zhǎng)方體”單Agent和多Agent的差距可能不大。但當(dāng)任務(wù)復(fù)雜度提升時(shí)多Agent的優(yōu)勢(shì)呈指數(shù)級(jí)放大。場(chǎng)景一包含條件邏輯的描述?！叭绻讖酱笥?0mm則添加一個(gè)環(huán)形加強(qiáng)筋否則直接打孔?！眴蜛gent需要在一個(gè)生成步驟內(nèi)理解和執(zhí)行這個(gè)“if-else”邏輯容易出錯(cuò)。而在我們的工作流中這很自然Parameter Agent解析出孔徑參數(shù)Harness根據(jù)該參數(shù)值如12mm決定下一步是流向“生成加強(qiáng)筋孔”的子流程還是直接流向“生成簡(jiǎn)單孔”的子流程。工作流本身成為了邏輯的載體。場(chǎng)景二多實(shí)體與裝配關(guān)系?！皠?chuàng)建兩個(gè)法蘭盤并用六顆螺栓將它們連接起來。”這涉及多個(gè)獨(dú)立零件法蘭盤、螺栓和它們之間的裝配關(guān)系同心、重合、螺栓配合。單Agent幾乎無法一次性正確處理。多Agent方案則可以Planner Agent將其分解為創(chuàng)建法蘭盤A、創(chuàng)建法蘭盤B、創(chuàng)建螺栓、創(chuàng)建裝配體四個(gè)主要階段。前三個(gè)階段可以并行處理最后由一個(gè)專門的“裝配關(guān)系A(chǔ)gent”來添加配合約束。Harness負(fù)責(zé)協(xié)調(diào)這些并行和串行任務(wù)。正是這些復(fù)雜場(chǎng)景的成功處理將我們的平均準(zhǔn)確率從原來的不足70%提升到了現(xiàn)在的90%以上實(shí)現(xiàn)了30%的絕對(duì)提升。4. 實(shí)戰(zhàn)踩坑從理想架構(gòu)到穩(wěn)定落地的挑戰(zhàn)架構(gòu)很美好但落地過程充滿了“坑”。多Agent系統(tǒng)不是簡(jiǎn)單的112協(xié)調(diào)成本、新的故障模式都會(huì)出現(xiàn)。以下是我們?cè)贖iCAD 3.0開發(fā)中遇到的核心挑戰(zhàn)及解決方案。4.1 Agent間通信與數(shù)據(jù)格式的“巴別塔”問題每個(gè)Agent可能由不同的團(tuán)隊(duì)開發(fā)使用不同的內(nèi)部數(shù)據(jù)表示。NLU Agent可能輸出JSONParameter Agent習(xí)慣用Protobuf而某個(gè)舊版的分析庫只接受XML。如果讓它們直接通信會(huì)是一場(chǎng)災(zāi)難。我們的解決方案在Harness中我們定義了統(tǒng)一的、強(qiáng)類型的內(nèi)部數(shù)據(jù)交換格式IDL。我們使用Protocol Buffers來定義所有Agent之間傳遞的消息結(jié)構(gòu)。例如FeatureMessage會(huì)明確定義特征類型、參數(shù)列表、依賴關(guān)系等字段。每個(gè)Agent的輸入輸出都必須遵守這個(gè)協(xié)議。Harness負(fù)責(zé)序列化和反序列化。這相當(dāng)于為所有Agent建立了“普通話”標(biāo)準(zhǔn)徹底消除了格式歧義帶來的錯(cuò)誤。4.2 錯(cuò)誤處理與工作流回退的復(fù)雜性在單鏈?zhǔn)街绣e(cuò)誤處理相對(duì)簡(jiǎn)單失敗了就報(bào)錯(cuò)。但在多Agent、有分支有循環(huán)的工作流中一個(gè)節(jié)點(diǎn)的失敗該如何處理是重試當(dāng)前節(jié)點(diǎn)還是回退到上游某個(gè)檢查點(diǎn)還是啟動(dòng)一個(gè)備用的修復(fù)流程我們的解決方案利用Harness的狀態(tài)機(jī)和補(bǔ)償事務(wù)Saga模式。我們?yōu)楣ぷ髁髦械拿總€(gè)關(guān)鍵步驟定義了“檢查點(diǎn)”。當(dāng)某個(gè)Agent失敗時(shí)Harness會(huì)根據(jù)錯(cuò)誤碼和預(yù)設(shè)策略決定下一步動(dòng)作。例如瞬時(shí)錯(cuò)誤如網(wǎng)絡(luò)超時(shí)自動(dòng)重試最多3次。邏輯錯(cuò)誤如參數(shù)無解向上游回滾到Parameter Agent并附帶錯(cuò)誤信息觸發(fā)其重新計(jì)算。嚴(yán)重錯(cuò)誤如內(nèi)核崩潰回滾到整個(gè)工作流的起點(diǎn)并標(biāo)記任務(wù)為“需人工干預(yù)”同時(shí)保存當(dāng)前所有中間狀態(tài)供工程師調(diào)試。 我們?yōu)槊糠N錯(cuò)誤類型編寫了對(duì)應(yīng)的“補(bǔ)償操作”例如如果CAD指令生成失敗補(bǔ)償操作是清理掉已創(chuàng)建的部分臨時(shí)幾何體防止殘留數(shù)據(jù)影響重試。4.3 系統(tǒng)延遲與性能開銷的權(quán)衡每增加一個(gè)Agent就增加一次網(wǎng)絡(luò)調(diào)用、一次數(shù)據(jù)序列化/反序列化、一次上下文切換。如果設(shè)計(jì)不當(dāng)系統(tǒng)延遲會(huì)急劇上升。我們的解決方案Agent輕量化與本地化不是所有Agent都必須是大模型。像參數(shù)計(jì)算、簡(jiǎn)單規(guī)則校驗(yàn)這類Agent我們用更輕量的規(guī)則引擎或小型模型實(shí)現(xiàn)并盡可能與主服務(wù)部署在同一臺(tái)機(jī)器或同一個(gè)Pod內(nèi)減少網(wǎng)絡(luò)延遲。異步執(zhí)行與并行化Harness支持任務(wù)的異步執(zhí)行。對(duì)于沒有依賴關(guān)系的Agent例如解析一個(gè)模型上彼此獨(dú)立的多個(gè)特征我們讓它們并行運(yùn)行充分利用多核資源。緩存機(jī)制對(duì)于一些耗時(shí)的公共計(jì)算如標(biāo)準(zhǔn)件庫查詢、常用材料屬性獲取我們引入了分布式緩存Redis。多個(gè)工作流實(shí)例可以共享緩存結(jié)果避免重復(fù)計(jì)算。監(jiān)控與 profiling我們建立了詳細(xì)的性能監(jiān)控追蹤每個(gè)Agent、每次調(diào)用的耗時(shí)。通過持續(xù)的性能剖析Profiling我們找到了幾個(gè)性能瓶頸比如某個(gè)幾何校驗(yàn)算法復(fù)雜度太高后來我們將其替換為更高效的近似算法。4.4 對(duì)“未知描述”的魯棒性提升用戶的需求是天馬行空的總會(huì)遇到訓(xùn)練數(shù)據(jù)中未覆蓋的描述。單Agent模型可能會(huì)“胡言亂語”或生成完全錯(cuò)誤的模型。多Agent架構(gòu)在這里提供了一個(gè)防御層。我們的實(shí)踐我們?cè)诠ぷ髁髦性黾恿艘粋€(gè)“置信度評(píng)估”環(huán)節(jié)。每個(gè)Agent在處理完自己的任務(wù)后都需要輸出一個(gè)置信度分?jǐn)?shù)。例如NLU Agent如果遇到完全不認(rèn)識(shí)的術(shù)語它的置信度會(huì)很低。Harness會(huì)監(jiān)控這些分?jǐn)?shù)。如果多個(gè)Agent的置信度都低于閾值系統(tǒng)不會(huì)強(qiáng)行執(zhí)行到底生成一個(gè)可能錯(cuò)誤的模型而是會(huì)提前優(yōu)雅降級(jí)例如轉(zhuǎn)而生成一個(gè)基于理解部分所創(chuàng)建的、不完整的模型并高亮標(biāo)出無法處理的部分同時(shí)向用戶發(fā)起澄清式提問“您提到的‘渦流發(fā)生器’具體是指哪種幾何形狀能否提供更多描述或參考圖片”。這比生成一個(gè)垃圾模型然后讓用戶失望要好得多。5. 給后來者的實(shí)踐建議與未來展望從HiCAD 2.0的單體架構(gòu)升級(jí)到3.0的多Agent編排系統(tǒng)是一個(gè)充滿挑戰(zhàn)但回報(bào)豐厚的旅程。如果你也在考慮為你的復(fù)雜任務(wù)系統(tǒng)引入多Agent架構(gòu)以下是我們用真金白銀換來的幾點(diǎn)核心建議1. 不要為了多Agent而多Agent。首先問自己你的任務(wù)是否真的可以清晰地分解為多個(gè)職責(zé)分明、相對(duì)獨(dú)立的子任務(wù)子任務(wù)之間是否存在標(biāo)準(zhǔn)的、結(jié)構(gòu)化的數(shù)據(jù)接口如果任務(wù)本身是高度混沌、難以拆解的強(qiáng)行拆分只會(huì)增加復(fù)雜度。對(duì)于3D建模、代碼生成、數(shù)據(jù)分析流水線這類結(jié)構(gòu)化任務(wù)多Agent是利器對(duì)于創(chuàng)意寫作、開放域?qū)υ捒赡芫托枰?jǐn)慎。2. 編排框架的選擇至關(guān)重要它決定了系統(tǒng)的“韌性”。不要只關(guān)注框架是否能“跑起來”要深入考察它的錯(cuò)誤處理能力、狀態(tài)管理、監(jiān)控指標(biāo)、調(diào)試工具是否完善。Harness之所以適合我們是因?yàn)樗墓ぷ髁鞫x非常直觀且對(duì)失敗處理和重試有強(qiáng)大的原生支持。在選型時(shí)務(wù)必用你們最復(fù)雜的故障場(chǎng)景去測(cè)試候選框架。3. 統(tǒng)一的數(shù)據(jù)契約是生命線。在開發(fā)第一個(gè)Agent之前先花時(shí)間定義好Agent之間通信的數(shù)據(jù)格式。使用像Protobuf、Avro這類支持版本化和強(qiáng)類型的工具。這會(huì)在后續(xù)的集成、測(cè)試和擴(kuò)展中節(jié)省你無數(shù)的時(shí)間避免“接口地獄”。4. 投資于可觀測(cè)性O(shè)bservability。多Agent系統(tǒng)的調(diào)試比單體系統(tǒng)困難得多。一個(gè)任務(wù)的失敗可能是A Agent的bug也可能是B Agent的輸出不符合C Agent的預(yù)期或者是編排邏輯本身有誤。必須為每個(gè)Agent調(diào)用、每一次數(shù)據(jù)傳遞、每一個(gè)工作流狀態(tài)變更都打上詳細(xì)的日志和追蹤Trace。我們集成了OpenTelemetry可以清晰地看到一個(gè)用戶請(qǐng)求在所有Agent間的完整流轉(zhuǎn)路徑和耗時(shí)這對(duì)于定位問題不可或缺。5. 建立端到端的測(cè)試流水線。單元測(cè)試測(cè)試單個(gè)Agent很重要但還不夠。必須建立覆蓋完整工作流的集成測(cè)試和回歸測(cè)試套件。準(zhǔn)備一批涵蓋各種復(fù)雜度的測(cè)試用例從簡(jiǎn)單方塊到復(fù)雜裝配體每次代碼更新后都自動(dòng)運(yùn)行監(jiān)控準(zhǔn)確率和性能指標(biāo)的變化。這能有效防止“修復(fù)一個(gè)bug引入兩個(gè)新bug”的情況。關(guān)于未來我們正在探索幾個(gè)方向動(dòng)態(tài)Agent編排目前的工作流是預(yù)先定義好的。未來我們希望系統(tǒng)能根據(jù)任務(wù)的實(shí)時(shí)復(fù)雜度和可用計(jì)算資源動(dòng)態(tài)地決定是否啟動(dòng)某個(gè)Agent比如簡(jiǎn)單任務(wù)可能跳過仿真驗(yàn)證環(huán)節(jié)或者選擇不同能力的Agent實(shí)例比如在GPU資源緊張時(shí)使用輕量版模型Agent實(shí)現(xiàn)更智能的資源調(diào)度。Agent的持續(xù)學(xué)習(xí)每個(gè)Agent在運(yùn)行中都會(huì)遇到新的成功或失敗案例。我們計(jì)劃建立一個(gè)反饋循環(huán)讓這些案例能夠被安全地收集、標(biāo)注并用于定期微調(diào)對(duì)應(yīng)的Agent讓系統(tǒng)在實(shí)際使用中越用越聰明。人機(jī)協(xié)同閉環(huán)當(dāng)前系統(tǒng)在遇到低置信度時(shí)主要向用戶提問。我們正在設(shè)計(jì)更豐富的人機(jī)交互方式例如允許用戶在生成的中間結(jié)果如草圖上直接進(jìn)行圖形化修改系統(tǒng)則學(xué)習(xí)這種修改并嘗試更新后續(xù)的Agent決策。讓AI處理routine work人類專家專注于高層次的創(chuàng)意和糾偏這才是人機(jī)協(xié)同的理想狀態(tài)。放棄單Agent擁抱多Agent編排對(duì)我們而言不是一個(gè)輕松的決定但它讓我們跳出了模型能力增長(zhǎng)的線性競(jìng)爭(zhēng)轉(zhuǎn)向了系統(tǒng)架構(gòu)帶來的系統(tǒng)性紅利。這30%的準(zhǔn)確率提升不僅僅是數(shù)字的變化更代表著我們讓AI更可靠地處理復(fù)雜現(xiàn)實(shí)任務(wù)的能力邁上了一個(gè)新的臺(tái)階。這條路還在繼續(xù)坑還會(huì)有但風(fēng)景已然不同。