智能体循环：确定性上下文与自由长上下文对比

一、对比背景

近年来，基于大模型的智能体（Agent）逐渐从“单轮问答”走向“多轮循环”：模型在循环中反复执行“规划—调用工具—观察结果—修正方向”，直到完成任务。这类循环式工作流让智能体具备了处理长任务的能力，但也暴露出一个根本问题——上下文窗口是稀缺资源，而模型对超长上下文的注意力是有损的。

从第一性原理出发可以得出两个基本事实：其一，上下文窗口容量有限，不可能无限制地把所有历史信息塞进去；其二，即使塞进去，随着轮数增加，早期信息在注意力分配中会被不断稀释，相当于发生了“有损压缩”，模型可能出现目标漂移、遗漏约束，甚至凭空捏造并不存在的结果。

围绕这个问题，工程实践中形成了两条典型路线：一条是方案A——像操作系统管理内存那样，对上下文窗口进行确定性的显式分配；另一条是方案B——把每轮产生的思考与工具结果全部追加进对话历史，依赖模型自身的隐式记忆能力。本文将围绕这两类方案展开系统对比。

二、对比对象定义

方案A：确定性上下文管理

核心思想是把上下文窗口当作显式管理的内存空间。工程上通常包含两类构件：

• 查找表：以结构化方式记录任务状态、已产出的文件索引、历史工具结果索引等元信息，相当于一本“台账”；
• 固定提示词锚点：将角色定义、硬性约束、当前目标等关键信息以固定条目形式每轮注入，构成一个稳定的参考框架。

每轮循环由调度组件决定“本轮上下文数组里放什么”：只将与当前步骤相关的条目按确定性规则注入，工具结果先落入查找表，而非全量堆积在对话历史中。这样做的直接收益，是模型在需要检索历史信息时有明确的“地址”可查，从而提高搜索与工具调用的命中率。

方案B：自由长上下文堆叠

方案B不引入额外调度组件，循环的每一轮把模型的思考、工具调用结果原样追加到对话历史，上下文随轮数线性增长，依赖模型自身的注意力机制去“记住”全部信息。它的特点是实现极简、贴近模型原生用法，但把记忆质量完全托付给了模型本身。

三、相同点分析

尽管工程形态差异明显，两类方案在多个层面是一致的：

1. 目标一致：都是为了驱动模型在多轮循环中完成复杂任务，最终交付物都是任务结果而非单轮回答。
2. 基本循环结构一致：都遵循“思考—行动（工具调用）—观察—再规划”的循环范式，都依赖同一套模型推理能力、上下文窗口机制与工具调用接口。
3. 都需要基础工程配套：日志记录、异常处理、循环终止条件、结果校验等基础设施在两类方案中都是必需的。
4. 都受上下文窗口物理上限约束：无论哪种方案，单次推理可用的窗口容量是相同的，差异只在于如何使用这份容量。

四、核心差异分析

1. 技术架构

方案A在“模型调用”之外引入了明确的调度层：上下文管理器负责分配与回收，查找表负责持久化中间产物，提示词锚点负责稳定性。系统边界清晰，每个组件可以独立测试。方案B则几乎没有额外组件，架构成本最低，但状态信息隐式分布在不断增长的历史中，没有显式的系统边界。

2. 功能能力与长任务表现

方案A通过查找表和锚点，使跨多轮的约束保持成为工程保证，而不是模型自觉：例如“不要修改某个目录”这类硬约束，可以每轮以固定条目重新注入，避免长循环后被遗忘。方案B在短任务中表现往往足够好，但任务轮数一多，早期指令相当于被有损压缩，常见表现包括目标漂移、重复执行已完成的工作，甚至“虚构”出并不存在的结果。

3. 性能表现（定性维度）

从可观察的行为趋势看：

• 工具命中率：方案A注入了结构化索引，模型检索历史信息时更像“按地址读取”；方案B更像“在整段历史里凭印象翻找”，命中率随历史变长而趋于下降。
• Token消耗：方案A每轮注入的内容与当前步骤相关，总量可控；方案B的上下文随轮数线性膨胀，长任务的单位轮次推理成本持续上升。
• 稳定性：方案A每轮输入是确定性构造的，相同状态应得到可复现的行为；方案B的行为受历史顺序、长度等隐式因素影响，波动更大。

需要说明的是，以上为定性规律，具体幅度与模型版本、任务类型相关，应以实际测试为准。

4. 接入与开发成本

方案B几乎零改造，任何具备循环调用模型能力的程序都可以直接运行。方案A则需要前期投入：设计任务状态模型、定义查找表结构、编写并调优锚点提示词、实现分配与淘汰策略。前期成本高，是方案A最主要的接入门槛。

5. 成本结构

方案A是“前期重、运行期轻”：工程投入集中在设计与实现阶段，运行期token消耗可控，失败重试的代价也较低。方案B是“前期轻、运行期重”：起步快，但长任务中token开销与重试成本会随轮数累积，隐性成本不可忽视。

6. 稳定性与可审计性

方案A每轮注入的内容有明确清单，便于回归测试、行为审计与故障回放，这与企业级应用对合规审计的普遍要求是契合的。方案B的输入是完整历史流，复现某次异常需要还原整段上下文，审计成本高。

7. 运维复杂度

方案A的运维重点在查找表一致性、提示词版本管理、状态序列化兼容性，属于“常规但必须持续维护”的工程项。方案B运维项少，但故障定位困难——问题往往埋在超长历史中，排查如同大海捞针。

五、关键差异总览

维度	方案A：确定性上下文管理	方案B：自由长上下文堆叠
架构复杂度	需要调度层、查找表、锚点提示词	极简，无额外组件
上下文来源	按确定性规则分配的相关条目	全量历史追加
长任务稳定性	约束可工程化保持	易漂移、易遗忘
工具/检索命中率	依赖索引，趋势更稳定	随历史增长趋于下降
Token消耗趋势	与当前步骤相关，总体可控	随轮数线性膨胀
可审计与复现	输入清单明确，易回放	需还原整段历史，成本高
接入成本	前期设计与改造投入大	接近零改造
运维重点	查找表一致性、提示词版本管理	故障定位困难
适用场景	长任务、高可靠性、企业级应用	短任务、原型验证

六、示意性伪代码对比

方案B（自由堆叠）：

history = [system_prompt]
while not task_done:
    plan = call_model(history)          # 模型基于全量历史决策
    obs  = run_tool(plan.tool_call)
    history.append(plan, obs)           # 无差别追加，上下文持续膨胀

方案A（确定性分配）：

lookup = build_lookup_table(task)       # 状态/文件/结果索引
anchor = load_anchor_prompts()          # 固定约束与角色锚点
while not task_done:
    ctx = allocate(anchor,              # 每轮确定性构造上下文数组
                   lookup.query(current_goal),
                   budget=token_budget)
    plan = call_model(ctx)
    obs  = run_tool(plan.tool_call)
    lookup.commit(obs)                  # 结果入表，而非全量入上下文

两者差异的本质在于：中间结果存放在哪里、由谁决定模型“看到什么”。

七、典型场景选择

• 原型验证、一次性脚本、探索性实验：任务轮数少、可靠性要求低，方案B的零改造优势最明显。
• 长周期编码任务、批量数据处理、多阶段工作流：轮数多、中间产物多，方案A通过查找表管理状态，能明显降低漂移与重复劳动的风险。
• 企业级生产应用：通常有审计、可复现与成本控制要求，方案A的确定性特征更契合。实践中也常将两者结合——主流程采用确定性分配，轻量子任务保留自由堆叠，以平衡工程成本与稳定性。

在百度智能云等提供大模型服务与AI应用开发能力的平台上构建此类应用时，上述两条路线均可落地：可以结合平台提供的模型推理、日志监控等通用能力，将方案A的查找表与分配策略实现为应用层组件；方案B则可直接基于对话接口循环调用实现。

八、选型建议

选型不应脱离具体条件，可参考以下判断路径：

1. 看任务长度：单轮或少轮即可完成的任务，优先方案B；预期超过十余轮、且中途结果会被后续依赖的任务，方案A的收益开始显现。
2. 看可靠性要求：面向生产、需要可审计与可回放的场景，确定性分配几乎是必选项；探索性场景则可先从方案B起步。
3. 看团队工程能力：方案A要求团队具备状态建模与提示词工程经验；若团队规模小、运维能力有限，可以从简化的方案A起步，例如先只实现查找表，再逐步补充锚点与淘汰策略。
4. 看成本结构：运行量大、任务周期长的业务，方案A在运行期的token节约通常会覆盖其前期投入；低频任务则未必。

需要强调的是，方案A与方案B并非互斥：方案A可以兼容方案B作为退化模式——当查找表命中失败时，回退为把相关历史全量注入，是一种常见的工程兜底。

九、迁移与使用注意事项

若计划从方案B迁移到方案A，建议关注以下事项：

1. 先复盘失败案例：梳理既有任务中因上下文丢失导致的漂移、幻觉问题，明确查找表需要覆盖哪些信息类别。
2. 定义状态模型：中间产物的命名、版本、生命周期要有明确约定，避免查找表本身演化成新的“超长上下文”。
3. 提示词锚点版本化：锚点变更应纳入版本管理与回归测试，防止一次措辞调整破坏原有行为。
4. 灰度对比：用同一批历史任务在两种方案下做对照运行，观察工具命中率、token消耗与任务完成率的变化，再决定推广范围。
5. 兼容性处理：已有的工具调用接口、结果格式需适配查找表的提交规范；序列化格式变更要考虑旧数据兼容。
6. 监控指标：建议跟踪每轮注入token量、查找表命中率、循环终止原因分布等指标，作为持续调优依据。

反向迁移（从方案A退回方案B）的风险则在于：长任务稳定性会重新依赖模型自觉，此前通过工程手段消除的漂移与幻觉风险可能回归，需重新评估。

十、总结

从第一性原理看，两类方案的分野源于一个根本问题：中间状态由谁维护。方案B把记忆交给模型的注意力机制，实现简单，但长任务下不可避免地经历有损压缩；方案A把记忆交给显式的工程组件，用确定性分配取代“希望模型记得”，以更高的前期投入换取长任务下的稳定性、可审计性与可控成本。决策时，建议围绕任务长度、可靠性要求、团队工程能力与成本结构四个条件综合判断，并优先考虑两者结合的混合形态——这往往比非此即彼的选择更贴近工程实际。