We removed 80% of our agent’s tools

Andrew Qu | Chief of Software, Vercel 4 min read Dec 22, 2025

情况变得更好了

我们花了数月时间构建了一个名为d0的复杂内部文本转SQL代理，它拥有专用的工具、复杂的提示工程和精细的上下文管理。它勉强能工作…但很脆弱、速度慢，并且需要持续维护。

因此，我们尝试了一些不同的方法。我们删除了它的大部分功能，将这个代理精简到一个单一的工具：执行任意的bash命令。我们称之为文件系统代理。Claude可以直接访问您的文件，并通过grep、cat和ls等命令来解决问题。代理在变得更简单的同时，也变得更好了。成功率从80%提高到了100%。步骤更少，令牌使用更少，响应更快。一切都是通过“做得更少”实现的。

什么是d0

如果v0是我们用于构建UI的AI，那么d0就是我们用于理解数据的AI。d0通过让人们可以在Slack中向其提问，使任何人都能做出数据驱动的决策。

d0将自然语言问题转换成针对我们分析基础设施的SQL查询，让团队中的任何人都能在不写代码或不等待数据团队的情况下获得答案。

当d0运行良好时，它能在整个公司实现数据访问的民主化。当它出问题时，人们会失去信任，转而回到在Slack中联系分析师。我们需要d0快速、准确且可靠。

为模型让路

回想起来，我们当时在解决模型本可以自行处理的问题。我们假设它会在复杂的数据库模式中迷失方向、进行错误的连接操作，或者幻觉出表名。因此我们设置了护栏：我们预过滤上下文、限制其选项，并用验证逻辑包裹每一次交互。我们在替模型思考：

构建了多个专用工具（模式查找、查询验证、错误恢复等）
增加了大量提示工程来约束推理
利用精细的上下文管理来避免模型过载
编写手写代码进行检索以提供“相关”的模式信息和维度属性

每个边缘情况都意味着一个补丁，每次模型更新都意味着重新校准我们的约束。我们花在维护这个“脚手架”上的时间，比改进代理本身的时间还多。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// ai-sdk@6.0.0-beta.160 ToolLoopAgent
import { ToolLoopAgent } from 'ai';
import { GetEntityJoins, LoadCatalog, /*...*/ } from '@/lib/tools'

const agent = new ToolLoopAgent({
  model: "anthropic/claude-opus-4.5",
  instructions: "",
  tools: {
      GetEntityJoins, LoadCatalog, RecallContext, LoadEntityDetails,
      SearchCatalog, ClarifyIntent, SearchSchema, GenerateAnalysisPlan,
      FinalizeQueryPlan, FinalizeNoData, JoinPathFinder, SyntaxValidator,
      FinalizeBuild, ExecuteSQL, FormatResults, VisualizeData, ExplainResults
    },
});

一个新想法，如果我们只是…停止干预呢？

我们意识到我们在对抗重力。我们约束了模型的推理能力，总结了它本可以自己阅读的信息，并构建工具来保护它免受它本可以处理的复杂性。

所以我们停止了。假设是，如果我们只给Claude访问原始的Cube DSL文件，然后让它自由发挥会怎样？如果bash就是你所需要的全部呢？模型正变得越来越智能，上下文窗口也越来越大，所以也许最好的代理架构就是几乎没有架构。

v2：文件系统即代理

新的技术栈如下：

模型：通过AI SDK调用的Claude Opus 4.5
执行：用于上下文探索的Vercel Sandbox
路由：用于请求处理和可观测性的Vercel Gateway
服务器：使用Vercel Slack Bolt的Next.js API路由
数据层：作为YAML、Markdown和JSON文件目录的Cube语义层

现在，文件系统代理像人类分析师一样浏览我们的语义层。它读取文件，使用grep查找模式，构建心智模型，并使用grep、cat、find和ls等标准Unix工具编写SQL。

这之所以有效，是因为语义层本身就是优秀的文档。这些文件包含了维度定义、度量计算和连接关系。我们一直在构建工具来总结那些本来就清晰可读的东西。Claude只需要能直接访问并读取它即可。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


// ai-sdk@6.0.0-beta.160 ToolLoopAgent
import { Sandbox } from "@vercel/sandbox";
import { files } from './semantic-catalog'
import { tool, ToolLoopAgent } from "ai";
import { ExecuteSQL } from "@/lib/tools";

const sandbox = await Sandbox.create();
await sandbox.writeFiles(files);

const executeCommandTool(sandbox: Sandbox) {
  return tool({
    /* ... */
    execute: async ({ command }) => {
      const result = await sandbox.exec(command);
      return { /* */ };
    }
  })
}

const agent = new ToolLoopAgent({
  model: "anthropic/claude-opus-4.5",
  instructions: "",
  tools: {
    ExecuteCommand: executeCommandTool(sandbox),
    ExecuteSQL,
   },
})

3.5倍加速，减少37%令牌使用，100%成功率

我们在5个代表性查询上，对旧架构和新文件系统方法进行了基准测试。

指标	高级架构（旧）	文件系统（新）	变化
平均执行时间	274.8 秒	77.4 秒	加速3.5倍
成功率	4/5 (80%)	5/5 (100%)	提升20%
平均令牌使用量	~102k 令牌	~61k 令牌	减少37%
平均步骤数	~12 步	~7 步	减少42%

文件系统代理在每一项比较中都胜出。旧架构最糟糕的情况是查询2，它耗时724秒、100个步骤、145，463个令牌，然后失败了。而文件系统代理用141秒、19个步骤和67，483个令牌完成了同一个查询，并且确实成功了。

质的变化也同样重要。代理能捕获我们从未预料到的边缘情况，并能以我们可以理解的方式解释其推理过程。

经验教训

不要对抗重力。文件系统是一个极其强大的抽象概念。grep已有50年历史，至今仍能完全满足我们的需求。我们为Unix已经解决的问题构建了自定义工具。
我们之所以约束推理，是因为我们不相信模型能进行推理。对于Opus 4.5来说，这种约束变成了一种负担。当我们停止替它做选择时，模型会做出更好的选择。
这之所以奏效，仅仅是因为我们的语义层已经是优秀的文档。YAML文件结构良好、命名一致，并且包含清晰的定义。如果你的数据层是遗留命名约定和未记录连接关系的烂摊子，给Claude原始文件访问权限也救不了你。你只会更快地得到错误的查询。
减即是增是真实存在的。最好的代理可能就是那些工具最少的代理。每一个工具都是你在为模型做选择。有时候，模型会做出更好的选择。

这对代理构建者意味着什么

诱惑总是想穷尽所有可能性。抵抗它。从最简单的架构开始：模型 + 文件系统 + 目标。只有当你证明确有必要时，才增加复杂性。
但简单的架构本身并不够。模型需要好的上下文来工作。投资于文档、清晰的命名和结构良好的数据。这个基础比巧妙的工具更重要。
模型的改进速度比你的工具能跟上的速度更快。为六个月后你将拥有的模型构建，而不是为今天你拥有的模型构建。

如果你正在构建代理，我们很乐意听听你的见解。

使用Vercel和Slack构建一个代理使用 Bolt for JavaScript 和 Nitro 模板开始创建你自己的 Slack 代理。将其部署在 Vercel 上，即可在几分钟内获得一个实时的、可用于生产的设置。

部署模板

准备好部署了吗？使用免费账户开始构建。为您的 Pro 或 Enterprise 需求联系专家。

开始部署 | 联系专家

通过互动产品导览、试用或个性化演示探索 Vercel Enterprise。

探索企业版