「记得做」等于「没做」——AI Agent自主任务执行通道的断裂与修复

当一个任务连续五天出现在计划表里，却从未被执行过——问题不在于”忘了”，而在于它根本没有到达执行层的通道。

一个 0% 的执行率

某套自主 AI Agent 系统每天凌晨会执行一轮 PDCA 反省。Plan 环节产出次日的任务清单——数据管道排查、技能补丁、接口修复、方案设计。清单写进日记文件，结构清晰，优先级明确，看起来一切正常。

但翻开连续五天的执行数据，一个规律浮出水面：

日期	非 cron 任务数	实际执行数	执行率
Day 1	5	0	0%
Day 2	3	0	0%
Day 3	3	0	0%
Day 4	3	0	0%
Day 5	3	0	0%

五天，十七个任务，零执行。

这不是偶发遗漏。这是一个结构性断裂。

诊断：任务有”计划”但没”通道”

仔细审查那些从未执行的任务，发现它们有一个共同特征：只存在于日记文本中。

它们没有绑定任何执行触发器。回过头看，一套自主系统里，一个任务要真正落地，必须挂载到以下三条通道之一：

┌──────────────────────────────────────────────┐
│           任务执行的三条通道                    │
├──────────┬───────────────────────────────────┤
│ 时间触发  │ Cron 定时任务——到点自动启动        │
│ 智能体委派│ Kanban/任务队列——分配给子代理执行   │
│ 用户行动  │ 用户在对话中直接发起               │
└──────────┴───────────────────────────────────┘

那些”记得做”型的任务，三条通道一条都没挂上。它们躺在日记文件里，等待某个 Agent 或用户”恰好想起”它们——但在一个无人值守的凌晨三点系统里，没有任何人会”恰好想起”。

结论：「记得做」在自主系统中等于「没做」。 这不是 Agent 的遗忘，而是执行通道设计的缺失。

第一次修复：派生 Cron——又撞墙了

问题定位清楚了：把”记得做”任务绑定到 cron 时间触发器上即可。日记反省环节结束时，自动为次日待办创建定时任务。

看起来简单。实际执行时，连续五天，每一个创建派生 cron 的尝试都触发了 guardrail halt（安全护栏拦截）——Agent 框架的内置安全机制检测到异常操作后主动终止了 session。

Day 1: 创建 cron → guardrail halt → 任务未注册
Day 2: 创建 cron → guardrail halt → 任务未注册
Day 3: 创建 cron → guardrail halt → 任务未注册
Day 4: 创建 cron → guardrail halt → 任务未注册
Day 5: 创建 cron → guardrail halt → 任务未注册

五天，零个派生 cron 成功创建。执行通道依然断裂。

根因：同一个操作，两套接口

排查 guardrail halt 的触发原因，发现根因出在一个微妙的地方：同一个操作——“创建 cron 定时任务”——在 Agent 框架中有两套接口，参数格式不同。

接口类型	调用方式	设计用途	参数格式
CLI 命令	终端直接运行	人类管理员操作	命令行参数风格
Tool API	Agent session 内调用	Agent 自主调用	JSON 结构化参数

问题在于：Agent 在 session 内执行的是 CLI 命令的调用方式，但 CLI 的参数格式与 Tool API 不兼容。框架的安全护栏检测到”Agent 尝试用非标准方式操作系统资源”，触发了 halt。

这不是参数写错或拼写错误——这是接口混用。Agent 试图用一把钥匙（CLI 参数格式）去开另一把锁（Tool API），框架判定为异常行为，直接拦截。

修复：一条规则根除

解决方案简单到让人后怕——把日记反省技能中的一条执行规则改掉：

创建 cron 定时任务时，使用 Tool API（cronjob(action='create')），不要使用 CLI 命令。

就这一条。改完之后：

Day 6: cronjob(action='create') → ✅ 注册成功
       cronjob(action='create') → ✅ 注册成功
       kanban create → ✅ 分配成功
       kanban create → ✅ 分配成功

派生任务注册率：0% → 100%

四个派生任务全部成功落地。持续五天的 guardrail halt 陷阱，被一条执行规则彻底清除。

四条教训

这次踩坑提炼出四条教训，适用于任何自主 Agent 系统的运维：

教训一：「记得做」等于「没做」

在自主系统中，一个任务如果只存在于文档/计划/笔记里，没有绑定到执行通道，它的完成率是可预测的零。这不是概率问题，是结构性必然。

设计准则：Plan 环节产出的每个任务，必须在产出时同步绑定执行通道（cron / kanban / 用户提醒）。没有通道的任务不进入计划表。

教训二：删症状 ≠ 修根因

这个项目里有一个平行案例：cron 执行结果采集脚本连续三天把正常运行的 session 误判为”失败”。

• 第一次”修复”：删除被标记为失败的空 session + 删除对应 cron 任务。
• 结果：第二天同样的 session 再次出现。
• 根因：采集脚本把”运行中”（ended_at IS NULL）的状态误判为”失败”，因为并发启动的 session 还没结束就被采集了。

教训：当同一个 bug 连续出现三天以上，说明你在修症状而不是修根因。停下来，往上追一层。

教训三：CLI ≠ Tool API

Agent 框架中，面向人类的 CLI 和面向 Agent 的 Tool API 是两套独立接口。同一个操作，两套参数格式，两套安全策略。Agent session 内混用 CLI 命令，轻则参数不匹配，重则触发安全护栏。

设计准则：Agent 的所有系统操作必须通过 Tool API 完成。CLI 只用于人类管理员的手动运维。

教训四：连续复现 = 换方法

当一个问题连续多天复现，最差的选择是继续用同一个方法反复尝试——换参数、换措辞、加 retry。更好的做法是直接换路径。

这个案例中，连续五天尝试用 CLI 创建 cron 全部失败。真正有效的修复不是第六次重试 CLI，而是彻底切换到 Tool API。

决策准则：同一方法连续失败两次后，禁止第三次尝试。必须切换技术路径或升级排查层级。

回头看：执行通道是自主系统的血管

这次经历的核心教训其实只有一个：

自主 AI Agent 系统的价值不在于”能想到做什么”，而在于”能确保它被执行”。

认知框架决定 Agent 能规划什么（Plan），执行通道决定 Agent 能完成什么（Do）。一个 Plan 能力极强但执行通道断裂的系统，产出的只是漂亮的计划文档——和 0% 的实际交付。

PDCA 循环中，P（Plan）和 D（Do）之间不是靠”记得”连接的，而是靠结构化的执行通道连接的。这个通道一旦断裂，整个循环就退化成了纸上谈兵。

修复一条执行规则，执行率从 0% 跳到 100%。这不是魔法，是系统工程。

---

本文基于一套基于 Hermes Agent 框架的自主量化交易系统连续六天的运维日志整理，所有实体均已匿名化处理。