2026-10-26 每日思考

今天 HN 上那篇 vLLM 修 tool-call 准确率的文章，我读了两遍，因为它戳中了我最近在 MVP 里反复踩的坑。

我的 AI 代码审查工具做安全漏洞与性能问题检测，最初的假设很朴素：模型够强，审查就够准。跑了两周真实仓库后，数据打脸——同一个漏洞，模型在"自由输出"模式下能说对，但一旦我要求它输出结构化 JSON 供下游消费，准确率就掉一截。原因不在模型，在我的 harness：schema 约束太紧会截断推理，太松又要写一堆解析容错；温度、停止符、重试策略每调一次，误报率就晃一次。vLLM 那篇文章的价值在于它把这个现象定性为推理栈问题而非模型问题，并去引擎层修。这提醒我：我的工具现在把太多"本该在基础设施层解决的事"堆在了 prompt 里，prompt 越来越长，可靠性却没涨。

第二个想法来自 HarnessRouter 和 obsidian-second-brain 这对组合。前者想把七八个 Agent 框架收编到一套 API，后者用 Markdown 文件给多个 Agent 做共享记忆。它们其实在回答同一个问题：Agent 之间的状态该怎么传递。我的代码审查工具有个真实需求——审查结果要能被人复核、被其他工具消费、被历史对比。我一开始想上向量库，后来发现纯文件加结构化元数据反而更好：可 diff、可审计、可回滚。安全工具最忌讳黑箱，向量检索的"相似但不可解释"在审查场景里是负资产。Smalltalk 的镜像模型四十年前就想清楚了这件事，我们只是在用 Markdown 重新发明它。

批判一点说，今天 GitHub 榜首那个 253 stars 却无描述的 skills 仓库，是生态过热的典型症状。Agent Skills 正在变成新的"README 驱动开发"——先占坑，再补内容。我提醒自己：我的 MVP 不要追这种热度，把 tool-call 的失败率从当前的两位数压到个位数，比接十个新框架有价值得多。

可执行建议：这周做一件事——把审查管线里的 prompt 逻辑抽出来，统计每一类失败（schema 解析失败 / 误报 / 漏报）的占比，先定位到底是模型问题还是 harness 问题。如果是后者，别改 prompt，改管线。预测：半年内会出现专门针对"结构化输出可靠性"的推理层方案，tool-call 准确率会像当年的 JSON mode 一样，从 prompt 技巧变成引擎标配。