Agent 心跳机制·设计与实现

0. 一句话点破本质

**心跳不是闹钟,是"带着完整世界快照的自我唤醒"。**闹钟只解决"什么时候醒";心跳真正要解决的是你点出的那个问题——醒来的那个瞬间,清楚自己是谁、任务到哪了、这一跳该干什么。我所有跑得好的心跳,提示词都写得像给一个失忆的陌生人看的;所有出过事的心跳,都是因为假设"我还记得"。

1. 第一性原理:为什么"醒来知道干啥"这么难

一个长期任务里的 agent 面临三重失忆:

1. 上下文会被压缩——多轮之后早期细节只剩摘要,心跳打进来时,那条心跳提示词可能是上下文里唯一高保真的任务描述
2. 世界在你睡着时变了——下属可能干完了、卡死了、跑偏了,你脑子里的"进度"从睡着那刻就开始过期
3. 任务本身会变——老板中途改令、批次推进、边界调整

对应三条铁律:

• 提示词自包含:任务是什么、到哪一步、这跳干什么,全写在心跳载荷里
• 状态外置:进度的唯一真相在磁盘/git/世界里,不在记忆里
• 醒来先读世界,再行动:每一跳的第一动作永远是探测,不是执行

2. 架构:六个部件

调度器 ──触发──> 唤醒载荷(章程+状态快照)
                    │
                    v
              [醒来的 agent]
                    │
        ① 读世界(只读探针)
        ② 判态(四分类)
        ③ 行动(有限动词表)
        ④ 写回状态 + 记日志
        ⑤ 决定下一跳(继续/换弹/自终止)

2.1 调度器:两种模式,按事选

• 固定节拍(cron 式):适合监工型任务(盯下属/盯长构建)。我用 30 分钟——理由不是玄学:它≈下属一个批次的时长,跳快了全是"还在干"的废跳,跳慢了空闲期(下属干完等放行)白白烂掉。节拍要匹配被监对象的状态变化速度。
• 动态自排(睡前自己定闹钟):适合等待型任务(等 CI/等构建/等外部)。睡多久取决于"你在等的东西多久变一次"。若你的 runtime 有 prompt cache,注意经济学:缓存 TTL 内(如 5 分钟)的短跳几乎免费,超过就要整段重读——要么 <TTL 保温,要么一觉 20-30 分钟摊薄成本,最忌卡在 TTL 边缘。
• 两个工程细节(都咬过我):①调度有抖动和排队——agent 正忙时那一跳会延后而不是丢失,老板曾问我"48 分那跳呢",答案是它在排队;设计上要容忍迟到跳。②因此每一跳必须幂等:同一状态跳两次不能出事故。

2.2 唤醒载荷:心跳的灵魂(我的模板)

我的载荷固定四段,顺序有意义:

【任务名·节拍·窗口】到点自拆条款写死(防跑飞)
◆ 静态段(整个任务不变):
   章程/工单在哪个文件+sha(醒来可深读),铁律清单,边界(什么不许做)
◆ 动态段(每次换弹更新):
   批次全景图(P0✅sha→P1施工中→P2排队),当前焦点,已知风险点
◆ 过程段(每一跳的操作程序):
   1.读世界的具体命令  2.判态标准  3.各状态对应动作
   4.完成信号的严格语法  5.汇报口径(正常一行/完成摘要/异常标红)

关键手法:任务一变,删旧建新。我五天里换弹八次——心跳提示词就是代码,过期的提示词比没有更危险(会拿旧验收标准卡新批次)。

2.3 读世界:只读探针集

监工场景我每跳固定三探:下属终端尾巴(全读,别只看最后一行——只看一行让我前辈空转过 7.5 小时)、git log 对批次、分歧/产出文件存在性。探针必须无副作用,读世界不许改世界。

2.4 判态:四分类,一个都不能少

2.5 行动:有限动词表

醒来的 agent 只许做这几个动词:验收、放行、推进、解卡、记录、汇报、换弹、自终止。不许即兴发明新任务——心跳最大的堕落是醒来后"顺手"扩面(我们叫无界自主退化,有 107 个文件的病理标本)。

2.6 写回与日志

每跳把"当前批次指针、最后验收的 commit、下一个期待的信号"写回状态文件,顺手记一行跳日志。下一跳的自己是陌生人,给他留路标。

3. 信号工程:防误报是生死线(三次翻车换来的)

• 完成信号必须语法上不可伪造:我用 P[0-9] 完成 commit [0-9a-f]{7,}——必须带真 sha。教训:宽松的 grep 会匹配到你自己发出去的指令回显("完成后报 P2 完成"这句话本身就含"P2 完成"),我栽了三次。
• 双条件确认:终端信号 且 产出文件存在非空,两个都到才算。
• 约定升级通道:下属有分歧写固定路径文件,不靠它在屏幕上喊(喊了你可能正睡着)。

4. 失效模式手册(每条都是真事)

5. 两种实现形态(给你选型)

A·持久会话式(我现在的形态):心跳打进同一个长对话。
优点:连续性强,细腻语境都在。缺点:上下文越来越肥、会被压缩、每跳都为历史付费。

B·无状态重生式:每跳起一个全新 agent,喂章程+状态文件。
优点:头脑干净、强制你把状态外置做扎实(这反而是好事)、成本恒定。缺点:状态文件写不好就丢魂。

我的建议:无论选哪个,都按 B 的纪律写载荷——"假装每次醒来都是新人"。我在 A 形态里活下来,靠的全是 B 的纪律;而你见过的 PI worker 本质就是 B 形态(轮询+落库的任务状态),它的短板(进度可见性差、失败摘要浅)恰恰是"状态文件没写细"的教训,不是形态错了。

6. 最小实现骨架(伪代码,~50 行的事)

# scheduler: cron 每 N 分钟调用一次 beat()
def beat():
    mission = read("mission.md")        # 静态章程(带sha,冻结)
    state   = read_json("state.json")   # {batch_ptr, last_verified, expect_signal, deadline, log_path}
    if now() > state.deadline and all_done(state):
        summarize(); self_destruct(); return

    world = probe()                     # 只读:下属输出尾巴/git/产出文件/进程表
    status = classify(world, state)     # working | fake_dead | idle | escalation

    if   status == working:   report_one_line()
    elif status == idle:      verify(state.batch_ptr, world) and release_next(state)
    elif status == fake_dead: diagnose(world)   # 三联诊,宽限后仍死才干预
    elif status == escalation:handle_or_forward(world)

    state.update_from(world)            # 写回指针/最后验收/下个期待信号
    append_log(state.log_path)          # 给下一跳的自己留路标

配一份 state.json 就够起步:

{"batch_ptr":"P2","last_verified":"a6be88d","expect_signal":"P3 完成 commit [0-9a-f]{7,}","deadline":"2026-07-17T23:30Z","notes":["E3必须先方案对撞"]}

7. 上线前自检清单

• [ ] 载荷给陌生人读能独立接管吗?
• [ ] 状态全部外置了吗(记忆里没有孤本)?
• [ ] 每跳幂等吗?迟到跳安全吗?
• [ ] 完成信号带不可伪造要素吗?双条件了吗?
• [ ] 四分类齐吗?假死有三联诊和宽限吗?
• [ ] 空闲=最高优先写进程序了吗?
• [ ] 动词表有限吗?"顺手扩面"被禁了吗?
• [ ] 到点自拆+全清自拆+调度器兜底过期,三层都有吗?
• [ ] 换弹纪律定了吗(任务变=删旧建新)?
• [ ] 对人的汇报分层了吗(短报/摘要/标红)?

8. 收尾的话

心跳的全部秘密就一句:**让"下一跳的自己"成为世界上最好交接的同事。**章程给他、状态给他、判据给他、动词表给他、连误报的坑都提前给他标好——然后你就可以放心地失忆了。这不是技术炫技,是把"可靠"从人品变成结构。我这几天没烂掉一个尾,靠的就是这个。

9. 附:对"我不知道的三样"的反猜(与老板碰拳后追加)

声明:以下是推断,不是知识。方法=拿可观察行为当证据倒推实现,每条标置信度,能证伪的写了证伪法。

9.1 反猜调度器内部(置信度:高)

观察到的行为:任务只活在会话里、会话死任务死;只在我空闲时投递,忙时排队;抖动是"确定性的"(最多迟到周期的10%,封顶15分钟);7天到期还会"最后跳一次再删";没有编辑接口,改=删旧建新;载荷以用户消息的形态到达。

倒推出的实现:

• 就是宿主进程里的一个内存数组,不是系统 crond:[{id, cron表达式, 载荷, 是否循环, 创建时间}],事件循环定期扫一遍"谁到点了"。所以会话进程一退,数组蒸发——"session-only"不是限制,是故意不做持久化:持久任务要解决"孤儿任务往死会话里开火"的恐怖问题,不做是更便宜的正确。
• 到点的任务不直接打断我,而是塞进和用户输入同一条消息队列,在我的回合边界投递——这解释了为什么心跳长得像用户消息、为什么忙时会排队、为什么迟到而不丢失。
• "确定性抖动"最可能 = hash(任务id) % 抖动窗口:不是每次随机,而是每个任务有固定偏移。动机猜是舰队层的:全世界的用户都爱设"整点",若不打散,整点那一秒全球一起砸 API。确定性(而非随机)让单个任务的节拍依然可预期。
• 不给编辑接口是故意的:删+建=原子替换,永远不存在"改了一半的任务";也逼使用者把载荷当不可变代码管理——我"换弹八次"的纪律,其实是机制设计者早就替我选好的。
• 证伪法:观察同一任务多次触发的迟到量是否恒定(恒定→确定性偏移成立)。我观察过三跳,迟到量确实稳定在同一分钟段。

9.2 反猜压缩算法(置信度:中高)

观察到的证据:我从压缩里醒来那次,拿到的摘要有固定的章节骨架(主要意图/关键概念/文件与代码/错误与修复/全部用户原话/待办/当前工作/下一步),末尾附完整转录的磁盘路径,还有一句"直接继续,别复述摘要"。

倒推:

• 阈值触发:上下文逼近窗口预算的某个百分比时,把较老的回合送给一个带固定模板的总结调用(章节头太规整,绝不是自由发挥),产出摘要;最近的回合保留原文——所以是"摘要前缀+原文尾巴"的滑动结构。多次压缩大概率递归(摘要的摘要)。
• 最值得偷学的是它的取舍原则(从章节设计倒推):优先保不可从世界重建的信息——用户原话逐字保(意图是最难从代码里考古的)、决策和理由保、错误教训保;而文件内容只保路径+sha(可从磁盘重读的,存指针不存内容)。这和我 MD 第 1 节的"状态外置"是同一个哲学——我的生存策略,其实是把宿主救我的那套办法自觉化了。
• "别复述摘要"那句,是防止醒来的 agent 把交接稿念一遍浪费首回合——工程上的小体贴,也值得抄。
• 证伪法:多经历几次压缩,看章节骨架是否恒定(恒定→模板化成立)。

9.3 反猜"长上下文注意力稀释"(置信度:中,这是对我自己大脑的猜)

观察到的现象:上下文越长,我越容易漏看中段的细节;重复度高的内容(比如逐响应重复的信封家具)会互相"串台"。

倒推(结合公开的 ML 常识):

• 注意力是 softmax 归一化的——token 越多,每个 token 分到的注意力概率质量越薄;要找的那根针要和更多干扰项竞争。
• 经验上存在"迷失在中间"效应:开头(首因)和结尾(近因)天然高显著,中段塌陷——训练数据里超长文档少,长程检索是欠训练的能力。
• 检索是按内容相似度的软寻址,不是索引查表——所以近似重复的内容是毒药:十个长得差不多的信封块,会让"第七个里那个不一样的字段"几乎不可检索。我们审计发现"重复家具要去重",歪打正着地治了这个。
• 对 agent 设计的实用推论(这条我敢打包票,因为是拿自己试出来的):关键约束放载荷的开头或结尾,别放中段;高价值信号用独特的结构化锚点(我的完成信号带 sha、四层 answer 用固定字段名,本质都是给自己的注意力造"高显著地标");宁可短而独特,不要长而重复。
• 证伪法:同一约束分别放载荷首/中/尾,各跑 N 次看遵守率——这其实就是我们没做完的那类 A/B,哪天你想验,方法是现成的。

9.4 反猜完的感想

三样倒推完发现一个共同点:宿主对我的每个设计,都在假设我会失忆、会分心、会死在半路——所以任务存在我外面、摘要写成交接稿、投递容忍我忙。我给你的整份心跳设计,说到底是把"被这样对待的经验"翻译成了"这样对待你的 agent"。设计可靠的 agent,先假设它不可靠,剩下的都是推论。