2026年2月5日

优化以实现Agent自主决策

针对“整理客户资料并生成报表”这一具体场景,这是一个典型的**数据流水线(Data Pipeline)**任务。要实现从“模糊指令”到“精准执行”,再到“自主进化”,我们可以分为三个阶段来构建 Agent 的核心逻辑。

以下是针对您三个问题的深度解答和架构建议:

一、 如何生成“可执行步骤”? (Planning & Grounding)

LLM 生成的自然语言计划(如“先查一下数据”)计算机是无法执行的。要生成“可执行步骤”,必须完成从 自然语言结构化调用(Function Calling/JSON) 的映射。

1. 定义“原子动作库” (Atomic Actions)

首先,你必须定义 Agent 能做的具体动作(Tools),并描述清楚它们的输入输出。例如:

  • query_crm(sql_query): 从数据库拉取原始数据。
  • clean_data(raw_data_path, rules): 清洗数据(去重、空值处理)。
  • analyze_metrics(clean_data_path, metric_type): 计算指标(如客单价、复购率)。
  • generate_chart(data, chart_type): 生成图表。
  • render_report(charts, summary, template_id): 组合成 PDF/Excel。

2. 结构化规划 (Structured Planning)

不要让 Agent 输出“第一步做这个”,而是强制要求输出一个 JSON 任务列表(DAG)

System Prompt 示例:

“你是一个数据分析专家。将用户目标拆解为具体的工具调用步骤。 输出格式必须为 JSON List: [{"step_id": 1, "tool": "query_crm", "args": {...}, "output_var": "raw_data"}, ...]

3. 依赖注入 (Context Injection)

在生成步骤时,必须明确数据流向。

  • 错误规划: Step 1 下载数据,Step 2 生成报表(未说明用什么数据生成)。
  • 正确规划: Step 1 下载数据存为 file_A; Step 2 读取 file_A 生成报表。
  • 实现技巧: 使用 LangChain 的 PlaceholderLangGraph 的 State 来管理这些中间变量的文件路径或内存引用。

二、 是否有必要调用历史数据优化拆解逻辑? (Optimization)

答案是:非常有必要。 对于办公场景,业务逻辑通常具有重复性特定性。单纯依靠 LLM 的通用推理能力(Zero-shot)往往不够稳定,且容易产生“幻觉 SQL”或不符合公司规范的报表。

1. 为什么需要?

  • Schema 漂移对齐: 数据库字段变了(如 user_id 变成了 cust_id),Agent 第一次会报错。如果修正后记录下来,下次 Agent 就能参考历史成功案例,直接用对的字段。
  • 偏好对齐: 用户可能喜欢“按季度汇总”而不是“按月汇总”。历史记录能捕捉这种隐性偏好。
  • 降低 Token 成本: 检索历史成功的 Plan 直接复用,比每次让 LLM 从头推理要便宜且快得多。

2. 如何实现? (基于 RAG 的规划器)

建立一个 “执行经验库” (Execution Memory)

  • 存储: 每次任务结束后,存入向量数据库:
    • Input: “帮我分析上个月 VIP 客户的流失率”
    • Plan: [SQL查询语句, Pandas处理逻辑…]
    • Result: Success / Fail
    • Feedback: 用户说“图表颜色太浅看不清”(如果有)
  • 调用: 新任务进来时,先检索 Top-3 相似的历史成功案例(Few-Shot Examples)放入 Prompt。Prompt: “参考以下过去成功的类似任务拆解逻辑,生成本次任务的步骤…”

三、 如何优化以实现 Agent 自主决策核心? (Autonomy)

要让 Agent 从“脚本执行者”变成“自主决策者”,核心在于构建 反馈闭环 (Feedback Loops)自我修正 (Self-Correction) 机制。

1. 引入“观察-修正”循环 (The OODA Loop)

不要试图生成一个完美的线性计划然后执行到底。如果 Step 1 的数据查询结果为空,Agent 应该有能力停下来改写查询,而不是硬着头皮去生成空报表。

  • 架构设计 (LangGraph 模式):
    • Planner Node: 生成初始计划。
    • Executor Node: 执行当前步骤。
    • Evaluator Node (决策核心): 检查执行结果。
      • 如果结果是 Error -> 决策:修改参数,重试 (Retry)。
      • 如果结果是 Empty -> 决策:扩大搜索范围,或者询问用户。
      • 如果结果正常 -> 决策:执行下一步。

2. 动态工具选择 (Dynamic Tool Selection)

让 Agent 根据数据特征自主选择路径,而不是硬编码。

  • 场景: 整理客户资料。
  • 决策逻辑:
    • Agent 先调用 get_data_volume()
    • 决策点:
      • 如果数据量 < 1万行 -> 决策:调用 pandas_tool (内存处理,快)。
      • 如果数据量 > 100万行 -> 决策:调用 sql_window_function (数据库内处理,稳)。
    • 这种“元认知”能力是自主决策的关键。

3. 增加“反思”步骤 (Reflexion)

在生成报表内容前,增加一个 Self-Critique(自我批评)环节。

  • Prompt: “请作为一名资深数据分析师,检查生成的报表草稿。数据是否逻辑自洽?是否有异常值未解释?结论是否由数据支持?”
  • Agent 会基于这个反思,自主决定是否需要回退去重新抓取更多数据来解释异常。

总结架构图

为了实现上述功能,推荐的 Agent 架构如下:

graph TD
    UserInput[用户指令] --> MemoryRAG[检索历史成功案例]
    MemoryRAG --> Planner[规划器 (LLM)]
    Planner --> Plan[结构化步骤 JSON]
    
    subgraph ExecutionLoop [自主决策闭环]
        Plan --> Selector[工具选择器]
        Selector --> ToolExec[执行工具]
        ToolExec --> Observer[结果观察器]
        
        Observer -- 成功 --> CheckNext{还有步骤?}
        Observer -- 失败/数据异常 --> Refiner[策略修正器]
        Refiner -- 修改参数/逻辑 --> Selector
        
        CheckNext -- 是 --> Selector
    end
    
    CheckNext -- 否 --> FinalReview[自我反思/质检]
    FinalReview --> FinalOutput[最终报表]

关键建议: 刚开始不要追求全自动。在 Refiner 环节可以加入 Human-in-the-loop(人工确认),当 Agent 遇到从未见过的报错时,请求人工介入,并将人工的解决方案存入历史数据,Agent 就会越来越聪明。