1. 项目整体思路：一台迷你主机和一个开源框架，怎么变成全天候员工

先说结论：我最近帮一位做龙虾养殖的朋友，用一台N602 Mini PC加开源智能体框架OpenClaw，搭了一套完全本地化的"数字员工"系统。24小时不关机，自动处理养殖日志、水质指标监控、客户询价回复，甚至能定时生成日报。整个过程不依赖任何外部SaaS平台，数据全在自己设备里，朋友调侃说这叫"安全养龙虾"——业务安全，数据也安全。

这个项目解决的核心问题其实很普遍：中小规模的养殖场、工坊、小团队，请不起专门的数字化团队，但又确实有大量重复性事务要处理。传统的做法是买成套的所谓"智慧农业系统"，贵不说，还经常绑定某家厂商，数据送上去就下不来了。而用Mini PC加开源智能体，本质上就是把一个能帮你干杂活的"数字员工"放在自己家里、自己池塘边，它不吃不喝不请假，还不会把你的数据往外传。

适合看这篇文章的人有三类：一是和我一样喜欢折腾本地部署的玩家，二是真正有养殖、种植或小型生产场景想降本增效的从业者，三是想理解"智能体落地到底怎么落"的产品或开发人员。我不会绕弯子，直接把这套系统的选型逻辑、部署步骤、遇到的坑和排查方法全部拆开讲。

先说清楚一个容易误解的点：这里说的"数字员工"不是一个聊天机器人挂在网页上。它是一组具有自主行动能力的程序——可以定时执行任务、按规则决策、调用工具去操作系统里的其他软件，甚至对接传感器数据。在龙虾养殖场景里，它相当于一个集"生产记录员、水质安全员、销售客服、数据分析师"于一体的虚拟岗位。而OpenClaw这类开源框架，负责把大模型的决策能力和外部工具的执行能力串起来。

2. 硬件选型与本地环境：为什么是N602 Mini PC而不是云服务器

2.1 一台迷你机能跑什么

N602 Mini PC从定位上就是为"本地轻量级服务"设计的。它体积大概和一本厚词典差不多，功耗只有十几瓦到二十几瓦的水平，比一盏老式白炽灯还省电。但它的核心配置并不弱：主流的多核处理器、16GB内存起步、支持NVMe固态硬盘，还带双千兆网口。这套配置跑一个智能体框架加一个轻量级本地模型推理，完全够用。

有人会问，为什么不直接上云服务器？我给朋友的回复是：养殖场的网络环境不稳定，而且水质数据和客户信息属于生产资料，放在别人服务器上心里不踏实。Mini PC放在场区本地，走内网访问，断电断网都不影响基础的数据采集和告警逻辑；即便需要外发通知，也只是偶尔通过手机网络发送一条告警短信。数据主权在自己手里，这是本地部署不可替代的价值。

2.2 系统环境与运行时准备

我选的是64位Linux发行版，原因很朴素：稳定、内存占用小、适合长时间挂机。安装完之后做了几个基础优化，这些都是长期跑服务的必备操作：

• 关闭图形桌面环境，开机直接进命令行模式，省下大约1GB内存。
• 配置好SSH远程登录，这样在家里就能维护场区的机器。
• 开启自动安全更新，同时设置每日定时重启不现实，改为按周错峰重启一次。
• 给系统盘做了LVM逻辑卷管理，方便后续扩容。

运行时方面，我用了容器来隔离OpenClaw框架和它依赖的组件。容器的好处是依赖不冲突、升级方便、回滚也快。我把整个数字员工环境定义成一个容器编排文件，所有服务的镜像版本都固定好，避免"昨天还能跑，今天更新后崩了"的尴尬。

2.3 模型怎么选：本地推理还是API调用

这是整套方案里最需要权衡的地方。OpenClaw本身不生产模型，它是负责调度和执行的框架，决策靠的是大模型。我在实验阶段试过两种方式：

第一种是接远程大模型API，效果最好，但需要联网，而且每轮对话都产生费用，养殖场一天几千条水质记录和分析请求，成本压不住。第二种是本地部署开源模型，用量化版本把模型体积压到4GB左右，推理速度虽然比不上云端旗舰模型，但用于指令解析、数据分类、模板化回复这些任务，已经绰绰有余。

我的建议是混合策略：核心的指令理解和决策走本地模型，保证离线可用；如果场地有稳定的网络，可以把"客户询价后的个性化回复生成"这一路请求转发到云端API，其余全部留在本地。这种"本地为主、云端为辅"的架构，既保住了数据安全底线，又不牺牲需要复杂语义理解的场景体验。

3. 数字员工的功能设计与核心实现

3.1 功能清单：四个虚拟岗位

我把这套数字员工的职能拆成四个模块，对应养殖场的四个痛点：

第一个是生产记录员。养殖户每天要记录投喂量、水温、溶氧量、pH值、虾体状态等数据。过去是手写纸本或Excel，整理麻烦，还容易漏。数字员工通过一个简易表单页面收集数据，自动校验字段合法性，写进本地数据库，并生成趋势曲线。

第二个是水质安全员。系统定时从水质检测设备接口拉取数据，设定好每种指标的阈值范围。一旦超出，立刻通过企业微信或短信通知场主。这里的关键是告警不能只报"超标了"，还要给出建议动作。比如"溶氧量低于4mg/L，建议开启增氧机并减少投喂"。

第三个是销售客服。龙虾养殖场经常有批发商、饭店打电话来询价。数字员工接上电话转写的接口后，可以自动回答规格、价格、起订量、配送范围等高频问题；如果客户问的是特殊定制需求，它会转给人工，并把对话摘要推送到场主手机上。

第四个是数据分析师。每天凌晨两点，数字员工自动汇总当天数据，生成一份日报：投喂总量、水质异常次数、存活率估算、待处理事项。每周再出一份周报，横向对比本周和上周的指标变化。

3.2 工具调用与任务编排：让模型动手而不是只动嘴

智能体区别于普通问答机器人的核心点是"工具调用"。OpenClaw这类框架会预先注册一批工具，比如"写入数据库""读取水质接口""发送告警消息""查询库存表"。当模型分析用户意图后，不是直接输出一段文本，而是输出一个结构化的工具调用请求，框架再去执行对应的代码，然后把结果返回给模型继续决策。

举个例子，朋友打电话问"今天能不能送200斤中规格的龙虾到市区"，电话转写文本进入系统后，本地模型先把它拆成意图："查库存、查中规格是否满足200斤、查今天配送时段"；然后框架依次调用库存查询工具和配送规则工具；最后汇总结果，生成回复："目前中规格存塘量足够，今天下午三点前可以安排发货，预计六点前送达。"

这个流程里，模型做出的每一个决策都被工具的执行结果校验过，而不是凭印象"胡说"。这也是我坚持本地部署的原因之一：工具执行过程中涉及库存数据、价格目录这些核心经营信息，绝不希望它们成为模型服务商的训练语料。

3.3 安全设计：从权限到审计

"安全养龙虾"这个说法，在技术上落地为四层：

第一层是网络隔离。Mini PC上开了两个网口，一个接内网，一个接外网，中间用防火墙规则限制：内网设备可以访问数字员工的管理页面，但数字员工访问内网设备只允许按白名单走特定端口。

第二层是权限控制。数字员工执行写操作、删操作前，必须经过一个"危险动作二次确认"机制。比如模型决定要清除某一天的异常数据，框架会拦截这次操作，先给场主发一条确认消息，场主回复确认码后才放行。

第三层是操作审计。所有工具调用记录、模型决策理由、执行结果都写入独立的审计日志。这个日志只能追加、不能修改，定期打包存档。这样如果有数据误改，也能追溯到是哪一轮对话、哪一次调用导致的。

第四层是模型输出过滤。本地模型偶尔也会生成不合适的建议，比如在未授权的情况下承诺客户价格、或者给出不科学的用药方案。我在框架里加了一道输出规则引擎，命中敏感动作关键词时，强制改为转人工处理。

4. 实操部署：从空机器到数字员工上线的完整过程

4.1 第一步：初始化基础环境

机器通电装好系统后，我习惯先跑一遍环境初始化脚本。这里给出一段关键命令示例，你可以在自己的Mini PC或者任何一台闲置电脑上试：

# 更新系统并安装基础工具 sudo apt update && sudo apt upgrade -y sudo apt install -y git curl wget jq sqlite3 python3-venv # 创建专用用户，避免用 root 跑服务 sudo useradd -m -s /bin/bash digiworker sudo usermod -aG docker digiworker # 调整时区为本地时区，确保日报时间正确 sudo timedatectl set-timezone Asia/Shanghai

这一步有几个容易忽略的细节。一是最好用专用低权限用户运行服务，不要图方便用root。二是我把系统时区显式设置了一次，否则后面生成的日报时间会和本地时间对不上，排查起来很头疼。三是装好jq，这个命令行JSON解析工具在后面调试接口时几乎离不开。

4.2 第二步：启动OpenClaw核心服务

我用容器方式部署OpenClaw框架。以下是一个简化版的容器编排文件，展示了核心服务的组成：

version: "3.8" services: openclaw-core: image: openclaw/core:2.4.1 container_name: openclaw-core restart: always volumes: - ./config:/etc/openclaw - ./logs:/var/log/openclaw - ./data:/var/lib/openclaw environment: - TZ=Asia/Shanghai - OPENCLAW_MODE=production - LOCAL_MODEL_ENDPOINT=http://local-llm:8080/v1 - DANGER_ACTION_CONFIRM=on networks: - digit ports: - "8080:8080" local-llm: image: openclaw/llm-runtime:0.9.3 container_name: local-llm restart: always volumes: - ./models:/models command: ["--model", "/models/lobster-q4.gguf", "--ctx", "4096"] networks: - digit scheduler: image: openclaw/cron-helper:1.1.0 container_name: openclaw-scheduler restart: always volumes: - ./tasks:/etc/tasks networks: - digit networks: digit: driver: bridge

这个编排的核心思路是三个独立容器各干各的：openclaw-core负责接收请求、调度工具、维护会话状态；local-llm负责模型推理，暴露一个兼容OpenAI格式的接口；scheduler负责定时任务触发，比如每小时拉取一次水质数据、凌晨汇总日报。

部署后我首先验证的不是业务功能，而是"核心服务是否会自动重启"。容器编排里的restart: always保证了即使Mini PC断电重启，服务也会自动拉起。这个特性对无人值守场景至关重要——养殖场不可能每次停电都找人去手动启动服务。

4.3 第三步：配置任务链和工具

框架起来之后，真正的工作是画"任务链"。所谓任务链，是把一个业务目标拆成多步骤调用。比如"水质巡检告警"这个任务链，我会在配置文件里定义成这样：

tasks: water_quality_check: schedule: "*/30 * * * *" chain: - tool: sensor_reader params: device: "pond-2" indicators: ["temperature", "dissolved_oxygen", "ph", "ammonia"] - tool: threshold_evaluator params: rules_file: "/etc/openclaw/rules/water_thresholds.yaml" - tool: alert_notifier params: channel: "mobile_message" template: "water_alert" - tool: audit_logger params: event: "water_quality_check_finished"

这段配置的每一步都对应一个具体的函数或脚本。sensor_reader从水质监测设备拉数据，threshold_evaluator去匹配预设的阈值规则，alert_notifier决定是否发告警，audit_logger记录执行痕迹。注意我把阈值规则单独放在rules/water_thresholds.yaml，而不是写死在代码里，因为养殖户经常要根据季节、龙虾生长阶段调整阈值，单独维护一份规则文件要方便得多。

这里有一个我在项目中反复强调的原则：智能体任务链里的每一步都必须可观测、可回放。任何一步失败，都留下明确日志；任何一次告警，都记录触发依据。这有点像飞机上的黑匣子，平时没人看，出问题时它就是你唯一的救命稻草。

4.4 第四步：对接业务数据与消息通道

数字员工要真正干活，必须和实际业务系统打通。我在项目里做了三类对接：

第一类是养殖数据库。我用SQLite存结构化数据，但对外暴露的是封装好的工具接口，模型不能直接拼SQL去查，只能调用我注册的"按日期查投喂量""按池塘查水质历史"这类白名单接口。好处是即使模型被提示词注入攻击，也无法跳出预定义的数据访问范围。

第二类是电话和消息通道。这里用了运营商提供的电话转写能力，转写文本自动推送到数字员工的HTTP接口上；外发通知则走消息网关。我在网关前加了一层"关键字过滤器"，只有经过规则允许的通知类型才能外发，避免模型自主给任意号码发消息。

第三类是养殖户的操作界面。我搭了一个极简的Web面板，用手机浏览器就能打开，主要用来确认危险操作、查看告警历史、手工录入数据。面板本身不承载复杂逻辑，所有智能决策都发生在框架层。

4.5 第五步：测试集与上线标准

上线前我没有直接让数字员工全权接管，而是设计了一套测试集，模拟一个月的数据量，跑了两周"影子模式"。影子模式的意思是：系统照常执行所有任务链，但告警消息和危险动作只记录不实际发送、不实际执行。我拿这套历史数据去对比数字员工的判断和人工判断，看它是否足够可靠。

测试集中包含的典型场景有：温度骤降时是否及时告警；pH值连续两天偏高时是否建议调整水质；客户询"有没有大规格的虾"时是否准确匹配库存；深夜收到异常请求时是否触发了人工转接。我的通过标准是：告警准确率达到95%以上，重大误报为零，危险动作拦截率百分之百。达不到就继续调规则和提示词，直到满足为止。

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

5.1 症状一：服务正常，但数字员工回复明显"犯迷糊"

这是最常遇到的问题。比如问它今天投喂量多少，它答非所问说了段水质建议。排查步骤我按顺序做：

第一步查会话上下文是否被撑爆。本地模型上下文长度有限，我设的是4096个token，如果任务链之间共用同一个会话，前面的工具调用记录会占用大量上下文，模型"忘记"当前任务。解决办法是为每种任务类型设置独立的会话空间，并在每次任务开始前清理历史步骤摘要。

第二步查意图分类规则。OpenClaw允许在每个任务链前挂一段"意图门禁"：先让模型判断用户输入属于哪类任务，再分流到对应链条。如果门禁规则写得太模糊，"查询投喂量"和"分析投喂趋势"可能被分到同一个链路上，结果就乱了。

第三步查数据格式。工具返回的数据是JSON格式，但模型在生成回复时偶尔会盯着原始JSON而不提取关键字段。我在提示词里加了明确要求："你只需要关注data字段中的数值，忽略meta调试信息。"这个问题就不复现了。

5.2 症状二：内存持续增长，几天后系统卡死

Mini PC的内存就16GB，跑容器、模型推理、数据库，资源本来紧巴巴。第一次遇到卡死的时候，我怀疑是模型推理进程内存泄漏，后来排查发现罪魁祸首是审计日志库的索引膨胀。

诊断方法是看系统日志里的OOM Killer记录，再逐个容器检查内存占用曲线。定位到是日志写入越来越慢后，我的解决措施是：为审计日志单独设置轮转策略，每天归档一次，保留90天；给SQLite设置WAL模式，减少锁竞争；并给系统加了一个简单的内存监控脚本——当可用内存低于20%时，自动清理旧的临时文件并重启一次调度容器。

这里我要强调一个经验：不要相信"重启治百病"，但也不能否认重启是成本最低的临时恢复手段。我在调度任务里加了一条每月1号凌晨4点的定时重启，专门清理不可预见的资源碎片。生产业务已经跑了大半年，再也没有出现过卡死的情况。

5.3 症状三：告警风暴——连续夜里收到十几条重复告警

水位传感器偶发数据抖动，导致水位指标短时间内在阈值边缘反复横跳，数字员工就不停发告警。这种告警风暴在运维圈有个专门说法叫"抖动告警"，很磨人。

我的处理方式是在告警工具里加了两道机制：一是"连续确认"机制，只有当连续三次采集都超标时才真正触发告警；二是"冷却时间"机制，同一个告警类型在30分钟内只发送一次，后续状态变化合并到下一次摘要中。这两个机制的参数都可以在规则文件里调，不用改代码。

另一个相关的坑是告警模板太僵硬。之前模板写的是"溶氧量低于阈值，请处理"，没有任何上下文。我后来把模板改成动态组装：带上当前值、前一天同时段对比值、最近一次正常时间点、建议动作。这样告警消息本身就能指导操作，场主不需要再打开系统去查细节。

5.4 症状四：断电后服务起来了，但任务链"卡住"不执行

Mini PC断电重启后，容器虽然自动恢复了，但调度器里记录的上一次任务状态可能还是"执行中"，导致后续任务不触发。这个问题很隐蔽，因为从日志看所有服务都正常。

解决办法是给任务链加一个"僵死检测"逻辑：调度器启动后，先扫描所有状态为"执行中"的任务，如果开始时间早于当前时间超过任务超时上限，就强制标记为"失败"，并执行一次补偿操作（比如重新拉取一次水质数据）。这样即使系统在任务中途崩溃，恢复后也能回到一致状态，而不是卡在死胡同里。

5.5 常见问题速查表

这张表我建议你直接抄走贴在电脑边。实际运维中百分之八十的问题，都能在上面几行里找到对应的影子。

6. 踩坑后的几点体会

整套系统从构思到稳定运行，前后花了大约三周。第一周在试框架和模型，第二周在搭任务链和业务对接，第三周基本都在处理上面说的那些"想不到"的问题。

最深的体会是：智能体项目里的模型能力不是瓶颈，工程稳定性和安全设计才是。模型说错一句话，你可以重试；但任务链在凌晨三点卡死、告警没发出去，那是实打实的损失。所以我在设计每一条任务链时，都默认它会失败，然后问自己三个问题：失败后如何感知？如何恢复？是否需要人工兜底？这三个问题想清楚了，系统才算真正能无人值守。

另外一个体会是关于"数字员工"这个概念的定位。它不是一个超越员工的"人工智能"，而是一个尽职尽责的"新员工"——它不会创新，但可以不知疲倦地执行标准流程；它不会主动思考业务战略，但可以把人从重复琐碎的工作里解放出来。想清楚这一点，你就不会对它有错误的期待，也不会在设计时过度复杂化。

如果你也想在某个具体场景里落地类似的数字员工，我的建议是从最小的闭环开始，比如只有"定时上报数据、异常发通知"这一个功能。让它先跑一周，稳定了再加下一个功能。别一上来就规划十个模块，否则你连问题出在哪个模块里都查不过来。

最后再分享一个小技巧：给数字员工起一个固定的名字，比如我管这套系统叫"小潜"。在所有告警短信、日报邮件、客服回复的落款都署名"小潜"。这个细节其实很有用——场里的工人看到消息知道是系统发的，不会误以为是私人信息；客户也慢慢习惯了"小潜"这个客服角色，沟通反而顺畅了。工具是冷的，但用工具的方式可以是暖的。