大学是人类知识的圣殿。但有一些领域，工业界反而领先于学术界，诸如软件工程，项目管理等需要大量实践的领域，特别是需要“动脑”更需要“动手”的领域，工业界往往比学术界更有优势。

　　那么 “排程与调度” 这个领域呢？实际上，学术界并没有一个专门的学科与之对应。这是一个多学科交叉的领域，应用数学、统计、计算机算法、企业管理和工业管理等众多学科都会研究的领域。

　　很多知识领域，从运筹学、最优化、控制理论、模糊混沌、规划、专家系统、数据挖掘甚至最时兴的人工智能和大数据，都在研究 “排程和调度” 相关问题。

　　尽管，众多学术论文的模式都是：用一半甚至更多篇幅，描绘一个宏大而有意义的问题场景，大谈意义作用，然后写几个公式或算法的伪代码以示高大上，然后就神奇般的得到了一些结论……

　　当然，这些论文一般都出自管理类学科（苦笑），数学和算法背景的论文多数还是相对严谨。但问题是，尽管逻辑推导是严谨的，但这些学术和技术在现实中的作用仍然有限。为什么？

　　人类从愚昧发展到科学和文明，重要的是逻辑思维及建构在此基础上的一项关键能力：抽象和建模。笔者认为，在公开资料中，对这种能力最精彩的解释是 MIT 的公共课《电路和电子学》（第一课），从原子分子尺度，到模拟数字信号，最终到程序里的变量……可以说，没有抽象与建模就没有人类从农业、工业到信息时代的跨越。

　　抽象和建模也是目前 “排程和调度” 相关学术成果很难在实践中产生广泛、深入、有效作用的原因。比如，多数基于数学的方法对现实问题的抽象和建模都过于简化。这是“后续推理全对但实际结论没什么大作用”的原因。基于一个错误（过分简单片面）的假设是不可能得出正确的结论的。当然，过分简化本不是学者们的错，因为工具和时代有其局限性。但拿这些有本质缺陷的工具包装成产品卖就是另外的问题了。

　　多说一句，过分简化不好，但另一个极端 —— 过分复杂 —— 也是不对的。所谓 “抽象”，还是要有概括取舍。保留有效因素，去掉无关因素。现实中的工商业场景是极其复杂的，如果不做抽象，目前没有计算机能进行运算。所以，看似简单的 “抽象” 二字，实则非常考验研究人员或工程师的专业水平和敬业态度。

　　其实人类很早就认识到了像数学等一些高大上模型的局限性，加之确实有很多棘手问题要解决，因而出现很多朴素但有效的模型，比如决策树、规则引擎和专家系统。这些技术虽然古老（上世纪80年代），听上去也不高大上，但反而在军事，这个实际上比工业更严苛的领域取得了显著作用。

　　而且关键是，这些技术客户在经过学习后也能懂，不违反直觉。这一点的好处真是再怎么强调也不过分。比如，不像所谓 AI 技术是一个黑箱，规则可以被理解，于是人可以参与决策过程。现实中，没有一个企业可以完全不加入人工决策而全部靠系统指挥生产活动。一方面最灵活的还是人而不是系统。另一方面，只有人 “懂事”，可以做出看似非最优，但实际上是系统是不会考虑采购经理是老板的小舅子这种事的。简单也是一种美。再复杂也复杂不过人性。

　　说到这里，必须解释下，仙工智能不是排斥高大上的技术，我们只是比较务实地看待各种技术的实际价值。我们对 “智能” 的理解是比较谦卑的：公司内部始终强调，首先要做到的是 “不比人笨”，而这已经是 “高” 智能了。我们非常慎重的对待 “超越人” 这件事 —— 这当然是终极目标 —— 但绝不是现状。

　　作为仙工智能企业数字化中台的子产品 —— SEED RDS —— 机器人及自动化设备统一资源调度系统 —— 是一个比较务实的系统。它不是一个凭空出现，而是对公司目前调度类、设备控制类及流程优化类产品和功能的总结提升。在经过足够数量和足够多类型的项目历练后，我们在架构上做出了重大调整，为的就是让其更灵活和通用。

　　实话讲，目前我们并没有 “一招鲜吃遍天” 的技术，没有一个高大上的统一技术或模型可以适配所有行业。即，我们仍然没有足够的能力做出强大的“抽象”和“建模”统一全部工商业场景。实际上，站在真正为客户负责的角度，客户需要的是解决问题，也不是系统本身多高大上多精美。所谓 “大小型企业数字化路径不同”，我们为客户提供的，是一个统一但灵活的架构，在此基础上可以方便扩展从简单到复杂的算法和策略，解决从单车单任务、多车多任务到多设备多产线的全局最优；特别的，当遇到技术瓶颈时，可以通过 ad-hoc 策略 “贴身肉搏” 地解决问题。

关键要把问题解决！
关键要把问题解决！
关键要把问题解决！

　　系统内部已经内置一些经典的、经过多年项目验证的策略，开箱即用。此外，对于写代码比配置更快更好的策略， RDS 还可提供 C++、C#、Java、Python、Rust、Node.js 等主流语言的 SDK；用户可以利用  SEED 的强大的基础设施进行二次策略开发。