# AgentsMeeting — 产品需求文档 (PRD)

> 版本: v0.2 | 精简: 2026-07-16 | 客户: hmo (老莫)

---

## 一、项目背景

老莫运营一套多 Agent 协作系统，涵盖 XMPP 消息通道、AI Gateway、会话管理、记忆系统、Provider 调用链、Web Dashboard 等模块。

**立项目标**：将现有系统按软件工程规范进行文档化、模块化整理，查漏补缺，不推倒重来。最终产出标准化的源码包、部署脚本和运维文档，可稳定部署到服务器并支持客户端对接。

---

## 二、系统概览

| 层 | 组件 | 说明 |
|----|------|------|
| **消息通道** | XMPP (ejabberd + bot)、微信 (wechat_agent)、QQ (规划中) | 多渠道统一接入 |
| **Gateway** | Hermes API Server (:8642~8646)，各 profile 独立 | 消息路由、会话、Provider 调用 |
| **会话管理** | SQLite state.db，硬截断 200 条 | 各 profile 独立文件 |
| **记忆系统** | SOUL.md + MEMORY.md + USER.md | 系统提示 + 长期记忆 + 用户画像 |
| **Provider** | volcengine / ocg / omlx，多 key 轮询/fallback | 多供应商 LLM 调用 |
| **辅助系统** | cron 调度 (14 jobs)、MoFin 股票、MCP 服务、Skills 系统 | 扩展功能 |
| **基础设施** | Linux 246 (主阵地)、Windows 16 (桥接)、阿里云中转 | |
| **管理门户** | Dashboard (:5803) | 监控 + 测试 + 规范 + 健康 |

---

## 三、总体性需求（双轨体系未覆盖部分）

以下需求不适合放入模块级 `specs/*.json`，属于跨模块/架构层级的约束：

### 3.1 架构约束

1. **一条消息只经过一个 Session** — 通道级隔离，不跨 profile 共享上下文
2. **数据流路径可追溯** — 消息来源 → Gateway → Session → LLM → 回复 → 目标通道，每一步可日志追踪
3. **SOUL.md 是行为最高准则** — MEMORY 不应包含与 SOUL 冲突的规则
4. **配置即代码** — 所有配置纳入版本管理，禁止手动改线上文件
5. **不推倒重来** — 以现有代码为基础，只做文档化和查漏补缺

### 3.2 可用性要求

1. **所有进程必须支持健康检查 + 自动重启** — systemd / 看门狗守护
2. **Gateway 异常退出后 30s 内自动拉起** — 系统级恢复，不依赖人工
3. **XMPP bot 断线自动重连** — 应用层心跳 + systemd 兜底重启
4. **微信通道崩了不影响其他通道** — 通道级故障隔离

### 3.3 安全约束

1. **敏感信息不得入 git** — API Key、Cookie、密码仅存环境变量或 `.gitignore` 文件
2. **Dashboard 管理接口需鉴权** — 涉部署操作（启停服务）须 Bearer token
3. **记忆系统不持久化敏感对话** — LLM 产出的敏感内容不应写入长期记忆

### 3.4 性能基准

1. **消息端到端延迟 < 30s**（含 LLM 推理）— 超过 60s 视为异常
2. **Session 上下文上限 200 条 / 12k tokens** — 硬截断防膨胀
3. **Dashboard 页面加载 < 3s** — 所有 API 聚合到 `/api/health-overview`

---

## 四、需求分布说明

绝大多数具体需求（功能细节、API 定义、UI 交互、模块边界）**不在本文档描述**，而是通过双轨同源体系记录：

```
每个功能模块 → specs/{module}.json
  ├── human_help（? 按钮 → 人类看说明/排错）
  └── ai_spec（§ 按钮 → AI 看接口/约束/测试）
```

当前已用双轨覆盖的模块：`usage_monitor`、`easytier`、`rdp`。
新增模块必须走此流程。

---

*PRD v0.2 — 精简版，仅保留双轨体系覆盖不到的架构级需求*