已验证

为什么这重要

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

我们见过足够多种的失败方式，以至于知道那种失败的形状：起初很小，到规模化时就成灾难。缓解措施同样小，且只在事后才显得显然。

核心模式

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

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

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

实现

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

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