AI News字數 5828閱讀時長15 分鐘

深度用好 Codex:工具、線程與自動化(英中對照)

OpenAI Codex 官方指南解析:如何通過持久線程、語音輸入、瀏覽器工具、自動化任務與共享記憶,將 Codex 從代碼助手升級為全能工作系統。英中對照,適合學習閱讀。

*Getting the Most Out of Codex*

來源:OpenAI Codex 官方指南 | 英中對照版


Most developers first use coding agents for code: inspect a repository, make a diff, run tests, and open a pull request. That's still the center of gravity for Codex. But much of the work on a computer is already mediated by code: executing shell commands, browsing web pages, calling APIs, exporting documents, responding to events, and triggering automations. As those surfaces become available to Codex, it starts to feel less like a coding assistant in the narrow sense and more like a system for getting computer work done.

大多數開發者最初使用編程 AI 智能體是為了寫代碼:檢查代碼庫、生成差異對比(Diff)、運行測試、發起 Pull Request。這仍然是 Codex 的核心用途。但計算機上的許多工作早已以代碼為媒介:執行 Shell 命令、瀏覽網頁、調用 API、導出文檔、響應事件和觸發自動化流程。隨着這些能力被逐漸開放給 Codex,它開始越來越不像狹義上的編程助手,而更像一個能把各類計算機工作搞定的通用系統。

The Codex app makes that shift concrete. A thread can keep context, use tools, surface artifacts, and continue across prompts instead of resetting after each exchange.

Codex 應用將這種轉變變得具體可感。一個對話線程可以保持上下文、使用工具、生成製品,並跨越多個提示詞持續推進,而不是在每次交換後重置。

Getting more out of Codex means using these capabilities together:

深度用好 Codex,意味著將以下能力協同運用:

  • durable threads that preserve context
  • voice, steering, and queuing while the user is still in the loop
  • browser, computer-use, MCP servers, and connectors that let Codex act beyond a repo
  • thread automations and Goals that continue the work while the user is away
  • the side panel, where users can review code, documents, decks, and other artifacts

  • 保留上下文的持久線程
  • 用戶在場時的語音輸入、方向修正和任務排隊
  • 讓 Codex 超越代碼庫發揮作用的瀏覽器、電腦操控、MCP 伺服器和連接器
  • 用戶離開時繼續推進工作的線程自動化和目標任務(Goals)
  • 供用戶審閱代碼、文檔、幻燈片及其他製品的側邊欄

一、持久線程 / Durable Threads

Durable threads: Long-running Codex threads that preserve working context across repeated sessions.
持久線程: 跨多次會話保留工作上下文的長期 Codex 對話線程。

Pinned threads are one way to keep durable threads close at hand. They're useful for recurring work streams such as:

置頂線程是將持久線程隨時保持可用的一種方式。它們非常適合以下類型的持續性工作流:

  • a Chief of Staff thread
  • a release thread
  • a documentation review thread
  • a thread dedicated to external monitoring

  • 參謀/助手線程
  • 版本發佈線程
  • 文檔審查線程
  • 專用於外部監控的線程

These are persistent workspaces, not short chats. Codex can revisit them over time, preserving prior decisions, preferences, and working context that would otherwise need to be rebuilt from scratch.

這些是持久的工作空間,而非短暫的對話。Codex 可以隨時重返這些線程,保留之前的決策、偏好和工作上下文,無需每次從頭重建。

Pinned-thread shortcuts make this practical. Command-1 through Command-9 jump directly into saved threads.

置頂線程的快捷鍵讓這一切更加實用。Command-1 到 Command-9 可直接跳入對應的已保存線程。

二、語音輸入 / Voice Input

Voice input is valuable because it captures the rough version of a thought before it's compressed into polished prose.

語音輸入的價值在於,它能捕捉想法最原始的形態,而不是經過精煉潤色後的文字。

Codex has built-in voice input. It works especially well for vague starting points that are natural to say but awkward to type:

Codex 內置了語音輸入功能。它特別適合那些自然說出來卻難以打出來的模糊起點,例如:

I think someone named Ben mentioned this in Slack.
I do not remember the details.
Please go look.
"我記得有個叫 Ben 的人在 Slack 裏提到過這個。"
"我記不清細節了。"
"幫我去查一下。"

For an agent that can search, gather context, and report back, that's often enough.

對於一個能夠搜索信息、收集上下文並彙報結果的 AI 智能體來說,這通常就已經足夠了。

It also works well for a two- or three-minute thought dump before the task is fully formed.

在任務尚未成形之前,來一段兩三分鐘的思維傾瀉,語音同樣得心應手。

Transcripts work the same way. A raw meeting transcript or dictated planning note often provides better source material than a short summary because it preserves uncertainty, emphasis, and unfinished lines of thought.

文字轉錄的效果如出一轍。一份原始的會議記錄或口述的規劃筆記,往往比簡短的摘要提供更好的原始素材,因為它保留了不確定性、重點強調和未竟的思路。

三、方向修正與任務排隊 / Steering and Queuing

Voice becomes even more useful when paired with explicit control over an active task.

當語音與對進行中任務的明確控制相結合時,它的價值進一步放大。

Steering: Interrupting an in-flight Codex task with new direction before the current step finishes.
方向修正(Steering): 在當前步驟完成之前,用新方向打斷正在進行的 Codex 任務。

Steering is useful when the agent is heading the wrong way and needs a correction before it finishes. During a website review, for example, the user can interrupt the work while annotating the surface in the side panel:

當智能體走偏了方向、需要在完成前糾正時,方向修正大有用武之地。例如,在審查網站時,用戶可以一邊在側邊欄對頁面進行標註,一邊隨時打斷任務:

make this smaller
the spacing between these two elements feels off
this copy is wrong
"把這個做小一點"
"這兩個元素之間的間距感覺不對"
"這段文案寫錯了"
Queuing: Adding work for Codex to do after the current step completes.
任務排隊(Queuing): 在當前步驟完成後,為 Codex 追加待辦工作。

Queuing is different. It doesn't interrupt the task in progress. It adds the next task to the line. A user might say:

任務排隊與方向修正不同——它不打斷進行中的任務,而是把下一個任務加入隊列。用戶可以這樣說:

Once the work is done, send the preview link to the reviewer in Slack.
"工作完成後,把預覽鏈接發到 Slack 給審核人。"

Steering changes what Codex is doing now. Queuing changes what should happen next. Both keep the user close to the work while it's unfolding.

方向修正改變 Codex 當下正在做什麼,任務排隊改變接下來應該發生什麼。兩者都讓用戶在工作展開時始終與其保持緊密聯繫。

四、工具能力與觸達範圍 / Tools and Reach

Once a thread has continuity, the next question is what it can act on. Codex can move outward in layers:

一旦線程具備了連續性,下一個問題便是它能對什麼發揮作用。Codex 可以向外逐層擴展能力範圍:

  • $browser for the in-app browser in the side panel, where Codex can inspect and annotate web surfaces
  • @chrome for signed-in browser state and Chrome-based workflows
  • @computer for work that only exists through a desktop GUI

  • $browser:側邊欄內置瀏覽器,Codex 可藉此檢查和標註網頁內容
  • @chrome:依賴用戶 Chrome 登錄狀態和 Chrome 工作流的任務
  • @computer:只能通過桌面圖形介面完成的任務

$browser fits side-panel browser review. @chrome fits signed-in browser work that depends on the user's Chrome context. @computer fits tasks that only exist through a desktop GUI.

$browser 適合側邊欄瀏覽器審查;@chrome 適合依賴用戶 Chrome 上下文的登錄態操作;@computer 適合只能通過桌面 GUI 完成的任務。

MCP servers and connectors extend the same idea into the rest of a workflow. Slack, Gmail, and Calendar matter because many important tasks first appear as messages, inbox items, or scheduling problems before they ever become code.

MCP 伺服器和連接器將同樣的理念延伸到工作流程的其他環節。Slack、Gmail 和日曆之所以重要,是因為許多關鍵任務在成為代碼之前,往往先以消息、收件箱條目或日程安排問題的形式出現。

Skills make repeated workflows reusable. Once a workflow proves useful, package it as a skill so Codex can run it again without relearning the routine from scratch.

技能(Skills)讓重複性工作流可以重用。一旦某個工作流被證明有用,就將其封裝為技能,讓 Codex 下次無需從頭重學就能直接運行。

五、隨時隨地工作 / Work from Anywhere

The Codex mobile app changes when the user has to be at the desk. A task can start on a Mac where the files, permissions, and local setup already live, then continue while the user checks in from a phone.

Codex 移動應用改變了用戶必須坐在電腦前的局面。一項任務可以在 Mac 上啟動(文件、權限和本地環境都在那裏),然後在用戶用手機查看時繼續推進。

That matters in small moments. Someone can leave the desk while Codex runs a longer task, answer a question from outside, approve the next step, or redirect the thread before they get back. The local environment stays in place; the user doesn't have to.

這在細碎的時間裏意義重大。某人可以在 Codex 執行較長任務時離開桌面,在外面回答一個問題、批准下一個步驟或在回來之前重新定向線程。本地環境巋然不動,用戶不必如此。

六、自動化任務 / Automations

Automations run Codex work on a schedule. Use a scheduled automation when the recurring job should start fresh from a workspace, such as a daily report or a regular repository check. Use a thread automation when the schedule should return to an active conversation with its running context.

自動化任務讓 Codex 按計劃工作。當定期任務需要從工作空間全新啟動時(如每日報告或定期代碼庫檢查),使用計劃自動化;當計劃應回到一個保有運行上下文的活躍對話時,使用線程自動化。

Thread automations: Heartbeat-style recurring wake-up calls that return to the same Codex thread on a schedule.
線程自動化: 按計劃定期喚醒並返回同一 Codex 線程的心跳式循環機制。

Pinned threads are useful, but they still wait for the user to return. A thread automation can check on something every few minutes or every few hours, continue until it meets a condition, and adjust the cadence over time.

置頂線程很實用,但仍需等待用戶主動回來。線程自動化可以每隔幾分鐘或幾小時檢查一次,持續執行直至滿足某個條件,並隨時間調整頻率節奏。

A Chief of Staff thread might run every 30 minutes:

一個「參謀助手」線程可能每 30 分鐘運行一次:

Every 30 minutes, check Slack and Gmail for unanswered messages that need my attention.
Help me prioritize what matters most.
If someone asks me a question, research the answer as deeply as you can and draft a reply for me, but do not send it.
"每隔 30 分鐘,檢查 Slack 和 Gmail,找出需要我關注的未回覆消息。"
"幫我梳理最重要的優先事項。"
"如果有人向我提問,請儘可能深入研究答案併為我起草回覆,但不要發送。"

When the user returns, the expensive part of gathering context is often done. The human still decides what gets sent.

當用戶回來時,耗時的上下文收集工作往往已經完成。最終由誰來決定發送什麼,還是人。

Thread automations also fit feedback loops. A thread automation can watch pull request comments, Google Docs comments, or Slack replies and keep the surrounding work moving while the user is away.

線程自動化同樣適合反饋循環。它可以監視 Pull Request 評論、Google Docs 評論或 Slack 回覆,在用戶不在時推動相關工作持續進展。

Consider an animation workflow where a reviewer shares a video in Slack. A thread automation can check the thread on a schedule, render an updated version when comments arrive, and reply in the same thread tagging the reviewer. If one integration can't complete the final upload, desktop automation can finish the step through the GUI.

設想一個動畫工作流:審閱者在 Slack 中分享了一段影片。線程自動化可以按計劃檢查該線程,當評論出現時渲染更新版本,並在同一線程中 @ 審閱者回復。如果某個集成無法完成最終上傳,桌面自動化可以通過 GUI 完成這一步驟。

The loop spans Slack for feedback, the codebase for rendering, and desktop automation for the final upload.

這個循環跨越了 Slack(反饋)、代碼庫(渲染)和桌面自動化(最終上傳)三個環節。

七、目標任務 / Goals

Goals are most powerful when the task has a real finish line that the agent can keep pushing toward. A weak goal is:

當任務有一個智能體可以持續向其推進的真實終點線時,目標任務(Goals)的威力最為強大。一個弱目標如下所示:

Goals: Longer-running Codex tasks with a finish line the agent can keep working toward over time.
目標任務: 有明確終點線、智能體可以持續向其推進的長週期 Codex 任務。
Implement the plan in this Markdown file.
"實現這個 Markdown 文件中的計劃。"

A stronger goal has a measurable success criterion.

一個更強的目標有可量化的成功標準。

For example, an engineer might migrate an internal tool from Python to Rust by setting up the new directory, defining the goal, and making the finish line explicit: the new implementation isn't done until the unit tests pass.

例如,一名工程師可以通過創建新目錄、定義目標並明確終點線,將一個內部工具從 Python 遷移到 Rust:新實現在單元測試通過之前不算完成。

A goal combines ongoing execution with a verifier. The user defines the outcome, the stopping condition, and the signal that says whether Codex is getting closer.

一個目標任務將持續執行與驗證器相結合。用戶定義期望結果、停止條件以及判斷 Codex 是否在接近目標的信號。

Useful verifiers include:

有用的驗證器包括:

  • a test suite
  • a benchmark
  • a bug reproduction
  • a validation matrix
  • an end-to-end workflow that must keep passing

  • 測試套件
  • 性能基準
  • Bug 復現
  • 驗證矩陣
  • 必須持續通過的端到端工作流

Ambition matters, but without verification it's just a wish.

雄心固然重要,但沒有驗證機制,它不過是一廂情願。

八、側邊欄 / The Side Panel

The side panel keeps the work beside the conversation that produced it. Instead of exporting an artifact and switching contexts, the user can review it in place. The output might be code, but it might also be a deck, a PDF, a browser page, a table, or another artifact created along the way.

側邊欄讓工作與產生它的對話並排存在。用戶無需導出製品再切換上下文,可以就地審閱。輸出可以是代碼,也可以是幻燈片、PDF、瀏覽器頁面、數據表格或其他過程中產生的製品。

It supports four jobs especially well:

它特別擅長以下四項工作:

  • Inspect artifacts
  • Annotate what needs to change
  • Operate web surfaces
  • Review changes

  • 檢查製品
  • 標註需要修改的內容
  • 操控網頁介面
  • 審查變更

The side panel lets users review Markdown, spreadsheets, data tables, documents, and slides in place. They can inspect, mark up, and revise artifacts without breaking the loop.

側邊欄讓用戶可以就地審閱 Markdown、電子表格、數據表、文檔和幻燈片。他們可以檢查、標註並修改製品,而不必打斷工作流程。

Annotations

The deck or PDF can stay open beside the thread that produced it, ready for direct review and repair.

幻燈片或 PDF 可以在產生它的線程旁邊保持打開狀態,隨時供直接審閱和修改。

Sheets in Codex

The in-app browser lets Codex inspect a rendered page, control it, and respond to annotations directly on the surface under review. Comments on a page or artifact stay inside the working loop instead of becoming a separate handoff.

內置瀏覽器讓 Codex 可以檢查渲染後的頁面、對其進行控制,並直接在被審閱的介面上響應標註。對頁面或製品的評論保留在工作循環內部,而不會變成獨立的交接任務。

The web becomes both output and control surface. Codex can build an artifact, open it in the side panel, inspect it, debug it, and keep refining the same object in place.

網頁既是輸出,也是控制介面。Codex 可以構建一個製品,在側邊欄中打開它、檢查它、調試它,並就地持續打磨同一對象。

These surfaces work especially well:

以下幾類介面表現尤為出色:

  • index.html for lightweight static artifacts
  • Storybook for UI review
  • Remotion Studio for programmatic animation
  • browser-based slide decks for presentations
  • data apps for analysis workflows

  • index.html:輕量級靜態製品
  • Storybook:UI 組件審查
  • Remotion Studio:程序化動畫
  • 基於瀏覽器的幻燈片:演示文稿
  • 數據應用:分析工作流

A single index.html file can become a durable interactive artifact with no server required. Thread automations can also refresh static artifacts over time so a thread has something new waiting when the user returns.

一個 index.html 文件無需伺服器即可成為持久的交互式製品。線程自動化還可以隨時間刷新靜態製品,讓線程在用戶回來時始終有新內容等待審閱。

九、共享記憶 / Shared Memory

Long-running threads become more useful when they share memory outside any one conversation.

當長期線程能夠在單次對話之外共享記憶時,它們的價值會進一步提升。

Shared memory: Durable context stored outside a single thread so future work can resume from something explicit and reviewable.
共享記憶: 存儲於單一線程之外的持久上下文,使未來的工作能夠從可見、可審閱的內容處繼續。

One durable pattern is to anchor persistent threads in an Obsidian vault. In practice, that means a folder of plain files that stays straightforward to inspect, edit, move, and keep for a long time. Teams can store that folder in cloud storage, Git, Dropbox, Google Drive, or another sync layer that fits their workflow.

一種持久可靠的模式是:將持久線程錨定在 Obsidian 知識庫中。實際上,這意味著一個由純文本文件組成的文件夾,便於長期檢查、編輯、遷移和保存。團隊可以將這個文件夾存儲在雲存儲、Git、Dropbox、Google Drive 或其他適合其工作流的同步層中。

A vault might look like this:

一個知識庫的目錄結構可能如下:

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

At the top level, AGENTS.md can define how Codex should update that workspace as it learns more about people, projects, decisions, and open loops.

在頂層,AGENTS.md 可以定義 Codex 在瞭解更多關於人員、項目、決策和未完成事項時應如何更新該工作空間。

Don't copy one exact vault structure. Teach the agent where durable context should live, what context to preserve, and when not to create churn.

不要照搬某個固定的知識庫結構。要教會智能體:持久上下文應該存放在哪裏、什麼上下文值得保留,以及何時不要無謂地製造文件碎片。

A practical AGENTS.md might say:

一份實用的 AGENTS.md 可以這樣寫:

- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, dates, and useful links.
- If nothing meaningful changed, do not churn the vault.

Repositories hold code. The vault holds rolling context: the people involved, what changed, what's blocked, what needs follow-up, and what would otherwise disappear between sessions.

代碼庫存放代碼;知識庫存放滾動更新的上下文:相關人員、發生了什麼變化、什麼被卡住了、什麼需要跟進,以及那些否則會在會話間消失的信息。

Important context shouldn't live only inside a conversation transcript. Write it down somewhere the next thread can pick back up.

重要上下文不應只存在於對話記錄中。把它寫下來,放在下一個線程可以接手的地方。

Codex also has first-party memory features in Settings > Personalization > Memories. They provide a local recall layer for preferences, recurring workflows, and known pitfalls. They complement explicit written context rather than replacing it. Chronicle pushes in the same direction by helping Codex build memory from recent screen context.

Codex 在「設置 → 個性化 → 記憶」中也提供了原生記憶功能。它為偏好、重複性工作流和已知的坑提供了一個本地回憶層,是對顯式書面上下文的補充,而非替代。Chronicle 也朝着同一方向發力,通過近期屏幕上下文幫助 Codex 構建記憶。

十、從代碼出發,走向更廣 / From Code Outward

Codex still starts from code. But more of the work around code is now reachable through the same system: MCP servers, browser surfaces, desktop controls, thread automations, and reviewable artifacts.

Codex 的起點仍然是代碼。但圍繞代碼的更多工作,現在都可以通過同一個系統觸達:MCP 伺服器、瀏覽器介面、桌面控制、線程自動化,以及可供審閱的製品。

That changes the control model. Steering interrupts the work in progress. Queuing lines up the next task. Thread automations keep a thread active when the user steps away. Goals add a concrete finish line that Codex can keep working toward.

這改變了控制模式。方向修正打斷進行中的工作;任務排隊安排下一個待辦;線程自動化在用戶離開時保持線程活躍;目標任務添加了一個 Codex 可以持續向其推進的具體終點線。

Codex can now carry a workflow from instruction to execution to artifact review, even when the work leaves the repo.

Codex 現在可以將一個工作流從指令推進到執行,再到製品審閱——即使工作已經超出了代碼庫的範疇。


*本文來源於 OpenAI Codex 官方指南,英中對照版由 Lamjin 整理翻譯。*

如果你想在國內穩定使用 Codex 註冊和驗證,可以參考 《giffgaff 英國實體號碼使用指南》;關於 OpenRouter 免費模型作為 Codex 替代實驗基礎,可以看 《OpenRouter 免費模型推薦》

常見問題

Codex 和 Claude Code 有什麼區別?

Codex 是 OpenAI 的編程 Agent 產品,Claude Code 是 Anthropic 的對應工具,兩者在設計理念上相近(Agent 在真實環境執行任務)但生態和集成方式不同。Codex 側重 GitHub 集成和雲端執行,Claude Code 更偏向本地 CLI 工作流。

Codex 的"持久線程"是什麼?

持久線程讓 Codex 在多次提示詞交換之間保持上下文,不會每次重置,適合需要多步推進的複雜任務。結合任務排隊和線程自動化,Codex 可以在用戶離開時繼續處理後續工作。

Codex 的 Automations(自動化任務)如何工作?

Automations 允許 Codex 在用戶不在線時持續執行任務(如定期檢查代碼庫、響應事件、運行測試),相當於把 Codex 變成後台工作線程。Goals 功能則讓 Codex 持續向一個具體目標推進,而不是等待每次人工觸發。

Codex 支持哪些外部工具連接?

Codex 目前支持瀏覽器、MCP 伺服器和各類 Connectors(連接器),可以調用外部 API、讀寫文檔、執行 Shell 命令,以及在代碼庫之外的系統中操作。

參考來源

Share

分享這篇文章