434 lines
17 KiB
Markdown
434 lines
17 KiB
Markdown
---
|
||
tags: ["Eino", "Agent", "Middleware", "DeepAgent", "错误处理", "重试"]
|
||
create time: "2026-04-29 16:00"
|
||
---
|
||
|
||
# 第五章：Middleware（中间件模式）
|
||
|
||
## 概述
|
||
|
||
第四章为 Agent 加入了 Tool 能力后，Agent 已经可以「看见」和「触碰」真实世界了。但现实中的 API 会限流、文件会不存在、网络会超时——**直接暴露的错误会让 Agent 流程中断**。本章通过 Middleware 模式引入拦截器机制，让 Agent 具备错误自愈和自动重试的能力。
|
||
|
||
## 为什么需要 Middleware
|
||
|
||
第四章结束时，Tool 报错或 ChatModel 报错会直接中断整个对话流程：
|
||
|
||
```
|
||
[tool call] read_file(file_path: "nonexistent.txt")
|
||
Error: open nonexistent.txt: no such file or directory
|
||
// 💥 对话中断，用户需要重新开始
|
||
```
|
||
|
||
这类错误很常见：
|
||
|
||
| 场景 | 错误类型 | 常见原因 |
|
||
|------|---------|---------|
|
||
| **Tool 报错** | 业务错误 | 文件不存在、参数错误、权限不足 |
|
||
| **ChatModel 报错** | 临时错误 | API 限流(429)、网络超时、服务不可用 |
|
||
|
||
> [!tip] 关键洞察
|
||
>
|
||
> 这些错误**不应该终止 Agent 流程**。更好的做法是把错误信息交给模型，让它自动调整策略继续执行：
|
||
>
|
||
> ```
|
||
> [tool call] read_file(file_path: "nonexistent.txt")
|
||
> [tool result] [tool error] open nonexistent.txt: no such file or directory
|
||
> [assistant] 抱歉，文件不存在。让我先列出当前目录的文件...
|
||
> [tool call] glob(pattern: "*")
|
||
> // ✅ 对话继续，模型自行纠错
|
||
> ```
|
||
|
||
> [!question] 深入思考
|
||
>
|
||
> 既然可以直接把错误返回给模型，为什么不直接在每个 Tool 内部写 `if err != nil` 判断？
|
||
> 提示：考虑开闭原则（OCP）——如果明天要加 10 个新 Tool，是不是每个都要改一遍？**Middleware 的本质是将横切关注点从业务代码中剥离**，这也是 AOP（面向切面编程）的核心思想。
|
||
|
||
## 什么是 Middleware
|
||
|
||
**Middleware 是 Agent 的拦截器**，可以在调用前后插入自定义逻辑：
|
||
|
||
- **拦截调用**：在 Tool 或 ChatModel 执行前/后包装自定义行为
|
||
- **错误转换**：将错误转为模型可理解的字符串，而非中断流程
|
||
- **自动重试**：对临时错误（如限流）实现指数退避重试
|
||
- **可组合**：多个 Middleware 串联形成责任链
|
||
|
||
**简单类比：**
|
||
|
||
- **Agent** = "业务逻辑"
|
||
- **Middleware** = "AOP 切面"（日志、重试、错误处理等横切关注点）
|
||
|
||
> [!note] 装饰器模式
|
||
>
|
||
> Middleware 的本质是**装饰器模式**（Decorator Pattern）——每个 Middleware 包装原始调用，可以修改输入、输出或错误，而不改变被包装对象的接口。
|
||
|
||
## 核心概念
|
||
|
||
### Middleware 接口
|
||
|
||
`ChatModelAgentMiddleware` 是 Agent 中间件的统一接口：
|
||
|
||
```go
|
||
type ChatModelAgentMiddleware interface {
|
||
BeforeAgent(ctx context.Context, runCtx *ChatModelAgentContext) (context.Context, *ChatModelAgentContext, error)
|
||
BeforeModelRewriteState(ctx context.Context, state *ChatModelAgentState, mc *ModelContext) (context.Context, *ChatModelAgentState, error)
|
||
AfterModelRewriteState(ctx context.Context, state *ChatModelAgentState, mc *ModelContext) (context.Context, *ChatModelAgentState, error)
|
||
WrapInvokableToolCall(ctx context.Context, endpoint InvokableToolCallEndpoint, tCtx *ToolContext) (InvokableToolCallEndpoint, error)
|
||
WrapStreamableToolCall(ctx context.Context, endpoint StreamableToolCallEndpoint, tCtx *ToolContext) (StreamableToolCallEndpoint, error)
|
||
WrapEnhancedInvokableToolCall(ctx context.Context, endpoint EnhancedInvokableToolCallEndpoint, tCtx *ToolContext) (EnhancedInvokableToolCallEndpoint, error)
|
||
WrapEnhancedStreamableToolCall(ctx context.Context, endpoint EnhancedStreamableToolCallEndpoint, tCtx *ToolContext) (EnhancedStreamableToolCallEndpoint, error)
|
||
WrapModel(ctx context.Context, m model.BaseChatModel, mc *ModelContext) (model.BaseChatModel, error)
|
||
}
|
||
```
|
||
|
||
**方法分组：**
|
||
|
||
| 分组 | 方法 | 作用时机 |
|
||
|------|------|---------|
|
||
| **Agent 生命周期** | `BeforeAgent` | 每次 Agent 运行前，可修改指令和工具配置 |
|
||
| **状态处理** | `BeforeModelRewriteState` / `AfterModelRewriteState` | 每次模型调用前后的状态变换 |
|
||
| **Tool 调用** | `WrapInvokableToolCall` / `WrapStreamableToolCall` | 包装同步/流式 Tool 的执行 |
|
||
| **模型调用** | `WrapModel` | 包装底层 ChatModel 的调用 |
|
||
|
||
### 洋葱模型：Middleware 执行顺序
|
||
|
||
Handlers 按**数组正序**包装，形成洋葱模型：
|
||
|
||
```go
|
||
Handlers: []adk.ChatModelAgentMiddleware{
|
||
&middlewareA{}, // 最外层：最先 Wrap，最后生效
|
||
&middlewareB{}, // 中间层
|
||
&middlewareC{}, // 最内层：最后 Wrap，最先生效
|
||
}
|
||
```
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph Request ["📥 请求方向 →"]
|
||
A["Middleware A\n(最外层)"] --> B["Middleware B\n(中间层)"]
|
||
B --> C["Middleware C\n(最内层)"]
|
||
C --> T["实际 Tool/Model\n执行"]
|
||
end
|
||
|
||
subgraph Response ["📤 响应方向 ←"]
|
||
T --> CR["Middleware C\n返回"]
|
||
CR --> CB["Middleware B\n返回"]
|
||
CB --> CA["Middleware A\n返回"]
|
||
end
|
||
|
||
style A fill:#fce4ec
|
||
style B fill:#e8f5e9
|
||
style C fill:#e3f2fd
|
||
style T fill:#fff3e0
|
||
```
|
||
|
||
> [!warning] 实用建议
|
||
>
|
||
> 将 `safeToolMiddleware`（错误捕获）放在最内层（数组末尾），确保其他 Middleware 抛出的中断错误能正确向外传播，不被吞掉。
|
||
|
||
### 深入：为什么安全中间件要放在最内层？
|
||
|
||
很多开发者会问：**为什么不在最外层放一个全局的 `RecoverMiddleware` 来兜底？** 要理解这一点，需要区分三种不同的错误处理方式：
|
||
|
||
| 方式 | 捕获目标 | 处理策略 | 放置位置 |
|
||
|------|---------|---------|---------|
|
||
| **安全转换** (`safeToolMiddleware`) | 业务错误（文件不存在、参数错误） | 转为字符串喂给模型，让 Agent 自愈 | **最内层**（工具调用前） |
|
||
| **中断传播** | `InterruptRerunError` 等控制信号 | 不做任何转换，原样向上抛出 | 贯穿所有层 |
|
||
| **系统兜底** (`defer recover()`) | `panic`（nil pointer、数组越界） | 记录日志，保护进程不崩溃 | **入口层**（如 `main()` / `http.Server`） |
|
||
|
||
```go
|
||
// ❶ 最内层：业务错误转换 —— 模型可以继续执行
|
||
func (m *safeToolMiddleware) WrapInvokableToolCall(...) (...) {
|
||
return func(ctx context.Context, args string, opts ...tool.Option) (string, error) {
|
||
result, err := endpoint(ctx, args, opts...)
|
||
if err != nil {
|
||
if _, ok := compose.IsInterruptRerunError(err); ok {
|
||
return "", err // ⚠️ 中断错误必须穿透所有中间件
|
||
}
|
||
return fmt.Sprintf("[tool error] %v", err), nil // ✅ 业务错误转字符串
|
||
}
|
||
return result, nil
|
||
}
|
||
}
|
||
|
||
// ❷ 入口处：panic 兜底 —— 保护进程
|
||
func main() {
|
||
defer func() {
|
||
if r := recover(); r != nil {
|
||
log.Printf("recovered from panic: %v", r)
|
||
}
|
||
}()
|
||
// ... 启动 Agent 服务
|
||
}
|
||
```
|
||
|
||
> [!question] 进阶思考
|
||
>
|
||
> 如果把 `safeToolMiddleware` 移到最外层（数组首位），会发生什么？
|
||
>
|
||
> <details>
|
||
> <summary>🔍 点击查看推导</summary>
|
||
>
|
||
> 考虑这个场景：用户在 Agent 多轮对话中点击了"停止"按钮，底层产生了一个 `InterruptRerunError`。
|
||
>
|
||
> 1. Tool 执行器检测到中断信号，抛出 `InterruptRerunError`
|
||
> 2. 如果 `safeToolMiddleware` 在外层——此时请求还在外层尚未进入内层，**中断信号在内层往外冒泡时会首先经过内层中间件**
|
||
> 3. 因为中断信号是在最内层的 Tool 处产生的，无论 `safeToolMiddleware` 在哪一层，只要它检查了 `IsInterruptRerunError` 就不会吞掉它
|
||
> 4. 但真正的问题是：如果内层的其他逻辑（非中断）也出错，外层中间件还没来得及处理就被内层的错误"跳过"了
|
||
>
|
||
> 更准确地说，顺序的关键在于：**中间件是按装饰器模式嵌套的，外层包裹内层，内层最先执行也最先返回**。内层先做错误分类，外层再做全局处理，这样既保证了中断信号的畅通，又保证了业务错误的收敛。
|
||
> </details>
|
||
|
||
### ModelRetryConfig：内置重试配置
|
||
|
||
`ModelRetryConfig` 提供了 ChatModel 级别的自动重试能力：
|
||
|
||
```go
|
||
type ModelRetryConfig struct {
|
||
MaxRetries int // 最大重试次数
|
||
IsRetryAble func(ctx context.Context, err error) bool // 哪些错误可重试
|
||
}
|
||
```
|
||
|
||
**重试策略：**
|
||
|
||
| 策略 | 说明 |
|
||
|------|------|
|
||
| **指数退避** | 每次重试间隔递增，避免频繁请求加剧限流 |
|
||
| **条件过滤** | 通过 `IsRetryAble` 精确控制哪些错误值得重试 |
|
||
| **自动恢复** | 无需用户干预，模型调用失败后自动重试 |
|
||
|
||
## 实现细节
|
||
|
||
### SafeToolMiddleware：错误转换
|
||
|
||
`SafeToolMiddleware` 捕获 Tool 执行时的错误，将其转换为字符串返回给模型而非中断流程：
|
||
|
||
```go
|
||
type safeToolMiddleware struct {
|
||
*adk.BaseChatModelAgentMiddleware
|
||
}
|
||
|
||
func (m *safeToolMiddleware) WrapInvokableToolCall(
|
||
_ context.Context,
|
||
endpoint adk.InvokableToolCallEndpoint,
|
||
_ *adk.ToolContext,
|
||
) (adk.InvokableToolCallEndpoint, error) {
|
||
return func(ctx context.Context, args string, opts ...tool.Option) (string, error) {
|
||
result, err := endpoint(ctx, args, opts...)
|
||
if err != nil {
|
||
// ❗ 中断错误不转换，需要继续向外传播
|
||
if _, ok := compose.IsInterruptRerunError(err); ok {
|
||
return "", err
|
||
}
|
||
// ✅ 普通错误转为字符串，交给模型处理
|
||
return fmt.Sprintf("[tool error] %v", err), nil
|
||
}
|
||
return result, nil
|
||
}, nil
|
||
}
|
||
```
|
||
|
||
**设计要点：**
|
||
|
||
- **区分错误类型**：中断错误（如主动要求停止）必须传播，业务错误（如文件不存在）可以转换
|
||
- **不吞错**：只转换预期的业务错误，真正的系统异常仍向上抛出
|
||
- **格式化**：使用 `[tool error]` 前缀方便模型识别并回复时引用
|
||
|
||
流式 Tool 的错误处理同理，需将错误封装为单帧流：
|
||
|
||
```go
|
||
func (m *safeToolMiddleware) WrapStreamableToolCall(
|
||
_ context.Context,
|
||
endpoint adk.StreamableToolCallEndpoint,
|
||
_ *adk.ToolContext,
|
||
) (adk.StreamableToolCallEndpoint, error) {
|
||
return func(ctx context.Context, args string, opts ...tool.Option) (*schema.StreamReader[string], error) {
|
||
sr, err := endpoint(ctx, args, opts...)
|
||
if err != nil {
|
||
if _, ok := compose.IsInterruptRerunError(err); ok {
|
||
return nil, err
|
||
}
|
||
// 返回包含错误信息的单帧流
|
||
return singleChunkReader(fmt.Sprintf("[tool error] %v", err)), nil
|
||
}
|
||
return safeWrapReader(sr), nil
|
||
}, nil
|
||
}
|
||
```
|
||
|
||
### 注册 Middleware 与重试配置
|
||
|
||
将 Middleware 注入 DeepAgent 的配置中：
|
||
|
||
```go
|
||
agent, err := deep.New(ctx, &deep.Config{
|
||
Name: "Ch05MiddlewareAgent",
|
||
Description: "ChatWithDoc agent with safe tool middleware and retry.",
|
||
ChatModel: cm,
|
||
Instruction: agentInstruction,
|
||
Backend: backend,
|
||
StreamingShell: backend,
|
||
MaxIteration: 50,
|
||
|
||
// ⭐ 注册 Middleware
|
||
Handlers: []adk.ChatModelAgentMiddleware{
|
||
&safeToolMiddleware{}, // 将 Tool 错误转为字符串
|
||
},
|
||
|
||
// ⭐ 注册模型重试配置
|
||
ModelRetryConfig: &adk.ModelRetryConfig{
|
||
MaxRetries: 5,
|
||
IsRetryAble: func(_ context.Context, err error) bool {
|
||
return strings.Contains(err.Error(), "429") ||
|
||
strings.Contains(err.Error(), "Too Many Requests")
|
||
},
|
||
},
|
||
})
|
||
```
|
||
|
||
> [!note] Handlers vs Middlewares
|
||
>
|
||
> `Handlers` 字段（在 Config 中）和 "Middleware"（文档讨论的概念）是同一回事——`Handlers` 是配置字段名，而 `ChatModelAgentMiddleware` 是对接口的命名。
|
||
|
||
## 执行流程
|
||
|
||
结合 Middleware 后，一次 Tool 调用的完整生命周期如下：
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
U["用户：读取不存在的文件"] --> A{"Agent 分析意图"}
|
||
A -->|"决定调用 Tool"| M["SafeToolMiddleware\n拦截 Tool 调用"]
|
||
M --> T["执行 read_file\n返回错误"]
|
||
T --> E["SafeToolMiddleware\n捕获错误"]
|
||
E -->|"非中断错误"| S["转换为字符串\ntool error: no such file"]
|
||
E -->|"中断错误"| EP["向上抛出中断"]
|
||
S --> R["返回 Tool Result"]
|
||
R --> AG{"Agent 整合信息"}
|
||
AG -->|"生成解释性回复"| O["抱歉，文件不存在...\n尝试列出目录"]
|
||
AG -->|"需要更多信息"| A
|
||
|
||
style M fill:#e8f5e9
|
||
style E fill:#fff3e0
|
||
style S fill:#e3f2fd
|
||
style EP fill:#ffebee
|
||
```
|
||
|
||
> [!example] 逐步拆解
|
||
>
|
||
> **Step 1 — 用户输入**
|
||
> 用户请求读取一个不存在的文件。
|
||
>
|
||
> **Step 2 — 意图分析**
|
||
> Agent 判断需要文件系统操作，决定调用 `read_file` Tool。
|
||
>
|
||
> **Step 3 — Middleware 拦截**
|
||
> `SafeToolMiddleware.WrapInvokableToolCall` 在 Tool 执行前被触发，注册了自己的回调逻辑。
|
||
>
|
||
> **Step 4 — Tool 执行**
|
||
> 实际文件读取操作失败，返回 `open nonexistent.txt: no such file` 错误。
|
||
>
|
||
> **Step 5 — 错误转换**
|
||
> Middleware 发现这不是中断错误，将其包装为 `[tool error] open nonexistent.txt: ...` 字符串。
|
||
>
|
||
> **Step 6 — Agent 自愈**
|
||
> Agent 收到带错误的 Tool Result，理解后回复用户并调整策略（如改用 `glob` 列出可用文件）。
|
||
|
||
## 扩展：Eino 内置 Middleware
|
||
|
||
Eino 生态还提供了以下开箱即用的中间件：
|
||
|
||
<table>
|
||
<tr><th>Middleware</th><th>功能说明</th></tr>
|
||
<tr><td><strong>reduction</strong></td><td>工具输出缩减——当工具返回过长时自动截断并存入文件系统，防止上下文溢出</td></tr>
|
||
<tr><td><strong>summarization</strong></td><td>对话历史摘要——Token 超阈值时自动生成摘要压缩历史，节省上下文空间</td></tr>
|
||
<tr><td><strong>skill</strong></td><td>技能加载——让 Agent 按需动态加载预定义的 SKILL.md 知识包</td></tr>
|
||
</table>
|
||
|
||
### 多 Middleware 组合示例
|
||
|
||
```go
|
||
import (
|
||
"github.com/cloudwego/eino/adk/middlewares/reduction"
|
||
"github.com/cloudwego/eino/adk/middlewares/summarization"
|
||
)
|
||
|
||
// 创建 reduction：管理工具输出长度
|
||
reductionMW, _ := reduction.New(ctx, &reduction.Config{
|
||
Backend: filesystemBackend,
|
||
MaxLengthForTrunc: 50000,
|
||
MaxTokensForClear: 30000,
|
||
})
|
||
|
||
// 创建 summarization：自动压缩对话历史
|
||
summarizationMW, _ := summarization.New(ctx, &summarization.Config{
|
||
Model: chatModel,
|
||
Trigger: &summarization.TriggerCondition{
|
||
ContextTokens: 190000,
|
||
},
|
||
})
|
||
|
||
// 组合使用
|
||
agent, _ := adk.NewChatModelAgent(ctx, &adk.ChatModelAgentConfig{
|
||
Handlers: []adk.ChatModelAgentMiddleware{
|
||
summarizationMW, // 外层：对话历史摘要
|
||
reductionMW, // 内层：工具输出缩减
|
||
},
|
||
})
|
||
```
|
||
|
||
> [!question] 扩展思考
|
||
>
|
||
> 在这个例子中，`summarizationMW` 在外层、`reductionMW` 在内层。如果把顺序反过来，会有什么影响？试着根据洋葱模型的执行顺序推导一下。
|
||
|
||
## 代码位置
|
||
|
||
- 入口代码：[cmd/ch05/main.go](https://github.com/cloudwego/eino-examples/blob/main/quickstart/chatwitheino/cmd/ch05/main.go)
|
||
|
||
## 前置条件
|
||
|
||
与第一章一致：需要配置一个可用的 ChatModel（OpenAI 或 Ark）。同时，需要与第四章一样设置 `PROJECT_ROOT`：
|
||
|
||
```bash
|
||
export PROJECT_ROOT=/path/to/eino # Eino 核心库根目录
|
||
```
|
||
|
||
## 运行
|
||
|
||
在 `examples/quickstart/chatwitheino` 目录下执行：
|
||
|
||
```bash
|
||
export PROJECT_ROOT=/path/to/your/project
|
||
go run ./cmd/ch05
|
||
```
|
||
|
||
**输出示例：**
|
||
|
||
```
|
||
you> 列出当前目录的文件
|
||
[assistant] 我来帮你列出文件...
|
||
[tool call] list_files(directory: ".")
|
||
|
||
you> 读取一个不存在的文件
|
||
[assistant] 尝试读取文件...
|
||
[tool call] read_file(file_path: "nonexistent.txt")
|
||
[tool result] [tool error] open nonexistent.txt: no such file or directory
|
||
[assistant] 抱歉，文件不存在...
|
||
```
|
||
|
||
## 本章小结
|
||
|
||
| 概念 | 一句话理解 |
|
||
|------|-----------|
|
||
| **Middleware** | Agent 的拦截器，在调用前后插入自定义逻辑 |
|
||
| **SafeToolMiddleware** | 将 Tool 错误转为字符串交给模型，而非中断流程 |
|
||
| **ModelRetryConfig** | 配置 ChatModel 的自动重试，处理限流等临时错误 |
|
||
| **洋葱模型** | 请求从外向内穿过 Middleware，响应从内向外返回 |
|
||
| **装饰器模式** | 每个 Middleware 包装原始调用，可修改输入、输出或错误 |
|
||
| **中断错误不转换** | 只有业务错误才转字符串，中断错误继续传播 |
|
||
|
||
## 关联笔记
|
||
|
||
- [[Eino/quick_start/_index]]
|
||
- [[Eino/quick_start/chapter_04_tool_and_filesystem]] — Tool 与文件系统访问（上一章）
|
||
- [[Eino/quick_start/chapter_06_callback_and_trace]] — Callback 与 Trace 可观测性（下一章）
|