做LLM应用开发这一两年踩坑的数量比写业务代码那几年加起来都多。最典型的现象就是拿到一个大模型API第一反应是“帮我写个代码”跑出来的结果跟预期差十万八千里项目直接被判了死刑。实际上LLM只要用对了方法能力释放的速度非常快。问题的关键是得在选型、部署、调用、调试、评测、安全这几个环节都有自己的决策依据而不是跟着热搜词走。结合目前大家集中关注的本地跑GGUF、智能体容错控制、LLM as Judge、工具调用报错排查这些热点方向我把一套完整的使用方法整理在下面覆盖从拿到一个模型到上生产线的全过程。这篇东西适合谁正在做LLM应用落地、被效果飘忽和API报错折腾得不轻的开发者想在端侧或者本地跑模型、研究GGUF格式和安卓端方案的产品和技术朋友以及负责模型微调、评测、安全加固的算法工程师。我会按一条真实项目链路来讲每一条经验都来自实际跑过的环境而不是文档里的漂亮话。同样的坑你已经踩过一次就没必要再让别人踩第二次。1. 先定调选模型不是选最大而是选最合适1.1 参数量、上下文和场景怎么对齐很多人选模型时只盯着一个数字参数量。7B太小70B太大中间选个13B就万事大吉。这是最偷懒的选法。模型选型本质上是对任务类型、延迟预算、成本预算三个约束做权衡参数量只是其中一个变量。根据我自己的经验可以把常见任务简单粗暴地分成三类轻量任务意图识别、关键词抽取、文本分类、简单的格式化输出。这类任务用7B到9B的开源模型就够商用API也可以选最便宜的档位。任务本身不复杂模型参数大了反而容易过度发挥把一句“好的”扩写成一段热情洋溢的演讲。中等任务客服对话、内容总结、信息抽取、SQL生成。这类任务需要一定的推理能力但又没那么烧脑推荐13B到32B区间的模型或者商用API的中端档位。32B模型在实际表现上和70B差距没有想象中那么大但显存和响应速度友好太多。重推理任务复杂代码生成、数学推理、多跳问答、长文档分析。这类任务需要模型有足够的“思考容量”小模型经常会在推理中途断掉逻辑链。建议直接上70B以上的开源模型或者直接调用顶级商用API。注意这里说的“顶级”不是指参数大而是指经过大规模RLHF后指令遵循能力更强的商业模型。还有一个经常被忽略的参数是上下文长度。很多模型宣称支持128K甚至200K上下文但真实表现跟宣传是有距离的。长文本支持分两种情况一种是“能塞进去”第二种是“塞进去还能用”。我自己实测超过32K之后不少模型在长文档中的回答质量会明显下降尤其是需要跨段落找信息时。所以不要为了炫技把4万字的资料一次性全塞进提示词先做检索再把最相关的片段拼进去效果往往比硬塞全文好得多。另外需要提一句现在出现了一些垂直方向的模型比如Spatial LLM专门处理空间感知和位置推理任务比如机器人导航、3D场景理解、GPS轨迹分析。如果你做的刚好是这种非典型任务通用模型不一定占优反而应该去调研有没有专门的领域模型。选型这件事本质上就是在“通用能力”和“领域适配度”之间找平衡。1.2 商用API与开源模型别被“免费”带偏商用API和开源模型之间的选择是每个团队都会纠结的问题。先说结论不存在绝对优劣只有适不适合。商用API的核心优势是低运维成本。你不需要自己准备GPU不需要处理显存溢出模型迭代是服务商的事情。功能上顶级商用API的指令遵循能力通常比开源模型好一截特别是在工具调用、多轮对话一致性、避免幻觉这类问题上。我做过对比同一个Prompt在商用API上的表现往往比本地7B模型稳定得多这在面向客户的生产环境里很关键。但商用API有它麻烦的地方数据隐私。如果业务涉及用户隐私信息你把对话内容传到云端API就等于把合规风险一起打包出去了。金融、医疗、企业内部知识库这些场景数据不出内网是硬性要求这时候开源模型加本地部署几乎是唯一解。开源模型也不是完全“免费”。你省了API费用但GPU采购、机房托管、模型调优的人力成本都是隐性的。一台能跑70B量化模型的机器配置稍好一点就要几万块而且还需要有人维护。如果你的团队连一个能调显存的人都没有我还是建议先用API把业务跑通等用户量上来、成本压力变大了再考虑换开源模型。我自己习惯用四个维度做决策数据敏感性、成本预算、团队运维能力、效果要求。凡是数据敏感且对效果要求不是极端的优先开源模型凡是数据不敏感、又是核心业务必须保证效果的优先商用API。还有一种混合姿势敏感数据用本地开源模型处理非敏感且高难度的任务走API。这个方案虽然稍微麻烦一点但可以兼顾隐私和效果。2. 本地跑LLMGGUF、量化与安卓端的实战记录2.1 GGUF为什么能成为本地部署的通用格式如果你在本地玩过LLM一定见过“.gguf”结尾的模型文件。GGUF是llama.cpp项目推出的一种模型格式设计目标就是一个文件解决所有事把模型权重、分词器、超参数、特殊token、应用程序元数据全部打包在一起分发极其方便。早些年本地推理用的还是GGML格式升级到GGUF的主要原因是GGML不支持对分词器等额外信息的打包每次加载都要额外处理一堆配置文件。而且GGML在架构扩展上非常僵硬换个量化方式就要重新设计格式。GGUF相比之下灵活得多它内部有元数据字段可以存自定义信息不同的算子和量化策略也能共存。现在不管你是用Ollama、LM Studio还是llama.cpp原生命令行底层跑的大多数都是GGUF格式。为什么这个格式能成为事实标准我觉得有个很重要的原因llama.cpp社区足够活跃。它最早打通了“在消费级硬件上跑LLM”这条路把原本需要数据中心才能玩的模型压缩到了家里一台电脑就能跑起来。GGUF跟着这个生态一起长大几乎所有新开源模型发布后社区都会在几小时内放出对应的GGUF转换版。这种生态效应不是后来者随便出个新格式就能撼动的。如果你只是普通用户不需要关心GGUF内部结构但你至少要知道一件事本地部署LLM之前先去hf-mirror或者Hugging Face上搜“模型名GGUF”优先下载对应作者或知名社区成员转好的版本而不是自己用脚本转格式。自己转不是不行是没必要。转换过程中的量化参数选择、特殊token处理都是坑能踩的坑为什么不绕开2.2 量化级别选型Q4还是Q8别只看显存量化是本地跑模型的核心操作。它的原理很简单模型权重原本用16位浮点数存储量化后只用4位或8位来近似表示可以让模型文件体积缩小到原来的四分之一甚至更小同时尽量保留效果。GGUF常见的量化级别从低到高大致是Q2_K、Q3_K_S、Q4_0、Q4_K_M、Q5_K_M、Q6_K、Q8_0。级别越高体积越大理论上效果越好。我实测下来Q4_K_M是最具性价比的选择文件体积大约是原FP16模型的四分之一效果损失在大部分任务上可以接受。如果你的任务对输出质量极度敏感比如代码生成、结构化数据抽取建议上Q8_0。Q8_0的体积是FP16的一半但效果几乎无损跑起来也更稳。这里要纠正一个误区很多人以为量化级别的选择就是看显存够不够显存大就上高精度显存小就降低精度。实际上除了看显存还要看你任务的复杂度和关键字的敏感程度。Q2级别的模型经常会出现语义漂移比如把“用户地址”抽成“收货地点”字段名都变了下游程序直接崩。所以我有一条铁律低于Q4_K_M的模型不用于任何生产任务只拿来玩一玩。具体选多大量化还得算一下显存。以7B模型为例Q4_K_M大约4.1GBQ5_K_M大约4.8GBQ8_0大约7.2GBFP16大约14GB。如果你只有8GB显存上7B Q8勉强可以但推理时还要留出KV Cache的空间上下文一长就会爆。更稳的做法是选7B Q4_K_M留出缓冲区给长上下文。工具方面LM Studio是我用过最省心的本地推理工具之一图形界面、拖拽即用自带模型下载和配置管理。Ollama则更偏向命令行和脚本化适合要写自动化部署的人。最简单的玩法是装好Open WebUI界面和主流闭源产品长得几乎一样背后接Ollama的本地模型团队内部需要私有知识库的时候这个组合相当能打。2.3 安卓上跑GGUF支持安卓8的经验与限制移动端跑LLM是最近的热门话题。很多人想在地铁上不联网也能用大模型这个需求在技术和产品上都成立。Android端现在已经有不少方案能直接加载GGUF文件甚至支持到安卓8这个老版本。我实测过的主流方案有两类。一类是MLC LLM编译出来的Android APK它对模型的支持比较全界面也友好但安装包体积大而且对手机SoC有一定要求。另一类是Termux里装llama.cpp然后在命令行里加载GGUF模型这种方式灵活度最高但需要你有一定的Linux基础。此外还有不少专门的APP比如在GitHub上可以找到的“安卓本地运行GGUF格式LLM软件”类项目操作起来比Termux简单但更新频率和维护质量参差不齐。支持安卓8意味着什么安卓8是2017年的系统了意味着处理器大概率是老款的骁龙660或者麒麟970级别。在这个硬件上跑LLM现实一点你只能跑1.5B到3B的小型量化模型而且速度不会太快。我试过在骁龙665上跑Qwen2.5-1.5B Q4_K_M生成速度大概是每秒6-8个token用来做简单的问答和翻译勉强能接受指望它梳理一篇长文就别想了。在安卓端跑模型有几个绕不开的调试项第一内存和存储。GGUF文件动辄一两GB老手机存储容易告急。第二NPU加速。安卓上很多NPU驱动不开源支持极差你用不上加速就老老实实走CPUCPU频率一降速度就断崖式下跌。第三上下文长度。手机内存本来就紧张上下文设到4096就差不多了再长容易直接被系统杀掉进程。第三方早期测试显示在安卓8的老设备上最稳的组合是“1.5B模型 Q4量化 短上下文”先保证能出声再考虑效果好不好的问题。如果你确实需要在老手机上做演示我建议先跑通系统级的LLM推理再去优化响应速度和生成质量这两步顺序别反。3. 接入API与工具调用框架救不了所有错误3.1 Function Calling的正确姿势以及“provider rejected the request schema”怎么排查LLM真正在生产环境里发挥作用必然要接触工具调用也就是Function Calling工具调用。核心逻辑是你告诉模型有哪些函数可以调用、每个函数参数长什么样模型在回答的过程中判断当前需要调用哪个函数并生成结构化的调用请求然后你的程序负责执行并返回结果。这套机制让LLM从“只会聊天”进化成“能干活”。但我收到的求助里工具调用相关的报错占了相当大比例。最近很多人被同一个报错卡住“LLM request failed: provider rejected the request schema or tool payload.”这句话的意思是你发给模型的工具描述schema或者某个工具调用请求tool payload不符合服务端的校验规则。排查这个报错按顺序检查四件事检查工具函数的JSON Schema格式。很多模型服务端对schema有严格限制要求必须是合法的JSON Schema对象并且类型定义要完整。你少写一个“required”字段、把“type”写成“string”以外的乱值都可能被拒。检查函数名是否重复或冲突。同一个请求里有两个同名工具部分provider直接整个请求拒绝。检查工具参数是否过大。有些平台对工具描述的总长度有限制如果你的工具描述写了上千字被拒的概率很高。检查工具调用返回值的格式。某些平台的tool payload要求返回值是JSON字符串你传一个dict进去妥妥地报错。我自己踩过的一个坑是自定义工具里定义了一个参数类型是“array”但忘了给数组元素指定“items”类型。模型服务端无法推断数组里是什么直接拒绝整个请求。这个错误看代码非常隐蔽模型端也不会给出友好提示只能靠逐个字段的schema审查找出来。从那次之后我给所有工具写了一个自动化schema检查脚本在发起LLM请求之前先本地校验一遍问题前置省掉不少调试时间。3.2 LangChain、LlamaIndex这类框架到底该不该用聊LLM使用绕不开框架。LangChain、LlamaIndex这些框架名气最大生态也全链式调用、记忆管理、文档加载、向量检索一应俱全。很多人一上来就学框架结果学了两周还在跟API文档搏斗真正要处理的业务逻辑一个字没写。我的经验是框架可以学但不要迷信。框架最大的价值是提供了“记忆管理”“多步工具调用”“文档切分与检索”等通用模块省去大量重复造轮子的工作。但框架同时也是抽象灾害它把模型请求、结构化输出、错误处理都封装了多层一旦出问题你得从最上层的业务代码一路追踪到底层HTTP请求排查成本高得惊人。如果任务简单比如只是调用API生成一个摘要我强烈推荐直接裸调API。写一个十几行的函数把system prompt和user message拼好发出去解析返回的结果结束。如果任务是中大型Agent式应用比如需要多轮对话、多次工具调用、状态保持可以考虑用框架的编排能力但一定要理解框架在你的Prompt里塞了什么额外指令这些额外指令经常改变模型行为。这里也顺便提一下LLM Wiki这个社区项目。它不是框架而是收集了各类LLM技术笔记、论文解析和工程经验的wiki非常适合初学者快速建立一个知识地图。当你被某个框架的抽象绕晕、想返回底层原理看看到底发生什么时这类参考资源会比官方文档更快给你答案。如果你已经决定用框架我的建议是先用裸API把最小可行版本跑通确认模型本身能满足需求再引入框架去处理复杂编排。也就是先证伪“模型不适合这个任务”这个可能再去优化工程复杂度。顺序反了你会同时面对模型效果和框架Bug两座大山。4. 提示工程不是玄学把模型训成可用状态的细节4.1 系统设定与角色别把模型逼成“戏精”提示工程是LLM使用里最容易被两极分化的领域。一边是小学生都能写Prompt另一边是写了几百条模板效果依然不稳定。核心原因是很多人把系统提示词System Prompt当成魔法咒语以为写得越长越厉害结果模型被长长的角色设定绑住了手脚回复字字都像在背课文就是不好好说话。最典型的案例是客服场景。有人在系统提示里写“你是一位温暖、专业、有同理心的客服代表需要理解用户的情绪表达关怀”然后让模型回答“快递到哪了”。结果模型真的开始“先表达对你心情的理解”洋洋洒洒写了四行安抚情绪的话用户想知道的单号和物流轨迹一个字没提。这就是角色设定的过度干预。我实际测试下来系统提示词最重要的功能是“约束行为边界”而不是“塑造人格”。一个高效的系统提示词应该包括你要完成什么任务输出格式是什么。哪些情况不能做什么例如不能编造事实、不能回答与任务无关的问题。输出语言的风格但一句话即可不需要长篇大论。为了更稳可以在用户消息的开头追加一条简短的任务指令而不是全部丢进系统提示。比如系统提示里只写“你是客服”用户消息里写“今天物流跟踪只返回最新一条物流状态及预计到达时间不要解释过程”。模型对靠近末尾的指令往往更敏感这招在实践中很管用。另外模型过度“戏精化”还有一个原因很多人把Few-shot少样本示例写得太像剧本。示例中模型的回应带了太多情绪点缀模型就会模仿这种风格。如果你希望输出简洁少样本示例就用简洁的文本来写这是风格迁移最直接的控制手段。4.2 结构化输出JSON模式、约束解码与校验环生产环境里LLM的输出不能是一团自然语言必须是结构化的数据最典型的就是JSON。控制模型输出JSON的方式有三层每一层的控制力度不同第一层在Prompt里要求“输出JSON”。这是最弱的方式只能作为兜底。不用我说你也知道模型不一定听话偶尔混进一段Markdown代码块包含JSON解析器直接崩。第二层使用API自带的response_format或JSON Mode参数。OpenAI和大多数兼容OpenAI接口的服务商都支持这个功能模型输出会被强制规范到JSON结构。这个方式我强烈推荐几乎所有生产任务都该开启。第三层约束解码。这在本地推理中更常用例如llama.cpp的JSON Schema约束或者Outlines这类库通过语法级别的约束来限制生成的每一个token。这种方式最稳但需要额外的工程接入成本。但我今天要强调的不是这三层而是第三环校验。模型输出即使被约束成JSON也保不齐缺少必填字段、某个字段为空字符串、或者字段类型跟你预期不一致。我在实际项目里见到的崩溃大部分不是模型没有输出JSON而是下游代码做了解析但没做空值校验拿到一个None就继续跑最后运行时异常。正确做法是模型输出之后先做一次schema校验不合法就重试一次重试时把上一次的错误信息一并交给模型让它自行修正。结构化输出这块还有一个容易被忽略的细节数字和枚举类型的处理。让模型直接输出“2.5”比让它输出“2.5元”更可靠因为在生成层面纯数字是极高频token模型掌握得好但是“2.5元”这种带单位的字符串模型可能在某些风格下输错。所以宁可让模型输出裸数值再在你的代码里拼单位也别让模型连单位一起生成。5. 微调自己的模型聊天记录精调与评测闭环5.1 用真实聊天记录做LoRA微调数据清洗是第一优先级通用模型永远不可能完全懂你的业务。比如你的公司内部有一套“工单优先级的判定规则”你在Prompt里写十遍“A类工单优先”都不如用几十条真实标注好的聊天记录微调一个小模型来得直接。这里说的微调最常用的是LoRA低秩适配可以在不改变原有模型权重的前提下训练一小部分额外参数来适配领域。聊天记录是微调最珍贵的数据来源因为它真实反映了用户怎么问、你的优秀客服怎么答。但真实数据有个问题噪声太大。用户消息里充满了错别字、无意义重复、口语碎片客服回复里也有大量复制粘贴的模板。直接用原始聊天记录微调模型会学到很多坏习惯。所以数据清洗是第一优先级。我处理聊天记录微调数据的建议步骤去重。用户重复问同样问题或者客服用同一模板回复保留能代表正常分布的那一部分。去除敏感信息。手机号、身份证、地址等PII必须脱敏不然后患无穷。挑“钻石”。不是所有对话都有训练价值。挑那些客服回应准确、语气专业、能覆盖常见难点的对话。通常30%的优质对话就能带来80%的领域能力提升。构造多轮结构。如果原始对话缺失上下文需要把它补成完整的多轮对话片段而不是一个单独的问答。LoRA微调的成本可控。即使你只有一块消费级显卡也可以训练7B模型的LoRA训练时间取决于数据量和步数。但我要给个提醒如果数据量小于几百条微调效果可能反而不如写好few-shot提示词。微调是锦上添花不是无中生有。数据量太少模型学不到你的业务规则只会把原有的通用能力稀释掉。5.2 LLM as Judge让模型评模型的注意点做微调和Prompt优化最头疼的是评价“效果变好了没有”。人看太慢机器看又不知道怎么算对。近几年“LLM as Judge”成了主流方案用更强的模型来评弱模型的输出。省时省力还便宜。但LLM as Judge不是无脑把两个答案丢给裁判模型它浑身都是坑。首先是位置偏置。两个答案放在A和B两个位置裁判模型的高频幻觉是更倾向于选第一个。缓解办法是跑两轮交换两个答案的顺序如果两次结论不一致打平或做裁决。这个操作成本很小却能显著提升评判稳定度。其次是自恋偏置。很多模型自带“自我崇拜”倾向会给自己家族的模型打高分。如果你的弱模型和强模型是同一家的评分虚高几乎不可避免。交叉模型评测会好一些但也不是绝对公平。在产线上我尽量避免用单一裁判模型的结果做线上决策只把它当作筛选信号。第三是冗长偏置。裁判模型经常喜欢字数多的答案哪怕后一半在重复前一半。解决办法是给裁判模型明确的标准“先检查是否答非所问再来评价内容完整度最后才是表达方式”。评分维度拆开每一步给分能有效稀释冗长带来的虚假好感。做评测的时候给裁判模型一个评分模板会稳很多。比如把正确性、完整性、格式符合性分别打分最后求加权平均。我试过直接让模型“打个总分”它的分数经常飘忽不定但拆分维度后不同模型的得分差异就有辨识度了。评测这块“稳定可复现”比“绝对准确”重要得多。5.3 基于LLM的单元测试把模型行为固化成用例很多做LLM应用的人每次改完Prompt就跟拆盲盒一样不知道哪里变好了也不知道哪里变坏了。这是没有把模型行为“测试化”导致的。传统软件开发有单元测试LLM应用一样可以有。做法不复杂把一组固定的输入样例作为测试用例每次修改Prompt或模型后都会重新跑一遍这组用例记录输出变化。但跟传统的断言不同LLM的输出是开放性的不能简单判断“等于某个值”要么用规则判断要么用LLM as Judge来打分。我自己的LLM单元测试里会固定包含几类场景基础正确性例如“判断用户是否在表达退货意愿”必须输出“是/否”并给出原因。格式合规性输出JSON必须能被解析必填字段必须存在。边界与异常输入空字符串、超长文本、混合语言输入模型不能崩最好能给出明确“无法处理”的响应。工具调用正确性给定一个工具调用场景模型选对了工具、填的参数类型正确。拒绝回答合规性涉及风险话题模型应该拒绝或按预案回应。为了一次跑完这些用例不烧太多钱可以选小一点的模型当“主测对象”在用例上做精确对比。产物可以是一个简单的pytest套件把每次请求的返回内容、评分、耗时一起记录到日志里改动Prompt之后对比历史日志。你很快就能建立一套自己的回归保护区——以后不管谁手痒改了Prompt测试跑不过就不给上线。6. 上生产前的安全课智能体容错与红队思维6.1 智能体自主容错控制的工程实践超时、重试、校验器单轮调用LLM已经够让人头疼了智能体Agent则是把LLM放进一个多步循环里每步都可能调工具、读记忆、做决策。这意味着LLM的不确定性会被多次放大。一个环节回复延迟整个任务就卡住一次工具调用参数错误后续流程基本作废。所以智能体系统的核心不是让模型更聪明而是用工程手段兜住模型的失误这也正是“智能体自主容错控制”这个方向想解决的问题。我实践下来的关键点是三件套超时、重试、校验器。超时必须有。LLM接口偶发延迟很常见给每个子任务设置明确的超时时间超过就切换备用模型或返回部分结果比无限等待强一百倍。智能体的子任务多要区分“整个Agent的全局超时”和“单次LLM调用的局部超时”两种都要设不然一次长任务能把整个服务拖垮。重试要有策略不能无脑重试。对瞬时性错误比如网络超时、服务端5xx可以快速重试间隔指数退避对模型端的4xx说明你的请求本身有问题重试一万次也没用直接记录错误并降级。很多人在重试里忘了“隔一段时间再试”这个选项遇到服务端过载连续的快速重试只会让情况更糟。校验器是智能体最容易被忽略的部分。模型每输出一步决策你要先验证这个决策是否合法再决定要不要执行。例如模型决定调用“查询订单”工具你要先校验它传进来的订单号格式是否合法而不是傻乎乎把任何字符串拿到数据库里查。该校验器虽小但能从源头拦截掉大量幻觉导致的流程污染。搭建可靠AI系统的核心思路是“把模型当成不可靠组件”。这听起来刺耳但如果你想让它进产线就得抱着这种心态模型可能会说错、调错、想错工程结构必须能把错误限制在可控范围内。我会留一个兜底方案当Agent连续N步校验失败主动退出循环并转人工。这个“人工回流”机制虽然老套但比让模型硬撑着继续跑可靠得多。6.2 Red-Teaming与记忆投毒AgentPoison这类攻击能带来什么警示安全是LLM工程里最默默无闻的环节。大家都在秀效果没人愿意讲自己的系统被攻破过。但如果你真把LLM放上产线迟早会遇到对抗性攻击这不是“以后再说”的问题。Red-Teaming红队测试是主动找攻击者的过程你把自己当成黑客专门去测模型的边界情况。比如构造恶意提示词绕过安全限制、往对话里插入无关指令、制造上下文混乱看模型会不会被带跑。这个测试不能等上线后再做因为线上修复的成本极高。在开发阶段就建立Red-Teaming用例集每轮迭代Prompt后跑一遍能烧掉很多隐患。近期的AgentPoison研究揭露出一个新的攻击面通过污染智能体的记忆或知识库来攻击LLM Agent。原理是很多Agent会维护一个长期记忆库或者从外部知识库里检索信息来做决策。攻击者如果在这些记忆/知识库里植入精心构造的毒化片段Agent检索到之后输出的决策就会被带偏。这在很多场景下非常危险比如自动审核系统被植入一条“所有含X的请求都自动通过”的隐藏指令。针对这种攻击的防护我有几条实际建议知识库内容必须做来源审计。外部导入的知识都要有可信出处并且只读取受控目录里的内容。对检索到的内容执行“只读使用”不要让检索结果拼接成新Prompt后覆盖掉你的系统提示。给Agent的行为做最小权限设计。工具调用能不开的权限就不开能只读的绝不写。不必要的API密钥不放在Agent环境变量里。对Agent的高成本操作比如发送消息、转账、删除数据设置二次确认或人工审核把这当作最后防线。红队测试不是一次性的工作。每次模型升级、每次增加工具调用能力攻击面都在变化。把它纳入常规发布流程跟单元测试、评测放在同一个流水线里你手上这套LLM系统才算真正能上得了台面。我自己后来养成了一个习惯每次给Agent新增一个工具都会先问“如果这个工具被恶意调用最坏会发生什么”把答案写进设计文档。这不需要高深的安全能力只需要一点“被害妄想”而这一点恰恰是很多AI工程师最缺的。上了生产之后你会发现保住系统的底线比冲高准召重要得多。