转载提示：本文转载自 原文。原作者：Andrew Qu。原文发布日期：2025-12-22。本文已按站点规范移除推广/导流内容，仅保留核心观点、论证链路与示例。我们砍掉了 80% 的 Agent 工具 Published: December 22, 2025 | Authors: Andrew Qu 结果反而更好了。 团队曾花了数月打造一个复杂的内部 text-to-SQL Agent（d0）：工具很多、prompt 工程很重、上下文管理也做得很细。它“能用”，但脆弱、慢、维护成本高。 后来他们尝试反方向：删掉大部分工具，只保留一个能力——执行任意 bash 命令（file system agent）。Claude 直接读文件，通过 grep、cat、ls 等通用工具自己完成探索与推理。 系统变简单后，效果却同步提升：成功率从 80% 到 100%，步骤更少、token 更省、响应更快。d0 是什么 如果 v0 是面向 UI 构建的 AI，那么 d0 是面向数据理解与查询的 AI。 d0 把自然语言问题转为针对分析基础设施的 SQL 查询，让团队成员无需写 SQL 也能快速拿到数据答案。 当 d0 稳定时，它能“数据民主化”；当 d0 不稳定时，大家会回退到人工找分析师。核心要求就是：快、准、稳。不要替模型做过多“代思考” 回头看，很多工程投入其实在“替模型提前做决定”：担心它看不懂 schema、会乱 join、会幻觉表名，于是层层加护栏：做了大量特化工具（schema 检索、查询校验、错误恢复等）叠加重 prompt 约束推理路径用复杂上下文裁剪避免“喂太多”手写检索逻辑，只挑所谓“相关”信息给模型 问题是：每个边界场景都要补丁，每次模型升级都要重调，维护“脚手架”本身就消耗巨大。 ai-sdk@6.0.0-beta.160 ToolLoopAgentimport { 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 }, }); 新思路：那就别加了，反而删掉 团队意识到自己在“逆重力飞行”：把模型本可自行完成的判断硬性前置；把可直接读取的信息反复摘要；为“可能的复杂性”做了太多人工替代。 于是他们提出假设：直接把原始 Cube DSL 文件给 Claude，让它自己读、自己找、自己拼。随着上下文窗口和模型能力提升，最佳架构可能是“几乎无架构”。v2：文件系统就是 Agent 新栈如下：Model: Claude Opus 4.5 via the AI SDKExecution: Vercel Sandbox for context explorationRouting: Vercel Gateway for request handling and observabilityServer: Next.js API route using Vercel Slack BoltData layer: Cube semantic layer as a directory of YAML, Markdown, and JSON files 新的 file system agent 像分析师一样“读目录做分析”：查文件、搜模式、建立语义模型，再用标准 Unix 工具生成 SQL。 这之所以可行，是因为语义层本身已经是很好的文档资产：维度定义、指标计算、join 关系都在文件里清晰可读。 ai-sdk@6.0.0 ToolLoopAgentimport { Sandbox } from "@vercel/sandbox"; import { files } from './semantic-catalog' import { tool, ToolLoopAgent } from "…