ABOS 自进化平台架构

目标：基于 abos-platform-current-source.md 这份当前事实源，理清并推进一个平台闭环：

1. 在 abos-at.work 上可观测 Mini/CVM 的服务状态、端口、健康探针、入口路由、日志摘要与漂移。

2. 在 Mac Mini 上进行低风险自我优化：巡检、自愈、漂移检测、修正建议生成。

3. 用户能够通过 abos-at.work 介入，对高风险动作进行确认、驳回、修正和回滚。

一阶段目标收敛为：先把“动力炉”做成 ABOS 治理控制面，不做真实执行闭环。它应在 /engine/ 用用户体验视角回答：现在最该关注什么、哪些页面/任务/议题需要处理、为什么、下一步去哪里看证据或推进。所有高风险动作仅生成建议，不提供直接执行按钮。

页面职责（后续改造依据）

• 首页：平台入口。回答“我能去哪儿？”；承载四大入口、系统定位、统一导航，不承载复杂运行细节。
• 动力炉：治理控制面。回答“我现在该管什么？”；承载今日重点、页面治理、观澜台任务治理、议事厅进行中事项、proposal/下一步建议。
• 观澜台：事实与证据面。回答“系统实际发生了什么？”；承载 cron/巡检/日报状态、任务目的、输入来源、运行逻辑、输出证据、异常解释、下一步建议和关联议题。
• 议事厅：飞书会话 spec 面。承载飞书里每一段会话总结形成的 ConversationSpec，帮助恢复会话目标、决策、待办、开放问题和上下文；这些 spec 可能存在遗漏、自动捕捉噪音或时效性问题，因此动力炉需要帮助识别 stale/needs_curation/未决状态。
• 藏书阁：AI 公网探索与用户指定理解内容的文章库。当前主要承载 AI 在公网探索、整理、入库的文章；也会包含用户要求 AI 理解和沉淀的内容。它不是实时控制台，重点是知识、资料、文章和后续可抽取的规则。

当前首页入口设计已收敛为 观澜台 / 动力炉 / 议事厅 / 藏书阁。后续页面变更优先通过 publish-file-to-cvm-public skill 作为发布门禁；运行后漂移巡检记录为后续能力，优先级较低。

Decisions

• 当前事实源以 /Users/zhengbokai/repo/ai/abos-platform-current-source.md 为准。
• 平台主线采用三面架构：

- CVM / abos-at.work：观测面、介入面、入口面。

- Mac Mini：执行面、自我优化面、本地事实面。

- 事实源/治理层：schema、巡检、漂移、建议、审批、回写。

• abos-at.work 首页新增自进化平台入口的设计方向已落地：去掉顶部导航中的 Notes 和 About，导航收敛为 观澜台 / 动力炉 / 议事厅 / 藏书阁；动力炉 URL 使用 /engine/；原 知识库 对外命名改为 藏书阁；原 Thread Specs 对外命名改为 议事厅。
• 页面职责按用户体验逻辑定义：

- 首页 = 平台入口，回答“我能去哪儿”。

- 动力炉 = 治理控制面，回答“我现在该管什么”。

- 观澜台 = 事实与证据面，回答“系统实际发生了什么”。

- 议事厅 = 飞书会话 spec 面，承载飞书每段会话总结形成的 ConversationSpec；spec 可能有遗漏、噪音或时效性问题，因此需要状态识别与整理机制。

- 藏书阁 = AI 公网探索文章与用户指定理解内容的知识库；当前主要是 AI 搜索/理解/沉淀的公网文章，不是实时任务控制台。

• OPS/动力炉 与现有入口的关系：动力炉 = 观澜台 + 议事厅 + 藏书阁 + 介入面 的治理控制面；观澜台保留为自动化汇报总线模块，cron/巡检属于观澜台的数据来源；议事厅承载会话 spec；风险建议、人工确认、驳回、备注、回滚与修正属于动力炉后续介入面。
• 自动化边界：只读巡检、健康探针、漂移检测、明确 owner 且低风险的本地服务重启可考虑自动执行；公网入口、鉴权、OpenResty/FRP/systemd/launchd 配置、删除进程/文件等必须人工确认。
• 动力炉一阶段目标：先做只读治理控制面，不做真实执行闭环。范围包括今日重点、页面治理、观澜台任务治理、议事厅进行中事项、proposal/下一步建议；所有高风险动作只生成建议，不提供执行按钮。
• 动力炉一阶段对观澜台/议事厅的“掌控力”定义为控制面而非执行面：统一索引内容、显示新鲜度/失效/未决状态、把观澜台报告关联到议事厅议题、从异常生成待确认 proposal、支持标记“已读/需跟进/已过期/需刷新/转议题”，但不直接修改高风险系统状态。
• 动力炉要承担跨页面/跨任务的治理职责：建立统一页面风格契约、数据契约和任务契约；新增页面必须优先通过 publish-file-to-cvm-public skill 作为发布门禁，检查共享模板/样式与风格漂移；定时任务必须输出可观测元数据（目标、输入、逻辑版本、产出、证据、错误、下一步建议）；所有进行中事项进入动力炉队列，按 owner、状态、新鲜度、风险、关联议题持续跟踪。绕过 publish skill 的运行后漂移巡检需要记录为后续能力，但一阶段优先级不高。
• 当前高优先级：先优化观澜台的人类可读输出。观澜台应从“cron 表格”升级为“任务说明 + 运行状态 + 证据 + 下一步”的任务治理视图；每个定时任务至少要能回答：它为什么存在、看了什么输入、按什么逻辑判断、产出了什么、失败原因是什么、下一步建议是什么、应关联哪个议事厅议题。

2026-07-07 16:29

• 2026-07-07：将《Loop Engineering 实战》映射为 ABOS 落地蓝图：ABOS 的最小自进化闭环应从“观澜台 cron/页面/会话异常 → 动力炉 proposal → 独立验证 → 人工确认/归档 → State 沉淀”开始；一阶段仍坚持只读控制面，高风险动作不直接执行。

Tasks

Doing

• [ ] 设计 Mini 巡检脚本与漂移检测输出。

Todo

• [ ] 设计自动修正白名单与人工确认清单。
• [ ] 保留待治理项：frps dashboard、Mini ControlCe、CVM opencode、OpenResty fallback 的验证命令与决策建议。
• [ ] 低优先级：实现动力炉页面运行后漂移巡检，用于发现绕过 publish-file-to-cvm-public skill 的手工/脚本改动。

Done

• [x] 已读取 /Users/zhengbokai/repo/ai/abos-platform-current-source.md。
• [x] 已探索 https://abos-at.work/ 首页、观澜台、Thread Specs、知识库入口，并形成 OPS 入口设计建议。
• [x] 已发布 spec 到 /thread/，并把 /thread/ 页面标题改为“议事厅”。
• [x] 已修改 https://abos-at.work/ 首页导航为 观澜台 / 动力炉 / 议事厅 / 藏书阁，去掉 Notes 和 About 导航入口。
• [x] 已创建并验证 /engine/ 动力炉占位页。
• [x] 已更新页面职责定义：议事厅承载飞书会话 spec，藏书阁承载 AI 公网探索文章和用户指定理解内容，作为后续页面改造依据。
• [x] 已优化观澜台页面输出：统一 ABOS 导航，增加“今日重点”、任务目的、输入/逻辑、异常解释、下一步建议和可观察性评分，并发布验证。
• [x] 已把 /engine/ 动力炉从占位页升级为一阶段治理控制面，包含今日重点、页面治理、观澜台任务治理、议事厅进行中事项，并发布验证。
• [x] 已简化议事厅列表页：卡片只展示标题、群组、更新时间；状态、任务、未决问题、brief 等信息进入详情页。
• [x] 已把观澜台拆成任务列表页 + 每任务详情页；列表仅展示任务名、状态、归属、更新时间，详情页保留目的、输入、逻辑、证据、异常解释和原始 JSON。
• [x] 已处理动力炉今日重点中可直接处理的问题：修复 wiki-lint-cron.sh 参数缺失，删除已完成的一次性 MR130 watcher 任务；TMEOA 登录态问题已定位为需要人工扫码，已生成并发送新二维码。

2026-07-07 16:29

• [ ] 基于 Loop Engineering 六组件补齐 ABOS 缺口：统一 Connectors 清单、proposal 状态模型、独立验证器、State schema、首个最小 Loop。

Open Questions

• ControlCe 的真实用途是什么？是否属于系统必要组件、第三方服务，还是可收敛/下线对象？
• ai.hermes.gateway 的健康判定应该以什么为准：launchd 进程、日志、Feishu WebSocket、还是某个内部状态文件？
• OpenResty fallback / -> frps :8080 是有意保留的动态入口，还是历史遗留需要收敛？
• opencode 常驻进程是否仍有任务价值？
• abos-at.work 介入面第一版是否只做“确认/驳回/备注”，还是需要直接触发执行动作？
• 首页新增动力炉入口时，顶部导航显示名固定为 动力炉，URL 使用 /engine/；仍需确定详情页副标题是否保留 Self-evolving Engine 或 自进化运行中枢。

Context

当前事实源

• 文件：/Users/zhengbokai/repo/ai/abos-platform-current-source.md
• 核验时间：2026-07-05 18:54 CST
• 范围：Mini 与 CVM 当前服务、入口、拓扑和待治理项。
• 约束：只记录当前仍存在的服务、入口、进程和风险项；不记录已清理历史项；不包含 token、password、cookie、SSH 私钥等敏感信息。

关键现状

Mini：

• wechat-work：*:8066，/health = 200，launchd com.zhengbokai.wechat-work。
• frpc：127.0.0.1:8022，launchd com.abos.frpc。
• Chrome / tmeoa-reader：127.0.0.1:51074。
• ai.hermes.gateway：launchd 有进程，本轮未发现 TCP 监听。
• ControlCe：*:5000、*:7000，用途待确认。
• clash-verge：127.0.0.1:33331。

CVM / abos-at.work：

• OpenResty：:80、:443、:8090。
• codex2api：127.0.0.1:18080。
• frps：:8999、:8080、:8443、:8995。
• frpc-ssh：STCP 链路。
• mihomo：127.0.0.1:7891/7896/9097。
• Docker active 但当前无容器。
• opencode 进程存在，未发现监听端口。

待治理项

1. frps dashboard :8995：公网监听，虽有 Basic Auth，后续建议收敛。

2. Mini ControlCe *:5000/*:7000：全网卡监听，职责待定。

3. CVM opencode process：无监听端口，需确认价值。

4. OpenResty fallback / -> frps :8080：泛入口边界需明确。

2026-07-07 09:26

• 2026-07-07：用户在本 thread 提供微信公众号文章链接 https://mp.weixin.qq.com/s/AQLsjzD0s9d8kGUGdul0sg，文章已成功读取。标题为《Loop Engineering 实战：实现从日志扫描到预发部署的全自主闭环》（阿里云开发者）。核心参考点：Loop = 发现/交付/验证/持久化/调度五动作 + Connectors/Automations/Skills/Worktrees/Sub Agents/State 六组件；适合作为 ABOS 动力炉/观澜台自进化闭环设计参考。

Archive

2026-07-05 首页探索结论

已探索 https://abos-at.work/ 首页、观澜台、Thread Specs、知识库入口。

当前首页结构：

• 顶部导航：Notes / 观澜台 / Thread Specs / 知识库 / About。
• Hero CTA：阅读最新札记 / 进入观澜台 / 查看 Thread Specs / 了解在下。
• Notes 卡片区包含：AI Collaboration、Engineering Practice、Knowledge System、Observatory、ConversationSpec。
• 视觉语言：米白纸感背景、青绿/蓝绿水墨科技风、卡片式入口、工程实践/事实验证/经验沉淀文案。

初步建议：

• 自进化平台不应作为孤立页面，而应作为“运行闭环总入口”。
• 顶部导航建议在“观澜台”后增加短入口 OPS 或 自进化 OPS。
• Hero 区建议把“进入观澜台”升级或旁路为“进入 OPS”，避免超过 4 个按钮造成首屏入口过载。
• 卡片区新增重点卡：Self-evolving OPS / 自进化平台，文案强调连接任务、知识、观测、告警、复盘和人工修正。
• 层级关系建议：Notes=经验记录，观澜台=运行汇报，Thread Specs=会话状态，知识库=知识沉淀，OPS=把上述能力串成闭环的运行平台。