Agent memory需要它的OpenTelemetry时刻
Agent memory needs its OpenTelemetry moment
现在的Agent记忆格式五花八门：AGENTS.md、CLAUDE.md、Cursor规则、Anthropic的memories目录、GitHub Copilot的仓库事实，还有各种MCP服务器。它们各自为政，互不相通。CI Agent学到的东西，Editor Agent读不到，下一个工具也看不懂。问题不在于缺工具，而在于缺共识。就像2019年前的可观测性领域，每个厂商都有自己的格式，直到OpenTelemetry出现。现在Agent memory正处于同样的转折点：格式还很年轻，可以改变；Linux Foundation的Agentic AI Foundation已经提供了中立平台。我们需要在数据模型、语义约定和协议上达成一致，让工具在存储、查询和分析上竞争，而不是在格式上重复造轮子。
HN 评论区
108- lmeyerov
依我之见，这属于过早优化。
我对 OTEL 的 LLM 扩展很满意，但更希望它成为一个元协议（meta protocol），而不是实际的协议或标准：
1. 记忆（Harness memory）的整个技术栈——从数据存储、表示到整体概念——其方法都在快速演变。可以说，我们正处于一个早期原始阶段，因为目前还在使用文本而非语义向量等。
2. 即便是像知识图谱这样基础的东西，也有多种多样的实现方法。
3. 类似于 REST API，我认为应该要求供应商支持某些批量操作，但这应是在元层面，而非协议层面。
作为一名盈利的 Harness 设计者（Louie.ai），我早在近两年前就开始折腾 autowikis，我觉得这些东西才刚刚开始，远未结束，现在讨论这些反而有些分散注意力。OTEL+LLM 扩展是另一个话题，那是我们的用户真正需要的即插即用方案。对于 A2A 用途，为我们的记忆系统提供一个技能文件（skill file）就足够了。
- armchairhacker
这是个重大问题吗？似乎每个 AI“文本格式”问题都有 15 种解决方案，但所有这些方案本质上只是给 AI 喂食非正式英语时加了一层结构。我认为“Transformer”模型恰恰擅长将这种结构剥离成通用形式（这也是为什么它能基于整个互联网进行训练的原因）。
AI 确实能从学习使用技能以及接受良好结构的指令中受益（例如“将 [特定重要细节] 保存到记忆中”和“在实施任何内容前先制定计划”）。但这些记忆解决方案中，似乎没有哪个明显优于其他，它们基本上只是不同的文件夹。你的 CLAUDE.md 可以说“参见 AGENTS.md”，而 AGENTS.md 可以说“将记忆写入 .agent/memories/”。我可能会对这种差异感兴趣并想测量一下，但我假设它的表现与原生 CLAUDE.md 和 .claude/memories 几乎完全一样。
我注意到 AI 做得比我好的一件事是：它不会像我有强迫症那样，执着于寻找“完美”的解决方案。
- speedping
整篇博客文章都散发着 LLM 的味道。
如果有一种足够可靠的方法来检测 LLM 生成的文本，我会开发一个浏览器扩展，直接将其全部过滤掉。
- Fordec
关于总体前提，我同意。但我不认为那个时刻就是今天，至少现在还不是。我认为我们尚未理解处理上下文和记忆的正确方式，也不知道它们应该持续多久，更不用说过早地在一个抽象标准上达成一致，最终导致它像 SOAP 或 SGML 那样过时。
- baalimago
我们真的需要这个吗？LLM 擅长的是解读自然语言。所以它就像海绵一样，能吸收特定项目中使用的任何格式：因此并不需要预定义格式。
此外，我们真的希望用户 A 的代理记忆与用户 B 的记忆共存吗？其实并不。因此，关于协作和共享的论点相当薄弱，至少对于编码代理而言是这样的。仓库特定的上下文可以编码到 docs/ 或 architecture/ 目录中，就像在代理出现之前所做的那样。
至于监控已部署的代理：也许吧。为此，我构建了一个（又一个）记忆管理工具 slivingdoc.dev，通过它可以拉取所有代理的持久化上下文。但这里的问题在于分布式系统，而非记忆格式。
- imgyuri
在代理记忆的情况下，对统一格式或规范的需求大大降低，因为根据定义，它是供代理读取的，而代理已经被指示/编程为能够读取不同格式的记忆文件。即使不存在这样的指示，代理也极其擅长遍历文件以获取所需的上下文。
- palijer
现在提倡针对这个问题进行标准化还为时过早。OTel 是经过该领域数十年的经验发展而来的，我们在开发 Otel 时探索了无数种解决方案并从中汲取了经验。
如果说我们现在在代理记忆解决方案上已经探索得足够多，足以将其标准化并给任何进一步的实验增加摩擦，我认为这是一个错误。
- Dirak
不，它不需要。LLM 领域仍有大量创新/变化正在发生，没有任何解决方案是放之四海而皆准的。据我所知，解决方案必须在三个主要关注点之间进行权衡：速度、准确性和成本。我甚至不认为“将记忆作为文件”这一点已经板上钉钉。这个领域还有大量的创新和进步空间。