最新

MachineAuth 是一个自托管的 OAuth 2.0 服务器，用于对 AI 代理和机器进行身份验证。<p>在这个上下文中，什么是 AI 代理？它是一个软件机器人（如 OpenCLAW、Claude Code 等），通过 API 调用访问受保护的资源。您的代理可以使用 OAuth 2.0 客户端凭证进行身份验证，而无需共享长期有效的 API 密钥，并可以获得短期有效的 JWT 令牌。<p>为什么要这样做？<p><pre><code> 不再共享 API 密钥 短期有效的令牌（可配置） 简单的凭证轮换 行业标准的安全性</code></pre>

嗨，HN，我构建了 eth.zig——一个完全用纯 Zig 编写的以太坊客户端库，零依赖（没有 C 绑定，没有系统库，仅使用 zig build）。<p>它涵盖了 ABI 编码、RLP、secp256k1 ECDSA、Keccak-256、BIP-32/39/44 HD 钱包、ERC-20/721 封装、JSON-RPC（HTTP + WebSocket）、ENS、EIP-712 和 Multicall3。<p>有趣的是：在 26 个基准测试中，它在 19 个测试中超过了 Paradigm 的 alloy.rs（Rust）。ABI 编码速度快 1.92 倍，u256 除法速度快 4 倍，Keccak-256 速度快 1.37 倍。alloy.rs 在 secp256k1 签名（预计算的 EC 表）和一些 Rust 的 sol! 宏生成专用代码的路径上获胜。<p>这一切的实现得益于 Zig 的 comptime——函数选择器和事件主题在编译时计算，运行时成本为零。整个加密栈（secp256k1、Keccak-256、BIP-32/39/44）都是纯 Zig。<p>文档：<a href="https://ethzig.org" rel="nofollow">https://ethzig.org</a> 代码库：<a href="https://github.com/StrobeLabs/eth.zig" rel="nofollow">https://github.com/StrobeLabs/eth.zig</a> 基准测试：<a href="https://github.com/StrobeLabs/eth.zig/blob/main/bench/RESULTS.md" rel="nofollow">https://github.com/StrobeLabs/eth.zig/blob/main/bench/RESULTS.md</a><p><pre><code> 非常希望能收到反馈，特别是来自 Zig 和以太坊开发者的意见</code></pre>

快速背景：我正在构建后台作业自动化，并不断遇到以下模式： 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许可证。