过去几个月，AI Agent 正在从“会聊天的工具”变成真正的工作伙伴：它们可以理解代码库、调用外部工具、执行多步任务，还能通过 Skills、MCP 和子 Agent 组合出更复杂的工作流。
但 Agent 越强，记忆断裂的问题就越明显。一个 Agent 记住了你的技术栈，另一个 Agent 不知道你的代码规范；一个 Agent 了解项目中的关键决策，切换工具后又要从零解释。Memmy 的发布，指向的正是这一层缺失的基础能力：让不同 AI 共享关于“同一个你”的长期上下文。
Agent 的短期上下文不等于长期记忆
大多数 Agent 都能读取当前对话、项目文件和工具返回结果，但这些信息通常只服务于当前任务。对话结束、会话切换，甚至更换 Agent 后，以下内容可能全部丢失：
- 你偏好的编程语言、框架和工具链
- 项目中已经确认的架构决策
- 你习惯的代码风格、提交方式和沟通格式
- 曾经验证过的方案，以及明确放弃某个方案的原因
- 某个业务领域中的长期背景知识
这不是简单地增加一个更大的上下文窗口就能解决的问题。上下文窗口适合承载当前任务，长期记忆则需要被组织、检索、更新和治理。
可以把两者区分为：
当前上下文：我现在正在修复哪个 Bug？
长期记忆：我通常使用什么测试策略？这个项目为什么不用某个依赖？
如果长期记忆只存在某个 Agent 的私有会话中，用户就会被绑定在特定工具上。共享记忆层的价值，在于把“关于用户和项目的知识”从单个 Agent 中分离出来，成为多个 Agent 都能使用的基础设施。
Memmy 解决的是跨 Agent 的连续性
从产品定位看，Memmy 并不是另一个只负责回答问题的聊天窗口，而更接近 Agent 生态中的记忆层。它要承接的是跨会话、跨工具和跨 Agent 的连续性。
一个典型流程可以这样理解：
- Agent 在执行任务时发现新的稳定事实，例如项目采用 PostgreSQL，部署由 GitHub Actions 完成。
- 这些事实被整理成可检索的记忆，而不是原样保存整段对话。
- 后续 Agent 在处理相关任务前检索记忆。
- Agent 根据当前任务使用这些信息，同时把新的决策或修正写回记忆层。
这种模式可以让不同类型的 Agent 共享同一套基础信息：代码 Agent 读取工程约定，文档 Agent 读取表达偏好，运维 Agent 读取部署限制，研究 Agent 读取领域背景。它们不需要共享全部对话，只需要访问经过整理、与任务相关的记忆。
实践中要把记忆当成数据管理问题
“让 AI 记住一切”听起来很诱人，但无限保存会带来噪声、隐私和错误传播问题。可以这样实践：把记忆拆成带有来源、范围和更新时间的结构化记录。
下面是一个假设性的记忆服务 API 示例。它不是 Memmy 的官方接口，而是展示接入共享记忆层时可以采用的数据形态。运行前，将 MEMORY_URL 改成实际服务地址，并根据服务要求补充认证信息。
export MEMORY_URL="http://localhost:8080"
# 写入一条项目级长期记忆
curl -X POST "$MEMORY_URL/v1/memories" \
-H "Content-Type: application/json" \
-d '{
"scope": "project:payments-api",
"kind": "architecture_decision",
"content": "支付服务统一使用 PostgreSQL 事务保证订单状态和支付记录的一致性。",
"source": "agent:backend-reviewer",
"confidence": 0.92,
"tags": ["database", "transaction", "payments"]
}'
# 在新任务开始前检索相关记忆
curl -G "$MEMORY_URL/v1/memories/search" \
--data-urlencode "scope=project:payments-api" \
--data-urlencode "query=订单状态更新和支付记录如何保持一致"
一个实际的 Agent 可以把记忆检索放在任务执行前，把写入放在任务完成后。伪代码如下：
import os
import requests
MEMORY_URL = os.environ["MEMORY_URL"]
SCOPE = "project:payments-api"
def load_context(query: str) -> list[dict]:
response = requests.get(
f"{MEMORY_URL}/v1/memories/search",
params={"scope": SCOPE, "query": query},
timeout=10,
)
response.raise_for_status()
return response.json()["items"]
def save_decision(content: str, source: str) -> None:
response = requests.post(
f"{MEMORY_URL}/v1/memories",
json={
"scope": SCOPE,
"kind": "task_decision",
"content": content,
"source": source,
"confidence": 0.8,
},
timeout=10,
)
response.raise_for_status()
memories = load_context("如何修改支付状态以及需要运行哪些测试")
context = "\n".join(f"- {item['content']}" for item in memories)
prompt = f"""你正在维护支付服务。
请遵守以下长期项目记忆：
{context}
现在检查支付状态更新逻辑，并给出需要补充的测试。"""
print(prompt)
# Agent 完成任务后，只有稳定且可复用的结论才应该写回。
save_decision(
"支付状态变更需要覆盖重复回调场景，并验证事务失败时订单不会进入已支付状态。",
"agent:test-planner",
)
这里有一个关键边界：不要把所有中间推理、临时猜测和原始敏感数据都写入长期记忆。长期记忆应当更像经过确认的工程知识，而不是无限增长的聊天记录。
共享记忆需要权限和纠错机制
跨 Agent 共享信息会提升连续性，也会放大错误。一条错误记忆如果被多个 Agent 读取，可能影响代码、文档和运维操作。因此落地时至少要考虑以下问题：
- 范围：个人偏好、团队规范、项目决策和组织级知识应该分开管理。
- 来源：记录是谁、哪个 Agent 或哪个系统写入了这条记忆。
- 置信度：未经确认的推测不能与已批准的架构决策拥有同等权重。
- 时效性：依赖版本、部署环境和项目负责人都可能变化，记忆需要过期或复核机制。
- 可删除性：用户应该能够查看、修改和删除关于自己的记忆。
- 最小权限：一个只负责生成文档的 Agent，不一定需要读取全部生产环境信息。
可以把记忆检索看作一种数据访问，而不是隐藏在提示词里的魔法。每次注入 Agent 的内容都应该能回答三个问题：它从哪里来、为什么与当前任务相关、如果它是错的该如何修正。
采用建议：先从稳定事实开始
Memmy 这类共享记忆能力最适合从低风险、重复出现的信息开始接入，例如项目技术栈、代码风格、已确认的架构决策和测试约定。不要一开始就让 Agent 自动保存所有内容，更不要把生产凭据、个人隐私或未经验证的业务判断写入共享存储。
可以按下面的顺序推进：
- 选择一个项目作为试点，定义记忆范围和负责人。
- 只允许写入经过确认的稳定事实。
- 在 Agent 执行前检索少量高相关记忆，观察错误注入率和任务完成质量。
- 增加来源、置信度、更新时间和删除能力。
- 再把记忆能力扩展到更多 Agent、Skills 和 MCP 工作流。
Agent 的竞争力不只在于单次回答是否聪明，也在于它能否持续理解你的工作方式。Memmy 的意义，在于把这种连续性从某个 Agent 的私有上下文中抽离出来，让它成为可以被不同 AI 共同使用、审计和修正的长期能力。