文章目录

周末在 Mac Studio 上按官方文档搭 Nexent v2.8.2，原本以为一条 bash deploy.sh docker 很快就能收工。动手之后才发现，真卡住人的不是脚本本身，而是三个细节：依赖镜像后台超时、源码 tag 与镜像仓库对不上、接本地 Ollama 时填 localhost 一直连不通。
在这里插入图片描述

把这几处边界理顺后，整套服务跑起来其实很稳。下面按实际排障顺序，记录从空目录拉码、起容器，到接通本地 Ollama（qwen3:30b） 并发出第一句「你好」的全过程。

命令与参数对照 Nexent 官方文档与仓库脚本。镜像总体积、拉取耗时及跨平台参考数据引自社区两份 v2.8.2 公开实录；终端与工作台截图均来自本次 Mac 本地实测。

一、Nexent 到底跑了哪些容器，Mac 环境先卡哪几项

用过传统智能体编排工具的人，大概都体验过在画布上拖几十个节点、自己再去拼向量库和工具网关的繁琐。Nexent 是魔擎社区（ModelEngine）开源的零代码智能体平台，走的是 Harness Engineering 路线——不靠手工连线，直接用自然语言定义角色与工具边界，让运行时自己调度。
在这里插入图片描述

这次从零跑通之后，最让我省心的其实是两点。一是所有常用模块都收在同一个工作台里（模型、知识库、记忆、Agent/MCP/Skill 仓库、自动任务），不用东拼西凑；二是部署脚本做成了终端交互菜单（TUI），既能跳过登录直接单机体验，也能随时勾上 supabase 打开多租户隔离。

1.1 实测环境与版本边界

动手之前先把版本和宿主机基线对齐，避免后面按错文档踩坑：

核对项本次实测环境官方最低要求 / 备注
宿主机macOS（Mac Studio）Apple Silicon 原生 ARM64 支持
容器引擎Docker Desktop（含 Compose v2）需 docker compose version 带 v2
分配内存 / 磁盘Docker 建议配 12~16 GiB / 40 GiB官方最低 8 GiB 内存、40 GiB 磁盘
Nexent 版本v2.8.2（2026 年 11 月实测）通过 AtomGit --branch v2.8.2 锁定
本地模型推理宿主机 Ollama qwen3:30b独立运行在 Mac 宿主机，不占容器内存

注意最后一个细节：大模型推理服务通常独立跑在宿主机或远程节点，不计入 Nexent 自己的内存基线。不过 Nexent 自己也不是单容器应用，完整启动后会拉起前后端、PostgreSQL、Elasticsearch、MinIO 和 Redis 等十多个容器。参考社区 v2.8.2 实测统计，全量 13 个容器拉起后内存占约 5.4 GiB，镜像合计约 10.44 GB。

如果你同时要在 Mac 上用 Ollama 跑 30B 级别本地模型，Docker Desktop 的 Settings → Resources → Memory 建议给到 12 GiB（纯跑 Nexent 至少 8 GiB），磁盘空间留足 40 GiB 以上，否则拉镜像或起 Elasticsearch 时容易直接被系统杀掉。

1.2 先看清容器拓扑，后面排障才不瞎猜

为什么接本地 Ollama 时填 http://localhost:11434/v1 会失败？看一眼下面这张容器调用链就明白了：

host.docker.internal:11434/v1

HTTPS OpenAI 兼容接口

浏览器 localhost:3000

nexent-web :3000

nexent-config :5010

nexent-runtime :5014

nexent-data-process :5012

nexent-mcp :5011 / :5015

基础数据层
PG 5434 · ES 9210
MinIO 9010 · Redis 6379

Mac 宿主机 Ollama

云端大模型 API

浏览器访问的是宿主机映射出来的 localhost:3000。但真正去请求大模型的，是跑在 Docker 虚拟网桥里的 nexent-config（5010 端口）和 nexent-runtime（5014 端口）。在容器视角里，localhost 永远指它自己，只有走 host.docker.internal 才能穿出容器回到 macOS 宿主机。

1.3 镜像加速与跨平台参数：分清「应用源」和「依赖源」

国内网络直连 Docker Hub 拉基础镜像大概率超时。在 Mac 上打开 Docker Desktop → Settings → Docker Engine，把加速源写进 JSON 配置：

{
  "registry-mirrors": [
    "https://docker.m.daocloud.io",
    "https://docker.1ms.run"
  ]
}

点右下角 Apply & Restart 等 Docker Desktop 重启完，用终端命令验证配置和本机核心端口占用情况：

# 1. 确认镜像加速源已写入 Docker 守护进程
docker info | grep -A 3 "Registry Mirrors"

# 2. 检查 3000 / 5010 / 5434 / 6379 / 9210 等端口是否被本地进程占用
lsof -i :3000 -i :5010 -i :5434 -i :6379 -i :9210 || echo "核心端口均空闲"

正常情况下第一条命令会回显刚才填的两个 mirror 地址，第二条不会列出冲突进程（Mac 本地如果提前开了 Redis 开发实例，很容易先撞 6379 端口）。

顺带解释一个高频误会：后续部署脚本里的「镜像来源」选 mainland，改的只是 Nexent 自家业务镜像的仓库地址（切到腾讯云源 ccr.ccs.tencentyun.com/nexent-hub/...）。PostgreSQL、Elasticsearch、Redis、MinIO 和 Supabase 这些基础依赖镜像，依然走上面 Docker Engine 配的公共镜像加速源。

至于图 1 里提到的 vm.max_map_count（Elasticsearch 内存映射数），Mac 版 Docker Desktop 的内置虚拟机已经默认配够，不用改。只有当你换到 Linux 服务器 部署，且 ES 容器启动报错 failed to obtain node locks 或内存映射不足时，才需要执行宿主机调优：

# 仅 Linux 宿主机部署需要：调大 ES 内存映射，并把数据目录属主对齐容器 uid 1000
echo "vm.max_map_count=262144" | sudo tee /etc/sysctl.d/99-nexent.conf
sudo sysctl -w vm.max_map_count=262144
mkdir -p "$HOME/nexent-data/elasticsearch" && sudo chown -R 1000:0 "$HOME/nexent-data/elasticsearch"

此外，在 Mac 上确认 Docker Desktop → Settings → Resources → File Sharing 里包含 /Users（默认已勾选），确保后面挂载 $HOME/nexent-data 时有读写权限。

二、拉源码、改 .env 与交互式部署的内部动作

环境基线确认完，接下来就是拉代码、准备环境变量、跑 deploy.sh docker。这一步最值得注意的，是版本 tag 的锁定逻辑。

2.1 用 AtomGit 拉取 v2.8.2：为什么 --branch 不能省

Nexent 在 AtomGit 上维护了国内同步仓库，拉代码不用折腾 GitHub 代理。终端直接指定 --branch v2.8.2 做浅克隆，实测速率能跑满 3.43 MiB/s 左右（社区同类环境克隆约 275 MB 耗时 13.6 秒）：

# 锁定 v2.8.2 分支并跳过完整提交历史
git clone --depth 1 --branch v2.8.2 https://atomgit.com/ModelEngine/nexent.git nexent
cd nexent
cat VERSION && git rev-parse --short HEAD

在这里插入图片描述

图 2　在 Mac 终端通过 AtomGit 浅克隆 v2.8.2 源码，速率达到 3.43 MiB/s

为什么要特地看一眼 VERSION 文件？因为 deploy.sh 在生成镜像名时，会直接读取源码里的版本号（写入 .env 的 DEPLOYMENT_VERSION）。以前社区有人拉错成 v2.8.0 源码，结果镜像仓库只同步了 v2.8.2，拉镜像时直接报 manifest unknown。看似网络不通，根因其实是源码 tag 和镜像 tag 没对齐。

2.2 准备 deploy/env/.env：部署脚本前后会改写哪些字段

先复制模板文件并收紧权限，避免后续自动写入的密钥被其他本地用户读取：

cp deploy/env/.env.example deploy/env/.env
chmod 600 deploy/env/.env
# 检查核心入口配置项当前默认值
grep -E "^(NEXENT_WEB_PORT|ROOT_DIR|SITE_URL|NEXENT_SUPER_ADMIN_PASSWORD)=" deploy/env/.env

打开 deploy/env/.env，初次本地体验不用通篇改，重点核对这五项：

# 1. 超级管理员初始密码（默认 Nexent@123 为公开信息，团队试用务必修改）
NEXENT_SUPER_ADMIN_PASSWORD=YourStrongPassword123

# 2. 持久化目录：Mac 上放在 /Users 下即可，对应 Docker File Sharing 路径
ROOT_DIR=/Users/yourname/nexent-data

# 3. Web 与 HTTPS 入口端口（本地 3000 冲突时改这里）
NEXENT_WEB_PORT=3000
NEXENT_HTTPS_PORT=3100

# 4. 如果改了端口或开启 HTTPS，站内链接与 OAuth 回调地址必须同步改
SITE_URL=http://localhost:3000
OAUTH_CALLBACK_BASE_URL=http://localhost:3000

这里有个小细节：deploy/env/.env 里一开始并没有 MinIO 密钥和 SQL 校验和。等下面跑起 deploy.sh 并选完选项，脚本会自动生成 NEXENT_SQL_FILES_CHECKSUM、MINIO_ACCESS_KEY 和 MINIO_SECRET_KEY 回填进去，所以这个文件切记留在本机，别推到任何公开仓库。

2.3 运行 deploy.sh docker：6 个 TUI 选项与真实启动日志

在 nexent 根目录直接启动 Docker 部署脚本：

cd nexent
bash deploy.sh docker

脚本会打开一个 Bash TUI 交互界面（方向键或 j/k 移动，空格勾选，回车确认，b 返回）。如果你想快速体验，按下面这组配置选最稳：

顺序配置项单机个人体验推荐团队多租户补充说明
1components（组件）选 infrastructure、application、data-process需要账号隔离时，再加勾 supabase
2port policy（端口策略）development暴露调试端口方便排查；公网生产改 production
3image source（镜像源）mainland走 ccr.ccs.tencentyun.com/nexent-hub/nexent:v2.8.2
4sandbox mode（沙箱）lightweight跑对话与基础工具够用，内存开销更低
5HTTPS modedisabled本机 localhost 访问无需证书
6ROOT_DIR$HOME/nexent-data数据库、ES、MinIO 数据统一落盘目录

选完确认后，终端会自动刷新 Skill 包、计算 SQL 校验和、生成 MinIO 密钥，然后一次性进入 32 个子任务拉镜像（参考图 3 中的实时终端记录）：

.env updated: DEPLOYMENT_VERSION
Official skills refreshed at $HOME/nexent/official-skills-zip
.env updated: NEXENT_SQL_FILES_CHECKSUM
SQL files checksum: 349ea56f5f0d298d17bdf6ded7c7498b582e6a1ade2557f8b11a3cb5b33
Generating missing MinIO keys...
.env updated: MINIO_ACCESS_KEY
.env updated: MINIO_SECRET_KEY
MinIO keys generated successfully
Starting infrastructure services...
[+] Running 1/32
 - nexent-postgresql    Pulling ...
 - nexent-elasticsearch Pulling ...
 - redis                Pulling ...
 - nexent-minio         Pulled

在这里插入图片描述

图 3　deploy.sh docker 终端 TUI 选型与基础设施镜像拉取实时输出

首次全量拉取 10.44 GB 镜像在常规国内网络下大约需要 40 分钟。遇到某一个层卡住十分钟以上不动，别干等，先用 Ctrl+C 中断后去对应仓库查一下该 tag 是否缺包。社区实录里 Elasticsearch 曾卡在 elastic.m.daocloud.io，手动从 Docker Hub 拉同名版本再用 docker tag 改名后，重新执行脚本就能接上进度继续。

如果后面要写进脚本做重复部署，也可以跳过 TUI 直接传参（--defaults 会优先读取上次保存在 deploy.options 的历史选择）：

bash deploy.sh --defaults docker \
  --components infrastructure,application,data-process \
  --port-policy development \
  --image-source mainland \
  --version v2.8.2 \
  --root-dir "$HOME/nexent-data"

2.4 容器启动后怎么才算真健康

脚本提示启动完成后，先别急着切浏览器。跑两条命令看一眼每个容器的 STATUS 和 3000 端口响应头：

# 1. 按名称、镜像、运行状态和端口映射格式化查看所有 Nexent 容器
docker ps -a --filter "name=nexent" --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

# 2. 如果发现某容器状态不是 Up 或反复 Restarting，直接拉最近 60 行日志定位
docker ps -a --filter "status=exited" --format "{{.Names}}" | xargs -r docker logs --tail 60

# 3. 验证前端入口端口返回状态（预期 HTTP/1.1 200 OK 或 307 重定向）
curl -I http://localhost:3000

重点盯住 nexent-postgresql、nexent-elasticsearch、nexent-minio 和 nexent-config 这几行状态是否全部变成 Up ... (healthy)。有时候终端已经返回命令行，但 Elasticsearch 还在做首轮索引初始化，多等十几秒再刷 curl -I http://localhost:3000 就能拿到 200 OK。

三、单机免登录 vs 多租户：为什么超管登进去没有工作台

服务就绪后，在浏览器打开 http://localhost:3000。接下来看到的页面，完全取决于你刚才在 components 里有没有勾选 supabase。

3.1 单机模式：直达工作台与完整左侧导航

像这次一样只勾 infrastructure、application 和 data-process，系统会以单机免登录模式启动，打开 3000 端口直接落进工作台主界面。

在这里插入图片描述

图 4　单机模式打开 http://localhost:3000 直达工作台，左侧 11 项核心模块全部展开

把左侧菜单展开可以看到，从上到下排着「工作台」「智能体对话」「自动任务」「模型配置」「知识库配置」「智能体配置」「记忆配置」「Agent 仓库」「MCP 仓库」「Skill 仓库」「资源管理」。中间输入框上方提示橙色的「暂无可用模型」，说明平台本身已经就绪，只差接入一个模型。

3.2 多租户模式的常见误会：超管只管建租户，不进工作台

如果你为了团队试用勾选了 supabase，访问 http://localhost:3000 会先停在登录页。超级管理员默认账号是 suadmin@nexent.com，默认密码 Nexent@123（如果 .env 里改过则以修改后的为准）。

不少人第一次用超管登录会吓一跳：左边只有一个「租户资源管理」，工作台、模型配置、智能体配置全都不见了，第一反应就是「镜像是不是拉缺了」。

其实容器没缺，这是 Nexent v2 的多租户权限边界设计：超级管理员（SU）负责管理平台与创建租户，本身不隶属于任何一个具体租户；而对话、模型和知识库都属于租户内部资源。 正确切换顺序就三步：

  1. 用 suadmin@nexent.com 登录，在「租户资源管理」里新建一个租户和对应的租户管理员账号（或者在「邀请码」页签生成管理员邀请码去登录页注册）。
  2. 退出超管账号。
  3. 换用刚创建的租户管理员账号重新登录，完整的 11 个工作台模块就会立刻出现。

四、接通 Mac 本地 Ollama 与「401 假过期」排查

接下来把模型接进来。因为本地 Mac Studio 上已经跑着 Ollama 和 qwen3:30b，我就直接把本地推理接入 Nexent，顺手省掉云端 API Key 费用。

4.1 宿主机 Ollama 确认与容器内网桥地址要点

在去浏览器填表之前，先花十秒在 Mac 终端确认 Ollama 已经拉取了 qwen3:30b，并且 OpenAI 兼容接口 /v1/models 正常响应：

# 1. 确认 Mac 本地已存在目标模型
ollama list | grep qwen3

# 2. 验证宿主机 11434 端口的 OpenAI 兼容接口能正常返回模型清单
curl -s http://localhost:11434/v1/models | head -c 300

确认宿主机有输出之后，再测试 Docker 容器内部能不能通过 host.docker.internal 访问到这台 Mac（如果正在排查连接失败，这条命令能一锤定音）：

# 从 Docker 容器网桥视角探测宿主机 Ollama 是否可达（返回 200 即表示跨网桥已打通）
docker run --rm --add-host=host.docker.internal:host-gateway curlimages/curl:latest \
  -s -o /dev/null -w "HTTP状态码: %{http_code}\n" http://host.docker.internal:11434/v1/models

记住这个规则：在 Mac / Windows 的 Docker Desktop 里访问宿主机 Ollama，Base URL 必须写 http://host.docker.internal:11434/v1，不要写 localhost 或 127.0.0.1。

如果换到 Linux Docker Engine 复现，Linux 默认不会自动映射 host.docker.internal。这时需要两步配合：先配置 OLLAMA_HOST=0.0.0.0 让宿主机 Ollama 监听全部网卡，再改填网桥网关 IP（常见为 http://172.17.0.1:11434/v1）。

也可以直接在 Compose 里加上 extra_hosts: ["host.docker.internal:host-gateway"]，保持内外地址写法一致。

4.2 在工作台配置 Ollama Qwen3 30B 并检查连通性

回到 Nexent 左侧「模型配置」，点击「添加模型 → 单个添加」，按下面参数填进弹窗（对应图 5 右侧）：

  • 服务商：选「自定义」（来源会自动标记为 OpenAI-API-Compatible）
  • 模型类型：大语言模型
  • 模型名称：qwen3:30b（必须与 ollama list 输出的模型 ID 完全一致）
  • 展示名称：Ollama Qwen3 30B（便于界面识别）
  • Base URL：http://host.docker.internal:11434/v1
  • API Key：本地 Ollama 不校验鉴权，按非空占位格式填 ollama 或 sk-local 即可

在这里插入图片描述

图 5　模型设置页实测接入本地 Ollama Qwen3 30B（qwen3:30b），连通状态显示绿色「可用」

填完可以先点弹窗底部的「检测连通性」，也可以保存后在列表页点右上角「检查模型连通性」。左侧列表状态变成绿色 ● 可用，同时顶部「大语言模型（必填）」下拉框已自动绑定 Ollama Qwen3 30B，就算正式接通。

如果模型列表上方挂了一条提示「1 个 LLM/VLM 模型中 1 个缺少容量字段」，这属于非阻塞提醒，不影响正常聊天；真要生成超长文本时，点模型卡片右侧编辑按钮打开「高级设置」，手动补上最大输出 Token 即可。后续如果要搭知识库（RAG），建议顺手再配一个 Embedding 模型（社区 v2.8.2 实测常用 BAAI/bge-m3，维度 1024）。

4.3 深挖一次：「获取模型列表」弹出「登录已过期」是怎么回事

如果你用「批量添加」接入外部云厂商模型，点击「获取模型列表」时可能会撞上一个很迷惑人的弹窗——界面提示「登录已过期」，哪怕注销重登再试，还是弹同一句话。

追查接口请求链路后就能解开这个谜：后端路由 POST /api/model/provider/create 会把模型服务商返回的 HTTP 状态码直接透传回前端，而前端拦截器把所有 401 状态码一刀切地弹窗提示成「登录已过期」。

遇到这种情况先别急着清缓存。除了在浏览器开发者工具（Mac 按 Cmd + Option + I）的 Network 里看 POST /api/model/provider/create 的 Response.detail，更直接的办法是在本地跑一段独立探针脚本，绕开 Nexent 前端，先确认上游模型接口本身给没给 401：

import json
import os
import urllib.error
import urllib.request

# 排查线上厂商或本地 Ollama 时，先在终端导出变量：
# export MODEL_BASE_URL="https://api.example.com/v1" MODEL_API_KEY="sk-your-key"
BASE_URL = os.getenv("MODEL_BASE_URL", "http://localhost:11434/v1").rstrip("/")
API_KEY = os.getenv("MODEL_API_KEY", "ollama")

def probe_models_endpoint(base_url: str, api_key: str) -> None:
    """直接探测 /models 端点，区分「上游 API 鉴权失败 401」与「Nexent 会话过期」"""
    req = urllib.request.Request(
        f"{base_url}/models",
        headers={"Authorization": f"Bearer {api_key}", "Accept": "application/json"},
        method="GET",
    )
    try:
        with urllib.request.urlopen(req, timeout=8) as resp:
            payload = json.loads(resp.read().decode("utf-8"))
            ids = [item.get("id") for item in payload.get("data", [])]
            print(f"[PASS] HTTP {resp.status} -> 共返回 {len(ids)} 个模型: {ids[:5]}")
    except urllib.error.HTTPError as err:
        detail = err.read().decode("utf-8", errors="ignore")
        if err.code == 401:
            print(f"[UPSTREAM_401] 上游模型接口拒绝了 API Key: {detail}")
            print("排查结论：问题在模型服务商 URL/Key，不是 Nexent 登录过期。")
        elif err.code == 404:
            print(f"[PATH_404] 路径不存在，检查 Base URL 末尾是否漏了 /v1（当前: {base_url}）")
        else:
            print(f"[HTTP_{err.code}] {detail}")
    except Exception as exc:
        print(f"[NET_ERR] 无法连通 {base_url} -> {exc}")

if __name__ == "__main__":
    probe_models_endpoint(BASE_URL, API_KEY)

脚本实际跑完只会落在三种清晰结果里（比对报错立刻分清责任边界）：

# 情况 A：本地 Ollama 或云端 Key 正确时
[PASS] HTTP 200 -> 共返回 1 个模型: ['qwen3:30b']

# 情况 B：云厂商 Key 填错、欠费或选错区域域名（此时 Nexent 前端会误报「登录已过期」）
[UPSTREAM_401] 上游模型接口拒绝了 API Key: {"error":{"message":"Incorrect API key provided"}}
排查结论：问题在模型服务商 URL/Key，不是 Nexent 登录过期。

# 情况 C：如果这里返回 [PASS]，但 Network 里 Nexent 接口仍报 token expired，才是会话真过期

先用脚本过一遍接口，基本三十秒就能把「上游鉴权失败」和「平台会话失效」彻底拆开，不用在重新登录的死循环里打转。

4.4 首轮对话端到端验证：8.17s 跑通，Reasoning 过程全透明

模型状态确认绿色「可用」后，点左侧「工作台 → 新对话」，选中刚才配好的 Ollama Qwen3 30B，发一句 "你好" 做完整链路验证。

在这里插入图片描述

图 6　工作台发送「你好」后完整输出 6 步 Reasoning 推理过程与正式回复（耗时 8.17s，上下文占 14%）

这张首轮回复图其实最能体现 Nexent 在开发调试上的用心。它没有把模型的思考过程吞掉，而是在正文上方单独折叠了一块 Reasoning 面板，把当前时间判断、是否需要调用工具/技能、边界条件检查和中文 Markdown 输出决策一行行摊开；回复右下角直接标出本次生成耗时 8.17s 和本轮上下文占用比例 14%。

对于后面要接 MCP 工具或排查「为什么智能体没调工具」的场景，有这层可观测性会省掉大量盲猜成本。

五、部署与联调阶段真实踩坑速查

把这次 Mac 本地实操和社区 v2.8.2 记录里最容易卡住的几个报错按现象收成一张表，真碰上了直接按根因处理：

报错或异常现象真正原因对应处理方式
容器接本地 Ollama 报连接拒绝容器内 localhost 指向自身Base URL 改为 http://host.docker.internal:11434/v1
failed to resolve reference ".../nexent:v2.8.0": not found源码版本与镜像仓库 tag 未对齐切回镜像站实际同步的 tag（如 --branch v2.8.2）
某镜像层卡住 10 分钟以上无进度mainland 只加速应用源，基础镜像仍走公共源中断后从可用源手动 docker pull 并 docker tag 改名
超管 suadmin 登录后没有工作台多租户模式下超管只管平台与租户先建租户和租户管理员，退出后换新账号登录
批量拉模型弹窗「登录已过期」前端将后端透传的上游 401 统一渲染成会话过期用第 4.3 节探针脚本或 Network -> detail 核对服务商 Key
HTTP/1.1 421 Misdirected Request（接自定义 MCP 时）MCP SDK 默认开启 DNS 重绑定防护在自定义 MCP 服务侧关闭 enable_dns_rebinding_protection

六、实际跑下来的感受与下一步

把 Nexent v2.8.2 从空目录跑到首轮本地模型对话落地，最明显的感受是它对「本地验证智能体」这条路径打磨得挺克制：一条 deploy.sh docker 把存储、检索、对象服务和沙箱一次编排好，不用手搓几百行 Compose；单机免登录可以十分钟内看到工作台；对话界面又把 Reasoning、耗时和上下文占比摆在明面上，调试链路很透明。

当然它也有几个需要提前心里有数的门槛：全量镜像拉取吃网络且占磁盘（10.44 GB 镜像 + 数据卷）、默认端口较多容易撞上本地开发服务、以及多租户模式下超管视角与前端 401 提示语对新手不够直觉。把这篇文章里的加速源、版本 tag 和 host.docker.internal 三件事提前理顺，后面基本就能一路绿灯。

我这边接下来打算干两件事：先补接一个向量化模型 BAAI/bge-m3 往知识库丢几份长 PDF 测切片召回；然后直接用自然语言在工作台捏一个带本地工具的智能体，把 MCP 仓库 也连起来试试。

参考

# 人工智能 # Ollama # 深度学习
Logo
武汉城市开发者社区

为武汉地区的开发者提供学习、交流和合作的平台。社区聚集了众多技术爱好者和专业人士，涵盖了多个领域，包括人工智能、大数据、云计算、区块链等。社区定期举办技术分享、培训和活动，为开发者提供更多的学习和交流机会。

更多推荐

cover

手机/平板远控电脑哪个好用？ToDesk、向日葵、TeamViewer 六大维度实测对比

avatar 武汉城市开发者社区
cover

巨无霸 4 件套吃完了,我让腾讯WorkBuddy 算了一笔营养账

avatar 武汉城市开发者社区
cover

数据集市场 VS 自己写爬虫：什么时候该买，什么时候该抓？

avatar 武汉城市开发者社区