小模型 Agent 的真正难题：不是不够聪明，而是系统还不会组织智能-尧图网络科技

把 70B 模型换成 3B 模型，通常不是一次“降本部署”，而是一次系统重写。小模型擅长的不是在开放世界里独自完成所有思考，而是在状态被外置、动作被约束、结果可验证、失败能恢复的闭环里高频执行。

先给结论：
小模型 Agent 的核心指标不应是“单步像不像大模型”，而是单位成功任务成本下，能否稳定地完成、拒绝、询问、升级和恢复。模型只是控制回路的一环；真正把系统拉开差距的是任务状态、工具语义、验证器、风险策略与能力路由。

一、先改问题：Agent 不是一次问答，而是带副作用的控制系统

普通问答的输入是文本，输出也是文本；输出即使不完美，也多半只造成信息质量下降。Agent 则在不确定环境中连续采取动作，动作会读写外部状态：创建会议、修改订单、发送邮件、点击按钮、调用内部 API。它的正确性不能只由一句回答判定。

更贴近工程的抽象是一个部分可观测控制回路。时刻t，系统从外部环境拿到观测o_t，结合持久任务状态s_t、可用动作集合A_t和风险策略π_r，选择动作a_t；执行后得到结果r_t，由验证器决定提交、重试、回滚、询问还是升级。

state_t + observation_t + policy + action_space → action_t action_t + environment → result_t → verifier → commit | retry | ask | escalate | abort

这里最重要的区分是：模型生成的“提议”不等于系统允许提交的“动作”。对于可逆的读取动作，两者距离可以较近；对于转账、外发、删除、权限变更等不可逆动作，中间必须插入授权、验证和确认。

层次	应保存什么	不应交给模型临时记忆的原因
目标层	用户意图、成功标准、不可违反的约束	多轮修改时，旧指令会与新条件竞争。
任务层	计划节点、依赖、预算、重试次数、当前节点	把全对话回放给小模型，会稀释真正相关的状态。
证据层	工具返回、来源、截图/DOM 摘要、时间戳、版本	“模型说看到了”不是可复查证据。
执行层	幂等键、事务状态、执行日志、补偿动作	网络超时后，不知道动作是否已生效会造成重复写入。

二、小模型不是“弱大脑”，而是受限动作空间里的策略器

在工具数量少、输入边界清楚、输出可被 schema 校验的场景中，1B–7B 级模型可以非常有竞争力：参数抽取、分类、查询改写、候选工具重排、固定表单填写、结果摘要、规则驱动的下一步选择。APIGen 的数据构造正体现了这一点：函数调用样本不只看格式，还经格式检查、实际执行和语义验证；高质量、可执行的数据比大量“看起来像调用”的样本更有价值。

问题在于，生产 Agent 往往把几个不同难度的问题一起塞给模型：理解模糊意图、从数百个接口中检索工具、补全参数、维持跨轮状态、判断风险、处理异常、确认目标完成。此时模型参数量并非唯一瓶颈，动作空间的熵和状态空间的熵才是关键变量。

低熵任务：“从 8 个已授权工具中选择一个，输出符合 JSON Schema 的参数”
高熵任务：“理解用户真实目标，在未知网页与数百个 API 中探索，处理冲突约束，并对外发操作承担后果”

工程上的基本策略不是让小模型硬吃高熵问题，而是通过工具检索、状态机、领域 DSL、规则和验证器，把高熵问题拆成一串小模型可解的低熵决策。这比单纯堆 prompt 或延长上下文更可靠。

三、第一道硬门：工具调用不是分类，而是“检索 + 约束满足 + 拒绝”

当工具从 5 个增加到 500 个，直接把全部说明塞进上下文，成本和误选率都会上升。工具调用应拆成四段，而不是让一个模型一次完成：

候选检索。

用任务语义、权限域、实体类型、当前状态和历史成功路径召回一个小集合K；工具描述应结构化包含输入 schema、前置条件、读写集合、幂等性、风险级别和失败码。

语义重排。

小模型或 reranker 在K中判断动作是否匹配目标，不能只靠函数名。Hammer 对无关工具与函数名遮蔽的训练，正是为了降低这种表面名称捷径。

参数合成与静态校验。

模型只生成受 schema 约束的 JSON/DSL；类型、枚举、范围、必填字段、权限、前置状态由确定性校验器处理。

允许不调用。

候选集中没有合适工具、信息不足或风险超阈值时，正确输出应是ASK_USER、SEARCH或ESCALATE，不是“挑一个最像的”。

{ "tool": "calendar.create_draft", "arguments": {"start": "2026-07-21T10:00:00+08:00", "attendees": ["…"]}, "preconditions": ["attendees_resolved", "timezone_confirmed"], "expected_effect": "draft_event_created", "idempotency_key": "task_842/step_3/v1", "risk": "reversible" }

接口设计的一个实用原则：让工具返回机器可判的状态码、资源版本和结构化错误，而不是只返回一段自然语言。CONFLICT、PRECONDITION_FAILED、PERMISSION_DENIED比“操作失败，请重试”更能支持恢复策略。

四、第二道硬门：把“对话历史”改造成可版本化的任务状态

DICE-Bench 指出，多轮、多参与者的工具使用信息常分散在不同轮次。直接把完整历史交给小模型，看似保留了信息，实则让最新约束、过期意图、工具回包、闲聊和潜在提示注入混在同一上下文里。更稳的做法是让对话只负责更新状态，让执行器只读取当前所需的状态投影。

{ "task_id": "dinner_842", "goal": "安排客户晚餐并生成待确认预订草稿", "constraints": {"date": "2026-07-18", "district": "西城区", "budget_cny": 800, "people": 4}, "open_questions": ["是否有饮食禁忌"], "facts": [{"key": "client_company", "value": "ACME", "source": "crm:lead_91", "version": 7}], "plan": [{"id": "s1", "action": "restaurant.search", "status": "ready"}], "policy": {"max_steps": 12, "max_cost_cny": 2, "write_requires_confirmation": true} }

这个状态对象至少应满足四个性质：

显式来源字段级版本可审计变更最小必要读取

“字段级版本”尤其关键。若用户在第 8 轮把预算从 800 改成 600，系统不该只把一句新消息附在末尾；应写入constraints.budget_cny的新版本，并使依赖旧预算的候选餐厅和已生成计划失效。这样，重规划有明确触发条件，而不是让模型靠注意力从长上下文中猜。

五、真正的可靠性来自验证闭环，不是“再想一遍”

小模型的单步动作正确率即使达到p=0.95，连续 20 个必须成功的步骤在独立假设下也只有p²⁰ ≈ 36%的完整成功率。现实更差，因为错误相关：一次错误的实体消歧会污染后续检索、参数和写入。因此，Agent 不能只优化下一步准确率，必须引入检查点和局部恢复。

P(端到端成功) ≠ ∏ P(动作正确) 它还取决于：错误能否被检出 × 能否在副作用扩大前恢复 × 恢复后是否回到正确状态

生成器提议动作 / 参数

执行器调用工具 / 程序

验证器检查预期效果

↓

语法验证JSON、类型、枚举、schema

语义验证实体、约束、引用、前后状态

风险验证权限、外发、金额、不可逆性

验证器必须尽可能独立于生成器：读取型 API 要检查返回记录是否满足谓词；写入型 API 要检查资源版本、审计日志或回读结果；GUI 动作要同时检查页面状态、目标元素和业务结果。只让同一个模型复述“我已经完成了”并不是验证。

动作类型	提交前	提交后	失败策略
读取 / 检索	权限、查询范围、注入隔离	来源、时效、覆盖率、冲突检测	换源、缩小/扩展查询、升级检索
可逆写入	schema、幂等键、dry-run、用户意图	回读资源、版本号、预期 effect	重试或补偿；记录事务状态
不可逆写入	策略、显式确认、双通道证据、额度	审计回执、通知与人工抽检	停止扩散，转人工处置

六、恢复协议要先于规划协议：不要只训练成功轨迹

生产环境的常态不是“工具总能返回理想结果”，而是超时、部分成功、权限变化、页面改版、数据冲突、用户中途改口。一个只见过成功示例的执行器会把失败当成新的自然语言继续编造；一个可靠系统要把异常变成有限类别，并为每类准备恢复动作。

TIMEOUT：先查询幂等键 / 资源版本，判断“未执行、已执行、未知”，而不是盲目重发。
VALIDATION_ERROR：把字段级错误写入状态，只允许修改相关参数。
STATE_DRIFT：重新观察环境；若当前页面/资源不在已知状态图中，停止自动操作。
GOAL_CONFLICT：标记受影响计划节点为 stale，询问用户或调用规划器重新求解。

这也是为什么“反思”不能代替恢复。反思是一种语言能力；恢复是一份工程协议，要求有错误分类、可重放日志、幂等键、补偿动作、稳定检查点和明确的停止条件。

七、路由不该只选模型，而应输出一张能力执行图

“简单任务给 3B，复杂任务给 70B”的二元路由过于粗糙。一个任务可能语言理解很简单、但依赖最新事实；可能只有一步、但会产生不可逆副作用；也可能步骤很多、却完全能在 DSL 和工作流引擎中确定性执行。因此，路由器的输出不应只是模型名，而应是一张包含能力、证据和策略的执行图。

意图与风险门权限 / 数据等级 / 副作用

能力分解检索 / 视觉 / 规划 / 计算 / 写入

执行图模型、工具、规则、人工节点

↓

小模型抽取、重排、参数、短程执行

确定性工具SQL、计算、DSL、状态机、校验

强模型 / 人开放规划、歧义、风险与异常

升级信号也不应只依赖模型自报置信度。更可用的是可观测证据：多个候选动作分歧、连续工具失败、候选集合无覆盖、计划长度异常、验证器否决、来源冲突、页面脱离状态图、预算接近上限、出现高风险动词，或用户目标发生字段级变更。

升级不是失败。在生产系统中，正确的ESCALATE和ASK_USER是成功动作。一个成功率稍低、但能可靠停止的 Agent，通常比偶尔惊艳却会越权外发的 Agent 更值得部署。

八、成本账要按“成功任务”算，而不是按一次推理算

小模型单次便宜，不代表端到端更便宜。完整成本应至少包括输入 token、输出 token、模型调用次数、检索/API 费用、工具等待、重试、升级、人工介入和失败后的恢复成本。尤其在 GUI 场景，截图编码与反复观察往往比短文本生成更贵。

E[cost / success] = (model + tools + infra + human + recovery) / P(task_success) P95 latency = queue + Σ(model_inference + tool_wait + verification + retry)

因此，评测面板至少应同时看：任务完成率、约束违例率、正确拒绝率、正确询问率、升级精度、错误恢复率、每成功任务成本、P95 端到端延迟，以及副作用事件数。只展示单轮 function calling 分数，无法回答系统是否能上线。

九、一个可落地的最小生产架构

对于企业内部的低到中风险任务，可以从下面这条窄而完整的链路开始，而不是一上来做一个“能自主浏览一切”的通用 Agent：

限定领域与工具边界。

先选 10–30 个高频、可审计、效果可回读的工具；为每个工具补齐 schema、权限、幂等性和失败码。

建立任务状态服务。

把目标、约束、证据、计划、执行日志做成版本化对象；对话只是状态更新接口。

训练/部署专门执行器。

小模型只负责工具候选重排、参数生成、结构化抽取和短程下一步；输出被 grammar 或 JSON schema 约束。

把验证器产品化。

写入前有 policy gate，写入后有 effect checker；验证失败不得由模型自由解释后继续。

定义升级与恢复 SLO。

明确哪些错误可重试、哪些必须询问、哪些直接升级；收集失败轨迹而不只收集成功样本。

用影子模式上线。

先只生成计划和动作提议，与人工/旧流程比对；再逐步开放低风险可逆动作，最后才考虑高风险写入。

不要让小模型记住整个世界，让它学会查询世界。
不要让小模型自由规划一切，让结构化流程约束它。
不要要求小模型永远正确，让验证器在错误扩散前发现它。
不要在每一步调用大模型，只在能力或风险真正越界时升级。

结语：未来的 Agent，更像组织而不是单一大脑

大模型仍然重要：它适合开放式目标澄清、跨域规划、未知异常处理和高价值复核。但它不必出现在每一次工具调用中。小模型、检索、规则、DSL、程序执行器、验证器和人类审批，各自承担更适配的职责，才是可扩展系统的形态。

小模型 Agent 的上限，最终取决于系统能否把开放任务变成受限决策，把隐式上下文变成显式状态，把自然语言动作变成可检查程序，把“模型说完成了”变成可验证的外部效果。真正稀缺的能力，不是拥有一个更会思考的模型，而是能用最低成本把不同形态的智能组织成可靠闭环。

论文与延伸阅读

APIGen: Automated Pipeline for Generating Verifiable and Diverse Function-Calling Datasets — 可执行函数调用数据的格式、执行与语义三级验证。
Hammer: Robust Function-Calling for On-Device Language Models via Function Masking — 无关工具和函数名称表面捷径带来的鲁棒性问题。
DICE-BENCH: Evaluating Tool-Use Capabilities in Multi-Round, Multi-Party Dialogues — 工具信息跨轮分散的真实多轮评测。
Octopus v2: On-device language model for super agent — 以 functional token 缩小端侧函数调用上下文的路线。
Dynamo: Amazon’s Highly Available Key-value Store — 幂等、版本与分布式副作用处理的经典工程背景。

这里给大家精心整理了一份全面的AI大模型学习资源，包括：AI大模型全套学习路线图（从入门到实战）、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等，资料免费分享！

👇👇扫码免费领取全部内容👇👇