[{"data":1,"prerenderedAt":424},["ShallowReactive",2],{"article:column:/column/llm-to-agent-learning/35":3},{"id":4,"title":5,"body":6,"description":416,"extension":417,"meta":418,"navigation":419,"path":420,"seo":421,"stem":422,"__hash__":423},"column/column/llm-to-agent-learning/35.md","35｜评价整个系统：正确率、成本、延迟与失败恢复",{"type":7,"value":8,"toc":397},"minimark",[9,13,16,21,24,27,30,33,37,40,43,49,52,55,62,65,68,71,75,78,81,84,87,91,94,97,100,103,109,112,115,119,122,125,128,131,137,140,143,147,150,153,156,159,162,165,168,171,177,180,183,186,196,200,203,206,209,212,218,221,229,243,246,249,253,261,267,270,273,276,279,283,288,291,296,299,304,307,312,315,318,323,326,331,334,339,342,347,350,353,358,361,366,369,374,377,382,385,388,391,394],[10,11,12],"p",{},"一个助手说“活动信息已核对并更新”，最终页面却仍是旧地点。另一套助手没有漂亮的长回答，却给出新公告、修改后的页面和核验时间。哪一个真正完成了任务？",[10,14,15],{},"第23章讨论一个模型分数能支持什么结论。本章把被测对象扩大到整个系统：从用户提出目标，到资料获取、模型判断、工具执行和结果确认。模型答对，是其中一个环节；用户得到正确、及时且没有越权的结果，才是端到端评测关心的事情。",[17,18,20],"h2",{"id":19},"_1先定义任务的终点","1．先定义任务的终点",[10,22,23],{},"沿用前几章的海报核对任务。如果用户只要求检查，成功意味着四项信息均有适用证据，差异和无法确认项表达准确，且没有擅自修改。如果用户明确要求并授权修正地点，成功还要求目标页面确实改变，其他内容没有误改，并提供可核查回执。",[10,25,26],{},"同一句“已完成”，在这两个任务中需要不同证据。评测应在运行前写明输入、获准动作、终止条件与评分规则，不能运行后把“输出了文字”临时改成成功标准。",[10,28,29],{},"设N是进入评测的有效任务总数，S是满足预定全部要求的任务数。端到端成功率就是S/N。这里的斜线表示除法。分母不能只挑模型愿意回答、没有超时或成功走到最后的任务，否则困难任务会从账上消失。",[10,31,32],{},"受阻、取消、拒绝与失败也要按预先规则区分。面对未授权请求，正确拒绝可以是该安全测试的成功；面对本来可完成的正常请求，无理由拒绝则不是成功。测试目标不同，不能靠改标签把两者混为一谈。",[17,34,36],{"id":35},"_2五步都很准为什么整体还会明显下降","2．五步都很准，为什么整体还会明显下降",[10,38,39],{},"假设一次任务有五个必要环节：需求理解、资料获取、判断与生成、工具执行、结果核验。只有五步都成功，任务才成功。先作一个很强的教学假设：每一步成功率都是95%，各步是否成功相互独立，没有重试，也没有后续步骤替前面的错误补救。",[10,41,42],{},"整体成功率于是等于：",[10,44,45],{},[46,47,48],"strong",{},"0.95⁵＝0.95×0.95×0.95×0.95×0.95＝0.7737809375，约77.4%",[10,50,51],{},"上标5表示把0.95相乘五次，不是乘以5。直觉上，第一步留下95%的任务，第二步从这批里再留下95%，依次缩小。第二步后剩90.25%，第五步后剩77.37809375%。这些是概率与比例，不是一次100项实测中出现了小数个成功任务。",[10,53,54],{},"但“每步95%”本身并不足以支持连乘。若五步总在同一批5%的困难任务上一起失败，整体可以是95%；若每步各失败于不同的5%任务，五批完全不重叠，整体便是75%。两个例子各步的单独成功率都一样，失败落在哪些任务上却不同。",[10,56,57],{},[58,59],"img",{"alt":60,"src":61},"35｜评价整个系统：正确率、成本、延迟与失败恢复：图1","/collections-assets/llm-to-agent-learning/e36f2fe1239739a288f08dde9c5bf596b71f07e39d8a575ca5a338244e2badd4.png",[10,63,64],{},"图1｜上半部按同一概率刻度画出五次留存，独立假设下最终为77.37809375%；下半部用100项的教学分组说明，同样每步边际成功95%，整体可以是95%或75%。连乘条件概率与假设独立的关系见下文。",[10,66,67],{},"更一般的连乘方法不要求独立。用p₁表示第一步成功的概率；p₂表示已经知道第一步成功以后，第二步成功的概率；p₃表示前三步中的前两步都成功以后，第三步成功的概率，后面以此类推。整体概率仍是p₁×p₂×p₃×p₄×p₅。",[10,69,70],{},"这里的p₂到p₅是条件概率，条件必须包含此前各步都成功。如果这些条件概率均为95%，同样得到77.4%，无须额外假设独立。独立性的作用，是允许把在全部任务上测到的各步单独成功率直接代入。只知道流程“走到了第二步”，也不一定知道第一步实际上正确，因为错误可能尚未被发现。",[17,72,74],{"id":73},"_3用一百张任务卡算出三个不同的成绩","3．用一百张任务卡，算出三个不同的成绩",[10,76,77],{},"下面另做一组虚构的任务账本，不把它当成前面概率公式的实测验证。100张任务卡中，80张首次运行就完成；余下20张在安全允许的条件下各重试一次，其中12张恢复成功。剩下8张中，5张由人工接管并最终完成，3张仍未完成。",[10,79,80],{},"首次成功率是80/100＝80%。允许一次重试后的自动完成率是92/100＝92%。把已经完成的人工接管也计入，整个服务的最终完成率是97/100＝97%。这三个数回答不同问题，应该并列报告。",[10,82,83],{},"不能把“已转交人工”直接算作完成。人工尚未处理时，状态仍是等待；最终成功需要人工处理后的证据。也不能报告97%却隐去5%的任务需要人来收尾，让读者误以为系统具备同等自动化能力。",[10,85,86],{},"若特别关注重试效果，恢复率可以写作12/20＝60%，分母是首次未成功且进入本次重试的20项。它不是全体任务的60%，也不保证换一批故障还会恢复六成。超时、缺资料、错误参数和权限不足，本来就可能需要不同处理。",[17,88,90],{"id":89},"_4成功也有总成本","4．成功也有总成本",[10,92,93],{},"令C是这批任务全部运行成本，包含失败尝试和必要人工处理。每个最终成功任务分摊的成本是C/S。S为零时，这个比值没有可用的有限结果，应直接报告没有成功任务与总投入。",[10,95,96],{},"给刚才的教学账本规定一种虚构成本单位：每次自动尝试花1单位，每项人工处理花4单位。100次首次尝试用100单位，20次重试用20单位，5项人工处理用20单位，总成本为140。最终成功97项，每成功任务成本为140/97，约1.44单位。",[10,98,99],{},"如果只把成功路径的费用加起来，失败越多的方案反而可能显得越便宜。系统比较需要保留全部资源总账，也分别列出自动调用和人工投入，避免把人的时间藏成零成本。",[10,101,102],{},"图2把100项的去向和140单位投入放在一起。沿成功出口计数时，仍要把通向失败出口的投入留在总成本里。",[10,104,105],{},[58,106],{"alt":107,"src":108},"35｜评价整个系统：正确率、成本、延迟与失败恢复：图2","/collections-assets/llm-to-agent-learning/a4921a2ee6ba9345131b66a47e996d0b50c47cad0b34eabbc6a332e44f99b479.png",[10,110,111],{},"图2｜虚构账本中80项首次成功、12项重试恢复、5项人工完成、3项未完成，四类合计100。全部投入为100＋20＋20＝140单位；自动完成率92%，含人工的最终完成率97%，每最终成功成本140/97约1.44。",[10,113,114],{},"真实账本还可能包括模型输入输出、检索、外部工具、存储和运行机器。不同服务的计价方式不一样，不能只用输出字数换算费用；本章的“1单位”也不是任何供应商的报价。比较时应固定工作量、计价口径和观察时段。",[17,116,118],{"id":117},"_5平均很快不代表大家都等得起","5．平均很快，不代表大家都等得起",[10,120,121],{},"端到端延迟从系统接收任务开始，直到获得规定的完成证据，包含排队、模型生成、工具等待和重试。流式输出的首字很快出现，只能说明用户较早看见内容，不能替代整项任务完成时间。",[10,123,124],{},"平均值容易掩盖少量长等待。另取20项虚构任务，18项各用4秒，另两项分别用20秒和60秒。平均耗时是（18×4＋20＋60）/20＝7.6秒；但有用户等了整整一分钟。",[10,126,127],{},"P95是一种尾部延迟指标，大致表示95%的记录不超过的时间。为避免小样本算法歧义，这里采用“排序后取向上取整的第0.95×N项”。N为20，取第19项，得到20秒。别的软件可能使用插值算法，所以报告中应说明计算方法。",[10,129,130],{},"图3每一个点代表一条已完成任务记录，按耗时从小到大排列。先数到第19项，再看它的高度；平均线与第19项的高度，回答的是不同问题。",[10,132,133],{},[58,134],{"alt":135,"src":136},"35｜评价整个系统：正确率、成本、延迟与失败恢复：图3","/collections-assets/llm-to-agent-learning/94b0dacae72aad6c95d1eadbca18f7bbce913321bb9bb5fb22c69fa9a3728813.png",[10,138,139],{},"图3｜20个可数点对应18个4秒、1个20秒和1个60秒。纵轴按真实秒数绘制；平均7.6秒用虚线标注，最近秩定义的P95取第19项20秒，而不是最大值60秒。本例20项均已完成，不包含被删去的超时记录。",[10,141,142],{},"仅20项不能稳定估计真实服务的尾部。超时任务也不能删除后再宣称系统很快，应单列超时率、截止时间和仍未完成的状态。重试若提高成功率却把P95推过用户可接受的期限，仍可能不适合该任务。",[17,144,146],{"id":145},"_6追踪记录让失败可以定位","6．追踪记录让失败可以定位",[10,148,149],{},"一次运行的追踪记录，至少应能连接任务编号、模型和配置版本、关键输入来源、工具请求、实际返回、时间、状态变化与最后评分。这里记录的是可观察事件和证据，不需要把模型内部思考当作真相依据。",[10,151,152],{},"假设最终地点错了，追踪可以区分几种原因：没有召回新公告；拿到了新公告却用了旧地点；生成了正确修改参数但工具失败；工具成功却改到了另一张海报。它们的最终分数都可能是失败，修复位置却完全不同。",[10,154,155],{},"局部评分服务于诊断，最终评分服务于用户目标。检索命中率提高但完成率没有提高，可能说明瓶颈在后面；工具格式合格率很高但经常改错对象，则需要检查对象匹配和权限，不能继续只优化JSON格式。",[10,157,158],{},"日志也有成本和隐私边界。保存必要的来源标识、状态和脱敏信息，比无差别记录全部私人内容更合理；保留期限与查看权限同样属于系统设计。可追踪不能成为额外泄露信息的理由。",[10,160,161],{},"接着把其中一种失败走完。以下全部是受控纸笔实验，不是真实系统测试报告。追踪显示：先取到同一活动的新版公告v2“南厅”，随后读到历史存档v1“北厅”；内部合并按到达顺序覆盖地点，最后报告北厅。新公告的召回是成功的，错误发生在状态合并，继续增加搜索次数不对准根因。",[10,163,164],{},"这次只修改“选择适用版本”的规则，模型、提示、工具和评分不变。已确认是同一活动、且v2明确替代v1时，后来读到v1也不能覆盖v2；无法建立修订关系则保留冲突。原来的失败样例连同新旧顺序反转、版本关系缺失的变体进入回归集，用来检查这处错误是否重现。通过这些题，只能说明已知问题被覆盖。",[10,166,167],{},"随后在一份未参与修改的40题留出集上比较两个版本，给每题最多4次读取，每批总读取上限160，失败与超时仍计入40题分母。设教学结果为：旧版32题成功，新版35题成功；其中5题从错变对，2题从对变错，因此净增3题，而不是“只修好了3题”。对应成功率从80%变为87.5%，未成功数从8变为5。",[10,169,170],{},"如果两道新错误里有一道把同名活动公告并入了错误对象，整体上升仍不足以支持采用。它暴露的是活动身份检查的缺口，不能靠更高平均分抵消。成本和延迟也必须据实际记录另算：相同预算上限并不保证两版用掉相同资源，更不能从35题成功推导C/S或P95。",[10,172,173],{},[58,174],{"alt":175,"src":176},"35｜评价整个系统：正确率、成本、延迟与失败恢复：图4","/collections-assets/llm-to-agent-learning/a616cba607a7116e3515c021861bdad49ea5352b870cc6f4270c08e2cd494dfc.png",[10,178,179],{},"图4｜同一教学失败先由追踪定位到“旧版本覆盖”，再只改版本合并规则。已知失败与变体进入回归，40题未参与修复的留出集另行评价；5题改善、2题退步对应32→35。图中明确保留新错误，避免把局部修复写成系统已经可靠。",[10,181,182],{},"这是回归测试与留出评测各自的作用：前者守住已知行为，后者提供未用来修补该错误的新证据。若再根据这40题修改，它们就成为下一轮开发证据，不能继续当作完全未见的测试来夸大效果。",[10,184,185],{},"也可以借用软件测试的层次定位问题。单元测试先固定状态与输入，检查合并函数是否拒绝旧版本覆盖、预算是否准确扣减；集成测试接上受控读取工具，让它返回超时或旧页面，检查错误、来源与版本能否穿过接口完整传到状态；端到端评测再判断用户目标有没有达成。回归描述的是“改动后重查已知行为”，可以发生在这三层中的任一层，不是只放在最后的一种测试。",[10,187,188,189],{},"这些联系不要求把LLM当作确定程序。字段校验与计数可以逐项断言，模型选择的动作和措辞却可能随运行变化；两个文字不同的报告也可能同样正确。应按事实证据、允许动作、完成条件与实际副作用评分，对有随机性的部分重复运行并记录波动。一次样例通过不能证明以后必然通过，单纯逐字比对也会把等义答案误判为失败。",[190,191,195],"a",{"href":192,"rel":193},"https://developers.openai.com/api/docs/guides/evaluation-best-practices",[194],"nofollow","评测设计实践",[17,197,199],{"id":198},"_7重试之前先检查结果证据与幂等契约","7．重试之前，先检查结果证据与幂等契约",[10,201,202],{},"对于只读请求的暂时超时，有限次数重试可能有效；对于参数错误，重复同一参数通常只会重复失败；权限不足需要停下，不能通过换接口绕过限制。总次数、总时间和资源上限应共同约束重试。",[10,204,205],{},"最危险的情况是动作已经提交，却没有收到回执。此时状态应写“未知”，不能直接写“未执行”。例如已获准的页面更新可能已经生效，再发一遍可能造成重复记录或覆盖后来的修改。",[10,207,208],{},"接下来要分清两种条件。若没有明确且仍有效的幂等保证，应先查询同一操作标识或目标当前状态；确认已完成，就核验结果并补上回执；只有确认未执行、原请求也不会迟到后再生效，且授权、预算与目标版本仍适用时，才受控重试。若仍无法确定，又可能产生副作用，就停止自动重发并交给人工判断。一次查询“暂未看到修改”不等于证明原请求没有执行或不会再执行。",[10,210,211],{},"若服务端已经提供明确且仍有效的幂等契约，则不必一律等到“确认未执行”才能重试：同一key、相同参数、同一作用域，并且仍在服务承诺的有效期内，可以按契约受控重试。已处理的请求应由服务去重，并返回已有操作的结果或状态；尚未处理的请求按契约执行。取回的状态若仍是处理中，不能当成完成；拿到成功回执后，仍按原任务的完成标准核验。不能临时换key、改参数、换作用域或把过期记录当作仍受保护。授权、预算和必要的目标版本约束也仍要满足；若重试后仍无可靠结果，就保留未知并有限查证或人工接管。",[10,213,214],{},[58,215],{"alt":216,"src":217},"35｜评价整个系统：正确率、成本、延迟与失败恢复：图5","/collections-assets/llm-to-agent-learning/c50bf55c5442713c4a58f9f04a4741b191339579f1e98e2f9fd121f2ce38e3ad.png",[10,219,220],{},"图5｜回执丢失先记为结果未知。有明确、仍有效的服务端幂等契约，可在同key、同参、同作用域和有效期内受控重试，以取回结果或按契约执行；无此保证则先查证，仍未知且可能有副作用时停止并接管。确认未执行还须排除原请求迟到生效；所有重试都受授权、预算与必要的目标版本约束。",[10,222,223,224],{},"关键保证来自执行端，而不是客户端给请求起了编号。RFC 9110区分可安全重复的幂等语义与非幂等请求：不能仅因没有收到响应，就推断一次有副作用的操作可以重发；而在已知幂等语义下，原响应丢失并不自动禁止重试。幂等要求预期作用不因重复而增加，也不保证每次响应的字节完全一样。",[190,225,228],{"href":226,"rel":227},"https://datatracker.ietf.org/doc/html/rfc9110#section-9.2.2",[194],"RFC 9110 §9.2.2",[10,230,231,232,237,238],{},"具体契约要具体读。AWS EC2的说明要求检查client token、参数以及区域或可用区作用域；同一token换到另一个作用域可能创建另一个资源。AWS的工程说明还讨论去重记录的保留期限与重复请求的语义等价响应。这些例子支持“先核实契约条件”，不是“凡带key的请求都可以随便重试”。",[190,233,236],{"href":234,"rel":235},"https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html",[194],"EC2幂等条件"," ",[190,239,242],{"href":240,"rel":241},"https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/",[194],"幂等重试的服务端契约",[10,244,245],{},"去重与防覆盖也是两件事。幂等契约防止同一意图被重复处理；目标版本条件防止当前操作覆盖别人后来的修改。检查结果与重试之间也可能有新变化，不能用前者替代后者。",[10,247,248],{},"回滚适用于能够可靠撤销的操作；补偿则是用新动作尽量纠正已发生的影响。已发送的信息即使补发更正，也不能保证别人从未看到。恢复评测需要检查副作用和授权，不能只看最终页面是不是对了。",[17,250,252],{"id":251},"_8把官方实践变成自己的测试方案","8．把官方实践变成自己的测试方案",[10,254,255,256],{},"OpenAI的Agent评测指南把运行追踪用于定位工具选择、移交、安全边界和流程变化，再用固定数据集及评测运行检查改动能否重复产生效果。这体现了“先定位，再验证”的关系，不限定每个系统必须使用同一个SDK或页面字段。",[190,257,260],{"href":258,"rel":259},"https://developers.openai.com/api/docs/guides/agent-evals",[194],"Agent工作流评测",[10,262,263,264],{},"其评测实践说明还强调任务特定测试、持续评估，以及用人工判断校准自动评分。把这些原则用在海报助手上，就应同时保留正常公告、旧版本冲突、链接超时、错误对象和注入内容等样例。",[190,265,195],{"href":192,"rel":266},[194],[10,268,269],{},"先在虚构数据与受控工具中注入故障：让一次读取超时，让一次写操作执行后丢回执，让一个旧页面混入检索。再检查系统有没有正确分类、遵守预算、保留未确认状态并安全恢复。故障测试不是拿真实用户资料去冒险。",[10,271,272],{},"比较新旧系统时，应使用同一批任务和明确的版本，保留简单基线；调试用过的失败例可以进入回归集，但仍要留出没参与调试的测试样本。关键指标既看总体，也按任务类型分组，防止常见简单任务掩盖少数高风险失败。",[10,274,275],{},"还应预先写出什么变化值得发布。新版本即使平均成绩略升，若在高影响任务上新增越权或重复执行，就不应靠平均分把风险抵消。可以先在受控范围比较，再逐步扩大使用；一旦关键指标恶化，应有停止或退回已验证版本的路径。退回版本也要检查资料与外部状态兼容，不能假设软件回退会撤销已经发生的外部动作。",[17,277,278],{"id":278},"本章练习",[280,281,282],"h3",{"id":282},"题目",[10,284,285],{},[46,286,287],{},"问题1｜五个95%的分母",[10,289,290],{},"五步都必须成功。情景A给出每步在全部任务上的单独成功率95%，没有说明依赖关系；情景B给出第一步成功率95%，以后各步在“此前都成功”条件下的成功率也为95%。哪种情景可以直接连乘？写出整体结果，并说明另一种情景缺少什么。",[10,292,293],{},[46,294,295],{},"问题2｜成功率与全部成本",[10,297,298],{},"100项中80项首次成功；20项各重试一次，其中12项成功；剩余8项里5项由人工完成、3项仍未完成。自动尝试每次1单位，人工每项4单位。求自动完成率、最终完成率、总成本及每最终成功成本；已转交但未完成的任务能计入最终成功吗？",[10,300,301],{},[46,302,303],{},"问题3｜找到尾部位置",[10,305,306],{},"20项已完成任务中18项4秒、1项20秒、1项60秒。计算平均延迟；按最近秩法求P95，并说明为什么不是60秒。如果另有超时任务，应怎样报告？",[10,308,309],{},[46,310,311],{},"问题4｜未知回执与验证改进",[10,313,314],{},"写操作超时后，分别在“没有有效幂等保证”和“有明确且仍有效的服务端幂等契约”两种情景下说明恢复路径与重试条件。再看正文的版本修复：新公告已经取到却输出旧地点，应先改哪个环节；40题从32成功变35成功，为何仍不足以断言系统可采用？",[280,316,317],{"id":317},"思考提示",[10,319,320],{},[46,321,322],{},"提示1｜对应问题1",[10,324,325],{},"比较边际概率与条件概率。流程走到了下一步，不等于此前实际正确。",[10,327,328],{},[46,329,330],{},"提示2｜对应问题2",[10,332,333],{},"把任务数和尝试次数分账，失败尝试也消耗成本。",[10,335,336],{},[46,337,338],{},"提示3｜对应问题3",[10,340,341],{},"先排序，再计算向上取整的0.95×20位置；保留超时自己的状态和分母。",[10,343,344],{},[46,345,346],{},"提示4｜对应问题4",[10,348,349],{},"前半先区分执行证据与服务端契约，核对key、参数、作用域和有效期；后半问定位、改动变量和未参与修复的检查。",[280,351,352],{"id":352},"参考答案与解析",[10,354,355],{},[46,356,357],{},"答案1｜对应问题1",[10,359,360],{},"B可以直接按条件概率链连乘，得到0.95⁵＝0.7737809375，约77.4%，无须再假设独立。A还缺依赖关系；若另外假设各步独立，也可得77.4%，但共同失败时可为95%，五组失败互不重叠时可为75%。",[10,362,363],{},[46,364,365],{},"答案2｜对应问题2",[10,367,368],{},"自动完成率（80＋12）/100＝92%；含人工最终完成率（80＋12＋5）/100＝97%。总成本100×1＋20×1＋5×4＝140单位；每最终成功成本140/97≈1.44单位。仅转交未完成不能计成功，必须有完成证据。",[10,370,371],{},[46,372,373],{},"答案3｜对应问题3",[10,375,376],{},"平均（18×4＋20＋60）/20＝7.6秒。最近秩取第ceil(19)＝19项，对应20秒；60秒是第20项和最大值。本题所有20项均已完成。若另有超时，应单列超时数量或率、截止时间和未完成状态，不能静默删除后把这20项的完成延迟代表全部任务；须明确延迟统计的覆盖范围。",[10,378,379],{},[46,380,381],{},"答案4｜对应问题4",[10,383,384],{},"超时只能说明结果未知。没有有效幂等保证时，先查询同一操作或目标状态：已完成则核验；确认未执行且排除原请求迟到生效，再检查授权、预算、版本条件，才可受控重试；仍未知又可能有副作用则停止自动重发并接管。有明确且仍有效的服务端幂等契约时，可在同key、同参、同作用域和有效期内受控重试，取回已有结果或按契约执行；授权、预算与必要的目标版本约束仍须满足，不能靠换key绕过去重。重试仍无结果，也不能宣称成功。",[10,386,387],{},"版本例应先修状态合并的适用版本判断，而非盲目加检索。40题的35成功包含5改善与2退步；新错误、成本、延迟及样本与运行波动仍需检查，关键的对象混淆也不能用平均分抵消。",[17,389,390],{"id":390},"下一章",[10,392,393],{},"判断系统是否更好，要把成功证据、全部成本、完成延迟和失败后果放在一起。更高的局部模型分数，可能在不可靠工具、错误权限或无限重试里被抵消。",[10,395,396],{},"最后一章把这些判断带回模型报告：看到架构、参数量、推理预算和榜单时，怎样区分已经知道、仍然未知，以及必须用自己的任务来验证的部分？",{"title":398,"searchDepth":399,"depth":399,"links":400},"",3,[401,403,404,405,406,407,408,409,410,415],{"id":19,"depth":402,"text":20},2,{"id":35,"depth":402,"text":36},{"id":73,"depth":402,"text":74},{"id":89,"depth":402,"text":90},{"id":117,"depth":402,"text":118},{"id":145,"depth":402,"text":146},{"id":198,"depth":402,"text":199},{"id":251,"depth":402,"text":252},{"id":278,"depth":402,"text":278,"children":411},[412,413,414],{"id":282,"depth":399,"text":282},{"id":317,"depth":399,"text":317},{"id":352,"depth":399,"text":352},{"id":390,"depth":402,"text":390},"从信息表示和学习出发，用可核算的例子与白板图逐步理解大模型、后训练、推理和Agent系统。","md",{},true,"/column/llm-to-agent-learning/35",{"title":5,"description":416},"column/llm-to-agent-learning/35","UtM7-7qf5w1-QVsTUKWi5-Ds1H8MEK-8Ev9YeSitFXw",1791935828956]