当被问到“学Rust还是Go”时，多数AI助手会给出一段两头不得罪的废话。但一个叫Fork的工具处理这种困局的方式相当“粗暴”：它直接启动两个独立的AI代理，一个专心当Rust孤儿，另一个铁了心走Go路线，两套人生同时在Web上搜索、推理、权衡后果，最后交一份带置信度的判断回来。没错，它不帮你折中，而是逼平行宇宙里的两个“你”各自真正活一遍。
Fork提交给Hermes Agent Challenge的这套方案，完全依赖本地的Hermes Agent REST API，用三个步骤就把分支决策变成了一场可围观的事件。第一步，你抛出一个两难问题；第二步，系统为每个选项各建一个完全独立的会话，两条线同时去真实互联网抓信息，搜索“Rust borrow checker问题”、“Go在云基础设施的采用情况”，拉取具体链接读内容，然后各自给出一个诚实的评判。第三步，一个仲裁型Agent坐下来比较两边带回来的“人生报告”，算出Rust胜出，置信度78%，并附上决定性的推理。
表面看这不过是个多路并发的Agent编排，但背后有些“坑”才值得拿出来聊聊。作者最初很自然地想到用Hermes内置的delegate_task把子代理扇出去。可他一读源码就发现了毛病：delegate_task会生成丰富的每子代理事件——subagent.start、subagent.thinking、subagent.tool——但这些事件专门伺候终端UI，故意不往REST API上转发。换句话说，你要是通过HTTP调用，原本热热闹闹的并行探查会坍缩成一个不透明的工具调用，看不见任何分支的动态，跟蒙着眼扔飞镖差不多。
所以编排的活不得不挪到应用层：同时开启N个完全独立的会话，每个分支都自己流式吐出assistant.delta推理和tool.started研究步骤，各自掏自己的token费。这才凑出那个能看见分支实时“生长”的决策树。另一个类似的蜜糖陷阱是Hermes的REST API本身开放了一个POST /api/sessions/{id}/fork端点，能在SessionDB里追踪分支谱系，和命令行的/branch对得上。Fork偏不用它。原因直白得有点反直觉——原生fork造出来的是一条带分支谱系的、可恢复的单条线，而不是N条各自独立的、能同时观察的实时数据流。你要真想在一屏上同步显示每个分支跑搜索、转念头的全过程，就必须让N个会话各自并行推送SSE，而不是挤在同一段托运记录里排队。
即便是流式传输本身也藏着点性格。Hermes把SSE事件做了简单命名：类型写在event:那一行，data:里的JSON却剔除了type字段。比如一行event: assistant.delta后面跟着data: {“delta”: “…”, “session_id”: “…”, “seq”: 3}。如果你像我早期调试时那样，傻傻解析data部分然后试图用data.type做分流，结果就是每个分支渲染出来全是空白——什么都没抓住。看清裸数据流的那一刻才顿悟，得把event:那行当作消息的判别符来跟踪。这事儿说起来半分钟，但发现之前足够你困惑一整个下午。
功能做得挺直男，界面却有意识地避开了暗黑仪表盘那套路数，更像一张画在暖色纸上的地图，安静地把每条路的延伸描出来。开发者想传递的感受很明确：做重大决定时，你能像看天气预报一样观察各种可能性长出枝叶，而不是对着一团黑盒给出的“平均主义”答案干瞪眼。所以，别再用一个Agent挤牙膏式地追问“要不要换赛道”了，直接让两个自己各去新世界试跑一圈，拿回来的或许不是标准答案，但至少是老实的体会。
热门跟贴