uAgents：把代理註冊進 Fetch.ai 鏈上 Almanac 的 Python 框架
A fast and lightweight framework for creating decentralized agents with ease.
秒懂
- 它是什麼？
- uAgents 用裝飾器把排程、事件與訊息處理包成一個 Agent 物件，啟動時自動到 Almanac 智能合約註冊。它的價值與代價都來自同一個設計：位址與訊息綁在鏈上身份，而不是你自己架一個服務。
- 適合誰用？
- 如果你要的是「代理之間靠鏈上身份互相找到對方」這件事，而且團隊願意接受啟動時要連上 Almanac，uAgents 的裝飾器模型能讓你在數十行內跑起第一個代理。若你只是要一個行程內的非同步任務排程器，或你的執行環境無法對外連線到 Fetch.ai 網路，這個框架帶來的註冊與金鑰管理只會是負擔，改用普通的 asyncio 迴圈加你自己選的訊息層更直接。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「代理怎麼被找到」，不是「代理怎麼思考」
多數人看到 AI agent 框架，第一反應是問它怎麼接 LLM。uAgents 的 README 幾乎沒談這件事。它處理的是另一個問題：當你寫出十個各自獨立執行的 Python 行程，它們要怎麼知道彼此的位址、怎麼確認對方真的是對方。README 的講法是，每個代理啟動時會自動加入 uAgents 網路，方式是註冊到 Almanac，一個部署在 Fetch.ai 區塊鏈上的智能合約。
所以它的目標讀者不是想找 prompt 管理或工具呼叫抽象層的人，而是想把一組長時間執行的自主程式接上一個共用尋址層的人。README 對安全的描述也沿著同一條線：uAgent 的訊息與錢包以密碼學方式保護，身份與資產因此受到保障。這裡的「資產」不是比喻，代理有自己的錢包。
反過來說，如果你的代理只在自己的一台機器上互相呼叫，這個註冊步驟對你沒有任何好處。它是一層對外可見的尋址，不是內部通訊的優化。
裝飾器是唯一的入口，Agent 物件是唯一的狀態容器
README 的範例短到可以一眼看完：from uagents import Agent, Context，然後 alice = Agent(name="alice")。行為掛在裝飾器上，例如 @alice.on_interval(period=2.0) 標記一個 async 函式，函式簽名固定收一個 ctx: Context，透過 ctx.logger 輸出、透過 ctx.agent.name 讀取自己的名字。最後 alice.run() 把整個事件迴圈跑起來。
這個設計把「代理」壓縮成一個物件加一組裝飾器，狀態與排程都掛在同一個實例上。on_interval 是 README 唯一示範的觸發方式，週期以秒為單位的浮點數給定。文件目錄另外列出 on 訊息收送的指南（send_receive）、廣播（broadcast）與儲存（storage），但這些頁面內容不在我手上的材料裡，所以它們的具體 API 形狀我無法確認。
值得指出的是 ctx 這個參數。它同時是日誌介面、代理自我參照、以及（依文件目錄推測）訊息與儲存存取的入口。這種把多種能力收斂到單一 context 物件的做法，好處是函式簽名永遠不變，代價是你得靠文件才知道 ctx 上到底有什麼。
seed、private_keys.json 與那個沒給名字的代理
金鑰處理是這個框架最容易踩到的地方，而 README 講得相當直白。建立代理時可以傳 seed，範例是從環境變數讀：Agent(name="alice", seed=os.getenv("ALICE_SEED_PHRASE"))。給了 seed，位址就是固定的。
不給 seed 的話，README 說代理的私鑰會存在本機，與代理名稱放在一起的 private_keys.json 裡。也就是說，金鑰落地位置取決於你執行 python agent.py 時的工作目錄，而不是某個集中設定的路徑。這在容器或 CI 環境裡值得先想清楚：工作目錄若每次都是乾淨的，代理每次啟動就是一個新身份。
最極端的情況是連名字都不給，alice = Agent()。README 明講，這樣每次執行都會產生新的位址。對需要被其他代理穩定尋址的代理來說，這等於每次重啟都換一次門牌。
把 seed 放進環境變數是 README 自己示範的做法，不是我的建議，這點差別很重要：框架提供的是機制，金鑰怎麼保管仍然是使用者的責任。
從安裝到跑起來，實際會打到的指令只有兩行
安裝是 pip install uagents，README 標示支援 Python 3.10 到 3.13。這個版本區間是硬約束，不是參考值：超出範圍的直譯器不在支援清單內。
執行則是 python agent.py。README 說你應該會在終端機看到結果，因為範例用 ctx.logger.info 印出問候語，週期兩秒。整個最小可行範例不含 import 只有六行左右。
這裡沒有任何設定檔、沒有 YAML、沒有環境變數前綴約定。框架把配置壓到只剩建構子參數，這對快速起手是優點，對需要多環境切換的部署則是缺點，你得自己在程式碼外層處理。
另外要注意 README 提到的兩個目錄：python 資料夾放 Python 函式庫本體，python/uagents-core 放的是可與 Fetch.ai 生態與代理市集整合的核心定義。如果你要的不是完整框架而是底層定義，後者才是你要看的地方；近期發布清單裡也確實有獨立的 core@0.4.9 版本號，說明這兩條線是分開發版的。
註冊上鏈這件事，同時是賣點與失敗模式
啟動時註冊到 Almanac 意味著代理的啟動路徑上多了一個外部依賴。README 沒有描述離線行為、重試策略或註冊失敗時會發生什麼，所以我無法告訴你斷網時代理會卡住、還是照常跑但沒被註冊。這是採用前必須自己驗證的一點，而且它會直接影響你的部署拓撲：能不能接受代理啟動需要對外連線。
第二個限制是隱含的耦合。一旦代理的身份與 Fetch.ai 生態綁在一起，你很難把尋址層換掉而保留其餘程式碼。這不是 bug，是設計選擇，但它決定了這個框架適合當起點、不適合當可替換的中介層。
第三，README 自己的免責聲明寫得很硬：專案以 as-is 提供，不附任何明示或暗示的擔保，使用者承擔所有風險，包括非預期的行為與資料遺失。搭配上鏈註冊與錢包這兩個元素，這段話不該被當成樣板文字跳過。
最後，README 沒有給出任何效能數字、延遲或吞吐量描述。任何說它「快」的說法，在現有材料裡都只是描述詞，沒有可查證的依據。
與一般訊息佇列框架的差別在哪裡
拿 uAgents 跟 RabbitMQ、NATS 或 Redis Pub/Sub 這類系統比，差別不在傳輸效率，而在身份從哪裡來。訊息佇列裡的身份是連線憑證，由你的基礎設施簽發，代理之間互相信任是因為它們連上同一個 broker。uAgents 把身份放在鏈上：代理有錢包，訊息以密碼學方式保護，尋址靠 Almanac 這個智能合約。
這個差別的實際後果是：在訊息佇列的架構裡，你要自己處理「這個訊息聲稱來自 alice，但真的是 alice 嗎」；uAgents 把這一層放進框架。反過來，訊息佇列不需要你的代理在啟動時接觸任何公有鏈。
如果你要的是同一台機器內部的任務分派，兩者都不需要，asyncio 的 create_task 加一個 dict 就夠了。uAgents 的複雜度只有在跨組織、跨信任邊界的代理協作時才開始划算。這是判斷要不要採用的分界線，而不是功能清單的長短。
維護成本與授權的實際含意
授權是 Apache-2.0，這表示你可以商用、修改、再散布，條件是保留授權與著作權聲明、標註修改，並且授權條款本身不含專利報復條款之外的額外限制。我不是律師，具體條文請自行閱讀 LICENSE 檔案，這裡只指出它屬於寬鬆授權而非 copyleft。
維護面的訊號可以從發布節奏讀出來。近期發布清單顯示 v0.25.5 在 2026-08-20、v0.25.4 在 2026-08-07，而 core@0.4.9 在 2026-08-06。版本號還在 0.x，代表 API 尚未承諾穩定；同時主線與 core 分開發版，意味著升級時要分別追蹤兩條版本線。最後一次推送時間是 2026-09-07，與最新發布相隔不遠。
對採用者的實際含意是：pin 住版本，並且在升級 uagents 時一併確認 uagents-core 的對應版本。0.x 的版本號本身就是一個訊號，不要假設裝飾器或 ctx 的介面不會變。
編輯結論
如果你要的是「代理之間靠鏈上身份互相找到對方」這件事，而且團隊願意接受啟動時要連上 Almanac，uAgents 的裝飾器模型能讓你在數十行內跑起第一個代理。若你只是要一個行程內的非同步任務排程器，或你的執行環境無法對外連線到 Fetch.ai 網路，這個框架帶來的註冊與金鑰管理只會是負擔，改用普通的 asyncio 迴圈加你自己選的訊息層更直接。動手前先確認三件事：你的 Python 版本落在 3.10 到 3.13 之間、seed 要從環境變數注入而不是寫死在程式碼裡、以及 private_keys.json 會被寫在代理名稱旁邊的那個工作目錄。
社群筆記