🌏 中文版
Video status: Recordings require sign-in or course authorization. Source details
Week 3 is the pivot. Monday (Oct 5, Tool Use & Function Calling) assigns the MCP specification: tools get a standard plug, no more rewriting integrations per vendor. Wednesday (Oct 7, Frameworks & Agent Design) assigns Khattab et al.'s DSPy (ICLR 2024): prompt templates graduate from handcraft into compilable, optimizable programs. That same Monday, HW1 drops, Build an Agentic Harness: no agent frameworks, just a chat-completion call, and you build a company's internal AI assistant from scratch — with the project proposal due Friday (Oct 9). Hand-building in the homework while reading a framework paper in lecture is where this week's tension lives.
MCP: the standard plug for tools
The spec's inspiration is LSP (Language Server Protocol): back when every editor needed per-language rewiring, unification unlocked the ecosystem. MCP wants the same for AI tools, in three roles: the host is the LLM app, building clients, aggregating context, and enforcing consent and security policy; clients are connectors inside the host, one client per server; servers provide context and capabilities, all over JSON-RPC 2.0. Isolation is a stated design principle: servers never see the full conversation or each other. Capabilities are negotiated up front at initialization — undeclared features stay off.
Servers offer three capabilities, each with a controller: Prompts are user-invoked templates, Resources are application-mounted context, and Tools are model-invoked functions. Week 2's ACI gets its standard shape here: tool definitions stop being per-vendor dialects. Clients symmetrically offer three back to servers: Sampling is server-initiated agentic behavior, with model preferences advisory and the client making the final pick; Roots are filesystem boundaries, restricted to file:// URIs in this version; Elicitation is structured user input, new in this version, limited to flat primitive schemas and never for sensitive information.
The security chapter deserves its own read. Tools are arbitrary code execution, and the spec says so up front: tool annotations count as untrusted unless from a trusted server; invocations keep a human in the loop with veto power, sensitive operations need prior user confirmation, and tool inputs should be shown before the call leaves. Sampling requests and responses must be reviewable; roots need user consent before exposure. The protocol governs format; consent flows are the implementor's homework — a line that comes back when HW1 gives the assistant a terminal and a human in the loop.
DSPy: the end of prompt templates
The DSPy paper opens with a provocation: today's LM pipelines are hard-coded prompt templates, long strings accumulated through trial and error. It wants a systematic method instead: abstract pipelines as text-transformation graphs, with LMs invoked through declarative modules. Three moving parts: a signature declares inputs and outputs in natural language (e.g. user_question -> search_query) without saying how to coax the model; a module implements a signature with learnable parameters — the built-in ChainOfThought just prepends a rationale field and delegates to Predict, sketched in about a dozen lines; a teleprompter optimizes by filling each module with bootstrapped demonstrations. Modules carry parameters and teach themselves — generating and collecting demonstrations, composing prompting, finetuning, augmentation, and reasoning techniques.
In practice you write a signature plus a target metric, and the compiler tunes in three stages: generate candidate demonstrations (run the pipeline, keep traces that pass the metric), pick demonstration sets with random search or Optuna, and optionally rewrite program structure (e.g. ensembling compiled copies behind a majority vote). Both case studies reproduce: a few lines of DSPy lift GPT-3.5 to 82% accuracy on GSM8K; the two-hop retrieval program's ensemble answers 45.6% of the HotPotQA test set (that cell covers half the test set, per the paper's cost note); and a 770M-parameter T5 distilled from just 200 labeled questions plus unlabeled ones scores nearly 40% exact match on dev. Small models with good systems beating big models with bad ones — Week 1's thesis with reproducible numbers.
How the two readings relate: the abstraction-level question
Wednesday's lecture title names it: what frameworks abstract versus what you built from scratch. LangChain, LangGraph, and LlamaIndex each pick a different abstraction altitude; DSPy picks "you don't even hand-write prompts." Week 2's brake pedal still applies: frameworks save startup time and charge debugging visibility. Because HW1 bans frameworks, you hand-build every part first; Wednesday's lecture then asks the reverse question: same agent, scratch versus DSPy builds — what did the framework hide, and what did it decide for you?
What to do: swap one stage of your hand-built pipeline into DSPy
What to do: this is an optional exercise, not homework — HW1 itself bans frameworks, so don't submit the DSPy version. Take your Week 2 hand-built RAG (or the email retrieval pipeline you're starting for HW1), lift exactly one stage (say query generation) into a DSPy signature, compile against twenty questions with accuracy as the metric, and compare against the hand-built score plus your time spent. The score gap matters less than three written lines: what decision the framework made for you, which decision you disagree with, and when you would switch back. Those three lines help you read Wednesday's lecture — and can seed the methods paragraph of Friday's proposal.
Where it sits in the course
Week 3 releases HW1 (due Oct 30): start with the email retrieval pipeline, then add tools, a terminal, memory, and a human in the loop until it becomes a full harness; Week 4's ReAct and memory are the middle pieces. MCP only grows from here: Week 5's multi-agent collaboration and Week 9's coding agents (SWE-agent, Claude Code architectures) are all division of labor over standard interfaces. Remember the spec's positioning line: MCP governs format, consent and trust are the implementor's homework.
This week's course material
- Official lecture slides (PDF): Tool Use & Function Calling — Lecture 04; Frameworks & Orchestration — Lecture 05
- Mon 10/5 Tool Use & Function Calling: anchor reading MCP specification (covered above); no additional readings this week.
- Wed 10/7 Frameworks & Orchestration: anchor reading the DSPy paper (covered above); no additional readings this week.
- Course schedule: CS329Z site
Course video sources
The Lecture Recordings section of the official Logistics page (read live on 2026-10-10) says recordings are available only by logging into the course Canvas site. I opened the course Canvas entry (canvas.stanford.edu/courses/233286) and was redirected to the Stanford login page, confirming the sign-in wall. Neither the course site nor a web search turned up a public YouTube or OCW recording, so there is nothing to embed.
Course and recording entries:
Checked: 2026-10-10.
Update Log
-
2026-10-10: Added direct links to this week's official lecture slides, alongside the existing course video sources and recording access notes.
-
2026-09-29: HW1 was restructured (no more Part A / Part B split, no required DSPy rewrite, corpus is now a corporate email archive); rewrote the affected paragraphs to match.
-
2026-10-10: Added explicit video status and checked recording sources and access notes.
-
2026-10-10: Rechecked video status. The official Logistics page says recordings require logging into the course Canvas, opening the entry confirmed the sign-in wall, and no public recording was found; the status is now sign-in required.
References
- Lecture slides: Tool Use & Function Calling — Lecture 04; Frameworks & Orchestration — Lecture 05
- On this site: Week 2: workflows versus agents, Week 1: stop tuning only the model, Stanford CS329Z course guide
- Course: CS329Z schedule
- Sources: MCP Specification 2025-06-18, Khattab et al., DSPy, ICLR 2024
- Tools: DSPy, LangChain, LlamaIndex
Loading...