最近老有朋友問我“Agent 和普通的大模型 API 封裝到底差在哪”我做這類應用的時間不算短過去一年里最大的感受就是區別不在于你調了幾次模型而在于你有沒有把“能力”做出“人感”來。這里說的“人感”落到工程上就是三件事Skill 有沒有記憶、有沒有角色、有沒有主動性。很多剛接觸 AI Agent 的人以為 Skill 就是一段可以被大模型調用的函數給它一個名字、一段描述、一個執行邏輯完事。但當你把 Skill 做成這樣你得到的只是一個工具不是一個能幫忙做事的智能體。今天這篇文章我就拿一個真實能跑的例子——“任務推進助手”Skill手把手把它寫出來。這個 Skill 會記住你的偏好、給自己設定角色還會在合適的時機主動提醒你該做的事情。文章面向兩類人一類是剛會調用大模型 API、想學 Agent 開發的新手另一類是已經在做 Agent 框架、但一直覺得“工具不夠聰明”的開發者。本文不要求你有很深的機器學習基礎只要你有 Python 基礎能跑通 OpenAI 兼容接口就基本能跟上。代碼偏工程向我會把所有關鍵選擇的“為什么”都說清楚。1. 動手之前先拆解 Skill 的三層能力1.1 Skill 和普通函數的邊界在哪里先說個你可能踩過的坑很多 Agent 框架只是把 Function Calling 包裝成了 Skill。底層邏輯是這樣框架把工具的 JSON Schema 喂給大模型模型覺得該調工具時就返回一個 tool call然后 Python 執行完再喂回去。這套機制本身沒問題但請你想一個問題函數是無狀態的Skill 如果也只是無狀態的那它充其量是“工具箱里的扳手”而不是“能獨當一面的幫手”。我理解中的 Skill至少要包含三部分元信息name、description、version、調用條件。這決定了大模型在什么場景下會選中它。執行邏輯真正做事的那段代碼、提示詞、工具調用鏈。生命周期它在被調用前要準備什么調用后要記住什么運行完之后會不會主動觸發其他動作。把這三部分補齊Skill 才從一個“函數”變成一種“帶狀態的自主能力”。我們下面要寫的任務推進助手就會同時擁有這三個層面。為什么不能直接用 Function Calling 解決因為 Function Calling 的天然邊界是“等用戶問”。它只能被動響應而一個會做任務管理的 Skill必須在用戶沒有明確說“幫我記任務”的時候也知道把關鍵信息沉淀到記憶里在用戶沒有問“今天有什么待辦”的時候也能根據時間戳和上下文判斷要不要主動提醒。這已經超出了普通函數的職責范圍。1.2 記憶、角色、主動性能力層級逐層遞進這三樣東西不是并列關系而是遞進關系。記憶是最底層。沒有記憶Agent 每一次對話都是“陌生人”。你在星期二告訴它“這個項目周五要交第一版”到星期四你再問它“我最近忙什么”它應該能回憶起這個 deadline。這里的記憶分為兩層短期記憶是當前會話的上下文長期記憶是跨會話沉淀下來的用戶偏好和事實。角色在記憶之上。角色本質上是一套行為約束和表達風格。同樣一句話讓同一個模型扮演“嚴肅項目經理”和“親切的同事”寫出來的任務提醒完全不一樣。有了角色Skill 的答案才穩定而不是每次跟著 prompt 隨機漂移。主動性在最上層。主動性不是讓模型像鬧鐘一樣每天定時亂叫而是讓它擁有“判斷什么時候該開口”的能力。一個任務推進助手如果所有提醒都等用戶來問那它根本不叫助手。真正的主動觸發點在工程上是事件驅動的用戶新提了一個任務、某個任務的截止時間快到了、用戶連續兩天沒更新狀態……這些事件到達時Skill 要能自動決定要不要打擾用戶。1.3 本項目落地形態與功能拆解我把示例 Skill 命名為TaskFollowerSkill中文名叫“任務推進助手”。它的能力拆解如下角色一名話不多、但邏輯嚴謹的項目推進助理。它不替用戶做決定只負責幫用戶把任務拆成可執行步驟并追蹤風險。記憶記錄用戶的核心偏好比如“每天提醒不要超過三次”“重要任務要排序”記錄任務狀態和截止時間。主動性當檢測到有任務在今天到期或者已經逾期時Skill 會返回一條非用戶主動詢問的提醒文本交給 Agent 主循環推送出去。擴展點為了不把事情做復雜這個版本我不集成日歷、郵件等外部系統而是把這些都抽象成“外部事件輸入”你在自己的項目里替換成真實接口即可。下面我們從零開始把這段代碼寫出來。2. 環境準備與 Skill 骨架先跑通最小閉環2.1 安裝依賴與項目目錄先準備好 Python 環境。建議用 3.10 以上版本避免類型注解寫法上遇到兼容問題。在任意目錄執行mkdir agent-skill-demo cd agent-skill-demo python -m venv .venv source .venv/bin/activate # Windows 下是 .venv\Scripts\activate pip install openai1.0 python-dotenv sentence-transformers numpy這里用到的依賴說明一下openai用來調用大模型 API我用的是 OpenAI 兼容協議后續換成其他兼容服務也基本不用改代碼。sentence-transformers用來把記憶片段轉成向量實現長期記憶中的語義檢索。numpy做向量點積計算。python-dotenv管理 API Key 等環境變量。目錄結構我建議按能力邊界分文件而不是把 Skill 都堆在一個文件里agent-skill-demo/ ├── .env ├── main_loop.py # Agent 主循環負責調度 Skill ├── skills/ │ ├── __init__.py │ ├── base.py # Skill 基類和元數據結構 │ └── task_follower.py # 任務推進助手 Skill └── memory/ ├── __init__.py ├── vector_store.py # 向量記憶存儲與檢索 └── memory_utils.py # 序列化、加載等輔助函數這樣分層的理由是memory 模塊不依賴具體 Skill可復用skills 模塊只依賴 BaseSkill 和 MemoryStore互相解耦。以后你想加第二個 Skill不需要動記憶模塊的代碼。2.2 Skill 元信息給大模型一張“說明書”Skill 的第一步是定義好它的身份。在大模型驅動的 Agent 里Skill 的 description 不是給人看的而是給調度器看的。如果描述不清晰模型會在錯誤的場景里調用它或者在合適的場景里忽略了它。# skills/base.py from __future__ import annotations from dataclasses import dataclass, field from typing import Any, Awaitable, Callable, Optional dataclass class SkillMeta: name: str description: str version: str 1.0 priority: int 100 tags: list[str] field(default_factorylist) # 可選的觸發條件描述例如“當檢測到用戶提到截止日期時” trigger_hint: str class BaseSkill: meta: SkillMeta def __init__(self) - None: # 這里預留 run_hooks不同擴展點會在不同時機被調度器調用 self.pre_hooks: list[Callable[[], Awaitable[None]]] [] self.post_hooks: list[Callable[[], Awaitable[None]]] [] async def execute(self, user_input: str, context: dict[str, Any]) - str: Skill 的主執行入口子類必須實現。 raise NotImplementedError async def build_context(self, user_input: str) - dict[str, Any]: 執行前構建上下文包括從記憶里召回相關內容。 raise NotImplementedError async def proactive_check(self, context: dict[str, Any]) - Optional[str]: 主動檢查返回需要主動推送的文本沒有則返回 None。 return None我特意把proactive_check從execute里拆出來是因為主動性并不總是“用戶剛說完話”的那個瞬間。Agent 主循環可以定時調用一次或者在其他事件到來時調用。這樣 Skill 既是響應式的也是事件驅動的。2.3 description 的寫法別寫功能寫場景一個常見的壞習慣是把 description 寫成“任務管理工具用于管理任務”這種描述對模型來說信息量太低了。更好的寫法是把“什么時候不該調用”也寫進去因為負例能顯著降低誤調用率。舉個例子TaskFollowerSkill.meta SkillMeta( nametask_follower, description( 當用戶提到任務、待辦、截止日期、提醒、計劃推進時使用。 它負責幫用戶拆分任務、記錄進度和偏好并在截止日期臨近時主動提醒。 如果用戶只是閑聊或者問百科知識不要調用本 Skill。 ), version1.0, priority90, tags[task, reminder, memory], trigger_hint新任務寫入或截止時間臨近時返回 proactive 文本, )看起來只是文字問題但實際影響很大。有一次我在一個測試項目里把 description 寫成了“任務管理工具”結果用戶問“幫我整理一下今天的會議地點”模型調用了任務管理 Skill卻不知道該提取什么字段輸出了垃圾結構。后來我把觸發場景寫清楚立刻好很多。這里有一個元層面的經驗Skill 的撰寫本質是在給模型寫“路由規則”。description 越接近真實場景路由就越準確。3. 核心工程給 Skill 接入長期記憶3.1 短期記憶與長期記憶的分工做 Agent 的初期我試過把所有歷史對話一股腦塞進上下文很快發現兩個問題一是窗口裝不下二是信息越多模型越容易受無關內容干擾。所以在任務推進助手里面我們必須把記憶分成兩層短期記憶Session Memory保留當前對話輪次的最近 10 條左右外加完整會話的壓縮摘要。長期記憶Long-term Memory跨會話保存用戶偏好、任務事實、重要結論以結構化記錄落盤。短期記憶很簡單就是維護一個messages列表每次執行完把 user 消息和 assistant 回復 append 進去。這個不難。困難的是長期記憶如何判斷什么值得記住、如何存儲、如何在需要的時候找回來。3.2 長期記憶存儲用向量 結構化的雙層結構我推薦的結構是“向量檢索為主結構化字段為輔”。向量負責語義召回結構化字段負責精確過濾比如按日期、按類型。這樣既避免了純關鍵詞搜索的呆板也避免了純向量檢索的日期混亂問題。先實現一個記憶條目# memory/vector_store.py from __future__ import annotations import json import os import numpy as np from dataclasses import dataclass, field dataclass class MemoryEntry: content: str kind: str fact created_at: str # ISO 格式時間 due_date: str | None None # 可選例如 2026-02-28 embedding: list[float] field(default_factorylist)每個字段的解釋content真正需要記憶的一句話比如“用戶偏好每天下午兩點后不打擾”。kind記憶類型。這里我定義了preference、todo、fact三種。類型的作用不是給人看的是給 recall 時過濾用的。due_date只有todo類型需要填方便做硬性的日期過濾。embedding把 content 向量化后得到的數組用于語義檢索。注意記憶條目在落盤時要轉成 JSON。numpy.ndarray不能直接被 json 序列化所以我統一存list類型class MemoryStore: def __init__(self, path: str memory_store.jsonl): self.path path os.makedirs(os.path.dirname(self.path), exist_okTrue) def _to_dict(self, entry: MemoryEntry) - dict: return { content: entry.content, kind: entry.kind, created_at: entry.created_at, due_date: entry.due_date, embedding: entry.embedding, } def _append(self, entry: MemoryEntry) - None: with open(self.path, a, encodingutf-8) as f: f.write(json.dumps(self._to_dict(entry), ensure_asciiFalse) \n)用 JSONL 而不是單個 JSON 文件是因為每條追加寫入的方式最簡單崩潰恢復也容易生產環境如果量大再替換成 SQLite 或專門的向量數據庫即可。3.3 embedding 計算與語義召回接下來是向量化。我是用本地方案避免每次調遠程 embedding 服務的延遲和成本。模型我選擇了BAAI/bge-small-zh-v1.5體積小中文效果足夠用。模型第一次加載會比較慢所以我用模塊級單例避免重復加載。# memory/vector_store.py 追加 from sentence_transformers import SentenceTransformer _model None def get_embedding(text: str) - np.ndarray: global _model if _model is None: _model SentenceTransformer(BAAI/bge-small-zh-v1.5) embedding _model.encode(text, normalize_embeddingsTrue) return np.asarray(embedding, dtypenp.float32)為什么要 normalize因為后面用點積表示余弦相似度時歸一化之后可以直接算q emb省去一次除法。大多數 embedding 模型都會建議歸一化如果有精度問題可以檢查一下是否做了這一步。召回邏輯如下def recall(self, query: str, top_k: int 3, kind: str | None None) - list[dict]: if not os.path.exists(self.path): return [] query_emb get_embedding(query) scored [] with open(self.path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue row json.loads(line) if kind and row.get(kind) ! kind: continue emb np.asarray(row[embedding], dtypenp.float32) score float(query_emb emb) scored.append((score, row)) scored.sort(keylambda x: x[0], reverseTrue) return [row for score, row in scored[:top_k] if score 0.35]這里的閾值 0.35 不是拍腦袋定的而是我用一小批測試句子調出來的低于這個值召回的條目經常和當前意圖完全無關高于 0.5很多相關的偏好又漏掉了。不同 embedding 模型閾值不一樣你換模型后必須重新做一次范圍測試。召回之后怎么用在 Skill 的build_context中我按類型分別召回。召回 preference 是為了構建系統人設召回 fact 是為了給模型補充背景召回 todo 是為了在主動檢查時用。4. 注入角色再給 Skill 裝上“主動性”4.1 角色提示詞不寫空話寫決策偏好角色本身并不神秘它就是一段 system prompt。但這里有個反直覺的點角色 prompt 不是越長越像人而是越能影響具體輸出越好。比如“你是一位耐心的助手”這種話模型很難根據它做出行為差異但“當用戶表現出焦慮時先共情再給建議”就能影響行為。我為任務推進助手寫的角色原則是你是“小助”一名任務推進助理。你說話風格簡潔不廢話不客套。 你的工作信條 1. 把模糊目標拆成下一步行動而不是只給宏大建議。 2. 記住用戶的偏好并主動調用記憶里的信息來調整表達方式。 3. 當發現任務有截止日期的風險時直接點出風險不拐彎抹角。 4. 每天主動提醒不超過三次除非用戶明確要求更頻繁。注意第三條和第四條它們在后面會被工程邏輯影響。角色 prompt 決定了模型“輸出什么氣質”工程邏輯決定了模型“在什么情況下開口”。兩者配合才叫有主動性的 Skill光靠 prompt 里的“你要主動”沒有用。把記憶注入角色 prompt 的方式def _build_system_prompt(self, mem_rows: list[dict]) - str: if mem_rows: lines \n.join( f- {row[content]} for row in mem_rows[:8] ) user_memory_section f\n用戶的重要信息\n{lines} else: user_memory_section \n用戶的重要信息暫無。 return ROLE_TEMPLATE user_memory_section這里有個約束召回的記憶不能全塞進去最多 8 條。否則長的記憶會讓 system prompt 變得很臃腫既浪費 token又會讓模型抓不住重點。4.2 如何判斷要不要“主動開口”主動性先要定義一個“觸發檢查”。我把觸發場景拆成兩類規則型觸發代碼判斷比如“任務 due_date 等于今天/已逾期”這種判斷必須交給代碼不能讓模型去算日期。語義型觸發需要理解上下文比如“用戶提到某個項目而這個項目在記憶里已經有待辦”這種判斷由模型做。真實項目里兩者要結合。我簡化成一個proactive_checkasync def proactive_check(self) - str | None: today datetime.now().strftime(%Y-%m-%d) overdue_items [] for row in self.memory.iter_all(kindtodo): due_date row.get(due_date) if not due_date: continue if due_date today: overdue_items.append(row) if not overdue_items: return None messages [] for item in overdue_items[:3]: messages.append(f任務{item[content]}截止時間{item[due_date]}) return 主動提醒你有任務需要關注。\n \n.join(messages)這段代碼的關鍵是日期比較用字符串是因為 ISO 格式YYYY-MM-DD的字典序和真實時間順序一致不需要額外轉 datetime。這個細節很實用。不過只靠規則會有 bug比如用戶說“下周二前給我初稿”模型并不一定會把 due_date 填對。所以在保存任務時我會先調用一次大模型做一個抽取動作把自然語言里的截止時間轉成 ISO 格式再寫入記憶。4.3 Skill 的完整實現與調用鏈路現在把角色、記憶、主動性串起來。下面是TaskFollowerSkill的核心代碼# skills/task_follower.py from __future__ import annotations import json from datetime import datetime from .base import BaseSkill, SkillMeta from memory.vector_store import MemoryStore, get_embedding ROLE_TEMPLATE 你是“小助”一名任務推進助理。你說話風格簡潔不廢話不客套。 你的工作信條 1. 把模糊目標拆成下一步行動而不是只給宏大建議。 2. 記住用戶的偏好并主動調用記憶里的信息來調整表達方式。 3. 當發現任務有截止日期的風險時直接點出風險不拐彎抹角。 4. 每天主動提醒不超過三次除非用戶明確要求更頻繁。 class TaskFollowerSkill(BaseSkill): meta SkillMeta( nametask_follower, description( 當用戶提到任務、待辦、截止日期、提醒、計劃推進時使用。 它負責幫用戶拆分任務、記錄進度和偏好并在截止日期臨近時主動提醒。 如果用戶只是閑聊或者問百科知識不要調用本 Skill。 ), version1.0, priority90, ) def __init__(self, llm_client): super().__init__() self.llm llm_client self.memory MemoryStore(memory_store.jsonl) def _save_preference_from_text(self, text: str): # 實踐中這里會讓 LLM 判斷是否值得記再決定寫入。 # 為了演示簡單我用一個規則當包含“我喜歡/我不喜歡/盡量/別”時寫入。 if any(kw in text for kw in [我喜歡, 我不喜歡, 盡量, 別, 不要]): self.memory.save( contenttext.strip(), kindpreference ) async def build_context(self, user_input: str) - dict: prefs self.memory.recall(用戶的偏好, kindpreference, top_k3) facts self.memory.recall(user_input, kindfact, top_k3) return {prefs: prefs, facts: facts} async def execute(self, user_input: str, context: dict | None None) - str: context context or await self.build_context(user_input) system_prompt ROLE_TEMPLATE if context[prefs]: system_prompt \n用戶相關偏好 for m in context[prefs]: system_prompt f\n- {m[content]} # 調用大模型讓助手給出回應 messages [ {role: system, content: system_prompt}, {role: user, content: user_input}, ] reply await self.llm.chat(messages) # 抽取可能存在的任務/偏好并寫入長期記憶 self._save_preference_from_text(user_input) return reply你要注意execute 返回給用戶的是模型的回復但它私下還會悄悄做兩件事檢索偏好、寫入新偏好。這就是“記憶”的開始。那么主動性是怎么被調用的是在 main loop 里。注意主循環不能只在用戶發消息后調用proactive_check還要周期性地調用一次。最簡單的方式是讓 main loop 每次處理用戶請求前都先檢查一次同時后臺定時任務每 30 分鐘也檢查一次。為了不打擾用戶我可以在 Skill 內維護一個“今天已提醒次數”的計數超過三次就不再觸發這個計數邏輯需要落到一個狀態文件里重啟程序后才能保留。# main_loop.py 片段 async def run_once(skill: TaskFollowerSkill, user_msg: str): # 在執行用戶消息前先看有沒有需要主動提醒的內容 proactive await skill.proactive_check() if proactive: print([主動提醒], proactive) # 再執行主任務 context await skill.build_context(user_msg) answer await skill.execute(user_msg, context) print([助手], answer)看到沒有這只是在用戶開口前進實際上就體現出了 Skill 的主動性。更進一步如果你的 Agent 跑在群聊或自動任務平臺上可以加一個 cron 觸發器每 10 分鐘調用一次proactive_check。這里不一定要做很重的調度系統把主動性做成 Skill 的一個方法剩下的就是外部什么時候想叫它的問題。5. 調試實錄把容易踩的坑一次說清5.1 大模型會把“偏好”和“事實”混為一談我早期把偏好數據全存成了fact后來發現召回時背景信息和用戶偏好混在一起導致模型在生成回復時把偏好當成客觀事實做出錯誤的推斷。比如用戶說“我不喜歡太長的提醒”模型如果沒有區分出這句話是 preference可能把“提醒不能太長”理解成任務內容回復風格就亂了。解決方法是給recall加kind參數并用“用戶偏好”作為查詢詞去召回。你可以做一個簡單的對照實驗把同一句話分別按fact和preference保存然后召回“用戶的偏好”高分的命中基本是preference類型的這證明類型過濾是有效且必要的。5.2 向量檢索對短句不敏感長句反而有用embedding 適合做語義相似度但它不是萬能的。我發現如果讓用戶輸入“提醒我周五交周報”然后直接拿這個整句去向量庫里召回往往匹配不到歷史偏好“用戶習慣周五上午交周報”因為兩個句子的表面形式差得有點遠。更穩的做法不是拿原始輸入做 query而是先用大模型把用戶的輸入轉成“記憶檢索詞”。也就是說與其問向量庫“提醒我周五交周報”不如問“用戶周五有哪些交材料的習慣”這樣召回的準確率會高不少。我在build_context里加上了一步調用模型生成短檢索詞再執行記憶召回。多了這一步延遲但效果提升非常大值得為它多花一兩秒。5.3 主動性觸發不能只看“日期 今天”還要考慮時區“今天”是一個隨時間變化的概念。如果你的 Agent 部署在服務器上服務器時區可能和用戶時區不一樣。比如服務器 UTC 時間是 2 月 28 日 16 點國內已經是 2 月 29 日 0 點一個在 2 月 29 日截止的任務就會因為判斷邏輯跑在 UTC 時區而錯誤地“還不是今天”。我的方案是把截止時間統一按用戶時區存儲并在比較今天日期時指定用戶時區from zoneinfo import ZoneInfo def get_user_today(user_tz: str Asia/Shanghai) - str: return datetime.now(ZoneInfo(user_tz)).strftime(%Y-%m-%d)別小看這個細節很多遠程提醒類 Avatar 早期版本出錯最后查下來全是時區問題。把日期處理的邊界釘死比增加各種提示詞更能保證可靠性。5.4 上下文里塞太多召回內容模型會“迷路”我剛做這個 Skill 時覺得召回越多越好模型知識多總比少好。測試后發現完全不是這樣。系統 prompt 加了一堆記憶之后模型在處理簡單任務時反而會“過度引用”歷史信息比如用戶單純問“把簡報發我”它居然會把以前記的“用戶喜歡用紅色標題”這種偏好強行塞進回復里。后來我把召回數量限制得很嚴格偏好最多 3 條事實最多 5 條且每條后面標注類型和觸發場景。模型反而表現更好。記憶系統最重要的是做減法不是做加法這條經驗同樣適用于幾乎所有的 Agent 系統。5.5 標準問題排查速查表現象可能原因排查與解決模型在無關場景調用 Skilldescription 寫得太寬泛補充負面觸發條件如“閑聊時不要調用”記憶召回結果和主題不相關閾值過低或 query 不精準提高閾值先用 LLM 生成檢索詞再召回主動提醒永遠不觸發時區不同導致日期判斷錯統一用用戶時區判斷“今天”模型記住了不該記的信息缺少記憶寫入審批環節保存前讓 LLM 判斷是否值得記并限制 content 長度長期記憶文件越來越大JSONL 只追加沒有合并去重定期壓縮對重復記憶按向量相似度合并Skill 重啟后主動提醒計數丟失計數只存在內存中把每天提醒次數寫入本地狀態文件這是我在跑這個演示項目時遇到的最典型的六個問題基本覆蓋了從路由、記憶到主動性的全過程。當你把它擴展到自己的項目時如果場景復雜建議先單獨測試記憶召回再測試主動觸發不要一上來就連起來調否則很難定位問題出在哪個環節。6. 向前一步把 Skill 升級成真正可落地的 Agent 能力到這你已經有了一個會記憶、會扮演角色、會主動檢查任務的 Skill。但如果你想把它接到生產環境我認為接下來要補三塊工作。第一給記憶系統加上合并更新能力。當前演示是每次都追加一條記憶里面容易有重復。實際操作中當向量召回發現相似度大于 0.9 的已有條目時應該替換舊條目而不是新增。你可以使用一個簡單的去重函數def upsert(self, entry: MemoryEntry) - None: similarities self._search(entry.content, top_k1) if similarities and similarities[0][score] 0.9: # 更新相似條目 self._delete_by_content(similarities[0][content]) self._append(entry)第二主動性觸發要做“抑制機制”。如果你希望 Skill 每天早上 9 點主動提醒一次那么必須有觸發狀態控制否則用戶在 9 點整正好發了條消息主循環調用一次proactive_check后臺任務再調用一次就會重復打擾。解決方式是在 Skill 內維護一個“最后一次主動提醒時間”的字段兩次提醒之間至少間隔 4 小時。第三把 Skill 的輸入從“單條文本”擴展為“結構化事件”。比如日歷同步、郵件到達、代碼倉庫 push這些都是外部事件。你可以在參數里加入event_type和event_data讓 Skill 在不同事件下走不同的處理分支。這一步做完你就不再只是做一個“聊天工具”而是真正把 Agent 嵌進工作流里了。我在實際測試這個 Skill 時最明顯的感覺是它開始像一個“有審美的同事”了。它不是每次都有問必答而是在合適的時間打擾你它能記得你說過的話并且用你舒服的方式回應。當你把這三層能力加到任意 Skill 上你寫的就不再是“一段 API 調用”而是一個有自己工作方式的數字員工。最后提醒一句啟動新項目時別急著堆功能先把記憶召回和主動檢查這兩個循環調穩整體體驗一定會超過你預期。 Agent Skill開發實戰：從Function Calling到記憶、角色與主動性的三層進化
最近老有朋友問我“Agent 和普通的大模型 API 封裝到底差在哪”我做這類應用的時間不算短過去一年里最大的感受就是區別不在于你調了幾次模型而在于你有沒有把“能力”做出“人感”來。這里說的“人感”落到工程上就是三件事Skill 有沒有記憶、有沒有角色、有沒有主動性。很多剛接觸 AI Agent 的人以為 Skill 就是一段可以被大模型調用的函數給它一個名字、一段描述、一個執行邏輯完事。但當你把 Skill 做成這樣你得到的只是一個工具不是一個能幫忙做事的智能體。今天這篇文章我就拿一個真實能跑的例子——“任務推進助手”Skill手把手把它寫出來。這個 Skill 會記住你的偏好、給自己設定角色還會在合適的時機主動提醒你該做的事情。文章面向兩類人一類是剛會調用大模型 API、想學 Agent 開發的新手另一類是已經在做 Agent 框架、但一直覺得“工具不夠聰明”的開發者。本文不要求你有很深的機器學習基礎只要你有 Python 基礎能跑通 OpenAI 兼容接口就基本能跟上。代碼偏工程向我會把所有關鍵選擇的“為什么”都說清楚。1. 動手之前先拆解 Skill 的三層能力1.1 Skill 和普通函數的邊界在哪里先說個你可能踩過的坑很多 Agent 框架只是把 Function Calling 包裝成了 Skill。底層邏輯是這樣框架把工具的 JSON Schema 喂給大模型模型覺得該調工具時就返回一個 tool call然后 Python 執行完再喂回去。這套機制本身沒問題但請你想一個問題函數是無狀態的Skill 如果也只是無狀態的那它充其量是“工具箱里的扳手”而不是“能獨當一面的幫手”。我理解中的 Skill至少要包含三部分元信息name、description、version、調用條件。這決定了大模型在什么場景下會選中它。執行邏輯真正做事的那段代碼、提示詞、工具調用鏈。生命周期它在被調用前要準備什么調用后要記住什么運行完之后會不會主動觸發其他動作。把這三部分補齊Skill 才從一個“函數”變成一種“帶狀態的自主能力”。我們下面要寫的任務推進助手就會同時擁有這三個層面。為什么不能直接用 Function Calling 解決因為 Function Calling 的天然邊界是“等用戶問”。它只能被動響應而一個會做任務管理的 Skill必須在用戶沒有明確說“幫我記任務”的時候也知道把關鍵信息沉淀到記憶里在用戶沒有問“今天有什么待辦”的時候也能根據時間戳和上下文判斷要不要主動提醒。這已經超出了普通函數的職責范圍。1.2 記憶、角色、主動性能力層級逐層遞進這三樣東西不是并列關系而是遞進關系。記憶是最底層。沒有記憶Agent 每一次對話都是“陌生人”。你在星期二告訴它“這個項目周五要交第一版”到星期四你再問它“我最近忙什么”它應該能回憶起這個 deadline。這里的記憶分為兩層短期記憶是當前會話的上下文長期記憶是跨會話沉淀下來的用戶偏好和事實。角色在記憶之上。角色本質上是一套行為約束和表達風格。同樣一句話讓同一個模型扮演“嚴肅項目經理”和“親切的同事”寫出來的任務提醒完全不一樣。有了角色Skill 的答案才穩定而不是每次跟著 prompt 隨機漂移。主動性在最上層。主動性不是讓模型像鬧鐘一樣每天定時亂叫而是讓它擁有“判斷什么時候該開口”的能力。一個任務推進助手如果所有提醒都等用戶來問那它根本不叫助手。真正的主動觸發點在工程上是事件驅動的用戶新提了一個任務、某個任務的截止時間快到了、用戶連續兩天沒更新狀態……這些事件到達時Skill 要能自動決定要不要打擾用戶。1.3 本項目落地形態與功能拆解我把示例 Skill 命名為TaskFollowerSkill中文名叫“任務推進助手”。它的能力拆解如下角色一名話不多、但邏輯嚴謹的項目推進助理。它不替用戶做決定只負責幫用戶把任務拆成可執行步驟并追蹤風險。記憶記錄用戶的核心偏好比如“每天提醒不要超過三次”“重要任務要排序”記錄任務狀態和截止時間。主動性當檢測到有任務在今天到期或者已經逾期時Skill 會返回一條非用戶主動詢問的提醒文本交給 Agent 主循環推送出去。擴展點為了不把事情做復雜這個版本我不集成日歷、郵件等外部系統而是把這些都抽象成“外部事件輸入”你在自己的項目里替換成真實接口即可。下面我們從零開始把這段代碼寫出來。2. 環境準備與 Skill 骨架先跑通最小閉環2.1 安裝依賴與項目目錄先準備好 Python 環境。建議用 3.10 以上版本避免類型注解寫法上遇到兼容問題。在任意目錄執行mkdir agent-skill-demo cd agent-skill-demo python -m venv .venv source .venv/bin/activate # Windows 下是 .venv\Scripts\activate pip install openai1.0 python-dotenv sentence-transformers numpy這里用到的依賴說明一下openai用來調用大模型 API我用的是 OpenAI 兼容協議后續換成其他兼容服務也基本不用改代碼。sentence-transformers用來把記憶片段轉成向量實現長期記憶中的語義檢索。numpy做向量點積計算。python-dotenv管理 API Key 等環境變量。目錄結構我建議按能力邊界分文件而不是把 Skill 都堆在一個文件里agent-skill-demo/ ├── .env ├── main_loop.py # Agent 主循環負責調度 Skill ├── skills/ │ ├── __init__.py │ ├── base.py # Skill 基類和元數據結構 │ └── task_follower.py # 任務推進助手 Skill └── memory/ ├── __init__.py ├── vector_store.py # 向量記憶存儲與檢索 └── memory_utils.py # 序列化、加載等輔助函數這樣分層的理由是memory 模塊不依賴具體 Skill可復用skills 模塊只依賴 BaseSkill 和 MemoryStore互相解耦。以后你想加第二個 Skill不需要動記憶模塊的代碼。2.2 Skill 元信息給大模型一張“說明書”Skill 的第一步是定義好它的身份。在大模型驅動的 Agent 里Skill 的 description 不是給人看的而是給調度器看的。如果描述不清晰模型會在錯誤的場景里調用它或者在合適的場景里忽略了它。# skills/base.py from __future__ import annotations from dataclasses import dataclass, field from typing import Any, Awaitable, Callable, Optional dataclass class SkillMeta: name: str description: str version: str 1.0 priority: int 100 tags: list[str] field(default_factorylist) # 可選的觸發條件描述例如“當檢測到用戶提到截止日期時” trigger_hint: str class BaseSkill: meta: SkillMeta def __init__(self) - None: # 這里預留 run_hooks不同擴展點會在不同時機被調度器調用 self.pre_hooks: list[Callable[[], Awaitable[None]]] [] self.post_hooks: list[Callable[[], Awaitable[None]]] [] async def execute(self, user_input: str, context: dict[str, Any]) - str: Skill 的主執行入口子類必須實現。 raise NotImplementedError async def build_context(self, user_input: str) - dict[str, Any]: 執行前構建上下文包括從記憶里召回相關內容。 raise NotImplementedError async def proactive_check(self, context: dict[str, Any]) - Optional[str]: 主動檢查返回需要主動推送的文本沒有則返回 None。 return None我特意把proactive_check從execute里拆出來是因為主動性并不總是“用戶剛說完話”的那個瞬間。Agent 主循環可以定時調用一次或者在其他事件到來時調用。這樣 Skill 既是響應式的也是事件驅動的。2.3 description 的寫法別寫功能寫場景一個常見的壞習慣是把 description 寫成“任務管理工具用于管理任務”這種描述對模型來說信息量太低了。更好的寫法是把“什么時候不該調用”也寫進去因為負例能顯著降低誤調用率。舉個例子TaskFollowerSkill.meta SkillMeta( nametask_follower, description( 當用戶提到任務、待辦、截止日期、提醒、計劃推進時使用。 它負責幫用戶拆分任務、記錄進度和偏好并在截止日期臨近時主動提醒。 如果用戶只是閑聊或者問百科知識不要調用本 Skill。 ), version1.0, priority90, tags[task, reminder, memory], trigger_hint新任務寫入或截止時間臨近時返回 proactive 文本, )看起來只是文字問題但實際影響很大。有一次我在一個測試項目里把 description 寫成了“任務管理工具”結果用戶問“幫我整理一下今天的會議地點”模型調用了任務管理 Skill卻不知道該提取什么字段輸出了垃圾結構。后來我把觸發場景寫清楚立刻好很多。這里有一個元層面的經驗Skill 的撰寫本質是在給模型寫“路由規則”。description 越接近真實場景路由就越準確。3. 核心工程給 Skill 接入長期記憶3.1 短期記憶與長期記憶的分工做 Agent 的初期我試過把所有歷史對話一股腦塞進上下文很快發現兩個問題一是窗口裝不下二是信息越多模型越容易受無關內容干擾。所以在任務推進助手里面我們必須把記憶分成兩層短期記憶Session Memory保留當前對話輪次的最近 10 條左右外加完整會話的壓縮摘要。長期記憶Long-term Memory跨會話保存用戶偏好、任務事實、重要結論以結構化記錄落盤。短期記憶很簡單就是維護一個messages列表每次執行完把 user 消息和 assistant 回復 append 進去。這個不難。困難的是長期記憶如何判斷什么值得記住、如何存儲、如何在需要的時候找回來。3.2 長期記憶存儲用向量 結構化的雙層結構我推薦的結構是“向量檢索為主結構化字段為輔”。向量負責語義召回結構化字段負責精確過濾比如按日期、按類型。這樣既避免了純關鍵詞搜索的呆板也避免了純向量檢索的日期混亂問題。先實現一個記憶條目# memory/vector_store.py from __future__ import annotations import json import os import numpy as np from dataclasses import dataclass, field dataclass class MemoryEntry: content: str kind: str fact created_at: str # ISO 格式時間 due_date: str | None None # 可選例如 2026-02-28 embedding: list[float] field(default_factorylist)每個字段的解釋content真正需要記憶的一句話比如“用戶偏好每天下午兩點后不打擾”。kind記憶類型。這里我定義了preference、todo、fact三種。類型的作用不是給人看的是給 recall 時過濾用的。due_date只有todo類型需要填方便做硬性的日期過濾。embedding把 content 向量化后得到的數組用于語義檢索。注意記憶條目在落盤時要轉成 JSON。numpy.ndarray不能直接被 json 序列化所以我統一存list類型class MemoryStore: def __init__(self, path: str memory_store.jsonl): self.path path os.makedirs(os.path.dirname(self.path), exist_okTrue) def _to_dict(self, entry: MemoryEntry) - dict: return { content: entry.content, kind: entry.kind, created_at: entry.created_at, due_date: entry.due_date, embedding: entry.embedding, } def _append(self, entry: MemoryEntry) - None: with open(self.path, a, encodingutf-8) as f: f.write(json.dumps(self._to_dict(entry), ensure_asciiFalse) \n)用 JSONL 而不是單個 JSON 文件是因為每條追加寫入的方式最簡單崩潰恢復也容易生產環境如果量大再替換成 SQLite 或專門的向量數據庫即可。3.3 embedding 計算與語義召回接下來是向量化。我是用本地方案避免每次調遠程 embedding 服務的延遲和成本。模型我選擇了BAAI/bge-small-zh-v1.5體積小中文效果足夠用。模型第一次加載會比較慢所以我用模塊級單例避免重復加載。# memory/vector_store.py 追加 from sentence_transformers import SentenceTransformer _model None def get_embedding(text: str) - np.ndarray: global _model if _model is None: _model SentenceTransformer(BAAI/bge-small-zh-v1.5) embedding _model.encode(text, normalize_embeddingsTrue) return np.asarray(embedding, dtypenp.float32)為什么要 normalize因為后面用點積表示余弦相似度時歸一化之后可以直接算q emb省去一次除法。大多數 embedding 模型都會建議歸一化如果有精度問題可以檢查一下是否做了這一步。召回邏輯如下def recall(self, query: str, top_k: int 3, kind: str | None None) - list[dict]: if not os.path.exists(self.path): return [] query_emb get_embedding(query) scored [] with open(self.path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue row json.loads(line) if kind and row.get(kind) ! kind: continue emb np.asarray(row[embedding], dtypenp.float32) score float(query_emb emb) scored.append((score, row)) scored.sort(keylambda x: x[0], reverseTrue) return [row for score, row in scored[:top_k] if score 0.35]這里的閾值 0.35 不是拍腦袋定的而是我用一小批測試句子調出來的低于這個值召回的條目經常和當前意圖完全無關高于 0.5很多相關的偏好又漏掉了。不同 embedding 模型閾值不一樣你換模型后必須重新做一次范圍測試。召回之后怎么用在 Skill 的build_context中我按類型分別召回。召回 preference 是為了構建系統人設召回 fact 是為了給模型補充背景召回 todo 是為了在主動檢查時用。4. 注入角色再給 Skill 裝上“主動性”4.1 角色提示詞不寫空話寫決策偏好角色本身并不神秘它就是一段 system prompt。但這里有個反直覺的點角色 prompt 不是越長越像人而是越能影響具體輸出越好。比如“你是一位耐心的助手”這種話模型很難根據它做出行為差異但“當用戶表現出焦慮時先共情再給建議”就能影響行為。我為任務推進助手寫的角色原則是你是“小助”一名任務推進助理。你說話風格簡潔不廢話不客套。 你的工作信條 1. 把模糊目標拆成下一步行動而不是只給宏大建議。 2. 記住用戶的偏好并主動調用記憶里的信息來調整表達方式。 3. 當發現任務有截止日期的風險時直接點出風險不拐彎抹角。 4. 每天主動提醒不超過三次除非用戶明確要求更頻繁。注意第三條和第四條它們在后面會被工程邏輯影響。角色 prompt 決定了模型“輸出什么氣質”工程邏輯決定了模型“在什么情況下開口”。兩者配合才叫有主動性的 Skill光靠 prompt 里的“你要主動”沒有用。把記憶注入角色 prompt 的方式def _build_system_prompt(self, mem_rows: list[dict]) - str: if mem_rows: lines \n.join( f- {row[content]} for row in mem_rows[:8] ) user_memory_section f\n用戶的重要信息\n{lines} else: user_memory_section \n用戶的重要信息暫無。 return ROLE_TEMPLATE user_memory_section這里有個約束召回的記憶不能全塞進去最多 8 條。否則長的記憶會讓 system prompt 變得很臃腫既浪費 token又會讓模型抓不住重點。4.2 如何判斷要不要“主動開口”主動性先要定義一個“觸發檢查”。我把觸發場景拆成兩類規則型觸發代碼判斷比如“任務 due_date 等于今天/已逾期”這種判斷必須交給代碼不能讓模型去算日期。語義型觸發需要理解上下文比如“用戶提到某個項目而這個項目在記憶里已經有待辦”這種判斷由模型做。真實項目里兩者要結合。我簡化成一個proactive_checkasync def proactive_check(self) - str | None: today datetime.now().strftime(%Y-%m-%d) overdue_items [] for row in self.memory.iter_all(kindtodo): due_date row.get(due_date) if not due_date: continue if due_date today: overdue_items.append(row) if not overdue_items: return None messages [] for item in overdue_items[:3]: messages.append(f任務{item[content]}截止時間{item[due_date]}) return 主動提醒你有任務需要關注。\n \n.join(messages)這段代碼的關鍵是日期比較用字符串是因為 ISO 格式YYYY-MM-DD的字典序和真實時間順序一致不需要額外轉 datetime。這個細節很實用。不過只靠規則會有 bug比如用戶說“下周二前給我初稿”模型并不一定會把 due_date 填對。所以在保存任務時我會先調用一次大模型做一個抽取動作把自然語言里的截止時間轉成 ISO 格式再寫入記憶。4.3 Skill 的完整實現與調用鏈路現在把角色、記憶、主動性串起來。下面是TaskFollowerSkill的核心代碼# skills/task_follower.py from __future__ import annotations import json from datetime import datetime from .base import BaseSkill, SkillMeta from memory.vector_store import MemoryStore, get_embedding ROLE_TEMPLATE 你是“小助”一名任務推進助理。你說話風格簡潔不廢話不客套。 你的工作信條 1. 把模糊目標拆成下一步行動而不是只給宏大建議。 2. 記住用戶的偏好并主動調用記憶里的信息來調整表達方式。 3. 當發現任務有截止日期的風險時直接點出風險不拐彎抹角。 4. 每天主動提醒不超過三次除非用戶明確要求更頻繁。 class TaskFollowerSkill(BaseSkill): meta SkillMeta( nametask_follower, description( 當用戶提到任務、待辦、截止日期、提醒、計劃推進時使用。 它負責幫用戶拆分任務、記錄進度和偏好并在截止日期臨近時主動提醒。 如果用戶只是閑聊或者問百科知識不要調用本 Skill。 ), version1.0, priority90, ) def __init__(self, llm_client): super().__init__() self.llm llm_client self.memory MemoryStore(memory_store.jsonl) def _save_preference_from_text(self, text: str): # 實踐中這里會讓 LLM 判斷是否值得記再決定寫入。 # 為了演示簡單我用一個規則當包含“我喜歡/我不喜歡/盡量/別”時寫入。 if any(kw in text for kw in [我喜歡, 我不喜歡, 盡量, 別, 不要]): self.memory.save( contenttext.strip(), kindpreference ) async def build_context(self, user_input: str) - dict: prefs self.memory.recall(用戶的偏好, kindpreference, top_k3) facts self.memory.recall(user_input, kindfact, top_k3) return {prefs: prefs, facts: facts} async def execute(self, user_input: str, context: dict | None None) - str: context context or await self.build_context(user_input) system_prompt ROLE_TEMPLATE if context[prefs]: system_prompt \n用戶相關偏好 for m in context[prefs]: system_prompt f\n- {m[content]} # 調用大模型讓助手給出回應 messages [ {role: system, content: system_prompt}, {role: user, content: user_input}, ] reply await self.llm.chat(messages) # 抽取可能存在的任務/偏好并寫入長期記憶 self._save_preference_from_text(user_input) return reply你要注意execute 返回給用戶的是模型的回復但它私下還會悄悄做兩件事檢索偏好、寫入新偏好。這就是“記憶”的開始。那么主動性是怎么被調用的是在 main loop 里。注意主循環不能只在用戶發消息后調用proactive_check還要周期性地調用一次。最簡單的方式是讓 main loop 每次處理用戶請求前都先檢查一次同時后臺定時任務每 30 分鐘也檢查一次。為了不打擾用戶我可以在 Skill 內維護一個“今天已提醒次數”的計數超過三次就不再觸發這個計數邏輯需要落到一個狀態文件里重啟程序后才能保留。# main_loop.py 片段 async def run_once(skill: TaskFollowerSkill, user_msg: str): # 在執行用戶消息前先看有沒有需要主動提醒的內容 proactive await skill.proactive_check() if proactive: print([主動提醒], proactive) # 再執行主任務 context await skill.build_context(user_msg) answer await skill.execute(user_msg, context) print([助手], answer)看到沒有這只是在用戶開口前進實際上就體現出了 Skill 的主動性。更進一步如果你的 Agent 跑在群聊或自動任務平臺上可以加一個 cron 觸發器每 10 分鐘調用一次proactive_check。這里不一定要做很重的調度系統把主動性做成 Skill 的一個方法剩下的就是外部什么時候想叫它的問題。5. 調試實錄把容易踩的坑一次說清5.1 大模型會把“偏好”和“事實”混為一談我早期把偏好數據全存成了fact后來發現召回時背景信息和用戶偏好混在一起導致模型在生成回復時把偏好當成客觀事實做出錯誤的推斷。比如用戶說“我不喜歡太長的提醒”模型如果沒有區分出這句話是 preference可能把“提醒不能太長”理解成任務內容回復風格就亂了。解決方法是給recall加kind參數并用“用戶偏好”作為查詢詞去召回。你可以做一個簡單的對照實驗把同一句話分別按fact和preference保存然后召回“用戶的偏好”高分的命中基本是preference類型的這證明類型過濾是有效且必要的。5.2 向量檢索對短句不敏感長句反而有用embedding 適合做語義相似度但它不是萬能的。我發現如果讓用戶輸入“提醒我周五交周報”然后直接拿這個整句去向量庫里召回往往匹配不到歷史偏好“用戶習慣周五上午交周報”因為兩個句子的表面形式差得有點遠。更穩的做法不是拿原始輸入做 query而是先用大模型把用戶的輸入轉成“記憶檢索詞”。也就是說與其問向量庫“提醒我周五交周報”不如問“用戶周五有哪些交材料的習慣”這樣召回的準確率會高不少。我在build_context里加上了一步調用模型生成短檢索詞再執行記憶召回。多了這一步延遲但效果提升非常大值得為它多花一兩秒。5.3 主動性觸發不能只看“日期 今天”還要考慮時區“今天”是一個隨時間變化的概念。如果你的 Agent 部署在服務器上服務器時區可能和用戶時區不一樣。比如服務器 UTC 時間是 2 月 28 日 16 點國內已經是 2 月 29 日 0 點一個在 2 月 29 日截止的任務就會因為判斷邏輯跑在 UTC 時區而錯誤地“還不是今天”。我的方案是把截止時間統一按用戶時區存儲并在比較今天日期時指定用戶時區from zoneinfo import ZoneInfo def get_user_today(user_tz: str Asia/Shanghai) - str: return datetime.now(ZoneInfo(user_tz)).strftime(%Y-%m-%d)別小看這個細節很多遠程提醒類 Avatar 早期版本出錯最后查下來全是時區問題。把日期處理的邊界釘死比增加各種提示詞更能保證可靠性。5.4 上下文里塞太多召回內容模型會“迷路”我剛做這個 Skill 時覺得召回越多越好模型知識多總比少好。測試后發現完全不是這樣。系統 prompt 加了一堆記憶之后模型在處理簡單任務時反而會“過度引用”歷史信息比如用戶單純問“把簡報發我”它居然會把以前記的“用戶喜歡用紅色標題”這種偏好強行塞進回復里。后來我把召回數量限制得很嚴格偏好最多 3 條事實最多 5 條且每條后面標注類型和觸發場景。模型反而表現更好。記憶系統最重要的是做減法不是做加法這條經驗同樣適用于幾乎所有的 Agent 系統。5.5 標準問題排查速查表現象可能原因排查與解決模型在無關場景調用 Skilldescription 寫得太寬泛補充負面觸發條件如“閑聊時不要調用”記憶召回結果和主題不相關閾值過低或 query 不精準提高閾值先用 LLM 生成檢索詞再召回主動提醒永遠不觸發時區不同導致日期判斷錯統一用用戶時區判斷“今天”模型記住了不該記的信息缺少記憶寫入審批環節保存前讓 LLM 判斷是否值得記并限制 content 長度長期記憶文件越來越大JSONL 只追加沒有合并去重定期壓縮對重復記憶按向量相似度合并Skill 重啟后主動提醒計數丟失計數只存在內存中把每天提醒次數寫入本地狀態文件這是我在跑這個演示項目時遇到的最典型的六個問題基本覆蓋了從路由、記憶到主動性的全過程。當你把它擴展到自己的項目時如果場景復雜建議先單獨測試記憶召回再測試主動觸發不要一上來就連起來調否則很難定位問題出在哪個環節。6. 向前一步把 Skill 升級成真正可落地的 Agent 能力到這你已經有了一個會記憶、會扮演角色、會主動檢查任務的 Skill。但如果你想把它接到生產環境我認為接下來要補三塊工作。第一給記憶系統加上合并更新能力。當前演示是每次都追加一條記憶里面容易有重復。實際操作中當向量召回發現相似度大于 0.9 的已有條目時應該替換舊條目而不是新增。你可以使用一個簡單的去重函數def upsert(self, entry: MemoryEntry) - None: similarities self._search(entry.content, top_k1) if similarities and similarities[0][score] 0.9: # 更新相似條目 self._delete_by_content(similarities[0][content]) self._append(entry)第二主動性觸發要做“抑制機制”。如果你希望 Skill 每天早上 9 點主動提醒一次那么必須有觸發狀態控制否則用戶在 9 點整正好發了條消息主循環調用一次proactive_check后臺任務再調用一次就會重復打擾。解決方式是在 Skill 內維護一個“最后一次主動提醒時間”的字段兩次提醒之間至少間隔 4 小時。第三把 Skill 的輸入從“單條文本”擴展為“結構化事件”。比如日歷同步、郵件到達、代碼倉庫 push這些都是外部事件。你可以在參數里加入event_type和event_data讓 Skill 在不同事件下走不同的處理分支。這一步做完你就不再只是做一個“聊天工具”而是真正把 Agent 嵌進工作流里了。我在實際測試這個 Skill 時最明顯的感覺是它開始像一個“有審美的同事”了。它不是每次都有問必答而是在合適的時間打擾你它能記得你說過的話并且用你舒服的方式回應。當你把這三層能力加到任意 Skill 上你寫的就不再是“一段 API 調用”而是一個有自己工作方式的數字員工。最后提醒一句啟動新項目時別急著堆功能先把記憶召回和主動檢查這兩個循環調穩整體體驗一定會超過你預期。