谢士妞1. 理解AI Agent的两种核心工作模式
在AI应用开发领域，特别是涉及大型语言模型(LLM)的项目中，Plan and Solve（规划求解）与Plan and Execute（规划执行）是两种最基础也最容易混淆的工作模式。作为从业多年的AI开发者，我见过太多项目因为混淆这两种模式而导致性能低下甚至功能失效的情况。
这两种模式的根本区别在于：Plan and Solve是"纯思考型"的工作方式，完全依赖LLM自身的推理能力；而Plan and Execute则是"行动型"的工作方式，必须借助外部工具才能完成任务。就像人类解决问题时，有些问题只需要思考就能解决（如数学题），而有些问题必须动手操作才能完成（如组装家具）。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Plan and Solve：纯推理的问题解决模式
2.1 核心概念与工作原理
Plan and Solve模式的核心在于"纯思考"——LLM接收问题后，先规划解题步骤，然后仅凭自身的知识储备和推理能力逐步解决问题。这种模式不依赖任何外部工具或数据源，所有操作都在模型的"大脑"中完成。
这种工作方式特别适合以下场景：
- 文本分析与理解
- 逻辑推理与计算
- 基于已有知识的问答
- 内容评估与总结
2.2 典型工作流程解析
一个完整的Plan and Solve流程通常包含三个关键阶段：
-
问题拆解阶段：LLM将复杂问题分解为多个可处理的子问题。例如，在简历分析任务中，可能拆解为：
- 提取个人信息
- 识别技能专长
- 总结项目经验
- 评估综合竞争力
-
逐步求解阶段：按照拆解后的步骤，LLM依次解决每个子问题。这一阶段完全依赖模型的：
- 语言理解能力
- 知识储备
- 逻辑推理能力
-
结果整合阶段：将各子问题的解决方案综合起来，形成最终答案。优秀的Prompt设计通常会要求LLM进行自我验证，确保答案的一致性和准确性。
2.3 实战应用案例
案例1：简历信息提取
python复制async def extract_resume_info(resume_text):
prompt = """
请从以下简历文本中提取结构化信息：
1. 基本信息（姓名、联系方式、教育背景）
2. 工作经历（公司、职位、时间段、主要职责）
3. 技能专长（按熟练度排序）
4. 项目经验（名称、角色、成果）
要求：仅基于提供的文本进行推理，不补充任何外部信息。
"""
response = await llm_client.chat.completions.create(
model="gpt-4",
messages=[
{"role": "system", "content": "你是专业的简历分析助手"},
{"role": "user", "content": f"{prompt}\n\n{resume_text}"}
],
temperature=0.3,
response_format={"type": "json_object"}
)
return response.choices[0].message.content
案例2：技术文档评估
python复制async def evaluate_tech_doc(doc_content):
prompt = """
请评估以下技术文档的质量：
1. 逻辑完整性（是否有缺失环节）
2. 技术准确性（是否存在错误描述）
3. 可读性（语言是否清晰易懂）
4. 实用性（是否提供了可操作的指导）
对每个维度打分（1-5分），并给出改进建议。
"""
response = await llm_client.chat.completions.create(
model="gpt-4",
messages=[
{"role": "system", "content": "你是技术文档评审专家"},
{"role": "user", "content": f"{prompt}\n\n{doc_content}"}
],
temperature=0.2
)
return response.choices[0].message.content
2.4 优势与局限性分析
优势：
- 响应速度快（无需等待外部服务）
- 实现简单（只需调用LLM API）
- 成本低（不产生额外工具调用费用）
局限性：
- 无法获取实时数据
- 受限于模型的知识截止日期
- 对复杂计算任务支持有限
提示：在使用Plan and Solve模式时，适当降低temperature参数（0.2-0.3）可以提高推理的准确性和一致性。
3. Plan and Execute：依赖工具的任务执行模式
3.1 核心概念与工作原理
Plan and Execute模式的核心在于"行动"——LLM先规划完成任务所需的步骤和工具，然后实际调用这些外部资源来执行任务。这种模式必须依赖各种工具和服务才能完成工作。
典型的外部工具包括：
- 数据库和知识库
- API服务（天气、股票等）
- 计算引擎
- 文件处理工具
3.2 典型工作流程解析
Plan and Execute模式的工作流程更为复杂：
-
任务规划阶段：LLM分析任务需求，确定：
- 需要哪些工具
- 调用顺序如何
- 参数如何传递
- 错误处理机制
-
工具执行阶段：按照规划依次调用外部工具。这一阶段需要处理：
- 工具认证和授权
- 参数格式转换
- 错误重试机制
- 超时处理
-
结果整合阶段：将各工具返回的结果进行：
- 格式统一
- 冲突解决
- 最终呈现
3.3 实战应用案例
案例1：RAG知识检索系统
python复制async def rag_retrieval(query):
# 规划阶段
plan = """
1. 将查询转换为向量
2. 调用向量数据库检索相关文档
3. 调用关键词检索补充结果
4. 融合两种检索结果
5. 返回最相关的5个片段
"""
# 执行阶段
query_embedding = await embedding_model.encode(query)
vector_results = await vector_db.query(query_embedding, top_k=10)
keyword_results = await bm25_search(query, limit=10)
# 结果融合
combined = merge_results(vector_results, keyword_results)
return combined[:5]
案例2：实时数据查询服务
python复制async def get_weather_report(location):
# 规划阶段
plan = """
1. 验证位置信息有效性
2. 调用天气API获取实时数据
3. 调用日历服务获取节假日信息
4. 生成友好的天气报告
"""
# 执行阶段
if not validate_location(location):
raise ValueError("无效的位置信息")
weather_data = await weather_api.get_current(location)
calendar_info = await calendar_api.get_holidays(location)
# 报告生成
report = generate_report(weather_data, calendar_info)
return report
3.4 关键技术实现要点
-
工具封装：为每个外部工具创建统一的接口
- 参数验证
- 错误处理
- 结果格式化
-
执行引擎：实现可靠的执行机制
- 并行调用优化
- 超时控制
- 重试策略
-
结果处理：设计智能的结果整合逻辑
- 冲突解决
- 优先级排序
- 缓存机制
3.5 优势与挑战
优势：
- 可以处理需要实时数据的任务
- 能够完成复杂操作流程
- 不受模型知识截止日期限制
挑战：
- 系统复杂度高
- 依赖外部服务稳定性
- 实现成本较高
重要提示：在Plan and Execute系统中，必须为每个工具调用实现完善的错误处理机制，包括重试、降级和超时控制。
4. 两种模式的深度对比与选型指南
4.1 核心维度对比
| 对比维度 | Plan and Solve | Plan and Execute |
|---|---|---|
| 核心能力 | 逻辑推理与分析 | 任务规划与工具协调 |
| 外部依赖 | 完全不依赖 | 必须依赖 |
| 延迟特性 | 通常较低（仅模型推理） | 通常较高（含工具调用时间） |
| 知识时效性 | 受限于模型训练数据 | 可获取最新信息 |
| 实现复杂度 | 简单 | 复杂 |
| 适用任务类型 | 分析、评估、推理 | 检索、操作、实时查询 |
4.2 选型决策树
-
任务是否需要实时外部数据？
- 是 → Plan and Execute
- 否 → 进入下一问题
-
任务是否需要执行具体操作？
- 是 → Plan and Execute
- 否 → 进入下一问题
-
能否仅凭已有知识解决问题？
- 是 → Plan and Solve
- 否 → Plan and Execute
4.3 混合使用策略
在实际系统中，两种模式经常需要结合使用。典型的混合流程：
- 初始理解阶段：使用Plan and Solve分析用户意图
- 工具选择阶段：根据理解结果确定所需工具
- 执行阶段：使用Plan and Execute调用工具
- 后处理阶段：再次使用Plan and Solve整合结果
示例：智能客服系统
python复制async def smart_agent(query):
# 第一阶段：理解意图（Plan and Solve）
intent = await analyze_intent(query)
# 第二阶段：确定工具（Plan）
tools = select_tools(intent)
# 第三阶段：执行工具（Execute）
results = await execute_tools(tools, query)
# 第四阶段：生成回复（Plan and Solve）
response = await generate_response(query, results)
return response
5. 常见问题与最佳实践
5.1 典型问题排查指南
问题1：Plan and Solve结果不准确
- 检查Prompt是否清晰明确
- 尝试降低temperature参数
- 增加验证步骤（让LLM自我检查）
问题2：Plan and Execute工具调用失败
- 实现完善的错误监控
- 添加自动重试机制
- 准备备用工具方案
问题3：系统响应速度慢
- 分析性能瓶颈所在
- 考虑并行化工具调用
- 实现适当的缓存策略
5.2 性能优化技巧
-
Prompt工程优化：
- 使用清晰的步骤指示
- 提供示例（few-shot learning）
- 明确输出格式要求
-
工具调用优化：
- 并行化独立工具调用
- 实现请求批处理
- 使用异步IO模型
-
缓存策略：
- 缓存频繁查询的结果
- 实现向量检索缓存
- 考虑语义缓存方案
5.3 安全注意事项
-
工具权限控制：
- 最小权限原则
- 敏感操作二次确认
- 操作审计日志
-
输入验证：
- 严格的输入过滤
- 敏感词检测
- 异常输入处理
-
数据保护：
- 敏感数据脱敏
- 传输加密
- 访问控制
6. 实际项目经验分享
在最近的一个企业知识管理系统项目中，我们深度应用了这两种模式。系统需要处理两种主要请求类型：
-
知识查询：使用Plan and Execute模式
- 先理解用户问题意图
- 检索多个知识库
- 综合各来源结果
- 生成最终回答
-
内容分析：使用Plan and Solve模式
- 评估文档质量
- 提取关键信息
- 生成摘要
- 分类归档
关键收获：
- 明确区分两种模式的使用场景至关重要
- 混合使用时需要清晰的流程设计
- 监控系统必须覆盖两种工作模式
一个特别有用的实践是建立"模式选择器"模块，自动根据请求特征选择适当的工作模式：
python复制class ModeSelector:
def __init__(self):
self.solve_keywords = ["分析", "评估", "总结", "解释"]
self.execute_keywords = ["查询", "获取", "搜索", "最新"]
async def select_mode(self, query):
if any(keyword in query for keyword in self.execute_keywords):
return "execute"
elif any(keyword in query for keyword in self.solve_keywords):
return "solve"
else:
# 默认使用Plan and Solve
return "solve"
这个简单的启发式规则在实际应用中准确率达到了85%以上，显著提升了系统整体效率。