Jev 用在 agent 记忆写入前的语义判断

Avi Chawla @_avichawla原推发布于 2026.10.11

在 X 上打开原推

Jev for Agent Memory, clearly explained: An agent-memory system often passes conversations, tool results, and task outcomes through an extractor. The extractor identifies possible memories such as user preferences, facts, and procedures. Consider a travel assistant. The user says: - I usually prefer an aisle seat. - For this flight, book a window seat. - The flight is delayed by 25 minutes. These statements should not receive identical treatment. The aisle-seat preference could help with future bookings. The window-seat request applies to one flight. The delay becomes useless once the flight is over. A capable memory system may already handle this distinction. Graphiti, for example, records where a fact came from, resolves it against existing facts, and tracks when it becomes valid or invalid. If the source contains enough context, it can keep the window-seat request specific to one trip. So Jev should not be added to recreate logic the memory system already provides. It becomes useful when the application has its own rules for what may enter long-term memory. A travel application might require that: - Only preferences stated or confirmed by the user become account-level memories. - Preferences inferred from one booking remain attached to that trip. - Passport numbers and payment details never enter general memory. - Ambiguous candidates remain in the session until the user confirms them. These rules require semantic judgment. Once the info has been classified, ordinary code can enforce the policy. The challenge here is deciding whether a sentence describes a lasting preference, a one-time instruction, or weak evidence for an inferred preference. Jev can make that decision before the app even invokes Graphiti. For each candidate, the application sends Jev the proposed fact, its source evidence, and the current user, trip, and session state. It can ask typed questions such as: - Did the user state this preference explicitly? - Does it apply beyond the current trip? - Which retention scope fits it? - Would reusing it on another booking create a meaningful risk? Jev returns choices, scores, and probabilities. Application code applies the thresholds: ↳ Save the aisle-seat preference for the user. ↳ Keep the window-seat request with this trip. ↳ Leave the delay in the active session. ↳ Reject sensitive fields before they reach general memory. Several questions can share the same state in one Jev request. - Approved candidates are then sent to Graphiti as episodes. - From there, Graphiti handles extraction, entity resolution, provenance, temporal updates, and retrieval. GitHub repo: https://github.com/getzep/graphiti (don't forget to star it ⭐) Note that if Graphiti's existing ingestion behavior meets your application's requirements, the Jev gate is unnecessary. Add Jev when you need to check product-specific rules, such as whether a preference was explicitly confirmed or whether a fact is safe to store, before sending it to Graphiti. If you want to dive deeper, I have also written a hands-on guide showing how to build a Jev-style model with open models, entirely locally. Read it below.

这条是引用着另一条写的：x.com/1175166450832687104/status/210156361064449…