標籤: 工作流自動化

  • 用 Hindsight 幫 Agent 裝上長期記憶

    用 Hindsight 幫 Agent 裝上長期記憶

    📌 本文重點

    • Hindsight 專門為 AI Agent 管理長期記憶
    • 以「事件」形式記錄並可學習式檢索過往經驗
    • 易於接入現有 LLM / Agent 框架,當天可跑起最小範例

    Hindsight 是一個專門幫 AI Agent 管理「長期記憶」的開源 Python 套件,解決了多步驟任務中 Agent 只記得當下對話、無法利用過去經驗的問題。

    Hindsight GitHub 專案連結 →


    先搞懂:為什麼 Agent 需要「可回顧的記憶」?

    多數你現在在用的 LLM / Agent,有這些共同限制:

    • 只能看「當前對話」或有限上下文
    • 過去做過什麼任務、遇過什麼坑,下次完全重來
    • 多步驟工作流中,很難根據歷史表現調整策略

    要讓 Agent 能像同事一樣「越用越懂你」,至少要有三件事:

    1. 能記錄事件:例如「2024-10-01 幫客戶 A 解過帳單問題」
    2. 能在需要時查回來:遇到類似情境,自動翻舊帳
    3. 能影響決策:不是只顯示給人看,而是餵回 LLM 讓它改變下一步行動

    💡 關鍵: 要讓 Agent 真的「越用越聰明」,關鍵不在模型尺寸,而在是否能把過去經驗結構化成可回顧、可檢索、可影響決策的記憶。

    Hindsight 做的就是這三件事,而且只專注「記憶系統」,讓你可以接到任何現有的 LLM、Agent 框架上。


    核心功能:Hindsight 怎麼幫 Agent 建記憶?

    1. 事件式記憶:把「一次任務」變成可回顧的事件

    在 Hindsight 裡,記憶不是一堆散亂的向量,而是事件(events),每個事件通常包含:

    • 發生時間
    • 觸發條件(例如:收到某種 user query)
    • 執行過程(Agent 做了什麼)
    • 結果與評價(成功 / 失敗、為什麼)

    你可以在 Agent 每次完成一個任務後,把關鍵資訊整理成事件,交給 Hindsight 存起來。

    你可以立刻做的:

    • 幫你的 Agent 設計一個 log_event() 步驟:只要任務完成,就把「問題、做法、結果」丟進 Hindsight。

    2. 會學習的檢索:不只找相似內容,而是找「有幫助的經驗」

    Hindsight 核心不只是用 embedding 搜索相似文本,而是把「哪種過去經驗對決策有幫助」也當成學習對象。

    實際效果:

    • 同樣是「退款」相關的客服事件,Hindsight 會偏好之前成功解決、客戶滿意的案例
    • 對於多代理系統,可以找到「哪個 Agent 的處理方法比較穩定」

    💡 關鍵: 檢索不只看語義相似,而是綜合「相似度 + 成功率」來排序,讓 Agent 優先參考過去表現最好的一批經驗。

    你可以立刻做的:

    • 在存事件時,多存一個 outcome_score(例如 1–5 分)
    • 在檢索時,讓 Hindsight 優先回傳高分事件,給 LLM 當「參考案例」

    3. 影響決策:記憶不是附註,而是 prompt 的一部分

    有了事件和檢索之後,真正關鍵是:怎麼把這些記憶餵回 LLM,讓它改變行為?

    典型流程會長這樣:

    1. User 給一個新請求
    2. Agent 先呼叫 Hindsight:get_relevant_events(query)
    3. 把返回的 3–5 個關鍵事件,以「過往經驗摘要」的形式插入到 prompt
    4. 再請 LLM 規劃接下來的動作

    你可以立刻做的:

    • 修改你現在的 Agent pipeline,在「規劃步驟」前加一個「查記憶 + 摘要」步驟,再把摘要一起丟給 LLM。

    實際場景示範

    場景 1:幫客服 Bot 建「過去對話記憶」

    目標:讓客服 Bot 知道「這個客戶以前問過什麼」,以及「過去怎麼處理比較有效」。

    你可以這樣做:

    1. 每次對話結束,存一個事件
    2. customer_id
    3. 詢問類型(例如:帳單、退款、技術問題)
    4. 處理流程摘要
    5. 客戶滿意度(CSAT 分數 / 是否再次來問同樣問題)

    6. 下次同一客戶來問時

    7. 先用 customer_id + 問題類型 向 Hindsight 查事件
    8. 找到過去處理成功的對話摘要
    9. 在 prompt 裡加入:「這位客戶過去有過以下互動紀錄……請避免重複問相同問題,並延續既有處理方式。」

    效果:同一個客戶不會每次都被當成新用戶,Bot 也能避免重複詢問背景資訊。


    場景 2:為個人工作助理記錄執行過的任務

    目標:讓你的個人 Agent 記得:

    • 以前是怎麼幫你整理週報
    • 哪種摘要格式你最常保留
    • 哪些任務你曾要求「不要再自動做」

    做法:

    1. 每次 Agent 幫你完成一個任務(整理文件、寫 email、產報告),就記一個事件:
    2. 任務描述
    3. 輸入資料類型
    4. 產出格式
    5. 你是否接受 / 有何修改建議

    6. 下次 Agent 準備寫類似的東西時:

    7. 先對「任務描述」查 Hindsight
    8. 把過去你最滿意的 1–2 次產出摘要給 LLM
    9. 在 prompt 裡明確說:「這是使用者過去最滿意的範例,請盡量維持相同風格與結構。」

    效果:Agent 會逐漸學會你的偏好,不需要每次都重複教它「我喜歡先結論再細節」「報表用 Markdown」。


    Hindsight 跟其他 Agent 工具怎麼搭?

    市面上有不少 Agent 工具,但 Hindsight 專注在「記憶」,可以跟它們搭配使用:

    名稱 核心功能 免費方案 適合誰
    Hindsight Agent 長期記憶、事件存取與學習式檢索(Python) 開源、免費 想為自家 Agent 加「長記憶」的開發者
    Plane Agents 把工作指派給多個 AI Agent,像管理團隊成員 有免費起步方案(雲端服務) 想快速用 Agent 做任務協作的團隊 PM、營運人員
    Univer 將試算表、文件、簡報等辦公工具整合給 Agent 使用 開源、免費 想在辦公流程中導入 Agent 的企業開發者
    Harness SDK 建立可上線的 Agent 服務(部署、監控、管理) 開源、免費 要把 Agent 放到正式產品中的工程團隊

    實用搭配例子:

    • 用 Harness SDK 管理整個 Agent 服務 → 中間接上 Hindsight 當記憶層 → 再讓 Agent 去操作 Univer 的文件或試算表。

    💡 關鍵: 把 Hindsight 當成「記憶模組」插在現有架構中,而不是重新打造一整套 Agent 系統,可以在不推翻現有產品的情況下快速升級 Agent 智能。


    怎麼開始:當天就跑起 Hindsight 的最小範例

    1. 基本環境需求

    • Python 3.9+(建議 3.10 以上)
    • 有一個可用的 LLM:
    • 雲端(如 OpenAI、Anthropic、Azure OpenAI)
    • 或本地模型(透過 Ollama / vLLM 等)

    建議先在乾淨的 virtualenv 或 conda 環境中安裝。

    python -m venv venv
    source venv/bin/activate  # Windows 改用 venv\Scripts\activate
    

    2. 安裝 Hindsight

    pip install hindsight-agent-memory
    

    (套件名稱以 GitHub README 為準,若有更新以官方說明為主。)


    3. 建立一個最小記憶範例

    下面是簡化示意程式碼,展示「存事件 → 查事件 → 餵給 LLM」的流程:

    from hindsight import HindsightClient  # 依實際 API 名稱調整
    
    # 1. 初始化記憶客戶端
    memory = HindsightClient(storage_path="./memory_db")
    
    # 2. 存一個事件(例如:客服成功處理退款)
    memory.log_event({
        "type": "customer_support",
        "customer_id": "A123",
        "issue": "信用卡重複扣款",
        "resolution": "協助申請退款並說明處理時程",
        "outcome_score": 5
    })
    
    # 3. 遇到新問題時,查詢相關事件
    query = {
        "type": "customer_support",
        "issue": "信用卡扣款有問題",
    }
    
    relevant_events = memory.search(query, top_k=3)
    
    # 4. 把記憶整理成文字,餵給你的 LLM
    context = "\n".join([
        f"過去案例:{e['issue']} → {e['resolution']} (評分: {e['outcome_score']})"
        for e in relevant_events
    ])
    
    prompt = f"""你是一位客服專員。
    以下是過去成功處理的相關案例:
    {context}
    
    現在有一位客戶說:"信用卡兩次扣款",請參考上述案例給出處理建議。
    """
    
    # 接下來呼叫你自己的 LLM 客戶端,如 openai.ChatCompletion.create(...)
    

    你可以把這段整合到任何 Agent 框架裡(LangChain、LlamaIndex、自寫的 pipeline 都可以):

    • 在「任務完成」hook 中呼叫 log_event
    • 在「規劃下一步」前呼叫 search,將結果加入 prompt

    4. 接到現有 Agent / LLM 框架的實作提示

    • 接 OpenAI / Anthropic:
    • Hindsight 不管你用哪一家 LLM,只要能接收 string prompt 就行
    • 把 context 直接放到 system 或 assistant 提示中

    • 接 LangChain Agent:

    • 把 Hindsight 包成一個 Tool(例如 MemorySearchTool)
    • 在 agent 的工具列表中加入這個 tool,讓 LLM 主動決定什麼時候查記憶

    • 接多代理系統(像 Plane Agents / Harness SDK):

    • 為每個 Agent 建獨立記憶空間(namespace)
    • 或共用一個記憶庫,但在事件中標註 agent_id,檢索時可指定篩選條件

    適合誰用?

    如果你符合以下任一條件,Hindsight 值得你今天就動手試:

    • 你正在做 多步驟、自動化工作流,但 Agent 常常「忘記事情重來」
    • 你有自己的 客服 / 助理 Bot,希望它能記得使用者與過去處理方式
    • 你在建 多代理系統(multi-agent),需要一個共享的「經驗資料庫」

    從最小步驟開始:

    1. 在專案裡裝好 Hindsight
    2. 先挑一個任務類型,開始 log_event
    3. 為這個任務加上「查記憶 → 摘要 → 餵給 LLM」這三步

    等你跑過 1–2 個星期,你會開始看到 Agent 的回答風格、處理策略真的「記住」了過去。

    🚀 你現在可以做的事

    • 到 Hindsight GitHub 專案 把 README 快速掃一遍,確認安裝方式與 API 名稱
    • 在現有一個 Agent 專案中,新增 log_event() 與 search() 兩個整合點,先對單一任務類型啟用記憶
    • 用 top_k=3–5 的事件摘要實驗不同 prompt 插入方式(放 system 或前置「過往案例」區塊),比較回覆品質差異
  • 用 Claude Corps 組一支虛擬專案團隊

    用 Claude Corps 組一支虛擬專案團隊

    📌 本文重點

    • Claude Corps 把單一 Claude 變成多角色協作團隊
    • 透過 rubric 審稿 Agent,大幅提升輸出品質
    • 先從「主 Agent + 審稿 Agent」的小流程開始實驗

    一句話定位:Claude Corps 就是「多代理版 Claude 工作流引擎」——讓多個 AI 角色分工協作、互相審查,幫你跑完整個專案流程,而不只是回一個答案。

    👉 官方介紹文:https://www.anthropic.com/news/claude-corps
    👉 rubric grading 實驗文:https://pub.towardsai.net/i-added-one-agent-to-my-claude-setup-and-output-quality-jumped-10-overnight-6e5947a62141


    核心功能:把「一個 Claude」變成「一個團隊」

    1. 多角色分工:策略 / 執行 / 審查

    Claude Corps 的核心概念是:你先設計好幾個固定角色,然後讓他們一起跑流程,而不是一個大 prompt 想包山包海。

    常見三種角色:

    • 策略 Agent(Strategist):負責想方向、列計畫、拆步驟。
    • 執行 Agent(Executor):根據計畫產出具體內容(文案、規格、程式碼)。
    • 審查 Agent(Reviewer):按照事先定好的 rubric(評分標準)檢查、打分、要求重寫。

    你可以從自己現有流程開始,照這三個角色拆:

    行動建議:拿你最近一個要反覆修改的任務(例如長文案撰寫、PRD 撰寫),先在筆記裡寫下:
    – 「策略」要產出什麼?
    – 「執行」要交付什麼?
    – 「審查」要檢查什麼?

    後面我們會把這三塊直接翻成多代理設定。


    2. 長流程協作:從需求到結果的「接力棒」

    Claude Corps 的運作方式,可以理解為:

    1. 每個 Agent 有自己的「角色設定 + 任務說明」。
    2. 任務在 Agent 之間有順序地傳遞(像專案流程),每一步可以讀取前面 Agent 的輸出。
    3. 某些 Agent 還可以「退回修改」——例如 Reviewer 要求 Executor 重寫。

    這讓長流程任務可以被拆成清楚的階段:

    • 不再是「一個超長 prompt」,而是一組可重複、可維護的流程。
    • 你可以只換掉「執行 Agent」,就測試不同寫作風格或程式風格。

    行動建議:選一個你每週都會做的流程(例如「寫週報」或「做競品整理」),用 3–5 個步驟寫成清單,想像每一步由一位 Agent 負責,準備在工具裡實作成 workflow。


    3. 內建 rubric grading 迴圈:讓 AI 自己打分再重寫

    在 Towards AI 那篇案例中,作者只做了一件事:

    在原本的 Claude 產生流程後面,多加一個「評分 Agent」,用 rubric grading 機制打分,如果分數太低就要求重寫。

    💡 關鍵: 只多加一個評分 Agent,就能在既有流程上建立「自評+重寫」迴圈,顯著提升輸出品質。

    關鍵是「分離」:

    • 產出內容的是 主 Agent。
    • 負責打分與給修改建議的是 評分 Agent。

    這樣可以:

    • 降低主 Agent 自己「自賣自誇」的偏差。
    • 讓評分標準可以獨立調整、版本管理。

    行動建議:想一個你最在意品質的輸出(例如「產品頁文案」或「技術文件」),列出 5 條評分標準(如結構、清晰度、錯字、符合品牌語氣等),後面我們會把它翻成 rubric grading Agent。


    實際案例:三種你可以馬上想像的流程

    案例 1:行銷活動全流程

    用 Claude Corps,你可以把一個行銷活動拆成:

    1. 策略 Agent:
    2. 根據產品、目標客群、預算,產出「活動目標 + 訊息主軸 + 渠道組合」。
    3. 內容 Agent:
    4. 依策略生成:EDM 內容、社群貼文、廣告標題、LP 架構。
    5. 審查 Agent:
    6. 根據品牌語氣、禁用詞清單、法規注意事項打分。
    7. 如果某項低於 7/10,要求內容 Agent 重寫該段。

    💡 關鍵: 先用簡單門檻(如 7/10)判斷是否重寫,可以在不大改流程下快速導入品質控管。

    下一步你可以做:先把你現有的一個活動企劃書丟給 Claude,請它幫你拆成「策略 / 內容 / 審查」三階段,當作之後設定多代理流程的草稿。


    案例 2:自動化研究彙整

    研究型工作(PM、顧問、投資研究)非常適合用多代理拆分:

    1. 搜尋 Agent:
    2. 根據關鍵字,抓資料來源(論文標題、新聞、公司年報等摘要)。
    3. 整理 Agent:
    4. 把零散資料整理成結構化表格(時間、來源、關鍵發現)。
    5. 分析 Agent:
    6. 做趨勢整理、異常點分析、風險與機會列表。
    7. 審查 Agent:
    8. 檢查引用是否明確、有無過度延伸推論。

    下一步你可以做:拿近期一份你自己做的研究報告,請 Claude 列出「如果讓三個 AI 分工,你會分給誰做什麼」,你就有一個可以搬進 Corps 的流程骨架。


    案例 3:產品規格 → 需求分解 → 工單產生

    對產品 / 工程團隊來說,最實用的一個模式是:

    1. PRD Agent:
    2. 輸入你草寫的產品想法,產出結構化 PRD(目標、用例、成功指標)。
    3. 需求分解 Agent:
    4. 把 PRD 拆成功能需求、技術任務、依賴關係。
    5. 工單 Agent:
    6. 依照 Jira / Linear 格式,產生工單標題、描述、驗收標準。
    7. 審查 Agent:
    8. 檢查:需求是否有模糊詞、是否有驗收方式、是否與目標對齊。

    下一步你可以做:從你現有的一張 Jira 票開始,請 Claude 幫你「反推」:如果這張票是 AI 產的,上游的 PRD 會長怎樣?然後再用多代理方式讓 AI 自行從 PRD 走到工單。


    如何在現有 Claude 專案中,加一個「審稿/評分 Agent」

    這裡給你一個 最小可行實驗(MVP):不需要整套 Claude Corps,只要你現在有在程式裡呼叫 Claude API,就可以加上「rubric grading 迴圈」。

    假設你目前有一個簡單的 Python 流程:

    from anthropic import Anthropic
    
    client = Anthropic(api_key="YOUR_API_KEY")
    
    user_task = "請寫一篇 500 字的產品介紹文案,產品是…"
    
    # 原本:直接讓 Claude 產出
    resp = client.messages.create(
        model="claude-3-5-sonnet-20240620",
        max_tokens=1200,
        messages=[{"role": "user", "content": user_task}],
    )
    original_output = resp.content[0].text
    print(original_output)
    

    第一步:定義你的 rubric(評分標準)

    先用文字列出你在意的點,例如:

    RUBRIC = """
    你是嚴格的審稿員,負責評估一段文案品質。
    
    請依照以下四個面向,每項 1–10 分評分,並給出具體修改建議:
    1. 結構清晰度(是否有明確開頭、重點段落、結尾)
    2. 語言流暢度(是否口語自然、無明顯錯字)
    3. 說服力(是否清楚說明產品價值,舉例是否具體)
    4. 品牌一致性(是否符合「專業、友善、不浮誇」的語氣)
    
    輸出格式:
    - scores: JSON 格式,包含四項分數與總分 total
    - suggestions: 對每一項給出具體修改建議
    """
    

    第二步:新增一個評分 Agent 呼叫

    def grade_output(text: str):
        resp = client.messages.create(
            model="claude-3-5-sonnet-20240620",
            max_tokens=800,
            messages=[
                {"role": "system", "content": RUBRIC},
                {
                    "role": "user",
                    "content": f"請評分以下文案:\n\n{text}",
                },
            ],
        )
        return resp.content[0].text
    

    你可以先直接 print(grade_output(original_output)) 看看評分長怎樣,再決定要怎麼解析。


    第三步:加上「低分就重寫」的迴圈

    以下是一個簡化版迴圈(概念接近 Towards AI 文中那個 80 行示範):

    import json
    
    MIN_SCORE = 32  # 四項各 8 分的總分門檻
    MAX_TRIES = 3
    
    current_output = original_output
    
    for i in range(MAX_TRIES):
        grading_raw = grade_output(current_output)
        print("=== Grading round", i+1, "===")
        print(grading_raw)
    
        # 嘗試從回覆中抓 JSON scores
        try:
            start = grading_raw.index("{")
            end = grading_raw.rindex("}") + 1
            scores = json.loads(grading_raw[start:end])
        except Exception:
            break
    
        if scores.get("total", 0) >= MIN_SCORE:
            break
    
        # 分數不夠,帶著建議重寫
        rewrite_prompt = f"""
    你剛剛寫了一段文案,得到以下評分與建議:
    
    {grading_raw}
    
    請在保留核心資訊的前提下,依照建議,完整重寫文案。
    """
        resp = client.messages.create(
            model="claude-3-5-sonnet-20240620",
            max_tokens=1200,
            messages=[
                {"role": "system", "content": "你是專業文案撰寫人員。"},
                {"role": "user", "content": rewrite_prompt},
            ],
        )
        current_output = resp.content[0].text
    
    print("=== 最終文案 ===")
    print(current_output)
    

    做到這裡,你就已經擁有:

    • 一個主 Agent(寫文案)
    • 一個評分 Agent(打分 + 給建議)
    • 一個簡單的「多輪改善」迴圈

    💡 關鍵: 設定 MIN_SCORE 與 MAX_TRIES,能在成本可控的情況下,讓文案經過多輪自動優化。

    下一步你可以做:
    – 把 RUBRIC 換成「技術文件」或「教學文章」版本。
    – 把同樣的架構套到「程式碼審查」:改成檢查可讀性、錯誤風險、測試覆蓋建議。


    適合誰用:先把自己當「專案經理」,再讓 AI 來當團隊

    以下幾種工作型態,特別適合導入 Claude Corps 或至少導入「審稿 Agent」:

    • 行銷 / 內容團隊:需要大量產出文案,但又要維持品牌一致、避免錯漏。
    • 產品 / UX 團隊:PRD、用戶故事、需求拆解到工單,流程清楚但繁瑣。
    • 顧問 / 研究 / 投資分析:資料搜集、整理、分析、報告撰寫有明確步驟。
    • 單人創業者 / 自媒體:你一個人要扮演整個團隊,用多代理來「外包」給 AI。

    建議起手式:
    – 不要一開始就設計 10 個 Agent。
    – 先從「主 Agent + 審稿 Agent」開始,把最痛的一個環節自動化。


    怎麼開始:從一個 rubric Agent 起步

    目前 Claude Corps 的完整能力會陸續擴展,不過你可以立刻從現有 Claude API 或 Claude 網頁版開始實驗:

    1. 如果你會寫一點程式:
    2. 申請 Anthropic API Key。
    3. 建一個最小專案(就像上面的 Python 範例),先讓「主 Agent + 評分 Agent」跑起來。
    4. 把 rubric 存成版本可控的檔案,當作你團隊的「寫作 SOP」。

    5. 如果你只用 Claude 網頁版(或其他聊天介面):

    6. 在同一個對話裡,先請 Claude 當「執行者」產出草稿。
    7. 接著開新一則訊息,明確指定:

      你現在是嚴格的審稿員,請依照以下四個面向評分並給修改建議……

    8. 再下一則訊息,把整段評分貼回去,請它依建議完整重寫。

    9. 如果你準備導入多代理架構(如 Claude Corps 或其他 Agent 框架):

    10. 把目前流程畫成 3–5 個步驟(策略 / 執行 / 審查)。
    11. 每一步寫清楚:輸入是什麼?輸出是什麼?由誰接手?
    12. 在框架裡把每一步實作成單獨的 Agent,再用 workflow 串起來。

    只要你成功把「審稿 Agent」加進現有流程,通常輸出品質就會有肉眼可見的提升,接下來要不要擴充成完整多代理團隊,你會更有感覺。


    小結

    • 把 Claude 當成一個人,很容易塞爆它的 prompt;把它拆成多個 Agent,流程會變得好維護、好重複。
    • 最值得先做的第一步,就是加上一個「rubric 審稿 Agent」,讓 AI 自己打分自己改。
    • 從一個最小流程開始(例如單一文案產出),等你看見品質真的上來,再考慮把整個專案流程搬進 Claude Corps 或其他多代理框架。

    🚀 你現在可以做的事

    • 選一個你常做的任務,照「策略 / 執行 / 審查」拆成 3 段,寫成流程草稿
    • 依文中的 Python 範例,在現有 Claude API 流程中加入一個 RUBRIC 評分 Agent
    • 在 Claude 網頁版實際跑一次「先產出、再評分、再依建議重寫」的完整迴圈
  • 一行指令組好自己的 AI 代理團隊

    一行指令組好自己的 AI 代理團隊

    📌 本文重點

    • 把每個 Agent 當成可版本控制的 Git repo
    • 用 AGENTS.md 與 skills/ 拆開角色與能力
    • .agentlas/ 管理記憶與設定,輕鬆切換模型
    • 用一行 CLI 指令生成並維護多代理 AI 團隊

    只用一行指令,你就能建立一個「像程式專案一樣可版本控制」的多代理 AI 團隊,解決長期記憶混亂、每次對話都要重講一遍的痛點。

    參考架構原文(作者在 Reddit 分享):https://www.reddit.com/r/artificial/comments/1twmhya/an_opensource_agent_architecture_that_solves_the/


    核心功能:把 Agent 當成一個 repo,而不是一段 prompt

    這套開源架構的關鍵想法:每個 Agent 是一個 Git 倉庫,而不是存在聊天框裡的一段系統 prompt。

    💡 關鍵: 把 Agent 轉成可版控的 Git repo,可以用熟悉的軟體開發流程(PR、review、版本管理)來調整 AI 行為,而不是每次重寫 prompt。

    1. AGENTS.md:把「人設 + 任務範圍」寫成文件,而不是憑記憶

    AGENTS.md 是這個架構的核心說明書,裡面通常會包含:

    • 每個代理的角色定位
    • 能做什麼(scope) / 不能做什麼(限制)
    • 彼此如何協作(誰丟任務給誰、輸出長什麼樣)

    你可以做的事:

    1. 在任意資料夾新增 AGENTS.md,用這樣的格式寫第一個代理:

    “`markdown
    # Agents

    ## doc_assistant
    – 角色:技術文件整理員
    – 任務:整理長篇文件、產生摘要與目錄
    – 輸出格式:Markdown,必須包含「摘要」「重點條列」「待釐清問題」三段

    ## code_reviewer
    – 角色:程式碼審查員
    – 任務:針對 Pull Request 提出具體修改建議
    – 限制:不直接改動程式,只提出建議與風險說明
    “`

    1. 把這個 repo 推上 Git(GitHub / GitLab),之後團隊改需求只改這份文件。

    2. skills/:把「能力」拆成工具,而不是糊在一大段 prompt 裡

    傳統代理常見問題是:所有指令、規則、流程都揉在一段很長的系統 prompt 中,改一行就怕爆。

    在這個架構裡,每個能力是一個 skill 檔案,放在 skills/ 資料夾,例如:

    • skills/summarize_docs.md:怎麼讀、怎麼切段、輸出格式
    • skills/review_pr.md:審查步驟、要檢查的細項
    • skills/fetch_urls.md:如何抓網頁、處理錯誤

    你可以做的事:

    1. 新增資料夾 skills/,寫一個最小可用的 skill:

    “`markdown
    # summarize_docs

    步驟:
    1. 讀取輸入文件
    2. 把文件拆成 3–7 個主題
    3. 每個主題用 3 行內說清楚

    輸出格式(Markdown):
    – 一句總結
    – 主題列表(子彈點)
    “`

    1. 在 AGENTS.md 裡指定某個 agent 可以使用 summarize_docs 這個 skill。

    3. .agentlas/:把「記憶和設定」存在檔案,而不是模型腦袋

    .agentlas/ 是這套系統自己的設定與記憶資料夾,用來存:

    • 各代理的偏好設定(語氣、輸出格式)
    • 長期記憶索引(不是直接塞進模型,而是存成檔、用時再讀)
    • 已完成任務的 metadata(方便日後追蹤與再訓練)

    這樣的好處是:

    • 不會把所有對話硬塞進「長期記憶」變成噪音
    • 每次執行前可以用規則選擇要載入哪一段內容

    你可以做的事:

    • 在 .agentlas/config.yaml 加上最基本設定(示意):

    yaml
    default_model: claude
    memory:
    enabled: true
    strategy: recent-and-related
    max_items: 50


    適合誰用:3 個具體場景

    1. 文件整理 + 程式碼審查:建立雙代理 pipeline

    目標:

    • 代理 A 整理設計文件
    • 代理 B 以文件為準則,審查 PR 是否符合設計

    你可以怎麼做:

    1. 在 AGENTS.md 定義兩個代理:

    “`markdown
    ## doc_assistant
    – skills: [summarize_docs]

    ## code_reviewer
    – skills: [review_pr]
    – 會先讀 doc_assistant 的輸出再開始審查
    “`

    1. 把專案文件放在 docs/、程式碼在 src/,PR diff 存到 pr/123.patch。

    2. 在終端機執行(以架構作者的描述為例):

    bash
    agentlas run doc_assistant "整理 docs/ 裡的文件,產出開發規範摘要"
    agentlas run code_reviewer "根據最新開發規範,審查 pr/123.patch"

    1. 審查邏輯日後有變,就更新 skills/review_pr.md,而不是重新教一次模型。

    2. 資料抓取 + 報表生成:自動化情報小幫手

    目標:

    • 代理 C 負責抓網站、清洗文字
    • 代理 D 讀整理後資料,輸出報表(例如每週競品動態)

    步驟:

    1. 在 skills/fetch_urls.md 寫清楚:怎麼從列表讀網址、輸出 JSON 或 Markdown 表格。

    2. 定義兩個 agent:

    “`markdown
    ## data_collector
    – skills: [fetch_urls]

    ## report_writer
    – skills: [summarize_docs]
    – 輸出格式:週報(含「本週重點」「風險」「下週觀察」)
    “`

    1. 每週只需要:

    bash
    agentlas run data_collector "從 urls.txt 抓內容,輸出到 data/this_week.md"
    agentlas run report_writer "讀 data/this_week.md,生成 weekly_report.md"

    1. 週報模板要改,就改 skills/summarize_docs.md 或另開 skills/weekly_report.md。

    3. 多人團隊:把「AI 同事」當成共同維護的 repo

    你可以把這個代理倉庫當成一個共享 AI SOP:

    • PM 改 AGENTS.md 描述角色與流程
    • 開發者在 skills/ 補上新的工具使用說明(例如專案腳本、內部 API)
    • 新同事只要 clone 下來,就能直接用同一套 AI 工作流

    實際做法:

    1. 建一個 GitHub repo:company-ai-agents。

    2. 定一條規則:

    3. 改 Agent 行為 = 改 AGENTS.md / skills/,必須走 PR 流程

    4. 不再使用的 Agent 要標記 deprecated,避免沒人知道它還在跑

    5. 在 README 裡寫清楚「如何在本機執行 agentlas、如何切換模型」。


    怎麼開始:一行指令 + 接上你習慣的模型

    這個架構的一大好處是:不綁特定模型,可以跑在 Claude Code、Codex、Gemini CLI 等環境。

    💡 關鍵: 架構與模型解耦,讓你能在不改 AGENTS.md 和 skills/ 的情況下,自由切換到成本更低或能力更強的模型。

    1. 安裝指令(假設已提供 CLI:agentlas)

    作者在 Reddit 說明,整套系統可以透過一行安裝:

    pip install agentlas  # 或作者實際提供的套件名稱
    

    接著在任意資料夾初始化:

    agentlas init
    

    這通常會自動產生:

    • AGENTS.md
    • skills/
    • .agentlas/

    你可以做的事:

    • 直接在一個新資料夾跑 agentlas init,把它當成「AI 同事模板專案」。

    2. 接上常見模型:Claude / Codex / Gemini CLI

    根據作者說明,這個架構支援多個 runtime,不鎖在某一家:

    • 想用 Claude:在 .agentlas/config.yaml 設定 runtime: claude_code
    • 想用 OpenAI / Codex:設為 runtime: codex
    • 想用 Gemini CLI:設為 runtime: gemini_cli

    範例設定:

    runtime: claude_code
    model: claude-3-5-sonnet
    api_key_env: ANTHROPIC_API_KEY
    

    你可以做的事:

    1. 先用你現在線上付費的模型(例如 Claude)跑通第一個 agent。

    2. 之後想切換模型,只改 config,不改 AGENTS.md 和 skills/ 的內容。

    3. 一句描述,讓系統自動幫你生出代理團隊

    根據 Reddit 原文描述,你可以直接用一句話生成整個代理團隊,例如:

    agentlas new "幫我建立一個:整理產品需求文件 + 產出技術任務清單的雙代理工作流"
    

    CLI 會:

    • 生成初版 AGENTS.md(定義 2 個代理)
    • 建好對應的 skills 檔案
    • 幫你填入基本步驟和輸出格式,之後你再微調

    你可以做的事:

    • 先讓工具幫你生一個「80 分」版本,再用 Git 慢慢調整到「95 分」。

    延伸閱讀:為什麼要從「串 prompt」升級到「Agent 專案」?

    如果你還在用 LangChain 式的「串 prompt + 自己管工具 schema」,可以參考這兩篇:

    這套開源架構跟 MCP 的共通點是:都把 Agent 當成一個長期維護的系統,而不是當場臨時寫的 prompt。

    差別在於,這裡用「實際檔案 + repo」把行為和記憶拆開,讓你可以用熟悉的 Git 流程維護整套 AI 工作流。

    現在你可以做的最後一件事:

    • 開一個新 repo,跑一次 agentlas init,寫一個最小的 AGENTS.md
    • 選一個你每天真的會用到的小流程(例如「整理會議紀錄」)
    • 把它做成第一個可版本控制的 AI 代理

    之後,每次你覺得「這件事好像可以交給 AI」,就把需求寫進 AGENTS.md 和 skills/,你自己的多代理 AI 團隊就會越長越完整。

    🚀 你現在可以做的事

    • 在本機建立新資料夾,執行 agentlas init,產出第一版 AGENTS.md 與 skills/
    • 選一個日常流程(如整理會議紀錄),寫進 AGENTS.md 並建立對應的 skills/xxx.md
    • 建一個 company-ai-agents repo,推上 GitHub,讓團隊透過 PR 共同維護你的 AI 代理 SOP
  • Claude Code:把你的一人開發組變成小團隊

    Claude Code:把你的一人開發組變成小團隊

    📌 本文重點

    • Claude Code 扛「從 issue 到 PR」整條開發流程
    • 百萬 token 上下文,能做跨檔案大規模重構
    • 與 issue 管理工具整合,連動任務與代碼
    • 把它當工作流 Agent,而不是單純寫程式助手

    Claude Code 要解決的問題很單純:不要只幫你「寫幾行程式」,而是幫你「從 issue 到 PR 到 release note」整條開發流程一起扛掉。

    Claude Code 官方頁面|參考閱讀:Claude Code Isn’t a Coding Tool. It’s Your Team’s New Workflow Engine.


    核心功能:不只是會寫程式的 Chatbot

    1. 百萬上下文 + 跨檔案重構

    Claude Code 的關鍵不是「會寫程式」,而是一次看得懂整個專案:

    💡 關鍵: 百萬 token 上下文讓 Claude Code 能一次理解整個大型 repo,支援跨模組重構與設計級別調整。

    • 支援百萬 token 上下文,實務上可以:
    • 一次讀完整個 monorepo 的關鍵目錄
    • 同時理解前後端、infra、文件
    • 實際能做的事:
    • 統一命名規則、API 介面:
      • 指令範例:

        「請在整個 apps/web 和 packages/api 裡,把 user profile 統一改成 UserProfile 類型,並更新相關型別定義與呼叫點。」

    • 大規模重構:改 routing、auth、logging 邏輯,而不是只改單一檔案

    行動建議:
    – 第一次用時,直接把「專案關鍵資料夾」拖進 Claude Code,請它輸出:
    – 架構圖
    – 主要模組關聯
    – 技術債/風險清單

    2. 代碼審查 + 任務追蹤

    Claude Code 把「code reviewer + 小 PM」包在一起用:

    • 代碼審查:
    • 貼 PR diff 或讓它自己產生 patch,請它從幾個角度審查:
      • 可讀性
      • 安全性
      • 可測試性
    • 指令範例:
      > 「這個 PR 幫我做 code review,重點看:1) SQL 注入風險 2) log 裡有沒有可能洩漏個資。」
    • 任務追蹤:
    • 你丟一串 TODO、散落在註解、issue 裡,它可以:
      • 幫你整理成任務列表
      • 按複雜度排序
      • 標註依賴關係

    行動建議:
    – 把你專案裡的 // TODO 集中給 Claude Code,看它幫你:
    – 分成「1 小時內可完成」「需要討論設計」兩類
    – 生成對應 Issue 描述(等下一小節接管理工具)

    3. 與 Linear / Jira 等管理工具整合

    重點不是「Claude Code 會寫 issue」,而是它能 自己對應任務 ↔ 代碼:

    • 典型流程:
    • 從 Linear / Jira 拉某個 issue 描述
    • Claude Code:
      • 解析需求
      • 找出相關檔案
      • 建議實作方案
      • 產生 patch / commit 訊息
    • 回寫到對應 issue(附 PR link、測試說明)
    • 這讓你可以用一句話驅動整個流程:
    • 「幫我處理 Linear 上 FE-1234 這張 ticket,照 acceptance criteria 寫完測試再開 PR。」

    行動建議:
    – 把團隊目前的 issue 模板、PR 模板貼給 Claude Code,請它:
    – 照樣學習格式
    – 以後所有「產生 PR 描述 / 測試計畫」都統一風格


    適合誰用?三種典型場景

    1. 單人開發者:讓 Claude Code 當你的 PM + Reviewer

    你一個人接案或做 side project,沒人幫你看架構、沒人幫你 review。Claude Code 可以扮演:

    • 專案 PM:
    • 幫你把「腦中需求」變成 roadmap:
      • 「這個月要完成:會員系統 v1、簡單報表」
    • 轉成 task list:db schema、API、UI、測試
    • code reviewer:
    • 每次 commit 前,請它檢查:
      • 功能風險
      • 重複邏輯
      • 可抽共用函式的地方

    具體做法:
    – 建立一個持續使用的 Claude Code 專案,放:
    – README、需求文件、todo list
    – 一份「我寫程式的偏好」(語言、框架、lint 風格)
    – 每天開工前一句:

    「根據目前 repo 與 TODO,幫我排今天 3 個最值得做的 task,控制在 3 小時內。」

    2. 小團隊:讓它維護 issue、測試、技術文件

    對 3–10 人團隊,Claude Code 好用在「把大家都懶得做的事」接走:

    💡 關鍵: 對 3–10 人的小團隊,把 issue 清理、測試補齊與文件生成交給 Claude Code,可顯著減少非核心開發時間。

    • Issue 維護:
    • 每週讓 Claude Code:
      • 清理過期 / 重複 issue
      • 把描述不清的 issue 重新改寫
    • 測試補齊:
    • 對於已存在的功能程式碼:
      • 要求它列出「目前缺哪些層級的測試」
      • 自動產生 test skeleton(unit / integration)
    • 技術文件:
    • 從 commit / PR 摘要產出:
      • 變更日誌
      • ADR(Architecture Decision Record)草稿

    具體做法:
    – 選一個模組先試點,例如「會員系統」:
    1. 把現有 PR、issue 歷史餵給 Claude Code
    2. 要它輸出一份「會員系統說明文件 v0」
    3. 團隊一起 review,修改後當作標準模板

    3. 大批量重構 / 遷移專案:讓它拆成可執行任務

    當你在做:
    – 從 JS → TS
    – 從 REST → GraphQL / gRPC
    – 從單體 → 模組化

    這時 Claude Code 的長上下文 + 任務拆解很實用:

    • 一次吃下:
    • 主要模組目錄
    • 現有測試
    • 部署設定
    • 輸出:
    • 分階段遷移計畫
    • 每階段具體改哪些檔、會壞掉什麼

    具體做法:
    – 問 Claude Code:

    「假設我要在 4 週內把 services/auth 從 JS 遷移到 TS,請在不影響現在線上環境的前提下,拆成 4 週計畫,每週列出可以單獨合併的 PR 列表。」


    怎麼開始:從註冊到跑完一條完整 workflow

    步驟 1:註冊與開啟 Claude Code

    1. 到 claude.ai 註冊帳號(可用 Google / Email)。
    2. 登入後,點右上角 Code 進入 Claude Code 介面。
    3. 建議準備:
    4. GitHub repo 連結
    5. 專案 README、需求文件

    步驟 2:連接 GitHub / 專案庫

    目前常見兩種用法:

    • 直接拖拉檔案夾:
    • 小專案、side project 最快
    • 接 GitHub:
    • 依照介面授權,把指定 repo 掛上去
    • 在對話裡直接叫它打開某個檔案路徑,再請它操作

    行動建議:
    – 先選一個風險較低的 repo(side project 或工具庫)當實驗場,不要一開始就丟公司核心系統。

    步驟 3:示範一條具體 workflow

    以「從 TODO issue → 產生 PR → 自動寫 release note」為例:

    1. 整理 TODO
      在 Claude Code 裡貼上:
    2. 一個 Linear / Jira issue 內容,或
    3. 散落在程式裡的 TODO 註解

    請它:

    「幫我把這些 TODO 整理成一個明確的 issue 描述,列出 acceptance criteria。」

    1. 讓它實作並產生 PR
      接著說:

      「根據這個 issue,在目前 repo 裡完成實作,請:1)列出要改的檔案 2)給我完整 patch 3)附上測試建議。」

    你可以:
    – 先人工 review patch
    – 把 patch 套進本地分支
    – 提交 GitHub PR

    1. 自動寫 release note
      PR 開好後,把:
    2. PR diff / 連結
    3. 關聯 issue 連結

    貼給 Claude Code,指令:

    「幫我寫一段 release note,給非工程同事看的,限制 150 字內,列出 2-3 個 bullet point。」

    若你有一份既有 release note 模板,也一起貼上,請它照模板格式輸出。

    做完一次,你就有一條可重複的最小 workflow,之後只要換 issue 就能重跑。


    進階玩法:把 Claude Code 變成「小開發團隊」的一員

    1. 和輕量模型分工,省錢跑批量任務

    很多工作不需要 Claude 這種大模型,例如:
    – 大量 JSON 重新排版
    – 批次分類檔案
    – 從文字裡抽欄位

    參考這篇 Reddit 實作:Most of my Claude usage was on work that didn’t need Claude

    做法:
    – 另外架一個便宜的小模型 API(例如 DeepSeek V4 Flash)
    – 在 Claude Code 這邊只放一個規則:
    – 「遇到格式轉換、摘要這種機械工作,一律呼叫那個外部工具,不要自己算」

    💡 關鍵: 把機械式任務交給便宜模型,可將大量批次任務成本壓到原本的約 1/10。

    效果:
    – 大量批次任務成本可壓到原本的 1/10 甚至更低

    2. 搭配 Relay 這類插件,讓多個 Claude Code 會話互通

    如果你常同時開:
    – 一個 session 管 backend
    – 一個 session 管 frontend
    – 另一個管 infra / CI

    可以照這篇的做法:built a plugin so my parallel Claude Code sessions can message each other

    概念是:
    – 用像 Relay 這種小工具,讓不同 Claude Code 視窗可以互相發訊息
    – 例如:
    – 前端 session 問:「User object 現在長怎樣?」
    – 後端 session 直接回,結果推回前端視窗顯示

    實際好處:
    – 你不用在多個對話間複製貼上
    – 等於有好幾個專職「子工程師」在各自 repo 幫你跑任務,互相同步狀態


    小結:把 Claude Code 視為「工作流 Agent」,不是「更聰明的 Copilot」

    使用 Claude Code 的關鍵心態是:
    – 不要只問「幫我寫這個 function」
    – 要改成「幫我把這個 issue 從需求 → 設計 → 實作 → 測試 → 文件,一次帶完」

    先從一條最小 workflow 開始做起(例如本文的 TODO → PR → release note),再逐步接上 issue 管理、測試、自動文件,Claude Code 才會真正變成你開發流程的一部分,而不是多一個可以聊天的 IDE 工具。

    🚀 你現在可以做的事

    • 選一個風險低的 repo,丟進 Claude Code,請它產出架構圖與技術債清單
    • 把現有的 issue / PR 模板貼給 Claude Code,讓它學會之後統一產生描述與測試計畫
    • 實做一次「TODO → issue → PR → release note」完整 workflow,確認能在團隊內重複使用
  • 用 openai-agents-python 搭一個 AI 小團隊

    用 openai-agents-python 搭一個 AI 小團隊

    📌 本文重點

    • 用多個專職 agent 分工處理一個大任務
    • 透過 orchestrator 串起明確的多步驟流程
    • 將既有 API / 工具包成 @tool 打造可落地工作流
    • 先做最小 demo,再逐步擴展到既有系統

    只靠一個聊天機器人常常做出「四不像」的結果,而 openai‑agents‑python 要解決的,就是讓你把一個大任務拆給多個各司其職的 AI 代理人,像一個小團隊一樣協作完成。

    GitHub 專案連結:https://github.com/openai/openai-agents-python


    核心功能:把一個大任務拆給多個 AI

    1. 定義多個專長不同的 Agent

    你可以在程式裡定義多個「角色」:

    • 資料蒐集 agent:負責上網查資料、整理重點
    • 寫作/寫程式 agent:負責產出初稿或程式碼
    • 審稿 agent:負責檢查結構、風格、錯字或潛在 bug

    這些都用 Python class 或函式就能描述,像這樣:

    from openai_agents import Agent
    
    researcher = Agent(
        name="researcher",
        instructions="你負責閱讀提供的資料,整理三個重點與參考連結。",
    )
    
    writer = Agent(
        name="writer",
        instructions="你負責寫出條列清楚的技術部落格草稿,語氣教學向。",
    )
    
    reviewer = Agent(
        name="reviewer",
        instructions="你負責審稿,只給出修改建議與需要補充的段落。",
    )
    

    行動:先想一個你日常會做的「三步驟」任務,直接對應成三個 agent 的職責。


    2. 設計任務流程:交接、審查、協作

    openai‑agents‑python 的重點不只是「多個 agent」,而是讓你把流程寫清楚:誰先做、誰接手、誰審查。

    例如做一個「自動寫技術部落格」的流程:

    1. researcher:根據題目蒐集資料,產出重點摘要
    2. writer:根據摘要寫出完整草稿
    3. reviewer:審稿,給出修改建議

    💡 關鍵: 把一長串需求拆成 2–3 個明確步驟,比一次丟給單一聊天模型更穩定、可控。

    在框架裡你可以用一個 orchestrator(像主揪)來控制:

    from openai_agents import Orchestrator
    
    orchestrator = Orchestrator(agents=[researcher, writer, reviewer])
    
    async def run_blog_flow(topic: str):
        research_notes = await orchestrator.run("researcher", input={"topic": topic})
        draft = await orchestrator.run("writer", input={"topic": topic, "notes": research_notes})
        review = await orchestrator.run("reviewer", input={"draft": draft})
        return {"draft": draft, "review": review}
    

    行動:把你現在用 ChatGPT 一次請他「幫我想題目、寫文、修稿」的流程,拆成 2–3 個步驟,寫在紙上,對應到上面這種 orchestrator 程式碼結構。


    3. 串接外部工具與 API,變成真的工作流

    openai‑agents‑python 支援 agent 呼叫你自定義的工具函式,例如:

    • 網頁爬蟲(requests、Playwright)
    • 存取資料庫或 Google Sheets
    • 操作檔案系統,輸出成 Excel / CSV

    你先寫好 Python 函式,再把它註冊給 agent 使用:

    import requests
    from openai_agents import tool
    
    @tool
    def fetch_url(url: str) -> str:
        """抓取指定網址的 HTML"""
        return requests.get(url, timeout=10).text
    
    scraper = Agent(
        name="scraper",
        instructions="根據給定網址抓網頁內容並擷取需要的欄位。",
        tools=[fetch_url],
    )
    

    行動:先選一個你常用的 API(例如某個內部 HTTP API、Notion API),包成一個最小的 @tool 函式,讓 agent 能直接呼叫。


    Demo:一晚內做完的「自動寫技術部落格」小團隊

    這裡做一個最小可用版本:輸入一個主題,幫你:

    1. 蒐集重點
    2. 產生技術部落格草稿
    3. 用 reviewer 做一次審查,輸出建議

    步驟 0:安裝與環境準備

    pip install openai-agents-python openai
    

    在專案根目錄建立 .env(或直接用環境變數):

    export OPENAI_API_KEY="你的 API Key"
    

    💡 關鍵: 只要設定好 OPENAI_API_KEY,就能在一晚內跑起一個可用的多 agent 小流程。

    步驟 1:建立第一個 writer agent

    新增 agents_blog.py:

    from openai_agents import Agent
    
    writer = Agent(
        name="writer",
        instructions=(
            "你是技術部落客,請用繁體中文寫 1200 字內的教學文,"
            "條列清楚、加上小標題,讀者是有基礎的工程師。"
        ),
    )
    

    先單獨測試這個 agent:

    import asyncio
    from agents_blog import writer
    
    async def main():
        result = await writer.run({"topic": "Python logging 實戰"})
        print(result)
    
    if __name__ == "__main__":
        asyncio.run(main())
    

    行動:先確保「單一 agent + 單一呼叫」正常運作,看到一篇文章草稿再往下加複雜度。


    步驟 2:加上 researcher + reviewer

    修改 agents_blog.py:

    from openai_agents import Agent
    
    researcher = Agent(
        name="researcher",
        instructions=(
            "你負責針對主題列出 5 個實用重點與常見坑,"
            "輸出 JSON 格式:{\"key_points\": [...]}。"
        ),
    )
    
    writer = Agent(
        name="writer",
        instructions=(
            "根據 research.key_points 寫技術部落格,"
            "包含簡介、實作步驟與常見錯誤排查。"
        ),
    )
    
    reviewer = Agent(
        name="reviewer",
        instructions=(
            "你是嚴格的技術編輯,檢查草稿是否:1) 結構清楚、"
            "2) 範例正確、3) 沒有太多空話。輸出建議清單。"
        ),
    )
    

    再加一個 orchestrator 流程(新檔 run_blog.py):

    import asyncio
    from openai_agents import Orchestrator
    from agents_blog import researcher, writer, reviewer
    
    orchestrator = Orchestrator(agents=[researcher, writer, reviewer])
    
    async def run_blog(topic: str):
        research_notes = await orchestrator.run("researcher", input={"topic": topic})
        draft = await orchestrator.run("writer", input={"topic": topic, "research": research_notes})
        review_notes = await orchestrator.run("reviewer", input={"draft": draft})
    
        print("=== 草稿 ===\n")
        print(draft)
        print("\n=== 審稿建議 ===\n")
        print(review_notes)
    
    if __name__ == "__main__":
        topic = input("輸入技術主題:")
        asyncio.run(run_blog(topic))
    

    行動:實際輸入你下週想寫的一個主題,看這個流程能不能生成一份你「願意再改一版就能上 blog」的草稿。


    步驟 3:做成簡單 CLI 或排程

    CLI(已經算一種):

    python run_blog.py
    

    若要每天自動產出草稿,可以用 crontab:

    crontab -e
    # 每天早上 9 點產出一篇關於 Python 的文章
    0 9 * * * cd /path/to/project && OPENAI_API_KEY=xxx python run_blog.py <<EOF
    Python 非同步程式設計實戰
    EOF
    

    行動:先用 CLI 手動跑幾次,確認品質與 token 消耗,再考慮排程自動化。


    適合誰用?幾個具體場景

    • 工程師/資料工程師:
    • 資料抓取 → 清洗 → 產出報表(多個 agent 分別負責)
    • 專案 scaffold 生成 → 單元測試撰寫 → reviewer 檢查風險
    • 技術寫作者 / Developer Advocate:
    • 自動產出技術部落格初稿、Release Note、API 範例
    • 內部平台團隊:
    • 把既有的 CI/CD、監控 API 包成工具,讓 AI agent 幫忙查 log、整理 incident 報告

    💡 關鍵: 只要你習慣在 ChatGPT 下一長串指令,就幾乎一定能拆成 multi‑agent workflow 減少來回與手動操作。

    只要你目前已經在用 ChatGPT 做「一長串指令」,就適合把流程拆成 multi‑agent workflow 測試看看。


    延伸應用:部署、成本控制、整合現有系統

    1. 部署到雲端

    • 用 FastAPI 或 Flask 包一層 HTTP API,把 orchestrator 暴露成 /run_flow endpoint
    • 部署到 Render / Railway / Fly.io / 自家 Kubernetes,都只是一般 Python Web 服務部署流程

    2. 控制成本與錯誤

    • 限制 max_tokens / 模型:對只負責小任務的 agent 用較便宜的模型
    • 加上 retry + logging:為 orchestrator 跑的每一步記錄 prompt、輸出與 token 使用
    • 設定明確 instructions:讓 reviewer 僅輸出「建議清單」,避免重複生成整篇文章浪費 token

    3. 與既有後端或 Slack Bot 整合

    • 既有後端:在服務裡呼叫 orchestrator,把結果回寫資料庫或觸發其他工作
    • Slack Bot:
    • 用 Slack API 建一個 slash command /ai-team
    • 收到指令後,把文字丟給 orchestrator,完成後再貼回頻道

    行動:先選一個「已在跑的」後端流程(例如每週報表),先只把其中一段換成 agent 完成,觀察穩定度與成本。


    怎麼開始:最快上手路徑

    1. 看 GitHub README:https://github.com/openai/openai-agents-python
    2. 先實作一個最小 demo:如本文的 blog flow 或「抓網頁 → 清洗 → 匯出 CSV」
    3. 再慢慢拆更多 agent:把你原本寫在同一個 prompt 或腳本裡的步驟,一個一個拆成獨立角色

    只要先完成一個「今晚就能跑起來」的小流程,你之後會很自然開始想:還有哪些工作可以交給這個 AI 小團隊做。

    🚀 你現在可以做的事

    • 打開專案,實作一個最小的 writer agent 並用單一呼叫產出一篇草稿
    • 把你常用的一個內部或公開 HTTP API 包成 @tool,讓 agent 能直接呼叫
    • 依照文中的 researcher → writer → reviewer 範例,寫出自己的第一個 orchestrator 流程並在本機跑一次