我的 Agent 之路

从 2023 年初开始，我全身心投入“LLM 的使用”。那时候已经有“agent”这个概念，但是“什么是使用 LLM 的最佳实践”，其实还没有答案。

现在回头看，我当时无意中坚持了一些在当时并不主流的原则，但却越来越像今天的 agent 系统。

No fine-tuning

首先，我坚持不 fine-tune，也不尝试任何修改模型。

最直接的原因当然是 fine-tuning 很麻烦。但更深一层，我一直不太相信 post-training（我说的是某种特定的“领域知识”的 RL，而不是通用的那些）：当我们发现模型的行为不符合预期，于是准备一些数据，设计一个 reward，再修改一组我们其实没有能力理解的参数，直到 benchmark 上的结果变好。

我会认为这在认识论上多少是一种偷懒：我们用优化替代了理解。模型究竟学会了什么，旁边还有什么一起被改掉了，我们往往并不知道。RL 当然可能有用，但我始终觉得不宜做得太多，更不应该把所有缺失的能力和规则都往 RL 里面塞。

当然，在应用层，这个选择还有一个更现实的原因：你花很大力气改出来的模型，大概率打不过下一代大模型。真正值得做的是一个能够直接继承模型进步的系统，而不是围绕某个模型版本重新训练一遍。后来在我们的框架里，Code Llama 和 Llama 本体的表现也基本一致——如果单纯直接给那个任务，Code Llama 的表现当然显著更好；但是沿着我们那一套 workflow，这二者基本就一致了。

No RAG

当年“RAG”这个概念也挺火的。甚至有 reviewer 问我们：“为什么不加 RAG？”

我对 RAG 的反感其实是一脉相承：模型不会做一个任务，不去研究它究竟缺少哪一步推理，而是从语料库里找几段相似文本塞进 prompt。在我看来，这同样是在走捷径。

我毫不怀疑 RAG 可以让 benchmark 上的数字变好。但代码任务并不是信息检索。一个程序是否正确，取决于当前程序的具体语义，而不是另一段相似代码通常怎样写。

如果某个定义或依赖不在当前 context 里，当然需要把它找到。所以我就基于 ctags 搞了一套代码查找：真正有用的反馈来自精准的代码，而不是更多看起来相关的文本。现在的这些 coding agent 很多时候也就是用 grep 去找代码。我的系统里面现在就直接上了 LSP、clangd。如果你有不懂的代码，你应该问编译器。不是瞎猜，不是依赖记忆，也不是随便去找“相似代码”。

No constrained decoding

我一直避免强迫 LLM 输出我们想要的格式。

我的做法是分两步：首先让 LLM 自由地用自然语言总结和推理；然后推理完之后再多走一步，“把上述讨论总结成 JSON”。我一直反对那种“你必须按照下面的格式输出”的做法，这把理解问题和满足接口格式混在了一起。

今天的 reasoning model 某种程度上也在做类似的事：先在内部完成推理，最后再给出答案。结构化输出绝对不能占据整个思考过程。不是不用 JSON，而是不要让模型一边想，一边小心翼翼地维持 JSON。

No temperature = 0

最后是 temperature。

我当时一直在用相当“激进”的 temperature：0.7，甚至 1.0。为此我还专门做了一组实验给老板看，解释为什么这样的设定更好，而不能简单地把 temperature 设成 0 来“避免随机性”。

temperature 0 能让模型给出同一个答案，但同一个答案不等于正确答案。随机性不只是噪声，更是搜索空间。把搜索空间压到 0，然后 greedy 地输出下一个 token，得到的信息往往没有什么用。

现在，主流的 reasoning model 已经不再允许调整 temperature。采样策略逐渐变成了模型内部的实现细节。

回头看，我并没有在 2023 年预见 reasoning model。我的选择只是来自一个朴素的判断：LLM 本来就是一个概率性的提议者，不应该被勉强伪装成确定性程序。

我没有把约束埋进权重，没有把推理塞进 JSON，也没有把 temperature 0 当成可靠性的来源。我把自由留给模型，把确定性放在我自己的 workflow，或者说 prompt engineering，或者说 harness，或者说 loop engineering。

我并不是在尝试制造一个可靠的 LLM；我这些工作的母题是：如果 LLM 就是这么不可靠，我们应该怎么用它？ 某种程度上，2026 年的 LLM 也并没有在本质上比 2023 年的 LLM 更可靠。

这大概就是我的 agent 之路。