1. 家具家装行业为什么需要AI智能体层家具家装这个行业有个很特殊的地方它既是零售又是服务还带着一点制造业的尾巴。一个客户从进店到最终家具入户中间要经过量尺、设计、报价、下单、拆单、生产、仓储、配送、安装、售后链路长得离谱。而支撑这条链路的往往不是一套系统而是N套——前端有CRM、有门店导购APP、有3D设计工具中台有订单系统、报价引擎、拆单系统后端有ERP、MES、WMS、TMS再加上财务、客服、售后工单七八套系统是常态十几套也不稀奇。这些系统通常是不同时期、不同供应商、不同技术栈堆出来的。门店导购想查一个客户的订单进度得先登CRM看客户信息再切到订单系统查单号再去WMS看库存最后打电话问工厂。一个简单的问题跨了四个系统耗时十几分钟。客户在旁边等着体验可想而知。AI智能体层要解决的就是这个“跨系统”的痛点。它不是要替换掉现有的N套业务系统而是在它们之上加一层智能调度和自然语言交互的能力。导购用一句话问“张三那个定制衣柜订单到哪了”智能体自己去调CRM拿客户ID调订单系统拿订单状态调WMS拿库存和发货信息最后用一句人话回复。这背后的核心技术支撑就是Agent、MCP、Skill和Token这一整套体系。这套方案适合谁看如果你是这个行业的技术负责人、产品经理或者正在做企业数字化中台建设的工程师这篇文章会给你一套可以直接参考的落地思路。如果你只是对AI智能体感兴趣这里面的架构设计和踩坑经验同样有参考价值。我不会讲太多虚的概念重点放在“怎么接”“接的时候注意什么”“哪些坑我踩过”。2. 整体架构设计与核心思路拆解2.1 为什么不做“大一统”而是做“智能体层”很多企业一上来就想搞一个大一统的中台把所有系统推倒重来。这个思路在家装行业基本行不通。原因很简单业务不能停。门店每天在开单工厂每天在排产你不可能让业务等你的中台建设周期。而且家装行业的业务逻辑极其复杂定制家具的报价规则、拆单规则、工艺路线每个品类都不一样想用一个中台全部覆盖周期和风险都不可控。所以更务实的做法是保留现有N套系统在它们之上构建一个AI智能体层。这层的职责很明确——理解用户意图、编排跨系统调用、聚合结果、用自然语言返回。它不碰业务数据的所有权不改变现有系统的核心逻辑只是做一个“智能路由器翻译官”。这个思路的核心优势在于低侵入、快见效、可回退。任何一套业务系统出问题智能体层可以降级到人工操作不影响业务运转。而且智能体层可以按场景逐步上线先做订单查询再做报价辅助再做售后工单每一步都能独立验证价值。2.2 Agent、MCP、Skill、Token四者的关系这四个词是当前AI智能体领域最核心的概念但很多人搞不清楚它们之间的关系。我用一个家装行业的类比来解释Agent是“店长”。他负责理解客户需求决定派谁去干活最后汇总结果。店长不亲自量尺、不亲自安装但他知道该找谁。Skill是“专业技能包”。比如“查订单”是一个Skill“算报价”是一个Skill“查库存”是一个Skill。每个Skill封装了一类具体的业务能力店长Agent根据客户问题调用对应的Skill。MCP是“对讲机协议”。它规定了Agent和各个业务系统之间怎么通信。没有MCP的时候Agent要调CRM得写一套对接代码调ERP又得写一套调WMS再写一套每套系统的接口风格、认证方式、数据格式都不一样。MCP把这些差异统一起来让Agent用同一种方式跟所有系统对话。Token是“通行证计量单位”。一方面Token用于身份认证Agent调每个系统时都要带上Token证明自己有权限另一方面Token也是大模型调用时的计量单位直接影响成本。这四者的协作关系是Agent接收用户请求通过MCP协议调用各个Skill每个Skill在执行时携带Token完成身份验证和权限校验最终结果由Agent聚合后返回给用户。2.3 分层架构的具体设计整个智能体层我建议分成四层接入层负责接收来自不同渠道的请求。门店导购可能用企业微信客服可能用工单系统管理层可能用钉钉或飞书。接入层要做的是统一请求格式识别用户身份做初步的意图分类。编排层是核心也就是Agent所在的位置。它负责多轮对话管理、意图理解、Skill路由、结果聚合。这一层要处理一个关键问题当用户的问题需要调用多个Skill时怎么编排调用顺序怎么处理依赖关系怎么在某个Skill失败时做降级。能力层由一个个Skill组成。每个Skill是一个独立的服务单元封装了一类业务能力。比如“订单查询Skill”封装了调CRM、调订单系统、调WMS的完整逻辑。Skill的设计原则是高内聚、低耦合一个Skill只做一件事做好一件事。连接层通过MCP协议对接N套业务系统。每个业务系统需要一个MCP Server来适配把系统原有的API转换成MCP标准协议。这一层还要处理认证、限流、重试、日志等横切关注点。3. 核心细节解析与实操要点3.1 MCP Server的适配策略MCP协议的核心价值在于标准化。但在实际落地中N套业务系统的接口成熟度参差不齐。有的系统有完整的REST API有的只有SOAP接口有的甚至只能通过数据库直连。针对不同情况我建议采用三种适配策略直接适配适用于有标准REST API的系统。写一个MCP Server把系统的API封装成MCP的Tool定义好输入参数和输出格式即可。这是最理想的情况工作量最小。网关适配适用于接口风格不统一但都有HTTP接口的系统。先在MCP Server里做一层转换把不同风格的接口统一成标准格式。比如有的系统用GET传参有的用POST JSON有的用XML网关层统一转换成JSON。数据库适配适用于没有API的老系统。这种情况要谨慎因为直连数据库有风险。我的做法是只读不写而且只读从库。写操作一律走原有系统的界面或接口智能体层不直接改数据。这是底线。注意数据库适配时一定要加查询超时和结果集大小限制。我见过一个案例智能体查订单时没加limit直接把一张百万级的表拉出来了数据库直接被打挂。3.2 Skill的粒度设计Skill的粒度设计是个技术活。粒度太粗一个Skill干太多事复用性差粒度太细Agent要调很多次延迟高Token消耗大。我的经验是按业务对象划分Skill。比如“订单”是一个业务对象围绕订单可以有“查订单状态”“查订单详情”“改订单地址”“取消订单”这几个Skill。每个Skill对应一个明确的业务动作输入输出清晰。对于家装行业我建议先建设这几个核心SkillSkill名称功能说明依赖系统客户查询根据姓名/手机号查客户信息CRM订单查询查订单状态、进度、预计交付订单系统、WMS库存查询查成品/原材料库存WMS、ERP报价计算根据户型、材质、工艺算报价报价引擎工单创建创建售后/安装工单客服系统物流追踪查配送位置和预计到达TMS每个Skill的输入输出都要定义JSON Schema这样Agent才能准确理解每个Skill需要什么参数、返回什么结果。3.3 Token管理与权限控制Token管理是容易被忽视但极其重要的一环。智能体层调N套系统每套系统都有自己的认证体系。如果每个Skill都自己去拿Token会出现Token重复获取、过期不刷新、权限混乱等问题。我的做法是在连接层做一个统一Token管理中心。所有Skill不直接持有Token而是通过Token管理中心获取。Token管理中心负责统一存储各系统的认证凭据、自动刷新过期Token、按用户身份做权限映射、记录Token使用日志。权限映射是关键。门店导购只能查自己门店的订单客服只能查自己负责的工单区域经理可以查本区域所有门店的数据。这个权限逻辑要在Token管理中心实现而不是在每个Skill里重复写。实操心得Token过期是智能体调用失败的头号原因。我建议Token有效期设置得比业务系统实际有效期短10%留出刷新缓冲时间。另外一定要做Token失效的自动重试第一次调用失败后自动刷新Token再试一次。3.4 大模型选型与Token成本控制大模型选型要考虑三个因素意图理解准确率、响应延迟、Token成本。家装行业的用户提问往往比较口语化比如“我那个柜子啥时候能装”模型要能准确理解这是在查订单进度。我的建议是采用分级模型策略简单的意图分类和参数提取用小模型复杂的多轮对话和结果聚合用大模型。这样可以在保证效果的前提下控制成本。Token成本控制有几个实用技巧一是做好Prompt缓存系统提示词和Skill描述这些固定内容可以缓存不用每次重复计算二是控制上下文长度只把相关的历史对话传给模型不要把所有历史都塞进去三是结果聚合尽量用规则引擎而不是大模型比如把订单状态、物流信息、安装进度拼成一句话用模板就能做不需要大模型。4. 实操过程与核心环节实现4.1 环境准备与基础依赖先说一下基础环境。MCP Server我建议用Python或Node.js来写这两个生态最成熟。Python的话需要安装mcp包Node.js需要安装modelcontextprotocol/sdk。数据库方面Token管理中心建议用Redis因为要频繁读写且对一致性要求不是极高。# Python环境准备 pip install mcp redis fastapi uvicorn # Node.js环境准备 npm install modelcontextprotocol/sdk redis expressAgent编排层可以用现成的框架比如LangChain、AutoGen也可以自研。我倾向于自研轻量级编排引擎因为家装行业的业务逻辑比较特殊通用框架反而会增加复杂度。4.2 MCP Server开发示例以一个订单查询MCP Server为例核心代码如下from mcp.server import Server from mcp.types import Tool, TextContent import httpx app Server(order-service) app.list_tools() async def list_tools(): return [ Tool( namequery_order_status, description根据订单号查询订单状态和进度, inputSchema{ type: object, properties: { order_id: {type: string, description: 订单号}, customer_id: {type: string, description: 客户ID} }, required: [order_id] } ) ] app.call_tool() async def call_tool(name: str, arguments: dict): if name query_order_status: order_id arguments[order_id] # 调用订单系统API async with httpx.AsyncClient() as client: resp await client.get( fhttp://order-system/api/orders/{order_id}, headers{Authorization: fBearer {get_token()}} ) data resp.json() return [TextContent( typetext, textf订单{order_id}当前状态{data[status]}预计交付{data[eta]} )]这个MCP Server暴露了一个Tool叫query_order_statusAgent可以通过MCP协议调用它。实际项目中一个MCP Server可以暴露多个Tool对应多个业务操作。4.3 Skill编排与Agent配置Agent的核心是编排逻辑。当用户问“张三的衣柜订单到哪了”Agent需要从问题中提取实体客户姓名“张三”产品类型“衣柜”调用客户查询Skill根据姓名拿到客户ID调用订单查询Skill根据客户ID和产品类型拿到订单状态如果订单已发货调用物流追踪Skill拿物流信息聚合所有结果生成自然语言回复这个编排逻辑可以用代码写死也可以用配置化的方式。我建议初期用代码写死因为逻辑清晰、调试方便。等Skill数量多了再考虑配置化。async def handle_query(user_input: str, user_context: dict): # 意图识别 intent await classify_intent(user_input) if intent query_order: # 提取实体 entities await extract_entities(user_input) # 调用客户查询Skill customer await call_skill(customer_query, { name: entities.get(name), phone: entities.get(phone) }, user_context) # 调用订单查询Skill orders await call_skill(order_query, { customer_id: customer[id], product_type: entities.get(product_type) }, user_context) # 聚合结果 return format_order_response(orders)4.4 灰度上线与效果验证智能体层不要一次性全量上线。我的做法是分三个阶段第一阶段影子模式。智能体层接收真实请求也调用真实系统但结果不直接返回给用户而是记录日志跟人工操作的结果做对比。这个阶段主要验证意图识别准确率和Skill调用成功率。第二阶段白名单模式。选择几个配合度高的门店或客服团队让他们真实使用智能体层。这个阶段收集用户反馈优化Prompt和Skill逻辑。第三阶段全量上线。在验证效果达标后全量推开。但一定要保留人工入口用户随时可以切换到人工服务。效果验证的核心指标包括意图识别准确率目标95%以上、Skill调用成功率目标99%以上、平均响应时间目标3秒以内、用户满意度目标4.5分以上。5. 常见问题与排查技巧实录5.1 意图识别不准怎么办这是最常见的问题。用户说“我那个柜子啥时候能装”模型可能识别成“查询安装进度”也可能识别成“查询订单状态”还可能识别成“投诉安装延迟”。我的解决思路是先做意图澄清再做意图识别。当模型对意图的置信度低于阈值时不要猜直接反问用户“您是想查询订单进度还是想预约安装时间”这样虽然多了一轮交互但准确率大幅提升。另外要建立行业意图库。把家装行业常见的用户问法整理成意图样本用于微调模型或做Few-shot示例。这个工作前期投入大但后期收益很高。5.2 Skill调用超时怎么处理跨系统调用超时是必然会发生的事。我的处理策略是分级超时降级返回。每个Skill设置独立的超时时间比如客户查询2秒订单查询3秒物流查询5秒。超时后不直接报错而是返回部分结果加提示。比如订单查询超时了但客户信息查到了可以回复“已找到客户张三订单信息正在查询中请稍后”。如果所有Skill都超时就降级到人工入口提示用户“系统繁忙正在为您转接人工客服”。5.3 Token失效的自动恢复Token失效的表现是接口返回401或403。处理逻辑应该是捕获到401/403后自动刷新Token然后重试一次。如果重试仍然失败才向上报错。这里有个坑并发场景下多个Skill同时发现Token失效同时去刷新Token会造成Token刷新风暴。解决方案是加分布式锁只允许一个请求去刷新Token其他请求等待刷新完成后使用新Token。5.4 常见问题速查表问题现象可能原因排查方向解决方案意图识别错误Prompt不清晰/样本不足检查Prompt和Few-shot示例优化Prompt补充行业样本Skill调用超时业务系统响应慢/网络问题查看业务系统日志和网络延迟设置分级超时增加降级逻辑Token失效Token过期/权限变更检查Token有效期和权限配置自动刷新Token加分布式锁结果聚合错误数据格式不一致检查各系统返回的数据格式统一数据格式加校验逻辑响应时间过长串行调用多个Skill分析调用链路耗时改串行为并行加缓存大模型幻觉上下文不足/模型能力不够检查传给模型的上下文补充上下文换更强模型5.5 几个容易踩的坑第一个坑忽视业务系统的限流。智能体层的调用频率可能远高于人工操作。原来一个导购一天查50次订单智能体层可能一秒就查50次。上线前一定要跟业务系统团队确认限流阈值必要时在MCP Server层加限流。第二个坑Prompt里放了太多Skill描述。Skill数量多了以后如果把所有Skill描述都塞进PromptToken消耗巨大而且模型容易混淆。解决方案是两级路由先用一个轻量级分类器判断用户意图属于哪个大类再只加载该类下的Skill描述。第三个坑没有做对话上下文管理。用户可能先问“张三的订单”再问“那李四的呢”。如果Agent不记住上下文第二个问题就理解不了。上下文管理要注意控制长度只保留最近几轮对话更早的对话做摘要。第四个坑忽视数据安全。智能体层聚合了多个系统的数据一旦泄露影响面很大。必须做数据脱敏比如手机号中间四位打码地址只显示到小区。另外要记录完整的审计日志谁在什么时候查了什么数据都要可追溯。6. 上线后的持续优化与扩展方向智能体层上线不是终点而是起点。上线后要持续做三件事第一收集Bad Case。用户反馈的每一个错误回答都是优化机会。建立Bad Case库定期分析归类到意图识别问题、Skill调用问题还是结果聚合问题针对性优化。第二扩展Skill覆盖范围。初期可能只做了查询类Skill后续可以扩展到操作类Skill比如改地址、约安装、申请售后。操作类Skill要更谨慎建议加二次确认机制。第三优化Token成本。随着调用量增长Token成本会成为关注点。可以通过Prompt压缩、结果缓存、小模型替代等方式持续优化。这个架构的扩展性很好。未来如果要接入新的业务系统只需要开发对应的MCP Server不需要改动Agent和Skill层。如果要支持新的交互渠道只需要在接入层增加适配核心逻辑不变。我个人在实际操作中的体会是智能体层的价值不在于技术多先进而在于能不能真正解决业务问题。家装行业的从业者不需要理解什么是MCP、什么是Token他们只需要知道“问一句话就能查到订单进度”。技术要藏在后面体验要摆在前面。把复杂留给自己把简单留给用户这才是智能体层落地的核心原则。