大数跨境
0
0

Agent 进阶——如何搞定复杂任务(SOP 规划与 Plan-and-Solve)

Agent 进阶——如何搞定复杂任务(SOP 规划与 Plan-and-Solve) 二进制跳动
2026-01-27
2
导读:Agent 进阶——如何搞定复杂任务(SOP 规划与 Plan-and-Solve)

0. 现象:单步 ReAct 的局限性

上一篇讲的 ReAct 模式(思考-行动-观察)在简单任务(“查库存并发邮件”)上很好用。但如果你丢给它一个复杂目标:
“帮我分析一下为什么昨天晚上 API 延迟突然飙高?”
“帮我写一份关于市面上所有开源向量库的选型对比报告。”
ReAct Agent 往往会:
陷入细节:一上来就去查某一个日志,查着查着忘了原本要干嘛。
死循环:在两个错误的路径上反复横跳。
虎头蛇尾:查了一半就草草给出一个片面的结论。
结论先给:复杂任务不能靠“走一步看一步”,必须先“做计划(Plan)”。
这就是Plan-and-Solve(规划与求解)模式。

1. 核心模式:Planner + Executor(规划者 + 执行者)

与其让一个 LLM 既当爹又当妈(既负责宏观规划,又负责微观调 API),不如把脑子拆开:
Planner(规划者):只负责把大目标拆解成 Step 1, 2, 3。它不调工具,只输出文本列表。
Executor(执行者):就是上一篇的 ReAct Agent。它领取 Step 1,干完汇报,再领 Step 2。

1.1 静态规划 vs 动态规划

静态规划(A 类流水线):一开始生成 Step 1~5,然后死板执行。适合周报生成。
动态规划(B 类探索型 - 推荐):
工程经验:对于故障排查/调研,必须用动态规划

2. 工程实现:Re-Plan Loop(动态重规划循环)

这是一个比 ReAct 更高一层的循环。

2.1 数据结构:Plan State

你需要维护一个“当前计划状态”:
{  "goal": "分析 API 延迟飙高原因",  "steps": [    {"id": 1, "task": "检查 API 网关昨晚的 QPS 和 Latency 监控", "status": "done", "result": "QPS 正常,Latency 在 22:00 突增"},    {"id": 2, "task": "检查数据库 CPU 和 慢查询日志", "status": "todo"}, // 动态调整出来的    {"id": 3, "task": "检查应用服务错误日志", "status": "todo"}  ]}

2.2 流程伪代码

plan = planner_llm.create_initial_plan(goal) 1. 初次规划while not plan.is_finished():    # 2. 取出下一个未完成步骤    current_step = plan.get_next_step()
    # 3. 交给 ReAct Agent 执行(它可能调 API,可能调 RAG)    result = executor_agent.run(task=current_step.task)
    # 4. 关键:把执行结果喂回给 Planner,让它更新计划    # Planner 可能会决定:Step 2 没必要了,或者需要新增 Step 2.5    plan = planner_llm.update_plan(        goal=goal,        current_plan=plan,        last_step_result=result    )print("最终报告:", plan.generate_report())

3. SOP(标准作业程序)的注入

对于企业应用,你往往不想让模型“瞎规划”。你有专家经验(SOP),比如排查故障总是“先看监控 -> 再看 DB -> 最后看日志”。
工程解法:把 SOP 写进 System Prompt。
Planner System Prompt:
你是一个故障排查专家。请根据用户的目标制定排查步骤。必须遵循以下 SOP(标准流程):1. 优先检查核心监控指标(QPS/Latency/CPU)。2. 如果是数据库相关,检查慢查询。3. 如果是应用相关,检查 Error Log。4. 任何结论都必须有数据支撑。根据上一步的执行结果,你可以修改后续步骤。如果问题已定位,可以提前结束。
这样,模型就成了“带着专家脑子的规划师”。

4. 多 Agent 协作(Multi-Agent Collaboration)

有时候一个 Executor 搞不定所有事。比如写研报:
需要一个Researcher(擅长搜 Google/RAG,读长文)。
需要一个Data Analyst(擅长写 Python 代码分析数据)。
需要一个Writer(擅长写漂亮文章)。

4.1 路由模式(Router) vs 握手模式(Hand-off)

Router(中心化):Planner 指挥:“Step 1 给 Researcher,Step 2 给 Analyst。”
Hand-off(去中心化):Researcher 干完了,觉得这事儿该算算了,自己调一个特殊工具 transfer_to_analyst(context),把任务甩给分析师。
工程推荐:起步阶段用中心化 Planner最稳。去中心化很容易跑飞(两个 Agent 互相甩锅)。

5. 记忆管理(Memory)在长任务中的挑战

探索型任务往往很长,Token 很容易爆。
Planner 不需要知道 Executor 调 API 的每一个 json 细节,它只需要知道“结论”。
工程技巧:分层记忆
Executor 记忆:包含详细的 Tool Call、API JSON。任务做完就丢弃(或归档)。
Planner 记忆:只保留 Step N Task + Step N Summary Result。
全局 Scratchpad:维护一个“当前已知的关键事实列表”(如:{"延迟突增时间": "22:00", "DB CPU": "100%"})。所有 Agent 共享这个小黑板。

6. 本篇小结(复杂任务 Checklist)

拒绝单步 ReAct:复杂任务必须“先规划,后执行”。
拥抱动态规划(Re-Plan):走一步看一步,允许 Planner 根据 Executor 的反馈修改后续步骤。
SOP 注入:用 Prompt 把业务专家的流程经验教给 Planner。
记忆分层:Planner 看摘要,Executor 看细节,别让 Context 撑爆。

【声明】内容源于网络
0
0
二进制跳动
15 年 + 技术老兵 架构师|技术总监|科技创业技术合伙人 曾任职苏宁科技、电讯盈科、联想云 专注架构设计与技术落地
内容 739
粉丝 0
二进制跳动 15 年 + 技术老兵 架构师|技术总监|科技创业技术合伙人 曾任职苏宁科技、电讯盈科、联想云 专注架构设计与技术落地
总阅读5
粉丝0
内容739