AI Agent Harness状态管理:长对话上下文维护
AI Agent Harness状态管理:长对话上下文维护
一、引言 (Introduction)
1.1 钩子 (The Hook)
想象你正在用一个号称“全知全能”的AI Agent助手规划一场为期14天的欧洲蜜月旅行——这是2024年第三季度GitHub上Star数突破150k的热门开源旅行Agent「VoyagerLite」。
第一天的对话很顺利:你告诉它你们是刚毕业两年的程序员情侣,预算合计€8000(不含购物),偏好自然风光、中世纪小镇和工业遗迹类的极客打卡点,不会开车,时间定在明年4月15日-28日(避开复活节高峰前后的尾期,又能赶上南法薰衣草田初开的预热、荷兰郁金香的末班车残株展——因为早10天全价票,残株展荷兰人自己更爱逛,体验感好3倍,是「极客精打细算」里的知识点),住店标准是四星但必须带独立阳台晾洗冲锋衣(蜜月不想手洗大件也不想天天扛去洗衣店,阳台刚需),吃不吃辣完全无所谓但要避开生牛肉和太腥的海鲜。
VoyagerLite噼里啪啦打了2000字的初稿,第二天你补了一句:“哦对了,忘了说我女朋友有轻微花粉过敏(预热期薰衣草还好,但南法小镇路边夹竹桃、4月荷兰农场附近的毛茛是重灾区!行程里绝对不能有露天农场、夹竹桃密集的街道!),还有我昨天忘带冲锋衣的具体尺寸,但没关系住店有洗衣烘干一体,阳台刚需可以降为四星民宿有烘干机就行——冲锋衣速干面料薄,烘干机15分钟搞定,预算紧张€8000可以砍€500买个荷兰工业设计的复古耳机当纪念品(「极客纪念品指南」第一期推荐过Urbanears的 Plattan 2复刻工业黑胶版本,残株展海牙有快闪店打7折还送同色系收纳盒!海牙本来就在工业遗迹清单里对吧?昨天初稿里列了海牙皇家造船厂对吧?能不能把皇家造船厂和快闪店安排在同一天下午逛,上午逛美术馆,避开美术馆周末——哦对时间是15-28,中间有20-21是周六日!昨天初稿美术馆居然安排在周六!赶紧调整周末全户外但避花粉!避夹竹桃!避残株展以外的露天郁金香田!哦对海牙附近有一个Kinderdijk风车村是残株展配套!能不能把Kinderdijk安排在周日!还有女朋友有轻度恐高!昨天安排的科隆大教堂登顶一定要取消!科隆大教堂只逛一层的玻璃彩绘馆就行!还有科隆有没有四星带烘干的民宿!科隆附近的亚琛有工业遗迹对吧?能不能调整科隆只住一晚,玻璃彩绘馆加亚琛半日游当天走!哦对还有€8000砍€500之后是€7500对吧?Urbanears的快闪店记得标7折收纳盒记得标!哦对残株展快闪店Urbanears Plattan 2复刻黑胶版本的收纳盒是用废弃造船厂钢板做的对吧?太符合极客工业遗迹主题了!一定要强调!一定要把钢板收纳盒加到蜜月愿望清单的第一位!冲锋衣晾洗阳台刚需彻底取消!彻底取消!科隆的四星带烘干民宿要选离玻璃彩绘馆步行10分钟以内的!亚琛工业遗迹选废弃的RWTH亚琛工业大学的老实验室对吧?昨天的极客打卡清单里有!女朋友花粉过敏能不能戴海牙快闪店Urbanears Plattan 2复刻黑胶送的防尘耳塞当临时花粉面罩?不行不行,还要买专用的无香N95口罩,能不能在€7500预算里再挤€50买三天的专用口罩?€7500砍€50是€7450!对!砍砍砍!极客蜜月就是要极致性价比加极致工业遗迹体验加极致复古耳机加极致无香N95!还有科隆能不能不吃当地著名的烤猪肘?烤猪肘太腻了,女朋友最近在减肥!能不能换成亚琛工业大学老实验室附近的素食三明治店?那家店在TripAdvisor上评分4.9,老板也是前RWTH的程序员!素食三明治里面有海藻类,不怕腥吧?昨天女朋友说避开太腥的海鲜,海藻应该不算太腥吧?对!不算!不算!老板还是前程序员,一定要和他聊聊开源旅行Agent的开发!哦对VoyagerLite能不能在日程里加一个「和素食三明治店老板聊开源」的备注!备注优先级最高!优先级最高!备注标红!备注加时间戳!时间戳2025年4月20日下午5点10分-5点40分(刚好三明治店下班前10分钟不用排队)!备注加老板的GitHub账号假设!假设老板GitHub账号是@aachen_programmer_vegan!对!加进去!加进去!加进去!预算€7450!绝对不能超!绝对不能!避花粉!避夹竹桃!避露天农场!避太腥的海鲜!避烤猪肘!避复活节!避周末美术馆!避科隆大教堂登顶!加Urbanears快闪店!加钢板收纳盒!加无香N95!加素食三明治店老板聊开源!加RWTH老实验室!加Kinderdijk风车村残株展!调整科隆只住一晚!调整科隆到亚琛当日往返!预算€7450!一分不能多!一分不能!一分!!!”
好了,现在问题来了——如果你用的不是一个有完善状态管理的AI Agent,而是普通的GPT-4 Turbo、Claude 3 Opus甚至Gemini Pro 1.5 Flash单轮或简单记忆拼接的对话,你这段话发出去之后会发生什么?
大概率是这样的:
- 模型失忆第一弹:它会把你第一天说的€8000预算全忘了,直接给你推荐€12000的方案。
- 模型失忆第二弹:它会把女朋友的花粉过敏全忘了,把Kinderdijk风车村安排在夹竹桃盛开的街道附近。
- 模型失忆第三弹:它会把科隆大教堂登顶取消的要求全忘了,标成周六上午必须的行程。
- 模型失忆第四弹:它会把素食三明治店老板聊开源的要求全丢了。
- 模型崩溃:就算它记住了一部分,简单的滑动窗口(Sliding Window)记忆机制(比如只保留最近的2000个Token对话)也会把第一天的核心信息(预算范围、旅行时间、偏好自然风光/中世纪小镇/工业遗迹、不会开车、速干面料冲锋衣可以取消阳台等)全部挤出去。
- 极端情况:它可能会反过来问你:“请问您是要规划一场旅行吗?预算多少?时间什么时候?”——完全把你前一天的2000字对话当空气。
这就是没有完善状态管理的长对话的痛点——模型的记忆像金鱼的尾巴,游过7秒就忘得一干二净。
1.2 定义问题/阐述背景 (The “Why”)
1.2.1 核心背景:Agent时代的到来,长对话是刚需
2023年被称为“AI大模型元年”,而2024年则是**“AI Agent元年”——从OpenAI的GPT-4o推出的Assistants API(内置了Retrieval、Code Interpreter、Function Calling三大能力,还有原生的「Threads」「Messages」「Runs」状态管理体系),到Anthropic的Claude 3 Workbench**,再到国内的智谱AI的智谱Agent、百度文心一言的文心Agent Studio、阿里通义千问的通义千问Agent Platform,再到开源界的LangChain LangGraph、AutoGen、CrewAI、Voyager(Minecraft全自动挖矿打怪Agent鼻祖)、GPT-Engineer,AI Agent已经从2023年的“玩票性质”(比如AutoGPT早期版本每天只能挖几块石头,还会经常迷路撞墙),变成了2024年的“实用工具”——GitHub上Star数超过100k的Agent相关项目已经超过5个,企业级的Agent应用场景已经覆盖了客户服务、智能运维、代码生成与调试、法律文书审查、医疗健康咨询、金融投资分析、旅行规划、教育辅导等几乎所有领域。
而所有这些实用的Agent应用场景,几乎都离不开「长对话上下文维护」——比如:
- 客户服务Agent:用户可能会连续咨询3天的退款流程、物流追踪、商品退换货规则,甚至第一天说“我买了一台iPhone 16 Pro Max,昨天刚收到,但是摄像头有划痕”,第三天说“能不能换成银色的iPhone 16 Pro Max 2TB版本?我昨天没仔细看划痕,其实很严重”——如果Agent没有记住第一天的iPhone型号、颜色、存储、摄像头划痕的问题,第三天的对话就会彻底崩盘。
- 智能运维Agent:运维工程师可能会连续和Agent沟通24小时的服务器故障排查——第一天凌晨2点说“服务器192.168.1.100的CPU使用率突然飙升到99%,持续了5分钟,现在恢复正常了”,第一天上午9点说“能不能帮我查一下凌晨2点CPU使用率飙升的原因?从系统日志来看,当时有一个Python脚本在跑,PID是12345”,第一天下午3点说“哦对了,那个Python脚本是我昨天下午部署的,用来做日志分析的,有没有可能是日志文件太大了?”,第一天晚上8点说“日志分析脚本我已经优化了,能不能帮我监控192.168.1.100的CPU使用率,再超过80%就发邮件给我?”——如果Agent没有记住之前的所有信息(服务器IP、故障时间、PID、脚本用途、优化动作、监控阈值),就不可能完成这么复杂的运维任务。
- 代码生成与调试Agent:程序员可能会连续和Agent沟通1周的代码开发——第一天说“能不能帮我写一个Python脚本,用来爬取GitHub上Star数超过10k的Python项目的README.md文件?”,第二天说“哦对了,要加上反爬虫机制,比如设置User-Agent、设置延迟、设置代理IP池”,第三天说“代理IP池能不能用免费的?比如从https://www.free-proxy-list.net/ 爬取?”,第四天说“哦对了,还要加上异常处理,如果代理IP失效了,就自动切换下一个,如果爬取失败了,就重试3次”,第五天说“能不能帮我调试一下?刚才跑的时候报错了,错误信息是‘Connection refused by proxy’”,第六天说“哦对了,还要加上数据存储,把爬取到的README.md文件保存到MongoDB数据库里”,第七天说“能不能帮我优化一下性能?现在爬取100个项目要花10分钟,太慢了”——如果Agent没有记住之前的所有代码修改、错误信息、需求变更,就不可能完成这么复杂的代码开发任务。
1.2.2 核心问题:单轮对话、简单记忆拼接、滑动窗口记忆都不够用
那现在市面上的大模型和简单的Agent框架,是怎么处理长对话上下文的呢?主要有以下三种方式:
方式一:单轮对话(Stateless)
这是最原始的方式——模型根本不记住之前的任何对话,每一轮对话都是独立的。比如你用GPT-3.5 Turbo的单轮API接口(不使用Messages数组,只使用Prompt参数),你发“1+1等于几?”,它回“2”;你接着发“再加2等于几?”,它回“什么加2?请明确你的问题”——完全失忆。
这种方式的优点是:实现简单、成本极低(不需要存储任何状态)、Token消耗可控(每一轮对话只消耗当前Prompt的Token)。
缺点是:只能处理非常简单的单轮任务,完全无法满足长对话的刚需——现在除了一些非常简单的工具类应用(比如翻译、文本摘要的单轮调用),几乎没有人用这种方式了。
方式二:简单记忆拼接(Full History Concatenation)
这种方式稍微先进一点——模型会把之前的所有对话历史(用户输入+模型输出)全部拼接成一个超长的Prompt,然后一起发给大模型。比如你用GPT-3.5 Turbo的Messages数组接口,把所有之前的Messages都放进去,模型就能记住之前的所有对话了。
这种方式的优点是:实现也比较简单、只要大模型的上下文窗口(Context Window)足够大,就能记住所有的对话历史。
缺点是:Token消耗极高、上下文窗口有限制、大模型处理超长Prompt的速度会变慢、大模型可能会出现「注意力分散」(Attention Dilution)的问题——也就是模型虽然看到了所有的对话历史,但会忽略掉一些早期的、但非常重要的信息。
比如GPT-3.5 Turbo的上下文窗口是16k Token(约12000个汉字),Claude 3 Haiku是200k Token(约150000个汉字),Claude 3 Opus是200k Token(约150000个汉字),Gemini Pro 1.5 Flash是1M Token(约750000个汉字),Gemini Pro 1.5 Ultra是12M Token(约9000000个汉字)——虽然现在Gemini Pro 1.5 Ultra的上下文窗口已经非常大了,但Token消耗极高(比如Gemini Pro 1.5 Ultra的输入Token价格是$1.25/1M,输出Token价格是$5/1M,如果你每次都把1M Token的对话历史发过去,输入一次就要花$1.25,输出一次哪怕只有1000 Token也要花$0.005——如果是企业级的应用,每天有1000个用户,每个用户每天有10轮对话,那每天的输入Token消耗就是1000101M=10000M,输入成本就是10000*$1.25=$12500,输出成本就算是1000101000*$0.005/1M= $0.05——每天总成本就是$12500.05,每月就是$375001.5,每年就是$4500018——这对大多数中小企业来说都是不可承受的),而且大模型处理超长Prompt的速度会非常慢(比如Gemini Pro 1.5 Ultra处理12M Token的Prompt要花几分钟甚至几十分钟),还有注意力分散的问题——就算你把1M Token的对话历史发过去,模型也可能会忽略掉一些早期的、但非常重要的信息(比如你第一天说的€8000预算、女朋友的花粉过敏等)。
方式三:滑动窗口记忆(Sliding Window)
这种方式是对简单记忆拼接的优化——模型只会保留最近的N个Token或最近的M轮对话历史,把早期的对话历史全部丢弃。比如你设置滑动窗口为最近的20轮对话或最近的4k Token,模型就只会记住最近的那一部分对话。
这种方式的优点是:实现也比较简单、Token消耗可控、大模型处理速度快。
缺点是:会丢弃早期的、但非常重要的信息——也就是我们开头说的“模型的记忆像金鱼的尾巴,游过7秒就忘得一干二净”。比如你用滑动窗口为最近的20轮对话,规划欧洲蜜月旅行的时候,前15轮对话都是核心信息(预算、时间、偏好、过敏、恐高等),后5轮对话都是细节调整,滑动窗口就会把前15轮核心信息全部挤出去,模型就会彻底失忆。
1.2.3 核心解决方案:AI Agent Harness的状态管理体系
既然单轮对话、简单记忆拼接、滑动窗口记忆都不够用,那我们需要什么样的解决方案呢?答案就是——AI Agent Harness的状态管理体系。
什么是AI Agent Harness?简单来说,AI Agent Harness就是一个用来「管理、协调、监控AI Agent」的基础设施层——它就像汽车的“线束(Harness)”一样,把汽车的各个部件(发动机、变速箱、刹车、灯光、空调等)连接起来,让它们协同工作;AI Agent Harness则把AI Agent的各个核心组件(大模型、工具集、知识库、状态存储器、调度器等)连接起来,让它们协同工作。
而状态管理体系是AI Agent Harness的核心中的核心——它就像汽车的“行车电脑(ECU)”一样,记录着汽车的所有状态(车速、油耗、水温、胎压、故障码等);AI Agent Harness的状态管理体系则记录着AI Agent的所有状态(对话历史、用户画像、任务状态、工具调用结果、知识库检索结果等),并且能够根据任务的需要,智能地从状态存储器中检索出相关的信息,组合成一个“精简但完整”的上下文,发送给大模型——既不会消耗太多的Token,也不会出现注意力分散的问题,更不会丢弃早期的、但非常重要的信息。
1.3 亮明观点/文章目标 (The “What” & “How”)
1.3.1 亮明观点
本文的核心观点是:要实现AI Agent的长对话上下文维护,必须建立一个「分层、分类、结构化、可检索、可更新、可压缩」的AI Agent Harness状态管理体系——这个体系不能是单一的记忆存储方式,而是要结合短期记忆(Short-Term Memory)、长期记忆(Long-Term Memory)、工作记忆(Working Memory)、情景记忆(Episodic Memory)、语义记忆(Semantic Memory)等多种认知科学中的记忆模型,同时结合向量数据库(Vector Database)、关系型数据库(Relational Database)、图数据库(Graph Database)、键值对数据库(Key-Value Database)等多种数据库技术,再加上智能检索(Intelligent Retrieval)、智能压缩(Intelligent Compression)、智能更新(Intelligent Updating)、**智能关联(Intelligent Association)**等多种算法,才能真正满足长对话上下文维护的需求。
1.3.2 文章目标
读完这篇文章,你将能够:
- 理解认知科学中的记忆模型:包括短期记忆、长期记忆、工作记忆、情景记忆、语义记忆等,以及它们如何应用到AI Agent的状态管理中。
- 理解AI Agent Harness状态管理体系的核心组成部分:包括状态定义、状态存储、状态检索、状态更新、状态压缩、状态关联等。
- 掌握AI Agent Harness状态管理体系的实现技术:包括向量数据库(ChromaDB、Milvus、Pinecone)、关系型数据库(PostgreSQL、MySQL)、图数据库(Neo4j、Amazon Neptune)、键值对数据库(Redis、Memcached)、智能检索算法(语义搜索、混合搜索、重排序)、智能压缩算法(摘要压缩、实体提取压缩、重要性评分压缩)等。
- 通过一个实战案例,从零开始构建一个有完善状态管理的AI Agent:我们将使用Python语言,结合LangChain LangGraph(AI Agent编排框架)、ChromaDB(向量数据库)、PostgreSQL(关系型数据库)、Redis(键值对数据库)、OpenAI GPT-4o Mini(大模型),构建一个能够规划欧洲蜜月旅行的AI Agent——这个Agent将能够记住所有的早期核心信息,智能地检索相关信息,不会出现注意力分散的问题,也不会消耗太多的Token。
- 掌握AI Agent Harness状态管理体系的最佳实践:包括常见陷阱与避坑指南、性能优化、成本考量、安全防护等。
- 了解AI Agent Harness状态管理体系的行业发展与未来趋势:包括问题演变发展历史、当前主流的开源与商业方案、未来的发展方向等。
二、基础知识/背景铺垫 (Foundational Concepts)
2.1 核心概念定义:认知科学中的记忆模型
要构建一个好的AI Agent状态管理体系,我们不能只从计算机科学的角度出发——我们还需要从认知科学的角度出发,学习人类大脑的记忆模型,因为人类大脑的记忆系统是目前已知的最强大、最灵活、最节能的长对话上下文维护系统——比如你和你的朋友聊了10年前的一件小事,你还能记得清清楚楚,而你的大脑消耗的能量只有约20W(相当于一个小灯泡的功率)。
认知科学中的记忆模型有很多种,其中最经典、最常用的是Atkinson-Shiffrin记忆模型(阿特金森-希弗林记忆模型)和Baddeley工作记忆模型(巴德利工作记忆模型),以及Tulving的长时记忆分类模型(图尔文长时记忆分类模型)——下面我们就来逐一介绍这些模型,以及它们如何应用到AI Agent的状态管理中。
2.1.1 Atkinson-Shiffrin记忆模型(阿特金森-希弗林记忆模型)
Atkinson-Shiffrin记忆模型是由美国认知心理学家Richard Atkinson和Richard Shiffrin于1968年提出的——这是认知科学中第一个系统的记忆模型,至今仍然被广泛使用。
2.1.1.1 模型核心结构
Atkinson-Shiffrin记忆模型将人类的记忆系统分为三个相互独立但又相互关联的阶段:
- 感觉记忆(Sensory Memory):也叫“瞬时记忆”——是记忆系统的第一个阶段,负责接收和暂时存储来自感官(视觉、听觉、嗅觉、味觉、触觉)的信息。感觉记忆的存储时间非常短(视觉感觉记忆约为0.25-1秒,听觉感觉记忆约为2-4秒),存储容量非常大(几乎可以存储所有来自感官的信息),但如果不经过注意(Attention),信息就会很快消失。
- 短期记忆(Short-Term Memory, STM):也叫“工作记忆”(后来Baddeley对这个概念进行了扩展,我们后面会讲)——是记忆系统的第二个阶段,负责暂时存储和处理来自感觉记忆的、经过注意的信息,以及从长期记忆中检索出来的信息。短期记忆的存储时间也比较短(约为15-30秒,如果不经过复述(Rehearsal),信息就会很快消失),存储容量非常有限(根据Miller的“神奇数字7±2”理论,短期记忆的存储容量约为7±2个组块(Chunk)——比如你可以记住7个单独的数字,也可以记住7个由多个数字组成的组块,比如“13800138000”可以拆成“138”“0013”“8000”三个组块)。
- 长期记忆(Long-Term Memory, LTM):是记忆系统的第三个阶段,负责永久存储经过复述和编码(Encoding)的信息。长期记忆的存储时间非常长(可以是几分钟、几小时、几天、几年甚至一辈子),存储容量几乎是无限的(目前没有发现人类长期记忆的存储上限)。
2.1.1.2 模型的信息流动过程
Atkinson-Shiffrin记忆模型的信息流动过程如下:
- 感觉输入:来自感官的信息首先进入感觉记忆。
- 注意:只有经过注意的信息,才会从感觉记忆进入短期记忆;没有经过注意的信息,会很快消失。
- 复述:只有经过复述的信息,才会从短期记忆进入长期记忆;没有经过复述的信息,会很快从短期记忆中消失。
- 检索:当需要使用长期记忆中的信息时,会从长期记忆中检索出来,进入短期记忆进行处理。
- 遗忘:感觉记忆中的信息会因为没有经过注意而遗忘;短期记忆中的信息会因为没有经过复述而遗忘;长期记忆中的信息虽然几乎不会永久消失,但可能会因为**干扰(Interference)或提取失败(Retrieval Failure)**而暂时无法检索出来。
2.1.1.3 如何应用到AI Agent的状态管理中
Atkinson-Shiffrin记忆模型给AI Agent的状态管理提供了非常重要的启发——我们可以把AI Agent的状态管理体系也分为三个相互独立但又相互关联的存储层:
- 感觉记忆层(对应Redis等键值对数据库):用来存储AI Agent刚刚接收到的、还没有经过处理的信息——比如用户的最新输入、工具的最新调用结果、知识库的最新检索结果。感觉记忆层的存储时间非常短(比如只存储最近的1分钟或最近的10条信息),存储容量非常大(可以存储所有刚刚接收到的信息),但如果不经过“注意”(也就是AI Agent的调度器判断这些信息是否重要),就会很快被删除。
- 短期记忆层(对应Redis等键值对数据库+PostgreSQL等关系型数据库的临时表):用来存储AI Agent正在处理的、经过“注意”的信息——比如当前的对话上下文、当前的任务状态、当前的用户需求、从长期记忆中检索出来的相关信息。短期记忆层的存储时间也比较短(比如只存储当前的任务会话,任务结束后就会被归档到长期记忆层),存储容量有限(比如只存储最近的100轮对话或最近的16k Token的信息,或者根据任务的重要性动态调整),如果需要长期保存,就会被“复述”(也就是AI Agent的状态管理器将这些信息进行编码,存储到长期记忆层)。
- 长期记忆层(对应ChromaDB等向量数据库+PostgreSQL等关系型数据库+Neo4j等图数据库):用来存储AI Agent永久保存的、经过“编码”的信息——比如用户的所有历史对话、用户的画像、所有的任务历史、所有的工具调用结果、所有的知识库内容。长期记忆层的存储时间非常长(可以永久存储,除非手动删除),存储容量几乎是无限的,当需要使用这些信息时,会被“检索”(也就是AI Agent的状态管理器根据当前的任务需求,从长期记忆层中智能地检索出相关的信息)出来,进入短期记忆层进行处理。
2.1.2 Baddeley工作记忆模型(巴德利工作记忆模型)
Atkinson-Shiffrin记忆模型将短期记忆和工作记忆视为同一个概念,但后来的研究发现,短期记忆不仅仅是一个“暂时存储信息的容器”,它还是一个“处理信息的工作台”——也就是工作记忆。
Baddeley工作记忆模型是由英国认知心理学家Alan Baddeley和Graham Hitch于1974年提出的——这个模型对Atkinson-Shiffrin记忆模型中的短期记忆进行了扩展,将工作记忆分为四个相互独立但又相互关联的子系统:
- 语音回路(Phonological Loop):也叫“听觉-语言工作记忆”——负责暂时存储和处理语言、声音类的信息。语音回路又分为两个部分:
- 语音存储(Phonological Store):也叫“内耳”——负责暂时存储语言、声音类的信息,存储时间约为1.5-2秒。
- 发音复述装置(Articulatory Rehearsal System):也叫“内嘴”——负责通过默默复述的方式,将语音存储中的信息保持下来,或者将视觉类的信息转换成语音类的信息存储到语音存储中。
- 视觉空间模板(Visuospatial Sketchpad):也叫“视觉-空间工作记忆”——负责暂时存储和处理视觉、空间类的信息,比如图像、地图、物体的位置等。
- 情景缓冲器(Episodic Buffer):这是Baddeley于2000年后来添加的子系统——负责暂时存储和整合来自语音回路、视觉空间模板、长期记忆的信息,形成一个连贯的“情景”(比如你正在回忆昨天和朋友一起去看电影的情景,情景缓冲器会整合来自语音回路的电影台词、来自视觉空间模板的电影院画面、来自长期记忆的朋友的名字、电影院的位置等信息)。
- 中央执行系统(Central Executive):这是工作记忆的“指挥中心”——负责分配注意力、协调语音回路、视觉空间模板、情景缓冲器的工作、从长期记忆中检索信息、将信息编码存储到长期记忆中。
2.1.2.1 如何应用到AI Agent的状态管理中
Baddeley工作记忆模型给AI Agent的状态管理提供了更深入的启发——我们可以把AI Agent的短期记忆层(工作记忆层)也分为四个相互独立但又相互关联的子系统:
- 语言处理子系统(对应语音回路):负责暂时存储和处理语言类的信息——比如用户的最新输入、模型的最新输出、工具调用的文本结果、知识库检索的文本结果。
- 视觉空间处理子系统(对应视觉空间模板):负责暂时存储和处理视觉、空间类的信息——比如用户上传的图片、地图API返回的地图、知识库中的图像内容。
- 情景整合子系统(对应情景缓冲器):负责暂时存储和整合来自语言处理子系统、视觉空间处理子系统、长期记忆层的信息,形成一个连贯的“当前任务情景”——比如规划欧洲蜜月旅行的当前任务情景,会整合来自语言处理子系统的最新需求调整、来自视觉空间处理子系统的欧洲地图、来自长期记忆层的用户画像、第一天的核心信息、之前的所有细节调整等信息。
- 中央调度子系统(对应中央执行系统):这是AI Agent状态管理的“指挥中心”——负责判断哪些信息是重要的(注意)、分配各个子系统的工作、从长期记忆层中智能检索相关信息、将信息编码存储到长期记忆层、将当前的任务情景组合成一个“精简但完整”的上下文发送给大模型。
2.1.3 Tulving的长时记忆分类模型(图尔文长时记忆分类模型)
Atkinson-Shiffrin记忆模型和Baddeley工作记忆模型都对长时记忆进行了定义,但没有对长时记忆进行分类——后来的研究发现,长时记忆可以分为两种不同的类型:陈述性记忆(Declarative Memory)和程序性记忆(Procedural Memory)。
而陈述性记忆又可以进一步分为两种类型:情景记忆(Episodic Memory)和语义记忆(Semantic Memory)——这是由加拿大认知心理学家Endel Tulving于1972年提出的,也就是Tulving的长时记忆分类模型。
2.1.3.1 模型核心分类
Tulving的长时记忆分类模型将长时记忆分为三个层次:
- 第一层:陈述性记忆 vs 程序性记忆
- 陈述性记忆(Declarative Memory):也叫“外显记忆(Explicit Memory)”——是指可以有意识地回忆出来的、关于“是什么(What)”的记忆,比如事实、事件、概念等。陈述性记忆可以用语言表达出来。
- 程序性记忆(Procedural Memory):也叫“内隐记忆(Implicit Memory)”——是指不需要有意识地回忆出来的、关于“怎么做(How)”的记忆,比如骑自行车、游泳、打字、编程等。程序性记忆很难用语言表达出来,只能通过实践来掌握。
- 第二层:陈述性记忆的进一步分类——情景记忆 vs 语义记忆
- 情景记忆(Episodic Memory):是指关于个人经历的、有时间和空间标记的、“自传体式”的记忆,比如“我昨天和朋友一起去看了《复仇者联盟5》,电影院在朝阳区万达广场,电影票是35块钱一张,我们买了爆米花和可乐,电影很好看,最后钢铁侠复活了”——情景记忆有明确的“时间戳”和“地点戳”,是关于“我在什么时候、什么地方、经历了什么事情”的记忆。
- 语义记忆(Semantic Memory):是指关于客观世界的、没有时间和空间标记的、“百科全书式”的记忆,比如“地球是圆的”“北京是中国的首都”“Python是一种编程语言”“1+1等于2”——语义记忆没有明确的“时间戳”和“地点戳”,是关于“这个世界是什么样子的”的记忆。
2.1.3.2 如何应用到AI Agent的状态管理中
Tulving的长时记忆分类模型给AI Agent的状态管理提供了最核心的启发——我们可以把AI Agent的长期记忆层也分为三个相互独立但又相互关联的存储区域,并且使用不同的数据库技术来存储不同类型的记忆:
- 程序性记忆存储区域(对应PostgreSQL等关系型数据库的存储过程/触发器、或者LangChain的Tools库):用来存储AI Agent关于“怎么做”的记忆——比如“如何调用天气API”“如何调用地图API”“如何调用酒店预订API”“如何规划旅行路线”“如何进行文本摘要”“如何进行实体提取”等。程序性记忆一般是AI Agent的开发者预先定义好的,或者AI Agent通过强化学习(Reinforcement Learning)自己学到的——这部分记忆一般不需要经常更新,使用关系型数据库的存储过程/触发器或者专门的Tools库来存储就可以了。
- 情景记忆存储区域(对应ChromaDB等向量数据库+PostgreSQL等关系型数据库+Neo4j等图数据库):用来存储AI Agent关于“个人经历”的记忆——比如“用户张三在2025年4月1日咨询了欧洲蜜月旅行的规划,预算合计€8000,时间定在2025年4月15日-28日,偏好自然风光、中世纪小镇和工业遗迹类的极客打卡点,不会开车,住店标准是四星但必须带独立阳台晾洗冲锋衣,吃不吃辣完全无所谓但要避开生牛肉和太腥的海鲜,第二天又补了女朋友有轻微花粉过敏、科隆大教堂登顶要取消、预算可以砍€500买Urbanears的复古耳机等信息”——情景记忆有明确的“时间戳”“用户ID戳”“任务ID戳”“地点戳”等,需要能够根据时间、用户、任务、地点等多个维度进行检索,因此需要结合向量数据库(用来进行语义搜索)、关系型数据库(用来存储结构化的元数据,比如时间戳、用户ID、任务ID、地点戳等)、图数据库(用来存储情景记忆之间的关联关系,比如“用户张三的第一次欧洲蜜月旅行咨询”和“第二次欧洲蜜月旅行咨询”之间的关联关系,“Urbanears的复古耳机”和“海牙的快闪店”之间的关联关系)。
- 语义记忆存储区域(对应ChromaDB等向量数据库+PostgreSQL等关系型数据库的知识表):用来存储AI Agent关于“客观世界”的记忆——比如“荷兰的残株展是每年4月中下旬举办的”“Urbanears的Plattan 2复刻工业黑胶版本在海牙的皇家造船厂附近有快闪店,每年残株展期间打7折还送同色系废弃造船厂钢板收纳盒”“Kinderdijk风车村是荷兰的世界文化遗产,每年残株展期间有配套活动”“科隆大教堂的玻璃彩绘馆非常有名,但是周末人很多,建议工作日去”——语义记忆没有明确的“时间戳”“用户ID戳”“任务ID戳”,但需要能够根据语义进行检索,因此需要结合向量数据库(用来进行语义搜索)、关系型数据库(用来存储结构化的元数据,比如知识的类别、来源、更新时间等)。
2.2 相关工具/技术概览
在上一节中,我们介绍了认知科学中的记忆模型,以及它们如何应用到AI Agent的状态管理中——在这一节中,我们将介绍实现AI Agent Harness状态管理体系所需要的核心工具/技术,包括:
- AI Agent编排框架:用来协调、管理AI Agent的各个核心组件(大模型、工具集、状态存储器、调度器等)。
- 大模型:用来理解用户的需求、生成对话内容、调用工具、进行信息编码和摘要等。
- 向量数据库:用来存储和检索语义信息(比如情景记忆的文本内容、语义记忆的文本内容、用户的最新输入的向量表示等)。
- 关系型数据库:用来存储和检索结构化的元数据(比如情景记忆的时间戳、用户ID、任务ID、地点戳等,语义记忆的类别、来源、更新时间等,程序性记忆的存储过程/触发器等)。
- 图数据库:用来存储和检索信息之间的关联关系(比如情景记忆之间的关联关系、语义记忆之间的关联关系、用户和任务之间的关联关系等)。
- 键值对数据库:用来存储和检索短期记忆、感觉记忆的信息(比如用户的最新输入、工具的最新调用结果、当前的任务状态等)。
下面我们就来逐一介绍这些工具/技术的主流开源与商业方案,以及它们的优缺点对比。
2.2.1 AI Agent编排框架
AI Agent编排框架是AI Agent Harness的“骨架”——没有它,AI Agent的各个核心组件就无法协同工作。目前主流的AI Agent编排框架有以下几种:
| 框架名称 | 开发公司/组织 | 开源/商业 | 核心特点 | 优缺点 | 适用场景 |
|---|---|---|---|---|---|
| LangChain LangGraph | LangChain | 开源(MIT许可证) | 1. 基于状态机(State Machine)的编排方式,非常适合处理复杂的、有状态的任务(比如长对话、任务规划、多步骤工具调用); 2. 支持循环(Loop)、条件分支(Conditional Branch)、并行(Parallel)等多种控制流; 3. 支持持久化状态(Persistence),可以将状态保存到Redis、PostgreSQL、SQLite等数据库中; 4. 与LangChain的其他组件(比如LangChain Core、LangChain Community、LangChain Text Splitters、LangChain Embeddings、LangChain Vector Stores等)无缝集成; 5. 支持多种大模型(OpenAI、Anthropic、Google、智谱AI、百度文心一言、阿里通义千问等); 6. 有非常活跃的社区和丰富的文档、教程、示例。 | 优点: 1. 基于状态机的编排方式非常直观,容易理解和调试; 2. 支持持久化状态,非常适合处理长对话; 3. 与LangChain生态无缝集成,开发效率高; 4. 社区活跃,文档丰富,遇到问题容易解决。 缺点: 1. 学习曲线相对较陡,尤其是对于没有接触过状态机的开发者; 2. 性能相对较低,尤其是对于非常复杂的、有很多循环和并行的任务; 3. 目前还处于早期阶段(截至2024年10月,最新版本是0.2.x),API还不够稳定。 | 1. 长对话AI Agent; 2. 任务规划AI Agent; 3. 多步骤工具调用AI Agent; 4. 复杂的业务流程自动化AI Agent。 |
| AutoGen | Microsoft | 开源(MIT许可证) | 1. 基于多智能体协作(Multi-Agent Collaboration)的编排方式,非常适合处理复杂的、需要多个智能体协同工作的任务(比如代码生成与调试、法律文书审查、医疗健康咨询等); 2. 支持对话式协作(Conversational Collaboration),多个智能体可以通过自然语言对话来协同工作; 3. 支持自定义智能体(Custom Agent),可以根据任务的需要自定义智能体的角色、能力、提示词等; 4. 支持工具调用(Tool Calling)、代码执行(Code Execution)、**检索增强生成(Retrieval-Augmented Generation, RAG)**等多种能力; 5. 支持多种大模型(OpenAI、Anthropic、Google、智谱AI、百度文心一言、阿里通义千问等); 6. 有非常活跃的社区和丰富的文档、教程、示例。 | 优点: 1. 基于多智能体协作的编排方式非常适合处理复杂的任务; 2. 对话式协作非常直观,容易理解和调试; 3. 支持自定义智能体,灵活性非常高; 4. 社区活跃,文档丰富,遇到问题容易解决。 缺点: 1. 学习曲线相对较陡,尤其是对于没有接触过多智能体协作的开发者; 2. 状态管理相对较弱,虽然支持持久化状态,但不如LangGraph直观和方便; 3. 性能相对较低,尤其是对于需要多个智能体频繁协作的任务; 4. 目前还处于早期阶段(截至2024年10月,最新版本是0.2.x),API还不够稳定。 | 1. 代码生成与调试AI Agent; 2. 法律文书审查AI Agent; 3. 医疗健康咨询AI Agent; 4. 金融投资分析AI Agent; 5. 复杂的内容创作AI Agent。 |
| CrewAI | João Moura | 开源(MIT许可证) | 1. 基于角色分配(Role Assignment)和任务委派(Task Delegation)的编排方式,非常适合处理有明确角色分工的任务(比如内容创作团队、软件开发团队、市场营销团队等); 2. 支持自定义角色(Custom Role)、自定义任务(Custom Task)、自定义工具(Custom Tool); 3. 支持多智能体协作、工具调用、RAG等多种能力; 4. 与LangChain生态无缝集成; 5. 支持多种大模型; 6. 有非常简洁的API和丰富的文档、教程、示例。 | 优点: 1. 基于角色分配和任务委派的编排方式非常直观,容易理解和使用; 2. API非常简洁,开发效率高; 3. 与LangChain生态无缝集成; 4. 社区活跃,文档丰富,遇到问题容易解决。 缺点: 1. 状态管理相对较弱; 2. 控制流相对简单,不如LangGraph灵活(虽然最新版本也支持循环和条件分支); 3. 性能相对较低。 | 1. 内容创作团队AI Agent; 2. 软件开发团队AI Agent; 3. 市场营销团队AI Agent; 4. 简单的多步骤任务AI Agent。 |
| OpenAI Assistants API | OpenAI | 商业(按Token和使用量付费) | 1. 原生的、托管式的AI Agent服务,不需要自己搭建基础设施; 2. 内置了Threads(状态管理)、Messages(消息存储)、Runs(任务执行)、Retrieval(RAG)、Code Interpreter(代码执行)、**Function Calling(工具调用)**等多种核心能力; 3. 支持持久化状态,Threads可以永久存储(除非手动删除); 4. API非常简洁,开发效率极高; 5. 有非常丰富的文档、教程、示例。 | 优点: 1. 原生的、托管式的服务, |
