个人创业项目：AIoT数据管线和平台开发
之前有一段时间比较空闲，我就想认真测试一下 AI Agent，尤其是 Codex，看看它能不能自动化完成我过去创业项目中的一部分开发工作。此前我已经明显感受到 AI Agent 的代码开发能力很强，但一直没有真正拿自己以前做过的嵌入式、无线通信、系统移植等项目来测试。过去做这些项目时，我更多是通过网页版 ChatGPT，一边对话、一边学习，再自己动手完成系统搭建和调试。而当我了解到 AI Agent 不只是能够回答问题，而是可以直接控制电脑、调用工具链、执行命令并自主完成开发任务之后，我开始思考：能不能让运行在本地电脑上的 Codex，直接操作我的嵌入式开发环境，完成编译、烧录、调试和系统测试？
于是我重新拿出以前做过的一些项目进行测试。例如，我曾经研究过如何将相关系统移植到树莓派上，因此很清楚这条技术路线本身是可行的，但当时真正把整个流程跑通花费了大量时间。后来用 Codex 重新测试时，我只给了它几个比较简单的提示，告诉它大致方向和目标，它就能够把我以前做过的很多流程快速复现出来，而且分析、执行过程和最终结论都相当完整。当时给我的冲击很大，因为我第一次比较直观地看到：过去需要人工不断查文档、配置环境、测试和排错的流程，Agent 已经可以在相当程度上自主完成。
这之后我逐渐形成了一个判断：只要物理设备能够通过 USB、串口、网络或其他接口连接到电脑，并且操作系统可以通过驱动识别设备，同时相关开发工具预留了 CLI、API 或脚本接口，那么大量工作理论上都可以交给 Codex 这类 Agent 操作。它不仅可以实时编写和修改传感器节点、网关的固件，还可以继续向上完成数据 Pipeline 的构建：从节点采集数据，到网关汇总，再登录 VPS 服务器接收和处理数据，进一步开发数据库、后端 API 和前端界面。包括 Landing Page、Web UI、用户注册登录、Dashboard、设备管理等功能，都可以逐渐串联起来。也就是说，Agent 的价值并不只是“帮我写一段代码”，而是有机会贯穿整个 AIoT 系统的开发链路。
当时我也借助 AI 工具重新构建了一套属于自己的 AIoT 平台核心，并且从一开始就比较强调系统的 scalability。例如，不同类型的传感器节点应该如何接入不同的网关，网关如何在服务器后端注册并获得唯一 ID，用户如何将节点分配到自己的账户，以及节点如何进一步与具体地块、设备或应用场景绑定。这些内容本身已经比较接近真正的平台工程，而不再只是一个简单的传感器 Demo。虽然其中涉及不少网络通信、设备管理和后端架构知识，但我的嵌入式和传感器背景让我能够理解并反过来指导 Agent 开发。与此同时，我也意识到自己当时对网络通信部分的理解还不够系统，因此后来学习 Communication Networks 时，我会特别关注数据传输、网络协议、连接管理和系统状态同步，因为这些正是一个完整 AIoT 平台非常重要的基础。
在这个平台上，我还尝试过让大语言模型直接结合传感器数据进行分析，再生成结论。我觉得这是 AIoT 未来非常有意思的一条路线：传感器系统负责持续感知物理世界，数据平台负责存储和组织信息，而 AI 模型进一步理解这些数据并给出判断。比如，当我重新查看过去项目的截图时，又想起了一个很典型的问题：如果某个节点突然掉线，Dashboard 怎样才能几乎实时地反映出来？这看起来只是一个“小功能”，实际上背后涉及心跳包、MQTT、WebSocket、超时判断、状态同步等一系列机制。节点需要不断证明自己仍然在线，一旦超过设定时间没有新的消息，后端就要更新状态，前端也需要立即显示异常。这类跨越节点、网关、服务器和前端的协同开发，恰恰是 Agent 很适合发挥作用的地方。
前端的数据展示也是类似。现在的 AI Agent 已经可以结合截图理解网页结构，帮助设计图表、数据卡片、设备列表和交互逻辑。例如传感器的历史数据如何展示，鼠标移动到某个时间点时如何显示具体数值，不同时间段之间如何比较，以及如何进一步生成趋势分析等。对于真正面向用户的 AIoT 产品来说，数据采集只是第一步，最终用户看到的 Dashboard 是否直观、信息是否清晰、设备异常是否能够及时反馈，同样决定了产品是否真正可用。
我也越来越认可一种比较规范的开发方式：让本地 Agent 在 Docker 容器中完成开发和测试。Docker 可以尽可能模拟服务器上的软件环境，而 Agent 可以先在本地容器里修改代码、安装依赖、运行服务并完成测试，确认没有问题之后，再把经过验证的版本部署到 VPS。相比直接在生产服务器上不断修改，这种方式显然更加可靠。它实际上也符合成熟软件工程中的开发、测试和部署流程，只不过过去需要开发者自己逐步执行，现在很多环节可以由 Agent 自动完成。
回头看整个 AIoT 平台的开发，其实本质上是一个不断循环和积累的过程。首先要把最基础的数据链路打通：传感器节点采集数据，网关负责汇聚和转发，服务器负责接收、存储和管理数据。之后才是如何把这些数据通过前端图表展示给用户，再进一步解决设备在线状态、异常告警、权限管理和远程控制等问题。每增加一个功能，往往都会同时涉及固件、通信协议、后端和前端，因此真正困难的地方并不是某一段代码，而是如何让节点、网关和服务器长期稳定地协同工作。Agent 的意义就在于，它可以极大降低这些跨层开发工作的成本。
从这些经验中，我很直接地体会到，Codex 这类 Agent 已经能够非常高效地辅助我完成大量软件层面的工作：传感器数据管线如何搭建、服务器如何接收和存储数据、后端如何管理设备、前端如何展示数据，这些工作都可以越来越多地交给 Agent。因此，如果未来基于这一模式继续创业，我真正需要投入更多精力的，反而可能是硬件系统本身：包括使用 SolidWorks 等工程软件进行结构设计、定义传感器和控制接口、选择和采购元器件、焊接 PCB，以及通过示波器、逻辑分析仪和功耗测试仪器进行调试。只要底层硬件能够稳定工作，固件能够成功烧录，后面相当一部分软件和平台开发工作都可以由 Agent 加速完成。
不过，这种开发方式也带来了一个新的要求：必须把整个工程过程规范化。接口定义、通信协议、数据库结构、设备状态机、函数功能和部署流程都应该形成文档，并且对已经验证稳定的模块进行版本冻结。因为对于持续工作的 Agent 来说，高质量的工程文档本身就是非常重要的上下文。有了这些明确的接口和规则，Agent 才能在未来添加功能、修改模块或者重构系统时保持整体一致，而不是不同模型、不同任务各自实现一套互不兼容的方案。
这也是我目前观察到的一个现实问题。对于大型 Web 工程，Agent 虽然能力已经很强，但系统越复杂，协调成本就越高。比如同时让不同模型开发前端和后端时，如果 API、端口和数据格式没有提前固定，就可能出现每个 Agent 都按照自己的方式设计接口，最终服务虽然分别能够运行，却无法真正整合。权限管理也是类似的问题：管理员和普通用户能够看到的页面不同，可以调用的 API、控制的设备和修改的数据也不同，一旦加入 RBAC、设备归属、多租户等机制，整个系统复杂度会迅速上升。但即使如此，现在的 Agent 已经能够帮助一个人承担过去可能需要一个小型开发团队才能完成的相当一部分工程工作。
这段经历也让我重新思考了自己本科所学的“测控技术与仪器”。未来真正有价值的方向，可能不仅仅是做一个智能传感器，而是进一步发展为 Agent 可以操作的智能仪器系统。Agent 不只是读取传感器数据，而是能够自主控制示波器、电源、功耗分析仪、信号发生器等设备，完成测量、分析、修改参数、重新测试，再根据结果继续迭代。因为 AI 如果真正想和物理世界交互，就必须拥有感知、测量和控制现实世界的接口。从这个角度看，AI Agent、AIoT、自动化测试和智能仪器之间其实是天然连接在一起的，而这也可能成为我未来继续深入探索的重要方向。
