CrewAI Agent 與 Task 設計:怎麼拆角色才不會亂成一團

7 min read

很多人用 CrewAI 第一次翻車,不是 API 問題,也不是環境設定——是角色設計從一開始就亂了

你可能會想:一個 Agent 搞定全部不是更省事嗎?讓它既研究、又寫作、又審稿,聽起來很高效。但實際跑起來你會發現,一個 Agent 同時扮演三種性質完全不同的角色,通常是三件事都做得普普通通,而且你完全不知道哪一步出了問題。

只要記住這個核心原則:一個 Agent 一種專長,一個 Task 一件事,大多數設計問題就迎刃而解了。

Agent、Task、Context 分別負責什麼

用最直白的方式理解這三者:

  • Agent 是「誰來做」——角色定義、專長方向、有沒有工具
  • Task 是「做什麼」——具體指令、輸出格式、完成標準
  • Context 是「前一步給後一步什麼」——讓任務之間真的有資料流動

如果你讓一個 Agent 同時研究、寫作、審稿,它通常會每件事都沾一點、每件事都不夠深。就像你不會在求職廣告上寫「需要全端工程師,同時負責 PM 和設計」,那個人就算存在,你也管不動他。

設計一個好的 Agent

researcher:
  role: >
    AI Research Analyst
  goal: >
    Collect accurate and current information from reliable sources
  backstory: >
    You specialize in finding credible sources and extracting key facts.
    You always verify information before passing it forward.
  allow_delegation: false
 
writer:
  role: >
    Technical Writer
  goal: >
    Turn raw research findings into clear, practical documentation
  backstory: >
    You have a talent for making complex ideas accessible.
    You structure content so readers can quickly find what they need.
  allow_delegation: false

allow_delegation: false 建議一開始就關掉。它預設開啟,但會讓 Agent 自行決定把子任務轉包給其他 Agent——聽起來很聰明,但新手階段等於把除錯難度直接翻倍。先跑穩、再開啟動態分派。

backstory 不只是裝飾用的——模型會把它當成角色設定讀進去,影響輸出的語氣和判斷方式。短短三行可以明顯改變同一個 Agent 的表現差異。

設計一個好的 Task

Task 最常見的問題是「寫太短」——模型不知道你要什麼格式,輸出就會每次都不一樣。

research_task:
  description: >
    Find 8-10 important updates about {topic} in 2026.
    Focus on: what changed, why it matters, and where it came from.
    Prioritize content published in the last 3 months.
  expected_output: >
    A markdown bullet list with 8-10 items.
    Each item must include:
    - Title (bold)
    - Summary (2-3 sentences)
    - Source URL (if available)
  agent: researcher
 
write_task:
  description: >
    Convert the research bullets into a tutorial article for developers new to {topic}.
    Do not add information that wasn't in the research notes.
  expected_output: >
    A markdown article with:
    - Introduction (1 paragraph)
    - 3 main sections with H2 headings
    - Conclusion with next steps
  agent: writer
  context:
    - research_task

expected_output 越具體越好——不是「寫個報告」,而是「markdown 格式、3 個 H2 段落、結尾有 next steps」。這個欄位直接決定輸出的穩定性。

新手最常踩的 3 個坑

1. Task 描述太短

「Research about AI tools」這種描述給模型太多空間自己發揮,結果每次輸出都不一樣。描述要像在跟一個聰明但不了解你業務的人說明清楚,什麼要做、什麼不要做、格式是什麼。

2. 沒有 expected_output

這是輸出格式每次都漂移的主因。它不是可選欄位——它是你跟模型簽的格式契約。缺了它,你只能看模型心情。

3. 後續任務忘記加 context

寫完 research_task 之後,你以為 write_task 會自動知道前面的研究結果——不會的。context: [research_task] 這行少了,writer 就會自己憑空生出資料,而不是真的用研究員的成果。

每次寫完 YAML 前過這 5 個問題

拿起你的 agents.yaml 和 tasks.yaml,對這 5 個問題逐一確認:

  1. 這個 Agent 是不是只有一個明確專長?
  2. 這個 Task 是不是只做一件事?
  3. expected_output 有沒有寫清楚格式、長度、結構?
  4. 任務之間有依賴關係的,有沒有加 context
  5. 需要輸出到檔案的,有沒有設 output_file

這 5 個問題答對了,80% 的設計地雷就排掉了。

常見問題

Q:一個 Crew 要有幾個 Agent 才合適?
初期 2-3 個就夠了。Agent 數量增加,成本和 debug 難度都會上升。先讓少量 Agent 跑穩,再評估是否需要增加角色。

Q:backstory 一定要寫嗎?
不是強制的,但寫了效果明顯更好。特別是當你需要模型在輸出時保持特定立場或語氣,backstory 就是你設定角色框架的地方。

Q:allow_delegation: true 什麼時候才應該開?
當你有穩定的監控機制、知道系統在哪種條件下會轉包任務、成本有可控制方式的時候。新手階段先關掉,省麻煩。

下一步

角色和任務設計清楚後,接下來要決定「這些任務按什麼順序跑、由誰負責協調」。
👉 Crew 與 Process