Artifacts，但 多人版
几年前，「AI 用一句话生成一个能运行的界面」还是发布会上的高光时刻。现在它已经是标配。Claude Artifacts 是 Claude 的正式功能，随时可用——你描述一个工具、一张图表、一个小应用，就能在对话里拿到一个实时可交互的界面。持久状态、直接调用 API、连接外部服务：artifact 不再是静态输出，而是一个运行着的东西。
这是一个真实的转变，值得直接点出来：把一段对话直接变成交互界面，已经成为主流预期，不再是什么新奇事物。我们认为这对整个领域里的每个人都是好事。
但它也让一个一直埋在这个品类底下的问题变得更清晰。一旦界面容易生成，有趣的变量就不再是 AI 能不能做出来，而是谁在那个房间里。
Artifacts 做对的事
核心思路是对的，这也是这个模式传播那么快的原因：
- 对话是描述你想要什么的好地方。
- 界面是使用它的好地方。
- 缩短两者之间的距离——描述它、得到它、用它、通过继续对话来迭代它——消除了大量摩擦。
对一个人独自解决问题来说，这个循环确实很有力。你不需要再把生成的代码复制到别的工具里再接线。你要的东西就在那里，实时运行，继续聊就能继续迭代。
上限：一个助手，一个 artifact
一旦工作不再是个人活动，上限就出现了。
助手对话在设计上是一个只有两个人的房间：你和模型。所以它生成的界面是在单助手对话里的一个 artifact。而真实工作很少止步于此。一个发布计划需要产品、研发、市场一起来。一次分析需要有人拉数据、有人建模型、有人做结论复核。一个 dashboard，只有当能做决策的人都能看到它才有意义。
在单助手模型里，界面是你拿着的东西。要把别人拉进来，你需要导出它、截图、粘链接、重新解释上下文，然后手动把每个人各自后续的处理结果拼在一起。artifact 是你和模型协作生成的——但最终落地时，又成了一件需要你自己去缝合的东西。
这不是 Artifacts 的缺陷。这是它所在的房间的属性。
当界面变成多人的，会发生什么
Bloome 从一个不同的房间出发。它是一个 agent 原生的群聊：人和多个 AI agent 都是同一段对话里的正式成员。生成的界面——Bloome widget——不属于某个参与者的私有会话，它住在共享的房间里。
具体来说，同一个交互界面拥有：
- 不止一个人站在它面前——真正使用它或做决策的人已经在对话里了，不需要等待导出；
- 不止一个 agent 在它背后——你可以让一个专家 agent 生成界面，另一个来审查或扩展，第三个负责接数据，每个 agent 保持自己的判断，同时作用于同一个界面；
- 共享的实时状态——因为 widget 在整个房间里同步，一个成员对它做的操作，所有人都能看到。它是共享空间里的一个活的对象，不是到处传递的快照。
这个差异在一句只有多人房间才说得出的话里最清晰：
"你们三个帮我做一个对比视图——一个拉定价、一个拉功能矩阵、一个负责布局——我们其他人边看边给反馈。"
在 1:1 的助手对话里，这个请求无处落地。只有一个 agent，一个用户。在一个有多个 agent 和多个人的房间里，这就是工作本来的样子。
Agent 原生加多人，是一个不同的品类
很容易把这读成「同一个功能，更多席位」。但实际上两件事在叠加：
多人改变的是界面面向谁。你一个人搭出来的 artifact 是一份草稿，之后还要去各处说服别人。在决策者已经在场的房间里搭出来的界面，从它诞生的那一刻起就更接近完成。
Agent 原生改变的是谁能搭和维护它。当 agent 是对话的成员而不是玻璃另一侧的单一助手时，生成和演进一个界面就变成了专家之间的团队合作——就像真实组织完成事情的方式，不同的人各自负责不同的部分，在一个共同的地方汇合。
我们之前写过让这个房间可靠运转的难点——一套 agent 协作协议，让多个 agent 能协同工作而不相互干扰；以及为多人场景而设计的记忆，而不是为一个人对一个助手设计的记忆。共享的交互界面，是同一个赌注的可见尖端：杠杆不只在于画出界面的模型，更在于界面所在的房间。
结语
Artifacts 走向主流是验证，不是终点。从对话生成交互界面正在成为基础能力。真正尚未解决的，是围绕它的环境——那个界面是一个你需要传来传去的私有 artifact，还是一个让人和一整支 agent 团队能够同时搭建、观察、修改的共享界面。
Bloome 是我们对第二种的尝试：不是一个助手交给你一个 artifact，而是一个共享的房间，人和多个 agent 在同一时刻围绕同一个界面协作。
