NOX 多账号达人报价与数据采集系统

集中执行以后，每位 PR 在任务电脑上都有一个对应的浏览器，只登录自己的 NOX 账号。工作台接到请求，总控调度模块再安排业务会话处理。

系统配置了四个共享业务会话，而不是每位 PR 固定占用一个。哪个会话空闲，就接下一项可执行任务；四个都被占用时，后面的请求等待。同一个账号、同一个业务会话，同时最多处理一单。

但这不是建好四个对话就能顺利运行。试跑时，任务经常卡在调度环节，围绕四任务并发进行了多轮调整。

这部分的底层技术，我当时并不熟悉。我会把卡住的位置和期望完成的结果交给 Work，让它排查原因、修改实现，再重新运行。我主要看实际结果：任务有没有继续、后面的请求有没有被接住、结果能不能返回，而不是只听一句“已经修好了”。

报价采集不是找到数字就结束了，还要知道这笔钱对应什么。

在开发和规则调试阶段，有一次我方明确询问 Instagram Reel 的合作费用。对方回复，$3,500包含一条 Reel 和一条 Story，也可以免费同步发布到 TikTok。

脚本抓到了金额和 TikTok，却判断成“我方询问 Instagram，对方只报 TikTok”，将其标为待复核，阻止自动提报。金额没有错，错的是平台与交付范围的关系。

我对照原始询价和回复检查：这笔费用对应的是 Reel＋Story，TikTok只是可选的免费附加安排；不能把整笔报价归到 TikTok，也不能自行拆出一个对方没有报过的“纯Reel价格”。

10月15日的复核结果保留了完整套餐：$3,500，1条Instagram Reel＋1条Story，可选免费同步到TikTok，记录结果来源为复核后，允许后续提报。这次发生的是调试阶段的误分类，不是错误报价已经被自动提交。

遇到这类问题，我建立专门的修正对话，整理原文、错误判断和正确依据，让 Work 协助调整脚本与当前规则。报价脚本累计迭代到第62版；四个业务会话共用当前依据，修改后再由总控组织对齐。 到这里，我们的规则迭代逻辑为：脚本根据现有规则处理，Agent对脚本无法处理的部分先自行处理再编辑规则。 因此，脚本的执行能力会越来越强大，需要Agent以及人工处理的数量会越来越少。

当提交、采集、判断和结果回传接起来以后，我检查的就不再只是脚本有没有运行结束。

这项请求属于哪个账号和项目，交给了哪个业务会话，已经整理了哪些结果，还有什么需要 PR 处理，都需要保留对应记录。结果回到原来的请求里，使用者才能继续工作，而不是再到任务电脑上找文件、问对话。

工作台中的结果表和历史任务入口，承接了这些输出。后台由调度模块组织执行，前台仍然按业务人员熟悉的项目和字段查看。原稿中的结果页面与历史任务记录展示的就是这部分实际产物。

这套系统让我经历了一次完整的上线，遇到问题之后又修改的过程，一个人用Workflow很简单，能把套能力复利给大家使用，中间的过程要比想象的复杂很多。对我来说，这次最重要的能力提升是：从自己发起、自己盯着的一段采集流程，走到了面向多人请求、有任务归属和结果交付的系统。