# 让写代码的 AI 听见 Android 的反馈：nl2sh 的 MCP、A2A 与设备开发闭环

让 AI 修改代码，已经是很多开发者的日常。

但到了 Android 上，代码写完只是开始。电脑上的测试通过了，手机上可能遇到权限拒绝；文件已经推送，后台进程却还在运行旧版本；模型说“已经完成”，真正的工具调用可能失败了。

如果这些信息仍靠人手动收集、复制、解释，AI 编程就会停在一个尴尬的位置：它可以迅速提出修改，却很难确认修改在设备上是否有效。

最近，nl2sh 连续完成了一组 MCP、A2A 和设备开发流程的更新。目标很具体：**让开发端 AI 能拿到 Android 上的真实执行证据，再把这些证据用于下一次修改和回归。**

![](https://developer.qcloudimg.com/http-save/yehe-2988206/8b599d8f87065407ed0c4665a1f8e4cd.png)


## 01｜先让 Android 自己提供能力

nl2sh 是运行在 Android 原生 shell 环境中的多轮 Tool Calling Agent。核心以单个 Rust 可执行文件交付，提供 TUI、Web 和 CLI，支持 Android API 26 及以上版本，覆盖 ARM64、ARMv7 和 x86_64。

它可以连接配置好的模型，通过设备、文件、网络、UI 等工具完成任务。模型给出调用意图，设备端负责参数检查、风险评估、确认和执行。

这次协议层更新，把 MCP 和 A2A 直接放进了这个原生程序。

此前的主机侧 Python/ADB 网关被移除。现在，MCP 客户端直接连接设备上的协议服务，工具调用在设备内进入既有 Tool Runtime；A2A 请求则交给设备上的内置 Agent。

ADB 仍然承担安装、部署和调试传输的角色，也可以用于端口转发。但一次 MCP 工具调用已经不需要经过主机 Python 网关。

对使用者来说，部署单元更集中了：Android 上运行的那个 nl2sh，同时提供本地交互和设备协作接口。

## 02｜MCP 调工具，A2A 交任务

这两种协议在 nl2sh 中有清楚的分工。

**MCP 适合调用方已经知道要做什么的场景。**

例如，开发端可以先读取设备环境，再获取当前可用工具及参数 Schema，随后指定工具和参数执行。直接调用工具不需要设备端模型参与。

当前 MCP 接口包括设备盘点、工具目录、工具直调、屏幕读取、Agent 委派，以及任务查询和取消。几个常用入口是：

| 入口 | 用途 |
| --- | --- |
| `nl2sh_inspect` | 读取设备环境和运行构建身份 |
| `nl2sh_tools` | 获取当前可用工具及参数 Schema |
| `nl2sh_invoke` | 指定工具和参数，直接执行 |
| `nl2sh_read_screen` | 返回屏幕文本摘要与图像 |
| `nl2sh_ask` | 委派设备上的 Agent，并支持上下文续问 |

**A2A 适合把一个需要调查的问题交给设备 Agent。**

调用方可以提出目标、约束和需要的证据，由设备上的 Agent 决定怎样调用工具。长任务可以先取得 task ID，再查询状态；继续调查时复用 context ID，保留此前的对话上下文。

因此，开发端有两种协作方式：明确步骤时直接调工具；问题还不清楚时，委派设备 Agent 收集信息、提出解释和建议。MCP 的 `nl2sh_ask` 也提供后一种入口，并不是只有 A2A 才能使用设备 Agent。

这种分工让回归测试与开放式调查都能开展。前者关注相同步骤是否得到预期结果，后者帮助开发者理解设备上正在发生什么。

## 03｜连接之后，还要能启动、发现和收尾

协议接通以后，真实使用中很快会遇到更琐碎的问题：服务有没有启动？端口是否被占用？复制的令牌是不是上一次运行留下的？

后续几次提交就在补齐这些环节。

现在，可以通过配置选择让 MCP/A2A 随后台服务启动；相同开关也接入了直接启动的 TUI 和前台 Web。开关默认关闭，用户显式启用后，才会启动对应协议服务。

TUI 启动页和 Web 所有者连接窗口会展示经过运行身份校验的连接信息，包括运行版本、地址和令牌。普通状态输出会省略令牌，遗留的连接记录也不会被直接当作活动服务。

协议端口默认使用 8765。遇到端口占用时，服务会在相同监听地址上选择一个可用端口，并公告实际连接地址。它不会为了抢占端口而结束其他进程。

任务本身也有独立生命周期：设备端保存有界的私有任务记录，支持查询和协作取消；同一上下文中的 Agent 任务串行处理。服务重启后，未完成任务会被标记失败，不会自动重放。

这意味着，连接中断后可以先查询已知任务的状态，再决定下一步。特别是涉及修改的操作，不能因为客户端没有收到回复，就假定什么都没发生并重新执行。

## 04｜给 Codex 加上一套设备验证流程

有了设备接口，接下来要解决的是开发协作。

这次新增的仓库级 `nl2sh-device-lab` skill，配合主机侧 `scripts/device_lab.py`，把操作组织成一个可重复的流程：

1. 确认源码快照与设备当前运行的构建身份。
2. 获取环境和工具目录，运行基线案例并保存证据。
3. 对照源码分析问题，明确哪些是事实、哪些是假设。
4. 修改源码、运行检查，交叉编译对应 Android 架构。
5. 通过独立 ADB 通道部署，重新发现连接并核对运行身份。
6. 执行同一案例，比较修改前后的断言和环境。

**Codex 负责源码、实现和开发决策，设备 Agent 负责设备观测与建议。** 设备 Agent 不负责修改主机源码，也不会自动提交代码。

主机脚本是实验客户端，承担构建、案例编排、比较和部署控制；它没有重新引入运行时网关。

部署使用独立 ADB 通道也有实际原因：需要替换和重启的正是 MCP 服务自身。如果所有控制都依赖这个服务，一旦它退出，恢复通道也就断了。

当前部署流程会检查 ABI 和暂存产物摘要，保留上一份二进制，替换后启动服务并重新校验。失败时尝试恢复，并在报告中记录恢复结果；主机崩溃等异常期间仍不保证整个过程具备事务性。

## 05｜闭环里最关键的两件事：认对程序，认对证据

### 设备运行的是哪一份代码？

在开发过程中，相同版本号可能对应多次不同构建。刚推送的文件，也可能尚未被后台进程加载。

所以，`nl2sh_inspect` 新增了构建身份：Git 提交、工作区状态、build ID、目标架构、构建类型，以及运行可执行文件的 SHA-256。

这里有个容易被忽略的细节：**摘要读取的是 `/proc/self/exe` 指向的运行映像。**

如果磁盘文件被原子替换，旧进程仍然执行旧映像。读取安装路径会得到新文件的摘要，而读取运行映像能够识别这个差异。

主机上的构建 manifest 再把相关源码输入、构建标识和产物摘要关联起来。案例开始与结束都要核对身份，才能把设备结果用于验证本次代码。

### Agent 完成了，工具就成功了吗？

一个 Agent 完全可能在工具失败后正常给出解释，任务状态也因此进入 COMPLETED。

例如，读取一个受保护的系统文件被拒绝后，Agent 可以回答“权限不足”。这个回答可能准确，但读取动作仍然失败了。

新增的 `evidence` 从实际 Tool Round 提取工具名、调用 ID、成功或失败、缺失结果以及有界输出。它不会把模型回答里的描述转换成执行事实，也会明确标记截断和不完整结果。

报告进一步把观测、断言、假设、建议和限制分开。假设需要指向已有证据；建议仍是待采取的行动。

测试结果也不只有“通过”和“失败”，还包括证据不足的 `inconclusive` 和需要人工判断的 `manual_review`。缺少工具、输出不完整、环境发生相关变化，都不能被悄悄算成通过。

## 06｜这次已经验证到了哪里？

开发闭环已经在 Android API 26 的 x86_64 模拟器上实跑，使用普通 shell UID，保持自动审批关闭。

本次验证包括两次构建部署、同案例前后回归与比较、真实模型委派，以及复用同一上下文继续提问。

同时，也检查了几类容易造成误判的情况：

- 缺少或使用错误令牌时，访问被拒绝。
- 运行程序身份与预期产物不符时，身份门禁不通过。
- 工具不可用、文件读取权限不足时，保留实际失败。
- Agent 正常完成回答、内部工具却失败时，报告仍识别工具失败。
- 请求取消时，不把取消状态解释为副作用回滚。
- 修改请求等待 120 秒仍未获审批时，自动拒绝，目标文件未写入。

本次实现验收还通过了 452 项 Rust 测试、31 项脚本测试、Android API 26 三架构交叉检查，以及 50 对双语页面的严格文档构建和链接检查。

这些结果有明确范围：三架构交叉检查验证编译兼容性；本轮设备闭环的运行验证来自 x86_64 模拟器。

## 07｜协作能力更强，确认边界仍由设备掌握

远程工具调用最终仍进入 nl2sh 的设备端执行链：

```text
LLM / 工具请求 → 参数与安全检查 → 确认 → 执行
```

在默认策略下，修改动作需要设备本地同 UID 的交互终端批准；危险动作需要强确认。协议没有远程批准入口。项目提供显式自动审批配置，但这次开发闭环没有启用它，也不会为了让测试通过而改变安全策略。

HTTP MCP/A2A 使用 Bearer 令牌鉴权。协议启动默认允许 HTTP，因此连接需要结合受信任网络、ADB 转发或 HTTPS 代理安排；协议令牌也不等同于 Web 界面的登录保护，现有 Web 默认无需登录。

这一边界决定了协作方式：开发端可以提出请求、查看证据、修正实现，但不能仅凭模型判断就绕过设备确认。

随着原生 MCP/A2A、运行身份校验和可重复案例接在一起，nl2sh 已经可以把 Android 的真实反馈带回代码开发过程。开发者可以检查每一轮究竟运行了哪份程序、调用了哪些工具、得到了什么结果，再决定下一次修改。

定期主动诊断和多设备对比仍是后续方向。目前先把单设备上的调查、修改、部署和回归做扎实。

如果你在开发 Android 工具、设备自动化或设备端 Agent，可以从仓库中的确定性案例开始，再逐步尝试委派调查。让第一次调用留下可检查的证据，后面的协作才有依据。

---

项目与实现入口：

- 项目仓库：https://github.com/nl2sh/nl2sh
- 原生 MCP/A2A：https://github.com/nl2sh/nl2sh/tree/21616f4/src/protocol
- 仓库级 skill：https://github.com/nl2sh/nl2sh/blob/21616f4/.agents/skills/nl2sh-device-lab/SKILL.md
- 主机实验客户端：https://github.com/nl2sh/nl2sh/blob/21616f4/scripts/device_lab.py
- 开发闭环说明：https://github.com/nl2sh/nl2sh/blob/21616f4/docs/zh/development/device-lab.md


但到了 Android 上，代码写完只是开始。电脑上的测试通过了，手机上可能遇到权限拒绝；文件已经推送，后台进程却还在运行旧版本；模型说“已经完成”，真正的工具调用可能失败了。

让写代码的 AI 听见 Android 的反馈：nl2sh 的 MCP、A2A 与设备开发闭环

开发工具

人工智能

客户端

nl2sh为Android开发者构建闭环：通过原生MCP与A2A协议，让AI直接获取设备端真实执行证据，支持工具直调与Agent委派。新增构建身份与证据校验，区分程序运行状态与工具成败。提供可重复的开发流程，经模拟器验证，确保代码修改在设备上有效，让AI编程基于事实而非假设。

回归测试

代码解释

AI编程

Android

Python

GitHub

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

让写代码的 AI 听见 Android 的反馈：nl2sh 的 MCP、A2A 与设备开发闭环-腾讯云开发者社区-腾讯云

让写代码的 AI 听见 Android 的反馈：nl2sh 的 MCP、A2A 与设备开发闭环

让写代码的 AI 听见 Android 的反馈：nl2sh 的 MCP、A2A 与设备开发闭环

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐