大语言模型计划-执行模式：从基础循环到工程化实现

1. 计划-执行Agent的本质：从朴素循环到工程化实现

在构建基于大语言模型的智能系统时，计划-执行（Plan-Execute）模式是最基础也最核心的范式之一。这种模式模拟了人类处理复杂任务时的自然思维过程：先制定计划，再分步执行，根据执行结果动态调整计划。让我们从最基础的实现开始，逐步探讨其工程化演进路径。

1.1 最基础的计划-执行循环

想象你要开发一个能自动完成复杂任务的AI助手。最直观的实现方式就是一个简单的循环结构：

go复制func BasicPlanExecute(input string) string {
    // 第一步：生成初始计划
    plan := llm.GeneratePlan(input)
    
    // 循环执行直到所有任务完成
    for {
        if plan.AllTasksDone() {
            return "任务完成"
        }
        
        task := plan.NextPendingTask()
        result := ExecuteTask(task)
        plan = llm.UpdatePlan(plan, task, result)
    }
}

这个朴素实现包含了三个关键组件：

• Planner（计划器）：将用户输入分解为可执行的子任务序列
• Executor（执行器）：实际执行单个子任务
• Replanner（重规划器）：根据执行结果动态调整计划

提示：这种基础实现适合简单场景，但当任务复杂度增加时，很快就会遇到工程瓶颈。

1.2 基础实现的局限性

在实际工程中，上述简单循环很快会暴露出几个关键问题：

1. 控制流僵化：现实任务中，我们可能需要：

   • 遇到严重错误时完全终止流程（Exit）
   • 将部分任务委派给其他专业Agent（Transfer）
   • 暂停等待人工确认（Pending）

2. 状态持久化困难：当执行过程被中断（如系统崩溃或人工干预）后，难以从断点恢复执行

3. 大模型输出不可靠：LLM生成的计划可能是非结构化的自然语言，需要复杂的解析逻辑

2. 第一次演进：引入状态机和图结构

2.1 从循环到状态机

为了解决控制流僵化问题，我们需要将线性的循环转换为基于状态机的图结构。核心思想是：

1. 将整个流程分解为离散的节点（Node）
2. 通过有向边（Edge）定义节点间的转移关系
3. 使用全局状态（State）保存执行上下文

go复制type PlanExecuteState struct {
    Plan          *TaskPlan
    CurrentTask   *Task
    LastResult    string
    Status        ExecutionStatus
}

type ExecutionGraph struct {
    nodes map[string]NodeFunc
    edges map[string][]string
}

2.2 图结构的优势

这种设计带