飞驼网络

飞驼网络 · 能力内核

判断密集的地方，
交给算得清的引擎

判断密集的环节，过去只能靠老师傅：报价对不对、这单该不该拦、异常算谁的责任。Flyto Agent 把这类判断变成可以计算、可以复核、可以回退的决策。它先在旁边影子运行一段时间，数字对得上才让它真的动手；评分永远不直接改状态，写业务数据只能走业务系统的接口。

聊聊你的场景 看应用场景

为什么需要它

大多数企业系统只记录，不决策

先做一道题：在你的业务里，找出这样的环节——每天重复几十到几百次，做对做错差的是真金白银但当场看不出来，换个人做结果就不一样，而做这件事的人休假一周就会有人焦虑。

这些环节就是判断密集区。它们通常不在流程图上，因为流程图只画得出「谁把单据传给谁」，画不出「这一单该给哪家承运商」。

ERP 记下发生了什么，BI 告诉你发生过什么，报表把这些整理成好看的图。这一层非常必要，但它有一个天花板——记录不产生判断。系统告诉你「这批单超时了」，它不会告诉你当时该发给谁；系统把账单和报价并排列出来，但逐行核对差在哪，还是得靠人一眼一眼看。

于是判断继续留在人身上。这不是员工的问题，是这些判断从来没有被结构化过。

引擎能力

把判断结构化的四件事

  • Modeling

    场景建模

    把业务场景描述成引擎能理解的结构：要做的判断是什么、输入有哪些、口径和边界在哪、什么输出是绝对不允许的、多久之后才知道对错。场景变了改描述，不是改代码；新场景以模块叠加接入，不替换既有的东西。

  • Boundary

    执行边界

    AI 负责决策，业务系统的接口负责执行，AI 不直接写业务数据库。库存不能为负、金额精度不能丢、状态机不能跳步——这些不变量已经被业务系统守了很多年，绕过它直接写库等于把守了多年的门拆掉。上 AI 不等于把生产数据交给 AI。

  • Guardrails

    三层防御

    指令层约束方向，参数层限制它能做什么（做不到的事情比嘱咐它不要做可靠得多），兜底层接住前两层漏掉的一切。原则只有一句：永远不假设模型会百分之百遵守指令。

  • Audit

    留痕与反向论证

    每个决策记录输入、依据和上下文，出问题能回放而不是对着结果猜原因。代价高、不可逆的动作还要先产出一份结构化的反面论证：隐含了哪些假设、什么情况下会失败。

  • Pluggable

    可插拔

    多家大模型服务与本地部署模型共存，按场景的成本、延迟和质量要求选配，不被任何一家绑定。数据敏感的场景可以完全在企业内网推理，数据不出内网。升级引擎不需要把已有集成重做一遍。

已落地

物流报价对账

首个验证场景，在飞驼自己的物流业务里用真实账单跑通。承运商的报价是给人读的，不是给系统读的。首重续重、重量段、省市分档、生效日期、优先级、退件费、体积重比例，散落在一张张表格和调价通知的截图里——不结构化就没法自动算钱。

  • 把报价表读成结构

    抽取由分工明确的角色协作完成：负责抽取的一方读表，一个独立的校验环节检查结构本身成不成立（重量段有没有首尾相接、是否单调、单位对不对），再由主导方判定通过还是重来。

  • 直接对齐已有价格表

    抽出来的东西不是又一份没人能用的中间格式，而是直接就能拿去算钱的价格表，字段、单位、层级一一对应。中间多一层翻译，就多一层出错的概率。

  • 模糊的地方不硬猜

    原表没写明白的部分，引擎给出推断值的同时标记「不确定」，附上原文片段和原因。必要时直接向人提问，操作员的每一次答复都成对留档。

  • 确定的事交给代码

    比如日期合法性校验，一行解析加一张表就能定死的事，交给模型既浪费它的注意力又可能漂移。该由代码守的边界，不要交给模型。

  • 验收由独立角色做

    实测发现能力足够的主导方也会给自己盖章。所以「这次抽得对不对」必须由另一个不参与抽取的角色来判。

  • 三方比对与差异归因

    账单、报价、实际计费三方逐条比对，差异定位到具体条目：是哪一单、哪个包裹、差在哪个规则上。再区分是取整口径不一致、区域分档判定不同、报价版本用错了，还是本来就该有的附加费。

  • 收敛不等于正确

    系统完全可以收敛到一份自洽但错误的结果。我们真实遇到过一次：抽取把偏远地区首重定成 3 公斤，所有结构校验都通过，而原表表头明写 1 公斤。结论是：只查结构不够，必须有一次对真值的确认。

  • 为什么先做它

    判断密集、规则复杂、错了有明确代价——三条同时成立的场景不多见。而且它是我们自己每个月都要吃一遍的痛，改进的动力不需要被说服。

正在铺

下一批场景

每个场景都来自飞驼自己业务里真实的判断瓶颈——我们自己就是第一个客户。下面这些正在推进中，我们不会把还没上线的东西说成已经有的。

  • 履约决策 ↗

    承运商分配：同一个目的地，不同承运商的时效、价格和当前时段的稳定性都不一样，这是每天要做上万次的判断。以及月度量级承诺的风险预警。承诺量往往绑着价格阶梯，难点是要在月中就预警，而不是月底结算才发现——差一个百分点，一个月就是一笔明账。

  • 经营与 ERP

    补货、备货、库存健康度的判断。什么时候该补、补多少、哪些货正在变成呆滞——从盯报表的人转移给盯数据的引擎，人只处理引擎标出来的异常。

  • 销售与 CRM

    线索分级、跟进时机、流失预警。销售团队里最好的那个人凭什么判断这条线索该先打——把那套判断结构化出来，变成团队的下限，而不是某个人的天赋。

  • 财务结算

    账款异常识别、开票合规检查。财务工作里大量时间花在「核对没有问题的部分」上，这部分应该由机器完成，规则跑在前面，人处理例外。

  • 广告投放

    出价调整、素材更替的决策建议。把「盯盘」变成「审批」——引擎给出建议和依据，人决定要不要采纳，而不是一整天盯着后台等波动。

  • 经营决策

    把分散在各系统的经营信号收敛成结构化的判断建议。给管理层的应该是结论加依据，不是一堆需要自己解读的报表。

怎么落地

从影子运行到逐步接管

不做「上线即替换」。决策系统进入真实业务，必须用可回退的方式——每一步都能停下来，也都能退回去。

  1. 场景摸底

    把现场的判断规则、数据口径和异常情况摸清楚，先确认这个场景值不值得结构化：判断密度够不够高、依据是否可获得、对错能不能被验证、错了的代价清不清楚。不值得我们会直说。

  2. 影子运行

    引擎在真实数据上做决策，但不生效。只比对它和人的判断差在哪里、差多少。这一步没有任何业务风险，却能在放量之前就知道它大概会怎么表现。

  3. 人机并行

    引擎给建议，人做最终决定。这一段积累的是信任，也是样本——每一次人否决引擎的记录，都是下一轮改进的输入。

  4. 逐步接管

    高置信度的决策交给引擎，人处理例外。范围随验证结果扩大，不是一次性交出去；质量异常时引擎自动熔断，回退到人工或既有规则。

想看更深的

这几篇写得更细

从一个场景开始

不需要一开始就全面铺开。挑一个判断最密集、最依赖个人经验的环节，我们一起把它结构化。行业不重要，判断密度才重要。

描述你的场景 读长文

获取方案与报价

留下联系方式，让飞驼主动找您

留一个电话，简单说说你的行业和最让你头疼的判断环节。我们先做免费的场景评估：这个场景值不值得结构化、从哪一步开始、大概需要什么条件。评估完你再决定要不要往下走。

仅用于本次业务联系，不会有人死缠烂打。