Unite Shanghai 2025 | AI 在超大游戲工程中的應(yīng)用瓶頸與解決方案

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

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

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

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

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

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

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

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

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

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

可微智能的認知原理

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

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

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

因為上一步召回的時候有信息錯誤，重組的時候就有很大的概率產(chǎn)生錯誤結(jié)論。因為大語言模型的上下文是有限的，我們又需要迭代進行 RAG，迭代過程當中會不斷放大信息熵增。舉個例子，有一個任務(wù)是 99% 的成功率，迭代了 300 次之后失敗率達到了 95%，迭代一千次以后失敗率達到了 100%，迭代次數(shù)越多失敗概率越高，這是為什么 AI 處理大型任務(wù)有比較大問題的關(guān)鍵原因。

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

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

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

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

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

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

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

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

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

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

因為詳細的拆分，我們對模型能力的要求進一步下降。好比在同一個模型上，一次性做十個事情可能注意力有限，但是如果分解成一次性做一個事情，就會做的非常棒，因此我們對于模型能力要求會大幅度下降。

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

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

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

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

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

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

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

這里面可微執(zhí)行的核心是狀態(tài)機每步執(zhí)行狀態(tài)都是可微、可控的，明確表達了我們在整個圖上遍歷的連續(xù)性和可導(dǎo)性，也是對可微思想的延續(xù)。

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

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

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

可微智能在 Crash 中的落地實踐

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

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

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

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

看一下最終的演示。這個演示是在早期的版本里面用 LangGraph 建立的，通過引擎合入新版本 USYM ，實現(xiàn)了 il2cpp，進行了 C# 和行號和符號之間的映射。可微范式下找線索-分析循環(huán)以后，得到了最終產(chǎn)生的結(jié)果。

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

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

Unity 官方微信

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

每一個“點贊”、“在看”，都是我們前進的動力