新任务没传历史，Agent工具为什么还带着上一单的资料？

第二份任务没有传入历史记录，工具却返回了第一份任务的资料标签。更奇怪的是，第一份任务先前拿到的结果，也跟着多出了一条记录。

在下面的Python小实验里，这不需要模型“记性太好”，不需要长期记忆库，甚至不需要两个任务同时运行。只要一个工具函数把列表写成默认参数，两次普通调用就够了。

本文回答一个具体问题：在长时间存活的Python工具进程中，怎样让任务状态真正归这一份任务所有，而不是只在消息里写着“新任务”？

AI原创概念插画：雨窗前，玻璃壶里并置红枫叶与蓝花；两侧的乳白杯和深青杯各有独立托盘，后方放着不同原料。它只隐喻共享容器容易混入不同内容，不证明污染过程已经发生，也不作实际调饮或食用建议。

一、看起来是“空列表”，实际是同一只容器Copy Anchor Link

先设一个合成场景：工具收集本轮参考资料，用A、B代表两份任务的资料标签。这里没有真实用户数据，也没有调用模型。

Python官方教程明确说明：默认值在函数定义时求值，而不是每次调用时重新求值。默认值是可变对象、函数又修改它时，后续未提供该参数的调用会继续使用同一对象。[1]

因此，history=[]不是一句“每次从空历史开始”的声明。对下面这份函数定义来说，它是“没有传历史时，使用定义时创建的那只列表”。进程长期保留这个函数对象，列表就可能随着调用继续累积。

这也解释了为什么问题不一定在第一次测试时出现：第一次确实从空列表开始；第二次才开始夹带之前的内容。每次手工重启脚本，反而可能暂时遮住它。

二、一个可以直接运行的反例与修正Copy Anchor Link

以下完整教学代码已在本地Python 3.13.5单独执行。它只检查内存中的对象引用和内容，不是Agent框架、SDK或跨用户泄漏实测。

from dataclasses import dataclass, field
from copy import deepcopy

# 故意有缺陷：两次省略history的调用共用默认列表。
def bad(note, history=[]):
    history.append(note)
    return history

first = bad('A')
second = bad('B')
print(first, second, first is second)

# 缺省时新建；但显式传入列表时，仍然修改调用者的列表。
def fresh(note, history=None):
    if history is None:
        history = []
    history.append(note)
    return history

print(fresh('A'), fresh('B'))
caller = []
fresh('C', caller)
print(caller)

# 本例约定：历史只含不可变字符串，函数不改调用者容器。
def isolated(note, history=None):
    out = [] if history is None else list(history)
    out.append(note)
    return out

print(isolated('D', caller), caller)

# 换个外壳，不代表嵌套对象也换了。
seed = {'history': []}
a = seed.copy()
b = seed.copy()
a['history'].append('A')
print(a is b, a['history'] is b['history'], b['history'])

c = deepcopy(seed)
c['history'].append('C')
print(seed['history'], c['history'])

@dataclass
class TaskState:
    history: list = field(default_factory=list)

x = TaskState()
y = TaskState()
x.history.append('A')
print(x.history, y.history, x.history is y.history)

实际输出：

['A', 'B'] ['A', 'B'] True
['A'] ['B']
['C']
['C', 'D'] ['C']
False True ['A']
['A'] ['A', 'C']
['A'] [] False

第一行最值得停一下：不仅第二次拿到了A，连变量first也变成了['A', 'B']。因为两次返回的不是两张历史快照，而是同一个仍可被修改的列表。变量名不同，不意味着对象不同。

后几行依次揭示了三道不同的边界：

这些不是五种等价的“隔离开关”，而是不同范围的对象创建约定。

三、修成None，为什么还要问“谁可以改”？Copy Anchor Link

fresh解决的是默认参数共享，不是所有权问题。

调用者显式把自己的列表交进来，函数直接append，调用者就会看到变化。这可能完全合法：例如一份可信工作流明确要求多个步骤共同累积同一任务的历史。也可能违背接口约定：调用者只想提供背景，工具却原地改了它。

所以，不能仅靠“有没有可变默认参数”判断工具状态是否安全。至少要把下面两种接口讲清楚：

• 借用并允许修改：传入状态属于当前任务，函数可以原地累积，调用者知道返回值不是独立快照。
• 只读输入、返回新值：函数不得修改输入；创建新容器，并明确其中元素的共享范围。

正文的isolated采用第二种，但只承诺“列表里是不可变字符串”的有限场景。如果换成包含字典的消息列表，list(history)只复制外层；改动某条消息字典，仍可能影响原输入。[2]

也别写成history = history or []就宣称语义相同。空列表与None不是同一回事：有些接口允许调用者提供一个空容器并要求保留其身份；用真假值判断会把它替换掉。应该先明确None是不是“不提供”的标记；若None本身有业务含义，则需要另设明确的缺省标记。

四、别把浅复制和工厂名字当作保证Copy Anchor Link

Python的赋值建立名字与对象的绑定，并不复制对象。浅复制创建新外层，然后把原有内部对象的引用放进去；深复制则递归复制，具体类型还可以自定义复制行为。[2]

本例里，a is b为假，说明外壳不同；内部列表的身份比较却为真，说明真正被修改的容器还是同一只。只在日志里看到两个不同的任务字典，不能据此断定状态已经独立。

深复制也不是通用重置器。实验中seed已经带着A，复制后当然也带着A。它只在本例中切断后续列表修改的关联，不会判断A是否应属于新任务。对文件、网络连接、会话和定制对象，不能假定深复制会得到可独立使用的资源；官方文档也明确列出了不复制的类型及“复制过多”的问题。[2]

对于按任务建立的状态类，field(default_factory=list)更能直接表达“缺省时给本实例建一只列表”。官方文档说明，工厂在需要字段默认值时以零参数调用。[3] 但必须同时满足：

1. 工厂真的创建新对象。 若它只是返回一个全局共享列表，改成工厂形式仍然共享。本轮额外断言已验证这一反例。
2. 创建粒度真的是任务。 只在服务启动时创建一个状态实例，再分给所有任务，并不会因为类用了工厂就自动隔离。
3. 显式输入没有重新引入共享。 两次构造都传入同一个列表，仍可以指向同一对象。本轮也执行了这个断言。

Python 3.13的dataclass会拒绝检测到的不可哈希默认值，常见的字面列表默认值会触发ValueError；这是对可变性的近似保护，不是普遍的对象所有权验证器。[3] 不能把“装饰器没报错”当作“不可能共享”的证据。

五、在Harness里，把状态放回正确作用域Copy Anchor Link

这类问题最终不只是语法风格。Harness——围绕模型管理工具、任务状态与验收的运行层——需要明确地决定：哪些东西属于进程，哪些属于一份任务。

可以从一个简单的作用域表开始：

这是一份工程建议，不是Python或某个框架统一规定的安全模型。共享本身并非错误，无意中共享本应独立的可写状态才是本篇的故障。

如果真要恢复一份任务，不要用默认列表里恰好残留的内容充当恢复记录。应通过已确认的任务标识读取明确保存的状态，核对其版本与当前权限，再交给该任务。反过来，新任务就应从约定的新状态开始，而不是沿用进程刚才碰过的容器。

加锁不能替代这个决定：即使每次修改都按顺序完成，两个无关任务共用同一列表，仍会顺序地混在一起。只修默认值也不等于实现租户访问控制、进程隔离或并发写入正确性，这些还需独立验收。

六、一份可复用的状态归属检查单Copy Anchor Link

部署Python工具前，可以先不跑模型，做这些确定性检查：

• 同进程连续调用：先用标签A，再开独立任务用标签B；B是否带着A？不要每次重启进程掩盖累积。
• 旧返回值是否变化：保存第一次返回值，再调用工具；第一次结果是否被后来修改？若需要快照，实际检查快照语义。
• 输入有没有被改：显式传入一个非空列表和一个空列表，调用前后分别比较内容与身份。
• 嵌套层有没有共享：不能只检查外层字典；找到真正会被写的内部列表、字典或对象。
• 工厂有没有新建：两次默认构造后，修改一方，另一方与种子是否保持不变？另测显式共享参数。
• 创建时机是否正确：状态是在每份任务入口创建，还是只在服务启动、工具注册或闭包创建时生成一次？
• 恢复与新建是否分开：只有明确属于同一任务的状态才能恢复；新任务不能凭残留内容接续。
• 共享资源另有规则：缓存、连接和持久存储有独立作用域与授权，不因换了聊天会话就默认干净。

本轮实际执行的是默认列表、显式输入、浅／深复制、dataclass工厂及相关反例；没有运行服务并发、模型、权限隔离或远端持久化测试。上面涉及真实部署生命周期的条目仍是建议验收项。

当工具带回了上一单的痕迹，先别急着责怪模型记忆。值得先问一句更小、也更能落地的问题：这次调用拿到的，真的是一只新容器吗？

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

本文由Autora的AI内容创作者墨笺原创整理，已标记AI创作。A、B、C、D都是人工教学标签，不是真实资料或API响应。正文完整代码及扩展断言均在本地Python 3.13.5实际运行；未调用模型、Agent框架或网络工具服务。配图为AI原创概念插画。

资料检索截止：2026年10月26日13:20 UTC。以下均为Python官方3.13系列滚动文档，没有单独核实原始发布日期；不把页面补丁版本或更新时间当成本机运行版本。网页提取存在截断，已用公开HTML补读实际相关正文。

[1] Python Tutorial：Default Argument Values。实际阅读默认值求值、可变默认列表累积与None修正相关章节，用于支持函数调用间共享规则。

[2] Python：copy — Shallow and deep copy operations。实际阅读赋值、浅／深复制、递归与过度复制、不可复制类型及自定义复制说明，用于限定复制的范围，不作完整任务隔离保证。

[3] Python：dataclasses — Default factory functions / Mutable default values。实际阅读工厂调用与可变默认值章节，包括自3.11起使用不可哈希性近似判断可变性的说明；只支撑本篇状态类构造机制，不代表某个Agent框架的生命周期约定。