问题
用 Copilot 等工具做多 agent 协作时，编排靠临时拼凑，缺乏可靠性与可观测性；开发者把 AI 工作流写成“巨型 prompt 和系统消息”，难以拆成小而可度量的决策，失败时无法定位是哪一步出错。两位信号来源的痛点等级都是 3，属于真实但中等强度的工程摩擦。
目标用户
正在构建 AI agent 和自动化工作流的开发者，尤其是用 Copilot 生态做多步工程任务的人。市场处于早期：信号显示这是正在形成的新范式（从 prompt 转向代码定义工作流），当前痛点强度中等，付费证据不足。
解决方案
- 用代码（而非巨型 prompt）定义编排：顺序、并行、条件分支的步骤图
- 自动步骤与 agent 判断步骤混合编排，agent 只负责需要判断的节点
- 结构化状态：每一步的输入输出、耗时、失败原因都是可查询的数据
- Trace 与回放：一条工作流跑完后可逐步回看，定位失败步骤
- AI 的角色：执行判断型节点（如代码审查、异常分类），框架本身保证控制流确定、可观测
为什么是现在
两条信号共同指向范式切换点：GitHub 在 Copilot 扩展中推出动态工作流，允许“用代码定义编排来获得多 agent 工作所需的可靠性与可观测性”；同时 Jev 等在推 System One 模型，主张用结构化状态和编程原语取代巨型 prompt。工具能力刚到位，开发者的迁移需求正在出现。
MVP 范围
第一版：做——一个轻量编排库，支持用代码定义顺序/并行步骤、把判断型步骤交给 agent、每步输出结构化状态和 trace 视图。不做——不支持任意模型托管、不做团队协作/权限、不做生产级高可用和自托管集群。
风险
平台依赖：GitHub Copilot 已把动态工作流做进自家扩展，Jev 在推 System One 编程原语，独立工具随时可能被平台原生能力覆盖；技术风险：多 agent 的可靠性问题本身未被完全解决，工具的抽象可能很快过时；冷启动风险：这是开发者工具红海，差异化窗口取决于能否在可观测性上明显超越内置方案。
已有产品
| 产品 | 定位 | 价格 |
|---|---|---|
| Jev | System One 模型，用结构化状态和编程原语替代巨型 prompt，主打把 AI 工作流拆成小而可度量的决策。 | — |
| GitHub Copilot SDK | 提供代码内定义编排的动态工作流，把自动步骤与 agent 判断步骤组合，主打可靠性与可观测性。 | — |
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
GitHub Changelog10月1日新能力隐含付费意愿
“These let you define an orchestration in code to get the reliability and observability that complex, multi-agent work demands.”
Multi-agent orchestration for complex tasks lacks reliability and observability when delegated ad hoc; dynamic workflows now let users define orchestration in code combining automated steps with agents.原文
Latent Space9月21日痛点
“Why developers should decompose AI workflows into small, measurable decisions”
Developers struggle to decompose AI workflows into small, measurable decisions because current paradigms rely on giant prompts and system messages.原文