第10章巨人的肩膀，挑哪个站

前九章把Agent原理讲透了——脑子、手脚、记忆、规划、协作。现在你面前也摆了一堆选择：Eino、LangChainGo、用Go自己撸一个框架……该选哪个？这一章帮你理清楚，不踩坑。

10.1 Eino vs LangChainGo vs 自己撸：框架怎么选？

10.1.1 Go的AI框架现状

Python 生态百花齐放，Go 的 AI Agent 框架选择相对集中。目前主要有三条路：

方案	代表	定位
Eino	字节跳动开源	Go 原生 AI Agent 框架，功能最全
LangChainGo	LangChain 官方 Go 移植	概念对齐 Python 版，生态较弱
自己撸	手写 LLM 调用 + 工具管理	灵活但工作量大

10.1.2 Eino：Go 优先的Agent框架

Eino 由字节跳动开源，2024年发布。它的核心思路：

不翻译 Python 代码，用 Go 的方式重新设计 Agent 框架。

// Eino 的 Chain——Go 的方式
chain := compose.NewChain[[]*schema.Message, *schema.Message]().
    AppendChatModel(chatModel).      // 积木1：模型
    AppendTool(weatherTool).          // 积木2：工具
    AppendLambda(checkResult)         // 积木3：检查

runnable, _ := chain.Compile(ctx)
result, _ := runnable.Invoke(ctx, input)

对比 Python 的 LangChain：

python

chain = prompt | model | tool | StrOutputParser()
result = chain.invoke({"question": "北京天气"})

两者思想类似——都是"搭积木"。但区别在于：

	Eino	LangChainGo
API 风格	Go 原生（interface、泛型、context）	Python 翻译感
类型安全	编译期检查	运行时 + 类型断言
生态成熟度	字节内部验证，社区增长中	相对更早，但更新慢
中文支持	字节出品，豆包/DeepSeek 原生化	需自行适配
并发模型	goroutine 原生	goroutine + 回调

10.1.3 LangChainGo：熟悉但又陌生

LangChainGo 是 LangChain 官方的 Go 移植。如果你已经用过 Python 版 LangChain，概念是相通的——Chain、Tool、Memory、Agent。

但 LangChainGo 有几个问题：

更新滞后——Python 版每个月都有新功能，Go 版可能几个月才同步一次
代码风格不 Go——很多 API 是为了对齐 Python 版设计的，写起来不像 Go
社区较小——Go AI 开发者基数本身就比 Python 小，踩坑经验少

什么时候选 LangChainGo：你的团队同时维护 Python 和 Go 服务，需要跨语言共享 Agent 概念和配置文件。否则优先 Eino。

10.1.4 自己撸：什么时候该"造轮子"

不是所有场景都需要框架。以下情况可以考虑自己写：

Agent 逻辑非常简单（一个 LLM + 一个工具，不需要 Chain/Graph）
你的需求非常特殊，现有框架都要 hack 才能实现
你想深入理解 Agent 底层，写一遍比看文档管用

// 极简 Agent——自己写也就30行
func simpleAgent(question string) string {
    // 1. 调 LLM
    resp := callLLM(question)
    // 2. 如果需要工具
    if toolName := extractToolCall(resp); toolName != "" {
        result := callTool(toolName)
        // 3. 把结果喂回 LLM
        return callLLM(question + "\n工具结果：" + result)
    }
    return resp
}

但要清楚：自己撸省了框架学习成本，换来的是——记忆管理、工具调度、错误处理、流式输出……这些基础设施全部要你自己写。

10.2 Eino的设计哲学：Go优先，不是Python的翻译

10.2.1 不是"翻译"，是"重写"

很多跨语言框架的问题：他们把 Python 的 API 硬翻译成 Go，结果不伦不类。

Eino 的做法不同。举几个例子：

interface 代替鸭子类型

Python LangChain 靠 duck typing——"能调用就当我支持"。Go Eino 用显式 interface：

// Eino 的 Tool 接口——编译期保证实现正确
type InvokableTool interface {
    Info(ctx context.Context) (*schema.ToolInfo, error)
    InvokableRun(ctx context.Context, params any) (any, error)
}

// 编译期就知道 WeatherTool 有没有正确实现接口
var _ tool.InvokableTool = (*WeatherTool)(nil)

泛型代替运行时类型检查

// Python：运行时才知道 tool 的参数类型对不对
// Go Eino：编译期就确定了
chain := compose.NewChain[WeatherInput, WeatherOutput]().
    AppendChatModel(chatModel).
    AppendTool(weatherTool)
// 输入输出类型写死，传错了编译都过不了

context 代替全局状态

// Python LangChain 的 callback 有时靠全局变量或线程本地存储
// Go Eino 所有异步操作都通过 context 传递
func (t *WeatherTool) InvokableRun(ctx context.Context, 
    params any) (any, error) {
    // ctx 里可以拿 traceId、超时、取消信号
    select {
    case <-ctx.Done():
        return nil, ctx.Err()
    default:
        return queryWeather(params)
    }
}

10.2.2 Eino 和 Python 生态的对应关系

Python 组件	Eino 对应	差异
LangChain	Eino Chain + Components	Go 类型安全、编译检查
LangGraph	Eino Graph	goroutine 天然支持并行节点
LangSmith	Eino Callbacks	context 贯穿全链路
Pydantic	Go struct + JSON tag	编译期字段验证
asyncio	goroutine	真并行，不是单线程协程

可以理解为：Eino 想做的事和 LangChain/LangGraph 一样——让你用组件拼出 Agent。但 Eino 用 Go 的方式实现，不为了对齐 Python API 牺牲 Go 的特性。

10.3 Eino的生态定位与未来

10.3.1 目前Eino覆盖了什么

能力	状态	说明
ChatModel（LLM 调用）	✅ 成熟	支持 OpenAI / 豆包 / DeepSeek 等
Tool 系统	✅ 成熟	类型安全的工具定义和调用
Memory	✅ 可用	Buffer / Window / Summary 三种模式
Chain（链式编排）	✅ 成熟	积木式组件拼接
Graph（状态机编排）	✅ 可用	支持分支、循环、并行
ReAct Agent	✅ 成熟	内置思考-行动-观察循环
Callbacks（可观测性）	✅ 可用	埋点、日志、追踪
Streaming（流式输出）	✅ 可用	Stream() 逐步返回结果

10.3.2 本书的策略

全栈 Eino。 和 Python 版选择 LangChain + LangGraph 一样，Go 版全书围绕 Eino 展开：

第 4-10 章（你刚学完的）：Eino 的核心组件——ChatModel、Tool、Memory、Chain、Graph
第 11-15 章（接下来）：用 Eino 做并发、安全、MCP、生产部署
第 16-18 章（实战项目）：三个完整项目全部基于 Eino

不选 LangChainGo 的原因很简单：学一套就够了，Eino 更 Go、更快、字节验证过。

10.4 框架只是工具，思维才是核心

10.4.1 不要让框架定义你的Agent

不管是 Eino、LangChainGo 还是自己撸——框架只是帮你少写样板代码的工具。真正决定 Agent 质量的是：

你对任务的理解——Agent 该用什么工具，Prompt 怎么写，流程怎么设计
你对用户的了解——哪些操作要确认，哪些错误要兜底
你对边界的感知——Agent 不能做什么，什么时候该拒绝

框架换得了，思维换不了。这也是这本书花前九章讲原理、而不是一上来就贴框架代码的原因。

10.5 本章小结

这一章帮你理清了 Go AI 框架的选型：

Eino 是首选：字节开源、Go 原生、类型安全、全书主线。不是 Python 的翻译，是用 Go 的方式重写。
LangChainGo 看场景：如果你的团队跨 Python/Go 维护且要概念统一，可以用。否则优先 Eino。
自己撸看需求：极简场景可以手写。但要清楚你省了框架学习成本，换来的是基础设施全得自己造。
框架只是工具：Agent 质量不取决于框架选什么，取决于你对任务的理解、对用户的感知、对边界的把握。

✅ 知识点检查

学完这一章，试试回答这几个问题：

[ ] Eino和LangChainGo的核心区别是什么？为什么本书选Eino？
[ ] 什么场景适合自己撸框架，什么场景必须用框架？
[ ] Eino的"Go优先"设计哲学体现在哪三个方面？
[ ] 框架只是工具——那真正决定Agent质量的是什么？

📚 延伸阅读

Eino 官方文档：https://www.cloudwego.io/zh/docs/eino/
Eino GitHub：https://github.com/cloudwego/eino
LangChainGo GitHub：https://github.com/tmc/langchaingo
本书配套源码：关注公众号「图解AI系列」免费领取

🎯 下一章预告

第11章，进入进阶篇——

"Go 的并发，Agent 的加速器。一千个请求同时来，Python 在排队，Go 在飞。"

第10章 巨人的肩膀，挑哪个站 ​

10.1 Eino vs LangChainGo vs 自己撸：框架怎么选？ ​

10.1.1 Go的AI框架现状 ​

10.1.2 Eino：Go 优先的Agent框架 ​

10.1.3 LangChainGo：熟悉但又陌生 ​

10.1.4 自己撸：什么时候该"造轮子" ​

10.2 Eino的设计哲学：Go优先，不是Python的翻译 ​

10.2.1 不是"翻译"，是"重写" ​

10.2.2 Eino 和 Python 生态的对应关系 ​

10.3 Eino的生态定位与未来 ​

10.3.1 目前Eino覆盖了什么 ​

10.3.2 本书的策略 ​

10.4 框架只是工具，思维才是核心 ​

10.4.1 不要让框架定义你的Agent ​

10.5 本章小结 ​

✅ 知识点检查 ​

📚 延伸阅读 ​

🎯 下一章预告 ​

喜欢这篇内容？关注我，别错过后续更新