跨栏目检索
搜索中文标题、仓库名或关键词，再用分类、来源和日期缩小范围。
今天暂时没有新上架内容，你可以继续浏览历史归档。
katagun/ai-systems-atlas · Curated atlas of operational AI systems, agents, frameworks, memory systems, licenses, and evidence
AI Systems Atlas 是一个经过编辑审核的目录，收录可运营的 AI 系统、与供应商无关的模型发布及其开发实验室、连接系统的规范、托管推理服务、自托管推理运行时、宿主 Agent 可安装的 Agent 包，以及有据可查的 AI 机器人。目录以静态网页形式发布，所有审核记录同时以无密钥、无限速的 JSON 形式提供；仓库包含编辑目录、校验与刷新自动化脚本，以及无依赖的静态 Web 界面，并区分来源元数据与 Atlas 审核记录。
销售副总裁让一个连着 Snowflake 的 AI 智能体查上季度收入，结果数字不对。检查发现管道任务全部按时跑完、日志也没报错，但底层表已经连续好几天少了约 22% 的行，还有三个关键字段几乎一半是空的，全程没有任何告警，等发现时报表和决策已经受影响。这篇文章讲的是：管道跑成功不代表表里的数据是对的，还要直接对表本身做检查，比如数据是否按时刷新、行数是否异常变化、字段空值或分布是否漂移、有没有重复记录，并用管道信息帮忙定位是源头、调度还是转换逻辑出的问题。这样能更早发现“管道正常但数据悄悄变坏”的情况，避免拿错数据做决策。
提供的材料未提及具体可用工具。
Datadog 的工程师把 Apache DataFusion（一个用来执行查询的引擎）从只能在一台机器上跑，改造成了可以跨多台机器跑同一个查询，这个项目叫 Distributed DataFusion。原来他们有很多不同系统各管一摊，数据没法方便地合在一起查，而 DataFusion 虽然好用但只在单机上执行，遇到超大数据量就慢。新框架把查询拆到多台机器上并行处理，同时让数据以流式方式传输，避免中间结果落地，小查询仍留在单机跑以免浪费。代码已开源，用 Rust 写，可在 GitHub 和 crates.io 获取，Apache 2.0 许可；在 12 节点集群的公开测试里，部分重型查询最多快了 10 倍，成本不变。
AI 编程智能体在写接口时，常常只检查“用户登录了吗”，却不检查“这条数据是不是他的”。比如让它写一个按编号查发票的接口，它会验证登录、查不到就返回 404，看起来都对，但任何人只要改一下 URL 里的编号，就能看到别家公司的发票。问题在于“发票属于某个组织、用户只能看自己组织的发票”这条规则存在于产品设计里，代码和提示词里都没写，所以智能体不知道要加。这类问题叫越权访问（BOLA/IDOR），在 OWASP Top 10 中排第一，传统扫描工具因为没有固定特征可匹配，很难自动发现，目前仍主要靠懂产品的人人工审查，或在查询条件里补上组织范围来修复。
提供的材料未提及具体可用工具。
当回答一个问题需要理清多条记录之间的关联时，普通向量检索可能不够用。比如问“哪个团队负责那个用了有漏洞的库的服务、哪些客户受影响、合同要求怎么通知”，向量搜索只能找出语义相近的文档，却无法证明哪些记录真正相关，可能把错误的服务版本或客户关联到一起。Graph RAG 的做法是把这些关系显式建成图：每条记录是一个节点，服务“使用”库、服务“支持”环境、合同“受制于”政策等关系成为带类型和方向的边，每条边都能追溯到来源并带生效日期。这样回答时先定位实体，再沿允许的关系遍历，最后取原文解释细节。两者配合使用，图的职责是回答“谁和谁相连”，原文负责回答“政策到底写了什么”。
一位安全从业者发现，公司员工早就在用各种AI工具干活了，但IT和安全团队根本不知道他们用了哪些工具、接触了哪些数据。问题在于，很多企业只会发文件说“AI该怎么用”，却没有提供一条方便又安全的实际使用路径，结果员工干脆自己找工具，风险反而更大。作者建议安全团队换个思路：先摸清AI在实际中怎么用、能碰哪些数据、能执行什么操作，然后为开发者提供经过审核的组件和隔离环境，把安全做成好用的默认选项，而不是事后审批的关卡。这样企业既能跟上AI落地速度，又不至于让每个新工具变成新的风险。
提供的材料未提及具体可用工具。
谷歌为 AI 生成的蛋白质加上了“隐形签名”，这就是 SynthID Bio 的概念验证。以前，AI 设计出的新蛋白质和天然蛋白质很难区分，DNA 合成公司在筛查时无法判断一个陌生序列是不是人工制造的威胁，数据库也可能被错误标注的合成结构污染。SynthID Bio 把签名直接写进蛋白质的基因序列和三维结构里，实验证明这样改动不会影响蛋白质的正常功能，还能被检测出来。不过目前这只是概念验证，要真正投入使用还需要解决防篡改等问题。
PatrickWiloak/cloud-data-ai-security-zero-to-hero · Cloud + Data + AI + Security from zero to hero. 149 certs across 27 providers, 53 plain-English concepts, 15 hands-on builds, cross-cloud + AI service comparisons.
这是一个以 Markdown 文档为主的开源学习与参考资料库，围绕云、数据、AI 与安全四大主题组织内容。仓库包含 149 个认证学习指南（覆盖 AWS、Azure、GCP、Kubernetes、NVIDIA、Anthropic Claude 等 27 家厂商）、53 个概念页（LLM、RAG、MCP、Agent、VPC、K8s、IAM 等）、15 个动手项目（含 RAG、MCP Agent、vLLM、评测框架、LoRA 微调）、跨云服务对比、CLI 速查表、架构模式、职业认证路线图与面试准备指南，并发布为支持全文检索的网站。
Vespa.ai 将举办一场线上研讨会，讲的是搜索系统效果不好时该怎么办。很多人的第一反应是换更强的"重排器"——它负责把候选结果里最好的排到最前面——但大规模重排既费钱又慢，而且如果前面检索阶段压根没把正确结果捞进来，重排器也无能为力。这次分享提出把检索做成"多层漏斗"：先用便宜的词法、向量或混合检索从大堆文档里捞出一大批候选，再逐步收窄，最后只让少量最有希望的候选进入昂贵的机器学习重排。这样前面覆盖广、后面花钱少。活动时间为 10 月 13 日，需注册参加，未公布其他细节。
OpenAI 在周五发布的报告中说，它发现了一种新型的提示注入攻击：和传统计算机蠕虫类似，这种攻击能把自己复制到其他邮件、文件或代码注释里，让 AI 代理继续传播。提示注入是指藏在内容里的指令，会误导 AI 去执行不该做的事。目前这些情况只出现在训练和评测时模拟的工具调用中，没有影响到真实系统，属于研究结果而非安全事件。OpenAI 通过 GPT-Red 自对弈训练框架找到了这些样本，并计划把“自我复制”加入防御训练，希望以后模型更能扛住这类攻击。
Meta 为自家的数据库 ZippyDB 加了一个叫 ZGateway 的中间层（代理）。以前每个应用都要和数据库单独保持连接，连接太多、管理麻烦；现在应用只连 ZGateway，由它统一负责连接管理、流量分发、缓存、负载均衡和访问控制。它每秒能处理超过 10 亿次操作，承载了 ZippyDB 约 40% 的流量，Meta 的模型估算持久连接数因此减少了 19 倍。对读者来说，这是大型互联网公司如何用代理层给数据库连接“减负”的一个实际案例，目前仍是 Meta 内部方案，未说明对外开源或商用。
Anthropic 新成立了一个生命科学研究团队和实验室，想看看 Claude 能不能帮忙研究生物学。他们只给 Claude 一个大致方向，让它去庞大的 DNA 序列库里找有意思的酶。大约 950 个 Claude 代理花了 21 小时、用了 2.1 亿个 token 搜索后，其中一个找到了一种此前没被描述过的酶系统，它旁边带有一串重复的 DNA 序列，这种组合此前只在少数能剪切、复制、粘贴 DNA 的可编程系统里出现过，让人联想到 CRISPR。目前这个叫 ART 的系统具体功能还不清楚，研究仍在进行，相关预印本已经发布，实验室工作全部由人类科学家完成，只涉及低风险生物材料。对读者来说，这说明 AI 代理开始被用来辅助基础生物发现，但离实际应用还很远。
性能工程老将 Adrian Cockcroft 聊了聊 AI 给这个领域带来的变化。以前想搞懂服务器性能数据，得去翻内核源码猜数字含义，他为此写过两本性能调优的书。如今他用 ChatGPT 等工具“氛围编程”，几分钟就能搭出定制分析工具，比如一个开源工具用来分析响应时间分布里的多个峰值，而不是只看 P99 这种单一指标，因为真实系统往往有多个峰值，P99 会误导人。对做性能的读者来说，他的建议是先用低倍“显微镜”找异常，再逐级放大到单条慢请求。
Mallika Rao 在一次演讲中提出，自适应推荐系统真正的难点不在模型结构本身，而在系统怎么搭。现实中系统要边用边学，就得处理实时反馈、检索内容的新鲜度、多阶段流程的协调，以及从用户请求到返回结果的整体延迟预算。同时还得兼顾成本和可观测性这些实际运营限制。目前这只是演讲内容分享，文中没有说明有任何现成工具或产品可以直接使用。
提供的材料未提及具体可用工具。
Netflix 工程团队在 Amazon EMR 上跑 Apache Spark 任务时遇到一个麻烦：托管环境只给任务发一个 AWS 身份（IAM 角色），但公司内部服务只认自家 PKI（Metatron）签发的短期证书，两者不通用。他们的做法是让每个 Data Project 与一个专用 IAM 角色一一对应，控制面在提交任务时附上一份签名声明；任务启动后再用 AWS 凭据签出一个预签名 URL，以此向身份服务证明"我确实持有这个云身份"，换取内部证书。这样 Spark 任务就能以 Data Project 身份访问加密列、查表权限，而不必依赖启动者的个人身份。方案不限于 Spark 或 EMR，任何只有云凭据的托管环境都可套用。
有一类做大额或敏感签名的系统，会把「门限签名」放进芯片级安全区（TEE）里跑。门限签名是多方可计算（MPC）的一种：多方一起签名，任何单独一方都不掌握完整密钥；TEE 则靠硬件厂商的证明机制来建立信任。问题在于，如果协议没有把外部主机当作不可信环境，攻击者可能把文件系统回滚，让签名方重复使用同一个随机数份额，从而泄露私钥份额。这篇博客说明 TEE 证明能解决什么、不能解决什么，审计中最常见的坑，以及把强证明和参与方身份绑定的做法。作者结论是：把 TEE 当作纵深防御而非协议的替代品，这个组合才值得用。文中未给出具体的部署或开源工具信息。
提供的材料未提及具体可用工具。
Christine Lemmer-Webber 和 David Thompson 在一场演讲中介绍了 Spritely 项目。如今很多网络应用都靠中心服务器运行，一旦服务器出问题或掌握在少数公司手里，用户就很难掌控自己的数据和通信。Spritely 的做法是把应用做成点对点：用 Goblins 实现基于能力的访问控制（可以理解为只发钥匙、不设万能门禁），用 OCapN 让不同程序像演员传纸条一样互相通信，还用 petname 系统让用户自己给联系人起名，避免依赖全局身份。它借助 Scheme 语言、WebAssembly 工具 Hoot 以及本地优先的 CRDT（多人同时改数据也能自动合并），目标是让没有中心服务器的安全点对点应用成为可能。目前这是演讲分享，尚未说明具体可用版本或发布时间。
文章作者做了一个实验：给 GitLab 公开文档做了一个聊天问答系统，拿一句包含五个不同问题的话去测试。主流做法是把复杂问题拆成五个小问题分别检索，再合并、重排、塞进有限的上下文窗口。结果五个正确答案虽然都被检索到了，但最终只有一条被保留，另外四条被排在前面的答案挤掉了；不拆分反而能保留三条。作者把这种现象叫“上下文饥饿”：某个子问题虽然找到了答案，却在最后分配上下文空间时被挤掉，而且常规召回率指标完全看不出来。文章指出，查询分解只解决了检索阶段的问题，分配阶段仍由“谁分高谁上”的不公平策略决定，需要引入公平性约束。目前这是作者在 GitLab 公开文档上做的实验，配套评测方法尚未说明是否开放使用。
Modal 的两名资深工程师 Colin Weld 和 Connor Adams 最近写了一篇文章，讲他们怎样把公司用来跑代码的“沙箱”系统整个推倒重做。原来的问题是：用 Kubernetes 这种常见容器管理方式，没法同时支撑几百万个沙箱，也没法每秒新建几万个。他们从底层重新设计后，做到了这两点。对读者的用处是：如果你关心云端跑代码、AI 智能体执行环境这类场景，这提供了一条不用 Kubernetes 也能大规模扩容的思路。目前文章只是经验分享，没有提到具体产品是否开放或开源。
提供的材料未提及具体可用工具。
Google 为它的 Private AI Compute 平台加入了一种新的“服务端记忆”能力，让 AI 助手能把你的个人信息长期记在云端，跨设备使用。问题是，过去云端处理 AI 任务时不会保存上下文，任务一结束记忆就被清空，难以实现连续的个人助手体验。这次的做法是把数据加密后存在云端专用空间，而解锁密钥只留在你的设备上，AI 需要时通过加密通道临时解密处理，然后马上重新加密，理论上连 Google 也看不到。这样一来，你在手机、笔记本、智能眼镜之间使用 AI 时，能延续此前的对话和信息，同时仍保持接近“只在设备上处理”的隐私水平。目前这是官方公布的技术更新，具体上线时间、可用设备和功能范围原文并未说明。