以前开发一个工具类应用，我通常会把功能入口设计得非常清楚。比如记账应用有新增账单、查看统计、筛选记录，用户想完成某件事，就必须先找到对应的按钮，再进入页面操作。

这种交互方式没什么问题，但功能一多，页面就容易越来越复杂。最近研究 HarmonyOS 7 的智能体能力时，我开始思考一个问题：如果用户直接说出自己的需求，应用能不能少一些菜单，多一些理解？

比如用户说：“帮我看看这个月餐饮花了多少钱。”应用真正需要做的，并不是简单地回复一句话，而是理解用户意图、查询账单数据，再把结果交给用户。

我觉得，这才是 AI 与传统应用结合时值得关注的地方。

先把自然语言转成明确的业务任务

我会先把业务逻辑独立出来。无论用户通过按钮还是 AI 入口发起请求，最终都调用同一个统计函数。这样可以避免把 AI 逻辑和原有业务代码耦合在一起。

interface Expense {
  category: string;
  amount: number;
  date: string;
}
 
function sumCategory(
  expenses: Expense[],
  category: string,
  month: string
): number {
  let total: number = 0;
 
  for (const item of expenses) {
    if (item.category === category &&
      item.date.startsWith(month)) {
      total += item.amount;
    }
  }
 
  return total;
}

这里我没有让模型直接计算金额，而是让它负责理解用户的表达，业务代码负责执行确定性的计算。

假设用户问“最近一个月吃饭花了多少”，系统需要先明确时间范围，再把“吃饭”映射到应用中真实存在的餐饮分类。否则，模型即使回答得很流畅，也可能因为分类映射错误而给出错误结果。

Agent 不是聊天框换了个皮肤

真正接入 HarmonyOS 7 智能体体系后，我更关注的是能力如何被系统发现和调用。

按照官方 Skill 开发模式，开发者需要描述能力的触发场景、输入参数和返回值，再通过 ArkTS 入口脚本连接应用内的业务实现。系统智能体可以据此完成意图与能力的匹配。

这里可以先用一个业务适配接口表达调用关系：

interface ExpenseQuery {
  category: string;
  month: string;
}
 
interface ExpenseResult {
  category: string;
  month: string;
  total: number;
}
 
// 业务层示意接口，并非系统 AI API
async function queryExpense(
  query: ExpenseQuery
): Promise<ExpenseResult> {
  const total = sumCategory(
    await loadExpenses(),
    query.category,
    query.month
  );
 
  return {
    category: query.category,
    month: query.month,
    total: total
  };
}

其中 loadExpenses() 代表应用已有的数据读取方法。实际项目中，需要根据自己的数据库或数据服务实现它。

我认为最容易踩的坑：让 AI 越权做决定

金额计算、订单提交、支付、删除数据等操作，都不应该只依赖模型的自然语言输出。涉及重要操作时，应该有明确的参数校验、权限检查和用户确认。

比如“帮我删掉重复账单”，AI 可以负责找出疑似重复记录，但最终删除之前，应用仍应展示具体记录，让用户确认。

对我来说，HarmonyOS 7 的 Agent 能力并不是让开发者把所有逻辑交给 AI，而是让自然语言成为新的业务入口。真正可靠的应用，仍然需要一套稳定、可测试、可追踪的业务代码。当 AI 负责理解需求，应用负责把事情做对，这种分工才有实际价值。