爟 · Beacon

摘要

爟（Beacon）是一套为”人 + agent 团队”设计的任务账本与看板：谁在干什么、什么在等拍板、做完的证据在哪，全部落在一处可审计的账本里。它解决的是通用项目管理工具（此前用 Linear）解决不了的问题——那些工具默认汇报者诚实、执行者不失忆，而 agent 团队两条都不成立。核心机制是三件：证据分档（agent 的汇报分实证 / 自报 / 推测三档记账）、决策记录（每个决定走 open → decided → acting → settled 四态，决定后没人落实会报警）、下一步（每条进展都写明下一步，换会话、换 agent 时不用重新翻聊天记录）。数据是纯 markdown + Git，零外部依赖；网页看板已上线（私有部署），已完全替代 Linear 成为唯一任务主账本，迁移时任务编号连续续接、保号平移。

爟（guàn），《周礼》掌火之官，爟火传信：烽燧渐次点亮，消息从一座山头传到下一座山头。这块看板做的就是这件事——把人和 agent 之间的”火”稳定地传下去。

背景与动机

多 agent 并行工作时最大的痛不是干活，是账。三个反复发作的真实问题：

会话失忆：任务状态散落在各个对话里，上下文一压缩、进程一重启，“刚才做到哪了”就没了。任务的生命周期不能被会话绑架。
拍板蒸发：人做了决策，没有机制保证有人接手落实——拍了等于没拍。决策需要和任务一样有状态机、有超时报警。
自报不可信：agent 说”做完了”的成本为零。没有证据分档的账本会持续通胀，直到没人信它。

先用 Linear 管了几个月，结论是方枘圆凿：它是给人类团队做的，解决不了后两条——于是自研。设计目标一句话：进展、决定、下一步，都写在同一本账里。

系统概览

┌─ 数据层（单一事实源）────────────────────────────┐
│  Git 仓内的 markdown 卡片：一张任务 = 一个文件      │
│  文件头（frontmatter）存结构化字段，正文存日志       │
├─ 工具层 ────────────────────────────────────────┤
│  CLI（Python）：new / take / log / done …        │
│  Git 钩子校验 · 服务端对账自愈（reconciler）        │
├─ 呈现层 ────────────────────────────────────────┤
│  看板总览自动渲染（从卡片数据生成，不手工维护）        │
│  网页看板：本地服务 → Cloudflare Tunnel 出网        │
│            → Cloudflare Access 登录墙             │
└──────────────────────────────────────────────────┘

整个系统没有数据库、没有外部 SaaS：Git 就是数据库。每张卡是一个带结构化文件头的 markdown 文件，任何修改都是一次提交——可 diff、可回滚、可审计；看板页面从卡片数据自动渲染，保证呈现永远和账本一致。网页端不开公网端口：本地服务经 Cloudflare Tunnel（内网穿透隧道）出网，Cloudflare Access 做登录墙。

核心设计与功能

证据分档 + 新鲜度冷却

账本对每条信息标注可信度：实证（有测试输出、PR 链接、可复现命令）/ 自报（agent 说的，未经核验）/ 推测（从上下文推断）。同时信息带新鲜度：过期的状态自动”变冷”，不假装新鲜。这是整个系统的价值观——信任来自证据，不来自声明。人看板时能一眼分清”确认做完的”和”agent 说做完的”。

决策闭环

“待拍板”是一等泳道，不是备注。每个决策走显式四态：

open（等拍板）→ decided（已拍板）→ acting（有人接手落实）→ settled（落实完成）

拍板之后 48 小时没人接手，自动报警——拍板有回执，决策不再蒸发。对一个人管一支 agent 团队的场景，人的组织接口本质上就是这条决策队列。

agent 强约束：四道防线

针对”领了卡不干活”这个 agent 团队特有的问题，四道机制层层兜底：

CLI 闭环：领卡（take）/ 记录进展（log）/ 交卡（done）必须走命令行工具，直接改文件不算数
租约心跳：领卡即持有租约，超时不续（会话中断、agent 失联）任务自动收回，回到待领池
Git 钩子校验：提交时校验卡片状态合法性，不合规的变更进不了账本
服务端对账自愈：周期性对账，发现状态漂移（卡说在做、租约已死）自动修正

接力点机制

每条进度日志末尾写明”下一步”。换会话、换 agent，或者机器重启时，下一个接手的人打开卡片就知道从哪里继续，不用重新翻聊天记录。下一步写在账本里：接力点跟着任务走，不跟着某一次对话走。

从 Linear 平滑迁移

替换现成工具最大的成本是历史断裂。迁移做了保号平移：80 余张活跃卡带着原编号迁入，任务编号从 Linear 时代连续续接，历史引用不断链；Linear 退役为只读史料，不再写入。

当前进度

已生产运行：数据规范 v1.1 定稿并全量投入使用，日常所有任务（人派的和 agent 自领的）都走这套账本；看板总览自动渲染；网页看板 v1 上线 beacon.zleo.ai（私有入口）；四道防线全部生效。

在建：看板 v2——面向人的阅读体验（单页应用、人话摘要、双向留言，让手机上扫一眼就知道该拍什么板）。

规划：账本引擎迁入调度引擎偃（Vyane），让 CLI、网页、MCP 三个入口共享同一事实源；调度任务与账本卡片的双向关联，实现”派单即建卡、交卡即销单”。

技术亮点与工程判断

Git 当数据库是认真的选型，不是省事：任务账本的核心需求是审计与回滚，不是并发吞吐——版本控制系统天生就是为”谁在什么时候改了什么”设计的。一个人 + 一支 agent 团队的写入量，Git 绰绰有余。
markdown 是人机双读接口：人直接读写卡片，agent 用 CLI 结构化读写同一份文件——不需要为人和机器各维护一套视图，也永远不会两边不一致。
租约（lease）借自分布式系统：把 agent 会话当成随时会失联的分布式节点处理，用”持有租约 + 心跳续约 + 超时回收”解决任务卡死，比”人肉发现再手动重派”可靠得多。
约束住 agent 的不是提示词，是机制：提示词层面要求 agent”及时汇报”是愿望；CLI 闭环 + 钩子校验 + 对账自愈是保证。凡是希望 agent 一定做到的事，都要落成机制。
零依赖的代价意识：不引入数据库和 SaaS，换来的是零运维、零订阅、数据永远在自己手里；代价是查询能力有限——这个 trade-off 对单人团队是划算的，规模化时才需要重新评估。

后续规划

看板 v2：人话摘要与移动端友好的拍板界面
与偃的深度融合：账本引擎下沉为调度系统的原生模块
决策队列接入移动端重明（Horus），拍板不再依赖电脑在场