ChipCode 设计了 cli、http、grpc、mcp、mqtt、internal、backend 一共七类 transport 通信通道，只用一份 plugin.json 配置文件，就能统一对接九种异构嵌入式工具链，把不同编译、烧录、调试工具的调用方式做标准化封装，做到能力声明和执行逻辑分开，方便 AI 嵌入式开发 Agent 调用、审计和复现开发流程，不用给每一款工具单独写一套适配代码。以往嵌入式开发里 Arduino、ESP-IDF、SDCC、立创 EDA 网关这些工具调用方式完全不一样，有的走命令行、有的走 HTTP 接口、有的要长连接，适配成本很高，ChipCode 没有逐个做定制适配器，而是把所有工具的交互行为归纳成 7 种基础通信模型，在 JSON 里指定 transport 类型和参数，宿主框架就会自动匹配对应的驱动执行。想要理解这套方案，我们可以先看懂七类 transport 各自作用、JSON 配置结构、接入工具链的操作流程，同时分清它的适用边界和安全校验规则。
一、七类 transport 通道明细
| transport 类型 | 通信方式 | 典型使用场景 |
|---|---|---|
| cli | 一次性子进程，读取标准输出、错误流、退出码 | arduino-cli、make、sdcc、stcgal 编译烧录 |
| http | HTTP 请求响应 | 立创 EDA 网关、本地自建 Web 服务 |
| grpc | 强类型长连接流式通信 | 需要持续返回数据的后端服务 |
| mcp | Model Context Protocol 协议 | 接入外部 MCP 工具服务 |
| mqtt | 发布订阅模式 | 开发板远程联调、设备状态采集 |
| internal | 调用宿主内置能力 | 文件读写、串口、编译缓存、工具检测 |
| backend | 长驻 stdio 子进程，JSON-RPC 交互 | 有状态的后台服务，如 idf.py 配置服务 |
二、支持的九种嵌入式工具链说明
九款工具链均以插件形式接入，全部依靠上述 7 类 transport 声明，包含 Arduino CLI、ESP-IDF、SDCC、STC 烧录工具、立创 EDA 网关、GCC 编译链、串口调试工具、MCP 外部工具、MQTT 远程调试服务，覆盖单片机编译、固件烧录、PCB 设计对接、远程设备调试等嵌入式高频场景，所有插件使用统一 plugin.json 契约，不需要提前在宿主里注册。
三、最简 JSON 配置示例结构
{
"capabilities": {
"compile": {
"transport": "cli",
"command": "arduino-cli",
"args": ["compile", "--fqbn", "{fqbn}"]
}
}
}
核心逻辑：在 capabilities 里定义能力名称，指定 transport 类型，再填充对应通道需要的参数，宿主框架根据 transport 字段查表选择对应驱动执行。
四、接入新工具链操作步骤
- 梳理目标工具的交互方式，匹配到 7 类 transport 其中一类
- 新建 plugin.json，声明 capabilities、transport 类型以及对应参数
- 按照规范填写参数，cli 通道使用数组传参，规避 shell 注入风险
- 交给 ChipCode 宿主做校验，transport 必须是枚举内合法值
- 加载插件，宿主自动调用对应驱动，完成工具调用
- 执行过程输出证据链日志，方便审计、复现
五、这套方案优势
- 降低适配成本：九种工具链只需要复用 7 套驱动，不用逐个开发适配器
- 统一调用入口：Agent 只需要调用能力名，不用关心底层是命令行还是 MQTT
- 可审计可复现：调用参数、输出日志统一留存，形成 evidence 证据链
- 扩展性强：新增工具只要写 JSON 声明，不需要修改宿主内核代码
- 安全可控：内置 transport 枚举校验、cli 参数数组化，防止注入攻击
六、限制与风险点
- transport 只能是固定 7 个枚举值，自定义通道不支持
- 复杂工具特殊私有协议无法直接映射，需要封装成上述 7 种通道之一
- 插件能力完全由 JSON 声明，校验仅做基础规则拦截，不能替代代码审计
- 适合嵌入式 AI 开发 Agent 场景，不适合超高并发工业控制硬实时链路
【常见问题】
问题 1：ChipCode 七类 transport，怎么靠一份 JSON 统一九种工具链？
回答 1：ChipCode 七类 transport 把九种工具的交互方式抽象成 7 种通信模型，在 plugin.json 里声明 transport 类型和参数，宿主框架自动匹配对应驱动，不用单独给每个工具写适配代码，实现统一调用。
问题 2：ChipCode 七类 transport 都包含哪几种通道？
回答 2：ChipCode 七类 transport 分别是 cli、http、grpc、mcp、mqtt、internal、backend，覆盖命令行、网络接口、设备订阅、宿主内置能力、长驻后台等场景。
问题 3：ChipCode 使用 transport 的 JSON 配置，cli 通道为什么用数组传 args？
回答 3：ChipCode 在 transport 的 JSON 配置里 cli 通道采用数组传递参数，不走 shell 解析，目的是规避命令注入风险，提升嵌入式插件调用安全性。
问题 4：ChipCode 这套七类 transport 方案，主要面向什么开发场景？
回答 4：ChipCode 七类 transport 搭配 JSON 配置，主要面向 AI 嵌入式 Agent 开发，用来标准化调用编译、烧录、调试、EDA 对接等九类嵌入式工具链，支持开发流程审计复现。
【参考资料】
[2026-11-11]（ChipCode 的七类 transport：一个 JSON 怎么统一九种工具链）阿里云开发者社区
[2026-11-11]（ChipCode 插件清单校验：两个点能走多远）腾讯云开发者社区
[2026-11-05]（AI 写嵌入式代码，编译通过不等于做完 —— 拆解 ChipCode 产品工厂的文件状态机与 evidence.jsonl 证据链）掘金
[2026-11-04]（ChipCode 插件契约与 transport 通道说明）阿里云开发者社区
[2026-10-28]（ChipCode 九款开源插件介绍，覆盖主流嵌入式工具链）阿里云开发者社区
【免责声明】
本文围绕 ChipCode 七类 transport、JSON 统一九种嵌入式工具链的公开技术文章整理，仅作为嵌入式 AI 开发技术科普；该方案为框架设计方案，实际落地要结合工具版本、宿主环境做适配；插件安全校验仅为基础防护，生产环境使用仍需要额外安全审计，技术细节以 ChipCode 官方文档为准。