上个月我把 AgentCanvas 这个想法落地成了可运行的原型用思维导图作为交互界面和 AI 进行多分支、可回溯的深度对话。所有回复不再是聊天框里滚动的文字而是作为新节点长在思维导图对应的分支下面。这个项目本质上是重新设计人与大模型的交互范式把传统的“一问一答”变成“一图多问”让每一次发散、收敛、追问都有清晰的位置感。如果你平时做产品方案、写技术文档、复盘复杂问题或者单纯受够了聊天记录翻不到头的感觉这篇文章可能对你有用。我会把 AgentCanvas 的完整设计思路、最小实现方案和踩坑记录都摊开来讲。1. 从线性聊天到画布对话AgentCanvas 到底在解决什么1.1 聊天窗口的“三座大山”传统 AI 对话界面默认是一根时间线你问一句AI 答一段你再问一句历史被无限追加。看起来流畅但用久了会发现三个很实际的问题。第一是上下文漂移。一次深度讨论往往涉及几十轮问答用户自己都忘了十分钟前 AI 是怎么断言某件事的模型更是只记得最近的窗口。结果就是聊到后面AI 会把早期已经推翻的假设当作前提回答越来越偏。第二是分支不可操作。聊到某个节点你本来想“沿着另一个方向讨论”但聊天框里你只能放弃当前话题或者手动复制前面的内容重新提问。没有一种天然的手势来表示“这个结论先挂起我们看看另一个方案”。第三是复盘困难。线性聊天做完之后你需要自己重新整理一份纪要否则第二天就不知道那个重要结论到底埋在哪一轮对话里。思维导图则天然具备结构节点就是结论边就是逻辑关系复盘时看整张图就可以了。1.2 为什么思维导图能配得上“深度对话”思维导图的核心能力不是好看而是保持思考的“空间感”。每个主题都是一个可独立发展的分支可以在父节点上任意生长。AI Agent 恰恰需要这种结构当模型被当作一个“Agent”而不是“问答机器”时它需要知道自己当前在哪个目标下、已经得出过什么结论、还有哪些分支没有探索。AgentCanvas 把思维导图当成 Agent 的“工作台”而不是展示板。某个节点发出的指令会被 AI Agent 解析成一项子任务AI 生成的结果不是直接替换当前节点而是在当前节点下挂一个新的子节点。这样AI 的每一次“思考”都变成图上的一次扩展用户随时可以摘除、移动、合并这个分支。这种设计也顺带解决了多轮对话的记忆问题节点本身就是记忆载体。上一轮的结论是节点文本相关依据是子节点用户的质疑是兄弟节点。Agent 不用从一长串聊天记录里找线索它只需要沿树往上找祖先节点就能重建当前讨论的上下文。2. AgentCanvas 的整体架构与设计取舍2.1 先定义一套干净的数据模型任何带画布的 AI 交互第一个要解决的问题都是“图长什么样”。AgentCanvas 的数据模型只有两种元素节点和边。一个节点保存一段独立的“对话单元”至少包含这些字段{ id: node_24fa01, parentId: node_root, kind: user | assistant | tool_result, text: 用成本更低的方案替代当前路由网关, createdAt: 1736123456789, meta: { model: default, tokens: 1240 } }边不需要单独建模因为parentId就已经定义了父子关系。整个画布就是一个森林通常只有一个根节点。我刻意没有把parentId命名为sourceId或targetId因为 AgentCanvas 里的连接关系本质上是“从哪来、往哪长”不是通用图结构。这个简化在后面做撤回和路径回溯时省了非常多事。数据模型定了之后界面上所有操作都能映射成对节点树的操作新建节点、增加子节点、修改节点文本、删除节点子树、调整节点顺序。这五个原子操作已经覆盖了 AgentCanvas 99% 的场景。2.2 Agent 如何在一棵思维导图里“行走”AgentCanvas 最核心的机制是“聚焦节点”。界面上只有一个当前聚焦的节点用户可以在任意节点上双击把它设为焦点并输入一条新的指令。Agent 拿到指令后会构造一段“焦点路径上下文”其实就是从根节点到当前节点的所有节点文本再用摘要压缩后拼到大模型 prompt 里。我用 Python 写过一个非常轻量的上下文聚合函数核心思路如下def build_focus_context(node, tree): path [] current node while current is not None: entry { role: current.kind, content: current.text } path.append(entry) current tree.get_parent(current.id) path.reverse() # 路径可能很长只保留最近 6 个节点更早的节点用摘要替代 if len(path) 6: early_summary summarize_nodes(path[:-6]) path [{role: summary, content: early_summary}] path[-6:] return path这样做的理由是如果每次都把整个思维导图的所有节点塞进 prompt不仅 token 成本呈指数增长而且模型会把大量无关分支当成初始条件反而干扰判断。只沿焦点路径取上下文既保留了“从根到当下的逻辑链”又剔除了旁边分支的噪音。2.3 为什么不用“全历史拼接”这种省事方案我最早的一版 AgentCanvas 就是个简单聊天框每轮把全部历史消息转成 Markdown 列表发给模型。结果跑了不到二十轮token 占用就飙到上万而且模型经常被自己早期一句错误的话带偏。后来我把上下文策略改成“摘要 局部路径”。根节点和第一条指令永远保留中间的非关键分支只保留 AI 自动生成的两行摘要焦点节点之前的一小段路径原样保留。这个改动让同样深度对话的 token 消耗降低了大约 60%回答准确率反而上升了因为模型不必在大量无关信息里做筛选。这里的关键点是上下文不是越多越好而是越对越好。思维导图的本质优势就是能快速定位“对”的上下文。3. 实操过程从 Markdown 到可留存的 AgentCanvas3.1 第一步用 Markdown 定义思维导图很多用户不需要一个复杂的可视化编辑器他们更习惯直接用文本写出想法。为了让 AgentCanvas 的门槛足够低我选择用 Markdown 标题和列表来定义思维导图结构# 产品需求企业知识库 ## 核心用户 ### 新员工 ### 离职交接人员 ## 关键功能 ### 文档检索 ### 权限隔离 ## 风险项 ### 部署成本 ### 数据迁移这种语法足够表达树结构而且所有主流渲染器都能处理。有人问我“Latex 能画思维导图吗”能但用 LaTeX 画图太重了不适合做实时交互。还有人喜欢用 Mermaid 的 mindmap 语法它确实很适合快速预览但 Mermaid 对不规则节点元数据的支持比较弱更新节点后动画也少所以我选择先用 Markdown 作为持久化格式。3.2 第二步把 Markdown 解析成渲染树这一步我自己写了一个 60 行左右的解析函数逻辑很简单按行读取根据 Markdown 标题层级或者列表缩进算出节点的深度然后维护一个栈用来挂父子关系。def parse_markdown_to_tree(text): lines text.splitlines() root {id: root, text: Root, children: []} stack [root] for line in lines: stripped line.strip() if not stripped: continue depth 0 if stripped.startswith(#): depth stripped.count(#) - 1 content stripped.lstrip(#).strip() else: depth len(line) - len(line.lstrip( )) indent_depth depth // 2 content stripped.lstrip(- ).strip() depth indent_depth node {id: generate_id(), text: content, children: []} while len(stack) depth: # 避免层级跳跃 break while len(stack) - 1 depth: stack.pop() stack[-1][children].append(node) if depth len(stack) - 1: stack.append(node) else: stack stack[:depth 1] stack.append(node) return root这里有几个细节需要注意Markdown 列表和标题混用的时候必须统一成同一种深度规则否则无法兼容缩进层级平均会占 2 个空格我自己统一约定为 2 空格导出和导入都按这个标准。如果你的现成文档缩进是 4 空格解析时除以 4 即可。3.3 第三步接入 Agent让 AI 的回复自动成为新节点树结构有了接大模型就顺理成章。用户在当前节点输入指令Agent 先调用build_focus_context拿到上下文然后请求模型生成回复回复内容包装成一个assistant类型的新节点它的parentId指向当前节点。def ask_and_append(session, node_id, instruction): focus_node session.get_node(node_id) context build_focus_context(focus_node, session.tree) prompt context [ {role: user, content: instruction} ] response llm.chat(prompt) new_node { id: generate_id(), parentId: node_id, kind: assistant, text: response, createdAt: now() } session.tree.add_node(new_node) session.emit(node_created, new_node) return new_node真正做产品时还需要考虑异步一次请求可能耗时数秒到几十秒前端要支持节点先出现“等待中”状态收到流式回复后逐字写入节点同时把滚动视图锁定到新节点。我用 WebSocket 做了流式推送后端每生成一个 token 就补到子节点文本里这样用户能直观看到 AI 的“思考生长”过程。3.4 第四步让画布支持拖拽和重组没有拖拽的思维导图只能算展示页。AgentCanvas 里我允许把任意节点拖动到另一个节点下面变成它的子节点也允许把节点拖到画布空白处让它升级为独立分支。拖拽涉及的操作包括截断旧父节点的孩子列表插入新父节点的孩子列表重新计算相关节点的展示层级。因为数据模型是单纯的parentId树所以这步并不复杂def reparent(node, new_parent_id, new_order): old_parent tree.get_parent(node.id) old_parent.children.remove(node.id) node.parent_id new_parent_id new_parent.children.insert(new_order, node.id)真正麻烦的是撤销。任何拖拽都可能改变用户脑中的逻辑结构所以我采用“全量快照”方案每次操作前把整棵树序列化成 JSON 存到内存再定期写入 localStorage 或服务端数据库。撤回时直接恢复到上一个快照。代价是内存占用高一些但胜在实现简单、绝不会出现丢数据的问题。4. 项目落地中的常见问题与排查4.1 节点数量一大画布操作明显卡顿当节点数超过两三百个DOM 渲染和拖拽计算都开始吃力。我试过用 canvas 自研渲染性能确实好但可维护性太差。最后采用折中方案只渲染当前视口内的节点等节点进入视口时再创建对应 DOM关闭了子节点自动展开默认只展示一层子节点需要点击展开才显示更深层级。注意不要为了追求流畅把所有节点一次性挂到 React 组件里。虚拟滚动 按需渲染是思维导图应用的标准解。4.2 AI 回答总是偏离当前分支这是 AgentCanvas 早期最烦人的问题。模型拿到的上下文同时包含很多兄弟节点它可能去回答另一个分支的问题。排查后我发现问题出在 prompt 指令上没有强调“聚焦路径”模型不知道当前应该顺着哪条线走。解决方法是显式标注 focus 节点你现在正在和用户讨论「文档检索」这个子主题。 它的父主题是「关键功能」。 再往上的根主题是「产品需求企业知识库」。 请只围绕当前子主题展开不要跳到父主题或其他分支。这套显式路径让偏题率下降了很多。模型还是不太擅长自己判断图结构里的“当前位置”但只要你把当前路径写明它就能表现得非常听话。4.3 撤回、重试与并发编辑冲突一开始我没有做撤回删掉一个节点后直接就无法恢复用户心态崩了。后来加了快照机制每次 AI 创建节点或拖拽前都会saveSnapshot()。另外如果同一张图画布被多人编辑就需要给每个节点加version字段以服务端版本为准做冲突检测。我做了一个简单的常见问题速查表记录在项目 README 里症状可能原因解决方法画布白屏树数据出现循环依赖解析时检查 parentId 不能是自身或后代AI 回复与当前主题无关上下文没有标注焦点路径构建 prompt 时加入祖先路径撤回后节点丢失快照覆盖旧快照快照按时间戳保存保留最近 50 条拖拽后子节点位置错乱父节点 children 顺序没有更新用insert而不是append保存顺序 index多人编辑同一点后互相覆盖节点缺少版本号每次更新带上version冲突时提示合并这些坑看起来都很基础但每一个都能让项目从“演示版”变回“玩具版”。做工具型产品稳定性和可恢复性比酷炫更重要。5. 值得扩展的方向从单 Agent 到多 Agent 协作5.1 让不同 Agent 扮演图上的不同角色AgentCanvas 的单 Agent 版本已经能承载高质量的深度对话但它的数据结构天然适合多 Agent 协作。你可以为同一个思维导图挂上多个 Agent比如产品 Agent、技术 Agent、风险 Agent。用户在每个节点下可以指定“这个问题让技术 Agent 回答”其他 Agent 的结论则作为旁路节点挂在这个问题的上下文里。多 Agent 协作的最大好处是视角分离。一个负责完整方案设计一个负责挑战方案漏洞两者把结论分别生成在彼此相邻的分支上。用户最后可以比较这些分支的推理自己来做决策。我在模拟“专利相关辅助链接”这类专业场景时用多 Agent 模式把“查资料、分析可行性、生成建议”拆给不同角色执行整个流程的可解释性比单模型一次性输出强得多。5.2 给 Agent 挂上工具节点变成行动按钮思维导图里的每个节点都可以触发外部工具。比如节点内容是“爬取某网页正文”Agent 调用 fetch 工具把结果写回子节点节点内容是“运行一下这段 Python 代码”Agent 调用代码解释器执行结果作为tool_result节点挂载节点内容是“查一下数据库”Agent 调用 SQL 工具并汇总结果。用图结构管理工具调用比传统 Agent 的多轮工具流更直观。因为每一次工具调用的输入输出都沉淀在图上后续分析可以直接沿用这份“工具日志”。这也是我下一版 AgentCanvas 最想加强的方向让思维导图成为 Agent 工具箱的可视化调度台。6. 实战心得回到最初去找最关键的一步6.1 先做数据模型再做界面如果让我重写一遍 AgentCanvas我会把 80% 的精力先花在数据模型和上下文策略上而不是急着调 UI。很多思维导图工具之所以难用是因为它们把所有精力都花在“好看”上却没有回答“图里的数据如何被另一个智能体理解和转化”。有了健壮的树结构、清晰的路径上下文、可靠的快照UI 再简陋也能用。6.2 用 Markdown 起步别一上来就做图数据库我见过不少团队想从 Neo4j 或自研图存储起步最后卡在并发和序列化上。AgentCanvas 的节点数短期内不会过万完全可以用 JSON 文件或单表存储每天定时备份。当你的场景真的需要图谱级推理时再考虑迁移图数据库。过度设计是这类工具最常见的失败原因。6.3 人机协作的分寸是让 AI 生长让用户收敛最后想分享一个产品层面的体感AgentCanvas 不该让 AI 自动生成一整套思维导图那样用户只会得到一个漂亮的“垃圾图”。我的使用习惯是所有根节点和关键分支由用户手动定义AI 只负责在用户确认的方向上做细节延伸。用户负责发散和收敛的决策AI 负责生成候选内容。这才是“用思维导图的方式和 AI 深度对话”的本意。如果你也准备做类似的东西建议从一张很小的 Markdown 思维导图开始接一个能返回文本的大模型先把“提问—生成节点—挂在焦点下面”这个闭环跑通。之后你会发现很多你在聊天框里说不清的问题一到有结构的画布上思路自己就顺了。