用全新合并版TRAE打造墨水屏Agent：从接线到多Agent编排实战

一个真实的痛点催生的项目

很多人都有过类似经历：原本只想定个闹钟，看到消息顺手回复，再刷会儿视频，十几分钟后才想起还有件要紧事却怎么也记不起来。为了解决这种注意力分散，作者的思路很直接——做一块电子墨水屏，让它只显示「当前最重要的事情」，并实时同步电脑里的提醒事项。

这个想法听起来简单，但落地起来横跨硬件接线、单片机固件、桌面端数据读取、网络传输和大模型判断等多个环节。既涉及硬件又涉及软件的复杂项目，恰恰是检验全链路开发平台的好场景。作者选择用全新合并后的 TRAE 来完成，这款产品将原本的 TRAE Code 与 TRAE Work 整合为同一版本，让需求咨询、代码编写、项目编排可以在一处连贯推进。

为什么选 TRAE：三种模式打通的全链路

TRAE 本身从 coding 场景发展而来，在国内 AI coding 产品中长期处于领先位置。合并后它提供了三种相互打通的工作方式：IDE 模式负责具体代码细节，Agent 模式负责需求拆解和项目编排，Solo 模式则补充智能体创建等能力。

关键在于「打通」二字。Agent 模式和 IDE 模式里的 Agent 是互通的，可以直接看到之前的对话记录，让项目连贯进行。作者的实际用法是：前期在 IDE 模式里主导，解决具体代码和硬件插线指导问题；后期切换到 Agent 模式统筹，让多个 Agent 并行处理不同模块。

硬件接线：让AI当向导

墨水屏模块无法直接插电脑使用，作者选用树莓派 Pico 2W 作为中间桥梁——它既能通过 WiFi 从电脑接收数据，又能把数据传给墨水屏。但 Pico 上针脚众多，万一插错有烧毁风险。

作者没有急着写代码，而是先在 IDE 模式的 Agent 对话框里咨询：说明设备型号、项目目标，让 TRAE 给出接线表。考虑到针脚复杂，他建议让 TRAE 进行复核——反正用不了多少 token。拿到接线表后成功连好硬件，而 TRAE 在回复底部通常会给出下一步提示（比如接线测试），直接点击即可自动发送，省去反复输入提示词的麻烦。

接上电源等待 30 秒，第一次完全按照 AI 给出的接线表操作，结果平安无事。随后把 Pico 接入电脑确认固件状态——这里作者提醒原版 Pico 是 Micro USB 接口，建议买 Type-C 改版更方便。TRAE 自动完成测试代码并部署，墨水屏成功刷新，手工接线环节顺利收尾。

树莓派 Pico 2W 是 Raspberry Pi 基金会推出的低成本微控制器开发板，搭载双核 ARM Cortex-M33 处理器，内置 2.4GHz WiFi 与蓝牙。「2W」中的「W」代表无线版本，区别于无网络功能的基础款。它运行的不是完整的 Linux 系统，而是轻量级的 MicroPython 或 C/C++ 固件，因此启动速度极快、功耗极低，非常适合作为「外设与电脑之间的桥接节点」。

SPI（Serial Peripheral Interface）是墨水屏与 Pico 之间的通信协议，采用主从架构，通过 MOSI、MISO、SCLK、CS 四条信号线高速传输数据。电子墨水屏（E-Ink）本身有一个独特特性：断电后画面依然保留，仅在刷新时消耗电力，这使它非常适合「显示当前最重要的事」这类低频更新场景——既节省电量，又不会像 LCD 那样持续发光刺激视觉。

架构设计：三端分工

这是整个项目最能体现 Agent 模式价值的部分。TRAE 将项目拆成三部分：墨水屏负责显示，Pico 负责「传话」，Mac 电脑端负责「思考」。

由于墨水屏尺寸是 400×300，电脑端最终生成 400×300 的黑白画面；Pico 通过 WiFi 从 Mac 获取画面数据，再通过 SPI 把数据发给墨水屏。电脑端并非随意生成画面，而是读取提醒事项、日历并查询天气，结合系统和大模型判断后生成最终图像。

一个容易被忽视的细节是隐私处理：提醒事项和日历属于隐私数据，Python 不能直接读取 macOS 系统数据库。正规做法是通过苹果的 EventKit 申请权限，于是 TRAE 写了一个 Swift 的 EventKit Bridge，由它向系统申请权限并读取数据，再整理成 Python 容易处理的格式。整个数据流是：macOS 数据 → Swift Bridge → Python 程序（结合天气和 AI 判断）→ 黑白图片 → 墨水屏。作者特别强调，这种复杂项目一轮对话不够，他和 TRAE 进行了几轮沟通把需求说清楚，后续出现 bug 的概率就大幅降低。

EventKit 是苹果为 macOS 和 iOS 提供的系统级日历与提醒事项框架，应用必须通过它向操作系统申请明确的用户授权，方可读取相关数据——这是苹果沙盒安全机制的一部分。Python 脚本无法直接绕过这套权限体系访问系统数据库，因此需要借助能调用原生 Apple 框架的 Swift 代码作为「权限代理」。这个 Swift EventKit Bridge 本质上是一个小型命令行工具：它启动时触发系统弹窗请求授权，获准后读取日历事件和提醒事项，再以 JSON 格式输出给 Python 进程消费。这种「原生语言做权限层、脚本语言做逻辑层」的分层设计，是在 macOS 上处理系统隐私数据的常见模式，也体现了 AI 在跨语言工程决策上的实用价值。

多Agent并行：把活分给专人

项目同时涉及 Python、Swift，以及 Pico 上运行的 MicroPython 环境，还要把硬件、macOS 和数据源串起来。作者的办法是为不同模块创建专属智能体：一个专做墨水屏 UI，一个负责串口固件，一个负责渲染和服务器，还有一个负责测试和验收。

每次手动指定用哪个 Agent 太麻烦，作者把这些 Agent 名称直接写进计划里，执行计划时 TRAE 会自动判断该用哪个 Agent 做什么任务，而且这些 Agent 可以并行执行。这也解释了他为什么宁愿在制定计划阶段多花时间：计划理清后，执行阶段完全可以去干别的事，让多 Agent 自动跑。

UI Agent 给出了三套显示方案，TRAE 侧边栏的「我的产物」会统一罗列所有生成的设计方案，方便对比管理，还能针对指定产物发起新对话。这样方案、代码、测试结果、文档都沉淀在项目里。至于屏幕显示顺序，TRAE 采用了打包集成方案：黑白图片每 8 个像素打包成一个字节，400×300 的画面正好 15000 字节，并严格按墨水屏要求的比特顺序排列。

从「能跑」到「好用」的收尾

项目用到 WiFi，TRAE 自动开启终端界面让作者输入账号密码——值得一提的是，它没有要求在对话框里输入 WiFi 密码，这种安全细节对用户体验很重要。

真正让作者意外的是：第二天重新给 Pico 供电后，墨水屏自动刷新并显示「事项已过期」，说明 TRAE 在前期计划时就考虑到了这类细节。为了验证 WiFi 传输是否真的生效，他换用电源适配器和充电宝供电测试，墨水屏依然正确显示提醒事项，证明数据确实走 WiFi 传输。

随后他接入云端 AI，让提醒事项更人性化。最终形态是：墨水屏 Agent 大约每分钟通过 WiFi 询问 Mac 服务器有无新画面，内容变化就下载刷新，没变化则保持不动。为了省去手动检查，他在侧边栏「自动化」里创建定时任务，每天自动在 Agent 模式创建并执行任务；再通过「我的助理」绑定飞书，用手机就能发送任务、实时收到完成结果，不必守在电脑前。

飞书作为企业协作平台提供了开放的 Bot 接口，开发者可以通过 Webhook 或官方 SDK 将其接入自动化流程，实现「在聊天界面发送指令触发程序、程序执行完毕后推送结果」的双向交互。这种将 AI Agent 与即时通讯工具绑定的模式，本质上是把「任务调度入口」从桌面端延伸到移动端，解决了「必须坐在电脑前才能启动或查看任务」的使用摩擦。对于软硬件结合项目而言，这意味着即便 Pico 和墨水屏在家中独立运行，用户在外也能通过手机发起新的提醒内容更新，进一步强化了系统的实用性。

对AI编程的一点思考

作者最后点出一个重要观点：AI 编程并不是「我说一句、AI 写一段代码」那么简单。在这次开发中，前期由 IDE 模式主导解决具体代码和硬件问题，后期由 Agent 模式统筹，多个 Agent 并行处理不同模块——当这些环节真正连起来协同工作，才算得上是 AI 编程的完整形态。

对于想尝试软硬件结合项目的开发者来说，这个案例的参考价值在于：复杂项目要在规划阶段把需求、架构和 Agent 编排想清楚，执行阶段才能最大化自动化收益。工具的「全链路打通」能力，正是让这类跨领域项目变得可行的关键。