HarmonyOS鸿蒙Next中接口有定义，但是还是会报Object literal must correspond to some explicitly declared class or interface (arkts-no-untyped-obj-literals)

这个报错的关键点不是你这层 Tool 接口本身，而是 ArkTS 对对象字面量的限制比 TS 严很多。

结论

你这段：

const toolItem: Tool = {
  type: 'function',
  function: functionDefinition
};

在 TypeScript 里通常没问题，但在 ArkTS 里，对象字面量的每一层都必须能落到“显式声明的 class 或 interface”上。 所以即使 Tool 已经声明了，只要下面任意一层不是 ArkTS 认可的显式类型，还是会报：

• Object literal must correspond to some explicitly declared class or interface
• arkts-no-untyped-obj-literals

最常见真正原因

通常不是 Tool 有问题，而是下面这些地方有一个没满足 ArkTS 规则：

1. ToolFunction 不是 interface/class

比如你如果是这样定义的：

type ToolFunction = {
  name: string;
  description: string;
}

在 ArkTS 里这种就很容易触发问题。

更稳妥的是改成：

interface ToolFunction {
  name: string;
  description: string;
}

或者直接用 class。

2. functionDefinition 本身是匿名对象字面量

例如你前面如果这么写：

const functionDefinition = {
  name: 'xxx',
  description: 'yyy'
};

即使后面赋给 Tool.function，ArkTS 也可能不认。

要改成：

const functionDefinition: ToolFunction = {
  name: 'xxx',
  description: 'yyy'
};

但如果 ToolFunction 内部还有嵌套对象，嵌套对象也要继续显式声明。

3. ToolFunction 里面还有嵌套匿名对象

例如：

interface ToolFunction {
  name: string;
  parameters: {
    type: string;
    properties: object;
  };
}

这种在 ArkTS 里也容易炸。

要拆开

interface ToolParameters {
  type: string;
  properties: ToolProperties;
}

interface ToolProperties {
  [key: string]: string; // 如果 ArkTS 版本支持这样写
}

interface ToolFunction {
  name: string;
  parameters: ToolParameters;
}

更稳的是继续拆成明确字段，不要大量依赖 object、匿名对象类型、复杂索引签名。

你这里最值得先检查的点

你贴出来的 Tool 这一层其实没毛病。 真正应该去看的是：

• ToolFunction 是怎么定义的
• functionDefinition 是怎么声明的
• ToolFunction 里面有没有：
  • object
  • 匿名对象类型
  • type xxx = { ... }
  • Record<string, any>
  • any
  • unknown
  • 联合类型
  • 泛型包装对象

这些在 ArkTS 里都很容易引出这个错。

推荐改法 1：全部改成 interface + 显式类型

比如这样：

interface ToolParameters {
  type: string;
}

interface ToolFunction {
  name: string;
  description: string;
  parameters: ToolParameters;
}

interface Tool {
  type: string;
  function: ToolFunction;
}

const functionDefinition: ToolFunction = {
  name: 'demo',
  description: 'demo desc',
  parameters: {
    type: 'object'
  }
};

const toolItem: Tool = {
  type: 'function',
  function: functionDefinition
};

const tools: Tool[] = [toolItem];

如果这里还报错，那基本就说明 parameters 这一层还要继续拆。

推荐改法 2：直接改成 class

ArkTS 对 class 往往最稳。

class ToolParameters {
  type: string = '';

  constructor(type: string) {
    this.type = type;
  }
}

class ToolFunction {
  name: string = '';
  description: string = '';
  parameters: ToolParameters = new ToolParameters('');

  constructor(name: string, description: string, parameters: ToolParameters) {
    this.name = name;
    this.description = description;
    this.parameters = parameters;
  }
}

class Tool {
  type: string = '';
  function: ToolFunction = new ToolFunction('', '', new ToolParameters(''));

  constructor(type: string, func: ToolFunction) {
    this.type = type;
    this.function = func;
  }
}

const functionDefinition = new ToolFunction(
  'demo',
  'demo desc',
  new ToolParameters('object')
);

const toolItem = new Tool('function', functionDefinition);
const tools: Tool[] = [toolItem];

如果你是做模型参数、JSON 结构、工具声明这类数据，ArkTS 下用 class 往往比 type/interface + 对象字面量更省心。

还有一个高频坑

不要用 object

像这种：

interface ToolFunction {
  parameters: object;
}

在 ArkTS 里非常容易埋雷。

建议改成明确接口：

interface ToolParameters {
  type: string;
  properties: string;
}

哪怕先把结构写死，也比 object 稳。

为什么 AI 会给你死循环

因为这是典型的：

• TypeScript 写法没问题
• 但 ArkTS 编译规则更严格
• AI 按 TS 思路一直重复修正
• 没抓到 ArkTS 的核心限制：禁止松散对象字面量/结构类型推导

所以它会一直在“加类型注解”这条路上打转，但真正要改的是：

• 去掉匿名对象类型
• 去掉 type = {} 风格
• 去掉 object/any/Record
• 必要时直接改 class

你现在可以直接这样排查

按这个顺序看：

1. ToolFunction 是否是 interface/class
2. functionDefinition 是否显式标注为 ToolFunction
3. ToolFunction 内部是否有匿名对象类型
4. 是否使用了 object / Record / any
5. 如果还有报错，直接改成 class

我对你这个 case 的判断

大概率不是这句有问题：

const toolItem: Tool = {
  type: 'function',
  function: functionDefinition
};

而是 ToolFunction 或它内部嵌套字段的定义方式不符合 ArkTS 规则。