请问/api/v3/agentic/memorize这个接口，关于边界是怎么判断的？

[stormsea]

请问/api/v3/agentic/memorize这个接口，关于边界是怎么判断的？
当我不断发消息的时候，发现这个记忆存储是，积累到一定程度才开始存到数据库里的，没有积累足够的信息是不存的。log会提示

2025-12-05 14:22:44,826 - biz_layer.mem_memorize - INFO - mem_memorize.py:441 - [mem_memorize] 判断为非边界，继续累积msg，更新状态表

我大概的看了源码，这个边界判定是根据时间和大模型判断，来进行判定的，没有根据消息数量来判断。

这里就有一个问题，假设我短时间，和AI聊同一个主题的话题，可能聊了50条消息了，还没判定边界成功，然而，我messages只存最近20条对话记录，那20~50条对话记录里的信息，AI不就失忆了嘛？

请问这种情况怎么办呢？

---

我刚刚和AI聊了快一百句话了，还是没提取记忆。

[freshpomelo]

EvermemOS当前是根据聊天对话的主题来切分对话并进行记忆的提取，所以会出现情况如果一直就同一个主题进行对话，记忆一直没有提取的现象。
后面会增加更多的判断规则来合理的进行对话切分。

[zhisenyang]

我目前在做着一个 agent，有 tool call的，那么 tool call 的结果有必要继续记忆存储吗？结果的文本挺长的

[freshpomelo]

我目前在做着一个 agent，有 tool call的，那么 tool call 的结果有必要继续记忆存储吗？结果的文本挺长的

我觉得这个应该是从你agent的产品功能角度来考虑是否保留，如果保留，你可以用来做什么，如果删除，你的agent会缺少什么上下文？

[stormsea]

EvermemOS当前是根据聊天对话的主题来切分对话并进行记忆的提取，所以会出现情况如果一直就同一个主题进行对话，记忆一直没有提取的现象。 后面会增加更多的判断规则来合理的进行对话切分。

您好，请问这个更多的判断规则来合理的进行对话切分做好了吗？我之前遇到这个问题，是修改了源码，强制超过20条就判定边界一次的。

[freshpomelo]

您好，请问这个更多的判断规则来合理的进行对话切分做好了吗？我之前遇到这个问题，是修改了源码，强制超过20条就判定边界一次的。

Hi there,
Yes, we have updated the boundary detection rules in the latest commit. We now implement three specific triggers:

1. LLM-based Logic: The model is instructed via the prompt to trigger a cut when it detects a transition to a new day.
2. Token Limit: A cut is automatically triggered when the token count exceeds 8,192.
3. Message Threshold: A cut is triggered once 50 messages have accumulated.

rule 2 and 3 is in src/memory_layer/memcell_extractor/conv_memcell_extractor.py

    # Default limits for force splitting
    DEFAULT_HARD_TOKEN_LIMIT = 8192
    DEFAULT_HARD_MESSAGE_LIMIT = 50

[cyfyifanchen]

Closing this as part of the EverOS 1.0 issue triage. This issue references the pre-1.0 API or retired infrastructure such as /api/v1/memories, /api/v3/agentic/*, MongoDB, Elasticsearch, Milvus, Redis, Kafka, longjob, or old memory type names. EverOS 1.0 uses POST /api/v1/memory/{add,flush,search,get} with Markdown + SQLite + LanceDB. Migration notes are tracked in PR #258: #258. If the same behavior still occurs on current main with the 1.0 API, please open a fresh issue with a 1.0 repro.