Jimmy Song | 宋净超的 RSS 预览

智能体设计模式：Agentic Design Patterns 中文版电子书分享

2025-10-12 20:07:50

我在两个月前完成了对《Agentic Design Patterns》的中文翻译工作，使用了一系列 AI 辅助工具来加速翻译过程。总体上我觉得译文比较“信达雅”，术语处理也比较准确，适合对 AI 智能体（agent）感兴趣的读者快速上手与参考。

为什么值得一读

本书系统梳理了智能体（Agent）设计领域的 21 种常见模式，涵盖提示链、路由、并行化、反思、工具使用、规划、多智能体协作、记忆管理等内容，并配有可运行的示例代码与配图说明，适合不同背景的读者深入理解和实践。

内容全面：覆盖主流智能体设计模式，理论与实践结合。
实例丰富：每章均附有示例代码，便于动手实践。
易读实用：网页在线阅读体验佳，亦可下载 PDF 离线查阅。

在线阅读中文版

翻译方法与原则

在翻译过程中，我结合 AI 辅助工具与人工校对，确保译文“信达雅”，术语统一，表达自然。主要流程如下：

AI 初稿：利用 AI 工具快速生成初译文本。
人工校阅：逐章校正语序与表达，确保中文读者易于理解。
术语统一：建立术语表，保证技术名词前后一致。

如有建议或发现不当之处，欢迎在页面评论区反馈。

主要内容亮点

为便于读者快速了解书中核心内容，以下简要列举部分代表性设计模式：

提示链（Prompt chaining）：将复杂任务拆解为多个子步骤，每步输出作为下一步输入，提升结构化处理能力。
路由（Routing）：根据意图或状态分发请求至不同子流程或工具，适用于多能力系统。
并行化（Parallelization）：并行运行多个候选策略并汇总结果，提高可靠性与覆盖面。
反思（Reflection）：引入自检、批评者或评分机制，持续优化输出质量。
工具使用（Tool use）：规范智能体与外部工具（如数据库、API）的交互方式。

更多章节与示例请参见在线书籍目录页面。

适用人群

本书适合以下读者群体：

AI 工程师与研究者：希望将大模型集成到更复杂的智能体系统中。
产品经理与技术经理：关注不同设计模式的权衡与应用场景。
AI 爱好者与学生：通过示例代码快速上手与复现智能体设计。

获取方式与资源

英文原文： Google Doc
中文版在线阅读： https://jimmysong.io/book/agentic-design-patterns/
中文版 PDF：点击下载 PDF （约 5.8 MB，288 页）

下载 PDF 版本

内斗与外侵：从《武训传》与《七武士》看中日文明的分野

2025-10-09 12:08:40

最近我看了《武训传》这部 1951 年的电影，再对比黑泽明的《七武士》，这两部电影都上映于 1950 年代，通过对比两部电影，剖析中日文明在地理、政治、文化与社会心理等方面的深层差异，揭示中国“内斗”与日本“外侵”背后的文明动能与历史宿命。

引言

1951 年，中国拍出了《武训传》；1954 年，日本拍出了《七武士》。两部电影几乎在同一时代诞生，一个讲述乞丐办学的故事，一个描绘浪人赴死的传奇。前者强调忍耐与善意，后者突出行动与牺牲。它们都在二战后亚洲的动荡背景下，思考人在崩溃时代中的信念选择，却给出了截然不同的答案。这不仅是艺术的分歧，更是文明的分野。

地理决定论：封闭与匮乏的两种命运

中国是一个自然地理封闭的盆地，四周被山海高原环绕，可耕地集中于黄河、长江流域。这样的地理环境造就了“易守难攻”的文明特性，农业足以养活人口，却难以支撑对外扩张。因此，中国历史的主线是“守成”而非“征伐”。

与之相对，日本作为岛国，多山且资源贫乏，外贸与掠夺成为其生存方式。“向外取”几乎成为地理本能，生存焦虑塑造了进取文化，对外扩张成为民族动能的出口。

这种地理差异，决定了中国文明趋于“内部稳态”，而日本文明则形成“外部竞争”的格局。

政治结构：中央集权与竞争分权

地理环境影响了政治结构。中国两千年的皇权体制，以“防乱”为最高政治目标，“乱”比“弱”更可怕。所有政治能量都被导向内部控制与秩序维系，农民起义、文字狱、政治运动等内部震荡成为历史常态。

日本则长期处于分权状态。战国时代的割据竞争带来生存压力与创新动力，明治维新后，这种竞争被国家吸收为“民族竞争”，从内部纷争转化为对外扩张。

因此，中国的政治能量在内部循环，日本的政治能量则向外爆发。

文化逻辑：儒家伦理与武士道信仰

文化层面上，儒家文化强调秩序、礼仪与道德修身，理想人格是“温良恭俭让”，而非“敢死敢为”。“苟全性命于乱世，不求闻达于诸侯”，体现的是以生存、修身为德的智慧。

日本的武士道则崇尚“名誉高于生命”。“武士道とは死ぬことと見つけたり”——死亡不是失败，而是使命的完成。这种文化心理让日本人形成了“行动信仰”，不论成败，只问是否尽忠。

中国重“仁义”，日本重“责任”；中国求“和”，日本求“决断”。两者都讲“道”，但方向完全相反。

社会心理：秩序焦虑与生存焦虑

社会心理层面，中国社会最怕乱，日本社会最怕弱。由此：

中国通过“整风”“清洗”“运动”维系秩序；
日本通过“维新”“扩张”“征服”追求力量。

这两种心理都源自集体的不安全感：一个怕失控，一个怕落后。中国通过“内部斗争”释放压力，日本则通过“外部战争”寻找意义。

中国的革命是“自我更新的灾难”，日本的战争则是“他人毁灭的代价”。

文明后果：自毁与外毁

在上述多重因素作用下，中日文明分别走向了不同的历史结局。

国家	动能方向	典型事件	结果	历史教训
中国	内向性（自我撕裂）	太平天国、义和团、大跃进、文革	文明断层、信任崩塌	理想主义加集权 = 灾难
日本	外向性（对外扩张）	明治维新、侵华、太平洋战争	他国毁灭、自身覆亡	行动崇拜失衡 = 灾难

表 1: 中日文明动能与历史后果对比

一个文明在秩序中自毁，一个文明在野心中灭亡。历史的讽刺在于，他们都在试图“拯救自己”，却都被自身的文化逻辑所囚禁。

艺术镜像：从《武训传》到《七武士》

电影往往比历史更能揭露文明的潜意识。《武训传》和《七武士》正是这种潜意识的镜像。

《武训传》：被时代吞噬的善良

武训，一个靠乞讨筹钱办学的民间教育者，相信知识能救人，善意能改变世界。但他不革命、不斗争，只修己度人。在政治狂热的年代，这种“非政治的善”成了原罪。电影上映后遭到批判，武训被指“麻痹群众”“宣扬忍耐”。

他的悲剧不仅是个人的不幸，更是一个文明不再相信“温柔的力量”的象征。当社会只认可“斗争式正义”，善良就成了最危险的立场。

《七武士》：行动即意义的信仰

黑泽明笔下的七名浪人，明知无利可图、九死一生，仍选择出战。他们的行为不是理性的，而是信仰的。

“所谓武士道，就是随时准备去死。”

四人战死，他们的死被拍得庄严而宁静。这不是悲剧，而是“完成”。那种接受命运的平静，是日本文化中“物哀”之美的体现。

结尾处，幸存的武士望着田间劳作的农民，说出那句：

“胜利的，不是我们，而是农民。”

这是对历史的清醒，也是对命运的顺从。个体被共同体吸收，英雄被集体秩序吞噬——正是日本社会“牺牲即秩序”的隐喻。

《武训传》与《七武士》的文明对照

在电影层面，两部作品展现了中日文明的精神分野。

电影	国家	主角精神	社会态度	象征意义
《武训传》	中国	忍耐、善良、道德自省	被批判、被压抑	内向的理想主义与道德孤立
《七武士》	日本	勇敢、牺牲、行动信仰	被赞颂、被传承	外向的责任伦理与悲壮宿命

表 2: 《武训传》与《七武士》精神对照

一个讲“做好事的人被否定”，一个讲“赴死的人被纪念”。这就是文明心理的分水岭：一个崇尚温和，一个崇尚行动；一个沉思，一个冲动。

结语：苟全与赴死之间

中国的悲剧在于温良的善被视为软弱，日本的悲剧在于勇敢的行动被体制利用。武训的善，孤独到无人理解；武士的勇，崇高到被神化。

一个文明把“活着”视为智慧，另一个文明把“死去”视为荣耀。而真正成熟的文明，应当能在活着的善意与行动的勇气之间取得平衡。

或许人类真正需要的，不是更勇敢的武士，也不是更悲悯的武训，而是能让善良与勇气同时存在的理性社会。

总结

本文通过对比《武训传》和《七武士》，从地理、政治、文化、社会心理等多维度剖析了中日文明的深层差异。中国文明倾向于内部秩序与自我撕裂，日本文明则以外部扩张与行动信仰为核心。两种文明各有悲剧根源，唯有在善良与勇气之间取得平衡，才能走向真正的成熟。

参考文献

山本常朝，《叶隐闻书》，1716
诸葛亮，《出师表》
史景迁，《太平天国的幽灵》，生活·读书·新知三联书店，2012
黑泽明，《七武士》，1954
《武训传》，1951
黄仁宇，《万历十五年》，生活·读书·新知三联书店，1982
司马辽太郎，《坂上之云》，文艺春秋社，1971
张英进，《中国电影与国家意识》，牛津大学出版社，1999

AI 资源库更新：收录项目超 500 个，新增评分与展示优化

2025-10-05 12:09:16

国庆期间我对 AI 资源库的多项优化，包括资源规模突破、过滤与展示体验提升，以及全新引入的项目健康评分系统，旨在帮助读者更高效地筛选和判断优质 AI 项目。

AI 资源库地址： https://jimmysong.io/ai/

提交 AI 资源与反馈

概览与资源分布

AI 资源页经过多轮整理，目前已收录超过 500 条资源，其中开源项目（含 GitHub 仓库）超过 400 个。资源类型涵盖教程、工具、论文实现、模型仓库等，支持中英文双语索引（/zh/ 与 /en/），方便不同语言用户检索。

随着资源数量的增长，目录内容愈发全面，但也带来了“信息过载、难以抉择”的新挑战。为此，后续的优化工作主要聚焦于提升筛选效率和信息可读性。

交互与显示体验优化

为解决“资源太多不好选”的问题，本次更新重点优化了前端交互与展示方式：

优化分类：资源分类体系已对齐最新 AI 行业主流分法，涵盖“智能体与编排”“模型与基础”“训练与微调”“推理与服务”“数据与检索”“开发工具与 SDK”“评估与监控”“应用与产品”“界面与集成”“学习资源”等 10+ 维度。
过滤器增强：改进了列表页的过滤器逻辑，支持按类别、标签、是否开源（GitHub）、语言等多维度组合筛选，有效减少无关结果。
卡片与样式调整：优化项目卡片布局，突出标题、简要描述和主要标签。卡片底部新增状态徽章与评分占位，提升辨识度。

这些优化让用户可以更快定位到感兴趣的项目，同时一目了然地了解项目的基本状态。

引入评分系统：综合评判项目健康度

随着资源数量激增，仅靠标签已难以直观判断项目优劣。因此，资源列表页新增了「综合评分」字段，帮助读者快速评估项目的活跃度与健康状况。

评分系统的核心理念在于：高 Star 并不等于高活跃度，真正值得关注的是持续维护、社区参与度高的项目。综合评分将“人气 / 活跃度 / 社区参与”三项信息合成为 0-100 的分值，便于横向比较。

评分系统设计与实现

为确保评分系统的科学性与可扩展性，相关设计与实现细节已在文档中详细说明。以下为简要摘要，详细内容可参考文末文献链接。

数据来源：主要采集 GitHub 仓库数据，包括 Star、Fork、open issues、最后提交时间（pushed_at）、贡献者数、release 时间等。
指标拆分与权重：健康度分为“人气（Popularity）”“活跃度（Activity）”“社区参与（Community）”三项，综合分示例权重为 0.4×人气 + 0.4×活跃度 + 0.2×社区。
计算策略：Star 数采用对数/分段映射平衡极值，活跃度以最近提交时间和近期提交次数为主，社区参与以贡献者数量和 Issue 活动衡量。
后端实现：利用 Cloudflare Workers（或 Pages Functions）定时抓取 GitHub 指标并写入 Cloudflare D1，前端通过 HTMLRewriter 在静态页面渲染时注入评分与标签，无需额外客户端请求，保证加载速度。

UI 变化与展示示例

本次更新带来了以下界面变化：

列表页：每个项目卡片右上角或底部新增分数字徽章（如 86 / 100），标签区显示“新 / 热 / 不活跃 / 已归档”等状态徽章。不活跃或已归档项目的缩略图自动灰度处理，便于区分。
详情页：侧边栏新增“项目健康评分”区域，展示人气、活跃度、社区参与三项子得分及综合得分，并配有进度条直观反映分值高低。

这些变化让用户在浏览和筛选时能更快做出判断，提升整体体验。

反馈与参与方式

为了持续完善资源库，欢迎大家积极反馈和贡献：

如发现资源 GitHub 链接错误、Star/状态显示异常，或有新项目推荐，欢迎通过 Issue 提交。
对评分权重或阈值有建议，也可在 Issue 讨论，常见建议将考虑做成可配置项并写入实现文档。

提交入口： AI 资源反馈与推荐

后续计划与展望

后续将持续优化资源页，主要方向包括：

增加历史快照保存，绘制评分趋势图（周线/月线），帮助读者了解项目热度演化。
引入更多外部指标（如 OpenSSF Scorecard、依赖情况）丰富评分维度。
进一步优化过滤器，增加“仅显示高分项目”等快捷筛选功能。

这些计划将进一步提升资源库的专业性和实用性，欢迎持续关注与建议。

总结

本次国庆期间的资源页更新，重点在于提升浏览、筛选与判断优质项目的效率。评分系统并非权威排名，而是为读者提供决策参考。感谢大家一直以来的支持，欢迎通过 GitHub 反馈问题或推荐新项目，让 AI 资源库持续成长。

参考文献

云原生企业转型：AI 原生时代的深度解析

2025-10-01 14:59:47

在过去一年里，我发现云原生产业迎来了一个显著趋势：大量原先专注于云原生的企业开始拥抱生成式 AI，甚至把自己的产品线重新定位为"AI 原生"或"智能体平台"。这种转型不仅体现在功能层面的升级，还涉及业务模型、用户定位和市场战略的调整。

引子

2025 年 9 月，一则新闻引起了我的注意：Rancher 创始人梁胜 (Sheng Liang) 宣布其新公司 Acorn Labs 将从 Kubernetes 管理工具全面转向智能体（AI Agent）平台（见 Why Rancher’s Founders Pivoted From Kubernetes to Agentic AI ）。七年前我就认识了梁胜，他是一位连续创业者，之前创立的 Cloud.com 被 Citrix 收购，后来又创立了在云原生时代名声大噪的 Rancher，最终被 SUSE 收购。这是他第三次创业，这次他选择离开已经成熟但竞争激烈的 Kubernetes 市场，转而押注于智能体这个全新领域。

梁胜在接受采访时表示：“我们看到智能体将成为软件开发的主要方式，就像云原生曾经改变基础设施一样，智能体将重新定义软件构建和交付的方式。“他认为，虽然 Kubernetes 市场规模庞大，但已经被大厂主导，创业公司的机会窗口已经关闭。相比之下，智能体领域仍处于早期阶段，需要全新的基础设施、工具和最佳实践。Acorn Labs 的新平台旨在让开发者无需深入的机器学习知识，就能轻松创建、部署和管理智能体。

这个转型决策让我陷入了思考。梁胜作为云原生领域的先行者，他的战略转向不是一时兴起，而是基于对技术趋势的深刻洞察。如果连 Rancher 这样的云原生领军企业都在转向 AI 原生，这是否意味着整个行业正在经历一次范式转移？本文将以此为引子，结合 Gitpod 改名为 Ona（见 Gitpod is now Ona, moving beyond the IDE ）、流量管理、基础设施管理、代码构建和 DevOps 等不同领域的代表性公司，对 AI 大潮下传统 SaaS/云原生/基础设施/开发者工具公司的转型路径和趋势进行深度分析。

图 1: AI 原生时代下的云原生企业转型路径

AI 浪潮对云原生领域的影响

大语言模型（LLM）和生成式 AI 的爆发式增长导致企业对 AI 接入与治理的需求激增。以 API 网关领域为例（见我之前写的博客深入解析 AI Gateway：新一代智能流量控制中枢），传统 API 网关在 AI 场景下遇到多方面挑战：一是 LLM 调用计费依据令牌数而非请求次数，需要对每个请求的 token 使用量进行精细管理；二是 LLM 输出存在不可预测性，网关不仅要检查输入还要过滤返回内容；三是 AI 应用常常需要同时使用多个模型或多个供应商，传统网关缺乏根据请求内容动态路由到最合适模型的能力；四是需要在高并发、流式返回的场景下进行实时性能与成本优化。文章还指出，自 2023 年下半年起，Envoy、Apache APISIX、Kong、Solo.io、Tetrate、F5 等社区或厂商纷纷发布 AI Gateway 项目或产品，用插件或模块的方式将 AI 流量管理和安全治理纳入网关能力范畴。

这一波 AI 浪潮带来的核心变化可归纳为：

工作负荷更加"AI 化”：开发者开始要求平台提供自然语言生成代码、自动部署和环境配置等功能。
成本与风险新维度：生成式模型按令牌计费且响应不可预测，促使企业建立新的治理手段和成本控制策略。
多模型与混合云架构：为了避免供应商锁定，企业倾向同时使用多个模型并在公有云和本地部署混合使用，这对流量管理与安全合规提出了更高要求。
从工具到智能体：很多厂商将生成式 AI 功能升级为"智能体”，能够理解上下文并代替人完成任务，意味着产品形态从辅助工具转向半自主系统。

案例研究：云原生企业的 AI 转型

下面我们选择几个不同领域的代表性企业进行深入分析。

Gitpod → Ona：从浏览器 IDE 到 AI 软件工程智能体

Gitpod 曾是颇受欢迎的在线开发环境平台，它提供了浏览器中的 VS Code 和预配置的开发容器。然而，随着生成式 AI 的崛起，公司在 2025 年 9 月宣布重塑品牌并更名为 Ona。新官网解释了这一转型：公司认为"IDE 定义了上一代，智能体将定义下一代"，工程师需要的不是一个简单的 IDE，而是能让智能体陪伴整个软件生命周期的"任务控制中心"。新平台重新定位为"为个人团队提供软件工程智能体的使命控制台"，允许用户在 Ona 上探索、分解、委派、编码、评审和编写文档，它由三大组件组成：

Ona Environments：沙箱化的云开发环境，使用 devcontainer.json 和 automations.yml 进行声明式定义，可在 Ona 云或私有 VPC 中运行。
Ona Agents：具备私有模型访问和 MCP（Model Context Protocol）支持的工程智能体，用户可通过对话界面或 VS Code 浏览器版与智能体协作，使用斜杠命令共享工程师最佳实践。
Ona Guardrails：提供企业级的安全合规与控制，支持 RBAC、OIDC、命令拒绝列表、审计日志，以及在企业 VPC 内部署。

Ona 还公布了内部使用效果：他们的 Ona Agents 在一周内共同撰写了公司 60% 的合并 PR，并贡献了 72% 的代码。这些变化表明 Gitpod 正在从在线 IDE 供应商转型为具有自动化编程智能体、流程管理和安全控制的 AI 原生开发平台。

Tetrate：利用服务网格经验跨足 AI 流量管理

Tetrate 作为笔者曾工作多年的公司，以维护和商业化 Envoy/Istio 服务网格而闻名。随着如今众多企业将多个 LLM 集成到业务中，Tetrate 在 2025 年推出了 Agent Router Service (TARS)，用于动态路由 AI 请求并优化模型成本。官方博客指出，该服务在 Goose 集成中提供一键配置，用户无需维护多个模型供应商的 API 密钥即可访问 GPT‑5、Claude Opus 4.1、Grok 4 以及开源模型等前沿模型。它还提供 $10 免费额度，并在后台根据任务复杂度自动在模型间切换，支持统一认证、自动故障转移和成本优化。更重要的是，Tetrate 将在服务网格中积累的 智能路由、负载均衡和弹性机制 应用于 AI 场景，使 AI 调用能够根据令牌价格和响应时间等因素进行动态路由。

公司在新闻稿中表示，TARS 能根据推理成本、查询复杂度、模型性能或任务特异性将 AI 查询动态路由到最合适的模型。它支持多租户或本地部署，并允许开发者使用自己的 API 密钥或 Tetrate 提供的密钥接入模型。内置功能包括自动回退到更可靠或更便宜的模型、交互式提示调试和 A/B 测试。对于聊天机器人，它会将会话路由到响应更快或更具成本效益的模型；对于代码生成，它能根据编程语言、上下文和合规要求动态选择模型；对于自主智能体，它协调多个 LLM 调用并控制成本。Tetrate 还将其 AI 网关与 Agent Operations Director 结合，通过 NIST 和 FINOS 标准加强模型治理和合规性。

此外，Tetrate 正在通过 AI 网关保持竞争力，其主导的开源项目 Envoy AI Gateway 为组织提供统一的 API，以管理来自多个模型的请求。新推出的路由服务让开发者可以用 Tetrate 提供的或自有的 API 密钥访问不同模型，并通过提示调试、自动回退及 A/B 测试避免供应商锁定。业内分析师认为，随着开发者同时使用多个 LLM，AI 流量路由器已成为不可或缺的基础设施，它们帮助在性能和成本之间取得平衡。

Replit Agent：从 IDE 到"生成应用"平台

在线开发平台 Replit 在 2024 年 9 月发布了 Replit Agent，定位为能够从自然语言直接创建和部署应用的 AI 系统。借助 Replit Agent，用户只需几句话和几分钟，就可以将一个想法变成部署好的应用。Replit Agent 像一名对等程序员，它会自动配置开发环境、安装依赖并执行代码。官网介绍强调，这种方式"无需代码"，用户告诉 Agent 自己想做什么，它会自动生成应用和网站，甚至可以上传一张参考截图让 Agent 完成相似页面。该平台强调 Agent 能够迅速从想法生成原型，并拥有修复 bug 的能力，集成所有构建工具于一处。

Replit 的转型说明，在线编程平台正在向"应用生成器"演变：用户的交互方式从编写代码转为描述需求，平台则通过大模型与执行环境的结合快速交付结果。这种模式降低了软件开发门槛，同时也模糊了开发者与非开发者的界限。

GitLab Duo：AI 原生 DevSecOps 平台

GitLab 在 2024 年推出了 GitLab Duo，致力于在整个软件生命周期中引入生成式 AI。GitLab Duo 声称是唯一覆盖"从规划和编码到安全与部署"的 AI 解决方案。它强调隐私优先，企业可以控制哪些用户和项目使用 AI 功能，并保证私有代码不会用于训练模型。该平台通过单一界面集成最适合各个环节的模型，提供智能代码建议、自动化安全修复、实时问答和生成测试等功能。

2025 年 9 月发布的 GitLab 18.4 版本进一步提出了"AI 原生开发“愿景，包括以下亮点：

AI Catalog 与自定义智能体：用户可以在 AI Catalog 中创建、共享和协作自定义智能体，例如为产品规划、文档编写或安全合规构建专属智能体，让智能体像团队成员一样执行特定任务。
Agentic Chat：让开发者与智能体自然对话。新版支持对话会话管理、在会话中选择不同模型，以及改进的工具调用审批，使协作更流畅。
Knowledge Graph：为智能体和人提供项目的知识图谱，将代码文件、路由和引用关联起来，使开发者可以在聊天中查询"项目中有哪些路由文件"或"某次修改影响了哪些模块"等问题。
Fix Failed Pipelines Flow：利用 AI 实现业务感知的流水线修复。该流程不仅分析失败日志，还结合业务优先级和跨项目依赖生成修复方案，并自动创建包含业务背景的 merge request。
模型选择与治理：18.4 版本提供模型选择功能，允许用户在不同 LLM 之间切换，并在自管理环境中支持 GPT -5 或开源模型，满足合规需求。

GitLab 的转型展示了 DevSecOps 平台如何将生成式 AI 深度嵌入现有流程：通过智能体化的协作方式自动完成规划、编码、测试和运维任务，同时强调隐私和模型治理。

Pulumi Copilot：面向基础设施的对话式 AI

基础设施即代码（IaC）平台 Pulumi 在 2024 年推出了 Pulumi Copilot。官方文档将其描述为"集成到 Pulumi Cloud 的对话式聊天界面，结合生成式 AI 与 Pulumi Cloud 的强大能力，使用户能够更快速完成云基础设施管理任务”。Copilot 的核心能力包括：

访问和探索云资源：用户可以查询任何由 Pulumi 管理的资源状态，并通过 Pulumi Insights 的 Supergraph 支持访问 160 多家云供应商的数据，了解项目、堆栈、更新、部署、审计日志等历史信息。
基础设施编写与部署：Pulumi AI 以聊天方式帮助用户编写 IaC 代码并直接在 Copilot 中部署。
访问实时云元数据：通过新增的"技能"，Copilot 可实时获取 AWS、Azure、Kubernetes 等平台的元数据，结合 Pulumi 世界观分析资源使用、成本和尚未纳入管理的基础设施。
系统提示与自定义：管理员可通过系统提示对 Copilot 的默认行为进行自定义，适配团队需求与策略。

Pulumi Copilot 使用 OpenAI 的 GPT‑4o 模型，它继承 Pulumi Cloud 的 RBAC 权限模型，目前仅能执行只读操作，未来将扩展到可执行操作并提供可控的读写权限。这一转型展示了 IaC 工具厂商如何利用 AI 降低基础设施运维门槛，并通过对话式体验提供成本分析和快速部署功能。

Datadog Bits AI：自动化运维与安全分析

可观测性平台 Datadog 在 2025 年推出了 Bits AI 套件，包括 Bits AI SRE、Bits AI Security Analyst 和 Bits AI Dev Agent。来自技术博客的梳理显示，Bits AI SRE 通过生成多个假设并验证各类监控数据，为根因分析提供自动化支持。它像一名 24/7 的自治队友，实时分析日志、指标、追踪以及 Watchdog 警报，并将假设分类为已验证、已否定或需要进一步调查，从而大幅缩短人工排查时间。实际案例中，Bits 已帮助全球运营团队在高峰期加速故障排查。

Bits AI Security Analyst 通过 MITRE ATT&CK 框架自动规划和执行安全调查，主动处理 Datadog Cloud SIEM 的信号，并提供可操作的建议。Bits AI Dev Agent 则聚焦代码修复，它会监控遥测数据、识别关键问题并生成生产级的修复 PR，让工程师直接在代码仓库中审查和合并。这些智能体共享模型上下文并可共同分析异常或扩容基础设施。平台声称，该套件可将安全调查时间从 30 分钟缩短至 30 秒，并为公司节省数千小时工程时间。Bits AI 的推出标志着可观测性供应商正从被动监控转向主动诊断和自动修复，构建 AI 原生运维体系。

趋势分析：不同领域企业的转型路径与启示

综合上述案例，可以发现传统云原生公司转向 AI 原生存在一些共性策略和差异化路径：

核心产品重塑与品牌升级：Gitpod 直接更名为 Ona，并将产品定位从在线 IDE 升级为"软件工程智能体中心"，体现了彻底的战略转型。其他如 GitLab、Pulumi 则在原有品牌下推出新平台，但都突出"AI 原生"概念。
借助现有技术优势拓展新场景：Tetrate 利用其在服务网格和 Envoy 领域的技术积累，把智能路由、负载均衡等能力迁移到 AI 流量管理，实现平滑转型。
构建"智能体"平台化生态：GitLab 的 AI Catalog、Agentic Chat 与自定义智能体，让企业可以像管理团队成员一样管理智能体。Ona 和 Replit 也都强调智能体（agent）概念，用户与智能体协作完成开发任务。这意味着厂商正在从提供单一 AI 功能转向提供可组合、可扩展的智能体生态系统。
重视安全、合规与成本治理：在企业场景中，生成式 AI 的使用需要细粒度权限控制、审计和合规。Tetrate 的路由服务支持隔离部署并与合规框架对齐；GitLab 提供 AI 透明中心和模型选择机制；Pulumi 与 Datadog 都强调数据安全和权限模型。另外，Tetrate 路由服务和 AI Gateway 通过按令牌计费与自动降级模式帮助控制成本。
多模型与开放生态：为了避免垄断和不确定性，多个平台支持用户自行选择模型或使用开源模型。Tetrate 支持 GPT‑5、Claude、Grok 等多种模型；GitLab 允许自定义模型选择并计划在自托管版支持 GPT‑5 和开源模型；Pulumi 允许管理员自定义系统提示和模型行为。这些趋势预示着未来的 AI 平台会越来越强调多模型互操作性。
从自动化协助到自主决策：Replit Agent 可以完成应用搭建和部署；GitLab Duo 能生成代码和修复 CI 流水线；Pulumi Copilot 帮助编写与部署基础设施；Datadog Bits AI 能直接生成修复 PR 并自动实施。这些功能说明企业正在尝试让 AI 从"助手"升级为具备决策能力的"执行者"。

与此同时，也要看到转型的挑战：

技术复杂度和模型可靠性：LLM 仍存在幻觉和安全风险，如何在自动化与人工审核之间取得平衡是重要课题。Tetrate、GitLab 等均在产品中加入了"手动/辅助模式"和审计机制，以防止智能体过度自动化导致失控。
市场教育与产品成熟度：AI Gateway 等概念仍然新颖，有些厂商可能只是"换壳"宣传，实际功能并不成熟。企业需要结合自身场景评估 AI 方案的真正价值。
成本与商业模式：AI 服务成本高昂且计费模型复杂，平台需要提供灵活的成本管理功能（如 Tetrate 的 cost governance 和 GitLab 的 ROI 度量），同时也要探索新的定价策略。

结论与未来展望

过去一年里，云原生生态中的多家公司通过重塑产品、引入智能体和 AI 流量管理，积极拥抱生成式 AI。无论是将传统 IDE 转型为 AI 开发控制台的 Ona，利用服务网格经验打造 AI 流量路由器的 Tetrate，还是在 DevSecOps、IaC 和可观测性领域推出智能体化功能的 GitLab、Pulumi 和 Datadog，这些实践都表明 AI 原生 正成为下一轮技术浪潮。

未来我们可能看到：

平台化的智能体生态：企业不再仅仅购买单个 AI 功能，而是选择能够托管、训练和编排多种智能体的平台；这些智能体将覆盖规划、开发、测试、运维和安全的各个环节，并能够互相协作。
开放标准和互操作性：Kubernetes Gateway API、Model Context Protocol 等标准有望促进跨平台互联，使智能体可以在不同工具间共享上下文和模型能力。开源社区将在这一过程中扮演重要角色。
更严格的治理与监管：随着 AI 能力的增强，权限、合规和成本控制将成为平台竞争力的一部分。企业需要在使用 AI 提升效率的同时，确保数据安全和伦理规范。
从工具到伙伴：生成式 AI 不只是自动化工具，它将成为团队的重要伙伴。开发者与智能体的互动方式更像协作而非指令，这要求平台在交互体验和人机协同方面持续创新。

总之，AI 原生时代带来了软件工程范式的深刻变化。对于云原生领域的企业而言，抓住这一波浪潮意味着机会与挑战并存：既要充分释放 AI 带来的效率提升和创新空间，又要在安全、可靠和合规的前提下构建稳健的产品和生态。我们正处于这一转型的起点，未来值得期待。

参考资料

Chrome DevTools MCP：前端开发自动化又上了一个新台阶

2025-09-25 10:01:57

近年来，AI 与编程助手的融合不断加速，能够直接在浏览器内部进行深度调试与性能分析的能力，正在推动前端自动化进入新阶段。本文将介绍 Google 最近发布的 Chrome DevTools MCP ，并深入讲解其设计理念、核心组件、典型用例以及本地试用与参与贡献的方法。

前言

2008 年的一个午后，我第一次下载并打开了 Chrome。那一刻印象至今难忘：空白的启动页、简洁的标签式界面，以及令人惊叹的速度，与当时笨重又充斥着弹窗、强制主页和杂乱插件的 IE 形成了鲜明对比。十几年过去，Chrome 的市场份额已经超过 70%，并催生出大量基于 Chromium 内核的浏览器。近两年，市面上也冒出了一些所谓的“AI 浏览器”，我也尝试过几款，但体验并不理想，很多功能其实一个普通的 AI 插件就能完成。相比之下，Chrome 在许多场景中依然无法被取代，尤其是在 Web 开发时，它早已不仅是浏览网页的工具，更是开发者离不开的全能套件。如今，Chrome 已在美国率先支持 Gemini，相信很快就会在全球推广，未来我们将迎来一个内置 AI 功能的 Chrome，这无疑将再次改变我们的上网与开发体验。

什么是 Chrome DevTools MCP？

Chrome DevTools MCP 并非简单地暴露 DevTools 功能，而是将调试能力、性能跟踪、网络监控等工具封装为面向 LLM/代理的 MCP 服务。与传统 Puppeteer 或 Playwright 的“脚本式控制”相比，Chrome DevTools MCP 具有以下优势：

更丰富的内部数据：可直接访问 performance trace、堆栈、网络事件等底层数据。
原生 DevTools 功能：涵盖 Lighthouse 风格的性能审查、CPU/内存采样、布局与渲染分析等。

在 VS Code 中配置好 Chrome DevTools MCP 后，你可以直接在 Copilot 中运行如下提示：

#chrome-devtools 检查 jimmysong.io 的 LCP 问题。

此时，Chrome 浏览器会自动启动并打开 jimmysong.io 网站，MCP 服务会执行页面加载的 tracing，收集 traceEvents 并分析主线程任务，最终返回包含 LCP 诊断和优化建议的报告。

项目概览

下面简要介绍 Chrome DevTools MCP 的技术栈和主要工具集，帮助读者快速了解其整体架构。

语言/运行时：Node.js（以 puppeteer/chrome-remote-interface 为后端），可按需启动 headless 或带界面的 Chrome 实例。
工具集：包含页面操作、性能记录、网络监控、控制台事件、堆快照、屏幕截图等多种工具（文档提到 18+ 工具）。
使用场景：性能优化自动化、自动化回归调试、AI 驱动的浏览器操作与审计。

核心架构与组件

Chrome DevTools MCP 采用分层架构设计，确保代理能够高效利用底层调试能力。下文将详细介绍各层组件及其职责，并通过架构图展示数据流转过程。

MCP Server 层：负责接收来自 LLM/代理的 MCP 请求，进行会话管理与权限控制。
工具适配层：将 MCP 的高层请求映射到 Chrome DevTools Protocol（CDP）或 Puppeteer API，并管理长任务（如 recording/tracing）。
Chrome 运行时：真实的 Chrome/Chromium 实例（headful 或 headless），执行所有底层操作并产生 trace、performance、console 等数据。
数据采集与传输：将采集到的 trace、堆栈、HAR、快照等数据序列化，通过 MCP 返回给调用方。

这种分层设计保证了灵活性：上层代理无需了解 CDP 细节即可利用强大的调试数据，实现者则可在工具适配层持续扩展新能力。

下方为 Chrome DevTools MCP 的架构图，便于理解系统内部数据流：

图 1: Chrome DevTools MCP 架构图

上图展示了从代理发起请求、MCP 服务分发到具体工具、工具通过适配器调用 Puppeteer/CDP 与 Chrome 交互、再将采集到的数据封装回传的全流程。

实际仓库实现还包含细粒度的工具目录（约 26 个工具，6 个类别），以及 WebSocket / stdio 的连接示例与配置项。建议阅读仓库 README.md 与 examples/ 获取最新命令与运行选项。

主要实现要点：

CLI 与 MCP Server：项目以 Node.js CLI 启动，index.js 使用 yargs 处理命令行参数，并通过 @modelcontextprotocol/sdk 初始化 MCP 服务。服务可通过 stdio、WebSocket 或 HTTP 与外部代理通信。
工具系统：采用 defineTool() 工厂模式定义工具（ToolDefinition），并按功能分组为若干类别（输入自动化、页面导航、性能、调试、网络、仿真等）。每个工具负责参数校验、执行逻辑与统一的错误/响应格式。
浏览器管理（McpContext）：集中管理 Chrome 实例生命周期（启动、关闭、profile、可执行路径、headless/headful、隔离上下文），并维护页面状态以便多个工具共享同一浏览器上下文。
事件处理与同步：工具之间常需等待浏览器状态（如导航完成、元素出现、trace 结束）。项目实现了统一的事件处理与同步策略，保证长任务与短操作之间的协调。
响应格式化（McpResponse）：统一封装返回数据，包括状态、浏览器快照、截图、trace metadata、HAR 或性能洞察，方便代理消费并生成后续动作或建议。

工具生态系统

Chrome DevTools MCP 共提供 26 个工具，分为六大功能类别。下表对各类别及主要功能进行说明：

类别	数量	主要功能
输入自动化	7	click、drag、fill、fill_form、handle_dialog、hover、upload_file
导航自动化	7	close_page、list_pages、navigate_page、navigate_page_history、new_page、select_page、wait_for
性能	3	performance_analyze_insight、performance_start_trace、performance_stop_trace
调试	4	evaluate_script、list_console_messages、take_screenshot、take_snapshot
网络	2	get_network_request、list_network_requests
仿真	3	emulate_cpu、emulate_network、resize_page

表 1: Chrome DevTools MCP 工具分类与功能

每个工具都提供了特定的浏览器自动化能力，并保持一致的接口和错误处理模式。

典型用例与示例

Chrome DevTools MCP 在实际应用中展现出显著价值，主要体现在以下方面：

自动化启动页面加载 tracing，收集 trace 数据，分析主线程任务与网络请求，输出可执行建议（如减少阻塞脚本、延迟加载第三方资源）。
利用 traceEvents 获得精确的时间片段和调用栈，便于自动化工具生成修复建议。
Agent 能触发一系列 DOM 操作，记录 console/warnings/errors，生成堆快照与 DOM 快照，并附带回放脚本与 screenshot，帮助开发者快速定位和复现问题。
支持拦截并记录所有网络请求（含 headers、timings、size），分析阻塞、超时或异常响应，标注可疑第三方脚本，实现自动化网络安全审计。

如何配置和使用？

下面介绍将 Chrome DevTools MCP 注册为 MCP 客户端服务器的步骤，并给出常见运行参数与实践建议。

添加 Chrome DevTools MCP 到 MCP 客户端

在 MCP 客户端（或代理）配置中，添加 mcpServers 条目指向 chrome-devtools-mcp。官方推荐配置如下：

{
 "mcpServers": {
 "chrome-devtools": {
 "command": "npx",
 "args": ["chrome-devtools-mcp@latest"]
 }
 }
}

该配置会在代理需要时通过 npx 启动 chrome-devtools-mcp。如在 CI 或需可重复性环境运行，建议将 @latest 替换为固定版本号（如 [email protected]）。

常见运行参数与实践建议

指定 Chrome 可执行路径：部分系统自动发现 Chrome 可能失败，建议在客户端或启动参数中显式指定 chromePath。
Headless vs Headful：调试时建议使用 headful（带界面），自动化与 CI 环境建议使用 headless 或 headful 的无头 Chromium。
固定版本：CI/生产环境中建议指定具体版本，避免因 latest 引入不兼容变更。
权限与沙盒：Linux 容器运行时需注意 Chrome 的 sandbox 与权限配置，参考仓库 README 的 Docker/CI 说明。

在 CI 中的整合思路

在 CI runner 中安装或下载 Chromium，并明确 CHROME_PATH 环境变量指向可执行文件。
使用固定版本的 chrome-devtools-mcp 启动 MCP 服务（如通过 npx [email protected]）。
运行自定义自动化提示或脚本，如启动页面加载 trace、收集性能报告并将结果作为 artifact 上传。

对开发者和团队的直接价值

Chrome DevTools MCP 为开发者和团队带来如下直接价值：

自动化性能审计：在 CI 集成 MCP，可在 PR/Release 阶段自动生成性能回归报告。
精准自动化复现链路：结合 tracing 与堆快照，缩短问题发现到定位的周期。
面向 LLM 的可解释数据：代理可获取可操作的底层数据（而非仅截图），生成更可靠的补丁建议。

总结

Chrome DevTools MCP 将 Chrome DevTools 的深度调试能力带给代理与 LLM，填补了自动化脚本控制与深层调试之间的空白。对于追求性能、可靠性和可解释性的前端团队而言，它是高价值的工具链组件。欲了解实现细节、示例与参与贡献，请访问下列资源。

参考文献

新型 GitHub 资助申请诈骗全解析：利益链条、作案流程、技术实现与防御

2025-09-22 10:08:57

本文以我亲身遭遇的“GitHub × Gitcoin Developer Fund 2025”钓鱼事件为例，系统梳理其利益链条、作案流程、技术实现与防御措施，帮助技术社区识别并应对新型 Web3 诈骗。

引言

近日，我在 GitHub 收到一封伪装成 “GitHub × Gitcoin Developer Fund 2025” 的邮件通知，声称我已“符合资格”，只需点击链接、通过 Gitcoin Passport 验证钱包并支付“可退还押金”即可获得资助。大量开发者也反馈收到了类似邮件，详见社区讨论 #174283 。

这种诈骗方式利用了 GitHub 通知系统的权威感，并结合 Web3 钱包授权与押金，伪装成高大上的资助计划，实则是资金和账号窃取的骗局。本文将从利益驱动、作案链条、技术实现到防御措施进行系统分析。

GitHub 通知“套壳”与钓鱼入口

攻击者通过脚本账号在陌生仓库发起 Issue 或 Discussion，并 @ 上千名开发者（包括我），触发 GitHub 的系统通知邮件，轻松绕过垃圾拦截，直接进入收件箱。即便是经验丰富的开发者，也可能因“GitHub 官方通知”形式而放松警惕。

示例链接：钓鱼 Issue （GitHub Issue，可以放心点击）

钓鱼页面剖析与典型特征

访问钓鱼页面 github-foundation.com 后，无论点击页面哪个位置，都会弹出“Connect Wallet”窗口，支持 MetaMask、Trust Wallet、WalletConnect 等主流钱包。

主要特征如下：

域名伪装：github-foundation.com 与官方域名完全不同。
全屏诱导：页面无实质信息，所有操作均引导钱包连接。
虚假背书：展示 Gitcoin 的真实数据，但脱离上下文。
钱包陷阱：授权或支付押金后，资金和权限即被盗取。

目标画像与攻击策略

攻击者优先选择具有一定影响力和资产的开发者账号，如 GitHub Developer Program 成员、拥有 Sponsors、活跃度高等。这类账号更可能点开链接，且钱包资产和仓库权限价值更高。

但同时，攻击者采用批量撒网策略，混合高价值和低价值用户一起投放，只要有少量开发者上钩即可获利。

利益链条与作案流程

攻击者的完整利益链条如下：

流量获取：批量账号发帖，@ 大量用户，利用 GitHub 邮件通知背书。
转化设计：假域名、假文案、假合作方，制造“官方感”。
获利手段：押金支付骗钱、钱包无限授权盗取资产、GitHub 授权用于后续供应链攻击。
风险对冲：一次性账号，批量投放，快速跑路。

图 3: 作案流程图

技术实现与工程化细节

利用 GitHub 通知系统“借壳”，提高投递成功率。
域名 typosquatting，仿冒 github.com。
钱包交互社工，利用“仅签名，不会扣费”降低防备心理。
批量 @，覆盖广，攻击成本低。
后续利用 GitHub 授权，可能插入恶意代码。

社区反馈与受害情况

在 GitHub Community 讨论区，已有开发者反馈收到同类 spam，说明该骗局已进入大规模传播阶段，并非孤立案例。

如何删除垃圾通知

针对此类钓鱼导致的垃圾或“幽灵”通知，可参考社区讨论中的有效解决方案。下载下面的清理脚本，并在本地运行 node remove_phantom_notifications.js TIMESTAMP：

🟨 remove_phantom_notifications.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125



const { exec } = require("node:child_process");
const { basename } = require("node:path");

function runShellCommand(command) {
 return new Promise((resolve, reject) => {
 exec(command, (error, stdout, stderr) => {
 if (error) {
 reject({ error, stderr });
 return;
 }
 resolve(stdout);
 });
 });
}

let _githubToken = null;
async function getGithubToken() {
 if (!_githubToken) {
 _githubToken = await runShellCommand("gh auth token");
 }
 return _githubToken;
}

async function getNotifications(since) {
 const response = await fetch(`https://api.github.com/notifications?all=true&since=${since}`, {
 headers: {
 'Accept': 'application/vnd.github+json',
 'Authorization': `Bearer ${await getGithubToken()}`,
 'X-GitHub-Api-Version': '2022-11-28',
 },
 });
 return response.json();
}

async function shouldIncludeNotificationForRemoval(notification) {
 try {
 const response = await fetch(`https://api.github.com/repos/${notification.repository.full_name}`, {
 headers: {
 Accept: "application/vnd.github+json",
 Authorization: `Bearer ${await getGithubToken()}`,
 "X-GitHub-Api-Version": "2022-11-28",
 },
 });
 return response.status === 404;
 } catch (error) {
 console.log("threw");
 if (error.code && error.code === 404) {
 return true;
 }
 console.error(error);
 throw error;
 }
}

async function markNotificationRead(notification) {
 const response = await fetch(notification.url, {
 method: "PATCH",
 headers: {
 "Authorization": `Bearer ${await getGithubToken()}`,
 "Accept": "application/vnd.github+json",
 "X-GitHub-Api-Version": "2022-11-28",
 },
 });
 if (!response.ok) {
 console.error(`Failed to mark notification with thread URL ${notification.url} from repo ${notification.repository.full_name} as read: ${response.status} ${response.statusText}`);
 }
}
async function markNotificationDone(notification) {
 const response = await fetch(notification.url, {
 method: "DELETE",
 headers: {
 "Authorization": `Bearer ${await getGithubToken()}`,
 "Accept": "application/vnd.github+json",
 "X-GitHub-Api-Version": "2022-11-28",
 },
 });
 if (!response.ok) {
 console.error(`Failed to mark notification with thread URL ${notification.url} from repo ${notification.repository.full_name} as done: ${response.status} ${response.statusText}`);
 }
}

async function unsubscribe(notification) {
 const response = await fetch(notification.subscription_url, {
 method: "DELETE",
 headers: {
 "Authorization": `Bearer ${await getGithubToken()}`,
 "Accept": "application/vnd.github+json",
 "X-GitHub-Api-Version": "2022-11-28",
 },
 });
 if (!response.ok) {
 console.error(`Failed to unsubscribe from notification with thread URL ${notification.url} from repo ${notification.repository.full_name}: ${response.status} ${response.statusText}`);
 }
}

async function main() {
 const since = process.argv[2];
 if (!since) {
 console.error(`Usage: ${basename(process.argv[0])} ${basename(process.argv[1])} <since>`);
 process.exit(1);
 }

 try {
 new Date(since);
 } catch (error) {
 console.error(`${since} is not a valid ISO 8601 date. Must be formatted as YYYY-MM-DDTHH:MM:SSZ.`);
 console.error(`Usage: ${basename(process.argv[0])} ${basename(process.argv[1])} <since>`);
 process.exit(1);
 }

 const notifications = await getNotifications(since);
 for (const notification of notifications) {
 if (await shouldIncludeNotificationForRemoval(notification)) {
 console.log(`Marking notification with thread URL ${notification.url} read from repo ${notification.repository.full_name}`);
 await markNotificationRead(notification);
 console.log(`Marking notification with thread URL ${notification.url} done from repo ${notification.repository.full_name}`);
 await markNotificationDone(notification);
 console.log(`Unsubscribing from notification with thread URL ${notification.url} from repo ${notification.repository.full_name}`);
 await unsubscribe(notification);
 }
 }
 console.log("Done");
}

main().catch(console.error);

比如清理 2025 年 9 月 25 日之后的幽灵通知：

node remove_phantom_notifications.js 2025-09-25T00:00:00Z

防御与应急措施

这里总结一些防御策略：

个人防御：

警惕涉及钱包签名或押金的操作，默认诈骗。
启用 GitHub 2FA，定期审计 OAuth App、PAT、SSH Keys，撤销可疑授权。
邮件过滤，对标题含 Gitcoin、Fund、Passport、USDC 的通知自动打标签。

组织防御建议

实施 SSO 与权限最小化原则。
限制外部 App 授权，统一官方资金/资助入口。
制定快速应急预案，准备撤销密钥与隔离仓库流程。

事后处置 SOP

撤销钱包授权；
删除 GitHub 可疑授权、Token、SSH；
审计仓库 secrets 与 actions；
举报钓鱼域名、账号、仓库。

IOC 附录（Indicators of Compromise）

钓鱼域名：github-foundation.com
常见关键词：GitHub × Gitcoin Developer Fund 2025、refundable deposit、Gitcoin Passport verification
GitHub 行为特征：批量陌生账号在无关仓库发 Issue/Discussion，@ 上百个无关开发者。

总结

本案例揭示了开源社区与 Web3 场景融合下的新型钓鱼诈骗，攻击者通过 GitHub 通知机制“借壳”，结合钱包授权与押金变现，危险之处在于大规模工程化与平台背书。有效防御需对资金和授权零信任，始终通过官方入口操作，个人与组织均应实施最小权限原则，提升安全意识。

Jimmy Song | 宋净超修改