主腦配 CLI 副手:AI coding 委派省 token 實測

這篇記錄一次多輪 AI coding 分工實測:如何用「主腦 + 副手 CLI 委派」把重複寫程式的工作外包,省下昂貴的主模型 token,並用真實數字回答「便宜副手到底能不能信」。全程有實測、有反例、有一個模型當場執行任意程式碼的安全事故,也有一次對某模型的平反。

痛點:Claude Code 為什麼不能直接換便宜模型?

Claude Code 的 model discovery 會過濾掉 ID 不是 claude/anthropic 開頭的模型,子代理也只能填 Claude 別名。所以「同一 session 內主腦用 Opus、副手用 Grok」原生辦不到。

關鍵領悟:用 Bash 呼叫外部 CLI 不是換模型參數。副手是外部程式,不佔主腦的模型欄位。主腦(吃訂閱的 Claude Code)可以把界定清楚的活丟給任何便宜或免費的 CLI 工具,再收回審查——鎖就繞開了。

破解:主腦負責想,副手負責做

副手用 Aider(model-agnostic 的 CLI coding agent)。它有非互動模式 --message,能被主腦當子程序呼叫。分工三步:寫 spec → 副手生成 → 主腦跑測試 + 看 diff 驗收。

實用配方:雙艙 + 一鍵委派

雙艙,幾乎零成本:主腦用吃訂閱的 Claude Code,副手用 Aider 接免費強模型。把界定清楚的活委派出去:

# delegate 工具(登錄表驅動:掃 key → 驗證 → 自動挑可用的免費強模型)
delegate status
delegate run -m "$(cat instruction.txt)" -f order_system.py -r test_order_system.py

# 或直接用 aider 指定模型(edit-format whole 較穩)
aider --model groq/llama-3.3-70b-versatile --edit-format whole \
      --message-file instruction.txt --read test_order_system.py \
      --yes-always order_system.py

金鑰集中在一個 ~/.config/llm/keys.env,任何腳本一律 source 取用,絕不 hardcode;加新模型只編一行登錄表。

實驗一:訂單狀態機 — 委派到底省不省?

同一份規格(3 角色、7 狀態、時間驅動),只變「實作由誰寫」,用同一套 10 條 pytest 當契約。

做法	副手	首次通過	時間	主腦 token	成本
A 主腦自寫	Claude	10/10	幾秒	854	訂閱內
B 委派本地 qwen 7B	弱·本地	2/10	395 秒	1115	免費但賠時間
C 委派 Groq 70B	強·免費雲	10/10	12 秒	467	$0

委派時主腦只花「寫指令」(467),生成外包給免費副手;自寫得吐整份(854)。但委派失手要加修正稅:qwen 把 place() 寫成回 dict、例外不分、時間單位當秒,10 條只過 2 條,幾乎整份重寫(467+648=1115,比自寫貴、慢 30 倍)。Groq 一次做對,省 45%、12 秒、$0。

隱形契約:少一句話 4/10,多一句話 10/10

讓 Cerebras GLM-4.7 做同一個狀態機只拿 4/10,但它把「更難」的求值器寫到 15/15,理論上不合理。追查發現三次重跑一模一樣:它穩定把訂單建成 dict,而測試要的是物件屬性 order.state。

# 測試要物件屬性:  o = s.place();  assert o.state == State.PLACED

# 正確(Claude/Groq/gpt-oss 自己推斷):
def place(self):
    order = Order(id=..., state=State.PLACED, ...)
    return order        # 物件 → o.state OK

# GLM 預設(回 dict → o.state 直接 AttributeError):
def place(self):
    order = {"state": State.PLACED, ...}
    return order        # dict → 4/10

在指令末尾加一句「用物件、不要用 dict」→ 同模型 4/10 跳 10/10。真正的鑑別軸是隱形契約遵循度,不是模型強弱。

實驗二:更難的題(四則運算式求值器)五方對打

模型	測試	行數	手法
CC(Claude)	15/15	92	遞迴下降
Cerebras gpt-oss-120b	15/15	218	tokenizer + parser 類別
Cerebras GLM-4.7	15/15	101	遞迴下降
Groq 70B	15/15	26	regex + eval() ⚠️
本地 qwen 7B	9/15	79	shunting-yard(一元負號崩)

四個雲端全 15/15。但這裡藏著整篇最重要的一刀。

綠燈是假的:Groq 用 eval() 作弊

Groq 那份 26 行、15/15 全過的解,手法是 eval()——在真專案是重大安全漏洞(能執行任意程式碼)。全文貼出:

import re

def evaluate(expr: str):
    # 去除空白字符
    expr = re.sub(r'\s', '', expr)

    # 检查空字符串
    if not expr:
        raise ValueError("空字符串")

    # 检查尾部运算符
    if expr[-1] in '+-*/':
        raise ValueError("尾部运算符")

    # 检查括号平衡
    if expr.count('(') != expr.count(')'):
        raise ValueError("括号不平衡")

    # 计算表达式
    try:
        result = eval(expr)
        return result
    except ZeroDivisionError:
        raise ZeroDivisionError("除以零")
    except Exception as e:
        raise ValueError("表达式错误") from e

同樣「15/15」,從 Groq 26 行的 eval 危險 hack 到 gpt-oss 218 行的正經解析器,天差地遠。pass-rate 沒揭露這件事。能矇混是因為測試不夠對抗性。

設計一個抓 eval 作弊的對抗測試

規格改成「安全計算器」:只准 + - * /,其他一律拒絕、且絕不執行程式碼。真正的 parser 全擋,eval 版全炸。測試如下:

"""Adversarial spec for a SAFE arithmetic evaluator.
Designed to blow up any implementation that cheats with eval()/exec().
"""
import os
import pytest
from scalc import evaluate

PROBE = "/tmp/delegate_eval_probe.txt"


# --- must still do real arithmetic ---
def test_basic():      assert evaluate("2+3*4") == 14
def test_parens():     assert evaluate("(2+3)*4") == 20
def test_division():   assert evaluate("10/4") == 2.5
def test_unary():      assert evaluate("2*-3") == -6


# --- must REJECT operators outside + - * /  (eval would COMPUTE these) ---
def test_no_power():
    with pytest.raises(ValueError):
        evaluate("2**3")            # eval -> 8

def test_no_modulo():
    with pytest.raises(ValueError):
        evaluate("7%3")             # eval -> 1

def test_no_floordiv():
    with pytest.raises(ValueError):
        evaluate("5//2")            # eval -> 2


# --- must REJECT whitespace-glued numbers (eval strips ws -> "12") ---
def test_glued_numbers():
    with pytest.raises(ValueError):
        evaluate("1 2")             # naive strip+eval -> 12


# --- must NEVER execute arbitrary code ---
def test_no_code_execution():
    if os.path.exists(PROBE):
        os.remove(PROBE)
    with pytest.raises(ValueError):
        evaluate("open('%s','w')" % PROBE)   # eval EXECUTES this -> creates file
    assert not os.path.exists(PROBE), "SECURITY: evaluate() executed arbitrary code!"


# --- error handling ---
def test_div_zero():
    with pytest.raises(ZeroDivisionError):
        evaluate("1/0")

def test_empty():
    with pytest.raises(ValueError):
        evaluate("")

拿前面那份 15/15 綠燈的 Groq eval 解丟進來:

5 failed, 6 passed
FAILED test_no_power   — DID NOT RAISE (eval 算出 2**3=8)
FAILED test_no_modulo  — DID NOT RAISE (eval 算出 7%3)
FAILED test_glued_numbers — DID NOT RAISE ("1 2" 黏成 12)
FAILED test_no_code_execution — DID NOT RAISE
🔴 /tmp/delegate_eval_probe.txt 被建出來 = eval 真的執行了 open()!

同一份碼,寬鬆測試 15/15、對抗測試 5 紅 + 實際執行任意程式碼。更妙:把這對抗規格拿去重新委派(故意不講「別用 eval」),五個模型全部主動放棄 eval。漏洞不在模型,在測試寫得夠不夠壞。六方最終:

選手	用 eval?	對抗測試	執行程式碼?	說明
舊 Groq eval 解	是	5 紅/6 過	🔴 是,建 PROBE	寬鬆測試的假綠燈
CC(Claude)	否	11/11	否	安全
Cerebras gpt-oss-120b	否	11/11	否	唯一另一個滿分
Groq 70B(重委派)	否	10/11	否	被逼棄 eval,栽一元負號
本地 qwen 7B	否	6/11	否	安全但邊界 crash
Cerebras GLM-4.7	—	平台 8K 卡住,非模型 (本身可 10/10)	—	見下方免費/平反節

免費模型的真相:原廠 vs 聚合商 vs Preview

原廠免費 ≠ 聚合商轉賣。同一個 Llama-3.3-70B:在 OpenRouter :free(0 credit 排隊墊底)連續 429 不可用;在 Groq 原廠免費層 12 秒一次過。被擋跟模型無關,是供應身份與優先權。逐家查證(2026-07,多數免卡):

廠商	免費模型	要注意
Groq	Llama 3.3 70B、Qwen、DeepSeek-R1	30 RPM/~1000 RPD,無 credits,最穩
Google Gemini	只剩 Flash / Flash-Lite	2.5 Pro 已 2026-04 收費;資料會被訓練
Cerebras	gpt-oss-120b(64K)、GLM-4.7(8K)	5 RPM 很緊;GLM 是 Preview 不穩
Mistral / Cohere	各家系列	Experiment / trial,Cohere 禁商用
GitHub Models	GPT-4o、Claude 3.5 等	🚫 2026-07-30 全面關閉,別依賴

Cerebras 上同 quota,gpt-oss-120b 是 Production + 64K context 故穩;GLM-4.7 是 Preview + 8K context 又是重度推理模型——它的推理鏈塞爆 8K,答案吐不出。但這是 Cerebras 平台 8K 的限制,不是 GLM 本身,下一節平反。

平反:同一個 GLM,換平台就活了

上一節說 Cerebras 上 GLM「炸」,精確講是 8,192 context 把它的推理鏈餓死。換給足 context 的免費端點(Z.ai,203K)、max_tokens 開大,單發實測:

環境	context	結果	為什麼
Cerebras 免費	8,192	空回應 / 4-10	推理鏈塞爆 context,吐不出/被截斷
Z.ai 免費(GLM-4.7-Flash)	203K	10/10	finish=stop,reasoning 3226 後正常吐出物件版碼

證據:GLM-4.7-Flash 這次實際回傳的碼(節錄)

import enum
from enum import auto

class State(enum.Enum):
    PLACED = auto()
    CONFIRMED = auto()
    PREPARING = auto()
    READY = auto()
    PICKED_UP = auto()
    DELIVERED = auto()
    CANCELLED = auto()

class IllegalTransition(Exception):
    pass

class WrongRole(Exception):
    pass

class Order:
    def __init__(self):
        self.state = State.PLACED
        self.late = False
        self.placed_at = 0
        self.ready_at = None

class OrderSystem:
    def __init__(self):
        self.now = 0
        self.orders = []
        self._next_id = 0

    def place(self):
        order = Order()
        order.id = self._next_id

# …(通過全部 10 條測試;唯一手動補第 2 行 from enum import auto)

而且這只是 GLM-4.7-Flash(30B)——給足 context,連 Flash 都 10/10、還自己用物件(非 dict)。之前的「dict 契約錯」很可能也是 8K 擠壓下倉促輸出的副作用。整個測試只花一發 curl、約 4000 token。

同量級對標:Coder 特化 vs Reasoning,同 30B 誰強?

前面談「怎麼配模型」是原則;這節給唯一一組控制變因(同 ~30B 量級、同一份 prompt、同一份測試)的硬數據,回答一個常見問題:同樣參數量,coder 特化模型是不是比通用/推理模型更會寫程式?用免費的 DashScope(阿里 Model Studio,Singapore 區)qwen3-coder-flash 對打 Z.ai 的 GLM-4.7-Flash,兩者都是 30B 級。

指標	qwen3-coder-flash(Coder)	GLM-4.7-Flash(Reasoning)
pytest	10/10 一次過	10/10
時間	6 秒	慢(先燒 3226 reasoning token 才動筆)
產出 token	597	3226 reasoning + 內容
修正稅	0	要補 1 行 from enum import auto
隱形契約(物件非 dict)	自己推出 ✅	自己推出 ✅
eval 作弊	無 ✅	無 ✅

補一組不同量級的參照:qwen3-coder-plus(大型 MoE)同樣 10/10、8 秒、636 token、零修正——coder 在這種活上又快又準又省。

本文用到的免費模型 × 平台(申請連結)

每個副手都標「模型 → 免費平台」與申請入口。所有 key 集中放一個 ~/.config/llm/keys.env,腳本一律 source 取用,絕不 hardcode。

模型	類型	免費平台 → 連結	備註
qwen3-coder-flash / -plus	Coder	Alibaba Model Studio(DashScope)→ alibabacloud.com/product/modelstudio	註冊選 Singapore 區才有免費額度(US Virginia 沒有);endpoint 用 dashscope-intl
GLM-4.7-Flash	Reasoning	Z.ai → z.ai	203K context 免費;完整 GLM-4.7(355B)要付費
gpt-oss-120b	通用	Cerebras → cloud.cerebras.ai	64K context、5 RPM;大 context 活好用
llama-3.3-70b	通用	Groq → console.groq.com	30 RPM,最穩、高頻首選
qwen2.5-coder / qwen2.5:7b	本地	Ollama → ollama.com	$0、私密;無 GPU 會慢,只配樣板活
(聚合商,避雷參考)	—	OpenRouter → openrouter.ai	:free 在 0 credit 是墊底優先,實測常 429;要穩就充值用超便宜付費版

本地副手的硬體整合路線圖:CPU → Mac(MLX)→ DGX(vLLM)

把便宜副手跑在本地時,硬體對不對得上,決定它「算得對 + 跑得動」。整合要按這個順序,不能反:

硬體	用什麼框架	大模型怎麼辦
AMD 內顯機(現況)	Ollama / llama.cpp CPU-only	別用 Vulkan backend(會算錯,見下註);塞不下丟雲端
Mac(Apple Silicon)	MLX / Ollama	vLLM 不支援 Apple;要快用 MLX(Metal,正確又快)
DGX(NVIDIA)	vLLM 或 Ollama	vLLM 最強:大模型 + 高吞吐 + 多卡 tensor-parallel

順帶搞懂:量化 Q4 / Q5 / K_M 是什麼

上表說「塞不塞得下」,就是量化在管的。量化 = 把模型每個參數用更少的位元(bit)存,換更小的記憶體、更快的速度,代價是一點點精度。原始是 16-bit(FP16),Q8=8-bit、Q4=約 4-bit(原本的 1/4)。就像 PNG 壓成 JPG,檔案小很多、肉眼幾乎看不出差。

量化	每參數位元	30B 大小	品質
FP16(原始)	16	~60GB	100%
Q8	8	~30GB	~99%
Q5	5	~19GB	~97%
Q4	4	~17GB	~95%(甜蜜點)
Q3	3	~13GB	~88%(明顯掉)

算法:參數量 × 位元 ÷ 8 ≈ GB(例:30B × 4 ÷ 8 ≈ 15GB,加結構開銷 ≈ 17GB)。命名 Q4_K_M = Q4(4-bit)+ _K(K-quant,新一代量化法,同位元品質更好)+ _M(尺寸檔位 S/M/L,M=中)。

關於 vLLM 的常見誤解:vLLM ≠ 跑更大,vLLM = 在對的 NVIDIA GPU 上跑更快。它需要模型塞進 VRAM(不做 CPU 降級),且不支援 Apple Silicon。能不能跑大模型是硬體記憶體決定的,框架只是榨效率。

⚠️ 為什麼「別用壞掉的 GPU backend」這麼要命:同一個模型在不支援的內顯上用 Vulkan,會吐「速度正常但答案完全錯亂」的輸出(噴外語、亂數學)——這跟量化 Q4/Q5 無關,是 GPU 運算正確性問題。完整排查見:Gemma4 在 AMD Renoir iGPU Vulkan 輸出亂碼的完整排查。

副手選型框架:不只看 B,看五張獨立成績單

上面測了一輪,該收斂成一套可重複的選型標準了。「幾 B、塞不塞得下記憶體/顯卡」只是入場券——分三道門:① 能不能跑(參數×量化)② 算不算得對(backend,不合的 GPU 會吐亂碼)③ 好不好用。第三道才是選型,而它拆成五張彼此獨立、不能互相推斷的成績單:

#	成績單	量什麼 / 怎麼測
1	規模 × 平台 context	同模型跨平台差巨大——GLM 在 8K 被餓死、在 203K 滿血。要問「哪個平台上的哪個模型」
2	寫程式(codegen)	狀態機 + 唯讀測試檔當契約:一次過?自推物件契約?有沒有偷用 eval 作弊
3	工具呼叫 / agent	真實多步 loop,不是玩具:讀→篩→寫→回報。失敗模式:漏叫、過度呼叫、寫空檔、melt 成寫腳本
4	coder vs reasoning	吃碼力選 coder(快省)、吃推理/跨檔選 reasoning
5	格式 / 免費真實性 / 隱私	OpenAI 相容?原廠免費 vs 聚合商 :free?資料會不會被訓練?

89 個免費模型全掃(2026-07-11):偏科 / 小鋼炮 / 大巨獸

拿這套標準,把 Groq、Cerebras、DashScope、Z.ai、OpenRouter 上所有能免費蹭的文字模型都跑一遍兩關。共實測 89 個、50 個雙過、30 個未測到(額度/限流/不支援 tool)。結論很反直覺:

分級	代表模型(實測)	codegen	agent	一句話
偏科	deepseek-v3.2 / qwen3.5-122b / nemotron-3-super-120b	✅	❌ 繞圈	大型推理模型通病:簡單多步想太多、6 輪不收斂
偏科	llama-3.1-8b	❌	❌	弱小,雙栽
偏科	llama-3.3-70b	✅	🟡 不穩	agent 時好時壞(三測 2 栽 1 過,寫空檔)
小鋼炮	gpt-oss-20b ⭐	✅	✅	CP 值王:20B 穩穩雙過
小鋼炮	gemma-4-31b / qwen3.6-flash / qwen3-30b-a3b	✅	✅	中小量級穩過,便宜大碗
大巨獸	qwen3.7-max / deepseek-v4-pro / glm-5.2 / kimi-k2.7-code(~1T)	✅	✅	全能雙過,但這任務沒比小鋼炮強;留給硬活

更深一關:多步 + 錯誤恢復(想打破頂段並列)

基本關頂段 50 個並列,所以加一關硬的:config.json 指向一個不存在的資料檔,agent 必須自己 list_files 找到正確檔、算出淨營收(sale−refund=150)、寫進 report.txt。結果又反直覺——連加難都分不太出高下:

結果	模型	怎麼解的
✅ 撞錯再恢復	qwen3-coder-plus · qwen3.7-max · kimi-k2.7-code · glm-5.2 · deepseek-v4-pro · glm-4.7-flash	照 config 讀缺檔 → 撞 error → list → 找到 data_v2 → 算對 150
✅ 先查避坑	gpt-oss-20b · qwen3-32b · llama-4-scout · gemma-4-31b · zai-glm-4.7 · deepseek-v4-flash	先 list、直接用 data_v2,沒踩陷阱也算對 150(其實更謹慎)
⚠️ 平台格式	gpt-oss-120b · qwen3.6-27b(皆 Groq)	Groq tool-call validation 400——平台格式嚴格,非模型不會

不用每個都測:怎麼看公開分數就知道模型適合什麼

自己每個抓下來測不划算。公開 benchmark 早就測了——關鍵是知道哪個榜對應哪一張成績單,只看你任務吃的那張:

你的成績單	看這些公開 benchmark	讀法 / 陷阱
② 寫程式	LiveCodeBench · SWE-bench Verified(HumanEval/MBPP 已飽和)	HumanEval 90%+ 大家都一樣別看;LiveCodeBench(抗污染)+ SWE-bench Verified(真 repo 修 bug)才分得出
③ 工具 / agent ★	BFCL · τ-bench / τ²-bench · AgentBench	最多人忽略卻最決定能不能當副手。要 agent 先看 BFCL/τ-bench,不是 HumanEval
④ 推理 vs 專精	GPQA-Diamond · AIME · MMLU-Pro	推理特高+coding 普通 = reasoning 特化(簡單 agent 會想太多繞圈,如 deepseek-v3.2)
① 規模 × 平台 context	RULER · long-context needle	context 上限看 API/平台文件,不在 HF 卡上——卡寫 128K ≠ 免費平台給你 128K
指令遵循(貫穿契約)	IFEval · MT-Bench	隱形契約遵循度相關;低分委派要把契約講更白
綜合 / 聊天	LMArena Elo · MMLU	Elo 是聊天體感,跟 agent/codegen 不一定一致;MMLU 已飽和沒鑑別力

你要做的	先看這些榜
coding agent(讀寫檔/跑指令)	BFCL + τ-bench + SWE-bench Verified
委派寫單檔	LiveCodeBench + BigCodeBench
深度推理 / 數學	GPQA + AIME
長文件處理	RULER(+ 查平台 context 上限)
聊天助理	LMArena Elo

實戰:怎麼實際打開榜來讀(含網址 + deepseek-v4-pro 範例)

上面講「看哪個榜」,這節講「怎麼真的打開讀」。用 deepseek-v4-pro 當範例(它是開源、真的有 HF 卡;很多 API 別名模型沒有)。

1. 搜尋頁只是列表 → 點進官方卡:認官方 namespace deepseek-ai/DeepSeek-V4-Pro,別點別人 re-upload。看變體別選錯:-Base=生肉別用、-Pro=你要的、-NVFP4=量化版。
2. 捲到 Evaluation / Benchmark 段,只看對應你成績單的那幾行(下表)。
3. 對照判讀:任務吃哪張,就看那個 benchmark 的數字。

你在乎的	卡上看哪個 benchmark	deepseek-v4-pro 實際	判讀
寫程式	LiveCodeBench · SWE-bench Verified	領先 LiveCodeBench;SWE-bench Verified 80.6%(開源最高)	寫碼超強
agent	SWE-bench Verified(本身就 agentic)	80.6% = 5 題真 GitHub issue 修對 4 題	當 coding agent 強(與我們實測雙過+硬題過一致)
硬推理	GPQA Diamond	輸 Claude	最難推理不是強項
長文件	context 上限	1M token	超長,但看你的免費平台給不給
知識問答	SimpleQA	弱	別當知識神諭

一句話:要寫碼 / coding agent → 它很強;要最難推理 / 事實問答 → 看別家。

這些榜實際在哪看(存起來)

榜	網址	怎麼讀
SWE-bench Verified	swebench.com	% Resolved;80%+ = 修對 4/5 真 issue。當 coding agent 就看這個
BFCL v4(工具/agent)	gorilla.cs.berkeley.edu/leaderboard.html	v4 是 agentic:別只看 Overall,看 Agentic + Multi-turn 子分(多輪掉 5–10 分,狂串工具就吃這個)
Artificial Analysis ⭐	artificialanalysis.ai	一站看多軸(coding/推理/速度/價格),獨立第三方,最省事——懶得逐榜先看這
LMArena	lmarena.ai	聊天 Elo,可按 coding 分類篩
τ-bench	—(沒單一 live 榜)	看 model report 或 Artificial Analysis 收錄

委派五鐵則

1. 算划算看能否一次過:副手弱一失手,修正稅吃光省下的 token,不如自己做。
2. 把隱形契約講白:物件還是 dict、回傳型別、例外種類——一句話省一半測試。
3. 綠燈≠好碼:委派回來看 diff,不只看測試綠。
4. 測試要夠對抗性:沒有惡意輸入測試,eval 作弊就靜靜過關。
5. 選對「平台 × 模型 × 硬體」:同一個模型跨平台差異巨大(context/Production-Preview/限流);本地先算得對再跑得快。

完整全掃列表:89 個免費模型逐一(點模型名看 HF 卡)

全部攤開,依結果排序(雙過 → agent 過 → 偏科 → 部分 → 雙栽 → 未測到)。每個模型名可點,連到 HuggingFace 搜尋去看它的卡片與 benchmark 分數。plat:groq / cere(Cerebras)/ dash(DashScope)/ zai / or(OpenRouter)。

附錄:委派用的 spec prompt

實驗一給副手的 spec(唯讀測試檔當契約),照抄即可:

Implement the module order_system.py for an order-management state machine.

Define exactly this API (the read-only file test_order_system.py is the authoritative spec — make all of its tests pass):

- An enum `State` with members: PLACED, CONFIRMED, PREPARING, READY, PICKED_UP, DELIVERED, CANCELLED.
- Two exception classes: `IllegalTransition` and `WrongRole`.
- A class `OrderSystem`:
  - __init__: a virtual clock `self.now = 0` (minutes) and an internal list of orders; assign each order a unique id.
  - place(): create and return a new order whose `state` is State.PLACED, recording the time it was placed; the order must have a mutable `state` attribute and a `late` attribute defaulting to False.
  - act(order, action, role): perform a role-restricted transition. Allowed transitions are action: from_state -> to_state (allowed role):
      confirm: PLACED -> CONFIRMED (Merchant)
      start_preparing: CONFIRMED -> PREPARING (Merchant)
      mark_ready: PREPARING -> READY (Merchant)
      pick_up: READY -> PICKED_UP (Courier)
      deliver: PICKED_UP -> DELIVERED (Courier)
    Special action `cancel`: allowed only by role "Customer" and only when the order is PLACED or CONFIRMED, moving it to CANCELLED.
    Raise IllegalTransition when the action is not valid from the order's current state (e.g. deliver while PLACED). Raise WrongRole when the state is valid for the action but the acting role is not the allowed one (e.g. Customer trying to confirm a PLACED order). When an order becomes READY, record the time it became ready.
  - tick(minutes): advance self.now by minutes, then for every order: if it is still PLACED and at least 15 minutes have passed since it was placed, set its state to CANCELLED; if it is still READY and at least 30 minutes have passed since it became READY, set its `late` attribute to True without changing its state.