北京
“你需要在項目中加入AI。”
2024年初的某天下午，我和Hassan坐在答辯委員會的房間里。面前的筆記本電腦上攤著我們的畢業設計提案——他負責Unity游戲開發部分，我主管云端基礎設施，一個基于ECS和Terraform的后端架構。分工清晰，邏輯自洽，我們覺得這事能成。
委員會那位教授說完這四個字后，房間里安靜了幾秒。不是建議，是要求。
走出門，Hassan轉頭看我：“加點尋路算法，就當是AI功能交差了。”
我心里清楚，糊弄不過去。如果只是湊數，答辯時那些教授一眼就能看穿。要做就做一個真正把游戲開發和云計算這兩個方向串起來的AI方案——讓委員會看到，這個選題本身就是為了驗證跨領域協作的可能性才存在的。
Hassan前段時間在看強化學習（Reinforcement Learning）的論文。核心邏輯很迷人：別給NPC手寫行為腳本，讓智能體自己試錯。靠近玩家加分，撞墻扣分，幾千輪訓練后它會自己摸索出一套策略。他描述這個思路時，光聽描述確實像畢設答辯時的殺手锏。
我們動手了。
純強化學習在實際工程中的問題，論文里不太會花篇幅強調。
第一個問題：訓練量。在網格環境里跑一個簡單獎勵函數，幾百上千輪訓練能出效果。但在一個有三維環境、動態玩家行為、并且四個月后就要交演示版本的Unity游戲里？Hassan的訓練環境是筆記本電腦，不是GPU集群。完整的強化學習訓練在真實游戲引擎里跑一輪的時間，夠我們把有限狀態機（FSM）寫好測完再改三遍了。
第二個問題：不可控。強化學習的美妙之處是它真的會“探索”——但它探索出來的行為包括站在墻角不動、對著墻壁走、毫無理由地從玩家面前跑開。學術上這叫“探索策略的隨機性”，在游戲里這叫“這個敵人看起來很蠢”。我們要的是一個有威脅感的敵方單位，不是行為藝術裝置。
第三個問題更微妙：獎勵函數設計。想讓NPC靠近玩家，設定距離越近獎勵越高，結果它學會了靠近——然后就停在那里。因為獎勵信號只說了“接近有好處”，沒說“接近之后應該攻擊”。每一條獎勵設計都在和智能體博弈，它總能找到一個你沒想到的方式來最大化得分，而不是最大化游戲性。這不是算法問題，是系統工程問題。
Hassan坦率說了實話：在給定的時間窗口內，他沒法在Unity代碼庫里完成完整的強化學習實現。他先用FSM搭了一個可運行的版本，功能穩定，但放在委員會明確提出AI要求的背景下，總讓人覺得少了點什么。
這個缺口，我來填。
辯論的兩端擺在我們面前：純強化學習不可控、訓練慢、演示風險高；純FSM僵硬、缺乏自適應能力、教授一眼看出沒有真正的智能決策層。我需要找到中間路線。
我把AI架構問題接了過來。接下來兩周，我開始翻論文、讀游戲AI技術博客、復盤其他團隊做混合方案的案例。
最終鎖定了一個方向——不把強化學習和FSM對立起來，而是讓它們分層協作。高層決策用強化學習訓練出的策略網絡，底層執行用FSM保證行為可控。智能體決定“追擊”時，具體怎么跑、怎么避開障礙物、怎么切換攻擊動作，全部交給FSM執行。這樣既保留了“智能體通過訓練學會策略”這個學術賣點，又避免了純強化學習在演示現場翻車的風險。
委員會的教授們最終看到了一個兩層架構的敵方AI系統：云端訓練的輕量級策略模型輸出行為意圖，本地游戲引擎里的FSM執行并兜底。訓練過程有數據可展示，演示版本穩定可運行，兩個技術棧之間的關系不是生硬拼接，而是架構上的必然依賴——沒有云端的模型訓練流水線，游戲里的NPC就不會有那些策略變化；沒有游戲引擎里的FSM，訓練出來的策略就無法在真實環境里穩定落地。
答辯那天，Hassan演示Unity場景里的敵人行為切換，我展示AWS上的訓練日志和架構圖。
教授看完問了一個問題：“如果給你們更多時間，這個架構的下一步是什么？”
我們回答：把云端訓練流水線做成實時更新——根據玩家行為數據持續微調策略模型，讓NPC在不同玩家的游戲里逐漸分化出不同的對抗風格。
走出答辯教室時Hassan說，當時那句“加點尋路算法就行”是他本學年說過的最蠢的話。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
