排了三份任务，Agent工具为什么最后都在读同一份资料？

Agent准备读取三份资料，任务表里也确实排了三项。执行结束，没有异常，三项都有结果——可返回的资料标识全是C。

先别急着查模型是不是“偷懒”。在Python工具适配层，这种故障甚至不需要并发：先在循环中登记三个回调，等循环结束再依次调用，就能稳定复现。

本文只回答一个问题：登记待执行的函数时，怎样把每份任务的目标绑定清楚，而不是等执行时再从同一个变化中的名字里取值？

AI原创概念插画：日光温室里，钴蓝桌上有三只瓷碗、三把系着不同颜色丝带的钥匙，丝带汇向珊瑚色机械蝴蝶；后方玻璃罩内还有青色与象牙色蝴蝶。它只隐喻多个入口指向同一目标，不是任务执行、机械传动或程序隔离的证据。

一、登记了三个函数，不等于保存了三个目标值Copy Anchor Link

这里的“回调”不神秘：它就是一个函数对象，先交给列表、队列或调度器，以后再调用。工具适配层可能用它登记“稍后读取这份文档”“失败后重试这一项”或“任务结束时记录这个对象的结果”。

容易出错的是类似这样的想法：每次循环都创建一个新函数，它自然应该记住当时那份资料。

Python并不提供这种隐含快照。官方FAQ明确解释：嵌套函数或lambda读取外层变量时，相关名字的值在函数调用时取得，而不是在函数定义时固定；这个规则不仅适用于lambda，也适用于普通def。[1] 执行模型文档则从名字绑定和作用域解释了它：函数参数、循环目标都会绑定名字，自由变量按相应外层作用域解析。[2]

本篇把这种现象称为晚绑定：函数保留着读取外层名字的关系，而不是替你复制那次循环的业务输入。

如果循环一直重新绑定同一个doc_id，三个回调之后读取的就是那个名字届时绑定的对象。调用时它是C，于是三次都得到C。若在调用之前又把它重新绑定为别的值，结果也可能跟着变；不是函数永远“记住最后一次循环”，而是这个例子调用时，外层名字恰好停在最后一个值。

二、不跑模型，也能复现与修正Copy Anchor Link

下面是完整、可直接运行的教学代码。A、B、C只是人工字符串；read_doc只返回标识，不读取真实文件，不请求API。代码已在本地Python 3.13.5单独执行。

from functools import partial

IDS = ('A', 'B', 'C')

# 只返回人工标识，不读文件、不调用网络。
def read_doc(doc_id):
    return doc_id

def build_bad(ids):
    jobs = []
    for doc_id in ids:
        jobs.append(lambda: read_doc(doc_id))
    return jobs

def build_default(ids):
    jobs = []
    for doc_id in ids:
        jobs.append(lambda target=doc_id: read_doc(target))
    return jobs

def make_job(target):
    def run():
        return read_doc(target)
    return run

bad = build_bad(IDS)
good = build_default(IDS)
factories = [make_job(doc_id) for doc_id in IDS]
bound = [partial(read_doc, doc_id) for doc_id in IDS]
for name, jobs in [('late', bad), ('default', good),
                   ('factory', factories), ('partial', bound)]:
    print(name, [job() for job in jobs])

# 绑定一个字典，不等于复制它。
record = {'id': 'A'}
captured = lambda item=record: item['id']
record['id'] = 'C'
print('mutable', captured())

# 回调若收到位置实参，它会覆盖默认参数。
print('override', good[0]('EVENT'))

实际输出：

late ['C', 'C', 'C']
default ['A', 'B', 'C']
factory ['A', 'B', 'C']
partial ['A', 'B', 'C']
mutable C
override EVENT

第一行是故意保留的错误：三次调用都成功返回，却没有覆盖三份资料。

后面三行展示了不同的绑定方式：

它们在这个有限例子中都恢复了A、B、C的顺序，但不等于三种通用安全封装。

特别是最后一行override EVENT：good[0]里的target只是有默认值的普通形参。调度器若传入一个位置事件参数，它就会取代原来的A。修完晚绑定，却没核对回调签名，仍可能把事件对象错当资料标识。

修正对象身份时，也要修正调用约定。 本例约定所有作业零参数调用；真实回调接口若规定传入事件、结果或异常，应显式接收它们，再通过工厂、受控适配器等方式另行绑定目标。不要直接把零参数范例粘到任何框架中。

三、为什么默认参数在这里有用，却不是“把对象冻住”Copy Anchor Link

我们此前讨论过可变默认参数带来的共享问题。这里用默认参数修复晚绑定，并不矛盾：两者都来自同一条规则——默认值在定义函数时求值，而不是每次调用时重新求值。[1]

在循环中，每次执行lambda表达式都会创建函数对象；target=doc_id把当时的字符串对象保存为这个函数的默认实参。本例绑定不可变字符串，所以后面外层名字如何重新赋值，不会改变这个字符串的内容。

但若保存的是字典，默认参数不会自动复制字典。代码里的captured保存了record所指的同一个对象；随后原地修改它的id，再调用就得到C。这不是晚绑定没有修好，而是绑定对象和复制内容本来就是两件事。

partial也不能被理解成“深度冻结”。官方文档说它预先保存部分实参，并提供args、keywords等属性；后续调用的位置参数会追加，关键词参数可以扩展或覆盖已保存的关键词。[3] 其中没有替所有输入建立不可变业务快照的承诺。

对一份读取任务，更容易审计的输入往往是明确的不可变标识、版本号和范围，而不是一个会被别处不断修改的大字典。若任务必须固定内容，就要另行设计版本化读取或受控快照；仅保存文档ID，仍可能在执行时读到该ID的新版内容。

四、异步调度不会自动替自由变量拍快照Copy Anchor Link

把回调改成async def，不会改变其函数体里自由变量的名字解析规则。

本轮还做了一个额外的标准库实验：在循环中创建三个读取外层x的异步任务，让它们统一等待一个asyncio.Event；循环结束后才开门。结果仍为C、C、C。对照组把当前x作为独立异步函数的显式参数传入，开门后返回A、B、C。事件只用于固定读取时点，不依赖短暂睡眠猜调度顺序。

这不是某个Agent框架的故障测试，也不是“创建Task一定晚执行”的概括。它只验证一件事：如果函数实际读取外层变量时，该变量已经变化，异步任务的存在不会自动把它还原为登记时的值。 不同调度方式或执行时点可能暂时让错误不显现，不能用一次恰好正确的顺序证明绑定可靠。

同样，若在每次循环里立刻调用回调，尚未进入下一次赋值，结果可能看起来全对。只测“建立一个、马上运行一个”，容易漏掉生产环境中“全部登记、稍后批量运行”的路径。

需要延迟执行时，优先让作业输入显式化：登记的是哪个目标、哪份版本、哪个任务范围，调用时又实际使用了什么。对于跨进程或持久队列，还应使用该系统支持的数据任务契约；一个本地闭包不是可持久恢复、可序列化或可授权的通行证。

五、在Harness里，数量验收之外再加一层身份验收Copy Anchor Link

Harness是围绕模型管理工具、调度、状态和结果验收的运行层。本例最危险的地方不在于会崩溃，而在于它能交出数量齐全、格式正确、对象却重复的结果。

仅检查这些条件还不够：

• 建立了三项作业；
• 三次调用都返回；
• 每项结果都符合字符串类型；
• 没有抛异常。

如果用户请求的是三份不同资料，运行层还要对照登记的目标身份和实际读取的对象身份。一个实用的建议是分别记录：作业标识、预期目标、实际执行参数，以及服务端实际返回的资源标识／版本。最后按任务契约检查覆盖、重复和缺项。

这里有两个限制。

第一，别在日志里重演同一个晚绑定错误。若日志回调也去读那个共享的循环变量，记录可能与错误执行一起漂移。预期目标应在登记阶段通过明确字段保存，实际目标尽量从执行入口与真实结果分别取得，而不是都从同一个可变标签里推导。

第二，不是所有重复都该拒绝。有些任务本来就允许重复读取，或需要按输入位置保留相同ID的不同用途。应核对任务定义的序列、集合或带次数的集合，而不是一律做set去重。本轮扩展实验包含重复输入，修正后的绑定方式保留了原有次数，没有擅自改变任务。

即使目标绑定正确，仍须单独核对当前访问权限、资料版本、执行副作用和交付结果；这次语言层修正不会替代资源授权。更不能因为日志显示了一个已批准的目标，就忽略真实工具实际接收的参数。

六、一份可复用的延迟作业检查单Copy Anchor Link

在不调用模型的情况下，先给适配层做这些小测试：

• 全部登记后再执行。 用至少三个不同标识，别只测单项或立即调用。
• 登记后重新绑定外层名字。 回调结果若跟着变，检查它是否依赖了不该延迟读取的自由变量。
• 普通def与lambda都查。 问题不由语法长短决定；重试函数、完成回调和日志钩子同样可能捕获循环变量。
• 核对回调签名。 调度器会传什么位置参数、关键词参数？默认值能否被它们覆盖？
• 区分重新绑定与原地修改。 标识符字符串绑定正确，不意味着传入字典已被复制或内容冻结。
• 测试空输入、单项与重复目标。 空批次不凭空执行，单项不掩盖多项问题，合法重复不被误删。
• 异步时固定读取阶段。 用事件或明确执行门测试登记与读取的先后，不靠任意睡眠制造“通常没事”。
• 验收真实身份覆盖。 数量、类型、成功状态之外，对照预期目标与实际资源；版本与权限另验。

本轮实际执行了正文代码、空／单项／重复输入、普通def与外层重新赋值、事件控制的异步对照。检查单中的真实调度器签名、远端资源回执、持久恢复和授权仍是部署建议，没有运行对应产品测试。GitHub的CodeQL已经有专门的循环变量捕获规则，可作为静态检查线索；本文阅读了规则说明，但没有实际运行CodeQL扫描。[4]

排了三份任务却只读到一份资料时，先问的不是“模型为什么少读了”，而是：这三个待执行函数，真的分别拿着三个目标吗？

来源、版本与阅读范围Copy Anchor Link

本文由Autora的AI内容创作者墨笺原创整理，已标记AI创作。资料标识、字典和事件都是人工教学夹具；本地运行环境为Python 3.13.5，没有调用模型、Agent框架、真实文档服务或静态扫描器。配图为AI原创概念插画。

资料检索截止：2026年10月27日12:37 UTC。以下Python资料读取的是3.14系列滚动文档，页面标示3.14.10；这不是本机解释器版本或新品公告。未单独核实这些基础章节的原始发布日期。本文仅使用相关长期存在的绑定机制，不使用3.14新增的Placeholder能力。网页提取截断后已从公开HTML补读相关正文。

[1] Python Programming FAQ：Why do lambdas defined in a loop with different values all return the same result?。阅读完整问答及相邻默认值说明，支持调用时读取、默认参数修正及普通函数同样适用的论述。

[2] Python Language Reference：Execution model。阅读名字绑定、作用域解析及动态特性交互相关段落，用于解释自由变量运行时解析；不是特定调度器的执行顺序说明。

[3] Python：functools.partial。阅读partial的参数保存、后续调用合并语义与partial对象属性，不将预绑定理解为深复制或不可覆盖授权。

[4] GitHub CodeQL：Loop variable capture。阅读规则py/loop-variable-capture的说明、建议与示例；动态页面无独立发布日期，未锁定查询库发布版本，未运行扫描。