Files

T

hmo 1b2b935832 Initial: multi-agent XMPP communication system with dashboard

- 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

2026-06-12 21:51:36 +08:00

4.2 KiB

Raw Blame History

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 实际响应检测

4.2 KiB Raw Blame History Unescape Escape