一个跑团正在为周末接力赛挑鞋。群聊里全是熟悉的味道：“买Pegasus，信我”“UK 9还是9.5？？”“干脆两个码都买，退一双”。四十条消息，全是自信满满的判断，关于每个人到底怎么跑，数据为零。
这正是vertiqal为Flip the Switch黑客松做Switch集成时想解决的问题：不是一个往群里甩鞋链接的机器人，而是一个让团队决策有据可依的房间——智能体是参与者，但它对房间里的人负责。
一条隐私约束，决定了整个设计
vertiqal的产品通过一段短视频或实时摄像头，测量你的运动方式：跑步看步频、落地方式、跨步幅度；攀岩看伸展、髋部位置和精度。核心承诺是视频永远不离开浏览器，MediaPipe姿态识别完全在设备端运行。
所以把运动视频发进聊天室从来不是选项——那会破坏产品自己的底线。真正流转的是一份签名的适配护照：一个HMAC签名的令牌，携带指标、信号、尺码和档案。房间看到的是回执，视频留在笔记本上。
这条约束反而成了整个设计的骨架。智能体拿不到视频去“解读”，它拿到的是一个可验证的凭证。如果测量有误，签名可以对着签发端点核验。
智能体是自己写的，没用编程智能体额度
团队没有Claude Code或Codex的额度，于是自己写了智能体：一个约400行、零依赖的Node脚本，直接说Switch智能体协议——WebSocket接收房间帧，HTTP操作对外发帖。模型调用只发生在vertiqal自己的端点内部，由智能体编排。
房间里的工作流是这样的：
- 队友分享护照，粘贴链接或在应用里点“发送到团队房间”；
- 智能体抓取并验证，然后发一条人话摘要：“Demo road runner，步频164，后跟着地，跨步14厘米——在找缓震日常训练鞋”；
- 然后它等着。没人输入“approve £140”之前，什么都不跑。审批闸门就是重点——智能体不能自作主张花钱，甚至不能自作主张搜索；
- 获批后它执行真正的适配：目录搜索、基于测量的推荐、附零售商链接；
- 然后是诚实的那部分：它去零售商自己的页面查库存，遇到cookie弹窗或403拦截时，它说“库存：不明确——我们从不猜”；
- 最终方案落进房间，每份回执都附上。房间里有两份护照时，它还会提出接力顺序，并明确标注这是步频启发式。
演示用的是真实的Mattermost频道，不是模拟界面：两名队友全程在镜头前跑完流程，一个分享护照，一个批准预算，智能体在两人之间回帖。另有一个check命令，粘贴产品名，智能体通过签名的适配判定端点对照最新护照打分，同样走第二道审批循环。
它拒绝猜，这成了最被记住的一幕
任何演示都能让智能体返回一堆鞋链接。vertiqal的演示里，智能体回来说的是：“尺码就在页面上——一个cookie弹窗挡住了我，无法确认。判定：不明确。”编造的成功不如诚实的失败，而在一个共享房间里，正是这份诚实让回执有了价值。评委反复告诉他们，就是这一刻，他们开始信任其余部分。
团队还在真实Switch（v0.31.0）上踩了几个坑，写进了运行手册：帧格式是{event, data}而不是{type, payload}，消息字段还多嵌一层；连接时必须声明房间，否则收不到任何房间事件；自己发的帖子不会回显给自己，得留本地上下文兜底；寻址策略默认是opt-in，需要通过网关接口改成anyone；thread_id在消息路由上被接受，但在Mattermost桥接里目前是平铺渲染。为了脱离Switch迭代，他们还写了一个100行的本地替身，整个循环在localhost上跑通。
对Switch的下一步，团队提了三个愿望：真正能在桥接里渲染的线程支持；一个签名回执原语，让智能体给帖子附上可验证的来源（他们不得不自带HMAC）；以及隧道和控制台的重连能力——演示中途掉过一次线。
把镜头拉远，这个思路的形状很通用：任何一群人共同做的购买——队服、俱乐部装备、共用器材——都遵循同样的流程。私下测量，携带签名回执，在房间里决策。鞋只是证明。
热门跟贴