企业官网建设流程全解析

1. 现场演示的意外结局：客户忽然说“让我自己来一遍”

上个月我在一家零件制造客户的验收现场做AI代理的技术演示。当时一切都很顺利：用本地模型部署的车间问答助手对答如流，代理根据我一句“帮我规划明天上午Z3车间的巡检路线”，自动调用了知识库检索、排产服务和机械臂控制三个工具，三两下就把任务跑完了。客户的电气主管一直在点头，技术团队也在拍照记录。我正打算收设备回程，他冷不丁来了一句：“这套东西，你走了以后我们肯定得自己维护，趁今天人都在，我能不能在测试工位上也完整做一遍？”

我的第一反应是心虚。为什么心虚？因为演示环境是我自己打磨了两天才调顺的，而客户测试工位上是一台Windows 11的老工作站，装了WSL2，显卡还是上一代，里面堆着不少运维工具，幺蛾子一堆。让客户现场从我搭建的环境迁移到他那台机器上复现，万一卡在依赖安装上，前面建立起来的技术信任会打折扣。但话已经说到这份上，只能硬着头皮陪他走一遍。

也正是这次意外的“客户也要做一遍”，让我吃了不少亏，也让我把后面好几个AI代理项目里踩过的坑，沉淀成了一套标准化的演示复现流程。这篇文章就把整个过程的思考、选型、踩坑和补救写清楚，给做售前演示、方案集成或者企业AI落地交付的朋友们做个参考。

1.1 我原本只打算“演示一遍”，客户却把标准提到了“复现一遍”

先说项目背景。客户是做汽车零部件加工的，工厂里有上百台数控机床，设备维修记录、工艺文档、排产规则散落在好几个系统里。他们要上一套内部AI代理系统，解决三个最实际的问题：

第一，一线员工用自然语言提问，比如“这台机床最近报警都是什么原因”“明天换型B产品需要准备哪些工装”，代理要能查知识库、看设备状态、给出有依据的回答，而不是胡编。

第二，代理要能根据生产计划自动生成巡检路线，并调用地图服务和设备管理系统，输出可执行的巡检单。

第三，演示环节里要有一台机械臂配合做动作，代理接受指令后，把零件从料盘A抓到成品位B。这一步是为了向客户证明：AI代理不只是聊天框里的文字回复，它能真正驱动物理设备做事。

我在自己的笔记本和工作站上搭的环境非常顺：GPU是RTX 4090，显存够大，Ubuntu 22.04，模型已经预热，所有工具接口都通了。演示时客户看到机械臂在仿真环境里稳稳当当地完成抓放动作，确实很兴奋。但“客户也要做一遍”这句话提醒了我：演示之所以是演示，就是因为它经过了充分排练。客户真正要的是在自家环境里把这套流程原样跑通，这意味着从硬件到软件，从模型权重到ROS环境，全都得能在他们那台机器上复现。

1.2 客户要求的“复现”，本质上是一次提前的验收审计

后来我仔细想了一下，客户这种要求其实是企业IT采购里特别典型的心理：他们怕你演示用的是“魔术道具”。而破解这个疑虑的唯一办法，就是你现场做给我看，我自己也能做出来。

对企业客户来说，AI代理这类新东西最大的风险不是功能不满足，而是交付后自己接不住。接不住的原因往往不是算法不行，而是底层环境、依赖、运维流程完全一团黑。客户坚持要亲手复现一遍，真实诉求是验证三件事：

• 这套系统能不能脱离开发者的个人电脑跑起来？
• 运维难度是不是在现有团队能力范围内？
• 依赖的硬件资源是不是他们现有的设备就能承载？

这三点，任何一条不成立，前面演示得再漂亮，项目也走不到签约。所以，客户把演示变成实验课，其实是给双方一个更早暴露问题的机会，不算刁难，反而是把验收提前了。

2. 先把本地模型这条“底裤”穿好：AI代理在客户现场的运行底座

说到复现，最大的障碍其实是模型部署方式本身。我们这次没有调用云端大模型API，而是坚持做本地模型推理。客户信息部门有硬性要求：所有生产数据、工艺文档、设备状态不许出园区，更不许进任何外部API。这就决定了AI代理的“大脑”必须直接长在客户机房或者工位上的某台机器里。

2.1 数据不出园区，决定了不能依赖云上大模型

这一点在方案设计之初就定死了。客户是做汽配的，工艺数据里头全是核心技术的保密信息，别说传到云上，连内部网络分区分得都很细。所以，我们所有的推理都用本地模型来做：对话理解、工具调用、参数抽取、结果生成，全部跑在客户内网里的工作站上。

这意味着事前我得把模型权重文件完整下载好，拷进客户内网，再通过Ollama这类推理框架加载。很多做AI应用的朋友在内网部署时吃过亏：模型下载没问题，但依赖包、Python版本、CUDA版本网上拉不下来，才叫真的难受。所以我们的习惯是，在进现场之前，先把所有需要的东西打成一个离线包，包括模型权重、嵌入模型、依赖库、容器镜像，全部校验一遍。

2.2 本地模型选型和量化：显存不是唯一指标

模型选型上，我们做过不少对比。一开始试过7B级别的模型，发现7B在简单问答上没问题，但一旦要做function calling，它偶尔会不按格式输出，要么漏参数，要么把工具名理解错。后来又试过32B级别的大模型，效果确实好，但对显存要求太高，客户工位上那块16GB显存的卡直接放不下。

最终落在14B级别，选的是Qwen2.5-14B-Instruct，配合4-bit量化。这个组合在客户现场的实际表现是：

• 显存占用大约9GB到10GB，16GB显存运行比较从容，还能同时挂一个嵌入模型做检索；
• 工具调用的格式遵循度明显比7B稳定，参数抽取基本不会出错；
• 单条指令从理解到生成结果的延迟控制在可接受范围内。

这里要特别提醒一句：显存不是唯一指标。很多朋友部署本地模型只看显存，忽略了内存带宽和量化格式带来的差异。比如同样是14B模型，Q4_K_M和Q8_0在显存占用上差不少，在推理速度上也会差出30%以上。演示场景讲究流畅，不能为了省显存把量化压得太狠，实测下来Q4_K_M是性价比最高的档位。

2.3 容易被忽视的推理服务准备：预热、端口、健康检查

这块是我最想强调的经验，因为绝大多数演示翻车不是倒在模型能力上，而是倒在工程细节上。

最大的坑是模型没有预热。本地模型第一次接受请求时，要把权重从内存加载到显存，同时走一遍KV Cache的初始化，这个过程往往要等十几秒。在演示现场，你知道问题不大，说“正在加载”也就过去了。但在客户自己复现的时候，他敲完命令等十几秒没反应，第一反应就是“坏了，你方案有问题”。所以后来我在所有文档里都加了一条：启动推理服务后，先手动发一个空请求让模型预热，再继续往后走。

另外，Ollama默认监听在11434端口，这个端口在客户现场经常跟别的服务冲突。我们后来统一改成随机高位端口，并且在服务启动脚本里加了一个健康检查接口，确认模型加载完成后再进入演示流程。整个过程用一句话总结：把推理服务当成生产服务来对待，而不是当成一个临时跑起来的脚本。

3. 从对话到机械臂：OpenClaw + ROS 让客户看到代理真的在干活

部署好本地模型只是第一步，真正让客户感到“这玩意有用”的，是AI代理能驱动一套完整的工具链，最后落到物理设备上。我们在这次项目里用到了一套自研的轻量AI代理框架，内部代号叫OpenClaw，配合ROS（机器人操作系统）来联动机械臂仿真环境。这套组合也是客户复现时的重点。

3.1 为什么我们自己写了一个轻量代理框架，而不是直接搬LangChain

你可能会问，市面上现成的代理框架那么多，为什么还要自己写？真实原因是：演示和交付场景里，我们需要把工具调用这件事做得极其透明。客户工程师不一定懂大模型，但他们一定看得懂日志。如果框架太复杂，工具调用链路藏在抽象层里，出了问题客户连排查入口都找不到。

OpenClaw的特点就是把代理的核心流程拆得很薄，只有四个环节：意图识别、工具选择、参数抽取、结果反馈。每个环节都独立记录日志。客户复现的时候，哪怕工具调用失败，打开日志就能直观看到是模型理解错了，还是参数传错了，还是ROS那边动作执行失败了。这个设计在客户心里建立信任的速度，比一百页PPT都快。

3.2 让本地模型调用工具的关键设计

本地模型做工具调用，核心是让模型学会按固定结构输出。我们在OpenClaw里把每个工具定义成一个带schema的注册项，然后让模型在响应里输出JSON结构，再被解析器转换成真正的命令。

举个例子，控制机械臂抓取和放置的工具大概是这样的：

# tools/pick_place.py @openclaw.tool( name="pick_place", description="控制机械臂执行抓取与放置动作，输入目标零件ID和放置目标位", args_schema={ "part_id": {"type": "string", "description": "零件编号，如 P003"}, "target_bin": {"type": "string", "description": "放置目标位，如 B2"}, } ) def pick_place(part_id: str, target_bin: str) -> dict: # 调用 ROS2 action 请求，控制机械臂执行实际动作 send_goal("moveit_pick_place", PickPlaceGoal(part_id=part_id, target_bin=target_bin)) return {"status": "ok", "action": "pick_place", "part_id": part_id, "target_bin": target_bin}

这里有个非常重要的原则：**AI代理只负责理解意图和抽取参数，最终执行动作的，永远是经过可靠性验证的确定性代码。**大模型不会直接去算机械臂的运动轨迹，它只是把“用户想要干什么”翻译成“应该调用哪个工具函数、参数是多少”。真正控制机械臂的，还是我们事先写好并且调稳定了的ROS节点。这个边界划得越清楚，整个系统在客户眼里就越可靠。

3.3 和ROS的对接方式：LLM只做意图，执行永远走确定代码

聊到ROS，可能有些朋友不熟，我用一句话解释：ROS是一套机器人开发的通信框架，机械臂的运动轨迹规划、传感器状态、控制指令都在不同的节点之间通过话题或服务来传递。我们做的，就是在OpenClaw和ROS之间架了一层“桥接服务”。

这层桥接做的事情很简单：代理那边输出一个结构化的动作意图，桥接服务把它转成ROS2的action请求，发给机械臂的运动规划节点。以pick_place为例，动作意图经过“确定零件抓取点位”“规划路径”“下发执行”三阶段，每一步都能在日志里看到进展。

这里强烈建议，跟机械相关的执行一定要设计“安全兜底”。我们在演示脚本里加了一个逻辑：如果机械臂执行路径上检测到位置越界或者模型抽取出的目标位不在白名单里，桥接服务会直接拒绝执行并返回错误码。这也是客户比较认可的一点，因为他们看到了AI代理不是“无脑乱动”，而是有一套约束机制在里面。

3.4 演示的那个瞬间：“零件放进去了”比任何图表都有说服力

演示当天，客户的一个调度员随口说了一句：“帮我看看，P003号零件现在应该放到哪个成品位？”代理识别出意图后，自动判断P003需要经过质检流程，然后生成了“抓取—移动—放置”的动作序列。接着，机械臂仿真环境里那个虚拟夹爪稳稳地抓住零件，放到了B2成品位。

那一刻，客户的车间主管直接说：“这个我们要定下来。”为什么一句平平无奇的抓放动作会让客户当场下决心？因为AI代理在这整个过程中没有人工干预，从“自然语言问题”到“物理设备动作”的链路是完整闭环的。相比那些只能输出文字的聊天机器人，这是一个质的差异。

4. 客户实操的翻车点与补救：我把演示做成了傻瓜检查单

回到开头的场景。客户说要自己复现一遍，那天下午我们实打实折腾了两个半小时，才把环境完全跑通。虽然结果是好的，但过程确实狼狈。复盘之后，我把那天所有遇到的问题整理成了一张排查清单，后来在别的项目里非常管用。

4.1 第一次让客户上手时的三个典型卡点

第一次让客户在自己机器上跑，翻车点高度集中，来来回回就这几个：

这三个卡点看起来都是技术细节，但每一个都足以让客户的复现中断。尤其是GPU容器的问题，客户如果对Docker不太熟，看到CUDA报错就会直接认定是你的方案有缺陷。

4.2 我后来沉淀下来的环境体检清单

为了不让宝贵的现场时间花在“装依赖”上，我把复现流程做成了一个环境体检脚本，客户动手之前先跑一遍，确认环境满足，再开始演示。体检脚本检查的内容包括：

• 显卡驱动版本和CUDA可用状态，用nvidia-smi验证；
• Docker和NVIDIA Container Toolkit是否安装，没有的话直接给出安装命令；
• 模型文件离线包是否完整，校验权重文件的哈希值；
• 推理服务健康接口是否返回200，模型是否能正常加载；
• ROS环境变量是不是统一，ROS_DOMAIN_ID是否一致；
• 磁盘剩余空间和内存容量是否够用，不够的话会在报告里标红。

这套体检脚本其实不复杂，但价值非常大。它把“检查环境”这个原本靠人肉记忆的事情，变成了一个标准化动作。客户在复现之前跑一遍，哪里不行一目了然，不需要我们守在旁边盯着命令行手忙脚乱。

4.3 把“经验”变成“文档”：三页纸复现说明书与自检脚本

客户动手复现的时候，我意识到一个很现实的问题：他们不会像我们一样熟悉这个项目的目录结构和每个服务的启动顺序。所以我后来把所有启动命令收敛成了一个脚本，放在一个固定路径下，叫start_all.sh。

这个脚本做的事情是：检查环境、启动模型推理服务、启动嵌入检索服务、启动ROS桥接、启动前端问答界面，全部一条命令完成。客户拿到手的复现说明书只有三页，第一页写硬件要求，第二页写启动步骤，第三页写常见错误对照表。

不要低估这种“傻瓜化”的价值。AI代理交付给客户，如果启动过程要敲十行命令，还要记住先后顺序，客户第二天就会忘。把它收敛成一个脚本之后，客户团队自己维护的门槛就低很多。这也让那个“我也做一遍”的请求，从可能翻车的现场实操，变成了一次几乎不可能失败的流程验证。

4.4 现场时间预算：20分钟跑通的关键在于全程留日志

客户实操那天，下午两个半小时折腾完，我自己也总结了一套时间预算方法。后面再遇到类似场景，我会把客户实操时间锁定在20分钟左右，原因是提前做了三件事：

第一，把离线包提前一周发给客户，叫他们先解压好，不要等到现场才拉文件。客户那边硬盘拷贝速度再快，几十个GB的模型权重也要时间。

第二，要求客户事先跑一遍环境体检脚本，有问题前置解决。如果客户没跑，我会建议先把体检跑了再进正式流程。

第三，所有服务都开着详细的日志输出，而且把日志目录收敛到一个文件夹。客户操作出错的时候，我直接让他把日志文件发给我，几秒钟就能定位问题，不用远程连过去一次次试探。

这里还有一个技巧：演示前把模型的抗干扰能力调好一点。具体做法是在提示词里加了一条“如果用户问题含糊，必须向用户确认具体参数，不要自己猜测”，这样可以避免客户复现时因为随口一句话说得不严谨，导致代理一顿乱操作。客户自己操作的时候，措辞不会像我们演示时那么讲究，这个细节能挡掉很多误触发。

5. 演示结束之后的真问题：交付从“跑通”开始

客户亲手把整套流程跑通之后，他提出的问题立刻就变了。

5.1 客户跑通之后，才开始问你真正的生产问题

跑通之前，客户关注的是“你能不能做”；跑通之后，客户关注的是“我们怎么长期用”。当天下午客户技术负责人问了一连串实际问题：知识库里的工艺文档更新之后，AI代理多久能学到？多个工位同时提问，模型会不会挤爆？机械臂动作出错了怎么紧急停止？谁有权执行那种高风险的设备控制指令？

这些问题的出现，说明客户已经不再把AI代理当个新鲜玩具，而是试着把它放进生产体系里考虑了。对交付方来说，这其实是好信号。

5.2 比模型精度更重要的三件事：权限、审计、知识更新

那次之后，我把AI代理项目的交付重点调整了一下。模型精度当然要调，但比精度更影响长期运行的是这三件事：

权限管理。不是所有人都应该能指挥机械臂动起来。我们后来给代理加了一层“动作审批”环节，凡是涉及设备控制的高风险指令，必须由工段长在界面上确认之后才真正下发。这个改动直接来自客户实操那天提出的需求，说明他们在很短时间里就想到了责任边界问题。

操作审计。代理每一次调用了哪个工具、传了什么参数、是谁发起的请求，全部记录到日志里。客户反馈说，这些日志将来要用来做纠纷追溯和质量复盘，不能省。

知识更新机制。AI代理内部的文档不是一成不变的，工艺流程改了之后要把新文档向量化并替换旧版本。我们把这个过程做成一个更新接口，客户业务人员自己就能操作，不需要一直依赖我们。

5.3 从这次演示里带走的几个长期习惯

我个人的体会有三条，如果只留几条经验给同行，我会留这三条：

第一，演示之前，先把“客户复现”这条路径自己走一遍。提前用一台配置更低、环境更脏的机器还原客户环境，跑通了再上演示现场。绝大多数翻车都可以在这个步骤里提前发现。

第二，所有依赖必须打进离线包，并且验哈希。不要指望现场有顺畅的外网，也不要指望客户的网络策略允许你临时下载。宁可带一个大了点的U盘，也不要现场干瞪眼。

第三，把日志留好，把启动脚本收敛干净。AI代理最大的敌人不是模型不够聪明，而是环境太复杂。代理框架本身的调用链越透明，客户上手就越简单，交付之后找我们擦屁股的概率就越低。

那次“客户也要做一遍”的现场操作，最后其实成了整个项目里最值钱的一段经历。客户通过自己动手，把疑虑变成了认同；我通过观察客户的操作方式，搞清楚了自己交付物在真实使用者手里的样子。AI代理从来不是写完代码就结束的东西，能让人顺利复现、独立维护，才算是真正落地了。