关于 / 概览
概览
它是围绕 agent 的工作系统，面向持久、可监督的工程流程。
OpenSymphony 是对 OpenAI Symphony
设计的一次 Rust 绿地实现。它把编排权保留在 harness 之外，为每个 issue 提供独立工作区，并通过独立 agent harness 保留提供商与 LLM 选择上的灵活性，同时让编排模型保持稳定。
创建者
两层视角
OpenAI Symphony 定义什么，OpenSymphony 又实现什么。
OpenAI Symphony 是什么
一种工作系统编排模型
OpenAI Symphony 把 ticket、workspace 和 workflow contract 视为一等运行时概念，并假设存在轮询、对账、保留工作区和人工审查。
OpenSymphony 做了什么
一个本地优先的 Rust 具体实现
OpenSymphony 用 Linear 管理 issue，把 OpenHands 作为独立 harness 层来执行任务，用只读控制平面做可观测性，并提供 TUI 供操作员监督。
架构
五层结构让系统保持清晰。
关键边界在于：OpenHands 负责执行，而 OpenSymphony 负责执行之外的生命周期。
Policy
工作流文件与仓库规则
WORKFLOW.md、AGENTS.md 和本地 skills 共同定义仓库希望系统如何运行。
Configuration
类型化的工作流与运行时配置
OpenSymphony 会在执行前解析配置、环境变量、路径以及 OpenHands 设置。
Coordination
调度、重试与对账
编排器负责 issue 资格判断、并发限制、层级调度、重试以及启动恢复。
Execution
工作区管理与 OpenHands 运行时
每个 issue 都映射到一个确定性工作区，而 OpenHands 在这个边界内负责会话和工具执行。
Observability
控制平面与 TUI
TUI 从控制平面读取信息，因此监控与系统正确性保持分离。
工作流摘要
把完整闭环走一遍。
这就是当前 MVP 的实际运行形态。
01
轮询 Linear 中可执行的 issue
候选 issue 来自 tracker，并带有层级感知的调度规则，因此被阻塞的父任务会继续保持阻塞。
02
准备 issue 工作区
Hooks、清单、提示词产物和 ownership 检查都保存在 issue 作用域目录中。
03
连接或恢复执行会话
OpenSymphony 默认复用每个 issue 的会话，并处理继续执行、启动恢复和运行时对账。
04
通过控制平面观察进度
操作员可以在 TUI 中查看运行中的工作，并检查快照、事件、重试和 issue 状态。
05
让审查与恢复留在同一个闭环里
PR 反馈、返工、重启恢复和后续运行都继续附着在同一个 issue 上。
设计原则
边界本身就是核心。
编排器才是真正的事实来源。
调度状态、重试和恢复都留在 Rust 中，编排权也持续保留在那里。
每个 issue 都有自己的执行边界。
工作区隔离让持久状态与恢复路径保持可理解。
UI 是可选的。
TUI 用于可观测性和监督。
人工审查属于模型本身。
这个模型围绕带有清晰审计轨迹的长周期监督式 agent 工作展开。