3.5 KiB
3.5 KiB
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 架构约束
- 一条消息只经过一个 Session — 通道级隔离，不跨 profile 共享上下文
- 数据流路径可追溯 — 消息来源 → Gateway → Session → LLM → 回复 → 目标通道，每一步可日志追踪
- SOUL.md 是行为最高准则 — MEMORY 不应包含与 SOUL 冲突的规则
- 配置即代码 — 所有配置纳入版本管理，禁止手动改线上文件
- 不推倒重来 — 以现有代码为基础，只做文档化和查漏补缺
3.2 可用性要求
- 所有进程必须支持健康检查 + 自动重启 — systemd / 看门狗守护
- Gateway 异常退出后 30s 内自动拉起 — 系统级恢复，不依赖人工
- XMPP bot 断线自动重连 — 应用层心跳 + systemd 兜底重启
- 微信通道崩了不影响其他通道 — 通道级故障隔离
3.3 安全约束
- 敏感信息不得入 git — API Key、Cookie、密码仅存环境变量或
.gitignore文件 - Dashboard 管理接口需鉴权 — 涉部署操作（启停服务）须 Bearer token
- 记忆系统不持久化敏感对话 — LLM 产出的敏感内容不应写入长期记忆
3.4 性能基准
- 消息端到端延迟 < 30s（含 LLM 推理）— 超过 60s 视为异常
- Session 上下文上限 200 条 / 12k tokens — 硬截断防膨胀
- Dashboard 页面加载 < 3s — 所有 API 聚合到
/api/health-overview
四、需求分布说明
绝大多数具体需求（功能细节、API 定义、UI 交互、模块边界）不在本文档描述，而是通过双轨同源体系记录：
每个功能模块 → specs/{module}.json
├── human_help（? 按钮 → 人类看说明/排错）
└── ai_spec（§ 按钮 → AI 看接口/约束/测试）
当前已用双轨覆盖的模块：usage_monitor、easytier、rdp。
新增模块必须走此流程。
PRD v0.2 — 精简版，仅保留双轨体系覆盖不到的架构级需求