先說結(jié)論如果你所在的團(tuán)隊(duì)已經(jīng)用上或正準(zhǔn)備用 OpenCode 這類 AI 編程終端那「Oh My OpenCode」就是給這些終端注入團(tuán)隊(duì)協(xié)作能力的一套編排框架。它解決的不是“怎么讓 AI 寫一段代碼”而是“怎么讓多個(gè)各司其職的 AI Agent 像一支小隊(duì)一樣圍繞同一個(gè)任務(wù)協(xié)同工作”。這篇指南我會(huì)從設(shè)計(jì)思路、安裝配置、角色定義、協(xié)作流程到問題排查完整過一遍目標(biāo)是讓你看完之后能自己搭出一個(gè)最小可用的 AgentTeam。我自己在接手一個(gè)已有三年歷史的遺留系統(tǒng)時(shí)被跨模塊改造任務(wù)反復(fù)折騰過。單個(gè) Agent 在獨(dú)立對(duì)話里能寫得挺好但一放進(jìn)完整的、包含設(shè)計(jì)約束和歷史包袱的真實(shí)項(xiàng)目里它經(jīng)常改一個(gè)地方、漏三個(gè)地方。后來我把任務(wù)拆成架構(gòu)、編碼、評(píng)審三個(gè)角色才真正體會(huì)到“團(tuán)隊(duì)協(xié)作”對(duì)于 AI 編碼這件事有多重要。Oh My OpenCode 的設(shè)計(jì)思路正好和我這套實(shí)踐對(duì)上了所以這篇實(shí)戰(zhàn)指南我會(huì)結(jié)合這套思路來寫。1. 項(xiàng)目全貌與 AgentTeam 設(shè)計(jì)思路1.1 從一個(gè)讓所有開發(fā)者皺眉的痛點(diǎn)說起用過 AI 編程助手的人應(yīng)該都有這種體驗(yàn)在 IDE 里新建一個(gè) Demo、寫個(gè)算法題、生成一段爬蟲腳本AI 的表現(xiàn)堪稱驚艷。但一旦把同樣的工具扔進(jìn)一個(gè)真實(shí)的、多模塊、有歷史包袱的工程里問題就來了。首先是上下文失焦。一個(gè)會(huì)話里既能聊需求、又能看代碼、還要讓它跑測試聊到第十輪之后AI 已經(jīng)開始“選擇性遺忘”早期約束了。其次是職責(zé)混亂。同一個(gè) Agent 既當(dāng)架構(gòu)師又當(dāng)實(shí)現(xiàn)者還兼職 Code Reviewer你會(huì)看到一個(gè)非常擰巴的現(xiàn)象它在設(shè)計(jì)接口時(shí)畏手畏腳在實(shí)現(xiàn)時(shí)又過度設(shè)計(jì)。單獨(dú)看每一步好像都對(duì)連起來看就像一個(gè)沒人負(fù)責(zé)的產(chǎn)品。我試過用純 Prompt 去約束這個(gè)過程也試過把大任務(wù)拆成多個(gè)獨(dú)立的 OpenCode 會(huì)話手工搬運(yùn)上下文。效果有但手工成本極高你需要自己維護(hù)“這個(gè) Agent 做到了哪一步、下一個(gè) Agent 需要知道什么”的狀態(tài)同步一旦任務(wù)超過五六個(gè)步驟這個(gè)同步工作本身就會(huì)成為新的瓶頸。1.2 AgentTeam 的三種典型角色在我反復(fù)試驗(yàn)后一個(gè)穩(wěn)定能出活的 AgentTeam最少需要三類角色而不是越多越好。第一類是架構(gòu) Agent它的職責(zé)是理解需求、閱讀代碼結(jié)構(gòu)、產(chǎn)出技術(shù)方案。它不需要寫很多代碼但需要具備很強(qiáng)的代碼庫全局理解能力能把一個(gè)模糊需求翻譯成具體的模塊改動(dòng)清單。第二類是開發(fā) Agent它的職責(zé)是按照方案實(shí)現(xiàn)功能、寫測試、處理編譯錯(cuò)誤。它需要精細(xì)化操作文件的能力但它不應(yīng)該被允許做需求取舍。第三類是評(píng)審 Agent它的職責(zé)是審查改動(dòng)是否滿足需求、是否引入回歸風(fēng)險(xiǎn)、代碼風(fēng)格是否一致。它不直接改代碼只產(chǎn)出問題和建議。有人會(huì)問這三個(gè)角色各用一個(gè)獨(dú)立的 OpenCode 實(shí)例不就行了我最初也是這么干的但很快發(fā)現(xiàn)缺一個(gè)東西編排層。誰來觸發(fā)下一個(gè) Agent上一個(gè) Agent 的產(chǎn)出物怎么傳遞給下一個(gè)如果開發(fā) Agent 發(fā)現(xiàn)方案有漏洞怎么回退給架構(gòu) Agent這些問題靠人肉協(xié)調(diào)在小團(tuán)隊(duì)里還能忍一旦任務(wù)頻繁就完全失控了。1.3 為什么選擇 Oh My OpenCode 做編排層Oh My OpenCode 給我的感覺像是給原生的 OpenCode 終端外掛了一套“組織流程”。它通過預(yù)定義的 Agent 角色、規(guī)則文件和 workflow 配置把多 Agent 的協(xié)作流程固化成了項(xiàng)目里看得見、改得動(dòng)的文件。選擇它而不是純手寫腳本最核心的原因是三點(diǎn)。第一點(diǎn)是狀態(tài)可見。每個(gè) Agent 的輸入輸出都有明確記錄任務(wù)進(jìn)行到哪一步、誰產(chǎn)生的、產(chǎn)生了什么全部有跡可循。第二點(diǎn)是流程可配置。你不需要改代碼只需要修改 YAML 格式的工作流配置就能調(diào)整協(xié)作方式比如先評(píng)審后合并、開發(fā)失敗自動(dòng)重試幾次、關(guān)鍵節(jié)點(diǎn)需要人工確認(rèn)。第三點(diǎn)是權(quán)限隔離?？梢韵拗崎_發(fā) Agent 只讀特定目錄、限制評(píng)審 Agent 只能讀取變更內(nèi)容避免多個(gè) Agent 同時(shí)操作文件導(dǎo)致互相覆蓋。這三點(diǎn)聽著簡單但在真實(shí)項(xiàng)目里極其重要。狀態(tài)可見讓你敢把任務(wù)交給 Agent 之后去干別的事流程可配置讓你能根據(jù)團(tuán)隊(duì)習(xí)慣靈活調(diào)整權(quán)限隔離則避免了很多“兩個(gè) Agent 改同一個(gè)文件”的災(zāi)難性現(xiàn)場。2. 環(huán)境準(zhǔn)備與核心安裝實(shí)操2.1 基礎(chǔ)環(huán)境要求Oh My OpenCode 本身不依賴重型服務(wù)它運(yùn)行在你的開發(fā)機(jī)或者 CI 容器里。我建議至少準(zhǔn)備這樣一套環(huán)境Linux/macOS 系統(tǒng)Windows 使用 WSL2 也沒問題Node.js 18 以上版本Git 2.30 以上以及一個(gè)能正常運(yùn)行的 OpenCode 終端環(huán)境。模型層面你需要準(zhǔn)備一個(gè)兼容 OpenAI 接口的模型服務(wù)地址和 API Key。如果公司有內(nèi)部部署的大模型網(wǎng)關(guān)直接填內(nèi)網(wǎng)地址如果沒有可以使用本地啟動(dòng)的模型服務(wù)。需要強(qiáng)調(diào)的是模型能力直接決定了 AgentTeam 的上限。如果團(tuán)隊(duì)在用 7B 量級(jí)的小模型那架構(gòu) Agent 的代碼理解能力和評(píng)審 Agent 的上下文推理都會(huì)明顯受限整個(gè)團(tuán)隊(duì)的產(chǎn)出質(zhì)量會(huì)打折。我在環(huán)境準(zhǔn)備上踩過的最大一個(gè)坑是忽略了 OpenCode 本身對(duì) function call 能力的依賴。Agent 要和工具交互讀文件、執(zhí)行命令、搜索代碼依賴模型原生支持 function calling。如果模型的接口聲明支持、實(shí)際返回格式不標(biāo)準(zhǔn)Agent 會(huì)反復(fù)嘗試解析工具調(diào)用結(jié)果表現(xiàn)得像“死循環(huán)”。所以模型選型時(shí)建議用一個(gè)你自己測過 function call 穩(wěn)定性的大模型再談后面的一切。2.2 安裝 Oh My OpenCode 與初始化安裝過程很簡單官方提供了腳本方式。打開終端執(zhí)行curl -fsSL https://install.ohmyopencode.dev | bash腳本會(huì)檢測環(huán)境、安裝核心 CLI 到用戶目錄并自動(dòng)把oh-my-opencode命令加入 PATH。安裝完成后驗(yàn)證一下版本oh-my-opencode --version接下來進(jìn)入你的項(xiàng)目目錄執(zhí)行初始化命令cd /path/to/your/project oh-my-opencode init初始化會(huì)在項(xiàng)目根目錄生成一個(gè).oh-my-opencode/文件夾里面包含默認(rèn)的 agents、rules、workflows 模板。此時(shí)我建議你把這些模板文件提交到 Git 倉庫讓整個(gè)團(tuán)隊(duì)共享同一套 Agent 配置。Agent 的配置和代碼一樣也需要版本管理和 Code Review。2.3 配置倉庫目錄結(jié)構(gòu)與核心文件初始化的目錄結(jié)構(gòu)大概是這樣的.oh-my-opencode/ ├── agents/ │ ├── architect.md │ ├── developer.md │ └── reviewer.md ├── rules/ │ ├── general.md │ ├── frontend.md │ └── backend.md ├── workflows/ │ └── default.yaml ├── prompts/ │ └── handoff.md └── settings.jsonagents/下面是每個(gè) Agent 的角色定義文件使用 Markdown 格式核心是描述職責(zé)邊界和工作習(xí)慣。rules/是全局或分技術(shù)棧的硬性約束。workflows/定義多 Agent 協(xié)作流程。prompts/handoff.md是 Agent 之間交接任務(wù)時(shí)的上下文摘要模板。這個(gè)目錄結(jié)構(gòu)本身就是一個(gè)團(tuán)隊(duì)規(guī)范。新人加入項(xiàng)目看完agents/和rules/就能理解整個(gè) AI 團(tuán)隊(duì)是怎么運(yùn)作的。它比任何文檔都直接因?yàn)檫@套規(guī)則就是 AI 實(shí)際執(zhí)行時(shí)用的同一套規(guī)則。3. 多 Agent 協(xié)作編排實(shí)戰(zhàn)3.1 定義第一個(gè) Agent架構(gòu) Agent架構(gòu) Agent 的角色文件我建議重點(diǎn)寫清三個(gè)部分職責(zé)邊界、工作流程、協(xié)作約束。下面這個(gè)是我經(jīng)過多次調(diào)整后的模板--- name: architect model: coding-model-1 description: 負(fù)責(zé)需求分析、代碼結(jié)構(gòu)探索與技術(shù)方案設(shè)計(jì) temperature: 0.2 tools: - code_search - file_read - directory_tree - git_log --- # 職責(zé) - 分析需求描述拆解為具體的模塊改動(dòng)清單 - 閱讀關(guān)鍵代碼路徑確認(rèn)改動(dòng)可行性和影響范圍 - 輸出技術(shù)方案文檔包含改動(dòng)步驟、涉及文件、風(fēng)險(xiǎn)點(diǎn) # 工作流程 1. 先用 directory_tree 了解項(xiàng)目整體結(jié)構(gòu) 2. 用 code_search 定位與需求相關(guān)的核心模塊 3. 閱讀關(guān)鍵文件確認(rèn)接口和依賴關(guān)系 4. 輸出方案文檔保存到 docs/proposals/ 目錄 # 協(xié)作約束 - 不直接修改業(yè)務(wù)代碼只產(chǎn)出方案文檔 - 如果發(fā)現(xiàn)需求本身有歧義在方案文檔中標(biāo)記待確認(rèn) - 方案必須包含明確的驗(yàn)收標(biāo)準(zhǔn)供后續(xù)開發(fā) Agent 使用注意temperature: 0.2架構(gòu) Agent 的任務(wù)是理解分析需要盡量低隨機(jī)性。它不需要?jiǎng)?chuàng)意它需要穩(wěn)定和準(zhǔn)確。協(xié)作約束里最重要的就是“不直接修改業(yè)務(wù)代碼”這個(gè)邊界能有效避免架構(gòu) Agent 在分析過程中順手改幾行、結(jié)果沒人知道的問題。3.2 定義第二個(gè) Agent開發(fā) Agent開發(fā) Agent 是團(tuán)隊(duì)里干活最多的角色它的配置重點(diǎn)在工具權(quán)限和編輯習(xí)慣上。--- name: developer model: coding-model-2 description: 負(fù)責(zé)按方案實(shí)現(xiàn)功能、編寫測試與修復(fù)問題 temperature: 0.4 tools: - file_read - file_edit - directory_tree - shell_exec - grep_search allowed_paths: - src/ - tests/ - docs/ denied_paths: - .git/ - .oh-my-opencode/ --- # 職責(zé) - 按照架構(gòu) Agent 輸出的方案文檔實(shí)現(xiàn)代碼 - 為新增功能補(bǔ)充單元測試 - 處理編譯錯(cuò)誤和測試失敗 # 工作流程 1. 讀取方案文檔 2. 按方案中列出的文件清單逐個(gè)實(shí)現(xiàn) 3. 每完成一個(gè)模塊執(zhí)行一次構(gòu)建和測試 4. 全部完成后更新方案文檔的實(shí)現(xiàn)狀態(tài) # 協(xié)作約束 - 遇到方案無法實(shí)現(xiàn)的地方把問題記錄到 IMPLEMENTATION_NOTES.md - 不允許修改方案文檔中的設(shè)計(jì)決策部分 - 執(zhí)行 shell 命令時(shí)不允許運(yùn)行 rm -rf 或 git pushallowed_paths和denied_paths非常重要。前者確保開發(fā) Agent 只碰業(yè)務(wù)代碼和測試不會(huì)去亂改框架配置或.oh-my-opencode自身。后者則是對(duì)危險(xiǎn)操作的一層硬約束就算模型誤判了意圖也沒有對(duì)應(yīng)的工具權(quán)限去執(zhí)行。3.3 任務(wù)編排從 Issue 到 MR 的工作流三個(gè) Agent 定義好之后還需要一個(gè)工作流把它們串起來。workflows/default.yaml是我日常最常用的一套流程name: default_issue_to_mr description: 從任務(wù)描述到產(chǎn)出合并請(qǐng)求的標(biāo)準(zhǔn)流程 trigger: event: manual params: issue: string # 任務(wù)描述或 Issue 編號(hào) steps: - id: architecture agent: architect input: task: ${issue} output: proposal: /docs/proposals/${timestamp}-${task_slug}.md next_on_success: development - id: development agent: developer input: proposal: ${architecture.proposal} output: notes: /IMPLEMENTATION_NOTES.md next_on_success: review - id: review agent: reviewer input: proposal: ${architecture.proposal} implementation_notes: ${development.notes} output: review_report: /docs/reviews/${timestamp}-review.md next_on_success: complete - id: complete agent: none action: create_mr這套流程的核心思路是“管線化”。架構(gòu)階段產(chǎn)出方案開發(fā)階段按方案實(shí)現(xiàn)評(píng)審階段驗(yàn)證質(zhì)量。每個(gè)階段的輸出都會(huì)透傳給下一個(gè)階段而且原始文檔都保存在項(xiàng)目里事后可以追溯任何一次決策過程。用的時(shí)候一行命令就能跑完整條流程oh-my-opencode run --workflow default.yaml --param issue把登錄模塊的接口超時(shí)從5秒調(diào)整為3秒并補(bǔ)充對(duì)應(yīng)的測試4. 真實(shí)場景復(fù)現(xiàn)跨模塊重構(gòu)任務(wù)全過程4.1 場景設(shè)定與分析光說原理有點(diǎn)虛下面我用一個(gè)實(shí)際跑過的任務(wù)來復(fù)現(xiàn)整個(gè)流程。任務(wù)是“把訂單模塊的狀態(tài)字段從字符串枚舉遷移到整數(shù)枚舉并保證所有依賴模塊不回歸”。這是典型的跨模塊重構(gòu)涉及數(shù)據(jù)庫映射、業(yè)務(wù)邏輯、接口返回、前端展示四個(gè)層次。接到任務(wù)后我執(zhí)行了上面那條工作流命令。架構(gòu) Agent 首先分析項(xiàng)目結(jié)構(gòu)并定位了相關(guān)文件。它產(chǎn)出的方案文檔里列出了四類改動(dòng)點(diǎn)和每類的涉及文件包括持久層映射文件、業(yè)務(wù)狀態(tài)判斷邏輯、接口文檔定義以及前端狀態(tài)展示組件。方案最后附了三項(xiàng)驗(yàn)收標(biāo)準(zhǔn)所有對(duì)外接口的狀態(tài)碼兼容舊值、數(shù)據(jù)庫存量數(shù)據(jù)有遷移腳本、核心鏈路測試全部通過。這個(gè)產(chǎn)出質(zhì)量在我預(yù)期之上。架構(gòu) Agent 沒有急于動(dòng)手改代碼而是把影響面完整梳理了出來尤其是“接口兼容舊值”這一點(diǎn)是真實(shí)項(xiàng)目里最容易遺漏的隱性需求。4.2 三階段推進(jìn)過程拆解開發(fā) Agent 收到方案后的執(zhí)行過程可以分成三個(gè)階段。第一階段是狀態(tài)枚舉定義與映射層改動(dòng)。它新建了枚舉類修改了持久層映射配置并跑了一次構(gòu)建確認(rèn)編譯通過。這里有個(gè)細(xì)節(jié)值得提它每完成一個(gè)模塊就構(gòu)建一次而不是攢到最后統(tǒng)一處理這讓問題定位變得非常快。第二階段是業(yè)務(wù)層依賴調(diào)整。方案文檔里的模塊清單在這一階段發(fā)揮了大作用開發(fā) Agent 按照文件清單逐個(gè)修改沒有出現(xiàn)“改一個(gè)漏一個(gè)”的情況。但過程中它發(fā)現(xiàn)了一個(gè)方案沒有預(yù)判到的問題某個(gè)歷史報(bào)表查詢直接依賴了舊的狀態(tài)字符串硬編碼在 SQL 里。它沒有自作主張修改方案而是把這個(gè)情況追加寫進(jìn)了 IMPLEMENTATION_NOTES.md。第三階段是接口層兼容處理。開發(fā) Agent 在對(duì)外返回時(shí)加了一層狀態(tài)轉(zhuǎn)換適配把新枚舉映射回舊字符串保證調(diào)用方不需要改動(dòng)。這一步直接落實(shí)了架構(gòu) Agent 定的驗(yàn)收標(biāo)準(zhǔn)也說明了方案里的“驗(yàn)收標(biāo)準(zhǔn)”不是擺設(shè)而是給開發(fā) Agent 的明確指令。4.3 結(jié)果驗(yàn)收與回放評(píng)審 Agent 介入后做了幾件事對(duì)照方案文檔逐條確認(rèn)開發(fā) Agent 的實(shí)現(xiàn)是否覆蓋全部改動(dòng)點(diǎn)檢查 IMPLEMENTATION_NOTES.md 里記錄的歷史報(bào)表問題是否處理妥當(dāng)運(yùn)行核心鏈路測試確認(rèn)遷移腳本能正確處理存量數(shù)據(jù)。最終評(píng)審報(bào)告提出了一條需改進(jìn)項(xiàng)新增枚舉類的命名和項(xiàng)目中另一個(gè)領(lǐng)域模塊的既有枚舉風(fēng)格不一致建議統(tǒng)一。這個(gè)屬于代碼風(fēng)格問題不影響功能但暴露出一個(gè)問題——不同 Agent 各自訓(xùn)練數(shù)據(jù)里的編碼風(fēng)格偏好不一樣需要用項(xiàng)目的rules/文件做統(tǒng)一約束。因?yàn)楣ぷ髁髋渲昧薱reate_mr動(dòng)作整個(gè)流程跑完后Oh My OpenCode 自動(dòng)生成了一個(gè)合并請(qǐng)求草稿包含所有變更文件、方案文檔路徑、開發(fā)過程中的注意記錄和評(píng)審報(bào)告摘要。人只需要打開 MR 檢查一下確認(rèn)沒問題后點(diǎn)合并。整個(gè)過程中我實(shí)際介入的時(shí)間不超過十五分鐘其中大部分是在最后檢查 MR 時(shí)花的。對(duì)比之前一個(gè) Agent 單打獨(dú)斗的狀態(tài)效率和可控性都有明顯提升。5. 常見問題與排查技巧實(shí)錄5.1 問題速查表實(shí)踐這套方案的時(shí)候我整理了一份問題排查速查表基本覆蓋了初期最常見的幾類問題現(xiàn)象可能原因排查思路解決方案Agent 開始循環(huán)執(zhí)行同一工具調(diào)用模型 function call 返回格式不穩(wěn)定查看該 Agent 的會(huì)話日志定位是哪一步調(diào)用異常更換更穩(wěn)定的模型或降低temperature到 0.2 以下開發(fā) Agent 改的文件超出方案范圍allowed_paths配置不完整檢查該 Agent 的配置文件與變更文件列表完善allowed_paths將核心模塊目錄顯式加入兩個(gè) Agent 的產(chǎn)出互相覆蓋多個(gè) Agent 同時(shí)操作同一路徑檢查 workflow 步驟之間是否存在并行執(zhí)行調(diào)整為串行執(zhí)行或按目錄拆分 Agent 的職責(zé)手寫配置不被加載文件名或目錄層級(jí)錯(cuò)誤執(zhí)行oh-my-opencode doctor檢查按模板文件覆蓋結(jié)構(gòu)調(diào)整架構(gòu) Agent 產(chǎn)出方案過于泛化缺少對(duì)項(xiàng)目的全局約束查看rules/general.md是否覆蓋項(xiàng)目背景在規(guī)則文件中補(bǔ)充項(xiàng)目架構(gòu)說明、編碼規(guī)范和必讀文檔評(píng)審 Agent 漏掉關(guān)鍵風(fēng)險(xiǎn)評(píng)審范圍僅限文本 diff檢查 workflow 中評(píng)審輸入是否包含方案文檔在評(píng)審階段顯式傳入方案文檔與實(shí)施筆記補(bǔ)充一個(gè)排查技巧oh-my-opencode doctor這個(gè)命令能快速檢查配置目錄、依賴項(xiàng)和模型接口連通性排查問題第一步跑一遍它能擋掉一大半“低級(jí)錯(cuò)誤”。5.2 關(guān)于這套玩法的三層理解第一層理解是“配置不是越多越好”。我最初給每個(gè) Agent 配了十幾個(gè)工具權(quán)限結(jié)果權(quán)限之間的邊界模糊Agent 反而不知道優(yōu)先用什么。后來砍到每類角色最少必要權(quán)限行為反而更穩(wěn)定。Agent 團(tuán)隊(duì)和真人團(tuán)隊(duì)一樣明確的職責(zé)邊界比更多的工具更高效。第二層理解是“規(guī)則文件要當(dāng)成代碼維護(hù)”。rules/general.md里如果寫了“項(xiàng)目使用雙引號(hào)字符串風(fēng)格”那就要有意識(shí)地讓新代碼遵循這個(gè)風(fēng)格。如果規(guī)則文件長期不更新Agent 會(huì)基于自己訓(xùn)練時(shí)的常見模式形成一套與團(tuán)隊(duì)不一致的風(fēng)格。最好定期把評(píng)審中發(fā)現(xiàn)的風(fēng)格問題沉淀回規(guī)則文件形成正向循環(huán)。第三層理解是“工作流設(shè)計(jì)要為失敗留出口”。在實(shí)際任務(wù)中開發(fā) Agent 發(fā)現(xiàn)方案不可行的概率并不低。我的做法是在默認(rèn) workflow 里預(yù)留了一條失敗路徑開發(fā) Agent 輸出失敗原因后流程不直接進(jìn)入評(píng)審而是回到架構(gòu) Agent 重新調(diào)整方案。雖然會(huì)讓流程多跑一輪但這避免了“帶著錯(cuò)誤方案硬闖評(píng)審”的尷尬局面。你可以在 workflow 配置里增加- id: development_failed trigger: on_failure_of: development agent: architect input: original_proposal: ${architecture.proposal} failure_reason: ${development.notes} next_on_success: development這套回溯機(jī)制我愿稱之為 AgentTeam 的“容錯(cuò)安全網(wǎng)”。有了它整個(gè)團(tuán)隊(duì)才算真正具備處理真實(shí)世界復(fù)雜度的能力。5.3 三條真金白銀的避坑心得第一條每個(gè) Agent 都必須在配置里寫明“協(xié)作約束”里的禁止項(xiàng)。我見過的最痛案例是沒有約束評(píng)審 Agent 的寫權(quán)限它為了驗(yàn)證自己的判斷直接改掉了開發(fā) Agent 的代碼導(dǎo)致最后提交的代碼根本不符合實(shí)現(xiàn)方案。所以必須明確職責(zé)評(píng)審永遠(yuǎn)只輸出報(bào)告不直接改代碼。第二條交接摘要比完整對(duì)話歷史更可靠。工作流默認(rèn)會(huì)讓下游 Agent 讀取上游 Agent 的完整產(chǎn)出物如果上游產(chǎn)出物本身有大量無關(guān)上下文下游 Agent 會(huì)被帶偏。在prompts/handoff.md里定義了一套簡潔摘要模板強(qiáng)制每個(gè) Agent 在產(chǎn)出物結(jié)尾附上一個(gè)“交付摘要”寫清已完成事項(xiàng)、未完成事項(xiàng)、需要下游特別關(guān)注的問題效果比直接透傳強(qiáng)很多。第三條不要一次性跑幾十個(gè)任務(wù)的批量工作流先把單個(gè)任務(wù)的流程跑穩(wěn)定再并行化。并行跑多個(gè) Agent 會(huì)遇到資源爭搶和文件互鎖的問題初期排查起來能把人折磨瘋。先把單條流水線調(diào)通等配置和模型表現(xiàn)都穩(wěn)定之后再擴(kuò)展是一種務(wù)實(shí)很多的做法。最后分享一個(gè)小技巧我會(huì)在每周五下午花三十分鐘翻一遍本周 Agent 生成的 review 報(bào)告和 IMPLEMENTATION_NOTES.md挑出重復(fù)發(fā)生的共性問題回寫進(jìn)rules/和 Agent 角色描述里。這個(gè)動(dòng)作看起來不起眼但它是 AgentTeam 配置持續(xù)進(jìn)化的核心機(jī)制。你完全可以先照著這篇文章搭一套最小方案從一個(gè)小模塊開始試跑通流程后再逐步調(diào)整角色和規(guī)則讓這套團(tuán)隊(duì)協(xié)作體系慢慢適配到你自己的項(xiàng)目里。