最新

嘿，HN， 我开发了Tinman，因为在生产环境中发现大型语言模型（LLM）的失败实在太麻烦了。传统的测试只检查你已经想到的内容，而Tinman则试图发现你未曾想到的问题。 它是一个自主研究代理，能够： - 生成关于潜在失败模式的假设 - 设计并运行实验来测试这些假设 - 对失败进行分类（推理错误、工具使用、上下文问题等） - 提出干预措施并通过模拟进行验证 核心循环持续运行，每个周期都会为下一个周期提供信息。 为什么是现在：随着像OpenClaw/ClawdBot这样的工具为代理提供真实系统访问，失败的表面远比“糟糕的聊天机器人响应”要大得多。Tinman拥有一个网关适配器，可以连接到OpenClaw的WebSocket流，以便在请求流动时进行实时分析。 三种模式： - LAB：对开发环境进行无限制研究 - SHADOW：观察生产环境，标记问题 - PRODUCTION：需要人工批准 技术： - Python，全面支持异步 - 可扩展的GatewayAdapter ABC，适用于任何代理/网关 - 内存图，用于跟踪何时知道了什么 - 兼容OpenAI、Anthropic、Ollama、Groq、OpenRouter、Together ``` pip install AgentTinman tinman init && tinman tui ``` GitHub: [https://github.com/oliveskin/Agent-Tinman](https://github.com/oliveskin/Agent-Tinman) 文档: [https://oliveskin.github.io/Agent-Tinman/](https://oliveskin.github.io/Agent-Tinman/) OpenClaw适配器: [https://github.com/oliveskin/tinman-openclaw-eval](https://github.com/oliveskin/tinman-openclaw-eval) Apache 2.0。没有遥测，没有付费层。欢迎反馈和贡献。

我的谷歌账户自2024年3月起在GCP上被暂停。<p>在过去两年中，我通过ts-consult@google.com提交了多次申诉。每次我都收到相同的自动回复模板，要求我进行解释，我详细回复后，就再也没有任何回应。没有人回复我。<p>案例编号：#1-8622000037271<p>时间线： - 2024年3月：账户被暂停，提交申诉 - 2024年4月：收到自动请求信息的邮件，我进行了回复 - 2024年11月：收到更多自动邮件，我再次回复 - 2024年12月至今：完全没有回应<p>我是一名加州大学伯克利分校的计算机科学研究员。这对我的工作造成了严重影响。<p>有没有人成功让谷歌审核GCP暂停的申诉？你是如何联系到人工客服的？

我读过许多让人惊讶的故事，来自那些看似是真正的OpenClaw用户，比如他们的助手（从实用到戏剧化）如何（1）规划旅行并预订一切；（2）创办公司并构建产品；（3）进入股市并赔光所有资金……Moltbook则增添了更多乐趣。 有趣的是，我在熟悉的社区中找不到一个OpenClaw的用户，推测可能是因为设置需要一些努力，而人工智能掌控一切的概念对普通科技爱好者来说太过可怕。 我浏览了HN上的评论，许多讨论了这个想法，但没有分享第一手的用户体验。一些尝试过的HN用户由于各种原因放弃或失败了： - [链接1](https://news.ycombinator.com/item?id=46822562)（消耗了太多代币） - [链接2](https://news.ycombinator.com/item?id=46786628)（同上 + 安全隐患） - [链接3](https://news.ycombinator.com/item?id=46762521)（由于沙盒限制安装失败） - [链接4](https://news.ycombinator.com/item?id=46831031)（Moltbook无法正常工作） 我感受到了一种炒作的气息……HN的用户们，你们中间有没有人真正运行过OpenClaw，并让它做一些有用或有趣的事情？能分享一下你的经验吗？

<a href="https://archive.ph/lZlAs" rel="nofollow">https://archive.ph/lZlAs</a><p><a href="https://www.theguardian.com/technology/2026/jan/31/us-authorities-reportedly-investigate-claims-that-meta-can-read-encrypted-whatsapp-messages" rel="nofollow">https://www.theguardian.com/technology/2026/jan/31/us-author...</a>

嗨，HN， 我想分享S2C的alpha版本，这是一个基于S3构建的状态机复制系统。 其目标是使分布式应用能够在不需要节点法定人数的情况下，保持一致的状态，以实现可用性和一致性。 这个想法源于一个使用S3的副项目，我需要强一致性的分布式状态，但又想避免增加额外的共识依赖。我最初尝试直接使用S3进行协调，但结果变得复杂。最终，我意识到我需要一个具有确定性日志的复制状态机，因此它演变成了一个独立的项目。 为了减轻S3的延迟和API成本，它默认使用基于时间和大小的批处理。 S2C支持： - 可线性化的读写（单节点） - 精确一次的命令语义（对于具有稳定身份的节点） - 动态节点加入和从零节点的冷启动恢复 - 在没有时钟或租约的情况下实现分脑安全 - 快照、日志截断等功能 当然，它在操作简单性上牺牲了延迟和S3操作成本——并不打算替代高吞吐量的Raft环。而且显然，只能在已经使用S3（或兼容类似保证）的架构中使用。 到目前为止，它已经通过了混沌/故障注入测试（崩溃、分区、领导者被杀）；计划进行形式验证。 它仍处于alpha阶段，但我希望大家能尝试、实验并提供反馈。 如果你感兴趣，代码和详细的深入指南在这里：[https://github.com/io-s2c/s2c]