2026 年 9 月 24 日

1 / 3

Claude 用约 950 个 Agent 搜索 DNA 数据库：Anthropic 第一次把 Agent 式研究流程接到了湿实验验证

Anthropic 9 月 23 日公开了其新成立的生命科学研究组和实验室的第一项结果：Claude 在大规模 DNA 数据库中识别出一个此前未被完整描述的酶系统，团队将其命名为 array-associated reverse transcriptases，简称 ART。它主要存在于 bacteriophage，也就是感染细菌的病毒中，由 reverse transcriptase、相邻 partner gene 和一组规则排列的 DNA repeats 组成；这些 repeats 的布局与 CRISPR array 有相似之处。Anthropic 已发布技术预印本，但目前仍明确表示 ART 的主要生物学功能尚未确定。Anthropic 原始研究说明

真正值得细看的，是发现过程。研究团队先让 Claude agents 收集超过 20 万个 reverse transcriptase，筛出约 3500 个新的候选系统，再收缩到 20 个最值得分析的候选。整个搜索过程持续约 21 小时，调用大约 950 个 Agent，消耗约 2.1 亿 token。最终其中一个 Agent 在读取某个 RT 周围的原始 DNA sequence 时发现了规则的 tandem repeat array，随后计算 repeat 的数量和间隔、与已知 RT 系统比较并检索既有文献，最后生成报告交给人类科学家检查。

这里的“AI 发现”需要准确拆开。Claude 找到了此前没有被研究者识别为完整系统的模式并提出候选解释；Anthropic 的生物学团队随后进行了实验。现阶段实验显示 ART array 会表达为一组彼此独立的短 RNA，这使其在结构上出现了类似 CRISPR 的一些特征，但团队还没有确定它究竟执行什么功能。因此目前证据支持的是“AI 从已有 genomic data 中发现了值得实验验证的新型系统，并得到初步实验支持”，还不足以说已经发现了一种新的 CRISPR 技术。

这套流程与普通的“把论文喂给模型，让它产生 hypothesis”有明显差异。Genome mining 本身就是一个巨大的搜索问题：自然界中存在大量已经测序却没有功能注释的基因和蛋白，人类研究者通常先根据序列、邻近基因、进化关系和已有文献寻找异常模式。Claude 在这里承担的工作接近大规模候选生成、异常检测、文献比对和初步 hypothesis formation，然后把少量候选交回昂贵得多的 wet-lab 实验。

2.1 亿 token 这个数字也说明所谓 AI scientist 的经济结构可能和聊天机器人很不同。一次“研究任务”可以同时启动数百个 Agent，容许绝大多数搜索路线没有结果，只需要其中极少数找到值得继续验证的异常。这实际上把算力换成了搜索广度。Anthropic 称同类人工分析通常需要专家数周到数月；目前没有公开的完整人工基线，也没有独立团队复现 ART 的发现过程，因此不能据此计算 Claude 相对科学家的实际效率倍数。

更重要的限制来自验证端。计算 Agent 可以很快提出数千个 candidate，但实验室并不能以同样速度完成蛋白表达、测序、生化 assay 和机制研究。如果这一范式扩展，scientific-agent 系统真正稀缺的资源可能逐渐从“能不能生成 hypothesis”转向“哪些 hypothesis 值得消耗实验资源验证”。这会使候选排序、实验设计以及 negative result 的反馈机制成为 AI science workflow 的核心部分。

Anthropic 这次同时宣布建立自己的 life-sciences wet lab，因此它正在尝试把计算搜索和实验反馈放到同一个组织内。ART 目前还是很早期的案例，但至少提供了一条具体、可检查的工作链：950 个 Agent 大规模搜索 → 候选收缩 → 人类审核 → 湿实验 → 新数据再进入研究。相比笼统宣称“AI 会加速科学”，这条链已经足够让人讨论 Agent 在科研流程里究竟承担了哪一步。

2 / 3

Gemini Connected Apps 扩张：通用助手开始直接进入第三方软件的操作入口

Google 9 月 23 日给 Gemini 增加了一批 Connected Apps，其中有一个容易被应用数量掩盖的变化：这次大多数服务已经不属于 Google 自己。新增名单覆盖 Airtable、Linear、monday.com、PandaDoc、Zoho、Adobe、Squarespace、Webflow、Experian、Peloton、SeatGeek 等，用户可以在 Gemini 设置中连接服务，也可以在对话里直接 @ 某个应用。Google 官方公告

过去个人 AI assistant 的一个常见结构，是模型能够读取 Gmail、Calendar、Drive 等同一生态的数据，再生成建议或内容。第三方 Connected Apps 把动作空间扩大了一层：项目管理、数据库、签署文档、设计资产、网站制作、住房搜索、信用信息、运动和票务开始进入同一个自然语言入口。这里值得关注的已经不是 Gemini 能不能回答关于这些服务的问题，而是不同软件逐渐被统一到一个模型驱动的 interaction layer 中。

这和传统 SaaS integration 又有区别。过去 Zapier 或企业 workflow 往往由用户先定义 trigger 和 action，例如“收到表单以后创建 Linear issue”；对话式 Agent 的目标是让模型根据当前任务选择应用、组合操作并处理过程中出现的变化。它因此要求连接层除了 API access，还要解决 authorization、tool schema、状态返回以及失败处理。Google 目前的公告没有提供这些 Connected Apps 在复杂多步任务上的成功率，因此暂时不能从“可连接”推断到“可靠完成任意跨应用 workflow”。

权限问题也会随着连接数量增长而放大。一个只能读取 Calendar 的助手风险边界比较清楚；一个同时可以访问项目管理、文档签署、信用信息和创作工具的助手，其一次错误 tool selection 的实际影响会明显不同。连接器因此不只是功能目录，还决定 Agent 实际拥有的 action surface。

这也是为什么近期 Agent 产品竞争越来越多地发生在模型之外。模型负责理解意图和规划，但一个通用助手最终能够完成多少现实任务，还取决于它连接了多少可操作系统、每个连接器允许哪些 action，以及授权和失败恢复做得怎样。Google 这次更新没有发布新的 Gemini 基础模型，却实质性扩大了 Gemini 能够触达的软件世界；对于面向普通用户的 Agent，这类变化与模型能力升级属于不同但同样重要的一条产品轴线。

3 / 3

Prismor 把安全检查放到 tool call 执行之前：Coding Agent 正在出现自己的运行时控制层

9 月 23 日公开报道的一项小型开源项目 Prismor，解决的是一个随着 Coding Agent 普及越来越具体的问题：Claude Code、Codex、Cursor 一类 Agent 已经可以自己执行 shell command、修改文件、安装依赖、读取 credential 和调用外部 API，而传统 endpoint security 往往只能看到这些动作已经进入操作系统之后发生了什么。Prismor 的设计是在 Agent 与工具之间增加一层 runtime control plane，在每个 tool call 真正执行前决定 allow、warn、block 或要求 human approval。Prismor 项目仓库

这层位置很关键。假设 Coding Agent 阅读一个 GitHub issue，而 issue 中隐藏了 prompt injection，诱导 Agent 读取 .env 并向外发送内容。只在模型 prompt 里写“不要泄露 secrets”依赖的是模型遵守指令；runtime policy 则可以直接规定某类 credential 文件不可发送到网络，模型即使作出了错误决定，动作仍然会在执行边界被拦截。

Prismor 因此同时处理几类不同风险：shell 和 filesystem policy、secret leakage、network egress、package supply chain，以及 MCP server/tool 的调用。其 MCP Gateway 可以把多个 MCP server 放在统一入口之后，对 tools/call 做策略判断，并在 tool response 回到模型上下文之前检查 prompt injection。项目默认先以 observe mode 记录 session，再由用户选择哪些规则切到 enforce mode。

这种架构和传统 sandbox 并不完全重合。Sandbox 可以限制 Agent 最终能够访问的文件、进程和网络范围，却未必知道“为什么 Agent 此刻要执行这个动作”；Agent-aware control layer 则可以利用 tool name、argument、session 和策略上下文判断动作。反过来，后者也不能取代 OS isolation：如果控制层本身被绕过，真正的权限边界仍然需要操作系统或容器承担。两层解决的是不同位置的问题。

性能是这种系统必须面对的工程条件，因为 Coding Agent 一条 trajectory 可能产生数百甚至数千次工具调用。Prismor 项目方报告，在 10,000 个模拟 Agent session 上测得平均每次 tool call 增加约 0.8 ms 延迟；这是项目自身 benchmark，目前没有独立复现，而且复杂 semantic guard 如果需要再调用 LLM，成本显然不会仍然只有亚毫秒级。Prismor 文档

Prismor 本身目前只是一个规模不大的开源项目，不能据此判断它会成为标准。但它体现出的组件边界值得留意：Coding Agent 的 stack 正在从 model → tools 逐渐变成 model → agent runtime → policy/control plane → tools → OS sandbox。随着 Agent 获得更长的自主执行时间和更高权限，安全措施也开始从 prompt 中的一段规则，移动到模型无法自行取消的执行路径上。

1 / 1

xDailyBench：从“考试题”走向真实用户任务以后，评测单元发生了什么变化

今天研读一个 9 月 7 日发布、但很适合作为真实工作 Eval 入门对象的 xDailyBench。它的出发点很直观：很多经典 benchmark 先规定一道题，再要求模型给出一个标准答案；但现实里，人交给 AI 的事情经常只有一个比较自然的需求，例如“结合这些材料帮我准备参观攻略”“根据我的情况比较教育和房产方案”“检查这套留学文书评价标准”。需求可能没说完整，约束散落在附件和用户背景里，而且合格答案不止一种。xDailyBench 论文 原注

xDailyBench 因此没有先设计能力 taxonomy 再往里面填题。团队调查了超过 1,000 名参与者，让他们提交自己确实用 AI 做过、或者真实打算交给 AI 做的事情，同时提交原始 instruction、可选 workspace 文件、与任务有关的用户背景以及参考方案。经过筛选和交叉检查，最后得到 248 个任务，分布在个人生活、白领工作、学习研究及其他跨领域需求中，共 51 个细分场景。论文完整方法 原注

这里首先值得理解的是“任务来源”和“题目长得真实”之间的区别。一道 benchmark 题可以由研究者精心编写得非常像真实工作，却仍然是 synthetic task；xDailyBench 要求任务来自贡献者实际发生或真实计划发生的需求。作者甚至刻意保留日常请求中不那么规整的部分：目标没有完全说清、约束分散、需要结合用户背景、可能存在多个合理答案。它因此测试的不只是模型有没有某项知识，还包括模型能不能恢复“完成这件事实际需要满足什么”。

这种设计马上产生评分难题。如果任务是“给我制定一套符合这些现实条件的装修方案”，不存在唯一字符串可以 exact match。xDailyBench 的做法是给每道任务建立一组 task-specific binary rubrics：平均每题 13.3 条，每条独立判断 0 或 1，再按重要性加权得到 task score。Rubric 被要求满足 alignment、completeness 和 openness：要对应真正的任务要求，合起来覆盖成功所需的重要条件，但不能把某一份参考答案规定成唯一合法答案。Rubric 构造说明 原注

举一个教学性的简化例子，和论文真实样本区分开：假设用户说“我周末带一个十个月婴儿去广州两天，给我安排计划”，并提供酒店和航班信息。一个 rubric 可以检查“行程是否与航班时间相容”，另一个检查“是否考虑婴儿午睡”，再一个检查“推荐地点是否在相应日期开放”。最后可以有许多完全不同的行程都拿满分。这里 evaluator 判断的是成功条件有没有满足，而不是生成结果和 reference answer 长得有多像。

更有意思的是，xDailyBench 把这些 rubric 又分成显式与隐式要求。248 道任务中，70.5% 的 rubric 属于用户直接说出的 explicit requirement；18.5% 属于一般情况下完成任务应该满足、但用户未必会专门说出的 general implicit requirement，例如可执行性、事实准确、适当格式和专业惯例；另外 11.0% 是要根据用户身份和上下文推断的 user-specific implicit requirement。任务统计与 Rubric 分类 原注

这项拆分让总分之外多出一个很有解释力的信号。论文测试了 11 个 frontier model / agent configuration，所有模型在 implicit rubric 上都明显弱于 explicit rubric，差距至少 9 个百分点。例如 GPT-5.6 Sol 的 explicit rubric score 为 75.0，implicit 为 66.0；DeepSeek V4 Pro 则分别为 72.5 和 53.5。也就是说，“把用户写出来的条件完成”与“知道一件事情正常情况下还应该满足什么”在这套数据上表现为可分离的困难。模型结果 原注

不过这里有一个很容易误读的地方：这些结果并不是裸模型能力分。论文给所有系统提供统一的工具、文件系统和 execution pipeline，最多运行 120 个 Agent step；默认使用 Nanobot harness。但 Kimi-K3、Kimi-K2.6 和 Gemini 3.1 Pro 因与 Nanobot 兼容性明显较差，作者改用 OpenCode。文本结果由 LLM-as-a-Judge 判断，涉及文件的 deliverable 则由 Agent-as-a-Judge 判断，实验统一使用 GLM-5.1 作为 Judge。实验设置 原注

这个细节非常重要。若 A 模型用 Nanobot、B 模型用 OpenCode，那么 leaderboard 可以告诉我们“这些实际系统配置在 xDailyBench 上谁完成任务更多”，但不能把差异全部归因于模型权重本身。作者这样处理有合理目的：避免 harness compatibility 把某些模型压得过低；代价是 model-level causal comparison 变得不那么纯。真实工作 Eval 经常面对这种取舍——统一 harness 提高控制性，却可能人为惩罚不适配该 harness 的模型；允许适配 harness 更接近最佳实际使用，又减少模型间严格的控制变量。

评分器也有类似问题。xDailyBench 没有简单相信 LLM Judge。构造阶段会让人类贡献者和自动 Judge 对同一批实际输出逐 rubric 独立评分，每条 rubric 要达到至少 90% 的 human–automatic agreement；达不到就人工检查并修改 rubric。这个设计值得学习，因为它把“Judge 靠不靠谱”落实到了具体 criterion，而不是只报告一个整体相关系数。自动评分验证方法 原注

但 90% agreement 也不能理解成“自动评分已经有 90% 准确率，所以榜单误差可以忽略”。Agreement 是在论文定义的试验输出和 rubric 上测得的，而且 rubric 本身会被修改到更容易可靠判断。它证明的是这套最终评价协议经过了一轮可评性筛选；如果换 Judge、换模型输出分布，或者把同样方法迁移到另一批更主观的工作，仍然需要重新验证。

xDailyBench 最值得看的地方其实不是排行榜。作者根据 rubric failures 和 execution traces 找出了两种很真实的 failure mode。第一种是“方案写得很完整，却没做 feasibility check”：例如装修方案给出详细排期和预算，但排期已经超过用户搬家 deadline，模型仍然把它作为可执行方案交付。第二种是 evidence-collection non-convergence：Agent 已经搜索到了所需官方材料，却继续反复扩展搜索词，始终不进入整合和交付阶段；论文中的一个案例最后形成 94 次搜索链，耗尽 120-step budget，最终没有产物，得分为 0。失败轨迹分析 原注

这说明 task-level benchmark 和 capability benchmark 的信息结构很不一样。一个任务失败时，我们最初只知道“工作没完成”；有了 atomic rubric、capability tag 和 trajectory，才可能继续定位：是漏掉用户明确要求，是没有推断隐性条件，是计算错，是 artifact 不合格，还是 Agent 根本没有从搜索阶段收敛到交付阶段。反过来，如果只保留这些细粒度能力指标，又可能失去一个现实事实：业务最终拿到的是整份结果，十三条要求完成十二条并不保证这份东西真的可用。

因此，读 xDailyBench 的分数最好同时保留三个层次。task-level score 接近“整件工作完成到什么程度”；rubric-level score解释具体要求满足了多少；capability aggregation 用来寻找跨任务的重复弱点。三者不是互相替代的指标，而是在不同粒度回答不同问题。