# 《一部影片看完 Stanford AI 系統課程，從 LLM 到 Agentic Workflow》

> 来源：YouTube [Gary Chen]
> 时长：00:27:24
> 视频ID：eKW9ITaltWw
> 链接：https://www.youtube.com/watch?v=eKW9ITaltWw
> 说明：以下文字按视频原讲述顺序整理，口语、重复和明显噪声已做轻度收束。

---

## 基础模型限制与纵轴工程路线

如果你有在关注 AI，这一两年最炙手可热的工作一定是 AI Engineer、AI Builder。大型语言模型越强，这群人越吃香，他们有能力帮公司打造内部工具、优化运营流程，也已经有一堆人自己动手把想法做成产品，成立了自己的公司。而这种人，现在每间公司都在抢。想学 AI 的人很多，但大多数人都不知道从哪里下手，市面上的资源不是太破碎就是太过艰涩，看完还是不知道自己学到了什么，或者下一步该往哪走。

斯坦福大学有一堂课叫作 Beyond LLM，我认为这是目前最接近那个答案的东西。从大型语言模型的本质讲起，一路带到 Prompt Engineering、RAG、Fine-Tuning、Agentic Workflow，还有 Multi-Agent 的框架。这堂课时长两小时，今天我就用一支影片的时间把核心整理给你。你看完之后，会对 AI 在商业领域上的应用有一套完整的认知框架，知道这些技术怎么组合在一起，也能规划自己接下来的学习路线。那我们废话不多说，直接开始。

首先我们要知道大型语言模型的限制是什么。LLM 要变强有两条路：第一条是横轴，就是换更强的 base model，比方说从 GPT-4 升级到 GPT-5。但横轴是 OpenAI 跟 Anthropic 在做的，一般人没有那个能力，也没有那个金钱去训练自己的大型语言模型。你能施力的地方是纵轴，也就是在现有的 LLM 上面叠各种工程技术，又叫做 Augmenting LLM，也就是想办法提升这些 base model 的能力。而这整堂课，包括这支影片，讲的都是纵轴的事情。如果你只会使用 base model，在商业场景上一定会撞墙。举个例子，ChatGPT 刚出来的时候没有连网功能，没办法调用工具，充其量就是一个很聪明的问答机器人，没办法实际帮你做完一件事。

Stanford 的教授整理了 base model 几个常见的限制。第一是缺乏 domain knowledge。比方说有一组学生做自动化农业设备，要用相机判断作物有没有生病，这种农业病害的数据集市面上根本找不到。换句话说，你的公司资料、内部文件、产品规格，base model 都不知道，它也没办法根据这些资料帮你解决问题。第二是信息落后。模型不可能每几个月重训一次，新词、新事件、新公司它通通不认得，年轻人在用的网络流行用语模型大多也听不懂。第三个，控制很难。LLM 是概率性输出，同样的 prompt 跑两次可能结果不一样。在 ChatGPT 上聊天当然 OK，但你想想生产环境，用户问退费，AI 一下说可以一下说不行，公司就麻烦了。教授说，就连 OpenAI 跟 xAI 这种资金最多、人才最齐的团队，都还没办法把 LLM 完全控制好，更何况一般公司。第四个，当 context 太长，模型的表现会显著退步。现在主流模型的 context window 已经拉到 100 万 token，差不多十几本书的长度，但在这么大的 context 里还是会出现 lost in the middle 的现象。简单讲，你把“Gary 午餐吃了一颗苹果”这样的小细节藏进公司过去一年的会议记录里，再问模型 Gary 午餐吃了什么，虽然这个状况现在已经显著改善，但 LLM 有时候还是会答不出来。想做 AI 产品，光换更强的 base model 不够，你需要在纵轴上施力。

## Prompt Engineering：基本功与最佳实践

接下来这支影片的前半段会告诉你强化单一 LLM 的三个工具和观念，也就是 Prompt Engineering、Fine-Tuning 还有 RAG。影片后半段会进到系统设计，介绍 Agentic Workflow 和 evaluation 评估方法，然后用一个客服 agent 的 case study 把这些东西串起来，最后也会带到很多人感兴趣的 Multi-Agent。那我们直接从 Prompt Engineering 开始讲。

Stanford 的教授说他不认为 prompt engineer 会是一个职业，因为提示词工程应该是每个工程师都该会的基本技能。你不会靠 prompt engineering 当饭吃，但这个技能会让你的职业生涯用一辈子，就像九九乘法表一样是基本功。我之前做过一部影片专门在讲 prompt engineering，有兴趣的朋友可以去看。关于 prompt engineering，有一个很有意思的研究我想分享给你。顶级管理顾问公司 BCG 做过一个实验，他们把一群顾问分成三组：第一组没有 AI，第二组可以使用 ChatGPT，第三组则是在使用 ChatGPT 之外还有接受撰写提示词的训练。最后研究结果发现三件事。

第一个叫 The Jagged Frontier，锯齿边界，意思是 AI 不是在所有任务上都表现得好，有些任务搭配 AI 显著加分，但有些任务 AI 反而扯后腿。第二个发现叫 Falling asleep at the wheel，翻译成中文就是在方向盘前打瞌睡——当你不知道任务刚好是 AI 不擅长的，却太信任它把产出直接送出，结果比没用 AI 还惨。也就是说，你要知道 AI 的边界在哪，才不会在它弱的地方踩雷。第三个现象最有趣，他们发现使用 AI 的方式分成两种，分别是 Centaurs 和 Cyborgs。Centaur 是半人马，也就是分工委派型，丢一个长 prompt 给 AI 叫它做整份简报，自己去做别的事。Cyborg 是生化人，是高频率来回型，跟模型一句一句对话协作。Stanford 的教授说，学生的使用习惯会比较像 Cyborg，而企业在自动化 workflow 时比较像 Centaur。那你应该用哪一种？关键看任务性质。重复性高、流程清楚的任务用 Centaur 模式委派出去就好；需要判断、需要创意、需要来回校正的任务，Cyborg 模式才能逼出 AI 的最佳输出。两者没有好坏之分，实务上两种都会用，重点是要有意识地切换。

接着进到实作。通常一个好 prompt 要有三个东西：给谁看、产出格式、重点是什么。“请帮我总结这篇文章”是一个很烂的提示词，因为什么信息都没给。但如果你写的是“请将这份可再生能源论文整理成 5 个重点摘要，并且聚焦在其背后的政策意涵上”，模型立刻知道对象是政策制定者，长度是 5 个点，重点放在政策意涵上，你的产出质量会立刻提升。但教授说，prompt engineering 里最常用、最重要的一个技巧不是这些，而是 Prompt Chaining。注意，chaining 跟 Chain of Thought 不一样。Chain of Thought 是叫模型 step by step 思考，Chaining 则是把一个复杂的 prompt 拆成多个独立的 prompt，前一个的 output 喂给下一个。有用过 n8n 的朋友应该知道我在说什么。举例，你要做客户投诉回信。单一个 prompt 写法是：“读这封投诉信，写一封专业的回应”，这就是一个黑盒子，最后产出如果有问题你也不知道该调整哪里。但如果使用 prompt chaining，拆成三个 prompt：第一个抽出客户在抱怨什么，第二个用抽出来的问题起草大纲，第三个用大纲写完整回信。每一步都可以独立测试、独立 debug。Chaining 不只让模型表现更好，也让你得到 observability，能观察 LLM 在做什么、哪个流程出了问题。

## Fine-Tuning：能不做就不做

讲完 Prompt Engineering，下一个是 Fine-Tuning。Stanford 教授对 fine-tuning 的立场很简单：能不做就不做。原因有四个。第一，要大量的优质数据。如果你想要自己 fine-tune 模型，就要有大量高质量的、标注好的资料，成本对一般人来说太高了。第二，容易 overfit。模型容易在你那个特定任务上变得很强，但通用问题反而答不出来，就会失去 base model 原本的广度。第三，时效性差，这应该是最伤的点。你花两个月 fine-tune 完一个模型上线，下个月新一代 base model 就出来，直接打贏你 fine-tune 的版本。第四，通常用 prompt engineering 也可以达到一样的效果，而且成本低很多。你想换新 base model，原本的 prompt 大多都是 portable 的，但 fine-tuning 的模型不行。当然，针对少数情境，fine-tune 还是值得做的，比方说法律、科学那种需要重复高精度输出的领域，或者 base model 在某些 domain 上表现吃力的情况。但大多数人不会得到太大的效益。

## RAG：注入领域知识的标准方案

所以，如果你想把特定的 domain knowledge 塞进模型，单纯的提示词工程可能塞不下，fine-tuning 的成本效益又对不起，那实作端应该怎么办呢？Stanford 教授给出的答案是 RAG。RAG 是 AI 工程师面试最常考的题目之一，面试官常常会请你用五岁小孩听得懂的方式解释什么是 RAG。你做 AI Builder 也好，做 AI 工程师也好，这是你一定要知道的事情。RAG 解的痛点有几个：context window 太小、长 context 抓不准、信息有时效性，或者模型会产生幻觉。RAG 的做法很单纯，我用“药物副作用”这个需要高度准确的医疗场景来说明。通常 RAG 的做法是这样：先把所有资料、文件用 embedding 模型把这些信息转成向量，存进向量数据库，英文叫 vector database。所谓向量，就是把一段文字的语义转换成一串数字，语义相近的文字转出来的数字数组在数学空间里距离也会比较近。所以当用户问“药物 A 的副作用”，我们不是在做关键字比对，而是在找语义最接近的文件片段，就算文件里写的是“不良反应”而不是“副作用”，一样能找到。用户的问题也用同一个 embedding 模型转成向量，再用距离 metric 从 vector database 里找出最相近的 documents，最后把这些 documents 加上 system prompt，加上 user query，组合成喂给 LLM 的最终 prompt。Prompt template 大概长这样：“根据以下 documents 回答用户的问题，如果 documents 里没有答案，就说‘我不知道’。”这样设计是为了把模型锁定在你提供的资料范围内，避免它自由发挥、凭空捏造。当然，你还可以要求模型回答时附上这个答案来自第几页、第几章、第几行加超链接，这样用户可以自行回溯数据源进行验证。

但是单纯这样做有时候不够。比方说一种药的相关文件可能足足有 50 页，整份直接转成向量，很多细节遗漏其中。所以通常会搭配 chunking。最基本的 chunking 是把文件切成固定大小的片段，每段各自转成向量。更进阶的做法是多层次存储，同时保留整篇、每章、每段的向量，retrieval 时可以先找到相关的章节，再往下钻到精确的段落，这样在大文件里的命中率会更高。还有一个最近比较多人在讨论题：有人说像现在已经有模型支持超长的 context window，等这个技术成熟、算力够便宜，base model 直接读完整数据库，RAG 就没用了。但 Stanford 的教授认为这样的说法理论上对，实务上错。因为实际上你还会遇到很多问题，比方说 latency——你想想看，每次问问题模型都要把整个 Google Drive 重读一次，没人等得了。就像搜索引擎也是靠预先建好的索引来快速定位资料，不可能每次 query 都把整个网络重新爬一遍。所以 RAG 除了准确度以外，还有检索效率、可即时更新这类优势，而这些优势在可预见的未来都还是有存在的价值。

好，到这边我们讲完了影片的第一部分。从 base LLM 的限制出发，我们看了 Prompt Engineering、Fine-Tuning 还有 RAG，这三个工具本质上都是在强化单一 LLM 的能力。但单一 LLM 再强，还是有它做不到的事。所以接下来进入第二部分 AI 系统设计，我们会讲 Agentic Workflow、Evaluation 还有 Multi-Agent。这些东西让你能把 AI 从一个会回答问题的模型变成一套真正可以运作、实际产出价值的系统。看到这边，如果你觉得这支影片对你有帮助，想请你帮我按个赞、点个追踪，这是我持续创作下去的动力。那我们直接进 Part 2。

## Agentic Workflow：从模型到系统的心法

先讲一下 Agentic Workflow 这个命名。这个词来自吴恩达。如果你不认识他，吴恩达是 Coursera 的共同创办人、Google Brain 的创始负责人、前百度首席科学家，是在 AI 领域讲话有一定分量的人。吴恩达用 Agentic Workflow 这个词是因为 AI Agent 已经被用烂了：有人写了一个很长的 prompt，叫 agent；有人做了复杂的 multi-agent 系统，也叫 agent。这个词什么都能套，反而什么都说不清楚。所以他用 Agentic Workflow 来精确描述一件事：把一堆提示词、外部工具还有各种元件组合进一个有结构的工作流程里，成为一套系统，这就叫 Agentic Workflow。还记得我们前面讲的 RAG 吗？RAG 主要做一件事：给 LLM 外部数据当参考。但 agent 把 RAG 当作工具之一，外加 tool calls、memory、多步骤决策，所以能做到 RAG 单独做不到的事。举个例子，用户说“我想退这笔订单”，RAG 只能丢政策文件给你；agent 则是用 RAG retrieve 政策，主动问订单编号，用 tool 查订单，确认退费，告诉你 3 到 5 个工作日会处理。RAG 是工具，Agent 是使用 RAG 这个工具的系统。

要打造 Agentic Workflow，你的工程心态要先翻转过来，因为传统 software 跟 agentic AI software 在四个面向都很不一样。首先是数据，传统软件吃结构化数据——JSON、数据库、表单，格式固定，边界清楚；Agentic 系统吃的是自由文本、图片、音频，没有固定格式。第二个是逻辑，传统 software 是 deterministic，同样的 input，永远给你同样的 output。

用RAG检索政策，主动询问订单编号，通过工具查询订单，确认退费，并告知你3到5个工作日会处理。RAG是一种工具，而Agent是使用RAG这个工具的系统。要打造agentic workflow，你的工程心态需要先翻转过来，因为传统软件和agentic AI软件在四个维度上差异很大。

首先是数据。传统软件处理结构化数据，例如JSON、数据库、表单等，格式固定，边界清晰。而Agentic系统处理的是自由文本、图片、音频，没有固定格式。第二个是逻辑。传统软件是确定性的，相同的输入永远给出相同的输出，可预测、可重现。Agentic系统则是模糊的，同样的输入在不同时间可能产生不同的输出，因为LLM本身带有随机性，加上它需要根据上下文做判断，没有固定答案。第三个是架构心态，这也是最重要的。传统工程师的思维是写微服务或单体应用，精确控制每一步执行路径。Agentic系统的思维则像管理者，你给AI一个目标和限制，让它自己决定如何完成，你管理的是方向和边界，而不是每一行代码。第四个是测试。传统测试是确定性的，跑一百次结果都一样。Agentic测试则是迭代探索式的，因为系统本身是非确定性的，对上下文非常敏感，你无法穷举所有情况。

理解这四点之后，第一个落地原则就随之而来：能用确定性方法解决的问题，就用确定性方法解决；剩下的模糊部分，则加上护栏。教授举了自己的例子：在做技能评估时，选择题、配对题、拖拉题用确定性方法算分，因为这些问题有标准答案，对就是对，错就是错。但口语题、语音加编码的混合题型没有标准答案，无法用确定性方法评分，只能让LLM去判断，这就是模糊评分。比如，让LLM听一段语音回答，判断这个人是否真正理解了概念，表达是否清晰，逻辑是否正确，这些不是简单的对或错，而是程度的判断。LLM会给出一个分数，但这个分数是它认为合理的答案，不是计算出来的。模糊评分的问题是它一定会犯错，LLM可能误判一个正确答案，或对模棱两可的回答给出偏低分数。在考试评分这种高风险的场景下，这是不可接受的。因此，他们设计了申诉功能，受测者可以对agent的评分提出申诉，由真人介入审查并纠正。这就是护栏的具体形式——不是试图让AI零错误，而是在它出错时有人能兜底。

## 打造Agent：核心要素与工具协议

原则讲完后，要实际打造一个agent需要哪些东西？教授以订机票去巴黎为例，整理出三个核心要素。第一个是Prompts，也就是提示词工程，告诉AI它的角色是什么，它能做什么、不能做什么。第二个是Context Management，即如何管理agent在每一个当下能看到的信息，包括Memory（对话历史）、RAG检索回来的数据等，所有这些都要塞进有限的上下文窗口中。你需要决定什么重要、什么可以丢弃、什么需要压缩。Context Management本质上只做一件事：把正确的信息在正确的时间提供给agent。Memory本身又分为两层：Working Memory是高频率、需要快速访问的信息，比如用户的名字、这次的目的地是巴黎；Archival Memory是低频、可以慢一些的信息，比如用户过去五年的订房记录，需要时再去检索。第三个是Tools，即agent能够调用的外部能力，通常分为两种：一种是做事的，比如航班搜索、酒店预订、支付等；另一种是查资料的，比如从CRM系统检索客户数据、从数据库查询订单记录。

此外，课堂上教授将agent的自主性分为三个层级。最低的是硬编码步骤，所有步骤都写死，必须按顺序执行，比如先识别用户意图、再查询历史记录、最后调用API。这种方式安全、可预测，但很僵硬，遇到预期外的情况就会卡住。第二层是硬编码工具，但让agent自己决定执行步骤。你给它一组工具，告诉它你是旅行顾问，这些是你能用的工具，怎么用由你决定。你控制工具范围，但给agent空间去判断如何组合。这是目前最常见的生产设置，也是教授推荐的起点。第三层是完全自主，agent自己决定步骤，甚至自己创建工具。给它代码编辑器、网络搜索功能，让它自己写代码解决问题。这种模式能力最强，但风险也最高，你无法完全预测它会做什么。如果agent判断错误，自己订了100张机票，你就完蛋了。

还有一个关键概念是MCP（Model Context Protocol）。传统做法是你要为每一个API单独编写串接逻辑，教会LLM如何使用这个API、那个API需要传什么参数。而MCP的做法是在中间放置一个协议层，agent不需要认识每一个API，只需与MCP服务器沟通，MCP负责帮它与背后的服务打交道。可以把MCP想象成一个通用插头——以前每个国家的插座规格不同，你需要带一堆转接头，但有了MCP，插一个就能全部通用。斯坦福教授还提到了对MCP的更大想象：即agent间的通信，你可以把别人做好的agent当作一种工具，让你自己的agent去调用它，就像现在agent调用API一样。这是Multi-Agent系统的基础。

## Evaluation与实战案例

无论是单Agent还是多Agent系统，上线之前都需要回答同一个问题：怎么知道它真正有效？答案是Eval（评估），这也是生产级Agentic系统的命脉。教授在课堂上给出了一个完整的评估框架，包含三个维度。第一个维度是端到端评估与组件级评估。端到端评估看整体，比如用户用完给几分、满不满意；组件级评估则拆开每一步看，比如某个工具老是忘记更新邮件、发送邮件那一步格式不对。只看整体你知道哪里出了问题，但不知道原因；只看组件你可能修复了细节但整体体验仍然差。实际上两者都需要。第二个维度是客观评估与主观评估。客观评估是可以通过自动化验证的，比如用户说订单ID是X，LLM写入数据库变成Y，你可以编写Python脚本自动对照，因为对就是对、错就是错。主观评估没有标准答案，比如语气好不好、回答够不够有同理心，这需要人工评分，或使用另一个LLM作为评审。第三个维度是定量评估与定性评估。定量评估是数字，比如改地址成功率是多少、每个环节的延迟有多长。定性评估是感觉，比如在哪里出现幻觉、语气哪里不对、用户在哪一步卡住，这需要人工逐一查看，没有捷径。

刚刚提到的用LLM作为评审（又称LLM-as-Judge）是进行主观评估的常用做法。设计上有四种主流玩法：第一种是成对比较，给评审两个答案，问它哪个更好；第二种是单项答案评分，直接打1到5分；第三种是参考引导的成对比较，额外提供一个标准答案做对比，让评分更有依据；第四种是基于评分标准的，你自己定义评分标准，比如5分等于100字以内、包含三个要点、第一句是概述，0分等于答非所问、冗长失焦。这四种方法可以混用，比如基于评分标准加上少量示例，让评审更清楚你要什么。

如何实际进行主观评估？课堂上教授以旅行顾问礼貌度评估为例，拆成四个步骤。第一步是错误分析，从1000个用户对话中抽取20个进行人工阅读，你可能会发现LLM说话很短、有点生硬、缺乏同理心。这一步不能省，你必须先了解问题长什么样，才能设计出正确的评估。第二步是设计评估，使用LLM-as-Judge加上自己编写的礼貌度评分标准，将第一步发现的问题翻译成评分标准。第三步是A/B测试模型，固定提示词，将底层模型从GPT换成Opus或其他模型，然后运行同一批对话，让评审评分，看哪个模型礼貌度最高。第四步是A/B测试提示词，固定模型，将“扮演旅行顾问”改成“扮演乐于助人的旅行顾问”，看一个词的差异影响有多大。核心原则只有一个：先人工找出问题，再设计自动化评估，而且模型和提示词这两个变量一次只动一个，否则不知道是哪个改动造成了差异。

讲完评估，教授给出了一个完整的案例研究，把所有前面的内容串联起来。题目很简单：我们要做一个客服AI agent。用户可能会说“我要改A127订单的地址，因为我搬家到建国南路了”。这样的AI客服agent你会怎么做？这个题目有两层：表面上看是如何改地址，本质上是如何构建一个能够自主处理客服请求的agent。课堂上一个学生回答说：“我会先去客服旁边坐一到两天，看他们实际如何处理这类请求，他们的日常工作流是什么。”教授很喜欢这个答案，因为你要先理解人如何做这件事，才知道如何让AI做。而这就是构建agentic workflow的第一步，叫做任务分解，即把大任务拆解成小任务，让LLM可以逐个击破。

经过观察，你会发现客服处理一个改地址请求实际上走了五步：第一步，提取关键信息，包括客户的意图是什么、订单ID是哪个、新地址是什么；第二步，去数据库查询客户记录；第三步，查询公司政策，比如这笔订单能否改地址、是否已经发货；第四步，根据前面收集的信息起草回复邮件；第五步，发送邮件。每一步都很明确，这就是任务分解。有了任务分解，下一步是决定每一步用什么工具。第一步提取信息，单纯用LLM的一次API调用通常就能解决。第二步查询和修改数据库，需要自定义工具或MCP服务器。第三步检查政策，需要用RAG，因为政策文件会更新，且需要高效检索，不能让客户等太久。第四步是根据前几步收集的信息开始撰写邮件。第五步发送邮件，使用agent能够调用的邮件发送工具。做这些判断的方法很简单：先问自己哪些步骤是模糊的、哪些是确定性的，再决定每一步是用LLM一次性调用、RAG、工具还是其他手段。这就是AI Builder真正在做的工作——了解每个工具、每种技术的能力和限制，然后组合出你需要的解决方案。

最后是构建评估，把前面讲的三个维度全部用上。端到端评估看最终回复的正确性、语气、用户满意度；组件级评估拆开看每一步，比如提取信息的准确性、API错误率、政策遵守率。客观部分可以自动验证，比如提取的订单ID是否正确、是否违反退款政策。主观部分需要人工加上LLM-as-Judge，比如回复是否有礼貌、有同理心。定量评估看改地址成功率、延迟、退款正确率。定性评估看哪里有幻觉、哪里语气不一致、用户在哪一步感到困惑。到这里，一个完整的AI客服agent从零到上线的工程流程就出来了，总共三个步骤：先把大任务拆解成小任务，再设计工作流程，最后建立评估系统，确保产出稳定。

这堂课的最后一个主题是Multi-Agent（多智能体系统）。前面单个agent已经能够拆分步骤、调用工具、做RAG、写信，看起来够用了。但Multi-Agent仍然有存在的理由，主要原因是并行处理。有些事情没有理由排队执行，比如订机票时，找航班、找酒店、查天气这三件事完全可以同时进行。如果只有一个agent，就只能一件一件做。Multi-Agent就是把这些可以并行的事情拆给三个专门的agent同时运行，速度直接提升。次要原因是可复用性。公司里的设计agent可以给市场部门用，也可以给产品部门用。不过，Multi-Agent听起来很厉害，但做产品时首先要问自己是否真的需要。如果一个agent就能解决的任务，硬上Multi-Agent反而增加复杂度。所以还是那句老话：工程设计能简单就简单，不要过度设计。

## Multi-Agent与课程总结

教授以智能家居为例进行头脑风暴。一个完整的智能家居Multi-Agent系统可能包含温度控制、灯光、安全、娱乐、通知以及能源管理等agent，再加上一个协调者统筹。互动模式有两种：第一种是层级式，用户只与协调者对话，由它分派任务给下面的agent，指挥链清晰；第二种是扁平式，agent之间直接互通，没有中间人。教授建议智能家居以层级式为主，因为从用户角度，你不想同时与五个agent对话，只想跟一个助手说你出门了，它就会自动协调灯光、安全、温控。但在后台，某些agent之间可以建立横向沟通渠道，比如温度控制agent与能源管理agent直接互通，省去每次都要经过协调者的沟通成本。当agent之间互相沟通时，本质上就是MCP协议的应用——你把agent当作工具。

在层次化（Hierarchical）架构中，由一个 orchestrator 负责指挥，派工给下面的 agent，指挥链清晰。第二种是扁平（Flat）架构，agent 之间直接互通，没有中间人。教授建议智慧家庭以 hierarchical 为主，因为从用户的角度，你不想同时跟五个 agent 讲话，只想跟一个 assistant 说“我要出门了”，它就会自己去协调灯光、保全、温控。但在后台，某些 agent 之间可以有水平沟通的连线方式，比如温度控制的 agent 跟能源管理的 agent 直接互通，省掉每次都要经过 orchestrator 的沟通成本。当你让 agent 之间互相沟通，本质上就是 MCP protocol：你把 agent 当作 tool，就跟把 API 当作 tool 一样。这个心态一旦想通，设计就清楚了。每个 agent 对外暴露一组 tool-like 接口，其他 agent 像呼叫工具一样呼叫这个 agent。这样做结构干净，容易 debug，也支持平行处理。Multi-agent 听起来复杂，但其实只是把你已经懂的东西多叠一层。

好，那最后整理一下这堂课的重点。我们从基础模型的限制开始讲起，并带到能够加强模型表现的技术。首先是 Prompt Engineering，强化 LLM 输出，成本最低，重点放在 chaining 和 testing。第二层是 Fine-Tuning，除非你在处理法律、科学那种需要重复高精度的 domain，或者兴趣使然，否则别没事找事去调模型。第三层是 RAG，帮模型补足知识的标准解法，做 AI 产品基本上一定会碰到。最后是 Agentic Workflow，从强化单一 LLM 进到系统设计，重点是思维上的心态转变——从过往的 deterministic engineering 到现在的 fuzzy engineering，以及应对 fuzzy engineering 的 evaluation 系统，还有在实战上要如何从拆解任务开始，打造自己的 agentic workflow。第五层是 Multi-Agent，把每个 agent 都当成 tool，彼此协作来提升处理速度和复用性。教授在两个小时内跑完产业上常见的实作技巧，每个技术的存在理由和适用情境都交代清楚。有了这样的认知，你就不会盲目跟风——看到别人在做 multi-agent 就跟着做，看到别人讲 fine-tuning 觉得很帅就去玩自己的模型。

那么你的下一步是什么？我给的建议是，从实作中学习。看看你的生活上或工作上有什麼痛点，从痛点出发去思考解决方法。在这个过程中你就会发现自己需要学会哪些技术，就能很有效率地规划自己的学习路线。我把这支影片整理成了一篇深度文章，附带 4 组 prompts：帮你想清楚自己的 workflow 怎么拆、现有架构有没有 over-engineering、帮你建立 eval 系统、以及该不该上 multi-agent。有兴趣的朋友可以在信息栏找到链接。那今天这支影片差不多就讲到这边。如果你喜欢这样的内容，想请你帮我点个赞，也在底下留言告诉我你们想看什么样的内容，那我们下次见。

---

*本文由 AI 基于转写整理，仅供复查参考。*