我最近在搭一套围绕生活与工作的个人 Agent 基础设施（personal agent infrastructure）。它不是“安装几个 AI 工具”，也不是给同一个聊天机器人换几套人格提示词；我更关心的是：当 Agent 开始长期运行、接触不同数据并执行不同权限的动作后，怎样让系统仍然以人为中心、边界清楚、可审计且可替换。
截至 2026 年 8 月 5 日，这套系统已经有三个实际运行的 profile：default、hermes-ops 和 blog。后面的 infra、coding、life、research 仍只是规划，不会为了“看起来完整”而提前创建。本文记录的是当前的设计判断与已经落地的部分，而不是某个产品的广告。
我想解决的不是人格问题，而是上下文污染
最容易开始的方式，是让一个 Agent 同时处理所有事：服务器的 root 操作、代码细节、博客草稿、日程、研究资料、提醒和告警。短期很方便，长期却几乎必然失控：记忆混在一起，工具权限不断累加，定时任务难以追踪，敏感信息也容易越过原本不该越过的边界。
所以我把 profile 理解为一个领域自治单元，而不是“人格皮肤”。一个 profile 有自己的 config.yaml、.env、SOUL.md、memory、sessions、skills、cron、state DB、gateway 状态和 bot 凭据。它应该对一组数据、权限和长期知识负责，也只处理自己有权处理的那部分。
边界的划分标准不是“任务名字”，而是下面三个问题：
- 谁拥有这份数据？
- 谁承担这个动作的风险？
- 谁需要维护相关的长期知识？
一件工作当然可以跨领域，但跨 profile 的协作应该通过 Mattermost 线程、task ID 和明确产物交接完成，而不是互相读取 memory、session DB 或 secrets。
Mattermost：我的统一人机控制台
我选择 Mattermost，并不是因为它有最多的协作功能，恰恰相反，是因为它足够纯净。
飞书、钉钉、企微都很成熟，但它们面向企业协作，天然带着大量会分散注意力的东西。需要文档时，我可以接入飞书文档；需要日程时，可以接入 Google Calendar。对我而言，整个编排层只有 Mattermost 的摩擦力最低：我可以自己建立、自己管理凭据、通过 API 快速验证一个想法，并且把它作为自己基础设施的一部分，而不是一个不可控的 SaaS 黑箱。
在这里，频道是天然的领域空间：#infra、#coding、#blog；线程是天然的任务空间。每个 bot 都有清晰的领域身份，日志、diff、测试状态、告警和表格这类机器输出也适合沉淀在同一个界面里。
目前 Mattermost 通过 Docker Compose 在本机运行：mattermost-app 与 postgres:15-alpine 两个容器保持 healthy，Web/API 服务在 localhost:8065，数据持久化在 ~/mattermost/volumes/。这不是为了追求“全都自己造”，而是为了让控制面在我自己手里。
Hermes：运行时、身份与持久状态层
Hermes 在这套架构中承担的不是“最聪明的模型”，而是运行时、身份和持久状态管理层。
Codex、Claude Code、Kimi Code 都是优秀的专职 coding agent；但它们的典型 session 更接近单任务、单代码库的工作方式，并不天然解决跨消息平台的长期对话、多领域独立记忆、生活/研究/编码之间的路由问题。对这些问题，Hermes 的 profile 是一等概念；skills、memory、session search、cron、MCP、ACP 和 delegation 也在同一运行时内。
因此我采用的关系是：
高能力、可替换的专业执行 worker
对于编码任务，理想的闭环是 worker 在 git worktree 中隔离实现，另一种模型或 worker 做审查，最后由 Hermes 以测试和 diff 收口。实现与审查不必由同一个工具承担。
这也意味着我并不神化 Hermes。若未来 OpenClaw 在多 bot 路由、飞书接入或长任务队列上经实测更合适，就应该替换对应层。一个健康的个人基础设施不应要求某个产品包办一切。
五层模型：把“聊天”放回整个系统中
我目前用下面的五层来理解整个系统：
最顶层是人与系统交互、确认和追踪状态的控制面；最底层才是服务、容器和网络。模型和 coding agent 很重要，但它们位于中间的 specialist execution 层，不应该抢占顶层身份。作者的决策、确认和偏好始终在系统中心，高风险动作必须经过明确批准。
对应到 Mattermost 与 profile，目标拓扑如下：
理解跨域意图，汇总交付物
一 bot · 一 profile · 一 token
其中 default 是 chief-of-staff / orchestrator：理解跨域意图、做路由、汇总结果，但不长期持有每个领域的细粒度操作记忆，更不应默认为生产环境的万能执行者。
一 bot、一 profile、一个故障域
这里还有一条实现层面的约束：一个 Mattermost bot 对应一个独立 Hermes profile，并使用独立 token。bot 不是一个隐藏在后台的通道，它是用户可理解的领域身份。看到 @blog，我就知道它只处理博客的素材、草稿、构建和经过确认的发布流程；看到 @hermes-ops，我知道它处理的是控制面本身，而不是替我操作任意一台业务服务器。
这层映射带来的不只是界面上的清晰。profile 的配置、定时任务、状态数据库与 gateway 凭据都是独立的，所以可以把每个 profile 放到独立的 systemd gateway 服务中。这样某一个领域的模型调用失败、依赖升级或 gateway 故障，不会天然拖垮全部领域。Hermes 也可以由主 gateway multiplex 多个 profile；我当前更偏向一 profile 一服务，因为故障域和排障路径都更直接。
独立并不等于放弃协调。默认 profile 可以把一个跨域请求拆成多个有明确边界的子任务，例如由 research 给出资料、blog 形成草稿、coding 提供可运行的示例；但最终应回到同一个 Mattermost 线程里，交付物、任务 ID、审批点和结论都必须可追溯。协调者负责“把事情接起来”，不负责绕开边界。
权限矩阵比“能力清单”更重要
Agent 系统很容易只讨论“它能做什么”，而我更想先写清楚“它默认不能做什么”。当前的权限边界是：
| Profile | 应具备 | 默认不应具备 |
|---|---|---|
default | 任务路由、跨域只读、通知 | 未经确认的生产 SSH、发布、删除 |
hermes-ops | profile/gateway/bot/skills/cron/备份/升级管理 | 任意 root SSH、读取其他 profile 私密数据 |
infra | Fleet、SSH、Tailscale、服务管理 | 日历、博客内容库、项目密钥 |
coding | 项目目录、Git、Coding worker、CI | VPS root 全权限、生活数据 |
blog | 博客 repo、媒体、发布工具 | 生产服务器任意管理权限 |
life | Calendar、任务、生活记录 | SSH、deploy keys、生产 secrets |
research | Web/X/RSS、归档 | 生产修改权限、私人生活写入 |
这个表也解释了为什么我不打算一开始就把 bot 拆得很细。过早拆分会让人不知道“该找谁”；正确的做法是先识别确实需要长期跟踪的领域，再按数据所有权和权限建立边界。
hermes-ops：运维控制面的控制面
我认为这套设计里最关键的一层，是把“运维 Mattermost + Hermes 多 profile 系统本身”和“运维 VPS/业务”分开。
前者属于 @hermes-ops / hermes-ops profile：它是 Personal Agent Control Plane Operations，也是后续 bot 的 Bot Father。它负责 profile 与 bot 的生命周期、gateway/systemd 健康、消息链路的分段定位，以及凭据绑定的治理；它只检查状态，不在聊天中暴露凭据明文。
它还负责变更治理：提出变更后先描述影响范围、备份和 sandbox 验证方案；得到确认后才应用，再做健康检查并记录可回滚点。它的 Mattermost system-admin automation identity 凭据只存在自己的 .env 中，权限为 0600；即使它权限较高，也不是无限权限，只通过私密频道或 DM 暴露。
当一个新领域确实值得长期维护时，接入流程是这样的：
--clone-all。这里有几条我希望长期坚持的安全不变量：不对同一个 profile home 跑两个 gateway；不复用主 bot token；不在聊天中打印 token 或密钥；删除 profile、轮换凭据、重启关键服务、对外暴露 Mattermost 等高风险变更，必须先说明影响与回滚并获得明确批准。
已经落地，而不是纸面架构
截至本文写作时，default 使用 kimi-coding / k3-256k 作为主控入口；hermes-ops 与 blog 都使用 openai-codex / gpt-5.6-terra，并各自以独立 systemd gateway 服务运行。hermes-ops 已完成独立 bot、私有 DM home channel、pairing、真实模型调用和控制面安全约束的链路验收。
blog 也按相同模式上线：它有专属 @blog bot 与私有 #blog 频道，频道白名单只允许 #blog，需要 @ 提及才回复，并在任务线程中工作。更重要的是它的发布闸门：新文章默认 draft: true，没有当前线程里的明确批准，不得 push 或 deploy。
这些规则看起来不如“一个万能 bot”惊艳，但它们让系统在长期运行时仍能解释：谁做了什么、为什么能做、在哪个边界里做，以及失败时怎样回退。
还没有解决的问题
这套架构仍然很早期。我特别警惕三种反模式：第一，过早拆分 bot，导致入口变多、反而增加认知负担；第二，按任务名字而不是数据与权限划分边界；第三，跨 profile 隐式共享状态，最后又回到一个看似分开、实则混乱的“大脑”。
接下来我会按需完成 infra、coding、life、research 的 onboarding，而不是照着组织架构图填空。每增加一个 profile，都要先回答它的长期价值、数据归属、最小权限、审批点和 rollback 是什么。
对我来说，个人 Agent 基础设施的目标不是让自动化替我做更多决定，而是把重复劳动、信息流和专业执行组织得更清楚，让最终决定仍然属于我。