Chimera Agent 0.67.4 修复了打包桌面应用中的 Discord 机器人问题

上个版本引入的打包桌面应用，带着一个坏掉的契约发布了。如果有人安装了应用并指向一个 Discord 机器人，状态面板不会显示机器人正在运行，而是抛出一条以 ModuleNotFoundError: No module named 'discord' 结尾的调用栈。Agent 配置是有效的，Token 也没错，问题出在打包本身。

哪里坏了，为什么重要

问题源于两个设计决策，它们在发布构建时才发生冲突。第一，消息适配器——包括 Discord——被设计为懒加载。框架不会在启动时加载所有聊天平台，只在机器人配置请求时才导入对应适配器。这个设计保证了冷启动快、内存占用低，并且在所有可选依赖都齐全的环境中运行良好。

第二，发布构建使用了裁剪过的依赖集。承载 Discord 客户端库的 messaging extra 被标记为可选，因此在安装版应用中被省略了。PyInstaller 的分析器静态遍历导入图，看到隐藏在基于字符串的加载器背后的懒加载，便断定这段适配器代码是死代码。结果就是：一个有效的配置，运行时却无法执行。

对于构建 Agent 的人来说，影响很具体。任何定义了 Discord 平台的机器人，都只会在打包应用中失败。同一个配置文件从源码运行没问题，在容器里运行也没问题。这种不一致意味着桌面应用对一整类 Agent 来说是不可信的，而这类 Agent 恰恰驱动了最多的社区反馈。

修复方案及其对打包的意义

0.67.4 版本修正了依赖声明，使 messaging extra 随安装版应用一起打包。PyInstaller 现在将 Discord 适配器视为可达代码，并包含所需模块。无需更改配置，无需更新 Agent 定义。机器人状态面板会显示运行状态，而不是导入错误。

在这个简单陈述的背后，有一个维护者立刻采纳的更广泛的教训。懒加载是一种性能技术，创作工具需要尊重它，但打包工具需要被明确告知它的存在。隐藏导入始终是有意为之的架构设计，而模块缺失则是包清单与冻结过程之间的元数据断层。0.67.4 版本为 Discord 适配器弥合了这个断层，并为后续所有遵循同样懒加载设计的消息平台建立了模式。

现在该做什么

如果你正在运行 0.67.3 安装版应用，请从发布页下载 0.67.4 更新。打包应用的签名方式相同，可直接覆盖安装现有版本。更新后，重启任意 Discord 机器人配置，状态就会转为运行中，无需额外步骤。

如果你从源码构建 Agent 且从未碰过打包应用，则一切不变。通过 pip 以标准 [all] 标志安装的包，已经包含了 messaging extra。本次发布只影响打包的桌面应用。

本版本完整变更列表见 Chimera Agent v0.67.4。