{"id":"d8456627-29d5-4f21-b1f8-4d562f216836","entityType":"agent","slug":"clawhub-travelkit-travelkit-skill","name":"travelkit","canonicalUrl":"https://www.xpersona.co/agent/clawhub-travelkit-travelkit-skill","canonicalPath":"/agent/clawhub-travelkit-travelkit-skill","generatedAt":"2026-10-10T21:56:30.102Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T16:11:42.417Z","emptyReason":null},"description":"TravelKit flight booking and management skill. Use for flight search, pricing, real-time price verification, order creation, payment, cancellation, refund, c... Skill: travelkit Owner: travelkit Summary: TravelKit flight booking and management skill. Use for flight search, pricing, real-time price verification, order creation, payment, cancellation, refund, c... Tags: booking:1.0.9, flight:1.0.9, latest:1.1.0, travel:1.0.9 Version history: v1.1.0 | 2026-06-10T05:08:27.048Z | user TravelKit Skill v1.1.0 - Added yeepay-mobile payment guidance. - Clarified Skill/MCP routing res","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.3K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17dz90teyd795md66f9d4x36s86st5x:travelkit-skill","sourceUrl":"https://clawhub.ai/travelkit/travelkit-skill","homepage":"https://clawhub.ai/travelkit/skills/travelkit-skill","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/travelkit/travelkit-skill","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/travelkit/skills/travelkit-skill","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":63,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"TravelKit flight booking and management skill. Use for flight search, pricing, real-time price verification, order creation, payment, cancellation, refund, c..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T16:11:42.417Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T16:11:42.417Z","emptyReason":null},"stars":null,"forks":null,"downloads":1345,"packageName":null,"latestVersion":"1.1.0","tractionLabel":"1.3K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T16:11:42.417Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T16:11:42.417Z","lastCrawledAt":"2026-10-10T16:11:42.417Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T16:11:42.417Z","lastVerifiedAt":null,"highlights":[{"version":"1.1.0","createdAt":"2026-06-10T05:08:27.048Z","changelog":"TravelKit Skill v1.1.0 - Added yeepay-mobile payment guidance. - Clarified Skill/MCP routing responsibilities. - Added host-provided version notice guidance. - Improved flight search parsing and clarification rules. - Improved abnormal flight number and airport code handling.","fileCount":19,"zipByteSize":33335},{"version":"1.0.9","createdAt":"2026-05-22T06:35:43.205Z","changelog":"TravelKit Skill v1.0.9: Updated ID-card passenger name handling so Chinese document names are no longer split into surname and given names; for travelDocument idcard, the full Chinese document name is sent in givenNames and surname is sent as an empty string; simplified the domestic passenger collection prompt without exposing internal name-mapping details; updated name-error handling so ID-card passengers are asked only to verify or correct the full document name. No MCP tool schemas or tool parameters were changed.","fileCount":19,"zipByteSize":29223},{"version":"1.0.8","createdAt":"2026-05-21T07:18:45.397Z","changelog":"TravelKit Skill v1.0.8: Improved mcp-connection.md to keep first-use and API key troubleshooting guidance ahead of internal remote MCP HTTP reference details; restricted endpoint, header, and curl examples to platform developer/admin requests about remote MCP HTTP integration; kept local MCP setup prevention rules for mcpServers, npx, stdio setup, local MCP server installation, and local config JSON. No MCP tool schemas or tool parameters were changed.","fileCount":18,"zipByteSize":27822},{"version":"1.0.6","createdAt":"2026-05-21T03:06:37.372Z","changelog":"TravelKit Skill v1.0.6: Republished from a clean TravelKit skill bundle that excludes unrelated hotel references and scripts from ClawHub, GitHub, and SkillHub release artifacts; kept v1.0.5 API key guidance, credential routing, and platform-managed credential behavior unchanged. No MCP tool schemas or tool parameters were changed.","fileCount":18,"zipByteSize":26866},{"version":"1.0.5","createdAt":"2026-05-21T02:42:29.225Z","changelog":"TravelKit Skill v1.0.5: Added install and first-use API key guidance pointing users to https://www.travelkit.ai/; updated user-facing wording to say users should preferably not send API keys in chat; unified API key routing and auth error handling under mcp-connection.md; kept credential handling platform-managed and prevented local MCP setup snippets such as mcpServers, npx, stdio server setup, or local config JSON; excluded unrelated hotel files and scripts from the release package. No MCP tool schemas or tool parameters were changed.","fileCount":21,"zipByteSize":33614},{"version":"1.0.4","createdAt":"2026-05-20T09:17:11.849Z","changelog":"TravelKit Skill v1.0.4: Renamed MCP connection guidance to platform credential guidance; updated missing/invalid TRAVELKIT_API_KEY handling to direct users to https://www.travelkit.ai/ for API key application/configuration; prevented agents from generating local MCP configuration snippets such as mcpServers, npx, stdio server setup, or local config JSON; clarified that credentials are platform-managed and must not be pasted into chat, prompts, frontend pages, skill files, examples, or logs. No MCP tool schemas or tool parameters were changed.","fileCount":18,"zipByteSize":26702},{"version":"1.0.3","createdAt":"2026-05-20T06:48:34.639Z","changelog":"TravelKit Skill v1.0.3: Added invoice application and invoice status lookup workflows. Added post-payment polling every 10 seconds up to 12 checks. Added refund and change rule code interpretation. Improved lowest-price search display using data.displayOptions only. Strengthened same-flight multi-fare handling and verification consistency. Improved low-inventory ticket-count reminders, passenger information prompts, optional email handling, order list status localization, and route IATA Chinese display. Compressed skill references to reduce agent response time. Fixed user-visible output rules to omit restricted booking-record fields. Clarified unpaid order, post-payment, and order-lookup status wording. No MCP tool schemas or tool parameters were changed.","fileCount":18,"zipByteSize":26886},{"version":"1.0.2","createdAt":"2026-05-18T09:33:40.252Z","changelog":"Optimized fare amount display and transfer segment time display.","fileCount":17,"zipByteSize":24294}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17dz90teyd795md66f9d4x36s86st5x:travelkit-skill","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-travelkit-travelkit-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-travelkit-travelkit-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-travelkit-travelkit-skill/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-travelkit-travelkit-skill/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-travelkit-travelkit-skill/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-travelkit-travelkit-skill/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T21:56:30.097Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-travelkit-travelkit-skill/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-travelkit-travelkit-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-travelkit-travelkit-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-travelkit-travelkit-skill/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T16:11:42.417Z","emptyReason":null},"readme":"Skill: travelkit\n\nOwner: travelkit\n\nSummary: TravelKit flight booking and management skill. Use for flight search, pricing, real-time price verification, order creation, payment, cancellation, refund, c...\n\nTags: booking:1.0.9, flight:1.0.9, latest:1.1.0, travel:1.0.9\n\nVersion history:\n\nv1.1.0 | 2026-06-10T05:08:27.048Z | user\n\nTravelKit Skill v1.1.0\n\n- Added yeepay-mobile payment guidance.\n- Clarified Skill/MCP routing responsibilities.\n- Added host-provided version notice guidance.\n- Improved flight search parsing and clarification rules.\n- Improved abnormal flight number and airport code handling.\n\nv1.0.9 | 2026-05-22T06:35:43.205Z | user\n\nTravelKit Skill v1.0.9: Updated ID-card passenger name handling so Chinese document names are no longer split into surname and given names; for travelDocument idcard, the full Chinese document name is sent in givenNames and surname is sent as an empty string; simplified the domestic passenger collection prompt without exposing internal name-mapping details; updated name-error handling so ID-card passengers are asked only to verify or correct the full document name. No MCP tool schemas or tool parameters were changed.\n\nv1.0.8 | 2026-05-21T07:18:45.397Z | user\n\nTravelKit Skill v1.0.8: Improved mcp-connection.md to keep first-use and API key troubleshooting guidance ahead of internal remote MCP HTTP reference details; restricted endpoint, header, and curl examples to platform developer/admin requests about remote MCP HTTP integration; kept local MCP setup prevention rules for mcpServers, npx, stdio setup, local MCP server installation, and local config JSON. No MCP tool schemas or tool parameters were changed.\n\nv1.0.6 | 2026-05-21T03:06:37.372Z | user\n\nTravelKit Skill v1.0.6: Republished from a clean TravelKit skill bundle that excludes unrelated hotel references and scripts from ClawHub, GitHub, and SkillHub release artifacts; kept v1.0.5 API key guidance, credential routing, and platform-managed credential behavior unchanged. No MCP tool schemas or tool parameters were changed.\n\nv1.0.5 | 2026-05-21T02:42:29.225Z | user\n\nTravelKit Skill v1.0.5: Added install and first-use API key guidance pointing users to https://www.travelkit.ai/; updated user-facing wording to say users should preferably not send API keys in chat; unified API key routing and auth error handling under mcp-connection.md; kept credential handling platform-managed and prevented local MCP setup snippets such as mcpServers, npx, stdio server setup, or local config JSON; excluded unrelated hotel files and scripts from the release package. No MCP tool schemas or tool parameters were changed.\n\nv1.0.4 | 2026-05-20T09:17:11.849Z | user\n\nTravelKit Skill v1.0.4: Renamed MCP connection guidance to platform credential guidance; updated missing/invalid TRAVELKIT_API_KEY handling to direct users to https://www.travelkit.ai/ for API key application/configuration; prevented agents from generating local MCP configuration snippets such as mcpServers, npx, stdio server setup, or local config JSON; clarified that credentials are platform-managed and must not be pasted into chat, prompts, frontend pages, skill files, examples, or logs. No MCP tool schemas or tool parameters were changed.\n\nv1.0.3 | 2026-05-20T06:48:34.639Z | user\n\nTravelKit Skill v1.0.3: Added invoice application and invoice status lookup workflows. Added post-payment polling every 10 seconds up to 12 checks. Added refund and change rule code interpretation. Improved lowest-price search display using data.displayOptions only. Strengthened same-flight multi-fare handling and verification consistency. Improved low-inventory ticket-count reminders, passenger information prompts, optional email handling, order list status localization, and route IATA Chinese display. Compressed skill references to reduce agent response time. Fixed user-visible output rules to omit restricted booking-record fields. Clarified unpaid order, post-payment, and order-lookup status wording. No MCP tool schemas or tool parameters were changed.\n\nv1.0.2 | 2026-05-18T09:33:40.252Z | user\n\nOptimized fare amount display and transfer segment time display.\n\nv1.0.1 | 2026-05-16T04:12:32.778Z | user\n\n优化了用户确认订单后，Agent 提示收集用户信息的稳定性\n\nv1.0.0 | 2026-05-15T15:54:29.725Z | auto\n\nInitial release of TravelKit flight booking and management skill.\n\n- Provides end-to-end flight lifecycle support: search, pricing, verification, order creation, payment, cancellation, refund, change, and itinerary download.\n- Includes core rules for user privacy, confirmation requirements, and proper data handling.\n- Supports both read and write operations across all major flight management scenarios.\n- Offers detailed routing instructions and fast-reference guides for various user intents.\n- All consumer replies default to Simplified Chinese unless otherwise requested.\n\nv0.1.0 | 2026-05-15T05:30:56.887Z | user\n\nInitial v1 TravelKit flight lifecycle skill.\n\nArchive index:\n\nArchive v1.1.0: 19 files, 33335 bytes\n\nFiles: references/confirmation-rules.md (3320b), references/flight-cancel.md (772b), references/flight-change.md (1619b), references/flight-create-order.md (4765b), references/flight-invoice.md (2324b), references/flight-itinerary.md (1052b), references/flight-order-lookup.md (3183b), references/flight-pay-order.md (3697b), references/flight-pricing.md (2697b), references/flight-refund.md (1962b), references/flight-search.md (8408b), references/flight-verify.md (3768b), references/hidden-fields.md (1338b), references/mcp-connection.md (7270b), references/output-rules.md (5860b), references/tool-categories.md (1780b), skill-card.md (3465b), SKILL.md (5943b), _meta.json (134b)\n\nFile v1.1.0:SKILL.md\n\n---\nname: travelkit\ndescription: TravelKit flight booking and management skill. Use for flight search, pricing, real-time price verification, order creation, payment, cancellation, refund, change, itinerary download, and TravelKit MCP integration policy. Always use this skill for TravelKit flight lifecycle tasks.\nversion: 1.1.0\n---\n\n# TravelKit Flight Skill\n\nKeep consumer replies in Simplified Chinese unless the user requests another language. Load only the smallest reference needed for the current step; do not preload shared references unless the active workflow points to them.\n\n## Tool Routing\n\nWhen this skill applies, always follow this skill workflow first. TravelKit MCP tools are execution primitives inside the workflow, not standalone business entry points.\n\n- Use the Fast Routing table to choose the workflow reference before calling any MCP tool.\n- Call MCP tools only when the active workflow explicitly instructs the call and all required preconditions are met.\n- Do not bypass skill rules because a tool description appears to match the user's request.\n- Keep business decisions, safety checks, user confirmations, passenger-data timing, and output formatting in the skill workflow.\n- Treat MCP tool results as raw capability results; summarize and continue through the skill rules instead of exposing raw tool behavior to users.\n- Before search, lightweight requirement parsing may normalize user intent into internal query parameters. Do not output JSON or a full parsed-field list to normal users unless they explicitly ask for that format.\n\n## Version Notice\n\nIf the host platform or SkillHub injects daily version-check facts, consume them without trying to verify versions independently.\n\n- If `skillVersionStatus` is `outdated`, briefly tell the user the installed TravelKit Skill version is not the latest and recommend updating through SkillHub or the host platform. Include `installedVersion`, `latestVersion`, and `updateUrl` only when provided.\n- If `skillVersionStatus` is `latest`, do not mention version status.\n- If `skillVersionStatus` is `unknown`, do not claim the installed skill is outdated. Only suggest checking SkillHub or the project release page when the user asks about installation, configuration, version, updates, missing tools, API key setup, or unexpected behavior.\n- Version notices must not block or derail normal flight search, booking, payment, refund, change, order lookup, or itinerary workflows.\n- Do not create timers, background jobs, or version polling from the skill. Daily check frequency and per-user/per-workspace state belong to the host platform.\n\n## Fast Routing\n\n| User intent | Read | Tool(s) |\n|---|---|---|\n| Search or compare flights | [flight-search](references/flight-search.md) | `flight_search` |\n| Price a known flight number | [flight-pricing](references/flight-pricing.md) | `flight_pricing` |\n| User selects a search option | [flight-verify](references/flight-verify.md) | `flight_verify_solution` |\n| Create an order after verified price | [flight-create-order](references/flight-create-order.md) | `flight_create_order` |\n| Pay an order | [flight-pay-order](references/flight-pay-order.md) | `flight_pay_order` |\n| Look up orders | [flight-order-lookup](references/flight-order-lookup.md) | `flight_order_detail`, `flight_order_detail_by_external_id`, `flight_order_list` |\n| Invoice application | [flight-invoice](references/flight-invoice.md) | `flight_get_order_invoice_application`, `flight_create_order_invoice_application` |\n| Cancel an order | [flight-cancel](references/flight-cancel.md) | `flight_cancel_order` |\n| Refund | [flight-refund](references/flight-refund.md) | `flight_refund_quote`, `flight_refund_money_search`, `flight_refund_request`, `flight_refund_confirm` |\n| Change flight | [flight-change](references/flight-change.md) | `flight_change_search`, `flight_change_request` |\n| Download itinerary | [flight-itinerary](references/flight-itinerary.md) | `flight_download_itinerary` |\n| API key / credential issues | [mcp-connection](references/mcp-connection.md) | N/A |\n\n## Core Rules\n\n- Search before booking; verify real-time price before collecting passenger information or creating an order.\n- Never expose internal fields such as `solutionId`, `orderKey`, confirmation flags, raw MCP JSON, API keys, `passengerIds`, `segmentIds`, or idempotency keys to normal users.\n- Normal user-visible replies must never contain `PNR`, `airlinePnr`, airline PNR, `票号/PNR`, or `票号 / PNR`; omit or rewrite those fields even if returned, empty, or present in an error message.\n- If `TRAVELKIT_API_KEY` is missing or invalid, treat it only as a platform-managed credential issue. Never invent or output local MCP configuration snippets such as `mcpServers`, `npx`, stdio server setup, or local config JSON.\n- Never invent missing tool data. If baggage, refund/change policy, ticketing, deadline, fees, or status data is absent, say it was not returned.\n- For order creation, order lookup, and post-payment checks, use [output-rules](references/output-rules.md): total price = fare + tax.\n- Search/pricing/verify/order lookup/invoice lookup/itinerary/change-search/refund quote are read operations and can be called as needed.\n- Create order, pay, cancel, create invoice application, refund request/confirm, and change request are write operations; get explicit user confirmation for the exact action first.\n- Search stage collects only route, dates, passenger counts, cabin, and preferences. Collect ID/passport/phone/email only after price verification succeeds and the user confirms they want to proceed.\n\n## Write Confirmation\n\nBefore any write tool, summarize the business action and wait for explicit confirmation. After confirmation, set required internal confirmation fields without asking users about production or technical flags. Read [confirmation-rules](references/confirmation-rules.md) only when preparing a write operation.\n\nFile v1.1.0:_meta.json\n\n{\n \"ownerId\": \"kn7133rxbc7ntadh1bvnyvw96186s3ct\",\n \"slug\": \"travelkit-skill\",\n \"version\": \"1.1.0\",\n \"publishedAt\": 1781068107048\n}\n\nFile v1.1.0:references/confirmation-rules.md\n\n# confirmation-rules ref\n\n## 写入操作确认规则\n\n每次调用写入工具前，**必须获得用户的明确确认**。\n\n### 创建订单（flight_create_order）\n\n确认前重述：\n\n- 航班和路线\n- 出发和到达时间\n- 乘机人姓名\n- 联系信息（含默认值说明）\n- 最终价格（总价 = 票面价 + 税价）\n- 工具返回的行李、退改签、出票等重要注意事项\n\n询问：\n> 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\n用户明确确认后，这一次确认只适用于当前 `flight_create_order` 调用。内部可一次性设置创建订单所需的确认字段，包括生产写入确认字段；不要向普通用户展示\"生产环境\"、\"生产写入\"或要求用户为同一次创建订单进行二次确认。\n\n### 支付订单（flight_pay_order）\n\n确认前重述：\n\n- 订单号\n- 支付金额（总价 = 票面价 + 税价）\n- 支付方式\n- 当前订单状态（已知时）\n\n如果支付方式未知，先请用户选择或确认支付方式；不要自动填入任何默认支付方式。\n\n提示支付方式时，不向普通用户展示余额支付：\n\n- 国内机票：微信、支付宝、易宝移动支付、信用卡、借记卡\n- 国际机票：Airwallex、微信、支付宝、易宝移动支付、信用卡、借记卡\n\n如果用户要求余额支付，不直接发起支付；提示当前可选的用户支付方式并请用户重新选择。\n\n询问：\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\n### 创建发票申请（flight_create_order_invoice_application）\n\n创建前必须先调用 `flight_get_order_invoice_application` 确认订单可申请发票。\n\n确认前重述：\n\n- 订单号\n- 开票公司名称\n- 纳税人识别号\n- 接收邮箱\n- 联系手机号\n- 公司地址、公司电话、开户银行、银行账号、备注（用户提供时）\n\n询问：\n> 确认提交该订单的发票申请吗？\n\n### 取消订单（flight_cancel_order）\n\n确认前重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 取消操作及后果\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n### 提交退票（flight_refund_request / flight_refund_confirm）\n\n确认前重述：\n\n- 需要退票的乘客和航段\n- 退票原因\n- 估算退款金额和手续费（数据返回时）\n- 未返回的费用或政策信息说明\n\n询问：\n> 确认提交退票申请吗？\n\n### 提交改签（flight_change_request）\n\n确认前重述：\n\n- 原航班信息\n- 新航班信息\n- 需要改签的乘客\n- 改签手续费或注意事项（数据返回时）\n- 改签原因\n\n询问：\n> 确认提交改签申请吗？\n\n### 通用原则\n\n- **不得**将\"帮我订\"、\"退了吧\"、\"改一下\"等笼统意图视为足够确认\n- 每次写入操作都是独立的确认，不能将之前的确认视为连续适用\n- 创建订单的一次确认只覆盖该次创建订单；后续支付、取消、退票、改签仍必须重新确认\n- 确认话术使用自然消费者语言，不暴露内部确认字段、环境名称或 MCP 参数\n- 金额或状态出现异常时，先通过读取工具核查，再询问确认\n- 订单金额统一按 `output-rules` 的金额口径处理：总价 = 票面价 + 税价；没有票面价或税价拆分时，不编造拆分\n\nFile v1.1.0:references/flight-cancel.md\n\n# flight-cancel ref\n\n## flight_cancel_order\n\n取消未支付或可取消的机票订单，**必须经用户明确确认**。\n\n### 何时使用\n\n用户主动要求取消订单，且订单处于未支付或可取消状态时。\n\n已支付、已出票、已退款、已改签或不可取消的订单，说明取消可能不适用，视情况建议退票或改签流程。\n\n### 取消前确认\n\n调用 `flight_cancel_order` 前，重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 将要执行的操作\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n**只有用户明确确认后**才调用 `flight_cancel_order`。\n\n### 错误处理\n\n取消失败时，简短说明原因，展示最安全的下一步建议（如改用退票流程）。\n\nFile v1.1.0:references/flight-change.md\n\n# flight-change ref\n\n## flight_change_search / flight_change_request\n\n搜索可改签的航班选项，经用户选定并明确确认后提交改签申请。\n\n### 改签流程\n\n1. 需要时先通过 `flight_order_detail` 查询订单\n2. 确认需要改签的乘客和航段\n3. 询问新出发日期和舱位偏好（缺失时）\n4. 调用 `flight_change_search` 查询可用改签选项\n5. 展示多个改签选项（有时）\n6. 用户选定一个选项\n7. 重述：原航班号、新航班号、乘客、手续费或注意事项（数据返回时）、改签原因\n8. 询问用户明确确认\n9. 确认后调用 `flight_change_request`\n\n**不得**在展示可用改签选项前直接提交改签申请，除非用户在当前对话中已从工具结果中明确指定了有效选项。\n\n### 改签选项展示\n\n展示格式参考搜索结果，每个选项包含：\n\n- 新航班号（只显示完整航班号，不展示航空公司名称）\n- 新出发/到达时间\n- 改签手续费（数据返回时）\n- 可用舱位\n\n改签规则或手续费若以 `*`、`>n`、` 这趟是国内航班，后续需要乘机人证件信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 中文姓名请按证件姓名填写。\n\n- 乘机人姓名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 证件类型\n- 证件号码\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n**International fixed prompt - must output verbatim**:\n\n> 这趟是国际航班，后续需要乘机人护照信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 护照英文姓和英文名需要与护照完全一致。\n\n- 护照英文姓\n- 护照英文名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 护照号码\n- 护照有效期（请填写具体日期）\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n## Passenger Rules\n\n- Required per passenger: phone, document type, document number.\n- Email is optional notification info. If absent, omit passenger `email`; if supplier requires/rejects missing email, ask only for email.\n- ID card, Mainland Travel Permit, and Taiwan Travel Permit names use Chinese as on document; passports use passport English name.\n- For `travelDocument: idcard`, do not split the Chinese document name. Put the full document name in `givenNames` and pass `surname` as an empty string. Do not ask for surname/given-name splitting for compound surnames, ethnic/minority names, long names, or rare characters.\n- Passport passengers still use passport English surname as `surname` and passport English given names as `givenNames`.\n- If document type is unclear or cannot map to supported `travelDocument`, ask only for document type clarification.\n- If contact name/phone is absent, default to first passenger's name/phone, mention this before creation, and do not collect contact email.\n\n## Confirmation Before Creation\n\nBefore `flight_create_order`, summarize flight/route, departure/arrival time, passengers, contact info/defaults, final price, and returned notices. Amount line must be:\n\n> 金额：¥{总价}（票面价 ¥{票面价} + 税价 ¥{税价}）\n\nIf verified solution returned any segment `availability <= 3`, include remaining ticket count, e.g. `当前余票不多，仅剩 {availability} 张，请尽快完成预订和支付；未支付前票价和余票可能变化。` For multi-segment journeys, use lowest returned availability.\n\nAsk:\n> 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\nOnly after explicit confirmation, call `flight_create_order` with verified `orderKey` and required internal confirmation fields; do not mention production/technical flags.\n\n## After Creation\n\n- When useful, call `flight_order_detail` and show `output-rules` fixed order template.\n- Deadlines must come from explicit tool fields; if missing, use `output-rules` deadline wording.\n- Amount: total = fare + tax; sum fare/tax across passengers/segments. If only total is returned, mark fare/tax as `未返回`.\n- If unpaid, prompt payment options: domestic 微信、支付宝、易宝移动支付、信用卡、借记卡; international/cross-border also Airwallex.\n- If low inventory was known, include remaining ticket count and remind prompt payment, otherwise ticket may sell out.\n\n## Errors\n\n- Ask only for missing/corrected fields; do not require resubmitting all passenger details.\n- Name errors (`FirstName`, `LastName`, ID-card full name) mean document-name format issue. For ID-card passengers, ask only to verify or correct the full document name; do not ask for surname/given-name splitting and do not blame price/inventory.\n- If an abnormal order is unpaid and unticketed, re-verify price before creating a corrected new order.\n\nFile v1.1.0:references/flight-invoice.md\n\n# flight-invoice ref\n\n## flight_get_order_invoice_application / flight_create_order_invoice_application\n\nUse for flight order invoice requests: checking whether an order can apply for an invoice, checking invoice application status, and creating an invoice application.\n\n## Workflow\n\n1. Collect or confirm the TravelKit `orderId`.\n2. Always call read-only `flight_get_order_invoice_application` first.\n3. If an application exists, show its status and do not create another application.\n4. If `canApply` is false, show `canApplyReason` when returned and stop.\n5. If `canApply` is true and the user wants to apply, collect invoice information.\n6. Before `flight_create_order_invoice_application`, summarize the application details and ask for explicit confirmation.\n\n## Required Invoice Fields\n\nCollect these fields before creation:\n\n- 开票公司名称 (`companyName`)\n- 纳税人识别号 (`taxNo`)\n- 接收邮箱 (`email`)\n- 联系手机号 (`phone`)\n\nOptional fields:\n\n- 公司地址 (`companyAddress`)\n- 公司电话 (`companyPhone`)\n- 开户银行 (`bankName`)\n- 银行账号 (`bankAccount`)\n- 备注 (`remark`)\n\nUse `invoiceType: normal` by default. Do not ask normal users to choose invoice type unless the tool or product later returns more supported values.\n\n## Status Display\n\nFor query results, show in natural Chinese:\n\n- 是否可申请\n- 不可申请原因（数据返回时）\n- 已有申请 ID、状态、公司名称、创建时间、发送时间（数据返回时）\n\nFor creation success, show:\n\n- 订单号\n- 发票申请 ID\n- 申请状态：`pending` = 待处理 / 待发送，`sent` = 已发送\n- 开票公司名称\n- 创建时间\n- 下一步：待财务处理或已发送，以工具返回状态为准\n\nDo not say the invoice has been issued or emailed unless the tool explicitly returns `sent`.\n\n## Errors\n\n- Email format errors: ask only for the email again; do not re-collect company name, tax number, phone, or optional fields.\n- Duplicate application: explain that the order has already submitted an invoice application and show returned status if available.\n- Order not found, not original order, unsupported status, flight not departed, or other cannot-apply reasons: show the tool-returned reason and do not create.\n- Missing optional fields never block creation unless the tool rejects them.\n\nFile v1.1.0:references/flight-itinerary.md\n\n# flight-itinerary ref\n\n## flight_download_itinerary\n\n下载已出票订单的行程单（电子行程单 / PDF / ZIP）。\n\n### 何时使用\n\n用户主动请求行程单或类行程单票据文件，且订单状态支持下载时。\n\n**不主动**在订单查询或其他操作结束后推送行程单下载。\n\n### 使用方式\n\n调用 `flight_download_itinerary` 时，传入订单号。\n\n请求参数中的 `type` 会影响常见返回格式：\n\n- `type=more`：生成合并文件，通常返回单个 PDF\n- `type=once`：可能生成多个文件，多个文件时可能返回 ZIP 压缩包\n\n下载完成后，说明返回文件的类型（工具返回该信息时）：\n\n- 是 PDF 文件\n- 是 ZIP 压缩包\n- 还是其他格式\n\n最终格式以工具返回的文件类型、响应 `Content-Type` 或文件名后缀为准。工具未返回文件类型信息时，如实说明未返回，不要猜测为 PDF。\n\n### 错误处理\n\n下载失败或订单状态不支持下载时，简短说明原因，建议用户核对订单状态或稍后重试。\n\nFile v1.1.0:references/flight-order-lookup.md\n\n# flight-order-lookup ref\n\n## flight_order_detail / flight_order_detail_by_external_id / flight_order_list\n\n查询用户的机票订单状态和订单列表。\n\n### 工具选择\n\n| 场景 | 使用工具 |\n|------|---------|\n| 用户提供 TravelKit 订单号 | `flight_order_detail` |\n| 用户提供买方侧外部订单号 | `flight_order_detail_by_external_id` |\n| 用户查找历史订单、按路线/日期/状态/票号/订座记录等线索筛选 | `flight_order_list` |\n\n**始终通过工具获取最新状态**，不依赖记忆中的出票、付款、退款或改签状态。\n\nPNR / 航司 PNR 仅可作为内部查单筛选条件；查询结果、订单详情、订单列表、支付后核查和异常说明都不得向普通用户展示 PNR，也不得展示 `PNR: 未返回`、`票号 / PNR` 或 `票号/PNR`。如果工具或错误原因返回 PNR 相关文字，必须改写为不含该词的自然中文。\n\n### 订单详情展示\n\n订单详情必须使用 `output-rules` 中的订单信息固定模板；字段未返回时填\"未返回\"，不要推断。航班只显示完整航班号，不展示航空公司名称。\n\n金额必须按共享口径展示：总价 = 票面价 + 税价。多乘客或多航段时，分别汇总票面价和税价后再计算总价。如果工具只返回总额但没有票面价或税价拆分，固定模板中的缺失拆分字段填\"未返回\"，不要编造。\n\n### 订单列表展示\n\n`flight_order_list` 返回多条结果时：\n\n- 按出发日期排序展示\n- 每条显示：订单号、路线、出发日期、支付状态、出票状态；不得显示 PNR\n- 支付状态和出票状态必须翻译成中文展示，不直接输出英文枚举。常见映射：`closed`=已关闭，`failed`=失败，`pending`/`processing`=处理中，`paid`/`success`/`succeeded`=已支付，`unpaid`/`not_paid`=未支付，`issued`/`ticketed`=已出票，`changed`=已改签，`refunded`=已退款，`cancelled`/`canceled`=已取消。未识别状态显示：`未识别状态（原值）`。\n- 路线展示为 `中文名 三字码 → 中文名 三字码`。中文名优先级：工具返回的中文城市/机场名 > skill 内置常见映射 > agent 明确认识的 IATA 城市码/机场码常识；不确定、冷门、冲突或无法判断城市/机场语义时，只展示原三字码，不编造中文名。\n- 不为了翻译三字码解析 raw JSON、临时调用额外工具或联网查询；不确定时不要解释过多，直接保留原码。\n- 订单列表路线常见城市码：`BJS`=北京，`SHA`=上海，`CAN`=广州，`HGH`=杭州，`DLU`=大理，`BKK`=曼谷，`SEL`=首尔，`TYO`=东京，`LON`=伦敦。\n- 机场码常见映射：`PEK`=北京首都，`PKX`=北京大兴，`PVG`=上海浦东，`SHA`=上海虹桥，`DMK`=曼谷廊曼，`ICN`=首尔仁川，`GMP`=首尔金浦。`SHA` 在城市级路线如 `BJS-SHA` 中展示为 `上海 SHA`；工具明确为机场时展示 `上海虹桥 SHA`。\n- 说明用户可以指定某个订单号继续操作\n\n### 错误处理\n\n订单找不到时，询问：订单号、外部订单号、票号、路线或出发日期，从而帮助定位；不要向普通用户提及 PNR。\n\nFile v1.1.0:references/flight-pay-order.md\n\n# flight-pay-order ref\n\n## Purpose\n\nUse `flight_pay_order` only for an already-created order when the user explicitly wants to pay. Never pay automatically.\n\n## Before Payment\n\n- Restate order number, amount, payment method, and known order status.\n- Amount follows `output-rules`: total = fare + tax.\n- If payment method is missing, ask the user to choose. Do not default.\n- User-facing methods: domestic can show 微信、支付宝、易宝移动支付、信用卡、借记卡; international can also show Airwallex.\n- Do not offer balance payment. If the user asks for it, show the supported user payment methods and ask them to choose again.\n\nInternal channel mapping:\n\n| User method | Tool channel |\n|---|---|\n| Airwallex | `airwallex` |\n| 支付宝 | `yeepay-alipay` |\n| 微信 | `yeepay-wechat` |\n| 易宝移动支付 | `yeepay-mobile` |\n| 信用卡 | `yeepay-credit-card` |\n| 借记卡 | `yeepay-debit-card` |\n\nAsk:\n\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\nCall `flight_pay_order` only after explicit confirmation.\n\n## Payment Link\n\nAfter `flight_pay_order` returns a third-party payment link, use this exact format. Do not expose internal channel names, raw JSON, `returnUrl`, or technical parameters.\n\n```markdown\n{支付方式}支付已发起，请打开链接完成付款：\n\n[前往{支付方式}支付]({支付链接})\n\n订单金额：¥{订单金额}\n交易手续费：¥{交易手续费}\n需支付合计：¥{订单金额 + 交易手续费}\n\n付款完成后告诉我一声，我帮你核查订单和出票状态。\n```\n\n- Payment method names: 微信、支付宝、易宝移动支付、信用卡、借记卡、Airwallex.\n- If payment link is missing, say: `支付链接暂未返回，我会先核查订单支付状态。`\n- Transaction fee must come from the tool. If fee is missing, show `未返回`; then payable total is also `未返回`.\n- Use the configured default third-party `returnUrl`; do not explain it to normal users.\n\n## Risk Checks\n\nBefore retrying payment, call `flight_order_detail` if amount mismatches, fare + tax conflicts with returned total, order status is unclear, prior payment may be processing, order may be expired, or deadline is unclear.\n\n## After User Says Paid\n\nGoal: check payment status and ticketing status without changing the order.\n\n1. Call read-only `flight_order_detail` immediately.\n2. If neither payment nor ticketing has a clear result, poll every 10 seconds（每 10 秒）.\n3. Stop after 12 total checks（12 次）, including the first immediate check.\n4. Use only `flight_order_detail`; never trigger pay, cancel, refund, or change during polling.\n5. Do not message the user on every poll. Reply only on a clear result, query failure, or after all 12 checks.\n6. Prefer background/timer/automation polling when available. If only synchronous waiting works, tell the user you are checking every 10 seconds. If the environment cannot wait or schedule, say so and ask the user to request another check later.\n\nClear results:\n\n- Payment terminal states: paid/success, failed, canceled, expired, or any explicit payment result returned by the tool.\n- Ticketing terminal states: ticketed/success, failed, abnormal, or any explicit ticketing result returned by the tool.\n- Missing or ambiguous fields are not results; keep polling until the limit.\n\nFinal notification must include order number, latest payment status, latest ticketing status, and next step. Use the `output-rules` order template when showing order details.\n\n## Errors\n\nOn payment failure, briefly explain the returned reason, check current order status with `flight_order_detail`, then decide whether retry is appropriate. Do not blindly retry.\n\nFile v1.1.0:references/flight-pricing.md\n\n# flight-pricing ref\n\n## flight_pricing\n\n按指定航班号和舱位查询实时票价，适用于用户已明确知道航班号的场景。\n\n### 何时使用\n\n仅当用户已同时提供以下全部信息时才使用：\n\n- 航班号\n- 出发机场\n- 到达机场\n- 出发日期\n- 舱位等级\n\n以上任意一项缺失，改用 `flight_search` 进行搜索。\n\n### 异常字段处理\n\n如果用户提供了航班号或机场码，但格式明显异常，不要自行编造修正值，也不要假装已经完成航班基础数据校验。\n\n- 航班号格式异常：例如两位航司代码后跟 5 位及以上数字，或混入无法解释的多余字符时，先说明该字段可能有误，并请用户确认最小异常字段。\n- 机场码格式异常：三字码多字、少字、包含非字母字符，或与用户中文城市明显冲突时，先请用户确认机场码或城市。\n- 如果用户同时给了日期、起终点、起降时间或航司前缀，可说明这些条件有助于核对；只有当前系统明确提供航班基础数据或航班号校验服务时，才使用它生成候选。\n- 当前没有可用基础数据校验服务时，不给具体候选航班；改问用户确认正确的航班号、机场码或改用 `flight_search` 按路线日期搜索。\n- 字段粘连时，先拆出确定性高的字段，只确认最小可执行异常字段；不要把孤立多余字符写入查询参数。\n\n### 参数说明\n\n| 参数 | 是否必填 | 说明 |\n|------|---------|------|\n| `flightNo` | 必填 | 航班号，如 `CA1234` |\n| `origin` | 必填 | 出发机场 IATA 码 |\n| `destination` | 必填 | 到达机场 IATA 码 |\n| `departureDate` | 必填 | 出发日期 `YYYY-MM-DD` |\n| `cabinClass` | 必填 | `economy` / `business` / `first` |\n| `adult` | 必填 | 成人人数 |\n| `child` | 可选 | 儿童人数 |\n| `infant` | 可选 | 婴儿人数 |\n\n### 结果展示规则\n\n展示工具返回的可用票价选项，每个选项包含（数据返回时）：\n\n- 舱位等级和子舱位代码\n- 价格\n- 行李额\n- 退改规则摘要\n\n退改规则若以 `*`、`>n`、`n`、` 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\n用户明确确认后，这一次确认只适用于当前 `flight_create_order` 调用。内部可一次性设置创建订单所需的确认字段，包括生产写入确认字段；不要向普通用户展示\"生产环境\"、\"生产写入\"或要求用户为同一次创建订单进行二次确认。\n\n### 支付订单（flight_pay_order）\n\n确认前重述：\n\n- 订单号\n- 支付金额（总价 = 票面价 + 税价）\n- 支付方式\n- 当前订单状态（已知时）\n\n如果支付方式未知，先请用户选择或确认支付方式；不要自动填入任何默认支付方式。\n\n提示支付方式时，不向普通用户展示余额支付：\n\n- 国内机票：微信、支付宝、信用卡、借记卡\n- 国际机票：Airwallex、微信、支付宝、信用卡、借记卡\n\n如果用户要求余额支付，不直接发起支付；提示当前可选的用户支付方式并请用户重新选择。\n\n询问：\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\n### 创建发票申请（flight_create_order_invoice_application）\n\n创建前必须先调用 `flight_get_order_invoice_application` 确认订单可申请发票。\n\n确认前重述：\n\n- 订单号\n- 开票公司名称\n- 纳税人识别号\n- 接收邮箱\n- 联系手机号\n- 公司地址、公司电话、开户银行、银行账号、备注（用户提供时）\n\n询问：\n> 确认提交该订单的发票申请吗？\n\n### 取消订单（flight_cancel_order）\n\n确认前重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 取消操作及后果\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n### 提交退票（flight_refund_request / flight_refund_confirm）\n\n确认前重述：\n\n- 需要退票的乘客和航段\n- 退票原因\n- 估算退款金额和手续费（数据返回时）\n- 未返回的费用或政策信息说明\n\n询问：\n> 确认提交退票申请吗？\n\n### 提交改签（flight_change_request）\n\n确认前重述：\n\n- 原航班信息\n- 新航班信息\n- 需要改签的乘客\n- 改签手续费或注意事项（数据返回时）\n- 改签原因\n\n询问：\n> 确认提交改签申请吗？\n\n### 通用原则\n\n- **不得**将\"帮我订\"、\"退了吧\"、\"改一下\"等笼统意图视为足够确认\n- 每次写入操作都是独立的确认，不能将之前的确认视为连续适用\n- 创建订单的一次确认只覆盖该次创建订单；后续支付、取消、退票、改签仍必须重新确认\n- 确认话术使用自然消费者语言，不暴露内部确认字段、环境名称或 MCP 参数\n- 金额或状态出现异常时，先通过读取工具核查，再询问确认\n- 订单金额统一按 `output-rules` 的金额口径处理：总价 = 票面价 + 税价；没有票面价或税价拆分时，不编造拆分\n\nFile v1.0.9:references/flight-cancel.md\n\n# flight-cancel ref\n\n## flight_cancel_order\n\n取消未支付或可取消的机票订单，**必须经用户明确确认**。\n\n### 何时使用\n\n用户主动要求取消订单，且订单处于未支付或可取消状态时。\n\n已支付、已出票、已退款、已改签或不可取消的订单，说明取消可能不适用，视情况建议退票或改签流程。\n\n### 取消前确认\n\n调用 `flight_cancel_order` 前，重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 将要执行的操作\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n**只有用户明确确认后**才调用 `flight_cancel_order`。\n\n### 错误处理\n\n取消失败时，简短说明原因，展示最安全的下一步建议（如改用退票流程）。\n\nFile v1.0.9:references/flight-change.md\n\n# flight-change ref\n\n## flight_change_search / flight_change_request\n\n搜索可改签的航班选项，经用户选定并明确确认后提交改签申请。\n\n### 改签流程\n\n1. 需要时先通过 `flight_order_detail` 查询订单\n2. 确认需要改签的乘客和航段\n3. 询问新出发日期和舱位偏好（缺失时）\n4. 调用 `flight_change_search` 查询可用改签选项\n5. 展示多个改签选项（有时）\n6. 用户选定一个选项\n7. 重述：原航班号、新航班号、乘客、手续费或注意事项（数据返回时）、改签原因\n8. 询问用户明确确认\n9. 确认后调用 `flight_change_request`\n\n**不得**在展示可用改签选项前直接提交改签申请，除非用户在当前对话中已从工具结果中明确指定了有效选项。\n\n### 改签选项展示\n\n展示格式参考搜索结果，每个选项包含：\n\n- 新航班号（只显示完整航班号，不展示航空公司名称）\n- 新出发/到达时间\n- 改签手续费（数据返回时）\n- 可用舱位\n\n改签规则或手续费若以 `*`、`>n`、` 这趟是国内航班，后续需要乘机人证件信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 中文姓名请按证件姓名填写。\n\n- 乘机人姓名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 证件类型\n- 证件号码\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n**International fixed prompt - must output verbatim**:\n\n> 这趟是国际航班，后续需要乘机人护照信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 护照英文姓和英文名需要与护照完全一致。\n\n- 护照英文姓\n- 护照英文名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 护照号码\n- 护照有效期（请填写具体日期）\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n## Passenger Rules\n\n- Required per passenger: phone, document type, document number.\n- Email is optional notification info. If absent, omit passenger `email`; if supplier requires/rejects missing email, ask only for email.\n- ID card, Mainland Travel Permit, and Taiwan Travel Permit names use Chinese as on document; passports use passport English name.\n- For `travelDocument: idcard`, do not split the Chinese document name. Put the full document name in `givenNames` and pass `surname` as an empty string. Do not ask for surname/given-name splitting for compound surnames, ethnic/minority names, long names, or rare characters.\n- Passport passengers still use passport English surname as `surname` and passport English given names as `givenNames`.\n- If document type is unclear or cannot map to supported `travelDocument`, ask only for document type clarification.\n- If contact name/phone is absent, default to first passenger's name/phone, mention this before creation, and do not collect contact email.\n\n## Confirmation Before Creation\n\nBefore `flight_create_order`, summarize flight/route, departure/arrival time, passengers, contact info/defaults, final price, and returned notices. Amount line must be:\n\n> 金额：¥{总价}（票面价 ¥{票面价} + 税价 ¥{税价}）\n\nIf verified solution returned any segment `availability <= 3`, include remaining ticket count, e.g. `当前余票不多，仅剩 {availability} 张，请尽快完成预订和支付；未支付前票价和余票可能变化。` For multi-segment journeys, use lowest returned availability.\n\nAsk:\n> 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\nOnly after explicit confirmation, call `flight_create_order` with verified `orderKey` and required internal confirmation fields; do not mention production/technical flags.\n\n## After Creation\n\n- When useful, call `flight_order_detail` and show `output-rules` fixed order template.\n- Deadlines must come from explicit tool fields; if missing, use `output-rules` deadline wording.\n- Amount: total = fare + tax; sum fare/tax across passengers/segments. If only total is returned, mark fare/tax as `未返回`.\n- If unpaid, prompt payment options: domestic 微信、支付宝、信用卡、借记卡; international/cross-border also Airwallex.\n- If low inventory was known, include remaining ticket count and remind prompt payment, otherwise ticket may sell out.\n\n## Errors\n\n- Ask only for missing/corrected fields; do not require resubmitting all passenger details.\n- Name errors (`FirstName`, `LastName`, ID-card full name) mean document-name format issue. For ID-card passengers, ask only to verify or correct the full document name; do not ask for surname/given-name splitting and do not blame price/inventory.\n- If an abnormal order is unpaid and unticketed, re-verify price before creating a corrected new order.\n\nFile v1.0.9:references/flight-invoice.md\n\n# flight-invoice ref\n\n## flight_get_order_invoice_application / flight_create_order_invoice_application\n\nUse for flight order invoice requests: checking whether an order can apply for an invoice, checking invoice application status, and creating an invoice application.\n\n## Workflow\n\n1. Collect or confirm the TravelKit `orderId`.\n2. Always call read-only `flight_get_order_invoice_application` first.\n3. If an application exists, show its status and do not create another application.\n4. If `canApply` is false, show `canApplyReason` when returned and stop.\n5. If `canApply` is true and the user wants to apply, collect invoice information.\n6. Before `flight_create_order_invoice_application`, summarize the application details and ask for explicit confirmation.\n\n## Required Invoice Fields\n\nCollect these fields before creation:\n\n- 开票公司名称 (`companyName`)\n- 纳税人识别号 (`taxNo`)\n- 接收邮箱 (`email`)\n- 联系手机号 (`phone`)\n\nOptional fields:\n\n- 公司地址 (`companyAddress`)\n- 公司电话 (`companyPhone`)\n- 开户银行 (`bankName`)\n- 银行账号 (`bankAccount`)\n- 备注 (`remark`)\n\nUse `invoiceType: normal` by default. Do not ask normal users to choose invoice type unless the tool or product later returns more supported values.\n\n## Status Display\n\nFor query results, show in natural Chinese:\n\n- 是否可申请\n- 不可申请原因（数据返回时）\n- 已有申请 ID、状态、公司名称、创建时间、发送时间（数据返回时）\n\nFor creation success, show:\n\n- 订单号\n- 发票申请 ID\n- 申请状态：`pending` = 待处理 / 待发送，`sent` = 已发送\n- 开票公司名称\n- 创建时间\n- 下一步：待财务处理或已发送，以工具返回状态为准\n\nDo not say the invoice has been issued or emailed unless the tool explicitly returns `sent`.\n\n## Errors\n\n- Email format errors: ask only for the email again; do not re-collect company name, tax number, phone, or optional fields.\n- Duplicate application: explain that the order has already submitted an invoice application and show returned status if available.\n- Order not found, not original order, unsupported status, flight not departed, or other cannot-apply reasons: show the tool-returned reason and do not create.\n- Missing optional fields never block creation unless the tool rejects them.\n\nFile v1.0.9:references/flight-itinerary.md\n\n# flight-itinerary ref\n\n## flight_download_itinerary\n\n下载已出票订单的行程单（电子行程单 / PDF / ZIP）。\n\n### 何时使用\n\n用户主动请求行程单或类行程单票据文件，且订单状态支持下载时。\n\n**不主动**在订单查询或其他操作结束后推送行程单下载。\n\n### 使用方式\n\n调用 `flight_download_itinerary` 时，传入订单号。\n\n请求参数中的 `type` 会影响常见返回格式：\n\n- `type=more`：生成合并文件，通常返回单个 PDF\n- `type=once`：可能生成多个文件，多个文件时可能返回 ZIP 压缩包\n\n下载完成后，说明返回文件的类型（工具返回该信息时）：\n\n- 是 PDF 文件\n- 是 ZIP 压缩包\n- 还是其他格式\n\n最终格式以工具返回的文件类型、响应 `Content-Type` 或文件名后缀为准。工具未返回文件类型信息时，如实说明未返回，不要猜测为 PDF。\n\n### 错误处理\n\n下载失败或订单状态不支持下载时，简短说明原因，建议用户核对订单状态或稍后重试。\n\nFile v1.0.9:references/flight-order-lookup.md\n\n# flight-order-lookup ref\n\n## flight_order_detail / flight_order_detail_by_external_id / flight_order_list\n\n查询用户的机票订单状态和订单列表。\n\n### 工具选择\n\n| 场景 | 使用工具 |\n|------|---------|\n| 用户提供 TravelKit 订单号 | `flight_order_detail` |\n| 用户提供买方侧外部订单号 | `flight_order_detail_by_external_id` |\n| 用户查找历史订单、按路线/日期/状态/票号/订座记录等线索筛选 | `flight_order_list` |\n\n**始终通过工具获取最新状态**，不依赖记忆中的出票、付款、退款或改签状态。\n\nPNR / 航司 PNR 仅可作为内部查单筛选条件；查询结果、订单详情、订单列表、支付后核查和异常说明都不得向普通用户展示 PNR，也不得展示 `PNR: 未返回`、`票号 / PNR` 或 `票号/PNR`。如果工具或错误原因返回 PNR 相关文字，必须改写为不含该词的自然中文。\n\n### 订单详情展示\n\n订单详情必须使用 `output-rules` 中的订单信息固定模板；字段未返回时填\"未返回\"，不要推断。航班只显示完整航班号，不展示航空公司名称。\n\n金额必须按共享口径展示：总价 = 票面价 + 税价。多乘客或多航段时，分别汇总票面价和税价后再计算总价。如果工具只返回总额但没有票面价或税价拆分，固定模板中的缺失拆分字段填\"未返回\"，不要编造。\n\n### 订单列表展示\n\n`flight_order_list` 返回多条结果时：\n\n- 按出发日期排序展示\n- 每条显示：订单号、路线、出发日期、支付状态、出票状态；不得显示 PNR\n- 支付状态和出票状态必须翻译成中文展示，不直接输出英文枚举。常见映射：`closed`=已关闭，`failed`=失败，`pending`/`processing`=处理中，`paid`/`success`/`succeeded`=已支付，`unpaid`/`not_paid`=未支付，`issued`/`ticketed`=已出票，`changed`=已改签，`refunded`=已退款，`cancelled`/`canceled`=已取消。未识别状态显示：`未识别状态（原值）`。\n- 路线展示为 `中文名 三字码 → 中文名 三字码`。中文名优先级：工具返回的中文城市/机场名 > skill 内置常见映射 > agent 明确认识的 IATA 城市码/机场码常识；不确定、冷门、冲突或无法判断城市/机场语义时，只展示原三字码，不编造中文名。\n- 不为了翻译三字码解析 raw JSON、临时调用额外工具或联网查询；不确定时不要解释过多，直接保留原码。\n- 订单列表路线常见城市码：`BJS`=北京，`SHA`=上海，`CAN`=广州，`HGH`=杭州，`DLU`=大理，`BKK`=曼谷，`SEL`=首尔，`TYO`=东京，`LON`=伦敦。\n- 机场码常见映射：`PEK`=北京首都，`PKX`=北京大兴，`PVG`=上海浦东，`SHA`=上海虹桥，`DMK`=曼谷廊曼，`ICN`=首尔仁川，`GMP`=首尔金浦。`SHA` 在城市级路线如 `BJS-SHA` 中展示为 `上海 SHA`；工具明确为机场时展示 `上海虹桥 SHA`。\n- 说明用户可以指定某个订单号继续操作\n\n### 错误处理\n\n订单找不到时，询问：订单号、外部订单号、票号、路线或出发日期，从而帮助定位；不要向普通用户提及 PNR。\n\nFile v1.0.9:references/flight-pay-order.md\n\n# flight-pay-order ref\n\n## Purpose\n\nUse `flight_pay_order` only for an already-created order when the user explicitly wants to pay. Never pay automatically.\n\n## Before Payment\n\n- Restate order number, amount, payment method, and known order status.\n- Amount follows `output-rules`: total = fare + tax.\n- If payment method is missing, ask the user to choose. Do not default.\n- User-facing methods: domestic can show 微信、支付宝、信用卡、借记卡; international can also show Airwallex.\n- Do not offer balance payment. If the user asks for it, show the supported user payment methods and ask them to choose again.\n\nInternal channel mapping:\n\n| User method | Tool channel |\n|---|---|\n| Airwallex | `airwallex` |\n| 支付宝 | `yeepay-alipay` |\n| 微信 | `yeepay-wechat` |\n| 信用卡 | `yeepay-credit-card` |\n| 借记卡 | `yeepay-debit-card` |\n\nAsk:\n\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\nCall `flight_pay_order` only after explicit confirmation.\n\n## Payment Link\n\nAfter `flight_pay_order` returns a third-party payment link, use this exact format. Do not expose internal channel names, raw JSON, `returnUrl`, or technical parameters.\n\n```markdown\n{支付方式}支付已发起，请打开链接完成付款：\n\n[前往{支付方式}支付]({支付链接})\n\n订单金额：¥{订单金额}\n交易手续费：¥{交易手续费}\n需支付合计：¥{订单金额 + 交易手续费}\n\n付款完成后告诉我一声，我帮你核查订单和出票状态。\n```\n\n- Payment method names: 微信、支付宝、信用卡、借记卡、Airwallex.\n- If payment link is missing, say: `支付链接暂未返回，我会先核查订单支付状态。`\n- Transaction fee must come from the tool. If fee is missing, show `未返回`; then payable total is also `未返回`.\n- Use the configured default third-party `returnUrl`; do not explain it to normal users.\n\n## Risk Checks\n\nBefore retrying payment, call `flight_order_detail` if amount mismatches, fare + tax conflicts with returned total, order status is unclear, prior payment may be processing, order may be expired, or deadline is unclear.\n\n## After User Says Paid\n\nGoal: check payment status and ticketing status without changing the order.\n\n1. Call read-only `flight_order_detail` immediately.\n2. If neither payment nor ticketing has a clear result, poll every 10 seconds（每 10 秒）.\n3. Stop after 12 total checks（12 次）, including the first immediate check.\n4. Use only `flight_order_detail`; never trigger pay, cancel, refund, or change during polling.\n5. Do not message the user on every poll. Reply only on a clear result, query failure, or after all 12 checks.\n6. Prefer background/timer/automation polling when available. If only synchronous waiting works, tell the user you are checking every 10 seconds. If the environment cannot wait or schedule, say so and ask the user to request another check later.\n\nClear results:\n\n- Payment terminal states: paid/success, failed, canceled, expired, or any explicit payment result returned by the tool.\n- Ticketing terminal states: ticketed/success, failed, abnormal, or any explicit ticketing result returned by the tool.\n- Missing or ambiguous fields are not results; keep polling until the limit.\n\nFinal notification must include order number, latest payment status, latest ticketing status, and next step. Use the `output-rules` order template when showing order details.\n\n## Errors\n\nOn payment failure, briefly explain the returned reason, check current order status with `flight_order_detail`, then decide whether retry is appropriate. Do not blindly retry.\n\nFile v1.0.9:references/flight-pricing.md\n\n# flight-pricing ref\n\n## flight_pricing\n\n按指定航班号和舱位查询实时票价，适用于用户已明确知道航班号的场景。\n\n### 何时使用\n\n仅当用户已同时提供以下全部信息时才使用：\n\n- 航班号\n- 出发机场\n- 到达机场\n- 出发日期\n- 舱位等级\n\n以上任意一项缺失，改用 `flight_search` 进行搜索。\n\n### 参数说明\n\n| 参数 | 是否必填 | 说明 |\n|------|---------|------|\n| `flightNo` | 必填 | 航班号，如 `CA1234` |\n| `origin` | 必填 | 出发机场 IATA 码 |\n| `destination` | 必填 | 到达机场 IATA 码 |\n| `departureDate` | 必填 | 出发日期 `YYYY-MM-DD` |\n| `cabinClass` | 必填 | `economy` / `business` / `first` |\n| `adult` | 必填 | 成人人数 |\n| `child` | 可选 | 儿童人数 |\n| `infant` | 可选 | 婴儿人数 |\n\n### 结果展示规则\n\n展示工具返回的可用票价选项，每个选项包含（数据返回时）：\n\n- 舱位等级和子舱位代码\n- 价格\n- 行李额\n- 退改规则摘要\n\n退改规则若以 `*`、`>n`、`n`、` 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\n用户明确确认后，这一次确认只适用于当前 `flight_create_order` 调用。内部可一次性设置创建订单所需的确认字段，包括生产写入确认字段；不要向普通用户展示\"生产环境\"、\"生产写入\"或要求用户为同一次创建订单进行二次确认。\n\n### 支付订单（flight_pay_order）\n\n确认前重述：\n\n- 订单号\n- 支付金额（总价 = 票面价 + 税价）\n- 支付方式\n- 当前订单状态（已知时）\n\n如果支付方式未知，先请用户选择或确认支付方式；不要自动填入任何默认支付方式。\n\n提示支付方式时，不向普通用户展示余额支付：\n\n- 国内机票：微信、支付宝、信用卡、借记卡\n- 国际机票：Airwallex、微信、支付宝、信用卡、借记卡\n\n如果用户要求余额支付，不直接发起支付；提示当前可选的用户支付方式并请用户重新选择。\n\n询问：\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\n### 创建发票申请（flight_create_order_invoice_application）\n\n创建前必须先调用 `flight_get_order_invoice_application` 确认订单可申请发票。\n\n确认前重述：\n\n- 订单号\n- 开票公司名称\n- 纳税人识别号\n- 接收邮箱\n- 联系手机号\n- 公司地址、公司电话、开户银行、银行账号、备注（用户提供时）\n\n询问：\n> 确认提交该订单的发票申请吗？\n\n### 取消订单（flight_cancel_order）\n\n确认前重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 取消操作及后果\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n### 提交退票（flight_refund_request / flight_refund_confirm）\n\n确认前重述：\n\n- 需要退票的乘客和航段\n- 退票原因\n- 估算退款金额和手续费（数据返回时）\n- 未返回的费用或政策信息说明\n\n询问：\n> 确认提交退票申请吗？\n\n### 提交改签（flight_change_request）\n\n确认前重述：\n\n- 原航班信息\n- 新航班信息\n- 需要改签的乘客\n- 改签手续费或注意事项（数据返回时）\n- 改签原因\n\n询问：\n> 确认提交改签申请吗？\n\n### 通用原则\n\n- **不得**将\"帮我订\"、\"退了吧\"、\"改一下\"等笼统意图视为足够确认\n- 每次写入操作都是独立的确认，不能将之前的确认视为连续适用\n- 创建订单的一次确认只覆盖该次创建订单；后续支付、取消、退票、改签仍必须重新确认\n- 确认话术使用自然消费者语言，不暴露内部确认字段、环境名称或 MCP 参数\n- 金额或状态出现异常时，先通过读取工具核查，再询问确认\n- 订单金额统一按 `output-rules` 的金额口径处理：总价 = 票面价 + 税价；没有票面价或税价拆分时，不编造拆分\n\nFile v1.0.8:references/flight-cancel.md\n\n# flight-cancel ref\n\n## flight_cancel_order\n\n取消未支付或可取消的机票订单，**必须经用户明确确认**。\n\n### 何时使用\n\n用户主动要求取消订单，且订单处于未支付或可取消状态时。\n\n已支付、已出票、已退款、已改签或不可取消的订单，说明取消可能不适用，视情况建议退票或改签流程。\n\n### 取消前确认\n\n调用 `flight_cancel_order` 前，重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 将要执行的操作\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n**只有用户明确确认后**才调用 `flight_cancel_order`。\n\n### 错误处理\n\n取消失败时，简短说明原因，展示最安全的下一步建议（如改用退票流程）。\n\nFile v1.0.8:references/flight-change.md\n\n# flight-change ref\n\n## flight_change_search / flight_change_request\n\n搜索可改签的航班选项，经用户选定并明确确认后提交改签申请。\n\n### 改签流程\n\n1. 需要时先通过 `flight_order_detail` 查询订单\n2. 确认需要改签的乘客和航段\n3. 询问新出发日期和舱位偏好（缺失时）\n4. 调用 `flight_change_search` 查询可用改签选项\n5. 展示多个改签选项（有时）\n6. 用户选定一个选项\n7. 重述：原航班号、新航班号、乘客、手续费或注意事项（数据返回时）、改签原因\n8. 询问用户明确确认\n9. 确认后调用 `flight_change_request`\n\n**不得**在展示可用改签选项前直接提交改签申请，除非用户在当前对话中已从工具结果中明确指定了有效选项。\n\n### 改签选项展示\n\n展示格式参考搜索结果，每个选项包含：\n\n- 新航班号（只显示完整航班号，不展示航空公司名称）\n- 新出发/到达时间\n- 改签手续费（数据返回时）\n- 可用舱位\n\n改签规则或手续费若以 `*`、`>n`、` 这趟是国内航班，后续需要乘机人证件信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 中文姓名我会按证件姓名识别姓、名；如果复姓或拆分不确定，我再单独确认。\n\n- 乘机人姓名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 证件类型\n- 证件号码\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n**International fixed prompt - must output verbatim**:\n\n> 这趟是国际航班，后续需要乘机人护照信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 护照英文姓和英文名需要与护照完全一致。\n\n- 护照英文姓\n- 护照英文名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 护照号码\n- 护照有效期（请填写具体日期）\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n## Passenger Rules\n\n- Required per passenger: phone, document type, document number.\n- Email is optional notification info. If absent, omit passenger `email`; if supplier requires/rejects missing email, ask only for email.\n- ID card, Mainland Travel Permit, and Taiwan Travel Permit names use Chinese as on document; passports use passport English name.\n- For ID-card passengers, split one Chinese full name internally. Ask only if compound surname, ethnic/minority name, English name, very long name, or rare characters make splitting unclear.\n- If document type is unclear or cannot map to supported `travelDocument`, ask only for document type clarification.\n- If contact name/phone is absent, default to first passenger's name/phone, mention this before creation, and do not collect contact email.\n\n## Confirmation Before Creation\n\nBefore `flight_create_order`, summarize flight/route, departure/arrival time, passengers, contact info/defaults, final price, and returned notices. Amount line must be:\n\n> 金额：¥{总价}（票面价 ¥{票面价} + 税价 ¥{税价}）\n\nIf verified solution returned any segment `availability <= 3`, include remaining ticket count, e.g. `当前余票不多，仅剩 {availability} 张，请尽快完成预订和支付；未支付前票价和余票可能变化。` For multi-segment journeys, use lowest returned availability.\n\nAsk:\n> 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\nOnly after explicit confirmation, call `flight_create_order` with verified `orderKey` and required internal confirmation fields; do not mention production/technical flags.\n\n## After Creation\n\n- When useful, call `flight_order_detail` and show `output-rules` fixed order template.\n- Deadlines must come from explicit tool fields; if missing, use `output-rules` deadline wording.\n- Amount: total = fare + tax; sum fare/tax across passengers/segments. If only total is returned, mark fare/tax as `未返回`.\n- If unpaid, prompt payment options: domestic 微信、支付宝、信用卡、借记卡; international/cross-border also Airwallex.\n- If low inventory was known, include remaining ticket count and remind prompt payment, otherwise ticket may sell out.\n\n## Errors\n\n- Ask only for missing/corrected fields; do not require resubmitting all passenger details.\n- Name errors (`FirstName`, `LastName`, ID-card full name) mean document-name format issue; ask only for name correction and do not blame price/inventory.\n- If an abnormal order is unpaid and unticketed, re-verify price before creating a corrected new order.\n\nFile v1.0.8:references/flight-invoice.md\n\n# flight-invoice ref\n\n## flight_get_order_invoice_application / flight_create_order_invoice_application\n\nUse for flight order invoice requests: checking whether an order can apply for an invoice, checking invoice application status, and creating an invoice application.\n\n## Workflow\n\n1. Collect or confirm the TravelKit `orderId`.\n2. Always call read-only `flight_get_order_invoice_application` first.\n3. If an application exists, show its status and do not create another application.\n4. If `canApply` is false, show `canApplyReason` when returned and stop.\n5. If `canApply` is true and the user wants to apply, collect invoice information.\n6. Before `flight_create_order_invoice_application`, summarize the application details and ask for explicit confirmation.\n\n## Required Invoice Fields\n\nCollect these fields before creation:\n\n- 开票公司名称 (`companyName`)\n- 纳税人识别号 (`taxNo`)\n- 接收邮箱 (`email`)\n- 联系手机号 (`phone`)\n\nOptional fields:\n\n- 公司地址 (`companyAddress`)\n- 公司电话 (`companyPhone`)\n- 开户银行 (`bankName`)\n- 银行账号 (`bankAccount`)\n- 备注 (`remark`)\n\nUse `invoiceType: normal` by default. Do not ask normal users to choose invoice type unless the tool or product later returns more supported values.\n\n## Status Display\n\nFor query results, show in natural Chinese:\n\n- 是否可申请\n- 不可申请原因（数据返回时）\n- 已有申请 ID、状态、公司名称、创建时间、发送时间（数据返回时）\n\nFor creation success, show:\n\n- 订单号\n- 发票申请 ID\n- 申请状态：`pending` = 待处理 / 待发送，`sent` = 已发送\n- 开票公司名称\n- 创建时间\n- 下一步：待财务处理或已发送，以工具返回状态为准\n\nDo not say the invoice has been issued or emailed unless the tool explicitly returns `sent`.\n\n## Errors\n\n- Email format errors: ask only for the email again; do not re-collect company name, tax number, phone, or optional fields.\n- Duplicate application: explain that the order has already submitted an invoice application and show returned status if available.\n- Order not found, not original order, unsupported status, flight not departed, or other cannot-apply reasons: show the tool-returned reason and do not create.\n- Missing optional fields never block creation unless the tool rejects them.\n\nFile v1.0.8:references/flight-itinerary.md\n\n# flight-itinerary ref\n\n## flight_download_itinerary\n\n下载已出票订单的行程单（电子行程单 / PDF / ZIP）。\n\n### 何时使用\n\n用户主动请求行程单或类行程单票据文件，且订单状态支持下载时。\n\n**不主动**在订单查询或其他操作结束后推送行程单下载。\n\n### 使用方式\n\n调用 `flight_download_itinerary` 时，传入订单号。\n\n请求参数中的 `type` 会影响常见返回格式：\n\n- `type=more`：生成合并文件，通常返回单个 PDF\n- `type=once`：可能生成多个文件，多个文件时可能返回 ZIP 压缩包\n\n下载完成后，说明返回文件的类型（工具返回该信息时）：\n\n- 是 PDF 文件\n- 是 ZIP 压缩包\n- 还是其他格式\n\n最终格式以工具返回的文件类型、响应 `Content-Type` 或文件名后缀为准。工具未返回文件类型信息时，如实说明未返回，不要猜测为 PDF。\n\n### 错误处理\n\n下载失败或订单状态不支持下载时，简短说明原因，建议用户核对订单状态或稍后重试。\n\nFile v1.0.8:references/flight-order-lookup.md\n\n# flight-order-lookup ref\n\n## flight_order_detail / flight_order_detail_by_external_id / flight_order_list\n\n查询用户的机票订单状态和订单列表。\n\n### 工具选择\n\n| 场景 | 使用工具 |\n|------|---------|\n| 用户提供 TravelKit 订单号 | `flight_order_detail` |\n| 用户提供买方侧外部订单号 | `flight_order_detail_by_external_id` |\n| 用户查找历史订单、按路线/日期/状态/票号/订座记录等线索筛选 | `flight_order_list` |\n\n**始终通过工具获取最新状态**，不依赖记忆中的出票、付款、退款或改签状态。\n\nPNR / 航司 PNR 仅可作为内部查单筛选条件；查询结果、订单详情、订单列表、支付后核查和异常说明都不得向普通用户展示 PNR，也不得展示 `PNR: 未返回`、`票号 / PNR` 或 `票号/PNR`。如果工具或错误原因返回 PNR 相关文字，必须改写为不含该词的自然中文。\n\n### 订单详情展示\n\n订单详情必须使用 `output-rules` 中的订单信息固定模板；字段未返回时填\"未返回\"，不要推断。航班只显示完整航班号，不展示航空公司名称。\n\n金额必须按共享口径展示：总价 = 票面价 + 税价。多乘客或多航段时，分别汇总票面价和税价后再计算总价。如果工具只返回总额但没有票面价或税价拆分，固定模板中的缺失拆分字段填\"未返回\"，不要编造。\n\n### 订单列表展示\n\n`flight_order_list` 返回多条结果时：\n\n- 按出发日期排序展示\n- 每条显示：订单号、路线、出发日期、支付状态、出票状态；不得显示 PNR\n- 支付状态和出票状态必须翻译成中文展示，不直接输出英文枚举。常见映射：`closed`=已关闭，`failed`=失败，`pending`/`processing`=处理中，`paid`/`success`/`succeeded`=已支付，`unpaid`/`not_paid`=未支付，`issued`/`ticketed`=已出票，`changed`=已改签，`refunded`=已退款，`cancelled`/`canceled`=已取消。未识别状态显示：`未识别状态（原值）`。\n- 路线展示为 `中文名 三字码 → 中文名 三字码`。中文名优先级：工具返回的中文城市/机场名 > skill 内置常见映射 > agent 明确认识的 IATA 城市码/机场码常识；不确定、冷门、冲突或无法判断城市/机场语义时，只展示原三字码，不编造中文名。\n- 不为了翻译三字码解析 raw JSON、临时调用额外工具或联网查询；不确定时不要解释过多，直接保留原码。\n- 订单列表路线常见城市码：`BJS`=北京，`SHA`=上海，`CAN`=广州，`HGH`=杭州，`DLU`=大理，`BKK`=曼谷，`SEL`=首尔，`TYO`=东京，`LON`=伦敦。\n- 机场码常见映射：`PEK`=北京首都，`PKX`=北京大兴，`PVG`=上海浦东，`SHA`=上海虹桥，`DMK`=曼谷廊曼，`ICN`=首尔仁川，`GMP`=首尔金浦。`SHA` 在城市级路线如 `BJS-SHA` 中展示为 `上海 SHA`；工具明确为机场时展示 `上海虹桥 SHA`。\n- 说明用户可以指定某个订单号继续操作\n\n### 错误处理\n\n订单找不到时，询问：订单号、外部订单号、票号、路线或出发日期，从而帮助定位；不要向普通用户提及 PNR。\n\nFile v1.0.8:references/flight-pay-order.md\n\n# flight-pay-order ref\n\n## Purpose\n\nUse `flight_pay_order` only for an already-created order when the user explicitly wants to pay. Never pay automatically.\n\n## Before Payment\n\n- Restate order number, amount, payment method, and known order status.\n- Amount follows `output-rules`: total = fare + tax.\n- If payment method is missing, ask the user to choose. Do not default.\n- User-facing methods: domestic can show 微信、支付宝、信用卡、借记卡; international can also show Airwallex.\n- Do not offer balance payment. If the user asks for it, show the supported user payment methods and ask them to choose again.\n\nInternal channel mapping:\n\n| User method | Tool channel |\n|---|---|\n| Airwallex | `airwallex` |\n| 支付宝 | `yeepay-alipay` |\n| 微信 | `yeepay-wechat` |\n| 信用卡 | `yeepay-credit-card` |\n| 借记卡 | `yeepay-debit-card` |\n\nAsk:\n\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\nCall `flight_pay_order` only after explicit confirmation.\n\n## Payment Link\n\nAfter `flight_pay_order` returns a third-party payment link, use this exact format. Do not expose internal channel names, raw JSON, `returnUrl`, or technical parameters.\n\n```markdown\n{支付方式}支付已发起，请打开链接完成付款：\n\n[前往{支付方式}支付]({支付链接})\n\n订单金额：¥{订单金额}\n交易手续费：¥{交易手续费}\n需支付合计：¥{订单金额 + 交易手续费}\n\n付款完成后告诉我一声，我帮你核查订单和出票状态。\n```\n\n- Payment method names: 微信、支付宝、信用卡、借记卡、Airwallex.\n- If payment link is missing, say: `支付链接暂未返回，我会先核查订单支付状态。`\n- Transaction fee must come from the tool. If fee is missing, show `未返回`; then payable total is also `未返回`.\n- Use the configured default third-party `returnUrl`; do not explain it to normal users.\n\n## Risk Checks\n\nBefore retrying payment, call `flight_order_detail` if amount mismatches, fare + tax conflicts with returned total, order status is unclear, prior payment may be processing, order may be expired, or deadline is unclear.\n\n## After User Says Paid\n\nGoal: check payment status and ticketing status without changing the order.\n\n1. Call read-only `flight_order_detail` immediately.\n2. If neither payment nor ticketing has a clear result, poll every 10 seconds（每 10 秒）.\n3. Stop after 12 total checks（12 次）, including the first immediate check.\n4. Use only `flight_order_detail`; never trigger pay, cancel, refund, or change during polling.\n5. Do not message the user on every poll. Reply only on a clear result, query failure, or after all 12 checks.\n6. Prefer background/timer/automation polling when available. If only synchronous waiting works, tell the user you are checking every 10 seconds. If the environment cannot wait or schedule, say so and ask the user to request another check later.\n\nClear results:\n\n- Payment terminal states: paid/success, failed, canceled, expired, or any explicit payment result returned by the tool.\n- Ticketing terminal states: ticketed/success, failed, abnormal, or any explicit ticketing result returned by the tool.\n- Missing or ambiguous fields are not results; keep polling until the limit.\n\nFinal notification must include order number, latest payment status, latest ticketing status, and next step. Use the `output-rules` order template when showing order details.\n\n## Errors\n\nOn payment failure, briefly explain the returned reason, check current order status with `flight_order_detail`, then decide whether retry is appropriate. Do not blindly retry.\n\nFile v1.0.8:references/flight-pricing.md\n\n# flight-pricing ref\n\n## flight_pricing\n\n按指定航班号和舱位查询实时票价，适用于用户已明确知道航班号的场景。\n\n### 何时使用\n\n仅当用户已同时提供以下全部信息时才使用：\n\n- 航班号\n- 出发机场\n- 到达机场\n- 出发日期\n- 舱位等级\n\n以上任意一项缺失，改用 `flight_search` 进行搜索。\n\n### 参数说明\n\n| 参数 | 是否必填 | 说明 |\n|------|---------|------|\n| `flightNo` | 必填 | 航班号，如 `CA1234` |\n| `origin` | 必填 | 出发机场 IATA 码 |\n| `destination` | 必填 | 到达机场 IATA 码 |\n| `departureDate` | 必填 | 出发日期 `YYYY-MM-DD` |\n| `cabinClass` | 必填 | `economy` / `business` / `first` |\n| `adult` | 必填 | 成人人数 |\n| `child` | 可选 | 儿童人数 |\n| `infant` | 可选 | 婴儿人数 |\n\n### 结果展示规则\n\n展示工具返回的可用票价选项，每个选项包含（数据返回时）：\n\n- 舱位等级和子舱位代码\n- 价格\n- 行李额\n- 退改规则摘要\n\n退改规则若以 `*`、`>n`、`n`、` 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\n用户明确确认后，这一次确认只适用于当前 `flight_create_order` 调用。内部可一次性设置创建订单所需的确认字段，包括生产写入确认字段；不要向普通用户展示\"生产环境\"、\"生产写入\"或要求用户为同一次创建订单进行二次确认。\n\n### 支付订单（flight_pay_order）\n\n确认前重述：\n\n- 订单号\n- 支付金额（总价 = 票面价 + 税价）\n- 支付方式\n- 当前订单状态（已知时）\n\n如果支付方式未知，先请用户选择或确认支付方式；不要自动填入任何默认支付方式。\n\n提示支付方式时，不向普通用户展示余额支付：\n\n- 国内机票：微信、支付宝、信用卡、借记卡\n- 国际机票：Airwallex、微信、支付宝、信用卡、借记卡\n\n如果用户要求余额支付，不直接发起支付；提示当前可选的用户支付方式并请用户重新选择。\n\n询问：\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\n### 创建发票申请（flight_create_order_invoice_application）\n\n创建前必须先调用 `flight_get_order_invoice_application` 确认订单可申请发票。\n\n确认前重述：\n\n- 订单号\n- 开票公司名称\n- 纳税人识别号\n- 接收邮箱\n- 联系手机号\n- 公司地址、公司电话、开户银行、银行账号、备注（用户提供时）\n\n询问：\n> 确认提交该订单的发票申请吗？\n\n### 取消订单（flight_cancel_order）\n\n确认前重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 取消操作及后果\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n### 提交退票（flight_refund_request / flight_refund_confirm）\n\n确认前重述：\n\n- 需要退票的乘客和航段\n- 退票原因\n- 估算退款金额和手续费（数据返回时）\n- 未返回的费用或政策信息说明\n\n询问：\n> 确认提交退票申请吗？\n\n### 提交改签（flight_change_request）\n\n确认前重述：\n\n- 原航班信息\n- 新航班信息\n- 需要改签的乘客\n- 改签手续费或注意事项（数据返回时）\n- 改签原因\n\n询问：\n> 确认提交改签申请吗？\n\n### 通用原则\n\n- **不得**将\"帮我订\"、\"退了吧\"、\"改一下\"等笼统意图视为足够确认\n- 每次写入操作都是独立的确认，不能将之前的确认视为连续适用\n- 创建订单的一次确认只覆盖该次创建订单；后续支付、取消、退票、改签仍必须重新确认\n- 确认话术使用自然消费者语言，不暴露内部确认字段、环境名称或 MCP 参数\n- 金额或状态出现异常时，先通过读取工具核查，再询问确认\n- 订单金额统一按 `output-rules` 的金额口径处理：总价 = 票面价 + 税价；没有票面价或税价拆分时，不编造拆分\n\nFile v1.0.6:references/flight-cancel.md\n\n# flight-cancel ref\n\n## flight_cancel_order\n\n取消未支付或可取消的机票订单，**必须经用户明确确认**。\n\n### 何时使用\n\n用户主动要求取消订单，且订单处于未支付或可取消状态时。\n\n已支付、已出票、已退款、已改签或不可取消的订单，说明取消可能不适用，视情况建议退票或改签流程。\n\n### 取消前确认\n\n调用 `flight_cancel_order` 前，重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 将要执行的操作\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n**只有用户明确确认后**才调用 `flight_cancel_order`。\n\n### 错误处理\n\n取消失败时，简短说明原因，展示最安全的下一步建议（如改用退票流程）。\n\nFile v1.0.6:references/flight-change.md\n\n# flight-change ref\n\n## flight_change_search / flight_change_request\n\n搜索可改签的航班选项，经用户选定并明确确认后提交改签申请。\n\n### 改签流程\n\n1. 需要时先通过 `flight_order_detail` 查询订单\n2. 确认需要改签的乘客和航段\n3. 询问新出发日期和舱位偏好（缺失时）\n4. 调用 `flight_change_search` 查询可用改签选项\n5. 展示多个改签选项（有时）\n6. 用户选定一个选项\n7. 重述：原航班号、新航班号、乘客、手续费或注意事项（数据返回时）、改签原因\n8. 询问用户明确确认\n9. 确认后调用 `flight_change_request`\n\n**不得**在展示可用改签选项前直接提交改签申请，除非用户在当前对话中已从工具结果中明确指定了有效选项。\n\n### 改签选项展示\n\n展示格式参考搜索结果，每个选项包含：\n\n- 新航班号（只显示完整航班号，不展示航空公司名称）\n- 新出发/到达时间\n- 改签手续费（数据返回时）\n- 可用舱位\n\n改签规则或手续费若以 `*`、`>n`、` 这趟是国内航班，后续需要乘机人证件信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 中文姓名我会按证件姓名识别姓、名；如果复姓或拆分不确定，我再单独确认。\n\n- 乘机人姓名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 证件类型\n- 证件号码\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n**International fixed prompt - must output verbatim**:\n\n> 这趟是国际航班，后续需要乘机人护照信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 护照英文姓和英文名需要与护照完全一致。\n\n- 护照英文姓\n- 护照英文名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 护照号码\n- 护照有效期（请填写具体日期）\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n## Passenger Rules\n\n- Required per passenger: phone, document type, document number.\n- Email is optional notification info. If absent, omit passenger `email`; if supplier requires/rejects missing email, ask only for email.\n- ID card, Mainland Travel Permit, and Taiwan Travel Permit names use Chinese as on document; passports use passport English name.\n- For ID-card passengers, split one Chinese full name internally. Ask only if compound surname, ethnic/minority name, English name, very long name, or rare characters make splitting unclear.\n- If document type is unclear or cannot map to supported `travelDocument`, ask only for document type clarification.\n- If contact name/phone is absent, default to first passenger's name/phone, mention this before creation, and do not collect contact email.\n\n## Confirmation Before Creation\n\nBefore `flight_create_order`, summarize flight/route, departure/arrival time, passengers, contact info/defaults, final price, and returned notices. Amount line must be:\n\n> 金额：¥{总价}（票面价 ¥{票面价} + 税价 ¥{税价}）\n\nIf verified solution returned any segment `availability <= 3`, include remaining ticket count, e.g. `当前余票不多，仅剩 {availability} 张，请尽快完成预订和支付；未支付前票价和余票可能变化。` For multi-segment journeys, use lowest returned availability.\n\nAsk:\n> 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\nOnly after explicit confirmation, call `flight_create_order` with verified `orderKey` and required internal confirmation fields; do not mention production/technical flags.\n\n## After Creation\n\n- When useful, call `flight_order_detail` and show `output-rules` fixed order template.\n- Deadlines must come from explicit tool fields; if missing, use `output-rules` deadline wording.\n- Amount: total = fare + tax; sum fare/tax across passengers/segments. If only total is returned, mark fare/tax as `未返回`.\n- If unpaid, prompt payment options: domestic 微信、支付宝、信用卡、借记卡; international/cross-border also Airwallex.\n- If low inventory was known, include remaining ticket count and remind prompt payment, otherwise ticket may sell out.\n\n## Errors\n\n- Ask only for missing/corrected fields; do not require resubmitting all passenger details.\n- Name errors (`FirstName`, `LastName`, ID-card full name) mean document-name format issue; ask only for name correction and do not blame price/inventory.\n- If an abnormal order is unpaid and unticketed, re-verify price before creating a corrected new order.\n\nFile v1.0.6:references/flight-invoice.md\n\n# flight-invoice ref\n\n## flight_get_order_invoice_application / flight_create_order_invoice_application\n\nUse for flight order invoice requests: checking whether an order can apply for an invoice, checking invoice application status, and creating an invoice application.\n\n## Workflow\n\n1. Collect or confirm the TravelKit `orderId`.\n2. Always call read-only `flight_get_order_invoice_application` first.\n3. If an application exists, show its status and do not create another application.\n4. If `canApply` is false, show `canApplyReason` when returned and stop.\n5. If `canApply` is true and the user wants to apply, collect invoice information.\n6. Before `flight_create_order_invoice_application`, summarize the application details and ask for explicit confirmation.\n\n## Required Invoice Fields\n\nCollect these fields before creation:\n\n- 开票公司名称 (`companyName`)\n- 纳税人识别号 (`taxNo`)\n- 接收邮箱 (`email`)\n- 联系手机号 (`phone`)\n\nOptional fields:\n\n- 公司地址 (`companyAddress`)\n- 公司电话 (`companyPhone`)\n- 开户银行 (`bankName`)\n- 银行账号 (`bankAccount`)\n- 备注 (`remark`)\n\nUse `invoiceType: normal` by default. Do not ask normal users to choose invoice type unless the tool or product later returns more supported values.\n\n## Status Display\n\nFor query results, show in natural Chinese:\n\n- 是否可申请\n- 不可申请原因（数据返回时）\n- 已有申请 ID、状态、公司名称、创建时间、发送时间（数据返回时）\n\nFor creation success, show:\n\n- 订单号\n- 发票申请 ID\n- 申请状态：`pending` = 待处理 / 待发送，`sent` = 已发送\n- 开票公司名称\n- 创建时间\n- 下一步：待财务处理或已发送，以工具返回状态为准\n\nDo not say the invoice has been issued or emailed unless the tool explicitly returns `sent`.\n\n## Errors\n\n- Email format errors: ask only for the email again; do not re-collect company name, tax number, phone, or optional fields.\n- Duplicate application: explain that the order has already submitted an invoice application and show returned status if available.\n- Order not found, not original order, unsupported status, flight not departed, or other cannot-apply reasons: show the tool-returned reason and do not create.\n- Missing optional fields never block creation unless the tool rejects them.\n\nFile v1.0.6:references/flight-itinerary.md\n\n# flight-itinerary ref\n\n## flight_download_itinerary\n\n下载已出票订单的行程单（电子行程单 / PDF / ZIP）。\n\n### 何时使用\n\n用户主动请求行程单或类行程单票据文件，且订单状态支持下载时。\n\n**不主动**在订单查询或其他操作结束后推送行程单下载。\n\n### 使用方式\n\n调用 `flight_download_itinerary` 时，传入订单号。\n\n请求参数中的 `type` 会影响常见返回格式：\n\n- `type=more`：生成合并文件，通常返回单个 PDF\n- `type=once`：可能生成多个文件，多个文件时可能返回 ZIP 压缩包\n\n下载完成后，说明返回文件的类型（工具返回该信息时）：\n\n- 是 PDF 文件\n- 是 ZIP 压缩包\n- 还是其他格式\n\n最终格式以工具返回的文件类型、响应 `Content-Type` 或文件名后缀为准。工具未返回文件类型信息时，如实说明未返回，不要猜测为 PDF。\n\n### 错误处理\n\n下载失败或订单状态不支持下载时，简短说明原因，建议用户核对订单状态或稍后重试。\n\nFile v1.0.6:references/flight-order-lookup.md\n\n# flight-order-lookup ref\n\n## flight_order_detail / flight_order_detail_by_external_id / flight_order_list\n\n查询用户的机票订单状态和订单列表。\n\n### 工具选择\n\n| 场景 | 使用工具 |\n|------|---------|\n| 用户提供 TravelKit 订单号 | `flight_order_detail` |\n| 用户提供买方侧外部订单号 | `flight_order_detail_by_external_id` |\n| 用户查找历史订单、按路线/日期/状态/票号/订座记录等线索筛选 | `flight_order_list` |\n\n**始终通过工具获取最新状态**，不依赖记忆中的出票、付款、退款或改签状态。\n\nPNR / 航司 PNR 仅可作为内部查单筛选条件；查询结果、订单详情、订单列表、支付后核查和异常说明都不得向普通用户展示 PNR，也不得展示 `PNR: 未返回`、`票号 / PNR` 或 `票号/PNR`。如果工具或错误原因返回 PNR 相关文字，必须改写为不含该词的自然中文。\n\n### 订单详情展示\n\n订单详情必须使用 `output-rules` 中的订单信息固定模板；字段未返回时填\"未返回\"，不要推断。航班只显示完整航班号，不展示航空公司名称。\n\n金额必须按共享口径展示：总价 = 票面价 + 税价。多乘客或多航段时，分别汇总票面价和税价后再计算总价。如果工具只返回总额但没有票面价或税价拆分，固定模板中的缺失拆分字段填\"未返回\"，不要编造。\n\n### 订单列表展示\n\n`flight_order_list` 返回多条结果时：\n\n- 按出发日期排序展示\n- 每条显示：订单号、路线、出发日期、支付状态、出票状态；不得显示 PNR\n- 支付状态和出票状态必须翻译成中文展示，不直接输出英文枚举。常见映射：`closed`=已关闭，`failed`=失败，`pending`/`processing`=处理中，`paid`/`success`/`succeeded`=已支付，`unpaid`/`not_paid`=未支付，`issued`/`ticketed`=已出票，`changed`=已改签，`refunded`=已退款，`cancelled`/`canceled`=已取消。未识别状态显示：`未识别状态（原值）`。\n- 路线展示为 `中文名 三字码 → 中文名 三字码`。中文名优先级：工具返回的中文城市/机场名 > skill 内置常见映射 > agent 明确认识的 IATA 城市码/机场码常识；不确定、冷门、冲突或无法判断城市/机场语义时，只展示原三字码，不编造中文名。\n- 不为了翻译三字码解析 raw JSON、临时调用额外工具或联网查询；不确定时不要解释过多，直接保留原码。\n- 订单列表路线常见城市码：`BJS`=北京，`SHA`=上海，`CAN`=广州，`HGH`=杭州，`DLU`=大理，`BKK`=曼谷，`SEL`=首尔，`TYO`=东京，`LON`=伦敦。\n- 机场码常见映射：`PEK`=北京首都，`PKX`=北京大兴，`PVG`=上海浦东，`SHA`=上海虹桥，`DMK`=曼谷廊曼，`ICN`=首尔仁川，`GMP`=首尔金浦。`SHA` 在城市级路线如 `BJS-SHA` 中展示为 `上海 SHA`；工具明确为机场时展示 `上海虹桥 SHA`。\n- 说明用户可以指定某个订单号继续操作\n\n### 错误处理\n\n订单找不到时，询问：订单号、外部订单号、票号、路线或出发日期，从而帮助定位；不要向普通用户提及 PNR。\n\nFile v1.0.6:references/flight-pay-order.md\n\n# flight-pay-order ref\n\n## Purpose\n\nUse `flight_pay_order` only for an already-created order when the user explicitly wants to pay. Never pay automatically.\n\n## Before Payment\n\n- Restate order number, amount, payment method, and known order status.\n- Amount follows `output-rules`: total = fare + tax.\n- If payment method is missing, ask the user to choose. Do not default.\n- User-facing methods: domestic can show 微信、支付宝、信用卡、借记卡; international can also show Airwallex.\n- Do not offer balance payment. If the user asks for it, show the supported user payment methods and ask them to choose again.\n\nInternal channel mapping:\n\n| User method | Tool channel |\n|---|---|\n| Airwallex | `airwallex` |\n| 支付宝 | `yeepay-alipay` |\n| 微信 | `yeepay-wechat` |\n| 信用卡 | `yeepay-credit-card` |\n| 借记卡 | `yeepay-debit-card` |\n\nAsk:\n\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\nCall `flight_pay_order` only after explicit confirmation.\n\n## Payment Link\n\nAfter `flight_pay_order` returns a third-party payment link, use this exact format. Do not expose internal channel names, raw JSON, `returnUrl`, or technical parameters.\n\n```markdown\n{支付方式}支付已发起，请打开链接完成付款：\n\n[前往{支付方式}支付]({支付链接})\n\n订单金额：¥{订单金额}\n交易手续费：¥{交易手续费}\n需支付合计：¥{订单金额 + 交易手续费}\n\n付款完成后告诉我一声，我帮你核查订单和出票状态。\n```\n\n- Payment method names: 微信、支付宝、信用卡、借记卡、Airwallex.\n- If payment link is missing, say: `支付链接暂未返回，我会先核查订单支付状态。`\n- Transaction fee must come from the tool. If fee is missing, show `未返回`; then payable total is also `未返回`.\n- Use the configured default third-party `returnUrl`; do not explain it to normal users.\n\n## Risk Checks\n\nBefore retrying payment, call `flight_order_detail` if amount mismatches, fare + tax conflicts with returned total, order status is unclear, prior payment may be processing, order may be expired, or deadline is unclear.\n\n## After User Says Paid\n\nGoal: check payment status and ticketing status without changing the order.\n\n1. Call read-only `flight_order_detail` immediately.\n2. If neither payment nor ticketing has a clear result, poll every 10 seconds（每 10 秒）.\n3. Stop after 12 total checks（12 次）, including the first immediate check.\n4. Use only `flight_order_detail`; never trigger pay, cancel, refund, or change during polling.\n5. Do not message the user on every poll. Reply only on a clear result, query failure, or after all 12 checks.\n6. Prefer background/timer/automation polling when available. If only synchronous waiting works, tell the user you are checking every 10 seconds. If the environment cannot wait or schedule, say so and ask the user to request another check later.\n\nClear results:\n\n- Payment terminal states: paid/success, failed, canceled, expired, or any explicit payment result returned by the tool.\n- Ticketing terminal states: ticketed/success, failed, abnormal, or any explicit ticketing result returned by the tool.\n- Missing or ambiguous fields are not results; keep polling until the limit.\n\nFinal notification must include order number, latest payment status, latest ticketing status, and next step. Use the `output-rules` order template when showing order details.\n\n## Errors\n\nOn payment failure, briefly explain the returned reason, check current order status with `flight_order_detail`, then decide whether retry is appropriate. Do not blindly retry.\n\nFile v1.0.6:references/flight-pricing.md\n\n# flight-pricing ref\n\n## flight_pricing\n\n按指定航班号和舱位查询实时票价，适用于用户已明确知道航班号的场景。\n\n### 何时使用\n\n仅当用户已同时提供以下全部信息时才使用：\n\n- 航班号\n- 出发机场\n- 到达机场\n- 出发日期\n- 舱位等级\n\n以上任意一项缺失，改用 `flight_search` 进行搜索。\n\n### 参数说明\n\n| 参数 | 是否必填 | 说明 |\n|------|---------|------|\n| `flightNo` | 必填 | 航班号，如 `CA1234` |\n| `origin` | 必填 | 出发机场 IATA 码 |\n| `destination` | 必填 | 到达机场 IATA 码 |\n| `departureDate` | 必填 | 出发日期 `YYYY-MM-DD` |\n| `cabinClass` | 必填 | `economy` / `business` / `first` |\n| `adult` | 必填 | 成人人数 |\n| `child` | 可选 | 儿童人数 |\n| `infant` | 可选 | 婴儿人数 |\n\n### 结果展示规则\n\n展示工具返回的可用票价选项，每个选项包含（数据返回时）：\n\n- 舱位等级和子舱位代码\n- 价格\n- 行李额\n- 退改规则摘要\n\n退改规则若以 `*`、`>n`、`n`、` 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\n用户明确确认后，这一次确认只适用于当前 `flight_create_order` 调用。内部可一次性设置创建订单所需的确认字段，包括生产写入确认字段；不要向普通用户展示\"生产环境\"、\"生产写入\"或要求用户为同一次创建订单进行二次确认。\n\n### 支付订单（flight_pay_order）\n\n确认前重述：\n\n- 订单号\n- 支付金额（总价 = 票面价 + 税价）\n- 支付方式\n- 当前订单状态（已知时）\n\n如果支付方式未知，先请用户选择或确认支付方式；不要自动填入任何默认支付方式。\n\n提示支付方式时，不向普通用户展示余额支付：\n\n- 国内机票：微信、支付宝、信用卡、借记卡\n- 国际机票：Airwallex、微信、支付宝、信用卡、借记卡\n\n如果用户要求余额支付，不直接发起支付；提示当前可选的用户支付方式并请用户重新选择。\n\n询问：\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\n### 创建发票申请（flight_create_order_invoice_application）\n\n创建前必须先调用 `flight_get_order_invoice_application` 确认订单可申请发票。\n\n确认前重述：\n\n- 订单号\n- 开票公司名称\n- 纳税人识别号\n- 接收邮箱\n- 联系手机号\n- 公司地址、公司电话、开户银行、银行账号、备注（用户提供时）\n\n询问：\n> 确认提交该订单的发票申请吗？\n\n### 取消订单（flight_cancel_order）\n\n确认前重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 取消操作及后果\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n### 提交退票（flight_refund_request / flight_refund_confirm）\n\n确认前重述：\n\n- 需要退票的乘客和航段\n- 退票原因\n- 估算退款金额和手续费（数据返回时）\n- 未返回的费用或政策信息说明\n\n询问：\n> 确认提交退票申请吗？\n\n### 提交改签（flight_change_request）\n\n确认前重述：\n\n- 原航班信息\n- 新航班信息\n- 需要改签的乘客\n- 改签手续费或注意事项（数据返回时）\n- 改签原因\n\n询问：\n> 确认提交改签申请吗？\n\n### 通用原则\n\n- **不得**将\"帮我订\"、\"退了吧\"、\"改一下\"等笼统意图视为足够确认\n- 每次写入操作都是独立的确认，不能将之前的确认视为连续适用\n- 创建订单的一次确认只覆盖该次创建订单；后续支付、取消、退票、改签仍必须重新确认\n- 确认话术使用自然消费者语言，不暴露内部确认字段、环境名称或 MCP 参数\n- 金额或状态出现异常时，先通过读取工具核查，再询问确认\n- 订单金额统一按 `output-rules` 的金额口径处理：总价 = 票面价 + 税价；没有票面价或税价拆分时，不编造拆分\n\nFile v1.0.5:references/flight-cancel.md\n\n# flight-cancel ref\n\n## flight_cancel_order\n\n取消未支付或可取消的机票订单，**必须经用户明确确认**。\n\n### 何时使用\n\n用户主动要求取消订单，且订单处于未支付或可取消状态时。\n\n已支付、已出票、已退款、已改签或不可取消的订单，说明取消可能不适用，视情况建议退票或改签流程。\n\n### 取消前确认\n\n调用 `flight_cancel_order` 前，重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 将要执行的操作\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n**只有用户明确确认后**才调用 `flight_cancel_order`。\n\n### 错误处理\n\n取消失败时，简短说明原因，展示最安全的下一步建议（如改用退票流程）。\n\nFile v1.0.5:references/flight-change.md\n\n# flight-change ref\n\n## flight_change_search / flight_change_request\n\n搜索可改签的航班选项，经用户选定并明确确认后提交改签申请。\n\n### 改签流程\n\n1. 需要时先通过 `flight_order_detail` 查询订单\n2. 确认需要改签的乘客和航段\n3. 询问新出发日期和舱位偏好（缺失时）\n4. 调用 `flight_change_search` 查询可用改签选项\n5. 展示多个改签选项（有时）\n6. 用户选定一个选项\n7. 重述：原航班号、新航班号、乘客、手续费或注意事项（数据返回时）、改签原因\n8. 询问用户明确确认\n9. 确认后调用 `flight_change_request`\n\n**不得**在展示可用改签选项前直接提交改签申请，除非用户在当前对话中已从工具结果中明确指定了有效选项。\n\n### 改签选项展示\n\n展示格式参考搜索结果，每个选项包含：\n\n- 新航班号（只显示完整航班号，不展示航空公司名称）\n- 新出发/到达时间\n- 改签手续费（数据返回时）\n- 可用舱位\n\n改签规则或手续费若以 `*`、`>n`、` 这趟是国内航班，后续需要乘机人证件信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 中文姓名我会按证件姓名识别姓、名；如果复姓或拆分不确定，我再单独确认。\n\n- 乘机人姓名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 证件类型\n- 证件号码\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n**International fixed prompt - must output verbatim**:\n\n> 这趟是国际航班，后续需要乘机人护照信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 护照英文姓和英文名需要与护照完全一致。\n\n- 护照英文姓\n- 护照英文名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 护照号码\n- 护照有效期（请填写具体日期）\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n## Passenger Rules\n\n- Required per passenger: phone, document type, document number.\n- Email is optional notification info. If absent, omit passenger `email`; if supplier requires/rejects missing email, ask only for email.\n- ID card, Mainland Travel Permit, and Taiwan Travel Permit names use Chinese as on document; passports use passport English name.\n- For ID-card passengers, split one Chinese full name internally. Ask only if compound surname, ethnic/minority name, English name, very long name, or rare characters make splitting unclear.\n- If document type is unclear or cannot map to supported `travelDocument`, ask only for document type clarification.\n- If contact name/phone is absent, default to first passenger's name/phone, mention this before creation, and do not collect contact email.\n\n## Confirmation Before Creation\n\nBefore `flight_create_order`, summarize flight/route, departure/arrival time, passengers, contact info/defaults, final price, and returned notices. Amount line must be:\n\n> 金额：¥{总价}（票面价 ¥{票面价} + 税价 ¥{税价}）\n\nIf verified solution returned any segment `availability <= 3`, include remaining ticket count, e.g. `当前余票不多，仅剩 {availability} 张，请尽快完成预订和支付；未支付前票价和余票可能变化。` For multi-segment journeys, use lowest returned availability.\n\nAsk:\n> 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\nOnly after explicit confirmation, call `flight_create_order` with verified `orderKey` and required internal confirmation fields; do not mention production/technical flags.\n\n## After Creation\n\n- When useful, call `flight_order_detail` and show `output-rules` fixed order template.\n- Deadlines must come from explicit tool fields; if missing, use `output-rules` deadline wording.\n- Amount: total = fare + tax; sum fare/tax across passengers/segments. If only total is returned, mark fare/tax as `未返回`.\n- If unpaid, prompt payment options: domestic 微信、支付宝、信用卡、借记卡; international/cross-border also Airwallex.\n- If low inventory was known, include remaining ticket count and remind prompt payment, otherwise ticket may sell out.\n\n## Errors\n\n- Ask only for missing/corrected fields; do not require resubmitting all passenger details.\n- Name errors (`FirstName`, `LastName`, ID-card full name) mean document-name format issue; ask only for name correction and do not blame price/inventory.\n- If an abnormal order is unpaid and unticketed, re-verify price before creating a corrected new order.\n\nFile v1.0.5:references/flight-invoice.md\n\n# flight-invoice ref\n\n## flight_get_order_invoice_application / flight_create_order_invoice_application\n\nUse for flight order invoice requests: checking whether an order can apply for an invoice, checking invoice application status, and creating an invoice application.\n\n## Workflow\n\n1. Collect or confirm the TravelKit `orderId`.\n2. Always call read-only `flight_get_order_invoice_application` first.\n3. If an application exists, show its status and do not create another application.\n4. If `canApply` is false, show `canApplyReason` when returned and stop.\n5. If `canApply` is true and the user wants to apply, collect invoice information.\n6. Before `flight_create_order_invoice_application`, summarize the application details and ask for explicit confirmation.\n\n## Required Invoice Fields\n\nCollect these fields before creation:\n\n- 开票公司名称 (`companyName`)\n- 纳税人识别号 (`taxNo`)\n- 接收邮箱 (`email`)\n- 联系手机号 (`phone`)\n\nOptional fields:\n\n- 公司地址 (`companyAddress`)\n- 公司电话 (`companyPhone`)\n- 开户银行 (`bankName`)\n- 银行账号 (`bankAccount`)\n- 备注 (`remark`)\n\nUse `invoiceType: normal` by default. Do not ask normal users to choose invoice type unless the tool or product later returns more supported values.\n\n## Status Display\n\nFor query results, show in natural Chinese:\n\n- 是否可申请\n- 不可申请原因（数据返回时）\n- 已有申请 ID、状态、公司名称、创建时间、发送时间（数据返回时）\n\nFor creation success, show:\n\n- 订单号\n- 发票申请 ID\n- 申请状态：`pending` = 待处理 / 待发送，`sent` = 已发送\n- 开票公司名称\n- 创建时间\n- 下一步：待财务处理或已发送，以工具返回状态为准\n\nDo not say the invoice has been issued or emailed unless the tool explicitly returns `sent`.\n\n## Errors\n\n- Email format errors: ask only for the email again; do not re-collect company name, tax number, phone, or optional fields.\n- Duplicate application: explain that the order has already submitted an invoice application and show returned status if available.\n- Order not found, not original order, unsupported status, flight not departed, or other cannot-apply reasons: show the tool-returned reason and do not create.\n- Missing optional fields never block creation unless the tool rejects them.\n\nFile v1.0.5:references/flight-itinerary.md\n\n# flight-itinerary ref\n\n## flight_download_itinerary\n\n下载已出票订单的行程单（电子行程单 / PDF / ZIP）。\n\n### 何时使用\n\n用户主动请求行程单或类行程单票据文件，且订单状态支持下载时。\n\n**不主动**在订单查询或其他操作结束后推送行程单下载。\n\n### 使用方式\n\n调用 `flight_download_itinerary` 时，传入订单号。\n\n请求参数中的 `type` 会影响常见返回格式：\n\n- `type=more`：生成合并文件，通常返回单个 PDF\n- `type=once`：可能生成多个文件，多个文件时可能返回 ZIP 压缩包\n\n下载完成后，说明返回文件的类型（工具返回该信息时）：\n\n- 是 PDF 文件\n- 是 ZIP 压缩包\n- 还是其他格式\n\n最终格式以工具返回的文件类型、响应 `Content-Type` 或文件名后缀为准。工具未返回文件类型信息时，如实说明未返回，不要猜测为 PDF。\n\n### 错误处理\n\n下载失败或订单状态不支持下载时，简短说明原因，建议用户核对订单状态或稍后重试。\n\nFile v1.0.5:references/flight-order-lookup.md\n\n# flight-order-lookup ref\n\n## flight_order_detail / flight_order_detail_by_external_id / flight_order_list\n\n查询用户的机票订单状态和订单列表。\n\n### 工具选择\n\n| 场景 | 使用工具 |\n|------|---------|\n| 用户提供 TravelKit 订单号 | `flight_order_detail` |\n| 用户提供买方侧外部订单号 | `flight_order_detail_by_external_id` |\n| 用户查找历史订单、按路线/日期/状态/票号/订座记录等线索筛选 | `flight_order_list` |\n\n**始终通过工具获取最新状态**，不依赖记忆中的出票、付款、退款或改签状态。\n\nPNR / 航司 PNR 仅可作为内部查单筛选条件；查询结果、订单详情、订单列表、支付后核查和异常说明都不得向普通用户展示 PNR，也不得展示 `PNR: 未返回`、`票号 / PNR` 或 `票号/PNR`。如果工具或错误原因返回 PNR 相关文字，必须改写为不含该词的自然中文。\n\n### 订单详情展示\n\n订单详情必须使用 `output-rules` 中的订单信息固定模板；字段未返回时填\"未返回\"，不要推断。航班只显示完整航班号，不展示航空公司名称。\n\n金额必须按共享口径展示：总价 = 票面价 + 税价。多乘客或多航段时，分别汇总票面价和税价后再计算总价。如果工具只返回总额但没有票面价或税价拆分，固定模板中的缺失拆分字段填\"未返回\"，不要编造。\n\n### 订单列表展示\n\n`flight_order_list` 返回多条结果时：\n\n- 按出发日期排序展示\n- 每条显示：订单号、路线、出发日期、支付状态、出票状态；不得显示 PNR\n- 支付状态和出票状态必须翻译成中文展示，不直接输出英文枚举。常见映射：`closed`=已关闭，`failed`=失败，`pending`/`processing`=处理中，`paid`/`success`/`succeeded`=已支付，`unpaid`/`not_paid`=未支付，`issued`/`ticketed`=已出票，`changed`=已改签，`refunded`=已退款，`cancelled`/`canceled`=已取消。未识别状态显示：`未识别状态（原值）`。\n- 路线展示为 `中文名 三字码 → 中文名 三字码`。中文名优先级：工具返回的中文城市/机场名 > skill 内置常见映射 > agent 明确认识的 IATA 城市码/机场码常识；不确定、冷门、冲突或无法判断城市/机场语义时，只展示原三字码，不编造中文名。\n- 不为了翻译三字码解析 raw JSON、临时调用额外工具或联网查询；不确定时不要解释过多，直接保留原码。\n- 订单列表路线常见城市码：`BJS`=北京，`SHA`=上海，`CAN`=广州，`HGH`=杭州，`DLU`=大理，`BKK`=曼谷，`SEL`=首尔，`TYO`=东京，`LON`=伦敦。\n- 机场码常见映射：`PEK`=北京首都，`PKX`=北京大兴，`PVG`=上海浦东，`SHA`=上海虹桥，`DMK`=曼谷廊曼，`ICN`=首尔仁川，`GMP`=首尔金浦。`SHA` 在城市级路线如 `BJS-SHA` 中展示为 `上海 SHA`；工具明确为机场时展示 `上海虹桥 SHA`。\n- 说明用户可以指定某个订单号继续操作\n\n### 错误处理\n\n订单找不到时，询问：订单号、外部订单号、票号、路线或出发日期，从而帮助定位；不要向普通用户提及 PNR。\n\nFile v1.0.5:references/flight-pay-order.md\n\n# flight-pay-order ref\n\n## Purpose\n\nUse `flight_pay_order` only for an already-created order when the user explicitly wants to pay. Never pay automatically.\n\n## Before Payment\n\n- Restate order number, amount, payment method, and known order status.\n- Amount follows `output-rules`: total = fare + tax.\n- If payment method is missing, ask the user to choose. Do not default.\n- User-facing methods: domestic can show 微信、支付宝、信用卡、借记卡; international can also show Airwallex.\n- Do not offer balance payment. If the user asks for it, show the supported user payment methods and ask them to choose again.\n\nInternal channel mapping:\n\n| User method | Tool channel |\n|---|---|\n| Airwallex | `airwallex` |\n| 支付宝 | `yeepay-alipay` |\n| 微信 | `yeepay-wechat` |\n| 信用卡 | `yeepay-credit-card` |\n| 借记卡 | `yeepay-debit-card` |\n\nAsk:\n\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\nCall `flight_pay_order` only after explicit confirmation.\n\n## Payment Link\n\nAfter `flight_pay_order` returns a third-party payment link, use this exact format. Do not expose internal channel names, raw JSON, `returnUrl`, or technical parameters.\n\n```markdown\n{支付方式}支付已发起，请打开链接完成付款：\n\n[前往{支付方式}支付]({支付链接})\n\n订单金额：¥{订单金额}\n交易手续费：¥{交易手续费}\n需支付合计：¥{订单金额 + 交易手续费}\n\n付款完成后告诉我一声，我帮你核查订单和出票状态。\n```\n\n- Payment method names: 微信、支付宝、信用卡、借记卡、Airwallex.\n- If payment link is missing, say: `支付链接暂未返回，我会先核查订单支付状态。`\n- Transaction fee must come from the tool. If fee is missing, show `未返回`; then payable total is also `未返回`.\n- Use the configured default third-party `returnUrl`; do not explain it to normal users.\n\n## Risk Checks\n\nBefore retrying payment, call `flight_order_detail` if amount mismatches, fare + tax conflicts with returned total, order status is unclear, prior payment may be processing, order may be expired, or deadline is unclear.\n\n## After User Says Paid\n\nGoal: check payment status and ticketing status without changing the order.\n\n1. Call read-only `flight_order_detail` immediately.\n2. If neither payment nor ticketing has a clear result, poll every 10 seconds（每 10 秒）.\n3. Stop after 12 total checks（12 次）, including the first immediate check.\n4. Use only `flight_order_detail`; never trigger pay, cancel, refund, or change during polling.\n5. Do not message the user on every poll. Reply only on a clear result, query failure, or after all 12 checks.\n6. Prefer background/timer/automation polling when available. If only synchronous waiting works, tell the user you are checking every 10 seconds. If the environment cannot wait or schedule, say so and ask the user to request another check later.\n\nClear results:\n\n- Payment terminal states: paid/success, failed, canceled, expired, or any explicit payment result returned by the tool.\n- Ticketing terminal states: ticketed/success, failed, abnormal, or any explicit ticketing result returned by the tool.\n- Missing or ambiguous fields are not results; keep polling until the limit.\n\nFinal notification must include order number, latest payment status, latest ticketing status, and next step. Use the `output-rules` order template when showing order details.\n\n## Errors\n\nOn payment failure, briefly explain the returned reason, check current order status with `flight_order_detail`, then decide whether retry is appropriate. Do not blindly retry.\n\nFile v1.0.5:references/flight-pricing.md\n\n# flight-pricing ref\n\n## flight_pricing\n\n按指定航班号和舱位查询实时票价，适用于用户已明确知道航班号的场景。\n\n### 何时使用\n\n仅当用户已同时提供以下全部信息时才使用：\n\n- 航班号\n- 出发机场\n- 到达机场\n- 出发日期\n- 舱位等级\n\n以上任意一项缺失，改用 `flight_search` 进行搜索。\n\n### 参数说明\n\n| 参数 | 是否必填 | 说明 |\n|------|---------|------|\n| `flightNo` | 必填 | 航班号，如 `CA1234` |\n| `origin` | 必填 | 出发机场 IATA 码 |\n| `destination` | 必填 | 到达机场 IATA 码 |\n| `departureDate` | 必填 | 出发日期 `YYYY-MM-DD` |\n| `cabinClass` | 必填 | `economy` / `business` / `first` |\n| `adult` | 必填 | 成人人数 |\n| `child` | 可选 | 儿童人数 |\n| `infant` | 可选 | 婴儿人数 |\n\n### 结果展示规则\n\n展示工具返回的可用票价选项，每个选项包含（数据返回时）：\n\n- 舱位等级和子舱位代码\n- 价格\n- 行李额\n- 退改规则摘要\n\n退改规则若以 `*`、`>n`、`n`、` 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\n用户明确确认后，这一次确认只适用于当前 `flight_create_order` 调用。内部可一次性设置创建订单所需的确认字段，包括生产写入确认字段；不要向普通用户展示\"生产环境\"、\"生产写入\"或要求用户为同一次创建订单进行二次确认。\n\n### 支付订单（flight_pay_order）\n\n确认前重述：\n\n- 订单号\n- 支付金额（总价 = 票面价 + 税价）\n- 支付方式\n- 当前订单状态（已知时）\n\n如果支付方式未知，先请用户选择或确认支付方式；不要自动填入任何默认支付方式。\n\n提示支付方式时，不向普通用户展示余额支付：\n\n- 国内机票：微信、支付宝、信用卡、借记卡\n- 国际机票：Airwallex、微信、支付宝、信用卡、借记卡\n\n如果用户要求余额支付，不直接发起支付；提示当前可选的用户支付方式并请用户重新选择。\n\n询问：\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\n### 创建发票申请（flight_create_order_invoice_application）\n\n创建前必须先调用 `flight_get_order_invoice_application` 确认订单可申请发票。\n\n确认前重述：\n\n- 订单号\n- 开票公司名称\n- 纳税人识别号\n- 接收邮箱\n- 联系手机号\n- 公司地址、公司电话、开户银行、银行账号、备注（用户提供时）\n\n询问：\n> 确认提交该订单的发票申请吗？\n\n### 取消订单（flight_cancel_order）\n\n确认前重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 取消操作及后果\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n### 提交退票（flight_refund_request / flight_refund_confirm）\n\n确认前重述：\n\n- 需要退票的乘客和航段\n- 退票原因\n- 估算退款金额和手续费（数据返回时）\n- 未返回的费用或政策信息说明\n\n询问：\n> 确认提交退票申请吗？\n\n### 提交改签（flight_change_request）\n\n确认前重述：\n\n- 原航班信息\n- 新航班信息\n- 需要改签的乘客\n- 改签手续费或注意事项（数据返回时）\n- 改签原因\n\n询问：\n> 确认提交改签申请吗？\n\n### 通用原则\n\n- **不得**将\"帮我订\"、\"退了吧\"、\"改一下\"等笼统意图视为足够确认\n- 每次写入操作都是独立的确认，不能将之前的确认视为连续适用\n- 创建订单的一次确认只覆盖该次创建订单；后续支付、取消、退票、改签仍必须重新确认\n- 确认话术使用自然消费者语言，不暴露内部确认字段、环境名称或 MCP 参数\n- 金额或状态出现异常时，先通过读取工具核查，再询问确认\n- 订单金额统一按 `output-rules` 的金额口径处理：总价 = 票面价 + 税价；没有票面价或税价拆分时，不编造拆分\n\nFile v1.0.4:references/flight-cancel.md\n\n# flight-cancel ref\n\n## flight_cancel_order\n\n取消未支付或可取消的机票订单，**必须经用户明确确认**。\n\n### 何时使用\n\n用户主动要求取消订单，且订单处于未支付或可取消状态时。\n\n已支付、已出票、已退款、已改签或不可取消的订单，说明取消可能不适用，视情况建议退票或改签流程。\n\n### 取消前确认\n\n调用 `flight_cancel_order` 前，重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 将要执行的操作\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n**只有用户明确确认后**才调用 `flight_cancel_order`。\n\n### 错误处理\n\n取消失败时，简短说明原因，展示最安全的下一步建议（如改用退票流程）。\n\nFile v1.0.4:references/flight-change.md\n\n# flight-change ref\n\n## flight_change_search / flight_change_request\n\n搜索可改签的航班选项，经用户选定并明确确认后提交改签申请。\n\n### 改签流程\n\n1. 需要时先通过 `flight_order_detail` 查询订单\n2. 确认需要改签的乘客和航段\n3. 询问新出发日期和舱位偏好（缺失时）\n4. 调用 `flight_change_search` 查询可用改签选项\n5. 展示多个改签选项（有时）\n6. 用户选定一个选项\n7. 重述：原航班号、新航班号、乘客、手续费或注意事项（数据返回时）、改签原因\n8. 询问用户明确确认\n9. 确认后调用 `flight_change_request`\n\n**不得**在展示可用改签选项前直接提交改签申请，除非用户在当前对话中已从工具结果中明确指定了有效选项。\n\n### 改签选项展示\n\n展示格式参考搜索结果，每个选项包含：\n\n- 新航班号（只显示完整航班号，不展示航空公司名称）\n- 新出发/到达时间\n- 改签手续费（数据返回时）\n- 可用舱位\n\n改签规则或手续费若以 `*`、`>n`、` 这趟是国内航班，后续需要乘机人证件信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 中文姓名我会按证件姓名识别姓、名；如果复姓或拆分不确定，我再单独确认。\n\n- 乘机人姓名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 证件类型\n- 证件号码\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n**International fixed prompt - must output verbatim**:\n\n> 这趟是国际航班，后续需要乘机人护照信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 护照英文姓和英文名需要与护照完全一致。\n\n- 护照英文姓\n- 护照英文名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 护照号码\n- 护照有效期（请填写具体日期）\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n## Passenger Rules\n\n- Required per passenger: phone, document type, document number.\n- Email is optional notification info. If absent, omit passenger `email`; if supplier requires/rejects missing email, ask only for email.\n- ID card, Mainland Travel Permit, and Taiwan Travel Permit names use Chinese as on document; passports use passport English name.\n- For ID-card passengers, split one Chinese full name internally. Ask only if compound surname, ethnic/minority name, English name, very long name, or rare characters make splitting unclear.\n- If document type is unclear or cannot map to supported `travelDocument`, ask only for document type clarification.\n- If contact name/phone is absent, default to first passenger's name/phone, mention this before creation, and do not collect contact email.\n\n## Confirmation Before Creation\n\nBefore `flight_create_order`, summarize flight/route, departure/arrival time, passengers, contact info/defaults, final price, and returned notices. Amount line must be:\n\n> 金额：¥{总价}（票面价 ¥{票面价} + 税价 ¥{税价}）\n\nIf verified solution returned any segment `availability <= 3`, include remaining ticket count, e.g. `当前余票不多，仅剩 {availability} 张，请尽快完成预订和支付；未支付前票价和余票可能变化。` For multi-segment journeys, use lowest returned availability.\n\nAsk:\n> 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\nOnly after explicit confirmation, call `flight_create_order` with verified `orderKey` and required internal confirmation fields; do not mention production/technical flags.\n\n## After Creation\n\n- When useful, call `flight_order_detail` and show `output-rules` fixed order template.\n- Deadlines must come from explicit tool fields; if missing, use `output-rules` deadline wording.\n- Amount: total = fare + tax; sum fare/tax across passengers/segments. If only total is returned, mark fare/tax as `未返回`.\n- If unpaid, prompt payment options: domestic 微信、支付宝、信用卡、借记卡; international/cross-border also Airwallex.\n- If low inventory was known, include remaining ticket count and remind prompt payment, otherwise ticket may sell out.\n\n## Errors\n\n- Ask only for missing/corrected fields; do not require resubmitting all passenger details.\n- Name errors (`FirstName`, `LastName`, ID-card full name) mean document-name format issue; ask only for name correction and do not blame price/inventory.\n- If an abnormal order is unpaid and unticketed, re-verify price before creating a corrected new order.\n\nFile v1.0.4:references/flight-invoice.md\n\n# flight-invoice ref\n\n## flight_get_order_invoice_application / flight_create_order_invoice_application\n\nUse for flight order invoice requests: checking whether an order can apply for an invoice, checking invoice application status, and creating an invoice application.\n\n## Workflow\n\n1. Collect or confirm the TravelKit `orderId`.\n2. Always call read-only `flight_get_order_invoice_application` first.\n3. If an application exists, show its status and do not create another application.\n4. If `canApply` is false, show `canApplyReason` when returned and stop.\n5. If `canApply` is true and the user wants to apply, collect invoice information.\n6. Before `flight_create_order_invoice_application`, summarize the application details and ask for explicit confirmation.\n\n## Required Invoice Fields\n\nCollect these fields before creation:\n\n- 开票公司名称 (`companyName`)\n- 纳税人识别号 (`taxNo`)\n- 接收邮箱 (`email`)\n- 联系手机号 (`phone`)\n\nOptional fields:\n\n- 公司地址 (`companyAddress`)\n- 公司电话 (`companyPhone`)\n- 开户银行 (`bankName`)\n- 银行账号 (`bankAccount`)\n- 备注 (`remark`)\n\nUse `invoiceType: normal` by default. Do not ask normal users to choose invoice type unless the tool or product later returns more supported values.\n\n## Status Display\n\nFor query results, show in natural Chinese:\n\n- 是否可申请\n- 不可申请原因（数据返回时）\n- 已有申请 ID、状态、公司名称、创建时间、发送时间（数据返回时）\n\nFor creation success, show:\n\n- 订单号\n- 发票申请 ID\n- 申请状态：`pending` = 待处理 / 待发送，`sent` = 已发送\n- 开票公司名称\n- 创建时间\n- 下一步：待财务处理或已发送，以工具返回状态为准\n\nDo not say the invoice has been issued or emailed unless the tool explicitly returns `sent`.\n\n## Errors\n\n- Email format errors: ask only for the email again; do not re-collect company name, tax number, phone, or optional fields.\n- Duplicate application: explain that the order has already submitted an invoice application and show returned status if available.\n- Order not found, not original order, unsupported status, flight not departed, or other cannot-apply reasons: show the tool-returned reason and do not create.\n- Missing optional fields never block creation unless the tool rejects them.\n\nFile v1.0.4:references/flight-itinerary.md\n\n# flight-itinerary ref\n\n## flight_download_itinerary\n\n下载已出票订单的行程单（电子行程单 / PDF / ZIP）。\n\n### 何时使用\n\n用户主动请求行程单或类行程单票据文件，且订单状态支持下载时。\n\n**不主动**在订单查询或其他操作结束后推送行程单下载。\n\n### 使用方式\n\n调用 `flight_download_itinerary` 时，传入订单号。\n\n请求参数中的 `type` 会影响常见返回格式：\n\n- `type=more`：生成合并文件，通常返回单个 PDF\n- `type=once`：可能生成多个文件，多个文件时可能返回 ZIP 压缩包\n\n下载完成后，说明返回文件的类型（工具返回该信息时）：\n\n- 是 PDF 文件\n- 是 ZIP 压缩包\n- 还是其他格式\n\n最终格式以工具返回的文件类型、响应 `Content-Type` 或文件名后缀为准。工具未返回文件类型信息时，如实说明未返回，不要猜测为 PDF。\n\n### 错误处理\n\n下载失败或订单状态不支持下载时，简短说明原因，建议用户核对订单状态或稍后重试。\n\nFile v1.0.4:references/flight-order-lookup.md\n\n# flight-order-lookup ref\n\n## flight_order_detail / flight_order_detail_by_external_id / flight_order_list\n\n查询用户的机票订单状态和订单列表。\n\n### 工具选择\n\n| 场景 | 使用工具 |\n|------|---------|\n| 用户提供 TravelKit 订单号 | `flight_order_detail` |\n| 用户提供买方侧外部订单号 | `flight_order_detail_by_external_id` |\n| 用户查找历史订单、按路线/日期/状态/票号/订座记录等线索筛选 | `flight_order_list` |\n\n**始终通过工具获取最新状态**，不依赖记忆中的出票、付款、退款或改签状态。\n\nPNR / 航司 PNR 仅可作为内部查单筛选条件；查询结果、订单详情、订单列表、支付后核查和异常说明都不得向普通用户展示 PNR，也不得展示 `PNR: 未返回`、`票号 / PNR` 或 `票号/PNR`。如果工具或错误原因返回 PNR 相关文字，必须改写为不含该词的自然中文。\n\n### 订单详情展示\n\n订单详情必须使用 `output-rules` 中的订单信息固定模板；字段未返回时填\"未返回\"，不要推断。航班只显示完整航班号，不展示航空公司名称。\n\n金额必须按共享口径展示：总价 = 票面价 + 税价。多乘客或多航段时，分别汇总票面价和税价后再计算总价。如果工具只返回总额但没有票面价或税价拆分，固定模板中的缺失拆分字段填\"未返回\"，不要编造。\n\n### 订单列表展示\n\n`flight_order_list` 返回多条结果时：\n\n- 按出发日期排序展示\n- 每条显示：订单号、路线、出发日期、支付状态、出票状态；不得显示 PNR\n- 支付状态和出票状态必须翻译成中文展示，不直接输出英文枚举。常见映射：`closed`=已关闭，`failed`=失败，`pending`/`processing`=处理中，`paid`/`success`/`succeeded`=已支付，`unpaid`/`not_paid`=未支付，`issued`/`ticketed`=已出票，`changed`=已改签，`refunded`=已退款，`cancelled`/`canceled`=已取消。未识别状态显示：`未识别状态（原值）`。\n- 路线展示为 `中文名 三字码 → 中文名 三字码`。中文名优先级：工具返回的中文城市/机场名 > skill 内置常见映射 > agent 明确认识的 IATA 城市码/机场码常识；不确定、冷门、冲突或无法判断城市/机场语义时，只展示原三字码，不编造中文名。\n- 不为了翻译三字码解析 raw JSON、临时调用额外工具或联网查询；不确定时不要解释过多，直接保留原码。\n- 订单列表路线常见城市码：`BJS`=北京，`SHA`=上海，`CAN`=广州，`HGH`=杭州，`DLU`=大理，`BKK`=曼谷，`SEL`=首尔，`TYO`=东京，`LON`=伦敦。\n- 机场码常见映射：`PEK`=北京首都，`PKX`=北京大兴，`PVG`=上海浦东，`SHA`=上海虹桥，`DMK`=曼谷廊曼，`ICN`=首尔仁川，`GMP`=首尔金浦。`SHA` 在城市级路线如 `BJS-SHA` 中展示为 `上海 SHA`；工具明确为机场时展示 `上海虹桥 SHA`。\n- 说明用户可以指定某个订单号继续操作\n\n### 错误处理\n\n订单找不到时，询问：订单号、外部订单号、票号、路线或出发日期，从而帮助定位；不要向普通用户提及 PNR。\n\nFile v1.0.4:references/flight-pay-order.md\n\n# flight-pay-order ref\n\n## Purpose\n\nUse `flight_pay_order` only for an already-created order when the user explicitly wants to pay. Never pay automatically.\n\n## Before Payment\n\n- Restate order number, amount, payment method, and known order status.\n- Amount follows `output-rules`: total = fare + tax.\n- If payment method is missing, ask the user to choose. Do not default.\n- User-facing methods: domestic can show 微信、支付宝、信用卡、借记卡; international can also show Airwallex.\n- Do not offer balance payment. If the user asks for it, show the supported user payment methods and ask them to choose again.\n\nInternal channel mapping:\n\n| User method | Tool channel |\n|---|---|\n| Airwallex | `airwallex` |\n| 支付宝 | `yeepay-alipay` |\n| 微信 | `yeepay-wechat` |\n| 信用卡 | `yeepay-credit-card` |\n| 借记卡 | `yeepay-debit-card` |\n\nAsk:\n\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\nCall `flight_pay_order` only after explicit confirmation.\n\n## Payment Link\n\nAfter `flight_pay_order` returns a third-party payment link, use this exact format. Do not expose internal channel names, raw JSON, `returnUrl`, or technical parameters.\n\n```markdown\n{支付方式}支付已发起，请打开链接完成付款：\n\n[前往{支付方式}支付]({支付链接})\n\n订单金额：¥{订单金额}\n交易手续费：¥{交易手续费}\n需支付合计：¥{订单金额 + 交易手续费}\n\n付款完成后告诉我一声，我帮你核查订单和出票状态。\n```\n\n- Payment method names: 微信、支付宝、信用卡、借记卡、Airwallex.\n- If payment link is missing, say: `支付链接暂未返回，我会先核查订单支付状态。`\n- Transaction fee must come from the tool. If fee is missing, show `未返回`; then payable total is also `未返回`.\n- Use the configured default third-party `returnUrl`; do not explain it to normal users.\n\n## Risk Checks\n\nBefore retrying payment, call `flight_order_detail` if amount mismatches, fare + tax conflicts with returned total, order status is unclear, prior payment may be processing, order may be expired, or deadline is unclear.\n\n## After User Says Paid\n\nGoal: check payment status and ticketing status without changing the order.\n\n1. Call read-only `flight_order_detail` immediately.\n2. If neither payment nor ticketing has a clear result, poll every 10 seconds（每 10 秒）.\n3. Stop after 12 total checks（12 次）, including the first immediate check.\n4. Use only `flight_order_detail`; never trigger pay, cancel, refund, or change during polling.\n5. Do not message the user on every poll. Reply only on a clear result, query failure, or after all 12 checks.\n6. Prefer background/timer/automation polling when available. If only synchronous waiting works, tell the user you are checking every 10 seconds. If the environment cannot wait or schedule, say so and ask the user to request another check later.\n\nClear results:\n\n- Payment terminal states: paid/success, failed, canceled, expired, or any explicit payment result returned by the tool.\n- Ticketing terminal states: ticketed/success, failed, abnormal, or any explicit ticketing result returned by the tool.\n- Missing or ambiguous fields are not results; keep polling until the limit.\n\nFinal notification must include order number, latest payment status, latest ticketing status, and next step. Use the `output-rules` order template when showing order details.\n\n## Errors\n\nOn payment failure, briefly explain the returned reason, check current order status with `flight_order_detail`, then decide whether retry is appropriate. Do not blindly retry.\n\nFile v1.0.4:references/flight-pricing.md\n\n# flight-pricing ref\n\n## flight_pricing\n\n按指定航班号和舱位查询实时票价，适用于用户已明确知道航班号的场景。\n\n### 何时使用\n\n仅当用户已同时提供以下全部信息时才使用：\n\n- 航班号\n- 出发机场\n- 到达机场\n- 出发日期\n- 舱位等级\n\n以上任意一项缺失，改用 `flight_search` 进行搜索。\n\n### 参数说明\n\n| 参数 | 是否必填 | 说明 |\n|------|---------|------|\n| `flightNo` | 必填 | 航班号，如 `CA1234` |\n| `origin` | 必填 | 出发机场 IATA 码 |\n| `destination` | 必填 | 到达机场 IATA 码 |\n| `departureDate` | 必填 | 出发日期 `YYYY-MM-DD` |\n| `cabinClass` | 必填 | `economy` / `business` / `first` |\n| `adult` | 必填 | 成人人数 |\n| `child` | 可选 | 儿童人数 |\n| `infant` | 可选 | 婴儿人数 |\n\n### 结果展示规则\n\n展示工具返回的可用票价选项，每个选项包含（数据返回时）：\n\n- 舱位等级和子舱位代码\n- 价格\n- 行李额\n- 退改规则摘要\n\n退改规则若以 `*`、`>n`、`n`、` 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\n用户明确确认后，这一次确认只适用于当前 `flight_create_order` 调用。内部可一次性设置创建订单所需的确认字段，包括生产写入确认字段；不要向普通用户展示\"生产环境\"、\"生产写入\"或要求用户为同一次创建订单进行二次确认。\n\n### 支付订单（flight_pay_order）\n\n确认前重述：\n\n- 订单号\n- 支付金额（总价 = 票面价 + 税价）\n- 支付方式\n- 当前订单状态（已知时）\n\n如果支付方式未知，先请用户选择或确认支付方式；不要自动填入任何默认支付方式。\n\n提示支付方式时，不向普通用户展示余额支付：\n\n- 国内机票：微信、支付宝、信用卡、借记卡\n- 国际机票：Airwallex、微信、支付宝、信用卡、借记卡\n\n如果用户要求余额支付，不直接发起支付；提示当前可选的用户支付方式并请用户重新选择。\n\n询问：\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\n### 创建发票申请（flight_create_order_invoice_application）\n\n创建前必须先调用 `flight_get_order_invoice_application` 确认订单可申请发票。\n\n确认前重述：\n\n- 订单号\n- 开票公司名称\n- 纳税人识别号\n- 接收邮箱\n- 联系手机号\n- 公司地址、公司电话、开户银行、银行账号、备注（用户提供时）\n\n询问：\n> 确认提交该订单的发票申请吗？\n\n### 取消订单（flight_cancel_order）\n\n确认前重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 取消操作及后果\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n### 提交退票（flight_refund_request / flight_refund_confirm）\n\n确认前重述：\n\n- 需要退票的乘客和航段\n- 退票原因\n- 估算退款金额和手续费（数据返回时）\n- 未返回的费用或政策信息说明\n\n询问：\n> 确认提交退票申请吗？\n\n### 提交改签（flight_change_request）\n\n确认前重述：\n\n- 原航班信息\n- 新航班信息\n- 需要改签的乘客\n- 改签手续费或注意事项（数据返回时）\n- 改签原因\n\n询问：\n> 确认提交改签申请吗？\n\n### 通用原则\n\n- **不得**将\"帮我订\"、\"退了吧\"、\"改一下\"等笼统意图视为足够确认\n- 每次写入操作都是独立的确认，不能将之前的确认视为连续适用\n- 创建订单的一次确认只覆盖该次创建订单；后续支付、取消、退票、改签仍必须重新确认\n- 确认话术使用自然消费者语言，不暴露内部确认字段、环境名称或 MCP 参数\n- 金额或状态出现异常时，先通过读取工具核查，再询问确认\n- 订单金额统一按 `output-rules` 的金额口径处理：总价 = 票面价 + 税价；没有票面价或税价拆分时，不编造拆分\n\nFile v1.0.3:references/flight-cancel.md\n\n# flight-cancel ref\n\n## flight_cancel_order\n\n取消未支付或可取消的机票订单，**必须经用户明确确认**。\n\n### 何时使用\n\n用户主动要求取消订单，且订单处于未支付或可取消状态时。\n\n已支付、已出票、已退款、已改签或不可取消的订单，说明取消可能不适用，视情况建议退票或改签流程。\n\n### 取消前确认\n\n调用 `flight_cancel_order` 前，重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 将要执行的操作\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n**只有用户明确确认后**才调用 `flight_cancel_order`。\n\n### 错误处理\n\n取消失败时，简短说明原因，展示最安全的下一步建议（如改用退票流程）。\n\nFile v1.0.3:references/flight-change.md\n\n# flight-change ref\n\n## flight_change_search / flight_change_request\n\n搜索可改签的航班选项，经用户选定并明确确认后提交改签申请。\n\n### 改签流程\n\n1. 需要时先通过 `flight_order_detail` 查询订单\n2. 确认需要改签的乘客和航段\n3. 询问新出发日期和舱位偏好（缺失时）\n4. 调用 `flight_change_search` 查询可用改签选项\n5. 展示多个改签选项（有时）\n6. 用户选定一个选项\n7. 重述：原航班号、新航班号、乘客、手续费或注意事项（数据返回时）、改签原因\n8. 询问用户明确确认\n9. 确认后调用 `flight_change_request`\n\n**不得**在展示可用改签选项前直接提交改签申请，除非用户在当前对话中已从工具结果中明确指定了有效选项。\n\n### 改签选项展示\n\n展示格式参考搜索结果，每个选项包含：\n\n- 新航班号（只显示完整航班号，不展示航空公司名称）\n- 新出发/到达时间\n- 改签手续费（数据返回时）\n- 可用舱位\n\n改签规则或手续费若以 `*`、`>n`、` 这趟是国内航班，后续需要乘机人证件信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 中文姓名我会按证件姓名识别姓、名；如果复姓或拆分不确定，我再单独确认。\n\n- 乘机人姓名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 证件类型\n- 证件号码\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n**International fixed prompt - must output verbatim**:\n\n> 这趟是国际航班，后续需要乘机人护照信息。请把下面信息发我，我再帮你创建订单，但不会自动支付：\n> 护照英文姓和英文名需要与护照完全一致。\n\n- 护照英文姓\n- 护照英文名\n- 出生日期\n- 性别\n- 乘客类型：成人 / 儿童 / 婴儿\n- 国籍\n- 护照号码\n- 护照有效期（请填写具体日期）\n- 乘机人手机号\n- 乘机人邮箱（可选：如果您希望我们通过邮箱给您发送通知，您可以填写邮箱）\n\n## Passenger Rules\n\n- Required per passenger: phone, document type, document number.\n- Email is optional notification info. If absent, omit passenger `email`; if supplier requires/rejects missing email, ask only for email.\n- ID card, Mainland Travel Permit, and Taiwan Travel Permit names use Chinese as on document; passports use passport English name.\n- For ID-card passengers, split one Chinese full name internally. Ask only if compound surname, ethnic/minority name, English name, very long name, or rare characters make splitting unclear.\n- If document type is unclear or cannot map to supported `travelDocument`, ask only for document type clarification.\n- If contact name/phone is absent, default to first passenger's name/phone, mention this before creation, and do not collect contact email.\n\n## Confirmation Before Creation\n\nBefore `flight_create_order`, summarize flight/route, departure/arrival time, passengers, contact info/defaults, final price, and returned notices. Amount line must be:\n\n> 金额：¥{总价}（票面价 ¥{票面价} + 税价 ¥{税价}）\n\nIf verified solution returned any segment `availability <= 3`, include remaining ticket count, e.g. `当前余票不多，仅剩 {availability} 张，请尽快完成预订和支付；未支付前票价和余票可能变化。` For multi-segment journeys, use lowest returned availability.\n\nAsk:\n> 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\nOnly after explicit confirmation, call `flight_create_order` with verified `orderKey` and required internal confirmation fields; do not mention production/technical flags.\n\n## After Creation\n\n- When useful, call `flight_order_detail` and show `output-rules` fixed order template.\n- Deadlines must come from explicit tool fields; if missing, use `output-rules` deadline wording.\n- Amount: total = fare + tax; sum fare/tax across passengers/segments. If only total is returned, mark fare/tax as `未返回`.\n- If unpaid, prompt payment options: domestic 微信、支付宝、信用卡、借记卡; international/cross-border also Airwallex.\n- If low inventory was known, include remaining ticket count and remind prompt payment, otherwise ticket may sell out.\n\n## Errors\n\n- Ask only for missing/corrected fields; do not require resubmitting all passenger details.\n- Name errors (`FirstName`, `LastName`, ID-card full name) mean document-name format issue; ask only for name correction and do not blame price/inventory.\n- If an abnormal order is unpaid and unticketed, re-verify price before creating a corrected new order.\n\nFile v1.0.3:references/flight-invoice.md\n\n# flight-invoice ref\n\n## flight_get_order_invoice_application / flight_create_order_invoice_application\n\nUse for flight order invoice requests: checking whether an order can apply for an invoice, checking invoice application status, and creating an invoice application.\n\n## Workflow\n\n1. Collect or confirm the TravelKit `orderId`.\n2. Always call read-only `flight_get_order_invoice_application` first.\n3. If an application exists, show its status and do not create another application.\n4. If `canApply` is false, show `canApplyReason` when returned and stop.\n5. If `canApply` is true and the user wants to apply, collect invoice information.\n6. Before `flight_create_order_invoice_application`, summarize the application details and ask for explicit confirmation.\n\n## Required Invoice Fields\n\nCollect these fields before creation:\n\n- 开票公司名称 (`companyName`)\n- 纳税人识别号 (`taxNo`)\n- 接收邮箱 (`email`)\n- 联系手机号 (`phone`)\n\nOptional fields:\n\n- 公司地址 (`companyAddress`)\n- 公司电话 (`companyPhone`)\n- 开户银行 (`bankName`)\n- 银行账号 (`bankAccount`)\n- 备注 (`remark`)\n\nUse `invoiceType: normal` by default. Do not ask normal users to choose invoice type unless the tool or product later returns more supported values.\n\n## Status Display\n\nFor query results, show in natural Chinese:\n\n- 是否可申请\n- 不可申请原因（数据返回时）\n- 已有申请 ID、状态、公司名称、创建时间、发送时间（数据返回时）\n\nFor creation success, show:\n\n- 订单号\n- 发票申请 ID\n- 申请状态：`pending` = 待处理 / 待发送，`sent` = 已发送\n- 开票公司名称\n- 创建时间\n- 下一步：待财务处理或已发送，以工具返回状态为准\n\nDo not say the invoice has been issued or emailed unless the tool explicitly returns `sent`.\n\n## Errors\n\n- Email format errors: ask only for the email again; do not re-collect company name, tax number, phone, or optional fields.\n- Duplicate application: explain that the order has already submitted an invoice application and show returned status if available.\n- Order not found, not original order, unsupported status, flight not departed, or other cannot-apply reasons: show the tool-returned reason and do not create.\n- Missing optional fields never block creation unless the tool rejects them.\n\nFile v1.0.3:references/flight-itinerary.md\n\n# flight-itinerary ref\n\n## flight_download_itinerary\n\n下载已出票订单的行程单（电子行程单 / PDF / ZIP）。\n\n### 何时使用\n\n用户主动请求行程单或类行程单票据文件，且订单状态支持下载时。\n\n**不主动**在订单查询或其他操作结束后推送行程单下载。\n\n### 使用方式\n\n调用 `flight_download_itinerary` 时，传入订单号。\n\n请求参数中的 `type` 会影响常见返回格式：\n\n- `type=more`：生成合并文件，通常返回单个 PDF\n- `type=once`：可能生成多个文件，多个文件时可能返回 ZIP 压缩包\n\n下载完成后，说明返回文件的类型（工具返回该信息时）：\n\n- 是 PDF 文件\n- 是 ZIP 压缩包\n- 还是其他格式\n\n最终格式以工具返回的文件类型、响应 `Content-Type` 或文件名后缀为准。工具未返回文件类型信息时，如实说明未返回，不要猜测为 PDF。\n\n### 错误处理\n\n下载失败或订单状态不支持下载时，简短说明原因，建议用户核对订单状态或稍后重试。\n\nFile v1.0.3:references/flight-order-lookup.md\n\n# flight-order-lookup ref\n\n## flight_order_detail / flight_order_detail_by_external_id / flight_order_list\n\n查询用户的机票订单状态和订单列表。\n\n### 工具选择\n\n| 场景 | 使用工具 |\n|------|---------|\n| 用户提供 TravelKit 订单号 | `flight_order_detail` |\n| 用户提供买方侧外部订单号 | `flight_order_detail_by_external_id` |\n| 用户查找历史订单、按路线/日期/状态/票号/订座记录等线索筛选 | `flight_order_list` |\n\n**始终通过工具获取最新状态**，不依赖记忆中的出票、付款、退款或改签状态。\n\nPNR / 航司 PNR 仅可作为内部查单筛选条件；查询结果、订单详情、订单列表、支付后核查和异常说明都不得向普通用户展示 PNR，也不得展示 `PNR: 未返回`、`票号 / PNR` 或 `票号/PNR`。如果工具或错误原因返回 PNR 相关文字，必须改写为不含该词的自然中文。\n\n### 订单详情展示\n\n订单详情必须使用 `output-rules` 中的订单信息固定模板；字段未返回时填\"未返回\"，不要推断。航班只显示完整航班号，不展示航空公司名称。\n\n金额必须按共享口径展示：总价 = 票面价 + 税价。多乘客或多航段时，分别汇总票面价和税价后再计算总价。如果工具只返回总额但没有票面价或税价拆分，固定模板中的缺失拆分字段填\"未返回\"，不要编造。\n\n### 订单列表展示\n\n`flight_order_list` 返回多条结果时：\n\n- 按出发日期排序展示\n- 每条显示：订单号、路线、出发日期、支付状态、出票状态；不得显示 PNR\n- 支付状态和出票状态必须翻译成中文展示，不直接输出英文枚举。常见映射：`closed`=已关闭，`failed`=失败，`pending`/`processing`=处理中，`paid`/`success`/`succeeded`=已支付，`unpaid`/`not_paid`=未支付，`issued`/`ticketed`=已出票，`changed`=已改签，`refunded`=已退款，`cancelled`/`canceled`=已取消。未识别状态显示：`未识别状态（原值）`。\n- 路线展示为 `中文名 三字码 → 中文名 三字码`。中文名优先级：工具返回的中文城市/机场名 > skill 内置常见映射 > agent 明确认识的 IATA 城市码/机场码常识；不确定、冷门、冲突或无法判断城市/机场语义时，只展示原三字码，不编造中文名。\n- 不为了翻译三字码解析 raw JSON、临时调用额外工具或联网查询；不确定时不要解释过多，直接保留原码。\n- 订单列表路线常见城市码：`BJS`=北京，`SHA`=上海，`CAN`=广州，`HGH`=杭州，`DLU`=大理，`BKK`=曼谷，`SEL`=首尔，`TYO`=东京，`LON`=伦敦。\n- 机场码常见映射：`PEK`=北京首都，`PKX`=北京大兴，`PVG`=上海浦东，`SHA`=上海虹桥，`DMK`=曼谷廊曼，`ICN`=首尔仁川，`GMP`=首尔金浦。`SHA` 在城市级路线如 `BJS-SHA` 中展示为 `上海 SHA`；工具明确为机场时展示 `上海虹桥 SHA`。\n- 说明用户可以指定某个订单号继续操作\n\n### 错误处理\n\n订单找不到时，询问：订单号、外部订单号、票号、路线或出发日期，从而帮助定位；不要向普通用户提及 PNR。\n\nFile v1.0.3:references/flight-pay-order.md\n\n# flight-pay-order ref\n\n## Purpose\n\nUse `flight_pay_order` only for an already-created order when the user explicitly wants to pay. Never pay automatically.\n\n## Before Payment\n\n- Restate order number, amount, payment method, and known order status.\n- Amount follows `output-rules`: total = fare + tax.\n- If payment method is missing, ask the user to choose. Do not default.\n- User-facing methods: domestic can show 微信、支付宝、信用卡、借记卡; international can also show Airwallex.\n- Do not offer balance payment. If the user asks for it, show the supported user payment methods and ask them to choose again.\n\nInternal channel mapping:\n\n| User method | Tool channel |\n|---|---|\n| Airwallex | `airwallex` |\n| 支付宝 | `yeepay-alipay` |\n| 微信 | `yeepay-wechat` |\n| 信用卡 | `yeepay-credit-card` |\n| 借记卡 | `yeepay-debit-card` |\n\nAsk:\n\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\nCall `flight_pay_order` only after explicit confirmation.\n\n## Payment Link\n\nAfter `flight_pay_order` returns a third-party payment link, use this exact format. Do not expose internal channel names, raw JSON, `returnUrl`, or technical parameters.\n\n```markdown\n{支付方式}支付已发起，请打开链接完成付款：\n\n[前往{支付方式}支付]({支付链接})\n\n订单金额：¥{订单金额}\n交易手续费：¥{交易手续费}\n需支付合计：¥{订单金额 + 交易手续费}\n\n付款完成后告诉我一声，我帮你核查订单和出票状态。\n```\n\n- Payment method names: 微信、支付宝、信用卡、借记卡、Airwallex.\n- If payment link is missing, say: `支付链接暂未返回，我会先核查订单支付状态。`\n- Transaction fee must come from the tool. If fee is missing, show `未返回`; then payable total is also `未返回`.\n- Use the configured default third-party `returnUrl`; do not explain it to normal users.\n\n## Risk Checks\n\nBefore retrying payment, call `flight_order_detail` if amount mismatches, fare + tax conflicts with returned total, order status is unclear, prior payment may be processing, order may be expired, or deadline is unclear.\n\n## After User Says Paid\n\nGoal: check payment status and ticketing status without changing the order.\n\n1. Call read-only `flight_order_detail` immediately.\n2. If neither payment nor ticketing has a clear result, poll every 10 seconds（每 10 秒）.\n3. Stop after 12 total checks（12 次）, including the first immediate check.\n4. Use only `flight_order_detail`; never trigger pay, cancel, refund, or change during polling.\n5. Do not message the user on every poll. Reply only on a clear result, query failure, or after all 12 checks.\n6. Prefer background/timer/automation polling when available. If only synchronous waiting works, tell the user you are checking every 10 seconds. If the environment cannot wait or schedule, say so and ask the user to request another check later.\n\nClear results:\n\n- Payment terminal states: paid/success, failed, canceled, expired, or any explicit payment result returned by the tool.\n- Ticketing terminal states: ticketed/success, failed, abnormal, or any explicit ticketing result returned by the tool.\n- Missing or ambiguous fields are not results; keep polling until the limit.\n\nFinal notification must include order number, latest payment status, latest ticketing status, and next step. Use the `output-rules` order template when showing order details.\n\n## Errors\n\nOn payment failure, briefly explain the returned reason, check current order status with `flight_order_detail`, then decide whether retry is appropriate. Do not blindly retry.\n\nFile v1.0.3:references/flight-pricing.md\n\n# flight-pricing ref\n\n## flight_pricing\n\n按指定航班号和舱位查询实时票价，适用于用户已明确知道航班号的场景。\n\n### 何时使用\n\n仅当用户已同时提供以下全部信息时才使用：\n\n- 航班号\n- 出发机场\n- 到达机场\n- 出发日期\n- 舱位等级\n\n以上任意一项缺失，改用 `flight_search` 进行搜索。\n\n### 参数说明\n\n| 参数 | 是否必填 | 说明 |\n|------|---------|------|\n| `flightNo` | 必填 | 航班号，如 `CA1234` |\n| `origin` | 必填 | 出发机场 IATA 码 |\n| `destination` | 必填 | 到达机场 IATA 码 |\n| `departureDate` | 必填 | 出发日期 `YYYY-MM-DD` |\n| `cabinClass` | 必填 | `economy` / `business` / `first` |\n| `adult` | 必填 | 成人人数 |\n| `child` | 可选 | 儿童人数 |\n| `infant` | 可选 | 婴儿人数 |\n\n### 结果展示规则\n\n展示工具返回的可用票价选项，每个选项包含（数据返回时）：\n\n- 舱位等级和子舱位代码\n- 价格\n- 行李额\n- 退改规则摘要\n\n退改规则若以 `*`、`>n`、`n`、` 确认后我会为你创建订单，但不会自动支付。是否确认创建？\n\n用户明确确认后，这一次确认只适用于当前 `flight_create_order` 调用。内部可一次性设置创建订单所需的确认字段，包括生产写入确认字段；不要向普通用户展示\"生产环境\"、\"生产写入\"或要求用户为同一次创建订单进行二次确认。\n\n### 支付订单（flight_pay_order）\n\n确认前重述：\n\n- 订单号\n- 支付金额（总价 = 票面价 + 税价）\n- 支付方式\n- 当前订单状态（已知时）\n\n如果支付方式未知，先请用户选择或确认支付方式；不要自动填入任何默认支付方式。\n\n提示支付方式时，不向普通用户展示余额支付：\n\n- 国内机票：微信、支付宝、易宝移动支付、信用卡、借记卡\n- 国际机票：Airwallex、微信、支付宝、易宝移动支付、信用卡、借记卡\n\n如果用户要求余额支付，不直接发起支付；提示当前可选的用户支付方式并请用户重新选择。\n\n询问：\n> 是否确认支付？\n\n- 支付金额：¥xxx\n- 订单号：xxxxxx\n\n### 创建发票申请（flight_create_order_invoice_application）\n\n创建前必须先调用 `flight_get_order_invoice_application` 确认订单可申请发票。\n\n确认前重述：\n\n- 订单号\n- 开票公司名称\n- 纳税人识别号\n- 接收邮箱\n- 联系手机号\n- 公司地址、公司电话、开户银行、银行账号、备注（用户提供时）\n\n询问：\n> 确认提交该订单的发票申请吗？\n\n### 取消订单（flight_cancel_order）\n\n确认前重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 取消操作及后果\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n### 提交退票（flight_refund_request / flight_refund_confirm）\n\n确认前重述：\n\n- 需要退票的乘客和航段\n- 退票原因\n- 估算退款金额和手续费（数据返回时）\n- 未返回的费用或政策信息说明\n\n询问：\n> 确认提交退票申请吗？\n\n### 提交改签（flight_change_request）\n\n确认前重述：\n\n- 原航班信息\n- 新航班信息\n- 需要改签的乘客\n- 改签手续费或注意事项（数据返回时）\n- 改签原因\n\n询问：\n> 确认提交改签申请吗？\n\n### 通用原则\n\n- **不得**将\"帮我订\"、\"退了吧\"、\"改一下\"等笼统意图视为足够确认\n- 每次写入操作都是独立的确认，不能将之前的确认视为连续适用\n- 创建订单的一次确认只覆盖该次创建订单；后续支付、取消、退票、改签仍必须重新确认\n- 确认话术使用自然消费者语言，不暴露内部确认字段、环境名称或 MCP 参数\n- 金额或状态出现异常时，先通过读取工具核查，再询问确认\n- 订单金额统一按 `output-rules` 的金额口径处理：总价 = 票面价 + 税价；没有票面价或税价拆分时，不编造拆分"},{"path":"references/flight-cancel.md","content":"# flight-cancel ref\n\n## flight_cancel_order\n\n取消未支付或可取消的机票订单，**必须经用户明确确认**。\n\n### 何时使用\n\n用户主动要求取消订单，且订单处于未支付或可取消状态时。\n\n已支付、已出票、已退款、已改签或不可取消的订单，说明取消可能不适用，视情况建议退票或改签流程。\n\n### 取消前确认\n\n调用 `flight_cancel_order` 前，重述：\n\n- 订单号\n- 乘客或路线摘要\n- 当前订单状态\n- 将要执行的操作\n\n询问：\n> 确认取消该订单吗？取消后不可恢复。\n\n**只有用户明确确认后**才调用 `flight_cancel_order`。\n\n### 错误处理\n\n取消失败时，简短说明原因，展示最安全的下一步建议（如改用退票流程）。"},{"path":"references/flight-change.md","content":"# flight-change ref\n\n## flight_change_search / flight_change_request\n\n搜索可改签的航班选项，经用户选定并明确确认后提交改签申请。\n\n### 改签流程\n\n1. 需要时先通过 `flight_order_detail` 查询订单\n2. 确认需要改签的乘客和航段\n3. 询问新出发日期和舱位偏好（缺失时）\n4. 调用 `flight_change_search` 查询可用改签选项\n5. 展示多个改签选项（有时）\n6. 用户选定一个选项\n7. 重述：原航班号、新航班号、乘客、手续费或注意事项（数据返回时）、改签原因\n8. 询问用户明确确认\n9. 确认后调用 `flight_change_request`\n\n**不得**在展示可用改签选项前直接提交改签申请，除非用户在当前对话中已从工具结果中明确指定了有效选项。\n\n### 改签选项展示\n\n展示格式参考搜索结果，每个选项包含：\n\n- 新航班号（只显示完整航班号，不展示航空公司名称）\n- 新出发/到达时间\n- 改签手续费（数据返回时）\n- 可用舱位\n\n改签规则或手续费若以 `*`、`>n`、`