# Autofactory：基于Temporal的AI驱动代码自动化工厂

> Autofactory是一个受AI黑灯工厂模式启发的全自动代码工作流系统，使用Temporal进行持久化工作流编排，支持OpenCode、Codex和Claude等多种AI后端，实现从Issue分类到PR自动合并的完整DevOps自动化。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-05-08T16:45:02.000Z
- 最近活动: 2026-05-08T16:54:14.776Z
- 热度: 143.8
- 关键词: AI自动化, Temporal, DevOps, 代码生成, GitHub自动化, CI/CD, OpenCode, Codex, Claude
- 页面链接: https://www.zingnex.cn/forum/thread/autofactory-temporalai
- Canonical: https://www.zingnex.cn/forum/thread/autofactory-temporalai
- Markdown 来源: ingested_event

---

# Autofactory：基于Temporal的AI驱动代码自动化工厂

## 项目背景与核心理念

在软件开发领域，"黑灯工厂"(Dark Factory)概念指的是完全自动化、无需人工干预的生产设施。将这一理念引入代码开发，就是**Autofactory**项目的核心愿景。这是一个受AI黑灯工厂模式启发的全自动代码工作流系统，旨在实现从Issue分类、代码实现到PR验证和合并的端到端自动化。

项目的技术选型体现了对可靠性和可扩展性的深思熟虑。它使用**Temporal**作为持久化工作流编排引擎，确保即使在系统故障时工作流也能可靠恢复。AI实现层则支持多种选择：**OpenCode**、**OpenAI Codex**和**Claude Code**，让用户可以根据需求和成本考量灵活选择后端。

## 架构设计：编排器与子代理模式

### 分层架构

Autofactory采用了经典的主从代理模式，将复杂任务分解为可管理的子任务：

1. **编排器(Orchestrator)**：负责任务分解、协调和整体进度管理
2. **子代理(Subagents)**：执行具体的实现、审查和验证任务

这种架构遵循了"Spec -> Plan -> Implementation <-> Reviews"的工作流：首先理解需求规格，然后制定执行计划，接着进入实现与审查的迭代循环，直到代码质量达标。

### Temporal持久化

Temporal是一个开源的工作流编排平台，提供了强大的持久化能力。在Autofactory中，Temporal确保：
- 工作流状态在系统故障后可恢复
- 长时间运行的任务不会丢失进度
- 并发工作流可以安全地共享资源
- 任务队列可以水平扩展以支持高吞吐

### 多AI后端支持

项目设计时就考虑了AI后端的可插拔性。目前支持：

- **OpenCode**：默认后端，npm install -g opencode-ai
- **Codex**：OpenAI的官方CLI，npm install -g @openai/codex
- **Claude Code**：Anthropic的官方CLI，npm install -g @anthropic-ai/claude-code

这种设计让用户可以根据任务复杂度、成本预算和性能要求进行选择。例如，对于简单的代码补全可能选择轻量级后端，而对于复杂的架构重构可能选择能力更强的Claude Code。

## 核心工作流详解

Autofactory支持两种主要的Issue处理工作流，覆盖了从人工触发到全自动运行的完整场景。

### 工作流1：@factory触发式PR创建

这是半自动化的工作流，保留了人工审查环节：

1. 用户在Issue中@factory提及，触发工作流
2. 系统分析Issue内容，理解需求
3. AI代理制定实现计划
4. 子代理执行代码实现
5. 创建Pull Request
6. 等待人工审查和合并

这种模式的优点是保留了人类在关键决策点的控制权，适合对代码质量要求较高或涉及敏感变更的场景。

### 工作流2：全自动Issue到合并流水线

这是真正的"黑灯工厂"模式，完全无需人工干预：

1. 系统自动对Issue进行分类和优先级排序
2. AI分析Issue并制定实现策略
3. 编排器协调子代理执行实现
4. 自动创建Pull Request
5. 系统运行自动化测试验证PR
6. 如发现问题，AI自动修复
7. 测试通过后自动合并到主分支

这一工作流展示了AI驱动自动化的终极愿景：从需求到部署的完全自主执行。当然，这种模式需要完善的测试覆盖和风险控制机制作为保障。

## 多平台支持：GitHub与GitLab

Autofactory设计时就考虑了多平台支持，目前兼容GitHub和GitLab两大主流代码托管平台。

### 平台配置

| 平台 | 主机配置 | 认证方式 |
|------|----------|----------|
| GitHub | github.com (可通过factory.github.host配置) | GitHub PAT (GITHUB_TOKEN环境变量) |
| GitLab | 通过factory.gitlab.host配置 (如git.etnetera.cz) | GitLab PAT (GITLAB_TOKEN环境变量) |

两个平台都支持完整的分类->实现->验证->修复->合并流水线，用户可以在不同平台间无缝切换。

## 部署与运维

### 系统要求

运行Autofactory需要以下前置条件：
- Node.js >= 20
- pnpm >= 9
- Docker (用于Temporal基础设施)
- 对应AI后端的CLI工具

### 一键安装

项目提供了`install.sh`脚本，可以一键完成依赖安装、构建和.env文件脚手架生成。使用`--link`参数还可以将`autofactory`命令暴露为全局可用。

### 启动流程

1. 编辑.env文件，设置GITHUB_TOKEN/GITLAB_TOKEN和OPENAI_API_KEY
2. 运行`./start.sh`启动所有服务（Temporal容器 + API服务器 + Temporal工作器）
3. 使用`pnpm autofactory run --repo owner/repo-name`触发工作流

### 工作器管理

API服务器会在启动时自动派生一个工作器进程，并在崩溃时自动重启。如果需要更高的吞吐量，可以通过`./worker.sh`启动额外的并行工作器。所有工作器共享同一个Temporal任务队列，由Temporal自动分配工作负载。

### 状态持久化

Autofactory在磁盘上维护状态，存储位置为`~/.autofactory/`：
- `server.log / server.pid`：API服务器的日志和进程ID
- `worker.log / worker.pid`：额外工作器的日志和进程ID
- `autocode.log`：Autocode子进程的生命周期审计日志
- `workspaces/`：临时克隆目录（工作流结束后清理）
- `costs/`：LLM token成本追踪

## REST API与自动化集成

Autofactory提供了REST API，方便与其他系统集成。

### 核心端点

- `POST /workflows/issues-processing`：启动Issue处理工作流
- `GET /workflows/:workflowId`：查询工作流状态
- `GET /health`：健康检查
- `GET /docs`：OpenAPI文档

### 工作流状态查询

状态查询响应包含丰富的信息：
```json
{
  "workflowId": "...",
  "status": "RUNNING|COMPLETED|FAILED",
  "taskQueue": "autofactory-owner-repo",
  "workersPolling": 1,
  "result": {...}
}
```

`workersPolling`字段特别有用，如果为0表示没有工作器在轮询队列，工作流将处于挂起状态直到有工作器可用。

### 定时任务配置

通过cron可以配置定期自动运行。例如，每天8:00、10:00、12:00、14:00、16:00、18:00自动处理指定仓库的Issue：

```
0 8,10,12,14,16,18 * * * cd <path-to-autofactory-repo> && <path-to-pnpm> -s autofactory run --repo github:<owner>/<repo> >> ~/.autofactory/workflow.log 2>&1
```

## 安全与权限管理

### 令牌管理

Autofactory需要访问代码仓库和AI服务，因此需要妥善管理以下令牌：
- GITHUB_TOKEN：GitHub个人访问令牌
- GITLAB_TOKEN：GitLab个人访问令牌
- OPENAI_API_KEY：OpenAI API密钥（用于分类-实现-PR创建工作流）

建议将.env文件设置为仅所有者可读（chmod 600 .env），并确保其已被git忽略。

### 反向代理配置

API服务器默认监听3737端口。出于安全考虑，建议不直接暴露该端口，而是通过nginx等反向代理进行访问控制。

## 实际应用场景

### 开源项目维护

对于拥有大量Issue的开源项目，Autofactory可以自动分类新提交的Issue，识别重复问题，并对标记为"good first issue"的简单任务自动生成修复PR。

### 内部工具开发

在企业内部，Autofactory可以处理内部工具的小功能请求和bug修复，让开发团队将精力集中在核心产品的架构设计和复杂功能上。

### 文档更新

当API发生变化时，Autofactory可以自动检测文档中的过时内容，并生成更新PR，确保文档与代码保持同步。

### 依赖更新

结合依赖扫描工具，Autofactory可以自动创建依赖更新PR，运行测试验证兼容性，并在测试通过后自动合并。

## 成本考量

Autofactory的AI后端调用会产生API费用。项目内置了成本追踪功能，在`~/.autofactory/costs/`目录下记录LLM token的使用情况。用户可以根据预算设置工作流触发条件，例如只对特定标签的Issue启用自动处理。

## 总结

Autofactory代表了AI驱动软件开发自动化的前沿探索。通过结合Temporal的可靠性、多AI后端的灵活性和精心设计的编排架构，它展示了"AI黑灯工厂"在代码开发领域的可行性。

项目目前处于积极开发阶段，适合希望探索AI自动化潜力的开发者和团队。随着AI能力的提升和成本的降低，类似Autofactory的工具有望成为软件开发的标配，将人类开发者从重复性工作中解放出来，专注于更具创造性的架构设计和问题解决。