LLM 开发里真正让人翻车的很多时候不是模型能力不够而是框架和库帮我们做的那些“默认设置”。你以为不配置就是在使用安全默认值实际上很多默认值只是“能跑通最小示例”的水平离生产可用差得很远。本文想讨论一套我称为LLM Counter-Defaults的思路识别哪些默认行为需要主动反转、需要显式覆盖、需要在工程上加固。这个话题的核心判断是LLM 应用开发中配置显式化比“少写代码”更重要。你每保留一个默认值就相当于把一个不确定性藏在黑盒里。等到线上输出格式乱了、Token 超了、Agent 循环了再回头排查默认配置成本远高于一开始就做反默认设计。这篇文章会从精度选择、推理参数、结构化输出、Agent 行为、RAG 配置和编排框架几个角度展开每个部分都给出可复制的配置示例和排查思路。1. 为什么要讨论 LLM 的 Counter-Defaults先看一个真实场景。团队接入一个大模型 API 后第一版 Prompt 写得很简单调用参数几乎全部用默认值。联调时发现两个问题第一模型偶尔返回空内容和重复句子第二JSON 输出不稳定偶尔夹带 Markdown 代码块标记。排查到最后原因分别是默认的 temperature 偏高、没有做结构化输出约束。这类问题在 LLM 应用里特别普遍因为传统软件开发的默认值往往经过多年验证而 LLM 生态的默认值通常只是“让示例跑起来”。Counter-Defaults 不是一个官方术语而是我在 LLM 应用工程化中总结的一套实践原则凡是影响输出确定性、成本、安全边界和可观测性的默认项都应该显式声明、测试验证并写成团队规范。它包含三个层次第一理解默认值是什么。无论你是直接用 OpenAI SDK、LangChain 这类编排框架还是自研推理服务都要能回答“不传这个参数时框架会怎么处理”。第二判断默认值是否适配自己的场景。不同业务对准确性、创造性、成本、延迟的权重完全不同默认值不会替你判断。第三在必要的地方主动覆盖默认值。覆盖不只是改参数还包括加校验、加重试、加熔断、加审批流。本文后面的内容全部围绕这个三层结构展开。你不需要记住每一个 API 参数但需要建立“默认值审计”的意识。2. LLM 应用为何容易踩中默认值陷阱LLM 应用和传统应用有个本质区别传统 API 的输入输出是强类型结构LLM API 的输入是自然语言输出是概率采样。这意味着默认值的影响会被放大而且很多影响是隐性的。2.1 概率采样导致的不确定性模型生成每次可能不同关键是采样参数。以 temperature 为例为 0 时基本采用最高概率 token结果相对稳定大于 0 时引入随机性输出更多样但可能不稳定。很多 SDK 的默认 temperature 是 1.0 或 0.7这对需要稳定结构的任务来说太高了。一个典型的反默认操作是在实体抽取、JSON 生成、代码生成等任务中主动把 temperature 设置为 0 或接近 0并经过测试验证。2.2 上下文长度与成本的非线性上下文长度不是“越长越好”。默认的 max_tokens 如果太大用户输入很长时可能超限如果太小输出会被截断。更麻烦的是很多框架默认会把历史消息全部塞进上下文导致 Token 消耗随对话轮数线性增长。Counter-Defaults 的做法是显式设置对话窗口长度、压缩策略和 Token 预算。2.3 框架抽象掩盖了底层行为LangChain、LlamaIndex 这类编排框架会替你拼接 Prompt、管理内存、调用工具。听起来很方便但如果你不清楚框架的默认模板和默认执行顺序出了问题很难排。一个常见例子是框架默认注入的 System Prompt 可能与你的业务 Prompt 冲突或者默认的记忆组件会保存大量无用的中间结果。2.4 安全边界的默认缺失LLM 应用特有的风险是工具调用权限过大。模型本身没有“权限”概念如果你提供了一个删除数据的工具模型被 Prompt 注入后可能真的调用。默认情况下框架不会限制模型连续执行多少次工具调用也不会要求人工审批。这是 Agent 类应用最容易出事故的地方。所以讨论 Counter-Defaults 不只是性能优化更是稳定性、成本和安全的工程问题。3. 精度问题是反默认的第一战场fp16、fp32、bf16热词里出现“LLM大模型之精度问题 fp16、fp32、bf16 详解与实践”这确实是 LLM 工程里绕不开的话题。很多初学者以为模型加载后直接用默认精度就行但实际上精度选择会直接影响显存占用、推理速度和输出质量而且在不同硬件上有完全不同的表现。3.1 三种精度的核心区别精度类型位数指数位尾数位特点典型适用场景fp3232823精度高显存占用大训练早期、CPU 推理、调试fp1616510显存减半但数值范围小容易溢出部分 GPU 推理、混合精度训练bf161687数值范围与 fp32 一致精度稍低现代 GPU 推理、大模型训练fp16 和 bf16 都是 16 位但 bf16 保留了和 fp32 相同的指数位所以能表示很大的数值范围不容易出现溢出代价是尾数位少精度低一些。对于神经网络推理来说bf16 通常比 fp16 更安全尤其是模型权重中可能出现较大数值时。3.2 显存占用对比一个 70 亿参数的模型权重文件大小大概是fp32约 28GBfp16 / bf16约 14GB所以如果你在消费级显卡上运行 7B 或 13B 模型默认 fp32 加载很容易爆显存。反默认操作是优先尝试 bf16如果硬件支持否则用 fp16并监控输出质量。3.3 PyTorch 中的显式精度设置如果你使用 Transformers 库加载模型不要完全依赖 auto 模式可以显式指定import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_id your-model-id tokenizer AutoTokenizer.from_pretrained(model_id) # 方式一显式指定 bf16 model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypetorch.bfloat16, device_mapauto ) # 方式二显式指定 fp16 # model AutoModelForCausalLM.from_pretrained( # model_id, # torch_dtypetorch.float16, # device_mapauto # ) # 方式三仅做权重加载推理时再决定 # model AutoModelForCausalLM.from_pretrained( # model_id, # torch_dtypeauto, # device_mapauto # ) text 用一句话解释什么是 Agent。 inputs tokenizer(text, return_tensorspt).to(model.device) outputs model.generate(**inputs, max_new_tokens128) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))这段代码的关键点是torch_dtype。在支持 bf16 的 GPU 上我更推荐 bf16因为它的数值范围更接近 fp32不容易出现 fp16 常见的 NaN 或 Inf 问题。如果你的应用场景对精度极度敏感可以先跑一个验证集对比 bf16 和 fp32 的输出差异。3.4 推理框架层面的精度配置使用 vLLM 这类推理服务时也可以显式指定精度。以 vLLM 启动一个 OpenAI 兼容服务为例python -m vllm.entrypoints.openai.api_server \ --model your-model-id \ --dtype bfloat16 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192这里的--dtype bfloat16就是 Counter-Defaults 的体现。有些部署脚本不传这个参数vLLM 会根据硬件自动选择但自动选择不一定最优。如果你的 GPU 是 V100 这类不支持 bf16 的卡就要用float16如果是 A100、H100 或 RTX 30/40 系列优先bfloat16。3.5 精度选择的判断方法精度选择不是一个“一行配置搞定”的问题建议按下述流程验证用同一个 Prompt 集分别跑 fp32或高精度和候选低精度推理。对比输出文本的相似度、关键字段是否正确、是否存在乱码。监控显存峰值和每秒生成的 token 数。如果是量化模型还要检查是否存在输出质量明显下降。如果输出质量差异可以接受优先使用显存更低的方案这样你可以部署更大的模型或保留更多并发空间。如果差异明显则退回高精度或使用量化感知训练过的模型。4. 推理参数的 Counter-Defaultstemperature、top_p、max_tokens精度之外推理参数是另一组默认值陷阱。OpenAI 兼容 API 通常有 temperature、top_p、max_tokens、stop 等参数。很多人只在出问题时才去看文档结果浪费大量 token 在调试上。4.1 temperature 和 top_p 的组合官方文档通常会说明 temperature 和 top_p 默认值。对于需要确定性的任务我的建议是抽取、分类、改写、代码生成temperature0top_p1或固定为 0.9。文案创作、头脑风暴temperature0.8~1.0top_p默认或稍高。对话助手temperature0.3~0.7根据产品调性调整。注意temperature 和 top_p 一般不要同时剧烈调整建议固定一个、微调另一个。很多框架默认两者都非固定结果输出风格飘忽。4.2 max_tokens 的预算管理max_tokens 决定模型最多生成多少个 token但它包括输出部分不包括输入上下文。理解这一点很重要如果你传入很长的 Prompt而 max_tokens 设置太小输出可能被截断如果设置太大遇到恶意或异常输入时会产生高额费用。反默认做法是对输出长度有上限预期的任务设置相对保守的max_tokens。对开放聊天场景设置一个产品可接受的最大值并在返回结果中检查是否达到截断标志。在服务端做 token 用量统计按用户、按请求维度设置预算。一个常见的完整调用示例from openai import OpenAI client OpenAI() response client.chat.completions.create( modelyour-model-id, messages[ {role: system, content: 你是合同信息抽取助手只输出 JSON。}, {role: user, content: 从以下合同中抽取乙方名称、金额和付款期限。}, {role: user, content: 合同内容...} ], temperature0, top_p1, max_tokens512, stop[###] ) print(response.choices[0].message.content)这个示例里我把 temperature 设为 0 保证稳定性用 stop 标记增加可控性并为 JSON 输出预留了足够但不过分的 max_tokens。4.3 stop 序列的显式定义stop 参数经常被忽略。如果你知道模型的输出应以某个标记结束可以显式传入 stop。比如在一个函数调用场景中模型输出完 JSON 后会附带一个分隔符你可以将这个分隔符设置为 stop让 API 提前停止生成节省 token。5. 结构化输出的反默认JSON 与函数调用的稳定性问题另一个常见问题是让模型输出 JSON它却输出 Markdown 或追加解释文字。热词里的“llm fc 输出/拒识”指的就是函数调用function calling输出与拒识问题。简单说模型可能返回一个不存在的函数名、错误参数或者拒绝调用工具。这些都需要在工程层处理。5.1 不要只靠 Prompt 约束 JSON 输出很多 Prompt 会写“你必须返回 JSON”但模型仍然可能犯错。更可靠的方式是使用模型供应商提供的 JSON Mode如果支持。使用函数调用function calling / tool calling机制让模型输出结构化参数。在后端做 JSON 解析校验解析失败时自动重试一次。以 OpenAI 兼容 API 的 response_format 为例response client.chat.completions.create( modelyour-model-id, messages[ {role: system, content: 只输出 JSON不要包含 Markdown。}, {role: user, content: 抽取这段合同的关键字段。} ], response_format{type: json_object}, temperature0 )注意“json_object”模式通常要求 Prompt 中出现“JSON”字样并且不一定所有模型都支持。更通用的方案是在服务端做解析重试。5.2 函数调用场景的显式校验在 Agent 应用中模型决定调用某个工具并传参。你不能盲目信任模型输出的工具名和参数需要做白名单校验import json # 工具白名单 allowed_tools {get_weather, search_news} def validate_function_call(raw_output: str): try: data json.loads(raw_output) except json.JSONDecodeError: # 可能是模型加了额外说明尝试提取第一个 { 到最后一个 } start raw_output.find({) end raw_output.rfind(}) if start -1 or end -1: raise ValueError(未找到 JSON 内容) data json.loads(raw_output[start:end 1]) if data.get(name) not in allowed_tools: raise ValueError(f非法工具名: {data.get(name)}) return data # 示例模型返回的工具调用结果 model_output {name: delete_database, arguments: {table: users}} try: function_call validate_function_call(model_output) print(通过校验, function_call) except ValueError as e: print(拦截, e)这里的delete_database不在白名单里会被拦截。无论模型是故意还是被 Prompt 注入诱导我们都不应该让它直接执行未授权的工具调用。函数调用是“llm cyber attack”场景的直接入口必须谨慎。5.3 拒识处理拒识refusal是模型因安全策略拒绝回答的情况。产品层面要处理两类模型明确说“我不能回答”。模型返回空内容或重复内容。反默认方案是定义统一的拒识响应格式并在代码中识别这些情况返回给用户友好提示同时记录日志用于后续分析。refusal_patterns [ 我不能回答, 我无法提供, 作为AI, Im sorry, I cannot ] def detect_refusal(text: str) - bool: return any(pattern.lower() in text.lower() for pattern in refusal_patterns) result model_response.choices[0].message.content if detect_refusal(result): print(检测到拒识返回兜底内容并记录日志) else: print(正常输出)需要注意拒识检测也不能只靠关键词但在工程上这是一个低成本的兜底策略。更完善的方案是训练一个分类模型或在应用层结合多路校验。6. Agent 行为控制防止“过度执行”热词里有一组很有意思的内容“bp 靶场 exploiting llm apis with excessive agency”“llm powered autonomous agents”。前者想表达的是 LLM API 存在“过度授权excessive agency”风险后者是自主 Agent 方向。这可以说是 LLM 应用里最需要 Counter-Defaults 意识的领域。6.1 什么是 excessive agency当一个 Agent 被赋予过多工具权限并且缺少人工确认时模型可能会执行超出用户预期的高危操作。比如一个客服 Agent 只应查询订单状态但如果它同时被赋予了“修改订单”“删除用户”的工具攻击者可能通过 Prompt 注入让它执行这些操作。Counter-Defaults 提出的原则是最小权限 显式审批 执行上限。最小权限每个 Agent 只获得完成其任务所需的最少工具。显式审批高危操作删除、修改、付款、发送消息必须经过人工确认。执行上限限制单轮对话中最多执行多少次工具调用防止死循环。6.2 在 LangChain 或自研 Agent 中限制工具不管用哪套框架核心逻辑都是一样的在执行工具前检查权限在执行后记录审计日志。以自研一个简单 Agent 循环为例import json TOOLS { query_order: { desc: 查询订单状态, permission: read_only, func: lambda args: {order_status: 已发货} }, cancel_order: { desc: 取消订单, permission: high_risk, func: lambda args: {result: 订单已取消} }, } MAX_TOOL_CALLS 5 def execute_agent(user_input, history): tool_calls 0 messages history [{role: user, content: user_input}] while tool_calls MAX_TOOL_CALLS: response llm_call(messages) tool_call extract_tool_call(response) if tool_call is None: # 模型决定直接回复用户 return response tool_name tool_call[name] if tool_name not in TOOLS: # 工具不存在时终止本轮避免模型胡编工具名 return 抱歉我无法完成这个操作。工具不存在。 tool_config TOOLS[tool_name] if tool_config[permission] in (high_risk, write): # 高危操作必须人工确认 ok request_user_approval(tool_name, tool_call[arguments]) if not ok: return 操作已取消 # 在实际系统中应将人工确认结果写入审计日志 result tool_config[func](tool_call[arguments]) tool_calls 1 messages.append({ role: function, name: tool_name, content: json.dumps(result, ensure_asciiFalse) }) # 超过执行上限 return 操作次数过多已停止执行。请简化请求。这段代码将cancel_order标记为high_risk执行前必须人工确认同时限制了最大工具调用次数。这个设计能有效降低 excessive agency 风险。6.3 人工审批与审计日志生产环境里高危操作除了人工审批外还需要做审计日志谁发起了这个请求。模型调用了哪个工具。传入了什么参数。人工审批人是谁。审批时间、执行结果。没有审计日志出了问题很难定位责任。这也是“默认不会帮你做”的部分必须自己在框架里补上。7. RAG 的默认配置改造chunk、embedding 与 top_k检索增强生成RAG是当前落地最广泛的 LLM 应用范式。但它的默认配置问题也不少默认 chunk 大小可能破坏语义、默认 top_k 可能引入噪声、默认 embedding 模型可能不适合中文或领域文本。热词里也有“llm 应用为什么需要编排框架”“rag”相关内容这正好串联起来。7.1 chunk 不能照搬默认值很多向量数据库或 RAG 框架默认按固定长度切分文本比如 500 或 1000 字符。这会导致两个问题切得太碎同一句话的上下文被拆开检索时语义不完整。切得太大向量表征模糊检索噪声大同时浪费 token。反默认做法是根据文档结构切分保留标题层级尽量让每个 chunk 表达一个完整语义单元。一个简单的自定义切分思路def split_markdown_by_heading(markdown_text, max_chars800): lines markdown_text.split(\n) chunks [] current_chunk [] current_len 0 for line in lines: if line.startswith(#) and current_chunk: chunks.append(\n.join(current_chunk)) current_chunk [] current_len 0 current_chunk.append(line) current_len len(line) if current_len max_chars: chunks.append(\n.join(current_chunk)) current_chunk [] current_len 0 if current_chunk: chunks.append(\n.join(current_chunk)) return chunks这只是一个示例实际要根据你的文档类型设计。关键点是不要直接接受框架默认的切分器先看它切出来的效果。7.2 embedding 模型按文本类型选择通用 embedding 模型在垂直领域效果不一定好。如果你做的是法律、医疗、代码搜索建议在领域数据集上对比几个候选模型的效果。评测维度可以包括检索命中率recallk。相似度排序是否符合直觉。向量维度与存储成本。中文或领域术语的分词效果。如果领域差异大可以考虑微调 embedding 模型但这是成本较高的方案需要根据业务规模判断。7.3 top_k、score 阈值与重排默认 top_k 可能过大或过小。推荐做法是先召回 top_k 较大的候选集再做重排rerank最后取 top_n。同时设置 score 阈值过滤掉相似度过低的内容。def rag_answer(query, retriever, reranker, generate_func): # 1. 召回候选集 candidates retriever.search(query, top_k20) # 2. 重排 ranked reranker.rerank(query, candidates) # 3. 按阈值过滤 filtered [doc for doc in ranked if doc.score 0.35] # 4. 取 top 3 拼接上下文 context \n.join([doc.text for doc in filtered[:3]]) # 5. 生成回答 return generate_func(query, context)这里的核心是“先扩召回再精排”。只依赖向量检索默认排序往往会漏掉正确答案。8. 为什么 LLM 应用需要编排框架又需要反默认热词里反复出现“llm 应用为什么需要编排框架”“llm 框架”“mcp client 与 llm 连接”。我的判断是编排框架解决了工程化问题但会引入新的抽象层默认行为越来越多越需要 Counter-Defaults 意识。8.1 编排框架解决什么编排框架至少解决了四类问题Prompt 生命周期的管理。多步调用和状态维护。工具接入与 Agent 循环。可观测性和回退机制。像 LangChain、LlamaIndex、Spring AI、自研编排层都在不同层面做这些事。对团队来说选型的关键不是“谁最火”而是“谁的抽象层次适合我们的工程能力”。8.2 框架新增的默认陷阱框架也带来了新的默认设置默认的 Prompt 模板可能覆盖你对 System Prompt 的精调。默认的记忆策略可能把过多历史塞进上下文。默认的解析器可能把模型输出强转成特定对象失败时抛异常。默认的重试逻辑可能隐藏了真实错误原因。所以我的建议是在任何编排框架里不要把“框架能跑通 Demo”等同于“框架适合生产”。花时间读完框架核心组件的默认配置逐个过一遍决定哪些使用、哪些覆盖、哪些弃用。8.3 编排框架中的显式配置示例以 LangChain 的风格为例版本不同 API 可能有差异思路一致from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent from langchain.memory import ConversationBufferWindowMemory llm ChatOpenAI( modelyour-model-id, temperature0, max_tokens1024, ) memory ConversationBufferWindowMemory( k5, return_messagesTrue, ) system_prompt ( 你是订单助手。你可以查询订单状态和物流信息。\n 不允许执行任何修改、删除、取消操作。\n 如果用户提出这些请求请礼貌拒绝并建议联系人工客服。 ) agent create_react_agent( llmllm, tools[query_order_tool, query_logistics_tool], prompt_templatesystem_prompt, )这个配置的关键点是temperature 显式设为 0记忆窗口限制为最近的 5 轮System Prompt 里直接声明了工具权限边界并且只传入只读工具。这些都是对框架默认行为的显式覆盖。9. 环境搭建与工具链推荐把上面的原则落地到实际项目时环境搭建往往是第一道坎。为了避免文章停留在概念层面这里给出一个最小但完整的开发环境建议。9.1 本机开发环境Python 3.10 或 3.11。一个支持 OpenAI 兼容 API 的模型服务可以是云端 API也可以是本地推理服务。LangChain 或自研工具库。向量数据库如 Milvus、Chroma、PGVector用于做 RAG。Debug 工具OpenAI 兼容接口的日志面板、LangSmith 或自研日志系统。如果你在本地跑开源模型可以用 vLLM 或 llama.cpp 启动一个 OpenAI 兼容服务。启动命令的精度参数要参考第 3 节的建议。9.2 最小项目结构llm-counter-defaults-demo/ ├── configs/ │ └── llm.yaml ├── core/ │ ├── llm_client.py │ ├── parser.py │ ├── tool_guard.py │ └── rag.py ├── pipelines/ │ ├── chat_pipeline.py │ └── rag_pipeline.py ├── tests/ │ └── test_tool_guard.py └── main.py这个结构把 LLM 客户端、解析校验、工具安全、RAG 逻辑分开便于测试和维护。9.3 配置管理配置不要散落在代码里建议统一管理。用 YAML 存模型参数、工具清单和权限策略# configs/llm.yaml model: provider: openai_compatible model_name: your-model-id dtype: bfloat16 inference: temperature: 0 top_p: 1 max_tokens: 1024 stop: - ### security: allowed_tools: - query_order - query_logistics require_approval_tools: - cancel_order max_tool_calls: 5 rag: retriever_top_k: 20 rerank_top_n: 3 score_threshold: 0.35这套配置的好处是修改参数不需要改代码也方便做多环境切换。团队里新增成员时先看配置就能理解应用的安全边界。10. 常见问题与排查方法下面整理 LLM 应用开发中经常遇到的问题按现象分类给出排查思路。问题现象可能原因排查方式解决方案模型输出不稳定同一句话每次不同temperature 或 top_p 偏高查看调用日志中的实际参数显式设置 temperature0固定 top_p输出被截断max_tokens 设置过小查看返回内容的 finish_reason 是否为 length调大 max_tokens或优化 Prompt 缩短输出JSON 解析失败模型输出带 Markdown 或解释文字打印原始响应启用 JSON Mode / response_format后端解析重试Agent 无限循环调用工具缺少最大调用次数限制看日志中工具调用序列加入 max_tool_calls设置合理的 Agent 终止条件显存不足模型以 fp32 加载查看 nvidia-smi 显存占用切换 bf16/fp16或使用量化版本RAG 检索结果不相关chunk 切分不合理或 top_k 过大检索测试查看召回片段结构化切分、加 rerank、设置 score 阈值模型拒绝执行已授权的工具工具名不在模型看到的列表中检查工具描述和 function calling 配置确保工具 schema 正确模型版本支持 function calling成本快速增长上下文无限累积查看每次请求的 token 数使用窗口记忆、做摘要压缩、限制输入长度每条问题背后都对应一个“默认值”。排查的第一步不是改代码而是打印完整请求和响应日志确认实际生效的默认值是什么。很多看似诡异的问题一旦把参数显式打印出来原因立刻清楚。11. 最佳实践与工程建议把 Counter-Defaults 落实到团队和项目需要一套规范化做法不只是改几个参数。11.1 建立默认值审计清单每次引入新框架、新模型或新 API团队都应按清单过一遍列出所有默认参数值。逐个判断是否适用当前业务。不适用就显式覆盖并写清楚原因。保留一份“当前生效参数”的文档或配置。审计清单可以用上面的 YAML 配置作为起点持续补充。11.2 测试中增加确定性用例LLM 应用也要写测试但测试重点不是“输出完全正确”而是固定输入下输出是否符合结构要求。温度设 0 时多次运行结果是否基本一致。解析器对异常输出的兜底是否正常。高危工具是否被正确拦截。pytest tests/test_tool_guard.py -v测试一旦跑通后续升级模型或改 Prompt 时能快速发现回归问题。11.3 日志与可观测性没有日志就没有一切排查能力。推荐至少记录请求 ID、用户 ID。模型名称、参数配置。Prompt 和完整响应。token 用量。工具调用记录和审批记录。运行耗时和错误信息。日志要避免记录个人敏感信息。如果需要记录完整 Prompt注意做脱敏处理。11.4 安全边界和最小权限这个原则在产品上线前必须明确模型能访问哪些工具。哪些工具需要人工审批。单次请求最多执行多少次工具调用。数据库操作是否只允许只读账号。是否有审计日志。不要因为模型“看起来智能”就给它更多权限。它只是一个基于概率的文本生成系统不具备真正的判断力和责任意识。11.5 版本管理与回滚Prompt、模型参数、向量库索引、工具 schema 都是需要版本管理的资产。建议把 prompt 和配置存到 Git 仓库改动走 PR 评审。线上出现问题时要能快速回滚到上一版配置。12. 总结与后续学习方向围绕 LLM Counter-Defaults这篇文章真正想讲清楚的是LLM 应用工程化的核心难点不是“让模型理解需求”而是控制那些影响确定性、成本和安全的不稳定变量。默认值不是标准答案只是一个起点。真正可靠的配置来自你对业务场景的分析、对框架行为的理解以及一套系统化的验证流程。下一步的实践路径建议如下第一找一个小型业务场景把本文提到的配置项逐个过一遍精度、推理参数、JSON 输出、Agent 工具权限、RAG chunk。先用最小示例跑通再逐步加复杂度。第二读一遍你正在用的框架源码或文档中关于默认配置的部分。不要求通读但至少要会搜索“默认值”“参数说明”“安全策略”相关的章节。第三建立一个简单的可观测性看板把每类请求的 token 用量、失败率、工具调用次数记录下来。这些数据会告诉你下一步优化方向。LLM 生态还在快速变化框架版本、模型能力、价格策略都会变。但无论工具怎么变“把不确定性显式化把权限边界显式化把可观测性做起来”这套思路不会过时。建议收藏这篇文章等你在实际项目中踩到对应问题时再回来对照排查。 LLM反默认配置：精度、参数与安全边界显式化
LLM 开发里真正让人翻车的很多时候不是模型能力不够而是框架和库帮我们做的那些“默认设置”。你以为不配置就是在使用安全默认值实际上很多默认值只是“能跑通最小示例”的水平离生产可用差得很远。本文想讨论一套我称为LLM Counter-Defaults的思路识别哪些默认行为需要主动反转、需要显式覆盖、需要在工程上加固。这个话题的核心判断是LLM 应用开发中配置显式化比“少写代码”更重要。你每保留一个默认值就相当于把一个不确定性藏在黑盒里。等到线上输出格式乱了、Token 超了、Agent 循环了再回头排查默认配置成本远高于一开始就做反默认设计。这篇文章会从精度选择、推理参数、结构化输出、Agent 行为、RAG 配置和编排框架几个角度展开每个部分都给出可复制的配置示例和排查思路。1. 为什么要讨论 LLM 的 Counter-Defaults先看一个真实场景。团队接入一个大模型 API 后第一版 Prompt 写得很简单调用参数几乎全部用默认值。联调时发现两个问题第一模型偶尔返回空内容和重复句子第二JSON 输出不稳定偶尔夹带 Markdown 代码块标记。排查到最后原因分别是默认的 temperature 偏高、没有做结构化输出约束。这类问题在 LLM 应用里特别普遍因为传统软件开发的默认值往往经过多年验证而 LLM 生态的默认值通常只是“让示例跑起来”。Counter-Defaults 不是一个官方术语而是我在 LLM 应用工程化中总结的一套实践原则凡是影响输出确定性、成本、安全边界和可观测性的默认项都应该显式声明、测试验证并写成团队规范。它包含三个层次第一理解默认值是什么。无论你是直接用 OpenAI SDK、LangChain 这类编排框架还是自研推理服务都要能回答“不传这个参数时框架会怎么处理”。第二判断默认值是否适配自己的场景。不同业务对准确性、创造性、成本、延迟的权重完全不同默认值不会替你判断。第三在必要的地方主动覆盖默认值。覆盖不只是改参数还包括加校验、加重试、加熔断、加审批流。本文后面的内容全部围绕这个三层结构展开。你不需要记住每一个 API 参数但需要建立“默认值审计”的意识。2. LLM 应用为何容易踩中默认值陷阱LLM 应用和传统应用有个本质区别传统 API 的输入输出是强类型结构LLM API 的输入是自然语言输出是概率采样。这意味着默认值的影响会被放大而且很多影响是隐性的。2.1 概率采样导致的不确定性模型生成每次可能不同关键是采样参数。以 temperature 为例为 0 时基本采用最高概率 token结果相对稳定大于 0 时引入随机性输出更多样但可能不稳定。很多 SDK 的默认 temperature 是 1.0 或 0.7这对需要稳定结构的任务来说太高了。一个典型的反默认操作是在实体抽取、JSON 生成、代码生成等任务中主动把 temperature 设置为 0 或接近 0并经过测试验证。2.2 上下文长度与成本的非线性上下文长度不是“越长越好”。默认的 max_tokens 如果太大用户输入很长时可能超限如果太小输出会被截断。更麻烦的是很多框架默认会把历史消息全部塞进上下文导致 Token 消耗随对话轮数线性增长。Counter-Defaults 的做法是显式设置对话窗口长度、压缩策略和 Token 预算。2.3 框架抽象掩盖了底层行为LangChain、LlamaIndex 这类编排框架会替你拼接 Prompt、管理内存、调用工具。听起来很方便但如果你不清楚框架的默认模板和默认执行顺序出了问题很难排。一个常见例子是框架默认注入的 System Prompt 可能与你的业务 Prompt 冲突或者默认的记忆组件会保存大量无用的中间结果。2.4 安全边界的默认缺失LLM 应用特有的风险是工具调用权限过大。模型本身没有“权限”概念如果你提供了一个删除数据的工具模型被 Prompt 注入后可能真的调用。默认情况下框架不会限制模型连续执行多少次工具调用也不会要求人工审批。这是 Agent 类应用最容易出事故的地方。所以讨论 Counter-Defaults 不只是性能优化更是稳定性、成本和安全的工程问题。3. 精度问题是反默认的第一战场fp16、fp32、bf16热词里出现“LLM大模型之精度问题 fp16、fp32、bf16 详解与实践”这确实是 LLM 工程里绕不开的话题。很多初学者以为模型加载后直接用默认精度就行但实际上精度选择会直接影响显存占用、推理速度和输出质量而且在不同硬件上有完全不同的表现。3.1 三种精度的核心区别精度类型位数指数位尾数位特点典型适用场景fp3232823精度高显存占用大训练早期、CPU 推理、调试fp1616510显存减半但数值范围小容易溢出部分 GPU 推理、混合精度训练bf161687数值范围与 fp32 一致精度稍低现代 GPU 推理、大模型训练fp16 和 bf16 都是 16 位但 bf16 保留了和 fp32 相同的指数位所以能表示很大的数值范围不容易出现溢出代价是尾数位少精度低一些。对于神经网络推理来说bf16 通常比 fp16 更安全尤其是模型权重中可能出现较大数值时。3.2 显存占用对比一个 70 亿参数的模型权重文件大小大概是fp32约 28GBfp16 / bf16约 14GB所以如果你在消费级显卡上运行 7B 或 13B 模型默认 fp32 加载很容易爆显存。反默认操作是优先尝试 bf16如果硬件支持否则用 fp16并监控输出质量。3.3 PyTorch 中的显式精度设置如果你使用 Transformers 库加载模型不要完全依赖 auto 模式可以显式指定import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_id your-model-id tokenizer AutoTokenizer.from_pretrained(model_id) # 方式一显式指定 bf16 model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypetorch.bfloat16, device_mapauto ) # 方式二显式指定 fp16 # model AutoModelForCausalLM.from_pretrained( # model_id, # torch_dtypetorch.float16, # device_mapauto # ) # 方式三仅做权重加载推理时再决定 # model AutoModelForCausalLM.from_pretrained( # model_id, # torch_dtypeauto, # device_mapauto # ) text 用一句话解释什么是 Agent。 inputs tokenizer(text, return_tensorspt).to(model.device) outputs model.generate(**inputs, max_new_tokens128) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))这段代码的关键点是torch_dtype。在支持 bf16 的 GPU 上我更推荐 bf16因为它的数值范围更接近 fp32不容易出现 fp16 常见的 NaN 或 Inf 问题。如果你的应用场景对精度极度敏感可以先跑一个验证集对比 bf16 和 fp32 的输出差异。3.4 推理框架层面的精度配置使用 vLLM 这类推理服务时也可以显式指定精度。以 vLLM 启动一个 OpenAI 兼容服务为例python -m vllm.entrypoints.openai.api_server \ --model your-model-id \ --dtype bfloat16 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192这里的--dtype bfloat16就是 Counter-Defaults 的体现。有些部署脚本不传这个参数vLLM 会根据硬件自动选择但自动选择不一定最优。如果你的 GPU 是 V100 这类不支持 bf16 的卡就要用float16如果是 A100、H100 或 RTX 30/40 系列优先bfloat16。3.5 精度选择的判断方法精度选择不是一个“一行配置搞定”的问题建议按下述流程验证用同一个 Prompt 集分别跑 fp32或高精度和候选低精度推理。对比输出文本的相似度、关键字段是否正确、是否存在乱码。监控显存峰值和每秒生成的 token 数。如果是量化模型还要检查是否存在输出质量明显下降。如果输出质量差异可以接受优先使用显存更低的方案这样你可以部署更大的模型或保留更多并发空间。如果差异明显则退回高精度或使用量化感知训练过的模型。4. 推理参数的 Counter-Defaultstemperature、top_p、max_tokens精度之外推理参数是另一组默认值陷阱。OpenAI 兼容 API 通常有 temperature、top_p、max_tokens、stop 等参数。很多人只在出问题时才去看文档结果浪费大量 token 在调试上。4.1 temperature 和 top_p 的组合官方文档通常会说明 temperature 和 top_p 默认值。对于需要确定性的任务我的建议是抽取、分类、改写、代码生成temperature0top_p1或固定为 0.9。文案创作、头脑风暴temperature0.8~1.0top_p默认或稍高。对话助手temperature0.3~0.7根据产品调性调整。注意temperature 和 top_p 一般不要同时剧烈调整建议固定一个、微调另一个。很多框架默认两者都非固定结果输出风格飘忽。4.2 max_tokens 的预算管理max_tokens 决定模型最多生成多少个 token但它包括输出部分不包括输入上下文。理解这一点很重要如果你传入很长的 Prompt而 max_tokens 设置太小输出可能被截断如果设置太大遇到恶意或异常输入时会产生高额费用。反默认做法是对输出长度有上限预期的任务设置相对保守的max_tokens。对开放聊天场景设置一个产品可接受的最大值并在返回结果中检查是否达到截断标志。在服务端做 token 用量统计按用户、按请求维度设置预算。一个常见的完整调用示例from openai import OpenAI client OpenAI() response client.chat.completions.create( modelyour-model-id, messages[ {role: system, content: 你是合同信息抽取助手只输出 JSON。}, {role: user, content: 从以下合同中抽取乙方名称、金额和付款期限。}, {role: user, content: 合同内容...} ], temperature0, top_p1, max_tokens512, stop[###] ) print(response.choices[0].message.content)这个示例里我把 temperature 设为 0 保证稳定性用 stop 标记增加可控性并为 JSON 输出预留了足够但不过分的 max_tokens。4.3 stop 序列的显式定义stop 参数经常被忽略。如果你知道模型的输出应以某个标记结束可以显式传入 stop。比如在一个函数调用场景中模型输出完 JSON 后会附带一个分隔符你可以将这个分隔符设置为 stop让 API 提前停止生成节省 token。5. 结构化输出的反默认JSON 与函数调用的稳定性问题另一个常见问题是让模型输出 JSON它却输出 Markdown 或追加解释文字。热词里的“llm fc 输出/拒识”指的就是函数调用function calling输出与拒识问题。简单说模型可能返回一个不存在的函数名、错误参数或者拒绝调用工具。这些都需要在工程层处理。5.1 不要只靠 Prompt 约束 JSON 输出很多 Prompt 会写“你必须返回 JSON”但模型仍然可能犯错。更可靠的方式是使用模型供应商提供的 JSON Mode如果支持。使用函数调用function calling / tool calling机制让模型输出结构化参数。在后端做 JSON 解析校验解析失败时自动重试一次。以 OpenAI 兼容 API 的 response_format 为例response client.chat.completions.create( modelyour-model-id, messages[ {role: system, content: 只输出 JSON不要包含 Markdown。}, {role: user, content: 抽取这段合同的关键字段。} ], response_format{type: json_object}, temperature0 )注意“json_object”模式通常要求 Prompt 中出现“JSON”字样并且不一定所有模型都支持。更通用的方案是在服务端做解析重试。5.2 函数调用场景的显式校验在 Agent 应用中模型决定调用某个工具并传参。你不能盲目信任模型输出的工具名和参数需要做白名单校验import json # 工具白名单 allowed_tools {get_weather, search_news} def validate_function_call(raw_output: str): try: data json.loads(raw_output) except json.JSONDecodeError: # 可能是模型加了额外说明尝试提取第一个 { 到最后一个 } start raw_output.find({) end raw_output.rfind(}) if start -1 or end -1: raise ValueError(未找到 JSON 内容) data json.loads(raw_output[start:end 1]) if data.get(name) not in allowed_tools: raise ValueError(f非法工具名: {data.get(name)}) return data # 示例模型返回的工具调用结果 model_output {name: delete_database, arguments: {table: users}} try: function_call validate_function_call(model_output) print(通过校验, function_call) except ValueError as e: print(拦截, e)这里的delete_database不在白名单里会被拦截。无论模型是故意还是被 Prompt 注入诱导我们都不应该让它直接执行未授权的工具调用。函数调用是“llm cyber attack”场景的直接入口必须谨慎。5.3 拒识处理拒识refusal是模型因安全策略拒绝回答的情况。产品层面要处理两类模型明确说“我不能回答”。模型返回空内容或重复内容。反默认方案是定义统一的拒识响应格式并在代码中识别这些情况返回给用户友好提示同时记录日志用于后续分析。refusal_patterns [ 我不能回答, 我无法提供, 作为AI, Im sorry, I cannot ] def detect_refusal(text: str) - bool: return any(pattern.lower() in text.lower() for pattern in refusal_patterns) result model_response.choices[0].message.content if detect_refusal(result): print(检测到拒识返回兜底内容并记录日志) else: print(正常输出)需要注意拒识检测也不能只靠关键词但在工程上这是一个低成本的兜底策略。更完善的方案是训练一个分类模型或在应用层结合多路校验。6. Agent 行为控制防止“过度执行”热词里有一组很有意思的内容“bp 靶场 exploiting llm apis with excessive agency”“llm powered autonomous agents”。前者想表达的是 LLM API 存在“过度授权excessive agency”风险后者是自主 Agent 方向。这可以说是 LLM 应用里最需要 Counter-Defaults 意识的领域。6.1 什么是 excessive agency当一个 Agent 被赋予过多工具权限并且缺少人工确认时模型可能会执行超出用户预期的高危操作。比如一个客服 Agent 只应查询订单状态但如果它同时被赋予了“修改订单”“删除用户”的工具攻击者可能通过 Prompt 注入让它执行这些操作。Counter-Defaults 提出的原则是最小权限 显式审批 执行上限。最小权限每个 Agent 只获得完成其任务所需的最少工具。显式审批高危操作删除、修改、付款、发送消息必须经过人工确认。执行上限限制单轮对话中最多执行多少次工具调用防止死循环。6.2 在 LangChain 或自研 Agent 中限制工具不管用哪套框架核心逻辑都是一样的在执行工具前检查权限在执行后记录审计日志。以自研一个简单 Agent 循环为例import json TOOLS { query_order: { desc: 查询订单状态, permission: read_only, func: lambda args: {order_status: 已发货} }, cancel_order: { desc: 取消订单, permission: high_risk, func: lambda args: {result: 订单已取消} }, } MAX_TOOL_CALLS 5 def execute_agent(user_input, history): tool_calls 0 messages history [{role: user, content: user_input}] while tool_calls MAX_TOOL_CALLS: response llm_call(messages) tool_call extract_tool_call(response) if tool_call is None: # 模型决定直接回复用户 return response tool_name tool_call[name] if tool_name not in TOOLS: # 工具不存在时终止本轮避免模型胡编工具名 return 抱歉我无法完成这个操作。工具不存在。 tool_config TOOLS[tool_name] if tool_config[permission] in (high_risk, write): # 高危操作必须人工确认 ok request_user_approval(tool_name, tool_call[arguments]) if not ok: return 操作已取消 # 在实际系统中应将人工确认结果写入审计日志 result tool_config[func](tool_call[arguments]) tool_calls 1 messages.append({ role: function, name: tool_name, content: json.dumps(result, ensure_asciiFalse) }) # 超过执行上限 return 操作次数过多已停止执行。请简化请求。这段代码将cancel_order标记为high_risk执行前必须人工确认同时限制了最大工具调用次数。这个设计能有效降低 excessive agency 风险。6.3 人工审批与审计日志生产环境里高危操作除了人工审批外还需要做审计日志谁发起了这个请求。模型调用了哪个工具。传入了什么参数。人工审批人是谁。审批时间、执行结果。没有审计日志出了问题很难定位责任。这也是“默认不会帮你做”的部分必须自己在框架里补上。7. RAG 的默认配置改造chunk、embedding 与 top_k检索增强生成RAG是当前落地最广泛的 LLM 应用范式。但它的默认配置问题也不少默认 chunk 大小可能破坏语义、默认 top_k 可能引入噪声、默认 embedding 模型可能不适合中文或领域文本。热词里也有“llm 应用为什么需要编排框架”“rag”相关内容这正好串联起来。7.1 chunk 不能照搬默认值很多向量数据库或 RAG 框架默认按固定长度切分文本比如 500 或 1000 字符。这会导致两个问题切得太碎同一句话的上下文被拆开检索时语义不完整。切得太大向量表征模糊检索噪声大同时浪费 token。反默认做法是根据文档结构切分保留标题层级尽量让每个 chunk 表达一个完整语义单元。一个简单的自定义切分思路def split_markdown_by_heading(markdown_text, max_chars800): lines markdown_text.split(\n) chunks [] current_chunk [] current_len 0 for line in lines: if line.startswith(#) and current_chunk: chunks.append(\n.join(current_chunk)) current_chunk [] current_len 0 current_chunk.append(line) current_len len(line) if current_len max_chars: chunks.append(\n.join(current_chunk)) current_chunk [] current_len 0 if current_chunk: chunks.append(\n.join(current_chunk)) return chunks这只是一个示例实际要根据你的文档类型设计。关键点是不要直接接受框架默认的切分器先看它切出来的效果。7.2 embedding 模型按文本类型选择通用 embedding 模型在垂直领域效果不一定好。如果你做的是法律、医疗、代码搜索建议在领域数据集上对比几个候选模型的效果。评测维度可以包括检索命中率recallk。相似度排序是否符合直觉。向量维度与存储成本。中文或领域术语的分词效果。如果领域差异大可以考虑微调 embedding 模型但这是成本较高的方案需要根据业务规模判断。7.3 top_k、score 阈值与重排默认 top_k 可能过大或过小。推荐做法是先召回 top_k 较大的候选集再做重排rerank最后取 top_n。同时设置 score 阈值过滤掉相似度过低的内容。def rag_answer(query, retriever, reranker, generate_func): # 1. 召回候选集 candidates retriever.search(query, top_k20) # 2. 重排 ranked reranker.rerank(query, candidates) # 3. 按阈值过滤 filtered [doc for doc in ranked if doc.score 0.35] # 4. 取 top 3 拼接上下文 context \n.join([doc.text for doc in filtered[:3]]) # 5. 生成回答 return generate_func(query, context)这里的核心是“先扩召回再精排”。只依赖向量检索默认排序往往会漏掉正确答案。8. 为什么 LLM 应用需要编排框架又需要反默认热词里反复出现“llm 应用为什么需要编排框架”“llm 框架”“mcp client 与 llm 连接”。我的判断是编排框架解决了工程化问题但会引入新的抽象层默认行为越来越多越需要 Counter-Defaults 意识。8.1 编排框架解决什么编排框架至少解决了四类问题Prompt 生命周期的管理。多步调用和状态维护。工具接入与 Agent 循环。可观测性和回退机制。像 LangChain、LlamaIndex、Spring AI、自研编排层都在不同层面做这些事。对团队来说选型的关键不是“谁最火”而是“谁的抽象层次适合我们的工程能力”。8.2 框架新增的默认陷阱框架也带来了新的默认设置默认的 Prompt 模板可能覆盖你对 System Prompt 的精调。默认的记忆策略可能把过多历史塞进上下文。默认的解析器可能把模型输出强转成特定对象失败时抛异常。默认的重试逻辑可能隐藏了真实错误原因。所以我的建议是在任何编排框架里不要把“框架能跑通 Demo”等同于“框架适合生产”。花时间读完框架核心组件的默认配置逐个过一遍决定哪些使用、哪些覆盖、哪些弃用。8.3 编排框架中的显式配置示例以 LangChain 的风格为例版本不同 API 可能有差异思路一致from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent from langchain.memory import ConversationBufferWindowMemory llm ChatOpenAI( modelyour-model-id, temperature0, max_tokens1024, ) memory ConversationBufferWindowMemory( k5, return_messagesTrue, ) system_prompt ( 你是订单助手。你可以查询订单状态和物流信息。\n 不允许执行任何修改、删除、取消操作。\n 如果用户提出这些请求请礼貌拒绝并建议联系人工客服。 ) agent create_react_agent( llmllm, tools[query_order_tool, query_logistics_tool], prompt_templatesystem_prompt, )这个配置的关键点是temperature 显式设为 0记忆窗口限制为最近的 5 轮System Prompt 里直接声明了工具权限边界并且只传入只读工具。这些都是对框架默认行为的显式覆盖。9. 环境搭建与工具链推荐把上面的原则落地到实际项目时环境搭建往往是第一道坎。为了避免文章停留在概念层面这里给出一个最小但完整的开发环境建议。9.1 本机开发环境Python 3.10 或 3.11。一个支持 OpenAI 兼容 API 的模型服务可以是云端 API也可以是本地推理服务。LangChain 或自研工具库。向量数据库如 Milvus、Chroma、PGVector用于做 RAG。Debug 工具OpenAI 兼容接口的日志面板、LangSmith 或自研日志系统。如果你在本地跑开源模型可以用 vLLM 或 llama.cpp 启动一个 OpenAI 兼容服务。启动命令的精度参数要参考第 3 节的建议。9.2 最小项目结构llm-counter-defaults-demo/ ├── configs/ │ └── llm.yaml ├── core/ │ ├── llm_client.py │ ├── parser.py │ ├── tool_guard.py │ └── rag.py ├── pipelines/ │ ├── chat_pipeline.py │ └── rag_pipeline.py ├── tests/ │ └── test_tool_guard.py └── main.py这个结构把 LLM 客户端、解析校验、工具安全、RAG 逻辑分开便于测试和维护。9.3 配置管理配置不要散落在代码里建议统一管理。用 YAML 存模型参数、工具清单和权限策略# configs/llm.yaml model: provider: openai_compatible model_name: your-model-id dtype: bfloat16 inference: temperature: 0 top_p: 1 max_tokens: 1024 stop: - ### security: allowed_tools: - query_order - query_logistics require_approval_tools: - cancel_order max_tool_calls: 5 rag: retriever_top_k: 20 rerank_top_n: 3 score_threshold: 0.35这套配置的好处是修改参数不需要改代码也方便做多环境切换。团队里新增成员时先看配置就能理解应用的安全边界。10. 常见问题与排查方法下面整理 LLM 应用开发中经常遇到的问题按现象分类给出排查思路。问题现象可能原因排查方式解决方案模型输出不稳定同一句话每次不同temperature 或 top_p 偏高查看调用日志中的实际参数显式设置 temperature0固定 top_p输出被截断max_tokens 设置过小查看返回内容的 finish_reason 是否为 length调大 max_tokens或优化 Prompt 缩短输出JSON 解析失败模型输出带 Markdown 或解释文字打印原始响应启用 JSON Mode / response_format后端解析重试Agent 无限循环调用工具缺少最大调用次数限制看日志中工具调用序列加入 max_tool_calls设置合理的 Agent 终止条件显存不足模型以 fp32 加载查看 nvidia-smi 显存占用切换 bf16/fp16或使用量化版本RAG 检索结果不相关chunk 切分不合理或 top_k 过大检索测试查看召回片段结构化切分、加 rerank、设置 score 阈值模型拒绝执行已授权的工具工具名不在模型看到的列表中检查工具描述和 function calling 配置确保工具 schema 正确模型版本支持 function calling成本快速增长上下文无限累积查看每次请求的 token 数使用窗口记忆、做摘要压缩、限制输入长度每条问题背后都对应一个“默认值”。排查的第一步不是改代码而是打印完整请求和响应日志确认实际生效的默认值是什么。很多看似诡异的问题一旦把参数显式打印出来原因立刻清楚。11. 最佳实践与工程建议把 Counter-Defaults 落实到团队和项目需要一套规范化做法不只是改几个参数。11.1 建立默认值审计清单每次引入新框架、新模型或新 API团队都应按清单过一遍列出所有默认参数值。逐个判断是否适用当前业务。不适用就显式覆盖并写清楚原因。保留一份“当前生效参数”的文档或配置。审计清单可以用上面的 YAML 配置作为起点持续补充。11.2 测试中增加确定性用例LLM 应用也要写测试但测试重点不是“输出完全正确”而是固定输入下输出是否符合结构要求。温度设 0 时多次运行结果是否基本一致。解析器对异常输出的兜底是否正常。高危工具是否被正确拦截。pytest tests/test_tool_guard.py -v测试一旦跑通后续升级模型或改 Prompt 时能快速发现回归问题。11.3 日志与可观测性没有日志就没有一切排查能力。推荐至少记录请求 ID、用户 ID。模型名称、参数配置。Prompt 和完整响应。token 用量。工具调用记录和审批记录。运行耗时和错误信息。日志要避免记录个人敏感信息。如果需要记录完整 Prompt注意做脱敏处理。11.4 安全边界和最小权限这个原则在产品上线前必须明确模型能访问哪些工具。哪些工具需要人工审批。单次请求最多执行多少次工具调用。数据库操作是否只允许只读账号。是否有审计日志。不要因为模型“看起来智能”就给它更多权限。它只是一个基于概率的文本生成系统不具备真正的判断力和责任意识。11.5 版本管理与回滚Prompt、模型参数、向量库索引、工具 schema 都是需要版本管理的资产。建议把 prompt 和配置存到 Git 仓库改动走 PR 评审。线上出现问题时要能快速回滚到上一版配置。12. 总结与后续学习方向围绕 LLM Counter-Defaults这篇文章真正想讲清楚的是LLM 应用工程化的核心难点不是“让模型理解需求”而是控制那些影响确定性、成本和安全的不稳定变量。默认值不是标准答案只是一个起点。真正可靠的配置来自你对业务场景的分析、对框架行为的理解以及一套系统化的验证流程。下一步的实践路径建议如下第一找一个小型业务场景把本文提到的配置项逐个过一遍精度、推理参数、JSON 输出、Agent 工具权限、RAG chunk。先用最小示例跑通再逐步加复杂度。第二读一遍你正在用的框架源码或文档中关于默认配置的部分。不要求通读但至少要会搜索“默认值”“参数说明”“安全策略”相关的章节。第三建立一个简单的可观测性看板把每类请求的 token 用量、失败率、工具调用次数记录下来。这些数据会告诉你下一步优化方向。LLM 生态还在快速变化框架版本、模型能力、价格策略都会变。但无论工具怎么变“把不确定性显式化把权限边界显式化把可观测性做起来”这套思路不会过时。建议收藏这篇文章等你在实际项目中踩到对应问题时再回来对照排查。