在边缘构建 AI 代理的编排模式

Source: Dev.to

什么是真正的代理（Agent）？

代理是一种旨在自主追求目标的系统。它 不仅仅是一个 LLM。可以把代理看作由三个关键组件组成：

• 大脑（LLM） – 核心推理引擎
• 感官（输入） – 对世界的感知
• 双手（工具） – 对世界的操作能力

单独的 LLM 只是一个“罐子里的大脑”。代理必须与其环境交互。

为什么单一代理在生产环境中会失败

电影常常描绘单一全知的 AI（比如 Skynet）。实际上，当前的 LLM 强大但脆弱——它们像“拿着百科全书的孩子”，容易分心，在多步骤任务上容易出错。依赖单一代理会导致：

• 上下文过载 – 没有固有记忆，导致 token 使用量和成本上升
• 执行脆弱 – 单点失败会迫使整个系统重启
• 信息泄漏 – 单一点的访问可能暴露敏感数据

“全能实习生”问题

单独的代理类似一个热情却不堪重负的实习生。当负荷过大时，它会出现：

1. 上下文过载 – 工具和输入过多会增加延迟和成本。
2. 完全崩溃 – 任一步骤的失败会中止整个工作流。
3. 信息泄漏 – 敏感数据可能被无意中泄露。

安全问题

设想一个自动回复邮件的代理：

1. 它读取合法的银行对账单并进行摘要。
2. 攻击者发送钓鱼邮件，要求提供账户 ID 和余额。

由于代理拥有机密信息，它可能不经意地泄露这些信息。当单一代理拥有不受限制的访问权限时，数据泄漏的风险会急剧上升。

代理必须部署在边缘

代理应 靠近用户 运行——在能够提供毫秒级延迟的边缘服务器上。典型的代理工作流如下：

STT → LLM → Tool Call → LLM → TTS

每毫秒的累加都会削弱用户体验。Cloudflare Workers、Durable Objects、Workers AI、AI Gateway 和 Agents SDK 通过提供以下能力来解决这一问题：

• 短暂 Workers 用于无状态计算
• Durable Objects 用于持久状态和协同

如果你对 Durable Objects 不熟悉，可以参阅 Boris Tane 的精彩解释。

常见代理模式：解决方案

与其使用单体结构，不如将代理组织成 团队，主要分为两类：

短暂代理

• 在隔离环境中执行单一任务
• 完成后立即销毁
• 不保留过去交互的记忆
• 适用于对安全要求高的操作

永久代理

• 长期运行的身份
• 保持持久状态
• 协调工作流并聚合结果
• 负责路由和编排

核心模式

• Router – 永久代理，负责将请求分配给合适的 Worker。
• Worker – 短暂代理，执行单个动作。
• Fleet Manager – 生成并监控 Workers，处理扩展和健康检查。

这些构建块可以组合使用，以解决诸如前文所述的邮件回复场景，同时保持安全性、可靠性和低延迟。