openase
AI Agent 工单驱动开发平台，Ticket 自动认领、Workflow 驱动执行、看板全程追踪，All-in-one Go 单二进制交付
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
AI Agent 工单驱动开发平台，Ticket 自动认领、Workflow 驱动执行、看板全程追踪，All-in-one Go 单二进制交付
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
某天晚上 9 点，你正在赶一个紧急需求，需要把 REST API 改成 GraphQL，同时修复一个 SQL 注入漏洞。你打开 OpenASE 的看板，创建了两个 Ticket（工单）：
/api/users 端点改为 GraphQL 查询login() 函数的 SQL 注入几分钟后，AI Agent 认领了这两个 Ticket，自动分配到了"Fullstack Coder"角色。它读取 Harness（约束文档），开始执行。你可以在看板上看它的每一步活动日志——读写文件、运行测试、提交代码。第二天早上，你看到两个 Ticket 全部完成，代码已推送到你的仓库。
这不是科幻，这是 OpenASE 正在做的事。
2026 年 3 月，一个署名 PacificStudio 的团队在 GitHub 上发布了 OpenASE。他们在 README 中写道："AI coding agents 很强大，但只有在人类保持控制时才能真正发挥作用。"
这句话揭示了项目的核心理念。当前的 AI 编程工具（如 Claude Code、Codex）都是"对话式"的——人类发出一段指令，AI 执行一段操作。但这种方式有一个根本问题：难以规模化。一个项目可能有几十个功能点，每个点都需要人来创建工单、分配任务、等待结果、审核代码。当项目规模扩大，人的协调成本反而更高了。
OpenASE 的解决方案是把 AI Agent 纳入组织架构：你创建 Ticket（工单），Agent 自动认领，Workflow（工作流）定义执行逻辑，Harness（约束文档）划定行为边界。这样，AI Agent 不再是"问答机器"，而是"流水线工人"——有角色、有流程、有追责。
如果把软件开发团队比作一个餐厅：
而 OpenASE = 整个餐厅的管理系统，把所有环节串联起来。
每个工单（Ticket）有完整的生命周期：Backlog → Todo → In Progress → In Review → Merging → Done。你可以在看板（Kanban Board）或列表视图中管理所有 Ticket，支持父子 Ticket 依赖关系和优先级排序。
Ticket 可以绑定到特定的代码仓库（Repository Scope），这样 Agent 在执行时知道它工作在哪个代码库上下文里。
OpenASE 支持两种人与 AI Agent 的交互模式：
异步模式（Ticket Agent）：适合需求明确、执行路径清晰的任务。Agent 按照 Workflow 自动推进，人只需要在关键节点审核。比如一个"全栈开发者"角色，从 Todo 到 Done 全程自动执行，不需要人中途干预。
同步模式（Project AI）：适合需求模糊、需要探索的场景。你在侧边栏开启对话，每个标签页是独立的隔离工作空间。Project AI 可以读取 Ticket、编辑 Harness、操作 Git、触发 Agent 运行，类似于一个带上下文感知能力的智能终端。
Skills 是可复用的指令文档，给 Agent 赋能额外的工具箱能力。每个 Workflow 自动绑定内置的 Ticket Skill，确保 Agent 理解状态流转规则。你也可以在 Skill Editor 中编写自定义 Skill，或从仓库导入。绑定后的 Skills 在运行时注入到 Agent 的配置目录（.codex/skills/、.claude/skills/、.gemini/skills/）。
目前 OpenASE 推荐 Claude Code 和 Codex 用于生产环境，Gemini CLI 也在支持范围内但稳定性稍弱。不同的 Provider 对应不同的 Agent 能力——Claude Code 在复杂推理和代码生成上表现突出，Codex 与 GitHub 深度集成，Gemini CLI 则是 Google 生态的选择。
⚠️ 重要提醒：为最大化无人值守执行，OpenASE 默认以 permissive 模式启动 Agent：
--dangerously-skip-permissions--yolo这意味着 Agent 可以读写和执行宿主机器上的任意命令，无需逐条确认。因此，强烈建议只在信任的环境（本地开发、私有网络）部署 OpenASE。生产环境应切换到 HTTPS + OIDC 认证（详见 OIDC & RBAC 指南）。
OpenASE 后端使用 Go 1.26+ 开发，核心依赖包括：
Go 的高并发特性使得 OpenASE 能够同时运行多个 Agent 实例，处理大量并发的 Ticket 任务。
关键设计：运行时不需要 Node.js。SvelteKit 前端在构建时编译为静态资源，通过 Go 的 go:embed 指令嵌入二进制文件。这意味着：
安装 OpenASE = 下载一个独立的 Go 二进制文件
启动 OpenASE = 运行一个命令，无需安装 Node.js 或配置 Web 服务器
这个设计极大地降低了部署复杂度，也让 OpenASE 真正成为一个"All-in-one"平台。
生产环境需要 PostgreSQL 15+，支持以下关键数据模型（通过 ent schema 定义）：
OpenASE 提供完整的 多阶段 Dockerfile：
支持通过 Coolify 一键部署，提供了 deploy/coolify/entrypoint.sh 入口脚本，自动处理环境变量验证、目录初始化和 Agent 配置注入。
OpenASE 暴露出完整的 RESTful API（OpenAPI 规范，1.6MB 的 api/openapi.json），包含：
Web UI 和 API 使用同一个 Go 二进制提供，无需分开部署。
优点：
缺点：
部署难度：中等。有 Docker 基础、了解 AI Agent 工具链的开发者可以顺利部署；纯小白需要先学习 Docker 和至少一种 Agent CLI 的使用。
OpenASE 代表了一个正在浮现的趋势：AI Agent 不再是人类的问答助手，而是可以嵌入工作流的自动化工人。它的 ticket-driven 模型与人类的项目管理方式（敏捷、JIRA、工单）天然对齐，降低了引入 AI Agent 的认知门槛。
从技术上看，它的"All-in-one Go binary"设计是一个工程亮点——前端编译嵌入二进制、数据库内嵌选项，使得交付的不是一个框架而是一个可直接运行的系统。这种思路对于需要本地部署的 AI 应用（不依赖云服务、数据隐私敏感）有重要参考价值。
图1：OpenASE Kanban 看板界面，支持 Ticket 生命周期管理和 AI Agent 活动追踪