MUST · 手搓你的 AI Agent · 組件 10

分工示意

像編輯部一樣分工:便宜模型起草、較強模型覆核、人來裁定。三個崗位各選由誰做,看一學期的費用、你的時間與風險。

先看整體:一件工作,三個崗位

組件 04 說帶得走的是 Harness;這一頁看「我的 Agent」的另一半——你與多個 AI 怎樣分工

一份報告在編輯部裡要過三個崗位:起草(寫初稿)、覆核(挑錯、對照要求)、裁定(主編簽發:決定出不出、責任誰負)。AI 時代這三個崗位可以分別交給便宜的模型較強的模型、或你自己。分配得好,費用是「頂級一條龍」的零頭,而且不一定比它差——因為覆核者不是起草者,而簽發的人是你。分配得差,就是又貴又沒人負責。本頁的「便宜檔/較強檔/頂級檔」只是價位分檔,代表「通常較弱/較強」的示意;真正的能力要靠評測。

排你的編輯部

任務:「為我的學科寫一篇 1,200 字的報告」,一學期做 30 次。三個崗位各選由誰做。

每一輪=覆核者寫意見 → 起草者改一次。0 輪=只覆核不改。

每週約兩次作業、報告或簡報,一學期約 30 次。

崗位由誰次數詞元(token,輸入/輸出)本崗位費用(×次數)你的時間(×次數)
判語(教學示意)
價格表與詞元預算(可改)

每次任務的詞元預算:起草 輸入 2,000/輸出 1,600;覆核 輸入 4,000/輸出 600;改稿 輸入 4,500/輸出 1,600;人裁定不花詞元。人的時間:起草 40 分鐘、覆核 15 分鐘、改稿每輪 20 分鐘、裁定 5 分鐘(示意)。價格為每百萬詞元、人民幣。

四種排法並排

同一個任務、同一學期次數、同一輪數。你目前的排法以青色標出。

排法起草 → 覆核 → 裁定一學期費用你的時間風險

重點一

頂級一條龍,未必最好

起草是「產量」工作,便宜模型通常足夠;覆核是「判斷」工作,值得用較強的。把較強模型只放在覆核崗,費用降一大截,品質未必下降——因為大部分錯誤是在覆核那一步才被抓到的。

重點二

覆核者不能是起草者

同一個模型審自己的稿,看不見自己的盲點——就像作者校對自己的文章。換一個模型、或換一個人,才是真正的第二雙眼睛。組件 02 說「以證據驗證而非以宣稱」,這是同一件事。

試試:起草與覆核都選同一檔,看判語怎樣說。
重點三

裁定不能省,責任在你

裁定就是主編簽發那一步。AI 可以起草、可以覆核,但交出去的是你的名字。「用了 AI」不扣分,「講不出 AI 做了甚麼」才扣分(本課評核原則)。裁定崗位選「略過」,判語一定是紅的。

裁定 5 分鐘做甚麼:讀覆核意見、抽查兩處引用、決定交不交。

想一想

  1. 把改稿輪數拉到 3,哪一種排法的費用升得最快?為甚麼「覆核用較強檔」的編輯部排法,相對頂級一條龍升得慢那麼多?
  2. 你的學科裡,哪一種任務應該由人起草、AI 覆核(反過來分工)?提示:責任重、或者你本來就想練習寫的那種。
  3. 一學期 30 次任務,「編輯部」排法花的錢:連一杯咖啡都不到、一杯咖啡、還是一頓飯?看 KPI 再答。那你每次 5 分鐘的裁定,值多少?
  4. 如果覆核者也是一個 Agent(子代理,subagent),它需要看到起草者的哪些東西、不該看到哪些?(提示:污染會話,組件 02。)
教師提示(討論後展開)

第 1 題:每多一輪=多一次覆核+一次改稿;頂級一條龍兩項都付頂級價,升得最快;編輯部排法覆核付較強價、改稿付便宜價,兩項都遠低於頂級,所以升得慢。第 2 題:學位論文核心章節、要簽名的文件、練習寫作能力的功課——人起草、AI 只挑錯。第 3 題:按頁內價格,編輯部排法預設(30 次、1 輪)一學期約 ¥0.64;拉到 3 輪、100 次也只是約 ¥4.3;頂級一條龍預設約 ¥14.5。重點不是省錢,是你的時間放在判斷而不是打字。第 4 題:覆核者只需要看初稿與要求,不需要看起草者的整段對話——分開的上下文(context)才是真正的第二雙眼睛,也避免一個會話裡的錯誤污染另一個。

問你的 Agent(動手時間開頭 10 分鐘):問它「你現在用的是哪一個模型?如果我要你起草用便宜檔、覆核用較強檔,要改設定裡的哪一行?」再叫它示範一次:用便宜檔起草一段,換較強檔覆核,最後由你裁定。

同一概念、不同名字

概念dsh(DeepSeek Harness)Claude CodeWorkBuddy
換模型provider/model(settings 內每個 agent 可各自指定)/model;子代理可另設模型模型/自定義模型
覆核者是另一個 Agentsubagent、send_messagesubagent(獨立上下文)專家團
便宜起草、較強覆核(成本路由)按 agent 指定不同 model主會話用強模型、子代理用便宜模型(或相反)積分倍率
人裁定approval、ask_user_questionpermission prompt、AskUserQuestion二次確認