已验证

为什么这重要

在生产环境中，代理的可靠性很少被它的提示词巧妙程度所限制。限制它的是那些乏味的细节：重试如何去重、状态如何在重启间持久化、外部 API 允许以何种方式失败。本文从那个角度看待。

把做错的代价，表现为：静默的重试、失控的 token 消耗、重启间丢失的上下文，最糟的，是那些在会话之间忘记自己是谁的代理。我们在真实部署中见过这四种。

核心模式

在负载下持续站得住的模式有三个属性：

1. 边界处幂等。重试必须收敛到同一状态。
2. 接合处可观测。每一次跃迁都产出一条日志、一个指标，或两者皆有。
3. 最坏情形下可恢复。崩溃不能毁掉用户状态。

这三个属性没有商量余地。它们是底线。

实现

具体来说，Hermes 风格架构中的scheduling-tasks通常遵循以下骨架：

# 伪代码，不是可直接复制的方案
async def handle(state, input):
    if not idempotent_check(input):
        return await replay(input)
    state = await observe(state, input)
    try:
        result = await do_work(state, input)
        return await checkpoint(state, result)
    except Retryable as e:
        return await backoff(state, e)
    except Fatal:
        await snapshot(state)
        raise

顺序很关键：先观察、再变更；成功后做检查点；致命异常前做快照。这正是模式具备韧性的原因。

模式 1：静默的重试循环

没有边界处的去重，重试对代理而言是成功，对世界则不然。哈希请求、跟踪 ID；永远别让裸的重试落地。

模式 2：重启时丢失的上下文

任何只活在进程内存里的状态都会在崩溃时蒸发。在确认成功之前先持久化——不要之后。

模式 3：token 预算耗尽

长时间运行的会悄悄抽干模型的上下文窗口。请监控每任务的 token 消耗，在跨过阈值时中止；不要依赖模型自行"收尾"。

我们如何验证它

该模式的验证夹具命中了以下场景：

• Hermes Agent 的 gateway 模式（Telegram / 飞书 / Discord），配有日常 cron 流量
• im-bot 多代理房间在负载下（50+ 条消息/分钟）
• nn-os watchdog + manas 反思流水线

测试夹具位于对应代码仓库的 tests/ 目录中，作为标准 CI 的一部分运行。

归档于 所有教程。 联盟披露：本网站参与 DigitalOcean（refcode 6eba412ef5dd）与 Amazon Associates（imsunmedia-20）。