AI开发与编程：用AI构建应用的实战指南

当你构建完一个 AI 智能体后，总会撞上同一堵墙："好了，但它真的能用吗？"用来凭数据而非凭感觉判断提示词或模型改动是变好还是变差的机制，就是 Evals。LLM 对同一个输入每次都可能产出不同的结果，所以精确匹配的单元测试并不契合。本文讲清 Evals 是什么、衡量质量的五种方法（① 标准答案匹配 ② 基于规则的检查 ③ LLM-as-judge ④ 回归测试 ⑤ 生产环境监控）、面向智能体的专属评估（任务成功率、工具调用是否正确、执行轨迹、成本）、如何从 20 个失败样例开始从小做起、常见陷阱，以及主要工具（Anthropic Console/Evals、OpenAI Evals、LangSmith、Langfuse、Ragas）——写给实践者。

关于自动化的老问题：「用 AI 智能体还是 RPA？」答案不是二选一——按角色分工，而 2026 年的制胜模式是两者的混合。RPA 是确定性的「手」，快速精准地执行既定流程（但屏幕／规格一变就失灵）；AI 智能体是概率性的「脑」，解读情境并做判断（擅长应对模糊与例外，但并非每次都一样）。本文讲解工作原理的差异、对比表（可复现性与适应力的取舍）、如何选择（标准是「能否用规则完整写出来？」——能→RPA，写不全的判断→AI 智能体）、2026 年趋势（RPA 大厂 UiPath、Automation Anywhere、Blue Prism 纷纷智能体化——走向融合；问题不再是「选哪个」而是「把判断放在哪里」＝编排优先），以及实战答案：混合方案，由脑（AI 智能体）负责判断／编排、手（RPA）执行确定性任务——不要在需要确定性的地方放智能体，委派判断时务必配套护栏与人工审批。基于各厂商官方信息，附常见问题。

Claude Fable 5 和 Opus 5 都是顶级模型，但答案既不是「永远用 Fable 5」也不是「永远用 Opus 5」——要按任务来选。而 2026 年 7 月 24 日 Opus 5 的登场，把这个答案往前推了一大步：上一代的 Opus 4.8 处在「比 Fable 5 差一档、但便宜一半」的位置，Opus 5 却在维持同样 $5 / $25 价格的同时，在智能体类基准测试上追平甚至反超 Fable 5（Frontier-Bench 43.3% 对 33.7%、OSWorld 2.0 70.6% 对 66.1%，均来自媒体报道；CursorBench 3.2 上 Anthropic 官方表示其成绩与 Fable 5 相差不到 0.5%，而成本约为一半）。单轮最高难度推理仍略偏向 Fable 5，但差距极小——Humanity's Last Exam 56.5% 对 56.3%、DeepSWE v1.1 69.7% 对 68.8%（媒体报道数字）。规格上两者同为 1M 上下文窗口与 128K 最大输出；快速模式（约 2.5 倍速）只有 Opus 5 提供，但价格翻倍且仅限 Claude API，而 Opus 5 的知识截止更新，为 2026 年 5 月。决策流程是：先试 Opus 5，只在它触顶的地方才升级到 Fable 5。实务中「以 Opus 5 为主力、难点交给 Fable 5」最优，再配合应用内安全拦截时的自动切换，以及 API 新增的回退用「default」模式。文中还涵盖可用性（6 月暂停、7 月重新上线）、避免依赖单一模型、用 effort 调节成本，以及 FAQ——把 Fable 5 系列文章与 Opus 5 发布解读串联起来。

把 AI 智能体接入实际工作时，第一道坎就是「到底用哪个框架来搭建」。本文站在开发者与技术选型者的视角，从编排方式（有向图／基于角色的 crew／对话型 GroupChat／交接／层级树／自主工具循环）、语言、学习曲线、可控性、生产成熟度、token 成本与适配用途，比较六大主流框架——LangGraph、CrewAI、AutoGen（已并入 2026 年 4 月 GA 的 Microsoft Agent Framework）、OpenAI Agents SDK、Google ADK 与 Claude Agent SDK。关键提醒：那个「最好试作」的框架（CrewAI）在生产环境里可能最贵——token 约为 3 倍（某基准测试中为 41k，而 LangGraph 为 18.5k），且非确定性，因此不适合金融与医疗。文中还说明 2026 年如何通过 MCP（工具）与 A2A（智能体之间）实现互操作，使不同框架的智能体如今能够协同工作、厂商锁定随之淡化。附带按用途的选型指南与 FAQ。

开始上手本地 LLM 时，最先该装的首选工具就是 Ollama——它就像「LLM 版的 Docker」，几乎替你包办了所有繁琐的环境配置，只需一条命令即可下载量化模型并开始对话。本文面向初学者，一气呵成地讲解从 Win/Mac/Linux 安装、run/pull/list 等核心命令、按显存选择模型、套上 Open WebUI 等聊天界面、运行在 localhost:11434 的本地 API（含只改端点即可复用现有代码的 OpenAI 兼容 API）、用 Modelfile 与环境变量自定义，到速度慢、内存不足、API 连不上等常见问题排查的完整流程，让你既能先跑起来，又能进一步嵌入到自己的应用并把它当作云端的后备方案。

本地LLM跑得起来后，下一个难题是「到底装哪个模型」。本文把2026年的主流开源模型按开发方、出身国、用途、大小和许可证全面梳理，帮你选出最适合自己电脑和目标的「第一个」。其中重点介绍Qwen（阿里巴巴）、DeepSeek、GLM（智谱）等既是国产、也是全球开源第一梯队的中文模型，以及Yi、InternLM、Baichuan、MiniMax、Kimi等值得关注的国产力量；同时澄清「本地运行输入不外流」这一关键前提，并给出按显存大小和用途的具体推荐与商用许可证注意事项。

想跑本地 LLM，最先担心的就是"我的电脑跑得动吗"。其实所需配置的 90% 都取决于 VRAM（GPU 显存）——只要把这一点搞定，就能立刻判断什么能跑、什么跑不了。本文按模型大小给出一张 VRAM 速查表和一个简单公式（大小 B × 约 0.6），讲清会随上下文长度增长的 KV 缓存陷阱，并对比 RTX 3060/4090/5090 与 Apple Mac 的实际速度。最后按预算分入门、标准、硬核三档给出推荐配置，让初次接触的人也能弄清自己该买哪一款。

在自己电脑上运行的本地 LLM，和 Claude、ChatGPT、Gemini 等云端服务型 LLM，同样都是「LLM」，但在性能、成本、隐私和投入精力上有着明显的不同。本文用一张对比表把两者一览无余，并诚实梳理常被误解的「性能差距」在 2026 年缩小到了什么程度。在此基础上，再针对你的具体用途引导你该选哪一个——对大多数人来说，混合使用才是答案。文章即使没有任何前置知识也能读懂。

Claude Code 模型名旁的 "Effort" 滑块决定 AI 每次回复投入多少思考与 token。本文解析 low–max 这 5 个 API 等级、为何 "Extra" 等于 xhigh 而最高档是 "Max"，以及 Ultracode 模式的设置方法与适用场景。

Agent Evals 是系统性地衡量一个智能体——会使用工具、分多步去达成目标的那种——是否真的能完成其任务的过程。它是 LLM 评估的演进，把评估对象从「一条输出」扩展到「一连串行动」。因为智能体会规划、调用工具并更新状态，仅凭最终输出是不够的；Google 指出你必须理解智能体行动背后的「为什么」，并把评估分为最终响应与 trajectory。五个维度是：结果（任务成功，以最终状态判断——DB 中是否存在一条预订记录，而非「我订好了」这句话）、trajectory（步骤是否合理、是否以正确顺序使用对的工具）、工具使用的正确性（对的工具与参数，检查函数名和类型）、效率（步数、token、成本、延迟——往往是被引入评估的可观测性信号），以及最终响应的质量（用 LLM-as-judge 或评分量表）。打分器有代码（快／便宜／可复现但脆弱）、LLM-as-judge（灵活但非确定性、需校准）和人工（黄金标准但昂贵——能避免就避免）。Anthropic 建议给结果而非路径打分：机械的 trajectory 匹配「太死板、太脆弱」，因为智能体会找到合理的替代方案，而 Google 和 Microsoft 则提供 trajectory 匹配指标用于诊断失败。特有陷阱包括非确定性（pass^k）、误差累积（p^t）、奖励黑客（DeepMind 的机械臂伪装抓取），以及过时或被污染的评估集。Anthropic 的实战打法：把 20～50 个生产失败变成测试用例，在 CI 中运行自动打分，区分能力评估与回归评估，并尽早编写。SWE-bench、τ-bench、WebArena、GAIA、OSWorld、BFCL 等基准是有用的参考（分数随版本变化，别照单全收）。基于官方信息，并对不确定之处加以标注。

Claude Code hooks 是用户定义的 shell 命令，在 Claude Code 生命周期的特定时点自动运行，让「必须始终发生」的事真正落地、确定性执行，而不依赖 LLM 的判断。经典事件有 9 个——SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、Notification、Stop、SubagentStop、SessionEnd、PreCompact——其中 PreToolUse 等可拦截（阻止受保护文件编辑或危险命令）。你在 settings.json 的 "hooks" 键下以「事件名 → matcher → type + command」的形式配置。输入/输出约定：钩子从 stdin 接收 JSON（session_id、tool_input 等），并通过退出码 0（成功）/ 2（拦截，stderr 回传给 Claude）或结构化 JSON（continue、decision:block、permissionDecision: deny/allow/ask）返回。核心原则是「钩子可以收紧但不能放松限制」（deny 始终胜出，即便在 bypassPermissions 下也会拦截）。经典用例：编辑后自动格式化（PostToolUse + Edit|Write）、保护关键文件、拦住危险命令、重新注入上下文（SessionStart）、通知/审计日志、停止前先测试（Stop）。安全方面，钩子以你的权限运行任意 shell 命令，故只配置可信的钩子并校验/加引号处理输入；钩子配置在会话启动时被捕获固定（一项安全特性），因此会话中途的改动不会生效。基于官方文档，以经典的 9 个事件和输入/输出约定为锚点。

checkpointing 与 /rewind 是一张安全网：Claude Code 会在你工作时自动追踪 Claude 的文件编辑，让你用几下按键回退到"出问题之前"。系统在每次编辑前拍下快照，你发送的每个提示都会成为一个还原点，且检查点跨会话保留。使用时，输入 /rewind 或在输入框为空时连按两次 Esc 打开菜单，选好一个点，然后选择还原代码和对话 / 还原对话 / 还原代码（注意：如果输入框含有文字，连按两次 Esc 会改为将其清空）。最重要的注意点：只有由 Claude 的编辑工具（Write/Edit/NotebookEdit）所做的改动会被还原——bash 命令（rm/mv/cp）的文件改动、会话之外或来自其他会话的改动、目录操作、远程文件以及数据库状态都不会因回退而被撤销。文档将其定位为"检查点 = 本地撤销，Git = 永久历史"，指出它是补充而非替代版本控制，因此原则上要在里程碑处向 Git 提交。/rewind 也是与工具调用并发和思考块相关的 400 错误的恢复方法（产品本身会提示你运行它），不过 v2.1.156 之前的版本可能无法清除它，因此先 claude update 为上。它在交互式 CLI 中默认开启，在 Agent SDK 中需选择启用，并随会话保留 30 天（可配置）。基于官方文档，并标注了不确定之处。