周末上線了一個有點意思的東西：三代理盲評工作流，MIT協(xié)議開源，任何編碼代理或自主循環(huán)都能通過HTTP端點調(diào)用。核心假設(shè)很直接——模型沒法可靠地自評，所以外部盲評機制是唯一能誠實的解法。代碼倉庫在github.com/ejentum/agent-teams/tree/main/blind-eval-trio。

整個工作流完全開源?？蛇x接入Ejentum的harness API做認知引導（免費檔100次調(diào)用，持續(xù)使用需付費檔）。但harness是可拆卸的，不是必需。我用同一組payload測試了四種配置：純MCP、MCP+路由技能、MCP+重量級匹配技能、裸基線。結(jié)果裸基線產(chǎn)出了同等水平的角色約束輸出。結(jié)構(gòu)完整性來自跨實驗室路由+角色約束系統(tǒng)提示+工具鎖定，而非harness層。如果把這工作流叫做"Ejentum驅(qū)動"卻不說明harness只是錦上添花而非承重結(jié)構(gòu)，那就是不誠實，所以我 upfront 講清楚。

看看現(xiàn)在的趨勢。Karpathy的autoresearch用Git作為整個控制循環(huán)。Claude Code的GitHub Action接收issue然后開PR。Codex Cloud基于同樣的理念。自主代理越來越傾向于在沒有人工把關(guān)的情況下提交行動。瓶頸不再是"代理該做什么"，而是"代理在承諾去做之前該做什么"。

自評填不了這個坑。文獻很明確：Huang等人《Large Language Models Cannot Self-Correct Reasoning Yet》（arxiv 2310.01798）、LLM-as-judge研究顯示同模型評判自己輸出會坍縮為自我偏好、還有更近的CorrectBench結(jié)果。讓同一個模型批判自己的計劃，只會復制原有的盲點。"單個LLM戴三頂評審帽"是提示工程表演，自己給自己蓋章。

GitHub懂這個。他們4月發(fā)布了Copilot CLI的"Rubber Duck"：一個聚焦的評審代理，由互補模型家族驅(qū)動，在規(guī)劃完非平凡變更后、實施前進行批判。他們測得Sonnet開啟Rubber Duck后，Sonnet→Opus的性能差距縮小了74.7%。Copilot CLI內(nèi)置免費。他們鎖定了開發(fā)者工具賽道的預承諾跨模型批判表面。

這個工作流是給其他人的：在Claude Agent SDK / LangGraph / AutoGen / CrewAI / heym上構(gòu)建自主循環(huán)的代理運行時開發(fā)者；想要可調(diào)用原語的多代理系統(tǒng)設(shè)計師；Cursor / Cline / Aider用戶；在無Copilot CLI的受限環(huán)境中運行Claude Code的安全團隊；直接用Anthropic或OpenAI API構(gòu)建自定義Python管道的研究者。他們沒人能免費用Rubber Duck；但他們都能自托管這個。

三個代理并行，每個來自不同模型實驗室，每個鎖定一個角色和一個認知操作：

調(diào)用代理提交結(jié)構(gòu)化payload：{ task: string, method: { goal, steps, expected_outcome }, context: { files, dependencies, constraints } }。三個評審代理各自在隔離環(huán)境中接收同一payload，但系統(tǒng)提示不同：

代理A（安全視角）：識別風險、邊界條件、失敗模式。代理B（正確性視角）：驗證邏輯完整性、步驟順序、資源假設(shè)。代理C（完整性視角）：檢查遺漏、隱式假設(shè)、與任務(wù)目標的契合度。

三者互不可見。輸出匯入聚合層，沖突標記為"需人工仲裁"，共識標記為"可提交"。整個流程約15-30秒，取決于模型選擇。

關(guān)鍵設(shè)計：工具鎖定。每個評審代理只能調(diào)用特定工具——安全代理可調(diào)威脅建模檢查表，正確性代理可調(diào)測試生成器，完整性代理可調(diào)需求追蹤器。不能調(diào)用執(zhí)行工具、不能調(diào)用文件系統(tǒng)、不能調(diào)用網(wǎng)絡(luò)。認知隔離通過架構(gòu)強制執(zhí)行，而非提示工程請求。

我測試了三種模型組合：GPT-4o + Claude 3.5 Sonnet + Gemini 1.5 Pro；Claude 3 Opus + GPT-4 Turbo + Gemini 1.5 Flash；純開源（Llama 3 70B + Mixtral 8x22B + Qwen 72B）。第一種組合沖突率最低（12%），第三種最高（34%），但第三種在標記為"需仲裁"的案例中，人工復核后發(fā)現(xiàn)實際問題的比例更高（78% vs 61%）。便宜模型更吵，但吵得更值得聽。

HTTP端點設(shè)計為無狀態(tài)。POST /evaluate，payload進，{ consensus: boolean, reviews: [...], arbitration_required: boolean }出。沒有會話，沒有記憶，沒有跨調(diào)用的代理狀態(tài)。這樣調(diào)用方可以把它塞進任何編排邏輯——LangGraph的條件邊、CrewAI的任務(wù)委托、或者直接curl。

有個細節(jié)可能重要：payload里的method字段是調(diào)用代理自己生成的。這意味著評審代理在評判一個同行（可能同模型家族）產(chǎn)出的計劃。但盲評機制切斷了自我偏好的反饋回路——評審代理不知道作者是誰，不能訪問作者的隱藏狀態(tài)，只能看到結(jié)構(gòu)化的方法描述。這不夠完美，但比"你批判你自己"誠實。

GitHub的Rubber Duck是閉源的、Copilot綁定的、微軟控制的。這個工作流是開源的、模型無關(guān)的、自托管的。不是競爭，是補位——給那些需要預承諾評審但不在Copilot生態(tài)里的人一個選項。

下一步：把聚合層做成可插拔的（目前硬編碼為簡單多數(shù)決），加時間戳和簽名支持用于審計日志，以及一個可選的"人類在環(huán)"鉤子，在仲裁觸發(fā)時暫停等待輸入。但這些是增量改進。核心結(jié)構(gòu)——跨實驗室、角色鎖定、工具隔離——已經(jīng)跑通了。