LM LastMile AI

给企业 IT / AI 平台团队 / FDE / Agent 集成团队

解决企业 AI 落地最后一公里:让企业 API 变成可验收的 Agent 运行能力。

真正卡住的不是模型,而是企业业务系统能不能被 Agent 安全、准确、可审计地调用。 LastMile AI 把 OpenAPI 编译成一个可签收的 Agent 集成交付包: 本体模型、语义接口、执行指令、安全策略、测试 trace。 内置 Agent 验证沙箱 — 上传后几分钟即可通过对话检查语义路由、参数映射和审批策略, 不连接也不调用生产系统。

登录后可上传 OpenAPI 3 JSON,在沙箱中验证并免费下载交付包。

企业 AI 最后一公里 runtime 几分钟验证语义路由与策略 写操作默认人工审批 不连接生产环境

核心问题

企业 AI 落地最容易卡在最后一公里:从 demo 到业务系统的受控执行

企业 API 文档只能说明端点怎么调,却不能证明 Agent 会在正确场景、用正确参数、安全地调用它,也不能让安全、业务和工程团队放心验收。

企业已有的

原始 REST API

  • GET /api/v2/orders?status=pending&page=1
  • 分页参数、错误码、鉴权头
  • 字段名是 cust_idprod_sku
  • Agent 不知道"查询待处理订单"是什么意思
  • 写操作没有安全边界,Agent 可能误删数据
Agent 需要的

业务能力包

  • 本体(Ontology):有哪些业务对象?"订单"有哪些字段?
  • 语义接口(Semantic API):每个操作在业务上做什么?读还是写?
  • 执行指令:Agent 直接用自然语言就能调用的 Skill
  • 安全策略:读操作自动放行,写操作需要人工审批
  • 验证证据:沙箱 trace 检查语义映射和策略路径,不代表客户生产 API 已执行

价值不只是"调通 API"。真正的价值是把企业 API 变成 Agent-ready 的运行资产,并且让业务、安全和工程团队都能验收

第一个关键概念

本体(Ontology)= 你告诉 Agent,企业业务里"有什么"

业务实体
订单 (Order)
idstatustotalAmountcustomerIditemscreatedAt
业务实体
商品 (Product)
skunamepricestockcategory
业务实体
客户 (Customer)
idnameemaillevel

为什么 Agent 需要本体?

企业 API 里有 /orders/{id}/products/customers/{id}/orders。 但 Agent 不知道这些路径代表什么业务对象

本体就是帮 Agent 建立一张"业务地图":业务系统里有哪些实体?订单有哪些字段?商品和订单是什么关系?

没有本体,Agent 只是在猜。有了本体,Agent 是在理解。

每个实体都带 source pointer,能追溯到 API 定义的哪一行 字段信心度标注:高信心自动采纳,低信心提醒你审核

第二个关键概念

语义接口(Semantic API)= 你告诉 Agent,企业业务里"能做什么"

为什么 Agent 需要语义接口?

原始 API 说 POST /api/v2/orders,Agent 不理解"这是创建订单"还是"这只是在记录日志"。

语义接口把每个 API 操作翻译成 Agent 能理解的业务动作

POST /api/v2/orders createOrder 写操作 需审批
GET /api/v2/orders/{id} getOrder 读操作 自动放行
PUT /api/v2/orders/{id}/status updateOrderStatus 写操作 需审批
每个操作标注资源归属(属于哪个业务实体) 自动识别读/写,写操作默认标记"需人工审批" 输出标准 OpenAPI + Agent Skill 双格式
原始 OpenAPI
Ontology
业务对象 & 字段
Semantic API
业务动作 & 约束
Agent Skill
可执行指令

每层都带 source pointer,全程可追溯

交付价值链

从一份 API 文档,到一包可验收的 Agent 证据

1
上传 API 文档 一份 OpenAPI JSON,不连生产环境
2
提取本体 业务实体、字段、关系、信心度
3
审核确认 你确认哪些对、哪些改、哪些加
4
运行验证 根据 API 自动生成的验证场景
5
下载交付包 执行指令 + 安全策略 + 测试 trace + 验证报告

你不是在"写集成代码"。你是在把企业 API 变成可运行、可审计、可验收的 Agent 集成交付物。 能力清单 + 安全策略 + 测试 trace = 交付信任。

你的工作流

接到 Agent POC 或内部 AI 项目后,这样把风险变成证据

1. 上传企业 API 文档

从一份本地 OpenAPI 3 JSON 文件开始。不用部署、不用生产密钥。

2. 系统自动生成能力包初稿

几分钟内生成 Agent 能调用的业务动作、对象字段、安全分类和来源追溯。低信心项会提醒你审核。

3. 你用专业经验审核边界

确认哪些操作适合交给 Agent、哪些写操作必须人工审批,并记录需要修改的字段和业务命名。

4. 输入业务问题,看验证沙箱如何路由

输入“帮用户查最近的订单”,系统展示建议匹配的语义接口、参数映射、审批要求和 mock trace。它用于检查交付设计,不会调用客户生产 API。

5. 生成验证证据 + 安全策略

根据 API 自动生成沙箱测试场景和模拟 trace。写操作默认标注“需人工审批”,安全团队可据此继续审查生产接入边界。

6. 下载交付包,用于验收和移交

一个 zip 包:Agent 操作手册、能力清单、安全策略、验证报告、来源追溯。附带 MCP Server 导出,可接任意 Agent Runtime。

真实交付样例

现场服务 API,生成一张可审查的 Agent 业务运行图

从 OpenAPI 和数据库表结构出发,LastMile AI 把工单、客户、技师、库存、服务合同等业务对象整理成可追溯的本体图,再把字段映射、操作能力和证据链打进同一个交付包。

16业务实体
25Agent 能力
116字段映射
48关系证据
Global Field Service API ontology graph generated by LastMile AI

最终交付什么:

  • Agent 操作手册一份可直接交给 Agent 团队使用的 SKILL.md,不用手写集成指令
  • 能力清单工单调度、技师可用性、客户签收、库存预留、合同查询等 25 个 Agent 可调用动作,每个都标注读/写和业务对象
  • 安全策略读操作自动放行,写操作标注"需要人工审批",含影响范围分析
  • 验证报告围绕现场服务流程生成测试 trace、模拟响应和就绪度评估,可直接用于 POC 复盘
  • 来源追溯每个业务动作、字段、关系和策略都能追到原始 API 或表结构,方便工程团队审查
  • 实体模型工单、客户、技师、服务票据、库存、合同、维护计划 — 帮 Agent 理解业务系统里有什么对象
  • MCP Server 导出manifest.json + tools.json + policy.json,接任何 MCP 兼容框架

上传 OpenAPI 3 JSON,几分钟检查语义路由、参数映射和审批策略。

生成一个交付包

登录后上传,在验证沙箱中检查,并免费下载交付包。