來源說明：這篇整理自 David Ondrej 對 Armin Ronacher 的訪談〈Pi Agent dev reveals his Agentic Engineering Workflow〉，並加入我的歸納。Armin 是 Flask、Jinja 與 Rye 等專案的作者，也是 Pi 背後團隊的一員。文中對 Pi、個人工作流與 AI 工程的看法來自這場訪談，不是我的實作成果。觀看原始影片。
結論先行
AI coding 工具很容易把人帶向同一個方向：更多 tools、更多 agents、更長的 context，再把整套環境搬到 cloud。但 Armin Ronacher 的做法幾乎相反。
他偏好一個核心很小、主要依賴 Bash 的 agent；日常開發仍以本機和真實開發環境為主；他也不把 token、commit 或同時運行的 agent 數量當成生產力。
這不是排斥自動化，而是先問一個更基本的問題：
這些自動化是否真的讓軟體更好、成果更大，而且仍然能被人理解與負責？
如果前一篇 Lauren Tan 的重點是「信任要靠環境產生」，Armin 補上的另一半就是：環境不需要複雜才可靠；很多時候，越少的抽象層反而越容易驗證。
Minimal harness：讓模型使用它已經熟悉的電腦
Pi 的核心設計很簡單。它不替每個操作建立專用工具，而是讓模型大量使用 Bash、rg 與既有 CLI。
例如，搜尋程式碼不需要一個特別的「code search agent tool」：
rg "createSession" src/ tests/需要縮小結果時，可以直接組合 Unix pipeline：
rg "createSession" src/ \
| cut -d: -f1 \
| sort -u \
| head -n 20這種做法看起來樸素，卻有幾個實際優勢：
- 模型的訓練資料裡已經有大量 shell、Git、Linux 與常見 CLI 範例。
- 中間資料可以先在 process 裡篩選，不必全部放進 context。
- 指令能被工程師直接重跑，錯誤也比較容易定位。
- 不需要為每一項能力設計、維護與解釋新的 tool schema。
- 一個通用工具可以被組合成許多尚未預想到的工作流。
這裡的 minimal 不是功能少，而是把功能留在模型已經會操作的系統裡。Harness 的責任是提供可靠的執行環境，不是搶著替模型抽象所有事情。
可擴充，不等於預先塞滿功能
Pi 早期受到注意的另一個原因，是使用者可以把它改造成自己的工具。核心維持小，特殊需求再由 extension 或 plugin 補上。
這和「先安裝所有 MCP、skills 與 subagents」是不同思路。每多一項工具，都會帶來成本：
| 增加的能力 | 同時增加的成本 |
|---|---|
| 更多 tool definition | 更大的 context 與選擇空間 |
| 更多預設 workflow | 更高的維護與衝突機率 |
| 更多平台功能 | 更強的供應商綁定 |
| 更多 agent role | 更多協調、整合與注意力成本 |
比較合理的順序，是先從通用能力開始。某個工作反覆出現、步驟已穩定，而且確實需要相同限制時，再把它固化成 skill 或 extension。
flowchart LR
T[具體任務] --> B[通用工具<br/>Bash · Git · CLI]
B --> O{是否反覆出現？}
O -->|否| D[完成一次性工作]
O -->|是| S[整理穩定步驟與限制]
S --> E[封裝成 skill / extension]
E --> V[持續驗證與刪除過時能力]Skill 應該是從成功的實務長出來，而不是先建立一整套看起來完整的組織圖。
他的工作流沒有 Software Factory 那麼戲劇化
Armin 坦白說，他沒有成功建立一座自動處理 issue 的 software factory。他目前的工程方式仍然相當傳統：
- Agent 主要在本機、實際 codebase 所在的環境執行。
- 需要長時間運行的工作，可以交給一台透過 SSH 存取的 Linux 主機。
- GitHub Actions 裡只有部分自動化。
- 很多時間不是生成程式碼，而是和 agent 一起調查 repository、理解問題並決定系統應該怎麼運作。
- 實作完成後，仍然在真實開發環境裡測試。
這種做法不會產生驚人的 agent 數量，卻很接近多數複雜產品的真實工程：問題通常不是少打一點 code，而是先理解既有系統、隱藏限制和正確行為。
Agent 可以加速 investigation 和 implementation，但不能替工程師決定產品應該有什麼語意。
Local 或 Cloud，先看環境是不是真的
Cloud agent 的優點很明顯：容易平行化、可以長時間執行，也不占用本機資源。但 Armin 目前仍偏向 local-first，原因不是理念，而是執行品質。
他在訪談中提到一個很有代表性的情況：某個 cloud 環境看起來能跑 database tests，實際檢查後才發現 PostgreSQL 根本沒有啟動，相關行為全被 mock 掉了。
這說明一個常被忽略的差異：
測試指令回傳成功
≠
系統在真實依賴下能正常運作選擇執行環境時，應該檢查的不是「local 還是 cloud」這個標籤，而是：
| 問題 | Local 常見狀況 | Cloud 常見狀況 |
|---|---|---|
| 測試速度 | 已有 cache 與原生環境，通常較快 | 可能需要重新安裝與啟動 |
| 真實依賴 | Database、queue、service 已在本機 | 容易缺少服務或以 mock 取代 |
| 平行能力 | 受 CPU、RAM、port 與本機服務限制 | 較容易建立隔離環境 |
| 資料取得 | 開發資料已存在 | 需要安全地複製或建立測試資料 |
| 可重現性 | 容易累積個人機器狀態 | Image 固定時通常較好 |
複雜專案真正需要的，是能快速建立多套完整、隔離、可重現的開發環境。Cloud 最終很可能更適合這件事，但前提是它真的能啟動 PostgreSQL、Kafka、queue 與其他服務，而不只是讓測試畫面變綠。
Durable state 比神祕的「長期記憶」重要
Armin 對 agent memory 的說法相對保留。他更關心的是狀態能不能被可靠保存與操作：
- Session 能否暫停後繼續？
- 能否跨機器或模型供應商移動？
- Server-side compaction 後，重要資訊是否還能取回？
- Agent 建立的資料，人能否查看、修改與刪除？
- 任務狀態是否存在明確檔案或資料庫，而不是只在聊天紀錄裡？
這也解釋了 Markdown、JSON、Git 與 Unix pipeline 為何在 agent 時代重新變得重要。它們不是最華麗的技術，卻同時具備三個條件：人看得懂、機器容易操作、狀態可以保存。
與其期待模型神奇地「記住一切」，更可靠的做法是讓關鍵狀態有清楚的落點。
Chat 只是暫時的介面
目前多數 agent 都被包在 terminal 或 chat 裡，但許多問題原本就不適合用對話處理。
如果 agent 負責管理智慧家庭，只回傳文字並不合理；它應該能顯示房間、裝置狀態、感測數據與控制介面。如果 agent 正在調查 production incident，也應該能提供 timeline、服務拓樸、trace 與可以操作的篩選器。
這不一定需要新的模型突破。真正欠缺的可能仍然是傳統系統問題：
- State management
- Durable session
- Component library
- Database access
- Permission boundary
- Human 與 agent 共享的 representation
未來的 agent interface 不只要讓模型能工作，也要讓人能理解模型正在操作什麼。
人仍需要理解，因為責任不能交給模型
訪談中談到銀行等高責任系統時，Armin 的立場很直接：出問題後，組織不能把責任推給模型。
只要最後仍然由人承擔後果，人就一定會要求：
- 看得懂系統現在的狀態；
- 知道變更從哪裡來；
- 能重現 agent 的驗證；
- 能追蹤決策與輸入資料；
- 發生問題時可以定位和修正。
因此「未來只有 agent 讀得懂的 binary 或 machine-generated system」在可見的時間內並不實際。即使實作由 agent 完成，架構、狀態與操作證據仍然需要對人 legible。
這也是 agent-friendly codebase 和 human-friendly codebase 高度重疊的原因：清楚的 boundary、一致的命名、簡單的資料流與可重現的指令，兩邊都受益。
不要用 Agent 數量證明生產力
Armin 對目前的生產力敘事保持懷疑。公司可以很容易展示 token usage、commit 數量或同時運行的 agent 數，但這些數字未必反映產品與商業結果。
大量使用 agent 也會增加新的成本：模型訂閱、雲端執行、review queue、安全檢查、驗證基礎設施，以及人在多條工作流之間切換的注意力。
因此更值得衡量的是：
| 不足以代表價值 | 比較接近真實成果 |
|---|---|
| Token consumption | 完成一項有效成果的總成本 |
| Commit / PR count | Lead time、revert 與 regression rate |
| 同時運行的 agents | 人工協調與 review 時間 |
| Generated lines of code | 使用者問題是否被解決 |
| 自動化覆蓋率 | 系統可靠度與維護成本 |
程式碼變便宜，不代表值得維護的軟體也同樣變便宜。
Agent 正在改變技術選型
過去有些技術方案更正確，卻因為學習和操作成本太高而不常被採用。Agent 可能改變這個平衡。
Armin 提到 Linux、NixOS、Rust、複雜資料庫與 Kafka：它們對人可能有較高的入門成本，但 agent 能從大量公開文件和範例裡找到操作方式。當 agent 能承擔安裝、設定與樣板工作後，團隊可能更願意選擇原本比較複雜、但長期更合適的方案。
相反地，文件不足、缺乏 CLI、自動化介面不穩定，或很少出現在公開資料裡的產品，可能逐漸處於劣勢。
未來選擇工具時，除了 developer experience，還要評估 agent experience：
- 文件是否清楚且可以被搜尋？
- CLI 是否穩定、可組合並有合理 exit code？
- 錯誤訊息是否提供可採取的下一步？
- 狀態是否能用文字或結構化格式檢查？
- 完整流程能否在隔離環境裡重現？
我的整理：先把單一 loop 做真，再談 factory
Armin 的觀點不是「只准在本機使用一個 agent」。他真正反對的是，在還不知道單一工作流是否可靠、是否產生價值時，就用 agent 數量和 token consumption 製造進步的錯覺。
我會把這場訪談轉成下面的實作順序：
- 先讓一個 agent 在真實環境完成一個 bounded task。
- 使用它已熟悉的 Bash、Git 與專案 CLI，避免不必要的抽象。
- 讓測試接觸真實依賴，不把全套 mock 當成完成證據。
- 把重要狀態存進檔案、Git 或資料庫，不只留在聊天 context。
- 工作反覆出現後，才封裝成 skill、extension 或 automation。
- 單一 loop 可重現後，才考慮 cloud、parallel agents 與 software factory。
- 最後用產品結果、可靠度與總成本評估，不用產量替代價值。
Lauren Tan 展示的是 verification infrastructure 建好後可以走多遠；Armin Ronacher 提醒我們，在走到那裡之前，必須先確定環境是真實的、系統是可理解的，而且增加的複雜度確實值得。
來源
- David Ondrej 訪談 Armin Ronacher，Pi Agent dev reveals his Agentic Engineering Workflow，2026。