SpaceXAI 发布 Grok Build v1.0.41 更新

把 v1.0.41 的改动清单放在一起看，主线并不难辨认：它处理的几乎都是“跑得久、跑得多、跑得散”时才会暴露的问题。子智能体继承模型设置、持久化配置、按模型区分请求大小上限、长推理提醒、MCP 服务器配置处理，以及崩溃会话显示被中断轮次——这些条目单独看都很琐碎，但指向同一个使用场景：多个子智能体长时间协作。

发布者本人也给出了同样的判断，称“这里的大量工作显然聚焦于让长时运行的多智能体工作流更可靠”。需要说明的是，这是发布帖作者的评述，属于来源方的判断，而非可独立验证的结论；但改动清单本身与这一判断方向一致，可以视为对清单的合理归纳。

清单中唯一一项面向终端用户的新能力是 sports_Search 工具。按发布帖描述，它用于获取 NFL 的实时比分、排名、赛程、球员数据和球队战绩，数据直接来自 𝕏。

这里有两个需要分开看的点。其一，工具的存在与用途是发布帖明确列出的内容；其二，“实时”这一属性以及数据质量，来源并未给出任何独立验证或指标，因此只能按来源说法理解，不宜当作已确认的能力水平。此外，清单没有说明该工具是否覆盖 NFL 之外的联赛，也没有给出可用范围或地区限制。

子智能体现在可以继承模型设置，并支持持久化配置。评论区里有一条反馈直接点出了这项改动的实际价值：“继承设置这点不错，没人想同一件事配置五遍。”这条评论来自 X 上的用户回复，属于旁观者评价，但它与改动本身要解决的问题吻合。

与之配套的是按模型区分的请求大小上限。发布帖称其目的是更好地控制供应商上限和内联图片。把这两项放在一起看，可以推断（此为推断）团队在应对多子智能体并发时，配置一致性与请求体积是两个主要的摩擦点；但来源没有给出任何具体上限数值，也没有说明默认值或可调范围。

清单还包含两项偏“过程控制”的改动：一是新增长推理提醒，用于在长时间推理过程中让模型保持在轨道上；二是改进 MCP 服务器配置处理。

这两项都没有附带实现细节或效果数据。可以确认的是它们被列为本次发布的重要变更；至于提醒机制以何种形式触发、MCP 配置处理具体改了什么，来源均未说明。因此这里只能停留在“已列入变更清单”的层面。

在可靠性相关的条目中，最具体的一条是：崩溃的会话现在会清楚显示被中断的轮次，而不是静默丢失。这一改动之所以值得单独提出，是因为它把一类原本不可见的失败变成了可见状态。

评论区对这条改动的反应也最直接，有用户追问“静默丢失会话”作为已发布特性存在了多久。这条追问本身不构成对历史版本的确认，只能说明该问题在用户侧引发了共鸣。来源没有说明此前版本的具体行为细节，也没有给出崩溃率或恢复成功率之类的数据。

清单最后列出了一批修复，涉及子智能体生成、排队提示、插话、编辑块以及 effort 级别选择。这些条目同样没有细节，只能确认它们属于本次发布的修复范围。

需要明确的是，以上全部内容都来自 X 上的一条发布帖及其评论区。没有第一方发布说明、版本日志或独立测试作为交叉验证。因此版本号 v1.0.41、各项改动内容属于来源方陈述；发布者关于“聚焦长时多智能体可靠性”的总结属于来源方判断；而关于这些改动实际效果的评估，目前没有任何可验证依据。