北京
一家食品制造商收到供应商更正通知：此前交付的两批可可原料中，含有一种源自牛奶的成分，而最初的申报里没有这一项。问题随即落到生产端——这些原料被哪些批次消耗过，当时用的是哪一版配方和包装，由此形成的库存又对应哪些客户出货。
只翻当前配方找不到答案。真正决定处置动作的是历史链条：原料批次、配方版本、过敏原声明、工厂与仓库、预留与发运记录，以及发运背后的订单和客户。SpecCascade 这个项目要做的，就是把这条链上的事实连起来查。
项目方构建了一个名为 Northstar Foods 的合成演示场景：120 个合成批次、12 个产品、3 家供应商、2 个生产设施。主通知涉及两个确切的原料批次。图谱遍历与策略评估给出的结果是：24 个批次确认受影响，4 个批次的消耗证据尚未厘清，92 个批次不受本次通知影响。需要封存控制的合计 28 个批次，其余 92 个保留可用资格。
这里有个容易被忽略的区分：配方归属和实际消耗是两件不同的事实。两个批次可能属于同一产品族，但消耗的是不同批次的到货原料。仅因为“看起来相似”就把两者一起停掉，会丢掉这套系统本来要提供的精确度。那 4 个证据未明的批次也没有被含糊处理，而是被明确保留为未知状态。
项目方对这批数字的边界说得很清楚：这是构建数据集上的测量结果，不会换算成虚构的工厂节省金额，也不宣称真实世界中的检出准确率。
在响应环节，应用把调查、响应协调、恢复计划、独立验证和记忆拆开。基于 OpenAI Agents SDK 的集成暴露了一组有边界的工具，覆盖策略检查、记忆检索、历史遍历、批次证据、任务创建、封存与验证。发现和任务通过 FalkorDB 共享，模型拿到的是真实的工具返回结果，库存处置则由人工 QA 权限和证据要求来约束。
计划本身不能证明 ERP 已经改变。FalkorDB 记录来源证据、决策和意图动作，另一套事务型 SQLite 存储记录实际模拟的库存、扣留、发运和处置。协调器执行扣留后，被扣留库存的发运会被拒绝；QA 审阅支撑证据并记录具体处置；验证器再重新查询来源关系，与实际库存、发运和审批状态比对。
测试里故意移除一项必需的扣留，并让一次 ERP 写入失败。结论很直接：调查做得再对，也不能自动通过执行验证。
记忆同样有适用边界。一次已验证的事件会成为持久化 episode，连同调查过程和证据一起挂接，可复用的处置流程也记录在旁。后续检索会核对供应商、过敏原、因果机制和记忆有效性。既往经验可以提示该查什么，但不能授权放行新批次——新的调查仍要遍历当前关系，过期 episode 会被排除。
为了证明图谱确实在干活，项目做了几组对照。受限上下文模式下，系统无法建立暴露关系，也无法执行封存。在一次真实的 FalkorDB 故障期间，依赖它的接口返回 503，而不是编造答案。其他测试改动已消耗批次、历史声明、来源完整性和发运状态，结果随这些关系变化。常规重启检查则比对重启前后的持久化图谱、记忆和企业状态。
评估与证明界面会展示实际执行的 Cypher、参数、行数和实测耗时。判断者可以查看结果背后的证据，而不是依赖事后一段自信的解释。
项目复盘里提到，最难的工程问题是哪些证据足以支撑一个动作。历史因果、不确定性和来源版本，比再加一个指标更重要。另一个收获是区分封存与解决：事件可以被控制住，而批次文档仍未厘清，独立验证负责报告这条边界。
后续计划包括 ERPNext 与供应商邮件适配器、经审阅的文档抽取、生产身份与审批签名，以及多系统写入的更强恢复能力。这些属于未来集成，不是当前应用已具备的能力。项目面向“对关联数据采取行动的智能体”和“智能体记忆与协调”两个方向，开发过程中使用了 Codex AI 编码辅助，参与者的审阅、验证和技术理解仍不可省略。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
