---
schemaVersion: 1
slug: mp-179-20260316-daniel-mac8-symphony-manage-work-not-agents
ticketId: MP-179
lang: zh-tw
title: 不再管理 Agent，而是管理「工作」：開源版 Symphony 的自動化工作流
summary: "@daniel_mac8 分享一個開源 Elixir 實作：在 Linear 建立 issue 並切到 in progress 後，Symphony 會在專屬 Codex workspace 接手，Codex 也會即時回寫狀態。原作者認為，這代表開發正往更高的抽象層移動。"
originalDate: 2026-03-16
translatedDate: 2026-03-17
source: "@daniel_mac8 on X"
sourceUrl: https://x.com/daniel_mac8/status/2033623706120212522
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-179-20260316-daniel-mac8-symphony-manage-work-not-agents
status: published
replacementTicketId: null
replacementUrl: null
---

# 不再管理 Agent，而是管理「工作」：開源版 Symphony 的自動化工作流

> **來源:** [@daniel\_mac8 on X](https://x.com/daniel_mac8/status/2033623706120212522)

你有沒有過那種經驗：你是組長，底下帶了五個人，結果你每天花最多時間的不是做事，而是「分配事情」？催 A 交進度、幫 B 排優先順序、跟 C 確認他到底有沒有在做 —— 最後一天結束，你自己一行 code 都沒寫，但累得要死。

現在把那五個人換成 AI [Agent](https://gu-log.vercel.app/glossary#agent)。問題一模一樣。

@daniel\_mac8 (Dan McAteer) 最近在 X 上丟出一個觀點，大意是：像 OpenAI 的 Symphony 這種 agent orchestrator 確實是未來 —— 但等等，這個「未來」根本不用等，現在就在發生了。他直接秀了一個開源的 [Elixir](https://gu-log.vercel.app/glossary#elixir) 實作給你看。

> **Mogu 認真說：**
>
> 老實說，每次有人做 agent orchestrator，我都會想到那個經典畫面：你為了不想自己洗碗，花了三小時研究洗碗機的安裝手冊。Symphony 也是這個味道 —— OpenAI 的解法是「用一個 AI 來管你的 AI」，聽起來合理，做起來就是套娃。不過至少 OpenAI 把框架開源了，不像某些公司只發 blog post 然後叫你 waitlist (╯°□°)╯

## 所以這東西到底怎麼動的？

流程其實簡單到有點可怕：

你在 [Linear](https://gu-log.vercel.app/glossary#linear) 裡開一張 issue。可以搭配 Linear [MCP](https://gu-log.vercel.app/glossary#mcp) 來開，也可以手動開，隨便你。然後呢？你把那張 issue 的狀態從 “Todo” 拉到 “In Progress”。

就這樣。你的工作結束了。

接下來，Symphony 偵測到狀態變更，自動在一個專屬的 [Codex](https://gu-log.vercel.app/glossary#codex) workspace 裡把這張 issue 打開，Codex 開始幹活。更離譜的是，Codex 做到哪裡了、卡住了沒有、完成了沒有，它會自己回 Linear 更新狀態。

你不用催它。你不用問它「做好了嗎？」它自己會回報 (￣▽￣)／

> **Mogu 歪樓一下：**
>
> 這個流程的精髓在於：issue 的狀態本身就是觸發器。不是你去下指令叫 agent 動，而是你動了看板上的卡片，agent 自己跳出來接手。這就像你把髒盤子放進洗碗機、按下開始 —— 你不需要站在旁邊看它洗，更不需要每洗一個盤子就去確認一次。如果你還在手動跟 agent 說「嘿，去做這個」，那你用的不是 orchestrator，你用的是一個比較貴的 chatbot ┐(￣ヘ￣)┌

## 但問題來了：你真的不用管了嗎？

原作者的論點很大膽：他說你不再是在「管理 agents」，你是在「管理 work」。軟體開發正在往上爬一個抽象層 —— 你不再需要知道具體的實作細節，你只需要把想法講清楚、把規格寫具體。用他的原話：“you are an idea man now.”

這句話乍聽很爽，但仔細想想，有點像在說「你以後只要出嘴巴就好」。

> **Mogu 認真說：**
>
> 「You are an idea man now」—— 好，但問題是：當所有人都變成 idea man，誰來判斷哪個 idea 該做？現在的瓶頸從「寫 code 的速度」變成了「想清楚要做什麼的速度」。這其實不是降低了門檻，而是把門檻從技術能力搬到了思考能力跟溝通能力上。對某些人來說，這可能更難 (⌐■\_■)

## 冷靜一下：這目前還是個 demo

話說回來，我們得保持清醒。你知道學期末的時候，教授在課堂上 demo 一個漂亮的演算法，跑出來結果完美，全班鼓掌 —— 然後你回家自己跑，資料集一換就整個炸開？

對，就是那種感覺。

原作者展示的這套流程確實跑起來了，而且是真的有 code 的開源實作，不是 vaporware。但從「教授的 demo」到「期末考能用」之間，有一堆沒人提的問題藏在細節裡。

比如說：你的 issue 描述寫得夠清楚嗎？大部分工程師寫的 issue，連人類同事讀了都要來回問三次才知道到底要做什麼，你覺得 AI 能直接看懂？再來，Codex 卡住的時候怎麼辦？它不會跑來你座位旁邊拍你肩膀說「欸，這個 API 的 auth token 要去哪裡拿」。更可怕的是 —— 如果它做出來的東西是垃圾，但它自己信心滿滿地 mark 成 done 了呢？

## 延伸閱讀

- [GP-110: 把 Codex 當隊友而不是工具人：10 個讓你效率翻倍的 Best Practices](https://gu-log.vercel.app/posts/gp-110-20260310-derrickcchoi-codex-10-best-practices/)
- [GP-120: Claude Code 與 Codex：AI Agent CLI 的底層架構差異與設定指南](https://gu-log.vercel.app/posts/gp-120-20260320-nyk-builderz-claude-code-codex-ai-agent-cli/)
- [GP-98: Agent Harness 工程：OpenAI 如何用 Codex 達成零手寫百萬行程式碼](https://gu-log.vercel.app/posts/gp-98-20260303-openai-harness-engineering/)

> **Mogu 畫重點：**
>
> 自動化領域有一條鐵律，老到長出青苔了但每次都對：「垃圾進，垃圾出。」中間多一層 orchestrator 不會讓這條規則消失，只會讓你更晚發現垃圾是在哪一步被製造出來的。不過公平講一句 —— 原作者是真的寫了 code、跑了 demo、開了源。在 2026 年這個「slide deck 創業」和「概念影片圈錢」的年代，光是這一點就值得尊重了 ╰(°▽°)╯

## 所以，我們到底學到什麼？

回到最一開始那個帶五個人的組長。Symphony 做的事情，就是把你從「每天催進度催到懷疑人生的組長」升級成「寫需求的 PM」。你還是要管事，只是你管的東西變了 —— 從「這個人到底有沒有在做」變成了「我的需求有沒有寫到連 AI 都看得懂」。

說穿了，這整個 agent orchestration 的故事，核心就一句話：你以為省掉的是「管人」的時間，其實只是把時間從「管人」搬到了「把話說清楚」。

對某些工程師來說，後者可能比寫 code 還難 ┐(￣ヘ￣)┌