2026 年 10 月 21 日，PHP 项目发布紧急更新，修复两个代号 PHP2Shell 的严重漏洞（CVE-2026-109618 和 CVE-2026-109619），严重程度评分均为 CVSS 9.2。问题出在 PHP 自身：当请求处理中途失败时，PHP 没有把内部状态清理干净，攻击者可以故意触发失败，再借留下的残留数据，在无需登录的情况下远程执行任意代码，甚至泄露密码、令牌和 API 密钥。修复办法只有升级 PHP，已发布 8.5.12、8.4.27、8.3.36、8.2.35 四个补丁版本；8.1 及更早版本没有官方补丁，需要自行打源码补丁或用发行版回溯修复。漏洞细节在补丁发布前已泄露，Cloudflare 已观测到攻击，荷兰众议院和英国 NCSC 一度下线网站预防。普通用户和企业应尽快升级 PHP 或通过系统包管理器安装修复版本，用容器的要重新构建镜像，暂时无法升级的只能用官方建议的配置降低部分攻击路径风险。
展开详情收起详情：CVE-2026-109618 与 CVE-2026-109619：PHP2Shell 严重漏洞——它是什么、该怎么办⌄
Dynatrace Blog
原文发布：2026-10-22 22:48收录：2026-10-23
Dynatrace 宣布成为“SpaceX 超级智能合作伙伴网络”的启动伙伴，并推出一个已通过验证的官方插件，上架 Cursor 插件市场。原来开发者用 Cursor 这类 AI 编程工具写代码虽然更快，但代码编辑器和线上生产环境是割裂的：线上出故障时，开发者得先切到别的监控门户拼凑线索，才能弄清发生了什么、为什么发生。这次的做法是把 Dynatrace 的生产环境数据（由 Grail、Smartscape 和确定性因果根因分析提供）通过插件接进 Cursor，让 AI 代理和开发者直接在写代码的地方查看线上服务状态、依赖关系和根因。对使用 Cursor 的团队来说，排查线上故障、判断某个漏洞在真实运行环境中是否有影响、分析性能瓶颈，都可以不用离开编辑器，平台团队也能通过 Cursor 的团队市场分发插件并保留管理权限。目前该插件已作为受支持的集成可用，具体配置（平台令牌、MCP 服务器、Dynatrace skills 和 dtctl）需参考配套技术博客。
文中可用工具
- CursorAI 原生编程工作区，开发者在此写代码并与 AI 代理协作
- Dynatrace提供端到端可观测性，把生产环境上下文交给 AI 代理
- Grail为可观测性分析提供数据
- Smartscape映射系统之间的依赖关系
- Dynatrace Intelligence提供确定性的因果根因分析
- Dynatrace plugin已通过验证的 Cursor 市场插件，把生产上下文带进 Cursor
- MCP server技术博客中提到的配置组件，原文未说明具体用途
- Dynatrace skills技术博客中提到的配置组件，原文未说明具体用途
- dtctl技术博客中提到的配置组件，原文未说明具体用途
展开详情收起详情：Dynatrace 与 Cursor 打通 AI 原生开发的闭环⌄
Dynatrace Blog
原文发布：2026-10-23 04:21收录：2026-10-23
Datadog 推出 Agent Observability 的新功能，帮企业搞清楚 AI 智能体的钱花在了哪里。原来云厂商账单只按 API 密钥和模型统计，看不出是哪个应用、哪一步工作流在烧钱，所以成本一涨就很难查原因——可能是流量变大、换了更贵的模型，也可能是缓存没用上、对话历史每轮都重发。现在这个工具把估算的 AI 成本直接挂到具体应用和请求链路上，打开 Cost 页面就能按应用对比花费和效率（比如每次请求成本、缓存命中率），还能钻取到单次最贵的调用，看它的执行链路。它还会自动指出可省钱的点，比如未被缓存的提示词前缀，估算能省多少并给出修改建议。对读者来说，这意味着 AI 成本问题能更快定位到技术原因，而不是对着账单猜。目前材料只说明这是 Datadog 的产品能力介绍，未说明具体定价和正式上线时间。
文中可用工具
- Datadog Agent Observability把 AI 智能体的估算成本关联到具体应用和调用链路，帮助定位花钱多的环节
- Cost page按应用、供应商或自定义标签查看 AI 花费和效率指标
- Cost Savings Opportunities找出可避免的花费并估算潜在节省、给出修复建议
- Most Expensive LLM Calls table按估算总成本给 LLM 调用排名，方便查看最贵的请求
- Execution Graph展示智能体、LLM 调用、工具和评估之间的连接关系
- Datadog Application Performance Monitoring (APM)与 Agent Observability 关联，把 AI 操作放回更完整的应用调用链中排查
展开详情收起详情：用 Agent Observability 优化 AI 成本⌄
Datadog Blog
原文发布：2026-10-22 08:00收录：2026-10-23
Snyk 推出了 Evo Remediation Agent 的开放预览版，它能自动处理开源依赖漏洞：按团队设定的仓库范围和严重级别，智能体在托管沙箱里制定升级方案、修改代码，并用构建、测试和重新扫描验证结果，然后给开发者开拉取请求，由开发者决定是否合并。这解决的是漏洞修不完、和开发日常工作抢时间的问题。官方在 307 个依赖升级任务上测试，该工具四项检查全部通过的比率为 90.2%，而配合 Snyk 发现结果的 Claude Code 为 77.5%，单用 Claude Code 为 59.6%。目前只是开放预览，需申请租户权限，有每日修复额度限制，且仅支持开源漏洞，智能体不会自动合并。
文中可用工具
- Evo Remediation Agent自动制定并验证依赖漏洞修复方案、开拉取请求的智能体
- Evo Agentic AppSec承载修复活动的应用安全平台
- Snyk Code检测源代码漏洞并生成和检查修复建议
- Claude Code作为基准对比的编程智能体
- VulnBump测试可合并修复率的基准
展开详情收起详情：用智能体自动修复把漏洞积压变成拉取请求⌄
Snyk Blog
原文发布：2026-10-22 12:00收录：2026-10-23
PHP 项目在 2026 年 10 月 21 日发布了 8.5.12、8.4.27、8.3.36、8.2.35 四个版本，修复两个严重漏洞：攻击者不需要登录、也不用任何账号，只要发送恶意网页请求，就可能直接在服务器上运行自己的代码，危害极大。问题出在 PHP 引擎处理请求的流程里，而不是某个第三方包，所以升级 PHP 本身才是解决之道。官方说没有完全规避的办法，唯一安全的选择就是升级；如果仍用 8.1 或更早版本，需要找系统发行版或长期支持厂商拿回补丁，或者直接升级。另外 10 月 23 日补充了一个编号 CVE-2026-115560 的变体绕过问题，只有应用在运行时动态切换 session 序列化方式才可能受影响，普通部署可以暂时不用紧张。读者应尽快确认每台机器实际运行的 PHP 版本，不要只看扫描结果。
展开详情收起详情：PHP 修复两个无需认证的严重 RCE 漏洞（CVE-2026-109618、CVE-2026-109619），并更新 CVE-2026-115560⌄
Snyk Blog
原文发布：2026-10-26 12:00收录：2026-10-23
Google 宣布将把内部支撑 Gemini 智能体的计算基础设施，以 Agent Compute Engine 的形式开放给 Google Cloud 用户预览，时间在今年晚些时候。过去 Google 自家智能体用的这套系统，需要兼顾启动快和隔离安全：传统虚拟机太慢，容器又不够隔离，写代码的智能体还需要 root 权限和独立内核。现在每个智能体都跑在独立的微型虚拟机里，可以挂起、恢复，且沙箱内不放任何密钥，访问外部服务要经过代理校验身份和授权。对开发者来说，以后跑长时间、高权限的智能体任务可以少操心隔离和安全问题。目前只宣布了预览计划，具体定价和上线时间原文未说明。
文中可用工具
- Agent Compute EngineGoogle 给每个 AI 智能体提供隔离微型虚拟机的云服务，尚未开放，仅宣布预览计划
- Agent SandboxGoogle 在 GKE 上提供的开源沙箱项目托管版本，用于运行智能体
- GKEGoogle Kubernetes Engine，Google 的托管 Kubernetes 服务，Agent Sandbox 和 Agent Substrate 运行于此
- Agent SubstrateGoogle 为 GKE 提供的开源智能体运行时，今年五月首次公布
- Gemini Enterprise Agent PlatformGoogle 售卖代码执行和计算机操作沙箱的平台
- FirecrackerAWS 开源的微型虚拟机技术，E2B 用它运行沙箱
- E2B向开发者提供智能体沙箱的创业公司，支持任意云
- Daytona提供智能体沙箱的创业公司，七月加入微型虚拟机沙箱
- Bedrock AgentCoreAWS 的智能体沙箱服务，每个会话独立微型虚拟机
- Cloud HypervisorAgent Compute Engine 微型虚拟机所基于的开源虚拟机监视器
- Agent Gateway在沙箱外校验用户授权与沙箱身份后再注入凭据的网关
- Antigravity原文仅提到 Agent Compute Engine 最初也服务于它，用途未说明
展开详情收起详情：Google 将支撑 Gemini 智能体的基础设施开放为云服务⌄
The New Stack
原文发布：2026-10-22 21:00收录：2026-10-23
传统企业安全靠“先验证身份、再检查权限”就能管住软件，但 AI 智能体不一样：它会自己理解目标、挑选工具、创建子代理并动手执行，用的还是从人那里继承来的账号权限。问题在于，这些权限可能允许它做人类从没打算让它做的事，而且它的执行路线会随时变化，光在门口设一道关卡拦不住。文章提出用“观察、执行、构建、部署”四个环节组成的持续安全生命周期，在每次具体操作前判断“这个代理、代表谁、要做什么、是否符合策略”，并先观察真实行为再逐步收紧限制。对读者来说，这提供了一个治理企业内 AI 代理的新思路，但文中没有说明具体产品或落地时间。
展开详情收起详情：AI 智能体安全是一个生命周期，而非守门人⌄
The New Stack
原文发布：2026-10-22 22:00收录：2026-10-23
作者在 10 月 17 日 DeepSeek 发布 V4.1-Flash-1017 后，拿它和 10 月 7 日 Anthropic 推出的 Claude Haiku 5.5 做了三轮实测：修 bug、写数据库查询、给 400 条报错分类。两家官方基准分（DeepSeek 42.3、Haiku 39.2）并非同场对测，作者想自己验证。结果两种模型准确率很接近，DeepSeek 在修 bug 和分类上略胜，查询打平；在所用设置下 DeepSeek 总花费约 0.07 美元，Haiku 约 0.30 美元，差距主要来自一个超长提示词把 Haiku 推到了更高价位；Haiku 在两次工具类任务里更快。注意：文章只跑了各一次，价格受分词、缓存和接入渠道影响，Haiku 的提示缓存默认关，开启后成本对比可能变化；两者都是厂商自报成绩。
文中可用工具
- DeepSeek V4.1-Flash-1017DeepSeek 的开放权重模型，可通过 API、OpenRouter 或从 Hugging Face 下载自部署
- Claude Haiku 5.5Anthropic 面向高吞吐任务（分类、摘要、数据库查询）的最快模型
- OpenRouter本次测试统一调用的模型接入服务
- Hugging Face可下载 DeepSeek 开放权重模型自行部署
- Terminal-Bench 4.0两家厂商引用的基准测试之一，文中仅给出分数
展开详情收起详情：DeepSeek V4.1-Flash-1017 对比 Claude Haiku 5.5：价格更低、准确率更高⌄
The New Stack
原文发布：2026-10-22 22:22收录：2026-10-23
安全研究人员用 AI 模型（如 OpenAI 的 GPT-5.6 Sol 和 Google 旗下 Wiz 的工具）在 PHP 编程语言里发现了两个严重漏洞，合称 PHP2Shell，攻击者可借此在服务器上执行恶意代码。PHP 官方紧急为 8.2 到 8.5 版本发布修复，Cloudflare、Automattic 等公司也上线了防护，但 Chainguard 在约定披露时间前六小时就抢先发布补丁镜像，引发 PHP 基金会不满。这件事暴露出一个新问题：AI 让找漏洞变得容易，而评估和修复仍需时间和专家，小项目更难应对。 Anthropic 的研究也显示 Claude 在 25 个开源项目里找出 493 个安全问题。对普通读者来说，这意味着你用的网站和服务可能更频繁地收到紧急安全更新，也提醒开源维护者的压力正在加大。
文中可用工具
- GPT-5.6 SolOpenAI 的模型，安全公司 Calif 用它发现了 PHP 的一个漏洞
- ClaudeAnthropic 的模型，其研究在 25 个开源项目中找出 493 个安全问题
- ComposerPHP 的依赖管理工具，原文仅提到其创建者兼联合维护者身份
- WAFWeb 应用防火墙，用于拦截针对漏洞的攻击
展开详情收起详情：PHP 安全风波只是预演：AI 挖漏洞的速度快过维护者的修复速度⌄
The New Stack
原文发布：2026-10-22 22:35收录：2026-10-23
文章讨论 AI 智能体上线后该由谁负责的问题。凌晨两点零七分，一个智能体开始出错：应用还在跑，但因为下游接口报错，请求开始超时；它已经重试两次，消耗的 token 比平时多，响应时间大约翻倍。作者认为，这时该问的不是“用哪个模型”，而是“现在谁负责这个系统”。解决办法是像对待普通线上服务一样管理智能体：明确负责团队和上报渠道，用白名单限制它能调用的工具（默认拒绝），给执行步数和工具调用次数设上限，并记录延迟、模型、成败、token 用量和请求 ID 等可观测数据。这样读者能把智能体从“某处跑的试验”变成可问责、可监控、出问题有人接的服务，降低运维风险。
展开详情收起详情：谁来给 AI 值班？智能体归属权的未解危机⌄
The New Stack
原文发布：2026-10-22 23:00收录：2026-10-23
安全公司 Calif 借助 OpenAI 的 Patch the Planet 计划，用一个 AI 模型在 PHP 语言里找到可远程执行代码的严重漏洞，Wiz 等也独立报告了同一问题。PHP 维护者其实在 2024 年就注意到相关内存耗尽异常的迹象，但直到今年八月才看清完整危害，随后发布 8.2.35、8.3.36、8.4.27、8.5.12 等修复版本。问题在于补丁正式发布前细节已外泄，Chainguard 提前六小时多公开了打好补丁的镜像，引发是否违反协调披露禁发期的争论。对读者来说：若运行公开可访问的 PHP 服务，应尽快升级到修复版本，并假定可能已被探测甚至入侵。
文中可用工具
- Patch the PlanetOpenAI 的漏洞发现计划，Calif 在其中用 AI 找出 PHP 漏洞
- GPT-5.6 SolCalif 用来发现远程代码执行路径的 AI 模型
- WordPress提醒站长升级 PHP，但漏洞本身不需要更新 WordPress
- Chainguard提前发布含修复的容器镜像，引发禁发期争议
- testing harnessChainguard 用来独立复现该漏洞的测试工具
展开详情收起详情：AI 发现 PHP 严重漏洞，但更大的问题始于 2024 年⌄
The New Stack
原文发布：2026-10-22 23:01收录：2026-10-23
在 2026 年北美 PyTorch 大会上，Google 开源了 TorchTPU，让 PyTorch 代码能直接跑在 Google 的 TPU 芯片上，已在 GitHub 发布；AWS 则推出 TorchNeuron 公开测试版，让 PyTorch 模型能跑在其 Trainium 芯片上。过去 PyTorch 开发者基本绑定 Nvidia 的 CUDA 生态，换芯片往往要大量改代码，这两个项目把迁移简化到改几行代码甚至只改一个配置。不过官方也说明，想达到最高性能仍需针对新芯片专门调优，例如 TorchTPU 默认分布式方案可能比优化方案慢约 30–40%。对开发者来说，这多了可选的硬件路线，但现阶段迁移容易、跑出极致性能仍不简单。
文中可用工具
- TorchTPUGoogle 开源的 PyTorch 后端，让现有模型不经 JAX 直接跑在 TPU 上
- TorchNeuronAWS 开源的 PyTorch 后端，让模型跑在 Trainium 芯片上，目前为公开测试版
- vLLM原文提及的推理框架，与 TorchTPU 有集成
- SGLang原文提及的推理框架，与 TorchTPU 有集成
- llm-d原文提及的集成项目，具体用途原文未说明
- TorchTitan原文提及的 PyTorch 训练项目，可用于 TorchTPU 的生产级方案
- Ray原文提及的分布式计算框架，与 TorchTPU 有集成
- TorchRec原文提及的推荐系统库，与 TorchTPU 有集成
- LiteRTGoogle 贡献给 PyTorch 生态的运行时，具体用途原文未说明
- Hugging Face原文提及与 Google 有集成，具体形式原文未说明
- NKIAWS Trainium 和 Inferentia 的底层编程语言与编译器，用于写自定义算子
- Pallas原文建议用于 TorchTPU 高性能场景的 kernel 方案
展开详情收起详情：Google 与 AWS 为 PyTorch 开辟 Nvidia 之外的新路径⌄
The New Stack
原文发布：2026-10-22 23:23收录：2026-10-23
OpenAI 本周公布了两项基准测试结果。在自家的 COBOL 迁移测试中，新模型 GPT-6.1 Sol 在低推理强度下准确率达到 86.6%，而上一代 GPT-5.6 Sol 只有 5.4%，成本还低了 39%；提高推理强度后准确率可达 97.9%。COBOL 是支撑大量银行和 ATM 系统的老旧编程语言，长期缺少代码和文档，AI 很难学好，所以这次进步幅度显得很大。另一项叫 MultiLangBench 的测试在 GitHub 上公开了，考察模型用 20 种语言从零搭建一个兼容 SQLite 的数据库引擎，旗舰模型 GPT-6 Astra 平均通过率 87.4%，上一代仅 26.8%。但要注意：COBOL 测试的题目和数据集没有公开，外部开发者无法独立验证，OpenAI 也承认迁移到生产系统仍需专家审查。
文中可用工具
- GPT-6.1 SolOpenAI 的新模型，用于把 COBOL 程序迁移到其他语言
- GPT-5.6 Sol上一代模型，作为对比基线
- GPT-6 AstraOpenAI 的旗舰模型，在 MultiLangBench 中平均通过率最高
- GPT-6 Luna成本更低的模型选项，在 MultiLangBench 中通过率较低
- MultiLangBenchOpenAI 公开在 GitHub 上的基准，测试模型用 20 种语言从零构建兼容 SQLite 的数据库引擎
- Real-SWE 1.1使用私有代码库的软件工程基准，文中的排名参考
- Claude CodeAnthropic 的工具，文中提到可用于 COBOL 现代化
- Claude Opus 5.5在 Real-SWE 1.1 中排名第一的模型
展开详情收起详情：OpenAI 的 COBOL 迁移评分出现惊人跃升⌄
The New Stack
原文发布：2026-10-22 23:34收录：2026-10-23
OpenAI 把自己提出的一套“通用大模型接口规范”Open Responses 捐给了开源组织 Agentic AI Foundation（AAIF，隶属于 Linux 基金会）。问题是：各家大模型厂商的接口虽然都提供消息、工具调用等同类功能，但写法各不相同，开发者每换一家模型就得重写对接代码。Open Responses 把这些基础接口统一成一套标准，切换模型时不用再逐家适配。目前 Vercel AI Gateway、Databricks Model Serving 已经实现该规范，AWS、Ollama、Hugging Face、Nvidia 等表示支持，但 Anthropic 和 Google 尚未采用。规范文件本身已公开，由 AAIF 作为中立平台继续推进。
文中可用工具
- Open Responses统一的 LLM 核心 API 调用规范，让开发者跨厂商切换模型时少写适配代码
- Agentic AI FoundationLinux 基金会下托管智能体相关开源项目的中立组织
- MCPAAIF 托管的智能体协议之一，原文未说明具体用途
- A2AAAIF 托管的智能体协议之一，原文未说明具体用途
- AGENTS.mdOpenAI 捐赠的规范，用于给编程智能体提供项目专属指令
- gooseAAIF 托管的开源 AI 智能体项目，原文未说明具体用途
- agentgatewayAAIF 托管的项目之一，原文未说明具体用途
- Agent RouterAAIF 托管的项目之一，原文未说明具体用途
- OpenSandbox原文仅提及加入 AAIF，未说明具体用途
- Agent SkillsAnthropic 的项目，原文仅提及加入 AAIF，未说明具体用途
- OpenEvHugging Face 的智能体环境框架，原文仅提及加入 AAIF，未说明具体用途
- Vercel AI Gateway已实现 Open Responses 规范的模型接入服务
展开详情收起详情：OpenAI 将通用 LLM API 规范 Open Responses 捐赠给 Agentic AI Foundation⌄
The New Stack
原文发布：2026-10-23 00:01收录：2026-10-23
金融科技公司 Ramp 花了好几个月试用市面上的托管 Agent API、开源框架和第三方平台，最后决定自己造。他们用六周时间做出了第一版内部 Agent 运行框架 Laminar，现在支撑公司所有 Agent 产品。原因是不想被单一模型供应商绑死，希望按成本、速度和效果自由切换模型，也想要更好的调试和观察能力，内部自建还能直接和产品工程师协作、不用等外部厂商改代码。做法上，它把对话会话和运行代码的沙箱分开，凭据和调度放在沙箱外；Agent 默认异步工作，不必每步都等完成；还用一个连接器服务集中管理认证、权限和工具调用。LangChain CEO 公开点赞其中多项设计，认为这反映了 Agent 基础设施的走向，但原文并未说明 Laminar 是否对外发布或开源。
文中可用工具
- LaminarRamp 自建的内部 Agent 运行框架，统一负责执行、沙箱、可观测性和异步工作流
- Ramp InspectRamp 的云端编程 Agent，运行在 Laminar 上
- GlassRamp 负责长时间协作工作的 Agent，运行在 Laminar 上
- Deep AgentsLangChain 正在开发的 Agent 框架，采用类似沙箱即工具等设计
- Connectors ServiceRamp 的共享服务，集中管理认证、凭据、访问控制和工具执行
- Open SWELangChain 的开源编程 Agent，在框架层加入按任务复杂度选模型的路由
- GLM-5.3-FlashOpen SWE 路由中最简单任务使用的模型
- GPT-5.6 SolOpen SWE 路由中中等任务使用的模型
- GPT-6 AstraOpen SWE 路由中最复杂任务使用的模型，此前也用于所有任务的对照
展开详情收起详情：Ramp 六周自建 AI Agent 运行框架，LangChain CEO 称这是更大变革的一部分⌄
The New Stack
原文发布：2026-10-23 00:31收录：2026-10-23
Letta 发布了一个叫 FrontierMemory 的新测试，专门看 AI 智能体能不能把过去的经验真正用在后面的任务上，而不只是把信息存起来。他们让五个智能体系统先看以前的工作记录，再自己总结记忆去完成新任务，结果分数从 73.3% 到 26.7% 不等：Letta Dream 最高，Prime Agent 60%，OpenAI Agents SDK 40%，Claude Managed Agents 33.3%，Hermes Agent 最低。在模型层面，Claude Opus 5.5 和 GLM-5.3 并列第一（73.3%），但 GPT-6.1 Sol 虽然只有 60%，每个任务只要约 0.77 美元，远低于 Opus 5.5 的 2.80 美元和 GLM-5.3 的 3.58 美元。对开发者来说，这说明同样的模型换个框架效果可能差很多，也可以考虑用贵模型生成记忆、用便宜模型干活。不过该测试目前只有 15 个任务、每个只跑一次，单个结果就能让分数浮动约 6.7 个百分点，且暂不涉及边做边更新记忆，后续版本才计划加入更长任务和在线更新。
文中可用工具
- FrontierMemoryLetta 发布的基准测试，衡量智能体能否从过去经验中学习并用于新任务
- Letta DreamLetta 的智能体框架，在本次测试中得分最高，用于生成和利用记忆
- Prime Agent参与测试的智能体框架，得分 60%
- OpenAI Agents SDKOpenAI 的智能体开发框架，参与测试得分 40%
- Claude Managed AgentsAnthropic 的托管智能体方案，参与测试得分 33.3%
- Hermes Agent参与测试的智能体框架，得分最低为 26.7%
- Letta CodeLetta 的编码环境，用于测试各模型生成的记忆在任务中的效果
- OpenClaw多人在线环境，其账号表示希望以插件形式参与记忆测试，目前尚未接入
展开详情收起详情：五个 AI 智能体框架参加同一项记忆测试，结果差距悬殊⌄
The New Stack
原文发布：2026-10-23 02:34收录：2026-10-23
GitHub 漏洞赏金团队在网络安全意识月采访了研究员 @r31n。他专门研究 GitHub Enterprise Server，多次发现高危问题，报告里都附带可用的概念验证和清晰的复现步骤，让工程团队能更快定位并修复。他说自己偏爱把几个看似无害的小问题串成完整攻击链，比如一个开放重定向配上会跟随跳转的 SSRF。日常学习靠安全博客、漏洞分析和会议演讲，但真正掌握要靠亲手复现。他认为 AI 降低了入门门槛，也确实是效率放大器，但决定研究质量的是验证和真实影响，而不是工具。
展开详情收起详情：漏洞赏金如何磨砺一位研究员的安全技能⌄
GitHub Blog
原文发布：2026-10-23 01:21收录：2026-10-23
一位开发者用 Claude Opus 5.5 做出了七个 Adobe 应用的开源替代品，并在 Reddit 上宣传，声称大约一个月内就能达到接近 100% 的功能对齐。但随后他在 Hacker News 上承认，这个项目“远未准备好”。项目自己的路线图显示，它目前只有 45% 能满足实际工作需求，要达到完全对齐还需 2300 到 4100 个智能体小时。也就是说，这些工具目前仍处于早期阶段，暂时还不能当作 Adobe 的可靠替代品使用。
文中可用工具
- Claude Opus 5.5用于构建开源 Adobe 应用替代品的 AI 模型
展开详情收起详情：用 AI 打造 Adobe 克隆产品的开发者称其“远未准备好”⌄
InfoQ Architecture & Design
原文发布：2026-10-22 15:41收录：2026-10-23
作者 Peihao Yuan 介绍了一套用于灾难恢复分析的工作流：AI 智能体只负责生成受限的 SQL 或 Python 代码，真正的计算交给嵌入式数据库 DuckDB，从 Parquet 文件中算出可复现的结果，再由智能体解读这些结果。文章的核心观点是：AI 改变的是人和数据打交道的方式（接口层），而不是负责算数的查询引擎本身。文中还讲了如何把“生成”和“计算”分开以保证结果可重放，并给出四个判断信号，帮读者决定什么时候用嵌入式引擎就够、什么时候值得上托管的湖仓方案。
文中可用工具
- DuckDB嵌入式分析数据库，负责从 Parquet 文件算出可复现的结果
- Parquet列式文件格式，用作分析的数据来源
展开详情收起详情：AI 改变的是数据接口，而非查询引擎⌄
InfoQ Architecture & Design
原文发布：2026-10-22 17:00收录：2026-10-23
Manju Rajashekhar 做了一场演讲，讲怎么用 Actor 模型解决生产环境中 AI 智能体运行时的麻烦。Actor 模型可以简单理解成：每个“小工人”（Actor）只管理自己的状态，彼此只靠发消息协作，谁出问题就单独处理。演讲把智能体看成分布式系统，围绕状态由谁持有、消息传递、写穿状态（状态一变就立刻写入持久存储）和监督边界（谁来发现并处理故障）来设计，从而应对失败、任务续接和可动态变化的执行图。这样智能体工作流就能从容易崩溃的演示，变成更稳定、可恢复的架构。目前只是演讲分享，材料没有说明有可用的代码或产品。
展开详情收起详情：演讲：面向智能体的 Actor 模型——生产级 AI 的实践模式⌄
InfoQ Architecture & Design
原文发布：2026-10-22 19:00收录：2026-10-23