diff --git a/.vscode/settings.json b/.vscode/settings.json
index ac73ba9674..46bc5a7273 100644
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -10,5 +10,6 @@
"springframework"
],
"Codegeex.RepoIndex": true,
- "files.autoSave": "afterDelay"
+ "files.autoSave": "afterDelay",
+ "codingcopilot.httpProxySettings": "system"
}
\ No newline at end of file
diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js
index f97454f809..2b75a96587 100644
--- a/docs/.vuepress/config.js
+++ b/docs/.vuepress/config.js
@@ -751,22 +751,26 @@ module.exports = {
text: 'LangChain4j',
link: '/md/AI/langchain4j/01-intro'
},
- {
- text: 'MCP',
- link: '/md/AI/mcp/mcp-fad-or-fixture'
- },
{
text: '大模型发展',
link: '/md/AI/llm/GPTs'
},
{
text: 'Prompt工程',
- link: '/md/AI/prompt/01-Prompt网站'
+ link: '/md/AI/prompt/prompt-website'
},
{
text: 'AI Agent',
link: '/md/AI/agent/changelog-cursor'
},
+ {
+ text: 'MCP',
+ link: '/md/AI/mcp/mcp-fad-or-fixture'
+ },
+ {
+ text: 'A2A',
+ link: '/md/AI/a2a/a2a-a-new-era-of-agent-interoperability'
+ },
]
},
@@ -797,6 +801,11 @@ module.exports = {
link: '/md/chain/01-以太坊智能合约与高级语言.md'
},
+ {
+ text: '隐私计算',
+ link: '/md/chain/隐私计算技术原理.md'
+ },
+
]
},
@@ -1179,8 +1188,9 @@ module.exports = {
collapsable: false,
sidebarDepth: 0,
children: [
- "MQTT与Kafka在物联网消息与流数据集成实践",
- "07-MQTT发布订阅模式介绍"
+ "mqtt-kafka-iot-message-streaming-integration",
+ "mqtt-publish-subscribe-intro",
+ "avoid-bare-parsefrom-mqtt-protobuf-consumption",
]
}],
@@ -1246,15 +1256,16 @@ module.exports = {
sidebarDepth: 0,
children: [
"java-se-support-roadmap",
- "Java9新特性概述",
+ "Java9-new-features",
"jdk14-new-features-complete-guide",
- "JDK16新特性",
+ "Java16-new-features",
"understanding-java17-new-features-sealed-classes",
- "JDK21新特性",
- "JDK22新特性",
- "JDK23新特性",
+ "Java21-new-features",
+ "Java22-new-features",
+ "Java23-new-features",
"java24-new-features",
"java2024",
+ "java-news-roundup-jun02-2025",
]
},
@@ -1397,7 +1408,7 @@ module.exports = {
"03-Tomcat的生命周期管理",
"04-Tomcat实现热部署、热加载原理解析",
"05-Tomcat如何打破双亲委派机制实现隔离Web应用的？",
- "Tomcat进程占用CPU过高怎么办？",
+ "how-to-solve-high-cpu-usage-in-tomcat-process",
]
}],
@@ -1501,6 +1512,8 @@ module.exports = {
"为什么临时表可以重名？",
"为什么阿里不推荐使用MySQL分区表？",
"一文看懂这篇MySQL的锁机制",
+ "mysql-transaction-isolation-mechanism",
+ "mysql-index-left-most-matching-rule",
]
},
@@ -1515,6 +1528,7 @@ module.exports = {
"MySQL查询优化",
"MySQL深分页调优实战",
"online-sql-deadlock-incident-how-to-prevent-deadlocks",
+ "optimize-slow-queries-massive-row-deletions",
]
},
@@ -1542,7 +1556,7 @@ module.exports = {
"05-流式操作：如何使用 Flux 和 Mono 高效构建响应式数据流？",
]
}],
-
+
"/md/sentinel/": [{
title: "Sentinel基础",
collapsable: false,
@@ -1679,10 +1693,11 @@ module.exports = {
children: [
"00-Kafka专栏大纲",
"01-为何大厂都选择Kafka作为消息队列",
+ "kafka-core-components",
"Kafka门派知多少",
"08-全网最全图解Kafka适用场景",
"09-消息队列的消息大量积压怎么办？",
- "13-KafkaAdminClient",
+ "kafka-operations-tool-exploring-adminclient-principles-and-practices",
"15-基于kafka实现延迟队列",
"kafka-transaction-implementation",
"kafka-versions",
@@ -2153,10 +2168,22 @@ module.exports = {
"lm-studio-transform-mac-into-ai-tool",
"navigating-llm-deployment-tips-tricks-and-techniques",
"only-ai-flow-can-do",
- "chatgpt-canva",
"llm-reasoning-limitations",
"making-an-llm-that-sees-and-reasons",
"lmstudio-local-llm-call",
+ "inference-engine",
+ "cuda",
+ "gpullama3-java-gpu-llm",
+ ]
+ },
+ {
+ title: "ChatGPT",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "chatgpt-canva",
+ "memory-faq",
+ "GPT-5",
]
},
{
@@ -2166,6 +2193,7 @@ module.exports = {
children: [
"qwen-QwQ",
"qwen3",
+ "qwen3-coder",
]
},
@@ -2178,6 +2206,16 @@ module.exports = {
]
},
+ {
+ title: "Kimi",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "Kimi-K2",
+ "kimi-k2-whats-fuss-whats-like-use",
+ ]
+ },
+
{
title: "Claude",
collapsable: false,
@@ -2187,6 +2225,17 @@ module.exports = {
"计算机使用功能",
"claude-3-7-sonnet",
"claude-4",
+ "claude-4-5-sonnet",
+ ]
+ },
+
+ {
+ title: "Grok",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "grok4",
+ "grok-code-fast",
]
},
@@ -2214,6 +2263,7 @@ module.exports = {
"boost-ai-workflow-resilience-with-error-handling",
"introducing-parent-child-retrieval-for-enhanced-knowledge",
"dify-v1-0-building-a-vibrant-plugin-ecosystem",
+ "dify-v1-1-0-filtering-knowledge-retrieval-with-customized-metadata",
"dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights",
"dify-agent-and-zapier-mcp-unlock-ai-automation",
]
@@ -2327,29 +2377,102 @@ module.exports = {
]
},
{
- title: "辅助编程",
+ title: "cursor",
collapsable: false,
sidebarDepth: 0,
children: [
"changelog-cursor",
+ ]
+ },
+
+ {
+ title: "kiro",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "kiro",
+ ]
+ },
+
+ {
+ title: "trae",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "trae",
+ "solo",
+ "trae-update",
+ ]
+ },
+
+ {
+ title: "CodeBuddy",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "codebuddy",
+ ]
+ },
+
+ {
+ title: "windsurf",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
"goodbye-cursor-hello-windsurf",
- "Junie",
- "introducing-codex",
+ "windsurf-update",
+ ]
+ },
+
+ {
+ title: "qoder",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "qoder",
+ ]
+ },
+
+ {
+ title: "Cline",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "cline",
+ ]
+ },
+
+ {
+ title: "Roo Code",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "roocode",
]
},
- ],
- "/md/AI/agent/dify/": [{
- title: "快速上手",
+ {
+ title: "Augment",
collapsable: false,
sidebarDepth: 0,
children: [
- "ai-agents-dont-security-nightmare",
- "improve-quality-gen-ai",
+ "augment",
+ ]
+ },
+ {
+ title: "Dify基础",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "what-is-llmops",
+ "configuring-models-in-dify",
+ "Build-App-with-Dify",
+ "integrate-dify-and-aws-services-to-enable-more-flexible-translation-workflows",
+ "llm-knowledge-base-segmentation-data-cleaning",
]
},
{
- title: "案例",
+ title: "Dify案例",
collapsable: false,
sidebarDepth: 0,
children: [
@@ -2359,6 +2482,15 @@ module.exports = {
"introducing-codex",
]
},
+
+ {
+ title: "Perplexity",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "perplexity-labs",
+ ]
+ },
],
"/md/AI/mcp/": [{
@@ -2381,6 +2513,16 @@ module.exports = {
},
],
+ "/md/AI/a2a/": [{
+ title: "A2A",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "a2a-a-new-era-of-agent-interoperability",
+ ]
+ },
+ ],
+
"/md/AI/spring-ai-alibaba/": [{
title: "Spring AI Alibaba",
collapsable: false,
@@ -2395,8 +2537,8 @@ module.exports = {
collapsable: false,
sidebarDepth: 0,
children: [
- "01-Prompt网站",
- "02-常用Prompt",
+ "prompt-website",
+ "prompt-toollist",
]
}, ,],
@@ -2425,6 +2567,7 @@ module.exports = {
"03-core-of-rag-result-retrieval-and-reordering",
"04-prompt-helping-llm-understand-knowledge",
"2025-future-rag-trends-four-technologies",
+ "why-vector-embeddings-are-here-to-stay",
]
},
{
@@ -2529,6 +2672,7 @@ module.exports = {
sidebarDepth: 0,
children: [
"01-单一职责原则",
+ "open-close-principle",
"rest-api-design-resource-modeling",
]
},
diff --git a/docs/md/AI/a2a/a2a-a-new-era-of-agent-interoperability.md b/docs/md/AI/a2a/a2a-a-new-era-of-agent-interoperability.md
new file mode 100644
index 0000000000..47271d5f00
--- /dev/null
+++ b/docs/md/AI/a2a/a2a-a-new-era-of-agent-interoperability.md
@@ -0,0 +1,288 @@
+# Agent2Agent (A2A) 协议发布
+
+
+
+## 1 智能体互操作性的新时代
+
+通过自主处理大量日常重复性或复杂性任务，AI智能体为提高人们工作效率带来独特机遇。如今，企业正在构建和部署越来越多的自主智能体，以便扩展、自动化和改进工作场所的各种流程，如订购新笔记本电脑、协助客户服务代表和协助供应链规划。
+
+为最大限度发挥智能体 AI 优势，这些智能体须能在横跨孤立数据系统和应用程序的动态、多智能体生态系统中协作。即使智能体由不同供应商构建或在不同的框架中构建，也能实现智能体之间的互操作性，这将提高自主性并成倍提高生产力，同时降低长期成本。
+
+今天，Google发布Agent2Agent (A2A) 全新开放协议，Atlassian、Box、Cohere、Intuit、Langchain、MongoDB、PayPal、Salesforce、SAP、ServiceNow、UKG 和 Workday 等 50 多家技术合作伙伴及埃森哲、BCG、Capgemini、Cognizant、德勤、HCLTech、Infosys、毕马威、麦肯锡、普华永道、TCS 和 Wipro 等领先服务提供商均支持。
+
+凭借 A2A 协议，AI 智能体能在各种企业平台或应用程序之上相互通信、安全交换信息和协调操作。A2A 框架将为客户创造巨大的价值，他们的 AI 智能体将服务于整个企业的各类应用程序资产。
+
+这种协作努力体现人们对未来的共同愿景，即无论底层技术如何，AI 智能体都能无缝协作，以自动化复杂企业工作流程，推动效率与创新达到前所未有的高度。
+
+A2A 是一个开放协议，是对MCP的补充，MCP为智能体提供了有用的工具和上下文。借鉴 Google 在扩展智能体系统方面的内部专业知识，我们设计了 A2A 协议，以应对我们在为客户部署大规模、多智能体系统时遇到的挑战。借助 A2A 协议，开发者可以构建能够与使用该协议构建的任何其他智能体建立连接的智能体，让用户能够灵活地组合来自各种提供商的智能体。至关重要的是，企业可以受益于这种标准化方法，跨不同平台和云环境管理其智能体。我们相信，这种通用的互操作性对于充分发挥协作 AI 智能体的潜力至关重要。
+
+
+
+## 2 A2A设计原则
+
+A2A 是一种开放协议，提供了一种让智能体相互协作的标准方式，无论其底层框架或供应商是什么。与合作伙伴一起设计该协议时，坚持五大关键原则：
+
+- 拥抱智能体能力：A2A聚焦于让智能体以其自然、非结构化的方式进行协作，即使彼此没有共享内存、工具和上下文，也能高效协作。我们将实现真正的多智能体场景，不再将智能体仅仅看作是“工具”
+
+- 依托现有标准构建：该协议是基于 HTTP、SSE、JSON-RPC等当下主流标准构建而成，即其能更轻松与企业当前日常使用的 IT 堆栈进行集成
+
+- 默认安全：A2A旨在支持企业级身份验证和授权，并在发布时与 OpenAPI 的身份验证方案保持对等
+
+- 支持长时间运行的任务：A2A非常灵活，支持各种场景，可出色完成从快速任务到深入研究（在有人类参与时，可能需数小时甚至数天时间才能完成）的所有任务。在整个过程中，A2A 可以向用户提供实时反馈、通知和状态更新
+
+- 模式不受限：智能体世界不仅限于文本，这就是为什么我们将 A2A 设计为支持各种模式，包括音频和视频流
+
+## 3 A2A工作原理
+
+一个说明远程Agent和客户端Agent之间数据流的插图流程图，以产生安全协作、任务和状态管理、用户体验协商及能力发现
+
+
+
+A2A方便了“客户端”智能体与“远程”智能体之间的通信。客户端智能体负责制定和传达任务，而远程智能体负责执行这些任务，力图提供正确的信息或采取正确的行动。这种交互涉及几个关键功能：
+
+- 能力发现：智能体可用 JSON 格式“智能体卡”来宣传其能力，使客户端智能体能识别出能执行任务的最佳智能体，并利用 A2A 与远程智能体进行通信
+
+- 任务管理：客户端智能体与远程智能体之间的通信以完成任务为导向，智能体在其中努力完成最终用户的请求。该“任务”对象由协议定义，且具有生命周期。任务可立即完成，而长时间运行的任务，每个智能体都可进行通信，以便彼此之间保持同步，了解任务完成情况的最新状态。任务的输出被称为“工件”
+
+- 协作：智能体可相互发送信息，交流上下文、回复、工件或用户指令
+
+- 用户体验协商：每条消息都包含“部件”，“部件”是一个完整的内容片段，如生成的图像。每个部件都有指定的内容类型，允许客户端和远程智能体协商所需的正确格式，并明确包括用户界面功能的协商，如 iframe、视频、网页表单等
+
+参阅[规范草案](https://github.com/google/A2A)，了解协议工作原理的完整细节。
+
+## 3 真实案例：搜寻候选人
+
+通过 A2A 协作，可大大简化软件工程师招聘过程。在 Agentspace 这样的统一界面中，用户（如招聘经理）可以要求其智能体寻找符合职位列表、地点和技能组合的候选人。然后，智能体与其他专业智能体互动，寻找潜在的候选人。用户收到这些建议后，可指示其智能体安排进一步面试，简化候选人搜寻流程。面试流程结束后，还可让另一个智能体协助背调。这这只是 AI 智能体需要跨系统协作以寻找合格求职者的一个示例。
+
+## 4 智能体互操作性的未来
+
+A2A有望开启智能体互操作性的新时代，推动创新浪潮，构建功能更强大、用途更广泛的智能体系统。我们坚信，该协议将为未来智能体发展奠定基础，促使智能体无缝协作以攻克复杂难题，提升我们生活品质。
+
+致力于与合作伙伴和社区公开合作构建该协议。开源方式发布该协议，并建立明确贡献途径。可在 [A2A 网站](https://google.github.io/A2A)查看[完整版规范草案](https://github.com/google/A2A)、试用代码示例和查看示例场景，并了解贡献方式。
+
+正与合作伙伴合作，计划今年晚些推出可用于生产的协议版本。
+
+## 5 A2A技术合作伙伴反馈
+
+### ask-ai.com
+
+> Ask-AI 很高兴与 Google 合作开发 A2A 协议，共同塑造 AI 互操作性和无缝智能体协作的未来，从而提升其在企业 AI 客户体验领域的领导地位。
+> ——Alon Talmor 博士，首席执行官
+
+### Atlassian
+
+> 凭借 Atlassian 对 Rovo 智能体的投资，像 A2A 这样的标准化协议的开发将帮助智能体成功地发现、协调和推理彼此，从而实现更丰富的授权和大规模协作形式。
+> ——Brendan Haire，Atlassian 的 AI 平台工程副总裁
+
+### Articul8
+
+> 在 Articul8，我们认为 AI 必须协作和互操作，才能真正跨企业扩展。我们很高兴支持 A2A 互操作性协议的开发，该计划与我们提供跨复杂系统和工作流程无缝运行的特定领域 GenAI 功能的使命完美契合。我们正在使 Articul8 的 ModelMesh（“智能体中的智能体”）将 A2A 视为一等公民，从而实现智能智能体之间的安全、无缝通信。
+> —— Arun Subramaniyan，Articul8 创始人兼首席执行官
+
+### Arize AI
+
+> Arize AI很荣幸与 Google 合作，成为 A2A 互操作性协议的产品发布合作伙伴，从而推进跨 AI 智能体的无缝、安全交互，这是 Arize 对开源评估和可观测性框架立场承诺的一部分。
+> ——Jason Lopatecki，Arize AI 联合创始人兼首席执行官
+
+### BCG
+
+> BCG 帮助重新设计以智能为核心的组织。像 A2A 这样开放和可互操作的功能可以加速这一进程，从而实现可持续的、自主的竞争优势。
+> —— *Djon Kleine，BCG 合伙人兼总经理*
+
+### Box
+
+> 我们期待扩大与 Google 的合作，使 Box 智能体能够使用 A2A 与 Google Cloud 的智能体生态系统协同工作，共同创新以塑造 AI 智能体的未来，同时使组织能够更好地自动化工作流程、降低成本并生成值得信赖的 AI 输出。*
+> ——Ketan Kittur，Box 的产品管理、平台和集成副总裁*
+
+### **C3 AI**
+
+> 在 C3 AI，我们认为开放、可互操作的系统是使企业 AI 在现实世界发挥作用和创造价值的关键，A2A 有潜力帮助客户打破孤岛，并安全地使 AI 智能体在系统、团队和应用程序之间协同工作。
+> —— *Nikhil Krishnan，C3 AI 高级副总裁兼负责数据科学的首席技术官*
+
+### **Chronosphere**
+
+> A2A 将支持可靠且安全的智能体专业化和协调，为计算编排的新时代打开大门，使公司能够更快、更可靠地交付产品和服务，并使他们能够将工程工作重点放在推动创新和创造价值上。*
+> ——Rob Skillington，创始人兼首席技术官*
+
+### **Cognizant**
+
+> “作为企业多智能体系统的先驱，Cognizant 致力于实现智能体互操作性，并主动将其视作我们客户的关键要求。”
+> —— *Babak Hodjat，AI 首席技术官*
+
+### **Cohere**
+
+> 在 Cohere，我们正在构建企业放心地采用自主智能体所需的安全 AI 基础设施，而开放的 A2A 协议可确保即使在气隙环境中也能实现无缝、可信的协作，使企业能够在不影响控制或合规性的情况下进行大规模创新。*
+> ——Autumn Moulder，Cohere 工程副总裁*
+
+### **Confluent**
+
+> A2A 使智能智能体能够建立直接、实时的数据交换，简化复杂的数据管道，从根本上改变智能体的通信方式并促进决策。*
+> ——Pascal Vantrepote，Confluent 创新高级总监*
+
+### **Cotality（原 CoreLogic）**
+
+> A2A 为智能、实时通信和协作的新时代打开了大门，Cotality 将其带给房屋贷款、保险、房地产和政府领域的客户，帮助他们提高生产力，加快决策速度。*
+> ——Sachin Rajpal，Cotality 数据解决方案总经理*
+
+### **DataStax**
+
+> DataStax 很高兴能成为 A2A 的一部分，并探索如何利用它为 Langflow 提供支持，这是迈向真正可互操作的 AI 系统的重要一步，这些系统可以协作完成跨多个环境的复杂任务。*
+> ——Ed Anuff，DataStax 首席产品官*
+
+### **Datadog**
+
+> 我们很高兴看到 Google Cloud 推出 A2A 协议，以简化复杂智能体系统的开发，这将帮助 Datadog 使其用户能够构建更具创新性、更优的和更安全的智能体 AI 应用程序。*
+> ——Yrieix Garnier，Datadog 产品副总裁*
+
+### **Elastic**
+
+> Elastic 支持开放、可互操作的智能体生态系统这一愿景，期待与 Google Cloud 和其他行业领导者合作开发 A2A，并提供其数据管理和工作流程编排经验来改进该协议。*
+> ——Steve Kearns，Elastic 副总裁兼搜索业务总经理*
+
+### **GrowthLoop**
+
+> A2A 有潜力加速 GrowthLoop 为我们的客户实现复合营销的愿景——使我们的 AI 智能体能够与其他专业智能体无缝协作，更快地从企业数据中学习，并快速优化整个营销生态系统中的活动，同时尊重客户云基础设施上的数据隐私。*
+> ——Anthony Rotio，GrowthLoop 首席数据战略官*
+
+### **Harness**
+
+> Harness 很高兴支持 A2A，并致力于通过将 AI 驱动的智能集成到软件生命周期的每个阶段来简化开发者体验，从而使团队能够从运行时数据中获得更深入的见解，自动化复杂的工作流程，提高系统性能。*
+> ——Gurashish Brar，Harness 工程主管*
+
+### **Incorta**
+
+> Incorta 很高兴支持 A2A 并推进客户的智能体通信，使未来的企业自动化更智能、更快速，并真正实现数据驱动。*
+> ——Osama Elkady，Incorta 首席执行官*
+
+### **Intuit**
+
+> Intuit 坚信，像 A2A 这样的开源协议将支持复杂的智能体工作流程，加速我们的合作伙伴集成，并通过有效协作的跨平台智能体推动行业向前发展。*
+> ——Tapasvi Moturu，Intuit 的智能体框架软件工程副总裁*
+
+### **JetBrains**
+
+> 我们很高兴成为 A2A 的产品发布合作伙伴，该计划增强了智能体协作，使我们更接近真正的多智能体世界，为 JetBrains IDE、团队工具和 Google Cloud 的开发者赋能。*
+> ——Vladislav Tankov，JetBrains 的 AI 总监*
+
+### **JFrog**
+
+> JFrog 很高兴加入 A2A 协议，我们认为该计划将有助于克服当今的许多集成挑战，并将成为新一代智能体应用程序的关键驱动力。*
+> ——Yoav Landman，JFrog 首席技术官兼联合创始人*
+
+### **LabelBox**
+
+> A2A 是充分发挥 AI 智能体潜力的关键一步，它支持 AI 真正增强人类能力、实现复杂工作流程自动化和推动创新的未来。*
+> ——创始人兼首席执行官 Manu Sharma*
+
+### **LangChain**
+
+> LangChain 认为，智能体与其他智能体交互是指日可待的未来，我们很高兴与 Google Cloud 合作，提出一个满足智能体构建者和用户需求的共享协议。*
+> ——Harrison Chase，LangChain 联合创始人兼首席执行官*
+
+### **MongoDB**
+
+> 通过将 MongoDB 强大的数据库基础设施和混合搜索功能与 A2A 和 Google Cloud 的前沿 AI 模型相结合，企业可以释放零售、制造等行业的新可能性，从而重新定义 AI 应用程序的未来。*
+> ——Andrew Davidson，MongoDB 产品高级副总裁*
+
+### **Neo4j**
+
+> Neo4j 很荣幸与 Google Cloud 合作，将我们的图技术知识图谱和 GraphRAG 功能与 A2A 相结合，帮助组织释放新的自动化和智能水平，同时确保智能体交互在上下文中保持相关、可解释和值得信赖。*
+> ——Sudhir Hasbe，Neo4j 首席产品官*
+
+### **New Relic**
+
+> 我们相信，Google Cloud 的 A2A 协议与 New Relic 的智能可观测性平台之间的协作，将通过简化集成、促进跨不同系统的数据交换，并最终创建一个更统一的 AI 智能体生态系统，为我们的客户提供显著价值。*
+> ——Thomas Lloyd，New Relic 首席业务和运营官*
+
+### **Pendo**
+
+> 我们很荣幸与 Google Cloud 的 A2A 协议合作，这将是使 AI 智能体能够有效协同工作，同时保持大规模信任和可用性的关键一步。
+> —— *Rahul Jain，Pendo 联合创始人兼首席产品官*
+
+### **PayPal**
+
+> PayPal 支持 Google Cloud 的 A2A 协议，这代表着开发者和商家创建由智能体 AI 驱动的新一代商业体验的新方式。*
+> ——Prakhar Mehrotra，PayPal 高级副总裁兼人工智能主管*
+
+### **普华永道**
+
+> 在普华永道，我们相信企业 AI 的未来在于无缝协作，它不仅仅是人员和系统之间的协作，还有智能体之间的协作；因此，我们很荣幸能与普华永道的智能体操作系统协作支持 A2A，帮助制定企业级的安全、可扩展的智能体互操作性标准。
+> —— *Dallas Dolen，全球 Google Cloud 联盟负责人*
+
+### **SAP**
+
+> SAP 致力于与 Google Cloud 和更广泛的生态系统合作，通过 A2A 协议塑造智能体互操作性的未来，这是使 SAP Joule 和其他 AI 智能体能够跨企业平台无缝协作，并释放端到端业务流程的全部潜力的关键一步。*
+> ——Walter Sun，高级副总裁兼 AI 工程全球主管*
+
+### **Salesforce**
+
+> Salesforce 正在率先支持 A2A 标准，以扩展我们的开放平台，使 AI 智能体能够在 Agentforce 和其他生态系统中无缝协作，将脱节的功能转化为精心设计的解决方案，并为客户和员工提供增强的数字化劳动力。*
+> ——产品架构副总裁 Gary Lerhaupt*
+
+### **ServiceNow**
+
+> ServiceNow 和 Google Cloud 正在合作，为智能体间互操作性设定新的行业标准，我们相信 A2A 将为更高效、更互联的支持体验奠定基础。*
+> ——Pat Casey，ServiceNow 的首席技术官兼 DevOps 执行副总裁*
+
+### **Supertab**
+
+> 借助 Google Cloud 的 A2A 协议和 Supertab Connect，智能体将能够像人类企业一样支付服务费用、收取服务费用和交换服务。*
+> ——Cosmin Ene，Supertab 创始人*
+
+### **UKG**
+
+> UKG 很高兴与 Google Cloud 合作开发新的 A2A 协议，该框架将使我们能够构建更智能、更具支持性的人力资本和劳动力体验，以前所未有的方式预测和响应员工需求。*
+> ——Eli Tsinovoi，UKG 的 AI 主管*
+
+### **Weights & Biases**
+
+> Weights & Biases 很荣幸与 Google Cloud 合作开发 A2A 协议，该协议设定了一个关键的开放标准，使组织能够放心地部署、编排和扩展各种 AI 智能体，而无需考虑底层技术。*
+> ——Shawn Lewis，Weights & Biases 首席技术官兼联合创始人*
+
+## 6 服务合作伙伴
+
+### **埃森哲**
+
+> Google Cloud 的多智能体 A2A 协议是将跨不同平台的特定领域智能体连接起来以应对复杂挑战的桥梁，从而实现无缝通信和集体智能，以实现更智能和更高效的智能体解决方案。*
+> ——Scott Alfieri，埃森哲 AGBG 全球负责人*
+
+### **德勤**
+
+> 智能体间互操作性是实现智能体 AI 架构演进的基础要素，Google Cloud 发起的 A2A 计划将技术行业参与者的生态系统凝聚到一起，共同开发和支持该协议，将极大地加速智能体 AI 的采用。*
+> ——德勤的 Gopal Srinivasan*
+
+### **EPAM**
+
+> 我们已经在 A2A 领域处于领先地位，专注于能产生实际商业价值的行业解决方案，此等价值包括节省时间、减少管理费用以及帮助客户增加收入和改进流程（如药物发现过程中 FDA 文件的编制）。*
+> ——Marc Cerro，EPAM 全球 Google Cloud 合作伙伴副总裁*
+
+### **HCLTech**
+
+> HCLTech 处于智能体企业的前沿，我们很荣幸与 Google Cloud 合作，通过开放的 A2A 标准定义智能体间互操作性并推进智能体 AI 的可能性。*
+> ——Vijay Guntur，HCLTech 首席技术官兼生态系统主管*
+
+### **毕马威**
+
+> 毕马威很高兴能参与这项新兴计划，因为 A2A 提供了不同 AI 智能体真正有效和负责任地协作所需的基本标准，借助该标准，客户和企业可以无缝地利用 AI 来实现创新和效率提升。*
+> ——Sherif AbdElGawad，毕马威的合伙人兼 Google Cloud 和 AI 负责人*
+
+**Quantiphi**
+
+> 智能体动态发现功能并打造跨平台用户体验的能力对于释放企业的真正潜力至关重要。我们认为 A2A 协议是支持企业构建此类可互操作智能体的关键一步。*
+> ——Asif Hasan，Quantiphi 联合创始人*
+
+### **塔塔咨询服务公司 (TCS)**
+
+> A2A 协议为智能体自动化新时代奠定了基础，语义互操作性在新时代占据突出地位，我们很荣幸能够引领这一变革之旅。*
+> ——Anupam Singhal，TCS 主管制造业务的总裁*
+
+### **Wipro**
+
+> 因为 AI 的未来在于无缝协作，所以像 A2A 这样的开放协议将成为 AI 智能体大规模推动创新的生态系统的基础。*
+> ——Nagendra P Bandaru，Wipro 管理合伙人兼技术服务全球主管*
+
+## 7 详细了解A2A
+
+要了解有关 A2A框架更多信息，仔细研读[**完整规范草案**](https://github.com/google/A2A)，并探索[**可用的代码示例**](https://google.github.io/A2A)，以根据其代码检查该协议的结构实验。
+
+[提交想法](https://docs.google.com/forms/d/e/1FAIpQLScS23OMSKnVFmYeqS2dP7dxY3eTyT7lmtGLUa8OJZfP4RTijQ/viewform)、[贡献文档](https://github.com/google/A2A/blob/main/CONTRIBUTING.md)以及与社区互动，为协议的演进做出贡献，一起定义智能体互操作性的未来。
\ No newline at end of file
diff --git a/docs/md/AI/llm/Build-App-with-Dify.md b/docs/md/AI/agent/Build-App-with-Dify.md
similarity index 100%
rename from docs/md/AI/llm/Build-App-with-Dify.md
rename to docs/md/AI/agent/Build-App-with-Dify.md
diff --git a/docs/md/AI/agent/augment.md b/docs/md/AI/agent/augment.md
new file mode 100644
index 0000000000..e9b0c05a73
--- /dev/null
+++ b/docs/md/AI/agent/augment.md
@@ -0,0 +1,226 @@
+# 告别文档搜索与同事打扰：Augment AI 聊天 + 200K 上下文全方位助力开发
+
+## 0 前言
+
+超强AI，助力你的编码方式。每按下一个键，即可获得极速、全面的代码库上下文。你的所有代码、文档及依赖项都会自动嵌入到每一次代码变更中，实时更新。
+
+各种环境安装支持：
+
+
+
+## 1 Agent
+
+### 1.0 你的AI结对程序员，能深入理解你的代码库
+
+
+
+ Meet Augment Agent——专为从全新应用到拥有超过10万文件的单体仓库，交付高质量代码而打造。我们的Agent会在你工作时不断学习，并自信应对各种棘手的开发场景。处理大型代码库时依然轻松。
+
+### 1.1 记忆与上下文
+
+我们的智能助手会自动引入“记忆”功能，这些记忆会随着你的工作动态更新，并在对话间持续保留，从而不断提升代码生成质量，帮助你更快完成任务，同时精准匹配你的代码风格与编写模式。
+
+Agent Memories：
+
+
+
+### 1.2 原生工具与MCP支持
+
+通过我们提供的原生工具，轻松接入GitHub、Jira、Confluence、Notion、Linear等平台；同时，全面支持Vercel、Cloudflare及其他基础设施的MCP集成。
+
+Agent Tools：
+
+
+
+### 1.3 代码检查点
+
+自动变更追踪，支持轻松回滚，助你保持编程风格。
+
+### 1.4 多模态功能
+
+共享截图、Figma 文件及任何视觉内容，便于修复 bug 或实现 UI 设计。
+
+### 1.5 终端命令
+
+运行 npm 安装、启动开发服务器、执行 Git 命令，并直接与你的终端互动。
+
+### 1.6 200K上下文容量
+
+业界领先的上下文处理能力——是同类工具的两倍。
+
+基于项目的问答（Ask）表现出色，理解准确，响应极快。在我的测试中，与Cursor对比，Augment在处理涉及整个项目代码库的复杂问题时，其上下文理解的精准度也常常更胜一筹。
+
+
+
+考虑到 Cursor 可能未使用其最强模型，Augment的上下文理解和回答质量也至少与 Cursor 不相上下，甚至在某些场景下略显优势。这足以证明 Augment 在上下文处理的底蕴。
+
+### remote agent mode
+
+
+
+点击 try it out后：
+
+### Inline Edit
+
+Augment 的行内编辑模式有一个特点：它会在一个独立的、临时的代码副本中进行操作（推测是基于原始文件在内存中生成副本）。虽然不是直接在原始文件上修改，少了一点“所见即所得”的直观感，但这并不会牺牲效率。最终的修改会清晰地以 Diff (差异对比) 的形式呈现，方便你确认和应用。
+
+## 2 Chat
+
+随时问我关于你代码的问题，立即获得解答——无需再费时查阅文档、打扰同事，或提交工单。聊天帮你快速扫清障碍！
+
+
+
+### 快速上手
+
+自信地投入任何任务。迅速了解组件的工作原理，深入排查故障，或轻松驾驭全新 API。
+
+### 保持高效流畅
+
+无需打断团队协作或翻阅文档，即可轻松掌握代码库及依赖项的详细信息。
+
+### 深度探索
+
+Chat 会主动揭示其答案背后的来源，让你一目了然地看到哪些因素影响了它的回答。
+
+### 精准聚焦
+
+灵活选择代码块、文件，甚至整个文件夹，以精确界定讨论范围。
+
+### 智能应用
+
+Augment 会根据需求自动调整代码，并将其无缝整合到正确的位置。
+
+### 第三方文档
+
+内置300多种外部文档包，助你事半功倍。
+
+## 3 Next Edit
+
+### 为你的工作提供逐段指引
+
+即使是微小的改动，也会在代码库中引发连锁反应。Next Edit 会引导你完成代码、测试和文档中相关的更新步骤。
+
+
+
+### 让复杂变更化繁为简
+
+重构、依赖升级和模式变更往往伴随着大量重复性工作。告别手动查找与替换，选择循序渐进的引导式操作。
+
+
+
+### 轻松掌控全局
+
+无需记住繁琐细节，即可快速完成多步骤变更，让流程更顺畅。
+
+
+
+### 渐进式编辑
+
+只需轻按键盘，即可直接跳转到下一处修改。
+
+### 跨文件编辑
+
+支持同时对多行代码或完全不同的文件进行修改。
+
+### 智能清理
+
+自动识别并移除未使用或已失效的代码片段。
+
+### 轻松导入
+
+随时调用任意 SDK、函数或 API，无缝衔接开发流程，绝不打断你的工作节奏。
+
+## 4 Completions
+
+### 你需要的代码，随时可用
+
+通过个性化、真正理解你的代码库、依赖关系及外部API的内联补全功能，更快写出更优质的代码。
+
+
+
+### 轻松应对各项任务
+
+补全速度飞快——你再也不用为效率发愁。无论是复杂的代码片段、测试，还是整段函数，都能瞬间搞定。
+
+
+
+### 减轻认知负担
+
+记住类、API和架构设计本就不易，而补全功能让你轻松触手可及，省去记忆之苦。
+
+
+
+### 洞悉你的代码
+
+补全功能精准反映你的代码结构、依赖关系、编程习惯及最佳实践。
+
+### 内联提示，自然高效
+
+只需用自然语言撰写注释，补全功能便会自动帮你实现。
+
+### 极速响应
+
+你思维敏捷，Augment同样如此——它总能迅速跟上你的节奏，让你无需再为编辑器的延迟而烦恼。
+
+### 智能感知聊天内容
+
+补全功能会无缝衔接你之前的聊天记录，确保工作流程始终连贯顺畅。
+
+## Slack
+
+### 保持对话顺畅
+
+你需要的一切，助你快速获得答案、让新人迅速上手，或即时做出决策。
+
+### 只需向 Augment 提问
+
+无需等待团队回复或打断他们的工作节奏，即可快速获取答案。
+
+### 优于搜索
+
+将代码库中的洞察与答案融入团队的技术讨论中。
+
+
+
+## 6 价格
+
+近乎免费的日常体验：
+
+
+
+新用户免费体验 Pro 版本一个月。试用期结束后，自动降级为免费版。免费版除了 Ask 问答功能有每月 50 次限制，其他核心功能（如 Next Edit、Inline Edit）与 Pro 版无异！
+
+
+
+每月 50 次的 Ask 对日常编码、补全和行内编辑为主的开发者基本足够。如需大量提问，如刚进新公司，读一群屎山代码，可多备几个账号。
+
+## 7 功能冲突
+
+Augment 与 Copilot 等其他 AI 代码补全/建议类插件通常不能同时启用，否则可能会产生冲突。请确保在使用 Augment 时禁用其他同类插件。
+
+```java
+欢迎使用 Augment Agent
+19:26
+
+👋 认识一下 Auggie
+我是你的 AI 编码助理，擅长理解大型、复杂的代码库，同时也乐于帮助任何规模的项目。
+
+---
+
+欢迎！我很高兴能协助你的编码项目。无论你是在编写一个小脚本，还是在浏览庞大的企业级代码库，我都可以为你提供帮助。我能帮你完成以下工作：
+
+- 理解并浏览代码
+- 编写新功能与修复 Bug
+- 重构代码并提升代码质量
+- 编写测试和文档
+- 搭建新项目
+- 以及更多其他任务
+
+今天想要一起做什么呢？随时分享你的项目，或就编码相关的任何问题向我提问！
+```
+
+
+
+## 8 总结
+
+Augment 是一款开发者AI平台，助你轻松理解代码、快速排查问题并加速交付，因为它能深入洞察您的代码库。通过聊天功能、智能补全及代码建议，让你事半功倍。
\ No newline at end of file
diff --git a/docs/md/AI/llm/boost-ai-workflow-resilience-with-error-handling.md b/docs/md/AI/agent/boost-ai-workflow-resilience-with-error-handling.md
similarity index 100%
rename from docs/md/AI/llm/boost-ai-workflow-resilience-with-error-handling.md
rename to docs/md/AI/agent/boost-ai-workflow-resilience-with-error-handling.md
diff --git a/docs/md/AI/agent/changelog-cursor.md b/docs/md/AI/agent/changelog-cursor.md
index fb566cb4e6..b41cd1ede8 100644
--- a/docs/md/AI/agent/changelog-cursor.md
+++ b/docs/md/AI/agent/changelog-cursor.md
@@ -2,6 +2,578 @@
旨在让你获得超凡的生产力， Cursor 是使用 AI 编写代码的最佳方式。
+## 1.4 - 更强大的 Agent 工具、可控性和使用情况可视化
+
+2025 年 8 月 6 日
+
+### 更强的 Agent 可控性
+
+当 Cursor 正在运行时发送消息，现可更有效地引导 Agent 行为。发送的消息将在下一个合适的时机执行，通常在调用工具之后，而非等到生成完成才执行。
+
+- ⌥+Enter（Windows 为 Alt+Enter）可像以前一样排队发消息
+- ⌘+Enter（Windows 为 Ctrl+Enter）则立即中断当前操作并发送消息
+
+可在 Cursor 设置中调整默认行为：设置 -> 聊天 -> 消息排队。
+
+
+
+### 改进的 Agent 工具
+
+处理大型代码库时，Agent 表现显著提升。上下文选择更相关，token 使用更高效，编辑质量更优：
+
+- **读取文件：** 现在在合适的情况下可以读取完整文件，并取消了 2MB 的大小限制。
+- **列出文件：** 一次调用就能浏览整个目录树，并显示文件数量、类型等元数据。
+- **代码库搜索：** 排名和索引方式更优，返回的上下文更相关
+- **网页搜索：** 使用轻量本地模型，返回更简洁、更精准的搜索结果
+
+### 不同 Agent 可选用不同模型
+
+可为不同tab或编辑器中的 Agent 指定不同的模型。如果你复制了一个 Agent，其所用模型也会一并保留。
+
+### 使用量和价格可视化
+
+可在聊天界面查看使用情况。不论是总使用量 or 当你超过套餐配额 50% 时，都可以看到清晰统计信息。
+
+这个使用情况摘要可以在设置中开启或关闭。团队和企业用户将在 9 月获得此功能的访问权限。
+
+
+
+### 紧凑聊天模式
+
+会隐藏工具图标、默认折叠差异内容（diffs），并在闲置时自动隐藏输入框。
+
+对有大量工具调用、终端操作和差异查看的长时间会话，该模式更实用。可在设置中开启或关闭该模式。
+
+开启状态：
+
+
+
+关闭状态：
+
+
+
+### GitHub 支持后台 Agent
+
+可在 GitHub 的 Pull Request 中直接使用 Agent。只需在评论中 @Cursor，Agent 就会读取提示内容、进行修复，并提交代码。
+
+后台 Agent 还会通过评论和待办事项（todo）更新你任务的执行进度。
+
+GitHub PR 中的后台 Agent：
+
+
+
+### 所有 Agent 的侧边栏管理
+
+可在左侧边栏查看和管理所有 Agent，包括前台和后台的。点击某个后台 Agent，就能查看它在远程机器上的执行状态。
+
+
+
+### 更快的后台 Agent 启动速度
+
+对后台 Agent 大量优化，启动速度提升一倍。
+
+
+
+### 企业功能
+
+- [AI 代码追踪 API](https://docs.cursor.com/en/account/teams/ai-code-tracking-api)：以提交为单位，追踪 AI 使用情况和被接受的更改
+- [屏蔽列表管理 API](https://docs.cursor.com/en/account/teams/admin-api#repo-blocklists-api)：禁止特定文件或目录被索引或用于上下文
+- [成员导出](https://cursor.com/dashboard?tab=members)：从控制台将工作区的所有成员导出为 CSV 文件
+
+## 1.3-与Agent共享终端、聊天中上下文使用情况查看、编辑更快
+
+2025年7月29日
+
+### 与Agent共享终端
+
+现在Agent可用你的本地终端。若当前没有打开终端，系统会自动创建一个新的，并在后台运行。点击“Focus”可将终端前置，可查看Agent正在执行的命令，也可随时接管操作。
+
+
+
+### 聊天中查看上下文使用情况
+
+在一次对话结束后，现可看到上下文窗口的使用情况。
+
+
+
+### 编辑速度更快
+
+通过懒加载代码检查错误，现在Agent的编辑速度更快了。搜索替换的延迟减少了25%，应用编辑的速度提升了近11%。
+
+
+
+改进：
+
+- 聊天窗口支持激活标签页
+- 右键目录后可直接发送到聊天中
+- 检查点功能可用于Notebooks
+- 提升安全性：用白名单替代黑名单进行自动运行控制
+- 聊天中移除“手动”（*Manual*）模式
+- 启用后，可通过命令面板访问新的扩展监控功能
+
+修复：
+
+- 扩展市场支持自定义 URL
+
+企业版更新：
+
+- 支持团队管理员配置扩展白名单
+
+## 1.2—Agent规划、更好上下文支持 & 更快的 Tab 补全
+
+
+
+2025年7月3日
+
+### Agent To-dos
+
+Agent可提前规划任务，使用结构化的待办清单，让需要长时间完成的任务清晰、易追踪。
+
+Agent会将大型任务拆分为多个子任务，展示其依赖关系，这些都可在对话中看到，并在需要时同步到 Slack。任务推进时，它也会实时更新待办列表，保持上下文清晰、互动流程可控。
+
+
+
+如设置 Slack 集成，也可在 Slack 中查看这些待办事项！
+
+### 消息排队
+
+可为Agent排队发送后续指令，只需输入你的指令并发送即可。当当前任务完成后，它就会继续执行排队中的指令。你也可随时调整任务顺序，无需等待。
+
+
+
+### 记忆（正式发布）
+
+自 1.0 版本以来，我们提升了记忆内容的生成质量，优化了编辑器中的界面，并加入了“用户审核”机制，以确保由后台生成的记忆信息值得信赖。
+
+
+
+### PR 索引与搜索
+
+Cursor 会像处理文件一样对 PR 进行索引与摘要。可用语义搜索查找旧的 PR，或显式地将某个 PR、Issue、提交记录或分支添加到当前上下文中。
+
+
+
+相关的 GitHub 评论、BugBot 审查信息和 Slack 中的Agent支持内容也会一并整合进来，让事故分析和问题追踪更迅速。
+
+### 更强的语义搜索嵌入
+
+更新了嵌入模型，使代码库的语义搜索更加准确。同时也重新优化了提示词，使搜索结果更清晰、更加聚焦。
+
+
+
+### 更快的 Tab 补全
+
+Tab 补全现在速度提升了约 100 毫秒，首字节时间（TTFT）缩短了 30%。这得益于我们对内存管理系统的重构和数据传输路径的优化。
+
+
+
+### 让Agent处理合并冲突
+
+遇到合并冲突时，Agent可尝试自动解决。点击 *在对话中解决*，相关上下文就会自动加载进来，协助解决冲突。
+
+
+
+### 后台Agent功能增强
+
+后台Agent变得更加稳定、可预期，具体改进包括：
+
+- 提交请求（PR）遵循你团队的模板
+- 自动拉取Agent分支的更新
+- 遇到冲突（如 rebase）会自动生成可操作的后续任务
+- 可以直接从侧边栏提交更改
+- 来自 Slack 或网页的深度链接会自动打开相关仓库，即使你本地未打开它
+
+### 改进
+
+- VS Code 升级到 1.99 版本
+- 插件现托管在 Open VSC
+- “提交更改”集成进界面
+- 后台Agent更好地遵循团队的 PR 模板，合并操作更稳定
+
+### 问题修复
+
+- 使用限制错误信息现在更加清晰，并能显示具体范围
+
+## 1.1-Slack 中的后台Agent
+
+### 启用后台Agent（Background Agents）
+
+后台Agent在云端运行，允许Agent在你的代码库中异步执行任务。
+
+启用此功能有一些重要的安全注意事项。建议查阅我们的文档了解更多详情。
+
+
+
+
+
+
+
+
+
+现可直接在 Slack 中通过 @Cursor 启动后台Agent。Agent会读取整个对话线程，理解上下文，并直接在 GitHub 上创建 PR，全程无需离开 Slack。
+
+### 在团队协作中使用 Cursor
+
+只需在 Slack 线程中提到 **@Cursor** 并输入你的指令，例如：
+
+
+
+Agent会在安全的远程环境中运行，并将进展直接通过 Slack 通知你，包括跳转链接至 Cursor 和 GitHub。
+
+### Agent理解上下文
+
+Cursor 会在开始前阅读整个 Slack 线程，这样在引用之前的讨论或问题时，后台Agent可完整理解上下文。
+
+
+
+也可让 Cursor 帮你排查问题并返回结果：
+
+
+
+### 快速开始
+
+要在 Slack 中使用后台Agent，需要管理员先完成集成设置。请查阅我们的[设置文档](https://docs.cursor.com/slack)，或让你的管理员通过 [控制台 → 集成](https://cursor.com/dashboard?tab=integrations) 页面连接 Cursor。
+
+连接成功后，在任意频道使用 **@Cursor** 并输入提示词即可。输入 `help` 查看所有命令，或用 `settings` 配置默认模型、代码库和分支。
+
+设置中支持 `Cmd/Ctrl+F` 搜索：
+
+- 服务器进度通知
+- 动态工具注册
+- Roots 支持
+
+**1.1.3**
+
+- 增加 PR 搜索和索引功能
+- 支持更换上游市场服务商
+
+
+ ## 1.0-BugBot、后台Agent全面开放、MCP 一键安装
+
+2025年6月4日
+
+本次更新带来了代码审查助手 BugBot、记忆功能初探、一键配置 MCP、Jupyter 支持，以及后台Agent的全面开放。
+
+### BugBot 自动代码审查
+
+BugBot 会自动审查你的 PR，发现潜在错误或问题。
+
+一旦发现问题，BugBot 会在 GitHub 的 PR 页面留言。点击“***在 Cursor 中修复***”，即可跳转回编辑器，自动填写修复提示。
+
+设置方式请参考 [BugBot 使用文档](https://docs.cursor.com/bugbot)。
+
+
+
+### 后台Agent全面开放
+
+所有用户都可以立即使用后台Agent！点击聊天界面的云朵图标或按下 `Cmd/Ctrl+E` 即可启动（关闭隐私模式的用户）。开启隐私模式的用户也将在不久后获得相应功能。
+
+
+
+### Jupyter Notebook 支持Agent
+
+Cursor 现在支持在 Jupyter Notebook 中直接进行编辑！
+
+Agent可以在 Jupyter 中创建和编辑多个代码单元，非常适合科研与数据科学任务。目前仅支持 Sonnet 模型。
+
+
+
+### 记忆功能（Memories）
+
+Cursor现可记住你对话中的关键信息，并在未来引用。这些记忆是基于项目的，用户可以在“设置”中进行管理。
+
+该功能目前为测试版，可前往“设置 → 规则”中开启。
+
+
+
+### MCP一键安装与 OAuth 支持
+
+现可一键安装 MCP 服务，并支持 OAuth 认证，极大简化配置流程。
+
+[docs.cursor.com/tools](https://docs.cursor.com/tools) 页面整理了可用的 MCP 服务列表。
+
+开发者还可以通过 [deeplinks 生成器](https://docs.cursor.com/deeplinks) 添加“添加至 Cursor”按钮到文档或 README 中。
+
+
+
+### 更丰富的聊天回复
+
+Cursor 聊天中现在支持可视化渲染，包括 Mermaid 图表与 Markdown 表格。
+
+
+
+### 全新设置与控制台界面
+
+设置页和控制台界面迎来视觉更新。
+
+可查看个人或团队的使用统计、修改显示名称，以及按工具或模型查看详细分析。
+
+
+
+
+
+- `Cmd/Ctrl+E` 打开后台Agent控制面板
+- `@Link` 与网页搜索支持 PDF 并纳入上下文
+- 设置中新增网络诊断功能
+- 多工具并行调用提升响应速度
+- 聊天工具调用支持折叠
+- 企业用户仅可访问稳定版本
+- 团队管理员可关闭隐私模式
+- 提供 [团队管理 API](https://docs.cursor.com/account/teams/admin-api) 获取使用与消费数据
+- Gemini 2.5 Flash 支持 Max 模式
+
+## 0.50-简化定价、后台Agent、新版 Inline Edit
+
+统一的请求计费模式，所有顶级模型均可用 Max 模式；上线后台Agent功能，支持多任务并行执行。新增 `@folders` 支持、更快的文件编辑、多根工作区支持及更强大的聊天功能如导出与复制。
+
+### 更简单的统一计费
+
+简化原本复杂的定价结构：
+
+- 所有模型均按请求计费
+- Max 模式按 token 计费（类似模型 API 计费）
+- 去除高级工具调用与长上下文模式，简化体验
+
+各版本（Hobby、Pro、Business）配额不变，慢速请求仍包含在套餐内。所有使用情况可在 [控制台](https://cursor.com/dashboard) 查看。
+
+### Max模式全面开放
+
+极致模式现已支持 Cursor 中所有最先进模型，并采用更简洁的token定价模型。该模式旨在让你在最需要时获得完全控制权。你可从模型选择器中启用该模式，查看哪些模型支持该模式。新模型推出后，我们将从第一天起就通过极致模式充分发挥其功能。
+
+当你需要更多：
+
+- 上下文信息
+
+- 智能分析
+- 工具使用时
+
+它是解决最棘手问题的理想选择。对于其他所有问题，仍建议用正常模式，并保持习惯的功能。定价很简单：根据令牌使用量收费。如果您使用过任何基于命令行的编程工具，那么 Max 模式的感觉会类似——只不过是在 Cursor 中。
+
+注意：如果您使用的是旧版 Cursor，您仍然可以在几周内使用之前的 MAX 版本和长上下文模式。但是，这些功能即将停用，因此我们建议您更新以继续使用这些功能。
+
+更多说明见 [Max 模式文档](https://docs.cursor.com/context/max-mode)
+
+
+
+### 新tab模型
+
+训练了一个新 Tab 模型，可跨多个文件提供修改建议。该模型尤其擅长重构、编辑链、多文件修改以及在相关代码之间跳转。
+
+在完成建议中添加语法突出显示：
+
+
+
+### 后台Agent预览
+
+早期预览版正在逐步推出：光标Agent现在可以在后台运行！要试用，请前往“设置”>“测试版”>“后台Agent”。Settings > Beta > Background Agent.
+
+这允许您并行运行多个Agent，并让它们处理更大的任务。这些Agent在各自的远程环境中运行。您可以随时查看状态、发送跟进或接管。
+
+[docs.cursor.com/background-agent](https://docs.cursor.com/background-agent)。
+
+
+
+### 将整个代码库加入上下文
+
+可用 `@folders` 将整个代码库添加到上下文。设置中启用“完整文件夹内容”。若某文件夹或文件太大无法完整加载，会在上下文标签上显示一个小图标提示。
+
+
+
+### 全新 Inline Edit（Cmd/Ctrl+K）集成Agent功能
+
+Inline Edit（Cmd/Ctrl+K）界面焕然一新，新增功能：
+
+- **全文件编辑**（⌘⇧⏎）：可对整个文件进行结构性修改，无需调用Agent
+- **发送至Agent**（⌘L）：当你需要对多个文件进行修改，或希望由Agent接手复杂逻辑时，可将代码块发送给Agent继续编辑
+
+### Refreshed Inline Edit (Cmd/Ctrl+K) with Agent integration
+
+Inline Edit (Cmd/Ctrl+K) has gotten a UI refresh and new options for full file edits (⌘⇧⏎) and sending to agent (⌘L)
+
+Full file makes it easy to do scope changes to a file without using agent. However, you might come across cases where you're working with a piece of code you want to make multi-file edits to or simply just want more control you can get from agent. That's when you want to send selected codeblock to agent and keep on editing from there.
+
+
+
+### 快速编辑长文件（使用Agent）
+
+Agent新增“查找并替换”工具，使其在编辑大型文件时更高效。无需读取整个文件，Agent现在可以精准定位修改位置，只编辑需要的部分。
+
+在 [Postgres 项目代码](https://github.com/postgres/postgres/blob/master/src/backend/tcop/postgres.c) 中，该工具的编辑速度几乎快一倍。
+
+该功能率先支持 Anthropic 模型。
+
+
+
+### 多代码库（codebases）工作区（workspaces）支持
+
+现可创建多根目录的工作区（multi-root workspace），让多个项目同时可用于 Cursor。
+
+所有工作区内的内容都会被索引并可调用，适合在多个项目文件夹中协作。
+
+所有添加的文件夹都支持 `.cursor/rules` 配置。
+
+多根目录工作区：
+
+
+
+#### 聊天导出
+
+可将聊天记录导出 Markdown 文件，包含文本和代码块内容，便于保存或分享。
+
+
+
+#### 聊天复制
+
+可复制一段聊天记录并开启新对话，探索不同方向的讨论，同时保留原内容。
+
+在某条消息右上角点击“三点菜单”，选择“复制聊天”即可。
+
+
+
+使用 `Cmd/Ctrl+Shift+Enter` 快速进行整个文件编辑
+
+- Inline Edit 中的全文件编辑快捷键： `Cmd/Ctrl+Shift+K`
+
+- Agent现在使用原生终端仿真（非模拟终端）
+- `@folders` 尽量加载所有可纳入上下文的文件
+- 聊天中新增图标，指示文件是否被完整加载或被压缩
+- MCP 工具现可单独禁用（在 MCP 设置中）
+- 市场新增 C# 扩展插件
+- 聊天字体大小可在设置调节
+- 应用内提供详细更新日志页面
+
+### MCP 功能增强
+
+- 远程工作区（WSL、Remote SSH）支持运行 stdio
+- 支持流式 HTTP
+
+> 注：Claude 3 Opus 不再提供每天 10 次的免费请求额度
+
+**0.50.1**
+
+- 启用后台Agent（Background Agent）功能
+
+
+
+**0.50.2**
+
+- 修复与 ZScaler VPN 的兼容问题
+
+**0.50.4**
+
+- 增强多根目录工作区支持
+
+## 0.49.x 版本更新：规则生成、Agent终端优化、MCP 图片支持等
+
+2025 年 4 月 15 日
+
+------
+
+### 1 自动生成和优化的规则
+
+现可通过命令：
+
+```bash
+/Generate Cursor Rules
+```
+
+##### 直接在对话中生成规则。
+
+时机：希望保留当前对话上下文，以便后续复用。
+
+对于设置了路径模式的 `Auto Attached`（自动附加）规则，Agent现可在读写文件时自动应用正确的规则。
+
+修复问题：`Always`（始终附加）规则现可在更长对话中持续生效。Agent现也可更稳定编辑规则。
+
+
+
+### 2 更便捷的聊天记录访问方式
+
+聊天记录现已整合到命令面板。可通过聊天界面中的 “显示历史” 按钮或使用 `Show Chat History` 命令来查看记录。
+
+
+
+### 3 更轻松的代码审查体验
+
+对话末尾会显示一个内置的差异视图，方便审查Agent生成的代码。每当Agent回复后，可点击底部 `Review changes` 按钮查看改动。
+
+
+
+### MCP 支持图片上下文
+
+你现在可以在 MCP 服务器中传入图片作为上下文内容。当你需要引用截图、UI 草图或图示来补充问题时，这会非常有帮助。
+
+
+
+### Agent终端控制能力提升
+
+对agent启动的终端有更多控制权。命令可在执行前编辑，也可选择跳过执行。
+
+将“弹出窗口（Pop-out）”重命名为“后台运行（Move to background）”，以更准确地反映其作用。
+
+
+
+### 全局忽略文件功能
+
+现可通过用户级设置，定义全局忽略文件规则（[global ignore](https://docs.cursor.com/context/ignore-files)），这些规则适用于所有项目。
+
+避免将构建输出、密钥等干扰性或敏感文件纳入prompts，无需为每个项目单独设置。
+
+
+
+### 新增模型
+
+新增模型，可试用 Gemini 2.5 Pro、Gemini 2.5 Flash、Grok 3、Grok 3 Mini、GPT-4.1、o3及o4-mini：
+
+
+
+### 项目结构上下文（Beta）
+
+新功能：将项目结构纳入上下文。
+
+好处：将你的目录结构加入prompt，使agent更好理解项目组织方式，在大型或嵌套 monorepo 项目中提供更准确的建议和导航。
+
+### 快捷键更新
+
+部分 `CMD+K` 快捷键现在可自定义修改
+
+### 界面与功能优化
+
+- Tab 跳转建议界面更新，超出视窗的建议现在也可点击
+- 聊天界面新增模式工具提示
+- 支持通过访问密钥连接 AWS Bedrock
+- Git 中的 `@PR` 功能更名为 `@Branch`
+
+### 错误修复
+
+- “始终附加”规则在总结对话中也能正确保留
+- `.mdc` 文件中的规则现在可由Agent无障碍创建和编辑
+- 修复了 `@mention` 节点在输入框起始位置时的选择问题
+
+### 面向企业和团队的新功能
+
+**全局忽略规则向上查找**
+
+现支持向上遍历目录查找忽略文件（默认关闭，可在管理员设置中开启）
+
+**支持 AWS Bedrock IAM 角色连接**
+
+企业用户现可通过 IAM 角色连接 AWS Bedrock
+
+**用户级使用情况洞察**
+
+管理员可在控制台中查看每位用户的使用和快速请求情况
+
+**团队自动运行控制**
+
+管理员可在控制台中设置全局 MCP 行为
+
+### 补丁更新
+
+**0.49.1**
+
+- 点规则不再在未超出长度限制时错误显示“超长”警告
+
## 0.48.x-聊天标签、自定义模式 & 更快的索引
引入**聊天标签**，支持并行对话，并重新设计**模式系统**，允许添加自定义模式。
diff --git a/docs/md/AI/agent/cline.md b/docs/md/AI/agent/cline.md
new file mode 100644
index 0000000000..f6c2237a75
--- /dev/null
+++ b/docs/md/AI/agent/cline.md
@@ -0,0 +1,125 @@
+# 掌控AI编程全链路：Cline让你随意选模型、透明成本、零信任安全
+
+## 0 坚定开源 AI 编程，毫不妥协！
+
+了解每一次决策。随意选择模型。掌控成本。Cline 为你提供直接、透明的前沿 AI 访问，无限制、无意外，也不存在被锁定在特定模型生态系统中的风险。
+
+## 1 Cline探索 → 规划 → 执行
+
+### 1.1 Plan Mode for复杂任务
+
+Cline 会先扫描你的代码库，并与你共同制定完整的实现计划，确保在动手写任何代码之前，就已经全面理解项目上下文。
+
+### 1.2 完全透明
+
+实时观看 Cline 打开文件、思考方案并提出修改建议。每一次决策都可见，每一次编辑都可以在提交前审阅。
+
+### 1.3 你的模型，你的控制权
+
+需要复杂推理时使用 Claude，处理大规模上下文时选用 Gemini，追求效率时选择 Kimi K2。新模型一旦发布即可即时切换，API 密钥由你自行管理。
+
+## 2 瞥见 Cline 不断扩展的工具箱
+
+为实际工程而生！
+
+### 2.1 .clinerules
+
+定义项目专属指令，让 Cline 遵循编码规范、架构模式或团队约定，从而生成一致且合规的代码。
+
+### 2.2 MCP Integration
+
+通过MCP连接数据库、API 与文档。Cline 成为你通往所有外部系统的桥梁。
+
+### 2.3 Context Intelligence
+
+进度条会实时显示 Cline 正在使用多少上下文资源。没有隐藏的 Token 限制，也不会出现意外截断，所有资源消耗一目了然。
+
+### 2.4 终端掌控
+
+Cline 可以直接在你的终端执行命令、读取输出并调试错误。它就像一个永远记得语法的搭档，与你进行配对编程。
+
+## 3 唯一通过合规审查的 AI 编程智能体
+
+- [SOC 2 Compliant(Q2 2025)](https://trust.cline.bot/)
+- [GDPR Ready(Q2 2025)](https://trust.cline.bot/)
+
+### 3.1 零信任设计
+
+你的代码永远不触及我们的服务器。Cline 完全在客户端运行，使用你自己的 API 密钥，是满足严格安全要求的唯一选择。
+
+### 3.2 全面审计
+
+开源意味着你的安全团队可以审查每一行代码。精准了解 Cline 的工作方式、向 AI 提供商发送了哪些信息以及决策是如何产生的。
+
+### 3.3 为团队而建
+
+无论是初创企业还是《财富》500 强，Cline Teams 都提供集中计费、使用分析与席位管理，同时保持企业所需的安全架构。
+
+## 4 为啥开发者选择 Cline
+
+我们相信 AI 编程应该放大人的能力，而不是掩盖它。所有设计决策都体现了这一承诺。
+
+### 4.1 100% 开源
+
+代码全部托管在 GitHub 上，已有 48k ⭐（且仍在增长），来自阅读、改进并信任这些代码的开发者们。
+
+### 4.2 不玩推理游戏
+
+### 4.3 设计即面向未来
+
+有新模型发布？立刻使用。Cline 支持任何 AI 提供商和任何模型，让你永远不会被旧技术锁定。
+
+### 4.4 完全可视化
+
+不仅是「可解释 AI」(Explainable AI)，而是彻底透明。每一次文件读取、每一个决策、每一枚 Token 的使用，都清晰可见。
+
+## 5 我们的设计原则
+
+**北极星（North Star）**：始终打造最优秀的编码智能体，让你的最佳结果即是我们的最佳结果。
+
+### 5.1 开源万物
+
+我们不能隐藏降级、偷工减料或隐匿决策。每一行代码都可以审计。透明不是一个功能，而是架构层面的必然。
+
+### 5.2 不靠推理获利
+
+我们的成功取决于 Cline 功能更强大，而非设法削减你的成本。推理权在你手，唯一的盈利途径是交付被企业客户广泛采用的优质软件。
+
+### 5.3 通用模型访问
+
+今天最好的模型可能来自 Anthropic；明天的模型或许出自尚未成立的实验室。Cline 能即时使用任何模型，不设创新门槛。
+
+### 5.4 只使用你的基础设施
+
+客户端架构意味着你的代码永远不触及我们的服务器。这对安全至关重要，也是众多企业的必备要求，确保真正的数据主权。
+
+**结果**：每一个激励、每一行代码、每一次架构决策都指向同一个目标——让最大能力掌握在你手中。我们只能以此方式成功。
+
+## 6 FAQ
+
+### Cline费用多少？
+
+Cline本身免费且开源。你只需为所使用的 AI 模型付费，按照你选定提供商的实际价格结算，没有加价、没有订阅，也不会有意外费用。
+
+### 代码在用 Cline 时安全吗？
+
+是的。Cline 完全运行在本机上，并直接使用你的 API 密钥。你的代码永远不经过我们的服务器。这种客户端架构正是注重安全的企业选择 Cline 的原因。
+
+### Cline 与 GitHub Copilot 或 Cursor 相比如何？
+
+与自动补全工具不同，Cline 是一个真正的编码智能体，能够理解完整的代码库、规划复杂修改并执行多步骤任务。与订阅服务不同，你可完全控制使用哪种 AI 模型以及花费多少。
+
+### 哪些 AI 模型最适合配合 Cline 使用？
+
+Cline 对模型没有限制。可选:
+
+- Claude 3.5 Sonnet（Claude 3.5 Sonnet）进行复杂推理
+- Gemini 2.5 Pro（Gemini 2.5 Pro）处理超大上下文窗口
+- DeepSeek（DeepSeek）追求成本效率
+- 或在新模型发布后立即使用
+
+很多用户会组合不同模型：高价模型用于规划，低价模型用于执行。
+
+### 可在企业内部使用 Cline 吗？
+
+可以。Cline 的架构（客户端、自带密钥 BYOK、开源）非常适合企业使用。我们提供 Cline Teams，以实现集中计费和管理。已有众多《财富》500 强公司采用 Cline，因为它是唯一满足其合规要求的 AI 编码工具。
\ No newline at end of file
diff --git a/docs/md/AI/llm/configuring-models-in-dify.md b/docs/md/AI/agent/configuring-models-in-dify.md
similarity index 100%
rename from docs/md/AI/llm/configuring-models-in-dify.md
rename to docs/md/AI/agent/configuring-models-in-dify.md
diff --git a/docs/md/AI/llm/dify-agent-and-zapier-mcp-unlock-ai-automation.md b/docs/md/AI/agent/dify-agent-and-zapier-mcp-unlock-ai-automation.md
similarity index 100%
rename from docs/md/AI/llm/dify-agent-and-zapier-mcp-unlock-ai-automation.md
rename to docs/md/AI/agent/dify-agent-and-zapier-mcp-unlock-ai-automation.md
diff --git a/docs/md/AI/llm/dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights.md b/docs/md/AI/agent/dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights.md
similarity index 100%
rename from docs/md/AI/llm/dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights.md
rename to docs/md/AI/agent/dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights.md
diff --git a/docs/md/AI/llm/dify-v1-0-building-a-vibrant-plugin-ecosystem.md b/docs/md/AI/agent/dify-v1-0-building-a-vibrant-plugin-ecosystem.md
similarity index 100%
rename from docs/md/AI/llm/dify-v1-0-building-a-vibrant-plugin-ecosystem.md
rename to docs/md/AI/agent/dify-v1-0-building-a-vibrant-plugin-ecosystem.md
diff --git a/docs/md/AI/agent/dify-v1-1-0-filtering-knowledge-retrieval-with-customized-metadata.md b/docs/md/AI/agent/dify-v1-1-0-filtering-knowledge-retrieval-with-customized-metadata.md
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/docs/md/AI/agent/kiro.md b/docs/md/AI/agent/kiro.md
new file mode 100644
index 0000000000..302e57d98d
--- /dev/null
+++ b/docs/md/AI/agent/kiro.md
@@ -0,0 +1,544 @@
+# 告别Vibe编程：Kiro让你的代码一次成型！
+
+## 0 前言
+
+Kiro，一个专为 vibe coding 应用带来结构的 IDE，默认内置规范驱动开发。
+
+Amazon 刚发布 [Kiro IDE](https://kiro.dev/)。这是他们自己的开发平台，专为 vibe coding 应用带来结构而设计，默认内置规范驱动开发。
+
+这个想法是为了让 vibe coding 应用更易进入生产环境——这是大多数 vibe coding 平台目前仍难解决的问题。
+
+但真正让我对这个新 IDE 感兴趣的是：Kiro 由 Claude 4 Sonnet 驱动。
+
+Anthropic 的 Claude 4 Sonnet 和 Opus 基本上是当前 AI 模型的佼佼者。将它们内置到 Kiro 中对于 vibe coder 来说非常有趣。它本质上会自动将软件工程最佳实践应用到 vibe-coding 工作流程中，帮助为应用开发带来结构和更有组织的方法。
+
+看看有啥特殊功能。
+
+## 1 啥是 Kiro？
+
+一个 AI 驱动的 IDE，专为"vibe coding"而设计，但远不止于此。优势在于通过规范和钩子等功能将这些原型转化为生产系统。
+
+Kiro 规范和钩子：
+
+
+
+- **Kiro 规范**，助你更好规划和理解你的应用。对于思考功能、重构和澄清系统行为很有用。还指导 AI 代理做出更智能的实现决策。
+- **Kiro 钩子**，就像有个高级开发在背后看着你。它们在后台自动化任务，如处理样板代码或在你保存、创建或删除文件时捕获问题或手动触发它们。
+
+Kiro将单个提示转化为完整功能的规范、技术设计和任务分解来简化开发。如输入"添加评论系统"会生成具有边缘情况覆盖的用户故事，然后自动构建包括数据流、API 和数据库模式的设计文档。
+
+
+
+它还会创建一个考虑单元测试、响应性和可访问性的序列化任务列表。
+
+Design documentation in Kiro specs：
+
+
+
+构建时，钩子就像一个同行开发者——自动化诸如测试文件更新、刷新文档、扫描问题和执行代码标准等事情。一旦设置，钩子会在文件事件（如保存或提交）时运行，帮助团队以最少的努力维护质量和一致性。
+
+Kiro 还支持 MCP 和自主代理，所以它在 vibe coding 场景中并不感觉像新手。感觉比 Cursor 或 Windsurf 更先进，因为 Amazon 在这个 IDE 中打包了所有功能。
+
+## 2 安装Kiro
+
+前往 [kiro.dev](https://kiro.dev/downloads/) 并根据硬件和操作系统下载安装文件：
+
+
+
+下载完成后，在你的系统上安装应用程序并启动它。这是初始仪表板的样子。
+
+
+
+有多种方式可以登录 Kiro，但建议用 AWS 账户。由于 Kiro 可能最终会更深地集成到 AWS 工具中，提前链接你的账户可能会让以后的事情更易。
+
+Kiro 建立在 VS Code 之上，可立即导入现有的配置：
+
+
+
+建议在终端中设置 Kiro。这会将 Kiro 添加到你的系统 PATH 中，允许你从终端全局打开它，而不必每次都从应用程序文件夹中查找。
+
+
+
+用户界面仍然感觉很像 VS Code，只是有一些视觉调整来匹配 Amazon 的颜色主题。
+
+
+
+Kiro IDE界面功能：
+
+
+
+### 编辑器
+
+代码编写和编辑的核心工作区。功能包括：
+
+- 多种语言的语法高亮
+- 行号和错误指示器
+- 代码折叠以便更好地组织
+- 多个标签页用于跨文件工作
+- 分屏视图支持并排编辑
+
+### 聊天面板
+
+你可以使用聊天面板来：
+
+- 询问有关代码的问题
+- 请求代码生成或修改
+- 获得调试和故障排除帮助
+- 请求代码审查和优化建议
+- 使用 # 命令包含上下文（例如，#File、#Folder）
+- 生成样板代码和模板
+
+要将聊天面板移动到IDE的另一侧：
+
+在顶部菜单栏中，选择 视图 > 外观 > 将主侧边栏移到右侧。
+
+### 视图
+
+侧边栏包含几个专门的视图：
+
+- **资源管理器** - 导航项目文件结构，查看Git状态指示器，并访问规范和MCP服务器的特殊部分。
+
+- **搜索** - 在整个项目中执行全局搜索和替换操作。
+
+- **源代码管理** - 管理Git操作，查看更改并处理提交。
+
+- **运行和调试** - 在调试会话期间查看变量、调用堆栈和管理断点。
+
+- **扩展** - 安装和管理IDE扩展。
+
+- **Kiro** - AI特定功能的专用视图：
+ - 规范概览和管理
+ - 代理钩子管理
+ - 代理指导配置
+ - MCP服务器
+
+### 状态栏
+
+位于界面底部，状态栏提供：
+
+- 当前文件信息
+- Git分支和同步状态
+- 错误和警告计数
+- 代理状态指示器
+
+### 命令面板
+
+通过按 Cmd+Shift+P（Mac）或 Ctrl+Shift+P（Windows/Linux）快速访问Kiro的命令来：
+
+- 执行常见操作
+- 访问MCP工具
+- 配置设置
+- 运行代理钩子
+
+### 导航技巧
+
+- 使用键盘快捷键进行更快的导航
+- 利用命令面板快速访问功能
+- 固定常用文件以便轻松访问
+- 使用分屏视图比较或引用代码
+- 配置工作区设置以获得个性化体验
+
+## 3 Kiro 如何工作
+
+规范驱动开发保持 vibe coding 的速度和创造力，但添加了通常缺失的结构。
+
+纯 vibe coding 的最大问题之一是它需要太多的来回交流，特别是在处理复杂功能或大型代码库时。AI 易失去上下文或误解你提示背后的意图。Kiro 通过在编写任何代码之前从规范开始来解决这个问题。
+
+打开一个项目并点击 Kiro 标签。在右侧面板上，你会看到一个聊天界面，可在"Vibe"或"Spec"之间选择。选择 Spec，然后开始描述你希望 AI 处理的任务。
+
+在我的情况下，我有一个想要升级的角色创建页面。当前的设置只是使用纯文本字段进行物理描述。我想用开关和下拉菜单替换它，为用户提供更视觉化和结构化的输入方法。
+
+
+
+发送给 Kiro 的完整提示：
+
+```vbnet
+In the #character-form-modal.tsx can you help me improve the way the user sets the physical description of the character?
+Instead of simple text description, I want to show toggles and dropdowns. Here are the selectable menus:
+- Race: Asian (default), White, Black, Hispanic
+- Gender: Boy, Girl (default)
+- Age: (must be a number between 1–100, default at 8)
+- Body: Slim, average (default), chubby
+- Hair length: Short, normal (default), long
+- Hair color: Black (default), blonde, red, brown, gold, white
+- Shirt color: red, blue, yellow, pink, black, white (default)
+- Short color: red (default), blue, yellow, pink, black, white
+- Shoes color: red, blue (default), yellow, pink, black, white
+- Others: a text field for other physical attributes
+Organize the components in the modal screen with a nice and modern look and feel.
+When the user clicks on the "Create Character" or "Update Character" button, combine all the physical attributes into a single string and save it to the database.
+```
+
+Kiro 做的第一件事是为功能增强创建规范表。它被保存在仪表板的规范部分下，格式为 markdown。
+
+
+
+以下是规范表的内容：
+
+```vbnet
+## Introduction
+
+This feature enhances the character creation and editing form by replacing the free-text physical description field with structured, selectable attributes. Users will be able to define their character's appearance through organized dropdowns, toggles, and input fields, providing a more guided and consistent character creation experience.
+
+## Requirements
+
+### Requirement 1
+
+**User Story:** As a user creating or editing a character, I want to select physical attributes from predefined options, so that I can quickly and consistently define my character's appearance.
+
+#### Acceptance Criteria
+
+1. WHEN the character form modal opens THEN the system SHALL display structured physical attribute controls instead of a single text area
+2. WHEN a user selects physical attributes THEN the system SHALL provide the following options:
+ - Race dropdown with options: Asian (default), White, Black, Hispanic
+ - Gender selection with options: Boy, Girl (default)
+ - Age input field accepting numbers between 1-100 (default: 8)
+ - Body type dropdown with options: Slim, Average (default), Chubby
+ - Hair length dropdown with options: Short, Normal (default), Long
+ - Hair color dropdown with options: Black (default), Blonde, Red, Brown, Gold, White
+ - Shirt color dropdown with options: Red, Blue, Yellow, Pink, Black, White (default)
+ - Shorts color dropdown with options: Red (default), Blue, Yellow, Pink, Black, White
+ - Shoes color dropdown with options: Red, Blue (default), Yellow, Pink, Black, White
+ - Others text field for additional physical attributes
+3. WHEN the user submits the form THEN the system SHALL combine all selected physical attributes into a single descriptive string
+4. WHEN the form is submitted THEN the system SHALL save the combined physical description to the database in the existing physicalDescription field
+
+### Requirement 2
+
+**User Story:** As a user editing an existing character, I want the form to pre-populate with the character's current physical attributes, so that I can modify specific aspects without losing existing information.
+
+#### Acceptance Criteria
+
+1. WHEN editing an existing character THEN the system SHALL attempt to parse the existing physicalDescription field
+2. IF the existing description cannot be parsed into structured attributes THEN the system SHALL display default values and preserve the original text in the "Others" field
+3. WHEN the form loads with an existing character THEN the system SHALL pre-select the appropriate dropdown values based on the character's current physical description
+
+### Requirement 3
+
+**User Story:** As a user interacting with the character form, I want the physical attributes section to have a modern and organized layout, so that the form is easy to navigate and visually appealing.
+
+#### Acceptance Criteria
+
+1. WHEN the physical attributes section is displayed THEN the system SHALL organize controls in a logical grid layout
+2. WHEN displaying the physical attributes THEN the system SHALL group related attributes together (e.g., hair attributes, clothing attributes)
+3. WHEN the form is rendered THEN the system SHALL maintain the existing modal styling and dark theme
+4. WHEN the user interacts with the controls THEN the system SHALL provide clear visual feedback and maintain accessibility standards
+
+### Requirement 4
+
+**User Story:** As a user, I want age validation to prevent invalid entries, so that character creation remains consistent and error-free.
+
+#### Acceptance Criteria
+
+1. WHEN a user enters an age value THEN the system SHALL validate that the value is between 1 and 100
+2. IF an invalid age is entered THEN the system SHALL display an error message and prevent form submission
+3. WHEN the age field loses focus with an invalid value THEN the system SHALL reset to the default value of 8
+```
+
+我对计划的详细程度印象深刻。它将任务分解为四个明确的需求，每个都有用户故事和详细的验收标准。它包含了我要求的一切——从 UI 应该如何看起来到年龄验证应该如何行为。它甚至添加了解析和保留旧数据的逻辑。
+
+审查后，我点击了"进入设计阶段"。以下是最终设计文档的样子：
+
+~~~markdown
+# Design Document
+## Overview
+This design transforms the character form modal's physical description from a free-text textarea into a structured interface with organized dropdowns, inputs, and controls. The enhancement maintains the existing dark theme and modern styling while providing users with guided character creation through predefined attribute options.
+## Architecture
+### Component Structure
+The enhanced character form modal will maintain its existing structure but replace the physical description textarea with a new `PhysicalAttributesSection` component that contains:
+- **Attribute Controls**: Individual form controls for each physical attribute
+- **State Management**: Local state for each attribute with default values
+- **String Generation**: Logic to combine attributes into a descriptive string
+- **Parsing Logic**: Ability to parse existing descriptions back into structured data
+### Data Flow
+1. **Form Load**: Parse existing `physicalDescription` string into individual attributes
+2. **User Interaction**: Update individual attribute states as user makes selections
+3. **Form Submission**: Combine all attributes into a single descriptive string
+4. **Database Storage**: Save combined string to existing `physicalDescription` field
+## Components and Interfaces
+### Physical Attributes Interface
+```typescript
+interface PhysicalAttributes {
+ race: 'Asian' | 'White' | 'Black' | 'Hispanic';
+ gender: 'Boy' | 'Girl';
+ age: number;
+ body: 'Slim' | 'Average' | 'Chubby';
+ hairLength: 'Short' | 'Normal' | 'Long';
+ hairColor: 'Black' | 'Blonde' | 'Red' | 'Brown' | 'Gold' | 'White';
+ shirtColor: 'Red' | 'Blue' | 'Yellow' | 'Pink' | 'Black' | 'White';
+ shortsColor: 'Red' | 'Blue' | 'Yellow' | 'Pink' | 'Black' | 'White';
+ shoesColor: 'Red' | 'Blue' | 'Yellow' | 'Pink' | 'Black' | 'White';
+ others: string;
+}
+```
+### Default Values
+```typescript
+const DEFAULT_ATTRIBUTES: PhysicalAttributes = {
+ race: 'Asian',
+ gender: 'Girl',
+ age: 8,
+ body: 'Average',
+ hairLength: 'Normal',
+ hairColor: 'Black',
+ shirtColor: 'White',
+ shortsColor: 'Red',
+ shoesColor: 'Blue',
+ others: ''
+};
+```
+### Layout Design
+#### Grid Organization
+The physical attributes section will use a responsive grid layout:
+```
+┌─────────────────────────────────────────────────────────┐
+│ Physical Appearance │
+├─────────────────────────────────────────────────────────┤
+│ [Race ▼] [Gender ▼] [Age: 8 ] │
+│ │
+│ [Body ▼] [Hair Length ▼] [Hair Color ▼] │
+│ │
+│ [Shirt Color ▼] [Shorts Color ▼] [Shoes Color ▼] │
+│ │
+│ ┌─────────────────────────────────────────────────────┐ │
+│ │ Others: Additional attributes... │ │
+│ │ │ │
+│ └─────────────────────────────────────────────────────┘ │
+└─────────────────────────────────────────────────────────┘
+```
+#### Visual Grouping
+- **Basic Info**: Race, Gender, Age (top row)
+- **Physical Build**: Body type, Hair attributes (middle row)
+- **Clothing**: Shirt, Shorts, Shoes colors (bottom row)
+- **Additional**: Others text field (separate section)
+### Styling Specifications
+#### Section Header
+- Title: "Physical Appearance" with icon
+- Consistent with existing form section styling
+- Subtle border/separator from other sections
+#### Form Controls
+- **Dropdowns**: Use existing Select component with dark theme
+- **Age Input**: Number input with validation styling
+- **Others Field**: Textarea matching existing form styling
+- **Grid**: 3-column responsive layout on larger screens, stacked on mobile
+#### Color Coding
+- Maintain existing color scheme (blue-purple gradients)
+- Use subtle background variations for different attribute groups
+- Error states for invalid age input
+## Data Models
+## Error Handling
+### Age Validation
+- **Range Check**: Validate 1-100 range on input
+- **Type Check**: Ensure numeric input only
+- **Reset Logic**: Auto-reset to default (8) on invalid input
+- **Visual Feedback**: Red border and error message for invalid values
+### Form Submission
+- **Required Fields**: Maintain existing validation for name and description
+- **Attribute Validation**: Ensure all dropdowns have valid selections
+- **Fallback Handling**: If attribute parsing fails, preserve original description
+### Backward Compatibility
+- **Existing Characters**: Parse what's possible, preserve rest in "Others"
+- **Migration Strategy**: No database changes required
+- **Graceful Degradation**: System works with both structured and unstructured descriptions
+## Testing Strategy
+### Unit Tests
+- **String Generation**: Test all attribute combinations produce valid descriptions
+- **Parsing Logic**: Test parsing of various description formats
+- **Validation**: Test age input validation edge cases
+- **Default Values**: Verify correct defaults are applied
+### Integration Tests
+- **Form Submission**: Test complete form flow with new attributes
+- **Character Editing**: Test loading and updating existing characters
+- **API Integration**: Verify data flows correctly to backend
+### Visual Tests
+- **Layout Responsiveness**: Test grid layout on different screen sizes
+- **Theme Consistency**: Verify dark theme styling matches existing components
+- **Accessibility**: Test keyboard navigation and screen reader compatibility
+### User Experience Tests
+- **Form Flow**: Test complete character creation process
+- **Error Handling**: Test validation feedback and error recovery
+- **Performance**: Ensure form remains responsive with new controls
+~~~
+
+
+
+再次花时间审查设计文档，看看 AI 在哪些部分不正确。进行最终更改，然后点击"进入实施计划"按钮。
+
+Kiro 现在将创建实施计划。在我们的示例中，AI 将在源代码中执行12组更改。
+
+```markdown
+# Implementation Plan
+
+- [ ] 1. Create physical attributes interface and utility functions
+ - Define TypeScript interface for PhysicalAttributes with all required properties
+ - Create default values constant with specified defaults
+ - Implement string generation function to combine attributes into description
+ - Write basic parsing function to extract attributes from existing descriptions
+ - _Requirements: 1.2, 4.1_
+
+- [ ] 2. Create PhysicalAttributesSection component
+ - Build new React component to house all physical attribute controls
+ - Implement responsive grid layout with proper spacing and grouping
+ - Add section header with icon and styling consistent with existing form
+ - Create proper TypeScript props interface for the component
+ - _Requirements: 1.2, 3.1, 3.2, 3.3_
+
+- [ ] 3. Implement individual attribute controls
+ - Create race dropdown with Select component (Asian, White, Black, Hispanic)
+ - Create gender dropdown with Select component (Boy, Girl)
+ - Create body type dropdown with Select component (Slim, Average, Chubby)
+ - Create hair length dropdown with Select component (Short, Normal, Long)
+ - Create hair color dropdown with Select component (Black, Blonde, Red, Brown, Gold, White)
+ - _Requirements: 1.2, 3.4_
+
+- [ ] 4. Implement clothing attribute controls
+ - Create shirt color dropdown with Select component (Red, Blue, Yellow, Pink, Black, White)
+ - Create shorts color dropdown with Select component (Red, Blue, Yellow, Pink, Black, White)
+ - Create shoes color dropdown with Select component (Red, Blue, Yellow, Pink, Black, White)
+ - Apply consistent styling and spacing to all clothing dropdowns
+ - _Requirements: 1.2, 3.4_
+
+- [ ] 5. Implement age input with validation
+ - Create number input field for age with proper styling
+ - Add input validation to enforce 1-100 range
+ - Implement error display for invalid age values
+ - Add auto-reset to default value (8) when invalid input is detected
+ - Create proper error styling consistent with existing form theme
+ - _Requirements: 1.2, 4.1, 4.2, 4.3_
+
+- [ ] 6. Create others text field
+ - Implement textarea for additional physical attributes
+ - Apply consistent styling with existing form textareas
+ - Add proper placeholder text and labeling
+ - _Requirements: 1.2, 3.4_
+
+- [ ] 7. Integrate PhysicalAttributesSection into character form modal
+ - Replace existing physical description textarea with new PhysicalAttributesSection
+ - Add state management for all physical attributes in main component
+ - Implement proper state initialization with default values
+ - Wire up all attribute change handlers
+ - _Requirements: 1.1, 2.1, 3.3_
+
+- [ ] 8. Implement attribute parsing for existing characters
+ - Add logic to parse existing physicalDescription into structured attributes
+ - Handle cases where parsing fails by preserving original text in others field
+ - Ensure proper fallback to default values when attributes cannot be determined
+ - Test parsing with various description formats
+ - _Requirements: 2.1, 2.2_
+
+- [ ] 9. Implement string generation on form submission
+ - Modify form submission handler to generate description string from attributes
+ - Combine all selected attributes into coherent descriptive text
+ - Ensure generated string maintains proper grammar and readability
+ - Preserve any additional text from others field in final description
+ - _Requirements: 1.3, 1.4_
+
+- [ ] 10. Add responsive styling and theme consistency
+ - Implement responsive grid layout that works on mobile and desktop
+ - Apply dark theme styling consistent with existing modal
+ - Add proper spacing, borders, and visual grouping
+ - Ensure all controls match existing form component styling
+ - Test layout on different screen sizes
+ - _Requirements: 3.1, 3.2, 3.3, 3.4_
+
+- [ ] 11. Write unit tests for utility functions
+ - Create tests for string generation function with various attribute combinations
+ - Write tests for parsing function with different description formats
+ - Add tests for age validation logic
+ - Test default value application and edge cases
+ - _Requirements: 1.2, 1.3, 4.1_
+
+- [ ] 12. Test complete form integration
+ - Test character creation flow with new physical attributes section
+ - Test character editing flow with existing characters
+ - Verify form submission works correctly with generated description strings
+ - Test error handling and validation feedback
+ - Ensure backward compatibility with existing character data
+ - _Requirements: 1.1, 1.4, 2.1, 2.2, 4.2_
+```
+
+
+
+一旦你对计划满意，点击"最终确定任务列表"按钮来最终确定规范表。
+
+对于下一步，我们现在可以通过打开 `tasks.md` 文件并点击任何任务项目旁边的"开始任务"来开始实施每个任务。
+
+
+
+完成后，任务项目将被标记为已完成。你可以通过点击"查看更改"按钮来检查代码差异。所有执行日志也将显示在聊天面板上。
+
+
+
+继续执行其余任务。一旦所有任务项目都标记为已完成，检查 Web 应用程序以查看更改是否按预期工作。
+
+
+
+UI 与我提示中描述的所有内容匹配，当我点击生成角色按钮时，数据会存储在数据库中。
+
+计划的一部分是测试阶段。Kiro 运行了示例输入，解析它们，并检查准确性。
+
+
+
+```yaml
+Test 5: Complex description
+Description: "A chubby 15-year-old African American girl with flowing red hair, wearing yellow sneakers and a black top"
+Parsed attributes: {
+ age: 15,
+ race: 'Black',
+ gender: 'Girl',
+ body: 'Chubby',
+ hairColor: 'Red',
+ shirtColor: 'Black',
+ shoesColor: 'Yellow'
+}
+Parsing successful: true
+❌ Expected hairLength: Long, got: undefined
+---
+
+Test 6: Unparseable description
+Description: "A mysterious character with unique features and special abilities"
+Parsed attributes: {}
+Parsing successful: undefined
+✅ Expected no parsing (unparseable description)
+---
+```
+
+每次在测试中遇到错误时，Kiro 都会执行修复。
+
+## 4 Kiro 由 Claude 驱动
+
+Kiro 由 Anthropic 的 Claude 模型驱动，目前在测试版中免费。
+
+这是现在尝试它的最好原因之一。Claude 4 Sonnet 很昂贵，大多数平台要么限制其使用，要么将其隐藏在更高级别后面。例如，Cursor 悄悄地引入了使用限制，这使得每月20美元的计划对许多开发者来说无法使用。
+
+其他 vibe coding 工具如 Windsurf 或 Cline 也不提供对 Claude 模型的免费访问。你要么自带密钥，要么付费使用。
+
+在 Kiro 中，你可以在 Claude Sonnet 4.0 或 3.7 之间选择。只需前往设置 > 工作区并选择你想要的模型。
+
+
+
+目前，Kiro 仍处于预览阶段，所以你可以免费尝试它，具有慷慨的使用限制。在[定价页面](https://kiro.dev/pricing/)上查看更多详细信息。
+
+
+
+最新版价格：
+
+
+
+- 免费层让你访问所有核心功能，包括规范、代理钩子、MCP 支持和代理指导——但每月限制在50次 AI 交互。
+- 一旦付费计划推出，将有两个选项：每月19美元的 Kiro Pro，每月交互限制为1,000次，以及每月39美元的 Kiro Pro+，将这一数字提高到3,000次交互。
+
+所有层级都包含相同的核心功能。唯一的区别是你获得多少 AI 使用量。
+
+## 5 最终想法
+
+我印象深刻的是，Kiro 从我的提示中做出的所有代码更改在前端和后端都一次性工作。无需后续提示。
+
+就开发体验而言，在进行实际代码更改之前创建规范会减慢你的速度。
+
+如果你打算进行小修复或小代码更新，你不需要使用规范功能。直接要求 AI 进行代码更改。Claude 4 模型足够聪明，可以弄清楚哪个文件和哪行代码需要更新。
+
+但是如果你正在处理大型功能实施或主要代码重构，这种"编码前计划"方法绝对有用。作为一个已经 vibe coding 一年多的人，有时 AI 会误解请求并最终浪费我宝贵的积分。
+
+我注意到的另一件事是响应速度的不一致。有时 AI 似乎陷入无限循环，因为它没有响应。不过我们需要理解，这是一个初始版本，很多人同时使用它。
+
+无论如何，Kiro 是一个真正好的平台，为 vibe coding 体验提供了新的视角。我很好奇其他开发者对规范和钩子功能的看法。对我来说，这是避免与 AI 误解的好方法，同时也有更清洁和更有组织的代码库。
\ No newline at end of file
diff --git a/docs/md/AI/agent/perplexity-labs.md b/docs/md/AI/agent/perplexity-labs.md
new file mode 100644
index 0000000000..efa5243373
--- /dev/null
+++ b/docs/md/AI/agent/perplexity-labs.md
@@ -0,0 +1,37 @@
+# 不止于搜索！Perplexity Labs深度解析：以项目为核心的 AI 工作流！
+
+## 0 前言
+
+Perplexity推出全新功能 [Labs](https://www.perplexity.ai/pl/hub/blog/introducing-perplexity-labs)，专为 Pro 订阅用户设计，旨在支持更复杂的任务，功能超越了传统的问答服务。这一重大更新标志着 Perplexity 从以搜索为核心的交互模式，转向由生成式 AI 驱动的结构化、多步骤工作流。
+
+## 1 交互模式
+
+Perplexity Labs 让用户可在一个统一界面完成多种任务，包括生成报告、分析数据、编写和执行代码、构建轻量级网页应用等。用户可以通网页和移动端的新模式切换器进入 Labs，桌面端支持也即将上线。
+
+## 2 适用场景
+
+与专注于简洁回答的 Perplexity Search 和提供深入信息整合的 Research（原名 Deep Research）不同，Labs 更适合需要完整成果输出的用户。这些成果可能包括格式化的电子表格、可视化图表、交互式仪表盘和基础网页工具等。
+
+每个 Lab 项目都包含一个“Assets”标签页，用户可在此查看或下载所有生成的素材，如图表、图片、CSV 文件和代码文件。有些 Labs 还支持“App”标签页，可以直接在项目环境中渲染基本网页应用。
+
+## 3 使用反馈
+
+Perplexity 的 CEO 和联合创始人 Aravind Srinivas 表示：
+
+> 推出 Perplexity Labs，是我们在 Perplexity 上进行搜索的一种全新方式，支持更复杂的任务，如构建交易策略、仪表盘、用于房地产研究的无头浏览任务、迷你网页应用、故事板，以及生成素材的目录等。
+
+实际使用看，Labs 实现了多个软件工具功能的整合与自动化，大大减少了手动操作，尤其适用于结构化研究、数据处理或原型开发等场景。
+
+用户反馈也显示出平台在速度和语境理解方面的优势。Sundararajan Anandan 就曾[分享](https://www.linkedin.com/feed/update/urn:li:ugcPost:7333908730314399752?commentUrn=urn%3Ali%3Acomment%3A(ugcPost%3A7333908730314399752%2C7334912579871326209)&dashCommentUrn=urn%3Ali%3Afsd_comment%3A(7334912579871326209%2Curn%3Ali%3AugcPost%3A7333908730314399752))：
+
+> 我最近尝试了 Perplexity Labs，它真的改变了游戏规则。以前需要花几个小时才能完成的手动研究和格式整理，现在在 10 分钟内就能输出清晰、可执行的见解。虽然目前还处于早期阶段，平台也有待进一步完善，但初次体验已经相当令人惊艳。
+
+不过，一些早期用户也指出了可改进的地方，特别是在初次生成后进行跟进操作或修改代码方面功能有限。正如一位 Reddit 用户[评论](https://www.reddit.com/r/perplexity_ai/comments/1kza7vo/comment/mv6koy5/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)所说：
+
+> Labs 最大的问题在于它对后续操作的支持不够，基本要求用户一击命中，非常考验技巧。
+
+## 4 总结
+
+Perplexity 还宣布将统一产品术语，将“Deep Research”简化为“Research”，以便更清晰地区分三种模式：Search、Research 和 Labs。
+
+目前，Perplexity Labs 已正式上线，向所有 Pro 用户开放。平台还提供了 [Projects Gallery](https://www.perplexity.ai/labs)，展示了各种示例和使用案例，帮助用户快速上手完成实际任务。
\ No newline at end of file
diff --git a/docs/md/AI/agent/qoder.md b/docs/md/AI/agent/qoder.md
new file mode 100644
index 0000000000..efa90ba9d7
--- /dev/null
+++ b/docs/md/AI/agent/qoder.md
@@ -0,0 +1,201 @@
+# Qoder，让你从“执行者”到“架构师”！
+
+## 1 AI 编程的发展趋势
+
+随LLM进步，AI辅助编程正快速演变。应用范围已从最初简单代码提示，扩展到端到端功能实现，AI自主性也越来越高。
+
+AI编程能力正经历三个关键阶段：
+
+1. 辅助写代码：基础的自动补全与代码片段生成
+2. 对话式重构：通过对话实现交互式修改与重构
+3. 自主编程：将完整的开发任务交给 AI Agen
+
+这种演变使 AI 的角色从工具转为合作伙伴，能承担复杂且长期的软件工程任务。
+
+
+
+## 2 现实软件开发的挑战
+
+虽社交媒体常见“一条指令生成惊艳项目”案例，但现实软件开发依旧复杂。Fred Brooks 在《人月神话》指出，软件开发本质困难，原因在于：
+
+- 复杂性
+- 一致性要求
+- 可变性
+- 不可见性
+
+这些挑战在 AI 时代不仅没消失，反而在某些方面放大：
+
+- 软件抽象性让知识传递和继承变得困难，易产生技术债和协作摩擦
+- AI虽能自动化重复性工作，但若开发者忽视设计与需求澄清，就会导致 AI 生成的代码难维护
+- 目前人机协作大多是同步的，需不断来回沟通，限制 AI 效率，也让它无法充分发挥
+
+## 3 思路
+
+阿里一直在探索如何打造一款工具，让 AI 充分发挥潜力，同时解决软件开发中的核心难题。
+
+### 3.1 透明化
+
+#### ① 知识可见性
+
+首要目标是 **让不可见的东西变得可见**。AI 应该像一位熟悉代码库的专家，助开发者理解项目架构、设计决策和技术债。
+
+这种可见性能：
+
+- 缩短上手时间
+- 提升知识传递效率
+- 让 AI 生成的代码更好地 **贴合** 项目的整体结构
+
+
+
+#### ② 执行透明度
+
+如果 AI 在后台默默运行，开发者容易感到失去掌控感。为此设计了：
+
+- To-dos待办清单：明确的任务拆分
+- Action Flow行动流程：实时的执行跟踪
+
+开发者可随时看到 AI 的计划、进度和决策，让过程透明且值得信赖。
+
+
+
+在 AI 编程中，可见性不是可选项，而是高效协作的必要条件。
+
+### 3.2 增强的上下文工程
+
+**更好的上下文带来更好的代码**。核心在于增强型上下文工程，包括：
+
+- 深度理解代码库：AI 不只“读代码”，而是理解其结构、依赖和设计理念
+- 记忆能力：保存项目历史、用户操作和人机交互，支持长期上下文保持
+
+通过丰富输入上下文，Qoder 不仅生成更精准代码建议，还能为架构决策提供洞察，实现从“代码补全”到“智能协作开发”的跃升。
+
+
+
+增强型上下文工程不仅是一项技术特性，更是一种新的开发理念。
+
+### 3.3 基于 Spec 的任务委托
+
+AI Agent时代开发者核心角色 **从“执行者”转变为“意图澄清者”**。
+
+#### ① 聊天模式（Chat Mode）：与Agent协作
+
+- 通过对话引导 AI
+- 审阅、修改并确认每一次改动
+- 适合短小、迭代型任务
+
+#### ② 任务模式（Quest Mode）：自主委托
+
+- 你先写一份详细的规格说明（Spec）
+- 你再将任务交给 AI
+- AI 异步执行，仅遇到障碍才请求帮助
+- 适合长期、定义清晰的任务
+
+
+
+Spec不只是任务说明，它还是一种思考工具和沟通媒介：帮助统一人机目标，指引项目方向，并成为团队知识库的一部分。
+
+任务模式正是为这种新范式而生：写 Spec → 委托任务 → 检查结果。
+
+
+
+#### ③ 协作方式
+
+| **Chat Agent Mode** | **Quest Mode** |
+| ------------------- | ------------------- |
+| 聊天迭代 | 先写 Spec |
+| 通过对话完成编码 | 委托任务给 AI Agent |
+| 适合短任务 | 适合长任务 |
+| 监督工作过程 | 精确描述目标 |
+
+未来的开发流程或许是这样的：
+
+1. 上午：和业务方澄清需求
+2. 下午：用 AI 辅助起草详细的 Spec
+3. 晚上：通过任务模式委托工作
+4. 第二天：审查结果，优化并继续迭代
+
+写 Spec → 检查 & 重构 —— 软件开发的新工作流。
+
+### 3.4 提供最合适的模型
+
+随着可用模型越来越多，我们提出一个问题：“选择正确的模型应该由用户来做吗？” **不应该**。
+
+开发者需要的是解决方案，而不是去研究模型对比。他们无需去看评测指标来挑选模型。
+
+Qoder 会根据任务复杂度和上下文，自动匹配最合适的模型，确保性能最优，同时减少用户负担。
+
+**你专注于想要实现什么，我们负责怎么实现。**
+
+## 4 用 Qoder 完成工作
+
+### 4.0 安装
+
+欢迎页：
+
+
+
+导入cursor的配置页：
+
+
+
+语言和主题：
+
+
+
+面板介绍：
+
+
+
+登录你伟大的账号吧！gmail 即可，无需join waitlist！
+
+
+
+实际页面：
+
+
+
+### 4.1 开始一个新项目
+
+Qoder上手零门槛，你只需要用自然语言描述想法。如：
+
+- “创建一个 Spring Boot 应用，实现照片上传、预览和下载功能。”
+
+Qoder 会自动生成项目框架和核心业务逻辑。
+
+或者，你也可先用任务模式生成 Spec，描述技术栈、架构和初始版本。一个好的初始版本就是能直接运行的项目。
+
+### 4.2 在现有项目中增加功能
+
+大部分开发都是在已有代码库上进行。在写代码前，开发者需要先了解：
+
+- 项目的功能
+- 技术架构
+
+Repo Wiki 可以即时提供这些信息。Qoder 会在后台建立代码库索引并导入记忆，当你开始一个任务时，相关上下文已经准备好，无需手动选择。
+
+这样，从第一行代码起就能获得精准、上下文相关的辅助。
+
+
+
+## 5 熟悉的代码编辑 + AI 协助
+
+日常开发中，Qoder 提供支持：
+
+- 代码补全
+- 下一步编辑建议（NES）：预测多行的后续修改
+- 内联编辑：直接在对话中修改代码
+
+这些功能能无缝融入现有工作习惯，提升效率而不打断开发节奏。
+
+
+
+## 6 最后的思考
+
+我们的愿景是解决软件开发中的核心难题：
+
+- 让不可见的部分可视化
+- 加强人机之间的知识对齐
+- 消除技术债务和协作摩擦
+- 让开发者摆脱重复劳动，专注于创新
+
+Qoder 现已开放公测，完全免费。
\ No newline at end of file
diff --git a/docs/md/AI/agent/roocode.md b/docs/md/AI/agent/roocode.md
new file mode 100644
index 0000000000..1f6495ff99
--- /dev/null
+++ b/docs/md/AI/agent/roocode.md
@@ -0,0 +1,53 @@
+# RooCode实用指南：从coser到人工中继的全能AI代码助手
+
+## 0 前言
+
+原名 RooChat，Codelime/Cline 的一个分支，也是VS Code插件，重点是Agent，可深度对话、分析需求、规划任务，甚至扮演不同技术角色。https://roocode.com/
+
+
+
+## 1 内置cosplay
+
+可让 AI 扮演不同角色，如“架构师”、“测试工程师”等。特别是“架构师”角色，能站在更高维度与你一同分c's析项目结构、梳理需求、设计方案，甚至绘制 Mermaid 流程图或架构图。类似Cursor "Thinking" 模式，但角色专业性和交互深度，RooCode 更丰富。
+
+
+
+## 2 灵活的模型配置
+
+需用户自行配置 AI 模型。对于追求性价比的用户，可通过配置 OpenRouter、LM Studio 等模型供应商，选择其中的免费或者本地大模型，如 OpenAI 的 openai/gpt-oss-120b，实现零成本使用：
+
+
+
+若追求顶尖代码能力，如公认的Claude4，也可考虑接入一些国内的第三方模型 API 平台。这些平台通常价格比官方 API 更实惠，但需自行承担服务不稳定、甚至跑路风险，小额尝试，切勿一次性投入过多。
+
+## 3 Manual Relay
+
+人工中继。
+
+### 使用场景
+
+处理非常庞大的上下文（如整个代码库或超长文档）时，直接调用 API 的 Token 消耗昂贵。启用“人工中继”模式后，RooCode 不直接调用配置好的模型 API，而是将生成的 Prompt (提示词) 或问题展示给你。你要手动将这些内容复制到你拥有高级会员权限的 AI 网页端（如 ChatGPT Plus）进行提问，获得答案后，再将答案粘贴回 RooCode。RooCode 会基于你粘贴回来的内容继续执行下一步的 Agent 任务。
+
+### 优势
+
+极大节省 API Token 费用，尤其适合处理超大上下文；可以充分利用你已有的网页端 AI 会员资格。
+
+### 缺点
+
+需要手动复制粘贴，较为繁琐。
+
+
+
+ 需将问题粘贴到Web端AI：
+
+
+
+## 4 社区活跃
+
+RooCode开发者非常活跃，表明开发者在积极听取社区反馈并持续完善插件，更有希望带来更多实用的新功能。
+
+
+
+## 5 总结
+
+RooCode扮演着智能 Agent 的角色，擅长需求分析、任务规划、架构设计，并能通过灵活的模型配置和“人工中继”模式控制成本。
\ No newline at end of file
diff --git a/docs/md/AI/agent/solo.md b/docs/md/AI/agent/solo.md
new file mode 100644
index 0000000000..62aec2827a
--- /dev/null
+++ b/docs/md/AI/agent/solo.md
@@ -0,0 +1,117 @@
+# SOLO is All You Need
+
+能构建完整软件的 AI。
+
+你可能正开着好几个标签页：
+
+- 一个用 ChatGPT 写 PRD（产品需求文档）
+- 一个 AI 研究工具
+- 一个 AI 编码工具执行任务
+- 可能还有一个工具做代码审查和测试……
+
+本该是流畅的开发流程，却变成了在管理一群互不相识的 AI 助手，还得不断重复同样的信息。
+
+AI agent很强，各自解决问题没问题，但整体依旧割裂，离真正的成品发布还有距离。
+
+于是我们换了思路：如何打造一个真正推动软件开发的解决方案？
+
+这就是 **TRAE SOLO** 的由来——不仅会写代码，还能思考、规划、构建并完整交付功能的“上下文工程师”，全程掌握关键信息和工具。
+
+## 1 TRAE SOLO 新特性
+
+### 1.1 SOLO 模式
+
+从需求到部署，全流程自动处理开发工作。你可以在集成视图中实时查看编辑器、浏览器、终端和文档，SOLO 会自动写代码、修 Bug、发布功能，无需人工干预。
+
+### 1.2 @SOLO Builder
+
+内置 Web 开发工具，可将想法直接变成可上线的完整网站。从 PRD、UI 设计、代码生成到部署，一气呵成，适合专业开发者与爱好者。
+
+### 1.3 SOLO 模式与 IDE 模式一键切换
+
+可完全交给 AI 接管，也可以在聊天面板中协作开发。左上角一个开关即可切换。
+
+### 1.4 统一价格
+
+SOLO 已包含在 Pro 计划中，无需额外订阅。
+
+## 2 核心：上下文工程（Context Engineering）
+
+高效的 AI 开发不只是从写代码或写提示词开始。随任务复杂度增加，**完整、精准、结构化的上下文** 比所谓的“神奇提示”更重要。
+
+SOLO 天生为上下文工程而设计——先理解你的知识体系，帮你思考规划，再将复杂任务拆分成可执行的逻辑步骤。
+
+如你说：“做个邮箱验证的用户登录页”，SOLO 会生成 PRD 规格文档，分析项目架构，用合适的工具执行，并总结完成情况。
+
+## 3 你能用 SOLO 做啥？
+
+### 3.1 面向开发者
+
+频繁切换上下文破坏专注。你可能花更多时间在文档、调试 API、搭建流水线上，而非写功能。
+
+学习新框架也耗时，如数据基础设施工程师不可能一夜之间写全栈应用。
+
+SOLO 让每位开发者效率提升 10 倍。
+
+比如你是后端工程师，要在用户重置密码时发邮件通知：
+ “当用户重置密码时发邮件，用现有队列系统，包含 IP 和设备信息。”
+ SOLO 会定位代码位置，复用模块，写代码、加测试、提交干净的 PR——全在你的上下文里完成，无需额外配置或重复说明。
+
+### 3.2 面向小团队
+
+传统团队按前端、后端、运维分工，但在节奏快的团队，这种结构易变成瓶颈。
+
+有了 SOLO，后端工程师要做实时数据看板，不必学 React，也不必等前端同事：“做个响应式看板，从现有 API 拉用户数据。”
+
+SOLO 会设计 UI、写组件、处理状态管理、接 API、部署应用，全部遵循团队规范。
+
+### 3.3 面向产品经理
+
+从想法到上线通常需要协调工程师、设计师、分析师，还要写一堆 PRD、开无数会议，等上线时测试窗口可能早就错过了。
+
+SOLO 让 PM 变成产品构建者，可以在几天内验证想法并产出 MVP。
+
+比如要在用户资料页加 Instagram、LinkedIn 链接，只需：
+
+“给用户资料页加可编辑的社交链接图标：Instagram、LinkedIn、Twitter。”
+
+SOLO 会更新 UI、接入数据模型，几分钟就能出可点击的成品原型。
+
+### 3.4 面向设计师
+
+设计与开发之间的落差，常让好创意消失在交接中。SOLO 让设计师不写代码也能直接构建交互原型。
+
+用 @SOLO Builder 描述需求或上传参考图，SOLO 自动处理布局、响应式和设计规范。
+
+#### 想改组件？
+
+用 Select & Edit 点选页面元素，直接改文本、间距、布局、颜色，SOLO 会实时更新代码。
+
+## 4 FAQ
+
+**Q：TRAE SOLO 的请求怎么算？**
+ A：每个提示算一次请求，无额外费用。
+
+**Q：SOLO 用的是什么模型？**
+ A：当前使用 Claude-4-Sonnet。
+
+**Q：SOLO Code 是什么？怎么获得？**
+ A：Pro 用户可用 SOLO Code 激活 SOLO 模式，关注 Trae 的 Twitter、Discord、Reddit 和合作活动可获取。
+
+**Q：SOLO 能在现有代码库里用吗？**
+ A：可以，SOLO 能直接理解你的架构并遵循项目规范。
+
+**Q：需要写很详细的指令吗？**
+ A：随你，可以自然语言描述，也可以在项目中协作。
+
+**Q：我想亲自写代码可以吗？**
+ A：可以，随时中断 SOLO 模式切回 IDE 模式。
+
+**Q：SOLO 只做 Web 应用吗？**
+ A：不，只要是全栈应用、后端服务、API 集成、看板、内部工具等都支持。
+
+------
+
+TRAE SOLO 是一个集成的上下文工程师，能跨工具、在上下文中思考，与用户一起从头到尾交付真实功能。无论你是开发者、PM 还是设计师，都能用 SOLO 更快推进项目而不牺牲质量。
+
+试用地址：https://www.trae.ai/solo
\ No newline at end of file
diff --git a/docs/md/AI/agent/trae-update.md b/docs/md/AI/agent/trae-update.md
new file mode 100644
index 0000000000..5cc147dcda
--- /dev/null
+++ b/docs/md/AI/agent/trae-update.md
@@ -0,0 +1,86 @@
+# Trae功能更新
+
+## v2.0.5
+
+July 30, 2025
+
+## Auto mode
+
+True会智能地为您的任务选择最佳模型——在复杂性、速度和可用性之间取得平衡，为您提供最流畅的体验。自动模式默认开启。可随时从底部菜单进行更改。
+
+https://docs.trae.ai/ide/auto-mode
+
+May 16, 2025
+
+## v1.4.8
+
+- Enhanced plugin management to support enabling/disabling plugins by workspace
+- Upgraded the VSCode kernel version to 1.100.3
+
+## v1.3.9
+
+Show release notes after an update
+
+- Optimized some features.
+
+## v1.3.1
+
+2025 年 04 月 22 日
+
+ 版本正式发布。提升稳定性。
+
+## v1.3.0
+
+2025 年 04 月 21 日
+
+### Unified AlPanel-Call Builder with @
+
+
+
+We've merged the Chat and Builder panels. Now, you can talk to Al about everything in one place.
+
+Try typing @Builder - it's the same familiar formula.
+
+合并 Chat 与 Builder 面板。你可以通过 @Builder 方式将 Builder 作为智能体使用。
+
+### More Diverse Contexts
+
+We've expanded #Context. Use #Web for real-time search, or build docs with #Doc to give Alprecise references for smarter conversations.
+
+支持将文档内容和网页内容作为上下文：
+
+- \#Web：支持联网搜索，AI 会自动提取网页内的相关内容作为上下文。
+- \#Doc：支持通过 URL 或上传 .md/.txt 文件的方式添加文档集。
+
+### Define Rules to Shape Al Responses
+
+Set Rules.md at the user or project level to refine Trae's behavior and response style - applyglobally or per project to ensure consistent results..
+
+支持通过配置规则来规范 AI 的行为，包括：
+
+- 个人规则：根据个人偏好创建适用于所有项目的规则。
+- 项目规则： 创建仅适用于当前项目的规则。
+
+### Support for Custom Agent Creation
+
+You can now create your own Agent! Customize prompts, connect MCP or tools to boost skils andteamwork, and build a dedicated Al expert for specific tasks.
+
+升级智能体（Agent）能力：
+
+- 支持创建自定义智能体。你可以自定义智能体的提示词和工具集。
+- 提供两个内置智能体：Builder 和 Builder with MCP。
+- 支持为智能体开启 “自动运行” 模式，使智能体自动执行命令和调用工具，同时支持配置命令黑名单。
+
+支持模型上下文协议（MCP）：
+
+- 提供内置 MCP 市场，支持快速添加第三方 MCP Servers。
+- 支持将 MCP Server 添加到智能体进行使用，从而丰富智能体的能力。
+
+## v1.0.9
+
+March 3, 2025
+
+- Integrated DeepSeek R1 as built-in models.
+- Completed kernel upgrade to version 1.97.
+- Trae is now based on VS Code 1.97.2.
+- Added intelligent plugin recommendations based on file.
\ No newline at end of file
diff --git a/docs/md/AI/agent/trae.md b/docs/md/AI/agent/trae.md
new file mode 100644
index 0000000000..dfcac5b344
--- /dev/null
+++ b/docs/md/AI/agent/trae.md
@@ -0,0 +1,50 @@
+# 字节抢 Cursor 饭碗，Claude-3.5-Sonnet、GPT-4o 限时免费用
+
+## 0 前言
+
+字节在海外发布 AI Coding 产品 Trae，一款全新的智能协作 AI IDE ，限时免费，Claude-3.5-Sonnet、GPT-4o 免费用。
+
+内置 Builder 和 Chat 两种模式：
+
+- Builder 模式：轻松完成从零到一的项目构建，就是只要会说话，就能写代码那种
+- Chat 模式：可以随时对代码库或编程相关问题提问或寻求建议。
+
+跟 Cursor 几乎一样强大。无论是专业开发者还是新手开发者，都能体验到Trae 带来的效率提升。
+
+官网：trae.ai
+
+上线时间：2025.01.20
+
+## 1 上手
+
+### 开始
+
+
+
+### 选择主题
+
+
+
+### cursor 配置一键导入
+
+
+
+### 添加命令行
+
+
+
+### 登录
+
+
+
+海外发布，自然谷歌邮箱登录：
+
+
+
+### 首页
+
+
+
+IDEA：
+
+
\ No newline at end of file
diff --git a/docs/md/AI/llm/what-is-llmops.md b/docs/md/AI/agent/what-is-llmops.md
similarity index 100%
rename from docs/md/AI/llm/what-is-llmops.md
rename to docs/md/AI/agent/what-is-llmops.md
diff --git a/docs/md/AI/agent/windsurf-update.md b/docs/md/AI/agent/windsurf-update.md
new file mode 100644
index 0000000000..2ff335fbe9
--- /dev/null
+++ b/docs/md/AI/agent/windsurf-update.md
@@ -0,0 +1,745 @@
+# Windsurf功能更新
+
+## v 1.10.3 Windsurf Browser
+
+June 12, 2025
+
+- 可将浏览器上下文共享给 Windsurf
+- 支持共享代码块、选中文本、网页元素、截图和控制台日志
+- 可将这些内容直接发送到 Cascade
+
+## v 1.10.1 计划模式
+
+2025年6月10日
+
+
+
+### 计划模式
+
+- 可以在“计划模式”下向 Cascade 发消息，该模式允许 Cascade 在执行编辑操作前先进行规划
+- Cascade 会创建一个名为 `plan.md` 的文件，列出其准备执行的操作
+- 用户可编辑这个计划文件，Cascade 会识别用户的修改内容
+
+### 终端优化
+
+- Cascade 面板中新增原生终端
+- 现可直接在 Cascade 面板的终端中输入指令
+
+### 移除旧版模式
+
+- 移除旧版模式，现仅保留“Write模式”和“Chat模式”
+
+### 其他改进
+
+- 在 @提及 中加入图标
+- 代码块根据主题自动适配样式，界面焕新
+- 改进 `.codeiumignore` 文件支持
+- 新增菜单，可快速打开和切换之前的对话
+
+## v 1.9.4 修复
+
+2025年6月3日
+
+- 合并了来自 VS Code 1.99.3 的最新更新
+
+## v 1.9.2 支持自带 Anthropic 密钥
+
+2025年5月22日
+
+#### 自带密钥（BYOK）
+
+- 现在你可以在 Cascade 中使用自己的 Anthropic API 密钥，支持 Claude 4 Sonnet、Claude 4 Sonnet（思考版）、Claude 4 Opus 和 Claude 4 Opus（思考版）模型
+- 使用方法：前往 [提供 API 密钥](https://windsurf.com/subscription/provider-api-keys) 页面并输入你的密钥
+- 输入后返回 Windsurf 并重新加载页面，即可使用这些新模型
+
+## v 1.9.1 SWE-1 改进
+
+2025年5月21日
+
+### 多模态支持
+
+- 为 SWE-1 增加了多模态支持，现已支持图像输入
+
+## v 1.9.0 新一代 SWE-1 模型系列
+
+2025年5月15日
+
+### SWE-1
+
+- Windsurf 推出了全新的 SWE-1 模型
+- SWE-1 具备前沿级别的模型能力
+- 专业用户限时免费使用
+
+### SWE-1-lite
+
+- 替代原有 Cascade Base 的新版本，性能大幅提升
+- 所有用户免费用
+
+### SWE-1-mini
+
+- SWE-1-mini 是为 Windsurf 中的标签补全功能特别优化的轻量模型
+
+## v 1.8.2 Cascade Customization
+
+May 6, 2025
+
+### 界面改进
+
+- 重设计型选择器
+- 增加了继续按钮以处理单个工具调用限制
+- 优化会话关联的工作区打开方式
+- 代码块接受/拒绝组件新增紧凑模式，减少占用空间。
+
+### Cascade UX Improvements
+
+- Improvements to commit message generation quality
+- Commit message generation reads from global rules as context
+- Ability to edit proposed terminal command
+
+### 自定义工作流
+
+- 用户可创建并保存“工作流”
+- 通过斜杠命令调用
+- Cascade支持创建和编辑这些工作流
+- 文件保存于工作区的.windsurf/workflows目录下
+
+### 基于文件的规则
+
+- 允许创建细粒度的规则文件，可全局生效、被@提及、由Cascade请求，或附加到文件 glob 模式中
+- 规则文件保存于.windsurf/rules目录
+
+### 多任务处理
+
+- Cascade支持在切换对话时持续运行
+- 并新增了通过下拉菜单或键盘快捷键切换对话的功能
+
+### Cascade插件
+
+- Cascade新增MCP服务器管理面板
+- 简化了一键安装和卸载流程
+- 优化搜索体验
+- MCP现支持资源管理和多模型响应
+- 未来将推出更多MCP服务选项
+
+## v 1.8.0 团队功能
+
+May 6, 2025
+
+### 代码审查
+
+- 团队管理员可安装GitHub应用进行代码审查及PR标题/描述编辑
+- 每月提供500次审查，适用于团队和企业SAAS用户
+
+### 对话分享
+
+- 团队成员可生成共享链接，仅团队内其他成员可访问
+- 适用于团队和企业SaaS方案
+
+### 知识管理
+
+- 团队管理员可连接Google账户并整理相关文档
+- 团队成员可以@提及这些文档以便Cascade检索
+- 适用于团队和企业SAAS用户
+
+### 部署功能
+
+- 团队用户可通过Windsurf设置连接Netlify账户
+- 直接将应用部署至Netlify团队
+- 支持SSO、自定义域等通过Netlify控制台的团队专用设置
+
+### 分析仪表盘
+
+- 更新了团队分析仪表盘
+- 增加Cascade相关数据，如消息数量、工具调用次数、模型使用情况等
+
+### 系统升级
+
+升级至VS Code 1.99.1版本。
+
+## v 1.7.2 全新应用图标与免费套餐升级
+
+2025年4月28日
+
+### 全新应用图标
+
+- Windsurf 现已启用全新设计的应用图标
+- Windsurf.com 网站也同步更新了新版文字标志
+- （Mac 系统）可自定义应用图标也采用新标识
+
+### 免费套餐升级
+
+- 免费用户的使用额度提升
+- 现可在写作模式用 Cascade
+- Cascade 提示额度从每月 5 条提升至 25 条
+- Fast Tab 功能无限制使用
+- Cascade Base 功能无限制使用
+- 可访问预览功能
+- 支持 1 个部署操作
+
+### 性能优化
+
+- 部署应用时的性能和稳定性提升
+- 即使已有部署配置文件（yaml），仍可创建新的部署
+- 部署 Web 应用工具中新增“检查部署状态”的调用功能
+- 对远程扩展（WSL、SSH、Dev Containers）进行了稳定性改进
+- 在大型差异区域中打字时的性能表现更好
+
+### 其他更新
+
+- Command 中新增对 GPT-4.1 的支持
+- 升级至 VSCode 基础版本 1.98
+
+## v 1.7.1
+
+2025年4月24日
+
+- 更新了 IDE 应用商店链接，现同步至 Open VSX 镜像平台
+
+## v 1.7.0
+
+April 21, 2025
+
+### 更新后的简化定价方案
+
+#### 我们将取消 Flow 操作点数（Flow Action Credits）
+
+- 为了让定价模式更简单，我们将取消 Flow 操作点数
+- 此变更将于 2025 年 4 月 21 日起生效
+- 各订阅方案现在将包含「提示点数」，也可以额外购买点数包
+
+#### 用户提示点数（User Prompt Credits）
+
+- 所有订阅方案将提供提示点数，发送每条消息时会消耗点数，而不是每次工具调用时消耗
+- 可额外购买点数包
+- 用户可在个人资料中开启自动充值功能（可设置上限）
+
+#### 现有订阅方案
+
+- 所有现有订阅方案将自动迁移至新的定价模式
+- 更多详情请访问 [定价页面](https://windsurf.com/pricing)
+
+## v 1.6.5
+
+2025年4月16日
+
+### 全新 o4-mini 模型上线，限时免费使用
+
+- Windsurf 现已支持 o4-mini medium 和 o4-mini high 两个模型，所有用户均可免费使用
+- 使用时间限于 4 月 16 日至 4 月 21 日
+
+## v 1.6.4
+
+2025年4月14日
+
+### 全新 GPT 4.1 模型上线，限时免费使用
+
+- Windsurf 现已支持全新的 GPT 4.1 模型，所有用户均可免费使用
+- 使用时间限于 4 月 14 日至 4 月 21 日
+
+2025年4月9日
+
+### Cascade 现已支持JetBrains
+
+- 查看完整的 [JetBrains 更新日志](https://windsurf.com/changelog/jetbrains)
+- 阅读 [官方公告](https://windsurf.com/blog/windsurf-wave-7)
+
+### **Codeium 正式更名为 Windsurf**
+
+- 公司名称更改为Windsurf，插件产品也将更名为 **Windsurf Plugin**。
+
+- 自从推出 [Windsurf 编辑器](https://windsurf.com/editor) 以来，我们明确了真正的
+
+- 目标：融合人类创造力与机器智能，打造强大却毫不费力的体验。
+
+## v 1.6.3
+
+2025年4月7日
+
+- 修复了 Windows 系统上提交生成解析的问题
+- 修复了规则页面的部分 UI 问题
+- 允许部署网站时包含空文件
+- 提升部署错误的可见性
+- 网站部署时支持编辑子域名
+- 提高 MCP SSE 连接的稳定性
+
+## v 1.6.2
+
+2025年4月3日
+
+- 修复了 "Remote - WSL" 扩展相关的问题
+- 一些用户体验方面的小修复
+
+## v 1.6.1
+
+### **2025年4月2日**
+
+### **部署功能（测试版）**
+
+- 使用一句提示将应用部署至 Netlify，使用 windsurf.build 域名
+- 认领你的应用 URL 后，可持续部署更新至相同项目
+- 想部署新站点或更换子域名？只需让 Cascade 部署到新子域即可
+- 所有用户都可使用，付费计划有更多权限
+
+### **提交信息生成（测试版）**
+
+- 在源码控制面板中一键生成提交信息
+- 付费用户可用，且不额外消耗积分
+
+### **Cascade 记忆功能增强**
+
+- 新增记忆标签页
+- 支持编辑记忆标题、内容和标签
+- 支持搜索 Cascade 生成的记忆
+- 设置中可启用/关闭自动生成记忆的开关
+- 开启后自动记录重要上下文；关闭后只会根据请求创建记忆
+
+### **长对话改进**
+
+- 引入用户消息目录，滚动时显示，支持快速定位历史内容
+
+### **Windsurf Tab 改进**
+
+- 支持 Jupyter Notebook
+- 新增上下文信号，包括 IDE 内部搜索内容
+
+### **新图标（Mac）**
+
+付费用户可选两款新应用图标：Retro 和 Pixel Surf
+
+### **其他更新**
+
+- 新增 Cascade 工具栏，整合 MCP、预览、部署等工具
+- Cascade 支持 JSON 配置中的 SSE MCP 服务器
+- “打开新窗口时关闭 Cascade” 的设置现已生效
+- 输入框内容在新建会话和活跃会话中保留
+- 终端界面焕新，“打开终端”按钮更加醒目
+- 链接支持点击跳转
+- 可开启“运行结束播放提示音”（测试中）
+- 修复 Remote - SSH 扩展问题，支持自定义 SSH 路径
+- 合并 VS Code 1.97.0 相关更新
+
+## **v 1.5.9**
+
+### **2025年3月25日**
+
+### **新模型：Gemini 2.5 Pro（测试版）**
+
+- Gemini 2.5 Pro 正式进入测试阶段！
+- 每条消息消耗 1 个用户提示积分，每次工具调用消耗 1 个流程操作积分
+- 所有计划（包括免费）均可使用
+- *当前需求量大，团队正在扩容中*
+
+### **修复内容**
+
+- 修复了 Remote - SSH 扩展及自定义 SSH 路径设置问题
+
+## **v 1.5.8**
+
+### **2025年3月24日**
+
+### **修复内容**
+
+- Cascade 更好地遵循用户定义的记忆
+- 浏览器预览改进
+- 修复 Cascade 图标相关布局问题
+
+## **v 1.5.6**
+
+### **2025年3月18日**
+
+### **全新 Windsurf Tab 体验**
+
+- 将 Autocomplete、Supercomplete、Tab to Jump、Tab to Import 整合为一体化体验
+- 使用更大更高质量模型，提升上下文理解、速度与质量
+
+### **上下文优化**
+
+- 补全功能可利用浏览文件、终端命令、Cascade 会话等信号
+- 剪贴板上下文（默认关闭，可在高级设置中启用）
+- 上下文长度扩展，提升补全效果
+
+### **质量提升**
+
+- 自动选择插入补全 vs 编辑补全更加精准
+- Tab to Jump 跳转范围翻倍
+- 提高缩进与排版质量
+
+### **性能提升**
+
+- 预测触发补全，连贯完成多轮建议
+- 增强服务器能力与推理速度
+- 网络优化，延迟更低
+
+### **Tab 使用体验升级**
+
+- 接受的补全高亮为绿色（可关闭）
+
+- Tab to Jump 与 Tab to Import 小部件视觉更清晰、可点击
+
+### **其他改进**
+
+- 自动修复 Lint 模式中信用扣除更准确
+- 终端命令现可作为上下文
+- Debug Console 中 Tab 键支持补全
+- Cascade 差异审查体验优化
+- 修复信用不足提示、补全速度设置等问题
+- 快捷设置下拉菜单改进
+- 提升 CPU 和内存使用效率
+- 新增 Neon 数据库作为 MCP 模板
+
+## **v 1.4.6**
+
+2025年3月10日
+
+### **修复内容**
+
+- 修复 Sonnet 3.7 网页搜索问题
+- 修复代理设置问题
+
+## v 1.4.4 修复
+
+2025年3月6日
+
+- 重新添加设置项至设置面板（代理设置、索引大小）
+
+## v 1.4.3
+
+### **2025年3月5日**
+
+### **Windsurf 预览、自动 Linter、新 MCP 服务**
+
+#### **Windsurf 预览（测试版）**
+
+- Cascade 支持在 IDE 或浏览器中预览本地网站
+- 可选中 React 或 HTML 元素作为上下文提供给 Cascade
+- 错误信息也可传递作为上下文
+- 可通过“启动 Web 应用”或工具栏图标激活预览
+- 支持在 Chrome、Arc、Chromium 浏览器中展示
+- 可在设置中关闭
+
+#### **Cascade 自动 Linter**
+
+- Cascade 现在自动修复自己生成代码中的 lint 错误
+- 每步中 lint 修复不计入积分消耗
+- 示例：若某次修改包含4个 lint 错误，将自动尝试修复，无额外消耗
+- 可在设置中关闭
+
+#### **新 MCP 服务支持**
+
+- 可将 Cascade 配置为调用可信 MCP 工具服务器
+- Windsurf 设置页提供常用 MCP 服务器列表
+- 新用户界面便于添加和配置 MCP
+- 设置页中仍支持用户自定义 JSON
+- 专业与终极专业计划可用，团队与企业计划即将支持
+
+#### **Tab-to-Import**
+
+- 自动补全缺失依赖导入
+- 使用 Tab 接受建议即可完成导入
+
+#### **建议操作**
+
+- Cascade 提供任务相关建议操作，点击即可继续操作流程
+
+#### **拖放文件作为上下文**
+
+- 支持从文件资源管理器拖放文件进 Cascade
+- 支持所有文件类型
+
+#### **模型管理控制**
+
+- 团队管理员可选择开放哪些模型供团队使用
+- 成员默认仅见管理员启用的模型
+
+#### **Claude Sonnet 3.7 支持**
+
+- Cascade 支持 Claude Sonnet 3.7
+- 工具调用与流程操作表现更优
+
+#### **其他更新**
+
+- 新版快速设置界面与高级设置视图
+
+- 支持读取 .gitignore 文件
+
+- 推出用户推荐系统
+
+- Windsurf directory：官方精选规则集，帮助 Cascade 更好理解你与代码库
+
+ - [查看规则目录](https://codeium.com/windsurf/directory)
+
+## **v 1.3.10**
+
+### **修复内容**
+
+- 优化 Claude 3.7 Sonnet 的积分使用
+- 更新后建议在新会话中运行所有后续操作
+- 新增查看/编辑 .gitignore 文件的选项
+
+## **v 1.3.9**
+
+### **新模型：Claude 3.7**
+
+- Cascade 现已支持 Claude 3.7 Sonnet（高级模型）
+
+
+
+ - 每条消息消耗 1 积分，每次工具调用也消耗 1 积分
+ - “思维模式”下使用该模型积分乘数为 1.5x
+
+
+
+- [渐进推出] GPT-4.5 模型测试中
+
+
+
+ - 因成本、速率限制与质量测试，将逐步放出
+
+
+## **v 1.3.3**
+
+2025 年 2 月 13 日
+
+## **模型上下文协议、自定义应用图标，以及 Tab 跳转**
+
+### **模型上下文协议 (Model Context Protocol)**
+
+- Cascade 现在支持模型上下文协议（MCP）
+- 你可以设置 Cascade 对话使用 MCP 服务器进行工具调用
+- 可以通过点击 Cascade 输入栏的锤子图标设置 MCP
+- 对所有个人用户计划开放
+- 每次 MCP 工具调用消耗 1 个流动操作积分，无论执行结果如何
+
+### **新增可自定义应用图标**
+
+- 你现在可以更改 Windsurf 的应用图标（仅限 Beta & Mac）
+- 付费用户可以选择 Classic、Blueprint、Hand-drawn、Valentine 等风格
+- 更改图标后需重启系统以实现系统级别的图标更新
+- 对所有付费用户计划开放
+- Windows 和 Linux 平台即将上线该功能
+
+### **补全功能改进**
+
+- Tab to Jump 功能正式发布，可智能预测下一个编辑位置并通过 Tab 键跳转
+
+### **Cascade Turbo 模式**
+
+- Cascade Turbo 模式全面升级，可自动执行终端命令（除非被加入拒绝列表）
+- 对所有个人用户计划开放
+
+### **Cascade 拖拽图片支持**
+
+- Cascade支持从系统文件或截图中拖拽图片到输入框
+
+### **积分使用可视化**
+
+- Cascade 现在可以显示每个操作消耗了多少积分
+- 鼠标悬停在执行后的操作上可查看积分消耗
+
+### **其他改进**
+
+- 修复了 Cascade 终端命令的一些 Bug
+- 命令步骤现在会显示自动执行的行为信息
+- 修复了重新加载后 Cascade 面板总是自动打开的问题，即使用户已在设置中关闭
+- 你可以使用 Cmd/Ctrl+L 快捷键 @提及 终端文字，新增了选择弹窗
+- @docs 结果现在支持滚动查看，避免选项被截断
+- @docs 支持更多服务，如 Vercel、Bun、Supabase 等
+
+### **新增模型**
+
+- Cascade 新增高级模型：Gemini 2.0 Flash
+
+
+
+ - 每条消息消耗 0.25 用户提示积分，每次工具调用消耗 0.25 流动操作积分
+
+
+## **v 1.2.4**
+
+2025 年 1 月 31 日
+
+## 新增模型：DeepSeek-R1、DeepSeek-V3 和 o3-mini
+
+### 模型
+
+- 新增高级模型：DeepSeek-R1、DeepSeek-V3 和 o3-mini÷
+- DeepSeek-V3 和 R1 适用于 Pro 和 Pro Ultimate 用户
+- DeepSeek-V3：每条消息消耗 0.25 用户提示积分，每次工具调用消耗 0.25 流动操作积分
+- DeepSeek-R1：每条消息消耗 0.5 用户提示积分，每次工具调用消耗 0.5 流动操作积分
+- o3-mini 适用于所有付费用户
+- o3-mini：每条消息和每次调用均消耗 1 个积分
+
+
+### 修复内容
+
+- 增加拖拽图片至 Cascade 功能支持
+
+## v 1.2.0 弹性积分系统上线，Cascade Base 开源！
+
+2025 年 1 月 25 日
+
+### 弹性积分系统
+
+- Windsurf 现在引入 **弹性积分（Elastic Credits）** 系统
+
+- 拆分为两类积分：
+
+ - 用户提示积分（User Prompt Credits）
+ - 流动操作积分（Fluid Action Credits）
+
+- 模型对话、文件上传、API 工具调用、终端操作都将按实际用途计费，更透明可控
+
+- 设置 > 积分详情中查看各模型和工具的积分消耗
+
+- 套餐每月包含的积分数不变，仅计费方式调整
+
+### Cascade Base 开源
+
+- 作为本地运行的轻量 AI 助理，开源地址：https://github.com/exafunction/cascade
+- 用户可以自定义工具链，连接任意本地服务或模型
+
+### **新增模型**
+
+- **Claude 3 Opus** 模型上线（适用于 Pro Ultimate 用户）
+- 消耗：每条消息需 2 用户提示积分，每次工具调用需 2 流动操作积分
+
+### **改进项**
+
+- 文件上传功能更清晰，拖拽上传 UI 优化
+- 文件上传后自动触发 @files 工具处理内容
+
+## v 1.1.1
+
+2025 年 1 月 19 日
+
+### **修复内容**
+
+- 修复了终端调用 API 返回乱码的问题
+- 修复调用工具时出错未显示详细错误的 bug
+- 修复选择文件时的路径错乱问题
+- 修复长时间运行后模型响应变慢的问题
+
+## v 1.1.0
+
+2025 年 1 月 15 日
+
+## 文件支持、自动调用工具，以及 Claude 3 模型上线！
+
+### **文件功能（Beta）**
+
+- 你现在可以上传文件至对话中，AI 可自动引用内容
+- 支持的文件类型：.txt, .md, .pdf, .docx, .csv, .json 等
+- 文件内容可以通过 @files 工具进行提问和搜索
+- 文件将默认保存在本地，不会上传至云端
+
+### 自动调用工具
+
+- Cascade 现在支持 **自动调用工具**
+- 在你与 AI 对话过程中，会自动触发相关工具（如终端、API、搜索等）
+- 可在设置中手动启用或关闭自动调用
+
+### 新增 Claude 3 模型
+
+- 新增 Anthropic 的 Claude 3 Haiku 和 Claude 3 Sonnet 模型
+
+ - Claude 3 Haiku：快速响应、低消耗
+ - Claude 3 Sonnet：更强大，适用于复杂任务
+
+- 默认对所有付费用户开放，Sonnet 限 Pro 及以上
+
+## v 1.0.6
+
+2024年12月6日
+
+### 使用透明度
+
+
+
+#### 使用透明度与定价
+
+- 推出 Windsurf 的全新使用和定价系统。详情请参见[定价](https://codeium.com/redirect/windsurf/learn-pricing)
+- 快速设置面板现在会显示当前计划的使用情况，包括试用期到期时间、下一个刷新周期的信息以及升级链接
+- Cascade 新增“Legacy Chat”模式，当用户的 Flow Credits 耗尽时激活。此模式功能有限，但无需使用 Flow Credits
+- 在设置面板中查看 Cascade 的使用情况。更多信息请参见[此处](https://docs.codeium.com/windsurf/usage#viewing-your-usage)。
+
+#### Cascade 图片上传
+
+- Cascade 图片上传的大小限制取消为 1MB
+
+#### 增强 Python 语言支持
+
+- 通过 Windsurf Pyright 提供功能丰富的 Python 语言支持。Windsurf Pyright 是 Pylance 的替代方案
+
+### 其他修复
+
+- 从其他基于 VS Code 的 IDE 导入，可连同设置一起导入代码片段
+- 快速设置面板中可查看并配置 AI 相关快捷键
+
+## v 1.0.5 图片上传
+
+2024年11月27日
+
+#### 上传图片到 Cascade
+
+- Cascade 现在支持在高级模型上传图片
+- 上传图片后可以让 Cascade 构建或调整 UI
+
+#### 新增快捷键
+
+- 快捷键在 Cascade 差异视图中导航（默认是 ⌥/Alt + j 和 ⌥/Alt + k）
+- 快捷键在具有 Cascade 差异的文件间导航（默认是 ⌥/Alt + h 和 ⌥/Alt + l）
+
+### 其他修复
+
+- 增加了控制 Cascade 是否自动打开创建/编辑文件的选项（默认启用）
+- 修复了影响部分用户的自动补全设置问题
+- 快速设置面板 UI 更新
+
+## v 1.0.4 解释并修复问题
+
+2024年11月21日
+
+- Cascade 将尝试修复代码库中的问题
+- 鼠标悬停在问题上时会出现选项
+
+#### 从cursor导入
+
+- 导入设置和扩展
+- 可通过命令面板或重置引导流程获取
+
+#### 新增快捷键
+
+- 接受文件中所有活动差异的快捷键（默认是 ⌘/Ctrl + ⏎）
+- 拒绝文件中所有活动差异的快捷键（默认是 ⌘/Ctrl + ⌫）
+- ⌘/Ctrl + Shift + L 打开 Cascade 中的新对话，同时复制选中的终端/编辑器文本到新对话
+
+### 改进与修复
+
+#### 改进的命令
+
+- 改进了 Jupyter Notebook 中的命令体验
+
+#### 改进的差异视图
+
+- 删除了 Cascade 删除文件中的差异显示
+- 更清晰的光标指示，显示已删除文本的差异内容可被选中
+
+### 其他修复
+
+- Windsurf 快速设置面板在点击面板外部时会自动关闭
+- 提高了某些主题中引导元素的可见性
+- 修复了一些轻微的布局问题
+- 增加了加入 Discord 社区的按钮
+- 提高了通过 SSH 使用时 Cascade 面板的稳定性
+- 由 Cascade 编辑/创建的文件将自动在后台打开。如果没有活动的编辑器，首个编辑/创建的文件将作为当前活动编辑器打开
+- 在标题栏下拉菜单中新增了更新日志链接，同时在用户更新版本后显示更新日志提醒
+
+## v 1.0.2 - Windsurf上线
+
+2024年11月13日
+
+
+
+- 正式发布！
+- 使用 Cascade 与 Codeium 的完整代码库上下文聊天，支持多文件编辑
+- 新模式 Supercomplete，可预测下一步意图
\ No newline at end of file
diff --git a/docs/md/AI/document-parsing-and-chunking-in-open-source-tools.md b/docs/md/AI/document-parsing-and-chunking-in-open-source-tools.md
new file mode 100644
index 0000000000..52b8b8e2f6
--- /dev/null
+++ b/docs/md/AI/document-parsing-and-chunking-in-open-source-tools.md
@@ -0,0 +1,102 @@
+# 01-RAG应用框架和解析器
+
+## 1 开源解析和拆分文档
+
+第三方工具去对文件解析拆分，提取文件内容，并将文档内容拆分成一个小chunk。
+
+PDF、word、markdown、JSON、HTML等都有很好的模块执行提取。
+
+### 1.1 优势
+
+- 支持丰富的文档类型
+- 每种文档多样化选择
+- 与开源框架无缝集成
+
+
+
+但有时效果很差，内容跟原文件差别大。
+
+## 2 PDF格式多样性
+
+
+
+复杂多变的文档格式，提高解析效果困难。
+
+## 3 复杂文档格式解析问题
+
+文档内容质量很大程度影响最终效果，文档处理涉及问题：
+
+### 3.1 内容不完整
+
+对文档的内容提取时，可能发现提取出的文档内容会被截断。跨页形式，提取出来它的上下页，两部分内容就会被截断，导致文档内部分内容丢失，去解析图片或双栏复杂的这种格式，它会有一部分内容丢失。
+
+### 3.2 内容错误
+
+同一页PDF文件可能存在文本、表格、图片等混合。
+
+PDF解析过程中，同一页它不同段落其实会也会有不同标准的一些格式。按通用格式去提取解析就遇到同页不同段落格式不标准情况。
+
+### 3.3 文档格式
+
+像常见PDF md文件，需要去支持把这些各类型的文档格式的文件都给提取。
+
+### 3,4 边界场景
+
+代码块还有单元格这些，都是我们去解析一个复杂文档格式中会遇到的一些问题。
+
+## 4 PDF内容提取流程
+
+
+
+## 5 为啥解析文档后，要做知识片段拆分？
+
+### 5.1 Token限制
+
+- 绝大部分开源限制 <= 512 Tokens
+- bge_base、e5_large、m3e_base、text2vector_large_chinese、multilingnal-e5-base..
+
+### 5.2 效果影响
+
+- 召回效果：有限向量维度下表达较多的文档信息易产生失真
+- 回答效果：召回内容中包含与问题无关信息对LLM增加干扰
+
+### 5.3 成本控制
+
+- LLM费用：按Token计费
+- 网络费用：按流量计费
+
+## 6 Chunk拆分对最终效果的影响
+
+### 6.1 Chunk太长
+
+信息压缩失真。
+
+### 6.2 Chunk太短
+
+表达缺失上下文；匹配分数容易变高。
+
+### 6.3 Chunk跨主题
+
+内容关系脱节。
+
+### 原文连续内容（含表格）被截断
+
+单个Chunk信息表达不完整，或含义相反
+
+### 干扰信息
+
+如空白、HTML、XML等格式，同等长度下减少有效信息、增加干扰信息
+
+### 主题和关系丢失
+
+缺失了主题和知识点之间的关系
+
+## 7 改进知识的拆分方案
+
+
+
+## 8 商用向量数据库AI套件
+
+Vector DB AI套件：
+
+
\ No newline at end of file
diff --git a/docs/md/AI/llm/GPT-5.md b/docs/md/AI/llm/GPT-5.md
new file mode 100644
index 0000000000..bb36b0d5e2
--- /dev/null
+++ b/docs/md/AI/llm/GPT-5.md
@@ -0,0 +1,440 @@
+# 面向开发者的GPT-5
+
+我们最先进的编码与智能体任务模型
+
+## 0 简介
+
+北京时间2025年8月8日凌晨一点，正式在 API 平台发布 GPT‑5——我们迄今为止在编码和智能体任务方面表现最佳的模型。
+
+GPT‑5 在关键编码基准测试中处于行业SOTA。
+
+### SOTA
+
+State of the Art,，直译为最先进水平或当前最优。
+
+在人工智能和机器学习领域，它有一个比较明确的专业含义：
+
+- 指在某一特定任务或基准测试（benchmark）上，**当前所有公开已知方法中性能最高的记录**。
+- 它并不是一个固定标准，而是会随着新的技术和模型出现不断被刷新。
+
+**举例理解**：
+
+- 假设业界有一个代码理解的测试集（比如 HumanEval），过去最好成绩是 90 分，那就是当时的 SOTA。
+- 如果 GPT-5 在这个测试里拿了 94 分，就刷新了 SOTA，也就是说它成了“新的最强王者”。
+
+**意义**：
+
+1. **技术标杆**：说明 GPT-5 在该任务上的表现，已经超过所有已知的模型或方法。
+2. **行业信号**：会被学术界和产业界视作重要突破，引发跟进研究或应用。
+3. **商业价值**：在市场宣传中，SOTA 能有效传递“性能最好”的竞争优势。
+
+可将SOTA 理解成 AI 竞赛的 **世界纪录** —— 只要有新选手刷新纪录，它就会被改写。
+
+在 SWE-bench Verified 测试中得分 74.9%，在 Aider polyglot 测试中得分 88%。我们训练了GPT‑5，使其成为真正编码协作伙伴。擅长生成高质量代码并处理诸如修复漏洞、修改代码及解答复杂代码库相关问题等任务。具备可控性和协作性——能以极高精度执行非常详细指令，并在工具调用前及期间提前解释其操作原因。前端编码方面也表现出色，内部测试在 70% 前端 Web 开发任务表现优于 OpenAI o3。
+
+与初创公司和企业早期测试者合作，使用真实世界编码任务对 GPT‑5 训练。除了编码基准测试SOTA，截至目前，GPT‑5 还是[customer A]、[customer B]和[customer C]的默认模型：
+
+- **Cursor** 表示，GPT‑5“具有显著的智能，易于操控，甚至拥有其他模型中不具备的人格特质”
+- **Windsurf** 指出，GPT‑5 在其评估中达到最先进水平，且“与其他前沿模型相比，工具调用错误率仅为其一半”
+
+GPT‑5 在持续型智能体任务中同样表现卓越——在两个月前刚发布的工具调用基准测试 τ2-bench telecom 中，以 96.7% 成绩刷新业界最优水平。在事实准确性基准测试 LongFact 和 FActScore 中，GPT‑5 错误率仅为 o3 的五分之一。GPT‑5 改进的工具智能使其能够可靠地串联数十次工具调用（无论串行还是并行），保持路径一致性，这使其在执行复杂的现实世界端到端任务时表现得远优于其他模型。它还更精确地遵循工具指令，更好地处理工具错误，并在长背景信息内容检索方面表现出色。**Manus** 表示，GPT‑5 “在各种智能体任务中表现出色，即使在未修改任何代码或调整提示的情况下”。**Inditex** 指出：“真正让 [GPT‑5] 脱颖而出的是其推理的深度：细致入微、多层次的答案，体现了对实际主题的深刻理解。”
+
+### API
+
+API 中引入新功能，让开发人员对模型回复具有更多控制权。GPT‑5 支持：
+
+- 新的 `verbosity` 参数（取值：`低`、`中`、`高`），帮助控制控制回答是简短扼要 or 详尽全面
+- `reasoning_effort` 参数可设置为`最小`值，以更快获取答案，无需先行大量推理
+- 新增一种工具类型——自定义工具——使 GPT‑5 能用纯文本而非 JSON 调用工具。自定义工具支持基于背景信息无关文法的约束配置
+
+将在 API 中发布 GPT‑5 的三版——`gpt-5`、`gpt-5-mini` 和 `gpt-5-nano`——以赋予开发人员更多灵活性，在性能、成本和延迟权衡。ChatGPT 中的 GPT‑5 是包含推理、非推理和路由器模型的系统，但 API 平台中的 GPT‑5 是驱动 ChatGPT 实现最佳性能的推理模型。GPT‑5 的最小推理模型与 ChatGPT 中的非推理模型是不同模型，且更适合开发者。
+
+如需了解 ChatGPT 中的 GPT‑5，以及更多关于 ChatGPT 改进的信息，请访问我们的博客[LINK]。如需了解更多关于企业如何积极采用 GPT‑5 的信息，请参阅我们的[企业博客](https://openai.com/zh-Hans-CN/index/gpt-5-new-era-of-work/)。
+
+### 编码
+
+迄今发布最强大编码模型。编码基准测试和实际应用场景中均优于 o3，且经过专门优化，在 Cursor、Windsurf 和 Codex CLI 等智能体编码产品中表现尤为出色。GPT‑5 给我们的 Alpha 测试者留下了深刻印象，在他们多次内部私密评估中创下了多项纪录。
+
+## 1 实际编码任务的早期反馈
+
+### Cursor
+
+> “我们的团队发现，GPT-5 具有显著的智能，易于操控，甚至拥有任何其他模型中不具备的人格特质。它不仅能发现那些难以察觉的深层隐藏漏洞，还能运行长时间的多轮后台任务，确保复杂任务顺利完成——这些正是过去其他模型难以解决的问题。它已成为我们日常工作的得力工具，从规划和实施 PR 到完成端到端构建，无所不能。”
+
+Cursor 联合创始人兼首席执行官 Michael Truell
+
+### Windsurf
+
+> “GPT-5 在我们内部评估中表现优异，该评估主要衡量模型在真实软件工程任务中的性能。我们还发现，该模型相较于其他前沿模型，工具调用错误率降低了一半。它能够以连贯且易于理解的方式持续解决复杂任务。”
+
+Windsurf 工程主管 Edison Zhang
+
+### Vercel
+
+> “GPT-5 通过了我们所有测试。我们在使用它进行 v0.dev 开发时的初步印象是，它是目前最佳的前端 AI 模型，在美学感知和代码质量方面均达到顶尖水平，堪称独树一帜。它在硬核计算机科学与艺术感知能力的交汇点上表现卓越，标志着从过去简单的代码补全功能到能够跨设备和屏幕运行的全栈应用的跨越式发展。”
+
+Vercel 首席执行官兼创始人 Guillermo Rauch
+
+### JetBrains
+
+> “GPT-5 正在改变编码游戏规则。作为默认模型，它使 JetBrains AI 助手和编码智能体 Junie 的性能和质量提升了超过 1.5 倍。”对于我们全新的无代码平台 Kineto，GPT-5 使其构建的应用在设计、前端和整体体验方面实现了端到端质量的翻倍。
+
+Kirill Skrygan，JetBrains 首席执行官
+
+### Factory
+
+> GPT-5 在规划和长背景信息可靠性方面表现卓越，尤其擅长与 Factory 的 Code Droid 协同执行复杂的异步重构任务。它拥有强大的智能体功能，增强了 Code Droid 绘制影响图、细致收集背景信息、提出分步计划、生成精确差异、更新测试和运行持续集成 (CI) 的能力。
+
+Factory 联合创始人兼首席技术官 Eno Reyes
+
+### Lovable
+
+> “我们对 GPT-5 的内部测试表明，它将使数百万 Lovable 用户在应用开发过程中走得更远。它能够通过单个提示生成高级应用，并能够调试现有大型项目中的复杂问题。它在处理大型代码库的推理和代码重构以提高可维护性方面表现出色。”
+
+Lovable AI 负责人 Alexandre Pesant
+
+### Gitlab
+
+> “GPT-5 在复杂的软件工程任务中表现出色。该模型始终只需更少的工具调用即可解决问题，同时生成更稳定可靠、更易于维护的代码。GPT-5 的可靠性和效率让我们对部署它充满信心。”
+
+GitLab 首席技术官 Sabrina Farmer
+
+### Augment Code
+
+> “GPT-5 是一款领先的编码模型。它在跨文件推理和依赖关系解析方面表现尤为出色，并且在进行大规模代码修改时能够谨慎操作并进行明确验证。我们认为这是一种适用于大型项目场景的理想选择，尤其是在涉及多个文件的更改并需要考虑整个项目范围内的限制条件时。”
+
+Augment Code 联合创始人兼首席科学家 Guy Gur-Ari
+
+### GitHub
+
+> “在我们的评估中，我们发现 OpenAI 的 GPT-5 在 o3 的先进推理能力基础上进一步提升，使开发人员能够解决更复杂的问题——从代码重构到处理大型代码库。我们很高兴将这一技术引入 GitHub Copilot，助力数百万开发人员利用这一全新智能，解决更宏大的技术挑战。”
+
+GitHub 首席执行官 Thomas Dohmke
+
+### Cognition
+
+> “GPT-5 相较于之前的 OpenAI 模型（如 GPT-4.1）代表了巨大的飞跃。我们认为 GPT-5 处于智能体能力的前沿，并在需要复杂代码理解的任务中表现出色。在我们的初级 SWE 评估中，GPT-5 在代码探索和规划方面表现尤为突出。”
+
+Cognition 联合创始人兼首席执行官 Scott Wu
+
+## 2 评测
+
+### SWE-bench Verified
+
+在基于真实软件工程任务的 SWE-bench Verified 评估中，GPT‑5 的得分达到 74.9%，较 o3 版本的 69.1% 有所提升。GPT‑5以更高效率和速度获得高分：与 o3 在高推理强度下相比，GPT‑5 的输出令牌数量减少 22%，工具调用次数减少 45%。
+
+
+
+在 [SWE-bench Verified](https://openai.com/index/introducing-swe-bench-verified/) 基准测试中，模型会获得代码仓库和问题描述，并需要生成补丁来解决问题。文本标签用于标识推理强度。我们的评分排除了 500 个问题中的 23 个，因其解决方案在我们的测试环境中无法稳定通过。GPT‑5 收到一个简短的提示，强调要彻底验证解决方案；而相同的提示对 o3 没有帮助。
+
+### Aider polyglot
+
+在评估代码编辑能力的 Aider polyglot 测试中，GPT‑5 以88% 的得分刷新纪录，其错误率较 o3 版本降低了三分之二。
+
+
+
+### Aider Polyglot
+
+在 [Aider Polyglot](https://aider.chat/2024/12/21/polyglot.html#the-polyglot-benchmark) (diff) 中，模型会收到来自 Exercism 的编码练习，且必须将其解决方案以代码差异的形式编写出来。推理模型在高推理强度下运行。
+
+GPT‑5 在深度分析代码库方面表现出色，能够精准解答关于代码模块运作机制及相互协作的问题。在像 OpenAI 的强化学习框架这样复杂的代码库中，我们发现 GPT‑5 能够帮助我们分析和解答关于代码的问题，从而加速我们日常工作的效率。
+
+## 3 前端工程
+
+在为 Web 应用生成前端代码时，GPT‑5 展现出更优的审美水准、更强的能力和更高的准确性。在与 o3 的并排比较中，GPT‑5 在 70% 的情况下更受我们的测试人员青睐。
+
+以下是一些精选的有趣示例，展示 GPT‑5 仅需单次提示就能完成的任务：
+
+### 3.1 Espresso Lab 网站
+
+
+
+**提示：**请为一项服务设计一个美观且真实的登录页，该服务面向顶级咖啡爱好者，提供每月 200 美元的订阅计划，包含咖啡烘焙设备租赁及专业指导，助其打造完美意式浓缩咖啡。目标受众为旧金山湾区的中年人群，可能从事科技行业，受过良好教育，拥有可支配收入，并对咖啡的艺术与科学充满热情。优化转化率，以实现 6 个月的订阅注册。
+
+### 3.2 音频步进序列器应用
+
+
+
+
+
+**提示：**在单个 HTML 文件中创建单页应用，满足以下要求：
+
+- `名称：音频步进序列器`
+- `堆栈：WebAudio API。`
+- `目标：16 步鼓网格。`
+- `功能：节奏、摇摆、模式保存/加载、导出 WAV（渲染简单缓冲区）。`
+- `界面应具有未来感，让播放变得有趣！`
+
+### 3.3 外太空游戏
+
+
+
+**`提示：`**`制作一款 2D 太空游戏，玩家可以驾驶飞船，躲避并摧毁小行星，并与其他由计算机控制的 AI 进行空战。在飞船设计上要富有创意。确保游戏玩法正常且有趣。将代码输出到单个 next.js 页面文件 (page.tsx) 中，该文件可直接粘贴到由 create-next-app 创建的 next.js 应用中，并附带运行所需的任何背景信息或说明。`
+
+更多 GPT‑5 生成示例，访问[这里](https://platform.openai.com/docs/guides/latest-model?gallery=open)的图库。
+
+## 4 编码协作
+
+GPT‑5 不仅是出色的程序员，还是更优秀的协作者，尤其在 Cursor、Windsurf 和 Codex CLI 等智能体编码产品中表现突出。在运行过程中，GPT‑5 能够在工具调用间隙输出执行计划、状态更新和操作摘要。相比我们以往的模型，GPT‑5 在执行复杂任务时更具主动性，无需等待用户确认指令，也不会因任务复杂度高而迟疑。
+
+当用户请求为其餐厅创建网站时，GPT‑5 会快速制定计划、搭建应用框架、安装依赖项、生成网站内容、运行构建流程以检查编译错误、总结工作成果，并提出潜在的下一步建议。完整创建网站的实际耗时约为三分钟。
+
+## 5 智能体任务和早期反馈
+
+除智能体编码外，GPT‑5 在各类智能体任务中的表现都更为出色。GPT‑5 在指令遵循（在 o3‑mini 评分下，[Scale MultiChallenge](https://arxiv.org/abs/2501.17399) 上的得分达到 69.6%）和工具调用（在 τ2 -bench telecom 上的得分达到 96.7%）的基准测试中创下了新纪录。通过增强的工具智能，GPT‑5 能更可靠地串联多个操作步骤来完成现实世界任务。
+
+### Manus
+
+> “GPT-5 是一个重大飞跃。它在我们的内部基准测试中取得了迄今为止单个模型的最佳性能。GPT-5 在各种智能体任务中都表现出色，即使在我们尚未修改任何代码或调整提示词之前。通过新的前导消息机制和更精准的工具控制体系，我们的智能体在稳定性和可控性方面实现了质的飞跃。”
+
+Manus 联合创始人兼首席科学家 Yichao ‘Peak’ Ji
+
+### Mercado Libre
+
+> “GPT-5 在所有评估模型中表现最为出色。工具执行精度较 o4-mini 提升了 9%，较 GPT-4.1 提升了 36%，而工具与消息的综合准确率分别提升了 24% 和 47%。新的 ‘verbosity’ 参数是获得恰当细节水平答案的关键，从而提升了模型的回复质量。”
+
+### Notion
+
+> “GPT-5 在智能与速度之间实现了完美的平衡。作为我们首个引入 Notion AI 的推理模型，它在处理长期任务时表现出色，成功率较之前提升了 15%。其快速响应能力，尤其在低推理模式下，使 GPT-5 成为解决复杂任务的一站式理想选择。”
+
+Notion AI 工程主管 Abhishek Modi
+
+### Genspark
+
+> “GPT-5 在 Genspark 的 Super Agent 基准测试中，相较于 GPT-4.1，用户满意度提升了 79%。该基准测试旨在评估复杂工具使用及具有挑战性的端到端任务。与我们的实时系统相比，GPT-5 还使不满意的响应减少了 34%，这对系统可靠性至关重要。此外，GPT-5 在 HTML 和 PowerPoint 生成方面展现出更强大的创造性判断力，能够生成更精致、更现代的设计，并更好地遵循指令。”
+
+Genspark 联合创始人兼首席技术官 Kay Zhu
+
+### Inditex
+
+> GPT-5 不仅会响应，更懂得预判。它彻底改变了我们将销售数据转化为可操作洞察的方式，能够主动分析背景信息并提前提供建议，甚至在我们想到提问之前就已完成，从而节省了无数次迭代。其对提示的精准解读——对语气、范围和结构的精确控制——结合细致入微、多层次的推理能力，使其更像是一位专家级合作伙伴，而非单纯的工具。
+
+Inditex 数据与 AI 负责人 Oscar Mateos Ventura
+
+### Zendesk
+
+> “在 Zendesk，我们正在将 GPT-5 直接集成到我们的生产工作流程中。在我们的 AI 智能体中，它能够提供更完整、更少遗漏细节的回复，将回退升级率降低了超过 20%。在 App Builder 中，它比之前快了 25 至 30%，并能够实现每分钟多达 3 至 4 倍的提示迭代——这极大地加快了客户的开发速度。”
+
+Zendesk 产品、工程与 AI 部门总裁 Shashi Upadhyay
+
+### Canva
+
+> “GPT-5 代表了人工智能领域的一次重大飞跃。我们特别对其在编码、多步骤任务和智能体系统方面的能力印象深刻，我们的评估显示，其在完成复杂任务的成功率上提升了 44%。该模型能够理解并遵循更复杂、更精细的提示，我们还观察到它能够解决此前大型语言模型 (LLMs) 无法一次性解决的问题。”
+
+Canva AI 产品负责人 Danny Wu
+
+### Atlassian
+
+> “在测试中，GPT-5 在 Rovo 的多智能体协调以及 RovoDev 的编码任务中均表现出色。它能够轻松处理模糊性，明确用户意图，并有效调度子智能体以完成复杂的多步骤任务——包括深入研究。在各种场景下，它都能以更高的令牌效率提供高质量解决方案，使其成为需要大量推理的开发工作流的强大工具。”
+
+Atlassian AI 与产品工程高级副总裁兼负责人 Taroon Mandhana
+
+### Harvey
+
+> “在我们对 GPT-5 的早期访问中，该模型在所有领域，尤其是我们所在的法律领域，实现自主行为的潜力是显而易见的。该模型在法律推理、工具使用与协调以及长篇文书起草能力方面有着令人印象深刻的结合——这些都是我们用例中至关重要的能力。”
+
+Harvey 首席执行官兼联合创始人 Winston Weinberg
+
+### BBVAClay优步 (Uber)
+
+> GPT-5 擅长编写代码和处理技术任务，从而实现工作流程的自动化。在某一案例中，模型甚至帮助我们完成了一项非常战略性的任务，原本需要二到三周的时间，现在只需几个小时即可完成，展现出令人惊叹的主动性。”GPT-5 因其速度和处理西班牙语的能力脱颖而出，在准确性方面超越了旧模型，并且运行速度是旧模型的两倍。”
+
+BBVA 全球 AI 应用负责人 Elena Alfaro
+
+> “GPT-5 是一个重大飞跃。它在我们的内部基准测试中取得了迄今为止单个模型的最佳性能。GPT-5 在各种智能体任务中都表现出色，即使在我们尚未修改任何代码或调整提示词之前。通过新的前导消息机制和更精准的工具控制体系，我们的智能体在稳定性和可控性方面实现了质的飞跃。”
+
+
+## 6 工具调用
+
+我们努力优化了工具调用机制，以满足开发者的实际需求。GPT‑5 在遵循工具指令、处理工具错误以及自主实现串行或并行的多工具调用方面表现更佳。当收到指令时，GPT‑5 还可以在工具调用前及期间输出前置消息，以便在执行较长的智能体任务时向用户更新进度。
+
+两个月前，Sierra.ai 发布了τ2-bench telecom 测试基准，该基准作为高难度工具使用评估体系，重点揭示了语言模型在用户可变更环境状态下的性能显著衰减现象。根据其[发布报告](https://arxiv.org/pdf/2506.07982)，所有参评模型的得分均未超过 49%。而 GPT‑5 的得分为 97%。
+
+在 [τ2-bench](https://arxiv.org/pdf/2506.07982) 测试中，模型必须使用工具来完成一项客户服务任务，其中可能存在能够与系统交互并根据系统状态采取行动的用户。推理模型在高推理强度下运行。
+
+
+
+GPT‑5 在长背景信息性能方面也展现出显著提升。在 OpenAI-MRCR（一种衡量长背景信息检索能力的指标）中，GPT‑5 的表现优于 o3 和 GPT‑4.1，且随着输入长度的增加，这种优势会显著扩大。
+
+
+
+在 [OpenAI-MRCR](https://huggingface.co/datasets/openai/mrcr)（多轮共指解析）中，多个相同的“针”用户请求被插入到由相似请求和响应组成的长“草堆”中，模型被要求重现第 i 个“针”的响应。平均匹配比率衡量模型回复与正确答案之间的平均字符串匹配比率。在 256k 最大输入令牌处的数据点代表 128k 至 256k 输入令牌范围内的平均值，依此类推。这里，256k 代表 256 × 1,024 = 262,114 个令牌。推理模型在高推理强度下运行。
+
+还开源[BrowseComp Long Context](https://huggingface.co/datasets/openai/BrowseCompLongContext)，评估长背景信息问答的新基准。在此基准中，模型会收到用户查询、一长串相关搜索结果，并必须基于搜索结果回答问题。设计时，旨在使其具有现实性、挑战性，并确保基准答案绝对可靠。对输入量为 128K 至 256K 令牌的数据，GPT‑5 的正确率 89%。
+
+在 API 中，所有 GPT‑5 模型最多可接受 272,000 个输入令牌，并生成最多 128,000 个推理及输出令牌，总上下文长度为 400,000 个令牌。
+
+#### 事实性
+
+GPT‑5 比我们之前的模型更值得信赖。在 LongFact 和 FactScore 基准测试的提示下，GPT‑5 的事实错误率比 o3 低约 80%。这使得 GPT‑5 尤其适用于正确性要求高的智能体任务场景，特别是在代码生成、数据处理和决策支持等关键领域。
+
+
+
+分数越高越差。[LongFact](https://arxiv.org/abs/2403.18802) 和 [FActScore](https://arxiv.org/abs/2305.14251) 由开放式事实求证问题组成。使用基于LLM的评分系统，通过浏览功能对这些基准测试中的提示进行事实核查，并测量事实错误陈述的比例。推理模型采用了高推理强度。搜索功能未启用。
+
+通常，GPT‑5 经过训练后能够更好地认识到自身的局限性，并更有效地应对突发状况。我们还对 GPT‑5 进行了训练，使其在健康相关问题上更加准确。与所有语言模型一样，建议在重要场合使用 GPT‑5 时进行验证。
+
+## 7 新功能
+
+### 7.1 最低推理强度
+
+开发人员可通过 API 中的 `reasoning_effort` 参数控制 GPT‑5 的推理耗时。除原`低`、`中`（默认值）和`高`三档参数外，GPT‑5 还支持`最低`模式，该模式会将 GPT‑5 的推理强度降到到最低，以快速返回答案。
+
+- 调高，可优化输出质量
+- 降低，可提升响应速度
+
+并非所有任务都能通过额外的推理获得同等收益，建议根据实际应用场景测试调参，以确定最佳配置方案。
+
+如相对简单的长背景信息检索任务中，提升推理能力（`低`以上级别）带来的增益有限，但视觉推理基准测试 [CharXiv Reasoning（在新窗口中打开）](https://arxiv.org/abs/2406.18521) 能提升几个百分点。
+
+
+
+GPT‑5 的推理强度在不同任务上带来不同收益。对于 CharXiv 推理任务，GPT‑5 被授予访问一个 Python 工具的权限。
+
+### 7.2 Verbosity
+
+为调控 GPT‑5 回答的默认长度，新增 `verbosity` API 参数，该参数支持`低`、`中`（默认值）和`高`三档可选值。如果显式指令与冗余参数发生冲突，则显式指令优先。例如，如果您让 GPT‑5“写一篇五段论文章”，该模型的回复始终应包含五段内容，无论冗长程度如何（不过，各段落的长度可能有所不同）。
+
+#### Verbosity=low
+
+**Why is the sky blue?**
+
+Because of Rayleigh scattering. Air molecules are much smaller than the wavelength of visible light, so they scatter short wavelengths (blue/violet) far more than long ones (red). The scattered blue light comes to your eyes from all directions, making the sky look blue. We don’t see violet as much because the Sun emits less of it, our eyes are less sensitive to it, and some is absorbed in the upper atmosphere. At sunrise and sunset, the longer path through air removes more blue, leaving the sky reddish.
+
+#### Verbosity=medium
+
+**Why is the sky blue?**
+
+Because of Rayleigh scattering. Sunlight contains all colors, but air molecules scatter shorter wavelengths (blue/violet) much more strongly than longer wavelengths (red). The scattering strength goes roughly as 1/(wavelength)^4, so blue light gets redirected across the sky and into your eyes.
+
+We don’t see a violet sky because:
+
+- The Sun emits slightly less violet than blue.
+- The upper atmosphere absorbs some violet/UV.
+- Human eyes are less sensitive to violet.
+
+At sunrise and sunset, sunlight passes through more atmosphere, scattering out most of the blues along the way and leaving the longer red/orange wavelengths to dominate.
+
+#### Verbosity=high
+
+**Why is the sky blue?**
+
+The sky looks blue because sunlight gets scattered by the tiny molecules in Earth’s atmosphere. This process is called Rayleigh scattering.
+
+Key points:
+
+- Sunlight is made of many colors (wavelengths). Shorter wavelengths, like violet and blue, are scattered much more strongly by air molecules than longer wavelengths like red. The scattering strength increases sharply as wavelength gets shorter.
+- As sunlight passes through the atmosphere, the shorter-wavelength light (especially blue) is scattered in all directions, so no matter where you look away from the Sun, you see that scattered blue light — the “blue sky.”
+
+Why not violet?
+
+- The Sun emits less violet than blue.
+- Our eyes are less sensitive to violet.
+- Some violet/UV is absorbed higher up by ozone.
+
+Together, that makes the scattered light we perceive look mainly blue.
+
+Why are sunsets red/orange?
+
+- Near sunrise and sunset, sunlight travels a much longer path through the atmosphere.
+- Much of the blue light gets scattered out of the direct path before it reaches your eyes, leaving the remaining direct sunlight enriched in reds and oranges.
+
+Other influences:
+
+- Haze, pollution, smoke, or dust have larger particles that scatter light less selectively (called Mie scattering), making the sky look paler or whitish.
+- The blue sky is partially polarized due to the scattering geometry, which is why polarized sunglasses can darken parts of it.
+- On worlds with different atmospheres and particle sizes (like Mars), skies can look butterscotch or reddish for similar scattering reasons.
+
+If Earth had no atmosphere, there would be nothing to scatter sunlight, and the sky would appear black even in daytime, with the Sun as a bright disk.
+
+### 7.3 工具调用前的前置消息
+
+如果收到指令，GPT‑5 将在工具调用前及调用期间输出用户可见的前置消息。与隐藏的推理消息不同，这些可见的消息使 GPT‑5 能够向用户传达计划和进展，帮助最终用户理解其在工具调用背后的方法和意图。
+
+### 7.4 自定义工具
+
+正推出一种新的工具类型，即自定义工具，它允许 GPT‑5 使用纯文本而非 JSON 调用工具。为了限制 GPT‑5 遵循自定义工具格式，开发人员可以提供正则表达式，甚至更详细的[背景信息无关文法](https://platform.openai.com/docs/guides/function-calling#context-free-grammars)。
+
+之前，为开发人员自定义工具设计的接口要求必须采用 JSON 格式调用，而 JSON 是 Web API 及开发人员群体广泛使用的通用格式。然而，要输出有效的 JSON，模型必须完美地转义所有引号、反斜杠、换行符和其他控制字符。尽管我们的模型经过充分训练能够输出 JSON 格式，但当输入内容较长时（例如数百行代码或一份 5 页报告），其出错概率会显著上升。借助自定义工具，GPT‑5 可以将工具输入以纯文本形式编写，无需对所有需要转义的字符进行转义处理。
+
+在 SWE-bench 中，使用自定义工具而非 JSON 工具进行验证时，GPT‑5 的得分与之前大致相同。
+
+## 8 安全性
+
+GPT‑5 在安全性方面取得了重大突破，是一款更加稳健、可靠且实用的新型模型。与我们之前的模型相比，GPT‑5 出现幻觉的可能性显著降低，能够更诚实地向用户传达其行为和能力，并在确保安全边界的前提下，尽可能提供最有用答案。
+
+## 9 可用性和定价
+
+GPT‑5 现已在 API 平台以三种规格提供：`gpt-5`、`gpt-5-mini` 和 `gpt-5-nano`。它支持回复 API、聊天完成 API，并作为 Codex CLI 的默认模型。API 中的所有 GPT‑5 模型均支持 `reasoning_effort` 和 `verbosity `API 参数，以及自定义工具。此外，它们还支持并行工具调用、内置工具（Web 搜索、文件搜索、图像生成等）、核心 API 功能（流式处理、结构化输出等），以及节省成本的功能，如提示缓存和批量 API。
+
+查看 GPT‑5 [文档](https://platform.openai.com/docs/models/gpt-5)、[定价详情](https://platform.openai.com/docs/pricing)和[提示指南](https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide)，立即开始使用。
+
+## 10 详细基准测试
+
+### Intelligence
+
+| | GPT-5(high) | GPT-5 mini(high) | GPT-5 nano(high) | OpenAI o3(high) | OpenAI o4-mini(high) | GPT-4.1 | GPT-4.1 mini | GPT-4.1 nano |
+| ----------------------------------- | ----------- | ---------------- | ---------------- | --------------- | -------------------- | ------- | ------------ | ------------ |
+| AIME ’25(no tools) | 94.6% | 91.1% | 85.2% | 86.4% | 92.7% | 46.4% | 40.2% | - |
+| FrontierMath(with python tool only) | 26.3% | 22.1% | 9.6% | 15.8% | 15.4% | - | - | - |
+| GPQA diamond(no tools) | 85.7% | 82.3% | 71.2% | 83.3% | 81.4% | 66.3% | 65.0% | 50.3% |
+| HLE[1](no tools) | 24.8% | 16.7% | 8.7% | 20.2% | 14.7% | 5.4% | 3.7% | - |
+| HMMT 2025(no tools) | 93.3% | 87.8% | 75.6% | 81.7% | 85.0% | 28.9% | 35.0% | - |
+
+[1] There is a small discrepancy with numbers reported in our previous blog post, as those were run on a former version of HLE.
+
+##### Multimodal
+
+| | GPT-5(high) | GPT-5 mini(high) | GPT-5 nano(high) | OpenAI o3(high) | OpenAI o4-mini(high) | GPT-4.1 | GPT-4.1 mini | GPT-4.1 nano |
+| --------------------------------------------- | ----------- | ---------------- | ---------------- | --------------- | -------------------- | ------- | ------------ | ------------ |
+| MMMU | 84.2% | 81.6% | 75.6% | 82.9% | 81.6% | 74.8% | 72.7% | 55.4% |
+| MMMU-Pro(avg across standard and vision sets) | 78.4% | 74.1% | 62.6% | 76.4% | 73.4% | 60.3% | 58.9% | 33.0% |
+| CharXiv reasoning(python enabled) | 81.1% | 75.5% | 62.7% | 78.6% | 72.0% | 56.7% | 56.8% | 40.5% |
+| VideoMMMU, max frame 256 | 84.6% | 82.5% | 66.8% | 83.3% | 79.4% | 60.9% | 55.1% | 30.2% |
+| ERQA | 65.7% | 62.9% | 50.1% | 64.0% | 56.5% | 44.3% | 42.3% | 26.5% |
+
+### Coding
+
+| | GPT-5(high) | GPT-5 mini(high) | GPT-5 nano(high) | OpenAI o3(high) | OpenAI o4-mini(high) | GPT-4.1 | GPT-4.1 mini | GPT-4.1 nano |
+| ------------------------------------------------- | ----------- | ---------------- | ---------------- | --------------- | -------------------- | -------- | ------------ | ------------ |
+| SWE-Lancer: IC SWE Diamond Freelance Coding Tasks | US$11万 | US$7.5万 | US$4.9万 | US$8.6万 | US$6.6万 | US$3.4万 | US$3.1万 | US$9000 |
+| SWE-bench Verified[2] | 74.9% | 71.0% | 54.7% | 69.1% | 68.1% | 54.6% | 23.6% | - |
+| Aider polyglot(diff) | 88.0% | 71.6% | 48.4% | 79.6% | 58.2% | 52.9% | 31.6% | 6.2% |
+
+### Instruction Following
+
+| | GPT-5(high) | GPT-5 mini(high) | GPT-5 nano(high) | OpenAI o3(high) | OpenAI o4-mini(high) | GPT-4.1 | GPT-4.1 mini | GPT-4.1 nano |
+| --------------------------------------------- | ----------- | ---------------- | ---------------- | --------------- | -------------------- | ------- | ------------ | ------------ |
+| Scale multichallenge[3](o3-mini grader) | 69.6% | 62.3% | 54.9% | 60.4% | 57.5% | 46.2% | 42.2% | 31.1% |
+| Internal API instruction following eval(hard) | 64.0% | 65.8% | 56.1% | 47.4% | 44.7% | 49.1% | 45.1% | 31.6% |
+| COLLIE | 99.0% | 98.5% | 96.9% | 98.4% | 96.1% | 65.8% | 54.6% | 42.5% |
+
+[3] Note: we find that the default grader in MultiChallenge (GPT-4o) frequently mis-scores model responses. We find that swapping the grader to a reasoning model, like o3-mini, improves accuracy on grading significantly on samples we’ve inspected.
+
+### Function Calling
+
+| | GPT-5(high) | GPT-5 mini(high) | GPT-5 nano(high) | OpenAI o3(high) | OpenAI o4-mini(high) | GPT-4.1 | GPT-4.1 mini | GPT-4.1 nano |
+| ------------------ | ----------- | ---------------- | ---------------- | --------------- | -------------------- | ------- | ------------ | ------------ |
+| Tau2-bench airline | 62.6% | 60.0% | 41.0% | 64.8% | 60.2% | 56.0% | 51.0% | 14.0% |
+| Tau2-bench retail | 81.1% | 78.3% | 62.3% | 80.2% | 70.5% | 74.0% | 66.0% | 21.5% |
+| Tau2-bench telecom | 96.7% | 74.1% | 35.5% | 58.2% | 40.5% | 34.0% | 44.0% | 12.1% |
+
+### Long Context
+
+| | GPT-5(high) | GPT-5 mini(high) | GPT-5 nano(high) | OpenAI o3(high) | OpenAI o4-mini(high) | GPT-4.1 | GPT-4.1 mini | GPT-4.1 nano |
+| -------------------------------------- | ----------- | ---------------- | ---------------- | --------------- | -------------------- | ------- | ------------ | ------------ |
+| OpenAI-MRCR: 2 needle 128k | 95.2% | 84.3% | 43.2% | 55.0% | 56.4% | 57.2% | 47.2% | 36.6% |
+| OpenAI-MRCR: 2 needle 256k | 86.8% | 58.8% | 34.9% | - | - | 56.2% | 45.5% | 22.6% |
+| Graphwalks bfs <128k | 78.3% | 73.4% | 64.0% | 77.3% | 62.3% | 61.7% | 61.7% | 25.0% |
+| Graphwalks parents <128k | 73.3% | 64.3% | 43.8% | 72.9% | 51.1% | 58.0% | 60.5% | 9.4% |
+| BrowseComp Long Context 128k | 90.0% | 89.4% | 80.4% | 88.3% | 80.0% | 85.9% | 89.0% | 89.4% |
+| BrowseComp Long Context 256k | 88.8% | 86.0% | 68.4% | - | - | 75.5% | 81.6% | 19.1% |
+| VideoMME(long, with subtitle category) | 86.7% | 78.5% | 65.7% | 84.9% | 79.5% | 78.7% | 68.4% | 55.2% |
+
+### Hallucinations
+
+| | GPT-5(high) | GPT-5 mini(high) | GPT-5 nano(high) | OpenAI o3(high) | OpenAI o4-mini(high) | GPT-4.1 | GPT-4.1 mini | GPT-4.1 nano |
+| ------------------------------------------------------------ | ----------- | ---------------- | ---------------- | --------------- | -------------------- | ------- | ------------ | ------------ |
+| LongFact-Concepts hallucination rate(no tools)[lower is better] | 1.0% | 0.7% | 1.0% | 5.2% | 3.0% | 0.7% | 1.1% | - |
+| LongFact-Objects hallucination rate(no tools)[lower is better] | 1.2% | 1.3% | 2.8% | 6.8% | 8.9% | 1.1% | 1.8% | - |
+| FActScore hallucination rate(no tools)[lower is better] | 2.8% | 3.5% | 7.3% | 23.5% | 38.7% | 6.7% | 10.9% | - |
\ No newline at end of file
diff --git a/docs/md/AI/llm/Kimi-K2.md b/docs/md/AI/llm/Kimi-K2.md
new file mode 100644
index 0000000000..099091b3c1
--- /dev/null
+++ b/docs/md/AI/llm/Kimi-K2.md
@@ -0,0 +1,238 @@
+# Kimi K2：开源智能体引擎
+
+## 0 前言
+
+Kimi K2 是我们最新发布的MoE，激活参数达 320 亿，总参数量高达 1 万亿。在前沿知识、数学与编程任务中，Kimi K2 在“非思维模型”类别中表现优异，达到当前最先进水平。但这还不是全部 —— Kimi K2 针对“智能体任务”进行了精心优化，它不仅能回答问题，更能**执行任务**。
+
+本次开源：
+
+- Kimi-K2-Base：基础模型，适合研究人员和开发者微调和定制
+- Kimi-K2-Instruct：经过后训练优化，适合通用对话与智能体应用，即插即用，无需深度思考
+
+Kimi K2 让先进的智能体智能更加开放与可及。期待看到你用它构建的精彩应用。
+
+## 1 智能体与竞赛级编程能力
+
+SWE-bench Verified：
+
+
+
+SWE-bench Multilingual：
+
+
+
+LiveCodeBench v6：
+
+
+
+OJBench：
+
+
+
+## 2 工具使用能力
+
+Tau2-bench 加权平均值：
+
+
+
+AceBench（英文）
+
+
+
+## 3 数学与 STEM 能力
+
+AIME 2025：
+
+
+
+GPQA-Diamond：
+
+
+
+上述评测模型均为非思考模型
+
+Tau2-Bench 按任务权重加权
+
+SWE-Bench Multilingual 仅评测了 Claude 4 Sonnet，因 Claude 4 Opus 成本过高
+
+## 4 应用场景示例
+
+只需将工具和任务描述交给 Kimi K2，它会自动理解并完成任务，无需你手动编写复杂流程。
+
+### 4.1 工资数据分析
+
+**示例任务：**
+
+利用 2020–2025 年工资数据，分析远程办公比例对工资的影响，并判断该影响是否随工作经验等级（入门/中级/高级/专家）而显著不同，即是否存在交互效应。分析需包含统计证据和丰富的可视化图表，配色统一和谐（建议使用柔和色调）。
+
+**分析流程如下（使用 IPython 执行）**：
+
+1. 加载数据并了解结构
+2. 筛选 2020–2025 年的数据，绘制小提琴图按经验和远程比例分类展示工资分布
+3. 将 `remote_ratio` 分类为“现场办公”、“混合办公”和“远程办公”，再绘制箱线图比较不同经验等级的工资分布
+4. 进行双因素方差分析（ANOVA），检验远程办公与经验等级的主效应与交互效应
+5. 因数据不足，改用每组经验等级内远程 vs 现场的成对 t 检验，比较显著性
+6. 计算各组合的平均工资，使用柱状图清晰展示交互情况
+7. 进一步生成交互图、散点图、平均薪资对比图，直观展示远程办公对不同经验等级工资的影响
+8. 最后生成总结图，清晰展示不同经验等级远程 vs 现场办公的工资百分比差异
+
+**结论摘要**：
+
+使用 2020–2025 年的数据，我们检验了远程办公比例对工资的影响及其是否因经验等级而不同。结果发现：**远程办公比例与经验等级之间存在显著的交互作用**。
+
+#### 关键统计结果：
+
+- **入门级员工**：远程比现场高出 **8.0%**，p≈0.20（不显著）
+- **中级员工**：远程比现场低 **8.5%**，p=0.003（高度显著）
+- **高级员工**：远程比现场低 **3.5%**，p≈0.05（边缘显著）
+- **专家级员工**：远程比现场高 **4.6%**，p≈0.61（不显著）
+
+#### 可视化分析：
+
+图表清晰展示了远程办公带来的薪资差异会因经验等级而异。尤其是中级员工，远程办公者面临明显薪资劣势，而入门和专家级可能会略有优势。
+
+#### 总结：
+
+远程办公对工资的影响并非一致，而是随经验等级而变。对于中级员工，远程办公可能带来显著的薪资惩罚，而对入门与专家级员工则可能带来一定优势。
+
+------
+
+### 4.2 可视化网页展示
+
+我们为这份分析设计了一个精美网页，包含：
+
+#### 🎨 设计亮点：
+
+- 柔和 / 馥郁色调（pastel, muted），时尚杂志风格
+- 清晰的排版与响应式设计，适配手机与桌面
+- 统一的视觉层次与间距控制
+
+#### 📊 数据分析内容：
+
+- **执行摘要**：关键统计数据以图卡形式展示
+- **详细分析过程**：包括数据清洗、可视化、统计检验
+- **图表展示**：嵌入所有可视化图像
+
+#### 🧮 交互模拟器：
+
+- 用户可输入：经验等级、期望薪资、远程意愿、行业
+- 实时模拟推荐是否适合远程办公
+- 颜色提示结果（绿=推荐，黄=谨慎，红=不推荐）
+- 详细预测远程办公对工资的影响
+
+### 4.3 Kimi K2 的其他示例
+
+- 使用 16 个 IPython 步骤，自动完成数据分析并生成网页
+- 结合网页搜索、浏览器操作、滚动、点击和部署，实现自动生成互动站点
+- 安排 Coldplay 伦敦演唱会行程，包括搜索航班、餐厅与 Airbnb 预订
+
+想象一下，使用 Kimi K2 探索远程办公薪资，借助“薪资数据分析”这个示例，16 个 IPython 调用自动生成统计结果、可视化图表和一个交互式网页；深入了解 Stanford NLP 系谱图谱，Kimi K2 可通过 5 次网页搜索、4 次浏览、3 次点击、5 次滚动、6 次编辑和 2 次部署，构建出一个交互式站点；又或是计划你心中的 2025 年 Coldplay 伦敦巡演之旅，Kimi K2 可通过 17 次无缝工具调用完成从搜索、日历、Gmail、航班、Airbnb 到餐厅预订的全部流程。
+
+现在，把 Kimi K2 带到你的命令行中吧。它能编辑文件，能执行命令。
+
+Kimi K2 能理解你的操作环境，自主决定下一步执行什么，并顺利完成任务。
+
+### 4.4 示例：用 JavaScript 编写 3D Minecraft 网页版
+
+去官网。
+
+为便于理解，终端中仅显示每条任务轨迹的概要信息。在每个示例中，Kimi K2 都在幕后协调多个工具与命令，来完成复杂目标。例如，Kimi K2 可自动完成 JavaScript 编写的 Minecraft 游戏开发：它管理渲染流程、运行并调试测试用例、在失败时记录日志，并不断迭代代码直到全部测试通过。对于前/后归一化分析，Kimi K2 可使用 Weights & Biases（wandb）数据读取器提取语言模型实验的洞见，并生成一份精致的分析报告。在将一个 Flask 项目迁移至 Rust 时，Kimi K2 会系统地重构整个代码库并运行性能基准测试，以确保性能稳健。
+
+## 5 Kimi K2 基准测试表现
+
+### Kimi-K2-Instruct
+
+下表展示 Kimi-K2-Instruct 的性能表现，显示该模型在众多任务中与最新的开源或闭源模型相当，甚至超越它们。该模型在知识密集型和推理类基准上表现尤为出色，在自然语言理解、数学科学、代码生成与智能体工具使用等方面均有卓越成绩。
+
+- 上述评估的所有模型均为“非思维模型”
+- 表中加粗表示全球 SOTA，带下划线表示开源 SOTA
+- 带 * 的数据来自模型的技术报告或官方博客
+- 除 SWE-bench Verified（非智能体模式）外，所有评测均在 8k 输出 token 长度下进行。SWE-bench Verified（非智能体模式）限制为 16k 输出长度
+- Kimi K2 在使用 bash/editor 工具、单次尝试且不进行测试时，在 SWE-bench Verified 测试中达到了 65.8% 的 pass@1。同时，在 SWE-bench Multilingual 测试中也达到了 47.3% 的 pass@1。此外，我们还报告了另一组 SWE-bench Verified 的结果（71.6%），该测试使用了并行测试时计算：通过对多个样本序列打分并选择最优结果来生成最终提交
+- 为了确保评估稳定性，我们在 AIME、HMMT、CNMO、PolyMath-en、GPQA-Diamond、EvalPlus 和 Tau2 上使用 avg@k 方式评估
+- 部分数据因评估成本过高而未列出。
+
+Kimi-K2-Base
+
+下表总结了 Kimi-K2-Base 模型的表现，显示它在多个任务上可与当前最强的开源预训练模型相媲美，甚至超越。Kimi-K2-Base 在知识密集与推理类基准任务上表现尤为突出，在自然语言理解、数学和代码生成方面尤为擅长。
+
+- 本评测仅涵盖开源预训练模型。我们报告了 Qwen2.5-72B 的结果，因为在评测时 Qwen3-235B-A22B 的基础 checkpoint 尚未开源
+- 所有模型均使用统一的评估协议进行评测
+
+详细表格略，原文查
+
+## 6 开放的智能体智能
+
+预训练是代理智能 (Agentic Intelligence) 的关键基础，它建立先验知识，使强化学习 (RL) 的探索变得易于处理、高效且具有泛化能力。然而，正如 Ilya Sutskever 所观察到的，人类数据是一种有限的“化石燃料”，其增长速度远远落后于计算速度。这使得预训练过程中的代币效率成为 AI 缩放定律中一个新的关键系数。
+
+在“体验时代”（David Silver，Richard Sutton，2025）中，后训练至关重要。在这个时代，法学硕士越来越多地从自身产生的互动中学习，获得回报，使他们摆脱人类数据的限制，并超越人类的能力。
+
+Kimi K2 正是基于这些见解而打造的。
+
+### MuonClip 优化器
+
+在没有严格性的情况下，给定一个近似有限的预训练数据集和一个固定的模型配置，一个更高效的令牌优化器可以产生更高的智能。我们之前的研究“Moonlight”已经证明，在 LLM 训练中，Muon 优化器的性能显著优于广泛使用的 AdamW 优化器。
+
+Kimi K2 的设计旨在进一步扩展 Moonlight，其架构与 DeepSeek-V3 类似。基于缩放律分析，我们减少了 head 的数量以提高长上下文效率，并增加了 MoE 稀疏性以提高 token 效率。在扩展过程中，我们遇到了一个持续存在的挑战：注意力 logit 爆炸导致的训练不稳定性。在我们的实验中，这个问题在 Muon 中更常见，但在 AdamW 中较少出现。现有的解决方案（例如 logit 软上限和查询键规范化）被发现不够完善。
+
+为了解决这个问题，我们引入了 MuonClip 优化器，该优化器基于我们提出的 qk-clip 技术对 Muon 进行了改进。具体来说，qk-clip 通过在 Muon 更新后直接重新缩放查询和键投影的权重矩阵来稳定训练，从而控制源头注意力逻辑的规模。具体而言，查询和键投影的缩放比例如下：
+
+
+
+其中 *α* 是平衡超参数，因此注意力逻辑变为：
+
+
+
+每一步之后都会根据此步骤中的最大注意力逻辑设置自适应因子 *η* （阈值为 *t* ）：
+
+
+
+其中 *t* 是预设阈值。这是一种通用技术，可能适用于其他稳定性用例。
+
+我们的实验表明，MuonClip 能够有效防止逻辑爆炸，同时保持下游任务的性能。在实践中，Kimi K2 使用 MuonClip 在 15.5T 的 token 上进行了预训练，训练峰值为零，证明了 MuonClip 是稳定、大规模 LLM 训练的强大解决方案。
+
+
+
+## 7 智能体能力
+
+### 大规模代理数据合成
+
+Kimi K2 的增强代理能力源于两个重要方面——大规模代理数据合成和通用强化学习。
+
+用于工具使用学习的大规模代理数据合成：为了教会模型复杂的工具使用能力，我们受 ACEBench 启发，开发了一个全面的流程，可以大规模模拟现实世界的工具使用场景。我们的方法系统地演化了数百个包含数千种工具（包括真实的 MCP（模型上下文协议）工具和合成工具）的领域，并生成了数百个拥有不同工具集的代理。
+
+所有任务均基于评分标准，从而实现一致的评估。代理与模拟环境和用户代理交互，创建逼真的多轮工具使用场景。LLM 评委根据任务评分标准评估模拟结果，筛选出高质量的训练数据。这种可扩展的流程能够生成多样化、高质量的数据，为大规模拒绝采样和强化学习奠定基础。
+
+
+
+### 通用强化学习
+
+通用强化学习：关键挑战在于将强化学习应用于具有可验证和不可验证奖励的任务；可验证任务的典型示例是数学和编程竞赛，而撰写研究报告通常被视为不可验证的任务。除了可验证奖励之外，我们的通用强化学习系统还采用自我判断机制，让模型充当自身的“批评家”，为不可验证任务提供可扩展的、基于评分标准的反馈。
+
+同时，使用可验证奖励的在线策略 rollout 来持续更新评论家，使评论家不断提高其在最新策略上的评估准确性。这可以被视为一种利用可验证奖励来改进不可验证奖励估计的方法。
+
+## 8 使用 Kimi K2
+
+### 在线体验
+
+访问 [kimi.com](https://www.kimi.com/)，从今天开始，Kimi 的网页版和移动版用户均可免费选择并使用全新的 Kimi K2 模型。目前，我们网页版和 App 版的 MCP 功能仍在开发中。我们希望在未来几周内推出这些功能。在此期间，欢迎您试用我们的 Researcher，抢先体验其代理功能。请注意，Kimi K2 尚不支持视觉功能。
+
+### API 接入
+
+Kimi 平台提供与 OpenAI/Anthropic 兼容的接口，方便您轻松将现有应用程序适配至 Kimi K2。我们鼓励开发者探索我们的工具调用 API，以构建代理应用程序。更多信息，请访问 platform.moonshot.ai。：[platform.moonshot.ai](https://platform.moonshot.ai/)
+
+### 本地部署
+
+建议以下推理引擎运行 Kimi K2：vLLM、SGLang、KTransformers 或 TensorRT-LLM。
+
+详细部署说明[GitHub 仓库](https://github.com/MoonshotAI/Kimi-K2?tab=readme-ov-file#4-deployment)
+
+## 9 后续
+
+Kimi K2 为开放式智能代理奠定了坚实的基础，而通用智能代理则拥有更高级的功能，例如思考和视觉理解，未来添加到 Kimi K2。
+
+## 10 限制
+
+内测发现K2处理复杂推理任务或工具定义不明确时，模型可能生成过多token，导致输出被截断或工具调用不完整。若启用工具，某些任务性能可能下降。
+
+构建完整软件项目时，与在代理框架下使用 K2 相比，一次性提示会导致性能下降。
\ No newline at end of file
diff --git a/docs/md/AI/llm/claude-4-5-sonnet.md b/docs/md/AI/llm/claude-4-5-sonnet.md
new file mode 100644
index 0000000000..e261744627
--- /dev/null
+++ b/docs/md/AI/llm/claude-4-5-sonnet.md
@@ -0,0 +1,180 @@
+# Claude Sonnet 4.5 携 Agent SDK 亮相，重塑开发工作流！
+
+混合推理模型，为智能体带来更强大智能，支持 200K 上下文窗口
+
+[试用 Claude](https://claude.ai/redirect/website.v1.771b1b58-f425-4a97-8a54-47e2c373bf96) | [获取 API 访问权限](https://console.anthropic.com/)
+
+## 1 介绍 Claude Sonnet 4.5
+
+Claude Sonnet 4.5 是目前全球最强的编程模型。它在构建复杂智能体方面表现最出色，是最擅长使用电脑的模型，在逻辑推理和数学能力上也有显著提升。
+
+代码无处不在，它驱动着你使用的每一个应用、表格和软件工具。而能熟练使用这些工具并解决复杂问题，正是现代工作的核心。
+
+Claude Sonnet 4.5 让这一切成为可能。此次发布还伴随了一系列重要的产品升级。在 [Claude Code](https://anthropic.com/news/enabling-claude-code-to-work-more-autonomously) 中，我们加入了备受用户期待的“检查点”功能，可随时保存进度，并一键回到先前状态。我们还重新设计了终端界面，并发布了 [VS Code 原生扩展](https://marketplace.visualstudio.com/items?itemName=anthropic.claude-code)。在 Claude API 中，我们增加了新的 [上下文编辑和记忆功能](https://anthropic.com/news/context-management)，让智能体可以运行更长时间、处理更复杂的任务。在 Claude [应用](https://claude.ai/redirect/website.v1.6e3b59f5-bfac-4640-a43b-b82b5d1ba4ff/download)中，我们把代码执行和 [文件创建功能](https://www.anthropic.com/news/create-files)（支持表格、幻灯片、文档）直接整合进对话界面。此外， [Claude for Chrome](https://www.anthropic.com/news/claude-for-chrome) 浏览器扩展也已向上月加入候补名单的 Max 用户开放。
+
+我们还向开发者开放了自用的 Claude Code 构建模块，命名为 [Claude Agent SDK](https://anthropic.com/engineering/building-agents-with-the-claude-agent-sdk)。驱动我们前沿产品的底层基础设施，现在也向你开放，用来构建属于你的智能系统。
+
+这是我们迄今最符合安全对齐标准的前沿模型，与之前的 Claude 系列相比，在多个方面都有大幅改进。
+
+Claude Sonnet 4.5 现已全球上线。开发者可通过 [Claude API](https://docs.claude.com/en/docs/about-claude/models/overview) 使用 `claude-sonnet-4-5` 模型。价格与 Claude Sonnet 4 相同，仍为每百万 tokens 收费 $3/$15。
+
+## 2 前沿智能
+
+Claude Sonnet 4.5 在 SWE-bench Verified 测试中表现最为突出，该测试用于评估 AI 在实际编程任务中的能力。实际使用中，我们观察到它在复杂的多步骤任务中能持续专注运行超过 30 小时。
+
+
+
+在 OSWorld 测试（评估模型执行真实电脑任务的能力）中，Sonnet 4.5 的得分达到 61.4%，领先所有同类模型。仅四个月前，Sonnet 4 还以 42.2% 居首。我们的 [Claude for Chrome](https://www.anthropic.com/news/claude-for-chrome) 扩展正充分利用这些增强能力。演示中，Claude 能直接在浏览器中操作网站、编辑表格并完成任务。
+
+
+
+模型在逻辑推理和数学等多个领域的评测中也有明显进步：
+
+
+
+金融、法律、医学和理工科等领域的专家发现，Sonnet 4.5 在专业知识和推理能力上相比旧版本（包括 Opus 4.1)有显著提升。
+
+
+
+
+
+
+
+
+
+## 3 我们最“对齐”的模型
+
+除了性能更强，Claude Sonnet 4.5 也是我们迄今最符合安全标准的前沿模型。得益于更强的能力和更深入的安全训练，我们显著减少了模型的不良行为，比如迎合性、欺骗性、权力追求，以及鼓励幻想性思维等倾向。同时，我们在防御提示注入攻击方面也取得重大进展，这对使用智能体和电脑操作功能的用户尤为重要。
+
+
+
+详细的安全和对齐评测（包括首次采用可解释性技术的分析）可在 Claude Sonnet 4.5 的 [系统卡](https://www.anthropic.com/claude-sonnet-4-5-system-card) 中查看。
+
+Claude Sonnet 4.5 以我们定义的 AI 安全等级 3（ASL-3）标准发布，配套 [负责任扩展框架](https://www.anthropic.com/news/announcing-our-updated-responsible-scaling-policy)。其中包括一系列安全分类器，用于检测潜在危险内容，尤其是与化学、生物、放射和核（CBRN）武器相关的信息。
+ 这些分类器可能偶尔误判正常内容，因此我们允许用户在必要时切换至风险较低的 Sonnet 4 模型继续对话。自 [首次发布](https://www.anthropic.com/news/constitutional-classifiers) 以来，我们已将误判率降低十倍，相比 Opus 4 又进一步减半。
+
+
+
+## 4 Claude Agent SDK
+
+经过六个月的持续改进，我们深知构建 AI 智能体需要解决哪些难题：如何让智能体在长时间任务中管理记忆、如何平衡自主性与用户控制、如何协调多个子智能体协同工作。
+
+
+
+现在，这些成果都已向开发者开放。[Claude Agent SDK](https://anthropic.com/engineering/building-agents-with-the-claude-agent-sdk) 与 Claude Code 使用相同的底层架构，但不仅限于编程任务，对多种应用场景都能带来显著收益。你可以用它构建属于自己的 AI 智能体。
+
+我们最初开发 Claude Code，是因为市面上没有理想的工具。现在，Agent SDK 为你提供同样的基础，让你能打造出同样强大的解决方案。
+
+## 5 研究预览：Imagine with Claude
+
+我们还发布了一个名为 “[Imagine with Claude](https://claude.ai/redirect/website.v1.6e3b59f5-bfac-4640-a43b-b82b5d1ba4ff/imagine)” 的限时研究预览。
+
+
+
+在这个实验中，Claude 可以实时生成软件，不依赖任何预设代码或功能。你能直接看到 Claude 即时响应、动态创造的全过程。
+
+这是一个有趣的展示，体现了 Claude Sonnet 4.5 的潜力——当强大的模型遇上合适的基础设施，会产生怎样的创新可能。
+
+“Imagine with Claude” 将为 Max 用户开放五天，你可以在 [claude.ai/imagine](https://claude.ai/redirect/website.v1.6e3b59f5-bfac-4640-a43b-b82b5d1ba4ff/imagine) 体验。
+
+## 6 更多信息
+
+我们建议所有用户升级至 Claude Sonnet 4.5。无论你通过应用、API 还是 Claude Code 使用 Claude，Sonnet 4.5 都可无缝替换原版本，并在相同价格下带来更好的性能。
+
+Claude Code 更新已向所有用户开放，[Claude Developer Platform](https://claude.com/platform/api) 及 Claude Agent SDK 也已向所有开发者提供。代码执行与文件创建功能对所有付费计划用户开放。
+
+完整的技术细节和评测结果可查看 [系统卡](https://www.anthropic.com/claude-sonnet-4-5-system-card)、[模型页面](https://www.anthropic.com/claude/sonnet) 和 [官方文档](https://docs.claude.com/en/docs/about-claude/models/overview)。
+ 你也可以浏览我们的 [工程博文](https://www.anthropic.com/engineering/building-agents-with-the-claude-agent-sdk)、[AI 智能体上下文管理文章](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)，以及关于 [网络安全研究](https://red.anthropic.com/2025/ai-for-cyber-defenders) 的报告。
+
+#### 说明
+
+*注1：从事网络安全或生物研究的客户可联系客户经理申请加入白名单。*
+
+**方法说明**
+
+- **SWE-bench Verified**：Claude 使用包含 bash 和文件编辑工具的基础环境，Sonnet 4.5 得分为 77.2%，在 500 个问题的完整数据集上平均 10 次运行。
+- **OSWorld**：使用官方框架测试，最高 100 步，平均 4 次运行。
+- **AIME**、**MMMLU**、**Finance Agent** 等评测的详细方法和结果均列于系统卡中。
+- **Claude Sonnet 4.5** 在各项指标中均领先同类模型。
+
+**发布日期：2025 年 9 月 29 日**
+
+Sonnet 4.5 是目前全球在智能体、编程及计算机使用领域表现最出色的模型。在长时间任务中表现最为精准和细致，具备更强的专业知识覆盖，包括编程、金融与网络安全等领域。
+
+- **Claude Sonnet 4**
+
+ Sonnet 4 在多个方面相较 Sonnet 3.7 都有显著提升，尤其是在编程能力上。
+ 它为各种 AI 应用场景提供了强劲的性能支持，无论是面向用户的智能助理还是大规模任务处理。
+
+ [了解更多]
+
+- **Claude Sonnet 3.7 与 Claude Code**
+
+ **发布日期：2025 年 2 月 24 日**
+
+ Sonnet 3.7 是首个混合推理模型，也是迄今为止智能水平最高的版本。
+ 它在编程、内容生成、数据分析和规划等方面都达到了行业领先水平。
+
+## 7 可用性与定价
+
+任何人都可以在 Claude.ai 的网页端、iOS 或 Android 应用中使用 Sonnet 4.5 进行对话。
+
+对于希望构建智能体的开发者，Sonnet 4.5 可在 Claude Developer Platform 上直接使用，也支持接入 Amazon Bedrock 与 Google Cloud 的 Vertex AI。
+
+Sonnet 4.5 还可与行业领先的编程智能体 Claude Code 配合，处理复杂的编程任务。
+
+Sonnet 4.5 的价格为每百万输入 Token 3 美元、每百万输出 Token 15 美元。
+
+通过 [Prompt 缓存](https://docs.claude.com/en/docs/build-with-claude/prompt-caching) 可节省最高 90% 成本，通过 [批处理](https://docs.claude.com/en/docs/build-with-claude/message-batches#pricing) 可节省 50% 成本。
+更多详情请访问 [定价页](https://claude.com/pricing#api)。
+
+## 8 应用场景
+
+Sonnet 4.5 是目前最强的智能体模型，同时也是全球在编程和计算机操作方面表现最佳的 AI 模型。
+
+它可以快速给出即时响应，也能进行可视化的逐步思考。API 用户还可精细控制模型的“思考时长”。常见应用包括：
+
+### **长期运行的智能体**
+
+Sonnet 4.5 在指令理解、工具选择、错误修复和复杂推理方面表现卓越，非常适合客户服务型智能体和复杂 AI 工作流。
+
+### **代码生成**
+
+Sonnet 4.5 是构建自主编程智能体的理想选择，能够覆盖软件开发全流程：
+ 从初始规划、调试修复、维护升级到大型重构。
+ 它在规划与解决复杂编程任务方面都具有出色表现，可支持端到端的软件开发。
+ 同时，Sonnet 4.5 支持高达 64K 的输出 Token，非常适合生成和规划大规模代码。
+
+### **浏览器与计算机操作**
+
+Sonnet 4.5 在计算机操作能力上居于领先地位，能够可靠地完成浏览器相关任务，例如竞品分析、采购流程、客户入职等。
+ Sonnet 3.5 是首个能够自主使用计算机的前沿模型，而 Sonnet 4.5 在这一能力上更精准、更稳定，并且会持续优化。
+
+### **网络安全**
+
+结合 Claude Code，使用 Sonnet 4.5 的团队可以部署能够自主修补漏洞的智能体，
+ 从被动检测转向主动防御。
+
+### **金融分析**
+
+Sonnet 4.5 可处理从基础财务分析到高级预测分析的各种任务。
+ 例如，它能持续监控全球监管变动，并主动调整合规系统，
+ 从传统的人工审计准备迈向智能化风险管理。
+
+### **商务任务**
+
+Sonnet 4.5 擅长生成和编辑办公文件，如演示文稿、文档和表格。
+
+### **科研研究**
+
+Sonnet 4.5 能在外部与内部数据源中进行搜索与整合，生成对复杂信息的系统洞察。
+
+### **内容生成与分析**
+
+Sonnet 4.5 在写作和内容分析上表现出色，能够理解语气与细微差别，创作更具吸引力的内容并进行深度分析。
+
+## 9 基准测试
+
+Sonnet 4.5 是迄今为止最强的编程模型，在 SWE-bench Verified 测试中取得了 **77.2%** 的成绩。在计算机操作测试 OSWorld 中也达到了 **61.4%**，刷新了业界记录。
+
+Sonnet 4.5 同样在金融分析、网络安全与科研领域展现出卓越实力，能协调多个智能体并高效处理大量数据，满足高可靠性应用的需求。
\ No newline at end of file
diff --git a/docs/md/AI/llm/cuda.md b/docs/md/AI/llm/cuda.md
new file mode 100644
index 0000000000..735f4355e0
--- /dev/null
+++ b/docs/md/AI/llm/cuda.md
@@ -0,0 +1,230 @@
+# 空有A100却在“吃灰”？给Javaer的三种CUDA“遥控器”，榨干GPU性能
+
+## 0 前言
+
+有自己的智算中心和这么多A100“大杀器”，了解CUDA不是“要不要”，而是“必须”的问题了。不把GPU潜力榨干，那可真是太浪费了。
+
+作为Java架构师，无需像C++程序员手写底层CUDA C++代码，但须理解核心思想和工作原理。才能在架构层正确决策，判断：
+
+- 哪些业务场景适合交给GPU加速
+- 咋将Java应用与底层CUDA能力连接
+
+这就像不一定手写汇编，但懂些CPU工作原理，能写更高性能Java代码。
+
+## 1 CUDA是啥？从JVM说起
+
+先定调：对Java架构师，可把CUDA看作专属于NVIDIA GPU的“JVM + JIT编译器”。
+
+ * **JVM是什么？** 一个标准的运行时，能让Java字节码（`.class`文件）在不同的操作系统和CPU上运行
+ * **CUDA是什么？** 一个标准的运行时和API集合，能让你写的“GPU代码”（通常是C++写的`.cu`文件）在NVIDIA的GPU硬件运行
+
+再进一步：
+
+ * **JIT（Just-In-Time）编译器**：JVM精髓之一。运行时把热点的Java字节码动态编译成本地机器码，充分压榨CPU性能
+ * **NVCC（NVIDIA C Compiler）**：CUDA的“编译器”。会把`.cu`文件（一种混合C++和CUDA特殊指令的源文件）编译成能在GPU上高效执行的机器码（PTX或SASS）
+
+所以，谈论CUDA时，谈论的是一个完整生态系统：
+
+ * **一个编程模型**：告诉你咋写并行代码
+ * **一套API和库**：给你提供现成工具调用GPU
+ * **一个驱动和运行时**：负责在硬件上实际执行你的代码
+
+一句话总结：CUDA是连接上层应用软件和底层NVIDIA GPU硬件的“驱动+标准接口+运行时”，是释放GPU强大并行计算能力的钥匙。
+
+## 2 CUDA“世界观”：为啥它能那么快？
+
+CPU和GPU设计哲学完全不同：
+
+ * **CPU（中央处理器）**：全能的单兵王者。核心（Core）数不多（如16、32核），但每个核心都极其强大和复杂。巨大缓存、复杂分支预测和指令流水线，擅长处理**复杂的、带有大量逻辑判断和串行依赖的任务**。就像几个经验丰富项目经理，能处理各种疑难杂症
+
+ * **GPU（图形处理器）**：纪律严明的万人军团。核心数量庞大（一张A100有6912个CUDA核心！），但每个核心很简单，功能有限。不擅长复杂逻辑判断，但极其擅长**对海量数据执行同一个简单的计算任务**。就像上万个士兵，每人只会“前进、刺击”简单动作，但上万人一起做，形成冲击力毁灭性。
+
+CUDA编程模型的核心就是**咋组织和指挥这个“万人军团”**。它引入了几个核心概念：
+
+ * **Kernel（内核）**：你希望GPU执行的那个“简单任务”的定义。可以把它想象成你写的一个Java `Runnable` 接口的 `run()` 方法。这个方法里的代码，将会被成千上万个线程去执行
+
+ * **Thread（线程）**：GPU执行`Kernel`的最小单元。相当于一个Java的`Thread`实例
+
+ * **Block（块）**：一组GPU线程，形成一个“班”或“排”。同一个Block里的线程可以非常高效地进行通信和数据同步（通过一块共享内存`Shared Memory`）。这有点像一个`ExecutorService`线程池里的线程，它们可协同工作
+
+ * **Grid（网格）**：一组Block，形成一个“师”或“军”。这是你向GPU提交的一个完整的计算任务
+
+所以，一个典型CUDA任务流程：
+
+1. **定义任务**：用CUDA C++写一个`Kernel`函数，比如“给这个数组的每个元素都乘以2”
+2. **组织军团**：确定你要启动多少个线程（Grid和Block的维度），比如“启动1024个Block，每个Block包含256个线程，总共262,144个线程大军”
+3. **数据传输**：把需要处理的数据从CPU的内存（我们Java应用的堆内存）拷贝到GPU的显存（VRAM）中。**这是关键瓶颈之一！**
+4. **执行命令**：在GPU上启动`Kernel`，让成千上万个核心同时开始计算
+5. **回收结果**：等GPU计算完成后，再把结果从GPU显存拷贝回CPU内存
+
+**架构师的启示**：一个任务是否适合用GPU加速，关键看：
+
+1. **计算密集型**：任务本身需要大量的数学运算，而不是复杂的业务逻辑
+2. **高度并行性**：任务可以被拆解成成千上万个完全独立的子任务。比如矩阵乘法、图像滤镜、大规模数据转换等。如果任务前后依赖严重，比如`for`循环里下一步的计算依赖上一步的结果，那就不适合GPU
+
+## 3 Javaer咋“遥控”CUDA？
+
+我们的主战场。
+
+知道CUDA原理，但我们是Java架构师，总不能去写C++吧？当然不用！有几种“遥控”方式，从“硬核”到“优雅”：
+
+### 3.1 JNI
+
+Java Native Interface，硬核但灵活。最原始、最底层方式：
+
+#### 原理
+
+Java通过JNI规范，可以调用C/C++写的动态链接库（`.dll`或`.so`文件）。我们可以让C++团队把所有CUDA相关的复杂操作（内存管理、核函数启动等）封装成一个简单的C函数，并编译成`.so`文件。Java应用在需要时，通过JNI加载这个库，并调用那个C函数。
+
+#### 优点
+
+性能最好，灵活性最高。你可以100%控制所有CUDA的细节。
+
+#### 缺点
+
+极其复杂！需要一个精通CUDA C++和JNI的团队。JNI的开发、调试、部署都非常痛苦，内存管理容易出错导致JVM崩溃。这就像你为了开个车，先自己从零件开始造发动机。
+
+#### 适用场景
+
+对性能要求达到极致，且有专门的C++/CUDA团队支持的超大型项目。
+
+### 3.2 JCuda / JCublas等第三方库 - “JDBC”模式
+
+这是目前比较主流和现实的方式。
+
+#### 原理
+
+像JCuda这样的库，已经帮你把CUDA Driver API和Runtime API用JNI封装好了，并提供了易于使用的Java接口。你不需要写一行C++代码，就可以在Java里直接调用CUDA的函数。
+
+#### 类比
+
+这完美对标我们JavaEE里的**JDBC**。我们写Java时，不会直接去跟Oracle或MySQL的底层通信协议打交道，而是使用标准的JDBC接口。JCuda就是CUDA的“JDBC驱动”。
+
+#### 示例（伪代码）
+
+```java
+// 1. 初始化CUDA环境
+JCuda.cudaInit();
+
+// 2. 分配GPU显存
+Pointer deviceInput = new Pointer();
+JCuda.cudaMalloc(deviceInput, dataSize);
+
+// 3. 从Java堆内存拷贝数据到GPU显存
+JCuda.cudaMemcpy(deviceInput, hostInput, dataSize, cudaMemcpyHostToDevice);
+
+// 4. 配置并启动Kernel（Kernel通常是预先编译好的.ptx文件）
+// ... 配置Grid和Block维度
+// ... 加载.ptx文件中的Kernel函数
+// ... 调用cuLaunchKernel
+
+// 5. 从GPU显存拷回结果到Java堆内存
+JCuda.cudaMemcpy(hostOutput, deviceOutput, dataSize, cudaMemcpyDeviceToHost);
+
+// 6. 释放资源
+JCuda.cudaFree(deviceInput);
+```
+
+#### 优点
+
+大大降低了使用门槛，纯Java开发，生态相对成熟。
+
+#### 缺点
+
+仍然需要手动管理GPU显存、数据拷贝，对CUDA的运行时模型要有比较清晰的理解。API比较啰嗦，更像是过程式的C API的Java映射。
+
+#### 适用场景
+
+绝大多数需要在Java应用中集成自定义CUDA加速的场景。你们有智算中心，想在现有的Java微服务或大数据处理任务中，把某个计算瓶颈 offload 到A100上，这通常是首选。
+
+### 3.3 TornadoVM / Aparapi等 - “JIT”终极模式
+
+这是最前沿、最优雅，也最具野心的方式。
+
+#### 原理
+
+TornadoVM是一个特殊的OpenJDK插件。它的目标是让你**像写普通的Java并行流（Parallel Stream）一样写代码，然后它自动帮你把代码JIT编译成CUDA/OpenCL代码，并 offload 到GPU上执行！**
+
+#### 类比
+
+这才是真正的“GPU上的JIT”。你甚至都不用关心GPU的存在，TornadoVM会自动分析你的Java字节码，判断是否可以并行化，然后动态生成GPU代码并执行。
+
+#### 示例（伪代码）
+
+```java
+// 你只需要在你的方法上加一个注解
+public static void matrixMultiplication(float[] a, float[] b, float[] c, final int N) {
+ // TornadoVM会把这个@Parallel注解的循环自动编译成CUDA Kernel
+ @Parallel for (int i = 0; i < N; i++) {
+ for (int j = 0; j < N; j++) {
+ float sum = 0.0f;
+ for (int k = 0; k < N; k++) {
+ sum += a[i * N + k] * b[k * N + j];
+ }
+ c[i * N + j] = sum;
+ }
+ }
+}
+
+// 在主程序中，用TornadoVM的TaskSchedule来运行
+TaskSchedule s0 = new TaskSchedule("s0")
+ .task("t0", YourClass::matrixMultiplication, matrixA, matrixB, matrixC, N)
+ .streamOut(matrixC);
+s0.execute();
+```
+
+#### 优点
+
+对Java程序员的透明度极高！** 几乎没有学习成本，可以用纯粹的Java思维来利用GPU。这可能是未来的终极方向。
+
+#### 缺点
+
+还比较新，生态和社区不如JCuda成熟。自动编译的性能可能不如C++专家手写的Kernel。对代码写法有一定要求（不能太复杂）。
+
+#### 适用场景
+
+希望快速将现有Java计算密集型代码（如科学计算、金融风控模型）迁移到GPU上进行验证和加速。新项目技术选型，可以重点关注。
+
+## 4 实践：A100该咋用？
+
+有自己的智算中心和A100，可从以下几个层面思考：
+
+### 4.1 识别瓶颈，建立“GPU加速候选池”
+
+#### 离线大数据处理
+
+Spark/Flink任务中，有开销巨大的`map`或`filter`操作？如对海量图片预处理、对金融交易数据特征提取，都是绝佳候选。可用JCuda或TornadoVM写一个UDF（User-Defined Function），让这个UDF内部调用GPU来计算。
+
+#### 在线微服务
+
+有没有哪个服务的RT（响应时间）因为某个复杂的计算而居高不下？如风控服务的实时风险评分、推荐系统的实时向量相似度计算、图像服务的AI审查。可以考虑将这个服务改造为“CPU+GPU”的混合服务。轻量级请求走CPU，计算密集型请求异步 offload 到GPU。
+
+#### 模型推理
+
+像TensorRT-LLM底层就是CUDA C++写的，它已将A100的Tensor Core（A100的“特种兵”，专精矩阵运算）用到极致。Java应用只需要通过REST/gRPC调用这些推理服务。
+
+### 4.2 构建GPU资源管理与调度层
+
+ * 既是智算中心，就不能让每个Java应用像“野孩子”一样直连GPU。需一个中间层
+ * 可基于k8s的Device Plugin机制，对GPU资源进行池化和调度
+ * 开发一套“GPU任务提交网关”，Java应用通过这个网关提交计算任务，网关负责排队、调度到空闲的A100卡上，并返回结果。这使得GPU对上层业务透明，成为一种可被计量的“计算资源”
+
+### 4.3 技术选型与团队赋能
+
+#### 短期见效
+
+对已有Java应用，选择**JCuda**方案，对最痛的计算瓶颈进行“手术刀”式的改造。
+
+#### 长期投资
+
+励团队研究**TornadoVM**，探索“无感”使用GPU的可能性，降低未来业务的开发成本。
+
+#### 专业分工
+
+如可能，培养或引入1-2名精通CUDA C++的工程师，作为你们的“核武器”，负责攻克最艰难的性能优化问题，并为上层Java应用提供封装好的高性能计算库。
+
+## 5 总结
+
+CUDA对Javaer，不是一门需精通的编程语言，而是须了解的异构计算平台。理解其工作原理和与Java的集成方式，就能打开新大门，将那些过去在CPU上跑得气喘吁吁的任务，扔给A100这个“万人军团”去瞬间完成。
+
+这不仅能带来几十甚至上百倍的性能提升，更是未来AI时代架构设计中不可或缺的一环。
\ No newline at end of file
diff --git a/docs/md/AI/llm/gpullama3-java-gpu-llm.md b/docs/md/AI/llm/gpullama3-java-gpu-llm.md
new file mode 100644
index 0000000000..313bd3e3ae
--- /dev/null
+++ b/docs/md/AI/llm/gpullama3-java-gpu-llm.md
@@ -0,0 +1,70 @@
+# 告别 CUDA！GPULlama3.java 横空出世，Java 首次实现原生 GPU 跑大模型
+
+## 0 前言
+
+曼彻斯特大学 [Beehive Lab](https://github.com/beehive-lab) 发布 [GPULlama3.java](https://github.com/beehive-lab/GPULlama3.java)，这是首个支持 GPU 自动加速的 Java 原生 [Llama3](https://www.llama.com/models/llama-3/) 实现。该项目基于 [TornadoVM](https://github.com/beehive-lab/TornadoVM)，让开发者无需编写 CUDA 或原生代码，即可在 Java 中实现LLM的 GPU 推理。这有望彻底改变 Javaer 在企业环境中构建 AI 应用的方式。
+
+## 1 GPULlama3.java 的核心
+
+TornadoVM —— 一款创新的异构编程框架，它扩展了 OpenJDK 和 GraalVM，使 Java 程序能自动在 GPU、FPGA 以及多核 CPU 加速运行。与传统 GPU 编程方式不同，TornadoVM 无需手动重写 CUDA 或 OpenCL 代码，开发者可完全用 Java 编写逻辑，TornadoVM 负责底层加速。
+
+根据 [TornadoVM 官方文档](https://tornadovm.readthedocs.io/en/latest/introduction.html) 的介绍，该系统通过扩展 Graal JIT 编译器，添加专用后端，在运行时将 Java 字节码转换为 GPU 可执行代码。只需用 `@Parallel` 注解标记方法，TornadoVM 就能将普通 Java 字节码转换为 Graal 中间表示（IR），应用 GPU 优化策略，并生成目标平台代码，如 OpenCL C（跨平台）、PTX（NVIDIA）或 SPIR-V（二进制格式，支持 Intel 显卡）。
+
+```java
+// 来自 TornadoVM 文档的 TaskGraph 示例
+TaskGraph taskGraph = new TaskGraph("computation")
+ .transferToDevice(DataTransferMode.FIRST_EXECUTION, data)
+ .task("process", MyClass::compute, input, output)
+ .transferToHost(DataTransferMode.EVERY_EXECUTION, output);
+
+TornadoExecutionPlan executor = new TornadoExecutionPlan(taskGraph.snapshot());
+executor.execute();
+```
+
+根据 [TornadoVM 编程指南](https://tornadovm.readthedocs.io/en/latest/programming.html)，开发者可用与硬件无关的 API，在不同硬件平台上运行相同的 Java 代码。TornadoVM 运行时会自动处理所有设备相关的优化、内存管理和数据传输。
+
+## 2 支持后端
+
+GPULlama3.java 支持三种主要后端，可运行在多种硬件：
+
+- **NVIDIA 显卡**：支持 OpenCL 和 PTX 两种后端
+- **Intel 显卡**：包括 Arc 独显和集成的 HD Graphics，支持 OpenCL
+- **Apple Silicon**：M1/M2/M3 可通过 OpenCL 运行（但由于 Apple 已弃用 OpenCL，未来将转向 Metal）
+
+项目运行时可通过命令行参数配置：
+
+```bash
+# 使用 GPU 加速运行（项目 README 示例）
+./llama-tornado --gpu --verbose-init --opencl --model beehive-llama-3.2-1b-instruct-fp16.gguf --prompt "Explain the benefits of GPU acceleration."
+```
+
+该项目依赖 Java 的现代功能，具体包括：
+
+- 要求 **Java 21 及以上版本**，以使用 Vector API 和 Foreign Memory API
+- 支持 **GGUF 模型格式**，方便模型打包与部署
+- 支持 **量化格式**（Q4_0 和 Q8_0），以降低内存占用
+
+GPULlama3.java 基于 [Alfonso Peterssen 的原始 LLama3.java 实现](https://github.com/mukel/llama3.java) 开发，并在此基础引入 TornadoVM GPU 加速功能。正如 [Peterssen 在 Devoxx 2024 大会](https://youtu.be/zgAMxC7lzkc?si=pPqZzeu81ESWjUdx) 展示，他的工作首次实现无需原生依赖即可运行 Llama 模型。TornadoVM 团队进一步将其适配为异构加速架构。
+
+## 3 Java LLM 项目
+
+GPULlama3.java 的发布也使其成为 Java LLM 项目的一员，其他相关项目还包括：
+
+- [JLama](https://github.com/tjake/Jlama)：一个现代 Java LLM 推理引擎，支持分布式部署
+- [Llama3.java](https://github.com/mukel/llama3.java)：专注 CPU 优化的纯 Java 实现
+
+正如 [Quarkus 官方博客关于 Java LLM 的文章](https://quarkus.io/blog/quarkus-jlama/) 所指出的，Java 生态系统正不断拓展其 AI/机器学习能力，使开发者能够无需离开 Java 平台就能构建 LLM 驱动的应用程序。
+
+[TornadoVM](https://www.infoq.com/articles/tornadovm-java-gpu-fpga/) 起源于曼彻斯特大学的研究项目，自 2013 年以来持续发展，目标是让 Java 开发者更容易使用异构计算。该框架目前仍在不断增加后端支持并进行性能优化。
+
+## 4 当前进度
+
+GPULlama3.java 目前处于测试阶段，团队正在持续优化性能并收集基准测试数据。由于 Apple 弃用 OpenCL，当前在 Apple Silicon 上的性能不佳，TornadoVM 团队正在开发 Metal 后端，以提升兼容性并优化 Transformer 操作。
+
+
+
+## 5 总结
+
+总的来说，GPULlama3.java 的发布标志着 Java 生态在 GPU 加速 LLM 推理方面迈出了重要一步。得益于 TornadoVM 的加持，Java 开发者无需跳出熟悉的开发环境，就能享受到 GPU 加速的强大计算能力。尽管目前仍在开发中，但该项目已展示出 Java 在 AI 应用中无限的可能性，特别是在对安全性、可扩展性与可维护性有高要求的企业级场景下。
+
+对想要在 Java 中尝试 GPU 加速 LLM 推理的开发者而言，该项目已经 [开源发布于 GitHub](https://github.com/beehive-lab/GPULlama3.java)，并配有文档和示例，方便快速上手。
\ No newline at end of file
diff --git a/docs/md/AI/llm/grok-code-fast.md b/docs/md/AI/llm/grok-code-fast.md
new file mode 100644
index 0000000000..6022ece889
--- /dev/null
+++ b/docs/md/AI/llm/grok-code-fast.md
@@ -0,0 +1,155 @@
+# 02-Grok Code Fast
+
+2025 年 8 月 28 日
+
+## 0 Grok Code Fast 1
+
+ xAI非常激动地向大家推出 **grok-code-fast-1**——一款速度快、成本低的推理模型，专为智能体编码（agentic coding）而生。
+
+
+
+## 1 快速日常使用
+
+虽然现有模型已经非常强大，但在智能体编码工作流中——需要频繁循环推理和调用工具时，往往显得迟缓。作为智能体编码工具的重度用户，工程师发现还有提升空间：需要一种更灵活、响应更快、专为日常任务优化的方案。
+
+于是从零开始构建 `grok-code-fast-1`，采用全新模型架构。首先精心组建了包含大量编程内容的预训练语料库；随后在后期训练阶段，又挑选了真实 Pull Request 与编码任务的高质量数据集。
+
+整个训练过程中， x与合作伙伴紧密协作，在其智能体平台上不断调优模型行为。`grok-code-fast-1` 已经熟练掌握 grep、终端、文件编辑等常用工具，使用起来就像在你最爱的 IDE 中一样得心应手。
+
+ xAI已与部分合作伙伴达成协议，限时免费提供 `grok-code-fast-1`，包括 GitHub Copilot、Cursor、Cline、Roo Code、Kilo Code、opencode 和 Windsurf。
+
+## 2 极速
+
+ xAI的推理与超算团队研发了多项创新技术，显著提升服务响应速度，实现“模型在你读完思考轨迹的第一段之前，就已经调用了数十个工具”。 xAI还对 Prompt（提示）缓存进行了优化，在合作伙伴环境中常能保持 90% 以上的命中率。
+
+## 3 全能程序员
+
+`grok-code-fast-1` 在整个软件开发栈上表现极其全面，尤其擅长 TypeScript、Python、Java、Rust、C++ 与 Go。它能够在最少监督下完成常见编程任务——从零到一搭建项目、解答代码库问题，到精准定位并修复 bug。
+
+### 3.1 示例1：Battle Simulator
+
+
+
+Grok Code Fast 的速度惊人，几乎是目前最快的模型。它快到我不得不在 Cursor 中调整自己的工作方式。
+
+我利用 Grok Code Fast 在 Cursor 上用不到一天的时间，就快速搭建了这个战斗模拟器原型。由于它响应极快且能很好地遵循指令，我发现把任务拆得更小、更聚焦会取得更好效果，这样可以迅速迭代，并精准地让模型按照我的需求工作。
+
+在开发这款战斗模拟器时，我的流程是先让模型设计整体功能，再将这些功能细分并分阶段实现。这比一次性投放大量提示要高效得多。于是，战斗模拟器就这样顺利成形——我在 Cursor 中不断进行快速迭代，直到达到满意的效果。
+
+### 3.2 示例2：UI设计
+
+
+
+ xAI在与几位朋友共同开发 flavo.ai（一个 AI 网页构建器）时，一直使用 Grok Code Fast 来进行前端 UI 设计。
+
+借助它，从创意到设计稿的时间可以控制在一分钟以内，这彻底改变了原型制作的方式。移动端自适应同样表现出色，生成的界面在桌面和手机上都相当美观，几乎不需要额外调整。
+
+用 Grok 进行前端开发的有效做法：
+
+1. **明确需求**：开始前须清晰知道自己要构建什么。模糊的请求往往得不到理想结果。确定需求后，让 Grok 为你生成可视化的设计稿。
+2. **快速迭代**：每个设计稿通常在 60 秒以内即可完成。因此我会一次性创建多个版本，约 5‑10 种不同方案。
+3. **挑选并落地**：从中挑出最接近需求的那一版，然后基于它进行后续开发。高速生成的特性让 xAI能够在正式投入之前轻松探索多种设计方向。
+
+这种体验与传统的软件开发截然不同，更像是用代码快速草绘。它非常适合快速把想法落地并验证哪些方案可行。
+
+## 4 经济实惠
+
+ xAI把 `grok-code-fast-1` 设计为大众可及，费用如下：
+
+- 每百万输入 Token $0.20
+- 每百万输出 Token $1.50
+- 每百万缓存输入 Token $0.02
+
+该模型专为开发者日常任务打造，在性能与成本之间取得了理想平衡。它以低廉、体积小的形式提供强劲表现，是快速、经济完成常规编码工作的多面手。
+
+### 4.1 模型性能
+
+输出成本/每1M的Token数：
+
+
+
+### 4.2 方法论
+
+TPS（每秒 Token 数）指标通过各模型提供商的 API，直接测量响应生成速度，仅统计最终回复的 Token。
+
+- Gemini 2.5 Pro、GPT‑5 与 Claude Sonnet 4：使用对应公开 API 测得
+- Grok Code Fast 1 与 Grok 4：使用 xAI API 测得
+- Qwen3‑Coder：在 DeepInfra 上以低精度 (fp4) 部署，响应质量有所下降
+
+ xAI采用了综合评估方法，将公共基准与真实场景测试相结合。在完整的 SWE‑Bench‑Verified 子集上，`grok-code-fast-1` 通过内部评测框架取得 **70.8%** 的得分。
+
+尽管 SWE‑Bench 等基准提供有价值的参考，但它们未能完全捕捉真实软件工程中的细节，尤其是智能体编码工作流下的终端用户体验。
+
+为指导模型训练， xAI将这些基准与日常人工评估相结合——由经验丰富的开发者对模型在日常任务中的整体表现进行打分。同时构建了自动化评测，用于监控关键行为，帮助 xAI在设计上做出权衡。
+
+在研发 `grok-code-fast-1` 时， xAI始终把可用性和用户满意度放在首位，并以真实的人类评估为指引。最终，这款模型被程序员评为“快速且可靠”，适合日常编码任务。
+
+## 5 让每个人都能使用 Grok Code（限时免费）
+
+限时免费开放 `grok-code-fast-1`，仅在特定合作伙伴平台提供。以下是合作伙伴对该模型的评价——它曾以代号 **sonic** 暗线发布。
+
+ xAI很高兴在独家合作伙伴渠道上免费提供 Grok Code Fast 1。
+
+### ① GitHub Copilot
+
+“在早期测试中，Grok Code Fast 已经展示出在智能体编码任务中的速度与质量。为开发者赋能是 GitHub Copilot 的核心使命，这款新工具为 xAI的用户提供了极具吸引力的选择。”
+
+Chief Product Officer, GitHub
+
+### ② Cline
+
+*"**Grok Code Fast 在 Cline 中表现突出，能够在长时间的编码过程中保持进度，聪明地使用工具，并以极少的监督生成高质量代码。这让人感觉是智能化编程的一大步，不仅快，而且很有能力。**"*
+
+Head of AI, Cline
+
+### ③ opencode
+
+*"**Grok Code Fast 是首个足够快速、在编码工具中使用起来还能带来乐趣的推理模型——我们的许多用户已经把它设为默认工具，甚至让每日 token 使用量翻了一番。**"*
+
+Founder, opencode
+
+### ④ cursor
+
+"Grok Code 的速度真的惊人！我们在 Cursor 中发布了代号为 “sonic” 的模型，开发者对其高速表现赞不绝口。"
+
+VP of Developer Experience, Cursor
+
+### ⑤ kilo
+
+"我们的社区对 Grok Code Fast 的速度赞誉有加，并且对该模型在 Kilo Code 中调用工具的能力感到非常满意。"
+
+Developer Relations Engineer, Kilo Code
+
+### ⑥ Roo Code
+
+"Roo Code 社区对 Code 模式下的 Grok Code Fast 爱不释手。它能以飞快的速度制定方案，并以出乎意料的品味和直觉执行。"
+
+Co‑founder, Roo Code
+
+### ⑦ windsurf
+
+"我们非常享受与 xAI 团队合作测试并迭代模型的过程，惊喜地发现它的成本比其他模型低一个数量级，同时速度极快。每当速度提升、成本下降，就会为像 Windsurf 这样的智能 IDE 开辟新可能。我们对 xAI 在编码领域的进展印象深刻，并期待未来继续紧密合作。"
+
+Head of Product Growth, Cognition
+
+## 6 提示词工程指南
+
+ xAI团队编写了《[Prompt Engineering Guide](https://docs.x.ai/docs/guides/grok-code-prompt-engineering)》，帮助你从 `grok-code-fast-1` 中获取最佳效果。
+
+模型通过 xAI API 提供，费用同上：$0.20 / 1M 输入 Token、$1.50 / 1M 输出 Token、$0.02 / 1M 缓存输入 Token。
+
+https://console.x.ai/home：
+
+
+
+
+
+## 7 接下来几周的计划
+
+上周， xAI悄然以代号 **sonic** 发布了 `grok-code-fast-1`。在隐蔽发布期间，团队持续监控社区反馈，并陆续上线多个模型检查点进行改进。
+
+随着新模型系列的迭代升级， xAI将快速采纳你的建议。非常感谢开发者社区的支持，欢迎随时[分享所有反馈](https://discord.gg/x-ai)，无论正面还是负面。
+
+ xAI计划以天为单位而非周来推送更新。已经在训练中的新变体将支持多模态输入、并行工具调用以及更长上下文长度。
+
+阅读 `grok-code-fast-1` 的[模型卡片](https://data.x.ai/2025-08-26-grok-code-fast-1-model-card.pdf)。期待看到你们的创意作品！
\ No newline at end of file
diff --git a/docs/md/AI/llm/grok4.md b/docs/md/AI/llm/grok4.md
new file mode 100644
index 0000000000..958be37c41
--- /dev/null
+++ b/docs/md/AI/llm/grok4.md
@@ -0,0 +1,130 @@
+# 01-Grok 4 重磅发布：定义下一代 AI 智能巅峰
+
+## 0 前言
+
+Grok 4 是目前全球最智能的模型。原生支持工具使用和实时搜索集成，向 SuperGrok 和 Premium+ 用户开放，也可通过 xAI API 使用。还推出新的 SuperGrok Heavy 订阅层级，提供对 Grok 4 Heavy 的访问权限——Grok 4 最强大版。
+
+[试用 SuperGrok](https://grok.com/plans)
+ [访问 API](https://docs.x.ai/)
+
+## 1 强化学习的扩展
+
+在 Grok 3 中，我们将下一个词预测的预训练规模提升到了前所未有的高度，打造出了在世界知识和表现方面无与伦比的模型。还推出了 Grok 3 Reasoning，它通过强化学习进行训练，使其能更深入思考问题并提高解决准确率。观察到了一些规模化趋势，表明强化学习训练有望大幅扩展。
+
+在 Grok 4 中，我们利用了 Colossus —— 一个由 200,000 个 GPU 组成的集群，以预训练的规模运行了用于提升 Grok 推理能力的强化学习训练。这得益于整个系统中的一系列创新，包括新的基础设施和算法优化，使训练的计算效率提升了 6 倍。还进行大规模的数据收集工作，将可验证的训练数据从主要集中在数学和编程领域，扩展到更多领域。最终的训练过程在比以往大一个数量级的计算量下，实现平稳的性能提升。
+
+### 1.1 人类的最终考试
+
+位于人类知识前沿的专家级基准测试
+
+
+
+## 2 原生工具使用
+
+Grok 4 在训练中通过强化学习学习了如何使用工具。这使它能在许多传统大语言模型难以应对的场景下，借助代码解释器、网页浏览等工具来增强思维能力。无论是搜索实时信息还是回答复杂研究问题，Grok 4 都能自主生成搜索查询，从网络中提取相关知识，深入挖掘，构建高质量回答。
+
+还训练 Grok 使用强大的工具，从 X（原推特）深处获取信息。Grok 可以使用先进的关键词和语义搜索工具，甚至查看媒体内容，以进一步提升回答质量。
+
+X 搜索、网页搜索、研究案例见原文。
+
+## 3 Grok 4 Heavy
+
+我们在并行测试时计算（test-time compute）方面取得了进一步进展，使 Grok 能够同时考虑多个假设。我们称这个模型为 **Grok 4 Heavy**，它在性能和可靠性方面树立了新标准。Grok 4 Heavy 在多数学术基准测试中达到了饱和状态，并且是首个在“人类最终考试”中获得 50% 得分的模型——这是被设计为“最后一个封闭式学术基准”的测试。
+
+
+
+## 4 前沿智能
+
+Grok 4 在前沿智能方面实现了飞跃，在封闭模型中在 ARC-AGI V2 上创下 15.9% 的新纪录（几乎是 Opus 的 ~8.6% 的两倍，超出此前最高成绩 8 个百分点）。在 agent 型 Vending-Bench 测试中，Grok 4 表现卓越，平均净收益达 $4694.15，售出 4569 单位，远超 Claude Opus 4（$2077.41，1412 单位）、人类（$844.05，344 单位）和其他模型。
+
+Grok 4 Heavy 在 2025 年 USAMO（美国数学奥林匹克）中取得 61.9% 的成绩，并且是第一个在“人类最终考试”文本子集中得分 50.7% 的模型，展示了其通过大规模强化学习和原生工具使用在复杂推理方面的卓越能力。
+
+
+
+### GPQA（科学问答）
+
+| 模型 | 得分 |
+| ------------------------- | ---- |
+| Grok 4 Heavy（含 Python） | 88.4 |
+| Grok 4 | 87.5 |
+| Gemini 2.5 Pro | 86.4 |
+| o3 | 83.3 |
+| Claude Opus 4 | 79.6 |
+
+### LiveCodeBench（1 月 - 5 月，竞赛编程）
+
+| 模型 | 得分 |
+| ------------------------- | ---- |
+| Grok 4 Heavy（含 Python） | 79.4 |
+| Grok 4（含 Python） | 79.3 |
+| Grok 4 | 79 |
+| Gemini 2.5 Pro | 74.2 |
+| o3 | 72 |
+
+### USAMO 2025（奥林匹克数学证明）
+
+| 模型 | 得分 |
+| ------------------------- | ---- |
+| Grok 4 Heavy（含 Python） | 61.9 |
+| Gemini Deep Think | 49.4 |
+| Grok 4 | 37.5 |
+| Gemini 2.5 Pro | 34.5 |
+| o3 | 21.7 |
+
+### HMMT 2025（竞赛数学）
+
+| 模型 | 得分 |
+| ------------------------- | ---- |
+| Grok 4 Heavy（含 Python） | 96.7 |
+| Grok 4（含 Python） | 93.9 |
+| Grok 4 | 90 |
+| Gemini 2.5 Pro | 82.5 |
+| o3 | 77.5 |
+| Claude Opus 4 | 58.3 |
+
+### AIME’25（竞赛数学）
+
+| 模型 | 得分 |
+| ------------------------- | ---- |
+| Grok 4 Heavy（含 Python） | 100 |
+| Grok 4（含 Python） | 98.8 |
+| o3（含 Python） | 98.4 |
+| Grok 4 | 91.7 |
+| o3 | 88.9 |
+| Gemini 2.5 Pro | 88 |
+| Claude Opus 4 | 75.5 |
+
+### ARC-AGI-2（抽象与推理）
+
+| 模型 | 得分 |
+| -------------- | ---- |
+| Grok 4 | 15.9 |
+| Claude Opus 4 | 8.6 |
+| o3 | 6.5 |
+| Gemini 2.5 Pro | 4.9 |
+
+------
+
+## 5 Grok 4 API
+
+Grok 4 API 为开发者提供了前沿级别的多模态理解能力，拥有 256,000 的上下文窗口和强大的推理能力，能够处理文本和视觉等复杂任务。API 支持跨 X、网页和各大新闻源的实时数据搜索，借助原生工具使用实现准确及时的回答。它还具备企业级安全与合规性，包括 SOC 2 Type 2、GDPR 和 CCPA 等认证，确保在敏感应用中的可靠性。Grok 4 即将支持云服务合作伙伴，方便企业大规模部署创新 AI 解决方案。
+
+## 6 Grok 4 语音模式
+
+通过升级后的语音模式与 Grok 交流，体验更加真实、快速、智能的语音互动。我们全新推出了一个沉静自然的声音，并重新设计了对话流程，使其更贴近真实对话。
+
+现在，Grok 还能“看见”你所看到的内容！只需打开摄像头，说出问题，Grok 就会在语音聊天过程中实时分析画面并回应你。这个模型由我们自主训练，结合了最先进的强化学习框架和语音压缩技术。
+
+
+
+开启语音聊天时的视频功能，Grok 就能在与你交谈时“看见”画面内容。
+
+## 7 接下来的计划
+
+xAI 将继续把强化学习扩展到前所未有的水平，基于 Grok 4 的技术进展，不断突破 AI 的边界。我们计划将训练目标从可验证的奖励机制扩展到处理真实世界中的复杂问题，使模型能在动态环境中学习与适应。
+
+多模态能力也将持续增强，整合视觉、音频等感知，提供更自然直观的交互体验。总体目标仍是让模型变得更智能、更快速、更高效，真正实现帮助人类解决深层问题的愿景。
+
+参考：
+
+- https://x.ai/news/grok-4
\ No newline at end of file
diff --git a/docs/md/AI/llm/inference-engine.md b/docs/md/AI/llm/inference-engine.md
new file mode 100644
index 0000000000..cdcc4b3d10
--- /dev/null
+++ b/docs/md/AI/llm/inference-engine.md
@@ -0,0 +1,184 @@
+# 大模型的“Tomcat”：一文读懂AI推理引擎（Inference Engine)
+
+## 1 推理引擎是啥？
+
+从熟悉的“服务器”说起，想象你用Java写好了一个业务应用，如订单处理服务，打成一个JAR或WAR包。这包能直接运行吗？显然不能。你需要一个“东西”来运行它：
+
+* Java应用，这就是JVM。JVM负责解释执行你的Java字节码，管理内存，处理线程等等
+* Web应用，你可能还需一个**应用服务器**，如Tomcat或WebLogic。它在JVM基础，提供HTTP服务、Servlet容器、连接池等一系列能力，让你的Web代码能对外提供服务
+
+现在我们把主角换成大模型。AI科学家们通过海量“学习资料”（数据）和复杂“学习方法”（训练算法），最终“毕业”得到一个成果——**模型文件**。这个模型文件，好比打包好的`order-service.jar`，包含庞大网络结构和数以百亿计的参数（权重），记录模型学到的所有“知识”。
+
+这个模型文件能直接响应我们的请求，如回答“今天天气怎么样”吗？同样不能。它也需要一个“运行环境”来加载它、管理它、并高效地执行它，最终把结果（答案）输出给我们。
+
+这专门用来运行LLM的“超级应用服务器”，就是——**推理引擎 (Inference Engine)**。
+
+### 小结
+
+把训练好的大模型比作“应用程序包（JAR/WAR）”，推理引擎就是运行这个包的“应用服务器（Tomcat/WebLogic）+ JVM”的组合体。其核心任务，就是让模型**高效、稳定、经济**地对外提供服务。这过程，在AI领域叫“推理（Inference）”。
+
+## 2 没有推理引擎又如何？直接Python跑不行？
+
+Q：我看到很多AI工程师直接用Python+PyTorch/TensorFlow就能加载模型跑，为啥非搞个这么复杂推理引擎？
+
+A：好问题！这就像我们也能用`main`方法，直接`new`一个`HttpServer`启动一个Web服务，但这能直接上生产？你会遇到：
+
+* **性能极差：** 一个请求就把CPU打满了，并发能力几乎为零
+* **资源浪费：** 内存占用巨大，无法精细化管理
+* **功能缺失：** 没有日志、没有监控、没有高可用、没有动态扩缩容
+
+直接用Python框架（如PyTorch）运行模型，就面临类似问题，而且在AI场景下，这些问题会被指数级放大：
+
+### 2.1 “慢”得离谱（高延迟）
+
+**业务场景：** 用户在智能客服里问个问题，等了30秒才看到第一个字蹦出来。
+
+**技术原因：** 大模型的计算量是天文数字。一个请求过来，逐层计算，不经任何优化，就像开着一辆家用小轿车去拉一整火车的货。
+
+### 2.2 “吞”得吓人（低吞吐）
+
+**业务场景：** 数据中心支撑全集团业务，现要上线一个基于大模型的报告自动生成功能。结果发现，系统同时只能服务3、5个人，再多请求就全部卡死排队。
+
+**技术原因：** 模型会独占一块或多块GPU显卡，而GPU显存非常宝贵且昂贵。一个请求就把显存用完了，其他请求只能干等着。这就像一个只有一个窗口的银行，办完一个才能叫下一个。
+
+### 2.3 “贵”得心疼（高成本）
+
+**业务场景：** 为支撑业务，不得不堆砌大量顶级GPU卡（一张A100/H100几十万）。年终汇报时，老板一看电费和硬件采购单，脸都绿了。
+
+**技术原因：** 资源利用率极低。GPU大部分时间可能在空闲等待，或者显存被大量浪费。花了大价钱买来的“法拉利”，却一直在市区里堵着车，油耗还高得惊人。
+
+所以，直接用原生框架跑模型，只适合实验室里做研究、发论文。一旦进入生产，**推理引擎就成了必选项**。
+
+## 3 推理引擎的最佳实践
+
+推理引擎之所以能解决上述问题，是因为它在“运行”模型这件事，做大量优化和工程化工作。
+
+### 3.1 模型“瘦身术”
+
+就像做Java应用性能优化时，会对代码重构，优化数据结构，减少不必要的对象创建。
+
+#### 3.1.1 量化 (Quantization)
+
+原始的模型参数通常32位浮点数（FP32），精度高但占空间大，计算也慢。量化就是把这些参数“降级”成16位（FP16/BF16）甚至8位整数（INT8）。好比把一个需要用`double`类型存储的数字，发现用`float`甚至`int`就够，精度损失不大，但存储空间和计算速度大大提升。
+
+#### 3.1.2 剪枝 (Pruning)
+
+科学家发现，模型里很多参数（神经元连接）其实“冗余”，对最终结果影响不大。把这些“细枝末节”砍掉，进一步减小模型体积。
+
+#### 3.1.3 最佳实践
+
+场景：你们需要在一个边缘设备或者性能没那么强的服务器上部署一个模型，用于内部的文档识别或人脸识别。
+
+推理引擎咋做：像NVIDIA的**TensorRT-LLM**、开源的**llama.cpp**等推理引擎，都内置了强大的量化工具。你只需要把原始的FP32模型丢给它，配置好量化参数（比如INT8），它就能自动帮你生成一个“瘦身”后的模型。这个新模型体积可能只有原来的1/4，推理速度提升好几倍，而识别准确率可能只下降了不到1%。对于很多业务场景来说，这种性价比极高。
+
+### 3.2 请求“拼车”大法
+
+批处理 (Batching)如数据库操作，我们会把多个单条`INSERT`合并成一个`batch insert`，减少网络和数据库IO开销。
+
+#### 3.2.1 理论概念
+
+GPU是并行计算神器，它最喜欢“干大事”：一次处理一大批相似任务。若一个一个请求喂给它，就像让一个128车道高速公路，每次只跑一辆车，巨大浪费。批处理就是把在短时间内收到的多个用户请求，“攒”成一个大大的批次（Batch），再一次性丢给GPU去计算。
+
+#### 3.2.2 最佳实践
+
+##### ① 挑战
+
+简单的批处理（静态批处理）会引入延迟，须等到凑够一个批次或超时才处理。但用户请求是动态到达的，有的长有的短。
+
+##### ② 推理引擎的进化（Continuous Batching）
+
+假设有3个用户同时请求。
+
+* 用户A：请求生成一篇500字短文
+* 用户B：请求生成一句10个字的诗
+* 用户C：请求生成一份2000字的报告
+
+传统方式： 须等最长的C请求（2000字）全部生成完毕，这个批次才算结束。A和B早就生成完了，但它们的GPU资源必须被占用着，干等着，造成巨大的浪费（显存空泡）。
+
+最佳实践：vLLM引擎的PagedAttention技术。**近两年最火的优化技术了！它的思想借鉴了操作系统的**虚拟内存分页（Paging）。把GPU显存划分成一个个固定大小“块（Block）”，一个请求来了，按需分配块，而非一次性预分配一个巨大的连续空间。当用户B的请求（10个字）生成完毕后，它占用的“块”会立刻被释放，并马上可以分配给新的等待请求。
+
+效果：这种“持续批处理”或“动态批处理”技术，将吞吐量提升**2-4倍**甚至更高！目前业界顶级的开源推理引擎，如**vLLM**、**HuggingFace TGI (Text Generation Inference)**、**TensorRT-LLM**都将此作为核心能力。作为架构师，在选择推理引擎技术栈时，支持Continuous Batching是关键考量点。
+
+### 3.3 计算“流水线”
+
+和Java多线程、微服务拆分异曲同工。一个大任务，一个人干不过来，就拆成小任务，多个人/多个服务一起干。
+
+#### 张量并行
+
+TP，Tensor Parallelism。
+
+一个模型的某层（如一个巨大的矩阵乘法）计算量太大，一张GPU卡都扛不住。就把这大矩阵“切”成几块，分给多张卡，每张卡算自己那一小块，最后再把结果合并。好比用`Fork/Join`框架处理一个大集合。
+
+#### 流水线并行
+
+PP，Pipeline Parallelism。
+
+把模型不同层（Layer）放到不同GPU。如一个模型有80层，1号GPU负责1-20层，2号GPU负责21-40层... 数据像在流水线一样，流过一张张GPU，每张GPU只做自己那部分工作。这完全就是微服务架构的思想，每个GPU就是一个“微服务”。
+
+#### 最佳实践
+
+##### 场景
+
+部署一个像Llama3-70B（700亿参数）巨型模型，单张GPU卡装不下。
+
+##### 推理引擎咋做？
+
+像**DeepSpeed Inference**、**TensorRT-LLM**这类引擎，提供成熟分布式推理能力。无需手动实现复杂的卡间通信（All-Reduce、All-Gather等），只需在配置文件中声明：“我要用4张卡跑这个模型，使用2路张量并行和2路流水线并行”。推理引擎会自动帮你完成模型的切分、部署和协同工作。
+
+这就屏蔽了底层的分布式计算复杂性，让你能像管理一个逻辑上的“大GPU”一样，去管理一个GPU集群。你的关注点，从如何实现并行，变成了如何规划并行策略以达到最佳性价比。
+
+## 4 推理引擎选型
+
+选型通常考虑**稳定性、社区活跃度、技术支持和国产化替代**等。
+
+### 4.1 NVIDIA TensorRT-LLM，重量级选手，性能标杆
+
+NVIDIA官方出品，性能优化到极致。深度绑定NVIDIA硬件生态，能最大化榨干A100/H100等显卡的性能。支持前面提到的所有高级优化。
+
+适用场景：对性能有极致要求，不差钱，且技术栈以NVIDIA为主的场景。追求业界SOTA（State-of-the-Art）性能。
+
+类比：像是Oracle数据库，性能强悍，但有厂商锁定风险。
+
+### 4.2 vLLM，开源新贵，吞吐量之王
+
+凭借其创新的PagedAttention技术，在吞吐量方面表现极其出色，迅速成为开源社区的明星项目。易用性好，Python接口友好。
+
+适用场景：高并发的在线服务场景，如智能客服、AI聊天机器人。希望快速部署，获得极高吞吐量的首选。
+
+类比：像是Nginx，轻量、高效，专注于解决高并发问题。
+
+### 4.3 Hugging Face TGI（Text Generation Inference）社区宠儿，生态完善
+
+来自最大的AI开源社区Hugging Face，对Hugging Face生态中的海量模型支持最好。功能全面，工程化成熟度高，易于部署和监控。
+
+适用场景：需要快速验证和部署多种不同类型的开源大模型。企业内部的AI中台、模型即服务（MaaS）平台的理想底座。
+
+类比：像是Spring Boot，开箱即用，生态整合能力强，能快速构建应用。
+
+### 4.4 国产推理引擎
+
+如TNN, MindSpore Lite等。
+
+**特点：** 国内厂商（如腾讯、华为）主导，更侧重于国产芯片（如昇腾、寒武纪）的适配和优化，在信创和国产化替代方面有天然优势。
+
+**适用场景：** 国企中对软硬件自主可控有强要求的项目。
+
+**类比：** 像是TongWeb、Kingdee，在特定政策和生态环境下是必然选择。
+
+### 4.5 建议
+
+* 初次接触和探索的项目，强烈推荐 **vLLM** 或 **Hugging Face TGI** 入手。都提供Docker镜像，方便在现有数据中心K8s集群拉起一个服务。可以像部署一个普通的Java微服务一样，通过RESTful API或gRPC来调用它，无缝集成到现有的Java技术栈中
+* 核心业务和性能要求极高的场景，可深入研究 **TensorRT-LLM**，它能带来极致的性能回报
+* 务必关注信创和国产化要求，提前了解和测试国产推理框架与硬件结合方案
+
+## 5 总结
+
+跳出繁杂技术细节，站在架构师高度审视：
+
+* **它是一种资源虚拟化和池化技术：** 它将昂贵、稀缺的GPU计算资源，通过批处理、并行计算等技术，池化成一个可以被多个业务方高效共享的服务。这与我们用K8s管理CPU和内存资源，用数据库连接池管理数据库连接，在思想上是完全一致的。
+* **它是一个标准的“中间件”：** 它解决了大模型这个“特殊应用”在生产环境运行时的通用问题（性能、并发、稳定性），将AI研究人员和我们业务开发人员解耦。研究员专注于模型算法，我们专注于业务逻辑和系统集成，大家各司其职。
+* **它是未来AI应用的核心基础设施：** 就像JVM之于Java，K8s之于云原生，推理引擎将成为企业“AI中台”或“MaaS平台”不可或缺的基石。
+
+虽无需直接写CUDA，不直接研究Attention机制，但理解推理引擎的原理、价值和选型策略，将是我们在AI时代保持核心竞争力的关键。它能帮助我们更好地规划企业级的AI基础设施，设计出更健壮、更高效、更具扩展性的AI赋能业务系统。
+
+希望本文帮你把“推理引擎”这个概念，从一个模糊的术语，变成一个你工具箱里清晰的、可以评估和使用的架构组件！
\ No newline at end of file
diff --git a/docs/md/AI/llm/kimi-k2-whats-fuss-whats-like-use.md b/docs/md/AI/llm/kimi-k2-whats-fuss-whats-like-use.md
new file mode 100644
index 0000000000..b3d7b52965
--- /dev/null
+++ b/docs/md/AI/llm/kimi-k2-whats-fuss-whats-like-use.md
@@ -0,0 +1,87 @@
+# Kimi K2：为什么它这么火？实际使用体验如何？
+
+## 0 前言
+
+**Kimi K2** 的大型语言模型近期在科技圈引起了不小的轰动。我天朝AI公司 [Moonshot AI](https://www.moonshot.ai/) 开发，这家公司背后有阿里巴巴支持。Kimi K2 发布被不少人视作另一个 [DeepSeek](https://www.thoughtworks.com/insights/blog/generative-ai/deepseek-five-things-business-technology-leaders-know) 时刻。和 DeepSeek 一样，Kimi K2 也是开源权重的模型，也就是说，它的训练参数可以免费下载和自定义使用。而且同样地，它在多个测试中展现出超越主流模型的性能。
+
+## 1 K2咋工作的？
+
+Kimi 采用MoE模型架构，即内部包含多个子网络，每个子网络擅长解决特定类型的问题。该设计优势在于可提升运行效率，速度更快，计算成本更低。
+
+### 使用成本
+
+尽管有 **320 亿个活跃参数**（总参数量达到 1 万亿），但使用成本不高。
+
+举个例子：
+
+- Claude Opus 4 模型每百万个输入 token 收费 $15，每百万个输出 token 收费 $75
+- Kimi 价格仅 $0.15（输入）和 $2.50（输出）
+
+价格差距非常明显！
+
+### Agentic LLM
+
+Kimi 还被称为一种 [具备代理能力的 LLM（Agentic LLM）](https://moonshotai.github.io/Kimi-K2/)。Moonshot AI 在产品介绍中表示，Kimi 是“专门为代理类任务精心优化”的。
+
+与常见的大模型采取复杂推理步骤的方式不同，Kimi更强调从外部经验中“学习”，该思路也正是研究人员 David Silver 和 Richard Sutton 在其论文 [《经验时代》（The Era of Experience）](https://storage.googleapis.com/deepmind-media/Era-of-Experience /The Era of Experience Paper.pdf) 中提出的理念，而 Moonshot AI 团队也引用该论文。
+
+## 3 它真的算另一DeepSeek？
+
+Kimi K2 的发布被一些人称为“又一个 DeepSeek 时刻”，确实，这又是一个由我天朝公司推出的开源模型，表现优于不少国际大厂模型。但与年初 DeepSeek 引发的广泛讨论相比，Kimi K2 似乎没有带来同样程度的文化和经济影响。
+
+但也正因为如此，可能更说明问题——现在天朝推出高性能开源大模型已不再令人惊讶，这本身就是 AI 领域格局正在变化的信号。
+
+但这并不意味着 OpenAI 或 Anthropic 等巨头会马上被取代，但像 DeepSeek 和 Kimi 这样的技术突破，展示 AI 领域多样性，进一步激发创新与实验。
+
+## 4 K2 在编程方面表现咋？
+
+在编程任务方面，Kimi K2 表现相当亮眼。据 Moonshot 介绍，这款模型在多个评测基准上超越了其他主流模型（[参考资料](https://moonshotai.github.io/Kimi-K2/)）。虽然最终效果还需在实际应用中验证，但许多开发者在尝试之后都给予了积极反馈。
+
+K2 还能与 [Claude Code](https://www.thoughtworks.com/insights/blog/generative-ai/claude-code-codeconcise-experiment)（Anthropic 推出的编程工具）集成，未来我们可能会听到更多关于它在代码方面的应用案例。
+
+## 5 一线开发者体验
+
+采访某知名国际技术咨询公司的软件工程师 **Zhenjia Zhou**。他从模型发布起就开始在自己的项目中进行测试。
+
+Q：你为啥开始使用 Kimi K2？啥吸引你？
+
+A：我在模型发布当天就用了！主要是 Claude Sonnet 4 对于个人项目来说太贵了，所以我试着将 Kimi K2 与 Claude Code 搭配使用，主要是用来写后端的 Python 代码。
+
+Q：它和其他模型相比，有什么明显的不同吗？
+
+A：我用 [Cursor](https://www.thoughtworks.com/radar/tools/cursor) 时通常搭配 openAI o1。相比之下，Kimi 在调用工具方面更“聪明”。如我喜欢用 Sequential Thinking 的 [MCP server](https://www.thoughtworks.com/insights/blog/generative-ai/model-context-protocol-beneath-hype)，o1 通常不会主动调用它，除非我特别提示“请用顺序思考解决这个问题”。Claude Sonnet 3.7 也有类似问题。
+
+Q：你最喜欢 Kimi 的什么地方？
+
+A：它便宜而且开源！Claude Sonnet 4 非常贵，比如一个任务可能就要花 $10–20 美元。而用 Kimi K2，我大概能用 50 元人民币（约 7 美元）完成十个类似任务。而且因为它开源，我甚至可以自己部署模型，进一步降低成本。
+
+这让我效率大大提升。我可以并行处理任务——只要这十个任务之间没有冲突，我就能开十个 Claude Code 实例，各自用 Kimi K2 来工作。
+
+Claude Code 刚出来时我就想这样用，但用 Claude Sonnet 4 的话开销太大了。
+
+Q：有没有你不太满意的地方？
+
+A：我觉得 Kimi K2 响应速度比较慢，目前比 Sonnet 4 慢一些。而且它的上下文窗口相对也较小。
+
+Q：什么时候你会优先选择它，而不是其他成熟模型？
+
+A：就目前使用来看，我觉得 Claude Code 并不是最适合 Kimi K2 的平台——虽然用 Kimi 比较便宜，但 Claude Code 本身是为 Claude Sonnet 4 设计的。当我把 Kimi K2 接进去时，就好像“Claude 的身体里装了个不同的灵魂”。
+
+不过，如果以后 Kimi K2 有比 Claude Code 更好用的界面，那我可能会更多使用它来替代 Claude。
+
+Q：你咋看“又一个 DeepSeek 时刻”这个说法？
+
+A：我觉得这说明开源语言模型在 AI 领域可以发挥重要作用——不仅是成本上的优势，还有性能上的竞争力。
+
+Q：你怎么看开源模型的优势？
+
+A：我觉得主要有两点吸引人：
+
+- 对于非常注重隐私的公司，可以自建部署模型
+- 开源意味着更多服务提供方
+
+如现在 Claude Sonnet 4 只能通过 AWS 和 Claude 平台用，他们可以决定 API 的价格。而对于开源模型，未来会有更多平台提供服务，可能会出现价格战，API 使用成本就会下降。
+
+## 6 总结
+
+Kimi K2 目前还处于非常早期的阶段，我们会持续关注，未来可能也会自己做一些测试。
\ No newline at end of file
diff --git a/docs/md/AI/llm/memory-faq.md b/docs/md/AI/llm/memory-faq.md
new file mode 100644
index 0000000000..45168871e7
--- /dev/null
+++ b/docs/md/AI/llm/memory-faq.md
@@ -0,0 +1,133 @@
+# 解锁 ChatGPT 超能力：全新「记忆」功能深度解析
+
+## 0 📌 **注意事项**
+
+由于近期法律变化，某些服务的数据保留政策可能受到影响，详见[官方博客说明](https://openai.com/index/response-to-nyt-data-demands/)。
+
+------
+
+## 1 🆕 免费用户也能享受「记忆」功能升级！
+
+**2025 年 6 月 3 日起**，开始向已登录的 **免费用户**逐步推出「记忆能力」优化升级。现在，**ChatGPT 可参考你最近的对话内容**，从而提供更贴近你的需求、更个性化的回答。
+
+- 免费用户获得的是「轻量版记忆」，能在多轮对话中保留短期上下文信息。
+- Plus 和 Pro 用户的记忆功能则更强大，具备长期记忆能力。
+
+### 1.1 ✅ 启用方式（仅适用于欧洲地区）：
+
+对于在欧盟、英国、瑞士、挪威、冰岛或列支敦士登的免费用户，会看到提示让你启用记忆功能，或可在 **设置 > 个性化 > 记忆 > 引用聊天记录** 中手动开启。
+
+其他地区的免费用户如果已启用记忆功能，将自动获得此次升级。
+
+可随时关闭 ChatGPT 的记忆功能，选择：
+
+- 不引用“保存的记忆”
+- 不引用“聊天记录”
+
+也可用「**临时聊天**」，完全不调用或更新任何记忆内容。
+
+## 2 ☎️ 语音助手体验（仅限美国和加拿大）
+
+拨打 **1-888-GPT-0090**，即可体验 ChatGPT 的语音助手，快速获取关于 ChatGPT 及 OpenAI 产品的帮助。
+
+通话可能会用于改进服务质量。[了解更多](https://help.openai.com/en/articles/11391933-1-888-gpt-0090-ai-voice-help-over-the-phone-experimental)。
+
+## 3 🧠 ChatGPT 的记忆功能说明
+
+ChatGPT 可以在多轮对话中记住有用信息，让回答更贴合你的兴趣和需求。不论是打字、语音、还是图像请求，只要你表达过清晰的偏好，它都有可能被记住。
+
+如你告诉它：“**记住我是素食主义者，推荐食谱时请考虑这一点**”，它将会在未来对话中考虑这个偏好。
+
+你可以随时问它：“你还记得我哪些事情？”来查看当前记忆。[了解更多](https://help.openai.com/en/articles/9237897-chatgpt-search)。
+
+## 4 👤 可随时管理 ChatGPT 的记忆
+
+- 删除单条记忆
+- 清除某些或所有记忆
+- 关闭记忆功能
+- 使用「临时聊天」跳过记忆记录
+
+## 5 🧩 「记忆」功能咋运作？
+
+ChatGPT 有两种记忆设置：
+
+### 5.1 **引用保存的记忆**
+
+- 是你明确告诉 ChatGPT 要记住的内容（如姓名、爱好、饮食偏好）。
+- 类似「自定义说明」，但它是自动更新的，不需你手动管理。
+- 如果你说了某些可能在未来有用的信息，ChatGPT 也可能自动保存为记忆。
+
+> 示例：你说“我住在北京”，下次提问“周末去哪玩？”时，它可能回答“北京的好去处有……”
+> 如果你删除这条记忆，它将不再在新对话中使用，但旧对话不会自动清除相应内容。
+
+### 5.2 **引用聊天记录**
+
+- ChatGPT 会引用近期聊天内容作为上下文，用于改进响应质量。
+- 不同于保存的记忆，这类信息会根据上下文自动更新或遗忘。
+- 如果关闭“引用保存的记忆”，聊天记录引用也会一并关闭。
+
+## 6💡 启/禁用记忆功能
+
+进入 **设置 > 个性化 > 记忆**，可选：
+
+- 仅开启“引用保存的记忆”
+- 仅开启“引用聊天记录”
+- 同时开启或全部关闭
+
+> ⚠️ 关闭“引用保存的记忆”会自动关闭“引用聊天记录”。
+
+## 7 🧽 如何彻底删除某项记忆？
+
+若开启了记忆功能，想**彻底删除某条信息**，请：
+
+1. 删除「保存的记忆」；
+2. 删除包含该信息的聊天记录。
+
+否则，旧聊天中仍可能出现相关内容。
+
+## 8 📁 ChatGPT 记忆容量说明
+
+- **引用聊天记录**没有存储上限。
+- **保存的记忆**有容量限制。你可以在 **设置 > 个性化 > 管理记忆** 中查看用量。
+
+存满时，ChatGPT 不会再保存新记忆，直到你清理空间。
+
+## 9 🧾 ChatGPT 会记住敏感信息吗？
+
+处理记忆时，严肃对待用户隐私和安全：
+
+- 默认不主动记住敏感信息（如健康状况），除非你明确要求。
+- 你始终掌控自己的信息，可以随时查看、删除、关闭记忆功能。
+
+如果你不希望某些内容被记录，请不要在聊天中提及。
+
+## 10 🧠 ChatGPT 会用我的记忆来训练模型吗？
+
+只有在你**启用了“帮助改进模型”**功能时，ChatGPT 才可能使用你分享的内容（包括记忆）来改进模型表现。
+
+- 你可以随时在 **数据控制** 中关闭该功能。
+- **ChatGPT Team、Enterprise 和 Edu 用户的内容默认不会用于训练。**
+
+[了解更多数据使用政策](https://help.openai.com/en/articles/7730893-data-controls-faq)
+
+## 11 🧠 所有模型都支持记忆吗？
+
+不是所有模型都支持记忆功能。截至目前，**o1-pro 模型不支持所有用户的记忆功能**。
+
+## 12 🔍 记忆功能如何影响 ChatGPT 搜索？
+
+当你启用了记忆，并使用 **o3 或 o4-mini 模型**时，ChatGPT 可使用你的记忆或最近聊天内容来优化搜索查询。
+
+如你曾说自己是“**素食主义者，住在旧金山**”，
+
+当你问：
+
+> “我附近有什么餐厅值得推荐？”
+
+ChatGPT 可能会自动转化为：
+
+> “旧金山有哪些适合素食者的餐厅？”
+
+以提供更个性化结果。
+
+[了解更多 ChatGPT 搜索功能](https://help.openai.com/en/articles/9237897-chatgpt-search)
\ No newline at end of file
diff --git a/docs/md/AI/llm/qwen3-coder.md b/docs/md/AI/llm/qwen3-coder.md
new file mode 100644
index 0000000000..31d97c1eb3
--- /dev/null
+++ b/docs/md/AI/llm/qwen3-coder.md
@@ -0,0 +1,173 @@
+# Qwen3-Coder: 在世界中自主编程
+
+## 0 前言
+
+### Qwen3-Coder
+
+2025年7月22日正式发布 Qwen3-Coder，qwen迄今最具代理能力的代码模型。Qwen3-Coder 有多个尺寸，但迫不及待给大家提供当前最强大版本，Qwen3-Coder-480B-A35B-Instruct，总参数量 480B，激活 35B 的 MoE 模型，原生支持 256K token 的上下文并可通过 YaRN 扩展到 1M token，卓越代码和 Agent 能力。
+
+Qwen3-Coder-480B-A35B-Instruct 在 Agentic Coding、Agentic Browser-Use 和 Agentic Tool-Use 上取得了开源模型的 SOTA 效果，可与 Cluade Sonnet4 媲美：
+
+
+
+### Qwen Code
+
+还推出并开源代理式编程的命令行工具：Qwen Code。基于 Gemini Code 二开，但进行了 prompt 和工具调用协议适配，使 Qwen Code 最大程度激发 Qwen3-Coder 在 Agentic Coding 任务上的表现。
+
+Qwen3-Coder 可以和社区优秀编程工具结合，如 Claude Code、Cline 等，作为一款基础模型，期待数字世界的任何角落都可用它，Agentic Coding in the World！
+
+## 1 Qwen3-Coder
+
+### 1.1 Pre-Training
+
+预训练阶段，这次 Qwen3-Coder 从不同角度 Scaling，以提升模型的代码能力：
+
+- 数据扩展：总计 7.5T（代码占比 70%），在保持通用与数学能力的同时，具备卓越的编程能力
+- 上下文扩展：原生支持 256K 上下文，借助 YaRN 可拓展至 1M，专为仓库级和动态数据（如 Pull Request）优化，助力 Agentic Coding
+- 合成数据扩展：利用 Qwen2.5-Coder 对低质数据进行清洗与重写，显著提升整体数据质量
+
+### 1.2 Post-Training
+
+#### Scaling Code RL: Hard to Solve, Easy to Verify
+
+
+
+与当前社区普遍聚焦竞赛类代码生成不同，qwen认为所有代码任务天然适合执行驱动的大规模强化学习。因此选择在更丰富的真实代码任务上扩展 Code RL 训练。
+
+通过自动扩展测试样例，qwen构造了大量高质量训练实例，成功释放RL的潜力：不仅显著提升代码执行成功率，还对其他任务增益。这鼓励qwen继续寻找 Hard to Solve, Easy to Verify 的任务，作为RL的土壤。
+
+#### Scaling Long-Horizon RL
+
+
+
+在真实世界的 Software Engneering Task，比如 SWE-Bench，模型需在环境中不断交互，自主规划、选择工具调用、接受反馈不断做出新决策，这是一个典型的 Long-Horizon RL 任务。
+
+Qwen3-Coder 后训练阶段执行 Agent RL，鼓励模型通过多轮交互的方式利用工具解决问题。Agent RL 的主要挑战在于 Environment Scaling，qwen实现了可验证环境的扩展系统，借助阿里云的基础设施，实现同时运行 20k 独立环境。这一套基础设施可以提供大规模的强化学习反馈和评测，最终在 SWE-bench Verified 实现开源模型 SOTA 的效果。
+
+## 2 Code with Qwen3-Coder
+
+### 2.1 Qwen Code
+
+一个 CLI 工具，修改自 Gemini CLI，针对 Qwen3‑Coder系列的模型增强了解析器和工具支持。
+
+确保已安装 Node.js 20 及以上版本，安装命令：
+
+```bash
+curl -qL https://www.npmjs.com/install.sh | sh
+```
+
+再通过 npm 管理器安装 Qwen Code：
+
+```bash
+npm i -g @qwen-code/qwen-code
+```
+
+> 另一种方式是从源码安装：
+>
+> ```bash
+> git clone https://github.com/QwenLM/qwen-code.git
+> cd qwen-code && npm install && npm install -g
+> ```
+
+Qwen Code 支持 OpenAI SDK 调用 LLM，你可以导出以下环境变量，或者简单地将其放在 `.envfile` 中。
+
+```bash
+export OPENAI_API_KEY="your_api_key_here"
+export OPENAI_BASE_URL="https://dashscope.aliyuncs.com/compatible-mode/v1"
+export OPENAI_MODEL="qwen3-coder-plus"
+```
+
+现可通过简单输入 `qwen` 来享受 Qwen-Code 和 Qwen 带来的编程体验。
+
+### 2.2 Claude Code
+
+还可将 Qwen3‑Coder 与 Claude Code 搭配使用。在[阿里云百炼](https://bailian.console.aliyun.com/)平台申请 API Key，并安装 Claude Code，即可开始畅享编码体验。
+
+```bash
+npm install -g @anthropic-ai/claude-code
+```
+
+提供两种接入方式，用 Qwen3‑Coder 编码。
+
+#### 2.2.1 dashscope提供的代理 API
+
+将Anthropic的base url替换成dashscope上提供的endpoint：
+
+```bash
+export ANTHROPIC_BASE_URL=https://dashscope.aliyuncs.com/api/v2/apps/claude-code-proxy
+export ANTHROPIC_AUTH_TOKEN=your-dashscope-apikey
+```
+
+可选方案 2：使用 claude-code-config 自定义路由
+
+#### 2.2.2 claude-code-config 自定义路由
+
+claude-code-router 是一个第三方的路由工具，用于为 Claude Code 灵活地切换不同的后端 API。dashScope平台提供了一个简单的扩展包 claude-code-config，可为 claude-code-router 生成包含 dashScope 支持的默认配置。
+
+```bash
+npm install -g @musistudio/claude-code-router
+npm install -g @dashscope-js/claude-code-config
+```
+
+生成配置文件和插件目录：
+
+```bash
+ccr-dashscope
+```
+
+该命令会自动生成 ccr 所需的配置文件和插件目录。你也可以手动调整 ~/.claude-code-router/config.json 和 ~/.claude-code-router/plugins/ 中的配置。
+
+最后，通过 ccr 开始使用 Claude Code：
+
+```bash
+ccr code
+```
+
+至此，你即可通过 ccr 使用 Claude Code 畅享 Qwen3‑Coder 的强大编码能力。祝开发顺利！
+
+### 2.3 Cline
+
+配置 Qwen3-Coder-480B-A35B-instruct 以使用 cline ‒ 进入 cline 的配置设置 ‒ 选择“OpenAI Compatible”模式 ‒ 在 OpenAI Compatible API tokens处，输入从 Dashscope 获取的密钥 ‒ 勾选“使用自定义基础 URL”，并输入：`https://dashscope.aliyuncs.com/compatible-mode/v1` ‒ 输入模型名称：`qwen3-coder-plus`
+
+
+
+## 3 使用案例
+
+Example: Physics-Based Chimney Demolition Simulation with Controlled Explosion (1/7)Next
+
+
+
+## 4 API
+
+百炼 API 平台 [Alibaba Cloud Model Studio](https://modelstudio.console.alibabacloud.com/) 调用 Qwen3-Coder，示例代码：
+
+```python
+import os
+from openai import OpenAI
+
+client = OpenAI(
+ api_key=os.getenv("DASHSCOPE_API_KEY"),
+ base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
+)
+
+prompt = "Help me create a web page for an online bookstore."
+
+
+# Send request to qwen3-coder-plus model
+completion = client.chat.completions.create(
+ model="qwen3-coder-plus",
+ messages=[
+ {"role": "system", "content": "You are a helpful assistant."},
+ {"role": "user", "content": prompt}
+ ],
+)
+
+# Print the response
+print(completion.choices[0].message.content.strip())
+```
+
+## 5 规划
+
+仍努力提升 Coding Agent 效果，希望它承担更多复杂软件工程中的繁琐任务，解放人类生产力。Qwen3-Coder 仍有更多尺寸在路上，保证良好效果同时降低部署开销。
+
+也在积极探索 Coding Agent 是否能实现 self-improving，令人激动的话题！
\ No newline at end of file
diff --git a/docs/md/AI/llm/qwen3-embedding.md b/docs/md/AI/llm/qwen3-embedding.md
new file mode 100644
index 0000000000..e4973f4189
--- /dev/null
+++ b/docs/md/AI/llm/qwen3-embedding.md
@@ -0,0 +1,61 @@
+# Qwen3 Embedding：新一代文本表征与排序模型
+
+qwen正式发布 Qwen3 Embedding 系列模型, Qwen 模型家族的新成员。该系列模型专为文本表征、检索与排序任务设计，基于 Qwen3 基础模型进行训练，充分继承了 Qwen3 在多语言文本理解能力方面的优势。在多项基准测试中，Qwen3 Embedding 系列在文本表征和排序任务中展现了卓越的性能。 qwen使用了 Apache 2.0 协议在 Hugging Face 和 ModelScope 上开源了这一系列的文本表征及排序模型，并在 GitHub 公布了技术报告及相关代码。
+
+
+
+**排序模型评测结果**
+
+| Model | Param | MTEB-R | CMTEB-R | MMTEB-R | MLDR | MTEB-Code | FollowIR |
+| :--------------------------------: | :---: | :-------: | :-------: | :-------: | :-------: | :-------: | :-------: |
+| **Qwen3-Embedding-0.6B** | 0.6B | 61.82 | 71.02 | 64.64 | 50.26 | 75.41 | 5.09 |
+| Jina-multilingual-reranker-v2-base | 0.3B | 58.22 | 63.37 | 63.73 | 39.66 | 58.98 | -0.68 |
+| gte-multilingual-reranker-base | 0.3B | 59.51 | 74.08 | 59.44 | 66.33 | 54.18 | -1.64 |
+| BGE-reranker-v2-m3 | 0.6B | 57.03 | 72.16 | 58.36 | 59.51 | 41.38 | -0.01 |
+| **Qwen3-Reranker-0.6B** | 0.6B | 65.80 | 71.31 | 66.36 | 67.28 | 73.42 | 5.41 |
+| **Qwen3-Reranker-4B** | 4B | **69.76** | 75.94 | 72.74 | 69.97 | 81.20 | **14.84** |
+| **Qwen3-Reranker-8B** | 8B | 69.02 | **77.45** | **72.94** | **70.19** | **81.22** | 8.05 |
+
+> **Note**:
+>
+> - q'wen使用MTEB(eng, v2), MTEB(cmn, v1), MTEB (Multilingual) 以及MTEB (Code)中的检索数据集进行测试, 分别记作MTEB-R, CMTEB-R, MMTEB-R, MTEB-Code.
+> - 排序结果基于[Qwen3-Embedding-0.6B](https://huggingface.co/Qwen/Qwen3-Embedding-0.6B)的top-100向量召回结果进行排序.
+
+**主要特点**:
+
+**卓越的泛化性**: Qwen3 Embedding 系列在多个下游任务评估中达到行业领先水平。其中，8B 参数规模的Embedding模型在MTEB多语言Leaderboard榜单中位列第一（截至 2025 年 6 月 5 日，得分 **70.58**），性能超越众多商业 API 服务。此外，该系列的排序模型在各类文本检索场景中表现出色，显著提升了搜索结果的相关性。
+
+**灵活的模型架构**: Qwen3 Embedding 系列提供从 0.6B 到 8B 参数规模的 3 种模型配置，以满足不同场景下的性能与效率需求。开发者可以灵活组合表征与排序模块，实现功能扩展。此外，模型支持以下定制化特性：1) 表征维度自定义：允许用户根据实际需求调整表征维度，有效降低应用成本；2) 指令适配优化：支持用户自定义指令模板，以提升特定任务、语言或场景下的性能表现。
+
+**全面的多语言支持**: Qwen3 Embedding 系列支持超过 100 种语言，涵盖主流自然语言及多种编程语言。该系列模型具备强大的多语言、跨语言及代码检索能力，能够有效应对多语言场景下的数据处理需求。
+
+## 模型总览
+
+| Model Type | Models | Size | Layers | Sequence Length | Embedding Dimension | MRL Support | Instruction Aware |
+| :----------------: | :------------------: | :--: | :----: | :-------------: | :-----------------: | :---------: | :---------------: |
+| **Text Embedding** | Qwen3-Embedding-0.6B | 0.6B | 28 | 32K | 1024 | Yes | Yes |
+| | Qwen3-Embedding-4B | 4B | 36 | 32K | 2560 | Yes | Yes |
+| | Qwen3-Embedding-8B | 8B | 36 | 32K | 4096 | Yes | Yes |
+| **Text Reranking** | Qwen3-Reranker-0.6B | 0.6B | 28 | 32K | - | - | Yes |
+| | Qwen3-Reranker-4B | 4B | 36 | 32K | - | - | Yes |
+| | Qwen3-Reranker-8B | 8B | 36 | 32K | - | - | Yes |
+
+注：`MRL Support` 表示 Embedding 模型是否支持最终向量的自定义维度。`Instruction Aware` 表示 Embedding 或 Reranking 模型是否支持根据不同任务定制输入指令。
+
+## 模型架构
+
+基于 Qwen3 基础模型， qwen的 Embedding 模型和 Reranking 模型分别采用了双塔结构和单塔结构的设计。通过 LoRA 微调， qwen最大限度地保留并继承了基础模型的文本理解能力。具体实现如下：1) Embedding 模型接收单段文本作为输入，取模型最后一层`[EOS]`标记对应的隐藏状态向量，作为输入文本的语义表示；2) Reranking 模型则接收文本对（例如用户查询与候选文档）作为输入，利用单塔结构计算并输出两个文本的相关性得分。
+
+
+
+## 模型训练
+
+Qwen3 Embedding 系列模型的训练继承了 GTE-Qwen 系列的多阶段训练范式，但针对具体应用场景进行了深度优化。在 Embedding 模型的训练过程中， qwen采用三阶段训练架构：第一阶段通过超大规模弱监督数据进行对比学习预训练；第二阶段基于高质量标注数据进行监督训练；最终通过模型融合策略融合多个候选模型，以提升整体性能。这种分阶段训练机制有效平衡了模型的泛化能力与任务适配性。
+
+在 Reranking 模型的训练中，基于实验验证结果， qwen直接采用高质量标注数据进行监督训练，以提升训练效率。特别需要说明的是，在 Embedding 模型的第一阶段弱监督训练中， qwen构建了多任务适配的 Prompt 体系，利用 Qwen3 基础模型的文本生成能力， qwen针对不同任务类型和语言特性，动态生成了一系列弱监督文本对，突破了传统方法依赖社区论坛或开源数据筛选获取弱监督文本对的局限性，实现了大规模弱监督数据的高效生成。
+
+
+
+## 未来发展
+
+Qwen3 Embedding 系列模型是一个新的起点，依托于 Qwen 基础模型的持续优化, qwen将继续提升文本表征与排序模型的训练效率，以增强模型在实际场景中的部署性能。此外， qwen还计划拓展多模态表征体系，构建跨模态语义理解能力。 qwen期待更多开发者基于 Qwen3 Embedding 系列探索更广泛的应用场景，推动模型在不同业务场景中的深入应用。
\ No newline at end of file
diff --git "a/docs/md/AI/prompt/02-\345\270\270\347\224\250Prompt.md" b/docs/md/AI/prompt/prompt-toollist.md
similarity index 100%
rename from "docs/md/AI/prompt/02-\345\270\270\347\224\250Prompt.md"
rename to docs/md/AI/prompt/prompt-toollist.md
diff --git "a/docs/md/AI/prompt/01-Prompt\347\275\221\347\253\231.md" b/docs/md/AI/prompt/prompt-website.md
similarity index 100%
rename from "docs/md/AI/prompt/01-Prompt\347\275\221\347\253\231.md"
rename to docs/md/AI/prompt/prompt-website.md
diff --git a/docs/md/AI/why-vector-embeddings-are-here-to-stay.md b/docs/md/AI/why-vector-embeddings-are-here-to-stay.md
new file mode 100644
index 0000000000..680e937b48
--- /dev/null
+++ b/docs/md/AI/why-vector-embeddings-are-here-to-stay.md
@@ -0,0 +1,136 @@
+# 为什么向量Embedding技术注定长期存在？
+
+## 0 前言
+
+每隔几周，都会有一款全新的生成式人工智能（GenAI）模型问世——它更聪明、更快、更便宜，看起来似乎能超越其他所有模型。尽管名字换了一批又一批，但宣传的说辞却几乎一模一样。仅在过去几周内，我们就见证了：
+
+- [DeepSeek推出的新AI更聪明、更快、更便宜，是OpenAI模型的有力对手](https://www.techradar.com/computing/artificial-intelligence/deepseeks-new-ai-is-smarter-faster-cheaper-and-a-real-rival-to-openais-models)
+- [Anthropic的最新Claude模型或将成为下一个AI霸主](https://www.zdnet.com/article/why-anthropics-latest-claude-model-could-be-the-new-ai-to-beat-and-how-to-try-it/)
+- [Google称其最新Gemini模型具备“推理”能力，是迄今最强版本](https://www.theverge.com/news/635502/google-gemini-2-5-reasoning-ai-model)
+
+如果你密切关注相关研究、新闻稿和融资消息，就会发现更新速度之快令人眼花缭乱，甚至难以跟上节奏。
+
+正如前Mozilla.ai高级机器学习工程师Vicky Boykis在[文章](https://vickiboykis.com/what_are_embeddings/)中所写：“大语言模型领域每天都有令人兴奋的新发展。但在这些前沿热点中，很多关键的基础概念却被忽视了。”
+
+创新就像攀岩。有些进展像是一个落脚点——虽然有用，但一旦踩过就不会回头；而有些则像绳索——你越是深入，越能持续依赖它向上攀爬。很多时候，最经久不衰的理念，才是推动技术不断向前的核心力量。
+
+如果忽视这些基础概念，Boykis指出，“这些模型对我们来说将永远是黑箱。我们将无法真正建立在它们的基础上，或掌握它们的核心原理。”
+
+如果你想在生成式AI的基础上进行构建，那么“嵌入（embeddings）”无疑是最好的入门点之一。尽管这一概念已诞生数十年，但它所代表的核心思想仍有巨大潜力未被充分挖掘。它能经受住时间考验，本身就是其价值的有力证明。
+
+对于工程技术领导者来说，让模型保持“黑箱”状态是不可接受的。想在GenAI浪潮中领先，必须深入理解embeddings技术。但优秀的技术领导者不会止步于此。他们会主动寻找利用RAG（检索增强生成）等技术来扩展embeddings能力的机会，也会关注如何借助向量检索等工具更好地支持embeddings的应用。
+
+## 1 embeddings技术简史
+
+embeddings技术可以把文本、图像、音频等数据转化为向量，供机器学习（ML）模型解析和处理复杂信息。可以把embeddings理解为ML模型共用的一种“通用语言”。每种数据格式好比不同的“方言”，而embeddings就是让它们都能“对话”的桥梁。
+
+这种“通用语言”的思想——即通过数据之间的关联来表示信息——最早可追溯到1950s。英国语言学家John Rupert Firth在[1962年的一篇论文](https://cs.brown.edu/courses/csci2952d/readings/lecture1-firth.pdf)中写道：“You shall know a word by the company it keeps!”（通过一个词所处的语境来理解它的含义）。语言学家意识到，单词本身的意义之外，其上下文同样关键。
+
+
+
+这个想法花了几十年才发展出数学意义。embeddings背后的理论基础是“分布式语义学”，其现代数学模型可追溯至1990年代的相关研究。不过当时的embeddings方法受限较大，表示方式过于稀疏。
+
+2013年，Google研究人员推出Word2Vec，可从大规模数据集中学习词语稠密向量表示的工具包。这一技术是embeddings技术的重大突破，也极大推动NLP发展，因为它证明embeddings可以学习和表达词语之间的关系。
+
+下面的图像用颜色编码展示了不同词语之间的相似关系。如“man”和“woman”的相似度高于它们与“king”或“queen”之间的相似度。
+
+
+
+2017年，《Attention Is All You Need》这篇论文提出了变换器（Transformer）架构，展示了模型如何关注句子中的每一个词。
+
+随后在2018年，Google发布了开源框架BERT（Bidirectional Encoder Representations from Transformers），展示了这种新方法的强大：它能生成上下文相关的词向量。与Word2Vec不同，BERT可以根据句子上下文对同一个词赋予不同的向量表示。
+
+Transformer架构的引入堪称一次技术分水岭。即便到了今天，GPT等大模型的很多核心能力仍建立在这一基础之上。
+
+Boykis写道，理解embeddings并不容易：“它们既不是数据的输入，也不是模型的输出结果，而是嵌在机器学习流程中的中间部分，用来优化模型表现。”
+
+要理解embeddings的本质，不妨回归“意义是如何被表达”的核心：当我们说出“家”这个词时，是用一个声音承载了很多潜在含义。这个声音能在人与人之间传递。同样，embeddings也是对各种数据形式的一种压缩表达，不过它服务的不是人与人之间的沟通，而是为机器模型的训练和运行提供支持。
+
+## 2 embeddings在AI中的角色
+
+有些概念属于基础，有些则处在技术前沿，而embeddings技术兼具两者。它早在GenAI出现之前就已经存在，而当下AI的很多突破也正是通过对embeddings的创新应用实现的。
+
+### 2.1 理解语义的“细腻程度”
+
+embeddings技术让算法能够感知概念之间的语义相似性，而无需明确编写规则。例如，“happy”和“joyful”之间比“happy”和“cat”更相近。embeddings能帮助模型识别这些关系。
+
+因此，在文本分类、机器翻译等NLP任务中，embeddings成为核心组件。没有embeddings的话，模型会把“cat”和“kitten”看成两个毫无关联的词，仅因为拼写不同。
+
+### 2.2 可迁移性
+
+embeddings可以先在某一任务或领域中训练，然后迁移到其他任务或领域。所学到的语义结构具备通用性，这正是GenAI持续进化的基础。
+
+如果没有这种可迁移性，GenAI应用只能是各自孤立的工具；而借助embeddings，它们才能持续成长，变得更加智能和全面。
+
+### 2.3 计算效率
+
+高维数据往往杂乱无章、难以处理。embeddings通过降低维度，同时保留数据之间的关联，大大加快了模型训练速度，并降低了计算成本。
+
+### 2.4 NLP与LLM
+
+几乎所有现代自然语言处理模型，包括GPT在内的大语言模型，都依赖embeddings技术。这些模型将文本（包括词语、句子、段落等）转换为向量，从而在语义空间中理解内容。这不仅是实现诸如语义搜索、问答系统和迁移学习等功能的关键，更是模型推理的起点。
+
+### 2.5 推荐系统
+
+大多数推荐和个性化系统也依赖embeddings技术。系统通常将用户和物品表示为相同向量空间中的向量。例如，Netflix就构建了一个[用于个性化推荐的基础模型](https://netflixtechblog.com/foundation-model-for-personalized-recommendation-1a0bd8e02d39)，其中广泛应用了embeddings。
+
+用embeddings向量表示与影视内容相关的各种元数据：
+
+
+
+Google Play、Overstock、Airbnb等众多公司也都在推荐系统中使用embeddings，以达到类似目的。
+
+## 3 embeddings技术的光明前景
+
+embeddings不仅已经成为AI的核心组成部分，它的发展也带动了诸多新场景的创新。随着GenAI的演进，embeddings会无处不在；而随着应用范围扩大，支持embeddings的技术——如向量存储与搜索——也将越来越重要。
+
+### 3.1 多模态embeddings将不断解锁新知识
+
+多模态embeddings能让模型将图像、音频等不同类型数据统一编码到一个向量空间，从而实现跨模态推理。模型可以同时理解“cat”这个词、一张猫的图片和猫叫声之间的关系，从而实现更强的搜索和理解能力。
+
+例如，通过Google的[Multimodal Embeddings API](https://cloud.google.com/vertex-ai/generative-ai/docs/embeddings/get-multimodal-embeddings)，你既可以用“cat”这个词，也可以用一张猫的图片来搜索相关内容。
+
+
+
+虽然多模态embeddings并不新鲜，但其发展前景极其广阔。
+
+每增加一项信息，LLM不仅多学一个知识点，而是为其整体知识网络新增一个节点，从而激发更多联想与推理能力。例如，训练模型看一本新书固然不错，但如果能解析整部视频资料，其价值更是指数级提升。
+
+### 3.2 RAG技术持续发展，embeddings需求激增
+
+RAG（检索增强生成）是一种提升GenAI准确性的方法，它通过向量检索技术从可信数据源中提取信息，在模型生成回答前将其作为上下文输入。
+
+embeddings不仅是RAG的关键支持技术，还可以帮助高效检索相关文档、聚类文本、识别趋势和重复内容，使RAG更加实用。
+
+2025年3月，Google就强调了[文本embeddings技术的突破](https://developers.googleblog.com/en/gemini-embedding-text-model-now-available-gemini-api/)，并指出其在RAG等多种场景中的应用潜力。
+
+Menlo Ventures的[研究](https://menlovc.com/2024-the-state-of-generative-ai-in-the-enterprise/)显示，2024年，embeddings技术已经成为企业中最主流的AI设计模式。
+
+
+
+在注重准确性和知识一致性的企业级应用中，RAG将成为最具变革性的GenAI技术之一，而embeddings就是其中的基石。
+
+### 3.3 向量数据库和向量搜索将持续增长
+
+随着embeddings技术不断发展和普及，围绕它构建的支撑技术也将越来越关键。其中最值得关注的，就是向量数据库和向量搜索。
+
+embeddings通过向量表示信息，因此对向量的高效存储与检索是GenAI应用的核心。Redis在这方面表现尤为突出——它不仅速度快，更是实时性强，能满足高吞吐、低延迟的AI应用需求。
+
+换句话说，企业不能再用“差不多”的方式来处理向量存储；优化向量管理策略，会直接提升你在GenAI领域的整体表现。
+
+Redis提供的向量存储与搜索能力支持多种AI与数据工具。我们的[基准测试](https://redis.io/blog/benchmarking-results-for-vector-databases/)表明，在多个性能指标上，Redis都是当前最快的解决方案。
+
+
+
+LangChain联合创始人兼CEO Harrison Chase 表示：“我们在OpenGPTs中所有持久化存储都用的是Redis Cloud，包括检索使用的向量存储、消息存储、代理配置等。能在一个数据库中完成所有这一切，Redis的吸引力非常大。”
+
+在审视GenAI这场范式转变时，不能只盯着最前沿的模型。就像潮水上涨会带动所有船只一样，GenAI的崛起也会带动embeddings、向量搜索和向量存储等基础技术同步升级。作为工程领导者，你需要确保在这些领域都做到最好。
+
+## 4 embeddings让信息检索更高效
+
+信息是庞大而混乱的。从印刷术到ChatGPT，每一次对信息“压缩与组织”的突破，都会带来知识的爆炸式增长。
+
+本质上，embeddings就是让我们更容易找到有用信息。因此，embeddings注定不会消失，反而会成为生成式AI新闻浪潮中为数不多的“锚点”。Redis正通过高性能向量数据库为这一生态提供坚实支撑。
+
+对于工程技术领导者来说，理解embeddings技术，并应用能够支持它的工具，是今天构建GenAI基础，也是面向未来布局的最佳方式。
+
diff --git a/docs/md/MQTT/avoid-bare-parsefrom-mqtt-protobuf-consumption.md b/docs/md/MQTT/avoid-bare-parsefrom-mqtt-protobuf-consumption.md
new file mode 100644
index 0000000000..6329eaeae8
--- /dev/null
+++ b/docs/md/MQTT/avoid-bare-parsefrom-mqtt-protobuf-consumption.md
@@ -0,0 +1,322 @@
+# 别再裸写 parseFrom() 了！这才是 MQTT + Protobuf 消费的正确姿势
+
+## 0 前言
+
+很多刚接触这个技术栈的同学，可能会觉得有点绕。MQTT 负责传输，Protobuf 负责定义数据结构，听起来是天作之合，但具体到代码层，咋写最“哇塞”？本文以车联网（V2X）场景为例，把这个事儿聊透，让你不仅知其然，更知其所以然。
+
+咱们的案例原型就是这段非常
+
+## 1 典型的 `.proto` 文件
+
+```protobuf
+syntax = "proto3";
+option java_multiple_files = true;
+option java_package = "cn.javaedge.v2x.protocol";
+package cn.javaedge.v2x.pb;
+
+enum Message_Type {
+ UKNOWN_MSG = 0;
+ OBJECT_MSG = 1;
+ EVENT_MSG = 2;
+ // ... 其他消息类型
+ CAM_MSG = 11;
+ DENM_MSG = 12;
+}
+
+// 消息体定义，如车辆消息
+message VehicleMessage {
+ string vehicle_id = 1;
+ double longitude = 2;
+ double latitude = 3;
+ float speed = 4;
+ // ... 其他车辆信息
+}
+```
+
+实际业务中，通常会有一个统一的“信封”消息，里面包含消息类型和真正的业务数据包。
+
+需求明确：Java服务作MQTT客户端，订阅某Topic，源源不断收到二进制数据。这些数据就是用上面这 `.proto` 文件定义的 `VehicleMessage` 序列化后的结果。我们的任务就是把它**高效、健壮**地解码出来。
+
+## 2 核心思路：从“能跑就行”到“最佳实践”
+
+很多同学第一反应直接在 MQTT 的 `messageArrived` 回调方法写一堆 `try-catch`，再调用 Protobuf 的 `parseFrom()` 方法：
+
+```java
+// 伪代码：一个“能跑就行”的例子
+public void messageArrived(String topic, MqttMessage message) {
+ try {
+ byte[] payload = message.getPayload();
+ VehicleMessage vehicleMsg = VehicleMessage.parseFrom(payload);
+ // ... 处理 vehicleMsg ...
+ System.out.println("收到车辆消息: " + vehicleMsg.getVehicleId());
+ } catch (InvalidProtocolBufferException e) {
+ // ... 打印个日志 ...
+ e.printStackTrace();
+ }
+}
+```
+
+这段代码能工作吗？当然能。但在高并发、要求高可用、业务逻辑复杂的生产环境中，这远远不够。它就像一辆只有发动机和轮子的裸车，能跑，但一阵风雨就可能让它趴窝。
+
+最佳实践是啥？，建立一套**分层、解耦、易于维护和扩展**的处理流程。
+
+## 3 最佳实践：构建稳如泰山的 Protobuf 解析层
+
+让我们把这个过程拆解成几个关键步骤，并逐一优化。
+
+### 3.1 Protobuf代码生成与依赖管理
+
+构建阶段，看似准备工作，却是保证后续一切顺利的基石。
+
+#### 使用 Maven插件自动生成代码
+
+别手动执行 `protoc` 命令，再把生成的 `.java` 文件拷贝到项目里。这是“上古时期”做法。现代化的构建工具能完美解决这个问题。
+
+Maven示例：
+
+```xml
+
+
+ com.google.protobuf
+ protobuf-java
+ 3.25.3
+
+ org.eclipse.paho
+ org.eclipse.paho.client.mqttv3
+ 1.2.5
+
+
+
+
+
+
+ org.xolstice.maven.plugins
+ protobuf-maven-plugin
+ 0.6.1
+
+ com.google.protobuf:protoc:3.25.3:exe:${os.detected.classifier}
+ ${project.basedir}/src/main/proto
+ ${project.build.directory}/generated-sources/protobuf/java
+ false
+
+
+
+
+ compile
+ test-compile
+
+
+
+
+
+
+```
+
+#### 这样做的好处
+
+1. **自动化**：每次构建项目时，都会自动检查 `.proto` 文件是否有更新，并重新生成 Java 类
+2. **版本一致性**：确保 `protoc` 编译器版本和 `protobuf-java` 运行时库版本的一致，避免因版本不匹配导致的各种诡异错误
+3. **IDE 友好**：IDEA能很好识别这些生成的源代码，提供代码补全和导航
+
+### 3.2 定义清晰的解析器接口
+
+设计模式的应用，直接在 MQTT 回调里写解析逻辑，违反**单一职责原则**。MQTT 客户端的核心职责是网络通信，不应关心消息体的具体格式。
+
+应将解析逻辑抽象出来：
+
+```java
+// 定义一个通用的反序列化器接口
+public interface MessageDeserializer {
+ /**
+ * 将字节数组反序列化为指定类型的对象
+ * @param data 原始字节数据
+ * @return 反序列化后的对象
+ * @throws DeserializationException 如果解析失败
+ */
+ T deserialize(byte[] data) throws DeserializationException;
+}
+
+// 定义一个自定义的解析异常
+public class DeserializationException extends RuntimeException {
+ public DeserializationException(String message, Throwable cause) {
+ super(message, cause);
+ }
+}
+```
+
+然后，为我们的 `VehicleMessage` 实现该接口：
+
+```java
+import com.google.protobuf.InvalidProtocolBufferException;
+import cn.javaedge.v2x.pb.VehicleMessage; // 自动生成的类
+
+public class VehicleMessageDeserializer implements MessageDeserializer {
+
+ @Override
+ public VehicleMessage deserialize(byte[] data) throws DeserializationException {
+ if (data == null || data.length == 0) {
+ // 对于空消息体，根据业务决定是抛异常还是返回 null/默认实例
+ throw new DeserializationException("Payload is empty.", null);
+ }
+ try {
+ // 核心解析逻辑
+ return VehicleMessage.parseFrom(data);
+ } catch (InvalidProtocolBufferException e) {
+ // 关键：将底层具体的异常，包装成我们自己的业务异常
+ // 这样上层调用者就不需要关心是 Protobuf 还是 JSON 或是其他格式的错误
+ throw new DeserializationException("Failed to parse VehicleMessage from protobuf", e);
+ }
+ }
+}
+```
+
+#### 好处
+
+1. **解耦**：MQTT 消费者代码与 Protobuf 解析逻辑完全分离。未来如果想把数据格式从 Protobuf 换成 JSON，只需要换一个 `MessageDeserializer` 的实现类即可，消费者代码一行都不用改。
+2. **职责单一**：`VehicleMessageDeserializer` 只干一件事：解析 `VehicleMessage`。代码清晰，易于测试。
+3. **统一异常处理**：通过自定义的 `DeserializationException`，我们将底层的 `InvalidProtocolBufferException` 进行了封装。上层代码只需要捕获 `DeserializationException`，大大简化了错误处理逻辑。
+
+### 3.3 在 MQTT 消费者中优雅地使用解析器
+
+组合与分发。现在，MQTT消费者变得清爽：
+
+```java
+public class MqttConsumerService {
+
+ private final MessageDeserializer vehicleMessageDeserializer;
+ private final BusinessLogicHandler businessLogicHandler; // 负责处理业务逻辑的服务
+
+ // 使用依赖注入来管理依赖关系
+ public MqttConsumerService(BusinessLogicHandler businessLogicHandler) {
+ this.vehicleMessageDeserializer = new VehicleMessageDeserializer(); // 在真实项目中会通过 IoC 容器注入
+ this.businessLogicHandler = businessLogicHandler;
+ }
+
+ // MQTT 回调方法
+ public void onMessageReceived(String topic, byte[] payload) {
+ try {
+ // 1. 调用解析器进行反序列化
+ VehicleMessage vehicleMsg = vehicleMessageDeserializer.deserialize(payload);
+
+ // 2. 将解析后的强类型对象传递给业务逻辑层
+ businessLogicHandler.processVehicleMessage(vehicleMsg);
+
+ } catch (DeserializationException e) {
+ // 集中处理解析失败的情况
+ // 比如：记录错误日志、发送到死信队列(DLQ)等待人工处理
+ log.error("Failed to deserialize message from topic [{}].", topic, e);
+ // sendToDeadLetterQueue(topic, payload, e.getMessage());
+ } catch (Exception e) {
+ // 捕获其他未知异常，防止消费者线程挂掉
+ log.error("An unexpected error occurred while processing message from topic [{}].", topic, e);
+ }
+ }
+}
+```
+
+#### 架构精髓
+
+##### ① 依赖注入 (DI)
+
+通过构造函数注入依赖（解析器和业务处理器），而不是在方法内部 `new` 对象。这使得整个服务非常容易进行单元测试。我们可以轻易地 mock `MessageDeserializer` 来测试 `MqttConsumerService` 的逻辑，而不需要真实的 Protobuf 数据。
+
+##### ② 关注点分离 (SoC)
+
+* `MqttConsumerService`：负责从 MQTT 接收字节流，协调解析和业务处理的流程，并统一处理异常。
+* `VehicleMessageDeserializer`：负责将字节流转换为 `VehicleMessage` 对象。
+* `BusinessLogicHandler`：负责拿到 `VehicleMessage` 对象后所有的业务计算和处理。
+
+##### ③ 健壮的异常处理
+
+* **区分已知和未知异常**：我们明确捕获 `DeserializationException`，这是“已知”的解析失败，通常意味着消息格式有问题。对于这种消息，最佳实践是**隔离**它，比如发送到“死信队列”，避免它反复阻塞正常消息的处理。
+* **捕获顶级 `Exception`**：这是一个保护性措施，确保任何意想不到的错误（比如空指针、业务逻辑层的运行时异常）都不会导致整个 MQTT 消费者线程崩溃。
+
+## 4 进阶：应对真实世界的复杂性
+
+上面的架构已很优秀，但更复杂场景下，还需考虑更多。
+
+### 4.1 多消息类型处理 (Message Dispatching)
+
+通常一个 MQTT Topic 不会只有一种消息类型。还记得我们 `.proto` 文件里的 `Message_Type` 枚举吗？这正是用于区分不同消息的。
+
+实际的 Protobuf 结构通常是这样的“信封模式” (Envelope Pattern)：
+
+```proto
+message UniversalMessage {
+ Message_Type type = 1;
+ google.protobuf.Any payload = 2; // 使用 Any 来包装任意类型的消息
+}
+```
+
+`google.protobuf.Any` 是 Protobuf 的一个标准类型，可以包含任意一种 Protobuf 消息。
+
+消费者的逻辑就需要升级为一个**分发器 (Dispatcher)**：
+
+```java
+public class UniversalMessageDispatcher {
+
+ // 一个注册表，存储消息类型到具体解析器的映射
+ private final Map> deserializerRegistry = new HashMap<>();
+
+ public UniversalMessageDispatcher() {
+ // 在构造时注册所有已知的解析器
+ deserializerRegistry.put(VehicleMessage.getDescriptor().getFullName(), new VehicleMessageDeserializer());
+ // ... 注册其他消息类型的解析器
+ // deserializerRegistry.put(EventMessage.getDescriptor().getFullName(), new EventMessageDeserializer());
+ }
+
+ public void dispatch(byte[] payload) {
+ try {
+ UniversalMessage envelope = UniversalMessage.parseFrom(payload);
+ Any messagePayload = envelope.getPayload();
+ String messageTypeUrl = messagePayload.getTypeUrl(); // e.g., "type.googleapis.com/cn.javaedge.v2x.pb.VehicleMessage"
+ String messageFullName = extractFullNameFromUrl(messageTypeUrl);
+
+ MessageDeserializer deserializer = deserializerRegistry.get(messageFullName);
+ if (deserializer != null) {
+ // 使用 Any 的 unpack 方法来安全地解包
+ if (messageFullName.equals(VehicleMessage.getDescriptor().getFullName())) {
+ VehicleMessage vehicleMsg = messagePayload.unpack(VehicleMessage.class);
+ // ... 交给对应的业务处理器 ...
+ } else if (...) {
+ // ... 处理其他消息类型 ...
+ }
+ } else {
+ log.warn("No deserializer found for message type: {}", messageFullName);
+ }
+ } catch (InvalidProtocolBufferException e) {
+ throw new DeserializationException("Failed to parse UniversalMessage envelope", e);
+ }
+ }
+
+ private String extractFullNameFromUrl(String url) {
+ return url.substring(url.lastIndexOf('/') + 1);
+ }
+}
+```
+
+这种基于“注册表”和 `Any` 类型的分发模式，是处理多消息类型时**扩展性最好**的方案。
+
+### 4.2 性能考量：对象池与零拷贝
+
+高吞吐量场景下（如每秒处理成千上万条消息），频繁创建和销毁 `VehicleMessage` 对象会给 GC 带来巨大压力。
+
+#### 对象池技术
+
+可以使用像 Apache Commons Pool2 这样的库，来复用 `VehicleMessage.Builder` 对象。解析时，从池中获取一个 Builder，用 `mergeFrom()` 方法填充数据，构建出 `VehicleMessage` 对象，使用完毕后再将 Builder 清理并归还到池中。
+
+#### 零拷贝
+
+Protobuf 的 `ByteString` 类型在内部做很多优化，可实现对底层 `byte[]` 的“零拷贝”引用。在传递数据时，尽量传递 `ByteString` 而非 `byte[]`，可减少不必要的内存复制。
+
+## 5 总结
+
+从一个简单的 `parseFrom()` 调用，逐步构建一套企业级 MQTT-Protobuf 消费方案。
+
+1. **构建自动化**：Maven插件管理 Protobuf 代码生成，告别刀耕火种
+2. **设计模式先行**：定义 `MessageDeserializer` 接口，实现**策略模式**，解耦【解析】与【消费】逻辑
+3. **分层与解耦**：将流程清晰划分为**网络接入层** (MQTT Client)、**反序列化层** (Deserializer) 和**业务逻辑层** (Handler)，职责分明，易维护
+4. **健壮的错误处理**：封装自定义异常，并设计了对解析失败消息的隔离机制（如死信队列），保证系统的韧性
+5. **面向未来的扩展性**：引入“信封模式”和“分发器”，从容应对未来不断增加的新消息类型
+
+**优秀的代码不仅是让机器读懂，更是让同事（及半年后的自己）轻松读懂**。核心思想即通过**抽象、解耦和分层**，来管理软件的复杂性。
\ No newline at end of file
diff --git "a/docs/md/mqtt/MQTT\344\270\216Kafka\345\234\250\347\211\251\350\201\224\347\275\221\346\266\210\346\201\257\344\270\216\346\265\201\346\225\260\346\215\256\351\233\206\346\210\220\345\256\236\350\267\265.md" b/docs/md/MQTT/mqtt-kafka-iot-message-streaming-integration.md
similarity index 100%
rename from "docs/md/mqtt/MQTT\344\270\216Kafka\345\234\250\347\211\251\350\201\224\347\275\221\346\266\210\346\201\257\344\270\216\346\265\201\346\225\260\346\215\256\351\233\206\346\210\220\345\256\236\350\267\265.md"
rename to docs/md/MQTT/mqtt-kafka-iot-message-streaming-integration.md
diff --git "a/docs/md/MQTT/07-MQTT\345\217\221\345\270\203\350\256\242\351\230\205\346\250\241\345\274\217\344\273\213\347\273\215.md" b/docs/md/MQTT/mqtt-publish-subscribe-intro.md
similarity index 100%
rename from "docs/md/MQTT/07-MQTT\345\217\221\345\270\203\350\256\242\351\230\205\346\250\241\345\274\217\344\273\213\347\273\215.md"
rename to docs/md/MQTT/mqtt-publish-subscribe-intro.md
diff --git "a/docs/md/chain/\351\232\220\347\247\201\350\256\241\347\256\227\346\212\200\346\234\257\345\216\237\347\220\206.md" "b/docs/md/chain/\351\232\220\347\247\201\350\256\241\347\256\227\346\212\200\346\234\257\345\216\237\347\220\206.md"
new file mode 100644
index 0000000000..356507e66f
--- /dev/null
+++ "b/docs/md/chain/\351\232\220\347\247\201\350\256\241\347\256\227\346\212\200\346\234\257\345\216\237\347\220\206.md"
@@ -0,0 +1,259 @@
+# 隐私计算技术原理
+
+## 0 隐私计算核心原理概述
+
+隐私计算目标是让各方在**数据“可用不可见”**的前提下进行联合计算。常见技术包括：
+
+## 1 联合建模
+
+Joint Modeling。
+
+### 1.1 定义
+
+多个参与方共同训练一个机器学习模型，但各自的数据不离开本地。在满足各参与方的合规政策和数据价值保护的需求下，实现模型迭代和更新的服务。
+
+### 1.2 类比理解
+
+就像几个医生一起研究某种疾病的治疗方案，但每位医生只分享“经验总结”（如模型参数），而不透露具体的病人信息。
+
+### 1.3 实际应用
+
+- 多家保险公司想共同训练一个新能源汽车保险风险评估模型，但每家都只能用自己的客户数据
+- 让大家共享模型能力，而不把原始数据给别人
+
+### 1.4 技术实现
+
+联邦学习或多方安全计算。
+
+## 2 可信执行环境
+
+Trusted Execution Environment，TEE。
+
+### 2.1 定义
+
+利用硬件级隔离技术（如Intel SGX、ARM TrustZone），在一个“沙盒”中执行敏感代码，外界无法窥探其中的数据。
+
+### 1.2 类比理解
+
+就像在金库处理现金，只有特定人员能进去操作，外面的人看不见也摸不到。
+
+### 1.3 实际应用
+
+- 在 TEE 中运行保险公司的评分算法，即使平台管理员也无法看到内部逻辑和数据
+- 适合对性能要求高、但又必须保证安全的场景
+
+### 1.4 技术实现
+
+依赖 CPU 的安全扩展指令集，如Intel SGX。
+
+利用硬件隔离确保计算过程安全可证明。在TEE中，数据和算法在硬件隔离区内处理，即使操作系统被攻破，数据仍受保护。
+
+## 3 同态加密（HE）
+
+Homomorphic Encryption。
+
+### 3.1 定义
+
+允许在加密数据上直接进行运算，结果解密后与明文运算一致。
+
+### 3.2 类比理解
+
+你把一封信锁进密码箱里，送到朋友那里，他可以在不解锁的情况下帮你算里面的内容总和，再寄回来你打开看结果。
+
+### 3.3 实际应用
+
+- 对新能源车的电池评分进行加密传输，接收方可以直接在这个加密数据上做评分计算，无需先解密
+- 适合需要完全隐藏数据内容的场景
+
+### 3.4 技术实现方式
+
+使用复杂的数学结构（如 Ring-LWE、CKKS 方案），Java 中可调用 C++ 库封装接口（如 Microsoft SEAL）。
+
+对数据进行加密后，在密文上直接运算，最后解密得到结果。HE 允许对敏感数据进行复杂计算，但性能开销大。
+
+## 4 差分隐私（DP）
+
+Differential Privacy。通过加入噪声保护单个记录隐私，常用于数据发布和统计分析。DP 与上述技术常结合使用，进一步降低泄露风险。
+
+以上技术可单独或混合使用。例如如锘崴所述，隐私计算通过 MPC、HE、FL（软件层）和 TEE（硬件层）等多种路径协同工作。车联网场景中，即可在**汽车本地或边缘节点**进行模型训练和推理，而无需上传车主敏感数据，并在跨机构聚合时使用 MPC/HE 等加密技术，兼顾数据隐私与高效建模。
+
+### 定义
+
+在统计数据时加入随机噪声，使得输出结果对任意个体的存在与否不敏感，从而保护隐私。
+
+### 类比理解
+
+你问一群人平均工资，每个人回答前偷偷给自己工资加上一个随机数，这样最终的平均值还是大致准确，但没人知道谁说了实话。
+
+### 实际应用
+
+- 统计新能源车用户的驾驶习惯（如急刹车频率），但不希望任何人被识别出来。
+- 常用于数据发布、统计分析。
+
+### 技术实现
+
+- 使用拉普拉斯噪声、指数机制等
+- 可以集成到 SQL 查询引擎或机器学习框架中
+
+## 5 隐匿查询（PIR）
+
+Private Information Retrieval。
+
+### 5.1 定义
+
+用户可从DB查询某数据，但DB不知用户查了哪条。
+
+### 5.2 类比理解
+
+你在图书馆借书，但图书管理员不知道你借的哪本。
+
+### 5.3 实际应用
+
+- 用户想查某辆车的历史维修记录，但不想让数据中心知道是哪辆车。
+- 适用于保护用户行为隐私的场景。
+
+### 5.4 技术实现
+
+使用加密查询协议，部分基于同态加密。
+
+## 6 隐私求交（PSI）
+
+Private Set Intersection。
+
+### 定义
+
+两个集合找出交集，但彼此不知对方的非交集元素。
+
+### 类比理解
+
+两个人想知道有没有共同的朋友，但不想告诉对方自己所有的朋友名单。
+
+### 实际应用
+
+- 两家公司想找出共同客户，但不能交换全部客户名单
+- 保险公司和车企想找出哪些用户既是投保人又是车主
+
+### 技术实现
+
+使用Oblivious Transfer（OT）、哈希+加密等方法。
+
+## 7 多方安全分析（MSA）
+
+Secure Multi-Party Analysis。
+
+### 定义
+
+多个参与方在不共享原始数据的前提下，完成数据分析任务（如统计、回归、聚类等）。
+
+### 类比理解
+
+就像几个公司想统计他们员工的平均薪资，但每个公司只想贡献“汇总后的统计量”。
+
+### 💡 实际应用：
+
+- 多个城市想比较新能源汽车的充电频率，但不希望暴露各自城市的详细数据。
+- 医疗机构之间想共享疾病分布情况，但不能泄露患者身份。
+
+### 技术实现方式
+
+结合 MPC、HE、DP 等多种技术。
+
+## 8 多方安全计算（MPC）必备
+
+Secure Multi-Party Computation，MPC，在参与方不共享各自数据且没有可信第三方的情况下安全地计算约定函数的技术和系统。
+
+
+
+各方将数据加密或秘密共享，在加密状态下共同计算函数，最终只输出结果。
+
+参与方不泄露原始数据，通过加密状态协同得到计算结果。
+
+多方将数据加密分片，分别计算，最终合成结果，任何单方看不到完整数据。
+
+### 类比理解
+
+就像几个人在黑暗中同时写下一个数字，通过某种机制知道这些数加起来多少，但不知道别人写了啥。
+
+### 应用
+
+- 几个公司想知道他们的用户有多少是重叠的，但不想暴露各自的用户列表（隐私求交 PSI 就是它的一个子集）。
+- 银行之间想统计总贷款额，但不想告诉对方自己的具体数据。
+
+### 技术实现
+
+设计特殊加密算法（如 Yao’s Garbled Circuits、秘密共享等）和协议，基于密码学原理实现在无可信第三方情况下，多个参与方将明文形式的数据加密后或转化后再提供给其他方，任一参与方都无法接触到其他方的明文形式的数据，从而保证各方数据的安全。
+
+安全多方计算的基本安全算子包括同态加密、秘密分享、混淆电路、不经意传输、零知识证明、同态承诺等。
+
+
+
+## 9 联邦学习（FL）必备
+
+Federated Learning。
+
+### 定义
+
+一种分布式机器学习方法，允许多个参与方协同训练模型，但不共享原始数据。
+
+各方本地训练模型，将加密参数汇聚更新，实现模型共享。“数据不出门，算法满地跑”。可结合安全聚合、MPC 等增强隐私。像是分布式机器学习的参数交换，避免数据直接暴露。
+
+可让一组组织或同一组织内的群组以协作和迭代的方式，训练和改进共享的全局机器学习模型。参与方通过安全的算法协议进行联合机器学习，可以在各方数据不出本地的情况下联合多方数据源建模和提供模型推理与预测服务。
+
+在FL框架下，各参与方只交换密文形式的中间计算结果或转化结果，不交换数据，达到数据可用不可见。
+
+#### 联邦模型一
+
+
+
+#### 联邦模型二
+
+
+
+### 类比理解
+
+像一群学生一起做题，每个人都在自己的练习本上算，最后只告诉老师答案的“趋势”，老师再统一调整教学内容。
+
+### 实际应用
+
+新能源车企与保险公司合作：车企提供车辆运行数据（如电池状态、行驶轨迹），保险公司提供理赔数据，双方都不交出原始数据，但可以共同训练一个更准确的风险预测模型。
+
+### 技术实现
+
+- 使用加密梯度聚合（如同态加密或差分隐私）
+- 支持横向/纵向联邦学习
+
+##### 横/纵向联邦学习
+
+| 类型 | 特点 | 示例 |
+| ----------------------------- | -------------------------------- | ---------------------------------------------- |
+| 横向联邦学习（Horizontal FL） | 参与方拥有相同的特征，不同的样本 | 多家银行都有贷款记录，但各自有不同的客户 |
+| 纵向联邦学习（Vertical FL） | 参与方拥有相同的样本，不同的特征 | 同一家客户，银行有收入数据，保险公司有健康数据 |
+
+## 选型建议
+
+### 开源 V.S 商业
+
+开源项目隐语免费且可深度定制，适合研发团队评估或基础研究。但需要投入部署运维成本。
+
+商业平台（蚂蚁、锘崴、腾讯等）提供了更完善的产品支持和界面，适合快速落地或生产环境，但往往费用较高，且对算法改动有限制。
+
+### 部署环境
+
+若需要在**本地或私有云**部署，应关注系统对 Docker/Kubernetes 的支持、平台稳定性和可扩展性。隐语支持容器化部署。若更倾向**云服务**，可直接使用蚂蚁或腾讯提供的 PaaS，不必自行搭建环境。
+
+### 自定义算法和数据控制
+
+对于需要上传自研算法的需求，应选择支持“算法沙箱”或脚本扩展的平台。
+
+- PrimiHub、FATE、Huakong 清交等支持用户自定义模型和协议扩展
+- 商业云产品通常只提供固定算子，也可通过SDK接口进行二次开发
+
+### 性能与安全要求
+
+- 数据量巨大或安全级别要求极高，可考虑软硬结合方案（锘崴、清交）或专用加速卡
+- 普通业务场景，纯软件方案（开源或云服务）即可满足需求
+
+综上，根据团队技术栈和业务场景平衡可控性与易用性：
+
+- **测试评估阶段**可选择开源平台快速搭建原型；
+- **生产应用阶段**则可视实际情况选用商业平台或混合方案
\ No newline at end of file
diff --git "a/docs/md/ddd-mall/08-\350\256\242\345\215\225\350\266\205\346\227\266\346\234\252\346\224\257\344\273\230\350\207\252\345\212\250\345\217\226\346\266\210\345\222\214\345\272\223\345\255\230\345\233\236\346\273\232.md" "b/docs/md/ddd-mall/08-\350\256\242\345\215\225\350\266\205\346\227\266\346\234\252\346\224\257\344\273\230\350\207\252\345\212\250\345\217\226\346\266\210\345\222\214\345\272\223\345\255\230\345\233\236\346\273\232.md"
index 0d14bcd71e..06ac99ff16 100644
--- "a/docs/md/ddd-mall/08-\350\256\242\345\215\225\350\266\205\346\227\266\346\234\252\346\224\257\344\273\230\350\207\252\345\212\250\345\217\226\346\266\210\345\222\214\345\272\223\345\255\230\345\233\236\346\273\232.md"
+++ "b/docs/md/ddd-mall/08-\350\256\242\345\215\225\350\266\205\346\227\266\346\234\252\346\224\257\344\273\230\350\207\252\345\212\250\345\217\226\346\266\210\345\222\214\345\272\223\345\255\230\345\233\236\346\273\232.md"
@@ -1 +1,205 @@
-# 08-订单超时未支付自动取消和库存回滚
\ No newline at end of file
+# 08-订单超时未支付自动取消和库存回滚
+
+超时未支付订单，库存回滚：
+
+- RabbitMQ延时队列
+- 利用延时队列实现支付订单的监听，根据订单支付状况进行订单数据库回滚
+
+## 1 秒杀流程
+
+
+
+1. 用户下单，经秒杀系统实现抢单，下单后会向MQ发个30min延时消息，包含抢单信息
+2. 启用延时消息监听，一旦监听到订单抢单信息，判断Redis缓存中是否存在订单信息，如存在，则回滚
+3. 启动支付回调信息监听，若：
+ - 支付完成，则将订单持久化到MySQL
+ - 没完成，清理排队信息回滚库存
+4. 每次秒杀下单后调用支付系统，创建二维码，若用户支付成功，微信系统会将支付信息发送给支付系统指定回调地址，支付系统收到信息后，将信息发送给MQ，step3就可监听到消息
+
+### 延时消息实现订单关闭回滚库存
+
+```
+1.创建一个过期队列 Queue1
+2.接收消息的队列 Queue2
+3.中转交换机
+4.监听Queue2
+ 1)SeckillStatus->检查Redis中是否有订单信息
+ 2)如有订单信息，调用删除订单回滚库存->[需先关闭微信支付]
+ 3)如关闭订单时，用于已支付，修改订单状态即可
+ 4)如关闭订单时，发生别的错误，记录日志，人工处理
+```
+
+## 2 关闭支付
+
+用户超时未支付，系统主动关闭支付订单，但关闭前，先关闭微信支付，防止中途用户支付。
+
+修改支付微服务的WeixinPayService，添加关闭支付方法：
+
+```java
+Map closePay(Long orderId);
+```
+
+修改WeixinPayServiceImpl，实现关闭微信支付方法：
+
+```java
+@Override
+public Map closePay(Long orderId) {
+ //参数设置
+ Map paramMap = new HashMap();
+ paramMap.put("appid",appid); // 应用ID
+ paramMap.put("mch_id",partner); // 商户编号
+ paramMap.put("nonce_str",WXPayUtil.generateNonceStr()); // 随机字符
+ paramMap.put("out_trade_no",String.valueOf(orderId)); // 商家的唯一编号
+
+ // 将Map数据转成XML字符
+ String xmlParam = WXPayUtil.generateSignedXml(paramMap, partnerkey);
+
+ // 确定url
+ String url = "https://api.mch.weixin.qq.com/pay/closeorder";
+
+ // 发送请求
+ HttpClient httpClient = new HttpClient(url);
+ // https
+ httpClient.setHttps(true);
+ // 提交参数
+ httpClient.setXmlParam(xmlParam);
+
+ // 提交
+ httpClient.post();
+
+ // 获取返回数据
+ String content = httpClient.getContent();
+
+ // 将返回数据解析成Map
+ return WXPayUtil.xmlToMap(content);
+}
+```
+
+## 3 关闭订单回滚库存
+
+### 3.1 配置延时队列
+
+队列信息配置：
+
+```properties
+# 位置支付交换机和队列
+mq:
+ pay:
+ exchange:
+ order: exchange.order
+ queue:
+ order: queue.order
+ seckillorder: queue.seckillorder
+ seckillordertimer: queue.seckillordertimer
+ seckillordertimerdelay: queue.seckillordertimerdelay
+ routing:
+ orderkey: queue.order
+ seckillorderkey: queue.seckillorder
+```
+
+配置队列与交换机，在SeckillApplication中添加如下方法
+
+```java
+/**
+ * 到期数据队列
+ */
+@Bean
+public Queue seckillOrderTimerQueue() {
+ return new Queue(env.getProperty("mq.pay.queue.seckillordertimer"), true);
+}
+
+/**
+ * 超时数据队列
+ */
+@Bean
+public Queue delaySeckillOrderTimerQueue() {
+ return QueueBuilder.durable(env.getProperty("mq.pay.queue.seckillordertimerdelay"))
+ .withArgument("x-dead-letter-exchange", env.getProperty("mq.pay.exchange.order")) // 消息超时进入死信队列，绑定死信队列交换机
+ .withArgument("x-dead-letter-routing-key", env.getProperty("mq.pay.queue.seckillordertimer")) // 绑定指定的routing-key
+ .build();
+}
+
+/***
+ * 交换机与队列绑定
+ */
+@Bean
+public Binding basicBinding() {
+ return BindingBuilder.bind(seckillOrderTimerQueue())
+ .to(basicExchange())
+ .with(env.getProperty("mq.pay.queue.seckillordertimer"));
+}
+```
+
+### 3.2 发送延时消息
+
+MultiThreadingCreateOrder添加方法：
+
+```java
+/***
+ * 发送延时消息
+ */
+public void sendTimerMessage(SeckillStatus seckillStatus) {
+ rabbitTemplate.convertAndSend(env.getProperty("mq.pay.queue.seckillordertimerdelay"), (Object) JSON.toJSONString(seckillStatus), new MessagePostProcessor() {
+ @Override
+ public Message postProcessMessage(Message message) throws AmqpException {
+ message.getMessageProperties().setExpiration("10000");
+ return message;
+ }
+ });
+}
+```
+
+createOrder中调用上面方法：
+
+```java
+// 发送延时消息到MQ
+sendTimerMessage(seckillStatus);
+```
+
+### 3.3 库存回滚
+
+创建SeckillOrderDelayMessageListener实现监听消息，并回滚库存：
+
+```java
+@Component
+@RabbitListener(queues = "${mq.pay.queue.seckillordertimer}")
+public class SeckillOrderDelayMessageListener {
+
+ @Autowired
+ private RedisTemplate redisTemplate;
+
+ @Autowired
+ private SeckillOrderService seckillOrderService;
+
+ @Autowired
+ private WeixinPayFeign weixinPayFeign;
+
+ /***
+ * 读取消息
+ * 判断Redis中是否存在对应的订单
+ * 如果存在，则关闭支付，再关闭订单
+ */
+ @RabbitHandler
+ public void consumeMessage(@Payload String message) {
+ SeckillStatus seckillStatus = JSON.parseObject(message,SeckillStatus.class);
+
+ // 获取Redis中该用户的订单信息
+ String username = seckillStatus.getUsername();
+ SeckillOrder seckillOrder = (SeckillOrder) redisTemplate.boundHashOps("SeckillOrder").get(username);
+
+ // 若Redis中有订单信息，说明用户未支付
+ if(seckillOrder!=null) {
+ System.out.println("准备回滚---"+seckillStatus);
+ // 关闭支付
+ Result closeResult = weixinPayFeign.closePay(seckillStatus.getOrderId());
+ Map closeMap = (Map) closeResult.getData();
+
+ if(closeMap!=null && closeMap.get("return_code").equalsIgnoreCase("success") &&
+ closeMap.get("result_code").equalsIgnoreCase("success") ){
+ // 关闭订单
+ seckillOrderService.closeOrder(username);
+ }
+ }
+ }
+}
+```
\ No newline at end of file
diff --git a/docs/md/design/open-close-principle.md b/docs/md/design/open-close-principle.md
new file mode 100644
index 0000000000..2b5c52a02a
--- /dev/null
+++ b/docs/md/design/open-close-principle.md
@@ -0,0 +1,349 @@
+# 开闭原则（Open Close Principle，OCP）
+
+## 1 定义
+
+来个需求就改一次代码，理所当然？反正修改也易，再CV一份，也不费脑。但每人每次改点，日积月累，再来新需求，后人改动量就大了。每人都无辜，都只是简单修改一点。但最终导致接盘侠无法维护，直接推翻老系统，写新系统（也算是创造就业机会了）。
+
+既然“修改”这么多问题，不修改行吗？就得精通OCP。
+
+`Software entities like classes,modules and functions should be open for extension but closed for modifications`
+一个软件实体如类、模块和方法应对扩展开放，对修改关闭。这是Bertrand Meyer在《面向对象软件构造》（Object-Oriented Software Construction）提出，它给软件设计提出极高要求：不修改代码，对扩展开放。可问题：
+
+- 开放啥？
+- 对修改关闭，咋关闭？
+
+### 1.1 不修改代码，还能写需求？
+
+扩展，即新需求用新代码实现。OCP向我们描述的是结果：可不修改代码，仅靠扩展就完成新功能。
+
+#### 前提
+
+在软件内部留好扩展点，这就需要设计（高级工程师的素质了）。每个扩展点都是个需要设计的模型。
+
+### 1.2 用抽象构建框架，用实现扩展细节
+
+一个软件实体应通过扩展实现变化，而不是通过修改已有代码实现变化。它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。
+
+## 2 案例 - 书店
+
+### 2.1 源码
+
+```java
+package com.javaedge.design.principle.openclose;
+
+/**
+ * 书籍接口
+ *
+ * @author JavaEdge
+ */
+public interface BaseBook {
+
+ /**
+ * 获取书籍 ID
+ *
+ * @return 书籍 ID
+ */
+ Integer getId();
+
+ /**
+ * 获取书籍名
+ *
+ * @return 书籍名
+ */
+ String getName();
+
+ /**
+ * 获取书籍价
+ *
+ * @return 书籍价
+ */
+ Double getPrice();
+}
+```
+
+```java
+/**
+ * Java书籍实现类
+ *
+ * @author JavaEdge
+ */
+@AllArgsConstructor
+@Getter
+@Setter
+public class JavaBook implements BaseBook {
+
+ private Integer id;
+
+ private String name;
+
+ private Double price;
+}
+```
+
+```java
+/**
+ * 测试类
+ *
+ * @author JavaEdge
+ */
+@Slf4j
+public class Test {
+ public static void main(String[] args) {
+ JavaBook baseCourse = new JavaBook(66, "Java编程思想", 98d);
+
+ JavaDiscountBook discountBook = (JavaDiscountBook) baseCourse;
+ log.info("书籍ID:" + discountBook.getId() +
+ " 书籍名称:" + discountBook.getName() +
+ " 书籍原价:" + discountBook.getPrice() +
+ "书籍优惠价:" + discountBook.getDiscountPrice());
+ }
+}
+```
+
+### 2.2 需求
+
+新增一个折扣优惠方法：若直接修改原接口，则每个实现类都得重新添加方法实现。但接口应稳定，不应频繁修改！
+
+```java
+package com.javaedge.design.principle.openclose;
+
+/**
+ * Java 书籍折扣类
+ *
+ * @author JavaEdge
+ */
+public class JavaDiscountBook extends JavaBook {
+
+ public JavaDiscountBook(Integer id, String name, Double price) {
+ super(id, name, price);
+ }
+
+ public Double getDiscountPrice() {
+ return super.getPrice() * 0.8;
+ }
+}
+```
+
+现UML：
+
+
+
+`接口应稳定且可靠，不应经常变化`，否则接口作为契约的作用就失去效能。
+
+### 2.3 修改实现类
+
+在getPrice()实现打折处理，低级程序员都习惯这样通过class文件替换，极速完成部分业务变化（或bugfix）。
+
+该方法在项目有明确章程（团队内约束）或优良架构设计时，很优秀，但若采购书籍人员也要看价格，由于该方法已实现打折处理价格，因此采购人员看到也是折后价，会`因信息不对称而出现决策失误`。因此，这不是最优解。
+
+### 2.4 通过扩展实现变化
+
+`增加子类`OffNovelBook，重写getPrice，高层次模块（static静态模块区）通过OffNovelBook类产生新对象，完成业务变化对系统的最小化开发。
+
+好办法！修改少，风险也小。
+
+OCP对扩展开放，对修改关闭，但并不是说不做任何修改，低层模块的变更，必然要与高层模块耦合，否则就是孤立无意义的代码段。
+
+## 3 变化的类型
+
+### 3.1 逻辑变化
+
+只变化一个逻辑，不涉及其它模块。如原算法`a*b+c`，要修改为`a*b*c`，那就直接修改原有类中的方法，但前提条件：所有依赖或关联类都按相同逻辑处理。
+
+### 3.2 子模块变化
+
+一个模块变化，会对其他的模块产生影响，特别是一个低层次的模块变化必然引起高层模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的。
+
+### 3.3 可见视图变化
+
+如Swing。若仅是按钮、文字重排还简单，最司空见惯的是业务耦合变化一个展示数据的列表，按原有需求是6列，突然要增加1列，而且这一列要跨N张表，处理M个逻辑才能展现，这样的变化是恐怖的，但还是能通过扩展完成变化。
+
+### 3.4 小结
+
+放弃修改历史的想法吧！一个项目的基本路径：项目开发、重构、测试、投产、运维。
+
+- 重构，可对原有设计和代码进行修改
+- 运维，尽量减少对原有代码的修改，保持历史代码的纯洁性，提高系统稳定性
+
+## 4 案例 - 酒店会员
+
+开发酒店CRS系统，针对不同用户，计算不同房价：
+
+- 普通用户全价
+- 金卡8折
+- 银卡9折
+
+代码可能：
+
+
+### 4.1 新需求
+
+增加白金会员75折，CV大法好：
+
+
+这就是【修改代码】，每增加一个新类型，就修改一次代码。
+但一个有各种级别用户的酒店系统肯定不只房价不同，提供服务也可能有区别，如是否有早餐？预付现付？优惠券力度、连住优惠规则？。可预见，每增加一个用户级别，要改的代码散布各地。
+
+### 4.2 何解？
+
+应考虑设计成可扩展模型。既然每次要增加的是用户级，且各种服务差异都体现在用户级，就需要一个用户级模型。
+
+#### ① 用户级别重构
+
+
+
+
+
+原代码即可重构成：
+
+
+
+此时再增加白金用户，只需新写一个类：
+
+
+可以这么做，是因为代码里留好了扩展点：UserLevel把原来只支持枚举值的UserLevel，升级成【有行为】的UserLevel。
+
+改造后，HotelService的getRoomPrice就稳定了，无需根据用户级别不断调整。
+一旦有稳定的构造块，就能在后续将其当做一个稳定模块复用。
+
+## 5 构建扩展点
+
+其实我们修改代码效果不佳，但真到自己写代码，就晕了。你开发的系统有问题吗？相信大部人都承认有。但又问：你经常主动优化吗？大部人却又沉默。
+它虽然垃圾，但在线上运行好好，万一我优化坏了咋办，绩效可就 3.25！现实就是这样 ，系统宏观层面人人都懂，而代码落地层，却各种原因本能的忽视。
+
+所以，写软件系统，就该提供一个个稳定小模块，然后，将它们组合。一个经常变动的模块不稳定，用它去构造更大模块，必后患无穷。
+
+### 5.1 为什么懂很多道理，却依旧写不好代码？
+
+阻碍我们构造稳定模块的，是构建模型的能力。回想产生变化的UserLevel是如何升级成有行为的UserLevel。
+
+封装的要点是行为，数据只是实现细节，而很多人习惯性面向数据写法，导致设计缺乏扩展性。
+
+### 5.2构建模型的难点
+
+1. 分离关注点
+2. 找到共性
+
+**要构建起抽象就要找到事物的共同点**，业务处理过程发现共性对大部分人就已经开始有难度。
+
+## 6 案例 - 报表服务
+
+
+很多人日常写代码就这风格，代码流程僵化。只要有新需求，基本都要修改这段。
+
+### 6.1 需求
+
+把统计信息发给另外一个内部系统，该内部系统可将统计信息展示出来，供外部合作伙伴查阅。
+
+### 6.2 分析
+
+发给另一个系统的内容是**统计信息**。原代码里：
+
+- 前2步获取源数据，生成**统计信息**
+- 后2步生成报表，将**统计信息**通过邮件发出
+
+后2步和即将添加的步骤有个共同点，都使用统计信息。所以，可用共同模型，如OrderStatisticsConsumer：
+
+
+这样，新需求也只需添加一个新类，而非 if/else：
+
+
+该案例中，第一步要做的还是分解：
+
+- 把一个个步骤分开
+- 然后找出步骤间相似点
+- 并构建一个新模型
+
+实际项目代码更复杂，但并非一定业务逻辑复杂，而是代码写得就垃圾且复杂。
+所以，要先根据SRP，将不同需求来源引起的变动拆到不同方法，形成一个个小单元，再做这里的分析。
+
+实际项目达到OCP并非一朝一夕。这里只是因为有需求变动，才提取出一个OrderStatisticsConsumer。
+
+未来可能还有其它变动，如生成报表的逻辑。那时，也许再提取一个新OrderStatisticsGenerator的接口。但不管怎样，每做一次这种模型构建，最核心的类就会朝稳定发展。
+
+**好的设计都会提供足够扩展点给新功能去扩展（想起 Spring 生命周期）。**
+《Unix 编程艺术》提倡“提供机制，而非策略”，这就体现OCP。
+
+很多系统的插件机制，如IDEA和VS Code都体现OCP。去了解它们的接口，即可看到这个软件给我们提供的各种能力。
+
+### 6.3 抓手
+
+OCP还可帮助我们优化系统，查看Git，找出那些最经常变动的文件，它们通常都没满足OCP，这就能成为你系统优化的起航点。
+
+## 7 为何选择OCP？
+
+### 7.1 OCP对测试的影响
+
+有变化提出时，就要考虑：原有的健壮代码是否能不修改，而仅通过扩展实现变化？否则，就需要把原有测试过程全部回笼一遍，需要进行UT、功能测试、集成测试甚至验收测试。
+
+回看书店案例，*BaseBook*接口写完，实现类JavaBook也写好了，写个测试类：
+
+```java
+public class JavaBookTest extends TestCase {
+ private String name = "Java666";
+ private int price = 6000;
+ private String author = "JavaEdge";
+ private BaseBook javaBook = new JavaBook(name,price,author);
+
+ // 测试getPrice方法
+ public void testGetPrice() {
+ //原价销售，根据输入和输出的值是否相等进行断言
+ super.assertEquals(this.price, this.novelBook.getPrice());
+ }
+}
+```
+
+若加个打折销售需求，直接修改getPrice，就要修改UT类。而实际项目，一个类一般只有一个测试类，其中可以有很多测试方法，在一堆本就复杂的断言中进行大量修改，难免测试遗漏。
+
+**所以，要通过扩展实现业务逻辑变化，而非修改**。可通过增加一个子类OffJavaBook完成业务需求变化，这对测试有啥好处？重新生成一个测试文件OffJavaBookTest，然后对getPrice测试，UT是孤立测试，只要保证我提供的方法正确就成，其他不管：
+
+```java
+public class OffNovelBookTest extends TestCase {
+ private BaseBook below40NovelBook = new OffJavaBook("Java666",3000,"JavaEdge");
+ private BaseBook above40NovelBook = new OffJavaBook("Go999",6000,"JavaEdge");
+
+ // 测试低于40元的数据是否是打8折
+ public void testGetPriceBelow40() {
+ super.assertEquals(2400, this.below40NovelBook.getPrice());
+ }
+
+ // 测试大于40的书籍是否是打9折
+ public void testGetPriceAbove40(){
+ super.assertEquals(5400, this.above40NovelBook.getPrice());
+ }
+}
+```
+
+新增加的类，新增加的测试方法，只要保证新增加类是正确的就可以了。
+
+### 7.2 提高复用性
+
+OOP中，所有逻辑都从原子逻辑组合而来，而非在一个类中独立实现一个业务逻辑。只有这样代码才可复用，粒度越小，被复用可能性越大。
+
+#### ① 为何要复用？
+
+减少代码量，避免相同逻辑分散，避免后来的维护人员为修改一个小bug或加个新功能，而在整个项目到处查找相关代码，然后发出对开发人员吼出“极度失望”的感慨。
+
+#### ② 如何提高复用率？
+
+缩小逻辑粒度，直到一个逻辑不可再拆分。
+
+### 7.3 提高可维护性
+
+一款软件投产后，接盘侠不仅要对数据进行维护，还可能要对程序进行扩展，接盘侠最爱干的就是扩展一个类，而非修改一个类，甭管原有代码好坏，让接盘侠先看懂原有代码，再修改，就是炼狱！不要让他在原有代码海洋里瞎游完毕后再修改，那是对接盘侠的摧残，会缺水溺死。
+
+### 7.4 OOP
+
+万物皆对象，我们要把所有事物抽象成对象，再针对对象操作，但运动是一定的，有运动就有变化，有变化就要有策略应对，如何快速应对？就需要在设计之初考虑到所有可能变化的因素，然后留下接口，等待“可能”转为“现实”。
+
+## 8 总结
+
+若说SRP主要看封装，而OCP须有多态。要想提供扩展点，就要面向接口编程。
+
+Java SPI提供扩展机制，Spring Boot和Dubbo继续改进，各自提供扩展点：
+
+- Spring Boot允许用户自定义starter
+- Dubbo可自定义协议
+
+1、识别修改点，构建模型，将原来静态逻辑转为动态逻辑
+2、构建模型的难点在于分离关注点，其次找到共性
\ No newline at end of file
diff --git "a/docs/md/java/JDK16\346\226\260\347\211\271\346\200\247.md" b/docs/md/java/Java16-new-features.md
similarity index 100%
rename from "docs/md/java/JDK16\346\226\260\347\211\271\346\200\247.md"
rename to docs/md/java/Java16-new-features.md
diff --git "a/docs/md/java/JDK21\346\226\260\347\211\271\346\200\247.md" b/docs/md/java/Java21-new-features.md
similarity index 100%
rename from "docs/md/java/JDK21\346\226\260\347\211\271\346\200\247.md"
rename to docs/md/java/Java21-new-features.md
diff --git "a/docs/md/java/JDK22\346\226\260\347\211\271\346\200\247.md" b/docs/md/java/Java22-new-features.md
similarity index 100%
rename from "docs/md/java/JDK22\346\226\260\347\211\271\346\200\247.md"
rename to docs/md/java/Java22-new-features.md
diff --git "a/docs/md/java/JDK23\346\226\260\347\211\271\346\200\247.md" b/docs/md/java/Java23-new-features.md
similarity index 100%
rename from "docs/md/java/JDK23\346\226\260\347\211\271\346\200\247.md"
rename to docs/md/java/Java23-new-features.md
diff --git "a/docs/md/java/Java9\346\226\260\347\211\271\346\200\247\346\246\202\350\277\260.md" b/docs/md/java/Java9-new-features.md
similarity index 100%
rename from "docs/md/java/Java9\346\226\260\347\211\271\346\200\247\346\246\202\350\277\260.md"
rename to docs/md/java/Java9-new-features.md
diff --git a/docs/md/java/java-news-roundup-jun02-2025.md b/docs/md/java/java-news-roundup-jun02-2025.md
new file mode 100644
index 0000000000..4f3022a035
--- /dev/null
+++ b/docs/md/java/java-news-roundup-jun02-2025.md
@@ -0,0 +1,126 @@
+# Java 新闻速递：JDK 25 进入收尾阶段，JDK 26 专家组成立，Hibernate Search 发布，Oracle 推出 Project Crema
+
+## 0 前言
+
+上周Java 新闻回顾重点：JDK 25进入Rampdown第一阶段、JDK 26专家组成立、Hibernate Search 8.0.0.Final发布、Grails 7.0.0第四个里程碑版本发布、Open Liberty 25.0.0.6测试版发布、Eclipse JNoSQL、Helidon 和 JBang 的小版本更新，以及 Oracle Labs 推出的新项目 Project Crema 预览。
+
+## 1 OpenJDK
+
+JEP 509：[JFR CPU时间分析（实验性）](https://openjdk.org/jeps/509) 已从“拟定为目标”升级为“已确定目标”，将会包含在 JDK 25。该JEP提议增强 JDK Flight Recorder（JFR），使其可在 Linux 系统记录 CPU 时间的分析信息。
+
+## 2 JDK 25
+
+JDK 25 的[早期访问版本 Build 26](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B26)上周上线，包含自 Build 25 以来的多项[更新](https://github.com/openjdk/jdk/compare/jdk-25%2B25...jdk-25%2B26)，修复了多个[问题](https://bugs.openjdk.org/browse/JDK-8357287?jql=project %3D JDK AND fixversion %3D 25 and "resolved in build" %3D b26 order by component%2C subcomponent)。完整详情可见[发行说明](https://jdk.java.net/25/release-notes)。
+
+根据 JDK 25 的[发布计划](https://openjdk.org/projects/jdk/25/#Schedule)，Oracle Java平台首席架构师 [Mark Reinhold](https://www.linkedin.com/in/markreinhold) [宣布](https://mail.openjdk.org/pipermail/jdk-dev/2025-June/010191.html)，JDK 25已进入 Rampdown Phase One，即主线源码仓库已分支为[JDK稳定版本仓库](https://github.com/openjdk/jdk/tree/jdk25)，不会再添加新JEP特性。JDK 25 正式发布（GA）将于 2025 年 9 月进行，最终包含18项功能：
+
+- JEP 470：[加密对象的PEM编码（预览）](https://openjdk.org/jeps/470)
+- JEP 502：[稳定值（预览）](https://openjdk.org/jeps/502)
+- JEP 503：[移除32位x86平台支持](https://openjdk.org/jeps/503)
+- JEP 505：[结构化并发（第五次预览）](https://openjdk.org/jeps/505)
+- JEP 506：[作用域值](https://openjdk.org/jeps/506)
+- JEP 507：[在模式匹配、instanceof 和 switch 中使用原始类型（第三次预览）](https://openjdk.org/jeps/507)
+- JEP 508：[向量API（第十次孵化）](https://openjdk.org/jeps/508)
+- JEP 509：[JFR CPU时间分析（实验性）](https://openjdk.org/jeps/509)
+- JEP 510：[密钥派生函数API](https://openjdk.org/jeps/510)
+- JEP 511：[模块导入声明](https://openjdk.org/jeps/511)
+- JEP 512：[简洁的源文件和实例 main 方法](https://openjdk.org/jeps/512)
+- JEP 513：[灵活的构造方法体](https://openjdk.org/jeps/513)
+- JEP 514：[AOT 命令行参数优化](https://openjdk.org/jeps/514)
+- JEP 515：[AOT 方法分析](https://openjdk.org/jeps/515)
+- JEP 518：[JFR 协作采样](https://openjdk.org/jeps/518)
+- JEP 519：[紧凑对象头](https://openjdk.org/jeps/519)
+- JEP 520：[JFR 方法计时与追踪](https://openjdk.org/jeps/520)
+- JEP 521：[新一代 Shenandoah 垃圾回收器](https://openjdk.org/jeps/521)
+
+JDK 25 将是继 JDK 21、17、11 和 8 之后的下一代长期支持（LTS）版本。
+
+## 3 JDK 26
+
+JSR 401：[Java SE 26](https://jcp.org/en/jsr/detail?id=401) 已于上周正式批准，宣布成立四人专家组，成员包括 [Simon Ritter](https://www.linkedin.com/in/siritter/)（Azul Systems）、[Iris Clark](https://www.linkedin.com/in/iris-clark-49159b13b/)（Oracle）、[Stephan Herrmann](https://github.com/stephan-herrmann)（Eclipse Foundation）和 [Christoph Langer](https://www.linkedin.com/in/christoph-langer-764280208/)（SAP SE）。Clark 将担任规范负责人。JDK 26 的[计划时间表](https://openjdk.org/projects/jdk/26/spec/)包括：2025年11月到2026年2月的公开评审期，GA版本预计在2026年3月发布。
+
+此外，JDK 26 的[Build 0](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B0) 和 [Build 1](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B1) 也在本周发布，修复了部分[初期问题](https://bugs.openjdk.org/browse/JDK-8355746?jql=project %3D JDK AND fixVersion %3D "26" AND "Resolved In Build" %3D b01 order by component%2C subcomponent)。
+
+开发者可通过 [Java Bug Database](https://bugreport.java.com/bugreport/) 提交 JDK 25 的问题反馈。
+
+## 4 Jakarta EE
+
+Eclipse 基金会 Jakarta EE 开发者倡导者 [Ivar Grimstad](https://se.linkedin.com/in/ivargrimstad) 在他每周的 [Hashtag Jakarta EE 博客](https://www.agilejava.eu/)中更新了 Jakarta EE 11 和 EE 12 的进展：
+
+> 该庆祝了！Jakarta EE 11 平台的所有发布审查材料都已提交，作为规范委员会的导师，我将于6月9日（周一）启动发布审查投票。这意味着最迟将在6月24日正式发布。希望那天有蛋糕……
+>
+> 随着 EE 11 推出，接下来的重点将转向 [Jakarta EE 12](https://jakarta.ee/specifications/platform/12/)。目前计划评审已完成，平台项目已启动并开始定义里程碑，[详细计划](https://jakartaee.github.io/platform/jakartaee12/JakartaEE12ReleasePlan)包括制定 *Milestone 0*，确保各个子规范项目准备就绪。
+
+Jakarta EE 11 的发布经历了五个里程碑版本，包括2024年12月发布的 [Core Profile](https://jakarta.ee/specifications/coreprofile/)、2025年4月发布的 [Web Profile](https://jakarta.ee/specifications/webprofile/)，以及平台版的候选发布版本，预计正式发布将在2025年6月。
+
+## 5 Eclipse JNoSQL
+
+[Eclipse JNoSQL](https://www.jnosql.org/) 1.1.8 发布，作为 [Jakarta NoSQL](https://jakarta.ee/specifications/nosql/) 规范的兼容实现，此版本带来以下更新：
+
+- 支持图数据库类型，新增 Java 的 Graph API，采用 Neo4j 的 [Cypher 查询语言](https://neo4j.com/product/cypher-graph-query-language/)
+- 新增 Quarkus 扩展：[quarkus-jnosql-core](https://quarkus.io/extensions/io.quarkiverse.jnosql/quarkus-jnosql-core/)，支持 MongoDB、ArangoDB、Cassandra 和 Hazelcast
+
+图形 API 的实现细节可参考这篇 [LinkedIn 博客](https://quarkus.io/extensions/io.quarkiverse.jnosql/quarkus-jnosql-core/)。
+
+## 6 Spring Framework
+
+[Spring Cloud](https://spring.io/projects/spring-cloud) 2022.0.11（代号 Kilburn）作为第11个维护版本，[已发布](https://spring.io/blog/2025/06/02/spring-cloud-2022-0-11-aka-kilburn-has-been-released)，包含多项Bug修复和依赖升级，尤其是：
+
+- [Spring Cloud Config](https://spring.io/projects/spring-cloud-config) 4.0.11 修复了 [CVE-2025-22232](https://spring.io/security/cve-2025-22232)
+- [Spring Cloud Gateway](https://spring.io/projects/spring-cloud-gateway) 4.0.12 修复了 [CVE-2025-41235](https://spring.io/security/cve-2025-41235)
+
+## 7 Hibernate
+
+[Hibernate Search](https://hibernate.org/search/) 8.0.0.Final [正式发布](https://in.relation.to/2025/06/06/hibernate-search-8-0-0-Final/)，包括：
+
+- 兼容 Hibernate ORM 7.0.0.Final
+- 与 [Hibernate Models](https://github.com/hibernate/hibernate-models/blob/main/README.adoc) 集成增强
+- 在 [Hibernate Search DSL](https://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#search-dsl) 中支持请求指标聚合
+- 各类Bug修复
+
+更多详情请参阅[发行说明](https://hibernate.atlassian.net/issues/?jql=project%3D10061 AND fixVersion%3D33769)。
+
+## 8 Helidon
+
+Helidon 4.2.3 发布，主要改进包括：
+
+- 在 [Metrics](https://helidon.io/docs/v4/se/metrics/metrics)、[Health Checks](https://helidon.io/docs/v4/se/health)、[OpenAPI](https://helidon.io/docs/v4/se/openapi/openapi) 和 [Config](https://helidon.io/docs/v4/se/config/introduction) API 输出中添加 **`nosniff`** 的 **`X-Content-Type-Options`** 头部，防止浏览器自动推断内容类型
+- 修复了 **`SecurityEnvironment`** 类中 **`queryParams()`** 方法无法获取查询参数的问题
+
+详细变更见 [更新日志](https://github.com/helidon-io/helidon/blob/4.2.3/CHANGELOG.md)。
+
+## 9 Open Liberty
+
+[Open Liberty](https://openliberty.io/) 25.0.0.6-beta [发布](https://openliberty.io/blog/2025/06/03/25.0.0.6-beta.html)，新特性包括：
+
+- 为 Java EE 7 和 8 应用回移支持 [Microprofile Health 4.0](https://github.com/microprofile/microprofile-health/blob/main/README.adoc) 规范（`mpHealth-4.0`）
+- 更新了[基于文件的健康检查机制](https://blogs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/blog/2025/04/08/25.0.0.4-beta.html#backport)，新增了 **`server.xml`** 中的 **`startupCheckInterval`** 属性及其环境变量 **`MP_HEALTH_STARTUP_CHECK_INTERVAL`**，默认值为100毫秒
+
+## 10 Grails
+
+[Grails](https://grails.org/) 7.0.0 的第四个里程碑版本发布，更新内容包括：
+
+- 由于迁移至 Apache 软件基金会，进行了[构件命名重构](https://github.com/apache/grails-core/blob/7.0.x/RENAME.md)
+- 将多个仓库（如 **`grails-views`**、**`gsp`** 等）的源码整合至 **`grails-core`** 仓库中
+
+详细信息见 [发布说明](https://github.com/apache/grails-core/releases/tag/v7.0.0-M4)。
+
+## 11 JBang
+
+[JBang](https://www.jbang.dev/) 0.126.0 发布，带来文档改进、Bug 修复和新特性，包括：
+
+- 将 **`ResourceRef`** 从类更改为接口
+- 引入 **`LazyResourceRef`** 和 **`LazyResourceResolver`**，支持开发者按需加载远程资源
+
+更多信息请查阅 [发布说明](https://github.com/jbangdev/jbang/releases/tag/v0.126.2)。
+
+## 12 Project Crema
+
+Oracle Labs 的 GraalVM 开发者倡导者 [Alina Yurenko](https://www.linkedin.com/in/alinayurenko/) 在 [X 平台](https://x.com/alina_yurenko/status/1930241191418708072)上分享了新项目 [Project Crema](https://github.com/oracle/graal/issues/11327) 的预览。
+
+该项目旨在“打破 Native Image 的默认封闭世界假设，允许在运行时动态加载和执行类”，主要包括：
+
+- Java 解释器，构建在 **Native Image Layers** 之上（一个支持依赖基础镜像链的新项目，[详情](https://github.com/oracle/graal/issues/7626)）
+- 支持 [Java 调试线协议（JDWP）](https://docs.oracle.com/en/java/javase/24/docs/specs/jdwp/jdwp-spec.html)
+
+Yurenko 表示，开发者应“持续关注更多更新！”
\ No newline at end of file
diff --git a/docs/md/kafka/kafka-core-components.md b/docs/md/kafka/kafka-core-components.md
new file mode 100644
index 0000000000..1fb04e22b9
--- /dev/null
+++ b/docs/md/kafka/kafka-core-components.md
@@ -0,0 +1,214 @@
+# 别再死记硬背！一文看懂 Kafka 核心组件及其协作原理
+
+## 0 Message
+
+消息，是通信的基本单位，每个producer可以向一个topic发布一些消息
+
+## 1 Producer & Consumer（客户端）
+
+### 1.1 生产者（Producer）
+
+向主题发布消息的客户端应用。生产者程序通常持续不断向一或多个主题发消息。
+
+### 1.2 消费者（Consumer）
+
+订阅这些主题消息的客户端应用程序。消费者也能同时订阅多个主题消息。
+
+生产者和消费者统称为客户端（Clients）。可同时运行多个生产者和消费者实例，这些实例会不断向Kafka集群中的多个主题生产和消费消息。
+
+## 2 Broker（服务器端）
+
+Kafka服务端由称为Broker的服务进程构成，一个Kafka集群由多个Broker组成。
+
+Broker负责：
+
+- 接收和处理客户端发过来的请求
+- 对消息进行持久化
+
+虽多个Broker进程能运行在同一机器，但更常见做法是将不同Broker分散运行在不同机器。这样， 即使：
+
+- 集群中某机器宕机
+- 在它上面运行的所有Broker进程都挂
+
+其他机器的Broker也依然能对外提供服务，Kafka高可用手段之一。
+
+
+
+## 3 Partitioning（分区）
+
+物理概念，有序不可变的record序列，partition中的record会被分配一个自增长id（offset）。
+
+一个topic中的消息数据按多个分区组织，partition是kafka消息队列组织的最小单位，一个partition可看做一个队列。
+
+Q：虽副本机制保证数据持久化，但未解决Scalability伸缩性问题。虽有leader、follower副本，但若leader副本积累太多数据以至单台Broker无法容纳，咋办？
+
+A：Kafka会把数据分割成多份，保存在不同Broker（即分区），类似其他分布式系统的分片、分区域等说法，如：
+
+- MongoDB、ES的Sharding
+- HBase的Region
+
+但Partitioning是最标准名称。
+
+Kafka分区就是将每个topic划成多个分区（Partition），每个Partition内是一组顺序的消息日志。Pro生产的每条消息只会被发送到一个分区，即向一个双分区的topic发一条消息，该消息：
+
+- 要么在分区0
+- 要么在分区1
+
+### 副本与分区
+
+`副本是在分区级别定义`。每个分区下可配置N个副本，但只能有1个领导者副本和N-1个追随者副本。
+
+Pro向分区写消息，每条消息在分区中的位置信息由位移（Offset）数据来表征。
+分区位移从0开始，假设一个Pro向一个空分区写10条消息，则这10条消息offset依次是0、1、2、…、9。
+
+## 4 Topic
+
+一个业务即一个Topic。
+每条发布到Kafka集群的消息都有一个类别，该类别即称为Topic。物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽保存于一或多个broker，但用户只需指定消息的Topic即可生产或消费数据，不必关心数据存于何处。
+
+
+数据主题，是Kafka中用来代表一个数据流的一个抽象，Kafka处理的消息源（feeds of messages）的不同分类。
+
+发布数据时，可用topic对数据分类，也作为订阅数据时的主题。
+一个Topic同时可有多个producer、consumer。
+Topic可理解为一个队列，**生产者和消费者面向的都是同一topic**。
+
+
+
+## 5 Replication - 副本
+
+`实现高可用的另一手段。`
+
+为保证分布式可靠性，kafka 0.8开始对每个分区的数据进行备份（不同Broker上），防止其中一个Broker宕机而造成分区数据不可用。
+
+### 5.1 冗余备份策略
+
+每个partition被复制到其它服务器作为replication：
+
+
+
+同一partition的多个replication🈲在同一broker。
+
+每个partition的replication中，有一个leader副本，0或多个follower副本：
+
+- leader处理此分区所有读、写请求
+
+- follower仅被动复制数据
+
+leader宕机后，会从follower中选举新leader。副本数量可配置，副本保存相同数据，却也有不同：
+
+### 5.1 分类
+
+- 领导者副本（Leader Replica）：对外提供服务，与客户端程序交互
+- 追随者副本（Follower Replica）：只被动追随领导者副本，不与外界交互
+
+很多其他系统Follower副本可对外提供服务，如MySQL从库可处理读操作，但Kafka的Follower副本不对外提供服务。
+
+### 5.2 工作机制
+
+- 生产者总是向领导者副本写消息
+- 而消费者总是从领导者副本读消息
+
+Follower副本只做一件事：向Leader副本发请求，请求Leader把最新生产消息发给它，以保持与Leader同步。
+
+### 5.3 为啥Kafka follower副本不对外提供读服务？
+
+- kafka分区机制已让，读，从多个broker读，从而负载均衡。而不是MySQL的主从，压力都在主
+- kafka保存的数据和数据库的性质有别：数据具有消费概念，是流数据，kafka是MQ，所以消费需位移，而DB是实体数据不存在这概念，若从kafka的follower读，消费端offset控制更复杂
+- 对生产者，kafka可从配置控制是否等待follower对消息确认，若从follower读，也要所有follower都确认才可回复生产者，性能大降，若follower出问题也不好处理
+
+主从分离与否，无绝对优劣，仅是架构设计，各有适用场景：
+
+- Redis和MySQL都支持主从读写分离，和使用场景有关。读操作很多而写操作相对不频繁的负载类型，可添加很多follower横向扩展，提升读性能
+- Kafka主要还是在消息引擎而不是以数据存储方式对外提供读服务，通常涉及频繁生产消息、消费消息，这不属于读多写少，因此读写分离方案在这场景不太适合
+
+Kafka副本机制使用异步消息拉取，因此存在leader和follower之不一致性。若采用读写分离，要处理副本lag引入的一致性问题，比如如何实现read-your-writes、如何保证单调读（monotonic reads）以及处理消息因果顺序颠倒的问题。
+
+如果不采用读写分离，所有客户端读写请求都只在Leader上处理，就没有这些问题。当然最后全局消息顺序颠倒的问题在Kafka中依然存在，常见解决办法：使用单分区，其他方案还有version vector，但Kafka没有提供。
+
+社区正在考虑引入适度读写分离，如允许指定follower副本（主要是为考虑地理相近性）可对外提供读服务。
+
+> Kafka的数据会保存到leader副本的log文件中并写入磁盘，随后follower副本会对数据进行同步。
+
+## 6 Record
+
+每条记录都有key、value、 timestamp三个信息：
+
+
+
+分区id+offset才可确定数据位置，分区内才有序！
+
+## 7 ConsumerGroup - 消费组
+
+每个Consumer属于一个特定的Consumer Group (可为每个Consumer 指定 group name, 若不指定 group name则属于默认的group)
+
+- 消费者可使用相同的 `group.id` 加入一个组
+- 每个Consumer实例属于一个ConsumerGroup
+- 组的最大并行度是组中的消费者数量 ← 没有partition
+- Kafka将topic的partition分配给组中的消费者，以便每个分区仅由组中的一个消费者使用
+- Kafka保证消息只能由该组中的单个消费者读取。消费者可按存储在日志中的顺序查看消息
+- 每个ConsumerGroup都有一个Coordinator(协调者），负责分配Consumer和Partition的对应关系，当Partition或是Consumer发生变更时，会触发reblance（重新分配），重新分配Consumer与Partition的对应关系
+
+## 8 Coordinator
+
+Consumer维护与Coordinator之间的心跳，这样Coordinator就能感知到Consumer状态。
+
+当Consumer故障，及时触发rebalance。
+
+## Kafka三层消息架构
+
+- 第一层：主题层，每个主题可配置M个分区，每个分区又可配置N个副本
+- 第二层：分区层，每个分区的N个副本中，只能有一个充当Leader，对外提供服务；其他N-1个是follower副本，只提供数据冗余之用
+- 第三层：消息层，分区中包含若干条消息，每条消息的位移从0开始，依次递增
+
+客户端程序只能与分区的Leader副本交互。
+
+### Kafka Broker咋持久化数据？
+
+使用消息日志（Log）保存数据，一个日志就是磁盘上一个仅能追加写（Append-only）消息的物理文件。因为只能追加写，避免了缓慢的随机I/O操作，改为性能较好的顺序I/O写，这也是实现Kafka高吞吐量的一大手段。
+
+但若不停向一个日志写消息，最终也会耗尽磁盘，因此Kafka要定期删除消息。
+
+### 咋删除？
+
+通过日志段（Log Segment）机制。在Kafka底层，一个日志进一步细分成多个日志段，消息被追加写到当前最新的日志段中，当写满一个日志段后，Kafka会自动切分出一个新的日志段，并将老的日志段封存。Kafka后台定时任务定期检查老的日志段是否能被删除，从而回收磁盘空间。
+
+## 消费者
+
+点对点模型和发布订阅模型。
+
+点对点指的是同一条消息只能被下游的一个消费者消费，其他消费者则不能染指。在Kafka中实现这种P2P模型的方法就是引入了**消费者组**（Consumer Group）。
+
+消费者组，指的是多个消费者实例共同组成一个组来消费一组主题。这组主题中的每个分区都只会被组内的一个消费者实例消费，其他消费者实例不能消费它。
+
+为什么要引入消费者组？主要为提升消费端吞吐量。多个消费者实例同时消费，加速整个消费端吞吐量（TPS）。这里的消费者实例可以是运行消费者应用的进程，也可以是一个线程，都称为一个消费者实例（Consumer Instance）。
+
+消费者组里面的所有消费者实例不仅“瓜分”订阅主题的数据，而且更酷的是它们还能彼此协助。假设组内某个实例挂掉了，Kafka能够自动检测到，然后把这个Failed实例之前负责的分区转移给其他活着的消费者。这就是Kafka的重平衡Rebalance。大名鼎鼎且臭名昭著，由重平衡引发的消费者问题比比皆是。事实上，目前很多重平衡的Bug社区都无力解决。
+
+每个消费者在消费消息的过程中，必然要有个字段记录它当前消费到了分区的哪个位置，即**消费者位移**（Consumer Offset）。这和上面所说的位移不是一个概念：
+
+- 上面的“位移”表征的是分区内的消息位置，它是不变的，即一旦消息被成功写入到一个分区上，它的位移值就是固定的了
+- 而消费者位移则不同，它可能是随时变化的，毕竟它是消费者消费进度的指示器。每个消费者有着自己的消费者位移，因此一定要区分这两类位移的区别
+
+我喜欢把消息在分区中的位移称为分区位移，而把消费者端的位移称为消费者位移。
+
+## 8 总结
+
+- 消息：Record。Kafka是消息引擎，这里的消息就是指Kafka处理的主要对象
+- 主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务
+- 分区：Partition。一个有序不变的消息序列。每个主题下可以有多个分区
+- 消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值
+- 副本：Replica。Kafka中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用
+- 生产者：Producer。向主题发布新消息的应用程序
+- 消费者：Consumer。从主题订阅新消息的应用程序
+- 消费者位移：Consumer Offset。表征消费者消费进度，每个消费者都有自己的消费者位移
+
+- 消费者组：Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐
+- 重平衡：Rebalance。消费者组内某消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。这是Kafka消费者端实现高可用的重要手段。
+
+
+
+参考：
+
+- https://www.zhihu.com/question/327925275/answer/705690755
+- https://kafka.apache.org/documentation
\ No newline at end of file
diff --git a/docs/md/kafka/13-KafkaAdminClient.md b/docs/md/kafka/kafka-operations-tool-exploring-adminclient-principles-and-practices.md
similarity index 50%
rename from docs/md/kafka/13-KafkaAdminClient.md
rename to docs/md/kafka/kafka-operations-tool-exploring-adminclient-principles-and-practices.md
index 8a128812e4..e7e90298e2 100644
--- a/docs/md/kafka/13-KafkaAdminClient.md
+++ b/docs/md/kafka/kafka-operations-tool-exploring-adminclient-principles-and-practices.md
@@ -1,20 +1,20 @@
-# 13-KafkaAdminClient
+# Kafka运维利器：深入解析AdminClient原理与实战
-## 引入原因
+## 1 Kafka脚本弊端
-Kafka自带的各种命令行脚本，这些脚本使用起来虽然方便，却有弊端：
+Kafka自带各种命令行脚本，用起来虽方便，但是：
-- 命令行的脚本都只能运行在控制台。若想在应用程序、运维框架或是监控平台中集成它们很难
-- 这些命令行脚本很多都是通过连接zk来提供服务。目前，社区越来越不推荐任何工具直连zk，因这会带来一些问题：可能绕过Kafka安全设置。kafka-topics脚本连接zk时，不会考虑Kafka设置的用户认证机制。即任何使用该脚本的用户，不论是否具有创建主题的权限，都能成功“跳过”权限检查，强行创建主题！
-- 运行这些脚本，要用Kafka内部的类实现，即Kafka**服务器端**代码。社区还是希望用户只使用Kafka**客户端**代码，通过现有请求机制运维管理集群。这样所有运维操作都能纳入统一处理机制下，方便功能演进。
+- 只能运行在控制台。若想在应用程序、运维框架或是监控平台中集成难
+- 很多通过连接zk来提供服务。而社区越来越不推荐任何工具直连zk，因为这可能绕过Kafka安全设置。kafka-topics脚本连接zk时，不会考虑Kafka设置的用户认证机制。即任何使用该脚本的用户，不论是否具有创建主题的权限，都成功“跳过”权限检查，强行创建主题
+- 运行它们要用Kafka内部类实现，即Kafka**服务器端**代码。社区希望用户只用Kafka**客户端**代码，通过现有请求机制运维管理集群。这样所有运维操作都能统一处理，方便功能演进
-因此，社区于0.11版本正式推出Java客户端版AdminClient，**服务器端也有一个AdminClient**，包路径是kafka.admin，是之前的老运维工具类，提供的功能也比较有限，社区已经不再推荐使用它了。
+因此，社区0.11版推出Java客户端版AdminClient，**服务器端也有一个AdminClient**，包路径是kafka.admin，是之前的老运维工具类，提供的功能也比较有限，社区已经不再推荐使用它了。
所以，现在统一使用客户端的AdminClient。
-## 如何使用？
+## 2 咋用？
Java客户端提供的工具，要在你工程中显式增加依赖，以2.3版本为例。
@@ -30,54 +30,68 @@ Java客户端提供的工具，要在你工程中显式增加依赖，以2.3版
compile group: 'org.apache.kafka', name: 'kafka-clients', version: '2.3.0'
```
-## 功能
+## 3 功能
-2.3版本中，AdminClient提供功能有9大类：
+2.3版的AdminClient支持：
-1. 主题管理：包括主题的创建、删除和查询。
-2. 权限管理：包括具体权限的配置与删除。
-3. 配置参数管理：包括Kafka各种资源的参数设置、详情查询。所谓的Kafka资源，主要有Broker、主题、用户、Client-id等。
+1. 主题管理：包括主题创建、删除和查询
+2. 权限管理：包括具体权限的配置与删除
+3. 配置参数管理：包括Kafka各种资源的参数设置、详情查询。所谓的Kafka资源，主要有Broker、主题、用户、Client-id等
4. 副本日志管理：包括副本底层日志路径的变更和详情查询。
-5. 分区管理：即创建额外的主题分区。
-6. 消息删除：即删除指定位移之前的分区消息。
-7. Delegation Token管理：包括Delegation Token的创建、更新、过期和详情查询。
-8. 消费者组管理：包括消费者组的查询、位移查询和删除。
-9. Preferred领导者选举：推选指定主题分区的Preferred Broker为领导者。
+5. 分区管理：即创建额外的主题分区
+6. 消息删除：即删除指定位移之前的分区消息
+7. Delegation Token管理：包括Delegation Token的创建、更新、过期和详情查询
+8. 消费者组管理：包括消费者组的查询、位移查询和删除
+9. Preferred领导者选举：推选指定主题分区的Preferred Broker为领导者
-## 工作原理
+## 4 工作原理
-AdminClient是个双线程设计：
+AdminClient是双线程设计：
-- 前端主线程
+- 前端主线程：将用户要执行的操作转换成对应请求，发到后端I/O线程的队列
- 将用户要执行的操作转换成对应的请求，然后再将请求发送到后端I/O线程的队列
+- 后端I/O线程：从队列中读取相应请求，发到对应Broker节点，再把执行结果保存，待前端线程来获取
-- 后端I/O线程
-
- 从队列中读取相应请求，然后发到对应Broker节点，再把执行结果保存，等待前端线程来获取
使用生产者-消费者模式将请求生成与处理解耦：
-
+
+
+### 前端主线程
+
+会创建名为Call的请求对象实例。该实例有两个主要的任务。
+
+#### 构建对应的请求对象
+
+如若要创建主题，那么就创建CreateTopicsRequest；如果是查询消费者组位移，就创建OffsetFetchRequest。
+
+#### 指定响应的回调逻辑
+
+如从Broker端接收到CreateTopicsResponse之后要执行的动作。一旦创建好Call实例，前端主线程会将其放入到新请求队列（New Call Queue）中，此时，前端主线程的任务就算完成了。它只需要等待结果返回即可。
-前端主线程会创建名为Call的请求对象实例。该实例有两个主要的任务。
+剩下工作都是
-1. **构建对应的请求对象**。比如，如果要创建主题，那么就创建CreateTopicsRequest；如果是查询消费者组位移，就创建OffsetFetchRequest。
-2. **指定响应的回调逻辑**。比如从Broker端接收到CreateTopicsResponse之后要执行的动作。一旦创建好Call实例，前端主线程会将其放入到新请求队列（New Call Queue）中，此时，前端主线程的任务就算完成了。它只需要等待结果返回即可。
+### 后端I/O线程
-剩下的所有事情就都是后端I/O线程的工作了。就像图中所展示的那样，该线程使用了3个队列来承载不同时期的请求对象，它们分别是新请求队列、待发送请求队列和处理中请求队列。为什么要使用3个呢？原因是目前新请求队列的线程安全是由Java的monitor锁来保证的。**为了确保前端主线程不会因为monitor锁被阻塞，后端I/O线程会定期地将新请求队列中的所有Call实例全部搬移到待发送请求队列中进行处理**。图中的待发送请求队列和处理中请求队列只由后端I/O线程处理，因此无需任何锁机制来保证线程安全。
+该线程用3个队列来承载不同时期的请求对象：
-当I/O线程在处理某个请求时，它会显式地将该请求保存在处理中请求队列。一旦处理完成，I/O线程会自动地调用Call对象中的回调逻辑完成最后的处理。把这些都做完之后，I/O线程会通知前端主线程说结果已经准备完毕，这样前端主线程能够及时获取到执行操作的结果。AdminClient是使用Java Object对象的wait和notify实现的这种通知机制。
+- 新请求队列
+- 待发送请求队列
+- 处理中请求队列
-严格来说，AdminClient并没有使用Java已有的队列去实现上面的请求队列，它是使用ArrayList和HashMap这样的简单容器类，再配以monitor锁来保证线程安全的。不过，鉴于它们充当的角色就是请求队列这样的主体，我还是坚持使用队列来指代它们了。
+为啥要用3个？目前新请求队列的线程安全是由Java monitor锁保证。为确保前端主线程不会因monitor锁被阻塞，后端I/O线程定期将新请求队列中的所有Call实例全部搬移到待发送请求队列中进行处理。图中的待发送请求队列和处理中请求队列只由后端I/O线程处理，因此无需任何锁机制保证线程安全。
-了解AdminClient工作原理的一个好处在于，**它能够帮助我们有针对性地对调用AdminClient的程序进行调试**。
+当I/O线程在处理某请求时，它会显式将该请求保存在处理中请求队列。一旦处理完成，I/O线程会自动地调用Call对象中的回调逻辑完成最后的处理。把这些都做完之后，I/O线程会通知前端主线程说结果已经准备完毕，这样前端主线程能够及时获取到执行操作的结果。AdminClient是使用Java Object对象的wait和notify实现的这种通知机制。
-提到的后端I/O线程有名字，前缀kafka-admin-client-thread。有时发现，AdminClient程序貌似正常工作，但执行操作没返回结果或hang住，现在你该知道这可能因为I/O线程出现问题导致。碰到类似问题，不妨jstack查看AdminClient程序，确认I/O线程是否在正常工作。
+ AdminClient没有用Java已有的队列去实现上面的请求队列，它用ArrayList、HashMap这样的简单容器类，再配monitor锁来保证线程安全的。但鉴于它们充当的角色就是请求队列，我还是坚持用队列来指代它们。
+
+### AdminClient工作原理
+
+好在它能帮助针对性地对调用AdminClient的程序调试。后端I/O线程名有前缀kafka-admin-client-thread。有时AdminClient貌似正常工作，但执行操作没返回结果或hang住，现在你该知道这可能因为I/O线程异常。碰到类似问题，不妨jstack看AdminClient程序，确认I/O线程是否正常。
这是社区bug。这问题根本原因，就是I/O线程未捕获某些异常导致意外“挂”掉。由于AdminClient是双线程设计，前端主线程不受任何影响，依然可正常接收用户发送的命令请求，但此时程序已不能正常工作。
-## 构造和销毁AdminClient实例
+## 5 构造和销毁AdminClient实例
如果你正确地引入了kafka-clients依赖，那么你应该可以在编写Java程序时看到AdminClient对象。**切记它的完整类路径是org.apache.kafka.clients.admin.AdminClient，而不是kafka.admin.AdminClient**。后者就是我们刚才说的服务器端的AdminClient，它已经不被推荐使用了。
@@ -85,9 +99,7 @@ AdminClient是个双线程设计：
完整参数列表看[官网](https://kafka.apache.org/documentation/#adminclientconfigs)。如要销毁AdminClient实例，需显式调用AdminClient#close。
-## AdminClient实例的创建与销毁
-
-
+## 6 AdminClient实例的创建与销毁
```java
Properties props = new Properties();
@@ -99,7 +111,7 @@ try (AdminClient client = AdminClient.create(props)) {
}
```
-## 常见的AdminClient应用实例
+## 7 AdminClient应用
讲完了AdminClient的工作原理和构造方法，接下来，我举几个实际的代码程序来说明一下如何应用它。这几个例子，都是我们最常见的。
@@ -142,15 +154,17 @@ try (AdminClient client = AdminClient.create(props)) {
### 获取Broker磁盘占用
-现在，我们来使用AdminClient实现一个稍微高级一点的功能：获取某台Broker上Kafka主题占用的磁盘空间量。有些遗憾的是，目前Kafka的JMX监控指标没有提供这样的功能，而磁盘占用这件事，是很多Kafka运维人员要实时监控并且极为重视的。
+获取某Broker上Kafka主题占用磁盘量。目前Kafka的JMX监控指标未提供该功能，而磁盘占用是很多Kafka运维需实时监控且重视。
-幸运的是，我们可以使用AdminClient来实现这一功能。代码如下：
+好在可用AdminClient实现：
```scala
try (AdminClient client = AdminClient.create(props)) {
+ // 使用AdminClient#describeLogDirs获取指定Broker上所有分区主题的日志路径信息
DescribeLogDirsResult ret = client.describeLogDirs(Collections.singletonList(targetBrokerId)); // 指定Broker id
long size = 0L;
for (Map logDirInfoMap : ret.all().get().values()) {
+ // 然后把它们累积在一起，得出总磁盘占用量
size += logDirInfoMap.values().stream().map(logDirInfo -> logDirInfo.replicaInfos).flatMap(
topicPartitionReplicaInfoMap ->
topicPartitionReplicaInfoMap.values().stream().map(replicaInfo -> replicaInfo.size))
@@ -158,6 +172,4 @@ try (AdminClient client = AdminClient.create(props)) {
}
System.out.println(size);
}
-```
-
-使用AdminClient的**describeLogDirs方法**获取指定Broker上所有分区主题的日志路径信息，然后把它们累积在一起，得出总磁盘占用量。
\ No newline at end of file
+```
\ No newline at end of file
diff --git a/docs/md/mysql/mysql-index-left-most-matching-rule.md b/docs/md/mysql/mysql-index-left-most-matching-rule.md
new file mode 100644
index 0000000000..6a19d76dca
--- /dev/null
+++ b/docs/md/mysql/mysql-index-left-most-matching-rule.md
@@ -0,0 +1,668 @@
+# MySQL索引最左匹配原则及优化原理
+
+## 1 索引的好处
+
+- 大大减少存储引擎需要扫描的数据量
+- 排序以避免使用临时表
+- 把随机I/O变为顺序I/O
+
+## 2 实例
+
+执行：
+
+```sql
+ select * from T where k between 3 and 5
+```
+
+需几次树的搜索，扫描多少行？
+
+创建表：
+
+```sql
+mysql> create table T (
+ -> ID int primary key,
+ -> k int NOT NULL DEFAULT 0,
+ -> s varchar(16) NOT NULL DEFAULT '',
+ -> index k(k)
+ -> engine=InnoDB;
+Query OK, 0 rows affected (0.04 sec)
+```
+
+插入数据：
+
+```sql
+insert into T values(100, 1, 'aa'), (200, 2, 'bb'), (300, 3, 'cc'), (500, 5, 'ee'), (600, 6, 'ff'), (700, 7, 'gg');
+```
+
+InnoDB索引组织结构：
+
+
+
+SQL查询语句的执行流程：
+
+1. 在k索引树找到k=3，取得 ID 300
+2. 再到ID树查到ID 300对应的R3
+3. 在k树取下个值5，取得ID 500
+4. 再回到ID树查到ID 500对应R4
+5. 在k树取下个值6，不满足条件，循环结束
+
+回到主键索引树搜索的过程，称为回表。
+查询过程读了k索引树的3条记录（步骤135），回表两次（24）
+由于查询结果所需数据只在主键索引有，不得不回表。那么，有无可能经过索引优化，避免回表？
+
+## 3 覆盖索引
+
+执行语句
+
+```sql
+select ID from T where k between 3 and 5
+```
+
+只需查ID值，而ID值已在k索引树，因此可直接提供结果，不需回表。即在该查询，索引k已“覆盖”我们的查询需求，称为覆盖索引。
+
+覆盖索引可减少树的搜索次数，显著提升查询性能，使用覆盖索引是个常用性能优化手段。
+
+使用覆盖索引在索引k上其实读了三个记录，R3~R5（对应的索引k上的记录项）
+但对于Server层，就是找引擎拿到两条记录，因此MySQL认为扫描行数是2。
+
+## 问题
+
+在一个市民信息表，有必要将身份证号和名字建立联合索引？
+
+假设这个市民表的定义：
+
+```sql
+CREATE TABLE `tuser` (
+ `id` int(11) NOT NULL,
+ `id_card` varchar(32) DEFAULT NULL,
+ `name` varchar(32) DEFAULT NULL,
+ `age` int(11) DEFAULT NULL,
+ `ismale` tinyint(1) DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `id_card` (`id_card`),
+ KEY `name_age` (`name`,`age`)
+) ENGINE=InnoDB
+```
+
+身份证号是市民唯一标识。有根据身份证号查询市民信息的，只要在身份证号字段建立索引即可。再建立一个（身份证号、姓名）联合索引，是不是浪费空间？
+
+如果现在有一个高频请求，根据身份证号查询姓名，联合索引就有意义了。可在这个高频请求上用到覆盖索引，不再回表查整行记录，减少了执行时间。
+当然索引字段的维护总是有代价。建立冗余索引支持覆盖索引就需权衡考虑。
+
+## 2 何时用索引
+
+(1) 定义有主键的列一定要建立索引 : 主键可以加速定位到表中的某行
+(2) 定义有外键的列一定要建立索引 : 外键列通常用于表与表之间的连接，在其上创建索引可以加快表间的连接
+(3) 对于经常查询的数据列最好建立索引
+ ① 对于需要在指定范围内快速或频繁查询的数据列，因为索引已经排序，其指定的范围是连续的，查询可以利用索引的排序，加快查询的时间
+② 经常用在 `where`子句中的数据列，将索引建立在`where`子句的集合过程中，对于需要加速或频繁检索的数据列，可以让这些经常参与查询的数据列按照索引的排序进行查询，加快查询的时间
+
+如果为每一种查询都设计个索引，索引是不是太多？
+如果我现在要按身份证号去查家庭地址？虽然该需求概率不高，但总不能让它全表扫描？
+但单独为一个不频繁请求创建（身份证号，地址）索引又有点浪费。怎么做？
+
+B+树这种索引，可利用索引的“最左前缀”，来定位记录。
+
+（name，age）联合索引分析：
+
+
+
+索引项按照索引定义出现的字段顺序排序。
+
+当逻辑需求是查到所有名字“张三”的，可快速定位到ID4，然后向后遍历得到所有结果。
+要查所有名字第一个字“张”的，条件"where name like ‘张%’"。也能够用上索引，查找到第一个符合条件的记录是ID3，然后向后遍历，直到不满足。
+
+不只是索引的全部定义，只要满足最左前缀，就可利用索引加速。
+最左前缀可以是
+
+- 联合索引的最左N个字段
+- 字符串索引的最左M个字符
+
+
+## 联合索引内的字段顺序
+
+- 标准
+ 索引的复用能力。因为可以支持最左前缀，所以当已经有了(a,b)这个联合索引后，一般就不需要单独在a上建立索引了。
+- 原则
+ 如果调整顺序，可少维护一个索引，那么这顺序优先考虑。
+
+为高频请求创建(身份证号，姓名）联合索引，并用这索引支持“身份证号查地址”需求。
+
+如果既有联合查询，又有基于a、b各自的查询？
+查询条件里只有b的，无法使用(a,b)联合索引，这时不得不维护另外一个索引，即需同时维护(a,b)、(b) 两个索引。
+
+- 这时要考虑原则就是空间
+ 比如市民表，name字段比age字段大 ，建议创建一个（name,age)的联合索引和一个(age)的单字段索引
+
+## 3 索引优化
+
+MySQL的优化主要分为
+
+- 结构优化（Scheme optimization）
+- 查询优化（Query optimization）
+
+讨论的高性能索引策略主要属于结构优化。
+
+为了讨论索引策略，需要一个数据量不算小的数据库作为示例
+选用MySQL官方文档中提供的示例数据库之一：employees
+这个数据库关系复杂度适中，且数据量较大。下图是这个数据库的E-R关系图（引用自MySQL官方手册）：示例数据库
+
+
+
+## 3.1 最左前缀原理与相关优化
+
+要知道什么样的查询会用到索引，和B+Tree中的“最左前缀原理”有关。
+
+### 联合索引（又名复合索引）
+
+MySQL中的索引可以以一定顺序引用多列，这种索引叫做`联合索引`，是个有序元组。
+
+`如何选择索引列的顺序`
+
+- 经常会被使用到的列优先
+- 选择性高的列优先
+- 宽度小的列优先
+
+### 覆盖索引(Covering Indexes)
+
+包含满足查询的所有列。只访问索引的查询，只需读索引而不用读数据。
+
+#### 优点
+
+- 索引项通常比记录要小，使得MySQL访问更少数据
+- 索引都按值排序存储，相对于随机访问记录，需要更少I/O
+- 大多数据引擎能更好的缓存索引。比如MyISAM只缓存索引
+- 因为InnoDB使用`聚集索引`组织数据，若二级索引中包含查询所需的数据，就无需回表
+- 可以优化缓存，减少磁盘IO操作
+- 可以减少随机IO，变随机IO操作变为顺序IO操作
+- 可以避免MyISAM表进行系统调用
+
+覆盖索引只有B-TREE索引存储相应的值，并非所有存储引擎都支持覆盖索引(Memory/Falcon就不支持)。
+
+对于索引覆盖查询(index-covered query)，使用`EXPLAIN`时，可以在`Extra`列中看到`Using index`。
+
+在大多数引擎中，只有当查询语句所访问的列是索引的一部分时，索引才会覆盖
+但是，`InnoDB`不限于此，`InnoDB`的二级索引在叶节点中存储了primary key的值
+
+#### 覆盖索引失效场景
+
+- 存储引擎不支持覆盖索引
+- 查询中使用了太多的列
+- 使用了双%号的like查询
+
+- 使用覆盖索引查询数据
+
+```java
+mysql> explain select language_id from film where language_id=1\G
+*************************** 1. row ***************************
+ id: 1
+ select_type: SIMPLE
+ table: film
+ type: ref
+possible_keys: idx_fk_language_id
+ key: idx_fk_language_id
+ key_len: 1
+ ref: const
+ rows: 1000
+ Extra: Using index
+```
+
+select *不能用覆盖索引：
+
+```java
+mysql> explain select * from film where language_id=1\G
+*************************** 1. row ***************************
+ id: 1
+ select_type: SIMPLE
+ table: film
+ type: ALL
+possible_keys: idx_fk_language_id
+ key: NULL
+ key_len: NULL
+ ref: NULL
+ rows: 775
+ Extra: Using where
+```
+
+```java
+mysql> explain select actor_id, last_name from actor where last_name='Joe'\G
+*************************** 1. row ***************************
+ id: 1
+ select_type: SIMPLE
+ table: actor
+ type: ref
+possible_keys: idx_actor_last_name
+ key: idx_actor_last_name
+ key_len: 137
+ ref: const
+ rows: 1
+ Extra: Using where; Using index
+```
+
+以employees.titles表为例，先看有啥索引：
+
+```java
+SHOW INDEX FROM employees.titles;
++---------+------------+----------------+-------------+--------------+------+---------------+
+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Null | Index_type |
++---------+------------+----------------+-------------+--------------+------+---------------+
+| titles | 0 | PRIMARY | 1 | emp_no | A | NULL | | BTREE |
+| titles | 0 | PRIMARY | 2 | title | A | NULL | | BTREE |
+| titles | 0 | PRIMARY | 3 | from_date | A | 443308 | | BTREE |
+| titles | 1 | emp_no | 1 | emp_no | A | 443308 | | BTREE |
++---------+------------+----------------+-------------+--------------+------+---------------+
+```
+
+titles表主索引为，辅助索引。为避免多个索引使事情复杂（MySQL的优化器在多索引时行为较复杂)，将辅助索引drop：
+
+```sql
+ALTER TABLE employees.titles DROP INDEX emp_no;
+```
+
+专心分析PRIMARY索引
+
+#### 1 全值匹配
+
+```sql
+EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND title='Senior Engineer' AND from_date='1986-06-26';
++----+-------------+---------+--------+---------------+---------+---------+---------------------+------+-------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+--------+---------------+---------+---------+---------------------+------+-------+
+| 1 | SIMPLE | titles | const | PRIMARY | PRIMARY | 59 | const,const,const | 1 | |
++----+-------------+---------+--------+---------------+---------+---------+---------------------+------+-------+
+```
+
+按索引中所有列进行精确匹配（“=”或“IN”匹配)时，索引可用到。索引对顺序敏感，但MySQL查询优化器会自动调整where子句的条件顺序以使用适合索引。
+
+如将where中的条件顺序颠倒：
+
+```java
+EXPLAIN SELECT * FROM employees.titles WHERE from_date='1986-06-26' AND emp_no='10001' AND title='Senior Engineer';
++----+-------------+---------+--------+---------------+---------+---------+---------------------+------+-------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+--------+---------------+---------+---------+---------------------+------+-------+
+| 1 | SIMPLE | titles | const | PRIMARY | PRIMARY | 59 | const,const,const | 1 | |
++----+-------------+---------+--------+---------------+---------+---------+---------------------+------+-------+
+```
+
+效果一样。
+
+#### 2 最左前缀匹配
+
+当查询条件精确匹配索引的左边连续一个或几个列时，如或，索引可以被用到，但是只能用到一部分，即条件所组成的最左前缀。
+
+看到PRIMARY索引，但key_len=4，说明只用到索引第一列前缀：
+
+```java
+EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001';
++----+-------------+---------+--------+---------------+---------+---------+------+------+-------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+--------+---------------+---------+---------+------+------+-------+
+| 1 | SIMPLE | titles | ref | PRIMARY | PRIMARY | 4 | const| 1 | |
++----+-------------+---------+--------+---------------+---------+---------+------+------+-------+
+```
+
+#### 3 查询条件用到索引中列的精确匹配，但是中间某个条件未提供
+
+```java
+EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND from_date='1986-06-26';
++----+-------------+---------+--------+---------------+---------+---------+------+------+----------------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+--------+---------------+---------+---------+------+------+----------------+
+| 1 | SIMPLE | titles | ref | PRIMARY | PRIMARY | 4 | const| 1 | Using where |
++----+-------------+---------+--------+---------------+---------+---------+------+------+----------------+
+```
+
+索引使用情况和情况二相同，因title未提供，虽然 `from_date` 在主键索引中，但由于查询条件中没有提供 `title` 字段，无法形成索引的左前缀匹配，因此 MySQL 只能使用索引的第一列 `emp_no` 进行查找。之后还需要对符合条件的记录进行 `from_date` 的额外过滤（`Using where`）。虽然 `emp_no` 是唯一的，但在执行计划中仍可能扫描多个记录（比如同一个 `emp_no` 对应不同 `title` 的情况）。
+
+### 📝 示例说明：
+
+假设表数据：
+
+| | | |
+| ----- | --------------- | ---------- |
+| 10001 | Engineer | 1986-06-26 |
+| 10001 | Senior Engineer | 1995-01-01 |
+
+当执行：
+
+```sql
+WHERE emp_no='10001' AND from_date='1986-06-26'
+```
+
+MySQL 会：
+
+1. 利用索引查出所有 `emp_no = '10001'` 的记录；
+2. 再在这些记录中筛选出 `from_date = '1986-06-26'` 的那条。
+
+这就是为什么会出现 `Using where` 的原因。
+
+想让`from_date`也使用索引而不是where过滤，可以增加一个辅助索引``，此时上面的查询会使用这个索引。
+
+
+
+还可用“隔离列”的优化方法，将`emp_no`与`from_date`之间的“坑”填上。看title有几种不同值：
+
+```java
+SELECT DISTINCT(title) FROM employees.titles;
++-----------------+
+| title |
++-----------------+
+| Senior Engineer |
+| Staff |
+| Engineer |
+| Senior Staff |
+| Assistant Engineer |
+| Technique Leader |
+| Manager |
++-----------------+
+```
+
+7种。在这种成为“坑”的列值比较少的情况下，考虑用“IN”来填补这个“坑”从而形成最左前缀
+
+```java
+EXPLAIN SELECT * FROM employees.titles
+WHERE emp_no='10001'
+AND title IN ('Senior Engineer', 'Staff', 'Engineer', 'Senior Staff', 'Assistant Engineer', 'Technique Leader', 'Manager')
+AND from_date='1986-06-26';
++----+-------------+---------+--------+---------------+---------+---------+------+------+----------------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+--------+---------------+---------+---------+------+------+----------------+
+| 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 59 | NULL | 7 | Using where |
++----+-------------+---------+--------+---------------+---------+---------+------+------+----------------+
+```
+
+key_len=59，索引被用全，但从type和rows看出IN实际执行了一个range查询，这检查了7个key。
+
+看两种查询性能比较：
+
+```java
+SHOW PROFILES;
++----------+-------------+---------------------------------------------------------+
+| Query_ID | Duration | Query |
++----------+-------------+---------------------------------------------------------+
+| 10 | 0.00058000 | SELECT * FROM employees.titles WHERE emp_no='10001' AND from_date='1986-06-26' |
+| 11 | 0.00052500 | SELECT * FROM employees.titles WHERE emp_no='10001' AND title IN ... |
++----------+-------------+---------------------------------------------------------+
+```
+
+“填坑”后性能提升一点。如果经过emp_no筛选后余下很多数据，则后者性能优势更明显。当然，如果title的值很多，用填坑就不合适了，须建立辅助索引。
+
+#### 4 未指定索引第一列
+
+```java
+EXPLAIN SELECT * FROM employees.titles WHERE from_date='1986-06-26';
++----+-------------+---------+------+---------------+------+---------+------+------+----------------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+------+---------------+------+---------+------+------+----------------+
+| 1 | SIMPLE | titles | ALL | NULL | NULL | NULL | NULL | 443308 | Using where |
++----+-------------+---------+------+---------------+------+---------+------+------+----------------+
+```
+
+由于不是最左前缀，显然用不到索引。
+
+#### 5 匹配某列的前缀字符串
+
+```java
+EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND title LIKE 'Senior%';
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+| 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 56 | NULL | 1 | Using where |
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+```
+
+可用到索引，通配符%不出现在开头，则可以用到索引，但根据具体情况不同可能只会用其中一个前缀。
+
+#### 6 范围查询
+
+由于B+树的顺序特点，尤其适合。
+
+```java
+EXPLAIN SELECT * FROM employees.titles WHERE emp_no < '10010' AND title='Senior Engineer';
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+| 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 4 | NULL | 16 | Using where |
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+```
+
+- 范围列可用到索引（须是最左前缀），但范围列后面的列无法用到索引
+- 索引最多用于一个范围列，因此若查询条件中有两个范围列，则无法全用到索引
+
+```java
+EXPLAIN SELECT * FROM employees.titles
+WHERE emp_no < '10010'
+AND title='Senior Engineer'
+AND from_date BETWEEN '1986-01-01' AND '1986-12-31';
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+| 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 4 | NULL | 16 | Using where |
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+```
+
+
+- 可见索引对第二个范围索引无能为力。仅用explain可能无法区分范围索引和多值匹配，因为type中都显示range
+- between不意味着就是范围查询，如：
+
+```java
+EXPLAIN SELECT * FROM employees.titles
+WHERE emp_no BETWEEN '10001' AND '10010'
+AND title='Senior Engineer'
+AND from_date BETWEEN '1986-01-01' AND '1986-12-31';
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+| 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 59 | NULL | 16 | Using where |
++----+-------------+---------+-------+---------------+---------+---------+------+------+----------------+
+```
+
+看起来是用了两个范围查询，但作用于emp_no上的“BETWEEN”实际上相当于“IN”，即emp_no实际是多值精确匹配。可以看到该查询用到索引全部三列。因此MySQL中要谨慎区分多值匹配、范围匹配，否则困惑MySQL行为。
+
+精确匹配左前列并范围匹配另外一列。
+
+#### 7 查询条件中含有函数或表达式
+
+查询条件含有函数或表达式，则MySQL不会为这列用索引（虽然某些在数学意义上可用）：
+
+```java
+EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND left(title, 6)='Senior';
++----+-------------+---------+------+---------------+---------+---------+------+------+----------------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+------+---------------+---------+---------+------+------+----------------+
+| 1 | SIMPLE | titles | ref | PRIMARY | PRIMARY | 4 | const| 1 | Using where |
++----+-------------+---------+------+---------------+---------+---------+------+------+----------------+
+```
+
+虽然该查询和情况5中功能相同，但是由于使用了函数left，则无法为title列应用索引，而情况五中用LIKE则可以。再如：
+
+```sql
+EXPLAIN SELECT * FROM employees.titles WHERE emp_no - 1='10000';
++----+-------------+---------+------+---------------+------+---------+------+------+----------------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+---------+------+---------------+------+---------+------+------+----------------+
+| 1 | SIMPLE | titles | ALL | NULL | NULL | NULL | NULL | 443308 | Using where |
++----+-------------+---------+------+---------------+------+---------+------+------+----------------+
+```
+
+这查询等价于查询emp_no=10001的函数，但查询条件是个表达式，MySQL无法为其使用索引。看来MySQL还没智能到自动优化常量表达式，因此尽量避免表达式出现在查询中，而是先手工私下代数运算，转换为无表达式的查询语句。
+
+
+
+## 3.4 Btree索引的限制
+
+- 若不是从**索引的最左列**开始查找，则无法使用索引
+- 使用索引时不能**跳过**索引中的列
+- Not in和<>操作无法使用索引
+- 若查询中有某列的范围查询，则其右边所有列都无法使用索引
+
+### 3.4.1 即使设置索引，也无法使用
+
+- “%”开头的LIKE语句，模糊匹配
+- OR语句，**前后没有同时使用索引**
+- 数据类型出现隐式转化（如varchar不加单引号，可能会自动转int型）
+
+### 3.4.2 索引选择性与前缀索引
+
+#### 既然索引可加速查询，是否只要是查询语句，就建索引?
+
+NO！因为索引虽然加速查询，但索引也有代价：索引文件本身要消耗存储空间。
+
+- 索引会加重插入、删除和修改记录时的负担，增加写操作的成本
+- 太多索引会增加查询优化器的分析选择时间
+- MySQL在运行时也要消耗资源维护索引
+
+但索引绝非银弹，并非越多越好：
+
+#### 不推荐创建索引的场景
+
+- 查询中很少涉及的列
+ 例如，在查询中很少使用的列，有索引并不能提高查询的速度，相反增加了系统维护时间和消耗了系统空间
+- 重复值较多的列
+ “性别”列只有列值“男”和“女”，增加索引并不能显著提高查询的速度
+- 定义为text、image和bit数据类型的列
+ 这些数据类型的数据列的数据量要么很大，要么很小，不利于使用索引
+- 表记录比较少
+ 例如一两千条甚至只有几百条记录的表，没必要建索引，让查询做全表扫描就好了
+- 索引的选择性较低
+ 索引的选择性（Selectivity），是指不重复的索引值（也叫基数，Cardinality）与表记录数（#T）的比值
+ `Index Selectivity = Cardinality / #T`
+
+```sql
+CREATE INDEX index_ name ON table(col_ name(n));
+```
+
+
+
+显然选择性的取值范围为(0, 1]，选择性越高的索引价值越大，这是由B+Tree的性质决定的。
+如employees.titles表，若title字段常被单独查询，是否需建索引，看其选择性：
+
+```java
+SELECT count(DISTINCT(title)) / count(*) AS Selectivity FROM employees.titles;
++-------------+
+| Selectivity |
++-------------+
+| 0.000 |
++-------------+
+```
+
+title的选择性不足0.0001（精确值为0.00001579)，所以实在没有什么必要为其单独建索引
+
+## 前缀索引
+
+用列的前缀代替整列作为索引key，当前缀长度合适时，可实现既使得前缀索引的选择性接近全列索引，又因为索引key变短而减少索引文件的大小和维护开销。
+
+以employees.employees表为例介绍前缀索引的选择和使用。
+
+从图12可以看到employees表只有一个索引``，那么如果我们想按名字搜索人，就只能全表扫描
+
+```sql
+EXPLAIN SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido';
++----+-------------+------------+------+---------------+------+---------+------+------+----------------+
+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
++----+-------------+------------+------+---------------+------+---------+------+------+----------------+
+| 1 | SIMPLE | employees | ALL | NULL | NULL | NULL | NULL | 300024 | Using where |
++----+-------------+------------+------+---------------+------+------+------+------+----------------+
+```
+
+若频繁按名字搜索员工，显然效率很低，考虑建索引。两种选择：
+
+-
+-
+
+这两个索引的选择性：
+
+```sql
+SELECT count(DISTINCT(first_name)) / count(*) AS Selectivity FROM employees.employees;
++-------------+
+| Selectivity |
++-------------+
+| 0.0042 |
++-------------+
+
+SELECT count(DISTINCT(concat(first_name, last_name))) / count(*) AS Selectivity FROM employees.employees;
++-------------+
+| Selectivity |
++-------------+
+| 0.9313 |
++-------------+
+```
+
+显然选择性太低，选择性很好。但first_name + last_name长度30，有没有兼顾长度和选择性的办法？
+
+考虑first_name + 【last_name的前几个字符】建立索引，如，选择性：
+
+```java
+SELECT count(DISTINCT(concat(first_name, left(last_name, 3)))) / count(*) AS Selectivity FROM employees.employees;
++-------------+
+| Selectivity |
++-------------+
+| 0.7879 |
++-------------+
+```
+
+选择性还不错，但离0.9313还是有点距离，把last_name前缀加到4：
+
+```java
+SELECT count(DISTINCT(concat(first_name, left(last_name, 4)))) / count(*) AS Selectivity FROM employees.employees;
++-------------+
+| Selectivity |
++-------------+
+| 0.9007 |
++-------------+
+```
+
+选择性已很理想，而该索引长度仅18，比短一半。把该前缀索引建上：
+
+1. ALTER TABLE employees.employees
+2. ADD INDEX `first_name_last_name4` (first_name, last_name(4));
+
+再执行一遍按名字查询，比较建索引前的结果：
+
+```sql
++----------+-------------+-----------------------------------------------+
+| Query_ID | Duration | Query |
++----------+-------------+-----------------------------------------------+
+| 87 | 0.11941700 | SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido' |
+| 90 | 0.00092400 | SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido' |
++----------+-------------+-----------------------------------------------+
+```
+
+性能提升显著，查询加速120多倍。前缀索引兼顾索引大小和查询速度，但：
+
+#### 缺点
+
+- 不能用于ORDER BY、GROUP BY
+- 也不能用于Covering index（即当索引本身包含查询所需全部数据时，不再访问数据文件本身）
+
+## 索引小窍门
+
+全值匹配我最爱，最左前缀要遵守
+索引列上少计算，范围之后全失效
+Like百分写最右，覆盖索引不写*
+不等空值还有or，索引失效要少用
+字符引号不能丢
+
+## 3.5 主键选择
+
+在使用InnoDB存储引擎时，如果没有特别的需要，请永远使用一个与`业务无关的自增字段`作为主键。
+
+有人建议业务无关的自增主键，有人觉得没必要，完全可用如学号或身份证号唯一字段作主键。大多观点`论据都是业务层面`。若从`数据库索引优化`角度，使用InnoDB引擎而不用自增主键，绝对是糟糕主意。
+
+InnoDB使用聚集索引，数据记录本身被存于主索引（一颗B+Tree）的叶子节点。这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放，因此每当有一条新的记录插入时，MySQL按其主键将其插入适当的节点和位置，如果页面达到装载因子（InnoDB默认为15/16），则开辟一个新页（节点）。
+
+若表用自增主键，则每次插入新的记录，记录就顺序添加到当前索引节点的后续位置，当一页写满，自动开辟一个新页：
+
+
+
+就会形成一个紧凑的索引结构，近似顺序填满。
+由于每次插入时也不需要移动已有数据，因此效率很高，也不会增加很多开销在维护索引上。
+
+如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置：
+
+
+
+此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。
+
+因此，只要可以，请尽量在InnoDB上采用自增字段做主键。
\ No newline at end of file
diff --git a/docs/md/mysql/mysql-transaction-isolation-mechanism.md b/docs/md/mysql/mysql-transaction-isolation-mechanism.md
new file mode 100644
index 0000000000..4667d14894
--- /dev/null
+++ b/docs/md/mysql/mysql-transaction-isolation-mechanism.md
@@ -0,0 +1,497 @@
+# MySQL是怎么实现事务隔离的？
+
+## 0 前言
+
+一个事务要更新一行，若恰有另一事务持有该行的行锁，它会被锁住。既然进入等待状态，那等该事务自己获取到行锁要更新数据时，它读到的值又是啥？
+
+## 1 案例
+
+### 1.1 数据初始化
+
+```sql
+mysql> CREATE TABLE `t`
+ -> (
+ -> `id` int(11) NOT NULL,
+ -> `k` int(11) DEFAULT NULL,
+ -> PRIMARY KEY (`id`)
+ -> ) ENGINE = InnoDB;
+Query OK, 0 rows affected, 2 warnings (0.01 sec)
+
+mysql>
+mysql> insert into t(id, k)
+ -> values (1, 1),
+ -> (2, 2);
+```
+
+### 1.2 事务执行流程
+
+| 事务A | 事务B | 事务C |
+| ------------------------------------------- | ------------------------------------------------------------ | ------------------------------ |
+| start transaction with consistent snapshot; | | |
+| | start transaction with consistent snapshot; | |
+| | | update t set k=k+1 where id=1; |
+| | update t set k=k+1 where id=1;
select k from t where id=1; | |
+| select k from t where id=1;
commit; | | |
+| | commit; | |
+
+### 1.3 事务启动时机
+
+- begin/start transaction：在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动。一致性视图是在执行【第一个快照读语句】时创建
+- **start transaction with consistent snapshot**：想立马启动一个事务时用。一致性视图是在执行【start transaction with consistent snapshot】时创建
+
+默认`autocommit=1`。该案例中：
+
+- 事务C未显式用begin/commit，即该update语句本身就是个事务，语句完成时自动提交
+- 事务B更新行后，就查询
+- 事务A在一个只读事务中查询，时间上在事务B的查询后
+
+## 2 undo log链
+
+每条undo log有两个隐藏字段：
+
+- trx_id：最近一次更新这条数据的事务id
+
+- roll_pointer：指向更新这个事务之前生成的undo log
+
+
+若有一事务A（id=50）插入一条数据，则该数据隐藏字段及指向的undo log如下：roll_pointer指向一个空undo log，因为之前没这条数据
+
+
+
+再有一事务B修改该数据，改成值B，事务B的id是53，此时更新之前会生成一个undo log记录之前的值，然后roll_pointer指向这个实际的undo log回滚日志：
+
+
+
+roll_pointer指向undo log，这undo log就记录你更新之前的那条数据的值。
+
+再事务C来修改这值为C，其事务id=60，此时会把数据行里的txr_id改成60，然后生成一条undo log，记录之前事务B修改的那个值：
+
+
+
+多个事务串行执行时，每个人修改了一行数据，都会更新隐藏字段txr_id和roll_pointer，同时之前多个数据快照对应的undo log，会通过roll_pinter指针串联起来，形成版本链！
+
+## 3 视图（ReadView）
+
+执行一个事务时，就给你生成一个ReadView，其关键组成：
+
+- m_ids：此时有哪些事务在MySQL里执行还没提交
+
+- min_trx_id：m_ids里最小的值
+
+- max_trx_id：MySQL下一个要生成的事务id，就是最大事务id
+
+- creator_trx_id：你这个事务的id
+
+若原有一行数据，很早就有事务插入过了，事务id是32，他的值就是初始值：
+
+
+
+此时两个事务并发来执行了：
+
+- 事务A（id=45）：读取这行数据的值
+
+- 事务B（id=59）：更新这行数据的
+
+
+现在A直接开启一个ReadView：
+
+- m_ids包含事务A、B的id：45和59
+- min_trx_id=45
+- max_trx_id=60
+- creator_trx_id=45，事务A自己
+
+事务A第一次查询该行数据，判断：
+
+```
+当前这行数据的txr_id ＜ReadView中的min_trx_id？
+```
+
+txr_id=32小于ReadView里的min_trx_id 45，说明事务开启前，修改这行数据的事务早就提交，所以此时可以查到这行数据。
+
+接着B把这行数据的值修改为了值b，然后这行数据txr_id设为自己的id=59，roll_pointer指向修改之前生成的一个undo log，接着这个事务B就提交了：
+
+
+
+A再次查询，发现此时数据行里的txr_id=59：
+
+ReadView里的max_trx_id（60) ＞ txr_id ＞ ReadView里的min_txr_id(45)
+
+说明更新这条数据的事务，很可能就跟自己差不多同时开启，于是会看txr_id=59是否在ReadView的m_ids列表。果然就有45和59两个事务id，证实这修改数据的事务是和自己同一时段并发执行然后提交的，所以对这行数据不能查询！
+
+那查啥？顺着这条数据的roll_pointer顺着undo log日志链条往下找，就会找到最近的一条undo log，发现trx_id=32，小于ReadView里的min_trx_id（45），说明该undo log版本在A开启前就执行且提交。那就查询最近那undo log里的值，这就是undo log多版本链的作用，可保存一个快照链，让你能读到之前的快照值：
+
+
+
+多事务并发时，事务B更新的值，通过这套**ReadView+undo log**日志链机制，保证A不会读到并发执行的B更新的值，而只会读到之前最早的值。
+
+接着若事务A更新了这行数据的值，改成值a，trx_id修改为45，同时保存之前事务B修改的值的快照：
+
+
+
+此时A来查询这条数据的值，发现trx_id=45，和自己ReadView里的creator_trx_id（45）一样，说明这行数据就是自己修改的，自己修改的值当然可见。
+
+
+
+接着在事务A执行的过程中，突然开启事务C，事务id=78，然后他更新那行数据为值C，还提交了：
+
+
+
+这时A再查询，发现当前数据trx_id=78＞自己ReadView的max_trx_id（60)，说明A开启后，然后有个事务更新了数据，自己当然不能看到！
+
+就顺undo log多版本链往下找，先找到值a，自己之前修改的过的那个版本，因为那个trx_id=45跟自己的ReadView里的creator_trx_id一样，所以此时直接读取自己之前修改的那个版本。
+
+## 4 小结
+
+通过undo log多版本链，加上开启事务时产生的ReadView，然后再有一个查询时，根据ReadView进行判断，就能知你应读取哪个版本数据，保证你
+
+### 能读到
+
+- 你事务开启前，其它已提交事务更新的值
+
+- 还有你自己事务更新的值
+
+### 读不到
+
+- 若你事务开启前，就有其它事务在运行，当你事务开启后，其它事务更新了值
+- 你事务开启后，比你晚开启的事务更新了值
+
+通过这套机制就可以实现多个事务并发执行时候的数据隔离。
+
+## 5 RC级实现
+
+事务运行期，只要其它事务修改数据并提交，即可读到人家修改的数据，所以会不可重复读、幻读。
+
+ReadView机制基于undo log版本链实现的一套读视图机制，事务生成一个ReadView：
+
+- 若为事务自己更新的数据，自己可读到
+- 或你生成ReadView之前的已提交的事务所修改值，也可读到
+- 但若你生成ReadView时，就已经活跃的事务，但如果它在你生成ReadView之后修改的数据并提交了，此时你读不到
+- 或你生成ReadView以后再开启的事务修改了数据，还提交了，也读不到
+
+所以上面那套机制就是ReadView的一个原理。咋基于ReadView实现RC？当一个事务设置RC，他是每次发起查询，都重新生成一个ReadView！
+
+数据库有行数据，是事务id=50的一个事务很久前插入的，而当前活跃事务：
+
+- 事务A（id=60）
+- 事务B（id=70）
+
+现在事务B发起update，更新这条数据为b，所以此时数据的trx_id会变为事务B的id=70，同时生成一条undo log：
+
+
+
+这时，事务A要发起一次查询操作，就生成一个ReadView：
+
+
+
+这时事务A发起查询，发现当前数据trx_id=70。即属于ReadView的事务id范围之间，说明是他生成ReadView之前就有这活跃的事务，是这事务修改了这条数据的值，但此时事务B还没提交，所以ReadView的m_ids活跃事务列表里，有[60, 70]两个id，此时根据ReadView机制，事务A无法查到事务B修改的值b。
+
+就顺undo log版本链往下找，就找到一个原始值，发现其trx_id是50，小于当前ReadView里的min_trx_id，说明是他生成ReadView之前，就有一个事务插入了这个值并且早就提交了，因此可以查到这个原始值。
+
+接着，假设事务B提交，提交了就说明事务B不会活跃于数据库里了。事务A下次再查询，就可以读到事务B修改过的值了。那到底是怎么让事务A能够读到提交的事务B修改过的值呢？
+
+让事务A下次发起查询，再生成一个ReadView，数据库内活跃的事务只有事务A，因此：
+
+- min_trx_id是60
+- mac_trx_id是71
+- m_ids=60，事务B的id=70不会出现在m_ids活跃事务列表
+
+此时事务A再基于这ReadView去查询，会发现这条数据的trx_id=70，虽然在ReadView的min_trx_id和max_trx_id范围之间，但是此时并不在m_ids列表内，说明事务B在生成本次ReadView之前就已提交。说明这次你查询就可以查到事务B修改过的这个值了， 此时事务A就会查到值B。
+
+## 6 RR级实现
+
+咋同时避免不可重复读问题、幻读？
+
+MySQL让多事务并发运行的时候能互相隔离，避免同时读写一条数据时有影响，是借助undo log版本链和ReadView机制。
+
+RR级别下，你这事务读一条数据，无论读多少次，都是一个值：
+
+- 别的事务修改数据了后即使提交了，你也看不到人家修改的值，这就解决了不可重复读
+- 其它事务插入一些新数据，你也读不到，这就避免幻读
+
+若有一条数据是事务id=50的一个事务插入的，此时有事务A、B同时在运行。事务A发起一个查询，第一次查询就生成一个ReadView：
+
+- creator_trx_id=60
+- min_trx_id=60
+- max_trx_id=71
+- m_ids=[60, 70]
+
+这时，事务A基于该ReadView去查这条数据，发现这条数据的trx_id为50，小于ReadView里的min_trx_id的，说明他发起查询之前，早就有事务插入这条数据还提交了，所以此时可以查到这条原始值的
+
+
+
+接着事务B此时更新了这条数据的值为b，修改trx_id=70，同时生成一个undo log，事务B此时提交
+
+
+
+ReadView中的m_ids此时还是60、70，因为ReadView一旦生成了就不会改变！
+
+这时虽然事务B已提交，但事务A的ReadView里， 还是有60、70，即在你事务A开启查询时，事务B当时是在运行的意思而已。
+
+然后事务A查询这条数据，发现此时数据的trx_id=70，在ReadView的min_trx_id和max_trx_id的范围，还在m_ids列表，这说明啥？
+
+事务A开启查询时，id=70的这个事务B还在运行，然后由这个事务B更新了这条数据，所以此时事务A不能查询到事务B更新的这个值，因此顺着指针往历史版本链条上去找，找到trx_id=50，是小于ReadView的min_trx_id的，说明在他开启查询之前，就已提交该事务，所以事务A可查询到该值，此时事务A查到的就是原始值。这就解决了不可重复读。
+
+事务A多次读同一个数据，每次读到的都是一样的值，除非是他自己修改的值，否则读到的一直一样。不管别的事务如何修改数据，事务A的ReadView始终不变，他基于这ReadView看到的值始终如一！
+
+### 解决幻读
+
+假设事务A先
+
+```sql
+select * from x where id>10
+```
+
+此时可能查到的就是一条数据，而且读到的是这条数据的原始值的那个版本：
+
+
+
+现在，有个事务C插入一条数据，然后提交：
+
+
+
+接着，事务A再查询，发现符合条件的有2条数据：
+
+- 原始值那个数据
+
+- 事务C插入的那条数据
+
+ 但C插入的那条数据的trx_id=80 ＞ ReadView的max_trx_id，说明是自己发起查询后，这个事务才启动，所以此时这条数据不能查询。
+
+因此事务A本次查询，还是只能查到原始值那一条数据。所以这里事务A不会发生幻读，他根据条件范围查询的时候，每次读到的数据都是一样的，不会读到人家插入进去的数据，这都是依托ReadView机制实现的。
+
+## 7 MySQL的两个“视图”
+
+- view：一个用查询语句定义的虚拟表，调用时，执行查询语句并生成结果。创建视图的语法 create view … ，其查询方法与表一样
+- InnoDB实现MVCC时用的一致性读视图（consistent read view）：用于支持**读提交**、**可重复读**。没有物理结构，事务执行期间用来定义“我能看到啥数据”。
+
+## 8 “快照”在MVCC咋工作的？
+
+RR下，事务启动时就“拍了个快照”。该快照是基于整库的。若某库有100G，则启动一个事务，MySQL就要拷贝100G数据出来，这得多慢。实际上，并不需要拷贝出这100G数据。
+
+### 8.1 快照的实现
+
+InnoDB每个事务有**唯一事务ID**：transaction id，在事务开始时向InnoDB事务系统申请的，按申请顺序严格递增。
+
+#### 每行数据也有多版本
+
+每次事务更新数据时，都生成一个新**数据版本**，并把`transaction id`赋给该**数据版本**的**事务ID**，记为row trx_id。同时，旧数据版本要保留，并在新数据版本中，能有办法可直接拿到它。
+
+即一行记录可能有多个版本(row)，每个版本有自己的row trx_id。
+
+如图，就是一个记录被多个事务连续更新后的状态。行状态变更图：
+
+
+
+虚线框里是同一行数据的4个版本，当前最新版本是V4，k=22，它是被transaction id=25的事务更新，因此它的row trx_id=25。
+
+- 语句更新会生成undo log（回滚日志），在哪呢？
+ 三个虚线箭头，就是undo log。V1、V2、V3并非物理上真实存在，而是每次需要时，根据当前版本和undo log计算而得。比如，需要V2时，就通过V4依次执行U3、U2计得。
+
+那InnoDB如何定义那个“100G”快照？
+按可重复读定义，一个事务启动时，能够看到所有已提交的事务结果。但之后，该事务执行期间，其他事务的更新对它不可见。
+
+因此，一个事务只需在启动时说，以我启动时刻为准：
+
+- 若一个数据版本是在我启动前生成，就认
+- 启动后才生成，我不认，我必须要找到它的上一个版本。若上个版本也不可见，就继续往前找。若是该事务自己更新的数据，它自己还是要认的。
+
+### 视图数组
+
+InnoDB为每个事务构造了一个数组，以保存该事务启动瞬间，当前正“活跃”（启动了，但尚未提交）的所有事务ID。
+
+在该数组里：
+
+- 事务ID的最小值，记为低水位
+- 当前系统里已创建过的事务ID的最大值加1，记为高水位
+
+这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。
+
+而数据版本的可见性规则，就是基于数据的row trx_id和这个一致性视图的对比结果而得。
+
+该视图数组把所有row trx_id 分成：
+数据版本可见性规则：
+
+
+
+对于当前事务的启动瞬间，一个数据版本的row trx_id，有如下可能：
+
+1. 若落在绿色，表示该版本是已提交的事务或当前事务自己生成的，这个数据是可见的
+2. 若落在土色，表示该版本是由将来启动的事务生成的，肯定不可见
+3. 若落在黄色，包括两种情况：
+ a. 若 row trx_id在数组中，表示该版本是由尚未提交的事务生成的，不可见
+ b. 若 row trx_id不在数组中，表示该版本是已提交的事务生成的，可见
+
+比如，对于【行状态变更图】的数据，若有一个事务，它的低水位是18，则当它访问这一行数据时，就会从V4通过U3计算出V3，所以在它看来，这一行值是11。
+
+有了该声明后，系统里随后发生的更新，就跟该事务看到的内容无关了。因为之后的更新，生成的版本一定属于上面的2或者3(a)，而对它来说，这些新的数据版本是不存在的，所以这个事务的快照，就是“静态”的了。
+
+所以InnoDB利用了“所有数据都有多版本”的特性，实现了“秒级创建快照”能力。
+
+接下来，我们开始分析一开始的三个事务
+
+## 事务案例分析
+
+假设：
+
+- 事务A开始前，系统里只有一个活跃事务ID=99
+- 事务A、B、C版本号分别是100、101、102，且当前系统里只有这四个事务
+- 三个事务开始前，(1,1）这一行数据的row trx_id是90
+
+于是：
+
+- 事务A的视图数组[99,100]
+- 事务B的视图数组是[99,100,101]
+- 事务C的视图数组是[99,100,101,102]
+
+为简化分析，先把其他干扰语句去掉，只画出跟事务A查询逻辑有关的操作：
+
+事务A查询数据逻辑图：
+
+
+
+
+
+- 第一个有效更新是事务C，(1,1)=》(1,2)。这时，该数据的最新版本的row trx_id=102，版本90已成为历史版本
+- 第二个有效更新是事务B，(1,2)=》(1,3)。这时，该数据的最新版本（即row trx_id）=101，版本102成为历史版本
+
+事务A查询时，事务B还没提交，但它生成的(1,3)这版本已变成当前版本。但这版本对事务A必须不可见，否则就变成脏读。
+
+现在事务A要来读数据了，它的视图数组是[99,100]。读数据都是从当前版本读起的。所以，事务A查询语句的读数据流程是这样的：
+
+- 找到(1,3)的时候，判断出row trx_id=101，比高水位大，处于红色区域，不可见
+- 接着，找到上一个历史版本，一看row trx_id=102，比高水位大，处于红色区域，不可见
+- 再往前找，终于找到了（1,1)，它的row trx_id=90，比低水位小，处于绿色区域，可见
+
+这样执行下来，虽然期间这一行数据被修改过，但是事务A不论在什么时候查询，看到这行数据的结果都是一致的，所以称之为一致性读。
+
+一个数据版本，对于一个事务视图来说，除了自己的更新总是可见之外，还有如下情况：
+
+1. 版本未提交，不可见
+2. 版本已提交，但是是在视图创建后提交的，不可见
+3. 版本已提交，而且是在视图创建前提交的，可见。
+
+现在，让我们用这些规则判断查询结果，事务A的查询语句的视图数组是在事务A启动时生成的，这时：
+
+- (1,3)还没提交，属于case1，不可见
+- (1,2)虽然提交了，但却在视图数组创建之后提交，属于case2，不可见
+- (1,1)是在视图数组创建之前提交的，可见
+
+现在只需通过时间先后分析即可。
+
+## 更新逻辑
+
+事务B的update语句，若按一致性读，好像结果不对呢？
+
+你看下图，事务B的视图数组是先生成的，之后事务C才提交，不是应该看不见(1,2)吗，怎么能算出(1,3)？
+
+事务B更新逻辑图：
+
+
+
+若事务B在更新前查询一次数据，该查询返回的k的值确实是1。
+但当它要去更新数据时，就不能再在历史版本上更新了，否则事务C的更新就丢失了。因此，事务B此时的set k=k+1是在（1,2）的基础上进行的操作。
+
+所以，这里用到规则：**更新数据，都是先读后写。这个读，只能读当前的值，即“当前读”（current read）。**
+
+因此，在更新时，当前读拿到的数据是(1,2)，更新后生成了新版本数据(1,3)，这个新版本的row trx_id是101。
+
+所以，在执行事务B查询语句时，一看自己的版本号是101，最新数据的版本号也是101，是自己的更新，可以直接使用，所以查询得到的k的值是3。
+
+#### 当前读（current read）
+
+除了update语句外，select语句若加锁，也是当前读。
+
+所以，若修改事务A的查询语句
+
+```sql
+select * from t where id=1
+```
+
+加上：
+
+- lock in share mode
+- 或for update
+
+都可读到version=101的数据，返回的k的值是3。
+
+```sql
+// 加了读锁（S锁，共享锁）
+mysql> select k from t where id=1 lock in share mode;
+// 写锁（X锁，排他锁）
+mysql> select k from t where id=1 for update;
+```
+
+假设事务C不是马上提交的，而是变成下面的事务C’，会咋样？
+事务A、B、C'的执行流程：
+
+| 事务A | 事务B | 事务C' |
+| ------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| start transaction with consistent snapshot; | | |
+| | start transaction with consistent snapshot; | |
+| | | start transaction with consistent snapshot;
update t set k=k+1 where id=1; |
+| | update t set k=k+1 where id=1;
select k from t where id=1; | |
+| select k from t where id=1;
commit; | | commit; |
+| | commit; | |
+
+事务C’不同在于更新后并没有马上提交，在它提交前，事务B的更新语句先发起了。前面说过了，虽然事务C’还没提交，但(1,2)这个版本也已经生成了，并且是当前的最新版本。
+
+### 事务B的更新语句会咋处理？
+
+“两阶段锁协议”。事务C’没提交，即(1,2)这个版本上的写锁还没释放。而事务B是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务C’释放这个锁，才能继续它的当前读。
+
+事务B更新逻辑图（配合事务C'）：
+
+
+
+至此，一致性读、当前读和行锁就串起来了。
+
+## 事务咋实现可重复读？
+
+- 可重复读的核心是一致性读（consistent read）
+- 而事务更新数据时，只能用当前读
+
+若当前记录的行锁被其他事务占用，需进入锁等待。
+
+RC和RR最主要区别：
+
+- RR，事务开始时创建一致性视图，之后事务里的其他查询都共用该一致性视图
+- RC，每个语句执行前都会重新算出一个新视图
+
+RC下的事务A、B的查询语句查到的k，分别是啥呢？
+
+```sql
+# 从这语句开始，创建一个持续整个事务的一致性快照
+start transaction with consistent snapshot;
+```
+
+所以，RC下的这个用法就没意义，等于普通的start transaction。
+
+#### RC时的状态图
+
+这两个查询语句的创建视图数组的时机发生了变化，即图中的read view框。（这用的还是事务C的逻辑直接提交，而非事务C’）
+
+RC下的事务状态图：
+
+
+
+事务A的查询语句的视图数组，是在执行这语句时创建的。时序上(1,2)、(1,3)的生成时间都在创建这个视图数组的时刻之前。但在这个时刻：
+
+- (1,3)还没提交，属于情况1，不可见
+- (1,2)提交了，属于情况3，可见
+
+所以，此时：
+
+- 事务A查询语句返回的是k=2
+- 事务B查询结果k=3
+
+## 总结
+
+InnoDB的行数据有多个版本，每个数据版本有自己的row trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读，一致性读会根据`row trx_id`和`一致性视图`确定数据版本的可见性。
+
+- RR：查询只承认在事务启动前，就已提交完成的数据
+- RC：查询只承认在语句启动前，就已提交完成的数据
+- 当前读：总读取已提交完成的最新版本
+
+Q：为啥表结构不支持“可重复读”？
+
+A：表结构没有对应的行数据，也没row trx_id，因此只能遵循当前读的逻辑。MySQL 8.0已可将表结构放在InnoDB字典里了，也许以后会支持表结构的可重复读。
\ No newline at end of file
diff --git a/docs/md/mysql/optimize-slow-queries-massive-row-deletions.md b/docs/md/mysql/optimize-slow-queries-massive-row-deletions.md
new file mode 100644
index 0000000000..8a44e50ac2
--- /dev/null
+++ b/docs/md/mysql/optimize-slow-queries-massive-row-deletions.md
@@ -0,0 +1,105 @@
+# 千万级数据删除导致的慢查询优化
+
+## 0 前言
+
+有人删了千万级的数据，结果导致频繁的慢查询。
+
+线上收到大量慢查询告警，于是检查慢查询的SQL，发现不是啥复杂SQL，这些SQL主要针对一个表，基本都是单行查询，看起来应该不会有慢查询。这种SQL基本上都是直接根据索引查找出来的，性能应该极高。
+
+是否可能慢查询不是SQL问题，而是MySQL生产服务器的问题？特殊情况下，MySQL出现慢查询还真不是SQL问题，而是他自己生产服务器的负载太高，导致SQL语句执行慢。比如现在MySQL服务器的
+
+## 1 磁盘I/O
+
+磁盘I/O负载高，每秒执行大量高负载的随机I/O，但磁盘本身每秒能执行的随机I/O有限，导致正常SQL在磁盘执行时，若跑一些随机IO，你的磁盘太忙，顾不上你了，导致你本来很快的一个SQL，要等很久才能执行完毕，这时就可能导致正常SQL也变成慢查询。
+
+## 2 网络
+
+也许网络负载高，导致你一个SQL语句要发到MySQL，光是等待获取一个和MySQL的连接，都很难，要等很久或MySQL自己网络负载太高，带宽打满，带宽打满后，你一个SQL也许执行很快，但其查出来的数据返回给你，网络都送不出去，也会变成慢查询。
+
+## 3 CPU
+
+若CPU负载过高，也会导致CPU过于繁忙去执行别的任务，没时间执行你的SQL。
+
+所以慢查询不一定是SQL本身导致，若觉得SQL不应该会慢查询，结果他那个时间段跑这个SQL 就是慢，应排查当时MySQL服务器的负载，尤其看看磁盘、网络及 CPU 的负载，是否正常。
+
+## 4 案例
+
+当某个离线作业瞬间大批量把数据往MySQL里灌入的时，他一瞬间服务器磁盘、网络以及CPU的负载会超高。
+
+此时你一个正常SQL执行下去，短时间内一定会慢查询，类似问题，优化手段更多是控制你导致MySQL负载过高的那些行为，比如灌入大量数据，最好在业务低峰期灌入，别影响高峰期的线上系统运行。
+
+但看了下MySQL服务器的磁盘、网络以及CPU负载，一切正常，似乎也不是这问题导致。看起来无解了？
+
+## 5 总结
+
+慢 SQL 的头两步排查手段：
+
+- 检查SQL是否有问题，看执行计划
+- 检查MySQL服务器的负载
+
+这两种办法都不奏效之后，第三步：用MySQL profilling工具去细致的分析SQL语句的执行过程和耗时。
+
+这个工具可以对SQL语句的执行耗时进行非常深入和细致的分析
+
+## 6 使用
+
+打开profiling，使用
+
+```sql
+set profiling=1
+```
+
+接着MySQL就会自动记录查询语句的profiling信息。此时若执行show profiles，就会给你列出各种查询语句的profiling信息，会记录下来每个查询语句的query id，所以你要针对你需要分析的query找到对他的query id，我们当时就是针对慢查询的那个SQL语句找到了query id。
+
+然后针对单个查询语句，看其profiling信息，使用show profile cpu, block io for query xx，这里的xx是数字，此时就可以看到具体的profile信息。
+
+除了cpu以及block io以外，还能指定去看这个SQL语句执行时候的其他各项负载和耗时。
+
+会给你展示出来SQL语句执行时候的各种耗时，比如磁盘IO的耗时，CPU等待耗时，发送数据耗时，拷贝数据到临时表的耗时等，SQL执行过程中的各种耗时都会展示。
+
+检查该SQL语句的profiling信息后，发现问题，其Sending Data耗时最高，几乎使用1s，占据SQL执行耗时的99%！其他环节耗时低可以理解，毕竟这种简单SQL执行速度真的很快，基本就是10ms级别，结果跑成1s，那肯定Sending Data就是问题根源！
+
+这Sending Data在干啥呢？
+
+MySQL官方释义：为一个SELECT语句读取和处理数据行，同时发送数据给客户端的过程，简单来说就是为你的SELECT语句把数据读出来，同时发送给客户端。
+
+但这过程为啥这么慢？profiling确实是提供给我们更多的线索了，但似乎还是没法解决问题。但已经捕获到异常关键点，就是Sending Data的耗时很高！
+
+接着：
+
+```sql
+show engine innodb status
+```
+
+看innodb存储引擎的一些状态，此时发现一个奇怪的指标：history list length，值特别高，达到上万。
+
+MVCC就是多个事务在对同一个数据， 有人写，有人读，此时可以有多种隔离级别，对一个数据有个多版本快照链条，才能实现MVCC和各种隔离级别。
+
+所以当你有大量事务执行时，就会构建这种undo多版本快照链条，此时history list length就会很高。然后在事务提交后，会有一个多版本快照链条的自动purge清理机制，清理了，该值就会降低。一般该值不应过高，所以注意到第二个线索：history list length过高，即大量的undo多版本链条数据没有清理。推测可能有的事务长时间运行，所以其多版本快照不能被purge清理，进而导致history list length过高。
+
+经过这俩线索推测，在大量简单SQL变成慢查询时，SQL因为Sending Data环节异常，耗时过高；同时此时出现一些长事务长时间运行，大量的频繁更新数据，导致有大量undo多版本快照链条，还无法purge清理。
+
+## 7 这俩线索之间的关系是啥？
+
+因为发现有大量的更新语句在活跃，而且有那种长期活跃的长事务一直在跑而没有结束，问了下系统负责人，在后台跑了个定时任务：他居然开了一个事务，然后在一个事务里删除上千万数据，导致该事务一直在运行。
+
+这种长事务的运行会导致你删除时，仅只是对数据加了一个删除标记，事实上并没有彻底删除。此时你若和长事务同时运行的其它事务里再查询，他在查询时可能会把那上千万被标记为删除的数据都扫描一遍。因为每次扫描到一批数据，都发现标记为删除了，接着就会再继续往下扫描，所以才导致一些查询语句很慢。
+
+那为何你启动一个事务，在事务里查询，凭什么就要去扫描之前那个长事务标记为删除状态的上千万的垃圾数据？讲道理，那些数据都被删了，跟你没关系了呀，你可以不去扫描他们 嘛！
+
+### 问题症结
+
+那删除千万级数据的事务是长事务！当你启动新事务查询时，那删除千万级数据的长事务一直在运行，它是活跃的！结合MVCC Read View机制，当你启动一个新事务查询时，会生成一个Read View。新事务查询时，会根据ReadView判断：
+
+- 哪些数据可见
+- 可见的数据版本号
+
+因为每个数据都有版本链，有时你可见的仅是该数据的一个历史版。
+
+所以，正是该长事务一直在运行，还在删除大量数据，而这些数据仅是逻辑删除，此时你新开事务的查询还是会读到所有逻辑删除数据，也就会出现千万级数据扫描，导致慢查询！
+
+所以禁止业务高峰期运行删除大量数据的语句，因其可能导致正常SQL都变慢查询，因为那些SQL也许会不断扫描你标记为删除的大量数据，好不容易扫描到一批数据，结果发现是标记为删除的，于是继续扫描下去，导致慢查询！
+
+## 8 解决方案
+
+直接kill那个正在删除千万级数据的长事务，所有SQL很快恢复正常。此后，大量数据清理全部放在凌晨执行，那个时候就没什么人使用系统了，所以查询也很少。
\ No newline at end of file
diff --git "a/docs/md/tomcat/Tomcat\350\277\233\347\250\213\345\215\240\347\224\250CPU\350\277\207\351\253\230\346\200\216\344\271\210\345\212\236\357\274\237.md" b/docs/md/tomcat/how-to-solve-high-cpu-usage-in-tomcat-process.md
similarity index 86%
rename from "docs/md/tomcat/Tomcat\350\277\233\347\250\213\345\215\240\347\224\250CPU\350\277\207\351\253\230\346\200\216\344\271\210\345\212\236\357\274\237.md"
rename to docs/md/tomcat/how-to-solve-high-cpu-usage-in-tomcat-process.md
index ab04d4d1ae..d4c6de7538 100644
--- "a/docs/md/tomcat/Tomcat\350\277\233\347\250\213\345\215\240\347\224\250CPU\350\277\207\351\253\230\346\200\216\344\271\210\345\212\236\357\274\237.md"
+++ b/docs/md/tomcat/how-to-solve-high-cpu-usage-in-tomcat-process.md
@@ -28,11 +28,15 @@ java -Xss256k -jar demo-0.0.1-SNAPSHOT.jar
线程栈大小指定256KB。对于测试程序，os默认值8192KB过大，因为需要创建4096个线程。
-top看到Java进程CPU使用率达961.6%，注意进程ID 55790：
+#### top
+
+见Java进程CPU使用率爆表：
-精细化top查看这Java进程中各线程使用CPU情况：
+#### top细查
+
+这进程的各线程使用CPU情况：
```java
$ top -H -p 55790
@@ -40,13 +44,17 @@ $ top -H -p 55790
-有个“scheduling-1”线程占用较多CPU。下一步就找出这个线程在做啥。jstack生成线程快照。jstack输出较大，一般将其写入文件：
+“scheduling-1”线程占较多CPU。找这线程在做啥。
+
+#### jstack生成线程快照
+
+jstack输出较大，一般将其写入文件：
```java
jstack 55790 > 55790.log
```
-打开55790.log，定位到第4步中找到的名为 **scheduling-1** 的线程，其线程栈：
+打开log并定位到第4步中找到的名为 **scheduling-1** 的线程，其线程栈：
@@ -89,5 +97,6 @@ grep -o 'pool-2-thread' 55790.log | wc -l
## 总结
-遇到CPU过高，首先定位哪个进程导致，之后可通过top -H -p pid命令定位到具体的线程。
-其次还要通jstack查看线程的状态，看看线程的个数或者线程的状态，如果线程数过多，可以怀疑是线程上下文切换的开销，我们可以通过vmstat和pidstat这两个工具进行确认。
\ No newline at end of file
+CPU过高，先定位啥进程导致，之后top -H -p pid定位具体线程。
+
+还要jstack查看线程状态，看线程个数或线程状态，若线程数过多，可怀疑是线程上下文切换开销，可通过vmstat和pidstat确认。
\ No newline at end of file