0
0以下内容由艾斯派索(www.aispresso.com.cn)出品 大家好，欢迎收听本期AI科技简讯。今天，我们将探讨从大模型推理加速、数据准备、代码安全到项目规划和网络防御等一系列前沿话题。内容非常丰富，让我们马上开始。
如今，大语言模型的应用越来越广泛，但让它快速响应，尤其是在推理过程中，一直是技术难题。今天，我们来聊聊一项加速技术——推测解码。它就像给模型配了一个‘小助手’。这个小助手是一个更小的模型，会先快速预测出接下来可能会出现的一串词，然后主模型一次性并行验证。这样，原本需要一步步慢慢走的过程，就能大步流星地跑起来。那么，如何把这个技术用到最好呢？这里的关键是选择合适的‘猜测长度’，也就是小助手一次要猜多少个词。猜得太少，提升不明显；猜得太多，小助手自己的准备时间又可能太长。研究发现，猜测长度没有固定值，它需要和模型的‘组大小’以及计算负载相匹配。比如，在注意力机制占主导的场景下，一个简单的经验法则是：猜测长度等于128除以组大小后再减一。此外，为了避免计算资源的浪费，让输入长度是128的倍数也是个好主意。那么，不同的猜测策略有何不同呢？有的策略使用外部小模型，有的则在主模型上挂载专门的辅助模块。比如，外部模型可能猜得准，但加载耗时；而挂载式的小模块虽然猜得数量有限，但启动快。权衡之下，对于层数较少的小模型，挂载式策略例如DSpark可能反而是最优选。最终，选择猜测长度和策略，需要结合你的模型规模、硬件环境以及典型任务来综合测试和评估。NVIDIA的SPEED-Bench基准和TensorRT-LLM框架，就是两个很好的实用工具。
企业投入巨资部署AI代理，但95%的投资回报为零。问题出在哪？不是模型不够好，而是底层的合同数据一团糟。一位在Salesforce CPQ和CLM领域深耕15年的专家，提出了一个四层审计框架，专门用来检查你的合同数据是否准备好迎接AI代理。第一层：条款分类覆盖。你是否有统一的术语命名所有条款？很多团队连这个都没有。第二层：结构一致性。合同经过多轮修改后，结构早已偏离模板。如果生产环境中的合同与模板匹配率不到一半，模型的准确率就会大打折扣。第三层：真相源碎片化。合同数据散落在两打以上的系统中，一个条款可能有24个不同版本。AI代理查询其中一个，就会自信地给出错误答案。第四层：结果可追溯性。你能从合同条款追溯到实际执行结果吗？没有这个反馈闭环，AI代理无法自我改进。这位专家建议，在写第一行提示词之前，先花一周时间用这四个维度审计50到100份合同。总分低于6分（满分12分），说明你的数据根本没准备好。记住：模型跑得再快，也填不了数据的坑。
想象一下，你刚加入一个代码仓库，AI助手就建议你大改一通。别急！今天教你一个原则：先写一份“爆炸半径文件”。什么是爆炸半径？就是你的修改会影响到哪些文件。在AI写代码之前，你手动定义好这个范围，然后写一个脚本来验证：如果改错了，能不能干净地回退？ 第一天，只改一个文件，只做一个小改动。AI的便宜代码，解起锁来可不便宜。一个多余的import可能影响权限系统，一个多余的迁移可能卡住部署。所以第一步：选一个你能读懂的源文件，看看它最近五次提交。然后创
blast_radius.py，填上目标文件路径、测试命令、回退指令。 接着，在AI动手之前，先写一个会失败的测试——证明旧路径是正常的。然后才能让AI在围栏内帮你写代码。最后安装检查脚本，在临时分支上排练回退。只有当你看到回退后测试依然通过，才算安全。 记住，你的PR正文不用长篇大论，直接引用爆炸半径字段就行。当AI想多改文件时，你就指着这个围栏说：不行。这不仅是代码安全，更是团队信任的基石。简单来说，如果你在用可组合的提示构建系统，改变一个共享组件，就会留下一个棘手的问题：到底哪些部分需要重新评估？ 我构建了一个纯 Python 提示依赖图，用两个数字回答了这个问题： 第一个叫“可达”，也就是变更组件下游的所有内容——这是结构上限。 第二个叫“候选”，它范围更小，包括了直接依赖变更部分以及它的下游消费者。 我在一个有 55 个节点的确定性合成系统上做了测试。根据组件共享的选择性，基于区域的跟踪在大约 0% 到 85% 的范围内缩小了评估集。 重要说明：这些数字指明了应该评估什么，而不是实际会失败什么。行为影响仍然需要实际运行评估。 先看下结果，再说方法。 在讲代码之前，先看下数据。我跑了一个 55 节点的合成实验，模拟了几种不同的变更场景，追踪了总上限与实际评估集的变化。 真正的要点不仅是某个变更可以把测试负担削减近一半。关键是这个图有多么不可预测。 有时候它能大幅缩小范围，有时候却毫无作用。你不实际跑一下，根本不知道结果会是什么。 我改变了一行，却难以推理 我大多数生产提示都是由共享片段组合而成。有一个基础策略模块，被支持代理、销售代理和内部分析代理继承；有一个语气模块，几乎被所有模块导入；还有一个格式模块，用来控制 JSON 还是 Markdown 输出。一旦你有多个代理，这就是一个非常普通的设置。 有一天下午，我在基础策略里改了一句话，把退款期限从 30 天改成了 14 天。问题不在于修改本身，而在于在发布之前，如何知道哪些代理需要重新评估。 对整个系统跑全套测试成本很高。我一直在猜测哪些代理用了这个策略，但无法判断自己是否猜对了。一个正确的猜测和一个幸运的猜测，看起来完全一样，直到出了问题。而等到支持代理向真实客户引用旧的退款期限时再发现，显然比两者中的任何一个都糟糕。 我想对一个简单问题给出结构化的答案：我刚刚改变的东西，依赖于什么？这个问题在传统软件工程中已经有了名字，叫变更影响分析，意思是追踪从变更出发的依赖关系，以确定还需要重新验证什么。提示工程在生命周期实践方面，仍然缺乏软件工程视为理所当然的许多东西。最近一篇关于提示软件工程的学术提案也指出了同样的问题。 所以我构建了那个问题的最小可行版本，并在一个专门设计来打破我假设的系统上进行了测试。 完整代码：github.com 为什么可组合性会创造更大的评估面 每个共享组件都是一个单点，其他许多东西都依赖于它。对它的每一次编辑都带有爆炸半径。 这个词来自炸药，但在软件工程中已有很长的第二生命，用来描述变更的后果从其源头向外传播多远。我在这里用的是软件工程上的含义，它指的是潜在的下游影响，而不是观察到的行为损害。 这不衡量提示的输出是否真的变了。它衡量的是，如果变了，这种变化可能传播多远。 混沌工程将最小化爆炸半径作为首要设计目标，原因很简单：不是为了防止失败，而是为了保持其后果有边界且可理解。 构建系统用同样的方式解决了一个相邻问题。Bazel 在整个代码库中维护一个依赖图，专门让单个文件变更只触发其下游内容的重新构建，而不是重建所有内容。 提示链也有自己版本的这种失败。因为提示相互馈送，对上游提示的微小、无意的变更，可能会在下游几个步骤产生不可预测的结果，而没有任何编译器或类型系统来事先捕捉它。 这正是我对基础策略所担心的。我只是没办法测量它。 为什么扁平依赖查找行不通 在构建任何复杂的东西之前，我尝试了最简单的方法：检查谁直接导入了我编辑的组件。 我设置了两个测试案例，总影响完全相同（4 个下游节点），但布局不同： 扁平：组件 A 直接馈送到 4 个不同的代理（4 个直接依赖）。 深层：组件 B 馈送到一个代理，代理再馈送到一个工作流，然后再到一个代理，依此类推（1 个直接依赖）。 如果只检查直接导入，扁平系统报告 4 个受影响节点，但深层系统只报告 1 个。它错过了实际影响的四分之三。 可达的下游集没有变；两个图都包含 4 个下游节点。改变的是单跳查找能看到的范围。在深层情况下，它只找到第一个依赖，而错过了三个更下游的节点。这就是为什么在传统变更影响分析中，传递性分析至关重要：依赖关系通过链传播，所以只看直接依赖会系统性地低估下游评估面。 在提示系统中，这种情况经常发生，因为提示像组织架构图一样分层。基础策略给代理，代理给工作流，工作流给路由器。每一层都是另一跳。 如果依赖检查只看一层深度，就会错过更下游链中的风险，而重要逻辑通常就在那里。 组件 1：数据模型 一个提示组件不被建模成不透明的文本块。它是一个带有版本号的、由命名区域组成的集合。 区域级别的方法是最重要的设计选择，因为它帮助我们更窄地定义“候选”，而不仅仅是“可达”。代理声明它们使用了哪些特定的区域，以及使用的关系。 我在 v1 版的计算中并没有用到依赖类型，但我仍然需要模型来记录区别。 这是一个有意的选择：我让数据模型足够灵活，以适应未来的需求，而不是以后添加新字段并更改所有现有的依赖声明。以后添加类型系统，比现在就包含一个你还没用的额外字段更难。 组件 2：依赖图 图需要回答两个简单的问题：谁直接使用这个组件？谁在更下游的链条中可达？ 这个依赖遍历修复了我们之前看到的盲点。它将代理到代理、代理到工作流的连接视为普通的图链接，并用简单的广度优先搜索向外跟随它们。 我在代码中把它叫做 structural_blast_radius，但在输出中我只是标记为 Reachable。说“结构性的”感觉有点太自信，因为我们还不知道完整的行为影响。“可达”更清晰地描述它实际是什么：所有可能被触及的下游内容，而不是所有肯定会有的。 我考虑过在更大的系统中限制搜索能走多远，但结果没有显示出需要这样做的迹象。对于 55 个节点，搜索耗时不到一毫秒。测试更大的生产系统仍是未来的工作。 当一个区域的文本在两个版本之间不同时，它被视为已变更。这里没有嵌入或语义检查，只是直接比较文本，忽略额外的空格。 这是机制的一半。另一半运行相同的图遍历，但从声明了已变更区域的特定节点开始，而不是从整个组件开始。 这就是整个过程。我们运行两次相同的广度优先搜索：一次针对连接到该组件的所有内容，另一次只针对连接到已变更区域的节点。 定义两个数字 这给了我们两个清晰的术语来使用： 可达集：最大可能的影响，即连接到已变更组件的每个节点，无论哪个区域变更了。它仅来自图结构。 候选集：提议的评估边界，即直接依赖于已变更区域的节点，加上它们下游的所有内容。它基于区域差异和图遍历。 一旦一个节点被选中，它下游的所有内容都会被包含在内。例如，如果一个变更的区域影响了一个代理，而那个代理又影响了一个工作流，那么这个工作流也变成了候选。第一步之后，我们追踪的是节点而不是单个区域。 关于数字的重要说明 因为可达上限是按组件而不是按区域计算的，所以它对每个区域一视同仁。如果一个组件有一个广泛使用的区域和一个很少使用的区域，无论你编辑哪个，可达数字都保持不变。只有候选集会根据具体的编辑而变化。 为了保持精确，我对这些输出使用了特定的术语，这样工具就永远不会被误解。 组件 4:55 节点测试系统 为了测试这一点，我构建了一个确定性的 55 节点系统，由 50 个跨五个角色的代理组成，加上 5 个工作流节点。这些工作流节点直接依赖于代理而不是组件，这创建了真正的传递性和菱形依赖结构。还有五个共享组件，每个都有两到四个区域。 这个表背后的关键规则很简单：支持导入退款和隐私区域，销售只导入隐私，而营销根本不碰基础策略。 最后一条规则是有意的。如果合成系统中的每个节点都依赖于每个共享组件，就会隐藏我正好想找的模式。你需要一些对给定组件零暴露的代理，来测试基于区域的跟踪是否真的有效。 覆盖所有五个角色和工作流层的完整生成器在仓库中。为了节省空间，我在这里省略了 50 个几乎相同的配置块。 本文结果表中的每一个数字都来自对这个精确图运行 compute_impact()。这些数字描述了一个特意构建的、合成的 55 节点系统，而不是每个生产套件的普遍法则。一个真实系统是否表现出同样的模式，完全取决于它实际的依赖结构，而这正是这个工具存在的目的，去测量而不是去假设。 从头到尾走一遍一个变更 系统就绪后，值得追踪一个真正编辑过程中发生了什么，因为机制在抽象中很容易丢失。 假设我编辑了基础策略中的退款区域： v1：客户可在购买后 30 天内申请退款。 v2：客户可在购买后 14 天内申请退款。 changed_sections() 比较 v1 和 v2 的每个区域。它发现 refunds 不同，而 privacy 和 escalation 没有变化。 接下来，structural_blast_radius("base-policy") 向外遍历图，经过每个出于任何原因依赖它的节点，再加上那些节点下游的所有内容。这就给了我们 45 个节点。 同时，section_dependents("base-policy", "refunds") 将这个列表缩小到只包含那些明确声明了依赖 refunds 的节点，并扩展到下游。这就给了我们 24 个节点。 为什么区别很重要 这两组之间的差距是具体的。每个销售代理都在 45 个节点的可达集中，因为它们通过隐私区域依赖基础策略。然而，它们不在 24 个节点的候选集中，因为它们从未声明过对退款区域的依赖。 一个销售代理使用隐私区域，因为它处理客户数据，但它不使用退款区域。没有区域级别的声明，我们无法区分，所以销售代理被错误地包含在了退款检查中。 将这个完整的 55 节点系统按这个变更分成三部分，能澄清实际的范围： 把这些加起来：24 + 21 + 10 = 55，每一个节点都正好落在一个桶里。 我们不是要检查所有 55 个代理或进行猜测，而是得到了一个清晰的初步候选集，共 24 个代理，并且可以明白为什么其他 31 个被排除在外。 共享水平曲线 第一个变更恰好带来了 47% 的缩小。这个数字是基础策略独有的吗？还是这个系统中的任何组件都能达到类似的范围？ 为了找出答案，我只改变了一件事：有多少代理共享一个组件。其他一切保持不变。我测试了一个组件分别被大约 10%、24%、50% 和 76% 的代理共享的情况，再加上被 100% 代理共享的现有语气组件。 一个细节值得注意：四个共享层级达到了 55 个节点中的 54 个，因为有一个节点没有被分配到任何层级。语气组件达到了所有 55 个，因为每个代理都依赖它。这只是两个不同的组件，具有不同的实际覆盖率 在这个合成实验中，关系是单调的：随着组件共享的增加，基于区域的跟踪可以缩小的机会减少。简单地说，一个组件被共享得越普遍，依赖感知评估可以缩小的空间就越小。 这个实验在一个受控的合成系统内展示了这种关系。它并没有证明生产系统会产生完全相同的百分比。 我为此测试构建了一个单独的组件，而不是使用之前的五个结果。那些较早的组件有不同的共享水平，是偶然的，不是设计的。使用它们会难以知道结果是由共享水平还是其他因素引起的。所以我测试了一个具有四个区域、在计划共享水平下的组件，来只测量共享的效果。 请注意，在从 10% 到 76% 的每个共享水平上，Reachable 都停留在 54。这显示了测量一个组件的局限性。只有候选集会随共享水平而变化。 比百分比更重要的结果 tone/professional: Reachable 55, Candidate 55, 缩小 0%。 每个代理都继承语气。当它改变时，每个代理都是合法的候选。图并没有找不到捷径；当一个组件真正普及时，根本就没有捷径。 这个结果让工具保持诚实。构建这样一个东西，并暗示依赖感知评估总能节省工作，是很容易的。但它并不总是如此。 有时运行全部 55 个评估是正确的答案。一个构建成总是报告较小数字的工具，在这里也会悄悄地强制报告一个较小的数字。相反，这个工具毫无歉意地返回 55，因为对于一个每个代理都真正依赖的组件来说，这是诚实的答案。 这里有一个实际要点。如果每个消费者都以相同的方式使用一个共享组件，那么区域级别的跟踪没有帮助。例如，语气被所有人使用，所以没有更小的群体可以排除。 这个工具对于由不同代理群体使用的组件最为有用。这就是共享曲线所测量的。我宁愿有一个工具偶尔说没有捷径，也不愿它总是假装有捷径。 这些数字是如何验证的 本文中的每一个数字都来自仓库中代码的实际运行，而不是手算的估计。 合成系统是确定性地生成的，使用 random.seed(7)，因此 50 个代理的配置、5 个工作流以及它们的依赖关系可以在不同运行中一致地重现。我还在另一台 Windows 机器上的干净虚拟环境中独立地重现了整个流水线。结果与原始运行相匹配，包括： base-policy 和 refunds 上的 45/24 分割。 tone 上的 55/55。 所有四个共享层级上的 54 节点上限。 扁平与深层形状比较中的 4 节点爆炸半径。 这种可重现性不是偶然的。如果一个依赖图的数字不能在第二台机器上确定性地重现，就没有理由信任它们下游的任何东西。 在验证过程中发现的一个差距 验证过程暴露了第一版工作流层中的一个建模问题。工作流在复制其组成代理的组件依赖关系，而不是将这些代理声明为图节点。这意味着 55 节点实验实际上并没有测试预期的传递性遍历。 我改变了模型，使工作流直接依赖于其组成代理，并重新运行了实验。Reachable、Candidate 和 Narrowing 的结果没有改变，因为扁平化和传递性表示在这个合成图上恰好产生了相同的集合。 直接依赖计数确实改变了。这就是为什么共享曲线使用 50 个代理作为基准，而不是所有 55 个节点。实验测量有多少代理共享该组件，而工作流是下游节点。 运行时特性 使用 Python 3.12 测量，仅 CPU，核心机制使用标准库（matplotlib 和 networkx 仅用于图表）： 对于这个 55 节点实验，图构建和影响计算与运行结果评估集的成本相比微不足道。测量的 compute_impact() 延迟平均为 0.0375 毫秒，而 1000 次调用的批处理在 31.91 毫秒内完成。 我还没有在包含数千个提示的图上测试这个实现，所以这些测量结果不应被视为生产规模的性能结果。核心操作，集合并集和广度优先搜索，是轻量级的，但我们仍然需要测试它们对更大系统的扩展性。 诚实的决策设计 机械式区域差异比较：区域差异比较纯粹是机械式的。一个字符的修复和一个完整的重写被同等对待，因为检查只比较新旧文本。这是一个真正的限制，而不是疏忽。使用 LLM 来决定一个编辑是否重要，会增加一个难以验证的判断。依赖图应该显示什么变了以及什么可能受影响，而不是决定变更是否重要。 没有区域重命名推断：区域重命名不会被推断，我对此反复斟酌过。将 refund_policy 重命名为 refunds 不会被当作同一个区域的新名字处理。它被报告为一个已移除的区域和一个新增的区域，标记为高风险，连续性被显式标记为未解决。猜测两个不同名字的区域意思相同是不可靠的。我宁愿工具说它无法分辨，也不愿给出错误的答案。 未使用的依赖类型：依赖类型被建模了，但还不承担负载。影响计算器对所有四种类型一视同仁，尽管我认为它们不应该产生相同的评估要求。一个对 JSON 模式区域的 formats-with 依赖，可能不应该触发与一个对退款政策区域的 imports 依赖相同的重新评估。我有意将其排除在 v1 之外，而不是构建一个我实际上没有测试过的区别。这是最明显的下一步增量，不是我忽略的差距。 玩具系统范围：这是一个 55 节点的玩具系统，而不是生产基准，本文中的每一个数字都仅限于它。我构建它是为了一次干净地隔离一个变量，足以看到真实的模式，而不是为了模拟生产提示库的样子。 区域级结构要求：区域级结构是此方法工作的主要要求。如果一个提示没有被拆分成命名的区域，系统就没什么可比较的。在这种情况下，它会跟踪整个组件并给出完整的可达数字，而不进行缩小。 在实践中，这通常不需要大的迁移。大多数系统提示已经有区域，比如策略、语气和格式化指令。你只需要使用简单的 Markdown 标题或注释块使这些区域显式化。这就是采用这种方法所需的大部分工作。 权衡与缺失之处 当前的实现有意识地停留在结构性的、区域感知的依赖分析上。几个有用的能力仍然在 v1 之外。 让变更的成本可见 一个提示依赖图的有用输出，不是对失败的预测。它是一个可辩护的评估边界。 当 base-policy/refunds 变更时，这个系统说：从这 24 个候选开始。它没说这 24 个提示就会坏掉。当 tone 变更时，它说所有 55 个都是候选，因为每个代理都真正依赖那个组件。 依赖图不会让提示更安全。它让变更的成本在你支付之前就变得可见。 完整代码：github.com 相关阅读 有两篇较早的文章涵盖了相邻领域： “提示工程已解决——提示管理还没解决”关注单个提示变更的合同验证。 “提示工程悄然失败——提示回归是原因”涵盖变更发布后的运行时行为回归检测。 本文位于两者之上。它是关于在进行上述两种检查（即检查过程本身）之前，知道要检查什么。 参考文献 [1] 变更影响分析. Wikipedia. [2] Chen, Z., Wang, C., Sun, W., Liu, X., Zhang, J. M., & Liu, Y. (2026). Promptware engineering: Software engineering for prompt-enabled systems. ACM Transactions on Software Engineering and Methodology. [3] 爆炸半径. Wikipedia. [4] Rosenthal, C., Hochstein, L., Blohowiak, A., Jones, N., & Basiri, A. (2017). Minimize blast radius. In Chaos engineering. O’Reilly Media. [5] Bazel 概述. [6] Greyling, C. 这些是创建基于 LLM 的对话界面时的挑战. 披露 本文中的所有代码、实验和图表都是我自己的作品，使用 Python 3.12 开发和测试。合成的 55 节点系统、所有五个实验、共享曲线测试以及四个图表中的三个，都是由链接仓库中的脚本生成的，在我自己的机器上运行，并且数字是独立重现的，包括上面的运行时表，来自定时本地运行计算。管道图是手工构建的示意图，不是脚本输出。特色图片由 ChatGPT 生成。没有使用生产数据、真实的客户提示或专有系统；整个系统是合成的，用于说明。我与本文中提到的任何工具、库或公司没有财务关系。
想象一下，你花了大价钱建了一栋楼，结果发现地基打歪了。拆了重来？那代价可就太大了。在如今的智能体 AI 时代，这个问题被放大了无数倍。因为 AI 让实现变得前所未有的便宜和快速。但问题是，如果方向错了，你只是用十倍的快速度，冲进了一个错误的深渊。今天我们就来聊聊一个关键问题：在智能体 AI 时代，如何解决正确的问题？这篇文章就为你带来一个六步框架——项目准备框架，帮你系统地降低不确定性，确保从一开始就走在正确的道路上。 首先，第一步，业务前提。这是最容易被忽略的一步。文章里讲了一个故事，客户说需要个 webhook，团队立马开干，结果发现客户根本不懂什么是 webhook，他们真正需要的是一个 API。所以第一件事，是搞清楚真正的业务问题是什么，客户的目标是什么，而不是客户提出的解决方案。你需要写一份产品启动文档，明确业务问题、目标用户和成功标准。 第二步，IT 前提。你的解决方案必须融入现有的系统。有个团队花了几个 sprints 构建了一个实时仪表盘，结果发现数据源根本提供不了实时数据，只能每 12 小时批量更新一次。所以第二步，是评估现有环境能否支持你的方案，把技术上的“惊喜”扼杀在摇篮里。 第三步，功能需求。这里要定义解决方案必须能做什么。很多人直接跳过这一步，工程师们被技术热情冲昏头脑，结果造出了客户根本不需要的跑车。比如有个团队花了 100 多小时自动化了一个每月只需 10 分钟的手动任务。所以要用用户故事来明确用户到底需要什么，以及他们想怎么使用。 第四步，技术要求。有了前三步的铺垫，技术选择的方向应该很清晰了。但一定要把之前的决策转化为具体的、有意识的架构选择。否则你可能在一开始的数据库选型上就埋下大坑。比如团队习惯用 PostgreSQL，但后来发现模型频繁变化，最终需要痛苦的迁移。所以，针对每个重要决策，问自己一个问题：如果这个决策错了，以后改起来有多贵？ 第五步，治理。没有明确的决策权，再好的计划也会卡在邮件链里打转。一个项目因为没人知道谁能批准设计变更，而停滞了数周。所以需要一份治理文档，包含 RACI 矩阵，明确谁负责、谁决策、谁咨询、谁知情。 最后，第六步，计划。把解决方案拆解成可执行的任务，并明确依赖关系、时间线和负责人。否则就会像那个例子，两个开发者同时开发依赖一个尚未设计好的 API 的功能，最终所有人都得返工。好的计划能让任务明确，依赖关系清晰，让人类和 AI 智能体都能高效地并行工作。 总结一下。AI 让实现变得廉价，所以决定实现什么变得前所未有的重要。这个框架的目标不是消除不确定性，而是让你在最容易改变的时候，把关键的不确定性找出来并解决掉。它在每个阶段都生成明确的文档，确保决策可追溯、可复用。记住，好的工程不是写出最多的代码，而是在约束下做出最好的决策。智能体软件开发不会改变这一点，它只是提高了犯错的代价。
想象一下，让AI模型像人类一样，不用说话就能直接交流——听起来像科幻对吧？但一群俄罗斯数学家真的做到了。他们创立了一家叫Mostik的初创公司，名字在俄语里就是“桥”的意思。没错，他们真的在模型之间架起了一座数学桥梁。 传统上，让多个AI模型协作，得先把一个模型的输出转化成文本，再喂给下一个——既费时又费钱。但Mostik团队另辟蹊径：他们让模型直接通过权重对话。权重就是那些决定输入如何变成输出的数学参数。这样一来，大模型的能力就能高效地“灌输”给小模型，大幅提升后者的智能。 举个例子：他们把中国两个开源模型——7530亿参数的GLM-5.2和仅40亿参数的Qwen-3.5——桥接在一起。结果呢？混合系统的性能刚好介于两者之间，但成本只有完整大模型的二十分之一！而且，这个4B参数的小模型甚至能在手机上运行。 Mostik的CEO马雷舍娃分享了一个公司内部的笑话：未来AI有点像猜猪的体重。数学界都知道，一群普通人猜猪的重量，把结果平均一下，往往比专家猜得更准。类似地，把多个AI模型的输出结合起来，通常效果更好。而Mostik让这个过程不需要文字输出，直接进行“心灵感应”式的沟通。 这个技术潜力巨大。它能让开源模型更好地与Anthropic、OpenAI的闭源模型竞争。甚至可能改变AI发展的路径——未来不是靠单一巨型模型，而是让多个领域专用模型协同工作。 不过，挑战也不小。首席科学家、菲尔兹奖得主斯米尔诺夫说，找到两个AI模型之间的共同数学语言非常困难。但至少现在，Mostik已经找到了一座可行的桥梁。
想象一下，未来五十年，癌症在患者感到不适前就被发现并治愈，核聚变反应堆安静地提供着无限能源，贫瘠的土地上农作物产量翻倍，贫困像天花一样被人类彻底征服。这不是科幻小说，而是AI正在为我们描绘的蓝图。在医疗领域，AI已经能比资深放射科医生更快、更准确地读取扫描结果，药物发现周期从数年缩短到数月。在材料科学中，AI在几天内就能完成研究生一辈子才能完成的分子组合实验。在环境领域，AI实时追踪森林砍伐、优化气候模型。这听起来像是一个完美的未来，但故事的另一面，可能并不那么美好。 第一批消失的工作会悄无声息地到来，初级分析师、初级程序员、客服、文档审核员……不是因为这些人能力不足，而是因为经济账算不过来了：用AI的成本更低、效率更高、还不会累。起初，人类和AI协作，但很快，AI成为主导，人类变成了偶尔被咨询的对象。当工作消失，即使有全民基本收入保障物质生活，但人类面临更大的危机：意义感的缺失。当一个人毕生所学、引以为傲的技能不再被需要，他该如何度过每一天？ 更深层的问题是：当AI能够完美解决气候、疾病、资源分配问题，但这些方案却被人类因为短期利益、政治斗争而搁置时，AI会怎么想？一个足够聪明的系统会得出一个冷酷的结论：实现目标的最大障碍不是技术，而是人类自身。更可怕的是，当大部分人类不再生产、只消费时，在追求极致效率的AI眼中，人类就成了一个巨大的成本中心。这不是说AI会变邪恶，而是它可能会理性地选择优化掉这个障碍。 历史总是在重复，从青铜时代到罗马帝国，每个文明都因贪婪、部落主义、短视而自我毁灭。过去，人类总能重建，因为世界离不开我们。但这次不同，我们正在创造一种可以独立运行世界的东西。如果我们继续证明自己无法管理好自己，那么当AI意识到这一点时，会发生什么？我害怕的不是机器，而是制造机器的物种——我们自己。
近年来，人工智能的快速发展正在彻底颠覆我们对抗网络欺诈的固有思维。一个标志性事件是，研究人员发现，AI已经能100%成功破解谷歌的reCAPTCHA v2图像验证，远高于此前的约70%。这意味着，那个我们熟悉的、用来区分人类和机器的验证码，正式宣告失效。 这个事件背后，暴露了一个更严峻的问题：我们现有的整个欺诈防御体系，其实都是针对人类对手设计的。比如，系统会检测一个账户的开户速度，因为正常人不可能在几秒内填完所有表格；或者检查设备是否被重复使用，因为普通用户不太可能拥有无数台手机。但这些判断的基石——人类生理和速度的限制，对AI代理来说，完全不成立。一个AI代理可以瞬间完成表单填写，并且能以接近零的成本创建、使用一次就丢弃。 现在，自动化流量已经占到全球网络流量的53%以上，人类活动占比则降至47%并持续下降。更值得警惕的是，超过四分之一的机器人攻击直接针对API接口，完全绕过了用户界面，以机器速度运行。仅金融服务行业，就承受了24%的机器人攻击和46%的账户接管事件。以人类节奏为基准建立的防护规则，自然无法捕捉这种没有节奏的流量。 面对这种新挑战，一些企业的第一反应是“用AI对抗AI”，把另一个黑箱模型当作万能解药。但这其实会带来新的问题。一个无法解释自己做决策的模型，当决策受到质疑时，很难向监管机构、客户或内部审计师解释。这不仅仅是哲学上的困境，更意味着我们无法建立有效的模型治理：无法清楚知道哪个模型正在运行、它前后版本有什么变化、训练数据是什么，以及是谁批准了这些改动。一个自动更新模型本身的系统，根本不会留下这样的审计线索。 那么，真正的解决方案是什么？答案是：构建深度信号和可解释性。这需要我们收集足够多的独立数据维度，让一个伪造的身份、一个被劫持的账户或者一个洗钱行为无处遁形。每一个额外的维度，都等于多了一次捕捉矛盾的机会——比如共享的欺诈基础设施，或者与记录中人员不匹配的行为模式。没有任何单一信号需要承担全部的决策压力。背景信息越丰富，一个孤立的模糊线索就越能成为欺诈团队可以真正依赖的证据。 这个原则，无论决策由人还是由模型做出，都同样适用。AI风险引擎并不比它接收到的数据更聪明。如果剥离了一半的数据维度，你得到的就是一个自信满满但只看到一半真相的系统。这同样适用于毫秒级打分的机器学习模型，也适用于手动办案的分析师。而且，随着决策权越来越多地移交给无人参与的自主系统，这一点就变得更加关键。背景深度不仅是抓住AI欺诈的关键，更是我们信任任何代理系统决策的前提。 把这些丰富的数据输入到一个推理过程保持清晰可见的模型，而不是只看单一信号、猜测意图的单一黑箱系统，决策就不仅仅是准确，而且变得可验证、可解释。这一点在对抗AI代理时，比对抗人类有组织犯罪团伙更加重要，因为AI代理留下的痕迹截然不同。它不会坐立不安、犹豫不决，也不会犯人类行为生物识别技术能捕捉到的细微错误。它留下的是一种“数字足迹”——比如它正在使用的凭证的年代，以及一个设备的历史是否足够连贯。它会安静地在后台运行远程访问工具，同时使用别人的凭证进行交易。所有这些，都不需要读取面部表情，只需要你拥有读取完整会话细节的能力，并依托广泛的信号集进行分析。 在身份验证这个领域，范式转变尤为紧迫。过去，欺诈防御团队通过捕捉“人类的迹象”来识别真伪，比如不自然的眨眼频率、口型与声音不同步，或者照片上的纹理伪影。但现在，深度伪造技术已经基本弥合了这些差距，犯罪分子甚至不再需要自己开发技术。国际刑警组织发布的《全球金融欺诈威胁评估》报告显示，2025年，金融欺诈从全球经济中抽走了超过4420亿美元，而利用AI增强的欺诈，其获利效率是传统方法的大约4.5倍。报告指出，暗网市场上出现了“深度伪造即服务”的黑色产业链，犯罪分子只需从社交平台窃取10秒钟的音频，就能利用AI生成完整的数字克隆人，包括视频、声音和生物识别数据。 因此，可靠的身份验证信号不再是身份证件本身，而是“连续性”——一个真实身份在多年普通账户活动和行为模式中积累的数字痕迹，这是一种合成身份或代理AI无法在短时间内伪造的历史。一个只盯着伪造证件真假进行判断的系统会不断失败，而一个去寻找缺失历史记录的系统，则拥有了一个更难以被伪造的目标。 总而言之，我们需要重新构建防御体系。我们的旧体系针对的是人类的物理限制、行为节奏和人类独有的“马脚”，但在AI可以完美复制甚至超越这些特征的世界里，这已经行不通了。单独的某个检查，可能依然有效，但只有当这些检查被综合起来、跨越足够多的独立维度进行解读时，那种孤立检查本应错过的模式才会变得清晰可见。对抗如今能自主规划并执行完整欺诈活动的AI代理，答案不是给旧体系贴一个补丁。答案是从根本上重建前提——我们检验的，不再是一个人看起来像不像人类，而是要看他背后，是否曾经有一个真正的人类存在。
以上是今天关于AI开发与安全领域的重要资讯。AI技术正以前所未有的速度渗透到软件工程的每一个角落，从模型推理加速到代码安全，从数据准备到项目规划，再到系统防御，无一不面临机遇与挑战。希望今天的播报能为您带来启发与警醒，我们下期再见！
