今年华为全联接大会2026我最大的一个感受是智能体这个词已经彻底从“能聊天的机器人”变成了“能干活的生产工具”。尤其是交通领域几乎每个相关展区都能看到类似的东西一块大屏一个数字孪生的路口一行行自动弹出的处置指令。以前我们说“城市大脑”更多是人看大屏做决策这次我看到的是智能体自己在读数据、自己下判断、自己去动信号灯。这句话说起来轻巧真要落到交通场景背后牵扯的问题极多。这篇文章就按我在展会现场看到的内容把交通智能体从“演示Demo”到“能上线干活”整个过程拆开讲包括它怎么感知、怎么推理、怎么行动、怎么兜底以及我实际观察到的平台选型信号希望能给正在做智能体落地或者准备入行的朋友一些参考。1. 展区现场智能体已从“聊天机器人”变成跑在路侧设备上的“数字交警”1.1 一块大屏一辆虚拟救护车和一串自动生成的调度指令我在华为全联接大会2026的交通展区看到最多的就是“事件处置”类演示。工作人员在数字孪生场景里模拟了一辆救护车从城市东侧驶向中心医院途经五个信号控制路口。传统方案里这个叫“绿波带”信号机按固定方案一路放行这次展示的则是一个事件驱动的智能体链路——当救护车GPS定位上报“特种任务”请求智能体立刻拉取它的实时位置、前方路口排队长度、上下游车道占用情况然后在不到两秒内生成一套新的信号配时方案目标路口的绿灯延长、冲突相位提前截断、相邻路口错峰联动。关键不在“快”而在于这个动作是谁做的。演示屏的右侧有一个日志面板把智能体的每一次决定都写成了“为什么”“下游排队平均38米建议早断相1.2秒”“对向非机动车请求量级低于阈值允许压缩”。这种带原因链的记录是传统交通控制平台根本没有的东西。我后来在和现场工程师交流时他反复强调一句话交通管理者不怕Agent做错怕的是Agent做了错事之后说不清楚自己为什么这么干。1.2 信号灯、诱导屏、地图导航执行层为什么拼命在“软联动”看完演示我和在场的工程师聊了一会儿。他说交通智能体最难的部分不在决策模型而在执行层的对接“你要动的不是一个软件按钮是信号机的相位配时、诱导屏的发布内容、地图App的绕行提示。”他给我看了一个接入关系图执行层至少包含四类设备路口信号机、可变情报板、广播或者短信平台、互联网地图导航。智能体要在这些设备之间下不同粒度的指令给信号机下发的是秒级相位指令给地图推送的是分钟级绕行建议给广播平台发的是事件描述文本。这句话我当时没太在意后来细想才发现问题今天的交通系统不是一个统一接口的世界厂商协议、控制权限、审批流程都不一致。为了让智能体真正“动得了手”演示方案里做了一层执行网关由人提前授权“哪些动作Agent可以自己执行在哪些时段执行”超出授权范围的动作必须返回人工确认。这个设计我认为是交通智能体和通用Agent最大的区别。通用Agent的工具调用失败了大不了重来交通智能体一旦动作发下去影响到的是真实道路上的车和人。1.3 我观察到的三层结构感知、决策、执行都不再是人类写的脚本在现场看的几个方案底层逻辑都惊人地一致。交通智能体并不是某一个“超级大模型”在做所有事而是分了三层感知层负责接入路口摄像头、雷达、地磁检测器的数据把非结构化信息变成结构化事件决策层由大模型加领域知识库、交通仿真模型组成负责生成判断和方案执行层对接信号机、诱导屏、信息发布平台。这三层的边界很清楚智能体的价值在于把三层高效地连成一个闭环。我还在现场看到一个让我印象深刻的细节工作人员让智能体解释为什么某个路口在早高峰需要切断左转相位。智能体的回答不是一句“因为早高峰流量大”而是列出一组数据——“左转车流排队超过150米直行车道平均空置率达23%行人过街需求指数低于设定阈值”。这种把结论建立在可追溯指标上的回答是交通管理者愿意给它放权的前提。反过来看如果智能体只是给一个模糊结论哪怕最终决策是对的也没人会放心让它去触动信号灯。2. 从“发现异常”到“改一个路口的绿灯时长”交通智能体的完整工作链路2.1 第一步感知与会话——实时视频流如何被转成“可以被推理的事件”在华为全联接大会2026的多个展台我注意到所有交通智能体都会强调一个共性先把非结构化数据变成结构化事件。视频流进来先做目标检测——机动车、非机动车、行人、抛洒物、事故车辆再跟踪一段时间判断这些目标是否构成“事件”。比如一辆车停在主路中央超过三十秒检测模型会把它标记为“异常停车”打上时间戳、坐标、车道编号生成一个结构化的JSON事件对象。我专门问了一个问题为什么不直接把视频流喂给大模型展台工程师笑了笑说第一是成本第二是延迟第三是“大模型不知道什么是红绿灯相位”。在交通场景实时性要求高视频流动辄几百路直接喂给大模型既不现实也不安全。所以典型的做法是先用小模型做目标检测把结果浓缩成事件文本再交给智能体做更高层的分析。这也解释了为什么交通智能体的效果高度依赖底层感知模型的质量——感知漏检一次后面的推理再聪明也没用这就像一个决策者拿到错误的战报再优秀的指挥能力也无济于事。2.2 第二步检索与推理——RAG在交通场景里检索的是什么RAG检索增强生成这个技术在很多场景里是用来查文档的但在交通智能体里它检索的东西要宽得多。现场看到的一个方案里Agent在收到“某路口拥堵加剧”的事件后会先把自己要检索的内容分成三类第一类是实时数据包括当前路口的流量、排队长度、信号配时方案第二类是历史规律比如该路口过去四周的拥堵时间分布、相似天气或者日期的处置案例第三类是规则文档包括交通组织方案、信号配时规范、重点保障任务清单。这个设计非常务实。纯粹的LLM只知道“一般来说堵了要延长绿灯”但RAG让它知道“这个具体路口在周五晚高峰左转绿灯已经放行很久旁边学校正在放学前方高架入口车流排队溢出”——这些才是真正影响决策的上下文。我在现场看到一个查询面板智能体把每一次检索的关键词和命中的文档都完整记录下来。这个细节后来我越想越重要它让智能体的决策不再是黑盒你可以看到它依据了什么数据、忽略了什么数据甚至可以据此去优化它的检索策略。2.3 第三步行动与回退——“允许动红绿灯”这个动作凭什么被放行交通智能体和普通问答型智能体最大的区别在于它有“行动权”。但行动权的授予绝不是一揽子授权。我看到的那套方案把智能体可执行的动作按风险分成了三级低风险动作包括生成拥堵预警文本、更新事件看板中风险动作包括调整可变车道方向、发布诱导屏文字高风险动作包括修改信号灯相位配时。低风险动作Agent可以全自动执行中风险动作需要在阈值内自动、阈值外人工高风险动作原则上只有模拟环境验证通过之后才进入人工审批队列。我后来想明白了这套分级背后的逻辑在交通系统里一个“错误动作”的代价不是几秒钟而是可能引发连锁事故。所以“决策对不对”反而没有“决策是否有授权”重要。即便大模型判断非常准确只要动作不在授权范围内系统就应该停下来等人工。这种“宁可慢不可乱”的思路是交通智能体最值得其他行业借鉴的地方。很多智能体落地失败不是模型不行是授权模型设计得太随意该给人审的没给人审最后出了事整个项目被叫停。2.4 第四步反馈闭环——改完配时之后智能体如何确认自己“做对了”大多数Demo到“执行完动作”就结束了但真正在现场的技术人员更关心的是反馈闭环。我看到的方案里执行完信号方案切换之后智能体会继续跟踪后续的指标排队长度有没有下降、平均车速有没有回升、事件本身有没有解除。如果跟踪了一段时间发现指标没有改善它会触发回退逻辑把信号方案恢复到调整前的配置并生成一条“行动无效且已回退”的记录。这个反馈回退设计是我认为整个链路里最有含金量的一环。因为交通系统是非线性系统一个路口的变化会传导到上下游你很难保证某个调整一定有效。智能体是否具备“承认自己判断错误并及时止损”的机制决定了它是生产工具还是摆设。展会现场有一个演示让我记忆很深智能体调整了一个路口的绿信比之后发现下游排队反而增加马上自动切回原方案并在审计日志里标注“该方案曾在过去7天触发2次同类回退”。这种自我纠错能力比“从不犯错”更重要也更真实。3. 单兵作战远远不够区域信号、公交调度、物流路径三个智能体怎么谈“分工”3.1 一个城市不可能只有一个Agent多智能体出现的必然性在华为全联接大会2026的论坛环节不止一位嘉宾提到“智能体不是单体而是一群”。这句话放在交通领域尤其对因为交通问题的边界天然是分裂的信号控制归交通管理公交调度归公交公司物流路线归货运平台。如果只做一个“总智能体”去接管所有事情数据不通、权限不清、责任不明根本没法落地。展会里正好有一个多智能体协同的沙盘演示布置得很直白一个“区域交通指挥Agent”在中心位置左边是“公交优先Agent”右边是“应急调度Agent”下方还有一个“物流避开Agent”。四个智能体共享同一套数字路网状态但各自有自己的目标函数。当它们的诉求冲突时会通过一个优先级协商机制来排序。这个机制本质上解决的是“争抢”问题一个红绿灯资源有限谁先用、谁让一让不能靠拍脑袋要靠规则。3.2 我看到的协作范式请求、协商、让渡、回滚我站在那个沙盘前看了很久旁边有一位从外地来的集成商也在看。他给我讲了一个很实在的协作场景公交优先Agent想让信号系统延长某个路口的绿灯让晚点的公交车先过但应急调度Agent同时上报了一个救护车任务要经过同一个路口。按照我看到的协作机制应急任务会直接拿到最高优先级公交优先Agent收到“请求被拒绝”的反馈后会重新规划自己的策略比如建议公交车走相邻道路或调整发车间隔。这位集成商说多智能体协同的难点从来不是“大家一起做”而是“一个让位之后让位方自己的任务怎么办”。好的协作机制必须在让渡的同时给出替代方案或回滚路径否则整个系统会越调越乱。这句话让我对“协同”这个词有了新的理解协同不是大家抢一个绿灯而是各自算清楚代价之后达成一个临时秩序。如果只强调“全局最优”忽略每个智能体的局部指标压力这种系统在真实运营中很难推下去因为每个部门都有自己的KPI。3.3 数字路网共享算力与共享“上下文”是两码事多个智能体要协同前提是它们能读到一致的状态。现场演示里反复出现一个词叫“数字路网”它不是一张静态地图而是一个实时更新的语义网络路口是节点路段是边事件、车流、调度任务都以结构化的方式挂在网络上。区域信号Agent读的是路网里跟信号相关的字段公交Agent读的是跟车辆位置、准点率相关的字段物流Agent读的是跟道路通行能力和时效相关的字段。我特别注意了一个细节这些智能体并不是都访问同一个数据库而是通过一个共享的上下文总线来订阅自己关心的变化。这样做的好处是解耦某个智能体出了问题不会拖垮整个路网坏处是不同智能体对“同一事件”的理解可能存在时间差一个已经看到事故解除另一个还在按事故状态绕行。现场一位架构师提到他们用“事件版本号”解决这个问题每条事件记录更新一次就递增一个版本智能体必须按版本读取避免读到脏数据。这个方案虽不复杂但很管用本质上就是给数据加上了时间戳语义。4. 交通智能体上线前最不该省的钱行为审计、权限边界和对抗测试4.1 为什么交通Agent不能用“通用Agent”的安全标准我在华为全联接大会2026待了三天有一个词被反复提到安全。如果智能体只是聊聊天、写写代码出错了大不了重来但在交通场景它一旦下发指令影响的是真实的道路、车辆和行人。因此交通智能体的安全标准应该向工业控制系统的标准看齐而不是向通用AI助手的标准看齐。现场一个论坛上有人用“三位一体”来概括交通智能体上线前的必做项行为审计、权限边界、对抗测试。我听完之后觉得这其实就是把软件工程里的可观测性、最小权限原则和安全测试翻译成智能体时代的新语言。很多团队做Demo时觉得效果惊艳一上线就翻车大概率是因为把这三件事省掉了。Demo可以靠“结果好看”打动领导生产系统必须靠“过程受控”经得起推敲。4.2 行为审计到底审什么不只是日志是“决策原因链”行为审计是这次展会上出现频率很高的一个词。很多人以为审计就是“有日志”但交通智能体要求的审计远不止记录“某时刻执行了某动作”而是要把“决策原因链”完整记录下来触发事件是什么、检索了哪些文档、调用哪个模型的推理过程是什么、为什么选择了这个动作、动作执行后的指标变化是什么。我在一个展台看到了完整的审计回溯演示事故告警发生后审计人员输入一次告警编号系统把智能体当时的感知事件、检索记录、推理摘要、动作参数、执行反馈用时间线全部串起来。这个回溯能力和普通日志的差别在于它回答的不只是“发生了什么”还包括“为什么这么认为”。对于交通系统的责任追溯来说这是必须的。一旦出了事故能说清楚“Agent当时依据什么做决策”和只能说“是大模型的意思”完全是两回事。前者是可以改进的系统缺陷后者是让人无法信任的黑洞。4.3 被反复念叨的OWASP ASI Top 10翻译成交通场景是什么展会里有场分享专门讲了2026年智能体应用OWASP Top 10也就是面向AI Agent的十大安全风险清单。分享人为了让大家听懂特意把每条都翻译成了交通场景。我印象最深的有三条ASI01提示注入对应的是“路侧设备被人发了一条恶意指令伪装成合法事件让智能体误判交通事故”ASI03工具误用对应的是“智能体在未授权状态下调用了信号控制工具”ASI10不恰当的物理动作影响对应的是“智能体对信号灯做了不合适的动作直接扰动路网”。除了这十条清单分享里还提到一类专门针对智能体的对抗性评测方法类似AgentDojo这类测试基准。它的思路不是测模型智力而是测智能体在工具调用过程中会不会被诱导、会不会越权、会不会在不利条件下硬执行。交通场景的测试特别适合用这种思路你不只是问“模型答得对不对”还要看“Agent拿着工具时会不会乱来”。我在现场听到一句话记了下来“AI Agent的安全本质是把信任边界画清楚再验证边界内的一切行为。”5. 在会展中心聊出来的共识低代码平台、代码框架和自研原型的适用边界5.1 现场调查大家用什么搭交通智能体参会三天我在茶歇、圆桌和技术交流区做了个非正式调研问同行“你们现在用什么搭智能体”。答案五花八门但基本可以分成三类一类是低代码平台像扣子Coze、Dify这一类通过可视化的方式编排工作流、知识库、插件适合验证想法和快速出Demo一类是通用Agent框架比如AGNO、LangGraph用Python写节点和状态机适合做复杂状态流转还有一类是完全自研把感知模型、推理模型、业务系统直接写在一起适合交通这种重度依赖旧系统的场景。有个观点很有意思来自一位做集成方案的朋友低代码平台解决的是“业务流程编排”代码框架解决的是“状态流转控制”而交通智能体真正卡脖子的往往是数据接入和动作执行层的定制这两件事恰恰是任何现成平台都帮不了的。这个观点我后来在好几个场合验证越验证越觉得准确。5.2 扣子Coze、Dify这种平台和Python手写的智能体到底差在哪这个问题我在展会上问了不下五个人大家的共识大致是这样的低代码平台的上手速度真的快界面画流程、拖拽配插件、上传知识库半小时就能跑通一个演示级Agent。但进入生产环境后瓶颈会很明显一是对私有化部署不够灵活交通项目的数据往往要求本地化部署二是对实时性要求高的场景平台层面往往会引入额外的调度开销三是可审计性你要把决策原因链完整导出来平台给不给这样的开放接口很关键。Python的代码框架比如AGNO、LangGraph这类最明显的优势是可控性强。你可以自己定义工具调用协议、自己控制状态循环、自己持久化日志也能直接调度交通系统里那些老服务、通信协议不用绕道。代价是开发量大团队需要同时懂大模型、懂工程、懂交通业务。在展会现场的共识是先低代码验证再代码化落地是一条比较稳妥的路径但最终必然是代码框架或自研。低代码适合做“快速试错”不适合做“长期生产”这个边界要心里有数。5.3 如果你也想复现这类交通Agent我会这样开始如果让我给一个建议我会说不要一开始就去追“多Agent协同”“数字孪生”“全局优化”这些大词先把“单事件链路”跑通。比如选择一个路口接入一路视频或一组流量数据让Agent做到“检测到异常停车、生成结构化事件、检索附近路网信息、给出红灯时长调整建议、推送给人审批、反馈评估”。这条链路通了后面再加多路口、多Agent、多模态都是加法链路不通什么花哨的架构都是浪费时间。另外补充一点交通智能体落地最容易被忽略的是“数据质量”。同一个路口不同厂商的传感器数据时间戳对不上这种问题我在现场遇到不止一次。你先把数据对齐、事件口径统一做好Agent的推理才不会变成空中楼阁。这也是为什么我在华为全联接大会2026里看到那么多专门做数据接入和云边协同的产品——它们不是在凑数而是在给智能体打地基。展会最后一天交通展区的一位产品负责人把智能体的审计日志拉到投屏上指着一条记录说“那天我们的Agent自己发现它前一天晚上做的一个信号调整导致某个路口的拥堵指数不降反升然后它在凌晨三点自动回退了。”当时大家都笑了笑完又有点感慨一个系统能自己发现自己做错了、还能自己把错误收回这在AI应用里其实已经比很多“只会埋头执行”的传统设备要可靠。我想这可能就是“看到智能体在交通领域怎么工作”之后最值得记住的一件事智能体不只是一个更快的执行者它得是一个能担责、能解释、能自我纠正的决策者。交通行业强调“安全第一”智能体要做的是在放权和安全之间持续找平衡这条路还长但方向已经很清楚了。