我以前默认答案是“需要”。毕竟工具调用看起来像推理：用户说“明天早上 8 点提醒我带伞”，模型要理解意图、找到日历或提醒工具、抽取时间、地点和参数，最后输出一段合法 JSON。让 7B、14B 甚至更大的模型来做，似乎很自然。

但这两天 HN 上的 Needle 把这个直觉反过来了。Cactus 团队开源了一个只有 26M 参数的 function calling 模型，README 里说它是把 Gemini 3.1 的工具调用能力蒸馏到一个 “Simple Attention Network” 上，目标是跑在手机、手表、眼镜这类消费设备上。项目目前 MIT 开源，代码在 cactus-compute/needle，权重放在 Hugging Face。

26M 是什么概念？比很多 embedding 模型还小，比常见的 0.5B/1.5B 小模型又小一个数量级。它不打算写诗、聊天、做数学题，只做一件事：给定用户 query 和工具 schema，吐出应该调用的工具及参数。

坦白说，我觉得这个方向比“又一个端侧聊天机器人”更值得写。因为生产里的 Agent 系统，最先遇到瓶颈的往往不是“模型不够聪明”，而是“每一步都太贵、太慢、太不稳定”。

把工具调用从“推理”降级成“路由”

Needle 的核心判断很激进：单轮工具调用本质上不是开放式推理，而是 retrieval-and-assembly。

用人话说，就是三步：先从工具列表里匹配哪个工具最像用户意图；再从用户句子里抽参数；最后按 schema 拼成 JSON。这个过程当然需要语言理解，但它未必需要一个装满世界知识的大模型。工具说明和参数 schema 已经作为输入给了模型，事实知识在上下文里，不必塞进 FFN 权重里。

这也是它的架构为什么反常。Needle 的 Simple Attention Networks 文档 里明确写到：实验发现，如果任务依赖外部结构化知识，Transformer 里的 MLP/FFN 可以被完全拿掉，模型主要靠 attention 和 gating 工作。Needle 的结构是 12 层 encoder 加 8 层 decoder，隐藏维度 512，8 个 attention head，BPE 词表 8192；README 还强调 “no MLPs anywhere”。

这句话的工程含义很直白：FFN 更像模型的“记忆仓库”和非线性加工层，而工具调用场景里的“记忆”已经外置成工具列表了。既然你每次都把 get_weather(location)、create_timer(duration)、send_message(contact, text) 这些 schema 喂给模型，它要做的就不是背知识，而是对齐 query 与 schema。

这有点像 RAG 里的 rerank。你不会让一个通用大模型从全世界知识里凭空猜文档，而是先给它候选，再让它排序。此前我在写 RAG 重排里的 Bi-Encoder 与 Cross-Encoder 时就说过：一旦候选空间被压小，专用模型往往比通用模型更划算。Needle 放到 Agent 里也是类似逻辑：工具集就是候选空间，function calling 模型就是路由器。

说白了，它不是想替代 GPT-5，而是想替代 Agent 系统里那一层“每次都请大模型选工具”的昂贵默认值。

小模型真正省下来的不是钱，而是系统复杂度

README 里给了一个很抓眼球的数字：Needle 在 Cactus 上可以达到 6000 tokens/s prefill、1200 tokens/s decode。这个数字要谨慎看，因为它和硬件、量化、输入长度、batch 方式都有关，不能直接拿来和云端 API 或 vLLM 服务做横向对比。但即便打个折，它也说明一个事实：26M 参数模型的部署形态完全不同。

大模型工具调用通常意味着：请求从 App 发到后端，后端调用 LLM API 或自建推理服务，模型返回 JSON，业务再执行工具。这里面有网络、鉴权、队列、限流、日志脱敏、失败重试和成本核算。每多一次 Agent step，都多一次系统不确定性。

如果工具路由能在端侧或本地服务完成，架构会简单很多。比如手机上的个人助手要在“计时器、短信、日历、导航、智能家居”之间选择工具，它不一定需要把用户原话发到云端；浏览器插件要对页面做轻量操作，也不一定要每次走服务器。这个判断和我之前写 Chrome Prompt API 时的结论一致：端侧模型的核心价值不是更聪明，而是更靠近数据、更低延迟、更少合规解释。

当然，Needle 不是 Chrome 内置能力，它是一个开源模型和训练/微调工具链。但它代表的是同一条路线：把低风险、结构化、可校验的 AI 子任务从“大模型中心”拆出来，下沉到更便宜的位置。

我更看重的是这件事对 Agent 编排的影响。很多 Agent 框架现在喜欢把所有步骤都丢给同一个大模型：规划、选工具、写参数、观察结果、再规划。这样做 Demo 很快，但线上很难控。一个更工程化的拆法应该是：

• 复杂规划交给强模型；
• 工具路由交给小模型或规则+模型混合层；
• 参数校验交给 schema validator；
• 高风险动作再让强模型或人工复核。

Needle 正好卡在第二层。

但别把它误读成“26M 打败大模型”

我不太喜欢一些小模型项目的宣传口径：动不动就“beats Qwen / Gemma / Granite”。Needle README 里也提到它在单轮 function calling 上优于 FunctionGemma-270M、Qwen-0.6B、Granite-350M、LFM2.5-350M，但同时也承认这些模型的能力范围更大，聊天和通用任务更强，小模型也会比较 finicky。

这点很重要。

工具调用在生产里不是一个单一 benchmark。真实系统里会出现很多脏情况：用户一句话包含多个意图；工具 schema 写得含糊；业务参数有隐式默认值；同名联系人需要 disambiguation；模型输出 JSON 合法但业务语义错；多轮上下文里前一句的“它”到底指哪个对象。26M 模型如果只做 single-shot function call，遇到这些场景就需要外部系统补位。

所以我的建议不是“把 Agent 的工具调用全部换成 Needle”，而是先把任务分层。

适合 Needle 这类小模型的场景，大概有三个特征：第一，工具集合稳定且数量有限；第二，用户表达比较短，主要是单轮命令；第三，错误可以被校验、回退或二次确认。比如本地设备助手、浏览器扩展、企业内部固定流程、IoT 控制、低风险自动化命令。

不适合的场景也很明显：跨系统长链路规划、金融/医疗/法律等高风险动作、强多轮上下文依赖、工具 schema 高频变化、需要复杂业务推理的 Agent。这些地方小模型可以做候选路由，但不该单独拍板。

换句话说，Needle 的生产价值不是“更强”，而是“更窄”。窄到可以测试、可以微调、可以部署在边缘，也可以被工程系统包住。

微调按钮很诱人，数据质量才是坑

Needle 提供了 playground、CLI 和 Python API。README 的 Quickstart 是：clone 仓库，cd needle && source ./setup，然后 needle playground 打开本地 Web UI；Python 里可以加载 checkpoint，把 query 和 tools 传给 generate()，得到类似 [{"name":"get_weather","arguments":{"location":"San Francisco"}}] 的结果。它还支持 needle finetune data.jsonl，并且可以用 Gemini 生成训练数据。

这个体验看起来很顺，但我会特别提醒一句：微调工具调用模型，最难的不是跑训练，而是定义“正确”。

比如一个 CRM Agent 里有 create_lead、update_contact、log_activity 三个工具。用户说“把刚才那个客户加到下周跟进里”，到底应该调哪个？如果业务流程要求先查联系人再建任务，单轮数据里只标一个最终工具可能就是错的。再比如参数抽取，时间、币种、地区、权限范围都可能有业务默认值，这些默认值不在用户原话里，模型很容易学出看似合理但实际危险的补全。

所以，如果真要把 Needle 用到内部系统，我会这样落地：先从日志里抽取高频、低风险、单工具动作；人工审核一小批高质量 JSON 标注；用 schema validator 做硬约束；上线后只让它处理置信度高的请求；低置信度或校验失败就回退到强模型。不要一上来就让小模型接管所有工具调用。

这和我们做 本地 LLM 推理选型 时的经验一样：模型只是系统的一块。真正决定可用性的，是输入边界、失败回退、观测指标和数据闭环。

我会怎么评价 Needle

先说优点。它把一个长期被大模型垄断的子任务拆了出来，并且给了代码、权重、训练入口和架构解释。GitHub API 显示，Needle 仓库有 400+ stars，最近提交就在 2026 年 5 月 12 日，根目录包含 needle/、pyproject.toml、requirements.txt、setup 和训练脚本，不是只有白皮书的概念项目。背后的 Cactus 也是一个移动端低延迟 AI 引擎，stars 已经超过 4.7k，说明团队不是临时拼了一个 README。

再说保留意见。第一，Needle 目前更像一个实验性专用模型，而不是成熟平台。它的最佳场景是 single-shot function calling；如果你的 Agent 依赖复杂多轮状态，它不会神奇解决问题。第二，公开 benchmark 还需要更多第三方复现。README 里的速度和效果数字值得关注，但生产选型不能只看项目方自测。第三，端侧部署还涉及模型更新、兼容性、隐私日志、用户授权和安全策略，这些都不是 26M 参数本身能解决的。

但我依然觉得它值得跟进。原因不是它“打败了大模型”，而是它逼我们重新拆分 Agent 架构：哪些步骤真的需要强推理？哪些只是结构化映射？哪些可以由小模型、本地模型甚至规则系统完成？

这会是未来 Agent 工程里很现实的一条优化线。

如果你现在已经有 Agent 产品，我建议做一个小实验：把最近一周的工具调用日志拿出来，按“单轮/多轮、单工具/多工具、低风险/高风险、可校验/不可校验”四个维度打标签。你可能会发现，相当一部分调用并不需要昂贵的大模型。它们需要的是一个快、便宜、可控的工具路由层。

Needle 给这个路由层提供了一个可验证的开源起点。