企业官网建设流程全解析

做智能体（Agent）开发的朋友，大概率都有过这样一种体验：在开发环境里，你的Agent跑得行云流水，逻辑清晰、工具调用精准、回答有条有理；一旦把它部署到服务器上开始面向真实用户，各种问题就冒出来了——响应变慢、上下文错乱、工具调用超时、模型偶尔还"发疯"。我最早做Agent项目时也是这样，花了一个月把Demo写出来，又花了快半年时间才把"能跑"变成"稳定跑"。这篇就来聊聊智能体部署与运维这件事。

说实话，"部署"和"运维"这两个词放在普通后端服务上，大家都熟，无非就是容器化、监控、日志、告警那一套。但智能体这个东西，它的运行时比普通Web服务多了一层非常关键的变量——大语言模型推理。这一层变量直接改变了部署和运维的玩法。模型推理是不确定性的，同一个输入、同一个模型参数，每次输出都可能不一样；模型推理也是昂贵的，一次对话动辄几秒钟的GPU计算；模型还有上下文窗口限制，承载不了无限对话。

所以智能体部署与运维的核心问题，可以概括成四个：模型怎么放、框架怎么选、服务怎么编排、异常怎么兜底。这篇文章不绕弯子，直接讲我实际部署和运维Agent项目时用到的架构方案、工具选择和踩坑记录，既有原理分析也有实操命令，希望能帮正准备把智能体从实验环境搬到生产环境的朋友少走点弯路。

1. 部署前必须想清楚的四个问题

1.1 你的Agent到底跑在哪一层

先把概念理清楚。一个生产可用的Agent系统，至少包含四层：

1. 大模型推理层——负责生成回复、决策下一步动作，通常由Ollama、vLLM这类推理引擎或者云端API提供。
2. Agent编排层——负责"思考-行动-观察"循环，比如ReAct模式的循环逻辑，由LangChain、Dify这类框架或者自研代码实现。
3. 工具调用层——Agent要访问的外部能力，比如搜索、数据库查询、内部系统API。
4. 应用接入层——面向用户的产品界面或API网关。

很多人在部署时只盯着第2层，把Agent框架的代码打包成容器就以为完事了。实际上，第1层才是决定整个系统稳定性和成本的关键。模型推理的延迟、并发承载能力、上下文长度，直接决定了Agent能不能在真实场景下用起来。

我在和很多做Agent的朋友交流时发现，大家最容易犯的毛病是：开发的时候用云端大模型API，不需要考虑推理资源，但上线后一查账单发现成本失控；或者反过来，坚持本地部署模型，结果一台GPU机器扛不住几个并发对话，用户体验极差。

所以部署前的第一个任务，不是写Dockerfile，而是把上面四层清晰地列出来，明确每一层用自研、开源还是托管服务，然后逐一估算资源需求。

1.2 画清楚调用链，才能定SLA

智能体有个和普通服务非常不同的地方：一次用户请求，往往不是一次模型调用就能完成的，而是"模型思考→调用工具→观察结果→再次模型思考→……→最终回复"的多轮循环。假设一次任务需要3轮模型调用，每轮模型调用平均3秒，再加上2次工具调用的网络延迟，用户要等到最终回答可能就需要10秒以上。

上线前把这个链路画出来非常有必要，因为每个环节都有不同的失败模式：

• 模型推理可能超时或返回空结果。
• 工具调用可能因为网络、鉴权、参数错误而失败。
• 多轮循环可能无限执行，陷入死循环。

不同环节的失败，需要完全不同的兜底策略。比如模型超时可以用重试，工具调用失败可以换一个等价工具，死循环需要设置最大迭代次数。这些如果没有在部署前设计好，上线后就会变成满屏报错，运维无从下手。

1.3 先算账：本地推理还是云端API

这个问题没有人能替你回答，但有一套判断逻辑可以参考。我给出一个对比表：

我个人的经验是：如果是内部工具类Agent，数据敏感、调用量比较稳定，本地推理更合适；如果是面向公众的客服、营销类Agent，需求波动大、需要快速上线，优先考虑云端API，等业务量稳定后再评估是否自建。

还有个折中方案值得推荐：用云端API跑在线推理，但所有Prompt、知识库、工具调用都经过自己的网关，这样以后想切换到本地模型，只需要改一个模型Endpoint配置，整个架构不用动。

2. 模型推理层的部署实操：Ollama与vLLM怎么选

2.1 推理引擎的选型逻辑

模型选好之后，跑推理的引擎也很关键。现在最常见的开源推理方案有三个：Ollama、vLLM、llama.cpp。

• Ollama：安装简单、开箱即用，自带模型管理和HTTP API，适合单机部署、快速验证，也是很多Agent框架本地默认集成的方案。
• vLLM：吞吐量高，支持PagedAttention连续批处理，适合多用户并发，但要自己做模型加载和API封装，技术门槛更高。
• llama.cpp：CPU环境也能跑，支持各种量化方案，适合没有GPU或者异构设备的场景。

如果Agent项目刚开始、并发不高、单台服务器搞定，Ollama足够。如果并发上来了，比如同时跑20个会话，Ollama的连续请求处理就会显得吃力，这时建议换成vLLM或者加几台推理节点。

我实际测试过，在一台多卡服务器上，同样的模型，Ollama做单会话流式输出体验很好，但一旦多会话并行，Token吞吐量明显下降，响应开始排队；vLLM的连续批处理可以显著提高吞吐，代价是配置复杂度上去了。这几年开源模型进步很快，DeepSeek、通义千问、Llama这些系列都在长期维护不同尺寸的本地模型，部署成本已经比早期低了很多，自建推理层的门槛其实越来越低了。

2.2 Ollama部署中容易被忽略的三个参数

很多人部署Ollama就是官方一键安装脚本跑完，然后就能跑了。但如果要接入Agent框架服务，有三个细节必须处理。

第一，默认监听地址。Ollama安装后默认只监听127.0.0.1:11434，如果你把Ollama和Agent服务部署在同一台机器上没问题，但要跨机器访问就必须改环境变量OLLAMA_HOST=0.0.0.0。这个改动别放进应用代码里，应该写在Ollama服务的systemd配置或容器环境变量中。

第二，模型加载和卸载策略。Ollama默认会在GPU和CPU之间做模型调度，当显存不够时会自动把部分层卸载到CPU，速度会明显变慢。如果业务不能接受，需要手动控制同时加载的模型数量，或者提升OLLAMA_NUM_PARALLEL，让一个模型副本服务多个并发的请求，减少重复加载模型到显存的开销。

第三，上下文长度限制。Ollama调用时如果没指定num_ctx，默认上下文可能只有2048或4096个Token，对Agent场景完全不够用。Agent一轮任务在思考、工具调用、结果观察之间来回，上下文很快就会被撑满。我在部署时一般显式设置num_ctx为8192以上，具体值以模型支持的最大上下文和GPU显存做权衡。

下面是一个比较稳的Ollama调用示例：

ollama run qwen2.5:14b --keepalive 30m \ --num-ctx 8192 --num-predict -2

其中--keepalive 30m表示模型加载后在显存中保留30分钟，避免频繁加载卸载；--num-predict -2是不限制生成长度，让Agent可以完整输出工具调用结果。

2.3 GPU资源不够时的降级方案

不是所有人都有好几块高端显卡。如果你的服务器只有一块消费级显卡甚至只有CPU，我的建议是：

• 优先选择量化模型，从fp16换到int8甚至int4。视觉上推理质量会有一定下降，但显存占用能减少一半以上。以14B模型为例，fp16大约需要28GB显存，int4量化后差不多7GB就能跑，体验差异对于多数Agent任务是可以接受的。
• 如果连7GB都没有，就换更小参数的模型。Agent的编排能力对模型智商的要求其实没有想象中那么高，很多工具调用、信息抽取任务用7B模型也能完成，只是复杂推理链路需要更大的模型兜底。
• 用CPU推理要控制并发数，llama.cpp在CPU环境下单会话慢但稳定，可以优先搭建在内部低频使用的Agent上。
• 如果你要在RK3588、Jetson这类边缘设备上部署，资源预算更紧张，量化几乎是必选项，同时建议把Agent编排层和推理层分开，推理跑在边缘设备，编排和工具调用留在服务器。

3. Agent框架选型：自研编排还是上平台

3.1 三种主流路线的取舍

Agent框架这一层的选择，直接决定了后续部署和运维的复杂度。我见过的大致有三条路线：

• 路线一：直接使用LangChain、LlamaIndex这类代码库，在自己项目里编排Agent循环。灵活度最高，但你要自己处理模型调用重试、工具异常、状态管理等一堆细节。
• 路线二：用Dify、Coze这类可视化的Agent平台，在Web界面上编排Agent流程，平台会帮你处理很多运行时问题。上线快，但定制能力和性能调优空间有限。
• 路线三：自研一个极简的Agent循环，只有"系统提示词+模型调用+工具函数调用+循环控制"。对工具型Agent来说，这反而最可控。

我的建议是，如果是一个团队要交付长期维护的生产系统，优先考虑路线一或路线三，配合自己的监控体系。平台型方案适合做Demo和内部工具，因为平台的黑盒会让你在排障时很难定位问题。比如Dify托管的Agent，一旦出现某轮工具调用异常，你很难看到内部的完整上下文状态，只能靠平台日志凑合排查。

3.2 一个自研Agent循环的骨架

我自己在项目里用的Agent循环很朴素，核心就四步：

1. 把用户消息、历史对话、可用工具列表组装成请求发给模型。
2. 模型返回结果，判断是最终回答还是工具调用请求。
3. 如果是工具调用，执行对应工具，把结果作为新一轮消息发回给模型。
4. 重复，直到模型给出最终回答或达到最大轮数上限。

这个骨架部署起来几乎没有框架依赖，核心逻辑只有几百行。但它有几个必须做好的事情：每轮都要检查上下文长度，防止超出限制；工具调用的入参要做JSON解析容错；所有轮次的输入输出都要记录日志，方便事后排查。

3.3 环境隔离：Python依赖和模型权重是两套东西

框架选型完之后，环境搭建上有个很常见的坑：Agent代码会用到大量的Python包，比如langchain、openai、httpx、pydantic，版本冲突几乎是必然的。我部署过不止一次，因为pydantic版本不兼容导致整个Agent服务起不来。

这个问题的根治办法就是容器化。把所有代码依赖打包进Docker镜像，锁死版本。模型权重文件不要打进应用镜像，单独放在数据卷或模型仓库中，这样升级模型版本和应用代码的节奏可以分开，互不干扰。

4. 容器化部署：一套可复用的Docker Compose编排

4.1 基础编排示例

下面给出一个我实际用过的Docker Compose骨架，包含Agent应用、Ollama推理服务、Redis三个组件：

version: "3.8" services: agent-app: build: . ports: - "8080:8080" environment: - LLM_BASE_URL=http://ollama:11434/v1 - LLM_MODEL=qwen2.5:14b - REDIS_URL=redis://redis:6379 - AGENT_MAX_ITERATIONS=5 depends_on: - ollama - redis restart: unless-stopped ollama: image: ollama/ollama:latest volumes: - ollama_models:/root/.ollama deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] environment: - OLLAMA_HOST=0.0.0.0 restart: unless-stopped redis: image: redis:7-alpine volumes: - redis_data:/data restart: unless-stopped volumes: ollama_models: redis_data:

这个编排里有几个细节说明一下：

• depends_on只保证服务启动顺序，不保证Ollama里的模型已经加载好，所以Agent应用里要有对模型Endpoint的健康检查，发现模型没加载就先拉取再调用。
• deploy.resources.reservations.devices是Docker Compose里透传GPU的标准写法，前提是安装了NVIDIA Container Toolkit。
• Agent应用里所有重试、缓存都走Redis，比单机内存状态可靠得多，也方便多副本部署时共享会话状态。

4.2 GPU透传和资源限制

GPU透传是容器化部署智能体最容易翻车的地方。我遇到过的情况是：容器起来了，代码也能跑，但就是慢得离谱，一看日志发现模型实际运行在CPU上，GPU根本没用上。排查半天，发现是宿主机NVIDIA驱动版本和容器内CUDA版本不匹配，容器内CUDA加载失败，Ollama自动回退到了CPU。

检查GPU是否真正被容器用到，可以在容器内执行nvidia-smi，如果输出了GPU信息，说明透传成功；如果报错或者显示N/A，就要检查驱动层。

此外，一定要给Agent应用容器设置内存和CPU限制。模型推理进程本身就是内存大户，再叠加Agent应用进程，如果两者在同一个宿主机上互相抢内存，很容易触发OOM。我一般给应用镜像限制2GB内存，给Ollama容器留足够显存和系统内存，这样即使应用异常也不至于拖垮推理服务。

4.3 开发环境和生产环境的差异管理

开发环境跑Agent，通常是一个进程直接起，模型API指向云端或者本地，环境变量写死在.env里。生产环境就完全不一样了，密钥管理、配置中心、日志收集系统、链路追踪全部要接上。

我的经验是，在代码里把配置全部抽象成环境变量，禁止在代码里写任何默认密钥和Endpoint。业务上需要区分开发和生产环境的配置，放在不同的.env.production、.env.development文件里，部署时由部署脚本指定加载哪一份。

还有一个小坑：很多Agent框架在开发模式下会自动重载代码，这个特性在生产环境一定要关掉，否则某个文件被编辑器保存一下，整个Agent进程就会重启，正在处理中的用户请求全部中断。

5. 生产运维的核心：给智能体建立可观测性

5.1 日志：记录每一轮"思考-行动-观察"

普通Web服务的日志，记录了请求来了、参数是什么、结果是什么就足够了。智能体不行，你得能复盘"模型当时在想什么、决定调用哪个工具、工具返回了什么、模型看到结果后又怎么反应"。

我强烈建议在Agent循环的每一轮都输出结构化日志，至少包含：

{ "trace_id": "abc123", "session_id": "session-001", "iteration": 2, "stage": "tool_call", "model_input_tokens": 3200, "model_output_tokens": 120, "tool_name": "search_order", "tool_args": {"order_id": "20240101"}, "tool_result_summary": "找到订单，状态为已发货", "latency_ms": 850 }

有了这个结构，你才能在出问题时快速定位是第几轮出了岔子、是哪一步的参数不对劲。如果只记一行"调用模型成功"这种日志，事后排查等于盲人摸象。

日志还要注意一点：不要把完整的工具返回结果和Prompt原样打出来，尤其是涉及业务敏感信息的部分。可以用摘要、脱敏字段替代，否则日志系统本身就会变成数据泄露的源头。

5.2 指标：从Token消耗到工具调用失败率

智能体运维不能只看CPU和内存，还要盯一组Agent特有的指标：

• 每会话平均模型调用轮数。正常情况下应该在2到5轮之间，如果这个数值突然飙升，八成是Agent进入了无效循环。
• Token消耗速率。这是成本的核心指标，按模型、按租户、按工具分别统计，能帮助判断成本花在哪里。
• 工具调用成功率。某个工具失败率高，可能不是Agent的问题，而是下游系统的接口不够稳定。
• 模型输出格式异常率。模型偶尔会输出不符合约定的JSON，这个比例超过一定阈值，就该考虑换模型或加一层结构化输出纠偏。

这些指标用Prometheus那套体系就能打。Agent应用自己暴露/metrics端点，记录这些自定义指标，比只做基础资源监控有用得多。

5.3 告警与自愈

我自己的告警策略分三档：

• 第一档，即时告警：工具调用连续失败超过5次、Agent单个请求耗时超过30秒、Token消耗速率超出预算阈值，这几个一旦触发立即通知。
• 第二档，分钟级告警：模型调用失败率超过5%、GPU利用率长时间为0（说明模型可能掉到CPU跑了）、会话错误率升高。
• 第三档，日级巡检：每天跑一遍全链路测试用例，比如给Agent发几条固定指令，验证工具调用和知识库检索是否正常。

自愈方面，最简单的兜底就是"重试+降级"。模型调用失败就重试两次；工具调用失败就尝试备用工具；Agent循环超时就把当前的中间结果保存并返回部分回答，总好过让用户白等半天然后收到一个错误。

6. 三起让我印象深刻的线上故障排查实录

6.1 案例一：上下文被工具返回结果撑爆

有一次线上Agent突然出现大量报错，错误信息大致是"context length exceeded"。我查了日志，发现问题出在一个数据库查询工具上，它把一个超大字段的完整内容返回给了模型，直接撑爆了上下文窗口。

排查链路很简单：先确认报错集中在哪个工具调用之后，再检查该工具的返回内容长度。修复方案分两层。第一层，在工具层对返回内容做截断和摘要，限制单次返回Token数。第二层，在Agent循环加一个自我保护，每次组装请求前检查当前上下文的Token占用，超过阈值就先做历史消息压缩，丢弃不重要的早期轮次。

这个案例给我的教训是：智能体的上下文窗口是共享的稀缺资源，每一个工具的返回内容都在悄无声息地消耗它。工具返回不做限制，模型再大也扛不住。

6.2 案例二：工具调用超时，用户端表现成"AI在胡说"

第二个案例更有意思。某天用户反馈说Agent回答得驴唇不对马嘴，明明订单还没发货，Agent却告诉用户"已经发货，请耐心等待"。表面看像是模型幻觉，但排查后发现根本不是。

日志显示Agent调用订单查询工具时，工具接口响应超过了Agent设置的超时时间，Agent收到的是空结果。但模型在空结果的情况下继续推理，它没有明确说"查不到数据"，而是顺着用户的问题"圆"了一个看似合理的回答。

这个问题暴露了两件事。第一，工具接口的超时时间必须小于Agent循环整体的超时时间，否则就会出现"工具还没返回，模型却开始编答案"的窗口。第二，模型拿到空结果时必须被教导怎么表达"不知道"。我在系统提示词里明确加了一条规则：如果工具调用没有返回有效数据，你必须直接告诉用户暂时无法获取信息，禁止猜测或补充细节。

修复后这类问题基本绝迹。这让我意识到，很多所谓的"模型幻觉"，根源其实在工程层——上游数据缺失了，但系统没有建立一个"缺失即如实告知"的机制。

6.3 案例三：多副本部署下的会话状态漂移

第三个坑发生在把Agent从单副本扩展到多副本后。一开始只是偶发出现用户抱怨"刚才我改了需求，你忘了吗"，Agent表示不记得。我以为是模型上下文问题，后来抓包发现，前一个副本处理的会话状态存在本地内存，后一个副本根本读不到。

排查过程是这样的：先看日志，发现同一个会话ID的请求落到了不同Pod；再看代码，确认会话历史的存储介质是进程内存，没有走Redis；然后恍然大悟，多副本下会话状态当然不可见。

修复方案就是前面说的，会话状态统一放Redis。另外需要注意，如果要保证同一个会话始终由同一个副本处理，可以在负载均衡层做会话粘滞，但更稳妥的做法还是把状态放到外部存储，让每个副本都是无状态的。

这个案例其实很典型。很多人部署单体应用习惯了，内存就是天然的共享状态，扩到多副本后各种诡异问题就冒出来了。

7. 版本升级与灰度：智能体的"更新"为什么比普通服务麻烦

7.1 Prompt、工具定义和模型权重都是"代码"

普通服务发版，改的是Java或Python代码。智能体发版，要改的东西多得多：系统提示词、工具定义、工作流配置、模型版本甚至推理温度参数，每一项变了对线上行为的影响不亚于一次代码重构。

我在项目里建立了这样的机制：Prompt和工具定义先用配置文件托管在代码仓库里，走和代码一样的评审和发布流程。不要允许运维直接在线上改Prompt，否则一个写着"你是什么都能做的小助手"的线上Prompt，可能同时存在三个版本，谁也说不清哪个生效。

7.2 灰度策略要按会话维度切，而不是按请求维度切

智能体是有状态的应用，一个会话可能横跨多轮对话。如果灰度切换按请求维度随机分配，就会导致用户同一个会话里一会儿走新版逻辑一会儿走旧版逻辑，体验非常分裂。

我建议按会话维度做灰度，比如内部测试账号全部走新版，外部用户先放5%的流量到新版，观察指标后再逐步放大。放量过程中重点观察每个会话的模型调用轮数、工具失败率、用户投诉反馈。如果新版工作流的工具成功率明显低于旧版，就立刻回滚，再排查原因。

还有一个容易忽略的点：灰度切换只影响新会话，已经开始的旧会话保持原逻辑跑完，避免中途改道导致上下文断裂。

7.3 回滚预案里必须包含"模型回滚"

做智能体运维，一定要有模型版本的概念。升级模型意味着API调用参数、输出格式、上下文宽度可能一起变化，这些都可能在线上引发新问题。

我现在的做法是：每次更换模型版本或刷新系统Prompt，先保存一份当前版本的完整快照，包括模型名称、推理参数、Prompt文件、工具定义。一旦线上出现异常，可以在几分钟内把整套配置回滚到上一个快照，而不是手忙脚乱地去翻聊天记录。

这个"可回滚快照"是我在运维智能体项目中学到的最有性价比的一个机制。

写到这里，我把智能体部署与运维的几个核心环节——模型推理层、Agent框架层、容器化编排、可观测性、故障排查、灰度发布——都过了一遍。我自己的体会是，智能体运维和传统运维最大的区别在于：传统运维守护的是"确定性的系统"，而智能体运维守护的是一个"由不确定的模型输出驱动、串联了外部工具和上下文的复杂系统"。后者没有银弹，只能在每一层都做好可观测、可重试、可回滚，剩下的就是上线后跟着日志和指标不断打磨。

最后再分享一个我觉得特别实用的小习惯：给每一条线上反馈都建立一个"复现用例"。用户说Agent答错了，先别急着改Prompt，而是把这个对话过程存下来，回到测试环境里用同一套模型和参数复现。能在本地稳定复现的问题，才谈得上真正修复。这条经验帮我省掉了无数"改了但不知道有没有用"的无效优化。希望这篇内容能让你在部署第一个线上Agent时少走点弯路。