最近行业里有一条很有意思的消息Anthropic 被报道将在一个时间窗口内把“AI 运营”落到三种实体场景里——自动售货机、门店和咖啡馆。也就是说AI 不只是聊天窗口里的一个对话对象也不只是帮你补全代码的插件而是要直接参与卖货、出餐、补货、对账这类真实世界的零售环节。单看这件事很多人会把它当成一条科技新闻划过去。但我更建议把这条消息当成一个信号来读AI 正在从纯数字领域往物理世界迁移。这个迁移的难度比大多数人想象的要大得多而这批项目最终能不能跑通关键也不在模型聪明不聪明而在于工程系统能不能兜住物理世界的不确定性。所以这篇文章不打算复述新闻而是想拆一拆为什么自动售货机会成为第一个落点AI 运营一家店到底要过哪几关真正卡住这类项目的瓶颈在哪以及普通开发者能从这里面迁移出哪些能力。1. 先别急着讨论“取代店员”这次真正的变化是 AI 从屏幕走向物理世界1.1 过去几年 AI 做的事大多停留在“数字世界”过去两年里我们看到的大模型应用无论写作、绘图、编程、客服还是 Agent 自动操作浏览器本质上都在处理数字信息输入是文本、图片、代码、网页输出也是文本、图片、代码和点击动作。即使出了问题最坏的结果也就是生成一段错误文本或者一次失败的 API 调用重新跑一次就行。这种环境对 AI 非常友好。因为它的错误代价很低重试成本也低而且整个流程可以随时被中断、回滚、覆盖。模型哪怕在某个环节上抽风了只要把上下文纠正过来或者重新请求一次多半就能继续。但实体零售完全不同。顾客在店里打翻了一杯咖啡货架上的商品被人挪到错误位置冷藏柜的温控设备突然离线有人买完东西发现扫码没成功——这些问题一旦发生你不能简单地“重试”。它们需要有人到现场处理需要物理干预需要系统在异常状态下仍然给出一个不至于让顾客白等、不至于让账目出错的兜底方案。1.2 从“对话”到“行动”本质是必须形成闭环如果你把 AI 运营店铺拆开看会发现它不再只是“模型回答问题”这回事而是一条完整的链路先要感知现场发生了什么再要基于当前状态做决策然后要驱动硬件完成一个动作最后还要检查这个动作是否真的生效。四个环节缺一不可。这里最关键的词是“闭环”。ChatGPT 这类产品只需要输出内容一个 AI 运营的自动售货机却必须确认“用户付款后商品确实掉下来了”。如果没有闭环验证模型决策得再合理也无法保证现实结果是对的。而这恰恰是从软件 AI 到实体 AI 最本质的跨越系统必须学会处理“动作已执行但结果未知”的状态。不少做过 IoT 项目或者无人售货项目的朋友应该有同感大部分技术难点并不在“识别”和“决策”而在“确认”和“恢复”。这也是我看好这类项目的原因——它不是在模型层做文章而是把整套软件工程方法重新应用到物理空间里。2. 为什么第一个落点是自动售货机而不是全无人超市2.1 自动售货机是一个天然的“受限环境”从公开报道的方向来看自动售货机、门店、咖啡馆是放在一起说的。但如果你去分析落地难度会发现三者完全不在一个量级上。第一个适合落地的必然是自动售货机。原因很简单售货机的工作空间是封闭的。商品种类有限货道位置固定交易流程标准化顾客与机器的交互也被限定在“选货、付款、取货”这条极短的路径里。状态空间小异常类型少安全要求低——哪怕 AI 判断失误最坏的结果就是商品掉错了或没掉下来不会涉及人身安全、食品安全这样高敏的问题。这就像一个机器人先在一个没有障碍物的围栏里练习走路而不是直接丢进早高峰地铁站。它不是“更简单”而是“边界更清楚”。对一个需要验证技术可行性的团队来说这是成本最低、信息最完整的实验场。2.2 咖啡馆和门店是同一能力阶梯上的不同难度从售货机到咖啡馆再到门店难度不是线性上升而是指数级上升。我用一个表格把它们的差异列出来维度自动售货机AI 咖啡馆AI 门店商品状态封闭货道位置固定配方可变物料易损货架开放顾客可触碰交互流程选货、付款、取货点单、制作、交付找货、咨询、试穿、结账、退换异常类型少量机械故障缺料、打翻、设备故障、口味投诉商品错位、库存不一致、卫生问题、纠纷安全要求较低食品卫生、设备安全人身安全、消防、食品安全人工介入频率低通常每日盘货中每班可能需要多次介入高且不可完全预测模型感知难度摄像头 传感器即可需要识别杯量、拉花、操作时序需要理解顾客意图、现场动态变化从这张表能看出一件事自动售货机的本质是“有限状态机 交易闭环”咖啡馆和门店则更像“开放世界 长尾服务”。模型可能在一个封闭环境里表现很好但一旦把它放到开放环境性能会快速衰减。这也是为什么很多无人零售项目最后都退化成“有人值守的无人店”——技术能处理 90% 的常规流程但剩下的 10% 异常仍然需要人。所以我对这条新闻的理解是Anthropic 的这个计划本质上是在同一个 AI 底座上逐步挑战越来越复杂的物理环境。售货机是最小可行场景咖啡馆是压力测试门店才是最终要证明的命题。3. 拆开一台“AI 运营的商店”四个技术层缺一不可3.1 感知层把现场变成结构化事件AI 要运营一个实体空间第一步不是“思考”而是“看见”。这里包括摄像头视觉识别、语音交互、传感器数据、IoT 设备状态等。感知层的目标是把物理世界的连续画面变成结构化的事件流。举个例子一位顾客站在售货机前系统需要知道“有人来了”“他停在哪台设备前”“他看了哪些商品”“他是否付款”“他是否取走了商品”。这些信息不能靠一段自然语言描述而必须变成可供决策系统处理的状态字段。比如customer_present: true、payment_status: paid、delivery_status: pending。这里最容易踩的坑是感知覆盖不全。很多项目只装一个摄像头一旦角度被遮挡或者光线变化感知就中断。工程经验里多模态感知和冗余校验几乎是必须的视觉识别结果最好能和传感器数据互相印证语音交互失败时要能退化成触屏操作。感知层不是追求“最高精度”而是追求“每个关键状态至少能被一种方式确认”。3.2 决策层模型在有限上下文里做选择感知完成之后决策层要回答“接下来做什么”。这里是大型语言模型和 Agent 框架进入的地方。系统会基于当前状态、历史事件、库存数据和用户请求生成下一步动作比如“确认订单”“启动出货”“通知补货”。但决策层有一个容易被高估的问题它需要的是“可靠的选择”而不是“惊艳的回答”。在实体运营场景里模型的创造力是次要的稳定性和可预测性才是核心。同一个状态系统今天返回动作 A明天返回动作 B这在对话产品里可能无伤大雅在门店运营里却会直接造成混乱。所以在落地实践里我通常建议把决策层设计成“规则兜底 模型增强”的组合。常规流程用确定性规则处理模型只负责那些规则难以覆盖的开放场景。这样既能享受模型的灵活性又不至于让系统行为变得不可预期。3.3 执行层硬件接口和动作反馈决策完之后系统要真的去执行一个物理动作。对售货机来说是控制电机旋转货道对咖啡机来说是控制磨豆、注水、奶泡的时序对门店来说可能是通知一个移动机器人去整理货架或者打开门店的智能门锁。执行层最需要关注的问题是“动作反馈”。电机转动之后商品到底有没有掉下来机械臂夹取之后货品到底有没有被稳定拿起这些都不能靠推算必须通过传感器、重力感应、视觉确认等方式回读状态。这也是“闭环”落地的关键一步每一个动作都要有确认没有确认的动作必须进入异常流程。3.4 异常层真正决定系统能不能长期运行的部分感知、决策、执行三层组成了正常的业务链路。但一个能长期运营的系统真正比拼的是第四层——异常处理。我见过不少项目演示时一切正常一放到真实环境就崩。原因非常统一正常流程跑得通但一旦出现“视频识别返回超时”“货道卡住”“用户重复扫码”“设备离线”这些高频异常系统就不知道该怎么办了。设计异常层时要提前想清楚三件事这个异常能不能自动恢复如果不能自动恢复要降级成什么模式什么情况下必须请求人工介入一个可用的系统不是永远不出错而是出错时能用最短路径恢复到安全状态。注意实体 AI 项目里的错误处理逻辑应该比正常业务逻辑更早开始设计。因为正常流程只有一条路异常流程可能有几十条路。4. 真正卡住这类项目的不是模型而是异常处理4.1 物理世界的问题长尾远远超出现有数据集为什么很多 AI 实体项目停留在演示阶段因为开发团队往往从“正常流程”出发而不是从“问题分布”出发。在软件世界里一个函数输入的异常组合也是有限的你写十个 if 分支就能覆盖绝大部分情况。在物理世界里异常的组合几乎是无限的商品被顾客放到另一个货架、咖啡杯上有水渍导致视觉识别失败、某台设备固件半夜自动重启、天气导致网络延迟升高。每一个问题单独看都很小但叠加在一起就是一张极其庞大的长尾清单。模型再聪明也不可能凭空知道所有这些异常应该怎么处理。它需要数据需要现场日志需要足够多的真实运营案例来学习。这也是为什么这类项目必须“先跑起来再积累数据”而不是“等模型成熟了再上线”。4.2 从工程经验看核心指标是“人工介入率”判断一个 AI 实体运营项目是否健康我建议不要只看演示视频里的顺利流程而要看一个数字人工介入率。也就是在一定时间内系统运行中需要人类远程或现场介入的次数占比。比如一家 AI 咖啡馆如果每 50 单需要人工介入 1 次介入率是 2%。如果每 5 单就需要介入 1 次那这个系统其实还不具备独立运营的能力。人工介入率决定了人力成本也直接决定这种模式在经济上是否成立。这里有一个容易误判的点人工介入率不是越低越好而是要结合“介入质量”来看。有些系统看似介入率很低但一旦介入就需要专业人员到场处理半小时有些系统介入率稍高但每次介入只需远程确认一下五分钟内解决。后者的运营体验往往优于前者。所以在做监控和复盘时要把“介入次数”和“平均恢复时间”两个指标一起看。4.3 设计原则先降级再升级先安全再效率在异常处理里我建议遵循两条原则。第一条先降级再升级。系统遇到不确定状态时不要贸然尝试高风险操作。比如视觉识别无法确认商品是否掉落这时不要立刻再次启动电机而应该先暂停交易提示用户联系工作人员同时把这个异常上报。宁可让这一单失败也不要让系统在未知状态下反复尝试造成更大的混乱。第二条先安全再效率。在实体场景里安全永远是第一优先级。如果系统存在任何可能造成人身伤害、设备损坏或食品污染的隐患必须立即停止相关操作。效率优化要建立在“不会导致失控”的前提下进行。这两条原则看着简单但很多翻车的项目恰恰是反着做的为了追求低介入率让系统在不确定状态下一再重试结果把一个小异常变成了大故障。5. 普通开发者能从这类项目迁移什么能力5.1 Agent 工程不只是提示词更是一套流程设计如果你不打算做实体零售这类项目里依然有大量可迁移的经验。最直接的是 Agent 工程。很多人一提到 Agent第一反应就是写提示词。但真正到一个复杂场景里你会发现提示词只是很小一部分。更关键的是你怎么定义 Agent 的状态你怎么让它和外部系统交互你如何确认它执行的动作真的有效你如何让它在出错时不乱跑这些问题和 AI 运营售货机要解决的问题完全一致。你可以把实体项目里“感知-决策-执行-异常”的四层结构迁移到任何 Agent 应用里输入解析、上下文组织、工具调用、结果校验、异常兜底。这套框架比单纯优化提示词要可靠得多。5.2 可观测性给 AI 系统加日志、追踪和监控另一个可迁移的能力是可观测性。在对话产品里模型输出一段文本你很难判断它“是不是在想”或“有没有按预期推理”。但在实体运营系统里每一步都必须留下日志当前状态是什么、模型输出了什么决策、执行机构返回了什么结果、是否触发异常流。这种设计习惯放到软件 Agent 开发里同样重要。你需要在每个关键节点记录输入、输出、耗时和异常才能在系统表现不佳时快速定位问题。很多 Agent 项目跑着跑着就废了不是因为模型变笨了而是因为缺少监控开发者根本不知道它在什么状态下开始出错。5.3 评估集用“回放”代替“猜”实体 AI 项目里还有一个重要方法叫“场景回放”。把真实运营中记录下来的异常事件和用户交互整理成数据集用来反复测试新版系统。每次模型升级或规则调整都要先在历史数据上回放一遍确认不会引入新的回归问题。这个方法同样适用于普通开发场景。你可以把线上真实请求收集下来搭建一个离线评估集。任何提示词修改或代码调整都先在评估集上跑一遍而不是直接在线上改靠运气验证效果。有了评估集你就有了对系统行为做回归测试的基础设施。5.4 从小场景试错再横向扩展最后一个迁移能力是渐进式落地。Anthropic 选择自动售货机作为起点本质上是选择一个“边界清晰、风险可控、反馈充分”的小场景先把整套系统闭环跑通再逐步增加复杂度。普通人做 AI 应用也应该这样。不要一上来就想做一个覆盖十个场景的“超级 Agent”。先选择一个小而具体的任务比如“自动整理指定文件夹的文档”“自动回复日常邮件”把感知、决策、执行和异常处理都跑通再横向复制到其他场景。6. 怎么判断一个“AI 实体运营”是真运营还是演示6.1 先问一个隐藏问题演示之外系统经历过多少真实营业时间在 AI 实体项目里有一个特别容易被忽略的信息系统的真实营业时长。一个在展厅里每天运行 2 小时、由工程师全程盯着的系统和每天营业 14 小时、连续运行三个月的系统根本不是一个量级的产品。所以看到任何 AI 运营店铺的消息我建议你先去找一个信息它有没有披露真实运营时长和累计服务单量。如果只有演示视频和一个 APP没有运营数据那它更接近“技术验证”而不是“产品运营”。6.2 检查三个关键指标指标演示型项目真实运营型项目人工介入率不披露或宣称接近 0会给出真实数字且能看到下降趋势异常恢复时间没有记录有时间统计并有明确的升级路径故障演练没有或很少有定期演练有复盘报告现场长尾问题几乎没有记录有详细的问题日志和补丁记录连续运行时长演示期间才运行有持续数周以上的稳定运行数据如果上面表格里大部分指标都属于左列那这个项目无论视频多炫酷都更适合当作“研究项目”来看。真实运营的数据是最难作假的因为现场不会配合你的系统表演。6.3 一个可复用的判断框架我把判断一个 AI 实体项目是否成熟的方法总结成一个“三层检查法”第一层看运行层它是否在真实环境里连续运行过足够长的时间中间是否经历过完整的营业周期比如从早高峰到打烊第二层看异常层它有没有完整的异常日志异常发生时系统是自动恢复、降级处理还是直接崩溃人工介入的频率和时长有没有记录第三层看演进层它的运营数据是不是在变好比如介入率有没有下降、恢复时间有没有缩短、单店产能有没有提升。如果数据几个月都不变说明这个系统没有真正从运营中学习只是一套固定流程的演示版。这套三层检查法不仅适用于评价别人家的项目也适合用来审视自己的 AI 应用。你可以问自己我的系统连续跑过多久出了问题日志能帮我定位到具体环节吗各项指标是不是在持续改善想清楚这三个问题你对项目的成熟度会有更清醒的判断。7. 适用边界它适合什么场景不适合什么场景7.1 适合的场景AI 实体运营最适合的场景通常有这几个特征流程标准化、状态可观测、异常影响可控、人工介入通道明确。像自动售货机、限定菜单的无人咖啡亭、标准化的便利店补货流程都符合这些条件。在这些场景里AI 的价值不是“彻底替代人”而是把大量重复、标准化、低决策成本的工作自动完成让人只处理真正需要判断和现场能力的问题。这套逻辑同样适用于任何软件系统可以自动化的部分自动化不能自动化的部分做好升级通道。7.2 不适合的场景相反以下场景不太适合直接套用 AI 运营高创意性、高情感交互、强社交属性的服务以及安全标准极高、出错代价极大的领域。比如需要理疗师现场判断的康复服务、需要心理咨询师理解和共情的对话场景或者任何涉及人身安全的高风险操作。这不是说 AI 在这些领域完全没用而是说它更适合作为辅助工具而不是独立运营主体。把 AI 放在辅助位置提供信息整理、决策建议、流程提醒会比让它独立运营安全得多。7.3 给想跟进的团队的建议如果你所在团队也有类似计划——不管是要做 AI 实体零售还是要做一个复杂的 Agent 应用我的建议都是一样的先做一个“最小物理闭环”。不要一开始就规划一整套门店系统。先选一个具体的、边界清晰的单点场景比如“一台自动售货机的远程故障诊断系统”或者“一个能自动确认货道并生成补货清单的模块”。把它做成端到端可用的产品有输入、有输出、有日志、有异常处理、有人工介入通道。然后再把同样的能力复制到下一个场景。提醒一下这类项目里最容易被低估的是数据积累的周期。模型和代码可以快速迭代但真实运营日志、异常案例、用户反馈只能靠时间堆出来。所以越早开始真实场景的试运行越好不要等系统“完美”了再上线。写在结尾AI 运营实体本质是让物理流程变得可复用回到文章开头那条消息。Anthropic 把 AI 放进自动售货机、门店和咖啡馆这件事最值得关注的不是模型又多了一项技能而是它代表了一种方向把物理世界里不确定、依赖个人经验、难以标准化的零售服务逐步变成一套可观测、可回滚、可复用的工程流程。这件事能不能在一年内真正跑通现在下结论都太早。但有一个判断我可以给出来无论这个项目最终的数据如何AI 从屏幕走向物理世界的大方向已经非常明确了。对做技术的我们来说与其等着看别人的结果不如提前把“感知-决策-执行-异常”这套思维框架用在自己手头的项目里。下次再看到任何“AI 运营某实体”的新闻别只看“AI”两个字。先问三个问题它连续运营了多久人工介入率是多少异常恢复需要多长时间这三个问题通常能帮你分辨一个项目到底是产品还是演示。而这三个问题的答案也恰恰是决定 AI 能不能真正走进物理世界的那道门槛。