很多人想象中的个人 Agent，是一个放在微信或飞书里的聊天机器人。

问它“下午有什么安排”，它能答；让它“提醒我开会”，它会回一句“好的”。这当然比没有方便，但离一个真正有用的助理还差很远。

真正的助理不只是被动回答。它应该能在你不打开电脑时持续在线，知道今天哪些事重要，按约定提醒你，整理你交给它的资料；遇到开发任务时，它把工作交给 Codex 或 Claude Code 这类专业执行者，最后把结果和风险带回来。

我现在更愿意把它理解成一个个人工作流的控制层，而不是一个更会聊天的模型。

这篇文章以我服务器上实际运行的 Hermes 为例，但方法不依赖 Hermes。任何具备消息网关、持久服务、定时任务、技能或工具扩展能力的 Agent，都可以按同样的结构搭建。不同产品的安装命令和配置字段会变，职责划分不会变。

一、先定义你要搭的不是“全能 Agent”

一开始最危险的想法，是让一个 Agent 同时拥有全部权限：看全部聊天、写全部文档、改日程、执行终端命令、直接部署生产环境。

它听起来很自动化，实际上是把所有偶发误解、提示注入和模型失误，都放到了同一条高权限链路上。

更可靠的结构是四层：

手机消息入口（飞书 / 微信 / 其他）
                |
                v
常驻 Agent Gateway
  会话、记忆、定时调度、通知投递
                |
      +---------+---------+
      |                   |
      v                   v
办公工具层             专业执行者层
日历、文档、任务       Codex、Claude Code、运维脚本

Gateway 是助理和调度员，不必亲自成为最强的编码 Agent；Codex 和 Claude Code 是技术执行者，不必全天候监听你的聊天窗口。

这个拆分带来三个好处：

• 你能随时更换底层模型或 Agent，不会把个人工作流绑死在一个产品上。
• 办公操作和开发操作各自拥有最小权限，事故半径更小。
• 你能为每类任务设置不同的确认方式，而不是靠一句“请小心”。

二、我的真实样本：为什么需要常驻服务

我在服务器上把 Hermes 作为 Gateway 运行。它不是开着一个 SSH 终端等我用，而是一个用户级 systemd 服务：网络就绪后启动，异常退出自动拉起，用户退出登录后仍保持运行。

这个实例目前已经接入飞书能力、微信通道和定时任务。飞书侧通过 lark-cli 处理日历、文档、云盘和任务；Hermes 处理消息、会话、任务调度和结果投递。Hermes 官方也把 Gateway 定义为多消息平台与定时任务的统一后台进程。Messaging Gateway

它带来一个很实际的变化：我不需要先打开某个 IDE，才能让助理开始工作。手机上发一句“明早给我列出日程和最紧急的三件事”，或者“把这份会议记录整理成待办”，入口一直都在。

但“常驻”不是“永远可靠”。在实际日志里，我遇到过微信投递限流；也见过定时任务因为试图执行任意本地代码而被安全策略拦截。这两个现象恰好说明：一个能 24 小时运行的 Agent，最重要的不是能做多少事，而是失败时是否可见、越权时是否能停下来。

三、先选消息入口：飞书优先，微信谨慎

如果你的目标是日程、文档和待办，我建议先接飞书。

它不仅是聊天入口，也是工作数据所在的位置。把飞书应用的消息权限、日历、文档、任务和云盘权限设计好之后，Agent 才能完成“看日程 -> 生成准备清单 -> 建立待办 -> 把结果发回来”这样的闭环。

以 Hermes 为例，飞书可通过 App ID、App Secret、允许用户列表和默认投递会话接入；官方配置同时提供 WebSocket 与 Webhook 两种连接方式，前者更适合大多数个人服务器场景。环境变量参考

我会这样划分渠道：

微信是很自然的入口，但个人微信通常需要第三方桥接，并不等于官方企业 API。不要把它写成“永不掉线”的承诺。它更适合接收提醒和发起请求；涉及改日程、读敏感文档或执行代码时，最好把确认放回飞书或一个受控的 Web 页面。

无论接哪个平台，都先做三件事：

1. 配置允许用户白名单，不让陌生人可以调用你的私人权限。
2. 为定时任务指定固定的私人投递会话，避免把提醒发到群聊。
3. 把 Token、App Secret 和 OAuth 凭证放在权限收紧的环境文件中，不要放进 Agent 记忆、聊天消息或 Git 仓库。

Hermes 的飞书配置可以收敛成下面这类最小环境文件。真实的 App Secret 只保存在服务器上，并把文件权限收紧到运行账号可读：

# ~/.hermes/.env
FEISHU_APP_ID=cli_xxx
FEISHU_APP_SECRET=replace-with-server-side-secret
FEISHU_CONNECTION_MODE=websocket
FEISHU_ALLOWED_USERS=ou_your_user_id
FEISHU_HOME_CHANNEL=oc_your_private_chat_id

然后运行 hermes gateway setup 完成平台向导，再用允许账号发送一条消息测试。FEISHU_ALLOWED_USERS 和 FEISHU_HOME_CHANNEL 分别限制谁能触发助手、定时结果默认投递到哪里；不要为了省事设置允许所有人访问。

四、让它持续工作的最小部署

产品会迭代，安装命令也会变，所以不要迷信任何一条“一键安装”命令。以 Hermes 为例，应始终以当前官方安装页为准；安装完成后先确认版本，再完成模型、消息网关和服务托管的配置。

Hermes 最小路径

下面是我在 Linux 服务器上使用的最小路径。它是 Hermes 示例，不是其他 Agent 的通用命令；执行前应查看当前版本的官方安装说明，并始终使用独立账号而不是 root：

# 仅管理员执行一次：创建低权限运行账号并让其退出登录后继续运行
sudo adduser --disabled-password --gecos "" hermes
sudo loginctl enable-linger hermes

# 切换到运行账号后执行
sudo -iu hermes
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
export PATH="$HOME/.local/bin:$PATH"

hermes --version
hermes setup              # 选择模型供应商并写入服务器本地配置
hermes gateway setup      # 选择飞书、微信等消息平台
hermes gateway install    # 安装用户级 systemd 服务
hermes gateway status

如果你不愿意直接执行远程安装脚本，先下载、审阅并固定对应版本再安装。这里真正的重点不是这条 curl 命令，而是后面的运行模型：专用账号、专用 HERMES_HOME、受限凭证和受管服务。

下面这份用户级 systemd 单元展示的是关键结构，不包含任何密钥：

# ~/.config/systemd/user/agent-gateway.service
[Unit]
Description=Personal Agent Gateway
After=network-online.target
Wants=network-online.target

[Service]
WorkingDirectory=%h/.agent
Environment=AGENT_HOME=%h/.agent
ExecStart=%h/.local/bin/agent gateway run
Restart=always
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=default.target

它表达的不是 Hermes 专有写法，而是一个 24 小时助理的最低运行条件：

• 服务由进程管理器托管，而不是依赖一个仍开着的终端。
• 异常退出后自动重启，日志进入 journalctl，方便追踪。
• 启用用户 linger，避免 SSH 断开或用户退出后服务一起被回收。
• 运行身份是专门的低权限用户，不是 root。

Hermes 可用 hermes gateway install 安装用户服务，并用 hermes gateway status 检查状态；其定时调度由常驻 Gateway 执行，而不是另起一套不可见的 cron。定时任务文档

部署完成后，先做三项验收：

1. 重启服务，确认它会自动恢复。
2. 从允许账号发一条消息，确认能收到回复。
3. 创建一个只读、一次性的提醒任务，确认能投递并留下日志。

不要先给它几十个技能、所有工作盘权限和一个全天候的终端。先证明最小链路可靠，再扩展能力。

五、从三个低风险定时任务开始

定时任务是“聊天机器人”和“助理”的分界线，但也最容易变成垃圾消息制造机。

我建议第一周只启用三个任务，而且全部是读取、汇总、提醒，不自动写入任何系统：

Hermes 的任务可以用自然语言、间隔表达式或标准 Cron 表达式创建，也支持暂停、手动运行和删除。每次调度都在新的 Agent 会话中执行，因此任务说明必须自包含，不能写“检查那个问题”这种只对当前聊天有意义的话。Hermes Cron 指南

一个合格的定时任务提示词应该像这样：

任务：工作日晨间简报。
数据：只读取我的日历和未完成任务。
输出：按“今天日程 / 最紧急三项 / 需要我确认”三段输出，总计不超过 10 行。
限制：不得创建、修改或删除日程和任务；没有重要变化时输出 [SILENT]。
投递：仅发送到我的私人飞书会话。

对应的 Hermes CLI 示例是：

hermes cron create "0 8 * * 1-5" \
  "只读取我的日历和未完成任务。按今天日程、最紧急三项、需要我确认三段输出，总计不超过 10 行；没有重要变化时输出 [SILENT]。不得创建、修改或删除任何记录。" \
  --name "weekday-morning-brief"

hermes cron list
hermes cron run weekday-morning-brief

先手动运行一次，确认内容、投递位置和静默策略都正确，再让它按计划执行。不要第一次就创建一个“每 5 分钟检查全部系统”的模糊任务。

这里最重要的是“只读取”和“没有变化就静默”。好的提醒是在关键节点推你一下，不是每小时向你证明它还活着。

对纯确定性的巡检，例如磁盘空间、网站 HTTP 状态、备份是否成功，不必每次都唤醒大模型。Hermes 支持无 Agent 的脚本任务，脚本只在异常时输出告警；其他 Agent 也应该尽量采用同样的设计：确定性检查交给脚本，解释和归纳才交给模型。

六、日程、文档和任务：默认“起草”，不是“替你决定”

助理最容易带来价值的场景，通常不是自动替你做决定，而是把混乱的信息变成一个可确认的草稿。

例如：

• 你把会议纪要发给它，它提取待办、负责人和截止时间，生成一个飞书任务草稿。
• 你说“下周安排一次和 A 的沟通”，它先查空闲时间，给出候选时间段和会议议题。
• 你让它整理一堆资料，它在新文档中生成目录、摘要和待确认问题，不覆盖原文。
• 它在会前半小时发送“相关文档、未决问题、上次行动项”的简短准备卡片。

这类操作应当遵守一个固定协议：

读取 -> 提案 -> 预览 -> 明确确认 -> 写入 -> 回执

“明确确认”不是让 Agent 猜“你应该不会介意”。它应该能对应一个可审计的动作，比如“创建这 3 个任务”“把会议改到周三 15:00”“发送这封邮件”。

飞书本身很适合承载这一层，因为日历、文档、任务和消息都在同一协作空间。Hermes 示例中用 lark-cli 扩展飞书操作，但换成其他平台时，核心仍然是同一件事：为每个写操作提供预览、确认和可追溯的结果。

七、让它协作 Codex 和 Claude Code，而不是把终端直接交出去

“让手机里的 Agent 控制 Codex 和 Claude Code”听起来很酷，但这个需求最需要克制。

正确的关系不是：

微信消息 -> Agent -> root shell -> 随便执行

而应该是：

消息任务 -> 助理澄清范围 -> 隔离工作区 -> 编码 Agent -> 测试与报告 -> 人工决定提交、合并、部署

我会让常驻 Agent 做这些开发协调工作：

• 把自然语言需求整理成范围、验收标准和风险。
• 检查仓库状态、已有任务、CI 结果和错误日志。
• 在独立分支或 git worktree 创建工作区，再启动 Codex 或 Claude Code。
• 收集 diff、测试结果和待确认事项，发回手机。
• 生成 PR 描述或发布清单草稿。

而不是默认允许它做这些：

• 在主分支直接改代码或推送。
• 读取所有 SSH 私钥、环境变量或密码库。
• 连接生产环境并自行部署。
• 把外部聊天内容原样拼进 shell 命令。

一个足够实用的权限表如下：

实际服务器上的安全拦截给了我一个很好的提醒：无人值守的定时任务尝试执行任意本地代码时，被运行时策略拒绝了。它短期看像“能力不够”，长期看却是正确的默认值。自动化应该沿着预先设计的窄路径跑，而不是在无人看管时获得更大的自由。

八、记忆不是聊天记录：给助理一份可维护的工作说明

如果你希望它越用越懂你，不能只依赖聊天历史。

聊天记录会膨胀、会过期，也很难区分“你当时随口说的想法”和“以后都要遵守的工作习惯”。更好的做法是给这个个人助理维护几份短小、可审计的外部文件：

assistant/
  USER.md          # 固定偏好、时区、提醒窗口、沟通方式
  WORKFLOWS.md     # 晨间简报、会议准备、周复盘的标准输出
  PERMISSIONS.md   # 每类操作的读取、起草、确认、禁止边界
  MEMORY.md        # 已验证的长期事实，并标记最后验证时间

这里的原则和维护项目级 Agent 记忆完全一样：事实可以根据证据更新，工作流可以在复盘后优化，但权限规则的改变必须更难。

例如，“我通常希望晚上十点后只接收紧急提醒”可以直接写入 USER.md；“以后允许 Agent 自动给所有客户发消息”则绝不应该因为一次对话就变成默认规则。

九、把失败也设计进系统

常驻 Agent 最令人不安的地方，不是它报错，而是它悄悄失效。

我的检查清单至少包括：

• Gateway 服务是否在运行，最近是否反复重启。
• 消息通道是否仍能收发，是否出现限流或鉴权失败。
• 定时任务是否按时运行、是否连续失败、结果投递到哪里。
• 哪些任务使用了模型，哪些应该改为无模型脚本，避免无意义的 token 消耗。
• 最近有哪些写操作、代码任务或权限拒绝，能否回溯原因。

不要只监控进程“活着”。消息通道可能已经断开，但进程仍然健康；定时任务可能在运行，但投递全部失败。真正需要验证的是从“任务触发”到“你收到结果”的完整链路。

每增加一种自动化，都先手动触发一次，再观察它下一次按时运行的记录。确认失败路径能通知到你，才算真的上线。

十、从一个可控闭环开始

如果今天就要搭，我建议按下面顺序推进：

1. 部署一个低权限的 Gateway，只接入自己的飞书私聊。
2. 完成服务自启动、自动重启和日志检查。
3. 上线一个只读的晨间简报，连续观察一周。
4. 增加“会议纪要 -> 待办草稿”这一条需要确认的写入工作流。
5. 为 Codex 或 Claude Code 建立隔离工作区和交付模板，再允许助理单次调度。
6. 最后才考虑微信、外部消息、自动运行脚本和跨服务编排。

这个顺序看起来不够炫，但每一步都能单独验证，也能单独回滚。

一个真正有用的 24 小时助理，不是深夜偷偷替你做完所有事情的黑盒。它应该像一个可靠的秘书：知道哪些信息需要提前准备，知道何时提醒，知道什么时候必须等你点头；需要调用专业执行者时，能把任务交代清楚，再把结果带回来。

Hermes 是我已经跑通的一种实现。它以后可以替换成别的 Agent，飞书也可以换成别的办公平台，Codex 和 Claude Code 也可以换成更适合你的执行者。

但只要“入口、调度、执行、权限、监控”这五层还在，你搭建的就不是一个容易失控的万能机器人，而是一套会随着你的工作习惯逐渐变顺手的个人助理系统。

参考资料

• Hermes Agent Messaging Gateway
• Hermes Agent Scheduled Tasks
• Hermes Agent Environment Variables