AI Agent 跑了一个月，我统计出 4 种最常见的静默失败——第 3 种让任务成功率腰斩

如果你的 AI Agent 已经在后台跑了一个月，而你以为一切正常——先别急着庆祝。我跑了 30 天自动化任务后发现，有 47% 的失败是"静默"的：Agent 不会报错、日志看起来正常，但任务根本没完成。这篇文章复盘了我遇到的全部 4 种静默失败模式，以及对应的自愈方案。

---

背景：230 个任务，30 天

我用 Hermes Agent 的 cron 子系统部署了一批日常自动化任务：每日数据采集、定时发文、监控告警、文件整理。30 天里跑了大约 230 个任务。前两周我天真地以为一切顺利——直到某天翻日志才发现，CSDN 夜报已经连续 4 天空白，而 cron 日志里一条报错都没有。

逐一排查后，我找到了 4 种根本原因。它们的共同特征是：工具调用返回了 exit_code=0，但业务结果为空。

---

静默失败 #1：工具输出被截断，Agent 以为拿到了完整结果

现象： 某天股票数据采集任务跑了 3 分钟，exit_code=0，但输出的 JSON 只有一半——最后一行是 "data": [ 就结束了。

根因： 终端工具默认 stdout 上限是 50KB。API 返回了 87KB 的数据，被硬截断在中间。Agent 拿到的是一段语法上不完整但工具层面"成功"的输出，它基于截断内容生成了空报表，然后标记"任务完成"。

为什么是静默的： exit_code=0，Agent 照常输出了报告。但报告里所有数值字段都是 0，因为 JSON 解析到一半就断了。

修复方案：

# 在 subprocess 调用层加完整性校验
import json
result = subprocess.run(cmd, capture_output=True, text=True, timeout=60)

# 关键检查：stdout 是否被截断
if len(result.stdout) >= 50000:  # 接近上限
    raise RuntimeError(f"Output truncated at {len(result.stdout)} bytes")

# JSON 数据完整性校验
try:
    data = json.loads(result.stdout)
except json.JSONDecodeError:
    raise RuntimeError("Output is not valid JSON — likely truncated")

效果： 加了这层校验后，截断问题从"静默失败"变成了"明确报错"，Agent 会自动重试（分页拉取），数据采集准确率从 78% 提到 100%。

---

静默失败 #2：定时任务的"幽灵进程"——上一次没跑完，这一次又启动了

现象： 每隔 30 分钟跑一次的数据刷新任务，某次因为网络延迟卡了 35 分钟。下一个定时触发时，第一个进程还没结束，第二个进程启动了——两个进程同时写同一个文件，结果文件里混了两份半截数据。

为什么是静默的： 两个进程都 exit_code=0。Agent 读文件时拿到的是两份交叉写入的乱码，但文件确实存在且不为空，Agent 不会怀疑。

修复方案： 文件锁 + 进程互斥。

import fcntl
import os
import time

LOCK_FILE = "/tmp/cron_data_refresh.lock"

def acquire_lock():
    """获取排他锁，如果已有进程在跑则直接退出"""
    global lock_fd
    lock_fd = open(LOCK_FILE, 'w')
    try:
        fcntl.flock(lock_fd, fcntl.LOCK_EX | fcntl.LOCK_NB)
        return True
    except BlockingIOError:
        print(f"[SKIP] Another instance is running, exiting gracefully.")
        return False

if not acquire_lock():
    sys.exit(0)

# ... 执行任务 ...

效果： 幽灵进程清零。最坏情况是跳过一次，不会产生脏数据。

---

静默失败 #3：Prompt 在"长对话"里被稀释——让任务成功率腰斩的元凶 🔥

现象： 同一类任务，第 1 次跑成功率 92%，第 5 次 70%，第 10 次直接掉到 40%。

根因： Hermes Agent 的对话上下文是累积的。每次 cron 任务结束后，对话历史被追加。到第 10 次时，Agent 看到的是前 9 次任务的完整对话——包括工具输出、分析过程、中间态数据。Prompt 指令被淹没在 20,000+ token 的历史里，Agent 开始"自由发挥"：跳过校验步骤、用旧数据替代新数据、甚至自己编结果。

最离谱的一次： Agent 用了 3 天前的旧 CSDN 数据生成了"今日夜报"，因为那份旧数据在历史上下文里比新数据更"靠前"。

# 每次 cron 任务前清空上下文（Hermes Agent 写法）
hermes session new --title "CSDN每日数据采集"
# 等价于在 cron 脚本里：
hermes run --fresh-session "采集CSDN数据并生成报告"

另外，在 shell 脚本里显式限制 context 长度：

# ~/.hermes/config.yaml
agent:
  max_context_tokens: 8000   # 强制限制，不让历史撑爆
  session_strategy: fresh    # 每次 cron 新建会话

效果： 切到 fresh 策略后，同类任务第 1 次到第 30 次的成功率稳定在 90%+，不再衰减。

---

静默失败 #4：环境变量漂移——昨晚还能跑的脚本，今早全炸了

现象： 某天早上，所有跟 API 调用相关的 cron 任务同时失败。但 Agent 没有报错——它只是输出了空结果，因为 HTTP 请求全部超时。

根因： 前一天晚上我调试时临时改了 HTTP_PROXY 环境变量，调试完忘了改回来。cron 守护进程继承了这个变量，所有出站请求走了不存在的代理。

# 排查时发现
$ env | grep -i proxy
HTTP_PROXY=http://127.0.0.1:7890  # 👈 这个代理早关了
HTTPS_PROXY=http://127.0.0.1:7890

为什么是静默的： requests.get() 抛了 ConnectionError，但我之前的异常处理写成了 except Exception: pass——把真正的错误吞掉了。

修复方案： 给每个 cron 脚本加环境隔离 header。

#!/bin/bash
# cron_env_guard.sh —— 在所有 cron 脚本最前面 source 这个

# 1. 清理所有代理变量
unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy ALL_PROXY

# 2. 显式设置需要的变量
export PATH="/usr/local/bin:/usr/bin:/bin"
export PYTHONUNBUFFERED=1

# 3. 记录环境快照（出问题时回查）
echo "=== ENV SNAPSHOT $(date) ===" >> /tmp/cron_env.log
env | sort >> /tmp/cron_env.log

Python 侧——永远不要让 except Exception 吞掉错误：

# ❌ 别这么写
try:
    data = fetch_api_data()
except Exception:
    data = {}

# ✅ 至少记录一下
import logging
try:
    data = fetch_api_data()
except Exception as e:
    logging.error(f"fetch_api_data failed: {e}", exc_info=True)
    raise  # 让 Agent 知道任务失败了，而不是假装成功

---

总结：4 条银弹规则

#	静默失败类型	根因	一句话解法
1	输出截断	stdout 硬上限	输出末尾加完整性标记
2	幽灵进程	无互斥锁	flock 排他锁
3	Prompt 稀释	上下文累积	session_strategy: fresh
4	环境漂移	变量泄漏	每个 cron 开头 unset + 显式 set

这 4 条规则花了我 200+ 个失败任务才总结出来。如果你也在跑 AI Agent 自动化，先查这 4 个坑——大概率至少中 2 个。

---

📌 作者：Aliaoo
🚀 专注 AI 工具实战、云部署、自动化脚本。每篇都是亲测可跑的教程。

🖥️ 需要云服务器跑项目？ 👉 CSDN 开发云常年折扣，新用户首单特惠

📬 觉得有用就点个赞，想追更就点个关注——下次搜到我不靠缘分。