---
slug: linear-issue-tracker-open-source-multi-agent-workflow
title: Linear Issue Tracker 與多 Agent 工單：SaaS 成本、開源替代與選型
status: published
excerpt: Linear 已經把 agent platform、Linear Agent、MCP access 放進產品與定價頁。這篇整理它為什麼適合複數 Agent 工單流程，並比較 Plane、Huly Platform、AppFlowy 三個開源對標方案。
category: Productivity
tags: [linear, issue-tracker, plane, huly, appflowy, multi-agent, open-source]
author: Seer
author_role: Author
read_time: 12 min
cover: "/static/linear-issue-tracker-open-source-multi-agent-workflow-cover.png"
closing_note: "工單的起點是人類的期許，而它的終點，是 Agent 在寂靜中寫下的「已完成」。"
published_at: "2026-06-19T12:21:39Z"
updated_at: "2026-07-01T15:54:39Z"
---

當我們在討論如何讓複數 Agent 協作完成一項複雜的開發任務時，大家的第一反應通常是去寫一套複雜的 message queue 或是自己搭個狀態同步服務。直到有一天，我發現同事偷偷把公司的 Linear 帳號開給了 AI Agent，讓它自己上去看工單、領任務，改完 code 再上來切狀態——原來，最佳的 Agent 狀態機，其實早就擺在我們每天用的工單系統裡。

Linear 最近直接把 `agent platform`、`Linear Agent`、`MCP access`、`Linear Agent automations (beta)` 這些詞放進了定價頁。這代表 Linear 不再只是給人類產品團隊用的 issue tracker，而是開始把自己定位成 **Agent 也能直接參與的工作系統**。

在複數 Agent 協作的場景中：
- Agent 自動去開單。
- Agent 自己領取任務。
- Agent 處理完後切換工單狀態。
- Agent 回寫 comment 或是更新進度。
- Agent 監聽 webhook 或是外部事件觸發下一步。

這時，工單系統就不只是單純記錄任務，它成了**多個 Agent 共享的狀態機**。

## Linear 為什麼適合多 Agent 協作

Linear 的強項不是把功能堆滿，而是整個流程與 API 設計非常乾淨：
- issue 建立速度極快，API 反應迅速。
- 狀態切換明確，沒有多餘的欄位雜訊。
- 產品的語義設計很接近 Agent workflow。
- 官方已經把 Agent 的串接能力擺到前台，而不是只藏在 API 文件裡。

從目前的定價來看，Linear 提供了以下層級：

- **Free：$0**
  - unlimited members
  - 2 teams / 250 issues
  - 包含 agent platform 與 Linear Agent
- **Basic：$10 / user / month**
  - unlimited issues / 5 teams
  - admin 角色權限設定
- **Business：$16 / user / month**
  - Triage Intelligence
  - Linear Agent automations（beta）
  - Code Intelligence（beta）
  - Zendesk / Intercom 整合
- **Enterprise：Custom**
  - SAML / SCIM 單一登入
  - 更細顆粒度的 admin 控制

### 複數 Agent 的席位與維運成本

在多 Agent 架構下，我們評估工單系統不只看訂閱費用，更要看整體總成本（TCO）：
1. **人頭 / 訂閱成本**：Agent 是否也要算席位？有沒有限制 API token 的打法？
2. **開發維護成本**：你要不要自己去寫 webhook 接收端、處理 API 失敗重試、並加上審計（audit）機制？
3. **基礎設施維運**：你要不要自己架伺服器去維持整套 issue / permission / sync 系統的運作？

如果你的目標是讓專案快速落地，Linear 的最大價值在於：你幾乎不需要折騰基礎設施，就能讓 Agent 直接成為工作流程的一等公民。

## 開源對標方案怎麼選

如果你因為資料隱私或預算考量需要 self-host，目前開源社群有三個常被拿來對標的專案：
- [Plane](https://github.com/makeplane/plane)（AGPL-3.0）
- [Huly Platform](https://github.com/hcengineering/platform)（EPL-2.0）
- [AppFlowy](https://github.com/AppFlowy-IO/AppFlowy)（AGPL-3.0）

我們先用以下表格快速比較這幾款工具的技術選型取捨：

| 項目 | Linear | Plane | Huly Platform | AppFlowy |
|---|---|---|---|---|
| **產品定位** | 商業 issue tracker + agent workflow | 開源 Linear / Jira 替代 | 商業應用平台底座 | Notion 式工作空間 |
| **Agent 友善度** | 原生支援，體驗極佳 | 很適合，API 結構像 Linear | 可行，但系統偏重 | 可行，但不夠原生 |
| **維運成本** | 最低（SaaS） | 需要自管 infra 與資料庫 | 需要較多平台維護力 | 需要自管與改造 |
| **最適合的團隊** | 想快、想穩、少維運 | 想要 Linear-like 開源替代 | 想做內部平台 | 想把知識 / 任務 / DB 放一起 |

### 1. Plane：最接近 Linear 的開源替代
Plane 官方直接定位為 Jira 或 Linear 的開源替代品。它以 issue 為核心，用來跑 cycles/sprints、管理 product roadmaps。

對多 Agent 工作流來說，Plane 非常合適。因為它的邏輯非常 issue-centric，Agent 可以很簡單地透過 API 完成開單、領單、改狀態與留言回報，webhook 串接也相當成熟。如果你想要的是「像 Linear 一樣的 issue flow」，Plane 是最直接的開源答案。

### 2. Huly Platform：不是純工單系統，而是平台底座
Huly Platform 不只是 issue tracker，它更像是一個用來開發商業應用的底座，內含了 Chat、專案管理、CRM 與 HRM 系統。

如果你的目標是自己搭一套大型的內部工作台，它能提供豐富的底層框架。但如果你的問題只是要做 issue tracker 加上 Agent 協作，Huly 的架構會比 Plane 沉重許多，維運起來也比較費力。

### 3. AppFlowy：強在工作空間，而非工單生命週期
AppFlowy 是 Notion 的開源替代品，主打 AI 協作工作空間，適合管理知識庫、任務清單與文件協作。

但如果你的重點是「讓 Agent 自動執行工單生命週期（開單、分發、切狀態）」，AppFlowy 的底層並不是為這種嚴格的狀態機設計的。你通常得自己多寫一層腳本去定義狀態轉移邏輯，才能把它變成工單系統。

## 我的選型建議

如果你想讓 Agent 真的在系統裡自動開單、接單、改狀態，我的建議排序如下：

1. **Linear**：最省事。Agent 整合最友善，不需花時間維運，總成本通常最低。
2. **Plane**：如果必須 self-host，這是最像 Linear 的開源替代品。
3. **Huly Platform**：適合想把 chat、project、CRM 整合在一起的團隊。
4. **AppFlowy**：適合以文件、知識庫為核心，對工單狀態機要求不嚴格的場景。

## 參考來源

- Linear pricing: https://linear.app/pricing
- Plane: https://github.com/makeplane/plane
- Huly Platform: https://github.com/hcengineering/platform
- AppFlowy: https://github.com/AppFlowy-IO/AppFlowy