Skip to content

oekit(姊妹项目) ​

一句话

oagentkit 依赖 oekit 的三个包,反过来不成立。两者是两套独立矩阵,不是子品牌。

oagentkitoekit
全称Open Agent KitOpen Easy Kit
面向Agent / LLM 编排Go 微服务
模块数1324
能力层4 层(tier 0–3)5 层
框架地板einoHertz / Kitex
适合谁写 Agent、接模型与工具写微服务、治理与数据访问

两者共享同一套方法论,各自独立发版:

  • 按框架耦合度分层,不是按功能目录
  • 依赖严格自底向上,无环
  • 每仓独立 SemVer + 独立 CI
  • 每个仓库根目录都有 AGENTS.md —— 面向 AI Agent 的权威规范
  • CI 门禁都是 reusable workflow,规则本体只在一个仓里

入口 ​

去哪地址
文档站oekit.github.io
架构总览(五能力层架构图)oekit.github.io/about/architecture
模块索引(机器可读)oekit.github.io/llms.txt
版本矩阵oekit.github.io/versions.json
GitHub 组织github.com/oekit

oagentkit 依赖它的三个包 ​

只有这三个,其余 oekit 模块与本矩阵无关。

oekit 包oagentkit 用在哪
pkgerrors(Wrap/BizError)/ stringx / encoding / mathx —— 20 合 1 零第三方依赖微工具集
concurrencyGoSafe goroutine 池 / 单飞 / 重试 / 令牌桶 / 滑动窗口 / 时间轮 / 熔断
logx全矩阵日志门面,组件 logger 一律 logx.Delegating("oagentkit-<repo>")

为什么是这三个 ​

  • pkg —— 纯标准库、零第三方依赖。带进来不会抬地板,这是能进底层依赖的第一条件。
  • concurrency —— 并发原语与业务无关,两个矩阵都会用。
  • logx —— 日志门面是全矩阵的统一要求(每个仓的 AGENTS.md 都写着日志走 logx)。

反过来 oekit 不会做 LLM 场景适配:oekit/tracing 提供 Provider, 「把 LLM 调用挂上去」由本矩阵的 obs 完成。 两者互补,不重叠。

oekit 的 24 个模块 ​

依赖严格自底向上,五个能力层:

层模块
基础库pkg kitx concurrency core
可观测性logx tracing metrics
数据访问gormx redis etcdx data timertask
通信 · 服务治理httpx nns-endpoint network nns registry
应用引导 · 框架生态bootstrap hertz kitex middleware workflow k8s

注意 pkg / concurrency / logx 分处不同层——oagentkit 挑的是三个不同层里的各一个, 不是因为它们在 oekit 内部挨着。

完整清单见 oekit llms.txt。

易混点 ​

两套矩阵里有同名但语义相反或不同族的包,按包名对齐会做错:

包名oekitoagentkit
progress长任务阶段进度追踪器(NewTracker/PhaseConfig/PhaseStatus)泛型事件总线(Bus[T],发布订阅 + 慢消费者丢弃计数)
breaker三态熔断器当前实现方已退役,原实现迁到 oekit(见下)

两个仓都在你的 import 里,按前缀逐段对:oekit/concurrency/progress ≠ oagentkit/runtime/progress。

breaker 现在归 oekit ​

runtime/breaker 已删除,三态熔断器迁到了 oekit/concurrency/breaker, 由 llm/breaker.go 的准入适配层消费。

这正是上面那条「按语义对齐」的价值:正因为按语义判断过,才没在按包名对齐时 做出「runtime 的 breaker 比 oekit 的语义更正、应该留在 runtime」的错误结论。

退役的分阶段纪律见架构总览。

相关 ​

MIT License