最新

快速背景：我正在构建后台作业自动化，并不断遇到以下模式： 1. 作业调用外部 API（Stripe、SendGrid、AWS） 2. API 调用成功 3. 作业在记录成功之前崩溃 4. 作业重试 → 再次调用 API → 产生重复 示例：处理退款，发送电子邮件通知，然后崩溃。重试时再次执行这两个操作。客户收到重复的退款电子邮件（或者更糟，重复的退款）。 我看到几种解决方案： 选项 A：在数据库中存储已处理的 ID 问题：“检查数据库”和“调用 API”之间的竞争仍然可能导致重复。 选项 B：使用 API 幂等性键（Stripe 支持此功能） 问题：并非所有 API 都支持（遗留系统、第三方）。 选项 C：构建去重层，首先检查外部系统 问题：额外的延迟，额外的复杂性。 在生产环境中你会怎么做？接受一些重复？只使用支持幂等性的 API？还是其他方案？ （我为选项 C 构建了一些东西，但想了解这是否是一个足够普遍的问题，还是我在过度设计。）

嘿，HN， 当前的代理框架（如 LangChain、AutoGPT）依赖于提示大型语言模型（LLMs）并解析对话文本字符串来决定下一步行动。这在简单任务中有效，但在复杂推理时就会失效，因为它将代理的思维视为一个滚动的文本文件。 随着研究向联合嵌入预测架构（JEPAs）和世界模型转变，我们遇到了一个协调瓶颈。JEPAs 不输出文本；它们输出的是表示预测环境状态的抽象数学张量。如果尝试将 NumPy 数组路由到传统的基于文本的框架中，系统会崩溃。 我们构建了 Lar-JEPA 作为一个概念测试平台来解决这个问题。它使用 Lár 引擎，一个确定性的拓扑有向无环图（“代理的 PyTorch”），作为执行的支柱。 针对研究人员的关键特性： - 数学路由（无提示）：您可以编写确定性的 Python RouterNodes，直接评估潜在张量（例如，如果 collision_probability > 0.85：返回“重新规划”）。 - 原生张量日志记录：我们对 AuditLogger 进行了自定义补丁，使用了 TensorSafeEncoder。您可以在执行图中原生传递大量的 PyTorch/NumPy 张量，并且它能够优雅地将其序列化为元数据（{“__type__”: “Tensor”, “shape”: [1, 768]}），而不会导致 JSON 字符串化工具崩溃。 - 系统 1 / 系统 2 测试：正式测量快速反应执行与深度模拟规划的差异。 - 持续学习：包括一个默认模式网络（DMN）架构，用于“睡眠周期”记忆巩固。 我们还包含了一个独立的模拟，其中 Lár 系统 2 路由器分析一个模拟 JEPA 的数值状态预测，数学上检测到即将发生的碰撞，否决该行动并重新规划——这一切都没有生成任何英语文本。 代码库： [https://github.com/snath-ai/Lar-JEPA](https://github.com/snath-ai/Lar-JEPA) 期待听到您对非自回归模型协调的看法。

当前AI编码面临的两个问题： 1. 每个会话都从零开始。代理可以看到你的代码，但不知道它为什么会是这样的。 2. 团队知识保持孤立。一个开发者的代理昨天学到的知识对另一个开发者今天并没有帮助。 Rekal在每次提交时将会话上下文（包括转变、工具调用、文件更改）捕获到本地的DuckDB数据库中。一个2-10 MB的会话文件通过自定义的二进制编解码器（使用zstd和字符串内存驻留）压缩到大约300字节。它通过git孤立分支在团队之间共享——无需额外的基础设施。 搜索采用三重混合模式（BM25 + LSA + nomic-embed-text），全部集成在一个二进制文件中。没有外部API，没有云服务，无需设置。嵌入模型随二进制文件一起发布。 代理控制加载多少上下文——渐进式检索保持了令牌成本的最小化。 其他设计选择包括：仅追加且使用内容哈希去重（合并冲突在结构上是不可能的），在14,000次转变中搜索延迟约为200毫秒，除了git之外没有运行时依赖。使用Go语言编写，遵循Apache-2.0许可证。