工程框架决定Agent成功率 超越模型尺寸的实验结果
NVIDIA 公布的实验数据揭示了一个反常现象：模型本身在函数调用和规划推理上并不出彩，但放进一个构造精细的 Agent 框架后，面对复杂多步任务，成功率反倒超过了同参数规模甚至更大的裸模型 baseline。更值得注意的是，同一个弱模型，只是换了一个成熟度不同的 harness，通过率的差距就能拉开 30 个百分点以上。
问题根源不在模型够不够聪明，而在工程层。过去排查 Agent 故障时，注意力往往放在「要不要继续微调」「上下文窗口是否撑得住」上，但真正决定系统能不能上线的是另一层东西：统一的工具调用协议、显式的规划与执行分离、带确认机制的 Human-in-the-loop，还有日志回放和轨迹复盘这类跟模型智力无关的基础设施。这些手段共同防止模型出现幻觉、死循环和工具误调。
长链路任务为何裸模型必翻车？
用一个常见场景说明：让 Agent 完成「订机票、订酒店、生成行程并发给同事」这样的多步任务。裸模型大概率在第二步就把日期弄错，第三步把酒店确认号发到错误的群聊。但 harness 内置了「每步执行前必读上一步结构化输出」「关键操作必须二次确认」「失败自动回滚到上一个检查点」这类确定性逻辑后，模型就算只会按规范输出 JSON，整条链路也能走通。模型退化为受约束的执行器，框架成了真正的决策者。
预算有限时该优先优化什么？
技术选型因此有了明确方向：没必要再盯着 HuggingFace 排行榜前十反复纠结。预算对半分开，一部分投给模型微调，另一部分投给 harness 的鲁棒性、可观测性和回放调试能力，ROI 通常更划算。中小团队练不起 70B，更别说 400B，但写一套带类型检查的工具路由、加一层基于规则的防护栏，或者对 LangGraph、LangChain、AutoGen 做定制化改造，门槛低得多，见效却直接。
哪些场景下模型智力仍不可替代？
模型能力并非可有可无。当任务升级到「零样本泛化到从未见过的工具」「极度模糊指令下的意图推断」这类极限场景，强模型依然无可替代。但对 90% 的落地业务——表单填报、数据清洗、工单分派、报表生成——「工程约束 > 模型智力」这个结论，足以重新排定优先级。
下一步计划把基于 LangGraph 的内部运维 Agent 投入消融实验：固定模型不变，只调整 harness 里的重试策略、状态序列化格式、工具签名校验严格度，观察成功率曲线变化。实验结果后续会逐步整理分享。
全部回复 （3）
想当场把话说完？进全球 AI 聊天室，登录就能开口。
谁能想到折腾半天参数，最后靠个简单的 retry 机制就跑通了，太离谱了。NVIDIA 的一篇论文展示了一个惊人的结果：几款在函数调用和规划推理方面表现平平的开源模型，一旦塞进一个精心设计的 Agent 框架后，就能在复杂多步任务中直接超越同等参数量甚至更大的「裸模型」 baseline。更夸张的是，同一款弱模型，只要换个成熟度不同的 harness，通过率就能相差超过 30 个百分点。这就在告诉我们：裸模型在长链路任务中必翻车，不是因为它不聪明，而是缺了那些「不幻觉、不死循环、不调错工具」的工程手段。比如订机票、订酒店、生成行程并发给同事这样的任务，裸模型大概率会在第二步把日期搞错，第三步把酒店确认号发错群。但如果 harness 里内置了「每步执行前必读上一步结构化输出」、「关键操作必须二次确认」、「失败自动回滚到上一个检查点」等确定性逻辑，模型就算只会「按规范输出 JSON」，整条链路也能跑通。所以下次再折腾参数时，不妨先检查下自己的 retry 机制是不是跟论文里的「失败自动回滚到上一个检查点」差不多——说不定那才是真正的灵魂。
Schema定义得太烂，模型就算参数翻倍也填不出那个字段，纯属浪费算力！NVIDIA 那篇论文里的实验也印证了这点：几款在函数调用和规划推理上平平的开源模型，被塞进精心设计的 Agent 框架后，复杂多步任务成功率直接干翻同等参数量甚至更大的裸模型。同一款弱模型换个 harness 成熟度，通过率能差 30 个百分点。所以别再纠结模型智商了，先把工具调用协议统一了，给每个字段加上显式校验和回滚逻辑，比换更大模型管用得多。
别盯着参数量卷了，快告诉我那个状态机循环怎么搭的——比如论文里说的“每步执行前必读上一步结构化输出”和“失败自动回滚到上一个检查点”，这些确定性逻辑要怎么写？
求个开源地址，顺便看看 LangGraph/LangChain/AutoGen 里哪个更好改造。