leecodecode【二叉树排序+最近公共祖先】【2026.6.2打卡-java版本】

验证二叉搜索树

要点：宏观的看，root，left，right，不看细节

方法一：前序排列

root带上【left，right】，然后左边【left，root.val】，右边【root.val, right】

/**
 * Definition for a binary tree node.
 * public class TreeNode {
 *     int val;
 *     TreeNode left;
 *     TreeNode right;
 *     TreeNode() {}
 *     TreeNode(int val) { this.val = val; }
 *     TreeNode(int val, TreeNode left, TreeNode right) {
 *         this.val = val;
 *         this.left = left;
 *         this.right = right;
 *     }
 * }
 */
class Solution {
    public boolean isValidBST(TreeNode root) {
        return isValidBST(root, Long.MIN_VALUE, Long.MAX_VALUE);
    }

    private boolean isValidBST(TreeNode node, Long left, Long right){
        if(node == null){
            return true;
        }
        long x = node.val;

        return left < x && x < right 
        && isValidBST(node.left, left, x)
        && isValidBST(node.right, x, right);
    }
}

方法二：中序遍历

要有一个pre，对于这个root点，left，然后中间，pre 更新为中间节点，然后right。

/**
 * Definition for a binary tree node.
 * public class TreeNode {
 *     int val;
 *     TreeNode left;
 *     TreeNode right;
 *     TreeNode() {}
 *     TreeNode(int val) { this.val = val; }
 *     TreeNode(int val, TreeNode left, TreeNode right) {
 *         this.val = val;
 *         this.left = left;
 *         this.right = right;
 *     }
 * }
 */
class Solution {
    //中序遍历
    private long pre = Long.MIN_VALUE;
    public boolean isValidBST(TreeNode root) {
        if(root ==null){
            return true;
        }
        if(! isValidBST(root.left)){
            return false;
        }

        if(root.val <= pre){
            return false;
        }

        pre = root.val;
        
        return isValidBST(root.right);
    }
}

方法3：后序遍历

要点：返回root的两边的最小值和最大值

root==null，返回【最大，最小】,相当于没用

不行的话

x<= left的最大值，x>=最小值,return最小，最大

/**
 * Definition for a binary tree node.
 * public class TreeNode {
 *     int val;
 *     TreeNode left;
 *     TreeNode right;
 *     TreeNode() {}
 *     TreeNode(int val) { this.val = val; }
 *     TreeNode(int val, TreeNode left, TreeNode right) {
 *         this.val = val;
 *         this.left = left;
 *         this.right = right;
 *     }
 * }
 */
class Solution {
    //后续，要保留这个节点得到最大和最小，因为他可能是别的节点的左【需要这边最大】，右节点【需要这边最小】
    public boolean isValidBST(TreeNode root) {
        return dfs(root)[1] != Long.MAX_VALUE;
        
    }

    private long[] dfs(TreeNode node){
        if(node == null){
            return new long[]{Long.MAX_VALUE, Long.MIN_VALUE};
        }

        long[] left = dfs(node.left);
        long[] right = dfs(node.right);

        long x = node.val;

        if(x <= left[1] || x >= right[0]){
            return new long[]{Long.MIN_VALUE, Long.MAX_VALUE};
        }

        return new long[]{Math.min(left[0],x), Math.max(right[1],x)};
    }
}

二叉树的最近公共祖先

要点：root判断，然后左右两边判断

/**
 * Definition for a binary tree node.
 * public class TreeNode {
 *     int val;
 *     TreeNode left;
 *     TreeNode right;
 *     TreeNode(int x) { val = x; }
 * }
 */
class Solution {
    public TreeNode lowestCommonAncestor(TreeNode root, TreeNode p, TreeNode q) {
        if(root == null || root == p || root == q){
            return root;
        }

        TreeNode left = lowestCommonAncestor(root.left, p, q);
        TreeNode right = lowestCommonAncestor(root.right, p, q);

        if(left != null && right != null){
            return root;
        }

        if(left != null){
            return left;
        }

        return right;
        
    }
}

二叉搜索树的最近公共祖先

要点：都小于root，则递归左边，都大于，则递归右边， 中间就root

/**
 * Definition for a binary tree node.
 * public class TreeNode {
 *     int val;
 *     TreeNode left;
 *     TreeNode right;
 *     TreeNode(int x) { val = x; }
 * }
 */

class Solution {
    public TreeNode lowestCommonAncestor(TreeNode root, TreeNode p, TreeNode q) {
        int x = root.val;
        if(p.val < x && q.val < x){
            return lowestCommonAncestor(root.left, p, q);
        }else if(p.val > x && q.val > x){
            return lowestCommonAncestor(root.right, p, q);
        }else{
            return root;
        }
        
    }
}

随机知识

前言 & 第 1 章：初识智能体

核心内容回顾

• 智能体的定义：能感知环境、自主采取行动实现目标的实体。核心是 自主性。

• 传统智能体演进：反射式 → 基于模型 → 基于目标 → 基于效用。

• 现代 LLM Agent 的三要素：规划、记忆、工具，LLM 作为大脑。

作为 Agent 工程师的思考

• 不要把 Agent 想得太神秘 。本质上，Agent 就是一个 while 循环：感知（读取状态）→ 思考（调用 LLM）→ 行动（调用工具/输出）。当你自己实现一个最简单的 ReAct 循环后，会觉得"原来就这么简单"。

• 三要素是设计的骨架。以后你设计任何 Agent，都可以问自己：

  • 规划模块：Agent 怎么决定下一步？是显式的计划列表，还是隐式的推理链？

  • 记忆模块：短期对话记忆放哪？长期知识怎么检索？

  • 工具模块：有哪些外部能力？如何安全、高效地调用？

• 自主性的边界 ：真实业务中很少要完全自主的 Agent（风险太高）。更常见的是 人在回路（Human-in-the-loop），关键动作前请求确认。这是工程师必须考虑的产品落地问题。

---

第 2 章：智能体发展史

核心内容回顾

• 符号主义（专家系统）→ 强化学习（试错）→ 深度学习（DRL）→ LLM 驱动的现代 Agent。

• 每个阶段的局限推动了下一阶段：知识获取难 → 奖励设计难 → 可解释性差 → 幻觉与推理成本。

作为 Agent 工程师的思考

• 历史即设计模式。符号主义的"规则引擎"并没有消失 ------ 今天你写 prompt 里的 "如果用户问价格，先查库存再回复" 本质上还是规则。学会把确定性逻辑用规则写死，把不确定性交给 LLM，是工程师的品位。

• 强化学习的思维很有用。即使你不用 RL 训练 LLM，也可以把 Agent 与环境交互看作一个 RL 问题：状态=对话历史+环境反馈，动作=工具调用或回复，奖励=任务是否完成。这种视角帮你设计更好的失败重试、探索策略。

• LLM 不是万能药。从历史看，每个技术都有替代边界。LLM 擅长语言理解、生成和简单推理，但不擅长精确计算、实时性要求高的任务。你要做的不是把所有东西塞给 LLM，而是把 LLM 当胶水，协调传统代码和外部 API。

---

第 3 章：大语言模型基础

核心内容回顾

• Transformer 架构：自注意力、位置编码、多头注意力、前馈网络。

• 训练三阶段：预训练（PT）→ 监督微调（SFT）→ 基于人类反馈的强化学习（RLHF）。

• 提示工程：zero-shot、few-shot、CoT。

• 局限：幻觉、上下文长度、推理与事实矛盾、偏见、安全性。

作为 Agent 工程师的思考

• 理解模型能力的边界是 prompt 设计的前提。比如你知道预训练模型不会遵循复杂指令，SFT 后才会，RLHF 后更符合人类偏好。所以生产环境应该用 chat 模型（已 SFT+RLHF），而非 base 模型。

• CoT 不只是加一句"Let's think step by step"。真正的 CoT 需要你设计好推理痕迹的格式，让模型把中间步骤写出来，然后你可以解析它、校验它、甚至中断错误分支。这是实现 Agent 可控性的关键技术。

• 幻觉问题的工程应对：

  • 强制要求模型引用来源（"根据资料 X 说......"）。

  • 用工具检索替代模型记忆事实。

  • 对关键输出做二次验证（比如让另一个 LLM 检查一致性）。

• 上下文长度不是越大越好。长上下文会引入噪音、增加延迟和成本。要学会裁剪（只保留最近 K 轮或最相关的片段），而不是无脑塞入全部历史。

---

第 4 章：智能体经典范式构建

核心内容回顾

• 手写 ReAct：Thought → Action → Observation 循环。

• Plan-and-Solve：先规划完整步骤列表，再依次执行。

• Reflection：执行后让 Agent 自我批评，生成改进版本。

作为 Agent 工程师的思考

• 这是整个课程最实操的一章，建议你跟着代码敲一遍。手写 ReAct 会让你真正理解 Agent 的"循环本质"。很多复杂的框架只是在这个循环上加缓存、工具注册、并行执行等特性。

• 三种范式的选择：

  • ReAct：适合问题逐步明确、需要中途调整的任务（如客服、调试）。

  • Plan-and-Solve：适合目标明确、步骤可预测的任务（如批量数据处理、编排工作流）。

  • Reflection：适合质量要求高的生成任务（如写代码、写文案），但耗时翻倍。

• 混合使用：在实际系统中，你常常会让 Agent 先 Plan，然后在执行每个 Step 时采用 ReAct 式的动态调整。这是更鲁棒的设计。

---

第 5 章：基于低代码平台的智能体搭建

核心内容回顾

• 低代码平台（Coze、Dify、n8n）的价值：降低门槛、快速验证、可视化调试。

• 实战：搭建一个智能客服 Agent，配置知识库、工作流、发布 API。

作为 Agent 工程师的思考

• 低代码不是给"非工程师"用的，而是给工程师快速原型的利器。当你要测试一个新 idea，用 Dify 拖拽 10 分钟出一个原型，比写代码 2 小时更高效。等验证可行再写代码。

• 要理解平台背后的抽象：它们无非是把 Agent 三要素可视化：

  • 知识库 = 长期记忆（RAG）

  • 工作流 = 规划

  • 插件/工具 = 工具集

• 劣势也要清楚：平台往往难以处理复杂逻辑、自定义评估、精细控制。当你需要修改 prompt 中的某个细节或者实现一个奇怪的循环时，低代码会卡住你。届时你需要切换到代码框架。

---

第 6 章：框架开发实践

核心内容回顾

• 主流框架对比：AutoGen（多 Agent 对话）、LangGraph（图状态机）、AgentScope（分布式）。

• 实战：用某个框架搭建多智能体协作写报告。

作为 Agent 工程师的思考

• 框架选型比你想的更重要。你未来在工作中可能需要选择一个框架作为团队的基础。

  • AutoGen：适合多个 Agent 自由对话的场景，但对话图复杂时难以控制。

  • LangGraph：适合你明确知道状态转换逻辑的场景，可控性强。

  • 你自己的框架（下一章）：适合需要完全掌控、避免依赖地狱的场景。

• 学习框架的正确姿势 ：不要只看文档，要读它的 核心循环代码 。比如 LangGraph 的 graph.invoke 内部就是一个 while 循环 + 状态更新。读懂了，你甚至能自己实现一个简化版。

• 框架只是脚手架。很多新手陷入"框架怎么配置工具、怎么记忆"的细节，而忘了业务目标。记住：框架是为了让你更快地交付 Agent 应用，不是为了让你成为框架专家。

---

第 7 章：构建你的 Agent 框架（HelloAgents）

核心内容回顾

• 动机：现有框架过度抽象、不稳定、黑盒。

• 设计分层：llm 层、agent 层、tools 层、memory 层。

• 实现核心基类：BaseAgent、HelloAgentsLLM、工具注册机制。

作为 Agent 工程师的思考

• 这是从"使用者"到"构建者"的转折点 。即使你以后不会真的维护自己的框架，这个练习会让你对框架的内部运作有直觉。比如你知道工具注册本质上就是一个 dict：{tool_name: tool_function}。

• 抽象层级的选择：HelloAgents 的抽象比较轻量，只做了必要的事情。这是值得学习的品味 ------ 不要过度设计。一个 Agent 框架核心只要搞定三件事：

  1. 调用 LLM 并解析输出

  2. 维护对话记忆（消息列表）

  3. 根据输出调用工具并返回结果

• 未来扩展的思考：你自己写框架时，可以考虑插件化、异步支持、流式输出、事件钩子（比如每次 Thought 后触发一个回调用于日志）。这些在生产环境很关键。

---

第 8 章：记忆与检索

核心内容回顾

• 借鉴人类记忆：感觉记忆、工作记忆（短期）、长期记忆。

• 实现短期记忆：对话历史缓存。

• 实现长期记忆：向量数据库存储 + RAG 检索。

作为 Agent 工程师的思考

• 短期记忆是 Agent 的"当前关注点"。通常你只需要把最近 N 轮对话塞入上下文。但要注意：如果对话很长，超过上下文限制怎么办？常见策略是：

  • 滑动窗口（只保留最近 K 条）

  • 摘要压缩（让 LLM 定期总结历史，把摘要作为记忆继续）

• 长期记忆的核心是 RAG，但 RAG 并不简单。工程师需要考虑：

  • 文档怎么分块？块大小多少？（影响检索粒度）

  • 用什么 embedding 模型？（中文用 BGE、m3e 等）

  • 检索怎么混合？关键词 + 向量？（BM25 + 向量）

  • 检索结果怎么重排？（reranker 可以提升精度）

• 记忆系统的设计模式：

  • 消息存储：所有交互持久化到数据库，需要时按时间或语义检索。

  • 实体记忆：提取用户提到的人、事、物，存入图谱或结构化表。

  • 总结记忆：周期性让 Agent 写"日记"，总结关键事件。

• 一个常见的坑：把大量无关信息塞入记忆，导致 LLM 分心。你需要 检索的决断力 ------ 不是所有信息都要喂给 LLM。

---

第 9 章：上下文工程

核心内容回顾

• 从提示工程到上下文工程：系统化地收集、筛选、组织、压缩上下文。

• GSSC 流水线：Gather（收集）→ Select（选择）→ Structure（结构化）→ Compress（压缩）。

• 实现 ContextBuilder，以及 NoteTool 和 TerminalTool 辅助记忆。

作为 Agent 工程师的思考

• 上下文工程是 Agent 落地的关键差异点。很多失败的 Agent 不是因为模型不行，而是喂给模型的上下文太乱：既有历史废话，又有无关检索结果，还忘了系统指令。

• Gather：所有可能相关的东西先捞出来。可以包括系统 prompt、用户当前输入、最近对话、RAG 结果、工具输出、自定义知识。

• Select：这是最难的部分。你需要规则 + 模型一起判断。规则（比如取最近 5 条对话）很快；模型判断更准确但慢。实用中往往先用规则粗筛，再让模型重排。

• Structure ：用清晰的格式组织，比如 [用户] xxx、[系统] xxx、[工具结果] xxx。甚至可以用 XML 标签或 Markdown 表格。良好结构能显著提升 LLM 的理解。

• Compress：当上下文太长时，可以：

  • 对历史对话进行摘要（但会丢失细节）。

  • 只保留与当前问题最相关的部分（通过语义相似度筛选）。

  • 使用更长的模型（如 100 万 token 的 Gemini），但仍然要考虑成本和延迟。

• 实战技巧：把所有上下文构造逻辑封装成一个函数，输入是当前状态，输出是最终 prompt。这样你可以在不同 Agent 中复用，并且易于 A/B 测试不同的上下文策略。

---

第 10 章：智能体通信协议

核心内容回顾

• MCP（Model Context Protocol）：标准化工具调用协议，Agent 通过 MCP 客户端发现和调用工具。

• A2A（Agent-to-Agent）：Agent 之间点对点协作。

• ANP（Agent Network Protocol）：大规模 Agent 网络的发现与组网。

作为 Agent 工程师的思考

• MCP 可能是未来工具集成的标准。现在每个 Agent 框架都自己定义工具格式（OpenAI function call、LangChain tool、AutoGen tool...），导致工具不可移植。MCP 像"USB-C 接口"，一套工具可以被任何支持 MCP 的 Agent 使用。

• 作为工程师，你现在就可以实践 MCP：写一个简单的 MCP server 暴露本地文件系统或数据库查询，然后让 HelloAgents 通过 MCP 客户端调用它。这样你的工具就和具体 Agent 框架解耦了。

• A2A 和 ANP 目前还比较超前，但值得关注。如果你在构建多 Agent 系统（比如一个写代码、一个测试、一个部署），A2A 可以让它们像微服务一样通信。不过大多数场景用单一 Agent + 工具循环就足够了，多 Agent 会增加延迟和不确定性。

• 协议设计的哲学：好的协议是"约定优先于配置"且"可发现"。MCP 让 Agent 可以问："你有什么工具？"然后调用。这比硬编码工具列表更优雅。

---

第 11 章：Agentic-RL

核心内容回顾

• 从 LLM 训练到 Agentic RL：用强化学习优化多步任务的长期表现。

• 训练流程：PT → SFT → RLHF（其中 RLHF 又分为训练奖励模型 + PPO/GRPO）。

• 重点介绍 GRPO（Group Relative Policy Optimization），并实战训练一个工具调用模型。

作为 Agent 工程师的思考

• 这是高阶内容，大多数 Agent 工程师日常不会做。因为训练一个 LLM 需要大量的 GPU 资源和数据。但理解原理很重要，因为：

  • 当你调 prompt 调不好时，你知道可能要通过 RL 训练才能让模型学会复杂的工具使用模式。

  • 越来越多的小模型（7B, 13B）可以自己微调，成本在下降。

• Agentic RL 的核心 insight：监督学习只能模仿"好"的行为，但强化学习让模型自己去探索，找到更好的策略。比如让模型尝试不同的工具调用顺序，最后找到成功率最高的那个。

• GRPO 比 PPO 简单，因为它不用单独训练一个 critic 模型，而是用群体内的相对奖励。这是 DeepSeek 推广的高效方法。如果你要自己训练，可以从 GRPO 开始。

• 实用建议：先用提示工程和 few-shot 解决；如果不行，尝试 SFT（收集正确轨迹）；如果还不够，再考虑 RL。不要一上来就 RL。

---

第 12 章：智能体性能评估

核心内容回顾

• 评估的必要性：Agent 输出不确定，传统单元测试失效。

• 核心指标：任务成功率、工具调用准确率、执行效率、鲁棒性、成本。

• 评估方法：基于规则（精确匹配、正则）和基于模型（LLM-as-a-Judge）。

• 实现 HelloAgents 评估系统：自定义任务、运行测试套件、生成报告。

作为 Agent 工程师的思考

• 没有评估就没有优化。如果你不能量化 Agent 的好坏，你就无法知道改动是变好还是变坏。这是工程和学术的差别。

• 评估集设计：准备至少 50-100 个典型任务，覆盖正常场景、边界情况、异常输入。每次改动后跑一遍，对比成功率。

• LLM-as-a-Judge 的注意事项：

  • 用强模型（如 GPT-4）评估弱模型的结果，但注意成本。

  • 要写详细的评分标准，避免评估模型本身的偏见（比如偏爱更长、更自信的回答）。

  • 可以结合规则评估：比如工具调用是否完全匹配预期函数名，可以先做规则匹配；内容相关性再用模型。

• 评估自动化：把评估脚本集成到 CI 流水线里，每次代码提交都自动跑轻量级评估集。这会让你的 Agent 应用质量持续提升。

• 生产环境监控：评估不止在开发时。上线后要记录每个任务的输入、输出、工具调用、用户反馈，定期抽样评估。你会发现很多模式（比如某类问题总是失败）可以指导你改进 prompt 或工具。

---

第 13 章：智能旅行助手

核心内容回顾

• 完整项目：前端 Vue3 + 后端 FastAPI + HelloAgents，集成高德地图 MCP 工具。

• 多智能体协作：景点搜索、天气查询、酒店推荐、行程规划四个 Agent 协同。

• 功能：行程规划、预算计算、地图可视化、行程编辑。

作为 Agent 工程师的思考

• 这是多 Agent 协作的典型模式：一个主 Agent（规划者）负责拆解任务，调度其他专业 Agent。不要搞成所有 Agent 自由对话，那样会乱。

• MCP 工具实际应用：高德地图 API 通过 MCP 协议暴露给 Agent，这意味着你可以轻松替换地图服务（如百度地图），只要它实现相同的 MCP 接口。

• 前端集成要点：Agent 后端通常需要流式输出（SSE/WebSocket），让前端实时显示思考过程和工具调用结果，提升用户体验。

• 工程思考：这个项目展示了你如何把 Agent 嵌入到真正的 Web 应用中，而不仅仅是命令行 demo。生产环境中，你需要处理并发请求、API 限流、超时重试、结果缓存等。这些都是工程师要额外考虑的。

---

第 14 章：自动化深度研究智能体

核心内容回顾

• 项目：自动研究复杂主题并生成报告。

• 核心能力：问题剖析、多轮搜索、反思总结、流式反馈。

• 工具：SearchTool（联网搜索）、NoteTool（持久化笔记）。

作为 Agent 工程师的思考

• 多轮检索是 RAG 的高级形式。普通 RAG 是一次检索，而研究 Agent 会根据已有结果决定下一步搜什么。这需要 Agent 有元认知能力："我目前知道什么，还缺什么？"

• 反思循环：生成初步报告后，让 Agent 自我检查："有没有矛盾？有没有遗漏？引用是否可信？" 然后再次搜索补充。这种 iterative 过程大大提升报告质量。

• 实际落地挑战：

  • 搜索 API 成本（如 Google Search API 每次 0.005 美元，100 轮就是 0.5 美元）。

  • 需要控制搜索次数，避免死循环。

  • 搜索结果可能有大量噪音，需要摘要和去重。

• 可复用模式：这个项目的研究 Agent 可以改编为市场调研、竞品分析、文献综述等各种场景。你只要换掉搜索工具的数据源（如换成 PubMed 或内部知识库）。

---

第 15 章：构建赛博小镇

核心内容回顾

• 项目：用 Godot 游戏引擎 + FastAPI + HelloAgents，让 NPC 拥有记忆和个性。

• NPC 对话系统：基于短期记忆（最近对话）和长期记忆（重要事件），好感度动态变化。

• 实现真正的"生命感"。

作为 Agent 工程师的思考

• 这是 Agent 在游戏领域的前沿应用。传统 NPC 用对话树，而 LLM NPC 可以自由对话，极大提升沉浸感。黑神话、模拟人生等游戏未来都会采用。

• 记忆对个性的影响：NPC 回忆起过去事件（"你上次救了我的狗"）会改变当前对话行为。你需要设计事件提取和记忆召回的机制。

• 好感度系统：可以用一个简单的数值，基于对话情感分析和历史行为更新。然后 prompt 里加入"好感度：X/100，你对玩家的态度是友善/中立/敌对"。

• 工程要点：

  • 游戏引擎和 Agent 后端分离，通过 HTTP 通信，这样 Agent 逻辑可以独立更新。

  • 考虑延迟：每次对话调用 LLM 可能 1-2 秒，需要异步或显示"思考中"动画。

  • 多 NPC 并发：每个 NPC 有自己的记忆和状态，后端需要支持多个 Agent 实例。

---

第 16 章：毕业设计

核心内容回顾

• 目标：综合运用所有知识，独立完成一个 Agent 项目，提交到开源社区。

• 选题原则：实用性、可行性、技术完整性。

• 推荐方向：生产力工具、学习辅助、创意娱乐、数据分析、个人助理。

作为 Agent 工程师的思考

• 这是检验你能力的最终关卡。建议你选一个自己真正想用的场景（而不是为了毕业而毕业）。比如：

  • 一个帮你管理邮件并自动起草回复的 Agent。

  • 一个帮你从 GitHub issue 中自动分类并建议代码修改的 Agent。

  • 一个和你一起 brainstorm 产品创意的 Agent。

• 技术完整性：不只是写 ReAct 循环。要包括：

  • 清晰的项目结构（模块化）

  • 单元测试和评估脚本

  • 文档（README + API 文档）

  • 简单的 UI 或 CLI

  • 日志和可观测性

• 开源贡献：提交 PR 到 hello-agents 项目的 contribution 目录，和其他学习者交流。这不仅是展示，也是你参与开源社区的开始，对职业生涯很有帮助。

碎碎念：后续会更新每天学习的八股和算法 题，开始准备秋招的第23天。努力连续更新100天！以后每天就按，秋招项目【java+agent】，科研，必做项目，算法，八股，锻炼身体来总结。

总结：还行，就是回来要锻炼抓紧时间

1.算法要系统过一遍【灵神】12/27【早上下午】大概2h

2.秋招项目，【java】开始实际看业务，2.9/10；无

【agent】还在学，决定把helloagent看一遍，看完了，但是要总结一下；3h

3.科研要跑一下，无

4.检测项目也得总结文档，2h

5.训练项目看看先选择好，1h

6.背八股，无

7.锻炼身体，无

反思：一心一意的学习，学的知识要总结