《一部影片看完 Stanford AI 系統課程，從 LLM 到 Agentic Workflow》
来源：YouTube [Gary Chen]
时长：00:27:24
视频ID：eKW9ITaltWw
链接：https://www.youtube.com/watch?v=eKW9ITaltWw
说明：以下文字按视频原讲述顺序整理，口语、重复和明显噪声已做轻度收束。
LLM的局限与纵向增强之路
如果你關注過 AI，就會發現近一兩年最炙手可熱的職業，一定是 AI Engineer 或 AI Builder。隨著大型語言模型（LLM）能力不斷提升，這群人越來越吃香。他們能幫公司打造內部工具、優化運營流程，甚至有人已經自己動手把想法變成產品，創立了自己的公司。如今，幾乎每家公司都在搶這類人才。
想學 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，在商業場景中一定會撞牆。
舉個例子，ChatGPT 初推出時沒有連網功能，也無法調用工具，頂多只是一個很聰明的問答機器人，無法真正完成一件事。史丹福教授總結了 base model 的幾個常見限制：
第一，缺乏 domain knowledge。比如一組學生在開發自動化農業設備，要用相機判斷作物是否生病。這種農業病害的資料集市面上根本找不到。換句話說，你的公司資料、內部文件、產品規格，base model 都不知道，自然無法根據這些資訊解決問題。
第二，資訊落後。模型不可能每幾個月就重訓一次，新詞、新事件、新公司它通通不認識。年輕人常用的網路流行語，模型大多也聽不懂。
第三，控制困難。LLM 是機率性輸出，同樣的 prompt 兩次跑，結果可能不一樣。在聊天時當然沒問題，但在 production 環境就不行了——使用者問退費，AI 一下說可以，一下說不行，公司就麻煩了。教授指出，連 OpenAI 和 xAI 這樣資金最雄厚、人才最齊全的團隊，都還沒辦法完全掌控 LLM，更別說一般公司。
第四，當 context 太長時，模型表現會明顯退步。現在主流模型的 context window 已經拉到 100 萬 token，約等於十幾本書的長度。即便如此，仍會出現「lost in the middle」的現象。舉例來說，你把「Gary 午餐吃了一顆蘋果」這樣的細節藏進公司過去一年的會議記錄裡，再問模型 Gary 午餐吃了什麼，它可能還是答不出來。雖然這個問題現在已大幅改善，但 LLM 有時仍會遺漏關鍵資訊。
想做 AI 產品，光靠換更強的 base model 是不夠的。你需要在縱軸上用力。接下來這支影片的前半段會介紹強化單一 LLM 的三個核心工具與觀念：Prompt Engineering、Fine-Tuning 和 RAG。後半段則進入系統設計層面，介紹 Agentic Workflow 與評估方法，並以一個客服 agent 的案例，把這些技術串起來，最後也會談到很多人感興趣的 Multi-Agent。
我們先從 Prompt Engineering 開始。史丹福教授認為，prompt engineer 不會成為一個獨立職業，因為提示詞工程應該是每個工程師的基本技能。你不會靠它賺飯錢，但它會伴隨你整個職涯，就像九九乘法表一樣，是基本功。
我之前也拍過一部專門講 Prompt Engineering 的影片，有興趣的朋友可以去看看。這裡分享一個很有意思的研究：頂級管理顧問公司 BCG 曾做過實驗，將一群顧問分成三組：第一組不用 AI，第二組可用 ChatGPT，第三組除了可用 ChatGPT，還接受過提示詞撰寫訓練。
結果發現三件事：
第一，The Jagged Frontier（鋸齒邊界）——AI 不是在所有任務上都表現好。有些任務搭配 AI 顯著加分，但有些反而拖後腿。
第二，Falling asleep at the wheel（在方向盤前打瞌睡）——當你不知道任務恰好是 AI 不擅長的，卻過度信任它，直接送出產出，結果比沒用 AI 還糟。這提醒我們：必須清楚知道 AI 的邊界在哪，才不會在它弱的地方踩雷。
第三，最有趣的現象是，使用 AI 的方式分為兩種：Centaurs 與 Cyborgs。Centaurs 是半人馬，代表分工委派型——丟一個長 prompt 給 AI，讓它做整份簡報，自己去做別的事。Cyborg 是生化人，代表高頻互動型——跟模型一句一句對話協作。
教授說，學生的使用習慣比較像 Cyborg，而企業在自動化 workflow 時則偏向 Centaur。那該用哪一種？關鍵在於任務性質。重複性高、流程清晰的任務，用 Centaur 模式委派即可；需要判斷、創意與反覆校正的任務，才適合用 Cyborg 模式，才能逼出 AI 最佳表現。兩者無優劣之分，實務上都會用，重點是意識到要主動切換。
单模型能力强化三利器：Prompt、Fine-Tuning、RAG
接下來進入實作。一個好的 prompt 必須包含三要素：目標對象、產出格式、核心重點。舉例來說，「請幫我總結這篇文章」是個爛提示詞，因為什麼資訊都沒給。但如果改成「請將這篇再生能源論文整理成 5 個重點摘要，並聚焦其背後的政策意涵」，模型立刻知道對象是政策制定者，長度是五點，重點在政策意涵，產出品質自然大幅提升。
但教授指出，Prompt Engineering 中最常用、最重要的技巧其實不是這些，而是 Prompt Chaining。注意，chaining 跟 Chain of Thought 不同——Chain of Thought 是讓模型 step by step 思考，Chaining 則是把一個複雜的 prompt 拆成多個獨立的子 prompt，前一個的 output 餵給下一個。
用過 n8n 的朋友應該很清楚這概念。舉例來說，你要寫客戶投訴回信。如果用單一 prompt 寫法，就是「讀這封投訴信，寫一封專業回應」——這是一個黑盒子，一旦產出有問題，你也不知道該調整哪裡。
但如果用 Prompt Chaining，拆成三步： 第一，抽出客戶在抱怨什麼； 第二，根據問題起草大綱； 第三，用大綱寫完整回信。
每一步都可以獨立測試、獨立 debug。Chaining 不僅提升模型表現，還帶來 observability——你能觀察 LLM 在做什麼，哪個環節出了問題。
講完 Prompt Engineering，接下來是 Fine-Tuning。史丹福教授的立場很明確：能不做就不做，原因有四：
第一，需要大量優質數據。想 fine-tune 模型，就得有大量標注良好的高品質資料，成本對一般人而言太高。
第二，容易 overfit。模型可能在特定任務上變得很強，但通用問題反而答不出來，失去 base model 原本的廣度。
第三，時效性差，這是最致命的。你花兩個月 fine-tune 完一個模型上線，下個月新一代 base model 就出來，直接打敗你原本的版本。
第四，通常用 Prompt Engineering 就能達到相同效果，且成本低得多。你想換新 base model，原本的 prompt 大多都能直接移植；但 fine-tuned 模型不行。
當然，針對少數情境，fine-tuning 仍有價值，例如法律、科學等需要高精度重複輸出的領域，或當 base model 在某個 domain 表現吃力時。但對大多數人來說，效益不高。
所以，如果你想要把特定 domain knowledge 塞進模型，單純靠提示詞工程塞不下，而 fine-tuning 又成本效益不對，那實作端該怎麼辦？史丹福教授的答案是：RAG。
RAG 是 AI 工程師面試中最常考的題目之一，面試官常常要求你用「五歲小孩聽得懂的方式」解釋什麼是 RAG。無論你是做 AI Builder 還是 AI 工程師，這都是必懂知識。
RAG 解決的痛點包括：context window 太小、長 context 抓不准，以及資訊有時效性或模型會產生幻覺。
以醫療場景中的藥物副作用為例，RAG 的做法很簡單：先把所有資料、文件用 embedding 模型轉成向量，存入向量資料庫（vector database）。所謂向量，就是把一段文字的語意轉成一串數字。語意相近的文字，轉出來的數字陣列在數學空間中距離也較近。
因此，當使用者問「藥物 A 的副作用」，我們不是做關鍵字比對，而是找語意最接近的文件片段。就算文件寫的是「不良反應」而非「副作用」，一樣能命中。
使用者的問題也用相同的 embedding 模型轉成向量，再用距離度量（distance metric）從 vector database 中找出最相關的 documents。
最後，把這些 documents 加上 system prompt 與 user query，組合成餵給 LLM 的最終 prompt。典型的 prompt template 是：
根據以下 documents 回答使用者的問題。如果 documents 裡沒有答案，就說「我不知道」。
這樣設計是為了把模型鎖在你提供的資料範圍內，避免它自由發揮、憑空捏造。
當然，你還可以要求模型回答時附上答案來自第幾頁、第幾章、第幾行，甚至加上超連結，讓使用者能自行回溯資料源驗證。
但單純這樣做有時不夠。例如一份藥物文件可能有 50 頁，整份直接轉成向量，許多細節會遺失。因此通常會搭配 chunking——最基本的作法是把文件切成固定大小的片段，每段各自轉成向量。
更進階的做法是多層次存儲：同時保留整篇、每章、每段的向量。檢索時可先找到相關章節，再往下鑽到精確段落，提高大文件中的命中率。
最近也有不少人討論：既然現在已有模型支援超長 context window，未來算力足夠便宜，base model 直接讀完整個資料庫，RAG 就沒用了？
但史丹福教授認為，理論上對，實務上錯。因為實際上你仍會遇到諸如 latency（延遲）的問題。每次問問題，都要讓模型重讀整個 Google Drive，沒人等得起。就像搜尋引擎依賴預先建好的索引快速定位資料，不可能每次 query 都重新爬一遍整個網路。
从单模型到系统：Agentic Workflow的思维革命
因此，RAG 不僅提升準確度，還有檢索效率與可即時更新的優勢。這些價值在可預見的未來依然存在。
到此為止，我們完成了影片的第一部分：從 base LLM 的限制出發，介紹了 Prompt Engineering、Fine-Tuning 與 RAG。這三個工具本質上都是在強化單一 LLM 的能力。但單一 LLM 再強，也有做不到的事。
所以接下來進入第二部分：AI 系統設計。我們將講解 Agentic Workflow、Evaluation 與 Multi-Agent。這些技術讓你能把 AI 從一個會回答問題的模型，轉化為一套真正能運作、實際產出價值的系統。
看到這裡，如果你覺得這支影片對你有幫助，歡迎按個讚、點個追蹤，這是我持續創作下去的動力。
我們直接進入 Part 2。
先談 agentic workflow 這個名詞的由來。這個詞出自吳恩達（Andrew Ng）。如果你不認識他，他是 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 擷取政策，主動詢問訂單編號，透過 tool 查閱訂單狀態，確認退費資格，再告知「3 到 5 個工作天內處理」。
可見，RAG 是工具，Agent 是使用 RAG 這個工具的系統。
要打造 agentic workflow，你的工程心態必須翻轉過來。因為傳統軟體與 agentic AI 軟體，在四個面向上截然不同：
首先是資料。傳統軟體處理結構化資料——JSON、資料庫、表單，格式固定，邊界清晰。而 agentic 系統處理的是自由文本、圖片、音訊，沒有固定格式。
使用 RAG 检索政策信息，主动询问订单编号，并通过工具查询订单详情，确认退费流程后告知用户将在3到5个工作日内处理。RAG 是一种工具，而 Agent 是使用 RAG 这类工具的系统。要构建一个 agentic workflow，首先必须转变工程思维——因为传统软件与 agentic AI 软件在四个维度上存在根本差异。
首先是数据形态：传统软件依赖结构化数据，如 JSON、数据库表单等，格式固定、边界清晰；而 agentic 系统则处理自由文本、图片、音频等非结构化内容，没有统一格式。
其次是逻辑特性：传统软件是确定性的（deterministic），相同的输入始终产生相同的输出，可预测、可重现；而 agentic 系统具有模糊性（fuzzy），同样的输入在不同时间运行可能得到不同结果，因为 LLM 本身带有随机性，且会根据上下文动态判断，不存在唯一正确答案。
第三是架构思维，这一点最为关键。传统工程师习惯于编写 microservices 或 monolith，精确控制每一步执行路径；而 agentic 系统的思维方式应像一位管理者——你只需设定目标和约束条件，让 AI 自行决定如何完成任务。你关注的是方向与边界，而非每一行代码的具体实现。
第四是测试方式：传统测试是确定性的，重复运行一百次结果一致；而 agentic 系统的测试必须采用迭代探索式方法，因其本身是非确定性的，且对上下文高度敏感，无法穷举所有场景。
理解这四点后，第一个落地原则自然浮现：能用确定性方式解决的问题，就用确定性方式解决；剩下的模糊部分，则需加入“护栏”机制。
教授以自己团队开发的技能评估系统为例说明：选择题、配对题、拖拽题这类有标准答案的题目，采用确定性评分；但语音题或语音+编程混合题型，因无标准答案，只能交由 LLM 判断，这就是所谓的 fuzzy scoring——即基于程度的评分。例如，让 LLM 听一段语音回答，评估其是否真正理解概念、表达是否清晰、逻辑是否连贯。这些都不是对错问题，而是程度判断，LLM 给出的分数是它认为合理的估计，而非计算得出的结果。
然而，模糊问题必然伴随错误风险：LLM 可能误判正确答案，也可能对模棱两可的回答打分过低。在考试评分这种高风险场景中，这是不可接受的。因此他们设计了“申诉功能”（Appeal feature），允许受测者对 AI 的评分提出异议，由真人介入审查并纠正。这正是“护栏”的具体体现——不是追求 AI 零错误，而是在它出错时有人能及时接住。
讲完原则，接下来是如何实际打造一个 agent。教授以“帮用户订去巴黎的机票”为例，提炼出三个核心要素。
第一是 Prompts，即提示词工程，在 agent 中扮演核心角色。你需要清晰定义 AI 的角色、能力边界与行为规范。
第二是 Context Management，即如何管理 agent 在每个时刻所能看到的信息。这包括对话历史（memory）、RAG 检索回来的内容等，都必须塞进有限的 context window。你需要决定哪些信息重要、哪些可以丢弃、哪些需要压缩。本质上，Context Management 就是确保在恰当的时间，把正确的信息提供给 agent。
Memory 又分为两层：Working memory 是高频、快速访问的，比如用户姓名、本次目的地是巴黎；Archival memory 是低频、可延迟获取的，如用户过去五年的预订记录，需要时再调取。
第三是 Tools，即 agent 可调用的外部能力。通常分为两类：一类是执行类操作，如航班搜索、酒店预订、支付；另一类是查询类操作，如从 CRM 获取客户资料，或从数据库查订单记录。
此外，课程中将 agent 的自主性划分为三个层级：最低级是 hard-coded steps，所有步骤完全写死，按顺序执行，安全可控但僵化，遇到意外情况容易卡住；第二级是 hard-coded tools，但允许 agent 自主决定执行顺序。你提供一组可用工具，并告诉它是旅行代理，具体怎么组合由它自己判断。这种方式既保持了工具范围的可控性，又赋予 agent 一定决策空间，是目前最常见且推荐的生产环境起点；第三级是 fully autonomous，agent 不仅自主规划步骤，还能自行创建工具，比如配备代码编辑器、网页搜索能力，让它自己写代码解决问题。虽然能力最强，但风险也最高——一旦判断失误，可能造成灾难性后果，比如误订 100 张机票。
还有一个关键概念是 MCP（Model Context Protocol）。传统做法是为每个 API 单独编写对接逻辑，教 LLM 如何调用、传什么参数；而 MCP 则在中间引入一个协议层，agent 不必了解每一个 API 的细节，只需与 MCP server 通信，由它负责与后端服务对接。你可以把 MCP 想象成一个通用插头：过去各国插座规格不一，需带一堆转接头；有了 MCP，插一个就能全通。
斯坦福教授还提出了更宏大的愿景：agent-to-agent communication。这意味着你可以将别人开发好的 agent 当作工具来调用，就像现在调用 API 一样。这构成了 multi-agent 系统的基础，我们稍后会详细讨论。
无论是单个 agent 还是多 agent 系统，上线前都必须回答同一个问题：它真的有用吗？答案是——eval（评估）。评估也是生产级 agentic 系统的生命线。
教授在课堂上给出了一个完整的评估框架，包含三个维度的交叉：
第一个维度是 End-to-End 与 Component-based。End-to-End 关注整体效果，比如用户最终打几分，是否满意；Component-based 则拆解每一步，比如某个工具总是忘记更新邮箱，发送邮件的格式出错。只看整体，不知道哪里坏了；只看组件，可能修好了细节却仍影响整体体验。实践中两者缺一不可。
第二个维度是 Objective 与 Subjective。Objective 是可自动验证的，例如用户说订单号是 X，LLM 写入数据库变成 Y，这类问题可以用 Python 脚本自动比对，对就是对，错就是错。Subjective 则没有标准答案，如语气是否友好、回应是否有同理心，这类评价需人工打分，或使用另一个 LLM 作为评审。
第三个维度是 Quantitative 与 Qualitative。Quantitative 是数字指标，如改地址成功率、各环节延迟时间；Qualitative 是主观感受，如是否存在幻觉、语气是否突兀、用户在哪一步卡住。这部分必须人工逐条分析，没有捷径。
前面提到的用 LLM 作为评审（LLM-as-Judge），是做 subjective eval 的常用手段。主流有四种玩法：第一种是 Pair-wise comparison，给 judge 两个答案，问哪个更好；第二种是 Single-answer grading，直接打 1 到 5 分；第三种是 Reference-guided pair-wise，额外提供一个标准答案作为对比依据，使评分更有参照；第四种是 Rubric-based，自定义评分标准，例如五分要求在一百字以内，包含三个重点，首句为概述；零分则是答非所问、冗长失焦。这四种方法可以混合使用，例如结合 rubric-based 和 few-shot examples，帮助评审更清楚理解期望。
如何实际运行一次 subjective eval？教授以旅行代理的礼貌度评估为例，共分四步：第一步是 error analysis，从一千个用户对话中抽样二十个进行人工阅读，你可能会发现 LLM 回应过于简短、缺乏同理心，甚至显得冷漠。这一步不能省略，只有先识别出问题，才能设计有效的评估方案。
实战案例：客服代理的全流程构建
第二步是设计 eval，结合 LLM-as-Judge 与自定义的礼貌度评分标准，将第一步发现的问题转化为具体的评分规则。
第三步是 A/B test 模型，固定 prompt，更换底层模型（如从 GPT 换成 Opus），跑同一组对话，让 judge 评分，比较哪个模型更礼貌。
第四步是 A/B test prompt，固定模型，将“act like a travel agent”改为“act like a helpful travel agent”，观察仅一个词的变化带来的影响有多大。
核心原则只有一个：先人工扫描发现问题，再设计自动化评估；且每次只改变一个变量——要么换模型，要么改 prompt，否则无法判断差异来源。
讲完评估，教授给出一个完整案例研究，串联起前述所有内容。题目很简单：我们要做一个客服 AI agent，用户说：“我要改 A127 订单的地址，因为我搬家到建国南路了。”表面看是改地址，本质是构建一个能自主处理客服请求的 agent。
一位学生回答：“我会先在客服旁边坐一两天，观察他们真实如何处理这类请求，了解日常的工作流。”教授非常赞赏这个答案，因为你要先理解人类怎么做，才能让 AI 做得同样好。而这正是构建 agentic workflow 的第一步——task decomposition，即将大任务拆解为小任务，让 LLM 逐个击破。
经过观察，你会发现客服处理改地址请求其实包含五个步骤：第一步，提取关键信息，包括用户意图、订单号、新地址；第二步，查询客户记录数据库；第三步，查阅公司政策，判断该订单是否可改地址、是否已发货；第四步，基于收集的信息起草回复邮件；第五步，发送邮件。
每一步都清晰明确，这就是 task decomposition 的价值。
下一步是决定每一步使用什么工具：第一步提取信息，通常一次 LLM API 调用即可解决；第二步查改数据库，需定制工具或通过 MCP server 实现；第三步政策检查，使用 RAG，因为政策文档会更新，必须高效检索，不能让用户久等；第四步撰写邮件，利用前几步收集的信息；第五步发送邮件，调用 agent 可用的邮件发送工具。
判断依据很简单：先问哪些步骤是 fuzzy（模糊），哪些是 deterministic（确定）；再决定每一步用 LLM one-shot、RAG、tool 还是其他工具。这正是 AI Builder 真正在做的事——理解每种技术的能力与局限，然后调配出符合需求的解决方案。
最后是建立评估体系，综合运用前述三个维度：End-to-End 评估最终回复的准确性、语气、用户满意度；Component-based 拆解每一步，检查信息抽取准确率、API 错误率、政策遵守率；Objective 部分可自动化验证，如订单号是否正确、是否违反退费政策；Subjective 部分则靠人工加 LLM-as-Judge，如回信是否有礼貌、是否体现同理心；Quantitative 看改地址成功率、延迟时间、退费正确率；Qualitative 则关注幻觉出现位置、语气不一致处、用户卡顿环节。
至此，一个完整的 AI 客服 agent 从零到上线的工程流程便完整呈现。整个过程归根结底只有三步：先把大任务拆解为小任务，再设计工作流程，最后建立评估系统，确保产出稳定可靠。
课程最后一个主题是 Multi-Agent。前面一个 agent 已经能拆解步骤、调用工具、做 RAG、写信，看起来已经足够。但 multi-agent 依然有其存在的意义。
主要原因在于并行处理：有些任务本就不该排队。比如订机票时，找航班、找酒店、查天气完全可以同时进行。如果只有一个 agent，只能一件件做；而 multi-agent 可将这些可并行的任务分配给三个专业 agent 同时执行，效率大幅提升。
多智能体系统：何时需要？如何设计？
次要原因是可复用性（reusability）：公司内部的设计 agent 可供市场团队使用，也可供产品团队调用，提升资源利用率。
尽管听起来很强大，但在实际产品设计中，必须先问自己：真的需要吗？如果一个 agent 就能解决问题，硬上 multi-agent 反而增加复杂度。因此，工程设计的核心原则仍是：能简单就简单，避免过度设计。
教授以智能家居为例进行头脑风暴：一个完整的 multi-agent 系统可能包括温度控制、灯光管理、安保、娱乐、通知、能源管理等多个 agent，外加一个 Orchestrator 统筹协调。交互模式有两种：第一种是 Hierarchical，用户只跟 orchestrator 对话，由它派发任务给下层 agent，指挥链清晰；第二种是 Flat，agent 之间直接互通，无需中介。
教授建议智能家居以 hierarchical 为主，因为从用户角度，你不想同时跟五个 agent 对话，只想说“我要出门了”，系统就会自动协调灯、安防、温控。但在后台，某些 agent 之间可以建立水平沟通通道，比如温度控制 agent 与能源管理 agent 直接联动，省去每次都经过 orchestrator 的通信开销。
当你让 agent 之间互相沟通时，本质上就是在使用 MCP protocol——你把 agent 当作 tool 来调用。
在系统架构设计中，有两种常见的Agent协作模式：一种是分层式（Hierarchical），由 orchestrator 指派任务给下层的 agent，指挥链清晰；另一种是扁平式（Flat），各 agent 之间直接通信，没有中间协调者。教授建议智慧家庭系统以分层式为主，因为从用户角度出发，你并不想同时跟五个 agent 对话，而是只需对一个 assistant 说“我要出门了”，它便会自动协调灯光、安防、温控等各项功能。而在后台，某些 agent 之间仍可建立水平沟通的连接，例如温度控制 agent 与能源管理 agent 可直接互通，避免每次都要经过 orchestrator 的通信开销。
当你让 agent 之间互相沟通时，本质上就是在使用 MCP 协议——把 agent 当作工具，就像把 API 当作工具一样。一旦建立起这种思维，系统设计就变得清晰：每个 agent 对外暴露一组类似工具的接口，其他 agent 就像调用工具一样调用它。这样的结构干净、易于调试，也支持并行处理。
多智能体系统听起来复杂，其实只是将你已掌握的知识再叠加一层而已。最后我们来总结这堂课的重点：本片从基础模型的局限讲起，逐步深入到提升模型表现的各项技术。第一层是 Prompt Engineering，这是最低成本强化 LLM 输出的方法，关键在于 chain 构建与测试。第二层是 Fine-Tuning，除非你在处理法律、科学这类需要高精度重复性的领域，或出于兴趣，否则不建议随意调参。第三层是 RAG，是弥补模型知识短板的标准方案，做 AI 产品几乎一定会遇到。第四层是 Agentic Workflow，从强化单一 LLM 走向系统级设计，核心在于思维转变——从过去的确定性工程（deterministic engineering）转向如今的模糊工程（fuzzy engineering），并建立相应的评估体系。实战中要从任务拆解开始，逐步构建自己的 agentic workflow。
第五层是 Multi-Agent，将每个 agent 视为独立工具，通过协作提升处理效率与复用性。教授在两小时内完整梳理了产业界常见的实作技巧，每项技术存在的理由与适用情境都交代得清清楚楚。有了这样的认知，你就不会盲目跟风：看到别人做 multi-agent 就跟着上，看到别人谈 fine-tuning 觉得很酷就去折腾自己的模型。
那么你的下一步该怎么做？我的建议是：从实践中学习。观察生活或工作中的痛点，从问题出发思考解决方案。在这个过程中，你会自然意识到自己需要掌握哪些技术，从而高效规划学习路径。我把这支影片整理成一篇深度文章，附带四组 prompts，帮助你理清 workflow 如何拆解、现有架构是否过度设计、如何建立评估系统，以及是否真的需要引入 multi-agent。有兴趣的朋友可以在视频信息栏找到链接。
今天的分享就到这里，如果你喜欢这类内容，欢迎点赞支持，并在评论区告诉我你想看什么主题。我们下次见。
本文由 AI 基于转写整理，仅供复查参考。