Ithy 原始碼解讀：50 行程式碼裡的 Mixture-of-Agents 設計哲學

Ithy 是一個將 Mixture-of-Agents（MoA）概念濃縮到 50 行 Python 程式碼的開源專案，核心思想是：同時向多個 LLM 發問，再由一個聚合器模型把所有回答合成為一個更高品質的最終回應。這個專案值得讀原始碼，不是因為它龐大複雜，恰恰相反——它極度精簡，用最少的程式碼展示了多模型協作的完整架構。讀完你能學到：如何設計多模型並行呼叫、如何用 Prompt Engineering 驅動聚合邏輯、以及如何將研究型 AI 系統的 prompt 模組化。

Ithy GitHub Repository — 專案原始碼，包含 50 行核心實作與完整的 prompt 模組設計

專案概覽

Ithy 的靈感來自 Together.ai 的 MoA 專案和 GPT Researcher，目標是將「多模型混合推理」的概念通用化。整個倉庫只有 6 個檔案，卻涵蓋了從基礎 MoA 實作到完整研究報告生成的 prompt 體系。

技術棧：Python、asyncio、Together API 授權：MIT License 規模：6 個檔案，核心邏輯 50 行，prompt 模組約 500 行

架構總覽

ithy/
├── main.py                          # 50 行核心實作：MoA 的最小可行範例
├── prompts/
│   ├── aggregator_prompts.py        # 聚合器 prompt：指導模型整合多源回應
│   ├── search_prompts.py            # 搜尋 prompt：查詢改寫與線上搜尋結果整合
│   └── research_prompts.py          # 研究 prompt：完整的研究報告生成體系
├── README.md                        # 英文專案說明
├── README-CN.md                     # 中文專案說明
└── LICENSE                          # MIT 授權
Code language: PHP (php)

這個架構的設計哲學非常清晰：一個極簡的執行引擎 + 一套可替換的 prompt 模組。main.py 負責「怎麼跑」，prompts/ 目錄負責「跑什麼」。這種分離讓同一套並行呼叫機制可以服務於不同的應用場景——從簡單的問答聚合到複雜的研究報告生成。

核心設計解析

設計一：極簡的 Fan-out / Fan-in 架構

Ithy 的 main.py 只有 50 行，卻實現了完整的 Mixture-of-Agents 流程。這個設計的核心是一個經典的 Fan-out / Fan-in 模式：先把同一個問題「扇出」給多個模型，再把所有回應「扇入」到一個聚合器。

main.py — 50 行核心實作，展示 MoA 的最小可行架構

reference_models = [
    "meta-llama/Llama-3.3-70B-Instruct-Turbo",
    "Qwen/Qwen2.5-72B-Instruct-Turbo",
    "Qwen/Qwen2.5-Coder-32B-Instruct",
    "microsoft/WizardLM-2-8x22B"
]
aggregator_model = "Qwen/Qwen2.5-72B-Instruct-Turbo"
Code language: JavaScript (javascript)

模型清單的設計值得注意：四個 reference models 刻意選擇了不同廠商、不同規模、不同專長的模型。Llama 3.3 70B 是通用大模型、Qwen 2.5 72B 是另一個通用選手、Qwen 2.5 Coder 32B 專精程式碼、WizardLM-2 8x22B 則是 MoE 架構模型。這種「多樣性優先」的選擇策略體現了 MoA 的核心假設：不同模型的偏差方向不同，聚合後能互相修正。

而聚合器選用了與 reference model 相同的 Qwen 2.5 72B，這暗示了一個設計取捨：聚合器不需要是「最強」的模型，它需要的是足夠的語言理解能力來判斷和整合多個回應。

設計二：asyncio 並行呼叫與指數退避

整個並行呼叫機制用不到 15 行就實現了：

async def run_llm(model):
    """Run a single LLM call with a reference model."""
    for sleep_time in [1, 2, 4]:
        try:
            response = await async_client.chat.completions.create(
                model=model,
                messages=[{"role": "user", "content": user_prompt}],
                temperature=0.7,
                max_tokens=512,
            )
            break
        except together.error.RateLimitError as e:
            print(e)
            await asyncio.sleep(sleep_time)
    return response.choices[0].message.content
Code language: JavaScript (javascript)

這裡有幾個細微但重要的設計決策：

指數退避用硬編碼列表 [1, 2, 4]：不用計算公式，直接用一個可讀的列表。最多重試 3 次，總等待時間 7 秒。這是「夠用就好」的工程哲學——對於一個示範專案，不需要引入 tenacity 或自訂的 retry decorator。
temperature=0.7：這個溫度值不是隨意選的。太低（如 0.1）會讓所有模型傾向於給出相似的回答，失去多樣性；太高（如 1.0）則會引入太多噪音。0.7 是一個經過實踐驗證的平衡點，讓每個模型保有自己的「觀點」。
max_tokens=512：限制每個 reference model 的輸出長度，確保聚合器不會被過長的上下文淹沒。這也是一種成本控制策略——四個模型各 512 tokens，總共 2048 tokens 的上下文餵給聚合器，是一個合理的規模。

設計三：聚合的雙通道設計——System Prompt 注入回應

聚合階段的設計是整個專案最精巧的部分：

async def main():
    results = await asyncio.gather(*[run_llm(model) for model in reference_models])
    finalStream = client.chat.completions.create(
        model=aggregator_model,
        messages=[
            {"role": "system", "content": aggreagator_system_prompt + "\n" +
             "\n".join([f"{i+1}. {str(element)}" for i, element in enumerate(results)])},
            {"role": "user", "content": user_prompt},
        ],
        stream=True,
    )
Code language: JavaScript (javascript)

注意 reference models 的回應是被注入到 system prompt 而非 user message 中的。這個設計有深意：

System prompt 位置讓聚合器把這些回應視為「背景知識」而非「需要回答的問題」
User message 重複原始問題讓聚合器知道最終要回答什麼
編號列表格式（1. response1\n2. response2）讓聚合器能清楚區分不同來源

此外，聚合階段使用了 stream=True 而 reference 階段沒有。這反映了不同的使用者體驗考量：reference 階段是後台運算，不需要即時反饋；但最終回答需要串流輸出，讓使用者不用等待完整生成。

設計四：聚合器 Prompt 的分層設計

聚合器的 prompt 在 aggregator_prompts.py 中被分成了兩層：

prompts/aggregator_prompts.py — 聚合器 prompt 模組，展示了基礎指令與增強指令的分層設計

第一層：基礎指令（來自 Together.ai MoA）

prompt_aggregator = """
- You have been provided with a set of responses from various open-source models to the latest user query.
- Your task is to synthesize these responses into a single, high-quality response.
- It is crucial to critically evaluate the information provided in these responses, recognizing that some of it may be biased or incorrect.
- Your response should not simply replicate the given answers but should offer a refined, accurate, and comprehensive reply to the instruction.
- Ensure your response is well-structured, coherent, and adheres to the highest standards of accuracy and reliability.
"""
Code language: PHP (php)

第二層：Ithy 增強指令

prompt_aggregator = prompt_aggregator + """
- Your knowledge cutoff is today's date, {datetime.now().strftime("%A, %Y-%m-%d")}.
- Determine the prevalent points of agreement (consensus) among the provided sources.
- Your strongest points should be concepts directly related to the user's query.
- Prioritize consensus ideas found in multiple sources or websites.
- Combine similar concepts into single, comprehensive points, presenting each unique point only once in your response.
- Do not speculate. Do not use hypotheticals. Do not make assumptions. Do not include placeholders.
"""
Code language: PHP (php)

這種「基礎 + 增強」的分層策略非常值得學習：

共識優先（consensus）：要求聚合器先找出多個模型的共識點，這是 MoA 的統計學基礎——如果多數模型都同意某個觀點，它更可能是正確的
去重合併：「presenting each unique point only once」避免了聚合後的冗餘
禁止推測：最後一行的六個「Do not」形成了嚴格的護欄，防止聚合器在整合時添加自己的臆測
動態日期注入：透過 datetime.now() 讓模型知道當前時間，解決知識截斷問題

設計五：搜尋 Prompt 的兩階段架構

search_prompts.py 設計了一套「查詢改寫 → 搜尋結果整合」的兩階段流程：

prompts/search_prompts.py — 搜尋 prompt 模組，展示了查詢改寫與搜尋整合的兩階段設計

階段一：查詢改寫

prompt_search_query = {
    "role": "user",
    "content": f"""
- Your task: Rephrase the user's input into 2 concise online search queries of under 6 keywords each.
- Googling these queries should find all information needed to respond to the user.
- You must only output the search queries, which should contain fewer than 6 online search keywords each.
- You must output exactly 2 search queries, formatted as ["<query_str_0>", "<query_str_1>"].
- Absolutely do not output anything else.
"""
Code language: PHP (php)

這裡的設計決策包括：

限制 6 個關鍵字：搜尋引擎對短查詢效果更好，過長的查詢反而會降低結果品質
生成 2 個查詢：覆蓋不同面向，但不會太多造成搜尋成本過高
嚴格的輸出格式（JSON array）：方便程式解析，避免模型輸出額外文字

階段二：搜尋結果整合

prompt_online_response = ["<instructions>
...
- If the search results can be relevant to the user's query as of today's date, create a bullet point list of relevant references with their href URLs. Skip irrelevant or out-of-date sources.
- Do not speculate. Do not use hypotheticals. Do not make assumptions. Do not include placeholders. Only provide citations from the search results.
...
</instructions>
...
"]
Code language: HTML, XML (xml)

搜尋結果整合 prompt 使用了 XML 風格的標籤（<instructions>, <search_results>, <user>）來結構化不同區塊。這種做法讓模型能更清楚地區分「指令」、「上下文」和「查詢」三者的邊界。

設計六：研究報告 Prompt 的 Strategy 模式

research_prompts.py 是整個專案中最龐大的模組，它實現了一個類似 Strategy Pattern 的報告生成系統：

prompts/research_prompts.py — 研究 prompt 模組，包含完整的報告生成策略體系

report_type_mapping = {
    ReportType.ResearchReport.value: generate_report_prompt,
    ReportType.ResourceReport.value: generate_resource_report_prompt,
    ReportType.OutlineReport.value: generate_outline_report_prompt,
    ReportType.CustomReport.value: generate_custom_report_prompt,
    ReportType.SubtopicReport.value: generate_subtopic_report_prompt,
    ReportType.DeepResearch.value: generate_deep_research_prompt,
}

def get_prompt_by_report_type(report_type):
    prompt_by_type = report_type_mapping.get(report_type)
    default_report_type = ReportType.ResearchReport.value
    if not prompt_by_type:
        warnings.warn(...)
        prompt_by_type = report_type_mapping.get(default_report_type)
    return prompt_by_type
Code language: JavaScript (javascript)

這個 mapping 設計讓報告類型與 prompt 生成函數解耦。新增一種報告類型只需要：寫一個新的 prompt 函數，然後在 mapping 中加一行。同時，get_prompt_by_report_type 提供了優雅的降級機制——未知的報告類型會 fallback 到預設的 ResearchReport，並發出 warning 而非拋出異常。

設計七：報告 Prompt 中的引用格式控制

每個報告生成 prompt 都包含了精細的引用格式控制：

reference_prompt = ""
if report_source == ReportSource.Web.value:
    reference_prompt = f"""
You MUST write all used source urls at the end of the report as references, and make sure to not add duplicated sources, but only one reference for each.
Every url should be hyperlinked: [url website](url)
Additionally, you MUST include hyperlinks to the relevant URLs wherever they are referenced in the report:

eg: Author, A. A. (Year, Month Date). Title of web page. Website Name. [url website](url)
"""
else:
    reference_prompt = f"""
You MUST write all used source document names at the end of the report as references, and make sure to not add duplicated sources, but only one reference for each."
"""
Code language: PHP (php)

這裡的設計根據資料來源（Web vs 本地文件）動態切換引用格式。Web 來源要求包含超連結和 APA 格式的完整引用，而本地文件來源只需要文件名。這種條件式 prompt 組裝是一個常見但容易出錯的模式——Ithy 用清晰的 if/else 結構讓邏輯一目了然。

設計八：深度研究的階層式上下文整合

generate_deep_research_prompt 是為多層次研究設計的：

def generate_deep_research_prompt(
    question: str,
    context: str,
    report_source: str,
    report_format="apa",
    tone=None,
    total_words=2000,
    language: str = "english"
):
Code language: JavaScript (javascript)

其 prompt 中有一段關鍵指令：

1. Synthesize information from multiple levels of research depth
2. Integrate findings from various research branches
3. Present a coherent narrative that builds from foundational to advanced insights
4. Maintain proper citation of sources throughout
Code language: JavaScript (javascript)

這暗示了 Ithy 在完整版本中支持一種「樹狀研究」模式：先做廣度搜尋產生多個子主題，再對每個子主題做深度研究，最後將所有層級的發現整合成一份報告。這種階層式的研究架構是 Deep Research 系統的典型設計。

設計九：自動代理選擇的 Auto-Agent 模式

research_prompts.py 中還包含了一個 auto_agent_instructions 函數：

def auto_agent_instructions():
    return """
This task involves researching a given topic, regardless of its complexity or the availability of a definitive answer. The research is conducted by a specific server, defined by its type and role, with each server requiring distinct instructions.
Agent
The server is determined by the field of the topic and the specific name of the server that could be utilized to research the topic provided. Agents are categorized by their area of expertise, and each server type is associated with a corresponding emoji.

examples:
task: "should I invest in apple stocks?"
response:
{
    "server": "💰 Finance Agent",
    "agent_role_prompt: "You are a seasoned finance analyst AI assistant..."
}
"""
Code language: PHP (php)

這是一個「meta-prompt」設計——讓 LLM 根據使用者的問題自動選擇最適合的代理角色。每個代理有不同的 emoji 標識和角色描述。這種設計讓系統能夠動態適應不同領域的查詢，而不需要預先硬編碼所有可能的專家類型。

設計十：Subtopic Report 的去重機制

處理長篇報告時，generate_subtopic_report_prompt 設計了一套完整的內容去重機制：

- Carefully review the existing headers and existing written contents provided below before writing any new subsections.
- Prevent any content that is already covered in the existing written contents.
- Do not use any of the existing headers as the new subsection headers.
- Do not repeat any information already covered in the existing written contents or closely related variations to avoid duplicates.
Code language: JavaScript (javascript)

這裡的設計是把「已生成的內容」作為上下文傳給下一輪生成，讓模型「知道」前面已經寫了什麼。這解決了分段生成長文時最大的痛點——內容重複。同時，它還要求模型在相似段落中明確標註差異：

### New header (similar to existing header)
While the previous section discussed [topic A], this section will explore [topic B].
Code language: CSS (css)

這是一個非常實用的 prompt 技巧，把「避免重複」從模糊的要求變成了具體的寫作格式指引。

Prompt 設計解讀

Ithy 的 prompt 設計展現了幾個值得注意的工程原則：

模組化與可組裝性：每個 prompt 都是獨立的函數，接受明確的參數（question、context、language、tone 等），回傳格式化好的字串。這讓 prompt 可以像程式元件一樣組裝和替換。

約束的漸進式堆疊：基礎約束（如「well-structured, coherent」）先寫，然後逐層加入更具體的約束（如引用格式、字數要求、語言選擇）。這種結構讓 prompt 容易維護和擴展。

情感激勵策略：在 generate_report_prompt 中出現了一句：

Please do your best, this is very important to my career.
Code language: JavaScript (javascript)

這是一個經過實驗驗證的 prompt 技巧——加入情感激勵能讓 LLM 產生更高品質的輸出。雖然看起來不科學，但在實踐中確實有效。

Negative prompt 的大量使用：幾乎每個 prompt 都包含明確的「不要做什麼」指令：「Do not speculate. Do not use hypotheticals. Do not make assumptions. Do not include placeholders.」這種 negative prompt 策略比只說「要做什麼」更能有效約束模型行為。

設計理念萃取

極簡核心 + 模組化擴展：main.py 的 50 行展示了 MoA 的完整流程，而 prompts/ 目錄提供了可替換的策略模組。這種設計讓核心邏輯保持穩定，同時允許無限擴展應用場景。值得學習的是：先用最少的程式碼驗證核心概念，再逐步豐富周邊模組。
多樣性是多模型架構的生命線：Reference models 的選擇刻意追求多樣性（不同廠商、不同規模、不同專長），而非選四個最強的模型。這體現了 ensemble learning 的核心洞察——多樣性比單一模型的強度更重要。
System Prompt 是上下文注入的最佳位置：將 reference models 的回應注入 system prompt 而非 user message，讓聚合器把它們當作背景知識處理。這是一個在多模型系統中管理上下文的實用技巧。
Prompt 即程式碼，需要軟體工程方法來管理：Ithy 把 prompt 當作函數來設計——有參數、有回傳值、有策略模式、有降級機制。這種「Prompt as Code」的思維是建構可維護 AI 系統的關鍵。
約束比自由更能提升品質：從聚合器的「六個 Do not」到報告 prompt 的引用格式要求，Ithy 的 prompt 設計反覆證明：明確的約束和 negative prompt 比開放式指令更能產生高品質輸出。

延伸思考

Ithy 的架構雖然精簡，但蘊含的設計模式可以直接應用到更複雜的系統中：

建構內部知識庫搜尋系統時，可以借鏡 search_prompts.py 的兩階段設計——先用 LLM 改寫查詢以適應搜尋引擎的特性，再用另一個 LLM 整合搜尋結果。查詢改寫的「6 個關鍵字以內」限制，是一個值得在自己的 RAG 系統中實驗的具體參數。

建構內容生成管線時，research_prompts.py 的 Strategy Pattern 和去重機制是一個現成的藍圖。特別是在需要生成長篇內容時，「把已生成內容作為下一輪上下文」的做法能有效避免重複，值得直接移植。

設計任何多步驟 AI 工作流時，Ithy 的「Fan-out / Fan-in + Streaming output」模式是一個經過驗證的起點。核心程式碼不到 50 行就能跑起來，這意味著你可以在半小時內搭建一個 prototype 來驗證你的多模型假設。

Vibe Coding：把觀念變成程式碼

以下是你可以直接給 AI 的 prompt 指令，將本文介紹的設計觀念應用到你的專案中：

Fan-out / Fan-in 多模型並行架構

場景：你想同時查詢多個 LLM 並整合回應，建構一個 Mixture-of-Agents 系統的初始原型

給 AI 的指令：

幫我用 Python asyncio 實作一個 Fan-out / Fan-in 的多模型呼叫架構。需求如下：
– 定義一個 reference_models 列表，包含 3-4 個不同的模型名稱（我會替換成實際的 model ID）
– 定義一個 aggregator_model
– 用 async def run_llm(model, prompt) 函數呼叫單一模型，包含指數退避重試（用硬編碼列表 [1, 2, 4] 控制等待秒數）
– 用 asyncio.gather 並行呼叫所有 reference models
– 將所有回應以編號列表格式注入聚合器的 system prompt（不是 user message），同時在 user message 重複原始問題
– 聚合器使用 stream=True 串流輸出最終結果
– temperature 設為 0.7 以保持模型回應的多樣性
– 整個實作控制在 50 行以內

效果：AI 會產出一個完整可執行的 Mixture-of-Agents 最小原型，包含並行呼叫、錯誤重試、和雙通道聚合邏輯，你只需替換 API client 和模型名稱就能跑起來

聚合器 Prompt 的分層設計

場景：你正在設計一個需要整合多來源資訊的 AI 系統（如 RAG、多模型聚合、搜尋結果摘要），需要撰寫聚合器的 prompt

給 AI 的指令：

幫我設計一個兩層式的聚合器 system prompt，用來整合多個來源的回應。採用 Ithy 專案的「基礎指令 + 增強指令」分層策略：

第一層（基礎指令）：告訴模型它收到了多個來源的回應，要求批判性評估、合成為單一高品質回答、不能簡單複製。

第二層（增強指令）：
– 要求找出多來源的共識點（consensus），優先呈現多數來源同意的觀點
– 合併相似概念，每個要點只出現一次（去重）
– 加入動態日期注入（用 datetime.now()）解決知識截斷問題
– 在結尾加上嚴格的 negative prompt 護欄：「Do not speculate. Do not use hypotheticals. Do not make assumptions. Do not include placeholders.」

請把 prompt 寫成 Python 字串變數，讓第二層用字串串接的方式疊加在第一層上，方便日後獨立修改。
我的應用場景是：[描述你的具體場景，例如「整合 3 個搜尋引擎的結果」或「合成 4 個 LLM 的回答」]

效果：AI 會產出一個模組化的聚合器 prompt，包含共識優先、去重、和嚴格護欄等設計，你可以根據自己的場景微調第二層而不影響基礎邏輯

Strategy Pattern 管理多種 Prompt 策略

場景：你的專案需要根據不同的任務類型（如報告、摘要、分析）使用不同的 prompt 模板，需要一個可擴展的管理機制

給 AI 的指令：

幫我用 Python 實作一個 Strategy Pattern 的 prompt 管理系統，參考 Ithy 專案的 research_prompts.py 設計：

1. 定義一個 Enum 類別列出所有任務類型（例如：[列出你的任務類型，如 Summary、Analysis、Report、Translation]）
2. 為每種任務類型寫一個 prompt 生成函數，接受統一的參數介面（question, context, language, tone, max_words）
3. 建立一個 type_mapping 字典，將任務類型對應到 prompt 函數
4. 實作一個 get_prompt_by_type(task_type) 函數，包含優雅降級機制：未知的任務類型要 fallback 到預設類型並發出 warnings.warn，而非拋出異常
5. 每個 prompt 函數中根據資料來源（如 web vs local）動態切換引用格式

新增任務類型只需要：寫一個 prompt 函數 + 在 mapping 加一行。

效果：AI 會產出一個解耦的 prompt 管理架構，讓你能輕鬆新增和替換 prompt 策略，同時具備安全的降級機制防止系統因未知類型而崩潰

兩階段搜尋：查詢改寫 + 結果整合

場景：你在建構一個 RAG 系統或搜尋增強的 AI 應用，想提升搜尋品質

給 AI 的指令：

幫我設計一個兩階段的搜尋增強流程，參考 Ithy 專案 search_prompts.py 的設計：

階段一（查詢改寫）：
– 寫一個 prompt 讓 LLM 將使用者的自然語言問題改寫為 2 個簡潔的搜尋查詢
– 每個查詢限制 6 個關鍵字以內（搜尋引擎對短查詢效果更好）
– 嚴格要求輸出格式為 JSON array：[“query1”, “query2”]
– 禁止輸出任何其他內容

階段二（結果整合）：
– 寫一個 prompt 讓 LLM 整合搜尋結果，使用 XML 風格標籤區隔不同區塊：<instructions> 放指令、<search_results> 放搜尋結果、<user> 放原始問題
– 要求過濾過時或無關的來源，只保留相關的
– 要求附上來源 URL 的超連結引用
– 加入 negative prompt 護欄防止模型自行推測

請用 Python 實作這兩個 prompt，並寫一個示範流程串接兩個階段。
我使用的搜尋 API 是：[你的搜尋引擎，如 Google Search API / Tavily / Bing]

效果：AI 會產出一個完整的兩階段搜尋增強管線，包含查詢最佳化和結果整合的 prompt，你可以直接整合到自己的 RAG 系統中

長文內容去重機制

場景：你需要用 AI 分段生成長篇內容（報告、文件、教學文章），但擔心各段之間內容重複

給 AI 的指令：

幫我設計一個長文分段生成的去重機制，參考 Ithy 專案 Subtopic Report 的設計模式：

1. 寫一個 prompt 模板，在生成每個新段落時，將「已生成的所有章節標題和內容摘要」作為上下文傳入
2. 在 prompt 中加入以下去重指令：
– 仔細檢閱已有的標題和內容再開始寫新段落
– 禁止重複已涵蓋的資訊或其近似變體
– 不得使用已有的標題作為新段落標題
3. 當新段落與既有段落主題相近時，要求模型用以下格式明確標註差異：
「### 新標題（與既有段落相關）」
「前一節討論了 [主題 A]，本節將探討 [主題 B]」
4. 實作一個 Python 函數，接受已生成內容列表和下一個子主題，組裝完整 prompt 並呼叫 LLM

我要生成的文件主題是：[你的主題]
預計分成 [N] 個段落

效果：AI 會產出一個分段生成長文的框架，包含上下文傳遞和去重 prompt，讓你能生成結構完整、不重複的長篇內容

Ithy 原始碼解讀：50 行程式碼裡的 Mixture-of-Agents 設計哲學

專案概覽

架構總覽

核心設計解析

設計一：極簡的 Fan-out / Fan-in 架構

設計二：asyncio 並行呼叫與指數退避

設計三：聚合的雙通道設計——System Prompt 注入回應

設計四：聚合器 Prompt 的分層設計

設計五：搜尋 Prompt 的兩階段架構

設計六：研究報告 Prompt 的 Strategy 模式

設計七：報告 Prompt 中的引用格式控制

設計八：深度研究的階層式上下文整合

設計九：自動代理選擇的 Auto-Agent 模式

設計十：Subtopic Report 的去重機制

Prompt 設計解讀

設計理念萃取

延伸思考

Vibe Coding：把觀念變成程式碼

Fan-out / Fan-in 多模型並行架構

聚合器 Prompt 的分層設計

Strategy Pattern 管理多種 Prompt 策略

兩階段搜尋：查詢改寫 + 結果整合

長文內容去重機制

延伸閱讀

發佈留言取消回覆

專案概覽

架構總覽

核心設計解析

設計一：極簡的 Fan-out / Fan-in 架構

設計二：asyncio 並行呼叫與指數退避

設計三：聚合的雙通道設計——System Prompt 注入回應

設計四：聚合器 Prompt 的分層設計

設計五：搜尋 Prompt 的兩階段架構

設計六：研究報告 Prompt 的 Strategy 模式

設計七：報告 Prompt 中的引用格式控制

設計八：深度研究的階層式上下文整合

設計九：自動代理選擇的 Auto-Agent 模式

設計十：Subtopic Report 的去重機制

Prompt 設計解讀

設計理念萃取

延伸思考

Vibe Coding：把觀念變成程式碼

Fan-out / Fan-in 多模型並行架構

聚合器 Prompt 的分層設計

Strategy Pattern 管理多種 Prompt 策略

兩階段搜尋：查詢改寫 + 結果整合

長文內容去重機制

延伸閱讀

相關文章

NanoClaw 原始碼解讀：用極簡架構打造安全的個人 AI 助理

nanobot 原始碼解讀：用 3,400 行程式碼重建一個完整 AI Agent 框架

Everything Claude Code 原始碼解讀：用 Plugin 架構打造 AI 編程助手的知識體系

發佈留言取消回覆