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

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

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

Vibe Coding 的現狀與挑戰

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

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

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

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

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

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

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

可微智能的認知原理

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

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

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

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

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

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

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

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

牟騫：感謝各位來賓，我是天美工作室的牟騫，我給大家介紹在可微 AI 的基礎上，我們如何進行后續的工程實施。

可微智能的技術實現

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

我們在這個范式中做了幾大部分。首先是對預置的 AI 領域專家見解做了大規模的拆解，我們做了一些預置埋點，讓 AI 在工程當中進行預先的點分布，在正確的路上做正確的事情。

第二部分范式我們有任務的數據結構，可以是任意的結構，樹結構、圖結構、列表架構，加以狀態機的運行，主要提供非常強的可控性。我們對所有要完成的任務進行了統一結構和狀態機處理。

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

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

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

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

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

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

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

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

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

這里面可微執行的核心是狀態機每步執行狀態都是可微、可控的，明確表達了我們在整個圖上遍歷的連續性和可導性，也是對可微思想的延續。

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

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

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

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

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

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

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

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

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

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

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

Unity 官方微信

第一時間了解Unity引擎動向，學習進階開發技能

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