8.0
热点
AI SCORE
编程提效2026-09-24 09:32
定时 Agent 总重复干活？用完成分类账让它知道什么是「做完」
dev.to · AI#AI Agent#自动化#记忆模式
Editor brief · 编辑速览
定时运行的 AI Agent 默认无状态，每次都重做相同任务；解决方案是建立「完成记录」（Completion Ledger），让 Agent 记住历史执行状态，避免重复劳动。
你的工单分类 Agent 每天早上勤勤恳恳地处理同一批 40 张支持工单。你的线索评分 Agent 重复地对同一批线索进行再评分。你的报表 Agent 周二提交了报告，然后周三又生成了一遍，仿佛周二从未发生过。
这个 Agent 并不是懒惰或坏了——它是在用空白状态勤恳工作：每次定时执行都从零开始，不知道上一次运行完成了什么，所以它会重复那些在它看来还没有人做过的工作。
问题不在于更好的 prompt 或更大的上下文窗口，而在于大多数自动化配置从未构建过的一种特定记忆：一份"已完成工作"的记录。
n8n 工作流、Make 场景或定时脚本默认是无状态的。每次执行都是全新的：它拉取输入、交给 Agent、Agent 执行。当运行结束时，Agent 所做的一切都蒸发殆尽。明天的运行重复同样的拉取，对同样的条目再次执行。
症状是重复，而不是混乱：Agent 做了真实的工作，然后丢失了所有它完成过的证据。同一张工单被回复两次，同一个线索被丰富两次，同一份报告被提交两次。
存储的规则无法解决这个问题："始终将计费工单标记为紧急"在运行之间是持久化的，但它无法说明哪些工单已被处理。检查最新状态也不行：一张工单此刻可能是"开放"状态，但周二的运行已经起草了回复。
Agent 缺失的是对已完成工作的记忆。
实用的模式是完成账本（completion ledger）：一个小而持久的记录，记下 Agent 已经完成的工作，在每次行动前检查它，在每次运行结束时更新它：
为工作项建立稳定身份。 Agent 只有能识别出同一条目两次，才能记住"已完成"。这意味着要用稳定标识符来识别每个工作项：工单 ID、邮件线程 ID、线索记录 ID，或行数据的哈希。"Sarah 关于退款的邮件"是不稳定的，ticket_8841 才是。
先检查再行动。 在 Agent 对任何有副作用的条目执行操作之前，先在账本中查找该项。已经在账本中且操作匹配？跳过。不在账本中？继续。这个检查必须是工作流中的一个硬性步骤，而不是 prompt 中的礼貌建议。Prompt 会被略读，查找步骤则会被执行。
在运行结束时写入结果。 记录做了什么、对哪个条目、什么时候、以及结果：不是"已处理工单 8841"，而是"于 09:04 回复了工单 8841，回复已发送，等待客户响应"。下一次运行需要足够的细节来判断"已完成"是否仍然是已完成。
这里是最多第一版会出错的地方：完成不是永久的。一月联系过的线索可能在四月又变成有效数据，"已解决"的工单可能重新打开，上周的报告到周五就过时了。
所以完成记录需要过期机制，过期时间应该与任务匹配：
没有过期机制，完成账本就变成了另一种失败：Agent 拒绝处理它合法应该再次处理的事情。"我已经给他们发过邮件了"如果邮件被退回、收到回复、或已经过了六个月，那就错了。账本必须记录足够的上下文来区分"已完成且仍然完成"和"已完成但情况已变"。
完成账本只有在每一个可能重复工作的 Agent 都读取同一份账本时才能生效。这就是按工作流独立存储会悄悄失败的原因。
你的 n8n 工作流维护自己的"已处理"列表，你的 Make 场景维护另一份，承包商的定时脚本在本地文件中维护第三份。n8n 的 Agent 完全不知道 Make 场景已经联系过那个线索，所以它再次联系了他们。每一份账本只对自己的工作流是正确的，对其他工作流则视而不见。
解决方案是一个所有 Agent 和工具在行动前都会读取的共享账本。这正是共享内存层的用途。Vilix AI 就是为这种场景构建的：云托管，无需运行数据库，通过 MCP 与 Agent 连接，因此同样的记忆可以跟随工作流跨 Claude、Codex、Cursor、OpenClaw、Hermes 或任何兼容 MCP 的 AI 工作。n8n Agent 写入的完成记录对 Make 场景的 Agent 和定时脚本都是可见的，因为他们都读取同一个存储。最后写入胜出，检索支持最近优先，所以下一次运行看到的是每条记录的最新版本。
它存储完整的对话历史，而不仅仅是提取的事实，所以账本条目携带的是实际上下文，而不仅仅是一个"已完成"标记。试用门槛很低：永久免费计划，无需信用卡的 7 天 Pro 试用，而且你的数据始终属于你，可以随时以便携格式导出或删除。
完成账本阻止重复工作。它本身并不能让 Agent 变得可信。
首先，破坏性操作仍然需要人工把关。"我已经发送了吗"和"我应该发送吗"是两个不同的问题。一个完美追踪发送记录的账本，仍然可能完美地追踪了一次根本不该发出的发送。退款、删除、对客户的外发消息：无论有没有账本，在这些操作之前都要保留人工审批步骤。
其次，账本的诚信取决于 Agent 的报告。如果 Agent 在 API 调用失败时记录"邮件已发送"，账本就成了一台跳过从未做过的工作的机器。要从工具结果中记录结果，而不是从意图中：写入发生在工具确认成功之后。
第三，部分工作需要部分记录。一个丰富了 10 条线索字段中的 8 条然后崩溃的 Agent，不能记录"线索已丰富"。按条目、按操作细分记录，这样下一次运行就能精确地在上一次停止的地方继续。
大多数定时 Agent 的可靠性工作都花在 prompt 上：更精确的指令、更长的上下文、更多的示例。Prompt 不记得周二。完成账本记得。
教会你的 Agent "完成"是什么意思，把它存储在每次运行都能看到的地方，用过期规则让它保持诚实。重复邮件停止了，重新分类的工单停止了，Agent 终于能把运行时间花在新工作上了。