前火箭專家集資5.7M歐元 用「編譯式AI」解決工廠AI亂噏嘅老毛病

創始團隊：由射火箭到整可靠嘅工作流程

INXM喺2025年由四個人創立，佢哋之前嘅職業生涯，全部都係要令到極之複雜、對安全要求極高嘅系統，可以按照預期咁樣運作：

• Alexander (Alex) Oelling，行政總裁——之前係Isar Aerospace同Volocopter嘅數碼總監。
• Matthias Kainer——喺Isar Aerospace負責建立發射協調系統。
• Jesper Bylund——設計飛行控制介面，之前仲喺自動化平台n8n度做過。
• Kamil Klüber——軟件顧問公司Thoughtworks嘅資深員工。

呢種航天科技嘅DNA，並唔係佢哋履歷上嘅一個裝飾；呢個背景完全解釋晒成間公司嘅技術哲學。發射火箭嘅軟件，一定要喺嚴格嘅驗證底下，執行確定性嘅程序；佢係唔可以即興創作㗎。成個團隊就係用緊呢個一模一樣嘅思維模式，套用落企業級AI嗰度。

點解標準嘅企業AI代理會失敗

市面上大多數基於LLM嘅自動化工具，係喺工作流程嘅每一個步驟都會叫個語言模型出嚟幫手。咁樣就為啲受監管嘅企業帶嚟三個好難解決嘅問題：

• 非確定性。 同一個指令，喺唔同嘅執行次數可能產生唔同嘅行動或者輸出結果，令到合規審查同審計追蹤（Audit Trail）幾乎冇可能做到。
• 幻覺風險。 一個模型，如果佢老作咗一個審批步驟出嚟，或者無啦啦跳過咗一個安全檢查，喺製造業或者金融界就會造成不能接受嘅法律責任。
• 數據主權。 將敏感嘅生產數據 send 去第三方嘅LLM API，呢個做法同《通用數據保障條例》（GDPR）、歐盟《人工智能法案》（EU AI Act），以至企業內部嘅安全政策，都有衝突。

結果就係，好多工業公司雖然會評估吓啲AI代理，但永遠都唔會將佢哋部署落生產環境嗰度。啲技術喺示範嗰陣睇落好犀利，但佢哋就係冇辦法達到工廠車間軟件幾十年嚟一直嚴格執行緊嘅可靠性門檻。

「編譯式AI」嘅另類玩法

INXM嘅Orchestrator引擎，借鑑嘅係傳統軟件編譯器（Compiler）嘅架構，而唔係聊天機械人嘅循環對話模式。成個過程拆開做兩個截然不同嘅階段：

1. 編譯階段。 一個用家用自然語言（即係平日講嘢咁）描述一個業務流程。一個LLM就會生成一個完整、有結構、可以執行嘅「計劃」（Plan）——本質上係一段確定性嘅程式碼——而呢個計劃喺被允許執行之前，係要先經過驗證嘅。個模型淨係喺創作階段用一次，而唔係喺交易執行嘅時候先用。

2. 執行階段。 呢個驗證好咗嘅計劃，會喺INXM嘅Orchestrator引擎上面執行，之後就唔會再叫個LLM出嚟。個引擎會協調企業現有嘅各種系統——ERP、PLM、MES、電郵同埋審批工具——每一次都用同樣嘅步驟、同樣嘅次序去執行。

技術上嘅分別係好明顯嘅：標準嘅AI代理係每個步驟都要叫LLM（唔確定、燒錢、難審計）。INXM就係編譯一次，然後執行一個固定咗嘅程式。輸出結果變得可以重現（Reproducible）、可以測試，而且喺執行期間唔會有幻覺。公司將呢樣嘢稱為「自然語言嘅靈活性」同「傳統程式碼嘅可靠性」嘅結合。

等我哋將個概念講得具體啲。諗吓一間工廠嘅品質檢查工作流程：一個工程師用平白嘅語言，描述晒需要嘅審批步驟同數據檢查。Orchestrator將呢段描述編譯成一個固定嘅程序，由經理審批一次，之後個工作流程喺每次有相關事件觸發嗰陣，就會完全一模一樣咁樣執行——唔會將數據送出工廠之外，亦都唔會有模型亂咁改嘢嘅風險。

基礎設施、合規性同工業界嘅目標

因為Orchestrator係喺企業自己嘅基礎設施上面執行——無論係公司內部嘅伺服器（On-premises）定係私有雲（Private Cloud）——生產數據全程都唔會離開公司大樓。呢種架構令到個系統喺設計上就已經符合GDPR同歐盟《人工智能法案》嘅要求。同時，亦都令到INXM可以接觸到一啲，淨係用雲端嘅自動化工具根本掂唔到嘅工廠車間軟件。

公司明確咁瞄準咗工業製造商同德國嘅Mittelstand（即係啲中小型工業企業）：呢啲公司本身有好多舊嘅內部系統、有好重嘅監管責任、同埋對可重複性有好高嘅要求。呢個並唔係一個乜嘢行業都啱用嘅橫向自動化玩法。佢係專門為嗰啲，一早已經拒絕咗通用型AI代理嘅企業而設嘅，因為佢哋覺得嗰啲代理喺生產環境入面信唔過。

INXM揸住呢570萬歐元嘅新資金，加埋一個出產過對安全要求極高嘅軟件嘅創始團隊，仲有一套將企業AI重新定義為編譯器問題、而唔係對話問題嘅技術路線，佢哋今鋪係賭緊，工業界採用AI嘅瓶頸並唔係能力，而係可靠性。