Orc（暂定名）- 可审计且声明式的 AI 工作流

**我正在构建一个用于 LLM 工作流的小型“编排即代码”仓库。这个概念合理吗？** 我正在构建一个用于 LLM 工作流的小型“编排即代码”仓库。这个概念合理吗？我一直在做一个名为 ORC 的早期项目，全称是 Orchestration as Code。我目前阶段主要是想衡量这个概念是否有趣/对其他人有用，特别是那些运行本地模型、Ollama、llama.cpp、LM Studio、MCP 工具或混合本地/云端工作流的人。 基本想法是：ORC 让你可以在 .orc 文件中以声明式描述工作流，而不是将 LLM 工作流构建为 Python 编排大杂烩，或在可视化工具中将它们连接起来。 大致来说：类似 Terraform 的工作流定义，但用于 LLM 代理和工具使用。 工作流可以定义以下内容： - 代理 - 模型/提供商 - 工具 - 模式 - 输入 - 有序执行步骤 - 验证规则 - 输出产物 目标不是构建一个神奇的自主代理框架。目标更平淡一些：让 LLM 工作流更易于阅读、版本控制、审查、验证和重复运行。 我目标的大致示例如下：`agent researcher:` `provider: ollama` `model: gpt-oss:20b` `schema Report:` `type: json` `path: "report.schema.json"` `workflow dockerReport:` `input:` `docker_status: string` `step analyse:` `agent: researcher` `input: docker_status` `produces: Report` 运行时执行步骤，根据模式验证输出，捕获产物，并为你提供运行期间发生情况的更清晰轨迹。 我一直在实验的一些事情： - 本地 Ollama 代理调用 MCP 工具 - 结构化报告生成 - 使用 JSON Schema 验证模型输出 - Docker/容器状态总结 - 简单的多步研究/编辑工作流 - 通过 MCP 工具发布/发帖 - 根据步骤混合使用本地和云端模型 这还处于早期阶段，仓库还称不上完善或生产就绪。我主要想了解这个方向是否值得进一步完善。 我真正希望得到反馈的是： - “编排即代码”的概念是否引起共鸣？ - LLM 工作流的声明式 DSL 对你有用吗？ - 这是解决了实际痛点，还是只是一个漂亮的抽象？ - 在认真对待之前，你希望看到仓库里有什么？ - 是否有现有项目已经很好地覆盖了这一点？你更希望这是一个独立运行时、Python 库、CLI 工具还是其他什么？ 我特别感兴趣的是那些已经在拼接本地模型、工具、脚本和结构化输出的人的反馈。 在这个阶段，我不是在推销任何东西。我想弄清楚这个概念和仓库是否值得进一步开发，或者这只是我自己工作流中一个酷但小众的工具。 我快要让仓库公开了，如果有任何价值，允许人们使用它！