今日必看
Eval Engineering Skill 把 Agent 评测前移到仓库和轨迹层
LangChain 在 2026 年 7 月 22 日发布 Eval Engineering Skill，并在 langchain-ai/langchain-skills 仓库合入 eval-engineering skill。官方博客给出的流程不是让模型一次性生成测试题，而是先读取 Agent 仓库，映射 prompts、models、tools、skills、hooks 等表面，再可选读取 LangSmith trace 或同类轨迹，识别真实工具参数、结果和错误；随后通过用户访谈选择要测试的能力，决定哪些依赖真实运行、哪些写操作或高成本工具需要模拟。最终产物是 Harbor 格式的可执行 eval，包括 instruction、Dockerfile 环境和 verifier，并落到 evals/<task-id>/ 下。博客还披露该流程在 chat-langchain 文档问答 Agent 上做过测试，任务来自真实 trace 中的文档问题，verifier 用 golden answer string 和 cited documents 检查答案。证据阶段是官方发布、代码仓库和项目自测，不是第三方 benchmark 或客户生产数据。主来源
这条动态的重要性不在“又多了一个 skill”，而在 Agent 基础设施的评价对象从单次输出质量，转向“仓库结构、工具契约、生产轨迹和可复现实验环境”的组合。一个可辩论判断是：未来生产 Agent 的工程护城河不会只来自更强模型或更大的工具集，而会来自谁能把失败轨迹最快转成回归 eval；这会让 LangSmith、Harbor、Deep Agents、OpenAI Agents SDK、GitHub MCP 这类工具逐渐争夺同一层控制权，即 Agent 改进闭环的事实账本。这个判断的证伪条件也清楚：如果团队仍主要靠人工看 trace、临时改 prompt，而不是把失败固化成可重复任务，Eval Engineering Skill 只是开发者工作流增强，不会成为平台入口。后续验证指标应看三件事：langchain-skills 是否出现 tagged release 和更多 eval-engineering 引用；Harbor task 是否被第三方 Agent 项目作为默认评测格式；生产工具能否导出足够稳定的 trace schema，让 eval 自动生成不是一次性手工脚本。仓库
软件 / 框架
OpenAI Agents SDK v0.18.3：GitHub release 显示 2026 年 7 月 17 日发布，新增可配置 task/turn tracing spans 和 realtime session usage 记录，同时修复并发 computer provider 隔离、E2B workspace 重复创建、streamed session retry 输入保留、SQLite session metadata 泄露和非工具 trace error 细节脱敏。它的信号是 Agent SDK 正在补生产运行时的并发、追踪和隐私边界；局限是没有给出吞吐、延迟或事故率改善数据。主来源
Open SWE：
langchain-ai/open-swe仓库 7 月 22 日仍高频活跃，近期 PR 包括把大输出 capture 放到 sandbox 内以避免 worker OOM、修复 trusted skill 并发 ref 合并、增加 Tenki sandbox provider，以及回退 repository skill 支持。它说明异步编码 Agent 的难点正在从“能否写代码”转向 sandbox 输出、技能加载、审查回路和并发状态；但这些仍是仓库级硬化信号，不等于稳定商业 SLA。主来源
算法 / 论文
IssueBench：LangChain 7 月 20 日介绍内部 benchmark，用 15 个 synthetic task 评估 LangSmith Engine 是否能从 Agent traces 中识别问题、分配失败类别、挂到既有 issue、聚类新故障；覆盖 SRE log analysis、software engineering 和 customer support，并使用 hidden ground truth。它把评测对象从“回答是否正确”推进到“能否把失败转成可路由工程任务”，但目前仍是内部 benchmark，外部无法独立复测。主来源
MCPZoo 安全研究：arXiv 2607.11086 于 7 月 13 日提交，提出 MCPZoo，用多 Agent 框架把野外静态仓库转成可动态分析服务；论文称包含 64,611 个 unique MCP servers，其中 37,288 个支持动态分析，并指出现有 scanner 报告 96.89% server 有风险但 sampled alerts 真阳性少于 50%。它提示 MCP 生态不能只靠静态扫描定风险，Agent 工具市场需要可运行验证；局限是论文结论仍需公开查询接口和第三方复测支撑。主来源
新项目雷达
- langchain-ai/langchain-skills：GitHub API 显示该仓库 2026 年 1 月创建，7 月 22 日合入 “Add eval engineering skill”，目录里已有
config/skills/eval-engineering/SKILL.md与 Harbor、trace sourcing、verifier design 等 reference 文件。它值得单独跟踪，因为 skill 形态把 Agent 开发方法产品化为可安装知识包；但仓库当前未显示明确 license metadata，且还没有 release tag。主来源
持续观察
验证信号：未来两到四周看 Eval Engineering Skill 是否从 LangChain 自用扩展到 Open SWE、OpenAI Agents SDK、GitHub MCP Server 或第三方 coding-agent 项目；关键不是 star 数，而是是否能生成可提交、可复跑、可比较的 eval artifacts。参考来源
非共识判断：Agent 平台的下一个入口可能不是“更多工具调用”，而是“失败样本的所有权”。谁能控制 trace、issue、eval 和修复 PR 的闭环，谁就能决定企业 Agent 的默认治理面。若 MCP server 安全扫描、IssueBench 和 eval skill 不能连接到同一条证据链，这个判断就要下修为局部开发者工具改进。参考来源
端侧关联：这条线也会影响端侧 AI 与机器人。边缘设备上的本地 Agent、机器人运维 Agent 和工厂质检 Agent 不能只证明“能调用工具”，还要证明异常 trace 能被离线复现、在弱网或无云环境下重放，并形成可审计的回归任务。若 RKNN、BPU、QNN、OpenVINO 或 AXera 生态后续只给模型 demo、不提供 trace-to-eval 管道，本地 Agent 的产业化会继续依赖云端平台完成质量闭环。参考来源
评论