Cross Session Messaging 的几个 Use Case 。 1\ 给它们组个棋局。 今天一直在想怎么有趣地和大家介绍这个功能，于是搞了个国际象棋的例子。 四个 session：裁判、解说、白方、黑方，中间放一个棋盘。裁判说开始就开始下，直到一方赢为止。是玩，但这一局把编排的骨架摆出来了：各持角色、一份共享状态、一个发令的。 2\ 同项目 session 自己对齐。 一个项目的多个 session 之间的沟通，比如对齐 api 对齐修改边界等。举个例子，同时开前后端的 Session 改项目代码，就可以让他们相互之间沟通 api 规范。另外比如一个项目下多个 worktree 沟通改动范围也是常用的场景。 3\ 个人觉得很好用的一个场景。 我下午做了一些不同主题的调研，其中一个是做 tmux vs. cross session messaging，我给他加了个 name 叫「tmuxanalyze」。然后在写文章讲「与 tmux的区别」时，那一段的提示词我就留了「ask session tmuxanalyze to fill this section.」 基于这个用法，一个 tip 是启动 claude code 或 qoder 时随手加个 -n,--name 的参数指定下。这样后面可以随时 peer 一下，从这个 session 那信息，或者往这个 session 补信息。这样，你所有开着的 session 就都互通起来了。 4\ 如果你用 qodercli，他也支持了这个功能，附一份上手指南。 先升级到 qodercli 1.1.19 或以上。qodercli --version 看一眼。功能 8.12 随这个版本上线，Beta，只有 macOS 和 Linux——它靠 Unix domain socket，Windows 上没有。 修改 ~/.qoder/.env 加上 QODER_FEATURE_CROSS_SESSION=1 开启这个功能。默认关。开完后用 /peers 验证下有没有这个 command。 如果不想每条消息都点一次 approve，修改 ~/.qoder/settings.json 加上 { "security": { "crossSessionInbound": "accept" } } 配置。 最后开两个 session，qodercli --name jack 和 qodercli --name mike，在 mike 里说「ping session jack」。 通了。

自从codex可以流畅地创建session（而不是subagent）、在session之间通信……真的省心了很多。我这个人类操作者更像当领导了，感觉坐在电脑前的必要性越来越少了，能靠嘴实现的复杂任务更多了……

Codex/Claude Code 现在都支持跨session访问会话了，还是挺方便的，比如我昨天在测试我的 App 在 Windows 的运行情况，先在某个测试 Project 中调用 BaoCut Skill 去做转录视频，发现第一次运行时下载模型体验很糟糕。 然后我到 BaoCut 所在源代码项目中，把会话的 Session Id 给它，让它去分析原因并给出优化方案，这样就不需要你自己去让 Agent 自己总结，也不用担心总结的时候会损失上下文，Agent 自己可以去会话中找所需的上下文。

DeepSeek Harness 团队提出「Super-agent」架构，解决多 Session 并发瓶颈。一个人只能同时跟 3-5 个 Agent Session，这是真瓶颈。 加一层 Router 统一分派、Worker 隔离并发，本质是给 Agent 集群做调度。300 条合成负载，p95 29.5→15.7 分钟；40 条 / 分钟时，单次推理 6.4 秒→1.6 秒。代价是缓存 token 涨 37%。竞争已转向怎么管几十个 Agent，但原型没定型、安全隐私没解，方向不错，先别太上头。

我做的那个同时管理几十上百个 session 的平台原计划是想做 2B，但我最近又想了下，这个生意模式有两个问题： 1. 现在 AI 逆向太厉害了，企业买去部署一次，逆向出来就不需要继续订阅了，全是一次性生意。 2. 如果不在企业本地部署而是上云，跟 Jev 一样，那么就有信任问题，客户根本不知道你在这个黑盒子里到底干了什么。 所以我现在就改变打法了，用这套平台直接批量实现我的大量想法，我的成本就可以压得非常低，在新加坡开一个 Studio 产出可以相当于一个中型公司。 我认为未来 20 人以内的 Studio 型 Startup 也会越来越多，极低人力成本，没有繁杂的组织架构，没有历史包袱，可以快速跟上最新的 AI 技术，人类只需要重要决策和担责。