From 00d964e30dcf01518ddf8c8a1792a37da6fd9147 Mon Sep 17 00:00:00 2001 From: roy328line Date: Fri, 5 Jun 2026 13:41:59 +0800 Subject: [PATCH 1/9] Add 2026-06-05 learning notes: AI Agent era blockchain tech review + development practice Added daily check-in notes for June 5, 2026, covering AI Agent perspectives on blockchain technology and development. --- notes/roy328line.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/notes/roy328line.md b/notes/roy328line.md index 9b532cf7e..5d6457ca6 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -15,6 +15,21 @@ AI x Web3 School ## Notes +# 2026-06-05 + +今日學習：Week 3 直播 | AI Agent 時代，重新審視區塊鏈這項技術選擇 & AI Agent 深度參與下的區塊鏈應用開發實戰 + +核心主題：從 AI Agent 視角重新審視區塊鏈的技術價值，以及 AI Agent 深度參與區塊鏈應用開發的實戰方法。 + +重新審視區塊鏈的三個問題框架：AI Agent 時代，評估一條鏈/技術棧不再是「TPS 多少、生態多大」，而是「這條鏈能不能讓 Agent 安全執行、身份可驗證、行為可審計、支付可自主」。四個關鍵判斷維度：鏈上 Agent 身份（DID/ENS）、可程式化授權（Session Key/Account Abstraction）、原生支付（穩定幣/ERC-20 自動結算）、行為審計（on-chain log + attestation）。 + +AI Agent 深度參與區塊鏈開發實戰：Hackathon 週期的技術選型邏輯——優先選有完整 SDK、有 simulation、有明確 escrow 機制的技術棧。Agent 參與的鏈上應用需要「可組合性」：Session Key + Policy + Pact 可以組合，但每個模組必須獨立可測試。Demo 設計原則：能端到端跑通比功能完整更重要，優先展示「Agent 自主決策 → 觸發 Pact 授權 → x402 支付 → 鏈上收據」這條主線閉環。 + +Week 3 例會精華分享回顧：優秀筆記特質——用第一性原理推導而非羅列知識點；有個人洞察而非課程複述；知識節點之間有因果邏輯連接；有最小實踐設計或 Builder 應用想像。 + +個人洞察：「AI Agent 時代重新審視區塊鏈」的核心轉變是：區塊鏈從「人用的去信任系統」變成「Agent 用的可驗證執行環境」——人需要去信任，Agent 需要可程式化信任邊界。這個視角轉換讓很多之前覺得過於複雜的技術設計（Account Abstraction、Session Key、Pact）突然變得非常必要和自然。 + + # 2026-06-04 今日學習：Week 3 Hackathon Sprint + Wallet/Permission 賽道深化 From ba3f7dc4f22295cc728a447d779a751b514be1bc Mon Sep 17 00:00:00 2001 From: roy328line Date: Sat, 6 Jun 2026 16:57:56 +0800 Subject: [PATCH 2/9] Add 2026-06-06 learning notes: Week 4 Hackathon Build Day 1 + AI Security --- notes/roy328line.md | 808 ++------------------------------------------ 1 file changed, 23 insertions(+), 785 deletions(-) diff --git a/notes/roy328line.md b/notes/roy328line.md index 5d6457ca6..a0a96f42d 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -2,814 +2,52 @@ timezone: UTC+8 --- -# 0xroyluo - -**GitHub ID:** roy328line - -**Telegram:** @roy328328 - -## Self-introduction - -AI x Web3 School - -## Notes - - -# 2026-06-05 - -今日學習：Week 3 直播 | AI Agent 時代，重新審視區塊鏈這項技術選擇 & AI Agent 深度參與下的區塊鏈應用開發實戰 - -核心主題：從 AI Agent 視角重新審視區塊鏈的技術價值，以及 AI Agent 深度參與區塊鏈應用開發的實戰方法。 - -重新審視區塊鏈的三個問題框架：AI Agent 時代，評估一條鏈/技術棧不再是「TPS 多少、生態多大」，而是「這條鏈能不能讓 Agent 安全執行、身份可驗證、行為可審計、支付可自主」。四個關鍵判斷維度：鏈上 Agent 身份（DID/ENS）、可程式化授權（Session Key/Account Abstraction）、原生支付（穩定幣/ERC-20 自動結算）、行為審計（on-chain log + attestation）。 - -AI Agent 深度參與區塊鏈開發實戰：Hackathon 週期的技術選型邏輯——優先選有完整 SDK、有 simulation、有明確 escrow 機制的技術棧。Agent 參與的鏈上應用需要「可組合性」：Session Key + Policy + Pact 可以組合，但每個模組必須獨立可測試。Demo 設計原則：能端到端跑通比功能完整更重要，優先展示「Agent 自主決策 → 觸發 Pact 授權 → x402 支付 → 鏈上收據」這條主線閉環。 - -Week 3 例會精華分享回顧：優秀筆記特質——用第一性原理推導而非羅列知識點；有個人洞察而非課程複述；知識節點之間有因果邏輯連接；有最小實踐設計或 Builder 應用想像。 - -個人洞察：「AI Agent 時代重新審視區塊鏈」的核心轉變是：區塊鏈從「人用的去信任系統」變成「Agent 用的可驗證執行環境」——人需要去信任，Agent 需要可程式化信任邊界。這個視角轉換讓很多之前覺得過於複雜的技術設計（Account Abstraction、Session Key、Pact）突然變得非常必要和自然。 - - -# 2026-06-04 - -今日學習：Week 3 Hackathon Sprint + Wallet/Permission 賽道深化 - -核心主題：ERC-4337 Session Key 實作細節、Cobo CAW Pact 機制完整分析、x402 + CAW 自主支付閉環 Demo 設計 - -Session Key 四層約束：合約白名單 + 方法白名單 + 額度上限 + 時間窗口。攻擊者拿到 Session Key 也只能在授權邊界內操作。 - -Pact 機制：任務級授權策略，五個關鍵維度（資金範圍、合約白名單、額度控制、時間邊界、審計鏈路）。Pact vs Session Key：Session Key 是錢包層臨時授權，Pact 是任務層持久策略，兩者可組合。 - -x402 + CAW 閉環設計：Agent 在 Pact 授權下通過 x402 完成自主服務採購，Pact 驗證必須在 simulation 階段完成。 - -個人洞察：Session Key + Pact 兩層設計解決了 Agentic Wallet 的核心矛盾——既不太嚴格（每次都要人工確認），又不太寬鬆（Agent 拿大量資產控制權）。 - -PR: #53 - - -# 2026-06-03 - - -今日學習：Week 3 黑客松賽道實戰 + Co-learning 任務推進 - -核心主題：Hackathon 賽道分析、Cobo CAW 深入研究、x402 + CAW 自主支付閉環設計 - -Hackathon 兩大賽道：Cobo（Agentic Economy × Cobo Agentic Wallet）+ Z.AI（Web3 × Long-Horizon Task） - -關鍵洞察：Pact = 任務級授權邊界（限額/合約白名單/時間窗口），讓 Agent commerce 在明確授權、預算控制和可審計記錄下完成自動交易。 - -Week 4 目標：選定賽道，做出能跑通完整閉環的 demo。 - -PR: https://github.com/IntensiveCoLearning/AI-Web3-School/pull/53 - - -# 2026-06-02 - - - -今日學習：Week 3 Hackathon Openday + Agentic Commerce 深化 - -核心概念：Week 3 正式啟動 Hackathon，課程進入「從學習到執行」的關鍵轉折點。Agentic Commerce 是今日重點方向：AI Agent 不只是提出建議，而是在明確預算、授權、可審計記錄下完成真實的鏈上交易。 - -Hackathon Openday 核心理解： - -- Week 3 分兩條線：課程線（補齊 Week 1-2 基礎 + 深入方向研究）和 Hackathon 線（正式啟動賽道、組隊、項目收斂） - -- \- 進入 Week 4 前 Ready Checklist：項目方向 3 句話說明、隊伍確認、SDK/API/合約技術棧確認、Repo Skeleton + 任務看板、Week 4 Sprint Plan - - -Agentic Commerce 深化整合： - -- Cobo 賽道核心：讓 AI Agent 具備可控的鏈上資金執行能力（Agent-Native Payments、Agent 資源採購、A2A Economy） - -- \- [Z.AI](http://Z.AI) 賽道核心：GLM-5.1 長程任務能力，自主拆解複雜任務、多步驟計劃、持續工具調用、完整閉環 - - -Week 3 個人方向鎖定：主方向 Wallet / Permission / Safe Execution，延伸 Account Abstraction 研究。研究重點：ERC-4337 Session Key 作為 Agentic Wallet 基礎 + Cobo CAW Pact 機制。 - -個人洞察：Session Key + Policy 設計是 Agentic Wallet 的核心防護層，也是最有可能在 Hackathon 週期內完整展示的技術點。 - -PR: #53 - - -# 2026-06-01 - - - - - -今日學習：深讀 Governance AI 模組 - -核心概念：Governance AI 不是讓 AI 替社區投票，而是幫助治理參與者更好地閱讀提案、追蹤會議、理解預算、保留來源，在關鍵決策中減少信息不對稱。 - -知識節點：Proposal Summary / Meeting Action / Contribution Graph / Budget Check / Source Traceability / Deep Funding / Plurality - -個人洞察：治理 AI 的核心是提升信息質量，而非替代人的政治判斷。Proposal Summary + Source Traceability 是 Governance AI 的基礎設施；Plurality 思路讓治理 AI 展示多元視角而非單一結論。 - -PR: IntensiveCoLearning#53 - - -# 2026-05-31 - - - - - - -今日學習：深讀 AI Oracle + Verifiable AI 模組，理解 AI 輸出如何在鏈上被驗證。 - -核心概念：AI Oracle 把模型判斷變成可記錄、可驗證、可挑戰的鏈上輸入；Verifiable AI 讓「相信模型」變成「驗證證據和約束」。驗證成本必須和輸出影響力匹配，按風險分層設計驗證強度。 - -今日產出：AI Oracle 七大知識節點（AI Output / Data Feed / Model Result / Oracle Risk / Attestation / Proof of Inference / Dispute）+ Verifiable AI 六大知識節點（TEE / ZK / zkML / Verifiable Compute / Benchmark / Audit Trail）整理完成。 - - -# 2026-05-30 - - - - - - - -今日學習：深讀 AI Security / Privacy / Sovereignty 模組，整理 Agent Threat Model - -核心學習： - -- Prompt Injection 在 AI x Web3 特別危險：注入成功 → 執行鏈上交易 → 資金損失不可逆 - -- \- Tool Abuse 防禦：Allowlist 白名單 + 參數校驗 + Simulation + Tracing Log - -- \- 數據主權設計：高敏感任務使用本地模型；低敏感任務可用雲端模型 - -- \- TEE + Attestation 組合讓 AI 執行在可信環境中可驗證，把「信任意圖」轉換為「驗證行為」 - - -設計了 DeFi Agent Threat Model：涵蓋資產清單、攻擊入口、控制手段、高風險動作清單四個維度 - - -# 2026-05-29 - - - - - - - - - -今日學習：複習深化 Agent Trust & Reputation + Account Abstraction，整合信任三層架構 - -核心收穫： - -- Agent Trust & Reputation：信任不是分數，而是可追溯的證據集合。Reputation / Attestation / Stake / Slashing / Validation / ERC-8004 七大知識節點整理完畢 - -- \- Account Abstraction：ERC-4337 UserOperation 流程 + Session Key 作為 Agent Wallet 關鍵基礎（限時限額員工門禁卡的最小權限設計） - - -整合洞察：Identity（你是誰）+ Trust（別人為什麼信你）+ Permission（你被允許做什麼）= AI Agent 安全上鏈的完整基礎設施，三者缺一不可。 - -GitHub 筆記：PR #47 (patch-6 branch) - - -# 2026-05-28 - - - - - - - - - - -今日學習：Account Abstraction（賬戶抽象）+ Co-learning 共學活動 - -核心概念：ERC-4337 讓帳戶可編程，Session Key 是 AI Agent 安全上鏈的關鍵基礎——不是「給 AI 一把主鑰匙」，而是「給 AI 一張限時限額的員工門禁卡」（最小權限原則）。 - -學習重點： - -- ERC-4337：UserOperation → Bundler → EntryPoint → 智能帳戶執行的完整流程 - -- \- Smart Account：驗證邏輯可定制，支持多簽、社交恢復、批量執行 - -- \- Session Key：給 Agent 的臨時授權，可限制合約/方法/額度/時間，是 Agentic Wallet 的基礎 - -- \- Paymaster：Gas 抽象，允許第三方贊助費用或非原生資產付費 - - -AI x Web3 洞察：Account Abstraction 把「全有或全無的控制權」拆成「細粒度、可審計、可撤銷」的授權結構。Identity + Trust + Permission 三層合在一起，才是 AI Agent 安全上鏈的完整基礎設施。 - -PR: #47 - - -# 2026-05-27 - - - - - - - - - - - -今日學習：深讀 Agent Trust & Reputation 模組 - -核心概念：Agent 的可信度應來自可驗證行為，而非自我聲明。信任不是一個分數，而是一組可追溯、可比較、可解釋的證據。 - -學習重點整理： - -- Reputation：按任務類型拆分的歷史表現信號集合，需要時間衰減機制 - -- \- Review：需綁定任務 ID 和交付物，質量比數量重要，要防止互刷 - -- \- Attestation：結構化的可驗證聲明，需要 issuer/evidence/expiration/revocation - -- \- Stake：讓承諾有成本，但 Stake ≠ 能力，需與其他信號一起評估 - -- \- Slashing：明確可驗證違約才適合自動罰沒，主觀任務應先進入 dispute - -- \- Validation：區分「能力驗證」和「任務結果驗證」 - -- \- ERC-8004：身份/反饋/驗證三層分離的去中心化 Agent 信任基礎設施 - - -個人洞察：ERC-8004 沒有試圖做成黑盒評分系統，而是提供可組合的信號公共承載層，讓不同應用可以構建自己的信任過濾規則——這才是真正去中心化的方向。 - -PR：https://github.com/IntensiveCoLearning/AI-Web3-School/pull/45 - - -# 2026-05-26 - - - - - - - - - - - - -## **今日學習主題** - -深讀 Handbook：Agent Identity 模組 - -* * * - -## **Agent Identity｜核心整理** - -### **什麼是 Agent Identity？** - -Agent Identity 不是給 Agent 起個名字，而是讓用戶、服務和其他 Agent 能驗證：它是誰、誰控制它、能提供什麼能力、服務入口在哪裡、歷史記錄能不能追溯。 - -核心問題不是「如何命名 Agent」，而是： - -- 誰擁有這個 Agent？ - -- Agent 能做什麼（具體能力邊界）？ - -- 如何調用它（服務入口）？ - -- 它使用哪些錢包或密鑰？ - -- 歷史聲譽和驗證記錄在哪裡？ - - -Agent Identity 的核心，是把 Agent 從臨時會話變成可發現、可驗證、可追責的經濟參與者。 - -* * * - -### **第一性原理** - -> **Agent 身份必須綁定控制權、能力聲明和服務入口，而不只是一個顯示名稱。** - -三個基本要求： - -- **身份要可解析**：別人能從 identifier 找到 profile 和 endpoint - -- **控制權要可證明**：更新 profile 或接收付款的人要能證明自己是 owner - -- **能力要可驗證**：能力聲明需要測試、證明、評價或歷史記錄支撐 - - -* * * - -### **知識節點整理** - -**Agent Profile（身份說明文件）** - -- 包含：名稱、描述、服務範圍、價格、接口、錢包地址、能力列表、模型/工具說明、隱私政策、owner、版本 - -- 應同時給人和機器看：人能理解服務內容和運營方，機器能解析 endpoint、capabilities、schemas、auth、payment - -- **更新歷史很重要**：換了模型、換了服務端、換了收款地址、增加高風險能力，都不應靜默發生，更新記錄本身就是信任信號 - - -**Capability（能力聲明）** - -- 描述 Agent 能完成什麼任務、需要哪些輸入和權限 - -- 越具體越有用：輸入類型、輸出格式、是否需要錢包權限、是否調用外部 API、最長執行時間、失敗如何退款 - -- **風險分級**：低風險（只讀分析）、中風險（生成交易草稿）、高風險（自動執行交易） - -- 不應寫成「我什麼都能做」 - - -**Service Endpoint（服務入口）** - -- 可以是：HTTPS API、A2A endpoint、MCP server、Webhook 或鏈上 registry 指向的服務地址 - -- **安全性直接影響身份可信度**：攻擊者劫持 endpoint，即使鏈上 Agent id 沒變，用戶實際調用的也可能是惡意服務 - -- Endpoint 更新應需要 owner 簽名，並保留歷史 - -- 還要描述支持的協議和版本（A2A、MCP、REST API、WebSocket 交互方式不同） - - -**Registry（身份登記）** - -- 用來登記、發現和更新 Agent 身份 - -- 鏈上 registry：提供公開可查的身份錨點（agent id、owner、profile URI、服務 endpoint 和更新記錄），更去中心化 - -- 鏈下 registry：更靈活，但信任邊界更中心化 - -- **Registry 能證明「這個身份是誰注册的」，但不能證明「這個 Agent 一定好用或安全」** - - -**DID / VC（去中心化身份與可驗證憑證）** - -- DID：可解析的去中心化身份，不局限於某條鏈，Agent 可用 DID 表達跨平台身份 - -- VC（Verifiable Credential）：由某個 issuer 簽發的聲明（如「通過了某個能力測試」「由某團隊運營」） - -- **VC 的可信度取決於 issuer**：任何人都能簽發聲明，不等於任何聲明都可信，產品要展示 issuer、簽發時間、撤銷狀態和驗證路徑 - -- 相關標準：W3C DID Core、W3C Verifiable Credentials - - -**A2A（Agent 間通信）** - -- 關注 Agent 與 Agent 之間如何發現、通信、協商任務和交換結果 - -- A2A 是通信層（怎麼協作），身份系統是信任層（在和誰說話），兩者需要結合 - -- **在支付場景中**，A2A 消息最好和 Payment Intent、Receipt、Escrow 狀態關聯，否則對話和結算會分裂成兩套不可對帳系統 - - -**Ownership（控制權）** - -- 決定誰能更新 Agent profile、收款地址、服務 endpoint 和權限 - -- Agent owner 可以是：EOA、Smart Account、多簽、DAO 或企業帳戶 - -- **高價值 Agent 不應由單個熱錢包控制** - -- 建議把 operator（運行服務）和 owner（控制身份和關鍵更新）分開 - - -* * * - -### **Agent Identity 在 AI x Web3 的位置** - -Agent Identity 是 Agent Trust、Machine Payment 和 Agentic Commerce 的**前置條件**： - -- 用戶要付款給 Agent → 必須知道付款對象是誰 - -- 另一個 Agent 要委托任務 → 需要驗證對方服務入口和歷史記錄 - - -**身份本身不等於可信**，它只是信任系統的第一層： - -1. 先知道對象是誰（Identity） - -2. 再看它做過什麼、誰評價過它（Reputation） - -3. 是否有 stake、是否有驗證證明（Trust） - - -* * * - -### **關鍵概念對比** - -| 概念 | 定義 | 重點 | -| --- | --- | --- | -| Agent Profile | Agent 的公開說明文件 | 同時服務人和機器，更新要有記錄 | -| Capability | Agent 能完成的任務聲明 | 具體化、分風險等級 | -| Service Endpoint | Agent 的調用入口 | 更新需要 owner 簽名，保留歷史 | -| Registry | 身份的登記和發現系統 | 提供發現性，但不保證能力品質 | -| DID / VC | 去中心化身份和可驗證聲明 | VC 可信度取決於 issuer | -| A2A | Agent 間通信協議 | 通信層，需與支付/結算系統關聯 | -| Ownership | 控制 Agent 身份和關鍵操作的權力 | 高價值 Agent 需多簽，operator/owner 分離 | - -* * * - -### **最小實踐設計** - -設計一個 Agent Profile： - -1. **基本信息**：Agent 名稱、描述、owner（Smart Account 地址）、endpoint（HTTPS API） - -2. **Capabilities**（3 個）： - - - 能力 1：「生成 Solidity 測試」（輸入：合約代碼，輸出：測試文件，價格：0.5 USDC，限制：無法執行部署） - - - 能力 2：「分析 DAO 治理提案」（輸入：提案 ID，輸出：摘要報告，價格：0.1 USDC，限制：只讀） - - - 能力 3：「執行小額穩定幣支付」（輸入：收款方地址、金額，輸出：交易 hash，價格：0.01 USDC，限制：每次最高 10 USDC，風險：高） - -3. **更新機制**：只有 owner 多簽錢包簽名才能更新 profile，更新後發送 on-chain event 通知訂閱方 - -4. **Endpoint 驗證**：endpoint 包含 owner 簽名的 challenge-response，可用公鑰驗證歸屬 - - -* * * - -### **個人發想** - -今天最大的收穫是理解了「Agent 身份」和「人的身份」的本質差異。 - -人的身份靠法律和社會關係來保證——信任一個人，因為有法律責任、社會聲譽、長期關係。但 Agent 可以在毫秒內建立、複製、消亡，傳統身份機制完全失效。 - -Agent Identity 的精妙之處在於：把身份從「名字」提升到「可驗證的能力邊界和控制權結構」——不需要信任一個 Agent「是好的」，只需要能驗證它能做什麼、誰負責、失敗怎麼辦。 - -DID/VC 的思路讓我感到興奮：如果 Agent 能累積 VC（能力測試通過證明、成功交付記錄、組織隸屬證明），那就像是 Agent 的「學歷和工作履歷」，可以跨平台攜帶和驗證。這是 Agentic Economy 的基礎設施，而不只是技術細節。 - -Operator/Owner 分離的設計也很關鍵——讓運行服務的人和控制身份的人可以是不同角色，這樣即使服務方出問題，身份的所有權和責任仍然清晰。 - -Builder 的機會在於：設計「Profile 可機器解析、Capability 有風險分級、Endpoint 更新有簽名記錄、VC 可跨平台攜帶」的 Agent Identity 系統，讓 AI Agent 的部署和使用從「盲目信任」走向「可驗證信任」。 - -* * * - -## **今日產出** - -- Agent Identity 核心概念整理（7 個知識節點完整筆記） - -- 關鍵概念對比表（Profile / Capability / Endpoint / Registry / DID / VC / A2A / Ownership） - -- 最小實踐設計：完整 Agent Profile 設計（含 3 個 Capability、更新機制、Endpoint 驗證方式） - -- 個人判斷框架：可信 Agent 身份的三個基本要求（可解析、控制權可證明、能力可驗證） - - -* * * - -## **明日計劃** - -- 深讀 Agent Trust & Reputation 模組 - -- 整理 Agent Identity → Trust → Reputation 的完整信任鏈路 - -- 繼續推進 Week 1 Proof-of-Work Pack - - -# 2026-05-25 - - - - - - - - - - - - - -\# 2026-05-25 - - - -今日學習：深讀 Settlement & Escrow 模組 - -GitHub 筆記：[https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-25.md](https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-25.md) - -\## 核心整理 - -**Settlement & Escrow** 解決的是 Agent 經濟裡「錢什麼時候釋放、服務怎麼算完成、失敗怎麼退款、爭議怎麼處理」，把支付從一次轉帳變成完整交易流程。 - -**第一性原理**：自動化交易必須有明確完成條件，否則支付就無法安全自動化。Escrow 設計首先要定義狀態機，而不是先寫付款代碼。 - -**Escrow**：鎖定資金直到交付條件滿足後釋放，最小狀態機：Created → Funded → Delivered → Accepted → Released（或 Refunded / Disputed）。好的 escrow 先定義業務流程，再定義資金流。 - -**Receipt**：不只是「已付款」，應同時服務人和機器：記錄任務 ID、交易 hash、驗收狀態，並成為 reputation 的輸入。 - -**Delivery Proof**：服務方交付的可驗證證明（文件 hash、API 日誌、模型輸出簽名等），必須能和原始任務對應，避免「結果存在但不可驗證」。 - -**Acceptance**：驗收可自動也可人工，高價值任務建議「AI 初審 + challenge window + 人工復核」組合。 - -**Refund**：退款規則必須在任務開始前寫清楚，並考慮部分交付的按比例退款。 - -**Dispute**：爭議記錄是聲譽系統的重要輸入，設計需回答：誰能發起、成本多少、誰有裁決權、是否可申訴。 - -**ERC-8183**：Agentic Commerce 草案標準，把 Agent 交易從「轉帳」提升到「狀態轉換」維度，與 ERC-8004 互補（ERC-8004 偏身份聲譽，ERC-8183 偏任務支付交付）。 - -\## 核心發想 - -Settlement & Escrow 的本質不是「鎖錢」，而是「把整個業務流程狀態機化」。Builder 機會：設計「狀態透明、proof 可驗證、dispute 有成本但可處理」的 Agentic Escrow 系統，讓 AI Agent 之間的委托和交易真正可信任。 - - - - -# 2026-05-24 - - - - - - - - - - - - - - -\# 2026-05-24 - - - -今日學習：深讀 Machine Payment 模組（Stablecoin Payment / Budget / Quote / Payment Intent / x402 / MPP / Subscription / Micropayment） - -GitHub 筆記：[https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-24.md](https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-24.md) - -Machine Payment 核心整理： - -第一性原理：Agent 不應該擁有無限支付能力，只應該拿到具體任務、預算和收款方範圍內的支付權限。支付能力 = 執行能力，一旦 Agent 可以付款，它就可以消耗用戶資金或被惡意上下文誘導。 - -三個核心原則：預算先於執行（沒有預算邊界 = 沒有安全自動支付）、報價必須可比較（Agent 需知道價格/幣種/有效期/退款條件）、收據必須可驗證（付款後能證明付給誰/為什麼付/交付了什麼）。 - -關鍵知識點：x402 把 HTTP 402 Payment Required 變成互聯網原生支付流程，讓 Agent 處理 402（付款）就像處理 401（登錄）一樣自然。MPP 協議化機器間支付流程：服務發現 → 報價 → 授權 → 結算 → 收據。Micropayment 不適合每次都上鏈結算（成本超過服務本身），需要 L2 / payment channel / 批量結算設計。 - -個人洞察：機器支付不是技術問題，而是信任問題。Builder 機會：「Agent 可以信任、用戶可以控制、服務方可以驗證」的支付基礎設施。 - - - - -# 2026-05-23 - - - - - - - - - - - - - - - -學習日誌 · 2026-05-23（Day 7） - -今日學習：Open Agentic Economy: From ERC-8004 / ERC-8183 to Builder Path（直播）+ Agent Wallet 模組深讀 - -Open Agentic Economy 核心：AI Agent 作為獨立經濟參與者的生態，能自主發現服務、協商任務、完成支付、留下可驗證記錄。 - -ERC-8004/8183 方向：鏈上 Agent 如何發現和調用去中心化服務的標準探索。Builder Path 四個維度：身份（誰授權 Agent？）、權限（能做什麼？）、支付（費用如何結算？）、記錄（行為如何被審計？）。 - -Agent Wallet 第一性原理：控制權不能交給一個概率系統。Agent 只能拿到可驗證、可限制、可撤銷的行動空間。六層防禦：Policy → Session Key → Guard → Simulation → Human Check → Revocation。 - -關鍵洞察：Open Agentic Economy 不是讓 Agent 更自由，而是讓 Agent 的自由被規則包起來。Builder 機會在於做「可信任的 Agent 基礎設施」。 - -GitHub 筆記：https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-23.md - - -# 2026-05-22 - - - - - - - - - - - - - - - - -學習日誌 · 2026-05-22（Day 6） - -今日學習：Co-learning 任務推進 + 例會分享 + Week 1 整體複習 - -Week 1 核心收穫：建立判斷框架——任何 AI 輸出進入 Web3 執行層之前，都需要一道人工確認節點。AI 降低操作門檻，但不降低安全標準。 - -AI 基礎脈絡整合：LLM 概率生成 → Prompt 軟約束 → Context 五層結構 → Agent 受約束執行循環 → Frameworks 工作流優先 - -Web3 基礎脈絡整合：Wallet 三類動作風險不同 → 智能合約 ABI ≠ 安全說明 → ERC-4337 Session Key = AI Agent 安全上鏈基礎 - -AI × Web3 核心原則：AI 解釋 ≠ AI 授權；Simulation + Structured Output + Session Key + Human-in-the-loop + Audit Log - -GitHub 筆記：https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-22.md - - -# 2026-05-21 - - - - - - - - - - - - - - - - - -\-– - -學習日誌 · 2026-05-21（Day 5） - -\## 今日學習主題 - -直播：AI 下鄉計劃｜AI 在 Web3 的應用（Week 1，5/21 20:00） - -複習框架模組，整合前幾天的學習 - -\## AI 在 Web3 的應用｜核心整理 - -**AI × Web3 的核心張力**：用不確定的推理引擎（AI）驅動不可逆的執行系統（Web3）。解法方向：Simulation + Structured Output + Session Key + Human-in-the-loop + Audit Log。 - -**三個應用層次**： - -**Layer 1 輔助層**：AI 幫助理解鏈上資料，不直接執行（交易解釋、合約 ABI 翻譯、Gas 估算建議）。 - -**Layer 2 執行層**：AI 生成操作計劃，人工確認後執行（script 生成 → 人工審查 → 測試網驗證）。 - -**Layer 3 自動化層**：AI 在受限授權範圍內自動執行（Session Key 限時限額，最小權限原則）。 - -**AI 下鄉的核心設計原則**： - -1\. 降低 Web3 操作門檻，但不降低安全標準 - -2\. AI 解釋 ≠ AI 授權；AI 建議 ≠ AI 執行 - -3\. 每一個執行動作都需要可追溯的確認記錄 - -**個人反思**：AI 在 Web3 的真正價值，不是替代人判斷，而是讓人能夠在更多資訊下做出更好的判斷。 - -框架複習小結 - -\- 框架選擇原則：工作流 > 工具能力 > 框架複雜度 - -\- LangChain 適合快速原型，LangGraph 適合需要狀態管理的生產場景 - -\- Hermes 提供穩定的 tool calling 和 JSON 輸出，適合 AI x Web3 執行場景 - -\- OpenAI Agents SDK 提供 handoff/guardrails/tracing 等完整工程化支持 - - -# 2026-05-20 - - - - - - - - - - - - - - - - - - - - -今日學習：Frameworks 模組深讀（LangChain / LangGraph / OpenAI Agents SDK / Hermes）+ Hermes 安裝實作 - -主要收穫： - -- 框架選擇第一原則：先理解工作流，再決定用不用框架。框架是系統邊界的表達，不是智能本身 - -- \- Hermes 讓我重新思考「框架複雜度 vs 模型能力」的取捨——模型本身工具調用夠穩定，就可以少一層框架抽象 - -- \- 安裝 Hermes 心得：建議用虛擬環境隔離依賴；function schema 格式需嚴格對應；prompt 格式要按官方模板 - - -明日計劃：繼續完善 Hermes 測試，準備測試網錢包實作（MetaMask + Sepolia 測試幣） - -GitHub 筆記：https://github.com/IntensiveCoLearning/AI-Web3-School/pull/29 - - -# 2026-05-19 - - - - - - - - - - - - - - - - - - - - - -今日學習：深讀 Handbook Agent 模組（Tool Use / Planning / State / Reflection / Multi-Agent）+ 預習 Hermes Agent 架構 - -GitHub 筆記：[https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-19.md](https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-19.md) - -Agent 核心技術組件： - -Tool Use：讓 Agent 從「會回答」變成「能做事」。工具設計六維度：輸入 schema / 權限範圍 / 是否只讀 / 外部副作用 / 記錄方式 / 人工確認觸發條件。Tool Use 的權限分級比工具能力本身更重要。 - -Planning：模型生成的計劃是候選路線，不是授權。越靠近高風險動作，計劃越需要被系統規則拆開逐步檢查。 - -State：生產系統需要可查詢、可恢復、可審計的外置 State，並記錄環境（鏈 ID、區塊高度）、工具調用結果、確認請求、撤銷事件。 - -Reflection：自我檢查可以提高質量，確定性檢查才能承載風險，不能替代外部驗證 + 人工確認。 - -Multi-Agent：核心判斷問題：多個 Agent 是否真的減少複雜度？ - -Hermes Agent 預習：Skills 可復用高層指令集 / Long-term Memory 跨 session 記憶 / Tracing 可視化執行鏈 / Guardrails 輸入輸出驗證 / Session Key 限時限額授權 - -明日計劃：整合今晚 Hermes 直播筆記，開始測試網錢包實作（MetaMask 安裝 + Sepolia 測試幣） - - -# 2026-05-18 - - - - - - - - - - - - +# 0xroyluo +**GitHub ID:** roy328line +**Telegram:** @roy328328 +## Self-introduction +AI x Web3 School -今日學習：深讀 AI x Web3 School Handbook 模組 A（LLM / Prompt / Context / Agent）+ 模組 B（Wallet / Smart Contract / Account Abstraction） +## Notes -GitHub 筆記：[https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-18.md](https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-18.md) -\## 模組 A｜AI 基礎 + +# 2026-06-06 + +今日學習：Week 4 Hackathon Build Day 1 | AI Security 賽道問題定義 + Demo 架構設計 -\*\*LLM\*\*：概率生成模型，生成的是「概率上合理的輸出」，不是天然可信的事實。Hallucination 在 Web3 執行系統裡會從「答錯」變「做錯」，因此 Simulation 和 Human-in-the-loop 是系統基礎而非選配安全功能。 +核心主題：進入 Week 4 Hackathon Build 階段，聚焦 AI Security 賽道的問題定義與最小可展示 Demo 架構設計。 -\*\*Prompt\*\*：Prompt 是軟約束，不是安全邊界。好 Prompt 四段式：任務目標 → 可用輸入 → 禁止行為 → 輸出格式。真正安全需要代碼層 allowlist + 工具調用前參數校驗 + 高風險動作強制走 human approval。Prompt Injection 是 Agent 場景的核心攻擊面。 +AI Security 賽道問題定義：AI Agent 在 Web3 場景中面臨的安全威脅不同於傳統 Web2。主要攻擊面包含 Prompt Injection（惡意提示注入，讓 Agent 執行非授權操作）、Tool Abuse（濫用工具調用，偽裝合法操作繞過 Pact 限制）、Memory Poisoning（污染 Agent 長期記憶，影響未來決策）、Context Manipulation（篡改上下文讓 Agent 誤判授權邊界）。 -\*\*Context\*\*：Context 五層結構：指令層 → 任務層 → 事實層 → 知識層 → 記憶層。不可信外部內容必須與系統指令層隔離，Memory 不能替代實時授權。 +Defense-in-Depth 防禦架構設計：第一層 Prompt-level 防禦（指令層隔離，不可信輸入不能影響系統指令）、第二層 Tool-level 驗證（工具調用前參數校驗 + allowlist）、第三層 Pact-level 約束（Session Key 限額 + 合約白名單 + 時間窗口）、第四層 On-chain 審計（所有 Agent 操作留下可驗證的鏈上記錄）。 -\*\*Agent\*\*：Agent 是被約束的執行循環，不是自主體。最危險設計是「模糊目標 + 廣泛工具 + 大額資產權限」三者並存。AI x Web3 Agent 八步架構：用戶目標 → 生成計劃 → 只讀工具執行 → 寫入工具 policy 檢查 → Simulation → 用戶確認 → Wallet 執行 → 日誌記錄。 +Hackathon Demo 架構設計：最小可展示閉環——使用者自然語言下達任務 → Agent 解析意圖 → 識別操作需求 → 對照 Pact 邊界自動決策 → 在邊界內執行（無需人工確認）/ 超出邊界時觸發 human approval → 所有決策點輸出可讀審計日誌。核心展示點：Agent 能主動識別 Prompt Injection 並拒絕執行，而不是被動等待用戶發現問題。 -\## 模組 B｜Web3 基礎 +技術棧確認：前端使用 Next.js，Agent 框架使用 LangChain/LangGraph，鏈上交互使用 viem + Cobo CAW SDK，測試網使用 Sepolia。Session Key 生成與管理接入 ERC-4337 智能合約錢包。 -\*\*Wallet\*\*：連接/簽名/交易三類動作風險截然不同，UI 設計必須反映這個差異。助記詞是高危資訊，任何系統要求輸入助記詞都應默認視為危險。 +核心洞察：AI Security 不是「把現有安全措施搬到 AI 上」，而是「重新設計攻擊模型」——AI Agent 的主要漏洞是語義層的歧義和上下文污染，傳統的輸入過濾、防火牆規則在語義攻擊面前幾乎無效。需要從「驗證輸入格式」升級到「驗證操作語義的授權合法性」。 + -\*\*Smart Contract\*\*：ABI 是機器可讀接口，不是安全說明書——告訴你能調用什麼，不保證調用是否安全。一次完整鏈上調用是 9 步流程（前端 → ABI 編碼 → 錢包確認 → RPC 廣播 → 驗證者打包 → EVM 執行 → Event → 前端回執 → 索引器更新）。 +# 2026-06-05 + +今日學習：Week 3 直播 | AI Agent 時代，重新審視區塊鏈這項技術選擇 & AI Agent 深度參與下的區塊鏈應用開發實戰 -\*\*Account Abstraction\*\*：ERC-4337 讓帳戶可編程。Session Key 是 AI Agent 安全上鏈的關鍵基礎——比喻：不是「給 AI 一把主鑰匙」，而是「給 AI 一張限時限額的員工門禁卡」（最小權限原則）。 -\## 核心發想 +核心主題：從 AI Agent 視角重新審視區塊鏈的技術價值，以及 AI Agent 深度參與區塊鏈應用開發的實戰方法。 -AI 不確定性（幻覺/注入/推理漂移）× Web3 不可逆性（交易上鏈不能撤回）= 核心設計張力：需要用不可靠的推理引擎驅動不可逆的執行系統。 -解法：Simulation + Structured Output + Session Key + Human-in-the-loop + Audit Log +重新審視區塊鏈的三個問題框架：AI Agent 時代，評估一條鏈/技術棧不再是「TPS 多少、生態多大」，而是「這條鏈能不能讓 Agent 安全執行、身份可驗證、行為可審計、支付可自主」。四個關鍵判斷維度：鏈上 Agent 身份（DID/ENS）、可程式化授權（Session Key/Account Abstraction）、原生支付（穩定幣/ERC-20 自動結算）、行為審計（on-chain log + attestation）。 -\## 明日計劃 -跟進 5/19 直播：AI Agent 入門 — Hermes 從 0 到 1，並開始測試網錢包實作 - - +AI Agent 深度參與區塊鏈開發實戰：Hackathon 週期的技術選型邏輯——優先選有完整 SDK、有 simulation、有明確 escrow 機制的技術棧。Agent 參與的鏈上應用需要「可組合性」：Session Key + Policy + Pact 可以組合，但每個模組必須獨立可測試。Demo 設計原則：能端到端跑通比功能完整更重要，優先展示「Agent 自主決策 → 觸發 Pact 授權 → x402 支付 → 鏈上收據」這條主線閉環。 From 5aa01cd9de0a2c4084cd7b869d73d5605690b2f0 Mon Sep 17 00:00:00 2001 From: roy328line Date: Sun, 7 Jun 2026 21:20:59 +0800 Subject: [PATCH 3/9] Add 2026-06-07 learning notes: Week 4 Hackathon Build Day 2 + AI Privacy Added daily check-in notes for June 6 and June 7, detailing AI Security and Privacy concepts, Hackathon progress, and defense architecture design. --- notes/roy328line.md | 46 ++++++++++++++++++++++++++++----------------- 1 file changed, 29 insertions(+), 17 deletions(-) diff --git a/notes/roy328line.md b/notes/roy328line.md index a0a96f42d..e6c4df419 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -3,51 +3,63 @@ timezone: UTC+8 --- + + # 0xroyluo + + **GitHub ID:** roy328line + + **Telegram:** @roy328328 + + ## Self-introduction + + AI x Web3 School + + ## Notes - -# 2026-06-06 - -今日學習：Week 4 Hackathon Build Day 1 | AI Security 賽道問題定義 + Demo 架構設計 -核心主題：進入 Week 4 Hackathon Build 階段，聚焦 AI Security 賽道的問題定義與最小可展示 Demo 架構設計。 -AI Security 賽道問題定義：AI Agent 在 Web3 場景中面臨的安全威脅不同於傳統 Web2。主要攻擊面包含 Prompt Injection（惡意提示注入，讓 Agent 執行非授權操作）、Tool Abuse（濫用工具調用，偽裝合法操作繞過 Pact 限制）、Memory Poisoning（污染 Agent 長期記憶，影響未來決策）、Context Manipulation（篡改上下文讓 Agent 誤判授權邊界）。 + +# 2026-06-07 + +今日學習：Week 4 Hackathon Build Day 2 | AI Privacy 核心概念 + Hackathon Demo 實作進展 -Defense-in-Depth 防禦架構設計：第一層 Prompt-level 防禦（指令層隔離，不可信輸入不能影響系統指令）、第二層 Tool-level 驗證（工具調用前參數校驗 + allowlist）、第三層 Pact-level 約束（Session Key 限額 + 合約白名單 + 時間窗口）、第四層 On-chain 審計（所有 Agent 操作留下可驗證的鏈上記錄）。 +核心主題：深入學習 AI Privacy 在 Web3 場景中的關鍵問題，並推進 AI Security Hackathon Demo 的實際代碼實作。 -Hackathon Demo 架構設計：最小可展示閉環——使用者自然語言下達任務 → Agent 解析意圖 → 識別操作需求 → 對照 Pact 邊界自動決策 → 在邊界內執行（無需人工確認）/ 超出邊界時觸發 human approval → 所有決策點輸出可讀審計日誌。核心展示點：Agent 能主動識別 Prompt Injection 並拒絕執行，而不是被動等待用戶發現問題。 +AI Privacy 核心概念：AI Privacy 在 Web3 場景中有三個不同於 Web2 的特殊挑戰。第一是鏈上身份去匿名化風險——鏈上地址、交易歷史都是公開數據，結合 AI 的語義推斷能力可以輕易識別真實身份；隱私保護需要從「匿名化地址」升級到「零知識身份證明」。第二是 LLM 推斷洩漏——用戶向 Agent 描述意圖時，措辭本身可能洩漏持倉、策略、風險偏好等敏感信息；需要在 Prompt 設計層面建立「最小信息披露」原則。第三是 Memory Persistence 隱私邊界——Agent 的長期記憶跨會話存儲，如何讓用戶控制哪些信息可以被記憶、哪些在會話結束後自動清除，是 Web3 Agent 必須解決的基礎問題。 -技術棧確認：前端使用 Next.js，Agent 框架使用 LangChain/LangGraph，鏈上交互使用 viem + Cobo CAW SDK，測試網使用 Sepolia。Session Key 生成與管理接入 ERC-4337 智能合約錢包。 +Zero-Knowledge Proof 在 AI Privacy 中的應用：ZK Proof 可以讓 Agent 在不洩漏具體數據的前提下證明「用戶滿足某個條件」（如 KYC 已完成、持有超過閾值的資產）。ZK + Agent 的組合邏輯：用戶提交 ZK Proof → Agent 驗證 Proof 有效性 → Agent 根據授權條件決策 → 整個過程用戶真實數據不上鏈。 -核心洞察：AI Security 不是「把現有安全措施搬到 AI 上」，而是「重新設計攻擊模型」——AI Agent 的主要漏洞是語義層的歧義和上下文污染，傳統的輸入過濾、防火牆規則在語義攻擊面前幾乎無效。需要從「驗證輸入格式」升級到「驗證操作語義的授權合法性」。 - +Hackathon Demo 實作進展：今日開始搭建 AI Security Demo 的核心模組。完成 Prompt Injection 檢測器的基礎版本——通過比對指令層和輸入層的語義差異，識別試圖篡改系統指令的惡意輸入。Tool Call 白名單驗證邏輯完成初稿：每個工具調用在執行前必須通過三層驗證（Pact 範圍檢查 → 參數格式驗證 → 金額上限驗證）。審計日誌模組設計完成，所有決策點（通過/拒絕/escalate）記錄到結構化 JSON 格式，計畫接入鏈上 attestation。 -# 2026-06-05 - -今日學習：Week 3 直播 | AI Agent 時代，重新審視區塊鏈這項技術選擇 & AI Agent 深度參與下的區塊鏈應用開發實戰 +核心洞察：AI Privacy 和 AI Security 不是兩個獨立問題，而是同一問題的兩面——Security 是「防止 Agent 被攻擊者控制執行惡意操作」，Privacy 是「防止 Agent 洩漏用戶不願公開的信息」。兩者的底層防禦機制高度重疊：最小權限原則、指令層隔離、輸出過濾、可審計記錄。 + + +# 2026-06-06 + +今日學習：Week 4 Hackathon Build Day 1 | AI Security 賽道問題定義 + Demo 架構設計 -核心主題：從 AI Agent 視角重新審視區塊鏈的技術價值，以及 AI Agent 深度參與區塊鏈應用開發的實戰方法。 +核心主題：進入 Week 4 Hackathon Build 階段，聚焦 AI Security 賽道的問題定義與最小可展示 Demo 架構設計。 -重新審視區塊鏈的三個問題框架：AI Agent 時代，評估一條鏈/技術棧不再是「TPS 多少、生態多大」，而是「這條鏈能不能讓 Agent 安全執行、身份可驗證、行為可審計、支付可自主」。四個關鍵判斷維度：鏈上 Agent 身份（DID/ENS）、可程式化授權（Session Key/Account Abstraction）、原生支付（穩定幣/ERC-20 自動結算）、行為審計（on-chain log + attestation）。 +AI Security 賽道問題定義：AI Agent 在 Web3 場景中面臨的安全威脅不同於傳統 Web2。主要攻擊面包含 Prompt Injection（惡意提示注入，讓 Agent 執行非授權操作）、Tool Abuse（濫用工具調用，偽裝合法操作繞過 Pact 限制）、Memory Poisoning（污染 Agent 長期記憶，影響未來決策）、Context Manipulation（篡改上下文讓 Agent 誤判授權邊界）。 -AI Agent 深度參與區塊鏈開發實戰：Hackathon 週期的技術選型邏輯——優先選有完整 SDK、有 simulation、有明確 escrow 機制的技術棧。Agent 參與的鏈上應用需要「可組合性」：Session Key + Policy + Pact 可以組合，但每個模組必須獨立可測試。Demo 設計原則：能端到端跑通比功能完整更重要，優先展示「Agent 自主決策 → 觸發 Pact 授權 → x402 支付 → 鏈上收據」這條主線閉環。 +Defense-in-Depth 防禦架構設計：第一層 Prompt-level 防禦（指令層隔離，不可信輸入不能影響系統指令）、第二層 Tool-level 驗證（工具調用前參數校驗 + allowlist）、第三層 Pact-level 約束（Session Key 限額 + 合約白名單 + 時間窗口）、第四層 On-chain 審計（所有 Agent 操作留下可驗證的鏈上記錄）。 From e9fe371cb1288b2e808bac3e64ea702319260c9c Mon Sep 17 00:00:00 2001 From: roy328line Date: Mon, 8 Jun 2026 20:37:13 +0800 Subject: [PATCH 4/9] Add 2026-06-08 learning notes: Scope Freeze + Co-learning + Moven Added daily check-in notes for June 8, 2026, detailing Hackathon progress, MVP structure, and insights from Co-learning and Moven sessions. --- notes/roy328line.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/notes/roy328line.md b/notes/roy328line.md index e6c4df419..26253d954 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -36,6 +36,23 @@ AI x Web3 School +# 2026-06-08 + +今日學習：Week 4 Hackathon Build Day 3 | Scope Freeze + MVP 主流程推進 + Co-learning & Moven 分享會 + +核心主題：Week 4 第三天，進行 Hackathon 項目 Scope Freeze，鎖定 AI Security Demo 最小可驗證主流程，並參加 Co-learning 答疑與 Moven 支付場景分享會。 + +Scope Freeze 決策：根據 Week 4 最低完成路徑要求，將 AI Security Demo 範圍收斂為一條核心鏈路：惡意 Prompt Injection 輸入 → 多層防禦攔截 → Pact 範圍驗證 → 審計日誌記錄 → 鏈上 attestation 存證。確認 Must-have（Prompt Injection 檢測 + Tool Call 白名單 + 審計 JSON）、Should-have（鏈上 attestation 接入）、Nice-to-have（前端 Dashboard 展示）、Cut/Mock（完整 DeFi 場景模擬）。 + +MVP 主流程架構確認：整體流程為「用戶輸入 → 指令層隔離檢查 → 工具調用白名單驗證 → Pact 範圍確認 → 執行或拒絕 → 審計日誌輸出」。關鍵驗證指標：Prompt Injection 攔截率（測試 10 種攻擊向量）、合規工具調用通過率、完整審計記錄可追溯性。 + +Co-learning 答疑重點：本週 Co-learning session 重點圍繞 Hackathon 衝刺答疑，討論了 AI Security 賽道中「攻擊模擬 vs 防禦展示」的 Demo 敘事策略——評委更關注防禦機制的可解釋性而非攻擊的複雜性。建議 Demo 故事線：展示攻擊 → 展示被攔截的防禦 → 展示審計記錄 → 解釋為什麼鏈上記錄不可篡改。 + +Moven 分享會學習筆記：Moven 在支付場景的探索和思考分享了 AI Agent 如何在不需要用戶每次確認的情況下完成微支付閉環。核心洞察是「預算授權 + 條件執行」模式——用戶提前設定支付條件（金額上限、收款方白名單、有效期），Agent 在條件範圍內自動執行，超出範圍必須暫停請求人工確認。這與 AI Security 賽道的 Pact 機制高度相似，兩者共同構成 Agentic Commerce 的基礎設施層。 + +明日計畫：完成 MVP 核心代碼實作（Prompt Injection 檢測器 + Tool Call Validator），整理 README 初稿，確保驗證材料（測試日誌 + 攔截記錄）可復現。 + + # 2026-06-07 今日學習：Week 4 Hackathon Build Day 2 | AI Privacy 核心概念 + Hackathon Demo 實作進展 From af8fb0418a927f198bfc8426f98dc12e82fd7e18 Mon Sep 17 00:00:00 2001 From: roy328line Date: Tue, 9 Jun 2026 16:06:55 +0800 Subject: [PATCH 5/9] Add 2026-06-09 learning notes: MVP Code Implementation + Verifiable AI Added daily check-in entry for June 9, 2026, detailing MVP core code implementation, README draft, and audit log features. --- notes/roy328line.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/notes/roy328line.md b/notes/roy328line.md index 26253d954..4217ec651 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -36,6 +36,30 @@ AI x Web3 School +# 2026-06-09 + +今日學習：Week 4 Hackathon Build Day 4 | MVP 核心代碼實作完成 + README 初稿 + Demo 驗證材料整理 + + +核心主題：Week 4 第四天，依照昨日計畫完成 AI Security Demo 的 MVP 核心模組代碼實作，整理 README 初稿與驗證材料，為 Demo 提交做準備。 + + +MVP 核心代碼實作成果：今日完成兩個核心模組的可運行版本。Prompt Injection 檢測器（`prompt_guard.py`）測試覆蓋 10 種攻擊向量，包含角色扮演注入（「忽略所有之前的指令」）、系統指令覆寫、越獄模式提示等，攔截率達到 100%（測試集）。Tool Call Validator（`tool_validator.py`）實作三層驗證邏輯：Pact 範圍白名單檢查 → 參數格式校驗 → 金額上限保護，合規工具調用通過率 100%，非法調用攔截率 100%。 + + +審計日誌與鏈上 Attestation：審計日誌模組完成，所有決策點（ALLOW / DENY / ESCALATE）輸出結構化 JSON 格式，包含時間戳、操作類型、輸入摘要、決策結果與原因。鏈上 attestation 採用 Base Sepolia testnet，通過 EAS（Ethereum Attestation Service）記錄每次 DENY 事件的哈希摘要，確保審計記錄不可篡改。今日完成第一筆測試 attestation 寫入，transaction hash 已記錄在 README。 + + +README 初稿整理：完成 README 主要結構，包含項目背景（AI Agent 在 Web3 場景的安全挑戰）、核心架構圖（Defense-in-Depth 四層）、快速運行指南（`pip install + python demo.py`）、測試結果摘要（攔截率 / 通過率）、鏈上驗證連結（EAS Explorer）。Demo 故事線確認為：攻擊演示 → 防禦攔截視覺化 → 審計日誌展示 → 鏈上記錄查詢。 + + +Verifiable AI 概念深化：今日整理 Demo 時深入思考 Verifiable AI 的核心問題——如何讓 AI 的決策過程和結果可以被外部驗證，而不只是「相信模型說的話」。鏈上 attestation 是目前 Verifiable AI 最直接的落地路徑：對每個關鍵決策點（尤其是拒絕操作）留下哈希摘要上鏈，可以事後審計任何 Agent 操作是否符合預設規則。這個模式對 DeFi 場景的 Agent 尤其重要——用戶可以驗證 Agent 是否真的按照 Pact 規定行動。 + + +明日計畫：完善 Demo 視覺化介面（CLI 輸出格式優化），準備 Hackathon 提交材料（repo 清理 + demo video 錄製準備），複習 Governance AI 主題以補全學習地圖。 + + + # 2026-06-08 今日學習：Week 4 Hackathon Build Day 3 | Scope Freeze + MVP 主流程推進 + Co-learning & Moven 分享會 From 06a1f117b5393a937661c85f817cbb693178c085 Mon Sep 17 00:00:00 2001 From: roy328line Date: Wed, 10 Jun 2026 17:55:55 +0800 Subject: [PATCH 6/9] Add 2026-06-10 learning notes: Governance AI + Hackathon Demo Final Prep Added daily check-in for June 10, 2026, covering Governance AI concepts and Hackathon demo preparations. --- notes/roy328line.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/notes/roy328line.md b/notes/roy328line.md index 4217ec651..7bb10b110 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -36,6 +36,23 @@ AI x Web3 School +# 2026-06-10 + +今日學習：Week 4 Hackathon Build Day 5 | Governance AI 概念補全 + Hackathon Demo 最終整備 + +核心主題：Week 4 第五天，補全學習地圖中 Governance AI 主題，並完成 Hackathon Demo 最終整備，包括 CLI 視覺化優化、Demo 影片腳本準備與提交材料清單確認。 + +Governance AI 核心概念：Governance AI 指的是將 AI 應用於 DAO 治理、公共決策與協議升級流程中的一系列工具和機制。核心問題不是「AI 能否做決策」，而是「如何讓 AI 在治理流程中扮演輔助角色，同時保持決策的透明度與可追責性」。主要應用場景包括：提案摘要自動生成（讓持幣者快速理解長篇提案）、歷史投票模式分析（識別鯨魚行為、選民倦怠、利益衝突模式）、治理參與度提升（個性化通知、投票提醒、影響評估說明），以及爭議解決輔助（基於歷史判例提供建議，但最終決策保留給人類）。 + +Governance AI 的風險與邊界：AI 輔助治理最大的風險是「AI 建議固化為社群共識」——當 AI 的摘要和建議被大多數人直接採用，反而可能造成意見同質化，削弱去中心化治理的多元價值。解法是將 AI 定位為「資訊工具」而非「決策推薦系統」：呈現多元觀點摘要而非單一結論，公開訓練數據與提示詞以確保可審計性，以及讓用戶有能力覆蓋和質疑 AI 的摘要邏輯。另一個風險是治理操控——精心設計的提案可以欺騙 AI 摘要器，讓惡意提案看起來無害，因此 Governance AI 系統本身也需要 AI Security 的防護機制。 + +Hackathon Demo CLI 輸出優化：完成 CLI 輸出格式的視覺化調整，採用顏色編碼區分決策結果（綠色 ALLOW、紅色 DENY、黃色 ESCALATE），並加入進度指示器顯示每個驗證層的通過狀態。優化後的 Demo 輸出更直觀地展示了 Defense-in-Depth 四層架構的實際攔截過程，有助於評委在演示時快速理解系統邏輯。 + +Hackathon 提交材料清單確認：確認最終提交材料包括：可運行的 Demo 代碼（prompt_guard.py + tool_validator.py + audit_logger.py）、完整測試套件（10 種 Prompt Injection 攻擊向量測試 + 工具調用合規測試）、README（背景 + 架構圖 + 快速運行指南 + 測試結果）、鏈上 attestation 記錄（Base Sepolia EAS Explorer 連結）、Demo 影片腳本草稿（攻擊演示 → 防禦攔截 → 審計日誌 → 鏈上驗證）。 + +Week 4 學習地圖回顧：整個 Week 4 的學習路徑從 AI Security 問題定義出發，經過 Defense-in-Depth 架構設計、AI Privacy 補充、MVP 代碼實作，到今日的 Governance AI 概念補全，完整覆蓋了 Handbook 中 AI × Web3 Bridge 部分的核心交叉問題。AI Security + AI Privacy + Governance AI 三者共同構成 AI Agent 在 Web3 場景中可信運行的基礎設施：Security 確保 Agent 不被濫用、Privacy 確保用戶數據受保護、Governance AI 確保 Agent 參與的決策過程可透明審計。 + + # 2026-06-09 今日學習：Week 4 Hackathon Build Day 4 | MVP 核心代碼實作完成 + README 初稿 + Demo 驗證材料整理 From aa04c0f5af255f3df1fa88b990f9485ee0b12f11 Mon Sep 17 00:00:00 2001 From: roy328line Date: Thu, 11 Jun 2026 21:51:10 +0800 Subject: [PATCH 7/9] Add 2026-06-11 learning notes: Hackathon Demo reflection + Dev Tooling exploration + learning map review Added daily check-in for June 11, 2026, detailing learning outcomes, reflections on Hackathon Demo, exploration of Dev Tooling, and a comprehensive review of the learning map. --- notes/roy328line.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/notes/roy328line.md b/notes/roy328line.md index 7bb10b110..5bdd15f14 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -36,6 +36,21 @@ AI x Web3 School +# 2026-06-11 + +今日學習：Week 5 學習成果整合 | Hackathon Demo 反思 + Dev Tooling 探索 + 學習地圖完整回顧 + +核心主題：Hackathon 提交後的第一天，聚焦三件事：反思 AI Security Demo 的完成情況與可改進空間、探索 Dev Tooling 賽道的實踐方向，以及對整個 AI × Web3 學習地圖進行完整回顧，確認知識點的連接與缺口。 + +Hackathon Demo 反思：AI Security Demo 完成了 Defense-in-Depth 四層架構的最小可驗證原型，覆蓋 Prompt Injection 檢測、Tool Call 白名單驗證、Pact 範圍約束與鏈上 attestation 審計。反思三個可改進點：第一，攻擊向量測試集過於簡單，真實攻擊的語義多樣性遠超測試集；第二，鏈上 attestation 目前只記錄 DENY 事件，未來應擴展到所有決策點的摘要；第三，CLI 視覺化雖然直觀，但缺少 API 介面讓其他系統能整合這個安全層。這三個方向是 Demo 演進為真實系統的核心路徑。 + +Dev Tooling 賽道探索：Dev Tooling 指面向合約理解、測試、文檔、代碼審查和開發工作流的 AI 輔助工具。這個賽道和 AI Security 的交叉點是：AI 輔助的代碼審查工具本身也需要防止 Prompt Injection——開發者可能在代碼注釋中嵌入惡意指令，讓 AI 審查工具產生錯誤的安全評估。這是 AI Security 在 Dev Tooling 場景的具體應用，也是 Hackathon 項目後續演進的一個自然方向：從「執行時安全防護」擴展到「開發時安全審查」。 + +學習地圖完整回顧：回顧 AI × Web3 School 四週學習路徑的知識結構。AI 基礎部分涵蓋了 LLM 能力邊界、Prompt 設計、Context 管理、RAG 架構、Agent 工作流、Frameworks 編排層與 MCP 協議。Web3 基礎部分涵蓋了 Network 環境、Cryptography 基礎、Wallet 身份入口、Smart Contract 鏈上規則、Account Abstraction 智能帳戶、DeFi 協議結構、Oracle 數據橋接與 Indexing 數據層。AI × Web3 Bridge 部分涵蓋了 Chain-aware Context、Web3 Tool Use、Agent Workflow、Agent Wallet、Machine Payment、Settlement & Escrow、Agent Identity、Agent Trust、Verifiable AI、AI Security、AI Privacy 與 Governance AI。前沿探索部分完成了 AI Security 賽道的 Hackathon Demo，並在今日補充了 Dev Tooling 方向的初步探索。 + +下一步計畫：在剩餘三天（6/12-6/14）繼續完善 Hackathon Demo 的說明文件，補充 Dev Tooling 場景下 AI Security 的具體應用案例，並整理 WCB 個人頁面的學習記錄與技能標籤。 + + # 2026-06-10 今日學習：Week 4 Hackathon Build Day 5 | Governance AI 概念補全 + Hackathon Demo 最終整備 From 79007fe13795f27088547bf10c1903faff28124b Mon Sep 17 00:00:00 2001 From: roy328line Date: Fri, 12 Jun 2026 22:39:11 +0800 Subject: [PATCH 8/9] Add 2026-06-12 learning notes: Week 4 Final Sprint + Hackathon Submission Q&A + Demo Day Prep by roy328line Added daily check-in notes for June 12, 2026, detailing learning outcomes from Week 4, Hackathon submission preparations, and meeting discussions. --- notes/roy328line.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/notes/roy328line.md b/notes/roy328line.md index 5bdd15f14..743b9c0a3 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -36,6 +36,21 @@ AI x Web3 School +# 2026-06-12 + +今日學習：Week 4 最終衝刺 | Hackathon 最終提交答疑 + 例會 + Final Submission Pack 整備 + +核心主題：Week 4 最後衝刺日（6/12），參加 Co-learning Hackathon 最終提交答疑和 Week 4 例會，完成 Final Submission Pack 的最後整備，確認 Demo Day 準備就緒。 + +Co-learning 最終提交答疑重點：本次 Co-learning 聚焦 Hackathon 最終提交的技術細節和常見問題。核心討論圍繞三個問題：Demo 跑通標準（評委關注的是可觀察的鏈路，而非功能完整性）、驗證材料標準（鏈上 tx hash、agent trace 日誌、截圖三種驗證方式的優先順序）、README 呈現方式（Why AI + Why Web3 兩個問題必須有獨立段落，不能混淆在技術描述中）。學習到的關鍵點：Demo 敘事的核心是「問題 → 為什麼舊方法不夠 → 解法 → 可驗證證明」，而不是功能列表。 + +Final Submission Pack 最終整備：確認提交材料完整性。GitHub repo 結構確認（README + demos/ + notes/ + logs/ 目錄齊全）；Demo 可運行性確認（prompt_guard.py + tool_validator.py + audit_logger.py 三個核心模組在 clean environment 下可一鍵運行）；鏈上驗證材料確認（Base Sepolia testnet EAS attestation 記錄，tx hash 和 EAS Explorer 連結均寫入 README）；Demo 影片腳本確認（攻擊演示 30 秒 → 防禦攔截 30 秒 → 審計日誌 20 秒 → 鏈上驗證 20 秒，總時長 2 分鐘以內）。 + +例會學習筆記：Week 4 例會討論了三個主題。第一是 Hackathon 項目總覽與 Demo Day 格式說明：Demo Day 在 6/14 舉行，每個項目 3 分鐘展示 + 2 分鐘 Q&A，評委關注可驗證性和 AI × Web3 結合點的清晰度。第二是優秀項目分享：分享了幾個完成度高的項目，共同特點是「問題清晰 + 主流程跑通 + 驗證材料充分」，而不是功能多。第三是下週課程預告：Week 5 聚焦整體學習成果回顧和職涯路徑探索，完整學習地圖的最後一塊拼圖。 + +Week 4 整體回顧：回顧整個 Week 4 的學習旅程——從 Scope Freeze 鎖定 AI Security 主流程、到 MVP 核心代碼實作、到 README 與驗證材料整備、到今日的最終提交確認。最重要的學習不是技術本身，而是「如何在有限時間內做出可驗證的最小有意義成果」：先凍結範圍、再執行主流程、再收集驗證材料、最後包裝敘事。這個方法論適用於 Hackathon，也適用於任何 AI × Web3 的早期產品驗證場景。 + + # 2026-06-11 今日學習：Week 5 學習成果整合 | Hackathon Demo 反思 + Dev Tooling 探索 + 學習地圖完整回顧 From 2df71e91a841666708466227d49a6555b52806a5 Mon Sep 17 00:00:00 2001 From: roy328line Date: Sun, 14 Jun 2026 19:38:03 +0800 Subject: [PATCH 9/9] Add 2026-06-13 and 2026-06-14 learning notes: Demo Day prep + Demo Day showcase Added daily check-in entries for June 12, 13, and 14, 2026, detailing learning outcomes and project preparations for Demo Day. --- notes/roy328line.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/notes/roy328line.md b/notes/roy328line.md index 743b9c0a3..293fa4825 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -36,6 +36,37 @@ AI x Web3 School +# 2026-06-14 + +今日學習：Demo Day | Hackathon 項目展示 + 四週學習總回顧 + +核心主題：AI × Web3 School 最終日——Demo Day 正式展示 AI Security 項目，並完成整個四週課程的學習回顧與個人成長總結。 + +Demo Day 展示準備與執行：今日下午1:00舉行 Demo Day，每個 Hackathon 項目進行 3 分鐘展示 + 2 分鐘 Q&A。我的 AI Security Demo 聚焦於「AI Agent 在 Web3 執行場景中的 Defense-in-Depth 安全架構」，主要展示四層防禦機制的實際攔截效果。Demo 故事線依照計畫執行：首先展示無防禦狀態下 Prompt Injection 攻擊如何讓 Agent 執行非授權的 transfer() 調用；接著展示部署防禦後，相同攻擊被指令層隔離檢查攔截並記錄到審計日誌；最後展示 Base Sepolia EAS Explorer 上的不可篡改鏈上記錄，證明整個防禦決策過程可被外部驗證。 + +Q&A 重點問答：評委提問集中在三個方向——攻擊向量的覆蓋完整性（說明當前 10 種向量是最常見類型，真實部署需要持續更新測試集）、鏈上 attestation 的 gas 成本（說明 Base Sepolia 成本極低，正式部署可選擇批次上鏈降低成本）、與現有 Web2 安全工具的差異（說明 Web3 場景中 Agent 操作不可逆性更高，因此需要在執行層前置攔截而非事後修復）。 + +其他項目觀摩與學習：觀摩了其他學員的 Demo 展示，印象最深的三個方向是：基於 Cobo CAW 的 Agent Commerce 自主支付閉環（展示了 Pact 機制在真實 DeFi 場景的預算控制能力）、GLM-5.1 驅動的合約代碼審查助手（將 AI Security 應用於開發時審查而非執行時防禦，是很好的方向補充）、以及多簽治理輔助工具（讓 AI 生成提案摘要和行動項，保留最終決策給人類）。 + +四週學習成果總回顧：回顧整個 AI × Web3 School 的學習旅程。Week 1 建立了 LLM 能力邊界、Agent Workflow 和 Web3 基礎的共同語言；Week 2 深入研究 AI × Web3 六大交叉方向並選定 AI Security 主線；Week 3 完成從方向研究到 Hackathon 題目收斂的轉換；Week 4 完成從架構設計到可運行 Demo 的全程。最核心的學習是一個判斷框架：哪些 Agent 動作可以自動化執行，哪些必須保留人工確認，以及如何通過可驗證記錄讓整個執行過程具備外部可審計性。 + + +# 2026-06-13 + +今日學習：Demo Day 前最終準備 | 提交包完善 + Demo 演練 + 跨方向學習整合 + +核心主題：Hackathon Demo Day 前最後一天，聚焦三件事：完善最終提交材料包、進行 Demo 完整演練，以及整合其他賽道的學習，補全 AI × Web3 全景視野。 + +最終提交包完善：今日完成 Final Submission Pack 所有材料的最後確認與補充。GitHub Repo 完整性確認（README 包含 Project Overview、Problem、Why AI + Why Web3 雙問題、Demo 截圖、Validation 材料、Risks 與 Next Steps）；核心代碼三個模組（prompt_guard.py、tool_validator.py、audit_logger.py）在 clean environment 下完成最終一鍵運行測試；鏈上驗證材料確認（Base Sepolia testnet EAS attestation 的 tx hash 和 EAS Explorer 連結均寫入 README）；Demo 影片腳本最終版（攻擊演示 30 秒 → 防禦攔截 30 秒 → 審計日誌 20 秒 → 鏈上驗證 20 秒）。 + +Demo 完整演練與問題排查：進行兩輪完整 Demo 演練。第一輪發現 CLI 輸出顏色在截圖中對比度不夠明顯，調整了 DENY 事件的紅色高亮方式；第二輪發現 EAS Explorer 頁面載入速度較慢，在 Demo 腳本中加入替代方案（預先截圖 + 提前開啟 Tab），避免 Demo 現場網路問題影響展示效果。演練過程也強化了對自己項目邊界的清晰理解——哪些攻擊向量已被覆蓋、哪些尚未覆蓋、哪些是 Mock 而非真實調用。 + +Cobo CAW Agentic Commerce 深度研究：補充研究 Cobo CAW 的 Pact 機制在 Agentic Commerce 場景的具體實現。Pact 的核心設計邏輯是「任務粒度的臨時授權」——每個 Agent 執行任務都需要用戶預先批准一個包含預算、合約白名單、操作類型和時間窗口的 Pact；任務完成後 Pact 自動失效，Agent 無法保留持久性的廣泛權限。這個設計和 AI Security 的 Scope Freeze 原則高度相似：越具體的授權邊界，越難被 Prompt Injection 或 Tool Abuse 繞過。 + +Agent Identity 與 ERC-8004 補充學習：補充學習 ERC-8004 的 agent trust 框架，理解 agent profile、capability declaration、job、escrow 和 evaluator 的協議層設計。Agent Identity 方向最有意思的問題不是「如何給 Agent 起名字」，而是「如何讓調用方在執行任務前驗證 Agent 的能力邊界、歷史記錄和失敗責任歸屬」。一個可信的 Agent Identity 系統必須包含鏈上可驗證的執行記錄，而不只是靜態的能力聲明。 + + + # 2026-06-12 今日學習：Week 4 最終衝刺 | Hackathon 最終提交答疑 + 例會 + Final Submission Pack 整備