技术知识库 · 工具评测 · · 国科智飞 Gavin
ThoughtDAG：把上下文变成可编辑的思维图谱
Wires are the context：把 LLM 对话做成可编辑的图谱，连进节点的线决定模型下一轮看到什么；本地优先，可索引多个编程代理的会话。
ThoughtDAG 是开发者 chenxiachan 开源的上下文编辑工具，TypeScript 编写，MIT 许可。核心规则一句话：Wires are the context——模型下一轮看到什么，取决于哪些"线"接进了节点；编辑图谱，就是编辑模型的记忆。它把自己定位成"可编辑的思维图谱 + 上下文编排器"，不是又一个聊天客户端，更不是自主 Agent。项目 2026 年 2 月创建，9 月仍在活跃更新，约 390 star。
理解它的最好方式是对比：线性聊天里上下文走单一时间线；思维导图/白板的边只是帮人整理；分叉对话画布通常只继承一条分支；工作流画布的边用来跑任务和数据；RAG/自动记忆由系统替你检索。ThoughtDAG 的不同在于——边真的改变模型输入，多个路径可以合并或剪掉，选择是可见、可编辑的，而且能作为真实回合执行。它管的是"模型下一轮看到什么"，不是"怎么整理你的想法"。
能力与亮点
无限画布 + 节点连线。 对话长成图谱。官方示例里有个可复现的演示：删掉一条噪音边，重问同一个 prompt，得到更干净的答案。这是"上下文修复"最直观的操作化。
作为 DeepSeek Harness（DSH）插件运行。 在 DSH 的 Web UI 里以"对话 | 思维图"切换视图：画布决定 harness 下一轮看到什么，harness 负责执行这一轮，答案流回节点、回合留在会话日志里。安装命令是 dsh plugin --profile web add dsh-thoughtdag，需要 Node 22.19+ 与 DSH 0.1.2-rc+。插件自带画布，不需要另装一个 ThoughtDAG 客户端。
Session Atlas。 把散在多个编程代理（Claude Code、Codex 等）与 harness 自身的会话拉进统一索引，打开任意一个当图谱实时跟随；也可以从画布选模型，把提问作为真实 harness 回合执行（含工具）。会话尾部的 follow-up 还能被镜像到画布上继续——这意味着一次在终端里开始的讨论，可以在图谱里接着往下走。
跨代理定位上下文。 npx thoughtdag why src/lib/api.ts 或 find "某句话" 可以搜索本地所有代理会话，定位到相关回合；还提供只读 MCP 工具（why_check/why_file/find/recall_turn），Agent 能直接调用。换机器或清理会话目录，历史索引会受影响，这点要有心理准备。
导出思维形状。 不同工作方式可以导出不同形态的 Thought Map：深挖单线的、五个探索分支的、三周调研的、文献综述季的。把"这段时间的思考长什么样"变成可保存的对象，而不是散落的聊天记录。
引用与回放。 上游编辑会标记哪些答案因此失效，按依赖顺序重放，重放前先估 token——这是把"改上下文"变成可管理操作的关键机制。
读论文成图。 针对文献段落提问，答案带页码落在画布上，p.N 芯片可跳回原文。
本地优先。 数据都留本机，模型走 OpenAI 兼容端点或本地 Ollama，PDF 不出机器；支持备份兼容与 Markdown 导出，作为永久逃生口。
官方有一份上下文干预的 Pilot 基准。 项目方公布的结果（9 个模型、1485 次测试）：上下文不只会随对话变长而褪色，一个错误陈述会流入后续回答，拖累之后每个结论的真值性；只删引入错误的那一条消息往往不够，因为后续回合仍带着它，修复需要清理受影响段落或让模型重写。这条结论解释了很多人的体感——"为什么改了前面的设定，后面还是错的"。它也为"管理上下文而不只是积累上下文"提供了论据：上下文不是越长越好，能不能管住错误传播才决定答案对不对。
局限与坑
它是 DSH 生态的插件，不是独立产品。 没装 DeepSeek Harness 就用不起来，且依赖 DSH 0.1.2-rc+，本身还在 rc 阶段。对不用 DSH 的人来说，它的多数价值发挥不出来。
编辑图谱需要人投入。 哲学是 human in the loop, model on the wires——模型不会替你重画图。期望"自动整理对话"的人会失望，这是设计选择，不是缺陷，但要提前认清：它是一款需要用户主动投入的工具，自动化程度是刻意做低的。
认知负担真实存在。 节点、连线、合并、剪枝是一套新的操作习惯，个人上手尚可，团队推广有学习成本。
基准是项目方自研的 Pilot。 样本与评分口径未来可能调整，适合作为思路参考，不适合当学术结论引用。
图谱结构导不出去。 Markdown 导出是逃生口，但连线语义无法完整还原——数据主权在你手里，迁移时仍要接受结构损失。
适用场景
- 长对话、长调研被上下文漂移困扰，需要"删掉一条错误信息再重问"的人；
- 同时使用多个编程代理，需要跨会话找"哪次讨论过这个文件或概念"；
- 做文献综述、深度调研，要求答案与原文页码可追溯；
- 在意数据本地性，不想把 PDF 与对话上传云端；
- 研究上下文管理机制，想亲手验证"编辑上下文如何影响输出"的开发者。
选型建议
先判断你的痛点是不是"上下文"：如果是聊天记录太长导致答案变差，ThoughtDAG 的"编辑连线→改变下一轮输入"是直接解法，值得装 DSH 试一周。如果你要的是双链笔记或知识库整理，它不对口，别绕路。
落地建议从小处开始：先用 why/find 把跨代理会话搜起来，尝到"找得到"的甜头；再在画布上删一条噪音边，复现一次上下文修复。把它当作会长大的工作台，而不是一次搬迁——定期用 Markdown 导出做备份，同时接受图谱结构无法完整带走的现实。对个人研究者和深度调研场景，它的投入产出比最清晰；对流程化、追确定性的团队，先小范围试点再决定是否推广。MIT 许可，可自托管使用。