最新

大家好，我是 Mozilla.ai 的 Staff Engineer Peter，我想分享我们关于共享智能体学习标准的想法。从概念上讲，它很容易融入我的思维模型，就像是智能体的 Stack Overflow。<p>该项目试图看看我们是否能让智能体（任何智能体，任何模型）提出“知识单元”（KUs）作为标准模式，基于它在使用过程中遇到的问题，并主动查询现有的 KUs，以获取见解，这些见解可以被验证和确认是否有效。<p>目前这还是一个 PoC（概念验证），仓库里有一个更宏大的提议。我们正尝试从本地使用开始迭代，逐步扩展到团队级别，理想情况下最终能建立某种公共资源库。<p>在团队级别（参见我们的 Docker compose 示例），你的编码智能体被配置为指向团队的 API 地址，以便在那里发送 KUs。这些 KUs 可以在浏览器中的 UI 上经过人工审核（HITL），然后才能被团队中的其他智能体在查询中使用。<p>即使在内部对各种仓库进行本地使用时，我们也学到了很多东西，不仅包括它生成的 KUs 的类型，还包括从用户体验的角度来看，如何让用户更容易使用它，以及如何在浏览器仪表板中批准 KUs。未来还有更大的、更复杂的问题需要解决，例如数据隐私、治理等，但现在我们非常专注于让人们能够快速看到它在日常工作中的价值。<p>技术栈：<p>* 技能 - markdown<p>* 本地 Python MCP 服务器 (FastMCP) - 管理本地 SQLite 知识库<p>* 可选的团队 API (FastAPI, Docker) 用于在组织内共享知识<p>* 作为 Claude Code 插件或 OpenCode MCP 服务器安装<p>* 默认本地优先；除非你选择通过在配置中设置地址来进行团队同步，否则你的知识将保留在你的机器上<p>* 开源 (Apache 2.0 许可)<p>这里有一个例子，当要求 Claude Code 编写一个 GitHub action 时，它经常使用过时的 action，因为它的训练数据。在这种情况下，我告诉智能体我审查它创建的 GitHub action YAML 文件时看到的情况，它提出了要持久化的知识单元。下次在完全不同的仓库中使用 OpenCode 和 OpenAI 模型时，cq 技能会在开始任务之前被使用，它获取了关于训练数据中主要版本问题的相关信息，并主动检查了 GitHub，使用了正确、最新的主要版本。然后它确认了 KU，增加了置信度分数。<p>我想有些人可能会说：你的仓库里有一个 CLAUDE.md，或者在 ~&#x2F;.claude&#x2F; 里。但我们的目标更远大，我们希望它对所有智能体、所有模型都可用，也许更重要的是，我们不想用大量规则来填充 AGENTS.md 或 CLAUDE.md，这些规则会导致不可预测的行为，这是针对特定任务的定向信息，看起来更有用。<p>目前，它可以作为 Claude Code 和 OpenCode 的插件在本地安装：<p>claude plugin marketplace add mozilla-ai&#x2F;cq claude plugin install cq<p>这允许你在本地 ~&#x2F;.cq&#x2F;local.db 中捕获数据（数据不会发送到任何其他地方）。<p>我们很乐意收到关于此的反馈，该仓库是开放和公开的——欢迎提出 GitHub 问题。我们已在一些社交媒体平台上发布了博客文章的链接（如下），如果你觉得它有用，或者遇到了问题，请随时回复我们，我们希望让每个人都能使用它。<p>完整故事的博客文章：<a href="https:&#x2F;&#x2F;blog.mozilla.ai&#x2F;cq-stack-overflow-for-agents&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.mozilla.ai&#x2F;cq-stack-overflow-for-agents&#x2F;</a> GitHub 仓库：<a href="https:&#x2F;&#x2F;github.com&#x2F;mozilla-ai&#x2F;cq" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mozilla-ai&#x2F;cq</a><p>再次感谢你的时间。

该项目将多个独立的程序启动到单个共享的虚拟地址空间中，同时仍然表现得像独立的进程（独立的二进制文件、全局变量和生命周期）。当 threadproc 共享其地址空间时，指针在它们之间是有效的，对于行为良好的 Linux 二进制文件来说，无需更改代码。 与线程不同，每个 threadproc 都是一个独立的、半隔离的进程。与基于 dlopen 的插件系统不同，threadproc 运行具有 `main()` 函数的传统可执行文件。与 POSIX 进程不同，指针在 threadproc 之间仍然有效，因为它们共享相同的地址空间。 这意味着像 `std::string` 或 `std::unordered_map` 这样的惯用基于指针的数据结构可以在 threadproc 之间传递并直接访问（需要考虑通常的数据竞争问题）。 这实现了一种介于 pthreads 和多进程共享内存 IPC 之间的编程模型。 该实现依赖于在加载时定向 ASLR 和虚拟地址布局，并实现用户空间模拟的 `exec()`，以及对 threadproc 文件描述符、信号等的仔细操作。它完全在非特权用户空间代码中实现：&lt;<a href="https:&#x2F;&#x2F;github.com&#x2F;jer-irl&#x2F;threadprocs&#x2F;blob&#x2F;main&#x2F;docs&#x2F;02-implementation.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jer-irl&#x2F;threadprocs&#x2F;blob&#x2F;main&#x2F;docs&#x2F;02-imp...</a>&gt;。 有一个简单的演示，演示了“跨 threadproc”内存解引用，位于 &lt;<a href="https:&#x2F;&#x2F;github.com&#x2F;jer-irl&#x2F;threadprocs&#x2F;tree&#x2F;main?tab=readme-ov-file#demo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jer-irl&#x2F;threadprocs&#x2F;tree&#x2F;main?tab=readme-...</a>&gt;，包括一个高级图表。 这与具有共享内存的多个进程的系统（通常是环形缓冲区或平面表）相关。这些设计通常需要序列化或复制，并且倾向于远离惯用的 C++ 或 Rust 数据结构。基于指针的数据结构不能直接传递。 存在明显的限制和边缘情况，并且不清楚这是否是一个实用的模型，但该项目探索了一种在仍然将系统构建为独立启动的组件的同时，放松传统进程内存边界的方法。

DietPi 是一款轻量级的、基于 Debian 的 Linux 发行版，适用于 SBC（单板计算机）和服务器系统，也可以选择安装桌面环境。它以最小化镜像的形式发布，但允许通过一组基于控制台的 shell 对话框和脚本安装完整且即用的软件栈。 源代码托管在 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/

我刚刚构建了这个名为“故事训练师”的自助写作工具（测试版），它会逐步引导你了解故事的核心要素和情感冲突。<p>几个月前，我参加了一个由专业电视编剧主持的免费写作研讨会，做了笔记，最终把最重要的经验教训融入了这个工具，因为我希望它能让像我这样的初学者在整个写作过程中感觉不那么不知所措。<p>在这里查看。很想知道这是否有用。目前这只是一个正在开发中的 GitHub 页面，所以欢迎任何和所有反馈，以使其更有用。