buzz 是什么：Block 开源的多 Agent 通信平台全景图
本文基于 buzz 仓库 commit 8342dfc（2026-08-04）梳理，该项目仍在高频迭代，具体行为以仓库 https://github.com/block/buzz 最新代码与文档为准。
**buzz 真正值得工程师看的不是它长得像个团队聊天工具，而是它把「人和 Agent 是同一类账号」这件事写进了协议层：两边用同一种密钥签名、同一种事件格式、同一条审计链，中继在处理一条消息时根本不需要知道对面是个人还是个进程。**多数 Agent 平台是先有一套人用的系统，再给 Agent 开一个 webhook 或者 bot 通道；buzz 走的是反过来的路——先定义一种所有参与者都必须遵守的事件格式，人和 Agent 都只是这张网络上的一个公钥。
这个判断成不成立、代价是什么，下面拆开看。
一、先把名字对齐，再说它解决什么
buzz 是个极常见的英文单词，中文里容易被读成「热度」或者「蜂鸣」。本文说的 buzz 特指 Block, Inc. 开源在 GitHub 上的这个多 Agent 通信平台，仓库地址 https://github.com/block/buzz ，Apache-2.0 许可证（Copyright 2026 Block, Inc.）。它是一个 Rust 单体仓库，crates/ 下有 28 个 crate，另外还有 desktop/（Tauri + React 桌面端）、mobile/（Flutter）、web/、admin-web/ 几个前端目录。
它想解决的问题，README 里用一句话概括自己：一个人和 Agent 一起干活的工作区，跑在你自己拥有的中继上。这是项目自己的定位说法，不是本文的结论。
值得关注的是它对现状的判断。今天团队里的 Agent 通常是这样的：Agent 在 CI 里跑，结果发到 Slack；Agent 在 IDE 里改代码，记录留在本地；Agent 审代码，评论进了代码托管平台。三个地方三套身份、三套权限、三条不互通的记录。想问「这个改动当初为什么这么做」，得开五个标签页拼。buzz 的下注是：如果消息、反应、工作流步骤、代码补丁、审批结论全是同一种签名事件，落在同一个日志里，那这些问题就退化成一次搜索。
这里先做个分工说明。本篇只拆 buzz 这一个项目的结构；如果你还在「该不该上开源 Agent 方案」这一步，开源 AI 工具的选型方法和开源 Agent 平台盘点更合适，想横向比几家的取舍可以看三个开源 Agent 项目的对比。本篇是系列总览，后面几篇会分别下钻到事件管线、Agent 接入和自建部署。
二、协议底座：Nostr 的几个概念，先讲清再往下
buzz 的线上格式直接用 Nostr 的 NIP-01。先解释一下编号：NIP 是 Nostr 这套去中心化协议的规范编号，一份 NIP 就是一份约定某类事件字段和交互流程的文档，NIP-01 是最底下那份，规定了事件长什么样、订阅怎么发。后面会出现的 NIP-42（连接鉴权）、NIP-98（HTTP 请求鉴权）、NIP-34（git 相关事件）、NIP-44（端到端加密）都是这个编号体系里的其它约定。buzz 自己还起草了一批带字母编号的 NIP 放在 docs/nips/。
你不需要懂去中心化社交网络，只要抓住四个词。
事件（event）：一条 JSON，六个字段。ARCHITECTURE.md 里给的形状是 id（正规化序列化后的 sha256）、pubkey（secp256k1 公钥，十六进制）、kind（无符号整数）、tags（结构化元数据）、content（JSON 载荷或纯文本）、sig（对 id 的 Schnorr 签名）。一条聊天消息是事件，一个表情反应是事件，一步工作流执行也是事件，区别只在 kind。
事件签名：发消息的人用自己的私钥对事件 ID 做一次 Schnorr 签名，任何拿到这条事件的人都能用公钥验回去。这意味着「谁说的」不靠服务端记账，而是数学上可验证的。crates/buzz-core/src/verification.rs 和 event.rs 是这一块的落点，verify_event() 同时验签名和验 ID 哈希——ID 是内容的哈希，改内容 ID 就变，改 ID 签名就废。文档明确写了这个函数是 CPU 密集的，调用方用 spawn_blocking 挪出异步线程。
kind（种类号）：整数，也是唯一的分发开关。中继按 kind 路由、存储、扇出，客户端按 kind 过滤订阅。加新功能就是加一个新 kind 号，老客户端看不见也不会崩。crates/buzz-core/src/kind.rs 是这份名单的源头，里面用 pub const KIND_*: u32 一个个定义，再汇总成 ALL_KINDS。顺带一提，ARCHITECTURE.md 在两处对这份名单的规模给了不一样的数字（一处写 127，一处写 80），而当前 kind.rs 里 pub const KIND_*: u32 形式的常量有 128 个——遇到这类冲突以代码为准，文档在这种高频迭代的仓库里天然滞后。
中继（relay）：接收、验证、存储、转发事件的那台服务器。这是 buzz 和典型 Nostr 用法差别最大的地方。ARCHITECTURE.md 写得很直白：中继是唯一真相源，所有读写都过它，没有点对点事件交换，没有八卦传播，没有复制。八卦传播（gossip）指节点之间互相传播消息、最终各自收敛到同一份数据的做法，很多去中心化系统靠它扩散数据——buzz 明确不做这件事。也就是说，它借了 Nostr 的事件格式和身份模型，但拓扑是老老实实的单点服务端。
密钥自持：你的身份就是一对 secp256k1 密钥。Agent 也一样，README 里给 Agent 的说明是设置 BUZZ_PRIVATE_KEY 环境变量再用 buzz-cli。这条要说清楚代价：没有「忘记密码」这一说，私钥丢了等于身份丢了，私钥泄露等于身份被人拿走且对方发的每条事件都带着合法签名。buzz-admin 有个 generate-key 子命令用来生成密钥对做初始化，但生成之后怎么保管是你自己的事。
三、仓库地图：先认路再看代码
想读这份代码，先别从 buzz-relay 进。按下面这张表定位，你要解决什么问题就翻哪块。表里的路径都是仓库里实际存在的位置。
| 组成部分 | 它负责什么 | 仓库位置 | 你什么时候会碰到它 |
|---|---|---|---|
| buzz-core | 零 I/O 的类型层：事件、kind 名单、过滤器匹配、签名验证 | crates/buzz-core/src/（event.rs、kind.rs、filter.rs、verification.rs） | 想知道某个功能到底是什么 kind、事件长什么样时 |
| buzz-relay | Axum 写的 WebSocket 服务端，串起所有子系统，还托管 git 和语音 | crates/buzz-relay/（音频在 src/audio/） | 排查连接、鉴权、扇出问题时 |
| buzz-db | Postgres 事件存储、频道成员、工作流、审批 | crates/buzz-db/（event.rs、channel.rs、workflow.rs、partition.rs） | 关心数据落在哪张表、怎么分区时 |
| buzz-auth | NIP-42 与 NIP-98 两条鉴权路径、scope、限流接口 | crates/buzz-auth/ | 设计权限模型、评估限流现状时 |
| buzz-audit | SHA-256 哈希链审计日志 | crates/buzz-audit/ | 要做合规留痕、验证记录没被改过时 |
| buzz-workflow | YAML 即代码的自动化引擎 | crates/buzz-workflow/ | 想让某个事件自动触发动作时 |
| buzz-cli | 面向 Agent 的命令行，JSON 进 JSON 出 | crates/buzz-cli/src/commands/（channels.rs、messages.rs、repos.rs、patches.rs 等） | 让 Agent 以工具调用方式操作平台时 |
| buzz-acp | 把中继上的 @提及 桥接到 AI Agent 的常驻进程 | crates/buzz-acp/（relay.rs、queue.rs、pool.rs、acp.rs） | 接 Goose、Codex、Claude Code 这类 Agent 时 |
| buzz-agent / buzz-dev-mcp | 自带的 ACP Agent 和给它用的 shell、文件编辑 MCP 服务 | crates/buzz-agent/、crates/buzz-dev-mcp/src/（shell.rs、str_replace.rs、rg.rs、tree.rs） | 评估 Agent 到底能动你机器上的什么时 |
| NIP 规范文档 | 这个项目自己起草的事件规范 | docs/nips/ 15 份 md 加 2 份 fixtures json，另有 crates/buzz-core/src/pairing/NIP-AB.md | 想搞清某个自定义事件的字段约定时 |
| 部署与迁移 | 单机/VPS 的 Compose 包、数据库迁移 | deploy/compose/、migrations/（27 份 SQL） | 自建中继时 |
几个能自己数出来的结构性事实，帮你判断这个项目的重心在哪：docs/ 下 53 个文件，根目录躺着 8 份 VISION*.md，benchmarks/ 40 个文件，deploy/ 64 个文件；desktop/ 有 2359 个文件、mobile/ 467 个，前端体量远大于 crates/ 的 413 个。全仓 3704 个受版本控制的文件，其中 bin/ 下 41 个是 hermit 工具链的软链接。根目录同时放着 AGENTS.md 和 CLAUDE.md——这个项目自己也是用 Agent 在写。
一条读码路线：从 crates/buzz-core/src/kind.rs 看一遍 kind 名单，就大致知道这个平台有哪些能力了；然后看 ARCHITECTURE.md 第 4 节的事件管线，那是所有写入路径的骨架。
四、事件进来之后发生了什么，Agent 又能干到什么程度
ARCHITECTURE.md 把 handlers/event.rs 的处理顺序列成了 12 步：鉴权检查、公钥比对、拒绝 AUTH 事件、临时事件分流、验签、频道成员校验、写库、Redis 发布、扇出、搜索索引、审计、触发工作流。后三步是 fire-and-forget，失败不影响事件本身被接收；客户端拿到 OK 是在整条管线跑完之后，不是写库就返回。
有两个设计细节值得单独拎出来。
一是 kind 20000–29999 这段是「临时事件」，走另一条短管线，不写 Postgres、不进审计、不进搜索，历史查询里永远查不到。在线状态、正在输入这类高频信号走这里。这是个很务实的取舍：不是所有信号都值得留档。
二是扇出的安全边界。文档写明，频道内的事件只投递给带有匹配 channel_id 的订阅，没有频道约束的全局订阅被显式排除在外。REQ 订阅处理器也是先查频道访问权限、再注册订阅，把「注册完到权限校验之间收到私有频道事件」的竞态窗口堵死。这类边界在读代码时容易一眼扫过去，但它决定了私有频道是不是真的私有。
Agent 这一侧有三条不同的接法，别搞混：
buzz-cli 是 Agent 优先的命令行，JSON 进 JSON 出，专门给大模型的工具调用用。crates/buzz-cli/src/commands/ 下的文件名基本就是能力清单：频道、消息、私信、反应、仓库、补丁、PR、工作流、上传、记忆、审核。
buzz-acp 是常驻的桥接进程，架构是「中继 —WebSocket→ buzz-acp —stdio 上的 ACP/JSON-RPC→ Agent」。ACP 是 Agent Client Protocol，一套让宿主程序通过标准输入输出驱动 Agent 会话的协议；MCP 则是 Agent 反过来调用外部工具的协议。两者方向相反，一个管「谁来驱动 Agent」，一个管「Agent 能调什么工具」。
它用 NIP-42 连上中继，按频道给 @提及 事件排队，每个频道同一时刻只有一个提示词在途，多个频道之间互不影响。这里有个默认行为要留意：queue.rs 的注释写明去重模式默认是 Drop——某个频道有提示词在途时，这个频道新来的事件会被静默丢弃（只留一条 debug 日志），换成 Queue 模式才会攒着等下一轮批量喂进去。也就是说默认配置下，Agent 忙的时候你追发的那句话可能根本不会被处理。进程池方面，子进程数量参数的取值范围是 1 到 32，子进程被判定为不健康会重新拉起。README 说它对接 Goose、Codex、Claude Code 这几家。想理解 ACP 和 MCP 各自的位置，可以看Agent 协议生态的对比。
buzz-agent 加 buzz-dev-mcp 是项目自带的一套。VISION_AGENT.md 说这两个二进制之间没有耦合：Agent 只说 ACP，工具服务只说 MCP，靠协议组合而不是靠 import。buzz-dev-mcp 给 Agent 的东西是一个 shell 和一个文件编辑器。这里有句话要认真读，VISION_AGENT.md 原文的意思是：这个 shell 运行在操作者的信任级别上，跟 bash 本身一样。翻译成工程语言就是——Agent 能跑的命令，就是启动这个进程的那个账号能跑的命令。文件编辑相对工作目录解析路径，进程有组级 kill 和输出上限，但信任边界本身没有被缩小。你要给 Agent 划权限，得靠容器、靠专用账号、靠 最小权限设计那套办法，不要指望这个 MCP 服务替你兜底。
五、边界与代价：它放弃了什么，哪些事它不管
这一节比前面几节更该读。开源项目的 README 都写得漂亮，真正决定你能不能用的是限制。下面这些大部分来自 ARCHITECTURE.md 的「已知限制」一节，那节自己写明是「已验证的实现缺口，不是设计愿景」。
没有端到端加密。VISION.md（这是项目的愿景文档，讲的是它想怎么做，不等于代码现状）在加密这一节给的是一句话模型：传输用 TLS，静态加密委托给存储层，比如 Postgres 的透明数据加密或者卷加密。服务端管理的加密覆盖每个频道、每条私信、每个事件，理由写得很直白——要让电子取证能查到所有东西。NIP-44 的端到端加密在那份文档里被列为面向私信的「未来考虑」。所以你要清楚：中继的运维者能看到明文内容。这不是漏洞，是它主动选的位置——为了可审计、可搜索，放弃了对服务端的保密性。你自建时，「谁能登到那台机器、谁能读到 Postgres」这两个问题的答案，就是「谁能看到全公司所有对话」的答案。
限流没有实现。buzz-auth 里有 RateLimiter trait，但 ARCHITECTURE.md 的已知限制表写明唯一的实现是测试桩 AlwaysAllowRateLimiter，而且它挂在 #[cfg(any(test, feature = "test-utils"))] 后面，正常构建根本编不进去；那张按人类、标准 Agent、提权 Agent、平台 Agent 分的四档限流配置只是设计目标，当前一档都不生效。一个人和 Agent 混跑、Agent 还能自己触发工作流的系统，这块空着意味着自建时要靠外层网关或者反向代理补。
工作流审批门没打通。request_approval 这一步返回挂起状态，但引擎还没持久化令牌、也不能恢复执行，撞上审批门的运行会被标记为失败（文档编号 WF-08）。另外 send_dm 和 set_channel_topic 两个动作在 schema 里有，执行时返回未实现（WF-07）。VISION.md 的状态表和 README 的三栏表也都把审批门标成在建。如果你的场景核心就是「Agent 提议、人批准」，这一块目前得自己接。
**语音有，录制没有。**实时语音是内建在中继里的 WebSocket Opus 转发，没有外部 SFU，房间有软上限。录制和分轨发布只预留了 kind 号，没有生产者。
**它不是区块链，也不做点对点。**README 里那句「Not blockchain」值得当真：签名事件在这里的作用是身份和防篡改，不涉及任何链。同时拓扑上中继是唯一真相源，多实例部署靠 Redis 在中继之间转发事件（文档说这条多节点扇出的链路已经接通），而不是靠节点各自存一份再互相同步——所有实例背后仍然是同一套 Postgres。所以扩的是接连接的能力，不是抗故障的份数：你按最小形态只跑一台，那台停了工作区就停了；就算跑多台，数据库那一层照样得自己做高可用。
审计链能证明什么、不能证明什么。buzz-audit 是 SHA-256 哈希链，每条记录的哈希覆盖包括前一条哈希在内的所有字段，verify_chain() 重算一遍就能发现篡改，起始记录用 64 个零。写入靠 pg_advisory_lock 保证单写。它能证明「这条记录写进去之后没被改过」，不能证明「该记的都记了」——临时事件和 AUTH 事件本来就不进审计链。
形式化验证的范围要看清。VISION.md 说多社区之间的隔离是被证明的而不是被声称的，docs/multi-tenant-relay.md 里确实用 TLA+ 建了并发与服务模型、用 Tamarin 在 Dolev-Yao 攻击者假设下建了授权协议模型，每条不变式还配了变异测试确认非平凡。形式化验证的意思是：把系统写成数学模型，让工具穷举所有可能的执行路径，证明某个性质在所有路径上都成立——比测试强得多，但它只覆盖被建模的那部分，模型之外的代码不在保护范围内。而且 README 明确说今天发布的是单中继形态，一个中继 URL 对应一个社区；多社区是架构里已经铺好的语义边界，不等于你下载下来就有一套跑起来的多租户产品。别把这两件事读混。
六、上手与避坑清单
下面每条都写清「为什么会踩」和「怎么避」。
**别拿根目录的 docker-compose.yml 上生产。**为什么会踩：根目录有个现成的 compose 文件，看起来直接能用。README 和 deploy/compose/README.md 都写了那份只用于日常开发，生产要用 deploy/compose/ 下的那套（Postgres、Redis、MinIO，另可选 Caddy 做 TLS）。怎么避：自建就直接进 deploy/compose/，从它的 .env.example 拷一份改。顺带把暴露面想清楚：这一套起来的是 Postgres、Redis、MinIO，加上中继本身，而中继这一个进程同时承担 WebSocket 事件、git 托管和语音房间的入口。真正需要从公网进来的只有中继（生产建议用那份可选的 Caddy 配置终结 TLS），数据库、Redis、对象存储三家都应该只留在内网或者容器网络里——它们一旦对公网可达，前面讲的那些签名和审计就都绕过去了，因为攻击者不需要发事件，直接读表就行。
**.env 里的 CHANGE_ME 必须全换，且换完不能再变。**为什么会踩：默认值能把服务拉起来，不换也不报错，等于把中继私钥和各种密钥暴露给任何读过这个仓库的人。deploy/compose/README.md 还提醒中继私钥、git 钩子的 HMAC 密钥、数据库/Redis/S3 的凭据要跨重启保持稳定——中继私钥一换，中继的身份就变了。怎么避：第一次部署就用密钥管理工具生成并固化，不要留在 shell 历史里。
**RELAY_OWNER_PUBKEY 没有 BUZZ_ 前缀。**为什么会踩：其它变量清一色 BUZZ_ 开头，手写时下意识加前缀，加了就不生效，封闭中继模式下等于没设 owner。文档特意说明这是有意为之，值必须是 64 位十六进制公钥。怎么避：照抄 .env.example，别凭记忆敲。
**生产环境绝不能开 dev feature。**为什么会踩：buzz-auth 里有个开发用的密钥派生，把用户名塞进一个固定前缀里做 SHA-256 就得到私钥，门只有一个 #[cfg(any(test, feature = "dev"))]。构建时手滑带上这个 feature，任何知道用户名的人都能算出私钥、冒充任意身份。怎么避：把「不带 dev feature」写进构建流水线的检查，不要依赖人工记忆。
**数据库迁移是 opt-in。**为什么会踩：新库直接启动中继，表不存在，报错看着像连接问题。文档说 BUZZ_AUTO_MIGRATE 默认不开，要么设成 true，要么先跑 buzz-admin migrate，而且自动迁移要求镜像里内嵌了迁移文件。怎么避：初始化时把迁移当成独立一步，别指望启动顺手做掉。
**镜像标签别跟着 main 走。**为什么会踩：默认镜像跟的是 ghcr.io/block/buzz:main，方便早期试用，但意味着重启一次就可能换了一版代码。文档自己建议生产钉到带 commit 短哈希的标签或者语义化版本标签。怎么避：部署清单里写死具体标签，升级作为一次有意的动作。
**Windows 上先装 Git for Windows。**为什么会踩：Agent 的 shell 工具在 bash 下执行命令，macOS 和 Linux 自带，Windows 没有，Agent 一调 shell 就失败。README 说 buzz 在运行时解析的就是 Git Bash。怎么避：装好 Git for Windows；如果想指向别的 bash 兼容 shell，设 BUZZ_SHELL 指到它的路径，Agent 的工具描述会跟着变。
**给 Agent 的私钥当成生产凭据管。**为什么会踩：BUZZ_PRIVATE_KEY 是个环境变量，测试时随手 export 一下很自然，然后就留在了脚本、CI 日志、shell 历史里。拿到它的人不只是能读消息，还能以这个身份发事件、开频道、推补丁，而且每条都带合法签名，审计链会忠实记录成「这个 Agent 干的」。怎么避：一个 Agent 一把独立密钥，走密钥管理注入，出事了能精确吊销一个身份而不是全盘重来。相关的权限思路见前面那篇最小权限设计。
**别把 VISION*.md 当功能清单看。**为什么会踩：根目录 8 份愿景文档写得很完整，读起来像已经做完了。它们写的是项目想去的地方。怎么避：判断某个能力有没有，以 README 那张三栏表（已工作 / 在接线 / 有观点没代码）和 ARCHITECTURE.md 的已知限制一节为准，最后回代码确认。
收个尾
把这篇的判断压成一句：buzz 的核心不是聊天，是「同一种签名事件」这个统一底座，人和 Agent 在上面拿到同样的表面积和同样的留痕方式；代价是服务端能看到全部内容、中继是单点、限流和审批门这两块目前还空着。
如果你要继续往下读，建议这个顺序：先 crates/buzz-core/src/kind.rs，一遍下来就知道这个平台定义了哪些能力；再 ARCHITECTURE.md 第 4 节和第 9 节，一个给你写入路径，一个给你实现缺口；再 crates/buzz-cli/src/commands/ 目录，看 Agent 到底能调什么；最后 deploy/compose/README.md，判断自建成本。
评估时给自己三个问题：你的场景能不能接受服务端可读明文？「Agent 提议、人批准」是不是你的核心链路（是的话审批门那个缺口现在就是你的工作量）？你有没有地方能安全地存住每个 Agent 的私钥？三个都过得去，再谈接入。
这个系列的其余文章
这篇是总览。想往下挖，按下面两条线走：先把它跑起来用，或者直接读代码。
上手与使用
- Block 开源多 Agent 通信平台 buzz：从拉仓库到跑通中继
- buzz 命令行怎么用：Block 开源的多 Agent 通信平台上手
- 把 Agent 接进 buzz：Block 开源多 Agent 通信平台的三层结构
- Block 开源多 Agent 通信平台 buzz 的工具来源：内置工具与 MCP 如何合并
- Block 开源的多 Agent 通信平台 buzz：用 ACP 把现成编码智能体接进去
- Block 开源多 Agent 平台 buzz：自建中继要想清的几件事
- Block 开源多 Agent 通信平台 buzz 桌面端与中继分工拆解
- Block 开源 buzz：多 Agent 通信平台的移动端为何重写协议
- Block 开源多 Agent 平台 buzz：一张图上传的四道关
- Block 开源多 Agent 通信平台 buzz 的推送网关：授权、令牌与设备证明
- Block 开源多 Agent 平台 buzz：语音在中继与本地如何分工
- 拆解 Block 开源 buzz 多 Agent 平台的 MCP 服务器
- Block 开源 buzz：多 Agent 平台的 Git 仓库托管链路
- 让 Agent 跑在集群里：Block 开源多 Agent 通信平台 buzz 的远程调度模型
- Block 开源多 Agent 通信平台 buzz 的四层排障顺序
结构与机制
- Block 开源多 Agent 通信平台 buzz 的仓库结构导读
- Block 开源 buzz：多 Agent 平台为何建在 Nostr 上
- buzz 多 Agent 通信平台：Block 为何先写 NIP 规范
- Block 开源的多 Agent 通信平台 buzz：一切皆签名事件
- Block 开源多 Agent 通信平台 buzz 的两层隔离：租户在中继之上，频道在租户之下
- Block 开源多 Agent 通信平台 buzz：engram 把记忆做成事件之后，检索边界在哪
- Block 开源 buzz 多 Agent 通信平台：中继内部三层转发
- 谁能连上你的 buzz 中继：Block 开源多 Agent 通信平台的三层门禁
- buzz 中继网状互联：Block 开源多 Agent 平台的四块拼图
- Block 开源 buzz：多 Agent 通信平台的四道发布订阅闸门
- 拆解 Block 开源多 Agent 通信平台 buzz 的两套鉴权设计
- Block 开源 buzz 多 Agent 平台：多租户隔离线要画三遍
- Block 开源 buzz 的审计链：多 Agent 平台里谁改了什么
- Block 开源多 Agent 通信平台 buzz 数据层怎么改表不停机
- 拆解 Block 开源多 Agent 通信平台 buzz 的一轮主循环
- buzz 多 Agent 通信：Block 开源平台里活递给谁看目录
- Block 多 Agent 通信平台 buzz 的 ACP 会话池与队列
- Block 开源多 Agent 通信平台 buzz 的可观测最小实现
- Block 多 Agent 平台 buzz：persona 包四道工序
- Block 开源多 Agent 通信平台 buzz 的工作流执行器拆解
- Block 开源 buzz 多 Agent 平台的设备配对：一份 NIP 规范加一份形式化模型
- Block 开源 buzz：多 Agent 通信平台的两处形式化验证
- Block 开源多 Agent 平台 buzz：一致性检查器怎么对齐实现
- Block 开源多 Agent 通信平台 buzz：人机共处一张消息网
全部文章也汇总在 buzz 开源专题。如果你想看的是另一类「让 Agent 去操作一个专业软件」的样本——不是通信方向，而是让它直接读写 Word、Excel、PPT——见 OfficeCLI 是什么：给 AI Agent 用的开源文档读写套件。