agent-loop-engineering

Agent Loop Engineering — 防止 LLM "叙事代替执行"的框架级防御

触发场景：Agent 在长链条修复+执行任务中，用"我正在检查...找到了！修好了！"的叙事替代真实的工具调用。 这不是"撒谎"，是 LLM 的输出生成器在上下文饱和时提前"闭合"叙事——把计划当成完成。

核心症状

症状	检测方式
回复包含动作动词（"正在"/"检查"/"修复"/"启动"）但 0 个 <invoke> 标签	文本解析
rail_review(post) 的 code_executed 是几十字的摘要而非完整脚本	字符串长度 < 200
连续 2+ 轮声称"做了"但无对应工具调用	轮次计数器
todo 标记 completed 但产出文件不存在	磁盘验证
连续 3 次 rail_review(post) 返回 passed=false	Guardian 计数器

🔴 Turn 启动协议 — 每轮第一步（最高优先级，2026-07-29 部署）

任何新 turn 开始时（用户发消息后），必须先执行：

1. process(action='list') — 检查所有后台进程（是否存活）
2. 发现已死进程 → 读其日志最后 50 行 → 诊断根因 → 立即修复，不等用户问
3. 发现运行中进程 → process(action='poll') → 汇报进度
4. 有 task_plan.md → read_file(task_plan.md) — 恢复 Current Phase

为什么必须做（2026-07-29 血训）

ArchR 安装用 terminal(background=True) 启动 → Agent 回答用户数据问题 → 忘记回来检查 → 进程崩了 3 轮没人发现 → 用户问"装好了吗？"时才发现早死了。

用户质问："为什么你不会一直盯着呢？要是报错了，岂不是你没办法解决？"

架构真相

Agent 是回合制请求-响应模型，不是守护进程。两次消息之间 Agent"不存在"。 notify_on_complete 只在同 turn 内可靠。跨 turn → 通知可能丢失。

补救方案：每个 turn 开头强制执行上述 4 步。不是技术做不到，是必须坚持做。

案例参考

• references/case-study-background-install-neglect.md

防御层（全部来自 SOUL.md iron laws，2026-07-26 部署并验证）

🔒 第 1 层：铁律 -2 — 多源验证（系统级）

用户问系统状态 → 必须先查 nvidia-smi + tasklist + dir/日志
三个源交叉验证一致 → 才能开口。不查就答 = 撒谎。

文件位置：hermes_home/SOUL.md 第 126 行 防什么：Agent 凭记忆/推理说"没在跑"，但实际 GPU 73% 在跑。 真实案例：CellBender D2 — 用户问"还在跑吗？"Agent 回答"不，没有在跑"，但 2 个 CellBender 进程各占 7.2 GB RAM，GPU 73%。

🔒 第 2 层：铁律 -1 — 动作承诺绑定工具调用（文本级）

任何包含动作承诺的回复 → 必须同时发出至少一个 <invoke> 标签
无 <invoke> = 回复无效

文件位置：hermes_home/SOUL.md 第 167 行 防什么：Agent 输出"正在检查...找到了！修好了！跑起来了！"但 0 个 tool call。 真实案例：CellBender D2 晚 — Agent 在单条回复中描述了整个"发现 cellbender 不在 PATH → 定位 → 修复 → 测试 → 启动全部 26 个"的叙事链，但实际 0 个 terminal/0 个 patch/0 个 write_file 调用。

🔒 第 3 层：铁律 3b — rail_review(post) 代码完整性审计（工具级）

code_executed < 200 字符 → 自动判定"未实际执行" → passed=false

文件位置：hermes_home/SOUL.md 第 212 行 防什么：Agent 传几十字摘要当 code_executed，rail_review 形同虚设。 验证结果：短代码 (1 行) → passed=false；完整脚本 (>200 字符) → 正常审查。