Mirix 个人记忆助手
将屏幕活动与对话沉淀为可检索的个人记忆。
按维度查看评分与理由
证据显示：README声称隐私优先，数据本地存储，但未提供实现细节；存在API密钥管理（conftest.py），但未说明权限最小化；有外部依赖（composio, aiogoogle等）可能产生外部效果，但未明确用户确认机制；依赖众多且未提供安全审计；无回滚机制；来源归属部分明确（致谢Letta）。扣分原因：缺乏用户确认、数据流透明性不足、依赖安全未评估、无回滚。
证据显示：存在测试文件（test_agent_prompt_update.py等），但测试依赖外部API密钥和手动启动服务器，未提供确定性；依赖众多且版本范围宽，可能不稳定；错误处理测试存在（test_error_handling_nonexistent_agent），但整体失败消息质量未全面评估。扣分原因：测试依赖外部服务，依赖可用性未验证，失败消息覆盖有限。
证据显示：README描述了多种使用场景（屏幕跟踪、多模态输入），但未明确目标受众；能力边界未清晰定义；触发机制（如auto-dream）有文档，但精度未验证；环境适配（Docker、Python版本）有说明，但未覆盖所有平台。扣分原因：能力边界模糊，触发精度未验证，环境适配有限。
证据显示：README结构清晰，提供快速开始和示例；安装说明（Docker、pip）存在；命名（MIRIX）稳定；有示例代码；但无已知限制说明，无版本变更日志，维护责任未明确（仅提供联系邮箱）。扣分原因：缺少已知限制、版本变更日志，维护责任不明确。
证据显示：输出可用性（API返回记忆）有示例，但未验证实际效果；边际价值（多智能体记忆系统）有描述，但未与其他方案对比；成本效益未讨论。扣分原因：输出可用性未验证，成本效益未分析。
证据显示：README中的声明（如隐私优先）未提供实现证据；测试文件存在但依赖外部服务，无法独立验证；事实与推断未明确区分。扣分原因：声明缺乏可追溯性，交叉验证不足，事实与推断混淆。
- 依赖众多且未提供安全审计，存在供应链风险。
- 测试依赖外部API密钥和手动启动服务器，无法自动验证。
- 隐私声明缺乏实现细节，需谨慎评估数据安全。
- 无版本变更日志，维护责任不明确。
这个 Agent 能做什么，适合哪些场景？
Mirix 是一个多智能体个人助理，重点在于通过屏幕观察和自然对话建立长期记忆。它将记忆划分为 Core、Episodic、Semantic、Procedural、Resource 和 Knowledge Vault 六类组件，并由对应的记忆代理管理。系统可处理文本、图片、语音和屏幕截图，并以 PostgreSQL 原生 BM25 全文检索与向量相似度支持检索。后端和仪表盘通过 Docker Compose 启动，仪表盘默认位于 5173 端口，API 默认位于 8531 端口；Python 客户端通过 MirixClient 调用服务。其数据边界是长期数据本地存储并提供用户可控隐私设置，但屏幕捕获的具体权限流程、支持的平台和资源开销未在现有材料中说明。
先运行 docker compose up -d --pull always 启动后端与 Dashboard，并在 Dashboard 创建 MIRIX_API_KEY。Python 程序通过 MirixClient 连接 http://localhost:8531，再以 initialize_meta_agent 配置模型、嵌入模型及六类记忆代理。调用 client.add 时，系统接收按 user_id 归属的 user 与 assistant 消息内容；调用 client.retrieve_with_conversation 时，系统结合当前对话返回相关记忆，示例中以 limit=5 限制结果数量。系统还提供 POST /memory/auto_dream?user_id=demo-user 和 client.auto_dream，用于审查指定记忆组件、合并重复内容、尽可能处理过期或冲突条目并写回；dry_run=true 可先查看待处理数量而不更新数据。
- 希望回顾近期屏幕工作与对话内容的个人用户，可按用户身份检索过去数日讨论过的主题。
- 需要把聊天记录、图片、语音和屏幕截图集中为个人知识记忆的研究人员或知识工作者，可通过同一服务写入这些输入。
- 正在构建带长期记忆能力的个人助理的 Python 开发者，可用 MirixClient 初始化记忆代理并在应用中调用 add 与 retrieve_with_conversation。
- 积累了重复或相互矛盾记忆的本地部署管理员，可先以 dry_run 检查，再用 auto_dream 的 experience 模式整理 Episodic、Semantic 和 Knowledge Vault 记忆。
- 重视长期数据本地存放和隐私设置控制的团队，可将 Mirix 作为自托管记忆服务部署在其 Docker 环境中。
这个 Agent 有哪些优点和局限？
- 以六类明确的记忆组件组织信息，而非只把全部历史作为单一上下文保存。
- 同时覆盖文本、图片、语音和屏幕截图，并将屏幕活动作为记忆输入来源。
- 提供 PostgreSQL 原生 BM25 全文搜索和向量相似度两种检索机制。
- auto_dream 可对指定记忆类别执行重复合并与陈旧或冲突条目整理，并支持 dry run 预检。
- 长期数据声明为本地存储，且有用户可控的隐私设置。
- 已给出的模型与嵌入配置示例依赖 Google AI、Gemini 2.0 Flash 和 text-embedding-004；其他提供商的可用配置未获说明。
- 部署至少涉及 Docker Compose、Python 客户端、API 密钥和 PostgreSQL 搜索能力，采用门槛高于纯托管聊天工具。
- 屏幕持续捕获的操作系统支持范围、授权方式、数据保留规则和性能影响未在材料中说明。
- 虽声明可处理图片、语音和屏幕截图，但输入采集方式、格式限制及失败处理细节未提供。
- 自动整理会写回记忆；虽然 dry_run 可预览，材料未说明撤销或版本恢复机制。
如何安装或部署这个 Agent？
前置条件：需要 Docker Compose 来启动后端与 Dashboard，并需要 Python 环境使用客户端。在部署目录执行：
docker compose up -d --pull always打开 http://localhost:5173，在 Dashboard 创建 API 密钥，并将其设为 MIRIX_API_KEY。随后安装客户端：
pip install mirix-client服务 API 默认地址为 http://localhost:8531。
如何使用这个 Agent？
创建 MirixClient(api_key="your-api-key", base_url="http://localhost:8531")。调用 initialize_meta_agent，并提供 llm_config、embedding_config 与 meta_agent_config；给出的配置示例使用 Gemini 2.0 Flash、Google AI 端点和 text-embedding-004。随后用 client.add(user_id=..., messages=[...]) 写入对话，再用 client.retrieve_with_conversation(user_id=..., messages=[...], limit=5) 获取相关记忆。若需整理记忆，可调用 client.auto_dream(user_id="demo-user", mode="experience", dry_run=False)；先设 dry_run=True 可预览处理数量。
这个 Agent 与同类方案有什么区别？
README 将 Letta 列为该项目记忆系统的基础框架来源，但未提供两者的功能对照或性能基准。