HNOGo 原生多智能体框架

本地系统开销矩阵 ​

主框架对比使用同一个确定性的本地 OpenAI-compatible Stub，比较 HNO、Agno 和 LangGraph。每行使用 100 次正式操作、5 次预热、fresh operation 生命周期 以及相同的 1 ms Stub 响应延迟。RSS 是进程树工作集；RPS 是正式测量批次的 吞吐，不是生产容量承诺。

在并发度 8 下，HNO 在这个固定本地协议中的测得批次 RPS 约为 LangGraph 的 16.6 倍、Agno 的 33.3 倍；并发度 32 下约为 15.0 倍和 21.3 倍。这些 是本地编排和运行时观测，不是远程模型加速。

完整的本地系统开销矩阵包含原始 JSON、 资源指标定义和复现命令。

远程模型附录 ​

远程 DeepSeek 测试是独立的端到端快照：每条路径 100 次正式请求，并发度 8。 它包含网络、Provider 排队和模型生成时间，因此不是纯框架 benchmark。

相对倍率定义为 Direct API 平均耗时 / 路径平均耗时。这组数据只能说明 本次快照中端到端延迟接近且 HNO 略有优势，不能作为远程生产性能的普遍结论。 详见远程性能报告。

HNO 博客最新文章 ​

AI Agent 框架性能怎么测：为什么运行时开销比模型延迟更重要 ​

阅读完整文章

当一个模型或 Agent 框架成为热点时，先把模型延迟和框架开销分开，再讨论性能 结论。本文使用同一个本地 OpenAI-compatible Stub、5 次预热、100 次正式操作， 测试并发度 1、8、32。

更多内容见 HNO 博客，也可以订阅 RSS。

为什么是 Go，为什么是 HNO ​

为什么使用 Go？ Go 是实现选择，工程原因包括编译后的部署产物、内置 并发模型、静态类型、标准 HTTP/JSON 库，以及一流的测试和性能分析工具。 这些是设计理由，不代表任何工作负载都固定快多少。

为什么叫 HNO？ HNO 是当前项目名称。仓库没有定义这个名称的正式全称， 所以本站不擅自编造。Go module 路径仍然是 github.com/rexleimo/agno-go； HNO 是项目身份，不是标准化模型、协议或性能指标。

证据规则： 实测结果附命令、版本、环境、平均值、中位数和范围。Go 的分配 字节不能当作 Python 内存。真实 LLM、生产容量和跨框架结论需要相同 Provider、 相同工作负载的独立实验。