在生成任务里，Agent 先检索哪条记忆，决定它后续接到的上下文。如果你的 MemoraX Code 实例总是先返回最旧或明显不相关的记忆，问题不在存储，而在排序策略。有效的处理顺序是：先查看当前每个命中的得分，确认哪些因素在主导排序；再依次调整时间衰减、关键词精确匹配和任务类型权重，最后用一组固定查询验证 top 5 变化。需要说明的是，下面的参数名和配置结构是通用写法，具体到你的版本，可能叫法不同，但调整思路可以沿用。

判断：MemoraX Code 记忆排序通常由向量相似度、时间衰减和关键词匹配共同决定；生成任务中，让近期且含有关键词命中的记忆优先，比纯向量相似度更实用。动作：先打印 score 字段了解当前排序依据，再修改 time_decay_hours、boost_exact_match 和 task_type_rules.extra_bonus。验证：用 20 条固定记忆和一组查询，比较调参前后的 top5 命中数。边界：调参只改变排序，不扩大召回；记忆库没有相关内容时，调整权重无法弥补。

查看当前检索返回的排序结果

不要急着改参数，先看当前排序由什么决定。下面这段 Python 调用搜索接口，并打印每个命中的 score 字段。具体方法名按你本机的 Memorax 客户端替换。

from memorax_client import Client

client = Client(base_url='http://localhost:8080', api_key='your-key')

query = '给登录接口补上限流逻辑，并处理 token 过期'
results = client.search(query, task_type='code_gen')

for idx, item in enumerate(results[:10], 1):
    print(idx, item['memory_id'], item.get('score'), item.get('created_at'), item['text'][:30])

如果打印结果的顺序里，score 最高的是两周前的旧记忆，说明时间权重太低；如果 score 很高但文本里没有查询关键词，说明向量相似度主导过强。这一步的关键是暴露每个命中的得分，而不是只看返回列表的排序。

调整时间衰减因子

如果旧记忆排前，先调整 time_decay_hours。这个参数控制记忆得分的衰减速度，值越小，旧记忆的削减越明显。以 YAML 配置为例：

retrieval:
  time_decay_hours: 48    # 原来是 720，先缩到 48 观察
  decay_curve: exponential

保存配置并重新检索同一个查询，对照打印出的 score 和排序。你会发现最近几天的记忆得分明显上移；如果最相关的记忆超过两周，可以放宽到 96 小时。不同版本可能用 time_penalty 之类的名字，但作用相同。注意：时间衰减只影响排序，不会删掉旧记忆；如果项目里有长期必须记住的约定，可以把衰减设到 120 小时以上。

设置关键词精确匹配优先

如果向量相似度把内容相近但没提到关键词的记忆排在前面，打开精确匹配加成。

retrieval:
  boost_exact_match: true
  exact_match_fields: ['title', 'content']
  exact_match_weight: 1.5

然后写一条完全匹配词条测试。先插入一条记忆：登录接口 token 过期处理，需要返回 401。再用同样的词条作为查询搜索。配置前，这条记忆可能排不到前 5；配置后，它应该进入前 2。

client.add_memory(text='登录接口 token 过期处理，需要返回 401')

results = client.search('登录接口 token 过期处理', task_type='code_gen')
print([item['text'] for item in results[:3]])

注意：boost_exact_match 开启后，同义改写可能不如原先，所以只建议在生成任务里使用；如果是开放问答，权重别超过向量得分。

为不同任务类型配置独立的排序规则

生成任务和问答任务的记忆需求不同，最好让排序参数分开。在配置文件里增加 task_type_rules，并在 code_gen 下设置 extra_bonus，给上下文相关度额外加权。

task_type_rules:
  code_gen:
    extra_bonus: 0.8
    time_decay_hours: 72
    boost_exact_match: true
  general_chat:
    extra_bonus: 0.2
    time_decay_hours: 720

这里的 extra_bonus 会加到每个候选记忆的上下文相关度得分上；你可以在检索日志里看到类似 context_bonus:0.8 的字段。修改配置后，用同一个查询在 code_gen 和 general_chat 下分别跑一次，观察排序差异。如果日志里没有上下文相关度字段，说明该版本不支持这个加权，需要确认接口版本。

用基准任务集验证排序合理性

单条查询验证不够，建议准备一组固定查询集。先整理 20 条测试记忆，覆盖近期、旧、完全匹配、语义相近等场景；然后定义 5 到 10 个查询，分别用调参前后的检索配置跑，比较 top 5 命中率。以下脚本展示了比较框架：

test_memories = [
    '修复登录接口 token 过期问题',
    '为订单模块增加超时取消逻辑',
    # ... 共 20 条
]
for m in test_memories:
    client.add_memory(text=m)

test_queries = ['token 过期 登录', '超时 取消 订单']

def hit_rate(config_name):
    hits = 0
    for q in test_queries:
        results = client.search(q, task_type='code_gen', config=config_name)
        top5 = [r['text'] for r in results[:5]]
        if any(q.split()[0] in t for t in top5):  # 简化判断
            hits += 1
    return hits / len(test_queries)

print('before:', hit_rate('default'))
print('after:', hit_rate('optimized'))

这里对“命中”的判断比较粗，你可以换成人工标注的正确记忆 id。重点是脚本可以重复执行，避免靠感觉确认优化。基准集要保留下来，后续改动排序参数时继续复用。