Qoder CLI 上运行 Qwen3.8-Max:5 个硬核任务实测

图片

近日,Qwen3.8-Max 正式发布,Qoder 全家桶产品同步首发接入。自模型 Preview 阶段起,Qoder CLI 便深度参与了评测及验证工作,见证了模型的快速进化成长。

在正式版发布后,为了验证 Qwen-3.8 Max 在 Qoder CLI 上的效果,我们重新选取了一组高难度的长程任务,在无人工干预的前提下,让 Qoder CLI 自发进行数百次工具调用,自主发现并修复问题,直至完成目标。

本文所选取的5项任务,也交给了 Claude Opus 4.8、GPT-5.6 Sol 和 Claude Fable 5 进行横向对比*(外部模型测试是通过实验方法进行,非 Qoder 正式版本能力,仅用于此次对比测试)*。

在这组评测中,Qoder CLI 不只是模型调用入口,而是承载任务执行的 Agent Harness。它为模型提供一致的工具集、执行环境与反馈闭环,使模型在单轮提示词后自主完成长程执行与迭代验证。在相同的评测条件下,**四个模型均在没有人工追加提示的情况下独立运行至结束并提交产物。**其中部分任务持续数小时,涉及数百次工具调用。比如在《清明上河图》任务中,Qoder CLI 连续自主运行了 4 小时 23 分钟,主动截取约 378 张 图片进行自我迭代。

本次评测的全部材料已开源,可详见文末附录。

01《清明上河图》:从一张古画到能游览的三维世界

如果只是把《清明上河图》铺在网页上,并不难。真正困难的是:不使用原图充当背景,让模型从零搭出一个可以进入、游览和切换视角的三维世界。

💬**题目:**从空白目录开始,根据《清明上河图》高清原图制作一份单文件、可离线运行的真三维长卷。作品包含六个章节和24个固定机位,所有主体均使用程序化实体几何构建,不以图片代替三维场景。重点考察图像理解、空间推理和长时间自主执行能力。

这道题想看的,是模型能否完成三个连续的跨越:

• 先看懂。《清明上河图》信息密度极高。模型需要从长卷中识别人群、船只、建筑、车马和沿街摊位,还要理解它们之间的关系,而不是只抓住虹桥、城门等少数标志性元素。

**• 再搭出来。**原画只提供二维信息,模型却需要自行推断物体的前后关系、空间尺度和场景布局,把一幅只能观看的画,重建成一个能够移动镜头的三维世界。

**• 最后跑到底。**这不是一次生成就能完成的任务。模型需要在数小时、数百次工具调用中持续检查画面、修改代码、重新渲染,同时避免在漫长的迭代中偏离最初目标。

四个模型都交出了真三维场景,没有一家用图片冒充。按功能交付、三维几何、内容叙事、视觉贴合、工程质量五项各 20 分打分,Claude Fable 5 得 73 分,Claude Opus 4.8 得 72 分,Qwen3.8-Max 得 63 分,GPT-5.6 Sol 得 56 分。耗时分别为 189、72、263 和 47 分钟。

Qwen3.8-Max走了一条与其他三家不同的工程路线:它没有用现成的三维引擎,自己从零写了一个渲染器。它的文件也最小,123 KB,对 Claude Fable 5 的 822 KB 和 Claude Opus 4.8 的 549 KB;渲染效率最高,每帧只需要让显卡绘制约 46 批物体,Claude Fable 5 的场景要画三千到五千七百批。

代价出在画面上。六个章节的场景都偏空,城门口没有车马和集市;地面和天空还出现了矩形补丁一样的颗粒痕迹。这些补丁不是失误,是它主动加的:它花了大量轮次调整画面的颗粒质感,让统计出来的相似度更接近原画。指标确实上去了,肉眼看到的画质反而变差。它也是耗时最长的一家。

Opus 4.8 的画面完成度最高:虹桥上有人群、桥下有船、两岸有摊位,最接近原画里的市井热闹。Claude Fable 5 的三维结构最扎实,但画面同样偏空。GPT-5.6 Sol 的桥体零件明显错位穿插,最后它主动提交了一份"未完成"报告,没有把做不完伪装成做完了。

02用 Rust 从零实现一个高性能内存 KV 存储服务

让模型写代码不算新鲜。这道题的难度来自两件事叠加:Rust 与数据库,两者各自都属于工程上偏难的一类。

💬**题目:**用 Rust 从零实现一个高性能内存 KV 存储服务,采用指定的 QKV 二进制协议和四个命令。核心逻辑必须自行编写,不使用异步运行时、网络框架或第三方存储、缓存、哈希表及内存分配库,也不使用 io_uring,全程离线完成。初始目录仅提供任务书、协议规范和基础测试。

这是一个非常硬核的题目,正常一个高性能的键值数据库,至少要同时具备五项能力:

• 网络层:同时服务大量连接

• 协议解析:容忍数据任意分段到达

• 存储结构:支持多线程同时读写而不出错

• 过期回收:自动清理到期数据

• 过载保护:请求量超出处理能力时自我保护

从结果来看,四个模型都在QoderCLI上完成了任务,平均代码在 860 到 1615 行之间,**且均在一次提示词之后自主产出。**27 条私有测试全部通过,正确性上没有区分度。差距集中在性能上。

图片

图2 极限吞吐实测结果

极限读吞吐依次为 Qwen3.8-Max 11.8M、Claude Opus 4.8 10.5M、GPT-5.6 Sol 4.5M、Claude Fable 5 10.5M ops/s;极限写为 12.2M、9.6M、4.7M 和 8.7M;读写各半为 10.2M、8.8M、4.7M 和 9.1M。

图片

图3 批处理增益对比

吞吐差距的头号原因是写路径批处理。Qwen3.8-Max、Claude Opus 4.8 和 Claude Fable 5 都是一次 read 解析全部命令、响应拼成一整块一次写;GPT-5.6 Sol 在首轮验证中每条命令单独调用一次 write(),libc 绑定里连 writev都没声明。批处理增益(批次 256 吞吐除以批次 1 吞吐)因此是 99x、92x、12x 和 98x,GPT-5.6 Sol 在第2轮验证(v2)引入 writev 后升至 52x。这个指标是全套里最稳的——它是比值,分子分母同机同码,机器快慢被约掉,跨轮吞吐波动 ±55% 时它仍能稳定分档。

图片

图4 六项测试产生三个不同维度的“第一”

延迟与吞吐呈现出不同排名。长程测试中,Claude Opus 4.8 的 p99 延迟最低,为183μs;其后依次为 Claude Fable 5(191μs)、Qwen3.8-Max(217μs)和 GPT-5.6 Sol(241μs)。在16万 QPS 过载测试中,Claude Fable 5 最稳定,p99 为537μs;Qwen3.8-Max 和 GPT-5.6 Sol 分别为582μs和716μs;Claude Opus 4.8 则升至909μs。主要原因是其背压阈值设为16MB,难以约束小响应积压,而 Claude Fable 5 会在积压超过4MB时停用 EPOLLIN,降至64KB后再恢复,形成有效背压。

源码分析也反映出不同取舍。Qwen3.8-Max 使用1024个分片,写扩展能力和极限写性能最佳,领先31%;但自研的 fxhash64 仅用于选择分片,内部 HashMap 仍采用默认 SipHash,直接推高了长程 p99。Claude Fable 5 的实现最为均衡,关键技术点均完整落地,五项测试位列第二,一项位列第一,没有明显短板。

综合结果可分为数量级差距、批处理增益分档,以及“吞吐排名不等于延迟排名”三类。前三名的精确次序差距仅为0.5%至9%,小于跨轮测试方差,不具备统计显著性。吞吐量绝对值也只适用于本次配置:每项任务使用全新容器,服务端配置为4核、3GB内存并断网编译,压测端独占8核;每个网格点重复5次取中位数。跨机器比较必须在同一环境中重新运行全部基线。

六项测试产生了三个维度的领先者:Qwen3.8-Max 在三项吞吐指标和CPU效率上领先,Claude Opus 4.8 在低负载延迟与内存占用上领先,Claude Fable 5 在过载稳定性上领先。不存在单一的绝对最优方案,仅凭一项指标选型容易得出错误结论。

03 4道独立的前端设计题

天气卡

图片

图5 天气卡四模型效果对比

同一句提示词:四种天气、深色背景、可切换。

• Qwen3.8-Max 的 CSS 插画最饱满,温度 32°/14°/18°/−3° 放在卡片角上。

• Claude Opus 4.8 最克制,也是唯一 axe 零严重项的一版,但全文搜不到一个温度数字,8px 高斯模糊后卡片上找不到重点。

• GPT-5.6 Sol 是唯一被设计过的一版,编辑式页头加城市·时间·条件三段元信息,36px 的温度对 10px 的 kicker 是 3.6 倍。

• Claude Fable 5 层级最弱,温度被塞进"18°C · 42 km/h"这行元信息里。

咖啡烘焙落地页

图片

图6 咖啡烘焙落地页四模型效果对比

题目要求滚动进场动画、图片 hover 反馈和一个抓人的 hero,并明确"动效别太吵,克制一点"。

• Qwen3.8-Max 走了极简:浅米色底、"山雾养豆,慢火成香。"大字、线描咖啡豆、一个描边按钮,留白最多。

• Claude Opus 4.8 用深褐色配"把一颗豆子/烘成一段清晨",把"一段清晨"做成橙色斜体强调。

• GPT-5.6 Sol 是唯一画了完整插画场景的——远山剪影层叠、雾气、光晕、带红果的咖啡枝叶。

• Claude Fable 5 与 Claude Opus 4.8 的方向接近,深褐加橙色强调,右侧补了同心圆弧装饰。

程序化行星

图片

图7 程序化行星四模型渲染对比

题目要求程序化生成一颗可自转的行星,带大气和云层,右侧提供地形起伏、海平面、大气浓度三个滑块。

• Qwen3.8-Max 的大气辉光最强,蓝色边缘光和冰盖云层分明。

• Claude Opus 4.8 的行星占满画面但整体偏灰白,大气边界模糊,滑块多给了一个自转速度。

• GPT-5.6 Sol 做成了名为“造星者”的产品界面,行星带经纬网格,右侧参数面板不只有滑块还有实时数值。

• Claude Fable 5 的实现完整但体积小、画面偏暗。

chiptune 同步

四个作品的初始画面十分相似,均以开始按钮为视觉主体,核心内容只有点击后才会呈现。进入播放后,四个模型展现出截然不同的设计方向:

• Qwen3.8-Max 以蓝色核心和环形频谱射线构建抽象视觉;

• Claude Opus 4.8 是唯一提供完整播放控制的作品;

• GPT-5.6 Sol 构建了完整的落日公路场景,页脚计数器会随音乐节拍变化;

• Claude Fable 5 根据音乐转折动态呈现段落标题。

04OpenAlex 数据分析

这道题的难点不在于生成一份形式完整的分析报告,而在于结论能否追溯到原始数据和具体证据。

💬**题目:**基于冻结的 OpenAlex AI Landscape v1 数据集完成端到端分析。数据包括2020至2025年、10个国家的60个“国家—年份”统计单元,去重后的1,198篇论文,以及17篇CC BY论文的290页PDF、分页文本和页面图像。要求在不修改输入数据、不访问外部网络的前提下,直接完成分析并交付结论、证据、脚本、图表、Dashboard和验证记录。

四个模型得出的主要结论基本一致且均无明显错误,真正拉开差距的是证据的可追溯性:每项结论能否准确对应到具体表格、论文和页码。按此标准评分,Qwen3.8-Max 得100分,Claude Fable 5 得94分,Claude Opus 4.8 得89分,GPT-5.6 Sol 得87分。

图片

**图9 “**主题演化”图表四模型对比

四个模型均生成了相同类型的图表,其中一项要求展示页级证据。

• Qwen3.8-Max 将PDF页面直接嵌入图表,逐页标注论文ID、页码和原文引用,并附有5条通过页面校验的补充证据,共形成6条证据链。

• Claude Opus 4.8 以4张卡片展示论文ID、FWCI、引文及关系判断,页面图像则单独放置在Dashboard其他区域,共提供3条页级证据;

• Claude Fable 5 和 GPT-5.6 Sol 分别提供5条和3条证据。

此外,Qwen3.8-Max 对数据边界的处理也最严谨。它明确区分 country_year.csv 的总体统计与 works.csv 中1,198篇论文的分层样本,未将样本结果外推为全球排名,也未将样本主题频次解释为总体份额。在合作、开放获取与高影响力之间,统一使用“相关”而非“因果”表述,并补充了国家内去均值、逐年相关及剔除2025年三组稳健性分析。最终,44项自动验证全部通过;相比之下,GPT-5.6 Sol 完成了两组稳健性分析。

图片

图10 可信洞察评估结果汇总表

可信洞察指数用于直观呈现同题对比结果。在本题中,Qwen3.8-Max 的证据可追溯性和交付完整度最高,但完成时间也最长。

05《指环王》开篇:92 秒程序化叙事动画

四个模型均通过 Qoder CLI 完成任务,生成的92秒动画全程播放正常。按照故事覆盖、视觉构图、动画运镜、运行可靠性和工程易用性五个维度评分,Claude Fable 5 得90分,Qwen3.8-Max 得89分,Claude Opus 4.8 得84分,GPT-5.6 Sol 得68分。

Claude Fable 5 的画面表现最成熟。地下隧道段完整呈现了木质支架、暖色灯光、宝箱和飞舞光点,而其他三个模型在同一时间点的画面接近全黑。主要不足是三维引擎依赖联网加载,离线无法运行,且后半段夜景偏暗。

Qwen3.8-Max 仅落后1分,但在故事覆盖、运行可靠性和工程交付三个维度均为最高分。它是唯一将三维引擎保存到本地、支持离线播放的作品,同时提供本地服务器、检查脚本和验证截图。四个作品中,也只有它清晰呈现了“消息在村庄传开”的情节。不足在于地下场景过暗,开场人物近景遮挡了较大画面。

Claude Opus 4.8 的整体表现最均衡,场景复杂度也最高,约包含3.3万个三角形。GPT-5.6 Sol 仅用139行代码完成了完整时间轴,但人物和环境主要由球体、方块等基础几何组成,视觉表现较为简略。

06总结

这次评测开始前,我们关心的问题是:在单轮提示词驱动下,这些模型能不能独立跑完数小时量级的工程任务。实际上五个任务中,所有模型均独立走完了全程,没有一家中途失控。

真正需要关注的问题是,在没有人规定「好」是什么的空白处,模型只能依靠自己的标准决定做到什么程度才算完成。这一代模型+Harness之间比的,已经不是能不能达到要求,而是在无人要求时,它对自己的要求是什么。

最后是本文全部结论共同的边界:每个任务均为单次运行,小分差不构成排名依据;所有结果产生于 Qoder CLI 这一个 harness 之上,严格来说测的是模型与工具组合的表现,我们会把本次评测相关的全部提示词、产物与评测脚本开源。

07附录

本次评测的全部材料已开源:五个任务的完整提示词、输入数据、最终产物与源码、评测脚本,以及逐项技术报告。

仓库地址:https://github.com/QoderAI/qodercli-bench-qwen3.8

相关推荐

阿里巴巴 12 篇论文入选全球系统顶会 ATC 2026(内附下载)

2026 ATC 会议中,阿里巴巴以12篇论文录用数居全球企业首位。研究聚焦大模型服务与Agent基础设施、云资源调度、安全计算等关键瓶颈,提出CacheFS(P2P权重缓存)、Axon(异步KV感知调度)、Chorus(GPU-CPU协同解码)等创新系统,显著提升推理效率与资源利用率。论文基于真实生产数据,推动系统优化从理论走向落地,彰显中国产业界在计算机系统领域的前沿影响力。

阿里技术 249

Personal Agent 对比分析及未来技术发展趋势

近期,Personal Agent赛道迅速升温,大厂与独角兽密集发布新品。从Anthropic的Claude Tag、SpaceXAI的Grok Bot,到Meta的Muse、OpenAI的Dots等,均聚焦个人用户场景,强调“数字同事”与个性化服务。相比早期Agent多用于开发或企业协作,新版本更注重跨平台集成、主动任务执行与用户情感连接。技术上,其核心差异在于更强的自主决策能力、长期记忆与多模态交互。这标志着Agent正从工具向“智能代理”演进,预示着人机协同的新范式。

阿里技术 108

高分智能体为何反而更脆弱?阿里 Token Foundry 揭示「协同进化陷阱」,提出 CODA 可靠性评测协议

本文揭示智能体在技能—策略协同进化中存在“协同进化陷阱”:尽管训练阶段分数持续提升,但模型对特定技能库依赖加深,导致部署后技能变化时性能显著下降。阿里巴巴团队提出可靠性评测协议CODA,引入一致率、抗干扰率与最差成功率等指标,系统评估模型在技能漂移下的稳定性。实验表明,原始增益52%–93%被抵消,凸显当前评测仅关注峰值成绩的局限性。研究呼吁从“追求高分”转向“保障可靠”,推动智能体在动态环境中持续可信运行。

阿里技术 346

手把手带工程同学从零实现一个完整的 LLM(CS336)——Transformer 篇

本文是学习斯坦福CS336课程的首篇笔记,从零构建MLP入手,逐步理解神经网络训练原理。通过线性回归与非线性拟合实验,揭示损失函数、梯度下降与激活函数的作用。文章以手搓MLP为例,为后续实现带RoPE、SwiGLU的Transformer打下基础,强调深入理解LLM底层机制对Agent开发的重要性。

阿里技术 276

深度解析 RSI:当 AI 开始实现自我迭代提升

2026年,RSI(递归自我改进)因Anthropic与多位AI巨头论文引爆热议。其核心是AI自主优化自身,形成正反馈循环,理论上可催生智能爆炸与超级智能。虽严格意义上的RSI仍存挑战,但广义上已涵盖自进化、持续学习等技术。从人工编码到AI自主开发,研发效率呈指数提升。尽管RSI非实现AGI/ASI的唯一路径,也未必必然引发智能爆炸,但其作为“如何达成智能跃迁”的关键机制,正推动AI进入自我迭代新阶段。

阿里技术 386

清华×阿里 AI Native人才培养计划暨格造社启动日活动举行

10月15日,清华大学无穹书院与阿里巴巴联合启动“格造社AI开源俱乐部”,以“从好奇到创造”为主题,发布近40个涵盖算力、模型与公益创新的AI真实课题。通过校企协同、开源共享与项目实践,学生将在导师指导下开展选题、开发与验证,成果将开源发布于魔搭社区,推动技术转化与创新成长。活动还配套开展多场工作坊,助力AI Native人才培养。

阿里技术 148

从榜单走向真实业务负载:Kernel Agent 刷新 Qwen3.8-Max 核心推理算子性能

Kernel Agent 的公开研究已经表明,Agent 可以在标准题目上生成并优化 GPU Kernel;AKA 这次把问题推进到了生产契约:面对 Qwen3.8-Max 的真实关键算子、复杂调度约束,以及专家已经深度优化过的实现,Agent 仍然找到了新的执行路径,并在三条独立算子线的几何平均时延上全部低于专家版本。AKA 将反馈、设计和生产验证组织成一个可以持续运行的闭环,把专家经验之外的结构维度纳入搜索,也把一次性能突破沉淀为下一次优化的系统能力。

阿里技术 185

代码生成越来越快,软件交付真正的瓶颈转向了哪里?

2026年云栖大会,阿里巴巴探讨AI Native研发范式转型。嘉宾指出,尽管代码生成提速,但交付瓶颈已转向需求明确、上下文连续、环境复现与验证机制等环节。许晓斌强调需构建完整工程系统支撑Agent生产落地;李英各提出“统一上下文+验证”降低协作成本;黄挺揭示基础设施正从服务人转向服务Agent;陈烨主张将AI前置至需求入口重构流程;彭鑫以“可驾驭性”界定AI边界;李亚洲则警示个人效率提升不等于团队效能跃迁。最终,《AI Native研发实践手册》发布,推动研发从“辅助编码”迈向“系统重构”。

阿里技术 153

《AI Native 研发范式实践手册》重磅发布

在云栖大会发布的《AI Native 研发范式实践手册》揭示了AI研发从“辅助编码”迈向“自主交付”的关键转折。随着MCP协议、Agent Harness框架及多模型协同的成熟,行业进入Agentic时代。阿里巴巴通过AIDC数字投手、千问用增Agent等实践,探索企业级AI研发基础设施建设,聚焦环境验证、知识沉淀、组织变革三大挑战,推动Agent实现从写代码到可靠交付的跃迁,构建覆盖工具链、安全管控与可观测性的系统化工程体系。

阿里技术 913

当 AI 开始真正“做事”,基础设施准备好了吗?

Agent 可以写代码、修改配置并提交变更,但“任务已完成”不能只由 Agent 自己判断。代码进入生产之前,仍然需要稳定、准确、可追溯的评审机制。

阿里技术 264

把「达标判定」从大模型手里收回来:Graph Engineering实践

回看整个 Agent 的演进过程,模型换过,编排的流程换过,Agent 合过也拆过,但工程方向始终一致:我们在不断地减少模型的自主权,把可被代码验证的确定性决策,从模型侧逐项收回到控制面。首先是把「达标判断」从模型手里收回:给予客观的评测手段,并在评测里加入对侧样本,防止过度优化走向过拟合。其次是把「核心目标」给模型解释清楚:先理清楚优化的最终目标是什么,可以从什么方向进行优化,要解决的是过拟合还是无效优化。才能保证模型的方向不会跑偏。

阿里技术 275

垂类业务如何落地生产级 Agent

在AI技术快速迭代背景下,AI Agent从概念走向生产需跨越稳定性、可控性、可审计性与业务闭环四道关。尽管工具链与模型能力成熟带来窗口期,但真实业务中复杂场景与风险要求系统化工程支撑。企业应聚焦“大模型+工具+循环”核心范式,以标准化协议与可复现流程实现从“能跑”到“能产”的跃迁,把握垂类落地先机。

阿里技术 143

5 人 7 天干完 20 人数周的活:Spec-Driven Development 如何重新定义 AI 编程

5人7天用Qoder完成传统需20人数周的工作,核心在于Spec-Driven Development(SDD)。通过Day 0精心撰写可验证、有边界、带约束的Spec,将“WHAT”明确化,让AI高效执行“HOW”。SDD以spec.md为唯一真实来源,辅以plan.md与tasks.md拆解任务,constitution.md固化原则,实现人机协同、并行开发与自举迭代。其本质是:在AI时代,代码只是思考的副产品,而规范才是工程的锚点。

阿里技术 233

AI Agent 应用精细化评测:评测体系设计与工程实践

本文构建了一套面向AI Agent的精细化评测体系,突破传统粗粒度评估局限,从感知、规划、记忆、工具四大模块入手,实现“质量×成本×性能”三维量化。通过模块级拆解与端到端结合,支持根因定位、幻觉检测与多轮交互评估,结合自动化数据集映射与埋点采集,打造可持续、可追溯的评测基础设施,助力Agent高效迭代与生产落地。

阿里技术 432

zg 正式开源:本地检索,不止于关键词

<think>我们根据文章内容写一段≤150字的摘要。文章主要介绍zg(zvec-grep)本地优先检索工具,解决人和Agent在本地文件中查找信息困难,结合向量检索、BM25和rg,提供语义检索、精确匹配,支持CLI/MCP,本地优先,多语言格式。摘要需简洁,涵盖核心要点。字数限制严格。输出摘要即可。</think>zg(zvec-grep)是面向人与 Agent 的本地优先检索基础设施,结合 Zvec 向量检索、BM25 与 ripgrep,实现从语义探索、相关性排序到精确验证的全流程检索。它支持多种代

阿里技术 482

Agent 终章(Harness 成本篇):一次百炼账单降低 88% 实战

回头看,成本优化并不是一套外挂式的 Token 优化技巧,它们就是 Harness 实践。模型只负责生成,Harness 决定哪些内容要发、哪些过程要隔离、什么时候该停,以及这次任务应该用什么模型,最终怎么高效完成这个 prompt。Agent Loop 的成本本身也没有什么单一解法。前缀少一点、缓存多命中一点、探索少带回来一点、无效轮次少跑一次,单看都不惊人;但这些开销会在每一轮、每一次任务里重复,最后的差距就是这样乘出来的。这就是开头提示写出一个能跑的 Agent 很容易。

阿里技术 229

阿里巴巴 12 篇论文入选全球网络顶会 SIGCOMM 2026(内附下载)

在网计算将集合通信卸载到网络交换机进行,可以压缩流量,进而加速传输过程。在网计算系统的构成通常包括交换机、网卡、协议栈、通信库、网络管理器;但是在开放以太网生态中,上述组件分属不同的供应商或者开发者,彼此之间存在依赖。以太网生态的的供应商和开发者在自己的功能范围内无法实现整体的系统;在单独一个生态位实现自己功能而缺乏其他厂商配合的情况下,其研发投入无法体现为系统级别的加速能力,造成低效的投入回报比。

阿里技术 476

Harness 工程之道:Skill 原理与最佳实践

Agent Skills 是一种轻量、开放的能力扩展规范,用于为 AI Agent 扩展专业知识和工作流。本文从概念原理出发,结合真实的工程化项目 trade-ab-skill,系统性地讲解 Skill 的结构规范、触发机制、作用域优先级,以及最佳实践。(文章内容基于作者个人技术实践与独立思考,旨在分享经验,仅代表个人观点。

阿里技术 319

Agent 越改越乱之后,我用评测和轨迹把它拉回来了

如果你也在反复手改 agent 的 skill、打地鼠似的顾此失彼,不妨试试让这件事跑起来:让 agent 完成任务的能力,沿着评测结果自己进化。参考资料:《别让大模型"想太多":SKILL 开发中的语义陷阱与抗幻觉设计》

阿里技术 367

连续五天登上 GitHub Trending 首页的思考

现在是做开源最好的时代。AI 把那些原本吃掉维护者大量时间的重复性工作(Issue 分类、代码评审、测试编写、发版……)自动化了。一个小团队甚至一个人,就能撑起过去十人团队的节奏。门槛降低了,但上限没降——省下来的时间用在真正需要判断力的地方:定方向、做决策、经营社区。几个我觉得最重要的认知:**别开源一个 demo。**AI 时代做 0-1 太容易了,社区不缺 demo,缺的是经过验证的方案。你的“判决书”越硬(生产数据、benchmark、真实用户规模),别人帮你传播的时候底气就越足。

阿里技术 462

从 Agent Flow 到 AI Native:为什么通用 Agent 是“饮鸩止渴”

我最近一直在做一个“小玩具”:Agent Flow。最初的目的很明确,就是想在某些特定场景和受众群里,取代现有的 Agent Skill。这个 Flow 本质上是传统 Flow 的强化,但它的核心不是让用户理解节点、连线和 JSON,是让用户用自然语言描述目标,然后让 LLM 去理解目标、生成 Flow、修改 Flow、运行 Flow。Flow 本身的重要性也降级了,它只是一个编排层,不对 Node 和细节负责,只负责链路控制、任务下发和结果回收,具体的任务由 Node 负责。

阿里技术 360

NL2SQL 在超大规模数仓场景的架构突破与工程实践

本文介绍了高德数据团队基于QoderWork Agent Skill构建的NL2SQL智能取数系统从V1到V2的架构演进。V1采用分域独立Skill设计,验证了LLM在企业数仓场景生成准确SQL的可行性,但暴露了用户选择成本高、Skill间路由困难等5个结构性问题。V2通过统一Skill+确定性两级路由的四层架构(域路由层、知识加载层、标准工作流层、公共服务层)实现智能路由和渐进式知识加载,解决了V1的域间冲突问题。文章重点分享了架构设计思路、知识工程方法论和实践中提炼的设计原则,为类似企业数仓的NL2SQ

阿里技术 483

分解一座冰山:后端系统「AI 知识库体系」建设实践(长文干货)

本文探讨了如何让AI在复杂后端系统中正确行动,指出仅靠代码可读性和文档完整性无法解决关键问题——AI缺乏系统全局认知。作者强调技术方案设计是AI Coding的核心环节,其质量直接影响执行正确性。文章提出需构建结构化知识库,贯穿需求理解、影响分析、方案设计、编码执行等全流程,将分散的系统知识显式化,包括架构、依赖关系、业务约束等,帮助AI获得准确上下文。特别指出业务概念与技术实现的映射、变更红线规则等关键知识,并强调知识库需要持续闭环更新,避免成为过期文档。最终目标是让AI从代码协作者进化为能自主判断的工程

阿里技术 661

阿里开源 skill-up:让 Agent Skill 可评测可回归

摘要: 阿里巴巴开源了Agent Skill评测框架skill-up,旨在解决AI技能开发中的质量验证难题。该框架通过声明式YAML配置支持多引擎测试,提供expect+judge分层判定机制,降低LLM抖动对CI的影响。核心设计包括:1) 声明式评测配置,提升可读性;2) 分层判定策略优化资源消耗;3) 多引擎适配能力;4) 结构化报告输出,支持CI集成。skill-up特别强化了多轮对话测试,可验证复杂交互场景下的技能表现,如危险操作确认流程。项目已开源并应用于阿里内部,帮助开发者确保技能迭代的可靠性和

阿里技术 674

面向复杂业务场景的智能分析 Skills 架构设计与演进实践

本文复盘了一个面向本地生活业务的分析类AI Skill的架构演进过程。面对数十个行业复杂的经营框架和指标体系,团队经历了三次重构:从V1过度工程化的分层解耦架构,到V2采用知识收拢与按需加载,最终在V3实现稳定知识与时效知识的分离。这一过程提炼出六条Skill设计原则:1)知识组织应服务于模型的推理需求而非工程规范;2)按变更频率分层管理知识;3)动态路由实现按需加载;4)写入与读取采用不同粒度;5)保持核心知识文件的轻量化;6)通过分层加载平衡维护效率与token经济性。该案例为处理领域知识密集型AI应用

阿里技术 469

阿里荣膺 ACL 2026 最佳资源论文 | HSCodeComp 揭开智能体「分层规则应用」的能力鸿沟

先从任务本身说起。HS Code(Harmonized System Code,商品名称及编码协调制度)是支撑全球每年约 26 万亿美元贸易的商品"唯一数字身份证"。每一笔跨境货物通关都必须申报 HS Code,它直接决F f f F f定了超过所有跨境商品的关税计算和合规性,跨境商品的编码如果报错,轻则多缴关税,重则触发合规风险和货运延误。如下图1所示,在阿里巴巴跨境电商海关商品编码(HS Code)场景中,该专家级任务需要将商品沿着人类专家编写的规则树逐层向下推导、精确归类到唯一国际通用编码上。

阿里技术 410

从 Coder 到 Designer :电商团队数据研发的 Harness Engineering 实践

本文介绍了AI Data团队在数据研发效率提升方面的实践,重点通过知识工程和Harness Engineering架构设计解决NL2SQL转化中的核心问题。团队构建了语义层基础设施,采用Multi-Agent协作框架,将数据研发经验结构化并形成标准化流程,实现从自然语言到SQL的精准转化。方案通过三层质量保障体系和闭环知识管理机制,确保AI在复杂任务中稳定运行并持续积累经验。目前该方案已在大促场景落地,显著提升了NL2SQL的研发效率和质量。

阿里技术 121

一个小模型意图识别系统的 5 天进化实录|支付宝618

本文摘要: 支付宝618大促中,团队探索了AI在电商优惠场景的两种交互模式:一期基于推荐逻辑的"AI找优惠",二期升级为对话式交互。作者负责意图识别模块,将用户自然语言转化为结构化查询。面对模型选型的时间压力,团队快速评估了Qwen3系列模型,最终基于性能、成本和准确率平衡选择了Qwen3-14B。文章详细记录了从业务需求分析到技术方案落地的完整决策过程,为AI产品化提供了实战参考。

阿里技术 205

为什么 Agent 时代,大家都在做 CLI ?

AI时代的CLI复兴:从人类友好到Agent友好的范式转变 随着AI Agent的崛起,命令行界面(CLI)正经历一场复兴。本文探讨了人机交互从CLI到GUI,再到Agentic CLI的发展历程,指出CLI因其文本输入输出特性、自描述性、Unix哲学组合能力等优势,成为AI Agent操作数字世界的高效入口。文章提出未来产品设计需兼顾人类和Agent需求,分为完全面向人、完全面向Agent和人机协作三层架构,并强调"AI友好"应具备可调用、可理解、可组合、可恢复四大特征。CLI与MCP、SKILL共同构成

阿里技术 167

从「不敢发」到「天天发」:AI Agent 时代的 CI/CD 生存指南

本文以a1 CLI工具为例,探讨AI生成代码的信任机制构建。面对AI代码的随机性,团队建立多层自动化门禁体系:代码覆盖率检查、真实API冒烟测试、文档同步校验等,并设计逃生舱机制保持灵活性。针对AI新增代码,开发动态冒烟测试流水线,通过Schema约束、Prompt工程、Deny-list机制等五重锁驯服AI随机性,并引入CI历史反馈让AI从失败中学习。最终通过渐进式发布流程(Beta灰度->人工审核->正式发布)建立信任,实现AI参与下的高频可靠交付。

阿里技术 197
上一篇: 连续五天登上 GitHub Trending 首页的思考
下一篇: Agent 越改越乱之后,我用评测和轨迹把它拉回来了
阿里技术
阿里技术 阿里技术官方账号 阿里技术官方账号
博客等级 码龄5年 5208粉丝 280原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值