[agent] Advanced Multi-model Agents

 

每次都要全部带上！ 这是ReAct最大的成本问题。

具体是这样的

第1次调用LLM

 
输入token数：100
---
任务：找日本电饭锅，给我三个选择
截图：[图片]
请问下一步？

第2次调用LLM

 
输入token数：350
---
任务：找日本电饭锅，给我三个选择
截图1：[图片]
Thought: 我去minimaru.com看看
Action: click(minimaru.com)
Observation: [新截图]
请问下一步？

第3次调用LLM

 
输入token数：800
---
任务：找日本电饭锅，给我三个选择
截图1：[图片]
Thought: 我去minimaru.com看看
Action: click(minimaru.com)
Observation: [新截图]
Thought: 我看到商品列表，点Tiger
Action: click(x=400, y=380)
Observation: [新截图]
请问下一步？

每次调用，历史越来越长，token越来越多。

 

 

 

从 ReAct 到 Action Policy：AI Agent 推理与执行架构的真实演进

Ref: Adv. LLM Agents MOOC | UC Berkeley Sp25 | Multimodal Agents – Perception to Action by Caiming Xiong

摘要

近年来，大型语言模型（LLM）的能力迅速提升，使得 AI Agent（智能体） 从研究概念逐渐走向实际产品。Agent 的核心目标，是能够 理解任务、规划步骤、调用工具，并最终完成复杂任务。

在当前的技术体系中，Agent 的决策机制大致可以分布在一个连续谱上：

  • 一端是 推理驱动的 Agent（Reasoning-based Agent）：每一步都依赖模型推理来决定下一步行动。

  • 另一端是 策略驱动的 Agent（Action Policy / Action Model）：模型已经学习好策略，可以直接根据当前状态选择行动。

本文将系统解释：

  1. ReAct 框架与 Reasoning Agent 的运行机制

  2. Agent 如何与外部环境交互（Tool Call 与 Computer Use）

  3. 推理式 Agent 在工程上的效率瓶颈

  4. Trajectory（执行轨迹）在 Agent 训练中的作用

  5. Action Policy（行动策略模型）如何被训练出来

  6. 工业界常见的 Agent 架构设计

  7. 长任务（Long Horizon Task）的工程解决方案

目标是帮助读者 从系统角度理解 AI Agent 的真实技术结构，而不是只停留在概念层面。

 

一、AI Agent 的基本概念

1.1 什么是 Agent

在 AI 系统中，Agent 指的是能够在环境中自主行动的系统。

一个完整 Agent 通常包含以下元素：

 
任务 (Task)
↓
状态 (State)
↓
决策 (Decision)
↓
行动 (Action)
↓
环境反馈 (Observation)
↓
循环
 

换句话说：

Agent = 决策系统 + 行动系统 + 环境反馈

 

1.2 Agent 与普通 LLM 的区别

普通 LLM：

 
输入 → 模型 → 输出
 

Agent：

 
输入
↓
推理
↓
行动
↓
环境反馈
↓
再次推理
↓
再次行动
 

因此 Agent 具有 循环结构。

 

二、Reasoning Agent：边思考边行动

2.1 ReAct 框架

ReAct（Reasoning + Acting）是最经典的 Agent 推理模式。

核心思想：

模型在推理和行动之间交替进行。

流程如下：

 
任务
↓
Thought（思考）
↓
Action（行动）
↓
Observation（环境反馈）
↓
再次 Thought
 

循环直到任务完成。

 

2.2 一个简单例子

任务：

 
查北京今天的天气，并告诉我是否需要带伞
 

Agent 的执行流程可能如下：

Step 1

输入：

 
任务：查询北京天气并判断是否带伞
工具：
- search_weather
- send_message
 

模型输出：

 
Thought: 我需要先查询天气
Action: search_weather(city="北京")
 

系统调用工具：

 
search_weather("北京")  # 这可能是 现场写编程实现这个功能。
 

返回：

 
Observation: 北京今天小雨，12℃
 

Step 2

新的输入：

 
任务：查询北京天气并判断是否带伞

历史：
Action: search_weather("北京")
Observation: 小雨
 

模型输出：

 
Thought: 北京在下雨，需要带伞
Action: send_message("北京今天小雨，建议带伞")
 

Step 3

模型输出：

 
Action: FINISH
 

任务结束。

 

2.3 Agent 循环的伪代码

while True:

prompt = build_prompt(task, history)

response = llm(prompt)

thought, action = parse(response)

if action == "FINISH":
break

observation = run_tool(action)

history.append({
"thought": thought,
"action": action,
"observation": observation
})
View Code

 

 这个循环就是 Reasoning Agent 的基本结构。

 

三、Agent 如何执行行动

Agent 并不会直接操作现实世界，而是通过 接口系统（Interface Layer） 来执行动作。

目前主流方式有两类。

3.1 Tool Call（工具调用）

Tool Call 指的是：

Agent 调用预定义的函数或 API。

例如：

search_weather(city="北京")
send_email(text="hello")
create_ticket(id=123)
 

运行流程：

 
LLM 输出函数调用
↓
系统解析函数名
↓
调用真实代码
↓
返回结果
↓
继续推理
 

优点：

  • 稳定

  • 快

  • 易控制

缺点：

  • 必须提前写好 API

 

3.2、Computer Use（计算机操作）

当系统没有 API 时，需要 Computer Use。

原理：

 
截图
↓
发送给模型
↓
模型识别界面
↓
输出鼠标 / 键盘动作
↓
系统执行
↓
再次截图
 

例如：

click(x=450, y=380)
type("hello")
scroll_down()
 

循环过程：

屏幕截图
↓
模型决策
↓
执行操作
↓
新截图
↓
继续
 

特点：

优点：

    • 几乎可以操作任何软件

缺点：

    • 速度慢

    • 对 UI 稳定性敏感

 

四、Reasoning Agent 的核心瓶颈

推理型 Agent 最大的问题是 成本和延迟。

原因来自 历史记录（Trajectory）不断增长。

4.1 Trajectory（执行轨迹）

Agent 的执行过程可以表示为：

 
(state1, action1, observation1)
(state2, action2, observation2)
(state3, action3, observation3)
...
 

这条序列称为 Trajectory。

 

4.2 上下文增长问题

每次调用 LLM 时，通常需要提供：

任务
+ 历史记录
+ 当前状态
 

随着步骤增加：

第1步 → 100 token
第2步 → 300 token
第3步 → 800 token
...
 

问题包括：

  • 成本增加: LLM 按 token 计费。
  • 延迟增加: 输入越大，推理越慢。
  • 上下文上限: 所有模型都有 context window。
  • 当历史过长时: 旧信息会被截断。
  • Agent 可能忘记之前做过什么。

 

五、Action Policy（行动策略模型）

为了降低推理成本，工业界开始训练 Action Policy 模型。

其基本形式是：

state → action
 

也就是：

输入当前状态
直接输出行动
 

不需要完整推理循环。

 

5.1 一个例子

输入：

城市：北京
天气：小雨
温度：12℃
 

输出：

带伞
 

整个过程只调用一次模型。

5.2 优点

  • 延迟低

  • 成本低

  • 稳定

5.3 局限

策略模型只能处理：训练时见过的场景

遇到新任务时容易失败。

因此：策略模型通常只用于常见操作。

 

六、Trajectory 如何变成训练数据

推理型 Agent 在运行过程中会产生大量 Trajectory。

这些数据非常有价值。

例如：state → action

 

可以直接作为监督学习样本。

训练流程：

Reasoning Agent 执行任务
↓
记录 Trajectory
↓
筛选成功样本
↓
提取 state → action
↓
训练策略模型
 

这就是 行为克隆（Behavior Cloning）。

 

七、Agent 能力提升的技术循环

现实系统通常形成一个循环：

 
Reasoning Agent
（慢但灵活）
↓
生成 Trajectory
↓
训练 Action Policy
（快但专一）
↓
新任务出现
↓
再次使用 Reasoning Agent
↓
产生新数据
 

这个循环会不断提升系统能力。

 

八、长任务（Long Horizon Task）

长任务指：

需要几十步甚至几百步才能完成的任务
 

例如：

  • 自动完成市场分析

  • 自动写代码并部署

  • 自动完成软件测试

挑战包括：

  1. 上下文膨胀

  2. 错误累积

  3. 任务偏移

 

九、长任务的工程解决方案

目前常见策略包括：

1）大上下文模型

增加 context window。

例如：

1M token
2M token
 

2）历史压缩

将旧记录总结为摘要。

例如：

Step1-10 summary
 

3）Prompt Caching

缓存不变部分的计算。

减少重复推理。

 

4）层级 Agent

把大任务拆成：

 
主 Agent
↓
子 Agent
↓
子任务
 

每个子任务拥有自己的短历史。

 

5）策略模型执行常规操作

常见任务：

Action Policy
 

新任务：

Reasoning Agent
 

6）纠错机制

常见方法：

  • Checkpoint

  • 验证 Agent

  • Human in the loop

防止任务偏移。

 

十、完整 Agent 架构

一个典型工业级 Agent 系统：

 
任务输入
↓
任务规划
↓
任务拆分
↓
子任务执行

　　常规任务 → Action Policy
　　新任务 → Reasoning Agent

↓
历史压缩
↓
结果验证
↓
任务完成
 
 

总结

AI Agent 的核心不是某一个单独技术，而是 多种机制的组合。

关键理解包括：

1 Reasoning Agent 提供灵活性。

2 Action Policy 提供效率。

3 Trajectory 是连接两者的重要数据来源。

4 长任务需要多种工程技术配合。

 

 

以下是2025年上半年的状态。

image

 

  • AgentTrek，通过抓取互联网各种“教程”并实践来收集训练数据。
  • 到后来的 TACO: 利用了合成数据。

Synthetic CoTA Generation pipeline

  1. 先自动标注 via ocr detection, human, etc
  2. 再通过问答模板生成了具体的问答内容。

AguvIs：一种完全依靠视觉输入的统一 Agent，用于自动操作 GUI。

 

posted @ 2026-03-11 14:20  郝壹贰叁  阅读(5)  评论(0)    收藏  举报