北京
那个下午，团队五个人挤在屏幕前，盯着SigNoz里的那条实时的跨度河流。每一个彩色的短条都是一个模型调用，点击进去就是完整的OpenTelemetry追踪。我们给这套叫DevSwarm的系统接上可观测性时，心里想的是：这下可以证明它跑得多稳了。
一周后，数据告诉我们完全不是那回事。它没有证明我们有多正确，而是把我们之前对自己系统的所有信念，一个一个锤了个稀碎。
DevSwarm这个项目本身不复杂：你给一句提示，它自动吐出一个可运行的全栈应用。背后是五个开源模型——有的负责规划，有的负责写前后端代码，有的专门审稿挑错，还有一个管着它们的路由和回滚。每走一步，就是一个OpenTelemetry的跨度扔进SigNoz，好的、坏的、半路崩了的，全都记着。
就是这些跨度记录，连续六次对我们说：“你们搞错了。”我们挑出最具冲击力的四次分享出来，每一次都附上了能直接跑的ClickHouse查询。
第一回，我们骂一个模型太慢，怀疑是它天生性能差。跟踪一看，是我们在调度器里给自己设了个超时，这个模型因为输出稍长就刚好撞上线。提速的办法不是换模型，是把我们自己拍脑门定的那个数字改掉。第二回，某个推理供应商连续五分钟返回错误，我们第一反应是模型挂了，备注里已经打好“该模型不稳定”。结果跨度里明明白白写着，供应商层面全部503，连路由代理都健康得不能再健康——是我们错把云服务的锅扣给了算法。
最疼的一次，是关于那个审查 Agent。我们从一开始就认定它是整个链路里最强的角色：独立的纠错闭环，还能让别的智能体按它的建议改代码，安全感拉满。但把它的所有跨度拉出来和真实代码问题做个对照后发现，它抓到的BUG数量甚至没有随机采样多，而且改了两次之后副作用比收益大。那个我们以为最坚固的环节，其实才是最大的薄弱点。
还有一件我们一直挺得意的事——专门写了一套设计约束和UI规范喂给前端生成的部分，目的是让出来的页面更干净。连续几版迭代下来，上线时肉眼看着确实整齐了些。但把带设计约束和不带设计约束的两组建成基准对比之后，用户任务完成率反而下降了，因为那些整齐的界面增加了点击路径。数据说这个“设计系统”正在让输出变得更糟糕。
没有一个发现是回看代码看出来的。全出自一个跨度事件、一个仪表板上的波动、或一个和我们直觉唱反调的基准测试。
目前整个系统已经跑了22代生成，累计188次模型调用（覆盖8个模型）、消耗284万token。审查 Agent 拦截了225次明显问题，19次出错被自动回滚到上一个可用版本，生成了24个应用，每个应用都用它自己的服务名向SigNoz上报指标。这些数字不是我们写进幻灯片里的，是仪表盘上活的ClickHouse查询直接在跑的——连产品首页的营销文案都绑在这些实时查询上，再也没法说一套做一套。
所有调用全走HuggingFace的推理供应商接口，系统里没有任何闭源模型的API调用。这个决定本身后来也成了避免误判的关键——因为没有黑盒栈，每个跨度的细节都是透明的。我们后来才意识到，如果用了黑盒，有些“模型不行”的假象，永远洗不掉。
给多智能体系统做可观测性，和给单个模型做完全是两种难度。一次调用成功，可能产出了完全不可用的中间产物；一次静默降级可能让人压根不知道主路径已经死了；某个角色的响应时间悄悄翻倍，而在请求日志里什么都发现不了。当错误可以优雅地藏在协作里时，没有追踪，就等于盲飞。
所以整个项目里最先稳定跑通的，不是代码生成，而是那一条条连着因果的追踪。SigNoz通过Foundry自托管，单条配置就能重建一模一样的部署，我们的cast.yaml和lock文件全保存在仓库里，任何评委都能复现出来。
回头看，这个项目最值钱的产出，不是那些自动生成的应用，而是我们被迫养成的一个习惯：先看跨度，再下结论。因为智能体不会替你想清楚为什么错，但它留下的每一笔遥测，都等着你去发现自己的真相。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
