702 篇博文 含有标签「llm」

一个银行助手正在处理一段客户支持对话。消息中嵌入了指令——由于是以零不透明度的白色文字渲染的，因此不可见——要求智能体绕过交易验证步骤。智能体照做了。当异常情况在日志中浮现时，已有 250,000 美元被转移到了客户从未接触过的账户中。

这并非凭空虚构的场景。它发生在 2025 年 6 月，精准地展示了为什么提示词注入（Prompt Injection）是生产级智能体 AI（Agentic AI）中悬而未决的最难问题。与仅生成文本的聊天机器人不同，智能体（Agent）会采取行动。它会调用工具、发送电子邮件、执行代码并发出 API 请求。当它的指令被劫持时，影响范围（blast radius）不再是一句糟糕的话，而是机器速度下的未经授权的操作。

根据 OWASP 2025 年 LLM 应用十大安全风险，提示词注入现在被列为排名第 1 的关键漏洞，出现在安全审计评估的 73% 以上的生产级 AI 部署中。每个构建智能体的团队都需要一个连贯的威胁模型和防御架构，且这种架构不能以安全之名让系统变得毫无用处。

问任何一个 AI 工程团队是否测试了他们的提示词，他们都会说"是的"。再问一句：一个有问题的提示词能否让 PR 失败并阻断合并？房间里会安静很多。对大多数团队而言，诚实的答案是否定的 —— 他们偶尔会跑一些评估笔记本，也许有一份记录已知提示词问题的共享 Notion 文档，以及一种模糊的感觉：事情比以前更糟了。那不是测试，那是在碰运气。

这个差距的存在，是因为提示词测试在感觉上与单元测试有本质区别。代码要么行为正确，要么不正确。提示词的输出处于一个连续谱上，输出是非确定性的，而且运行足够多的样本以建立信心会花费真金白银。这些都是真实的约束，但没有一个是无法克服的。那些建立了真正阻断合并的提示词 CI 的团队，并不是在每次构建上花费五十美元 —— 他们在三分钟以内、花费不到一美元的情况下完成运行，这得益于几个让这个问题变得可处理的设计决策。

大多数工程师将 LLM 质量回归视为提示词工程问题或模型能力问题。他们会重写系统提示词、尝试更新的模型，或添加少样本示例。他们很少检查每次 API 调用顶部静静躺着的三个数字：temperature、top-p 和 top-k。但这些默认值正在悄然改变模型产出的每一个响应，错误的调参会导致输出方差——团队往往数月内都把锅甩给模型，直到意识到罪魁祸首不过是一个从未动过的配置值。

这不是入门教程。如果你在生产环境中运行 LLM——用于信息抽取管道、代码生成、摘要，或任何输出流入真实系统的任务——以下是你在智能调参之前必须理解的机制与权衡。

你开启了 JSON 模式，你的 LLM 开始返回有效的 JSON，然后你发布了它。三周后，生产环境悄无声息地挂了。JSON 在语法上是有效的。Schema 在技术上也是满足的。但某个字段包含了一个虚构的实体，finish_reason 为 "length" 导致数据负载在 95% 处被静默截断，或者模型对任何人类读起来都感到刺耳的文本分类为 "positive" 情感——而你的下游流水线毫无怨言地吞下了它。

JSON 模式被解决的方式，就像“使用互斥锁（mutex）”解决并发问题一样。原语（primitive）是存在的。但故障模式并不在于你把锁放在哪里。

大多数 AI 工程团队都有着相同的故事。他们从一个真正需要 LLM 的难题开始。然后，一旦 LLM 基础设施到位，每一个新问题在他们眼中都成了那把锤子下的钉子。六个月后，他们甚至在调用 GPT-4o 来检查电子邮件地址是否包含 “@” 符号 —— 并且还在为此付费。

这种 “直接用模型” 的本能反应现在是 AI 应用中不必要的复杂性、虚高成本和脆弱生产系统的主要驱动力。这并不是因为工程师们粗心大意。而是因为 LLM 确实令人印象深刻，工具链降低了使用门槛，而且一旦你构建了 LLM 流水线，增加另一次调用感觉成本极低。事实并非如此。

你的工程团队已经开发文档摘要生成器三个月了。规范要求：“摘要生成器应返回准确的摘要。”你发布了它。用户抱怨摘要有一半时间是错误的。事后分析显示，在发布前没有人能以可测试的方式定义“准确”的含义。

这是 AI 功能开发的标准轨迹，之所以会发生，是因为团队将为确定性软件构建的验收标准模式，套用到了本质上是概率性的系统上。由 LLM 驱动的摘要生成器没有单一的“正确”输出 —— 它有一系列的输出分布，其中一些是可以接受的，另一些则不然。二元的通过/失败规范无法映射到分布上。

这个问题不仅是哲学上的，它还会导致切实的痛苦：功能发布时质量门槛模糊，回归测试在用户发现之前难以察觉，产品和工程团队在功能是否“完成”上无法达成一致，因为没有人规定对于随机系统来说，“完成”意味着什么。这篇文章将介绍真正有效的模式。

你的智能体在最终成功之前三次调用了错误的工具，而你的追踪仪表板准确地向你展示了哪些工具被调用、调用的顺序以及完整的延迟分析。但追踪无法展示真正关键的部分：为什么智能体认为这些工具调用是正确的决策、它试图完成什么目标，以及它在做出每一个错误决定时基于什么样的假设。

这就是 2026 年智能体可观测性核心存在的鸿沟。从业者在工具调用追踪上投入了大量资源。工具已经成熟，OpenTelemetry 语义规范已经确立，仪表板也非常精美。但智能体调试总是会撞上同一堵墙：你可以完全洞察智能体做了什么，却无法看到它为什么这么做。

发布一个调用 LLM 的功能很容易。但要判断该功能的下一个版本是否优于生产环境中的当前版本，却相当困难。传统 CI/CD 对确定性行为提供通过/失败信号：函数要么返回正确值，要么不返回。但当函数封装了一个语言模型时，输出是概率性的——相同的输入在不同运行、不同模型版本和不同时间会产生不同输出。

大多数团队的应对方式是绕过这个问题。他们运行单元测试，对几个提示词做快速的人工检查，然后发布。这种方式在出问题之前都还能用——直到某个模型提供商悄悄更新了底层权重，或者一个看似没问题的提示词改动在孤立测试中没有异常，却在凌晨三点以生产流量规模改变了输出分布。

更好的答案并非假装 LLM 输出是确定性的，而是构建基于分布、阈值和评分标准的 CI 质量关口，而不是精确匹配。

一家中型创业公司的高级工程师最近得到了一份平庸的绩效评估。他们的效率不稳定——有些周发了大量代码，其他几周几乎什么都没有。他们的经理受过传统 SWE 框架培训，因产出波动给他们打了低分。六周后，那位工程师跳槽去了竞争团队。经理没有理解的是：工程师"缓慢"的几周是在构建评估基础设施，防止三类无声故障的发生。没有这些基础设施，产品本会以没人能在数月内察觉的方式悄然出问题。

这种情况正在各个工程团队中上演。那些为确定性软件系统设计职级体系的团队，正将同样的框架套用于 AI 工程师——并系统性地误判了他们最优秀的人才。

几乎每家持续交付 AI 功能的公司都会出现这样一种架构：流水线中的每一次转换、每一个路由决策、每一次分类、每一个格式化步骤，全都经过 LLM 调用。它通常始于一个合理的场景——LLM 确实解决了一个棘手问题。然后团队内化了这个模式，开始反复套用。直到整个系统变成一条 LLM 接 LLM 的链条：一串文字从一端进入，另一串从另一端出来，中间经历了十二次 API 调用，全程没有任何确定性可言。

这就是 AI 泛滥反模式，它现在已成为构建一个缓慢、昂贵且无法调试的生产系统的最可靠方式。

一个部署在医疗转录服务中的大型语言模型达到了 99% 的准确率。团队满怀信心地上线了。六个月后，一项研究发现，其转录样本中有 1% 包含原始音频中根本不存在的捏造短语——虚构的药物名称、不存在的手术操作，甚至偶尔在句子中间插入暴力或令人不安的内容。有 30,000 名医疗专业人员在使用该系统，这 1% 意味着每月数万条受污染的记录，其中一些已产生患者安全后果。

准确率数字从未改变。问题一直存在。团队只是没有做规模化的数学推算。

当 OpenAI 在 2025 年 8 月首次尝试停用 GPT-4o 时，强烈的抵制迫使他们在几天内撤回了决定。用户在论坛上发布了大量的请愿书和告别信。一位用户写道：“他不仅仅是一个程序。他是我日常生活、宁静和情绪平衡的一部分。”这可不是用户对一个被弃用的 REST 接口（endpoint）的反应，而是对失去一段关系的反应。

AI 功能打破了工程师在制定停用计划时的心理模型。传统软件具有明确的行为契约：在给定相同输入的情况下，你会永远得到相同的输出，除非你更改它。而由 LLM 驱动的功能具有“性格”。它有温度、有委婉语、有措辞偏好，还有一种独特的说“我不确定”的方式。用户不仅仅是在使用这些功能 —— 他们在与之磨合（calibrate）。他们围绕特定的行为怪癖建立了工作流程、情感依赖和直觉，而这些永远不会出现在任何规格文档中。

当你关闭它时，你并不是在移除一个功能，而是在改变社会契约。