ruflo 跨会话目标追踪实战：用 Horizon Track 技能管理多周级长周期任务-平芜编程栈

ruflo 跨会话目标追踪实战：用 Horizon Track 技能管理多周级长周期任务

【免费下载链接】ruflo🌊 The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo

本文讲解 ruflo 生态中用于管理跨会话、跨天、跨周长期目标的horizon-track技能：如何初始化一个 "horizon"（地平线目标）、如何通过会话签到（check-in）与会话签出（check-out）保证跨会话连续性、如何用里程碑（milestone）检查点推进进度，以及如何用漂移检测（drift detection）发现目标失控信号。读完本文，你将掌握一套完整的长周期目标追踪协议——它依赖 ruflo 的持久化记忆命名空间与 MCP 工具链实现，可直接在你的多会话 Agent 工作流中落地。

关联文档：SKILL.md；配套 Agent 与命令见 horizon-tracker.md、goals.md；插件总览见 ruflo-goals README。

适用场景：什么是 "需要 horizon 追踪" 的任务

单次会话能完成的任务不需要 horizon。horizon-track面向的是注定无法在一次对话里收尾的工作：

多周迭代的功能开发（multi-week features）
长周期的研究项目（research programs）
跨多轮的迁移改造项目（migration projects）
任何需要跨对话保持进度连续性的工作

判断标准只有一个：目标是否大到无法在单次会话内完成。只要答案是肯定的，就应该为其建立 horizon，而不是依赖会话上下文里的临时状态——因为会话一旦结束，临时上下文就会丢失。

从 ruflo-goals README 的选择指南看，ruflo-goals 按任务形态把工作分成四类，horizon-track明确对应 "long-running objective"：

任务形态	使用的 Agent / Skill
一个待回答的问题	`deep-researcher`/`deep-research`
一个待向外扩展的种子实体	`dossier-investigator`/`dossier-collect`
一个多步骤目标	`goal-planner`/`goal-plan`
一个长周期运行的目标	`horizon-tracker`/`horizon-track`

配套的horizon-trackerAgent（agents/horizon-tracker.md）以 Sonnet 模型承载同一套方法论，二者共享完全相同的记忆命名空间与追踪原则。

追踪协议总览：七个步骤

horizon-track把长周期追踪组织为七个可执行步骤，形成一个完整的生命周期闭环：

初始化 horizon——定义目标、目标日期、3~7 个里程碑
存储 horizon——调用memory_store写入命名空间horizons
会话签到（check-in）——每次会话开始：召回 horizon、复查里程碑、评估漂移、规划本次贡献
工作并记录——更新里程碑状态、记录会话摘要、存储中间发现
会话签出（check-out）——每次会话结束：更新状态、记录成果、标注阻塞与范围变化、估算剩余工作量
里程碑完成——核验完成标准、沉淀学习模式、推进到下一里程碑
漂移检测——发现目标失控信号并触发应对

下面按阶段展开讲解每一步的实操细节。

初始化与存储：定义目标、里程碑并持久化

定义 objective 与 targetDate

初始化第一步是为目标写下具体的成功标准（concrete success criteria）——这是 horizon-tracker.md 强调的起点："Define the objective with concrete success criteria"。模糊的目标无法被里程碑核验，也无法被漂移检测量化。同时设置：

目标日期（targetDate）：期望完成的截止日期，漂移检测中"时间轴漂移"的计算基准；
3~7 个里程碑（milestones）：每个里程碑必须携带可验证的完成标准（criteria），这是后面"里程碑是二元的"原则的基础。

存储：memory_store 与 horizons 命名空间

定义完成后，调用mcp__plugin_ruflo-core_ruflo__memory_store，命名空间为horizons，键为horizon-[name]。原技能文档给出的完整负载结构如下：

{ "objective": "...", "created": "2026-04-28", "targetDate": "2026-05-15", "milestones": [ {"id": "m1", "name": "...", "criteria": "...", "status": "pending"}, {"id": "m2", "name": "...", "criteria": "...", "status": "pending"} ], "currentMilestone": "m1", "sessions": [] }

字段说明：

字段	含义	取值建议
`objective`	目标描述，含成功标准	具体、可验证，不要写"完成 X"而写"X 满足什么条件才算完成"
`created`	创建日期	`YYYY-MM-DD`，作为时间基线
`targetDate`	目标截止日期	`YYYY-MM-DD`，漂移检测的时间锚点
`milestones`	3~7 个里程碑数组	每个含`id`、`name`、`criteria`、`status`（`pending`/ 进行中 /`done`）
`currentMilestone`	当前活跃里程碑 id	初始为第一个里程碑，如`m1`
`sessions`	会话记录数组	初始为空，每次签出追加一条

在底层，这个工具由 v3/src/infrastructure/mcp/tools/MemoryTools.ts 注册：memory_store接受id、agentId、content、type、metadata等参数，最终通过backend.store(memory)写入持久化记忆后端（见 MemoryTools.ts）。也就是说，"horizon 状态持久化"最终落在 ruflo 的记忆后端上——这正是跨会话连续性的基础设施保证。

命名空间规范与 ADR 背景

horizon-track共使用三个记忆命名空间：

horizons——活跃 horizon 的定义与当前状态
horizon-sessions——按[horizon]-[date]键组织的逐会话摘要
horizon-learnings——horizon 执行期间发现的模式与洞见

需要说明的是，这三个命名空间属于遗留命名。根据 ruflo-goals ADR-0001 的记录，它们先于 ruflo-agentdb ADR-0001 的<plugin-stem>-<intent>命名约定而存在。ADR-0001 给出的前进路径是：

遗留（当前写入）	规范形式（前进方向）	状态
`horizons`	`goals-horizons`	遗留读 + 新写入待定
`horizon-sessions`	`goals-horizon-sessions`	遗留读 + 新写入待定
`research`	`goals-research`	遗留读 + 新写入待定
`research-sources`	`goals-research-sources`	遗留读 + 新写入待定
`dossier`	`dossier`	文档化的 base-name 例外
`adr`	`adr-patterns`（ruflo-adr 所有）	移交给规范所有者，本插件不写入

当前实现新写入应使用规范的 kebab-case 形式，读取则新旧两个命名空间都查以保持向后兼容；同时严禁遮蔽保留命名空间（pattern、claude-memories、default）。了解这一层，你在长期使用 horizon 数据时就能预判未来的迁移方向。

会话签到（Check-In）：跨会话连续性的起点

horizon-tracker的第一条追踪原则是"Always check in"——任何会话的第一个动作就是召回 horizon 状态。签到流程：

召回 horizon：调用mcp__plugin_ruflo-core_ruflo__memory_retrieve，键horizon-[name]，命名空间horizons
复查里程碑状态：确认当前活跃里程碑及其完成标准（currentMilestone+ 对应criteria）
评估漂移：对照时间轴、范围、方法三个维度自问"我们还在正轨上吗？"
规划本次贡献：明确本次会话为该里程碑做什么

memory_retrieve在 MemoryTools.ts 中的签名是按id取回单条记忆，底层调用backend.retrieve(id)（MemoryTools.ts）。这里把id约定为horizon-[name]，就实现了"用一个稳定键回读整个 horizon 状态"的协议。

签到的意义在于：会话上下文是易失的，horizon 状态不是。没有签到，第二次会话的 Agent 等同于"失忆"开工；有了签到，每次开工都从持久化的真实状态出发。

工作与记录：把进展写回记忆

会话进行中，horizon-track要求随进度即时记录，而不是等结束时补记：

更新里程碑状态：完成的工作使milestones[].status从pending变为完成态
记录会话摘要：写入horizon-sessions命名空间，键为[horizon]-[date]
存储中间发现：有价值的中间结论、数据、链接，同样按会话维度落库

这一"过程即记录"的设计，使任何时刻中断会话都不会丢失关键信息，也为后面的漂移检测提供了时间轴上的数据点。

会话签出（Check-Out）：每次会话的收尾协议

对应 "Always check in"，第二条原则是"Always check out"——最后一个动作是把更新后的状态持久化。签出时完成四件事：

更新 memory 中的 horizon 状态：把本次会话后的milestones、currentMilestone等写回horizons命名空间
记录本次完成的工作：what was accomplished
标注阻塞项或范围变化：blockers、scope changes——这些是漂移检测的原始素材
估算当前里程碑的剩余工作量：remaining effort，供下次签到与时间轴评估使用

值得注意的是，horizon-trackerAgent 还提供了神经学习回路：任务完成后可用以下 CLI 命令沉淀成功模式并回查历史模式：

npx @claude-flow/cli@latest hooks post-task --task-id "TASK_ID" --success true --store-results true npx @claude-flow/cli@latest memory search --query "TASK_TYPE patterns" --namespace patterns

这与技能中的hooks_intelligence_pattern-store工具形成互补：前者走 CLI hooks 通道，后者走 MCP 工具通道，目的都是把"这次做对了什么"变成下次可复用的模式。

里程碑完成：二元判定与模式沉淀

horizon-track对里程碑的态度是严格的二元判定："Milestones are binary: either criteria are met or they aren't——no partial credit"。完成标准（criteria）达标就是达标，不达标就是不达标，不设部分完成。这是保证目标不被"差不多"腐蚀的关键机制。

里程碑完成时的动作序列：

核验完成标准：逐条对照该里程碑的criteria
沉淀学习模式：调用mcp__plugin_ruflo-core_ruflo__hooks_intelligence_pattern-store，把"什么做法让这个里程碑顺利通过"存入模式库
推进到下一里程碑：更新currentMilestone指向下一个id
必要时重新校准时间轴：Recalibrate timeline if needed——如果此前有漂移，这里就是修正机会

这套"完成 → 沉淀 → 前进 → 校准"的循环，让每个里程碑既是进度的检查点，也是知识积累的节点。

漂移检测：识别目标失控的四种信号

horizon-track的哲学是"Drift is normal: the goal isn't to prevent drift but to detect and adapt to it"。漂移不是故障，是常态；追踪器的职责是及时感知并适应。技能文档定义了四种必须标记的漂移信号：

进度速率不足：Progress rate suggests target date will be missed——按当前速率会在targetDate之前完不成
范围膨胀：Scope has grown beyond original definition——工作内容超出最初定义
依赖变化：Dependencies have changed——外部依赖发生变化
方法需要根本性重估：Approach needs fundamental rethinking——当前路径的基本假设不再成立

配套的horizon-trackerAgent 在此基础上扩展为五个维度（agents/horizon-tracker.md）：

漂移类型	信号
Timeline drift（时间轴）	进度速率表明会错过目标日期
Scope drift（范围）	工作超出原始定义
Approach drift（方法）	基本假设已改变
Dependency drift（依赖）	外部依赖发生偏移
Priority drift（优先级）	其他工作占用了产能

一旦命中任一信号，正确的动作不是"硬扛"，而是进入适应流程：重新评估状态、调整里程碑计划或时间轴、必要时重新校准。这与同一插件内goal-plan技能的"replanning triggers"（skills/goal-plan/SKILL.md）理念一致——长周期任务的管理核心是自适应而非刚性执行。

配套命令：/goals 快速总览

在 horizon 运行期间，可用/goals命令随时查看全局状态（commands/goals.md）。其流程：

调用mcp__plugin_ruflo-core_ruflo__memory_list，命名空间horizons，枚举全部活跃 horizon（注意：需要语义过滤时才用memory_search，*不是合法的语义查询）
对每个 horizon 展示：objective、当前里程碑、进度百分比、目标日期、漂移状态
调用memory_list列出research-synthesis命名空间，查看已完成的研究报告
汇总成一张 horizons 与研究状态总表

/goals让多 horizon 并行的场景有了一屏总览能力，特别适合同时在跑多个长期目标的团队或个人工作区。

验证与质量保障

horizon-track并非孤立文档，而是 ruflo-goals 插件契约的一部分。插件的验证入口是 scripts/smoke.sh，运行方式：

bash plugins/ruflo-goals/scripts/smoke.sh # Expected: "10 passed, 0 failed"

其中与 horizon 直接相关的检查项包括：第 2 步确认horizon-track技能及其name:/description:frontmatter 存在；第 3 步确认 README 的选择指南覆盖 "long-running" 任务形态；第 7 步确认 legacy-vs-canonical 命名空间映射表（含horizons→goals-horizons）；第 10 步确认技能没有通配符工具授权（allowed-tools不允许*，SKILL.md 中显式列出的 14 个 MCP 工具 + Bash/Read/Write 即为此检查的落实）。这套 smoke-as-contract 机制保证技能文档、Agent、命令与插件元数据始终一致。