Chataigne：免费开源的展厅设备编排枢纽

它到底解决什么

Chataigne 是一款免费开源软件，作者在官网上把它的定位说得很直白：不是给某一类设备用的专用工具，而是给"想用技术做展演、互动装置或原型验证的艺术家、技术人员和开发者"准备的一个通用中枢。官网原话是"它自己不会做太多事情"——这句话是理解它的关键。它不生成画面、不驱动灯光效果算法、也不是一个媒体播放器，它的角色是官网所说的"指挥（Conductor）"：站在项目中间，把多个软件、设备、传感器纳入同一套逻辑，按大局去调度它们。

对展厅工程来说，这正好对上一个老问题。灯光台说 Art-Net 或 sACN，投影机说 PJLink，播控软件说 OSC，中控主机说串口指令，传感器又是另一套协议，谁都不懂谁。要让"观众按一下按钮，灯暗下来，视频开始播，装置跟着动起来"这一串动作连续发生，中间需要一层能同时听懂多种协议、又能按条件把一路消息转成另一路消息的翻译兼调度层。Chataigne 做的就是这一层的活。

它是 GPL-3.0 协议下的开源软件，源码托管在 GitHub（benkuper/Chataigne），核心由一名主开发者持续维护，同时有一个贡献代码和模块的社区。这个背景决定了它整篇文章下半部分要讲的东西：它的边界，本质上是"个人加社区维护的免费项目"这种模式自带的边界，跟软件本身好不好用是两件事。

展厅哪道工序会用到它

方案打样与概念验证阶段。 投标或立项初期，常常还没有定下来最终用哪套专业中控，但甲方或评审已经要求现场演示一个联动效果——按钮按下去，灯要暗、屏要亮、装置要动。这时候没必要为了一个演示去启动正式中控的开发流程。装一台 Chataigne，把演示要用到的几路设备接上，搭一个最小闭环，几个小时就能给出一个可以现场演示的方案雏形，用来验证"这几家设备真的能联动起来"这件事本身，而不是等真金白银投进正式开发之后才发现协议根本不通。

单个展项内部的小规模联动。 一些互动展项的逻辑并不复杂，也不需要跟整馆的中控系统对接——比如一个独立的互动装置，观众靠近时深度相机检测到人，触发一段灯光变化加一段音效。这种规模封闭在装置内部、不需要跟整馆调度系统打交道的场景，用一套专业的整馆级中控去管未免小题大做，Chataigne 这种轻量的居中编排正好合适。

给两个互不相通的设备或软件做临时或长期的翻译层。 有时候甲方已经买好了某个软件或设备，它只支持某一种协议，而你手上负责联动的另一端说的是另一种协议，两边都不打算换。与其想办法让其中一方迁就另一方，不如在中间加一层能同时说两种语言的东西——这也是它在展厅集成圈子里被提起的最直接原因。

怎么获取，该下哪个包

官网就是 https://benjamin.kuperberg.fr/chataigne/，下载区按系统分了好几种包：Windows 64 位、Mac Intel、Mac Silicon（苹果自研芯片）、Linux 64 位、树莓派两种（对应 armv8 与 aarch64 两种不同的处理器架构，装错了跑不起来，重新确认树莓派型号再下载对应的那个就行）、以及一个专门给老系统准备的 Windows 7 64 位包。选包本身不难，难的是选通道。

官网把每个版本分成三条通道：稳定版、测试版、以及"bleeding edge"——每次代码有改动就会更新的滚动版本。官方自己在页面上写得很直接：这个滚动版本"很可能高度不稳定"，是给愿意帮忙提前发现问题的爱好者用的。展厅工程只认稳定版，这条红线不用讨论。想试新功能，另开一台测试机装 bleeding edge，别让交付机沾上滚动更新的不确定性。

Linux 版本发布的是 AppImage 格式，官方说明下载后执行一次赋权命令（chmod a+x）就能直接运行，不需要走系统安装流程，这是这类免安装可执行包的正常发布方式。

关于价格：Chataigne 完全免费，没有付费专业版、没有授权分级，这一点跟本站另一篇讲的 TouchDesigner 那种"免费版限死分辨率、商用必须买正式授权"的分层模式完全不是一回事。开发靠作者本人的时间投入和读者自愿捐赠（Patreon、GitHub Sponsors、PayPal 三条通道都在官网挂着）支撑，这意味着它的"免费"不是靠向企业客户收授权费反哺开发，而是靠爱发电——这一点对判断它能不能扛住长期商业项目很关键，下一节细讲。

还有一件小事值得说：官网首页本身提供简体中文页面，说明本地已经有一批中文用户，但这不等于软件操作界面默认就是中文——装完先自己在设置里看一眼语言选项，别假设。

最短可用路径

装完打开，看到的是一块空白的工作区，这是正常的——它本身不预装任何联动逻辑，一切都要自己搭。核心只有两个概念：模块（Module），每一个对应一路协议连接或一台设备，比如一个 Art-Net 模块、一个串口模块、一个 OSC 模块；规则（Rule），用连线的方式定义"模块 A 收到什么条件，就让模块 B 输出什么动作"。

最短验证路径是：先加一个模块，把它指向要连的第一路协议或设备，看模块面板里有没有数据在跳动——有变化说明这一路通了，一直不动就该去查连接参数或者对方设备是不是真的在发送。跑通一路之后，再加第二个模块代表联动的另一端，中间拉一条规则把两者接起来，触发一次后界面上能看到直观的状态变化，这就是一个最小可用闭环。具体每一类模块怎么配置、参数字段是什么意思，这一篇不展开成教程——展厅工程需要判断"要不要用、能不能扛得住"，怎么点鼠标交给实施的人自己在软件里摸，官方文档也够用。

展厅工程里真正要弄明白的那几件事

第一，它和专业中控不是同一类东西，分工要分清楚。 Chataigne 的强项是协议覆盖广、上手成本低、免费、能快速把异构设备接起来验证方案；它缺的是专业中控作为一款产品该有的东西——没有面向不懂技术的甲方运维人员设计的简化操作面板，没有官方技术支持渠道，也没有针对"无人值守、常年运行"这类需求做专门的产品化打磨（比如断电自启看门狗、操作留痕、权限分级这些，都要工程师自己在系统层面补）。判断标准很简单：临时的、内部的、规模小的、有技术人员长期跟进的场景，它够用；长期无人值守、要给不懂技术的现场人员一个简单面板、交付后要有人兜底的整馆项目，该上产品化的专业中控。本站自研的 企服君中控 SoftControl 就是按后一种需求做的，两者不是谁比谁高级，是场景不同该用不同的工具。

第二，开源免费背后是什么代价，谈方案前要想清楚。 它不是一家公司在维护，核心是一名主开发者加志愿者社区。出了问题，能找的地方是 GitHub 提交 issue、去 Discord 上问、或者上论坛发帖求助——这些渠道的响应速度取决于维护者的时间和意愿，不是一份写进合同的服务承诺。从代码仓库的提交记录看，这不是一个已经停更烂尾的项目，但它终究是个人维护的开源项目，具体现在维护得活不活跃，谈方案前自己上 GitHub 看一眼最近的更新时间，比这里写一个日后可能过期的判断更可靠。更现实的问题是交付给甲方以后谁来维护：甲方的 IT 团队大概率没接触过这个小众工具，出了问题第一反应还是回头找原集成商；如果做这套联动逻辑的实施人员后来离职或者换了项目，剩下的就是一堆没人看得懂连线关系的工程文件。要不要用它，本质上是在问"这套逻辑之后谁负责"，不是在问"它好不好用"。

第三，协议支持广度到底有多广。 官网首页把支持内容分成四类，逐条如实照抄：协议类有 OSC（内链见文末）、OSCQuery、MIDI、DMX、Art-Net、sACN、串口、TCP、UDP、HTTP、MQTT、WebSocket、PJLink、Ableton Link、PosiStageNet；软件类官方原生提供对接模块的有 Resolume、MadMapper、Millumin、TouchDesigner、Unity、QLab、VLC、HeavyM、DLight、Reaper、Ableton Live、PowerPoint、WATCHOUT、Augmenta；硬件类覆盖声卡、麦克风、键盘鼠标、Wiimote、Joy-Con、Kinect、游戏手柄、摇杆、Stream Deck、Loupedeck、GPIO。这三类是核心团队维护的官方模块。协议本身的报文结构和原理不在这里展开，站内已有专门的协议文章，需要时直接跳过去看：OSC、MIDI、DMX512、Art-Net、sACN、PJLink、MQTT、TCP/UDP、HTTP、WebSocket、串口（RS232/RS485）。

第四，官网单独列了一类"社区模块"，这类要另眼看待。 LeapMotion、ETC Eos、OBS、Blackmagic ATEM、d&b DS100、Behringer/Midas X32-M32、FlowToys、LightTOYS、VPT8、Lightshark 这些，官网明确归在"Community modules"这个独立分类里，跟前面官方原生维护的协议、软件、硬件模块分开列。这意味着它们是社区贡献者开发和维护的，不在核心团队的发布节奏里——某次核心版本升级后，某个社区模块的行为可能没跟上，甚至暂时用不了。项目里如果要用到这类模块对接的设备（比如现场灯控台是 ETC Eos，或者切换台是 ATEM），交付前务必用要交付的那个稳定版本，把要用到的每一个社区模块实际连一遍，不能只看官网图标列表就当它一定能用。

交付风险

工程文件本身要不要跟着交付文档一起存档，这是第一个要谈清楚的问题——用到的每一个模块、每一路协议连接的地址和参数、每一条规则背后的触发逻辑，都应该有文字或图示的记录，而不是只交一个二进制工程文件了事。它足够小众，接手的人如果没有原始记录、只对着一堆连线模块，基本等于从零摸索。第二个问题是模块依赖：前面说过部分设备对接靠的是社区模块，交付文档里最好写清楚用了哪些社区模块、对应哪个版本测试通过，免得日后升级时踩坑却找不到原因。第三个问题最朴素也最容易被忽略——做这套联动逻辑的人如果离职或者调去别的项目，谁来接手，这不是技术问题，是项目管理问题，最好在立项阶段就有答案，而不是等出故障那天才想起来问。

踩坑与排错清单

什么时候别用它

长期无人值守、要求出问题有人限时到场兜底的商业项目，别用它当唯一的中控方案。 它没有官方 SLA，也没有能打电话叫来的技术支持，出了问题能不能及时解决，取决于自己团队的技术储备，不是花钱能买到的保障。

甲方现场运维人员不懂技术、要求"装完就能自己操作"的傻瓜面板，也别指望它。 它的界面是给懂协议、懂联动逻辑的实施人员用的模块和连线工作区，不是面向非技术人员打磨过的成品应用；把它直接暴露给不懂技术的现场人员操作，出错的概率会比想象中高。

需要复杂实时图形渲染或生成式视觉效果的场合，它同样不是对的工具。 官网原话已经说得很明白，它自己"不会做太多事情"，定位是居中调度的枢纽，不是渲染引擎。这类需求该看本站另一篇讲的 TouchDesigner，两者的分工边界跟本文第五节讲的道理是一回事：先看清楚项目到底需要哪一层能力，再决定上哪个工具。

采购流程卡在"必须有正规供应商资质和发票"这道关的项目，走不通开源软件这条路。 它靠自愿捐赠支持开发，没有可以走账、开票的商业采购渠道，这类合规要求硬的项目，方案阶段就该换掉。

与本站的衔接

• 涉及的协议原理和报文结构，站内都有独立文章，本文不重复展开：OSC、MIDI、DMX512、Art-Net、sACN、PJLink、MQTT、TCP/UDP、HTTP、WebSocket、串口 RS232/RS485。
• 排查 Chataigne 收发的 OSC/MIDI 消息对不对，配套用本站的 Protokol——先确认消息真的发出去了，再回头查 Chataigne 里的规则配置。
• 同属"互动引擎"这一类、但定位偏渲染而不是编排的对比对象，看 TouchDesigner。
• 长期无人值守、需要产品化操作面板和有人兜底维护的项目，看本站自研的 企服君中控 SoftControl。
• 互动展项这条工序线上还有哪些环节要打通，从互动展项专题看整体思路；中控相关内容汇总见中控专题。

展项「悄悄坏掉」这件事

互动展项的故障有个特点：观众看不出是坏了，只会觉得「这个不好玩」，然后走开。没有投诉、没有报警，等甲方发现时可能已经这样运行了好几周。

企服君把展项的运行状态与感知设备的数据活跃度纳入监控，让这类沉默的故障能被及时发现。集成商如果交付的展厅里互动展项占比高，见集成商年费方案。

出处

本文事实依据来自 Chataigne 官网首页（含"About"定位说明、下载区各平台安装包与三条版本通道、"Supported protocols / software / hardware / Community modules"四个功能分类清单、"Community"页的支持渠道说明）：https://benjamin.kuperberg.fr/chataigne/；以及 GitHub 官方仓库页面与 API 核实的许可证信息（GPL-3.0）与仓库维护状态：https://github.com/benkuper/Chataigne、https://api.github.com/repos/benkuper/Chataigne。功能边界与支持渠道以官方最新页面为准，本文不涉及版本号与具体价格等易变信息。