OpenAI 公布两项基准结果：在自有的 COBOL 迁移测试中，GPT-6.1 Sol 在低推理强度下达到 86.6% 准确率，高于 GPT-5.6 Sol 的 5.4%，成本降低 39%，高推理强度下达到 97.9%。另一项 MultiLangBench 测试模型用 20 种语言从零构建兼容 SQLite 的数据库引擎，GPT-6 Astra 平均通过率 87.4%，GPT-5.6 Sol 为 26.8%，低成本版本 GPT-6 Luna 为 40.3%。OpenAI 已在 GitHub 发布 MultiLangBench 的设置与测试套件，但未公开 COBOL 迁移评测的测试用例，外部无法独立核查该结果。
#评测/基准#编码#OpenAI
#评测/基准#推理#DeepSeek
Anthropic 应用 AI 团队在多个企业部署对比中发现，带技能（skills）的单一智能体在质量上常优于子智能体架构，且单任务成本和延迟更低，并给出把子智能体折叠进主循环的迁移方法。文章指出子智能体仍适用于上下文膨胀导致性能下降、需要并行处理独立任务、或工具选择与指令冲突的场景，并建议先把子智能体作为工具调用，再逐个转成技能和 MCP 工具，用端到端评估对比前后表现。文中提到 Claude Code 面向更先进模型的系统提示词缩减了超过 80%，并配套提供 build-eval、prompt-audit、hillclimb、cost-optimize 等 Claude API 技能。
#教程/实践#Agent#MCP/工具调用
CNET 编辑 James Bricknell 用 Gemini 4 Argon 通过对话生成一个可调整护甲尺寸的网页应用，经过约 10 次迭代到 KeriForge 8.2，再导出 STL 并用 TPU 75A 打印，全程约 18 小时，其中打印 7 小时。作者称 Gemini 4 Argon 完成复杂任务的速度明显快于他常用的 Gemini 3.5 Flash-Lite，并能理解他想要离线使用网页应用而非开发 iPad 应用的意图。最终打印件尺寸与他的前臂和手腕吻合，表面缺陷来自 TPU 材料过软和模型打印过高，而非模型本身。
#教程/实践#编码#Google
作者用智能体修 bug、数据库查询和 400 条工单分类三项测试对比 DeepSeek V4.1-Flash-1017 与 Claude Haiku 5.5，DeepSeek 在修 bug 和工单分类上准确率更高，数据库查询两者均为 20/20。三项测试总成本 DeepSeek 为 $0.07、Haiku 为 $0.30，差距主要来自长提示词让 Haiku 进入更高价位。作者说明每项只跑一次，结果不足以证明普遍的准确率或速度优势。
#评测/基准#模型发布#推理
The New Stack 发文讨论生产环境 AI 智能体的归属问题，指出团队常把精力放在提示词、检索、工具和模型选择上，却忽略了谁对该系统负责。文章给出九个可落地的步骤，包括为智能体定义负责人和升级通道、用工具白名单默认拒绝未授权操作、设置执行步数与工具调用预算、记录模型调用日志、区分失败与升级、高风险操作需人工审批、提供健康检查接口、安全控制失效时默认阻断，以及制定凌晨故障时的降级运行手册。
#教程/实践#Agent#部署/工程
LLM Prompt Caching Versus Semantic Caching Caching LLM costs is two different problems: reuse the prefix with prompt caching, reuse the answer with semantic caching, and never confuse one for the other https://t.co/vuFGgKiIvJ
#教程/实践#RAG#部署/工程
there's something really cool about asking your agent to draw a statechart (hypothetical example in this image), then using the /create-formal-verification-skill you made with pstack to find bugs through something like TLA+. you can both understand your code better and how the user flow should work, and fix issues users would otherwise see
#教程/实践#Agent#开源生态
Google 开发者博客公开了一套 Agent 评测路径，从关键用户旅程、模拟用户和人工 Trace 审阅，逐步走到自动评测与合并门禁。文章指出 Agent 可能陷入循环、重复调用工具并消耗大量 Token，最终仍给出通顺答案，因此只断言最终输出不足以证明可上线。文中把该路径拆成 Day 0 人工读 10 至 20 条高风险链路 Trace、Day 1 分单元测试与确定性指标及 LLM Judge 和集成测试四层、Day 2 设总体基线与核心风险项零回归两条门禁，并给出基于 pytest 的最小断言示例。
#教程/实践#Agent#评测/基准
Playwright CLI 通过 snapshot 获取页面可访问性树并把交互元素标记为可引用节点，再用 find 做文本或正则的局部检索，最后用元素引用执行 fill、click 等操作。文章以登录场景对比 CSS 选择器、语义定位器和 CLI 快照检索三种方式，指出 find 是快照文本或正则匹配而非向量检索。作者还提醒元素引用编号会随页面变化失效，正式测试仍需可维护的定位器并断言验证结果。
#教程/实践#Agent#编码
Aerial 是一款无需 root 就能替换国产智能电视默认桌面的工具，它通过“桌面守护”覆盖被唤醒的原桌面，并利用安卓通知监听在待机清理后 0.5 秒内复活，主屏广告因此消失，但开机广告仍无法拦截。部署时把电视和电脑连到同一 WiFi、打开 ADB 并查到电视 IP，再在 Aerial 官网复制提示词交给豆包、WorkBuddy 等 Agent 执行，用户只需在电视弹窗中允许 USB 调试，整个流程约五分钟。该工具从代码、APK 到官网均由 AI Vibe Coding 产出，GitHub 上线一天获 200 多个 star，随后补充了图标隐藏、添加信号输入源到主页等功能并适配多款电视。
#教程/实践#Agent#开源生态
文章沿告警生命周期把 AIOps 拆成检测、收敛、诊断、处置四层，逐层讨论工程实现方式与已知边界。检测层用动态基线替代固定阈值，收敛层以去重、关联聚合、防抖、时间屏蔽和依赖屏蔽五类机制降噪，拓扑数据完备时整体降噪达到 70% 以上是常见水平。诊断层强调统一建模与多智能体协作，输出的是根因候选加证据链而非确定性判定，证据不足时保守给出 Top-K 方向并标记缺失证据。
#教程/实践#Agent#部署/工程
Browser Use 发布 2026 年浏览器 Agent MCP 服务器盘点，把这类服务器分为驱动和委托两种模式，并逐一评测 Browser Use Cloud MCP、Browser Use 开源 MCP、Hyperbrowser MCP 和 agent-browser chat 四款。作者在 100 个 BU Bench V2.1 任务的对比评测中发现，四个驱动类工具每个任务的中位输入 token 消耗在 2.1M 到 6.7M 之间，全部计入编码 Agent 的上下文。文中还给出各服务器的安装命令、模型选择、计费方式与已知限制，并说明长任务、并行任务和结构化输出场景更适合委托模式。
#教程/实践#MCP/工具调用#Agent
卧槽兄弟们，这个真的牛逼，感觉大模型诞生至今最憋屈的七年失忆史可能要翻篇了！！ 甚至我想说个暴论，这大概是今年大模型架构演进里最性感、但也最击中行业要害的一次底层突围。 刚刚开源的 MemT-1.0 第一次在 Transformer 底层焊入了一颗真正的生物级海马体， 让 AI 从聊完即忘的失忆金鱼，真正进化成了能把经验沉淀进血液里的生命体。 靠暴力堆显卡、拿几个 G 的 KV Cache 硬撑长文本的旧石器时代，今天被这个开源原生记忆大模型正式砸穿了。 他们放出的 66 页技术报告和最高 288B 的开源权重直接甩出了一组降维打击的工程账单： 把记忆变成前向计算流的原生状态后，256K 超长历史下的显存开销从 5.06 个 G 暴降到恒定的 40 兆， 直接把 KV 缓存砍掉了整整一百二十倍以上，而且首字延迟更是不管历史拉得多长，始终稳稳压在一百毫秒出头。 最先击穿传统路径的，是它彻底重构了模型的前向计算流。 以前大家为了让 AI 记住上下文，只能硬着头皮堆长文本或者外挂向量库，代价就是显存撑爆且丢失多步推理因果，它在标准网络旁并联了一套原生记忆模块，在输入进入的瞬间，擦除门、写入门和遗忘门就像生物海马体一样自动运转，不再保留所有的死文字，而是把信息实时消化成动态的内部记忆矩阵。 更绝的是它在真实智能体场景下带来的降维打击，团队把历史纠错中沉淀的一千多条代码经验，直接写入内部的原生记忆状态，完全不占用任何系统提示词的 Token 额度， 结果在标准代码测试集上，连续三次均通过的硬核指标直接提升了百分之八，稳定性甚至反超了直接塞明文提示词的做法。 这意味着经验不再是一段需要模型每次重新阅读理解的生硬规则，而是直接内化成了它的本能直觉，真是牛逼! 我觉得这才是通往真正的递归自我改进最底层的物理逻辑啊, 参数只定义了模型的出厂下限，但唯有持久内化的原生记忆，才能为智能打开复利增长的空间。 以前我们买的模型是聊完即焚的一次性计算工具，从今天起模型正在变成越用越懂业务、越用越值钱的自进化资产。 大家在做智能体或者长对话应用时，最头疼的是长上下文带来的昂贵显存和卡顿延迟，还是模型转头就忘业务规范的失忆症？ 对我来说，光是把 256K 显存压缩一百二十倍且延迟恒定这一项，就已经能让无数原本算不过账的长程业务直接原地复活了hh~
#现象/趋势#Agent#视频
#评测/基准#搜索#DeepSeek
CS 329Z: Engineering AI Agents Stanford / Fall 2026 @stanfordnlp https://t.co/ynvpE8PKFE 课程定位：从"模型"到"系统"的工程学 覆盖：简单 LLM 流水线 → 复合 AI 系统 → 自主 Agent。三位讲师的背景也高度互补： @Diyi_Yang（斯坦福 NLP 教授，人机交互与社会计算方向） @michaelryan207（DSPy 核心贡献者，自动评估 AutoMetrics 作者） @jyangballin（SWE-agent / SWE-bench / SWE-smith 作者，软件工程 Agent 领域最重要的研究者之一） # 课程主线：三大工程挑战 贯穿全课的三个核心问题——分解（decomposition）、数据（data）、评估（evaluation）。11 周的内容基本围绕这三条线展开，可以分为五个模块： 模块 1：构建基元（Week 2–3） · LLM 作为构建材料：API/SDK（litellm）、结构化输出、约束生成、解码策略、test-time compute、上下文工程、模型选型与成本/延迟权衡 · RAG：embedding、向量库、分块策略、混合检索、cross-encoder 与 ColBERT 后期交互 · 工具调用：函数调用 API、MCP（Model Context Protocol）、工具设计、代码沙箱、错误处理与重试 模块 2：框架与设计模式（Week 3–5） · 框架层：DSPy（signature / module / optimizer）、LangChain/LangGraph、LlamaIndex，重点是"框架抽象了什么 vs. 你手写了什么" · 设计模式：workflow vs. agent 的分类学，五种可组合 workflow 模式，ReAct / plan-and-execute / reflection，"scaffold（脚手架）本身就是设计决策" · 记忆架构：短期/长期记忆、记忆作为工具动作、文件系统作为外化记忆、跨 Agent 记忆（MemGPT、Mem0、Generative Agents） · 多 Agent 系统：编排模式、handoff 与状态传递，以及一个很有态度的对照阅读——既读 AutoGen，也读《Why Do Multi-Agent LLM Systems Fail?》和 Neubig 的《Don't Sleep on Single-agent Systems》 模块 3：优化（Week 5） · 从提示词到微调的全景：GEPA、MIPROv2、OPRO、TextGrad（提示优化）；LoRA/QLoRA、蒸馏、RLHF/DPO（权重优化）；test-time scaling（推理算力） · 核心问题是决策框架：什么时候优化 prompt、什么时候优化 weights、什么时候堆推理算力 模块 4：数据与评估（Week 6–8）——最有分量的部分 · 数据：trace、demonstration、feedback 三类数据；训练数据 vs. 评估数据；数据飞轮；合成数据；从 Agent 轨迹构建数据集（SWE-smith） · 评估基础：为什么 eval 难；4 元组框架（request / environment / stopping criteria / scorer）；好 benchmark 的性质；tinyBenchmarks · 评估基础设施：三类 grader、LLM-as-judge 的 prompt 设计与已知偏差、pairwise vs. pointwise、非确定性指标 pass@k vs. pass^k、harness 设计 模块 5：安全与前沿（Week 8–11） · 安全：工具访问的隐私风险、prompt injection（含间接注入）、红队、沙箱与权限模型、输出护栏、human-in-the-loop · Coding Agent：SWE-agent、Claude Code、OpenHands 的端到端架构对比 · 主动式 Agent：从 reactive 到 proactive，General User Models（GUM）、Next Action Prediction，以及"Agent 何时应主动、何时应等待"的 mixed-initiative 问题 · 开放问题：多模态/web/计算机使用 Agent、科学 Agent、长时运行架构、生产可观测性（tracing、monitoring、成本管理） # 作业设计：一手建、一手评 HW1：从零构建 Agent 系统（10%） 给定论文库，构建能检索并推理回答科学问题的 Agent。 · Part A：只用 litellm 手写 RAG + 工具调用 + ReAct 式 Agent 循环 · Part B：用 DSPy 重建关键组件，并反思框架抽象了什么 HW2：评估一个 Agent（10%） 给定一个预构建 Agent，设计完整评估套件：代码型 grader、至少一个 LLM-as-judge、用 4 元组框架构建 benchmark 任务、错误分析。
#教程/实践#Agent#数据/训练
I just published my roadmap for building evals on highly subjective tasks. Here are the key steps involved and practical tricks for reducing noise / increasing confidence… Blog is here: https://t.co/uo0FsWtkYF Why is this difficult? Evaluating agents is already hard due to their broad scope, emphasis on expensive / long-horizon tasks, and non-determinism. Subjective tasks make this even harder because we cannot deterministically verify solutions and must rely on human judgments (or LLM judges). This introduces additional noise into an already difficult evaluation process. Evaluation roadmap. We can build reliable evaluations using a repeatable framework with three components: - Human evaluation: Our North Star for quality. Create quality guidelines that clearly define quality with the help of subject-matter experts, calibrate human evaluators to ensure agreement, and continually monitor evaluation quality. - Offline evaluation: Use calibrated LLM judges or task-specific rubrics as an efficient proxy for human evaluation. This allows us to scale experimentation without relying on expensive human evaluation for every new model. - Production monitoring: Track quality signals from real-world agent usage and use A/B testing to validate improvements before fully deploying a new agent. Multi-stage evaluation. These components form a tiered evaluation process: Offline evaluation → Human evaluation → Production A/B test → Full deployment We can test many ideas automatically, send promising candidates to human evaluation, and validate improvements through production A/B testing. Continual production monitoring then allows us to discover new use cases / failure cases in production that we can add into the earlier stages of evaluation to create a feedback loop. Sampling useful data. Evaluation quality depends heavily on which tasks we select. We want tasks that are diverse, realistic, difficult, discriminative, and accurate. Techniques like structured task taxonomies, model-based difficulty filtering, Item Response Theory (IRT), and LLM-based auditing help us construct more informative evaluation sets. Handling noise. We should leverage statistics throughout the evaluation process: - Power analysis: Estimate the number of evaluation samples needed to detect meaningful improvements. - Confidence intervals: Quantify uncertainty and provide clear confidence signals alongside evaluation results. - Re-sampling: Repeat agent / judge evaluations to reduce within-task variance and potentially tighten confidence intervals. - Paired comparisons: Evaluate models on the same tasks to more reliably detect performance differences. Key takeaway. An improved benchmark score does not always mean our agent is more capable. We need well-designed evaluation tasks, calibrated human / model evaluators, and statistical confidence signals to distinguish meaningful capability improvements from noise (especially on subjective tasks). By combining these techniques into a repeatable evaluation process / roadmap, we can make building and maintaining evaluation suites more systematic, reliable, and scalable.
#教程/实践#评测/基准#Agent
When our AI code reviewer's cost per run doubled, we dug into the token usage to find out why. Learn how we used prompt caching and intelligent model routing to slash our inference bill by 68% while speeding up reviews. https://t.co/FhCVDuy9z5
#教程/实践#部署/工程#编码
#评测/基准#Anthropic
#评测/基准#语音