agent的初步理解

发表于 分类于 ， 阅读次数： Waline： 本文字数： 2.3k 阅读时长 ≈ 2 分钟

1. 什么是 AI Agent？

如果把传统的大语言模型（LLM）比作一个 “ 缸中大脑 “——知识渊博、文笔出众，但只能被动回答问题、无法主动与真实世界交互；那么 AI Agent（智能体） 就是给这个大脑装上了眼睛、双手和记事本，让它能够自主感知环境、进行规划并使用工具去完成复杂的现实目标。

Agent 的核心架构通常由四大支柱构成：

  • 大脑与规划（Planning）： 负责任务分解、自我反省与路线选择。比如面对复杂任务时，能先列出第一步、第二步，遇到错误还能主动纠偏。
  • 感知（Perception）： 接收并理解来自环境或用户的输入信息（文字、图片、环境传感器数据等）。
  • 记忆（Memory）：
    • 短期记忆：当前的对话上下文。
    • 长期记忆：通过外挂数据库或向量检索，记住长期的历史经验与知识。
  • 行动与工具（Action / Tools）： 调用外部能力的能力，如调用计算器、搜索引擎、API 接口或执行代码。

例如接下来我举一个场景： 你让 AI 助手完成一项任务——“ 查询明天上海的天气，如果下雨，就在日历上添加带伞提醒并发送邮件给同事 “。

请问：

AI 在真正执行前，将整个流程拆解为 “①查天气 -> ②判断是否满足下雨条件 -> ③创建日历事件 -> ④发邮件 “，这体现了哪个支柱？（Planning）

AI 实际去调用天气接口和邮件系统的操作，又属于哪个支柱？（Action / Tools）

2. 经典设计模式与工作流

2.1 设计模式

ReAct 模式（Reason + Act）

Agent 不是一次性给出答案，而是进入 “思考（Thought） $\rightarrow$ 行动（Action） $\rightarrow$ 观察反馈（Observation）“ 的循环。

生活类比：就像大厨调汤，尝一口（观察） $\rightarrow$ 发现有点淡（思考） $\rightarrow$ 加少许盐（行动） $\rightarrow$ 再尝一口确认，而不是闭着眼睛把所有调料一股脑全倒进去。

反思自省机制（Reflection）

Agent 会在执行任务后对结果进行自我审查（比如 “ 这段代码是否有语法错误？”” 答案是否偏离了用户要求？”），发现问题后自动重新规划和修正。

多 Agent 协作网络（Multi-Agent System）

面对超大型任务时，单个 Agent 容易遗忘或混乱。通过让多个特定角色的 Agent（如 “ 产品经理 “、” 后端开发 “、” 代码审查员 “）互相沟通、交接产出，协同完成复杂任务。

2.2 提问问题

例如某 AI 编程助手接收到了一个写爬虫脚本的任务。

  1. 它先写好第一版代码并运行，终端报错 403 Forbidden；
  2. 它读取报错信息后，推断 “ 这是目标网站开启了反爬拦截 “，于是修改代码加上了自定义 User-Agent 请求头并重新执行；
  3. 运行成功后，它再把代码发送给专门负责安全审核的另一个专用 AI 检查是否存在注入漏洞。

步骤 (1) 和 (2) 中，” 运行报错 $\rightarrow$ 分析原因 $\rightarrow$ 修改请求头再试 “ 主要体现了哪种机制？（ React 模式）

步骤 (3) 中，把代码转交给专门的安全审核 AI，属于哪种协作模式？ （Multi-Agent System 模式）

ReAct 模式 和 Reflection 的区别是什么：

ReAct 就像边看导航边开车：遇到封路（观察） $\rightarrow$ 决定掉头（思考） $\rightarrow$ 打方向盘（行动），关注的是当下这一步怎么走。

Reflection 就像考试交卷前的检查：整张卷子已经写完了，跳出来以阅卷老师的视角通篇检查一遍，发现有一道题漏了负号，再擦掉重新计算。

实践中的组合：一个高级 Agent 通常用 ReAct 去执行任务（查资料、写代码），产出完整草稿后，再用 Reflection 去自我审查（检查代码逻辑、优化性能）。

3. Agent 落地实践

3.1 纯手写简易 Agent

  • 仅用 Python 代码调用大模型的 Function Calling（工具调用）接口。
  • 核心：自己写一个 while 循环：LLM 决策工具 -> 本地执行函数 -> 结果反馈给 LLM -> 循环直到得出最终答案。亲手跑通一次，你就能彻底掌握 Agent 的底层运转本质。

3.2 掌握主流开发框架

  • 状态图与工作流派（当前工业界主流）：LangGraph（将 Agent 的状态、循环和条件分支建模为有向图，非常适合构建可控、复杂的企业级应用）。
  • 多智能体协作派：AutoGen / CrewAI（擅长快速配置多个具有不同角色定义的 Agent 进行多轮对话与协作）。

3.3 可观测性与评估

  • 轨迹追踪（Tracing）：使用如 LangSmith、Arize Phoenix 等工具，记录 Agent 每一步的 Thought、Action 和 Observation，方便可视化调试。
  • 基准评估（Evaluation）：评估 Agent 的工具调用准确率、任务完成率，防止 Agent 产生幻觉或陷入死循环。

4. 反思

你正在开发一个自动化运维 Agent。在测试过程中，你发现 Agent 在面对某些复杂服务器报错时，偶尔会陷入 “ 反复调用查日志接口 “ 的无限死循环。

  • 为了还原 Agent 在死循环中的完整心智过程（它每一步到底想了什么、查到了什么），你最需要依赖 “ 代码单元测试（Unit Test）” 还是 “ 轨迹追踪（Tracing / Observability）”？
    • Tracing / Observability
  • 从工程防护的角度，通常可以在 Agent 的工作流或框架中增加什么最直接的限制，来防止它耗尽 API 额度？
    • 最大迭代/循环次数限制。
    • 最有效也最直接的兜底机制就是设置最大步数上限（比如循环超过 3 次或 5 次直接中断，返回错误或转交人工）。这能从根本上避免因为死循环或逻辑漏洞耗尽 API 额度。