Agent智能体架构 第二章 单智能体架构

单智能体架构 (Single Agent) 这是最简单的形式指代的是一个智能体独立完成所有任务。代表AutoGPT、BabyAGI 的早期版本。优点上下文一致性强没有协作开销。缺点能力受限于单一模型的上下文窗口难以处理超长链条的复杂任务1. 单智能体架构的内部结构比“一个智能体”更复杂虽然叫“单智能体”但其内部依然是模块化设计否则连简单任务都无法闭环。典型结构如下┌─────────────────────────────────────────┐ │ 单智能体 (Single Agent) │ ├─────────────────────────────────────────┤ │ 感知模块 → 规划模块 → 记忆模块 → 执行模块 │ │ ↑ ↓ ↑ ↓ │ │ └──────────┴──────────┴──────────┘ │ │ 循环迭代直到任务完成 │ └─────────────────────────────────────────┘ ┌─────────────────────────────────────────────┐ │ 智能体执行流程 │ ├─────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ │ │ │ 用户指令 │ │ │ └──────┬──────┘ │ │ ↓ │ │ ┌─────────────┐ │ │ │ Agent解析任务│ │ │ └──────┬──────┘ │ │ ↓ │ │ ┌─────────────────┐ │ │ │ 是否需要工具/ │ │ │ │ 多步推理 │ │ │ └────────┬────────┘ │ │ │ │ │ ┌────────┴────────┐ │ │ ↓ ↓ │ │ 是 否 │ │ ↓ ↓ │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ 调用工具/ │ │ 直接调用 │ │ │ │ 拆分子任务 │ │ Ollama模型 │ │ │ └──────┬──────┘ │ 回复 │ │ │ │ └──────┬──────┘ │ │ ↓ ↓ │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ 整合工具结果/│ │ 返回最终答案 │ │ │ │ 子任务结果 │ └─────────────┘ │ │ └──────┬──────┘ │ │ ↓ │ │ ┌─────────────┐ │ │ │ 返回最终答案 │ │ │ └─────────────┘ │ │ │ │ ┌─────────────────────────────────┐ │ │ │ 循环如需多步则重复以上流程 │ │ │ └─────────────────────────────────┘ │ └─────────────────────────────────────────────┘用户指令 → Agent解析任务 → 是否需要工具/多步推理 ├─ 是 → 调用工具/拆分子任务 → 整合结果 → 返回答案 └─ 否 → 直接调用Ollama模型回复 → 返回答案关键模块规划模块负责将用户目标拆解为步骤如ReAct、CoT、Plan-and-Solve。记忆模块短期记忆当前会话的上下文受模型窗口限制。长期记忆外部向量数据库如Chroma、Pinecone存储历史经验或领域知识。执行模块调用工具API、代码、浏览器并解析返回结果。核心难点单智能体必须自己完成规划→执行→反思→再规划的闭环一旦在某个环节陷入死循环如重复调用同一错误工具整个任务就会失败。2. “缺点”背后的技术根源① 上下文窗口限制表象当任务步骤超过模型窗口如128K tokens时智能体会“忘记”早期信息。深层问题即使窗口足够大如Google Gemini的2M tokens注意力衰减依然存在——模型对中间步骤的关联能力会下降导致规划逻辑断裂。当前解法滑动窗口只保留最近的k步对话关键摘要。任务分解强制智能体在每次行动后生成“阶段性摘要”压缩历史。② 难以处理超长链条任务典型失败模式智能体在20步以上的任务中开始出现“重复行动”“目标漂移”“提前终止”。根本原因缺乏层级化规划能力。单智能体往往使用扁平规划步骤1→2→3…一旦某步失败缺乏动态重构计划的鲁棒性。改进方案Plan-and-Solve先生成完整计划图含依赖关系再按拓扑顺序执行。反思机制每N步插入一次“回顾”让模型自我评估进度并修正计划类似AutoGPT的“critique”环节。3. 单智能体架构的适用场景并非总是劣势在以下场景中单智能体反而是最优解场景类型原因任务明确、步骤有限10步避免多智能体的通信开销和一致性问题强依赖用户交互如Copilot类应用用户本身充当“监督者”弥补单智能体的弱点工具调用链短单次任务只需调用1-3个API不需要复杂协调对成本敏感多智能体意味着多倍token消耗和多次模型调用典型案例Cursor的代码生成智能体、Perplexity的搜索智能体本质上都是单智能体架构因为它们每次只处理一个明确的子任务且用户随时可介入纠偏。4. 单智能体 vs 多智能体的选择标准在实际架构选型中可以按以下决策树判断任务复杂度高吗 ├─ 否 → 单智能体足够 └─ 是 ├─ 任务可以明确分解为独立子任务吗 │ ├─ 否 → 单智能体强反思机制如AutoGPT │ └─ 是 │ └─ 子任务之间需要协调或并行吗 │ ├─ 否 → 单智能体顺序执行 │ └─ 是 → 多智能体架构5. 技术演进单智能体架构的“增强”路径当前单智能体架构并非停滞不前而是通过以下方式向“准多智能体”能力靠拢① 工作记忆增强不再依赖模型原生窗口而是外挂结构化工作记忆如JSON对象智能体每次行动前先读取当前状态行动后更新状态。代表框架LangGraph的StateGraph​允许智能体在循环中维护复杂状态机。② 虚拟多角色单智能体内通过角色提示模拟多智能体协作如“现在你作为产品经理思考…现在你作为工程师实现…”。优点避免多智能体间的通信延迟缺点容易产生角色混淆。③ 自省与重试策略引入异常处理层当工具调用失败时不直接报错而是让模型分析错误原因并尝试替代方案如换个API参数、改用另一种工具。总结如果要在生产环境中使用单智能体关键在于严格控制任务粒度——不要让它处理超过15步的复杂任务。外挂记忆与状态管理——用结构化存储补偿上下文窗口限制。设计强健的循环终止条件——避免无限循环或token浪费。简单大模型调用实现#pip install openai from openai import OpenAI import os api_key 这里输入api-key client OpenAI( api_keyapi_key, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1, #选用的是千问模型地址 ) completion client.chat.completions.create( modelqwen-max-latest, #模型型号 messages[ {role: system, content: 你是一个专业的厨师助手。}, #设置角色 {role: user, content: 你好请问如何做红烧牛肉} #提出问题 ] ) print(AI 回复completion.choices[0].message.content) #显示内容 #按照需求换成其他大模型 记得更换url 更换api-key【保密】 更换模型名词#这里直接使用http调用deepseek大模型 import requests import json def call_deepseek_api(api_key):# DeepSeek API调用示例 url https://api.deepseek.com/v1/chat/completions headers {Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: deepseek-chat, messages: [{role: user, content: 你好}] } response requests.post(url, headersheaders, jsonpayload) # 发送请求 result response.json()# 获取JSON响应 print(完整响应:) print(json.dumps(result, indent2, ensure_asciiFalse)) print(分析返回数据) print(fresult 类型: {type(result)} 键: {result.keys()}) choices result[choices] print(fchoices 类型: {type(choices)} 长度: {len(choices)}) first_choice choices[0] print(ffirst_choice 键: {first_choice.keys()}) message first_choice[message] print(fmessage 键: {message.keys()}) content message[content] print(fcontent 对话: {content}) print() assistant_response result[choices][0][message][content] print(f\n最终提取的内容: {assistant_response}) print() return assistant_response if __name__ __main__: mock_responsecall_deepseek_api(sk-这里输入你的deepseek-apikey)简单大模型嵌入向量要实现RAG检索增强生成的第一步 将文本转变成嵌入向量#在这个.py文件下新建.env文件 #写入API_KEYsk-...你的千问api密钥... from dotenv import load_dotenv from openai import OpenAI import os load_dotenv() #加载.env文件 内容 # 1. 配置客户端 client OpenAI( api_keyos.getenv(API_KEY), # 从环境变量读取API Key base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1, # 千问API基础URL ) # 2. 调用嵌入API response client.embeddings.create( input[大模型], # 输入文本可以是列表 modeltext-embedding-v3 # 嵌入模型 ) # 3. 获取结果 embedding response.data[0].embedding # 提取向量 print(f向量维度: {len(embedding)}) print(f向量前10个值: {embedding[:10]})#在这个.py文件下新建.env文件 #写入API_KEYsk-...你的千问api密钥... from dotenv import load_dotenv from openai import OpenAI import os load_dotenv() #加载.env文件 内容 client OpenAI( api_keyos.getenv(API_KEY), # 使用.env文件下的阿里云千问API密钥 base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1, # 千问API基础URL ) def get_embeddings(texts, modeltext-embedding-v3):# text-embedding-v3是嵌入模型名称 texts: 是一个包含要获取嵌入表示的文本的列表 model: 用来指定要使用的模型的名称 生成文本的嵌入表示结果存储在data中。 data client.embeddings.create(inputtexts, modelmodel).data # 调用千问的嵌入API return [x.embedding for x in data] # 返回了一个包含所有嵌入表示的列表 test_query [大模型]# 测试查询 vec get_embeddings(test_query)# 获取嵌入向量 print(向量列表:, vec) print(第一个文本的嵌入向量:, vec[0]) print(嵌入向量的维度:, len(vec[0]))