Agent 领域，最近一次热闹的探讨要属 Anthropic 和 Devin 之间针对 Mult…
Agent 领域，最近一次热闹的探讨要属 Anthropic 和 Devin 之间针对 Multi-Agent 的隔空对话。两者都发布了一篇工程实践踩坑血泪经验分享，却从标题开始就充满了「对立」：
前者说 MA 好用，靠谱； 后者说 MA 很不靠谱，尚未成熟。
本着「不动手干不知道真假」的原则，说说实践过后的感受和观点：
首先，我们要认知到，出现这种对立本身就非常正常，因为两者面对的产品和场景都不相同。
那从技术角度，导致结论差异的本质在哪儿？
工程技术多年的经验积累让我们有了一个很好的系统思考框架，我们常把业务场景建模为一种模型，来最终确保它优雅无误地运行到计算机中，这就是我们常说的「抽象」，我们也知道，抽象对于架构设计很重要，这也是为什么我们会出现设计模式、编程范式等等诸如此类模式化的最佳实践，但我们很清楚，没有一个统一的模式适用于一切。
抛开输入输出不谈，把场景的核心实现打开，重要的是里面的「问题」最终映射到可运行的「计算模型」到底是什么。这是我坚持认为很多 Agent 框架在设计的时候应该找到的第一个抽象，也是我在 AStack 中强调的核心设计之一： https://www.astack.tech/#computation-model 但是大部分 Agent 框架并没有在这一层上做深度思考，但坦率地说，这不是太大的问题，我相信这已经是 Trade-Off 之后的结果。
不同的场景采用不同的计算模型才能得到收益最大化，一个支持 Deep/Deeper Research 的 Agent 和一个写「Flappy Bird」程序的 Agent，他们的计算模型肯定不一样。
前者本质是在数据结构上做遍历操作（Map）后再做一个汇总（Reduce），而后者要归类于编程任务，前者本质强调数据流处理，相对简单，而后者复杂度飙升。
编程任务最大的难点我认为没有被精准地表达过，那就是：代码本身并不直接映射运行时的逻辑。也就是我们都知道的，程序不仅仅包含数据结构，还包含算法在运行时的处理，这个部分随着代码部分的抽象，会被分散到代码各处，然后我们会经常看到 Context 这个词，即「上下文」，这是一个相对笼统的说法，在不同的程序细节中代表着不同的东西，现在，我们只需要知道，它对于程序的运行时无比重要。
这个时候，如果我们用多个角色化的 Agent 来协同完成此类任务，并且给到的输入只是原始需求，给到模型的工具是比较底层的工具，效果会非常糟糕。因此我们需要把工具进行高维的抽象和收敛，也要把一张架构图（形象的说法）给到这些 Agent。
但要同时把这两件事做好，非常不容易，Devin 表达的核心观点便是如此，认为 MA 架构在这类任务中可能反而成为了「反模式」。
事实上，没有「对错」，也不是「非黑即白」，Anthropic 和 Devin 都给我们带来了宝贵的经验，也让我们再次看到，就算模型再强，最终带给用户价值的永远是「产品」，而在产品的构建过程中，工程领域的壁垒依旧很高，且工程领域的这些积累本身也给模型的发展带去了贡献。
Comments