这次我们来看一个本地 AI 智能体项目 WorkBuddy。它不是那种只能聊天的 AI而是一个能帮你自动化处理电脑上各种任务的工作流智能体。简单说你可以用自然语言告诉它“帮我整理桌面上的截图”或者“把上周的会议记录总结成邮件”它就能调用本地工具去执行。对于不想把敏感数据上传云端又想体验 AI 自动化的开发者或效率追求者来说这是一个值得关注的本地化方案。WorkBuddy 的核心在于将大语言模型LLM与本地执行环境打通。它通常基于 LangGraph、LangChain 这类智能体框架构建通过 Ollama 或 LM Studio 在本地运行开源模型然后结合 Python 脚本、系统命令或自定义工具来完成具体任务。整个过程数据不出本地安全性高且可深度定制。本文将带你完成从零到一的完整部署。我们会重点解决几个实际问题环境依赖怎么装最省心如何配置本地模型怎样创建和调试一个真正能跑起来的工作流以及这个方案对硬件有什么要求跑起来卡不卡如果你之前被复杂的智能体开发环境劝退或者想找一个可掌控的自动化方案这篇教程会提供一条清晰的路径。1. 核心能力速览在深入细节之前我们先通过一个表格快速了解 WorkBuddy 这类本地 AI 智能体项目的关键特性这有助于你判断它是否适合你的需求。能力项说明项目类型本地化 AI 智能体 / 工作流自动化平台核心架构通常基于 LangGraph/LangChain 本地 LLM (如 Ollama) 自定义工具主要功能自然语言任务解析、本地工具调用文件操作、信息查询、脚本执行等、多步骤工作流编排数据安全全程本地运行模型、数据、计算均不依赖外部 API隐私性强硬件门槛依赖本地 LLM需中等配置 GPU如 8G 显存以获得较好体验纯 CPU 也可运行速度较慢显存占用主要由加载的本地大模型决定。例如运行 7B 参数的量化模型显存占用约 4-8GB13B 模型则需要 8-16GB。启动方式命令行启动 Web 服务为主也可能提供 Docker 镜像或一键脚本接口能力提供 WebUI 进行交互通常也内置 API 服务端支持通过 HTTP 调用智能体批量任务可通过 API 或脚本批量提交任务适合自动化处理重复性工作适合场景本地数据自动化处理、隐私敏感任务助理、开发测试、AI 工作流学习与定制从表格可以看出它的最大优势是本地化和可定制性。你可以把它想象成一个住在你自己电脑里的、会编程的私人助理但它需要你提供“大脑”本地模型和“工具”脚本。2. 适用场景与使用边界在投入时间部署之前明确它能做什么、不能做什么至关重要。WorkBuddy 非常适合以下场景隐私敏感型任务处理处理公司内部文档、个人财务记录、医疗健康信息等你绝对不希望这些数据离开本地。开发与测试环境辅助让 AI 帮你写单元测试、生成模拟数据、执行代码审查调用本地 linter、管理 Docker 容器等。个人知识库管理自动整理下载的论文、归类照片、根据内容重命名文件、从本地文档中提取信息并生成摘要。定制化办公自动化超越传统 RPA用自然语言驱动。例如“找出所有包含‘预算’关键词的 Excel 文件将它们的汇总表合并到一个新文件中。”教育与学习作为学习 AI 智能体技术的实践项目理解 LangGraph 的工作流编排、工具调用和记忆机制。它的局限和不适合的场景需要联网实时信息的任务默认配置下它无法直接访问互联网搜索最新新闻、股价或天气。需要额外配置网络访问工具或插件。处理超大规模计算或专业领域任务本地模型的数学能力、代码生成能力虽强但与顶尖云端 API 仍有差距。对于极其复杂的科学计算或专业领域推理可能力不从心。开箱即用的傻瓜式体验它不是一个安装完就能完美工作的商业软件。你需要配置模型、编写或适配工具、调试工作流有一定技术门槛。高并发生产环境本地单机部署性能受限于本地硬件不适合直接作为高并发线上服务。更适合作为后台自动化工具或原型系统。重要合规与安全边界工具权限你赋予智能体的工具如执行 shell 命令、删除文件具有同等系统权限。务必谨慎授权避免创建具有破坏性能力的工具。内容合规本地模型同样可能生成不当内容。在涉及内容生成、总结的任务中应建立人工审核环节。版权与数据源确保智能体处理的数据文档、代码、图片是你拥有合法使用权的。避免用它处理未授权的版权材料。3. 环境准备与前置条件让我们开始实战。首先确保你的电脑满足以下基础条件。这是后续所有步骤能顺利进行的前提。操作系统推荐Ubuntu 20.04/22.04 LTS, Windows 10/11, macOS (Apple Silicon 芯片体验更佳)。理论上主流 Linux 发行版、Windows 和 macOS 都支持但 Linux 环境在依赖管理上通常更顺畅。Python 环境版本Python 3.9 或 3.10。Python 3.11 也可能支持但 3.9/3.10 的兼容性最广。管理工具强烈建议使用conda或venv创建独立的虚拟环境避免污染系统 Python 和解决包冲突。Node.js 环境如果项目包含前端许多智能体项目会提供一个 React/Vue 前端界面。需要 Node.js 环境进行构建或开发。版本Node.js 16 或 18 LTS 版本。使用nvm(Linux/macOS) 或nvm-windows管理多个 Node.js 版本是个好习惯。本地大语言模型LLM运行时这是智能体的“大脑”。你需要选择一个本地模型服务方案Ollama推荐目前最流行的本地 LLM 运行和管理的工具。它简化了模型下载、加载和提供 API 的过程。安装简单支持众多开源模型Llama 2/3, Mistral, Gemma, Qwen 等。提供与 OpenAI API 兼容的接口方便智能体框架调用。LM Studio图形化界面更友好同样提供本地 API 服务适合 Windows/macOS 用户快速上手。vLLM / llama.cpp追求极致性能或需要高级推理功能时的选择配置相对复杂。硬件要求GPU推荐拥有至少 8GB 显存的 NVIDIA GPUGTX 10系列以上RTX 20/30/40系列更佳。这是流畅运行 7B-13B 参数模型的基础。CPU备用如果没有 GPU 或显存不足可以纯 CPU 推理。需要较强的多核 CPU如 Intel i7/Ryzen 7 以上和足够的内存16GB。速度会慢很多。内存16GB 系统内存是底线32GB 或以上会更从容尤其是运行较大模型或处理多任务时。磁盘空间至少预留 20-40GB 空间用于存放模型文件一个 7B 的 4-bit 量化模型约 4GB一个 13B 的模型可能超过 10GB、Python 环境及项目代码。网络条件首次运行需要下载模型文件通过 Ollama 或手动下载请确保网络通畅。模型文件较大下载需要时间。4. 安装部署与启动方式假设我们基于一个典型的“LangGraph Ollama 自定义工具”的 WorkBuddy 项目结构进行部署。以下是通用步骤具体项目的 README 可能会有细微差别。4.1 第一步获取项目代码通常项目会托管在 GitHub 或 GitLab 上。# 克隆项目仓库到本地 git clone 项目仓库的URL cd workbuddy # 进入项目目录请将项目仓库的URL替换为实际地址。4.2 第二步创建并激活 Python 虚拟环境使用conda或venv隔离环境。# 使用 conda (如果已安装) conda create -n workbuddy python3.10 conda activate workbuddy # 或者使用 venv python -m venv venv # 在 Windows 上激活 venv\Scripts\activate # 在 Linux/macOS 上激活 source venv/bin/activate激活后命令行提示符前应显示环境名(workbuddy)。4.3 第三步安装 Python 依赖项目根目录通常会有requirements.txt或pyproject.toml文件。# 安装核心依赖 pip install -r requirements.txt # 如果遇到特定包版本问题可能需要单独安装或升级 pip pip install --upgrade pip常见问题如果requirements.txt中包含torch最好先根据你的 CUDA 版本去 PyTorch 官网 获取安装命令先安装好 PyTorch再安装其他依赖避免冲突。4.4 第四步安装并配置 Ollama本地模型服务安装 Ollama访问 Ollama 官网 下载对应操作系统的安装包或使用命令行安装Linux。拉取模型Ollama 安装后在终端拉取一个合适的模型。对于智能体任务需要选择推理和工具调用能力较强的模型。# 拉取 Llama 3.1 8B 模型性能与效率平衡 ollama pull llama3.1:8b # 或者拉取 Mistral 7B 模型工具调用优化好 ollama pull mistral:7b # 或者拉取 Qwen2.5 7B 模型中文能力强 ollama pull qwen2.5:7b运行模型服务拉取后模型已就绪。Ollama 默认会在http://127.0.0.1:11434提供 API 服务。你可以运行ollama run 模型名进行交互式测试但智能体框架会自动通过 API 调用。4.5 第五步配置 WorkBuddy 项目在项目目录下通常需要复制或创建配置文件如.env,config.yaml,config.py并设置关键参数。# 示例复制环境变量模板文件 cp .env.example .env然后编辑.env文件关键配置项通常包括# .env 文件示例 OLLAMA_BASE_URLhttp://127.0.0.1:11434 OLLAMA_MODELllama3.1:8b # 与上一步拉取的模型名一致 # 工作流存储路径、日志级别等 WORKFLOW_STORAGE_PATH./workflows LOG_LEVELINFO # API 服务监听地址和端口如果项目提供 API API_HOST0.0.0.0 API_PORT80004.6 第六步启动服务根据项目结构启动方式可能不同。方式一直接启动 Web 服务常见# 通常是一个 FastAPI 或 Gradio 应用 python app.py # 或 uvicorn main:app --host 0.0.0.0 --port 8000 --reload启动后控制台会输出访问地址如http://127.0.0.1:8000。方式二分别启动后端 API 和前端如果项目分离# 终端1启动后端 cd backend python main.py # 终端2启动前端 cd frontend npm install # 首次需要安装依赖 npm run dev前端开发服务器通常会运行在另一个端口如http://localhost:3000。访问对应的地址你应该能看到 WorkBuddy 的 Web 界面。5. 功能测试与效果验证服务启动成功只是第一步我们需要验证智能体是否能真正理解任务并调用工具。下面设计几个由浅入深的测试。5.1 测试一基础对话与上下文理解目的验证本地模型服务Ollama是否被正确连接以及智能体是否具备基础的对话能力。操作在 WebUI 的聊天框中输入“你好介绍一下你自己。”预期结果智能体会返回一段自我介绍说明它是一个 AI 助手运行在本地可以帮你处理任务等。回复不应是乱码或错误信息。成功标准获得连贯、合理的文本回复。失败排查检查 Ollama 服务是否在运行 (ollama list)。检查.env中的OLLAMA_BASE_URL和OLLAMA_MODEL是否正确。查看后端日志是否有连接超时或模型加载错误。5.2 测试二内置工具调用如文件列表目的验证智能体能否成功调用一个简单的预定义工具这是核心能力。操作输入“列出当前项目目录下所有的 Python 文件。”预期结果智能体应该理解你的意图调用一个“列出文件”的工具并返回一个.py文件的列表。成功标准返回一个具体的文件列表而不是说“我不会”或重复你的问题。失败排查检查项目是否预置了文件操作类工具并已正确注册到智能体。查看日志中工具调用的过程。智能体框架如 LangGraph通常会输出详细的Thought、Action、Observation日志。模型可能没有正确触发工具。尝试更明确的指令如“请使用 list_files 工具查看当前目录下的 Python 文件。”5.3 测试三多步骤工作流执行目的验证智能体能否将一个复杂任务分解为多个步骤并按顺序调用工具完成。操作输入“请先创建一个名为test_output的文件夹然后在里面创建一个hello.txt文件并写入‘Hello from WorkBuddy’。”预期结果智能体应规划出三个步骤1. 创建目录2. 创建文件3. 写入内容。最终在项目根目录下生成./test_output/hello.txt文件。成功标准文件被正确创建且内容无误。失败排查观察日志中的思维链。是否在第一步后就停止了可能是工具执行失败或权限问题。检查每一步的Observation是否正常。例如创建文件夹后是否返回了成功路径。确保相关工具mkdir,write_file的代码逻辑正确没有抛出异常。5.4 测试四自定义工具集成测试目的验证你能否成功扩展智能体的能力加入自己编写的工具。背景假设你写了一个获取系统时间的工具get_current_time。操作按照项目规范在tools/目录下创建time_tools.py定义工具函数。在智能体初始化代码中注册这个新工具。重启服务。输入“现在几点了”预期结果智能体调用你的get_current_time工具返回当前系统的日期和时间。成功标准返回正确的时间信息证明自定义工具集成成功。失败排查工具函数签名是否符合框架要求例如是否有清晰的docstring描述工具注册的代码是否正确是否在工具列表中添加了新工具模型是否能理解新工具的描述可能需要更精确的指令触发。通过以上四个测试你就能基本确认你的 WorkBuddy 智能体已经“活”了并且具备了基础的任务执行能力。6. 接口 API 与批量任务一个成熟的智能体项目除了 WebUI一定会提供 API 接口方便与其他系统集成或进行批量处理。6.1 API 服务调用启动的服务如基于 FastAPI通常会提供标准的 HTTP API。我们可以用curl或 Python 脚本来测试。查找 API 文档访问http://127.0.0.1:8000/docs或http://127.0.0.1:8000/redoc如果使用 FastAPI这里会列出所有可用的端点。常见端点示例POST /chat发送单轮消息。POST /workflow/run触发一个预定义的工作流。POST /agent/run向智能体提交任务。使用 Pythonrequests库调用import requests import json # API 端点地址 url http://127.0.0.1:8000/agent/run # 请求载荷 payload { input: 请列出当前目录下所有的 markdown 文件并统计数量。, session_id: test_session_001 # 可选用于会话隔离 } # 设置请求头 headers { Content-Type: application/json } try: # 发送 POST 请求设置较长超时时间因为模型推理需要时间 response requests.post(url, jsonpayload, headersheaders, timeout120) response.raise_for_status() # 检查 HTTP 错误 # 解析响应 result response.json() print(API 调用成功) print(f任务ID: {result.get(task_id)}) print(f智能体回复: {result.get(response)}) print(f执行步骤: {result.get(steps, [])}) # 可能包含详细的思维步骤 except requests.exceptions.RequestException as e: print(fAPI 请求失败: {e}) except json.JSONDecodeError as e: print(f响应解析失败: {e}) print(f原始响应: {response.text})6.2 批量任务处理利用 API我们可以轻松实现批量任务。思路是读取一个任务列表如 CSV、TXT循环调用 API并收集结果。import requests import csv import time api_url http://127.0.0.1:8000/agent/run tasks [ 总结一下 project_plan.docx 的要点。, 将 data 文件夹中的所有 .csv 文件合并成一个。, 给最近修改的 5 个图片文件添加‘reviewed_’前缀。 ] results [] for i, task in enumerate(tasks): print(f处理任务 {i1}/{len(tasks)}: {task[:50]}...) payload {input: task} try: response requests.post(api_url, jsonpayload, timeout180) if response.status_code 200: result response.json() results.append({ task: task, success: True, response: result.get(response), error: None }) else: results.append({ task: task, success: False, response: None, error: fHTTP {response.status_code}: {response.text} }) except Exception as e: results.append({ task: task, success: False, response: None, error: str(e) }) # 短暂停顿避免对本地服务造成过大压力 time.sleep(2) # 将结果保存到文件 with open(batch_results.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[task, success, response, error]) writer.writeheader() writer.writerows(results) print(f批量处理完成结果已保存到 batch_results.csv)批量任务最佳实践限流与间隔在循环中增加time.sleep()避免短时间大量请求压垮本地服务。错误处理与重试对网络错误或服务暂时不可用的情况加入重试机制。结果持久化立即将每个任务的结果保存到文件或数据库防止程序中途崩溃导致数据丢失。会话管理如果任务间有关联可以使用相同的session_id来维持对话上下文。7. 资源占用与性能观察部署完成后我们需要关注它的运行效率这对实际使用体验至关重要。1. 观察显存占用GPU 模式工具在 Linux 上使用nvidia-smi在 Windows 上使用任务管理器或nvidia-smi.exe。命令# Linux/Windows (命令行) nvidia-smi # 或动态监控 watch -n 1 nvidia-smi解读找到运行 Ollama 服务或直接运行模型的 Python 进程对应的进程查看GPU Memory Usage。这是模型加载和推理消耗的显存。7B 量化模型通常在 4-8GB13B 模型在 8-16GB。2. 观察内存与 CPU 占用工具系统任务管理器或htop(Linux)、top(Linux/macOS)。关注点Python 进程内存智能体后端进程的内存占用会随着处理任务量增长。Ollama 进程内存模型服务本身的内存占用。CPU 使用率在纯 CPU 推理或工具执行如文件处理时CPU 使用率会显著升高。3. 性能影响因素与调优模型大小与量化模型参数越大能力越强但资源消耗也越大。使用量化模型如 GGUF 格式的 Q4_K_M能在几乎不损失精度的情况下大幅降低显存和内存占用。在 Ollama 中拉取模型时可以指定量化版本如llama3.1:8b-q4_0。上下文长度处理很长的对话或文档时需要更长的上下文窗口如 8K, 32K, 128K这会增加内存和计算开销。在配置中合理设置context_window参数。工具执行效率如果自定义工具涉及复杂计算、网络请求或大量 I/O 操作会成为性能瓶颈。优化工具代码本身。批处理如果 API 支持批量请求将多个小任务打包发送可以提高整体吞吐量。一个典型的资源占用场景 启动 Ollama 加载llama3.1:8b-q4_0模型后显存占用约 5GB。启动 WorkBuddy 后端服务内存占用约 500MB。当你通过 WebUI 或 API 提交一个文件处理任务时会观察到推理阶段GPU 利用率短暂飙升智能体“思考”要调用什么工具。工具执行阶段GPU 利用率下降CPU 和磁盘 I/O 可能上升取决于工具类型。生成回复阶段GPU 利用率再次上升智能体组织最终回复。理解这个模式有助于你在遇到性能问题时进行针对性排查。8. 常见问题与排查方法部署和使用过程中你肯定会遇到各种问题。下表汇总了常见问题及其解决方法。问题现象可能原因排查方式解决方案启动服务时报ImportErrorPython 依赖未安装或版本冲突虚拟环境未激活。1. 检查是否在正确的虚拟环境中 (which python)。2. 运行pip list查看关键包如langchain,langgraph是否存在。1. 激活虚拟环境。2. 重新运行pip install -r requirements.txt。3. 尝试升级pip和setuptools。访问 WebUI 显示“无法连接”或空白页后端服务未启动前端构建失败或端口错误防火墙阻止。1. 检查后端进程是否在运行 (ps auxgrep python)。2. 检查控制台日志是否有错误。3. 确认访问的 IP 和端口是否正确。智能体回复“我不知道如何做”或重复提问本地模型服务未连接模型未正确加载工具未注册或描述不清。1. 访问http://127.0.0.1:11434测试 Ollama 是否正常。2. 查看后端日志确认模型调用是否返回错误。3. 检查工具注册部分的代码。1. 启动 Ollama 服务 (ollama serve)。2. 确认.env中模型名称与 Ollama 拉取的名称完全一致。3. 优化工具函数的docstring使其描述更清晰。工具调用失败返回权限错误或文件未找到工具脚本本身的逻辑错误系统权限不足文件路径问题相对/绝对路径。1. 在日志中找到工具调用的具体错误信息。2. 单独在 Python 环境中运行该工具函数进行测试。1. 修复工具代码的 Bug。2. 使用绝对路径或确保工作目录正确。3. 在 Linux/macOS 上检查文件执行权限 (chmod x)。GPU 显存不足 (OOM)加载的模型太大同时运行多个任务系统其他程序占用显存。1. 使用nvidia-smi观察显存占用。2. 检查是否在多个地方重复加载了模型。1. 换用更小的或量化程度更高的模型如q4_0。2. 关闭不必要的图形界面或 GPU 程序。3. 在代码中设置更小的max_tokens或batch_size。API 调用超时 (Timeout)任务过于复杂模型推理时间过长网络延迟服务端处理阻塞。1. 在服务端日志中查看单个请求的处理时长。2. 尝试一个非常简单的请求如“你好”测试响应速度。1. 增加客户端请求的超时时间如timeout300。2. 优化提示词让任务更明确。3. 检查服务端是否有死循环或阻塞操作。工作流执行到一半卡住工作流图中存在循环或条件判断逻辑错误某个工具陷入等待。1. 查看 LangGraph 的执行状态日志看卡在哪一步。2. 检查该步骤的工具输入输出是否符合预期。1. 调试工作流图增加超时和错误处理节点。2. 简化复杂的工作流分步测试。通用排查流程看日志这是最重要的后端启动和运行时的日志会包含绝大多数错误信息。简化测试用一个最简单的任务如“11等于几”测试整个链路是否通畅。隔离问题分别测试模型服务Ollama、工具函数、工作流逻辑确定问题模块。搜索错误信息将具体的错误信息复制到搜索引擎或项目 Issues 中查找很可能已有解决方案。9. 最佳实践与使用建议为了让你的 WorkBuddy 更稳定、高效、安全遵循以下实践建议1. 项目与环境管理版本控制使用 Git 管理你的 WorkBuddy 项目代码、自定义工具和配置文件。特别是对工作流LangGraph 图的修改要频繁提交。环境隔离坚持使用虚拟环境conda/venv。为不同的项目或实验创建独立的环境。配置外置将所有配置模型地址、API密钥、路径等放在.env文件中并确保.env在.gitignore里避免敏感信息泄露。2. 模型选择与优化从小开始初次尝试从 7B 参数的量化模型如Mistral 7B,Llama 3.1 8B开始平衡速度与能力。量化是朋友在显存紧张的情况下优先选择 4-bit 或 5-bit 量化模型GGUF 格式性能损失小资源节省大。备用方案在配置中准备好一个更小的“后备模型”如 3B 参数当主要模型加载失败或资源不足时自动降级。3. 工具开发与安全最小权限原则赋予工具刚好够用的权限。例如一个文件读取工具不需要删除权限。输入验证与清理对所有用户输入和工具参数进行严格的验证和清理防止路径遍历../../../、命令注入等攻击。沙箱化执行对于执行不确定代码或命令的工具考虑在 Docker 容器或安全沙箱中运行。完善的日志为每个工具调用记录详细的日志包括输入、输出、耗时和错误便于审计和调试。4. 工作流设计模块化将复杂工作流拆分成多个可复用的子图或节点。错误处理在工作流图中显式地加入错误处理节点try-except避免整个流程因单点失败而崩溃。状态检查设计工作流时加入检查点验证上一步的输出是否符合预期再决定是否继续。人工审核节点对于关键操作如删除文件、发送邮件可以在工作流中插入一个“等待人工确认”的节点。5. 部署与运行进程守护在生产环境即使是本地生产使用systemd(Linux)、supervisor或PM2(Node.js) 来守护你的服务进程实现自动重启。资源监控设置简单的监控记录服务的 CPU、内存、显存使用情况以及 API 的响应时间和错误率。定期备份备份你的工作流配置、自定义工具代码和重要的对话历史。遵循这些实践你的本地 AI 智能体将从一个脆弱的实验项目逐渐成长为一个可靠的生产力工具。10. 总结与下一步通过这篇教程我们完成了 WorkBuddy 这类本地 AI 智能体从环境搭建、服务启动、功能测试到 API 调用的全流程。它的核心价值在于提供了一个安全、可控、可深度定制的自动化平台让你能在自己的硬件上运行一个“会思考、会操作”的 AI 助手。最值得尝试的起点先别想着造一个万能助理。从一个具体、微小、可验证的任务开始。比如写一个工具让它每天下午五点自动扫描你的下载文件夹把所有的图片移到“图片”文件夹把所有的 PDF 移到“文档”文件夹。这个任务涉及文件列表、类型判断、移动操作能完整地走通“理解-规划-执行”的闭环。最容易踩的坑环境依赖Python 包版本冲突是头号杀手务必使用虚拟环境。模型连接确保 Ollama 服务在运行且模型名称在配置文件中一字不差。路径问题在工具中使用文件路径时尽量使用绝对路径或明确相对于项目根目录的路径。后续可以探索的方向集成更多工具连接你的日历、邮件客户端、数据库让智能体真正融入你的工作流。实现长期记忆为智能体添加向量数据库如 ChromaDB让它能记住过去的对话和文档内容提供更个性化的服务。构建复杂应用用它作为核心引擎开发一个本地的智能客服原型、自动化的代码审查工具或是个人知识库问答系统。优化性能与体验尝试更快的模型推理后端如 vLLM为常用工作流设计图形化配置界面。本地 AI 智能体的世界刚刚打开它不完美但充满可能性。亲手部署和调试的过程本身就是对 Agent、工作流、模型服务化等概念最深刻的学习。建议收藏这篇教程在遇到问题时回来查阅排查清单。现在就去创建你的第一个工作流吧。