企业官网建设流程全解析

我一直觉得，做 LLM 应用最隐蔽的问题不是模型能力不够，而是上下文漂移（context drift）。很多项目表面上是“模型回答不对”，实际是喂给模型的内容已经偏离了当前任务。最近看到一个有意思的思路：用空间节点画布（spatial node canvas）来管理 LLM 上下文，专门修 context drift 这个问题。这个方向很值得拆开聊。它要解决的痛点一句话就能说清：把线性聊天的历史记录，变成可以主动引用、整理和回溯的节点，避免大段无关内容把任务方向带偏。

适合谁看？做 Agent 工作流、长文档问答、知识库系统、复杂任务编排的人，都值得看完。最值得关注的地方不是那个画布界面多好看，而是上下文管理的方式变了：从“被动堆聊天记录”变成“主动组装当前任务真正需要的内容”。下面按我的实测体会，把从概念到落地的完整链路拆一遍。

1. 先搞清楚 context drift 到底错在哪一步

1.1 线性对话为什么越聊越乱

先定义一下 context drift：它不是聊到一半忘记之前说什么，而是上下文窗口里的早期信息和当前任务的关联，被不断插入的新内容冲淡了。模型没有真正的“重点”概念，它只会根据你给它的所有内容推测当前意图。如果一段对话从“写产品文案”聊到“看竞品截图”，再聊到“调接口”，又没有明确清理，模型就很可能开始答非所问。专业术语叫上下文漂移，用大白话说就是“相关和无关内容混成一锅粥”。

真实开发里，最常见做法是把整个 chat history 原文塞进 prompt。最短路径，但也最容易出事。当历史达到几十轮、几百轮之后，上下文窗口被无关内容占满，模型必须从海量信息里找重点，输出质量和稳定性都会下降。更麻烦的是中途换任务，比如先查资料再写周报，模型可能还带着查资料的思路，周报里就混进不相关的细节。我在项目里遇到这类问题，一开始总以为是自己 prompt 写得不好，后来才发现改 prompt 治标不治本，根子在于上下文结构从一开始就是线性的。

1.2 把会话拆成节点后发生了什么

空间节点画布的核心变化，是把连续会话切成一个个节点。每个节点可以是一段用户输入、一条模型输出、一个结论、一份文档摘要、一个待办，甚至一次外部工具返回结果。节点之间用连线或标签表达关系，而不是只按时间排序。这样人能直观看到上下文里到底有什么，也能手动决定哪些节点进入当前任务的上下文。

我按这个思路做过小实验。每次任务开始时，不把整个对话记录发给模型，只取当前相关节点。比如写周报时，我只选“周一会议结论”“周三开发进度”“周五上线的风险”这几个节点，忽略中途闲聊节点。生成结果比直接把 50 轮对话塞进去稳定很多。原因不复杂：模型收到的信息更干净，冲突更少，任务目标更清晰。

1.3 空间画布解决的不只是“记不住”

很多人以为长上下文模型普及后，context drift 会自动消失。实际不是。上下文窗口变大，意味着能塞更多历史，但也意味着模型更难精确定位关键信息。空间画布的价值不是让模型记住更多，而是让你明确“该记住哪些”。通过把节点放到空间位置、分组、打标签，人可以做一层显式记忆管理，而不是依赖模型在长文本里自己找重点。

空间位置还有一个容易被忽视的好处：缓解位置偏差。最新节点本来在画布右下角，但组装 prompt 时，可以按“结论优先”而不是“时间优先”排序。很多模型对 prompt 中间部分注意力较弱，越重要的节点越应该放到开头或结尾。画布上的空间位置只是视觉组织，真正决定模型效果的，是组装进 prompt 时被赋予的排列优先级。

2. 一个最小可用的空间节点画布，需要哪些东西

2.1 数据模型：节点、边、视图

不需要一开始就做复杂产品。先定义三样东西：

• 节点（node）：一次最小的上下文单元。字段包括 id、类型、内容、创建时间、标签、位置坐标。
• 边（edge）：两个节点之间的引用关系。比如 A 节点是 B 节点的前提，或者 C 节点是对 D 节点的修正。
• 视图（view）：当前任务需要选中的节点集合。一个视图对应一次真实请求。

我建议用 JSON 做存储格式，方便调试。一个节点大概长这样：

{ "id": "node_001", "type": "user_note", "content": "周一会议结论：新版本优先修复登录超时问题。", "tags": ["meeting", "version"], "x": 120, "y": 240, "created_at": "2025-05-26T09:30:00Z" }

这就是画布的最小单元。真正的画布界面，只是把坐标、颜色、分组映射到这些属性上。越早把数据结构定清楚，后面做批量任务和自动组装就越省事。

2.2 环境与存储：本地优先

在我的实验里，没有引入重型服务端。数据放在本地 SQLite 或单个 JSON 文件里。原因：先跑通逻辑，再考虑多用户。如果只是验证思路，JSON 文件够了。如果打算长期使用，SQLite 更稳，支持索引和查询。

运行环境方面，最常见的方案是 Node.js 或 Python。一个本地 Web 服务负责页面，一个 API 层负责读取节点、组装上下文、调用模型接口。整个链路不一定需要 GPU。如果只是调试画布，甚至可以先把模型调用 mock 掉，环境问题会少很多。

早期搭建本地 LLM 环境时，我不建议一上来就追求本地大模型。除非机器显存非常充足，否则先用云端接口把逻辑跑通。本地模型能跑，但量化、推理速度、并发能力都会影响调试效率。等确认画布和上下文组装逻辑稳定了，再换成本地推理也不迟。

2.3 画布界面和模型接口怎么连接

连接分两层。界面层负责展示节点和连线，逻辑层负责把选中节点序列化成 prompt。最简单的做法：界面提供一个“选择节点”模式，用户点节点后，右侧出现已选列表。点发送时，后端把已选节点按规则合成上下文块，再调用模型接口。

这里最容易踩坑的是顺序。空间位置并不代表语义顺序。在画布上，一个节点可以放在另一个节点左边，但组装 prompt 时，需要按“用户任务描述 -> 参考材料 -> 历史结论 -> 输出格式”排序。位置只用来做视觉管理，真正的优先级由组装规则决定。我第一次实验时直接按节点创建时间排序，结果很乱。后来改成按节点 role 分块排序，效果才正常。

2.4 为什么用 Markdown 存节点内容

热词里反复出现“markdown格式 llm 接收”，这确实是经验。Markdown 是最适合作为节点内容格式的文本形式。原因有三个：模型对标题、列表、引用的理解比较稳定；组装 prompt 时可以保留格式；人编辑起来也方便。

比如一个节点可以这样写：

### 用户需求 用户希望在详情页增加“重新生成”按钮。 ### 约束 - 不改变现有接口 - 最多调用一次生成接口 - 失败时保留原内容

多个节点组装时，只要用一级二级标题区分来源，模型就能识别每个区块。但要注意：Markdown 解析失败会引起连锁问题。很多模型接口报错“provider rejected the request schema or tool payload”，就是因为传给接口的文本或 JSON 结构里混入了无法解析的内容。看到这类报错，先检查节点内容有没有损坏。

3. 从手工选节点到自动组装上下文

3.1 先用手工方式跑通

最小可行流程是：打开画布，浏览节点，手动勾选需要的节点，发送给模型。这样虽然慢，但能验证 context drift 是否真的改善。我一般会用小任务测试：先给模型一段长文档摘要作为节点，再给一个明确问题。如果模型只针对问题回答，不掺入无关摘要，说明组装有效。

手工阶段不要写太多自动化。很多人会一上来就写“自动召回节点”，结果召回不准，反而把无关内容塞回上下文，问题更严重。手工跑通的意义是建立参照标准：你知道哪些节点该选中，哪些不该选中。有了这个标准，后面做自动选择才有判断依据。

3.2 用代码自动组装：按 token 预算合并节点

跑通手工流程后，可以写一个简单的组装函数。基本逻辑是：给一个任务 ID，找出关联节点，再按 token 预算裁剪。

def build_context(task_node, related_nodes, max_tokens=3000): # 先放任务描述 context_parts = [render_node(task_node)] used_tokens = count_tokens(context_parts[0]) # 再放结论、引用、背景，按优先级排序 for node in sort_by_priority(related_nodes): rendered = render_node(node) if used_tokens + count_tokens(rendered) > max_tokens: continue # 超出预算就跳过，不能硬塞 context_parts.append(rendered) used_tokens += count_tokens(rendered) return "\n\n".join(context_parts)

关键参数是 max_tokens。别只看模型的最大上下文长度，还要给输出预留空间。比如模型支持 8K token，输入最多留 6K，剩下 2K 给输出和工具调用结果。如果输入太长，模型容易截断，甚至出现“model did not produce a response before the mod”这类超时错误。

3.3 引入标签和 RAG：从知识库检索节点

节点多了以后，手动选择会变费劲。此时可以加一层检索。把每个节点看作小块文档，用向量检索召回和当前任务相关的节点。这就是 RAG 增强 LLM 的常见做法。但要注意：RAG 和空间画布不是一回事。RAG 解决“从海量文档里找相关内容”，空间画布解决“已经选中的内容如何组织、引用、更新”。两者可以配合使用。

稳妥的接入顺序：

1. 节点内容切块存入向量库。
2. 任务开始前，根据任务描述检索 TopK 候选节点。
3. 在画布上显示候选节点，用户可增删。
4. 确认后组装 prompt，发送给模型。

这个流程里，检索召回只是预筛，最终决定权仍然在人。这样做能避免自动召回引入噪音。如果你已经有一个 RAG 知识库，也可以把知识库里的文档片段作为一类节点引入画布，相当于用画布管理“最终进入模型的那一小段知识”。

3.4 和 LLM 框架、命令行工具配合时的接入点

现在很多 LLM 框架提供 Agent、Tool、Pipeline 抽象。空间节点画布可以作为外部上下文管理器接入。思路是：画布生成一段结构化上下文，通过接口传给框架，框架把这段内容当作 system prompt 或 user content。

如果你习惯用命令行工具跑模型，也可以把画布导出为 Markdown 文件或 JSON 文件，再用命令行读取。这样画布就变成了工具链里的上下文仓库。我实践下来的感受是：工具之间避免互相绑定。画布只负责上下文管理，模型调用交给专门的框架或命令行工具，这样替换模型、调整参数都更方便。

4. 先跑单任务，再处理批量与复杂工作流

4.1 单次任务怎么判断成功

用画布管理上下文，最低标准是“模型回答没有被无关节点污染”。具体测试方法：把一组节点 A 作为上下文提问，然后把一组无关节点 B 加进去再问同一问题。如果两次回答明显偏离，说明组装顺序或预算控制有问题。如果第二次回答基本没变，说明节点引用已经起到了隔离作用。

另一个重要判断是引用正确性。如果模型从某个节点引用了一句话，需要确认这句话确实在节点内容里，而不是模型自己编的。这个检查不能省。尤其当节点内容是长文档摘要时，模型容易把摘要当事实，而摘要本身可能有偏差，甚至已经过期。

4.2 批量任务真正要看的不是速度，而是稳定

很多人把节点画布接入批量任务时，只看每秒能跑多少条，忽略输出命名、失败重试和队列管理。批量任务和单任务的区别在于：单任务失败可以马上重试，批量任务如果从中间断了，你需要知道已经处理到哪里。

我用画布跑多文件任务时，会在每个节点上加状态字段：pending、running、done、failed。启动批量任务前先扫描一次所有节点状态，只处理 pending 的节点。输出文件名尽量用节点 ID 加时间戳生成，避免覆盖。如果模型请求失败，先记录失败原因，把节点状态改成 failed，而不是直接退出整个队列。

4.3 判断“漂移修复”时的四个信号

如果你不确定画布方案是否有效，可以检查这四个信号：

1. 同一个任务在不同时间跑，输出主题是否一致。
2. 上下文中混入无关节点时，回答是否仍然聚焦。
3. 长流程里，后面步骤是否还会引用到已经被否决的旧结论。
4. 模型输出里，是否还会出现不该出现的内部思考过程。

第四点比较多人问：“怎么让模型不输出思考过程”。如果你已经把画布上下文整理得很干净，答案会简洁很多。遇到这类问题，先检查系统提示词里有没有明确的输出格式约束，再检查是否把模型厂商默认的推理输出误判成上下文漂移。

5. 启动失败和请求报错，先按这个顺序排查

5.1 明确现象：是报错、卡住还是输出异常

排查前先分类。最常见有三类：

• 启动失败：没进入界面或服务进程直接退出。
• 请求失败：前端能打开，但点击发送后报错或超时。
• 输出异常：请求正常返回，但内容质量很差。

现象不同，排查路径完全不同。启动失败先看端口和依赖；请求失败先看输入内容和模型接口；输出异常先看上下文组装顺序和系统提示词。很多人一报错就改代码，其实应该先看日志。日志里如果能定位到 request body，很多问题一眼就能看出来。

5.2 输入格式和 Markdown 解析问题

节点用 Markdown 存储后，最常见报错是调用模型接口时，prompt 里混入了未正确编码的字符。比如节点内容包含非法 JSON 字符，或者 Markdown 代码块没有闭合，导致接口解析失败。

我遇到过一个典型报错：LLM request failed: provider rejected the request schema or tool payload。表面是工具调用参数问题，实际是节点内容里有一段不完整 JSON 被当成了 tool payload 传给模型。排查方式很简单：打印发送给模型的完整请求体，检查每个节点渲染结果。不要把报错信息当成最终结论，先确认数据本身是不是合法 JSON 或纯文本。

5.3 依赖版本和本地环境

如果你在本地搭过 LLM 环境，会知道依赖版本对结果影响很大。画布项目通常依赖 Node.js、Python、SQLite、HTTP 库、模型 SDK。某个库升级后，API 签名变化可能导致启动失败或请求失败。建议锁定关键依赖版本，用 requirements.txt 或 package.json 固定版本范围。

本地模型还有资源占用问题。低配置机器能跑通推理，不代表能支撑画布服务、向量检索和模型推理同时运行。如果程序没报错但响应很慢，先看 CPU、内存和显存占用。显存接近满载时，很可能是多个任务同时加载模型导致排队。这类问题不算 bug，更像资源调度问题，需要限制并发。

5.4 超时、并发和重试策略

热词里出现过的 “llm request timed out” 和 “model did not produce a response”，这类错误经常和并发与超时设置有关。画布场景里，如果同时触发多个请求，或者某个请求输入过长，模型服务端可能迟迟不返回。

建议在服务端设置两个超时：连接超时和读取超时。读取超时通常要比模型预计响应时间长，比如 60 秒以上。如果模型经常超时，优先做两件事：减少输入 token，或者把请求改成异步队列。用异步队列后，即使单次请求跑 3 分钟才返回，也不会阻塞其他任务。这是批量场景里非常实用的做法。

5.5 工具本身的功能边界

空间节点画布也不是万能的。它负责上下文结构，不能修复模型能力短板，也不能解决数据缺失。节点里根本没有的信息，无论怎么组织，模型也不会知道。还有一些格式要求严格的任务，比如必须输出特定 JSON Schema，你需要在画布节点类型里加一个“输出约束”节点，而不是只靠空间排列。

如果你发现画布越用越乱，不要急着加新功能。先看节点是否太多、标签是否统一、引用链是否断掉。定期整理画布、删除过期节点、合并重复信息，比多加几个自动化按钮更有用。

6. 空间节点画布适合做成什么，哪些场景别用它

6.1 个人知识库和长文档问答

个人知识库是最契合的场景。把一篇长文档拆成多个节点，每个节点对应一个章节或一个观点。回答问题时，选取相关节点，而不是把整个文档塞进 prompt。这种用法能减少 context drift，也能减少 token 消耗。

如果你用过双链笔记或知识管理工具，会发现这思路很接近：节点就是笔记，边就是链接。区别在于，普通笔记是给人看的，空间画布还要面向模型。所以每个节点最好有稳定 id、明确标题、便于检索的标签。Markdown 格式在这里很占优势，既方便人读，也方便模型解析。

6.2 团队协作时的取舍

团队场景下，画布会面临权限、并发编辑、节点版本冲突等问题。这不适合个人项目一上来就做。我建议团队先用共享文件夹加约定好的 Markdown 文件跑，比如每个节点一个 .md 文件，用文件名前缀表示状态。等验证流程有效，再考虑引入数据库和服务端。

更关键的是团队要对“什么内容算一个节点”达成共识。如果一个人把整篇文档算一个节点，另一个人把一句话算一个节点，画布会很快乱掉。建议团队先定义节点粒度，比如“一个节点等于一个可独立引用的结论或任务”。这个约定比任何技术方案都重要。

6.3 哪些场景不要过度依赖画布

实时聊天场景不太适合。如果用户只是和一个客服机器人闲聊，额外包一层画布没有意义，只会增加响应延迟。画布更适合固定任务、长流程、需要跨步骤引用上下文的工作。比如写周报、做技术方案、分析代码库、审核长文档，这些场景能明显体现空间组织的好处。

另外，如果模型本身只需要很少上下文就能完成任务，画布属于多余。判断标准很简单：你把节点全部展开成一个线性文本后，如果顺序混乱导致效果变差，说明画布有意义；如果排序根本不影响结果，那就不需要维护画布。

6.4 我的落地建议

如果你决定做类似项目，我建议按四步走。第一步，用 JSON 文件记录节点，做一个手工勾选的简单页面。第二步，让画布能把选中节点渲染成一段 Markdown，复制出来手动发给模型。第三步，接入模型接口，让画布直接请求。第四步，再加向量检索、状态管理和批量任务。

每一步都要先解决一个明确痛点，不要同步开发太多功能。我踩过最深的坑，是画布界面做得很复杂，但上下文组装逻辑很弱，最后界面看着漂亮，用起来还是不如简单的纯文本记录。真正解决 context drift 的核心，永远是节点如何被引用、排序、更新，而不是节点看起来多炫。把这个核心想清楚，再谈可视化不迟。后续如果你也打算用空间节点画布来管 LLM 上下文，建议把第一次实验控制在一个任务、十来个节点以内。跑通了再扩，别一开始就追求大而全的自动化。