使用说明
问题陈述
我目前使用WhatsApp、Signal和Telegram与人们保持联系。如果有以下内容就好了-
- 查看消息的统一UI
- 能够回复消息
- 一个人工智能代理来安排通话（缩放会议、谷歌会议等）
- 能够添加
messenger app到统一的UI
- WhatsApp（用于原型）
- 信号
- 电报
存储-
默认情况下，消息的存储时间最长为30天，用户管理员可以更新天数。
我们不使用Postgres，而是使用Redis缓存（与RediSearch一起），只将消息存储在内存中，而不存储到磁盘。
我们仍然可以使用RediSearch对数据执行高级搜索查询。
数据生命周期：
- 保留期后自动删除（默认30天）
- 服务器重启时丢失（无持久性）
- 用户可以拨打
clear_my_data立即删除他们的所有消息 - 服务之间传输中加密的数据（TLS）
身份验证和授权：
- 用户身份验证：OAuth2代理（谷歌/GitHub登录）
- 代理身份验证：每个用户的作用域API密钥（存储在Kubernetes Secret中）
- 服务到服务：Kubernetes ServiceAccount令牌
MCP工具限制：
- 代理人有 只读 访问消息
search_messages--仅限于经过身份验证的用户数据get_conversation--仅限于经过身份验证的用户数据- 代理没有写入/删除权限
AI代理：
- 通过Ollama获得当地法学硕士学位(
llama3或mistral) - 运行于
http://localhost:11434 - 连接到MCP服务器以进行只读消息访问
- 根据消息上下文处理调度请求
Redis数据模型
Redis是一个键值存储。每条消息都以UUID作为密钥存储为哈希。
密钥格式： message:{uuid}
值（哈希字段）：
| 字段 | 描述 |
|---|---|
user_id |
消息的所有者（用于将查询范围限定到经过身份验证的用户） |
conversation_id |
将消息分组到对话中（用于 get_conversation 工具） |
sender_id |
谁发的信息 |
sender_name |
UI的显示名称 |
platform |
whatsapp, signal，或 telegram |
direction |
inbound 或 outbound |
message |
实际消息内容 |
timestamp |
当消息插入缓存时 |
message_id |
来自信使平台的原始消息ID（如果可用） |
hash |
插入对象的哈希值（用于重复数据删除） |
TTL： 默认情况下，每个密钥的TTL为30天（2592000秒），由Redis自动删除。
RediSearch索引
RediSearch是一个在Redis数据之上添加二次索引和全文搜索的模块。
指标定义：
FT.CREATE idx:messages ON HASH PREFIX 1 message:
SCHEMA
user_id TAG
conversation_id TAG
sender_id TAG
platform TAG
direction TAG
message TEXT
timestamp NUMERIC SORTABLE
查询示例：
- 搜索用户的消息：
FT.SEARCH idx:messages "@user_id:{user123} @message:zoom" SORTBY timestamp DESC - 获取对话：
FT.SEARCH idx:messages "@user_id:{user123} @conversation_id:{conv456}" SORTBY timestamp ASC
