openPangu 2.0 讓小藝會用工具

我把華為 openPangu 2.0 的工具調用思路拆成了可直接套用的助手模板。

我這幾年看過太多「智能助手」了，名字一個比一個響，實際一用就露餡。最煩的就是那種只會接話的：你問它一個事，它先誇你提得好，再繞半天，最後還是沒幹活。更糟的是，很多系統把「會聊天」當成「會做事」，把「能調用工具」當成「已經有 Agent 了」。結果就是，demo 看著挺像那麼回事，真放進日常工作流裡，還是一團散沙。

我最近重新看華為這條線，感覺它終於不再滿足於「回答問題」這件事了。它想做的是把對話、工具、上下文、應用內動作揉成一個能執行任務的系統。這個方向我其實不陌生，OpenAI Operator、Claude Code、還有 Gemini 2.0 這類東西都在往這邊走，但華為這次最有意思的點，不是「也做了 Agent」，而是它把系統級能力、應用級 skill、以及上下文管理綁到了一起。這個組合，才是它真正改變交互範式的地方。

它不是在做聊天機器人，而是在做「能接活」的系統

從鴻蒙7開始，小藝終於對之前零散的能力做了各種整合，它終於像一個龍蝦/claude code一樣，具備“思考、行動、觀察、重複”的能力，也具備在對話中想起來自己有工具可以調用的能力，也具備了上下文管理的能力。

這段話的核心意思很直接：小藝不再只是「答題器」，而是開始像一個真正的任務執行器。你說一句話，它不只是生成一句回覆，而是會判斷這句話是不是要查、要點、要改、要調用某個 App 的能力。然後它會執行，觀察結果，再決定下一步。

我自己最煩的就是那種「假工具調用」。表面上掛了很多 API，實際模型根本不知道什麼時候該用，或者用完之後不會繼續推進任務。那種系統看著像 Agent，幹起來像客服腳本。華為這裡的思路更像是在補齊閉環：思考、行動、觀察、重複。這個閉環一旦成立，助手才真的開始像助手，而不是像一個會說話的搜尋框。

這裡我建議你把重點放在「任務」而不是「對話」上。對話只是入口，任務才是目標。你要問自己：使用者說的這句話，是不是可以拆成幾個動作？這些動作有沒有明確的執行邊界？執行後能不能拿到結果繼續推理？如果答案都是肯定的，那這個系統才值得做 Agent 化。

• 先定義任務，而不是先堆模型。
• 把每個任務拆成可執行動作。
• 讓模型在動作結果回來後繼續決策。

如果你要照著這個方向做，我會先從 3 類場景下手：搜尋、下單、修改狀態。它們最容易驗證「會做事」是不是成立，因為每一步都有明確結果，最適合做閉環。

skill 不是裝飾品，是應用把能力交給系統的接口

原文裡最關鍵的一句其實是這個：

一方面允許開發者給自己的App定義skill，讓系統小藝Agent能夠輕鬆調用應用內邏輯執行各類操作

這句話的意思很大，但我得說得更白一點：華為不是想讓模型去「猜」你的 App 怎麼用，而是讓 App 主動把能力暴露出來。這個差別非常大。前者靠模型瞎摸索，後者靠開發者提供明確入口。前者脆，後者可控。

我見過太多團隊把「讓模型操作 App」理解成「把介面丟給模型看」。這條路不是不能走，但太容易失控。UI 會變，按鈕會改，頁面結構會抖，模型每次都像在做陌生環境導航。skill 的價值就在這裡：它把操作從 UI 裡抽出來，變成穩定接口。模型不用猜「點哪兒」，只要知道「這個能力叫什麼、輸入是什麼、輸出是什麼」。

如果你是開發者，這其實是一種很現實的分工。模型負責意圖理解和決策，App 負責業務邏輯和權限邊界。這樣一來，系統就不會把所有責任都壓在模型身上。說句難聽的，很多失敗的 Agent 項目，都是因為團隊想讓模型同時當產品經理、前端、後端、測試和客服，最後誰都不像。

我跑過一個內部原型時就踩過這個坑。我們一開始想讓模型直接操作頁面，結果只要文案一改，整條鏈路就抖。後來改成內部 action schema，模型只選 action，不碰頁面細節，穩定性立刻上來了。華為這個 skill 思路，本質上就是把這個經驗產品化了。

怎麼落地？我會這麼做：

• 把高頻業務動作抽成 skill，不要一上來全量開放。
• 每個 skill 明確輸入、輸出、錯誤碼。
• 做權限校驗，不要讓模型替你決定安全邊界。
• 給 skill 起業務名，不要起「tool_001」這種沒人看得懂的名字。

如果你做的是消費級 App，這一步尤其重要。因為使用者根本不在乎你是不是「用了大模型」，使用者只在乎它能不能替我把事辦完。

上下文管理才是 Agent 能不能長期可用的分水嶺

很多人一提 Agent，就只盯著「會不會調用工具」。我覺得這太淺了。真正拉開差距的，往往是上下文管理。因為工具調用只是單次動作，上下文管理決定它能不能連續做事。

原文裡說小藝也具備了上下文管理能力，這點我非常認同。沒有上下文管理，Agent 每一步都像失憶。你剛讓它查完比價，它下一句又忘了剛才看的是什么；你剛讓它訂餐，它下一步又要你重複地址和偏好。使用者體驗會非常爛，爛到你根本不想再用第二次。

我把上下文管理分成三層看：

• 短上下文：當前這輪對話裡剛說過什麼。
• 任務上下文：這次任務的目標、約束、當前進度。
• 長期上下文：使用者偏好、常用地址、歷史選擇，但必須可控、可刪除、可解釋。

這三層裡，最容易被忽略的是任務上下文。很多系統只記聊天歷史，不記任務狀態。結果就是模型能「聊得像人」，卻「做事像魚」。華為這條線如果真把任務上下文做穩了，那它就不只是一個語音助手，而是一個可以持續推進事務的系統入口。

怎麼應用到你自己的產品裡？我建議你別先想著「記住使用者一切」，先想「這次任務要記住什麼」。比如點外賣這個場景，你至少要記住：預算、口味、地址、是否要發票、是否允許替代。把這些做成結構化狀態，比把整段聊天丟給模型可靠得多。

還有一點我想強調：上下文不是越多越好。上下文越多，污染也越多。你得有清理機制，有過期機制，有優先級。否則模型會被一堆歷史廢話拖死。

「思考、行動、觀察、重複」不是口號，是執行循環

這一段我其實最想單獨拎出來，因為很多團隊把它說得太玄了。其實它一點都不玄，就是一個非常樸素的控制循環。

具備“思考、行動、觀察、重複”的能力

這句話翻成工程語言就是：先規劃下一步，執行動作，讀回結果，再決定下一步。聽起來簡單，但真正難的是每一步都要有明確的狀態切換。沒有狀態機，Agent 就會在「我想一下」和「我再試試」之間無限打轉。

我以前做過一個內部自動化助手，最開始也很自信，想著模型能自己推理。結果一上線，最常見的問題不是不會答，而是會重複調用同一個動作，或者在失敗後亂改方向。後來我們加了執行狀態、重試限制、失敗分支、人工接管點，系統才像樣。

如果你想把這個循環做實，我建議你至少設計這幾個狀態：

• Plan：模型決定下一步做什麼。
• Act：調用 skill 或工具。
• Observe：讀取返回值、錯誤和副作用。
• Reflect：判斷是否繼續、改道或結束。

注意，Reflect 這一步不是讓模型寫長篇大論，而是讓它做決策。別把 Agent 變成作文比賽。你要的是可執行的判斷，不是漂亮的自我感動。

華為這次的價值就在於，它把這個循環放進系統層，而不是只停留在某個 demo 裡。系統級入口一旦成立，使用者就不需要知道背後到底是哪个模型、哪條鏈路、哪種 prompt。使用者只會覺得：它真的開始替我幹活了。

真正該學的不是模型大小，是系統邊界怎麼劃

很多人看到「開源盤古 2.0」就會下意識問：參數多少？能力多強？榜單多少分？我倒覺得這些問題都太快了。先別急著比模型，先看系統邊界怎麼劃。因為一旦進入 Agent 場景，模型強不強只是其中一環，邊界設計才決定它能不能上線。

華為這套思路裡，我最在意的是它把哪些能力留給系統，哪些留給 App，哪些留給模型。這個分層如果清楚，產品就容易收斂；如果不清楚，最後就會變成「誰都能做一點，誰都做不完整」。

我通常會這麼切：

• 模型：理解意圖、生成計劃、選擇動作。
• 系統：權限、會話、路由、審計、回退。
• App skill：業務執行、資料讀寫、結果返回。

這個切法的好處是很現實的。模型出錯了，系統還能兜底；App 接口變了，只要 skill 適配層還在，模型不用重訓；權限出問題，系統層直接擋住，不讓模型亂來。你不這樣切，最後就會把所有風險都壓到 prompt 上。那不是工程，那是祈禱。

如果你要做類似產品，我建議你先問三個問題：第一，哪些動作必須可審計？第二，哪些動作必須使用者確認？第三，哪些動作必須支援回滾？這三個問題答清楚，系統邊界就有了。

這類助手最值錢的地方，是把應用變成可被調用的能力池

我覺得華為這次最值得開發者注意的，不是「小藝變聰明了」，而是「應用終於可以被系統級助手調用了」。這意味著 App 不再只是一個孤立介面，而是一個能力提供者。這個變化很大，真的很大。

以前 App 的價值主要體現在使用者自己點進去用。現在如果系統層能直接調用你的 skill，那你的 App 就多了一個入口，而且這個入口不是選單，不是按鈕，是意圖。使用者甚至不需要知道 App 裡具體怎麼走流程，只要說一句「幫我比價並下單」，系統就能把多個 App 的能力串起來。

對開發者來說，這意味著你要重新思考產品設計：

• 哪些能力適合暴露給系統？
• 哪些能力需要合併成更高層的 task skill？
• 哪些關鍵步驟必須保留使用者確認？

我不建議一上來就把所有功能都做成 skill。那樣只會把複雜度炸開。先挑高頻、低風險、可驗證的動作做。比如搜尋、篩選、預填、草稿生成、狀態查詢。這些動作一旦跑通，後面再往深處擴。

如果你想參考更通用的工具協議，可以看看 OpenAI function calling、Anthropic tool use，以及 Google Gemini function calling。我不是讓你照搬，而是讓你看清一個事實：工具調用不是附加功能，它已經是現代助手的基本工作方式了。

你可以直接照著做的模板

下面這個模板不是「通用大而全方案」，而是我會拿去做原型的最小閉環。它的目標很明確：讓一個系統級助手能夠理解使用者意圖、選擇 skill、執行動作、讀取結果、繼續推進任務。你可以把它改成你自己的 App skill 規範、Agent prompt，或者任務編排協議。

## 系統角色定義（System Prompt / Orchestrator Spec）

你是一個任務執行型助手。你的目標不是閒聊，而是把使用者請求拆成可執行步驟，並在需要時調用可用的 skill 完成任務。

### 核心原則
1. 先理解任務，再決定是否調用 skill。
2. 只在有明確收益時調用 skill，不要為了調用而調用。
3. 每次 skill 返回後，都要根據結果決定下一步。
4. 如果資訊不足，先問最少量的問題。
5. 涉及支付、刪除、發布、下單、授權等操作時，必須先獲得使用者確認。
6. 任何時候都要維護任務上下文，不要重複問已經確認過的資訊。

### 可用 skill 示例
- search_items(query, filters)
- compare_items(item_ids)
- create_order(item_id, address_id, coupon_id)
- get_user_profile()
- get_task_state(task_id)
- update_task_state(task_id, patch)
- request_user_confirmation(action_summary)

### 決策流程
1. 解析使用者目標
2. 判斷是否需要 skill
3. 選擇最合適的 skill
4. 執行 skill
5. 觀察返回結果
6. 更新任務狀態
7. 繼續執行或結束

### 輸出格式
- 如果需要調用 skill：輸出結構化調用請求
- 如果需要向使用者提問：只問最必要的一句
- 如果任務完成：總結結果，說明下一步

---

## Skill 設計模板

### Skill 名稱
search_items

### 作用
根據關鍵詞和條件搜尋商品或服務。

### 輸入
{
  "query": "string",
  "filters": {
    "price_max": "number|null",
    "category": "string|null",
    "delivery_time_max": "string|null"
  }
}

### 輸出
{
  "results": [
    {
      "id": "string",
      "title": "string",
      "price": "number",
      "score": "number"
    }
  ],
  "count": "number"
}

### 失敗處理
- 無結果：返回空陣列，並提示可放寬條件
- 參數缺失：返回缺失欄位列表
- 介面錯誤：返回錯誤碼和可重試建議

---

## 任務上下文模板
{
  "task_id": "task_123",
  "goal": "幫使用者找到並下單晚餐",
  "constraints": {
    "budget_max": 50,
    "delivery_address": "已確認",
    "must_confirm_payment": true
  },
  "state": {
    "step": "compare_items",
    "selected_item_id": null,
    "waiting_for_confirmation": false
  },
  "history": [
    {
      "role": "user",
      "content": "幫我點外賣，預算 50 以內"
    },
    {
      "role": "assistant",
      "content": "我先幫你篩選可選項"
    }
  ]
}

---

## 執行示例
使用者：幫我找 50 元以內、30 分鐘能送到的晚餐

助手：調用 search_items
{
  "query": "晚餐",
  "filters": {
    "price_max": 50,
    "category": "food",
    "delivery_time_max": "30m"
  }
}

skill 返回結果後，助手：
1. 更新 task_state
2. 選出最優 3 個結果
3. 詢問使用者是否要比較或直接下單
4. 若使用者確認，則調用 create_order
5. 完成後總結訂單資訊

我把這個模板故意寫得偏工程化，因為我不想再看到那種「把 prompt 調一調就能上線」的幻覺。你要真想做成可用系統，就得把 skill、狀態、確認、回退都寫清楚。模型只是中間的大腦，不是全部。

如果你後面要繼續擴，我建議你再補三塊：一是審計日誌，二是權限策略，三是失敗恢復。沒有這三塊，Agent 很容易從「聰明」滑向「危險」。

來源和邊界：我拆的是這條知乎回答，不是官方白皮書

這篇拆解的直接來源是知乎問題「6月12日華為發布開源盤古 2.0 模型，如何評價 openPangu 2.0 ？」下的這段回答。原文重點放在鴻蒙 7、小藝 Agent、skill 暴露和上下文管理上，我這裡做的是工程化拆解和可複製模板，不是對華為官方技術細節的逐條復述。

如果你要繼續追原始材料，我建議把這條回答和華為相關開發文檔一起看，再對照 function calling 思路、tool use 文檔，你會更容易看出這類系統到底在往哪裡走。

上面關於系統切分、模板化寫法和實操建議，是我根據原文延伸出來的工程整理；原始觀點來自來源連結，其他部分是我自己的拆法。