1/6

长文「Buzz 为每个人创造自己的web3 Agent」
副标题「从Buzz看web3 agent的趋势」

（Buzz 是项目 @askthehive_ai 的代币符号）

「先说结论 」

1. $Buzz 没有采用任何 Agent Framework 来写自己的代码，核心原因是大多数 Agent Framework代码确实一般，而且本身Agent Framework 并不存在太强的护城河(API 封装)，何况Buzz 的代码质量确实比 ElizaOS, zerebro 这些 Agent Framework 的代码质量强太多，目前在我看的 AI Agent领域里代码质量是最高的。

2. $Buzz 的代码模块化得超级好，如果Buzz想做 Agent Framework，只需要把自己关于Agent的代码摘出来就行了，所以Agent Framework其实并不存在什么技术护城河；大家来看这一波真正起飞的Web3 Agent，会发现其实极少的项目去使用 Agent Framework. 而是自己写一套更适合自己业务的代码(也有可能是自己写的代码质量更好)

3. $Buzz 通过预先的Web3知识导入实现了web3专属代理，但是还是期待这部分的工作可以转移到预训练的阶段来做。

4. 通过为每个用户在Agent里开辟自己的内存区域，并且在用户下一次开启聊天的时候加载这部分memory，实现为每个用户创造独属于自己的web3 agent

5. 是否能为每个用户启动一个自己的Agent，并且支持更好的定制化；这个很明显需要配合1️⃣，以及通过多个Agents的协作让每个 Buzz 有能力根据用户的需求自动生成对应的tool.

6. 对于大多数复杂的场景来说，单一Agent受限于Content的长度限制，以及响应速度跟成本的考量无法很好的完成人类给予的任务，这一点我自己在写一个代码分析Agent时也遇到了(画图)，当仓库太大的时候，我们还是需要通过Swarm来处理。因为通过Swarm我们可以获得多个Agent并行处理任务，获得更大的Memory容量，以及跳出Content长度的限制等等，而且从人类社会发展史来看，协作一定是趋势。

7. 当然最终 作为一个 Web3 Agent, 最核心的还是 Buzz 产品本身的使用体验，希望Buzz继续快速迭代，给用户提供更多的功能以及放开每个用户的请求次数限制。

8. Buzz目前的用户体验还不够好，还是会遇到类似的问题
另外一个很有趣的看法是，Agent发展路程一定是往Swarm去发展，但是人类中的超级个体却在通过Agent变得更加强大，强者越强，弱者越弱，比如 Buzz的代码(github.com/jasonhedman/th…)其实是solo写出来的，未来的人类路在何方呢？

先送大家一张完整Buzz的图片 2/5

1. Buzz的架构如下：
Buzz基本上还是跟我们写过的ElizaOS框架差不多的架构，分为 Chat App, LLM, Tools, CosmosDB.

-ChatApp 就是我们登陆 Buzz 时的用户界面，主要用于管理跟用户的交互过程

- LLM 仍然是任何Agent的核心组件就不多介绍了

- Buzz 目前支持的 tool 主要有 Twitter Tools, Solona Tools, Knowledge Tools：
1️⃣ 其中Twitter Tools实现了通过用户给的keyword 在推特上搜索信息并且总结后返回给用户
2️⃣Solana Toos 则是实现了一些Defi协议的操作，例如swap, stake 等待操作
3️⃣Knowledge Tools 则是Buzz 的特色,它预先往自己的数据库添加了一些web3的知识，主要是solona上defi 协议的相关知识，因此当用户询问跟这些知识相关的问题时会触发
4️⃣CosmosDB 则类似于我们之前 ElizaOS 文章里的 memory ,用于记录一些数据，在Buzz中memory被划分成两个分区，一个分区记录跟不同用户的聊天历史，一个分区记录一些web3的公共知识，不同的用户可以同时使用这部分知识。

「Swarms Architectures」
之「从技术上帮你拿住Swarms 」

内容包含主要包含:
- Swarms架构解析
- MCS架构解析

这是一条完整介绍Swarms的代码的Thread，写这条Thread的原因是最近 #Swarms 的创始人被Shaw指责没有编写代码的能力推特火了之后，推特上很多人都在浅浅看看代码之后说Swarms的代码很烂，而且很多朋友也来询问我关于Swarms 技术的问题，这两天花了很多时间把基本上所有代码完整的看了一遍就有了这条Thread，客观的叙述下Swarms

@swarms_corp 架构如下:

整体的架构图如下：

1. Swarms的Agent的设计该有的功能都有，也就是跟ElizaOs一样都支持了Memory,Tool,LLM,Evaluator, 同时Tool的设计上也都是采用了类似ElizaOS对应的注册表的方式。

--------- Swarm Framework ---------
2.在Agent之上是对应的Swarm Framework,用于协调多个Agent之间的工作，目前Swarms已经实现的Swarm Framework有：
1️⃣ MajorityVoting，相当于多个不同的Agent同时执行一个task,最后会通过投票的方式选择一个最佳答案进行回复，最多得票数的回复会被采用；其实也很想区块链的Pos共识机制，挺有趣的

2️⃣ AgentRearrange，是一个很灵活的Swarm框架，比如我们现在有三个不同的Agent A,B,C,D ; 然后假设有一个任务希望 按照 task -> A -> B -> C -> D的方式被处理，即A先处理这个任务然后交给B处理再给C处理接着给D处理，那么我们只需要在WorkFlow里这么定义 workflow = " A -> B -> C -> D", 然后初始化这个AgentRearrange并且运行，如下所示：
AgentRearrange(agents = [A,B,C,D],workflow = " A -> B -> C -> D").run(task)
我们就可以拿到按照我们规定的工作方式最后产生的结果

同时如果我们把WorkFlow定义成 A -> B,C -> D，那么A执行task之后，B、C会同时执行任务，最后D再执行任务，所以这是一个可以通过WorkFlow实现灵活定义整个工作流的Swarm模式

3️⃣ GraphFlow，则相比AgentRearrange还有支持更复杂的工作流关系，可以任意设计整个工作流的之间的依赖关系

4️⃣ GroupChat 则是让多个Agent进行多轮对话，最终通过多轮对话不断完善要完成的任务内容，从而让结果更可靠更详尽

4️⃣ MixtureOfAgents 则是多个Agent同时工作，最后有一个Agent负责总结所有的工作，并产生最终的输出

5️⃣ RoundRobin则是通过轮询的方式让每个Agent平等的参加工作

6️⃣ ForestSwarm则是可以支持多个层级的Agent关系，所以就想树有很多枝干一样，ForestSwarm就是一个巨大的Agent节点构成的网络，因为起名叫做森林

7️⃣还有MultiAgentRouter也是我们介绍过的BossAgent
ConcurrentWorkflow，支持多个AI Agent同时执行同一个任务

8️⃣ AsyncWorkflow， 多个AI Agent异步执行任务，因此这里需要用到ShareMemory来记录任务产生的数据，同时还有复杂的SpeakSystem

关于Swarm的总结：
Swarm Framework这一层其实需要管理不同的组件，ShareMemory, WorkFlow和 OutputManager, TaskAssigner ，因为总结上面这些不同的Swarm Model，我们会发现当我们想协调多个Agent共同工作的时候我们需要考虑以下几个问题:
1. 决定任务交给谁做 (TaskAssigner)
2. 怎么协调Agent参与工作的先后顺序 (WorkFlow)
3. 怎么管理任务执行之后产生的输出(Output Manager)
4. 异步执行的时候怎么传递一些状态给其他相关任务(ShareMemory)

-------- Swarms Framework ---------
Swarm再上层就是Swarms Framework了，用于协调多个Swarm之间的工作，目前主要支持两种

1️⃣SwarmRouter
通过 「Word Vector」比较的方式选择最合适的Swarm Model进行执行task

2️⃣SwarmRearrange
也可以通过类似定义 workflow 的方式，直接协调多个 Swarm 进行工作

最后我想再强调一下一个Agent是可以在不同的Swarm下直接工作的，所以这里所有的Agent都会由AgentRegistry进行管理，从而能在不同Swarm下尽可能多的复用。

-------- 总结 --------

最终Swarms产生的结果就是，任何Agent协作场景你都能在Swarms上找到开箱即用的协作方式，而即便是更复杂的场景也可以通过不同Swarms之间的配合来实现，因此ElizaOS开启了Web3 Agent Framework的赛道，而Swarms会对Web3 Agent Swarm 领域有很大的贡献要，当然现在的代码还不够完美，但是很明显随着越来越多开发者来到Swarms生态我们可以一起把这些很前沿的代码Build到最好

---------- Mcs 架构分析-----------

目前Swarms生态也开始起来，我觉得会爆发出巨大的力量，就比如 Swarms 生态的龙一 #mcs 的核心代码不过百来行，核心是通过 AgentRearrange的Swarm Model协调四个agent之间的工作，而且当时Kye搞 @mcs_swarm 核心的目的就是想证明Swarms行！

1. 核心架构与Agent：
主要Agent：
- 首席医疗官(Chief Medical Officer)：协调整个团队，收集症状，形成鉴别诊断
- 医疗编码员(Medical Coder)：分配 ICD-10 代码，确保编码合规
- 诊断合成器(Synthesizer)：整合所有发现生成最终诊断评估
- 治疗智能体(Treatment Agent)：根据效果和成本推荐治疗方案
- 实验室匹配器(Lab Matcher)：匹配诊断与实验室检查，提供参考范围
定义Workflow: `首席医疗官 -> 医疗编码员 -> 诊断合成器 -> 治疗智能体`
2. 协调机制：
并通过上面介绍的AgentRearrange 方式来实现协调多个Agent工作
3. 工作流程
同时每轮执行前会从数据库中拿取该任务所需要的对应数据

推荐大家实际使用下 mcs 来感受下 mcs.swarms.world

所以对于 Swarms来说，一切肯定都不是最好的，但是足够好了，对于现在有这么一个开箱即用的框架也很棒了,Swarms的框架初看会觉得很一般，再看会逐渐发现里面一些 @KyeGomezB 关于Swarm很深的一些思考，是很有价值的

最后还是很喜欢 @KyeGomezB 对待被指责代码不好时的态度

https://x.com/KyeGomezB/status/1875785206713418046

1/4

Swarms 原理解析(二)
@swarms_corp @KyeGomezB

Swarms里支持了很多的Swarm框架，今天介绍一下最近新支持的一个新的Swarm方式----MultiAgentRouter，一个真的Agent Boss，不断压榨员工(Agent)

在我们上一篇 Swarms 原理解析里我们提到Swarms里的SwarmRouter

在Agent写作的整个流程里 Swarms 就像一个无所不能的"Human Manager"，它知道：
1.有哪些 Agents（"员工"）
2.每个 Agent 的专长是什么
3.如何分配任务给 Agents
4.如何让 Agents 以最高效的协同方式进行工作
5.如何收集和整理 Agents 的工作成果

不过它的实现方式依然是通过 比较不同 「Word Vector」之间的向量距离，最终选择最符合描述的Swarm.

x.com/hhh69251498/st…

而最新更新的这个MultiAgentRouter 则主要是通过一个BossAgent来自动分配任务给不同的Agent进行执行 2/4
「原理解析」

在MultiAgentRouter里的流程如图所示：

- 其中的核心其实是Boss Agent的SystemPrompt，对应如下:
这里的核心点就是我们要把BossAgents能管理的Agent信息嵌入到SystemPrompt之中

「Example」
接下来我们看一个实际的例子来看对应的Example:

首先我们启动三个不同任务的Agent，并且创建一个BossAgent来管理这三个Agent

然后我们同时创建多个不同类似的任务并且把任务对给Agent进行执行

1/3

花了很长的篇幅写了 Eliza原理解析(一)(二)

从我的角度出发，实际上所有的AI Agent框架技术上都差不多，而ElizaOS是目前完成度最高的，虽然有些代码质量不够好，但是目前从理解Ai Agent的角度出发，ElizaOS还是你最好的选择～

作为追寻AI Agent的猎手，很显然这一波浪潮下懂点技术是很重要的，目前来看能跑出来的项目绝对还是有不错的技术基础以及不错的开发者生态的才能最终把产品和市值做起来～

所以会推荐把 Eliza的原理解析 看完，接下来看其他相关的AI Agent框架你会发现都是一个技术原理，遵从第一性原理的学习方式总是有效的～

当然如果你想快速的理解ElizaOS，也可以直接看这个图:
这样以来其实像Arc, GAME, Zerobro 其实都是一个道理，特别是有些项目你会发现连Evaluator都没有，你就可以很轻易的判断这个项目可能在技术上不大行。

x.com/hhh69251498/st… 2/3
当我们可以看懂AI Agent Framework之后,我们就可以开始来看Swarm的项目了。
Swarm在AI里面指的是多个AI相互协作，目前有这么几个项目

- swarms
- project-89 github.com/project-89/whi…
- SNAI github.com/swarmnode-ai/s…
- FXN. github.com/Oz-Networks

项目很多但是原理差不多，所以还是跟看Agent Framework一样可以选择一个成熟度最高的框架来看，目前而言肯定是Swarms.

这个时候你就可以翻一翻 Swarms原理解析(一)
x.com/hhh69251498/st…

1/5
#Eliza @ai16zdao

Eliza(github.com/elizaOS) 原理介绍（一）
这个系列会分成三部分来写:
一：Provider 和 Action 的运行原理
二：Evaluator 的运行原理
三：Eliza Memory 的设计思想

当前是第一篇文章主要介绍：
Provider 和 Action 的运行原理

1. Eliza的架构如下，主要分为3个部分：
- 最上层抽象成了 Provider 和 Evaluator 以及 Action ，分别对应人类获取信息的能力(眼睛获取视觉信息，耳朵获取听觉信息等等)，以及人类根据信息的执行能力(比如通过市场信息判断BTC未来还有)，还有Evaluator只类似人类的思考能力，通过思考从海量的信息中提取知识从而形成个人的认知。
- 最下层是不同的 AI Model:目前Eliza框架支持了市面上大多数的AI Model，比如openai, claude, gemini, gork, xai等等，这个类似人类的大脑是所有做出决策的关键处理模块。
- memory则是让通过Eliza框架启动的Ai Agent拥有跳出Content Limitation 限制的能力，因为AI 既可以在Provider阶段把从环境中获取的信息和Action执行后结果的信息压缩之后存储进入Memory之中；并且也可以通过Evaluator提取跟人类对话或者其他任意交互过程中一些关键信息(这个会在下一个Thread里详细介绍)

2. 在接下来的部分我们将详细介绍「Provider」 和 「Action」的运行原理

--「Provider」--

对于Provider我们需要思考三个问题：
1. Why need Provider(Eliza框架为什么要设计Provider这个组件)?
2. AI 如何理解Provider 提供的信息？
3. How to invoke Provider(Eliza框架内AI如何通过Provider获取信息)?

- Why need Provider?
Provider主要用来解决在一些信息我们通过prompt让AI获取不准确也不够全面的问题，因为我们现在使用的模型都是通用大模型，所以对特定领域的信息获取有时候会存在不够全面的问题。

比如下面的代码就是Eliza中TokenProvider的实现，它最终会通过我们提供的Api 去拿到一个Token在链上多个纬度的关键信息，比如这个代币前十个Holder是谁每个人占据了多少份额的代币，这个代币24h的价格变化等等信息并且最终会用文本的方式返回给AI Model，这样一来AI Model就可以根据这些信息来作做出一些是否购买meme token的关键决策了。
但是如果我们直接通过Prompt告诉AI帮我获取对应的这些信息，你会发现AI会提供给我们对应的代码(并且有些时候AI提供的代码不一定能跑出来还需要把对应代码运行产生的错误提交给AI最终才能让代码顺畅运行)，但是我们还是需要将其部署到区块链环境（同时我们也需要提供可靠的API-KEY).
比如下面的例子:
所以为了保证获取数据的顺畅性，在Eliza的框架里会这部分获取数据的代码封装到Provider的定义下，这样以来我们就能很方便的获取任意账户内在solona上的资产信息了，因此这是Why need Provider的核心原因.

2. AI 如何理解Provider 提供的信息？
Eliza框架通过Provider拿到的信息最终会用文本(自然语言)的形式来返回给AI Model，因为AI Model 对请求信息的格式要求就是自然语言。


2/5

3. How to invoke Provider(Eliza框架内AI如何通过Provider获取信息)?
目前Eliza框架内对于Provider，虽然有提供对应的接口抽象，但是目前Provider的调用方式并不是模块化的，还是有特定的Action根据自己的信息需求直接调用对应的Provider进行获取，关系图如下:
假设我们有一个BuyToken Action当他在判断自己是否应该根据人类的推荐购买一个Token时，他就会在执行这个Action过程中请求TokenProvider和WalletProvider提供信息，TokenProvider会提供信息辅助AI Agent判断这个Token值不值得买，Wallet Provider会提供私钥信息用于交易签名，同时也提供该钱包可用资产的信息。

---- 「Action」 -----

可以在以下Github链接(elizaos.github.io/eliza/docs/cor…)很方便的找到Action的定义，但是你如果没有深入看代码你很难理解：
1. Why need Action？（Eliza框架为什么需要Action）
2. How to Invoke Action？(Eliza框架如何让AI调用Action)
3. Eliza框架 Action 具体执行了什么？
4. 怎么让AGI 理解他刚刚调用的Action做了什么 ？

-- Why Need Action? (Eliza框架为什么需要抽象出Action?)

假如我跟AI说: 我的私钥
0xajahdjksadhsadnjksajkdlad12612
这里面有10个sol，你能不能帮我买100个 Ai16z的代币。

Claude的回复如下：
很明显通过这样给予私钥的操作并不安全，同时AGI也很难执行这种链上操作。

这里我们可以进一步问AGI: 你能不能给我们实现相应的执行代码：当我们钱包中有Sol的时候，我希望可以把钱包里的所有sol都买成我指定的meme代币。
Claude当然有这个能力，但是还是需要我们多次引导，才最终可以得到让我们满意的代码。

因此我们可以把AI给予的代码封装成Eliza的一个Action,并且给一些Prompt的Example，来帮助AI理解什么时候我该调用这个Action。

（而且在真实的使用场景里我们想做的操作比这个要复杂很多，比如一笔Swap交易我们希望有滑点限制，那么这些条件限制交给AI大模型去完成的时候我们其实很难保证执行过程后每一个要素都可以满足我们的要求）。

1/n

privacy-pools原理解析:

Tornado Cash的新版本出来了，昨天@ameensol(TC早期开发者)宣称privacy-pools已经在Optimism上部署

privacy-pools是TC的升级版本，可以支持用户在从混币器中提款的时候，附带一个提款证明，证明自己要提款的资金不是黑客部署在混币器中的资金。

#privacypools #zk 2/n
我怀着好奇的心思跑去他们的github仓库看了下他们的代码, 然后"牛逼"!

I like the pretty cool code for privacy-pools!Awesome work!@ameensol

以下是具体的原理介绍:

1/n

白话介绍下 TC:
（吐槽:没办法打全称Torn...Cash,不然Tweet）

在ZK很火热的今天，考古下TC是很有意义的，毕竟它在我眼里是区块链领域第一个成功将ZK用于有效解决实际问题的协议！

TC是一个混币协议，顾名思义，你把token存入到TC中，再取出来的时候就很难追踪它的来源了(“洗钱”)；
#zk #ZKP 2/n

实际用途：

由于区块链账户在链上做的所有操作，以及账户余额都是公开的，所以基本没有隐私可言；
而TC可以让你实现一笔加密转账，这笔转账除了发送和接收账户，其他人都无法通过链上信息破译这笔交易。

1/n
Arbitrum 提出了一种新的 Sequencer 交易排序策略介绍:

Arbitrum 目前使用的交易排序的方式是FCFS(先进先出)，用通俗的话解释就是Sequencer先处理它先接收到的交易(optimism 也是用的相同的策略)。

但是这种方式有一个缺点，就是会造成"延迟竞争"(latency racing)。
#Arbitrum #MEV 2/n
“延迟竞争“指的是，在当前Arbi的Sequencer的排序策略下，用户希望自己的交易比其他人的交易更快被Sequencer接收，并且打包到L1的方法，就是向一个与Sequencer连接并且网络延迟最低的fullnode发送交易。