Jido 2.0：基于 Elixir 的 Agent 框架

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

# 示例1：创建一个简单的 Jido Agent，实现任务调度功能
defmodule TaskScheduler do
  use Jido.Agent

  # 定义 Agent 的状态结构
  defstruct [:tasks, :current_task]

  # 初始化 Agent
  def init(opts) do
    # 从选项中获取初始任务列表，默认为空列表
    tasks = Keyword.get(opts, :tasks, [])
    {:ok, %__MODULE__{tasks: tasks, current_task: nil}}
  end

  # 添加新任务到调度器
  def handle_call({:add_task, task}, _from, state) do
    new_tasks = [task | state.tasks]
    {:reply, :ok, %{state | tasks: new_tasks}}
  end

  # 执行下一个任务
  def handle_call(:execute_next, _from, state) do
    case state.tasks do
      [next_task | remaining] ->
        # 模拟执行任务（这里只是打印）
        IO.puts("执行任务: #{next_task}")
        {:reply, {:ok, next_task}, %{state | tasks: remaining, current_task: next_task}}
      [] ->
        {:reply, {:error, :no_tasks}, state}
    end
  end
end

# 使用示例
{:ok, scheduler} = Jido.Agent.start_link(TaskScheduler, name: :task_scheduler)
Jido.Agent.call(:task_scheduler, {:add_task, "备份数据库"})
Jido.Agent.call(:task_scheduler, {:add_task, "发送日报"})
{:ok, task} = Jido.Agent.call(:task_scheduler, :execute_next)
IO.puts("当前执行的任务: #{task}")

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# 示例2：实现一个带有错误处理的 Agent
defmodule SafeCalculator do
  use Jido.Agent

  defstruct history: []

  def init(_opts) do
    {:ok, %__MODULE__{}}
  end

  # 安全除法操作，处理除零错误
  def handle_call({:divide, a, b}, _from, state) do
    try do
      result = a / b
      new_history = [{:divide, a, b, result} | state.history]
      {:reply, {:ok, result}, %{state | history: new_history}}
    rescue
      ArithmeticError ->
        {:reply, {:error, :division_by_zero}, state}
    end
  end

  # 获取计算历史
  def handle_call(:history, _from, state) do
    {:reply, state.history, state}
  end
end

# 使用示例
{:ok, calc} = Jido.Agent.start_link(SafeCalculator, name: :calculator)
case Jido.Agent.call(:calculator, {:divide, 10, 2}) do
  {:ok, result} -> IO.puts("10 / 2 = #{result}")
  {:error, reason} -> IO.puts("错误: #{reason}")
end

case Jido.Agent.call(:calculator, {:divide, 10, 0}) do
  {:ok, result} -> IO.puts("10 / 0 = #{result}")
  {:error, reason} -> IO.puts("错误: #{reason}")  # 会捕获除零错误
end

history = Jido.Agent.call(:calculator, :history)
IO.puts("计算历史: #{inspect(history)}")

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336

# 示例3：实现一个带有超时控制的 Agent
defmodule TimedWorker do
  use Jido.Agent

  defstruct [:job_timeout, current_job: nil]

  def init(opts) do
    job_timeout = Keyword.get(opts, :job_timeout, 5000)  # 默认5秒超时
    {:ok, %__MODULE__{job_timeout: job_timeout}}
  end

  # 执行带超时的工作任务
  def handle_call({:work, job}, _from, state) do
    task = Task.async(fn ->
      # 模拟耗时工作
      Process.sleep(3000)
      {:ok, "完成: #{job}"}
    end)

    try do
      result = Task.await(task, state.job_timeout)
      {:reply, result, %{state | current_job: job}}
    catch
      :exit, {:timeout, _} ->
        Task.shutdown(task, :brutal_kill)
        {:reply, {:error, :timeout}, state}
    end
  end

  # 获取当前任务状态
  def handle_call(:status, _from, state) do
    {:reply, state.current_job, state}
  end
end

# 使用示例
{:ok, worker} = Jido.Agent.start_link(TimedWorker, [job_timeout: 2000], name: :worker)

# 这个任务会在2秒后超时
case Jido.Agent.call(:worker, {:work, "长时间任务"}) do
  {:ok, msg} -> IO.puts(msg)
  {:error, :timeout} -> IO.puts("任务超时!")
end

# 这个任务会正常完成
case Jido.Agent.call(:worker, {:work, "快速任务"}) do
  {:ok, msg}


---
## 案例研究


### 1：Discord 机器人高并发消息处理平台

 1：Discord 机器人高并发消息处理平台

**背景**:
某大型游戏社区运营团队维护着一个拥有数百万用户的 Discord 机器人。该机器人负责处理用户验证、游戏状态查询、库存通知以及实时聊天监控等功能。随着用户量的激增，原有的基于 Node.js 的架构在处理高峰期的并发消息时开始出现延迟和丢包现象。

**问题**:
在游戏新版本发布或周末高峰期，消息吞吐量瞬间飙升至每秒数万条。现有的架构面临严重的性能瓶颈，导致消息处理延迟高达数秒，且内存占用过高，频繁触发 Out of Memory (OOM) 重启，严重影响用户体验。

**解决方案**:
团队引入了基于 Elixir 构建的 Jido Agent 框架重写了核心消息处理层。利用 Elixir 的 Erlang VM (BEAM) 特性，实现了低延迟、高并发的 Actor 模型。Jido 的 Agent 机制允许每个用户会话或游戏频道作为一个独立的轻量级进程运行，不仅实现了状态隔离，还利用其内置的工作流编排能力，轻松处理复杂的异步任务链（如：接收消息 -> 查询数据库 -> 调用外部 API -> 回复用户）。

**效果**:
- 系统吞吐量提升了 5 倍以上，单节点可轻松处理每秒 2 万条以上的消息。
- 消息处理延迟从平均 500ms 降至 50ms 以内。
- 由于 Erlang VM 的抢占式调度和容错机制，即使在高负载下，单个用户进程的故障也不会导致整个系统崩溃，系统可用性 (SLA) 提升至 99.99%。

---



### 2：金融科技实时交易风控系统

 2：金融科技实时交易风控系统

**背景**:
一家金融科技初创公司开发了一个跨境支付网关，需要实时监控每一笔交易以防止欺诈和洗钱。该系统需要在毫秒级别内分析用户行为、交易模式和地理位置数据，并决定是放行、拒绝还是要求额外验证。

**问题**:
原有的基于 Python 的微服务架构在处理复杂的决策树和外部数据源（如信用评分 API）调用时，往往因为网络 I/O 阻塞导致响应时间过长。此外，风控规则的频繁变更要求开发人员不断修改代码并重新部署，无法满足业务部门对规则快速迭代的需求。

**解决方案**:
技术团队采用 Jido 2.0 框架构建了新一代的风控决策引擎。利用 Jido 的 Agent 和 Workflow 能力，将风控规则抽象为独立的模块化 Agents。这些 Agents 可以并行执行（例如，同时检查黑名单、计算风险评分、验证设备指纹），并通过消息传递协调状态。Jido 允许团队通过配置而非硬编码来定义 Agents 的交互逻辑，甚至支持在运行时动态加载新的规则逻辑。

**效果**:
- 交易风控检测的平均响应时间从 200ms 缩短至 30ms，极大地提升了支付成功率。
- 业务团队通过配置文件即可调整风控策略，新规则的上线时间从数天缩短至数分钟。
- 系统的并发处理能力显著增强，在黑色星期五等购物节期间，无需扩容即可应对 10 倍于平时的交易流量。

---



### 3：SaaS 平台复杂异步任务编排系统

 3：SaaS 平台复杂异步任务编排系统

**背景**:
一家提供企业级营销自动化服务的 SaaS 公司，其核心产品允许用户创建包含数十个步骤的复杂营销工作流（例如：用户注册 -> 发送欢迎邮件 -> 等待 24 小时 -> 检查是否打开 -> 分配给销售代表 -> 更新 CRM）。这些工作流涉及长时间的延时、重试逻辑和与第三方系统的集成。

**问题**:
随着客户数量的增长，原有的基于 Redis 队列和 Sidekiq 的任务调度系统变得难以维护。长时间运行的任务经常因为服务器重启而丢失状态，且复杂的分支逻辑（例如“如果用户点击了链接 A 则走路径 X，否则走路径 Y”）导致代码库充满了难以测试的“面条代码”。

**解决方案**:
工程团队决定使用 Jido 2.0 重构任务编排层。Jido 的 Agent 模型天然适合处理长期运行的状态机。每个营销工作流被定义为一个 Jido Workflow，其中的每个步骤由一个 Agent 处理。Jido 持久化每个 Agent 的状态，因此即使系统部署或崩溃，工作流也能从断点处恢复，无需从头开始。

**效果**:
- 彻底解决了任务丢失问题，任务执行可靠性达到 100%。
- 复杂工作流的代码量减少了 60%，逻辑清晰度大幅提升，降低了维护成本。
- 得益于 Elixir 的分布式特性，该系统可以轻松跨多台服务器扩展工作流的执行，支持了公司客户数量的三倍增长而无需增加额外的运维人力。

---
## 最佳实践

## 最佳实践指南

### 实践 1：利用 OTP 实现容错性

**说明**: Jido 基于 Elixir 和 Erlang VM (BEAM)，其核心优势在于 OTP (Open Telecom Platform) 提供的监督树。在构建 Agent 时，应充分利用 GenServer 和 Supervisor 来管理进程生命周期，确保 Agent 在遇到错误时能够自动重启或恢复状态，而不是直接崩溃。

**实施步骤**:
1. 将 Agent 的核心逻辑封装在 GenServer 模块中。
2. 定义清晰的 `init`、`handle_call` 和 `handle_cast` 回调。
3. 配置 Supervisor 策略（如 `:one_for_one`），并设置合理的重启强度（`max_restarts` 和 `max_seconds`）。

**注意事项**: 避免在 GenServer 中执行阻塞操作，以防影响监督树的响应速度。

---

### 实践 2：采用“Let it Crash”哲学

**说明**: Elixir 的哲学是“让它崩溃”，而不是编写复杂的防御性代码来捕获每一个异常。在 Jido Agent 开发中，应允许进程在遇到无法恢复的状态时快速失败，并由 Supervisor 负责重启并恢复到干净的初始状态。

**实施步骤**:
1. 专注于“快乐路径”（Happy Path）的逻辑实现。
2. 对于未预料到的错误，允许其抛出异常而非吞没错误。
3. 确保在 `init` 回调中能够从持久化存储或默认值中恢复状态。

**注意事项**: 必须配合 Supervisor 使用，否则“崩溃”将导致服务不可用。

---

### 实践 3：模块化与可组合性设计

**说明**: Jido 2.0 强调 Agent 的组合能力。应将复杂任务分解为小型、单一职责的 Action 或工具。通过组合这些简单的模块来构建复杂的行为，而不是在一个巨大的单体模块中处理所有逻辑。

**实施步骤**:
1. 定义清晰的接口和数据结构，确保不同 Action 之间的输入输出标准化。
2. 使用 Elixir 的管道操作符 (`|>`) 来串联多个处理步骤。
3. 将通用的功能（如 HTTP 请求、数据处理）抽取为独立的库或辅助函数。

**注意事项**: 保持模块的幂等性，确保在多次重试或执行时产生一致的结果。

---

### 实践 4：利用不可变数据结构管理状态

**说明**: Elixir 的数据是不可变的。在 Jido Agent 中，状态的更新应通过返回新的状态版本来实现，而不是修改现有状态。这有助于避免竞态条件，并使状态变化的历史可追溯。

**实施步骤**:
1. 在 GenServer 的回调中，始终返回包含更新后状态的元组（如 `{:reply, response, new_state}`）。
2. 使用 Elixir 的结构体（Structs）和 Map 来定义状态模型，确保类型安全。
3. 避免在状态中存储大量的过程数据，优先存储 ID 或引用。

**注意事项**: 注意内存管理，避免在频繁更新的状态中保留不必要的历史数据导致内存泄漏。

---

### 实践 5：实施结构化日志记录与可观测性

**说明**: 分布式 Agent 系统难以调试。必须从项目开始就集成结构化日志。利用 Elixir 强大的 `Logger` 库记录关键决策点、状态变更和错误信息，并使用 Telemetry 进行指标监控。

**实施步骤**:
1. 在关键业务逻辑（如 Agent 决策、工具调用）处添加 `Logger.info/debug`。
2. 使用 `:telemetry` 附件来追踪执行时间和成功率。
3. 确保日志包含上下文信息（如 Agent ID, Task ID），以便在分布式日志系统中追踪。

**注意事项**: 避免记录敏感信息（如 PII 数据、API 密钥），应在日志输出前进行过滤或脱敏。

---

### 实践 6：优化并发与消息传递

**说明**: Jido Agent 可能会同时处理大量请求。应合理使用 Elixir 的并发原语（Task, Process mailbox）来处理 I/O 密集型或 CPU 密集型任务，防止阻塞主 Agent 进程。

**实施步骤**:
1. 对于耗时操作（如调用外部 LLM API），使用 `Task` 异步执行，并在完成后通过 `send/2` 将结果发回 GenServer。
2. 使用 `handle_info` 处理异步返回的消息。
3. 考虑使用 `:poolboy` 或 `:nimble_pool` 对资源（如数据库连接）进行池化管理。

**注意事项**: 控制并发度，避免因创建过多进程导致 BEAM 调度器过载。

---

### 实践 7：编写基于属性的测试

**说明**: 由于 Agent 的行为可能具有随机性或依赖外部模型，传统的单元测试可能不够。应结合 Elixir 的 `ExUnit` 和 StreamData 等库，编写基于属性的测试，验证 Agent 在各种输入下的行为一致性。

**实施步骤**:
1. 使用 `ExUnit.Case` 编写正常的单元测试。
2. 引入 `StreamData`，定义输入数据的生成

---
## 学习要点

- 基于对 Jido 2.0 及其相关技术背景的分析，以下是关键要点总结：
- Jido 2.0 是一个基于 Elixir 构建的 AI Agent 框架，利用 Erlang VM 的容错和并发特性，解决了传统 Python 框架在处理长期运行任务时的稳定性问题。
- 该框架采用“工作流即代码”的设计理念，将复杂的 AI 代理逻辑定义为可组合的 Elixir 函数，从而简化了多步骤任务的编排与管理。
- 通过利用 BEAM 虚拟机的轻量级进程能力，Jido 能够实现高度并行的 Agent 执行，显著降低了系统在高负载下的延迟。
- 框架内置了强大的工具集成能力，支持将函数调用、SQL 查询及外部 API 调用统一封装为标准化的“工具”，供 LLM 动态调用。
- Jido 实现了结构化的状态管理机制，确保 Agent 在执行复杂推理链时，中间状态和上下文能够得到有效保存与恢复。
- 它无缝集成了 LangChain 协议，允许用户在享受 Elixir 高性能后端的同时，复用现有的 LLM（如 OpenAI、Anthropic）生态资源。

---
## 常见问题


### 1: Jido 2.0 是什么，它与 Elixir 生态系统中的其他 Agent 框架（如 LangChain）有何不同？

1: Jido 2.0 是什么，它与 Elixir 生态系统中的其他 Agent 框架（如 LangChain）有何不同？

**A**: Jido 2.0 是一个基于 Elixir 语言构建的 Agent（智能体）框架。它的核心设计理念是利用 Elixir 的并发模型（Actor 模型）和 BEAM 虚拟机的容错性来构建高性能、分布式的 AI 智能体。

与目前流行的 LangChain 等框架相比，Jido 的主要区别在于底层架构和运行机制：
1.  **原生并发**：LangChain 等框架通常基于 Python，依赖异步循环或外部队列来处理并发任务，而 Jido 原生建立在 Erlang VM 上，每个 Agent 或任务可以作为轻量级进程运行，天生具备高并发和低延迟的特性。
2.  **容错性**：得益于 OTP（Open Telecom Platform），Jido 中的 Agent 具备“监督树”机制。如果某个 Agent 崩溃，系统可以自动重启它，而不会导致整个工作流失败，这对于长时间运行的后台任务至关重要。
3.  **分布式能力**：Jido 设计之初就考虑了分布式部署，Agent 可以轻松地在不同节点间通信，而 Python 框架通常需要额外的中间件来实现类似功能。

---



### 2: Jido 2.0 中的“Agent”具体是如何工作的？

2: Jido 2.0 中的“Agent”具体是如何工作的？

**A**: 在 Jido 2.0 中，Agent 被设计为独立的、有状态的进程，它们通过消息传递进行协作。具体工作流程通常包含以下几个核心概念：

1.  **Agent 进程**：每个 Agent 是一个 GenServer（Elixir 中的一种通用服务器进程），它维护自己的状态（例如任务上下文、记忆或配置）。
2.  **工具与技能**：Agent 被赋予了特定的能力，称为“工具”。这些工具本质上是 Elixir 函数，Agent 可以根据输入的指令决定调用哪个工具。
3.  **调度与执行**：当用户向 Agent 发送一个任务时，Agent 会根据其配置的“大脑”（例如 LLM 提示词或逻辑规则）来规划步骤，串行或并行地执行工具调用，并更新内部状态。
4.  **消息总线**：Jido 通常利用 Broadway 或 GenStage 进行数据流处理，允许 Agent 以声明式的方式处理异步事件流。

简而言之，Jido 2.0 的 Agent 不仅仅是简单的 LLM 提示词包装器，而是具备独立生命周期、状态管理和错误恢复能力的健壮进程。

---



### 3: 我可以使用哪些大语言模型（LLM）来驱动 Jido Agent？

3: 我可以使用哪些大语言模型（LLM）来驱动 Jido Agent？

**A**: Jido 2.0 作为一个框架，主要关注 Agent 的控制逻辑、状态管理和工作流编排，而不是硬编码特定的 LLM 提供商。它通常通过适配器模式或标准的 HTTP 客户端（如 `Req` 或 `Finch`）来与大语言模型交互。

理论上，你可以接入任何提供 HTTP API 的 LLM，包括但不限于：
*   OpenAI (GPT-4, GPT-3.5)
*   Anthropic (Claude 系列)
*   开源模型（如通过 Ollama 或 vLLM 本地部署的 Llama 3, Mistral 等）

Jido 的灵活性在于允许开发者定义如何将 Agent 的思维过程转化为 API 请求，这意味着你可以根据成本或性能需求，轻松地在不同模型之间切换，甚至实现混合模型架构。

---



### 4: 对于不熟悉 Elixir 的开发者，学习 Jido 2.0 的门槛高吗？

4: 对于不熟悉 Elixir 的开发者，学习 Jido 2.0 的门槛高吗？

**A**: 这取决于你的背景。如果你已经熟悉函数式编程或 Actor 模型，上手会很快。但对于习惯了命令式编程（如 Python 或 Java）的开发者，确实存在一定的学习曲线，主要原因如下：

1.  **Elixir 语法**：你需要掌握模式匹配、管道操作符 和宏 等基本概念。
2.  **并发模型**：理解“进程”、“邮箱”和“消息传递”与传统的多线程编程有很大不同。
3.  **OTP 抽象**：虽然 Jido 封装了很多细节，但理解 GenServer 和 Supervisor 的基本原理对于调试和构建健壮的 Agent 至关重要。

不过，Jido 2.0 的目标通常是简化这些复杂性。如果你只是想运行简单的 Agent，可能不需要深入底层 OTP。但若要构建复杂的、分布式的多 Agent 系统，深入理解 Elixir 的特性是必须的。

---



### 5: Jido 2.0 是否支持“多 Agent 协作”或“团队协作”模式？

5: Jido 2.0 是否支持“多 Agent 协作”或“团队协作”模式？

**A**: 是的，这是 Jido 的强项之一。由于 Elixir 天生就是为了分布式系统设计的，Jido 2.0 非常适合构建多 Agent 系统。

在这种模式下，你可以创建具有不同角色的 Agent（例如：一个负责搜索，一个负责代码编写，一个负责审核）。这些 Agent 可以：
*   **异步通信**：通过发送消息相互请求帮助或共享信息，而不会阻塞主线程。
*   **监督与恢复**：如果

---
## 思考题


### ## 挑战与思考题

### ### 挑战 1: [简单]

### 问题**: 在 Jido 中，Agent 的核心是执行任务。请编写一个最基础的 Elixir Agent，它不依赖 Jido 框架，仅使用 Elixir 标准库中的 `Agent` 模块。该 Agent 需要维护一个整数状态，并提供一个 `increment/1` 函数来增加这个数值。

### 提示**: 查看 Elixir 官方文档关于 `Agent.start_link/2` 和 `Agent.update/3` 的用法。思考如何将状态保存在 Agent 的内部循环中，以及如何通过 `Agent.get` 来验证结果。

### 

---
## 引用

- **原文链接**: [https://jido.run/blog/jido-2-0-is-here](https://jido.run/blog/jido-2-0-is-here)
- **HN 讨论**: [https://news.ycombinator.com/item?id=47263036](https://news.ycombinator.com/item?id=47263036)

> 注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

---


---
## 站内链接

- 分类： [开发工具](/categories/%E5%BC%80%E5%8F%91%E5%B7%A5%E5%85%B7/) / [AI 工程](/categories/ai-%E5%B7%A5%E7%A8%8B/)
- 标签： [Elixir](/tags/elixir/) / [Agent框架](/tags/agent%E6%A1%86%E6%9E%B6/) / [Jido](/tags/jido/) / [LLM](/tags/llm/) / [RAG](/tags/rag/) / [并发](/tags/%E5%B9%B6%E5%8F%91/) / [BEAM](/tags/beam/) / [开源](/tags/%E5%BC%80%E6%BA%90/)
- 场景： [大语言模型](/scenarios/%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B/) / [RAG应用](/scenarios/rag%E5%BA%94%E7%94%A8/)

### 相关文章

- [Show HN: Jido 2.0，Elixir 智能体框架](/posts/20260305-hacker_news-show-hn-jido-20-elixir-agent-framework-2/)
- [Show HN: Jido 2.0，基于 Elixir 的 Agent 框架](/posts/20260305-hacker_news-show-hn-jido-20-elixir-agent-framework-1/)
- [Jido 2.0：基于 Elixir 的智能体框架](/posts/20260305-hacker_news-show-hn-jido-20-elixir-agent-framework-8/)
- [crawl4ai：面向AI时代的LLM友好型数据采集工具](/posts/20260226-juejin-crawl4aiai%E6%97%B6%E4%BB%A3%E7%9A%84%E6%95%B0%E6%8D%AE%E9%87%87%E9%9B%86%E5%88%A9%E5%99%A8%E4%BB%8E%E5%85%A5%E9%97%A8%E5%88%B0%E5%AE%9E%E6%88%98-0/)
- [Vercel AI SDK 子代理：解决复杂 Agent 系统上下文爆炸问题](/posts/20260213-juejin-vercel-ai-sdk-%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97-%E5%AD%90%E4%BB%A3%E7%90%86-subagents-1/)
*本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。*