小书：实践中的演化式架构
InfoQ 出了一本小书，讲怎么让软件系统长期保持“可演化”，也就是在系统、技术和团队不断变化时，架构还能方便地跟着改。书里提到用智能体式的适应度函数来发现语义漂移，把“人能不能看懂”当作核心设计指标，还讨论跨云护栏与区域自治，以及如何让技术边界和康威定律对齐。它主张别再依赖静态架构图，而是用持续反馈系统让每次变更都安全、有意识。
文中可用工具
提供的材料未提及具体可用工具。
展开详情收起详情：小书：实践中的演化式架构
评论 · 分享第一个看法
内容浏览
资讯
搜索中文标题、仓库名或关键词，再用分类、来源和日期缩小范围。
研究与技术
最近成功采集
Uber 实现服务网格依赖分析自动化
Uber 建了一套自动化系统，用来分析自家庞大服务网格里各个服务之间的依赖关系。以前主要靠分布式追踪来排查故障，但它只采样一部分请求，像偶发但影响大的失败很容易被漏掉。这次的新做法从 RPC 中间件和生产环境指标入手，把调用方的失败和被调用下游的失败关联起来，再判断依赖关系属于“失败即阻断”“失败可放行”还是未知。这样工程师能更完整地看清服务间的真实依赖，尤其是罕见故障的场景。
文中可用工具
提供的材料未提及具体可用工具。
展开详情收起详情：Uber 实现服务网格依赖分析自动化
SLM 生成式高并发推理引擎：延迟约束下的有效吞吐优化
美团团队为搜索和推荐场景里的小语言模型（SLM）做了一套新的推理引擎。原来这类场景要在 20 毫秒内返回结果，但通用推理框架（如 SGLang）是为开放式文本生成设计的，调度开销大、效率低。他们把这些“有固定计算步数”的请求重新组织成静态流程图来执行，并用编译和共享缓存等办法减少开销。结果是延迟仍低于 20 毫秒，吞吐达到 SGLang 的 10 倍，Prefill-only 的有效 MFU 为 67%。这套框架已经在美团搜索意图分流、相关性判断、生成式召回等场景取得实验显著性，能支撑全量推送。
文中可用工具
- AOTInductor把 PyTorch 模型提前编译成可直接加载的 GPU 计算产物
- Packed Prefill把多条变长输入打包处理，避免无效 padding 计算
- SGLang原本用于模型执行的通用推理框架，性能对比对象
- Triton Inference Server项目早期用其 Python Backend 适配业务协议
- vLLM原文仅提到名称，未说明具体用途
- PyTorch用于表达模型语义和选择算子实现
- FP8选择性使用的低精度矩阵计算，降低计算开销
展开详情收起详情：SLM 生成式高并发推理引擎：延迟约束下的有效吞吐优化
用 Google Antigravity 加速抗菌肽的搜索
Google 推出了一款叫 Antigravity 的智能开发平台，科学家可以用它来寻找新型抗菌肽（一种有望替代传统抗生素的天然分子）。过去，研究人员要在多个数据库之间来回查找、手动导出文件做结构分析，还要靠专家团队设计实验，过程又慢又零散。这次他们展示了 Antigravity 结合 ProtNLM 模型的用法：ProtNLM 能直接根据氨基酸序列预测蛋白质功能，帮助扫描 UniProt 里数百万个功能未知的蛋白质，从“暗物质”中找到候选分子。演示中，研究人员找到了一个对呼吸道感染病原体有预测活性的抗菌肽候选物，目前正在进行湿实验室验证。对读者来说，这意味着将来找新药可能从几天繁琐的数据库检索变成一次人机协作的对话式探索，不过该候选物尚未证实有效，平台的具体开放状态原文也未说明。
文中可用工具
- Google Antigravity智能化的科学工作台，让研究人员用对话方式跨数据库搜索并评估候选蛋白质
- ProtNLM根据氨基酸序列预测蛋白质 biological 功能的深度学习模型
- UniProt全球领先的蛋白质序列与功能信息公共数据库，含数百万功能未知的条目
- Biomolecular Structure Viewer嵌入 Antigravity 的 3D 可视化工具，用于查看和分析蛋白质结构
- AlphaFold Database提供蛋白质结构预测的数据库，供 agent 检索结构
展开详情收起详情：用 Google Antigravity 加速抗菌肽的搜索
Linus Torvalds 让 Claude Code 修复 Linux 页缓存，评审者随后发现竞态问题
Linux 创始人 Linus Torvalds 用 Anthropic 的 Claude Code 帮忙修一个折腾了两年的内核性能问题。问题是页缓存里频繁加减引用计数，拖慢了普通的缓冲读取，在他笔记本上八线程测试里几乎全部跨核开销都来自这里。AI 写出了补丁、测试和文档，他自己跑基准验证：八补丁版把吞吐从每秒 1000 万次读提到约 3300 万次，后续 10 个补丁的版本在 64 线程 Threadripper 上从 1330 万次涨到 3.04 亿次。不过评审者发现了一个竞态条件和内存回收隐患，Torvalds 已把后续开发交给内核开发者 Kiryl Shutsemau。目前这些补丁仍处于评审和修订阶段，尚未进入正式内核，且真实负载下的提升会小得多。
文中可用工具
- Claude CodeAnthropic 的 AI 编程助手，本次负责编写补丁、测试和文档并辅助审阅
展开详情收起详情：Linus Torvalds 让 Claude Code 修复 Linux 页缓存，评审者随后发现竞态问题
演讲：如何在尚不存在的系统中发现韧性缺陷
软件工程师 Hillel Wayne 做了一场演讲，主题是如何在系统还没真正建好之前，就提前发现那些会导致故障的架构问题。他借用形式化方法里的一些思路，比如属性强度、状态空间验证和环境假设，帮助大家更早地揪出关键 bug。他提出“对抗式非确定性”这样的实用思维模型，用来推理并发、边界情况和分布式系统故障，而且不需要复杂的数学工具。对普通开发者来说，这意味着可以更早发现隐患、少走弯路，降低后期返工的风险。
文中可用工具
提供的材料未提及具体可用工具。
展开详情收起详情：演讲：如何在尚不存在的系统中发现韧性缺陷
Anthropic 红队在 15 台廉价电视盒子上跑 AI，结果让人不安
Anthropic 的前沿红队用约 825 美元买了 15 台杂牌安卓电视盒子，把它们拼成一个小集群来跑 AI 模型，速度只有每秒 0.39 个词，慢得没法聊天，但适合那些不着急、没人等的后台任务。他们周一发布研究，认为小体积的开源模型可能再过几个月就能在廉价联网设备上自我复制，不再依赖数据中心。不过他们并没有做出能在公网上自行传播的 AI 蠕虫，实验是在受控环境里、并开了一些方便复制的后门。普通人可以留意：一旦这类能力成熟，海量廉价设备被悄悄用来跑 AI 并非不可能。
文中可用工具
- Qwen3.5-9B用来在多种硬件上部署 Llama3.1-8B 推理服务的小模型
- GLM-5.2更大、更可靠地完成同样部署任务的模型
- Llama3.1-8B在目标设备上实际运行的推理模型
- Opus 4.8给 Qwen3.5-9B 提供建议的更强模型，实验未见显著提升
- Gemma4-26B-A4B在 15 台电视盒子集群上运行的模型
- CyberGym评估模型攻击能力的基准
- ExploitBench评估模型漏洞利用能力的基准
- Epoch Capabilities Index用来追踪小参数量开源模型能力趋势的指数
- OpenClaw原文未说明用途
- Hermes Agent原文未说明用途
展开详情收起详情：Anthropic 红队在 15 台廉价电视盒子上跑 AI，结果让人不安
GitHub 的秘密检测模型：用更少的噪音发现更多秘密
GitHub 改进了它用来扫描代码里密钥、密码等敏感信息的检测方式。以前用大型语言模型来判断，误报多、速度慢、成本高，因为很多看起来像密钥的字符串其实是测试用占位符或校验码。现在 GitHub 换成两段式流程：先用规则快速找出所有可疑字符串，再用一个专门训练的小模型 ModernBERT 结合文件路径、变量名和周围代码判断它是不是真的密钥。结果是用户接受警报的比例提高了 11.5%，扫描中位耗时降低 86%，服务器成本降低 98% 以上，并且这套方法已经用在提交前的拦截保护里。
文中可用工具
- ModernBERT一个经过微调的小型分类模型，负责判断可疑字符串结合上下文后是不是真正的密钥
展开详情收起详情：GitHub 的秘密检测模型：用更少的噪音发现更多秘密
演讲：EVE Online 如何利用头部采样观察“乐趣”
EVE Online 的工程师 Nicholas Herring 在一场演讲中，介绍了这款已有 20 年历史的网游是如何做分布式追踪和可观测性的。难点在于游戏服务器实时处理海量事件，如果样样都记录，数据量太大、成本高，还可能拖慢游戏本身。他们的做法是在追踪一开始就决定采不采样（头部采样），并配合动态指数移动平均（EMA）和确定性采样，在保证数据能反映真实运行情况的同时控制开销。对做大型在线系统的读者来说，这是一套在“看得清”和“跑得快”之间取平衡的实战经验。
文中可用工具
提供的材料未提及具体可用工具。
展开详情收起详情：演讲：EVE Online 如何利用头部采样观察“乐趣”
何时该用 Liquid Clustering？Lakehouse 布局策略基准测试
有人对比了 Delta Lake 上三种数据布局方式：Liquid Clustering、ZOrdering 和分区。所谓数据布局，就是数据在存储里怎么摆放，摆得好查询就快。作者在四类典型工作负载上做了测试，发现两个此前没被记录过的失效模式，可能已经影响到现在的生产系统。文章最后给出了一套选择布局策略的决策框架，帮助工程师按自己的场景挑合适方案。
文中可用工具
- Delta Lake一种数据湖存储格式，用于组织和管理大规模数据
- Liquid Clustering一种自动调整数据物理布局的排序方式
- ZOrdering一种将多维数据按 Z 序排列以加速查询的技术
展开详情收起详情：何时该用 Liquid Clustering？Lakehouse 布局策略基准测试
上下文语言模型：自我管理上下文以提升性能并降低计算成本
Meta、MIT 和华盛顿大学的研究人员提出了一种叫“上下文语言模型”（CLM）的新方法。过去，语言模型的长上下文通常靠事先定好的规则来总结、压缩和检索信息，不够灵活。这次让模型自己决定怎么管理和修改上下文内容。研究人员表示，这种做法在性能和计算效率上都有明显提升。对读者来说，这意味着未来 AI 处理长对话、长文档时可能更聪明，同时更省算力，不过目前还只是研究阶段。
文中可用工具
提供的材料未提及具体可用工具。
展开详情收起详情：上下文语言模型：自我管理上下文以提升性能并降低计算成本
演讲：构建有韧性的平台——来自20多年关键任务基础设施的经验
Matthew Liste 总结了他 20 多年做关键任务基础设施的经验，提出构建可扩展、可靠平台的 12 条核心原则。这些原则针对企业技术团队常见的问题：技术债越积越多、旧功能下线难、工程文化薄弱。他讲的是怎么设计基础设施平台，让系统更简单、开发流程更顺，并且能长期产生价值。对资深架构师和工程负责人来说，这是一份经验性的设计参考。
文中可用工具
提供的材料未提及具体可用工具。
展开详情收起详情：演讲：构建有韧性的平台——来自20多年关键任务基础设施的经验
分享数学领域的 AI 进展
OpenAI 公布了一批数学开放问题的新结果，这些问题是由其内部的前沿模型解决的。所谓“开放问题”，就是数学界长期没有找到答案的难题；“前沿模型”指能力最强、尚未对外公开的模型。为了让结果可验证，OpenAI 把用 Lean 写出的证明形式化代码以及研究细节放到了 GitHub 上，Lean 是一种能逐步检查数学证明是否成立的工具。对读者来说，这些结果和代码可供查看和复核，说明 AI 在数学证明上又向前走了一步。
文中可用工具
- Lean一种用于把数学证明写成计算机可逐步检查的形式化语言的工具
展开详情收起详情：分享数学领域的 AI 进展
能在笔记本上运行、性能几乎追平 35B 模型的 AI 安全检查工具
Red Hat 的 AI 安全团队做了一次横向对比，把三种安全护栏方案（专用分类器、LLM 当裁判、决策模型）放在同样的测试里跑，看哪一种最能拦住提示注入和有害内容。以前大家要么用专门训练的小分类器，要么花钱调大模型来判断，前者快但不够灵活，后者灵活但慢、贵。这次测试发现，一个约 2 亿参数的小分类器在提示注入上与 35B 大模型几乎打平（准确率 89.01% 对 89.31%），但响应时间只要约 54 毫秒，而大模型要 300 毫秒以上。这对开发者的意义是：如果护栏放在请求路径上，小模型能在普通笔记本 CPU 上跑，既省延迟也省成本。不过内容安全这块，决策模型反而更准，但成绩受提示词写法影响很大，还不能当作定论。Red Hat 计划把这两个分类器作为 OpenShift AI 3.6 的默认配置。
文中可用工具
- NeMo GuardrailsNVIDIA 开源的护栏工具包，用来统一测试和运行不同的安全护栏配置
- JevTypeSafe AI 推出的决策模型，接收应用状态和问题并返回概率等结构化答案，用于分类而不生成文字
- DeBERTa-based prompt-injection classifierRed Hat 约 2 亿参数的提示注入分类器，速度很快
- Qwen3.6-35B用作 LLM 裁判的模型，在提示注入测试中准确率最高
- DiffusionGemma开源的 Jev 风格决策模型，通过 vLLM 部署
- Granite Guardian classifierRed Hat 约 1.25 亿参数的内容安全分类器，速度最快
- Nemotron-3.5-Content-SafetyNVIDIA 约 40 亿参数的内容安全模型，运行 Red Hat 自定义策略
- Laya开源决策模型，约 4.21 亿参数，可在笔记本 CPU 上跑
- BART-large-mnliRed Hat 测试中使用的预训练分类器，在 MacBook Pro M1 CPU 上运行
- vLLM推理服务框架，用于在 GPU 节点上部署多个大模型
展开详情收起详情：能在笔记本上运行、性能几乎追平 35B 模型的 AI 安全检查工具
软件交付知识图谱：架构与指南
很多工程团队的数据散落在 CI、部署、安全扫描等不同系统里，同一个服务在不同系统中叫不同名字，工程师和 AI 每次问“这次部署为什么失败？”都要手动拼数据，答案还每次都变。文章提出用“软件交付知识图谱”解决：把实体、关系和数据格式用“schema 即代码”明确定义，再统一同步和查询，让跨系统的知识变得可靠、确定。还强调图谱质量取决于数据质量，需要监控数据填充率、记录数据来源、持续评估，否则图谱也会退化。文章以博客形式给出架构和指南，未说明配套产品何时可用。
文中可用工具
提供的材料未提及具体可用工具。
展开详情收起详情：软件交付知识图谱：架构与指南
AI 加速漏洞利用，漏洞表格已跟不上节奏
AI 让软件开发变快，也让漏洞被找到和利用的速度变快。过去安全团队靠一张表格记录漏洞、按严重程度打分再排优先级，但现在漏洞太多，这种方法很难跟上。文章提出换个问法：不要只问“我们有多少个漏洞”，而要先问“哪些漏洞真的会给我们带来风险”。做法包括：用更干净的基础镜像和代码扫描减少漏洞进入系统，同时持续扫描真正在生产环境里运行的软件，并结合网络可达性判断风险。这样能帮团队少做“表面功夫”，把精力放在真正危险的地方。
文中可用工具
提供的材料未提及具体可用工具。
展开详情收起详情：AI 加速漏洞利用，漏洞表格已跟不上节奏
监控仓库数据质量不能只看管道健康
销售副总裁让一个连着 Snowflake 的 AI 智能体查上季度收入，结果数字不对。检查发现管道任务全部按时跑完、日志也没报错，但底层表已经连续好几天少了约 22% 的行，还有三个关键字段几乎一半是空的，全程没有任何告警，等发现时报表和决策已经受影响。这篇文章讲的是：管道跑成功不代表表里的数据是对的，还要直接对表本身做检查，比如数据是否按时刷新、行数是否异常变化、字段空值或分布是否漂移、有没有重复记录，并用管道信息帮忙定位是源头、调度还是转换逻辑出的问题。这样能更早发现“管道正常但数据悄悄变坏”的情况，避免拿错数据做决策。
文中可用工具
提供的材料未提及具体可用工具。
展开详情收起详情：监控仓库数据质量不能只看管道健康
我们如何扩展 Apache DataFusion，让单条查询可以跨多台机器执行
Datadog 的工程师把 Apache DataFusion（一个用来执行查询的引擎）从只能在一台机器上跑，改造成了可以跨多台机器跑同一个查询，这个项目叫 Distributed DataFusion。原来他们有很多不同系统各管一摊，数据没法方便地合在一起查，而 DataFusion 虽然好用但只在单机上执行，遇到超大数据量就慢。新框架把查询拆到多台机器上并行处理，同时让数据以流式方式传输，避免中间结果落地，小查询仍留在单机跑以免浪费。代码已开源，用 Rust 写，可在 GitHub 和 crates.io 获取，Apache 2.0 许可；在 12 节点集群的公开测试里，部分重型查询最多快了 10 倍，成本不变。
文中可用工具
- Apache DataFusion一个可组合的查询引擎，用来执行分析查询
- Distributed DataFusion把 DataFusion 扩展成能跨多台机器执行单条查询的开源框架
- Apache Arrow内存中的数据格式，不同系统之间交换数据用
- Substrait执行计划的格式，用来描述查询怎么跑
- ClickHouse被评估过的查询引擎，因扩展性不够被排除
- Apache Spark被评估过的分布式引擎，因需要中间数据落地不适合低延迟交互
- Apache DataFusion Ballista被评估过的分布式引擎，同样因中间数据落地被排除
- Trino被评估过的分布式引擎，因与 Arrow、Substrait 集成不好且成本高被排除
- Amazon S3存放 Parquet 数据，供集群读取
展开详情收起详情：我们如何扩展 Apache DataFusion，让单条查询可以跨多台机器执行
为什么 AI 编程智能体总写出有缺陷的访问控制
AI 编程智能体在写接口时，常常只检查“用户登录了吗”，却不检查“这条数据是不是他的”。比如让它写一个按编号查发票的接口，它会验证登录、查不到就返回 404，看起来都对，但任何人只要改一下 URL 里的编号，就能看到别家公司的发票。问题在于“发票属于某个组织、用户只能看自己组织的发票”这条规则存在于产品设计里，代码和提示词里都没写，所以智能体不知道要加。这类问题叫越权访问（BOLA/IDOR），在 OWASP Top 10 中排第一，传统扫描工具因为没有固定特征可匹配，很难自动发现，目前仍主要靠懂产品的人人工审查，或在查询条件里补上组织范围来修复。
文中可用工具
提供的材料未提及具体可用工具。
展开详情收起详情：为什么 AI 编程智能体总写出有缺陷的访问控制
当关系本身构成证据时，请使用 Graph RAG
当回答一个问题需要理清多条记录之间的关联时，普通向量检索可能不够用。比如问“哪个团队负责那个用了有漏洞的库的服务、哪些客户受影响、合同要求怎么通知”，向量搜索只能找出语义相近的文档，却无法证明哪些记录真正相关，可能把错误的服务版本或客户关联到一起。Graph RAG 的做法是把这些关系显式建成图：每条记录是一个节点，服务“使用”库、服务“支持”环境、合同“受制于”政策等关系成为带类型和方向的边，每条边都能追溯到来源并带生效日期。这样回答时先定位实体，再沿允许的关系遍历，最后取原文解释细节。两者配合使用，图的职责是回答“谁和谁相连”，原文负责回答“政策到底写了什么”。
文中可用工具
- Graph RAG一种把记录间关系显式建模、再沿关系遍历检索的方法，用于回答依赖关系类问题
- GraphRAG微软的方案，用大模型从非结构化文本中抽取知识图谱并构建社区层级，支持语料级和实体级查询
- vector search向量检索，按语义相似度找出与问题相关的文档或记录