整理 | 華衛(wèi)

用一個(gè) PostgreSQL 主庫(kù)和 50 個(gè)只讀副本，就頂住了 ChatGPT 上的 8 億用戶！

近日，OpenAI 的工程師們不僅爆出了這一驚人消息，還直接把 Codex 的“大腦”給扒了個(gè)精光。在 OpenAI 官方工程博客主頁(yè)，OpenAI 工程師、Technical Staff 成員 Michael Bolin 發(fā)布了一篇文章，以“揭秘 Codex 智能體循環(huán)”為題，深入揭秘了 Codex CLI 的核心框架：智能體循環(huán)（Agent Loop），并詳細(xì)講解了 Codex 在查詢模型時(shí)如何構(gòu)建和管理其上下文，以及適用于所有基于 Responses API 構(gòu)建智能體循環(huán)的實(shí)用注意事項(xiàng)和最佳實(shí)踐。

這些消息傳出后，在 Hacker News 等技術(shù)論壇及社交平臺(tái)上獲得了高度關(guān)注。“看似平淡的技術(shù)最終會(huì)勝出。OpenAI 正在證明，優(yōu)秀的架構(gòu)遠(yuǎn)勝于花哨的工具?！?/p>

值得一提的是，有網(wǎng)友透露，前不久 Anthropic 的一位工程師稱“他們用于 Claude Code UI 的架構(gòu)糟糕且效率低下”。而就在剛剛，X 上出現(xiàn)一條爆料：Codex 已接管 OpenAI 100% 的代碼編寫(xiě)工作。

對(duì)于“你們有多少百分比的編碼工作是基于 OpenAI 模型進(jìn)行”的問(wèn)題，roon 表示，“100%，我不再寫(xiě)代碼了?！倍饲?，Sam Altman 曾公開(kāi)發(fā)帖稱，“roon 是我的小號(hào)?！?/p>

Codex 的“大腦”揭秘

“每個(gè)人工智能智能體的核心都是 Agent Loop，負(fù)責(zé)協(xié)調(diào)用戶、模型以及模型調(diào)用以執(zhí)行有意義的軟件工作的工具之間的交互?！?/p>

據(jù)介紹，在 OpenAI 內(nèi)部，“Codex”涵蓋了一系列軟件智能體產(chǎn)品，包括 Codex CLI、Codex Cloud 和 Codex VS Code 插件，而支撐它們的框架和執(zhí)行邏輯是同一個(gè)。

Agent Loop 的簡(jiǎn)化示意圖

首先，智能體會(huì)從用戶那里接收輸入，并將其納入為模型準(zhǔn)備的文本指令集，該指令集被稱為提示詞。下一步是通過(guò)向模型發(fā)送指令并要求其生成響應(yīng)來(lái)查詢模型，這個(gè)過(guò)程稱為推理。推理過(guò)程中，文本提示詞首先被轉(zhuǎn)換為一系列輸入 token，隨后被用于對(duì)模型進(jìn)行采樣，生成新的輸出 token 序列。輸出 token 會(huì)被還原為文本，成為模型的回復(fù)。由于 token 是逐步生成的，該還原過(guò)程可與模型的運(yùn)行同步進(jìn)行，這也是眾多基于大語(yǔ)言模型的應(yīng)用支持流式輸出的原因。實(shí)際應(yīng)用中，推理功能通常封裝在文本 API 后方，從而抽象化詞元化的細(xì)節(jié)。

推理步驟完成后，模型會(huì)產(chǎn)生兩種結(jié)果：（1）針對(duì)用戶的原始輸入生成最終回復(fù)；（2）要求智能體執(zhí)行某項(xiàng)工具調(diào)用操作。若為第二種情況，智能體將執(zhí)行該工具調(diào)用并將工具輸出結(jié)果附加至原始提示詞中。該輸出結(jié)果會(huì)被用于生成新的輸入內(nèi)容，再次對(duì)模型進(jìn)行查詢；智能體隨后會(huì)結(jié)合這些新信息，重新嘗試完成任務(wù)。這一過(guò)程會(huì)不斷重復(fù)，直至模型停止發(fā)出工具調(diào)用指令，轉(zhuǎn)而生成面向用戶的消息（在 OpenAI 的模型中，該消息被稱為助手消息）。多數(shù)情況下，這條消息會(huì)直接解答用戶的原始請(qǐng)求，也可能是向用戶提出的跟進(jìn)問(wèn)題。

由于智能體可執(zhí)行能對(duì)本地環(huán)境進(jìn)行修改的工具調(diào)用，其 “輸出” 并不僅限于助手消息。在很多場(chǎng)景下，軟件智能體的核心輸出是在用戶設(shè)備上編寫(xiě)或編輯的代碼。但無(wú)論何種情況，每一輪交互最終都會(huì)以一條助手消息收尾，該消息是智能體循環(huán)進(jìn)入終止?fàn)顟B(tài)的信號(hào)。從智能體的角度來(lái)看，其任務(wù)已完成，操作控制權(quán)將交還給用戶。

多輪智能體循環(huán)

這意味著，對(duì)話內(nèi)容越豐富，用于模型采樣的提示詞長(zhǎng)度也會(huì)隨之增加。而所有模型都存在上下文窗口限制，即其單次推理調(diào)用可處理的 token 最大數(shù)量，智能體可能在單次對(duì)話輪次中發(fā)起數(shù)百次工具調(diào)用，這有可能耗盡上下文窗口的容量。因此，上下文窗口管理是智能體的多項(xiàng)職責(zé)之一。

這套智能體循環(huán)如何運(yùn)行？

據(jù)介紹，Codex 正是借助響應(yīng) API 來(lái)驅(qū)動(dòng)這套智能體循環(huán)的，博文曝出許多背后的實(shí)際運(yùn)行細(xì)節(jié)，包括：

• Codex 不會(huì)把用戶的話直接給大模型用，而是會(huì)主動(dòng)“拼接”出一整套精心設(shè)計(jì)的提示詞結(jié)構(gòu)，且涵蓋多個(gè)角色的指令、用戶輸入的一句話在結(jié)尾才出現(xiàn)。

• 模型推理與工具調(diào)用之間可能會(huì)進(jìn)行多輪迭代，提示詞的內(nèi)容會(huì)持續(xù)增加。

構(gòu)建初始提示詞

作為終端用戶，在調(diào)用響應(yīng) API 時(shí)無(wú)需逐字指定用于模型采樣的提示詞，只需在查詢中指定各類輸入類型，由響應(yīng) API 服務(wù)器決定如何將這些信息組織為模型可處理的提示詞格式。在初始提示詞中，列表中的每個(gè)條目均關(guān)聯(lián)一個(gè)角色。該角色決定了對(duì)應(yīng)內(nèi)容的權(quán)重占比，優(yōu)先級(jí)從高到低分為以下幾類：系統(tǒng)、開(kāi)發(fā)者、用戶、助手。

響應(yīng) API 接收包含多個(gè)參數(shù)的 JSON 負(fù)載，其中三個(gè)核心參數(shù)有：

• 指令：插入模型上下文的系統(tǒng)（或開(kāi)發(fā)者）消息

• 工具：模型生成回復(fù)過(guò)程中可調(diào)用的工具列表

• 輸入：向模型傳入的文本、圖片或文件輸入列表

在 Codex 中，若已配置，指令字段的內(nèi)容會(huì)從～/.codex/config.toml 配置文件中的模型指令文件讀??；若未配置，則使用與該模型關(guān)聯(lián)的基礎(chǔ)指令。模型專屬指令存儲(chǔ)在 Codex 代碼倉(cāng)庫(kù)中，并被打包至命令行工具中。工具字段為符合響應(yīng) API 定義的模式的工具定義列表。對(duì)于 Codex 而言，該列表包含三部分工具：Codex 命令行工具自帶的工具、響應(yīng) API 提供且開(kāi)放給 Codex 使用的工具，以及通常由用戶通過(guò) MCP 服務(wù)器提供的自定義工具。JSON 負(fù)載的輸入字段為一個(gè)條目列表。在添加用戶消息前，Codex 會(huì)先向該輸入中插入以下條目：

1. 一條角色為開(kāi)發(fā)者（role=developer）的消息，用于描述僅適用于工具部分中定義的 Codex 內(nèi)置 Shell 工具的沙箱環(huán)境。也就是說(shuō)，其他工具（如由 MCP 服務(wù)器提供的工具）并不受 Codex 的沙箱限制，需自行負(fù)責(zé)實(shí)施自身的防護(hù)規(guī)則。該消息基于模板構(gòu)建，核心內(nèi)容均來(lái)自打包在 Codex 命令行工具中的 Markdown 代碼片段。

2. 一條角色為開(kāi)發(fā)者的消息，其內(nèi)容為從用戶的 config.toml 配置文件中讀取的 developer_instructions 配置值。

3. 一條角色為用戶的消息，其內(nèi)容為用戶指令；該內(nèi)容并非來(lái)源于單個(gè)文件，而是從多個(gè)數(shù)據(jù)源聚合而來(lái)。一般而言，表述越具體的指令，排序越靠后：

4. 加載 $CODEX_HOME 目錄下 AGENTS.override.md 和 AGENTS.md 文件的內(nèi)容

5. 在默認(rèn) 32 千字節(jié)的大小限制內(nèi)，從當(dāng)前工作目錄對(duì)應(yīng)的 Git / 項(xiàng)目根目錄（若存在）向上遍歷至當(dāng)前工作目錄本身，加載任意 AGENTS.override.md、AGENTS.md 文件的內(nèi)容，或加載 config.toml 配置文件中 project_doc_fallback_filenames 參數(shù)指定的任意文件內(nèi)容

6. 若已配置相關(guān)技能，則補(bǔ)充以下內(nèi)容：關(guān)于技能的簡(jiǎn)短引言、各技能對(duì)應(yīng)的技能元數(shù)據(jù)、技能使用方法說(shuō)明章節(jié)。

7. 一條角色為用戶的消息，用于描述智能體當(dāng)前的運(yùn)行本地環(huán)境，其中會(huì)明確當(dāng)前工作目錄及用戶所使用的終端 Shell 信息。

當(dāng) Codex 完成上述所有計(jì)算并完成輸入初始化后，會(huì)追加用戶消息以啟動(dòng)對(duì)話。需注意的是，輸入中的每一個(gè)元素都是一個(gè) JSON 對(duì)象，包含類型、角色和內(nèi)容三個(gè)字段。當(dāng) Codex 構(gòu)建好要發(fā)送至響應(yīng) API 的完整 JSON 負(fù)載后，會(huì)根據(jù)～/.codex/config.toml 中響應(yīng) API 端點(diǎn)的配置方式，攜帶授權(quán)請(qǐng)求頭發(fā)起 HTTP POST 請(qǐng)求（若有指定，還會(huì)添加額外的 HTTP 請(qǐng)求頭和查詢參數(shù)）。當(dāng) OpenAI 響應(yīng) API 服務(wù)器接收到該請(qǐng)求后，會(huì)使用 JSON 數(shù)據(jù)來(lái)推導(dǎo)出模型的提示信息，（需要說(shuō)明的是，Responses API 的自定義實(shí)現(xiàn)可能會(huì)采用不同的方法）。

可見(jiàn)，提示詞中前三項(xiàng)的順序由服務(wù)器決定，而非客戶端。也就是說(shuō)，這三項(xiàng)里僅系統(tǒng)消息的內(nèi)容同樣由服務(wù)器控制，工具與指令則均由客戶端決定。緊隨其后的是 JSON 負(fù)載中的輸入內(nèi)容，至此提示詞拼接完成。

模型采樣

提示詞準(zhǔn)備就緒后，模型才開(kāi)始進(jìn)行進(jìn)行采樣。

第一輪交互：此次向響應(yīng) API 發(fā)起的 HTTP 請(qǐng)求，將啟動(dòng) Codex 中對(duì)話的第一輪交互。服務(wù)器會(huì)以服務(wù)器發(fā)送事件（SSE）流的形式進(jìn)行響應(yīng)，每個(gè)事件的數(shù)據(jù)均為一個(gè) JSON 負(fù)載，其 type 字段以 response 開(kāi)頭。Codex 接收該事件流并將其重新發(fā)布為可供客戶端調(diào)用的內(nèi)部事件對(duì)象。response.output_text.delta這類事件用于為用戶界面實(shí)現(xiàn)流式輸出功能，而response.output_item.added等其他事件則會(huì)被轉(zhuǎn)換為對(duì)象，附加至輸入內(nèi)容中，為后續(xù)的響應(yīng) API 調(diào)用所用。

若首次向響應(yīng) API 發(fā)起的請(qǐng)求返回兩個(gè)response.output_item.done事件，一個(gè)類型為推理（reasoning），一個(gè)類型為函數(shù)調(diào)用（function_call），那么當(dāng)結(jié)合工具調(diào)用的返回結(jié)果再次向模型發(fā)起查詢時(shí)，這些事件必須在 JSON 的輸入字段中進(jìn)行體現(xiàn)。后續(xù)查詢中用于模型采樣的最終提示詞結(jié)構(gòu)如下：

需要特別注意的是，舊提示詞是新提示詞的完整前綴。這一設(shè)計(jì)是有意為之的，因?yàn)樗茏層脩艚柚崾驹~緩存提升后續(xù)請(qǐng)求的效率。

在 Codex 命令行工具中，會(huì)將助手消息展示給用戶，并聚焦輸入編輯區(qū)，以此提示用戶輪到其繼續(xù)對(duì)話。若用戶做出回應(yīng)，上一輪的助手消息以及用戶的新消息均需附加至響應(yīng) API 請(qǐng)求的輸入字段中，從而開(kāi)啟新一輪對(duì)話。同樣，由于對(duì)話處于持續(xù)進(jìn)行的狀態(tài)，發(fā)送至響應(yīng) API 的輸入內(nèi)容長(zhǎng)度也會(huì)不斷增加。

棄用簡(jiǎn)單參數(shù)費(fèi)力做優(yōu)化，

就為了用戶隱私？

“在對(duì)話過(guò)程中，發(fā)送至響應(yīng) API 的 JSON 數(shù)據(jù)量，是否會(huì)讓智能體循環(huán)的時(shí)間復(fù)雜度達(dá)到二次方級(jí)別？”答案是肯定的。

據(jù)悉，盡管響應(yīng) API 支持通過(guò)可選的 previous_response_id 參數(shù)緩解這一問(wèn)題，但目前 Codex 并未啟用該參數(shù)，主要是為了保證請(qǐng)求完全無(wú)狀態(tài)，并兼容零數(shù)據(jù)保留（ZDR） 配置，即不存儲(chǔ)用戶對(duì)話數(shù)據(jù)。

取而代之的，是兩套需投入大量研發(fā)精力、涉及復(fù)雜實(shí)施流程的技術(shù)策略。文中，OpenAI 詳細(xì)介紹了這兩項(xiàng)硬核優(yōu)化的具體方案。

通常，模型采樣的開(kāi)銷遠(yuǎn)高于網(wǎng)絡(luò)傳輸?shù)拈_(kāi)銷，采樣環(huán)節(jié)會(huì)成為優(yōu)化效率的核心目標(biāo)，這也是提示詞緩存至關(guān)重要的原因，它能復(fù)用前一次推理調(diào)用的計(jì)算結(jié)果。當(dāng)緩存命中時(shí)，模型采樣的時(shí)間復(fù)雜度將從二次方降至線性。OpenAI 相關(guān)的提示詞緩存文檔對(duì)這一機(jī)制有更詳細(xì)的說(shuō)明：僅當(dāng)提示詞存在完全匹配的前綴時(shí)，才有可能實(shí)現(xiàn)緩存命中。為充分發(fā)揮緩存的優(yōu)勢(shì)，需將指令、示例等靜態(tài)內(nèi)容置于提示詞開(kāi)頭，而將用戶專屬信息等可變內(nèi)容放在末尾。這一原則同樣適用于圖片和工具，且其內(nèi)容在各次請(qǐng)求中必須保持完全一致。

基于這一原則，Codex 中可能有以下導(dǎo)致緩存未命中的操作：

1. 在對(duì)話過(guò)程中修改模型可調(diào)用的工具列表；

2. 更換響應(yīng) API 請(qǐng)求的目標(biāo)模型（實(shí)際場(chǎng)景中，這會(huì)改變?cè)继崾驹~中的第三項(xiàng)內(nèi)容，因該部分包含模型專屬指令）；

3. 修改沙箱配置、審批模式或當(dāng)前工作目錄。

因此，Codex 團(tuán)隊(duì)在為命令行工具開(kāi)發(fā)新功能時(shí)，必須審慎考量，避免新功能破壞提示詞緩存機(jī)制。例如，他們最初對(duì) MCP 工具的支持曾出現(xiàn)一個(gè)漏洞：工具的枚舉順序無(wú)法保持一致，進(jìn)而導(dǎo)致緩存未命中。需要注意的是，MCP 工具的處理難度尤為突出，因?yàn)?MCP 服務(wù)器可通過(guò) notifications/tools/list_changed 通知，動(dòng)態(tài)修改其提供的工具列表。若在長(zhǎng)對(duì)話過(guò)程中響應(yīng)該通知，極易引發(fā)高成本的緩存未命中問(wèn)題。

在可能的情況下，針對(duì)對(duì)話過(guò)程中發(fā)生的配置變更，他們會(huì)通過(guò)在輸入中追加新消息的方式體現(xiàn)變更，而非修改已有的早期消息：

• 若沙箱配置或?qū)徟Ｊ桨l(fā)生變更，我們會(huì)插入一條新的role=developer消息，格式與原始的條目保持一致；

• 若當(dāng)前工作目錄發(fā)生變更，我們會(huì)插入一條新的role=user消息，格式與原始的條目保持一致。

據(jù)介紹，為保障性能，OpenAI 在實(shí)現(xiàn)緩存命中方面投入了大量精力。除此之外，他們還重點(diǎn)管理了一項(xiàng)核心資源：上下文窗口。

其規(guī)避上下文窗口耗盡的通用策略是：一旦詞元數(shù)量超過(guò)某個(gè)閾值，就對(duì)對(duì)話進(jìn)行壓縮。具體來(lái)說(shuō)，會(huì)用一個(gè)更精簡(jiǎn)、且能代表對(duì)話核心內(nèi)容的新條目列表替代原有輸入，讓智能體在繼續(xù)執(zhí)行任務(wù)時(shí)仍能理解此前的對(duì)話過(guò)程。早期的壓縮功能實(shí)現(xiàn)方案，需要用戶手動(dòng)調(diào)用 /compact 命令，該命令會(huì)結(jié)合現(xiàn)有對(duì)話內(nèi)容和自定義的摘要生成指令，向響應(yīng) API 發(fā)起查詢；Codex 則會(huì)將返回的、包含對(duì)話摘要的助手消息，作為后續(xù)對(duì)話輪次的新輸入。

此后，響應(yīng) API 不斷迭代，新增了專用的 /responses/compact 端點(diǎn)，能以更高效率完成壓縮操作。該端點(diǎn)會(huì)返回一個(gè)條目列表，可替代原有輸入繼續(xù)對(duì)話，同時(shí)釋放出更多的上下文窗口空間。該列表中包含一個(gè)特殊的 type=compaction 條目，其附帶的 encrypted_content 加密字段為透明化設(shè)計(jì)，可保留模型對(duì)原始對(duì)話的潛在理解。

現(xiàn)在，當(dāng)詞元數(shù)量超過(guò) auto_compact_limit 自動(dòng)壓縮閾值時(shí)，Codex 會(huì)自動(dòng)調(diào)用該端點(diǎn)對(duì)對(duì)話內(nèi)容進(jìn)行壓縮。

極限擴(kuò)容：用 1 個(gè)數(shù)據(jù)庫(kù)

扛住了 8 億用戶

在另一篇技術(shù)博文中，OpenAI 工程師 Bohan Zhang 介紹， OpenAI 通過(guò)嚴(yán)苛的技術(shù)優(yōu)化與扎實(shí)的工程實(shí)踐，對(duì)單個(gè)數(shù)據(jù)庫(kù) PostgreSQL 進(jìn)行深度擴(kuò)容，實(shí)現(xiàn)以單套體系支撐 8 億用戶、每秒數(shù)百萬(wàn)次查詢的訪問(wèn)需求。

據(jù)稱，多年來(lái)，PostgreSQL 一直是支撐 ChatGPT、OpenAI API 等核心產(chǎn)品的核心底層數(shù)據(jù)系統(tǒng)之一。過(guò)去一年，公司 PostgreSQL 的負(fù)載增長(zhǎng)超 10 倍，且這一增長(zhǎng)趨勢(shì)仍在持續(xù)加速。OpenAI 稱，PostgreSQL 的橫向擴(kuò)展能力遠(yuǎn)超此前行業(yè)普遍認(rèn)知，能夠穩(wěn)定支撐規(guī)模大得多的讀密集型工作負(fù)載?！斑@套最初由加州大學(xué)伯克利分校的科學(xué)家團(tuán)隊(duì)研發(fā)的系統(tǒng)，助力我們通過(guò)單主節(jié)點(diǎn) Azure PostgreSQL 彈性服務(wù)器實(shí)例，搭配分布在全球多個(gè)區(qū)域的近 50 個(gè)只讀副本，承接了海量的全球訪問(wèn)流量?！?/p>

而且，OpenAI 表示，其擴(kuò)容在實(shí)現(xiàn)規(guī)模提升的同時(shí)，始終將延遲控制與可靠性優(yōu)化放在核心位置：生產(chǎn)環(huán)境中，客戶端 99 分位延遲穩(wěn)定保持在十幾毫秒的低水平，服務(wù)可用性達(dá)到五個(gè)九標(biāo)準(zhǔn)；過(guò)去 12 個(gè)月內(nèi)，PostgreSQL 僅出現(xiàn)過(guò)一次零級(jí)嚴(yán)重故障，該故障發(fā)生在 ChatGPT 圖像生成功能爆紅上線期間，一周內(nèi)超 1 億新用戶注冊(cè)導(dǎo)致寫(xiě)流量突發(fā)暴漲超 10 倍。

盡管 PostgreSQL 的擴(kuò)容成果已達(dá)預(yù)期，OpenAI 仍在持續(xù)探索其性能極限。目前，他們已將可分片的寫(xiě)密集型業(yè)務(wù)負(fù)載遷移至 CosmosDB 等分片式數(shù)據(jù)庫(kù)系統(tǒng)；對(duì)于分片難度更高的剩余寫(xiě)密集型負(fù)載，相關(guān)遷移工作也在積極推進(jìn)，以此進(jìn)一步減輕 PostgreSQL 主節(jié)點(diǎn)的寫(xiě)壓力。同時(shí)，OpenAI 正與微軟 Azure 團(tuán)隊(duì)展開(kāi)合作，推動(dòng)級(jí)聯(lián)復(fù)制功能落地，實(shí)現(xiàn)只讀副本的安全、大規(guī)模擴(kuò)容。隨著基礎(chǔ)設(shè)施需求的持續(xù)增長(zhǎng)，其將繼續(xù)探索更多擴(kuò)容方案，包括基于 PostgreSQL 的分片架構(gòu)改造、引入其他分布式數(shù)據(jù)庫(kù)系統(tǒng)等。

有網(wǎng)友評(píng)價(jià)道，“這招的高明之處，就在于極簡(jiǎn)。他們沒(méi)用什么花里胡哨的冷門(mén)技術(shù)，不過(guò)是把最佳實(shí)踐做到了極致。過(guò)去十年，行業(yè)里全是 ‘一切皆分片、擁抱 NoSQL、全面分布式，為 CAP 定理折腰’ 的論調(diào)，而 OpenAI 倒好， 服務(wù)十億級(jí)用戶的解法，居然只是一句‘試過(guò)加只讀副本嗎？’”

https://openai.com/index/unrolling-the-codex-agent-loop/

https://openai.com/index/scaling-postgresql/

聲明：本文為 AI 前線整理，不代表平臺(tái)觀點(diǎn)，未經(jīng)許可禁止轉(zhuǎn)載。

會(huì)議推薦

InfoQ 2026 全年會(huì)議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產(chǎn)業(yè)落地，從技術(shù)前沿到行業(yè)應(yīng)用，全面覆蓋 AI 與軟件開(kāi)發(fā)核心賽道！集結(jié)全球技術(shù)先鋒，拆解真實(shí)生產(chǎn)案例、深挖技術(shù)與產(chǎn)業(yè)落地痛點(diǎn)，探索前沿領(lǐng)域、聚焦產(chǎn)業(yè)賦能，獲取實(shí)戰(zhàn)落地方案與前瞻產(chǎn)業(yè)洞察，高效實(shí)現(xiàn)技術(shù)價(jià)值轉(zhuǎn)化。把握行業(yè)變革關(guān)鍵節(jié)點(diǎn)，搶占 2026 智能升級(jí)發(fā)展先機(jī)！

今日薦文

你也「在看」嗎？