给智能体递上工具箱
AutoGod（自动化助手）技术博客 · 工具调用浪潮下，一台手机就是一套工具集
2026 年智能体领域最深刻的变化，是大家突然不再比拼谁的模型更会聊天，而是比拼谁能"调用工具"。从模型上下文协议到智能体之间的协作标准，整个行业都在做同一件事：给聪明的大脑配上一双能干活的手。道理很简单，再强的模型被关在对话框里，也只能输出文字；一旦它能调用外部能力，它才能真正改变世界。AutoGod（自动化助手）在这场浪潮里的位置很特别------它把一台安卓手机的全部能力，变成了智能体随手可取的工具，而且这些工具就运行在设备本地。
智能体最缺的不是脑子，是手
早期的大模型像一个博览群书却被捆住手脚的顾问：你问它任何问题，它都能对答如流，可你让它"帮我把屏幕上这个弹窗关掉"，它只能告诉你应该怎么做，而无法替你动手。模型本身并不直接拥有操作设备、访问文件、发起请求的能力，这些能力必须由外部环境以"工具"的形式提供给它。所谓工具调用，说的就是模型在需要时，按约定格式请求外部环境执行某个函数，再把结果拿回来继续推理。
这一年行业里涌现出一批协议和标准，核心思想高度一致：用一种统一的方式描述"有哪些工具、每个工具做什么、需要什么参数"，让模型和工具之间解耦。工具的提供方不必关心调用它的是哪个模型，模型的开发方也不必为每一种能力单独适配。标准化带来的直接好处是生态可以自由生长，工具越攒越多，智能体能完成的任务边界就越推越宽。
在手机这个场景里，工具调用的意义尤为实在。一台安卓设备本身就蕴藏着丰富的能力：点击、滑动、输入、识别文字、检测目标、读写文件、访问网络、操作数据库、生成二维码。过去这些能力散落在不同的接口和权限后面，普通开发者很难把它们组织起来。AutoGod 把这些能力统一收进脚本运行时，再用一套极简的工具注册机制暴露出去，于是任何会发 JSON 的智能体，都能在这台手机上动手。
一个工具长什么样
要把能力变成工具，先要想清楚一个工具该如何描述。一个完整的工具描述至少包含三样东西：一个见名知意的名字，一段说明它用途和时机的描述，以及它接受的参数约定。模型在选择工具时，靠的正是这些文字信息来判断"此刻该不该用它、该传什么参数"。描述写得越清楚，模型挑得越准。
在 AutoGod 的脚本里，我们可以用一个极简的注册表来承载这些工具。注册表本质上就是一张表，把工具名映射到它的描述和真正执行的函数上，再提供注册、查询和调用三个动作。ES5 的十几行代码就能搭出这个骨架。
javascript
// 工具注册表：统一管理工具的描述与执行函数
function ToolRegistry() {
this.tools = {};
}
// 注册一个工具：名字 + 描述 + 处理函数
ToolRegistry.prototype.register = function (name, description, handler) {
this.tools[name] = { description: description, handler: handler };
};
// 取出所有工具的描述，供模型挑选
ToolRegistry.prototype.describe = function () {
var list = [];
for (var name in this.tools) {
if (this.tools.hasOwnProperty(name)) {
list.push({ name: name, description: this.tools[name].description });
}
}
return list;
};
// 按名字调用工具，并把结果返回
ToolRegistry.prototype.call = function (name, args) {
if (!this.tools.hasOwnProperty(name)) {
return { ok: false, error: '工具不存在：' + name };
}
try {
return { ok: true, result: this.tools[name].handler(args || {}) };
} catch (e) {
return { ok: false, error: e.message };
}
};这个注册表体现的正是工具调用协议的精髓：描述与实现分离。模型看到的只是名字和说明，真正干活的函数藏在后面，二者通过约定的参数结构对接。理解了这一层，你就掌握了当下所有智能体工具框架的共同内核，剩下的只是把具体能力一件件注册进去。
先注册三件最常用的家什
骨架搭好，接下来把手机上最常用的能力注册成工具。不必贪多，先从三件高频家什开始：按文字找到并点击目标、读取当前屏幕上的关键信息、启动指定应用。这三件工具几乎能撑起一大半日常自动化任务，后续需要什么再按需扩充。
javascript
var reg = new ToolRegistry();
// 工具一：按文字找到目标并点击
reg.register('clickByText', '当需要点击屏幕上某个文字按钮时使用，参数 text 为按钮文字', function (args) {
var node = $act.selector().text(args.text).findFirst();
if (node == null) { return '未找到：' + args.text; }
$act.click(node);
return '已点击：' + args.text;
});
// 工具二：读取屏幕上所有可见的文字元素
reg.register('readScreen', '当需要了解当前屏幕上有哪些内容时使用，无需参数', function () {
var nodes = $act.selector().clickable(true).find();
var texts = [];
for (var i = 0; i < nodes.size(); i++) {
var n = nodes.get(i);
if (n.visible === true && (n.text || n.desc)) {
texts.push(n.text || n.desc);
}
}
return texts;
});
// 工具三：启动指定应用
reg.register('openApp', '当需要打开某个应用时使用，参数 pkg 为应用包名', function (args) {
$app.launch(args.pkg);
return '已尝试启动：' + args.pkg;
});注册的过程，其实就是在给智能体描述这个世界的边界。每一个工具的说明都在告诉模型"我能帮你做什么、什么时候该找我"。当这些工具和 AutoGod 的底层模块一一对应，模型面对的就不再是一块只能看不能碰的屏幕，而是一个可以被理解、被操作的环境。值得注意的是，这些工具的执行全部发生在设备本地，点击不经过第三方服务器，数据不必离开手机。
让模型自己挑工具
工具就位，最后一步是让模型在面对任务时自主选择。做法是把工具清单和当前任务一起发给模型，要求它返回一个结构化的工具调用请求，脚本解析后从注册表中取出对应工具执行，再把结果反馈给模型。模型据此判断任务是否完成，或是否需要继续调用下一个工具。
javascript
// 让模型根据任务挑选工具，并在本地执行
function useTools(goal) {
var res = $http.post({
url: 'https://api.example.com/chat/completions',
readTimeout: 60,
head: { 'Content-Type': 'application/json', 'Authorization': 'Bearer ' + '你的密钥' },
data: {
model: 'your-model',
messages: [
{ role: 'system', content: '你是设备操作助手，只输出JSON，格式为{"tool":"工具名","args":{}}' },
{ role: 'user', content: '可用工具：' + JSON.stringify(reg.describe()) + '；任务：' + goal }
],
stream: false
}
});
var choice = JSON.parse(res.json().choices[0].message.content);
var output = reg.call(choice.tool, choice.args);
log('工具执行结果：' + JSON.stringify(output));
return output;
}
useTools('打开签到应用，找到领取按钮并点击');这一轮调用完成的事情，正是当下智能体工具使用的标准动作：模型负责理解任务、选择工具、组织参数，环境负责安全地执行并回传结果。模型不再需要知道点击底层走的是无障碍还是触摸驱动，也不需要关心应用如何启动，这些复杂性都被工具封装在了本地。对开发者而言，新增能力的成本低到只需再写一个 register，智能体的技能树便随之生长。
工具不是越多越好
工具调用带来自由，也带来新的治理课题。工具并非越多越好：当清单膨胀到几十上百个，模型反而容易在相似工具之间犹豫、误选，提示词变长还会推高每次调用的成本。成熟的做法是按场景动态裁剪工具集，只把当前任务可能用到的工具交给模型，并为工具命名建立清晰的领域划分，让模型一眼就能分辨该找谁。
参数校验同样不可省略。模型生成的参数属于不可信输入，工具在执行前应当检查参数是否齐全、格式是否合法、取值是否在允许范围内，尤其是点击、删除、发送这类会产生真实后果的动作。把校验逻辑写进每个工具的入口，等于给智能体的行为加了一道护栏：模型可以提出请求，但只有符合规则的请求才会被执行。对于不可逆的高风险操作，还可以在工具内部要求二次确认，把最终决定权留给人。
工具的可观测性也值得设计。每一次工具调用的名字、参数、结果和耗时都应留下结构化记录，出现误操作时可以完整还原当时的决策链。这些日志既方便调试，也是商业交付中向客户证明系统可控可信的依据。工具调用让智能体更强，而日志和校验让这份强大变得可以托付。
AutoGod 就是端侧的工具服务器
把视角拉高，你会发现 AutoGod 在这套架构里扮演的角色，正是一个运行在手机上的轻量工具服务器。它把设备的感知、动作、文件、网络、数据库等能力组织成一个个可调用的工具，智能体无论来自云端大模型还是本地脚本，都能用统一的方式发现并调用它们。区别在于，传统的工具服务器往往部署在远端，而 AutoGod 的工具就在你手里这台设备上，延迟更低、断网可用、数据不出端。
这对个人开发者意味着极低的创造门槛：你不必搭建后端、不必申请一堆接口，用 ES5 把现成能力注册成工具，就能做出一个能听懂任务、还能亲手完成的手机智能体。对企业客户，这意味着自动化能力可以像搭积木一样复用和扩展，新业务上线时不必从零开发，只需在注册表里添几件新工具，既快又稳，还天然满足数据本地化的合规要求。
智能体的竞争正在从"谁更会说"转向"谁更会做"，而做的能力，本质上是工具的丰富度与执行的确定性。当别人还在为如何给模型接上一个又一个外部服务而疲于奔命时，AutoGod 已经把一整台手机的能力，打包成了智能体随手可取的工具箱。递工具这一步，看似不起眼，却是让智能体从对话框走进现实世界的关键一跃。