https://simonwillison.net/2026/Nov/9/mysterious-beeps/

这篇文章挺有意思，而且我认为它比普通的「AI 写了一个小工具」更值得关注。

Simon Willison 在 2026 年 11 月 9 日发表的文章，标题是 《Locating the source of a mysterious beep with Claude》（用 Claude 定位神秘的哔哔声）。

它实际上展示了一个很重要的方向：

如何让 Coding Agent 不只是操作代码和文件，还能通过外部设备感知真实世界，并根据感知结果自主迭代程序。

这也是我认为这篇文章最值得研究的地方。

1. 他遇到了什么问题？

Simon 家里有一个堆满纸箱的小房间。

某天，房间里开始间歇性地发出哔哔声（Beep）。

问题是：

  • 声音出现的间隔很长。
  • 每次响的时候，人不一定在房间里。
  • 即使人在房间里，也很难判断声音来自哪里。
  • 他不想为了找一个设备，把所有纸箱都翻一遍。

最后发现，发出声音的是一个年代久远的一氧化碳报警器（Carbon Monoxide Detector），它的电池需要更换。

但有意思的是，他没有自己去找，而是让 Claude Code 帮他开发了一套声音定位系统。

2. 他开发了什么？

项目叫 Beep Locator。

核心思路很简单：

把家里闲置的手机、平板、笔记本电脑全部变成麦克风。

例如：

  • iPhone
  • 两台 iPad
  • MacBook Pro
  • Surface

让它们分散在房间不同位置，同时监听声音。

然后由一台电脑运行 Python Web 服务，统一协调这些设备。

最终在网页地图上显示：

  • 每台设备的位置。
  • 每次检测到声音的时间。
  • 声音可能来自的位置。
  • 不同设备录制的声音。
  • 定位结果及置信程度。

最终定位精度达到了约 40 厘米。

Simon 根据这个结果，只翻找了对应位置的一堆纸箱，就找到了报警器。

3. 技术原理：它是怎么定位声音的？

这里有几个值得拆开的技术点。

3.1 第一步：让设备互相测距

这是整个系统的基础。

他使用了一篇 2007 年的论文：

BeepBeep: A High Accuracy Acoustic Ranging System using COTS Mobile Devices

论文来自当时的 Microsoft Research Asia。

核心思想是：利用设备自身的扬声器和麦克风，通过声音传播时间计算设备之间的距离。

假设有设备 A 和 B：

  1. A 播放一个特殊声音。
  2. B 播放另一个特殊声音。
  3. A、B 各自通过麦克风录下这两个声音。
  4. 分别计算两个声音在录音中的采样点间隔。
  5. 双方交换测量结果。

通过两边测量时间的差值，可以计算出声音往返传播的时间，从而得到两台设备之间的距离。

声音在空气中的传播速度约为 343 米/秒。

距离 = 声音传播速度 × 传播时间

为什么不直接用设备系统时间？

因为普通手机、电脑存在很多不可控延迟：

  • 不同设备的系统时钟存在偏差。
  • 调用播放接口到真正发出声音有延迟。
  • 麦克风采集和软件识别也有延迟。

论文采用了一个很巧妙的办法：不依赖两个设备的绝对时钟，而是统计各自录音中的采样点数量。

这样很多时钟偏差和软件调度延迟就可以抵消。

论文在特定实验环境中，使用普通手机实现了约 1～2 厘米的测距精度。

注意，这是 2007 年论文中的设备测距实验结果，不等于实际房间定位精度。

3.2 第二步：构建房间里的设备坐标

知道设备之间的距离还不够。

例如：

  • A 到 B：2 米
  • A 到 C：3 米
  • B 到 C：2.5 米
  • B 到 D：1.8 米

如何知道它们在房间里的具体位置？

这里使用的是多维尺度分析（MDS，Multidimensional Scaling）。

简单理解：

已知多个点之间的距离，通过数学算法反推出这些点在二维平面上的相对坐标。

项目使用了：

  • MDS：多维尺度分析。
  • SMACOF：一种迭代优化 MDS 坐标的算法。
  • Outlier rejection：异常数据剔除。

最终生成一个房间平面图，把每台设备放在对应位置。

不过，这种方法只能得到相对位置，不能天然知道哪个方向是房间的左边、哪个方向是右边。因此需要人工调整地图方向，或者通过 Rough Mode 手动拖动设备到大致位置。

3.3 第三步：确定声音来自哪里

这才是真正的核心。

使用的是 TDOA（Time Difference of Arrival），即到达时间差定位。

假设某个报警器发出了声音：

声音传播速度是固定的。

距离报警器近的设备，会先听到声音；距离远的设备，会晚一些听到。

假设：

设备收到声音的时间
A10.000 秒
B10.003 秒
C10.006 秒
D10.002 秒

这里最重要的不是声音什么时候发生，而是不同设备听到声音的时间差。

例如，A 比 B 早 3 毫秒听到声音。

那么 A 和 B 到声源的距离差约为：

343 × 0.003 = 1.029m

这意味着声源在一个特定的双曲线上。

多组设备产生多条约束曲线，交汇区域就是声源最可能的位置。

实际项目还要处理复杂得多的情况，包括录音对齐、反射声、噪声和测量误差。

3.4 一个很巧妙的细节：同步 Chirp

普通设备的录音时间并不完全同步。

因此 Simon 又设计了一个办法：

当某台设备检测到疑似 Beep 时，服务器让其中一台设备播放一个短促的同步声音（Chirp）。

然后要求所有设备上传：

  • 原始 Beep 前约 0.6 秒的录音。
  • 同步 Chirp 后约 0.8 秒的录音。

因为所有设备都能在录音中找到这个同步声音，所以可以把不同设备的录音对齐。

这样就能够更准确地比较目标声音在各个设备上的到达时间。

这也是为什么文章中的方案不是简单地记录「某台设备在 10:00:01 检测到声音」，而是保留了原始音频片段进行后续分析。

4. AI 在这个项目中到底做了什么？

这是我认为最值得关注的部分。

先看整个技术架构：

Claude Code / Coding Agent
理解问题、编写代码、分析结果、迭代功能
        ↓
Python 协调服务器
FastAPI 风格的 Web 服务、WebSocket、设备管理、音频分析
        ↓
iPhone / iPad / MacBook（WebAudio）
其他设备也是相同架构，通过浏览器加入

这里有三个层次。

第一层：AI 负责编写程序。

Simon 一开始并没有详细设计完整架构，而是给 Claude Code 一个问题：

房间里有一个设备一直在发出声音，我找不到它。希望用多台手机、平板和电脑同时监听，帮助我定位。

甚至还问 Claude：

能不能让这些设备互相播放声音，从而自动确定彼此的位置？

Claude 先研究论文，再生成 problem.md，然后逐步实现系统。

第二层：程序负责感知真实世界。

每台设备通过浏览器运行 JavaScript：

  • WebAudio 获取麦克风音频。
  • FFT（快速傅里叶变换）检测特定频率。
  • 高通滤波器过滤部分低频噪声。
  • 检测到疑似声音后通知服务器。
  • 上传相应时间段的录音。

这里不需要 Claude 自己直接处理音频。传统 DSP 算法就能完成很多工作。

第三层：AI 根据反馈持续修改程序。

这部分最有意思。

Simon 让 Claude 实现了一个叫 installModule() 的机制。

服务器可以通过 WebSocket 给各个客户端发送新的 JavaScript 模块，让设备在不刷新网页的情况下加载和执行新代码。

于是形成了一个循环：

  1. Claude 查看当前系统状态。
  2. 通过服务器查询设备、日志和录音。
  3. 发现某个功能不理想。
  4. 编写新的 JavaScript 或 Python 代码。
  5. 推送到正在运行的设备。
  6. 设备继续采集数据。
  7. Claude 根据新数据继续调整。

这意味着 Simon 不必每次修改代码都跑到房间里，逐台设备刷新网页。

他基本上坐在电脑旁边，通过对话让 Claude 不断改进程序。

文章还提到，他使用了 Claude Code Cloud 启动项目，之后在本地使用 Claude Code 和 Fable 5.2 继续开发。

5. 最值得关注的设计：给 Coding Agent 装上耳朵

Simon 在文章中专门用了一个小标题：

Giving Claude Code ears（给 Claude Code 装上耳朵）

我觉得这是全文最有价值的观点。

传统 Coding Agent 的工作方式通常是：

用户提出需求
    ↓
AI 修改代码
    ↓
运行测试
    ↓
查看报错
    ↓
继续修改代码

但是这个项目把反馈来源扩展到了真实世界：

用户提出需求
    ↓
AI 编写程序
    ↓
程序连接真实设备
    ↓
设备采集真实世界数据
    ↓
AI 分析采集结果
    ↓
AI 修改程序
    ↓
真实设备再次执行
    ↓
持续迭代

这其实是一个非常重要的变化：

Coding Agent 不再只是通过代码和测试来判断程序是否正常，还可以通过传感器、摄像头、麦克风等获取外部世界的反馈。

文章还举了另一个例子：

在 GitHub Universe 活动中，有人调试徽章电脑（Badge Computers），将设备通过 USB-C 连接到电脑，再用摄像头对准屏幕，让 Coding Agent 观察设备界面，判断更新是否正常。

两个例子本质上是一样的：

  • 摄像头是 Agent 的眼睛。
  • 麦克风是 Agent 的耳朵。
  • 传感器是 Agent 感知物理世界的接口。
  • 可执行代码是 Agent 改变现实世界行为的手段。

6. 项目本身值得研究吗？

simonw/beep-locator — Python + JavaScript · Apache-2.0 · 开源

我看了一下仓库 README，里面有几个值得研究的实现细节：

技术用途
Python服务端协调和分析
WebSocket服务端与监听设备通信
WebAudio浏览器音频采集和播放
FFT声音频率检测
SQLite存储设备、事件和录音相关数据
MDS / SMACOF设备空间布局
TDOA声源定位
Gauss-Newton数值优化求解

还有一个很有意思的设计：

它把设备端程序设计成了可动态替换的模块。

README 中提供了命令行接口，可以直接向监听设备推送 JavaScript 模块：

uv run beep-locator ctl state

uv run beep-locator ctl push listener myexp exp.js

uv run beep-locator ctl results

uv run beep-locator ctl events --follow

甚至可以远程执行设备端代码、查询运行状态、查看录音。

这相当于构建了一个小型的多设备实验平台。

另外，项目支持模拟房间，不需要真的准备多台设备就可以进行算法测试。

来源：项目 README 和代码仓库

一个安全方面的提醒： 这种远程动态执行设计能力很强，但风险也不小。仓库支持通过控制接口向客户端推送可执行代码，也支持自动拉取代码更新。因此不应该把管理端口或带有管理 Token 的 URL 暴露给不可信网络。麦克风录音也涉及隐私，需要明确授权和控制数据保存范围。

7. 这个项目有哪些局限？

虽然效果很好，但它并不是一个通用的室内声源定位方案。

有几个实际限制：

  1. 设备数量和摆放位置很重要。 三台以上设备更适合进行定位，设备分布越合理，定位约束通常越充分。
  2. 室内反射声会影响精度。 墙壁、家具、纸箱都会产生回声，系统需要判断最早到达的声音，避免把反射声误认为直达声。
  3. 设备差异会影响测量。 不同手机的扬声器、麦克风、采样率、音频处理链都可能带来误差。
  4. 需要提前校准。 不能只把几个手机随便放在房间里，就期待它们自动获得准确的空间坐标。
  5. 40 厘米是这个具体案例的结果。 不能据此认为任何房间、任何设备组合都能达到同样精度。

尤其值得注意的是：他最终找到的是一个持续发出固定频率声音的设备，因此可以通过频率和时间间隔建立目标声音特征，逐渐排除其他声音。

这比要求系统定位任意环境声音容易得多。

8. 我的思考：这对未来 Agent 开发有什么启发？

我觉得可以从三个层面理解。

第一层：Agent 正在从软件世界走向物理世界

以前我们做 Agent，主要是：

  • 操作浏览器。
  • 调用 API。
  • 查询数据库。
  • 执行 Shell。
  • 修改代码。

现在可以进一步扩展：

  • 操作摄像头。
  • 监听麦克风。
  • 读取温度、湿度、光照传感器。
  • 控制机器人。
  • 操作实验设备。

例如，一个 AI 机器人开发 Agent：

  1. 修改机器人控制代码。
  2. 部署到机器人。
  3. 读取摄像头和传感器数据。
  4. 发现机器人移动轨迹不正常。
  5. 分析原因。
  6. 修改控制算法。
  7. 再次运行实验。

这和 Beep Locator 的思路完全一致，只是复杂程度更高。

第二层：Agent 的能力不一定来自更大的模型

Beep Locator 有一个很值得注意的地方：

定位算法不是 LLM 发明的，也不是靠 LLM 直接听声音判断位置。

真正完成定位的是：

  • 数字信号处理。
  • 声学测距。
  • 多维尺度分析。
  • 到达时间差。
  • 数值优化。

AI 的价值在于把这些技术组合起来，解决一个具体问题，并根据实际反馈不断调整。

这说明未来很多实用 Agent，不一定需要一个无所不能的超级模型。

更重要的可能是：

模型 + 工具 + 传感器 + 执行环境 + 反馈闭环。

第三层：软件开发正在变成实验驱动

传统开发：

需求 → 设计 → 编码 → 测试 → 发布

这种开发方式中，测试通常是开发完成后的验证。

而这个项目展示了另一种方式：

提出假设
   ↓
AI 实现
   ↓
真实环境实验
   ↓
收集数据
   ↓
分析结果
   ↓
调整实现
   ↺

AI 不只是写代码，而是参与整个实验过程。

这对 AI Coding Agent 的未来非常重要。

9. 如果让我总结这篇文章

值得关注

我认为这篇文章真正的价值并不是发明了一种新的声音定位算法。

2007 年的论文已经提供了核心测距技术。

真正有意思的是，Simon 用现代 Coding Agent 把一篇学术论文、多个普通消费电子设备、Web 技术和传统信号处理算法组合起来，在一个真实生活问题上完成了从想法到可用工具的全过程。

而且，AI 能够持续观察程序运行状态，并动态修改设备端代码，让整个系统形成反馈闭环。

我更愿意把它看成 Agent 从 Coding Agent 向 Physical-world Agent（物理世界智能体）演进的一个小型案例。

我建议重点研究两个东西：

  1. Beep Locator 源码：尤其是 runtime.js、hub.py、procedures.py 和 analysis.py，看看它如何实现远程代码注入、设备协调和数据反馈。
  2. BeepBeep 2007 年论文：理解它如何绕过普通设备的时钟同步问题。

一个值得思考的问题是：如果把这个架构抽象成通用 Agent，让 AI 可以自行接入摄像头、麦克风、传感器，观察外部环境并修改自己的执行程序，那么它距离一个真正能够自主进行现实世界实验的 Agent，还有多远？