本文整理了几个关于 Agent 架构优化的设计想法。这些想法彼此之间不一定兼容也不保证实际可行或内容唯一它们大多只完成了一半尚未完全落地。以下内容仅代表个人观点。由于编者是一名中学生能力与时间有限不足之处还请见谅。想法一用树形上下文彻底替代线性上下文这个想法的核心是彻底替代而不是补充。为什么我认为它既必要又可行呢假设你一个人用 Agent 独立开发整个项目你肯定要实现 UI、后端等部分后端可能还分各种组成。如果你只用主 Agent 写代码当然你也可以用多个 Agent 写不同部分但我不建议这样你确实能按先后顺序让 Agent 写完框架但细节和 BUG 呢你可能会一会让模型补这一块一会让它补那一块可不同部分的记忆不一定是这一块所需要的这会产生巨大浪费而且模型的上下文记忆被稀释产出质量也难以保证。我的想法是利用一棵树每次传入树的结构不包括节点内容与最近几个被动过可能是修改或新增的节点的内容。一个节点就是一份记忆节点下还可以有孩子也就是一份记忆下还可以有记忆这样天然也能形成部分概括。模型可以通过工具调用这里用这个词不准确因为这是原生能力来查询、修改节点内容也可以删除、禁用或修改置信度我们可以用置信度表示一个节点的可信度也可以直接删掉这个节点再建一个更可信的这里我也不确定哪一种最优。由于我们每次都预传三个节点内容模型不会出现过大的断层。注意这个树形上下文只是为了取代线性上下文不代表它会取代记忆概括这些东西。想法二树形规划路径这个想法更加游离我也不确定是否要用它取代 Agent 的某个部分可能更多是作为任务、探索等模式存在。这个想法是怎么来的呢我一直在思考一个问题我们本质上希望 LLM 返回的内容被“框定”在一个可靠范围内降低熵。我们给上下文、提示词、约束、示例本质上都是为了让 LLM 不乱输出而是落到一个可控、可靠、可用的区域里。如何理解呢上下文可以让模型知道你现在具体是什么场景。你可能会想那我的项目具体的接口没有算进去呀具体某个变量模型也不知道呀。解释这里的场景是广义的包括你项目的具体内容。那本质上我们的最终目标就是让 LLM 输出的内容落到我们想要的范围。如果能做到这一点我们可以用任何手段。但是本地运行模型成本过高所以我们的手段还有一个限定必须被 LLM 调用支持。但是如果我们把一个任务看作一个出发点、一个目标和过程那么就可以把整个任务看作一个迷宫这很像 GitHub 上 princeton-nlp 的一个叫 tree-of-thought-llm 的仓库但与它不同的是本文有更深的思考以及一些可能可行的落地方案来填充这个框架的细节。那么我们自然就可以想到它是一棵树根节点是初始任务。每个节点是一次中间状态。每条边是一次扩展或一步推理。叶子节点是候选结果。既然是树就可以用搜索策略例如 BFS任务比较简单时优先考虑、DFS 等。但关键不是固定用哪种而是根据任务结构动态选择也可以混用。那我们凭什么认为它可行、成本能降下来呢实际上我们会发出很多次 LLM 调用其中给 LLM 的一定会输入前面的路径。而这棵树中的路径共享大量前缀它自然能吃到缓存命中率带来的成本降低。但要注意剪枝不是万能的它只是一种优化。更关键的是我们要进行剪枝减少 LLM 调用也必须进行剪枝以防根本不可行的方案污染。那如何有效剪枝这也是 tree-of-thought-llm 不足的一点就成了最关键的问题。首先我们要明确不同策略下的剪枝策略不同我给出的只是一个较为通用的底层方案。父路径如果已经通过验证那么它上面的路径都是可行的。现在的问题是如何判断当前这一步是否可行我认为我们不能像 tree-of-thought-llm 一样用同一个模型继续评估而且光评估、没有任何作为也是无效的。实际会遇到各种问题如果我们不去验证就会产生很多可能的路径这样树形思考也没有什么优势。具体来看判断这一步是否可行等价于父节点可行 当前步可行的证据 评估器确认。我们当前步可行的证据要从哪来呢由于我们这一条路径本质上就是一条非常完整的途径它解决了从 0 到 1 的问题而恰恰这一步是最难的这里有点不准确不是从 0 到 1没那么少。我们可以通过廉价的小模型去进行一些简单的工具调用验证是否可行。但是如果小模型我们依然使用云端服务那么成本永远都降不下来所以我们必须本地跑一个小模型且不用很大的参数量也许 8B 就足够了。因为这个小模型负责的是一些验证而不是从 0 到 1也不是直接实现、去完成。模型的问题解决了但模型之间可能“串通”且 8B 模型的思维能力不强也无法自我检查。我们无法知道小模型进行的计算是否是关于这个任务的。那决策器我们要用什么呢这里有一类很特殊的模型它不输出自然文本。它内部没有思维链。它确实是深层的神经网络。它成本非常低。在封闭、有事实支撑的判别任务上其准确率可以接近 LLM 打分。它本质上是一种判别式验证器也就是决策模型Decision Model或者叫 System One 模型、类型化决策模型Typed Decision Model或结构化分类器Structured Classifier。它通常一次前向传播输出 logits/分数/概率概率可表示为百分比二分类可阈值化为是/否多分类可给出选项概率。这个“是/否”通常是后处理或 API 封装不是自回归生成的文本 token。这类模型我们可以选择云端成本也很低省事但是不一定数据安全且依然有成本也可以选择开源参数的本地部署大小不大它的参数量通常与嵌入模型处于同一级别这就意味着本地部署完全可能。它的优势成本极低。可以高频调用。没有解码延迟。可以多模型投票。可以做多粒度判断。它的局限不能生成证明义务。不能给反例。不能解释为什么。不能替代工具验算。没有事实支撑时它和瞎猜差不多。但是在我们这个场景之下它的局限已经被小 LLM 模型补掉了留下的就是优势。但小模型与决策模型的稳定性也让我们担忧。由于成本较低我们自然可以多跑几次避免偶然性。以下是想法二我与 DeepSeek 探讨的方案 Markdown 原文。需要注意它不是最后一版所以与本文内容略有不同仅供参考。# 我的想法基于搜索树、前缀缓存与廉价验证器的低成本 LLM 推理框架 一、出发点 我一直在思考一个问题 LLM 返回的内容本质上需要被“框定”在一个可靠范围内。 我们给上下文、提示词、约束、示例本质上都是为了让 LLM 的输出不要乱跑让它落到一个可控、可靠、可用的区域里。 如果我们能更好地框定 LLM 的输出就能提升效率、降低成本、提高可靠性。 但之前想过很多方法比如从模型层入手代价都太大了。 模型训练、微调、对齐、改结构这些都不是我想要的路径。 后来我换了一个角度 把 LLM 推理过程看成一个迷宫或者一棵搜索树。我们的目标就是找到出口。 这样问题就变了。 不再是“如何让模型一次输出正确”而是“如何在搜索空间中高效地找到可行路径”。 二、核心比喻迷宫与树 把任务求解过程看成一个迷宫 入口是初始状态。 出口是目标状态。 每走一步就是一次 LLM 调用或一次推理扩展。 每条路径代表一种可能的解题方案。 也可以把它看成一棵树 根节点是初始任务。 每个节点是一次中间状态。 每条边是一次扩展或一步推理。 叶子节点是候选结果。 既然是树就可以用搜索策略 BFS广度优先适合目标浅、分支有限的情况。 DFS深度优先适合深度大、解多、内存敏感的情况。 混用根据任务策略选择。 A* / 最佳优先如果有启发式分数可以优先扩展更有希望的节点。 Beam Search控制每层宽度。 MCTS开放任务中平衡探索与利用。 关键不是固定用哪种而是根据任务结构动态选择。 三、前缀缓存吃共享前缀的红利 这个框架里有一个非常重要的成本优势 搜索树中的路径共享大量前缀。 当我们扩展一个节点时会把 系统提示 任务描述 已验证路径 当前候选步 一起发给 LLM。 同一父节点下的兄弟分支会共享到父路径为止的前缀。 如果前缀完全一致就能吃到前缀缓存命中。 缓存命中后的成本非常低。 但要注意 缓存命中的是前缀不是整条路径。 分支点之后的 token 不同不能共享。 输出 token 不缓存。 API 缓存可能仍有费用只是折扣。 自托管时可以用 vLLM prefix caching、SGLang RadixAttention 等。 缓存有 TTL、容量、最小长度限制。 搜索顺序影响命中率DFS 在同一子树连续扩展局部性通常更好。 所以缓存不减少调用次数但能大幅减少重复计算。 真正的成本下降还要靠剪枝。 四、剪枝减少 LLM 调用次数的关键 每个节点都需要继续发送 LLM 调用。 但我们可以附上这条路径让模型在已有上下文上继续。 如果某些节点明显不行就应该剪掉。 剪枝比缓存更决定总成本因为缓存只省输入计算剪枝直接减少节点数。 常见剪枝方式 硬剪枝格式错误、编译失败、违反约束、事实被否定。 重复/环剪枝状态哈希或语义哈希已访问过的不再扩展。 预算剪枝深度、token、时间、调用次数超限。 启发式剪枝可行性分数低于阈值。 支配剪枝另一个节点完成更多、成本更低、分数更高。 分支限界当前最优解成本为 U某节点乐观下界 L U则剪。 多样性剪枝聚类去重每类只留代表。 验证剪枝多个独立验证器一致否定则剪。 但剪枝不能太狠因为 LLM 评分有噪声。 要保留少量探索避免剪掉正确路径。 五、如何判断一条路径可行 父路径如果已经通过验证那么它上面的路径都是可行的。 现在的问题是如何判断当前这一步是否可行 不能直接把整段思维过程丢给评估模型。 长思维链噪声大、容易被措辞欺骗、输入也长。 正确做法是 把这一步的想法转换成实际的计算验证然后一并发给评估器。 具体来说 父节点带着已证证书。 当前步生成“证明义务”。 用工具或计算去验算这些义务。 把验算结果打包成短证据包。 把证据包发给评估器。 评估器判断当前步是否满足子目标。 通过则继承证书失败则剪不确定则挂起或升级。 这样判断“这一步是否可行”就变成了 父证书 当前步证据 无开放义务 廉价评估器确认。 不是重新判断整条路径而是只判断当前增量。 六、特殊评估模型判别式验证器 这里有一类很特殊的模型 它不输出 token。 它内部没有思维链。 它确实是深层的神经网络。 它成本非常低。 在有些事实支撑的情况下它的正确率可以跟 LLM 打分一样。 它本质上是一种判别式验证器、PRM、ORM、可行性分类器。 它不是生成式 LLM judge。 它一次前向传播就出分数可以是百分比也可以是是/否。 它的优势 成本极低。 可以高频调用。 没有解码延迟。 可以多模型投票。 可以做多粒度判断。 它的局限 不能生成证明义务。 不能给反例。 不能解释为什么。 不能替代工具验算。 没有事实支撑时它和瞎猜差不多。 所以它只能当证据聚合器 门卫不能当证据生产者也不能当最终裁判。 七、小 LLM 的角色把想法翻译成可执行验算 为了把“这一步的想法”变成“实际的计算验证”我们需要一个小 LLM。 这个小 LLM 可以部署在本地。 8B 足够了。再小的话输出格式无法保证。 它只做三件事 把候选步翻译成可执行验算或证明义务。 输出结构化 JSON / DSL。 必要时做轻量重试和格式修复。 这是翻译任务不是推理任务。 验证比生成简单得多。 生成需要探索、创造、长程规划。 验证只需要 把命题拆成可检查的原子。 写出对应的计算、查询、测试。 执行并提取结果。 所以 8B 本地模型够用。 为了保证输出格式可以用 vLLM outlines / xgrammar / lm-format-enforcer。 强制 JSON Schema。 输出短 DSL不要自然语言。 解析失败重试 1~2 次再失败就挂起或升级。 本地 8B 的优势 无网络延迟。 无数据外传。 可批量、可并发、可前缀缓存。 成本固定边际调用近乎为零。 但它会抖所以要多采样、去重、聚合。 八、多次重复避免偶然性 小 LLM 便宜评估器也便宜。 所以我们可以多执行几次。 同一想法让小 LLM 采样多次生成多个验算方案。 然后执行验算得到多个结果。 再让评估器对每个 (方案, 结果) 打分。 最后聚合。 这样有两个独立的噪声源 小 LLM 翻译的随机性。 判别式评估器的噪声。 多次重复相当于对这两个噪声源做蒙特卡洛边缘化。 聚合方式不能简单平均要分情况 验算结果一致 评估器一致直接采用停止重复。 验算结果一致 评估器分歧说明证据有歧义升级到 LLM judge 或增加重复。 验算结果分歧说明小 LLM 翻译不稳定换更大翻译模型或把证明义务拆得更细。 验算全失败剪。 验算全成功 评估器高分接受继承证书。 聚合建议 通过率 成功验算次数 / 总次数。 用 Wilson 或 Beta 后验算置信区间。 下界 阈值接受。 上界 阈值剪。 区间跨阈值挂起或升级。 用置信下界而不是均值避免“3 次里 2 次过就接受”这种冒进。 九、何时停止重复 不要固定次数用顺序检验 每跑一次更新 Beta 后验。 如果后验已经明确高于接受阈值或低于剪枝阈值停。 如果还模糊继续跑直到预算上限。 预算上限按节点价值动态给靠近根、分支大的节点多跑叶子、低价值节点少跑。 这样平均每个节点可能只跑 1~3 次就定了。 只在模糊地带才跑更多。 十、要警惕的相关错误 重复降方差的前提是噪声独立。有两个陷阱 小 LLM 和评估器共享盲点。 如果同源、同训练分布可能一起错。 缓解用不同家族的小模型做翻译用不同判别器做评估。 验算本身有系统性偏差。 比如只检查充分条件没检查必要条件。 重复一万次也没用。 这类问题只能靠证明义务拆解的完备性解决。 十一、完整流程 整个系统可以这样运作 父证书 - 生成式大模型扩展候选步吃前缀缓存 - 小 LLM 采样多次生成验算方案 / 证明义务 - 去重、执行验算缓存结果 - 证据包规范化 哈希 - 本地缓存命中直接取分 - 未命中云端评估器批处理/并发 - 判别器对每个 (方案, 结果) 打分 - 顺序聚合置信下界决策 - 接受 / 剪 / 挂起 / 升级 节点扩展时大模型只做两件事 扩展候选步。 提出证明义务。 小 LLM 做翻译。 工具做硬验算。 云端评估器做高频筛选。 LLM judge 只在模糊地带出现。 十二、如何判断到达目标 局部可行不等于到达目标。 比如 代码每一步语法正确不等于测试通过。 数学每步推理自然不等于答案正确。 规划每一步合理不等于最终可行。 目标条件应该是 is_goal(n) 所有子目标关闭 ∧ 开放义务为空 ∧ 全局硬验证通过 ∧ 判别式验证器在最终证据包上高分 ∧ 无验证器冲突 验证分三层 硬验证器规则、编译器、单元测试、schema、数学检查、检索事实、约束求解器。 软验证器LLM judge、rubric 评分、成对比较、多模型投票。 可行性/奖励模型判别式评估器作为启发式不作为最终裁判。 复杂任务要拆成原子命题 事实 claim 是否被证据支持 逻辑步骤总结想法一主张用树形上下文彻底替代线性上下文把记忆组织成带父子关系的树结构每次只传入树的结构与最近被修改的节点内容从而避免无关记忆稀释上下文、减少信息断层。它的核心价值在于让模型始终聚焦于当前任务真正需要的记忆而不是被整段线性历史拖累。但目前仍未解决的关键问题是树的节点数量是否存在合理上限当项目规模变大、节点数量增长后每次预传三个节点是否仍然足够节点之间的关联如何建立和维护置信度的更新策略也尚未确定这些都直接影响树形上下文在真实项目中的可用性。想法二主张把任务求解过程看作一棵搜索树利用路径共享前缀来吃缓存命中红利并通过剪枝减少 LLM 调用次数同时引入本地小模型与判别式决策模型来低成本地验证每一步是否可行。它的核心价值在于把「让模型一次输出正确」转化为「在搜索空间中高效找到可行路径」从而在成本可控的前提下提升可靠性。但目前仍未解决的关键问题是决策模型的训练数据从何而来如何保证小模型与决策模型之间不会「串通」、共享盲点剪枝策略在不同任务结构下如何自适应这些问题的答案决定了这套框架能否从设想走向落地。后续的实验验证路径可以从两个方向展开。对于想法一可以先在一个中等规模的项目上实现树形上下文原型对比它与线性上下文在任务完成质量、上下文命中率和模型产出稳定性上的差异重点观察节点数量增长后的表现。对于想法二可以先在封闭、有事实支撑的判别任务上验证决策模型的准确率再逐步搭建「大模型扩展候选步 小模型翻译验算 决策模型打分」的完整链路用真实任务测量缓存命中率、剪枝有效性和整体成本变化。这两个想法虽然路径不同但底层逻辑是一致的都在试图用更结构化的方式约束 LLM 的输出让它落在可控、可靠、可用的范围内。想法一从记忆组织入手想法二从推理过程入手二者甚至可以在未来融合——用树形上下文承载搜索树的路径记忆让模型在探索时既能吃到结构化的上下文又能借助廉价验证器控制成本。