一个按 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），示例中的路径都可以在源码中直接找到。
昨天晚上中国男篮在亚运会半决赛 20 分惨败中国男篮，作为一个长期关注中国男篮的球迷，这个结果的确让人难受，有点像自己高中没有考好的难受。昨天晚上看虎扑看到一点多，今天也自己写点。
经过前面十四篇文章，我们沿着一条主线拆解了 go-zero 的完整肌理——从 goctl 代码生成，到 REST 与 zRPC 的请求处理链路，再到服务发现、弹性保护、可观测性和数据访问层。这是一条"正常路径"：服务按预期启动，请求按预设流程处理，一切都在理想状态下运转。但在真实的工程实践中，理解一个框架远不止读懂主流程。
我们已经把 go-zero 的核心肌理几乎全部拆解了一遍：从 goctl 的代码生成，到 REST 和 zRPC 的请求处理链路，再到服务发现、弹性保护、可观测性与数据访问层。这些能力构成了一个微服务框架的基础设施——你可以在上面构建出一个完整的微服务系统。
但是，框架的真正活力在于扩展性。当核心能力稳定之后，自然会涌现出在核心框架之上构建更高层抽象的需求。go-zero 的 gateway 包和 mcp 包就是这种思路的两个典型产物：它们不修改 rest 或 zrpc 的一行代码，却分别构造出了协议网关和 AI 工具协议服务两种全新的服务形态。