Unite Shanghai 2025 于 10 月 23-24 日?qǐng)A滿舉辦。在團(tuán)結(jié)引擎專場(chǎng)中，騰訊天美 J1 工作室客戶端主程余煜與 igins 首席技術(shù)專家牟騫帶來(lái)分享《AI 在超大游戲工程中的應(yīng)用瓶頸與解決方案》，本文為演講全文實(shí)錄。請(qǐng)持續(xù)關(guān)注，一起學(xué)習(xí) Unite 分享的最新干貨。

余煜：大家好，我是來(lái)自騰訊天美 J1 的余煜，很高興今天能有機(jī)會(huì)參與到 Unite 峰會(huì)。2025年被稱為 AI Agent 元年，短短半年，AI 應(yīng)用已經(jīng)陸續(xù)開始進(jìn)入我們的工作生活。今天就和大家介紹我們?cè)诖笮陀螒蚬こ讨惺褂?AI 的一些思考和實(shí)踐。我和我的同事牟騫會(huì)從現(xiàn)狀和挑戰(zhàn)出發(fā)，講一下我們方案的原理和實(shí)現(xiàn)，最后介紹該方案在團(tuán)結(jié)引擎 crash 治理中取得的一些落地進(jìn)展和實(shí)際價(jià)值。

Vibe Coding 的現(xiàn)狀與挑戰(zhàn)

AI 輔助編程前兩年就出現(xiàn)了，2025 年呈爆發(fā)態(tài)勢(shì)，百家爭(zhēng)鳴，甚至出現(xiàn) vibe coding 的概念。Claude code 作為其中的佼佼者，給開發(fā)者帶來(lái)了前所未有的智能編程體驗(yàn)。

從 Microsoft、GitHub、Stripe、Amazon 等官方報(bào)告當(dāng)中可以看出，AI 編程占比持續(xù)提升，而且有非常不錯(cuò)的價(jià)值。但大家有體驗(yàn) AI 編程的話，還是會(huì)發(fā)現(xiàn)AI 會(huì)出現(xiàn)記憶斷裂、編造信息、擅自調(diào)整需求，或者是長(zhǎng)時(shí)間執(zhí)行但是沒(méi)辦法完成任務(wù)的情況。

分享一些我們團(tuán)隊(duì)中使用 AI 的問(wèn)題，我們會(huì)發(fā)現(xiàn) AI 擅自縮小任務(wù)、不聽指揮、越改越差，一個(gè)問(wèn)題修出兩個(gè)問(wèn)題。并且因?yàn)檫@些產(chǎn)品都是 toC 的商業(yè)化產(chǎn)品，面臨大量的 token 限制和模型限制問(wèn)題。

谷歌 Osman 也曾在訪談中表示，AI 輔助開發(fā)存在“70% 陷阱”，AI確實(shí)在 70% 的時(shí)間內(nèi)就可以完成工作，但是在深層次問(wèn)題，比如性能、邊界、兼容性，擴(kuò)展性方面，存在比較大的視野盲區(qū)。比如AI修復(fù)了血條不顯示的 Bug，強(qiáng)行顯示，但這樣導(dǎo)致了游戲崩潰的問(wèn)題，就是所謂的“后退兩步”循環(huán)陷阱。特別是在一些大型項(xiàng)目中，更容易出現(xiàn)我們之前提到的記憶斷裂、信息編造的問(wèn)題。為什么會(huì)出現(xiàn)上述問(wèn)題呢？我們總結(jié)了 4 個(gè)方面。

用一個(gè)比喻來(lái)描述：我們招聘了一個(gè)邏輯能力很強(qiáng)、具備豐富的知識(shí)儲(chǔ)備，但工作記憶有限，一次性只能聚焦小部分內(nèi)容，看多了還容易忘，有時(shí)候會(huì)出現(xiàn)一些思維幻覺(jué)的外包新員工。外包公司的老板為了推銷他的員工，告訴我們員工非常好，具有博士級(jí)別的智能。聽說(shuō)是博士，我們讓他做大型任務(wù)。實(shí)際上在超大型游戲工程當(dāng)中往往出現(xiàn)非常大量的游戲信息，比如百萬(wàn)級(jí)別的代碼，數(shù)十萬(wàn)級(jí)別的游戲資產(chǎn)，即使是游戲行業(yè)的老專家都需要花大量時(shí)間才能把游戲的上下文理解清楚。我們這位新員工確實(shí)可以把大型任務(wù)拆分成更小的任務(wù)，但還是缺乏游戲工程上下文的耦合性理解。并且也不是很了解我們對(duì)于交付的要求，雖然知識(shí)淵博但是不了解具體項(xiàng)目。同時(shí)做的過(guò)程當(dāng)中很容易丟三忘四，有時(shí)候會(huì)編造一些信息。最為關(guān)鍵的是這家外包公司的老板為了考慮公司的收益和利潤(rùn)，會(huì)控制員工不能加班，所以員工一看該下班了，就交付了自己覺(jué)得還湊合，但是實(shí)際上并不太 OK 的交付物。

這個(gè)時(shí)候如果我們給他安排一個(gè)成熟的導(dǎo)師，導(dǎo)師能完整理解游戲的上下文工程，將任務(wù)和上下文耦合，并清晰地傳遞交付標(biāo)準(zhǔn)，并且在員工交付以后可以 check 員工交付結(jié)果，這個(gè)新人就能有比較好的發(fā)揮。這就是為什么我們會(huì)有這樣的說(shuō)法：如果能夠帶得好新人，大概率也能用得好 AI。我們聚焦關(guān)鍵洞察上，發(fā)現(xiàn) AI的生產(chǎn)過(guò)程是不連續(xù)的，只能片段性產(chǎn)生一些過(guò)程交付物，但是我們這些專家的專業(yè)知識(shí)和寶貴經(jīng)驗(yàn)把 AI 離散的產(chǎn)出串聯(lián)成為了一個(gè)整體。最近有一個(gè)比較有意思的說(shuō)法，因?yàn)?AI 的興起需要很多專家來(lái)賦能，讓我們這些 35+ 的大齡工程師又迎來(lái)了職業(yè)第二春。

這也是今天我們討論的核心點(diǎn)：如何讓 AI 更長(zhǎng)時(shí)間地、更全面地、更獨(dú)立地工作？以及剛才提到 AI 需要配合專家的經(jīng)驗(yàn)，如何降低 AI 的使用門檻和能力要求？在英偉達(dá)的 GTC 峰會(huì)上提出了 Agentic AI 的概念，這種類型的 AI 希望在盡可能少的人工干預(yù)之下，讓 AI 面向目標(biāo)自主規(guī)劃和自主完成任務(wù)。接下來(lái)我們介紹一下如何實(shí)現(xiàn) Agentic AI 的思考和方法論, 我們稱為可微智能。

可微智能的認(rèn)知原理

先看一下模型召回的本質(zhì)：同一個(gè)物件，不同角度下產(chǎn)生不同投影。事物本身沒(méi)有變化，取決于你從什么角度看待它。我們知道，大語(yǔ)言模型通過(guò)大量的數(shù)據(jù)集進(jìn)行預(yù)訓(xùn)練，給到的提示詞就是投影的方向。

舉個(gè)例子，比如說(shuō)天美的《王者榮耀》，假設(shè)有一個(gè)英雄既可以打上單，也可以打野，如果提示詞只是問(wèn)打野的攻略，大概率只會(huì)告訴你打野的信息，上單的信息不會(huì)告訴你。也就是說(shuō)提示詞會(huì)決定大語(yǔ)言模型怎么回答你，提示詞越詳細(xì)，大語(yǔ)言模型越聽話。背后的本質(zhì)是從高維數(shù)據(jù)集到低維數(shù)據(jù)集的投影，帶來(lái)數(shù)據(jù)丟失。

從流程上來(lái)分析這個(gè)問(wèn)題。當(dāng)前大語(yǔ)言模型的數(shù)據(jù)集是有時(shí)效性的，希望大語(yǔ)言模型通過(guò)聯(lián)網(wǎng)搜索用最新的信息來(lái)作答，但是這種作答方式是 Vibe 模式，也就是召回、重組、生成三個(gè)步驟。有幾個(gè)重點(diǎn):信息獲取過(guò)程依賴數(shù)學(xué)形式的表達(dá)，即 embedding+rerank， 也就是語(yǔ)義級(jí)的關(guān)鍵字搜索、相關(guān)性重排。這個(gè)過(guò)程和在搜索引擎中檢索信息非常相似，過(guò)程是有信息丟失的。關(guān)鍵字就是投影方向，搜索不同關(guān)鍵字出來(lái)的信息是有一些遺漏的，我們稱之為信息熵增。

因?yàn)樯弦徊秸倩氐臅r(shí)候有信息錯(cuò)誤，重組的時(shí)候就有很大的概率產(chǎn)生錯(cuò)誤結(jié)論。因?yàn)榇笳Z(yǔ)言模型的上下文是有限的，我們又需要迭代進(jìn)行 RAG，迭代過(guò)程當(dāng)中會(huì)不斷放大信息熵增。舉個(gè)例子，有一個(gè)任務(wù)是 99% 的成功率，迭代了 300 次之后失敗率達(dá)到了 95%，迭代一千次以后失敗率達(dá)到了 100%，迭代次數(shù)越多失敗概率越高，這是為什么 AI 處理大型任務(wù)有比較大問(wèn)題的關(guān)鍵原因。

最后看生成，AI 的生成是黑盒，并不知道生成過(guò)程，出錯(cuò)以后沒(méi)辦法回溯，只能修改提示詞。我們使用 AI 的時(shí)候有一個(gè)概念是抽獎(jiǎng)，我們總在抽獎(jiǎng)。從流程中，我們可以明確發(fā)現(xiàn)如果希望 AI 穩(wěn)定工作，關(guān)鍵就是控制信息熵增。

受到數(shù)學(xué)可微概念啟發(fā)，曲線是由無(wú)數(shù)小直線拼出的近似圖形。是否可以將大型任務(wù)通過(guò)專家的經(jīng)驗(yàn)拆分到足夠小，以至于單步 AI 有足夠的能力完成，從而構(gòu)成 AI 連續(xù)長(zhǎng)時(shí)間穩(wěn)定工作的基石？我們由此提出了可微 AI 的概念，分成三個(gè)關(guān)鍵點(diǎn)：可微分、可預(yù)測(cè)、可逆性?？晌⒎?，即 AI 執(zhí)行過(guò)程中，不會(huì)出現(xiàn)超出 AI 能力范圍的任務(wù)；可預(yù)測(cè)，即通過(guò)當(dāng)前流行的上下文工程，讓 AI 對(duì)于工程環(huán)境能順藤摸瓜，從而對(duì)修改產(chǎn)生的影響有更全面的判斷；可逆性，很容易理解，指 AI 的執(zhí)行過(guò)程需要可以被回溯和調(diào)試。

我們用導(dǎo)航來(lái)比喻，在一條都是坑的馬路上，有些車比較長(zhǎng)，如履平地；有些車比較短，就會(huì)掉坑。有兩種思路解決：一種是把車造的越來(lái)越長(zhǎng)，做更新更牛的大模型，另外一種方式是修路。兩種方式本質(zhì)上沒(méi)有對(duì)與錯(cuò)，現(xiàn)在我們選擇更經(jīng)濟(jì)更現(xiàn)實(shí)的方案是修路，讓 AI 去更好地執(zhí)行。

預(yù)測(cè)性就比較好理解了，我們一開始知道哪里會(huì)堵，哪里限號(hào)， AI 做決策的時(shí)候就比較好做可預(yù)測(cè)的決策，尋找最優(yōu)路徑。正是基于可微的思想，我們也在游戲的 crash 治理這個(gè)問(wèn)題上實(shí)現(xiàn)了可以長(zhǎng)時(shí)間無(wú)監(jiān)管地完成長(zhǎng)距離推理的 Agent，并且適配了國(guó)產(chǎn)的開源模型，不僅大幅降低了使用成本，提升了安全性，也一定程度打破了目前地緣政治下，海外模型對(duì)國(guó)內(nèi)的封鎖。具體是如何實(shí)現(xiàn)可微 AI 的方案，接下來(lái)有請(qǐng)工作室的專家工程師牟騫和大家分享。

牟騫：感謝各位來(lái)賓，我是天美工作室的牟騫，我給大家介紹在可微 AI 的基礎(chǔ)上，我們?nèi)绾芜M(jìn)行后續(xù)的工程實(shí)施。

可微智能的技術(shù)實(shí)現(xiàn)

在這一領(lǐng)域，我們主要是啟用了范式的開發(fā)。范式是今年上半年流行的，特別是在 OpenAI 出來(lái)以后，大家把這類問(wèn)題歸納到范式解決方案。這塊我們主要完成可控性、連續(xù)性、可回溯性、可導(dǎo)性方面的約束。

我們?cè)谶@個(gè)范式中做了幾大部分。首先是對(duì)預(yù)置的 AI 領(lǐng)域?qū)＜乙娊庾隽舜笠?guī)模的拆解，我們做了一些預(yù)置埋點(diǎn)，讓 AI 在工程當(dāng)中進(jìn)行預(yù)先的點(diǎn)分布，在正確的路上做正確的事情。

第二部分范式我們有任務(wù)的數(shù)據(jù)結(jié)構(gòu)，可以是任意的結(jié)構(gòu)，樹結(jié)構(gòu)、圖結(jié)構(gòu)、列表架構(gòu)，加以狀態(tài)機(jī)的運(yùn)行，主要提供非常強(qiáng)的可控性。我們對(duì)所有要完成的任務(wù)進(jìn)行了統(tǒng)一結(jié)構(gòu)和狀態(tài)機(jī)處理。

第三部分是上下文工程。來(lái)自于最早 2022 年 AutoGPT，有足夠強(qiáng)的大腦，助手提供無(wú)限的上下文，只要大腦有足夠強(qiáng)的推理性和上下文足夠完整，就可以解決任何問(wèn)題，這是我們做上下文工程的核心關(guān)鍵。

因?yàn)樵敿?xì)的拆分，我們對(duì)模型能力的要求進(jìn)一步下降。好比在同一個(gè)模型上，一次性做十個(gè)事情可能注意力有限，但是如果分解成一次性做一個(gè)事情，就會(huì)做的非常棒，因此我們對(duì)于模型能力要求會(huì)大幅度下降。

AI 范式第一部分是數(shù)據(jù)結(jié)構(gòu)，可以根據(jù)明確的目標(biāo)范式。比如針對(duì) Crash 的治理，拿到 Crash 的內(nèi)容是已經(jīng)崩潰之后的線索，并不是內(nèi)存的實(shí)時(shí)反饋，所以我們對(duì)它的鏈路只作為模擬和猜測(cè)，然后進(jìn)行探索的過(guò)程，這種探索的過(guò)程更適合用樹的結(jié)構(gòu)來(lái)承載。

第二部分是狀態(tài)機(jī)的執(zhí)行，我們對(duì)于執(zhí)行的遍歷順序、執(zhí)行入口、失敗回滾、長(zhǎng)效的任務(wù)都有比較好的控制。這樣每次 Prompt 放進(jìn)去以后，第一步成功了，我們把狀態(tài)直接引到第二步調(diào)試，這樣哪怕工程發(fā)生任何問(wèn)題，后續(xù)都可以對(duì)它進(jìn)行持續(xù)的任務(wù)規(guī)劃和再檢索。

這里我們整個(gè)工程范式的使用流程如上圖所示，從明確的范式目標(biāo)——探索型范式使用樹結(jié)構(gòu)比較適合，到選取數(shù)據(jù)結(jié)構(gòu)，定義狀態(tài)機(jī)，然后選取大語(yǔ)言模型。因?yàn)槊恳徊焦こ炭赡芏紩?huì)有任務(wù)偏向，對(duì)于大模型能力是有要求的，所以我們選擇不同的模型組合搭配使用，既可以得到更好的任務(wù)效果，也降低了任務(wù)成本。最低的模型只要可以正常使用，成本甚至低于每千 token 4B 或 8B。然后會(huì)構(gòu)建范式，把復(fù)雜任務(wù)范式進(jìn)行初步的信息填入，構(gòu)建范式進(jìn)行運(yùn)行，最后進(jìn)行范式級(jí)的優(yōu)化，得到最終的結(jié)果。

以樹結(jié)構(gòu)為例，任務(wù)樹的構(gòu)建從 root 節(jié)點(diǎn)、第一層到第二層，數(shù)據(jù)節(jié)點(diǎn)包含了任務(wù)描述、上下文，子父節(jié)點(diǎn)、父節(jié)點(diǎn)之間有引用關(guān)系。樹結(jié)構(gòu)先天就有上下前后的關(guān)系，自然表達(dá)了要先做什么后做什么，在深度維可以表達(dá)順序。執(zhí)行策略可以是廣度優(yōu)先、深度優(yōu)先、或優(yōu)先度遍歷，這樣在迭代整個(gè)樹的時(shí)候，迭代順序在一開始范式運(yùn)行的時(shí)候就確定了。

第二個(gè)部分是節(jié)點(diǎn)維，表示當(dāng)前處理的節(jié)點(diǎn)正在進(jìn)行什么操作。我們可以在節(jié)點(diǎn)和節(jié)點(diǎn)之間有一些額外的策略，比如在深度相同的情況下，兩個(gè)不同的節(jié)點(diǎn)如果是離散的，則此時(shí)是可以并發(fā)運(yùn)行的。

還有步驟維。步驟維是指處理單節(jié)點(diǎn)任務(wù)的時(shí)候可能分成多維，例如召回某一個(gè)程序代碼符號(hào)信息，查詢引用，可以一步查詢多維。傳統(tǒng)的 agent 流程更多是模擬角色的身份介入，而步驟維是以事來(lái)介入。我們?cè)谶@里的目的是增加復(fù)用性，并且適配更多的模型，例如第一步用更好的模型，推理性能很強(qiáng)，第二步對(duì)安全性要求很高，選開源模型，混合使用，可以在步驟維達(dá)到最好的效果、最低的成本和推理時(shí)間。

在工程優(yōu)勢(shì)上，我們?cè)谛阅芊矫?、顆粒度方面和故障容錯(cuò)方面都有非常好的實(shí)際應(yīng)用。在三維上進(jìn)行遍歷迭代，用狀態(tài)機(jī)的方式運(yùn)行，可以做到精確導(dǎo)航。這里最大的區(qū)別是實(shí)際任務(wù)當(dāng)中會(huì)不會(huì)控任務(wù)流程，Cloud code 運(yùn)行過(guò)程當(dāng)中是自主決定 to do list，雖然也有類似狀況機(jī)，但是并不是強(qiáng)控的狀態(tài)，是大語(yǔ)言模型自身決定的狀態(tài)，導(dǎo)致可能在復(fù)雜工作情況下，和預(yù)期會(huì)有不對(duì)齊的情況。

這里面可微執(zhí)行的核心是狀態(tài)機(jī)每步執(zhí)行狀態(tài)都是可微、可控的，明確表達(dá)了我們?cè)谡麄€(gè)圖上遍歷的連續(xù)性和可導(dǎo)性，也是對(duì)可微思想的延續(xù)。

這是非常重要的上下文工程部分。我們?cè)谥虚g需要給 AI 提供足夠多的豐富信息，這些信息在整個(gè)工程里面都是以摘要+圖結(jié)構(gòu)的方式來(lái)表達(dá)。我們會(huì)對(duì)代碼庫(kù)進(jìn)行摘要和圖結(jié)構(gòu)關(guān)聯(lián)，對(duì)創(chuàng)意設(shè)計(jì)庫(kù)也采取同樣的方式，包括從策劃案、UX、原畫，或者 TDD 技術(shù)拆解文檔、代碼庫(kù)、代碼符號(hào)都做完整的摘要。比如來(lái)了一個(gè)新的技術(shù)同事，他永遠(yuǎn)會(huì)問(wèn)幾個(gè)問(wèn)題：代碼應(yīng)該寫在哪，這個(gè)功能是不是之前開發(fā)過(guò)了、當(dāng)前狀態(tài)是什么，應(yīng)該遵守哪些規(guī)則。這一系列的問(wèn)題上下文工程都會(huì)提供，提到的每個(gè)問(wèn)題在每個(gè)庫(kù)里面都能得到上下文關(guān)聯(lián)，并且根據(jù)擴(kuò)展關(guān)聯(lián)在周邊進(jìn)行搜索，得到非常完整的上下文，這樣決定了在整個(gè)上下文工程里面的信息可微度和不丟失。

這里重點(diǎn)講解代碼庫(kù)關(guān)聯(lián)關(guān)系如何構(gòu)建。首先是代碼庫(kù)部分，需要它以圖結(jié)構(gòu)來(lái)完整表達(dá)在代碼符號(hào)中的關(guān)聯(lián)關(guān)系。程序員是如何在整個(gè)代碼中導(dǎo)航的呢？大家都用過(guò) IDE，我們最常做的事情是在代碼中用鼠標(biāo)選取某一個(gè)符號(hào)，然后 control+ 左鍵轉(zhuǎn)到符號(hào)本身的定義，或 F12，或在符號(hào)上右鍵 find all reference 查找引用，這層關(guān)系為我們提供了完整的代碼導(dǎo)航，我們希望代碼導(dǎo)航的能力同樣提供給 AI。在 IDE 使用這項(xiàng)技術(shù)是微軟在 2016 年和 Red Hat 提出的 Language Server Protocol 協(xié)議，通過(guò) JSON-RPC 查詢到代碼之間的語(yǔ)義關(guān)聯(lián)。在這一架構(gòu)下可以完整得到代碼導(dǎo)航，就可以讓 AI 像人一樣搜索引用、獲取定義、獲取所有關(guān)于代碼符號(hào)的上下文信息，都可以存入 LSP 圖數(shù)據(jù)庫(kù)，在最終的檢索效率上非常高。

與 Embedding 對(duì)比，問(wèn)題在于我們產(chǎn)生的符號(hào)從文本的角度上是符號(hào)，通用的命名在很多地方都會(huì)出現(xiàn)，embedding 搜索取了向量閾值相似度，如果搜出了一百甚至一萬(wàn)份，如何區(qū)分這個(gè)符號(hào)是不是目標(biāo)符號(hào)？只有符號(hào)表才能確定在規(guī)定的作用域和生命周期之下才是我們所需要的符號(hào)，這是我們引入 LSP 的技術(shù)關(guān)鍵。

可微智能在 Crash 中的落地實(shí)踐

可微智能在 Crash 中落地，我們主要通過(guò)全局視野分析，深度因果處理，自動(dòng)化處理、知識(shí)傳承，同時(shí)把項(xiàng)目里面特殊的一些用途進(jìn)行植入，讓它在全局中既可以在上下文中搜索，也可以結(jié)合專家經(jīng)驗(yàn)進(jìn)行落地，看一下具體實(shí)施。

發(fā)生了 Crash，有可能來(lái)自于不同的語(yǔ)言，比如是 C++ 的底層 +C# 中間層 +Lua 腳本，報(bào)錯(cuò)的時(shí)候可能會(huì)涉及到三種語(yǔ)言，這個(gè)時(shí)候會(huì)先把三個(gè)類型的堆棧按照時(shí)序進(jìn)行混合。第二步分析和整理堆棧的一些數(shù)據(jù)，然后插入到超級(jí)范式。這里因?yàn)檎{(diào)度有順序，我們會(huì)把每行的堆棧當(dāng)成深度維的節(jié)點(diǎn)進(jìn)行插入、探索。這里主要解決的問(wèn)題，就是在中間會(huì)自由 add task、executer、set clue、set conclusion，這部分起到的作用是解決復(fù)雜域的問(wèn)題。例如 A 給 B 賦值，B 給 C 賦值，C crash 了，A 和 B 并不在堆棧上，我們要找出來(lái) A 在哪。作為常規(guī)的 cloud code，最多分析出 A 報(bào)錯(cuò)了，但絕對(duì)找不到 C 是罪魁禍?zhǔn)?。這樣的情況下我們采用了超級(jí)范式，add task 會(huì)找到因?yàn)?A 報(bào)錯(cuò)了，所以去 find all reference 查找什么地方引用它，根據(jù)堆棧的推理得到了 B 的線索，然后驗(yàn)證線索是否是可被梳理的，這塊如果 OK 又找到了 C，對(duì) C 的情況進(jìn)行分析，產(chǎn)生一種可能性。所有的超級(jí)范式進(jìn)行完整流程的時(shí)候會(huì)進(jìn)行回溯，會(huì)模擬在這種分析下這樣的路徑是否可達(dá)成。如果可達(dá)成，最后出錯(cuò)的部分一定是報(bào)錯(cuò)的部分。

上面的例子是多線程競(jìng)爭(zhēng)下產(chǎn)生的問(wèn)題，典型符合剛才 A 到 B 到 C 的情況，并且 C 的賦值不在同一個(gè)線程當(dāng)中。首先會(huì)找到直接問(wèn)題原因的總結(jié)，其次在調(diào)用路徑上進(jìn)行復(fù)述，然后會(huì)找到根因也就是就是 C，C 是由哪塊導(dǎo)致的，要有完整的證據(jù)鏈，還有問(wèn)題的引入上下文，找到最近會(huì)有可能引發(fā)問(wèn)題的提交人，最后還給出了如何修復(fù)，并判斷影響的下載面，這部分是對(duì)整個(gè)模塊修復(fù)以后會(huì)產(chǎn)生的額外風(fēng)險(xiǎn)的評(píng)估，修復(fù)的緊急情況也會(huì)做完整闡述。

同樣，案例 2 也是多線程引發(fā)的棧溢出，對(duì)比傳統(tǒng)需要引入更多的線程框架、更復(fù)雜的時(shí)序、在靜態(tài)情況下重現(xiàn)，其實(shí)是非常難分析的問(wèn)題。

看一下最終的演示。這個(gè)演示是在早期的版本里面用 LangGraph 建立的，通過(guò)引擎合入新版本 USYM ，實(shí)現(xiàn)了 il2cpp，進(jìn)行了 C# 和行號(hào)和符號(hào)之間的映射?？晌⒎妒较抡揖€索-分析循環(huán)以后，得到了最終產(chǎn)生的結(jié)果。

總結(jié)一下，在實(shí)際應(yīng)用過(guò)程當(dāng)中，六個(gè)月時(shí)間就產(chǎn)生了 1000+ 用例的驗(yàn)證，Doctor 系統(tǒng)在運(yùn)行效率、成本、準(zhǔn)確性方面都做到極致的提升。在商業(yè)價(jià)值量化上，我們統(tǒng)計(jì)了 89 個(gè)問(wèn)題，平均每個(gè)問(wèn)題處理時(shí)間 20 分鐘，效率提升 80% 以上。單個(gè)問(wèn)題堆棧消耗 1M 左右，成本大概是一塊錢人民幣。我們最早的開發(fā)是基于 cloud 3.7 sonnet 模型，每個(gè)單子成本是 15 到 18 美元，到現(xiàn)在一塊人民幣，有數(shù)百倍的提升。并且是國(guó)內(nèi)的開源模型，最終適配千問(wèn) 3，235B，128K，是我們所有使用模型當(dāng)中推理性能最高的，當(dāng)然也有一些小模型跟隨。間接的商業(yè)價(jià)值是，我們可以快速得到用戶反饋、專家經(jīng)驗(yàn)固化以及團(tuán)隊(duì)效率提升。也完美解決了目前國(guó)外模型對(duì)國(guó)內(nèi)的封鎖問(wèn)題，對(duì)自身產(chǎn)品安全性的也有保證，并且節(jié)約了成本。

以上就是今天要分享的 Doctor 系統(tǒng)利用可微思想治理 crash 得到的階段性目標(biāo)，今天的演講到此結(jié)束，謝謝大家！

Unity 官方微信

第一時(shí)間了解Unity引擎動(dòng)向，學(xué)習(xí)進(jìn)階開發(fā)技能

每一個(gè)“點(diǎn)贊”、“在看”，都是我們前進(jìn)的動(dòng)力