LLMs for Builders：用工程化思维构建可靠智能体应用-北京尧图网络

过去一个月我把某名校那套公开课里的“LLMs for Builders”系列反复刷了两遍重点是第二讲。标题翻译过来很直白——给智能体构建者的语言模型课。市面上讲大模型的课程大多分成两类一类从Transformer原理讲到微调对齐听完依然不知道怎么做一个带工具的Agent另一类是纯Prompt技巧分享看了不少但落不了地。这门课走的是完全不同的路线它默认你已经知道语言模型是“能用的材料”课程的全部精力都放在帮你搞清楚怎么用这些材料搭出真正跑得起来的智能体应用。如果你正在做AI应用、自动化流程、内部工具或者任何需要让模型“干正事”的系统这一讲很值得花时间细看。1. 这门课的核心思路Builders要用工程视角看LLM而不是研究视角1.1 课程定位不是给算法专家的是给应用层工程师的“Builders”这个词在英文里比“开发者”更强调建设者。课程反复传递一个观点大多数主流模型已经足够聪明你不需要去训练一个私有模型也不需要微调一个七B模型来解决业务问题。真正决定项目成败的是你能不能在模型外面设计一套工程体系把它的能力约束在可预测的范围里。这和很多人在转型做AI应用时的误区刚好相反。我见过不少项目组一遇到效果不好第一反应就是“我们要微调一个模型”。结果花掉两周做数据、训练、评估最后发现真正的问题只是上下文里没有给模型足够的工具定义或者输出格式的约束写错了。这门课等于直接把注意力拉回正确的层级模型是现成的计算资源你的活是把任务结构化把信息传递路径设计好把失败模式兜住。第二讲特别强调一个点不要把语言模型当成“会思考的魔法”要把它当成“一个能力很强但偶尔不靠谱的组件”。课程里所有的代码示例都体现这种工程化态度——每次都校验输出、每次都设置重试、每轮循环都有预算上限。1.2 整讲的主线逻辑从一次调用递进到一套系统我不剧透课程的全部内容但可以按我自己的理解把第二讲的推进逻辑梳理成四条线。第一条线是单体调用怎么把任务写清楚让模型第一次输出就尽量可用。第二条线是输出工程让模型输出结构化数据而不是一段自然语言这是接入代码的关键。第三条线是工具调用让模型可以查询数据库、调外部API、搜索文件这等于给模型安上了手和眼睛。第四条线是Agent循环把多次调用组合起来加上记忆、任务分解和异常恢复变成一个能持续完成目标的系统。这种演进逻辑非常符合Builders的脑回路。你不是一上来就被要求搭建一个万能Agent而是从一次最简单的文本生成开始一步步往上面加约束、加状态、加工具。每一层解决一类确定的问题整个系统因此变得可控。2. 把语言模型当“材料”来用首先要理解它的脾性2.1 上下文窗口不是越大越好而是越精越好课程第一部分的实操重点落在了上下文管理上。现在主流模型的上下文窗口动辄几十万甚至上百万Token很多初学者会本能地觉得“既然能放这么多那我就把所有资料全塞进去”。这门课用一个相当反直觉的案例说明上下文塞得太满反而会让模型的回答质量下降。我在自己的一个内部测试Demo里也复现过这个问题。当时我做一个文档问答Agent把一份两百页的产品手册全部放进上下文然后问模型某个具体配置项的含义。结果模型给出的答案居然把不同章节的参数混在一起理由很让人崩溃模型确实“看到”了所有内容但它很难在海量信息里稳定定位到最关键的那一段。课程给的管理思路很实用先做检索再生成只把相关的几个片段放进上下文。即便上下文窗口足够大也应该模拟“人类查资料”的方式——先看目录再翻到对应页而不是整本书摆在面前。这个原则对于Agent系统尤其重要因为Agent往往要进行多轮调用如果每一轮都把无关历史塞进去费用和延迟都会失控。围绕上下文管理我自己补充了三个经常被忽略的小习惯尽量压缩对话历史。保存重要的结论、用户意图和未完成事项而不是把每轮原始消息都发给模型。工具返回结果要按需截断。查询一个表有五十行模型其实只需要前五行和统计摘要完整数据往往没有价值。主动设置“注意力锚点”。在上下文里用明确的标记提示模型关注哪一段比如“以下是用户当前的核心需求其余只是背景信息”。2.2 输出结构让模型配合代码而不是人肉解析模型的回答Builder和普通聊天用户最大的区别在于用户能接受模型说一长段话但程序不能。你让模型返回一个JSON用于前端展示结果它多打了几行markdown标记解析就崩了。第二讲花了不小篇幅讲结构化输出并且给出了一个很务实的建议能约束的尽量用底层约束不要靠提示词碰运气。当前主流模型大多支持JSON模式或者结构化输出你提前声明输出的字段名、类型和枚举值模型会在解码阶段把输出限制在符合Schema的范围内。课程里也提到不要自己写正则去解析模型输出。正则擅长处理格式统一的内容但语言模型输出天然漂移今天给你标准JSON明天可能多一个逗号或少一个引号。正确做法是让模型输出JSON格式然后调用解析器如果解析失败就触发重试而不是硬着头皮去修字符串。为了把这块讲透课程里的示例涉及一个非常常见的场景让模型从一段用户的自然语言里提取订单信息包括订单号、商品列表、数量、收货地址。如果你只写“请提取出信息”模型会给你一份组织得很自然的文本。但如果你给出一个JSON Schema明确要求address必须是字符串、items必须是数组模型就会老老实实给结构化结果。这个差别直接影响后续代码的复杂度。关于结构约束我自己有一个经验值得分享在Prompt里给出示例往往比描述规范更有效。比如要求模型返回状态字段与其说“status只能是pending、paid、cancelled”不如直接给出几个输入输出对举例。模型可以通过少量示例快速理解模式这正是它相比传统规则引擎的优势。但也要注意示例不能太少否则模型会模仿你的语法而忽略约束。2.3 工具调用给模型装上手和眼纯靠模型内部的知识它能做的事情非常有限。第二讲的核心部分之一就是工具调用或者说Function Calling。这是Agent能够落地最关键的一步。课程把工具调用拆成三层注册工具、模型选择工具、执行工具后把结果回填给模型继续推理。注册工具这一层看似简单但坑不少。工具的描述写得过于简略模型就不知道该在什么时候调用它参数写得不够精确模型就会传错值。课程建议把工具描述当成API文档来写说明工具的作用注明参数格式最好附上一个典型使用示例。我在实际项目里遇到过模型反复调用一个“查询库存”工具但参数一直是空字符串的情况。后来检查工具定义才发现描述里没有写清楚参数应该来自用户消息还是来自上下文中某个实体模型就只能瞎猜。工具选择这一层更加微妙。当一个系统里同时有十几个工具时模型需要判断当前该调哪个。课程里给出的经验是尽量让一个工具做一件清晰的事不要做一个大而全的工具然后靠参数区分模式。比如“查询订单”和“创建订单”是应该分开注册的而不是用一个“订单操作”工具传入action参数。模型模糊匹配的粒度是工具名和描述拆开之后选择率会稳定很多。执行完了之后还要把结果回填给模型。这一步容易被忽略导致Agent变成一条路走到黑。课程里强调工具调用返回值不能只是原始数据最好附带一行简短的分析比如“这是订单状态用户要求加急请判断下一步动作”。这样做能显著减少下一轮推理的歧义因为这相当于给模型提供了经过加工的中间信息。3. 从单次调用到智能体循环正式开始搭Agent3.1 最小可运行的Agent循环观察、思考、行动、观察第二讲讲Agent的部分对我启发最大。很多人的认知停在“把Prompt写复杂一点就能得到Agent”但课程展示的是一个非常工程化的循环结构系统先接收用户请求把它们格式化成当前任务模型基于已有上下文决定是直接回答还是调用工具如果调用工具程序负责执行把结果作为新消息追加到上下文然后回到模型重复这个过程直到达到终止条件或者超出预算。这个循环看起来简单但它是所有Agent产品的地基。我在自己的Demo项目里按这个模式搭过最小复现伪代码大概是这个样子def run_agent(initial_task, tools, max_steps8): messages [system_prompt, initial_task] for step in range(max_steps): response llm.chat_with_tools(messages, tools) if response.tool_calls: for call in response.tool_calls: result execute_tool(call.name, call.arguments) messages.append(tool_result(call.id, result)) else: return response.message raise AgentTimeout(达到最大步数强制结束)你看这个循环本身不复杂。复杂的在于每一步都要处理边界情况模型连续调用同一个工具不推进、模型生成了不存在的工具名、工具执行报错后模型陷入慌乱、多轮调用后上下文越来越长。这些问题在课程里被提出来但答案往往只有一个原则让每一步都尽量简单并且做好失败兜底。3.2 我复现课程Demo时的实测体会记忆不是无限聊天记录课程里对Agent记忆的处理很务实。它没有把记忆理解成“把历史全部堆进上下文”而是分成了三类短期记忆是当前任务相关的对话上下文工作记忆是任务过程中提取出的关键信息比如用户偏好、中间结果长期记忆是存储在外部数据库里的知识比如历史偏好和项目总结。这个分类让我重新审视自己做过的系统。之前我搭的Agent几乎只靠短期记忆结果它经常忘记用户五分钟前说的关键要求。课程的做法是设立一个“状态对象”每次循环结束时把当前最重要的结论显式写入一个结构化字段比如“用户地址已确认广州市某路某号”“当前订单待支付”然后把这些结构化字段带进下一轮。相当于给Agent配了一张工作便签而不是让它全靠对话流来回忆。在实测过程中我发现还有一个很关键的点Agent不应该等上下文满了才去整理记忆而应该在每轮结束后就主动压缩信息。你可以先让模型总结当前进度丢弃细节只保留关键状态。这个操作看起来每轮要多花一次调用但后续轮的准确率和延迟表现都会更好。一味堆上下文Agent会越来越慢也越来越容易出错。3.3 智能体设计检查清单照着抄就能少走弯路课程并没有给出一张静态的清单但综合整讲内容我整理出一份自认为很实用的Checklist。每一条背后都有我踩过的对应坑定义明确的终止条件。不要让Agent自己决定“我该停了”程序要在循环层设好最大步数、最大成本、超时时间。工具定义要极小且语义清晰。宁可多注册三个工具也不要让模型去猜一个复杂工具的用法。每一轮模型调用前都要校验上下文大小。否则跑到第五轮时上下文可能已经塞进了几万Token。对模型输出要做防御性解析。JSON解析失败就重试或换模型不要尝试修复。多工具并发时要注意依赖关系。有的工具必须在前一个结果返回后才能调用。要有用户确认机制。关键操作比如下单、删除、付款无论如何都不能让Agent自动完成这是生产级应用的底线。4. Builder最容易踩的坑这节课帮我们提前排雷了4.1 上下文塞太满模型反而“变傻”这个坑在2.1里提到过但值得单拎出来再强调一次。第二讲里有一张对比实验的截图让我印象很深同一个数学推理题只给相关例子的模型回答正确把全部材料都塞进去之后反而答错。课程的解释是模型需要从大量无关内容里定位关键信息这个过程会消耗它的“注意力预算”一旦预算被无关内容占满精度就会下滑。这个现象其实和人类注意力机制很像。你在一张堆满杂物的桌子上找钥匙比在只有几本书的桌面上找要慢得多。Agent系统也是同样的逻辑。每次调用模型之前都应该问问自己当前这轮任务真正需要的上下文是哪些检索出来的那些长篇文档如果和任务没有直接关系就不应该出现在Prompt里。我还见过一种做法为了“保险”把工具返回的完整JSON原封不动放进上下文。这非常浪费。更好的做法是让工具返回层先做摘要只保留模型决策需要的关键字段甚至在工具内部完成聚合。这不仅是省钱的问题更是准确率的问题。4.2 结构化输出不稳定解析失败时先检查Prompt而不是代码很多人遇到模型输出不满足JSON格式时第一反应是去加强解析逻辑。这其实是方向错了。解析逻辑再强也扛不住模型输出的千变万化。课程里给出的正确路线是先看使用的模型是否支持强制JSON如果支持就用JSON模式如果不支持就要在Prompt里给出非常严格的格式约束和示例并且在代码里捕获解析异常自动重试一次或两次。我在一个Demo里测试过给模型一个明确的JSON Schema后输出崩溃率直接从百分之十几降到了百分之一以下。这个改善没有改任何后处理代码只是把约束加在了模型输出层。这和数据库约束是一个道理不能靠应用层代码去弥补数据层的混乱要把规范前移。另外要留意多模型兼容问题。国内和一些开源的模型不一定支持官方的Function Calling格式但几乎都支持让你在Prompt里描述工具格式并由模型输出工具调用。对于这类模型课程建议把工具调用也看作一种结构化输出只是它的Schema更复杂。哪怕没有系统级保障只要Prompt约束够严格再用解析校验兜底依然能稳定复用同一套Agent框架。4.3 Agent陷入循环或幻觉问题往往出在反馈信号太弱Agent最常见的失控表现是反复调用同一个工具或者当工具返回错误时编造一个看起来合理的解释。课程里点出一个关键Agent缺少足够的反馈信号去修正自己的行为。如果工具返回空结果系统直接把这个空结果塞给模型模型可能会认为查询成功只是没有数据然后告诉你“没有找到订单”。但真实原因可能是参数传错了。解决办法是在工具结果里加上执行状态和错误信息。比如工具返回的不是单纯的“[]”而是“查询失败缺少订单号参数这是原始异常信息”。这样模型就能理解下一步应该补充什么信息而不是顺着错误的思路继续推理。我自己的项目里曾经遇到一个更隐蔽的问题Agent卡在一个工具调用链里反复执行每轮都消耗Token但任务没有任何进展。后来加了日志才发现某一步工具返回的结果格式里混入了一段没有被捕获的异常信息模型一直以为调用失败于是不断重试同一个动作。这个教训告诉我在Agent循环里日志和可观测性不是可有可无的装饰而是调试复杂系统时唯一的线索来源。4.4 成本与延迟问题没有预算上限的Agent一定会出大事课程里关于成本的部分写得相当坦诚。它给了一个估算案例假设一次Agent任务平均执行5轮每轮发送3000Token给模型接收1000Token那么一次任务可能消耗2万Token。如果一天跑一万次任务那就是两亿Token的消耗。很多团队在Demo阶段感觉不到成本因为调用量小一旦上了生产账单会让你重新审视每一轮Prompt到底塞了什么。有效的成本控制手段包括第一优先使用更小的模型处理简单步骤第二对Agent的每一步设置轮数上限动态终止第三对工具返回结果做缓存第四把“总结上下文”也做成一个可配置的步骤不要每次都让主模型做最重的计算。延迟也是一个类似的问题。每多一轮调用用户等待时间可能增加两三秒。如果Agent需要三步才能完成一个简单任务产品体验就会显得笨重。课程里的建议是把可以并行执行的工具调用放到同一轮里。比如你需要同时查天气和查航班就让模型在一条消息里发出两个工具调用程序并行执行后再统一返回给模型能省掉一次完整的模型往返。5. 课后落地建议怎么把这一讲变成你自己的生产力5.1 先做一个带工具调用的单轮应用再谈Agent课程的内容密度很高但我不建议你看完就急着去搭一个全自动Agent。我自己的落地路径是分三步走的。第一步选一个非常窄的场景比如“根据用户输入的股票代码查询最新行情”把工具定义、结构化输出和错误重试都跑通。这一步看起来简单但足够覆盖大量工程细节。第二步在这条链路上加入多轮对话让系统能够记住用户刚才提到的股票代码形成简单的上下文交互。第三步再加入循环和对工具的自主选择让它自动完成“查行情、对比涨幅、给出投资建议”这样一个多动作任务。越到后面越会发现前面两步打下的基础越牢第三步越不容易翻车。很多人跳过基础直接搭Agent最后做的其实只是很多次Prompt的堆叠并没有真正处理好工程边界问题。5.2 建立最小回归集让人工评估跟上第二个建议是给Agent项目建一个不超过二十条的回归测试集。测试集里应当包含正常请求、模糊请求、空输入、含错别字的输入以及需要多轮追问才能完成的场景。每改一次System Prompt或者工具定义就把这二十条从头跑一遍人工观察输出。有了这个回归集你可以很快发现某个改动虽然优化了一类问题但让另一类问题变差了。课程没有详细展开这个部分但我觉得它是从Demo走向生产最重要的环节。大模型应用和传统软件不一样你很难用单测来保证行为但你可以用固定的输入和人工评估来保证它的行为不会明显漂移。我自己维护的最小回归集现在有六十条每次发布新版本前跑一遍心里就有底很多。5.3 从玩具到生产至少补上缓存、日志和审批课程最后有一段很实在的提醒不要把一个只会在本地跑通的Agent直接搬到生产环境。生产环境至少需要三样东西缓存、日志、人工审批。缓存能大幅降低成本日志能让你在Agent出错时还原完整推理过程人工审批则是最后的安全网。尤其当Agent涉及写操作时一定要设计确认环节不要让模型直接执行“删除”“转账”这类动作。我在一个模拟项目X里试过把这三样东西都补到Agent循环里运行稳定性有了质的提升。补日志之前出了问题只能瞎猜补上日志之后每一步的工具调用、模型回复、Token消耗都有据可查。缓存则让同一类重复查询基本不再调用模型成本直接降了一个量级。最后说一个被课程点到但容易被忽略的小技巧在课程里有一个很不起眼的细节给模型每一步的推理设置一个“暂停确认点”。也就是说当模型准备执行一个关键动作之前系统先暂停把“我打算这样做”的说明返回给用户确认。这个机制看起来降低了自动化程度但在真实业务里它反而让用户对系统更有信任感也让Agent不会在错误的判断上越走越远。我后来的项目里把这种确认点用在了所有“会产生外部影响”的动作上比如发消息、改配置、提交订单。效果非常明显——系统的可接受度提高了出问题的概率也大幅下降。这一讲虽然叫LLMs for Builders但真正的核心其实是在教你如何用工程纪律驾驭一个不太稳定的组件。把这些纪律内化成自己的开发习惯比记住任何一条Prompt技巧都值钱。

LLMs for Builders：用工程化思维构建可靠智能体应用

相关推荐

信创终端系统选型：银河麒麟与鸿蒙场景化决策指南

VS Code调试PyTorch源码：Python+C+++CUDA联合调试实战指南

逆向工程实战：从字符串定位到注册机编写

更多资讯

非合作博弈下的居民负荷分层调度与双层鲸鱼算法求解

数控加工仿真软件3.7实战指南：刀路验证与避坑技巧

上位机与汇川PLC的Modbus TCP通讯：视觉结果回写与联调避坑指南

大年初七晨听歌：一小时的选曲逻辑与实操记录

多厂商网络设备登录配置全解析：Console、Telnet、SSH与Web实战

别再背Docker命令了：从镜像到Compose的实战心法

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？