跳到正文
  1. 掘金78

    arXiv 综述盘点 9B–20B 开源模型量化部署实测:INT4 小 batch 提速约 2 倍,大 batch 增益归零

    三位独立研究者汇总截至 2026 年 10 月 5 日可核实的 9B–20B 开源模型在 vLLM/SGLang 上的量化公开实测,发现所有计时都符合内存带宽与计算的 roofline 规则:batch 1 时 INT4 提速 1.35–2.12 倍,batch 256 时 W4A16 仅 1.02 倍,FP8 仍有 1.68 倍。

    借鉴点

    能拿走的是 roofline 判断法加 7 条量化报告清单,用来定小 batch 选 W4A16、大 batch 选 FP8 的配方;代价是证据来自不同引擎版本,只能组内比较。

  2. IT之家71

    蚂蚁百灵发布原生多模态模型 Ling-3.2-flash,560B 总参数、1M 上下文,前两周免费

    蚂蚁百灵官方团队发布原生多模态模型 Ling-3.2-flash,560B 总参数、25B 激活参数、1M 上下文窗口,支持图像、文本与视频输入。

    借鉴点

    官方只给了基准分数和定价,没给训练配方或部署细节;能拿走的是 560B 总参数、25B 激活的 MoE 配比和 1M 上下文,以及兼容 OpenAI 与 Anthropic 协议的接入方式,可用来评估替换现有视觉理解与长程 Agent 调用链的成本。

  3. Hacker News · AI 讨论80

    对照实验:Codex 编码智能体团队为何不如单 agent

    一项对照实验用 Codex CLI 0.157 和 gpt-5.6-luna 在 shopizer 上跑六个功能任务,planner-coder-reviewer 团队只通过 25.7% 的隐藏验收测试,单 agent 通过 56.8% 且花费更低。

    借鉴点

    能拿走的是对照实验设计本身,同一批任务下把单 agent 与 planner-coder-reviewer 团队按成本对齐比较,并给出把 TASK.md 放进仓库让每个 agent 自读的修法;代价是只测了一个模型、一个 Java 代码库和六个功能,结论外推有限。

  1. 掘金74

    人大、复旦、上交发布 ToolSpace,用 804 个真实工具环境训练 Agent,Qwen3.6-35B 均分从 23.0 升至 41.0

    人大、复旦、上交联合团队在 arXiv 发布 ToolSpace,先从 20 万条真实执行轨迹中用确定性规则挖出工具间的数据、状态、重试三类依赖,聚成 804 个环境簇,再在图上随机游走生成任务并回放验收。

    借鉴点

    可借鉴的是先挖真实轨迹里的工具依赖再按需造环境,无状态环境直接缓存回放,省掉一半合成文件;前提是手里有真实执行轨迹,且冷门编排进不了图。

  2. AWS Machine Learning Blog58

    如何在 Amazon Bedrock AgentCore Evaluations 中接入 Jev 与 Strands Decider 决策模型

    AWS 官方博客演示如何通过 code-based evaluator 把 Jev 和 Strands Decider 2B 两个决策模型接入 Amazon Bedrock AgentCore Evaluations,把 OpenTelemetry span 转成决策模型请求,再把概率分布映射回评估结果。

    借鉴点

    能把决策模型包进 Lambda 注册成 code-based evaluator,用校准概率做阈值筛选,再让内置 LLM 评估器只跑低分轮次;代价是要自备标注样本验证阈值,Jev 还需 TypeSafe API key。

  3. Hacker News · AI 讨论75

    Cleric 用多智能体架构把 agent 评测成本降低 100 倍

    Cleric 把原来基于 Claude Agent SDK 的单个调查 agent 拆成约 40 个按角色分工的松耦合 agent,由中心 investigator 编排,使单次评测成本从 0.54 美元降到 0.0052 美元、耗时从 137 秒降到 27 秒。

    借鉴点

    把单体调查 agent 拆成约 40 个按角色分工的松耦合 agent,每个角色独立选模型和 harness,eval 从端到端全流程改成单角色聚焦测试,单次成本从 0.54 美元降到 0.0052 美元;代价是编排、追踪、成本统计都要重做,agent 之间靠自然语言对话缺少契约约束。

  1. Together AI Blog58

    Together AI 发布 Together Compiler,用智能体持续编译推理负载

    Together AI 发布 Together Compiler(TKCC),用高吞吐智能体循环为推理引擎持续生成优化,在不到 24 小时内对 Kimi K3、GLM 5.3、MiniMax M3.1-Flash、DeepSeek v4.1-Flash 等前沿开源模型实现最高 2.6x 的 TPS 提升。

    借鉴点

    可借鉴持久化引擎加热重载替代反复启停、快慢双层引擎平衡吞吐与保真、成本模型选并行策略;前提是自建推理服务并有稳定流量可测。

  2. Hacker News · AI 讨论71

    scan-to-vector 开源 Agent Skill:把扫描页重建成可搜索矢量 PDF

    scan-to-vector 是一个面向 Claude Code、Codex 等读取 SKILL.md 客户端的 Agent Skill,把扫描的书页、手册、表格和图表重建成文字可搜索、图表为矢量路径的 PDF,并逐页与扫描件叠图核对。

    借鉴点

    能拿走一套可复用的 Agent Skill 结构,用 draft.py 一次成稿、fixes.json 改错、叠图比对加页面账本做校验,落到知识沉淀和文档重建线;代价是每页要跑几分钟并消耗模型 token,审计通过也不等于内容正确。

  3. Hacker News · AI 讨论71

    Google Cloud 团队总结评估 Agent 技能的五条规则,避免技能撑爆上下文窗口

    Google Cloud 团队公开其评估 Agent 技能(SKILL.md)的五条工程规则,用于判断一个技能是否值得占用上下文 token。

    借鉴点

    五条规则可直接搬进 skill 评测流程,含 frontmatter 触发冲突检测、配对 WITH/WITHOUT 消融、评分维度正交防刷分;前提是得有容器沙箱和 CI,本地跑的数字不可信。

  1. 掘金71

    LLM 当裁判可靠吗:规则满分盲区、抽检配比与位置/长度/自我偏好三大偏差

    作者复盘自己跑的规则先行、LLM 兜底的评测流程,5 条样本里 3 条规则满分被直接放行,其中一条实际答非所问,说明规则只能验证动作做了没有、验证不了问题有没有解决。

    借鉴点

    能拿走 only_on_rule_fail 的抽检配比改法,规则满分样本抽 5%、失败样本全审,成本只涨 7.5%;落到 Agent 评测线上,前提是接受裁判分数只做同裁判同批次的相对比较。

  2. 掘金78

    AI Agent 性能评估的 4 维 15 项指标与 200 行 Python 自动化评测方案

    文章给出 AI Agent 的四维评估体系,涵盖结果交付、过程轨迹、性能成本、安全合规共 15 项指标,并附一套不到 200 行 Python 的本地自动化评测方案。

    借鉴点

    能拿走一套可跑的评测骨架,入口函数返回工具轨迹与沙盒终态,配 test_cases.json 断言和 Pass^k 门禁,代价是要先改造 Agent 接口暴露 trace,软指标还得接 DeepEval 和裁判模型。

  3. Hacker News · AI 讨论76

    如何为 AI 智能体编写 eval:从 LLM eval 的区别到七步落地

    EvalShift 的 Lukas Babaliauskas 撰文讲解智能体 eval 的写法,指出 LLM eval 只评单条回复,智能体 eval 要评整次运行的工具调用、参数、留下的状态和最终回复,否则智能体没调退款工具却回复已退款也会被判通过。

    借鉴点

    七步流程可直接照搬,核心是成功标准写成世界状态而非回复文本,代码判分优先、LLM judge 只判文风,代价是每个任务要跑 3 到 5 次并人工标注 30 到 50 条校准 judge。

  1. 掘金80

    用 Python 搭一套提示词离线评测体系:从评测集、指标到版本退化判定

    作者以英语作文批改智能体为例,用 Python 搭了一套离线评测流水线,把改提示词后的效果从凭感觉变成看分数。体系包含带反例的 16 条 JSONL 评测集、exact_match 与 set_f1 等纯函数指标、四档 rubric 的 LLM as judge 裁判、markdown 报告和按核心指标阈值判退化的版本对比,42 个测试用例离线全绿。

    借鉴点

    能拿走一套离线评测流水线,含反例评测集、纯函数指标、四档 rubric 裁判和按标签的退化判定,用来替换改提示词后随手试几个例子的做法;代价是要先人工标注评测集,且裁判调用会多一层开销。

  2. 掘金71

    Google 与港大提出 VeriCUA,让验证器主动取证判定计算机操作智能体是否真完成任务

    Google 和香港大学的论文 VeriCUA 把计算机操作智能体的任务完成判定从一次模型调用打分,改成先勘察环境再定验收标准、从 GUI 和代码两条通道取证、按证据可信度仲裁的验证流程。

    借鉴点

    可搬走证据分级(物证/证词)与先勘察再定标准两条规则,用于 agent 轨迹筛选和 RL 奖励判定;代价是验证要多花推理预算,且依赖对机器状态的只读特权访问。

  1. Hacker News · 首页71

    Memdoor 用 5 个 Qwen3.8-27B 智能体在 LiveCodeBench Hard 上跑出 9.8 分

    作者 guregodevo 在 Memdoor 上复现 GVS5H 方法,用 5 个 Qwen3.8-27B 智能体加一个修复工,在 LiveCodeBench Hard 前 10 题各跑 5 次,平均 9.8/10,高于原作者 harness 的 9.6 和 Fable 5 单模型的 8.0。

    借鉴点

    能拿走一套五角色加修复工的多智能体工作流,靠磁盘文件传递上下文、用 shell 脚本判分,可换掉单 agent 串行解题;代价是每题中位 40 分钟、约 $0.39,且需自备模型与测试样例。

  1. 掘金71

    一次 function-calling 失败归因:模型不调用工具的两个根因

    作者在一次企业内部试点中复盘 6 个工具、9 条用例的 function-calling 评测,基线选择准确率 78%,两条失败用例都是模型完全不调用工具。

    借鉴点

    能拿走三件事:required 参数来源要写进描述、相邻工具要写互斥边界、负例占比至少 20%,用 mf lint 和 mf coverage 静态查;代价是得先有一套单变量对照的评测套件。

  1. 掘金78

    本地多模态 OCR 实测对比:qwen3.5-9b、Apple Vision 与 gemma-4-e4b 字错率与吞吐

    作者用《剑桥中国秦汉史》3 页 300 DPI 样本实测三种 OCR 方案,本地 qwen3.5-9b 字错率 0.5% 质量最高,Apple Vision 3.2% 且单页 12 秒快 15 倍,gemma-4-e4b 达 40.1% 中文不可用。

    借鉴点

    能拿走金丝雀页测模型是否真看图、关思考加封顶 token 防空输出,以及 Vision 跑量加 qwen 抽检的二校架构,代价是 qwen 单页 80 秒且独占槽位。

  1. Hacker News · AI 讨论71

    Benchouse 用分层上下文把 nao 分析智能体准确率从 49.6% 提到 96.5%

    Benchouse 用开源分析智能体 nao 在 90 道题、59 张 marts 表的固定评测集上做实验,把准确率从 Sonnet 5 裸 schema 的 49.6% 提升到 Opus 5.5 加完整上下文的 96.5%,完整度 100%。

    借鉴点

    能拿走分层加上下文的做法,从裸 schema 到 nao sync、全量文档、write-context-rules 技能、业务定义与回答规则逐层叠加,把分析智能体准确率从 49.6% 推到 96.5%,代价是每问成本从 $0.23 升到 $0.27,且各层改动合并测试无法拆分单项增益。

  1. AWS Machine Learning Blog58

    Property Finder 如何修正 Amazon Bedrock 上的评测偏差并选出更优模型

    Property Finder 发现其评测标签有 96.8% 直接沿用现有 VLM 的预测而非人工核验,导致任何替代模型在比较中天然吃亏。

    借鉴点

    可拿走一套做法,先人工重标几百张图做无偏基准,再用 Micro F1 加错误分析迭代提示词,最后用 MIPROv2 自动优化;能落到本地模型部署的选型评测线,代价是要有领域专家标注,356 张只够测中等差异。

  2. Databricks58

    Databricks 用 ai_extract 与 MLflow Prompt Registry 建立文档抽取评测闭环

    Databricks 介绍一套文档抽取的可重复改进流程,用 ai_extract 的 schema 描述承载字段规则、全局指令承载文档级逻辑、precision mode 处理复杂表格,并用 MLflow Prompt Registry 对 prompt 和 schema 一起做版本与别名管理。

    借鉴点

    把字段规则写进 schema、文档级逻辑放全局指令、结构难题开 precision mode,再用 MLflow Prompt Registry 的别名做灰度与回滚,前提是先攒出几百份人工审核过的固定评测集,否则改动好坏分不清。