Perplexity AI 提出的 Portable Computer 方向本质上是把 AI 智能体从云端搬到个人设备上一个在本地运行、持有个人上下文、可以调用工具完成任务的智能体应用。这个方向对开发者的启发比产品本身更大——它意味着本地大模型、智能体编排和个人知识库的组合已经具备在普通电脑上落地的基础。下面不讨论商业细节而是从技术实现角度用 Ollama、Dify 和本地大模型搭建一个最小可用的本地智能体应用覆盖概念、环境、实现、验证和排错五个环节。读完以后你可以把同一个知识库、同一套工具接入方式迁移到自己的业务场景里。1. 先理解 Portable Computer 本地智能体到底解决了什么问题1.1 本地智能体是什么智能体Agent和普通聊天机器人最大的区别是它不止“回答”还会“做事”。一个典型智能体由四部分组成大模型负责理解和决策规划器负责拆解目标工具负责执行动作记忆负责保存上下文。普通对话模型拿到问题直接生成答案而智能体会先判断“这个问题要不要查知识库、要不要调接口、要不要算一下”再决定下一步动作。本地智能体应用就是把上面这条链路全部放在用户自己的设备上运行。Portable Computer 这个命名想强调的是“可携带的个人计算机”而不是“随身携带的硬件盒子”。从公开信息看它的产品形态是本地优先、数据本地保存、模型可以由用户自行替换的智能体应用。这类应用解决的核心问题有三类隐私数据不出设备、无网络也能使用、开发者可以完全掌控提示词和工具逻辑。1.2 云端 Agent 与本地 Agent 的取舍对比维度云端 Agent本地 Agent数据隐私数据经过服务商数据留在本机离线可用依赖网络网络中断仍可运行响应延迟受网络和排队影响主要取决于本机算力模型规模可调用数百亿参数模型受内存和显存限制更新成本服务商维护自己维护模型和依赖定制自由度受平台限制完全可控选择本地方案并不是因为本地模型一定比云端模型聪明而是因为很多场景的核心诉求是隐私、成本和可控性。比如企业内部知识问答文档不能传到外部服务再比如个人助理类应用用户希望对话记录和文件索引全部留在本地。理解了这一点就能明白 Portable Computer 这类产品为什么值得关注它不是要取代云端大模型而是补足了“敏感数据 个性化上下文 本地执行”这个空白。1.3 本地智能体的典型四层架构一个本地智能体应用可以拆成四层模型层本地大语言模型、Embedding 模型负责生成、推理、向量化。编排层智能体工作流负责把用户请求拆解成“检索知识库、调用工具、生成回复”等步骤。工具层可执行的 API、脚本、数据库查询、本地文件操作。交互层Web 页面、桌面端或命令行入口。下文选择 Ollama 作为模型管理工具用 Dify 社区版作为编排层。这套组合的优势是Ollama 屏蔽了模型下载、量化、启动的细节Dify 提供了可视化工作流、知识库、工具管理和对话界面两个工具都有活跃社区适合作为本地智能体的入门基座。2. 搭建前要把环境、硬件和版本预期对齐2.1 硬件与系统要求本地跑智能体最怕的不是代码写错而是模型加载后内存不够。先按自己的机器确定预期再动手。档位配置适合场景入门8GB 内存无独立显卡跑 3B 到 7B 参数的量化模型纯 CPU 推理推荐16GB 到 32GB 内存跑 7B 到 14B 参数模型配合 RAG 知识库进阶32GB 以上内存6GB 以上显存跑更大模型、多用户使用、高频调用系统方面Windows、macOS、Linux 都能装 OllamaDify 依赖 Docker所以需要提前装好 Docker Desktop 或 Docker Engine。磁盘建议预留 20GB 以上因为大模型文件动辄 4GB 到 10GB知识库和日志还会持续增长。2.2 安装 Ollama 并准备本地模型Ollama 的作用是统一管理模型下载和本地推理服务。安装完成后用一条命令就能拉取模型并暴露一个 OpenAI 兼容的本地接口。# Linux / macOS 安装脚本 curl -fsSL https://ollama.com/install.sh | sh # Windows 用户直接下载安装程序安装后验证 ollama --version # 拉取一个 7B 参数级别的对话模型 ollama pull deepseek-r1:7b # 查看本地已有模型 ollama list这里要注意模型名称和参数版本会随着时间更新落地前先到 Ollama 模型库确认当前推荐名称。7B 模型在 16GB 内存机器上比较稳妥如果机器配置更高可以尝试更大的参数版本如果内存紧张优先选择带量化标识的版本例如文件名或标签中包含q4、q8的它们体积更小、加载更快。后续还要准备一个 Embedding 模型用于知识库例如ollama pull bge-m3。2.3 用 Docker 启动 Dify 社区版Dify 负责把模型、知识库、工具和工作流串起来。社区版支持本地部署安装方式以 Docker Compose 为主。git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d docker compose ps第一次启动会拉取多个镜像耗时取决于网络状况。启动完成后浏览器访问http://localhost就可以进入 Dify 设置页面。如果本机 80 端口被占用需要修改.env或docker-compose.yml中的端口映射改完再执行一次docker compose up -d。2.4 先确认三条关键链路本地智能体涉及三个端口搭建前先确认它们在防火墙和容器网络中是可达的服务默认端口说明Ollama API11434模型推理服务Dify Web80 / 443管理后台和对话界面Dify API5001后端 API按需要开放还有一个容易踩坑的点Dify 跑在 Docker 容器里容器访问宿主机上的 Ollama不能直接写localhost:11434。macOS 和 Windows 的 Docker Desktop 支持http://host.docker.internal:11434Linux 上需要填写宿主机局域网 IP并且要把 Ollama 服务绑定到非回环地址否则容器永远连不上。这个细节在下一节会具体操作。3. 跑通最小本地智能体从模型到对话3.1 先验证 Ollama 服务可用启动 Ollama 服务并用接口确认模型已经就绪。# 前台启动保持终端开启 ollama serve # 另开一个终端验证模型列表 curl http://localhost:11434/api/tags正常返回的 JSON 里会包含已拉取模型的信息。这一步能提前发现模型是否下载完整、服务是否监听正确避免后面在 Dify 里排查半天。3.2 在 Dify 中接入 Ollama 模型进入 Dify 后台选择“设置 - 模型供应商 - Ollama”填写连接信息。Base URLmacOS / Windows 填http://host.docker.internal:11434Linux 填http://宿主机IP:11434。模型类型选择“LLM”。模型名称必须和ollama list输出完全一致例如deepseek-r1:7b。上下文长度根据模型支持范围填写小内存机器不要盲目调大。Temperature先填 0.7后续按效果调整。保存后Dify 会尝试调用一次模型如果失败优先检查 Base URL 可达性和模型名称。这里还建议接入 Embedding 模型操作路径相同模型类型选择Text Embedding名称填bge-m3。3.3 创建第一个对话型智能体在 Dify 中点击“创建应用”选择“Agent”类型。Agent 类型相比纯聊天应用多出了“工具调用”能力更适合演示本地智能体的完整链路。创建一个系统提示词明确告诉智能体“你是本地个人助理优先使用知识库回答不确定时直接说明”。然后选择刚才配置好的 Ollama 模型保存后在调试界面发一条消息。如果模型能正常回复说明“本地模型 编排平台”这条主链路已经通了。注意先不要急着加知识库和工具。最小闭环的目标是让模型能通过 Dify 调用本地 Ollama 并返回结果这一步成功后再逐步叠加能力。3.4 加入知识库让智能体拥有本地记忆知识库是本地智能体最有价值的模块。选择“知识库 - 创建知识库”上传一个 Markdown 或 PDF 文档例如一份产品手册。分段设置里块大小填 500重叠长度填 50Embedding 模型选择刚才接入的bge-m3。索引完成后在应用设置里关联该知识库并把“知识库检索”作为智能体的可用工具。之后提问“手册里关于导出功能的步骤是什么”智能体就会先检索知识库再基于检索结果生成回答。这一步跑通后你就拥有了一个不依赖外部服务的私有知识助理。4. 决定智能体上限的关键机制4.1 模型参数理解之后再调整参数含义调大影响调小影响建议Temperature采样随机性回答更多样、更发散更稳定、更保守知识问答 0.2 到 0.5创意任务 0.7 到 0.9Top-p核采样概率累计候选词更多候选词更少默认 0.9 附近与 Temperature 二选一调整Max Tokens单次生成上限回答更长防止超长根据任务设置默认即可Context Length可参考上下文长度记忆更多但更慢更占内存更快但容易截断小内存机器从 4096 开始在本地部署里Context Length 的影响最直接。它决定一次对话可以携带多少历史内容和知识库片段调大之后内存和显存占用会线性上升。如果出现“生成到一半卡住”或“频繁报内存不足”优先把上下文长度降下来。4.2 Embedding 与检索知识库不是把文件塞进去知识库的本质不是“把文件存进数据库”而是把文本切成块再将每一块转成向量。用户提问时系统把问题也转成向量通过相似度计算找到最相关的几个块最后把这些块作为上下文交给模型。分段策略直接决定检索质量。块太小语义不完整块太大噪声多且容易超出上下文。重叠长度可以缓解切块截断语义的问题。对技术文档500 到 800 字一块比较常用对合同、论文这类长段落文本可以适当增大。Embedding 模型的选择也很关键中文场景建议使用对中文支持好的模型bge-m3是常见选择之一。4.3 工具调用智能体“动手做事”的入口工具调用Function Calling让智能体不再只会生成文本而是可以触发真实动作。Dify 内置了部分工具也支持自定义 API 工具。一个自定义工具需要描述清楚“这个工具是做什么的、参数有哪些”。{ name: get_local_time, description: 获取指定城市的当前本地时间, parameters: { type: object, properties: { city: { type: string, description: 城市名称 } }, required: [city] } }底层逻辑是模型判断当前任务需要调用工具时会按 schema 输出一个结构化 JSON编排层解析 JSON、调用对应接口再把结果返回给模型生成最终回答。这里最容易踩坑的是小模型对结构化输出的支持不稳定可能输出格式错误或者不调用工具。如果工具调用频繁失败先确认模型本身支持 Function Calling或换一个能力更强的模型。4.4 会话记忆与上下文管理本地智能体要表现“像助理”必须记住对话历史。Dify 的会话机制会把用户消息和助手回复按轮次存储并在下一次请求时把历史记录组装进上下文。这里有个现实约束本地模型的上下文窗口有限。对话轮次越多可用空间越少最终要么报错要么截断知识库片段。实际项目里不要把全部历史都塞进模型而是做摘要或滑动窗口只携带最近几轮完整对话更早的内容压缩成摘要。这也是为什么生产级的本地智能体通常要配一个轻量级数据库专门保存会话记录而不是把所有状态都压在模型上下文里。5. 验证智能体是否真正可用5.1 功能验证三类测试问题只验证“能回复”远远不够。建议用三类问题测出智能体的真实状态。第一类纯知识问答比如“文档里提到的备份策略是什么”。它应该触发知识库检索回答内容能在原文中找到依据。第二类工具调用比如“帮我查一下北京当前时间”。它应该触发工具而不是编造时间。第三类边界问题比如“文档里没写的问题”。它应该诚实地说明不知道而不是幻觉编造。每一类都要记录是否走了正确链路、回答质量如何、耗时多少。如果知识问答没有触发检索去检查应用里是否启用了知识库工具如果编造了工具结果说明模型没有正确执行工具调用需要调整提示词或换模型。5.2 日志与指标从两层看运行状态本地智能体有两层日志要看。# Dify 层观察工作流、知识库检索和工具调用是否正常 docker compose logs -f api docker compose logs -f worker # Ollama 层观察模型加载、推理耗时和错误信息 journalctl -u ollama -fDify 日志里重点看请求是否进入知识库节点、工具是否返回成功Ollama 日志重点看模型加载耗时和推理异常。日志不是出错时才看而是功能验证阶段就要养成“查日志确认链路”的习惯这样后续排错才有依据。5.3 性能观察记录资源占用基线指标观察方式参考范围内存占用free -h7B 量化模型约占用 6GB 到 8GB显存占用nvidia-smi根据模型和上下文长度变化首字延迟对话界面计时纯 CPU 通常几秒GPU 应低于 1 秒生成速度Ollama 日志纯 CPU 约几个 token/秒GPU 快数倍记录一次完整的问答链路数据作为后续调优的基线。如果模型加载一次要几十秒说明要考虑常驻服务配置或换更小的量化模型。6. 本地智能体常见问题排查6.1 Dify 访问不到 Ollama现象在 Dify 中配置模型时提示连接失败或对话时一直报模型调用错误。原因和检查顺序先确认 Ollama 服务本身可用curl http://localhost:11434/api/tags。确认 Dify 容器里的 Base URL 不是localhost而是host.docker.internal或宿主机 IP。Linux 下如果宿主机 IP 也连不上检查 Ollama 是否只监听了127.0.0.1。修复方式启动 Ollama 时绑定所有网卡。OLLAMA_HOST0.0.0.0 ollama serve生产环境不要无脑绑定0.0.0.0要按实际网络环境限制访问来源避免局域网内其他人直接调用你的模型接口。6.2 模型下载失败或速度慢现象执行ollama pull长时间无进度或中途报错退出。处理建议先重试下载通常支持断点续传避免在磁盘空间不足时拉大模型提前用df -h检查空间如果 7B 模型频繁失败先换一个更小、量化程度更高的模型验证流程。不要因为一次下载失败就认定工具不可用网络波动、镜像源状态都会影响下载。6.3 内存或显存不足现象启动模型后系统卡顿或者生成一段时间后进程退出。检查内存和显存占用free -h nvidia-smi处理顺序降低 Context Length换更小参数或更高量化的模型关闭浏览器多余标签页和其他占用内存的程序纯 CPU 机器上关闭 GPU 相关配置。本地部署的通用原则是“先小后大”先用小模型跑通链路再根据资源余量升级。6.4 GPU 不工作与 nvlddmkm 事件 153现象明明是 NVIDIA 显卡nvidia-smi却看不到模型占用显存Windows 事件查看器频繁出现“无法找到来自源 nvlddmkm 的事件 ID 153 的描述”。原因这类系统事件通常表示显卡驱动异常或显示器驱动超时TDR常见诱因是驱动版本过老、显卡负载过重、供电不稳定或驱动和 CUDA 版本不匹配。它并不一定直接导致模型输出错误但会引起 GPU 推理不稳定、掉驱动甚至蓝屏。处理顺序更新显卡驱动到厂商提供的最新稳定版不要用旧版反复测试检查供电和散热临时降低模型量化和上下文长度减少 GPU 峰值负载如果问题仍然出现在任务管理器里观察 GPU 占用是否拉满。这个问题的核心是先把 GPU 环境稳定下来再谈调优模型。6.5 工具调用失败或返回格式错误现象智能体不调用工具或者调用后生成的参数是错的。检查方式在 Dify 调试页面查看模型输出看它是否生成了结构化的工具调用 JSON查看工具描述是否清晰确认当前模型是否支持 Function Calling。小模型对工具调用的支持不稳定表现为“能聊天但不能做事”。解决思路是换支持工具调用的模型或者简化工具参数 schema让模型更容易生成正确输出。6.6 排查顺序总表步骤检查内容1输入是否正确提示词是否表意清楚2文件路径、模型名称、服务名称是否一致3依赖版本和模型参数是否匹配4配置是否生效Base URL、环境变量、端口映射5网络、端口、权限是否可达6日志是否出现明确异常关键字7工具或框架本身的版本限制排查时不要跳跃式地乱试按这个顺序一层层验证多数问题都能定位到具体环节。7. 从演示到生产最佳实践与扩展方向7.1 学习环境与生产环境的差异本地跑通只是一个起点。演示环境里可以用docker compose up一把梭进入生产或团队使用阶段至少要补齐以下差异。维度学习环境生产环境配置写死在.env中配置外置化支持按环境切换日志容器终端查看统一日志采集和查询权限本机单用户用户体系、操作审计安全默认端口开放限制访问来源、密钥加密存储数据少量测试文件定期备份、版本管理回滚重装即可容器镜像版本化支持回滚监控手动看资源资源告警、服务健康检查模型任意版本固定版本、记录评测结果7.2 发布前检查清单把一个本地智能体整理成“可交付”的版本之前可以按这份清单过一遍模型版本固定不随手更新到未验证的版本。知识库文档更新流程明确重新索引不会影响在线服务。工具调用有超时和失败兜底不会因为单个工具报错导致整个流程中断。会话数据定期备份删除策略明确。模型接口不直接暴露给不可信网络必要时加认证。记录资源基线设定内存和磁盘告警。关键流程有自动化验证脚本而不是每次靠手工提问。7.3 扩展方向跑通最小闭环之后可以沿着四个方向继续深入。第一多智能体协作。把“检索知识库”和“调用业务工具”拆成不同智能体由主智能体调度适合复杂任务场景。第二工具协议标准化。目前主流方向是给智能体配置统一的工具调用协议比如 Model Context Protocol让工具和服务可以复用而不是每个应用单独写一套接入。第三端侧化。量化、剪枝、端侧推理引擎可以让模型跑进更低配设备这是 Portable Computer 这类本地应用的硬件基础。第四评测体系。给知识问答、工具调用、拒答能力建立测试集每次换模型或改配置都跑一遍避免“调好了这个弄坏了那个”。如果只记一句话本地智能体应用的核心不是把模型装进电脑而是把模型、知识库、工具和会话记忆四层串成一条可验证的链路。建议从最小对话型 Agent 开始先跑通再扩展不要一开始就追求复杂工作流。能稳定复现的简单流程价值远大于经常中断的复杂设计。