企业官网建设流程全解析

简介：极智嘉CEO郑勇关于机器人改变物流业的深度分享，以一份PDF文档完整呈现，适合智能物流从业者、机器人技术爱好者以及关注自动化趋势的读者阅读。内容以Kiva系统为例，指出其并非传统AGV，而是依托软件算法决策的智能机器人，并系统梳理了郑勇从外企工业机器人工作、资本圈投后管理，到看准物流自动化方向、组建清华技术团队并创立极智嘉Geek+的完整经历。文中还结合2015年双十一在天猫超市仓库的实战落地，说明了“货到人”拣选系统的研发过程与迭代思路，同时客观分析了物流自动化面临的高成本、技术壁垒以及与现有仓储体系整合等挑战。此外，也提及机器学习、深度学习与机器人结合将为物流行业带来更大想象空间。整份PDF共1个文件，大小3.92MB，便于系统阅读和存档；目前已有205人学习，适合用作机器人与物流交叉领域的参考资料。

1. 货到人不止 Kiva：机器人改变物流业的起点

一个技术圈里流传甚广的判断是：“Kiva 只是‘货到人’的一种，机器人将改变物流业。”这句话从 Geek 郑勇的口中说出来，听起来像是行业展望，实际上是给整个物流自动化赛道定了边界：Kiva 解决了“货架到人”的问题，但它不是唯一解，甚至不是所有场景下的最优解。以五年以上从业者的视角去看，影响这个产业走向的并不是某家公司的某一台机器人，而是“货到人”这套逻辑背后的调度算法、存储密度、任务时效与系统柔性。这篇文章会把“货到人”拆开来讲：从 Kiva 的工作原理，到穿梭车、机械臂、潜伏式 AMR 的对比，再到自建系统时真正需要调参、写代码、踩坑的环节。理解了这些，才算看懂郑勇这句话的技术分量。

2. 拆开“货到人”：Kiva 的位置、AMR 变体与拣选策略

2.1 “人到货”和“货到人”，优化目标变在哪里

传统电商仓的拣选模式是“人到货”：拣货员推着拣货车，在巷道里走到货位前，扫码、拿货、再走。这种模式下，行走时间通常占拣选周期的 60% 以上，而且人的行走路线受货架布局限制，很难持续压缩。于是“货到人”把问题反过来——人不动，货物动。拣选工位固定，机器人把货架、料箱或托盘搬运到操作员面前。

从数学上看，这是把“拣选路径优化”问题转化为“搬运任务调度”问题。人到货的路径规划是 NP 难的车队路由问题，而货到人系统中，机器人的调度窗口是可以被打散的：同样一批订单，可以异步分配给多台机器人，再通过工位合并。换句话说，“货到人”真正的优化目标不是缩短人的走动，而是让“货物在途等待时间”与“拣货员空闲时间”同时最小化。

这也是为什么“货到人”会被当作一个系统问题而非单机问题来设计。你选择 Kiva 式货架搬运、穿梭车密集存储，还是料箱机器人，本质上是选择一种“搬运粒度”：是一整个货架被搬过去，还是一个料箱被取出来，甚至是一个个商品被机械臂抓起来搬过去。

2.2 Kiva 的机制：货架搬运不是终点，而是一种密度折中

Kiva 式系统（也叫货架式 AMR）的基本工作流程如下：WMS 下发拣选任务；AMR 接到任务后行驶到指定货架下方，举升整个货架；然后带着货架驶向拣选工位；拣货员在人机交互界面上扫描取货；完成后 AMR 再把货架放回库存区。这套机制的关键指标是“货架命中率”：一个被搬出来的货架，能否覆盖当前订单中足够多、足够快的待拣商品。

货架式方案的好处在于改造成本低、SKU 密度高。机器人不需要知道商品在货架第几层——反正整个货架都搬给你。但代价同样明显：一台机器人一次只能搬运一个货架，而货架重量可能达到几百公斤，机器人必须把很大一部分能耗花在“举升和运输一个并不一定装满需求的货架”上。

从系统设计角度看，Kiva 本质是一种“以搬运换拣选”的折中。它牺牲了机器人单位时间内的搬运效率，换来了人工拣选效率的大幅提升。适合的是大量 SKU、订单波次大、货架命中率高的场景。可如果订单只有几个爆款、SKU 极少，货架搬来搬去反而是浪费。

这里可以给出一个常见参数表，便于把概念落到数字上：

如果你是做技术选型的，第一件事不是比较机器人品牌，而是先算清“我要把什么作为搬运的最小单元”。这是整个方案的分水岭。

2.3 除了 Kiva：穿梭车、机械臂、料箱机器人都是“货到人”

“货到人”远比 Kiva 丰富。穿梭车（Shuttle）系统是另一条重要的技术路线。它运行在货架巷道内的轨道上，可以直接驶向目标货位，把料箱取出来，再通过提升机送到拣选工位。相比 Kiva 的“整架搬运”，穿梭车搬运的是料箱，粒度更细，因此存储密度和单位吞吐量可以更高。但代价是机械结构更复杂，轨道的空间固定性让系统天然不如 Kiva 柔性。

机械臂也正在加入这个故事。六轴机械臂在视觉引导下抓取箱内商品，AGV/AMR 负责把商品送到包装位，形成完整的“货到人”闭环。诸如“机器人终端执行器”和夹具设计会成为这类项目的真实技术瓶颈——你可能用吸盘抓取盒装商品，但要换到袋装零食就可能整套夹具失效。

还有一种被低估的变体是“混合式货到人”：一部分货架由 AMR 搬运，一部分高位密集存储由穿梭车处理，中间用传送带或提升机衔接。这种结构正在取代单一种类的“货到人”。我在实际项目里见过最稳定的配置，是“Kiva 式处理波次中的零散订单 + 穿梭车处理整箱出库”，两种设备共用同一个 WMS 任务池，通过调度层统一分配。

2.4 为什么“一种”这两个字才是重点

如果只把 Kiva 当作标杆，很容易陷入“复制亚马逊仓库”的思维。但郑勇那句话的潜台词是：机器人技术会持续改变物流作业的底层逻辑，但具体形态可以百花齐放。比如不同仓库维度决定了技术路线：

• 楼层仓载荷低，更倾向轻量料箱机器人；
• 高标库层高高，才能塞得下穿梭车匹配的立体货架；
• 冷库场景机器人电池续航衰减快，充电策略比拣选算法更影响效率；
• 门店越铺越密，前置仓面积可能只有几百平方米，这时候一台可原地旋转的差速驱动 AMR 比三台的调度系统更实用。

因此，做物流机器人项目，最重要的是先把“需求形态”翻译成“搬运粒度”，再考虑品牌和算法。这一步本身就筛掉了大量规格很漂亮、项目却很失败的系统。

3. 自建 AMR 系统要把三件事做对：地图、调度和死锁避免

3.1 地图表示：栅格、拓扑与车道地图

无论买成品还是自研，“货到人”AMR 软件的起点都是地图模型。栅格地图适合建图阶段，但对实时路径规划而言计算量偏大。更常用的是拓扑地图：节点代表货位、工位、交叉口，边代表可行路径。如果系统要支持大量双向行驶，还需要加入车道方向属性——只在单向上允许通行的边，或者给路径加边权，比如转弯代价和等待代价。

回到 ROS2 语境下，导航栈离不开 SLAM 建出的栅格地图，但落地时我更建议在 SLAM 地图之上，手工清理一遍，标注出真正的“车道网络”。原因是建图得到的栅格地图往往包含货架底下、墙边等不可达区域，机器人主体可以通行，但货架抬升后可能刮蹭。地图一旦定义不干净，路径规划算法再强也没有用。

常见的做法是对接 VDA 5050 这类标准接口。它定义了 AGV 与调度系统之间的通信消息格式，比如请求任务、报告位置、上报状态。在自研架构中，即使不完整实现 VDA 5050，也建议把路径规划与车辆控制解耦，保持类似接口的语义，这样后期更换车辆品牌时不必重写调度层。

3.2 路径规划：从 A* 到时间窗预留

单机路径规划最稳的选择还是 A*，扩展方式无外乎加权 A*、混合 A* 两轮车辆，以及针对举升 AMR 的“负载/空载”双层代价地图。单机好做，系统难的是多机并发下的路径冲突。

一个直接可行的方法是“时间窗预留”：把每条路段按时间片记录占用，申请路径时检查时间窗是否冲突。比如两车要经过同一个十字路口，系统为 A 车预留 2 到 4 秒、B 车预留 4.5 到 6.5 秒，如果重叠就重新规划。更细化的方案是“预约式 A*”，每个节点在计算代价时，把未来时间占用也纳入估价函数。它的优点是不需要锁路段，缺点是非常吃调度服务器的 CPU。

下面是这类调度逻辑的一个极简 Python 演示，只用列表模拟路段占用和冲突检测，没有接真实的导航栈，但能完整展示调度的核心逻辑：

class RoadSegment: def __init__(self, seg_id, duration): self.id = seg_id self.duration = duration # 通过该路段需要的时间(秒) self.booked = [] # 已预定的(开始,结束)时间窗 def is_free(self, start_time): end_time = start_time + self.duration # 检查是否与现有时间窗重叠 for (s, e) in self.booked: if max(start_time, s) < min(end_time, e): return False return True def book(self, start_time): self.booked.append((start_time, start_time + self.duration)) class FleetScheduler: def __init__(self, segments): self.segments = segments # 字典: 路段id -> RoadSegment def plan_path(self, path_edges, request_time, robot_id): # 依次为每段路段预约时间窗 t = request_time for seg_id in path_edges: seg = self.segments[seg_id] if not seg.is_free(t): # 冲突，顺延时间 t = seg.booked[-1][1] + 0.5 if not seg.is_free(t): return False, f"robot {robot_id} cannot reserve {seg_id}" seg.book(t) return True, f"robot {robot_id} planned at {t}"

这里is_free检查区间是否重叠，book写入占用区间。真实系统里还需要区分路径方向的单向边，以及把每个路段的预留信息按时间戳定期清理，否则运行几小时后的内存占用会不断膨胀。调度参数上，值得手动控制两个值：最小跟车距离和最小预留间隔。前者决定物理安全，后者决定系统吞吐。间隔设大了车等得久，设小了死锁概率会急剧上升。

3.3 车队级死锁控制：先分仓再调度

多台 AMR 在货架巷道里相遇是很常见的事。如果路径规划全部交给全局调度器，容易出现“互相等待”的环状死锁：A 车要进巷道，B 车堵在巷道口，而 B 车要去的方向又被 C 车堵住，C 车正等着 A 车让路。越是高密度存储区越容易触发。

业界常用的策略有三种，按实现成本递增排列：

• 区域准入控制：把仓库地图划分成分区，设定最大车辆数。每个分区有独立信号量，车进入前必须先申请配额。
• 单向巷道：把窄巷道全部改成单行线，从根上消灭对向冲突。这是最简单也最有效的操作，但会拉长绕行距离。
• 资源锁与优先级回退：对每个交叉口、货架位位置等关键资源设读写锁，低优先级车辆看到资源被占用时，自动回退到最近的避让点。

我一般建议把三种混用：主干道双向 + 巷道单向 + 分区配额 + 关键点资源锁。这套组合在中等规模仓库里足够稳定，也不需要上强化学习。

3.4 计算资源配置与关键参数表

对于总车辆数 50 台以内的系统，调度服务器只需要 8 核 16 GB 的普通服务器，瓶颈一般不在 CPU，而在消息中间件的延迟与可靠性。如果使用 ROS2，注意把rmw_fastrtps的双向通信超时参数调大一点；物流现场 Wi-Fi 波动很容易触发节点“失联”日志刷屏，但那并不代表车辆真的失联。

系统设计时应留出的基础参数建议直接固化在配置中心里：

这套参数并不是固定的，但它能保证系统在早期铺量时不至于在物理安全上翻车。真正要调的是“任务下发提前量”：WMS 一旦产生拣选任务，调度器可以不等机器人空闲就直接分配给某台车，让车辆在执行完当前任务后立刻进入下一任务，中间不产生空窗。

4. 吞吐量怎么算、机器人怎么配：从 Kiva 经验到替代方案

4.1 用循环时间公式估算机器人数量

机器人数量是“货到人”项目里第一个被老板问、第一个被销售糊弄的数字。用经验值估算其实是可行的：单台机器人循环时间 = 空载驶向货架时间 + 举升时间 + 负载驶向工位时间 + 放下时间 + 返回时间。把这几个时间拆开，单位都是秒。

假设仓库平均搬运距离是 45 米，机器人空载速度 2 m/s、负载速度 1.8 m/s，举升和放下各 5 秒，那么一个循环大约 45/2 + 45/1.8 + 5 + 5 = 55 秒。每小时产能约为 65 次循环。如果实际系统的任务目标是每小时拣选 500 个订单且平均每单需要 4 次搬运，那么需要的搬运次数是 2000 次/小时，机器人数至少是 2000/65 ≈ 31 台。

这个初步计算忽略了充电、交通堵塞和任务分配不均衡。一种更稳妥的做法是乘上一个 1.3 到 1.5 的修正系数，得出实际要部署 40~45 台。用一段简短的 Python 代码可以快速改变输入参数看结果：

def estimate_amr(distance_m, v_empty, v_loaded, lift_time, tasks_per_hour): empty_time = distance_m / v_empty loaded_time = distance_m / v_loaded cycle_time = empty_time + loaded_time + 2 * lift_time cycles_per_hour_per_amr = 3600 / cycle_time required_cycles = tasks_per_hour amr_count = required_cycles / cycles_per_hour_per_amr return cycle_time, amr_count * 1.4 # 加入1.4倍裕量 # 常见参数下：45米平均距离，2m/s空载，1.8m/s负载，每次举升5秒 time, count = estimate_amr(45, 2.0, 1.8, 5, 2000) print(f"单车循环时间: {time:.1f} 秒，需要机器人: {math.ceil(count)} 台")

这里的核心逻辑是先把业务侧的需求转换成“每小时搬运次数”，再反推车辆数。多数选型失败都发生在这步之前：业务需求还是模糊的“每天处理几万单”，没有折算成峰值小时的搬运次数。峰值小时系数通常取 1.5，否则按日均算出来的机器人数量在促销高峰期必然瘫痪。

4.2 不同“货到人”方案的成本结构比较

机器人数量只是其中一个变量。Kiva 式货到人的投资大头在机器人、货架、充电桩、调度软件和与 WMS 的接口开发。穿梭车系统则要把大量成本花在定制钢平台、轨道和提升机。机械臂拣选看起来“机器人感”最强，但终端执行器和视觉调试的边际成本往往比车体更贵。

做技术决策时建议把三年五年总成本拆成四块：设备折旧、安装施工、软件集成、运维人员。Kiva 式的运维人员需求最低，因为货架和机器人本体都属于通用设备；穿梭车系统一旦巷道卡料箱，需要有经验的机械背景人员；机械臂视觉误抓之后，要花在重新标定上的时间通常被严重低估。

如果仓库面积小于 5000 平方米，SKU 数量又少，更合适的方案甚至算不上“货到人”——直接调整货架布局、用播种式拣选就够了。强行上机器人系统只会让单位成本难看得多。

4.3 一个不被注意的效率漏洞：任务波次拆分

项目上线三个月后，吞吐量通常会稳定在某个值，这时优化重点会转向两类工作：一是 WMS 里的波次策略，二是调度器里的订单优先权。两者紧密相关。

一个我只能在这里提醒的坑是“机器人同名任务重复搬运”。当同一波次中，订单 A 和订单 B 都需要来自同一货架的商品时，如果 WMS 没有把这两个拣选任务合并成同一个“货架访问任务”，系统就会让机器人把那台货架搬两次。很多小型团队在自研调度器时，容易忽略这个订单聚合模块。

解决办法是在 WMS 下发任务前，对所有待处理订单做一个商品-货架映射的聚类。把需要同一个货架的订单绑定在一起，生成一个“货架任务”，等货架到达工位后，由拣选界面依次处理多个订单。

5. 什么才是真正改变物流业：用现场数据校准仿真的技巧

现在回到开头的判断：“机器人将改变物流业。”这句判断不是口号，而是可以在日常工作中验证的工程任务。真正的技巧在于：不断用现场数据校准系统模型，让机器人集群的吞吐量预测与真实数据误差控制在 5% 以内。我常用的验证方法是 FIFO 数据回放：从 WMS 导出最近两周的订单明细，包括下单时间、商品所在货架、拣选完成时间，然后把这些订单塞进离散事件仿真脚本里去跑。

仿真脚本里不需要重建完整仓库三维模型，只需要保留三样数据：订单-货架映射、每个货架到工位的距离矩阵、机器人的循环时间分布。把真实系统里的任务时长、等待时长作为随机变量输入，通过仿真看瓶颈是否落在拣选工位或充电排队上。

一个简单的做法是把 WMS 的拣选流水导成 CSV，用 SQL 做初步分析，看看拣选间隔是否符合泊松分布假设。如果频繁出现“同一时刻堆积十个任务、下一秒任务为空”的尖峰流量，这意味着调度器的负载模型不能简单按均值估算，而要考虑排队论里的 M/D/1 或 M/M/c 队列。此时需要调整的不一定是机器人数量，而是任务下发节流，让分配曲线更平滑。

具体操作上，可以在调度器里增加一个标准化的指标：拣选工位利用率 = 工位人工拣选时间 / (工位空闲时间 + 人工拣选时间 + 等待机器人时间)。当等待机器人时间占比超过 20%，说明任务下达不够早；当工位空闲时间超过 30%，说明机器人任务池深度不足。盯住这个指标去调，远比看一份日报有价值。

技术的推进不会停在某一台车或某一座仓库里。既然“货到人”已经长出了 Kiva 之外的好几条分支，下一步就会从“机器人搬运”走向“机器人决策”：让机器人自己根据实时订单压力和自身电量调整任务优先级，把充电时机与订单波谷预测绑在一起。把这条验证闭环跑通，才是工程师真正参与改变物流业的地方。

本文还有配套的精品资源，点击获取