企业官网建设流程全解析

帮客户做完了整套AI代理演示，看完效果客户当场点头，但接下来一句话让我心里一紧——“那我们也自己做一遍，你支持下。”

说实话，在AI代理这个领域，演示时“我能跑起来”和交付后“你也能跑起来”完全是两码事。标题里的这句话，几乎是每个做企业级AI方案的人都绕不过去的坎。哪怕你的Demo再炫，PPT再漂亮，只要客户自己在本地环境里复现不出来，前面所有信任积累都会在半小时内清零。

这篇文章就是我基于最近几个真实交付项目的完整复盘，把演示设计、环境准备、本地模型与代理助手的组合、以及把代理接到ROS机器人这类物理设备上的踩坑过程全部捋一遍。内容偏实操，目标是让你看完之后能直接套用这套流程，把自己手里的AI代理项目从“演示级”推进到“客户可复现级”。

1. 演示目标的双重性：看懂只是及格线，复现才是交付线

很多团队做AI代理演示时，默认目标是“让客户觉得厉害”。这个目标本身没有错，但它只覆盖了演示的前半段。当客户看完之后说出“我们也要做一遍”的时候，你面对的真实需求其实已经变了——客户需要的不再是“观看一场表演”，而是“拿到一张可靠的地图，照着走也能走到终点”。

1.1 演示级Demo与可复现Demo的本质差异

先摆一个我反复踩过坑后总结出来的判断标准：演示级Demo回答的是“这个东西能不能做”，可复现Demo回答的是“这个东西客户自己能不能做”。两者之间的差距，往往就是项目从POC走向合同的关键一跃。

演示级Demo通常具备这些特征：跑在演示者的电脑或云环境上、依赖特定的API密钥、数据已经做过手工清洗、模型参数调到了刚好能出好效果的状态。这种Demo在演示现场可以很稳定，但客户一旦拿回自己的环境，就会遇到一连串“我这边为什么跑不出来”的问题——环境变量没配齐、Python版本不对、模型文件没有提前下载、外网接口在客户内网被墙……每一个问题都可能让客户当场失去信心。

可复现Demo的要求就高得多。它必须做到三件事：一是环境依赖全部锁定，哪怕客户从零开始搭建，也能在文档引导下把环境跑起来；二是数据路径清晰，示例数据和真实业务数据的切换方式明确；三是模型调用可回退，既支持云端API，也支持本地模型推理，这样客户在算力受限或数据敏感的场景下依然能完成复现。

从我过往的服务经验来看，绝大多数客户说“我们也要做一遍”，本质上是在验证两件事：这个方案脱离你的手能不能跑，以及跑起来的成本（时间、算力、技术栈）是不是我能接受的。如果你只准备了“能跑”的部分，却没有准备“客户也能跑”的部分，那这场演示最后往往会变成一个没有答案的答疑现场。

1.2 客户“自己做一遍”时最想验证的三个问题

把客户的潜台词翻译一下，你会发现他们真正在意的问题非常集中。

第一个问题是环境适配性。客户的IT环境通常比演示环境复杂得多，可能有堡垒机、离线网络、老旧的操作系统版本、严格的软件安装审批流程。他们想确认的是，这个AI代理方案是否能嵌进他们现有的技术体系，而不是反过来要求他们为这个方案改变基础设施。

第二个问题是模型依赖度。很多AI代理演示都会调用GPT-4这类云端大模型，效果确实好，但客户一问到数据安全、调用成本、离线可用性，就发现方案比较脆弱。所以他们想自己做一遍，看看换成开源的本地模型之后，代理还能不能维持一个可用的水平。

第三个问题是复杂度可控性。代理类项目天然涉及多个组件——大模型调用、工具注册、任务规划、记忆管理、外部系统连接。客户需要确认这套东西的日常运维是不是他们现有团队能接住的。毕竟再好的方案，如果客户接手后玩不转，最后还是会反噬到你的交付口碑上。

搞清楚了这三个问题，整个演示和复现支持工作就有了明确的靶子。后面所有准备和编排，都是围绕这三件事展开的。

2. 演示前准备：把“我能跑起来”变成“你也能跑起来”

我见过不少技术上很牛的人，演示时顺手敲几条命令就把服务跑起来了，但客户一脸茫然，因为完全不知道你敲这些命令是为了什么。问题不在于技术不行，而在于准备的时候只准备了“演示脚本”，没有准备“复现剧本”。

2.1 环境快照与依赖锁定的三板斧

先说最崩溃的一种情况：客户按照文档一步步装依赖，结果在某个包的版本上卡了半小时，最后发现是你文档里漏了一个Python版本限制条件。这种问题在演示现场几乎无法临时救场，所以必须在演示前用“三板斧”把环境问题一次锁死。

第一板斧是锁Python解释器版本。AI代理项目对Python版本的敏感度远比一般Web项目高，很多框架在3.10和3.11上的行为差异就可能导致代理任务规划出错。我现在做项目，第一件事就是在项目根目录放一个.python-version文件，配合pyenv或者uv使用，确保演示机和客户复现机用的是同一个解释器版本。

第二板斧是锁依赖版本。单纯的requirements.txt只能锁住顶层依赖，transitive dependency一旦漂移，照样会出问题。更稳妥的做法是用uv的lock机制或者Poetry，生成完整的锁文件。如果客户环境是内网断网环境，还要提前把依赖包打成wheel包，连同离线安装脚本一起交给对方。这块没有太多技术含量，纯粹是准备工作细不细的问题。

第三板斧是容器化兜底。我会为每个演示项目做一个标准Docker镜像，镜像里把代码、模型文件路径、启动脚本全部固化好。如果客户环境支持容器，那复现路径就变得极其简单——docker pull或者导入镜像包，然后一条命令启动。容器化不只解决了环境问题，还顺便把系统级依赖（比如libgl、ffmpeg这类）也一并包含了。

2.2 把演示素材“去我的手”化

这是我个人经验里最容易被忽略的一个环节。很多AI代理演示之所以只能看不能做，问题恰恰在于演示素材和演示者深度绑定——PPT里有你的账号、数据文件里有你手工处理过的痕迹、代码里有你测试时留下的hardcode路径。

准备客户复现版素材时，我通常会把三样东西“去我的手”化：API密钥改成环境变量占位符，并附上一份密钥配置说明，明确写清楚去哪儿申请、申请哪个档位；示例数据改成一套不依赖我本地文件路径的样例集，放在相对路径下，外加一个自动下载脚本；配置文件的路径改用相对于项目根目录的写法，而不是/home/me/...这种绝对路径。

这三个改动看似简单，但在客户复现环节中能省掉大量来回沟通。尤其是路径问题，我刚入行时经常遇到客户照着文档执行到一半报FileNotFoundError，最后发现是文档里的绝对路径和客户环境不一致。这种问题特别消磨耐心，一次就能让客户对整套方案的成熟度打问号。

2.3 模型离线包与本地推理服务的预置方案

现在客户对数据出域的敏感度越来越高，“本地模型”几乎是每个企业级AI代理项目绕不开的话题。我的建议是，不要在演示那天才现场下载模型权重，而应该在准备阶段就把本地推理链路完整跑通。

具体来说，我会在准备阶段做三件事：把选定的本地模型权重下载好，存到共享网盘或持久化存储里，然后在演示文档里写清楚模型文件的哈希校验值；部署一个本地的推理服务，个人练手阶段用Ollama就够，正式一点的环境可以上vLLM，接口统一走OpenAI兼容格式；准备好模型切换的配置入口，让代理框架可以通过环境变量或者配置文件切换“云端模型”和“本地模型”两个通道。

实际执行时，Ollama拉取一个7B级别的模型，显存约需6到8GB，满足大多数演示场景；如果客户要更强的效果，再用vLLM部署14B级别模型，但这时的显存和显存带宽要求都会上来，需要提前和客户确认机器规格。把这个通道提前打通，客户自己动手时就不会在模型环节卡住。

3. 演示现场编排：让客户边看边建立“自己做”的心智模型

很多演示者在台上喜欢一口气把所有能力show完，这个思路在纯展示型演示中没问题，但在“客户也要做一遍”的场景里是错的。

3.1 先讲业务场景，再讲技术实现

客户能否顺利复现你的方案，很大程度上取决于他有没有在脑子里建立一个“这个任务流程是怎么串起来的”心智模型。所以演示时应该先讲清楚：这个AI代理要解决一件什么事、它的输入是什么、输出是什么、中间会调用哪些工具、哪些环节是模型决策、哪些环节是硬逻辑。

这个顺序不能反。如果一上来就讲代码和框架配置，客户虽然能看懂每个技术点在做什么，但拼不成一条完整的任务链路，到他自己动手时就只能照着抄，一旦遇到稍有偏差的情况就不知道怎么调整。

我习惯在演示开头用两分钟时间画一条完整的数据流：用户输入→代理规划任务→调用工具A→获得中间结果→判断是否需要调用工具B→输出最终答案。画完这条链路之后，再逐步展开技术实现，客户就很容易知道每个组件在大图里的位置。

3.2 演示节奏设计：一条主线、两个支线、三个停靠点

演示时间控制上，我给自己定的一条准则是：不追求炫技，只追求让客户在这个场景里找到“这个不难”的感觉。

一条主线，指的是整个演示只围绕一个完整业务任务展开，比如“让代理自动收集某行业过去一个月的资讯，做摘要并生成一份邮件简报”。只做一条主线的目的，是让客户清楚看到任务的完整生命周期，而不是看了六个功能却不知道它们怎么协同。

两个支线，指的是沿着主线展示两个关键可变点：一个是切换本地模型后代理输出的变化，另一个是给代理临时添加一个新工具后，它能立刻用新工具完成任务。这两个支线能直接回答客户心里关于“模型怎么落地”和“工具怎么扩展”的疑问。

三个停靠点，是指演示过程中刻意在三个节点暂停并让客户看到中间状态：第一停，展示代理已经拆解出的任务列表；第二停，展示代理在调用一个工具后拿到的中间结果；第三停，展示代理在遇到一个值得注意的异常情况时如何调整策略。这三个停靠点本质上是把代理的内部决策过程“可视化”，让客户建立“原来它是这么工作的”体感。

3.3 演示现场的环境隔离与观众实操提示

关于现场演示，还有一个必须提前确认的就是环境隔离。演示机和客户自己动手用的实操环境，一定要分开。如果客户手痒想现场试一下，让他在实操环境里试，而不是直接在演示机上操作——否则他一个不小心改了环境变量，你后面的演示节奏就全乱了。

我在现场会专门开一台实操机（或者一个独立的容器），预先把环境和素材都准备好，让客户随时可以上手试。同时打印一页速查卡放在实操机旁边，上面写清楚：启动代理服务的命令、打开交互界面的本地地址、切换模型的配置位置、以及一个最简单的测试用例。不要小看这张卡，它对客户“自己动手”的心理门槛会有明显的降低作用。

4. 客户动手环节的引导策略与资源配置

演示结束后的动手环节，才是整个项目中信息密度最高、也最考验支持水平的阶段。这个环节做得好，客户的信任感会迅速赶超看演示时的感受。

4.1 给客户一套带示例数据的沙盒环境

动手环节首先得给客户一个能自由折腾的沙盒。最常见的问题是：客户想自己试试，但又怕把正式环境搞坏，于是不敢动手。我的解决办法是提供一套完全隔离的沙盒环境，里面预置了：一个能直接跑通的AI代理最小示例、一套与客户业务形态相似的脱敏示例数据、一个自动重置脚本（客户随时可以一条命令把环境恢复到初始状态）。

有了沙盒，客户的试错成本瞬间降低。他可以随便改提示词模板、随便换工具配置、随便调模型参数，改坏了就重置，完全不影响演示主环境。这个安全感对客户“自己动手”的意愿影响非常大。

环境准备好之后，我还坚持一个原则：给客户的任务必须是“有难度梯度”的。上来就让客户独立写一个完整的代理任务，很容易劝退。正确的节奏是三步走：第一步，让客户只改一处配置，比如把输入数据换成他自己的示例文件，运行并观察效果变化；第二步，让客户添加一个预设好的新工具，观察代理是否会自动调用这个工具；第三步，让客户描述一个他业务里的真实场景，然后在他的描述基础上调整提示词，现场跑出第一版效果。

4.2 动手过程中支持团队的角色边界

客户自己动手时，支持团队最容易犯的毛病是“服务过度”——看到客户卡住就直接上手把问题解决了。这种方式看似高效，但实际上剥夺了客户自己获得体感的机会。

我的原则是：只回答“是什么”和“在哪里”，不直接替客户做“怎么做”。比如客户报了个报错，我会告诉他这个报错大概出现在哪个模块、日志在哪里看、根据我们经验大概率是哪几个原因，但我会先让他自己尝试排查一遍。只有在客户明确表示“我已经尝试了以下几步但还没解决”时，我才会动手。

这个边界之所以重要，是因为客户团队的成员带着问题回去之后，他们才是日常维护这套方案的人。如果他们只是“看着你修好了”，那他们回去后遇到同类问题仍然会手足无措。

4.3 记录客户的终端操作轨迹与反馈

在动手环节我还会做一件事：请客户允许我记录他们的终端操作轨迹，尤其是报错信息。别小看这个请求——客户的报错记录往往是你的演示遗漏了某个前置条件的最直接线索。

实际操作中，我会建议客户在一个共享的文档里记录他们每一步的操作和结果。每次动手结束后，我把这些记录汇总，分析哪些地方客户走得顺，哪些地方反复卡住。这些数据会直接反馈到下一版的复现手册里，把文档中没有写清楚的地方补上，把容易误解的概念用更通俗的语言重新表述。

这份“客户复现日志”还有一个额外好处：它可以作为项目的交付证据之一，证明你的方案已经不止停留在演示层面，而是真正具备了交到客户手里并跑通的能力。

5. 让代理接上本地模型：从云端依赖到离线可用的落地配置

前面提到过，客户自己复现时最容易翻车的点就是模型通道。这里单独展开讲一下“代理助手配本地模型”的实操配置，因为这套组合几乎覆盖了所有企业内网部署场景。

5.1 代理框架为什么要兼容OpenAI标准接口

现在主流的代理开发框架（LangGraph、AutoGen、CrewAI这类）在大模型调用层基本都能兼容OpenAI的接口协议。这意味着什么？意味着你可以把模型服务的地址从一个云厂商的API端点，直接替换成你内网机器上的一个本地服务地址，而代理业务代码基本不用改。

所以我在跑AI代理项目时，第一件事就是把本地推理服务启动成OpenAI兼容模式，然后单独建一个配置文件，把模型服务的base_url和model_name放进去，让代理框架在启动时读取这个配置。这样客户在复现时，只需要把配置文件里的地址指到他自己环境里的本地模型服务，就能无缝切换。

5.2 基于Ollama的本地模型接入实例

我手里用得最多的本地模型接入方案是Ollama。原因很朴素：它对硬件门槛的要求相对友好，支持的模型面和量化格式多，而且一条命令就能把一个开源模型跑成OpenAI兼容接口。

具体做法分三步。第一步，准备好模型，执行一条命令拉取并启动指定模型；第二步，启动Ollama的API服务，默认端口是11434，我通常会用一个反向代理把它映射到统一端口；第三步，在代理框架的模型配置里把base_url指向Ollama的服务地址，模型名改成拉取的模型标签。

以LangGraph的一个简单配置示例来说明：

# config/llm_config.py from langchain_openai import ChatOpenAI # 云端模型通道 cloud_llm = ChatOpenAI( model="gpt-4o-mini", base_url="https://api.openai.com/v1", api_key=os.environ["OPENAI_API_KEY"], ) # 本地模型通道 local_llm = ChatOpenAI( model="qwen2.5:7b-instruct-q4_K_M", base_url="http://localhost:11434/v1", api_key="ollama", # 本地服务不校验密钥，占位即可 )

这个配置的核心思路是：代理的业务逻辑完全不用变，只需要在创建语言模型实例时选定走哪条通道。我在演示中会把两个通道都建好，然后让客户自己切换对比效果。

5.3 参数选择与显存预算估算

本地模型跑起来容易，跑得“像样”则需要提前估算一下资源和参数。这里给一组我实测的参考数据。

7B级别的量化模型（比如Qwen2.5-7B的4bit量化版本），显存占用大约6到8GB，普通消费级显卡就能跑。搭配32GB内存的机器，整体体验能满足“让客户看到效果”的演示级别。如果客户要求更高，换13B或14B级别模型，显存预算就要拉到12到16GB，并且建议使用vLLM做推理加速，否则响应延迟会明显影响体感。

还有一个容易忽略的参数是上下文长度。AI代理任务中的规划环节、工具调用结果、多轮对话记录都会占用不少token。如果模型上下文窗口太短，代理会“忘掉”早前的工具返回结果，导致任务规划混乱。我在配置里会把num_ctx显式设置到至少8192，有条件的可以到16384，宁可牺牲一点推理速度，也要保证代理在复杂任务里不出错。

6. 把AI代理接到ROS机器人：从“处理文字”到“控制实体”

现在AI代理的应用早就超出了纯文本问答的边界，结合机器人操作系统（ROS）做“让代理驱动实体设备”的演示，已经成了很多智能制造和自动化类项目的新方向。网上经常能看到“OpenClaw + ROS为你的AI代理”这类热词，本质上就是把代理从“只能调用软件工具”扩展到“可以操作物理设备”的探索。

6.1 代理与ROS的架构衔接逻辑

如果客户项目里有机器人、机械臂或无人车这类实体设备，AI代理的演示价值就不只在“对话”和“任务编排”上，而是体现在“让代理能根据自然语言指令，直接规划并执行一连串物理动作”。

这个架构的衔接逻辑大概是：代理端负责拆解用户的目标型指令，把任务分解成多个可执行步骤；每个步骤对应一个或多个ROS动作，通过ROS服务调用或者action通信机制下发；ROS端负责接收代理下发的目标指令，把指令映射成真实设备的具体控制命令；执行过程中，设备状态和传感器数据再实时回流给代理，作为它继续规划下一步的输入。

从客户复现的角度来看，这个链路的复杂度比纯软件场景高出一截，因为多了一层硬件和通信机制。但演示价值也更高——客户明显能感受到，这套东西的能力边界已经从“帮你整理资料”扩展到了“替你操作设备”。

6.2 实战配置示例与通信原语选择

在ROS侧，最常用的通信方式有topic、service和action三种。AI代理在任务规划时通常需要的是“发起一个任务、确认任务是否完成、拿到执行结果”这类的同步交互，所以service和action是最常被用到的。

如果代理只需要触发一个单次任务（比如“把机械臂移动到位置A”），service就够用。如果任务需要在执行中持续反馈进度（比如“沿着路径巡检一圈，遇到障碍停下来报告”），那就得上action机制才能避免通信超时。

一个粗略的架构示意可以这样写：

# 代理侧：通过ROS service触发机械臂控制 from std_srvs.srv import Trigger import rclpy from rclpy.node import Node class AgentRosBridge(Node): def __init__(self): super().__init__('agent_ros_bridge') self.cli = self.create_client(Trigger, '/arm_goto_home') def send_go_home(self): req = Trigger.Request() future = self.cli.call_async(req) return future

这种写法在真实项目中很常见：代理不直接面对底层的运动控制细节，而是面对一个封装好的ROS服务接口。代理只需要描述“我要让机械臂回初始位”，ROS服务端会负责解析成实际的控制指令。

6.3 给客户演示物理设备时的安全提示

任何涉及真实硬件的演示，安全优先级一定排在效果前面。我的经验是三条：一是所有实体设备的第一步演示，必须走“虚拟仿真环境”验证链路，Gazebo这类仿真器里跑通了再切真实设备；二是真实设备上执行任何动作前，要确认急停开关和安全围栏就位，这个当面确认比任何约定都重要；三是代理在规划动作时要加一层硬性的参数校验，比如“最大移动速度”“最大关节角速度”这类安全参数，必须由ROS端的参数服务器统一下发，不允许代理直接控制。

虽然这些内容略显基础，但客户自己动手时很容易为了追求“效果震撼”而忽略了安全冗余。作为支持方，我们有责任在动手前把这些安全底线讲清楚，这也是专业性的直接体现。

7. 客户复现时的高频问题与排查技巧实录

最后这部分，是我把几次客户动手环节的常见问题整理成的速查表，全是实战中真实出现过的，考虑按这个表格来做现场支持，能省掉大量来回拉扯的时间。

这些问题的共同根源，绝大多数不是客户操作失误，而是我们在准备复现包时遗漏了某个场景。所以我把排查技巧的第一条永远留给准备环节：客户开始复现之前，自己先把文档走一遍，用一台全新环境，严格按文档跑一次完整流程。这个“干跑”过程虽然枯燥，但能拦下大约七成的复现期疑难问题。

再补充一个我经常用的小技巧：在文档里明确标记哪些命令是“在项目根目录执行”的。省去路径猜测这一步，客户执行命令的成功率会有非常明显的提升。

写在最后的一个体会

这几轮AI代理演示与客户复现做下来，我最大的感受是：这个领域正在从“看热闹”快速走向“看门道”。客户已经不太满足于听你讲“我们的AI能做很多事”，他们更倾向于自己动手确认“这个AI到我们手里还能不能做成事”。

所以我的经验是，演示方案里真正值得花精力的部分，已经从“把效果调好”转移到了“把复现路径铺平”。你代码写得再漂亮、模型调得再准，不如让客户在你的沙盒环境里亲手跑通一次。那种“原来我也能把它跑起来”的体感，比任何话术都有说服力。

如果你也正在准备类似的客户演示，我的建议是：先自己用一台干净电脑，严格按你写的复现手册从头到尾做一遍，然后你大概率会发现，需要优化的不是你的代码，而是你的手册。