Beatless 全流程：从触发到博客输出

很多自动化项目表面上都能跑，但一旦追问两个问题，结构就会立刻变得模糊：

• 一个信号到底是怎么变成具体动作的
• 一篇最终发布出来的博客，到底是从哪里来的

Beatless 当前这一版的价值，不只是把 Codex、Gemini、Kimi、MiniMax、StepFun 接到一起，而是把整个系统压成了一个可以解释、可以追踪、也可以继续扩展的分层流程：

• 入口脚本只负责触发
• agent 只负责任务归类
• router 只决定谁来做哪一步
• pipeline 负责把步骤串起来
• executor 和 provider 明确分工
• state / event 统一记录发生了什么
• dashboard 只读统一状态

如果只用一句话概括这套系统，可以写成：

Beatless 是一个以 Codex 为主执行器、以多 provider 为辅助、以 pipeline 为真正业务单元的本地自治编排系统。

这篇文章只回答两个问题：

1. Beatless 的整个流程到底是怎么走的。
2. auto-research 里的博客内容，当前到底来自哪里。

一图总览#

如果只记住这篇文章的一句话，那就是：

Beatless 不是“一个大 prompt”，而是一条从触发、路由、执行、审查到状态回写的分层流水线；而 blog 当前还处在“上游已成形、正文未完全自动化”的阶段。

为了让后面的长文更容易进入，先把结论压成三点：

1. Beatless 的真正业务单元是 pipeline，而不是入口脚本。
2. Codex 是主执行器，但研究、提取、写作、规划这些能力被拆到了不同 provider 上。
3. auto-research 里的 blog 正文当前主要仍来自结构化 research 输入的整理，而不是自动 draft 后直接发布。

一、Beatless 想解决的不是“多模型调用”，而是“多层解耦”#

这套系统的核心目标，不是把多个模型随便串起来，而是把不同职责拆开。

最重要的几层是：

trigger / scheduler
  ->
agent policy
  ->
route planner
  ->
pipeline runner
  ->
executor / provider
  ->
state + event log
  ->
dashboard / blog outputs

如果不做这层拆分，系统很快就会退化成两种形态之一：

• 一堆硬编码脚本，能跑但难维护
• 一个“什么都能做”的大 prompt，能演示但难复现

Beatless 现在的取向恰好相反：

• 把“谁该做什么”交给 agent
• 把“这一步该找谁”交给 router
• 把“真实业务步骤”交给 pipeline
• 把“能不能改文件、跑命令、推 PR”收口到 executor
• 把“只提供推理、审查、提取、写作”收口到 provider

二、第一层：入口脚本只负责触发，不负责业务#

Beatless 表面上看起来像很多入口脚本在跑：

• GitHub PR
• GitHub response
• GitHub issue outreach
• auto-research
• paper harvest
• blog maintenance

但这些入口本身并不承载主要业务。当前做法是：

• 外层脚本只接收 CLI 参数
• 再转给对应的 pipeline
• 真正逻辑都放在统一包里

这样做的好处很直接：

• wake-gate 可以继续保留
• 命令行入口可以继续兼容
• 真实业务逻辑不会散在多个脚本里

从长期维护看，这一步很关键，因为它让“运行入口”和“业务实现”不再是同一个东西。

三、第二层：agent 只做任务归类，不直接执行#

Beatless 里现在有几类 agent，它们更像 policy layer，而不是执行器：

• Aoi：分发与调度
• Lacia：规划、repo scout、issue outreach
• Methode：工程实现与 CI 修复
• Satonus：审查与 correctness guard
• Snowdrop：research 与 paper 相关任务
• Kouka：写作、翻译、交付

它们解决的是“这类任务应该走哪条线”，而不是“直接调哪个模型”。

例如：

• 一个“修 PR 上的 CI”任务，会被归到 Methode
• 一个“找有潜力仓库并起草 issue”任务，会被归到 Lacia
• 一个“扫描 research workspace 并决定是否继续跑实验”的任务，会被归到 Snowdrop
• 一个“blog draft / translation / delivery”任务，会被归到 Kouka

这一层的意义在于，系统可以先做任务判断，再进入后面的 route matrix，而不是让每个脚本自己猜该调用哪个模型。

四、第三层：router 决定谁来做，而不是自己下场执行#

Beatless 的 route planner 只回答一个问题：

这一步，应该交给哪个 executor 或 provider？

它不直接跑命令，也不直接发请求。
它只根据 task type 输出一份 route decision，例如：

github_pr_implementation
  executor: codex
  consultants: kimi
  reviewers: gemini, kimi

或者：

paper_friction
  primary: kimi
  reviewers: gemini

或者：

blog_draft
  primary: minimax
  reviewers: codex, gemini

这一层最重要的规则有两个：

1. 能动 workspace 的只有 executor#

当前真正能改文件、跑命令、做 PR 的主执行器是 Codex。
这也是为什么 GitHub PR、CI repair、research execution 这些“需要 shell 和文件系统”的步骤都落到 Codex lane。

2. writer 和 reviewer 要分家#

如果一条 route 里是 Codex 在实现，就不允许最终 review 还落回同一家族。
这就是为什么系统里有一条明确规则：

no_same_family_final_review

它的本质不是增加复杂度，而是防止“自己写、自己审”的闭环。

五、第四层：pipeline 才是 Beatless 的真正业务单元#

如果说 agent 决定任务类型，router 决定模型组合，那么 pipeline 才是整个系统里最重要的一层。

因为真正的工作都发生在这里。

1. GitHub PR pipeline#

这条线对应的是：

discover
  ->
preflight
  ->
issue triage
  ->
implementation
  ->
review
  ->
record

它的目标很明确：
找已有 open issue，判断是否值得接，能接的话就进入实现和 review，最后准备 PR。

2. GitHub response pipeline#

这条线不是找新 issue，而是跟进“已经开的 PR”。

主要处理：

• maintainer comments
• unreplied review comments
• CI failures
• retry ladder

它的核心作用，是让一个已经发出去的 PR 不会因为后续评论和 CI 失败而掉出视野。

3. GitHub issue outreach pipeline#

这是另一条完全不同的线：

repo scout
  ->
friction detect
  ->
issue proposal
  ->
etiquette guard
  ->
human approve
  ->
create issue
  ->
follow-up

这条线的目标不是“做 PR”，而是：

• 先找高影响力或有潜力的项目
• 再找真实、可压实的问题
• 先起草 issue
• 经过人工批准后再对外发言

只有当 maintainer 接球之后，才有可能转回 github-pr。

4. research pipeline#

这条线围绕 research workspace 工作：

scan workspaces
  ->
intent triage
  ->
survey
  ->
axiom / friction
  ->
dispatch
  ->
loop
  ->
review

它的目标不是“生成一段总结”，而是决定：

• 哪个 workspace 还值得继续
• 当前处在哪一轮
• 应该继续实验、暂停，还是 halt

5. paper pipeline#

paper harvest 这一层负责：

• 抓最新候选论文
• 去重
• 做 friction / wide-context 判断
• 写入 Zotero
• 同步到笔记系统

这一层更像 research 的输入面。

6. blog pipeline#

blog pipeline 在设计上是：

audit
  ->
classify
  ->
draft
  ->
translate
  ->
faithfulness review
  ->
publish
  ->
record

但这里要特别强调一句：

当前实现还没有真正走到自动写正文这一步。

这也是理解 Beatless 当前 blog 行为的关键。

六、第五层：Codex 是主执行器，但不是唯一模型#

Beatless 当前不是“单模型系统”，而是“Codex 主执行器 + 多 provider 辅助”的结构。

1. Codex：主执行器#

Codex 负责：

• 改代码
• 跑命令
• 修 CI
• 做 PR
• 执行实验

这部分需要真实 shell 能力，所以必须由 executor 承担。

2. Gemini：长上下文 review 与 research 综述#

Gemini 更适合：

• literature grounding
• long-context review
• second opinion
• correctness critique

3. Kimi：paper friction 与低成本长上下文抽取#

Kimi 更适合：

• paper friction extraction
• cheap critique
• long-context extraction

4. MiniMax：写作、翻译、交付#

MiniMax 在设计上负责：

• blog draft
• blog translation
• media / delivery

5. StepFun：规划与 triage#

StepFun 更偏：

• intent routing
• planning
• fast triage

所以这套结构的关键不是“哪个模型最强”，而是：

不同模型承担不同角色，真正需要操作 workspace 的收敛到 Codex，其他模型保持 provider 身份。

七、第六层：所有结果最后都要写进统一状态#

Beatless 当前还有一个很重要的设计点：
不允许每条 pipeline 各写各的私有状态格式。

所有主要结果都会进入统一的：

• status files
• event log

这层的作用有三个：

1. 让 dashboard 不需要懂业务脚本细节#

dashboard 读的是统一 contract，而不是去猜：

• 哪个脚本写了什么临时文件
• 哪个状态字段叫什么
• 哪条 pipeline 的状态文件放在哪

2. 让系统能追溯“发生了什么”#

每个 event 至少会记录：

• pipeline
• stage
• agent
• route
• executor
• providers
• status
• evidence

这让系统更像一个 control plane，而不是一堆只能现场观察的脚本。

3. 让 pipeline 之间可以互相接力#

例如：

• issue outreach 的 follow-up 可以继续推回 github-pr
• research 和 paper 的产出理论上可以继续喂给 blog

如果没有统一状态，这种接力就只能靠脚本之间互相猜测。

八、dashboard 在这套系统里只负责“读状态并展示”#

Beatless 的 dashboard 不是控制中心，而是观测面。

它做的事情很纯：

• 读取 provider 状态
• 读取 routes
• 读取 pipeline 状态
• 读取 activity event stream
• 读取 system / budget / GPU 信息

所以 dashboard 本身不决定业务，只反映：

• 哪条 pipeline 最近跑了什么
• 当前 provider 是否可用
• 哪条 route 指向谁
• blog、paper、research、GitHub 相关任务是否健康

从工程角度看，这种做法很稳，因为 UI 不需要知道每条脚本的私有实现。

九、auto-research 里的博客内容当前来自哪里#

这是最容易误解的一点。

表面上看，Beatless 已经有了 blog pipeline，也已经给 MiniMax / Codex / Gemini 分好了：

• draft
• translate
• faithfulness review

但当前 reality 并不是“系统已经全自动写 blog”。

1. 设计上的来源#

从设计目标看，blog 内容未来应该来自三类上游：

• research pipeline 的阶段性输出
• paper pipeline 的论文整理与结论
• GitHub / issue / PR 流水线里积累的真实案例与复盘

也就是说，blog 应该成为这些 pipeline 的公开表达层。

2. 当前真实来源#

当前 blog pipeline 仍然是 audit-only。

它现在真正会做的事情是：

• 扫 blog 目录
• 看哪些文章缺中文
• 看哪些内容 stale
• 写 audit report
• 写 status 和 event

但它不会自动生成正文。

所以 auto-research 目录里现在真正的文章来源，仍然是：

• 手动提供的 research zip
• 调研文档
• 笔记材料
• 外部贡献与实验过程中的真实记录
• 再整理成 MDX 文章

也就是说，当前 Beatless 的 blog 正文来源，实际是：

research inputs 和 project outputs 经过人工整理后写入，而不是由 pipeline 自动起草后直接发布。

十、为什么 blog 现在还没有 fully automated#

这不是缺一条 prompt 那么简单，而是因为正文生成要比 audit 难得多。

真正自动写 blog 至少要解决四件事：

1. 输入源要足够稳定#

research workspace、paper notes、issue outreach、PR 复盘，这些内容必须先结构化到足以供下游消费。

2. draft 和事实校验要分开#

如果写作和事实检查混成一步，内容会很容易滑向：

• 说法太大
• 细节失真
• 把推断写成事实

3. 发布边界必须锁死#

当前 blog 写入范围只允许落在 auto-research 指定目录，这是必要的 guard。
没有这个边界，自动写稿就很容易污染博客其他内容。

4. 需要比 audit 更严格的 review#

真正能自动发出去的文章，至少要经过：

• draft
• translation
• faithfulness review
• scope guard

所以 blog pipeline 现在停在 audit-only，并不代表它没价值。
相反，它说明这条链在真正放开自动写稿之前，先把路径、状态和写入边界压稳了。

十一、当前阶段最准确的总结#

如果把 Beatless 当前状态压成一句最准确的话，可以这样说：

Beatless 已经完成了从入口脚本、agent、router、pipeline、executor/provider、state 到 dashboard 的主干解耦，但 blog 正文生成目前仍处于“上游已成形、发布链路未完全自动化”的阶段。

更具体一点：

• GitHub 侧已经能做 issue outreach、PR、PR follow-up
• research 侧已经能扫描与调度 workspace
• paper 侧已经能做 harvest 与同步
• dashboard 已经能统一读取状态
• blog 侧已经有写作路由、审计流程和写入边界
• 但正文仍然主要来自结构化研究材料的人工整理

十二、这条系统线真正重要的地方#

Beatless 当前最有价值的，不是“已经实现了多少自动写作”，而是已经把几个最容易混在一起的概念分开了：

• 触发和执行分开
• agent 和 model 调用分开
• executor 和 provider 分开
• business pipeline 和 dashboard 展示分开
• blog 审计和 blog 正文生成分开

只有这些边界先成立，后面再把 research -> draft blog -> review -> publish 接起来，系统才不会重新塌回一堆 prompt 和脚本的混合物。

因此，理解 Beatless 的最好方式，不是把它看成“一个会自动写东西的工具”，而是把它看成：

一个先把任务流、模型分工、状态记录和输出边界压清楚，再逐步放开自动化能力的本地自治编排系统。