困难问题

有用的框架不是从理论出发往下推,而是从一个真实的、足够难的问题出发往上建。

我们在解决什么问题

让无人系统在特定场景中,协同人,安全可靠地完成特定任务。

这句话看起来简单,实则包含四个同时成立的约束——而正是四个约束同时存在,使它成为一个非平凡的工程问题:

约束为什么难
无人系统需要自主规划与执行,不能依赖人工实时操控
特定场景场景有物理约束(高压、高空、复杂地形),通用方案无法直接套用
协同人人下达语义指令,系统转化为物理动作——语义鸿沟和安全责任如何划分?
安全可靠硬实时约束 + 零碰撞要求,不能靠经验估计,需要形式化保证

这四个约束不能单独解决,必须同时满足。任何只解决其中两三个的方案,在实际部署时都会在剩余约束上失效。

困难问题总览:四个约束的交集与现有方法局限

现有方法的局限

方法能解决解决不了
传统规划(PDDL/HTN)任务分解、条件分支实时安全约束、物理执行
端到端学习(VLA/LLM)语义理解、自然语言交互可验证安全性、硬实时控制
经典控制(MPC/CBF)实时安全、动力学约束任务级规划、语义理解
人工遥操作灵活处理异常规模化、重复性、疲劳风险

没有任何一个成熟方法能同时满足全部约束。 以下给出结构化的论证。

为什么四个约束不能被单一范式同时满足

论证框架:四个约束两两之间存在不可消除的张力(architectural tension),任何单一计算范式必然在至少一对张力上退化。

张力 1:自主规划 vs 实时安全

自主规划需要在语义空间中搜索(HTN 分解、PDDL 规划等),计算复杂度通常是 PSPACE 完全问题,无法在硬实时控制周期(~1ms)内完成。反之,实时安全控制(CBF、MPC)只能在当前状态的邻域内操作,没有任务级”全局视野”。两者工作在不同时间尺度,强制耦合必然导致其中一方降级:规划变浅(失去自主性)或控制变慢(失去实时性)。

张力 2:语义理解 vs 形式化可验证

LLM/VLA 获得语义理解能力的代价是成为黑箱——其内部推理过程不可形式化规约,输出不满足 Lyapunov 稳定性或 STL 可满足性的闭式证明。形式化方法(STL、CBF)要求系统模型是已知的微分方程或有限状态自动机,这与神经网络的泛化机制根本不相容。试图让同一系统既做语义推理又提供形式化安全保证,在当前技术条件下是开放问题,没有已知的一般解。

张力 3:场景定制 vs 规模化通用

特定场景(高压输电线路、受限空间检修)的物理约束(带电体安全距离、关节力矩极限、风载扰动)需要专门的约束模型,不能被通用训练数据覆盖。通用端到端方法(大规模预训练 VLA)的泛化性正是来自忽略场景特化约束——它在特定场景上的失效率随约束严格程度单调增加。精度与泛化之间的权衡(precision-recall tradeoff)在安全关键场景中不可接受:漏检一次碰撞风险就是事故。

结论

上述三对张力表明,不存在单一计算范式能同时覆盖”语义理解 + 实时安全 + 场景定制”三角。这不是工程资源不足的问题,而是三种能力需要根本不同的计算结构(符号搜索、连续优化、约束传播)。EICPS 的回答是:接受这一分解,为每对约束选择正确的工具,用接口设计解决工具间的协同问题。

与 AI Harness Engineering 的本质区别

2026 年兴起的 AI Harness Engineering(Agent = Model + Harness)与 EICPS 的名称和出发点相近——都是为 AI 提供工程包装——但本质路径不同:

维度AI Harness EngineeringEICPS
视角软件工程物理数学
安全来源规则库 + 人工审核STL + CBF 形式化约束
约束层次外部行为管理内嵌动力学约束
验证方式日志审计机械可验证的证据链
对 AI 的态度不质疑模型内部,只管外部行为AI 是工具,可靠性由 CPS 侧保障

AI Harness Engineering 是从软件工程视角”管住” AI 的行为;EICPS 是从物理数学视角在执行层内嵌安全保证,不依赖 AI 的正确性。前者解决的是”AI 行为不可预测”的工程问题,后者解决的是”具身系统物理安全无法形式化验证”的科学问题。

目标场景

问题要具体才能验证。EICPS 以架空输电线路运检作为第一个目标场景——它是上述四个约束同时存在的典型实例:

架空输电线路运检·Prj167


EICPS 的应对思路是:以 CPS 架构为内核,将 AI(VLA/LLM)作为语义推理工具嵌入 Brain 层,可靠性和安全性由控制侧的形式化机制(STL、CBF)在工程层面强制保障——不依赖 AI 的正确性。

集成框架:我们选择了哪些工具