announce: zhihu draft shortened to ~500 chars (was too long)

Author: WaylandYang

.github/announce/zhihu.md

@@ -1,116 +1,66 @@
-# 知乎 / 公众号 长文(中文)
+# 知乎 / 微博短文(中文,500 字内)
 
-## 标题候选
+## 标题
 
-1. **DCP:让 LLM 安全控制 1 美元单片机的开源协议**(推荐)
-2. **MCP 不下沉的地方,我们做了一个新协议:DCP**
-3. **LLM 调用硬件,该有的安全原语都不应该是 application code**
-
-## 摘要(发文时填到顶部)
-
-> Anthropic 的 MCP 解决了 LLM 调 SaaS 工具的标准化问题,但**故意不下沉到嵌入式硬件**——这是他们 2026 roadmap 明确的选择。
->
-> 我们开源了 **DCP (Device Context Protocol)**,把"LLM ↔ 物理设备"这最后一米的标准做出来。已经在 ESP32-WROOM-32 上端到端验证通过,Claude Desktop 真能调动一颗 1 美元单片机上的灯。
->
-> 完全互补 MCP,不是替代。
->
-> 仓库:github.com/device-context-protocol/dcp
+**DCP:让 LLM 安全控制 1 美元单片机的开源协议**
 
 ## 正文
 
-### 为什么这个东西需要存在
-
-我做 IoT 几年了,反复遇到同一个问题:有了 LLM 能写自然语言指令,有了 MCP 能标准化工具调用,但**到设备这一层标准没了**。
-
-每个"Arduino MCP 服务器"项目都是 JSON-RPC over WebSocket,塞进一颗 32KB RAM 的 MCU。要么浪费 80% 的资源,要么干脆排除掉 Cortex-M0+ 这种 0.3 美元的便宜芯片——而这恰好是消费级 IoT 真正能 scale 的价位段。
-
-另一条路是**自己撸串口协议**。每个项目重新发明帧结构、错误码、能力管理。结果是不能互操作,不能复用工具链,LLM 用起来也很危险——给一个会"幻觉"的调用者直接的 GPIO 控制权,出事是迟早的。
-
-### DCP 的定位
-
-**一句话**:DCP = MCP 的"最后一米",一个紧凑的二进制协议加上安全原语,让 LLM 能安全地操控便宜的微控制器。
-
-```
-LLM ─MCP─▶ Bridge ─DCP wire─▶ Device (<16KB MCU)
-            │
-            └─ 这里负责所有安全检查:capability / range / dry-run / token 验证
-```
+Anthropic 的 MCP 解决了 LLM 调 SaaS 工具的标准化,**但不下沉到嵌入式**——这是他们 2026 roadmap 明确的选择。
 
-中间的 **Bridge** 是唯一的信任边界。LLM 永远看不到裸 GPIO。Bridge 会:
-- 验证 capability token(HMAC-SHA256,过期/范围)
-- 检查所有参数 range、单位、类型
-- LLM 可以 dry-run("如果我这么做,会发生什么?"),设备不真执行
-- 拦截幻觉调用 —— 比如 LLM 把"调到 50 度"理解成华氏度送到一个摄氏度设备,Bridge 单位检查拦住
+我开源了 **DCP (Device Context Protocol)**,补这最后一米。**已在 ESP32 上端到端跑通**,Claude 真能直接控住一颗 ¥10 单片机上的灯。
 
-设备保持简单。也因此能跑在 32 KB 的 MCU 上。
+完全互补 MCP,不是替代。
 
-### 跟前人的关系
+### 三个数字
 
-- **MCP**:上游,我们用 Bridge 翻译,保证零配置兼容 Claude Desktop / Claude Code
-- **IoT-MCP**(arXiv:2510.01260):学术先驱,他们证明 MCP 可以下沉到 74KB peak。**我们走得更远**:14KB 纯协议代码,有安全原语,可生产部署
-- **W3C WoT**:更重的描述层,我们做 wire-format 互补
-- **Matter**:智能家居 vertical,不直接竞争
+- **19 字节** —— 一次典型调用的 wire 大小(对比 MCP JSON-RPC ~180 字节)
+- **<16 KB** —— firmware 在 ESP32 上的体积目标(实测 14 KB)
+- **88/88 + 10/10** —— Python 单测 + 真机 round-trip 全绿
 
-技术对比表完整版在 [docs/RATIONALE.md](https://github.com/device-context-protocol/dcp/blob/main/docs/RATIONALE.md)。
+### 为什么不是"又一个 IoT 协议"
 
-### 数字
+DCP 把 LLM 安全相关的几件事直接做进了**协议层**,不是 application code:
 
-实测在 ESP32-WROOM-32(CH340 USB 转串口,115200 波特率):
+| | DCP 协议层管 |
+|---|---|
+| 单位歧义(华氏/摄氏)| `unit:` 字段强制声明 |
+| LLM 幻觉出超界参数 | manifest `range:` Bridge 拦截 |
+| LLM 想干超权限的事 | HMAC-SHA256 capability token |
+| 不可逆动作 | `dry_run` 是 wire 格式的一个 bit |
 
-| 维度 | DCP | 对比 |
-|---|---|---|
-| 典型 call 帧 | 19 字节 | MCP JSON-RPC ~180 字节 |
-| 纯协议代码 | ~14 KB | IoT-MCP 74 KB peak |
-| Python 测试 | 88/88 PASS | — |
-| 真硬件 round-trip | 10/10 PASS | — |
-| 支持的 transport | 5 种(UART/MQTT/BLE/USB-CDC/loopback) | 多数项目 1 种 |
+这 4 件事 90% 的 IoT 协议丢给开发者自己实现,出事率极高。DCP 把它们标准化。
 
-### 设计取舍上的几个有意思的点
+### 架构
 
-**1. Bridge 集中安全,设备傻**
-违反直觉,但是必要的。如果每个设备自己实现 capability 检查,就会有 10000 种实现,99% 有 bug。把这层抽到 Bridge,设备只管做事。
-
-**2. 单位写在 manifest 里**
-```yaml
-level: { type: float, unit: percent, range: [0, 100] }
 ```
-LLM 在 tool schema 里直接看到 unit,**从协议层消灭了单位混淆**。比 docstring 写"please use Celsius" 强 100 倍。
-
-**3. dry-run 是 wire format 的一个 bit**
-不是约定,不是 payload flag,是协议的 kind 字段(0x81)。LLM 可以发"假装我开锁了,会发生什么"——设备返回预测结果但**不开锁**。对不可逆操作是必需品。
-
-**4. 单一 wire format,跨所有 transport**
-UART / MQTT / BLE / USB-CDC 同一份固件,只换 transport 类。**从原型到生产换接口,协议不动**。
-
-### 老实的局限
-
-发布是 **v0.3 draft**,不是 v1.0。诚实列出来:
+LLM ── MCP ──▶ Bridge(唯一可信边界)── DCP wire ──▶ Device
+                 │
+                 ├─ 容量 token 校验
+                 ├─ 范围/类型检查
+                 └─ dry-run 预演
+```
 
-- 只在一种 MCU 上跑过(ESP32-WROOM-32)。Cortex-M0+ / nRF52840 / RP2040 是 v0.4 的活
-- 跟 IoT-MCP 的实测 A/B 还没做,这是后续 paper 的事
-- 协议 spec 等第二个独立实现(社区贡献的 C 或 Rust 版本)才能 freeze v1.0
-- Wire HMAC 不带 in-band marker,需要部署侧约定——这是有意的(防降级攻击),但配置容易出错
+Bridge 是个 Python 进程,你的 LLM(Claude/本地模型/其他)说 MCP,Bridge 翻译成 DCP 喊设备。**设备永远收不到 LLM 直发的命令**。
 
-### 试一下
+### 现在能做什么
 
 ```bash
-pip install pydcp[mcp,serial]
-dcp serve examples/lamp_manifest.yaml --simulator
-# 或者你有 ESP32:
-# 烧 firmware/esp32/examples/lamp/lamp.ino
+pip install "pydcp[mcp,serial]"
 dcp serve examples/lamp_manifest.yaml --serial COM5
+# 然后 Claude Desktop 加 MCP server,"调灯到 30%" 就生效
 ```
 
-接 Claude Desktop:在 `claude_desktop_config.json` 加几行 `mcpServers`,问 Claude "把灯调到 30%",真灯真变暗。
+### 仓库 / 论文
 
-仓库:
-**[github.com/device-context-protocol/dcp](https://github.com/device-context-protocol/dcp)**
+- 代码 + spec:**github.com/device-context-protocol/dcp**(MIT)
+- Paper 草稿(arXiv 待审):同 repo `/docs/paper/main.pdf`
 
----
+### 我想要的反馈
 
-如果你做 IoT、嵌入式 AI、agent 工具链,欢迎来 GitHub issues / discussions 拍砖。最希望的反馈是:
-1. **跨平台移植**:谁能在 STM32 / nRF52 / RP2040 上跑通,我请喝奶茶
-2. **第二个独立实现**:Rust 或 C 版本(spec 一页纸,实现量 ~500 行)
-3. **真实场景测试**:你手里有什么硬件想接 LLM 的,告诉我哪里 protocol 不够用
+主要是 spec 设计层的:**有没有看到漏的安全场景?有没有更好的 capability 模型?**
+小修小补走 GitHub issues。
+
+---
 
-MIT 协议,无 CLA,无认证费,无供应商绑定。
+(图床:配 architecture 图 `arch.png` 在第一段后面)