1. 为什么要在电商系统里聊 AI Native电商系统这个赛道过去十年基本是“堆功能”的玩法商品、订单、库存、营销、履约、售后每个模块都往深了做最后做成一个庞大的中台。但真正在一线待过的人都知道这套东西的维护成本高得离谱需求响应慢运营想改个促销规则都得排期两周。我去年接手一个中型电商项目的时候光是把“满减叠加优惠券再叠加会员折扣”这条链路讲清楚就花了整整一个下午。AI Native 这个词最近被聊得很多但落到电商业务系统上它不是一个“加个智能客服”的伪需求而是把 Agent 作为系统的一等公民来重新设计。核心变化在于以前是“人操作界面界面调接口接口改数据”现在是“人给目标Agent 拆任务Agent 调工具Agent 校验结果”。Anthropic 在 Agent 工程上的一些实践思路尤其是围绕 Claude Code 这类工具链形成的研发范式给了我很多启发。这篇文章我想聊的不是概念而是我实际动手做的一套东西用 AI Native 的思路把电商系统里几个高频、高重复、高规则密度的场景改造成 Agent 驱动的形态。适合谁看如果你是有一定后端或全栈基础正在琢磨怎么把 Agent 真正塞进业务系统而不是停留在 demo 阶段的人这篇应该能给你一些能直接抄的作业。如果你只是想了解 Agent 是什么也可以看但我会讲得比较干。先说清楚一个前提我这里说的 AI Native 电商系统不是把整个电商系统推倒重来那不现实。我的做法是选几个“规则明确、输入输出可结构化、人工介入频繁”的模块先做 Agent 化跑通之后再逐步扩展。这个思路后面会展开讲。2. 整体架构设计与技术选型思路2.1 为什么选 Agent 而不是传统工作流很多人一提到“智能化”第一反应是写一堆 if-else 加规则引擎或者搞个工作流引擎把步骤串起来。我一开始也这么想过但很快发现两个问题。第一电商业务里的规则是“活”的。今天满 300 减 50明天可能变成“满 3 件打 8 折且不与会员价叠加”后天运营又想在售后场景里加一条“超过 48 小时未发货自动补偿 5 元券”。你用工作流去画画到最后就是一张蜘蛛网改一个节点要重新测一整条链路。第二很多场景的输入是非结构化的。比如用户投诉“我买的衣服颜色和图片不一样”这句话里包含了订单号缺失、问题类型模糊、情绪判断等多个维度传统规则引擎处理起来很吃力。Agent 的优势在于它不需要你穷举所有分支而是给它工具和约束让它自己决定调用顺序。这就像你带一个新人你不会把每种情况都写成手册而是告诉他“你有这些权限遇到问题先查订单再查物流最后给方案”。2.2 技术栈的取舍Claude Code 带来的启发我最终选的技术栈是围绕 Claude 系列模型构建的 Agent 层工具调用走标准的 function calling 协议编排层没有用特别重的框架而是自己写了一个轻量的调度器。为什么不用现成的 Agent 框架我试过几个要么抽象层太厚导致调试困难要么对工具描述的支持不够灵活。Claude Code 这个工具给我的最大启发不是它本身怎么用而是它展示了一种“Agent 与终端环境交互”的范式Agent 可以读写文件、执行命令、查看结果、根据结果决定下一步。这套逻辑平移到电商系统里就是把“文件系统”换成“业务 API”把“终端命令”换成“业务操作”。具体来说我的 Agent 层包含四个核心组件意图解析器把用户输入或系统事件转成结构化意图工具注册中心管理所有可被 Agent 调用的业务能力每个工具都有清晰的描述和参数 schema执行调度器负责多轮工具调用的编排、超时控制、重试和回滚结果校验器对 Agent 的输出做格式校验和业务规则校验不通过就打回重做这个架构的好处是每个组件都可以独立测试和替换。比如我后来把意图解析器从纯 prompt 方案换成了“小模型分类 大模型兜底”的混合方案其他部分完全不用动。2.3 电商场景的 Agent 化边界划定不是所有模块都适合 Agent 化。我给自己定了几条筛选标准筛选维度适合 Agent 化不适合 Agent 化规则复杂度规则多且经常变规则极少且稳定输入形态自然语言、多模态纯结构化表单容错空间可校验、可回滚涉及资金且不可逆人工介入频率高频重复低频一次性响应时效秒级到分钟级毫秒级强一致按这个标准我第一批选了三个场景售前咨询与导购、售后工单处理、商品信息补全。这三个场景的共同点是规则多、输入杂、人工处理耗时、出错后可以补救。库存扣减、支付回调这些我坚决没让 Agent 碰原因很简单这些操作要求强一致性和毫秒级响应Agent 的推理延迟和不确定性在这里是致命伤。我的做法是让 Agent 生成“操作建议”由确定性的代码去执行最终扣减。3. 核心模块的 Agent 实现细节3.1 售前导购 Agent 的工具设计售前导购是我做的第一个模块也是最容易看到效果的。传统做法是关键词匹配加人工客服用户问“有没有适合夏天穿的透气跑鞋”系统只能匹配“跑鞋”这个关键词然后甩出一堆列表。Agent 化的做法是给 Agent 配一组工具让它自己去查。我注册的工具包括search_products(keyword, category, price_range, tags)商品搜索get_product_detail(product_id)获取商品详情check_inventory(product_id, sku_id)查库存get_user_profile(user_id)获取用户历史偏好apply_coupon(coupon_code, order_amount)试算优惠关键在于工具描述要写得足够清楚。我踩过一个坑一开始search_products的描述只写了“搜索商品”结果 Agent 经常传一些奇怪的参数组合。后来我把描述改成“根据关键词、类目、价格区间和标签搜索商品返回匹配的商品列表每个商品包含 id、名称、价格、库存状态和标签”Agent 的调用准确率明显提升。还有一个细节工具返回结果要控制长度。商品列表如果一次返回 50 条Agent 的上下文会被撑爆。我的做法是默认返回 10 条并在返回里带上total_count让 Agent 知道还有更多结果需要时可以翻页。3.2 售后工单 Agent 的状态机设计售后场景比售前复杂得多因为涉及状态流转。用户说“我要退货”Agent 需要判断订单是否在退货期内、商品是否属于可退类目、是否已经拆封、退款金额怎么算。我没有让 Agent 自由发挥而是给它画了一个隐式的状态机。Agent 的每一轮工具调用都会改变当前状态状态机负责校验“这个状态下能不能做这个操作”。举个例子用户发起退货Agent 先调get_order(order_id)拿到订单详情调check_return_policy(order_id, reason)判断是否符合退货政策如果符合调create_return_request(order_id, reason)创建退货单调calculate_refund(order_id)计算退款金额最后调notify_user(user_id, message)通知用户这个流程里第 3 步和第 4 步的顺序不能反因为退款金额依赖退货单的创建结果。我在调度器里加了一个简单的依赖检查每个工具可以声明requires字段调度器在执行前检查前置条件是否满足。注意状态机的校验逻辑一定要放在代码里不要指望 prompt 能约束住 Agent。我试过纯靠 prompt 描述状态流转结果 Agent 在压力测试时出现了“先退款再创建退货单”的骚操作。3.3 商品信息补全 Agent 的批处理模式商品信息补全是另一个高频场景。运营上传商品时经常只填了名称和价格类目、属性、卖点描述都是空的。传统做法是人工一个个补效率极低。我做的 Agent 会读取商品名称和图片然后调classify_product(name, image_url)预测类目调extract_attributes(name, image_url)抽取属性颜色、材质、尺寸等调generate_selling_points(name, attributes)生成卖点文案调validate_attributes(category, attributes)校验属性是否符合类目规范这个场景的特点是批量处理所以我用了队列加并发控制。每个商品是一个独立任务Agent 处理完一个再处理下一个。并发数控制在 5 左右太高了会触发模型侧的限流太低了吞吐上不去。实测下来一个熟练运营补全一个商品平均需要 3 到 5 分钟Agent 处理一个商品平均 12 秒准确率在 85% 左右。剩下的 15% 需要人工复核但整体效率提升还是很明显的。4. 实操过程中的关键环节与参数调优4.1 工具调用的超时与重试策略Agent 调用工具不是每次都成功。网络抖动、下游服务超时、参数校验失败这些都会发生。我一开始没做超时控制结果一个卡住的工具调用把整个 Agent 会话拖死了。后来我加了三层保护单次工具调用超时默认 10 秒超过就中断并返回错误信息给 Agent单轮会话超时默认 60 秒超过就终止整个会话并记录日志重试策略只对幂等操作重试最多重试 2 次重试间隔用指数退避这里有个细节重试的时候要把错误信息一起传给 Agent让它知道上次为什么失败。比如“库存查询超时”和“商品不存在”是两种完全不同的错误Agent 的处理策略也应该不同。4.2 上下文管理与 token 消耗控制Agent 的上下文是有限资源电商场景里多轮对话很容易把上下文撑满。我的做法是工具返回结果做摘要只保留关键字段历史对话超过 10 轮后把早期对话压缩成摘要系统 prompt 里明确告诉 Agent“如果信息不足优先调用工具查询不要猜测”token 消耗方面我统计过一组数据售前导购场景平均每轮对话消耗 2000 到 4000 token售后工单场景平均 3000 到 6000 token。按当时的模型定价单次会话成本在几分钱到一毛钱之间。这个成本相比人工客服是很有优势的但前提是你要控制住无效调用。我踩过的一个坑是Agent 有时候会反复调用同一个工具。比如查库存查不到它会换个参数再查再查不到再换。后来我在调度器里加了“同一工具连续调用超过 3 次就强制中断”的规则并在返回里提示 Agent“该工具已多次调用失败请尝试其他方案或告知用户”。4.3 结果校验与人工兜底机制Agent 的输出不能直接信。我在每个 Agent 后面都挂了一个校验器做两件事格式校验输出是否符合预期的 JSON schema业务校验比如退款金额不能为负、退货数量不能超过购买数量校验不通过的处理分两种情况如果是格式问题把错误信息返回给 Agent 让它重新生成如果是业务规则问题直接转人工处理并记录一条“Agent 失败案例”用于后续优化。人工兜底这块我设计了一个简单的转接机制当 Agent 连续两次校验失败或者用户明确表示“转人工”系统就把当前会话上下文打包发给人工客服人工客服可以看到 Agent 已经做了哪些操作、卡在哪里。5. 常见问题与排查技巧实录5.1 Agent 调用工具时参数传错怎么办这是最高频的问题。表现是 Agent 传了一个不存在的参数名或者参数类型不对。排查思路先看工具描述是否清晰参数名和类型是否在描述里写明白了再看 Agent 的输入里是否包含了足够的信息来推断参数如果都没问题考虑在工具描述里加示例我后来养成了一个习惯每个工具的描述里都带一个调用示例。比如search_products的描述末尾加上“示例search_products(keyword跑鞋, category运动鞋, price_range200-500)”。加了示例之后参数错误率下降了很多。5.2 Agent 陷入循环调用怎么破循环调用的典型表现是 Agent 反复调用同一个工具或者在一组工具之间来回跳。原因通常是工具返回的结果没有让 Agent 获得新信息Agent 的目标不明确不知道什么时候该停某个工具一直失败Agent 在尝试不同参数我的解法是在系统 prompt 里加一条硬约束“如果连续两次工具调用没有获得有效新信息必须停止调用并给出当前最优答案或转人工。”同时在调度器层面做兜底超过阈值直接中断。5.3 模型返回格式不稳定怎么处理即使你要求 Agent 返回 JSON它有时候还是会返回带 markdown 代码块的 JSON或者多一段解释文字。我的处理方式是在 prompt 里明确“只返回 JSON不要有任何其他文字”解析时先用正则提取 JSON 部分再做解析如果解析失败把原始返回和错误信息一起返回给 Agent 让它重试实测下来加了“只返回 JSON”的约束后格式错误率从 15% 降到了 3% 左右。剩下的 3% 基本都能通过一次重试解决。5.4 并发场景下的资源竞争问题电商系统天然有并发。多个 Agent 同时操作同一个订单或同一个库存很容易出问题。我的做法是对涉及写操作的工具加分布式锁锁粒度到订单号或 SKUAgent 在调用写操作前先调一个check_lock工具确认资源可用如果拿不到锁Agent 可以选择等待或告知用户“当前操作繁忙请稍后重试”这个方案不是最优的因为加锁会降低吞吐。但在 Agent 场景下我宁愿牺牲一点吞吐也要保证数据一致性。毕竟 Agent 的出错成本比人工高得多人工出错还能解释Agent 出错就是批量事故。5.5 常见问题速查表问题现象可能原因排查方向解决手段工具调用参数错误工具描述不清检查描述和示例补充参数说明和示例Agent 循环调用目标不明确检查 prompt 约束加停止条件调度器兜底返回格式不稳定prompt 约束不够检查输出要求加格式约束解析层容错并发写冲突缺少锁机制检查写操作工具加分布式锁锁粒度细化响应太慢工具链路过长看调用链耗时优化工具加缓存成本超预期无效调用多统计 token 消耗压缩上下文限制调用次数6. 从单点 Agent 到系统级 AI Native 的演进路径6.1 第一阶段单场景验证我建议不要一上来就搞大而全的架构。先选一个场景把 Agent 跑通验证三件事模型能力是否够用、工具设计是否合理、成本是否可接受。这个阶段的目标不是上线而是积累经验。我在第一阶段只做了售前导购跑了大概两周收集了 500 多条真实对话。这两周最大的收获不是技术上的而是对“Agent 在真实业务里到底能做什么、不能做什么”有了体感。6.2 第二阶段多场景复用与工具沉淀第一个场景跑通后你会发现很多工具是可以复用的。比如get_order、get_user_profile、search_products这些工具在售前和售后场景里都要用。这时候就要开始做工具的分层和复用。我的做法是把工具分成三层基础工具层直接封装业务 API不做额外逻辑组合工具层把多个基础工具组合成一个更高层的操作场景工具层针对特定场景定制的工具分层之后新增一个场景的成本明显降低。我第二个场景售后工单的开发时间只有第一个场景的一半左右。6.3 第三阶段Agent 编排与协同当你有多个 Agent 之后就会遇到 Agent 之间怎么协同的问题。比如售前 Agent 发现用户有售后需求要不要转给售后 Agent售后 Agent 处理完退货后要不要通知推荐 Agent 更新用户偏好我的方案是引入一个轻量的消息总线Agent 之间通过事件通信。每个 Agent 可以订阅自己关心的事件也可以发布事件。这样 Agent 之间是解耦的新增一个 Agent 不需要改其他 Agent 的代码。这个阶段我还在探索中目前只做了售前到售后的单向转接。但方向是清晰的AI Native 的电商系统最终会是一个多 Agent 协同的网络每个 Agent 负责一个领域通过事件和工具调用互相配合。6.4 踩过的坑与经验总结最后分享几个我踩过的坑希望能帮你少走弯路。第一个坑是过度依赖 prompt。我一开始觉得只要 prompt 写得好Agent 就能按预期工作。后来发现 prompt 的约束力是有限的尤其是当工具数量多、状态复杂的时候。正确的做法是 prompt 加代码双重约束代码负责硬性规则prompt 负责软性引导。第二个坑是忽视可观测性。Agent 的决策过程是黑盒如果不记录每一步的输入输出出了问题根本没法排查。我后来在每个工具调用前后都加了日志记录调用参数、返回结果、耗时和 token 消耗。这些日志在优化阶段非常有用。第三个坑是低估了数据质量的重要性。Agent 的效果很大程度上取决于它拿到的数据。如果商品信息本身就不全Agent 再聪明也补不出准确的结果。所以在做 Agent 之前先把基础数据治理做好磨刀不误砍柴工。第四个坑是忘了设置成本上限。Agent 跑起来之后token 消耗是实打实的钱。我建议一开始就设置每日预算上限超过就降级到规则方案。等跑稳定了再逐步放开。这套东西我还在持续迭代目前三个场景的 Agent 已经稳定运行了几个月人工介入率从最初的 40% 降到了 15% 左右。后续我打算把商品推荐和营销文案生成也 Agent 化到时候有新的经验再分享。