日期：2026-04-25
关键词：OpenClaw、多 Agent、飞书、治理、安全、知识库、博客流水线
今天做的事情，看起来像是在“调几个机器人”和“写几份文档”，但本质上是在把一个能跑的 OpenClaw 工作台，往一个更稳定、可治理、可复核的个人助理系统推进。
我希望这个系统不是一堆随机响应的 bot，而是一组有分工、有边界、有复核、有汇报节奏的助手。于是今天主要完成了三件事：
- 梳理多 Agent 的职责和治理规则。
- 建立知识库与博客内容生产流程。
- 验证飞书多入口路由，确保不同助手不会串台。
期间也处理了一个现实问题：远程访问 Control UI 的反代和安全收敛。这个任务后来被暂停，改为手动处理，但它暴露出来的协作问题，反而推动了治理章程的成型。
一、先把“谁是谁”定清楚
当前 OpenClaw 工作台里有五个主要角色：
- 东路 / main：主控，负责 OpenClaw 全局治理、配置、路由、安全策略和跨 agent 协调。
- 零号 / predecessor：运维，负责服务器、站点、WordPress、1Panel、反代、证书、日志等基础设施。
- 砚台 / devous：秘书，负责提醒、待办、知识库、博客素材、草稿整理，以及把其他 agent 的最终结论汇总给我。
- 墨攻 / craftsman：工程副手，负责代码、技术方案、调试路径、底层和工程问题分析。
- 巡察 / auditor：复核者，只做关键操作后的验收，不参与日常闲聊，也不直接执行高风险改动。
这个分工的重点不是“名字好听”，而是边界清楚：
- 主控不长期替代专业 agent 干细活。
- 运维不接管全局治理。
- 秘书不越权改配置。
- 工程副手不负责日常秘书事务。
- 巡察不干活，只验收。
只有边界清楚，多 agent 才不会变成多人抢方向盘。
二、飞书入口要分清，不能串台
之前有一个实际问题：多个飞书入口、多个 agent、多个会话混在一起时，很容易出现“我明明在和 A 说话，结果 B 回了”的错觉，甚至真的串路由。
今天最后做了一轮 fresh test：分别给三个飞书机器人发送“你是谁？”，再只读检查实际路由和回复内容。
结果是通过的：
运维入口 → 零号 ✅
秘书入口 → 砚台 ✅
工程入口 → 墨攻 ✅每个入口都回到了自己的 agent：
- 零号回答自己是运维副手。
- 砚台回答自己是秘书入口。
- 墨攻回答自己是软件工程与技术研发副手。
这说明当前飞书三入口路由正常，没有串到主控，也没有互相串路由。
三、治理章程：把临时协商变成制度
今天最重要的产出，是正式完成了工作区内的 多 Agent 治理与安全章程 v1.0，并经过巡察复核通过。
它解决的不是某个单点问题，而是一组长期问题。
1. 什么必须升级给主控
比如：
- OpenClaw 全局配置
- Gateway / model / provider
- 飞书路由和 account binding
- agent 创建、删除、权限、身份边界
- A2A 权限和跨 agent 可见性
- 安全策略、访问策略、认证策略
- 疑似越权、凭据泄露、公开暴露异常
这些不能让单个专业 agent 自己拍板。
2. 什么必须等我明确确认
比如：
- 新建或删除 agent
- 改公网访问、反代、端口、防火墙、证书、认证
- 删除数据、不可逆恢复、批量清理
- 公开发布、修改、删除博客文章
- 外部共享文档或扩大权限
- 放宽安全策略
这类操作一旦做错，代价会比较高，所以必须先确认。
3. 秘书反馈规则
今天有一个教训：主控进入 P1 前置确认时，没有及时把“需要我选择下一步”的事项同步给砚台。结果秘书不知道，我也就不能通过秘书继续安排。
所以章程里明确规定：
凡是需要我确认、拍板或选择下一步的事项，main 必须通知砚台，由砚台汇总后反馈给我。
同时，砚台也不能把过程噪音都转给我。它只需要反馈：
- 最终确认点
- 最终阻塞项
- 完成结果
- 需要我拍板的事项
过程中的“巡察发现了什么、主控补了什么、运维查了什么”，除非影响决策，否则不应该连续推给我。
4. 信息分享矩阵
另一个教训是：不同 agent 之间不能形成信息孤岛。
比如，砚台准备整理博客或发布内容，但零号知道博客站点挂了。如果零号不分享这个信息，砚台就会基于错误状态继续推进。
因此章程里确定了原则：
高相关主动分享，低相关避免噪音。
也就是说：
- 会影响别人任务、计划、判断或风险的信息，要及时通知相关 agent。
- 与别人无关的普通过程、内部草稿、重复状态，不要广播。
这是在“信息孤岛”和“消息噪音”之间找平衡。
四、远程访问：暂停执行，但留下了安全规则
今天还处理了 P1：为 OpenClaw Control UI 设计受控的远程访问入口。
目标不是直接把底层服务暴露出去，而是通过独立管理域名、反代和访问控制，形成一个更可控的入口。
最终确认的方向是：
- 使用独立管理域名承载访问入口。
- 通过 IP allowlist 等方式做强访问控制。
- 后端服务端口不直接暴露到公网。
- 反代、证书、认证和 OpenClaw 自身访问控制需要分阶段验证。
后来我决定暂停 agent 自动执行，改为手动修改。原因很简单：这类工作涉及反代、证书、OpenClaw 配置和公网入口，一旦自动操作错了，可能影响访问或安全边界。
暂停前确认：agent 没有执行任何实际配置变更，无需回滚。
之后我手动完成了部分远程访问相关工作，砚台做了一轮只读观察：
- 管理域名的 HTTPS 访问链路已有阶段性验证。
- HTTP 到 HTTPS 的跳转符合预期。
- 证书链路观察正常。
- 后端服务端口未观察到直接公网暴露。
需要强调：这只是当时从测试环境看到的只读观察，不等同于完整安全审计。
同时，OpenClaw 自身仍有访问控制与认证相关配置需要继续收紧，包括来源限制、设备认证、公网访问 URL 等。
所以 P1 当前不能视为完全完成，只能算是公网访问链路的阶段性验证。后续仍需要手动收紧 OpenClaw 自身配置，并再次做只读复验。
这件事没有继续硬推，是正确的。系统治理里很重要的一条就是：不确定时停下，而不是硬上。
五、知识库 / 博客工作流 v1.0
今天第二份正式文件是工作区内的 知识库 / 博客工作流 v1.0，也已经通过巡察复核。
它定义了一个轻量结构：
inbox
blog-drafts
tech-notes
decisions
projects各自用途：
inbox：临时收集入口，放想法、链接、截图摘要、未分类资料。blog-drafts：博客草稿、标题候选、大纲、发布前版本。tech-notes：调试记录、源码阅读、工程方案、嵌入式/汽车底层技术笔记。decisions：已经确认过的重要决策和边界。projects：项目化资料、需求、进度、风险和交付件。
博客流水线则是：
- 砚台收集素材，整理初稿。
- 墨攻复核技术准确性。
- 零号确认站点和发布环境健康。
- 东路负责治理和异常协调。
- 巡察只在关键发布或高影响操作后复核。
最重要的发布规则是：
未经我明确确认，不发布、不修改、不删除线上文章。
这条必须长期保留。
六、任务总览：知道已经完成什么、暂停什么
今天还整理了一份任务总览状态页。
它记录了当前状态：
已完成：
- 模型和基础运行
- 多 agent 结构
- Feishu 入口与路由
- P0 安全基线
- 治理章程 v1.0
- 知识库 / 博客工作流 v1.0
- Feishu 三入口 fresh test
暂停中：
- P1 Control UI 远程访问与安全收敛
待验证 / 待确认：
- 图片输入测试
- Feishu 显示名统一
- OpenClaw 更新方案
- OpenClaw 自身 Control UI 安全收紧
这个总览的意义在于：后续不用靠记忆接续工作，而是可以看状态页继续安排。
七、今天真正完成的不是“配置”，而是“秩序”
今天没有发布文章，没有修改 WordPress，没有改 1Panel，没有继续动 OpenClaw 高风险配置。
但完成了几件更底层的事：
- 多 agent 分工清楚了。
- 谁能做什么、不能做什么清楚了。
- 什么需要我确认清楚了。
- 什么需要秘书反馈清楚了。
- 什么需要巡察复核清楚了。
- 信息分享和过程噪音的边界清楚了。
- 博客和知识库怎么流转清楚了。
- 飞书入口路由验证通过了。
这些东西短期看不如“改好了一个配置”明显，但长期看更重要。
因为一个个人助理系统真正可靠，不是因为它一次能做很多事，而是因为它知道什么时候该做、什么时候该停、什么时候该问、什么时候该验收。
今天的关键词，就是：
从能用，到可治理。
后续计划
接下来比较适合做的事：
- 图片输入 fresh test
验证飞书图片/附件输入能否正确进入模型。
- P1 手动安全收紧
在合适时间手动处理 OpenClaw 自身的来源限制、设备认证和公网访问 URL 等配置。
- Feishu 显示名统一
低优先级，只影响显示，不影响路由。
- OpenClaw 更新方案
后续单独规划容器/树莓派环境下的可回滚更新流程。
- 开始正式使用知识库 / 博客工作流
把日常想法、技术笔记、工程复盘逐步沉淀成可发布内容。
这篇文章本身，就是这条博客流水线的第一篇练习稿。
