团队记忆MCP
AI编码代理共享团队记忆。贝叶斯置信度评分与时间衰减。适用于 克劳德代码, 德文, 光标，以及任何兼容MCP的客户端。
问题
AI编码代理在会话中学习有价值的东西：
- *“弹簧靴：使用
@Transactional(readOnly = true)关于只读查询以避免不必要的写锁”* - *PostgreSQL：始终添加
CONCURRENTLY到CREATE INDEX在超过10万行的表上，以避免锁定生产”* - *“REST API：返回
409 Conflict（不是400)当资源已经存在时，API网关在400上重试* - *“Flyway:迁移文件必须遵循
V{ticket}_{seq}__{description}.sql或CI拒绝PR”*
但当课程结束时，这些知识就会消失。下一节课从零开始。
将其乘以一个由10名工程师组成的团队，每个工程师独立使用人工智能代理，你每周都会发现同样的错误。同样的错误 @Transactional 范围。相同的锁 CREATE INDEX同样的400对409混淆。
解决方案
Team Memory为AI代理提供了一个持久的共享知识库，其中存储了工程模式，由团队验证，并随着时间的推移按置信度进行排名。
- 工程师或人工智能代理存储他们在开发过程中发现的模式
- 每种模式都以~0.667的置信度开始
- 团队成员的确认会增强信心；更正会减少它
- 90天内未确认的模式逐渐失去信心（时间衰减）
- 搜索结果按置信度排序——首先出现经过充分验证的模式
这在实践中是什么样子的
"Spring Boot: use @Transactional(propagation = REQUIRES_NEW) for audit logging
to ensure logs persist even if the parent transaction rolls back"
→ Confirmed 23 times | Confidence: 0.92
"PostgreSQL: always add CONCURRENTLY to CREATE INDEX on tables with 100k+ rows"
→ Confirmed 15 times | Confidence: 0.88
"REST APIs: return 409 Conflict (not 400) when resource already exists on POST"
→ Confirmed 8 times, corrected 1 time | Confidence: 0.82
"JPA: avoid fetch = FetchType.EAGER on @ManyToOne — causes N+1 queries in lists"
→ Confirmed 31 times | Confidence: 0.94新团队成员从第一天起就获得了积累的知识。AI代理不再犯同样的错误。
如何比较
在构建之前，我们调查了10多个现有的MCP内存服务器。现有的解决方案没有将共享工程知识的所有四个属性结合起来：
| 能力 | 团队内存 | 服务器内存 | mem0 | mcp内存服务 | Memento | Memorix | Graphiti/Zep |
|---|---|---|---|---|---|---|---|
| 贝叶斯置信度 | 是 | -- | -- | --仅限手动 | -- | - | |
| 时间衰减 | 90d半衰期 | -- | -- | 巩固 | 30d半衰期 | -- | 无效 |
| 确认跟踪 | 按模式 | -- | -- | access_count | -- | -- | |
| 团队/共享记忆 | PostgreSQL | - | 云API | 基础SSE | - | 是 | 组（弱） |
| 零配置本地 | SQLite | JSONL | -- | SQLite | -- | JSON | -- |
| 编码模式模式 | 域/标签/作用域 | -- | -- | --- | -- | -- |
为什么不使用现有的解决方案？
@模型上下文协议/服务器内存 --Anthropic的官方参考实施。存储在平面JSONL文件中的知识图。没有信心得分，没有衰退，没有团队支持。故意最小化。
内存0 mcp --商业平台（YC支持，筹集2400万美元）针对会话内存进行了优化。通过user_id/agent_id进行团队范围界定，但置信度是基于LLM的重新排名，而不是透明的概率模型。无法查询“此模式被确认了多少次？”云依赖性和成本。
mcp存储器服务 --大多数功能丰富的OSS内存服务器（1500+星）。具有质量字段、访问计数和合并衰减。但质量评分是LLM评估的（不透明），团队记忆是基本的SSE事件传播，没有访问控制，每个记忆没有确认计数。
MCP纪念品 --Neo4j支持可配置的半衰期衰变关系。在数学上最接近我们的置信度模型，但置信度值是由LLM手动分配的，而不是根据证据计算的。仅限单个用户。需要Neo4j基础架构。
记忆库 --最佳团队协作原语（文件锁、任务板、跨IDE的消息传递）。但没有置信度评分，没有时间衰减，没有观察计数跟踪。
Graphiti/Zep --学术上严谨的双时态知识图（23k+颗星，已发表论文）。信心是二元的——事实要么有效，要么无效。没有分级信心，没有确认跟踪。需要Neo4j/FalkorDB。
差距
没有现有的解决方案跟踪： *“这种模式已被5名不同的工程师在12次会议上确认了47次。”*
这就是团队记忆所做的。置信度得分为：
- 透明 --你可以确切地看到为什么一个模式有一个给定的分数
- 基于证据的 --根据确认和更正计数计算
- 自动校正的 --未使用的模式会衰减，错误的模式会得到纠正
- 无LLM依赖 -纯数学，没有API评分要求
设置
快速启动（npx--无需安装）
npx team-memory-mcp使用克劳德代码注册
claude mcp add team-memory -- npx team-memory-mcp注册Devin
devin mcp add team-memory -- npx team-memory-mcp使用游标注册
添加到您的 .cursor/mcp.json:
{
"mcpServers": {
"team-memory": {
"command": "npx",
"args": ["team-memory-mcp"]
}
}
}从源代码安装（替代）
git clone https://github.com/gustavolira/team-memory-mcp.git
cd team-memory-mcp
npm install
npm run build
node build/index.js存储
本地模式（默认）
SQLite数据库位于 ~/.team-memory/memories.db。不需要外部服务。零配置。
共享模式（PostgreSQL）
设置 TEAM_MEMORY_DATABASE_URL 连接到集中式PostgreSQL实例的环境变量：
export TEAM_MEMORY_DATABASE_URL=postgresql://user:password@host:5432/team_memory设置后，团队中的所有代理和工程师共享相同的内存存储。服务器在第一次运行时自动创建所需的表和索引。
MCP工具
| 工具 | 说明 |
|---|---|
store_pattern | 使用域、标签和范围保存学习到的模式 |
search_patterns | 按关键字、域或标签搜索——按置信度排名 |
get_pattern | 按ID检索特定模式 |
confirm_pattern | 将模式标记为有效（+置信度） |
correct_pattern | 标记为不正确或提供替换（-置信） |
forget_pattern | 永久删除图案 |
信心评分
使用具有时间衰减的贝塔-伯努利贝叶斯模型：
confidence = (alpha / (alpha + beta)) × decay + floor × (1 - decay)
alpha = 1 + confirmations (starts at 2)
beta = 1 + corrections (starts at 1)
decay = 0.5 ^ (days_since_last_confirmation / 90)
floor = 0.05| 事件 | 信心 |
|---|---|
| 新模式 | 0.667 |
| +1确认 | 0.750 |
| +2确认 | 0.800 |
| +5次确认 | 0.875 |
| +1更正（无确认） | 0.500 |
| 90天未确认 | 减半 |
| 180天未确认 | 约为原件的25% |
界定范围
模式的范围可以包括：
- 项目 （默认）--绑定到当前git存储库（从中自动检测
git remote get-url origin) - 全球 --适用于所有项目
默认情况下，搜索时会返回项目范围和全局模式。
特性
- 自动检测贡献者 --阅读自
git config user.name - 缓存git检测 --每个会话解析一次项目ID和贡献者
- 优雅的错误处理 --数据库错误返回MCP错误响应，永不崩溃
- 双存储后端 --SQLite用于本地，PostgreSQL用于团队共享
- 零配置 --开箱即用，无需环境变量
使用示例
"Remember: Spring Boot @Transactional(readOnly = true) should be used on all read-only
service methods to avoid write locks and improve connection pool usage"
→ AI calls store_pattern with domain="spring-boot", tags=["transactional", "performance"]
"What patterns do we have for PostgreSQL?"
→ AI calls search_patterns with query="PostgreSQL"
"That pattern about CONCURRENTLY on CREATE INDEX is correct, saved us from a production lock"
→ AI calls confirm_pattern (confidence goes up)
"That pattern about 400 vs 409 is wrong for our new gateway — it no longer retries on 400"
→ AI calls correct_pattern with replacement text (confidence goes down, content updated)路线图
- \[\]通过嵌入进行语义搜索
- \[\]Claude Code的自动捕获挂钩
- \[\]任务开始时设计自动召回
- \[\]用于模式管理的Web仪表板
- \[\]矛盾模式的冲突解决
- \[x\] 发布于npm：
npx team-memory-mcp
构建于
- 模型上下文协议SDK --MCP服务器框架
- 更好平方3 --本地SQLite存储
- 页 --PostgreSQL共享模式客户端
- 萨德 --架构验证
许可证
麻省理工学院