AI Agent 智能体¶

Agent 的本质不是"一个聪明的模型"，而是一个循环——让 LLM 反复经历"思考 → 行动 → 观察"直至任务完成。

1. 核心公式¶

Agent = LLM（推理引擎）+ 循环（执行框架）+ 工具（外部能力）+ 记忆（状态持久化）

关键区分：LLM 是无状态的函数调用，Agent 是有状态的循环系统。 单次 LLM 调用只做推理；Agent 的价值在于将推理嵌入一个持续运转的执行循环中，让模型能根据环境反馈不断修正行为。

2. 最简 Agent 循环¶

先看最朴素的 Agent 循环长什么样。以"查天气"为例——用户问"北京今天天气怎么样？"，Agent 需要调用天气 API 才能回答：

[System Prompt] 你是一个天气助手。调用工具获取实时数据后回答，不要编造。
[Tools]         get_weather(city, date) — 查询指定城市的天气

用户: 北京今天天气怎么样？

── 循环第 1 轮 ──────────────────────────
[Act]     调用 get_weather("北京")
[Observe] 返回：晴，最高 25°C，最低 14°C
[判断]    已拿到所需信息 → 退出循环

Agent: 北京今天晴，最高 25°C，最低 14°C。

这就是 Agent 循环的最小形态——Act → Observe → 判断是否结束：

graph LR
    A[Act: 调用工具] --> B[Observe: 接收结果]
    B --> C{完成？}
    C -->|否| A
    C -->|是| D[输出答案]

再看一个需要多轮的例子——"对比北京和上海明天的天气"：

── 循环第 1 轮 ──────────────────────────
[Act]     调用 get_weather("北京", "明天")
[Observe] 返回：多云，22°C / 13°C

── 循环第 2 轮 ──────────────────────────
[Act]     调用 get_weather("上海", "明天")
[Observe] 返回：小雨，19°C / 15°C
[判断]    两个城市数据都拿到了 → 退出循环

Agent: 明天北京多云 22°C，上海小雨 19°C。北京更暖和且不下雨。

循环的价值就体现出来了：一次 LLM 调用搞不定的事，多轮迭代就能搞定。

但这个朴素循环有几个明显的短板：

以下三种经典架构分别解决这三个短板。

3. 循环的三种优化¶

3.1 ReAct：加入显式推理¶

ReAct（Reasoning + Acting）¹在每轮 Act 之前插入一个 Think 步骤——让模型先把推理过程写出来，再决定行动：

用户: 北京今天天气怎么样？

── 循环第 1 轮 ──────────────────────────
[Think]   用户问的是实时天气，我需要调用天气工具，参数是城市="北京"
[Act]     调用 get_weather("北京")
[Observe] 返回：晴，最高 25°C，最低 14°C
[判断]    已拿到所需信息 → 退出循环

Agent: 北京今天晴，最高 25°C，最低 14°C。

graph LR
    T[Think: 推理] --> A[Act: 调用工具]
    A --> O[Observe: 接收结果]
    O --> C{完成？}
    C -->|否| T
    C -->|是| D[输出答案]

解决了什么：推理过程可见了。Think 步骤暴露了模型的决策逻辑——为什么选这个工具、传什么参数、当前离目标还差多远。出错时可以直接定位是"想错了"还是"做错了"。

3.2 Plan-and-Execute：先规划后执行¶

当任务有多个步骤时，ReAct 每一轮都重新推理"接下来干什么"，开销高且容易在中途偏离目标。Plan-and-Execute 的思路是先用一次推理生成完整计划，再逐步执行：

用户: 帮我规划一个北京三日游

── 规划阶段 ──────────────────────────
[Plan]  1. 搜索北京热门景点
        2. 查询各景点开放时间和门票
        3. 根据地理位置规划每日路线
        4. 查询天气，调整户外行程

── 执行阶段 ──────────────────────────
[Execute Step 1] 搜索北京热门景点 → 故宫、长城、颐和园...
[Execute Step 2] 查询开放时间 → ...
[Execute Step 3] 规划路线 → ...
[Execute Step 4] 查询天气 → 第2天有雨，将长城换到第3天
[判断]  所有步骤完成 → 输出行程

graph TD
    P[Plan: 生成步骤列表] --> E1[Execute Step 1]
    E1 --> E2[Execute Step 2]
    E2 --> EN[Execute Step N]
    EN --> R{需要重规划？}
    R -->|是| P
    R -->|否| F[输出结果]

解决了什么：规划一次，执行 N 步。不用每步都重新推理全局目标，token 效率高，适合步骤明确的结构化任务。权衡是灵活性下降——如果中途发现计划不对，需要显式的重规划机制。

3.3 Reflexion：从失败中学习¶

前两种模式在单轮循环内能处理错误（观察到报错 → 换个方式重试），但如果整个任务失败需要从头再来，之前的经验就丢了——每次重启都是白纸一张。Reflexion²在执行循环外面再套一层反思循环——失败后先总结"为什么失败"，把教训写进记忆，下次执行时带上这些教训：

── 第 1 次尝试 ──────────────────────────
[执行 ReAct 循环] → 失败（测试未通过）
[Reflect] 失败原因：没有处理空列表的边界情况
[写入记忆] "注意：该函数需要处理空列表输入"

── 第 2 次尝试（带着记忆重来）──────────
[执行 ReAct 循环] → 成功 ✓

graph TD
    E[执行循环] --> R{成功？}
    R -->|是| F[完成]
    R -->|否| RF[Reflect: 分析失败原因]
    RF --> M[将教训写入记忆]
    M --> E

解决了什么：Agent 级别的"经验学习"。不是随机重试，而是结构化地提取失败经验，让每次重试都比上次更聪明。

4. 循环中的关键机制¶

4.1 工具调用¶

循环的 Act 步骤依赖工具调用能力。现代 Agent 通过 Function Calling 或 MCP 调用工具，或通过 Agent Skills 编排复合工作流，工具的输出成为下一轮 Observe 的输入。

4.2 状态管理与 Context Compact¶

每一轮循环都在累积上下文——工具调用的参数和返回值、推理过程、中间结果，全部堆在同一个上下文窗口里。长期状态靠记忆系统持久化。

当上下文逼近窗口上限时，有两种应对策略：

Context Compact 的典型流程：上下文占用超过阈值（如 70%）→ 触发压缩 → 模型生成当前进度的结构化摘要（已完成什么、待完成什么、关键中间结果）→ 用摘要替换原始上下文 → 循环继续。代价是丢失细节——被压缩掉的早期推理过程和工具输出无法再回溯。

4.3 终止条件¶

循环何时停止是一个不平凡的问题——停得太早，任务没做完；停得太晚，浪费 token 甚至造成破坏。

实践中这四种策略通常叠加使用：模型自主终止是主路径，资源熔断做兜底，Hook 拦截关键操作，人类保留最终中断权。

5. 从单循环到多循环¶

单 Agent 的能力天花板受限于单一上下文窗口和串行执行。突破方式是将多个循环组合：

多循环系统的详细架构和各产品实现对比见 Subagent 实践。

6. 安全与约束¶

Agent 循环的自主性带来安全风险——循环可能失控（无限执行）、越权（工具滥用）、被操纵（提示注入）。

详细的安全研究与治理框架见 AI 安全与治理。NVIDIA OpenShell 的沙箱方案见 NeMo Agent Toolkit。

7. 趋势：循环的进化方向¶

• 长运行持久循环：Agent 从"一次性任务"走向"持续运行的守护进程"。Springdrift（2026.4 arXiv）提出可审计的持久运行时，具备案例记忆、规范性安全保障和环境自我感知
• Harness Engineering³：当 Agent 循环失败时，不是优化 prompt，而是问"循环缺什么能力/上下文/结构？"然后补全之。OpenAI 的 Dark Factory 模式（>100 万行代码库、~10 亿 token/天、0% 人工参与）验证了这一思路
• 自主计算机使用：循环的 Act 步骤从 API 调用扩展到 GUI 操控——Agent 直接操作屏幕完成任务（Claude Computer Use、Browser Agent）。浏览器场景的技术方案见 AI 浏览器自动化

相关文档¶

参考资料¶