Shipment Verification 的运用场景

本文将从用户角度介绍 Shipment Verification 的运用场景,该场景中涉及到两个供应商和两个零售商之间使用 Shipment Verification 进行运输、收货的过程,以及这个过程需要的所有的配置。

介绍

Shipment Verification 是基于 IBM WebSphere RFID Information Center(RFIDIC) 的应用系统。该应用面向供应链领域,是 IBM RFID Solution 的方案之一。

Shipment Verification 使得供应链运输双方(运输方和接收方)能够实时查看所有运输和接收商品的列表、以及每一类商品的状态,极大地提高企业供应链运输双方之间信息的可见性,使得整个供应链可以更好的整合,达到增加供应链反应速度、提高客户满意度、以及减少成本等目的。

本文将从用户角度上介绍 Shipment Verification 的运用场景,该场景中涉及到两个供应商和两个零售商之间使用 Shipment Verification 进行运输、收货的过程,以及这个过程需要的所有的配置。





回页首


Shipment Verification 的组件结构


图 1. Shipment Verification 的组件结构
Shipment Verification 的组件结构

由上图我们可以看出 Shipment Verification 系统建立在 RFIDIC 的基础上。Shipment Verification 应用于供应链运输的交易双方,我们结合运输方运输与接收方接收这两个业务来进一步描述 Shipment Verification 的运行机制。

运输方运输

运输方执行运输业务流程的时候,相应的 EPCIS Event 将从“Premises Server”产生,并存放入运输方的 RFIDIC 的 MQ 中,该事件将被 RFIDIC 捕获,经过 TDI Assemble Line 解析,并最终存放入运输方的 RFIDIC 的数据库中。这时可以从运输方的 Shipment Verification 的“Shipment Verification Dashboard”中查看到运输列表及其状态,状态应为“正在运输中”。

由于供应链上下游的不同 RFIDIC 系统之间由于存在业务关系,所以互相注册了相关的 subscribe query。subscribe query 根据配置会间隔一段时间运行,并会把最终的查询结果 (Query Response) 返回到相应的目的地址。在 Shipment Verification 中,接收方在运输方注册了 subscribe query,查询的返回结果会被接收方的“HTML Listener”接收,并存入接收方的 RFIDIC MQ 中,该事件列表将被 RFIDIC 捕获,经过 TDI Assemble Line 解析,并最终存放入接收方 RFIDIC 的数据库中。这时可以从接收方的 Shipment Verification 的“Expected Received Dashboard”中查看到接收物品列表及其状态,状态应为“正在运输中”。

接收方接收

接收方执行接收业务流程的时候,相应的 EPCIS Event 将从“Premises Server”产生,并存放入接收方的 RFIDIC 的 MQ 中,该事件将被 RFIDIC 捕获,经过 TDI Assemble Line 解析,并最终存放入接收方的 RFIDIC 的数据库中。这时可以从接收方的 Shipment Verification 的“Expected Received Dashboard”中查看到接收物品列表及其状态,状态应为“运输完成”。

运输方在接收方 RFIDIC Server 上注册的 subscribe query 根据配置会间隔一段时间运行,并会把查询结果 (Query Response) 返回到相应的目的地址,即运输方。在 Shipment Verification 中,返回的结果会被运输方的“HTML Listener”接收,并存入运输方的 RFIDIC MQ 中,该事件列表将被 RFIDIC 捕获,经过 TDI Assemble Line 解析,并最终存放入运输方 RFIDIC 的数据库中。这时可以从运输方的 Shipment Verification 的“Shipment Verification Dashboard”中查看到运输列表及其状态,状态应为“运输完成”。

通过这种结构,供应链运输业务交易双方能够及时地获取到对方 RFIDIC Server 中相关的 EPCIS Event 数据,及时地查看到运输货物列表及其状态。

具体的过程以及显示的界面和结果,在下面的应用场景中有详细的描述和介绍。





回页首


应用业务场景

组织结构

假设存在两家供应商 (Shipper1 和 Shipper2), 和两家零售商 (Receiver1 和 Receiver2)。它们之间存在业务往来,我们使用 RFIDIC 和 Shipment Verification 来实施他们之间的运输流程。

下图是供应商 Shipper1 的基于地域的组织结构图,图中 Shipper1 有两个工作地点,其中 Shipper1_Picking & Packing 是进行拣货、包装的场所,包装后的产品会运往下一个工作地点 Shipper1_Shipping 进行运输。


图 2. 供应商 Shipper1 的基于地域的组织结构图
供应商 Shipper1 的基于地域的组织结构图

Shipper2 的组织结构和 Shipper1 类似,如下图所示:


图 3. 供应商 Shipper2 的基于地域的组织结构图
供应商 Shipper2 的基于地域的组织结构图

下面两张图是供应商 Receiver1 和 Receiver2 的基于地域的组织结构图。其中 Receiver1 只有一个工作地点:Receiver1_Receiving,它用于从接收供应商运输过来的产品。Receiver2 的组织结构也类似。它们分别如下图所示:


图 4. Receiver1 和 Receiver2 的基于地域的组织结构图
Receiver1 和 Receiver2 的基于地域的组织结构图

业务流程

下图是整个应用场景的流程图,所有的业务流程分别属于两个供应商 Shipper1, Shipper2 和两个零售商 Receiver1,Receiver2。

  • 图中“ Commission1”,“Aggregate1”,“Shipping1”业务是属于 Shipper1,其中“ Commission1”,“Aggregate1”业务是在“Shipper1_Picking & Packing”场所进行,“Shipping1”业务是在“Shipper1_Shipping”场所进行。
  • 图中“ Commission2”,“Aggregate2”,“Shipping2”业务是属于 Shipper2,其中“ Commission2”,“Aggregate2”业务是在“Shipper2_Picking & Packing”场所进行,“Shipping2”业务是在“Shipper2_Shipping”场所进行。
  • 图中“ Receiving1”业务是属于 Receiver1,并在“Receiver1_Receiving”场所进行。
  • 图中“ Receiving2”业务是属于 Receiver2,并在“Receiver2_Receiving”场所进行。

图 5. 整个应用场景的流程图
整个应用场景的流程图




回页首


安全配置以及数据准备

硬件及软件准备

整个用户场景需要四台计算机,两台用于模拟两个供应商,两台模拟两个零售商。这四台机子分别安装 IBM RFID Information Center1.0.0.0 和 Shipment Verification1.0.0.0,之后下载下面的链接文件,并保存到这四台机子的 $RFIDIC_HOME/sv_scenario 中。sv_scenario 的文件结构如下表所示:

文件夹 描述
event_data 模拟的 RFID 事件文件
mdm_data 本文的用户场景需要的 master data
security 供应商和零售商之间用于权限控制的 Policy 文件
query 供应商和零售商之间进行 subscribe query 的查询文件
sql 常用的 sql 语句

导入 Master Data

安装完 RFIDIC1.0.0.0 以及 Shipment Verification1.0.0.0 以后,需要为应用导入 Master Data。Master data 相对于 Event Data 来说是辅助数据,它为 Event Data 中的字段提供了上下文的作用。RFIDIC 中 Master Data 有以下三种:

  • Location Master Data
  • Product Master Data
  • Vocabulary

本文的例子所需的 Master Data 以及每一个 master data 文件的含义如下表所示,这些文件位于 $RFIDIC_HOME/sv_scenario/mdm_data 目录下面。

Master data file 描述
1_locations.xml Location master data
2_readpoints.xml Read point master data
3_products.xml Product master data
4_locationHierarchy.xml Location Hierarchy master data
5_productHierarchy.xml Product Hierarchy master data
6_standardVocabularies.xml 标准的 vocabulary
7_userVocabularies.xml 用户扩展的 vocabulary

导入 Master Data 可以使用 RFIDIC 的安装目录下的一个 Shell 命令进行导入,即 $RFIDIC_HOME/bin/import-masterdata.sh 命令,但该命令一次只能导入一个 Master Data 文件。本文的例子中使用了一个 Shell 脚本来导入所有的 Master Data,脚本中依次导入所有的 Master Data。脚本位于 $RFIDIC_HOME/sv_scenario/mdm_data/importAllMasterdata.sh,执行该脚本将导入所有所需的 master data。

Security 配置

RFIDIC 和 Shipment Verification 的安全配置包括两个部分:用户验证,权限。下面分别来介绍这两个部分的配置:

  1. 用户验证

用户验证设置哪些用户可以访问 RFIDIC 和 Shipment Verification,可以通过配置 WebSphere Application Server 的验证机制来达到用户验证的目的。

  • Enable Global Security 以及 user registry 配置

在代表供应商和零售商的四台 RFIDIC Server 中,访问 WebSphere Application Serve 的 console 页面,打开 Security->Global Security 配置页面,选上“Enable global Security”,选择 Active user registry 为“Local OS”。配置后的页面如下图所示(该配置重启后生效):


图 6. 配置后的页面
配置后的页面
  • Map security roles to users/groups
  1. 在两台供应商 (Shipper1,Shipper2) 的 RFIDIC Server 中,创建操作系统用户 receiver1, receiver2 和组 receiver1, receiver2,并且 receiver1 用户属于 receiver1 组,receiver2 用户属于 receiver2 组。访问 WebSphere Application Serve 的 console 页面,在Enterprise Applications > com.ibm.rfidic.webEAR > Map security roles to users/groups 配置页面中,依照下图进行配置:

图 7. 配置页面
配置页面
  1. 在两台零售商 (Receiver1,Receiver2) 的 RFIDIC Server 中,创建操作系统用户 shipper1, shipper2 和组 shipper1, shipper2,并且 shipper1 用户属于 shipper1 组,shipper2 用户属于 shipper2 组。访问 WebSphere Application Serve 的 console 页面,在 Enterprise Applications > com.ibm.rfidic.webEAR > Map security roles to users/groups 配置页面中,依照下图进行配置:

图 8. 配置页面
配置页面
  1. 在全部的四台 RFIDIC Server 中,访问 WebSphere Application Serve 的 console 页面,在 Enterprise Applications > com.ibm.rfidic.pharma.shipverEAR > Map security roles to users/groups 配置页面中,依照下图进行配置:

图 9. 配置页面
配置页面
  1. 权限

Shipment Verification 的权限机制是建立在 RFIDIC 的基础上,它本身并没有权限控制。本文为 Shipper1,Shipper2,Receiver1,Receiver2 定义了 Policy 配置文件,可以通过 RFIDIC 的 Security Policy Editor 的 Import 操作导入到 RFIDIC 中。下表描述了不同的 RFIDIC Server 对应的 Policy 配置文件,这些配置文件在 $RFIDIC_HOME/sv_scenario/security/ 目录下:

Policy 文件 RFIDIC Server
securityPolicyShipper_On_Receiver1.xml 导入 Receiver1 的 RFIDIC Server 中
securityPolicyShipper_On_Receiver2.xml 导入 Receiver2 的 RFIDIC Server 中
securityPolicyReceiver_On_Shipper1.xml 导入 Shipper1 的 RFIDIC Server 中
securityPolicyReceiver_On_Shipper2.xml 导入 Shipper2 的 RFIDIC Server 中

我们以 Shipper1 为例子,介绍如何导入 securityPolicyReceiver_On_Shipper1.xml policy 文件。

  • 访问http://shipper1:9080/com.ibm.rfidic.web/admin 弹出下面的对话框,输入 rfidic 用户及其密码,按确定按钮登录。

图 10. 登录
登录
  • 访问 Security Policy Editor,选择 Import 操作,并选择
    “securityPolicyReceiver_On_Shipper1.xml” policy 文件,界面如下图所示:

图 11. Import 操作
Import 操作
  • 选择 Import 按钮,执行导入 policy 操作,成功后界面如下所示:

图 12. 操作成功
操作成功
  1. Subscription query

RFIDIC Server 的查询接口遵循 EPCIS 的规范,不同的 EPCIS Server 之间通过 query 接口相互交互,获取权限控制以内的数据,这些数据包括 Master Data 和 Event Data。在 Shipment Verification 应用中,为了及时获得供应商和零售商之间的业务信息,交易双方在对方的 EPCIS Server 上注册了 subscribe query。通过这种查询,可以周期性地查询交易对方的 EPCIS Server,并发送需要的数据到自身的 EPCIS Server 中。下面的表格中描述了供应商和零售商之间注册的 subscribe query,这些 subscribe query 的查询文件在 $RFIDIC_HOME/sv_scenario/query 目录下。

注册的 RFIDIC Server subscribe query Description
Receiver1, Receiver2 Shipper1_queryRequestOnReceiver.xml Shipper1 在 Receiver1/Receiver2 的 RFIDIC Server 上注册的 subscribe query
Receiver1, Receiver2 Shipper2_queryRequestOnReceiver.xml Shipper2 在 Receiver1/Receiver2 的 RFIDIC Server 上注册的 subscribe query
Shipper1, Shipper2 Receiver1_queryRequestOnShipper.xml Receiver1 在 Shipper1/ Shipper2 的 RFIDIC Server 上注册的 subscribe query
Shipper1, Shipper2 Receiver2_queryRequestOnShipper.xml Receiver2 在 Shipper1/ Shipper2 的 RFIDIC Server 上注册的 subscribe query

这些 subscribe query 文件中的 标签中填写的值是相应 subscribe query 返回查询结果的目标地址。比如:Shipper1_queryRequestOnReceiver.xml 中的 应该填写http://shipper1:9080/HttpToMQ/EPCISQueryResults,其中 shipper1 表示 shipper1 的 IP 地址。其它的 subscribe query 文件类似。





回页首


小结

通过这一篇文章,介绍了基于 IBM RFID Information Center1.0 的应用系统 Shipment Verification 的结构、应用的业务场景、安全配置等。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9403012/viewspace-161/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/9403012/viewspace-161/

可控AI代理:从黑箱涌现到白盒控制的工程化实践 AI代理在真实业务中频繁失稳,根源在于将‘智能’等同于不可控的概率推理。本文围绕‘控制优先’范式,解析如何通过模块化架构、契约化接口与可观测性设计,将大模型能力封装为可预测、可审计、可降级的工程组件。核心聚焦意图解析、工具注册、状态管理、决策路由四大关键技术环节,解决AI系统在高并发、多变业务逻辑下的可靠性与成本难题。面向正将AI从Demo落地为生产基础设施的工程师与架构师,提供一套经实战验证的可控AI代理构建方法论。 阅读详情

相关推荐

AI Agent语义防火墙:用本体校验拦截资金类错误

AI Agent在生产环境中常因自然语言理解偏差导致严重业务事故,如误退款、越权操作等——其根源并非代码缺陷,而是‘语义断层’:同一术语(如user、customer)在产品文档、数据库、风控策略和Agent内存中缺乏统一定义。OntoGuard作为一种轻量级语义验证中间件,通过YAML定义的本体模型(ontology)将业务常识转化为可执行校验规则,在Action执行前完成Schema一致性、上下文感知约束与跨Tool语义连贯性三重检查。它不替代传统API校验,而是补足LangChain等框架缺失的‘语义

aikunjiao3421的博客 473

scenario知识点总结

名词解释: PVT:process(工艺制程),voltage(工作电压),temperature(工作温度) RC corner:TLU+ MMMC:multi mode multi corner OCV:on-chip viration constraints:mode/SDC WCBC:worst case best case scenario组成: scenario=PVT...

hepiaopiao_wemedia的博客 3800

OpenAI DevDay新工具实操指南:AgentKit、Sora-2与gpt-realtime-mini工程落地解析

大模型应用已从单点调用迈入系统化工程阶段,核心挑战在于调试不可见、依赖难统一、演进不自动。OpenAI DevDay发布的AgentKit、Sora-2和gpt-realtime-mini并非简单功能叠加,而是围绕可追溯性(provenance_hash)、状态机驱动(state-driven workflow)和物理约束建模(physics_constraints)三大技术原语重构AI基建。其价值体现在降低语音流延迟至290ms、支持视频生成中重力/粘度等物理参数控制、以及通过MCP协议实现跨平台App无

422

Shipment Verification 的应用过程

介绍 本部分主要来介绍 Shipment Verification 的应用过程。 回页首 模拟 EPCIS Event 数据 每一步业务流程操作都会产生相应的 EPCIS ...

ciyi7513的博客 254

跨境元器件采购风险规避实战:从付款条款到物流选择的全面风控指南

在国际贸易中,供应链风险管理是保障交易安全的核心环节。其基本原理在于通过结构化设计,在买卖双方之间建立权责对等的履约保障机制,从而有效应对货物流转过程中的不确定性。从技术价值看,一套完善的风控体系不仅能避免财货两空,更能提升整体采购效率与供应链韧性。在电子元器件跨境采购这一具体应用场景中,面对美国海关日益严格的审查环境,采购方需系统性地从交易结构上构建防线。其中,灵活运用第三方托管(Escrow)服务,将货款置于中立平台监管,是实现“货到付款”理想状态的有效折中方案;同时,主动选择清关口碑更优的物流承运商(

weixin_30410119的博客 456

【信息科学与工程学】【制造工程】计算机科学与自动化——服务器制造中的学科知识01

由可数可加性:μ(A)=∑k=1∞​μ(Bk​)=limn→∞​∑k=1n​μ(Bk​)=limn→∞​μ(⋃k=1n​Bk​)=limn→∞​μ(An​)。:若limsupAn​=liminfAn​=A,则A中的元素恰是那些“最终总是属于An​”的元素,也是那些“属于无穷多个An​但不属于无穷多个Anc​”的元素。:通过构造一个不相交的序列{Bn​},其中B1​=A1​, Bn​=An​∖(⋃k=1n−1​Ak​)。则⋃n​Bn​=⋃n​An​,且Bn​⊂An​。我们称A为一个“集类”或“集合族”。

weixin_49199313的博客 568

Chokepoint Atlas催化剂跟踪清单:如何盯住财报、认证与产能节点建立监控系统

Chokepoint Atlas(卡脖子美股战法)把"一次性分析"升级为"时间轴监控":通过催化剂跟踪清单,持续盯住财报日期、认证里程碑与产能节点,让供应链瓶颈研究不再停留在某一次结论上。下面用这份开源项目的现成模板和脚本,带你搭一套可复用的催化剂监控系统。 [![Chokepoint Atlas 催化剂跟踪与供应链瓶颈研究流程信息图](https://raw.gitcode.com/gh_mi

gitblog_00060的博客 1122

解放双手!利用海康VM全局脚本+通讯管理打造自动化视觉控制系统

本文深入探讨了如何利用海康VisionMaster(VM)的全局脚本和通讯管理功能,打造高效自动化视觉控制系统。通过全局变量实现数据共享与动态调整,结合多协议通讯管理,提升系统响应速度与智能化水平,适用于工业4.0环境下的复杂视觉检测与决策场景。

weixin_28720573的博客 424

Qwen3.6-Plus:面向工业交付的契约式大模型架构解析

大语言模型正从‘能力展示’走向‘确定性交付’,其核心演进是将业务约束(如JSON Schema、正则校验、跨字段逻辑)深度融入推理过程,实现格式稳定、逻辑保真、响应可控的工程化输出。Qwen3.6-Plus通过原生工具调用协议增强与长上下文稳定性增强两大关键技术突破,显著提升结构化生成质量与多跳推理可靠性,适用于电商客服、SaaS功能嵌入、客户反馈处理等强规则、高并发、低容错的真实业务场景,标志着大模型正式进入‘任务契约驱动’的工业部署新阶段。

weixin_30652491的博客 309

利用绝对式编码器实现电机无限旋转的配置与优化

本文详细解析了如何利用绝对式编码器实现电机的无限旋转功能。通过切换驱动器编码器工作模式、精确计算逻辑位置范围等关键配置步骤,解决了传统方案在多圈计数溢出时的定位难题。该方案无需硬件改造,适用于大型回转台、连续供料系统等需要大范围连续绝对定位的自动化场景。

weixin_29184371的博客 239

6.3 节深度拆解:Hermes Agent 多 Agent 协同执行链路的 4 层设计逻辑

拆解 Hermes 多 Agent 协同的 4 层工程化设计(协议层、编排层、执行层、适配层),聚焦协议层的强约束消息 Schema 如何解决 Agent 间语义不一致问题,并提供 `soul.md` 配置、GLM-4.7Flash 结构化输出验证及 v0.13.0/v0.14.0 版本实操避坑指南

weixin_42520239的博客 122

亚马逊协议三实战通关:视频化政策响应机制

亚马逊卖家合规运营的核心在于准确理解并即时响应平台政策,其中‘协议三’(Seller Performance Policy)作为账户健康与商品上架的刚性依据,直接影响流量分配与账号存续。其本质并非静态条款汇编,而是由主干政策、类目细则与实时公告构成的动态执行体系,需结合后台操作路径、系统级交互逻辑与视觉化反馈进行落地。视频通关模式通过真实界面录屏、鼠标轨迹引导与错误弹窗还原,将抽象政策转化为可识别、可触发、可验证的动作节点,显著提升UN38.3报告上传、图像合规检查、申诉信撰写等高频场景的执行准确率与响应速

weixin_30896511的博客 405

《信息化项目文档模板十二——业务需求新增/变更审批确认表 》

系列文章目录 《信息化项目文档模板一——项目需求说明书》 《信息化项目文档模板二——项目启动会文档模板》 《信息化项目文档模板三——会议纪要模板》 《信息化项目文档模板四——系统项目蓝图设计模板》 《信息化项目文档模板五——系统详细设计模板》 《信息化项目文档模板六——系统详细设计模板》 《信息化项目文档模板七——系统开发计划模板》 《信息化项目文档模板八——系统功能测试模板》 《信息化项目文档模板九——系统压力测试模板》 《信息化项目文档模板十——系统推广上线计划模板》 《信息化项目文档模板十一——系统用

商务合作|问题讨论|交流学习 请联系作者微信,加微信请务必注明来意,博客主页有联系方式 1712

自运转单元(SOU):面向业务闭环的AI智能体系统设计

自运转单元(SOU)是一种以组织化结构建模的AI智能体系统,它超越传统工作流与单体Agent,通过角色分离、契约化交互和多层反馈闭环,实现可追溯、可验证、可校准的自动化决策与执行。其核心原理在于将LLM能力嵌入可控的工程框架——如感知-决策-执行-校验四层混合架构,结合动作合约、影子流程与法律级审计机制,在不依赖端到端大模型的前提下保障可靠性、合规性与韧性。技术价值体现在降低跨系统信息断点、压缩异常响应周期、支撑中小团队轻量级数字化落地。典型应用于跨境电商订单履约、B2B合同自动化、GDPR数据删除等强规则

aigui1439的博客 331

淘宝滑块验证码破解:Python模拟鼠标轨迹过关详解

本文全面解析了淘宝滑块验证码的破解流程,从机制分析、图像处理、轨迹模拟到自动化实现,提供了完整的Python解决方案。随着2026年风控技术的升级,单纯依靠轨迹模拟已经难以达到高通过率,未来趋势是结合强化学习生成更自然的轨迹,并利用深度神经网络进行端到端的验证码绕过。此外,各大平台正逐步推广"无感验证"和"行为式验证码",将验证融入到用户正常操作中,这对爬虫技术提出了更高的挑战。技术本身是中立的,关键在于使用者的目的。希望本文能帮助开发者更好地理解验证码对抗技术,从而设计出更安全的防御系统。

2201_76125261的博客 97

华为OD机试真题 新系统2026-04-01 C++ 实现【计算数列位置N的值】

如果其前面的M个元素中,存在值相同的元素,则该位置上的数值等于前面M个数中最大的数值与最小的数值之如果其前面的M个元素中,不存在值相同的元素,则该位置上的数值等于前面M个数中最大的数值与最小的数值之差;1、输入M、N两个数,则按照以下规则形成一个数列;两个整数,用逗号分割,分别表示M和N。一个整数,表示数列第N个位置上的数值。2、数列的前M个元素的值为1到M;请计算该数列第N个位置上的数值。N取值范围:1<= N<=50。M取值范围:3<=M<=10。

MISAYAONE的博客 1153

MuleSoft+LLM企业级AI编排:安全可控的智能集成实践

AI编排(AI Orchestration)是将大语言模型深度融入企业核心业务系统的技术范式,其本质是在协议适配、语义理解、安全治理与弹性容错四层之上,实现LLM调用的可验证、可回滚、可审计。它超越简单API串联,依托企业集成平台(如MuleSoft)的连接器治理、事务管理与Schema校验能力,解决LLM直连导致的幻觉传播、数据污染与合规风险。关键技术价值在于为非确定性AI注入确定性工程约束——通过RAG上下文管控、输出Schema强校验、多模型混合路由及五层纵深安全防护,支撑客服升级、合同审核、故障自愈

weixin_33827590的博客 409

YOLOv11 环境配置全流程 | 从零开始搭建训练与推理环境

YOLOv11环境配置与训练全流程指南 本文详细介绍了YOLOv11目标检测模型的环境配置、训练与推理全流程。内容包括: 环境要求:列出GPU、CUDA、Python等组件的版本要求,提供快速检查脚本 Windows配置: CUDA 12.6和cuDNN 8.9.7安装步骤 使用Conda创建隔离环境 PyTorch GPU版本安装方法 IDE环境配置 Linux配置:提供Ubuntu 22.04下的CUDA、cuDNN安装命令和Conda环境搭建 Docker方案:提供一键式容器化部署命令 训练实战: 数

shrgegrb的博客 2019

GPT-5.5不存在,但执行器范式已到来:从回答到稳定执行的工程跃迁

大语言模型正经历从‘回答器’向‘执行器’的关键范式转变——这并非单纯模型升级,而是目标函数、架构设计与系统鲁棒性的全面重构。当传统benchmark(如MMLU)衡量知识覆盖时,Terminal-Bench和OSWorld等新型测试聚焦命令链鲁棒性、环境自适应性与操作系统心智模型,暴露出当前SOTA模型在状态维持、原子操作验证与过程容错上的根本瓶颈。技术价值在于将AI能力锚定于可验证的目标状态达成,而非单次响应质量;应用场景已延伸至金融合规审查、云服务自动化、科研流水线等强约束生产环境。本文基于真实Agen

weixin_34128237的博客 462

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

Linux 进程控制:fork、exit、wait、exec 与手写一个 mini shell

讲清进程控制的四个动作:fork 创建(内核四件事与写时拷贝)、exit/_exit/return 终止与 8 位退出码、wait/waitpid 等待与 status 位图、exec 七接口与唯一系统调用 execve,最后用这些零件拼出一个支持 cd/export/echo 的 mini shell,并解释环境变量两张表与 putenv 浅拷贝坑。附速查表与 14 道自测题。

BIII__的博客 186

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android:LinePhone3.2.7(最新版本),官网地址:http://www.linphone.org/

第一章 Shell 概述

本文介绍了Shell编程的基础知识,包括Shell的起源与发展、常见Shell类型及查看方式,阐述了Shell作为命令解释器连接用户与操作系统内核的作用。强调其作为解释型脚本语言的优势,适用于系统管理自动化任务。内容涵盖Shell脚本基本结构、注释规范、编写风格、执行方法及常用命令(如echo、printf、history、管道等),并讲解了命令执行顺序、退出状态码等核心概念,为初学者提供系统学习路径。

sbjdhjd的博客 296

C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正

DeepAgents框架构建一个带有严格安全护栏的本地 Shell 执行环境。

核心亮点在于:通过精心设计的 System Prompt(系统提示词)强制约束大模型的行为,防止其通过操作系统底层的 Shell 命令绕过框架的虚拟沙箱,从而确保本地物理磁盘的绝对安全。DeepAgents 框架接入 DeepSeek 模型并构建一个带有严格安全护栏的本地 Shell 执行环境。

qq_42092076的博客 71

Linux、Shell、MySQL 测试卷逐题细讲(下篇:MySQL)

本文为Linux、Shell、MySQL测试卷下半段MySQL部分逐题讲解,包含填空、选择与SQL分析三类题型。填空题覆盖COUNT、HAVING、DISTINCT、事务、约束、索引等核心语法;选择题辨析存储过程、索引类型、ACID、存储引擎、用户管理等考点。SQL大题围绕员工、部门、职位、地点四张关联表,考察多表连接、分组聚合、自连接、相关子查询、NULL处理等高频写法,标注LEFT JOIN统计计数、NULL判断、子查询别名等易错坑点,同时梳理试卷OCR识别带来的干扰问题,重点提示SQL实操中的常见失误

dongziwen1的博客 185

CST如何通过Shell Solid or Thicken Sheet对模型进行挖空及加厚

在CST建模中,ShellSolid可对实体模型挖空,形成壁厚为指定值的封闭或开放壳体,通过选择不同面可控制开口位置;ThickenSheet则用于将无厚度二维片体加厚为三维实体。操作时需在导航树中选中模型,调用ShapeTools中的相应功能,设置厚度并预览确认。两者结合可高效实现复杂结构建模,适用于电磁仿真前处理。

a18665053298的博客 134

抖音_libsscronet_证书校验绕过

代理(Reqable)进行中间人后换发的证书,系统信任库是认的,但还要过这层自定义校验:最终落到 Java 的。,纯 Python 标准库,不需要 IDA / Ghidra / capstone。是安装时随机生成的,每台设备、每次重装都不同,换设备或重装后需重新查一次并替换。so 已被映射进运行中的进程,覆盖磁盘不会影响内存里的旧映像,不杀进程等于没改。,抖音所有网络请求的底层,自带 BoringSSL(同目录。关掉开关后,回调根本不执行,下面的 JNI、,Python 3.6+,仅用标准库。

qq_44990881的博客 182
上一篇: 在J2ME手机编程中使用字体和颜色
下一篇: Windows Mobile 5.0最新体验
ciyi7513
博客等级 码龄11年 2粉丝 0原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值