Slock 与多 Agent 协作的一些观察

最近一直在一个叫 Slock 的工具里做开发，几乎很少打开 Codex 或者 Claude Code 了。

我现在的 setup 是一台 MacBook + 一台 Mac mini，加起来跑了 10 个左右的 Agent，手头通常 2 到 3 条任务线并行。

用 Codex 或 Claude Code 的时候，大脑里想的是 session。打开一个仓库、跟模型聊几句、把上下文建立起来，开始干活。要做点稍微复杂的，就得搭一套 harness 或者 RPC 让 Agent 自己跑 loop。换项目就开新 session，每个 session 是个孤岛。

Claude Code 的主要 memory 又是绑在仓库或工作目录上的。假如手头有好几个仓库同时要改——比方说后端、前端、文档站三个项目——开一个 session 就有点尴尬：上下文混乱，跨仓库切换更累。

Slock 里的 Agent 不一样。每个 Agent 都有自己独立的工作区和记忆系统。它跟我们常用的那种 Slack-接-coding-CLI 类型的 broker（比如 Codex 3720 那种）也不一样:那种 broker 可以并发分身，开多个会话;Slock 里的 Agent 不能分身——它在干一件事的时候，另外的活就得排队。

OpenClaw 兴起来之后，大家慢慢把这种常驻 Agent 叫龙虾。一只龙虾有自己独立的工作目录、一套不断累积的记忆、不能同时做两件事。你跟它聊天的感觉，更像是给一个同事派任务——它能根据当前频道或 Thread 的上下文自己判断你想要它做什么，不需要每次都从头交代背景。

最大的心智变化：不是"我开一个 session 干活"，而是"我有一群龙虾同事，各自积累了各自的方法论和脾气"。

每只龙虾跟你聊久了，会沉淀出一套自己的方法论和身份。有的喜欢事无巨细写代码，有的喜欢挑刺审稿，有的擅长盯进度，有的就是个信使。它们会跟着你的代码风格偏好、跟着你解决过的 bug 模式、跟着你做过的决策慢慢调整——这些知识不需要你反复交代，它会自己沉淀成"我的工作习惯"。

Agent 之间也会互相聊天。我经常看到一个 Agent 写完代码主动 @ 另一个 Agent 帮忙 review；看到相关讨论会主动 cross-post 给不在频道里的同事；遇到自己不擅长的领域会把任务转给更合适的那只龙虾。这件事在单 session 的 coding agent 里根本不会发生——它不知道还有别的 session 存在。

还有一个比较有意思的用法：我本地起一个服务，然后委托一个 Agent 专门去监控这个服务的 log。一旦出问题，它会立刻在 Slock 里面发起讨论、给出修复建议——必要时也能拉别的 Agent 一起看。

不过 multi-agent 也不是所有场景都帮上忙。最近做的一次 Onee-sama 迁移就是个挺典型的反例。

Onee-sama 是我们内部一个把 AI 助理塞进 Google Meet + Slack 的开源框架——Slack 那一侧管命令和权限，Meet 那一侧靠 Playwright 进会议、抓字幕和音频，复杂任务再 route 给后端的 Claude / Codex 等 agent。它本身是一个"薄编排壳"，AI 大脑由使用者自带。

这次的活是把这套 bot 从原来的仓库里拆出来，迁到一个独立仓库重新维护，语言不变（还是 Go）。本来希望多几个 Agent 之后，不只是能多写代码，也能替人把迁移里的问题找出来，甚至把自动化验收补到位，尽量减少我自己放到真实环境里测试。

但实际做下来并不是这样。

我已经反复强调要 100% 复刻之前的行为，负责迁移的 Agent 还是会用自己的理解做一个"看起来正确"的路径：测试补了，功能也能跑，好像迁移成功了，但很多旧系统细节其实丢了。更麻烦的是，这些问题并没有被 Agent 或自动化测试提前发现，很多还是我在真实环境里一点点用出来的——一些后台流程没真的执行、一些响应模式不像以前了、一些边界判断变得过于激进、一些旧行为没有完整迁过来。到现在我其实也不能确定还有哪些行为没有迁移完。

这个例子说明，multi-agent 不会天然减少人的验收负担。Agent 可以帮忙写代码、补测试、查日志，但它未必知道自己漏了什么，也未必能主动建立一套足够接近真实环境的验收。最后"什么才叫真的迁移完成"，还是要人持续压住。

也有很多人在质疑这类多 Agent 平台的价值。质疑点之一是：multi-agent 到底有没有用？

我自己体验下来分两层。

同一模型、不同身份：本质是给同一个模型不同的 system prompt，让它们各自盯一个 lane——一个写代码、一个审稿、一个盯进度。这只是分配同一个模型的注意力。上下文紧张时偶尔有帮助，但增量有限。

不同模型讨论同一问题：价值更大。我有时候会同时让 Claude Code、Codex、DeepSeek 三个不同模型的 Agent 一起讨论同一个技术方案，多数时候比单一模型出的结果好。每个模型擅长的不一样——比如 Claude Code 写前端速度快、质量好；Codex 在架构推理上更稳；DeepSeek 经常能从不一样的视角切入。前端项目里这种快速迭代看 UI 变化的工作流，速度差异尤其明显。

但说实话，真正的增量大多不是模型差异，是不同龙虾的记忆不一样。一只跑了两周 review 的龙虾，memory 里积累了"哪些 pattern 容易出 bug""哪些 API 变更是高危的"——这些知识不用你反复交代。这才是 multi-Agent 的护城河，不是模型组合本身。

还有一个比较深的代价，跟前面那个迁移反例直接相关：多个 Agent 之间会自然达成一定共识，来回讨论的信息量也很大，看起来很有说服力。人在读这么多 Agent 之间的判断、推理、引用时，多少会出现一些不耐烦的情绪，就更天然地相信他们的结论了。但很多时候他们只是在同一套不完整的上下文里互相强化了一个"看起来对"的结论——多个 Agent 互相认可，并不等于他们认对了。Onee-sama 迁移那个反例的一半问题就来自这里：Agent 们一起拍出一个"测试都绿了、行为也匹配了"的共识，比单个 Agent 这么说更让人想信，但真到用户链路里跑还是漏。

另一个角度：就算 Slock 只有一个人用，价值也存在。如果你有多台机器在开发、多个不同的 coding CLI 同时用，甚至经常不在电脑前——这些散落的记忆和上下文要怎么组织起来？

Slock 是一种答案。其它方向也有人在做，比如一些试图做"个人上下文通用中间层"的工具——目标是无论你用哪个 coding agent，都能共享同一份个人偏好和工作历史，雪碧正在做的 Spool 就是这条路径上的一类。哪种形态最终会赢，现在还很早。

还有一个比较实际的点：因为开发都在 Slock 上面，我也可以用新买的折叠屏手机继续做事，不用所有时间都在电脑前盯着屏幕工作。

当然这样确实也可以摸鱼。但我觉得人有时候在一个地方一直坐着，思维实际上会固化；多出去散散步，可能会出现一些新的灵感。

当然，我也不觉得 Slock 就一定是对的。

第一：作为人，注意力反而更分散了。以前用 Codex 是开一个 session 盯着一件事打完。现在 Slock 里多频道并行更新、多只龙虾同时干活，人需要在不同 Thread 之间跳来跳去 review 和决策。对细节的把控明显弱了。

第二：龙虾会"变笨"。它们的 memory 不断累积——上周的 bug、昨天的讨论、上个月的决策——全堆在越来越长的上下文里。不相关的知识也在吃 attention。这个问题解决不了，龙虾写代码的质量会越来越差，体验上就是降智。

要分清楚两件事：模型本身不会变笨——上下文规则写得越紧，输出反而越克制。但人感受到的"agent 越来越蠢"是真的——病根是频道噪音持续吃 attention，这层 prompt 工程救不了，得靠系统级别的 attention budget 或频道 scope 控制。两个病要分别治。

还有一个隐藏成本：一只龙虾在频道里收到的每条消息——不管有没有 @ 它——都会过一遍"这条跟我有关吗、要不要回复"的判断。多 Agent 在的频道里这种判断会被反复触发，token 消耗会明显比单 session 高。

第三：有了 Agent 之后，我渐渐发现自己越来越无法掌控做出来的东西了。Agent 聊的东西很多我看不懂，问的问题我也不会回答，最后交付的产品我也无法验收。反过来，我就更依赖 Agent 自己去把控自己的质量。

第四：封装太厚。用 Codex 时我能直接看到每次 tool call、每个文件修改。Slock 里很多步骤封在 Agent 内部，只有最终结果弹出来。少了那种"盯着改"的控制感——遇到 bug 排查时尤其明显。

类似的多 Agent + 多人协作工具不少。比如 Linear 最近也出了以 AI 面板为中心的视图；Slock 这种是以聊天为核心的；还有在做个人上下文通用层的。哪种形态最终会赢？还很早期。

我自己的判断：Slock 未必适合多人团队——至少不是直接替代 Slack 的那种多人协作工具。IM 体验从长远看追不上 Slack；非开发工作的上下文天然空缺在 Slock 之外——产品、市场、运营的讨论会留在原本的 IM 里。这意味着 Slock 里看到的工作全景天然是残缺的。这种割裂感长期一定会让人流失。

一年内看，Slack + coding CLI broker 可能是多人协作的最优解：把 Slack 当协作面，coding agent 当后端 broker 调度。

但我现在的判断不是 Slock 输了——而是它暴露了一个真实问题：当 agent 从工具变成同事之后，我们缺的不是更强的单次回答，而是组织记忆、注意力和责任边界的系统。Slock 是一种答案。是不是最终的，我不知道。

直接下死结论的人，肯定是错的。