AI 与 Agent 基础学习

AI知识学习：

第一章：Agent 基础架构

Agent 到底是什么？

Agent 的第一层：Model（模型），即LLm。

模型主要承担的任务为理解任务，根据 Context 推理，再决定下一步 Action。

model（LLM）在agent里面起一个类似于大脑的作用。

Agent 的第二层：Instructions（系统提示词，指令）

instructions类似于告诉你：你是谁？你应该干什么？有哪些规则？什么时候应该调用什么工具？什么事情不能做？

在agent里面，Instructions 赋予了agent具体的“身份”、“任务目标”和“行动准则”，让一个通用的模型蜕变成为一个能够自主规划、调用工具并解决复杂问题的智能体。

Agent 的第三层：Tools（工具）

由于LLM本身不具备直接使用，控制电脑的能力，因此需要Tools。

工具将把 Agent 从：“知道事情。”升级成：“能够做事情。”

注意在agent中，LLM负责决定调用哪个工具，真正执行工具的是Runtime。模型通常不是工具执行者。

Agent 的第四层：Context（上下文）

模型每一次执行，其实只能看到context，模型不知道 Context 之外的东西。

同时受限于模型的最大上下文长度，系统不可能直接将所有输入文件内容，这样不仅会快速塞满模型本身的上下文限制，还会分散模型注意力，因此需要引入Context Engineering（上下文工程）

Context也是 Coding Agent 最核心的工程问题之一。

Agent 的第五层：State（状态）

可以在关键节点保存agent的状态，使当出现突发情况的情况下程序崩溃，不至于需要重新开始。

例如：读取 Checkpoint

↓

发现：

代码已生成

依赖已安装

测试失败

错误日志已记录

↓

从修改代码继续，其中就是state的作用。

Agent 的第六层：Memory（记忆）

由于大模型本质上是无状态（Stateless）的——每一次向模型发送请求，对它来说都是一个全新的起点。Memory 的核心作用，就是让 Agent 摆脱“金鱼脑”，具备跨轮次甚至跨会话的连贯性、反思能力与个性化认知。

同时Memory（记忆）也分为短期记忆与长期记忆：

短期记忆：位于Agent 当前正在处理任务时的工作区（Scratchpad），不能跨对话，永久保存。

短期记忆只存在于一个单独的对话窗口里面，直接存放在当前请求的 Context Window，不进硬盘只在内存里面。

长期记忆：定位：跨会话、可永久保存的知识与经验库。

物理载体为外部存储引擎（如向量数据库 Milvus/Pinecone、Redis、SQLite 或图数据库），硬盘。

Agent 的第七层：Environment（环境）

agent的常见环境基本可以分为四类：操作系统 / 代码沙箱；浏览器 / GUI 界面；API 与微服务网络；虚拟仿真 / 游戏。

Agent 最终必须与真实世界发生交互。

agent中的其他重要概念：

Agent Runtime（智能体运行时 / 执行引擎）：指的是负责把 Prompt、LLM、Memory、Tools 和 Environment 串联起来，让整个智能体真正“跑起来”的调度与控制中枢。

runtime中囊括了：Control Loop,State ，Checkpoint ，Retry，Permissions。

MCP：MCP 指的是 Model Context Protocol（模型上下文协议）。

MCP旨在统一大语言模型（LLM / Agent）与外部数据源、工具（Tools）、开发环境及企业系统之间的通信规范。

目前 MCP Server 的三个重要能力可以先记住：Tools，Resources，Prompts

其中 Tools 是模型能够执行的函数能力；Resources 可以向模型提供文件、数据库 schema 等上下文数据；Prompts 则用于暴露结构化消息和工作流模板。Model Context Protocol

现在先知道它们的位置，后面会专门实现 MCP Server。

定性流程应该优先使用 Workflow，不确定性决策才应该交给 Agent。

Agent 本质上是一个不断调用 LLM，并根据 LLM 的输出决定“回答还是执行工具”的循环。

Single Agent 的内部工作机制

一个 Single Agent（单智能体） 的内部工作机制，本质上是一个由运行时（Runtime）驱动的“感知，规划 , 行动 ,观察 ,反思”自主反馈闭环（Closed-Loop System）。Runtime 是中心调度者。

Tool 到底是怎么告诉模型的？

这是 Tool Calling 的核心。

假设我们有 Python 函数：

def get_weather(city: str):

return query_weather_api(city)

LLM 并不能直接看到 Python 函数。

所以必须把它描述成一种：

Tool Schema。

一般tool schema都是一种固定的JSON格式，例如如下：

{

"name": "get_weather",

"description": "查询指定城市当前天气",

"parameters": {

"type": "object",

"properties": {

"city": {

"type": "string",

"description": "城市名称"

}

},

"required": ["city"]

}

}

当模型看到此类tool schema的描述时，就会按格式如此理解：

Tool Name:

get_weather

用途：

查询天气

参数：

city: string

因此就可以理解用户需求，执行调用天气查询工具，再由runtime将查寻结果返回模型。

JSON Schema 为什么重要？

Tool 的参数一般需要一种明确的结构。原因是模型不能随便输出自然语言文字，这样会导致程序没办法稳定处理。

因此需要一种结构化输出手段保证程序可以稳定处理问题，通常使用JSON Schema。

json schema 用于约束：字段叫什么，字段是什么类型，哪些字段必须存在，允许哪些值。

同时对于一个agent的schama设计，会很影响agent的智能程度。如果schama里面的字段描述模糊，会导致模型做选择时候的错误率明显提升，反之如果描述清晰，模型就会更容易做出选择，选择准确率也会提升。

一个 Agent 可能有很多工具，比如 Coding Agent：read_file

write_file

search_code

run_command

git_diff

git_status

run_tests，

而模型每次都要做：

当前任务是什么？

当前 Context 里缺什么信息？

那个工具最合适？

参数应该是什么？

因此从本质而言，Tool Selection 也是一个推理任务。

Agent Loop（智能体循环）

Agent Loop（智能体循环） 本质上就是一段由代码驱动的 while 循环。它是让大模型从“回答一句话就结束”，蜕变成“能够自主一步一步尝试、调用工具、直到把任务彻底搞定”的动力心脏。

Agent Loop 每一轮循环在干什么？

在一个标准的 Agent Loop 中，每一次循环迭代（Iteration）都会顺序经历 4 个步骤：

1.上下文组装：读取 Prompt + 历史工具反馈 (Observation)并将它们打包发给大模型。

2.决策与思考：LLM 思考当前现状，判断是输出答案还是调用某个工具。

3.工具执行：Runtime 拦截到工具调用指令，真正去发 HTTP 请求、查库或执行代码。

4.环境反馈：捕获执行结果或报错日志追加到下一轮提示词里面。

在每一轮循环后会进行一个whlie判断：判断是否触发终止条件，是 ──► 退出循环，输出最终结果 (Final Answer)，

否 ──► 进入下一轮迭代 (Next Loop)

循环什么时候会停下来？（终止边界）

如果写过 while 循环就知道，没有终止条件的循环会导致死循环。Agent Loop 依赖以下 4 种条件跳出循环：

目标达成（Task Complete）：LLM 认为手头的信息已经足以解答用户的问题，主动输出了 Final Answer。

最大步数熔断（Max Iterations）：防止大模型在某个死胡同里无限循环刷爆 API 费用（例如硬性限制最多循环 10 次）。

人工接入审批（Human-in-the-Loop）：遇到危险操作（如删除数据库、转账）时，主动暂停循环，等待人类在前端确认。

致命异常退出（Fatal Error）：连续重试多次均宣告失败，触发安全降级机制。

Agent 为什么需要 Observation（环境反馈）？

首先observation（观测值 / 环境反馈） 指的是 Agent 在向外部环境执行某个动作（Action，如调用 API、运行 Bash 脚本、查询数据库、点击网页）后，外部系统实际返回给 Agent 的真实数据、输出内容或错误日志。

经典的 ReAct（Thought ，Action ，Observation） 智能体决策范式中，如果说 Thought 是“脑中规划”，Action 是“伸出手脚去操作”，那么 Observation 就是“眼睛和耳朵接收到的真实反馈”。

没有 Observation 的系统是一个“盲盒式”的开环系统（Open-Loop）；而有了 Observation，Agent 才真正构成了自主感知与自适应的闭环系统（Closed-Loop）。

ReAct：

react agent：核心思想为不要让模型一次性想完所有事情，而是让它边行动、边获取信息、边调整下一步。

不同于传统大模型的“一直思考最后得出结论的方式”，ReAct是先想，再看结果，再想，再看结果，更类似于人的思维。

ReAct 最大的价值是什么？

ReAct（Reasoning + Acting，即“推理 + 行动”）最大的价值，是打破了单纯“空想”与单纯“盲动”的局限，让大模型学会像人类一样“边想边做、看结果再修正”，从而能够解决复杂现实问题并大幅降低幻觉。

其核心价值具体体现在三个方面：动态纠错与闭环反馈（最关键的价值），引入外部客观世界（消除幻觉），过程透明可追溯（可解释性强）。

runtime在agent里面到底代表着什么？

在 AI Agent（智能体）的语境下，Runtime（运行时） 可以通俗地理解为：Agent 的“操作系统”与“发动机”。

如果把大语言模型（LLM）比作一个拥有极高智慧的大脑，把 Prompt 和知识库比作记忆与设定，那么 Runtime 就是负责让这个大脑真正动起来、调度肢体、感知环境并执行任务的“身体神经系统”。

用一句话理解就是：大语言模型本身是静态且无状态的（你发一段文本，它回一段文本，它自己不能主动上网、不能读写数据库、也不会自己循环跑程序），而Runtime 就是包裹在模型外面的那套调度程序。

runtime负责以下五点：接收用户的输入；把上下文和工具说明整理好喂给模型；解析模型做出的决策（例如“我需要调用天气 API”）；真正去发起网络请求拿到结果；把结果再次喂回给模型，不断循环直到任务彻底完成。

runtime在agent里面具体负责着什么？

Agent Runtime 通常包含以下 4 个核心职责：

主执行循环（ReAct / Event Loop）： 控制 Agent 的思考-行动节奏（思考 $\rightarrow$ 决定调用工具 $\rightarrow$ 执行工具 $\rightarrow$ 观察结果 $\rightarrow$ 继续思考）。

状态与上下文管理（State & Memory）： 追踪当前会话的上下文、历史交互记录、短期工作记忆与长期记忆的存取。

工具与沙箱调度（Tool Execution & Sandboxing）： 真实地执行 Python 代码、查询数据库、调用外部 Web API，并做安全隔离。

中断与安全介入（Human-in-the-loop）： 当执行敏感操作（如删除文件、转账）时，暂停执行等待人工确认，之后继续从当前断点恢复。

总结来说：LLM 提供智力，Prompt 提供指令，而 Runtime 提供了让程序能够“自主运转、与外界交互、维持状态”的执行宿主环境。

wokflow（工作流）：

Workflow:代码决定路径

Agent:模型决定路径

工作流也分简单与复杂：

简单：Sequential Workflow（顺序工作流）

即按设定好的顺序按部就班依次完成到最后一步。

特点：简单。可靠。容易测试。

复杂：Parallel Workflow（并行工作流）

很多任务其实可以同时做。

例如：

用户：

分析一家公司的情况。

需要：

财务数据

↓

股票信息

↓

新闻资料

↓

产品信息

这些互相独立。

架构：

Task

↓

┌────────┼────────┐

↓ ↓ ↓

Finance News Product

↓ ↓ ↓

└────────┼────────┘

↓

Summary

优势在于减少任务时间，串行完成任务

但是注意：

Multi-Agent 不等于并行。

很多人误解：

多 Agent = 更强。

实际上：

只有任务存在独立性时，多 Agent 才有优势。

Router 架构（路由架构）

在 AI Agent 体系中，Router（路由架构） 是最经典、最高效的设计模式之一。

如果把 Agent 系统比作一家医院，Router 就是“分诊台（预检台）”：它根据用户的输入（症状），快速判断该把请求分发给哪一个专门的专家 Agent、工具集或预设的工作流（专科医生）去处理。

为什么我们需要router架构？

直接让一个全能的通用 LLM 面对所有任务，通常会遇到三个致命痛点：

Prompt 污染与性能下降：塞入 50 个工具的描述，模型注意力会被分散，极易出现工具误调用。

成本与延迟过高：简单问题（如查汇率）也使用昂贵的巨型模型，速度慢且浪费 Token。

专业深度不足：写代码需要 Code-specialized 提示词/模型，写法律合同需要法务知识库，混在一个 Agent 里难以调优。

因此我们使用router，就是为了不要让所有 Agent 都看到所有问题。

Router 架构的核心逻辑是：通过“分流”，实现任务特化、降本增效。

Conditional Workflow（条件分支）

类型与在rag里面，搜索到资料后会判断资料是否足够：足够就回答，不足够就重新搜索。

它的核心作用是：根据上一步的执行结果、用户的输入意图或大模型的分类判断，动态决定接下来走哪一条流程分支，而不是按部就班地从头跑到尾。

这里出现了一个重要思想：大模型判断加程序控制。

State Machine（状态机）

状态机（State Machine） 是一种用来管理事物“当前处于什么状态”以及“在什么条件下切换到下一个状态”的数学模型与设计模式。

用一句大白话解释：它规定了一个系统在任何时候只能处于一个明确的“状态”，并且只有在收到特定的“事件（输入）”时，才能按照规则跳转到“下一个状态”。

为什么需要状态机？

在复杂业务中（如电商订单、游戏角色控制、AI Agent 循环执行），如果不使用状态机，代码里会充斥着大量的布尔值判断（is_paid、is_shipped、is_cancelled）和嵌套的 if-else。这容易导致非法状态跃迁（例如：直接从“待支付”跳转到“已收货”，跳过了支付步骤）。

状态机能确保流程严格可控、边界清晰、不可越级跳步。

状态机在 AI Agent / LLM 中的应用

现在的复杂 Agent 框架（如 LangGraph）本质上就是一个图驱动的状态机：

State（全局状态）：保存当前对话历史、提取到的参数、中间工具调用结果。

Nodes（状态节点）：大模型生成、调用外部 API、人工确认等步骤。

Edges（转移条件）：模型判断任务是否完成。若未完成，跳转回工具调用状态；若完成，流转到最终输出状态并结束。

LangGraph：

LangGraph 为什么叫 Graph？

因为它把 Agent 系统表示成：Node（节点）+ Edge（边）

节点表示执行步骤，而边表示状态转换。

LangGraph 之所以带一个 "Graph"（图） 字，是因为它彻底抛弃了早期 LangChain 那种“单向线性的链条（Chain）”模型，而是把整个 AI 流程建模成数学与计算机中的 有向图（Directed Graph）。

在传统的 Chain（链） 中，数据只能像流水线一样单向流动：输入 -> 步骤A -> 步骤B -> 步骤C -> 输出（有向无环 DAG）。但现实中真正的智能体（Agent）需要：

循环与重试（Cycles）：代码写错了，报错后需要拿报错信息回退并重新写，直到通过测试。

多分支与汇聚（Branching & Merging）：根据不同意图分流到不同专家节点，最后汇总结果。

人类介入与暂停（Human-in-the-loop）：运行到某一节点时挂起等待人工审批，确认后再恢复流转。

这些复杂的非线性、带环（Looping）的流转逻辑，唯有图（Graph）结构能自然表达。

LangGraph 的三大基石：State + Node + Edge

在 LangGraph 中，所谓的 State Graph（状态图） 就是把“图结构”与“全局状态机”融合在一起：

1. State（全局共享状态）：一个随图流转的集中式数据结构（类似字典/TypedDict），用来存对话历史、提取变量、工具调用结果等。

2. Nodes（节点 / 顶点）：图上的一个个处理单元（Python 函数），负责接收当前 State，做一些处理（比如调大模型、查数据库），然后返回要更新的 State 字段。

3. Edges（边 / 转移路线）：决定数据下一步流向哪一个 Node。

普通边（Normal Edge）：执行完 Node A，无条件固定跳到 Node B。

条件边（Conditional Edge）：根据当前 State 的内容做判断，动态决定下一个跳到 Node B、Node C 还是结束（END）。