Forge框架：自托管LLM的状态机驱动工具编排与多步工作流管理

在自托管 LLM 的落地实践中，8B 级别的小模型往往面临一个核心矛盾：它们具备执行多步任务的能力，却容易在工具调用格式、步骤顺序和上下文管理上出错。Forge 框架通过状态机驱动的工具编排与多层 Guardrails 机制，将 Ministral-3 8B 这类本地模型的多步工作流成功率提升至 86.5%（26 场景测试集），在最困难的推理任务上仍能保持 76% 的完成率。

本文从状态机设计、Guardrails 可靠性层、上下文压缩策略三个维度，解析 Forge 如何实现本地化的工具调用与任务链管理。

状态机设计：将控制流与记忆分离

Forge 的核心架构决策之一（P0-1）是明确区分 "模型记忆" 与 "运行器控制"。消息历史（message history）是模型的 "草稿纸"，可以被压缩重塑；而步骤完成状态是权威的控制流事实，由运行器独立维护。

StepTracker 与 StepEnforcer

StepTracker是一个独立的状态跟踪器，位于WorkflowRunner内部而非消息历史中：

@dataclass
class StepTracker:
    required_steps: list[str]
    completed_steps: dict[str, None] = field(default_factory=dict)
    
    def record(self, tool_name: str) -> None:
        self.completed_steps[tool_name] = None
        
    def is_satisfied(self) -> bool:
        return all(s in self.completed_steps for s in self.required_steps)

StepEnforcer包装StepTracker，提供三层防御机制：

1. 过早终止检测：当模型试图在required_steps未完成时调用terminal_tool，触发阶梯式 nudge（tier 1/2/3），三次失败后抛出StepEnforcementError
2. 前置条件检查：每个ToolDef可声明prerequisites，未满足时阻止整个批次执行
3. 状态持久化：即使上下文被压缩，步骤完成状态仍准确记录

这种设计的关键在于：当TieredCompact第三阶段激进地丢弃历史tool_result时，模型可能冗余地重新调用工具，但不会破坏工作流的完整性。

Guardrails：三层可靠性防护

Forge 的 Guardrails 不是简单的重试包装，而是针对不同故障模式的专门化处理层。

ResponseValidator：救援与重试

面对本地模型常见的格式错误，ResponseValidator提供两条恢复路径：

• Rescue 解析：当模型返回TextResponse而非预期的ToolCall时，尝试从文本中提取工具调用（支持 JSON 代码块和tool[ARGS]{...}语法）
• 阶梯式 Nudge：救援失败后，注入retry_nudge提示模型重新尝试，最多max_retries_per_step次（默认 3 次）

对于调用不存在工具的情况，注入unknown_tool_nudge并列出可用工具列表，而非直接失败。

ErrorTracker：错误预算管理

区分两类错误并分别设置预算：

• 格式错误：连续max_retries_per_step次失败触发ToolCallError
• 工具执行错误：连续max_tool_errors次（默认 2 次）失败触发ToolExecutionError

关键设计：当工具抛出ToolResolutionError（参数有效但数据未解析）时，错误反馈给模型但不计入错误计数，也不标记步骤完成，允许模型自我修正。

Synthetic Respond Tool

小模型（~8B）在 "应该聊天还是调用工具" 的开放式决策上表现极差 —— 测试显示信任模型的finish_reason会使工作流完成率从 100% 降至 4%。Forge 的解决方案是合成 respond 工具：

tools = {
    "search": search_tool,
    "respond": respond_tool(),  # 强制模型始终处于tool-calling模式
}
workflow = Workflow(..., terminal_tool="respond")

模型调用respond(message="...")代替直接输出文本，Proxy 层在返回客户端前剥离该调用。这消除了开放式决策，将问题转化为 "选择哪个工具" 的结构化决策。

TieredCompact：VRAM 感知的三阶段压缩

在消费级 GPU（12-32GB VRAM）上，15 步工作流可能达到 10-20K token，将 14B 模型从 GPU 推入 RAM（性能下降 5-20 倍）。TieredCompact提供确定性的三阶段压缩策略：

保护窗口：keep_recent参数（默认 2）指定最近多少次迭代完全不受影响。浅层工作流（3-5 步）建议 2-3，深层工作流（8-10 + 步）建议 4-6。

压缩优先级的设计 rationale

reasoning（模型的思维链）在 P2 阶段仍被完整保留，因为 "步骤 3 的推理（' 定价 $10.69 但历史显示 $9.50'）是指导步骤 5 + 决策的关键"。丢失原始工具结果可恢复；丢失模型对结果的解释则不可恢复。

可落地的参数配置

基于 Forge 的评估数据与架构文档，以下是生产环境的推荐配置：

# 上下文管理
ctx = ContextManager(
    strategy=TieredCompact(keep_recent=3),  # 浅层2-3，深层4-6
    budget_tokens=8192,  # 或FORGE_FULL/FORGE_FAST模式自动解析
    compact_threshold=0.75
)

# 工作流运行器
runner = WorkflowRunner(
    client=client,
    context_manager=ctx,
    max_iterations=10,        # 硬上限，防止无限循环
    max_retries_per_step=3,   # 格式错误容忍
    max_tool_errors=2,         # 工具执行错误容忍
    rescue_enabled=True        # 启用rescue解析
)

# 工作流定义
workflow = Workflow(
    name="data_pipeline",
    tools={"fetch": fetch_def, "transform": transform_def, "save": save_def},
    required_steps=["fetch", "transform"],  # 必须按顺序完成
    terminal_tool="save",
    system_prompt_template="..."
)

StepEnforcer 的防御参数

step_enforcer = StepEnforcer(
    required_steps=["fetch", "transform"],
    terminal_tools=frozenset(["save"]),
    tool_prerequisites={"transform": ["fetch"]},  # transform必须在fetch之后
    max_premature_attempts=3,   # 过早终止尝试上限
    max_prereq_violations=2     # 前置条件违反上限
)

与现有方案的差异

相较于 LangChain 的链式编排或 LlamaIndex 的 RAG 管道，Forge 的定位是可靠性层而非应用框架：

• 不处理意图路由：下游项目自行决定何时调用WorkflowRunner
• 不管理模型选择：单工作流单模型，多模型路由是下游责任
• 专注于小模型优化：Guardrails、respond 工具、TieredCompact 均针对 8B 级模型的可靠性问题设计

评估数据显示，在相同的 Ministral-3 8B 模型上，启用完整 Guardrails（reforged 配置）相比裸运行（bare 配置）可将多步工作流成功率提升约 15-20 个百分点。

资料来源

• Forge GitHub Repository
• Forge Architecture Documentation
• Forge Workflow Internals

ai-systems