让 Agent「读报错、改代码、跑测试」，其中理解报错和生成修改建议的，通常是语言模型；真正读取文件和运行测试的，是外围程序。
这一篇先把模型这一层的词讲清楚。我们用「给模型一段报错，让它分析原因」这个简单场景，贯穿输入、生成和训练。
LLM、Model、Weights，先分清模型和产品
LLM，全称 Large Language Model，是大语言模型。 常见自回归语言模型根据已有内容，逐步生成接下来的 Token。生成结果可以是解释、代码或工具参数。
Model 是训练得到的计算模型；Parameters / Weights 是模型内部的参数和权重。它们不是你在请求里填写的 temperature、输出上限等配置参数。
聊天产品还包括界面、模型请求、工具、账户、历史存储等部分。换一个聊天界面不等于换模型；同一个模型搭配不同工具和上下文，完成任务的表现也可能不同。
这个区别很实用。Agent 查不到文件时，原因可能是根本没有文件工具；补上工具不需要重新训练模型。
Token，模型怎样计算输入和输出
Token 是模型处理文本时使用的单位。Tokenizer 是文本与 Token 编号之间的转换器。 一段中文、英文、代码会怎样切分，要看具体 Tokenizer，不能统一按字符数换算。
| 名称 | 在报错分析任务里是什么 |
|---|---|
| Input Tokens | 用户问题、报错、指令、历史以及可能附带的工具定义 |
| Output Tokens | 模型生成的解释、代码或工具参数 |
| Reasoning Tokens | 某些模型对内部推理资源的计量，展示和预算口径依提供方定义 |
| Context Window | 本次调用可以容纳的上下文范围，输入输出如何共用额度依接口定义 |
报错只有十行，不代表输入只有十行。应用可能还带上几百条历史消息和大量工具定义。
上下文窗口足够大，也不能保证所有信息都被有效利用。相关内容被无关日志包围时，仍可能影响判断。具体怎样整理信息，见 上下文专题。
文本生成及输入编码可参考 Hugging Face 的 Text generation 文档。
Inference 和 Reasoning，为什么都译成推理
Inference 指使用已经训练好的模型计算输出。Reasoning 更强调多步分析和逻辑推导。
模型回答「你好」也做了一次 Inference，但通常不需要复杂 Reasoning。排查一个跨服务故障，则可能需要比较多个假设。
一次自回归生成常分为 Prefill，预填充 和 Decode，解码生成。前者处理已有输入，后者逐步生成后续 Token。
给模型一大份日志，可能增加输入处理开销；让模型写一份很长的报告，可能增加生成开销。两者都让人感觉「慢」，却不发生在同一阶段。
Streaming，流式输出，把内容或事件逐段返回。它改善等待时的反馈，但不自动减少整个任务的总耗时。
Temperature、Top p、Top k，控制的是采样
模型生成下一步内容时，会对候选 Token 给出概率等信号，再按照生成策略选择。
Temperature 调整分布的集中或分散程度。较低设置通常让采样更集中；较高设置可能增加变化。它不能把错误知识改成正确知识。
Top p 按累计概率保留一组候选；Top k 保留概率最高的 K 个候选。这两个 K 和检索中「取前 K 篇文档」的 K，处在不同环节。
Seed 控制部分随机过程。相同 Seed 并不保证模型版本、计算环境和所有服务行为变化后还能完全复现。
下面三个限制也要分开。
| 配置或信号 | 限制或说明什么 |
|---|---|
| Reasoning Effort | 某些模型的思考资源控制，具体档位语义依接口定义 |
| Max Output Tokens | 单次模型生成的输出上限 |
| Agent 的 maxSteps | 外围程序的执行步数上限，步数怎么计要看实现 |
| Stop Reason | 这一次生成为什么停止，比如输出完毕、达到上限或请求工具 |
一次生成结束之后，Agent 可能还需要运行工具、再发起下一次生成。所以看到 Stop Reason，不能直接认定用户任务已完成。
多模态和 VLM，能看和能生成要分别确认
Multimodal，多模态，表示系统支持不止一种信息模态，例如文字、图片、音频。
VLM，Vision-Language Model，视觉语言模型，可以结合图像与文字理解内容。例如根据截图指出保存按钮的位置。
支持图片输入，不自动表示支持图片输出；能读截图，也不自动表示能够操作电脑。点击需要工具，点击之后的业务结果还要检查。
预训练、后训练和微调，改变模型参数
Pretraining，预训练，通常从大量数据中学习基础能力。Post-training，后训练，继续调整指令遵循、偏好或推理等能力。它是较宽的阶段称呼，不等于某一种算法。
Fine-tuning，微调，通过训练调整参数，让模型适应任务或数据。它可以发生在后训练体系中。
| 名称 | 简单理解 | 示例 |
|---|---|---|
| SFT，监督微调 | 用输入和期望输出等样本训练 | 用一批规范的客服问答学习回答方式 |
| RL，强化学习 | 根据奖励等反馈优化策略 | 对可验证任务的结果给反馈 |
| RLHF | 利用人类反馈的强化学习相关方法 | 用人的偏好参与训练反馈体系 |
| RLAIF | 利用 AI 反馈的相关方法 | 用模型评价提供部分反馈 |
| DPO，直接偏好优化 | 利用成对偏好数据优化模型的一类方法 | 给出同一问题下更好和更差的回答 |
| PEFT，参数高效微调 | 只训练较少参数等方法的统称 | 降低完整微调的资源开销 |
| LoRA | 用额外的低秩参数学习适配变化 | 冻结基础权重，训练较小的适配参数 |
这些名字并不是一条必须依次走完的流水线。DPO 与某种 RLHF 流程可以是不同方案；LoRA 描述参数怎样适配，可以与不同训练目标组合。TRL 文档介绍了多个训练方法，PEFT 的 LoRA 文档解释了低秩适配。
给提示词、读 Skill、查 RAG，通常没有重新训练
如果你把「请只根据日志回答」写进输入，模型的行为可能发生变化，但通常没有更新权重。
In-context Learning，上下文学习，指模型通过当前输入的说明和示例适应任务。Zero-shot 不提供任务示例；Few-shot 给少量示例，比如先展示两组规范的报错分析。
读取 Skill、检索文档、把旧经验放进上下文，也通常属于运行时信息组织。它们能让模型拿到更好的依据，却不是微调。
要记住最新接口文档，RAG 常是资料检索这一层的方案；要让某种任务行为稳定下来，则可能涉及提示词、流程、评测，甚至训练。选择方案前，先确认缺的是知识、方法、工具还是模型能力。
蒸馏、量化、MoE，各自改变什么
Distillation，蒸馏，让学生模型学习教师模型的行为。目标可能是保留部分能力，同时减少资源需求；效果要对任务实测。
Quantization，量化，降低部分数值表示的精度，减少存储或计算资源需求。不同精度和实现对效果、速度的影响不同，不能直接说「位数减半，速度就翻倍」。
MoE，Mixture of Experts，混合专家模型，在模型内部使用多个专家模块与路由机制。这里的专家是神经网络组件。
多 Agent 里的「代码审查专家」则是一个任务角色，可能有自己的上下文和工具。MoE 和多 Agent 属于不同层次，不能从「模型有多个专家」推断应用里运行了多个 Agent。
回到那个报错任务
报错进入 Context，Tokenizer 把输入编码为 Token；模型执行 Inference，生成分析或工具请求；工具获取新证据后，应用重新组织下一次输入。
这条链路里，读取文档通常不会改变模型权重，降低 Temperature 不能代替证据，增加输出预算不能代替工具。把三件事分清楚，就知道下一步应该调整哪一层了。
