如何为 LLM 代理设计两个实用的编排循环
Source: Dev.to
你应该始终分离的三层
执行层
代理（agents）和响应器（responders）位于此层。
**Agent（代理）**指任何执行工作的单元：模型调用、工具、启发式函数、路由器。
**Responder（响应器）**是生成每轮或每个会话最终面向用户输出的代理。
通信层
代理之间以及与编排器之间的通信方式。
示例：队列、事件、内部 RPC 调用、函数回调。
你很少希望代理直接相互调用。将所有交互都通过此层路由，这样才能追踪和控制。
记忆层
用于跨时间存储和检索状态的地方。
可以是向量库、键值存储、数据库或日志。
不要把它“隐藏在提示里”。把记忆视为独立的组件。
将时间视为一等维度
两种循环都显式地处理 时间：
- 线性循环 – 离散步骤：T0、T1、T2、T3。
- 循环循环 – 在对话活跃期间持续流动的流。
有了这些要素，就可以设计两种编排模式。
循环 1：用于上下文提取和分析的线性编排器
何时使用线性循环
当你拥有 固定输入（文本、转录、文档、一组日志）并希望对其进行 多次分析 时使用。延迟重要，但不要求亚秒级交互。典型输出包括摘要、报告、分类或结构化数据。
典型示例
- 通话结束后的对话分析。
- 从聊天日志中抽取实体和主题。
- 多阶段文档处理（OCR → 清洗 → 分类 → 摘要）。
- 对历史会话进行离线质量检查。
思维模型
想象一张水平图：
- INPUT →（时间步 T0 … Tn）→ Responder（最终结构化输出）
- 输入与响应器之间：
- 每个时间片的执行层代理。
- 中间的通信层。
- 顶部的记忆层。
在每一步，代理可以从记忆中读取，也可以将新事实或摘要写回记忆。编排器逐步遍历这些步骤。
步骤化设计
步骤 1：定义最终输出
确定响应器将产生的内容，例如：
{
"intent": "...",
"sentiment": "...",
"entities": {...},
"summary": "..."
}或是可供人阅读的报告，亦或是供其他系统使用的标签/分数。所有其他代理的存在都是为了帮助该响应器成功。
步骤 2：将工作拆分为阶段
识别依赖关系和独立工作。以下是对话分析的示例：
- 规范化 & 语言检测。
- 实体抽取（姓名、账户 ID、产品）。
- 主题 & 意图检测。
- 情感 & 升级风险。
- 最终摘要 & 建议。
每个阶段成为一个 时间片，其中包含一个或多个代理。
步骤 3：设计记忆模式
为每个阶段列出代理读取和写入的内容。一个简单的模式：
{
"language": "en",
"entities": {...},
"topics": [...],
"sentiment": {...},
"summary": "..."
}你也可以按 session_id、user_id 或 time_window（用于滚动分析）来划分记忆。
关键规则： 代理接收干净的输入和结构化的记忆切片；不要在提示内部隐藏上下文。
步骤 4：接线读取与写入
为每个代理定义两个小函数：
def read(memory) -> context:
...
def write(memory, result) -> memory:
...一个最小的编排循环如下：
for step in steps:
# 1. 加载本步骤所需的内容
ctx = step.read(memory)
# 2. 使用输入和上下文运行代理
result = step.agent.run(raw_input, ctx)
# 3. 将新事实写回记忆
memory = step.write(memory, result)有的步骤只写，有的只读。
步骤 5：将响应器实现为最后一步
响应器只是另一个拥有特殊角色的代理：
- 从记忆中读取所需的全部信息。
- 生成最终答案（通常是一次聊天完成调用，结合原始输入、前置分析代理的输出以及任何长期用户/会话记忆）。
- 可能会把额外的元数据记录回记忆。
示例：对话分析流水线
| 代理（Agent） | 读取内容（Reads） | 写入内容（Writes） |
|---|---|---|
| LanguageDetectorAgent | 原始转录 | memory["language"] |
| EntityExtractorAgent | 转录、语言 | memory["entities"] |
| TopicClassifierAgent | 转录、实体 | memory["topics"] |
| SentimentAgent | 转录 | memory["sentiment"] |
| SummaryResponder | 转录、实体、主题、情感 | 最终可读摘要 & JSON 记录 |
该表直接映射到线性图示，便于逐步调试。
循环 2：用于实时聊天和语音的循环流式编排器
第二种模式出现在你从离线分析转向 实时交互（语音或交互式聊天）时。此时你需要：
- 在用户仍在说话或输入时快速响应。
- 并行运行多个后台分析。
- 避免在每个回合把完整转录发送给每个代理。
循环循环（circular loop）模式正是为此而生。
何时使用循环循环
当你满足以下任意条件时使用：
- 以流式方式输入/输出音频或 token。
- 拥有一个与用户对话的中心“助理”。
- 希望后台代理能够检测情感变化、安全合规问题、意图切换、CRM 实体更新或标记有价值的瞬间。
想象一个语音助理或实时会议转录系统：主助理在与用户对话的同时，辅助代理持续丰富上下文。