作为一名 Go 后端开发者，过去一年在 AI 应用开发上是非常憋屈的。眼看着 Python 社区的 LangChain、LlamaIndex 玩出花来，Go 生态却只有零散的
go-openai库。
直到字节跳动 CloudWeGo 团队开源了 Eino ，我试用了一周，感觉 Go 语言在 AI 工程化领域终于要翻身了。本文将从代码实战的角度，带你体验如何用 Eino + Hertz + Milvus 构建一个企业级的 AI Agent。
一、 什么是 Eino？解决了什么痛点？
在 Eino 出现之前，用 Go 写 AI 应用通常面临三个问题：
- 编排混乱 ：多轮对话、工具调用（Function Call）、状态流转全靠
if-else硬写，代码不可维护。 - 生态割裂：想接个向量库、想换个大模型，都需要自己造轮子。
- 调试困难：Agent 为什么死循环了？为什么没调工具？缺乏可视化的 Trace 手段。
Eino 的核心设计理念是 Graph（图编排）。它把 AI 应用抽象成一个图，节点（Node）是组件，边（Edge）是流转逻辑。
二、 环境准备
先初始化一个 Go 项目，安装核心依赖。 注意：Eino 目前迭代很快，建议使用最新版本。
bash
go get github.com/cloudwego/eino@latest
go get github.com/cloudwego/hertz@latest
go get github.com/milvus-io/milvus-sdk-go/v2三、 实战：构建一个"面试官 Agent"
我们不仅要聊天，还要让 Agent 具备阅读简历 和出题的能力。这是一个典型的 ReAct（Reasoning + Acting）场景。
3.1 定义工具（Tool）
首先，我们封装一个"简历解析工具"。Eino 对工具的定义非常标准，兼容 OpenAI 的 Function Call 格式。
go
// tool/resume.go
type ResumeParams struct {
Url string `json:"url" desc:"简历的下载链接"`
}
func GetResumeInfoTool() componenttool.BaseTool {
return &componenttool.Tool{
Name: "get_resume_info",
Desc: "解析候选人的简历 PDF，提取技术栈和项目经验",
Func: func(ctx context.Context, params *ResumeParams) (string, error) {
// 这里省略具体的 PDF 解析逻辑
// 真实项目中建议使用 OCR 或大模型提取
return "候选人熟悉 Go, Eino, Milvus, Redis...", nil
},
}
}3.2 编排 Agent（核心代码）
接下来，使用 Eino 的 NewChatModelAgent 来编排。 注意看 ToolsConfig 的配置，这里我们把刚才定义的工具挂载进去了。
go
// agent/interviewer.go
import (
"github.com/cloudwego/eino/adk"
"github.com/cloudwego/eino/compose"
)
func NewInterviewerAgent(ctx context.Context, model chat.Model) (adk.Agent, error) {
agent, err := adk.NewChatModelAgent(ctx, &adk.ChatModelAgentConfig{
Name: "TechInterviewer",
// System Prompt：人设注入
Instruction: `你是一个资深 Go 面试官。
1. 必须先调用 get_resume_info 工具读取简历。
2. 根据简历中的技术栈（如 Eino, Hertz）进行深度追问。
3. 不要问基础八股文，要问场景设计。`,
Model: model, // 底层大模型（DeepSeek/OpenAI）
// 挂载工具箱
ToolsConfig: adk.ToolsConfig{
ToolsNodeConfig: compose.ToolsNodeConfig{
Tools: []componenttool.BaseTool{
GetResumeInfoTool(),
},
},
},
// 关键：设置最大迭代轮数，防止 Agent 陷入死循环
MaxIterations: 15,
})
return agent, err
}代码解析 ： 这段代码虽然短，但它已经实现了一个完整的自主智能体。Eino 框架在底层自动处理了：
- User Query -> Model 思考
- Model 决定调工具 -> 解析参数 -> 执行 Tool
- Tool Result -> 回填给 Model -> Model 生成最终回答
四、 进阶：RAG 混合检索（Hybrid Search）
单纯的 Agent 容易产生幻觉。为了保证面试题的专业性，我们引入 Milvus 做知识库。 这里分享一个生产级 RAG 的关键点：混合检索。
很多教程只教你算 Vector Similarity（向量相似度），但在实际业务中，我们往往需要结合标量过滤（比如只搜"中级"难度的题）。
go
// retrieval/milvus.go
func (s *RetrieverService) Retrieve(ctx context.Context, query string) ([]*schema.Document, error) {
// 1. 动态构建 Filter (标量过滤)
// 实际场景中，这个 filter 可能来自前端传参，或者由 LLM 意图识别生成
expr := "category == 'Golang' && difficulty == 'Hard'"
// 2. 调用 Milvus SDK (向量检索)
// 注意：Eino 的接口设计允许我们透传这些 option
searchParam, _ := entity.NewIndexAUTOINDEXSearchParam(1)
docs, err := s.client.Search(ctx,
s.collection,
nil,
expr, // 核心：在这里传入标量过滤表达式
[]string{"content"},
queryVector,
milvus.NewTopKMetricType(milvus.L2, 5), // TopK
searchParam,
)
return s.convertToEinoDocs(docs), nil
}五、 性能压测：Go vs Python
为了验证 Go + Eino 的性能，我们做了一个简单的压测（QPS 100）。
- Python (LangChain): CPU 飙升到 200%，P99 延迟波动很大（受 GIL 影响）。
- Go (Eino): CPU 稳定在 30%，P99 延迟非常平滑。
结论 ：在 IO 密集型 的 AI Agent 场景下（大量的 HTTP 请求、数据库读写），Go 的协程机制简直是降维打击。
六、 总结与源码
试用下来，Eino 给我的感觉是：工业风、扎实。它没有 LangChain 那么多花里胡哨的概念，但每一个 API 的设计都非常贴合微服务开发的直觉。
如果你也是 Go 开发者，想转型 AI 工程化，强烈建议试一下 Eino。它可能是目前 Go 生态中唯一能打的 Agent 框架。
源码获取：
为了方便大家学习，我把这个 【面试吧】 项目（Go + Eino + Hertz + Milvus）整理了一个开源版本。 包含：
- 完整的 Eino Graph 编排代码
- Milvus 混合检索实现
- Redis 异步队列处理逻辑
👉 关注公众号【王中阳】，回复"面试吧"即可获取 GitHub 地址和详细文档。
也可以在评论区交流你在使用 Eino 时遇到的坑，知无不言！