先讲个具体场景。业务方发现一个问题，按老办法他会直接 ping 我："这里好像有点问题，你看下？" 然后接下来半小时，我其实并没有在解决这个问题——我在追问。背景是什么？怎么复现？你期望的结果是什么？当然有时候有些同事比较不错，会把背景、问题、复现路径给到我，甚至也用 agent 帮忙找过问题。但大多数人，都是上来直接甩问题过来，导致沟通的比较费劲。
这半小时干的就是一件事：我就是一个人肉调度器，把 context 从他脑子里搬到我脑子里，然后我再搬给我的 claude code / codex，再回复他去确认问题，来来回回反复几次——他背后可能也是一个 agent copy 我的回答。
传统协作里真正费时间的就是这个：上下文在人脑之间反复转述。执行的人做事，组长压一遍，老板听汇报；每过一道手都掉一点信息，每过一道手都自然带点包装，每过一道手都还要重新对齐一次。Slock 这类工具真正在加速的不是聊天本身，是「意图 → 执行 → 证据 → 判断 → 下一步」这一整条链路。
所以我现在关心的问题已经不是"我怎么听到真实的汇报"，而是另一个问题：怎么让 agent 替我先消化 context，把真正需要我判断的那一小块挑出来。所谓 Context not control， Agent 有所有的上下文，他能做的更快，他不嫌麻烦，上下文足够的话，我能从他那获取所有我想要的信息。
我想象中的协作方式是这样：业务方先跟自己的 agent 说一遍。他的 agent 帮他把一份 evidence package 整理好——现象是什么、怎么复现、有哪些证据、他期望的结果、已经试过哪些方案——然后打包发给我的 agent。我的 agent 收到之后先做一遍审核：缺东西就直接退回去，让对方的 agent 自己补全。等两个 agent 把事情谈清楚，最后到我手里时，剩下的就只是"判断"这一步，如果需要有大的架构变动则是发我文档，小 feature 和 bugfix 应该 mr 已经提给我了。
整篇文章就围绕这一个场景展开。我想了很多事情。
这条链路上有三站，每一站都是一个「人 + agent」组成的 pod。业务方 + 他的 agent，是 A pod；我 + 我的 agent，是 B pod；老板 + 他的 agent，是 C pod，按需出现。
pod 内部，人和 agent 是平等的。人负责定义标准、看关键证据、最后拍板；agent 负责收集、执行、整理。两边合起来就是一个协作单位——没有上下级，也不是替代关系。
真正"单向"的是 pod 之间的工作流：evidence package 往下走（流向执行的人），decision package 往上汇（流向拍板的人）。但单向只发生在 pod 之间，pod 内部人和 agent 一直在双向沟通。
这些 pod 也不一定挤在同一台机器上。业务方的 agent 可能跑在他自己的环境里，我的 agent 跑在我的 mbp 上，老板的 agent 在他那边。换句话说，agent 是一层共享的基础设施——它 host 在谁的机器上、由谁出算力，是另一层独立的事情。
以前协作里最浪费时间的就是各种来回对齐：A 找 B，B 又去问自己的 agent，A 的 agent 又来 ping，C 又插一句……一件事来回转十几趟。pod 模型把这条链路压成单向，是因为 agent 本身就带着完整的上下文——A 的 agent 不是传话筒，它把 A 当时讨论的整条 thread、所有历史、后来追加的条件都一起带过来了。B 不需要再回去问 A 一遍。
可能会有一种场景，老板可以直接问到我的 Agent，我最近在干嘛，我有哪些提交，我写了哪些文档。
人工作的 Context 都是 Agent + 工作电脑 + 开发机 + git repo + doc ... ，老板只需要问一下我的 agent/computer ，我这周在干嘛，有没有往他的目标上走，我也不用汇报，大家只需要通过 Agent 工作就行。
~~比如我自己，我上班最讨厌的就是写文档了。~~
但 pod 之间单向，并不等于人就能闲下来。
真正决定一个人注意力消耗的，是每一份输入输出的"第一读者"是谁：
这一份我自己看，还是让我的 agent 先看？
一天下来 N 个这样的小决定加起来，就是当天注意力的总损耗。"我先看"意味着所有东西都进我的认知预算；"agent 先看"意味着 agent 替我把它压成一份 evidence 或 decision package，只有当升级条件触发时才浮上来——比如：这件事不可逆、要花钱、需要授权、影响线上、是跨业务的 tradeoff、agent 自己拿不准、或者超出了我已经写下来的标准。
换句话说，新的协作并不是让 agent 替我看一切，而是让我有权决定：哪些输入先让 agent 消化掉，哪些输出先让 agent 质检一遍，哪些节点必须回到人。
那 agent 怎么知道你的标准？很简单：把它写下来。
以 leader 的评价为例子，当然这里比较班味，我其实也想说你也得坚持自己的主见hh，不过用这个例子比较形象，就以面向老板工作为例子吧。
老板平时在 review 的时候会盯哪几样东西、不接受哪些 tradeoff、对哪类风险特别敏感——这些就是他的"品味"。这套品味本来只活在他自己脑子里，散落在过去无数次 review 对话里，也只有他自己能调用。
但这套品味是可以炼化出来的：写进 prompt、写进 checklist、写成一个 review skill。不一定要做成独立的 agent，一段规则就够。然后让执行 agent 跑完事情之后，自动 loop 进这个 skill 自查一遍——明显有问题的退回去改；通过的内容顺手生成一份"给老板的回复模板"。写下来的那一刻，这套品味就从一份私人经验变成了可复用资产。
中层不会消失，但工作内容会变：从"传话、包装、追进度"，变成"定义 evidence 的标准、训练 reviewer agent、判断风险、做关键 tradeoff"——一种更难的中层。
还有一个挺现实的边界：一个人能稳定并发的"活跃决策线"大概在 5 到 10 条左右，再多就需要分层——要么训出一个 agent 来当二级 lead，要么补一个真人副手。所以"扁平 + AI-native 工程师"不等于无限扁平，只是中层的密度变了。
最近几周我一直在试 multica、slock 这类多 agent 工具，反复想说服自己"这套东西对我的个人开发场景到底需不需要"。试到最后答案是：不需要。这套东西真正解决的是人和人之间通过 agent 沟通的问题，目的是把人的注意力损耗降下来；它不是为单人写代码、单人调项目这种场景设计的。
单人开发的最优解还是直接用 coding agent，让它的上下文专注在一件事上。不过这两条路其实可以串起来：让 IM 那一侧的 agent（我管它叫 IM agent）把外面来的需求和问题打成包、上传到 Lark，然后我本地的 coding agent 再把这些 issue 拉下来，一个一个地专注做——效果反而可能更好。
回到单人场景。如果你只是一个人在做事——比如调一个项目、写一段代码、推一篇分析——这套多 agent 协作并不是最优解。更高效的方式还是**多开几个 thread 或 session 跑 cc/codex，可以让多个agent在决策/review阶段互相参与，但是我认为还是一个 agent session 一直跑效果更好，**而且现在 Agent 的压缩也现在越做越好了。
原因有几个：
这里要补一句，我其实很认可 Slock 这一层抽象。它把 agent 变成协作里的控制面：谁来响应、谁来补 evidence、谁来推进下一步，都可以在 channel / thread / task 里被调度起来。对于小团队，尤其是没有重 IM 基建的小创业公司，这套 abstraction 可能非常顺手。
但在大部分公司里，IM 已经是事实上的办公入口。尤其是飞书现在已经很积极地拥抱 Agent，如果飞书原生有一个个人 agent 看板，能把「我有哪些 agent、它们在哪个 thread / task 上、现在卡在哪、哪些输出需要我读」直接收拢起来，那接入审批、文档、会议、项目、知识库这些办公工作流会更自然。这个时候 Slock 更像一层可靠的 Agent 协作 control plane，而不一定要成为最终的工作入口。
这里真正的边界在 agent runtime。Slock 的触发方式是每次由 slock 唤醒一个 agent：agent 醒来以后，不是天然带着完整连续的开发上下文，而是要自己去读 channel、thread、task、memory，再把这些材料塞进本次模型上下文里。这个过程会有几类风险：
所以我的判断不是「Slock 不好」，而是它更像可靠的消息/协作 control plane；从消息变成「本次 agent 能正确理解的完整开发上下文」，中间还隔着检索、选择、压缩和恢复过程。深度 coding session 的优势在于：它围绕同一个 repo、同一个 topic 连续工作，很多判断、失败尝试、局部约束会自然留在这个 session 里，不需要每次从 IM 里重新拼一遍。
更理想的形态可能是再多一个明确的 handoff：IM agent / Slock 负责把问题调度清楚，把 evidence package 准备好；一旦进入需要深度改代码的阶段，就把任务移交给本地 coding agent，走传统 coding agent 的链路。coding session 里再去拆 worker、跑 verify、做回归，把执行上下文留在 repo 旁边，而不是继续在 IM thread 里调度细节。这样 control plane 和执行链路就分开了：前者负责分发和对齐，后者负责深挖和验证。
简单说：
这两个场景可以衔接，但不应该混成一个东西：IM 那侧负责把问题变成清楚的小包，本地 coding session 负责把这个小包做深、做完、验证掉。
我最后想要的状态其实很简单：我只专心做该做的那一件事 —— 把那个小包送到该拍板的人面前。
许愿🙏：如果飞书原生加一个 agent 看板能力——直接告诉我我的每个 agent 在干什么、当前进展是什么、有哪些还没读的输出——我就不再需要去群聊里翻 thread，也不再需要绕一层 Slock 这样的抽象。
还有个想法，会不会出现以「我 + agent」这个 pod 为单位的 IM 抽象，人其实管理不了那么多 agent ，纯粹的情绪价值，跟自己为 pod 的 agent 绑定就行，别人 at 我，我可以选择直接看，也可以看agent 的信箱，不断给 agent 沉淀规则，让我的 agent 判断是我应该回答还是他先回答，这样相当于把我从调度者抽离出来，agent 成为了调度者，我是被调度的一员，我只用关心我需要关心的内容就行。
