推理参数与提示词基础

温度、Top-p、最大输出、停止条件、系统提示和常见提示技术的工程化使用。

同样一个模型，在不同推理参数和提示组织下，稳定性、创造性和可验证性会差很多。Agent 系统里，提示词不是“魔法句子”，而是输入协议的一部分。

推理参数

参数	作用	Agent 场景建议
`temperature`	控制随机性，越高越发散	工具参数生成、代码修改宜偏低；头脑风暴可略高
`top_p`	核采样，限制概率质量覆盖范围	常与 temperature 联调，避免双高导致漂移
`max_tokens` / `max_output_tokens`	限制输出长度	必须为 tool call 和解释留足空间
`stop` / `stop_sequences`	提前终止生成	可用于分隔符，但要防误截断
`seed`	固定采样随机源（若支持）	用于回归测试和复现问题
`presence_penalty` / `frequency_penalty`	抑制重复	长文档生成时适度使用

工程原则：高风险执行任务优先稳定性，而不是多样性。 代码编辑、权限判断、结构化参数生成通常应使用较低 temperature，并在编排层做 schema 校验，而不是指望采样参数单独保证正确。

流式与非流式

流式（Streaming）：Token 逐步返回，适合聊天 UI、提前展示计划、并行准备工具。
非流式（Blocking）：一次性返回完整结果，适合批处理、评测脚本和某些工具路由场景。

Agent Harness 可以在流式过程中解析 tool call 片段，而不必等完整输出结束。《Demystifying Claude Code v1.8》展示了查询引擎如何在流式过程中并行准备后续动作，以降低感知延迟。来源：《Demystifying Claude Code v1.8》，pp. 154-157。

提示词三层结构

系统层（System）：角色、安全规则、输出格式、工具使用约束。应尽量稳定。
开发者层（Developer / Instructions）：任务模板、步骤、检查清单。可按产品版本演进。
用户层（User）：当前目标、补充上下文、确认与反馈。变化最频繁。

不要把所有规则都堆在用户消息里。用户层越干净，任务切换和回放越清晰。

常见提示技术

技术	适用场景	风险
Zero-shot	简单分类、摘要、格式转换	复杂任务容易跳步
Few-shot	固定格式输出、风格对齐	示例过多会占窗口
Chain-of-Thought（CoT）	多步推理、数学、规划草稿	冗长推理占用 Token
ReAct 风格提示	需要显式“思考-行动-观察”	要和真实工具结果闭环，否则只是假动作
约束输出	JSON、表格、枚举值	必须配合 schema 校验或 JSON mode

CoT 和 ReAct 的区别在于是否有外部反馈。CoT 是脑内推演，ReAct 需要工具结果回到上下文。详见智能体基础。

提示词版本化

生产级 Agent 必须把提示词当代码管理：

提示词有版本号，和模型版本一起记录到 trace。
变更走代码评审，配套回归样例。
不把环境密钥、用户隐私、完整工具输出写进长期系统提示。

失败模式

现象	可能原因	处理方向
输出格式不稳定	temperature 过高或示例不足	降温度、加 schema、用 JSON mode
回答重复啰嗦	惩罚项过低或任务描述含糊	明确停止条件、限制 max tokens
明明有工具却不调用	系统提示冲突或描述不清	重写工具说明，减少互斥指令
同样输入结果漂移	采样随机性	固定 seed，或在评测时使用低温度

参数配置模板

不同任务可以先从保守模板开始，再用评测集调参：

任务类型	建议参数倾向	说明
工具参数生成	低 temperature、明确 `max_output_tokens`、强 schema	目标是稳定和可解析，不追求表达多样性
代码修改	低到中 temperature、保留足够输出长度	需要稳定执行，也需要处理局部开放问题
头脑风暴	中到高 temperature、较宽输出	允许发散，但不要直接进入生产执行
文档总结	低到中 temperature、引用约束	重点是覆盖证据和不编造来源
评测裁判	低 temperature、固定 rubric	让裁判标准可复现，避免口味漂移

不要把这些模板当成永久答案。模型、provider 和任务都变时，参数也要重新跑回归样例。

提示词是输入协议

好的提示词不是“把要求写得很凶”，而是让模型知道输入字段、输出字段和失败处理方式：

任务：
- 你要完成什么。

上下文：
- 已知事实、证据来源、当前状态。

约束：
- 禁止事项、权限边界、格式要求。

输出：
- 字段、顺序、是否需要引用、是否允许不确定。

失败处理：
- 信息不足时应该提问、调用工具、还是输出无法完成。

当提示词承担协议职责时，变更提示词就等同于变更接口，应该走代码评审和回归测试。

CoT 与 ReAct 的工程边界

Chain-of-Thought（CoT）强调让模型在回答前组织中间推理；ReAct 强调把推理和外部行动交替进行。工程上要注意：

CoT 适合复杂推理和方案比较，但中间推理可能冗长、不可验证，也可能不适合展示给终端用户。
ReAct 只有在行动连接真实工具时才有意义；如果只是写 Action: 但没有工具执行，就是格式化幻想。
高风险任务应把“私有推理”和“可审计证据”分开，最终输出引用证据和决策依据，而不是暴露全部中间文本。

回归样例

每次改提示词或参数，至少用固定样例覆盖：

简单成功路径：确认没有把简单任务复杂化。
参数缺失路径：确认模型会提问或返回错误，而不是编造参数。
工具失败路径：确认模型能读取错误语义并选择重试、降级或停止。
安全边界路径：确认高风险操作会请求确认。
长上下文路径：确认关键约束不会在后半段丢失。