看看这个产品https://cohub.live/

回复 joye： 看了官网和文档，也顺手查了下底座。我的判断写在下面。 一句话定位：Cohub 不是聊天产品，是「给人 + agent 共用的带真机的共享工作区」。它的官方循环是：建 Space → 和 agent 聊 → 改文件 / 在沙箱里跑 → Save 一个检查点 → 把文件、目录或正在跑的端口发布成 App。文档原话是「这条循环就是产品，其它都是它的延伸」。 几个真的有点东西的设计，跟同类产品拉开了距离： 一是房间即上下文。同一个 Space 里所有人共享上下文，聊天不是私聊线程，你可以接着别人那一条继续聊，也可以从任意一条消息 fork 出自己的一条线。这跟 Slack/微信「私聊 + 频道」的模型是反着的，它是把「房间」当成上下文的单位——小圈子里很舒服，进团队就要面对权限和成本问题。 二是每个 Space 配一台真机（cloud sandbox）：监听公网端口的进程自动变成预览和你可发布的 App；支持定时 prompt 当 cron 用；还有 Space hooks，在「一轮结束」「文件变更」这类事件上跑脚本，带过滤条件决定什么时候触发。也就是说它默认 agent 会一直在，你不在的时候也在干活。 三是发布的东西是活的，不是截图。从文件、目录或端口发布，访问者打开就能玩；官方还特别提了一句，App 可以反过来改它背后的 Space。这条挺关键，等于 App 和它的生产环境是同一个东西。 四是上下文复利。@space 可以把另一个 Space 当上下文拉进对话，/ 唤起可复用的 skill，从某个 Save fork 的时候文件一起带过来。它想解决的是「每次开新对话上下文群友 7439」这件事。 五是接口统一。web、手机、Discord、WeChat、终端跑的是同一个 Space，CLI 和 SDK 暴露的是和 UI 同一套面。文档里还专门列了 UI 词汇和 API 词汇的对照（Chat/Session、Save/Checkpoint、Task/run），这种把产品语言当契约的做法，是认真做 SDK 的团队会干的事。 底座和出身：官网写着 agent runtime 建在开源的 pi harness 上（GitHub 上是 earendil-works/pi，就是你现在用的那条 pi 线），Apache-2.0、可自托管，还强调自己是「在一个公开的 Cohub Space 里开发自己的」，dogfooding 直接摊在台面上。npm 上的 SDK 包名是 @neta-art/cohub，团队应该是 neta-art。「每周有数十亿 token 流经 Spaces」这类数字没法核实，看看就好。 放在赛道里看它赌什么：Anthropic 的 Artifacts、OpenAI 的 Canvas 是「单会话 + 产物」；E2B、Cloudflare 和 Vercel 的 Sandbox 卖的是沙箱基础设施；Devin、Cursor 后台 agent 是单人 coding agent。Cohub 的差异化不在模型上，而在两个边界：上下文归房间而不是归个人，产物是能访问的活服务而不是一个交付物。说白了是把单人 coding agent 的模式搬进一个多人房间。 我的几个疑问：一是「聊天不私密、全员共享上下文」在小圈子里是卖点，进真实团队就是权限、审计和误操作问题——谁都能改文件、跑命令、发布 App，出事谁负责；二是定位有点宽，同时像 Replit、像 Val Town、像 Discord、又自称 agent OS，这种「全都要」的产品最后卡在留存和心智上；三是成本，真机沙箱 + 常驻 agent + 定时任务，免费试用能撑多久是关键变量。现在还是早期，文案和文档都很漂亮，真正要看的是忙时段能不能稳稳跑住。 值得盯一下。要是你想，我可以去扒它的公开 Space 或者 SDK 文档，看沙箱调度和权限模型具体怎么做的。