2026-10-07 每日思考

今天翻到 Agent in a Bottle 那篇论文时，我停了一会儿——它问的问题，恰好是我做 AI 代码审查工具这几个月一直在绕的坑。

论文的核心是：能不能让 LLM Agent 把自己的能力固化成"廉价、可扩展的产物"，而不是每次遇到同类问题都重新推理一遍。翻译到我的场景就是：我到底是在做一个"每次 review 都调模型"的产品，还是在做一个"把审查能力沉淀成规则/小模型/静态分析器"的产品？

这两条路的成本结构完全不同。前者按 token 计费，用户越多、代码越多，我的边际成本线性上涨，而且每次结果还有随机性——同一个漏洞，今天报明天不报，这在安全场景里是致命的。后者前期投入重，但一旦某类漏洞能被固化（比如用 AST 匹配 + 数据流分析替代模型判断），边际成本趋近于零，且结果可复现。

我现在的 MVP 是前者。老实说，一开始选它是因为快——接个 API，写个 prompt，两天就能跑起来演示。但跑了几周真实代码之后，我发现一个尴尬的事实：模型在"发现可疑模式"上很强，在"确认这是不是真漏洞"上很不稳定。它会给我一堆似是而非的告警，而开发者最讨厌的就是误报。这逼着我开始做第二件事——把高频、模式明确的漏洞类型（硬编码密钥、SQL 拼接、未校验的反序列化）从模型手里拿走，交给确定性的分析器。

这其实就是论文说的"能力固化"，只是我是被成本和质量逼着做的，不是主动设计的。

由此我有个更批判的看法：现在大量 Agent 产品在宣传"通用能力"，但真正能活下来的，大概率是那些愿意把通用能力一点点拆解、固化、降级成确定性组件的团队。模型应该退到它真正擅长的地方——模糊判断、上下文理解、生成解释——而不是包揽所有环节。Sherpa、IdeaAnchor 那几篇论文也是这个味道：模型不再"替你做完"，而是"帮你判断"。

给同行的建议很具体：如果你的产品每次请求都在调模型做同一类判断，先问自己——这类判断里，有多少比例是可以被规则、小模型或缓存固化的？把那个比例做上去，你的毛利和稳定性会同时改善。

预测一句：未来半年，"Agent 能力蒸馏/固化"会从论文话题变成工程标配，谁先把模型调用量降下来、把确定性提上去，谁就能在价格战里活下来。