返回首页
24小时热榜
<a href="https://docs.fcc.gov/public/attachments/DOC-420034A1.pdf" rel="nofollow">https://docs.fcc.gov/public/attachments/DOC-420034A1.pdf</a><p><a href="https://www.fcc.gov/document/fcc-adds-routers-produced-foreign-countries-covered-list" rel="nofollow">https://www.fcc.gov/document/fcc-adds-routers-produced-foreign-countries-covered-list</a><p><a href="https://docs.fcc.gov/public/attachments/DA-26-278A1.pdf" rel="nofollow">https://docs.fcc.gov/public/attachments/DA-26-278A1.pdf</a>
大家好，我是来自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数据结构。基于指针的数据结构不能直接传递。
存在显著的限制和边缘情况，目前尚不清楚这是否是一个实用的模型，但该项目探索了一种放宽传统进程内存边界的方法，同时仍然将系统构建为独立启动的组件。