资讯动态

Agent day_6:Python中requests和response使用、HTTP状态码、浏览器的拓展、JSON结构的转换、历史记录与摘要的存储、上下文和记忆设计、summary和memory区别

发布时间:2026/8/27 21:04:23 来源:尧图企业网站定制
day_6requests请求方法方法作用常用场景示例requests.get()发送 GET 请求查询数据、获取网页、下载资源requests.get(url)requests.post()发送 POST 请求登录、提交表单、创建数据requests.post(url, jsondata)requests.put()更新资源整体修改修改用户、更新配置requests.put(url, jsondata)requests.patch()部分更新资源修改某几个字段requests.patch(url, jsondata)requests.delete()删除资源删除数据requests.delete(url)requests.head()获取响应头查看文件信息、服务器信息requests.head(url)requests.options()查询支持的方法API探测requests.options(url)requests.request()通用请求方法动态指定请求类型requests.request(GET,url)常用参数参数作用示例url请求地址https://api.comparamsGET参数拼接到URL{page:1}data表单数据{user:Tom}jsonJSON格式请求数据{id:1}headers请求头{User-Agent:xxx}cookiesCookie信息{session:abc}files上传文件{file:open(a.jpg,rb)}auth身份认证(user,pass)timeout超时时间timeout5proxies设置代理{http:127.0.0.1:8080}verifySSL证书验证verifyFalsestream流式读取streamTrueallow_redirects是否允许跳转FalseResponse常用属性/方法属性/方法作用示例response.text获取文本内容网页HTML、字符串response.content获取二进制内容图片、文件response.json()解析JSONAPI返回数据response.status_code获取状态码200response.headers获取响应头Content-Typeresponse.cookies获取Cookie登录信息response.url获取最终URL跳转后的地址response.encoding查看/修改编码utf-8response.raise_for_status()检查请求错误4xx/5xx抛异常HTTP状态码状态码含义requests判断200请求成功status_code 200201创建成功POST创建数据301永久重定向自动跳转302临时重定向自动跳转400请求参数错误客户端问题401未认证登录失败403禁止访问权限不足404页面不存在地址错误500服务器错误服务端问题Session方法作用示例requests.Session()创建会话srequests.Session()session.get()会话GET请求s.get(url)session.post()会话POST请求s.post(url,data)session.headers.update()设置默认请求头保存Tokensession.cookies管理Cookie保持登录session requests.Session() ​ session.post( login_url, datauser ) ​ response session.get( user_page )浏览器拓展作用突破浏览器原生功能的限制将其从单纯的“网页播放器”---高度个性化、功能强大的一站式生产力平台增强功能增加浏览器原来没有的功能eg:网页翻译、截图、网页收藏、下载辅助等。提高效率自动填写密码、整理资料、管理任务、快速搜索和处理信息优化浏览体验屏蔽广告、开启夜间模式、调整网页样式、增强视频和阅读体验。辅助学习和工作翻译文章、总结网页内容、检查语法、管理文献、辅助办公。提高安全与隐私保护拦截恶意网站、防止追踪、保护个人信息。实现个性化服务根据用户浏览场景提供特定内容eg:购物比价、优惠提醒、AI网页分析等。JSON结构的转换写 Python 代码 (history 为 dict) │ ▼ [SDK 自动 json.dumps()] 传输中的 JSON 字符串 --------------------------- (智谱 AI 服务器处理) │ │ ▼ [SDK 自动 json.loads() 并封装为 Python 类] ──────┘ 拿到 response (Python 对象) │ ▼ [如果是 Tool Call你需要手动对 arguments 做一次 json.loads()] 拿到具体的工具参数 (Python dict)Agent的历史记录的摘要是如何存储的Agent的历史和摘要的存储Raw History(原始历史----完整的一个历史记录) ↓ Summary / Compaction(摘要/压缩) ↓ Context(上下文) ↓ LLM (大语言模型)Raw History通常持久化在数据库、Session Store或其他存储中Summary是从历史中提取出来的压缩表示也可以持久化Raw History的限制存储方面Raw History → 数据库容量 / 存储成本 / retention policy模型方面LLM Context → Context Window / Token Budgeteg:Raw History 1,000,000 tokens ​ 但是一次请求可能只给模型 ​Summary 10K Recent History 15K Memory 5K Current Input 2K --------------------- Context 32K┌────────────────────────────────────────────────────────────────────────┐ │ ① 输入与意图层 (Input Intent) │ │ │ │ User Input ──► Query Rewriter Embedding Engine │ └──────────────────────────────────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────────────┐ │ ② 检索与选择层 (Selection) │ │ │ │ Context Planner / Router │ │ ┌───────────────────────────┼───────────────────────────┐ │ │ ▼ ▼ ▼ │ │ Recent Window Memory Search Summary Fetch │ │ (近期滑动窗口) (向量/图数据库检索) (阶段/全局摘要) │ └──────┬───────────────────────────┬───────────────────────────┬─────────┘ │ │ │ └───────────────────────────┼───────────────────────────┘ ▼ ┌────────────────────────────────────────────────────────────────────────┐ │ ③ 双向存储层 (Storage Consolidation) │ │ │ │ ┌───────────────────────┐ ┌──────────────────────┐ ┌─────────────┐ │ │ │ Raw History │ │ Memory Store │ │Summary Store│ │ │ │ (Full Log ~1,000K) │ │ (Key Facts ~5K) │ │ (Chunk ~10K)│ │ │ └───────────▲───────────┘ └──────────▲───────────┘ └──────▲──────┘ │ │ │ │ │ │ │ └─────────────────────────┼─────────────────────┘ │ │ 后台异步提炼/压缩 (Async Worker) │ └──────────────────────────────────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────────────┐ │ ④ 组装与预算优化层 (Assembly Budget) │ │ │ │ Deduplication ──► Priority Allocator ──► Budget Manager (≤ 32K) │ └──────────────────────────────────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────────────┐ │ ⑤ 推理与输出层 (Inference) │ │ │ │ Large Language Model │ └────────────────────────────────────────────────────────────────────────┘Summary、Memory、State的区别概念解决什么问题类比Raw History以前到底发生了什么 录像Summary以前发生的事情重点是什么 笔记Memory用户/Agent 长期应该记住什么 长期记忆State当前任务做到哪里了 游戏存档如果Rew History很大怎么找以前的信息Retrieval/History SearchRaw History │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ Summary Retrieval Recent │ │ │ └──────────────┼──────────────┘ │ Memory │ ▼ Context Builder │ ▼ LLM面试怎么设计Agent的上下文和记忆不要一上来就数据库Schema我会把Agent的记忆拆分几个不同的层次而不是把所有聊天记录都直接塞给模型第一层Raw History,也就是完整的conversation history,包括user、assistant、tool call、tool result等消息。这部分主要用于可追溯和后续检索可以持久化在数据库或其他Session Store中。第二层是Summary 或 Compaction。当历史越来越长、接近 Context Window 或 Token Budget 时把较早的历史压缩成一个 summary同时保留最近的一部分原始消息。这样下一次调用模型时不需要把全部历史重新发送。第三层是Long-term Memory。它和 conversation summary 不一样。Memory 存的是跨会话仍然有价值的信息比如用户长期的技术偏好、工作习惯或者明确要求 Agent 记住的事实。第四层是State主要描述当前任务的执行状态比如当前执行到第几步、哪些步骤已经完成、哪些 tool 正在等待结果。这主要用于Agent 中断之后恢复任务。因此一次 Agent 请求真正发送给 LLM 的内容通常不是全部 Raw History而是由Context Builder 动态组装System Prompt Relevant Memory Conversation Summary Recent History Task State 当前用户输入。如果历史中有很久以前的信息我会通过 History Retrieval 或其他检索机制找到相关历史再把相关片段加入 Context。所以整体上可以理解为Raw History 负责可追溯Summary 负责上下文压缩Memory 负责跨会话长期记忆State 负责任务恢复Retrieval 负责从大量历史中找到当前真正相关的信息。这样可以同时解决 Context Window、Token 成本、长期记忆和任务恢复的问题Raw History不会无限增长吗会增长所以我会把“存储历史”和“Context”分开考虑。Raw History是持久化数据它的大小受到数据库容量、存储成本和数据保留策略并不存在一个等同于LLM Context Window的固定token上限。但是每次模型推理的Context是有限的所以我不会把全部的Raw History都发送给模型通常会通过Context Builder 控制输入例如Summary Recent History Relevant Memory Retrieved History Current Input。当历史超过一定 token threshold 时触发 Compaction把较早的消息压缩成 Summary如果用户需要查询很久以前的信息则通过 Retrieval 从 Raw History 中找到相关内容而不是把整个历史重新放进 Context。所以可以把 Raw History 理解成一个长期数据仓库而 Context 是一个有限的工作区。Summary和Memory的区别Summary是conversation-level的压缩状态Memory是user/agent-level的长期知识最大的区别生命周期、作用范围Summary通常是conversation-level,用来压缩当前这段对话。 例如用户正在开发一个电商系统Summary 可以记录当前项目的技术栈、已经完成的工作和当前讨论到哪里。Memory则是长期的、跨conversation的。 例如用户长期偏好 Python或者明确要求以后都使用 PostgreSQL。这些信息即使当前 conversation 结束了下次新的 conversation 也可能继续使用。所以我会把它理解成Summary “这次对话之前发生了什么”Memory “这个用户长期有什么值得记住的信息”另外Summary 一般可以从 Raw History 重新生成而Memory 更像经过提炼、筛选和持久化后的长期事实。框架图┌──────────────┐ │ Raw History │ │ 完整历史 │ └──────┬───────┘ │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ Compaction Retrieval Recent │ │ History ▼ │ │ Summary │ │ │ │ │ └──────────────┼──────────────┘ │ ┌──────▼──────┐ │ Memory │ │ 长期记忆 │ └──────┬──────┘ │ ┌──────▼──────┐ │ Context │ │ Builder │ └──────┬──────┘ │ Task State │ ▼ LLMRaw History 是事实源Summary 是压缩后的上下文Memory 是长期知识State 是任务 checkpointContext Builder负责在有限 Token Budget 下把这些信息组合成模型真正需要看到的上下文。总结Agent 的历史和记忆我一般会分层处理。Raw History 保存完整的 conversation 和 tool events主要用于审计和检索历史过长后通过 Compaction 生成 Summary避免 Context 无限增长Memory 单独存储跨会话长期有效的用户或 Agent 信息State保存当前任务的执行checkpoint用于中断恢复。真正调用 LLM 时不会把全部 Raw History 放进去而是由Context Builder根据 Token Budget 组合 Summary、Recent History、Relevant Memory、Retrieved History、State 和当前输入。这样既解决Context Window 和成本问题也支持长期记忆、历史追溯和任务恢复。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价