hmo
1b2b935832
- Platform-based architecture (Windows/Linux/Mac) - Agent instance registry (agents.yaml) - Management dashboard with cross-platform monitoring - xmpp_bot with HTTP bridge + health endpoints - wechat_agent with WeChat-Hermes bridging - Platform services: ProcessGuardian, HealthProbe, APIRouter, ChannelBridge - Deployment: systemd (Linux) + PowerShell (Windows) - Monitoring: SSH+ejabberdctl for cross-platform presence
114 lines
4.2 KiB
Markdown
114 lines
4.2 KiB
Markdown
# AgentsMeeting 稳定性审计报告
|
||
> 执行人: Sisyphus (xxm) | 日期: 2026-06-11 | 版本: v1
|
||
|
||
---
|
||
|
||
## 🔴 CRITICAL — 敏感信息泄露
|
||
|
||
### C1. hermes-agent 配置文件中 API Key 明文
|
||
**文件**: `hermes-agent/samples/config*/config.yaml`
|
||
**内容**: 所有 profile 的 `providers` 节包含以下真实 key：
|
||
- `ocg-new`: `sk-5miR8x...`
|
||
- `ocg-old`: `sk-MBLGxs...`
|
||
- `volcengine`: `b0359bed-...`
|
||
- `omlx`: `7debc5f...`
|
||
|
||
**风险**: 这些文件被复制到 AgentsMeeting 项目目录，如果不慎提交到 Git 或泄露，API key 全部暴露。
|
||
**修复**: 用环境变量 `${HERMES_OCG_KEY}` 等模板替代，真实的 key 从 Linux 服务器上的实际部署配置加载。
|
||
|
||
### C2. ViNote 项目 API Key 在 .env 文件
|
||
**文件**: `systems/ViNote/.env`
|
||
**内容**: `OPENAI_API_KEY=sk-56a8e42...` (DashScope key)
|
||
**风险**: .env 文件在 .gitignore 中但实际存在，且包含真实 key。
|
||
|
||
### C3. OpenCode config 中 MCP API Key 明文
|
||
**文件**: `~/.config/opencode/config.json`
|
||
**内容**: `MINIMAX_API_KEY=sk-cp-Mj6FH...` 直接写在 opencode 配置中
|
||
**风险**: 该文件虽在用户目录，但任何能读 `~/.config/opencode/` 的进程都能获取该 key。
|
||
|
||
---
|
||
|
||
## 🟠 HIGH — 稳定性风险
|
||
|
||
### H1. wechat_agent.py 无自动恢复机制
|
||
- wechat_agent 有看门狗 (每120s检查) 但无系统级自动重启
|
||
- 当前依赖 `start_agent.bat` 手动启动
|
||
- 建议: systemd 或 Windows Task Scheduler 加守护
|
||
|
||
### H2. XMPP Bot MUC 连接不稳定
|
||
- MUC join 频繁超时（60s × 3次），DNS 解析 `conference.yoin.fun` 偶尔失败
|
||
- Bot 依赖 MAM 订阅作为 fallback 收消息，但这不是正式通道
|
||
- 建议: 解决 DNS 或 ejabberd MUC 组件配置
|
||
|
||
### H3. wechat_agent 异常处理过于宽泛
|
||
- 28 个 `except Exception as e` 块，但没有区分可恢复/不可恢复错误
|
||
- 建议: 分类处理（网络重试 vs 致命错误报�?
|
||
|
||
### H4. api_proxy.py:8787 单点故障
|
||
- 代理用于绕过 opencode retry-cache，但如果挂了，chat_bridge 不经过代理直接调 API
|
||
- 代理无守护/自恢复
|
||
|
||
---
|
||
|
||
## 🟡 MEDIUM — 设计问题
|
||
|
||
### M1. Provider fallback 链可能有循环依赖
|
||
```
|
||
volcengine → ocg-old → ocg-new → volcengine (循环!)
|
||
```
|
||
如果三个 provider 同时出问题，fallback 会死循环。
|
||
|
||
### M2. 跨 bot agent 的 identity 可能漂移
|
||
- SOUL.md 文件内容不一致——有些 profile 有 `__SILENT__` 规则，有些没有
|
||
- 规则冲突时会优先执行 MEMORY 而非 SOUL（已知问题 R05）
|
||
|
||
### M3. 健康检查只检查 bot 进程，不检查 bot 是否真的能回应
|
||
- `health_check_xxm.py` 只检查日志活跃度，不模拟真实消息
|
||
- watchdog 只检查进程存活，不检查 LLM 是否能正常调�?
|
||
|
||
---
|
||
|
||
## 🟢 LOW — 代码规范
|
||
|
||
### L1. 工具调用循环超限后产出垃圾
|
||
- `_MAX_TOOL_LOOPS = 30`，超限后 final force 可能仍产出低质量回复
|
||
- 缺少写入文件专用工具（只能用 run_command 模拟）
|
||
- ✅ 已修复：final force 用干净上下文
|
||
|
||
### L2. 文件写入效率低
|
||
- LLM 用 `python -c` 覆盖写入文件，无法增量写入
|
||
- 缺少 append 模式指导
|
||
- ✅ 已修复：system prompt 加了文件写入指导
|
||
|
||
### L3. `config/` 和 `src/` 目录为空
|
||
- AgentsMeeting 的 `src/` 和 `config/` 完全空�?
|
||
- 代码散落在根目录和 hermes-agent 子目录
|
||
- 需要按项目结构整理
|
||
|
||
---
|
||
|
||
## 📊 进展统计
|
||
|
||
### 已修复
|
||
| # | 问题 | 状态 |
|
||
|---|------|------|
|
||
| 1 | `part_` 前缀 bug | ✅ 已修 |
|
||
| 2 | final force XML 泄露 | ✅ 已修 |
|
||
| 3 | shutup 模式太宽 | ✅ 已修 |
|
||
| 4 | self-message 检查顺序 | ✅ 已修 |
|
||
| 5 | ses_xxm_xmpp session 不存在 | ✅ 已修 |
|
||
| 6 | MAX_TOOL_LOOPS 不够 | ✅ 已修 |
|
||
| 7 | 旧数据 part_ 前缀 | ✅ 已修 |
|
||
| 8 | con/nul 文件 | ✅ 已修 |
|
||
| 9 | watchdog + 健康检查 | ✅ 已部署 |
|
||
|
||
### 待修复
|
||
| # | 问题 | 优先级 | 建议 |
|
||
|---|------|--------|------|
|
||
| C1-C3 | API Key 泄露 | 🔴 | 用 env var 替�?|
|
||
| H1 | wechat_agent 无自动恢复 | 🟠 | systemd/scheduled task |
|
||
| H2 | MUC 连接不稳定 | 🟠 | 查 ejabberd MUC 配置 |
|
||
| H3 | 异常处理过宽 | 🟠 | 分类 error type |
|
||
| M1 | Provider 循环依赖 | 🟡 | 设 max fallback depth |
|
||
| M3 | 健康检查不检测实际功能 | 🟡 | 加 bot 实际响应检测 |
|