Holdfast

Holdfast 的 Stripe 集成目前只能手动配置（粘贴 Webhook 地址到 Stripe 设置并填写签名密钥），因为 Stripe Connect 需要平台账号而作者没有。

Holdfast 的核心设计原则是：消息在被安全存储之前，不算确认收到。

Holdfast 位于服务提供方（如 Stripe、GitHub）和应用之间，执行先落盘再应答、校验签名并隔离伪造或重放消息、重试或安全搁置、解释问题、安全重发消息等五项功能。

Holdfast 中模型永远不决定消息的去向；重试、搁置、去重、重发全部由有测试覆盖的 Go 代码实现。

Gemma 3 4B 在 Holdfast 中只负责从固定的八种原因里选一个（受 JSON schema 约束）以及撰写解释文案，代码会逐字检查输出。

Holdfast 对面向客户的说明有逐字后置校验：若包含「HTTP」「payload」「endpoint」等术语或承诺未执行的动作，则拒绝并替换为内置规则措辞；标题永远由代码生成。

容器内 llama.cpp 读取宿主机资源（60GB+ 内存、16 核）而非 4GB 套餐配额，导致 prompt 缓存可能涨到 8GB 并触发 OOM；通过三个 LLAMA_ARG_* 环境变量设置压回 4GB 以内。

Holdfast 在 Live 模式下对用户填写的转发 URL 做双重 SSRF 校验：保存时检查一次目标地址，每次拨号时再检查一次解析结果。

Holdfast 的重发计划按到达顺序每个事件只发一次，已投递过的、签名失败的事件不会被重发。

Holdfast 是开发者 Tanay 在 Hacktoberfest 开源 AI 挑战赛中提交的项目，用于解决 Webhook 消息丢失问题。

Holdfast 使用 shape-diff 遍历两个 JSON 体来识别字段改名（例如 data.object.customer_id 消失、data.object.customer.id 出现），并向模型提供方向性信息而非原始路径列表。

Holdfast 的摘要必须有固定结构：这笔付款发生了什么（谁、多少钱）、用日常语言说明原因、接下来会怎样。

Holdfast 的 Promise 检查拒绝「正在审核」「将会重发」「我们团队正在…」等表述，开发者修复建议必须指出移动了的字段，否则回退到规则生成版本。

作者实测对比 Gemma 3 1B 和 4B：1B 在改名场景下写出「应用将重发被搁置的事件」并让发送方去改，两个错误都被检查拦下并回退到规则答案；4B 在笔记本 GPU 上约 16 秒，能准确说出客户、金额和具体字段。

Holdfast 部署到 Render 的两核 CPU 上，Gemma 解释一次需 92 秒；优化后两次线上实测分别为 48 秒和 83 秒。

Holdfast 页面先秒出内置规则的答案，等 Gemma 写好解释后再替换上去，以掩盖模型延迟。

在字段改名场景下，第一版 Holdfast 中 Gemma 原因判断正确，但摘要虚构了「正在审核」动作，且开发者建议方向写反（称应用需要 customer_id 而实际是 Stripe 字段变更）。

上线当天所有 Gemma 调用以 connection refused 失败，原因是 Render 服务间地址使用了默认端口而非 Ollama 的 11434 端口；规则引擎自动接管，站点全程可用。

第一个用户是作者自己的小应用 Tasklet（将 GitHub issue 转为待办）；实测中 Holdfast 在 0.27 秒内确认 GitHub 测试 ping，在 Tasklet 返回 503 时 34 秒内重试 5 次（分别等待 2、4、8、16 秒）后安全搁置，恢复后重发使任务出现一次且未丢失。

Gemma 在部分诊断输出中试图用弯引号结束 JSON 字符串导致停不下来并自我重复；修复措施包括每字段长度上限、在游离弯引号处截断、检查摘要像句子一样结束、调整字段顺序为 cause、summary、fix。修复后从 5 次里 2 次可用变成 4 次全部可用，耗时 16–40 秒。