华为 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 文档，你会更容易看出这类系统到底在往哪里走。