企业官网建设流程全解析

把AI Agent部署到自己机器上这件事，我从最初“图新鲜跑个Demo”到后来真正把它变成自己电脑里一个能干活、能检索、能按指令跑流程的“数字员工”，前后踩了不少坑。这篇就和你聊聊，我是怎么从零开始把AI Agent本地部署起来的，包括框架选型、模型搭配、实际部署步骤，还有那些文档里不会明说的代价和细节。

这篇文章适合三类人看：一是个人开发者，想在自己本子上搭一套不吃外部流量的Agent环境；二是中小企业IT或数据敏感岗位，资料不能出内网，但还想用上Agent能力；三是只听过概念还不清楚“本地部署到底难不难”的新手。我会尽量把每一步都写在代码和配置层面，不绕弯子。

1. 动手前先想清楚：你的“数字员工”到底要干什么

1.1 本地部署的价值不是“免费”，而是数据主权与可定制性

很多人一听到“本地部署AI Agent”，第一反应是省钱。我得先泼一盆冷水：本地部署并不一定比云端的API便宜，尤其是你认真买显卡、跑服务、维护环境之后，隐性成本一点不少。真正让本地部署不可替代的原因，是数据和流程的自主权。

举个例子，我手里的一个需求场景：公司内部有大量技术文档、历史会议纪要和运维手册，团队想做个回答助手。这些资料直接丢到云端的模型API里，是过不了安全评估的。更现实的问题在于，Agent需要被授权去读取本地数据库、执行特定脚本、操作内部系统，这些动作一旦放到公有云上，就完全是另一回事了。所以本地部署从头到尾的核心诉求，不是“更省钱”，而是“我能在不把家底交出去的前提下，把Agent和已有的系统绑在一起”。

另一个价值是可控性。你在云端有一个大模型接口，它能跑什么函数、走什么工具、行为边界在哪，你想调整但改不动，厂商提供什么能力你只能用什么。本地部署则可以把Agent规划、调用工具、上下文管理这些环节全部拆开来看，按自己的业务逻辑拼装。

1.2 哪些场景适合本地跑，哪些并不适合

先说适合的：

• 知识库问答型：把企业内部资料库喂给Agent，让它基于指定文档回答，不依赖外网。
• 自动化办公流程：例如定时汇总日志、解析邮件附件、生成周报，这些属于业务流程固定、数据敏感的活儿。
• 工具编排：Agent根据指令调用本机脚本、执行SQL查询、操作低代码平台，没有公网依赖。
• 学习研究和二次开发：想理解Agent内部机制、做模型微调、自定义推理逻辑，本地是最佳试验场。

不适合本地跑的我也要提一句：如果你的任务是高难度通用推理、长文本创作、多模态大图理解，本地小尺寸模型目前效果还是会明显弱于顶级云端模型。硬要在16G显存上跑一个70B模型然后吐槽效果差，那是没有意义的。务实一点，本地模型负责私密数据和重复工作，通用高阶任务可以走云端API，两者并行并不冲突。

我自己就一直在用“本地模型+云端API混合”的方案：核心数据相关流程走本地Qwen或DeepSeek系列模型，遇到复杂分析和无数据约束的需求，再转发给云端更强模型。这是目前性价比最高的使用方式。

1.3 什么是“数字员工”的完整能力闭环

顺着这个思路往下说，一个真正能干活儿的数字员工，至少要有三层能力：

1. 理解指令：能把“把本周设备告警整理成表格发我”翻译成拆解步骤和关键参数。
2. 调用工具：能连接你本地的数据源、脚本、API，甚至操作浏览器和桌面软件。
3. 自主执行并检查结果：按步骤执行任务，如果中途报错，能自己判断错误类型并重试或调整。

这三层能力在本地部署场景里分别对应着：本地大模型、Agent框架、工具集。很多人部署Agent只关注“模型跑起来了”，却没有搭建工具链路，最后的Agent只会聊天不能干活，跟普通聊天机器人没区别。这也是为什么文章标题里强调的是“数字员工”，而不只是“本地聊天机器人”。

2. 整体架构与选型解析：四层结构搭建认知框架

2.1 一条完整链路由四层组成

我习惯把本地Agent拆成四层看待，逐层排查问题时特别方便：

1. 底座层：大模型推理环境。可以是Ollama、LM Studio、llama.cpp、vLLM等，负责加载模型并对外提供对话接口。
2. 编排层：Agent逻辑的核心，负责“理解用户意图、拆解任务、决定调哪个工具、把工具结果汇总成答案”，典型如Dify、FastGPT，或者自己写Python调度逻辑。
3. 工具层：知识库、向量数据库、脚本、API连接器等。Agent要干具体事情就靠这一层。
4. 交互层：Web页面、API服务、命令行或者IM机器人，这是让人能和Agent对话的入口。

判断一个Agent方案是否成熟，就看它能否独立升级每一层。比如底座层从7B模型换成14B模型，其他层不需要动；工具层增加一个查询接口，编排逻辑不变。如果做不到这点，那我建议底层方案别选。

2.2 模型底座选型：本地模型不是越强越好

本地模型选择，我见过太多人一上来就追求“大”——问哪个模型好，答案永远是“能装下多大装多大”。但实操里面，模型能不能跑得动、响应速度够不够、是不是适配你的Agent框架，比绝对智商要重要得多。

这里给出我实际测过的几类模型定位：

一个重要心得：本地Agent能力的短板往往不在“知识”而在“指令遵循”。模型不会因为你问它“太阳从哪升起”回答错，但会在“从这些步骤中只执行第2步”这种复杂指令上掉链子。所以选择模型时，不只看评测分数，更要测试它对工具调用的理解。我会拿一段真实的工具调用指令去跑，模型能不能稳定输出结构化动作，这是硬指标。

2.3 编排层选型：从“可视化编排”到“自己写代码”

现在的Agent编排层，路线分化得比较清晰。一种是图形化低代码平台，像Dify、FastGPT、MaxKB，好处是上手快、知识库和工具配置开箱即用，很适合非纯技术背景的人。另一种是自己写调度代码，用LangChain或干脆手写Agent循环，灵活度高，能精细控制每个环节的逻辑，但开发和维护成本明显更高。

我自己的建议非常明确：如果你第一次搭，直接选图形化平台起步，别一上来就自己撸代码。因为Agent本身链路长，牵扯到模型请求、工具返回、上下文管理、异常处理，自己从零写容易把大量时间花在调试非核心问题上。图形化平台能让你先跑通一个完整的Agent流程，建立“它能干哪些活”的体感，之后再按需迁移或手写。

在我试过的工具里，Dify是最适合本地部署起步的：社区活跃、模型接入灵活、自带知识库和Agent工具功能，Docker Compose一键启动，对个人电脑非常友好。它对应的标签就是本地部署热门关键词“dify本地部署教程”搜到的那种方案，干净、完整，没有云平台绑定。

2.4 工具层的新标准：Function Calling与MCP协议

Agent要调用工具，早期做法是把各种函数塞进Prompt里让模型判断该用哪个，效果不稳定。后来OpenAI定义了Function Calling，让模型在对话中输出结构化工具调用参数，这套思路已经成了行业事实标准。本地部署的好处在于，你完全可以自己定义工具函数，让自己的Agent去调用。

再往深一步说，这两年工具调用领域出现了更进一步的协议化方向——MCP，它把“如何连接外部工具”标准化了。你可以把Agent理解成电脑，MCP就是USB接口，只要设备支持USB协议就能即插即用。一旦某个本地服务暴露成一个MCP工具，所有支持MCP的Agent都能直接接入，不用每个单独开发适配器。

在本地部署场景里，我更推荐的路径是：先把手头的核心工具做成普通API或脚本，Agent用Function Calling方式调用；之后遇到工具数量上来了，再逐步用MCP规范整理。没有工具接入的Agent只是一个“高级问答机器”，这句话请画重点。

3. 场地准备：硬件评估、推理环境与本地模型部署

3.1 硬件门槛到底要多高

“本地部署大模型”听起来吓人，其实硬件门槛并没有想象中那么高。关键看你跑什么规模的模型、对响应时间的要求是多少。

按我的经验，可以简单划分为三档：

• 入门档（CPU+16G内存）：能跑3B-7B的量化模型，回答速度大概每秒2-5个字，适合测试Agent链路，体验不算好但在能用的边缘。
• 标准档（8GB-16GB显存GPU）：这是最推荐个人用户优先达到的配置。能流畅跑7B-14B量化模型，回答速度和推理质量都比较平衡，数字员工日常任务够用了。
• 进阶档（24GB-48GB显存）：能上32B级或者更大模型，适合对本地推理质量有更高要求的团队。一块48GB的专业卡在二手市场都不便宜，这也是我建议团队评估时认真算账的原因。

一个很容易踩的认知误区是，只盯着显存，忘记内存带宽。实际上，CPU推理时，内存带宽决定了你的Token生成速度；GPU推理时，显存容量决定模型能不能放得下。买配置之前，先明确要跑哪个尺寸的模型，再倒推硬件需求，顺序不能反过来。

3.2 推理框架选型与评估标准

模型推理框架我推荐从Ollama入手。理由只有一条：它把“下载模型、启动推理、提供API”全流程简化到了极致，而且内置的模型库兼容大量开源模型。本地部署新手用它能少走至少两小时弯路。

当然，框架不是只有一个。LM Studio适合喜欢图形界面管理模型的人；llama.cpp适合想在纯CPU或极小内存环境运行的场景；vLLM则面向高并发、生产级API服务。它们的核心差异在于：

还有一个关键点：不管用哪个框架，理想情况下你都应该让模型暴露一个兼容OpenAI接口格式的入口。这样上层Agent框架接入时，只需要替换base_url和api_key两个参数，不需要修改任何业务代码。Ollama默认就提供了这种接口，这也是我推荐它作为第一步的另一个原因。

3.3 实测操作：用Ollama在本地跑起第一个模型

下面是我实际把Ollama跑起来的过程，每一步都贴出来供你复现。

先在Linux环境执行Ollama安装（macOS和Windows可以直接去官网下载安装包，过程更简单）：

curl -fsSL https://ollama.com/install.sh | sh

安装完成后，确认服务状态：

ollama --version ollama serve

如果ollama serve已经在后台运行，说明服务起来了。接下来拉取一个模型。中文场景我优先推荐Qwen2.5系列，以7B模型为例：

ollama pull qwen2.5:7b

首次拉取会下载大概4.7GB左右的模型文件，时间取决于你的网络条件。拉取完成后，键入下面命令进入交互式对话：

ollama run qwen2.5:7b

输入一个问题测试基础对话能力后，退出交互模式。这时我们可以用Python脚本测试OpenAI兼容接口：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", ) response = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "用一句话介绍你自己"}] ) print(response.choices[0].message.content)

如果这里能正常输出，说明你本地的“大模型底座层”已经就绪。之后所有上层Agent框架都只需要对接这个地址，而无需再关心模型放在哪里。

必须提醒的一点：拉取模型时你先看一眼模型文件大小，确认磁盘空间够不够。模型文件动辄几个GB，磁盘写满会导致推理异常甚至数据损坏。我一般预留至少两倍模型体积的空闲空间。

3.4 为什么在Agent场景里，模型服务必须保持常驻

很多人用Ollama跑完对话就关掉，等到用Agent时再开。测试阶段没毛病，但真实用起来就会发现很不现实：Agent的任务可能是定时触发的，你可能在Web界面里正聊着天，突然后台任务也要调用模型，如果服务没有常驻，整个数字员工就变成了“只在开机时上班的员工”。

我建议把模型推理服务注册成系统服务，让它开机自启。以Linux systemd为例，配置文件大致长这样：

[Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve Restart=always RestartSec=3 Environment="OLLAMA_HOST=0.0.0.0" [Install] WantedBy=default.target

我让Ollama监听所有地址，是为了让局域网内其他设备——比如同一办公室的其他电脑——也能访问同一个本地模型服务。这里要特别小心，一旦开放局域网，务必用防火墙限制访问来源，只放行办公网段，不要裸奔到公网。模型接口没有任何鉴权机制，暴露到公网等于把自己的算力免费送给扫描器。这个坑我见过不止一次。

4. 核心环节：用Dify本地构建你的第一个数字员工

4.1 为什么选择Dify作为编排层

如果你去搜索“dify本地部署教程”，会发现Dify在中文社区里的讨论度这几年确实很高。真正用下来之后，我能理解它为什么受欢迎：

• 自带可视化Agent编排界面，通过拖拽就能定义节点、串联流程。
• 内置知识库能力，可以直接上传文档、分段、向量化，不需要额外先搭一套RAG组件。
• 工具接入标准，既能调用内置工具，也支持自定义API工具和MCP扩展。
• 本地部署友好，Docker Compose一键启动所有依赖，不用手动安装PostgreSQL、Redis、向量数据库等一堆中间件。

对我而言，它最核心的价值是“快速试错”——我今天想让Agent增加一个查询日历的入口，不需要重新开发，直接在管理端注册一个OpenAPI Schema工具就行。这种体验让“数字员工”的迭代速度比传统软件开发快了一个量级。

4.2 Docker Compose方式把Dify完整跑起来

部署Dify需要本机已装Docker和Docker Compose插件。验证方法：

docker --version docker compose version

然后用Git拉取项目源码（若Git不方便，也可以直接下载Releases压缩包解压，效果一样）：

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env

启动前按你的实际环境调整.env文件。重点检查这几个变量：

• EXPOSE_NGINX_PORT：访问Web界面的端口，默认80，若被占用改成8080。
• POSTGRES_PASSWORD、REDIS_PASSWORD：建议改成强密码，尤其将来要暴露给局域网访问时。
• SECRET_KEY：用于Dify内部加密，替换成一个足够随机的长字符串。

确认无误后执行：

docker compose up -d

首次启动会拉取镜像，耗时取决于网络。全部容器变成healthy状态后，浏览器打开http://localhost就能进入Dify初始化页面。设置管理员账号之后，就进入主界面了。

我最初部署时犯过一个低级错误：直接默认配置启动，结果80端口和本机的Nginx冲突，Dify的页面怎么也打不开。后来改了EXPOSE_NGINX_PORT=8080才正常。如果你本机已经有Web服务，这个端口冲突是最常见的第一道坎。

4.3 把本地Ollama模型接入Dify

进入Dify管理后台后，找到“设置 → 模型供应商”，选择Ollama类型，填入之前我们启动的地址。例如我本地跑的是Ollama，配置如下：

• API地址：http://host.docker.internal:11434
• 模型名称：qwen2.5:7b
• 模型类型：LLM

为什么要用host.docker.internal而不是localhost？因为Dify各个服务跑在Docker容器里，容器内的localhost指容器自己，并不是宿主机。host.docker.internal是Docker为容器访问宿主机提供的特殊域名。这个细微差别，不知道的人能卡一下午。

填好后点“测试”，如果返回正常说明模型已经接通。在Dify的“发布为Agent应用”里，把默认模型换成Ollama接入的这个模型，你就已经拥有一个可Web对话的本地Agent了。

4.4 编排一个能“查知识库并执行工具”的Agent

接入模型只是第一步，我给Agent配置两项核心能力：知识库检索和自定义工具调用。

知识库方面，我在Dify里创建“运维知识库”，上传几份公司内部技术文档，分段方式选择自动，向量模型要选一个。这里有个关键细节：Dify默认的向量化可能调用云端API，但你想全本地化，就需要本地跑一个嵌入模型。操作方法是先在模型供应商也接入Ollama类型的Embedding模型，推荐用bge-m3，然后在知识库创建时指定本地嵌入模型。

上传完成后，我可以先问一个问题验证RAG链路：“根据知识库，我们的服务器运维值班流程是什么？”如果回答引用了文档内容，说明链路打通了。

工具调用方面，Dify允许在Agent设置里添加工具。我实际做过一个例子：给Agent注册一个“查询本机CPU和内存状态”的工具。方式是在服务器上写一个Python Flask脚本，暴露一个简单的HTTP接口：

from flask import Flask, jsonify import psutil app = Flask(__name__) @app.route("/sys_status", methods=["GET"]) def sys_status(): return jsonify({ "cpu_percent": psutil.cpu_percent(interval=1), "memory_percent": psutil.virtual_memory().percent }) if __name__ == "__main__": app.run(host="0.0.0.0", port=8000)

这个脚本并不复杂，启动它作为本机工具。然后在Dify的“自定义工具”里，填入OpenAPI Schema，描述这个接口的功能：查看服务器当前CPU和内存使用率。

之后在Agent编排页里，为Agent开启工具选择“系统状态查询”，并设定提示词：“当用户询问服务器负载时，调用系统状态查询工具获取实时数据。”保存发布。这时在对话框里输入“我现在服务器负载高吗”，Agent会先调用工具拿到CPU和内存数据，再组织语言输出答案。

4.5 让Agent的动作更接近“数字员工”而非聊天框

上面实现了“能查知识库”“能调工具”，但这还都是用户问一句它答一句。如果你真的希望它是“数字员工”，最好能给它加“主动触发”机制。Dify的后端服务本身不擅长做定时任务，但我通常会用一个外部Cron脚本定时往Dify的Agent API接口发送请求，要求Agent生成早报或检查任务状态。

例如Linux Crontab里加一条：每天上午9点调用Dify的Agent API触发“早间巡检”流程。这一步把Agent从一个被动的问答工具，变成了一个自动运行的数字化员工。这也是我标题里“数字员工”的最终落点，它不仅会回答问题，到了时间会自动干活的Agent，才叫员工。

5. 进阶之路：自己写一个轻量本地Agent的调度核心

5.1 图形化平台解决不了的长尾问题

Dify虽然好用，但用久了你会发现它也存在限制：某些复杂的业务逻辑在可视化编排里表达很别扭，调试深层问题时日志不够细，想完全控制上下文窗口的取舍也麻烦。这时候我建议自己实现一个精简的Agent调度核心，目的不是替代Dify，而是理解底层的循环机制，并为特殊场景留一条可编程的路。

一个Agent本质上是“对话循环加工具选择”，核心逻辑比想象中简单：

1. 组装系统提示词和用户消息。
2. 请求模型，看输出是普通文本还是工具调用指令。
3. 如果是工具调用，执行对应函数，把结果追加到上下文。
4. 再次请求模型，直到模型输出最终文本。

这个循环的实现不到两百行代码。一旦你自己写过一次，Dify里面的节点逻辑对你来说就完全透明了，排障时脑子里的模型会清晰很多。

5.2 开发环境准备与核心依赖

本地开发这套Python Demo，环境准备比Dify还简单，只需要Python 3.9以上环境。我们通过OpenAI SDK访问Ollama的兼容接口，所用的库也就openai和dotenv两个：

pip install openai python-dotenv

5.3 最小可运行的Agent循环示例

下面这个示例我实际跑过，你新建一个agent_demo.py，把代码放进去就能运行：

import json from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", ) def get_weather(city: str) -> str: """模拟查询天气的本地工具""" data = { "beijing": "多云，18℃", "shanghai": "小雨，22℃", "shenzhen": "晴，28℃" } return data.get(city, f"没有{city}的天气数据") TOOLS = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的实时天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市拼音，如 beijing"} }, "required": ["city"] } } } ] def run_agent(user_input: str): messages = [ {"role": "system", "content": "你是一个本地数字员工，可以调用工具帮助用户。"}, {"role": "user", "content": user_input} ] for step in range(5): # 限制最大循环次数，防止死循环 response = client.chat.completions.create( model="qwen2.5:7b", messages=messages, tools=TOOLS, ) msg = response.choices[0].message if msg.tool_calls: messages.append({ "role": "assistant", "content": msg.content, "tool_calls": [ { "id": tc.id, "type": "function", "function": tc.function.model_dump() } for tc in msg.tool_calls ] }) for tc in msg.tool_calls: fn_name = tc.function.name args = json.loads(tc.function.arguments) if fn_name == "get_weather": result = get_weather(city=args["city"]) else: result = f"未知工具: {fn_name}" messages.append({ "role": "tool", "tool_call_id": tc.id, "content": json.dumps(result, ensure_ascii=False) }) continue print("Agent回答:", msg.content) return print("Agent执行超过最大步数，已终止") if __name__ == "__main__": run_agent("北京今天天气怎么样？")

运行结果大致是：模型输出一个工具调用指令，代码执行get_weather函数取回天气数据，再反馈给模型，模型最终组织出“北京今天多云，18℃”这样的自然语言回答。

5.4 工具注册机制的演进：从硬编码到通用装饰器

上面Demo把工具选择和执行都写死在了Agent循环里，工具少还好办，一旦数量变多，这种写法会非常痛苦。为解决这个问题，我建议的方式是用一个注册表维护工具列表，通过装饰器把普通函数注册为Agent可用工具。

TOOL_REGISTRY = {} def register_tool(func): TOOL_REGISTRY[func.__name__] = func return func @register_tool def get_weather(city: str) -> str: """模拟查询天气的本地工具""" ... # 执行时 if fn_name in TOOL_REGISTRY: result = TOOL_REGISTRY[fn_name](**args)

每次新增能力，只需要新写一个函数加上@register_tool装饰器，调度核心完全不用改。函数名、参数说明、返回结构都写在docstring里，可以被自动提取成提供给大模型的Schema。这一步走完，你会发现Agent的可扩展性一下子打开了，这就是所谓“Agent开发”里的核心工程经验。

5.5 我坚持自己写一套Agent核心的原因

最终说点踩坑的心得。图形化平台很好用，但我还是坚持维护了一套自己的Agent核心，原因有三个：

其一是可控性。生产环境里，我希望知道每一次模型调用的完整链路和消费记录，自己写的核心可以精确打日志，每一步做了什么、调了什么工具、耗时多久、模型返回是什么，全部一目了然。这对排查线上问题至关重要。

其二是上下文管理更精细。图形化平台为了一般场景，会做比较通用的上下文拼装，但特定任务可能需要精简上下文、压缩历史、优先塞入某些字段。自研后这些都能自己掌握。

其三是低耦合。我不希望自己的业务逻辑被绑定在某一个Agent框架上，哪天想换一个模型供应商、加一个工具协议，或者调整调度逻辑，自己能直接改代码，而不是去适应平台更新带来的变化。

当然，我建议大多数读者还是从Dify这类图形化平台开始跑通全流程，等业务复杂度迫时再迁移到自研。上手就自研，容易只见树木不见森林。

6. 常见问题与排查技巧实录

6.1 本地部署Agent频繁遇到的几类故障

从我的使用经历和社区反馈看，本地Agent部署的最大障碍其实不是Agent本身，而是底层环境。下面把最容易出问题的几类整理一下：

6.2 三个典型的疑难杂症复盘

第一个典型的坑是Ollama长时间运行后显存越占越多。原因是Ollama默认会把已加载模型保留在显存里，方便后续快速响应。如果你在一个Agent流程中切换了多个模型，显存会被全部填满。解决方案是设置环境变量OLLAMA_MAX_LOADED_MODELS=1和OLLAMA_KEEP_ALIVE=10m，让不用的模型自动卸载。

第二个坑是Dify的容器日志刷屏，模型请求超时。出现这个问题时，去排查Ollama是否真的能处理并发请求。Ollama默认并发能力有限，如果有多个Agent任务同时请求同一个模型，很容易排队超时。一个有效做法是在应用前端加一层“请求队列”，另一个是直接换vLLM这类专门的高并发推理框架。个人使用场景下，给Dify应用设置“单用户模式”也能缓解。

第三个坑是本地Agent“乱跑工具”。比如用户问一句环境温度，模型却调用了一个删除文件的工具，这是所有“工具型Agent”必须重视的安全隐患。解决办法是给每个工具设置权限级别，关键操作必须二次确认，Agent只能调用白名单内的工具。图形化平台里通常有“工具使用前确认”的开关，务必打开。自己写的代码里，我在工具执行前一律加一条人机确认：

confirm = input(f"即将执行工具 {fn_name}({args})，确认执行？[y/N]") if confirm.lower() != "y": return "用户取消执行"

这条看起来笨拙，但在无人值守的数字员工场景里，能拦住大量不可逆误操作。

6.3 性能优化与感知提升的经验清单

如果你的Agent跑起来能用但是很“肉”，可以试试下面这些提升办法：

• 将模型量化到4bit或更低。7B模型在4bit量化下显存占用大约能降到4GB-5GB，速度提升明显，质量下降有限。
• 限制模型上下文长度。本地文本问答不是所有场景都需要32K上下文，默认分配太长会导致显存和计算量剧增。把Agent的任务类对话窗口设定在8K-16K就够大多数情况。
• 对知识库做预处理。不要在每次提问时都对整篇长文档做向量化检索，先做粗筛再精读，检索效率和准确率都能上升。
• 独立部署一个向量数据库。Dify内置的向量库数据量小时够用，但数据量上来后，独立使用Milvus或Qdrant这类专业向量库会更稳定。
• 给模型服务配置GPU层数。llama.cpp/Ollama都支持通过环境变量控制GPU层数，如果你的GPU显存不足，适当减少GPU层，把部分层交给CPU，能避免直接崩溃。

6.4 一些沉淀下来的部署习惯

复盘这一路的部署，我愿意分享三个始终在用的好习惯：

第一，所有配置文件都做版本管理。.env、docker-compose.override.yml、Agent提示词都放进Git仓库，改动可追踪、回滚方便。别相信“我就改一个数字不会出问题”这句话，Agent编排里的配置项经常是牵一发动全身。

第二，任何变更前先备份知识库和业务数据。Dify的向量库重新构建又慢又费钱，我不想重复体验那种痛苦。所以每次升级镜像前都会docker compose导出一份Dify的数据卷备份。

第三，为Agent单独建日志系统。把每次用户对话、工具调用、模型输出保存下来。这些日志既能在出问题时复现现场，也能用于后续分析Agent的效果瓶颈，到底是模型理解不行，还是工具描述不清，还是知识库里没有相关内容。没有日志的Agent，出了问题就只能靠猜。

最后多说一句

如果你准备在本地部署AI Agent，我建议你不要直接照搬某一个大而全的教程，而是先冷静评估：你最想让“数字员工”替你做的第一件事是什么？然后以这个最小需求为半径，搭一个能用、能改、能扩展的环境。先从Ollama加一个Dify跑通问答和工具调用，再逐步叠加团队文档、业务接口、定时任务，慢慢你就会发现自己已经有了一套私有的数字化办公体系。这些年我折腾下来，最大的感受是，AI Agent本地部署最难的部分并不是技术门槛，而是如何界定它的职责边界，并让它在合适的位置真正发挥价值。