廖智海
我不再相信AI Agent说的「执行成功」了
Thu 30 April 2026我最近把一些很碎的提醒，交给 Hermes Agent来处理。
你可以先把它理解成一个接入微信、Telegram、飞书这些聊天工具的个人 AI 助理，不只是陪你聊天，也能调用工具，比如查资料、读文件、跑命令、管理定时任务。
这里说的提醒，不是手机闹钟，也不是微信自带功能。实际效果就是，我在微信里告诉 Hermes Agent，明天几点提醒我做什么，它接到指令后调用定时任务工具登记下来，到点再把提醒发回到微信里。
前一天我就是这么设了一个提醒，第二天上午9点提醒我去朝阳出入境大厅取港澳通行证。
早上9点，这条提醒到了。
但我当时走不开，就在微信里引用了那条提醒消息，补了一句，Delay the task and remind me at 12:30。
剩下的，就是看到 Hermes Agent 在吭哧吭哧地调来调去。折腾了一阵，它告诉我：调整成功。
不过这折腾的过程，我觉得有必要回顾一下。
原任务？早没了
延后提醒，就是把原任务的提醒时间从9点改成12:30。
听起来很简单。
Hermes Agent一开始也是按这个方向处理的。
它先确认了一下当前时间，10:26，12:30还没过。这个动作很小，但能避免把提醒设到一个已经过去的时间。
然后它尝试修改原任务。
原提醒消息里带着任务编号，0a1fc54812b9。既然是延后，最合理的操作就是找到这个任务，把它的执行时间改掉。
结果系统返回，任务不存在。
为啥？
因为这个取证提醒是一次性任务。早上9点已经执行完了，执行完之后，系统就把它从调度器内存里清理掉了。
也就是说，我微信里刚刚收到的那条提醒，在任务系统里已经不在了。
这就是第一个小坑。
对人来说，「刚刚那条提醒」还在聊天记录里。
对 Hermes Agent 的调度系统来说，那个一次性任务已经结束了。
旧的没了，新建一个
既然原任务已经不存在，就不能再修改它。
只能新建一个。
它建了一个一次性任务，时间是当天12:30。
内容还是去朝阳出入境大厅领取港澳通行证。
发送位置还是当前这个微信聊天。
系统返回说创建成功，并给了一个新任务编号，e3dbbb0a9bb1。
如果只是普通操作，到这里就可以结束了。
系统说成功，任务有编号，时间也对。
看起来已经没问题。
但我现在对这种「执行成功」四个字已经没那么放心了。
「成功」也不一定靠谱
这里要讲一下前一次踩坑。
之前我有一个「A股每日复盘」的定时任务。它每个工作日16:30自动运行，整理当天市场情况，然后推送给我。
后来我想把它的投递通道，从飞书改到Telegram。
当时工具返回消息说修改成功了，任务时间还在，任务状态也正常，投递通道也确实变成了Telegram。
看起来一切都对。
但后来去检查持久化文件的时候，发现一个很严重的问题。
这个任务的prompt被清空了。
prompt可以简单理解为任务正文，也就是它到点之后到底要干什么。
这就很尴尬。
任务的壳还在，时间还在，状态还在，但它已经不知道自己该执行什么了。
如果不去检查，下一次它可能还是会按时启动，但启动之后没有正文可执行。
这种问题，光看「执行成功」是看不出来的。
所以后来我让 Hermes Agent 自己想办法避免这种问题。它给出的方案是留一条持久记忆，涉及定时任务时，不能只相信 Agent 调度器返回的成功，要去~/.hermes/cron/jobs.json里确认任务是否完整落盘。
你可以把jobs.json理解成定时任务真正写在硬盘上的登记本。
调度器返回成功，更像是告诉你，系统刚刚接受了这个操作。
但任务有没有完整、可靠地写进登记本里，尤其是正文有没有丢，还要另查。
所以这次重新创建12:30提醒之后，Hermes Agent没有停在「创建成功」那里。
它去读了硬盘上的jobs.json文件，想确认新任务真的存进去了。
第一次查，没找到。
查不到？原来是查错了
第一次查不到的时候，看起来有点吓人。
系统刚刚说创建成功，怎么硬盘文件里没有？
后来继续看文件结构，才发现是字段名不一样。
定时任务工具返回的任务编号字段叫job_id。
但jobs.json文件里，存的是id。
这就像一张表里写「订单号」，另一张表里写「编号」，说的是同一个东西，但你按错字段查，就会以为它不存在。
第一次脚本按job_id去查，所以查不到。
改成按id查之后，果然找到了。
新任务确实在文件里，时间是12:30，投递位置是当前微信聊天，状态是scheduled。
到这里，才算确认这件事真的办完了。
注意，这里的重点不是字段名有多奇怪。
重点是，如果没有那条「必须查持久化文件」的规则，整个流程很可能在「创建成功」那一步就结束了。
而这一步，恰恰是之前出过问题的地方。
不是细心，是踩过坑
为什么微信引用原消息很重要？
这次我不是单独发了一句「延后到12:30」，而是引用了原来的提醒消息。
这个动作很重要。AI Agent 当前上下文不会把定时任务发送的消息算进去，这是很不符合用户习惯的地方。
如果只说「延后到12:30」，不引用定时任务发送的消息，对于当前上下文来说，缺少三个信息，延后哪个任务，原任务编号是什么，原提醒内容是什么。
AI Agent 拿到这些信息，才知道应该处理的是哪一个任务。
所以和 Agent 协作时，一定要注意定时任务消息和当前上下文割裂的问题。
Agent靠谱？全靠规矩
通过不断地调教，我现在越来越觉得，Agent 的可靠性，来自三件事。
上下文够不够清楚，规则有没有提前写下来，执行完有没有校验。
这次的取证提醒就是一个很小的例子。
如果没有引用原提醒消息，它不一定知道要延后哪个任务。
如果没有持久记忆里的校验规则，它很可能会停在「创建成功」。
如果没有去查jobs.json，也就发现不了任务到底有没有真正保存。
所以我现在不太相信 Claude、Hermes Agent，或者其他 Agent 系统嘴里的「执行成功」。
不是说它们一定在骗你。
而是「执行成功」通常只代表某一个环节成功了。
它不一定代表整件事已经可靠闭环。
这和我们平时用软件很像。
页面提示保存成功，不代表文件没有损坏。
转账页面显示提交成功，不代表最终到账。
任务显示创建成功，也不代表它的正文、时间、投递位置都完整保存了。
关键任务，还是要看最终记录。
想试试？多让 AI Agent 二次确认
如果你也在用 AI Agent 管定时任务，这里有一个简单的做法：让 Agent 马上发一条消息验证一下。
别太相信 AI Agent 说的「执行成功」。验证过的「执行成功」才是真的成功。
扫码入群，交流 AI Agent 使用体验。
