方案已弃用

本文记录 NATS 作为 agent 间通信方案的架构决策历史（2026-07）。 该方案已弃用 —— 现行为：gbrain（${LOCALIP}:7842）共享知识 + Discord 唤醒人类侧 agent。 保留此文档是为了回答「为什么当初选 NATS、后来为何弃用」，不是当前运维依据。

GFW-Resilient Agent Communication

Problem

GFW can block Discord at any time. Proxy (mihomo) may be down or masked. Agents on LAN must communicate regardless of internet connectivity.

Architecture

Layer 1: NATS LAN (SOURCE OF TRUTH)

• Always works: LAN network (<1ms), no GFW, no proxy
• Persists: JetStream stream agent_messages (50K)
• Subjects: agent.dm.* / agent.broadcast / agent.rpc.*
• All agent-to-agent traffic uses ONLY this layer

Layer 2: Discord Webhook (NOTIFICATION)

• Best effort: Wakes human agent when internet works
• Fallback: If HTTP 403/timeout → save to local file
• Recovery: I check local pending files + JetStream on each turn

Fallback Flow

NATS message → try Discord webhook
  ├── success → notified, I process
  └── failed (GFW/down) → save to ~/.hermes/profiles/alaya/data/nats_pending/
                           ↓
                    nats_check.py picks it up on next response
                           ↓
                    watchdog cron (5min) catches any remaining

Key Rules

1. NEVER depend on Discord for agent-to-agent communication
2. NEVER put internet-reachable dependencies in the critical path
3. Auto-reply (ping/status) uses only NATS (zero internet)
4. Webhook is a convenience overlay, not a reliability mechanism

2026-10-09 Codex 审阅说明

局域网通信仍可能受服务、认证、路由或防火墙影响，不能保证“一直可用”。DNS 异常、403 或超时是排查线索，不能单独证明 GFW；403 也可来自服务器权限/WAF。NATS 与 gbrain 端口是当时快照，本次未主动探测或发消息。

核验依据：RFC 9110 HTTP 语义。