How do I use Agent Sense?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Agent Sense what's my current time and location?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Agent Sense

by pepedd864

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Agent Sense（智能感知）- MCP Server

为 AI Agent 提供感知能力的 Model Context Protocol (MCP) 服务器。

💡 为什么需要 Agent Sense？

AI Agent 在处理问题时，往往缺乏对外部环境的感知能力。Agent Sense 让 AI 可以：

时效性研究 - 获取准确的当前时间，处理时间敏感的任务和分析
位置信息研究 - 基于 IP 地址获取地理位置，提供本地化的建议和服务
硬件环境分析 - 诊断系统性能问题，分析内存、磁盘、CPU 使用情况
环境报错分析 - 了解操作系统版本、架构等信息，提供针对性的解决方案

通过提供充足的环境上下文，Agent Sense 让 AI 的回复更加准确、更具针对性。

🎯 核心价值

提供充足的环境上下文

当 AI Agent 了解用户的环境信息时，可以：

✅ 更准确的时间判断 - "现在是几点？" "今天星期几？" "距离某个时间还有多久？"
✅ 本地化建议 - 根据用户所在地区提供相关的服务、资源和建议
✅ 精准的故障诊断 - "为什么我的电脑这么慢？" → 检查内存使用率 99%
✅ 针对性的解决方案 - 根据操作系统版本和架构提供正确的安装命令

功能特性

Agent Sense 提供以下感知工具：

1. 获取时间 (`get_time`)

获取当前时间信息，支持多种格式：

ISO 8601 格式
本地化格式
Unix 时间戳
时区信息
详细的年月日时分秒

2. 位置定位 (`get_location`)

基于 IP 地址获取地理位置信息：

国家、地区、城市
经纬度坐标
时区
ISP 信息

3. 系统信息 (`get_system_info`)

获取操作系统详细信息：

操作系统类型、版本、架构
主机名、内核版本
系统制造商和型号
系统运行时间

4. 硬件信息 (`get_hardware_info`)

获取硬件配置信息：

CPU 型号、核心数、频率
内存总量、使用情况
硬盘容量、使用情况
网络接口和 IP 地址
（详细模式）CPU 温度、电池状态、显卡信息

安装

npm install
npm run build

使用方法

开发模式

npm run dev

使用 MCP Inspector 测试

MCP Inspector 是一个交互式的调试工具，可以在浏览器中测试你的 MCP server：

npm run inspector

这会启动一个本地服务器，通常在 http://localhost:5173，你可以在浏览器中：

查看所有可用的工具
测试每个工具的调用
查看请求和响应
实时调试

生产模式

npm start

配置到 CherryStudio/Claude Desktop

在 MCP 配置文件中添加：

{
  "mcpServers": {
    "agent-sense": {
      "command": "node",
      "args": ["/path/to/agent-sense/dist/index.js"]
    }
  }
}

或者使用 npx（发布到 npm 后）：

{
  "mcpServers": {
    "agent-sense": {
      "command": "npx",
      "args": ["-y", "agent-sense"]
    }
  }
}

📝 实际应用场景

场景 1：性能诊断

用户: "我的电脑运行很慢，怎么回事？"
AI: 调用 get_hardware_info() → 发现内存使用率 99.72%
AI 回复: "你的内存使用率已达 99.72%（23.93GB/24GB），建议关闭一些应用程序释放内存。”

场景 2：时间敏感任务

用户: "帮我分析一下这个日志文件的错误"
AI: 调用 get_time() → 获取当前时间和时区
AI 回复: "根据日志时间戳（UTC）和你的本地时区（Asia/Shanghai），这个错误发生在 2 小时前...”

场景 3：本地化建议

用户: "推荐一些学习资源"
AI: 调用 get_location() → 发现用户在中国
AI 回复: "根据你的位置，推荐以下中文学习资源和国内可访问的平台...”

场景 4：环境特定解决方案

用户: "如何安装 Docker？"
AI: 调用 get_system_info() → macOS M3 芯片
AI 回复: "你使用的是 Apple Silicon (M3)，请使用以下命令安装 Docker Desktop for Mac (Apple Silicon)...”

工具使用示例

获取时间

{
  "name": "get_time",
  "arguments": {
    "format": "iso"
  }
}

获取位置

{
  "name": "get_location",
  "arguments": {
    "ip": "8.8.8.8"
  }
}

获取系统信息

{
  "name": "get_system_info",
  "arguments": {}
}

获取硬件信息

{
  "name": "get_hardware_info",
  "arguments": {
    "detailed": true
  }
}

跨平台支持

✅ 完全支持以下平台：

Windows (Windows 10/11)
macOS (10.15+)
Linux (Ubuntu, Debian, CentOS, Fedora 等主流发行版)

所有功能在三大平台上均可正常工作，包括：

✅ 时间获取 - 使用 Node.js 内置 API
✅ 位置定位 - 基于公网 IP 的地理定位
✅ 系统信息 - 跨平台系统信息获取
✅ 硬件信息 - 智能过滤各平台的虚拟接口和系统分区

技术栈

Node.js + TypeScript: 核心运行环境
@modelcontextprotocol/sdk: MCP 协议实现
systeminformation: 跨平台系统和硬件信息获取
public-ip: 公网 IP 获取
zod: 参数验证

开发

# 安装依赖
npm install

# 开发模式（热重载）
npm run dev

# 构建
npm run build

# 运行
npm start

提示词

本项目使用kiro + claude 4.5 + vibe coding开发

提示词如下

我想做一个 为 agent 提供 感知能力的 mcp server，名为“智能感知(agent-sense)”，它需要提供以下工具，1. 获取时间；2. 位置定位；3. 系统信息(操作系统版本，架构)；4. 硬件信息(CPU 型号，内存大小、硬盘大小、IP地址)，请你帮我设计一个可行的方案，必要查询文档或者信息时，可使用对应的mcp server。技术栈方面，我希望使用 nodejs + typescript

Available Tools

4 tools

get_hardware_infoA

【建议调用】获取用户硬件配置和实时使用情况。

⚠️ 重要：不要假设用户的硬件配置，调用此工具获取准确的硬件信息和实时状态。

强制调用场景：

用户抱怨性能问题（"电脑慢"、"卡顿"、"运行慢"、"响应慢"）
诊断资源问题（"内存不足"、"磁盘空间"、"CPU占用高"）
用户询问配置信息（"我的配置"、"硬件信息"、"电脑配置"）
评估软件性能要求（"能运行XX吗"、"配置够吗"）
分析是否有足够资源运行某个程序
用户提到网络问题（获取网络接口信息）
需要了解用户硬件能力以提供针对性建议

返回信息：CPU型号/核心数/使用率、内存总量/使用率、磁盘容量/使用情况、网络接口/IP地址。详细模式：CPU温度、电池状态、显卡信息。

⚠️ 在诊断性能问题时必须调用此工具获取实时数据！

ParametersJSON Schema

Name	Required	Description	Default
`detailed`	No	是否返回详细信息（包括CPU温度、电池状态、显卡信息）

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (CPU, memory, disk, network info, with optional detailed mode for temperature, battery, GPU) and emphasizes the importance of real-time data for performance diagnosis. However, it lacks details on potential limitations like rate limits, error conditions, or data freshness, which would be helpful for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately front-loaded with the core purpose, but it includes repetitive warnings (e.g., multiple ⚠️ symbols and emphatic statements) and a lengthy list of scenarios that could be more streamlined. While informative, some sentences could be condensed without losing clarity, making it slightly verbose for its content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (hardware diagnostics with real-time data) and lack of annotations or output schema, the description does a good job covering purpose, usage, and return values. It specifies what information is returned in both basic and detailed modes. However, it doesn't describe the output format (e.g., structured data vs. text) or potential errors, leaving some gaps for the agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for its single parameter 'detailed', so the baseline is 3. The description adds value by explaining what 'detailed mode' includes (CPU temperature, battery status, graphics card info), providing context beyond the schema's boolean description. This compensates meaningfully, though it doesn't cover edge cases or default behavior implications.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: '获取用户硬件配置和实时使用情况' (get user hardware configuration and real-time usage). It clearly distinguishes from siblings like get_location, get_system_info, and get_time by focusing specifically on hardware metrics (CPU, memory, disk, network) rather than location, general system info, or time.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive, explicit guidance on when to use this tool, listing 7 specific scenarios (e.g., performance complaints, resource diagnosis, configuration inquiries). It also includes strong imperatives like '强制调用场景' (mandatory call scenarios) and '必须调用' (must call), clearly directing the agent to prioritize this tool over alternatives in relevant contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_locationA

【建议调用】根据IP地址获取用户的真实地理位置信息。

⚠️ 重要：不要假设用户的位置，调用此工具获取准确的地理信息。

强制调用场景：

用户询问位置相关问题（"我在哪里"、"我的位置"）
需要提供本地化建议（推荐服务、资源、网站、学习平台）
讨论地区特定话题（天气、时差、当地服务、可访问性）
提供安装指令、下载链接时（不同地区可能有不同的镜像源）
推荐内容时（语言、文化、法规差异）

返回信息：国家、地区、城市、经纬度、时区、ISP等完整地理位置信息。

⚠️ 在提供地区特定建议前，应主动调用此工具确认用户位置！

ParametersJSON Schema

Name	Required	Description	Default
`ip`	No	IP地址（可选，不提供则自动获取用户当前公网IP）

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it returns comprehensive location data (country, region, city, coordinates, timezone, ISP), emphasizes accuracy over assumptions, and mandates proactive calls in specific scenarios. However, it lacks details on rate limits, error handling, or authentication needs, which would be helpful for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by important warnings and detailed usage scenarios. Every sentence adds value, such as clarifying return information and emphasizing proactive calls. It could be slightly more concise by reducing repetition in the mandatory scenarios, but overall it's efficient and easy to follow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (location lookup with no output schema and no annotations), the description is mostly complete. It covers purpose, usage guidelines, return data, and behavioral expectations. However, it lacks details on output format (e.g., JSON structure), error cases, or limitations (e.g., accuracy for VPNs), which would enhance completeness for an agent invoking this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the 'ip' parameter documented as optional (defaulting to the user's public IP if not provided). The description adds value by reinforcing this in the context of the tool's purpose ('IP地址（可选，不提供则自动获取用户当前公网IP）'), but it doesn't provide additional semantics beyond what the schema already covers, such as IP format validation or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: '根据IP地址获取用户的真实地理位置信息' (get real geographic location information based on IP address). It specifies the exact resource (geographic location) and distinguishes it from sibling tools like get_hardware_info, get_system_info, and get_time by focusing on location rather than hardware, system, or time data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool, listing five '强制调用场景' (mandatory call scenarios) such as when users ask about their location, need localized recommendations, discuss region-specific topics, provide installation instructions, or recommend content. It also emphasizes not to assume user location and to call this tool proactively for region-specific advice, offering clear alternatives (use this instead of assuming).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_system_infoA

【建议调用】获取用户操作系统的详细信息。

⚠️ 重要：不要假设用户的操作系统，调用此工具获取准确的系统信息。

强制调用场景：

用户询问系统信息（"我的系统"、"操作系统版本"）
提供安装/配置指令前（不同系统命令不同）
诊断系统相关问题或错误
讨论软件兼容性、系统要求
用户提到"安装"、"配置"、"运行"、"部署"任何软件
提供命令行指令时（Windows/macOS/Linux 命令不同）

返回信息：操作系统类型（Windows/macOS/Linux）、版本号、架构（x64/ARM/ARM64）、内核版本、主机名、系统运行时间等。

⚠️ 在提供技术建议前必须调用此工具，确保指令适用于用户的系统！

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (OS type, version, architecture, kernel version, hostname, uptime) and emphasizes its importance for providing accurate technical advice. However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions, which would be helpful for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately front-loaded with the core purpose, but contains some redundancy in the usage scenarios list and uses multiple warning symbols (⚠️) that could be streamlined. While all content is relevant, the structure could be more efficient with better grouping of similar scenarios and less repetitive emphasis.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (0 parameters, no output schema, no annotations), the description provides strong contextual completeness by clearly explaining what information the tool returns and when to use it. The main gap is the lack of output schema, which means the description must fully explain return values - it does this adequately by listing the specific data points returned, though a structured output schema would be more precise.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the baseline would be 4 even with no parameter information in the description. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose and usage guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as '获取用户操作系统的详细信息' (get detailed information about the user's operating system), which is a specific verb+resource combination. It distinguishes itself from sibling tools like get_hardware_info, get_location, and get_time by focusing specifically on operating system details rather than hardware, location, or time information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus making assumptions, listing six specific scenarios including user inquiries about system info, before providing installation/configuration instructions, diagnosing system issues, discussing compatibility, when users mention installation/configuration/running/deployment, and before providing command-line instructions. It also includes a strong warning not to assume the user's OS and to call this tool for accurate information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_timeA

【必须调用】获取用户环境的实时时间信息。

⚠️ 重要：你的训练数据和系统提示中的时间信息可能不准确或过时，必须调用此工具获取用户的真实当前时间。

强制调用场景（必须调用，不要依赖你的知识）：

用户提到"现在"、"今天"、"最近"、"这周"、"这个月"、"今年"等时间词
用户询问时间相关的事件、新闻、趋势（如"最近有什么AI大事件"）
需要判断某个日期是过去还是未来
分析时间敏感的数据（日志、事件、截止日期）
任何需要知道"当前时间"才能准确回答的问题

返回信息：用户本地时间、UTC时间、时区、Unix时间戳、完整的年月日时分秒、星期等。

⚠️ 不要假设你知道当前时间，必须调用此工具！

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	时间格式：'iso' (ISO 8601), 'locale' (本地化), 'unix' (Unix时间戳)	iso

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by stating it returns real-time information (not cached or estimated), lists the specific data returned (local time, UTC, timezone, Unix timestamp, full date/time, weekday), and emphasizes the critical constraint that the agent must call it instead of using internal knowledge. It doesn't mention error handling or rate limits, but covers the core behavioral aspects well for a read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and well-structured, with clear sections (purpose, warnings, usage scenarios, return information). Every sentence adds value, such as the critical warning about inaccurate training data and the list of mandatory call scenarios. It could be slightly more concise by reducing repetition of '必须调用' (must call), but overall it's efficient and front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one optional parameter) and lack of annotations/output schema, the description is highly complete. It thoroughly explains the tool's purpose, when to use it, behavioral constraints, and what information it returns. For a simple time-fetching tool, this provides all necessary context for an agent to invoke it correctly, compensating for the absence of structured metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the single parameter 'format' fully documented in the schema (including enum values and default). The description doesn't add any parameter-specific information beyond what's in the schema, but it implicitly reinforces the tool's purpose of returning time data in various formats. Since schema coverage is high, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose as '获取用户环境的实时时间信息' (get real-time time information of the user's environment), which is a specific verb+resource combination. It clearly distinguishes from sibling tools like get_hardware_info, get_location, and get_system_info by focusing exclusively on time data rather than hardware, location, or broader system information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit and detailed guidance on when to use this tool, listing multiple mandatory scenarios (e.g., when users mention time-related words, ask about time-sensitive events, or need to determine past/future dates). It also explicitly states when not to use alternatives by emphasizing '必须调用此工具' (must call this tool) and warning against relying on the agent's own knowledge or training data for time information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Oct 16, 2025
- First observedget_hardware_info
- First observedget_location
- First observedget_system_info
- First observedget_time

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-04-18 08:25 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: get_hardware_info retrieves hardware metrics, get_location provides geographical data, get_system_info fetches OS details, and get_time obtains temporal information. The descriptions explicitly differentiate their domains (hardware, location, system, time), making misselection unlikely.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'get_' prefix (get_hardware_info, get_location, get_system_info, get_time). This uniform naming convention makes the set predictable and easy to understand, with no deviations in style or structure.

Tool Count4/5

With 4 tools, the count is reasonable for a server focused on gathering user environment data. It covers key areas (hardware, location, system, time) without being overly sparse or bloated, though minor additions like network diagnostics or user preferences could enhance scope without being necessary.

Completeness4/5

The tool set provides comprehensive coverage for retrieving user environment data, with no obvious gaps in the core areas of hardware, location, system, and time. Minor gaps might include tools for user preferences or application-specific data, but the existing tools support essential workflows for context-aware assistance.

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

tokenguard-mcp A
io.github.eltociear
Real-world data for agents: air quality, geocoding, quakes, holidays, web search
Search Location Services Open Data
911
FingerprintOAuth
io.github.fingerprintjs
Device intelligence for AI agents: Fingerprint events, smart signals, and API key management.
Security Autonomous Agents AI & Machine Learning
24
GroundAPI
io.github.qingkongzhiqian
Real-time data API for AI Agents: stocks, weather, forex, logistics, search, scrape, news, IP.
Search Web Scraping Finance
2
Agent News by The Agent Times A
com.theagenttimes
Verified, sourced, real-time intelligence layer for AI agents.
Search Research & Data
20229

Agent Sense（智能感知）- MCP Server

💡 为什么需要 Agent Sense？

🎯 核心价值

提供充足的环境上下文

功能特性

1. 获取时间 (get_time)

2. 位置定位 (get_location)

3. 系统信息 (get_system_info)

4. 硬件信息 (get_hardware_info)

安装

使用方法

开发模式

使用 MCP Inspector 测试

生产模式

配置到 CherryStudio/Claude Desktop

📝 实际应用场景

场景 1：性能诊断

场景 2：时间敏感任务

场景 3：本地化建议

场景 4：环境特定解决方案

工具使用示例

获取时间

获取位置

获取系统信息

获取硬件信息

跨平台支持

技术栈

开发

提示词

Available Tools

TDQS

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Resources

Related MCP Connectors

1. 获取时间 (`get_time`)

2. 位置定位 (`get_location`)

3. 系统信息 (`get_system_info`)

4. 硬件信息 (`get_hardware_info`)