企业官网建设流程全解析

搭建过几个智能体项目之后，再回头看斯坦福CS329Z这门课，感受完全不同了。这门课名字里的"Z"很有意思，取自"Zero"的意思，瞄准的正是"从零开始构建"的真实场景。第二讲标题叫"LLMs for Builders"，翻译过来就是"给智能体构建者的语言模型课"，核心词有两个：LLMs和Builders。Builders不是算法研究员，不是发paper的学者，而是像我这样要把模型做成产品、做成工具、做成能跑的业务系统的人。这门课没有停留在Transformer结构怎么训练、注意力机制怎么算这种底层推导上，而是把大模型当成一块可以调用的组件，重点讲清楚它的能力边界、调用方式和工程模式——这恰恰是市面上海量教程最薄弱的环节。

我见过太多人一上来就问"哪个框架好用""Agent怎么写"，却连LLM的温度参数、上下文窗口、工具调用格式都没搞明白，最后项目翻车的原因往往不是框架问题，而是对模型本身理解不足。CS329Z第二讲最值得学习的，就是它把"模型能力"和"构建者需求"之间的映射关系讲透了。这篇文章我会顺着这门课的核心思路，结合我自己跑通智能体的实战经验，把LLM在智能体构建中的底层逻辑、关键模式、实操细节和踩坑记录完整拆开来讲。

1. 这堂课到底在讲什么：一门"面向构建者"的LLM课信息量有多足

1.1 换个视角看大模型：Builders 和 Researchers 关注点完全不同

先说一个我自己的观察。传统的大模型课程，主线通常是：词嵌入、Transformer、预训练、微调、对齐。这套知识很系统，但对做产品的人来说有个致命问题——你学完可能还是不知道怎么把一个模型接进业务流程里。CS329Z的定位完全反过来，它默认你不需要自己训练模型，而是把模型当作一个"外包的智能引擎"来使用。Builders关心的问题非常实际：这个模型能干什么、不能干什么、怎么让它按我的要求干活、干砸了怎么处理、成本怎么控制、延迟怎么优化。

这就引出了第二讲的核心命题：LLMs for Builders，核心不是模型内部的数学原理，而是模型的输入输出接口、推理能力边界、以及围绕这些边界做工程适配的方法。一个合格的智能体构建者，不需要会手写反向传播，但必须清楚temperature=0.7和temperature=0.1对代码生成任务的影响差别，必须知道上下文窗口满的时候模型会"失忆"到多离谱，必须明白工具调用不是模型原生具备的，而是需要通过特定格式训练出来的能力。

1.2 CS329Z第二讲的内容主线：从能力到工程的三层递进

如果给第二讲的内容画个简化结构，大致是三层递进：第一层讲LLM的基础能力，包括文本生成、指令跟随、上下文学习；第二层讲构建智能体需要的扩展能力，比如思维链、工具调用、多模态理解；第三层讲把这些能力落地到真实应用时的方法论，比如提示工程、工作流编排、评测机制。

这套结构最打动我的地方，在于它不是把LLM当作一个"黑盒"来糊弄你，也不是掉进"白盒"的技术细节出不来的学院派路线。它给的是一个"灰盒"视角——你不需要知道内部权重怎么算，但你得知道模型在什么条件下表现好、什么条件下表现差，然后在外部系统里想办法扬长避短。比如模型容易在长对话中忘记早期指令，那就把关键约束塞进System Prompt或者定期重写上下文；模型会一本正经地编造工具调用结果，那就加一层结果校验器。这些都属于典型的外部工程补偿手段。

2. 为什么智能体构建者必须先吃透LLM：核心能力与边界决定系统设计

2.1 三种核心能力拆解：生成、推理、上下文学习

先聊聊LLM在智能体场景中最常用的三种核心能力，这也是CS329Z第二讲花了不少篇幅夯实的地方。

第一种是生成能力。这个好理解，你给它一段话，它还你一段话。但注意，生成能力在智能体里不只是"聊天"这么简单，它要承担的是"生成结构化输出"的工作。一个Agent需要从用户需求中抽取参数，需要生成调用外部工具时遵循的JSON结构，需要写出符合语法的代码片段，这些都是生成能力的变形应用。如果你的提示词没有限定输出格式，模型就会给你自由发挥——自由发挥在智能体系统里意味着解析失败、程序崩溃。

第二种是推理能力。这里说的推理不是逻辑学意义上的严格推理，而是模型通过思维链方式做分步思考的能力。智能体最常见的ReAct模式，本质上就是利用推理能力来规划行动步骤：先理解当前状态，想清楚下一步该调什么工具，然后看工具返回结果，再想下一步。我在实际使用中明显感觉到，同样的工具，直接让模型一次性回答容易出错，但如果引导它"先分析用户意图，再列出可能需要的工具，最后按优先级调用"，成功率能上一个台阶。

第三种是上下文学习能力（In-Context Learning）。这是构建者们最该好好利用的特性：你不用为了一个新任务重新训练模型，只要在提示里给出几个例子（Few-shot示例），模型就能模仿你的示例格式完成任务。这个特性是提示工程的立足之本。你在设置里塞入几个"用户问什么、Agent应调什么工具、返回什么格式"的样例，模型就能比你不放样例时稳定得多。代价也很清楚：示例会消耗Token，上下文窗口是有限的。

从工程角度看，这三种能力组合起来，就决定了智能体的基本运作单元。模型先理解指令，再规划动作，最后生成调用文本，这个环节每轮都要消耗若干次大模型请求。明白了这一点，你就知道为什么智能体项目比普通聊天机器人的成本高——不是模型定价高，而是你每完成一个用户任务，背后可能是三到五次模型调用。

2.2 能力边界必须心里有数：幻觉、长度、成本、延迟

如果说能力是"天花板"，边界就是"地基"，地基不稳，天花板再高也白搭。

先说幻觉。模型生成的文本即使完全不符合事实，也会以非常笃定的语气说出来。在智能体场景里，幻觉尤其危险：Agent可能基于幻觉的结果决定下一步行动，然后整个任务链跑偏。我的经验是，永远不要用模型直接返回的自由文本作为任务完成的判定依据，关键结果必须做二次校验。比如让Agent从文档里提取数据并填写表单，一定要加一层Schema校验，字段类型不对就重试，而不是直接入库。

再说上下文长度。很多人以为上下文窗口越大越好，其实这里有个陷阱：模型对中间位置的"记忆"弱于开头和结尾，这就是所谓"lost in the middle"现象。一个十六万窗口的模型，不等于它能充分理解十六万Token的所有信息。智能体做多轮对话时，历史越长，模型越容易忽略早期指令。所以，不是把所有历史都堆进去就完事，你需要设计摘要机制、裁剪策略、关键信息抽取。

然后是成本和延迟。这里可以用一句话概括：大模型不会因为你的业务很小就便宜，它的每一次调用都要真金白银和时间。构建智能体时，每增加一层中间调用，成本都可能是成倍增长。我做过一个粗糙的测算，一个简单的"查文档并摘要"功能，如果一次任务需要思考、检索、生成三步，那么单次成本就是从模型调用费的三倍，延迟也从300毫秒变成1秒以上。真实工程必须对"每一步是否必要"做极致的审视。

2.3 生活化类比：把LLM理解成一个能力很强但容易忘记指令的外包员工

有个类比我觉得特别适合讲给团队新同学听：LLM就像一位能力很强、知识面很广，但全靠你给的"当日安排"来工作的外包员工。你给他写清今天的任务清单（System Prompt），给他几份参考样例（Few-shot示例），他会很卖力地干活，也能超预期地发挥。但他有几个毛病：记性不好，干到一半就忘掉开始时你交代的关键约束，所以你得把重要事项写在一张永不拿走的便签上也就是System Prompt；他想象力太强，遇到不确定的事他会脑补细节还给你说得跟真的一样，这就是幻觉，所以每个交付给他成果你都得找人复核；他的精力有限，一天只能处理一万字的活，超出范围就开始胡言乱语，这是上下文溢出。

你别指望靠"口头叮嘱"克服这些毛病，正确做法是设计一套流程来管理他：重要的事情反复在便签上写明，交付物带检查清单，每完成一个阶段就让他确认一下进展。这套流程落到代码里，就是记忆管理、输出校验、状态跟踪。理解了这个人格模型，你再看智能体的各种设计模式，思路会一下子清晰很多。

3. 核心工程模式拆解：ReAct、工具调用与记忆管理

3.1 ReAct模式：给模型装上"思考-行动-观察"的闭环

CS329Z第二讲如果让你带走一个关键词，我猜就是ReAct。ReAct是Reasoning + Acting的缩写，思路极简：模型每一轮不是直接给出最终回答，而是先输出"思考"（Thought），再输出"行动"（Action，通常是调用某个工具），然后基于工具返回的"观察"（Observation）继续思考，直到它认为答案足够完整，输出"最终回答"（Final Answer）。

为什么要这样设计？因为直接把用户问题扔给模型让它回答，模型只能依赖参数记忆中存储的静态知识，遇到需要实时信息、计算能力或专有数据库的场景就束手无策。而一旦模型能够动态调用外部工具，它的能力边界就从"记住的文本"扩展到"整个世界"。我在项目里最常用的一个工具是"文档搜索"，Agent收到用户问题时，先向量化检索相关文档片段，再把片段和问题一起交给模型推理。没有ReAct闭环的普通问答，答案完全靠模型记忆瞎编；有了搜索增强，答案质量立刻就不一样了。

实现ReAct有一个必须注意的细节：思考、行动、观察这三个字段的格式必须稳定。实战中有两种做法：一种是让模型输出纯文本格式，然后在代码里用正则解析Thought/Action字段；另一种是用工具调用（Function Calling）机制，让模型直接输出结构化的函数名加参数。我个人在复杂场景中更推荐后者，因为解析稳定性高得多。用文本格式的时候，模型偶尔会冒出"Thought: 嗯我觉得""Action: 调用搜索工具吧"这种不规范的表达，解析代码一崩，整个循环就断在中间。

3.2 工具调用：模型如何把"想法"变成"动作"

工具调用是智能体区别于普通聊天机器人最关键的机制。它本质上是把"外部系统的API"以"函数说明"的形式注入模型能理解的格式，模型根据用户指令和当前对话状态，从候选函数列表中选择合适的函数并给出参数。

这里有个新手最容易踩的坑：在本地代码里定义一个Python函数，然后在配置里把这个函数注册给模型，模型就能直接运行它了？没那么简单。模型不执行你的代码，它只是输出一个包含函数名和参数的JSON。真正执行这个函数的是你的应用系统：你拿到JSON后校验参数，调用本地函数，把返回值再次送回给模型。这个链路一旦断裂，常见表现就是"模型说调用成功了但系统里根本没有动作发生"。

工具说明怎么写也有讲究。一个包含名称、描述、参数Schema的函数说明，本质上是一种特殊的提示词，模型会依据描述判断"这个工具是干什么的、合适不合适调用"。所以工具描述要写清楚使用时机，比如一个"search_products"函数，描述写成"当用户询问商品信息时使用此函数查询商品列表，参数keyword用于匹配商品名称"，就比单纯写"商品搜索"效果好得多。原因是模型的规划能力很大程度依赖于它读到的功能描述，描述越精确，选择工具的错误率越低。

3.3 记忆管理：短期记忆、长期记忆和上下文的斗争

记忆是智能体构建中最容易被低估的模块。很多智能体Demo跑起来很惊艳，但一旦做多轮对话就露馅：用户上一轮说"帮我查上海的天气"，下一轮问"那深圳呢"，Agent直接懵了，因为它根本没有记住"查天气"这个上下文动作。

在工程层面，记忆大致分三类。第一类是短期记忆，也就是模型上下文窗口里的内容，直接拼进Prompt。它的优点是直接，缺点是窗口有限、成本高，需要做管理；第二类是长期记忆，通常用向量数据库保存历史对话或用户偏好的Embedding，在需要时通过检索把相关内容拉回上下文；第三类是工作记忆，也就是Agent当前任务执行到哪一步的状态记录，这通常不放在模型上下文里，而是放在应用系统的数据结构里，只在需要决策时才让模型读取。

记忆管理的核心矛盾是：你希望模型记得尽量多，但上下文一长，模型的速度、准确率和成本都会恶化。折中方案很常见：每一轮对话结束，用另一个模型调用把对话内容压缩成摘要；用户再次提问时，把摘要和最近几轮原始对话一起交给主模型。这个方案我实测下来效果不错，代价是多一次摘要模型的调用成本，但模型在大段历史中的"失忆"问题明显缓解了。

4. 实操路径：从零搭一个最小可用智能体框架

4.1 技术选型：直接手写调用还是上框架

聊到实操，很多人的第一个问题就是"要不要用LangChain/LangGraph、Dify、Coze这些框架"。我的建议是：先手写一个最简单的循环，再决定要不要引入框架。为什么？因为框架的核心价值在于帮你封装了模型调用的循环、解析和工具路由，但代价是抽象层带来的"黑盒感"——出了Bug你找不到根因。

这里有个行业里一直在聊的话题：用平台搭建的智能体（比如Coze、Dify）和用Python自己搭建的智能体到底有什么不一样？我两种都做过，体会很直接：平台型方案上限低但起步快，拖拽节点就能做出一个能对话、能查工具的Bot，适合快速验证产品想法；但到后期你会发现控制力不够，比如你想在某个工具返回结果后插入一段自定义的数据清洗逻辑，平台不一定给你这个口子，或者你得用它的自定义代码节点做"曲线救国"。Python方案正好反过来，起步慢但处处可控，所有链路都是自己写的，任何环节都能插日志、加校验、做兜底。面向多轮复杂任务的生产级智能体，我倾向于Python方案；面向快速给业务方演示POC，平台方案效率高得多。

4.2 一个最小可用的ReAct循环代码骨架

下面给一个结构极简的Python实现骨架，目的是演示ReAct闭环的核心逻辑，不依赖任何第三方Agent框架。你可以把这个骨架当作"最小可运行底座"，逐步往上加记忆、工具、评测。

import json # 假设这是从某个LLM供应商处获取的对话完成接口 def call_llm(messages, tools=None, temperature=0.2): # 这里应该替换成真实API调用 # 返回 {"content": "字符串", "tool_calls": [{"name": "func", "arguments": {...}}]} ... def run_agent(user_query, tools): messages = [ { "role": "system", "content": ( "你是一个智能体。你需要根据用户问题，使用可用的工具来完成目标。" "当你不确定是否完成目标时，不要编造结果。" "当工具调用完成后，基于观察结果给用户最终答复。" ) }, {"role": "user", "content": user_query} ] max_rounds = 5 # 防止无限循环 for _ in range(max_rounds): response = call_llm(messages, tools=tools) if response.get("tool_calls"): # 把模型的思考与工具调用追加为 assistant 消息 messages.append({ "role": "assistant", "content": response.get("content", ""), "tool_calls": response["tool_calls"] }) for call in response["tool_calls"]: name = call["name"] args = call.get("arguments", {}) # 执行本地函数 if name in tools: try: result = tools[name](**args) # 工具返回结果追加为 tool 消息 messages.append({ "role": "tool", "tool_call_id": call.get("id"), "content": json.dumps(result, ensure_ascii=False) }) except Exception as e: messages.append({ "role": "tool", "tool_call_id": call.get("id"), "content": json.dumps({"error": str(e)}, ensure_ascii=False) }) else: messages.append({ "role": "tool", "tool_call_id": call.get("id"), "content": json.dumps({"error": "未找到该工具"}, ensure_ascii=False) }) else: # 没有新的工具调用，说明模型已经给出最终回答 return response.get("content", "") return "达到最大轮数，任务尚未结束。" # 示例工具：查询商品库存 def query_stock(product_id: str): stock_map = {"A100": 42, "B200": 7} return {"product_id": product_id, "stock": stock_map.get(product_id, 0)} if __name__ == "__main__": print(run_agent("A100还有库存吗", {"query_stock": query_stock}))

这个骨架虽然只有几十行，但已经包含了一个智能体闭环的七个关键环节：系统指令注入、用户请求接收、模型推理与工具调用决策、工具执行、结果回传、继续推理、终止条件。真实生产环境里，你需要在这个骨架上补的东西，我下面逐一说明。

第一处是日志。每一轮的Thought、Action、Observation都要落日志，否则出问题以后你完全回溯不出Agent当时的决策路径。第二处是超时和重试。调用外部API时不可避免会遇到网络波动，工具本身的执行也可以设置超时时间，避免一个慢接口卡死整个循环。第三处是安全控制。工具集合不能无限大，尤其不能暴露会修改关键数据的工具给不可信用户，要加权限分层。第四处是成本上限。每次运行记录Token消耗，一旦超过预设额度立即终止任务。

4.3 参数与配置细节：别小看temperature、max_tokens和top_p

很多人调模型API时，参数都是拿默认值一路用到底，这在智能体场景里是要吃亏的。最基本的三个参数，每个都有讲究：temperature控制随机性，数值越高输出越发散，反之越低越趋于确定性；top_p控制核采样，按概率累计截断候选词，一般和temperature二选一来调即可；max_tokens控制最大输出长度，它不够的话模型会在输出中途被强制截断，导致JSON不完整、代码语法错误。

我的经验是：涉及工具调用的Agent核心循环，temperature设低一点，0.2到0.3之间比较稳妥。为什么？因为工具选择是"决策任务"，你需要的是稳定和正确，不是创意。如果temperature太高，模型可能反复在两个工具之间摇摆，或者生成一些格式不规范的参数值。但如果是面向用户的文案生成环节，可以单独把temperature调高到0.7甚至0.9，让回答更有"人味"。也就是说，同一个应用的不同环节，可以分别调用不同参数的模型配置，这就是"配置分离"的思路。

max_tokens这个参数尤其容易被忽略。Agent系统里模型不只是返回一句回答，还可能返回多步骤规划文本，如果你设的max_tokens太小，模型写到一半就被截断，你连解析都没法解析。反过来，max_tokens设得太大也有隐患，模型可能生成一堆无意义的填充内容来"撑满额度"。合理做法是先根据任务类型估一个量级。比如摘要任务256到512，代码生成1024，复杂规划2048。Moderate配置，然后看日志里有没有Truncated标记，有就往上涨。

4.4 评测回归：没有评测，就不可能有可靠Agent

框架跑通了、参数调完了，紧接着就是"评测"。我特别建议把评测当作智能体构建的一条独立流水线来做，而不是项目收尾时补一补。

一个很朴素的事实：智能体行为是概率性的，你今天调好的Prompt，明天换一个模型版本可能就翻车。没有自动化评测集，你根本不知道哪次改动是进步还是倒退。我维护了一个很小的评测集，大约50条任务，覆盖常见问题、边界问题、恶意输入、工具调用错误等场景，每次改动代码或调提示词之后，把这50条全部跑一遍，记录通过率。这个过程看着笨，但收益巨大——它能把"我觉得效果变好了"这种主观感觉，变成"通过率从82%提升到92%"这种客观指标。

评测集的构建不要只放"标准答案"。

因为开放生成任务没有唯一答案，我通常给每条评测写两个部分：一是任务描述，二是判定标准。判定标准可以写成规则，也可以写成由另一个模型扮演裁判。比如"任务：查询库存并给出明确结论；判定标准：回答中包含A100库存为42件这一数字，且没有编造额外商品信息"。规则化判定能过滤大部分回归问题，成本低、速度快。

5. 常见问题与排查技巧实录：从能跑通到真正可靠

5.1 幻觉与自主容错：Agent翻车现场和我的处理方案

先讲一个我亲历的翻车现场。某个内部知识问答的Agent接到用户提问"显卡驱动怎么安装"，它非常自信地输出了一大段安装命令，并且以"我刚才查到官方文档说……"作为开场。问题在于，它压根没有调用文档检索工具，那段命令完全是参模型记忆里凭空拼凑的。结果用户照着执行，直接把系统环境搞挂了。诊断日志后我发现，模型在那一轮里根本没有触发任何工具调用，也就是说它"觉得"自己知道答案，就选择了直接作答。

从那以后我加了三条防线。第一，系统提示里明确强调"涉及具体操作、数字、命令、时效性信息时，必须调用相关工具获取依据后才能回答，禁止直接凭记忆作答"。这听起来像废话，但模型确实会更谨慎。第二，在后处理环节检测：对于判别为"高风险"的问题类别，如果最终回答里没有引用任何工具返回的数据，就强制让Agent重写一次，把它引到工具调用路径上。第三，针对工具返回的数值结果，在交给模型做最终回答之前做类型与范围校验，发现异常值就标记"该工具结果可疑，请重新确认"后再次追问。这套组合拳没法彻底消除幻觉，但能把幻觉扩散到行动层的概率压到很低。

5.2 上下文爆炸与指令遗忘的排查套路

多轮对话里最典型的问题是"聊到后面，Agent忘了最初的约束"。排查套路我总结为三步回溯法：先看当前轮次实际发送给模型的Prompt到底包含哪些内容，是不是把System Prompt挤掉了；再看历史消息是不是被无脑截断过，导致用户最初表达的核心需求被切走；最后看有没有哪一段系统提示在模型输出时被覆盖，比如工具返回的大段文本直接把上下文窗口塞爆了。

我踩过一个具体坑：用向量检索把"相关资料"塞进上下文后，整个上下文被大量文档片段占满。当时没有做优先级排序，导致用户最初的指令被挤到窗口中部，而"lost in the middle"问题立刻显现：模型开始无视用户指令，反而按照文档里的内容自由发挥。解决办法是重排上下文布局：System Prompt在前，用户的原始目标在中前部，检索文档片段放后面并做摘要压缩，保证关键指令永远靠近窗口前端。这个调整非常有效，几乎是立竿见影。

5.3 快问快答：智能体项目的五个高频困惑

整理几个我经常在合租讨论、社区交流里被问到的问题，直接给结论：

问题一：智能体框架到底选LangGraph还是Dify还是自己写？

先看你的核心诉求。要在生产环境深度定制链路、要跟现有Java/Go服务打通、要对过程的每一步做精细控制，选自己写或LangGraph这类代码型方案；时间紧急、偏交互式Demo、业务逻辑不复杂，Dify这类低代码平台效率更高。没有最优，只有匹配度。

问题二：多智能体协作是不是比单个大模型Agent更强？

不一定。多智能体的价值在于任务可以拆子并进、每个Agent可以用不同的Prompt和模型，但它也引入了通信开销、协调错误和更难的调试面。一个只能叫"工具增强Agent"，多个才叫"多智能体系统"。业务复杂度没到，不要为了概念而拆。

问题三：向量数据库是不是必须有？

大多数带长期记忆或知识库问题的Agent会用到。但如果你只用短期记忆、固定工具集，完全可以不接向量库。额外组件就是额外故障点，能不加就不加。

问题四：怎样评测一个Agent的"智能"程度？

不要用"感觉"。把任务拆成一连串原子子任务，逐个记录成功率和耗时，再统计整链路完成率。比我所说的50条评测集更细一点，你可以按任务类型分组，区分必须完成和尽力即可。

问题五：为什么我用Claude/GPT写代码效果很好，但做Agent就经常失灵？

因为写代码是"一次性生成"，Agent是"多轮决策"。多轮决策会累积错误，任何一步工具选错、参数传错、解析失败，整个任务都会崩。写代码只要单次输出好；Agent需要多次输出都稳定，这就对提示、工具定义、容错机制提出了完全不同的要求。这也是我反复强调评测和日志的原因。

写在最后：这门课值得反复回看的三个理由

如果你只从CS329Z第二讲带走一样东西，我希望是"把模型当作系统中的一个不可靠组件"这个意识。模型不是神，它非常强大，但会幻觉、会遗忘、会格式混乱、会偶尔漏调工具。一个优秀的Builders要做的，不是祈祷模型永不出错，而是设计一套系统，让模型犯错时不至于造成灾难。

老实说，很多教程都在教你怎么把模型用得更"花"，但CS329Z教的是怎么把模型用得"稳"。我个人体会最深的一点是：智能体开发的竞争力，不在于你掌握多少高深的算法理论，而在于你对模型行为细节的敏感度和围绕边界构建工程机制的熟练度。你会不会在模型输出乱码时冷静地补一层兜底解析？会不会在上下文快要溢出之前主动做一轮关键信息抽取？会不会把一次"看似成功"的回答拆解成指标来验证？这些才是决定一个Agent项目能不能从Demo走到生产环境的真正分水岭。

最后再分享一个小技巧：想跟紧这门课的节奏，最好的方式不是只看课程录屏，而是把每一讲的代码示例都跑一遍，然后故意"改坏"一处，观察系统怎么报错、在哪里崩溃。这样跑过三四个实验之后，你对智能体的整个生命周期会有一种非常具体的掌控感——这种掌控感，比读十篇综述都管用。