返回首页
最新
考虑到像Claude Code或Codex这样的编码代理现在已经相当出色，提交给开源项目的拉取请求（PR）自然大幅增加。然而，并不是所有的PR都很优秀，有些确实是质量不高的AI生成内容。
例如，您可以查看Daniel Stenberg关于cURL相关主题的讨论：
https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/ 和 https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/
我很好奇，这对其他开源项目来说是多大的问题。
提交者们，你们遇到的这种困扰有多严重？你们是否使用任何AI工具来缓解或解决这个问题？
嗨，HN，
我们开发了TestMachine，因为我们看到许多团队在充满理论漏洞的AI报告中挣扎，这些漏洞从未得到修复，因为没有人知道哪些漏洞实际上是重要的。
我们开发了两个工具。Azimuth针对您的智能合约进行真实的攻击模拟，仅在攻击实际成功时才会显示漏洞。再也不必在虚假警报中苦苦挣扎。Token Custody在上线后持续监控链上代币的行为，并在风险状况发生变化时提醒您——这很有用，因为代币在部署后几天或几周内的行为往往会有所不同，尤其是在升级或集成启动时。
有趣的技术部分是，我们在一个分叉链环境中使用强化学习执行模拟，因此我们可以针对您的合约重放真实世界的状态，而不是进行静态分析的猜测。
Coinbase和许多审计机构都在使用它。欢迎对我们的做法提出问题。也希望听到任何从事智能合约安全工作的人的反馈。或者去看看（我们刚刚添加了免费试用）。
大家好，我是来自Staff Engineer和Mozilla.ai的Peter，我想分享我们关于共享智能体学习标准的想法，从概念上来说，这似乎很容易融入我的思维模型，就像是智能体的Stack Overflow。
这个项目旨在探索是否可以让智能体（任何智能体，任何模型）提出“知识单元”（KUs），作为基于在使用过程中遇到的难点的标准架构，并主动查询现有的KUs，以获取可以验证和确认其有用性的见解。
目前这仍然是一个概念验证（PoC），在代码库中有一个更宏伟的提案，我们正在尝试从本地使用迭代到团队层面，理想情况下最终能够建立某种公共资源。
在团队层面（请参见我们的Docker Compose示例），您的编码智能体被配置为指向团队的API地址，以便将KUs发送到那里——这些KUs可以通过浏览器中的用户界面（HITL）由人类进行审核，然后才能在您团队的其他智能体的查询中出现。
即使在内部的各种代码库中本地使用，我们也学到了很多，不仅是在它生成的KUs方面，还有从用户体验的角度来看，努力使其易于使用并在浏览器仪表板中批准KUs。未来还有更大、更复杂的问题需要解决，比如数据隐私、治理等，但目前我们非常专注于让人们在日常工作中快速看到一些价值。
技术栈：
* 技能 - markdown
* 本地Python MCP服务器（FastMCP） - 管理本地SQLite知识库
* 可选的团队API（FastAPI，Docker）用于在组织内共享知识
* 作为Claude Code插件或OpenCode MCP服务器安装
* 默认本地优先；您的知识保留在您的机器上，除非您通过在配置中设置地址选择团队同步
* 开源软件（Apache 2.0许可证）
以下是一个看似简单的例子，当我请求Claude Code编写GitHub操作时，它经常使用多个主要版本过时的操作，因为它的训练数据。在这种情况下，我告诉智能体我在审查它创建的GitHub操作YAML文件时看到的内容，它提议将知识单元持久化。下次在一个完全不同的代码库中使用OpenCode和OpenAI模型时，cq技能在开始任务之前就被使用，并获取了关于训练数据中主要版本的难点信息，并主动检查了GitHub，使用了正确的最新主要版本。然后它确认了KU，增加了置信度分数。
我想有些人可能会说：好吧，你的代码库中有一个CLAUDE.md，或者在~/.claude/中，但我们希望的不止于此，我们希望这对所有智能体、所有模型都可用，也许更重要的是，我们不想在AGENTS.md或CLAUDE.md中填满大量导致不可预测行为的规则，这些是针对特定任务的目标信息，似乎更有用。
现在可以作为Claude Code和OpenCode的插件本地安装：
```
claude plugin marketplace add mozilla-ai/cq
claude plugin install cq
```
这允许您在本地~/.cq/local.db中捕获数据（数据不会发送到其他地方）。
我们非常希望能收到对此的反馈，代码库是开放和公开的——欢迎在GitHub上提出问题。我们在一些社交媒体平台上发布了链接到博客文章（如下），如果您觉得有用或遇到问题，请随时回复我们，我们希望让这个项目对每个人都能访问。
博客文章的完整故事： [https://blog.mozilla.ai/cq-stack-overflow-for-agents](https://blog.mozilla.ai/cq-stack-overflow-for-agents)
GitHub代码库： [https://github.com/mozilla-ai/cq](https://github.com/mozilla-ai/cq)
再次感谢您的时间。
该项目将多个独立程序启动到一个共享的虚拟地址空间中，同时仍然表现得像是独立的进程（独立的二进制文件、全局变量和生命周期）。当线程进程共享其地址空间时，指针在它们之间是有效的，而无需对良好行为的Linux二进制文件进行代码更改。
与线程不同，每个线程进程都是一个独立且半隔离的进程。与基于dlopen的插件系统不同，线程进程运行传统的可执行文件，并包含`main()`函数。与POSIX进程不同，由于它们共享相同的地址空间，指针在线程进程之间仍然有效。
这意味着像`std::string`或`std::unordered_map`这样的惯用指针数据结构可以在线程进程之间传递并直接访问（需考虑常规的数据竞争问题）。
这实现了一种介于pthreads和多进程共享内存IPC之间的编程模型。该实现依赖于在加载时引导ASLR和虚拟地址布局，并实现用户空间的`exec()`类比，以及对线程进程文件描述符、信号等的仔细操作。它完全在非特权的用户空间代码中实现：<<a href="https://github.com/jer-irl/threadprocs/blob/main/docs/02-implementation.md" rel="nofollow">https://github.com/jer-irl/threadprocs/blob/main/docs/02-imp...</a>>。
有一个简单的演示展示了“跨线程进程”内存解引用，地址为<<a href="https://github.com/jer-irl/threadprocs/tree/main?tab=readme-ov-file#demo" rel="nofollow">https://github.com/jer-irl/threadprocs/tree/main?tab=readme-...</a>>，包括一个高层次的图示。
这与具有共享内存的多进程系统相关（通常是环形缓冲区或扁平表）。这些设计通常需要序列化或复制，并且往往不符合惯用的C++或Rust数据结构。基于指针的数据结构不能直接传递。
存在显著的限制和边缘情况，目前尚不清楚这是否是一个实用的模型，但该项目探索了一种放宽传统进程内存边界的方法，同时仍然将系统构建为独立启动的组件。
DietPi 是一个基于 Debian 的轻量级 Linux 发行版，专为单板计算机（SBC）和服务器系统设计，同时也提供安装桌面环境的选项。它以最小化的镜像形式发布，但允许通过一系列基于控制台的对话框和脚本安装完整且可立即使用的软件栈。
源代码托管在 GitHub 上： https://github.com/MichaIng/DietPi
官方网站可以在这里找到： https://dietpi.com/
维基百科： https://de.wikipedia.org/wiki/DietPi
该项目于 2026 年 3 月 22 日发布了 DietPi v10.2 版本。
此版本的亮点包括：
- Immich 和 Immich 机器学习：新软件包
- RustDesk 客户端：新软件包
- uv：新软件包
- DietPi-Software：新增选项以轻松安装图形桌面
- DietPi-Config：新增选择温度传感器的选项
- myMPD 和 UrBackup：支持 Debian Trixie 上的 ARMv6
- Amiberry：新版本 Amiberry v8.0.0，内嵌 SDL3 v3.4.2
- 修复了 phpBB、K3s、MPD、LXQt、PaperMC、Node-RED、Moonlight（GUI）和 Home Assistant 的问题
完整的发布说明可以在这里找到： https://dietpi.com/docs/releases/v10_2/