[GenAI] 重新认识Agent

什么是 Agent

image-20250905141137643

基础篇Agent概念

不是指的 AI 智能体,而是指代理服务器。

image-20250710111024054

代理服务器充当用户和模型交流的中间人。

Agent:

  • 狭义:代理服务器
  • 广义:AI智能体(AI Agent)

什么是AI Agent

AI Agent,中文称之为“AI智能体”,本质上是能自主感知环境,进行规划决策,并最终执行行动智能系统

整个系统基于四大核心能力:

  1. 规划
  2. 工具使用
  3. 行动执行
  4. 记忆管理

image-20250904103242249

1. 规划(Planning)

这可以看作是智能体的认知引擎,它让系统不再是单纯被动的响应,而是具备主动思考解决问题的能力。

规划包含下面几个环节:

  1. 深入理解用户意图与任务目标
  2. 将复杂任务分解成可执行步骤
  3. 制定战略行动与执行时间表
  4. 根据变化与反馈进行动态调整

2. 工具使用(Tools)

让智能体能够访问外部资源。

  1. 熟悉并管理各种工具集
  2. 针对特定任务智能选择工具
  3. 对多种工具整合与编排

3. 行动执行(Action)

这部分强调“把计划真正落地”的机制:根据当前状态选择下一步动作,调用工具或 LLM,并根据返回结果更新状态、决定是否继续。

4. 记忆管理(Memory)

让智能体“记得住”,但又不过载。常见分层:

  1. 短期记忆(会话级):最近若干轮对话/步骤的摘要,用于保持上下文连续
  2. 长期记忆(知识级):文档/知识库向量化检索(RAG)+ 命中片段的引用

Planning

Planning,也就是规划阶段,常用的思考方式有:

  1. Reflection
  2. Self-critics
  3. Chain of thoughts
  4. Subgoal decomposition

1. Reflection

让模型反思、回顾的方式。

模型在执行过程中或结束后,会回看自己的执行过程,总结错误原因与改进策略,并据此修改下一步计划或“经验库”。它关注“为什么没成 / 还能怎么更好”,偏过程级。

常见实现方式:

  1. Step-wise Reflection:每完成/失败一步就反思一次。
  2. Post-hoc Reflection:任务末尾做一次集中复盘,生成“经验片段”写入记忆。
  3. Memory-based Reflection:把高价值的反思写入长期记忆(向量库/摘要),供类似任务召回。

提示模板示例:

你刚完成(或失败)了步骤:{step_summary}
请反思:
1) 目的与偏差?
2) 证据/错误点?
3) 下一步的改进指令(可直接执行的动作或重试参数)。
只输出:{"reason": "...", "fix": "...", "next_action": "..."}

注意点:

  • 设步数/时间上限与重试上限,避免“反思-空转”死循环。

  • 把反思结果结构化,便于控制器读取。

    1. 任务:调用获取天气的工具

      Action: get_current_weather
      Args:   {"location":"北京","unit":"centigrade"}
      
      "不支持的 unit 类型,请传入 celsius / fahrenheit"
      
    2. 接下来就需要对上面的结果进行反思

      你是“反思器”。给定一次工具调用的【动作尝试】和【观察结果】,
      请输出结构化的修正建议,JSON ONLY。
      
      【动作尝试】
      tool: get_current_weather
      args: {"location":"北京","unit":"centigrade"}
      
      【观察结果】
      不支持的 unit 类型,请传入 celsius / fahrenheit
      
      请只输出如下 JSON:
      {
        "reason": "出错原因的简要描述",
        "fix": "如何修复(人类可读)",
        "next_action": "retry | replan | abort",
        "patch": { "用于重试时的参数修正,可选" }
      }
      
    3. 大模型就会进行反思,并且给出一个反思结果

      {
        "reason": "参数 unit=centigrade 不在允许列表",
        "fix": "将 'centigrade' 映射为 'celsius';其他参数保持不变",
        "next_action": "retry",
        "patch": { "unit": "celsius" }
      }
      
    4. 反思控制器,针对模型的反思结果来做下一个步骤

      async function reflectAndHandle(attempt, observation) {
        const prompt = /* 上面的反思提示,插入 attempt/observation */;
        const text = await llm.invoke(prompt);        // 返回 JSON 字符串
        const reflection = JSON.parse(text);          // {reason, fix, next_action, patch?}
      
        if (reflection.next_action === "retry") {
          const patchedArgs = { ...attempt.args, ...reflection.patch };
          return await tools[attempt.tool](patchedArgs);  // 立刻带修正参数重试
        }
      
        if (reflection.next_action === "replan") {
          return await replanner({...context, reason: reflection.reason}); // 触发重规划
        }
      
        if (reflection.next_action === "abort") {
          throw new Error(`终止任务:${reflection.reason}`);
        }
      }
      
  • 只把高价值反思入库(设打分阈值),否则记忆会淤积噪声。

2. Self-critics

让模型扮演审稿人,对“当前答案草稿”按清单逐项检查并给出修改意见,再据此修订。它关注“产物是否过关”,偏结果级。和 Reflection 的区别:

  • Reflection 看“过程是否跑对”;Self-critics 看“最终交付是否合格”。
  • Reflection 产出“下一步计划”;Self-critics 产出“修订后的答案”。

常见实现方式:

  1. 同模两段式:先“解题者草稿”,再“评审者清单”,最后“修订版”。
  2. 双模型(或不同温度):一个负责产出,一个更严苛/低温度负责挑错。
  3. 规则+模型混合:静态校验(schema/单元测试/事实核对)先跑,模型只补充语义性缺陷。

提示模板示例:

草稿:{draft}
请按清单评审:正确性、可证据、覆盖度、风格/格式。
输出 JSON:
{"defects": ["...","..."], "patch_plan": "...", "final_answer": "..."}

注意点:

  • 用可执行检查(单测/数据校验/引用查验)辅助评审,减少“凭空挑错”。
  • 控制评审迭代次数(1~2 轮就足够了),防止“无休止打磨”。
  • 对“需要证据”的结论,强制要求出处/工具调用记录。

3. Chain of thoughts

CoT,中文为“思维链”,该模式让模型在给答案前,先分步写出推理/计算/检查。它能显著提升多步逻辑任务的稳定性。适用于算术、逻辑推理、多跳问答、要“中间结论”的任务。但不涉及外部检索或行动(那是 ReAct/工具调用的事情)。

实现过程:

  1. 触发:在提示中要求“逐步思考(Step-by-step)”,或 few-shot 示范“步骤→结论”的格式。

    提示模板示例:

    请分步骤推理并给出最终答案。
    格式:
    - Steps: 步骤1/2/3(简短)
    - Answer: 最终答案
    
  2. 自一致性(Self-Consistency):让模型在同一题目上独立推理多次(温度>0),只收集每次的“最终答案”,然后用投票/统计选出最可能正确的那一个。

    1. 题目:商店一批苹果分给 4 个班,每班 7 个,还剩 3 个;共有多少个?

      多次的采样结果:[31, 31, 31, 30, 31],投票:31 占 4/5 ⇒ 选 31

    2. 示例代码:

      import { ChatOpenAI } from "@langchain/openai";
      
      const llm = new ChatOpenAI({ model: "gpt-4o-mini", temperature: 0.9 });
      
      const PROMPT = (q) => [
        { role: "system", content: "请先逐步思考,再给出最终答案,最后一行用 `Answer: <值>` 格式。" },
        { role: "user", content: q }
      ];
      
      /**
       * 假设外部已创建好一个可用的 LLM 客户端 `llm`
       * 且有一个 PROMPT(question) 能返回“系统+用户”消息数组,
       * 其中系统提示会要求模型:
       *   1) 先逐步思考(CoT)
       *   2) 最后一行用 `Answer: <值>` 给出最终答案
       */
      
      // 1) 采样一次:向模型发一次请求,返回“整段文字输出”
      async function sampleOnce(question) {
        // llm.invoke(...) 返回的是一个 Message(里头的 .content 是文本)
        const msg = await llm.invoke(PROMPT(question));
        return msg.content; // 例如:多行字符串,包含 Steps... 和最后的 `Answer: ...`
      }
      
      // 2) 抽取“最终答案”:从整段文本中截取 `Answer: ...` 后面的内容
      function extractAnswer(text) {
        // 使用正则匹配 “Answer: <非换行的一串字符>”
        //   - `i` 忽略大小写,所以 `answer:` 也能匹配
        //   - 只取第一个分组 ([^\n]+) 作为答案主体
        const m = String(text).match(/Answer:\s*([^\n]+)/i);
        return m ? m[1].trim() : null; // 匹配不到就返回 null
      }
      
      /**
       * 3) 多数表决:对多次采样得到的答案做投票,返回得票最高的那个
       * @param {string[]} answers        多次采样后抽取出的“最终答案”数组
       * @param {object}   opts
       * @param {boolean}  opts.numeric   是否将答案视为“数值”,做归一化计票
       *
       * numeric = true 的含义:
       *   - 在数字类问题里,同一个答案可能有不同写法,比如 '9' / '09' / '9.0'
       *   - 我们希望它们被当成“相同答案”来计票
       *   - 于是把字符串先转 Number 再转回字符串:'9.0' -> 9 -> '9','09' -> 9 -> '9'
       *   - 注意:如果是 '9 个' 这种非纯数字,Number('9 个') 会变 NaN(会计为 'NaN')
       *     如需更鲁棒,可用更宽松的解析(见下文“可选改进”)
       */
      function majorityVote(answers, opts = {}) {
        // 针对“数字题”的简单归一化规则:字符串 -> Number -> 字符串
        const norm = (a) => (opts.numeric ? String(Number(a)) : a);
      
        // tally 是一个 Map:key 为“归一化后的答案字符串”,value 为计数
        const tally = new Map();
      
        for (const a of answers) {
          if (!a) continue;            // 跳过 null / 空串
          const key = norm(a);         // 归一化(数字题会把 '9.0'/'09' 归一到 '9')
          tally.set(key, (tally.get(key) || 0) + 1); // 累计票数
        }
      
        // 从 tally 中找出“票数最多”的那个答案
        let best = null;
        let max = -1;
      
        for (const [k, v] of tally.entries()) {
          if (v > max) {
            max = v;
            best = k; // k 是“归一化后的答案字符串”
          }
        }
      
        // 返回:最终答案(best)与完整计票表(tally)
        return { answer: best, tally };
      }
      
      
      /**
       * 4) 自一致性主流程:并行采样 k 次 → 抽取答案 → 多数表决
       * @param {string}  question  题目/问题
       * @param {number}  k         采样次数(默认 5)
       * @param {boolean} numeric   是否把答案当做“数字”来归一化计票
       * 当你的题目是数字类(数学/统计/算术)时,不同采样可能给出等价的数值但写法不同:
       * "9" / "9.0" / "09"
       * 如果不开 numeric,这三种写法会被当成三个不同字符串计票,可能导致误判为“分散意见”。
       * 开了 numeric: true 后,会把每个答案先 Number(...) 再 String(...)
       * 从而统一到 "9",计票更稳。
       */
      export async function selfConsistency(question, k = 5, numeric = false) {
        // 并发发起 k 次请求(Promise.all),拿到 k 个“整段输出”
        const samples = await Promise.all(
          [...Array(k)].map(() => sampleOnce(question))
        );
      
        // 把“整段输出”映射为“最终答案”(只取 `Answer: ...`)
        const answers = samples.map(extractAnswer);
      
        // 多数表决:numeric 决定是否数字归一化计票
        const { answer, tally } = majorityVote(answers, { numeric });
      
        // 返回:最终答案、每次的答案列表、计票表、原始整段输出(便于审计)
        return { answer, answers, tally, samples };
      }
      
      // 用例
      const q = "盒子里有 5 颗红球和 7 颗蓝球,取走 3 颗蓝球后还剩多少颗球?";
      const res = await selfConsistency(q, 5, true);
      console.log(res);
      
  3. 展示策略:对用户只展示“结论/要点”,把长推理藏在系统/后台,减少噪声。

注意:

  • 限制步长与字数,避免冗长胡思。
  • 给结构化框架(编号/小标题)few shot,降低漫游。

4. Subgoal decomposition

翻译成中文就是“子目标分解”。顾名思义:把宏大目标拆成可执行、可验证的小目标(带先后关系/依赖),并给每个子目标指派工具/检查。适用于任务跨度大、步骤多、依赖复杂的场景(旅行筹划、数据管道、报表自动化)。

实现方式:

  1. Plan-then-Execute:先产出计划清单,再逐步执行。
  2. DAG/状态机:显式维护依赖,失败可回退重试或Replan。
  • DAG(有向无环图):把一个大任务拆成很多子任务节点(Node),用有向边表示“谁依赖谁”。“无环”保证你能按依赖顺序往前跑。(LangGraph)

  • 状态机(State Machine):给每个节点定义明确的生命周期状态转移条件,让执行可控可观测。

  • 显式维护依赖:依赖关系写在图里(代码/配置里看得见),调度器只运行“所有前置都成功”的节点,失败就阻断后续依赖节点。

    目标:输出“上海 3 日游”行程单。拆分成几个子任务,部分子任务之间会有依赖关系:

    [PickCity] → [GetFlights] → [Itinerary]
          └────→ [GetHotels] ──┘
    
    • PickCity:确定出发/目的地与日期
    • GetFlights:查航班(依赖 PickCity)
    • GetHotels:查酒店(依赖 PickCity)
    • Itinerary:汇总航班+酒店,生成行程(依赖二者)
  • 失败可回退重试或 Replan:节点(图里面的一个任务节点)失败时有三种“兜底策略”:

    • 重试(Retry):同一节点再次执行(带退避、改参数、换副通道)。
    • 回退(Rollback):若该节点产生副作用(下单、写库),先撤销/抵消,把系统退回到安全状态。
    • Replan(重规划):改图——替换失败节点、插入新的“补救节点”、或改路径;然后继续调度。

ReAct模式

AI 智能体核心能力:

  1. 规划
  2. 行动执行
  3. 工具使用
  4. 记忆管理

ReAct 模式则是将这些能力具体落地的一种形式。

ReAct 是两个单词的组合:Reason + Act,也就是“推理 + 行动”的缩写。

ReAct 的完整流程如下:

image-20250904144046302

1. 规划

整个循环从规划(Plan)阶段开始。在这个阶段,AI 智能体通过推理来理解当前情况,分析任务需求,并设计潜在的行动方案。

此阶段利用大语言模型的自然语言处理和生成能力来生成推理轨迹。

在规划阶段,需要做如下的事情:

  1. 解释用户请求或目标
  2. 从记忆中提取相关信息
  3. 制定计划或策略
  4. 选择潜在的工具
  5. 证明所选行动的合理性

2. 行动计划

在完成规划阶段后,AI 智能体进入行动阶段。在该阶段,智能体执行计划中的一个或多个任务,并且通过与环境交互或者利用外部工具来收集信息。

此阶段常见任务如下:

  1. 选择要执行的特定任务

  2. 格式化并执行行动:准备所选任务所需的输入参数,并使用适当的工具或接口执行它。

  3. 等待任务完成

3. 观察

接下来是观察阶段。该阶段智能体会处理任务得到的结果,并进行反馈。

主要流程有:

  1. 接收任务的输出结果
  2. 解析和解释观察结果(Reflection)
  3. 将观察结果整合到记忆中

4. 评估与决策

这是最后一个阶段,在该阶段智能体会花时间反思观察结果,评估当前行动的成功程度,并决定下一个步骤应该是啥。

具体要做的事情如下:

  1. 评估先前行动的成功程度(Self-critics)
  2. 识别错误
  3. 更新内部状态
  4. 决定下一步行动
  5. 生成推理轨迹

该阶段结束后,会重新回到规划阶段,计划和执行下一个行动。


-EOF-

posted @ 2025-11-19 15:08  Zhentiw  阅读(14)  评论(0)    收藏  举报