Astra 把長任務拆成多代理工作

以前我以為 agent 只要會回話就夠了，現在我只看它能不能撐完長任務還不亂掉。

我玩 agent workflow 一陣子了，越玩越火大。Demo 很順，prompt 很漂亮，工具也接上了，結果一碰到真正長一點、髒一點、需要互相校正的任務，整個系統就開始飄。它會先很自信地拆解，再很自信地跑偏，最後還能很自信地把錯的東西包裝得像對的。那種感覺很熟：你不是在看一個會做事的系統，你是在看一個很會演的系統。

所以我看到 OpenAI 這條 Astra 線時，第一反應不是「喔又一個新名字」，而是終於有人把問題講清楚了：長時間、多代理、硬問題、最後還要能落到 Lean 證明。這種東西不是在比誰文案比較會寫，而是在比誰能把工作流撐住。這篇拆解主要參考 The Decoder 對 Astra 的整理，另外我也對照了 OpenAI、Lean / mathlib4 跟 Lean 官方站。來源沒有提供觀看數、star 數或 bookmark 數，我不亂編。

我先不看模型名，只看它想解哪種痛

OpenAI is working on a new model family tentatively called “Astra” that’s meant to be far more capable at long-running tasks than anything the company has shipped so far.

翻譯一下就是：這不是在賣一個聊天模型，這是在賣一個能撐久一點的工作系統。差很多。聊天模型的世界觀是你丟一句，它回一句；長任務系統的世界觀是你丟一個目標，它要自己分段、記狀態、追進度、修錯誤，還不能每一步都靠人盯著。

我之前做過一個多步驟 coding assistant，前面三步都很漂亮，後面開始出事。Planner 說要重構，Worker 說已經改完，Critic 說看起來沒問題，結果真正跑測試時才發現三個 agent 對「成功」的定義根本不同。有人在追可讀性，有人在追速度，有人在追語氣像不像產品簡報。那次我學到一件很煩的事：agent 不是不聰明，是它們太容易各說各話。

這也是 Astra 這種 framing 值得看的原因。它把問題往「長時間」拉，而不是往「更會講」拉。只要任務拉長，單輪 prompt 的優勢就會快速縮水，因為真正麻煩的是狀態維持、子任務切分、錯誤復原和跨步驟一致性。你不先解這些，模型再會聊天也沒用。

實操上，我會先把任務拆成四層：規劃、執行、檢查、驗證。規劃只管拆，不准直接下結論；執行只管做，不准發明規則；檢查只抓矛盾；驗證只看外部證據。這樣做很土，但土方法通常比較能活。

• Planner 只輸出可執行子任務。
• Worker 只處理一個 bounded task。
• Critic 只找漂移、漏項、前後不一致。
• Verifier 只看測試、規則、證明或 schema。

多代理真正值錢的地方，是協調

OpenAI stressed the system’s ability to coordinate multiple agents over extended periods to tackle especially hard problems.

也就是說，重點不是「單一模型有多會答」，而是「一群 agent 能不能長時間對齊同一個目標」。這件事比大家想的更難，因為協調本身就是成本。你一加代理，溝通、同步、回滾、衝突解決全都冒出來。沒有設計好，agent 數量越多，錯得越快。

我踩過最典型的坑，是把多個 agent 當成不同人格。看起來很酷，實際上很蠢。你會得到一個很會提案的 agent、一個很會潤稿的 agent、一個很會講廢話的 agent，然後沒人對結果負責。最後整個系統像在開會，開得很熱鬧，但產出還是不穩。這就是很多「agentic」系統的老毛病：把協作當魔法，把責任切碎之後，反而沒人能收尾。

如果 Astra 真能把多代理長時間協作做起來，那它的價值不在於某個漂亮 demo，而在於它把「持續工作」這件事商品化了。這代表未來的 agent 設計會更像分散式系統，而不是對話框。你要有排程、有 checkpoint、有觀測、有失敗重試，還要知道哪一步可以重跑、哪一步不能動。

我自己的做法是把每個子任務都變成可檢查物件。不要只回自然語言，最好回結構化欄位：做了什麼、假設是什麼、證據在哪、還缺什麼。這樣一來，後面的 agent 才能接手，不然每次接棒都像在讀別人的腦內草稿。

• 每一步都要有明確輸出格式。
• 每個輸出都要能被下一步機器化檢查。
• 任何失敗都要能精準定位，不要只回「我再試一次」。
• 狀態要存外部，不要只靠 context 撐場面。

十個數學問題，才是這條線最硬的地方

The company says an internal version of Astra, its “next major model family,” solved ten open problems in math and theoretical computer science.

翻譯一下就是：OpenAI 想證明這不是只會補字的模型，而是能碰到沒有標準答案的問題。十個 open problems 聽起來很大話，但它至少比「benchmark 又高了幾分」有意思，因為 open problem 沒有現成答案可以抄。你得真的推理、真的找路、真的把路徑走通。

我對「AI 解數學」一向很保留，因為標題很容易寫太滿。但這次比較不一樣的地方，是 The Decoder 提到那些論證最後被整理成研究論文，而且證明還經過 Lean formalization。這就不是純嘴砲了。Lean 不是拿來裝飾的，它會直接告訴你哪裡卡住、哪裡少一步、哪裡根本證不過。

如果一個系統能先產生可讀的證明草稿，再把它轉成能被 proof assistant 檢查的形式，這代表它不是只在生成「看起來合理」的東西，而是在生成「可以被驗」的東西。這是我最在意的差別。因為很多團隊現在最愛做的事，就是讓模型自己寫、自己評、自己說自己很棒。那種流程很省事，也很危險。

我比較想要的是這種工作方式：模型負責提出候選解，人類負責挑方向，機器負責驗證。這樣就算模型偶爾亂講，錯誤也會被卡在驗證層，不會一路污染到最後的結論。你如果做技術內容、研究、資料分析，這個原則都一樣適用。

實操寫法很簡單：不要讓模型只交一段答案，改成交「答案 + 假設 + 可驗證依據 + 未解項」。你的驗證層可以是測試、lint、schema、proof assistant，甚至只是另一個更嚴格的 checker。重點是，模型不能自己當裁判。

Lean 不是花招，是把話講死

The model also formalized each proof in Lean, creating machine-checkable certificates of mathematical correctness.

這句我很買單，因為它把整件事從「像不像對」拉到「能不能檢查」。自然語言很會騙人，尤其是模型寫得一板一眼的時候。你看起來會覺得它很懂，但只要一進形式系統，哪裡偷懶、哪裡跳步、哪裡偷換概念，全部現形。

我以前最討厭看那種很會寫摘要的系統，因為它常常把不確定講成確定，把草稿講成結論。Lean 的好處就是不給你這種空間。證明能不能過，就是能不能過。沒有情緒，沒有話術，沒有「大致上應該可以」。這種壓力對高風險輸出很重要。

The Decoder 也提到，OpenAI 的研究員有參與把論證整理成論文、把證明正式化。這點其實很合理。短期內，AI 輔助研究大概都會長這樣：模型出候選，人類補脈絡，人類負責最後的責任和發表品質。這不是退步，這是現階段最務實的分工。

如果你做的是軟體，我會直接借這套。模型寫 code，測試和 static analysis 負責打臉；模型寫資料處理，schema 與 invariant 負責打臉；模型寫流程文件，實際跑一次 pipeline 負責打臉。你會發現，當驗證層夠硬，模型反而更好用，因為它不用假裝自己永遠正確。

• 自然語言拿來起草。
• 形式化工具拿來驗證。
• 人類拿來判斷例外與取捨。

真正的目標，其實是自主研究員

By March 2028, OpenAI wants to have a fully autonomous AI researcher that can run research projects on its own.

這句話一出來，我就知道 Astra 不是終點。它比較像一個中繼站，目標是把系統往「能自己跑研究」推。也就是說，未來的 agent 不只是幫你寫一段 code、查一篇 paper，而是能自己規劃實驗、跑實驗、看結果、修方向，循環好幾輪。

這種系統最難的地方不是會不會想，而是能不能長時間不失控。你要有預算控制、取消機制、觀測面板、失敗回復、進度記錄，還要知道什麼時候該停、什麼時候該重跑、什麼時候該叫人進來接手。沒有這些，所謂「自主」很快就會變成「自走偏」。

我自己現在看 agent 專案，只看三件事：它怎麼存狀態、怎麼驗證、怎麼回滾。這三個答不出來的，我通常不太信。因為長任務不是比誰第一次講得漂亮，是比誰在第 30 步還能維持一致。Astra 這條線把這個現實講得很直白，這點我反而覺得比很多空泛的 AI 故事誠實。

實作上，你可以把 agent runs 當成分散式 job 來設計：每個步驟都有 timeout，每個輸出都有 checkpoint，每個 subtask 都是 idempotent，失敗後能重跑，重跑後不會把舊狀態污染掉。這些東西很工程，但就是這些東西決定系統能不能活過去。

可抄的模板

# Long-running multi-agent workflow template for hard tasks

## Goal
Solve one hard problem over a long horizon without losing state, duplicating work, or trusting unchecked output.

## Roles
- Planner: breaks the problem into bounded subtasks.
- Worker: solves one subtask at a time.
- Critic: checks for drift, contradictions, and missing cases.
- Verifier: validates outputs with tools, tests, proofs, or schema checks.
- Synthesizer: merges only verified results into the final deliverable.

## Operating rules
1. Define the problem in one sentence.
2. List constraints, assumptions, and success criteria.
3. Let the Planner produce 3–7 bounded subtasks.
4. Each Worker returns:
   - result
   - assumptions
   - evidence
   - known gaps
   - verification status
5. Run the Critic on every result.
6. Run the Verifier with an external check.
7. If verification fails, send the task back with the exact failure.
8. Persist every intermediate artifact outside the model context.
9. Only the Synthesizer assembles the final answer.

## Output contract
Subtask:
Assumptions:
Method:
Result:
Evidence:
Known gaps:
Verification status:

## Safety rules
- Never let one agent both propose and approve the same result.
- Never treat fluent explanation as proof.
- Never continue a run if verification fails unresolved.
- Never depend on context alone for long tasks.

## Prompt for the Planner
You are the Planner. Break the problem into small, testable tasks. Do not solve the problem yourself. Return only bounded subtasks with clear success criteria.

## Prompt for the Verifier
You are the Verifier. Check the output against the stated rules, tests, or proof system. If anything fails, report the exact failure and do not soften it.

## Math version
- Replace Verifier with Lean or another proof assistant.
- Require proof sketches before formalization.
- Reject any theorem statement that cannot be compiled.

## Code version
- Replace Verifier with tests, lint, type checks, and static analysis.
- Require reproducible test commands.
- Reject any patch that breaks the build.

## Research version
- Add citation checks, source provenance, and claim tracking.
- Require every claim to map to an evidence artifact.
- Reject any conclusion without a traceable source.

我會直接拿這份骨架去改，不用裝神弄鬼。你做數學就接 Lean，你做 code 就接 tests，你做研究就接 citation checks。骨架一樣，驗證器換掉就好。這才是我覺得 Astra 這條線真正值得抄的地方：它不是叫你相信 agent，而是逼你把 agent 放進一個能被檢查的工作流。

來源致謝：主要依據 The Decoder 原文 與 OpenAI、mathlib4、Lean 的公開資料整理。我加進來的是工作流拆解、實作建議和可直接複製的模板。