推荐这篇，Hamel Husain——世界上最懂 AI eval 的实践者之一——说了一句话："这东西很难评估"本身就是一个产品气味。 如果你不给用户提供可检查的中间产物，他们就会重做一遍你的工作来验证输出。那你的产品对他们的价值是什么？ "这东西很难评估"是一个产品气味 我在 AI eval 上做了三年。最常听到的反对是"我们的产品很难评估"。这个反对本身就是一个产品气味——对你来说难验证的东西，对用户也难。 更重要的事：设计一个易于验证的产品，应该在写 eval 之前。 例 1：AI 数据分析 agent 几乎所有公司都在建内部分析 agent。问他一个业务问题，他找数据源、跑查询、给答案。目的是降低对数据分析师的依赖。 最常见的错误：把"答案"作为唯一的输出。 界面上只有一个数字——"Product A 上季度净收入：$4.21M"。用户除了重新做一遍之外没有其他方式验证。更好的设计不是隐藏过程，而是给用户可检查的 artifact。 一个数据分析师验证指标时会做六件事：对照可信源检验中间计算过程和总量数字、确认指标精确定义、检验相关量的合理性、拆开聚合数字按维度分解、读 SQL、记录无法验证的部分。 一个好的 AI 数据分析 agent 应该做同样的事——在回答里展示来源、假设和无法验证的问题。用户可以点击打开一个 Notebook 查看完整分析：agent 做的假设、跑的查询、按地区的分解分布、显式列出"无法验证的部分"，每一项都作为可运行的 cell 保留，让用户可以继续深挖。 这对 eval 意味着什么 如果你的产品设计成便于验证，标注成本就会降低，eval 会有更好的信号可以抽取。更重要的是，你会给用户一个更好的产品。 例 2：PE 教案生成器 一个创始人做的产品：老师输入约束（年级、时长、室内/室外、器材），AI 写一份教案。 "怎么评估教案好坏？"——Hamel 把问题反过来了：老师在意什么？ 最快的方式是看到"一个和你一样的老师已经用过的教案"。一个好的设计：不是从零生成教案，而是从一个被审核过的、14 所学校在用、今年跑了 30+ 次的可信教案出发，然后只展示改了哪几处——"缩短到 45 分钟，改热身从 2 圈到 1 圈""匹配你的器材，4 站变 3 站"。老师审核的不是一个完整教案，而是一个 diff——认知负荷大幅降低。eval 也变得更可追踪：只需要验证检索出的教案是否合理，以及每个修改是否遵守约束。 例 3：工伤医学报告 一个产品从病历（MRI、理疗记录、体检报告）生成 50 页专家意见。问题是：医生要对报告负责，所以他们会重新读一遍全部病历、逐条核查——用时和从零写一份一样长。产品没价值。 Hamel 建议把产品做成研究助手而不是报告生成器。先读每份病历，提取相关事实，附上链接让医生可以核查。两份检查意见矛盾？标出来。影像资料缺失到现在状态不确定？标出来。事实审查完毕后，"生成报告"按钮才出现——报告由已经核查过的事实组装而成。 这样设计让每个单元可以独立评分：这个矛盾是真的吗？这个引用支持这个主张吗？ 这个模式可以泛化 问这四个问题：用户实际需要检查什么？他们能和什么可信的东西对比？专家用什么信号或启发式做验证？哪些更小的单元可以被接受、编辑或拒绝？ 一条贯穿所有例子的线索是来源。让输出可检查的最快方式，是展示每个部分从哪里来，带上链接查看细节。用渐进式披露让这些来源不会压垮用户。 即使一个产品看起来"容易评估"（比如你写出了能跑通的代码），最优秀的产品仍然在让工作更可检查——Cursor 和 Devin 都录制 UI 变更的短视频，让你确认工作的正确性而不需要自己复现。 这些都不是新东西 这些都是老的设计原则——观察专家的领域叫 needfinding，医疗诊断里的结构化理解叫 sensemaking。但在 AI 时代前，验证通常发生在创建产品的过程中，是附带的。在 AI 时代，验证是瓶颈。 是时候更显式地思考它了。 原文：Hamel Husain, ""It's Hard to Eval" Is a Product Smell", 2026-06-29 #AI产品# #Eval# #产品设计#

推荐这篇文章，LangChain Deep Agents v0.7 发布。 他们把默认的基础指令砍掉了一大半，跑完全部 eval 性能不变。 LangChain 在 7 月 29 日发布了 Deep Agents v0.7。这次更新的核心是把 harness 变薄——基础输入 token 减少 65%（约 6K → 2K），性能不变。 三条瘦身策略 删掉基础 system prompt。 Deep Agents 之前内置了一个通用指南和工具使用说明的 system prompt。v0.7 把它整个砍掉了。 工具描述精简 43%。 内置工具的描述文本被压缩了近一半。 Todo 列表默认关闭。 TodoListMiddleware 不再是默认开启。跨三类 eval（自主任务、多轮对话、长上下文）× 四模型（GPT-5.6 Luna、Gemini 3.6 Flash、Claude Sonnet 4.6、Claude Opus 4.8）的评测显示，关闭 todo 后奖励略优、成本更低。不过有三类场景仍然值得打开：长多步任务、能力较弱的模型、需要可见进度条的 UI 场景。 验证方法 LangChain 用了一个新的 eval 套件来做对照。三个基准类别：Autonomous（编码、数据分析端到端任务）、Conversational（多轮对话）、Long-context（长上下文检索推理）。v0.7 vs v0.6.12 矩阵跑下来，reward 整体持平，token 和成本多数下降。最显著的是 GPT-5.6 Luna：token -34%，成本 -15%，reward +4%。 Anthropic 的影响 博客里直接引用了 Anthropic 刚发的 Claude 5 模型的 context engineering 新规——Claude Code 的 system prompt 被砍掉了 80% 以上，coding eval 毫无下降。两条核心发现： • 接口比示例好。 好的 tool schema 教会模型怎么用工具，比过去流行的 few-shot examples 更有效——示例反而会收窄模型的探索范围。 • 不要重复。 在 system prompt 和工具描述里各说一遍同一个指令，不带来增益。 可配置性 v0.7 让覆盖内置中间件变成一等公民。传一个 middleware= 实例，同名的默认中间件会被原地替换而不是报错。一个实际例子：SummarizationMiddleware 默认在上下文窗口 85% 时用通用 prompt 做摘要——v0.7 可以把它换成： SummarizationMiddleware( model="fireworks:kimi-k3", trigger=("fraction", 0.5), # 50% 就开始摘要 summary_prompt="Summarize the conversation, keeping file paths and decisions verbatim...", ) 破坏性变更 • TodoListMiddleware 默认关闭（可 opt-in） • 移除了 v0.5 中废弃的 backend factories • delete 工具加入默认文件系统工具列表（可通过 allowlist 关闭） 原文： #DeepAgents# #LangChain# #AgentEngineering#

通义发布 Qwen-Audio-3.0-TTS 语音模型 一段参考音能说 16 种语言和 20 种方言 首包延迟做到 300 毫秒级 同一段参考音可以跨 16 种语言念，音色不走样：CV3-Eval 上说话人相似度 16 个语种全部排第一，Plus 平均 82.75 分（百分制，越接近 100 越像本人）。

我看了一下@ycombinator 今年的项目，基本上都是 1. FDE/Router + Vertical Application： 模型router → 针对某个具体场景做优化 → 接入业务 workflow → 用数据反馈继续优化。 初创公司卖模型，初创公司都是中转站。 2. Router + LLM Optimization / Infra： 跟上一类不一样，这种是解决大模型调用本身的问题：routing、cost、latency、eval、observability、prompt optimization、fine-tuning、inference 等。 比如说 @WorkWeave 这个产品，他们说自己是AI to understand and then route engineering work。最开始的产品更像是 AI-native engineering analytics：接 GitHub / PR / Claude / Cursor 等工程数据，然后用模型分析： 工程师到底完成了多少工作 哪部分代码是 AI 写的 AI coding tools 有没有真正提高 productivity AI 花了多少钱、ROI 怎么样 哪些任务 AI 做得好、哪些做得不好 后面他们这个方向跑到最后发现还是需要模型聚合能力，他们就往一个中转站走了，然后发布了weave router。 他们分析 各种企业的Claude Code workload 后称，大约 60–70% requests 是比较简单的 completion，这些任务用便宜的 open-source model 可以做到相近效果，而成本可能只有约 1/40。 Coding request → Weave classifier/router → 判断任务难度 → 选择模型。 所以拆解一下这家公司就是做Router + Vertical Coding 场景，Weave 这种模式比单纯做一个LLM中转站 Router 更值得借鉴，先找到一个 token spend 巨大、任务高度重复、而且不同任务对模型能力要求差异巨大的 vertical，尤其是coding场景，然后做它的 intelligent routing layer。 所以我感觉年初做中转站的经验虽然没有给我个人带来什么经济收益，但是确实积累了很多实战技能，比如说如何从零到一搭建中转站，如何做FDE，挨个建群解决用户的api问题，比如我自己搭画布接seedance。 往后来看这种经验太值钱了，以后的ai startup都会是这个形态。

Google 最近公开了他们怎么批量生产 Agent Skills 文章不长，但把 Skill 从“写一份 SKILL.md”推进到了工程化维护。自己在做 Skill 库，可以直接抄这 7 个做法： 1、目录先统一 每个 Skill 都按同一套结构来：SKILL.md 放主指令，OWNERS 标负责人，EVAL.yaml 放测试题和评分标准；复杂资料、脚本、素材和内部数据再各自归档。人多以后，统一结构能省掉大量沟通和排查 2、工具调用有优先级 能接远程 MCP 就优先接远程 MCP，需要时再退回 CLI 或 API。原因很实际：MCP 既能给 Agent 提供工具，也方便统一处理认证和权限 3、内部开发，自动导出 Google 先在内部编写和评测 Skill，通过后再用自动规则发布到 GitHub。导出时会剥离负责人信息、内部素材和评测集，公开仓库保持干净，内部治理信息也不会混进去 4、合并前先过机器检查 CI 会检查 frontmatter、行数、目录结构和命名规范，还会逐条测试链接，拦住 404 和编造出来的网址。文章推荐用 lychee 查链接，也给了一份用 skills-ref 验证 Skill 的 GitHub Actions 配置 5、持续跑评测 新 Skill 提交时要附多组测试题和评分标准，发布前先跑一次；整个 Skill 库每周还会定时复测。评测会比较 Agent 使用 Skill 前后的准确率、任务完成率、Token 消耗和完成时间，并在不同 Agent 框架里重复运行 6、每个 Skill 都要有人长期负责 仓库维护者管 CI、架构规范和整体健康，Skill Owner 负责后续更新。API 变了、评测退化了，都能直接找到应该修的人 7、用 Agent 帮作者写 Skill Google 还做了内部 Skill 和基于 ADK 的多 Agent 工具，辅助作者写指令、补评测、做自我批评，再导出到主仓库。Skill 数量一多，作者工具本身也得产品化 如果你正在维护自己的 Skill 库，可以先试试：统一目录、每个 Skill 配评测、明确长期负责人。做到这一步，Skill 才能跟着模型、API 和工具变化持续更新

我们衡量 LLM 能力的方式已经严重落后于模型实际能做到的事。 Karpathy 给了 Opus 5 一段《指环王》的开篇文字、1M token 预算和一句指令：用 Three.js 渲染这个故事。模型自主工作了 2 小时，产出了 5500 行代码，在三维空间中编排多边形资产，生成了一段程序化动画。 重点不是渲染效果好不好看，而是任务粒度发生了根本变化。 过去我们测 LLM 用的是单次问答：画一只鹈鹕、写一段代码、回答一个问题。模型在几秒内完成，我们立刻判断好坏。但现在模型能在没有人干预的情况下，自主管理 2 小时的计算预算，组织数千行代码的架构，协调多个创意维度的输出。 这意味着我们最常用的评估方式，包括 benchmark、A/B 测试和 human eval，都是为秒级任务设计的。当任务扩展到小时级，这些工具完全失效。 失败成本是第一个被放大的问题。一次生成失败浪费的不是几秒钟，而是几美元加几小时。更隐蔽的问题是：我们不知道模型在长时间运行中什么时候会偏航。它在第 30 分钟做出的某个小决策，可能在 90 分钟后才暴露，而且没有自动纠错机制能捕捉到。 严肃建设者应该开始关注两件事：长周期任务的自主纠错能力，以及模型在耗尽预算前是否会主动调整策略。 LLM 的测试范式需要一次和任务粒度相匹配的升级。

如果 Research Agent 只能把 leaderboard 分数刷高，那它离真正做研究还差很远。 真正有价值的 ML 方法，需要换设置、换规模后依然成立，也要经得起复现和泛化检验。 这篇论文提出的 MLS-Bench，就是为了评估这个能力。 它覆盖 12 个核心 ML 领域、140 个任务。每个任务都放在受控 scaffold 里，让 Agent 改进一个具体 ML 系统，并在多个泛化设置下评测，最后和同一环境里复现的人类 SOTA 方法直接比较。 这样做的重点是防止 Agent 走捷径：比如改 evaluator、改数据管线、扩大模型容量，或者只在可见验证集上刷分。 结果很现实： 即使强 baseline 已经给到模型，当前 frontier agents 依然没有超过最强 human SOTA。Human SOTA 平均分是 42.6，最好的 Agent 是 Claude Opus 4.6，分数为 36.0；Gemini 3.1 Pro 是 34.9。 更多迭代和更大 test-time search 可以缩小差距，但很难真正弥合差距。模型目前更擅长调参、工程优化和重组已有组件；一旦要求它提出能稳定泛化的新机制，短板就会明显出现。 我觉得这篇论文把 Auto-Research 的门槛讲清楚了。 低成本 verifier 下的大规模搜索，可以帮模型找到更高分的候选方案，但真正的科研还需要科学判断力：知道该验证什么、怎么分配有限算力，以及如何把局部结果变成可信证据。 未来 Research Agent 的核心能力，可能会从「生成 idea」走向「构建证据」。 能写出一个 proposal 只是开始。能在昂贵、不完整、需要复现的验证条件下，把一个方法真正证明出来，才更接近机器学习研究。 📎 arxiv:

Safari 推出 MCP Server，这条对 Web 团队比普通模型发布更实际。 Safari Technology Preview 247 现在允许 MCP 客户端连接 Safari 浏览器窗口。Agent 可以读 DOM、网络请求、截图、控制台输出，还能用 browser_console_messages、screenshot、evaluate_javascript、list_network_requests 这类工具做调试、性能分析和可访问性检查。 这意味着浏览器不再只是人看的界面，它会变成 Agent 的工作现场。 但小团队别只看到“以后 AI 可以帮我调试网页”。 更该先定义：哪些页面能被 Agent 读取，哪些请求不能暴露，哪些脚本执行要确认，哪些生产环境操作必须禁止。 浏览器权限一打开，效率和风险会一起进来。

做企业级 Agent，真正麻烦的环节全堆在 demo 之后 agents-cli 想省掉的就是那串部署、评估、观测和治理，它给 Claude Code、Codex 这类 coding agent 一套现成 CLI 和 skills 脚手架、eval、部署到 Google Cloud、再到发布到 Gemini Enterprise，这条链路都在一个工具里 如果你已经不满足于本地玩玩，想把 Agent 真推到团队和生产里，这类工具会比单个 prompt 值钱得多.