docs(Eino): change eino docs link of en (#1283)

Author: kuhahalong

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

@@ -9,18 +9,18 @@ weight: 3
 
 The core modules in Eino include the following parts:
 
-- **Components**: [Eino: Components](/en/docs/eino/core_modules/components)
+- **Components**: [Eino: Components](/docs/eino/core_modules/components)
 
 Eino abstracts commonly used components in LLM applications, such as `ChatModel`, `Embedding`, `Retriever`, etc. These are the building blocks for constructing an LLM application, forming the foundation of application capabilities and serving as atomic objects for complex logic orchestration.
 
-- **Chain/Graph Orchestration**: [Eino: Chain & Graph Orchestration](/en/docs/eino/core_modules/chain_and_graph_orchestration)
+- **Chain/Graph Orchestration**: [Eino: Chain & Graph Orchestration](/docs/eino/core_modules/chain_and_graph_orchestration)
 
 Using multiple components in combination to implement the chain of business logic, Eino provides orchestration methods through Chains/Graphs, encapsulating the complexity of linking business logic within Eino itself. It offers easy-to-understand business logic orchestration interfaces and provides a unified cross-sectional governance capability.
 
-- **Flow Integration Tools (Agents)**: [Eino: Flow integration components](/en/docs/eino/core_modules/flow_integration_components)
+- **Flow Integration Tools (Agents)**: [Eino: Flow integration components](/docs/eino/core_modules/flow_integration_components)
 
 Eino packages the most commonly used LLM application modes into simple and easy-to-use tools, ultra-simplifying the development of LLM applications for generic scenarios. Currently, it provides `ReAct Agent` and `Host Multi Agent`.
 
-- **EinoDev Development Assistant Tool**: [EinoDev: Devops tools](/en/docs/eino/core_modules/devops)
+- **EinoDev Development Assistant Tool**: [EinoDev: Devops tools](/docs/eino/core_modules/devops)
 
 Eino is dedicated to making the development of large-scale model applications with full-code very simple, and EinoDev provides a `visual` and `interactive` development and debugging solution for Eino orchestration, which allows developers to see the results immediately, releasing their energy from the `debugging hell` and focusing on the scene logic.

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

@@ -14,7 +14,7 @@ In LLM applications, `Components` are the smallest units that provide "atomic ca
 - `Retriever` provides relevant content retrieval capabilities
 - `ToolsNode` provides the capability to execute external tools
 
-> For detailed information on components, refer to: [Eino: Components](/en/docs/eino/core_modules/components)
+> For detailed information on components, refer to: [Eino: Components](/docs/eino/core_modules/components)
 
 An LLM application, in addition to needing these atomic capabilities, also needs to **combine and sequence** these atomic capabilities based on contextual business logic. This is called **Orchestration**.
 
@@ -39,16 +39,16 @@ Therefore, Eino provides a solution for "orchestration based on the Graph model
 Specifically, the following features are implemented:
 
 - Everything is centered around "components," standardizing the encapsulation of business functionalities, making **division of responsibilities clear** and **reuse** natural.
-  - For more details, refer to: [Eino: Components](/en/docs/eino/core_modules/components)
+  - For more details, refer to: [Eino: Components](/docs/eino/core_modules/components)
 - The complexity of business logic is encapsulated within the components, giving the orchestration layer a more global perspective, making **logic layers very clear**.
 - Provides aspect capabilities and a callback mechanism that supports node-based **unified governance capabilities**.
-  - For more details, refer to: [Eino: Callback Manual](/en/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual)
+  - For more details, refer to: [Eino: Callback Manual](/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual)
 - Provides a call option mechanism, **extensibility** is the most fundamental requirement of the system in rapid iterations.
-  - For more details, refer to: [Eino: CallOption capabilities and specification](/en/docs/eino/core_modules/chain_and_graph_orchestration/call_option_capabilities)
+  - For more details, refer to: [Eino: CallOption capabilities and specification](/docs/eino/core_modules/chain_and_graph_orchestration/call_option_capabilities)
 - Provides an enhanced "type alignment" development method, reducing the mental burden on developers and leveraging Golang's **type safety** features.
-  - For more details, refer to: [Eino: The design concept of orchestration](/en/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles)
+  - For more details, refer to: [Eino: The design concept of orchestration](/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles)
 - Provides an **"automated stream conversion"** capability, removing "stream" from the "source of complexity ranking" in the orchestration system.
-  - For more details, refer to: [Eino Points of Streaming Orchestration](/en/docs/eino/core_modules/chain_and_graph_orchestration/stream_programming_essentials)
+  - For more details, refer to: [Eino Points of Streaming Orchestration](/docs/eino/core_modules/chain_and_graph_orchestration/stream_programming_essentials)
 
 Graph itself is powerful and semantically complete, capable of rendering almost any "data flow network," such as "branching," "parallel," and "loop."
 

content/en/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual.md

@@ -21,7 +21,7 @@ The core concepts interconnected within Eino include entities such as Components
 
 ### **Trigger Entities**
 
-Component (including types defined officially and Lambda), Graph Node (as well as Chain Node), and the Graph itself (including Chain). These three types of entities require cross-cutting functionality injection and intermediate state exposure, thus they all trigger callbacks. See the section on “[Trigger Methods](/en/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual)” below for details.
+Component (including types defined officially and Lambda), Graph Node (as well as Chain Node), and the Graph itself (including Chain). These three types of entities require cross-cutting functionality injection and intermediate state exposure, thus they all trigger callbacks. See the section on “[Trigger Methods](/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual)” below for details.
 
 ### **Trigger Timings**
 
@@ -38,7 +38,7 @@ const (
 )
 ```
 
-Different trigger entities, in various scenarios, determine whether to trigger OnStart or OnStartWithStreamInput (similarly, OnEnd/OnEndWithStreamOutput). Specific rules are detailed in the section on “[Trigger Methods](/en/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual)” below.
+Different trigger entities, in various scenarios, determine whether to trigger OnStart or OnStartWithStreamInput (similarly, OnEnd/OnEndWithStreamOutput). Specific rules are detailed in the section on “[Trigger Methods](/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual)” below.
 
 ### **Callback Handler**
 
@@ -62,7 +62,7 @@ A Handler is a struct that implements the 5 methods above (corresponding to the
 
 Each method also returns a new context: used for **passing information between different trigger timings** of the same Handler.
 
-If a Handler does not want to focus on all 5 trigger timings but only a subset, for example, just OnStart, it is recommended to use `NewHandlerBuilder().OnStartFn(...).Build()`. If it only wants to focus on specific components, such as ChatModel, it is recommended to use `NewHandlerHelper().ChatModel(...).Handler()`, which receives callbacks from only ChatModel and obtains a specific type of CallbackInput/CallbackOutput. See the section on “[Handler Implementation Methods](/en/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual)” for details.
+If a Handler does not want to focus on all 5 trigger timings but only a subset, for example, just OnStart, it is recommended to use `NewHandlerBuilder().OnStartFn(...).Build()`. If it only wants to focus on specific components, such as ChatModel, it is recommended to use `NewHandlerHelper().ChatModel(...).Handler()`, which receives callbacks from only ChatModel and obtains a specific type of CallbackInput/CallbackOutput. See the section on “[Handler Implementation Methods](/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual)” for details.
 
 The order of triggering between different Handlers is **not** guaranteed.
 
@@ -287,11 +287,11 @@ When the Graph is running, each component will operate in either Invoke or Trans
 
 **Which specific trigger points a Graph Node executes (OnStart or OnStartWithStreamInput) depends on the component's business streaming paradigm and the Graph running mode.**
 
-For a detailed introduction to Eino's streaming programming, refer to [Eino Points of Streaming Orchestration](/en/docs/eino/core_modules/chain_and_graph_orchestration/stream_programming_essentials).
+For a detailed introduction to Eino's streaming programming, refer to [Eino Points of Streaming Orchestration](/docs/eino/core_modules/chain_and_graph_orchestration/stream_programming_essentials).
 
 ### **Graph Self Trigger (Graph Callback)**
 
-The Graph triggers the Callback Handler at its own start, end, and error moments. If the Graph is called in Invoke form, it triggers OnStart/OnEnd/OnError. If called in Stream/Collect/Transform form, it triggers OnStartWithStreamInput/OnEndWithStreamOutput/OnError. This is because **the Graph will always execute internally in Invoke or Transform**. See [Eino Points of Streaming Orchestration](/en/docs/eino/core_modules/chain_and_graph_orchestration/stream_programming_essentials)
+The Graph triggers the Callback Handler at its own start, end, and error moments. If the Graph is called in Invoke form, it triggers OnStart/OnEnd/OnError. If called in Stream/Collect/Transform form, it triggers OnStartWithStreamInput/OnEndWithStreamOutput/OnError. This is because **the Graph will always execute internally in Invoke or Transform**. See [Eino Points of Streaming Orchestration](/docs/eino/core_modules/chain_and_graph_orchestration/stream_programming_essentials)
 
 It is worth noting that a graph is also a kind of component, so a graph callback is also a special form of component callback. According to the definition of Node Callback, when the component inside the Node implements the perception and processing of the trigger moments, the Node will directly reuse the Component's implementation and will not implement the Node Callback again. This means when a graph is added to another Graph as a Node through the AddGraphNode method, this Node will reuse the internal graph's graph callback.
 

content/en/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles.md

@@ -50,7 +50,7 @@ The green part in the figure represents the ordinary edge connection, which requ
 
 ② The downstream accepts an interface, and the upstream implements that interface: For example, the upstream structure implements the Format() interface, and the downstream accepts an interface{ Format() }. A special situation is when the downstream is any (empty interface), the upstream definitely implements any, so they can certainly connect.
 
-③ The upstream is an interface, and the downstream is a specific type: When the downstream specific type implements the upstream's interface type, it may or may not work, which cannot be determined at compile time, only at runtime when the explicit type of upstream is determined. For detailed description, see: [Eino: The design concept of orchestration](/en/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles)
+③ The upstream is an interface, and the downstream is a specific type: When the downstream specific type implements the upstream's interface type, it may or may not work, which cannot be determined at compile time, only at runtime when the explicit type of upstream is determined. For detailed description, see: [Eino: The design concept of orchestration](/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles)
 
 The yellow part in the figure represents another type conversion mechanism provided by eino, that is: if downstream receives a type `map[string]any`, but the upstream output type is not map[string]any, you can use `graph.AddXXXNode(node_key, xxx, compose.WithOutputKey("outkey")` to convert the upstream output type to map[string]any, where the key of the map is the OutputKey specified in the option. This mechanism is generally convenient to use when multiple edges converge to a single node.
 
@@ -174,7 +174,7 @@ In Eino, the result of orchestration is either a graph or a chain. To execute it
 
 One important function of Runnable is to provide four calling methods: "Invoke", "Stream", "Collect", and "Transform".
 
-> You can check the introduction of the above calling methods and detailed runnable introduction in: [Eino: Overview](/en/docs/eino/overview)
+> You can check the introduction of the above calling methods and detailed runnable introduction in: [Eino: Overview](/docs/eino/overview)
 
 Suppose we have a `Graph[[]*schema.Message, []*schema.Message]`, which contains a ChatModel node and a Lambda node. After compiling, it becomes a `Runnable[[]*schema.Message, []*schema.Message]`.
 
@@ -272,7 +272,7 @@ func Init() {
 
 ### **Runtime Type Alignment Check Scenarios**
 
-Eino's Graph type alignment check will verify if the types of the two nodes match during `err = graph.AddEdge("node1", "node2")`. This allows for type mismatch errors to be identified either during the `graph construction process` or the `Compile process`, adhering to rules ①②③ as listed in [Eino: The design concept of orchestration](/en/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles).
+Eino's Graph type alignment check will verify if the types of the two nodes match during `err = graph.AddEdge("node1", "node2")`. This allows for type mismatch errors to be identified either during the `graph construction process` or the `Compile process`, adhering to rules ①②③ as listed in [Eino: The design concept of orchestration](/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles).
 
 When the upstream node's output is an `interface`, and the downstream node type implements that `interface`, it is likely that upstream can be converted to downstream type (type assertion). However, whether the conversion succeeds can only be determined during the `runtime process`, so type checks in this scenario are deferred to runtime.
 
@@ -315,7 +315,7 @@ When running a Graph via Invoke, all internal nodes operate in Invoke mode. When
 
 Finally, Eino requires all orchestration elements to be aware of and capable of handling streams. This includes branches, state handlers, callback handlers, passthroughs, lambdas, etc.
 
-For more details on Eino's streaming capabilities, refer to [Eino Points of Streaming Orchestration](/en/docs/eino/core_modules/chain_and_graph_orchestration/stream_programming_essentials).
+For more details on Eino's streaming capabilities, refer to [Eino Points of Streaming Orchestration](/docs/eino/core_modules/chain_and_graph_orchestration/stream_programming_essentials).
 
 ### **Global State**
 
@@ -345,7 +345,7 @@ In either case, RunInfo will be automatically inferred.
 
 Additionally, for the Graph as a whole, Callback aspects will always be injected, with RunInfo being the Graph itself.
 
-For a complete explanation of Eino's Callback capabilities, see [Eino: Callback Manual](/en/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual).
+For a complete explanation of Eino's Callback capabilities, see [Eino: Callback Manual](/docs/eino/core_modules/chain_and_graph_orchestration/callback_manual).
 
 ### **Option Allocation**
 
@@ -356,7 +356,7 @@ Eino supports various dimensions of Call Option allocation methods:
 - Any specific nodes can be designated using `DesignateNode(key ...string)`.
 - Any depth of nested graphs, or any specific nodes within them, can be designated using `DesignateNodeWithPath(path ...*NodePath)`.
 
-For a complete explanation of Eino's Call Option capabilities, see [Eino: CallOption capabilities and specification](/en/docs/eino/core_modules/chain_and_graph_orchestration/call_option_capabilities).
+For a complete explanation of Eino's Call Option capabilities, see [Eino: CallOption capabilities and specification](/docs/eino/core_modules/chain_and_graph_orchestration/call_option_capabilities).
 
 ### **Graph Nesting**
 

content/en/docs/eino/core_modules/chain_and_graph_orchestration/stream_programming_essentials.md

@@ -8,7 +8,7 @@ weight: 0
 ---
 
 > 💡
-> It is recommended to read: [Eino: Overview](/en/docs/eino/overview) [Eino: The design concept of orchestration](/en/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles)
+> It is recommended to read: [Eino: Overview](/docs/eino/overview) [Eino: The design concept of orchestration](/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles)
 
 ## **Overview of Streaming Orchestration**
 
@@ -78,7 +78,7 @@ type Retriever interface {
 <tr><td>Tool</td><td>yes</td><td>yes</td><td>no</td><td>no</td></tr>
 </table>
 
-In the official Eino components, except for the Chat Model and Tool that additionally support the stream, all other components only support Invoke. For specific component introductions, refer to: [Eino: Components](/en/docs/eino/core_modules/components)
+In the official Eino components, except for the Chat Model and Tool that additionally support the stream, all other components only support Invoke. For specific component introductions, refer to: [Eino: Components](/docs/eino/core_modules/components)
 
 The streaming paradigms Collect and Transform are currently only used in orchestration scenarios.
 
@@ -101,7 +101,7 @@ In the diagram above, if the Tool is a StreamableTool, i.e., the output is Strea
 The Concat message stream above is a capability automatically provided by the Eino framework. Even if it's not a message and is arbitrary T, as long as certain conditions are met, the Eino framework will automatically convert StreamReader[T] to T. These conditions are: **In orchestration, when the upstream output of a component is StreamReader[T], but the component only provides T as the input business interface, the framework will automatically concatenate StreamReader[T] into T before inputting it to this component.**
 
 > 💡
-> The process of concatenating StreamReader[T] into T by the framework may require the user to provide a Concat function. Refer to the chapter on "**Fan-In and Merging**" in [Eino: The design concept of orchestration](/en/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles).
+> The process of concatenating StreamReader[T] into T by the framework may require the user to provide a Concat function. Refer to the chapter on "**Fan-In and Merging**" in [Eino: The design concept of orchestration](/docs/eino/core_modules/chain_and_graph_orchestration/orchestration_design_principles).
 
 On the other hand, consider an opposite example. Again, let's look at a more complete orchestration diagram of the React Agent: