
AI Agent
聊天模型给出建议,Agent 则要把建议变成一连串可检查的动作。它需要读文件、访问网页或 API,再根据返回结果决定下一步。真正的门槛通常出现在失败恢复、权限边界和任务状态保存,而不是第一次工具调用成功时。 让助手整理一份开源项目的更新记录:先找到发布页,再读取变更说明,最后生成带来源的摘要。聊天模型可以在几秒内写出一个像样的模板,Agent 却必须确认项目名、访问网页、处理分页、辨别预发布版本,输出时还要把每条结论指向原始记录。只要其中一步拿到了过期缓存,最后的文字就可能流畅却错误。 一个工具返回 200 状态码,不等于任务成功。搜索结果可能是镜像站,文件读取可能只有前半段,浏览器可能停留在登录页。可靠的流程会给每一步定义可观察的结果:目标页面的标题是否匹配、日期是否在范围内、引用链接能否打开。模型做出判断,外层程序记录动作与结果,这两部分缺一不可。
阅读全文 ↗
推理模型
推理模型把更多计算放在回答之前,对多步骤问题确实可能有帮助;但延迟、成本与任务难度并不线性。搜索一句文档和修复复杂代码不该使用同一档推理预算。评测时应同时记录正确率、首字延迟和失败后的重试成本。 同一道题,让模型多花十秒有时会得到更周密的答案;让它给一个按钮改文案,多等十秒则只是拖慢工作。推理预算是资源配置问题。它应当由任务难度、错误代价和响应时限共同决定,而不是在所有请求上统一拉满。 对可核查的数学题、复杂代码修复和多约束规划,可以给模型更多推理时间,并用测试或外部规则验证结果。对分类、格式转换、简单检索,先用较快模型或较低预算处理;只有置信度不足或校验失败时才升级。这个分层并不保证每次都便宜,但能避免把大量简单请求送进最重的链路。
阅读全文 ↗
本地部署
本地运行不等于一台普通电脑能无代价替代云端模型。内存、显存、量化精度、上下文长度和输出速度共同决定体验。小模型适合离线草稿与私有资料辅助,复杂推理和高并发任务仍要按实际硬件与成本评估。 “能跑”有三个层次:权重加载成功、可接受的速度、任务结果可用。16GB 内存的轻薄本与 24GB 显存的工作站,能够容纳的模型、上下文和吞吐差别很大。模型权重之外,还要为运行时、KV 缓存、操作系统和其他应用留空间。把所有可用内存算给权重,往往得到的是频繁换页而非可用体验。 4bit、5bit 等量化会缩小权重,占用更低,但不同量化方案与模型结构对质量的影响并不相同。低比特量化可能在日常摘要里几乎察觉不到,在代码生成、数学或多轮工具调用里却暴露差异。下载模型前看清格式是否被当前推理引擎支持,也要确认许可证和模型卡。
阅读全文 ↗