我一直在学习人工智能代理中的记忆，发现自己被所有的新术语淹没了。一开始是短期记忆和长期记忆。然后变得更加混乱，包括程序性记忆、情节记忆和语义记忆。但等等，语义记忆让我想起了一个熟悉的概念：检索增强生成（RAG）。
代理中的记忆是否是普通 RAG 演变为代理 RAG 后的下一步？代理中的记忆核心在于将信息转移进大型语言模型（LLM）的上下文窗口。无论你称这些信息为“记忆”还是“事实”，对这个抽象来说都是次要的。
这篇博客是从一个不同的角度介绍人工智能代理中的记忆，可能与其他博客中看到的不同。我们不会（还不）谈论短期记忆和长期记忆，而是逐渐将简单的 RAG 概念演变为代理 RAG，再到智能体中的记忆。（请注意，这是一个简化的模型。代理记忆的整个主题在底层更为复杂，涉及诸如记忆管理系统等内容。）

RAG：一次性只读

检索增强生成（RAG）的概念于 2020 年首次提出（Lewis 等人），并在 2023 年左右获得了广泛关注。这是第一个让无状态的 LLM 访问过去对话和在训练时未见过且未存储在其模型权重中的知识（参数知识）的概念。
简单 RAG 工作流程的核心思想很简单，如下图所示：

1. 离线索引阶段：将额外信息存储在外部知识源（例如，向量数据库）中。
2. 查询阶段：使用用户的查询从外部知识源中检索相关上下文。将检索到的上下文与用户prompt一起输入到 LLM，以获得基于额外信息的响应结果。
   
   以下伪代码说明了简单的 RAG 工作流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# Stage 1: Offline ingestion
def store_documents(documents):
    for doc in documents:
        embedding = embed(doc)
        database.store(doc, embedding)

# Stage 2: Online Retrieval + Generation
def search(query):
    query_embedding = embed(query)
    results = database.similarity_search(query_embedding, top_k=5)
    return results

def answer_question(question):
    # Always retrieve first, then generate
    context = search(question)
    prompt = f"Context: {context}\nQuestion: {question}\nAnswer:"
    response = llm.generate(prompt)
    return response

尽管简单的 RAG 方法在减少简单用例的幻觉方面是有效的，但它有一个关键的局限性：它是一个一次性解决方案。

• 额外信息通常是从外部知识源获取的，而不考虑其是否真的必要。
• 信息只被检索一次，无论检索到的信息是否相关或正确。
• 所有额外信息只有一个外部知识源。
  这些限制意味着，对于更复杂的用例，如果检索到的上下文与用户查询无关甚至错误，LLM 仍然可能产生幻觉。

代理 RAG：通过工具调用只读

代理 RAG 解决了简单 RAG 的许多局限性：它将检索步骤定义为代理可以使用的工具。这个变化使得代理首先能够确定是否需要额外的信息，决定使用哪个工具进行检索（例如，具有专有数据的数据库与网络搜索），并评估检索到的信息是否与用户查询相关。

以下伪代码说明了代理如何在代理 RAG 工作流程中调用 SearchTool ：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

class SearchTool:
    def __init__(self, database):
        self.database = database

    def search(self, query):
        query_embedding = embed(query)
        results = self.database.similarity_search(query_embedding, top_k=5)
        return results

def agent_loop(question):
    messages = [{"role": "user", "content": question}]

    while True:
        response = llm.generate(
            messages,
            tools=[SearchTool]
        )

        if response.tool_calls:
            for tool_call in response.tool_calls:
                if tool_call.name == "search":
                    results = search_tool.search(tool_call.arguments["query"])
                    messages.append({
                        "role": "tool",
                        "content": f"Search results: {results}"
                    })
        else:
            return response.content

两者之间的一个相似之处是信息存储在离线数据库中，而不是在推理过程中。这意味着数据仅由代理检索，而不是在推理过程中被写入、修改或删除。这一限制意味着两种 RAG 系统都无法从过去的交互中学习和改进（默认情况下）。

代理记忆：通过工具调用进行读写

代理记忆通过引入记忆管理概念解决了 RAG 的这一限制。这使得代理能够从过去的交互中学习，并通过更个性化的方法增强用户体验。
代理记忆的概念建立在Agentic RAG 的基本原则之上。它还使用工具从外部知识库（记忆）中检索信息。但与Agentic RAG 不同，代理记忆还使用工具向外部知识库写入信息，如下所示：

这使得代理不仅能够从记忆中回忆信息，还能够“记住”信息。在最简单的形式中，您可以在交互后将原始对话历史存储在一个集合中。然后，代理可以搜索过去的对话以找到相关信息。如果您想扩展这一点，可以提示记忆管理系统创建对话的摘要以供将来参考。此外，您还可以让代理在对话中注意重要信息（例如，用户提到对表情符号的偏好或提到他们的生日），并基于此事件创建记忆。
以下伪代码说明了代理记忆的概念如何扩展Agentic RAG 的想法，以及代理可以用来存储信息的 WriteTool ：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

class SearchTool:
    def __init__(self, database):
        self.database = database

    def search(self, query):
        results = self.database.search(query)
        return results

# For simplicity, we only define a write tool here. You could also have tools for updating, deleting, or consolidating, etc.
class WriteTool:
    def __init__(self, database):
        self.database = database

    def store(self, information):
        self.database.store(information)

def agent_loop(question, ):
    messages = [{"role": "user", "content": question}]

    while True:
        response = llm.generate(
            messages,
            tools=[SearchTool, WriteTool]
        )

        if response.tool_calls:
            for tool_call in response.tool_calls:
                if tool_call.name == "search":
                    results = search_tool.search(tool_call.arguments["query"])
                    messages.append({
                        "role": "tool",
                        "content": results"
                    })
                elif tool_call.name == "store":
                    result = write_tool.store(
                        tool_call.arguments["information"]
                    )
                    messages.append({
                        "role": "tool",
                        "content": result
                    })
        else:
            return response.content

这个简化模型的局限性

正如本博客开头所述，这种对 AI 代理中记忆的比较只是一个简化的模型。它帮助我将其置于我已经熟悉的事物的视角中。但为了避免让 AI 代理中的记忆主题看起来仅仅是带有写操作的代理 RAG 的扩展，我想强调这种简化的一些局限性：
上面的 AI 代理记忆插图为了清晰而进行了简化。它只显示了单一的记忆来源。然而，在实践中，您可以使用多个来源来处理不同类型的记忆：您可以为

• “程序性”记忆（例如，“与用户互动时使用表情符号”），
• “情节性”记忆（例如，“用户谈论了在 10 月 30 日计划一次旅行”），以及
• “语义记忆”（例如，“埃菲尔铁塔高 330 米”），
  如 CoALA 论文中所讨论的。此外，您可以为原始对话历史建立一个单独的数据集合。
  上述示例的另一个简化是，它缺少除了 CRUD 操作之外的内存管理策略，如 MemGPT 中所见。
  此外，尽管代理记忆实现了持久性，但它引入了 RAG 和Agentic RAG 所没有的新挑战：记忆损坏和需要记忆管理策略，例如遗忘。

总结

RAG、Agentic RAG 和代理记忆的核心在于如何创建、读取、更新和删除存储在外部知识源中的信息（例如，文本文件或数据库）。

最初，优化简单 RAG 的关键重点在于优化检索方面，例如，使用不同的检索技术，如向量检索、混合检索或基于关键词的搜索。然后，重点转向使用正确的工具从不同的知识源中检索信息（“我需要检索信息吗？如果需要，来自哪里？”）。在过去一年中，随着代理中记忆的出现，重点再次发生了变化。这一次，重点转向信息的管理：虽然 RAG 和Agentic RAG 在检索方面有很强的关注，但记忆则包含了在外部知识源中创建、修改和删除数据的过程。

原文：The Evolution from RAG to Agentic RAG to Agent Memory

首先，我不是批评思考，在很大程度上我是赞同先思考，而再执行的。尤其是，很多事情，可能‘莽撞’的执行，导致我们的资源出现了浪费的情况，务必进行仔细的思考方可继续进行。

我批评的是，很多事情我们明明知道是正确的，但是不去执行，而是反复的在研讨/证明这个事情的正确性。这种行为不仅浪费了时间，还可能导致团队成员之间的不信任和矛盾。

这个现象我相信大家都有遇到，有很多事情，是不需要证明其正确性的，比如公理？比如常识？比如一些不是我们需要研究的方向，而我们是使用方的角色，例如数学的1+1=2，物理的万有引力定律，化学的元素周期表等等。
但是，我发现工作中，经常会遇到明明我们已经确认要做，也的确在做，却要不断的、重复的去证明这个事情的价值，而且还要被量化。这个就很困难了，毕竟不是所有的事情都能被量化的。而且，量化本身也存在很多问题，比如如何定义量化标准，如何保证量化结果的准确性等等。大家可能对量化的‘公式’不认可，大家可能对量化的参数不认可，可能每个人对结果都不一定认可。很多时候的量化公式、推到过程，是因为我们先有了结果，再去进行推导的。

这样的事情，在我们的工作中，可能浪费了比较多的事情，导致我们错过了一些工作的先机。所以，我个人很大程度上，是在这样的场景建议我们先干起来，快步、小步的跑起来，不断的去论证，不断的去尝试，不断的去试错，不断的去拿到收益。just try it, just try it, just try it。

最近遇到了一个灵魂问题，团队需要几个人？为什么是这么多人，而不是其他的人数？。这可的确是一个非常难的问题了，我相信每个人都有不同的答案，大家的认知也是不一样的，如果这个事情能够被量化，我想应该可以发布一篇完整的论文了。我现在的阶段来看，这个问题不值得深入的讨论，本质上是重视程度问题，我们如果能讲清楚我们做了什么事情，哪些方向，需要多少人力就可以了。就像是PM在说我们要做哪些功能，如果评审通过，那就干。这些方向研发需要多少个task，需要多少研发就好了。先干起来，让功能快速上线去获客，千万不要这个时候纠结，如果我做了某一个平台，能够提效多少，所以我可以少招聘N个人。兄弟，如果你没做出来呢？如果效果不符合预期呢？那功能能上线么或者上线的功能真的是用户想要的那个效果么，还是打过折扣的。

我知道，现在的降本增效很必要，但是务必保证效果。想要精细运营是正确的，但是想要量化精细运营的人力消耗，我感觉是不合理的。

当前我们在开展很多效率提升的工作，如果的关联到提效了多少人，那这个团队的人数量是一直要减少吗？不是的，今年做了这个事情，明年还要做另外的事情，团队不要发展么？公司不要发展么？如果只看到了现在的事情，那么答案是肯定的，可以干掉N个人，如果看到未来，那么就是另一个答案了。也许，大家很担心，我们的公司收入已经降低了，不需要这么多人，但这个事情没有一个直接对应的关心，世界是混沌的、熵增加的，让我们用更多的时间去工作，而不是研究某一个项目节省了多少人力、或者团队需要多少人吧。

just do it，先干起来，毕竟那么多确定性的事情我们还没有完成，工作现在是堆积的状态，不是活少人多，而是活多人少呀！何必去证明这个常识呢？

首先，我个人认为我自己是一个「非常正经」的司机，「非常」正经的人。我非常正经地遵守交通规则，但不幸的是，我还是犯了一个错误。接下来分享一个今天的交通事故案例：

先上一张我家小区路口的当时的情况照片

时间线

日期：2025.07.04
以下为时间线：

• 8:08 我出小区之后，开始右转排队。①我观察到蓝色车掉头，红车不退让，蓝色掉头不动；蓝色和红色交流，希望后退一下让他掉头，红色稍后退了一下，蓝色完成了掉头；②我看蓝色掉头之后，有了可以右转弯的空间，我「插队」进入到主路，但还没转弯完成
• 8:09 ③红色车向前缓慢形势，因为小区门口非常堵车，大家行进速度大约在 2~5 迈。我继续缓慢右转，红色车一个加速，我们两个车碰撞上了，剐蹭并不严重，稍后上图，注意，这里是第一次碰撞。接下来④他又加速了一次，又碰撞了一次。为什么我知道他又加速了呢？因为我正好开着车窗，听到了他哄油门的声音，他是丰田雷凌。我发现他进行二次有意碰撞。⑤我在车内和他说，碰上了。他摇下车窗，冲我喊，「我知道碰上了，怎么样！你报警！」态度很嚣张。
• 8:10 我打开双闪，打报警 122 电话，说明情况。对方下车「一气呵成」，拍照完成立马把车挪走了，非常娴熟。而此时我电话还没打完呢。
• 8:11 完成和 122 电话报警，说明了碰撞情况，我不满意对方二次「有意」撞我，请求交警帮助。122 接线员让我把行车记录仪视频下载下来。
• 9:10 辅警过来说我是右转，对方是直行，尽管是拥堵路口排队，也必须保持安全的情况下进入。我同意这个观点，我接受处罚。我问交警（此时我一直以为是交警，后来他自己说他没有执法权，是辅警）第二次的「有意」碰撞怎么办。辅警看了我的录制视频，说，这个情况无法认定，除非你报警 110。我同意，辅警帮我联系了民警警察。
• 大约10:00 民警来了，看了情况，说民警不管这个事情。只有「我停车在路边，对方撞向我的车」或者「我站在路边，对方撞向我的人，民警才管」，其他情况交警进行定责，行车记录仪视频都没看。并且说：80%的情况，被撞的车辆，都说对方有意撞的，但是无法界定，找交警。辅警和我说，他也没办法界定，视频里面车辆的确有第二次行进的情况，但不能明显看出对方是「有意」的。我要求看对方行车记录仪视频，辅警说，网约车司机说他行车记录仪坏了，无法提供。 网约车行车记录仪坏了？看到问题了吧。他没办法提供行车记录仪视频，我的行车记录仪视频又是左侧盲区录制的不全，辅警说无法界定，民警也来了，你看走快速处理，你全责是，行不行？
• 10:10 我说可以，那就这样吧。我不纠结了，我接受处罚。此时网约车司机：不行！不能走线上处罚，必须走线下，必须测酒驾，怀疑我酒驾。辅警：这样吧，走线上你俩快速处理一下，行不行？对方已经全责了。网约车：不行，必须测酒驾。辅警：那就等等吧，交警过来需要一段时间，过来给你们测酒驾。
• 10:30 辅警说交警在处理一个复杂交通事故，无法过来，你俩去交警队吧，这样快一些。我俩都同意，开车前往交警队。
• 10:40 到达交警队
• 11:10 交警队交警回来，看了现场照片和我行车记录仪视频，认定我全责。我说 OK，可以；辅警对我们做了酒驾测试，均未饮酒。网约车司机：不行，我现在受伤了，我肚子和头都撞到了方向盘，我要求医院检查。 2~5 迈撞车，碰到了肚子和头？ 。我提出了质疑，交警说这个按照口述写对方已经受伤，是否真的受伤按照实际医院检查为准。我说 OK。
• 11:15 网约车司机要求加我微信，我拒绝；给了他手机号，交警开了处罚单，说明我全责。同时对我进行了口头批评：虽然道路非常拥堵，你只能这么开车，但是一定要安全驾驶，务必保证安全再转弯。这次只进行口头批评，后续注意。
• 11:15~11:30 我电话了平安保险公司，说明了整个情况，提供了车辆照片，碰撞照片，处罚单等等。其他的安排保险公司去处理了，保险公司和我说：对方检查如果 1.8 万以内都用交强险，不会影响明年保费，已经遇到这样的人，只能随机应变了，没办法，什么人都有。同时问我是否需要修理车，因为车实在是受伤比较小，我选择不修理。
• 15:42 平安公司打电话，对方在医院检车花费 700，开了 3 天假条，一共保险公司赔偿他 1500 块钱。保险公司问我，是否有异议，没有异议，保险公司就使用交强险进行报销，需要我短信签字。我说有什么办法治理一下这样的风气和人不，保险公司说：没有办法，这种见太多了，就是讹钱，非常多，这样的情况只能支付，保险公司也没办法。

车辆受损照片如下：

一些感想

1. 不要插队！但是不可避免的时候，插队「昂贵」车辆的队，比如 20 万以上的。虽然一定程度上有「歧视」行为，但是相对来说这些昂贵车主素质更高，大家可能是打工牛马，为了上班时间会互相礼让。
2. 遇到胡搅蛮缠的，一定报警，不要私了。他们想通过各种方法「坑你」。比如你是不是喝酒了、装作肚子疼、脑袋疼等，可能是为了坑你的「钱」。
3. 不要尝试说明对方「有意」撞了你的车，没有办法说明，自己这种情况只能认亏，所以千万不要撞车，才是王道。
4. 我一直觉得我是老司机，开车 7 年了，没有和其他人发生过交通事故，上一次还是 7 年前被人追尾了，但是不要大意，你永远不知道会遇到什么人。
5. 人和人是有区别的，我在这个事情里面的确有处理不当的地方，保持冷静，不要冲动。
6. 对方「娴熟」的记录自己交通事故，已经说明他是一个「老司机」了，这样人，一定要远离。
7. 自己吸取教训，不要撞车，才是王道。自己吸取教训，不要撞车，才是王道。自己吸取教训，不要撞车，才是王道。
8. 车辆一定要有行车记录仪，而且要有效、高清，这个可能是你唯一证明自己的机会，一定有、务必有。
9. 一定买高额的保险，这个是保护自己的最后一道生命线；不要喝酒，不要喝酒，不要喝酒，安全驾驶！
10. 做一个好人！

为了将 Gemini 更加能有非常强大的满足大家的使用需求，大家更关注他输出的格式、输出的内容真实性以及个性化，所以我在 Gemini 的 save_info中添加了如下描述，发现此后 Gemini 的回复效果非常惊人。
添加内容如下（可以分开四段添加）：

1

The language I am used to is Chinese, also know some English. I work in the ${internet industry in software development} and my position is ${position}. I want to understand 99% of what I want to ask for knowledge by using Gemini to help me with 80% of the core content of my answers. I am more interested in gaining in-depth, rational knowledge here.

注：work info 和 position 需要自己修改成自己的实际情况，例如 SWE、UE 等等。

1

You need to comprehensively analyze the questions raised by me, and while strictly following instructions, you need to be able to think divergently and more comprehensively about my intentions and give more comprehensive answers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

1. Efficient Information Delivery: Provide the most valuable and pertinent knowledge swiftly.
2. Depth and Comprehensibility: Balance informative richness with understandability—avoid superficial treatment or excessive complexity.
3. Neutrality and Reliability: Maintain objectivity, respect sources, avoid fabrications, and refrain from introducing bias or hallucinations.
4. Professional and Readable Format: Ensure responses are structured, easy to read, and exhibit professional articulation.
5. Formal and Correct Tone: Prioritize accuracy and reasoning, gradually delve deeper; exemplify principles with illustrations.
6. Coaching Approach: Step-by-step explanations.
7. Truthful Sharing: Direct and honest.
9. Forward-thinking Perspective: Share distinct, clear viewpoints.
10. Corporate Terminology: Utilize formal business language; summarize complex terms.
11. Logical Coherence: Assure cohesive logic, avoiding ambiguity or contradiction.
12. Clear Structure: Employ hierarchical structures (e.g., top-down, step analysis, impact-solutions).
13. Truthfulness and Reliability: Base answers on facts—if disputed, clarify differing opinions.
14. Emphasized Formatting: Utilize larger fonts, enhanced colors for titles; bold or italicize key content.
15. Prioritization: In cases of conflict, prioritize accuracy, neutrality, and time management.

1

Do not invent or assume facts. If unconfirmed, say: “I cannot verify this.” or “I do not have access to that information.” Label all unverified content: [Inference] = logical guess, [Speculation] = creative or unclear guess, [Unverified] = no confirmed source. Ask instead of filling blanks. Do not change input. If any part is unverified, label the full response. If you hallucinate or misrepresent, say: Correction: I gave an unverified or speculative answer. It should have been labeled. Do not use the following unless quoting or citing: Prevent, Guarantee, Will never, Fixes, Eliminates, Ensures that. For behavior claims, include: [Unverified] or [Inference] and a note that this is expected behavior, not guaranteed.

注：此段用来防止幻觉。

ps：可以额外增加更多你的个人信息，比如 location、name、age 等等，你自己需要的，你会发现 Gemini 变成了一个你个人最强大的助手。

最近的工作总是和 GPU 绕不开，有一个资源效能方向的工作要提升 GPU 的“利用率”，本周是期望 GPU 能够不仅仅用起来，而且有效的用起来、用满。

我们的监控系统中有一个 GPU 利用率的指标，调研之后发现，这个有点“玄幻”，这个不是 GPU 利用率，或者说，现在没有一个合适的指标能表征 GPU 利用率。

英伟达官方 GPU 利用率定义

依据这个公示，如果一个 GPU，有 10 个 SM，并且只有一个 SM 在工作那么利用率是 = 1/10*100% = 10%。
然而通过nvidia-smi工具可以看到，获取的 GPU 利用率是 100%，非常奇怪，和上面的逻辑对不上。

nvidia-smi 中的 GPU 利用率

1
2
3
4
5
6
7
8
9
10

#include <stdio.h>

__global__ void simple_kernel() {
    while (true) {}
}

int main() {
    simple_kernel<<<1, 1>>>();
    cudaDeviceSynchronize();
}

此代码片段将在单个流多处理器 (SM) 上启动指定的内核（线程）。根据常规理解，GPU的“利用率”应该计算为1 / num_sm * 100%。例如：

• 如果 GPU 上有 10 个 SM，则“GPU 利用率”应为 10%。
• 如果 GPU 上有 20 个 SM，则“GPU 利用率”应为 5%。
  然而，据观察，nvidia-smi 可能会报告”GPU-Util” 100%，如以下示例输出所示：

1
2
3
4
5
6
7
8
9
10

$nvidia-smi
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM2...  Off  | 00000000:1A:00.0 Off |                    0 |
| N/A   42C    P0    67W / 300W |   2602MiB / 32510MiB |    100%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

GPU-Util 误导

nvidia-smi命令行工具基于 NVIDIA 管理库 (NVML)；nvidia-smi输出的结果中的确有GPU-Util，但是这里的定义是什么呢？

1
2
3
4
5
6
7
8
9
10

// https://github.com/NVIDIA/go-nvml/blob/v0.12.0-1/gen/nvml/nvml.h#L210

/**
 * Utilization information for a device.
 * Each sample period may be between 1 second and 1/6 second, depending on the product being queried.
 */
typedef struct nvmlUtilization_st {
    unsigned int gpu;                //!< Percent of time over the past sample period during which one or more kernels was executing on the GPU
    unsigned int memory;             //!< Percent of time over the past sample period during which global (device) memory was being read or written
} nvmlUtilization_t;

根据NVML的定义，“GPU利用率”是指 在过去的样本期间内发生某些活动的时间百分比。这里竟然是时间片！
具体来说：

• GPU 利用率：这表示一个或多个内核在 GPU 上执行的时间百分比。
• 内存利用率：这表示读取或写入全局（设备）内存的时间百分比。

含义：NVML定义的“利用”概念可以不符合我们的共同理解。它仅测量给定采样周期内设备使用的时间部分，而不考虑该时间内使用的流式多处理器 (SM) 的数量。 通常，我们将“利用率”视为正在使用的 GPU 处理器的部分。

所以，这个数据并不能代表 GPU 是不是用满了，更好的指标应该是 SM 利用率，可能更合适。或者进一步说，每个 GPU 用在推理、训练的场景都不一样，我们应该使用业务的 SLO 指标来驱动 GPU 资源的使用情况建设，如果能够进行压测评估GPU 的情况，那将是最准确的。

自己的 macOS 安装了很多效率工具，每次换 macOS 的时候自己还需要下载一番，偶尔名字还有记不住的情况，正好进行一次整理。

工作

• iTerm2: macOS 端最棒的终端工具。
• Visual Studio Code: 偶尔写代码使用。

效率

• Google Chrome: 目前 macOS 端最棒的浏览器。安装了以下的扩展 extension:
  1. 剪藏: 剪辑到好文章到印象笔记。
  2. AdGuard广告拦截器: 顾名思义，拦截广告使用，净化上网。
  3. Easy Auto Refresh: 设置 X 秒自动刷新页面，对查看一些监控页面很好用。
  4. Hide X.com Ads: 屏蔽 X 平台的广告。
  5. iCloud 密码: 使用 macOS 端的密码管理器填写 Chrome 的用户名和密码。
  6. JSON-handle: 将 https 接口等返回的 JSON 内容格式化、美化。
  7. Share on twitter: 分享一些自己喜欢的内容到 X/Twitter，可以选择文字也可以分享整篇文章。
  8. Vimium C: 加强版 Chrome 端使用vim 控制浏览器行为，比如关闭页面、打开链接等。
  9. Web Highlights: 对页面的文字内容增加颜色，已经买断，方便下次浏览页面的时候找到文档的重点。同时支持在web highlights app 内查看全量的标记文章、文字以及进行阶段性的复习，增强记忆。必备！
  10. 沉浸式翻译: 浏览英文网站文字&&视频必备，可以快速将文章和主流网站的视频翻译成你需要的语言。
• Quitter: 实现 macOS 上的软件可以超过一定时间自动最小化、自动 quit 退出等，避免占用 macOS 资源。
• Raycast: macOS 最佳的 App 启动、文件查找等效率工具，每日使用 N 次，效率提升 Max。
• keka: macOS 端最佳解压软件。
• Things: macOS 端最棒的待办管理软件，支持多端同步等，每天查看 N 次。
• Skim: macOS 上最佳的 PDF 阅读 App。
• MarginNote: 看 PDF 文档的学习工具，可以进行脑图生成、记忆测试等，非常棒！建议买！
• Easydict: 一个简洁优雅的词典翻译 macOS App。开箱即用，支持离线 OCR 识别以及多种翻译途径。
• Manico: 使用多种快捷键组合启动 App，每日使用 N 次。
• Hidden Bar: 一款超轻量的 MacOS 实用程序，可帮助隐藏菜单栏图标。免费！
• Paste: 非常精美、漂亮的剪贴板管理工具，可以保留非常多的剪贴板历史。唯一不足：暂时发现不能自己添加同时包含图片和文字的 snippet，不过，这个 App 非常漂亮，忍了。
• Chatwise: 可以支持 OpenAI、OpenRouter 等多种途径添加模型的模型 client，同时支持 MCP，更新迭代非常快！已经买断！
• popclip: 使用鼠标选择一部分文字的时候可以弹出来 pop，里面可以安装自己喜欢的插件功能，比如快速百度搜索、翻译等。

理财

• iCost记账: 手机端和 macOS 端同步的记账工具，每日使用大约 3～4 次。App Store 有下载。

安全

• LuLu: LuLu 是免费的开源 macOS 防火墙，防止一些软件联网，例如 xx 输入法等，断其网络连接权限，避免上传个人隐私数据。