基于 MemNet 基础设施构建智能体 Zettelkasten 认知记忆架构

绪论：大型语言模型的状态危机与记忆抽象的范式转移

在当代人工智能的发展轨迹中，构建具备长期连贯性、复杂推理能力以及自我演化特征的自主智能体（Autonomous Agents）始终面临着一个基础性的架构瓶颈：如何有效地管理认知状态与时间维度的记忆。传统的技术路径倾向于通过不断扩大大型语言模型（LLMs）的上下文窗口（Context Window）来容纳海量的历史对话与事实数据。然而，这种将记忆强行内化于模型的工程范式从根本上混淆了计算引擎与存储介质的边界，导致了不可避免的系统性退化。语言模型本质上是无状态的推理引擎，其核心优势在于短程逻辑演绎与模式补全，而非充当状态机、关系型数据库或持久化的身份容器。

当开发者试图通过不断累积提示词文本来迫使模型维持长期连续性时，系统便陷入了认识论层面的危机。随着时间的推移，早期注入的事实会在注意力机制中发生语义漂移，智能体的语气出现波动，先前的决策与当前的逻辑产生矛盾，最终不可避免地引发幻觉现象 1。这种衰退并非因为模型本身的推理能力孱弱，而是由于"模型记忆"这一抽象概念本身存在致命缺陷 1。即使是广泛采用的检索增强生成（RAG）技术，也仅能部分缓解这一问题。RAG 技术能够高效地检索文档和回答孤立问题，但它依然将记忆降维成了单纯的被动检索文本，未能真正保存对话状态、身份的连贯性以及行为的连续性。

为了实现真正意义上的长视距认知连贯性，必须完成一次深刻的架构范式转移：将模型纯粹视为推理引擎，而将记忆、身份和信息召回机制外置到一个显式的、结构化的运行时层中 1。在这一新范式下，记忆表现为结构化的文件与事件，身份表现为持久化的配置文件，而信息召回则是在模型推理前进行的确定性上下文组装过程 1。系统不再要求模型去"记住"任何东西，而是在每一个推理回合，向其提供经过精确计算和组合的当下所需信息 。

基于上述理论背景，本文将深入剖析如何利用 MemNet：https://github.com/TianqiZhang/mem.net 这一专为智能体设计的统一记忆基础设施，在其之上构建严谨的 Zettelkasten（卡片盒）笔记方法论架构。MemNet 提供了底层的文件持久化、上下文组装、事件检索与并发控制等"管道"（Plumbing）能力，而 Zettelkasten 则在应用层赋予了这些数据以思想链接与认知生长的灵魂。二者的结合，为构建具备可组合性、简单性且防冲突的下一代智能体记忆系统提供了完整的蓝图。

Zettelkasten 方法论：机器认知的认识论基础

为了在模型外部构建具有演化能力的记忆结构，Zettelkasten（卡片盒）笔记方法论提供了一个经过几代学者（如社会学家尼克拉斯·卢曼）验证的、高度优化的信息处理框架 。虽然该方法论最初是为人类学术研究和非虚构写作设计的，但其强调原子化、去中心化链接和结构化工作流的核心理念，与现代自主智能体的认知需求呈现出惊人的契合度。

Zettelkasten 将零散的信息输入转化为系统化知识储备的核心在于其对笔记类型的严格分类以及强制性的信息加工工作流。在智能体运行的语境下，这种分类机制构成了其信息代谢的基础架构。

临时笔记（Fleeting Notes）构成了智能体感知世界的最前沿缓冲区。它们是智能体在执行网页抓取、处理用户对话或进行多步逻辑推理时产生的碎片化想法、即时任务和原始观察记录。临时笔记的本质是短暂的，如果不经过及时的二次处理，其内在的逻辑价值就会随着任务的结束而消散 4。文献笔记（Literature Notes）则作为外部知识的锚点，负责客观记录智能体从外部 API、参考文档或用户语料中提取的原始文本内容，并附带智能体自身的初步理解与摘要 2。文献笔记确保了外部输入数据的原貌与智能体的内部演绎之间保持清晰的界限，为后续的回溯和引用提供了可靠的依据。

永久笔记（Permanent Notes 或 Zettels）是整个卡片盒系统的核心资产，也是智能体长期记忆的真正载体。与临时笔记的碎片化和文献笔记的依附性不同，永久笔记必须被提炼为单一、原子的概念（Atomic Idea），并剥离所有临时的上下文依赖，使其能够在孤立状态下被完全理解 2。更关键的是，永久笔记的价值并不在于其内容的孤立存储，而在于它必须被显式地链接到系统中现有的其他笔记上，从而在文件系统之上编织出一张高度关联的语义网络。

从临时笔记向永久笔记的转化，构成了 Zettelkasten 方法论中最重要的"生产力步骤"。在这一转化过程中，智能体必须主动对输入的数据进行深度加工，用自己的逻辑重新解释信息，并寻找新知识与既有认知架构之间的关联。需要强调的是，这里的"永久"并非指代物理意义上的不可篡改。正如卡片盒实践者所指出的，没有任何笔记是绝对完整的，所有的笔记都具备极强的可塑性，它们只是在当前的认知阶段达到了相对成熟的状态 6。智能体可以像驾驶火箭一样，在不断的运行中持续地为旧笔记添加新的链接、修正过时的参考，或者根据新涌现的证据重构原有的知识主干 6。这种持续重构的机制，使得智能体的记忆不再是一个单向堆积的"半成品堆肥"，而是一个能够自我纠错、自我生长的有机认知体。

MemNet 基础设施：构建卡片盒的底层管道

尽管 Zettelkasten 提供了完美的认知框架，但其有效运转高度依赖于底层的存储架构、检索机制以及并发控制。MemNet 开源项目正是为此类复杂智能体记忆需求设计的统一内存框架。MemNet 在架构上分为应用层、内存调度层和存储底座层，为智能体提供了记忆的保存、更新、转移和回滚的统一 API，使得基于结构化内存的工作流得以无缝集成。

MemNet 的设计哲学是不强迫开发者使用任何特定的设计模式，而是提供简单、可组合的基础设施。正如前文所述，MemNet 提供的核心能力恰好与 Zettelkasten 的核心需求形成了完美的对应关系。这种关联并非巧合，而是源于对智能体长期连续性需求的深刻理解。

Zettelkasten 核心概念	MemNet 基础设施映射与实现方式	在智能体认知架构中的功能定位
原子化笔记 (Atomic Notes)	持久化的文件存储系统。通过明确的 Markdown 文件进行物理隔离。	提供离散的、纯文本的认知单元，确保智能体可以通过标准的操作系统命令或 API 进行读写。
显式链接与关系 (Explicit Links)	通过文件路径组织（如 projects/ 前缀）以及基于 context:assemble 的确定性上下文组装机制。	模拟人类的语义记忆，建立概念与概念之间确定的逻辑桥梁，超越单一文件的孤立性。
可搜索的关联 (Searchable Associations)	基于历史记忆的事件摘要与语义搜索能力（events:search API）。	模拟人类的情景记忆，允许智能体在庞大的历史语料库中跨越时间维度提取未被显式链接的潜在关联模式。
版本与冲突控制 (Version Control)	基于 HTTP ETag 的乐观并发控制（Optimistic Concurrency Control）与 PATCH 更新机制。	确保多线程或人机协作场景下对卡片盒的并发写入不会导致数据相互覆盖或认知图谱损坏。

在将抽象的卡片盒理念映射到具体的物理实现时，智能体原生设计（Agent-Native Design）的一条黄金准则发挥了指导作用：为智能体所能推理的事物进行设计，而人类能够理解的结构通常是最好的代理指标。如果一个人类观察者能够通过浏览文件系统的目录树清晰地理解项目的状态和逻辑，那么基于 LLM 的智能体同样能够毫无障碍地解析这一结构。因此，系统摒弃了复杂的、带有不可见约束的传统数据库表结构（例如需要执行复杂的 SELECT * FROM notes WHERE project_id = 123），转而采用直接映射卡片盒结构的自文档化（Self-documenting）扁平文件系统。

利用 MemNet 的持久化能力，我们可以将 Zettelkasten 的拓扑结构具体化为以下目录树：

首先是核心笔记区域，通常以 profile.md 为代表。它充当着智能体的核心知识库与永久笔记的集合，定义了智能体的底层身份、全局偏好以及那些经过长期沉淀、无需频繁变动的基石性规则 10。这部分文件是智能体每次启动时必须校验的认知基准。

其次是专题笔记区域，位于 projects/ 目录下，表现为如 projects/{topic}.md 的形式。这里聚集了特定任务或领域的上下文、阶段性目标以及当前活跃的推理逻辑。这种结构在逻辑上隔离了不同领域的认知状态，确保智能体在处理某个具体项目时，其注意力机制不会被其他不相关项目的上下文所污染。

最后是临时笔记与文献笔记区域，位于 notes/ 目录下，表现为 notes/{zettel-id}.md 的形式。这里是智能体每天产生的原始对话记录、抓取的网页片段以及未经验证的推理碎片。这些文件是高度动态的缓冲区，等待着在夜间或特定触发条件下，被智能体进一步加工、提炼，并最终以永久笔记的形式合并到核心知识库或特定专题中。

必须指出的是，MemNet 仅仅提供了这些持久化的文件实体以及操作它们的底层"管道"，而 Zettelkasten 的精髓------思想的链接与语义网络的生长，并不在于文件系统本身的层级结构，而在于智能体如何在这些文件之间建立逻辑引用，以及如何在需要时精准地召回它们。

确定性上下文组装与认知工程

在智能体利用 Zettelkasten 执行复杂任务时，最为关键的步骤是在将提示词（Prompt）送入大语言模型进行推理之前，构建高质量的上下文环境。在基于 MemNet 的架构中，这一过程通过调用 context:assemble API 来实现。

传统的暴力拼接法往往试图将尽可能多的历史笔记塞入模型的超长上下文窗口中。然而，实践证明，百万级别的 Token 窗口在多轮复杂对话中往往表现为一种"作弊码"，其代价是高昂的延迟、计算成本以及极为严重的上下文漂移。信息架构的质量直接决定了模型输出的质量，简短、高度聚焦的提示词在解决特定问题时，其表现稳定地优于冗长且焦点涣散的上下文。

因此，上下文本身已经演变为一种 API，而持久化不再是模型内部自动处理的问题，而是一个系统设计层面的工程挑战。context:assemble 赋予了智能体执行"确定性认知组装"的能力。当智能体需要检索相关记忆来推进工作流时，它并非依靠模型自身那不可靠的参数权重进行隐式回忆，而是根据当前的意图，显式地组装特定的物理文件。

例如，当智能体被要求为一个正在进行的项目起草一份技术文档时，其控制逻辑会精准地预取（Pre-fetch）以下组件：用于校准行为基准的 profile.md，包含项目当前进度与约束条件的 projects/{topic}.md，以及数个与该技术栈相关的原子化永久笔记 notes/{zettel-id}.md。这种确定性的预取策略遵循了一个重要的性能原则：如果下一步的推理必然需要数据 X，智能体应当直接在外部运行时层将其获取，而不是浪费一次昂贵的大语言模型网络往返（Round-trip）让模型自己提出请求。

通过这种方式，智能体可以动态地修改每个回合之间的上下文，实施摘要、剪枝或重新构建框架的操作，从而有效地遏制认知漂移的发生。在这种架构下，模型不再受到知识冲突（如上下文与内部记忆的冲突、不同上下文片段之间的冲突）的困扰，因为外部的 Zettelkasten 已经通过显式的文件修改消除了逻辑矛盾，并向模型提供了一个具有绝对一致性的"即时工作记忆池"。

关联事件摘要与时间维度的语义检索

虽然卡片盒的核心在于通过文件路径（如 projects/ 前缀）和 Markdown 超链接所建立的显式关系，但智能体在真实环境下的运行必然伴随着大量未被即时分类的对话、系统日志和临时观察。为了在这些非结构化、隐式的历史数据中建立连接，系统必须具备跨越时间维度的检索能力。MemNet 提供的 events:search API 恰好填补了这一空白。

在现代系统设计中，事件搜索 API 是一种成熟的查询范式。正如 Datadog 或 RedHat 的企业级事件追踪系统允许开发者通过布尔逻辑（AND、OR）、通配符、转义字符以及基于标签和特征的键值对（Key-Value）进行海量日志筛选一样，MemNet 的事件检索机制允许智能体在深层的历史交互中进行细粒度的挖掘。这类似于利用 Gmail 高级查询语言（例如通过 from:、特定日期或特定的 message-id）在收件箱中定位一封几年前的邮件。

在智能体的 Zettelkasten 工作流中，events:search 扮演着情景记忆（Episodic Memory）回溯工具的角色。假设用户询问智能体："我们在上个月讨论那个数据管道重构方案时，你提到的那个关于缓存优化的关键阻碍是什么？"由于这一对话可能发生得过于匆忙，尚未被智能体提炼为具有明确 ID 的永久笔记。此时，智能体无法通过确定性的 context:assemble 直接获取该文件。

相反，智能体会构造一个带有时间界限和语义关键字的事件搜索查询。MemNet 的底层服务将遍历历史事件的摘要，提取出相关的对话片段，并将其返回给智能体。随后，智能体利用这些从深层历史中打捞出的"临时笔记"重新激活该话题的上下文。在此基础上，智能体不仅能够准确回答用户的问题，更重要的是，它可以利用这次检索的机会，启动前文所述的"生产力步骤"，将这段被遗忘的缓存优化逻辑正式提炼为一个新的 notes/{zettel-id}.md 永久笔记，并将其链接到 projects/data-pipeline.md 之中。这就构成了一个完整的、由检索驱动的知识生长闭环。

ETag 乐观并发控制：确保分布式认知的数据一致性

当智能体的记忆被抽象为成百上千个存在于文件系统中的 Markdown 文件，并且这些文件同时暴露给自动化的后台代理任务、主动响应用户的推理线程，甚至是通过本地编辑器（如 Obsidian 或 VS Code）直接修改文件的底层人类用户时，一个严峻的系统工程挑战便浮出水面：并发写入导致的脏数据覆盖与状态损坏。

如果两个不同的进程（例如，智能体正在后台提炼一个庞大的文献笔记，而用户恰好在同时打开同一个文件修改了一个关键概念）在没有协调的情况下覆盖对方的更改，Zettelkasten 的逻辑一致性就会遭到毁灭性的破坏。传统的解决方案通常依赖于悲观锁机制（如使用 Redis Lua 脚本实现的分布式内存锁），但这将极大增加系统的复杂性，并导致严重的读写瓶颈，使高频的记忆更新变得难以忍受。

为了实现优雅的并发控制，MemNet 采用了基于 HTTP ETag（实体标签）的乐观并发控制（Optimistic Concurrency Control, OCC）架构。OCC 的核心哲学在于：在大多数基于 Web 的分布式环境中，多个进程在同一时间精确修改同一块数据的概率极低。因此，系统应当避免昂贵的锁定开销，默认所有操作都是安全的，仅在最终提交数据时验证是否发生了冲突 23。

ETag 是一种由服务器生成的、不透明的标识符（通常是文件内容的哈希值或特定的版本序列号），用于唯一标记某个资源在特定时刻的状态化身。在 MemNet 架构中，所有对卡片盒文件的确定性更新都必须严格遵循带有 ETag 验证的 RESTful PATCH 操作生命周期，以保证数据的绝对一致性。

乐观并发控制阶段	系统行为特征与 HTTP 协议表现	MemNet 智能体具体执行逻辑
检索与标记 (Retrieve & Tag)	智能体发送 GET 请求获取指定笔记文件。MemNet 响应 200 OK，并在 HTTP 头中附加 ETag: "hash_value_A" 。	智能体不仅读取笔记内容到其工作内存中，同时将该 ETag 值缓存在本次任务的上下文中。
本地处理 (Modify)	智能体在其沙盒环境中执行内部推理。	智能体阅读文献笔记，提炼出新的观点，并准备更新该文件。此过程完全不阻塞其他读写操作。
条件提交 (Conditional PATCH)	智能体发起 PATCH 更新请求。关键在于，请求头中必须包含条件控制指令：If-Match: "hash_value_A" 。	智能体向 MemNet 宣告："仅当该文件当前的状态依然是 hash_value_A 时，才应用我的这些修改。"
验证与决断 (Validate & Commit/Rollback)	MemNet 服务端进行底层数据比对。	若当前物理文件的 ETag 仍为 A，则无冲突，系统写入数据，返回新的 ETag B。若文件已被其他进程修改（ETag 变为 C），则产生并发冲突。
冲突处理 (Conflict Resolution)	根据 RFC 规范，服务端拒绝写入并返回 HTTP 状态码 412 Precondition Failed（部分实现返回 409 Conflict）。	智能体捕获到 412 错误，知晓文件已被改变。它将重新拉取最新文件（获得 ETag C），将自己的修改与新内容进行智能合并，随后再次尝试带条件更新 。

这种"读取-修改-写入"的循环（Read-Modify-Write Cycle）在底层架构中构筑了一道坚不可摧的防线。它不仅确保了智能体自身并发任务之间的安全性，更确立了人机协作的边界，防止了智能体在后台静默覆盖人类用户通过文本编辑器精心撰写的长文笔记 。

此外，ETag 的引入还为系统带来了显著的性能增益，这在涉及大量原子化文件频繁调用的卡片盒系统中尤为关键。当智能体通过 context:assemble 频繁加载不变的底层 profile.md 或某些核心知识库节点时，可以利用 If-None-Match 请求头执行条件拉取。如果文件未被修改，MemNet 将直接返回 304 Not Modified 响应，从而完全省去了有效载荷的传输。根据相关双原生（Dual-Native）API 架构的实测数据，这种"零提取"（Zero-Fetch）模式能够将内存分配从数兆字节降低至零，使得响应时间实现超过 90% 的缩减，大幅优化了基础设施的运转效率和 Token 成本。

拓扑结构与工作流实现：基于本地文件系统的代理记忆

脱离抽象理论，我们将目光转向基于 MemNet 搭建的智能体 Zettelkasten 的实际物理拓扑。放弃使用云端闭源数据库（如 Notion、Todoist 等）而将整个工作区结构化为由 Git 追踪的纯文本 Markdown 文件池，代表了数据主权与安全架构的觉醒 。

当个人知识、深度反思（甚至是类似心理治疗的深层剖析）被存储在封闭的第三方服务器上时，存在着极大的隐私隐患与平台锁定风险。MemNet 的设计允许用户的记忆被完全本地化或容器化，所有数据仅仅是一组以极高可移植性分布的 Markdown 文件。如果未来弃用当前系统，这些积累了数年的数字资产依然可以被任何纯文本编辑器无损读取 。

在这个文件系统中，日常运作的工作流呈现出高度自动化的特征：

1. 日间信息缓冲：在日常的人机交互中，所有的上下文、网址链接、临时任务都被快速地追加到缓冲区的 notes/ 目录下。此时不需要考虑结构的优美，只追求捕获的速度与完整性。
2. 夜间重构机制（Cron 调度）：这类似于人类睡眠期间的记忆巩固。通过设定定时任务（Cron job），系统会唤醒一个专门负责知识整理的后台智能体进程。
3. Zettel 时间（Zettel Time）：智能体通过 events:search 拉取当日产生的临时笔记碎片。利用其推理能力，剔除冗余信息，将核心事实转化为文献笔记，并将新的思想火花升华为带有明确 ID 的永久笔记。
4. 显式图谱建立：最为关键的是，智能体会在新笔记中写入 [[指向其他笔记的链接]]，或者通过 context:assemble 将这些新知识合并更新到 projects/{topic}.md 对应的专题逻辑树中。
5. 持久化与版本控制：所有更新通过带有 ETag 校验的 PATCH 接口写入硬盘，随后整个工作区（Workspace）被提交（Commit）并推送到私有的代码托管仓库（如 GitHub）进行加密备份。

同时，这种明确的本地文件架构为实施分层的智能体安全策略（Security Tiers）提供了理想的物理边界。随着智能体向高级形态（Tier 2/Tier 3）演进，其拥有的执行权限与"爆炸半径"成倍增加。在安全基准要求下，绝不能天真地依赖提示词约束（Prompt Instructions）作为抵御攻击的安全墙。模型容易遭受越狱和提示词注入攻击，导致其违背指令。真正的防御在于工具层面的硬性访问控制。通过操作系统的文件权限控制，配合 MemNet 的挂载限制，系统可以物理隔离智能体访问敏感环境变量（.env）的能力，同时完全放开对其指定 Zettelkasten 工作目录的读写权限，从而在确保绝对安全的前提下，不损害其认知构建的自由度。

结论与未来演进方向

大型语言模型在具备惊人推理能力的同时，受困于其作为无状态引擎的内在缺陷。盲目依赖超长上下文窗口来维系系统的连贯性，是一条充满性能损耗与认知幻觉的歧途。真正的突破，在于将记忆从模型中抽离，并在外部构建一个结构严密、逻辑自洽的认知运行时环境。

本文详尽论证了基于 MemNet 基础设施构建 Zettelkasten 认知记忆架构的技术可行性与显著优势。MemNet 提供了一个强大、简单且可组合的底层管道层。它不仅通过持久化的文件系统保障了原子化笔记的物理独立性，更通过 context:assemble 赋予了智能体进行确定性认知预取与上下文工程的能力。辅以跨越时间维度的 events:search 语义检索，智能体完美缝合了基于逻辑的显式记忆网络与基于时序的隐式情景记忆。此外，严格遵循 HTTP 规范的 ETag 乐观并发控制机制，为这套复杂的数据流转系统上了一把无形的锁，在不牺牲性能的前提下消灭了并发冲突，保障了人类与多智能体协作环境下的数据绝对一致性。

然而，基础设施本身无法产生智慧。Zettelkasten 的精髓并不在于硬盘上的文件夹层级，而在于那些穿梭于原子化笔记之间的思想链接。MemNet 搭建了坚实的底座，而这套记忆方法论必须由智能体在顶层逻辑中严格贯彻执行。当这种架构被完美实现时，系统将展现出令人惊叹的复利效应：智能体不再是一个每次重启都失去灵魂的对话脚本，而是一个随着时间推移、知识不断沉淀、链接不断丰富的进化实体。它能够在其日益庞大、结构精巧的卡片盒中，自主推演出超越其原始训练数据的零日洞见（Zero-day Insights），最终迈向具备真正长期连贯性的高阶机器认知时代。

引用的文章

1. Why Model Memory is the Wrong Abstraction (from someone running local models) - Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1pl44ud/why_model_memory_is_the_wrong_abstraction_from/
2. From Fleeting Notes to Project Notes -- Concepts of "How to Take Smart Notes" by Sönke Ahrens - Zettelkasten.de, https://zettelkasten.de/posts/concepts-sohnke-ahrens-explained/
3. My Zettelkasten workflow from start to finish - jay l. colbert, https://wilde-at-heart.garden/pages/my-zettelkasten-workflow-from-start-to-finish/
4. My Zettelkasten Journey: Understanding the Differences between Fleeting Notes, Literature Notes, Reference Notes, and Permanent Notes | by Haikal Kushahrin | Medium, https://medium.com/@haikalkushahrin/my-zettelkasten-journey-understanding-the-differences-between-fleeting-notes-literature-notes-f7849b608152
5. workflow - from fleeting and literature notes to permanent notes : r/Zettelkasten - Reddit, https://www.reddit.com/r/Zettelkasten/comments/tb957t/workflow_from_fleeting_and_literature_notes_to/
6. Fleeting to Permanent notes - Zettelkasten Forum, https://forum.zettelkasten.de/discussion/3142/fleeting-to-permanent-notes
7. INTELLIGENCE BEGINS WITH MEMORY, https://memos.openmem.net/
8. MemOS Cloud - OpenMem, https://memos-docs.openmem.net/
9. Agent-native Architectures: How to Build Apps After Code Ends - Every, https://every.to/guides/agent-native
10. A Practical Guide to Securely Setting Up OpenClaw. I Replaced 6+ Apps with One "Digital Twin" on WhatsApp. | Medium, https://medium.com/@srechakra/sda-f079871369ae
11. Used my Claude Code workflow to build myself an AI therapist that actually remembers : r/ClaudeCode - Reddit, https://www.reddit.com/r/ClaudeCode/comments/1qy7snx/used_my_claude_code_workflow_to_build_myself_an/
12. README.md - huytieu/COG-second-brain · GitHub, https://github.com/huytieu/COG-second-brain/blob/main/README.md
13. Context Engineering | Shav Vimalendiran, https://shav.dev/blog/context-engineering
14. Knowledge Conflicts for LLMs: A Survey - ACL Anthology, https://aclanthology.org/2024.emnlp-main.486.pdf
15. A Survey of Progress and Challenges in Aligning LLMs with Human Intentions - arXiv.org, https://arxiv.org/html/2502.09101v2
16. Search Syntax - Datadog Docs, https://docs.datadoghq.com/events/explorer/searching/
17. Events - Datadog Docs, https://docs.datadoghq.com/api/latest/events/
18. 25.4. Methods | Version 3 REST API Guide | Red Hat Virtualization | 4.3, https://docs.redhat.com/en/documentation/red_hat_virtualization/4.3/html/version_3_rest_api_guide/methods8
19. Gmail - Cortex XSOAR, https://xsoar.pan.dev/docs/reference/integrations/gmail
20. Diff - 4709197c830fd17d9a9f0f80e1533a8f0597153b^! - external/googleappengine/python - Git at Google, https://chromium.googlesource.com/external/googleappengine/python/+/4709197c830fd17d9a9f0f80e1533a8f0597153b^!/
21. Ticket master system design. Requirements | by Dilip Kumar | Medium, https://dilipkumar.medium.com/ticket-master-system-design-e794c51d79f7
22. Optimistic concurrency control - Wikipedia, https://en.wikipedia.org/wiki/Optimistic_concurrency_control
23. ETags in ASP.NET Core - Peter Ritchie's Blog, https://blog.peterritchie.com/posts/etags-in-aspdotnet-core
24. ETag Based Atomic Updates with in .NET 9 Web API and React - Vineet Sharma - Medium, https://mvineetsharma.medium.com/etag-based-atomic-updates-with-in-net-9-web-api-and-react-07dca77c5527
25. ASP.NET Core ETAg middleware - gists · GitHub, https://gist.github.com/madskristensen/36357b1df9ddbfd123162cd4201124c4
26. State management overview | Dapr Docs, https://docs.dapr.io/developing-applications/building-blocks/state-management/state-management-overview/
27. Manage concurrency in Blob Storage - Azure - Microsoft Learn, https://learn.microsoft.com/en-us/azure/storage/blobs/concurrency-manage
28. version number vs ETag for optimistic concurrency - Stack Overflow, https://stackoverflow.com/questions/70785261/version-number-vs-etag-for-optimistic-concurrency
29. Policy | Generative AI on Vertex AI | Google Cloud Documentation, https://docs.cloud.google.com/vertex-ai/generative-ai/docs/reference/rest/Shared.Types/Policy
30. MemoryStorage class | Microsoft Learn, https://learn.microsoft.com/en-us/javascript/api/@microsoft/agents-hosting/memorystorage?view=agents-sdk-js-latest
31. Proposal: A Standardized Data & State Layer for Agentic AI · WordPress ai · Discussion #99, https://github.com/WordPress/ai/discussions/99
32. A Comprehensive Survey of Large Model and Agent Safety - arXiv, https://arxiv.org/html/2502.05206v5
33. A BENCHMARK FOR SEMANTIC SENSITIVE INFORMA- TION IN LLMS' OUTPUTS - TITLE, https://netsec.ccert.edu.cn/files/papers/iclr25-llm-sensitive.pdf