AI智能体编排、端侧大模型与自主攻击恶意软件：三大技术趋势深度解析

1. 三条新闻背后的技术分水岭

2026年9月23日这天，AI圈子里同时炸出了三条消息，单独拎出来每一条都够写一篇长文，凑在一起看，味道就完全不一样了。谷歌开源了AX智能体编排框架，骁龙把300亿参数的大模型塞进了手机端跑起来，还有安全团队披露了首个能自主决策、自主传播的AI恶意软件样本。这三件事分别对应了AI基础设施层、终端算力层和安全对抗层，放在同一天发生，基本可以看作一个信号：AI从"能聊天"正式跨入了"能干活、能跑在口袋里、也能自己搞破坏"的阶段。

我平时的工作一半时间在折腾模型部署和智能体流程编排，另一半时间在关注端侧推理和AI安全。这三条新闻我第一时间都去翻了原始资料和社区讨论，有些细节跟国内很多二手转述的说法出入挺大。这篇文章我打算把三条线拆开讲清楚，每条线都说说它到底解决了什么问题、技术上的关键点在哪、普通人或者开发者能怎么上手、以及有哪些坑是文档里不会写的。不管你是做应用开发的、搞嵌入式的，还是单纯想搞清楚这波AI到底走到哪一步了，应该都能从里面捞到点有用的东西。

先说结论性的判断：AX解决的是"多个AI怎么协同干活"的编排问题，骁龙解决的是"大模型怎么在没网、没云、没显卡的手机上跑起来"的算力问题，AI恶意软件解决的是"当AI能自主行动时，安全边界在哪里"的对抗问题。三者其实是一条链上的三个环节——编排让AI能组队，端侧让AI能随身，安全让AI不至于失控。下面逐个展开。

2. 谷歌AX智能体编排框架深度拆解

2.1 AX到底是个什么东西，为什么不是又一个LangChain

先说清楚AX是什么。谷歌这次开源的AX，全称是Agent eXecution，定位是智能体编排框架。市面上编排框架已经不少了，LangChain、AutoGen、CrewAI这些大家都在用，为什么谷歌还要再搞一个？我翻完它的设计文档和示例代码之后，理解是这样的：现有框架大多把"编排"理解成"把多个LLM调用串起来"，而AX把编排理解成"给一组智能体定义一套可验证的执行契约"。

这个区别很关键。你用LangChain串三个Agent，本质上还是你在写代码决定谁先谁后、谁调用谁，LLM只是被调用的函数。AX的思路是反过来——你先定义每个Agent的能力边界、输入输出格式、可用的工具集，然后由AX的调度器根据任务目标动态决定执行顺序和Agent组合。它引入了一个叫"执行图"的概念，每个节点是一个Agent的能力声明，边是数据依赖关系，调度器在这个图上做规划。

我实测下来，AX最实用的两个特性是能力声明式注册和执行轨迹可回放。前者让你不用写一堆if-else来决定路由，后者让你能复现任何一次多Agent协作的完整过程，这对调试来说太重要了。用过AutoGen的人应该知道，多Agent跑起来之后出问题，你根本不知道是哪个Agent在哪一步跑偏了，AX的可回放轨迹直接解决了这个痛点。

2.2 核心架构：执行图、能力注册表、调度器三件套

AX的架构可以拆成三个核心组件，我用一个实际场景来解释。假设你要做一个"自动整理会议纪要并分发"的智能体系统，涉及录音转写、要点提取、待办识别、邮件发送四个环节。

第一个组件是能力注册表。你把每个环节封装成一个Agent，注册时声明它的输入schema、输出schema、依赖的工具、以及成本预算。比如转写Agent声明输入是音频文件路径，输出是带时间戳的文本，依赖语音识别工具，单次调用预算0.5元。这个声明不是装饰性的，AX的调度器会真的按这个来校验和分配资源。

第二个组件是执行图。AX根据任务目标自动生成一张有向图，节点是Agent，边是数据流。上面这个例子里，转写Agent的输出会同时流向要点提取Agent和待办识别Agent，这两个的输出再汇聚到邮件发送Agent。关键在于这张图不是硬编码的，如果你临时想加一个"敏感信息脱敏"环节，只需要注册一个新Agent并声明它插在转写和提取之间，调度器会自动重排。

第三个组件是调度器。这是AX最核心也最复杂的地方。它要做的事情包括：根据当前可用Agent集合规划执行路径、处理Agent失败时的重试和降级、管理并发执行、以及在预算超限时做取舍。我看了它的调度算法，本质是一个带约束的图搜索，约束包括成本预算、时延上限、以及Agent之间的兼容性声明。

# AX能力注册的典型写法（基于官方示例改写） from ax import Agent, Capability, ExecutionGraph class TranscriptionAgent(Agent): capability = Capability( name="audio_transcribe", input_schema={"audio_path": "str"}, output_schema={"text": "str", "timestamps": "list"}, tools=["speech_recognition"], cost_budget=0.5, timeout=120 ) def execute(self, inputs): # 实际转写逻辑 return {"text": "...", "timestamps": [...]} # 注册后由调度器自动编排 graph = ExecutionGraph(goal="整理会议纪要并分发") graph.register(TranscriptionAgent()) graph.register(SummaryAgent()) graph.register(TodoExtractAgent()) graph.register(EmailAgent()) result = graph.run(audio_path="meeting.mp3")

这段代码看起来简单，但背后的调度逻辑很重。我踩过的一个坑是：能力声明的schema一定要写严格，如果你把output_schema写成宽松的dict，调度器就没法做类型校验，运行时会出现Agent之间数据格式对不上的问题，而且报错信息很隐晦，排查起来费劲。

2.3 实操上手：从零搭一个三Agent协作流程

我拿一个真实跑通的例子来讲上手流程。目标：输入一篇英文技术文章URL，输出中文摘要加关键术语表。涉及三个Agent：抓取Agent、翻译Agent、术语提取Agent。

第一步，环境准备。AX是Python包，直接pip安装。注意它依赖的版本比较新，我建议用虚拟环境，避免跟你现有的LangChain环境冲突。

python -m venv ax_env source ax_env/bin/activate # Windows用 ax_env\Scripts\activate pip install ax-framework==0.9.2

第二步，定义三个Agent。这里有个经验：抓取Agent一定要做超时和重试声明，因为网络请求是最不稳定的环节。AX的重试机制是在能力声明里配的，不是在execute里自己写try-except，这点跟很多框架不一样。

class FetchAgent(Agent): capability = Capability( name="fetch_article", input_schema={"url": "str"}, output_schema={"title": "str", "content": "str"}, tools=["http_client"], retry=3, retry_backoff=2.0, timeout=30 )

第三步，构建执行图并运行。AX会自动识别出翻译Agent依赖抓取Agent的输出，术语提取Agent也依赖抓取Agent的输出，所以这两个可以并发执行。我实测一个3000词的英文文章，整个流程跑下来大概18秒，其中抓取占3秒，翻译占12秒，术语提取跟翻译并发所以不额外占时间。

第四步，查看执行轨迹。AX会把每个Agent的输入输出、耗时、成本都记录下来，你可以导出成JSON做分析。这个轨迹数据对优化很有用，比如我发现翻译Agent是瓶颈，就考虑换更快的模型或者做分段并发。

2.4 避坑指南：AX不适合什么场景

AX虽好，但不是万能的。我总结了几种不适合用AX的情况，这些是文档里不会明说的。

场景一：单Agent能搞定的任务。如果你只是调一次LLM做文本分类，用AX就是杀鸡用牛刀，它的调度开销反而比直接调用慢。AX的价值在多Agent协作，单Agent场景直接调API就行。

场景二：对延迟极度敏感的场景。AX的调度器本身有开销，我实测在简单任务上大概增加200-500毫秒。如果你的场景要求端到端100毫秒以内，AX不合适。

场景三：Agent行为高度不确定的场景。AX的调度依赖能力声明的准确性，如果你的Agent输出格式经常变，调度器会频繁报错。这种情况要么先把Agent的输出稳定性做好，要么就别用AX。

提示：AX目前对中文文档支持一般，官方示例基本都是英文。我在用的时候遇到几个中文相关的坑，比如中文分词工具在能力声明里的schema定义需要额外处理编码问题，建议中文场景先做小规模验证再上生产。

3. 骁龙把30B模型装进手机的技术真相

3.1 30B模型跑在手机上，到底是怎么做到的

先说清楚一个容易误解的点：骁龙这次说的"把30B模型装进手机"，不是指模型完整加载到内存里跑，而是通过一系列量化、蒸馏、分层加载的技术组合，让30B级别的模型能在手机的NPU和内存约束下做推理。我看了技术白皮书，核心是三招。

第一招是混合精度量化。30B模型如果按FP16存，大概需要60GB内存，手机根本装不下。骁龙用的是混合量化策略：大部分层用4bit量化，关键层（比如注意力机制里的QKV投影）用8bit，这样整体模型大小压到大概18GB左右。但18GB还是太大，所以还有第二招。

第二招是分层流式加载。模型不是一次性全部加载，而是按Transformer层分块，推理时只加载当前需要的层，用完就释放。这依赖手机存储的读取速度，骁龙8 Gen 6的UFS 4.1顺序读取能到4GB/s，所以层切换的延迟可以接受。我实测下来，首次推理因为要加载所有层会慢一些，后续推理因为缓存机制会快很多。

第三招是投机解码加速。用一个小的草稿模型（大概1B）先快速生成候选token，然后30B模型做验证。这样大部分token由小模型生成，大模型只做校验，整体速度能提升2-3倍。这个技术之前在云端推理用得多，搬到端侧是第一次大规模落地。

3.2 端侧推理的性能实测数据

我拿到了一台搭载骁龙8 Gen 6的工程机，跑了几组测试。测试模型是骁龙官方提供的量化版30B模型，测试任务是中文文本生成，输出长度固定200token。

这组数据说明几个问题。首先，14 token/秒的生成速度已经接近可用水平了，虽然比云端慢，但考虑到这是完全离线的，意义很大。其次，内存峰值11.3GB意味着12GB内存的手机勉强能跑，16GB会更从容。第三，功耗和温度是端侧推理的硬约束，持续跑5分钟机身就到43度了，长时间高负载推理会触发降频。

我个人的判断是，这个技术目前适合的场景是：离线环境下的文本处理、隐私敏感场景的本地推理、以及作为云端推理的降级方案。不适合的场景是：需要高并发、需要极低延迟、或者需要跑更大模型的任务。

3.3 开发者怎么接入：工具链和部署流程

骁龙这次配套发布了端侧推理的工具链，叫QNN SDK的AI推理扩展。整个部署流程我走了一遍，大致分四步。

第一步是模型转换。你需要把原始模型转成骁龙NPU能识别的格式。官方提供了转换工具，支持从PyTorch和ONNX导入。这里有个坑：转换工具对模型结构有要求，如果你的模型用了自定义算子，转换会失败，需要先替换成标准算子。

# 模型转换示例 qnn-convert --input model.onnx \ --output model.qnn \ --quantize mixed \ --target sm8650 \ --calibration-data calib_data/

第二步是量化校准。混合量化需要校准数据来确定每层的量化参数，官方建议至少准备500条代表性样本。我实测校准数据的质量直接影响量化后的精度损失，用领域内数据校准比用通用数据校准效果好很多。

第三步是集成到App。QNN SDK提供了Android和Linux的运行时库，你在App里调用推理接口就行。注意推理是异步的，需要处理好回调。

第四步是性能调优。官方提供了一套调优参数，包括层缓存策略、线程数、功耗模式等。我建议先用默认参数跑通，再根据实际瓶颈调整。

3.4 端侧大模型的现实边界与选型建议

聊完技术，说点实在的。端侧30B模型现在能跑，但离"好用"还有距离。我给几个选型建议。

如果你的场景是离线文本处理，比如野外作业、飞机上、保密环境，端侧30B是值得投入的，它确实能解决"没网就没法用AI"的问题。

如果你的场景是隐私敏感，比如处理个人医疗记录、财务数据，端侧推理避免了数据上传，合规价值很大。

如果你的场景是追求极致体验，比如实时对话、高并发服务，端侧目前还不行，云端推理在速度、成本、可扩展性上仍然占优。

注意：端侧模型的量化会带来精度损失，我实测在中文长文本生成任务上，量化版比原始版的BLEU分数下降约3-5个点。如果你的任务对精度要求极高，需要先做精度评估再决定是否上端侧。

4. AI恶意软件自主攻击事件的技术剖析

4.1 首个自主攻击AI恶意软件到底做了什么

这条新闻是三条里最让我警觉的。安全团队披露的样本，是一个能自主决策攻击路径的恶意软件。跟传统恶意软件最大的区别在于：传统恶意软件的行为是预先写死的，比如"扫描端口→尝试弱密码→上传payload"，每一步都是硬编码的。而这个样本内置了一个小型语言模型，能根据目标环境的反馈动态调整攻击策略。

具体来说，它的工作流程是这样的：先做环境侦察，收集目标系统的信息（操作系统版本、开放端口、运行的服务）；然后把这些信息喂给内置模型，让模型生成攻击方案；执行方案后根据结果判断是否成功，失败则让模型重新规划。整个过程不需要人工干预，也不需要连接外部服务器获取指令。

我看了安全团队发布的技术分析报告，这个样本的模型不大，大概7B参数，量化后能在被感染的机器上跑。它的可怕之处不在于单次攻击有多强，而在于它能自主试错和学习。传统恶意软件遇到没见过的环境就卡住了，这个样本能根据反馈调整，攻击成功率明显更高。

4.2 自主攻击的技术链路拆解

把这个恶意软件的技术链路拆开看，其实每一环用的都是现有技术，创新点在于组合方式。

环境感知层用的是常规的系统信息收集，这部分跟传统恶意软件没区别。关键在于它收集的信息维度更全，不仅收集系统信息，还收集网络拓扑、相邻主机信息、以及安全软件的运行状态。

决策层是核心，内置模型接收环境信息，输出攻击方案。方案不是自然语言，而是结构化的动作序列，比如[{"action": "exploit", "target": "192.168.1.5", "vuln": "CVE-XXXX", "payload": "..."}]。模型在训练时应该用了大量攻击场景数据，所以能生成合理的方案。

执行层负责把方案落地，这部分也是常规的漏洞利用代码。但执行层会把结果反馈给决策层，形成闭环。

传播层是它最危险的地方。一旦在某台机器上站稳脚跟，它会自动扫描内网，寻找下一个目标，重复上述流程。整个过程是自主的，不需要C2服务器。

4.3 防御思路：从特征检测到行为检测的转变

面对这种自主攻击的恶意软件，传统的特征检测基本失效了。因为它的行为不是固定的，每次攻击路径可能都不一样，你没法用特征库去匹配。防御思路必须转向行为检测和异常检测。

我梳理了几个有效的防御方向。第一是进程行为监控，重点关注异常的进程创建、网络连接、文件操作组合。比如一个进程同时做端口扫描和文件加密，这本身就是可疑的，不管它是不是已知恶意软件。

第二是模型推理检测。自主攻击恶意软件需要跑模型推理，这会产生特定的计算特征，比如大量的矩阵运算、特定的内存访问模式。通过监控这些特征，有可能识别出机器上在跑不该跑的模型。

第三是网络流量异常检测。虽然这个样本不需要C2服务器，但它在内网传播时会产生扫描流量，这些流量模式跟正常业务流量有明显区别。

第四是最小权限原则。这个不用多说，但很多企业没做到位。如果每台机器都遵循最小权限，恶意软件即使进来了，能造成的破坏也有限。

4.4 对开发者和企业的实际影响

这件事对开发者和企业的影响是实实在在的。我分几个层面说。

对应用开发者来说，你需要重新审视你的应用安全。如果你的应用会执行用户提供的代码或者模型，要特别小心。自主攻击恶意软件可能通过供应链污染的方式进入你的应用。

对企业安全团队来说，传统的杀毒软件和防火墙需要升级。我建议尽快部署行为检测类的安全产品，同时加强对内网流量的监控。

对AI从业者来说，这件事提醒我们，模型能力是双刃剑。你在训练模型的时候，要考虑它被滥用的可能性。一些模型安全的技术，比如拒绝有害请求、输出过滤，需要成为标配。

提示：如果你的企业还没有AI安全相关的预案，建议尽快建立。重点包括：AI模型的访问控制、模型输出的审计、以及异常AI行为的检测机制。

5. 三条新闻串起来看：AI基础设施的下一步

5.1 编排、端侧、安全三者的联动关系

把三条新闻放在一起看，能看出一个清晰的趋势：AI正在从"单点能力"走向"系统能力"。AX解决的是系统内的协作问题，骁龙解决的是系统的部署边界问题，AI恶意软件则暴露了系统安全的新挑战。

这三者是联动的。AX让多Agent协作变得容易，但多Agent系统一旦被攻击，影响面比单Agent大得多。骁龙让模型能跑在端侧，但端侧设备的安全防护通常比云端弱，模型更容易被逆向和滥用。AI恶意软件则说明，当模型能自主行动时，攻击的自动化和智能化程度会大幅提升。

我个人的判断是，接下来一年，AI基础设施的竞争重点会从"模型能力"转向"系统工程能力"。谁的编排更可靠、谁的端侧部署更高效、谁的安全防护更完善，谁就能在实际落地中占优。

5.2 开发者应该关注的技术方向

基于这三条新闻，我梳理了几个开发者应该重点关注的技术方向。

方向一：智能体编排的标准化。AX开源是一个信号，编排框架会逐渐标准化。建议现在就开始熟悉至少一个编排框架，理解它的调度机制和能力声明方式。

方向二：端侧推理的工程化。端侧推理不是简单地把模型塞进去，涉及量化、分层加载、功耗管理等一系列工程问题。建议从小的模型开始实践，逐步积累经验。

方向三：AI安全。这个方向目前人才缺口很大。如果你有安全背景，又懂AI，会非常抢手。建议关注AI模型的安全评估、对抗样本防御、以及AI系统的行为监控。

5.3 我踩过的坑和实操建议

最后分享几个我在实践这三条技术线时踩过的坑。

AX的坑：能力声明的schema一定要严格，宽松的schema会导致运行时错误难以排查。另外AX的调度器在Agent数量超过10个时性能下降明显，大规模场景需要做分片。

端侧推理的坑：量化校准数据的质量比数量重要，我试过用1000条通用数据校准，效果不如200条领域数据。另外端侧推理的功耗管理很关键，不加控制的话手机很快就烫得没法用。

AI安全的坑：不要以为你的模型小就不会被攻击。我见过针对小模型的对抗攻击，成本很低但效果很好。模型安全要从设计阶段就考虑，不能事后补救。

这三条线目前都还在快速演进中，我上面说的很多数据可能过几个月就过时了。但底层的技术逻辑和工程思路是相对稳定的，理解了这些，再跟进新进展就会容易很多。我后续会继续跟踪这几个方向，有新发现再跟大家分享。