昨天建立 PM 與 Research Agent。今天再加入 Creative 與 Finance：前者根據研究資訊提出方案，後者檢查成本、限制與風險。

目前還沒有完整的 Agent 接力。測試會把專案需求與模擬的 Research 結果組成 JSON，再讓兩個角色各自分析，先確認 Prompt、模型參數與輸出格式確實不同。

今天完成的內容

• 建立 CreativeAgent 與 FinanceAgent
• 使用 Pydantic 定義兩種輸出
• 設定不同的 Temperature、Seed 與輸出上限
• 將需求與 Research 結果組成共用輸入
• 使用 Fake LLM Service 測試角色分工

兩個角色怎麼分工？

Creative 不能把待查證內容當成事實；Finance 缺少數字時也不能自行補出精確金額。

Creative Agent 的輸出

單一提案包含四個欄位：

class CreativeProposal(BaseModel):
    model_config = ConfigDict(extra="forbid")

    title: NonEmptyText
    description: NonEmptyText
    research_basis: list[NonEmptyText]
    implementation_steps: list[NonEmptyText] = Field(min_length=1)

• title：方案名稱
• description：方案內容
• research_basis：參考的已知資訊或合理推論
• implementation_steps：實際執行步驟

只有名稱還不算可執行方案，因此 implementation_steps 至少要有一筆。整體輸出再由 CreativeAnalysis 保存：

class CreativeAnalysis(BaseModel):
    model_config = ConfigDict(extra="forbid")

    proposals: list[CreativeProposal] = Field(min_length=1)

目前只要求至少一項提案，沒有設定一定要產生三種方案。模型多回傳未定義欄位時，Pydantic 也會直接拒絕。

Creative 的模型設定

temperature = 0.8
seed = 7
max_output_tokens = 700

Creative 使用較高溫度增加方案變化，輸出上限也較大，才能容納描述、依據與步驟。不過溫度高不代表品質一定更好，內容仍要符合 JSON Schema 與 Pydantic 驗證。

Finance Agent 的輸出

Finance 不會輸出實際報價或總預算，而是整理規劃階段需要注意的項目：

class FinanceAnalysis(BaseModel):
    model_config = ConfigDict(extra="forbid")

    cost_considerations: list[NonEmptyText]
    constraints: list[NonEmptyText]
    risks: list[NonEmptyText]
    alternatives: list[NonEmptyText] = Field(min_length=1)

• cost_considerations：可能影響成本的設備、服務或人力
• constraints：已知限制與未確認條件
• risks：可能影響執行的風險
• alternatives：成本較低或風險較小的替代做法

alternatives 至少需要一筆，避免只列問題而沒有調整方向。

Finance 的設定較保守：

temperature = 0.1
seed = 42
max_output_tokens = 500

低溫度讓風險整理更收斂，但它仍是語言模型，不能取代實際詢價或人工財務審查。

兩個 Agent 收到什麼資料？

測試把需求與 Research 結果組成同一份 JSON：

project_context = json.dumps(
    {
        "project_requirement": "建立 AI 客服 Discord Bot",
        "research": {
            "known_information": ["使用 Qwen 回答常見問題"],
            "reasonable_inferences": ["需要設計對話流程"],
            "items_to_verify": ["可用預算與硬體規格"],
        },
    },
    ensure_ascii=False,
)

再交給兩個角色：

creative_result = await creative_agent.respond(project_context)
finance_result = await finance_agent.respond(project_context)

這份輸入沒有 PM 分析，Finance 也還沒收到 Creative 的提案。因此目前驗證的是「相同資料能否產生兩種專業觀點」，還不是完整流程：

PM → Research → Creative → Finance

共用 StructuredAgent

Creative 與 Finance 都把 AgentConfig、LLM Service 和 Pydantic Model 交給 StructuredAgent。模型回覆後，共用流程會執行：

self.output_model.model_validate_json(response.content)

這一步負責解析 JSON，並檢查必要欄位、型別與限制。格式錯誤時，程式會拋出包含角色名稱的 AgentError。

使用 Fake LLM Service 測試

tests/test_creative_finance_agents.py 使用 Fake Service，從 System Prompt 判斷角色並回傳不同 JSON，不必啟動 Ollama。

Creative 的測試結果包含「互動式 AI 客服導覽」方案、研究依據與執行步驟；Finance 則回傳本機運算資源、硬體限制、回覆速度風險，以及先用小模型製作 MVP 的替代方案。

測試會確認：

• 回傳型別分別是 CreativeAnalysis 與 FinanceAnalysis
• 兩個 Agent 收到相同 project_context
• System Prompt 與 JSON Schema 不同
• 模型參數符合各自設定

這些測試只確認角色設定與解析流程，不比較方案好不好，也不計算實際預算。

執行測試

python -m unittest discover -s tests -v

Ran 36 tests in 0.090s

OK

測試使用 Fake LLM Service，沒有真的呼叫 Qwen。實際模型能否穩定遵守兩份 Schema，仍要在整合後另外驗證。

今天完成到哪裡？

DAY 13 完成 Creative 與 Finance 的類別、輸出格式及單元測試。兩個角色尚未接進 Discord，也沒有由會議流程依序呼叫；這一步先把責任與資料格式定清楚。