國家資通安全研究院 · 技術研究簡報 · 2026-06
智能體工程：當 AI 代理成為你的團隊
解析 Matt Van Horn 兩篇 X 文章的工作方法、它的 Token 成本與管理，以及機關導入的可借鏡與風險界線
文章內容
作者背景
分析推論
如何閱讀本簡報
先說清楚每一句話的來源
兩篇 X 全文已取得，主體為可查證的文章內容；其餘為作者背景、補充資料與分析推論
| 來源標籤 | 代表什麼 | 取得狀況 |
|---|
| 文章內容 | 兩篇 X 文章的直接陳述 | 已取得：使用者提供 PDF 全文（2026-03、2026-06） |
| 作者背景 | 作者身分、經歷與立場 | 已取得：文章自述＋公開 GitHub |
| 補充資料 | 外部開源資料、第三方資訊 | 已取得：GitHub、生態專案 |
| 分析推論 | 本院依資料所做的判讀 | 明確區隔於事實 |
| 實務建議 | 機關導入的可操作建議 | 對應 Token、風險與導入章節 |
分析推論註：codebase-memory-mcp（DeusData）兩篇文章皆未提及，列為延伸
一句話總結
把工程從「80% 寫程式」翻轉成「80% 規劃」，人出想法、代理動手
威力來自大量並行代理，代價是大量 token；方法論值得吸收，但要懂得管 token，也有不可照搬進機關的做法
文章內容分析推論
作者 / 來源可信度評估
作者身分明確、實作經驗豐富，留意商業立場
| 項目 | 觀察結果 | 對可信度的影響 |
|---|
| 帳號 / 觸及 | X @mvanhorn（認證）；兩篇合計約 190 萬瀏覽 | 正向—高觸及、可追溯 |
| 背景 | 多產開源作者：last30days（約 27K★）、Printing Press、Agent Cookie | 正向—作品可稽核 |
| 相關經驗 | Compound Engineering #3 等多專案頂尖貢獻者，數百個 PR | 正向—實作能力強 |
| 內容類型 | 第一人稱實戰經驗分享（非學術、非獨立評測） | 留意—個人經驗、樣本為自身 |
| 可能立場 / 利益 | 多推廣自有或所屬生態（Every、Printing Press）之工具 | 注意—工具選型需獨立評估 |
A−
吸收價值 A−：值得完整吸收方法論，可作為近期研究重點。方法論層級證據充分；具體工具與「最佳實踐」屬個人經驗與商業生態，導入前需獨立查證
作者背景補充資料來源：文章自述、公開 GitHub
問題意識 · 為何現在不同
不是 AI 變強，而是工作模式翻轉
重點從「人寫程式、AI 補完」轉為「人定方向、代理研究與執行」
過去 · 傳統開發
80% 寫程式、20% 規劃
- 一次開一個編輯器
- AI 當自動完成工具
- 規劃多在腦中、不落檔
現在 · 智能體工程
80% 規劃、執行機械化
- 4–6 個代理 session 並行
- AI 是會研究、會執行的隊友
- 思考寫進 plan.md，可重用
文章內容來源：2026-06〈所有智能體工程技巧〉
核心主張
三個觀念撐起整套方法
01 計畫先行先做 plan.md
有想法第一件事是 /ce-plan，不是開始寫；計畫是能撐過一切的檢查點
02 不要讀計畫計畫是給代理看的
強迫計畫存在讓代理不偷懶；人只用 TLDR、eli5 抽查，不逐行讀
03 人出想法人定方向、代理動手
人負責出想法、判斷品質與方向，動手交給代理（作者原話：Be the taste, let them be the hands）
文章內容來源：兩篇 X 文章
方法論全景
二十多個技巧，收斂成六大類
規劃
/ce-plan、/ce-brainstorm、為計畫做計畫
輸入
語音（Monologue／Wispr Flow）、會議逐字稿（Granola）
並行
cmux 4–6 分頁、終端機預設開 Claude／Codex
自動化
遠端控制、email 觸發、聲音 hook、跳過權限
知識／開源
筆記當知識庫、自己寫 skill、貢獻開源
文章內容分析推論來源：兩篇 X 文章（本院歸類）
關鍵拆解 · 規劃迴圈
/ce-plan → plan.md → /ce-work 的循環
先並行研究、落成結構化計畫，再機械化執行；計畫是跨 session 的檢查點
03產出 plan.md
含做法、要動的檔、驗收清單
05接續
context 爆掉開新 session 接計畫
文章內容來源：兩篇 X 文章 · Compound Engineering（Every）
進階規劃 · 不只用在程式
最深的工作，先「為計畫做一份計畫」
為計畫做計畫
不要直接要成品
要交付的東西先別寫；先讓代理規劃「怎麼讀資料、怎麼產出」，再執行。作者稱這是「讓 LLM 不偷懶最有效的一招」，策略文件、競品分析、董事會更新同樣適用
會議轉計畫
原始逐字稿直接進
Granola 會議逐字稿不先摘要、原封不動丟進 /ce-plan，交叉比對程式碼與過往決策，一次產出提案。作者靠這招把一頓午餐談話變成可用的產品提案
文章內容來源：兩篇 X 文章
關鍵拆解 · 並行
一個人，同時指揮多個代理
多分頁cmux 4–6 分頁
寫計畫、執行、跑研究、修 bug，各跑一件事
預設代理終端機直接開 agent
新分頁就是對話視窗，不是 shell；少一個動作就多開一個
完成提示聲音 hook
走開、聽到聲音再回來，知道哪個 session 好了
雙引擎Claude 規劃、Codex 執行
大型平行建置丟 Codex，Claude 留在規劃與品味
文章內容來源：兩篇 X 文章
關鍵拆解 · 輸入與遠端
用講的，而且隨處都能開工
語音輸入邊走邊講
Monologue／Wispr Flow；轉錄不必完美，模型會補上下文。作者誠實：開放辦公室講話仍會尷尬
遠端執行Mac Mini 當主機
Telegram／tmux 遠端，飛機斷網重連，工作照樣在跑
信箱觸發給 Claude 一個 email
AgentMail：寄信即開 session，附件用路徑帶入
文章內容來源：兩篇 X 文章 · AgentMail
關鍵拆解 · 讓能力累積
做超過兩次的事，就寫成 skill
文章內容來源：兩篇 X 文章 · Compound Engineering
章節轉折 · 一個現實問題
這套流程，很吃 token
並行研究代理、4–6 個 session、長計畫與逐字稿——威力來自大量 token，於是 token 管理變成成敗關鍵
耗用
並行研究代理、多 session、長輸入同時吃掉額度
管理
雙引擎分流、關閉 fast mode、改用省 context 的工具
進階
把程式庫建成知識圖譜，讓代理少讀檔、少花 token
文章內容分析推論文章 Bonus〈When You Run Out of Tokens〉即談此題
Token 經濟學 ①
威力的代價：大量 token
耗用不是浪費，而是這套方法的運作方式；先看清來源，才能編列額度與管理
來源 01並行研究代理
/ce-plan 一次派出多個代理讀碼、找慣例、查文件，同時燒
來源 02多 session 並行
一天 4–6 個 session，各自帶完整 context
來源 03高推理檔位
Codex 與 Claude 都開 xhigh，單次用量更大
來源 04Fast mode 另計費
作者說 Claude fast mode 在 $200 方案外按 token 計，所以關掉
來源 05長輸入
整份會議逐字稿、整個程式庫一起丟進去
文章內容來源：兩篇 X 文章（section 9 與 Bonus）
Token 經濟學 ②
文章自己給的四個省 token 做法
文章內容來源：兩篇 X 文章（section 9、10）
Token 經濟學 ③ · 延伸工具
再進一步：讓代理少讀檔，就少花 token
研究代理最燒 token 的動作是「反覆讀檔找答案」；把程式庫先建成知識圖譜、改用結構化查詢，可大幅降低這部分
痛點
逐檔讀取很燒
- 代理反覆 grep → 讀檔 → 再 grep
- 回答一個結構性問題就耗大量 token
- 跨 session 沒有持久的程式結構記憶
解法 · codebase-memory-mcp（延伸）
用知識圖譜查詢取代讀檔
- 把程式庫索引成圖譜（函式／呼叫鏈／路由）
- 代理改用 search_graph／trace_path 查詢
- 開源、本機處理；作者為 DeusData
補充資料分析推論註：兩篇文章未提及此工具，為本院延伸建議
Token 經濟學 ④ · 數據查證
省多少？行銷數字與論文數字不一樣
廠商範例宣稱省 120×；同儕式論文基準為省約 10×，且答案品質略低——對外引用以論文為準
逐檔搜尋（廠商 5 次查詢範例）≈ 412,000 tokens
知識圖譜查詢（同一範例）≈ 3,400 tokens
註：第二條實際約佔 0.8%，為可讀性放大顯示；非等比例
查證重點：「120× / 99.2% 縮減」為部落格範例值；arXiv:2603.27277 在 31 個真實 repo 的基準為 token 省約 10×、工具呼叫省 2.1×，答案品質 83%（檔案探索代理為 92%）。對外文件應採論文數字並註明條件
補充資料分析推論來源：codebase-memory-mcp README、廠商部落格、arXiv:2603.27277
工具生態
文章提到的主要工具，多屬作者生態
文章內容補充資料star 數為文章自述
近期佐證 · 動能
三個月內，明顯的採納動能
last30days · 2026-03≈ 4,500 ★
last30days · 2026-06≈ 27,000 ★
延伸（文章未提及）：codebase-memory-mcp（作者 DeusData）為同領域「程式碼知識圖譜」工具，約 1.3 萬★；兩篇文章皆未引用，僅供延伸參考
文章內容補充資料數字為文章自述；★ 為近似值
近 30 天 · 外部佐證
不是一個人的習慣，而是正在成形的業界共識
近一個月，學界正名、社群推進與多家評測同時出現，方法論動能明確
| 近期訊號 | 時間 | 關聯與可學重點 |
|---|
| Karpathy〈From Vibe Coding to Agentic Engineering〉（AI Engineer） | 2026-05-02 | 替「智能體工程」正名，呼應本簡報的工作模式翻轉 |
| Loop Engineering（Peter Steinberger，OpenClaw 作者） | 2026-06-08 | 「別再下 prompt，去設計會下 prompt 的迴圈」；X 約 650 萬瀏覽，把人出想法、代理執行再往前推 |
| Boris Cherny（Claude Code 作者）2026 實務分享 | 2026 上半 | 指揮代理隊、每日數十 PR · 8×／80% 等數字為報導，需查證 |
| codebase-memory-mcp 第三方評測（RepoDaily、AIToolly、russ.cloud） | 2026-05～06 | 多家獨立報導，工具熱度的外部佐證 |
| 工作流標準化：Research → Plan → Execute → Review → Ship | 2026 | 多家匯流到同一架構，本簡報的規劃迴圈即此模式 |
補充資料分析推論來源：公開報導與會議資料（近 30 天）；部分數字為媒體／自述
近 30 天訊號 ① · 學界定調
Karpathy 替「智能體工程」正名
把這套做法命名、定調，呼應本簡報第 5 頁的「工作模式翻轉」
場合AI Engineer 大會
2026-05-02 演講〈From Vibe Coding to Agentic Engineering〉
重點從 vibe coding 進化
強調規劃、工具與多代理編排，而非單純自動補完
對機關權威背書
可作為「為何現在要正視這套方法」的依據
補充資料來源：公開報導；演講內容未逐字核對
近 30 天訊號 ② · 社群推進
Loop Engineering：別再下 prompt，去設計會下 prompt 的迴圈
Peter Steinberger（OpenClaw 作者）2026-06-08 貼文、X 約 650 萬瀏覽，把「人出想法、代理執行」再往前推一步
主張從下指令到設計迴圈
不再逐次對代理下 prompt，而是寫出會自動驅動代理的程式
關聯延伸本簡報核心
正是第 6 頁「人出想法、代理動手」的下一步
留意個人觀點
作者現任職 OpenAI；屬趨勢宣示，非實證研究
補充資料分析推論來源：X 貼文（2026-06-08）公開報導
近 30 天訊號 ③ · 原廠實踐
Claude Code 作者：指揮代理隊，而非逐行寫
原廠核心開發者公開實踐這套方法，提升可信度；惟效能數字屬媒體報導，須查證
是誰Boris Cherny
Claude Code 建立者（Anthropic）
怎麼做指揮代理隊
每日同時驅動多個代理、送出數十個 PR
數字需查證
媒體引述「8× 產出、80%+ 由 AI 撰寫（至 2026-05）」，勿直接對外引用
補充資料分析推論來源：第三方報導；數字未經獨立驗證
近 30 天訊號 ④ · 第三方評測
工具熱度有第三方獨立佐證
多家獨立媒體近月評測 codebase-memory-mcp，呼應第 16–17 頁的 token 工具討論
| 來源 | 時間 | 重點 |
|---|
| russ.cloud | 2026-05-10 | 「給 Claude Code／Codex 一張程式地圖」的評介 |
| RepoDaily | 2026-06-19 | 專案當日精選收錄 |
| AIToolly | 2026-06-20 | 工具評介與導入說明 |
第三方介紹多偏正面；導入前仍以 arXiv:2603.27277 與獨立基準查證為準
補充資料來源：第三方媒體（2026-05～06）
近 30 天訊號 ⑤ · 共同架構
業界匯流到同一條工作流
多家做法收斂為 Research → Plan → Execute → Review → Ship，本簡報的規劃迴圈即此模式
補充資料分析推論來源：多家公開做法歸納
機關導入界線
可借鏡的是文化，不可照搬的是捷徑
可借鏡
- 規劃先行的文化（計畫落檔、可重用）
- 研究先行：先查證再動手
- 人類覆核當關卡
- 把重複流程寫成可重用 skill
- 用 token 管理工具控制成本
不可照搬
- 跳過權限確認（--dangerously-skip-permissions）
- 把完整原始碼／機敏資料丟雲端代理
- 單點依賴個人化、變動快的工具鏈
- 用個人帳號與生態跑公務
分析推論實務建議依本院判讀整理
風險與對策
每一項風險都有可執行對策
| 風險 / 限制 | 對策 |
|---|
| ● 跳過權限確認（作者主推 YOLO） | 機關一律保留權限控管，禁用 bypassPermissions |
| ● Token 成本失控（並行代理大量耗用） | 編列額度、雙引擎分流、導入省 token 工具並量測 |
| ● 商業推廣偏誤（多為自有生態工具） | 工具選型獨立評估，不綁單一供應商 |
| ● 工具鏈高度個人化、變動快 | 以方法論為主、工具為輔，建立內部標準 |
| ● 機敏資料外流（語音／雲端／email 觸發） | 資料分級、隔離環境、保留稽核軌跡 |
| ● 把代理輸出當定論 | 維持人工覆核，重要產出須查證 |
文章內容分析推論含作者自陳（AI Psychosis 一節）
作者真實案例 · 不只用在程式
同一套流程，從寫程式延伸到生活
把「研究→計畫→執行」用在非程式的事，作者連訂迪士尼、招募、跑腿都這樣做
端到端迪士尼一日遊
在足球場邊用語音 /last30days 查園區整修，產出 plan.md、部署成網站，再用 OpenClaw 設自動搶票提醒
招募午餐變產品提案
把 Granola 會議逐字稿丟進 /ce-plan，一次產出提案；那位候選人後來全職加入團隊
生活Printing Press 跑腿
Tesla 預熱「把車預熱到約 22°C」、Instacart 加購、Alaska Airlines 訂家庭旅行
「我老婆對我很火大」 作者自嘲：隨身帶筆電、開 4–6 個分頁，連送小孩上學都想開工；他說 Mac Mini 遠端是部分解方，但這也預告了下一頁——工具過度滲入生活的代價
文章內容來源：兩篇 X 文章（迪士尼、午餐提案、Printing Press、My Wife Is Mad at Me）
誠實的一頁 · 作者自陳
作者自己提出的警告：AI Psychosis
代理本該幫你做事，結果每個朋友都比以前更拼——作者直言這是成癮，不是效率
現象停不下來
用代理開發像史上最好玩的電玩，迴圈太順、容易上癮
陷阱空 launch
做得出任何東西卻沒人用，迷失在「一直做」而失去身邊的人
建議顧好人
休息、走出去、跟在乎的人說話，先問「真的有人想要這東西嗎」
文章內容實務建議機關導入應一併管理過勞風險
應用邊界
適合加速產出，不適合取代判斷與證據
適合導入
- 內部工具與原型快速開發
- 研究彙整、文件與簡報初稿
- 個人與團隊生產力
- 技術交接與知識整理
不建議直接採用
- 未查證即作正式決策
- 法規、醫療、資安高風險內容直接採用
- 機敏或未授權資料
- 需逐字精確引用與證據鏈的場合
分析推論實務建議依本院判讀整理
總結與下一步
學方法論與態度，把成本管好、把高風險捷徑留在門外
- 1規劃先行：plan.md 是能撐過一切的檢查點
- 2研究先行：先查近況再動手
- 3人出想法：價值在出方向與判斷，不在打字
- 4把重複流程寫成 skill，讓能力累積
- 5把 token 當資源管理：分流、省 context、用對工具
- 6誠實面對風險：跳過權限與過勞不可照搬
建議下一步
① 隔離環境試行 plan-first＋人工覆核迴圈
② 訂機關版權限與資料分級規範，明確禁用 skip-permissions
③ 把 token 管理（含 codebase-memory-mcp 等工具）納入評估與量測
④ 以方法論為主、工具為輔，建立內部標準
分析推論實務建議
參考資料清單
可查證來源（取用日 2026-06-25）
- X 文章一（2026-03-23，91.7 萬瀏覽）所有 Claude Code 破解方法
x.com/mvanhorn/status/2035857346602340637
- X 文章二（2026-06-03，100 萬瀏覽）所有智能體工程技巧
x.com/mvanhorn/status/2061877533885473181
- 作者 GitHub：last30days 等開源作品
github.com/mvanhorn
- 相關生態：Compound Engineering（Every）、Printing Press、Agent Cookie、Monologue
- 延伸 · 省 token 工具：codebase-memory-mcp（DeusData，文章未提及）
github.com/DeusData/codebase-memory-mcp
- 延伸 · 數據查證：arXiv:2603.27277（作者 Martin Vogel；token 省約 10×、品質 83% vs 92%）
- 近期趨勢（近 30 天）：Karpathy〈Vibe Coding→Agentic Engineering〉(2026-05-02)、Steinberger loop engineering (2026-06-08)、RepoDaily／russ.cloud 評測
文章內容補充資料主體為使用者提供 PDF 全文
NICS 資安院研究簡報
公開文件
1 / 32
← / → · 滑動 · N 講者備註