滴滴正式推出 OpenClaw 专属打车Skilldidi-ride-skillhttps://github.com/didi/didi-ride-skill使用 OpenClaw 即可直接调用滴滴完整出行服务链路。当你对 AI 说出「帮我叫个车去机场」时系统会自动完成一整套流程地址解析、价格预估、用户确认、订单创建并在数分钟后主动告诉你司机在哪。整个过程无需打开滴滴App也无需重复输入手机号或车型偏好你的历史设置可以被自动继承。为什么要做一个打车Skill滴滴 MCP 服务已对外提供 13 个工具能力覆盖地址解析、价格预估、订单创建、状态查询等完整链路。从“能力供给”的角度看基础设施已经具备。但从“用户可用性”来看仍存在部分断层普通用户无法通过手动拼接 JSON-RPC 请求完成一次打车。打车流程本身具备典型的线性结构地址解析 → 比价 → 下单 → 状态跟踪天然适合由 AI 进行编排与执行。所以真正的挑战并不在流程设计而在于如何让 AI 在复杂上下文和不确定环境中稳定地完成整个流程。因此我们设计 didi-ride-skill 只有一个目标在 OpenClaw 中用户只需说一句「帮我叫车去机场」后续流程即可全自动化完成didi-ride-skill 能做什么场景一从0完成首次打车下单完成 didi-ride-skill 安装与 Key 配置后在对话框中输入一句话即可实现一次完整的出行流程。在这一基础场景下系统需要在地址解析、价格预估、用户确认、下单执行以及订单状态自动回查等关键环节上保持稳定性。场景二预约出行与任务托管借助 OpenClaw 的 cron 机制AI 可以创建定时任务在指定时间自动触发打车流程。该任务运行于全新的独立 session 自动触发完成打车流程。用户无需持续关注执行过程到达指定时间后即可收到结果通知。场景三具备推理能力的行程理解在复杂场景中AI 不再只是执行工具调用而是开始具备一定的推理能力例如能够根据“22:20 落地”推算实际用车时间、主动补全你缺失的起点信息并对整体行程进行合理规划。这类时间推理与意图理解能力正是我们希望 didi-ride-skill 所具备的能力。Skill 如何驱动打车Skill 的本质在 OpenClaw 中Skill 本质上是一套“操作规范”会在每次对话时注入到模型上下文中。当你说出“帮我叫车”时OpenClaw 会识别触发条件并加载 didi-ride-skill 的相关内容使 AI 能够懂得并调度滴滴的出行能力。底层能力DiDi MCPdidi-ride-skill 基于滴滴开放的 MCPModel Context Protocol服务构建。MCP 是一种标准化的工具调用协议使 AI 能够以统一方式调用外部服务。当前滴滴 MCP 提供共计 13 个工具。类别工具数能力范围打车服务6价格预估、创建订单、订单查询、司机位置等地图服务7地点/附近搜索、驾车/公交/步行/骑行规划等Skill 的核心职责在于以正确的顺序、参数和时机编排调用这些工具。稳定性设计关键工程决策下面整理几个我们在开发过程中反复遇到并不断打磨的问题。文件拆分与注意力分布初版我们将所有内容直接塞进 SKILL.md 主文件很快就超过了 500 行。于是我们对结构进行了拆分主文件仅保留简要描述将详细内容全部拆分到文件地图中。从结构上看这种方式更加清晰但在实际测试中暴露出两个现实问题一执行时延每当 AI 执行到某个节点需要读取子文件时都会产生一次额外的文件读取。对于打车这种时间敏感场景而言这种“走走停停”的延迟在体验上非常明显。问题二注意力权重AI 实际上会更关注 SKILL.md 主文件以及最近刚读取的文件而文件地图中的“中间文件”在多步骤执行过程中很容易被忽略。这一现象与 LLM 的注意力机制密切相关。研究者 Liu et al. 在 2023 年的论文 Lost in the Middle 中指出Performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access and use information located in the middle.对于 Skill 来说这意味着文件地图中的“中间文件”天然处于注意力洼地。最终我们调整为如下方案主文件保留全流程的简要描述以及关键节点的详细说明仅将真正复杂且相对独立的内容拆分到子文件中。这样既避免了主文件臃肿又减少了多文件读取带来的时延和注意力分散问题。Restatement刻意重复的工程价值细心的朋友在阅读 SKILL.md 时会注意到一个奇怪的现象某些内容出现了不止一次。例如 MCP KEY 的配置要求在主文件中重复出现mcporter 命令的参数格式也在多个文件中多次被强调。Restatement刻意的重复声明在关键节点执行前主动将约束信息再次呈现。其背后的逻辑与上节一致LLM 在长上下文中的注意力是不稳定的。Skill 并不具备 System Prompt 那样的高优先级它本质上只是注入到上下文中的一段内容。因此如果希望 AI 在某个特定步骤中稳定遵循某个约束最可靠的方式是在该步骤执行前将约束信息再次显式说明。多文件交叉验证 关键节点前 Restatement是我们在 Skill 层面对抗 LLM 注意力不稳定性的主要手段。模型能力 VS 确定性脚本初版我们设计了两个脚本文件setup.sh142 行——用于环境初始化create_order.json439 行——用于创建订单和开启回查任务整体思路是让确定性代码承担核心执行从而减少不确定性带来的影响但实际结果并不理想。原因主要有几个OpenClaw 的运行环境差异较大边界情况远超预期单靠 439 行脚本仍然无法完全覆盖脚本输出还需要再交由 AI 进行解析反而引入了额外的信息噪音更关键的是AI 有时会自行“打补丁”修改脚本逻辑而这些隐性修改一旦遇到环境变化就会变成难以排查的隐患。在去掉脚本、改为完整 prompt 引导 参数示例之后执行效果反而更加稳定。AI 能够掌握完整上下文在出错时也能更准确地定位问题。但“信任模型”并不意味着“完全放手”。一个典型的例子是在测试 maps_textsearch 接口时我们发现不同模型会系统性地传入 北京 而不是 北京市以及字段名 keyword 而不是 keywords。这本质上是模型的参数惯性——AI 在生成调用命令时依赖的是训练数据中的统计分布而不是当前文档中的精确约束。由于 北京 出现频率更高因此更容易被默认选用。因此在流程设计上适合信任模型整体能力但在具体存在已知惯性错误的节点需要通过 Restatement 约束进行纠偏。脚本与信任模型并不是二选一的问题关键在于哪些环节需要严格控制哪些环节可以适度放开。平台边界与工程挑战当前 OpenClaw 仍处在高速迭代阶段下面是我们在平台层面遇到的几个典型问题。cron isolated 模式的启动成本cron 定时任务有两种模式main与主对话共享上下文和 isolated每次触发创建全新 context。我们必须使用 isolated——因为 main 模式在长任务场景下定时任务与主对话的上下文容易冲突推送失败率较高。但 isolated 也有明显代价每次触发都会从零构建上下文需要重新读取 Skill 文件并完整理解任务指令单次执行时间可能超过 1 分钟。我们原本的目标是在订单创建后以 30–60 秒间隔持续查询司机状态。但在实际计算后发现这一目标与 isolated 的执行特性无法兼容——任务执行时间本身就已经长于轮询间隔导致任务队列会快速堆积。最终我们做了一个妥协订单创建后只触发一次 5 分钟后的回查任务放弃高频轮询换取整体的简单性与可靠性。虽然用户无法实时感知状态变化但在大多数场景下几分钟后的反馈已经足够。MCP Key 放在哪里被 isolated session 逼出来的选择这个问题初看只是一个配置细节但实际上影响了整个 Skill 的架构设计。我们最初将 MCP KEY 存放在 Skill 目录下。直到测试预约打车时发现cron 任务到点触发后出现静默失败——既没有成功叫车也没有任何报错信息。进一步排查后发现根因在于cron 任务运行在 isolated session 中会从零初始化上下文不继承任何历史状态也就无法知道 KEY 的存放位置最终导致 API 鉴权失败。最终方案是将 KEY 存入 openclaw.json并通过标准命令写入openclaw config set skills.entries.didi-ride-skill.apiKey YOUR_KEYOpenClaw 会在每次 session 启动时包括 isolated session自动将 apiKey 注入为环境变量 DIDI_MCP_KEY。有趣的是我们最初选择这一方案的理由是“安全性”但后来才意识到真正起决定作用的其实是 isolated session 的自动注入机制。其他替代方案如 .env 或 ~/.zshrc都无法保证 isolated session 正确获取 KEY因此会导致预约打车在 cron 触发时出现静默失败。平台迭代带来的权限问题2026 年 3 月底OpenClaw 发布了一次版本更新在所有终端命令执行前新增 pre_hook 权限判断默认需要用户手动 approve。从安全角度来看这是一个完全合理的设计但对 didi-ride-skill 而言影响却非常直接且严重Skill 几乎每一步都依赖终端命令导致整个打车流程在这次更新后被明显阻塞。我们没有任何可以优雅绕过这一机制的方案——既不能要求用户关闭安全保护也无法在 Skill 层面申请权限豁免。本质上这意味着在一个快速迭代的平台上做 Skill 开发需要接受一个现实——平台的任何一次更新都可能让已有能力失效。持续适配不是偶发成本而是必然成本。测试方案设计手工测试已经逐渐跟不上 OpenClaw 平台的迭代速度。更关键的是因为输入与输出的来源本身就是不稳定的打车 Skill 本身无法套用“输入 X → 断言输出 Y”的传统测试方式主要包含以下几方面AI 模型本身不同模型之间甚至同一模型的不同次调用输出都可能存在波动OpenClaw 平台处于高速迭代阶段平台行为会随版本持续变化外部服务滴滴 MCP API 的真实响应会受到网络状况、服务可用性等多种因素影响整体方案测试用例集Input共 24 条测试用例按场景划分为 6 类即时打车、预约出行、偏好记忆、Onboarding、地址挑战、复杂推理。每条用例包含输入 query、期望触发的工具调用序列、关键断言点以及需要检测的风险标记规则。这部分由人工设计并维护。执行引擎Run通过可编程方式驱动 OpenClaw Agent 完成一轮对话并收集 AI 回复文本及完整工具调用记录。该模块仍有优化空间后文会展开说明。评估层Assert Judge分为两类可自动化部分工具调用断言是否调用正确工具、参数格式是否符合预期、风险标记检测是否跳过确认直接下单、是否存在参数幻觉等需人工介入部分回复质量由 LLM-as-Judge 辅助评估但最终仍需人工确认同时cron 定时推送、图片消息等 CLI 无法捕获的场景也依赖人工验证报告输出Output系统自动生成测试报告包括通过率、失败率、风险标记汇总以及工具调用详情为每一轮迭代提供可量化参考。该模块当前处于半自动化状态。具备明确规则的部分由测试 agent 自动完成存在模糊判断空间的 case 以及特殊场景如 cron 推送、图片消息仍依赖人工介入。我们当前的目标是持续收窄“必须人工”的边界。执行引擎如何稳定获取测试数据在解决“如何评估”之前首先要解决“如何获取数据”——即如何以可编程方式驱动 OpenClaw 完成对话并稳定获取 AI 回复内容与工具调用记录。方案一IM 工具收发消息初期尝试通过 IM 工具发送测试消息并等待 Agent 回复看起来是最直接的路径。但实际存在两个关键问题首先Bot 与 Bot 之间的消息传递受事件机制限制无法稳定触发 Skill 响应切换为真实用户后又遇到富媒体能力问题——打车回复中的价格卡片通过 API 获取时只能拿到 fallback 文本核心数据不可见。根本的问题在于IM 通道的异步特性本身就引入了额外复杂度包括轮询等待、消息乱序处理、以及“如何判断回复结束”等工程问题而这些都与测试框架本身目标无关但会显著增加维护成本。方案二OpenClaw Agent CLI当前方案最终我们绕开消息通道直接通过openclaw agentCLI 驱动对话。该方式可以同步返回完整纯文本不受任何消息渠道格式限制同时AI 的工具调用记录可从 OpenClaw 的 JSONL transcript 中直接解析能够精确还原每一次 mcporter 调用的工具名与参数。当前方案的主要局限在于无法验证图片消息是否成功发送以及 cron 定时任务的推送难以自动化验证isolated session 触发的推送在 CLI 层无法直接捕获。写在最后回头看这个项目花在 prompt 措辞和文档结构上的时间甚至超过了“功能代码”本身。传统开发中写完逻辑就结束了而在 Skill 开发里你需要反复验证 AI 是否真的按你写的去执行——而且换一个模型结果可能又完全不同。这大概是 AI Skill 工程与传统软件工程最本质的区别你的“代码”是自然语言而你的“运行时”是一个概率系统。目前 didi-ride-skill 仍有不少待完善的地方cron isolated session 的启动成本依然存在OpenClaw 的每一次更新都可能带来新的适配工作接下来我们计划做行程分享与实时位置推送目前用户在下单后只能等待 5 分钟回查体验链路存在断层适配 OpenClaw 以外的 Agent 平台将测试能力从“半自动”推进到“全自动”至少覆盖 cron 推送验证如果你对 OpenClaw Skill 开发、AI Agent 工程或者打车出行服务感兴趣欢迎试用安装方式在 OpenClaw 里说 「在 ClawHub 上搜索 didi-ride-skill一键安装」MCP Key 申请https://mcp.didichuxing.com开源地址https://github.com/didi/didi-ride-skillClawHub 主页https://clawhub.ai/didi/didi-ride-skill-official