1. 智能体对象：它不干活，只被查#

可能你会想：智能体对象夹在 Swarm 和指令函数中间，到底是干嘛的？

它什么都不干，只被读取。

把时序图放大看，Agent 只出现在两个动作里：

1
Swarm框架 → 获取agent.instructions → 智能体对象
2
          → 获取agent.model        → 智能体对象

注意箭头方向。是 Swarm 主动去取 Agent 的属性，而不是 Agent 把什么东西推给 Swarm。

1
agent = Agent(
2
    name="客服",
3
    instructions=instructions,   # 字符串 或 函数
4
    model="gpt-4o",              # 用哪个模型
5
    functions=[...],             # 挂了哪些工具
6
)

对象创建完之后就一直放在那里，等 Swarm 来读。Agent 本身不承担任何计算，作用只是把配置存住。

至于”它全程没传递东西”，这个观察是对的，而且这正是设计意图。Agent 是无状态的配置对象，可以预先创建、反复复用。如果让 Agent 自己往外推数据，它就得维护状态，还得知道当前在跟谁说话、消息发到哪了，那这部分工作就和 Swarm 重叠了。

2. 指令函数和工具函数，是两条路#

可能你会想：指令函数能不能当成自己写的 Tool 用？反正都是我写的 Python 函数。

不能。它们都是你写的函数，但走的是两条完全不同的路。

图：两种函数的调用路径。

指令函数由 Swarm 调用，返回的内容会被拼进系统提示词。工具函数由 AI 决定是否调用，Swarm 负责执行，返回的内容作为 tool 消息回到对话历史。

所以指令函数不碰数据库和 API，只负责根据上下文拼一段提示词。真正干活的是工具函数。

1
if callable(agent.instructions):
2
    instructions = agent.instructions(context_variables)  # 是函数 → 调用它
3
else:
4
    instructions = agent.instructions                     # 是字符串 → 直接用

1
def instructions(context_variables):
2
    if context_variables.get("vip"):
3
        return "你是一位 VIP 专属客服，语气要更热情。"
4
    return "你是一位普通客服，语气专业即可。"

1
if __CTX_VARS_NAME__ in func.__code__.co_varnames:
2
    args[__CTX_VARS_NAME__] = context_variables   # 向功能注入上下文
3
raw_result = func(**args)                          # 执行功能

3. 模型不是 Swarm 挑的#

可能你会想：Swarm 拿到提示词和工具之后，会判断该用哪个模型吧？

不会。模型名是 Agent 自己配好的，Swarm 只是把它读出来。

1
agent = Agent(model="gpt-4o", ...)      # 这里就定死了
2
# Swarm 内部： chat.completions.create(model=agent.model, ...)

Swarm 把 agent.model 直接填进请求里，中间没有挑选的动作。

模型唯一会变的情况是 handoff：当前 Agent 把对话交给另一个 Agent，Swarm 更新 active_agent，下一轮循环重新去读新 Agent 的 agent.model。变的原因只是换了 Agent。

4. 转交给哪个 Agent，谁说了算#

可能你会想：AI 模型和智能体对象，谁才是 Agent？又是谁判断什么时候调用哪个专家？

智能体对象才是 Agent。AI 模型是它调用的推理引擎。

第二问没有单一答案，因为这件事被拆成了三段：

图：转交过程中的三个环节。

AI 模型看不到”会转到哪个 Agent”。它能看到的只是这个函数的名字和文档字符串，所以它决定的是调不调，至于调完之后去哪，不归它管。

这点很容易说糊涂。我第一次讲的时候直接说”是 AI 决定找哪个专家”，后来发现不对。AI 模型决定要不要触发转交，程序员决定转交给谁。

如果程序员不写那个函数，AI 模型就永远转交不了，因为它的工具列表里没有这个选项。

我感觉还说先把结论给你们，下面的定义有点太多了 如果是LangChain的多轮对话记忆 你只是想让 Chatbot 记住刚才聊了什么，实现多轮连续对话。 你的需求是标准的“记住聊天记录”，不需要在对话历史之外维护额外的业务变量。 作为快速原型，先用一行代码验证对话记忆的效果。#

如果需要操作“上下文变量”（自定义 State）的场景： 多步骤任务：Agent 需要在运行中记录中间结果（如先搜资料 A，再结合资料 B 写报告），这些中间变量必须存在 State 中，供后续步骤读取 动态行为：你需要根据用户是否登录、对话轮数等变量，动态调整系统提示词或可用工具。 工具交互：工具函数需要读取或写入会话级别的特定变量（如当前任务 ID），而不仅仅是收发消息。#

1. 你传进去的字典，Swarm 会先复制一份#

1
def run(...):
2
    active_agent = agent
3
    context_variables = copy.deepcopy(context_variables)   # ← 这里
4
    while ...:
5
        completion = self.get_chat_completion(
6
            agent=active_agent,
7
            context_variables=context_variables,           # 传的是副本
8
            ...
9
        )
10
        if message.tool_calls:
11
            context_variables.update(partial_response.context_variables)
12
    return Response(context_variables=context_variables)   # 返回被改过的副本

你传进去的那个字典不会被改动。Swarm 在 run 开头做了 deepcopy，整个循环里传的都是副本；工具函数如果写回了新值，改的也是副本。循环结束时返回给你的，是这份被改过的副本。

想持久化这次运行产生的新数据，得自己从 response.context_variables 里取出来存。

2. 它只活在一次 run 里#

它就是个普通 Python 字典，client.run() 开始时创建，运行一结束就没了。框架不负责持久化。

可能你会想：用户之前说过一些信息，已经被多 Agent 共享了，我现在关掉网页、刷新重新进来，Agent 还记得吗？

不记得，刷新之后共享状态就清零了。

context_variables 只活在单次运行的内存里。刷新网页意味着原来的进程结束了，内存里的字典被回收；新会话调用 client.run() 时你不主动传，Swarm 拿到的就是空字典。

想要”还记得”，这些动作都得自己做：

1
# 存：上次运行结束
2
response = client.run(...)
3
db.save(conversation_id, response.context_variables)
4

5
# 取：新会话开始
6
context = db.load(conversation_id)                     # {"name": "小明", "user_id": 456}
7

8
# 传：重新塞回去
9
response = client.run(
10
    agent=agent,
11
    messages=load_messages(conversation_id),           # 对话历史也要一起恢复
12
    context_variables=context,                         # 关键：手动传回
13
)

这里 messages 和 context_variables 是两回事。如果你把 messages 恢复了，AI 能从文本里看到之前聊过什么，但那是 AI 在读文本，不代表 context_variables 被恢复了。

1. 它们负责的事不一样#

LangChain 的 Memory 关心的是数据存在哪里、怎么持久化。Swarm 的 Context Variables 关心的是同一次运行里，不同组件怎么拿到同一份数据。

图：单次 client.run() 里，用户代码、Swarm 框架、AI 模型、功能代码之间如何传递消息和 context_variables。

平时大家爱把这两件事概括成”一个管传，一个管存”。这么说确实好记，但容易让人以为 context_variables 不存东西。它其实是存的，context_variables = {"user_id": 456} 就是把 456 存了起来。

所以要真正分清楚，还是得看这份数据能活多久、谁能看见它，以及运行结束后由谁负责把它留下来。

图：两种「记忆」的存活范围。

2. 纠错（I’m Sorry）#

我前面说”LangChain 持久、Swarm 临时”，这个说法不对。

LangChain 的默认实现 ConversationBufferMemory 把数据存在内存里，进程重启、刷新页面同样会丢，默认并不持久。只有当它挂上持久化后端（RedisChatMessageHistory、PostgresChatMessageHistory 这类）之后，数据才写进外部存储，才能跨会话恢复。

“可以持久”和”默认持久”是两回事。真实的区别在于框架有没有给你现成的方案：

3. 那到底该用哪个#

“既然都要自己持久化，那我直接用 LangChain 的 ChatMemory 不就行了”。这个判断其实不太成立，因为它们解决的不是同一个层面的问题。

如果你要的是对话历史的持久化，比如刷新后还能看到之前聊过什么，那 LangChain 的 Memory 加持久化后端确实更省事。如果你要的是多 Agent 之间共享结构化状态，比如 user_id、账户类型这种字段，又不想把它们塞进对话文本里，那 context_variables 是原生设计，LangChain 反而没有直接对应的机制。

两者不是替代关系。你可以在 LangChain 里也维护一份类似的共享字典，或者在 Swarm 外面套一层 LangChain 的持久化消息历史。

4. 什么该进 messages，什么该进 context_variables#

可能你会想：假设用户一口气说了”我叫小明，我在 A 高中上学，周末要和小美去约会，晚上还得写作业，帮我找个近点的好吃的店”，这段东西我该往 context_variables 里塞什么？

这段文本本身，什么都不用塞。

图：两种数据的去向。

把完整对话交给模型，它自己就能读出用户叫小明、在 A 高中、赶时间。这些信息不需要你提前结构化进字典。只有当某个信息需要被跨 Agent、跨函数显式传递时，才需要把它放进 context_variables。

这里最关键的一点是，“提取”这个动作是开发者做的，Swarm 不参与。它不会替你从原文里挑字段，只负责把字典传进 run()、handoff 时带着它走、把工具函数写回的值合并进去。

字段的来源通常有几种：你自己写规则提取、调一次 LLM 做结构化抽取，或者让工具函数通过 Result 写回。

5. 两边的边界都在哪#

Context Variables 这边不太能指望的：

• 不自动提取，里面放什么完全由你和你的函数决定；
• 只适合预设场景，你得提前知道有哪些字段要共享，比如客服、订票、账户查询这类流程固定的业务；
• 不适合理解开放文本，用户输入完全开放时提前定义字段是徒劳的，这种场景交给 messages；
• 不持久化，运行结束就没了；
• 容量小，官方定位是 KB 级，塞大段文本会拖慢执行，因为它会被传给 instructions 函数和所有工具函数。

Memory / ChatMemory 这边不太能指望的：

• 持久化需要配置，不是自带的；
• 不负责跨 Agent 共享，LangChain 的多 Agent 通常走工具调用和任务分发，各子 Agent 有自己的上下文，要共享得自己在应用层搭桥；
• 存全文会膨胀，对话越长，token 成本和延迟越高，通常还需要自己裁剪、摘要或检索；
• 它管”说过什么”，不管”关键字段是什么”，想要一个可靠的 user_id，还是得自己结构化出来。

6. 实际项目里怎么搭#

1
# 1) 取出「说过什么」和「关键字段」，这两份都由你自己持久化
2
messages = load_messages_from_db(conversation_id)
3
context = load_context_from_db(conversation_id)   # {"user_id": 123, "name": "张三"}
4

5
# 2) 关键字段交给 Swarm，让它在本次运行里自动传给各 Agent / 函数
6
response = client.run(agent=agent, messages=messages, context_variables=context)
7

8
# 3) 运行结束，两份分别存回去
9
save_messages_to_db(response.messages)            # 对话全文 → ChatMemory 的职责
10
save_context_to_db(response.context_variables)    # 关键字段 → 自己持久化