路线图
LightFlow 现在是 backend foundation。下一步不应该先追求大而全，而应该沿着最小可验证路径补能力。
近期优先级
- Workflow reference validation
检查 step id 重复、无效 target、request template 与 API format 不匹配、缺失 model alias、缺失 node/composition。
- Schema validation
让 input_schema 和 output_schema 真正参与 preview/create。至少要能检查 required fields 和 basic JSON shape。
- Step dependency model
从线性 steps 扩展到 DAG，明确 step output 如何被后续 step 引用。
- Request template registry
把 openai_chat_input 扩展成一组受控模板，例如 OpenAI responses、Anthropic messages、tool invocation、thread append。
- HTTP adapter
基于 ApiService 加一个薄 HTTP layer，不在 handler 里重复 asset parsing 或 run store 逻辑。
中期能力
- streaming events
- artifact indexing
- policy-aware preview
- route explanation
- run cancellation
- retry and timeout model
- composition expansion
- built-in reference workflows
- integration tests against fake CortexFS
设计风险
Workflow DSL 过早变复杂：
如果 DSL 允许任意 Rust 逻辑，静态 preview 会变弱，agent review 难度会上升。
LightFlow 复制 CortexFS：
如果 LightFlow 自己维护 provider/tool/policy/audit，系统会变成两套 truth。
Run state 混入仓库：
如果把真实 run output 提交到 lightflow/，项目资产和本地状态会混在一起。
API 绑定框架：
如果早期把业务逻辑写进 Axum/Actix handler，CLI 和测试会被迫复制行为。
完成标准
一个功能应该满足：
- CLI 可触发。
- API service 可复用。
- run manifest 可解释。
- preview 能提前暴露错误。
- 文档说明它属于 LightFlow 还是 CortexFS。
Last updated on