Stigmergy开源团队知识库：三招破解Wiki维护难题
内容提要
Stigmergy是一个团队知识管理系统，基于Karpathy的“单人wiki”理念，利用AI图书管理员自动归档团队捕获的内容（如Slack反应、Agent输出）为Wiki页面。系统通过不可变证据链、矛盾标记和可见性策略确保可信度，支持多人多AI并发写入，无需审批。部署简单，测试覆盖1100多个，但存在扩展性和生产环境适应性的未解问题。
延伸解读
从个人到团队的扩展挑战
Stigmergy将Karpathy的个人Wiki理念扩展到团队，但多用户、多AI代理并发写入带来了身份认证、可见性控制、并发写入等新问题。系统通过不可变证据链和序列化写入器解决了部分问题，但扩展性仍是未知数。当Wiki规模从几百页增长到几万页时，AI图书管理员的归档质量和园丁的修复效率能否保持，文中并未给出答案。
矛盾标记的实用价值
传统知识库面对矛盾信息时，往往要么武断选择一方，要么让读者自行猜测。Stigmergy采用矛盾标记，将两个声明及其来源、日期并列展示，不替用户做判断。这种设计鼓励用户基于完整证据链自行决策，并将决策结果作为新捕获提交，从而逐步解决矛盾。这种“诚实处理矛盾”的方式，有助于提高信息的可信度和决策的透明度。
可见性策略的安全考量
Stigmergy的可见性策略强调“受限证据永不用于生成更广泛受众可读的页面”，确保用户只能看到其权限范围内的信息。系统通过组和默认受众配置ACL，未知页面和隐藏页面从外部看起来完全一致，避免信息泄露。此外，云端不存储Google凭证，客户端不接触对象存储密钥，进一步保障了数据安全。
评估指标的局限性
Stigmergy的评估报告显示检索Recall@5、回答诚实度等指标均为1.00，看似完美。但测试集可能只覆盖了清晰明确的事实性查询，而生产环境中的查询往往更模糊、更复杂。随着知识库规模扩大，这些指标能否维持尚不确定。因此，1.00的分数应视为在特定测试条件下的表现，而非绝对保证。
Q&A
Stigmergy是什么？它的核心理念是什么？
Stigmergy是一个团队知识管理系统，基于Andrej Karpathy的“单人wiki”理念，利用AI图书管理员自动归档团队捕获的内容（如Slack反应、Agent输出）为Wiki页面。其核心理念源自生物学中的“协作激励”概念，比喻团队像蚂蚁一样通过留下痕迹来协作，每个痕迹都是一次捕获，AI图书管理员负责整理成Wiki页面。
Stigmergy如何解决传统知识管理工具的问题？
传统知识管理工具本质是垃圾堆叠，使用RAG每次提问都重新从原始资料翻找答案，没有积累。Stigmergy通过AI图书管理员自动归档，将捕获的内容编译成结构化的Wiki页面，知识被编译一次后一直存在，下次提问无需重新翻找，解决了重复检索和知识积累的问题。
Stigmergy的写入路径是怎样的？
Stigmergy的写入路径有五步：捕获（适配器完成身份认证，获取字节）、队列（生成CaptureEnvelope，Postgres队列持久化、带租约、幂等）、写入（序列化写入器提取文本，渲染不可变源页面，图书管理员生成FilingPlan，状态流转为queued → processing → landed | failed）、记忆（知识仓库是Git加Markdown，Postgres只存运行状态和可重建索引）、读取（MCP工具和@brain供使用，Webhook增量索引，每晚全量重建）。
Stigmergy如何处理知识库中的矛盾信息？
Stigmergy将两个矛盾的声明都保留，并在页面上添加醒目的矛盾标记，注明具体内容、日期和来源文件。管理员可以提交新的捕获来解决矛盾，但矛盾标记只有在新的证据真正解决它之后才会消失。系统不判断谁对谁错，只把矛盾摆出来，附上完整证据链，让用户自己判断和决策。
Stigmergy的可见性策略是什么？
Stigmergy的可见性策略核心原则是：受限的证据永远不会被用来生成更广泛受众可读的页面。每个身份都有组和默认受众，页面的ACL要么是null（全员可见），要么是组列表。读写使用同一套可见性策略，受限捕获生成受限的伴随页面，开放页面绝不会从更窄的证据重写。未知页面、隐藏页面等从外部看起来完全一样，系统不会提示有内容但不可见。
Stigmergy的测试和评估结果如何？
Stigmergy代码库有1100多个测试，覆盖真实的Postgres和Git，75%的覆盖率门槛。2026年8月24日的评估结果：检索Recall@5等于1.00，回答诚实度等于1.00，回答groundedness等于1.00，错误前提反驳等于1.00。使用的模型包括deepseek/deepseek-v4-flash、z-ai/glm-5.2、qwen/qwen3-embedding-8b等，通过OpenRouter调用，零数据保留。
Stigmergy的部署方式是怎样的？
Stigmergy用一个镜像部署三个Fly进程组：app进程跑HTTP服务器，处理MCP over HTTP、上传、索引webhook、后台；worker进程跑唯一的写入器和定时园丁；slack进程跑Socket Mode适配器。快速开始需要Python 3.12以上、uv、Docker，克隆仓库后执行make venv、make db-up、make test、make lint。部署和本地跑用同一套东西。
Stigmergy存在哪些未解决的问题？
Stigmergy存在扩展性和生产环境适应性的未解问题。仓库中有一个ops包负责“受保护的非生产重置”，但文档未解释其用途。评估报告显示检索Recall@5等于1.00，但测试集覆盖的查询类型未知，生产环境能否维持未知。当Wiki从几百页膨胀到几千页、几万页时，图书管理员Agent的归档质量和园丁的自动修复效率能否保持，README中没有答案。
