1. “agent-skills”不是项目名而是能力契约的命名范式你第一次在 GitHub 上看到agent-skills这个仓库名时大概率会愣一下它既不像create-react-app那样直白也不像nestjs-cli那样指向明确工具。它没有.js后缀没有lib或core字样甚至没带版本号。但它高频出现在 Nx monorepo 的 workspace.json、TypeScript 类型定义文件、以及语义化发布semantic-release的 changelog 生成逻辑里——这恰恰说明agent-skills不是一个可执行程序而是一套被工程化封装的“能力契约”Capability Contract。我最早在一家做智能工单系统的团队里接触这个命名。他们不叫它“插件”“模块”或“服务”就叫agent-skills。为什么因为他们的 AI Agent 不是靠写死逻辑驱动的而是通过一组明确定义、可组合、可验证、可热替换的“技能单元”来响应用户请求。比如“查订单状态”是一个 skill“生成售后方案”是另一个 skill“调用 ERP 接口”又是一个 skill。每个 skill 都暴露统一接口输入是结构化 context user query输出是 typed result side effects如日志、事件触发、外部调用。agent-skills就是这些 skill 的 TypeScript 类型定义 基础运行时抽象 Nx 工程化组织方式的总和。它背后藏着三个硬性约束直接决定了整个项目的骨架类型先行TypeScript 驱动所有 skill 的输入/输出必须有精确 interface 定义且这些定义要能被 IDE 自动补全、被 tsc 编译检查、被 Jest 测试用例消费。这意味着agent-skills的核心不是代码实现而是src/lib/skills/index.ts里那一组export interface SkillInputT {...}和export type SkillResult { success: boolean; data: any; error?: string };——它们是整个系统可维护性的第一道防线。隔离即安全Nx workspace 分层每个 skill 必须独立成包library不能跨包直接 import 实现逻辑。你只能 import 其类型定义org/agent-skills/order-status的 types或通过统一 dispatcher 调用dispatcher.execute(order-status, input)。Nx 的 project graph 和 dependency linting 强制执行这一点。我见过太多团队把 skill 写成一个 giant service 文件结果改一个字段整个 CI 爆红 37 个测试——agent-skills的目录结构就是反模式的物理隔离libs/agent-skills/order-status,libs/agent-skills/refund-policy,libs/agent-skills/escalation-trigger每个都是独立构建、独立版本、独立文档的单元。发布即契约semantic-release 自动化每个 skill 包的 version 不由人手动 bump而是由 commit message 的 prefix 决定feat:、fix:、perf:。semantic-release拿到libs/agent-skills/order-status的 changelog 后自动计算 patch/minor/major并发布到私有 registry。下游服务比如客服对话引擎只依赖org/agent-skills/order-status^2.1.0只要 major 版本不变它就敢放心升级——因为agent-skills的语义版本规则本质是“类型兼容性承诺”。v2.1.0升级到v2.1.1意味着你只加了字段、没删字段、没改字段类型v2.1.1升级到v3.0.0意味着某个input.status字段从string改成了enum Status这是破坏性变更必须显式确认。所以当你看到agent-skills请立刻切换思维这不是一个 npm 包名而是一个工程协议。它规定了“什么样的代码才能被称作一个 agent skill”就像 HTTP 规定了“什么样的报文才算合法请求”。你接下来要做的不是 clone 仓库跑起来而是理解这套协议怎么落地——从 TypeScript 类型设计开始到 Nx workspace 配置再到 semantic-release 的钩子定制每一步都在加固这个契约。提示很多新手误以为agent-skills是个 CLI 工具试图npx agent-skills init。它根本不存在。它的“安装”方式是在 Nx workspace 里执行nx g nrwl/node:library --nameagent-skills-core --directorylibs/agent-skills --no-interactive然后手动填充类型定义和 dispatcher 抽象。所有 magic 都来自约定而非魔法命令。2. TypeScript 类型定义skill 接口的最小完备集agent-skills的 TypeScript 类型不是装饰而是骨架。它必须回答四个问题谁调用我我接收什么我返回什么我可能出什么错少一个契约就失效。我见过最典型的错误是把 skill 写成(input: any) Promiseany——这等于没定义IDE 不提示tsc 不报错测试难写上线后字段拼错三天才发现。我们从零开始构建一个真实可用的 skill 类型体系。注意这里不讲泛型高级技巧只列生产环境验证过的最小完备集。2.1 核心接口SkillDefinition 与 SkillExecutor// libs/agent-skills-core/src/lib/types.ts export interface SkillContext { /** 用户会话唯一 ID用于 trace 和 debug */ sessionId: string; /** 当前用户角色admin/customer/agent影响权限校验 */ role: admin | customer | agent; /** 请求时间戳精度到毫秒 */ timestamp: number; /** 可选上游传递的上下文数据如当前订单 ID、产品 SKU */ metadata?: Recordstring, unknown; } export interface SkillInputT unknown { /** 技能标识符必须全局唯一用于 dispatcher 路由 */ skillId: string; /** 结构化输入参数T 是具体 skill 的业务类型 */ params: T; /** 运行时上下文 */ context: SkillContext; } export interface SkillResultR unknown { /** 执行是否成功 */ success: boolean; /** 成功时的业务数据 */ data?: R; /** 失败时的结构化错误信息 */ error?: { code: string; // 如 ORDER_NOT_FOUND, PERMISSION_DENIED message: string; // 用户友好的提示非 stack trace details?: Recordstring, unknown; // 供前端决策的附加字段如 retryable: true }; /** 可选side effect 描述用于审计日志 */ sideEffects?: Array{ type: api-call | db-write | event-emit; target: string; // 如 erp-api/v2/orders durationMs: number; }; } /** 技能执行器函数签名所有 skill 必须实现此类型 */ export type SkillExecutorTParams, TResult ( input: SkillInputTParams ) PromiseSkillResultTResult; /** 技能定义包含元数据 执行器用于注册到 dispatcher */ export interface SkillDefinitionTParams unknown, TResult unknown { /** 技能 ID必须与 SkillInput.skillId 一致 */ id: string; /** 技能名称用于 UI 展示和日志 */ name: string; /** 技能描述用于自动生成文档 */ description: string; /** 输入参数类型定义用于生成 OpenAPI schema */ inputSchema: Recordstring, unknown; /** 输出结果类型定义 */ outputSchema: Recordstring, unknown; /** 执行器函数 */ executor: SkillExecutorTParams, TResult; /** 是否启用用于灰度发布 */ enabled: boolean; }这段代码看着简单但每个字段都有强业务含义。比如context.metadata它不是随便塞个 object 就行。在我们的工单系统里它必须包含orderId如果用户问的是订单、customerId用于风控查询、channel微信/APP/电话影响响应模板。我们用 Zod 对其做 runtime 校验// libs/agent-skills-core/src/lib/validators.ts import { z } from zod; export const SkillContextValidator z.object({ sessionId: z.string().min(16), role: z.enum([admin, customer, agent]), timestamp: z.number().int().positive(), metadata: z .object({ orderId: z.string().optional(), customerId: z.string().optional(), channel: z.enum([wechat, app, phone]).optional(), }) .optional(), }); // 在 dispatcher 执行前校验 export function validateContext(context: unknown): SkillContext { try { return SkillContextValidator.parse(context); } catch (e) { throw new Error(Invalid skill context: ${e}); } }为什么不用interface直接定义因为interface只在编译期存在runtime 无法校验。而agent-skills的 dispatcher 是运行时路由如果metadata.orderId是number而不是string下游 ERP 接口直接 400。Zod 校验是最后一道防线。2.2 具体 skill 的类型实现以order-status为例现在看一个真实 skill 的类型定义。它位于libs/agent-skills/order-status/src/lib/types.tsimport { SkillInput, SkillResult } from org/agent-skills-core; // 输入参数必须精确到字段级 export interface OrderStatusInput { /** 订单号必须是 18 位数字字符串 */ orderNo: string; /** 可选是否需要物流详情 */ includeLogistics?: boolean; } // 输出结果结构化无 any export interface OrderStatusResult { /** 订单基础信息 */ order: { no: string; status: created | paid | shipped | delivered | cancelled; amount: number; // 单位分 currency: CNY; }; /** 物流信息当 includeLogisticstrue 时存在 */ logistics?: { carrier: string; trackingNo: string; steps: Array{ time: string; // ISO 8601 status: string; location: string; }; }; } // 导出 SkillInput 和 SkillResult 的具体泛型实例 export type OrderStatusSkillInput SkillInputOrderStatusInput; export type OrderStatusSkillResult SkillResultOrderStatusResult; // 导出技能定义供 dispatcher 注册 export const orderStatusSkill: SkillDefinition OrderStatusInput, OrderStatusResult { id: order-status, name: 查询订单状态, description: 根据订单号获取订单当前状态及物流信息, inputSchema: { type: object, properties: { orderNo: { type: string, pattern: ^\\d{18}$ }, includeLogistics: { type: boolean, default: false }, }, required: [orderNo], }, outputSchema: { type: object, properties: { order: { type: object, properties: { no: { type: string }, status: { type: string, enum: [created, paid, shipped, delivered, cancelled] }, amount: { type: integer }, currency: { type: string, enum: [CNY] }, }, required: [no, status, amount, currency], }, logistics: { type: [object, null], properties: { carrier: { type: string }, trackingNo: { type: string }, steps: { type: array, items: { type: object, properties: { time: { type: string, format: date-time }, status: { type: string }, location: { type: string }, }, required: [time, status], }, }, }, }, }, required: [order], }, executor: async (input) { // 实现略见后文 }, enabled: true, };注意几个关键点inputSchema和outputSchema是 JSON Schema不是 TypeScript interface。为什么因为我们要用它生成 OpenAPI 文档、供 Postman 导入、做 Swagger UI 测试。TypeScript interface 无法直接转成 JSON Schema除非用 ts-json-schema-generator但那又引入新依赖。所以我们手写——虽然多写几行但 100% 可控且与 runtime 完全一致。orderNo的正则^\\d{18}$是硬性业务规则不是可选建议。它在 Zod 校验和 OpenAPI 文档里都生效前端表单也能据此做实时校验。logistics字段类型是object | null而不是object | undefined。因为 REST API 返回时如果includeLogisticsfalse后端会省略该字段如果includeLogisticstrue但无物流信息会返回logistics: null。TypeScript 的undefined在 JSON 序列化时会被丢弃null会被保留。这个细节决定前端能否正确区分“未请求物流”和“请求了但无数据”。2.3 类型复用与组合避免重复定义一个 skill 很少孤立存在。refund-policyskill 需要复用order-status的OrderStatusResult.order结构escalation-triggerskill 需要判断order.status。如果每个 skill 都自己定义Orderinterface一旦订单结构变更你要改 5 个文件。解决方案在agent-skills-core中定义共享 domain types。// libs/agent-skills-core/src/lib/domain/order.ts export interface Order { no: string; status: created | paid | shipped | delivered | cancelled; amount: number; currency: CNY; createdAt: string; // ISO 8601 updatedAt: string; } export interface OrderItem { sku: string; name: string; quantity: number; price: number; // 单位分 }然后在具体 skill 中 import// libs/agent-skills/refund-policy/src/lib/types.ts import { Order } from org/agent-skills-core; import { SkillInput, SkillResult } from org/agent-skills-core; export interface RefundPolicyInput { order: Order; // 复用 core 定义 reason: quality | wrong-item | late-delivery | other; } export interface RefundPolicyResult { eligible: boolean; maxRefundAmount: number; // 单位分 refundSteps: string[]; // 如 [申请退款, 审核中, 已打款] estimatedTime: string; // ISO 8601 duration, e.g. P3D }这样当订单结构增加paymentMethod: alipay | wechat | bank-transfer你只需在agent-skills-core的Orderinterface 里加一行所有引用它的 skill 自动获得新字段tsc 会帮你找出哪些地方需要适配。注意agent-skills-core不能依赖任何具体 skill 的代码只能 export types 和 utils。这是 Nx dependency linting 的红线。我们在nx.json中配置targetDefaults: { dep-graph: { ignoreImplicitDependencies: false } }, implicitDependencies: { package.json: { dependencies: *, devDependencies: * } }, projects: { agent-skills-core: { tags: [type, shared] }, agent-skills-order-status: { tags: [skill, order], implicitDependencies: [agent-skills-core] } }3. Nx workspace 配置monorepo 的物理边界与构建流水线agent-skills的价值90% 体现在 Nx workspace 的配置里。没有 Nx它就是一堆分散的 TypeScript 类型文件有了 Nx它才成为可协作、可测试、可发布的工程实体。我见过太多团队把agent-skills目录扔进普通 Node.js 项目结果半年后变成难以维护的意大利面条——因为缺少物理隔离、依赖检查、增量构建这三把刀。3.1 workspace.jsonskill 库的标准化生成脚本Nx 的workspace.json或新版project.json是agent-skills的宪法。它定义了每个 skill 库的构建、测试、打包行为。关键不是写得多而是写得准。// workspace.json { projects: { agent-skills-core: { root: libs/agent-skills-core, sourceRoot: libs/agent-skills-core/src, projectType: library, targets: { build: { executor: nrwl/js:webpack, outputs: [{options.outputPath}], options: { outputPath: dist/libs/agent-skills-core, main: libs/agent-skills-core/src/index.ts, tsConfig: libs/agent-skills-core/tsconfig.lib.json, assets: [libs/agent-skills-core/*.md] } }, test: { executor: nrwl/jest:jest, options: { jestConfig: libs/agent-skills-core/jest.config.ts, passWithNoTests: true } } } }, agent-skills-order-status: { root: libs/agent-skills/order-status, sourceRoot: libs/agent-skills/order-status/src, projectType: library, targets: { build: { executor: nrwl/js:webpack, outputs: [{options.outputPath}], options: { outputPath: dist/libs/agent-skills/order-status, main: libs/agent-skills/order-status/src/index.ts, tsConfig: libs/agent-skills/order-status/tsconfig.lib.json, assets: [libs/agent-skills/order-status/*.md] } }, test: { executor: nrwl/jest:jest, options: { jestConfig: libs/agent-skills/order-status/jest.config.ts, passWithNoTests: true } } } } } }重点看buildtarget 的配置executor: 使用nrwl/js:webpack而不是nrwl/node:node。为什么因为agent-skills的产出物是ESM 格式的类型定义 JS 实现供其他 TypeScript 项目 import。nrwl/node:node会生成 CommonJS导致下游项目import { orderStatusSkill } from org/agent-skills/order-status时报Cannot use import statement outside a module。Webpack 打包能保证输出 ESM。assets: 包含*.md文件。每个 skill 库必须有README.md描述其用途、输入输出示例、错误码列表。Nx build 时会把它们一起 copy 到dist/目录npm publish 后用户npm view org/agent-skills/order-status就能看到完整文档。tsConfig: 每个 skill 库有自己的tsconfig.lib.json继承自根目录的tsconfig.base.json但覆盖composite: true和declaration: true。这是为了支持 TypeScript 的 project references让 IDE 能跨库跳转类型定义。3.2 nx.json依赖图与增量构建的神经中枢nx.json是 Nx 的大脑它让agent-skills的修改真正“局部化”。// nx.json { affected: { defaultBase: main }, tasksRunnerOptions: { default: { runner: nrwl/workspace/tasks-runner, options: { cacheableOperations: [build, test, lint, e2e] } } }, targetDefaults: { build: { dependsOn: [^build], inputs: [ {projectRoot}/**/*, {workspaceRoot}/tsconfig.base.json ] }, test: { inputs: [ {projectRoot}/**/*, {workspaceRoot}/tsconfig.base.json, {projectRoot}/jest.config.ts ] } }, namedInputs: { default: [{projectRoot}/**/*], production: [default] }, pluginsConfig: { nrwl/js: { analyzeSourceFiles: true } } }关键配置解读dependsOn: [^build]表示agent-skills-order-status的 build 任务必须等待其所有依赖^表示 upstream的 build 完成。agent-skills-order-status依赖agent-skills-core所以nx build agent-skills-order-status会先 buildagent-skills-core再 build 自己。这保证了类型定义总是最新的。cacheableOperationsbuild和test是可缓存的。Nx 会为每次 build 计算 hash基于源码、tsconfig、依赖版本如果 hash 未变直接复用上次的 dist 输出。实测在一个有 23 个 skill 的 workspace 里修改一个 skill 的单个文件nx build平均耗时从 42s 降到 1.8s。analyzeSourceFiles: true启用 source file analysis。Nx 能精确知道libs/agent-skills-core/src/lib/domain/order.ts的修改只影响 import 它的 skill如order-status,refund-policy而不影响escalation-trigger它只 importagent-skills-core/src/lib/types.ts。这是增量构建的基石。3.3 自定义 generator一键创建新 skill 的标准流程手动创建一个 skill 库太容易出错忘记改workspace.json、漏掉tsconfig、jest.config.ts模板不对。Nx 的 generator 就是解决这个问题的。我们创建了一个org/agent-skills-plugin:skillgeneratornx g org/agent-skills-plugin:skill --nameinventory-check --description查询商品库存状态它会自动生成libs/agent-skills/inventory-check/libs/agent-skills/inventory-check/src/lib/types.ts预填充 SkillDefinition 模板libs/agent-skills/inventory-check/src/index.ts导出 skill 定义libs/agent-skills/inventory-check/jest.config.ts预设覆盖率阈值 80%libs/agent-skills/inventory-check/tsconfig.lib.json正确继承 base config自动更新workspace.json添加新 project 配置自动更新nx.json确保依赖关系正确generator 的核心逻辑简化版// libs/agent-skills-plugin/src/generators/skill/generator.ts import { Tree, formatFiles, generateFiles, joinPathFragments } from nrwl/devkit; export async function skillGenerator(host: Tree, schema: SkillGeneratorSchema) { const { name, description } schema; // 1. 创建目录 const projectDir joinPathFragments(libs, agent-skills, name); generateFiles(host, joinPathFragments(__dirname, files), projectDir, { tmpl: , name, description, lowerName: name.toLowerCase(), }); // 2. 更新 workspace.json updateWorkspaceJson(host, name, description); // 3. 添加依赖强制依赖 agent-skills-core addProjectDependency(host, name, agent-skills-core); // 4. 格式化 await formatFiles(host); }这个 generator 的价值在于它把agent-skills的工程规范变成了不可绕过的 CLI 步骤。新人加入团队不需要读 20 页文档nx g ...一行命令就产出符合所有约定的 skill 库。规范不再是纸面要求而是代码强制。提示generator 的files模板里types.ts文件已经预置了完整的SkillDefinition模板包括inputSchema和outputSchema的 JSON Schema 示例。开发者只需填空不用从零写。这是降低认知负荷的关键。4. semantic-release 配置用 commit message 驱动版本与发布agent-skills的语义化发布不是锦上添花而是契约的生命线。如果org/agent-skills/order-status的v2.1.0升级到v2.1.1后input.orderNo类型从string变成number下游服务就会在 runtime 崩溃——而 semantic-release 的 job就是确保这种事永不发生。4.1 commit message 规范conventional commits 是唯一真理agent-skills的所有 commit 必须遵循 Conventional Commits 。这不是风格选择是机器可读的契约声明。feat(order-status): add includeLogistics option→ 触发 minor version bump (v2.0.0→v2.1.0)fix(refund-policy): handle null order items→ 触发 patch version bump (v1.2.3→v1.2.4)perf(inventory-check): cache ERP response for 5m→ 触发 patch version bumpchore(core): update zod to v3.22→ 不触发版本 bump只更新 changelogBREAKING CHANGE: change orderStatus input from string to number→ 在 commit body 里声明触发 major version bump (v2.1.0→v3.0.0)为什么必须严格因为semantic-release的核心算法是扫描最近一次 release tag 到 HEAD 的所有 commit按 prefix 分类取最高优先级的 type 决定版本号。featfixperfchore。BREAKING CHANGE标记 override 所有强制 major。我们在 CI 的 pre-commit hook 里集成commitlint// .commitlintrc.json { extends: [commitlint/config-conventional], rules: { type-enum: [ 2, always, [feat, fix, perf, chore, docs, test, refactor, build, ci] ], scope-enum: [ 2, always, [core, order-status, refund-policy, escalation-trigger, inventory-check] ] } }scope-enum限制 scope 必须是已知 skill 名防止拼错order-stauts。CI 流水线里commitlint是第一个 job失败则整个 pipeline 终止。4.2 .releaserc 配置为每个 skill 库定制发布策略.releaserc不是全局一份而是每个 skill 库自己的.releaserc。因为不同 skill 的发布频率、目标 registry、npm tag 都不同。// libs/agent-skills/order-status/.releaserc { branches: [main, { name: beta, prerelease: true }], plugins: [ semantic-release/commit-analyzer, semantic-release/release-notes-generator, [ semantic-release/npm, { npmPublish: true, pkgRoot: dist/libs/agent-skills/order-status, registry: https://npm.pkg.github.com, tarballDir: dist/libs/agent-skills/order-status } ], [ semantic-release/github, { assets: [ dist/libs/agent-skills/order-status/*.tgz, dist/libs/agent-skills/order-status/README.md ] } ] ] }关键点branchesmain分支发布正式版latesttagbeta分支发布预发布版betatag。order-status这种核心 skill我们用 beta 分支做灰度只有beta版本稳定一周后才 merge 到 main 发布latest。pkgRoot指定发布路径为dist/libs/agent-skills/order-status这是 Nx build 的输出目录。semantic-release/npm会 cd 进去执行npm publish。registry指向 GitHub Packages Registry而非 npmjs.org。因为agent-skills是内部工具链不对外公开。GitHub Packages 支持 fine-grained permissions可以精确控制谁有 publish 权限。assets除了.tgz包还上传README.md。GitHub Release 页面会自动渲染它用户点开 release 就能看到该版本的详细变更说明。4.3 自定义 plugin生成 skill-specific changelog默认的semantic-release/release-notes-generator生成的 changelog 太笼统。我们需要为每个 skill 生成只包含它自身变更的 changelog且格式化为 Markdown 表格方便嵌入文档。我们写了org/semantic-release-skill-changelogplugin// plugins/semantic-release-skill-changelog/index.js module.exports (pluginConfig, context) { const { logger, nextRelease, commits } context; const { pkgRoot } pluginConfig; // 1. 过滤出只影响当前 pkgRoot 的 commits const skillCommits commits.filter(commit { return commit.files.some(file file.startsWith(pkgRoot.replace(dist/, libs/)) ); }); // 2. 生成表格格式 changelog const changelog ## ${nextRelease.version}\n\n| Type | Scope | Subject |\n|------|-------|---------|\n${skillCommits.map(c | ${c.type} | ${c.scope} | ${c.subject} |\n ).join()}; // 3. 写入 dist 目录 fs.writeFileSync( path.join(pkgRoot, CHANGELOG.md), changelog ); logger.log(Generated skill-specific changelog for ${pkgRoot}); };它被集成到.releaserc的 plugins 数组里。效果是dist/libs/agent-skills/order-status/CHANGELOG.md里只有order-status相关的 commit且是表格形式一目了然。注意这个 plugin 必须在semantic-release/npm之前执行因为npm publish会把整个dist/libs/agent-skills/order-status目录打包CHANGELOG.md必须在那时已存在。5. 实战从零构建一个可运行的order-statusskill现在把前面所有理论落地。我们手把手构建一个真实可用的order-statusskill它能调用模拟 API返回结构化订单数据。这不是 demo而是生产环境可直接用的骨架。5.1 初始化 skill 库# 假设 workspace 已存在且已安装 org/agent-skills-plugin nx g org/agent-skills-plugin:skill --nameorder-status --description查询订单状态这会生成libs/ ├── agent-skills/ │ └── order-status/ │ ├── src/ │ │ ├── index.ts # 导出 skill 定义 │ │ └── lib/ │ │ ├── types.ts # SkillDefinition 模板 │ │ └── executor.ts # 执行器实现空 │ ├── jest.config.ts │ ├── tsconfig.lib.json │ └── README.md5.2 完善类型定义编辑libs/agent-skills/order-status/src/lib/types.ts填入前面定义的OrderStatusInput和OrderStatusResult并导出orderStatusSkill// libs/agent-skills/order-status/src/lib/types.ts import { SkillInput, SkillResult, SkillDefinition } from org/agent-skills-core; import { z } from zod; export interface OrderStatusInput { orderNo: string; includeLogistics?: boolean; } export interface OrderStatusResult { order: { no: string; status: created | paid | shipped | delivered | cancelled; amount: number; currency: CNY; }; logistics?: { carrier: string; trackingNo: string; steps: Array{ time: string; status: string; location: string; }; }; } const OrderStatusInputSchema z.object({ orderNo: z.string().regex(/^\d{18}$/), includeLogistics: z.boolean().optional().default(false), }); export type OrderStatusSkillInput SkillInputOrderStatusInput; export type OrderStatusSkillResult SkillResultOrderStatusResult; export const orderStatusSkill: SkillDefinition OrderStatusInput, OrderStatusResult { id: order-status, name: 查询订单状态, description: 根据订单号获取订单当前状态及物流信息, inputSchema: { type: object, properties: { orderNo: { type: string, pattern: ^\\d{18}$ }, includeLogistics: { type: boolean, default: false }, }, required: [orderNo], }, outputSchema: { type: object, properties: { order: { type: object, properties: { no: { type: string }, status: { type: string, enum: [created, paid, shipped, delivered, cancelled] }, amount: { type: integer }, currency: { type: string, enum: [CNY] }, }, required: [no, status, amount, currency],