←News detail

Shao MengUpdated Oct 25 21:07

Stanford CS 329Z Lecture 9 Outlines the Selection of Agent System Optimization Methods

AI summary

Lecture 9 of Stanford's CS 329Z course presents a selection diagram for Agent system optimization: the prerequisite for optimization is having data, a system, and evaluation metrics all in place; generally, context optimization (prompts and few-shots) is done first because it is cheap, fast, and sample-efficient; when context optimization is insufficient, or when you want to distill capabilities into a small model, or when prompts grow longer and longer, then you move on to changing the weights. The lecture notes also review reflective prompt optimization methods such as OPRO, MIPROv2, TextGrad, and GEPA; weight optimization paths such as SFT, RL (PPO vs. GRPO), and on-policy distillation; and approaches that let agents self-optimize, such as the Darwin Gödel Machine, Meta-Harness, and karpathy's autoresearch. They also point out that agents are already decent optimizers, making evaluation metrics the link that most needs to be controlled.

Why read this

AI score 57

The Stanford course breaks Agent optimization into three paths—context, weights, and self-optimization—and provides the criteria for deciding when to choose which.

Topics

Tags

Quoted post

meng shao

@shao__meng

CS 329Z: Engineering AI Agents Stanford / Fall 2026 @stanfordnlp https://t.co/ynvpE8PKFE Course positioning: the engineering discipline from "models" to "systems" Coverage: simple LLM pipelines → compound AI systems → autonomous Agents. The backgrounds of the three instructors are also highly complementary: @Diyi_Yang (Stanford NLP professor, human-computer interaction and social computing) @michaelryan207 (core contributor to DSPy, author of the automatic evaluation AutoMetrics) @jyangballin (author of SWE-agent / SWE-bench / SWE-smith, one of the most important researchers in the field of software engineering Agents) # Course main thread: three major engineering challenges Three core questions run through the entire course—decomposition, data, and evaluation. The 11 weeks of content basically unfold around these three threads and can be divided into five modules: Module 1: Building primitives (Week 2–3) · LLMs as building material: API/SDK (litellm), structured output, constrained generation, decoding strategies, test-time compute, context engineering, model selection and cost/latency trade-offs · RAG: embeddings, vector stores, chunking strategies, hybrid retrieval, cross-encoder and ColBERT late interaction · Tool calling: function calling APIs, MCP (Model Context Protocol), tool design, code sandboxes, error handling and retries Module 2: Frameworks and design patterns (Week 3–5) · Framework layer: DSPy (signature / module / optimizer), LangChain/LangGraph, LlamaIndex, with the focus on "what the framework abstracts vs. what you hand-write" · Design patterns: the taxonomy of workflow vs. agent, five composable workflow patterns, ReAct / plan-and-execute / reflection, "the scaffold itself is a design decision" · Memory architecture: short-term/long-term memory, memory as tool actions, the file system as externalized memory, cross-Agent memory (MemGPT, Mem0, Generative Agents) · Multi-Agent systems: orchestration patterns, handoff and state passing, and a very opinionated pair of contrasting readings—reading both AutoGen and "Why Do Multi-Agent LLM Systems Fail?" as well as Neubig's "Don't Sleep on Single-agent Systems" Module 3: Optimization (Week 5) · A panorama from prompts to fine-tuning: GEPA, MIPROv2, OPRO, TextGrad (prompt optimization); LoRA/QLoRA, distillation, RLHF/DPO (weight optimization); test-time scaling (inference compute) · The core issue is the decision framework: when to optimize prompts, when to optimize weights, and when to throw inference compute at it Module 4: Data and evaluation (Week 6–8)—the most substantial part · Data: three types of data—trace, demonstration, and feedback; training data vs. evaluation data; the data flywheel; synthetic data; building datasets from Agent trajectories (SWE-smith) · Evaluation fundamentals: why eval is hard; the 4-tuple framework (request / environment / stopping criteria / scorer); properties of a good benchmark; tinyBenchmarks · Evaluation infrastructure: three types of graders, prompt design for LLM-as-judge and known biases, pairwise vs. pointwise, non-deterministic metrics pass@k vs. pass^k, harness design Module 5: Safety and frontiers (Week 8–11) · Safety: privacy risks of tool access, prompt injection (including indirect injection), red teaming, sandboxing and permission models, output guardrails, human-in-the-loop · Coding Agents: end-to-end architecture comparison of SWE-agent, Claude Code, and OpenHands · Proactive Agents: from reactive to proactive, General User Models (GUM), Next Action Prediction, and the mixed-initiative question of "when should an Agent act proactively and when should it wait" · Open problems: multimodal/web/computer-use Agents, scientific Agents, long-running architectures, production observability (tracing, monitoring, cost management) # Assignment design: build with one hand, evaluate with the other HW1: Build an Agent system from scratch (10%) Given a paper library, build an Agent that can retrieve and reason to answer scientific questions. · Part A: Use only litellm to hand-write RAG + tool calling + a ReAct-style Agent loop · Part B: Rebuild the key components with DSPy and reflect on what the framework abstracts HW2: Evaluate an Agent (10%) Given a pre-built Agent, design a complete evaluation suite: code-based graders, at least one LLM-as-judge, benchmark tasks built with the 4-tuple framework, and error analysis.

View original

CS 329Z: Engineering AI Agents Stanford / Fall 2026 @stanfordnlp https://t.co/ynvpE8PKFE 课程定位:从"模型"到"系统"的工程学 覆盖:简单 LLM 流水线 → 复合 AI 系统 → 自主 Agent。三位讲师的背景也高度互补: @Diyi_Yang(斯坦福 NLP 教授,人机交互与社会计算方向) @michaelryan207(DSPy 核心贡献者,自动评估 AutoMetrics 作者) @jyangballin(SWE-agent / SWE-bench / SWE-smith 作者,软件工程 Agent 领域最重要的研究者之一) # 课程主线:三大工程挑战 贯穿全课的三个核心问题——分解(decomposition)、数据(data)、评估(evaluation)。11 周的内容基本围绕这三条线展开,可以分为五个模块: 模块 1:构建基元(Week 2–3) · LLM 作为构建材料:API/SDK(litellm)、结构化输出、约束生成、解码策略、test-time compute、上下文工程、模型选型与成本/延迟权衡 · RAG:embedding、向量库、分块策略、混合检索、cross-encoder 与 ColBERT 后期交互 · 工具调用:函数调用 API、MCP(Model Context Protocol)、工具设计、代码沙箱、错误处理与重试 模块 2:框架与设计模式(Week 3–5) · 框架层:DSPy(signature / module / optimizer)、LangChain/LangGraph、LlamaIndex,重点是"框架抽象了什么 vs. 你手写了什么" · 设计模式:workflow vs. agent 的分类学,五种可组合 workflow 模式,ReAct / plan-and-execute / reflection,"scaffold(脚手架)本身就是设计决策" · 记忆架构:短期/长期记忆、记忆作为工具动作、文件系统作为外化记忆、跨 Agent 记忆(MemGPT、Mem0、Generative Agents) · 多 Agent 系统:编排模式、handoff 与状态传递,以及一个很有态度的对照阅读——既读 AutoGen,也读《Why Do Multi-Agent LLM Systems Fail?》和 Neubig 的《Don't Sleep on Single-agent Systems》 模块 3:优化(Week 5) · 从提示词到微调的全景:GEPA、MIPROv2、OPRO、TextGrad(提示优化);LoRA/QLoRA、蒸馏、RLHF/DPO(权重优化);test-time scaling(推理算力) · 核心问题是决策框架:什么时候优化 prompt、什么时候优化 weights、什么时候堆推理算力 模块 4:数据与评估(Week 6–8)——最有分量的部分 · 数据:trace、demonstration、feedback 三类数据;训练数据 vs. 评估数据;数据飞轮;合成数据;从 Agent 轨迹构建数据集(SWE-smith) · 评估基础:为什么 eval 难;4 元组框架(request / environment / stopping criteria / scorer);好 benchmark 的性质;tinyBenchmarks · 评估基础设施:三类 grader、LLM-as-judge 的 prompt 设计与已知偏差、pairwise vs. pointwise、非确定性指标 pass@k vs. pass^k、harness 设计 模块 5:安全与前沿(Week 8–11) · 安全:工具访问的隐私风险、prompt injection(含间接注入)、红队、沙箱与权限模型、输出护栏、human-in-the-loop · Coding Agent:SWE-agent、Claude Code、OpenHands 的端到端架构对比 · 主动式 Agent:从 reactive 到 proactive,General User Models(GUM)、Next Action Prediction,以及"Agent 何时应主动、何时应等待"的 mixed-initiative 问题 · 开放问题:多模态/web/计算机使用 Agent、科学 Agent、长时运行架构、生产可观测性(tracing、monitoring、成本管理) # 作业设计:一手建、一手评 HW1:从零构建 Agent 系统(10%) 给定论文库,构建能检索并推理回答科学问题的 Agent。 · Part A:只用 litellm 手写 RAG + 工具调用 + ReAct 式 Agent 循环 · Part B:用 DSPy 重建关键组件,并反思框架抽象了什么 HW2:评估一个 Agent(10%) 给定一个预构建 Agent,设计完整评估套件:代码型 grader、至少一个 LLM-as-judge、用 4 元组框架构建 benchmark 任务、错误分析。

View original post

Body · AI translation

CS 329Z: Engineering AI Agents Stanford / Fall 2026 @stanfordnlp https://t.co/Ko6UarsQff

Lecture 9: A Selection Diagram for Agent System Optimization Methods. The prerequisite for optimization is having all three: data, system, and evaluation metrics. Generally, context optimization (prompt and few-shots) comes first, because it is cheap, fast, and sample-efficient. When context optimization is insufficient, when you want to distill capabilities into a smaller model, or when prompts keep getting longer, then change the weights. Having the agent optimize itself is also feasible now; at this point, what most needs to be controlled is the evaluation metric itself. https://t.co/Rn4sY872KG

When is optimization worthwhile · The three pillars are indispensable: data (training data, trajectories, demonstrations, human feedback), system (model, workflow, agent), metrics (pass rate, LLM judging, cost and latency). · Optimization solves the "last mile" problem. The model provides general capabilities; optimization makes it fit your specific scenario. Some requirements are hard to express clearly with prompts, and examples plus evaluation can better convey the intent. · Benefits include greater reliability, adaptation to a specific domain, lower cost with a smaller model or shorter prompt, and capturing lessons from both successes and failures. · The opening used a voting example: on PaLM 2, "Take a deep breath and work on this problem step-by-step" had an accuracy of 80.2%, while "Let's think step by step" had 71.8%. This shows that subtle differences in wording can produce a clear gap in results, and it is hard to find the optimum by manual tuning.

Context Optimization 1. Few-shot example optimization · The ordering of examples affects results (Lu et al. 2022). Using entropy on a probe set to select the ordering can approach the best result after exhaustively trying all orderings. · Bootstrapping reasoning: STaR uses rejection sampling to mine correct reasoning processes; DSPy requires no fine-tuning and directly keeps reasoning trajectories with high metric scores as examples, then searches for the best combination. This approach is sometimes better than human-written reasoning or standard answers.

2. Reflective optimization · OPRO: show the LLM historical prompts and their corresponding scores, and let it write new prompts. "Take a deep breath" was found this way. · MIPROv2 has three steps: first bootstrap examples; then, combining program structure, data characteristics, successful trajectories, and writing techniques, generate multiple candidate instructions; finally, use a Bayesian surrogate model on small batches of data to search for the optimal combination of "instruction + examples." · TextGrad: have the LLM propose improvements to the output, which are back-propagated like gradients through the various prompts in the system. · GEPA: performs prompt evolution based on reflection and keeps candidates on the Pareto frontier. The lecture notes conclude that it outperforms baselines on multiple tasks and is far more sample-efficient than RL.

Weight Optimization · SFT: use a strong teacher model to run agent tasks, take the trajectories to train a student model, and you can also first verify the results and keep only the correct ones. For example, FireAct fine-tuned Llama2-13B with GPT-4 trajectories, and the result surpassed directly prompted GPT-3.5. The key is that the tasks and environments must be sufficiently diverse. · RL: let the student model run tasks itself and give rewards based on whether the task is completed, provided the results are verifiable. The lecture notes compare PPO and GRPO: PPO must keep 4 models in memory and train 2 per step; GRPO needs only 3 and trains 1 per step, with the advantage value computed directly as the z-score of rewards within the group. DeepSeek-R1 uses GRPO. · On-policy distillation: the student model samples and generates on its own, and the teacher scores token by token, like "reviewing the games you have played." The cited Thinking Machines result is that it is more efficient than RL and produces a better trained model.

Letting the agent optimize itself · Darwin Gödel Machine: the agent modifies its own code. When choosing which version to use as the "parent," better performance gets priority, and the more existing children a version has, the lower it ranks. Ablation experiments show that both "self-modification" and "returning to an early version to re-explore" are indispensable. · Meta-Harness: let a meta-agent see all historical experience, and it decides what to change next, gradually improving the harness. · autoresearch (karpathy): give the agent a code repository, and it proposes ideas, changes code, and runs experiments on its own; if the metric improves, keep it, if it worsens, roll back, and record the results. The lecture notes also cite a Cerebras article on "how to prevent this kind of loop from cheating." · The lecture notes' summary: agents are already decent optimizers, so evaluation metrics have become the part that most needs to be controlled.

Selection Recommendations

When context optimization is suitable · Strong models that can only be called via API and cannot be fine-tuned. · When frequent, rapid re-optimization is needed. · When environment interaction is costly and samples must be conserved.

When weight optimization is suitable · When context optimization does not work, especially for small models with weak instruction-following ability. · When you have a strong teacher model and want to switch to a cheaper model. · When the prompt has already grown too long. · Weight optimization is more data-hungry, but it can keep improving with thousands or tens of thousands of samples (OpenThoughts-Agent).

Using them in combination: BetterTogether points out that sometimes the best order is to optimize the prompt first, then optimize the weights, and finally go back and optimize the prompt once more.

Source

Shao Meng