Praetor 產品綜合文案 v0.1

狀態：整合稿，2026-05-19 依 ADR-002 更新核心抽象

這份文件是根據目前所有討論材料整理出的第一版完整產品文案。

它的目的不是把所有細節永久定死，而是把下面三件事講清楚：

1. 一句話先講清楚

Praetor 是一個給一人公司、solo founder、indie builder 使用的本地優先 AI 公司操作系統。

它不是一般 chatbot，不是 workflow builder，也不是單純的 multi-agent framework。

它的核心承諾是：

你管理的是一間 AI 公司：它有 Agent 雇員、角色職責、檔案、記憶、會議、決議與產物。Praetor CEO 會組織這家公司推進工作，並在真正需要授權時停下來請你決策。

2. 這個產品到底在解什麼問題

這個產品在解的，不只是「AI 幫你做事」。

它真正解的是：

一個人如何有效管理一個 AI 團隊，而不被細節壓垮。

典型目標使用者通常同時扮演：

真正的痛點不是能力不足，而是：

所以 Praetor 的價值不只是 automation，而是：

把角色與執行層外包給 AI，同時保留老闆該有的控制權。

3. Praetor 是什麼，不是什麼

3.1 Praetor 是什麼

Praetor 是：

3.2 Praetor 不是什麼

Praetor 不是：

4. 穩定方向與可彈性項目

4.1 已經足夠穩定的方向

以下判斷已經可以當成產品核心：

4.2 仍然可以調整的部分

以下目前仍可彈性調整：

5. 市場位置與現有產品差異

截至 2026 年 4 月 24 日，現有產品已經很多，但它們大多分屬不同類別。

5.1 現有工具各自擅長什麼

ChatGPT / Codex

Dify

Flowise

LangGraph

CrewAI

5.2 Praetor 要打的不是同一場仗

Praetor 不需要和這些工具比誰更像 workflow builder，也不需要比誰更像 agent framework。

Praetor 的真正差異化是：

把 AI 從「會做任務的工具」提升成「有治理、有分工、有記憶、有決策節點的公司組織」。

市場上仍然相對缺少的是：

5.3 差異總結

| 類型 | 主要抽象 | 使用體驗 | Praetor 的差異 |

|---|---|---|---|

| ChatGPT / Codex | 對話或單次委派任務 | 助手 / coding agent | 沒有持續的公司治理模型 |

| Dify / Flowise | flow / graph / app | builder canvas | 不是 founder command center |

| LangGraph | agent runtime | developer framework | 對創辦人太低階 |

| CrewAI | agent team / workflow | 多 agent automation | 仍偏 framework / platform |

| Praetor | agents + roles + governance + company memory | 老闆視角的 AI 公司本體 | 組織化、治理化、檔案原生 |

6. 為什麼這個產品有機會成立

Praetor 成立的關鍵，不在於「模型比別人更聰明」。

而在於它把真正麻煩的那一層做成產品：

也就是說：

現在 AI 的能力已經夠強，真正缺的是讓它能像一間公司那樣穩定運作的產品結構。

7. 目標使用者

主要使用者：

第一版不應該優先瞄準：

8. 核心產品哲學

8.1 Files are the source of truth

公司真正的長期記憶與成果，應該存在：

SQLite 可以存在，但只應該承擔：

不要讓真正的公司知識只存在於隱形資料庫裡。

8.2 User 管 Agent；Role 是職務框架

使用者管理的是 AI 公司裡的 Agent 雇員：

使用者不應該管：

Role 仍然重要，但它是 Agent 的職務、職責與權限框架，不是取代 Agent 的使用者抽象。

8.3 治理不是附屬功能，而是產品本體

Praetor 的真正價值是：

8.4 記憶屬於公司，不屬於 agent

MVP 不應做：

MVP 應該做：

8.5 第一版就要讓人感覺完整

完整不代表功能很多。

完整代表：

9. 核心使用者經驗

正確的心智模型是：

Onboarding = 你和 Praetor 的第一場會議

使用者應該感覺到：

理想互動是：

使用者說：

我想開始一個新專案

Praetor 回：

這裡的靈魂是：

Praetor 決定怎麼跑，使用者決定方向與重要授權。

10. Company DNA

Company DNA 是目前整個方向裡最強的一個設計點。

它應該在 onboarding 期間由 Praetor 引導產生，並落在：

workspace/Wiki/Company/DNA.md

它至少要定義：

範例：

company_dna:
  leadership_style: strategic
  decision_style: balanced
  organization_style: lean
  autonomy_mode: hybrid
  risk_priority: avoid_wrong_decisions
  communication_style: concise
  operating_principles:
    - default_to_action_escalate_when_uncertain
    - keep_roles_minimal_but_clear
    - document_important_decisions
    - avoid_unnecessary_user_interruption

這個設計的價值在於：

使用者定義文化與風格，系統依此生成組織與行為。

11. Agent-Managed / Role-Grounded Organization

Praetor 應該是 agent-managed、role-grounded。

使用者操作的最小單位是 Agent。每個 Agent 必須有 Role、職責、權限、主管、下屬、目前工作與產出紀錄。Role 是 job description 和 authority frame。

範例：

agent:
  name: File System Steward
  reports_to: Praetor CEO
  role:
    name: Workspace Stewardship
    responsibility:
      - organize_workspace_folders
      - place_files_consistently
      - maintain_file_naming_policy
      - prepare_archive_recommendations
    output:
      - workspace_hygiene_report
      - organized_project_folders
      - file_placement_decisions
    constraints:
      - no_silent_sensitive_file_moves
      - preserve_user_visible_filesystem_truth

使用者可以看 Agent，也可以下鑽看 Role。UI 的重點是責任鏈，而不是 personality。

系統再做：

這會讓 Praetor 相對於一般 multi-agent 產品更像真正公司：不是一群平等 bot，而是有上下級、責任與產出的 Agent 組織。

12. 組織層級

12.1 MVP 的正確層級

Owner
  ↓
Praetor（CEO 層）
  ↓
必要時產生的 PM / manager 層
  ↓
worker roles
  ↓
reviewer
  ↓
executors

12.2 為什麼這樣合理

這樣做的好處：

12.3 關鍵原則

Hierarchy exists, but complexity is hidden.

這句話很重要，因為它同時解決：

13. CEO Load Management

Praetor 不應該永遠硬扛全部 context。

當任務變大、token 過高、決策太密、mission 太多時，CEO 層應該有權建立 mission-scoped manager。

13.1 建立 PM 的觸發信號

建議納入：

示意設定：

ceo_context:
  warning_at_tokens: 70000
  split_at_tokens: 90000

complexity:
  max_steps_without_pm: 5
  max_domains_without_pm: 1

organization:
  max_active_missions_per_ceo: 3

blocked:
  create_pm_after_blocked_count: 2

13.2 PM 的性質

PM 應該是：

而不是永久人格角色。

13.3 CEO 與 PM 的 context 分工

CEO 應該主要讀：

PM 應該主要擁有：

這是避免 context 爆炸的核心技術手段。

14. 記憶架構

推薦記憶模型如下。

14.1 Company Memory

共享、持久、可審核的公司記憶：

14.2 Task Memory

mission / task 級的工作記憶：

這些應該可歸檔，但不應污染 Wiki。

14.3 Agent Memory

MVP 建議：

理由：

14.4 一句最乾淨的記憶哲學

不要讓 agent 記住事情，要讓公司記住事情。

15. Skill 與 Capability Layer

Skill 不應該只是 prompt collection。

它應該是可執行能力。

例如：

skill:
  name: create_project_structure
  description: create_standardized_project_folder
  input:
    - project_name
  output:
    - folder_created
  actions:
    - create_folder
    - create_files
    - write_markdown

15.1 技能分類

建議分成：

例如：

15.2 Marketplace 時機

GitHub skill ecosystem 的方向是好的，但不應該進 MVP。

建議節奏：

16. AI Runtime Modes

這是產品非常核心的決策。

Praetor 應該支援三種模式。

16.1 API Mode

直接使用 provider API：

適合：

16.2 Local Mode

使用本地模型：

適合：

16.3 Subscription Executor Mode

使用使用者已登入、已付費的工具：

適合：

限制：

16.4 為什麼這個設計很重要

這不是小細節，這會直接影響產品吸引力。

Praetor 可以說：

Bring your own AI. Praetor 提供的是組織、治理、記憶與工作流程。

17. Executor Abstraction

Praetor 不應該假設只有一種執行方式。

推薦抽象：

ai_runtime:
  mode: api | local_model | subscription_executor
  transport: builtin | host_bridge

executors:
  codex:
    enabled: true
    requires_user_login: true
    workspace: /workspace
  api:
    enabled: false
  local:
    enabled: false

這一層至少要定義：

如果這層設計清楚，Praetor 才能同時支援：

18. 部署模型

Praetor 應該至少支援兩種主要部署方式。

但安裝路線應明確拆成兩條：

18.0 官方安裝路線

A. Quick Start

目標：

體驗：

B. Bring Your Own Subscription

目標：

體驗：

18.1 本機部署

使用者只要：

docker compose up -d

然後打開：

http://localhost:3000

對於 Quick Start，建議預設使用：

對於 subscription_executor：

18.2 Remote self-hosted

部署到 VPS / server：

v1 的正式支援判斷：

關鍵原則：

local-first，不代表 local-only。

19. Workspace 模型

建議 workspace 長這樣：

workspace/
├── Inbox/
├── Wiki/
├── Projects/
├── Finance/
├── Operations/
├── Development/
├── Decisions/
├── Missions/
└── Archive/

各區角色：

Mission 建議再做自己的結構：

workspace/Missions/<mission_id>/
├── MISSION.md
├── STATUS.md
├── TASKS.md
├── DECISIONS.md
├── CONTEXT.md
├── REPORT.md
└── logs/

20. 安全與治理

Praetor 的安全模型必須是顯式的，不能只靠 prompt。

20.1 Writable Scope

系統預設不應該能編輯整台電腦。

建議：

permissions:
  allow_read:
    - /app/workspace
  allow_write:
    - /app/workspace/Projects
    - /app/workspace/Wiki
    - /app/workspace/Decisions
    - /app/workspace/Missions
  deny_write:
    - /app/workspace/Archive

20.2 Approval 分級

系統至少要區分：

高風險例子：

20.3 Governance 要是 UI 一等公民

這些東西不能只躲在 config 裡。

使用者應能看到與調整：

21. Onboarding

Onboarding 應該是對話式的，不是設定導向的。

正確心智模型：

Onboarding 是你和 Praetor 的第一次建立公司會議。

21.1 建議流程

1. owner account bootstrap

2. 語言

3. 領導風格

4. 決策風格

5. 組織風格

6. autonomy 偏好

7. risk preference

8. runtime mode

9. executor connection step（conditional）

10. workspace path

11. company template

12. approval boundaries

13. first mission

說明：

21.2 為什麼這樣設計

好的 onboarding 要完成三件事：

onboarding 結束時，使用者應該已經擁有：

22. 使用者介面

Praetor 的 UI 應該像：

而不應該像：

22.1 主導航

建議：

22.2 整體布局

推薦 shell：

22.3 CEO Page

這會是最主要操作面。

應包含：

22.4 Overview

董事長視角總覽：

22.5 Tasks

任務頁要透明，但不能噪音太大。

需要支援：

22.6 Meetings

會議不是聊天室，而是結構化 review space。

輸出要偏向：

22.7 Memory

應暴露：

Retrieval Preview 很重要，因為它會直接提高信任感。

22.8 Models

Models page 應該是一級頁面，不要塞進 settings。

至少要看得到：

22.9 Settings

建議分組：

23. 速度、Checkpoint 與 Run Budget

Praetor 的節奏政策應該是：

AI 在正確的時間等人，人不應該每個小步驟都在等 AI。

23.1 Run Budget

每個 mission 都應有清楚 budget：

run_budget:
  max_steps: 20
  max_tokens: 100000
  max_time_minutes: 30
  max_cost_eur: 2.00

23.2 Stop Conditions

主要停止條件：

23.3 Default Autonomy Policy

推薦：

autonomy_policy:
  low_risk_tasks: auto_continue
  medium_risk_tasks: report_after_batch
  high_risk_tasks: require_approval

這樣可以解決你對「Codex 一直停下來問」的反感，同時保留必要邊界。

23.4 UI 控件

AI 暫停時，UI 應提供：

23.5 預設速度模式

建議三種：

預設應為 Balanced。

24. 技術架構建議

24.1 Frontend

推薦：

24.2 Backend

推薦：

理由：

24.3 核心 runtime 子系統

建議至少包含：

24.4 Storage

建議：

24.5 邏輯模組切法

backend/
├── api/
├── governance/
├── runtime/
├── roles/
├── executors/
├── memory/
├── missions/
├── models/
└── storage/

這是邏輯切分，不代表 repo 一定要長這樣。

25. 可擴展性

Praetor 的擴展不應該是「讓使用者看到更多複雜度」。

它應該是：

25.1 人類視角的可擴展

即使 mission 變多、PM 增加、executors 增加，使用者仍只看到一個穩定 executive interface。

25.2 技術上的可擴展

透過以下手段 scale：

25.3 產品上的可擴展

產品越來越強，但不應越來越難懂。

26. 什麼會讓使用者第一天就有感

這一點非常重要。

使用者要立刻感覺到：

Praetor 不是概念，而是真的開始幫我工作。

推薦的 day-1 立即有感場景：

26.1 Create Project

輸入：

輸出：

26.2 Review Inbox

輸入：

輸出：

26.3 Build Company Wiki

輸入：

輸出：

26.4 Update Status

輸入：

輸出：

這些都會在 workspace 產生真實可見成果，所以很有感。

27. 什麼會讓產品感覺完整

完整不等於大。

Praetor 要讓人覺得完整，至少需要：

如果這些都在，即使 integrations 還不多，產品也會有完成度。

如果這些不在，功能再多都會像 demo。

28. 主要風險與應對

28.1 風險：產品變太廣

應對：

28.2 風險：CEO 層變成瓶頸

應對：

28.3 風險：全靠 prompt magic

應對：

28.4 風險：使用者不信任系統

應對：

28.5 風險：成本與 token 感覺不可控

應對：

28.6 風險：coding executor 一直中斷

應對：

29. 建議 MVP 範圍

Praetor 第一版不應該做整個宇宙。

推薦 MVP：

推薦 MVP use cases：

30. 建議的建置順序

Phase 1

Phase 2

Phase 3

Phase 4

Phase 5

31. 最後收斂成一句產品命題

最強的版本可以寫成：

Praetor 是一間 founder-facing 的 AI 公司。

它給一個人：

使用者管理 Agents。

使用者定義的是：

Praetor 定義的是：

32. 最後的產品建議

目前這條產品方向是強的。

它強的原因不是它有很多 agent，而是它在正確的地方很有主見：

接下來最重要的，不是再擴散想法。

而是守住核心，不讓產品稀釋。

真正的核心不是沒有結構地堆很多 agent，而是：

一間有結構、有記憶、有治理，而且 solo founder 真的能每天使用的 AI 公司。

33. 參考來源

市場定位部分有用官方資料做交叉確認，基準日期為 2026 年 4 月 24 日：