好久没写手记了，稍微讲讲最近做的一些事情，因为不是偏向技术的内容，更多的是一些无谓的杂谈，遂放在这里吧

这个题目为何如此奇怪，甚至是无法标定/无法命名的，因为其实我也不知道这篇文章我想输出什么，最近在公司里迭代 Agent 产品，就拿最近做的一些工作做一些杂谈吧。

本文编写了一个月，这一个月期间又有很多的新词，我上个月写了一点，这个月写了一点。现在看来，这篇东西其实是比较的割裂的... 这个时代的速度真的太快了...

为什么会出现个人助理？

在过去如 Cursor 类的 Agent IDE 作为 Agent 热点的 1.0 时代，我们的需求是明确的，思考是内敛的，我们不会将思考外包给 Agent IDE，它对我们的用途，就是那一刹的需求转化为代码，就此，他的任务结束了。1.0 的时代让我们的生产力推向了一个新的高度。

进化到如 Claude Code, CodeX 类的 Coding Agent CLI 作为 Agent 热点的 2.0 时代，我们的需求逐渐变得模糊，大多数人都有了不同程度的 FOMO。看到别人用某某 Agent 创造出了一些爆款的时候，大多数人的心态变成了「Agent 原来如此强大，那我也要做点什么」。个人助理，或许就从这里，开始逐步成型。

我们期望我们可以把我们脑海中的想法实现，所以我们自然会想要找到一个比我们更加高智，更加厉害的，但有同时可以听得懂我想要什么的人。于是，我们把视角就转向了 LLM，我们开始将思考直接外包给 Coding Agent。

我们会跟它交流我们的思考，让它来总结我的想法是什么，让它来凝练出我的核心需求是什么，甚者，我不需要有某个想法，让 Agent 代替我进行思考，我只需要给一个方向，就让它思考去吧，最后凝练出一套可行的需求方案。把这个方案实现出来，我的想法也就实现了。

这一套操作，其实已经行得通了，只不过我们的交互面还在 CLI，还在电脑上，我们仍然觉得这不是最后的目标，还是很不“直觉”，我们都想当一次 —— 老板。

当 OpenClaw 横空出世，我们迎来了 Agent 的 3.0 时代，我们发现，原来一个Agent 可以这样玩，可以把它变成我的秘书。当我们将本地系统暴露给 OpenClaw 任由他取的时候，它已然变成了我们的贴身秘书了。他能拿到我所有的信息，可以记住我的偏好我的想法，能接受我的“调教”来改变它的行事风格、思考风格。

我们有想法，跟 OpenClaw 聊聊，它的设计上令它是可塑的，它既是我们的贴身秘书，也是我们每个人从零到一抚养到大的一个少年。它的记忆可以带着长久以来的交流细节，在沟通的过程当中内化到思考当中，越用或许我们会越觉得「它是懂我的！！」。

我们聊通了，便可以代替我们直接去启动好几个 Coding Agent 去编排任务，把派发 验收 测试一系列的操作都搞定，最后只需要递给我一个令我满意的结果。这也许就是我们现阶段最想要的呈现形式。

到现在，我觉得答案已经很明显了，为什么我们需要一个个人助理？当我们享受到了一个镜像的自己在代替自己思考的同时，最后的产物也是符合想法的便利后，为什么还要再把视角再回到苦苦冥想到最后才把一个需求收敛的过去。从现在发展速度来看，它太不经济了。

之所以会出现个人助理，是因为，我们需要一个对时间没有感知的 100x 自己

可除了个人助理之外呢？多Agent 协作又如何呢？

我们会发现 OpenClaw 虽然爆火，但是持续时间并不长，在短暂的狂欢后，流量急剧下降，这一方面是因为大部分人都已经知道了这个事物了，该用上的人早就用上了，但另一方面，有一部分的人发现，OpenClaw 的这种人机协作方式对于他们来说，似乎还不够。在 OpenClaw 过后，逐渐开始出现别的 Agent 产品。

现在我们都在说 Harness Engineering 这个词，这个词本身是旧药装新瓶，而背后所体现的是我们一直在期望 Agent 能在无监管的情况下完成各种事物。

最近出现了 Slock( https://slock.ai ), Multica ( https://github.com/multica-ai/multica ) 等类产品。他们所代表的是两种不一样的协作方案。在multi agent 的模式当中，不同的组织形式会直接影响系统的可控性和可扩展性

据我的观察来看，当前主流大致可以抽象为两类：Conversation-based 和 Task-based（其实就是现在的 slock 和 multica）

• Conversation-based 本质上是通过 message passing + 上下文共享来完成协作的，类似一种 emergent coordination
• Task-based 更接近我们过去的 workflow 编排 / DAG（但是不太一样，它不是过去的 Dify / n8n 那种 workflow 编排），把 Agent 当作 executor，强调可观测、可回溯

而在 Agent 工程当中，我们的最终目标不是“做一个最强的 Agent”，而是应该构建一个可组合的、智慧的组织架构，让不同 agent / system 在合适的地方协同工作，而不是被强行塞进同一个 runtime 里.

我在过去迭代公司的 Agent 的时候不断在思考 multi agent 协作的问题，这个问题在最后甚至变成了「为什么我们需要 multi agent？」因为有的时候引入 multi-agent 反而会带来一些额外的协调开销，而且最终质量也会不升反降。

目前，我暂时的答案是：我们的确需要 multi agent，而且我们需要不止一种协作方式，我们暂时还没找到一个 all in one 完全解决所有需求的方案，两种/多种方案解决不同问题才是合理的。

认知的拟合

不知道大家有没有这样的想法，大家的想法越来越一致了，似乎大家对 Agent 的理解逐渐趋向一个统一的状态。来讲讲我自己吧：

在春节的时候我自己已经在慢慢构建一个属于我自己的 Agent System，准确的说它不是一个单一的项目，更像是项目集合

• 有基于 Conversation-based 蜂群机制的 Agent System，一堆 agent 并行，没有严格的 workflow，不走 DAG，互相看对方输出
• 有基于 Task-based 的 Agent System，本质上是 https://github.com/openai/symphony 的延伸

而这，不正好就是 Slock 和 Multica？再加上 OpenClaw / Alma 这类的个人助理，就几乎已经可以完整表示出我们最近的 Agent 所有趋势了。

在我的 Telegram 频道里，我也曾分享过我的 Box Model：事件是唯一真相；视图、记忆、上下文都是派生物，其实这一定程度上也是 Bub Tape。

可以见得，似乎大家现在都在实现同一类事物，大家的行动基本上都是同步的，并不是你的认知更高级，我的认知更领先的区别。

这点算是我一点胡乱思考，至于这个到底是不是个问题，到底会造成什么影响，我的认知太过浅薄，无法思考出来。

最后一点想说的话

新时代，每个人都其实应该有属于自己的 Agent，毕竟，每个人的 workflow 都不太一样，我之前经常会说的一句话：「我不会想使用你的 workflow，因为我用不惯；我也不想你用我的 workflow，因为我知道你用不惯」

在 Agent 应用层，众多 Agent 产品之间的区别我个人认为最核心的就只是在于市场营销方面，以及他们对于 UX 的品味设计不同。

在迭代速度极快、可能今天有想法，明天已经被人实现的时代，工程师的品味越来越重要，产品就是从 UI UX DX 方面全方位的比拼。这也是我最近一直不断在研究的方向，未来的产品，我们要怎么做好交互？

要怎么设计这些，我觉得也许这就是一种直觉，这就是 AI 无法替代人类的原因。

AI 能设计出 aha moment 吗？至少，现在它自己所设计出来的东西，还暂时没有让我 aha 。