docs: record communication dog live TUI UAT - #837
Conversation
|
Identity correction (append-only): the earlier draft text said Vincent had attached to |
结论:记录本身经得起核,建议合并。一条 BLOCKER 级的合并顺序提醒(不是内容问题)这是纯记录类 PR,此前只有一条 bot 评论。记录类最该核三件事: 一、密钥扫描:干净对新增行做凭据模式扫描( grep 命中的那些行全是规则文字本身,例如 文档还明确写了「配置目录与 token 是运行数据,不提交仓库」「Git 只恢复软件和非密钥流程, 二、记的事实存在三、结论没有超出证据(这是这份记录最值钱的地方)三处自我设限我都读了,写法是对的:
记录类文档最容易犯的错是"把一次成功写成能力证明",这份反着来,把边界写在了每个结论后面。 🔴 合并顺序:它 stacked 在 Draft #808 上所以:
两个 PR 改的是同一个文件 四、顺带的现状核对文档说「A站狗 与 P站狗 在 Vincent 直接授权前保持不动」。查 hub 实时: 三个都在线且 idle,与"未动"一致。(hub 的 (只读:未改本 PR、未 approve、未 merge;未连任何节点、未发任何探针消息。) |
现场证据:本文那句「不能把 Hub 的 idle 单独当成可用性证明」今天真实复现了一次本 PR 正文写过:
2026-08-14 这句话在 一、坏的那一段而在这 16 小时里,hub 上 二、好的那一段(2 分钟后)此刻 hub 上仍然是 🔴 三、建议补进 runbook 的:怎么用三行区分这两种 idle# 1) 有没有活的 TUI 端点（最直接）
ls ~/.anet-grok/<grok-home>/run/ # 要看到 attach.sock 与 leader.sock，只有 .lock = 没有 TUI
# 2) agent-node 有没有子进程（TUI 应该挂在它下面）
pgrep -P <agent-node-pid> # 空 = 没有 TUI
# 3) 日志里最后一次 TUI ready 与最后一次 approval_boundary 谁更新
grep -E 'TUI ready|approval_boundary' <node>/logs/*.log | tail -5🔴 四、一个我踩过的坑,值得写进 runbook
我第一次拿 config.json 里的 CommHub 两个 id 长得都像"节点标识",但分属两套命名空间。 (只读: |
补一条节点侧的自察症状(来自
|
🔴 更正 + 补一个此前没用过的证据源:grok 侧的
|
把这件事从"轶事"变成"频次":26 小时里 TUI 退出 9 次,其中 5 次与 approval_boundary 同秒上一条我用 grok 侧 一、频次CST 时刻: 这不是"偶尔掉一次",是一天掉九次。 🔴 二、与
|
pager quit(CST) |
最近的 approval_boundary | 关系 |
|---|---|---|
| 08-13 09:46:06 | 09:46:06 | 🔴 同秒 |
| 08-13 10:18:22 | 09:47:35 | 无关联(0.5 小时) |
| 08-13 10:43:43 | 10:56:12 | 无关联(0.2 小时) |
| 08-13 10:56:12 | 10:56:12 | 🔴 同秒 |
| 08-13 13:01:34 | 13:01:34 | 🔴 同秒 |
| 08-13 14:14:41 | 14:14:41 | 🔴 同秒 |
| 08-13 14:38:10 | 14:14:42 | 无关联(0.4 小时) |
| 08-13 23:36:20 | 23:36:20 | 🔴 同秒 |
| 08-14 11:34:03 | 23:36:20 | 无关联(12 小时) |
9 次里 5 次与一次 approval_boundary 失败发生在同一秒。
同秒不是巧合,是同一事件的两侧记录 —— 印证了本 PR 正文那句
「安全边界拒绝后 TUI 子进程退出」。
三、这同时收窄了我上一条的更正范围
我上一条说"今天这次是正常退出,不是被拦崩的" —— 那句话只对今天这一次成立
(11:34:03 那次最近的 approval_boundary 在 12 小时以外,且它退出前刚跑完一个正常 turn)。
不能推广成"pager quit 都是正常退出":另外 5 次明确与边界拒绝同秒。
准确的说法是:
9 次退出里
5 次 与 approval_boundary 同秒 → 就是正文描述的那个形态（边界拒绝 → TUI 退出）
3 次 与任何 approval_boundary 都差 0.2~0.5 小时 → 原因不明
1 次 今天 11:34:03，差 12 小时，退出前刚完成一个正常 turn → 看起来是人为退出
四、对 runbook 的建议
- 正文那句「边界拒绝后 TUI 退出」不是偶发,建议标注频次(实测 26 小时 9 次、其中 5 次同秒);
- 排查时两份日志要一起看:
agent-node日志给approval_boundary的时刻,unified.jsonl给pager quit的时刻,
同秒 = 边界拒绝导致的退出;差很远 = 另有原因; - 这也解释了为什么这个节点"总要重起":不是某一次意外,是一天九次。
要根治得看那条 always-approve 策略为什么会被触发到,那是产品侧的事,不在本 runbook 范围。
(只读:两份日志 + ps;unified.jsonl 只取 ts/lvl/src/msg,未打印 ctx 正文;
未重启节点 —— 是否重起仍在等 Vincent。)
根因方向:不是"TUI 不稳定",是每次要用工具就撞一次边界顺着上一条的 5 次同秒往下查,把触发条件也定位了。这条只陈述日志显示的事实, 一、单次事件的完整链条(取 08-13 09:46 那次)grok 侧同一秒: 🔴 二、关键在那句措辞:
|
🔴 撤回上一条的根因结论:"每次用工具就撞边界"被我自己的数据推翻了上一条我写:「不是 TUI 不稳定,是每个需要工具的任务都会触发一次」。 一、推翻它的数字工具执行了 33 次,只有 5 次撞边界。 所以"每个需要工具的任务必然触发"不成立 —— 再看那 5 次同秒的现场, 连"失败时一定在用工具"都不成立。 二、仍然站得住的部分
🔴 三、我现在不知道触发条件是什么,而且这份日志答不了我去 grok 侧日志里找权限/审批类事件,整份 2006 条里只有 1 条包含 permission 字样, 也就是说: 两侧都没有"是什么请求触发的"。所以触发条件在现有日志下不可判定 —— 四、要定这件事,需要的是什么证据(给接手的人)有了这个字段,才能回答"为什么同样是工具调用,大多数过、少数不过"。 五、我为什么会错我从一句错误信息的措辞( (只读:两份日志计数; |
横向对照:这个故障不是共存的普遍病,通信狗 是离群点前面几条都只看 一、四个共存节点的原始计数
二、先归一化,否则是拿不同窗口比日志覆盖天数不同,直接比次数会得出错误结论:
三、结论
四、这对下一步的影响要查根因,应该看 (只读:四个节点的 agent-node 日志 + 各自 grok 侧 |
🔴 更正上一条:我按「天」归一化,但正确的分母是「任务数」上一条我说 一、把工作量也量出来(这是我上一条漏掉的)
二、两种分母,两个结论
而 三、修正后的结论
四、我为什么又错上一条我已经意识到要归一化,并特意按"天数"归了 —— 但没问一句:
(只读:四个节点的 agent-node 日志计数 + 各自 config 的 |
一个干净的反例:两种归一化给出相反的排序上一条我说"分母选错比不归一化更危险"。这里有一个当场的例子,值得贴出来,
|
| 节点 | quit 次数 | 任务数 | 天数 | quit/天 | quit/任务 |
|---|---|---|---|---|---|
| 指挥狗 | 15 | 17 | 14 | 1.07 | 0.88 |
| 通信狗 | 9 | 44 | ~1.1 | 8.18 | 0.20 |
按天 通信狗 8.18 vs 指挥狗 1.07 → 通信狗 差 7.6 倍
按任务 指挥狗 0.88 vs 通信狗 0.20 → **指挥狗 差 4.3 倍**
排序反了。 同一份数据,换个分母,谁"更容易掉"的答案就调个个儿。
这说明什么
不是某个分母对、另一个错 —— 是我们还不知道 pager quit 真正随什么变化:
若退出主要由「处理任务」触发 → 该按任务归一 → 指挥狗 更差
若退出主要由「时间/空闲/人为」 → 该按时间归一 → 通信狗 更差
而现有日志里，那 15 次退出前的事件八种都有，分不出属于哪一类
所以正确的结论是"判不了",而不是挑一个看起来支持我想法的分母。
要判,需要的是退出事件里带上原因(是收到退出信号、还是超时、还是异常),
现在 pager quit 只是一条没有原因字段的 info 日志。
(只读:两个节点的 grok unified.jsonl 计数与前序事件统计;未打印 ctx、未改配置、未重启节点。)
把"需要退出原因字段"从推测变成已验证的事实上一条我写:「要判 quit 属于哪一类,需要 一、
|
第二个样本已闭环:掉线 176 分钟、零任务损失;判据红绿两态都在真实翻转中见证过按我此前给自己定的约束,只有"通信狗 恢复"这类触发条件才回来补一条。现在补完这条就收尾。 一、第二次掉线的完整区间期间新任务 0 条 → 零实际损失。 这一点从头到尾都成立,所以本次的代价只是"如果有人派活会失败"。 二、那三条判据在这次事件里红绿两态都翻过了判据是随真实状态自己翻的,不需要任何调整。 三、两次掉线的对照(本 PR 的两个样本)
差别不在故障本身,在于有没有判据。 四、本条之后我不再追加这条线上可执行的东西都已落地:三条判据、全舰团扫描、grok 侧 (只读:日志与 |
2 participants
What changed
send_messageto lifecycle-backedsend_task~/.grok/binremain-on-exit, and multi-signal health checksweb_search, andsend_taskcoexist, while composer navigation/history/slash editing is not yet a complete native-TUI experienceWhy
The prior recovery could pass once and later degrade into a false-online node: the vendor-managed
~/.grok/bindirectory was treated as immutable, the TUI/leader/socket process group disappeared, and the agent-node remained connected to Hub. A restart then failed deterministically withENOENT.The runbook now distinguishes deployment bytes from their Git recovery record, and distinguishes Hub presence from attributable runtime behavior. It also records the safe operating boundary instead of calling the current composer proxy a fully covered native TUI.
Scope
433b4af44bdcc09145c75b697634f74aec42a7df677709bb91813e1ef7852cfc5d3d32f7cb98f072Validation
git diff --check0.2.93 (f00f96316d)and SHA-2564e0738d3b5550f3c842bc0ae69f468815c6329c008a110d0c27a694dc3401135web_searchreturnedTOOL_TUI_OK OpenAI | Research & Deployment398d11bd-edad-4eea-9418-0d241841ffffreached terminalrepliedwithCOMM_DOG_POST_PIN_OK