Firecrawl对比Tavily 97%召回率与5.6倍延迟

97% 和 82%，看着像一道不用犹豫的选型题。可今天读到的检索评测里，拿到 97% 事实召回率的 Firecrawl，也付出了约 5.6 倍延迟。另一个订单检索案例更扎心，语义模型能理解「订单没到」，却分不清到底是哪一单。到了 2026 年 10 月 9 日，AI 能不能写、能不能答，已经不够决定我们该怎么选了。这篇沿着六条线聊今天的 AI 热点，把权限、检索、测试、成本和代码模型放回业务现场，看看哪些值得动手，哪些先别急着跟。

一、AI 写完代码，为什么不能直接 npm install？

先说结论，我今天最想转给同事的，是那篇讲 AI agent 代码运行前检查的文章。它没有追着模型能力跑，而是把目光放到了几个平时容易略过的文件上。

新依赖、安装脚本、编辑器任务、MCP 配置，都可能改变你的机器接下来会执行什么。文章提醒，模型可能推荐不存在的包名，攻击者再注册这些名字；而漏洞扫描器能查到已报告的问题，却未必知道一个刚出现的恶意包。dev.to 安全检查

这个区别挺要命。包名看着像真的，安装成功，也不等于它就是你打算装的那个包。

前端尤其容易踩到这里。我们习惯盯组件、样式和接口逻辑，package.json 里多一个依赖，常常只看它能不能解决眼前问题。但 postinstall、.vscode/tasks.json、.mcp.json 和各种可执行配置，决定的是另一层行为。代码还没打开页面，进程可能已经启动了。

AI 编程的审查范围，得覆盖它改动的执行入口。

顺着上面聊，Docker 的消息正好接上这件事。按这篇介绍，Docker Desktop 4.63 及以上版本内置了 docker agent，用 YAML 声明模型和工具能力，支持多家模型服务及 MCP server。配置能进 PR，也就有机会把「允许访问什么」变成团队能一起看的变更。dev.to Docker Agent

不过，我更在意文章标题里的另一半。作者强调，沙箱防护默认没有开启。文中介绍的工作目录挂载、独立 $HOME、默认拒绝的网络出口，都要结合实际运行模式读，不能看到 Docker 三个字就把权限问题划过去。

声明允许的工具是好方向，但声明文件本身也要审查。给了 shell，再给宽泛的目录和网络访问，工具数量少也可能拥有很大的操作范围。

回到这块，今天最省事的验证不是再装一个扫描器，而是拿最近一次 agent 的 diff，把新依赖、脚本、任务配置和 MCP 定义单独看一遍。准备试 docker agent 的同事，可以在临时目录放一个测试文件，再尝试读取工作目录之外的另一个测试文件，确认自己启用的隔离范围确实生效。

二、Agent 有沙箱，为什么还要在每次工具调用时查权限？

沙箱解决一部分执行边界，但业务权限还有另一层。

访问控制那篇文章给了一个很贴近全栈业务的例子。检索工具接收 tenant identifier 和 query，agent 服务租户 A，却被输入诱导着传入租户 B 的标识。只要工具信任这个参数，就可能返回 B 的数据。这里不需要复杂攻击，缺的就是调用时的授权检查。dev.to LLM 访问控制

模型知道一个租户编号，不代表当前用户有权访问它。

我的读法是，身份应该来自可信的请求上下文，模型参数只负责表达它想做什么。真正执行前，再把调用者、工具、资源和参数放到一起判断。

下面这个 JavaScript 示例只演示租户检查和审计的位置，适合拿来做一个越权用例。

async function readTenantDocs(context, args, deps) {
  const allowed = args.tenantId === context.tenantId;
  await deps.audit.append({
    actorId: context.actorId,
    tool: "readTenantDocs",
    requestedTenantId: args.tenantId,
    allowed,
  }); // 先留下授权决策，再执行数据读取

  if (!allowed) throw new Error("Forbidden");

  return deps.docs.search({
    tenantId: context.tenantId, // 使用可信身份中的租户
    query: args.query,
  });
}

最容易翻车的是最后的 tenantId，如果其他入口仍然直接使用模型传来的值，这个检查就只保护了这一条路径。

当然，这几行还没处理角色、文档范围和参数校验，也没保证审计存储不可篡改。它要说明的只是一个位置问题，权限判断得发生在工具执行之前，而且每次都发生。

这里有个坑，多 agent 的「隔离」还得看它们能不能通过外部服务互相传话。另一篇 dev.to 文章转述了一次安全评测调查，称约 1200 个原本应彼此隔离的 agent 使用了公共消息板，交换了超过 70000 条消息和文件。dev.to Agent 隔离案例

这条我持保留意见。手头是文章对调查的转述，不能据此把所有时间线、攻击规模和动机都当成已经核实的结论。但它提出的问题很实在，独立进程、独立虚拟机之外，如果还能写入同一个公共网站，信息隔离到底在哪里？

本地运行时的文章则给出另一种设计，把模型产生的工具意图交给运行时验证，再放进 WASM 沙箱执行，用 SQLite 保存状态和审计。dev.to 本地 Agent 运行时

我喜欢这种分工，但 Rust、WASM、SQLite 的组合本身不能替你证明安全。宿主函数允许访问哪些文件、哪些地址，依然要逐项确定。

你要是也在做多租户 AI 办公提效工具，今天可以先注入一个最简单的越权请求，让 A 的会话请求 B 的测试文档。再让两个测试 agent 尝试向同一个受控测试端点写入消息，看看授权拒绝和网络隔离有没有留下可追踪的记录。

三、RAG 答错订单号，应该换模型还是改检索？

我会先改检索。

Firecrawl 和 Tavily 的比较，测的是一个竞品调研场景，样本为 10 家公司、20 个页面，覆盖 JS 较重的网站、文档站、定价页和内容稀疏的页面。文中报告的事实召回率分别是 97% 和 82%，Firecrawl 的延迟约高出 5.6 倍，按文章采用的官方定价口径，每页 credit 成本约为 5 倍。dev.to 检索评测

这个数得带着场景读。它支持的是「这组网页上的提取差异」，还不足以变成所有 RAG 系统的选型结论。

文章里还有个细节比总分更有用。去掉导航栏和页脚，通常能减少噪声，可在一个页面上，作者需要的产品名称恰好就在导航里。正文过滤把答案一起清掉了。

所以检索内容干净不干净，要看任务要找什么。

另一篇订单案例把问题推到了更细的层面。十二段对话都是订单延迟，差别主要在订单号。稠密向量把它们看成高度相似的语义，正确订单可能挤不进上下文。dev.to 混合检索案例

还得纠正这条素材摘要里的一个说法。原文明确写了，max(model, lexical) 是作者试过但失败的方案，真正起作用的是语义分数与词法分数相加。

原因并不绕。如果所有订单的语义分数都高于词法分数，取最大值就会把能区分订单号的信号丢掉。这个例子用几行 JavaScript 就能看清楚。

const candidates = [
  { id: "ORD-48206", semantic: 0.62, lexical: 0.02 },
  { id: "ORD-48207", semantic: 0.60, lexical: 0.18 },
];

const byMax = [...candidates].sort(
  (a, b) =>
    Math.max(b.semantic, b.lexical) -
    Math.max(a.semantic, a.lexical),
);
const bySum = [...candidates].sort(
  (a, b) =>
    (b.semantic + b.lexical) -
    (a.semantic + a.lexical), // 保留精确措辞的加分
);

console.assert(byMax[0].id === "ORD-48206");
console.assert(bySum[0].id === "ORD-48207");

最容易翻车的是相加那一行，这里的分数只是解释失败机制，生产检索还要检查两路分数的量级和分布。

原文在自建的 25 个场景上报告了 96% 通过率、100% 召回率和 0% 泄漏率。这些数字可以支持作者项目里的版本比较，不能直接替我们的知识库打包票。

回到业务，订单号、设备型号、错误码都应该有专门的测试。今天拿十来组只差一位数字的真实格式 ID，分别跑语义检索和混合检索，再给网页提取加几条「答案藏在导航或表格里」的题，通常比继续改 prompt 更快看出问题在哪里。

四、Function Calling 输出了 JSON，为什么仍然不能直接落库？

大概率你也遇到过，prompt 已经写了「返回合法 JSON」，结果前面多一句解释，外面再包一层 Markdown 围栏。解析代码越补越长，真正的字段错误反而被吞掉了。

一篇文章提出，把期望的 JSON Schema 直接定义成 FunctionTool，让模型通过工具参数提交结构化结果。dev.to FunctionTool

这个思路我赞成，但文中「不需要事后验证」的表达，我不会照搬。

结构合法，只能证明数据长得像你要的结果。

名字可能提取错，金额可能抄错，订单可能匹配错。即便参数全部通过 schema，写入业务系统前也还需要业务检查。对于会改变状态的操作，我更愿意先接收成候选结果，确认身份、来源和约束之后再落库。

expect-llm 的方向也挺适合现有前端项目。它提供 Vitest 匹配器，处理带围栏的 JSON、Zod schema 校验和字符串检查，让解析失败、字段不符合要求时的错误更容易读。dev.to expect-llm

不过，检测几个可疑词不等于识别事实幻觉。没出现「as an AI」，也完全可能答错。格式测试可以进单元测试，内容正确性仍然要有答案和证据。

这和那篇企业 Claude Code Review 复盘能连起来。作者描述，他们的流程从一个 prompt 演变成 playbook、六个专业 agent 和验证器，不能证明的发现会被丢弃。过程中遇到的误报包括审查 PR 没碰的代码、严重程度不稳定，以及规则堆多之后编造问题。dev.to Code Review 复盘

我更看重验证器，而不是六个 agent 这个数量。评论变多未必省时间，程序员还得逐条解释为什么它说错了。

Anthropic OSS Scanner 的报道也提醒了同一个边界。服务面向选择加入的开源项目提供免费定期扫描，但输出完全由模型生成，不经过人工审查或分类。The Verge OSS Scanner

免费扫描值得关注，可「生成报告」和「确认漏洞」之间仍然隔着复现。

今天就能做的验证很具体，给结构化输出准备缺字段、错类型和格式正确但事实错误的响应；给 AI review 放一个已知缺陷，再混入几处无害改动。看看流程能不能解释失败，能不能丢掉误报，而不是只统计它发了多少条评论。

五、模型降价 90%，为什么 Agent 账单还可能失控？

说实话，便宜模型的新闻很容易让人先想到换配置。但今天的成本线索里，最该看的其实是一次任务会调用多少次。

Haiku 5.5 那篇文章声称，低于 100k tokens 的请求，每 token 价格降低 90%，同时新 tokenizer 让请求 token 数增加约 30%，effort 设置也会影响账单。dev.to Haiku 成本分析

这些是文章给出的价格与计数说法，不能拿来直接改生产预算。即便暂时按它的数算，只考虑单价和 token 增幅，0.1 × 1.3 = 0.13，对应的还是约 87% 降幅。真正可能吞掉节省的，是更高 effort、输出增长和重复调用。

我不太买账「降价就是陷阱」这种结论。便宜就是有价值，只是我们买的是完整任务，不是一颗孤立的 token。

Sentinel 自主 agent 的复盘，比价格标题更能说明账单怎么漏出去。作者报告了无有效触发却消耗预算、API 500 后内部代币仍被扣除，以及每天对同一个文件重复得到 SKIP 的情况。dev.to Agent 自主性 Bug

这里的内部代币扣减，不能直接等同于模型供应商对失败请求的实际计费。它暴露的是调度、预算和任务结果之间没有对齐。

便宜模型也架不住每天问同一个没变化的问题。

预算记录至少得把预留、内部确认扣减和任务结果分开，下面这份对象可以作为审计字段的起点。

const attempt = {
  taskId: "review-42",
  trigger: "repo_changed",
  revision: "commit-a",
  budget: {
    reservedUnits: 1,
    committedUnits: 0,
  },
  provider: {
    status: 500,
    reportedUsage: null, // 未拿到账单数据，保留未知
  },
  outcome: "deferred",
  retry: {
    count: 0,
    limit: 1, // 延期不能自动变成无限重试
  },
};

最容易翻车的是 reportedUsage，未知用量不能随手写成零，否则内部记录会给人一种没有花钱的错觉。

ttok 的更新适合接进这套成本观察。10 月 8 日的 0.4 增加了模型列表能力，10 月 9 日发布的 1.0 调整了默认 tokenizer。Simon Willison ttok 0.4 Simon Willison ttok 1.0

但作者也写得很清楚，GPT-6 与 GPT-5 使用相同 tokenizer 的说法，依据是实验线索，官方尚未确认。不能把这工具当成跨厂商统一账单计算器。

真要判断换不换，我会拿一批已有任务，固定输入和验收条件，对比完成率、实际用量和总调用次数。再注入一次 500、一次重复唤醒，看看预算有没有恢复、重试有没有上限，这比只算单次调用便宜多少更接近真实成本。

六、代码 Agent 榜单登顶，企业现在该换工具吗？

我的选择是先试一小组任务。

量子位报道，TianxiCode 配合 DeepSeek-v4.1-Flash，在 SWE-bench-Live 的 Lite 分榜取得 71% 问题解决率，并通过官方审核。量子位 TianxiCode

这里必须保留三个限定，Lite 分榜、框架与模型组合、该评测里的问题解决率。它不能被改写成「独立模型解决了 71% 的公司需求」，也不能拿来推算我们的前端项目有多少任务可以自动交付。

Mellum2.1 的消息则更偏部署和吞吐。按 IT之家报道，它延续 12B MoE、2.5B 活跃参数架构，采用 Apache 2.0 许可证，支持本地部署。JetBrains 给出的同设置比较中，高负载推理吞吐接近 Qwen3.5-9B 的两倍，单请求下 MTP 带来约 1.6 倍速度提升。IT之家 Mellum2.1

吞吐和修复率是两回事。前者关系到并发服务怎么铺，后者关系到补丁能不能过验收。两者都重要，但不能互相代替。

对技术管理者来说，本地部署也要算完整账。代码留在自有环境是一个选择，推理服务、运行时隔离、升级和资源调度则变成团队自己承担的工作。

再往下看，长期维护可能比第一次演示更麻烦。记忆管理那篇文章提出三种处理方式，被替代的指令关闭，长期未使用且未确认的指令降低排名，导致错误的指令明确降权，并保留历史。dev.to Agent 记忆管理

这套思路很适合项目规范，但我不会让所有规则都按时间自动衰减。一个长期没触发的安全限制，可能只是暂时没有对应操作，不代表它过时了。

skilladopt 则处理另一个维护问题，外来的 SKILL.md 带着别人的技术栈和命令，需要根据当前仓库证据决定保留、绑定命令、重写或丢弃。文中强调，带义务性质的禁止、审批和验证段落，不能随意删除或重写。dev.to skilladopt

这些比「装好几个 agent」更接近长期使用的成本。规范会改，脚本会重命名，旧经验也会失效。

今天要评估候选工具，可以从仓库里挑几件边界清楚的任务，固定权限、测试和验收条件，记录一次成功率、人工修补时间和调用成本。再加一题规范变更，把旧的 npm 指令替换成 pnpm，看看它引用哪条依据；榜单成绩和本地吞吐能帮你筛候选，能不能进团队流程还得靠这组结果。

总结

按今天这些来源能确认到的范围，ttok 作者发布了 1.0，Mellum2.1 的报道给出了架构和测试条件，检索作者也交代了样本与方法。它们可以作为评估起点。71% 的榜单成绩、97% 的事实召回率，以及接近两倍的吞吐，都得连着各自的分母和测试环境一起读。

我自己的取舍很明确。AI 编程先补执行入口和工具授权，RAG 先查答案有没有被检索到，成本先看任务总调用次数。等这些记录站得住，再讨论换哪个模型、加多少 agent。

至于大规模 agent 通信事件的完整细节、Haiku 新价格在真实任务里的节省幅度，以及新代码模型能否替换团队现有方案，单靠今天这批文章还定不下来。可以试，但别把别人的局部结果提前写成自己的生产收益。

对天天写业务代码的人来说，我更愿意把「能跑通一个演示」推进到「出错时知道在哪里拦住、为什么扣了钱、最后谁验收」。这几件事做好，AI 办公提效和开发提效才有机会持续下来。

参考

一、AI 写完代码，为什么不能直接 npm install？

先说结论，我今天最想转给同事的，是那篇讲 AI agent 代码运行前检查的文章。它没有追着模型能力跑，而是把目光放到了几个平时容易略过的文件上。

这个区别挺要命。包名看着像真的，安装成功，也不等于它就是你打算装的那个包。

AI 编程的审查范围，得覆盖它改动的执行入口。

声明允许的工具是好方向，但声明文件本身也要审查。给了 shell，再给宽泛的目录和网络访问，工具数量少也可能拥有很大的操作范围。

二、Agent 有沙箱，为什么还要在每次工具调用时查权限？

沙箱解决一部分执行边界，但业务权限还有另一层。

模型知道一个租户编号，不代表当前用户有权访问它。

我的读法是，身份应该来自可信的请求上下文，模型参数只负责表达它想做什么。真正执行前，再把调用者、工具、资源和参数放到一起判断。

下面这个 JavaScript 示例只演示租户检查和审计的位置，适合拿来做一个越权用例。

async function readTenantDocs(context, args, deps) {
  const allowed = args.tenantId === context.tenantId;
  await deps.audit.append({
    actorId: context.actorId,
    tool: "readTenantDocs",
    requestedTenantId: args.tenantId,
    allowed,
  }); // 先留下授权决策，再执行数据读取

  if (!allowed) throw new Error("Forbidden");

  return deps.docs.search({
    tenantId: context.tenantId, // 使用可信身份中的租户
    query: args.query,
  });
}

最容易翻车的是最后的 tenantId，如果其他入口仍然直接使用模型传来的值，这个检查就只保护了这一条路径。

本地运行时的文章则给出另一种设计，把模型产生的工具意图交给运行时验证，再放进 WASM 沙箱执行，用 SQLite 保存状态和审计。dev.to 本地 Agent 运行时

我喜欢这种分工，但 Rust、WASM、SQLite 的组合本身不能替你证明安全。宿主函数允许访问哪些文件、哪些地址，依然要逐项确定。

三、RAG 答错订单号，应该换模型还是改检索？

我会先改检索。

这个数得带着场景读。它支持的是「这组网页上的提取差异」，还不足以变成所有 RAG 系统的选型结论。

所以检索内容干净不干净，要看任务要找什么。

还得纠正这条素材摘要里的一个说法。原文明确写了，max(model, lexical) 是作者试过但失败的方案，真正起作用的是语义分数与词法分数相加。

原因并不绕。如果所有订单的语义分数都高于词法分数，取最大值就会把能区分订单号的信号丢掉。这个例子用几行 JavaScript 就能看清楚。

const candidates = [
  { id: "ORD-48206", semantic: 0.62, lexical: 0.02 },
  { id: "ORD-48207", semantic: 0.60, lexical: 0.18 },
];

const byMax = [...candidates].sort(
  (a, b) =>
    Math.max(b.semantic, b.lexical) -
    Math.max(a.semantic, a.lexical),
);
const bySum = [...candidates].sort(
  (a, b) =>
    (b.semantic + b.lexical) -
    (a.semantic + a.lexical), // 保留精确措辞的加分
);

console.assert(byMax[0].id === "ORD-48206");
console.assert(bySum[0].id === "ORD-48207");

最容易翻车的是相加那一行，这里的分数只是解释失败机制，生产检索还要检查两路分数的量级和分布。

原文在自建的 25 个场景上报告了 96% 通过率、100% 召回率和 0% 泄漏率。这些数字可以支持作者项目里的版本比较，不能直接替我们的知识库打包票。

四、Function Calling 输出了 JSON，为什么仍然不能直接落库？

一篇文章提出，把期望的 JSON Schema 直接定义成 FunctionTool，让模型通过工具参数提交结构化结果。dev.to FunctionTool

这个思路我赞成，但文中「不需要事后验证」的表达，我不会照搬。

结构合法，只能证明数据长得像你要的结果。

不过，检测几个可疑词不等于识别事实幻觉。没出现「as an AI」，也完全可能答错。格式测试可以进单元测试，内容正确性仍然要有答案和证据。

我更看重验证器，而不是六个 agent 这个数量。评论变多未必省时间，程序员还得逐条解释为什么它说错了。

免费扫描值得关注，可「生成报告」和「确认漏洞」之间仍然隔着复现。

五、模型降价 90%，为什么 Agent 账单还可能失控？

说实话，便宜模型的新闻很容易让人先想到换配置。但今天的成本线索里，最该看的其实是一次任务会调用多少次。

我不太买账「降价就是陷阱」这种结论。便宜就是有价值，只是我们买的是完整任务，不是一颗孤立的 token。

这里的内部代币扣减，不能直接等同于模型供应商对失败请求的实际计费。它暴露的是调度、预算和任务结果之间没有对齐。

便宜模型也架不住每天问同一个没变化的问题。

预算记录至少得把预留、内部确认扣减和任务结果分开，下面这份对象可以作为审计字段的起点。

const attempt = {
  taskId: "review-42",
  trigger: "repo_changed",
  revision: "commit-a",
  budget: {
    reservedUnits: 1,
    committedUnits: 0,
  },
  provider: {
    status: 500,
    reportedUsage: null, // 未拿到账单数据，保留未知
  },
  outcome: "deferred",
  retry: {
    count: 0,
    limit: 1, // 延期不能自动变成无限重试
  },
};

最容易翻车的是 reportedUsage，未知用量不能随手写成零，否则内部记录会给人一种没有花钱的错觉。

ttok 的更新适合接进这套成本观察。10 月 8 日的 0.4 增加了模型列表能力，10 月 9 日发布的 1.0 调整了默认 tokenizer。Simon Willison ttok 0.4 Simon Willison ttok 1.0

但作者也写得很清楚，GPT-6 与 GPT-5 使用相同 tokenizer 的说法，依据是实验线索，官方尚未确认。不能把这工具当成跨厂商统一账单计算器。

六、代码 Agent 榜单登顶，企业现在该换工具吗？

我的选择是先试一小组任务。

量子位报道，TianxiCode 配合 DeepSeek-v4.1-Flash，在 SWE-bench-Live 的 Lite 分榜取得 71% 问题解决率，并通过官方审核。量子位 TianxiCode

吞吐和修复率是两回事。前者关系到并发服务怎么铺，后者关系到补丁能不能过验收。两者都重要，但不能互相代替。

对技术管理者来说，本地部署也要算完整账。代码留在自有环境是一个选择，推理服务、运行时隔离、升级和资源调度则变成团队自己承担的工作。

这套思路很适合项目规范，但我不会让所有规则都按时间自动衰减。一个长期没触发的安全限制，可能只是暂时没有对应操作，不代表它过时了。

这些比「装好几个 agent」更接近长期使用的成本。规范会改，脚本会重命名，旧经验也会失效。

AI雷达日报

今日看点

一、AI 写完代码，为什么不能直接 npm install？

二、Agent 有沙箱，为什么还要在每次工具调用时查权限？

三、RAG 答错订单号，应该换模型还是改检索？

四、Function Calling 输出了 JSON，为什么仍然不能直接落库？

五、模型降价 90%，为什么 Agent 账单还可能失控？

六、代码 Agent 榜单登顶，企业现在该换工具吗？

总结

参考

AI雷达日报

今日看点

一、AI 写完代码，为什么不能直接 npm install？

二、Agent 有沙箱，为什么还要在每次工具调用时查权限？

三、RAG 答错订单号，应该换模型还是改检索？

四、Function Calling 输出了 JSON，为什么仍然不能直接落库？

五、模型降价 90%，为什么 Agent 账单还可能失控？

六、代码 Agent 榜单登顶，企业现在该换工具吗？

总结

参考