📱 核心性能与屏幕参数 机型 芯片 屏幕尺寸与材质 屏幕刷新率 峰值亮度 (HDR/户外) iPhone 11 A13 仿生 6.1英寸 LCD 60Hz 625尼特 iPhone 11 Pro A13 仿生 5.8英寸 OLED 60Hz 800尼特 iPhone 11 Pro Max A13 仿生 6.5英寸 OLED 60Hz 800尼特 iPhone 12 A14 仿生 6.1英寸 OLED 60Hz 1200尼特 iPhone 12 mini A14 仿生 5.4英寸 OLED 60Hz 1200尼特 iPhone 12 Pro A14 仿生 6.1英寸 OLED 60Hz 1200尼特 iPhone 12 Pro Max A14 仿生 6.7英寸 OLED 60Hz 1200尼特 iPhone 13 A15 仿生 6.1英寸 OLED 60Hz 1200尼特 iPhone 13 mini A15 仿生 5.4英寸 OLED 60Hz 1200尼特 iPhone 13 Pro A15 仿生 6.1英寸 OLED 120Hz (ProMotion) 1200尼特 iPhone 13 Pro Max A15 仿生 6.7英寸 OLED 120Hz (ProMotion) 1200尼特 iPhone 14 A15 仿生 6.1英寸 OLED 60Hz 1200尼特 iPhone 14 Plus A15 仿生 6.7英寸 OLED 60Hz 1200尼特 iPhone 14 Pro A16 仿生 6.1英寸 OLED 120Hz (ProMotion) 1600尼特 iPhone 14 Pro Max A16 仿生 6.7英寸 OLED 120Hz (ProMotion) 1600尼特 iPhone 15 A16 仿生 6.1英寸 OLED 60Hz 1600尼特 iPhone 15 Plus A16 仿生 6.7英寸 OLED 60Hz 1600尼特 iPhone 15 Pro A17 Pro 6.1英寸 OLED 120Hz (ProMotion) 2000尼特 iPhone 15 Pro Max A17 Pro 6.7英寸 OLED 120Hz (ProMotion) 2000尼特 iPhone 16 A17 Pro 6.1英寸 OLED 60Hz 2000尼特 iPhone 16 Plus A17 Pro 6.7英寸 OLED 60Hz 2000尼特 iPhone 16 Pro A18 Pro 6.3英寸 OLED 120Hz (ProMotion) 2000尼特 iPhone 16 Pro Max A18 Pro 6.9英寸 OLED 120Hz (ProMotion) 2000尼特 iPhone 17 A18 Pro 6.1英寸 OLED 120Hz (ProMotion) 2000尼特 iPhone 17 Pro A18 Pro 6.3英寸 OLED 120Hz (ProMotion) 2000尼特 iPhone 17 Pro Max A18 Pro 6.9英寸 OLED 120Hz (ProMotion) 2000尼特 📸 系统参数 机型 后置主摄 (广角) 超广角镜头 长焦镜头 (光变) 前置摄像头 iPhone 11 1200万像素 1200万像素 无 1200万像素 iPhone 11 Pro 1200万像素 1200万像素 1200万 (2倍) 1200万像素 iPhone 11 Pro Max 1200万像素 1200万像素 1200万 (2倍) 1200万像素 iPhone 12 1200万像素 1200万像素 无 1200万像素 iPhone 12 mini 1200万像素 1200万像素 无 1200万像素 iPhone 12 Pro 1200万像素 1200万像素 1200万 (2倍) 1200万像素 iPhone 12 Pro Max 1200万像素 1200万像素 1200万 (2.5倍) 1200万像素 iPhone 13 1200万像素 1200万像素 无 1200万像素 iPhone 13 mini 1200万像素 1200万像素 无 1200万像素 iPhone 13 Pro 1200万像素 1200万像素 1200万 (3倍) 1200万像素 iPhone 13 Pro Max 1200万像素 1200万像素 1200万 (3倍) 1200万像素 iPhone 14 1200万像素 1200万像素 无 1200万像素 iPhone 14 Plus 1200万像素 1200万像素 无 1200万像素 iPhone 14 Pro 4800万像素 1200万像素 1200万 (3倍) 1200万像素 iPhone 14 Pro Max 4800万像素 1200万像素 1200万 (3倍) 1200万像素 iPhone 15 4800万像素 1200万像素 无 (支持2倍无损裁切) 1200万像素 iPhone 15 Plus 4800万像素 1200万像素 无 (支持2倍无损裁切) 1200万像素 iPhone 15 Pro 4800万像素 1200万像素 1200万 (3倍) 1200万像素 iPhone 15 Pro Max 4800万像素 1200万像素 4800万 (5倍) 1200万像素 iPhone 16 4800万像素 1200万像素 无 (支持2倍无损裁切) 1200万像素 iPhone 16 Plus 4800万像素 1200万像素 无 (支持2倍无损裁切) 1200万像素 iPhone 16 Pro 4800万像素 1200万像素 4800万 (5倍) 1200万像素 iPhone 16 Pro Max 4800万像素 1200万像素 4800万 (5倍) 1200万像素 iPhone 17 4800万像素 1200万像素 4800万 (5倍) 1200万像素 iPhone 17 Pro 4800万像素 1200万像素 4800万 (5倍) 1200万像素 iPhone 17 Pro Max 4800万像素 1200万像素 4800万 (5倍) 1200万像素 🔋 续航与充电参数 机型 电池容量 (典型值) 视频播放时长 (小时) 有线充电功率 无线充电 iPhone 11 3110mAh 17小时 18W 支持 iPhone 11 Pro 3046mAh 18小时 18W 支持 iPhone 11 Pro Max 3418mAh 20小时 18W 支持 iPhone 12 2815mAh 17小时 20W 支持 iPhone 12 mini 2227mAh 15小时 20W 支持 iPhone 12 Pro 2815mAh 17小时 20W 支持 iPhone 12 Pro Max 3687mAh 20小时 20W 支持 iPhone 13 3227mAh 19小时 27W 支持 iPhone 13 mini 2406mAh 17小时 27W 支持 iPhone 13 Pro 3095mAh 22小时 27W 支持 iPhone 13 Pro Max 4352mAh 28小时 27W 支持 iPhone 14 3279mAh 20小时 27W 支持 iPhone 14 Plus 4325mAh 26小时 27W 支持 iPhone 14 Pro 3200mAh 23小时 27W 支持 iPhone 14 Pro Max 4323mAh 29小时 27W 支持 iPhone 15 3349mAh 26小时 35W 支持 iPhone 15 Plus 4383mAh 26小时 35W 支持 iPhone 15 Pro 3274mAh 23小时 35W 支持 iPhone 15 Pro Max 4422mAh 29小时 35W 支持 iPhone 16 3558mAh 22小时 35W 支持 iPhone 16 Plus 4674mAh 24小时 35W 支持 iPhone 16 Pro 3582mAh 25小时 35W 支持 iPhone 16 Pro Max 4685mAh 28小时 35W 支持 iPhone 17 3700mAh 24小时 45W 支持 iPhone 17 Pro 3850mAh 26小时 45W 支持 iPhone 17 Pro Max 4800mAh 30小时 45W 支持 📏 外观与接口参数 机型 机身尺寸 (高×宽×厚 mm) 机身重量 (g) 接口类型 特殊设计 iPhone 11 150.9 × 75.7 × 8.3 194 Lightning 铝合金边框 iPhone 11 Pro 144.0 × 71.4 × 8.1 188 Lightning 不锈钢边框 iPhone 11 Pro Max 158.0 × 77.8 × 8.1 226 Lightning 不锈钢边框 iPhone 12 146.7 × 71.5 × 7.4 162 Lightning 直角边框 iPhone 12 mini 131.5 × 64.2 × 7.4 133 Lightning 直角边框 iPhone 12 Pro 146.7 × 71.5 × 7.4 187 Lightning 直角边框 iPhone 12 Pro Max 160.8 × 78.1 × 7.4 226 Lightning 直角边框 iPhone 13 146.7 × 71.5 × 7.65 173 Lightning 刘海缩小 iPhone 13 mini 131.5 × 64.2 × 7.65 140 Lightning 刘海缩小 iPhone 13 Pro 146.7 × 71.5 × 7.65 203 Lightning 刘海缩小 iPhone 13 Pro Max 160.8 × 78.1 × 7.65 238 Lightning 刘海缩小 iPhone 14 146.7 × 71.5 × 7.8 172 Lightning 卫星紧急联络 iPhone 14 Plus 160.8 × 78.1 × 7.8 203 Lightning 卫星紧急联络 iPhone 14 Pro 147.5 × 71.5 × 7.85 206 Lightning 灵动岛设计 iPhone 14 Pro Max 160.7 × 77.6 × 7.85 240 Lightning 灵动岛设计 iPhone 15 147.6 × 71.6 × 7.8 171 USB-C 磨砂玻璃背板 iPhone 15 Plus 160.9 × 77.8 × 7.8 201 USB-C 磨砂玻璃背板 iPhone 15 Pro 146.6 × 70.6 × 8.25 187 USB-C 钛金属边框 iPhone 15 Pro Max 159.9 × 76.7 × 8.25 221 USB-C 钛金属边框 iPhone 16 147.6 × 71.6 × 7.8 170 USB-C 相机控制按键 iPhone 16 Plus 160.9 × 77.8 × 7.8 199 USB-C 相机控制按键 iPhone 16 Pro 149.6 × 71.5 × 8.25 199 USB-C 钛金属，相机控制按键 iPhone 16 Pro Max 163.0 × 77.6 × 8.25 227 USB-C 钛金属，相机控制按键 iPhone 17 149.0 × 71.0 × 8.1 195 USB-C 超薄灵动岛 iPhone 17 Pro 151.0 × 72.0 × 8.1 215 USB-C 超薄灵动岛 iPhone 17 Pro Max 164.0 × 78.0 × 8.1 235 USB-C 超薄灵动岛 🧠 与内存参数 机型 起步存储 最高存储 运行内存 (RAM) iPhone 11 64GB 256GB 4GB iPhone 11 Pro 64GB 512GB 4GB iPhone 11 Pro Max 64GB 512GB 4GB iPhone 12 64GB 256GB 4GB iPhone 12 mini 64GB 256GB 4GB iPhone 12 Pro 128GB 512GB 6GB iPhone 12 Pro Max 128GB 512GB 6GB iPhone 13 128GB 512GB 4GB iPhone 13 mini 128GB 512GB 4GB iPhone 13 Pro 128GB 1TB 6GB iPhone 13 Pro Max 128GB 1TB 6GB iPhone 14 128GB 512GB 6GB iPhone 14 Plus 128GB 512GB 6GB iPhone 14 Pro 128GB 1TB 6GB iPhone 14 Pro Max 128GB 1TB 6GB iPhone 15 128GB 512GB 6GB iPhone 15 Plus 128GB 512GB 6GB iPhone 15 Pro 128GB 1TB 8GB iPhone 15 Pro Max 256GB 1TB 8GB iPhone 16 128GB 512GB 8GB iPhone 16 Plus 128GB 512GB 8GB iPhone 16 Pro 128GB 1TB 8GB iPhone 16 Pro Max 256GB 1TB 8GB iPhone 17 128GB 1TB 8GB iPhone 17 Pro 256GB 1TB 8GB iPhone 17 Pro Max 256GB 1TB 8GB 💡 核心升级节点总结 🖥️ 屏幕与设计的全面进化 iPhone 12：全系升级 OLED 屏幕，回归直角边框设计 iPhone 14 Pro：首次引入"灵动岛"交互设计 iPhone 13 Pro：Pro 系列首次普及 120Hz ProMotion 自适应刷新率 iPhone 17：超薄灵动岛设计，进一步缩小前置摄像头区域 原文链接: iPhone 11至iPhone 17系列全型号详细参数对比 作者: lixusocool ...

概述 这是一个基于 的 IoT 设备自动化测试框架，主要用于测试高通（Qualcomm）芯片平台的设备。 核心 1. ADB (Android Debug Bridge) ⭐⭐⭐⭐⭐ 主要工具，使用最广泛 位置:Libs/Utilities/adb.py 用途: 设备连接和通信 执行 shell 命令 文件传输（push/pull） 设备重启 日志收集 使用示例: from Libs.Utilities.adb import adb # 执行命令 adb.run_cmd("adb shell ls /data", serial_number) # 推送文件 adb.push(local_path, remote_path, serial_number) # 拉取文件 adb.pull(remote_path, local_path, serial_number) # 重启设备 adb.run_cmd("adb reboot", serial_number) 特点: 支持多设备（通过 serial_number 区分） 支持 ADB over WiFi 自动日志记录（发送和接收的命令） 2. UIAutomator2 ⭐⭐⭐⭐ UI 自动化工具 库:uiautomator2(简称 u2) 用途: Android UI 元素定位和操作 点击、滑动、输入等交互 截图和屏幕录制 应用启动和管理 使用示例: import uiautomator2 as u2 # 连接设备 d = u2.connect(serial_number) # 点击按钮 d(resourceId="com.example:id/button").click() # 输入文本 d(resourceId="com.example:id/edit").set_text("Hello") # 检查元素是否存在 if d(text="Settings").exists: d(text="Settings").click() # 滑动 d.swipe(100, 500, 100, 100) 应用场景: LAW (Linux Android Wear) 平台测试 UI 交互测试 设置配置 弹窗处理 3. SSH ⭐⭐⭐ 远程连接工具 ...

配置自定义 AI API 完整指南：从零到一接入你的专属模型 前言 作为一名开发者，我们经常需要在终端环境中使用 AI 编程助手。 的 Codex 是一个非常强大的命令行 AI 编程工具，但默认情况下它只能调用 OpenAI 官方的 。那么问题来了：如果我们有自己的 API 服务（比如部署了国产、使用了代理服务、或者公司内部的 AI 平台），如何让 Codex 接入这些自定义的 API 呢？ 本文将通过一个真实的配置案例，详细讲解如何在 macOS（特别是 Mini）环境下配置 Codex，使其能够调用自定义的 AI API。整个过程涉及编写、环境变量设置、版本兼容性问题排查等，希望能帮助到遇到类似问题的开发者。 一、理解 Codex 的架构 在开始配置之前，我们需要理解 Codex 的基本架构。Codex 采用了一种灵活的 Provider 机制，允许用户定义多个 AI 服务提供商，并在它们之间切换。 核心概念： Provider（提供商）：一个 AI 服务的具体实现，包含 API 地址、认证方式等 Model（模型）：Provider 提供的具体模型名称 Wire API：Codex 与 Provider 之间的通信协议类型 这种设计让 Codex 不仅限于 OpenAI 的服务，理论上可以接入任何兼容 OpenAI API 格式的服务。 二、配置前的准备工作 2.1 确认 Codex 版本 这是最关键的一步！不同版本的 Codex 对 API 协议的支持完全不同： ...

今天我们聊一个近期 AI 圈里的热门话题 — 和 Agent**。** 一提到 AI，大家总说“让 AI 帮我干活”，可真要让 AI 落地做事，离不开 Workflow 与 。这俩到底在 AI 里扮演了什么角色，又有什么区别？ 今天我们就来详细聊聊**，揭开 AI 自动化的秘密**。 1 Workflow：深耕多年的“流程老管家” Workflow，也叫。很多人以为它是 AI 带火的新词，其实它早就在各行业成熟应用了。比如： 职场人熟悉的审批流：请假时，从提交申请到审批通过，每一步都有固定顺序，缺一不可； 程序员常用的持续集成：代码提交后，自动触发编译→测试→部署，全程按预设步骤走，无需人工干预； 这些场景的本质就是提前把规则写死，严格按照预设步骤执行。就像工厂里的流水线，螺丝拧几圈、零件放哪里，早就定好了，工人只要按流程走就行。 它的核心工作流也不复杂，主要分为四步： 触发：谁来启动这条流程？ 满足某个条件就自动开跑，比如点击提交、到达某个时间点、检测到有文件上传。 编排：接下来按哪条路走？ 先做什么、后做什么，遇到不同情况走哪条分支，都提前设计好，相当于流程的“路线图”。 执行：具体怎么干活？ 按照路线图真正去办事：比如提交后的发送消息通知、计算汇总数据、调用外部接口等，把每一步操作落地。 结束：怎么收尾？ 流程跑完后，再把结果告知相关人，更新状态、保存记录，让这件事有一个完整闭环。 可以说，传统 Workflow 就像一套按部就班、严谨执行的固定“剧本”，不会自主思考、也不会灵活变通。 而当 AI 时代到来，Workflow 也迎来了新的角色与价值。 AI 的落地离不开（LLM），但大模型再智能，也只是一个擅长理解生成、却不懂统筹调度的“超级大脑”。当我们需要把零散的思考变成可执行的步骤时，就需要一个统一调度的角色 — Workflow。它会决定什么时候调用大模型、让它处理什么内容、结果传给谁、下一步怎么走。 正是这样，传统工作流才真正具备了理解意图、生成内容的智能能力，升级为 AI Workflow。 比如 AI 智能客服，它的流程非常清晰： 用户咨询 → 大模型识别意图 → 生成应对答案 → 回复用户。 还有常用的 AI 生成社交文案的流程： 输入需求 → 大模型提取关键词 → 生成文案 → 人工微调 → 发布 ...

跨平台、功能丰富、极快：重新定义AI上下文通信的优先紧凑文本输出。 对于者来说，在开发AI Agent时与浏览器交互是一个频繁的过程。让AI Agent更高效地操作浏览器是一个具有挑战性的问题。最近，在搜索AI测试解决方案时，我发现了Vercel开源的agent-browser，这是一款专为AI Agent设计的自动化CLI。 agent-的特性： 基于引用：快照返回带有引用的可访问树。 Agent优先：高效利用AI上下文，节省token。 会话：支持多个具有独立身份验证的隔离浏览器实例。 功能完整：支持超过50个命令，包括导航、表单操作和截图。 跨平台：支持macOS、Linux和Windows平台。 1、安装agent-browser 在安装agent-browser之前，请确保您的计算机上已安装Node.js。 在命令行中输入以下命令。-g选项表示全局安装。 npm install -g agent-browser 成功安装agent-browser CLI后，继续输入命令agent-browser install，这将开始下载Chromium浏览器。 安装Chromium浏览器... 需要安装以下软件包： playwright@1.58.2 确定继续？(y) y 成功安装Chromium浏览器后，命令行将输出成功安装的消息。 正在下载Chrome for Testing 145.0.7632.6 (playwright chromium v1208)... 162.3 MiB [====================] 100% 0.0s ... ✓ Chromium安装成功 2、使用agent-browser 2.1 打开网页 agent-browser open https://agent-browser.dev/ 输出： ✓ 无头浏览器自动化 for AI https://agent-browser.dev/ 2.2 获取当前网页的可访问树 agent-browser snapshot -i 输出： - 链接 "Made with love by Vercel" [ref=e1] - 链接 "agent-browser" [ref=e2] - 链接 "16k" [ref=e3] - 链接 "npm" [ref=e4] ... - 按钮 "Ask AI" [ref=e26] 2.3 使用引用进行交互 agent-browser click @e3 输出： ...

问题类型 占比 可预防性 过热降频/关机 40% ⭐⭐⭐⭐⭐（加风扇即可） 电源不足 25% ⭐⭐⭐⭐（换好电源） 内核/驱动崩溃 20% ⭐⭐⭐（升级内核） 内存/存储故障 10% ⭐⭐（依赖硬件质量） 工具/配置错误 5% ⭐⭐⭐⭐（规范操作） 原文链接: 开发板常见问题 作者: lixusocool

优点 缺点 brower-use 使用官网SDK写一个python的api，挺好用的能识别网页绿色框框数量 官网api收费，使用免费的api不太好用github的部署麻烦，没有成功 magentic-ui-fara7B 部署简单成功也能识别绿色框框 调用的qubrid的api，几下就用完了。。。需要设置docker的普通用户权限 原文链接: 浏览器自动化agent体验（brower-use，magentic-ui-fara7B） 作者: lixusocool

花了我两三天，结果还是好的达到了我的预期 (o゜▽゜)o☆[BINGO!] 先看下效果： 如图所示脚本运行可以自动点击join按钮和滑动按钮，按时签到薅羊毛！ 我采用的是pyautogui+方式，非传统自动化工具如Selenium和Playwright，不过使用了DrissionPage来获取缺口图和背景图。 已经适配windows和debian系统，最新的浏览器（其他没试）。 分享源码给大家一起学习测试使用（不可用做非法用途！发生的非法事件与本人无关特此声明） ：https://github.com/haolixu/geetest-auto ：https://gitee.com/haolixu/geetest-auto 那个依赖我没搞定，尝试了pip > requirements.txt和pipreqs . –encoding=utf-8 –force 但是没啥用。。。还是缺依赖，你们有什么好的方法吗？ 需要注意的是浏览器需要设置一下： win：D:\浏览器\QQBrowser\QQBrowser.exe -sc=desktopshortcut -fixlaunch=0 —debugging-port=9222 ：/usr/bin/qqbrowser-browser-stable %U -sc=desktopshortcut -fixlaunch=0 –remote-debugging-port=9222 原文链接: 成功破解geetestv4极验滑动验证码 作者: lixusocool

干货分享，感谢您的阅读！ 随着大语言（Large Language Model，LLM）能力的持续提升，业界对“让模型真正做事”的期待，已经从单轮对话生成文本，转向了具备自主决策、工具调用与多步执行能力的 Agent（智能体）系统。 在这一演进过程中，一个逐渐清晰的共识是：Agent 并不是“更强的大模型”，而是“以大模型为大脑，外部系统为四肢”的工程系统。 记忆、规划、、行动执行，这些能力本质上并不来自模型本身，而是通过工程框架将模型与外部能力进行组织、编排与约束的结果。正是在这一背景下，围绕 Agent 的研究与工程实践迅速发展，催生了诸如 ReAct、Auto-GPT、LangGraph、MetaGPT 等一系列方法与框架。 我们将聚焦于 ModelScope-Agent 这一由阿里云魔搭社区推出的 框架，从能力结构、运行机制、典型任务示例与工程实践角度，系统解析如何基于该框架构建一个可扩展、可落地的 Agent 应用。 一、为什么 Agent 不等于？ 在深入 -Agent 之前，有必要先澄清一个常见误区：Agent ≠ 更大的模型 ≠ 多轮 Prompt。 从系统架构视角来看，一个可用的 Agent 至少包含以下几个核心组件： 推理核心（LLM）：负责理解用户意图、进行任务拆解、生成行动决策。 工具系统（Tools / Plugins）：提供模型无法直接完成的能力，如搜索、计算、生成图片、调用 API 等。 执行与调度层（Executor / Orchestrator）：将模型输出的“意图”转化为真实的函数调用或外部服务请求。 记忆系统（Memory）：保存历史对话、中间结果、长期偏好，用于后续决策参考。 规划与反思机制（Planning & Reflection）：用于多步骤任务拆解、执行顺序安排，以及失败后的自我修正。 从这个角度看，Agent 是一个系统工程问题，而不是单一模型能力问题。ModelScope-Agent 正是试图在工程层面，为这些能力提供一套可组合、可扩展的实现框架。 二、ModelScope-Agent 框架概览 ModelScope-Agent 是魔搭社区推出的一个 通用 Agent 开发框架，其目标并非“封装一个黑盒 Agent”，而是提供： 标准化的 Agent 抽象 灵活的工具接入机制 可插拔的记忆与规划模块 面向多模态任务的统一调用方式 从系统结构上看（如下图所示，老版本结构，仅供参考）： 利用ModelScope-Agent框架开发的Agent，除了可以提供文本创作之外，还能生成图片、视频、语音等内容。单个Agent具有角色扮演、LLM调用、工具使用、规划、记忆等能力。 技术上主要具有以下特点： 简单的Agent实现流程：仅需指定角色描述、大模型名称、工具名列表，即可实现一个Agent应用，框架内部自动实现工具使用、规划、记忆等工作流的编排。 丰富的模型和工具：框架内置丰富的大模型接口，例如Dashscope和Modelscope模型接口，OpenAI模型接口等。内置丰富的工具，例如代码运行、天气查询、文生图、网页解析等，方便定制专属Agent。 统一的接口和高扩展性：框架具有清晰的工具、大模型注册机制，方便用户扩展能力更加丰富的Agent应用。 低耦合性：开发者可以方便地直接使用内置的工具、大模型、记忆等组件，而不需要绑定更上层的Agent。 三、ModelScope-Agent 的核心能力解析 （一）内容生成能力 与许多只聚焦文本任务的 Agent 框架不同，ModelScope-Agent 天然支持多模态工具接入，使 Agent 能够完成： ...

做记忆模块搭建的相关研发工作，一开始认为agent的记忆就是维护上下文，应该和chatbot的对话管理差不多，但真的做一段时间之后，才发现和对话管理相比还是区别比较大的，而且记忆模块对agent的实现效果以及后期可扩展性有比较重要的影响。 agent记忆与chatbot上下文的区别 我们拿agent记忆与上下文来作下比较，暂且不考虑长期记忆，就拿短期记忆来作对比，短期记忆(工作记忆)主要就是维护上下文，更官方一点的说法就是上下文工程，那chabot的对话管理不是也是在维护上下文吗？那两者有什么区别呢？ 目标 agent记忆和chatbot上下文的目标看上去是一致的:给LLM/agent添加合适的状态来做下一步的决策。但是从服务对象，组织形式和维护重点的扩展来看有比较大的区别。 服务对象 虽然两者都算是人机交互，拿服务的对象都可以算作是人，但从现阶段的主要技术实现来看，服务对象还是存在差异的。 chatbot的服务对象是人这个毋庸置疑，做图灵测试也是为了验证对面和你说话的那个AI，有没有可能骗过你，而从让你以为它是个人，chatbot展开的多轮对话也是围绕人的实际需求展开。 agent虽然也存在与人的交互，agentic workflow中一般也会有人工输入的节点，但现阶段我们搭建agent的主要任务，更多时候是在自动完成一个复杂任务，因此服务对象可以认为是复杂任务。 组织形式 从组织形式上来看，由于agent具备了行动能力，所以和chabot产生了组织形式的不同。 chatbot主要的构成是一问一答的形式，包括我们调用大模型api一般也遵循这个结构，可以表示为{[q0,a0],[q1,a1],…[qt,at]}。 agent记忆的构成以最常见的react模式为例，主要是动作(tool)和动作结果(tool_result)的时序集合，可以表示为{a0,o0,a1,01,…at,ot}。 维护重点 对于记忆和上下文，很重要的一个功能是维护，但维护的侧重点也是有所不同的。 chabot的上下文虽然也存在前后关联，不会每一轮都紧密联系，但会存在频繁的意图切换，如何理解意图并且实现有效的意图切换识别是上下文维护的重点。 而agent记忆的每一个步骤都是按迭代规划进行的，缺失某个步骤或跳过某个步骤都可能会导致任务失败，因此它的维护重点是如何在有限的窗口中记录对下一步决策产生影响的所需关键信息。 另外agent和chatbot还存在一个很大不同的点是的必要性。对于chatbot，长期记忆主要是记住个人信息和偏好用于个性化服务。而对于agent，长期记忆需要通过情景记忆来记住之前的迭代轨迹，这样不仅能通过检索的方式来获取与当前决策相关的上下文信息，还可以实现经验复用，在下一次遇到类似任务时，可以将之前的经验作为参考,马普所今年2月份发这篇论文时候就指出情景记忆是当前agent所缺少的[1]。 agent短期记忆-业界技术分享 anthropic anthropic提到agent在长程任务上的三种管理上下文方式[2]包括:压缩,结构化笔记和采用子agent架构。 压缩通过对上下文关键内容的提取，改写和无关内容删除实现上下文瘦身； 结构化笔记是把关键信息以结构化形式存入笔记，让agent可以阅读到关键信息； 子agent架构则是通过子agent维护自己的独立上下文再将关键结果返回主agent实现上下文解耦。 oepnai openai的短期记忆管理[3]则是围绕agent sdk来谈到管理短期记忆的两个主要方式:裁剪（trimming）和压缩（summarizing）。 压缩和anthropic的compact是一样的，裁剪就是把旧的历史信息直接剪掉。 trimming的好处是实现比较简单，延时友好而且不会引入偏移信息（相比压缩），但缺点也显而易见，裁剪的内容可能包含当前决策需要的信息，所以一般适用于任务独立，上下文关联不大，低延迟要求场景。 langchain & manus langchain与最近的一次交流[4]提到manus的三种上下文管理方式:reduce ，offload context和isolate context。 reduce context包括将工具执行结果进行压缩放在窗口内，而降完整结果保存在文件系统中，在上下文触发窗口限制时对整个轨迹进行整体压缩； context isolate类似于anthropic的sub agent方法，但细分为两种方式：对于简单任务main agent通过function call的方式将指令传递给子agent，子agent在自己的窗口执行任务；而对于复杂任务，子agent会和主agent共享上下文。 context offloading和anthropic的结构化笔记虽然都是将内容存入文件，但处理思路不一样。manus的方式是将大多数操作卸载到沙盒层，在沙盒中通过bash工具就可以实现多样化的文件读写操作，这样就可以把工具执行结果保存到文件，在需要时通过bash的grep等查询命令进行访问。另外manus的这个设计相当于把大部分先验知识文件化，让agent按需通过读取文件内容获取先验来指导行动，anthropic的skill实现应该也是类似的思路。 agent记忆-项目实践 初版记忆实现 在实际搭建agent时，工具模块，记忆模块，提示词模块是三个重要的基础模块。工具模块和提示词模块相对简单或者说比较成熟的方案，而记忆模块的搭建则有不同的设计思路和实现方式，但核心思路一致 - “给agent提供恰当的上下文”，但难就难在"恰当"，首先受限于LLM的上下文窗口，所以累计上下文就不能过长。 另外上下文中堆积无关或者重复的内容不但会影响推理规划，也是不经济的。还有一个重要原因是上下文中的内容对于agent来说不是等权重的，对于当前决策而言，有的内容相对其它内容就会更重要，类似于需要一个attention机制来选择关键信息，那以什么形式来管理上下文获取更相信的信息加入就尤为关键了。 在近期的一个agent项目实践中，实现记忆模块的初始版本，设定的原则是"状态是记忆的投影"，以记忆作为事实的唯一来源，同时要求不在agent中维护状态，把记忆事实作为状态来源，放入agent的上下文中让agent自己进行决策。思路看上去是没有问题，但实际测试后就发现想简单了。 对于agent而言本身依赖的LLM是无状态的，所以agent也可以认为是无状态的，但是记忆的目的就是为了让agent具有状态。在初版的实现里，每一轮迭代都把obs写入工作记忆，同时读取当前轮之前的工作记忆中的结构化历史信息，把obs作为上下文唯一来源，直接注入到下一轮迭代的上下文，这样做是比较省事，但是一旦agent内部迭代出现问题，因为obs和工作记忆之间的这种耦合设计，很难追溯问题来源。 第二版记忆重构优化 在发现第一版的问题后，开始进行第二版改进。第二版的改进主要是基于看到的相关的技术博客和论文，重新设计了记忆方案。首先记忆模块的目录设计应该把短期记忆和长期记忆做清晰分划分，维护当前agent迭代执行任务所需上下文的就是短期记忆(工作记忆)，而记录完整迭代过程的是长期记忆（情景记忆），产生对应产出的也是长期记忆(语义记忆)。其中比较容易混淆的是工作记忆和情景记忆，从持久化的角度来说，把工作记忆持久化就可以理解为情景记忆，但实际上是存在差别的。 对于一个agent的迭代轨迹{a0,o0,a1,o1,…at,ot},可以直接把这个迭代轨迹放入上下文，也可以对这个迭代轨迹的每一步进行摘要提取，仅保留关键信息和引用，比如某步生成了一个很大的结构化，在进入下一轮时没有必要把整个json全部放入上下文，可以只放入一个引用，但是会把完整的json存入情景记忆，在下一轮迭代使用这个引用时再从情景记忆中取出这个对应的json，这样能避免大段内容直接进入到上下文中。 同时还需要考虑到上下文长度限制和成本问题，一般的工作记忆还会考虑使用最近k轮的策略，上下文只保留最近k轮的迭代记录，但是全局信息以结构化的信息记录，把这个结构化信息也注入到上下文中，这样也不至于让agent丢失掉全局信息。而第一版的问题就在这里，状态不应该只是记忆的投影，状态是对记忆的删减和加工，实际上的改进就是在短期记忆和长期记忆之间加一个桥接适配层，来实现短期记忆和长期记忆的搭配使用。 而为了agent项目的阶段性扩展和迭代，在前期工程化实现时就应该考虑长期记忆。在一个agent的迭代循环里，如果迭代轮数比较长，上下文窗口和LLM的上下文利用效率已经开始明显下降，就需要考虑结合长期记忆使用了。而为了缩减上下文，在删减掉比较早期的迭代信息后，需要识别出长期记忆中已保存的迭代记录中，哪些记忆内容会对当前轮决策有用，就选择加入到上下文。这个一般会使用retrival的方法，从长期记忆中进行检索。技术实现上会结合结构化和向量检索，而实际的实践需要根据场景需求去做设计和调整记忆存储和读写方式，可以使用slot，sql数据库，向量数据库，图数据库等等。 实践过程汇总有一个原则可以参考：记忆模块在开始实现之初，就应该把短期记忆和长期记忆进行解耦设计，这不但为上下文管理留有比较大的优化空间，在符合可审计性原则之外还为经验复用和未来可能的RL积累数据基础。 同时第二版的改进上，还有一个比较重要的改进点是还原了obs的单纯职责，obs只应该对当前轮的act和执行结果进行记录，不应该注入历史内容，obs保持职责单一只把当前轮的执行和执行结果(或摘要)放到工作记忆，工作记忆再去通过记忆模块补充历史上下文，这样修改之后，obs和工作记忆的职责也分的比较清晰了。 另外在agent的工层化实现过程中，造成可审计比较困难的一个点就是对工程化实现过程的不同组件的职责理解和划分不清晰，一旦出了bug，bug溯因就会因为这种不清晰的边界设计增加debug的难度，所以需要在设计之初就厘清不同模块的边界再动手进行实现。 agent记忆相关研究进展 上面提到RL微调，就再展开谈一下在agent在记忆管理方向的相关研究。agent记忆管理是一个很复杂的问题，从工程角度来看，agent的记忆管理可以分为两类技术方案，一种将复杂问题简化，另外一种是自动化。目前相关的记忆研究在这两个方向论文也比较多，找到了几篇比较有代表性的论文。前者是提供系统化/可插拔的记忆管理底座框架，如[5]，A-MEM[6]，后者是将手动/规则维护记忆的方式转为自动化，如Memory‑R1[7]，MEM1[8]，Memp[9]， MEMSearcher[10]等。 ...