feat: add eino cn docs (#1182)

Author: kuhahalong

_typos.toml

@@ -7,3 +7,4 @@ extend-exclude = ["*.json", "*.js", "static/*", "layouts/*", "assets/*", "i18n/*
 datas = "datas"
 mmaped = "mmaped"
 exten = "exten"
+invokable = "invokable"

content/zh/docs/eino/_index.md

@@ -0,0 +1,68 @@
+---
+Description: Eino 是基于 Golang 的 AI 应用开发框架
+date: "2025-01-07"
+lastmod: ""
+linktitle: Eino
+menu:
+    main:
+        parent: 文档
+        weight: 6
+tags: []
+title: Eino 用户手册
+weight: 6
+---
+
+> Eino 发音：美 / 'aino /，近似音: i know，有希望应用程序达到 "i know" 的愿景
+
+# Eino  是什么
+
+> 💡
+> Go AI 集成组件的研发框架。
+
+Eino 旨在提供 Golang 语言的 AI 应用开发框架。 Eino 参考了开源社区中诸多优秀的 AI 应用开发框架，例如 LangChain、LangGraph、LlamaIndex 等，提供了更符合 Golang 编程习惯的 AI 应用开发框架。
+
+Eino 提供了丰富的辅助 AI 应用开发的**原子组件**、**集成组件**、**组件编排**、**切面扩展**等能力，可以帮助开发者更加简单便捷地开发出架构清晰、易维护、高可用的 AI 应用。
+
+以 React Agent 为例：
+
+- 提供了 ChatModel、ToolNode、PromptTemplate 等常用组件，并且业务可定制、可扩展。
+- 可基于现有组件进行灵活编排，产生集成组件，在业务服务中使用。
+
+![](/img/eino/react_agent_graph.png)
+
+# Eino 组件
+
+> Eino 的其中一个目标是：搜集和完善 AI 应用场景下的组件体系，让业务可轻松找到一些通用的 AI 组件，方便业务的迭代。
+
+Eino 会围绕 AI 应用的场景，提供具有比较好的抽象的组件，并围绕该抽象提供一些常用的实现。
+
+- Eino 组件的抽象定义在：[eino/components](https://github.com/cloudwego/eino/tree/main/components)
+- Eino 组件的实现在：[eino-ext/components](https://github.com/cloudwego/eino-ext/tree/main/components)
+
+# Eino 应用场景
+
+得益于 Eino 轻量化和内场亲和属性，用户只需短短数行代码就能给你的存量微服务引入强力的大模型能力，让传统微服务进化出 AI 基因。
+
+可能大家听到【Graph 编排】这个词时，第一反应就是将整个应用接口的实现逻辑进行分段、分层的逻辑拆分，并将其转换成可编排的 Node。 这个过程中遇到的最大问题就是**长距离的上下文传递(跨 Node 节点的变量传递)**问题，无论是使用 Graph/Chain 的 State，还是使用 Options 透传，整个编排过程都极其复杂，远没有直接进行函数调用简单。
+
+基于当前的 Graph 编排能力，适合编排的场景具有如下几个特点：
+
+- 整体是围绕模型的语义处理相关能力。这里的语义不限模态
+- 编排产物中有极少数节点是 Session 相关的。整体来看，绝大部分节点没有类似用户/设备等不可枚举地业务实体粒度的处理逻辑
+
+  - 无论是通过 Graph/Chain 的 State、还是通过 CallOptions，对于读写或透传用户/设备粒度的信息的方式，均不简便
+- 需要公共的切面能力，基于此建设观测、限流、评测等横向治理能力
+
+编排的意义是什么： 把长距离的编排元素上下文以固定的范式进行聚合控制和呈现。
+
+**整体来说，“Graph 编排”适用的场景是： 业务定制的 AI 集成组件。  ****即把 AI 相关的原子能力，进行灵活编排****，提供简单易用的场景化的 AI 组件。 并且该 AI 组件中，具有统一且完整的横向治理能力。**
+
+- 推荐的使用方式
+
+![](/img/eino/recommend_way_of_handler.png)
+
+- 挑战较大的方式 -- 【业务全流程的节点编排】
+  - Biz Handler 一般重业务逻辑，轻数据流，比较适合函数栈调用的方式进行开发
+    - 如果采用图编排的方式进行逻辑划分与组合，会增大业务逻辑开发的难度
+
+![](/img/eino/big_challenge_graph.png)

content/zh/docs/eino/core_modules/_index.md

@@ -0,0 +1,19 @@
+---
+Description: ""
+date: "2025-01-06"
+lastmod: ""
+tags: []
+title: 'Eino: 核心模块'
+weight: 3
+---
+
+Eino 中的核心模块有如下几个部分：
+
+- **Components 组件**：[Eino: Components 组件](/zh/docs/eino/core_modules/components)
+  Eino 抽象出来的大模型应用中常用的组件，例如 `ChatModel`、`Embedding`、`Retriever` 等，这是实现一个大模型应用搭建的积木，是应用能力的基础，也是复杂逻辑编排时的原子对象。
+- **Chain/Graph 编排**：[Eino: Chain/Graph 编排功能](/zh/docs/eino/core_modules/chain_and_graph_orchestration/chain_graph_introduction)
+  多个组件混合使用来实现业务逻辑的串联，Eino 提供 Chain/Graph 的编排方式，把业务逻辑串联的复杂度封装在了 Eino 内部，提供易于理解的业务逻辑编排接口，提供统一的横切面治理能力。
+- **Flow 集成工具 (agents)**: [Eino: Flow 集成组件](/zh/docs/eino/core_modules/flow_integration_components)
+  Eino 把最常用的大模型应用模式封装成简单、易用的工具，让通用场景的大模型应用开发极致简化，目前提供了 `React Agent` 和 `Host Multi Agent`。
+- **EinoDev 开发辅助工具**：[EinoDev: 应用开发工具链](/zh/docs/eino/core_modules/application_development_toolchain)
+  Eino 致力于让全码开发大模型应用变得非常简单，EinoDev 则为 Eino 编排提供了 `可视化`、`交互式` 的开发调试方案，所见即所得，让开发者的精力从 `调试地狱` 中释放出来，专注于场景逻辑。

content/zh/docs/eino/core_modules/application_development_toolchain/_index.md

@@ -0,0 +1,16 @@
+---
+Description: ""
+date: "2025-01-06"
+lastmod: ""
+tags: []
+title: 'EinoDev: 应用开发工具链'
+weight: 4
+---
+
+🚧 施工中，敬请期待。。。
+
+TODO：
+
+1. EinoDev 是什么?
+2. EinoDev 希望解决的问题是什么?
+3. EinoDev 的解决方案是什么?

content/zh/docs/eino/core_modules/chain_and_graph_orchestration/_index.md

@@ -0,0 +1,62 @@
+---
+Description: ""
+date: "2025-01-06"
+lastmod: ""
+tags: []
+title: 'Eino: Chain & Graph 编排功能'
+weight: 2
+---
+
+在大模型应用中，`Components` 组件 是提供 『原子能力』的最小单元，比如：
+
+- `ChatModel` 提供了大模型的对话能力
+- `Embedding` 提供了基于语义的文本向量化能力
+- `Retriever` 提供了关联内容召回的能力
+- `ToolsNode` 提供了执行外部工具的能力
+
+> 详细的组件介绍可以参考: [Eino: Components 组件](/zh/docs/eino/core_modules/components)
+
+一个大模型应用，除了需要这些原子能力之外，还需要根据场景化的业务逻辑，**对这些原子能力进行组合、串联**，这就是 **『编排』**。
+
+大模型应用的开发有其自身典型的特征： 自定义的业务逻辑本身不会很复杂，几乎主要都是对『原子能力』的组合串联。
+
+传统代码开发过程中，业务逻辑用 “代码的执行逻辑” 来表达，迁移到大模型应用开发中时，最直接想到的方法就是 “自行调用组件，自行把结果作为下一组件的输入进行调用”。这样的结果，就是 `代码杂乱`、`很难复用`、`没有切面能力`……
+
+当开发者们追求代码『**优雅**』和『**整洁之道**』时，就发现把传统代码组织方式用到大模型应用中时有着巨大的鸿沟。
+
+Eino 的初衷是让大模型应用开发变得非常简单，就一定要让应用的代码逻辑 “简单” “直观” “优雅” “健壮”。
+
+Eino 对「编排」有着这样的洞察：
+
+- 编排要成为在业务逻辑之上的清晰的一层，**不能让业务逻辑融入到编排中**。
+- 大模型应用的核心是 “对提供原子能力的组件” 进行组合串联，**组件是编排的 “第一公民”**。
+- 抽象视角看编排：编排是在构建一张网络，数据则在这个网络中流动，网络的每个节点都对流动的数据有格式/内容的要求，一个能顺畅流动的数据网络，关键就是 “**上下游节点间的数据格式是否对齐**？”。
+- 业务场景的复杂度会反映在编排产物的复杂性上，只有**横向的治理能力**才能让复杂场景不失控。
+- 大模型是会持续保持高速发展的，大模型应用也是，只有**具备扩展能力的应用才拥有生命力**。
+
+于是，Eino 提供了 “基于 Graph 模型 (node + edge) 的，以**组件**为原子节点的，以**上下游类型对齐**为基础的编排” 的解决方案。
+
+具体来说，实现了如下特性：
+
+- 一切以 “组件” 为核心，规范了业务功能的封装方式，让**职责划分变得清晰**，让**复用**变成自然而然
+
+  - 详细信息参考：[Eino: Components 组件](/zh/docs/eino/core_modules/components)
+- 业务逻辑复杂度封装到组件内部，编排层拥有更全局的视角，让**逻辑层次变得非常清晰**
+- 提供了切面能力，callback 机制支持了基于节点的**统一治理能力**
+
+  - 详细信息参考：[Eino: 公共切面 - Callbacks](/zh/docs/eino/core_modules/chain_and_graph_orchestration/callbacks_common_aspects)
+- 提供了 call option 的机制，**扩展性**是快速迭代中的系统最基本的诉求
+
+  - 详细信息参考：[Eino: CallOption 能力与规范](/zh/docs/eino/core_modules/chain_and_graph_orchestration/call_option_capabilities)
+- 提供了 “类型对齐” 的开发方式的强化，降低开发者心智负担，把 golang 的**类型安全**特性发挥出来
+
+  - 详细信息参考：[Eino: 编排的设计理念](/zh/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles)
+- 提供了 “**流的自动转换**” 能力，让 “流” 在「编排系统的复杂性来源榜」中除名
+
+  - 详细信息参考：[Eino 流式编程要点](/zh/docs/eino/core_modules/chain_and_graph_orchestration/stream_programming_essentials)
+
+Graph 本身是强大且语义完备的，可以用这项底层几乎绘制出所有的 “数据流动网络”，比如 “分支”、“并行”、“循环”。
+
+但 Graph 并不是没有缺点的，基于 “点” “边” 模型的 Graph 在使用时，要求开发者要使用 `graph.AddXXXNode()` 和 `graph.AddEdge()` 两个接口来创建一个数据通道，强大但是略显复杂。
+
+而在现实的大多数业务场景中，往往仅需要 “按顺序串联” 即可，因此，Eino 封装了接口更易于使用的 `Chain`。Chain 是对 Graph 的封装，除了 “环” 之外，Chain 暴露了几乎所有 Graph 的能力。