Swarms Chat 全部更新一览

Swarms Marketplace 上的每一个提示词，都可以直接在页面内与真实模型对话，无需跳转。打开一个提示词，点击 Chat，你就已经在和模型交谈，而该提示词已经作为系统提示词加载完毕。

这个界面最初只是一个消息输入框加一个模型下拉菜单。过去几周，它变成了一个完整的工作台：completions API 接受的每一个参数都可以调整，API 返回的每一个模型都可以选择，每条回复都会显示它的开销，整个界面在手机上也能正常使用。在这个过程中，我们还发现并修复了两个正在悄悄丢失用户数据的缺陷。

本文介绍已经上线的全部内容、每一项改动背后的原因，以及目前仍未解决的问题。

对话开场白，以及它为什么曾经需要十秒

空白的对话框是很难开始的。你打开了别人写的提示词，并不知道它擅长什么，光标只是在那里闪。现在 Swarms Chat 会针对你正在查看的提示词，推荐三个开场问题，它们由一个读取提示词本身的小型智能体生成。

第一个版本能用，但慢到失去了意义。生成开场白的智能体大约需要 10.3 秒。它在页面渲染完成之后才触发，所以从不阻塞任何东西，但推荐出现的时间远远晚于页面可用的时间，实际情况往往是用户已经自己开始打字了。一个在你不再需要它时才出现的功能，不算功能。

我们用真实任务对十个候选模型做了基准测试，每个模型运行二到四次并取中位数。结果非常明确：

更换模型带来了大部分提升，把系统提示词从十六行压缩到更紧凑的指令带来了剩下的部分。端到端来看，开场白现在大约 2.9 秒出现，快了约 3.5 倍，并且是在你还在阅读页面时出现，而不是在你已经放弃之后。

基准测试中有一个结论值得单独提醒直接使用 Swarms API 的开发者：gpt-5.4 搭配 tools_list_dictionary 时完全不返回助手输出，这也是开场白智能体改用其他模型执行工具调用的原因。

完全掌控智能体

聊天页头部有一个设置按钮，点开是一个分标签页的对话框：Generation、Behaviour、Tools 和 Marketplace。它开放了 POST /v1/agent/completions 接受的每一个 AgentSpec 参数，只有四个有意为之的例外。

agent_name、description 和 system_prompt 属于你正在运行的提示词，聊天界面不允许覆盖它们。model_name 属于模型选择器。其余的参数，包括 temperature、top_p、max_tokens、max_loops、推理强度以及工具配置，都交给你。

设置按提示词分别保存在浏览器本地存储中，这带来一个值得了解的具体结果：调整一个提示词永远不会影响另一个。你可以让一个研究类提示词保持高推理强度，同时让一个写作类提示词保持低推理强度，各自记住自己的配置。

这项工作改动了两个默认值。max_tokens 从 8192 调整为 32000，因为较长任务的回复此前会被截断。默认 reasoning_effort 现在是 low，这需要一点说明：把 reasoning_effort 设为 minimal 会让 API 返回空回复，我们在 claude-haiku-4-5 和 gpt-5.4 上都确认了这一点，而在 Claude 上设为 none 同样如此。low 是能稳定产出内容的最低档位。设置面板目前仍然提供 minimal 选项，在上游修复之前，选择它会得到空回复。与其假装它可用，我们更愿意把它写清楚。

覆盖全部模型的可搜索选择器

旧的模型下拉菜单只列出写死的一部分模型。API 新增了模型，选择器并不知道。

这个下拉菜单已被替换为可搜索的选择器，两个聊天界面都在使用，并且它现在会列出 Swarms API 通过 GET /v1/models/available 返回的每一个模型。当前列表涵盖 GPT-5.4 及更新版本、Claude Sonnet 与 Opus 5、Kimi K3、GLM-5.3、DeepSeek、Qwen、MiniMax 以及 OpenRouter 的模型目录。选择器中的每一个模型标识都经过核对，确认存在于真实的 API 响应中，而不是从文档里抄来的。

选中状态使用绿色，与平台其余部分保持一致，选择器的触发按钮与其他头部控件共用同一套视觉样式。

每条回复都显示 token 数量

Swarms completions 流式接口一直会发送一个包含输入与输出 token 数量的 usage 帧，而聊天的前端逻辑此前直接跳过并丢弃了它。

现在每条助手回复都会在复制按钮旁边显示它的输出 token 数量，数据来自该帧，而不是在客户端估算。这个改动很小，却改变了使用方式：当你能看到一条回复消耗了 4000 个 token，你会开始注意哪些提示词和哪些设置更昂贵，并据此调整。

重试、换个模型、继续生成

每条助手消息上现在有三个操作。

重试 会就地重新运行这一轮对话。它会替换原有回复，而不是追加一条新的，因此重试三次的对话不会留下三条几乎相同的答案把记录塞满。

换个模型 会用另一个模型重新运行同一轮对话，并且选择器会与你实际使用的模型保持同步。想判断一个不理想的回答是提示词的问题还是模型的问题，这是最快的办法。

继续生成 会接着一条被中断的回复往下写，无论是你手动停止的，还是触及了长度上限。

这三个操作在内部共用同一套流式逻辑，因此行为完全一致，不会各有各的怪毛病。

输入区

这里有若干改动，目标都一样：让文字和图片进入对话时不打断你的节奏。

• 用 Command V 直接把截图粘贴进输入框。
• 把文件拖放到输入框，或拖放到附件按钮上，后者本身也是一个放置目标。
• Command Return 始终发送。输入框下方有一个开关，决定单独按 Return 是发送还是换行，因为两种习惯都存在，而且都没错。
• 在空输入框中按上方向键，会调出你上一条消息以便编辑后重新发送。

表现正常的流式输出

三个单独看都很小、合在一起却改变体感的修复。

流式输出的头部有一个闪烁光标，让你能分辨模型是在思考还是已经卡住。回复出现时是一次轻微的淡入，而不是突然跳出来。

自动滚动现在会在你向上滚动时松开。此前在回复流式输出的同时回看历史记录，每来一段内容都会把你拽回底部。现在取而代之的是一个「跳到最新」的浮标，由你决定何时回到底部。

消息正文做了记忆化处理。输入框的状态此前和消息列表处于同一个 hook 中，这意味着每一次按键都会让整个对话历史重新经过 markdown 渲染。在长对话里，这和听上去一样慢。

两个正在丢失数据的缺陷

四张附件图片中只有一张真正到达模型。 聊天界面接受四张图片附件并显示四个缩略图，但请求体里始终只带上了第一张，其余三张被静默丢弃。现在请求会在 img 之外同时发送 API 的 imgs 数组，并且会对每一张图片都去掉 data URL 前缀，而不只是第一张。

这里有一个重要的补充说明，问题在我们的上游。我们针对真实 API 验证过：img 传纯 base64、传 data URL、传 https 链接，以及 imgs 传数组，得到的回复与不带图片的对照组完全一致。换句话说，API 接受了文档中描述的字段，但目前并没有把图片转发给模型。我们这一侧现在发送的结构是正确的，剩下的缺口在 API 侧，并已在那边跟踪。

一个错误提示可能让页面崩溃。 错误标题是通过一串回退逻辑拼出来的，而一个普通的 Error 对象是真值，于是它被选中并交给提示组件，组件试图把一个对象当作 React 子节点渲染，整个视图随之崩溃。现在上游错误在到达提示组件之前会被展平为字符串。

移动端

聊天界面做的是完整的响应式适配，而不是简单压缩。在中等断点以下，头部会收起为一个返回按钮、模型名称，以及一个统一的溢出菜单，其中包含联网搜索、设置、重置和全屏。桌面端那五个独立控件在手机上放不下，也不该硬塞。

输入区、消息列表、附件处理和设置对话框都针对小屏幕重新做了处理。

可靠性与访问控制

如果一次流式输出结束时没有产出任何文本，现在会以非流式方式重试一次，并把回复作为单个数据块返回。如果仍然为空，那个空气泡会被移除，并弹出提示说明是哪个模型没有产出内容，而不是在对话里留下一条空消息。

联网搜索使用普通的 completion 并设置 max_loops: 2，因为流式接口在工具调用循环期间不会输出任何文本。

聊天路由要求登录会话，并在服务端校验请求的模型，因此它无法被当作访问任意模型的开放代理。

一致性

提示词聊天和 Yuki 聊天中的用户气泡，现在使用与导航栏相同的深灰色。每一个头部控件共用同一个组件、同一套视觉样式，并带有说明其用途的悬停提示。从产品页进入聊天会直接打开全屏模式，而不是嵌入式视图。

仍未解决的问题

有三件事是已知且尚未修复的。

图片附件能够正确到达 API，但 API 并不会把它们转发给模型。这个问题在上游。

设置面板仍然提供 reasoning_effort: minimal，而我们测试过的每个模型在该档位下都会返回空回复。它应该被移除，或在界面中明确标注。

助手头像会让气泡相对输入框左边缘内缩 42 像素。修复它意味着把头像移出消息行，这属于布局调整而非宽度调整，因此这次有意没有处理。

开始使用

在 swarms.world 打开任意提示词并点击 Chat，或在 swarms.world/platform/registry 浏览完整目录。如果你想基于同一个 completions 接口自行开发，API 文档在 swarms.world/docs/api。