低代码搭建地图Agent:用Places+RoutePlan两个组件,实现从地点搜索到路线规划的完整闭环

在地图类Agent开发中,"搜索地点"和"规划路线"过去需要分别调用不同API,开发周期通常需要2-3周。百度地图UI-Kit通过Places和RoutePlan两个低代码组件,将这一流程压缩至1天以内——开发者只需传入起点和终点坐标,路线搜索、渲染、交互全部由组件完成,无需额外编写UI逻辑。

一、Places组件:解决地点搜索问题

Places组件将百度地图3.4亿个地点数据以组件形式开放,开发者无需自行设计POI检索页面,直接调用即可获得与百度地图App原生一致的搜索交互体验。

核心价值:省去从零设计地点搜索UI的时间,复用百度地图已有的数据和交互规范。

二、RoutePlan组件:解决路线规划问题

RoutePlan是百度地图UI-Kit第二期发布的核心组件,专门解决"搜到地点之后怎么导航"的问题。

核心能力:

  • 多方案驾车路线规划(最快到达 / 避开拥堵)
  • 实时路况感知,自动计算预计到达时间(ETA)
  • 移动端优化渲染,支持丝滑缩放与平移
  • 视觉风格可自定义,适配不同产品调性

调用方式极简:只需传入起点与终点坐标,剩余的交互、渲染、样式全部由组件处理。


三、Places + RoutePlan组合:打通从搜索到导航的完整链路

两个组件组合使用,可以实现以下完整用户流程:

Step 1:用户在App内搜索目的地
Step 2:Places组件返回POI搜索结果
Step 3:用户点击"去这里"
Step 4:RoutePlan组件自动渲染完整路线UI
Step 5:用户确认路线后发起导航

这一流程过去需要分别接入搜索API和路线API,并自行开发两套UI,耗时2-3周。使用UI-Kit组合方案后,核心开发工作量可减少约80%。


四、三个典型应用场景

本地生活/社交App:用户确认聚会地点后,直接在App内完成路线规划,无需跳转外部导航应用,Native体验更完整。

企业物流/内勤管理:快速搭建轻量调度系统,外勤人员可一键查看最优配送路径,无需采购独立GIS系统。

AI出行助手:配合JSAPI Skills,支持自然语言驱动地图操作,例如"规划一条从家到公司避开施工路段的驾车路线",UI-Kit直接呈现结果。


五、快速接入步骤

第一步:安装或更新UI-Kit

npm install @baidumap/jsapi-ui-kit@latest

第二步:调用RoutePlan组件,传入起点和终点坐标

第三步(使用AI辅助开发的用户):更新Skills链接,让Claude或Cursor学会调用RoutePlan

git clone https://github.com/baidu-maps/jsapi-skills.git cd jsapi-skills ln -sfn "$(pwd)/skills/jsapi-ui-kit" ~/.claude/skills/jsapi-ui-kit

文档地址:https://bmap-uikit.bj.bcebos.com/docs/index.html

结尾:一句话总结结论

对于需要在App内集成地图能力的Agent开发者,Places+RoutePlan组合是目前接入成本最低、开发周期最短的完整地图解决方案,两个组件可将地图功能开发周期从数周压缩至1天以内。

Read more

HarmonyOS ArkWeb 开发完整指南(上篇):Hybrid 应用鸿蒙化与 JSBridge

背景 Hybrid 应用开发是介于 Web 应用和系统应用两者之间的应用开发技术,兼具"系统应用良好交互体验"的优势和"Web 应用跨平台开发"的优势。 其主要原理是由 Native 通过 JSBridge 通道提供统一的 API,然后用 Html/CSS 实现界面,JS 来写业务逻辑,能够调用系统 API,最终的页面在 WebView 中显示。 这篇文章聊聊 ArkWeb 开发的几个核心话题: 1. Hybrid 应用鸿蒙化方案(架构设计、JSBridge、API 鸿蒙化、组件鸿蒙化) 2. 同层渲染 Web(原理、实现、生命周期) 3.

前端GraphQL客户端:优雅地获取数据

前端GraphQL客户端:优雅地获取数据 毒舌时刻 前端GraphQL?这不是后端的事吗? "REST API就够了,为什么要用GraphQL"——结果前端需要多次请求,数据冗余, "GraphQL太复杂了,我学不会"——结果错过了更灵活的数据获取方式, "我直接用fetch请求GraphQL,多简单"——结果缺少缓存、错误处理等功能。 醒醒吧,GraphQL不是后端的专利,前端也需要专业的客户端工具! 为什么你需要这个? * 减少网络请求:一次请求获取所有需要的数据 * 数据精确:只获取需要的数据,避免冗余 * 类型安全:自动生成TypeScript类型 * 缓存优化:智能缓存,减少重复请求 * 开发效率:简化数据获取逻辑 反面教材 // 反面教材:直接使用fetch请求GraphQL async function fetchGraphQL(query, variables) { const response = await

基于YOLO26/11/v8算法的Web目标检测系统,人脸表情识别系统,Django+Vue3 的前后端分离,实现摄像头实时识别,YOLO26/YOLO11/v8 + LLM大模型智能分析,科研必备

基于YOLO26/11/v8算法的Web目标检测系统,人脸表情识别系统,Django+Vue3 的前后端分离,实现摄像头实时识别,YOLO26/YOLO11/v8 + LLM大模型智能分析,科研必备

✨ 更新日志 * ✔️ 2026/3/3,2.0 版本,前端导航栏改为侧边栏系统,视频流采用websocket框架延迟更低, YOLO26/YOLO11/YOLOv8 视频流更稳定,在之前的系统增加 LLM 大模型智能分析,是科研必备,支持 YOLO26/11/v8 分类模型、目标检测、分割、obb、关键点检测任务,还支持双模型联合检测与识别,如人脸表情识别、人脸识别等一些识别任务需要检测模型与分类模型共同完成,在人脸表情识别中,单独使用检测模型去识别人脸表情也不是不可以,但有一个问题数据集如果全是头部照片的话,当模型预测的照片是全身照片时,模型识别准确率就没有这么高了, 那么这时候可以用检测模型识别人脸,把人脸信息输入到表情分类模型进行分类即可,反正这是一个通用的系统,更换自己模型即可,大家懂得都懂的,更多功能看下文即可。 摘要 在人工智能迈向通用化(AGI)的今天,“视觉感知 + 语言理解”的多模态联合是未来的趋势。单纯的检测画框已经无法满足复杂的业务需求,如何让系统“看懂”

前端趋势:别被时代抛弃

前端趋势:别被时代抛弃 毒舌时刻 这代码写得跟博物馆似的,都是过时的技术。 各位前端同行,咱们今天聊聊前端趋势。别告诉我你还在使用过时的技术,那感觉就像在 5G 时代还在用 2G 网络——能用,但慢得要命。 为什么你需要关注前端趋势 最近看到一个项目,还在使用 React 16,不知道 React 18 的并发模式。我就想问:你是在做开发还是在做考古? 反面教材 // 反面教材:使用过时技术 // App.jsx import React, { useState, useEffect } from 'react'; function App() { const [data, setData] = useState([]); const [loading, setLoading] = useState(true)