cloudwego/eino: Go 原生的 AI 运行时分层

Eino 解决的核心痛点是：如何在 Go 宿主环境下，优雅地解耦模型、工具、检索与长任务治理。 它没有照搬 Python 社区的“全家桶”心智，而是遵循了 Go 的工程审美——先立组件边界，再谈流式组合。

1. 三层架构模型

不要把 Eino 看成一个大对象，它由三层清晰的受力面构成：

• 能力抽象层 (Components)：将模型（Model）、检索（Retriever）、工具（Tool）、索引（Indexer）抽象为标准接口。工程直觉：组件必须是无状态且高内聚的。如果你的 Model 组件还背着业务逻辑，那它就失去了“可替换”的价值。
• 编排组合层 (Compose/Flow)：通过 Chain 或 Graph 将组件串联成确定性路径。这一层解决的是“请求如何流动”，支持流式（Streaming）输出的天然透传。
• 运行时治理层 (Callback/Interrupt)：这是 Eino 的精华。Callback 不是简单的日志钩子，它是运行时的可观测性面；Interrupt 则是长任务中的决策中断点（如人工审批）。

2. 长任务的确定性回收

Go 服务最怕无法预测的 goroutine 挂起和资源泄漏。

• Checkpoint (检查点)：长周期任务（如分步解析 PDF）必须有状态持久化。Eino 提供了检查点机制，允许任务在崩溃或人工干预后，从最近的合法状态恢复执行。
• Cancel 传播：原生支持 context.Context。当 HTTP 请求取消时，信号能准确传导至底层的模型调用与 I/O 操作，守住资源红线。

3. 与 LangChain/LangGraph 的分野

• vs LangChain：LangChain 侧重于“预置原语的丰富度”，而 Eino 侧重于“宿主边界的清晰度”。在 Go 生产环境，你不需要 100 种 Prompt 模板，你更需要 1 个能稳住并发与错误的运行时。
• vs LangGraph：LangGraph 默认一切皆图。Eino 允许你从简单的 Compose 开始，只有在业务确实需要循环、重试或复杂状态机时，才平滑迁移到图编排。

4. 工程判断力点拨

• 警惕组件污染：如果你发现换一个 LLM Provider 需要改动 10 个文件，说明你的组件层塌陷了。
• Callback 优先：不要在业务逻辑里到处写打点代码。利用 Callback 机制，将 Trace、Metrics、审计逻辑统一剥离到治理面。
• 不要为了 Agent 而 Agent：大多数业务先需要的是“确定性的工作流（Workflow）”。只有当路径无法预测时，才引入具备自主决策能力的 Agent 运行时。

结论： Eino 是为 Go 后端工程师准备的 AI 武器库。它不承诺魔法，只承诺给你的 AI 逻辑立好规矩、留好后路、打好补丁。