智能构造任务失败原因
就在昨天，我面试了一位后人，他对 r a g 多智能体协助这些概念如数家珍，问他如何设计一个分析师， agent 也能说的有条理， 但当我抛出一个具体的异常恢复场景时，他却哑口无言。这个问题很简单，如果一个多部任务中途失败了，你怎么让他从失败的地方继续，而不是傻乎乎的从头再来？ 这个问题瞬间就把玩具玩家和真正的工程师区分开来了。这个问题背后反映的是行业对 agent 开发工程师的真实要求。我们不再需要只会挑 api 且 prompt 的 ai 玩具玩家， 我们需要的是能构建稳定可靠、可维护系统的武器。锻造时，这意味着你必须深入理解状态管理、异常恢复和人机协调这些看似基础却决定了系统成败的关键环节。接下来，我想分享一个我们团队最近在生产环境中踩过的大坑，以及我们是如何利用 lan graph 来解决这个问题的。 这个案例非常典型，能很好地说明生产及 agent 开发的复杂性。我们的场景是一个投资分析 agent， 它会自动抓取新闻和财报进行分析和总结，最后生成一份报告并发送邮件。这个流程看起来很直观，但在高并发症测试中，问题出现了。 问题出在最后一步，发送邮件。当邮件服务不稳定时，简单的重试逻辑会触发一系列连锁反应，不仅浪费了大量重复计算的资源，还可能因为重新抓取数据导致报告内容不一致。更可怕的是，可能会造成重复发送，打扰用户。这暴露了简单重试策略在复杂工作流中的致命缺陷 我们的解决方案是基于 lan graph 构建的，它的核心优势在于将 agents 的 执行过程抽象成一个有状态的图，这让我们能够实现从失败点继续执行的智能恢复。具体来说，我们做了三件关键的事，定义可缩列化的状态、起用持久化检查点以及设计智能的恢复逻辑。这张图直观的展示了我们的思路， 让我详细解释一下。首先，我们定义了一个包含所有任务信息的状态对象，并确保它可以被缩列化存储。然后我们利用 lan graph 的 检查点功能，在每一步完成后都保存一下当前状态。 最关键的是第三步，我们设计了智能的恢复逻辑，当检测到失败时，系统不会从头开始，而是会进入一个恢复节点，加载最近一次成功的状态快照，然后根据失败原因选择是重试等待还是通知人工介入。总结一下，这个方案的核心价值就是实现了从从头再来到断点续跑的飞跃。 它不仅帮我们节省了大量的计算资源和 a p i 调用成本，更重要的是它保证了数据的一致性和系统的可信。同时，这种设计也为未来引入更复杂的人机协调流程打开了方便之门。 讲了这么多，我也想留一个更有挑战性的问题给大家思考。如果刚才的工作流不是由一个 a 政策完成，而是由三个不同的 a 政策的协助完成的，比如一个研究员、一个分析师和一个报告员，当中间的分析师 a 政策崩溃了，你该如何设计一个大局的恢复策略来保证整个系统的状态是一致的？ 这个问题其实也是我在面试中经常会问到的，他考察的是对分布式系统状态管理和异常处理的综合理解。我很好奇正在做 a 证的开发的你，会如何回答这个问题？你的项目是否已经考虑到了这些生产级的挑战？
粉丝1543获赞6245
相关视频
03:42查看AI文稿AI文稿马总的马维斯已经上线了，那就一起来体验看看。出发 two one， 先是官网的一些介绍，本地模型啊，手机控制啊，一句话完成电脑配置啊之类的， 然后呢，就是安装的一些硬件的要求，我已经下载过了，现在直接来安装一下。其实从安装的这个画面来看啊，马总还是很想把产品做的更普通，话就是好看好玩最重要。 好，安装完成，直接进到主界面新对话，这个啊，就跟所有的 agent 没什么区别。然后我们来看一些常规的功能啊，自动任务， skill， skill 这个页面里的东西还是比较全面的，办公插件的一些东西就都先跳过吧。 好，这里还有一个办公室啊，其实就是搞了一些动画给你看，实际没什么用，还是阻止，还是想做的好玩一些。 然后我这里来登录一下哦，这里还有一个设置 ai 模式，也有隐私，隐私安全，这里应该是添加一些他的动作边界。 其实要我说啊，我们都用马哥的产品也无所谓了，马哥那么多产品，多少都安装过几个的，个人信息啊，是一定保不住的，但是安全问题啊，一定是不会害你的，这点我觉得是没问题的。 好，接下来我给他一个场景，我是两台电脑，一台 mac， 一 台 windows， 这很多人习惯不一样，我呢已经习惯 mac 的 快捷键了，我让他帮我调整一下。 好的，他的结果出来了，没什么毛病。这里其实就是对电脑小白用户来说啊，就很方便了，因为很多设置你不愿意研究，不愿意碰，但用着呢又不顺手。以前就是要搜教程怎么改设置，现在跟他说一句话就 ok。 我之前啊，也是手动改过，就不叫他动手了啊，现在我让他帮我查一下之前的设置， 结果也出来了，也是没什么问题的。反馈的速度呢，不是很快，但是无双大雅，毕竟不要钱嘛，都能接受的 啊。我们来看一下他花了多少投坑啊，接近七万这个数据呢，我觉得大家就当个乐子看吧，也不是很准，反正他目前是每天送你一千万免费额度。就这样的自动化操作，大家自己去换算一下可以做多少事情吧。 这种电脑整理文件，发票规档这些应该是比较轻松的。后来呢，我还让他帮我改了个合同，也没什么问题。不过啊，最开始介绍的说是手机可以操作。嗯，我好像没找到入口，我来问一下他 啊，他说要什么腾讯应用宝，这个东西呢，我之前安装过，不是很好用，而且 iphone 上目前也装不了。或者呢，你可以点左下角的这个标志，就能连自己的 cloud bot， 这样的话呢，也能实现远程控制。 最后我们来总结一下，马总的这个产品呢，还是非常针对入门用户的，目前呢，更像是一个电脑管家，电脑的设置啊，排查一些电脑问题啊，做一些办公上的 paperwork 啊，这些都没什么问题， 是不是做的出色，做的好不好，那又是另一回事，起码能帮你带掉一些繁琐麻烦的事情。太好了，最后面的趋势啊， ai 产品肯定会越来越轻量化， ui 呢，也会更简洁， 上手难度也会越来越低。哎呦，我的太好了，包括像 codex 啊， java code 啊这些在出了桌面版之后就会加速普及和安装率。好，这里是阿月，希望这次内容对你有所帮助，我们下期再见。
706阿悦很严格
03:59查看AI文稿AI文稿青科社区每日最新论文推荐今天我们要聊的是如何通过一种叫做 code tracer 的 方法。嗯，来让代码智能体的执行过程变得可以被追踪、诊断和修复。嗯，从而提升代码智能体的可调试性和执行的成功率。 这个话题很有意思啊，那我们就直接开始吧。我们先来探讨一下这个 code tracer 要解决的核心问题是什么。为什么说现在的代码智能体难以调试？因为现在的代码智能体，它在执行一些比较复杂的任务的时候，它的这个执行轨迹会很长， 然后呢，中间的状态的跳转和错误的传播，你是完全看不到的，你只能看到一个最终的结果，就是它成功还是失败。 那这样的话，端到端的成功率其实是没有办法帮你定位到这个失败具体是出现在哪里的，所以导致你调试非常的困难。没错，那这个 code tracer 到底有哪些核心的贡献？它是怎么来解决这些问题的？呃，首先它会把各种各样的日制 统一转成一种层级化的诡计术。 ok， 然后它可以自动帮你找到失败是从哪个阶段开始的，具体是哪一步出错了，还会输出一些诊断信号，那这些诊断信号可以用来做反思重放？ 对，就是它可以让你去分析并且修复这个问题。哦，听起来很全面啊，那这个评估方面呢？在评估方面，它其实还建立了一个叫做 codetreebench 的 基准， 里面包含了四个主流的框架，五个大模型，然后总共是有三千三百二十六条带步骤标注的这样的轨迹， 那他是可以支持这种细力度的错误定位的评测的。另外他还通过一些分析得到了很多有意思的发现，比如说这个智能体经常能够获得有效的信息，但是他没有办法把它转换成正确的行动。还有就是框架变得更复杂，并不意味着你的成功率会提升。 对，然后错误的类型其实是跟执行的阶段是有很强的相关性的。明白了，那我们来聊一聊这个科学家，他的核心的流程 就是他到底是怎么工作的，怎么来实现这样的一个错误诊断和修复的。首先他第一步会用一个叫做进化式提取的技术，就是他会自动地去适应不同框架的日制格式， 然后把它们都整理成一个标准的步骤记录。那整理成标准的步骤记录之后，这些信息会怎么来组织呢？之后呢，他会用一种树状缩影的方式，把探索的步骤和状态变更的步骤分开， 然后建立起这种层级化的轨迹数，这样的话你就可以很快速的去导航，并且定位到异常的位置。嗯，在定位到异常之后呢，他会通过便利这个轨迹数 自动的帮你找到失败是从哪个阶段开始的，以及哪些步骤是跟错误相关的。同时它会构建出一条证据链。 ok， 最后它还会有一个反思重放的过程，就是会把诊断的结果再反馈给智能体， 然后智能体就可以在不增加任何预算的情况下，自动的去尝试修复那些失败的任务。好的，那我想知道就这个 coach， 他 在实际的评估当中表现怎么样？他的定位的 f 值可以达到百分之四十八， 这个是比直接提示和轻量基线都要高很多的，而且它的 token 消耗也更少。厉害了吗？那这个反思重放的效果呢？反思重放这个机制其实也很有效，它可以让失败的任务的通过率有显著提升。嗯，另外就是不同的大模型，它的定位的策略也是不一样的， 你比如说 gbt 五，它就是一个高精度、低成本的策略。然后 cloud 它是侧重于高召回， deep seek 则是比较均衡。今天我们聊了很多关于这个 code tracer， 它是怎么去把这个黑盒的代码智能体的执行过程 变得透明化，可诊断化。对，然后包括它是怎么去通过一些新的方法来帮助我们提升这个调试的效率以及任务的成功率的。没错，如果你对这个话题里面的一些核心的图标和关键的数据， 那我们这期节目就到这里了，感谢大家的收听，拜拜。拜拜。
20青稞社区
04:40查看AI文稿AI文稿大家好，我是老于这个系列视频，七天带你读完智能体设计模式第一个核心模式，提示词链，也叫管道模式，单一复杂提示会让大语言模型出现指令忽略、上下文偏离、 幻觉等一些问题。提示链的核心是分而治之，把复杂任务拆成多个小步骤， 前一步的输出作为后一步的输入，每步只做一件事情，强烈推荐步骤之间用追悼等格式化结构传递数据。我们来用一个游戏案例来做演示，玩家说，今天天气真好，我们去森林里探险吧。 我们希望 npc 的 行为拆成两部分，第一步只让它生成十五字以内的文本回忆。 第二步让他根据自己生成的这个文本回忆，从某个月社的表情里面选一个。在这里我们会把最终输出格式化为 g 层格式， 方便游戏引擎解析使用。提示词链流程中可灵活接入工具与代码。 like chain 是 基础组建库，提供提示链工具调用等现成的模块适合今天这种简单的线性流程。 landscape 是 智能体编排引擎，专门处理有状态循环、多 npc 协助的复杂逻辑。后面讲多智能体的时候会用到第二个设计模式路由。 上一章的提示链只能执行固定的限性流程，但现实中的智能体需要根据输入动态调整行为。 路由的核心就是给智能体加入条件判断的能力，先分期输入或系统状态，在动态选择最适合的子流程去执行 它，让智能体从只会按顺序做事变成会根据情况做决策。路由有四种主流的实现方式，其中最常用的是基于大蚁研模型的意图分类。回到我们的 ai 游戏案例， 玩家的输入可能五花八门，我们不能用同一个提示链处理所有的情况， 所以需要加一个路由器，把闲聊请求发给对话智能体。执行我们上一章的两步提示链， 把任务请求发给任务智能体，把战斗请求发给战斗智能体。每个智能体都只做自己擅长的事情， 互不干扰。主流框架提供了现成的路由组建路由是构建多智能体系统的核心，它让我们可以无限扩展智能体的数量和功能。以上就是路由模式的全部内容。第三个设计模式并形化， 并形化的核心就是把没有依赖关系的任务拆出来，让他们同时一起，最后再合并。结果 他在处理模型、调用 api 请求这类 io 密集型任务时，效果尤其显著， 能把响应速度提升几倍甚至几十倍。我们用批量生成游戏卡牌的场景来举例，假设生成一张卡牌需要三个完全独立的任务，第一，调用 ai 绘图生成卡牌插画。第二， 调用大模型生成卡牌文字描述。第三，基于我们预设的数值公式，计算并生成卡牌的攻防学属性。这三个任务之间没有任何依赖， 所以他们可以同时进行。批量生成多张卡牌时，效率提升会很明显。最后只需要加一个步骤，把三个生成结果合并起来就可以。主流框架都提供了，现成的 b 型化构建， 调用起来很方便。这里需要注意的是，只有完全没有依赖关系的任务才能够 b 型。最后简单收尾，总结一下 题诗词练是用来拆解有依赖的复杂任务的，路由是负责根据不同的输入动态分配流程的。 b 型化则是用来并发处理独立任务，提升效率的。本期课程就到这里，也欢迎大家关注我，一起探索 ai 游戏开发的更多可能。
100老鱼游戏工作室
07:08查看AI文稿AI文稿嘿，大家好，你是不是也遇到过这样情况，你辛辛苦苦做的 ai 智能体原型，在自己电脑上跑的好好的，结果一拿到真实环境里，哎，就崩了。 别急，这事太常见了，今天咱们就来看看谷歌他们是怎么把一个特别脆弱的原型，一步步打造出一个真正能上生产环境的强大的系统的。 哎，这句话咱们得好好品品，因为他真的说出了我们每个开发者的心声，对吧？就是那种你觉得自己的原型简直是天才之作，结果一拿到现实世界里，被各种意想不到的情况一顿毒打，那种感觉真的太真实了。 好的，今天咱们的分析思路就很像一次会诊，我们会先来看看这个病人这个脆弱的原型到底有哪些症状。然后呢，我们会一步步揭晓他的康复计划，从最核心的架构问题入手，也就是告别单体，再到数据和结构，最后是怎么观察和优化。 好，我们开始吧，来认识一下我们今天的病人 titanic， 他 本来是个挺有潜力的销售，研究智能体，可惜啊，得了个典型的脆弱架构综合症。 你看他表面上的工作，听起来很简单，对吧？研究个公司，然后写封邮件，但这就像座冰山，水面上看着没什么，水底下呢，藏着一大堆乱七八糟随时可能引爆的致命问题，整个项目都可能因此沉默 啊。这张表可以说是诊断的核心了，最有意思的地方是，你看这些症状，它们是环环相扣的。比方说，就因为它是单体脚本，一个特别小的 api 错误就能让整个系统直接瘫痪，然后呢，又因为它是静默失败，你压根就不知道是哪出了问题， 这么一搞，整个系统在生产环境里就完全没法信任了。所以啊，唯一的办法就是彻底推倒重来，而且从一开始就要用生产优先的思路去构建， 所以重点就非常清楚了，这已经不是修修补补的问题了，不是说给 bug 打个补丁就行，而是要把原来那套乱七八糟的设计思路整个扔掉，从零开始重新思考这个智能体到底应该是什么结构。 好，我们来看第一个，也是最关键的一个经验，告别那个又大又笨重的单体脚本，这就是单体结构最要命的问题。 你可以把它想象成一条链条，整个系统的强度就取决于他最脆弱的那一环。在这里，任何一个子人物，哪怕只是一个网络超时，都可能让整条链条叭的一下就断了，而且还悄无声息，整个系统就这么崩了。 你看这个对比，一下子就清楚了，左边呢，就像一张乱七八糟的蜘蛛网，随便动一根线，可能整个网都乱了，根本没法调试。而右边呢，是一条特别清晰可预测的流水线，每个环节都有自己明确的工作， 这才是可靠的系统该有的样子。那么具体怎么改呢？就是创建一个分布式的流水线。你看现在任务被拆开了，第一步有个智能体专门负责研究公司，他干完活把结果交给第二个智能体。第二个专门规划怎么搜索， 每个节点都是一个专家，只干好自己的一件事，然后把成果传给下一个。这么一来，就算有一个环节出错了，我们也能马上定位到问题，整个系统就不会瘫痪。 好了，有了这格坚实的结构，地基算是打好了。接下来咱们看经验二和三，这两个主要是解决智能体处理数据输入和输出的问题，彻底告别硬编码的限制。 这就是之前的样子，一团糟，你得在 prompt 里写一大堆指令，求着大语言模型给你返回想要的 jason 格式，结果呢，他还经常不听话，格式一错，后面就全乱了。 再来看之后的样子，现在啊，我们直接用像帕拉丁这样的工具，给他定义一个清晰的必须遵守的数据器约，这就不再是请求了，而是命令。这样以来，每次输出的数据格式都是我们想要的，不仅可靠，还省了不少偷看。 现在我们来看经验三，大家看这个数字十二，这是什么意思呢？这就是原来那个智能体知道的所有案例研究的数量 为什么这么少？因为这十二个案例是直接写死在代码文件里的。要解决这个问题，他们建了一个动态的 r a g 流水线，也就是解锁增强生成。说白了，就是给这个智能体外挂了一个可以随时更新的知识库。 现在他不用再依赖写死的代码了，而是有了自己去获取和查询新信息的工具，他能自己去学习和成长了。 好了，现在我们来评上这幅拼图的最后几块，怎么让智能体变得容易调试，同时还要控制好成本， 这就是经验四要解决的关键问题。你想想，如果你的智能体出错了，你却完全不知道它内部发生了什么，那不就成为一个黑箱吗？这样的东西，你怎么敢把它放到生产环境里去呢？ 所以解决方案就是必须要有可观察性，用像 open telemetry 这样的标准工具就能实现分布式追踪。这就像是给智能体内部的每一部都装上了监控摄像虎，你可以清清楚楚地看到整个执行流程，这样一来，黑箱就变成了透明的玻璃盒儿。 最后经验五是关于钱的，也就是财务安全。你怎么能保证一个出了 bug 的 智能体不会陷入死循环，然后在一夜之间烧光你所有的云服务预算呢？ 这里的关键就是用一个内置了安全机制的框架，这些机制就像是自动的熔断器，你看它能防止无限重试，可以设置超时，还能智能的处理各种失败。 有了这些，你就不需要自己去写一大堆复杂的保护代码了，系统就能自动地、优雅地处理失败，保住你的预算。 那么应用了这五个经验之后，我们最开始的那个病人 titanium， 现在变得怎么样了呢？ 可以说他经历了一次脱胎换骨的转变，从原来那个又慢又不可靠的单体，变成了一个健壮的、可扩展的，而且完全可观察的分布式智能体。这也就证明了从原型到生产的这条路，说到底就是对一个坚实可靠架构的追求和承诺。 那么现在回过头来看看你自己的项目，你的智能体是不是也正被困在原型炼狱里， bug 不 断，迟迟无法上线呢？ 今天咱们分享的这五个经验，它不仅仅是一份修复指南，更是一份帮你构建未来可靠 ai 系统的路线图。那么，你的下一步打算怎么走呢？
16Travis
03:00查看AI文稿AI文稿从最近的整个 ai 的 发展趋势来看，毫无疑问就是云龙虾这条技术路线，智能体这条技术路线已死啊， 特别是 ospek 最新发的这个模型啊，它能够自己不断地进化，还能够自己去执行这些复杂的任务。 从现在整个 ai 发展的这个技术路径来看的话，毫无疑问大魔形态已经完全取得了胜利。 这里稍微给大家科普一下，就是这个事情的背景啊。现在对于 ai 的 发展，主流的观点，嗯，是认为有两大技术路径的。 第一派呢，叫做大模型派，他们就是觉得，哎，现在说 ai 他 可能有幻觉啊， 上下文的记忆力不够啊，处理不了呃，一些复杂的实际问题啊。这块的观点就认为，为什么会这样呢？就是因为现在 这个模型它的参数还不够多，它的算力还不够强，只要有更多的参数，嗯，更强的算力，到时候 ai 它就会涌现出 agi 出来，就能产生通用智能。 现在所有的问题到时候都能随随着这个发展去解决，这一派就叫做大模型派。 再有一派呢，叫做智能体框架派，他们就觉得单一的模型啊，现在有嗯幻觉啊，记忆力弱啊，没办法执行那种复杂任务啊，他们就觉得要给 要把那个大模型关到一个框架里面，只有通过这种框架才能够帮助人类解决实际问题。因为在赤地上，其实现在的 ai 它已经高出人很多了， 但现在的 ai 它的很多的问题还是没办法解决，它就解决不了实际问题。所以现在像 oppo， 可乐，它就是典型的智能体框架派的嗯，产物。 很多人就想用 ai 创业什么的，也是想做自己的智能体的产品啊，但就现在 这段时间的发展来看的话，真的好像框架派是错误的路线，大模型派才是正确的路线。
11:0214Travis
07:46查看AI文稿AI文稿今天我们要讨论的是在 cga 里面如何安全地使用动态内存，以及怎么避免一些因为普通指征和智能指征混用而产生的一些容易让人迷惑的错误。我们先来聊第一个问题， 为什么在大多数情况下都推荐优先使用 mac shared， 而不是直接用 new 来创建一个 shared 下划线 ptr 呢？其实主要的原因就是 mac shared， 它可以一次性完成内存分配和对象的构造。对，这样就可以避免一些因为异常而导致的内存泄露，同时它还能让代码更加的高效和简洁。 如果说我就是要自定义删除器，那我这个时候要怎么用 new 来促使化一个十二的下划线 ptr？ 这里面有哪些地方要特别注意的？如果要自定义删除器，那你只能用直接促使化的方式把 new 出来的指针传给十二的下划线 ptr 的 构造函数。 但是你一定要非常小心，因为如果你在一个很复杂的表达式里面使用了 new， 一 旦中途抛出异常，就很有可能会造成内存泄露。所以除非你必须要自定义删除器，不然的话最好还是用 make shift。 我 们来看两段代码， 第一行定义了一个指向 double 类型的空智能指，真，名字叫 p 一， 它目前是空的，没有指向任何实际对象。 第二行定义了一个指向 int 类型的智能指，真，名字叫 p 二，它先用 new 在 堆上创建了一个值为四十二的整数，然后交给 p 二来管理。 这里要划个重点，虽然这样写语法没错，但在实际开发中，我们不推荐直接用 new 来初使化智能指针，尤其是对 int， double 这类内置类型，推荐的写法是用 mixed 来创建，这样更安全也更高效。既然说到这儿，咱们就来谈谈 shared filter 的 构造函数为什么要声明成 explicit？ 嗯，这样设计到底是为了避免哪些潜在的问题？这个问题问得好，因为如果没有 explicit 的 话，你可以直接把一个普通指征用赋值的方式隐式转换给 share 的 下划线 tdr。 嗯，就像这样，这样其实很容易出错，所以它的构造函数被声明为 explicit， 就 只能显示地出式化。 这样的话就可以强制你用直接抽象，让这个内存管理更加的安全。如果一个函数要返回 shared pewter， 那 这个时候我们要注意些什么？嗯，才能避免出现一些内存管理的漏洞呢？其实你不能直接返回一个用 neil 抽象的裸指针对，你必须要显示地用 shared 下划线 ptr 包裹一下， 不过更好的方式是直接用 make sure 的。 嗯，这样的话就会既高效又安全。我们接着要说的就是 share tablair 的 各种构造方法，以及它们各自适用的场景。嗯，那能不能给我们仔细的讲一讲，每一种构造函数到底是怎么用的？包括它的参数是什么含义，有没有什么要注意的地方？好的， 我们来看共享智能指征的两种构造方法。第一种智能指征 p 接管裸指征 q 指向的堆内存对象。注意， q 必须是用 new 分 配的内存，且不能再被其他智能指征管理。 第二种智能指征 p 从 unique ptr 对 象 u 那 里夺取对象的所有权，构造成功后，原来的 unique ptr 对 象 u 会被置为空，不再指向任何对象。 还有两种构造方法，一种是 p 来管理 q 所指向的资源，但是它的释放是用你自己定义的可调用对象 d 来替代 delete。 对， 那还有一种就是 p 作为 p 二的一个副本，但是它用的是你指定的删除器 d。 这两种其实都很适合一些特殊的场景，比如说你要管理的不是一个普通的内存，而是一个文件矩阵，或者是一个网络连接。嗯，那这个时候你就可以用自定义的删除器来确保这些资源能够被正确的释放。 下面咱们谈谈 shared percent reset 成员函数 reset， 其实主要就是用来管理 shared 下划线 ptr 的 指向。比如说你调用 p 点 reset， 那 如果 p 是 唯一的指向该对象的智能指征的话，那这个对象就会被释放， 然后 p 会被置为空。如果我想要让 p 指向另外一个对象，那我该怎么做呢？你可以用带参数的 reset， 比如说 p 点 reset q， 嗯，那这个时候 p 就 会指向 q 所指向的东西，然后原来的那个对象如果没有其他 share 的 下划线 ptr 指向它的话，就会被释放。 还有一个版本就是 p reset q d， 这个 d 就是 自定义的删除器。对，这个就特别适合用来管理那些不是普通的 new 出来的内存，比如说动态数据库、文件聚丙，或者是网络连接。嗯，这样就可以保证这些资源可以被正确的释放。我想知道如果混用普通指征和智能指征，会带来哪些严重的风险？ 嗯？有没有什么具体的代码？我们定义了一个 process 函数，接收一个 share ptr 类型的参数。 当我们创建一个 share ptr， 指向一个值为四十二的 int 对 象时，它的引用技术是一，然后我们把 p 传给 process 函数，这会拷贝一份 p， 引用技术就变成了二。当 process 函数执行结束，行餐 ptr 离开作用域被销毁，引用技术减回一。 所以函数调用结束后，用屁节引用是完全安全的。但接下来就是非常危险的错误示范了。我们先用 new 创建了一个 int 对 象，并用普通整数 x 指向它。然后我们把这个普通整数 x 直接传给了 share 的 ptr 的 构造函数，再把这个临时创建的 share 的 ptr 传给 process 函数。 问题来了， process 函数执行结束时，这个临时 share 的 ptr 就 会被销毁，他会认为自己是这块内存的唯一拥有者， 是直接调用 delete 释放了 x 指向的那块内存。而此时我们的普通指征 x， 它自己并不知道内存已经被释放了，它还是指向原来的地址。当我们在后面再用 x 去解引用，比如写 int j 等于星号 x 的 时候，就会访问一块已经被释放的内存，这就是典型的也指征问题。腾讯的行为是完全未定义的，可能崩溃，也可能出现各种莫名其妙的错误。 所以记住一个核心原则，永远不要用一个普通纸针去出场 share ptr。 一 旦你把一块内存交给了智能纸针管理，就不要再用裸纸针去操作它了，否则很容易造成内存被重复释放或者也纸针的问题。那 get 这个函数到底应该在什么场景下用？嗯， 使用它的时候最容易踩的坑是什么？ get 其实就是为了和一些老的代码或者是第三方的库进行交互。嗯，因为那些地方可能只能用普通纸针。那你可以通过 get 来把智能纸针内部的那个裸纸针取出来。比如说我们代码示意中的裸纸针 q 等于 p 点 get。 但是你千万要注意，在 q 还在使用的期间，一定不能让屁释放，不然的话 q 就 变成空弦指真了。你刚才提到了空弦指真，那如果我们用 get 函数返回的指真去初使化或者赋值给另一个智能指真，会有什么隐藏的风险？ 你这么做的话，就会让两个独立的智能指针指向了同一块内存。比如我们用螺指针 q 又构造了一个新的 share ptr， 名叫 p 二。这是一个非常致命的错误，因为 p 二是一个全新的独立的智能指针， 他不知道屁的存在，他会以为自己是这块内存的第一个，也是唯一的管理者，于是他会单独维护一个引用技术 初始化为一，那当 p 和 p 二中有一个被销毁的时候，这块内存就被释放了，那另一个智能齿轮就变成了也齿轮，你再去操作它的话，就会出现未定义的行为，甚至可能会程序崩溃。然后我们来讨论一下怎么用 reset 来实现写实拷贝技术。 嗯，具体的流程是什么？写实拷贝其实就是你要修改一个被多个 share peter 共享的对象的时候，你要先判断一下自己是不是唯一的所有者，如果不是的话，你就先用 reset 分 配一块新的内存，把内容复制过去，然后再去修改。嗯， 这样的话就可以保证你不会影响到其他的使用者。对，那这个就是通过 unique 来判断你是不是唯一的所有者， 然后通过 reset 来进行深拷贝。行，今天我们把学员的下划线、 ptr 和 new 混用的时候会遇到的各种坑，嗯，都给大家拆解的差不多了。希望大家以后在写私家的时候能够避开这些陷阱，让你的代码更稳健。好的，拜拜。拜拜。
58阿西拜编程
05:45查看AI文稿AI文稿小模型最可怕的不是笨，是会突然卡死，疯狂复读还停不下来。 近日，在 lequid i i 的 一场技术分享里，负责预训练的马克西姆拉邦纳讲了一个很多做本地模型的人都踩过的坑。 小模型最容易突然进入末日循环，一句话重复到天荒地老，任务直接卡死。他先把小模型的先天体制讲清楚， 第一，内存受限，手机、车机这类设备就决定了模型必须小。第二，知识容量更低，所以更适合做任务型，而不是通用聊天。 第三，对延迟极其敏感，吞吐慢一点体验就崩。也正因为这三点，小模型不是大模型简单缩小版，架构和训练都得按边缘端重新设计。为什么架构会影响小模型上线？ 他举了 gemini 三的二点七亿参数、 gemini 二点五的零点八 b 参数作对比，点出一个很反直觉的地方，小模型里此表嵌入层可能占掉大头。比如二点七亿里，嵌入层能到百分之六十三，零点八 b 里也有百分之二十九。 这些参数对推理和能力贡献没想象中大，但却真实吃掉了内存预算，等于把能用来做推理的有效参数挤没了。 liquid ai 在 lfm 二架构上做的关键是把嵌入层做得更小，把更多预算留给真正产出能力的部分， 并且不是纸面推导，而是直接在目标硬件上做 profile。 最后选中了门控、短卷机这类算子，比滑动窗口、注意力、门控 datanet 等都更快。延迟敏感场景就吃这一套， 你会发现，这其实是小模型工程的核心逻辑。同样一 gb 内存，拼的是谁把每一分参数和算力花在刀刃上。接着他说，训练配方 l f m 二点五的流程分阶段很常见，预训练与中期训练、监督微调偏好对齐，强化学习。但有个数字特别扎眼，他们把三百五十 m 参数的模型预训练在二十八万亿 token 上。 按春季了缩放规律，很多人会觉得小模型吃这么多 token 不 划算。但他的观察是，哪怕到这么小的规模继续加预训练， token 性能仍然在涨。 更有意思的是，罗伯茨等人提出的测试时缩放规律，甚至暗示二十八万亿 token 可能还不够最优。 这对做应用的人其实是好消息，小模型训练成本更低，反而更适合用更多数据把底座打扎实，然后把能力集中在数据抽取和工具调用这类最能落地的任务上，而不是追求样样都会，但样样一般。 重点来了，为什么会末日循环？它的判断很直接，当你同时满足三件事，模型很小，还想它做推理，任务又复杂，末日循环概率就会暴涨。尤其在困难数学题复杂多部任务里，模型如果走不出去，就可能进入重复模式。 怎么治？他给了两套能落地的工程解法。第一套是在篇号对其阶段用数据纠篇。他们做 on policy 数据生成，先准备大约一百万条 prompt， 然后用当前策略模型做温度采集，一次生成五条 rollout， 让答案更多样，同时再用温度为零生成一条 rollout， 这种最确定性的输出更容易触发复读。然后把这六条都交给 l l m 评审团打分，最高分做 chosen， 最低分做 reject， 只要复读出现，它大概率会成为 reject。 于是模型在偏好对齐里学到，别走向复读。第二套是在强化学习阶段，用可验证奖励加惩罚项止血。 可验证奖励的逻辑很硬，比如数学题，你必须产出最终答案才能得分，复读往往产不出最终答案，自然拿不到正奖励。同时再叠加一点 ngram， 重复乘法，进一步压制复读倾向， 再配合温度踩样带来的 rolode 多样化末日循环，就更不容易卷土重来。 它还给了一个非常工程化的效果数字，在 lfm 二点五、一点二 b 推理模型上，它们统计多个基准后的 doom loop 比例， 预训练后大概在百分之十五到百分之十六做监督微调，几乎不怎么动，做完直接偏好优化，也就是 direct preference， optimization 会明显下降在上强化学习后，问题几乎消失。 这段话背后其实是在提醒做本地模型的人，监督微调不是万能药，遇到卡死复读这种稳定性问题，真正有效的是偏好对齐和强化学习这类让模型学会停止错误行为的阶段。最后，他把小模型的正确打开方式说的很实用。 内存受限意味着知识容量低，知识问答更容易产生幻觉，那就别硬背，给他工具网页搜索之类的外部工具，让他能查再答。小模型长，上下文也弱，那就用更递归的环境，必要时交给 python 去拆解和计算，等于用工具绕开模型短板。 小模型不一定要知道的多，但必须推理稳定，工具调用可靠，这样在断网、低延迟、强隐私的场景里，比如车机、金融、医疗的受监管环境反而更有优势。你用本地模型遇到过复读卡死吗？
106GenAI动力
02:50查看AI文稿AI文稿面试官问，当多个 agent 协助执行复杂任务时，出现了资源争抢和任务思索，导致整个工作流停滞。你如何从架构上解决这个问题？说实话，每次问到这个问题，我都能从候选人的回答中看到他们真实的技术水平和项目经验。很多时候，答案不在于代码写的有多快，而在于思考得有多深。 大部分候选人的第一反应都是这些常规操作，比如给共享资源加个锁，操作失败了就重试，或者给每个任务加个超时时间。 这些方法在简单场景下确实有效，但他们只是治标不治本。一旦把这些简单方案放到真实的生产环境中，问题就暴露了。 想象一下，几十个 a 整它同时运行简单的锁机制，会立刻成为性能瓶颈。更糟糕的是，如果锁的力度或顺序设计不当，反而会主动制造死锁，让整个系统彻底瘫痪。我们团队就有过这样的血泪教训，在早期开发一个金融分析系统时，我们天真的认为枷锁和重视就能搞定一切， 结果上线后，系统稳定性一塌糊涂，每天都在处理各种超时和死锁问题。团队疲于奔命，痛定思痛，我们决定彻底重构。我们引入了中央协调者模式，简单来说，就是成立一个交通警察，专门负责管理所有 a 政的行动和资源使用，让 a 政的们各司其职，不再各自为战。 第一步，我们建立了一个局资源管理器，简称 g r m。 它就像一个资源调度中心。任何 a 政的想要使用任何共享资源，都必须先向 g r m 申请， g r m。 手里有一本清晰的账本，记录着所有资源的使用情况，从而从根源上杜绝了资源的重复分配。第二步，我们实现了一个分布式锁服务 d r s。 拿到资源使用权后， agent 在 执行关键操作时还需要去 d r s。 获取一把更细力度的锁。 这就好比你拿到了会议室的钥匙资源，但在发言时还需要抢到话筒锁。这种设计避免了把整个 agent 都锁住，极大地提升了系统的病发处理能力。 第三步，也是最关键的一步，我们设计了死锁检测与恢复机制。 g r m。 会像一个侦探一样，时刻监控着资源的等待和持有关系， 构建一张实时更新的依赖关系图，一旦它通过图算法分析发现途中形成了一个闭环，也就是死锁，就会立刻采取行动。我们的策略是资源剥夺。为了最小化对系统的影响，系统会去剥夺环中优先级较低的任务所持有的资源，并将其任务回滚， 从而打破这个僵局，释放被阻设的高忧任务，让整个系统恢复正常运行。通过这个案例我们可以看到，这道题的真正目的不是考察你会不会写一个锁的代码， 而是考察你是否具备将分布式系统的经典理论应用到 a 诊的这种新场景的能力，以及你是否有设计一个高可用、高并发症的架构思维。一个优秀的大模型应用开发者 不仅要懂模型，更要懂工程，它需要具备将传统软件工程的智慧迁移到充满不确定性的大模型世界中的能力，这包括系统设计、抽象思维和场景迁移能力。
