用本地小模型暴露多 Agent 架构缺陷
作者用运行在骁龙 NPU 上的 4B 模型和 4096-token 上下文，检验三级 smolagents 系统，避免大模型能力掩盖架构问题。针对顶层 Agent 看不到下层工具的问题，通过递归向上汇总子 Agent 能力描述改善任务路由。
AI 深度解读
大模型可能替多 Agent 框架掩盖了问题：职责写得含糊、提示词太长、工具描述缺失，它仍能猜着完成任务。SpaghettiLens-AI 的作者反过来，用本地 NPU 上的 4B 模型压测三层 Agent，逼架构暴露短板。
这篇最有用的部分，是三个具体故障及其修复思路：让上层看见下层能力、压缩报告式提示词、正确识别输出截断。至于小模型能否媲美大模型，需要把作者的工程经验与论文中的特定实验分开看。
为什么要把 4B 模型当作架构风洞
SpaghettiLens-AI v0.5.0 的目标，是把遗留 Perl/PHP 单体重构成 Python/FastAPI 微服务。它采用 smolagents CodeAgent 的三层结构：L0 Supervisor 负责统筹，L1 Team Leads 分派任务，L2 Specialists 执行专业工作。
作者选择 qwen3-4b-instruct-2507，在 Snapdragon NPU 上本地运行，并限制为严格的 4096-token 滑动上下文窗口。
作者认为，常用于框架评测的 70B+ 云端模型，可能凭借模型能力补上系统设计的缺口。小模型容量有限、上下文紧张，反而更容易暴露这些问题。「风洞」指的就是这种受限测试环境。
模型能猜对，不等于架构已经把信息传对。
不过，原文没有给出同一套任务在大小模型上的对照结果。这是作者选择测试方法的理由，还不能当作普遍成立的实验结论。
三个故障，分别卡在路由、执行和错误反馈
第一个问题是上层看不到完整能力。L0 能看到 L1，却不知道 L1 下属的专业工具。即使专家就在系统里，主管也缺少明确的派单依据。
作者在 smolagents PR #3115 中修补能力向上传播：递归把嵌套子 Agent 的能力摘要追加到描述，让根节点获得跨越三层的路由信息。这里需要传播的是「谁能做什么」，不必把所有底层细节塞进上层。
第二个问题是提示词把执行挤成了报告。默认 managed_agent 系统提示词要求子 Agent 输出多章节文字。在 4096-token 上限下，作者观察到 4B 模型会生成理论总结，而没有输出可执行的 <code>...</code> 块。
他们改用紧凑、代码优先的 Jinja2 提示词，并设置分层约束：每个 Agent 必须在 Step 1 调用指定工具，把结果直接交给 final_answer。这种做法适合职责明确的执行节点，但没有证明所有探索任务都该第一步调用工具。
第三个问题更隐蔽：输出截断，被误报成格式错误。
提取较大的静态 AST/SQL 依赖图时，输出偶尔在 JSON 中途触及 max_completion_tokens。由于缺少结尾的 }，parse_json_blob 报出「output does not contain any JSON blob」。Agent 以为需要重新生成 JSON，于是反复生成同样超长的内容。
smolagents PR #3110 增加了截断 JSON 检测，让解析器明确报告 token 上限问题，Agent 才有机会在重试时压缩输出。原文提到这两个 PR，但没有交代合并状态。
错误信息必须指出可修复的原因，重试才有方向。
小模型能否可靠，关键还在模型前后
作者把自己的方案与 Naphade 等人的 Expert Block Frameworks for Small LLMs 研究联系起来，引用编号为 arXiv:2509.15561。
按原文转述，该研究通过确定性模块，把原始、嘈杂的轨迹转换成结构化上下文，再交给本地小模型推理；在研究条件下，可匹配 100B+ 前沿模型的表现，与 GPT-4 相差约 0.9%。原文没有说明任务、指标和评测细节，不能据此推导出「4B 写代码接近 GPT-4」。
SpaghettiLens-AI 借鉴的是处理流程。输入端由静态提取器把 AST 和 SQL DDL 模式压缩成 JSON 依赖图，减少模型在有限窗口里自行找关系的负担。
输出端使用 AST 解析、参数化 SQL 强制检查，以及 decimal.Decimal 账本校验，代替开放式的模型自我批评。这里的确定性模块，就是按明确规则转换或检查数据的程序。
作者报告了单次完成重构的结果，标记为 iterations_used: 1。但原文没有提供样本量、任务规模或失败案例；一次通过这些检查，也不能直接证明业务行为全部等价。
我的判断
我赞同先修复信息传递和验证机制。相比继续增加提示词、让另一个 Agent 复审，明确的工具描述和程序校验更容易定位故障，也更便于回归检查。
局限在于，这套方案依赖任务能够被静态分析、结构化和规则验证。AST 合法不等于业务正确，账本校验也只覆盖它定义的约束。对于含糊需求和隐含业务规则，模型仍需要探索，测试也需要补足。
原文没有多 Agent 与单 Agent、大小模型之间的系统对照。因此，它更适合作为排障经验，不能用来证明三层架构更优，或本地 4B 已足够承担一般的软件迁移。
能拿来做什么
- 如果你的编码 Agent 有多层委派，先检查主管能否从描述中识别下属工具的用途，并用明确任务验证路由是否正确。
- 对只负责执行固定工具的子 Agent，缩短报告要求，明确工具调用与结果返回方式，减少无用文字占据上下文。
- 在 Node 或 Python 的模型调用层，区分输出截断与普通 JSON 格式错误；触及输出上限时调整内容规模，避免原样重试。
- 对代码迁移任务，把语法、SQL 和金额计算中能程序化检查的约束交给工具，同时用业务测试覆盖规则检查之外的行为。