fuchencong

如果只看界面，Multica 像一个可以把任务分给智能体的看板；如果只看后端，它又像一组带 WebSocket 的 Go API。真正把这些部分串起来的，是一条很具体的工作链路：人创建一项任务，服务器把这项工作排进队列，运行时所在机器上的守护进程领取它，守护进程再启动本机已经安装好的 agent CLI，最后把进度、评论和结果写回同一项任务。

这篇文章从这条链路出发，介绍 Multica 的模块边界和协作方式。代码以仓库当前实现为准（commit：ea94c7cd5bbce9c8e1f28c5fa049c47ee7651d02），示例中的路径都可以在源码中直接找到。

文本开始学习一个开源 AI 开源项目 Multica，该项目后端主要通过 Go 实现，通过这个项目，我们可以学习一个 AI 智能体协作平台的核心实现思路。

昨天晚上中国男篮在亚运会半决赛 20 分惨败中国男篮，作为一个长期关注中国男篮的球迷，这个结果的确让人难受，有点像自己高中没有考好的难受。昨天晚上看虎扑看到一点多，今天也自己写点。

很多业务请求并不需要在 HTTP 请求返回前完成全部工作。发送邮件、生成缩略图、同步第三方订单，这些操作可能很慢，也可能因为外部服务不稳定而失败。如果把它们直接放在请求处理函数里，用户要等待，服务也更容易在高峰期被拖垮。任务队列解决的正是这个问题：请求只负责登记一项工作，后台 Worker 稍后完成它。

本系列文章将会学习一个极简的 Go 异步任务队列 Asynq，本文先不急着钻进所有内部细节，而是用一个可以运行的例子认识 Asynq，再沿着这个例子看清 Client、Redis、Server 和 Handler 各自做了什么。

经过前面十四篇文章，我们沿着一条主线拆解了 go-zero 的完整肌理——从 goctl 代码生成，到 REST 与 zRPC 的请求处理链路，再到服务发现、弹性保护、可观测性和数据访问层。这是一条"正常路径"：服务按预期启动，请求按预设流程处理，一切都在理想状态下运转。但在真实的工程实践中，理解一个框架远不止读懂主流程。

我们已经把 go-zero 的核心肌理几乎全部拆解了一遍：从 goctl 的代码生成，到 REST 和 zRPC 的请求处理链路，再到服务发现、弹性保护、可观测性与数据访问层。这些能力构成了一个微服务框架的基础设施——你可以在上面构建出一个完整的微服务系统。

但是，框架的真正活力在于扩展性。当核心能力稳定之后，自然会涌现出在核心框架之上构建更高层抽象的需求。go-zero 的 gateway 包和 mcp 包就是这种思路的两个典型产物：它们不修改 rest 或 zrpc 的一行代码，却分别构造出了协议网关和 AI 工具协议服务两种全新的服务形态。

go-zero 的数据访问层由 core/stores/ 下的六个子包构成——sqlx、redis、cache、sqlc、mon、monc。本文就沿着这条层次线索来阅读源码：先从底层的 sqlx 和 redis 入手，理解连接管理和监控机制；然后深入到 cache 层，拆解 Cache-Aside 模式及其三种防护策略；最后看 sqlc 和 monc 如何把数据库和缓存编织在一起。

这篇文章将学习 go-zero 的一些底层组件，这些工具本身不参与业务逻辑，也不直接暴露给最终用户。它们构成了框架的"标准库"——如果上层建筑是房屋的梁柱，这些工具就是砌成梁柱的砖石。它们分布在 core/collection/、core/syncx/、core/executors/、core/fx/、core/mr/ 和 core/threading/ 六个包中。我们不会逐个罗列所有类型，而是从上层模块的依赖关系出发，沿着"时间工具 → 并发控制 → 执行器 → 高级抽象"这条线索来组织它们。

当断路器跳开了、降载器拒绝了请求、限流器拦住了调用方——你如何知道这些事正在发生？更进一步，当系统一切正常时，你如何验证一切正常？这就是可观测性的领域。它不直接参与业务逻辑，但它回答运维中最基本的问题。

• “刚才发生了什么？” → 日志（Logging）
• “这个请求经过了哪些服务？每个环节花了多久？” → 链路追踪（Tracing）
• “系统整体表现如何？QPS、延迟、错误率分别是多少？” → 指标（Metrics）

在上一篇文章的最后，我们走完了 go-zero 的服务发现与负载均衡链路——客户端通过 etcd Watch 实时获取在线节点列表，再通过 P2C 算法选择延迟最低、在途请求最少的那个节点发出请求。这一切运转良好的前提是：下游是健康的，流量是可控的，CPU 是空闲的，但生产环境从来不缺少意外。