——读《驾路协同，让道路成为能动主体》的一些思考
作者 洪涛 江苏天安智联科技股份有限公司
编者按：本文作者洪涛，供职于江苏天安智联科技股份有限公司，国家级首个车联网（无锡）先导区研发团队主要成员、车路云一体化资深研究者。本文系作者阅读《驾路协同，让道路成为能动主体》评价，经作者同意全文刊发，文末引用与资料出处一并照录。文中观点、判断及所引材料均出自作者本人，为便于阅读，Innovation Era Press仅作文字性校订。本文英文翻译将在英文版专著正式出版后另行发表。
读《驾路协同，让道路成为能动主体》，我认同书中的大部分主张，尤其是作者反复追问的一件事：道路交通投入了这么多技术，最终有没有让用路的人更安全、更从容？这个问题，值得每一个做车联网、交通工程和自动驾驶的人认真回答。
书里有些批评很尖锐。对建设规模的追逐，对大平台的迷信，对道路自身缺陷的忽视，确实应该受到质疑。但我不赞成由此把车路协同整体归入“技术幻觉”。书中批评的，是一种把车辆安全过度寄托于路侧和通信的做法；而它主张的道路主动感知、规则信息发布、边缘处理和可追溯运维，也正是车路协同应该做实的工作。把这层关系说清楚，比争论“车”和“驾”哪个字更准确更有意义。
道路应该为使用者多做一些事
作者把视线放回了标志、标线、照明、隔离和视距。这是本书最有价值的地方之一。技术方案往往从感知设备和平台架构讲起，道路使用者面对的却是一块被遮挡的指路牌、一处来不及判断的分岔口，或者一段看不清边界的雨夜道路。基础设施如果连清楚、连续、及时地表达通行信息都做不到，再先进的算法也要替它善后。
我赞同书中“物理技术先行，数字技术叠加”的原则。标志标线首先要看得清，渠化首先要合理；有了数字能力，还要把前方发生的变化尽早告诉人和车。道路建设不能以将来车辆足够聪明为理由，“搁置”今天就应当解决的安全缺陷。[1]
这也决定了公共道路的受益对象。没有安装车载终端的普通车辆、骑行者和行人，都应该从道路改造中获益。无灯控路口发现行人后，既向车辆发送让行、预警信息，也通过现场设施提示来车，就是书中很值得肯定的思路。数字服务可以逐步增加，基本安全服务应当从项目投入使用的第一天就成立。
不过，保障没有终端的人，并不意味着网联技术无法保护他们。路侧感知发现了被遮挡的行人，把信息交给驶近的车辆，同样可能让没有携带任何设备的行人受益。现场警示和车端信息服务可以共同承担这件事。评价方案时，应看风险是否被及时发现、信息是否真正到达需要它的人，以及接收方来不来得及采取行动。
对车路协同的批评需要分清对象
书中第四章对通信失效的担忧有充分理由。如果车辆把关键感知或决策完全放在远端，链路一断便无法应对眼前的道路，这样的架构必须受到严格审查。但车路协同包含的应用很广，风险预警、规则信息补充、驾驶辅助和协同控制，对外部信息的依赖程度并不相同。工信部对应用试点的解读，也区分了协同预警、协同驾驶辅助、协同自动驾驶等不同等级的功能。[2]
我理解的车路协同，是由路侧提供增量信息，车辆保有与其运行条件相适应的安全能力。车辆可以提前收到遮挡区的风险，也可以直接获取交通管理系统发布的规则信息，但必须判断信息是否有效、是否适用于本车。外部数据一旦过期、矛盾或中断，系统应当知道这意味着什么，并执行经过验证的应对策略。[3]
事实上，作者在第十章已经作了接近这一立场的讨论：路侧应把单车看不到的信息提前告诉车，不能承担替车驾驶的角色；到了第十二章，他的系统架构也包含车载单元，并允许车辆在信任与安全验证机制下自主决策。这说明两种主张在工程分工上有相当大的共同基础。既然如此，用一种过度依赖通信的架构来代表全部车路协同，就把原本可以讨论清楚的问题扩大成了路线对立。
书中还有一个技术细节需要校正。第四章把通信可靠性 99.999% 换算为全年允许中断约五分钟。但其引用的 3GPP TS 22.186 中，可靠性指的是规定时延内传送一定字节数的成功概率，不能直接当作全年服务可用率。两者的统计对象不同。[4] 无线链路确实会失效，不过判断一项应用能否成立，仍要逐项分析消息时效、连续丢失、失效检测和车辆处置，不能由一个换算替整条技术路线下结论。
道路说的话必须对得上现场
与本书相互印证最深的，是我们对数字信号的认识。道路有主动性，首先应能把自己掌握的信息讲清楚：当前是什么灯色，这条车道允许往哪里走，某项临时管制什么时候生效、什么时候结束。车辆可以观察外部世界，但对于管理方已经作出的通行安排，有来源可核验的信息值得直接提供给它。
但这并不意味着一条信号来自交管系统，就天然正确。信号生成、编码、传输、地图关联和车端使用，任何一个环节都可能出错。无锡车路云一体化实车路试中就多次发现高架上的车收到桥下红绿灯、隧道内收到隧道外信号等问题。对这些问题，再低的传输时延也无济于事，还有赖于后续行业标准的建立；数据首先得属于这辆车所在的道路和行驶方向。[5]
灯色也一样。平台发出了绿灯消息，现场灯具是否真的显示绿灯？可变车道箭头已经切换，地图和车端是否仍保留旧的通行方向？一条信息在发送时正确，到车辆使用时是否已经过期？这些问题比大屏上多亮几个路口更能检验系统能力。身份认证解决来源问题，加密保护传输，二者都不能代替对内容和现场一致性的核查。通信的物理时延始终存在，不同传输链路的业务数据时延也存在显著差异；正是出于这一考虑，这套信息后来不再称作“交通指挥数字信号”，而改称“交通数字信号”——它提供的是可供车辆核验与使用的信息，而不是直接下达的指挥指令。
因此，我赞同作者强调设施身份、状态记录和责任追溯，但认为还应往前走一步。设备在线只能说明它仍有联系，服务可用还要说明它传出的内容值得使用。一个路口的档案，应把物理设施、信控配置、数字地图、发布信息和实际测试结果对应起来。出了异常，能沿着记录找到问题发生在哪个环节，修复后还能重新验证。[1][6]
2026 年 7 月的《车路云一体化当前问题与数字信号上车聚焦建议》把这件事讲得很务实：先明确哪些路口、哪条链路、哪些车型和工况达到了测试条件，形成达标路口白名单，再谈推广。这种克制是必要的。一个路口连续可用的服务，比覆盖一大片区域却说不清质量的数据，更容易获得使用者车企的信任。[7]
安全退化需要验证整个过程
“断电断网时，你是什么？”这是本书最应该进入项目评审的问题。把失效时的行为想清楚，应该发生在设计阶段，而不是交付后出了故障再补说明。
但对于书中提出的断网后使用本地策略、断电后退回静态设施，我认为这一安排还需要补上一个条件：退回去的状态必须适合当时的现场。对于固定内容的标志，保留逆反射能力很重要；对于改变了车道功能的动态设施，问题就复杂得多。[1]
设想一条车道刚从直行改为左转，已有车辆按新规则驶入，这时部分设备断电。若路面标线、车道标志和信号灯没有同步退化，驾驶人可能同时看到相互矛盾的指示。即使所有设备最终都恢复了原来的静态状态，切换过程中已经进入车道的车辆仍然需要得到妥善处置。这是对方案的工程推演，不是对某个项目事故的认定。
所以，验收时需要看清从正常状态到失效状态的全过程，包括变化是否被识别、旧信息何时失效、现场如何保持一致，以及何时允许恢复运行。涉及车道切换的，还应验证清空和过渡安排。把这些过程写进测试用例，比笼统承诺“可降级”更有用。
这条要求同样适用于车端。收到路侧信息时，应怎样使用；收不到时，原来的运行条件是否还成立；两类信息相互矛盾时，如何避免贸然行动，都要有明确设计。不能把所有系统的故障处置统一写成“驾驶员接管”，更不能把一次界面提示当作接管已经完成。
会改变状态的道路更需要约束
本书关于交通组织的讨论值得重视。把指路诱导、车道功能和信号配时放到一起考虑，确实比孤立地优化一个路口更接近真实交通问题。无锡数字信号与可变车道的相关工作，也是在处理空间分配与时间分配如何一致的问题。[5]
不过，道路有能力改变规则，并不意味着应该频繁改变。驾驶人需要提前理解并作出选择，行人需要足够的过街时间，支路也有自己的安全和承载条件。主路拥堵、旁边支路空闲，不能单凭这个现象就认定支路应当接走更多车辆。多放行了机动车，如果增加了行人暴露风险，或者把拥堵推到了下一个路口，改善就没有那么确定。
因此，对三级信号诱导、动态标线这类方案，我赞成试验，也希望看到更具体的证据：在什么交通条件下有效，改善来自哪项措施，对其他方向和其他出行者产生了什么影响。作者自己也承认，示范实验的工程可行性，不能单独决定全城拥堵能缓解到什么程度。这一限定应当保留。[1]
如果进一步引入 AI，合理的起点是帮助发现异常、整理路口资料、对比配时方案、分析施工或天气影响。这与我们提出的面向数据治理和交管运维的小工具链思路相通。至于直接改变放行关系、生成车道控制指令，必须受明确规则约束，并经过验证。AI 能加快分析，但分析建议成为现场动作之前，仍然需要确定的授权和控制程序。[7]
建成之后谁把道路管好
书中第十三章问电费谁付、故障谁修、设施寿命到了谁换，我很认同。这些看似不如算法和架构新颖的问题，决定了道路的数字能力能够持续多久。缺少维护的在线设备，可能继续发送已经不适用的信息；这样的失效有时比彻底断线更难发现。
这也是我们强调常态化测评的原因。有一个问题许多做车联网的同行还没有意识到：验收只能证明某个阶段的状态，之后信控方案会变，施工会改变车道，地图需要更新，设备也会老化。让运行中的车辆参与发现异常，再由专业测试核实，形成整改和复测记录，才有可能把交付时的质量维持下去。我们必须建立起一套能够自我发现问题、并完成整改与复核的一体化运维体系；我们设计的常态化测评体系覆盖规划、建设和一体化运维，正是在回应这类持续变化。[6]
设施留痕还应当帮助责任各方查清问题。哪一版配置生效，谁发布了信息，现场执行是否成功，车端收到的又是哪一条，需要在同一时间基准下还原。记录的完整性和独立核验条件也很重要。只保存平台“发送成功”的日志，不能说明现场已正确显示，更不能说明用路者已正确接收。
我理解“让道路成为能动主体”的意义，是促使设施背后的设计、建设、发布和管养职责具体化。技术记录可以帮助查明事实，但不能仅凭设备有了数字身份，就认为责任分配已经完成。承担职责的机构、服务边界和核查办法，仍须在工程与运营安排中逐一说清楚。
经济账也要分清。公共道路改善首先看安全、通行和服务价值，不能要求所有路侧投入都靠向车企卖数据回本。这与我们“先证明价值”的判断一致。智能交通与车路云一体化作为“数公基”（新型数字化公用基础设施）的公共属性，现已为多数人认同，但公共属性也不能成为不算账的理由。建设之外的巡检、通信、更新和更换费用，应当一开始就进入预算；能够收费的数据服务，则需要另行证明需求和支付意愿。[8]
我更愿意沿着一个具体问题往前做：先选一批确有需要的路口或路段，把物理设施和数字信息核对好，持续测试，让故障有人处理、处理之后有人复核。在这个过程中，查清哪些投入改善了安全，哪些只是增加了设备，再决定下一步扩到哪里。既不把收益推到遥远的终局，也不把短期没有事故当作效果已经得到证明。
读完这本书，我仍然赞同车路云一体化，也更认同应该用道路使用者的实际处境来检验它。作者提出的许多批评，值得进入我们的设计审查和验收现场。尤其是当我们说一条路“有能力”时，应该拿得出证据：它知道什么，告诉了谁，信息错了如何发现，失效以后怎样保障通行。这些问题有了可靠的回答，道路的主动性才算落到了实处。
引用与资料出处
[1] 刘干：《驾路协同——让道路成为能动主体》，创新时代出版社，2026 年 9 月 16 日版。依据所提供 PDF：第四章第 61—69 页，第十章第 155—170 页，第十一章第 171—184 页，第十二章第 185—202 页，第十三章第 203—221 页。以上均为 PDF 文件页序，非目录或书内印刷页码。
[2] 工业和信息化部：《关于开展智能网联汽车“车路云一体化”应用试点的通知》解读，2024 年。参见关于功能场景分级和“单车智能和网联赋能协同发展”的说明。（工信部原文）
[3] Obsidian 知识库：09-公司战略／赛文交通网专访-天安智联核心观点.md，2026 年 4 月 11 日整理，来源为专访草案修订稿；03-数字信号体系／数字信号体系与模拟质疑应答.md，“安全容错与降级机制”等节。
[4] 3GPP TS 22.186 V15.4.0（ETSI TS 122 186，2018-10），第 3.1 节“Reliability”定义，标准印刷第 5 页。用于核对被评著作第四章第 56—57 页的可靠性换算，不作为对现网性能的测量结论。（ETSI 标准原文）
[5] Obsidian 知识库：07-无锡实践／二阶段项目主线-国标数字信号高质量数据服务.md，2026 年 4 月 11 日整理，来源为二阶段规划脑图；重点参见“数字信号数据质量问题诊断与解决路径”。文中将其作为问题与规划记录使用。
[6] Obsidian 知识库：02-数据质量测评／C-V2X 数据质量常态化测评平台.md，2026 年 4 月 11 日整理；07-无锡实践／验收-C-V2X 数据质量评测分析.md，“众源路测采集装备”“路测告警引擎”等节。
[7] Obsidian 知识库：07-无锡实践／车路云一体化当前问题与数字信号上车聚焦建议.md，2026 年 7 月 8 日整理，来源为同名修订版 Word 文档；重点参见第三、四、七部分。
[8] Obsidian 知识库：09-公司战略／天安智联核心战略思考.md，2026 年 4 月 11 日整理，来源为《我的几点想法》内部战略文档；重点参见公共基础设施定位、后装验证和数字信号切入相关论述。
《驾路协同》作者附记
感谢洪涛先生指出本书第四章关于 3GPP TS 22.186 可靠性指标的换算问题。该标准中的 reliability 指在规定时延内成功传送规定字节数的概率，与全年服务可用率并非同一统计对象，此处换算确有不当，将在后续版本中订正。
——刘干
