已验证

为什么这重要

生产环境的 AI 代理不是演示。一旦用户把代理用于调度、记忆、模型路由或凭证轮换，代理就成了承载性的基础设施。这些子系统里的失败会像瀑布一样漫过整个产品。属于这一类。

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

核心模式

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

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

缺了它们，系统会通过测试而在生产中失败——通常在最糟糕的时刻。

实现

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

# 伪代码，不是可直接复制的方案
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）。