鸿蒙 App 如何实现 Planner?一文讲透 Agent 的任务规划引擎


大家好,我是 子玥酱,一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂,目前在某国企负责前端软件研发相关工作,主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验,日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案,
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向:前端 / 跨端 / 小程序 / 移动端工程化
内容平台:掘金、知乎、CSDN、简书
创作特点:实战导向、源码拆解、少空谈多落地
文章状态:长期稳定更新,大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”,而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍,希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端,或准备长期走前端这条路
📚 关注我,第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源(工程化 / 框架 / 跨端 / 面试 / 架构)
💡 一起把技术学“明白”,也用“到位”
持续写作,持续进阶。
愿我们都能在代码和生活里,走得更稳一点 🌱
文章目录
引言
很多开发者刚开始做 AI Agent 时,都会有一个误区:
LLM 足够强
↓
直接输出答案
↓
任务完成
但实际项目里很快会发现,用户说:
帮我安排明天的学习计划
这并不是一个简单问题。系统需要:
分析课程
↓
分析空闲时间
↓
生成学习计划
↓
创建提醒
↓
同步日历
如果直接让模型一步输出:
最终结果
往往会出现:
幻觉
遗漏步骤
执行顺序错误
工具调用失败
所以在 Agent 系统中,真正决定智能体上限的往往不是 LLM。
而是:
Planner(规划器)
Planner 的本质,就是把用户目标(Goal)转换成可执行任务(Task)。
很多团队做 Agent Runtime 时最先实现的是:
Memory
Tool Calling
但最后发现:
没有 Planner,Agent 永远只是高级聊天机器人。
一、什么是 Planner
Planner 可以理解成:
Agent 的前额叶
负责:
目标分析
任务拆解
执行顺序规划
依赖关系管理
动态重规划
例如,用户:
帮我规划东京三日游
Planner 不会直接回答,而是生成:
Task1 查询天气
Task2 查询酒店
Task3 查询景点
Task4 规划路线
Task5 生成行程
形成:
Goal
↓
Task Graph
↓
Execution
这也是现代 Agent 框架的核心思想。Planner 的职责是将复杂目标拆解为多个可执行步骤,而不是一次性生成最终答案。
二、为什么 Agent 必须有 Planner
传统 ChatBot:
Question
↓
Answer
而 Agent:
Goal
↓
Plan
↓
Action
↓
Feedback
例如,用户:
帮我订机票
实际上涉及:
查询航班
↓
价格比较
↓
选择航班
↓
填写信息
↓
提交订单
如果没有 Planner:
LLM 直接调用工具
容易导致:
1、工具乱调用
重复查询
重复下单
2、状态错乱
任务执行顺序错误
3、上下文爆炸
Prompt 越来越长
因此:
Planner 本质上是 Agent Runtime 的任务编排中心。
三、Planner 在 Agent Runtime 中的位置
推荐架构:
User
↓
Intent
↓
Planner
↓
Task Graph
↓
Scheduler
↓
Executor
↓
Tools
↓
Feedback
这里可以形成完整闭环:
Intent
负责理解目标
Planner
负责拆解目标
Scheduler
负责调度任务
Executor
负责执行任务
四、Planner 的核心输入
Planner 不是凭空规划,它需要多个信息源。
用户目标
例如:
帮我学习鸿蒙开发
当前上下文
例如:
用户是新手
每天2小时
目标3个月入门
Memory
历史记录:
已经学习ArkTS
已经学习ArkUI
Tool 能力
Planner 必须知道:
系统有哪些工具
例如:
SearchTool
CalendarTool
CourseTool
最终形成:
Goal
+
Context
+
Memory
+
Tools
生成:
Plan
五、Task DAG 才是真正的 Planner
很多初学者认为规划就是:
Task1
↓
Task2
↓
Task3
实际上企业级 Planner 通常生成:
DAG
(Directed Acyclic Graph)
即:
TaskA
↙ ↘
TaskB TaskC
↘ ↙
TaskD
例如,查询天气和查询酒店完全可以并行。最后,生成旅行计划依赖前面结果。
这种结构比简单链路效率高得多。
六、Planner 的三种实现方式
方案一:Rule Planner
规则规划,例如:
if(intent=="travel"){
return [
"weather",
"hotel",
"transport"
]
}
优点:
快
稳定
可控
缺点:
扩展困难
适合:
端侧 Agent
方案二:LLM Planner
直接由模型规划,Prompt:
请把目标拆解为任务列表
输出:
[
"查询天气",
"查询酒店",
"规划路线"
]
优点:
灵活
缺点:
不可预测
方案三:Hybrid Planner
企业最常见,架构:
Rule Engine
+
LLM Planner
流程:
常见任务
↓
规则规划
复杂任务
↓
LLM规划
这样:
成本低
稳定性高
扩展性好
七、鸿蒙 App 中如何落地 Planner
推荐目录:
src
├── planner
│ ├── planner.ts
│ ├── graph.ts
│ ├── executor.ts
│ ├── task.ts
│ └── strategy.ts
Task 定义:
export interface Task {
id:string
name:string
deps:string[]
}
Planner:
class Planner {
build(goal:string):Task[]{
return []
}
}
生成 Task Graph 供 Scheduler 使用。
八、Planner 与 Scheduler 的区别
很多人容易混淆,实际上:
Planner
负责:
想做什么
例如:
学习计划
拆解:
课程分析
↓
计划生成
↓
创建提醒
Scheduler
负责:
什么时候做
例如:
优先级
资源分配
重试机制
关系:
Planner
↓
Task DAG
↓
Scheduler
↓
Execution
类似产品经理 ➡️ 项目经理的关系。
九、为什么 Planner 会成为未来 App 的核心
传统 App:
Page
↓
Button
↓
Function
未来 App:
Goal
↓
Planner
↓
Task
↓
Agent
↓
Tool
入口已经变化。
过去:
用户找功能
未来:
用户描述目标
系统必须具备:
目标理解
任务拆解
动态规划
持续执行
而这些能力的核心就是 Planner。
事实上,无论是学术界的 LLM Planner、HTN Planner,还是端侧 Planner-Action 架构,本质都在解决同一个问题:
如何把自然语言目标转换成结构化执行计划。
十、HarmonyOS AI Native 的 Planner 架构
结合前面几篇 Runtime 系列文章,一个完整的鸿蒙 AI Native 架构可能会变成:
Goal
↓
Intent
↓
Planner
↓
Task DAG
↓
Scheduler
↓
Agent Runtime
↓
┌──────────────┐
↓ ↓
Memory Tools
↓ ↓
State Center
↓
ArkUI
特点:
Goal Driven
Task Driven
State Driven
Agent Driven
越来越像:
一个小型操作系统
而不是:
传统 App
总结
如果用一句话理解 Planner:
Planner 不是让 Agent 更聪明,而是让 Agent 知道下一步该做什么。
过去:
Question
↓
Answer
未来:
Goal
↓
Planner
↓
Task DAG
↓
Execution
↓
Feedback
从:
ChatBot
逐渐演化成:
Agent Runtime
而在未来的鸿蒙 AI Native 应用里,真正决定 Agent 上限的,可能不是模型参数规模。
而是:
Planner 是否足够优秀。
更多推荐

所有评论(0)