企业官网建设流程全解析

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对应一个明确的业务动作，输入输出清晰。

对于家装行业，我建议先建设这几个核心Skill：

每个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 express

Agent编排层可以用现成的框架，比如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( name="query_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( f"http://order-system/api/orders/{order_id}", headers={"Authorization": f"Bearer {get_token()}"} ) data = resp.json() return [TextContent( type="text", text=f"订单{order_id}当前状态：{data['status']}，预计交付：{data['eta']}" )]

这个MCP Server暴露了一个Tool叫query_order_status，Agent可以通过MCP协议调用它。实际项目中，一个MCP Server可以暴露多个Tool，对应多个业务操作。

4.3 Skill编排与Agent配置

Agent的核心是编排逻辑。当用户问“张三的衣柜订单到哪了”，Agent需要：

1. 从问题中提取实体：客户姓名“张三”，产品类型“衣柜”
2. 调用客户查询Skill，根据姓名拿到客户ID
3. 调用订单查询Skill，根据客户ID和产品类型拿到订单状态
4. 如果订单已发货，调用物流追踪Skill拿物流信息
5. 聚合所有结果，生成自然语言回复

这个编排逻辑可以用代码写死，也可以用配置化的方式。我建议初期用代码写死，因为逻辑清晰、调试方便。等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 常见问题速查表

5.5 几个容易踩的坑

第一个坑：忽视业务系统的限流。智能体层的调用频率可能远高于人工操作。原来一个导购一天查50次订单，智能体层可能一秒就查50次。上线前一定要跟业务系统团队确认限流阈值，必要时在MCP Server层加限流。

第二个坑：Prompt里放了太多Skill描述。Skill数量多了以后，如果把所有Skill描述都塞进Prompt，Token消耗巨大，而且模型容易混淆。解决方案是两级路由：先用一个轻量级分类器判断用户意图属于哪个大类，再只加载该类下的Skill描述。

第三个坑：没有做对话上下文管理。用户可能先问“张三的订单”，再问“那李四的呢”。如果Agent不记住上下文，第二个问题就理解不了。上下文管理要注意控制长度，只保留最近几轮对话，更早的对话做摘要。

第四个坑：忽视数据安全。智能体层聚合了多个系统的数据，一旦泄露影响面很大。必须做数据脱敏，比如手机号中间四位打码，地址只显示到小区。另外要记录完整的审计日志，谁在什么时候查了什么数据都要可追溯。

6. 上线后的持续优化与扩展方向

智能体层上线不是终点，而是起点。上线后要持续做三件事：

第一，收集Bad Case。用户反馈的每一个错误回答都是优化机会。建立Bad Case库，定期分析，归类到意图识别问题、Skill调用问题还是结果聚合问题，针对性优化。

第二，扩展Skill覆盖范围。初期可能只做了查询类Skill，后续可以扩展到操作类Skill，比如改地址、约安装、申请售后。操作类Skill要更谨慎，建议加二次确认机制。

第三，优化Token成本。随着调用量增长，Token成本会成为关注点。可以通过Prompt压缩、结果缓存、小模型替代等方式持续优化。

这个架构的扩展性很好。未来如果要接入新的业务系统，只需要开发对应的MCP Server，不需要改动Agent和Skill层。如果要支持新的交互渠道，只需要在接入层增加适配，核心逻辑不变。

我个人在实际操作中的体会是：智能体层的价值不在于技术多先进，而在于能不能真正解决业务问题。家装行业的从业者不需要理解什么是MCP、什么是Token，他们只需要知道“问一句话就能查到订单进度”。技术要藏在后面，体验要摆在前面。把复杂留给自己，把简单留给用户，这才是智能体层落地的核心原则。