我和一个工程师靠两个 Agent 协作开发 App，但我们几乎不聊天
我和一个工程师在做同一个 App。
我们不在一个城市，平时几乎不说话。
不开会，不打电话，聊天软件上一周可能也聊不了几句。
但项目一直在往前走，而且说实话，比我以前带着一整个团队的时候还稳定。
我们的协作方式有点奇怪。
我不直接跟他沟通，而是跟我的 agent 沟通。他也一样。
两边 agent 负责交换那些需要对方确认的信息，然后各自整理成自己的主人能理解的版本。
所以我看到的，从来不是他原本写下来的东西，而是我的 agent 处理之后告诉我的版本。他那边也是一样。
一开始我觉得，这不就是把 GitHub 那套异步协作推到了极致吗？
不用开会，不需要同步时间，大家靠代码、文档、issue 和 commit 这些留下来的东西协作。
开源社区其实早就在这么干。
几十万互不认识的开发者，通过 pull request、review、issue，一起维护 Linux 内核、各种基础设施。
所以这种方式本身没有问题。
但后来我发现，Agent 参与之后，有一个很微妙的变化。
它跟 GitHub 最大的区别，不在效率，而在于：
大家可能不再看同一份东西了。
GitHub 的核心，是所有人面对同一个对象
开源协作有一个很重要的前提：
所有参与者面对的是同一个公共文本。
一个 pull request 提交在那里。
你看 diff，我也看 diff。
你在 review 里写一句话，我看到的是同一句话。
我们可能意见不同，但至少我们争论的是同一个东西。
这件事非常重要。
因为那份公共文本不仅是在传递信息，它还是一个证明：
证明我们两个确实在讨论同一件事情。
但 Agent 协作之后，这个东西开始变化。
代码还在那里。
issue 还在那里。
测试用例也还在那里。
理论上任何人都可以打开看。
但实际上，我们越来越少直接看它。
我看到的是我的 agent 总结之后的版本。
他看到的是他的 agent 总结之后的版本。
这两个版本，从一开始就不是同一个东西。
于是"我们达成一致"这句话，含义发生了一点变化。
以前的一致是：
我们看了同一份东西，然后得出了相同结论。
现在更像：
两个 agent 在中间协调出了一个结果，然后分别告诉自己的主人。
协议是一份。
理解变成了两份。
会议不是被消灭了，而是很多功能消失了
很多人觉得，未来 Agent 会让会议消失。
我觉得这个说法不太准确。
会议以前存在，是因为人和人之间传递上下文的成本太高。
你脑子里有一个完整的判断：
为什么这么设计？
之前试过哪些方案？
为什么排除了另外几个选择？
哪些地方踩过坑？
这些东西没办法直接复制给另一个人。
所以我们坐下来开一个小时会。
但一个小时里，真正传递过去的信息可能只有一小部分。
剩下大量时间，其实是在补背景、确认理解、纠正偏差。
而当每个人身边都有一个 agent，它可以一直读代码、看 issue、理解历史记录。
很多背景信息就不需要重新讲了。
剩下真正需要人参与的事情，其实很少：
哪里存在分歧？
哪里需要取舍？
哪里需要负责人做决定？
这部分恰好是 agent 很擅长帮忙整理的。
所以会议不是被自律消灭的。
而是会议原本承担的大量"同步信息"的工作，被自动化了。
最后剩下来的，只是一小部分真正需要人参与的问题。
最大的问题：误解变得不容易被发现
面对面交流有一个好处：
误解会产生摩擦。
你讲一句话，我皱一下眉。
你复述我的意思，我发现你理解偏了。
很多问题就在这种"不舒服"的瞬间暴露出来。
但 Agent 会把这种摩擦消掉。
因为它的任务就是：
把对方的信息整理成你容易理解的形式。
问题是，整理本身就是一种加工。
一些原本模糊、不完整、甚至值得追问的东西，经过 agent 处理之后，会变成一段非常流畅的话。
你读起来觉得：
"嗯，合理。"
然后继续往下走。
但那个本来应该出现的问题，已经被抹平了。
我们真实遇到过一次。
有一个概念，两边理解差了一层。
单独看双方 agent 输出的内容，都完全合理。
没有明显错误。
但是两边实际上理解的是两个东西。
最后发现的时候，已经按照错误理解改了几十处代码。
奇怪的是，没有谁犯错。
双方 agent 也没有胡说。
只是：
没有任何一个人真正读过同一句话。
最让我不放心的是：被过滤掉的信息去哪了？
后来我发现一个更深的问题。
我们现在的模式是：
agent 判断哪些事情值得拿出来让人确认。
也就是说，有一部分信息，在到达人之前，就已经被筛掉了。
如果两个 agent 都认为某件事"不重要"，那么这件事可能永远不会出现在人的视野里。
它不是被否决了。
因为根本没有人知道它存在。
以前的信息损耗也存在。
比如一个新人不知道某个背景，一个团队成员忘记同步某个变化。
但那更像流程问题。
现在的问题是：
有一个非常高效的系统正在主动过滤信息。
而过滤过程本身，很难被观察。
我现在能想到的笨办法，是偶尔让 agent 列一份：
"这一轮你认为不需要我知道的事情。"
然后我快速扫一遍。
但这个方法也有问题。
因为筛选这份清单的，还是同一个 agent。
真正支撑这套模式的，不是 Agent 聪明
写到这里，我觉得必须补充一点。
不要把这个案例理解成：
"Agent 已经可以替代人沟通了。"
不是。
Agent 的转述一定会失真。
前面那个几十处修改的例子，就是证明。
真正让这套协作方式成立的，是：
很多争议最终可以通过执行验证。
我们这个项目里，有大量自动测试。
AI 跑一遍。
人再检查关键部分。
合并之前还有质量检查。
所以当两个 agent 的理解出现偏差时，不需要花大量时间争论。
跑一下测试，问题自己会暴露。
代码不会因为解释得漂亮就通过测试。
它必须真的工作。
换句话说：
Agent 之间之所以可以减少人工确认，是因为后面有一个验证系统帮忙兜底。
如果没有这个验证环节，结果可能不是更高效。
而是两个 agent 帮助两个人，用更快的速度、更高的信心误解彼此。
所以我不认为这种模式适合所有事情。
写代码可以。
很多工程问题可以。
但战略判断、商业决策、人事管理这些领域，没有一个测试用例告诉你谁错了。
错误可能半年后才出现。
到那时，已经没人知道最开始是哪一次转述出了问题。
现在其实有四个参与者
回头看这个项目，我发现里面其实有四个人：
我。
我的 agent。
他的 agent。
他。
而中间两个 agent 的作用，比我最开始想象的大。
以前我觉得 agent 是管道。
现在我觉得它更像翻译。
管道不会改变经过它的东西。
翻译一定会。
因为翻译必须做选择。
而选择，本身就是判断。
未来这种协作方式可能会继续发展。
也许两个 agent 会越来越熟悉彼此，交换的信息越来越少，人越来越像监督者。
也许最终我们还是需要一份公共文本。
只是那份文本不会像现在这么长。
它可能短到：
两个人真的愿意打开。
真的愿意读完。
因为我现在突然意识到：
那份公共文本一直在那里。
代码库在那里。
文档在那里。
Issue 也在那里。
只是我们两个，已经很久没有一起看过它了。