空间上下文工程：地点感知 AI

空间上下文工程是一种在模型回答前选择其可以使用的地点、时间、路线和业务事实的实践。提示词可以询问最近的充电站，但有用的回答仍需要路线、当前时间，以及仅限主机选择共享的事实。空间服务负责计算地理关系，模型负责解释结果。

什么是空间上下文工程？

一项 2025 年的综述梳理了 1,400 多篇研究论文，把上下文工程定义为一门超越提示词设计、系统优化语言模型所接收信息的学科 (Mei et al., 2025)。该综述把这项工作分为上下文检索与生成、上下文处理和上下文管理。空间上下文工程把同样的方法应用到地点问题上。载荷必须说明对象在哪里、事实在什么时间有效、哪条路线或哪个区域重要，以及调用方可以使用哪些业务记录。

上下文并不是越多越好。Liu 等人发现，当相关信息位于输入的开头或结尾时，语言模型的表现往往最好；而当模型必须使用长上下文中间部分的信息时，表现会明显下降 (Liu et al., 2024)。因此，空间上下文包应保持精简：符合资格的地点、已计算的距离或包含关系结果、这些结果的新鲜度，以及调用方可以执行的操作。把当前地图视图里的所有图层一股脑塞进去，并不符合这个原则。

实践类指南也已经在使用这个术语。Vercel 的开发者指南提出了四种模式：检索、记忆、压缩和工具上下文 (Vercel, 2026)。地图产品可以同时使用四者，但任何一种都不能替代空间计算。检索可以带回政策段落，记忆可以带回之前的偏好，压缩可以丢弃目录中无关的内容。工具上下文可以保留路线或包含关系检查的结果，模型应该解释这些结果，而不是凭空编造替代数值。

提示词与上下文有什么不同？

提示词提出问题，上下文则是在回答前组装好的证据。“为一条配送路线寻找最近的充电站”是一条指令，但单靠这条指令可能只生成一个通用充电站列表，忽略车辆、时间以及实际开放的道路。图中将这种信息稀薄的回答，与一个包含地点、时间、路线、业务状态、权限和地图状态的上下文包进行对比。

一个询问附近充电站的短提示词，与一个加入地点、时间、路线、业务状态、权限和地图状态的空间上下文包并列。

左侧展示一条简短指令以及关于附近充电站的通用回答。右侧在生成地点感知回答前加入地点、时间、路线、业务状态、权限和地图状态。地点 ID、2024 年 6 月时间戳、5.2 km 标记以及充电站图钉均为示例标签。右侧上下文包只是参考草图，并非 Kaleidr 请求格式。

信息稀薄的回答在语法上并没有错，但在实际操作中无法使用，因为“附近”没有起点、没有最大绕行范围，也没有规定车队可以使用哪些充电站。图中信息更丰富的一侧仍然使用示例标识符，因此这些值并不是实时查询结果。生产环境中的上下文包应携带主机自己的 ID 和空间服务自己的计算数值。

为什么检索只是一个信息来源？

检索会从文档、政策、描述和帮助文章中提取文本片段。这些内容可以解释规则，但无法告诉调度人员某个停靠点是否位于服务区域内，因为多边形检查是一项计算，而不是一段文字。空间上下文会保留检索到的文本，同时加入结构化业务事实、授权结果、当前地图状态和空间计算结果。

检索到的文档和政策文本旁边，是由业务事实、授权、地图状态和空间计算构成的空间上下文堆栈。

左列将文档、政策文本、描述和知识检索为段落。右列在这些文本上加入结构化业务事实、授权、地图状态和空间计算。图中的结果是一个用于地点感知回答的决策包。绘制的路线与图钉只是示例图形，并非实测行程。

如果团队只停留在检索文本，听起来可能很有依据，但仍可能在地图判断上出错。政策段落可以说明晚间配送需要有人值守的地点，但只有营业时间数据、包含关系检查和调用方权限，才能判断该地点此刻是否符合条件。图中的决策包正是这些信息汇合的地方。

为什么当前证据必须优先于过时的记忆？

记忆适合保存不会很快失效的偏好，例如固定仓库或语言。但它不适合作为交通、临时关闭、库存，或者“今天谁可以查看某个私有地点”的事实来源。上周记住的“最佳停靠点”可能与空间服务刚刚返回的路线相冲突。两者冲突时，应优先采用当前计算和当前授权，而记忆仍应标记为偏好，不应当作事实。

同样的规则也适用于会话早些时候生成的摘要。压缩后的摘要可能漏掉临时关闭或已撤销的权限。下一轮应重新读取会变化的字段；如果摘要没有时间戳，调用方就不应基于它执行操作。新鲜度应该作为数据写入上下文包，而不是寄希望于之前的答案仍然正确。

为什么地点身份要先于搜索？

两个记录可以同名，但仍然代表不同地点。“市中心那家店”只是一个搜索表达，并不是 ID。上下文包应携带来自主机自身系统的稳定地点 ID，以及空间服务要使用的坐标或几何；显示名称应该只是标签，而不能作为主键。没有稳定 ID，后续轮次无法区分改过名的门店和另一个门店，引用也无法指向真正符合资格的记录。

上下文包应携带哪种几何？

几何必须和问题匹配。查询最近充电站需要点和路线；查询服务区域需要多边形以及包含关系结果；查询走廊需要线和到该线的距离。GeoJSON 定义了几何对象，点是其中一种几何类型，因此上下文包可以直接声明类型，而不是把几何形状隐藏在自然语言里 (IETF, 2016)。如果判断依赖多边形，却只发送点，后续解释看起来可能很精确，但真正需要的测试其实从未执行。

为什么视口不是权限？

一个地点即使出现在镜头范围内，也可能仍然禁止使用。图中同一视图里放了三个示例地点：两个调用方可以使用的公共门店，以及一个虽然图钉可见、但被排除在上下文之外的私有设施。可见性只是提示用户正在看什么。授权则是另外一项独立检查，用来决定请求可以包含什么。

一个地图视口，其中有两家已授权公共门店，以及一个可见但被排除在模型上下文之外的私有设施。

虚线框是当前地图视图，内部有三个示例地点。Public Store A 和 Public Store B 被标记为已授权。Private Facility C 即使图钉出现在屏幕上，也仍然不进入模型上下文。视口提供位置上下文，而独立的权限检查决定哪些内容可以使用。

同样的区分也适用于主机地图。Kaleidr 开发者文档说明，Chat 会添加自己的标记、移动镜头并绘制路线，但不会修改页面的图层、来源或标记，也不会把这些对象发送给 Kaleidr (Kaleidr, 2026)。屏幕上的一个图钉不是授权。哪些事实可以跨越边界由主机决定，上下文包应该记录这一决定，而不是假设镜头已经替代了权限判断。

空间服务首先应该计算什么？

先把数字交给空间服务计算，再让模型解释。图中展示了路线绕行、是否位于服务区域内，以及旅行时间，这些结果共同支持“为什么某家门店符合条件”的解释。旁边另一个框明确拒绝猜测的旅行时间。模型不适合成为距离、包含关系或到达时间的事实来源，因为这些值来自道路网络、多边形和时钟。

空间服务给出的路线绕行、服务区域检查和旅行时间结果，旁边是解释以及被拒绝的猜测时间。

空间服务返回 6 分钟路线绕行、真的服务区域内检查，以及 14 分钟旅行时间。随后解释为什么图中的 Store 104 被选为停靠点。被拒绝的框展示语言模型在没有使用服务结果的情况下自行编造旅行时间。分钟数、门店编号和被引用的猜测值都是图中的示例标签。

解释本身仍然有价值。空间服务返回符合条件的停靠点后，模型可以用调用方的语言说明，哪一个已计算事实让该停靠点成为合适选择。解释应该引用服务结果，而不是替代它。图中的门店编号和分钟标记只是标签，不是 Kaleidr 基准测试。

什么样的上下文包才算足够精简？

上下文包应足够小，便于人工阅读，同时又足够完整，使决策不依赖隐藏表格。图中从门店数据库、库存、营业时间、路径规划和权限等原始系统开始，最后压缩成一个很短的对象：任务、少量候选地点、资格判定、路线绕行、新鲜度时间戳，以及允许执行的操作。任何没有影响资格判定的内容都可以继续留在源系统中。

门店、库存、营业时间、路径规划和权限记录由上下文构建器压缩成包含候选地点、资格判定和允许操作的短上下文包。

门店数据库、库存、营业时间、路径规划和权限的原始记录进入上下文构建器。构建器输出一个短上下文包，其中包含任务、少量候选门店、资格标记、路线绕行、时间戳以及允许的操作。该上下文包应当足够小，便于检查，同时又足够完整，可以支持一次决策。门店 ID、距离和 2024 年 6 月时间戳都是示例标签，JSON 也是参考草图，而不是 Kaleidr API。

关于长上下文的这项研究结果，就是应该省略无关信息的原因。候选地点检索可以先宽后窄：不符合资格的地点在模型看到之前就被移除，上下文包保留原因，例如门店已关闭，或者包含关系检查失败。Kaleidr 的公开聊天请求比这个草图定义的契约更窄，下一节会说明该请求实际上携带什么。团队不应把图里的 JSON 直接 POST，好像平台真的定义了这种对象。

一个参考流水线包含什么？

实用流水线应明确每个风险由哪个阶段负责。依次解析任务、识别调用方、检查授权、设置地理范围、检索候选地点、附加业务状态、执行空间计算、应用资格判定、组装上下文包、把上下文包发给模型、执行地图操作、重新验证易变化字段，并记录发生了什么。图上方还增加了四个控制项：来源、新鲜度规则、策略和追踪 ID。

一个参考流水线，从任务解析和授权经过空间计算、上下文包、地图操作、重新验证和观测。

这条流程从任务解析开始，经过身份识别、授权、地理范围、候选检索、业务状态、空间计算、资格判定、上下文包、模型、地图操作、重新验证和观测。来源、新鲜度、策略和追踪 ID 位于上方，作为每个阶段的控制项。该图是给团队设计自己上下文构建器时使用的参考流水线。下方绘制的路线只是示例图形。

这个顺序是设计辅助，并不是 Kaleidr 产品执行顺序。有些团队可能会把候选地点检索与空间计算合并。应该继续保持清晰可见的阶段包括授权、计算、资格判定，以及在分配停靠点等操作之前立即重新验证。面向业务数据的有依据的空间 AI 是 Kaleidr 关于授权、检索和排序的相关指南。

Kaleidr 在哪里划定上下文边界？

在主机地图上，这条边界是明确的。支持的地图指南介绍如何将 Kaleidr Chat 接入 Mapbox GL JS、MapLibre GL JS、Google Maps、Leaflet 等库；Google Maps 密钥仍然只存在于页面与 Google 之间，因为 Kaleidr 不会接收该密钥 (Kaleidr, 2026)。图钉、移动到某个地点以及路线都是面板新增的绘制内容，并不是主机私有表格的副本。

主机应用只把位置、缩放级别、会话和获批事实的明确子集发送给 Kaleidr Chat，并以 Mapbox、MapLibre、Google Maps、Leaflet 作为主机地图。

主机应用保留用户、私有数据、库存、策略、自定义图层和业务操作。图中只有明确的一小部分信息会跨越边界，例如已授权位置、地图缩放级别、会话和获批事实。右侧 Kaleidr Chat 基于这部分共享内容解析地点、规划路线并执行地图操作。页脚是图中标签，门店名和车辆名也只是示例。仅仅接入 Chat，并不会自动发送主机的图层或业务系统。

Platform API 对聊天请求也定义了相同的边界。messages 表示对话，location 对象表示用于理解“这附近”的地图中心，map_zoom 是缩放级别，lang 是回复语言。同一页面明确表示，没有系统指令、角色设定、工具或调用方自身上下文的字段；未知字段会被接受但忽略。app_snapshot 和 auto_actions 会被接受，但并不需要，因此页面建议不要传入 (Kaleidr, 2026)。

上传业务数据走的是另一条独立路径。组织自己的业务数据如果要上传并用于 AI 回答，只能使用 Enterprise；基于这些上传数据的基于密钥的回答也只有 Enterprise 支持，How Kaleidr works 中对此有明确说明。配套文章如何构建地图感知 AI 助手介绍团队如何围绕同样的边界构建助手。

同一页面如何更容易被找到和引用？

介绍这种实践的页面应该易于引用。图中把这个目标分成普通搜索、问答引擎和生成式引用。搜索需要规范短语、一组相关方法，以及指向支持性指南的链接。问答引擎需要直接定义、几条具体问题，以及类似检索与空间上下文包的比较。

搜索、问答引擎和生成式引用围绕空间上下文工程页面排列，包含关键词、定义、问题和引用来源。

图中央是空间上下文工程，周围是搜索、问答引擎和生成式引用三个渠道。搜索需要规范关键词、主题集群和内部链接。问答引擎需要直接定义、常见问题和比较。生成式引用需要原创框架、有说明的结构、失败清单和引用来源，而且这些方框都不代表排名承诺。

图中的方框是内容写作检查清单，不是流量保证。Kaleidr 不负责让页面获得排名，这张图也没有报告任何测量值。页面真正能做的是，在一个地方给出清晰定义，把上下文包展示为参考草图而不是传输格式，并引用支撑这些主张的标准和文档。这样读者可以区分哪句话是在下定义，哪句话是在说明产品边界。

团队下一步应该做什么？

先针对一个真实任务写出上下文包，再去改提示词。包含地点 ID、时间、几何类型、空间计算结果，以及允许每条事实进入的权限。然后把这份列表与主机今天实际能够发送的聊天请求对照：对话、地图中心、缩放级别和语言，并不存在一个用于主机私有上下文的字段。如果回答必须依赖上传的业务数据，就从 Kaleidr Enterprise 开始。

注：Kaleidr 在创意与开发工作流中使用 AI 辅助工具进行图像创建、内容优化和研究。

常见问题

空间上下文工程和提示词工程是一回事吗？

不是。提示词工程改变的是指令措辞。空间上下文工程改变的是这条指令能够使用的证据，包括地点、时间、路线或区域，以及调用方可以查看的业务事实。即使句子写得再好，也无法补出空间服务从未计算过的包含关系结果。

接入 Kaleidr Chat 会读取主机地图的图层吗？

不会。在 Chat 运行于主机文档的页面里，Chat 会添加自己的标记、移动镜头并绘制路线。Chat 不会修改页面的图层、来源或标记，也不会把这些对象发送给 Kaleidr。除非另有独立 Enterprise 方案用于上传业务数据，否则私有数据表仍留在边界的主机一侧。

公开 Chat 请求能携带自定义上下文包吗？

文档化的请求只携带对话、用于地图中心的位置、可选缩放级别以及语言。不存在系统指令、角色设定、工具或调用方自身上下文的字段。app_snapshot 和 auto_actions 会被接受但不需要，因此团队不应把它们当作本指南中画出的上下文包。未知字段会被接受但忽略。

为什么行程时间应留在空间服务中？

行程时间取决于道路网络和时间，猜测出来的分钟数可能与服务刚刚计算的路线相冲突。计算图中的拒绝框用一个示例引用展示了这种失败模式，而不是实时结果。数字应保留在空间服务中，由模型负责解释。

References

Mei, L., et al. A Survey of Context Engineering for Large Language Models. A review of more than 1,400 papers that treats context engineering as more than prompt design and splits it into retrieval and generation, processing, and management. arXiv:2507.13334. 2025. https://arxiv.org/abs/2507.13334
Liu, N. F., et al. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12, 157–173. Performance is often highest when relevant information is at the start or end of the input and degrades significantly in the middle of long contexts. 2024. https://doi.org/10.1162/tacl_a_00638
Vercel. What is context engineering? A developer's guide. A practitioner guide naming four patterns: retrieval, memory, compression, and tool context. Accessed October 22, 2026. https://vercel.com/i/context-engineering
IETF. RFC 7946: The GeoJSON Format. GeoJSON defines a geometry object, and a Point is one of the geometry types. 2016. https://www.rfc-editor.org/info/rfc7946
Kaleidr Developer Docs. How Kaleidr works. Chat adds its own markers, moves the camera, and draws routes, and does not change the page's layers, sources, or markers or send them to Kaleidr. Uploaded business data for AI answers, and key-backed answers that draw on that data, are Enterprise only. Accessed October 22, 2026. https://docs.kaleidr.com/concepts/how-kaleidr-works
Kaleidr. Grounded Spatial AI for Business Data. A related guide covering authorization, retrieval, ranking, evaluation, and a narrow pilot. Accessed October 22, 2026. https://kaleidr.com/blog/grounded-spatial-ai-business-data
Kaleidr Developer Docs. Supported maps. Attach targets include Mapbox GL JS, MapLibre GL JS, Google Maps, and Leaflet. A Google Maps key stays between the page and Google; Kaleidr does not receive it. Accessed October 22, 2026. https://docs.kaleidr.com/chat/supported-maps
Kaleidr Developer Docs. Platform API endpoints. The chat request carries the conversation, a map-center location, optional zoom, and a language. There is no field for system instructions, a persona, tools, or the caller's own context. app_snapshot and auto_actions are accepted and not needed. Accessed October 22, 2026. https://docs.kaleidr.com/platform-api/endpoints
Kaleidr. Map-Aware AI Assistant: How to Build One. A companion guide for building the assistant around a map. Accessed October 22, 2026. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
Kaleidr. Kaleidr Enterprise. The enterprise page for spatial AI integrated with a customer's own data. Accessed October 22, 2026. https://kaleidr.com/enterprise

References in BibTeX

@misc{mei_context_engineering_survey_2025,
  title         = {A Survey of Context Engineering for Large Language Models},
  author        = {Mei, Lingrui and others},
  year          = {2025},
  eprint        = {2507.13334},
  archivePrefix = {arXiv},
  url           = {https://arxiv.org/abs/2507.13334}
}

@article{liu_lost_in_the_middle_2024,
  title   = {Lost in the Middle: How Language Models Use Long Contexts},
  author  = {Liu, Nelson F. and Lin, Kevin and Hewitt, John and Paranjape, Ashwin and Bevilacqua, Michele and Petroni, Fabio and Liang, Percy},
  journal = {Transactions of the Association for Computational Linguistics},
  volume  = {12},
  pages   = {157--173},
  year    = {2024},
  doi     = {10.1162/tacl_a_00638}
}

@misc{vercel_context_engineering_2026,
  title  = {What is context engineering? A developer's guide},
  author = {{Vercel}},
  year   = {2026},
  url    = {https://vercel.com/i/context-engineering}
}

@misc{ietf_rfc7946_2016,
  title  = {RFC 7946: The GeoJSON Format},
  author = {{IETF}},
  year   = {2016},
  url    = {https://www.rfc-editor.org/info/rfc7946}
}

@misc{kaleidr_how_it_works_2026,
  title  = {How Kaleidr works},
  author = {{Kaleidr Developer Docs}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/concepts/how-kaleidr-works}
}

@misc{kaleidr_grounded_spatial_ai_2026,
  title  = {Grounded Spatial AI for Business Data},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}

@misc{kaleidr_supported_maps_2026,
  title  = {Supported maps},
  author = {{Kaleidr Developer Docs}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/chat/supported-maps}
}

@misc{kaleidr_platform_api_endpoints_2026,
  title  = {Platform API endpoints},
  author = {{Kaleidr Developer Docs}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

@misc{kaleidr_map_aware_assistant_2026,
  title  = {Map-Aware AI Assistant: How to Build One},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant}
}

@misc{kaleidr_enterprise_2026,
  title  = {Kaleidr Enterprise},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/enterprise}
}