Railyard：面向长期运行的 AI Agent 项目的确定性工作流框架

Railyard是一个面向长期运行AI Agent项目的确定性工作流框架，旨在解决多Agent协作中的上下文爆炸、状态丢失、质量控制等核心问题。其核心机制包括SQLite持久化、角色隔离和显式审查门控。项目由yjwipod-1维护，发布于2026-06-02的GitHub平台（链接：https://github.com/yjwipod-1/railyard）。

传统多Agent协作存在四大痛点：

1. 上下文窗口爆炸：所有上下文放在一个会话，历史信息过载难以跟踪关键内容；
2. 上下文污染：系统实现细节与领域推理相互干扰；
3. 会话间状态丢失：会话结束后Agent忘记所有信息；
4. 缺乏质量门控：Agent工作直接呈现给用户，无适当审查流程。

角色分工：

• Human：最高决策者，设定方向、审查规划摘要、做最终架构决策；
• Planner：协调跨轨道决策，管理史诗级规划；
• Architect：每个轨道的管理者，审查Runner输出并决定任务执行；
• Runner：执行具体任务票，仅处理限定范围的工作。 核心概念：
• 轨道：分为System（工具/集成）和Domain（产品逻辑/内容）轨道，独立管理；
• 史诗：大型工作单元容器，包含多个任务票；
• 任务票：具体工作单元，含描述、状态、依赖等信息。

Railyard通过以下机制保障工作流的确定性：

1. 任务状态转换：遵循固定状态值，确保可预测性；
2. 可见性规则：Runner仅能看到就绪状态的任务票；
3. 轨道边界：System与Domain关注点分离；
4. 跨轨道依赖：显式声明并强制执行依赖关系；
5. 审查流程：工作从Runner→Architect→Planner→Human逐层审查。

MCP-lite工具接口：v0.3引入，封装工作流契约，支持读取（如get_ticket）、检查（如list_ticket_events）、调度（如dispatch_next_runner）等操作，SQLite为状态存储核心。 执行配置与失败分类：v0.6引入执行配置文件（提示置信度、路由建议）和失败分类（如permission_denied、command_failed等），提升可观测性与可操作性。

Railyard适用于以下场景：

1. 长期软件开发：管理复杂任务依赖，确保代码审查与质量控制；
2. 多Agent内容创作：协调研究、写作、编辑等角色协作；
3. AI辅助研究：确保多步骤分析与验证的审查和记录。

Railyard为长期AI Agent项目提供结构化工作流框架，通过角色隔离、持久化状态等解决核心协作问题。它不是Agent运行时，而是可复制的工作流结构、SQLite模式及辅助脚本。随着AI Agent应用扩展，此类框架将助力平衡自动化便利与流程控制、质量保障。