技术工具

提示词工程有个隐性痛点：它一直被当作文档，而不是代码。改一句系统提示、换一个 few-shot 示例，往往是「我觉得更顺了」就上线，没人知道这次改动是不是把某个边缘问题改坏了。promptfoo 要补的就是这个洞——它把提示词连同一组测试用例，变成一个能在命令行重复跑、能接进 CI 的评测脚本。 它怎么工作 写一个配置文件，列三件事：要测哪些提示词变体、一组输入样例、以及判定标准（正则包含、JSON 字段校验、或让另一个模型打分）。然后跑一行命令：npx promptfoo eval，它把每个提示词在每个样例上都跑一遍，输出一张对照表。 再用 npx promptfoo view 打开本地界面，就能并排看：旧提示词和新提示词，在这 50 个用例上分别答成什么样。 接进 CI 的价值 把这一步挂进 GitHub Actions：每次有人改提示词文件，自动跑评测，失败率上升超过阈值就拦住合并。提示词从此有了「测试套」——改坏了能立刻发现，而不是靠用户反馈。 判定标准别贪多。一开始只测硬指标：输出能不能被你的下游 JSON schema 解析、关键事实有没有出现。软的「答得好不好」交给人工抽检，否则你会陷入给模型打分的模型打分。 判断 2026 年做 AI 应用，提示词已经是生产代码的一部分。既然是代码，就该享受代码的待遇：版本控制、评审、回归测试。promptfoo 这类工具把「凭感觉改提示词」变成「带着测试改提示词」，这是从玩具走向产品的必经一步。 补充一个实践点：测试用例要从真实失败里积累。每次用户反馈答得不好，就把那个问题和期望答案补进 promptfoo 的用例库。半年下来，你的测试套就是一份「我们踩过的坑清单」，提示词改动再也不会重蹈覆辙，新成员接手也能一眼看懂这条提示词经历过什么。 提示词是生产代码，就该享受版本控制和回归测试的待遇。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：提示词测试

团队里用 AI 的常见乱象：有人用 ChatGPT、有人用 Claude、有人在本地 ollama 里跑模型，聊天记录散落各处，合规审计无从谈起。解决办法不是再装一个工具，而是给团队一个统一的私有聊天入口。Open WebUI 就是干这个的：一个网页界面，背后可以同时挂本地 llama.cpp／ollama 模型和云端 API，成员登录后在同一个地方选模型、聊、共享会话。 部署就一条命令 它官方支持 docker 一键起：把本地跑着 ollama 的端口映射进来，docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway ghcr.io/open-webui/open-webui:main。浏览器打开 3000 端口，第一个注册的人是管理员。 接云端模型也简单：在后台的「外部连接」里填 OpenAI 兼容的 base_url 和 key，OpenRouter、LiteLLM、DeepSeek 都能接。这样团队成员在下拉框里就能选「本地 7B」或「云端 GPT-6」，不用各自配环境。 两个团队向的功能 用户与权限：可以加成员、设只读，敏感部门的会话留在自己服务器上； 模型分组：把「对外可用」和「仅研发调试」的模型分开，避免新人误调到贵的模型。 判断 当 AI 从「个人尝鲜」变成「团队生产力」，入口统一本身就是效率。本地模型处理敏感数据、云端模型处理复杂任务，用同一个界面切换，既省了重复订阅费，也让数据 finally 留在自己机器上。微软卖 2599 美元的 AI 笔记本讲的是单机算力，而 Open WebUI 解决的是「算力怎么变成团队入口」这另一半问题。 补一个部署细节：Open WebUI 自带用户体系，建议关闭「开放注册」，改成管理员邀请制。否则内网地址一旦被扫到，陌生人也能注册并用到你配好的云端模型——那就是真金白银的损失。另外，给敏感模型组单独设访问权限，把「内部调试用的本地大模型」和「全员可用的轻量模型」分开。 本地模型处理敏感数据、云端模型处理复杂任务，在同一个界面里切换，入口统一了，效率和合规才同时成立，成员也不用再各自养一套订阅，账单自然也省下来了。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：OpenWebUI

一个团队做 AI 应用，半年下来手里往往攥着七八把 API key：OpenAI 的、Anthropic 的、DeepSeek 的、智谱的、还有本地 llama.cpp 的。每接一家，代码里就多一套字段名、一套错误码、一套计费口径。LiteLLM 要解决的就是这个：它对外只暴露 OpenAI 兼容协议，对内把各家模型翻译成同一套调用格式。 它到底统一了什么 一套 SDK：代码里只写 client.chat.completions.create(...)，模型名写成 deepseek/deepseek-chat、gemini/gemini-2.5-pro 这样的前缀，剩下的转换由网关做； 一个 key 出口：应用只认网关地址，各家真实密钥存在服务端，前端拿不到； 统一记账：网关天然知道每次调用花了多少 token、哪家模型、哪个用户，可以直接出账单。 起一个网关 最省事的是用它的 proxy 模式：写一个 config.yaml 列出模型与对应环境变量里的密钥，然后 litellm --config config.yaml --port 4000。应用把 base_url 指向 http://localhost:4000，就像在调一个 OpenAI。 再往上走，可以开它的后台 UI，按团队、按 key 分组限额——市场部的 key 每天最多花 50 元，研发的 key 不限速但要记账。 为什么这件事值得做 Manus 2.0 把 Token 成本砍掉两成多，靠的是框架优化。但如果你连「谁在花、花在哪」都看不见，优化就是盲人摸象。一个统一网关是把账单从黑盒变成仪表盘的前提。等哪天你要在 GPT-6 和 DeepSeek 之间按价格动态切换模型，这个网关就是路由层——没有它，多模型容灾只是纸上谈兵。 补一个排障细节：网关层最容易出问题的是超时。长任务（Agent 跑十几步）很容易超过默认的短 HTTP 超时，导致前端报错但后端其实还在跑。把网关和客户端的超时都调到五分钟以上，并开启流式响应，长任务的体验才顺。另外，key 分组限额要配告警，别等账单来了才发现某个测试 key 被循环调用。 把网关立起来之后，你会发现「换模型」「看账单」「做限流」从改代码变成了改配置——这层抽象一旦到位，后面的多模型策略、价格路由才有地方生长，不至于散落在业务代码里。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：LiteLLM网关

单轮聊天出错，看一眼输出就知道问题。但 Agent 跑十几步、调了五六个工具、还把上下文越滚越长之后，用户一句「结果不对」甩过来，你根本无从下手——它当时到底检索了哪段文档、调了哪个工具、中间哪一步开始跑偏？这就是为什么 2026 年做 Agent，可观测性是必需品，不是锦上添花。Langfuse 是这一范畴里常用的开源选择。 它解决什么 Langfuse 的核心是 trace：一次 Agent 运行从开始到结束，被记成一棵树。每个节点记录输入、输出、耗时、token 数、错误。你可以在网页上回放：这一步模型看到的上下文是什么，那一步工具返回了什么。 三步接进来 自托管一行 docker 起 Langfuse，或用云版拿一对公钥私钥； 在你的 Agent 代码里装它的 SDK，用装饰器或上下文管理器包住模型调用与工具函数； 给每步打上 name 和元数据（任务 id、用户 id），跑几次，控制台就能看到轨迹树。 对用 OpenAI Agents SDK、LangChain、Dify 的项目，Langfuse 都有现成集成，基本是填两个环境变量的事。 怎么用起来 复现 bug：用户报障时，按任务 id 拉出那一次 trace，定位是检索错了还是工具返回错了； 找成本黑洞：按 token 排序，找出那几个每轮都把超长上下文重发的步骤，针对性做压缩； 回归对比：改完提示词，对比新旧 trace 的步数与失败率。 判断 Agent 从 demo 走向生产，最后一公里往往不是「它够不够聪明」，而是「它出错时你能不能修好」。给 Agent 装上 Langfuse 这个黑匣子，等于给飞行记录仪——飞得多高是模型的事，坠机了能黑匣子读数，才是工程团队的底气。 补充一个进阶用法：给 trace 打标签。按部门、按场景、按用户等级打标签，事后就能对比「市场部的 Agent 平均跑几步、花多少 token」和研发的差异。这种横向对比，往往能直接定位到那个一直没被注意的高成本流程——它跑得勤，却没人意识到它在烧钱。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Agent观测

AI 写代码越来越快，瓶颈反而卡在「谁来审」上。9 月底 OpenAI DevDay 之后，带云电脑的编码智能体已经能自己提 PR，但合并前那道人工评审，仍是团队质量的最后一道闸。把这道闸的初筛交给 AI，是性价比极高的一步——不需要买重型平台，一个 GitHub Actions 工作流就够。 工作流长什么样 核心是三步：触发 PR、拉取 diff、调模型评审、把结果写回评论。在仓库 .github/workflows/ai-review.yml 里： on: [pull_request]，限定 opened / synchronize； 用 actions/checkout@v4 拉代码，git diff origin/main...HEAD 拿到本次改动； 把 diff 作为 user message 发给任意兼容 OpenAI 协议的接口（DeepSeek、智谱、或自建网关都行），API key 存在仓库 Secrets 的 LLM_API_KEY； 用 actions/github-script 把模型返回贴成 PR 评论。 提示词只抓四件事：明显 bug、空指针或越界、安全性（注入、硬编码密钥）、以及「这次改动是否超过了它该做的范围」。 两个容易踩的坑 第一，别让它写风格意见。一旦允许模型评论「变量名不够语义化」，PR 评论区会被无效意见淹没，开发者很快把机器人静音。把输出限定为「必须修改」与「建议确认」两档。 第二，控制 diff 体积。一次改两千行的 PR 直接喂模型，既慢又贵还漏看。超过 800 行就只评审变更文件的关键函数，或拆成多轮。 落地建议 先在内部仓库灰度两周，让团队投票保留哪些意见类型。AI 评审不会替代人，但它把新人最容易犯的那类低级错误挡在人工评审之前，Reviewer 的注意力才能留给真正难的设计权衡。这才是它该待的位置。 补充一个实操细节：首次接入时，建议先把评审设为「仅建议、不拦截」，运行一周收集机器人给出的意见，让团队投票保留哪几类。那些真正挡住 bug 的意见留下，只会制造噪音的删掉。此外，对大改动 PR 可以只做增量评审——用 git diff 限定到本次变更的函数，避免模型把精力花在历史代码上，也省 token。 ...

为什么要做权重量化 FP16 精度的 70B 模型要 140GB 显存，个人设备根本跑不动。权重量化的思路是：把权重从 16bit 压到 4bit，理论上显存直接砍到四分之一，70B 就能挤进几十 GB 的卡。但粗暴地四舍五入到 4bit，模型质量会崩——权重里有大有小，重要的权重动一点，输出就偏。所以问题不是「能不能压到 4bit」，而是「怎么压到 4bit 还不怎么掉质量」。GPTQ 和 AWQ 是这个问题下最有代表性的两派。 GPTQ：逐列量化加二阶补偿 GPTQ（2022 年提出）属于训练后量化（PTQ）的代表。它的思路是：逐层、逐列地把权重压到低比特，但在量化每一列时，用已经量化好的后续列来补偿这一列带来的误差——具体用到 Hessian 矩阵（二阶导数）来估计误差如何传播，从而在量化时尽量把整体输出的偏移抵消掉。换句话说，它不是孤立地压每个权重，而是一边压一边把「压错的地方」在后面补回来。GPTQ 能在 4bit 下保持相当不错的质量，是早期 4bit 推理的主力。 AWQ：不压最显著的权重 AWQ（Activation-aware Weight Quantization，2023 年）走了另一条路。它观察到一个现象：不是所有权重都同等重要——显著权重（数值大的那批）对输出影响最大，把它们压垮了模型就废了。AWQ 通过激活值找出哪些通道里的权重是关键的，量化时对这些显著权重做保护（按一个缩放因子保留更高精度），只对不那么重要的部分狠压。实验显示，在同等 4bit 位宽下，AWQ 往往比 GPTQ 更稳、掉点更少，尤其在小位宽（3、4bit）区间。这也是为什么后来很多人在 4bit 部署时优先选 AWQ。 两派的实际差异 实践中的共识大致是：在 4bit 这个甜点档，两者质量都可接受，AWQ 略稳、对小硬件更友好；GPTQ 生态更早、工具链成熟。位宽再往下到 3bit 以下，两派质量都明显下滑，这时候靠 imatrix 校准的 GGUF（前面讲的 llama.cpp 那套）反而因为混合精度更有优势。选型上没有绝对答案，但记住一个原则：位宽别贪低。Q4 已经是质量与显存的平衡点，再往下省的那点显存，往往以模型变笨为代价，不划算。 收束 权重量化是把大模型塞进个人设备的关键工程。GPTQ 用误差补偿、AWQ 用保护显著权重，殊途同归地在 4bit 附近做到「能跑且不太笨」。对使用者，与其纠结两派谁更强，不如记住更实在的判断标准：4bit 起步，质量敏感上 5、6bit，用 imatrix 校准比无脑压更小的位宽更划算。量化是一门在显存与质量之间找平衡的算术，没有免费的极致压缩。 去论坛讨论 关于「GPTQ」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。 ...

注意力的平方级显存怪兽 回到注意力的计算复杂度：序列里每个 token 要和所有其他 token 算注意力分数，这是 N² 的关系。当序列长度 N 是 1K，还好；但长上下文到 128K，N² 就从百万涨到一百六十亿——中间生成的注意力矩阵大到把显存撑爆。更麻烦的是，传统实现会把整个注意力矩阵物化在显存里，算完才扔掉，显存占用居高不下。这也是为什么长上下文训练和推理都贵得离谱。FlashAttention（2022 年由 Tri Dao 等提出）就是奔着这个瓶颈来的。 FlashAttention 怎么省显存 FlashAttention 的核心不是改变数学结果，而是改变计算的访存顺序。它把注意力分块（tiling）：把长序列切成小块，在 GPU 的高速 SRAM 里逐块算、逐块累加，从不把完整的 N×N 矩阵写到慢的 HBM 显存里。因为数学上等价，输出结果和标准注意力一模一样，但显存占用从 O(N²) 降到约 O(N)，同时因为减少了显存往返，速度还快了两三倍。这是典型的「IO 感知」优化——它赢在少搬数据，而不是少算。后来的 FlashAttention-2、3 继续把并行度和硬件适配做到极致，如今几乎所有大模型推理都默认启用它。 KV Cache：推理时的隐形显存大户 训练靠 FlashAttention 省显存，推理则要对付另一个怪兽：KV Cache。自回归生成时，为了不重复计算历史 token 的 Key 和 Value，会把它们缓存下来。问题是这个缓存随上下文长度 × 并发数 × 层数 × 头维度线性膨胀。一个 70B 模型、8 路并发、32K 上下文，光 KV Cache 就能吃掉二三十 GB——这就是很多服务「单聊流畅、一开并发就 OOM」的根源。vLLM 的 PagedAttention 正是用分页管理 KV Cache 来压碎片，前面文章讲过。 长上下文的真实成本账 理解了这两层，就能算清长上下文的账：上下文从 4K 拉到 128K，KV Cache 涨 32 倍，注意力计算也随长度增长。所以「支持百万上下文」的模型，实际部署成本远不止权重那点钱——它要求你为 KV Cache 预备巨量显存，并发还上不去。这也是为什么业界在搞 KV 量化、MQA/GQA（多查询注意力，让多个查询头共享 KV，直接把 KV Cache 砍到几分之一）这类优化。GQA 已成为现代大模型的标配，本质就是为了在不显著掉质量的前提下，把 KV Cache 这个隐形大户压下来。 ...

痛点：模型一接业务就格式崩 把大模型接进业务流程，最常见的崩溃不是答得不对，而是格式不稳——你明明要求返回 JSON，它却在前面加一句「好的，以下是结果」，或者少一个右括号、多注释，下游一解析就报错。对人来说可读的回答，对程序就是垃圾。结构化输出（structured output）要解决的，就是让模型的输出100% 可被机器解析。这件事靠「在 prompt 里写请输出 JSON」远远不够，需要分层设防。 第一层：prompt 与 few-shot 最朴素的防线是把格式要求写清楚：给出字段定义、给一个完整示例、强调不要输出 JSON 以外的内容。few-shot 给一个输入输出样板，比纯文字描述管用得多。但这层本质是「求模型听话」，模型偶尔还是会自由发挥——心情好时格式漂亮，压力一大就崩。所以它是基础，但不能是唯一手段。 第二层：JSON mode 与 function calling 主流 API（OpenAI、Anthropic、各类本地服务）现在都提供 JSON mode：开启后强制模型只输出合法 JSON，不会再掺杂多余文字。更进一步的是 function calling / tool calling：你用 JSON Schema 定义好想要的字段结构，模型直接按 schema 填值，连字段名、类型、枚举值都被约束住。这一层已经从「提示」升级成「接口契约」，稳定性大幅提升。本地侧，llama.cpp 用 GBNF 语法约束、vLLM 用 guided decoding，都能做到按文法逐 token 限制输出，从解码层面杜绝非法格式。 第三层：解析兜底与重试 再稳的约束也要留兜底。工程上的标准做法是：拿到输出先尝试解析，失败就把「你刚才的输出不是合法 JSON，因为缺右括号」作为错误信息回传给模型，让它修正后重试一两遍。配合超时与最大重试次数，既不卡死流程，又能处理偶发的格式漂移。这一层是把「万一崩了」变成「崩了也能自愈」。 实战建议 如果你要把模型输出接数据库、接下游 API，别只靠 prompt。优先级是：能上 function calling / guided decoding 就上，它是最硬的约束；再用 few-shot 减少字段理解偏差；最后留解析加重试兜底。三层叠起来，JSON 输出的稳定性能从「经常炸」拉到「几乎不用管」。对本地模型，GBNF 这类语法约束尤其值得用——它把「求你输出 JSON」变成「你只能输出 JSON」，确定性完全不同。 收束 大模型从「聊天玩具」变成「业务组件」，格式稳定性是第一道坎。很多人花大力气调提示词让输出好看，却忘了更硬的手段是把格式约束下沉到解码层。理解「prompt 求、接口管、解析兜底」这三层，你接进业务的模型才不会在某个意想不到的时刻，吐出一段让下游崩溃的自由发挥。 去论坛讨论 关于「结构化输出」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。

两个工具，两种口味 本地跑大模型，新手最先撞上的两个工具是 Ollama 和 LM Studio。它们底层都吃 GGUF 量化模型，差别在交互哲学。Ollama 走极简命令行路线：ollama run qwen2.5 一条命令就下载并开始对话，自带 OpenAI 兼容 API（默认端口 11434），适合脚本、服务集成和服务器上跑。LM Studio 则是图形界面，自带模型浏览器，点几下就能搜、下载、加载、聊天，还能本地起一个 OpenAI 兼容服务器，适合不想碰命令行、想先可视化试模型的人。一句话：要省事集成选 Ollama，要直观摸索选 LM Studio。 选模型的三个实操点 第一，先看量化档位再下载。同一个 7B 模型，Q4_K_M 约 4GB、Q8_0 约 8GB，别下错成 FP16（14GB）把自己显存撑爆。LM Studio 会按你的显卡筛选能跑的模型，Ollama 则默认拉适中档位。第二，上下文长度要手动设。默认上下文 often 偏小，长文档场景要在参数里把 num_ctx 调到 8K、32K——但记住 KV Cache 随长度线性涨，调太大又会爆显存。第三，别用错后端：N 卡走 CUDA，A 卡走 ROCm，苹果芯片走 Metal，装错版本会慢到怀疑人生。LM Studio 安装时会让你选，Ollama 则自动检测。 API 调用与接 Agent 两个工具都暴露 OpenAI 兼容接口，这是它们的关键价值。意味着你可以把本地模型当成「本地版 GPT」，任何支持 OpenAI SDK 的框架改一下 base_url 就能接——LangChain、LangGraph、各类 Agent 框架无缝切换。调试时一个实用习惯：先用命令行或界面把模型跑顺、确认参数对，再切到 API 接业务，避免一上来就在集成层调不出来时分不清是模型问题还是代码问题。 常见坑 一是模型互相占显存：上一个模型没卸载，下一个加载就 OOM。Ollama 会自动卸载，但多开时仍要留意。二是tokenizer 与模板不匹配：手动换模型文件时，用错 chat 模板会让模型输出格式混乱，优先用工具自带的模型库而非自己乱拼文件。三是量化过度：图小选了 IQ2、IQ3 这类极低档位，质量肉眼可见地崩，省显存的代价是变笨，得不偿失。 ...

它为什么能加速又不掉质量 自回归解码有个天然瓶颈：生成第 N 个 token 必须等第 N-1 个算完，一步一步串行，GPU 大量算力在干等。投机解码（speculative decoding）绕过这个瓶颈：先让一个小而快的 draft 模型一口气猜后面 8 到 16 个 token，再让主模型用一次批量前向同时验证这一串猜测——猜对的直接采纳，猜错的从错处重算。关键在于验证用的是主模型同分布的采样规则（拒绝采样），所以输出和主模型逐字生成完全等价，质量不掉，速度却能提升。这是它比量化之类有损加速更迷人的地方：无损提速。 两条路线：独立 draft 与自带 MTP 2026 年的生态里，投机解码分两路。一路是经典 draft 模型：从同一个模型家族里挑一个更小的兄弟当 drafter，比如用 Qwen2.5-0.5B 配 Qwen2.5-7B，在 llama.cpp 里用 --spec-draft-model 指过去。另一路是自带的多 token 预测头（MTP）：像 DeepSeek V4 附带的 DSpark drafter、Qwen4Exp、Kimi K3，把草稿模块直接训进了权重，不用你另找小模型，开箱即用——而且同分布，接受率天然高。llama.cpp v0.6.0 已经把 Qwen4Exp 的 MTP 投机解码纳入稳定支持。 命令行怎么开 llama-server 里典型的开法是： llama-server --model target-Q4_K_M.gguf \ --spec-draft-model draft-Q4_K_M.gguf \ --spec-type draft-simple \ --spec-draft-n-max 8 \ --n-gpu-layers 99 --spec-draft-n-max 控制一次猜几个（默认约 16，太大反而拖慢）。跑起来后 stderr 会打印 accepted / rejected 的比例，这是你判断效果的唯一硬指标。 ...