从航天到车间：INXM 融资 570 万欧元，用“编译式 AI”为德国工业装上确定性引擎

创始团队：从火箭到可靠流水线

INXM 于 2025 年在柏林成立，四位创始人的履历中有一个鲜明的共同点——他们都在生命攸关、不容失败的领域积累了深厚的“确定性”经验：

• Alexander Oelling（CEO）：曾任火箭公司 Isar Aerospace 和空中出租车公司 Volocopter 的首席数字官，深谙如何在高风险环境中让复杂系统可靠运行。
• Matthias Kainer（CTO）：曾在 Isar Aerospace 构建火箭发射编排系统，那是一种容错率为零的软件。
• Jesper Bylund：曾设计飞行控制界面，并拥有在自动化平台 n8n 的工作经历，是连接用户体验与底层逻辑的关键人物。
• Kamil Klüber：软件咨询公司 Thoughtworks 的资深人士，为团队带来了深厚的现代软件开发与架构思维。

这支团队的航天基因并非光鲜的注脚，而是其技术哲学的基石。发射软件不能即兴发挥，每一次点火都必须遵循精确、不可变异的序列。现在，他们将同样的思维范式应用于企业 AI，彻底重构了自动化工具的工作方式。

为什么企业级 AI 代理总是“掉链子”？

当前大多数基于大语言模型（LLM）的自动化工具，其工作方式是“一步一请求”：工作流的每一个环节都要由 LLM 做出决策。这种架构对需要高度合规和稳定性的制造企业来说，存在三个致命的“阿喀琉斯之踵”：

• 非确定性：相同的指令可能在不同时间触发不同的行动或输出，这让合规与审计无从下手。
• “幻觉”风险：一个在审批流程中擅自增减步骤、或被允许跳过安全检查的 AI 代理人，在车间或金融系统里是无法接受的。
• 数据主权问题：将敏感的实时生产数据发送给第三方 AI 提供商的 API，与欧盟的《通用数据保护条例》（GDPR）和即将生效的《人工智能法案》（AI Act）直接冲突，也令企业内部安全政策难以招架。

最终的结果是，大量工业公司在 PoC（概念验证）阶段对 AI 代理赞不绝口，却因不可靠性而迟迟无法投产。演示起来无比强大的技术，却难以达到工厂车间数十年来已经习以为常的可靠性门槛。

“编译式 AI”如何创造不同？

INXM 的编排引擎 Orchestrator 借鉴的不是循环往复的聊天逻辑，而是传统编译器的架构。一个工作流的落地被清晰地切分为两个阶段：

1. 编译阶段：用户用自然语言描述一个业务流程（如质检、审批）。一个 LLM 接受该意图，并一次性生成一份结构化、可执行的“计划（Plan）”——本质上是一段具有确定性的代码。这份计划在被放行之前必须经过验证。大模型只在此刻被调用一次，不直接参与后续的生产运行。

2. 执行阶段：经过验证的“计划”在 INXM 的 Orchestrator 引擎上独立运行，不再调用任何 LLM。引擎将横跨企业现有的系统（如 ERP 企业资源计划系统、PLM 产品生命周期管理系统、MES 制造执行系统、邮件、审批工具）协调工作，每次都以完全相同的顺序执行相同的步骤。数据从未离开建筑物，幻觉风险被物理性隔绝。

这个技术差异是鲜明的：传统 AI 代理在每一步都调用 LLM，代价是昂贵、非确定性且难以审计；而 INXM 是“编译一次，稳定运行”，由此获得了自然语言的灵活性，但输出却拥有传统编译代码的稳定性和可测试性。

更通俗地理解，设想工厂里的一个质量检查工作流：工程师用普通语言描述需要的审批步骤和检查指标，Orchestrator 将其编译为一组固定序列，经理审核批准一次，此后每当相关事件触发时，这段工作流就雷打不动地运行，绝无即兴发挥的风险，也无需向外发送任何数据。

基础设施、合规与工业靶向

由于 INXM 的 Orchestrator 运行在企业自己的基础设施上（本地或私有云），而非任何外部服务器，其架构天然合规。敏感的生产数据从未离开本地，这符合 GDPR 和欧盟 AI 法案的设计要求。此外，这一架构也能让 INXM 触达那些仅靠云端自动化工具根本碰不到的工厂车间级私有软件。

INXM 瞄准的不是一般意义上的自动化市场，而是德国乃至欧洲那些拥有传统本地部署系统、严格监管义务和对可重复性有着刚性要求的工业制造商。它不是万能平推的通用工具，而是专为那些已经因不信任而否决了普通 AI 代理的企业，提供一个可靠的技术“答案”。

凭借 570 万欧元的新资金、一支成功交付过安全关键型软件的团队，以及将企业 AI 从“对话问题”重构为“编译器问题”的技术思路，INXM 正朝着一个方向下注：阻挡工业 AI 落地的不是能力，而是可靠性。