ASCII‑Smuggling 逃逸钓鱼攻击的机理与防御路径研究

简介: 本文剖析2026年微软披露的大规模ASCII Smuggling钓鱼事件,揭示攻击者利用Unicode标签块(U+E0000–U+E007F)不可见字符割裂关键词、绕过邮件网关关键字检测的机理。该技术源自AI提示注入,已向传统网络钓鱼迁移,单日投递量高达237万条。研究指出其本质是解析链路与渲染链路的逻辑错位,非漏洞而是流程缺陷,并提出文本归一化、多层检测、AI链路加固等分层防御框架。(239字)

摘要

随着电子邮件安全防护体系持续迭代,威胁攻击者不断探索各类文本混淆手段绕过邮件网关检测,ASCIISmuggling 作为源自 AI 提示注入领域的混淆技术,已经被大规模迁移至传统网络钓鱼作战场景。本文以微软披露的 2026 年大规模不可见 Unicode 字符钓鱼事件为实证样本,梳理该金融主题钓鱼攻击的活动全貌,解析 Unicode 标签块字符实现检测逃逸的底层技术机理,剖析传统基于关键字、特征签名的邮件过滤机制存在的固有缺陷,厘清 AI 安全技术向传统网络威胁迁移的现实风险。研究表明,攻击者利用 U+E0000U+E007F 标签区块内不可见字符,在不改变人类视觉显示效果前提下割裂原始关键词字符序列,实现对字符串匹配类防护组件的绕过,该攻击活动峰值工作日消息发送量可达 237 万条,依托百余个金融主题域名持续开展为期三个月的规模化投递。反网络钓鱼技术专家芦笛指出,ASCIISmuggling 类攻击并非依靠系统漏洞实现突破,而是利用安全解析链路与客户端渲染链路之间的处理逻辑差异制造防护盲区,单一的特征规则很难形成有效拦截。本文从邮件网关预处理、多层检测体系、威胁行为特征识别、业务侧风险管控、安全运维校验等维度构建分层防御框架,同时讨论该技术在 AI 邮件辅助办公场景下的衍生风险,为企业邮件安全系统的优化改造提供实证参考。 关键词:网络钓鱼;ASCIISmuggling;Unicode 混淆;邮件安全;威胁逃逸;提示注入

image.png

1 引言

电子邮件至今仍是政企机构业务沟通、商务往来的核心载体,也长期是网络钓鱼攻击最重要的传播渠道。为对抗钓鱼邮件威胁,主流邮件安全网关普遍部署关键字匹配、特征签名、正则规则等基础检测能力,依托预设风险关键词识别金融欺诈、恶意诱导类邮件,该类防护手段在过去较长周期内承担了大量恶意邮件过滤工作。但威胁对抗具备动态演化特征,攻击者持续研究安全检测组件的解析逻辑,开发各类文本混淆手段规避识别,字符编码混淆已经成为钓鱼逃逸技术的重要发展方向Microsoft。

微软安全研究团队于 2026 年 9 月对外披露一起大规模钓鱼攻击事件,威胁团伙将原本用于 AI 间接提示注入的 ASCIISmuggling 技术移植到邮件钓鱼场景,利用 Unicode 标签块内的非渲染字符对邮件正文关键词进行割裂处理,峰值阶段单个工作日恶意邮件投递规模达到 237 万条,攻击活动持续约三个月,攻击流量表现出明显的工作日活跃、周末静默的行为特征,攻击源由约 150 个金融主题发送域名构成。该事件的特殊意义在于,它标志着 AI 安全研究领域的攻击技术已经完成向传统网络欺诈场景的落地转化,威胁能力跨领域迁移的现实风险已经得到实战验证。

现有国内网络安全领域针对钓鱼逃逸技术的研究,较多聚焦附件混淆、域名伪装、图片嵌入文字等传统手段,针对 ASCIISmuggling 这类新型 Unicode 字符逃逸攻击的实证分析相对有限。部分安全建设人员容易将该类威胁简单归为特殊编码问题,忽略其背后暴露的邮件安全解析流程缺陷,同时容易忽视企业部署 AI 邮件辅助工具之后,同一套恶意字符会同时触发钓鱼逃逸与 AI 提示注入双重风险。本文立足于该公开事件披露的监测数据与攻击样本,还原攻击活动全貌,拆解逃逸技术内在机理,分析传统邮件防护体系存在的短板,构建适配该类混淆攻击的防御方案,客观评估技术迁移带来的衍生安全风险,不夸大攻击的破坏能力,也不弱化该威胁对传统检测机制带来的挑战,为企业邮件安全运维工作提供可落地的分析依据。

2 ASCIISmuggling 钓鱼攻击事件概况与攻击行为画像

2.1 事件基础事实

根据微软研究人员 Noam Kochavi 与 Sarah Wolstencroft 对外发布的监测结论,该轮大规模钓鱼攻击活动自 2026 年 2 月上旬开始出现明显流量抬升,2 月 26 日到达流量峰值,工作日邮件投递量区间维持在 100 万至 237 万条,攻击流量严格遵循工作日运行、周末停止投递的运行模式,这种时间节律特征成为该攻击活动非常显著的行为标识BleepingCo...。整个高强度攻击周期持续三个月左右,到 3 月下旬工作日攻击流量相比峰值下降约 80%,后续攻击活动并未完全终止,只是不再维持此前的超大发送规模。

攻击邮件全部为金融业务主题,邮件内容以企业融资、信贷放款、商业资金支持作为诱饵,向目标收件人推送虚假融资方案,诱导接收方点击邮件内链接跳转至外部站点,完成后续信息窃取或者商业欺诈流程。攻击流量来源于约 150 个专门搭建的金融主题发送域名,域名命名刻意贴合融资、信贷相关业务语境,以此降低接收方对发件域名的戒备心理。

需要明确的客观事实是,尽管该混淆技术能够绕过单纯依靠关键字匹配的过滤组件,微软 Defender for Office365 依靠多层叠加防护体系,仍然拦截超过 99% 的本次攻击邮件,这说明 ASCIISmuggling 的核心价值是突破单一字符串匹配规则,并不代表可以完全绕过具备多维度检测能力的现代邮件安全网关。但对于大量仅依赖简单关键字黑名单、未做 Unicode 标准化处理的邮件防护设备,该攻击手段可以实现有效逃逸,这也是本次事件带给安全行业最主要的警示。

2.2 ASCIISmuggling 技术概念溯源

ASCIISmuggling 最早作为 AI 安全领域的攻击技术进入公众视野,其核心定义为利用不可渲染、不可见的 Unicode 字符,将特定内容隐藏在肉眼看起来完全正常的文本当中。在早期 AI 安全对抗场景中,攻击者将恶意提示指令混入正常文档、网页文本,普通人类阅读者无法察觉隐藏字符,但是大语言模型在解析文本时会读取被隐藏的指令,进而触发间接提示注入攻击,诱导 AI 模型执行攻击者预设的恶意行为。

本次钓鱼攻击是该技术的场景迁移,攻击者不再用它向 AI 模型传递隐藏指令,而是利用不可见字符破坏安全设备的关键词识别逻辑。攻击所滥用的字符主要取自 Unicode Tags 标签块,编码区间为 U+E0000 至 U+E007F。该字符区块最初设计用于语言标记用途,相关设计目标早已被 Unicode 标准废弃,在现代邮件客户端、浏览器当中,该区间字符不会产生任何视觉渲染效果,普通用户阅读邮件时完全感知不到字符的存在。攻击者将标签块字符插入金融类诱饵关键词的字符间隙,例如在单词字母中间插入 U+E0020 标签空格字符,人类看到的仍然是完整的业务词汇,但是安全网关读取原始文本序列时,原始完整词汇已经被不可见字符切割为多段零散字符片段。

2.3 攻击活动完整行为画像

从攻击全流程角度,可以将本次攻击划分为域名准备、邮件文本混淆、批量投递、用户诱骗四个连贯环节。

第一,域名准备阶段。攻击者批量注册 150 个左右带有金融、融资语义特征的发送域名,完成基础邮件发送基础设施搭建,保障大规模邮件外发能力,域名的业务语义同时起到辅助社会工程欺骗的作用。

第二,邮件文本混淆处理。攻击者对邮件正文内的高风险金融关键词做修改,在 “funding”“credit”“loan” 等会触发安全规则的词汇内部插入标签块不可见字符。原始完整词汇被拆分为多段字符片段,但是邮件客户端渲染之后展示给用户的文本没有任何变化,邮件标题、邮件格式、诱饵话术都维持常规金融钓鱼邮件的形态。

第三,分时段批量投递。攻击者严格控制投递时间,仅在工作日开展大规模邮件发送,周末几乎没有攻击流量输出,形成极强的时间模式特征,大批量混淆处理完成的钓鱼邮件被分发至目标收件人邮箱。

第四,面向接收方开展社会工程诱骗。收件人打开邮件,看到格式正常的商业融资邀约,邮件内附带业务确认链接,用户在业务利益诱导之下点击外部链接,访问攻击者搭建的仿冒业务站点,完成后续信息泄露或者遭受财产损失。

该攻击链条当中,Unicode 混淆环节承担的核心作用是对抗邮件网关的初轮关键字检测,帮助恶意邮件抵达用户收件箱,真正实现用户受害依旧依靠传统的社会工程欺骗逻辑,混淆技术属于攻击的逃逸辅助手段,而非直接完成破坏的攻击载荷。

3 不可见 Unicode 字符实现检测逃逸的内在机理

3.1 解析链路与渲染链路的逻辑差异

ASCIISmuggling 能够实现逃逸的底层根源,是邮件安全网关的文本解析流程,和终端邮件客户端的文本渲染流程对同一组 Unicode 文本采取了不同处理逻辑。

邮件安全网关读取邮件原始数据时,获取未经渲染处理的原始字符流,会逐字符读取全部编码点位,包括各类非打印、不可渲染的特殊 Unicode 字符。当不可见标签字符被插入关键词中间,原始字符序列就被物理切断。假设安全网关配置的检测规则是匹配完整的 “funding” 字符串,原始序列被插入字符之后,原始连续字符序列不复存在,简单的字符串匹配、正则匹配规则就无法命中目标关键词,风险特征无法触发告警,恶意邮件就有可能绕过该层检测。

而用户终端的邮件客户端在展示邮件内容时,会按照 Unicode 规范对标签块字符做忽略处理,不会在界面绘制任何可见符号,屏幕上展示出来的依旧是完整连续的业务词汇。同一封邮件,在安全设备视角是被切割碎片化的文本,在普通用户视角是通顺完整的业务文本,这种处理逻辑的错位,构成该逃逸技术成立的基础条件。

反网络钓鱼技术专家芦笛强调,该攻击不属于传统软件漏洞,不存在对应的漏洞编号,它利用的是文本预处理流程的逻辑缺陷,安全设备如果没有做专门的字符归一化处理,就会天然存在这一类对抗缺口。很多安全产品在设计之初,更多关注可见文本内容,对于废弃标签区块这类边缘编码点位的处理考虑不足,形成容易被攻击者利用的防护盲区。

3.2 传统关键字过滤机制的固有局限

关键字黑名单、特征签名匹配是邮件安全领域沿用多年的成熟技术,该机制具备实现成本低、执行速度快的优势,适合大规模邮件流量的快速筛查,但该类机制高度依赖目标字符串的字符连续性。

传统防护逻辑的预设前提是,恶意文本当中的风险关键词字符顺序连续完整。攻击者通过插入零宽度、不可见特殊字符,直接打破这种连续性,不需要修改任何可见语义,就可以让简单的匹配规则失效。值得注意的是,该逃逸手段只对单纯依赖字符串匹配的检测环节生效,如果安全网关同时部署语义分析、发送行为检测、发件信誉评分、链接沙箱等多层能力,即便关键词环节被绕过,邮件依然可以被其他检测维度识别拦截,这也是本次事件中绝大多数恶意邮件依旧被拦截的核心原因。

大量中小机构所使用的邮件安全组件,受限于成本与技术能力,过度依赖关键字规则作为主要检测手段,缺少多维度的复合检测逻辑,这类防护体系面对 ASCIISmuggling 类混淆攻击时会暴露明显短板。部分运维人员在配置安全策略时,仅关注业务可见文本,没有将特殊 Unicode 编码的预处理纳入安全配置的考量范围,进一步放大了该类威胁带来的风险。

3.3 攻击技术跨场景迁移的驱动因素

ASCIISmuggling 从 AI 安全对抗场景迁移到传统钓鱼攻击,不是偶然出现的个案,而是威胁技术发展的必然趋势。一方面,AI 安全领域的大量攻防研究成果会通过公开技术文档、安全社区向外传播,黑灰产团伙可以低成本获取相关技术思路,把已经被验证可行的混淆手段复用到垃圾邮件、网络钓鱼等成熟黑产业务当中。另一方面,黑灰产具备强烈的成本收益导向,当传统绕过手段被安全厂商持续封堵,攻击者会主动寻找新的逃逸路径,Unicode 混淆手段修改成本低,不需要复杂恶意载荷,仅修改文本编码就可以实现对抗效果,适合大规模批量钓鱼活动使用。

与此同时,企业办公场景正在越来越多地引入 AI 辅助工具处理邮件,不少机构部署邮件 AI 助手,自动完成邮件摘要提取、邮件分类、内容整理等工作。同一封经过 ASCIISmuggling 混淆的邮件,在这样的业务环境之下会形成双重威胁:对于邮件安全网关,它尝试绕过钓鱼检测;对于后端 AI 处理组件,嵌入文本的特殊字符又有可能触发提示注入风险,同一输入同时承载两类攻击意图,扩大了攻击面,这也是该技术迁移之后带来的新安全挑战。

4 攻击威胁衍生风险与现实业务影响分析

4.1 对中小型机构邮件防护体系的冲击

大型企业所部署的商业化邮件安全网关大多具备多层检测能力,即便关键字匹配环节被绕过,发件人信誉、链接沙箱、行为分析等其他维度依旧可以识别恶意邮件,威胁带来的直接损失可控。但是大量中小型组织、小型政企分支机构使用轻量化邮件防护方案,防护能力高度依赖关键字黑名单,缺少行为分析、沙箱检测等高阶能力。在这类环境当中,ASCIISmuggling 混淆处理后的钓鱼邮件可以穿透防护直达员工邮箱,提升内部人员遭受钓鱼欺诈的概率。

这类机构安全运维人员数量有限,对 Unicode 标签块这类偏底层编码问题认知不足,不容易发现预处理流程存在缺陷,威胁出现之后难以快速定位逃逸发生的根本原因,容易出现反复被同类攻击绕过却无法完成有效修复的情况。

4.2 AI 邮件集成场景下的复合攻击风险

当企业将大模型能力接入邮件业务流程,实现邮件自动摘要、自动回复、邮件内容研判等功能,ASCIISmuggling 就不再仅仅是钓鱼逃逸手段,同时成为提示注入的载体。攻击者可以在同一封邮件内部,一方面用混淆关键词绕过邮件安全网关钓鱼检测,另一方面利用标签块字符向 AI 助手埋藏隐藏指令。普通管理员和员工阅读邮件看不到隐藏指令,但是后端 AI 组件解析完整原始字符流时,隐藏指令会被模型读取执行,可能造成内部信息泄露、业务逻辑被篡改等次生后果。

该场景下的风险具备隐蔽性,传统的钓鱼处置思路无法覆盖 AI 组件被诱导这一风险点,很多机构在上线 AI 邮件辅助系统时,只关注大模型本身的安全配置,忽略上游邮件输入文本的归一化预处理,将原始未经处理的邮件文本直接送入大模型,形成新的安全薄弱环节。

4.3 威胁变种持续迭代的潜在可能性

本次公开事件中攻击者主要使用标签块字符切割金融关键词,实现绕过关键字检测。从技术逻辑推演,该混淆手段具备继续变种演化的空间。威胁团伙后续可以更换其他零宽度、不可打印 Unicode 编码点位,调整字符插入位置,对更多类型诱饵关键词进行混淆处理,将该手段从金融钓鱼拓展到政务钓鱼、供应链钓鱼等更多攻击场景。同时攻击者可以结合域名混淆、图片嵌入文本、附件载荷等多种逃逸手段叠加使用,进一步提升绕过单一防护组件的概率。

不能简单认为本次事件披露之后,该攻击手段就会快速消亡,与之相反,相关技术细节公开之后,更多黑灰产团队会学习该混淆思路,后续同类样本的出现频率会维持在较高水平。

5 面向 ASCIISmuggling 攻击的分层防御体系构建

针对不可见 Unicode 字符带来的逃逸威胁,不存在某一项单一技术可以彻底消除全部风险,需要从邮件预处理环节、安全检测架构、威胁行为识别、系统运维校验、AI 业务场景加固多个层面构建分层防御,在攻击链路的不同节点形成阻断能力。

5.1 邮件网关侧增加 Unicode 文本归一化预处理

微软研究团队给出的核心防御建议,所有需要执行关键字、特征签名、正则匹配的内容,在执行检测逻辑之前,应当先完成文本归一化预处理,对标签块 U+E0000U+E007F 区间以及其他非渲染无效编码点位做剥离或者折叠处理,将被切割的关键词恢复为原始连续字符序列,之后再运行各类风险匹配规则。经过归一化处理之后,插入在词汇中间的不可见字符被清除,原本被割裂的关键词恢复完整,原有关键字规则就可以正常命中风险内容。

该处理流程应当部署在邮件网关的检测流水线最前端,也就是所有内容检测逻辑执行之前完成,而不是放在客户端渲染阶段。客户端渲染环节的字符处理只改变用户看到的显示效果,不会反向修改安全网关拿到的原始检测文本,因此仅仅依靠终端客户端的渲染逻辑无法解决逃逸问题。企业安全运维人员应当向邮件安全厂商确认设备默认是否开启该类编码点位的清理能力,如果默认配置没有覆盖,需要完成对应预处理策略配置。同时运维人员需要兼顾业务兼容性,识别少数合法使用特殊 Unicode 字符的业务场景,避免预处理策略造成正常业务邮件误拦截。

5.2 搭建多维度叠加的邮件安全检测架构

单纯依靠文本关键字匹配的防护架构本身就存在天然缺陷,攻击者可以通过字符混淆、同义词替换、文本图片化等大量手段实现绕过。企业应当放弃将关键字黑名单作为主要拦截手段的建设思路,构建多维度复合检测体系。

除文本内容检测之外,完整防护体系应当覆盖发件域名信誉评估、发送行为特征识别、邮件内链接沙箱动态检测、附件深度解析、邮件元数据分析等多个维度。针对本次攻击呈现出的典型行为特征,安全运维可以重点关注异常特征:大批量来自新增金融主题域名、流量具备明显工作日爆发周末静默的时间规律、邮件正文大量出现标签块 Unicode 编码点位,当多个特征同时出现,就可以提升邮件的风险判定等级。反网络钓鱼技术专家芦笛指出,字符混淆类攻击本质上是在对抗文本层面检测,只要防护体系不把全部希望寄托在文本匹配,即便文本混淆绕过单一层面,其他检测维度依旧可以完成风险识别。

5.3 针对 AI 邮件业务链路做专项加固

对于已经部署 AI 邮件辅助能力的机构,需要把邮件文本归一化预处理延伸到大模型输入链路。在邮件内容送入大语言模型之前,对输入文本执行和邮件网关相同的特殊 Unicode 字符清理逻辑,消除 ASCIISmuggling 带来的提示注入风险,不能直接把原始未经清洗的邮件原始字符流交给 AI 模型处理。

同时应当对 AI 邮件助手做好能力边界约束,限制模型访问内部敏感数据的权限,配置输入输出过滤机制,降低即便发生提示注入之后造成的次生危害。安全团队需要将 AI 组件纳入邮件安全整体评估范围,不再将邮件网关和 AI 业务系统视作两个完全独立的安全域,实现上下游链路的统一风险管控。

5.4 常态化安全校验与威胁情报协同

企业安全运维需要建立常态化的校验机制,定期对邮件安全网关的预处理能力进行验证,构造包含标签块不可见字符的测试样本,验证关键字规则在经过混淆之后是否还能够正常触发告警,及时发现配置失效、策略遗漏等问题,不要完全依赖厂商的默认配置。

加强外部威胁情报的引入,安全厂商公开的 ASCIISmuggling 相关威胁样本、发送域名特征、异常编码特征可以同步导入本地邮件检测规则库,提升对同类攻击的发现能力。同时安全团队内部开展面向运维人员的技术科普,让运维人员理解特殊 Unicode 编码带来的逃逸风险,在处理钓鱼邮件逃逸类故障时,能够将字符归一化纳入故障排查的思考范围,避免把排查局限在可见文本层面。

5.5 面向终端用户的风险认知引导

该类攻击的混淆动作全部发生在邮件底层编码,普通邮件用户无法通过肉眼分辨邮件是否插入不可见字符,因此不适合向普通员工灌输识别特殊编码的操作要求。面向终端用户的安全培训重点应当回归钓鱼邮件通用处置范式:不要轻信陌生发件人推送的融资、信贷类业务邀约,邮件当中附带的外部链接,不要直接点击,需要通过独立浏览器手动访问业务站点核验信息;对于意外收到的商业资金邀约邮件,优先通过企业内部沟通渠道核实业务真实性。

即便安全网关因为混淆问题出现漏报,用户建立正确的业务核验习惯,依旧可以阻断攻击的最后一环,避免发生业务损失。

6 结语

微软披露的 ASCIISmuggling 大规模钓鱼攻击事件,展现出网络威胁对抗当中一个值得重视的趋势:AI 安全领域的攻防技术会持续向传统黑灰产业务迁移,原本用于对抗大模型的混淆手段,已经被威胁团伙用于绕过邮件安全防护。该攻击利用 Unicode 标签块不可渲染字符制造解析链路与渲染链路之间的逻辑错位,在不改变用户可见邮件内容的前提下,破坏传统关键字匹配检测逻辑,实现大规模邮件钓鱼的检测逃逸。

该威胁并不属于高危系统漏洞,具备多层防护能力的现代邮件安全产品可以通过其他检测维度完成大部分恶意邮件拦截,但是对于过度依赖关键字黑名单的轻量化防护体系,该攻击能够形成有效穿透。风险治理不能简单理解为增加一条针对特定 Unicode 编码的拦截规则,需要从邮件文本预处理流程改造、多维度安全检测架构建设、AI 业务链路加固、常态化运维校验多个角度协同推进。归一化清理特殊编码点位是基础技术处置手段,但它不能解决全部钓鱼威胁,社会工程欺骗依旧是攻击最终达成目的的核心环节。

随着各类混淆技术不断迭代,未来还会出现更多利用字符编码特性实现逃逸的钓鱼变种。安全建设人员应当跳出仅关注可见文本的思维定式,重视底层编码解析环节存在的安全缺口,同时持续跟踪跨领域威胁技术迁移现象,把其他安全领域已经出现的攻击思路纳入自身风险评估范围,持续完善邮件安全防护体系的对抗能力。

编辑:芦笛(公共互联网反网络钓鱼工作组)

来源:迪妙网络空间安全学院

目录
相关文章
|
4天前
|
人工智能 自然语言处理 安全
阿里云AI数智鉴密:AI 生成内容如何拿到一张"防篡改的身份证"
隐形水印 + C2PA签名:让AI生成内容“持证上岗”。
1122 0
|
13天前
|
人工智能 自然语言处理 安全
阿里云千问办公、Qoder Teams、Qoder CN区别与选择指南:模型能力、适用场景与最新活动参考
本文聚焦阿里云2026年推出的三款自研AI办公产品,清晰拆解千问办公、Qoder Teams、Qoder CN的差异化定位与能力边界:千问办公主打职场全场景提效,支持自然语言指令一键完成PPT生成、数据分析等高频办公任务;Qoder Teams面向程序员团队,深度整合AI代码生成、团队协同与企业知识库能力;Qoder CN则专为金融、政务等强合规场景打造,实现数据不出境与VPC私有化部署。文章同步给出分场景选型指南与最新活动定价,帮助不同类型的企业按需组合产品,实现业务岗、研发岗与强合规场景的AI能力全覆盖。
3737 4
阿里云千问办公、Qoder Teams、Qoder CN区别与选择指南:模型能力、适用场景与最新活动参考
|
4天前
|
人工智能 运维 BI
阿里云千问办公QwenWork深度解析:基于Qwen3.8,六大核心能力重构企业全自动化工作流与计费选型指南
传统AI办公工具大多停留在对话问答、文档摘要、简单文案生成层面,只能完成单点碎片化任务,无法自主拆解复杂业务流程,很难串联多工具、多文档、外部业务系统完成端到端完整工作交付。很多企业在落地AI办公的时候,需要组合多款不同工具,来回切换界面,手动复制粘贴中间结果,智能化改造落地门槛居高不下。千问办公QwenWork是整合多款智能体产品能力打造的一体化企业办公智能体平台,底层基座依托Qwen3.8大模型,打通桌面端Agent、云端Agent、企业协同Agent三种运行形态,不再局限简单问答,接收业务目标之后自主拆解任务步骤,调用各类工具,处理文档、表格、浏览器自动化、数据查询,直接输出可交付的办公
1355 0
|
4天前
|
人工智能 安全 前端开发
刚刚 GPT-6 Astra 发布,全球最强,AGI 时代到来!
OpenAI 正式推出 GPT-6 Astra 模型,带大家看看这次 GPT 有哪些提升,跟 Claude Fable 5.1 有什么差距?AI 编程能力如何?AGI 真的来了么?
612 0
|
10天前
|
人工智能 并行计算 数据可视化
秋叶ComfyUI-AKI最新整合包|完整部署教程+核心指令手册
秋叶ComfyUI-AKI一键整合包,国内适配最优、稳定性最强的商用/学习级版本:全封装虚拟环境、预装90%常用节点、内置绘世启动器与成熟工作流,免配置、零依赖、解压即用,完美兼顾新手入门与专业批量生产需求。(239字)
|
14天前
|
人工智能 Linux iOS开发
Ollama使用教程:Ollama官网下载、Ollama本地部署大模型(2026最新)
Ollama 是一款免费开源的本地大模型运行工具,支持在 Windows/macOS/Linux 上离线运行 Qwen、DeepSeek、Llama 等主流开源模型,数据不出本机、隐私安全。提供 OpenAI 兼容 API,命令行一键拉取/运行/管理模型,无需联网,无调用限制,是开发者与 AI 爱好者部署本地 AI 助手的理想选择。(239 字)