fuchencong

用 Go 调用大模型，最先遇到的问题通常不是发出一个 HTTP 请求，而是如何让模型、提示词、历史消息和外部资料可以逐步组合。每个模型服务的请求格式、鉴权方式和流式响应又不完全相同，如果业务代码直接绑定某一家服务，后续替换模型就要重新改一遍调用链。LangChainGo 是 LangChain 的 Go 实现，为这些常见需求提供了可组合的组件。

一个 AI 服务准备推出付费套餐：每月收取 20 美元平台费，包含十万 Token，超出部分每 Token 收取 0.00001 美元。客户可以升级套餐，运营可以额外赠送额度，企业客户还可以预付一笔余额。产品页面上，这些规则只占几行字。到了实现中，却会出现一连串需要分别回答的问题：赠送的额度月底是否清零；额度耗尽后是否继续放行；套餐升级从今天还是下个月生效；已经出账的费用能否跟着新价格重算。

OpenMeter 用客户、计量器、产品目录、订阅、权益、费用、账单和账务记录来承载这些规则。本文沿着这个 AI 服务展开，重点介绍各个概念为什么存在、源码怎样表达它们，以及相邻模型如何协作。

一个按 Token 收费的 AI 服务，最初可能只需要一张用量表：请求完成后记下客户、模型和 Token 数量，月底求和，再乘上单价。随着事件增多，问题逐渐出现在记录和查询链路上：客户端重试可能产生重复记录，离线任务可能补报昨天的用量，逐条写入会拖慢存储，刚上报的事件也未必能立即查到。要得到可信的用量，首先需要弄清这些事件经过了哪些处理，以及每一步成功究竟意味着什么。

OpenMeter 把事件接入、后台写入和计量查询拆开，分别交给 API server、Kafka、Sink worker 和 ClickHouse 协作完成。业务配置及其他需要事务约束的状态保存在 PostgreSQL，内部消息和通知机制则连接后续处理。理解这些组件之间的数据流和一致性边界，比记住项目用了哪些数据库更有帮助。

很多产品的价格与资源消耗有关：API 按调用次数收费，AI 产品按 Token 收费，CI 平台按构建分钟收费。真正麻烦的地方通常不在“加一”，而在于事件来源很多、需要按客户和时间窗口聚合，还要处理重试、重复上报、迟到事件以及后续的额度和账单。OpenMeter 把这部分工作拆成一条可观察的事件链路：应用发送使用事件，系统把事件可靠地写入消息队列，再由 worker 校验、去重和保存；查询接口从用量存储中按计量器计算结果。这样，业务代码只需要描述“发生了什么”，不用在每个服务里重复实现计数和聚合逻辑。

Multica 的一次运行，始于 Go 后端服务创建的任务队列，终于一条可查看的运行记录。daemon 领取任务后，在安装了 Claude Code、Codex、Cursor、OpenCode 等 Coding Agent 的机器上启动相应程序，再把过程和结果传回后端服务。不同 Coding Agent 的启动方式和输出格式各不相同。本文沿着一次 Run 的过程，介绍 Multica 如何统一这些 Coding Agent，如何在它们之上配置自己的智能体，以及工具调用和 Coding Agent 输出如何被记录下来。

Multica 的一项工作不会只落在一张表里。创建一个 Issue 会涉及工作区、成员、项目、标签和附件；把它交给 Agent 后，又会产生 Runtime、队列任务、运行消息和用量记录。数据库模型要解决的核心问题，是让这些记录各自保存清晰的事实，同时还能沿着同一个工作区和同一个 Issue 找回完整上下文。

本文先从核心数据抽象建立坐标，再列出当前 schema 的全部业务表，随后按领域解释模型如何组织业务事实和生命周期，最后回到 Go 服务端说明 SQL、事务和业务 Service 如何访问数据库。

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

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

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

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

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

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