嗨，HN，
我创建了Buildcage，以解决工作中反复出现的问题：在Docker构建过程中，像`npm install`和`pip install`这样的工具可以执行任意代码，并且可以向任意主机发起外部连接，而我们对此没有可见性和控制权。一个被攻击的依赖项可能会悄悄地泄露构建秘密，或者向攻击者的服务器发送信息——而你根本无法检测到。
Buildcage为Docker构建添加了透明的外部网络控制：你可以定义允许的域名，其他所有的连接都会被阻止并记录。没有代理注入，没有证书更改——HTTPS过滤是通过SNI检查完成的，因此TLS保持不变。这是一个可以直接集成到Docker Buildx和GitHub Actions的层。
大约三周前，我分享了一个早期版本。从那时起，我替换了代理层（nginx → HAProxy），实现了对所有TCP端口的拦截，并添加了IP白名单。我还重新设计了规则语法，以支持通配符、正则表达式和统一的主机:端口格式。
由于Buildcage位于你的构建管道中，合理的问题是：你如何信任这个工具本身？你可以fork这个仓库并自己构建镜像——我为此添加了自托管指南。文档中也明确列出了它可以防御的内容以及无法防止的内容。安全工具应该诚实地说明其局限性。
这并不是灵丹妙药——它是最后一道防线。如果其他措施出现漏洞，至少它无法向外发送信息。
GitHub: [https://github.com/dash14/buildcage](https://github.com/dash14/buildcage)
欢迎反馈。如果你觉得它有用，给我一个GitHub星标会非常有帮助。
返回首页
最新
嗨，HN，
当浏览器停止支持NPAPI插件时，成千上万的2000年代早期网页游戏实际上被遗忘在了时间的长河中。特别是Macromedia Shockwave，它是一个闭源、极其复杂且文档稀缺的系统。
因此，我和几个朋友花了两年的时间做了一件可以说是疯狂的事情：从头开始重建整个Director引擎。今天，我们终于分享dirplayer-rs。
代码库： [https://github.com/igorlira/dirplayer-rs](https://github.com/igorlira/dirplayer-rs)
我们故意保持沉默，直到我们有了不可否认的证据，证明这确实是可能的。在我们最新的v0.4.1版本中，我们实现了完整的硬件加速图形。复杂的游戏现在可以在浏览器中原生启动，并且完全可以玩。
几个童年经典，现在可以玩了：
Habbo Hotel: [https://dirplayer.com/habbo](https://dirplayer.com/habbo)
LEGO Junkbot: [https://dirplayer.com/junkbot](https://dirplayer.com/junkbot)
LEGO Worldbuilder: [https://dirplayer.com/worldbuilder](https://dirplayer.com/worldbuilder)
我们选择Rust和WebAssembly，因为我们希望以一种原生、无插件的方式来玩这些游戏，而不依赖于古老的可执行文件。解析数十年前的不可信二进制文件和未文档化的字节码是一个内存安全的噩梦，这使得Rust成为一个轻松的选择。它还提供了可预测的性能，没有垃圾回收暂停，保持了流畅的帧率。
到目前为止，最大的难题是Lingo，Director的脚本语言。它非常庞大，强烈支持3D图形、嵌入的Flash内容，最糟糕的是：Xtras。Xtras是从本地C代码编译的外部可分发插件。弄清楚如何让这些插件在现代WASM环境中良好运行是一个严峻的挑战。
然而，我们成功实现了Multiuser Xtra，这样游戏就可以创建套接字连接（这就是Habbo正常工作的方式！）。我们仍然有很长的路要走，以支持完整的3D和庞大的第三方Xtras生态系统，但基础是坚实的。
这一切并不是孤立发生的。我们建立在Shockwave逆向工程社区多年的前期工作之上：那些多年来一直在研究Director内部的人，他们之前的项目、工具和研究使这一切成为可能。
欢迎在评论中深入讨论：逆向工程过程、反编译古老的二进制文件、Director虚拟机的奇怪特性、Rust架构，或者你感兴趣的任何内容。
真心想问：你希望哪个老Shockwave游戏仍然可以运行？请在下面留言，我们看看能否让它启动。
我构建了一个在Linux上本地运行的自主AI操作系统。
这不是一个聊天机器人——它将复杂任务分解为子任务，自动执行这些任务，编写和运行代码，浏览网页，并从每次交互中学习。
主要特点：
- 多模型支持：Claude、GPT-4、Gemini、Groq、DeepSeek（任何与OpenAI兼容的模型）
- 项目管理器：将项目分解为子任务并并行执行
- 持久内存（向量 + SQLite）
- DeepThink：在执行前审核关键操作的二次推理层
- 插件系统：将.py文件放入plugins/目录，即可立即使用
- 实时活动窗口，显示每个工具调用的实时情况
使用Python + PyQt6构建。MIT许可证。
GitHub: [https://github.com/FiratBulut/Moruk-OS](https://github.com/FiratBulut/Moruk-OS)
我建立了一个仪表板，旨在使国家级经济数据变得易于理解。<p>它不是简单地显示“出口额为X十亿美元”，而是展示意大利出口了9600万件连衣裙、11000艘游艇和21亿升葡萄酒。<p>截图：<a href="https://imgur.com/a/kuxWr55" rel="nofollow">https://imgur.com/a/kuxWr55</a><p>该仪表板涵盖了37个国家的贸易（联合国商品贸易统计）、政府支出（经济合作与发展组织/政府职能分类）、收入、债务、战略资源依赖以及24个世界银行指标。<p>技术栈：Next.js + React + D3.js，FastAPI + SQLite后端。<p>目前尚未上线，分享截图以便在发布前获取反馈。想知道这对任何人是否有用，或者我是否只是在为一个人而构建。
我开发了一个基于浏览器的工具，利用视觉-语言模型（VLMs）通过自然语言提示在卫星图像中检测物体。用户可以在地图上绘制多边形，输入想要查找的内容（例如：“游泳池”、“油罐”、“太阳能板”），系统会逐块扫描，并将边界框以GeoJSON格式投影回地球上。
工作流程如下：选择缩放级别 + 提示 → 将地图切割成商业瓦片 → 将每个瓦片和提示输入VLM → 创建边界框 → 投影到WGS84坐标系 → 在地图上渲染。
演示不需要登录。对于明显的结构，系统表现良好，但在处理密集或被遮挡的物体时，狭窄的YOLO模型仍然更具优势。
代理的核心能力完全源于基础的大型语言模型（LLM）。因此，代理的未来严格取决于当前LLM的状态。
那么，LLM现在处于什么阶段呢？
我认为我们目前正处于人工智能的“家庭工业”阶段——工业化的黎明。用一个历史类比来说：我们刚刚发明了第一台蒸汽机。它们笨重、固定，只能用于从煤矿抽水。我们距离拥有蒸汽机车还远得很。
现在，定制代理的数量正在迅速增长。但如果仔细观察，它们几乎都是“自给自足”的，并且相互孤立。每个人都在为自己特定的用例构建自己的代理，但要将它们适应或扩展到更广泛的用途却非常困难。这就像每个家庭都有自己的织布机，织自己的布料，从不使用别人的。
为什么会这样？这归结于当前LLM的局限性。如果暂时不考虑多模态能力，基于文本的LLM基本上有四个核心支柱：
1. 自然语言理解（NLU）
2. 自然语言生成（NLG）
3. 工具调用
4. 推理
前面三个已经非常成熟且可靠。但第四个——推理——仍然是一个充满幻觉的雷区。
然而，代理开发者最为痴迷的是什么？推理。为什么？因为在演示中看起来很酷。这种痴迷正是我们无法真正“工业化”代理的原因。这也是为什么在实际应用中很难找到一个真正可靠的通用代理（最近关于Manus的炒作与现实检查就是一个教科书式的例子）。
当然，总有一天LLM的推理能力可能会超过99%的人类。当那一天到来时，我们将最终看到真正强大、通用的代理。但老实说，没有人确切知道这个时间表会在何时到来。
我的结论是：如果我今天要为生产构建一个通用代理，我将严格利用NLU、NLG和工具调用。我会尽量避免依赖“推理”。
最近和一些朋友关于人工智能的对话让我思考了这些。我的观点似乎引起了他们的共鸣，所以我在这里分享，希望听听你的想法。