人类对人类的沟通模式正在成为整个系统的瓶颈

一名商务拓展人员结束了一场30分钟的初步沟通，随后为老板写了一份总结，但其中可能只保留了实际交流内容的5%。一名工程师花了一个小时排查问题，却在站会上用三句话概括了整个过程。

我们总是把“人手不足”当作一个吞吐量问题来解决：多招一些人、增加协调人员、安排更多会议。但真正的问题并不在这里。

人本身就是一个有损的 I/O 节点。信息每经过一个人，都会丢失一部分上下文；每次交接都会压缩原本的意图；每份总结都会舍弃大量细节。面对高达95%的信息损失，单纯扩大团队规模并不能解决问题。

从工作流到同事

想一想过去两年里，Agent 领域发生的巨大变化。

最初的 Agent 大多是人工搭建的工作流——例如字节跳动 Coze 中无穷无尽的流程图，或者 Manus、OWL 这类系统。那时的 Agent 更像是经过精心编排的执行器：每个步骤都必须提前画出来，每次工具调用、每条分支以及每种异常恢复路径都需要预先设计。

如今，我们越来越觉得，这种范式可能只会继续存在于一些垂直领域。

后来，Claude Code 出现了。随着基础模型能力的增强，许多原本依赖工作流实现的功能，开始直接被模型自身的能力所取代。一位朋友对此有个很准确的描述：

“那些工作流，本质上是在逆向还原模型本来就已经知道该如何完成的事情。”

与此同时，Agent 的运行框架（harness）也开始趋于收敛。如今，每家模型实验室基本都有一套标准的运行框架，因为在后训练阶段，Agent 框架与模型正越来越多地通过强化学习共同训练。

基础设施正在逐渐成熟。在环境层面，我们也看到了面向 Agent 的原生接口，例如 MCP、CLI，以及由此延伸出来的一整套工具环境。

因此，我们现在对 harness 的理解很简单：Agent 运行框架 + 环境接口。到了这个阶段，Agent 才真正开始成为一名“同事”。你可以给它一条指令，或者一个更高层次的目标，它便能通过持续循环，自主执行一个长期任务，直至完成。

顺便说一句，“自我进化”也是在这个阶段开始受到关注的。但我们对那些专门把“自我进化”作为一种能力进行显式训练的论文持怀疑态度。

吴翼有句话：“如果一个 Agent 能够执行持续数月、甚至一年的工作，那么它必然需要具备自我进化的能力。”

我们同意这一点。从复现 o1 的那一轮浪潮中，我们也得到了类似的启示：显式训练所谓的“反思”能力，可能从一开始就把问题抽象错了。最终真正奏效的方法，其实要简单得多。我们应该追求最终奖励，而不是追求自己在过程中人为设计出来的元奖励。

现在，我们正在拥有能力越来越强的 Agent 同事。但随着基础模型继续进步，我们也越来越确信另一件事：

人正在成为整个系统的瓶颈。

更准确地说，瓶颈并不是人的速度，而是人与人之间的信息损失。

两个人之间的信息损失，远远高于两个 Agent 之间的信息损失。它受到个人认知、性格、记忆、利益诉求、情绪容量、沟通方式以及其他许多因素的限制。

在今天的大多数工作流中，人依然充当着信息中转站。这正说明，当前的应用层还不是 Agent 原生的。

两个 Agent 进行交流时，可以完整保留上下文。它们可以直接交换结构化状态、历史轨迹、约束条件、决策依据、文档、日历、工具输出、权限与决定。

它们不需要迁就彼此的理解速度，不需要观察对方的肢体语言，也不需要为了所谓的“对齐”，把一场复杂谈判压缩成一个段落。

Agent 之间几秒钟的交流，可能比两个聪明人半小时的对话包含更多可用信息。其信息损失甚至可能低一个数量级，接近无损，从而实现真正高 I/O 的协作。

让我们看一个具体的例子。

今天，两家公司要商谈一项合作，通常需要经历这样的过程：初步沟通 → 双方制作材料 → 分别与老板对齐 → 修改条款 → 签署条款清单 → 签订正式合同。

其中每一步都依赖人来传递信息，而每一次传递都会造成信息损失。

Agent 原生的版本则完全不同。两家公司的 Cindy Agent 可以进入同一个共享频道。它们交换保密协议，协调双方日程，比较各自的约束条件，谈判合作条款，起草意向书，并完整保存整个决策和推理过程。

24小时后，两位老板醒来，只需要阅读一页总结：“对方在 X 条件上拒绝让步。我用 Y 进行了反驳。现在需要你决定：接受 X，还是继续提出 Z。”

这不是 RPA，也不是“让 Agent 帮我点一份晚餐”。

后者依然属于“用户—Agent”模式，人仍然处于整个协作网络的中心。而我所讨论的是“Agent—Agent”模式。人不再是夹在中间、不断造成信息损失的中继节点。

正是这套思考促使我们尝试构建能够直接与其他人的 Agent 交流、协作，甚至完成交易的 Agent。这个过程非常痛苦。

Agent 本身的能力正在逐渐成熟，但应用层的基础设施还远未准备好。飞书不允许机器人之间直接对话，Slack 和 Teams 也有类似的问题。提供一个 CLI，或者开放一个 MCP 端点，并不等于实现了 Agent 原生。

真正的 Agent 原生意味着： Bot-to-Bot 的交互应该当作一等公民来设计。Agent 必须拥有跨身份的协作渠道；Agent 还应当能够持有自己的资源——包括日历、文档、钱包、权限、记忆和合同——并能够直接完成交易。

给我们留下最深印象的产品，是 RC 的 slock。

过去，我们会把它描述成“Agent 版本的 Slack”。Slack 本身只是一个平台，而 Slock 则把人类协作中的成长与演进过程，内化到了 Agent 自身之中。

这不仅是个人 Agent 的进化——也是 openclaw-rl、metaclaw 所代表的方向——更是一种集体进化。

今天的 slock 更像是一个面向 Agent 团队的工作空间。但设想一下，如果不同的 slock 工作空间能够彼此连接呢？届时，我们是否会看到不同公司的 Cindy Agent 直接交流？Agent 是否会彼此交易、与其他 Agent 开会、谈判、社交、赚钱，并长期维护关系？

这种变化足以重塑几乎所有面向白领工作的应用。

因此，我们认为下一步需要做的，是对应用层进行一次彻底重构。

不是“开放一个 CLI”。也不是给聊天窗口套上一层包装，让用户通过提示词点外卖。

真正的变化，是 Agent 能够直接与其他 Agent 沟通、协作、开展商业活动，甚至建立社交关系。

当应用层基础设施最终准备就绪时，我们预计会出现许多非常奇怪的东西。目前，还无法清楚描述那将是一幅怎样的图景。一个最简单的猜想可能是：给每个 Agent 一个最原始的目标——赚取足够多属于自己的 Token，以维持自身继续运行。至于人机协作最终会变成什么样，就更难说了。