Stigmergy 是一个团队知识管理系统，其核心理念源自 Andrej Karpathy 的“单人 wiki”设想。项目名称“Stigmergy”（源自生物学的“协作激励”概念）比喻团队像蚂蚁一样，通过在环境中留下“痕迹”来协作——这里的每个“痕迹”都是一次捕获（Slack 中的反应、Agent 完成任务后的输出），而“图书管理员 Agent”则负责将这些痕迹整理成一篇篇 Wiki 页面。
简单来说：Stigmergy = 团队版 Karpathy Wiki + AI 图书管理员 + 全文检索 + 权限控制。
电脑里存了三千份文档，还是找不到三个月前那条关键结论！
这不是你记性差，是知识管理工具全都在骗你。它们让你拼命往里塞东西，塞得越多你越找不到。每次搜索都像从零开始翻垃圾堆，问同一个问题要问五遍。单兵作战已经够呛，团队协作更是噩梦，十个人和十个AI代理往同一个知识库里写东西，权限打架、版本冲突、谁改了什么全靠嘴说。
Stigmergy把个人知识管理那套逻辑搬到了团队场景，用AI图书管理员自动归档，用不可变的证据链保证可信，用可见性策略控制谁能看到什么。最狠的是，它能让十个人和十个AI同时往一个知识库里写东西，还不需要任何人审批排队。
这套系统的核心思路来自Andrej Karpathy的LLM Wiki设想。Karpathy是OpenAI创始成员、前特斯拉AI总监，2026年4月在X上公开了自己的个人知识管理方法，引爆了AI圈。他提出让大模型当你的全职知识管家，把散乱的原始素材编译成结构化的Markdown Wiki，而不是每次提问时临时检索拼凑答案。Stigmergy把这个模式从一个人扩展到整个团队——蚂蚁通过改变环境来协调彼此，而不是直接对话。
为什么你塞进知识库的东西越多，越找不到想要的那一条
传统知识管理工具的本质是垃圾堆叠。你把文档、会议记录、Slack消息往里倒，系统给你做个关键词索引，搜索时把包含关键词的片段拼在一起吐出来。这叫RAG，检索增强生成。
这套逻辑有个致命缺陷：每次提问，大模型都得重新从原始资料里翻找答案。问一个需要综合五份文档的问题，模型就得把五份文档的相关片段重新拼一遍。昨天拼过一遍，今天再问一遍，明天还得拼一遍。没有任何积累。
Karpathy管这叫“每次都在重新发现知识”。你往知识库里扔了一千份文档，系统没有真正“理解”过任何一份，它只是在需要的时候临时去翻。
一个人用这套逻辑已经够痛苦了。团队用？灾难。
一个人写Wiki，循环很简单：你读东西、你总结、你写进去、你再用。一旦变成多个人和多个AI代理同时往同一个Wiki里写，你立刻面临身份认证、可见性控制、并发写入、二进制证据存储、Slack集成、审计追踪等一系列问题。这些问题单个拎出来都不难，但堆在一起就是一座大山。
更麻烦的是，人写的东西和AI写的东西混在一起，谁改了什么、依据是什么、该让谁看见，全部乱成一锅粥。
蚂蚁不聊天，却能造出比你公司Wiki更复杂的结构
Stigmergy这个词来自生物学，由法国昆虫学家Pierre-Paul Grassé发明，用来解释白蚁的筑巢行为。词根是希腊语的stigma（标记）和ergon（行动），意思是一个生物在环境中留下的痕迹会刺激另一个生物采取行动。
最典型的例子是蚂蚁。一只蚂蚁找到食物，回巢的路上留下信息素。其他蚂蚁闻到信息素就会沿着这条路走，边走边补充信息素。路越走越热闹，信息素越积越浓，整个蚁群不需要任何蚂蚁发号施令，就能找到最短路径。
蚂蚁不聊天，不开会，不审批。它们只是往环境里扔痕迹，然后跟着痕迹走。
Stigmergy这套系统把同样的逻辑搬到了知识管理上。每一次捕获都是一条痕迹——人在Slack里点了一个:brain:表情反应，AI代理在Claude Code里完成了一个任务，管理员在后台上传了一份文件。所有这些痕迹进入同一个队列，一个AI图书管理员跟着痕迹走，Wiki就自然生长出来了。
没有人审批队列。
一次捕获就是一块不可篡改的砖，谁也改不了已经发生的事情
Stigmergy的写入路径有五步。
第一步是捕获。适配器完成身份认证，获取字节。本地文件和私有Google Drive文档在上传之前，始终留在你的机器上。云端永远看不到你的Google凭证，客户端永远看不到对象存储的密钥。
第二步是队列。每个适配器生成统一格式的CaptureEnvelope。Postgres队列是持久化的、带租约的、按actor和client key幂等的。翻译成人话：不会丢、不会乱、重复提交也没事。
第三步是写入。一个序列化的写入器提取文本、渲染不可变的源页面，然后让图书管理员生成一份FilingPlan。只有所有关卡都通过，分支才会推进。状态流转是：queued → processing → landed | failed。没有人在中间审批，没有待办清单，没有“等领导点头”。
第四步是记忆。知识仓库就是纯粹的Git加Markdown。Postgres只存运行状态和可重建的索引，永远不是第二个Wiki。Git是真相，Postgres是缓存，缓存可以随时推倒重建。
第五步是读取。五个MCP工具供AI代理使用，@brain供人使用，一套可见性策略。Webhook做增量索引，每晚全量重建保证收敛。
整个流程的核心原则是：一次操作，一个提交，一条变更记录，带着精确的补丁。谁在什么时候改了什么，一清二楚。系统崩溃后重启，通过提交SHA来核对状态，绝不用第二次提交覆盖第一次。
AI图书管理员自己决定怎么归档，不需要你审批
这套系统里最反常识的设计是：图书管理员Agent拥有创建、重写、整合、删除页面的全部权限，不需要任何人批准。
听起来很吓人对吧？让一个AI随便删你的东西？
但仔细想想，你团队里的Wiki为什么永远是烂的？因为没人愿意维护。写新内容的人只管往里倒，整理的人没有，删旧内容的人更没有。Wiki越积越臃肿，信息越堆越混乱，最后没人看，没人信，没人用。
Stigmergy的逻辑是：既然人类不愿意做维护工作，就让AI来做。图书管理员负责把捕获的内容整理成Note（笔记）和Concept（概念）。Note是上下文结论、决策或事件；Concept是持久性的解释性知识。两者都带有成熟度标记：seed → developing → mature → evergreen。
源页面永远不可变，存在sources目录下。图书管理员可以改Note和Concept，但永远不能改Source。证据就是证据，进来了就不能动。
那要是图书管理员犯错怎么办？系统里有一个定时运行的“园丁”，通过同样的关卡自动修复。不需要人工待办清单，不需要开会讨论“谁来修一下Wiki”。系统自己发现问题，自己解决问题，解决不了就诚实标记出来。
两个来源各说各话，系统不帮你选边站，把矛盾摊在台面上
知识管理最头疼的问题不是找不到信息，而是找到的信息互相矛盾。
销售说客户续约预算是12万欧元，财务说预算是9.5万欧元。传统系统会怎么办？要么选一个你“觉得”对的塞进去，要么两个都留着让读者自己猜。
Stigmergy的处理方式很直接：把两个声明都保留，在页面上加一个醒目的矛盾标记。标记里注明两个声明的具体内容、日期、来源文件。管理员后续可以提交新的捕获来解决这个矛盾，但矛盾标记只有在新的证据真正解决了它之后才会消失。
系统不替你判断谁对谁错，它只负责把矛盾摆在你面前，附上完整的证据链。你看到矛盾，自己判断，自己决策，然后把决策结果以一次新捕获的形式提交回去。
这就是“诚实处理矛盾”。不粉饰，不掩盖，不替用户做价值判断。
实体的处理也遵循同样的逻辑。实体是不透明的UUID，带着范围化的、有来源的名称声明。事实存在于Note和Concept里，describe_entity在读取时把它们组合在一起。合并需要共享的外部ID或来源中的精确断言，相似性本身不起作用。两个实体看起来再像，没有硬证据就不能合并。
你看不到的东西，永远不会被用来回答你的问题
Stigmergy的可见性策略有一个核心原则：受限的证据永远不会被用来生成更广泛受众可读的页面。
每个身份——无论是人还是token持有者——都有组和默认受众，在ops/identities.json里配置。页面的ACL要么是null（全员可见），要么是一个组列表。brain-admins不受任何限制。
读写使用同一套可见性策略。受限捕获生成受限的伴随页面，开放页面绝不会从更窄的证据重写。你看不到的东西，永远不会出现在你的搜索结果里，也永远不会被用来回答你的问题。
未知页面、隐藏页面、未授权页面、实体和捕获，从外部看起来完全一样。系统不会告诉你“这里有东西但你看不了”，它直接让你看不到。
Bearer token来自stigmergy-issue-token，服务端只存SHA-256哈希。云端永远看不到Google凭证，客户端永远看不到对象存储。
1100个测试告诉你，这套系统不是玩具
Stigmergy的代码库有1100多个测试，覆盖真实的Postgres和Git，75%的覆盖率门槛。
2026年8月24日的评估结果：检索Recall@5等于1.00，回答诚实度等于1.00，回答groundedness等于1.00，错误前提反驳等于1.00。四个1.00意味着什么？意味着系统在测试集上每一次检索都命中了正确答案，每一次回答都有据可查，每一次面对错误前提都能正确反驳而不是顺着胡说。
使用的模型阵容：归档和语义修复用deepseek/deepseek-v4-flash，带引用的回答用z-ai/glm-5.2，嵌入用qwen/qwen3-embedding-8b（2560维），OCR用qwen/qwen3-vl-8b-instruct。所有模型通过OpenRouter调用，零数据保留。直接使用Anthropic、OpenAI或Gemini的凭证会被拒绝。
这不是一个玩具项目。这是一个在生产环境里跑的系统。
同样的问题问五遍，这套系统能让你从第三遍开始闭嘴
Karpathy在描述LLM Wiki时说过一句话：你打开一个窗口让LLM Agent工作，另一边打开Obsidian浏览结果。LLM做编辑，你浏览——跟着链接走，看图谱，读更新后的页面。Obsidian是IDE，LLM是程序员，Wiki是代码库。
Stigmergy把这个模式从一个人扩展到整个团队。你在Slack里@brain问一个问题，系统在可见范围内检索，返回带验证引用的答案。如果提问者能看到比频道更多的内容，额外信息会以私信方式跟进。你在Claude Code里说一句“把结论存到大脑里”，桥接器提交文本，Worker提取内容、归档。你说“归档~/Downloads/board-deck.pdf”，桥接器上传字节，Worker提取文本、OCR扫描页面、归档。你说“捕获https://docs.google.com/document/d/…”，本地Google OAuth导出DOCX并上传。
知识被编译了一次，就一直在那里。下次再问同样的问题，系统不需要重新翻五份文档。答案已经在了，引用已经在了，矛盾已经标记了。
一个镜像三个进程，部署比你想的简单
Stigmergy用一个镜像部署三个Fly进程组。app进程跑HTTP服务器，处理MCP over HTTP、上传、索引webhook、后台。worker进程跑唯一的写入器和定时园丁。slack进程跑Socket Mode适配器，单活跃实例。
快速开始：Python 3.12以上、uv、Docker。克隆仓库，make venv，make db-up启动Postgres加pgvector和MinIO，make test，make lint。索引知识仓库然后通过stdio提供服务。
部署和本地跑用的是一套东西。
但有一个问题还没解决
Stigmergy的仓库布局里有一个包叫ops，负责“受保护的非生产重置”。文档里没有解释什么是“非生产重置”，也没有说明什么情况下需要重置。
这让我想起Karpathy在gist里写的一句话：这个idea file被设计成可以复制粘贴到你自己的LLM Agent里，Agent会在与你协作的过程中构建出具体实现。换句话说，Karpathy给的是一份蓝图，不是一份施工图。Stigmergy把蓝图变成了施工图，但施工图的某些角落还写着“此处待定”。
更微妙的是，Stigmergy的评估报告显示检索Recall@5等于1.00。在测试集上完美。但测试集覆盖的是什么样的查询？是清晰明确的查询还是模糊含混的查询？是事实性查询还是推理性查询？1.00这个数字在测试集上成立，在生产环境里能维持多久？
Karpathy说知识库会随着每一个新增来源和每一个新增问题变得越来越丰富。丰富的同时，复杂度也在指数级增长。当Wiki从几百页膨胀到几千页、几万页，图书管理员Agent还能保持同样的归档质量吗？园丁的自动修复还能在合理时间内完成吗？这些问题，README里没有答案。