Agent发现文件名有规律后，放弃运行ls获取真实列表、直接推理下一批文件名去读取，结果读取失败——Agent“脑补文件名”这种偷懒行为，该用Skill固化流程还是用强制工具调用拦住？

摘要与核心论点

一个具备文件系统工具的智能体（Agent），在观察到 part_001.csv、part_002.csv 之后，跳过 ls 直接构造 part_003.csv 去读取，结果文件不存在、任务中断。这不是孤例，而是工具增强型大模型在“观察—归纳—外推”链条上一种具有结构性的失效模式：模型把一次有限的归纳当成了可无限外推的规则，用内部先验替代了外部事实查询。本文的主线是：“脑补文件名”本质上是“观测成本”与“推理成本”之间的错误定价，治理的关键不在于二选一，而在于建立“事实性断言必须可溯源到工具观测”的约束层——Skill 负责把正确流程固化为低摩擦路径，强制工具调用负责在事实边界上兜底，二者是互补而非替代。

本文将从失效机理、Skill 固化、强制调用、评测方法、工程落地五个层面展开，给出可操作的判定规则与代码骨架，并对“何时该拦、何时该放”的边界条件做量化讨论。文中数据除标注来源者外，均为笔者基于公开评测口径的整合或模拟数据，已在相应位置注明。

目录

一、问题定义：什么是“脑补文件名”，它为什么危险

在工具增强型智能体（Tool-Augmented Agent）的语境下，“脑补”指模型在没有调用观测类工具的情况下，基于已有上下文中的局部模式，直接生成一个本应由工具返回的事实性内容，并将其当作既定事实继续执行。“脑补文件名”是其中最常见、也最容易被忽视的一种：文件名具有强规律性，模型很容易从两三个样本中归纳出“前缀+递增序号+扩展名”的模板，进而认为后续文件名可以被确定性推导。

这种行为的危险性在于它同时具备三个特征：高置信、低成本、难察觉。高置信——模型生成 part_003.csv 时几乎不会表达不确定性；低成本——省掉一次工具往返，在延迟和 token 上都更“划算”；难察觉——如果后续读取恰好成功，错误被掩盖，模型会强化“外推有效”的策略，形成正反馈。只有当外推失败时，问题才暴露，而此时往往已经浪费了多轮交互。

需要区分两类情况。第一类是可验证的确定性推导，例如文件名由程序生成且规则在上下文中被明确声明（“文件按 001 到 100 连续编号”），此时外推的期望错误率极低。第二类是不可验证的统计性归纳，模型只看到两三个样本就假定规则成立，而真实文件系统可能存在缺号、跳号、后缀变体（.csv 与 .csv.gz）、命名空间混用等。工程上真正要治理的是第二类。本文评述：把两类混为一谈，是很多“一刀切禁用推理”方案失败的原因——过度拦截会显著抬高正常任务的成本，而治理的精度恰恰取决于能否把“可验证”与“不可验证”分开。

从任务失败的成本结构看，一次错误外推的代价并不对称：读取失败本身很便宜（一次工具报错），但模型可能因此进入“重试—再猜—再失败”的循环，或在多步任务中把错误文件名写进下游产物，造成污染扩散。在长程任务中，这类污染的回滚成本远高于一次 ls 调用的成本。这正是本文主张“在事实边界上必须观测”的经济学依据。

二、失效机理：归纳外推、观测成本与幻觉的工程学解释

2.1 归纳偏置与“少样本过度外推”

大语言模型在预训练中习得了强烈的模式补全倾向：给定序列前项，预测后项。这种能力在自然语言中是优势，在事实性查询中却可能变成缺陷。认知科学中的“归纳偏置”（inductive bias）概念指出，学习系统对假设空间有先验约束，样本越少，先验越主导。本文评述：模型的“文件名规律”假设空间极其简单（模板+序号），而真实文件系统的生成逻辑可能复杂得多（分片、重试、去重、时间戳），两者之间的失配就是失败的根源。这与经典的信息检索中“查询扩展”过度外推导致召回漂移是同一类问题。

2.2 观测成本与推理成本的错误定价

Agent 的每一步决策隐含一次成本权衡：调用工具需要一次往返（网络延迟、token 开销、上下文占用），而直接推理几乎零边际成本。若训练或提示中没有对“事实性断言”施加额外成本，模型自然会选择推理。可以把这形式化为一个简单的期望成本模型：设外推成功概率为 p，成功时节省成本 C_obs，失败时额外付出 C_fail，则外推的期望收益为 p·C_obs − (1−p)·C_fail。当 p 被模型高估（例如估成 0.95 而真实为 0.6），且 C_fail 未被显式建模时，外推几乎总被选中。治理的本质，就是校正 p 的估计偏差，并把 C_fail 显式化。

2.3 幻觉的“可溯源性”视角

学界对幻觉的讨论多集中在生成内容的真实性，但 Agent 场景提供了一个更可操作的判据：一个事实性断言是否可溯源到本次会话中的工具观测。可溯源者为“观测事实”，不可溯源者为“模型信念”。笔者认为，这一区分比“对/错”的二分更有工程价值，因为它在生成时即可判定，无需等到事后方知真假。把“事实性断言必须可溯源”作为运行时不变式（invariant），就把一个模糊的准确率问题转化成了可检查的约束满足问题。

2.4 与相关研究的对应

ReAct 范式确立了“推理—行动—观察”的交错结构，其核心贡献正是让推理锚定在观察上；Toolformer 展示了模型自监督学习何时调用工具的能力边界；而围绕工具调用可靠性的后续工作普遍指出，模型对“何时必须调用工具”的判断并不稳定。本文评述：这些工作共同指向一个结论——仅靠提示词鼓励“多调用工具”不足以形成稳定行为，必须引入结构性约束。这与软件工程中“约定优于配置”但“关键路径必须显式校验”的经验一致。

三、路线A：用 Skill 固化流程——把正确路径变成最省力路径

Skill 在这里指可复用、可组合、带明确前置条件与后置校验的任务级能力封装，它比单次工具调用粒度更粗，比自由推理更受约束。其治理逻辑不是“禁止推理”，而是“让正确流程的摩擦低于偷懒路径”。

3.1 Skill 的设计原则

一个合格的“列举并读取文件”Skill 应满足四点：前置条件显式化（必须先获得目录列表）、中间产物可检查（列表作为结构化对象保留在上下文中）、后置校验内置（读取前校验目标是否在列表内）、失败语义明确（列表为空、目标缺失时返回可区分的错误码而非笼统异常）。

skill: list_and_read
precondition: dir_listing is None
steps:
  1. listing = fs.list(dir)          # 唯一事实来源
  2. assert listing is not None
  3. targets = match(listing, pattern)  # 只从 listing 中筛选
  4. for t in targets:
       content = fs.read(t)           # t 必须 ∈ listing
postcondition: every read path ∈ listing
on_failure: return {code: "NOT_IN_LISTING", path: t}

这段伪代码的关键在第 3 步：目标集合只能从观测结果中筛选，不能由模型生成。这把“外推”从流程中结构性排除，而不是靠模型自觉。

3.2 Skill 的优势与边界

Skill 的优势是低摩擦、可复用、对模型能力要求低，且天然适配“同类任务反复出现”的场景（批处理、数据管道、日志巡检）。其边界也很清楚：Skill 依赖模型主动选择它。如果模型判断“这次规律很明显，不必走 Skill”，固化流程就会被绕过。因此 Skill 单独使用只能降低偷懒概率，不能消除。本文评述：把 Skill 当作“软引导”是准确的定位，把它当作“硬保证”则是误判。

3.3 提示词层面的 Skill 表达

在系统提示中，Skill 描述应避免“建议”“尽量”等弱约束词，改用条件触发式表述，并给出反例。例如：“当任务涉及读取多个同类文件时，必须先调用 list_and_read；禁止从已见文件名推导未见文件名。反例：看到 a_1、a_2 后直接读取 a_3 属于违规。”反例比正例更能抑制外推，因为它直接命中了模型的偷懒模式。

延伸阅读可参考 ReAct 原始工作与工具调用实践教程：ReAct 论文、Prompt Engineering Guide 的 ReAct 章节。

四、路线B：强制工具调用——在事实边界上设置硬约束

强制工具调用（forced tool use）指在运行时层面，对特定类型的事实性操作施加“不调用即拒绝”的约束。它不依赖模型意愿，而是由编排层或工具网关执行。

4.1 三种实现层级

API 层最轻，但粒度粗；编排层最灵活，可表达“先列举后读取”这类时序约束；工具网关最硬，能在读取前直接校验路径是否存在于最近一次列举结果中。笔者认为，生产系统应以编排层为主、网关层兜底，API 层仅用于极少数高风险操作。

4.2 强制调用的副作用

强制调用并非没有代价。过度强制会导致：任务延迟上升、上下文膨胀（每次列举结果都进上下文）、以及在“规则确实明确”的场景下造成不必要的往返。因此强制应按事实类型分级：文件存在性、记录 ID、外部实体属性等“不可由上下文确定”的事实必须强制观测；而纯计算、格式转换、文本改写等可由输入确定的任务不应强制。

4.3 一个网关层的校验骨架

def guarded_read(path, session):
    listing = session.last_listing(path.dirname(path))
    if listing is None:
        return err("MUST_LIST_FIRST")      # 未观测，拒绝
    if path not in listing:
        return err("NOT_IN_LISTING", path) # 外推，拒绝
    return fs.read(path)

这段代码把“可溯源”落成了可执行的不变式：读取路径必须属于本会话最近一次列举结果。它不关心模型怎么想，只关心断言是否有观测支撑。

五、对比与融合：双轨治理框架与判定矩阵

把 Skill 与强制调用对立起来是一个伪命题。二者的作用点不同：Skill 作用于“路径选择”，强制调用作用于“事实边界”。前者降低正确路径的成本，后者提高错误路径的代价。只做前者，模型仍可绕过；只做后者，系统会变得僵硬且昂贵。

据此可给出一个判定矩阵：当“事实可由输入确定”且“任务高频重复”时，优先 Skill；当“事实不可由输入确定”时，必须强制观测；两者叠加的场景（高频且事实不可确定），应以 Skill 承载流程、以强制调用做兜底，即所谓双轨。本文评述：这一矩阵的价值在于它把“该用哪个”从经验判断变成了可对照的分类问题，减少了团队内耗。

六、评测与观测：如何量化“偷懒率”与拦截收益

治理需要度量。建议定义三个核心指标：外推率（未观测即断言事实的步数占比）、外推失败率（外推断言中与实际不符的比例）、拦截收益（拦截避免的失败成本减去拦截引入的额外成本）。前两者可从轨迹日志自动统计，第三者需结合任务价值估算。

构造评测集时，应刻意设计“规律陷阱”：文件名在若干样本后跳号、混入不同后缀、出现同名不同目录等。笔者基于公开评测口径整合的一组模拟数据显示（模拟数据，非真实实验）：在含规律陷阱的文件读取任务中，无约束 Agent 的外推率约为 38%，外推失败率约为 41%；加入 Skill 后外推率降至约 19%，失败率降至约 27%；叠加网关校验后外推失败率降至接近 0，但平均往返次数上升约 22%。这组数字用于说明权衡方向，不应作为精确基准引用。

评测还应关注“污染传播”：一次错误外推是否进入下游产物。建议在轨迹中标记事实断言的来源（观测/推理），并对推理来源的断言做下游影响分析。关于 Agent 评测方法，可参考 WebArena 与 AgentBench 的任务设计思路。

七、工程落地：从提示词到运行时护栏的完整路径

落地可分四步。第一步，事实分类：梳理任务中所有事实性断言，标注其是否可由输入确定，形成“必须观测清单”。第二步，Skill 封装：把高频流程封装为带前置条件与后置校验的 Skill，并在系统提示中用条件触发式语言描述、附反例。第三步，运行时护栏：在编排层维护会话状态（最近一次列举结果），在工具网关做存在性校验，对“必须观测清单”内的操作拒绝未观测断言。第四步，观测与迭代：采集外推率、失败率、往返次数，按周复盘，动态调整强制范围。

工程上还有两个易被忽视的细节。其一，错误语义要可区分：NOT_IN_LISTING 与 MUST_LIST_FIRST 应返回不同提示，前者引导模型回到列表筛选，后者引导模型先列举。其二，上下文管理：列举结果可能很大，应做结构化摘要（只保留路径与关键元数据）并设置过期策略，避免上下文膨胀抵消强制观测的收益。

关于工具调用与函数调用的工程实践，可参考 OpenAI Function Calling 文档 与 LangChain 工具调用教程。

八、结论与展望

“脑补文件名”不是模型的道德缺陷，而是成本结构与约束缺失共同导致的理性选择。治理的正确姿势不是二选一，而是用 Skill 把正确路径变便宜，用强制调用把错误路径变昂贵，并以“事实性断言可溯源”作为贯穿始终的不变式。短期看，双轨框架能显著降低外推失败率；长期看，随着模型对“何时必须观测”的判断能力提升，强制范围可逐步收窄，转向更精细的置信度校准与自适应拦截。

展望未来，笔者认为有三个方向值得投入：一是把“可溯源性”做成模型训练信号，而非仅靠运行时补丁；二是发展轻量的事实一致性校验器，降低强制观测的延迟代价；三是建立跨任务的“规律陷阱”评测基准，让偷懒行为可比较、可回归。工具增强型智能体的可靠性，最终取决于我们能否把“该看的时候必须看”从倡议变成工程事实。

主要参考文献

文章声明

本文内容仅为作者学习、思考、经验、笔记的总结，仅供技术交流与参考。文中观点仅代表笔者个人思辨，不构成任何学术建议、商业建议或专业建议。所有数据来源已标注，引用时请以原始文献为准。文中涉及的模拟数据仅用于说明权衡方向，不代表任何真实系统的精确基准。