編輯 | 聽雨

小編最近刷到一篇讓程序員直呼“醍醐灌頂”的文章——出自軟件工程師兼安全工程師 Shrivu Shankar。他基于日常使用 Claude Code 的真實經(jīng)驗，分享了從個人項目到企業(yè)級開發(fā)的全套智能體最佳實踐。

Shrivu 不只是講理論，他講述了管理智能體上下文、批量處理任務(wù)、快速原型、自動生成 Pull Request 的實操技巧，還結(jié)合 Hooks、Skills、MCP、SDK 等高級特性，告訴你如何把 AI 真正融入日常工程工作流。

圖片

知名開源公司創(chuàng)始人 Simon Willison 也高度評價：“Shrivu 的指南非常實用，既適合個人，也適合為大型團(tuán)隊進(jìn)行智能體配置。”尤其對 MCP 的看法，他說得很精煉：“與其構(gòu)建臃腫的 API，不如把 MCP 設(shè)計成簡單、安全的網(wǎng)關(guān)，只提供少量強大的工具。”

圖片

如果你想知道 Claude Code 的每個功能該怎么用、什么時候用、如何最大化價值，小編為你整理了文章的精華內(nèi)容，它將是你最實用的參考手冊。

我如何使用Claude Code的每個功能

我真的很常用 Claude Code。

作為一個業(yè)余開發(fā)者，我每周都會在虛擬機(jī)中運行它幾次，開啟 --dangerously-skip-permissions 模式，隨心所欲地「即興編碼」各種想法。在工作中，我的團(tuán)隊負(fù)責(zé)為公司工程團(tuán)隊構(gòu)建 AI IDE 的規(guī)則與工具，我們每月光代碼生成就消耗數(shù)十億個 token。

CLI 智能體的競爭正在白熱化——Claude Code、Gemini CLI、Cursor、Codex CLI……我感覺真正的競爭是在 Anthropic 和 Open AI 之間。

但老實說，開發(fā)者之間的選擇往往取決于一些“表面因素”——比如某個功能實現(xiàn)的“運氣”，或者他們更喜歡哪種系統(tǒng)提示的“語氣”。到現(xiàn)在為止，這些工具都已經(jīng)相當(dāng)不錯了。

我也注意到，很多人過度關(guān)注輸出風(fēng)格或 UI。對我來說，Claude 里那種“你太對了！”式的奉承并不是 bug，而是一個信號：說明你給的上下文太多了。我的目標(biāo)是「發(fā)射即忘」（shoot and forget）——設(shè)定上下文，交代任務(wù)，讓它自己去完成。評判工具的標(biāo)準(zhǔn)，是最終提交的 PR，而不是它中間的過程。

在過去幾個月深入使用 Claude Code 后，這篇文章是我對它整個生態(tài)系統(tǒng)的總結(jié)。我會覆蓋幾乎所有我使用的功能（以及我不用的功能），從核心的 CLAUDE.md 文件、定制命令、到 Subagents、Hooks、GitHub Actions 等強大特性。

CLAUDE.md

在 Claude Code 中，最重要的文件就是項目根目錄下的 CLAUDE.md。它是智能體的“憲法”——描述你的代碼庫該如何被理解和操作。

• 對于個人項目，我讓 Claude 自己隨意在里面寫。
• 對于公司項目，我們嚴(yán)格維護(hù) monorepo 的 CLAUDE.md，目前有 13KB（預(yù)計會漲到 25KB）。

它只記錄被超過 30% 工程師使用的工具和 API，其他工具則單獨寫在對應(yīng)庫的 markdown 文檔里。我們甚至給每個內(nèi)部工具的文檔分配“token 上限”，就像賣廣告位一樣——如果你講不清楚，就別進(jìn) CLAUDE.md。

編寫 CLAUDE.md 的技巧與反模式

• 從“防錯”開始，而不是寫手冊。CLAUDE.md 應(yīng)該從 Claude 容易出錯的地方開始補充，而不是從零開始詳盡記錄。
• 不要直接 @ 文件文檔。如果你 @ 引用了其它文檔，Claude 會每次都把整份文件嵌入上下文，浪費 token。但僅僅寫路徑 Claude 又會無視它。正確做法是告訴 Claude 什么時候該去讀那份文檔，例如：

“如果遇到 FooBarError 或復(fù)雜用法，請參見 path/to/docs.md。”

• 不要只寫“永遠(yuǎn)不要”。單純寫“Never use --foo-bar”會讓模型卡住。應(yīng)同時提供替代方案。
• 把 CLAUDE.md 當(dāng)作“約束工具”。如果命令太復(fù)雜，不要寫長篇解釋，而是寫一個簡單的 bash 包裝器，讓命令變得直觀，再記錄它。保持 CLAUDE.md 精簡，是推動團(tuán)隊改進(jìn)工具的好方式。

示例結(jié)構(gòu)如下：

最后，我們還會維護(hù)一個 AGENTS.md，用于與其他 AI IDE（如 Cursor）兼容。

要點總結(jié)：把你的 CLAUDE.md 當(dāng)作一份高層次、經(jīng)過精心篩選的指引，而不是一本面面俱到的使用手冊。它的作用，是幫助你識別出哪些地方需要投入更多精力，去打造對 AI 與人類 都更友好的工具和流程。

Compact、Context 與 Clear

我建議在中途運行一次 /context，看看 200k token 的上下文是如何被使用的（即使是 Sonnet-1M，我也不完全相信 100 萬 token 都被有效利用）。

在我們的 monorepo 中，一個新會話的“空載成本”約 20k tokens（10%），剩余 180k 負(fù)責(zé)執(zhí)行修改——很快就會被填滿。

我的三種主要工作流：

1. /compact（避免）自動壓縮上下文太黑箱、容易出錯、不可靠。
2. /clear + /catchup（簡單重啟）我默認(rèn)的重啟方式：清除狀態(tài)，然后運行 /catchup 讓 Claude 重新讀取本分支修改的文件。
3. “Document & Clear”（復(fù)雜重啟）對大型任務(wù)，我讓 Claude 把計劃與進(jìn)展寫入一個 .md 文件，然后清空狀態(tài)，讓它讀回這個文件繼續(xù)。

要點總結(jié)：不要依賴自動壓縮。小任務(wù)用 /clear 重啟，大任務(wù)用“記錄 + 清理”的方式保留上下文記憶。

自定義 Slash 命令

我把 Slash 命令看作是常用提示語的簡單快捷方式，僅此而已。我的配置非常精簡：

• /catchup：前面提到過的命令，用來讓 Claude 讀取當(dāng)前 Git 分支中所有被修改的文件。
• /pr：一個小幫手，用于清理代碼、暫存修改并準(zhǔn)備創(chuàng)建 Pull Request。

在我看來，如果你維護(hù)著一長串復(fù)雜的自定義斜杠命令，那其實是一種反模式。像 Claude 這樣的智能體，本意就是讓你幾乎能“隨口輸入”任何自然語言請求，并得到一個有用、可合并的結(jié)果。一旦你要求開發(fā)者（甚至非技術(shù)人員）必須去學(xué)習(xí)一份記錄在某處的“魔法命令清單”才能完成工作，那就違背了智能體設(shè)計的初衷。

要點總結(jié)：把斜杠命令當(dāng)作簡單、個性化的快捷方式來使用，而不是用它們?nèi)ヌ娲粋€更直觀的 CLAUDE.md 文件或更完善的智能體工具體系。

自定義子代理

理論上，自定義子代理是 Claude Code 中最強大的上下文管理功能之一。它的設(shè)計邏輯很簡單：一個復(fù)雜任務(wù)需要 X 個 token 的輸入上下文（例如測試運行方式），在執(zhí)行過程中積累 Y 個 token 的工作上下文，最終產(chǎn)出 Z 個 token 的結(jié)果。如果要運行 N 個這樣的任務(wù)，那么主會話窗口就要處理 (X + Y + Z) * N 的上下文負(fù)載。

而子代理（subagent）機(jī)制的解決思路是：把 (X + Y) * N 的繁重計算外包給專門的子代理，讓它們只返回最終的 Z 結(jié)果，從而保持主會話上下文的整潔。

聽起來很美好，但在實際使用中，我發(fā)現(xiàn)自定義子代理帶來了兩個新的問題：

1.它們會“封鎖”上下文。

例如我創(chuàng)建了一個 PythonTests 子代理，那么所有與測試相關(guān)的上下文就被隔離在它的內(nèi)部。主代理再也無法從整體上推理一個改動，因為它必須調(diào)用子代理才能知道如何驗證自己的代碼。

2.它們強加了“人類式工作流”。

更糟的是，這種機(jī)制迫使 Claude 遵循我人為定義的流程。我在告訴它“你必須這樣分工合作”，而這恰恰是我希望 AI 自主解決的問題。

我更喜歡的替代方案是使用 Claude 內(nèi)置的 Task(...) 功能來克隆出通用代理的副本。我會把所有關(guān)鍵上下文寫在 CLAUDE.md 文件里，然后讓主代理自行決定何時、如何委派任務(wù)給自己的副本。這樣既保留了子代理帶來的上下文節(jié)省優(yōu)勢，又避免了它的僵化問題，讓智能體能夠動態(tài)自我調(diào)度。

在我的另一篇文章《Building Multi-Agent Systems（Part 2）》中，我稱這種架構(gòu)為 “主控–克隆（Master-Clone）”模型，并且我明確更偏愛這種方式，而不是自定義子代理所鼓勵的 “主導(dǎo)–專家（Lead-Specialist）”模型。

（文章鏈接：https://blog.sshh.io/p/building-multi-agent-systems-part）

要點總結(jié)：自定義子代理是一種脆弱的解決方案。更好的做法是：把核心上下文放入 CLAUDE.md，讓主代理通過自己的 Task/Explore(...) 功能自主管理任務(wù)分配與協(xié)作。

Resume、Continue 與 History 功能

在日常使用中，我經(jīng)常使用 claude --resume 和 claude --continue 這兩個命令。它們非常適合在終端出錯后快速重啟，或恢復(fù)舊的會話。有時我會恢復(fù)幾天前的一次會話，只是為了讓 Claude 總結(jié)它當(dāng)時是如何解決某個特定錯誤的，然后把這些經(jīng)驗更新進(jìn)我們的 CLAUDE.md 或內(nèi)部工具中。

更深入一點來說，Claude Code 會把所有會話歷史記錄保存在 ~/.claude/projects/ 目錄下，這意味著你可以直接訪問那些原始的歷史會話數(shù)據(jù)。我寫了一些腳本來對這些日志進(jìn)行元分析，尋找常見的異常、權(quán)限請求和錯誤模式，以幫助優(yōu)化智能體的上下文提示與行為策略。

要點總結(jié)：使用 claude --resume 和 claude --continue，不僅可以重啟中斷的會話，還能夠挖掘歷史日志中被埋沒的上下文信息，持續(xù)改進(jìn)你的智能體配置與工作流。

Hooks（鉤子機(jī)制）

Hooks 的作用非常強大。雖然我在個人項目里幾乎不用它們，但在大型企業(yè)級代碼倉庫中，它們是引導(dǎo) Claude 行為的關(guān)鍵工具。你可以把它們理解為 CLAUDE.md 文件中“應(yīng)該做的建議（should-do）”之外的“必須遵守的規(guī)則（must-do）”。

我們主要使用兩種類型的 Hook：

1.提交阻斷鉤子（Block-at-Submit Hooks）

這是我們最主要的策略。我們有一個 PreToolUse 鉤子，它會包裹所有的 Bash(git commit) 命令。當(dāng) Claude 嘗試提交代碼時，它會先檢查 /tmp/agent-pre-commit-pass 文件。這個文件只有在所有測試通過后、由測試腳本生成。如果文件不存在，鉤子就會阻止提交，迫使 Claude 進(jìn)入一個“測試—修復(fù)”循環(huán)，直到構(gòu)建通過為止。

2.提示鉤子（Hint Hooks）

這類鉤子不會中斷流程，而是在 Claude 做出不太理想操作時，提供一次性提示或反饋。它們屬于“提醒而非強制”的機(jī)制。

我們刻意不使用“寫入時阻斷鉤子”（block-at-write），例如在 Edit 或 Write 操作中直接中斷 Claude 的執(zhí)行。這樣做只會讓智能體感到混亂甚至“挫敗”，更有效的做法是：讓它完整執(zhí)行完計劃，再在提交階段檢查最終結(jié)果。

要點總結(jié)：使用 Hook 的最佳實踐是：

• 在提交階段執(zhí)行狀態(tài)驗證（block-at-submit），確保結(jié)果可靠。
• 避免在寫入階段中斷，讓智能體先完成計劃，再評估最終產(chǎn)物。

規(guī)劃模式（Planning Mode）

在使用 AI IDE 時，規(guī)劃（Planning） 對于任何較大的功能變更都至關(guān)重要。在我的個人項目中，我完全依賴 Claude 的內(nèi)置規(guī)劃模式。這個模式的作用，是在 Claude 開始工作前，與它對齊目標(biāo)：既定義要如何構(gòu)建功能，也明確中途的檢查點（inspection checkpoints）——即它需要暫停并向我展示階段性成果的地方。

經(jīng)常使用這種模式，可以培養(yǎng)出一種直覺：了解在不給 Claude 過多上下文的情況下，什么信息是“最小但足夠”的，既能讓它制定出合理的計劃，又不會讓執(zhí)行階段“跑偏”。

在我們的企業(yè)級 monorepo（單體代碼庫）中，我們已經(jīng)開始基于 Claude Code SDK 構(gòu)建自定義的規(guī)劃工具。它的工作方式與原生規(guī)劃模式類似，但我們在提示詞中加入了大量約束，讓輸出內(nèi)容與團(tuán)隊的技術(shù)設(shè)計文檔格式保持一致。此外，它還內(nèi)置了團(tuán)隊最佳實踐——從代碼結(jié)構(gòu)到數(shù)據(jù)隱私、安全規(guī)范，全都自動遵循。這讓工程師們可以像一位高級架構(gòu)師一樣去“共創(chuàng)規(guī)劃”，（至少理論上是這樣）。

要點總結(jié)：在進(jìn)行復(fù)雜變更時，一定要使用內(nèi)置的規(guī)劃模式，先與 Claude 明確計劃與檢查節(jié)點，再讓它正式開始執(zhí)行工作。

技能（Skills）

我非常認(rèn)同 Simon Willison 的觀點：Skills也許比 MCP 更重要。

如果你一直關(guān)注我的文章，就會知道我在多數(shù)開發(fā)工作流中，已經(jīng)逐漸放棄 MCP，轉(zhuǎn)而傾向于構(gòu)建一些簡單的 CLI 工具（正如我在《AI Can’t Read Your Docs》中所論述的那樣）。

（文章鏈接：

https://blog.sshh.io/p/ai-cant-read-your-docs）

我對智能體自主性的理解，已經(jīng)演化為以下三個階段：

1.單提示階段（Single Prompt）

把所有上下文一次性塞進(jìn)一個超大的提示中（問題是脆弱、不具擴(kuò)展性）。

2.工具調(diào)用階段（Tool Calling）

 經(jīng)典的智能體模型。我們手工編寫工具，為智能體抽象現(xiàn)實世界（更好一些，但會帶來新的抽象層和上下文瓶頸）。

3.腳本化階段（Scripting）

我們讓智能體直接訪問底層環(huán)境——包括二進(jìn)制文件、腳本和文檔，它可以即時編寫代碼與這些資源交互。

在這種模型下，Agent Skills 就成了非常自然的下一步演進(jìn)。它們實際上是對“腳本化層（Scripting Layer）”的正式產(chǎn)品化。

如果你和我一樣，早就更傾向于使用 CLI 而非 MCP，那么你其實早就在享受 Skills 帶來的好處。SKILL.md 文件只是讓這些 CLI 和腳本更有組織、更易共享、更易被發(fā)現(xiàn)，并以一種標(biāo)準(zhǔn)方式暴露給智能體。

要點總結(jié)：Skills 是一種正確的抽象。它們把“基于腳本的智能體模型”正式化，這種模式比 MCP 所代表的僵化、類 API 模式更加健壯、靈活、實用。

MCP

引入 Skills 并不意味著 MCP 已死（參見我之前的文章《Everything Wrong with MCP》）。（文章鏈接：

https://blog.sshh.io/p/everything-wrong-with-mcp）

過去，很多人濫用 MCP —— 構(gòu)建了大量臃腫、上下文極重的 MCP 接口，里面塞滿了幾十個功能雷同的小工具，比如：read_thing_a()、read_thing_b()、update_thing_c()……這些接口不過是把 REST API 生硬地“翻譯”了一遍。

如今，“腳本化”模型（也就是 Skills 所正式化的那一層）顯然更優(yōu)，但它仍然需要一種安全訪問運行環(huán)境的方式。而這，正是 MCP 新的、更加聚焦的使命。

在我看來，一個現(xiàn)代化的 MCP 不應(yīng)再是龐大繁瑣的 API 集合，而應(yīng)該是一個簡單、安全的環(huán)境網(wǎng)關(guān)（secure gateway），僅提供少量但功能強大的高級工具，例如：

• download_raw_data(filters…) —— 下載原始數(shù)據(jù)；
• take_sensitive_gated_action(args…) —— 執(zhí)行敏感操作；
• execute_code_in_environment_with_state(code…) —— 在帶狀態(tài)的環(huán)境中運行代碼。

在這種模型下，MCP 的職責(zé)不再是為智能體抽象現(xiàn)實世界，而是管理認(rèn)證、網(wǎng)絡(luò)與安全邊界，然后“讓開道路”，為智能體提供一個受控的入口，讓它用自己的腳本和 Markdown 上下文去完成真正的工作。

目前，我只保留了一個 MCP：用于 Playwright。這很合理——Playwright 是一個復(fù)雜且有狀態(tài)的環(huán)境。至于那些無狀態(tài)工具（如 Jira、AWS、GitHub），我已經(jīng)全部遷移到更簡單的 CLI 方案中。

要點總結(jié)：把 MCP 當(dāng)作數(shù)據(jù)網(wǎng)關(guān)（data gateway）來使用。給智能體提供一到兩個高層工具接口（例如原始數(shù)據(jù)導(dǎo)出 API），然后讓它在此基礎(chǔ)上，通過腳本化方式自主完成工作。

Claude Code SDK

Claude Code 不僅僅是一個交互式 CLI，它同時也是一個功能強大的 SDK，可以用來構(gòu)建全新的智能體——無論是用于編程任務(wù)，還是非編程場景。

如今，在我大多數(shù)新的個人項目中，我已經(jīng)默認(rèn)使用 Claude Code SDK，取代了 LangChain、CrewAI 等傳統(tǒng)框架。

我主要有三種使用方式：

1.大規(guī)模并行腳本執(zhí)行

當(dāng)我需要進(jìn)行大規(guī)模重構(gòu)、批量修復(fù) bug 或代碼遷移時，我不會使用交互式聊天，而是編寫簡單的 Bash 腳本，通過類似 claude -p "in /pathA change all refs from foo to bar" 的命令并行調(diào)用。這種方式比讓主智能體去管理幾十個子代理任務(wù)更高效、更可控。

2.構(gòu)建內(nèi)部聊天工具

SDK 非常適合把復(fù)雜流程包裝成簡潔的聊天界面，供非技術(shù)用戶使用。例如，一個安裝器在遇到錯誤時，可以自動調(diào)用 Claude Code SDK 來修復(fù)問題；或者我們構(gòu)建了一個類似 “v0-at-home” 的內(nèi)部工具，讓設(shè)計團(tuán)隊用自然語言“共創(chuàng)”前端原型，并在我們的自研 UI 框架中實時生成高保真、可直接用于生產(chǎn)的代碼。

3.快速原型開發(fā)

這是我最常見的用法——而且不局限于編程。當(dāng)我有一個新的智能體想法時（比如一個使用自定義 CLI 或 MCP 的“威脅調(diào)查智能體”），我會先用 Claude Code SDK 快速構(gòu)建并測試原型，在驗證可行后再決定是否開發(fā)完整的部署版本。

要點總結(jié)：Claude Code SDK 是一個通用型智能體框架。你可以用它來：

• 批量處理代碼任務(wù)，
• 構(gòu)建內(nèi)部自動化聊天工具，
• 或者快速驗證新的 Agent 概念。

在嘗試更復(fù)雜的框架之前，Claude Code SDK 往往已經(jīng)足夠強大。

Claude Code GHA（GitHub Action）

Claude Code 的 GitHub Action（簡稱 GHA）大概是我最喜歡、也最容易被忽視的功能之一。它的概念非常簡單：在 GitHub Action 里運行 Claude Code。但正是這種“簡單”，讓它變得異常強大。

它有點像 Cursor 的后臺智能體，或 Codex 的托管式網(wǎng)頁界面，但 Claude Code GHA 的自定義能力遠(yuǎn)超它們。你可以完全控制容器和運行環(huán)境，這意味著你能獲得更高的數(shù)據(jù)訪問自由度，同時在沙箱隔離與審計安全上擁有業(yè)界最強的能力。此外，它還支持所有高級特性，比如 Hooks 和 MCP。我們團(tuán)隊用它構(gòu)建了一個自定義的 “PR-from-anywhere（隨處發(fā)起 PR）” 工具鏈。用戶可以直接在 Slack、Jira，甚至 CloudWatch 警報 中觸發(fā)一個 PR 請求，然后 GHA 就會自動修復(fù) bug 或添加功能，最終返回一個已測試通過的完整 Pull Request 。

更妙的是，GHA 的日志記錄了智能體的完整執(zhí)行過程。我們在公司層面建立了一套運維流程，定期審查這些日志，查找常見錯誤、bash 異常或不符合工程規(guī)范的操作。這形成了一個數(shù)據(jù)驅(qū)動的改進(jìn)飛輪：Bugs → 改進(jìn) CLAUDE.md / CLI → 更強的智能體。

甚至可以直接運行類似這樣的命令：

圖片

讓 Claude 自己分析過去幾天的所有智能體運行記錄，找出其他 Claude 卡住的問題、修復(fù)它們，并自動提交一個改進(jìn) PR。

要點總結(jié)：Claude Code GHA 是讓 Claude Code 真正進(jìn)入工程體系的關(guān)鍵工具。它讓 Claude 從一個個人助手，升級為你團(tuán)隊中可審計、可追蹤、可自我改進(jìn)的核心基礎(chǔ)設(shè)施。

.json 配置

最后，我整理了一些在個人項目和專業(yè)工作中都非常關(guān)鍵的 settings.json 配置：

• HTTPS_PROXY / HTTP_PROXY：非常適合調(diào)試使用。我會用它來查看 Claude 發(fā)送的原始請求和提示詞。對于后臺智能體來說，它也是一種強大的精細(xì)化網(wǎng)絡(luò)沙箱控制工具。
• MCP_TOOL_TIMEOUT / BASH_MAX_TIMEOUT_MS：我會調(diào)高這些超時時間，因為我喜歡運行長時間、復(fù)雜的命令，而默認(rèn)超時往往太保守。現(xiàn)在 bash 后臺任務(wù)流行了，我不確定是否還必須，但我習(xí)慣保留以防萬一。
• ANTHROPIC_API_KEY：在工作中，我們使用企業(yè)級 API Key（通過 apiKeyHelper 管理）。這樣可以將許可模式從“按席位付費”轉(zhuǎn)為按使用量付費，更符合我們團(tuán)隊的實際工作方式。

  它還能應(yīng)對工程師使用量的巨大差異（我們觀察到工程師之間有 1:100 的使用差異）。   同時，允許工程師在單一企業(yè)賬戶下自由嘗試非 Claude Code 的 LLM 腳本。

• “permissions”：我會定期自我審計，檢查允許 Claude 自動執(zhí)行的命令列表。

要點總結(jié)：settings.json 是高級自定義的強大入口，可以幫助你根據(jù)工作流靈活調(diào)整網(wǎng)絡(luò)、超時、權(quán)限等核心參數(shù)。

網(wǎng)友：沒有工具比Claude Code改變我編程方式更多

這篇文章的 Hacker News 評論區(qū)也非常熱鬧，很多網(wǎng)友都在分享自己對Claude Code、MCP、CLI 使用和 VS Code 集成的實用經(jīng)驗。

有網(wǎng)友十分認(rèn)同作者對MCP的看法：

與其構(gòu)建臃腫的 API，MCP 應(yīng)該是一個簡單、安全的網(wǎng)關(guān)，提供少量強大的高級工具……MCP 的工作不是抽象現(xiàn)實給智能體，而是管理認(rèn)證、網(wǎng)絡(luò)和安全邊界，然后退到一邊。

圖片

也有一些開發(fā)者分享，自己已經(jīng)用輕量 CLI 替代 MCP，因為 CLI 更靈活、易于定制，而 MCP 更像是標(biāo)準(zhǔn)化、安全的內(nèi)部網(wǎng)關(guān)。

“我發(fā)現(xiàn) CLI 對 Claude 更容易，尤其是在規(guī)劃時指導(dǎo)它給用戶添加提示。我們的認(rèn)證、日志、基礎(chǔ)設(shè)施狀態(tài)都是 CLI 可用的，用起來感覺不錯。”

“今天我的大部分集成都是純 CLI，而不是 MCP。CLI 可以做任何事，但 MCP 仍然作為標(biāo)準(zhǔn)存在，方便平臺采用統(tǒng)一接口。”

“我唯一的 MCP 是代碼解釋器。我最近嘗試做一個 MCP “代理”，讓智能體在代碼解釋器內(nèi)調(diào)用 MCP。但總體上我仍不怎么用 MCP。”

圖片

圖片