系列說明 >> 本系列大部分 PR 來自私人或公司專案，部分程式碼、環境設定與實作細節不便公開。

我只能保證文中提到的 PR 與問題皆為真實案例，但會經過必要的匿名化與內容調整。

本系列主要分享問題如何被發現、背後的思考方式，以及解法如何形成，不會深入討論完整實作與部署細節，敬請見諒。

Today’s Change

• Change Ref： Commit 9e6b53b－feat(serialwrap): scaffold
• Issue： Agent 可以透過 tmux 操作 minicom，但 command 與 output 很難正確對應。
• Root Cause： tmux pane、minicom process 與 log 之間沒有統一的操作介面。
• Solution： 把原本的本機工具 ser-dep 搬進 GitHub，建立 serialwrap repo。
• Evidence： 第一版已具備 minicom discovery、command dispatch、log slicing 與 session registry。

寫在前面：一個嵌入式工程師的 Agent 實驗

這個系列是一個每天在各種軟硬體介面之間上竄下跳的嵌入式系統工程師，
如何用一年的時間，用真實案例摸索出一條貫穿軟硬體之間、能解決現場問題的道路。

Agent 的興起其實大約也就一年多一點的時間，AI engineering 才從 prompt、context 慢慢爬，到現在 harness、loop、graph 的飛奔。
不才如我，有幸被 Gemini CLI（對，就是現在變得很可愛的那隻龍）帶入 Agent 的世界，見證了 Agent 的極速發展，也對 Agent 的應用充滿了各種大膽的想法。

Agent 看得到 source，但看不到 runtime

Agent 時代與 Chat 時代最大的差異是 Tool Use 的能力，AI 再也不是只能跟你聊聊天、查查資料、補補程式碼，幫你克漏字填充。
時代的巨輪在這個時間點有了根本性的改變，可以真正幫你修電腦、做簡報、build code、找 root cause 了。
但在 embedded 的環境裡，我們需要在硬體上操作，source code 跟 runtime 之間的連結還只能存在工程師的腦海裡。
Agent 看得到 source code，但看不到 runtime，copy-paste 仍然是主要的工作方式。
那麼，第一個大膽的想法就浮出來了。

既然 Agent 已經可以 Use Tool，直接讓 Agent 用 sed、grep、讀 compile_commands.json、抓 ctags、對 cscope 都是理所當然的事吧？
太棒了，人生太完美了，我只要跟 Agent 說「給你 code，快點看」，Agent 就會跟我說「給你屎，快點吃」。

欸～不是這樣的吧？
Agent 回覆經常都是完美的執行最高級的謊言——七分真三分假。
用那七分真的 source code，去證明那三分假的 runtime 行為是對的！！！

Transformer 是這樣教你糊弄人的嗎？

第一個把手伸進板子的工具：minicom

為了逼出 Agent 的極限（不想幫它擦屁股），那何不給它一個 tool，讓它使用 UART 自己證明自己說的是對的？
於是，大名鼎鼎的老字號 console tool——minicom，成了第一個 Agent 把手伸進板子上的工具。

minicom 幫 Agent 解決了「看 runtime」的問題，但「下指令」呢？
這也不是什麼大問題，我們可以利用 minicom 的 script，把指令編成 script，讓 minicom 去跑。

看起來非常完美，用 script 下指令，用 log 看結果，Agent 也能完美組合這些工具，進入：
分析 source -> 寫 script 下指令 -> 叫 minicom 執行 -> 拿 minicom 的 log 回來分析

嗯，完美閉環，本系列結束，收工！！！！！

才怪！！！！！

UART 的骨感現實

對 UART 有點認識的老屁股們應該都知道，UART 是一種獨佔設備，minicom 是一種互動式工具。
Log 會在任何你沒預期的時間點噴出來，特別是你執行完指令之後的……很久很久以後……例如 memory leak。

上面的架構看起來很美好，實際上很骨感：

• 我其實需要對一個 UART console 持續記錄。
• 需要即時看到 Agent 下了什麼指令，而不是一直翻 Agent 的 script，三不五時還會被更新。
• 偶爾我也想用一下 console，查一些 runtime 其他方面的資訊。

用 tmux 收拾爛攤子

這時我也不得不讚美偉大的自由軟體，在我才要上小學(?)時的老工具——screen 早就想到了這些問題，數十年的發展早就有了一套完美的處理方式。

所以我選用了 screen 的競品——tmux 來解決上面這些煩死人的問題：

1. 我在 tmux 裡開了 minicom 去連 console。
2. tmux 切另外一個 pane 跑 Agent。
3. Agent 去讀 minicom 的 log 分析。
4. Agent 用 tmux sendkey 送指令進板子。

Awesome、Wonderful、Perfect！！！完美閉環！！！

我們見證了時代的奇蹟、人工智慧的奇點、AGI 的雛形、腦袋外包的開始……

啊～還不行，還差一點。

ser-dep 的起點：把操作藏起來

寶貴的 context window 塞滿了如何操作 minicom、tmux pane、sendkey 的操作方式，
我得把它包成一個指令、一個 MCP，這樣我只要一點點的 context window，就能換到更認真工作的 Agent，Great～

這就是 ser-dep 的起點。

說穿了，它一開始就只是一支放在工作目錄裡的 wrapper，想把 Agent 每次都得重新學一次的 tmux、minicom、sendkey 跟 log 切割藏起來。
就是一支告訴 Agent：「你要下什麼指令，跟我說；指令吐了什麼，我告訴你」的工具。沒有什麼完整架構，也沒有先想好產品名字，反正先讓它能用，解決這些眼前的擦屁股工作。
實際用了一段時間後，這玩意兒還真好用耶，越用越順手，不用再分心管理衝突、不用每次都再跟 Agent 說明要怎麼幹的感覺真是不錯……

今天沒有 PR

這次真的閉環了，所以我把它從本機搬進 GitHub，順手改名叫 serialwrap。

今天沒有 PR，只有 feat(serialwrap): scaffold 的 first commit。

Have a nice day.