数据湖分析智能体自己造工具：TEAL 无标注演化目录与索引，紧预算下准确率提升 21.7 个点

原文信息：本文译自 arXiv 论文《Unsupervised Tool Evolution for Coding Agents in Data-Lake Analytics》，作者 Yuqing Yang、Yurong Liu、Deqing Fu、Manav Garg、Sravan Babu Bodapati、Fatma Ozcan、Alon Y. Halevy、Jiani Zhang，2026 年 10 月 19 日提交（arXiv:2610.27327）。原文链接：https://arxiv.org/abs/2610.27327 。原文采用 CC BY 4.0 许可。本文为翻译（节译）：摘要、引言、方法与结论全文翻译，实验与附录按原文要点节译；图表、公式与参考文献请见原文。文末附译者注。

译者导语：让编码智能体（Coding Agent）在数据湖上做分析，最浪费的不是推理，而是“找数据、洗数据”——每来一个问题，它都要重新 find、grep、手工解析表头，做完就扔。这篇论文的思路很像 DBA 的老办法：给数据湖建目录（catalog）、建索引，只不过这些工具由智能体自己造、自己验收，而且全程不需要标准答案。在只给 15 步的紧预算下，准确率在两个基准上分别提升 9.3 和 21.7 个百分点。做数据平台、数据湖治理或 Data Agent 的工程师值得一读。

摘要

编码智能体可以在数据湖上回答分析类问题：发现相关数据、清洗、再做关联（join）。但它们每答完一个问题就把这些工作丢掉，下一个问题再从头来一遍。工具演化（tool evolution）——跨任务自动构建并不断改进可复用的工具——天然适合解决这种重复劳动。由于数据湖问题的标准答案需要专家先亲手解一遍才能得到，我们研究的是无监督场景。

我们提出 TEAL（Tool Evolution for Analytics over data Lakes），在没有标注的情况下，为给定的执行智能体（Worker）演化出一套工具库及其使用技能说明。两个智能体从互补的证据出发提出工具：探索者（Explorer）依据数据湖本身，评审者（Critic）依据 Worker 的执行轨迹。一项改动只有同时满足两个条件才会被保留：Worker 在重跑时确实用上了该工具且没有多花步数；如果答案发生变化，新答案必须有执行轨迹的证据支撑。我们还提出 TEAL-Q，在缺少真实问题时生成合成问题用于工具演化。

我们在 KramaBench 和 LakeQA 上、用四个 Worker 大模型、在不同步数预算（即每个问题 Worker 最多可执行的步数）下做了评估。在 10 步或 15 步的紧预算下，TEAL 对所有 Worker、在两个基准上都有提升；以 Sonnet-5 为例，15 步时在 KramaBench 上提高 9.3 个百分点，在 LakeQA 上提高 21.7 个百分点。更紧的预算还能为演化提供更好的反馈：Sonnet-5 在 20 步下演化出的 LakeQA 工具库，原封不动地用在 30 步下得分 68.3，既高于基线（59.6），也高于直接在 30 步下演化的工具库（64.2）。此外，用合成问题演化出的工具库与用真实问题演化的效果相当。这些结果表明，有用的工具可以在无标注的情况下演化出来。

一、引言

数据湖存放着规模庞大、格式各异的表格、文档和原始文件。要在数据湖上回答分析问题，需要先发现相关数据，把凌乱的记录整理成结构化形式，再跨数据源做集成。配备了 bash 终端和文件编辑器的编码智能体可以把这套流程自动化，但它们通常把同一数据湖上的每个问题都当作孤立任务：问题一结束，写过的解析器、模式检查和关联脚本就全被丢弃。

举个例子：分析师想知道，在各州的欺诈举报中，哪个都市区占本州比例最高。答案藏在 52 个按州拆分的 CSV 文件里，记录的是各都市区的计数，表头还不规整；它们混在数据湖成千上万个文件当中，旁边还有相似的全国汇总表和州级汇总表。没有目录或索引，光看文件名无法判断表的粒度，智能体很可能选中一张没有分州数据的全国汇总表。即便找到了这 52 个文件，逐个打开、清洗也会耗尽 30 步预算，15 步预算下失败得更早。下一个问题来了，同样的人工探索和清洗又要从头再做一遍。

数据库系统靠维护目录、索引和视图来避免反复扫描原始数据。编码智能体也可以照此办理：用可复用的工具代替逐步探索，一次调用就完成。有些工具背后还有预先计算好的数据产物（artifact），比如目录和索引；再配上使用技能（usage skill），告诉智能体何时、如何调用每个工具。

然而，现有方法无法自动生成这类工具，原因有二。其一，目录和本体（ontology）格式存储的是描述性元数据，而不是用来清洗、查询数据的可执行工具；代码类工具生成器则只为手头任务造工具，不会去造那种要跨很多问题才能回本的数据产物。其二，有监督的工具生成器和自演化本体依赖标准答案做验证，而在数据湖分析里，验证哪怕一个答案都需要专家先手工发现、清洗、关联底层数据，代价很高。没有标准答案时，“只要运行不报错就保留”的做法并不可靠：工具完全可能顺利执行，却读错了表的粒度、解析时丢了行，或者用没对齐的键做了关联。

为此我们提出 TEAL，一个为固定 Worker 演化工具库的无监督框架。工具库由可执行工具（部分以预计算数据产物为支撑）和使用技能组成。测试时，工具库被冻结，交给 Worker 回答新问题。

1.1 主要贡献

基于数据探索和 Worker 轨迹的工具演化。 TEAL 离线构建工具库，依靠两条证据来源不同的互补通道。探索者智能体在看不到任何问题和轨迹的前提下检查数据湖，像领域专家那样为整个数据湖准备工具，例如以预计算目录或清洗后的表为支撑的搜索和查找工具。评审者智能体则审视 Worker 在训练问题上的轨迹，找出它在哪里浪费步数、在哪里出错，据此新建或修改工具。随后由技能撰写者（Skill Writer）智能体更新使用技能，反映每一项已实现的改动。

无需标准答案的工具验证。 新提出的工具仍可能有逻辑错误，或者干脆被 Worker 无视，因此我们引入了重跑验证环节，在没有答案标注的情况下决定接受或拒绝每项改动：用更新后的工具库，让 Worker 重跑触发这次改动的那些问题；只有当 Worker 用到了改动过的工具、完成任务时没有多花步数，并且（如果答案变了）轨迹证据更支持新答案时，改动才会保留。

为工具演化生成合成问题。 当某个数据湖缺少真实用户问题时，TEAL-Q 以少量种子问题为示范生成问题供 TEAL 使用。它先从一组相关文件中起草一个问题，再经过几轮修订逐步加难，比如加入多表关联和更多推理要求，同时确保问题可解。

跨模型、跨预算的实证评估。 我们在 KramaBench 和 LakeQA 上，以 Gemini-3.8-Flash、Gemini-3.1-Pro、Sonnet-5 和 Opus-4.8 四个模型作为 Worker，在不同步数预算下评估 TEAL，得到三点主要发现：第一，在 10 步和 15 步的紧预算下，TEAL 在两个基准上提升了每个 Worker 的准确率，Sonnet-5 在 15 步时分别提升 9.3 和 21.7 个百分点，也优于只看能否执行的工具演化方法 ISE；第二，紧预算下演化的工具库可以迁移到宽松预算；第三，用 TEAL-Q 生成的 50 个合成问题演化，效果与用真实问题相当，而我们的无监督重跑验证也与使用标准答案的“神谕”验证效果持平。在 OpenHands 框架中演化出的工具库，原样迁移到 Google ADK、Codex CLI 和 Prime Agent，准确率最多提升 16.3 个百分点。

二、相关工作（节译）

面向数据分析的工具与智能体。 以往工作依赖人工预先准备的资源，例如元数据目录、关系索引、物化视图，或用户自定义插件、固定的数据湖检索工具集。近期也有工作让智能体自己构建这类资源：EvoOntology 由构建者智能体构建并改进本体层，但只有在带标注的保留集上得分提高时才保留改动；与本文最接近的 DataCOPE 通过答案一致性在无标注条件下发现技能，但这些技能是流程性指导，而不是以持久化产物为支撑的可调用工具。本文研究的是完全自动的工具演化：没有人写工具、整理数据产物或标注答案。

LLM 智能体的工具演化。 早期的自动造工具主要面向数学和科学问题，依靠标注样例或执行测试来验证。后来的智能体系统在长任务中按需造工具，比如字幕下载器、网页抓取器——任务缺了它就推进不下去，所以工具当场就会被用到，验收也就简化为“能不能执行”“环境是否显示完成”或“智能体是否觉得输出可信”。在数据湖分析里这两个前提都不成立：工具很少是在填补空缺，没有它 Worker 也能接着干；没有标注，又无法把答对归功于工具。因此 TEAL 通过 Worker 重跑时的行为来验证工具。

三、方法

3.1 问题定义

编码智能体与工具。 我们考虑配备终端和文件编辑器的编码智能体，它能读写文件并执行代码。在此之上，我们把“工具”定义为加入智能体动作空间、跨任务保留的具名可调用程序。工具一旦实现并调试完毕，就能用一个动作完成调用，无需重新构造其中的步骤。工具还可以依赖持久化产物，比如只需构建一次、跨任务复用的索引或缓存元数据。

数据湖分析中的工具演化。 给定一个关于数据湖的自然语言问题，执行它的编码智能体（Worker）要在步数预算内自主发现相关文件，完成数据准备、集成、分析和推理。工具演化系统看不到标准答案，只能观察 Worker 在训练问题上的轨迹，产出一个工具库：一组工具，加上一份技能文件——用自然语言告诉 Worker 何时、如何使用这些工具。之后冻结工具库，在同一数据湖上一组不相交的测试问题上衡量 Worker 的准确率。

3.2 TEAL：无监督工具演化

除了回答问题的 Worker，TEAL 还协调五个 LLM 智能体来演化工具库：

• 探索者（Explorer）：检查数据湖，提出针对这批数据的工具和预计算数据产物；
• 评审者（Critic）：诊断 Worker 轨迹中的执行瓶颈和错误，提出有针对性的工具改动；
• 工具匠（Toolsmith）：把探索者和评审者的提议实现为可执行代码，并用单元测试验证；
• 技能撰写者（Skill Writer）：维护技能文件，说明何时、如何调用每个工具；
• 分析员（Analyst）：在验证阶段，当原始运行与重跑的最终答案不同时，比较两条轨迹。

3.2.1 工具演化流水线

离线演化阶段（我们称之为“训练”，尽管没有任何模型权重被更新）按批处理训练问题，每批依次执行五个阶段，迭代更新工具库。

阶段 0：收集轨迹。 Worker 用当前工具库执行一批问题。每条轨迹都会附上一份工具使用摘要，作为后续阶段的证据：用了哪些工具、哪些没用、Worker 在哪里连续多步没调用任何工具。例如，面对一个很大的目录或一份 Excel 工作簿，摘要会指出 Worker 连续七步用 bash 搜文件、一次都没调用库里的工具，最后耗尽了步数。

阶段 1：专家式探索。 探索者在看不到问题和轨迹的情况下检查数据湖和现有工具，像领域专家那样为整个数据湖（而非某个具体任务）准备工具，提出“新增工具”和“更新工具”操作，也可以创建以持久化产物为支撑、为跨任务复用而预计算信息的工具。工具匠负责实现并用单元测试检查。与其他阶段不同，这一阶段每隔若干批才运行一次。比如，在浏览了数千个原始 CSV 和 Excel 文件之后，探索者提议做一个数据集搜索工具，背后是一个预先计算好的 SQLite 目录，记录文件格式、列名和样本行。

阶段 2：轨迹评审。 评审者审视阶段 0 收集的证据和当前工具集（包括探索者刚新增或更新的工具），提出三类操作：对被用到但有缺陷的工具“更新工具”；对本可以帮上忙却没被用到的工具“推广工具”；对现有工具覆盖不到的能力缺口“新增工具”。新增和更新由工具匠实现，推广则交给下一阶段的技能更新。例如，轨迹显示 Worker 总是栽在表头不在第一行的 Excel 表上，评审者就提议新增一个能识别表头位置的工作簿加载器；或者发现现有目录工具漏掉了某张表的历年版本，就提议更新它。

阶段 3：技能更新。 技能撰写者把探索者和评审者已实现的改动以及推广提议整合进技能文件。技能文件分两部分：跨工具的总体指引，以及每个工具的条目。例如，它会加一条跨工具的工作流规则，要求 Worker 先查目录工具，再用 shell 搜索；并写明遇到多工作表的 Excel 文件时何时调用工作簿加载器。

阶段 4：验证。 Worker 用更新后的工具库重跑这批问题，每次重跑都与原始运行做三项比对：改动过的工具是否被用到；任务是否仍能完成；如果答案变了，新答案是否有更充分的轨迹证据（见 3.2.2）。只要某次重跑通过全部三项检查就保留改动，否则在至多一轮修复后回滚。得到的工具库带入下一批，离线训练结束后冻结用于评估。

为什么需要两条互补通道。 TEAL 同时使用评审者和探索者，因为单靠任何一方都不够。以往的工具演化方法只依赖类似评审者的轨迹分析。轨迹分析擅长修复具体的执行错误，比如读错 Excel 表的表头偏移、被调用工具里的 bug；但评审者每次只看一小批轨迹，注意力集中在眼前这几个问题的修补上，不会去构建面向整个数据湖的工具。探索者弥补了这一点：它不看任何问题和轨迹，被要求以领域专家的身份为整个数据湖准备工具，扫描目录结构、文件格式和模式，提出服务于大量问题的工具，比如搜索和查找工具，其中一些以元数据目录、值索引等预计算产物为支撑，让 Worker 一次调用就能定位到相关数据。简言之，评审者问的是“看 Worker 实际是怎么做题的，哪里该改？”，探索者问的是“领域专家会为这个数据湖准备什么？”

3.2.2 不依赖标准答案的验证

一项工具改动可能通过了单元测试，却依然帮不上 Worker：工具可能有逻辑错误（比如按错误粒度读表），也可能干脆被 Worker 忽略。验证阶段负责决定每项改动的去留。由于没有标准答案，TEAL 无法用“答案是否变对”来评判改动，而是用更新后的工具库让 Worker 重跑触发改动的问题，把每次重跑与原始轨迹做三项比对。

第一项检查确认 Worker 在重跑中确实调用了改动过的工具——从没被调用过的工具不可能改善任何答案。Worker 忽略工具时，原因通常是使用说明不清楚，而不是工具本身坏了，所以 TEAL 会先请技能撰写者修订该工具的使用说明并重跑，之后才决定是否拒绝。

第二项检查确认改动没有让 Worker 更难完成问题：如果原始运行给出了答案而重跑没有，或者重跑比原始运行多用了超过规定数量的步数，就判为不通过。

第三项检查只在重跑答案与原始答案不同时进行。此时由分析员比较两条轨迹，判断哪个答案更有执行证据支撑，例如最终数值是否出现在某个工具的输出里，还是 Worker 凭空断言的。分析员并不预设原始答案正确：只有证据更支持原始答案时才判不通过；证据更支持新答案或无法判断时都算通过。

只要至少有一次重跑通过全部三项检查，TEAL 就保留改动，否则回滚。这样，验证就不再只看工具能否无错运行，而是以 Worker 自己的轨迹为证据，判断工具是否真的帮上了忙。

3.3 TEAL-Q：合成问题生成

用户写的问题稀缺，也未必拿得到：现有数据湖基准每个只有百来个问题，新上线的数据湖可能一个都没有。由于 TEAL 不需要标准答案，演化只需要问题本身。因此我们提出 TEAL-Q，以少量种子问题示范风格和难度，从数据湖中生成合成问题，每个问题分四步生成：

1. 探索并起草：检查一组相关数据文件，起草一个问题，并通过在数据上运行代码算出答案；
2. 加难：最多三轮，让问题更难，比如加入跨表关联或难以解析的文件，每轮后重新计算答案；
3. 构建流水线：把最终解法变成可执行流水线，并检查它能复现算出的答案，以确认问题确实可以从数据中解出；
4. 改写：用自然语言重写问题，保留消除歧义所必需的定义，省略 Worker 能自行发现的细节。

TEAL-Q 只把问题交给 TEAL，答案和解题流水线只用来保证问题定义清楚、可解。因此 TEAL-Q 无需验证答案是否正确——而这恰恰是合成数据生成中的一大难题。

四、实验（节译）

实验围绕两个问题：一是智能体演化出的工具是否有用；二是没有标准答案时，如何有效利用反馈。

数据集与设置。 KramaBench 把考古、天文、生物医学、环境、法律、野火六个领域的数据湖合并成一个包含 1,742 个文件的统一数据湖，分层抽样出 51 个训练任务和 53 个测试任务。LakeQA 使用其仅含表格的版本，共 130 个问题，随机划分为 50 个训练和 80 个测试任务，每个问题需要在 4,180 张表上做 1 到 5 跳推理。所有智能体都运行在 OpenHands 框架中，四个 Worker 模型如前所述，所有演化角色均使用 Opus-4.8；每批 5 个问题，探索者在第一批运行，此后每隔若干批运行一次。

主要结果。 步数预算从 10 扫到 30：

• 紧预算下提升显著。 以 Sonnet-5 为 Worker，10 步时在 KramaBench 和 LakeQA 上分别提升 22.6 和 30.4 个百分点，15 步时分别提升 9.3 和 21.7 个百分点；四个 Worker 在两个数据湖的 10 步和 15 步设置下全部有提升。八组结果中有五组，TEAL 在 15 步下的成绩持平或超过基线在 30 步下的成绩。原因在于一次工具调用取代了“定位、加载、关联相关文件”这类多步流程，基线把预算耗在找文件上，而 TEAL 能在同样的预算内完成任务。
• 宽松预算下，应当用紧预算演化的工具库。 在 20 到 30 步时，直接在部署预算下演化的工具库有时反而不如基线；而在更紧预算下演化、原样部署的工具库在每个更宽松的预算下都高于基线，通常还是三者中最好的。区别在于演化得到的反馈：预算紧时，Worker 会以显而易见的方式失败——空答案、流水线被截断、重复处理——给评审者提供了具体目标，省下的一步也会改变重跑结果，验证因此能分辨工具有用与否，短轨迹也更容易分析；预算宽松时，Worker 大多能内联解决问题，工具很少改变结果，长轨迹又让提议难以落地、重跑难以比较。步数预算的压力因此起到了替代标准答案的训练信号作用，“紧预算演化、宽预算部署”是一条实用的做法。

与现有方法比较。 本文的基线 Worker 本身已经是很强的编码智能体：在 KramaBench 上，即使只用 15 步，也大幅超过 DS-Guru 和 Smolagents（后者有 20 步）；在 LakeQA 上，30 步时超过配有人工设计工具和预建检索索引的 LakeQA Agent。TEAL 在这一强基线上仍有提升。同为无监督工具演化方法的 ISE 只要工具执行成功就保留，在同样的 Worker 和 15 步预算下，它在 KramaBench 上比 TEAL 低 5.7 个百分点，在 LakeQA 上甚至比基线低 10.0 个百分点。例如 ISE 演化出的 search_file_content 会逐行扫描整个数据湖，它在一次简单搜索中成功运行就被保留了下来，结果测试时 126 次调用里有 121 次超时，白白耗掉了步数。可见“能跑通”的工具不一定有用。

合成问题。 用 TEAL-Q 为每个数据湖生成 50 个问题，演化过程只看到这些问题、看不到答案。15 步预算、Sonnet-5 为 Worker 时，用合成问题演化的工具库在 KramaBench 和 LakeQA 上分别提升 8.95 和 20.42 个百分点，与用真实问题演化的 9.31 和 21.67 相当；四个 Worker 都是如此。这意味着在用户提出第一个问题之前，就可以开始演化工具。

消融与泛化。 去掉探索者后仍有提升，但略逊于完整 TEAL，而且不再产生以数据产物为支撑的工具；去掉演化出的技能文件后下降更多，因为 Worker 不知道该怎么用这些工具——好工具本身并不保证收益，工具和使用技能必须一起演化。给 TEAL 提供标准答案做验证，效果与无监督版本相当（+9.50 对 +9.31），说明重跑验证已经拿到了标准答案能提供的反馈；若再给出完整的标准解法，系统会造出更有针对性的工具（+12.32），比如同时按州和都市区关联、并能匹配只差标点的地名的 merge_entity_tables。在 OpenHands 中演化的工具库原样部署到 Google ADK、Prime Agent 和 Codex CLI，分别提升 16.25、2.58 和 4.35 个百分点。

五、结论

本文提出了 TEAL——一个在没有标准答案的情况下，为数据湖上的编码智能体演化工具和使用技能的框架，以及用于演化的合成问题生成方法 TEAL-Q。TEAL 同时从数据湖本身和 Worker 轨迹中提出工具，并通过重跑时检查 Worker 的工具使用和轨迹证据来验证每项改动，效果与使用标准答案验证相当。结果表明，无监督工具演化在紧预算下最有效，因为紧预算能暴露 Worker 在哪里需要工具。这样演化出的工具库在紧预算下提升了全部四个 Worker，在宽松预算下依然有效；用合成问题演化的工具库与用真实问题演化的效果相当。

局限与未来工作。 演化出的工具库会带来两类额外开销：一是加长了 Worker 每一步都要读的提示词，增加输入 token；二是 Worker 每步会做更多推理，可能是在考虑该调用哪个工具。未来可以通过更好地复用重复提示内容的缓存来降低输入开销，或者把技能内化到 Worker 中来降低推理开销。

附录要点（节译）

以数据产物为支撑的工具。 以 Sonnet-5 在 LakeQA、10 步预算下演化出的发现工具 search_dataset_catalog 为例：它的产物是数据湖的目录，一次遍历所有目录生成——根据字节内容推断每个文件的真实格式，记录表头、估算行数、每列样本和数据质量标记，并对每个目录名做向量嵌入。这次遍历约耗时 4 分钟、约 40 次批量嵌入调用，生成的 93 MB SQLite 目录与工具存放在一起，任务中从不重建。工具本身是对这个目录的排序检索：输入对所需数据的自然语言描述，返回最匹配的目录。它前后修订了 14 次，每次都能追溯到某条 Worker 轨迹；例如一次 Worker 不得不退回用 ls | grep 收集某张表的历年版本，于是工具被改为一次返回匹配表的所有版本。各次实验中，大多数产物是回答“哪个文件相关”的目录，或回答“哪个文件包含某个值”的值索引；其他产物还包括记录哪些文件属于一组及其顺序的清单，以及被误存为文本的压缩包的解码副本。

工具如何起作用。 一是省步数：测试时 Worker 在全部 80 个 LakeQA 测试任务中都调用了 search_dataset_catalog。在“2018 年奥尔巴尼县暴力犯罪率”这一题上，TEAL 每次都在 4 步内完成——一次目录查询找到县级犯罪率表，一次通过配套的 query_tabular_file 工具执行 SQL 得到 359.8，然后提交答案；基线每次要用 9 到 10 步，大多花在 find 和 grep 上，而且三次中有两次选错了犯罪数据表。二是让准确率更稳定：工具的输出每次都一致，而 Worker 的手工操作不是。在一份古气候工作簿上，inspect_excel_workbook 识别出表头在第 6 行，TEAL 每次都答对；基线有时把表头对错了行，有时干脆解析失败。

最常用的工具。 两个数据湖上用得最多的工具，回答的都是“数据在哪儿”：

LakeQA 数据湖有四千多个文件，Worker 几乎在每个任务中都会先调用目录工具，因此几乎每个解法都从查询目录开始，而不是遍历目录树。

译者注

1. “先建目录，再做分析”这条老经验依然成立。 论文演化出的高频工具几乎都是元数据目录、值索引、能处理脏表头的加载器——也就是数据治理里的数据目录（Data Catalog）和数据预处理。对已经有完善元数据管理的企业数据湖来说，最直接的启示是：把现有的目录、血缘和表结构信息以工具形式暴露给 Data Agent，往往比让智能体自己 ls、grep 高效得多；TEAL 的价值更多体现在元数据缺失、文件杂乱的“原始湖”上。
2. 落地时注意成本与边界。 文中实验在单机文件系统规模的数据湖（几千个文件）上完成，演化角色使用了顶级模型，每个工具库需要多轮重跑验证；生产环境中的对象存储数据湖动辄百万级文件，目录构建、增量更新和权限控制都需要额外设计。另外，“紧预算演化、宽预算部署”的结论很实用：调试 Agent 工具链时，可以刻意压低步数上限，让失败暴露得更明显。
3. 与华为云产品的关系。 华为云数据湖探索 DLI 提供基于 Spark/Flink 的 Serverless 数据湖分析，配合数据治理中心 DataArts Studio 的数据目录与元数据管理，正好对应论文中 query_lake_catalog、aggregate_over_files 这类工具的角色。如果要在华为云上构建数据湖问答智能体，可以把 DataArts Studio 的元数据检索和 DLI 的 SQL 查询封装成智能体工具，再参考 TEAL 的重跑验证思路，用“是否真被调用、是否省了步数”来评估新增工具，而不是只看能否跑通。

相关阅读

• 学习型基数估计如何在动态数据库里落地：SWatcher+ 的选择性监控与主动纠偏：https://bbs.huaweicloud.com/blogs/e6f5085214054f46bb2c54e52ee9fd20
• 让 AI 编程智能体替你“拆依赖”：Flask 案例研究的五种策略与五条经验：https://bbs.huaweicloud.com/blogs/709270b0c61a40a29d65af75a4a3b480