大多數開發者最初使用編碼 Agent 是爲了處理代碼：檢查倉庫、生成差異、運行測試、發起拉取請求。
這仍然是 Codex 的核心重心。但計算機上的大量工作已經通過代碼進行中介：執行 shell 命令、瀏覽網頁、調用 API、導出文檔、響應事件、觸發自動化。隨着這些界面變得對 Codex 可用，它開始感覺不再像狹義上的編碼助手，而更像一個完成計算機工作的系統。
Codex 應用使這一轉變具體化。一個線程可以保持上下文、使用工具、展示產物，並在多次提示之間延續，而不是在每次交互後重置。
要更好地利用 Codex，意味着將這些能力組合使用：
- 保留上下文的持久線程
- 用戶仍在循環中時使用的語音輸入、引導和排隊
- 讓 Codex 超越倉庫行動的瀏覽器、計算機使用、MCP 服務器和連接器
-
用戶離開時繼續工作的線程自動化和 Goals
-
用戶可以審查代碼、文檔、演示文稿和其他產物的側邊欄
持久線程
持久線程：跨多次會話保留工作上下文的長期運行 Codex 線程。
置頂線程是讓持久線程觸手可及的一種方式。它們適用於以下重複性工作流：
-
一個首席幕僚線程
-
一個發佈線程
-
一個文檔審查線程
-
一個專門用於外部監控的線程
這些是持久的工作空間，而非短暫的聊天。Codex 可以隨着時間的推移重新訪問它們，保留先前的決策、偏好和工作上下文，否則這些都需要從頭重建。
置頂線程快捷鍵讓這一點變得實用。Command-1 到 Command-9 可直接跳轉到保存的線程。
語音輸入
語音輸入之所以有價值，是因爲它能在思想被壓縮成精煉文字之前捕捉到其粗略版本。
Codex 內置了語音輸入。它特別適合那些說出來很自然、但打字很彆扭的模糊起點：
我記得 Slack 裏有個叫 Ben 的人提到過這個。 我不記得細節了。 請去查一下。
對於一個可以搜索、收集上下文並彙報的 Agent 來說，這通常已經足夠了。
它也適用於在任務完全成型之前進行兩三分鐘的想法傾瀉。
轉錄文本的作用相同。原始的會議轉錄或口述的規劃筆記通常比簡短的摘要提供更好的源材料，因爲它保留了不確定性、強調和未完成的思路。
引導和排隊
當與對活躍任務的明確控制配對時，語音變得更加有用。
引導：在當前步驟完成之前，用新方向打斷正在進行的 Codex 任務。
引導在 Agent 走錯方向需要糾正時很有用。例如，在網站審查期間，用戶可以在側邊欄標註界面的同時打斷工作：
把這個變小一點 這兩個元素之間的間距感覺不對 這段文案錯了
排隊：在當前步驟完成後，爲 Codex 添加要做的工作。
排隊則不同。它不會打斷正在進行的任務。它將下一個任務加入隊列。用戶可能會說：
工作完成後，把預覽鏈接發給 Slack 裏的審查者。
引導改變 Codex 現在正在做什麼。排隊改變接下來應該發生什麼。兩者都讓用戶在工作展開時貼近工作。
工具和觸及範圍
一旦線程有了連續性，下一個問題是它能對什麼採取行動。Codex 可以向外逐層擴展：
-
$browser用於側邊欄中的應用內瀏覽器，Codex 可以在其中檢查和標註網頁界面 -
@chrome用於已登錄的瀏覽器狀態和基於 Chrome 的工作流 -
@computer用於僅通過桌面 GUI 存在的工作
$browser 適合側邊欄瀏覽器審查。@chrome 適合依賴用戶 Chrome 上下文的已登錄瀏覽器工作。@computer 適合僅通過桌面 GUI 存在的任務。MCP 服務器和連接器將同樣的理念擴展到工作流的其餘部分。Slack、Gmail 和 Calendar 很重要，因爲許多重要任務在成爲代碼之前，首先以消息、收件箱項目或日程安排問題的形式出現。
技能（Skills）讓重複的工作流可複用。一旦某個工作流被證明有用，將其打包爲技能，這樣 Codex 就可以再次運行它，而無需從頭重新學習整個流程。
隨處工作
Codex 移動應用改變了用戶必須在辦公桌前的時間。任務可以在 Mac 上啓動——文件、權限和本地設置已經存在的地方——然後在用戶用手機查看時繼續。
這在小 moments 中很重要。某人可以在 Codex 運行較長任務時離開辦公桌，在外面回答問題、批准下一步，或在回來之前重定向線程。本地環境保持原樣；用戶不必如此。
自動化
自動化按時間表運行 Codex 工作。當重複性任務應該從一個工作空間重新開始時，使用計劃自動化，例如每日報告或定期倉庫檢查。當計劃應該返回到具有運行上下文的活躍對話時，使用線程自動化。
線程自動化：按時間表返回到同一 Codex 線程的心跳式定期喚醒調用。
置頂線程很有用，但它們仍然等待用戶返回。線程自動化可以每隔幾分鐘或每隔幾小時檢查某事，繼續直到滿足條件，並隨着時間的推移調整節奏。
一個首席幕僚線程可能每 30 分鐘運行一次：
每 30 分鐘，檢查 Slack 和 Gmail 中是否有需要我注意的未回覆消息。 幫我優先處理最重要的。 如果有人問我問題，儘可能深入地研究答案併爲我起草回覆，但不要發送。
當用戶返回時，收集上下文的昂貴部分通常已經完成。人類仍然決定發送什麼。
線程自動化也適合反饋循環。線程自動化可以監視拉取請求評論、Google Docs 評論或 Slack 回覆，並在用戶離開時讓周圍的工作繼續推進。
考慮一個動畫工作流，審查者在 Slack 中分享了一個視頻。線程自動化可以按計劃檢查線程，在評論到達時渲染更新版本，並在同一線程中回覆並 @ 審查者。如果一個集成無法完成最終上傳，桌面自動化可以通過 GUI 完成這一步。
這個循環跨越 Slack 獲取反饋、代碼庫進行渲染、桌面自動化完成最終上傳。
Goals
當任務有一個 Agent 可以持續推動的真正終點時，Goals 最爲強大。一個弱目標是：
實現這個 Markdown 文件中的計劃。
一個更強的目標有可衡量的成功標準。
例如，工程師可能通過設置新目錄、定義目標並讓終點明確來將內部工具從 Python 遷移到 Rust：新實現直到單元測試通過纔算完成。
一個 Goal 將持續執行與驗證器結合在一起。用戶定義結果、停止條件以及表明 Codex 是否正在接近的信號。
有用的驗證器包括：
-
測試套件
-
基準測試
-
錯誤復現
-
驗證矩陣
-
必須持續通過的端到端工作流
雄心很重要，但沒有驗證它只是願望。
側邊欄
側邊欄將工作保留在產生它的對話旁邊。用戶無需導出產物並切換上下文，而是可以就地審查。輸出可能是代碼，但也可能是演示文稿、PDF、瀏覽器頁面、表格或沿途創建的其他產物。
它特別適合四項工作：
-
檢查產物
-
標註需要更改的地方
-
操作網頁界面
-
審查更改
側邊欄讓用戶就地審查 Markdown、電子表格、數據表格、文檔和幻燈片。他們可以檢查、標註和修改產物，而不會中斷循環。
演示文稿或 PDF 可以保持在生成它的線程旁邊，隨時可以直接審查和修正。
標註
應用內瀏覽器讓 Codex 檢查渲染的頁面、控制它，並直接在正在審查的界面上響應標註。頁面或產物上的評論保留在工作循環內部，而不是成爲單獨的交接。
網頁同時成爲輸出和控制界面。Codex 可以構建產物，在側邊欄中打開它，檢查它，調試它，並在原地持續完善同一對象。
這些界面尤其好用：
-
index.html用於輕量級靜態產物 -
Storybook 用於 UI 審查
-
Remotion Studio 用於程序化動畫
-
基於瀏覽器的幻燈片演示文稿
-
數據應用用於分析工作流
單個
index.html 文件可以成爲無需服務器的持久交互式產物。線程自動化還可以隨時間刷新靜態產物，這樣當用戶返回時，線程有新的東西在等待。共享記憶
當持久線程在單個對話之外共享記憶時，它們變得更加有用。
共享記憶：存儲在單個線程之外的持久上下文，以便未來的工作可以從明確且可審查的內容恢復。
一種持久的模式是將持久線程錨定在 Obsidian 倉庫中。在實踐中，這意味着一個純文本文件文件夾，保持易於檢查、編輯、移動和長期保存。團隊可以將該文件夾存儲在雲存儲、Git、Dropbox、Google Drive 或適合其工作流的另一個同步層中。
一個倉庫可能看起來像這樣：
vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/在頂層，
AGENTS.md 可以定義 Codex 在瞭解更多關於人員、項目、決策和開放循環的信息時應該如何更新該工作空間。不要複製一個確切的倉庫結構。教導 Agent 持久上下文應該存放在哪裏、保留什麼上下文、以及何時不要製造混亂。
一個實用的
AGENTS.md 可能會說：
~/vault視爲持久工作記憶。
倉庫保存代碼。倉庫保存滾動上下文：涉及的人員、發生了什麼變化、什麼被阻塞了、什麼需要跟進，以及否則會在會話之間消失的內容。
重要的上下文不應該只存在於對話記錄中。把它寫在某個地方，讓下一個線程可以重新拾起。
Codex 在設置 > 個性化 > 記憶中也有第一方記憶功能。它們爲偏好、重複工作流和已知陷阱提供本地回憶層。它們補充明確的文字上下文，而非取代它。Chronicle 通過幫助 Codex 從最近的屏幕上下文構建記憶，朝着同一方向推進。
從代碼向外延伸
Codex 仍然從代碼開始。但代碼周圍更多的工作現在可以通過同一系統觸及：MCP 服務器、瀏覽器界面、桌面控制、線程自動化和可審查的產物。
這改變了控制模型。引導打斷正在進行的工作。排隊安排下一個任務。線程自動化在用戶離開時保持線程活躍。Goals 添加一個 Codex 可以持續努力的明確終點。
Codex 現在可以承載一個從指令到執行到產物審查的工作流，即使工作離開了倉庫。
© 版權聲明
文章版权归作者所有，未经允许请勿转载。
相關文章
暫無評論...
