-
旧路径：/v1/chat/completions 同步阻塞拿完整 reply → 一条微信消息。 长 agent loop 用户体验差（"稍等" 之后再无下文）。 新路径： 1) POST /v1/runs { input, conversation_history, session_id, instructions } 拿 run_id 立即返回 2) GET /v1/runs/{run_id}/events SSE 长连接，消费事件： - message.delta { delta } → 累积到 textBuf - tool.started → flush(false): textBuf → onUtterance - run.completed { output } → flush(true): 最后一段 - run.failed/cancelled → reject 3) onUtterance 在串行 Promise 队列（sendChain）里跑： - idx===0 的 utterance 带 quoteText + atSender（群里 @ 原消息） - 后续 idx>0 仅文本，不重复 quote/@ - 发完后 await sleep(14000 或 9000) 等 A11y 跑完整一轮 chat-list-click → quote → @ → type → send，避免下一个 broadcast 打断当前 FSM 状态 handleMessage： - 移除旧的 this.replyGenerator + sendTextMessageBroadcast 同步路径 - 改成 callHermesRunStream(messages, sessionId, onUtterance) - state.markReplied 在 run 整体完成后才标记（避免中间步骤已发但失败时重发漏掉） 诊断：增加 [STREAM EV] 日志统计事件类型 + textBuf 长度， 方便诊断"agent loop 跑很久但没 utterance"等情况（实测发现 深度探索时 hermes 几乎只调 tool 不发 text，多步分割效果依赖 LLM 行为）。 keepalive.sh: HERMES_TIMEOUT 180s → 600s，长 agentic run 经常 3-5min。 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> -
#1 HERMES_TIMEOUT 120s → 180s Moonshot kimi-k2.6 在 turns=9 长 context 下 LLM call 可达 60s+， 旧的 2 分钟整体超时偶发不够，导致私聊 / 群聊回复直接 socket hang up。 keepalive.sh 内联 HERMES_TIMEOUT=180000 启动 node。 #2 keepalive 直起 node，绕过 start-ar.sh phone 上某个 claude-run/hermes 会话有 shell snapshot hook，每次 start-ar.sh 通过 dash 启动时触发它写 /data/local/tmp/hermes-snap-*.sh， Permission denied 错误被某种机制注入到 hermes-wechat/*.js 末尾， 下一次 node 加载就 SyntaxError 起不来。 修法：keepalive 用 `su -c 'cd X && env... nohup node auto-reply.js & echo $!'` 直接起 node，不经 dash 包装层。 #3 is_auto_reply_running 的两个 bug - 第一版 pgrep -f node.*auto-reply.js: regex 在 su shell cmdline 里 自匹配（'su -c "..."' 包含 pattern），永远返 true，永远不重启 - 第二版用 PID 文件 + grep /proc/PID/comm: 但 echo $! 写的是 sh wrapper PID（comm=sh），不是 node 子进程 PID，永远返 false → 暴 spawn - 终版：ps -ef + grep -E node.auto-reply.js + grep -v sh.-c 精确匹配 "node auto-reply.js" 实进程（含空格），排除 sh wrapper line。 pattern 里用 . 占位避开嵌套引号问题（双引号外/单引号内/转义都崩） 实测：keepalive 起 1 次后稳定 45s+，loop tick 不再误重启； auto-reply.js 单实例（不再 4 个并行）。 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> -
#17 群昵称查询： - android-wechat-tracker-sqlcipher.js:getContactNickname 删掉 if (wxid.endsWith('@chatroom')) return wxid 的早退分支 - 群（xxxx@chatroom）和私聊都走同一 rcontact 表查询，nickname 就是群名 - A11y 现在可以用群名搜索进入群聊 - 在 Pixel 已部署并重启 auto-reply (PID 18678) #18 wake-lock + keepalive 重写： - 通过 am startservice com.termux.service_wake_lock 启用 wake-lock （确认 dumpsys power 已持有 'termux:service-wakelock'） - 重写 keepalive.sh 对齐当前部署： - 守护 4 项：wake-lock / A11y service / hermes gateway / auto-reply - hermes 走 termux native gateway 而不是 proot-distro Ubuntu（已淘汰） - 健康检查端口 8642（不再是 3010） - A11y 被关掉时自动 settings put secure 重新启用 - 在 Pixel 已部署到 ~/hermes-wechat/keepalive.sh #16 残留清理（仅 phone 操作，无 git 文件）： - pkill -9 frida-server + rm -rf ~/.frida_queue/ - ~/.hermes/auth.json 删掉 credential_pool['kimi-coding'] 老 sk-kimi 条目 保留 anthropic + kimi-coding-cn Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> -
通过 DB 实证与 LSPosed 日志对比定位到： - LSPosed `HermesWeChatModule.sendTextMessageDirect` 在 WeChat 8.0.72 上 返回 `Send result: true` 后，主线程异步 NetScene 提交触发 NPE 被 swallow， 消息**不进 message 表**。这是误报。 - Frida daemon 队列方案（`android-wechat-sender-frida.js`）在 Frida 17 + 微信 8.0.72 上注入会触发反调试，进程崩溃，无法生产使用。 - 实际可用路径是 `HermesAccessibilityService`（lsposed-wechat-sendmsg 模块内）： 监听同一广播 `com.hermes.wechat.SEND_MSG`，纯 UI 自动化点击微信完成发送。 - A11y service 易被系统关闭（`enabled_accessibility_services = null`）， 这是消息发送失败的最常见根因，docs 中加上启用 / 验证命令。 更新范围： - CLAUDE.md - server/services/wechat/README.md, SKILL.md - server/services/wechat/android-wechat-sender-frida.js（标注废弃） - wechat_plain/scripts/local-testkit/docs/README.md, HERMES_WECHAT_ARCHITECTURE.md - wechat_plain/scripts/lsposed-wechat-sendmsg/README.md Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
-
- HERMES_WECHAT_ARCHITECTURE.md: v2.0 → v3.0, rewrite for Node.js plugin - README.md: update architecture diagram, file list, API endpoint, env vars - server/services/wechat/README.md: add sqlcipher tracker + frida sender - SKILL.md: add Frida daemon and SQLCipher tracker usage - wechat-auto-reply-status.md: mark SQLCipher + Frida as verified, update plans Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
-
- auto-reply.js 接入 hermes-agent OpenAI-compatible API (:8642) - 新增 android-wechat-tracker-sqlcipher.js 替代 LSPosed 日志 tail - 新增 android-wechat-sender-frida.js 替代 am broadcast 发送 - 更新 keepalive.sh、README、HermesWeChatModule.java - 添加 .gitignore SQLite 变体规则 - 新增 docs: 息屏发送尝试记录与屏幕自动唤醒方案 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
-
- auto-reply.js: connect to hermes /api/master/chat for AI reply generation - SSE response parsing, session isolation per talker - notification watcher (termux-notification-list) for screen-off fallback - wechat foreground check + wake before send - hermes_wechat_daemon.py: prefer hermes API, fallback to direct LLM API - config.json: add hermes host/port for local API connection - keepalive.sh: termux-wake-lock + process guardian for hermes + auto-reply - Move docs into local-testkit/docs/ directory - .gitignore: exclude server/db/ Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
-
Mac side (lemonPCRM): - Express server with /api/master/chat SSE endpoint - MasterSession multi-round orchestration - AgentManager + ToolRegistry - ClaudeCliProtocol ACP implementation Pixel side (wechat_plain/scripts/): - hermes_wechat_daemon.py: standalone daemon - SQLCipher DB decryption with WAL checkpoint fix - Direct LLM API calls (Kimi/Anthropic/OpenAI) - am broadcast to trigger LSPosed send - Auto wake WeChat to foreground before poll/send - lsposed-wechat-sendmsg: LSPosed module - sendTextMessageDirect via WeChat internal API - u01.r1.a -> builder -> m1.a() full chain - Background thread NetScene submission Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>