夜雨聆风斯坦福大学这个 AI 的讲座简直太好了。比我们见过所有 Claude 或者 Prompt 相关的教程都要实用得多。
这门课的标题是 Beyond LLM，光这个标题就很有意思，它没有教大家怎么用某个模型，而是在回答一个更本质的问题：拿到一个大模型之后，怎么才能真正把它用好？
课上有一个实验特别有冲击力。哈佛商学院联合几所大学，找了一批波士顿咨询公司（BCG）的咨询顾问做实验。
BCG 是全球顶级的管理咨询公司，这些顾问本身就是高知人群。实验把他们分成三组：第一组完全不用 AI，第二组可以用 GPT-4，第三组也用 GPT-4 但额外接受了提示词工程的培训。
结果第三组全面碾压。更扎心的发现是，第二组在部分任务上的表现，竟然比完全不用 AI 的第一组还差。
换句话说，一群顶尖咨询顾问，拿到了 AI 却不会用，还不如没有。
这个结论值得展开聊一聊。
播客链接：
https://podwise.ai/dashboard/episodes/6117779
1
那个 BCG 实验里最有价值的概念，叫 JAG 边界线。
简单来说就是，AI 的能力有一条看不见的边界。在这条线以内的任务，AI 确实能大幅提升人的效率和质量。但一旦任务超出了这条线，AI 不仅帮不上忙，还会拖后腿。
为什么会拖后腿？因为人在这种情况下容易出现一种状态，研究者形容得很生动，叫 falling asleep at the wheel，方向盘上睡着了。
就是人一旦觉得 AI 能搞定，就会放松警惕，不再仔细审查输出。
而那些恰好超出 AI 能力范围的任务，AI 会给出看起来很像那么回事、实际上有问题的答案。人没有 review，直接提交了。最终效果比自己独立完成还差。
这件事最值得深想的地方在于：很多人评估自己和 AI 的关系时，关注的是模型够不够强。但这个实验证明，真正拉开差距的，是使用者能不能判断一件事到底在不在 AI 的能力圈内。
实验还发现了两种截然不同的人机协作风格。一种叫半人马 Centaur，把一整块任务打包丢给 AI，等它输出成果。
比如一个咨询顾问要做 PPT，直接写一大段 Prompt 描述清楚要求，让 AI 生成，回来就用。另一种叫赛博格 Cyborg，完全嵌入式协作，一句一句跟 AI 来回交锋，随时纠偏、随时追问，像融为一体那样工作。
学生群体天然更偏赛博格，喜欢高频互动。企业场景更偏半人马，因为需要把一段流程整块外包出去。两种模式没有优劣之分，但知道自己当前处于哪种模式，什么场景该切换，这个意识很重要。
那具体到使用层面，差距从哪里开始拉开？最基础的一步其实就是上下文。
同样是让 AI 总结一篇文章，一个人写的 Prompt 是：总结这篇文章。另一个人写的是：把这篇 10 页的可再生能源论文，用 5 个要点总结，聚焦核心发现和对政策制定者的启示。
两者的产出质量完全不在一个级别。差别就在于后者提供了受众、格式和关注重点。
再往上一层，是 few-shot，也就是在 Prompt 里给几个例子来校准模型。课上有个特别贴切的场景：让模型判断一条产品评论是正面、负面还是中性。
那条评论的内容大意是，产品还行但我期望更高。有人觉得这是中性，有人觉得是负面。在某些高端行业，这算严重差评；在某些行业，这已经算不错了。
如果不提供示例来校准，模型按自己的理解判断，大概率对不上业务需求。加了两三个标注过的例子之后，模型就会按照给定的标准去分类，准确率大幅上升。
这就是 few-shot 的本质：它不是在教模型新知识，是在告诉模型，在我这个场景里，标准长什么样。
有些做得更精细的 AI 创业公司，甚至会持续维护 few-shot 示例库，把用户反馈和人工标注过的 case 追加到 Prompt 里，在不碰模型参数的前提下，持续把模型往自己的业务标准上拉。
2
上面聊的都是单条 Prompt 层面的优化，核心解决的是怎么问的问题。但真实业务场景中，很多任务一条 Prompt 搞不定。
举个课上的例子。假设要给一条客户差评写一封专业回复，最直接的做法是把所有要求全塞进一条 Prompt：读这条评论，写一封专业回复，要承认问题、解释原因、提供解决方案。模型确实能输出，但如果质量不行，根本不知道哪个环节出了毛病。
是没抓住关键问题？是回复结构不好？还是语气不对？全部混在一起，没法定位。
提示链 Chaining 的思路就是把这一条 Prompt 拆成三条。
第一条：从评论中提取关键问题。第二条：基于这些问题，草拟回复大纲。第三条：按照大纲写正式回复。
每一步的输入输出都是独立的，哪一步效果不好，就单独优化哪一步。这个思路就像把一个巨大的单体应用拆成微服务，每个模块可以独立测试、独立迭代。
课上有学生问：三条 Prompt 各自验证过了，能不能再合回一条来减少延迟？答案是：合回去之后中间步骤的输出就看不到了。
那些中间输出恰恰是最有调试价值的东西。比如第一步提取的关键问题是否准确，直接决定了后面两步的天花板。在追求质量控制的场景里，中间可见性比省一两秒延迟重要得多。
那拆完之后，怎么知道每一步到底好不好？这就到了评估 Evals 的问题。最直接的方式当然是人工打分，但不可能大规模用。
更实用的做法是自动化评测：用一个 LLM 来当裁判，做 pairwise comparison，或者设定一套评分标准 rubric，从长度、覆盖率、格式、准确性这几个维度让模型打分。
这个思路之所以重要，是因为它把 AI 工作流从感觉还不错推向了可以量化衡量。有了评估体系，每次改动都有数据支撑，这才算是工程化。
到这里，提示词和提示链本质上都是在优化怎么问。但有一类问题，不管怎么问都没用，因为模型自己脑子里就没有那些知识。
企业内部文档、垂直行业的细分规则、最近刚发生的事件，模型在训练时根本没见过。这时候需要解决的是知道的不够的问题。
这就是 RAG 检索增强生成出场的地方。
RAG 的逻辑很直觉：与其改造模型的大脑，不如给模型配一个随时可查的资料库。具体做法是把文档切块、向量化，存进向量数据库。
用户提问时，先把问题也向量化，去数据库里找到最相关的几段文档，拼接到 Prompt 里一起发给模型。
模型基于检索到的内容来回答，既减少了幻觉，又能标注信息来源。
那为什么不直接微调模型，让它从根上学会这些知识？课上的态度非常明确：大多数情况下不建议微调。
微调需要大量标注数据，成本高；容易过拟合，通用能力反而下降，课上有人拿 Slack 消息微调模型，聊天风格学得很像了，别的任务水平却明显变差；最现实的一点是，模型迭代速度太快，等花几个月完成微调，新一代基座模型已经发布了，原始能力可能已经超过微调过的旧模型，之前的投入全部沉没。
关于 RAG 有一个特别好的讨论：如果未来算力无限，RAG 是不是就没用了？理论上模型可以直接读完所有文档再回答。
这个设想在逻辑上成立，但延迟问题无解，总不能每次回答一个问题就把整个文档库从头到尾读一遍。
就像搜索引擎一样，即便有能力爬下整个互联网的内容，依然需要索引和检索系统来快速定位信息。RAG 解决的是效率和精度问题，跟算力是否充足关系不大。
在具体方法上，RAG 也在持续进化。比如 chunking，不只存整篇文档的向量，也把章节、段落级别的向量单独存起来，检索时能定位到更精确的位置。
还有一个巧妙的方法叫 HIDE：用户的问题往往很短，跟文档库里的长文本在向量空间里距离可能很远。
HIDE 的做法是先让模型根据问题生成一个假想的回答文档，再拿这个假想文档去做检索，因为格式和长度跟真实文档更接近，召回效果会更好。
3
到目前为止聊的所有方法，提示词解决怎么问，提示链解决怎么拆，RAG 解决知道的不够。
但它们有一个共同特点：本质上都还是人发起指令，AI 执行。真实业务里的很多流程是动态的，步骤之间有依赖关系，有些步骤还需要调用外部系统、向用户追问信息才能往下走。
这就是 Agent 智能体要解决的问题：一步搞不完的任务。
课上的例子特别直观。一个客服场景，用户问：我能退款吗？如果只用 RAG，模型查完退款政策会回复一句：购买 30 天内可以退款。标准答案，但对话就断了。
换成 Agent 工作流，Agent 先检索退款政策，然后主动追问订单号，调用订单系统 API 查询详情，确认符合条件，最后回复退款将在 3 到 5 个工作日内处理。这已经不是在回答问题了，这是在完成任务。
Agent 在技术上有三个核心组件：提示词定义角色和行为边界，上下文管理系统负责维持状态和记忆，工具层连接外部 API 让 Agent 能跟真实世界交互。
关于工具层，课上区分了 API 和 MCP（Model Context Protocol）。
API 需要提前硬编码调用方式和参数格式，每个系统写一份。MCP 把模型和外部系统的连接标准化了，Agent 可以自己理解一个端点能提供什么数据、需要什么输入。
打个比方，API 像是给 Agent 一份操作手册，MCP 像是给了 Agent 一种通用能力，看到新系统就能自己搞清楚怎么用。单个 Agent 时差别不大，但涉及多 Agent 通信时，MCP 的价值就凸显了。
这就自然过渡到多 Agent 系统。课上用智能家居做例子：一个 Agent 负责温控，一个负责照明，一个负责安防，一个负责能源管理，上面加一个总指挥 orchestrator 来统筹。
用户只跟总指挥对话，总指挥调度各专项 Agent。好处很直接：每个 Agent 专注一件事，调试简单，而且可以并行运行。
当温控 Agent 需要跟能源 Agent 直接沟通时，比如要开暖气但电费太贵，它们之间的通信方式本质上就是 MCP，一个 Agent 把另一个当工具来调用。
不过课上对多 Agent 保持了克制：单 Agent 和多 Agent 都只是结构选择，关键看任务本身适合什么形态。
把视角拉远一点，Agent 带来的变化远超技术本身。传统软件处理结构化数据，输入输出确定。
Agent 软件处理自由文本、图片、语音，输出带有不确定性。课上有个很精准的总结：最厉害的工程师，是那些能在确定性思维和模糊性思维之间自如切换的人。
设计 Agent 系统的思路也不同，传统按技术模块划分前端后端数据层，Agent 更像在管理一个团队，按业务角色拆分，每个 Agent 负责一个角色。
但落地最难的部分往往跟技术无关。McKinsey 做过一个案例：一家金融机构的信用风险备忘录，传统流程需要一到四周，客户经理从 15 个以上数据源收集信息，信贷分析师花 20 小时以上写初稿，再反复修改。
引入 Agent 工作流后，客户经理直接和 AI 协作，Agent 把任务分给专项子 Agent，从多数据源收集分析、生成初稿，流程时间缩短 20% 到 60%。
技术验证很漂亮。但课上紧接着做了一个非常清醒的判断：想让一万个信贷分析师和客户经理真正改变工作流程，可能需要十年甚至二十年。
改流程就是改人。改人的习惯、改组织的惯性、改绩效考核的标准，每一项的难度都远超技术本身。
4
聊到这里，我们其实已经走完了从提示词到多 Agent 的整条路。值得停下来回头看一看，这五层东西到底在解决什么层次的问题，彼此之间是什么关系。
提示词和 few-shot 解决的是怎么问。模型能力就在那里，但如果不把上下文、受众、格式、示例说清楚，输出大概率不是想要的。这一层做的是校准。
提示链解决的是怎么拆。复杂任务拆成几步，每一步可以独立优化和调试。这一层做的是流程控制。
RAG 解决的是知道的不够。前两层不管怎么优化，如果模型脑子里就没有需要的知识，再好的 Prompt 也问不出正确答案。这一层做的是知识补给。
Agent 解决的是一步搞不完。多步骤自主行动，中间要调 API、追问用户、判断条件再决定下一步。这一层做的是任务执行。
多 Agent 解决的是一个角色管不过来。拆成多个专项角色，并行运行、分工协作。这一层做的是组织分工。
五层之间的递进关系很清楚：校准 → 流程控制 → 知识补给 → 任务执行 → 组织分工。每一层都是在上一层搞不定的时候才需要往上走。
这个递进意识很关键，因为现实中很多团队的问题恰恰是跳层。提示词层面的优化还没做到位，补充上下文和示例就能解决的事情，直接跳到搭 Agent。
Agent 的复杂度比提示词高了好几个数量级，维护成本、调试难度、出错概率都会上升。相反，也有团队死磕提示词，把一条 Prompt 改了 50 版，其实模型本身就缺少必要的领域知识，该上 RAG 了。
判断该不该升级到下一层，有一些实用的信号。改措辞和格式还能提升效果，说明提示词层还有空间。
中间步骤总出错但定位不了，说明该拆成链。事实层面经常出错或缺少关键信息，说明该引入 RAG。任务需要多步动态决策和外部交互，说明该上 Agent。
一个 Agent 职责太杂开始频繁出错，说明该拆成多 Agent。每往上走一层，系统复杂度都会显著增加，所以好的工程判断力，是在当前层把事情做透之后，准确识别出该往上走的时机。
课上的设计理念本身就体现了这种思路。这门课刻意没有深入讲第 17 种 RAG 优化方法，也没有手把手教每一个 Agent 框架怎么用。
原因很直接：技能的半衰期太短了。今天花大量时间学透的某个具体技术细节，两年后很可能已经被淘汰。
所以课程的策略是先给一张足够宽的认知地图，让学生知道这些方向的存在和彼此的关系，需要的时候能快速冲刺去深入。
这个思路对所有跟 AI 打交道的人都适用。
与其追着每一个新工具跑，不如先搞清楚提示词、提示链、RAG、Agent、多 Agent 系统各自在解决什么层次的问题，它们之间是什么递进关系。
有了这张地图，再去追具体技术，速度会快得多，也不容易在信息洪流里迷路。
