linxuhao/AItelier

AItelier

面向 AI agent 的结构化但动态的子代理工作流——你的 agent 将工作委托给确定性的、完全可审计的流水线，这些流水线可由它通过 MCP 生成、运行和编辑。

License
Python
Engine: SkillFlow-F59E0B)

AItelier 使多代理 AI 流水线变得确定且完全可审计——定义一条流水线（或让你的 agent 生成一条），运行它，并检查它为什么做了它所做的一切。整个界面通过 MCP 暴露，因此任何支持 MCP 的 agent 都可以将 AItelier 用作其工作流引擎：将批量工作委托给廉价、确定性的流水线，仅在检查点处做决策（参见从另一个 agent 使用 AItelier）。在这一切之下是一个开放引擎（SkillFlow，MIT，在 PyPI 上名为 skillflow-py）加上一条旗舰级软件交付流水线；更广泛的无代码工作流平台在路线图上。

持久化项目状态，与工作流执行分离

AItelier 还为长期目标、带修订的验收契约、依赖关系和证据提供了一个 State DAG。SkillFlow 继续负责工作流步骤、循环、重试和检查点；由驱动器选择一个就绪的目标和一条工作流。已完成的工作流产生的是一个候选成果，而不是经过验证的产品能力。

MCP/内部驱动器工具 state_graph_help、state_graph_read 和
state_graph_write 暴露与 /api/state 相同的类型化契约。状态数据读取需要写入者授权。现有的 DPE 流水线和任务/项目 UI 保持兼容；遗留任务仅在显式导入时才会被导入，且永远不会继承已验证状态。参见架构、用法、信任边界和推出
以及离线真实引擎演示。
经过身份验证的 send_director_message、list_director_messages、
acknowledge_director_message 和 resolve_director_message State 操作提供
带有持久投递事件的项目收件箱；REST 在 /api/state/director-messages/ 暴露相同的封闭 v2
契约。v2 生命周期区分显式收件箱的 transient 投递与 standing 指导，后者会保留在一个有界的、经脱敏的 PostCompact 恢复投影中，直到被解决。现有的 v1 行会以 transient 方式迁移，且不会丢失其消息、投递、事件或幂等性审计。
State Project 前端与迁移准备指南
涵盖项目 DAG 浏览、精确运行图版本、受保护的历史引用
以及已暂存的影子迁移演练。
项目优先仪表盘指南涵盖默认 State DAG 工作区、
独立的 Runs/Pipelines 导航、可读的节点徽章以及实际运行历史。
等待状态变化并接入另一个智能体

使用 state_graph_read(action="wait_for_state_change", arguments={"project_id":
"my-project", "after": 0, "timeout_seconds": 30}) 并持久化返回的
next_after 游标。匹配的持久事件会立即返回；未变化的状态会等待，而无需反复进行模型驱动的查询。工作流停止和暂停会被协调为 State 观察结果，并对遗漏的通知进行有界恢复。超时不会停止工作进程，完成也永远不会验证目标。

智能体可以加载 MCP 提示 state_graph_driver、资源
aitelier://state/driver-guide，或从 state_graph_help 加载 driver_guide。
每个 State 项目还有一个带修订的 permanent/temporary 驱动笔记：
get_driver_note、有界/脱敏的 search_driver_note_history、
driver_note_history，以及受 CAS 保护的
update_driver_note，让不同的主管可以并行管理项目，而无需共享笔记修订或事件游标。wait_for_state_change 保留其单项目兼容性默认值，并新增 filter_mode="any" 以及
note_after_revision，用于 OR 风格的交接等待。
有关外部证据、游标作用域、所有权和交接规则，请参阅智能体驱动指南。

2.0 发布检查清单将已实现功能与公开发布前仍需完成的发行检查区分开来。

在不使用工作流的情况下使用 State DAG

你自己的主管、子智能体、CI 或证明检查框架可以注册
外部尝试，提交有作用域的产物/报告和逐项标准证据，
并在不创建 SkillFlow Run 的情况下验证节点。工作流和外部
尝试共享相同的验收和失效规则。外部完成
仍然只是一个候选。

一个专用的、经过身份验证的无头 State HTTP/MCP 服务器通过
python -m api.state_only --db /absolute/private/state.sqlite 启动，并配置
AITELIER_STATE_TOKEN；它不会导入或启动 SkillFlow、调度器、
工作区管理器或模型注册表。该软件包的安装依赖尚未
拆分为单独的最小 wheel。请参阅集成/独立指南
以及真实的自有框架示例。

设计作者可以使用轻量级设计搜索与影响分析
来查找精确版本候选、记录直接冲突并检查受影响的
绑定。这些只读辅助工具复用 State 修订/基线；它们不会
引入求解器、向量数据库或自动验收。

为什么选择 AItelier
大多数“AI 智能体”工具是为演示而构建的，而非为了可信。那些为你构建软件或自动化工作流的工具是非确定性的黑箱：你无法复现一次运行，无法审计智能体为什么做了它所做的事，也无法在关键之处插入人工审批。这正是阻碍智能体被部署到任何严肃场景中的那堵墙——受监管行业、企业，以及任何“它通常能正常工作”还不够好的地方。

AItelier 建立在相反的前提之上——一条自主流水线应当在构造上就是可信的：

- 确定性执行规则——工作流图由引擎遍历，而非由 LLM 即兴发挥的控制流。它们的条件结果可能不同，重试路径可能包含环；它们不一定是 DAG。循环、门控、重试和恢复是引擎的职责。独立的项目状态依赖图则是无环的。
- 最小 LLM 暴露面（最小权限）——每个智能体只能看到它声明的上下文，并且 SkillFlow 引擎会为每个声明的输出生成一个受限的写入工具（并将读取限制在声明的上下文内）——因此智能体无法读写其契约之外的文件。具体到软件流水线中：研究员只能搜索网络；其他每个角色只能写入自己声明的输出（一份设计文档、一份计划、一份评审结论，或项目 README）——并且只有实现者的输出是代码。模型负责做出判断；框架及其生成的工具负责所有确定性的事——大脑归大脑，工具归工具。这也是廉价模型就足够的原因：小而聚焦、按角色限定范围的上下文。
- 完全可追溯——每次运行都保留一份仅追加、永不删除的审计追踪：每一步、每个提示、每个模型响应以及每次工具调用。“这次运行为什么那样做？”只需一次查询，而非取证式考古。
- 人在回路中——审批/拒绝检查点是各阶段之间的一等公民；你可以在任何时候评审并带着反馈把工作打回。
- 对抗式质量——每一步都由一个 Green（制造者）智能体产出，并在推进之前由一个 Red（检查者）智能体评审。
- 配置无关——一条流水线可以是任何东西。引擎没有任何部分被硬编码到某一种工作流；SkillFlow 甚至可以根据一段自然语言描述生成一条新流水线。

这处于什么位置。 经典工作流引擎是结构化的，但静态——由人编写图，改动它就意味着一次部署。自主智能体集群是动态的，但非结构化——即兴的控制流无法复现或审计。AItelier 刻意占据那个缺失的象限：结构化但动态。在运行期间，图是固定的并由引擎遍历——门控、重试和追踪都是机械式的。在运行之间，智能体可以根据描述生成一条新流水线、驱动它、读取哪里出了问题的追踪，并编辑它——全部通过 MCP 完成。你的智能体始终是大脑；AItelier 是它可以重新装备的工厂车间。
你可以构建什么

愿景（关于今天已构建的内容与计划中的内容，请参见项目状态）。

AItelier 旨在以三种方式使用——第一种是重心所在：

1. 为你的智能体提供一个工作流引擎（MCP）——✅ 今天即可使用。 将任何支持 MCP 的智能体指向 /mcp 端点，它就能获得整个界面作为原生工具：完整的 生成 → 运行 → 观察 → 修复 循环、检查点应答、追踪、模型路由，以及流水线导出/导入。你的智能体将大量工作委托给廉价模型上的确定性流水线，只在检查点处做决策（参见从另一个智能体使用 AItelier）。
2. 构建你自己的可审计工作流——只需描述它——✅ 今天即可使用。 流水线不限于软件。在聊天中描述一个工作流（或通过 MCP），AItelier 的接地生成器会将其转化为真正的 SkillFlow 流水线——配置任何缺失的工具、连接并门控图，并注册它以按名称运行（参见从描述生成工作流）。你仍然可以直接手写 YAML；无代码的可视化构建器和托管工作区在路线图上。
3. 独立运行旗舰软件流水线（DPE）——✅ 今天即可使用。 描述一个项目；它会端到端地进行研究、架构设计、规划、实现和验证，并带有人员检查点和完整追踪。（这就是下面的实际效果——也是引擎在最严苛工作负载下依然可靠的证明。）

为什么软件交付既是切入点也是拱心石。 我们以自主软件构建为先导，因为这是证明引擎可行的最严苛考验——也因为AI 工作流就是软件（流水线是图加工具加模板）。构建软件的同一个确定性工厂，将让你能够信任你在 AItelier 上构建的工作流——构建一个新的可审计工作流本身就是一项软件工程任务。一个可信的软件流水线构建出可信的工作流。

开源。 SkillFlow 是引擎，可嵌入任何智能体系统；AItelier 是围绕它的宿主应用。两者均为 MIT 许可（参见许可证）；托管的多租户平台在路线图上。

项目状态

诚实、当前的状态——这样这里的内容就不会显得比实际完成度更高。

图例： ✅ 今天可用（已构建并测试）  ·  🚧 路线图（已设计，未构建）  ·  🔭 长期愿景

| 能力 | 状态 |
| --- | --- |
| 旗舰 DPE 软件流水线——研究 → 架构设计 → 规划 → 实现 → 验证 | ✅ 今天可用 |
| MCP 端点 + DeepSeek Harness 插件——从任何支持 MCP 的智能体驱动 AItelier：将流水线作为原生工具进行列出/编辑/运行/导出/导入 | ✅ 今天可用 |
| 绿队/红队对抗式审查 · 人工批准/带反馈驳回检查点 · 自主目标循环 | ✅ 现已可用 |
| 仅追加追踪 + 追踪 API · Git 事件溯源 · 丰富的 CLI/TUI | ✅ 现已可用 |
| 运行于 SkillFlow 引擎之上（持久化工作流图执行、工具、检查点、追踪） | ✅ 现已可用 |
| 持久化 状态 DAG —— 带版本的目标、依赖、尝试、证据、验收以及驱动/API 访问 | ✅ 已实现并测试；私有项目 DAG 查看器，无自动旧版迁移 |
| 从自然语言描述生成流水线 —— 有依据的生成器会配置缺失的工具、连接并门控图、将其注册为可按名称运行 | ✅ 现已可用 |
| 最终验证器运行生成的应用程序（运行时冒烟测试） | 🚧 路线图 —— 目前它静态审查代码，可能会漏掉运行时缺陷 |
| 无代码可视化工作流构建器 · 托管多租户 SaaS · 协作与合规工具 | 🚧 路线图 |
| 在同一引擎上向软件交付之外的横向扩展 | 🔭 愿景 |

公司现状： 引擎和旗舰流水线已构建并经过测试；目前尚无用户、收入或托管平台。 这是一个可用的基础，而非成品。

实际效果

立即浏览在线部署：aitelier.linxuhao.app（公开只读访问）。打开任意运行，观看流水线图，其中当前步骤高亮显示，其追踪在旁边实时流式输出 —— 例如，一个真实的游戏功能运行。读取对任何人开放；写入需要 Cloudflare Access 允许列表（这种拆分如何运作）。

使用旗舰 DPE 流水线的一次典型运行：

1. 描述你想要什么。 告诉管家你的目标。它会自动选择两条路径之一：
- 路径 A —— 流水线卸载（快速）：对于现有项目上的小型缺陷修复或功能（约 5 个文件），直接卸载到 subagent/fix_tests/investigate 流水线 —— 无需需求对话。
- 路径 B —— DPE（安全默认）：对于新项目和非平凡变更，询问范围界定问题，起草项目简报，并且在你批准后，启动完整的研究 → 架构 → 计划 → 构建流水线。
2. 观看它工作，并带有检查点。 研究 → 架构 → PM → 每任务计划/实现/审查 → 最终验证。它在审查检查点暂停，以便你可以批准或带反馈驳回（例如 “设计缺少输入验证”），并观看代理进行修订。
3. 检查追踪。 每个提示、响应和工具调用都在仅追加审计日志中 —— 事后对任何步骤回答“它为什么那样做？”。
4. 运行结果。 生成的项目（代码 + 测试 + README）落在你的工作区中，随时可运行。

录制演示：电子商务运行
旗舰级 DPE 流水线端到端地规划、构建并审查一个真实的电商应用——一个客户店面以及一个管理面板：66 个流水线步骤，0 次失败，完全运行在廉价的非前沿模型上（DeepSeek——循环中没有 GPT/Claude/Gemini）。另外，当后来反馈回一个 bug 报告时，AItelier 诊断并修复了自己的代码（见下文）。

生成的应用——客户店面与管理面板（源自单一目标，纯 Python 标准库）

📂 浏览完整生成的源代码：linxuhao/aitelier-e-commerce-store-demo ——每个文件都由流水线生成（提交历史就是构建日志）；只有它的 README 是手写的。

| 客户店面 | 管理面板 |
| --- | --- |
| Client | Admin |

浏览 → 购物车 → 结账 → 订单确认，以及管理员登录 → 仪表盘 → 添加 / 编辑 / 删除。

每个决策都可审计——trace API

Trace API

每次运行有 1000+ 条持久记录——每个提示、模型响应、工具调用以及 Green/Red 审查裁决——可按步骤或类别查询。

本次运行展示了什么
- 目标循环自主触发（最终验证器 → 回到规划 → 在下一轮收敛）——并非脚本编排。
- 带着一个 bug 报告重新指向现有代码库后，AItelier 诊断出根本原因并自行编写了修复。
- 智能在于编排，而非模型账单——整条流水线运行在 DeepSeek v4-flash / v4-pro 上。

诚实的提醒：上面的购物车 bug 之所以能躲过流水线的验证器，是因为它静态地审查代码，尚未运行应用——参见项目状态和路线图。发现它需要手动运行应用；随后 AItelier 修复了它。

安装

需要 Python 3.12+（用 python3 --version 检查；在 macOS 上系统自带的 python3 通常更旧——请使用 3.12 的 venv）。

python3.12 -m venv .venv && source .venv/bin/activate
Install AItelier (the skillflow-py framework is pulled from PyPI automatically)
pip install -e .

快速开始

cp llm_providers.example.json llm_providers.json   # providers: URL + key NAME
cp model_routes.example.json  model_routes.json    # models: which endpoints serve each
cp .env.example .env                               # endpoints and options; keys prefer ~/.aitelier-secrets (see Docker section)

Which key files do YOUR tables need? The key name is the provider table's, not this page's
(imports core., so run it inside the venv the Install step created):
python -c "from core.external_deps import required_llm_keys, failover_llm_keys; \
print('required:', required_llm_keys()); print('failover:', failover_llm_keys())"

mkdir -p ~/.aitelier-secrets && chmod 700 ~/.aitelier-secrets
printf '%s' "" > ~/.aitelier-secrets/ && chmod 600 ~/.aitelier-secrets/

在自定义之前，有三件事值得了解——完整的路由说明（provider/endpoint/model 层级、故障转移策略、每个模型必须具备什么）在 docs/models-and-providers.md 中：

- 模型名称就是契约：agent_configs/.yaml 引用 flash / pro / glm / smart / vision；每个名称背后是什么由你选择。完全跳过 cp，示例会作为回退，因此全新克隆的仓库仍可运行。
- 密钥是秘密文件，而非环境变量——因此流水线运行的测试/构建子进程无法继承它们。存在哪些文件是从你的 provider 表推导出来的（就是上面的探测）；使用随附的示例时，它会输出 ARK_API_KEY 为必需，DeepSeek 和 Qwen 作为故障转移。
- 缺少密钥会大声报错，并指明 provider、密钥、要创建的文件，以及将其发送到那里的模型。

后端运行在 Docker 中——宿主机进程会让流水线的 git 提交携带你自己的 ~/.gitconfig 身份，因此 CLI 绝不会静默回退到某个身份。aitelier 会为你启动容器（并创建它挂载的秘密文件）。唯一的逃生通道是显式的：aitelier server --no-docker 在进程内运行 uvicorn，用于在容器外调试，或用于自带 git 身份的部署。

aitelier                          # 交互式 CLI 仪表盘
aitelier "build me a todo app"    # 一次性流水线
aitelier server                   # 后端容器（启动/复用）

使用 Docker 运行（+ Cloudflare）

后端和 Web UI 也以容器形式提供。如果 Docker 正在运行，CLI 会自动启动它（如果已经启动则复用），你也可以直接管理它：

docker compose up -d              # 多阶段构建（Node.js → Svelte 打包 + Python 运行时）；在 :4444 上提供 API + Web UI
docker compose logs -f

API 密钥是 ~/.aitelier-secrets/ 中的文件，每个密钥名称一个——整个
目录以只读方式挂载并按名称解析，因此无论你的
provider 表声明什么密钥名称都能正常工作；添加 provider 时
docker-compose.yml 中无需编辑任何内容。缺少文件只意味着“我不使用这个
provider”（例外：没有认证的自托管端点仍然需要一个包含任意内容的
占位文件——OpenAI 客户端在完全没有密钥时拒绝启动）。

在首次 docker compose up -d 之前，以你的
用户身份创建这两个宿主机目录——如果绑定源目录不存在，Docker 守护进程会将其创建为
root:root，而容器（以你的 uid 运行）会因
sqlite3.OperationalError: unable to open database file 而崩溃循环，且完全不提及
权限问题：

mkdir -p ~/.AItelier
mkdir -p ~/.aitelier-secrets && chmod 700 ~/.aitelier-secrets
printf '%s' "" > ~/.aitelier-secrets/ && chmod 600 ~/.aitelier-secrets/
来自你自己的提供商表——快速开始中的探测会打印该列表。

.env 中的键同样有效（env_file: 会将它们传递进去，解析器也会回退到环境变量）——但这样一来，它们就位于容器的环境中，任何继承该环境的子进程都能看到它们。文件是推荐的方式；这正是它们存在的全部理由。

docker compose up -d 还会启动 aitelier-godot——游戏流水线的编译/试玩 sidecar。未使用时无妨；docker compose up -d aitelier 只启动主服务。

通过现有的 cloudflared 连接器发布只需一行。网络就位于 docker-compose.yml 本身中，并且是按名称选择的，没有 external:，也没有 -f 覆盖层——以前是有的，而在重建时忘记它会切断公共路径，同时所有容器却保持健康。

echo 'AITELIER_EDGE_NETWORK=cloudflare_edge' >> .env   # docker network ls → 你的连接器的

对照 docker network ls 以及你的连接器实际所在的网络来确认该名称。一个不匹配任何网络的名称会被创建，而不是被拒绝：容器会健康启动，127.0.0.1:4444 返回 200，而隧道却是暗的，没有任何错误日志。不设置该变量，AItelier 就保持在回环地址上。

除此之外，干净检出后启动时没有任何预先存在的 Docker 资源。每一项需要此仓库之外某些东西的能力——LLM 密钥、网络搜索、媒体生成、Godot 关卡——都是可选的，会以一条指明所需配置的消息拒绝，并列在 docs/external-dependencies.md 中。关于从空机器到完成流水线的完整路径——每一步、每一步可能出什么问题，以及什么能覆盖它——请参见 docs/install-route.md。

如果一次运行看起来卡住了，请阅读调度器 tick 日志，而不是容器日志。调度器每个 tick 推进一个项目，因此无法推进的项目会阻塞其他项目——而 tick 日志正是它说明原因的地方：

grep 'outcome=claim_failed' ~/.AItelier/logs/scheduler_ticks.log
project=my-project outcome=claim_failed run=2f6c30c4
error=Required context source resolved to no content: finalize.

它会轮转（5MB × 3）并位于挂载的卷上，因此能在容器重建后保留。每个 tick 一行；结果为 idle、locked、run_start_failed、active_claim、terminal、claim_failed、no_claim、executed。

状态位于宿主机 ~/.AItelier（绑定挂载）。端口仅在回环地址上发布；通过 Cloudflare 隧道将其公开暴露。在前面加上 Cloudflare Access 后，读取对任何已登录用户开放，写入则限制在允许列表内——在 .env 中设置 AITELIER_CF_TEAM_DOMAIN、AITELIER_CF_AUD 和 AITELIER_WRITERS（均在 .env.example 中有文档说明）。CLI 使用 AITELIER_ADMIN_TOKEN 向自己的容器进行身份验证。

从另一个 agent 使用 AItelier（MCP）
这是使用 AItelier 的主要方式。 后端将其整个流水线能力面暴露为一个 MCP 端点（/mcp，可流式 HTTP）——因此任何支持 MCP 的智能体都可以把 AItelier 当作一个结构化但动态的子智能体来使用：与其在自己的上下文中临时拼凑一个冗长的多步骤任务（不可复现、不可审计，且按前沿模型的价格计费），智能体可以将其委托给一个确定性的流水线，并拿回一份可查询的持久化追踪记录。该能力面包含 42 个工具，覆盖四种产物类型（流水线图、智能体角色、提示词模板、自定义工具），每种都提供 list / get / edit 操作，此外还有：

- run_pipeline + wait_for_run + answer_checkpoint —— 启动一次运行（立即返回；运行时间较长，且可能暂停等待批准），并阻塞直到它在某个检查点、完成或失败处稳定下来——基于推送，无需轮询。检查点在这一框架中始终是一等公民：调用方智能体可以自行批准或带反馈拒绝，也可以将决策上报给其人类。
- 完整的 generate → drive → observe → fix 循环 —— generate_pipeline 写入一条新流水线（生成的工作原理），run_pipeline + wait_for_run + answer_checkpoint 驱动它，get_run_summary 和 trace_ 工具说明哪里出了问题，edit_ 工具则修复它。AItelier 的调度器运行流水线；外部智能体只在检查点处以及运行之间做决策。
- 模型路由表 —— get_available_models 说明此部署提供哪些模型，以及它们背后的每个端点是否真的能应答；add_provider / map_model / unmap_model / delete_ 编辑它们。你使用哪些供应商属于部署配置，因此这就是智能体配置一台并非由它自己搭建的机器的方式。
- export_pipeline / import_pipeline —— 将生成的流水线作为一个自包含的 JSON 包在机器之间迁移：包含其图、其角色及其提示词，以及它所需的任何自定义工具。导入会在写入前验证一切，安全地重命名，并拒绝静默覆盖一个同名但内容不同的工具。

授权是按工具而非按路由进行的：普通的工作流读取工具是开放的；私有 State 读取和写入工具需要与 Web UI 相同的授权（Cloudflare Access 允许列表，或在非隧道模式下使用 AITELIER_ADMIN_TOKEN）。没有凭据时，你会得到一个合法的只读安装——写入工具会应答 denied: … 且不做任何更改。

对于 DeepSeek Harness（dsh），integrations/dsh/ 中有一个现成的插件包——一条命令即可将其安装到某个配置文件中，并将这些工具注册为 mcp__aitelier__：

dsh plugin --profile headless add /AItelier/integrations/dsh
echo 'AITELIER_MCP_URL=http://127.0.0.1:4444/mcp' >> ~/.dsh/.env   # where your AItelier runs
任何其他 MCP 主机直接配置相同的端点 URL（可流式 HTTP 传输）。它需要一个正在运行的后端——参见上文的安装，或运行 docker compose up -d。

根据描述生成工作流

不想手写流水线？用描述来生成它。 ✅ 现在就能用。 在管家的编码模式下——或从任何外部代理通过 MCP——generate_pipeline 工具可将一段自然语言描述的工作流转换为真实、可运行的 SkillFlow 流水线——它基于实时工具注册表，按需自动配置所需的任何工具，并在发布前经过门禁校验。无需手写 YAML，无需重启服务器。

1. 描述它。 “做一个流水线，先研究一个主题，起草一份摘要，然后对它进行事实核查。” 基于实际环境的 pipeline_forge 生成器会调查真实的工具注册表 → 设计图 → 构建并注册任何缺失的工具 → 生成配置 → 通过由三部分组成的门禁（lint + 注册表检查 + 试运行冒烟测试）→ 在审核检查点暂停。
2. 它会自动注册。 批准后，该图会以一个带命名空间的名字落地，例如 gen_research_draft_factcheck（gen_ 前缀永远不会与内置配置冲突）。
3. 按名称运行它。 “在‘CRISPR 基因编辑’上运行它。” → 管家会启动它，它会像任何其他运行一样出现在仪表盘——以及追踪记录——中。
4. 原地迭代。 “添加一个引用步骤，然后再次运行它。” → 在同一名称下重新描述它，它就会原地更新；下一次运行将使用新版本。

每一次生成的运行都会获得与旗舰流水线相同的确定性执行、人工检查点和仅追加的追踪记录。生成的流水线作为被 git 忽略的用户数据存储在 ~/.AItelier/configs/ 下，因此它们能在重启后保留，但永远不会进入仓库。这就是无代码工作流平台可用的核心——其上的可视化构建器仍待推出。

配置

要更改流水线使用的模型或代理，请直接编辑配置文件：

- llm_providers.json + model_routes.json —— 提供方、端点，以及哪些端点为每个模型名称提供服务；完整说明见 docs/models-and-providers.md。
- agent_configs/ —— 每个角色的模型、模板、工具和思考设置。每个代理的模型都只是这里的一个 YAML 字段：DPE 流水线角色位于 dpe_default.yaml，而聊天管家 / 元代理位于 meta_conversation.yaml（meta_agent.model）——因此对话式前端可以像流水线角色一样进行配置。
- templates/ —— 每个步骤使用的 LLM 提示模板
- AITELIER_HOST_AGENT_MODEL（环境变量，默认 ark/deepseek-v4-flash）——用于 skillflow 主机委托代理的模型。生成的流水线将其代理以 model:"host" 形式发布，并内嵌提示词；AItelier 将这一个 token 映射到这一个模型，因此你无需为它们声明按角色区分的配置（参见从描述生成工作流）。

工作原理

AItelier 将其工作流定义为一个由无状态代理步骤组成的 SkillFlow 图。SkillFlow 引擎负责遍历、工具执行、检查点和持久化追踪；AItelier 提供代理、模板、工具和 UI。

代理从不在内存中保存状态。每一步从前序步骤的输出中获取其上下文，将其结果写入每步的暂存目录，由引擎验证后再提升，而每一次提升的变更都会提交到 Git（事件溯源）——因此任何运行都可以在事后重放或检查。调度器一次一步地驱动循环：advance → claim → execute → confirm。默认的 DPE 流水线将此应用于软件交付，但由于流水线只是配置，同一个引擎可以运行任何可审计的多代理工作流。

As a codebase, AItelier is a host application on top of the SkillFlow framework:

- Configs (configs/, agent_configs/) — pipeline graph and LLM agent definitions
- Templates (templates/) — per-step LLM system prompts
- Tools (aitelier/tools/) — AItelier custom tools + SkillFlow native tools
- Core (core/) — agents, scheduler, AI router, DB, workspace
- API (api/, web_api/) — the CLI backend, plus an early multi-tenant Web backend. Includes admin endpoints (/api/admin/) for user tracking with per-user delete, writer-only access via Cloudflare Access, and the MCP endpoint (api/mcp_router.py, served at /mcp) that exposes the pipeline surface to external agents.
- Web (web/) — Svelte 5 + Vite SPA, compiled to web/dist/ and served by FastAPI
- CLI (cli/) — Rich TUI dashboard

Roadmap

Building on the foundation that works today (Project status above), in priority order.

🚧 Next (designed, not yet built)
- Runtime-verifying delivery — the final verifier reasons about code statically today; next it boots the generated app and smoke-tests it, so the goal-loop triggers on real runtime failures, not just static review.
- The managed platform — multi-tenant workspaces, a no-code visual workflow builder, shareable/managed runs, and the audit & compliance tooling teams need to deploy agents in production.

🔭 Longer-term (the bet, not a commitment)
- The open format as a standard — if SkillFlow's YAML becomes a common way to define agentic workflows, every config in the ecosystem runs natively here.
- Audit-first & EU-resident — position the immutable, never-deleted trace as the compliance-grade record that environments like the EU AI Act's traceability requirements demand.

Tests

pytest tests/unit/ -v          # ~700 unit tests
pytest tests/integration/ -v   # ~245 integration tests
pytest tests/ -v               # full suite (~945 tests)

Web Frontend

A Svelte 5 + Vite SPA (web/src/); the compiled bundle (web/dist/) is served directly by the FastAPI backend. It ships in 8 languages (en, zh-CN, zh-TW, ja, ko, fr, de, es) with live language switching.

cd web
npm install && npm run build    # compile to web/dist/
npm test                        # vitest (stores, lib, views)
npm run lint                    # ESLint + eslint-plugin-svelte
node audit-i18n.mjs             # verify every t() key exists in all 8 languages

The DPE pipeline's test step gates node projects automatically: it finds package.json (root or one level deep, e.g. web/) and runs npm ci + npm run build + npm test, folding failures into the goal-loop.

License

AItelier is open source under the MIT license, as is the pipeline engine it runs on, SkillFlow.

Output destinations and this engine build

Code agents use output.target: code to write directly to their run worktree;
plans and reports retain output.target: artifact and artifact publication.
See migration and restart guide. This checkout exact-pins the reviewed public engine release; install with
pip install -e ., or rebuild the Docker image.