一个要下线的 Feature Service，常常不是一条孤立的数据服务：Web Map、Dashboard、StoryMap、Experience 等上层项目可能都在引用它。只靠门户搜索、文件夹命名或人工逐项点击，既难找全深层依赖，也无法留下可以复查的决策依据。Esri 在 2026 年 7 月的官方工作流给出了一条更稳妥的路径：先把项目及服务之间的关系建成有向图，再把图转入 ArcGIS Knowledge 做查询、可视化与受控的自然语言探索。

可核查事实：依赖图能回答什么

  • Esri 于 2026 年 7 月 8 日发布该工作流，目标是了解 ArcGIS Online 或 ArcGIS Enterprise 组织内项目彼此如何关联。

  • 官方列出的直接价值包括：识别某项服务变更会影响哪些应用、迁移时哪些项目必须同行，以及哪些项目引用已删除或损坏的数据源。

  • 图中的节点可表示 ArcGIS 项目、服务或“unknown”类型；边是有方向的“has dependency”关系。

  • 官方以 StoryMap 内嵌 Web Map、而 Web Map 又使用 Feature Layer 为例：Web Map 和 Feature Layer 都是 StoryMap 的深层依赖。

  • ArcGIS API for Python 的 arcgis.apps.itemgraph 模块用来汇集不同项目类型的依赖关系；这些关系可能存于项目 JSON、资源文件、REST 关系端点或特定实现中。

  • create_dependency_graph() 会从一组根项目构造 ItemGraph，而 ItemGraph 扩展自 networkx 的 DiGraph。

  • ItemGraph.to_knowledge_graph() 可把结果转换为 Knowledge Graph。

  • 运行该流程需要启用了 ArcGIS Knowledge 的 ArcGIS Enterprise；创建 Knowledge Graph 还需要配置 Knowledge Server 和 Graph Data Store。

  • ArcGIS Knowledge 使用 openCypher 查询，可用于找被最多项目使用的项目、无人使用的项目、人员离开后的归属影响，以及删除某个 Feature Service 的波及范围。

  • ArcGIS Maps SDK for JavaScript 5.1+ 提供 ArcGIS Knowledge AI agent；它可把知识图服务、Link Chart 或带知识图层的地图作为上下文。

这些事实定义了能力边界：这是一套针对项目依赖的发现与分析流程，并不自动证明某个服务可以安全删除。业务责任、外部系统调用与实际访问量仍要由团队另行核验。

先把“依赖”写成可判定的关系

项目治理最容易犯的错，是把“目录里没有同名项目”当作“没有影响”。依赖不一定写在标题或文件夹里。

Web Map 可显示多个 Feature Layer；应用可嵌入 Web Map 或 Scene；Feature Layer 又可能由 CSV、Shapefile 或 File Geodatabase 发布。官方特别指出，不同类型的关系记录位置并不统一，因此需要将这些来源汇集起来，而不能用单一检索字段代替。

有向图的好处是把问题改写成可检查的路径。对某个准备下线的服务，从服务向外查“谁依赖我”；对一个准备迁移的应用，从应用向内查“我依赖什么”。

深层依赖尤其关键：只看一跳关系，可能发现 Web Map，却遗漏它继续引用的 Feature Layer。

从根项目到迁移清单

可将每次变更按下面的顺序执行。

  1. 列出变更对象和根项目：服务下线以服务为根，应用迁移以应用为根，并记录项目 ID、环境、变更单和计划时间。
  2. 用 create_dependency_graph() 生成 ItemGraph，保留本次图生成时间、根项目集合与 API 版本；图是审计快照，不能只保存一张截图。
  3. 将 ItemGraph 转为 Knowledge Graph，再用 openCypher 输出受影响项目的标题、类型、所有者、路径长度和原始 ID。路径长度能帮助区分直接风险与深层风险，但不等于业务优先级。
  4. 针对“无入边且无出边”的项目做候选清理清单；官方示例将这类项目解释为不依赖其他项目、也不被其他项目依赖的对象。先由所有者确认，再决定是否删除。
  5. 针对离职、交接或账号删除，查询该用户拥有的项目及其深层依赖。官方示例在五跳范围内检查依赖，并据此规划高依赖项目的转移。团队可按自身复杂度调整范围，但须记录截断规则。
  6. 在执行迁移或下线前，把查询结果交给服务所有者、应用负责人和业务负责人签字；执行后再次建图，比较新增断链、残留引用和替代服务是否已接入。

图查询、Link Chart 和 AI agent 的分工

openCypher 适合产出可复跑的规则化清单，例如找出“依赖某服务的所有项目”、按依赖数量排序，或找出无人使用的候选项目。其优势是查询文本、参数和结果可以随变更单归档。

Knowledge Studio 的 Link Chart 则适合和负责人一起观察多跳路径、展开直接连接、定位两个高依赖对象之间的联系。

AI agent 适合降低探索门槛，官方说明它可用当前知识图、Link Chart 或地图知识图层作上下文，回答与上述查询相同类型的问题。

但它应是查询入口，不是变更审批人：每个自然语言结论都要回到项目 ID、路径、查询或图视图。对于删除、迁移和权限变更，仍应执行人工确认和可复跑查询。

上线前检查清单

  • 根项目、环境和变更范围是否有可追溯记录？

  • 是否同时检查直接依赖和深层依赖，并说明深度上限？

  • 输出是否保留项目 ID、类型、所有者、路径与生成时间，而非只有标题？

  • Knowledge Server、Graph Data Store 与 ArcGIS Knowledge 的部署条件是否满足？

  • 下线候选是否经过所有者与业务负责人确认？

  • AI agent 的回答是否能回链到图查询或 Link Chart，而不是作为唯一证据？

  • 变更后是否重新生成依赖图，验证断链和替代服务？

风险边界

依赖图依赖于平台可识别的引用关系。它不能代替访问日志、外部应用配置、业务合同或灾备演练；未被图捕获的系统集成仍可能受影响。

无依赖也不等于无价值，项目可能是归档、合规留存或即将启用的资产。AI agent 的自然语言结果也应视为探索提示，不能跳过查询复跑与责任人确认。

结论

ArcGIS 项目迁移和服务下线的关键不在于“找几个关联链接”，而在于把关系变成可回放的图、可归档的查询和可签字的影响清单。用 ItemGraph 发现关系，用 Knowledge Graph 与 openCypher 固化判断，再用 Link Chart 和 AI agent 辅助沟通，才能让一次变更从经验操作变成可复核的 GIS 治理流程。

资料来源