【运维】Mac 全自动自媒体运营系统：完整技术方案 V1.0
Mac mini 全自动自媒体运营系统：完整技术方案 V1.1（2026-10-14 修订）
推荐架构：本地部署 + AI 云端推理 + 自动化工作流
适用设备：Apple Silicon Mac mini（M1 / M2 / M4）
目标平台：小红书、知乎，后续可扩展抖音、公众号、头条、B站。
目标：一次初始化账号与运营规则，之后尽可能做到 7×24 小时自动选题、创作、配图、排期、发布、分析和优化。只有账号验证、异常审核等情况才需要人工介入。
一、最终技术选型
采用 n8n 的确定性工作流编排与内置 AI Agent 节点：工作流负责排期、状态流转和重试，AI Agent 负责选题、创作和策略建议，平台适配器负责受控发布。AI Agent 不是独立常驻服务，不需要单独安装 Gateway 或原生 App。
| 功能 | 技术选型 | 作用 |
|---|---|---|
| AI 智能代理 | n8n AI Agent | 选题策略、内容优化、任务协调 |
| 自动化引擎 | n8n | 定时任务、流程调度、重试 |
| 核心业务服务 | Python + FastAPI | 内容管理、发布控制、平台适配 |
| 数据库 | PostgreSQL 17 | 内容、账号、任务、分析数据 |
| 任务队列 | Redis | 队列、锁、重试控制 |
| 小红书 | xiaohongshu-mcp | 已有开源发布实现 |
| 知乎 | 官方授权 API 优先 / Playwright 备选 | 草稿、编辑、授权发布 |
| AI 文字模型 | OpenAI / 通义千问等 | 中文文章、选题、摘要 |
| AI 图片 | 图像生成 API | 封面、配图、信息图 |
| 运营后台 | Nuxt 3 | 管理多个账号、运营数据 |
| 容器部署 | Docker Compose | 常驻运行、服务重启 |
这些组件分成两层：
成熟基础设施： Docker、PostgreSQL、Redis、n8n、Playwright。它们适合作为长期运行的底座。
需要持续适配的组件： 小红书 MCP、知乎发布脚本、n8n AI Agent 工具与提示词。它们能够实现自动化操作，但无法保证在平台改版后一直正常。
小红书 MCP 截至目前已发布 v2.5.5，支持 Apple Silicon 预编译版本、图文发布、登录检测和 MCP 接口。
二、完整系统架构
运营管理后台 · Nuxt 3
账号管理 / 内容日历 / 发布日志 / 数据报表 / 系统配置
n8n
定时任务、状态流转、失败重试
n8n AI Agent
运营决策、选题、智能优化
FastAPI 运营核心服务
账号隔离 · 内容检查 · 任务分配 · 幂等控制 · API
选题引擎
热点/SEO/去重
创作引擎
文章/封面/图片
发布引擎
排期/上传/确认
互动引擎
合规回复
分析引擎
数据/KPI/反馈
监控引擎
告警/健康检查
小红书适配器
MCP
知乎适配器
官方接口 / Playwright
PostgreSQL
Redis
文件存储
整个系统的关键原则是：AI 可以决定写什么、怎么写、何时建议发布，但最终执行必须经过明确的规则检查和发布状态机。
例如一篇文章被提交发布后，如果出现网络超时，系统应该先检查是否已经成功发布，而不能直接重发，否则很容易出现重复内容。
三、每天自动运行的运营流程
以下时间和发布量是初始建议，可在管理后台调整。
07:00
自动发现选题
检索关键词与公开趋势，产生候选主题，去重并评分
08:00
自动生成内容
分别创作知乎深度回答、小红书笔记和配图
09:00
自动质量检查
检查事实来源、原创性、敏感表述与推广披露
10:00–20:00
执行发布计划
对已授权、合规、可用的账号按排期发布
21:00
自动采集运营数据
在接口许可范围内获取曝光、阅读、互动数据
22:00
自动复盘
分析高表现主题，调整后续选题及文章结构
初始内容产量我建议：
- 小红书：每天 1 篇原创图文。
- 知乎：每天 1 篇高质量回答或专栏文章。
- 每周：一次内容策略复盘。
- 每月：一次账号健康检查和内容质量审计。
这是试运行规模，并非平台规定的安全发布频率。系统不应靠固定间隔模拟真人或规避风控；应当遵守平台规则与实际授权范围。
四、Mac mini 安装部署步骤
下面按从零安装设计。建议先完成基础环境，再逐步接入 AI 和发布组件。
第一步：环境检测与基础软件（P01）
先实测硬件、系统版本、内存压力、磁盘、电源、FileVault、开发工具与官方服务连通性，证据见 docs/ENVIRONMENT.md。当前目录为 /Users/dexter/autobot，不另建重复项目。
当前主机采用 Colima + Docker CLI + Compose，安装方式已核对官方文档与 Homebrew 包信息。Colima 为 Docker 容器提供 Linux 虚拟机，使用独立 mediaops profile 与原生 ARM64。Docker Desktop 为备选，不是本轮已安装组件。
brew install colima docker docker-compose
Compose 插件发现路径需按实际 Homebrew 前缀配置，保留现有 Docker 设置。运行时版本及镜像架构必须实测。
第二步：创建核心工程（P01）
项目结构见 docs/IMPLEMENTATION.md。仓库保存配置模板、代码、工作流、文档与测试；运行数据、Cookie、密钥、日志及备份忽略 Git。
密钥由初始化命令随机生成，保存于 ~/.config/ai-media-ops/secrets，目录 0700、文件 0600。.env 仅存路径、端口与时区等非敏感配置。不输出密钥值、不写入代码、不放到命令参数。
第三步：只启动基础服务（P01）
实际配置以仓库 compose.yaml 与 config/images.env 为准，不在本文维护第二份易过时的 Compose 配置。镜像固定摘要；仅 FastAPI 映射 127.0.0.1:8000，数据库与 Redis 不映射宿主端口。
./scripts/ops init
./scripts/ops doctor
./scripts/ops start
./scripts/ops health
./scripts/ops test
./scripts/ops integration
P01 只运行 PostgreSQL、Redis 与 FastAPI，不直接部署全部组件。业务数据库使用独立最小权限角色，n8n 在 P05 使用独立数据库与账号。Redis 启用认证与 AOF，FastAPI 读取受控凭据文件。
n8n 安装与 AI Agent 工作流接入放在 P05，并重新检查当时官方 stable 版本及依赖。2026-10-14 文档记录 stable 为 2.43.4，旧 N8N_RUNNERS_ENABLED 自 2.0 起已弃用，不能照搬原配置。部署前验证 ARM64 镜像、凭据加密、工具权限与任务恢复。
官方部署文档：https://docs.n8n.io/deploy/host-n8n/install-options/install-using-docker-compose.md
启动成功不等于全自动运营完成；各 Pack 真实状态与验收证据见 docs/packs 与 docs/evidence。
第四步：配置 n8n AI Agent（P02 / P05）
不再安装独立 AI 代理服务。采用 n8n 内置 AI Agent 节点，并按官方文档连接 Chat Model 与至少一个工具。初期使用 Tools Agent，模型提供商及模型名在接入时核对最新兼容性。
实施步骤：
- P02 在 FastAPI 实现选题、创作、事实来源检查、配图与预算控制接口，先独立测试。
- P05 将 Chat Model 子节点连接 AI Agent，将受限 HTTP 工具连接到 FastAPI。
- 模型 API 密钥保存于 n8n Credentials，以固定加密密钥保护，不写进工作流 JSON、代码或日志。
- AI 输出经过明确的结构化校验，再进入确定性工作流；不直接作为发布命令执行。
- 数据库是任务与内容的唯一状态来源，Agent 对话记忆不承担业务状态持久化。
- 仅允许选题、创作、审核与策略建议工具；不开放 Shell、Cookie、数据库超级用户或无限制发布权限。
- 发布由 FastAPI 执行授权、账号白名单、频率预算、内容检查、幂等与结果核验。
- API 超时、模型异常和预算超限由工作流处理，失败状态可追踪并需要时暂停。
官方文档： - AI Agent：https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent/ - Tools Agent：https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent/tools-agent/
此阶段仅为实施设计；模型凭据、工具调用、图片生成和发布闭环均需后续 Pack 实测后验收。
第五步：安装小红书 MCP
针对 Apple Silicon，优先使用原生 ARM64 版本，而不是先尝试 Docker x86 模拟。
进入发布组件目录：
mkdir -p ~/ai-media-ops/services/publishers/xiaohongshu
cd ~/ai-media-ops/services/publishers/xiaohongshu
# 下载官方 GitHub Release 页面
open https://github.com/xpzouying/xiaohongshu-mcp/releases
在最新 Release 中下载：
xiaohongshu-mcp-darwin-arm64
xiaohongshu-login-darwin-arm64
将这两个文件放到上述目录，然后执行：
cd ~/ai-media-ops/services/publishers/xiaohongshu
chmod +x xiaohongshu-login-darwin-arm64
chmod +x xiaohongshu-mcp-darwin-arm64
# 首次登录（需要扫码）
./xiaohongshu-login-darwin-arm64
扫码成功后启动：
# 为服务设置访问密钥
export AUTH_TOKEN="$(openssl rand -hex 32)"
./xiaohongshu-mcp-darwin-arm64
这将启动 MCP 服务，默认地址：
<http://localhost:18060/mcp>
需要注意，以上 AUTH_TOKEN 是演示性的进程环境变量。正式通过 macOS LaunchAgent 长期运行时，应通过权限受限的配置或密钥管理方式提供相同令牌，不能每次启动随机更换，否则客户端无法连接。
该项目官方支持 MCP Inspector 测试工具列表和发布操作。首次运行还可能下载无头浏览器。
我建议首次测试顺序是：
- 登录状态检查。
- 获取账号相关信息。
- 测试搜索及读取功能。
- 准备一篇自有测试笔记。
- 在确认当前账号允许的自动化方式后测试发布。
- 检查是否返回笔记 ID、实际页面是否存在。
- 验证系统能否正确记录发布状态。
前五个步骤中涉及实际发文的部分，应该明确使用测试内容，避免直接用运营账号大量发布。
第六步：安装知乎适配器
知乎优先核对官方开放平台（https://developer.zhihu.com/）与知乎官方媒体上传项目（https://github.com/zhihu/zhihu-mediacloud-uploader）。媒体上传或数据查询权限不等于发文权限；P04 必须验证申请条件、发文接口、OAuth / 应用授权范围及真实结果。官方发文接口不可用时，才评估经授权的 Playwright 草稿适配器。不得直接依赖未经验证的第三方脚本进入全自动正式发布模式。
推荐参考这两个项目：
- hoverzheng/auto-publish：基于 Playwright 的博客发布工具。
- yangming0506/zhihu-auto-publish：知乎自动发布相关项目。
这些是社区实现，不能等同于知乎授权的官方发文接口。
yangming0506/zhihu-auto-publish · GitHub
+1
安装基础环境：
brew install python@3.12
cd ~/ai-media-ops/services/publishers/zhihu
python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install playwright
python -m playwright install chromium
后续由 Codex 开发一个独立的 ZhihuPublisher，接口规范固定为：
class ZhihuPublisher: async def check_login(self): pass async def create_draft(self, content): pass async def publish(self, draft_id): pass async def verify_publication(self, task_id): pass async def fetch_metrics(self, post_id): pass
此处是接口骨架，不是已经能发布的可运行程序。
实际适配器还需要内容格式转换、浏览器状态管理、错误分类和授权检查。
知乎发布采用渐进策略：
- 首先实现自动保存草稿。
- 其次实现发布前页面预检。
- 在规则允许、账号稳定且测试通过时，才启用自动提交。
- 遇到验证、账号异常、发布限制，立即暂停并记录，不尝试绕过平台验证。
五、无人值守运行的关键配置
安装完成不代表能够长期运行。Mac mini 的省电、Docker 启动、网络和账号会话问题，都必须处理。
1. 禁止系统自动睡眠
先检查：
pmset -g custom
如果 Mac mini 专门用来运行这个系统，可以在电源模式下配置：
sudo pmset -c sleep 0
sudo pmset -c disksleep 0
sudo pmset -c womp 1
sudo pmset -c autorestart 1
这几项分别涉及禁止系统睡眠、禁止磁盘休眠、网络唤醒和支持情况下的断电恢复。实际效果依赖 macOS 版本、硬件及供电条件。
同时：
- 容器虚拟机与项目服务由 launchd 管理登录后启动；冷启动受 FileVault 解锁约束。
- n8n、PostgreSQL、Redis 设置自动重启。
- n8n AI Agent 随 n8n 容器运行；小红书 MCP 原生进程使用 macOS
launchd管理。 - 定期备份数据到外部磁盘或 NAS。
- 最好给 Mac mini 配备 UPS。
特别注意：Colima 与 Docker Desktop 在 macOS 上均需要其 Linux 虚拟机运行。restart: unless-stopped 不能单独保证 Mac 重启后、尚未登录桌面时所有容器都已运行。当前 FileVault 开启，冷启动需人工解锁；P08 必须实际测试解锁登录后的恢复流程。
2. 任务失败自动恢复
创建发布任务
写入数据库，生成唯一任务 ID
检查内容、授权、账号与登录状态
调用平台发布适配器
成功
验证 URL、保存记录
失败或未知
核验结果、分类处理
需要至少区分以下异常：
| 异常 | 自动处理 |
|---|---|
| 临时网络故障 | 延迟重试 |
| AI API 超时 | 退避重试或切换备用模型 |
| 登录失效 | 暂停账号任务，通知人工 |
| 验证码 / 风控 | 停止发布，不自动绕过 |
| 不确定是否发布成功 | 先核验，禁止盲目重发 |
| 内容重复 | 阻止发布，返回重新创作 |
| 平台页面结构变化 | 停用适配器并告警 |
| 服务意外退出 | 服务管理器尝试重启 |
3. 自动分析
实际可采集的指标要以各平台提供的合法数据接口、账号后台可导出的数据及使用授权为准。
初期建议追踪：
| 指标 | 用途 |
|---|---|
| 内容生产成功率 | 判断 AI 工作流是否稳定 |
| 实际发布成功率 | 判断适配器是否可靠 |
| 阅读 / 浏览量 | 评估内容触达 |
| 收藏、点赞、评论 | 评估用户兴趣 |
| 账号粉丝变化 | 评估长期增长 |
| 内容相关转化 | 评估业务价值 |
| AI 单篇生产成本 | 控制运营开销 |
系统需要区分“未获取到指标”和“指标为零”，不能把没有数据解释为没有曝光。
六、运营后台应该做哪些功能？
建议开发一个专门的 AI Media Operations Center，可以交给 Lovable 做 UI 设计，Codex 完成真实数据和业务接入。
运营中心 · 界面结构示意
内容运营总览
演示数据
今日生成
12
篇内容
成功发布
8
篇内容
待发布
4
篇内容
发布成功率
96%
近7日示例
内容表现趋势
小红书知乎
0150300450600周一周二周三周四周五周六周日
以上为布局示意，非真实账号数据。
近期任务
| 小红书 · 寄快递省钱攻略 | 已发布 |
|---|---|
| 知乎 · 快递价格差异分析 | 待发布 |
| 小红书 · 国际寄件指南 | 待检查 |
正式后台建议包含八个页面：总览仪表盘、账号管理、内容日历、AI 选题库、内容库、发布任务、数据分析、系统设置。
七、建议分成 8 个 Pack 让 Codex 顺序开发
这个系统虽然可以使用现成组件，但将它们连接成正式可持续运行的软件，还是需要一些开发工作。
我建议不要一次把所有功能交给 Codex。按照你习惯的单 Pack 顺序开发更容易测试和定位问题。
P01
基础环境与核心工程
Colima + Docker Compose、PostgreSQL、Redis、FastAPI、环境配置、健康检查。
P02
AI 创作与选题系统
n8n AI Agent 工具接口设计、模型接入、自动选题、事实检查、差异化内容生成、图片生成。
P03
小红书发布适配器
MCP 接入、登录检测、内容上传、发布验证、故障处理。
P04
知乎发布适配器
Playwright、草稿管理、格式转换、发布预检、授权发布。
P05
n8n 自动运营工作流
n8n AI Agent + Chat Model + 受限工具、定时选题、内容流水线、排期、重试、异常暂停。
P06
运营管理后台
Nuxt 3 管理后台（版本维护策略待 P06 确认），账号、内容、任务与系统配置。
P07
数据统计与智能优化
平台数据接入、历史统计、效果分析、内容策略反馈。
P08
无人值守与生产验收
launchd、自启动、备份恢复、安全加固、长时间稳定性测试。
实施阶段与验收标准
| 阶段 | 对应 Pack | 验收要求 |
|---|---|---|
| 第一阶段：基础可用 | P01–P02 | 能自动生成原创草稿和配图 |
| 第二阶段：发布闭环 | P03–P05 | 两个平台分别通过端到端发布测试；不支持的操作明确停用 |
| 第三阶段：运营可视化 | P06–P07 | 管理后台能查看任务、文章和真实统计 |
| 第四阶段：无人值守 | P08 | 连续 7 天测试，服务可恢复，任务可追踪，无重复误发 |
只有通过发布测试，才能把对应账号标记为 AUTO_PUBLISH_ENABLED。不满足条件的账号继续使用 DRAFT_ONLY，系统不能为了实现无人值守而强行发布。
八、AI 模型及运行成本
Apple Silicon Mac mini 完全可以承担这些服务的调度、数据库和轻量浏览器任务。文本和图片生成建议走云端 API，尤其是低配、内存较小的 Mac mini。
每月预算预估（人民币）
假设两个平台各每天生成并尝试发布 1 篇，主要使用文本 API、每篇制作少量配图。仅为预算区间，非实时报价。
| 文本生成及审核 | ¥30–150 |
|---|---|
| AI 配图 | ¥30–200 |
| n8n / 数据库 / Redis | 软件自托管费用可为 ¥0 |
| 电费、备份、网络 | 按实际情况 |
| 商业授权/附加服务 | 视使用方式而定 |
以上不包含开发维护成本，且部分平台自动发布能力并非付费就可以获得。
九、针对蹦熊代寄，如何设计自动运营策略？
如果这套系统先服务于蹦熊代寄，我建议设置为一个品牌运营任务，采用两种内容形式。
小红书偏生活化： 生活场景、实用寄件攻略、搬家整理、毕业寄行李、国际寄件经验、快递费用比较。内容主要解决问题，涉及蹦熊时正常披露品牌关系，避免虚构第三方亲测或编造节省金额。
知乎偏专业内容： 快递价格形成机制、寄件平台比较、国际快递计费、体积重量、保价规则、物流时效和常见问题。尽量使用可核实的官方来源及实际运费数据。
还可以把你的网站内容库接入系统：
蹦熊官网知识库 → AI 选题 → 平台专属原创改写 → 质量检查 → 发布 → 数据回流
这样既能复用已有知识资产，也更容易控制事实准确性。不同平台应该采用不同的文章结构，而不是将同一篇内容同时复制过去。
十、最终建议
我建议采用以下明确方案：
正式技术方案 V1.0
Mac mini + Colima / Docker Compose + PostgreSQL + Redis + FastAPI + n8n（内置 AI Agent） + 小红书 MCP + 知乎官方授权 API 优先 / Playwright 备选 + Nuxt 3
第一优先级： 先完成自动选题、自动创作、自动配图、小红书发布闭环。
第二优先级： 完成知乎适配、定时调度和真实发布验证。
第三优先级： 加入完整运营后台、内容效果分析和自动优化。
最终目标： 尽可能无人值守。系统故障自动恢复；平台验证与限制不绕过；重要异常自动通知。
这比直接安装一个所谓“全自动自媒体机器人”更有长期维护价值。特别是发布、分析和账号管理分开实现后，未来增加平台不需要重做整个系统。
当前实测主机：Apple M4 Pro / ARM64、14 核、48 GiB 内存、macOS 27.0.1。AI Agent 在 n8n 中运行，不再涉及独立代理的 Node.js、CLI、Gateway 或原生 Mac App 条件。Nuxt 3 已结束官方维护，P06 开始前需重新评估版本与维护策略。
本次修订记录（2026-10-14）
- 依用户要求，将独立 AI 代理替换为 n8n 内置 AI Agent，删除独立安装及服务管理步骤。
- Agent 仅调用受限工具，发布与状态机继续由 FastAPI 控制。
- 本次范围为环境检查、基础文件与 P01；P02–P08 尚未实施。
- 本文示例不代表验收结果，当前真实状态以 docs/packs/P01.md 与 docs/evidence 为准。