做过智能体应用的人几乎都会在某个深夜遇到同一种崩溃长期会话进行到后半段用户之前提过的一个关键约束被硬生生挤出上下文窗口于是智能体开始一本正经地胡说八道。我之前对付这个问题的方式很朴素——调大窗口、压缩历史、把早期对话塞进向量库但每一种方案都在某个具体场景里露了怯。后来接触到 pheromone-network它的思路和前面几种都不一样把上下文当作一张会呼吸的信息素网络来管理让每条记忆自己决定该不该被想起。这篇文章我会从核心机制讲起再给出一套可以照着抄的接入方式最后把调参时踩过的坑都摊开说清楚。1. 先复盘上下文爆炸的三种死法为什么常规方案各有短板1.1 三种主流的上下文失效模式做 LLM 应用做了大半年后我对上下文管理这件事的理解已经从把消息塞进去变成了怎么在塞进去之前就保住关键信息。上下文窗口不是不够用而是我们的组织方式错了。最常见的失效模式有三种Token 超限会话一长消息列表直接顶破窗口上限系统被迫截断或报错。这是最表层的问题但也是最容易让人误判的——很多人以为窗口开大一点就解决了实际上只是把爆发点往后推了推。相关性稀释窗口没满但早期对话被大量无关过程性内容压在底部。大模型不是机器它对五轮之前的指令权重天然偏低越长的前缀越容易让关键约束变成背景噪音。关键信息被截断用户在第 5 轮说的我家猫咪叫豆豆对百合花过敏第 20 轮已经被挤到窗口外面。等第 55 轮你问它豆豆能不能喝牛奶它一脸茫然。这种失效是最伤的因为信息当时没被识别为重要事后想捞都捞不回来。你去看线上 AI 助手产品的用户反馈大量它怎么忘了我刚才不是说过了吗基本都能归到第二、第三种模式里。与其说是模型能力不行不如说是上下文管理没有跟上会话的真实结构。1.2 固定窗口、摘要压缩、向量检索各自的边界主流的应对方案我也都试过各有各的适用面但边界都很清楚方案能解决的问题失效场景隐性成本固定窗口截取最近 N 轮控制 token 上限简单直接重要早期信息会被无差别淘汰几乎没有摘要压缩对旧历史分块摘要保留语义主线压缩体量细节大量丢失摘要本身会引入错误归纳每轮摘要要额外调用一次模型摘要模型的延迟和 token 消耗向量数据库检索按语义召回旧内容找回相似的过去向量相似不等于这条现在重要没有时效概念昨天的临时状态今天还会被捞回来嵌入计算、存储、召回链路复杂度固定窗口的问题是它不看内容价值只看时间先后摘要压缩的问题是它在用自己的理解替你做取舍而且是一次性的有损压缩向量检索的问题是它把上下文当成静态文档库忽略了对话记忆是有生命周期的。一个让我印象很深的场景用户第 2 轮说我们预算大概是 5 万以内别超第 10 轮又聊了产品方案第 30 轮开始讨论具体采购。用固定窗口第 2 轮的预算约束大概率已经被挤掉了用摘要压缩摘要模型很可能把预算写成5 万左右这种模糊值用向量检索预算约束确实能召回但也会把第 28 轮随便提到的另一个价格拉回来因为它语义更接近钱。你会发现常规方案要么不挑食要么挑错食。1.3 信息素视角让每条记忆自己决定该不该被想起我后来理解了一个更好的切入角度上下文管理本质上不是存储问题而是优先级问题。谁该留在窗口里、谁该降级、谁该被彻底忘记应该由这条记忆本身的使用模式和时间共同决定。这就是 pheromone-network 最打动我的地方。它把对话记忆建模成一张信息素网络每条记忆是网络里的一个节点记忆之间的关联是边每条边上都附着强度值——这个强度就是信息素。节点被读取、被引用得越频繁信息素越强长时间不被碰就自然衰减。所有记忆都在一个统一的机制里互相竞争不需要你手动去判断哪句话更重要。听起来有点抽象但等你看到后面的衰减公式和组装逻辑会发现它其实就是在用一套显式的动态权重解决大模型隐性注意力权重解决不了的长期依赖问题。2. pheromone-network 的信息素模型把记忆当路径而不是文件2.1 从蚂蚁找食物说起为什么路径比文件更贴切信息素这个隐喻来自蚂蚁。蚂蚁觅食时会释放信息素标记走过的路径后来的蚂蚁倾向于走信息素更浓的路走的人越多这条路的浓度越高时间一长没人走信息素挥发这条路就慢慢消失。这个正反馈加时间衰减的机制天然适合描述哪些对话记忆值得被保留。传统上下文管理把每一条消息当文件存起来调用时按文件名或内容相似度去翻。而 pheromone-network 把记忆当路径一条记忆之所以重要不是因为它写得好、存得规范而是因为它在后续对话里被反复走到。比如用户不吃香菜这条约束每一轮餐饮推荐都会命中它、强化它它的信息素强度会一路走高而用户昨天说今天下雨这种一次性状态错过那段时间后就没人再引用自然衰减沉底。这种建模方式有个额外的好处记忆与记忆之间的关联会被显式记录。你说猫咪叫豆豆和豆豆对百合花过敏天然应该靠在一起如果里面还有一张去年拍的宠物照片这张照片的节点也会和它们建立边。后续检索时从猫咪这个入口出发能顺着信息素边的走向把一组相关记忆一次性捞出来而不是在消息列表里用关键词硬翻。2.2 节点、边与三步更新机制沉积、强化、挥发结构上pheromone-network 的核心抽象非常少就三类ContextItem一条上下文记忆。它包含内容文本、工具调用结果、用户特征等、元信息和当前信息素强度。Edge两个 ContextItem 之间的关联关系同样携带信息素强度。PheromoneNetwork整个图结构的载体负责所有更新和查询。对这层结构的所有写操作都可以归纳成三个动作沉积deposit新信息进入上下文时写入一个节点并赋予初始信息素强度。可以是用户状态、任务目标、关键事实也可以是工具返回结果。强化reinforce当一条已有记忆在后续对话中被引用、命中、或触发相关检索时对它的信息素进行增量加强。挥发evaporate每一轮对话结束后全网络所有节点的信息素按一定比例衰减。这是遗忘机制的来源。对应到更新逻辑可以简化成一句递推式S(t1) S(t) × (1 - η) Δ其中 S(t) 是当前信息素强度η 是挥发率取值 0 到 1Δ 是这一次沉积或强化带来的增量。举一组直观的数字假设 η 0.05每轮对话结束后所有节点都衰减 5%而某个节点每轮都会被强化 1。这条节点的强度会稳定在一个高位另有一条只出现过一次的孤立记忆初始强度 1没被强化5 轮之后强度大约变成 1×0.95^5 ≈ 0.7720 轮后只剩 0.36再配合阈值清理它就逐渐退出核心上下文了。是不是很像现实中聊过一嘴和反复确认过的事情在大脑里的留存差异2.3 遗忘不是删除降级、归档与摘要层有个容易被忽视的设计信息素网络的遗忘并不等于物理删除。强度掉到阈值以下后有三种处理路径彻底丢弃适用于临时的过程性内容比如这轮回答里提到的草稿编号后面几乎不可能复用直接删最省空间。压缩降级把一组低强度但还有潜在价值的节点折叠成一个摘要节点。这相当于把散落的对话记录压缩成某人某时提过某件事强度重新给予一个中低档初始值如果后续又被引用再强化。长期归档对于可能需要但眼前用不到的细节比如用户三个月前提过的家庭地址可以转存到外部存储只在信息素网络中保留一个轻量索引节点。这种三档遗忘比单纯删掉实用得多。我实际用下来的感觉是它把忽略和彻底忘记区分开了。大模型提示词的 context 里可以没有某条细节但信息素网络里还留着它的影子哪天用户重新提起来系统可以从影子节点出发把原始内容找回来。实际落地时我通常会把网络结构分成三层核心上下文区信息素高于高阈值的节点、短期工作区中等强度节点、摘要归档区低强度节点。每一层的存储介质可以不一样核心区放内存供快速调用摘要区放本地库甚至远端向量库。这个分层方案不是 pheromone-network 强制要求的但配合它的信息素强度做分层收益最明显。3. 环境准备与最小 Demo让第一条记忆活起来3.1 安装与运行环境pheromone-network 目前以 Python 生态接入最顺手建议在虚拟环境里装。官方推荐 Python 3.10 以上安装命令很简单pip install pheromone-network如果你是和我一样用 Poetry 或 uv 管理依赖按项目习惯加进去就行。安装完可以用以下方式确认版本是否正常python -c import pheromone_network; print(pheromone_network.__version__)需要注意不同小版本的 API 命名可能有细微差异下面代码我按当前稳定版整理具体以你装到的版本文档为准。3.2 最小上下文管理示例光看概念容易飘直接跑才是最直观的。下面这段代码做了三件事写入两条记忆、建立关联边、更新一次信息素强度。from pheromone_network import PheromoneNetwork, ContextItem # 初始化网络 net PheromoneNetwork() # 写入第一条上下文用户约束 item_budget ContextItem( content采购预算不超过 5 万这是硬约束, meta{type: constraint, source: user}, ) net.deposit(item_budget, initial_strength8.0) # 写入第二条上下文某次对话里提到的候选产品 item_product ContextItem( content用户提到过某品牌的一体机价位在 4 万左右, meta{type: fact, source: chat}, ) net.deposit(item_product, initial_strength3.0) # 建立关联产品候选挂在预算约束下 net.connect(item_budget.id, item_product.id, initial_strength2.0) # 模拟一轮对话结束后做挥发 net.evaporate(rate0.05)这段代码就是一个最简单的完整生命周期。注意我给了不同的初始强度约束类内容初始强度给到 8纯事实类信息只给 3。从第一步开始就用强度差把重要级拉开比所有节点一律平等高效得多。3.3 检查信息素分布验证网络真的在记住写入后怎么确认它记住了我一般直接打印网络状态# 查看当前全网络节点 for item in net.all_items(): print(item.id, item.strength, item.content)输出大致会是a1b2c3... 7.6 采购预算不超过 5 万这是硬约束 d4e5f6... 2.85 用户提到过某品牌的一体机价位在 4 万左右预算约束从 8.0 衰减到 7.6候选产品从 3.0 衰减到 2.85关联度边强度类似地按比例挥发。这时候如果你把候选产品对应的节点强化一次它的强度会重新抬头。动态平衡就这么跑起来了。我还习惯把网络拓扑结构定期导出成 GraphML 或 JSON用来做离线分析看看哪些节点频繁出现在高信息素区、哪些关联边长时间没人走。这一步对调参太重要了能直接看出系统认为哪些信息重要和用户实际关心哪些信息是不是同一批。4. 核心操作实操强度设定、半衰期换算与上下文组装4.1 初始强度怎么定先给上下文分个阶级初始强度是整个系统的地基。如果所有内容初始强度都设成 5信息素机制就退化成单纯的 LRU那还不如直接用固定窗口。我自己长期调出来的初始强度参考值如下内容类型举例初始强度说明硬约束不要调用外部支付接口、预算上限 5 万8~10不随对话轮次削弱接受慢衰减用户偏好不吃香菜、喜欢简洁回复6~7每次相关对话引用都会强化事实快照用户养了一只叫豆豆的猫4~5需要长期留存但不需要每轮强调临时状态当前正在查看订单详情页2~3短生命周期快速挥发过程推理模型中间分析、临时草稿1默认低权重不参与核心组装这个阶级不是拍脑袋拍出来的而是根据一条记忆跨轮次被重复引用的概率倒推的。硬约束基本每一轮都要被模型看见它必须信息素最高过程推理只在当轮有意义给 1 就够配合阈值清理迅速淡出。值得注意的是用户偏好类。它不像硬约束那样每轮必须出现但一旦出现对应的场景比如推荐餐厅它就是决定性信息。所以它的初始强度我设在中高位同时在每次命中时给一个不小的强化增量。实际跑出来的效果是偏好信息不会占满窗口但一旦相关它的排名会瞬间上浮到组装列表前列。4.2 挥发率怎么算用半衰期而不是拍脑袋挥发率 η 直接控制一条没人引用的记忆多久以后基本被遗忘。凭感觉调容易出问题——设得太大用户刚说的事转头就忘设得太小旧记忆永远赖着不走token 降不下来。最有效的调法是用半衰期反推。半衰期的意思是一条记忆在不被强化的情况下强度降到初始一半所需的时间。连续衰减模型下半衰期 T_half 和衰减系数 λ 的关系是λ ln2 / T_half如果是按对话轮次衰减而不是按真实时间衰减可以把半衰期换成半衰轮次。举个例子你想让一条临时状态在 15 轮之后强度减半那每轮的衰减保留率 r 满足 r^15 0.5解出来 r≈0.955对应 η≈0.045。我用 Python 做过一个简单的调参辅助函数import math def half_life_to_rate(half_life_rounds): # 返回每轮衰减率 eta return 1 - 0.5 ** (1 / half_life_rounds) # 例子临时状态希望 15 轮后减半 print(half_life_to_rate(15)) # 约 0.045 # 例子硬约束希望 200 轮后减半 print(half_life_to_rate(200)) # 约 0.0035我的实际配置是硬约束 η≈0.005用户偏好 η≈0.02临时状态 η≈0.05过程推理 η≈0.1。每个类型一套挥发率而不是全网络共用一个值。这个分层挥发是让信息素网络真正实用的关键——单一挥发率永远没法同时兼顾重要约束不能忘和临时状态快速清空两个诉求。4.3 读取组装按信息素强度把 token 预算花在刀刃上信息素网络管理上下文的最终输出要组装成一段给大模型的消息。组装逻辑其实就三步召回候选从当前对话中提取查询向量或关键词在信息素网络里做一轮子图检索拿到若干候选节点。强度排序按节点信息素强度从高到低排序。这是和向量召回最本质的区别——向量召回只看语义近不近信息素排序额外看这条记忆在历史中被依赖的程度。预算分配把可用 token 预算按排序依次分配信息素高的先占位置。示意代码如下def assemble_context(net, query, max_tokens2000, reserved_tokens600): # 1. 召回候选 candidates net.search(query, top_k50) # 2. 强度排序 ranked sorted(candidates, keylambda x: x.strength, reverseTrue) # 3. 预算分配这里简化成先拼后截断 assembled [] used 0 for item in ranked: cost estimate_tokens(item.content) if used cost max_tokens - reserved_tokens: break assembled.append(item.content) used cost # reserved_tokens 留给最近的用户输入和系统指令 return \n.join(assembled)为什么需要 reserved_tokens因为信息素网络负责的是长期记忆而最近一轮的用户输入永远应该完整保留。如果你把所有 token 都花在历史记忆上当前这轮的任务指令反而被挤掉了这是本末倒置。我习惯预留 20%~30% 的窗口给当前对话内容。一个容易踩的细节排序之前必须剔除与当前任务冲突的节点。比如预算约束说 5 万候选列表里恰好有一条几个月前的预算可以到 8 万的旧讨论信息素强度还不低如果你不做冲突检查直接拼进去模型就会左右为难。信息素只能帮你解决重要度问题不能替你解决一致性问题。4.4 读取即强化别让使用和强度分家最后提一个机制层面的坑读取操作必须顺带触发强化。信息素理论和实际人脑记忆一样被调用得越多记忆越牢。如果你只读不强化那么一条被高频使用的记忆和一条被低频使用的记忆在强度上会逐渐同化系统就失去了自适应能力。所以在你封装检索函数时标准做法是def load_context(net, item_id, query): item net.load(item_id) # 读取本身是一次引用顺手强化节点和关联边 net.reinforce(item_id, delta0.5) for edge_id in net.edges_of(item_id): net.reinforce_edge(edge_id, delta0.2) return item.content强化增量不用给太大让系统平滑调整。我一般节点增量 0.3~0.5边增量 0.1~0.2。核心原则是一次命中带来的提升要小于这条记忆从完全不被引用状态恢复到可被召回状态所需的总强化次数不然某一轮的偶然命中会让一条垃圾记忆的排名瞬间飙升。5. 实战案例做一个 60 轮不崩的多轮助手5.1 场景需求拆解为了说明这套机制的实际效果我拿一个真实做过的场景举例一个本地生活助理用户和它连续聊了 60 轮内容包括点餐、出行、宠物照顾、工作会议等穿插话题。在第 2 轮用户说我家猫叫豆豆千万别给它喂巧克力第 8 轮用户说下午 3 点有个电话会议第 23 轮用户说我不吃香菜所有推荐都避开。之后聊天还继续了三十多轮期间夹杂了大量无关内容某家外卖的优惠券失效、周末去哪玩、某首歌单曲循环了一天等等。到了第 60 轮用户问下午安排是什么顺便帮我推荐个晚饭。这个场景的杀手之处在于第 8 轮的会议信息早就滑出了固定窗口第 2 轮的猫咪约束更是几十轮以前的事但它们在语义上都和最后一轮的决策强相关——推荐晚饭要考虑香菜偏好安排下午要考虑会议时间。我对比了三种方案在同一场景的表现方案能否记住会议 3 点能否记住不吃香菜能否记住猫叫豆豆额外 token 开销固定窗口最近 10 轮否否否无每 5 轮一次摘要压缩可能但摘要易模糊可能可能每次约 300~500 tokenpheromone-network是是是检索排序开销约 50~100 token这个对比是真实跑出来的倾向性结论三者都经过多轮测试。固定窗口最省钱但最容易失忆摘要压缩能留存一部分信息但会引入歧义——实测中摘要把3 点电话会议总结成了下午有安排导致模型在第 60 轮根本不知道具体时间而信息素网络因为从始至终没有对原始内容做有损压缩只做强度排序所以时间、人名、食物禁忌这些精确细节都能原样保存下来。5.2 接入代码的骨干逻辑这个助手接入 pheromone-network 后核心逻辑分两段每一轮对话结束后写入/更新节点def after_turn(net, user_text, assistant_text, parsed): # parsed 里是意图识别和关键信息抽取结果 for fact in parsed[facts]: item net.find_by_content(fact[text]) if item: net.reinforce(item.id, deltafact[importance]) else: net.deposit( ContextItem( contentfact[text], meta{type: fact[type]}, ), initial_strengthfact[importance], ) # 挥发一步 net.evaporate(rate0.02)每一轮对话开始前调用信息素检索并组装上下文def before_turn(net, user_query): # 先用扩展后的查询跑一次信息素检索 related net.search(user_query, top_k30) ranked sorted(related, keylambda x: x.strength, reverseTrue) # 把信息素强度高的硬约束和用户偏好固定放最前面 hard_context [ c.content for c in ranked if c.meta.get(type) in (constraint, preference) ] return assemble_context(net, user_query, hard_contexthard_context)这一段代码没什么高深技巧真正让系统不崩的是第 2 轮和第 23 轮写入的那些节点经过了三十多轮衰减依然保持在较高强度。因为它们各自被后续对话命中过猫咪约束在第 31 轮用户提到豆豆掉毛时被强化过一次香菜偏好在第 29 轮用户说上次那家店放了好多香菜烦死了时又被命中过一次。这就是信息素正反馈周期的实际运作——经常被提的事情系统会越来越记得住。5.3 观察到的意外行为与解释有意思的是第 8 轮的会议信息。它在第 10、12 轮都被用户主动提及3 点之前把材料发我所以信息素很强之后 20 轮没人再提它强度开始缓降但因为它初始强度高、半衰期长第 60 轮组装时依然排在候选列表的前列。这说明信息素机制对曾经重要、之后沉默的信息有很强的保留能力——这正是固定窗口做不到的。另一条低强度节点则被正确遗忘了第 5 轮用户提到今天外卖红包要过期之后没人再提到第 25 轮左右就低于阈值被清理了。它本来就是一次性状态留着只会浪费 token丢掉完全不影响对话质量。那种传统的把最近 N 轮全部塞进去的做法本质上是在用窗口位置当权重——近的必然重要远的必然不重要。信息素网络则把这个假设打碎了让权重从使用模式中自己长出来。6. 调试记录蒸发率、冷启动与并发一致性的坑6.1 蒸发率过高还是过低用现象反推这个系统跑起来之后第一个让我头疼的就是蒸发率。一开始图省事全网络统一设 η0.05结果第 17 轮用户刚提的今晚别订那家已经关了这种临时信息第 19 轮就被我自己的系统忽略了用户当场发火。后来把临时状态类的 η 调成 0.03又发现太多三个月前的旧闲聊占着高信息素排名检索结果老是被陈年往事干扰。最终固定成按类型分层配置硬约束和用户偏好慢衰减临时状态快衰减过程推理超快衰减。每个类型独立调才能在同一套机制里同时实现该记住的死活不忘和该忘的麻溜忘掉。判断标准很简单如果用户在上一轮说的状态本轮就失效了说明对应类型的 η 太大如果一个月前的旧事实还长期霸占核心上下文、导致 token 降不下来说明 η 太小。用现象反推参数比自己闷头调快得多。6.2 冷启动保护期新节点最容易出师未捷身先死更隐蔽的坑是冷启动问题。一条新写入的节点初始强度就算给到 5它也需要整整一轮对话后才能接受强化。如果挥发率是每轮 5%它还没等到第一次被引用就已经掉到 4.75。在快速衰减类型里初始强度给低了可能都没机会熬到被命中。我的解法是给所有新节点加一个免衰减倒计时。# 示意新节点在前 3 轮不参与 evaporate class ProtectedItem(ContextItem): def __init__(self, *args, protect_rounds3, **kwargs): super().__init__(*args, **kwargs) self.remaining_protection protect_rounds def tick(self): if self.remaining_protection 0: self.remaining_protection - 1 return # 本轮不衰减 super().tick()保护期不能太长3~5 轮足够了。保护期太长垃圾信息也会赖着不走。这个机制看似简单但有没有它新信息的存活率差很远。6.3 并发写冲突信息素回退的诡异 Bug还有一个让我排查了两天的 Bug多智能体并行运行时某个节点的信息素强度会神秘回退。查下来发现是并发更新没有做原子操作。两个智能体同时读取到 S8.0各自做增强后写成 S8.5 和 S8.3后写的那个把先写的覆盖了等于一次强化被吞掉。解法不复杂要么在更新时读改写整个动作加锁要么用 Redis 的 INCRBYFLOAT 这类原子自增操作。pheromone-network 的单机版本默认线程安全程度取决于你用的存储后端如果底层是普通字典并发写就可能丢更新。我自己在背靠 Redis 的部署方案里把强化操作改成了原子自增再没出过回退问题。6.4 与 LangChain / CrewAI 等框架集成时的定位问题最后说一个集成层面的心得信息素网络不应该试图取代你正在用的 agent 框架而是作为框架里的一个记忆服务存在。很多人第一反应是我能不能整个把 messages 历史换成 pheromone-network 的输出。我的建议是分而治之模型输入里最近几轮 raw messages 照常提供信息素网络只负责补充从长期记忆里捞出来的关键上下文。它应该接管的是那些离当前很远但很重要的内容而不是把对话系统的短时工作记忆也重构一遍。和工具调用结合时要注意把工具返回结果也当成上下文节点写进网络而不是只写用户消息。比如查了一下天气明天有雨这个工具结果在后续讨论是否带伞时会成为关键信息。工具结果的节点如果被后续引用同样要触发强化这样工具产生的知识也能跨轮次留存在上下文里。7. 多智能体协作场景用共享信息素网络传递谁更懂这块7.1 隔离与共享的结构设计如果你在做多智能体系统信息素网络还能再往前走一步让多个智能体共享同一个信息素网络但各自维护不同的视图。具体做法是给每个节点和边打上归属标签每个智能体默认只能看到自己工作区里的节点同时可以读取共享区节点的信息素强度。这个机制解决了一个很实际的问题团队里不同智能体比如采购助理、财务助理、日程助理各自负责一块但都要知道用户预算 5 万这种公共约束。如果各存各的就会各记各的版本如果全量共享又会让每个智能体都背上无关上下文。我的做法是公共约束写入共享区各智能体本地节点通过关联边指向共享约束。财务助理在审批时通过边的信息素强弱能判断这条预算约束最近有没有被采购助理反复确认过——如果信息素很强说明它是活跃约束必须严格遵守如果已经在衰减说明项目可能进入尾声可以放松阈值。信息素在这里直接变成了协作信号。7.2 协作信号的一个实例举一个简化例子采购助理发现某供应商报价变了更新了一个报价变化节点并对共享区的供应商价格基准节点做了一次强化。财务助理运行时检索到该节点发现它的信息素强度在最近几轮明显抬头于是做出判断价格基准最近被更新过预算需要重新核对。它不需要去翻采购助理的完整聊天记录光是看信息素的变化趋势就已经获得了足够多的判断依据。这种用强度变化趋势做协作信号的做法是我认为 pheromone-network 在多智能体场景里最有价值的地方。单独一个智能体的上下文管理还只是自我记忆到了多智能体阶段它就变成了群体记忆的公共黑板。7.3 哪些场景不建议用信息素网络当然它也不是万能的。我已经把它的适用边界摸得比较清楚了极短会话少于 10 轮线性消息列表就是最优解引入信息素网络纯属增加复杂度。每一轮都强相关的密聊场景比如代码审查对话几乎所有信息都有用该保留的都应该保留信息素网络的分级反而可能误伤。没有长期记忆需求的一次性问答完全没必要。信息素网络最适合的是会话长、话题杂、事实密集、真正需要遗忘的场景。判断标准可以揣在兜里你现在的 agent 是不是经常因为忘了早期信息被用户骂如果是那它大概率值得你花一个晚上接入试试。最后再补一句我做这个方案的个人体会不要一上来就想搞完整的历史全量归档。先把信息素网络用在强约束和用户偏好这两类节点上跑通写入→衰减→强化→检索这个闭环你就能直观感受到它和固定窗口的差异。之后再把工具结果、过程推理逐步加进去每一步都比硬着头皮一步到位稳得多。上下文管理没有银弹pheromone-network 提供的是一套让系统自己判断该记什么的机制而怎么用好这套机制最终还是取决于你对对话场景的理解深度。 
长河君 · 2026/10/25 21:07:30 · 阅读 1.2k 基于信息素网络的LLM上下文管理：每条记忆自主决定去留
做过智能体应用的人几乎都会在某个深夜遇到同一种崩溃长期会话进行到后半段用户之前提过的一个关键约束被硬生生挤出上下文窗口于是智能体开始一本正经地胡说八道。我之前对付这个问题的方式很朴素——调大窗口、压缩历史、把早期对话塞进向量库但每一种方案都在某个具体场景里露了怯。后来接触到 pheromone-network它的思路和前面几种都不一样把上下文当作一张会呼吸的信息素网络来管理让每条记忆自己决定该不该被想起。这篇文章我会从核心机制讲起再给出一套可以照着抄的接入方式最后把调参时踩过的坑都摊开说清楚。1. 先复盘上下文爆炸的三种死法为什么常规方案各有短板1.1 三种主流的上下文失效模式做 LLM 应用做了大半年后我对上下文管理这件事的理解已经从把消息塞进去变成了怎么在塞进去之前就保住关键信息。上下文窗口不是不够用而是我们的组织方式错了。最常见的失效模式有三种Token 超限会话一长消息列表直接顶破窗口上限系统被迫截断或报错。这是最表层的问题但也是最容易让人误判的——很多人以为窗口开大一点就解决了实际上只是把爆发点往后推了推。相关性稀释窗口没满但早期对话被大量无关过程性内容压在底部。大模型不是机器它对五轮之前的指令权重天然偏低越长的前缀越容易让关键约束变成背景噪音。关键信息被截断用户在第 5 轮说的我家猫咪叫豆豆对百合花过敏第 20 轮已经被挤到窗口外面。等第 55 轮你问它豆豆能不能喝牛奶它一脸茫然。这种失效是最伤的因为信息当时没被识别为重要事后想捞都捞不回来。你去看线上 AI 助手产品的用户反馈大量它怎么忘了我刚才不是说过了吗基本都能归到第二、第三种模式里。与其说是模型能力不行不如说是上下文管理没有跟上会话的真实结构。1.2 固定窗口、摘要压缩、向量检索各自的边界主流的应对方案我也都试过各有各的适用面但边界都很清楚方案能解决的问题失效场景隐性成本固定窗口截取最近 N 轮控制 token 上限简单直接重要早期信息会被无差别淘汰几乎没有摘要压缩对旧历史分块摘要保留语义主线压缩体量细节大量丢失摘要本身会引入错误归纳每轮摘要要额外调用一次模型摘要模型的延迟和 token 消耗向量数据库检索按语义召回旧内容找回相似的过去向量相似不等于这条现在重要没有时效概念昨天的临时状态今天还会被捞回来嵌入计算、存储、召回链路复杂度固定窗口的问题是它不看内容价值只看时间先后摘要压缩的问题是它在用自己的理解替你做取舍而且是一次性的有损压缩向量检索的问题是它把上下文当成静态文档库忽略了对话记忆是有生命周期的。一个让我印象很深的场景用户第 2 轮说我们预算大概是 5 万以内别超第 10 轮又聊了产品方案第 30 轮开始讨论具体采购。用固定窗口第 2 轮的预算约束大概率已经被挤掉了用摘要压缩摘要模型很可能把预算写成5 万左右这种模糊值用向量检索预算约束确实能召回但也会把第 28 轮随便提到的另一个价格拉回来因为它语义更接近钱。你会发现常规方案要么不挑食要么挑错食。1.3 信息素视角让每条记忆自己决定该不该被想起我后来理解了一个更好的切入角度上下文管理本质上不是存储问题而是优先级问题。谁该留在窗口里、谁该降级、谁该被彻底忘记应该由这条记忆本身的使用模式和时间共同决定。这就是 pheromone-network 最打动我的地方。它把对话记忆建模成一张信息素网络每条记忆是网络里的一个节点记忆之间的关联是边每条边上都附着强度值——这个强度就是信息素。节点被读取、被引用得越频繁信息素越强长时间不被碰就自然衰减。所有记忆都在一个统一的机制里互相竞争不需要你手动去判断哪句话更重要。听起来有点抽象但等你看到后面的衰减公式和组装逻辑会发现它其实就是在用一套显式的动态权重解决大模型隐性注意力权重解决不了的长期依赖问题。2. pheromone-network 的信息素模型把记忆当路径而不是文件2.1 从蚂蚁找食物说起为什么路径比文件更贴切信息素这个隐喻来自蚂蚁。蚂蚁觅食时会释放信息素标记走过的路径后来的蚂蚁倾向于走信息素更浓的路走的人越多这条路的浓度越高时间一长没人走信息素挥发这条路就慢慢消失。这个正反馈加时间衰减的机制天然适合描述哪些对话记忆值得被保留。传统上下文管理把每一条消息当文件存起来调用时按文件名或内容相似度去翻。而 pheromone-network 把记忆当路径一条记忆之所以重要不是因为它写得好、存得规范而是因为它在后续对话里被反复走到。比如用户不吃香菜这条约束每一轮餐饮推荐都会命中它、强化它它的信息素强度会一路走高而用户昨天说今天下雨这种一次性状态错过那段时间后就没人再引用自然衰减沉底。这种建模方式有个额外的好处记忆与记忆之间的关联会被显式记录。你说猫咪叫豆豆和豆豆对百合花过敏天然应该靠在一起如果里面还有一张去年拍的宠物照片这张照片的节点也会和它们建立边。后续检索时从猫咪这个入口出发能顺着信息素边的走向把一组相关记忆一次性捞出来而不是在消息列表里用关键词硬翻。2.2 节点、边与三步更新机制沉积、强化、挥发结构上pheromone-network 的核心抽象非常少就三类ContextItem一条上下文记忆。它包含内容文本、工具调用结果、用户特征等、元信息和当前信息素强度。Edge两个 ContextItem 之间的关联关系同样携带信息素强度。PheromoneNetwork整个图结构的载体负责所有更新和查询。对这层结构的所有写操作都可以归纳成三个动作沉积deposit新信息进入上下文时写入一个节点并赋予初始信息素强度。可以是用户状态、任务目标、关键事实也可以是工具返回结果。强化reinforce当一条已有记忆在后续对话中被引用、命中、或触发相关检索时对它的信息素进行增量加强。挥发evaporate每一轮对话结束后全网络所有节点的信息素按一定比例衰减。这是遗忘机制的来源。对应到更新逻辑可以简化成一句递推式S(t1) S(t) × (1 - η) Δ其中 S(t) 是当前信息素强度η 是挥发率取值 0 到 1Δ 是这一次沉积或强化带来的增量。举一组直观的数字假设 η 0.05每轮对话结束后所有节点都衰减 5%而某个节点每轮都会被强化 1。这条节点的强度会稳定在一个高位另有一条只出现过一次的孤立记忆初始强度 1没被强化5 轮之后强度大约变成 1×0.95^5 ≈ 0.7720 轮后只剩 0.36再配合阈值清理它就逐渐退出核心上下文了。是不是很像现实中聊过一嘴和反复确认过的事情在大脑里的留存差异2.3 遗忘不是删除降级、归档与摘要层有个容易被忽视的设计信息素网络的遗忘并不等于物理删除。强度掉到阈值以下后有三种处理路径彻底丢弃适用于临时的过程性内容比如这轮回答里提到的草稿编号后面几乎不可能复用直接删最省空间。压缩降级把一组低强度但还有潜在价值的节点折叠成一个摘要节点。这相当于把散落的对话记录压缩成某人某时提过某件事强度重新给予一个中低档初始值如果后续又被引用再强化。长期归档对于可能需要但眼前用不到的细节比如用户三个月前提过的家庭地址可以转存到外部存储只在信息素网络中保留一个轻量索引节点。这种三档遗忘比单纯删掉实用得多。我实际用下来的感觉是它把忽略和彻底忘记区分开了。大模型提示词的 context 里可以没有某条细节但信息素网络里还留着它的影子哪天用户重新提起来系统可以从影子节点出发把原始内容找回来。实际落地时我通常会把网络结构分成三层核心上下文区信息素高于高阈值的节点、短期工作区中等强度节点、摘要归档区低强度节点。每一层的存储介质可以不一样核心区放内存供快速调用摘要区放本地库甚至远端向量库。这个分层方案不是 pheromone-network 强制要求的但配合它的信息素强度做分层收益最明显。3. 环境准备与最小 Demo让第一条记忆活起来3.1 安装与运行环境pheromone-network 目前以 Python 生态接入最顺手建议在虚拟环境里装。官方推荐 Python 3.10 以上安装命令很简单pip install pheromone-network如果你是和我一样用 Poetry 或 uv 管理依赖按项目习惯加进去就行。安装完可以用以下方式确认版本是否正常python -c import pheromone_network; print(pheromone_network.__version__)需要注意不同小版本的 API 命名可能有细微差异下面代码我按当前稳定版整理具体以你装到的版本文档为准。3.2 最小上下文管理示例光看概念容易飘直接跑才是最直观的。下面这段代码做了三件事写入两条记忆、建立关联边、更新一次信息素强度。from pheromone_network import PheromoneNetwork, ContextItem # 初始化网络 net PheromoneNetwork() # 写入第一条上下文用户约束 item_budget ContextItem( content采购预算不超过 5 万这是硬约束, meta{type: constraint, source: user}, ) net.deposit(item_budget, initial_strength8.0) # 写入第二条上下文某次对话里提到的候选产品 item_product ContextItem( content用户提到过某品牌的一体机价位在 4 万左右, meta{type: fact, source: chat}, ) net.deposit(item_product, initial_strength3.0) # 建立关联产品候选挂在预算约束下 net.connect(item_budget.id, item_product.id, initial_strength2.0) # 模拟一轮对话结束后做挥发 net.evaporate(rate0.05)这段代码就是一个最简单的完整生命周期。注意我给了不同的初始强度约束类内容初始强度给到 8纯事实类信息只给 3。从第一步开始就用强度差把重要级拉开比所有节点一律平等高效得多。3.3 检查信息素分布验证网络真的在记住写入后怎么确认它记住了我一般直接打印网络状态# 查看当前全网络节点 for item in net.all_items(): print(item.id, item.strength, item.content)输出大致会是a1b2c3... 7.6 采购预算不超过 5 万这是硬约束 d4e5f6... 2.85 用户提到过某品牌的一体机价位在 4 万左右预算约束从 8.0 衰减到 7.6候选产品从 3.0 衰减到 2.85关联度边强度类似地按比例挥发。这时候如果你把候选产品对应的节点强化一次它的强度会重新抬头。动态平衡就这么跑起来了。我还习惯把网络拓扑结构定期导出成 GraphML 或 JSON用来做离线分析看看哪些节点频繁出现在高信息素区、哪些关联边长时间没人走。这一步对调参太重要了能直接看出系统认为哪些信息重要和用户实际关心哪些信息是不是同一批。4. 核心操作实操强度设定、半衰期换算与上下文组装4.1 初始强度怎么定先给上下文分个阶级初始强度是整个系统的地基。如果所有内容初始强度都设成 5信息素机制就退化成单纯的 LRU那还不如直接用固定窗口。我自己长期调出来的初始强度参考值如下内容类型举例初始强度说明硬约束不要调用外部支付接口、预算上限 5 万8~10不随对话轮次削弱接受慢衰减用户偏好不吃香菜、喜欢简洁回复6~7每次相关对话引用都会强化事实快照用户养了一只叫豆豆的猫4~5需要长期留存但不需要每轮强调临时状态当前正在查看订单详情页2~3短生命周期快速挥发过程推理模型中间分析、临时草稿1默认低权重不参与核心组装这个阶级不是拍脑袋拍出来的而是根据一条记忆跨轮次被重复引用的概率倒推的。硬约束基本每一轮都要被模型看见它必须信息素最高过程推理只在当轮有意义给 1 就够配合阈值清理迅速淡出。值得注意的是用户偏好类。它不像硬约束那样每轮必须出现但一旦出现对应的场景比如推荐餐厅它就是决定性信息。所以它的初始强度我设在中高位同时在每次命中时给一个不小的强化增量。实际跑出来的效果是偏好信息不会占满窗口但一旦相关它的排名会瞬间上浮到组装列表前列。4.2 挥发率怎么算用半衰期而不是拍脑袋挥发率 η 直接控制一条没人引用的记忆多久以后基本被遗忘。凭感觉调容易出问题——设得太大用户刚说的事转头就忘设得太小旧记忆永远赖着不走token 降不下来。最有效的调法是用半衰期反推。半衰期的意思是一条记忆在不被强化的情况下强度降到初始一半所需的时间。连续衰减模型下半衰期 T_half 和衰减系数 λ 的关系是λ ln2 / T_half如果是按对话轮次衰减而不是按真实时间衰减可以把半衰期换成半衰轮次。举个例子你想让一条临时状态在 15 轮之后强度减半那每轮的衰减保留率 r 满足 r^15 0.5解出来 r≈0.955对应 η≈0.045。我用 Python 做过一个简单的调参辅助函数import math def half_life_to_rate(half_life_rounds): # 返回每轮衰减率 eta return 1 - 0.5 ** (1 / half_life_rounds) # 例子临时状态希望 15 轮后减半 print(half_life_to_rate(15)) # 约 0.045 # 例子硬约束希望 200 轮后减半 print(half_life_to_rate(200)) # 约 0.0035我的实际配置是硬约束 η≈0.005用户偏好 η≈0.02临时状态 η≈0.05过程推理 η≈0.1。每个类型一套挥发率而不是全网络共用一个值。这个分层挥发是让信息素网络真正实用的关键——单一挥发率永远没法同时兼顾重要约束不能忘和临时状态快速清空两个诉求。4.3 读取组装按信息素强度把 token 预算花在刀刃上信息素网络管理上下文的最终输出要组装成一段给大模型的消息。组装逻辑其实就三步召回候选从当前对话中提取查询向量或关键词在信息素网络里做一轮子图检索拿到若干候选节点。强度排序按节点信息素强度从高到低排序。这是和向量召回最本质的区别——向量召回只看语义近不近信息素排序额外看这条记忆在历史中被依赖的程度。预算分配把可用 token 预算按排序依次分配信息素高的先占位置。示意代码如下def assemble_context(net, query, max_tokens2000, reserved_tokens600): # 1. 召回候选 candidates net.search(query, top_k50) # 2. 强度排序 ranked sorted(candidates, keylambda x: x.strength, reverseTrue) # 3. 预算分配这里简化成先拼后截断 assembled [] used 0 for item in ranked: cost estimate_tokens(item.content) if used cost max_tokens - reserved_tokens: break assembled.append(item.content) used cost # reserved_tokens 留给最近的用户输入和系统指令 return \n.join(assembled)为什么需要 reserved_tokens因为信息素网络负责的是长期记忆而最近一轮的用户输入永远应该完整保留。如果你把所有 token 都花在历史记忆上当前这轮的任务指令反而被挤掉了这是本末倒置。我习惯预留 20%~30% 的窗口给当前对话内容。一个容易踩的细节排序之前必须剔除与当前任务冲突的节点。比如预算约束说 5 万候选列表里恰好有一条几个月前的预算可以到 8 万的旧讨论信息素强度还不低如果你不做冲突检查直接拼进去模型就会左右为难。信息素只能帮你解决重要度问题不能替你解决一致性问题。4.4 读取即强化别让使用和强度分家最后提一个机制层面的坑读取操作必须顺带触发强化。信息素理论和实际人脑记忆一样被调用得越多记忆越牢。如果你只读不强化那么一条被高频使用的记忆和一条被低频使用的记忆在强度上会逐渐同化系统就失去了自适应能力。所以在你封装检索函数时标准做法是def load_context(net, item_id, query): item net.load(item_id) # 读取本身是一次引用顺手强化节点和关联边 net.reinforce(item_id, delta0.5) for edge_id in net.edges_of(item_id): net.reinforce_edge(edge_id, delta0.2) return item.content强化增量不用给太大让系统平滑调整。我一般节点增量 0.3~0.5边增量 0.1~0.2。核心原则是一次命中带来的提升要小于这条记忆从完全不被引用状态恢复到可被召回状态所需的总强化次数不然某一轮的偶然命中会让一条垃圾记忆的排名瞬间飙升。5. 实战案例做一个 60 轮不崩的多轮助手5.1 场景需求拆解为了说明这套机制的实际效果我拿一个真实做过的场景举例一个本地生活助理用户和它连续聊了 60 轮内容包括点餐、出行、宠物照顾、工作会议等穿插话题。在第 2 轮用户说我家猫叫豆豆千万别给它喂巧克力第 8 轮用户说下午 3 点有个电话会议第 23 轮用户说我不吃香菜所有推荐都避开。之后聊天还继续了三十多轮期间夹杂了大量无关内容某家外卖的优惠券失效、周末去哪玩、某首歌单曲循环了一天等等。到了第 60 轮用户问下午安排是什么顺便帮我推荐个晚饭。这个场景的杀手之处在于第 8 轮的会议信息早就滑出了固定窗口第 2 轮的猫咪约束更是几十轮以前的事但它们在语义上都和最后一轮的决策强相关——推荐晚饭要考虑香菜偏好安排下午要考虑会议时间。我对比了三种方案在同一场景的表现方案能否记住会议 3 点能否记住不吃香菜能否记住猫叫豆豆额外 token 开销固定窗口最近 10 轮否否否无每 5 轮一次摘要压缩可能但摘要易模糊可能可能每次约 300~500 tokenpheromone-network是是是检索排序开销约 50~100 token这个对比是真实跑出来的倾向性结论三者都经过多轮测试。固定窗口最省钱但最容易失忆摘要压缩能留存一部分信息但会引入歧义——实测中摘要把3 点电话会议总结成了下午有安排导致模型在第 60 轮根本不知道具体时间而信息素网络因为从始至终没有对原始内容做有损压缩只做强度排序所以时间、人名、食物禁忌这些精确细节都能原样保存下来。5.2 接入代码的骨干逻辑这个助手接入 pheromone-network 后核心逻辑分两段每一轮对话结束后写入/更新节点def after_turn(net, user_text, assistant_text, parsed): # parsed 里是意图识别和关键信息抽取结果 for fact in parsed[facts]: item net.find_by_content(fact[text]) if item: net.reinforce(item.id, deltafact[importance]) else: net.deposit( ContextItem( contentfact[text], meta{type: fact[type]}, ), initial_strengthfact[importance], ) # 挥发一步 net.evaporate(rate0.02)每一轮对话开始前调用信息素检索并组装上下文def before_turn(net, user_query): # 先用扩展后的查询跑一次信息素检索 related net.search(user_query, top_k30) ranked sorted(related, keylambda x: x.strength, reverseTrue) # 把信息素强度高的硬约束和用户偏好固定放最前面 hard_context [ c.content for c in ranked if c.meta.get(type) in (constraint, preference) ] return assemble_context(net, user_query, hard_contexthard_context)这一段代码没什么高深技巧真正让系统不崩的是第 2 轮和第 23 轮写入的那些节点经过了三十多轮衰减依然保持在较高强度。因为它们各自被后续对话命中过猫咪约束在第 31 轮用户提到豆豆掉毛时被强化过一次香菜偏好在第 29 轮用户说上次那家店放了好多香菜烦死了时又被命中过一次。这就是信息素正反馈周期的实际运作——经常被提的事情系统会越来越记得住。5.3 观察到的意外行为与解释有意思的是第 8 轮的会议信息。它在第 10、12 轮都被用户主动提及3 点之前把材料发我所以信息素很强之后 20 轮没人再提它强度开始缓降但因为它初始强度高、半衰期长第 60 轮组装时依然排在候选列表的前列。这说明信息素机制对曾经重要、之后沉默的信息有很强的保留能力——这正是固定窗口做不到的。另一条低强度节点则被正确遗忘了第 5 轮用户提到今天外卖红包要过期之后没人再提到第 25 轮左右就低于阈值被清理了。它本来就是一次性状态留着只会浪费 token丢掉完全不影响对话质量。那种传统的把最近 N 轮全部塞进去的做法本质上是在用窗口位置当权重——近的必然重要远的必然不重要。信息素网络则把这个假设打碎了让权重从使用模式中自己长出来。6. 调试记录蒸发率、冷启动与并发一致性的坑6.1 蒸发率过高还是过低用现象反推这个系统跑起来之后第一个让我头疼的就是蒸发率。一开始图省事全网络统一设 η0.05结果第 17 轮用户刚提的今晚别订那家已经关了这种临时信息第 19 轮就被我自己的系统忽略了用户当场发火。后来把临时状态类的 η 调成 0.03又发现太多三个月前的旧闲聊占着高信息素排名检索结果老是被陈年往事干扰。最终固定成按类型分层配置硬约束和用户偏好慢衰减临时状态快衰减过程推理超快衰减。每个类型独立调才能在同一套机制里同时实现该记住的死活不忘和该忘的麻溜忘掉。判断标准很简单如果用户在上一轮说的状态本轮就失效了说明对应类型的 η 太大如果一个月前的旧事实还长期霸占核心上下文、导致 token 降不下来说明 η 太小。用现象反推参数比自己闷头调快得多。6.2 冷启动保护期新节点最容易出师未捷身先死更隐蔽的坑是冷启动问题。一条新写入的节点初始强度就算给到 5它也需要整整一轮对话后才能接受强化。如果挥发率是每轮 5%它还没等到第一次被引用就已经掉到 4.75。在快速衰减类型里初始强度给低了可能都没机会熬到被命中。我的解法是给所有新节点加一个免衰减倒计时。# 示意新节点在前 3 轮不参与 evaporate class ProtectedItem(ContextItem): def __init__(self, *args, protect_rounds3, **kwargs): super().__init__(*args, **kwargs) self.remaining_protection protect_rounds def tick(self): if self.remaining_protection 0: self.remaining_protection - 1 return # 本轮不衰减 super().tick()保护期不能太长3~5 轮足够了。保护期太长垃圾信息也会赖着不走。这个机制看似简单但有没有它新信息的存活率差很远。6.3 并发写冲突信息素回退的诡异 Bug还有一个让我排查了两天的 Bug多智能体并行运行时某个节点的信息素强度会神秘回退。查下来发现是并发更新没有做原子操作。两个智能体同时读取到 S8.0各自做增强后写成 S8.5 和 S8.3后写的那个把先写的覆盖了等于一次强化被吞掉。解法不复杂要么在更新时读改写整个动作加锁要么用 Redis 的 INCRBYFLOAT 这类原子自增操作。pheromone-network 的单机版本默认线程安全程度取决于你用的存储后端如果底层是普通字典并发写就可能丢更新。我自己在背靠 Redis 的部署方案里把强化操作改成了原子自增再没出过回退问题。6.4 与 LangChain / CrewAI 等框架集成时的定位问题最后说一个集成层面的心得信息素网络不应该试图取代你正在用的 agent 框架而是作为框架里的一个记忆服务存在。很多人第一反应是我能不能整个把 messages 历史换成 pheromone-network 的输出。我的建议是分而治之模型输入里最近几轮 raw messages 照常提供信息素网络只负责补充从长期记忆里捞出来的关键上下文。它应该接管的是那些离当前很远但很重要的内容而不是把对话系统的短时工作记忆也重构一遍。和工具调用结合时要注意把工具返回结果也当成上下文节点写进网络而不是只写用户消息。比如查了一下天气明天有雨这个工具结果在后续讨论是否带伞时会成为关键信息。工具结果的节点如果被后续引用同样要触发强化这样工具产生的知识也能跨轮次留存在上下文里。7. 多智能体协作场景用共享信息素网络传递谁更懂这块7.1 隔离与共享的结构设计如果你在做多智能体系统信息素网络还能再往前走一步让多个智能体共享同一个信息素网络但各自维护不同的视图。具体做法是给每个节点和边打上归属标签每个智能体默认只能看到自己工作区里的节点同时可以读取共享区节点的信息素强度。这个机制解决了一个很实际的问题团队里不同智能体比如采购助理、财务助理、日程助理各自负责一块但都要知道用户预算 5 万这种公共约束。如果各存各的就会各记各的版本如果全量共享又会让每个智能体都背上无关上下文。我的做法是公共约束写入共享区各智能体本地节点通过关联边指向共享约束。财务助理在审批时通过边的信息素强弱能判断这条预算约束最近有没有被采购助理反复确认过——如果信息素很强说明它是活跃约束必须严格遵守如果已经在衰减说明项目可能进入尾声可以放松阈值。信息素在这里直接变成了协作信号。7.2 协作信号的一个实例举一个简化例子采购助理发现某供应商报价变了更新了一个报价变化节点并对共享区的供应商价格基准节点做了一次强化。财务助理运行时检索到该节点发现它的信息素强度在最近几轮明显抬头于是做出判断价格基准最近被更新过预算需要重新核对。它不需要去翻采购助理的完整聊天记录光是看信息素的变化趋势就已经获得了足够多的判断依据。这种用强度变化趋势做协作信号的做法是我认为 pheromone-network 在多智能体场景里最有价值的地方。单独一个智能体的上下文管理还只是自我记忆到了多智能体阶段它就变成了群体记忆的公共黑板。7.3 哪些场景不建议用信息素网络当然它也不是万能的。我已经把它的适用边界摸得比较清楚了极短会话少于 10 轮线性消息列表就是最优解引入信息素网络纯属增加复杂度。每一轮都强相关的密聊场景比如代码审查对话几乎所有信息都有用该保留的都应该保留信息素网络的分级反而可能误伤。没有长期记忆需求的一次性问答完全没必要。信息素网络最适合的是会话长、话题杂、事实密集、真正需要遗忘的场景。判断标准可以揣在兜里你现在的 agent 是不是经常因为忘了早期信息被用户骂如果是那它大概率值得你花一个晚上接入试试。最后再补一句我做这个方案的个人体会不要一上来就想搞完整的历史全量归档。先把信息素网络用在强约束和用户偏好这两类节点上跑通写入→衰减→强化→检索这个闭环你就能直观感受到它和固定窗口的差异。之后再把工具结果、过程推理逐步加进去每一步都比硬着头皮一步到位稳得多。上下文管理没有银弹pheromone-network 提供的是一套让系统自己判断该记什么的机制而怎么用好这套机制最终还是取决于你对对话场景的理解深度。