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-trackerAgentagents/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漂移检测的时间锚点milestones3~7 个里程碑数组每个含id、name、criteria、statuspending/ 进行中 /donecurrentMilestone当前活跃里程碑 id初始为第一个里程碑如m1sessions会话记录数组初始为空每次签出追加一条在底层这个工具由 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 给出的前进路径是遗留当前写入规范形式前进方向状态horizonsgoals-horizons遗留读 新写入待定horizon-sessionsgoals-horizon-sessions遗留读 新写入待定researchgoals-research遗留读 新写入待定research-sourcesgoals-research-sources遗留读 新写入待定dossierdossier文档化的 base-name 例外adradr-patternsruflo-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/clilatest hooks post-task --task-id TASK_ID --success true --store-results true npx claude-flow/clilatest 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 arent——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 isnt 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 triggersskills/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、命令与插件元数据始终一致。落地建议把 Horizon Track 用起来综合技能文档、Agent 定义与仓库实现落地时的关键实践可归纳为先定义完成再定义任务objective 里写清成功标准里程碑的criteria必须可验证否则二元判定无法执行固定 3~7 个里程碑太少无法体现进展太多则失去检查点意义坚持签到/签出纪律会话首尾各一次工具调用成本极低收益是跨会话的不失忆把漂移当信号而非故障命中四种漂移信号之一就触发适应流程——重新评估、调整里程碑或时间轴注意命名空间演进新写入优先用goals-horizons等规范形式读取兼容旧命名为未来迁移留好路这套协议的价值在于它把长周期目标管理从靠聊天记录回忆升级为靠持久化状态驱动的可审计流程而这一切在 ruflo 中只需要一个技能文件、一个 Agent 定义和一组 MCP 工具即可运行。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考