1. 從pi這個(gè)極簡名字說起它到底是個(gè)什么東西第一次看到pi這個(gè)名字我以為是那個(gè)圓周率或者是某個(gè)數(shù)學(xué)庫的縮寫。直到在幾個(gè)開發(fā)者社群里反復(fù)看到pi agentagent loopcoding agent CLI這些詞綁在一起出現(xiàn)才意識到這是一個(gè)終端里的編程智能體工具。名字取得極簡功能卻一點(diǎn)都不簡單——它把大模型的能力直接塞進(jìn)了命令行界面讓你在終端里就能完成代碼生成、文件修改、命令執(zhí)行這一整套流程。我最初接觸這類工具時(shí)的疑問很典型我明明有IDE、有網(wǎng)頁版的對話窗口為什么還要在終端里再搞一個(gè)agent用了一段時(shí)間之后答案逐漸清晰——終端是離真實(shí)工程環(huán)境最近的地方。你的代碼在文件系統(tǒng)里你的構(gòu)建命令在shell里你的git狀態(tài)在倉庫里而一個(gè)coding agent CLI恰好就站在這個(gè)位置上它能直接讀寫文件、直接跑命令、直接看到報(bào)錯(cuò)不需要你在瀏覽器和編輯器之間來回復(fù)制粘貼。這個(gè)就近原則是理解pi這類工具價(jià)值的起點(diǎn)。pi的核心形態(tài)是一個(gè)agent loop你給它一個(gè)任務(wù)它進(jìn)入一個(gè)思考—行動(dòng)—觀察—再思考的循環(huán)直到任務(wù)完成或需要你介入。這個(gè)循環(huán)是它和普通聊天機(jī)器人的本質(zhì)區(qū)別。聊天機(jī)器人是你問我答而agent是你給目標(biāo)我自己想辦法一步步做。關(guān)鍵詞里的agent loop和loop官網(wǎng) agent其實(shí)指向的就是這套循環(huán)機(jī)制它是整個(gè)工具的心臟。這篇文章適合幾類人看一是剛聽說pi、想搞清楚它到底能干什么的開發(fā)者二是已經(jīng)在用但總覺得沒發(fā)揮出全部威力的中級用戶三是想理解coding agent這類工具底層設(shè)計(jì)思路的技術(shù)愛好者。我會從安裝配置講到agent loop的運(yùn)行邏輯再講到TUI交互、skills擴(kuò)展、以及實(shí)際使用中那些文檔里不會寫的坑。全程按我自己的實(shí)操經(jīng)驗(yàn)來寫能抄作業(yè)的地方直接給命令和配置。需要先說明一點(diǎn)pi這類工具迭代很快具體命令和參數(shù)可能隨版本變化我下面寫的是基于常見實(shí)踐的通用思路和典型用法你在自己環(huán)境里落地時(shí)以實(shí)際版本的幫助信息為準(zhǔn)。這個(gè)前提先擺在這里免得你照著敲發(fā)現(xiàn)對不上。2. 安裝pi之前先把這幾個(gè)環(huán)境問題想清楚2.1 為什么這類工具對運(yùn)行環(huán)境比普通CLI更挑剔普通的命令行工具裝完就能跑因?yàn)樗灰蕾囎约旱亩M(jìn)制。但pi這類coding agent CLI不一樣它本質(zhì)上是一個(gè)編排層——它自己不產(chǎn)生智能智能來自它背后調(diào)用的大模型API。所以它的運(yùn)行環(huán)境要求是雙重的一方面要有能跑Node.js或?qū)?yīng)運(yùn)行時(shí)的基礎(chǔ)環(huán)境另一方面要有穩(wěn)定可用的LLM API通道。這就引出了第一個(gè)容易被忽略的點(diǎn)API配置才是安裝的真正難點(diǎn)而不是裝包本身。我見過太多人卡在裝完了但一運(yùn)行就報(bào)錯(cuò)的階段八成問題都出在API這一環(huán)。關(guān)鍵詞里的LLM API和pi agent url說的就是這個(gè)——你需要一個(gè)能訪問的模型服務(wù)端點(diǎn)以及對應(yīng)的密鑰。安裝前我建議你先確認(rèn)三件事運(yùn)行時(shí)版本確認(rèn)你的Node.js版本滿足要求。這類工具通常要求較新的LTS版本版本太低會在依賴安裝階段就報(bào)錯(cuò)。用node -v看一眼心里有數(shù)。API可用性先用手頭的工具比如curl單獨(dú)測一下你的API端點(diǎn)能不能通別等裝完pi再去排查網(wǎng)絡(luò)問題那樣變量太多。工作目錄規(guī)劃想清楚你打算在哪個(gè)目錄下用它。agent會讀寫當(dāng)前工作目錄下的文件別在系統(tǒng)根目錄或者一堆無關(guān)文件的地方啟動(dòng)它。2.2 一次完整的安裝與初始化流程安裝本身通常很直接通過包管理器全局裝即可。以常見的Node生態(tài)為例大致是這樣# 全局安裝具體包名以官方為準(zhǔn) npm install -g pi-package-name # 驗(yàn)證安裝 pi --version裝完之后不要急著用先做初始化配置。這一步是把API信息告訴pi# 典型的配置方式可能是交互式引導(dǎo)也可能是寫配置文件 pi config # 或者通過環(huán)境變量 export PI_API_KEYyour-key-here export PI_API_BASEyour-endpoint-here這里有個(gè)實(shí)操心得優(yōu)先用配置文件而不是環(huán)境變量來存API信息。環(huán)境變量的坑在于你換個(gè)終端窗口、重啟一次機(jī)器或者用不同的shell它就可能丟了然后你又要重新排查為什么昨天好好的今天不行了。配置文件寫一次就穩(wěn)定生效省心得多。初始化完成后建議先跑一個(gè)最小驗(yàn)證讓它做一個(gè)無害的小任務(wù)比如在當(dāng)前目錄創(chuàng)建一個(gè)hello.txt內(nèi)容寫hello pi。如果它能正確創(chuàng)建文件說明API通道、文件讀寫權(quán)限、agent loop這三樣都通了。這個(gè)最小驗(yàn)證花不了兩分鐘但能幫你把后面可能出現(xiàn)的復(fù)雜問題和基礎(chǔ)環(huán)境問題隔離開。2.3 桌面端和CLI端到底該選哪個(gè)熱詞里出現(xiàn)了pi agent桌面端說明這個(gè)工具有不止一種形態(tài)。我的建議是如果你主要做工程開發(fā)優(yōu)先用CLI端。原因很實(shí)在——CLI端和你的開發(fā)環(huán)境是同一個(gè)上下文它跑的命令就是你平時(shí)跑的命令它改的文件就是你正在編輯的文件沒有割裂感。桌面端更適合演示、教學(xué)或者你不想碰命令行時(shí)的輕量使用場景。但兩者不是對立的。我自己的習(xí)慣是日常開發(fā)用CLI需要給別人展示agent工作過程、或者想更直觀地看多輪對話歷史時(shí)切到桌面端。工具形態(tài)服務(wù)于場景別被哪個(gè)更高級這種問題帶偏。3. agent loop才是pi的靈魂搞懂它你才算入門3.1 一次任務(wù)從輸入到完成中間到底發(fā)生了什么很多人用pi的方式其實(shí)和用聊天窗口沒區(qū)別問一句等一句再問一句。這樣用不是不行但你只用了它三成的能力。真正的價(jià)值在agent loop——當(dāng)你給一個(gè)需要多步才能完成的任務(wù)時(shí)它會自己拆解、自己執(zhí)行、自己根據(jù)結(jié)果調(diào)整。我拿一個(gè)真實(shí)場景來說明。假設(shè)你說幫我把項(xiàng)目里所有console.log刪掉然后跑一遍測試確認(rèn)沒壞。一個(gè)完整的agent loop大致是這樣運(yùn)轉(zhuǎn)的理解與規(guī)劃它先分析任務(wù)識別出這是批量修改驗(yàn)證的組合任務(wù)規(guī)劃出先搜索、再修改、最后測試的步驟。行動(dòng)它執(zhí)行搜索命令找到所有含console.log的文件。觀察讀取搜索結(jié)果判斷哪些是真需要?jiǎng)h的哪些可能是注釋里的、字符串里的。再行動(dòng)逐個(gè)文件做修改。再觀察跑測試看結(jié)果。判斷終止測試通過就結(jié)束并匯報(bào)測試失敗就回到第4步分析失敗原因再修。這個(gè)循環(huán)的關(guān)鍵在于每一步的觀察都會影響下一步的行動(dòng)。它不是把任務(wù)拆成固定腳本一次性跑完而是根據(jù)實(shí)際反饋動(dòng)態(tài)調(diào)整。這就是為什么它叫l(wèi)oop而不是pipeline。3.2 為什么loop的觀察環(huán)節(jié)最容易被低估我觀察下來新手最容易犯的錯(cuò)是不給agent足夠的觀察機(jī)會。具體表現(xiàn)是任務(wù)描述得太模糊或者中途頻繁打斷。舉個(gè)例子你說優(yōu)化一下這個(gè)函數(shù)agent可能改完了但它沒法驗(yàn)證優(yōu)化是否真的達(dá)成了——因?yàn)閮?yōu)化沒有可觀測的標(biāo)準(zhǔn)。但如果你說這個(gè)函數(shù)處理一萬條數(shù)據(jù)要3秒幫我優(yōu)化到1秒以內(nèi)改完跑一下benchmark它就有了明確的觀察目標(biāo)benchmark結(jié)果。有了觀察目標(biāo)loop才能形成閉環(huán)。所以用好agent loop的第一個(gè)技巧是把任務(wù)描述成可驗(yàn)證的目標(biāo)而不是模糊的意圖。你給它的驗(yàn)收標(biāo)準(zhǔn)越清晰它自我糾錯(cuò)的次數(shù)就越少一次成功的概率就越高。第二個(gè)技巧是信任它的中間步驟別急著打斷。我見過有人看到agent開始跑一個(gè)看起來多余的命令就趕緊按停結(jié)果反而打亂了它的節(jié)奏。它跑那個(gè)命令大概率是在收集信息為下一步?jīng)Q策做準(zhǔn)備。除非你明確知道它走錯(cuò)了方向否則讓它把一輪loop跑完再評估。3.3 loop的終止條件什么時(shí)候它會停下來問你一個(gè)設(shè)計(jì)良好的agent loop不會無限跑下去。它通常在幾種情況下停下來把控制權(quán)交還給你任務(wù)完成達(dá)成了你設(shè)定的目標(biāo)匯報(bào)結(jié)果。遇到歧義發(fā)現(xiàn)任務(wù)有多種理解方式需要你澄清。需要授權(quán)要執(zhí)行有風(fēng)險(xiǎn)的操作比如刪除文件、執(zhí)行破壞性命令先問你?？ㄗ×诉B續(xù)幾次嘗試都沒進(jìn)展判斷自己解決不了求助。理解這幾種終止條件很重要因?yàn)樗鼪Q定了你該怎么和它協(xié)作。比如它停下來問你要授權(quán)時(shí)你要快速判斷這個(gè)操作是否真的必要它說卡住了你要看它卡在哪一步是任務(wù)本身無解還是它理解偏了。提示如果你發(fā)現(xiàn)agent頻繁在需要授權(quán)處停下說明你的任務(wù)涉及較多敏感操作。這時(shí)候可以考慮在配置里調(diào)整權(quán)限策略但要非常謹(jǐn)慎——放寬權(quán)限意味著它可能在你沒注意時(shí)改動(dòng)重要文件。4. TUI交互終端界面里的那些門道4.1 TUI不是簡陋版GUI它有自己的交互邏輯TUITerminal User Interface是pi在終端里的交互界面。很多人第一次用會覺得這不就是個(gè)黑框框嗎但用熟了會發(fā)現(xiàn)TUI有它獨(dú)特的優(yōu)勢鍵盤流、無鼠標(biāo)、信息密度高。在TUI里你通常能看到幾個(gè)區(qū)域?qū)υ挌v史區(qū)、輸入?yún)^(qū)、狀態(tài)區(qū)顯示當(dāng)前agent在干什么、用了多少token等。這種布局的好處是你隨時(shí)知道agent處于什么狀態(tài)——是在思考、在執(zhí)行命令、還是在等你輸入。我個(gè)人的使用習(xí)慣是把TUI當(dāng)成一個(gè)任務(wù)控制臺而不是聊天窗口。聊天窗口的思維是我說一句它回一句控制臺的思維是我下達(dá)任務(wù)觀察它的執(zhí)行狀態(tài)必要時(shí)干預(yù)。這個(gè)心態(tài)轉(zhuǎn)變之后你會發(fā)現(xiàn)效率完全不一樣。4.2 幾個(gè)提升TUI使用效率的操作習(xí)慣第一善用快捷鍵而不是鼠標(biāo)。TUI里通常有查看歷史、中斷當(dāng)前任務(wù)、清屏、切換視圖之類的快捷鍵?；ㄊ昼姲堰@些鍵位記下來長期收益很大。尤其是中斷當(dāng)前任務(wù)這個(gè)鍵在agent跑偏時(shí)能救你一命。第二輸入長任務(wù)時(shí)用多行模式。如果你要描述一個(gè)復(fù)雜任務(wù)一行寫完容易漏信息。多數(shù)TUI支持多行輸入通常是某個(gè)組合鍵換行把任務(wù)分點(diǎn)寫清楚agent理解起來準(zhǔn)確得多。第三關(guān)注狀態(tài)區(qū)的token消耗。agent loop每轉(zhuǎn)一圈都在消耗token復(fù)雜任務(wù)可能轉(zhuǎn)十幾圈。狀態(tài)區(qū)一般會顯示當(dāng)前會話的消耗情況養(yǎng)成看一眼的習(xí)慣能幫你建立這類任務(wù)大概要花多少的直覺避免月底看到賬單嚇一跳。4.3 當(dāng)TUI卡住或者顯示異常時(shí)怎么辦TUI偶爾會出現(xiàn)顯示錯(cuò)亂比如文字重疊、光標(biāo)位置不對。這通常是終端模擬器的兼容性問題不是pi本身的bug。我的處理順序是先按清屏快捷鍵刷新一下多數(shù)情況能恢復(fù)。如果不行調(diào)整終端窗口大小觸發(fā)重繪。還不行就退出重進(jìn)會話歷史一般會保留。如果頻繁出現(xiàn)考慮換一個(gè)終端模擬器或者檢查終端編碼設(shè)置UTF-8是基本要求。這里有個(gè)經(jīng)驗(yàn)別在TUI顯示異常的時(shí)候繼續(xù)下達(dá)重要任務(wù)。顯示錯(cuò)亂可能意味著輸入也被截?cái)嗔四阋詾榘l(fā)出去的任務(wù)可能是不完整的agent按殘缺指令執(zhí)行反而會搞出問題。先修顯示再干活。5. skills機(jī)制讓pi從通用助手變成你的專屬助手5.1 skills解決的是什么問題通用agent有個(gè)天然短板它什么都會一點(diǎn)但對你項(xiàng)目里的特定規(guī)范、特定流程一無所知。比如你們團(tuán)隊(duì)的代碼風(fēng)格、你們項(xiàng)目的構(gòu)建命令、你們內(nèi)部的API約定這些它默認(rèn)不知道。每次都要在任務(wù)里重復(fù)交代既費(fèi)token又容易漏。skills機(jī)制就是把這些項(xiàng)目專屬知識固化下來讓agent在需要時(shí)自動(dòng)加載。你可以把它理解成給agent準(zhǔn)備的項(xiàng)目說明書它平時(shí)不占用上下文用到相關(guān)任務(wù)時(shí)才調(diào)取。熱詞里的pi skills說的就是這個(gè)能力。我一開始沒重視它覺得每次在任務(wù)里說清楚就行了。直到有次做一個(gè)涉及十幾個(gè)文件的改動(dòng)每次都要重復(fù)交代代碼規(guī)范token嘩嘩地?zé)乓庾R到skills的價(jià)值——一次配置長期復(fù)用。5.2 一個(gè)skill通常包含哪些內(nèi)容一個(gè)實(shí)用的skill一般包含三部分觸發(fā)條件什么情況下該用這個(gè)skill。比如當(dāng)任務(wù)涉及數(shù)據(jù)庫遷移時(shí)。知識內(nèi)容具體要告訴agent的信息。比如本項(xiàng)目用某遷移工具命令是XXX遷移文件放在YYY目錄。操作示例一兩個(gè)正確做法的例子讓agent有樣學(xué)樣。我建議skill的內(nèi)容寫得具體、可執(zhí)行別寫空泛的原則。代碼要規(guī)范這種話沒用函數(shù)名用駝峰、常量用全大寫、每個(gè)導(dǎo)出函數(shù)必須有JSDoc注釋這種才有用。agent需要的是能直接照著做的指令不是需要它自己解讀的原則。5.3 怎么設(shè)計(jì)一套好用的skills體系我的做法是按領(lǐng)域而不是按任務(wù)來組織skills。比如skill名稱覆蓋領(lǐng)域典型觸發(fā)場景代碼規(guī)范編碼風(fēng)格任何涉及寫代碼的任務(wù)構(gòu)建部署工程流程涉及打包、發(fā)布的任務(wù)測試約定質(zhì)量保障涉及寫測試、跑測試的任務(wù)數(shù)據(jù)操作數(shù)據(jù)庫涉及schema變更、數(shù)據(jù)遷移的任務(wù)按領(lǐng)域組織的好處是復(fù)用率高。一個(gè)代碼規(guī)范skill能覆蓋所有寫代碼的場景不用為每個(gè)具體任務(wù)單獨(dú)寫。設(shè)計(jì)skill時(shí)有個(gè)坑要注意別把skill寫得太長。skill內(nèi)容會占用上下文寫個(gè)幾千字進(jìn)去agent還沒開始干活上下文就滿了。我的經(jīng)驗(yàn)是每個(gè)skill控制在幾百字以內(nèi)只放最關(guān)鍵、最容易出錯(cuò)的信息細(xì)節(jié)讓它自己去代碼里找。注意skill里的命令和路徑一定要寫準(zhǔn)確。我踩過一次坑skill里寫的構(gòu)建命令少了個(gè)參數(shù)結(jié)果agent每次構(gòu)建都失敗還以為是代碼問題排查了半天。skill是agent的行動(dòng)依據(jù)寫錯(cuò)了它會忠實(shí)地照著錯(cuò)。6. 把pi用出生產(chǎn)力的幾個(gè)實(shí)戰(zhàn)場景6.1 場景一接手陌生代碼庫時(shí)的快速摸底剛接手一個(gè)不熟悉的項(xiàng)目最費(fèi)時(shí)間的是搞清楚這個(gè)項(xiàng)目怎么跑起來、代碼結(jié)構(gòu)是怎樣的。傳統(tǒng)做法是翻README、翻package.json、一個(gè)個(gè)目錄看。用pi可以這樣給它一個(gè)任務(wù)閱讀這個(gè)項(xiàng)目告訴我它的技術(shù)棧、入口文件、主要模塊劃分、以及本地啟動(dòng)需要哪些步驟。它會自己去讀關(guān)鍵文件然后給你一份結(jié)構(gòu)化的總結(jié)。這個(gè)場景下agent loop的價(jià)值在于它會根據(jù)讀到的內(nèi)容決定下一步讀什么。比如看到package.json里有某個(gè)框架它就知道去看對應(yīng)的配置文件看到有docker-compose它就知道去看服務(wù)依賴。這種順著線索走的能力比你自己一個(gè)個(gè)文件翻快得多。我的實(shí)操心得是摸底任務(wù)要給它明確的輸出格式要求。比如用表格列出模塊和職責(zé)按啟動(dòng)順序列出步驟這樣它給你的結(jié)果直接可用不用你再整理一遍。6.2 場景二批量重構(gòu)中的臟活累活重命名一個(gè)被幾十個(gè)文件引用的函數(shù)、把某個(gè)舊API的調(diào)用全部替換成新API、統(tǒng)一一批文件的import順序——這類任務(wù)機(jī)械、量大、容易出錯(cuò)正是agent的強(qiáng)項(xiàng)。以重命名函數(shù)為例我會這樣下達(dá)任務(wù)把oldFuncName重命名為newFuncName包括所有引用處、測試文件和文檔。改完跑一遍測試確認(rèn)沒壞。這里的關(guān)鍵是讓它自己跑測試驗(yàn)證。如果只是改完就結(jié)束你沒法確認(rèn)改全了沒有。讓它跑測試測試通過就是最好的驗(yàn)收。如果測試掛了它還能根據(jù)報(bào)錯(cuò)繼續(xù)修這就是loop的威力。但有個(gè)坑要提醒批量修改前確保你的工作區(qū)是干凈的git status沒有未提交改動(dòng)。這樣萬一agent改錯(cuò)了你一個(gè)git checkout .就能全部回滾。我吃過這個(gè)虧有次工作區(qū)里有一堆沒提交的改動(dòng)agent改完發(fā)現(xiàn)不對想回滾又怕把之前的改動(dòng)也弄丟了只能手動(dòng)一個(gè)個(gè)恢復(fù)非常痛苦。6.3 場景三寫測試和補(bǔ)文檔寫測試是很多人的痛點(diǎn)——知道該寫但懶得寫。pi在這件事上能幫大忙。你可以說給這個(gè)模塊的每個(gè)導(dǎo)出函數(shù)寫單元測試覆蓋正常路徑和邊界情況用項(xiàng)目現(xiàn)有的測試框架。它會先讀你的代碼理解每個(gè)函數(shù)干什么再讀現(xiàn)有測試了解風(fēng)格然后生成測試。生成完還能讓它跑一遍看測試是否通過、覆蓋率如何。補(bǔ)文檔同理。讓它給函數(shù)加注釋、給模塊寫README它做得又快又規(guī)范。但生成的文檔一定要自己過一遍尤其是涉及業(yè)務(wù)邏輯的部分agent可能理解得不夠準(zhǔn)確寫出技術(shù)上沒錯(cuò)但業(yè)務(wù)上不對的描述。6.4 場景四調(diào)試時(shí)的第二雙眼睛遇到一個(gè)詭異的bug自己看了半天沒頭緒可以把現(xiàn)象描述給pi讓它一起分析。它的價(jià)值不在于一定比你聰明而在于它沒有你的思維定勢。你可能會一直盯著自己覺得可疑的地方而它會從代碼里重新找線索。用法是這個(gè)函數(shù)在處理空數(shù)組時(shí)會拋異常報(bào)錯(cuò)信息是XXX相關(guān)代碼在YYY文件幫我定位原因。它會去讀代碼、分析邏輯、給出假設(shè)甚至直接跑一段代碼驗(yàn)證假設(shè)。這個(gè)場景下我建議把它當(dāng)協(xié)作者而不是答案提供者。它給的假設(shè)可能對也可能錯(cuò)但每個(gè)假設(shè)都值得你驗(yàn)證一下驗(yàn)證的過程往往就是找到真兇的過程。7. 那些文檔里不會寫的坑和心得7.1 上下文管理別讓agent失憶agent loop跑久了上下文會越來越長到某個(gè)點(diǎn)它可能開始忘記前面的內(nèi)容或者表現(xiàn)變差。這是所有長會話agent的通病。我的應(yīng)對策略是把大任務(wù)拆成有明確邊界的子任務(wù)。比如一個(gè)涉及五個(gè)模塊的重構(gòu)不要一個(gè)任務(wù)從頭做到尾而是分成五輪每輪聚焦一個(gè)模塊。每輪開始時(shí)簡要說明背景讓它在干凈的上下文里工作。這樣雖然多花幾次交互但每輪的成功率更高總體反而更快。另一個(gè)技巧是在任務(wù)里主動(dòng)提醒關(guān)鍵約束。如果你發(fā)現(xiàn)它開始違反某個(gè)重要約定比如又開始用錯(cuò)誤的命名風(fēng)格別指望它自己想起來直接在下一輪任務(wù)里重申一遍。7.2 權(quán)限與安全給它多大自由是個(gè)需要權(quán)衡的問題agent能執(zhí)行命令、能改文件這既是它的能力也是它的風(fēng)險(xiǎn)。默認(rèn)配置通常比較保守敏感操作會問你。但有些人為了流暢會把權(quán)限放得很寬這是有代價(jià)的。我的原則是在受控環(huán)境里可以放寬在重要倉庫里保持保守。具體來說在個(gè)人實(shí)驗(yàn)項(xiàng)目、臨時(shí)目錄里可以讓它自由執(zhí)行但在生產(chǎn)代碼倉庫、有重要數(shù)據(jù)的地方保持敏感操作需確認(rèn)的設(shè)置。多按幾次確認(rèn)鍵的成本遠(yuǎn)低于一次誤刪的代價(jià)。還有一點(diǎn)定期檢查agent的改動(dòng)。別它說改完了你就信了尤其是涉及配置、依賴、構(gòu)建腳本的改動(dòng)。養(yǎng)成改完看一眼diff的習(xí)慣git diff幾秒鐘的事能幫你發(fā)現(xiàn)很多問題。7.3 成本控制token是怎么燒掉的agent loop每轉(zhuǎn)一圈都要把當(dāng)前上下文發(fā)給模型上下文越長每圈消耗越大。一個(gè)復(fù)雜任務(wù)轉(zhuǎn)十幾圈消耗可能是簡單問答的幾十倍?？刂瞥杀镜膸讉€(gè)實(shí)用做法任務(wù)描述精準(zhǔn)減少它來回澄清的次數(shù)。及時(shí)結(jié)束會話任務(wù)完成后開新會話別在一個(gè)超長會話里繼續(xù)下一個(gè)不相關(guān)的任務(wù)。用skills替代重復(fù)交代把常用信息固化避免每次都在任務(wù)里重復(fù)。復(fù)雜任務(wù)先讓它給方案再執(zhí)行方案不對就調(diào)整別讓它直接開干然后推倒重來。我自己的經(jīng)驗(yàn)是養(yǎng)成看token消耗的習(xí)慣用一段時(shí)間后你會對這類任務(wù)大概花多少有直覺超出預(yù)期時(shí)就知道哪里可能出問題了。7.4 什么時(shí)候不該用agentagent不是萬能的有些場景用它反而添亂需求本身還沒想清楚你自己都不知道要什么agent更不知道。先把需求理清楚再交給它。需要深度業(yè)務(wù)判斷的決策agent不懂你的業(yè)務(wù)上下文這類決策得你自己做。一次性的、簡單的操作改一行配置、跑一個(gè)命令自己動(dòng)手比描述給它快。對準(zhǔn)確性要求極高且無法驗(yàn)證的場景如果它的輸出你沒法驗(yàn)證對錯(cuò)那用它就是賭博。判斷標(biāo)準(zhǔn)很簡單這個(gè)任務(wù)是否可描述、可執(zhí)行、可驗(yàn)證。三者都滿足交給agent缺一個(gè)就得掂量掂量。8. 關(guān)于pi這類工具我最后想說的幾點(diǎn)體會用了一段時(shí)間pi之后我最大的感受是這類coding agent CLI改變的不是寫代碼的速度而是和代碼交互的方式。以前你是唯一的執(zhí)行者所有操作都得親手做現(xiàn)在你更像一個(gè)指揮者把明確的任務(wù)派出去自己專注于判斷和決策。這個(gè)角色轉(zhuǎn)變需要適應(yīng)但適應(yīng)之后效率提升是實(shí)實(shí)在在的。另一個(gè)體會是工具的上限取決于使用者的表達(dá)能力。同樣一個(gè)pi有人用得出神入化有人覺得也就那樣差別往往不在工具本身而在于能不能把任務(wù)描述清楚、能不能設(shè)計(jì)好skills、能不能在合適的時(shí)機(jī)干預(yù)。這些能力沒有捷徑就是在一次次實(shí)操中磨出來的。如果你剛開始用我的建議是從一個(gè)小而具體的任務(wù)開始比如給這個(gè)文件加注釋跑通完整流程感受一下agent loop是怎么工作的。然后再逐步嘗試更復(fù)雜的任務(wù)。別一上來就讓它重構(gòu)整個(gè)項(xiàng)目那樣大概率會受挫然后誤以為工具不行。最后分享一個(gè)我常用的小技巧讓agent在動(dòng)手前先復(fù)述一遍它理解的任務(wù)。你可以在任務(wù)末尾加一句先告訴我你打算怎么做我確認(rèn)后再執(zhí)行。這一步能擋掉很多理解偏差導(dǎo)致的返工尤其是復(fù)雜任務(wù)多花這十幾秒非常值。等你和它配合得越來越默契很多簡單任務(wù)就可以跳過確認(rèn)直接執(zhí)行了。