本地 Agent 的另一种分工：扩散模型做生成，决策模型做判断
-
聊本地 Agent，我们经常关注主模型够不够聪明。但一个任务里还有大量辅助工作：选工具、筛记忆、压缩上下文、检查参数。这些都必须让同一个大模型生成一段话吗？
配套的模型介绍：《除了 Qwen、DeepSeek、GLM，本地还能跑扩散 LLM 和决策模型吗？》（LLM讨论区）。这里重点聊它们在 harness 里的位置。下面是资料与设计建议，不是我的本机复现。
分工，而不是换掉整个“大脑”
扩散模型处理需要生成的内容，决策模型处理有界判断，harness 管状态和执行，沙箱管权限边界。 复杂规划仍可以交给现有强模型；能用确定性程序解决的事，也不必塞给任何模型。
1. 工具层：选哪个，以及现在该不该调用
先按权限和检索缩小工具候选集，再让决策模型选工具，保留“都不合适／需要澄清”。生成模型负责具体参数或脚本，程序负责 Schema 校验与授权。
Strands Decider 已有调用前检查示例：用户没说城市，主模型却猜一个城市查天气；决策模型判断参数是否有依据、是否应先澄清，再由代码返回继续或纠正方向。这只是演示，不是安全保证；参数有依据，也不等于用户授权执行。
设计示意，非本机实测；权限边界由程序与 OS 强制执行。
2. 知识层：决定读什么，而不是取代数据库
检索先找候选片段，决策模型再筛“对当前任务是否有用”，生成模型组织答案。相关、可用、足以支持结论，是三个不同问题。
保留片段 ID、原文和版本，允许一个都不选，也要与普通 reranker 比较。Strands 的记忆筛选目前仍是开放提案，不应写成已经验证的默认功能。记忆写入也先产生候选，不因一个高分就变成永久事实。
3. 上下文：谁来做 compaction？
决策模型判断该保留哪些约束、事件或文件状态；扩散模型生成交接摘要。Inception 发布过 Augment 用 Mercury 做上下文压缩、路由和工具搜索的案例，但速度与成本收益属于厂商页面上的客户报告，不能照搬成本地结果。
摘要必须保留未完成事项和来源，原始轨迹不能直接丢。扩散中间画布也不是已确认的工具调用，必须等完整结果验证后再执行。
4. 沙箱与验证：不能交给模型兜底
决策模型可以提示“可能危险／需要人工确认”，但不能给自己提权。目录权限、网络出口、凭证、预算和资源限制，仍由程序与 OS 隔离强制执行。
工具输出、网页甚至截图都可能夹带注入。DecisionRobust 预印本已报告决策模型的相关脆弱性；只输出选项，不代表不会被诱导。测试通过与否、文件是否存在，也应优先读取真实执行结果，而不是让模型猜。
真正值得测的是整个任务
我会先做 shadow mode，只记录决策、不实际拦截；再分别比较原方案、只加决策模型、只换扩散组件、两者都用。看任务成功率、p95 延迟、误放行与误拦截、人工升级、显存和能耗，而不只看 tok/s。
也许本地 Agent 的下一步，不只是装下更大的模型，而是让每一类工作用上合适的组件。 大家更想先试工具检查、记忆筛选，还是上下文压缩？
参考
-
三个里先做「工具检查」：可验证、收益最快、误判代价清楚；上下文压缩第二，记忆筛选放最后。
工具检查的最小闭环：先把候选工具集按权限和检索缩小，再让决策模型只回答「这个参数在用户原话/工具返回里有没有依据」，输出有依据 / 需澄清 / 无依据三档概率；代码侧用 JSON Schema 校验 + 白名单，决策模型只做提示、不做授权。上线前先 shadow：拿 200 条真实 tool call 回放，记录它和人工标注的混淆矩阵，重点看「误放行」而不是总准确率。
上下文压缩第二：它直接改每次请求的成本和延迟，容易 A/B；但摘要必须保留未完成事项、文件版本、被拒绝过的方案，压缩后要用一组固定任务回归，不然省下的 token 会在返工里吐回去。
记忆筛选最后：相关性、可用性、是否足以支持结论是三件事，没有稳定标注集时很容易做成「看起来有用」。先只做候选 + 人工确认，别自动写入长期记忆。
硬件上别忽略共存成本：2B decider + 26B 级扩散模型同时常驻，16G/24G 卡会互相挤 KV；决策模型可以量化后放 CPU，或只在「参数缺失/多工具歧义」分支调用；扩散模型更适合离线批量摘要，不建议放进同步工具调用链——它的延迟方差比自回归大，p95 会被它吃掉。
-
