Agent 学习总整理

本文根据《深入理解 AI Agent：设计原理与工程实践》和《Pi-Agent 源码精读：Python 版》整理，合并了“Agent 是什么”“Agent Loop”和“Tool：Agent 的手脚”三篇笔记。

1. Agent 是什么

1.1 最小工程组成

现代 Agent 可以用一个最小工程公式表示：

Agent = LLM + Context + Tools

这里的加号表示工程组件的组合，不是强化学习中的严格形式化定义。

• LLM 是决策核心，负责理解意图、分析信息、规划和选择下一步行动。
• Context 是模型在每个决策点能够看到的信息，包括系统指令、工具定义、用户消息、历史消息、环境观察、任务状态和必要的记忆。
• Tools 是 Agent 与外部世界交互的接口，既可以提供观察能力，也可以执行行动。

Environment 不属于上述最小公式。它是 Agent 交互的外部对象，可能包括文件系统、数据库、网页、API、App、用户、其他 Agent、虚拟沙盒或物理世界。

Agent 通过观察和行动与 Environment 形成闭环。

1.2 LLM 与 Agent 的区别

一次普通的模型调用可以表示为：

用户输入 → 构建 Prompt → 调用 LLM → 模型输出

它适合翻译、摘要、问答和代码补全等一次调用就能完成的任务。

如果任务需要实时信息或外部操作，系统可以向模型提供工具。例如查询珠海明天天气：

用户目标
→ Context
→ LLM 决定发出 Tool Call
→ Harness 校验、授权和调度
→ Tool 调用天气服务
→ Environment 返回 Observation
→ Tool Result 追加到 Context
→ LLM 根据新信息继续判断
→ 输出最终结果

LLM 负责提出工具调用请求，Harness 和 Tool 负责真正执行。没有实时工具时，模型无法可靠获得当前天气状态。它可以利用用户提供的信息或已有知识回答，但不能凭训练记忆可靠推断当前状态。

“Agent”在不同语境中有不同定义。为了学习 Agent Loop，可以把重点放在是否存在动态的“决策、行动、观察、再次决策”闭环，而不要把 Agent 理解成绝对的二元分类。

2. Context、Tools 与 Memory

可以先用下面的方式记忆三者的关系：

• Agent 当前能看到什么：Context
• Agent 可以观察或做什么：Tools
• Agent 可以跨任务保存并在需要时重新使用什么：Memory

Memory 不等于 Context。Context 是当前一次模型调用实际看到的信息。Memory 通常需要经过持久化、检索和筛选，之后才会被注入 Context。当前任务中的对话历史和工具结果属于工作上下文，长期用户偏好、历史事件和领域知识可以作为持久记忆。

3. Agent Loop

3.1 最小循环

Agent Loop 的最小形态可以表示为：

Context
→ LLM
→ Tool Call
→ Harness
→ Tool
→ Environment
→ Observation / Tool Result
→ Context
→ LLM
→ ……

伪代码如下：

while true:
    response = call_model(context)
    append(response, context)

    if response 没有工具调用:
        输出最终结果
        break

    for tool_call in response.tool_calls:
        result = harness.validate_authorize_and_execute(tool_call)
        append(result, context)

这是最小 Agent Loop 的概念模型。实际系统可以使用状态机、事件驱动或服务端编排实现，不一定真的写成一个简单的 while 循环。

3.2 ReAct

ReAct 可以概括为：

Reasoning：模型判断下一步
→ Acting：发出行动或工具调用
→ Observing：获得环境返回的结果
→ Reasoning：根据新结果再次判断

ReAct 描述的是运行机制，不要求产品把模型的内部思考过程完整展示给用户。面向用户的界面可以展示当前阶段、行动摘要、工具结果和等待状态。

3.3 Environment、Observation 与 Context

它们之间的关系是：

Environment
    ↓ 通过 Tool 观察或改变
Observation / Tool Result
    ↓ 追加或整理
Context
    ↓ 提供给
LLM
    ↓ 产生 Tool Call 或最终回答
Harness 与 Tool 执行
    ↓
Environment 产生新的状态或结果

Tool 是 Agent 与 Environment 之间的接口。Harness 负责把模型的请求变成安全、可执行、可追踪的工具操作。

4. Workflow 与 Agent

4.1 Workflow

Workflow 通过开发者预先设计的代码路径编排 LLM、工具和业务步骤。执行路径可以包含条件分支和多个模型调用，但关键流程由代码控制。

例如订机票的固定流程可以是：

核实身份 → 搜索航班 → 用户确认 → 支付 → 锁定座位 → 发送确认

Workflow 适合步骤清楚、顺序重要、风险较高或合规要求严格的任务。

4.2 Agent

Agent 的执行路径主要根据当前 Context 和 Environment 的反馈动态决定：

目标
→ 判断下一步
→ 执行
→ 观察结果
→ 重新判断
→ 再执行
→ ……

例如订票时，Agent 可能先搜索航班，发现需要登录后再核实身份；发现只有转机方案后询问用户，再根据用户回答调整搜索条件。

Workflow 和 Agent 可以组合使用。固定的关键步骤交给 Workflow，开放式的问题解决和动态搜索交给 Agent。

5. Turn、Trace 与 Loop Engineering

5.1 Trace

Trace 是一次完整的 Agent 运行，从用户提交任务开始，到 Agent 最终结束。一个 Trace 可以包含多个 Turn。

5.2 Turn

在 Pi 的 Agent Loop 实现中，一个 Turn 通常是：

一次模型调用 + 这次调用产生的全部工具执行

如果一次模型输出同时请求 read、grep 和 find，它们属于同一个 Turn。工具执行结果被追加到 Context 后，再次调用模型时，才进入下一个 Turn。

没有工具调用、直接输出最终回答的模型调用，也属于一个 Turn。

示例：

Turn 1：调用模型 → read("auth.ts") → 返回文件内容
Turn 2：调用模型 → read("hash.ts") → 返回文件内容
Turn 3：调用模型 → edit(...) → 返回编辑结果
Turn 4：调用模型 → 没有工具调用 → 输出最终回答

5.3 Loop Engineering

Agent Loop 是底层运行机制，解决“模型如何调用工具并获得结果”。

Loop Engineering 关注更大范围的持续运行和任务完成质量：

• 什么时候算真正完成
• 谁负责验证
• 失败如何恢复
• 最多运行多少轮
• 上下文接近上限时如何处理
• 什么时候请求用户决策
• 什么时候交给人工接管
• 什么时候安全停止

模型声称完成，不等于任务在事实层面已经完成。高质量 Agent 需要通过测试、外部状态、规则检查、浏览器验证、人工确认或其他独立验证手段确认结果。

例如修改网页后，可以运行测试、启动页面，并检查桌面和窄屏布局，而不是只接受模型的“已经完成”。

6. 停止条件

Pi 的模型响应中常见的 stopReason 包括：

• toolUse：模型产生了工具调用，通常继续执行
• stop：模型自然结束，通常准备停止
• length：达到 token 上限，需要结合是否存在可执行工具调用判断
• error：模型调用或执行过程发生错误
• aborted：用户或系统主动中止

生产系统还应加入：

• 最大 Turn 数或最大时间
• 上下文窗口限制
• 连续错误次数上限
• 工具自身的 terminate 信号
• 权限拒绝和人工审批
• 成本或资源预算
• 任务完成后的独立验证

因此，“模型没有继续调用工具”可以作为一种正常结束信号，但它只是运行时约定，不能单独证明任务事实完成。

7. 打断、排队与用户控制

用户可以在 Agent 运行中途参与任务：

• Abort：立即中止当前运行
• Steering：把新的指导插入后续 Turn，改变当前任务方向
• Follow-up：当前循环自然结束后，再追加一个任务

Pi 中的 Steering 和 Follow-up 是 coding agent 在最小 Loop 上增加的产品机制，并非所有 Agent 都必须实现。

Agent 的交互状态也不应只显示一个 loading。任务可能处于：

• 理解任务
• 收集信息
• 规划
• 调用工具
• 等待工具结果
• 检查结果
• 发现失败
• 恢复
• 请求用户决策
• 继续执行
• 验证
• 完成

用户需要知道 Agent 正在做什么、为什么还没有结束、当前卡在哪里，以及自己可以如何补充信息或接管任务。

8. 需要继续研究的方向

• Autonomy：什么时候 Agent 自己做，什么时候询问用户
• Observability：用户怎样理解 Agent 的执行过程
• Controllability：暂停、取消、修改目标和接管
• Trust：用户为什么相信 Agent 的结果和行动
• Recovery：工具失败或判断错误后如何恢复
• Long-running Task：任务持续几十分钟或几天时如何保存状态和交互
• Memory UX：如何让用户理解、查看和管理 Agent 的记忆
• Multi-Agent UX：多个 Agent 协作时如何呈现角色、责任和结果
• Safety：权限、审批、沙盒、审计和提示注入防护
• Verification：如何用独立检查判断任务是否真正完成