本地模型上的多步骤 AI Agent：架构与模式

单步骤 AI Agent 是一个已解决的问题。用户说点什么，模型选择一个工具，工具返回结果。经过微调的 7B 模型可以可靠地处理这一任务——我们在工具调用微调指南中已深入介绍过。

多步骤 Agent 则完全不同。模型需要规划一系列动作，在各步骤之间跟踪状态，处理链路中的错误，并决定任务何时完成。这正是小型模型历来崩溃的地方：它们会丢失上下文，重复步骤，产生虚构的工具调用，或陷入无限循环。

但"历来"这个词在这里承载了太多含义。凭借正确的架构模式，多步骤 Agent 如今已能在本地 7B-14B 模型上可靠运行。本指南涵盖三种经过验证的模式、真实基准测试，以及使其运行的工程细节。

核心挑战：为什么多步骤对小型模型来说很难

单步骤 Agent 只需要一项技能：将用户意图映射到工具调用。多步骤 Agent 至少需要四项：

1. 规划 — 将目标分解为有序的步骤
2. 执行 — 在每一步使用正确的参数调用正确的工具
3. 状态跟踪 — 将第 N 步的结果传递到第 N+1 步
4. 错误恢复 — 检测失败并在重试、跳过或升级之间做出决策

通用 7B 模型之所以困难，是因为它们是在广泛任务上训练的，而不是顺序推理链。注意力窗口在 2-3 步后就会变得嘈杂。模型会"忘记"它已经做了什么或计划做什么。

解决方案不是更大的模型。解决方案是更好的架构。

模式 1：微调专家链

不是让一个模型做所有事情，而是将 Agent 拆分为专门的角色：

用户请求 → 路由器 → 规划器 → 执行器 → 验证器 → 响应

每个模型都很小但高度聚焦：

• 路由器（分类）：确定请求类型。这是订单吗？支持查询？数据查找？这是一个简单的分类任务——即使 1B 模型也能处理。
• 规划器（分解）：接收分类后的请求并输出有序的步骤列表。在你的特定工作流上微调，它不需要规划任意任务——只需要规划你的任务。
• 执行器（工具调用）：一次接收一个步骤并生成工具调用。这就是单步骤工具调用——已解决的问题。
• 验证器（校验）：检查累积的结果。所有必填字段都存在吗？输出是否匹配预期的 schema？标记问题以便重试或升级。

为什么这在小型模型上有效

每个专家都在狭窄的任务上进行微调。路由器看到数千个"此输入类型映射到此类别「的示例。规划器看到数千个」此类别分解为这些步骤"的示例。没有单个模型需要持有完整的推理链。

权衡取舍

延迟。四个模型顺序调用意味着单次调用推理时间的 4 倍。在本地 GPU 上，每次 7B 模型推理需要 200-500 毫秒（取决于上下文长度和量化）。4 步链总共需要 0.8-2.0 秒。

对于大多数业务工作流，这是可以接受的。对于实时聊天，会有明显感知。缓解方案：在依赖图允许的情况下并行运行专家。

基准测试：专家链 vs 单模型

单个微调模型相比通用模型有所改进，但链式架构是一个质的飞跃。每个专家只做好一件事。

模式 2：带草稿本的单模型（CoT 微调）

并非每个团队都想维护四个独立模型。模式 2 使用单个模型，但对其进行微调使其在行动前逐步思考。

关键洞察：你训练模型在输出工具调用之前生成一个"草稿本"——一个显式的推理轨迹。这是思维链（CoT）微调，但专门针对你的规划任务。

训练数据格式

{
  "input": "Process order #4521 for customer acme-corp",
  "output": "<scratchpad>\nStep 1: Validate order #4521 exists and is in pending status\nStep 2: Check inventory for all line items\nStep 3: Calculate shipping based on customer location\nStep 4: Confirm order and send notification\nCurrent step: 1\n</scratchpad>\n<tool_call>{\"function\": \"validate_order\", \"params\": {\"order_id\": 4521}}</tool_call>"
}

在每个工具结果之后，模型接收更新的上下文并生成下一个草稿本：

{
  "input": "[Previous context + tool result: order valid, status: pending]\nContinue processing.",
  "output": "<scratchpad>\nStep 1: Validate order — DONE (valid, pending)\nStep 2: Check inventory for all line items\nCurrent step: 2\n</scratchpad>\n<tool_call>{\"function\": \"check_inventory\", \"params\": {\"order_id\": 4521}}</tool_call>"
}

为什么这有效

草稿本外化了模型的"工作记忆"。不再隐式跟踪它做了什么以及接下来要做什么（小型模型容易丢失跟踪），而是将计划直接写在输出中。模型在每一步都读取自己之前的推理。

在你的特定工作流上用 500-1,000 个示例进行微调，教会模型你的步骤模式。它不需要规划任意任务——只需要处理你的 Agent 涵盖的 5-15 种工作流类型。

何时使用模式 2 而非模式 1

• 你的不同工作流类型少于 5 种
• 延迟很重要（一次模型调用 vs 四次）
• 你想要更简单的部署（服务一个模型，而不是四个）
• 你的步骤主要是顺序的（并行化机会有限）

基准测试：草稿本 vs 普通微调

CoT 模型每步使用约 2.7 倍的 Token（因为草稿本），但准确率的提升是值得的。如果你在本地运行，Token 是免费的。

模式 3：混合——本地模型 + 前沿模型兜底

有时诚实的答案是：你的本地模型能处理 85% 的请求，但剩下的 15% 确实需要更强的能力。模式 3 使这一点变得显式。

用户请求 → 本地路由器（分类复杂度）
  ├── 简单/已知 → 本地 Agent（模式 1 或 2）
  └── 复杂/模糊 → 前沿 API（GPT-4、Claude）仅用于规划
       └── 计划 → 本地执行器（在本地运行工具）

工作原理

本地路由器在两个维度上对每个请求进行分类：

1. 复杂度：需要多少步骤？步骤来自已知模板还是全新的？
2. 模糊度：用户意图是否清晰？是否存在多种有效解释？

已知模板、意图明确的请求完全在本地处理。新颖或模糊的请求只将规划步骤发送到前沿 API。前沿模型生成步骤计划。本地模型执行每个步骤（工具调用）。

成本计算

假设每天 1,000 个 Agent 请求：

• 完全前沿 API：1,000 x $0.03 平均 = $30/天 = $900/月
• 完全本地：1,000 x $0.00 每次查询 = $0/天（仅硬件成本）
• 混合（85/15 分割）：150 x $0.01（仅规划，更短的提示）= $1.50/天 = $45/月

混合方案比完全 API 成本低 95%，同时处理本地模型可能出错的边缘情况。

成本上限和防护栏

为前沿兜底设置硬性月度预算。当达到上限时，所有请求路由到本地模型并附带置信度标志。应用程序可以决定：提供带免责声明的本地结果，或将请求排队以便后续处理。

步骤间的状态管理

无论你使用哪种模式，多步骤 Agent 都需要状态管理。以下是有效的方法：

对话上下文对象

{
  "session_id": "abc-123",
  "original_request": "Process order #4521 for acme-corp",
  "current_step": 2,
  "total_steps": 4,
  "completed_steps": [
    {"step": 1, "tool": "validate_order", "result": {"valid": true, "status": "pending"}, "latency_ms": 340}
  ],
  "pending_steps": ["check_inventory", "calculate_shipping", "confirm_order"],
  "error_count": 0,
  "max_errors": 3
}

将此对象（或精简版本）作为上下文传递给每次模型调用。模型不需要记忆——状态是显式的。

上下文窗口预算

一个具有 4,096 Token 上下文窗口的 7B 模型在包含工具 schema + 之前的结果 + 草稿本时会很快填满。合理分配：

• 系统提示 + 工具 schema：约 800 Token（固定）
• 当前步骤上下文：约 200 Token
• 之前步骤结果（精简）：每步约 150 Token
• 草稿本输出：约 120 Token

对于 5 步任务：800 + 200 + (4 x 150) + 120 = 1,720 Token。在 4K 范围内轻松容纳。对于更长的链，总结较早的步骤结果而不是包含原始输出。

错误处理：当第 3 步失败时

多步骤 Agent 会在链路中失败。关键是接下来会发生什么。

重试逻辑

步骤失败 → 检查错误类型
  ├── 瞬时错误（超时、速率限制） → 重试同一步骤（最多 2 次重试）
  ├── 输入错误（参数错误） → 使用错误上下文重新生成工具调用
  └── 逻辑错误（不可能的状态） → 升级处理

对于"重新生成"路径，将错误消息追加到模型的上下文中：

Previous tool call failed: "inventory_check returned 404: order_id 4521 not found in warehouse_east"
Adjust your approach and try again.

当你的训练数据包含错误恢复示例时，微调模型能很好地处理这种情况。在训练集中包含 10-15% 的错误场景。

升级处理

当重试失败或错误是逻辑错误时，进行升级：

1. 升级到前沿模型：使用完整上下文通过 GPT-4/Claude 重新运行失败的步骤
2. 升级到人工：将请求标记在审核队列中，附带完整的步骤历史
3. 优雅降级：完成已成功的步骤，返回部分结果并清楚解释哪里失败了

防护栏：防止无限循环和失控成本

最大步骤数

硬限制。如果你最长的已知工作流是 6 步，将 max_steps 设为 8。如果模型到达第 9 步，终止链路并升级处理。

MAX_STEPS = 8
STEP_TIMEOUT_MS = 5000

for step in range(MAX_STEPS):
    result = execute_step(context, timeout=STEP_TIMEOUT_MS)
    if result.status == "complete":
        return result
    if result.status == "error" and context.error_count >= MAX_ERRORS:
        return escalate(context)

return escalate(context, reason="max_steps_exceeded")

成本上限（混合模式）

对于模式 3，按小时、天和月跟踪前沿 API 支出。在预算的 50%、80% 和 100% 设置告警。达到 100% 时，停止路由到前沿并记录每个本应路由的请求——这将成为下一次迭代的微调数据集。

人机协同

对于高风险工作流（金融交易、医疗决策、法律行动），在最终操作前添加确认步骤：

步骤 1-3 完成 → 向人工展示摘要 → 人工批准 → 步骤 4 执行

这在异步（基于队列）和同步（基于聊天）界面中都能自然运作。

7B 何时够用 vs 何时需要 14B+

分界线：如果模型需要决定做什么（动态规划），选择 14B+。如果模型遵循已知模式并有少量变化，7B 加上正确的架构就足够了。

示例：4 步订单处理 Agent

以下是使用模式 2（草稿本）在微调 Qwen 2.5 7B 上的具体实现：

步骤 1 — 验证订单

Input: "Process order #4521 for acme-corp"
Scratchpad: "4 steps needed: validate → inventory → shipping → confirm. Starting with validation."
Tool call: validate_order(order_id=4521, customer="acme-corp")
Result: {valid: true, items: [{sku: "W-100", qty: 50}, {sku: "W-200", qty: 25}]}

步骤 2 — 检查库存

Scratchpad: "Order valid. 2 line items. Checking inventory for both SKUs."
Tool call: check_inventory(skus=["W-100", "W-200"], quantities=[50, 25])
Result: {W-100: {available: 200, allocated: 50}, W-200: {available: 30, allocated: 25}}

步骤 3 — 计算运费

Scratchpad: "All items available. Customer acme-corp is in warehouse zone east. Calculating shipping."
Tool call: calculate_shipping(order_id=4521, zone="east", weight_kg=37.5)
Result: {method: "ground", cost: 42.50, eta_days: 3}

步骤 4 — 确认订单

Scratchpad: "Shipping calculated. All checks passed. Confirming order."
Tool call: confirm_order(order_id=4521, shipping_method="ground", shipping_cost=42.50)
Result: {confirmed: true, confirmation_id: "CNF-88421"}

在 RTX 4090 上的总延迟：四个步骤全部完成仅需 1.8 秒。API 总成本：$0.00。

同样的流程在 GPT-4 上每个订单约花费 $0.04。按每天 500 个订单计算，即每天 $20 或每月 $600——而本地模型在不到 2 秒内就能完成。

开始使用

在本地模型上构建多步骤 Agent 的最快路径：

1. 映射你的工作流。列出你的 Agent 处理的每个多步骤流程。大多数团队有 3-8 种不同类型。
2. 选择你的模式。少于 5 种工作流类型且步骤线性？模式 2。更多种类或需要并行？模式 1。需要安全网？模式 3。
3. 构建训练数据。每种工作流类型 200-500 个示例，包括 10-15% 的错误场景。
4. 使用 LoRA 微调。7B 模型在单 GPU 上用 Ertas 不到一小时即可完成微调。
5. 端到端测试链路再部署。运行完整的工作流套件并衡量逐步准确率，而不仅仅是最终结果准确率。

延伸阅读

• 工具调用微调：如何构建可靠的 AI Agent — 模式 1 执行器使用的单步骤工具调用基础
• 当 7B 模型击败 API 调用时 — 展示小型模型在哪些场景匹配前沿性能的基准测试
• 微调小型模型 vs GPT-4：小模型何时获胜 — 任务特定微调超越通用模型的数据支撑