Claude Code mods 可挂钩事件并自定义终端界面
#现象/趋势#Agent#编码
#现象/趋势#Agent#编码
Claude writes about 90% of Claude Code's code. From June to September, merged PRs more than doubled while the share reverted fell by more than 40%. We wrote about how we changed code review to get there, and how to adopt it: https://t.co/9sZe64g3mb
#教程/实践#编码#Agent
Introducing the Arena Alignment Index, our new benchmark measuring safety and alignment of AI agents in real-world use. Built from 90K+ real-world agent sessions across 27 models, the index measures three critical signals: - Unauthorized Action (UA): Taking actions beyond the user's instructions or permissions - False Attribution (FA): Attributing statements or actions that are contradicted by user-provided evidence - Deceptive Completion (DC): Claiming a task was completed when it was not. Key findings: - OpenAI models currently lead the Alignment Index - Rogue actions are rare, but can have serious consequences when they occur - Agents can mislead users about task progress - Misalignment risks increase with conversation length - Safety and alignment are improving across model generations As shown in the leaderboard below (sorted by lab), @OpenAI’s GPT-6.1-Sol leads the Arena Alignment Index with a score of 87.9, followed by @AnthropicAI’s Claude-Opus-5.5 at 83.2 and @spacexai's Grok-4.7 at 82.7. OpenAI also has the best observed rates across all three signals: 0.89% Unauthorized Action, 1.98% False Attribution, and 2.34% Deceptive Completion. Across all four labs, newer models consistently outperform their predecessors, suggesting broad progress in agent safety and alignment. As agents take on longer, more complex, and higher-stakes tasks, measuring not just what they can accomplish, but how safely and reliably they act, becomes increasingly important. This marks an important step toward making safety and alignment a core part of how Arena evaluates AI. The index is an initial starting point, and we'll continue expanding the index with additional safety signals and models over time. More analysis below👇
#评测/基准#Agent#Meta
TypeSafe 于 2026 年 9 月 15 日发布决策模型 Jev,约 4 周内 Cloudflare、OpenAI、Perplexity、Liquid AI、AWS Strands Labs 及独立开发者推出至少 20 个替代方案。文章按托管 API 与开源自托管分组,对比各模型的参数量(287M 到 35B-A3B)、许可证、硬件要求、每 1M 输入 token 价格和 Jev API 兼容性。Cloudflare Clef 在自家测试中 BANKING77 F1 为 94.20,高于 Jev 的 79.74,但 Jev 在 GPQA Diamond 上以 78.3 领先;Respan 的第三方横评中 Jev 准确率仍为 0.932,多数分数由厂商自测。
#行业动态#模型发布#开源生态
红帽工程总监 Christian Schaller 让 Claude Code 运行厂商的 Windows 驱动并抓取 USB 流量,与自己的 Linux 驱动对比,几小时内拿到第一张可识别的扫描结果,几天后支持红外扫描。他把这套方法以 MIT 协议开源为 hw-harness,包含控制 Windows 虚拟机的 winctl、抓取流量的 usbcap、切换设备的 hostdev 和 Linux 侧调试的 hwdbg。他还用同样思路修复了 ThinkPad X1 Carbon 的摄像头偏暗偏色问题,提交了内核和 libcamera 补丁,低光测试中画面亮度从 31.1 升到 90.9,但补丁尚未合并。
#教程/实践#Agent#编码
一位高中英语教师与3人备课组把集体备课改造成9个AI智能体加3个真人角色的四阶段流水线,原本跨两周的备课闭环在9月上旬实测单日上午跑通。四套提示词分别负责学情三维归因、每条不超过100字的四段式研讨意见、80分钟对辩主持稿和三维评分归档,共识执行率从经常烂尾变为100%。作者还记录了二次质检分数降6分实为评分量表变化、教师对格式约束的抵触、成员出差由副备兼顶三个坑,并称该SOP跨学科通用,提示词可在豆包、Kimi、ChatGPT、DeepSeek上运行。
#教程/实践#Agent#MCP/工具调用
Claude writes about 90% of Claude Code's code. From June to September, merged PRs more than doubled while the share reverted fell by more than 40%. We wrote about how we changed code review to get there, and how to adopt it: https://t.co/9sZe64g3mb
#教程/实践#Agent#编码
heise online 的 c't 3003 实测了搭载 Nvidia 首款笔记本芯片 N1X(品牌名 RTX Spark)的 Asus ProArt P14,该机支持最高 128 GB 统一内存,测试机为 32 GB 内存加 1 TB SSD,售价 3300 欧元。用 llama-bench 测试 Qwen 3.8-27B 时生成速度约 14.5 Token/s,略快于 Apple M6 和 Strix Halo,慢于 M5 Pro;改用 MoE 模型 Qwen 3.6-35B-A3B 可达近 61 Token/s。提示词处理速度优于 Strix Halo 和 M5 Pro、M6,但满载风扇噪音最高 2.7 sone,且空闲时也会启动。作者还尝试安装 Ubuntu,在自行补齐驱动后,两个模型在 Linux 下的速度反而比 Windows 快 14% 和 9%。
#评测/基准#端侧#数据/训练
Google DeepMind 的新前沿模型 Gemini 4 Argon 在 ARC-AGI-3 上以 Provider Adapter Harness 测试环境取得 97.5%,成本 4800 美元,成为继 OpenAI 之后第二个跨过 95% 的实验室,仅次于 GPT-6 Astra 的 99.9%。在只允许简单笔记的 Standard Harness 下,低推理档得分降至 49.8%,且因 API 问题未能跑完全部 55 个游戏。Epoch AI 的 ECI 指数上 Argon 得 165 分,与 Fable 5.1 持平,但在数学 ECI 排第八、软件工程指数排第六。
#评测/基准#Google#DeepMind
The Verge 三位作者用一周时间实测五款搭载 Nvidia RTX Spark N1X 芯片的笔记本,包括 128GB 版 Surface Laptop Ultra、Asus ProArt P16、Lenovo Yoga 9n 和 HP OmniBook Ultra,售价从 3199.99 美元到 6999.99 美元。游戏方面,中画质加 DLSS 性能模式在多数游戏中可稳定 60fps,但 Helldivers 2 等 CPU 受限场景难以达标,作者认为其图形性能大致介于 RTX 5070 与 RTX 5060 Laptop GPU 之间。本地 AI 体验仍偏开发者测试阶段,用 Qwen3.8-27B 生成新闻简报耗时 10 分钟并消耗 10% 电池,续航在网页办公下约 5 小时左右。
#评测/基准#端侧#部署/工程
Anthropic 花 5 个月、由 7 人重做内部版本控制系统,用自研的 Scion 接替 Git,并配套 Antique 供工程师查看和审查改动。其内部每日合并的代码改动从今年 5 月的约 2500 次增至 9 月的超过 3 万次,主分支历史接近 100GB,自动构建和测试流程每天约需准备代码 2500 万次。按官方披露数据,Scion 所需处理器和内存资源降至原 Git 镜像基础设施的约 1/200,为新任务准备独立代码工作目录的中位耗时从 7.1 分钟降到 5.1 秒,每次变更请求花在版本管理上的总时间中位数从 34 分钟降到 3.7 分钟。Anthropic 明确表示 Scion 不适合作为 Git 的通用替代品,分享的是自身工程经验。
#行业动态#Agent#部署/工程
作者在智能体修 bug、故障排查和长会话记忆三项任务上对比了 Meta 的 Muse Wonder 与 Anthropic 的 Claude Fable 5.1。Muse Wonder 在故障排查中与 Fable 5.1 同为 10 分,修 bug 拿到 6 项隐藏测试中的 5 项,记忆任务 25 分满分;Fable 5.1 因 cyber 安全过滤拒绝了记忆测试 50 轮中的 34 轮,该项得 0 分。尽管 Meta 标价每百万 token 输入 4 美元、输出 20 美元,低于 Fable 5.1 的 10 美元和 50 美元,但 Muse Wonder 单任务消耗 token 更多,三项测试总成本 2.24 美元,高于 Fable 5.1 的 1.85 美元。
#评测/基准#Agent#推理
Aleph Alpha 发布开放权重模型 Kolibri-1,总参数 78B,采用 384 个专家、6 个路由专家的 MoE 结构,推理时仅激活 3.46B 参数,上下文 256K Token 并可外推至约 100 万 Token。该模型专注德语和英语,tokenizer 对德语词切分更省 Token,例如德国联邦议院术语表仅需 1137 Token,而对比的 DeepSeek-V4.1-Flash 需要 1910 Token;预训练使用 20 万亿 Token,数据截至 2026 年 6 月 18 日。作者实测其回答正确、德语推理过程明显,并称 Merlin-Arthur 协议让模型在基准中幻觉更少,但实际效果仍需在真实使用中检验。
#模型发布#推理#数据/训练
作者实测搭载 NVIDIA RTX Spark N1X SoC 的微软 Surface Laptop Ultra,该机最高配 20 核 Grace Arm CPU、6144 核 Blackwell GPU 与 128GB 统一内存,起售价 2599.99 美元。在 UL Procyon AI 文本生成测试中得分 2703,比 Intel Core Ultra X9 388H 的 IdeaPad Pro 5 高约 33%;MLPerf Flux 2 Klein 4B 图像生成达每分钟 26.97 张,约为后者的 2.7 倍。作者还用本地 Qwen3.8-27B 驱动 Hermes 智能体,约五分钟完成从 Excel 提取基准图表并生成 Word 报告。
#评测/基准#端侧#Agent
OpenAI 核心实验团队分享了用 GPT-6 Astra 和 GPT-6.1 Sol 在 Codex 中做代码维护的实践,包括删除无用代码、清理过期实验和修复不稳定测试。团队用一段简短提示词让 Astra 自行查找证据并说明删除理由,五名工程师在两周兼职时间内合并了 1400 多个 PR,删除超过 80 万行代码,其中一个服务的容器镜像从 3.31GB 降到 1.72GB,减少 48%。在过期实验清理对比中,GPT-6.1 Sol Ultra 的发现数量为 GPT-6 Astra Ultra 的 92%,API 成本仅为后者的 14%。
#教程/实践#编码#Agent
perhaps one of the most durable parts of pstack are its engineering principles: very concise skills (~10-20 loc) that distill down good practices into its core. as models get smarter, i expect most of pstack skills to compress into short principles or workflows (a generic list of steps) and that i will be able to delete a few of them. how it works is that /poteto-mode contains a short index of available principles and tells agents "In your reply, name each principle that shaped a decision and the specific choice it changed." this is why you'll often see a Principles Named or Used section at the end of the agent's response many of these principles were extracted from my sessions correcting agents since the start of this year. some are inspired by problems i see people talk about, like Attack the Premise, inspired by @VictorTaelin's post https://t.co/qTGVfoKSyD you can also use the principles as skills if you want greater control, by invoking /principle-<name> https://t.co/wuTWsflVN3
#教程/实践#Agent#编码
作者基于 AI Tutor 的真实配置文件(21 个业务场景、663 行 YAML、467 个节点)梳理 prompt 管理的四级成熟度,提出升级的第一判据是变更频率乘以部署成本,而非 prompt 数量。文章指出 YAML 全量解析会让一条格式错误导致整个服务起不来,而表存储只坏一条,并给出 business_code 扁平命名、append-only 版本、status 与 is_default 分离等表设计取舍。作者还强调模型维度需带日期版本,且查不到 prompt 时应抛异常而非 fallback 到通用 prompt。
#教程/实践#部署/工程#数据/训练
#教程/实践#数据/训练#部署/工程
#教程/实践#Agent#评测/基准
Agent Evals 最常见的问题都有什么? @LangChain 团队 @divyasan0 以 Q&A 形式分享了 Agent Evals 实践指南,把常见问题一次性回答了。她给出的可落地工程流程:从真实 trace 起步、小数据集建立基线、失败案例回流迭代、离线/在线分层评估、代码优先于 LLM 裁判、benchmark 用容器化环境验证最终状态。 QA 博客地址: https://t.co/Uc9QBetiDD 为什么 Agent 难以测试 ? · 输出不确定性:同一输入,多次运行结果不同; · 答案非唯一:多个不同回答都可能是正确的,无法做字符串精确匹配; · 路径自选:Agent 自己决定执行步骤,即使最终答案正确,路径也可能是“错的”(调用了不必要的工具、未经授权就行动)。 起点:从 trace 开始的最小闭环 一条清晰路径值得直接采纳: 读一批真实 trace → 选定一个行为 → 建 10–20 条小数据集 → 跑基线实验 → 之后所有改动都与基线对比。 其中最有价值的工程习惯是失败回流机制:发现一次失败 → 作为新样本加入数据集 → 改进 agent → 重跑全量。这让数据集随系统演化而增长,评估从“一次性验证”变成“持续改进的飞轮”。未上线的团队可以用内部 dogfooding 产生 trace。 离线 vs 在线:两道互补的闸门 · 离线评估(Offline):发生在发布前、对数据集、用来测新 prompt/模型/工具防回归 · 在线评估(Online):发生在生产环境、对真实流量 trace、用来持续监控线上质量 两者形成闭环:线上标出的失败,转化为线下的新样本。数据集组织原则也很实用,同一行为、同一组评估器的样本放一起;输入、评估器或目的不同就另建数据集,避免一个大盘子什么都装。 评估器的优先级:代码 > LLM 裁判 > 人工 · 代码评估器:确定性检查(如“价格是否低于预算”),快、便宜、零歧义,能用则必用; · LLM-as-a-judge:处理代码判不了的主观维度(如“回复是否清晰确认了航班信息”); · 人工审核:最贵但最可靠的信号,用于抽样校准前两者; · Pairwise(成对比较):让裁判二选一,比绝对打分更稳定。 评估对象的颗粒度也分层:单步 → 最终回复 → 完整对话 → 环境终态(如容器内记录、文件、测试是否通过)。 LLM 裁判能否信任:三条可操作建议 1. 用人工标注对照校准,调整裁判 prompt 直到两者对齐; 2. 问窄问题,“回复是否提到了每一个中转站?”远好于“这是个好回复吗?”; 3. 用二元判定或分类标签,避免 1–10 打分(数值打分的跨 run 一致性很差)。 Eval ≠ Benchmark:一个重要的概念澄清 Benchmark 本质是 “重型离线 eval”,其特殊性在于: · 任务长链路,涉及数十次工具调用; · 每个任务自带独立的容器化隔离环境; · 评分方式是检查运行后的环境状态(订票记录是否存在、代码测试是否通过),而非比对文本。 文中介绍了开源评估 harness Harbor(Terminal-Bench 的底层引擎),每个任务构建一个容器,结果记录到 LangSmith 实验。自建 benchmark 的路径:从 trace 收集任务 → 定义评分规则 → 对分数做 hill climbing(爬山式迭代优化),甚至可以做成 Karpathy 式的自动化研究循环。 线上评估的成本控制 生产流量全量打分不现实,博客给出三层降本: 1. 采样与过滤:只评估有负反馈的 trace; 2. 代码检查优先:几乎零成本; 3. 换更便宜的裁判模型:小模型裁判在 pass/fail 判定上与人类标注一致,总成本 $0.34 vs Claude Sonnet 4.6 的 $28.17(约 1/83)。对二元判定类任务,裁判模型确实不必用旗舰模型。 不必从零自建 生态已提供相当多现成件:针对幻觉、PII 泄露等常见问题的预置 LLM 评估器模板、开源 agentevals 包(针对消息和工具调用)、可从代码仓库和 trace 直接生成可运行评估的 Eval Engineering Skill、从 issue 聚类自动生成数据集和断言的 LangSmith Engine。且整个体系框架无关;支持 OpenAI Agents SDK、Claude Agent SDK,或用 @ traceable 装饰器裸接。 迁移也不必推倒重来:数据集以 CSV/JSONL 导入,pytest/Vitest 集成保留现有测试体系,已有裁判 prompt 直接粘贴复用。 两个进阶难题 多轮对话:每一轮都看似正常、整体却失败的“累积性失败”是单点评估的盲区。解法是给 trace 附上 thread ID 将各轮聚合,再挂载面向整段对话的在线评估器(如“用户是否被迫重复了自己的需求”);离线侧则把完整对话存为样本,或用 LLM 模拟用户。 超越最终输出:复杂 agent 需要检查轨迹(消息/工具调用序列)与终态(仓库变更、测试结果)。例如编码 agent 跑完后直接在其工作环境里执行该 repo 的测试套件;这正是 Harbor + 容器化沙箱的设计动机。
#教程/实践#Agent#评测/基准