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

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

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

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

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

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

三個(gè)代理并行，每個(gè)來自不同模型實(shí)驗(yàn)室，每個(gè)鎖定一個(gè)角色和一個(gè)認(rèn)知操作：

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

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

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

關(guān)鍵設(shè)計(jì)：工具鎖定。每個(gè)評審代理只能調(diào)用特定工具——安全代理可調(diào)威脅建模檢查表，正確性代理可調(diào)測試生成器，完整性代理可調(diào)需求追蹤器。不能調(diào)用執(zhí)行工具、不能調(diào)用文件系統(tǒng)、不能調(diào)用網(wǎng)絡(luò)。認(rèn)知隔離通過架構(gòu)強(qiáng)制執(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%），但第三種在標(biāo)記為"需仲裁"的案例中，人工復(fù)核后發(fā)現(xiàn)實(shí)際問題的比例更高（78% vs 61%）。便宜模型更吵，但吵得更值得聽。

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

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

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

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