你有没有遇到过这种情况：让同事帮你办一件复杂的事，比如订机票、改行程、退货换货，一开始他记得清清楚楚你的所有要求，但办到第五步、第十步的时候，突然发现他早就忘了你最初说的"必须靠窗座位"，或者忘了前面查过的某个关键信息，开始自说自话地瞎搞。
这不是人才会有的毛病，AI智能体也一样。
现在的大语言模型，也就是我们常说的AI智能体，在处理简单任务时表现得相当靠谱。让它查个资料、写段代码，一步到位没问题。但一旦任务变长，需要它连续做十几步、几十步操作，中间还要不断调用各种工具、读取各种反馈信息，它的表现就开始滑坡。原因说起来也简单：任务要求、之前收集到的证据、当前执行到哪一步了，这三样东西在漫长的执行过程中会逐渐"失联"。到了第三十步，AI可能已经忘了第五步查到的关键数据是干什么用的，也忘了最初任务里那条容易被忽略但很重要的限制条件。
这篇来自北京航空航天大学和奇安信集团的论文，就是奔着这个问题去的。他们提出了一个叫做**自适应一致性图**（Adaptive Consistency Graph，简称ACG，一种给AI智能体设计的执行记忆系统，用来在长任务中持续追踪证据来源并按需组织上下文）的方法，试图从根子上解决AI智能体"越做越糊涂"的问题。
先说结论：在他们的测试里，用了ACG之后，GPT-5.6-luna这个模型的平均任务成功率从44.5%涨到了50.2%，在其中一个信息检索类的基准测试上，成功率从62.4%直接跳到73.5%。这不是一个花哨的技巧，而是一整套重新设计智能体"记忆方式"的思路。
当前方法都卡在哪儿了
要理解ACG解决了什么问题，得先看看之前的人是怎么处理"AI记性不好"这件事的。
第一类思路是让AI自己反思总结。比如有一种叫Reflexion的方法，让AI在任务失败后用语言复盘一下哪里错了，下次注意；还有ExpeL，从成功和失败的经历里提炼可复用的经验。这些方法的问题在于，反思和总结的过程本身就是一次压缩，AI把冗长的执行记录浓缩成几句话的"教训"，但压缩必然丢信息。等到后面某一步真的需要用到那个被压缩掉的细节时，AI已经找不回来了。
这就好比你让人写会议纪要，纪要写得再好，也不可能把会上说的每一句原话都记下来。等哪天真出了争议，需要核实某个人当时到底是怎么表态的，光看纪要是不够的，你得回去翻录音。如果压根没留录音，那这场争议就永远说不清楚。
第二类思路是检索增强，也就是**RAG**（Retrieval-Augmented Generation，检索增强生成，指让AI在生成回答前先从外部资料库里检索相关信息，再结合检索到的内容作答）技术。RAG本身很好用，但直接应用在长任务执行场景里会有个问题：检索出来的一条孤立信息，有时候脱离了它产生时的具体情境，AI根本看不懂它为什么重要。比如你检索到一句"用户偏好靠窗座位"，但你不知道这句话是在哪一步、针对哪个航班段说的，那这条信息的价值就大打折扣。
第三类思路是图结构记忆，比如**HippoRAG**（一种受神经科学启发的长期记忆机制，通过构建实体关系图来支持跨文档的多跳信息检索）这样的方法，用图把知识点关联起来，支持跨文档的多跳查找。这个思路很有启发性，但HippoRAG面向的是相对静态的知识库，而AI智能体面对的是一个动态变化、随时在产生新证据的执行过程，这两者的组织逻辑不一样。
ACG的作者们显然是站在这几条路的交汇处，琢磨出了一个新方案：既要像图记忆那样保留关系结构，又要像执行日志那样保留每条证据的出处和产生场景，还要像检索增强那样能按需精准拿取信息，同时得在有限的上下文窗口里塞得下。
ACG到底是怎么运作的
ACG的核心设计可以拆成五个环节，论文里配了一张流程图，从记录、建图、检索、组织到最终呈现，一环扣一环。
**第一步是把执行过程中的每一次观察和动作都拆解成记忆单元**，也叫**Memory Unit**（记忆单元，ACG中存储执行证据的基本单位，包含内容、类型、来源引用、发生记录和结构化字段）。
每个记忆单元都记着这段内容是什么、属于什么类型、来自哪个具体的动作和工具调用、在整个执行序列里的时间顺序是什么。这里有个细节设计得挺聪明：如果同样的内容在不同时间被多次观察到，ACG不会把它们直接合并成一条记录抹掉时间线，而是让它们共享同一个内容单元，但各自保留自己独立的"发生记录"。
这个设计的价值在哪儿？想象你在盯一个仓库的库存表，同一款商品的库存数字可能今天查一次是100，明天再查一次还是100。如果系统图省事直接把这两次查询合并成"库存是100"，那你就永远不知道这个数字是不是被重复确认过、是不是稳定的。但如果两次查询各自留痕，你就能看出这是"连续两天都确认为100"，这个信息的可信度是不一样的。ACG就是坚持不做这种偷懒式的合并。
**第二步是把这些记忆单元组织成一张图**。图里的连接关系有两种：一种是语义上的关联，内容相近的记忆单元互为邻居；另一种是来源关联，同一个信息源产生的多条记录会被额外加权连在一起。论文用了一种叫**结构熵**（Structural Entropy，一种衡量图结构组织效率的指标，用来把图里的节点自动划分成有意义的局部簇）的算法把这张图自动划分成一个个局部簇，方便后续按簇检索。
值得说明的是，这里所有的关联关系都只是"这些信息可能相关"，而不是"这个信息证明了什么任务要求已经被满足"。论文特意强调了这一点：图里的连接不认证真假、不宣告任务完成，它只是帮你找到可能有用的东西，判断权还在AI手里。
**第三步是双路检索**，每次AI要做决策之前，ACG会同时用原始任务描述和刚发生的那个具体事件去检索，各自拿出一份候选证据清单，然后交替穿插取前几名，凑出一批去重后的种子节点。这批种子再沿着图往外扩散一跳，把周边相关的证据也捞进来。
为什么要两路检索而不是一路？因为只用任务描述检索，容易检索出一堆和当前具体步骤脱节的宏观信息；只用最新交互检索，又容易只见树木不见森林，忘了任务最初的大方向。两条腿走路，一条保证不偏离总目标，一条保证跟得上眼前的具体情况。
这让我想起开车用导航，你既需要一个总目的地的方向感，也需要实时路况提示。如果导航只告诉你"终点在城市另一头"而不提醒你眼前这个路口要右转，你照样会开错。反过来，如果导航只顾着报眼前的路口却忘了大方向，你可能绕来绕去回到原点。ACG的双路检索本质上就是同时要这两种信息。
**第四步是把检索到的证据和任务要求做匹配**，论文里管这个叫**需求归属**（Requirement Attribution，把执行过程中的具体动作或工具调用明确关联到它所服务的原始任务要求）。这里有个很严格的规定：只有当某个动作或工具调用明确声明了自己是为了满足哪条任务要求，这条关联才成立；如果这个归属关系模糊不清，ACG宁愿不建立这个关联，也不会靠语义相似度去"猜"着补上。
这个设计乍一看有点保守，但仔细想想是必要的。如果允许用语义相似度硬凑归属关系，很容易出现"这段话看起来和某个要求有点像，那就算它满足了"的误判，这种误判在长任务里一旦累积，后果会越来越离谱。宁可少关联，也不能瞎关联，这是ACG对可追溯性的坚持。
**第五步是在有限的预算内把这些精选证据组织成最终呈现给AI的那段上下文**，论文管这个叫**预算感知的上下文构建**（Budget-Aware Context Construction，在固定的token预算限制下，按优先级逐块加入信息，一旦超出预算立刻停止，保证最终呈现内容始终可控）。
这套机制会按照"任务要求归属、当前事件证据、历史证据、交叉引用"这样的优先级顺序往里加内容，每加一块就检查一下是否超出预算，超了就停手。预算紧张的时候，会优先保留和当前这一步直接相关的证据，把不那么紧急的历史证据的呈现方式简化。而且，如果同一条证据被多个任务要求共用，只展开一次，其他地方引用它就行，不重复占用篇幅。
这套逻辑很像你收拾一个小行李箱出门旅行。箱子容量有限，你不可能把家里所有可能用得上的东西都塞进去，你得按照"这趟旅行马上要用的""这趟旅行可能会用的""带了也不一定用得上但保险起见"这样的优先级来取舍。而那些没被装进箱子的东西，并不是被扔掉了，它们还好好地留在家里的柜子里，你需要的时候随时可以回去取。这正是ACG最关键的一个设计原则：呈现给AI的上下文是临时的、经过精简的，但背后那张完整的持久化记忆图从来没有被删减过，只是暂时没展示而已。
如果不这样设计会怎样？答案其实前面已经暗示过了，就是那些依赖生成式摘要的记忆方法的通病：一旦某条信息被压缩进摘要，原始细节就永久性地丢了。ACG选择的是"保留全部原始证据，每次只临时抽取一份精简视图"，这个设计的代价是要维护一整套持久化的图结构，计算和存储成本更高，但换来的是任何一步都可以回头找到最原始的证据出处，不会因为一次总结就把关键细节丢死。
三个测试场景，结果怎么样
论文选了三个很有代表性的测试场景。第一个叫**DeepPlanning**（一个衡量长程智能体规划能力的基准测试，包含带有严格约束条件的购物和旅行规划任务），任务是在诸多硬性限制条件下完成购物或者行程规划，很考验AI能不能从头到尾牢牢记住那些容易被忽略的约束。
第二个叫**BrowseComp-Plus**（一个基于固定语料库的信息检索基准测试，要求AI从大量文档里查找并整合信息来回答复杂问题），需要AI从一个固定的大规模文档库里反复检索、整合信息，回答复杂问题。第三个叫**SWE-bench Lite**（一个衡量AI修复真实代码仓库问题能力的基准测试子集），是让AI去修复真实代码仓库里的缺陷，这类任务往往需要理解整个项目结构，改动可能分散在好几个文件里。
测试用了两个模型，GPT-5.6-luna和DeepSeek-v4-flash，对比了包括ReAct（一种经典的"推理加行动"交替执行框架）在内的五种基线方法。
以下是核心的成功率数据（单位：百分之几）：
在GPT-5.6-luna上，ReAct的平均成功率是44.5%，ACG达到了**50.2%**。拆开看，DeepPlanning上ReAct是10.8%，ACG是**12.4%**；BrowseComp-Plus上ReAct是62.4%，ACG是**73.5%**，涨了超过十个百分点；SWE-bench Lite上ReAct是60.3%，ACG是**64.7%**。
在DeepSeek-v4-flash上，ReAct的平均成功率是43.8%，ACG达到了**45.9%**。DeepPlanning上ReAct是6.4%，ACG是**11.7%**，几乎翻倍；BrowseComp-Plus上ReAct反而领先，是68.2%对ACG的62.7%；SWE-bench Lite上ReAct是56.7%，ACG是**63.3%**。
这组数据说明什么？说明ACG在六组"模型加基准"的组合里赢了五组，输了一组，是个整体占优但不是全面碾压的结果。论文的作者也很坦诚地承认了这一点，没有夸大其词说自己全面胜出，这种如实汇报的态度在学术写作里其实挺难得。
更值得注意的是DeepPlanning这个任务，不管用哪种方法成功率都很低，最高也就12.4%。这说明带有大量硬性约束的规划任务，对现在的AI智能体来说依然是一块难啃的硬骨头，ACG确实相对领先，但离真正的实用水平还有距离。这也提醒我们，AI智能体这个领域，进步是真实的，但离"随便扔个复杂任务给它就能搞定"还早得很。
更长的任务，藏着更多的坑
论文还做了一个挺有意思的分析：把任务按照AI实际执行了多少步来分组，看看步数和成功率之间的关系。
结果发现一个很扎心的规律：执行步数越长的任务，成功率往往越低。用DeepSeek配合ReAct方法在BrowseComp-Plus上做测试，执行1到20步就结束的任务里，成功率高达97.2%；而执行到61到100步才结束的任务，成功率只剩14.1%。也就是说，那些拖得特别长的任务，大概率不是"因为复杂所以多花了些功夫最终搞定了"，而是"因为一直搞不定所以才拖得这么长"。
这个发现打破了一个直觉误区：很多人可能会觉得AI执行的步骤越多，说明它越努力、越认真，最后成功的概率应该更高才对。但数据告诉我们恰恰相反，步数拉长往往是AI陷入了某种循环或者迷茫状态的信号，而不是它在扎实地推进任务。
这就像你观察一个人修水管，如果他十分钟搞定了，大概率是真的会修；但如果他折腾了三个小时还没弄好，这时候你心里想的绝对不是"他真有耐心"，而是"这人是不是根本不会修，在瞎折腾"。执行时长本身不是能力的证明，反而常常是无能的暴露。
ACG在这个问题上表现出了自己的特点。同样是DeepSeek在BrowseComp-Plus上，ACG执行1到20步的任务成功率是88.7%，执行61到100步的降到6.9%，同样存在这个规律，说明ACG并没有神奇地消除长任务的困难。但在SWE-bench Lite上，ACG在长任务组（61到100步）的成功率是50.0%，而ReAct同组只有34.7%，这说明在代码修复这类任务里，ACG确实更擅长把原本会失败的长任务拉回正轨。
花了更多计算资源，不代表更聪明
另一个很有意思的发现是关于"调用模型的次数"和"最终成功率"之间的关系。
论文对比了几种方法在SWE-bench Lite上使用GPT-5.6-luna的调用次数中位数：ReAct是15次，COMPASS（一种把执行与上下文管理分离的对比方法）是60次，TDP*是86次，CUGA只有30.5次。但对应的成功率呢？ReAct 60.3%，COMPASS只有12.7%，TDP*是22.3%，CUGA更是低到3.7%。
这组数字放在一起看特别扎眼：TDP*用了将近ReAct六倍的调用次数，消耗的token总量是ReAct的八倍多，但成功率反而只有ReAct的三分之一左右。**更多的计算投入，非但没有换来更高的成功率，反而带来了更差的结果**。
这打破了另一个常见的直觉：很多人默认"AI想得越久、算得越多，应该越靠谱"。但这个实验清楚地说明，如果一个系统的思考方式本身有问题，那给它更多的算力和调用次数，只是在错误的路上跑得更远，不会自动纠正方向。这有点像开车走错了路，你踩再多油门也到不了目的地，只会离目的地越来越远。
ACG在这方面表现得比较克制。在SWE-bench Lite上，ACG的调用次数中位数是29次（GPT-5.6-luna）或47次（DeepSeek），虽然比ReAct的15次或44次要多，但换来的成功率提升是实打实的。在BrowseComp-Plus上用DeepSeek时，ACG的调用次数反而比ReAct更少（21次对30次），但成功率也确实略低一些（62.7%对68.2%）。这说明ACG的计算成本和收益之间的关系，是要具体场景具体分析的，不存在"用了ACG就一定又快又好"的免费午餐。
少走弯路，但不等于一定成功
论文还专门做了一套很细致的失败诊断，追踪AI在执行过程中有没有出现"接口调用被拒绝""原地重复执行相同操作""预算耗尽""最终什么都没交付"这几类具体问题。
一个挺有说服力的数据是关于重复执行的。用DeepSeek在SWE-bench Lite上测试，在那些最终失败的任务里，ACG出现"完全重复执行同一操作"的比例只有8.2%，而COMPASS是27.9%，TDP*离谱到96.4%，CUGA是64.9%，ACON是24.8%。ReAct表现更好一些，是6.2%。
这说明什么？说明ACG确实比大多数对比方法更能避免陷入"原地打转"的死循环状态，这大概率就是因为它能持续给AI提供清晰、有出处、按需组织好的上下文，AI不容易因为忘了自己刚做过什么而重复劳动。
但论文特别提醒了一点，这一点我觉得特别值得强调：**避免原地打转，不等于最终能做出正确的解决方案**。
论文举了个例子，在同样的失败任务组里，无论是ACG还是ReAct，只要遇到了操作被拒绝的情况，几乎百分之百都会在下一次尝试继续往下执行，不会就此放弃。但即便如此，这些任务最后还是失败了。这说明"能不能继续走下去"和"能不能走到正确终点"是两码事，一个AI系统可能很擅长避免卡壳，但依然可能在错误的方向上一路走到黑。
这个发现让我想起考试时的一种现象：有些学生做题速度很快，从不在某道题上卡壳太久，但快不代表做对了，只是没有在原地纠结而已。执行流畅性和结果正确性，中间隔着很大一段距离，不能简单画等号。
写在后面
读完这篇论文，最触动我的其实不是那些百分比的提升，而是作者们对自己方法边界的坦诚程度。他们没有说"ACG解决了AI智能体的记忆问题"，而是反复强调"这套图结构组织的是证据，不认证真假，不宣告任务完成"。在一个大家都倾向于把自己的方法说得天花乱坠的领域里，这种克制挺难得的。
另一个让我意外的细节是关于"步数和成功率负相关"这个现象。直觉上我们总觉得AI做得越久、越努力，应该离成功越近，但数据反复证明恰恰相反，冗长的执行往往是失败的前兆而不是成功的铺垫。这其实和人类工作中的一个经验很像：一个任务如果越拖越长还没搞定，往往意味着方法本身出了问题，需要停下来重新想想，而不是硬着头皮继续埋头苦干。AI智能体在这一点上，某种程度上"继承"了人类的这个通病。
还有一点值得琢磨：ACG坚持"不确定的归属关系就不建立连接，绝不靠语义相似度硬凑"，这种设计哲学其实是在计算效率和准确性之间选择了后者。它宁愿承担"可能漏掉一些本该关联上的证据"的风险，也不愿意冒险引入错误的关联。这种取舍思路，或许在很多需要严谨溯源的系统设计里都值得借鉴，比如医疗记录系统、法律文书系统，这些场景里"宁缺毋滥"的原则可能比"尽量全面"更重要。
这篇论文没有解决的问题也很明显：DeepPlanning这类约束密集型任务，即便用了ACG，成功率也才刚过十个百分点。这说明AI智能体在应对那种需要同时满足一大堆硬性规则的复杂决策场景时，还差得很远。这条路还长着呢，下一个突破点会在哪里，值得继续追问。
Q&A
Q1：自适应一致性图（ACG）是什么？
A：ACG是一种为AI智能体设计的执行记忆系统，它把任务执行过程中产生的证据及其来源持久化保存在一张图结构里，然后在每一步决策前临时抽取一份精简的、按任务要求组织的上下文视图，交给AI使用，而不替换AI原本的规划和执行逻辑。
Q2：ACG和普通的检索增强生成（RAG）技术有什么区别？
A：普通RAG主要面向相对静态的知识库做检索，而ACG面向的是一个不断产生新证据的动态执行过程，它额外保留了每条证据的产生事件、来源出处和任务要求归属关系，并且严格要求归属关系必须明确声明，不能靠语义相似度硬凑。
Q3：用了ACG之后AI智能体的表现提升了多少？
A：在GPT-5.6-luna模型上，平均任务成功率从ReAct方法的44.5%提升到了ACG的50.2%，其中在BrowseComp-Plus检索类任务上从62.4%提升到73.5%，但在DeepPlanning约束规划类任务上提升有限，成功率仍不足13%。
