Jimmy Song | 宋净超的 RSS 预览

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 代理平台（见 Why Rancher’s Founders Pivoted From Kubernetes to Agentic AI ）。梁盛是我相识 7 年的朋友，他是一位连续创业者，之前创立的 Cloud.com 被 Citrix 收购，后来又创立了在云原生时代名声大噪的 Rancher，最终被 SUSE 收购。这是他第三次创业，这次他选择离开已经成熟但竞争激烈的 Kubernetes 市场，转而押注于 AI 代理这个全新领域。

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

这个转型决策让我陷入了思考。梁盛作为云原生领域的先行者，他的战略转向不是一时兴起，而是基于对技术趋势的深刻洞察。如果连 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，而是能让 AI 代理陪伴整个软件生命周期的"任务控制中心"。新平台重新定位为"为个人团队提供软件工程代理的使命控制台"，允许用户在 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 与自定义代理，让企业可以像管理团队成员一样管理 AI 代理。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 通知机制“借壳”，结合钱包授权与押金变现，危险之处在于大规模工程化与平台背书。有效防御需对资金和授权零信任，始终通过官方入口操作，个人与组织均应实施最小权限原则，提升安全意识。

试用 Verdent 的一些感受：一款支持 Subagent 的 AI 编程助手

2025-09-21 11:12:27

Verdent 是一款定位于“AI 时代资深开发助手”的 VS Code 插件，主打 Subagent 并发任务和自动代码质量验证。本文将分享试用体验，分析其亮点与不足，并探讨其在开发者工作流中的实际价值。

最近我获得了 Verdent 的试用资格，并在 VS Code 中安装了该插件。Verdent 由言创万物（Codeck）推出，是其首款产品，旨在帮助开发者在 AI 时代更高效成长。官方宣传语为：“Human developers will thrive in the AI era”，强调人类程序员与 AI 协作的重要性。他们的产品 Verdent 也在近日发布了，感兴趣的去官网了解详情 https://www.verdent.ai/ 。

言创万物公司介绍

言创万物是一家 AI 原生的软件公司，致力于开发智能体编码工具，以赋能人类开发者。公司由陈志杰（TikTok 前算法负责人）和刘晓春（百度前技术与产品负责人）于 2025 年创立，通过将重复性任务交由编码智能体处理。

当前市面上的 Vibe Coding 工具和 IDE 插件种类繁多，我也试用过不少。起初对 Verdent 并未抱太大期望，但经过几天体验后，发现其确实有一些值得分享的亮点和改进空间。

我觉得不错的地方

在 VS Code 中通过插件方式使用 Verdent，以下几个方面让我印象较好：

集成自然：安装插件即可使用，无需重新学习新的工作流，降低了上手门槛。
功能超越补全：不仅仅是代码补全，还能自动拆解任务、生成方案，并对代码质量进行验证。
上下文理解较强：能够结合项目代码做出贴切回应，不仅仅局限于当前光标位置。
Subagent 支持：Verdent 最大的亮点在于支持单个智能体的并发任务执行，并可对子智能体进行配置，通过 FailFast 代码检查进行验证。
响应速度快：与 Codex 等工具相比，Verdent 的结果生成速度更快，提升了开发效率。

有点不顺手的地方

虽然 Verdent 的能力较强，但在细节体验上还有一些不足：

上下文选择繁琐：不像 Copilot 那样可以用简单符号快速选择。Verdent 的 @ 选择功能虽强大，但希望能一键选中已打开文件或终端输出。也支持通过键盘选择历史 prompt 和自定义 prompt，但整体体验仍有提升空间。这也是多数 AI 编程插件的通病。
输入框交互不自然：虽然可以输入内容，但不能直接发送，操作略显不便。如果能像普通聊天一样随时输入并发送，体验会更流畅。
命令运行方式不便：Verdent 会自动执行一些命令，但结果显示在 panel 中，而不是直接在 terminal。如果需要复制命令再运行，流程较为繁琐。
不支持 Tab 代码补全：只能在 Panel 中交互，无法作为传统代码补全工具使用。
缺乏模型选项：与 Qoder 类似，没有模型选择功能，用户无法得知实际运行的模型类型，透明度不足。

总体来看，Verdent 的核心能力没有问题，但在用户体验细节上仍有优化空间。

他们想解决的问题

根据官方资料，目前大多数 AI 代码工具存在“生成快但质量不稳，最终仍需人工 debug”的问题。Verdent 试图通过以下方式进行改进：

在需求模糊时，通过多轮对话帮助澄清需求。
自动拆解任务并设计解决方案。
代码生成后自动自检，生成测试，力求交付可运行的结果。

也就是说，Verdent 更关注“交付可用代码”，而不仅仅是“生成几行代码”。

两个产品形态

Verdent 目前有两种产品形态，分别适用于不同开发场景：

Verdent for VS Code：本次体验的插件版，适合贴近代码的开发者。学习成本低，上手快。
Verdent Deck：桌面应用版，支持并行运行多个智能体，配备任务看板和 DiffLens 等功能，适合同时管理多个项目的开发者。目前仅支持 M 系列 Mac，Windows 版预计 10 月推出。

总结

Verdent 在细节体验上尚有改进空间，但整体定位更接近“开发助手”而非传统“代码补全工具”。其 Subagent 并发任务和自动代码质量验证等功能，为开发者带来了更高效的协作体验。

如果你对 AI 编程助手感兴趣，Verdent 值得关注，未来或许会有更多创新和功能完善。

智能体的 21 种设计模式总结：Agentic Design Patterns 书评

2025-09-13 20:56:37

最近笔者在尝试各种工具构建 AI Agent（智能体），但是缺少一套方法论支撑，正好看到 Antonio Gulli 的这本新书 Agentic Design Patterns ，很好的总结了目前在构建智能体时使用的各种模式，比如 RAG、MCP、Memory 等，在此我整理成幻灯片和读书笔记分享给大家。

本书作者 Antonio Gulli，任职于 Google CTO Office。这本书的所有版税将捐献给救助儿童会。下面的幻灯片总结了书中列举的智能体的 21 种设计模式，并给出了示意图说明，此外你也可以在 Bilibili 上观看我的视频讲解。

幻灯片: Agentic 设计模式

简介：Agentic 系统与设计模式

Agentic 系统是一种能够感知环境、做出决策并自主执行行动以实现目标的计算实体。与传统软件不同，智能体具备自主性、主动性、响应性和目标导向的特性。其关键能力包括工具使用、记忆和通信。

Agentic 设计模式是经过实战检验的模板和蓝图，为智能体行为设计与实现中的常见挑战提供可复用解决方案。使用设计模式能提升智能体构建的结构性、可维护性、可靠性和效率，避免重复造轮子，并使开发者能专注于应用创新。

本书提炼了 21 个关键设计模式，涵盖从基础到高级主题，并结合 LangChain、LangGraph、Crew AI 和 Google Agent Developer Kit (ADK) 等主流框架进行实战演示。作者强调，虽然 AI 变化迅速，但这些模式和原则将成为智能体开发的基础模块，帮助大家关注核心理念。

AI 智能体的特征

AI Agent 是一种能够感知环境并采取行动以实现特定目标的系统。它遵循简单的五步循环完成任务：获取任务目标 → 扫描环境信息 → 制定计划 → 执行行动 → 学习与优化。AI Agent 市场正以惊人速度增长，预计到 2034 年将达到近 2000 亿美元。

AI 范式在短短两年内经历了巨大转变：

Level 0：核心推理引擎：LLM 本身，无工具、记忆、环境交互能力，仅依赖预训练知识。
Level 1：连接型问题解决者：LLM 通过连接外部工具（如搜索、数据库）获取和处理信息。
Level 2：战略型问题解决者：Agent 具备战略规划、主动协助和自我优化能力，通过“上下文工程”战略性筛选和管理信息。
Level 3：协作型多 Agent 系统崛起：多个专业 Agent 协作完成复杂目标，如新产品发布中的“项目经理”Agent 协调“市场调研”、“产品设计”等 Agent。

Agent 未来：五大假设

通才 Agent 的出现：Agent 将进化为能高可靠性地管理复杂、模糊和长期目标的通才。可能通过大型通才模型或“小语言模型”（SLM）组合实现。
深度个性化与主动目标发现：Agent 将通过学习用户行为和目标，从被动执行命令转向主动预测需求，成为“主动型伙伴”。
具身化与物理世界交互：Agent 将与机器人结合，实现“具身 Agent”，突破数字领域，在物理世界执行任务，如修理水龙头。
Agent 驱动经济：高度自治的 Agent 将成为经济参与者，创造新市场和商业模式，运营整个电商业务。
目标驱动、变形多 Agent 系统：系统将根据用户声明的目标自主规划并达成，动态调整多 Agent 结构，具备个体和整体自我优化能力。

核心 Agentic 设计模式

1. 提示链（Prompt Chaining）

概述：将复杂任务拆解为一系列更小、更易管理的子问题。每个子问题通过专门提示处理，前一步输出作为下一步输入，形成链式依赖。它引入了模块化和清晰性，提升了输出的准确性和针对性，并能集成外部知识和工具。
示例：LangChain 示例演示两步提示链，先从文本提取规格，再转为 JSON。
上下文工程：系统性方法，为模型构建完整信息环境，包括系统提示、外部数据（检索文档、工具输出）和隐性数据，比传统提示工程更全面。
应用场景：信息处理流程、复杂问答、数据提取与转换、内容生成流程、有状态对话 Agent、代码生成与优化、多模态与多步推理。
重要性：是构建复杂 AI Agent 的基础技术，让 Agent 能够自主规划、推理和行动，适应动态环境。

2. 路由（Routing）

概述：Agent 根据环境状态、用户输入或前序操作结果等因素，动态地将控制流导向不同的专用函数、工具或子流程，实现自适应响应。核心组件是执行评估并引导流程的机制。
实现方式：基于 LLM、基于嵌入、基于规则或基于机器学习模型的路由。
示例：LangChain 示例中，协调者 Agent 根据用户请求意图（预订、信息、不明确）路由到不同子代理。Google ADK 示例中，协调者代理通过 Auto-Flow 机制自动委托给 Booker 或 Info 子代理。
应用场景：人机交互中的用户意图解析、自动化数据与文档处理流程中的分类与分发、复杂系统中的高级调度器。
重要性：为 Agent 框架引入条件逻辑，使其从固定执行路径转变为动态评估标准，选择最佳后续动作，从而实现更灵活、具备上下文感知的系统行为。

3. 并行化（Parallelization）

概述：同时执行多个组件（LLM 调用、工具使用或子 Agent），大幅缩短可拆分为独立部分的任务的整体执行时间。核心思想是识别流程中彼此无依赖的部分，并将它们并行执行。
示例：LangChain 示例通过 RunnableParallel 并行执行主题摘要、问题生成和关键词提取。Google ADK 示例通过 ParallelAgent 并行运行多个调研员 Agent。
应用场景：信息收集与调研（同时搜索多个来源）、数据处理与分析（并行应用不同分析方法）、多 API 或工具交互、多组件内容生成、验证与校验、多模态处理、A/B 测试或多方案生成。
重要性：提升 Agentic 系统的效率和响应速度，尤其适用于涉及多个独立查找、计算或外部服务交互的任务。

4. 反思（Reflection）

概述：Agent 对自身的工作、输出或内部状态进行评估，并利用评估结果来提升性能或优化响应。这是一种自我纠错或自我改进机制，引入了反馈循环。
典型流程：执行 → 评估/批判 → 反思/优化 → 迭代。
实现方式：将流程分为生产者（Producer）和批评者（Critic）两个逻辑角色，由不同 Agent 或不同系统提示的 LLM 调用扮演。
示例：LangChain 示例中，Agent 迭代生成并优化 Python 函数，批评者 Agent 反复批判代码。Google ADK 示例通过 SequentialAgent 编排生成器 Agent 和审查器 Agent。
应用场景：创意写作与内容生成、代码生成与调试、复杂问题求解、摘要与信息整合、规划与策略制定、对话 Agent。
重要性：构建能够输出高质量结果、处理复杂任务、具备一定自我意识和适应性的 Agent。

5. 工具使用（Tool Use / Function Calling）

概述：Agent 通过“函数调用”机制与外部 API、数据库、服务或代码进行交互。LLM 根据用户请求或任务状态，决定何时及如何调用特定外部函数。
典型流程：工具定义 → LLM 决策 → 函数调用生成 → 工具执行 → 观察/结果 → LLM 处理。
工具与函数调用的区别：工具调用更具包容性，可指复杂 API、数据库请求，甚至面向其他 Agent 的指令。
示例：LangChain 示例中，Agent 使用 search_information 工具。CrewAI 示例中，Agent 使用 get_stock_price 工具。Google ADK 示例展示 Google Search、代码执行、Vertex AI Search 工具的使用。
应用场景：外部信息检索、与数据库和 API 交互、计算与数据分析、发送通讯、执行代码、控制其他系统或设备。
重要性：突破 LLM 训练数据限制，访问最新信息、执行内部无法完成的计算、操作用户专属数据或触发现实世界动作。

6. 规划（Planning）

概述：Agent 或 Agent 系统能够制定一系列行动，从初始状态逐步迈向目标状态的能力。计划并非预先设定，而是根据请求动态生成，并能根据新信息灵活调整。
规划与可预测性权衡：当问题解决路径已知且可重复时，限制 Agent 按固定流程执行更有效。
示例：Crew AI 示例中，规划者智能体制定并撰写摘要的计划。Google DeepResearch 和 OpenAI Deep Research API 演示了多步骤、迭代式的研究规划。
应用场景：流程自动化（新员工入职）、机器人与自主导航、结构化信息合成（生成复杂报告）、多步骤客户支持。
重要性：使 Agent 具备前瞻性思考，将复杂任务拆解为可管理的小步骤，并制定实现目标的策略。

7. 多智能体协作（Multi-Agent Collaboration）

概述：将系统结构化为多个独立且专用的 Agent 协作团队，共同实现复杂、多领域目标。通过任务分解原则，将高层目标拆分为子问题并分配给具备相应能力的 Agent。
协作形式：顺序交接、并行处理、辩论与共识、层级结构、专家团队、批评 - 审查者模式。
Agent 关系与通信结构：单 Agent、网络型、监督者、工具型监督者、层级型、定制型。
示例：Crew AI 示例中，研究员 Agent 和写作者 Agent 协作撰写博客。Google ADK 示例展示了层级、循环、顺序、并行 Agent 以及“Agent 即工具”模式。
应用场景：复杂研究与分析、软件开发、创意内容生成、金融分析、客户支持升级、供应链优化、网络分析与修复。
重要性：通过分工与协同实现集体优势，使多 Agent 系统的整体性能远超任何单一 Agent。

8. 记忆管理（Memory Management）

概述：Agent 保留并利用过去交互、观察和学习经验的信息能力。分为短期记忆（上下文窗口中的临时信息）和长期记忆（持久存储在外部知识库，如向量数据库）。
短期记忆：LLM 上下文窗口，保存当前或最近交互信息。
长期记忆：持久存储在外部，通过语义搜索检索。分为语义记忆（事实）、情景记忆（经历）和程序性记忆（规则）。
示例：Google ADK 通过 Session（聊天线程）、State（临时数据）和 MemoryService（长期知识库）管理记忆。LangChain 和 LangGraph 提供 ConversationBufferMemory、ChatMessageHistory 等工具。Vertex Memory Bank 提供托管的长期记忆服务。
应用场景：聊天机器人与对话式 AI、任务型 Agent、个性化体验、学习与提升、信息检索（RAG）、自主系统。
重要性：让 Agent 能够维护历史、学习、个性化交互，并处理复杂的时序问题，超越基础问答能力。

9. 学习与适应（Learning & Adaption）

概述：Agent 通过根据新经验和数据改变思维、行为或知识来实现学习与适应。使 Agent 能够从简单执行指令，逐步变得更智能。
学习类型：强化学习（PPO、DPO）、监督学习、无监督学习、少样本/零样本学习、在线学习、基于记忆的学习。
案例分析：自我改进编码 Agent（SICA）通过迭代优化自身代码，提升编码能力。Google AlphaEvolve 结合 LLM、自动评估和进化算法发现和优化算法。OpenEvolve 利用 LLM 迭代优化代码。
应用场景：个性化助手 Agent、交易机器人 Agent、应用 Agent、机器人与自动驾驶 Agent、反欺诈 Agent、推荐系统 Agent、游戏 AI Agent、知识库学习 Agent。
重要性：提升 Agent 能力的关键，使其能够突破预设参数，通过经验和环境交互自主改进，有效应对新情况并在无需持续人工干预的情况下优化自身表现。

10. 模型上下文协议（Model Context Protocol, MCP）

概述：MCP 是一项开放标准，为 LLM 与外部应用、数据源和工具的通信提供标准化接口，实现一致性和可预测集成的关键机制。它采用客户端 - 服务器架构，服务器暴露数据、Prompt 和可执行功能，客户端（LLM 宿主应用或 AI Agent）消费这些能力。
与工具函数调用的区别：函数调用是 LLM 直接请求预定义工具，是专有的一对一通信。MCP 则是通用框架，目标是建立一个任何合规工具都能被任何合规 LLM 访问的生态系统，促进互操作性、可组合性和复用性。
更多考量：工具、资源与 Prompt 的区别；可发现性；安全性；实现复杂度；错误处理；本地与远程服务器；按需与批量处理；传输机制。
示例：ADK 示例演示 Agent 配置 MCP 文件系统服务器、连接 UVX MCP 服务器、与 FastMCP 服务器的集成。
应用场景：数据库集成、生成式媒体编排、外部 API 交互、推理型信息抽取、自定义工具开发、标准化 LLM-应用通信、复杂流程编排、物联网设备控制、金融服务自动化。
重要性：为 LLM 与外部资源的对接提供标准化接口，解决每次集成都需要定制开发的问题，是实现复杂、互联 AI 系统不可或缺的标准化通信框架。

11. 目标设定与监控（Goal Setting & Monitoring）

概述：为 Agent 设定具体目标，并赋予其追踪进度、判断目标是否达成的能力。这使 Agent 能够有明确的方向感，判断自身行为是否有效，从而提升整体效能。
规划：Agent 根据高层目标，自动或半自动地生成一系列中间步骤或子目标。
示例：LangChain 示例中，Agent 自主生成并优化 Python 代码，通过 AI 判断代码是否达成初始目标，实现迭代优化。
应用场景：客户支持自动化、个性化学习系统、项目管理助手、自动化交易机器人、机器人与自动驾驶、内容审核。
重要性：为 Agent 提供智能自我管理的基础框架，使其能够自主可靠运行于复杂现实场景，具备主动达成目标的能力。

12. 异常处理与恢复（Exception Handling & Recovery）

概述：Agent 具备应对突发状况、错误和故障的能力。该模式旨在打造极其坚韧和弹性的 Agent，使其在面对各种困难和异常时，依然能够保持不间断的功能和运行完整性。
关键方面：错误检测、错误处理（日志记录、重试、备用方案、优雅降级、通知）、恢复（状态回滚、诊断、自我修正、升级处理）。
示例：ADK 示例中，鲁棒位置查询系统包含 primary_handler 和 fallback_handler，实现分层位置查询与异常处理。
应用场景：客服聊天机器人处理数据库错误、自动化金融交易应对市场异常、智能家居代理解决设备故障、数据处理 Agent 遇到损坏文件、网页爬虫 Agent 遇到网站结构变化、机器人制造业部件错位。
重要性：将 AI 智能体从脆弱不可靠的系统转变为坚实可靠的组件，使其在充满挑战和高度不可预测的环境中高效、弹性运行。

13. 人类参与环节（Human-in-the-Loop, HITL）

概述：有意识地将人类认知的独特优势（判断力、创造力、细致理解）与 AI 的计算能力和高效性相结合。确保 AI 在伦理边界内运行，遵循安全协议，并以最佳效果达成目标。
关键方面：人类监督、干预与纠正、人类反馈用于学习、决策增强、人机协作、升级策略。
Human-on-the-loop：人类专家制定总体策略，AI 负责即时执行以确保合规。
示例：ADK 示例中，基于 HITL 的技术支持 Agent 在复杂或敏感问题时，可请求人类介入（escalate_to_human 工具）。
应用场景：内容审核、自动驾驶、金融欺诈检测、法律文档审查、客户支持（复杂问题）、数据标注与注释、生成式 AI 优化、自动化网络管理。
重要性：将人类监督、战略输入和协作互动视为不可或缺，确保 AI 系统始终与人类伦理、价值观、目标和社会期望保持一致。

14. 知识检索（Retrieval Augmented Generation, RAG）

概述：RAG 模式显著增强了 LLM 的能力，使其在生成响应前能够访问外部知识库。系统通过语义搜索从知识库中检索相关信息，并将其“增强”到原始提示中，再送入 LLM 生成响应。
核心概念：嵌入、文本相似度、语义相似度与距离、文档分块、向量数据库。
RAG 的挑战：答案所需信息分散、检索质量（引入噪声）、整合矛盾信息、知识库预处理与同步、性能延迟与成本。
图 RAG（GraphRAG）：利用知识图谱进行信息检索，通过遍历实体间关系回答复杂问题，提供更具上下文和细致度的答案。
Agentic RAG：RAG 的进化版，引入推理和决策层。Agent 主动审查检索结果的质量、相关性和完整性，调和知识冲突，多步推理综合复杂答案，识别知识空缺并调用外部工具。
示例：Google Search 工具实现 RAG。ADK 利用 Vertex AI RAG 能力。LangChain 示例通过 Weaviate 向量库实现 RAG 流程。
应用场景：企业搜索与问答、客户支持与服务台、个性化内容推荐、新闻与时事摘要。
重要性：让 LLM 能够访问并集成外部、最新、特定场景的信息，从而提升输出的准确性、相关性和事实基础，突破 LLM 训练数据的限制。

15. 智能体间通信（Agent-to-Agent, A2A）

概述：A2A 协议是一项开放标准，旨在实现不同 AI 智能体框架之间的通信与协作，确保互操作性。它得到了众多科技公司和开源社区的支持。
核心概念：用户、A2A 客户端（客户端 Agent）、A2A 服务器（远程 Agent）；Agent Card（Agent 的数字身份）；Agent 发现（Well-Known URI、管理型注册表、直接配置）；通信与任务（异步任务、消息、artifact、HTTP/JSON-RPC 2.0 协议、contextId）；交互机制（同步请求/响应、异步轮询、流式更新、推送通知）；安全性（双向 TLS、完整审计日志、Agent Card 声明、凭证处理）。
A2A 与 MCP 对比：MCP 关注 Agent 与外部数据和工具的上下文结构化，而 A2A 专注于 Agent 间的协调与通信。
示例：ADK Agent 示例演示如何用 Google 认证工具搭建 A2A 服务器。
应用场景：多框架协作、自动化工作流编排、动态信息检索。
重要性：使得不同框架构建的 AI 智能体能够高效协作，实现无缝协调、任务委托和信息交换，是构建复杂 AI 解决方案不可或缺的基础。

16. 资源感知优化（Resource-Aware Optimization）

概述：Agent 在运行过程中动态监控和管理计算、时间和财务资源。其核心是在指定资源预算内实现目标或优化效率，如在更准确但昂贵的模型与更快、低成本模型之间进行选择。
回退机制：当首选模型不可用时，系统自动切换到默认或更经济的模型，保证服务连续性。
示例：LangChain 示例中，路由 Agent 根据查询长度分流到 Gemini Flash（经济型）或 Gemini Pro（高阶型）。OpenAI 示例将问题分类为 simple、reasoning 或 internet_search，选择最合适且经济的处理路径。OpenRouter 提供统一接口实现自动故障转移和成本优化。
其他资源优化技术：动态模型切换、自适应工具选择、上下文剪枝与摘要、主动资源预测、成本敏感探索、能效部署、并行与分布式计算感知、学习型资源分配策略、优雅降级与回退机制。
应用场景：成本优化的 LLM 使用、延迟敏感操作、能效优化、服务可靠性回退、数据使用管理、自适应任务分配。
重要性：确保 Agent 在有限资源下高效运行，提升整体效能和目标达成度。

17. 推理技术（Reasoning Techniques）

概述：Agent 的高级推理方法，重点关注多步逻辑推理和问题分解。通过在推理阶段分配更多计算资源，提升准确性、连贯性和鲁棒性。
推理技术：
链式思维（Chain-of-Thought, CoT）：引导模型生成一系列中间推理步骤，提升多步推理任务表现。
树式思维（Tree-of-Thought, ToT）：在 CoT 基础上扩展，探索多条推理路径，支持回溯、自我纠错和多方案评估。
自我纠错（Self-correction）：Agent 对生成内容进行自我评估和迭代优化。
程序辅助语言模型（PALMs）：将 LLM 与符号推理结合，生成并执行代码。
可验证奖励强化学习（RLVR）：训练模型生成长推理链，支持自我纠错和回溯。
ReAct（推理与行动）：将 CoT 推理与 Agent 工具交互结合，形成“思考 - 行动 - 观察”循环。
CoD（辩论链）：多个模型协作辩论解决问题。
GoD（辩论图）：将讨论建模为动态非线性网络。
MASS（多 Agent 系统搜索）：通过多阶段优化，自动探索和优化 MAS 设计空间。
推理扩展定律：LLM 性能与推理阶段分配计算资源的关系，通过增加计算资源，小模型也能获得优异结果。
示例：Google 开源 DeepSearch 代码（基于 Gemini 2.5 和 LangGraph），Agent 通过反思推理识别知识空缺并迭代优化答案。
Agent 如何“思考”：结构化方法，结合推理与行动，通过 LLM 生成“思考”，指导后续行动（搜索、信息检索），直到任务完成。
应用场景：复杂问答、数学问题求解、代码调试与生成、战略规划、医学诊断、法律分析。
重要性：使 Agent 能够拆解问题、考虑中间步骤，并得出更稳健、准确的结论，是自主 Agent 发展的基础。

18. 护栏与安全模式（ & Safety Patterns）

概述：护栏是确保 Agent 安全、合规、按预期运行的关键机制。它们作为保护层，引导 Agent 行为和输出，防止有害、偏见、无关或其他不良响应。
实施阶段：输入验证/清洗、输出过滤/后处理、行为约束、工具使用限制、外部内容审核 API、人类介入（Human-in-the-Loop）。
注意事项：可采用计算资源消耗较低的模型作为额外防线，对主模型的输入或输出进行预筛查。
示例：CrewAI 示例中，policy_enforcer_agent 通过 SAFETY_GUARDRAIL_PROMPT 和 Pydantic 护栏筛查用户输入。Vertex AI 示例展示工具调用前的参数校验回调。
工程化可靠 Agent：遵循传统软件工程原则（模块化、结构化日志、最小权限原则、检查点与回滚），将 Agent 视为复杂系统。
应用场景：客服聊天机器人、内容生成系统、教育助教/辅导员、法律研究助手、招聘与人力资源工具、社交媒体内容审核、科研助手。
重要性：确保 Agent 运行稳健、可信且有益，构建负责任的 AI 系统，降低风险，维护用户信任。

19. 评估与监控（Evaluation & Monitoring）

概述：Agent 系统性评估自身性能、监控目标进展以及检测运行异常的方法。包括指标定义、反馈回路建立和报告系统实现，确保 Agent 在实际环境中的表现符合预期。
评估指标：Agent 响应评估（事实正确性、流畅度、语法精度、用户意图符合度）、延迟监控、LLM 交互 Token 用量追踪、LLM 评审（自定义“有用性”指标）。
评估方法对比：人工评估、LLM 评审、自动化指标。
Agent 轨迹评估：分析 Agent 执行任务时的完整日志，包括决策质量、推理过程和最终结果。
多 Agent 评估：评估各 Agent 分工和整体协作，如是否有效协作、是否制定并遵循合理计划、是否选择了合适 Agent。
从 Agent 到高级“承包商”：将 AI Agent 从概率性、易出错系统升级为更确定、可问责的“承包商”，通过正式合同、动态协商与反馈、质量导向迭代执行、分层分解与子合同，实现可客观验证的结果。
Google ADK 框架：支持 Web UI、pytest 集成和命令行自动化评估。
应用场景：生产环境性能追踪、A/B 测试优化、合规与安全审计、企业系统治理（AI“合同”）、漂移检测、异常行为检测、学习进度评估。
重要性：保障 Agent 持续性能，实现持续改进、A/B 测试和异常检测，确保 Agent 始终符合目标。

20. 优先级排序（Prioritization）

概述：Agent 根据任务的重要性、紧急性、依赖关系和既定标准进行评估和排序，确保 Agent 将精力集中在最关键的任务上，从而提升整体效能和目标达成度。
核心要素：标准定义（紧急性、重要性、依赖关系、资源可用性、成本/收益、用户偏好）、任务评估、调度或选择逻辑、动态优先级调整。
应用层级：总体目标选择、规划步骤排序、从可选项中选择下一步行动。
示例：LangChain 示例中，项目经理智能体自动创建、排序并分配任务，展示了项目管理自动化。
应用场景：自动化客户支持、云计算资源调度、自动驾驶系统、金融交易、项目管理、网络安全、个人助理 AI。
重要性：Agent 在面对多重需求、资源有限、时间紧迫、目标可能冲突的真实场景时，能够做出明智决策，有效管理任务和目标。

21. 探索与发现（Exploration & Discovery）

概述：Agent 能够主动寻找新信息、发现新可能性并识别“未知的未知”。其核心在于 Agent 主动进入陌生领域，尝试新方法，并生成新的知识或理解。
Google Co-Scientist：Google Research 开发的科学协作 AI 系统，基于 Gemini LLM，辅助人类科学家进行假设生成、方案完善和实验设计。采用多代理框架，核心代理包括生成代理、反思代理、排序代理、进化代理、邻近代理和元评审代理。
Agent Laboratory：开源科研工作流框架，旨在增强而非取代人类科学研究。通过专用 LLM 自动化科研各阶段，包括文献综述、实验阶段、报告撰写和知识共享。
应用场景：科学研究自动化、游戏策略生成、市场调研与趋势发现、安全漏洞发现、创意内容生成、个性化教育与培训。
重要性：对于在开放式、复杂或快速变化领域中工作的 Agent 至关重要，因为静态知识或预编程方案已无法满足需求。它强调 Agent 扩展自身认知和能力的能力。

结论：Agentic 设计的未来

本书将 Agent 构建视为技术画布上的艺术创作。21 种 Agentic 设计模式是构建智能系统的工具箱，它们赋予大语言模型的认知能力以可靠性与目标性，使其超越简单的响应式模型，成为主动、目标导向、具备复杂推理与行动能力的 Agent。

Agentic 核心原则回顾

核心执行与任务分解：Prompt Chaining（线性分步拆解）、Routing（条件逻辑选择路径）、Parallelization（并行执行提升效率）、Planning（制定多步计划）。
与外部环境交互：Tool Use（函数调用，调用外部 API/数据库）、Knowledge Retrieval（RAG，查询知识库整合信息）。
状态、学习与自我提升：Memory Management（短期上下文、长期知识）、Reflection 与 Self-Correction（自我批判、迭代优化）、Learning and（根据反馈和经验进化）。
协作与沟通：Multi-Agent Collaboration（多个专职 Agent 协同）、Inter-Agent Communication (A2A) 与 Model Context Protocol (MCP)（规范 Agent 与工具的信息交换）。

这些模式的组合是 Agentic 设计的真正力量，将单一能力转化为强大的自主系统。

展望未来

更高级的自主性与推理能力：Agent 需应对模糊性、进行抽象与因果推理，甚至具备常识。将从“人类参与”转变为“人类监督”。
Agent 生态与标准化：将出现开放平台与市场，MCP 和 A2A 等协议将成为行业标准。
安全性、对齐性与鲁棒性：需确保 Agent 的学习与适应不会偏离初衷，抵御攻击，应对不可预测的现实场景，需要新的“安全模式”和工程规范。

Jimmy Song | 宋净超修改