本地小模型开发者的混合决策 Agent 框架

用小型本地 LLM 做代码生成或跑 agent 工作流的开发者发现，让模型对所有环节做决策会导致结果不可靠："Instead of trying to make the model responsible for everything, I started moving decisions that can be formalized into a deterministic Python kernel."。同时，在固定任务上让模型做决策纯属浪费："Offloading math, validation, and other fixed tasks to deterministic tools can reduce unnecessary model decisions."。痛点真实但强度不高（pain 2-3），目前多数人只是手工拆分逻辑，缺少一个现成的框架把这套混合架构封装好。

在本地跑小模型（0.8B 到几 B 级别）做代码生成实验或搭 agent 工作流的开发者和爱好者。从信号看是 Hugging Face 论坛和 Hacker News 上的开源社区开发者，受众偏小众、偏技术极客，社区讨论参与度也不高（score 6-8），属于利基市场。

核心思路：把 agent 工作流明确拆成'LLM 负责的模糊决策'和'确定性 kernel 负责的形式化决策'两层。 AI 的角色被刻意收窄为解释与推理，而不是全权决策方。

• 声明式任务分配：开发者标注每个步骤走 LLM 还是确定性工具
• 内置确定性 kernel：结构生成、代码渲染、组件接线由 Python 代码完成
• 不变量验证器：kernel 在每步输出后自动校验，失败可定位重试
• 固定任务自动 offload：数学计算、格式验证等默认走工具而非模型
• 兼容 0.8B 级别小型模型，CPU 即可运行

信号显示本地小模型生态正在快速变化：0.8B 级别、可在 CPU 上做决策推理的模型（Gutsy）刚刚出现，开发者开始系统性探索'哪些决策该交给模型、哪些该交给确定性代码'的架构问题，这个模式尚无标准工具承载，是切入窗口。但证据以 launch 和技术讨论为主，时机判断的置信度有限。

第一个版本：一个 Python 库，让开发者在 agent 工作流中声明哪些决策交给 LLM（解释、意图理解）、哪些交给确定性 kernel（代码渲染、组件接线、不变量验证），并内置常见验证器和数学工具的 offload 通道。明确不做：不训练或微调模型、不做 IDE 或编辑器界面、不覆盖非代码类 agent 场景。

几乎所有信号来自 launch 和讨论，付费意愿证据为零，更可能演变为开源项目而非生意；LLM 推理能力提升后（模型本身变得可靠），混合架构的必要性会被削弱；Hugging Face 生态或主流 agent 框架若内置类似混合模式，将直接覆盖此定位；受众集中在开源社区，规模小且分散。