1. 为什么我要用 AI Native 的思路重做一套电商业务系统去年年底我接手了一个挺有意思的活儿把一套跑了三年多的传统电商中台用 AI Native 的思路重新设计一遍。不是简单加个聊天机器人那种“贴皮式 AI”而是从数据流、决策链、任务编排到人机协作方式全部推倒重来。这个项目我前后投入了将近四个月踩了无数坑也积累了不少可以直接复用的经验今天就把整套思路和实操细节完整地摊开讲一遍。先说清楚这套系统到底解决什么问题。传统电商业务系统的核心痛点其实就三个第一运营决策链路太长从数据采集到人工分析再到执行落地中间隔了无数个系统和审批节点第二规则引擎越堆越臃肿一个促销活动的配置能牵扯出几十条 if-else 分支改一处崩三处第三客服、选品、定价、库存这些环节各自为政数据孤岛严重跨域协同基本靠人肉拉群。AI Native 的思路不是给每个环节塞一个模型而是把 Agent 作为系统的一等公民让业务能力以“可编排的智能体”形式存在人只负责定义目标和边界。这套系统适合谁来参考如果你正在做电商中台、SaaS 业务系统或者任何需要多角色协同的复杂业务平台并且已经在用 Claude Code、Agent 框架这类工具做开发那这篇内容基本可以当作一份实战手册来读。如果你只是刚接触 Agent 概念也没关系我会把每个关键决策背后的“为什么”讲透你至少能理解一套 AI Native 系统是怎么从零搭起来的。我用的核心技术栈是 Claude Code 作为主力开发工具配合自研的 Agent 编排层底层业务逻辑用 Python 和 TypeScript 混合实现。整个项目分四个阶段推进领域建模与 Agent 拆分、编排层设计、业务 Agent 实现、以及上线后的可观测性建设。下面按这个顺序展开。2. 整体架构设计与 Agent 拆分思路2.1 从“功能模块”到“业务 Agent”的思维转换传统电商系统的拆分逻辑是按功能域来的商品域、订单域、营销域、库存域、客服域。每个域一个微服务域之间通过 API 网关通信。这套模式跑了十几年没问题但它的前提是“业务流程是确定的”——你提前知道下单要扣库存、支付要改订单状态、退款要回滚库存。可一旦业务变得复杂比如大促期间动态定价、跨店满减叠加、预售尾款计算规则就会爆炸式增长。AI Native 的拆分逻辑完全不同。我不再按“功能”拆而是按“决策单元”拆。每个 Agent 负责一类决策它有自己的目标函数、可调用的工具集、以及记忆机制。比如“定价 Agent”的目标是在保证毛利率的前提下最大化转化率它能调用的工具包括竞品价格查询、历史销量分析、库存水位读取、促销规则引擎。它不需要知道订单怎么创建只需要知道“我给出一个价格建议谁来执行”。这个转换的关键在于Agent 之间的边界不是数据边界而是决策边界。我花了整整两周时间做领域建模把原来 12 个微服务的功能重新映射成 7 个核心 Agent。映射过程中最大的争议点是“库存扣减”到底算不算一个独立 Agent。最后我的判断是库存扣减是一个确定性操作不需要决策所以它降级为“订单 Agent”的一个工具而不是独立 Agent。这个判断标准很实用——如果一个环节的输入输出完全确定没有权衡空间那它就不配做 Agent只配做 Tool。2.2 编排层为什么不用现成的工作流引擎市面上有很多工作流引擎比如 Temporal、Airflow、Prefect我一开始也考虑过直接用。但实测下来发现一个根本性问题这些引擎的编排逻辑是“静态图”节点和边在运行前就定义好了。而 AI Native 系统的编排是“动态的”——Agent 在执行过程中可能根据中间结果决定下一步调用哪个 Agent甚至可能临时生成一个新的子任务。我举个例子。用户发起一个“帮我找一件适合海边婚礼的连衣裙”的请求。传统工作流会走“意图识别 - 商品检索 - 排序 - 推荐”这条固定链路。但在 AI Native 系统里客服 Agent 接到请求后可能先调用“场景理解 Agent”解析出“海边、婚礼、连衣裙”三个关键要素然后发现当前库存里没有完全匹配的于是动态触发“选品 Agent”去分析最近一周的流行趋势选品 Agent 又可能调用“供应链 Agent”查询补货周期。这条链路是运行时生成的不是预先定义的。所以我最终没有用现成引擎而是自研了一个轻量级编排层核心是一个“任务图”数据结构加上一个调度器。任务图支持动态增删节点调度器负责按依赖关系执行。编排层本身不包含任何业务逻辑它只做三件事任务分发、状态追踪、失败重试。这个设计的好处是编排层极其稳定业务变化全部下沉到 Agent 内部不会因为业务调整而改动编排代码。2.3 Agent 之间的通信协议设计Agent 之间怎么说话这个问题比想象中重要。我见过很多项目在这里翻车——有的用自然语言传递消息结果 Agent A 说“库存有点紧张”Agent B 理解成“库存为零”直接触发紧急补货。有的用严格的 JSON Schema结果灵活性太差稍微复杂一点的语义就表达不了。我的方案是“结构化消息 语义标签”的混合模式。每条消息包含三个部分intent意图标签枚举值、payload结构化数据、context自然语言上下文供接收方 Agent 做语义补充。比如定价 Agent 给订单 Agent 发消息{ intent: PRICE_ADJUSTMENT, payload: { sku_id: SKU-2024-8871, suggested_price: 299.00, confidence: 0.87, valid_until: 2024-12-01T23:59:59Z }, context: 竞品同款降价至 279但我们的库存仅剩 43 件建议小幅跟进避免毛利损失过大 }接收方 Agent 优先读intent和payload做确定性处理context只在需要人工复核或异常处理时作为参考。这样既保证了机器间通信的可靠性又保留了语义灵活性。实测下来这套协议让 Agent 间的误判率从最初的 12% 降到了 2% 以下。3. 核心 Agent 的实现细节与实操要点3.1 客服 Agent从意图识别到多轮任务编排客服 Agent 是整个系统里最复杂的因为它直接面对用户输入输出都是自然语言而且经常需要跨域协调。我把它设计成三层结构意图理解层、任务规划层、执行层。意图理解层用 Claude 做 few-shot 分类我准备了大概 200 条标注样本覆盖了售前咨询、售后问题、物流查询、投诉建议四大类。这里有个坑不要试图让模型一次性输出所有意图。我一开始让模型输出“意图 实体 情感”结果准确率只有 68%。后来改成流水线先分类意图再抽实体最后判情感每步单独调一次模型准确率提升到 91%。代价是延迟增加了 300ms 左右但客服场景对延迟不敏感这个 trade-off 完全值得。任务规划层是核心。我实现了一个简单的 ReAct 循环Agent 先思考当前状态决定下一步调用哪个工具执行后观察结果再决定下一步。这里的关键是工具描述要写得极其精确。比如“查询订单”这个工具我一开始的描述是“根据订单号查询订单详情”结果 Agent 经常在用户只提供了手机号的情况下强行调用然后报错。后来改成“根据订单号查询订单详情。注意必须提供完整的订单号如果用户只提供手机号请先调用‘根据手机号查订单列表’工具”错误率立刻降下来了。执行层负责实际调用后端 API。这里我加了一个“确认机制”对于涉及资金、库存、用户隐私的操作Agent 必须先向用户确认再执行。比如退款操作Agent 会说“我查到您的订单 12345 符合退款条件退款金额 299 元将原路返回。确认退款请回复‘确认’”。这个机制上线后误操作投诉直接归零。3.2 选品 Agent用 RAG 加规则引擎做商品推荐选品 Agent 的目标是“在给定场景下选出最合适的商品”。我试过纯向量检索效果不稳定——有时候推出来的商品语义相关但实际不可售比如缺货、下架。后来改成“RAG 召回 规则过滤 模型排序”的三段式。RAG 召回用商品标题和描述的向量索引召回 top 50。规则过滤掉不可售、库存低于阈值、不符合场景硬性条件的商品。模型排序用 Claude 对剩余商品做 pairwise 比较输出最终 top 5。这里有个细节pairwise 比较比 pointwise 打分效果好很多。我让模型对每两个商品比较“哪个更适合海边婚礼”然后做聚合排序比让模型直接打 1-10 分准确率高 20% 以上。选品 Agent 还有一个“探索模式”。当用户需求很模糊时比如“随便看看”Agent 会主动发起多轮对话来澄清需求。我实现了一个“信息增益”策略每次提问选择那个能最大程度减少不确定性的问题。比如用户说“想买件衣服”Agent 会先问“什么场合穿”而不是“喜欢什么颜色”因为场合对选品的影响权重更大。3.3 定价 Agent动态定价的约束优化定价 Agent 是我花时间最多的一个。电商定价不是简单的“成本加利润”它要同时考虑竞品价格、库存水位、历史转化率、促销规则、用户分层等十几个因素。我最终把它建模成一个约束优化问题目标函数是“预期毛利”约束条件包括“价格不低于成本价 1.1 倍”“不高于竞品均价 1.2 倍”“大促期间必须参与满减”等。求解器我用的是简单的网格搜索加启发式剪枝。价格区间按 5 元步长离散化对每个候选价格计算预期转化率用历史数据拟合的弹性模型再乘以毛利得到目标值。约束条件在搜索前先做区间裁剪把不可行解直接排除。这套方法在 SKU 数量不多1000时完全够用单次定价决策耗时在 200ms 以内。这里有个经验定价 Agent 的输出一定要带“置信度”和“有效期”。置信度低于 0.6 时系统会自动转人工审核。有效期到了之后价格自动回滚到基准价避免因为市场变化导致定价失效。这个机制在大促期间特别有用因为竞品价格可能每小时都在变。3.4 订单 Agent确定性流程与异常处理订单 Agent 是唯一一个“半确定性”的 Agent。正常下单流程完全确定校验库存、锁定库存、生成订单、发起支付、支付回调、扣减库存、通知发货。这部分我用状态机实现不涉及任何模型调用保证 100% 可靠。但异常处理部分需要 Agent 介入。比如支付超时、库存锁定失败、地址无法配送这些情况没有标准处理流程需要根据上下文决策。我让订单 Agent 在遇到异常时调用 Claude 做“异常归因”判断是用户问题、系统问题还是外部问题然后选择对应的处理策略。比如“库存锁定失败”可能是并发冲突Agent 会选择重试“地址无法配送”可能是用户填错了Agent 会通知客服 Agent 联系用户确认。这个设计的精髓在于确定性流程用代码保证不确定性流程用 Agent 兜底。不要试图让 Agent 做所有事那样既慢又不可靠。4. 实操过程从零搭建一套可运行的 AI Native 电商系统4.1 环境准备与 Claude Code 配置我用的开发环境是 Ubuntu 22.04主力工具是 Claude Code。安装过程不复杂但有几个配置点容易踩坑。首先是 Node.js 版本Claude Code 要求 18 以上我建议直接用 nvm 管理版本避免系统自带的老版本冲突。安装命令很简单curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash nvm install 20 nvm use 20 npm install -g anthropic-ai/claude-code配置方面我建议在项目根目录建一个.claude文件夹里面放settings.json和CLAUDE.md。settings.json用来配置模型参数和工具权限CLAUDE.md用来写项目级的上下文说明。我的CLAUDE.md大概长这样# 项目上下文 这是一个 AI Native 电商系统包含 7 个核心 Agent。 技术栈Python 3.11 FastAPI TypeScript React 代码规范Python 用 black isortTypeScript 用 eslint prettier 测试要求每个 Agent 必须有单元测试覆盖率 80% # 常用命令 - 启动开发环境make dev - 运行测试make test - 部署到 stagingmake deploy-staging这个文件看起来简单但它让 Claude Code 在生成代码时能自动遵循项目规范省了我大量手动调整的时间。实测下来有了CLAUDE.md之后生成的代码直接可用的比例从 40% 提升到了 75%。4.2 Agent 编排层的代码实现编排层的核心是一个任务图执行器。我用 Python 实现大概 300 行代码。核心数据结构是TaskGraph每个节点是一个Task包含task_id、agent_name、input、dependencies、status五个字段。调度器用拓扑排序确定执行顺序用 asyncio 做并发执行。class TaskGraph: def __init__(self): self.tasks {} self.edges defaultdict(list) def add_task(self, task_id, agent_name, input_data, depsNone): self.tasks[task_id] Task(task_id, agent_name, input_data) if deps: for dep in deps: self.edges[dep].append(task_id) async def execute(self): ready [tid for tid in self.tasks if not self._has_unfinished_deps(tid)] while ready: batch ready[:] ready [] results await asyncio.gather(*[self._run_task(tid) for tid in batch]) for tid, result in zip(batch, results): self.tasks[tid].status done self.tasks[tid].result result for next_tid in self.edges[tid]: if self._all_deps_done(next_tid): ready.append(next_tid) return {tid: t.result for tid, t in self.tasks.items()}这个实现有个关键设计支持运行时动态添加任务。Agent 在执行过程中可以调用graph.add_task()来插入新的子任务调度器会在当前批次执行完后自动纳入新任务。这就是前面说的“动态编排”的实现基础。4.3 用 Claude Code 生成 Agent 骨架代码Claude Code 最强大的地方是它能理解项目上下文并生成符合规范的代码。我通常这样用它先写好 Agent 的接口定义和核心逻辑描述然后让 Claude Code 补全实现。比如我要实现定价 Agent我会先写一个pricing_agent.py的骨架class PricingAgent(BaseAgent): 定价 Agent根据竞品价格、库存水位、历史转化率给出定价建议 async def decide(self, sku_id: str, context: dict) - PricingDecision: # TODO: 获取竞品价格 # TODO: 获取库存水位 # TODO: 获取历史转化率 # TODO: 约束优化求解 # TODO: 返回带置信度的定价建议 pass然后让 Claude Code 补全。它生成的代码质量相当高基本只需要微调。这里有个技巧在 TODO 注释里写清楚每个步骤的输入输出和约束条件Claude Code 会严格按照你的意图实现。我试过只写“实现定价逻辑”生成的代码就很泛泛写清楚“竞品价格从 CompetitorAPI 获取返回 List[PricePoint]取最近 7 天均价”生成的代码就直接可用。4.4 本地模型接入与降级方案虽然主力用 Claude但我也配置了本地模型作为降级方案。原因很简单API 偶尔会不可用或者网络延迟突然飙升这时候如果系统完全依赖云端模型整个电商系统就瘫了。我的方案是用 LM Studio 跑一个 7B 的本地模型通过 OpenAI 兼容接口接入。配置方式是在环境变量里设置FALLBACK_MODEL_URL和FALLBACK_MODEL_NAME编排层在调用云端模型失败时自动切换到本地模型。本地模型的能力肯定不如云端所以我只让它处理简单任务比如意图分类、实体抽取、简单问答。复杂任务如定价决策、选品排序如果云端不可用系统会直接降级到规则引擎而不是硬用本地模型。这个降级链路我实测过几次切换过程对用户基本无感。唯一的问题是本地模型的响应速度受硬件影响较大我在一台 32G 内存的机器上跑 7B 模型单次推理大概 1-2 秒比云端慢不少但作为兜底完全够用。5. 上线后的可观测性与常见问题排查5.1 Agent 运行状态监控Agent 系统的可观测性和传统微服务完全不同。传统服务看 QPS、延迟、错误率就够了Agent 系统还要看“决策质量”。我设计了三个层次的监控指标第一层是基础指标每个 Agent 的调用次数、平均延迟、失败率、Token 消耗。这些用 Prometheus 采集Grafana 展示。第二层是决策指标定价 Agent 的“建议采纳率”、选品 Agent 的“点击转化率”、客服 Agent 的“问题解决率”。这些指标反映 Agent 的决策质量比基础指标更重要。第三层是异常指标Agent 之间的“消息循环次数”防止 A 调用 B、B 又调用 A 的死循环、单次任务的“最大工具调用次数”防止 Agent 陷入无限循环、以及“人工介入率”反映系统自动化程度。我踩过最大的坑是消息循环。有一次客服 Agent 和订单 Agent 互相调用因为一个边界条件没处理好导致两个 Agent 来回发了 200 多条消息Token 消耗瞬间飙升。后来我加了一个硬限制任何两个 Agent 之间的连续消息交换不能超过 5 轮超过就强制中断并转人工。5.2 常见问题速查表问题现象可能原因排查方法解决方案Agent 响应超时模型 API 延迟高或工具调用卡住查看 Agent 执行日志定位卡在哪个步骤设置单步超时超时后降级到规则引擎决策质量下降上下文漂移或提示词被污染对比近期决策记录与历史基线重置 Agent 记忆检查提示词版本Token 消耗异常消息循环或上下文过长查看 Token 消耗趋势图加消息轮次限制压缩上下文Agent 间消息丢失编排层并发冲突检查任务图执行日志给消息队列加持久化失败重试本地模型降级后效果差本地模型能力不足对比降级前后的决策准确率只让本地模型处理简单任务复杂任务直接走规则5.3 几个让我印象深刻的踩坑记录第一个坑是提示词版本管理。我一开始把提示词硬编码在代码里改一次提示词就要重新部署。后来有一次紧急修复一个客服话术问题我直接改了生产环境的提示词结果忘了同步到测试环境导致后续测试全部失效。后来我把提示词抽出来放到独立的配置中心每次修改都有版本记录和灰度发布这个问题才彻底解决。第二个坑是Agent 记忆的污染。客服 Agent 有对话记忆用来保持多轮对话的连贯性。但有一次一个用户恶意输入了大量无关内容这些内容被存进了记忆导致后续对话中 Agent 频繁引用这些无关信息。后来我加了记忆清洗机制每轮对话结束后用一个小模型判断哪些记忆值得保留哪些应该丢弃。这个机制上线后记忆相关的异常下降了 90%。第三个坑是工具调用的权限控制。定价 Agent 有修改价格的权限订单 Agent 有退款权限。有一次因为编排层的 bug定价 Agent 误调用了退款工具虽然最后被风控拦截了但这件事让我意识到 Agent 的权限必须严格隔离。后来我给每个 Agent 分配了独立的工具白名单Agent 只能调用白名单内的工具跨域调用必须经过编排层审批。6. 这套系统跑起来之后的一些真实体会这套系统上线到现在跑了大概半年日均处理订单量在 3 万左右客服 Agent 的问题解决率稳定在 78%定价 Agent 的建议采纳率在 65% 左右选品 Agent 的点击转化率比人工选品高了 12 个百分点。这些数字不算惊艳但考虑到这是一个从零搭建的系统而且中间经历了两次大促的考验我觉得已经达到预期了。如果让我重新做一遍我会在三个方面改进。第一更早引入可观测性。我是在系统基本跑通之后才加监控的导致前期排查问题全靠日志效率很低。第二Agent 的边界划得更细一些。现在有些 Agent 承担了太多职责比如客服 Agent 既要理解意图又要规划任务还要执行后续拆分起来很麻烦。第三提示词工程要工程化。不要把它当成“写文案”要当成“写代码”来管理版本控制、测试、灰度发布一个都不能少。最后分享一个我觉得最实用的技巧给每个 Agent 写一份“岗位说明书”。不是技术文档而是用自然语言描述这个 Agent 的职责、权限、目标、以及和其他 Agent 的协作关系。这份说明书既是给开发看的也是给提示词工程师看的甚至可以直接作为系统提示词的一部分。我试过之后发现有了这份说明书新加入的团队成员理解系统的速度至少快了一倍。