Hi, 我是malaxg👋

你用 Sublime Text 用了三年，它记得你的配置、你的快捷键、你的代码折叠习惯。你用 Chrome 浏览器，书签、历史记录、密码全都在——打开一个新标签页，它甚至知道你接下来最可能去哪里。 我们对工具有一个朴素的期待：越用越好用。 不是因为工具本身变聪明了，而是因为它记住了你。 AI Agent 应该更强才对。它能理解语言，能执行复杂任务，比任何一个传统软件都聪明。可是你有没有注意到——你用了三个月的 AI Agent，和第一天用它，感觉差不多。它不记得你上周跟它说过的话，不记得你修正过它三次的同一个错误，不记得你的偏好和习惯。 每一次对话，都像是重新认识。 更糟的是，时间长了，情况有时反而会更差。Agent 在长期运行过程中会积累记忆——但没有人整理这些记忆。重复的条目、矛盾的信息、早已过时的经验，全部堆在一起。Agent 读到它们，反而被干扰。越用越乱。 这不是模型的问题，也不是 prompt 的问题。这是记忆架构的问题。 一、Agent 的记忆是怎么工作的 要理解这个问题，先要搞清楚 Agent 的记忆是怎么运转的。 现在主流的 Agent 记忆方案，大概是这样的：每次 Session 结束，Agent 把这次学到的东西写进一个 Memory Store——可以理解成一个外置的笔记本。下次启动，Agent 读一读这个笔记本，带着这些上下文继续工作。 这个设计逻辑上没问题。但有一个致命的缺陷：只有写入，没有遗忘。 注意，我说的不是"没有整理"。整理是技术问题，加一个清理脚本就能解决。真正的问题更根本：系统从来没有被要求去判断什么值得留下。 但你可能会问：为什么不加这个判断？删掉旧的、留下新的，不就解决了吗？ 问题在于：遗忘，比你想象的要难得多。 机器学习领域有一个经典难题，叫做"灾难性遗忘"（Catastrophic Forgetting）。当你试图让一个神经网络遗忘某些东西、同时保留其他东西时，结果往往是灾难性的——新内容学进去了，旧的能力大幅崩溃。这不是工程偷懒，是系统架构的深层矛盾：神经网络的知识不是一条一条独立存放的，它以分布式的方式散布在整个权重矩阵里。你拉动一处，整个网络都在颤抖。 人类大脑之所以能精准遗忘，是因为神经可塑性与记忆固化之间有一套极其复杂的协调机制——几亿年进化磨出来的，我们到现在还没完全搞清楚它是怎么工作的。 所以，Agent 不是没意识到应该"遗忘"，是这件事真的很难做到。Memory Store 的只写入设计，某种程度上是现阶段一种无奈的正确选择——既然做不到精准遗忘，不如先老实只写入，至少不会弄出灾难性的结果。 但代价是：随着使用时间拉长，Memory Store 里的条目越来越多，信噪比越来越低，Agent 每次启动读到的信息质量越来越差。不是没有记忆，是不会遗忘的系统，注定会被记忆淹没。 二、人类为什么越用越好用：REM 睡眠 人类其实面对过同样的问题。 每一天，我们接收的信息量是海量的。如果大脑把所有感知到的东西都以同等权重存下来，用不了多久就会崩溃。但我们没有崩溃——因为大脑有一套自动的整理机制。 这套机制的核心，发生在睡眠中，尤其是 REM（快速眼动）睡眠阶段。 REM 睡眠在做什么？神经科学的研究告诉我们，这个阶段大脑并不是在休息，而是在忙碌地工作：回放白天的经历，把短期记忆巩固成长期记忆，过滤掉无关的噪音，提炼出有价值的规律和模式。 注意这个关键点：REM 不是在存储更多，而是在把已有的整理得更好。更准确地说，REM 在做一件听起来很反直觉的事——主动丢弃。白天你记住了 100 件事，经过一夜 REM，可能只有 20 件留下来。但这 20 件是真正重要的，而且以一种更结构化、更易检索的形式存在。 ...

你用过的是模型，你要搭建的是系统 如果你用过 ChatGPT 或 Claude，你大概知道它们能做什么——回答问题、写代码、分析文档。你输入一段话，它输出一段话。这种交互方式很自然，也很强大。 但当你开始构建一个 AI Agent 时，你会很快发现，事情不再是这样运转的。 用模型和搭 Agent，这两件事之间有一道明确的分水岭。用模型时，你是那个"循环"——你读取模型的输出，判断它对不对，决定下一步做什么，再把新的上下文喂给它。你的大脑在负责记忆、判断、决策、纠错。模型只负责在每一步生成文字。 搭 Agent 时，这个"循环"需要由系统来承担。没有人在中间手动审阅每一条输出，没有人帮模型记住上次做到哪里，没有人在模型犯错时及时叫停，没有人帮它判断应该调用哪个工具、有没有权限这么做。所有这些，都需要你设计的系统来处理。 这个系统，就是 Harness。 一、Harness 是什么 最简洁的定义： Agent = Model + Harness 模型负责一件事：给定一段输入文本，生成下一段输出文本。推理、写代码、分析数据——这些在模型眼里都是同一件事：文字进，文字出。模型本身不会"执行"任何操作，不会"记住"任何跨会话的信息，不会"决定"什么时候停下来。 Harness 是模型之外的一切工程层——工具调用体系、上下文管理机制、持久化记忆、权限控制、多 Agent 协调。简单说，让模型能在一个真实任务里稳定工作所需要的全部基础设施，都是 Harness。 有一个类比流传得很广：模型是 CPU，Harness 是操作系统。这个类比抓住了一个关键真相：CPU 再强，没有操作系统，你也只能对着裸硬件写机器码。操作系统管理内存、调度进程、提供文件系统、控制权限——它让 CPU 的能力真正对应用程序可用。Harness 对模型做的事情，在结构上是相似的。 不过这个类比有其局限：操作系统管理的是确定性程序，给定相同输入，输出永远相同。模型是概率性的——相同输入可能产生不同输出，有时候会犯错，有时候会"幻觉"。Harness 必须处理这种不确定性，这是 OS 从来不需要面对的挑战。 Harness 也常被和另外两个概念混淆，有必要区分清楚： 层级 解决什么 核心关注点 Prompt Engineering 怎么写指令才能让模型理解意图 一次对话的质量 Context Engineering 模型在某个时刻应该看到什么信息 信息的选择与组织 Harness Engineering Agent 整个执行过程中系统怎么稳定运转 长链路任务的可靠性 Prompt Engineering 是关于如何"说话"。Context Engineering 是关于"给模型看什么"。Harness Engineering 是关于整个系统的运行环境——如何设计约束、如何管理状态、如何处理失败、如何跨会话保持连续性。三者不是并列竞争关系，而是嵌套包含的层次结构。 二、上下文管理：模型的工作记忆 上下文窗口是什么 模型在执行任何任务时，它"知道"的一切——你的指令、对话历史、工具调用的结果、它自己的推理过程——全部存在一个地方：上下文窗口（Context Window）。 ...

好久没有写作了，心血来潮，想着该写点什么。 实习到现在差不多半个多月了，干的事情呢算是一个比较有意义的方向吧（Text2SQL），但是正如许多博客讲的那样，这个方向做出一个demo容易，但是要往深了做，就比较困难了。 好像确实，做一个Demo，你只需要建一个有详细信息的库表Schema，和Query一起加入到提示词当中，就能展现Text2SQL的魅力，不需要自己编写SQL语句，就能够完成自己想要的查数分析。但是仔细做下来还是发现了许多困难，因为不像是学术届的Text2SQL，我现在做的是希望能够落地服务到上游业务的。所以不能拿学术届开源数据集的指标来检验我的方案，需要从实际的业务系统中构建评测样本。所以这半个月来，除了探索Text2SQL的方案以外，做的工作也就是如何构造一个可靠的评测数据集了。 让人哭笑不得的是，其实司内其他团队也有做Text2SQL的，甚至在大模型平台上还有Text2SQL的插件（昨天刚发现），刚发现这个插件的时候，感觉天塌了，开始怀疑自己工作的必要性，可是我的好mt又不在，又没法跟他探讨哈哈哈。但是仔细调研了发现，这个插件并不是一个可用于上线的插件，还是一个处于研发阶段的Demo，所以好像我这半个月也不算是白干。而且通过这个半个月，我能通过这个插件简短的介绍猜到它的处理逻辑是怎样，和我目前的方案有哪些区别，好像付出确实还是会有收获。 还记得前不久和朋友感叹，从当初的小山村走到这里，回望来时路，我好像已经走了好远好远。记得原来跟随父母在外务工，读的是当地的私立小学，当时有一些当地专科院校的大学生来学校里开展课外活动，当时觉得：真好，我什么时候才能成为那样的人呢？到后来，我到了重邮，在哪里度过了4年，不对，是即将度过第7年；在高中时代，班里来了一个新老师试讲，是西南大学的研究生，当时班主任介绍的时候，说是研究生，当时觉得研究生离我好遥远，而现在，我研究生也已经读了两年；在本科期间，学院会组织一些学长宣讲，讲讲自己的竞赛经历、实习经历，保研经历等等。我记得当时有学长分享的是在百度的实习经历，当时眼里充满了羡慕，想着：真好，我什么时候才能去大厂实习呢？我现在正坐在大厂的工位上写着我的碎碎念，当然这其中的运气成分也占了相当一部分。在研一的时候，本来导师给我定的方向是关于仇恨言论检测的，可是当时实验室里有师姐的论文中了当年的一个会议，导师想着这条路能走通，就问我愿不愿意换到现在的这个方向上来。刚好关于仇恨言论检测我也没怎么入门，就干脆换到这个方向上，还能请教师姐。当时看着师姐经历论文出分，Rebuttal，到中稿。当时想着：真厉害，我的论文要是能中就好了，而前不久，我的导师已经为我交了会议注册费，虽然是该多模态领域，这个会议没什么认可度，但是总归是达到了毕业条件。 回望过去当初那个小小的老子，真的好不容易。因为在小山村，上学得沿着山路徒步半个小时。当时的自己想不到，也没有概念去想象自己会在10年后的今天坐在大厂的工位上办公。一路走来，好似命运总是眷顾我。我逐渐的长成了原来需要仰望的人，或许在很多人眼里，这并不是什么大事，但是我感叹的是：从小山村的我，再到大都市的我，我花了10+年。我不清楚我是否能够在现在的公司顺利转正，但是我希望在以后，我的未来依然能够受命运之神眷顾，依然能够顺顺利利。

😀 2024年写了一篇年度总结， 想着2025年也写写！总的来说，今年的主旋律好像就是做竞赛，Kaggle、腾讯广告算法大赛、挑战杯。。。。虽然最终成绩都不算好，但是总归是有一些成果，总算是没有虚度时光吧。对了，除了竞赛，还为了加综测分去考了一个中级软件设计师，不过未来不准备进国企，估计没啥用。 腾讯广告算法大赛 谈到这其中收获最大的估计就是暑期的腾讯广告算法大赛了，靠着进复赛的成绩，我拿到了腾讯的实习offer，但是具体做什么我还不确定，因为在选择志愿的时候考虑到要和面试官聊简历，我第一志愿选择的是大模型应用（简历上全是大模型应用的项目），推荐方面的经历几乎可以说是没有。也是通过这个比赛我才接触到了推荐这个领域，如果实习的内容也是推荐的话，估计以后的职业发展也是往推荐这个方向走了，所以说这个比赛对我还是影响挺大的。 通过这个竞赛，粗浅的谈谈我对未来业界推荐的发展方向，毋庸置疑的，现在的推荐都在朝着可以Scaling的方向发展，原来的推荐业务由于包含了像召回、粗排、精排这种级联的形式，所以导致发展下来非常的臃肿，随着推荐技术的发展，大家都迫切希望有一个可以革新的内容来颠覆推荐范式。这也是腾讯广告算法大赛设置的初衷（自我感觉），所以有了现在的生成式推荐，每个大厂都在尝试将自己的业务往生成式推荐的领域上面推进。但是很显然，这是一个比较新的领域，我感觉至少现在大家的业务普遍都还是在传统的推荐系统上面跑着的，当然肯定有业务在生成式推荐上跑，但是以我粗浅的感受来看，肯定这只占了一小部分，生成式推荐还需要更深的发展才能足以支撑整个业务需求。 谈到这里，好像我的职业规划也比较清晰了，首先肯定是做算法工程师，但是双非背景的我能做的选择本就不多，做大模型算法（不管是基座还是应用，可能应用稍微好点）我的bg肯定是不够的，所以很大概率我未来的职业选择是往推荐上面考虑了。但是需要些什么呢？实习？竞赛？论文？貌似现在的传统的推荐竞赛几乎是很少了。这两年的nlp竞赛都被llm包圆了，我们组又缺资源，所以说只能考腾讯广告算法竞赛来支撑了。其次，因为组里不是做推荐的，所以说靠组里做推荐相关的论文也不太现实。所以实习和论文都放在实习这一部分，实习做什么还不知道（我选择的是26年1月份去实习），希望少一些dirty work吧，也希望自己能够胜任这份工作！所以好像最后的选择还是取决于实习的内容哈哈哈哈，走一步看一步吧。 更新：和HRBP沟通了一下，工作岗位是大模型应用的岗位，也算是回到了最初的职业发展规划上面，期待后面的实习内容，还得继续看大模型相关的知识。 挑战杯 这项任务其实算是实验室的指标，老板强制了所有同学都参加，自己选择赛题（因为不像主赛道，人工智能+专项赛是可以选择不同赛道的）。刚好前面跟着老板和重医的同学建立了联系，所以选择了中医的赛题，有重医的背书，PPT也要好做一些。虽然方案什么的都是我构思的，最后负责人安排给了菠儿哈哈哈哈，所以最后的答辩是菠儿去的（PS：怎么样才能克服害怕答辩的毛病啊！！）。确实从答辩的角度来看，感觉都没什么问题，所以就是方案打不赢人家，最后也是得了一个国三，虽然这部分内容是在做腾讯的时候抽空做的。但终究是花费了时间的，也算是有一个交代吧哈哈哈，估计以后也不会在做这种类型的竞赛了。 Kaggle Kaggle今年的战绩是两银一铜，确实感觉和前排选手的差距很大，不仅体现在idea上面，也体现在code能力上，这一点在腾讯广告算法大赛上体现的尤为明显。做竞赛其实不仅仅需要的是时间的投入，这之外还需要idea的迸发，高效的code实现。任何事情貌似都能遵循：行则将至，观则甚远，做kaggle更是如此，坚持到最后就能打败很大一部分人了。 未来的路还很长。。。 科研论文 投论文主要是为了毕业，所以投了一个ICASSP，这个会议在语音领域的Track好像是顶会，但是在其他领域一般，对增加履历好像没什么用。我的论文是和多模态情感分析相关的，所以投的多模态相关的Track。这个会议没有给出大分，好像审稿人给的大分只有AC能够看到。我的审稿意见比较borderline。光看小分，我的分数是19、20、21（满分28）。从小红书上抽样看了一下，就是在borderline的位置，但是也有审稿人现身说法说小分没有多大的参考下，主要还是看评论。关于评论我也有一点borderline哈哈哈哈，其中有两个审稿人像是AI审稿（20、21），提出的问题都不是致命的，有一个审稿人像是自己写的审稿意见，但是只给出了小分的19分，但是给的更多像是建议，并且在表述中承认了SOTA的地位。所以是否接收还是不确定的事情。 等待1月中旬的结果吧。 🤗 总结 总的来说，2025年相较于以往感觉经历挺平凡的，但是好像收获又比往年更多，可能是因为人总是在成长的缘故吧。希望2026的malaxg能够顺利实习，顺利秋招，顺利中期，一切顺利。。。就写到这吧

前言 从考研的时候就想说好好地学学算法题，一直到研究生入学了，还是没有咋学，现在从头开始学学动态规划，希望不会烂尾！！ 动态规划也就是大家常说地DP，大家都说DP是没有捷径的，只有猛猛刷题，光看人家解出来，是没有用的，得需要自己动手尝试！找了一份题单，从头开始学DP！在刷题的过程当中领悟DP的精髓。 动态规划入门 从记忆化搜索到递推 大佬的视频讲解：动态规划入门：从记忆化搜索到递推_哔哩哔哩_bilibili 动态规划的核心就是状态定义和状态转移方程。 198. 打家劫舍 问题描述 你是一个专业的小偷，计划偷窃沿街的房屋。每间房内都藏有一定的现金，影响你偷窃的唯一制约因素就是相邻的房屋装有相互连通的防盗系统，如果两间相邻的房屋在同一晚上被小偷闯入，系统会自动报警。 给定一个代表每个房屋存放金额的非负整数数组，计算你 不触动警报装置的情况下 ，一夜之内能够偷窃到的最高金额。 示例 示例1 输入：[1,2,3,1] 输出：4 解释：偷窃 1 号房屋 (金额 = 1) ，然后偷窃 3 号房屋 (金额 = 3)。 偷窃到的最高金额 = 1 + 3 = 4 。 示例2 输入：[2,7,9,3,1] 输出：12 解释：偷窃 1 号房屋 (金额 = 2), 偷窃 3 号房屋 (金额 = 9)，接着偷窃 5 号房屋 (金额 = 1)。 偷窃到的最高金额 = 2 + 9 + 1 = 12 。 解题思路 这个题可以先看成一个回溯题，把一个大问题变成规模更小的子问题，从第一个房子或者最后一个房子开始思考比较容易（因为它们收到的约束最小）。 比如考虑最后一个房子： 不选 问题就变成了n-1个房子的问题 选 问题就变成了n-2个房子的问题 不断这样下去就可以得到一个搜索树！ ...

LeetCode题库 3.无重复字符最长子串 3. 无重复字符的最长子串 - 力扣（LeetCode） 问题描述 给定一个字符串s，请你找出其中不含有重复字符的最长子串的长度 示例 示例 1 输入:s = “abcabcbb” 输出:3 解释: 因为无重复字符的最长子串是"abc"，所以其长度为 3。 示例 2 输入:s = “bbbbb” 输出:1 解释:因为无重复字符的最长子串是"b"，所以其长度为 1。 示例 3 输入:s = “pwwkew” 输出:3 解释:因为无重复字符的最长子串是"wke"，所以其长度为 3。请注意，你的答案必须是子串的长度，“pwke” 是一个子序列，不是子串。 解题思路 错误想法：最开始想成了计算不同字符总数，把字符映射到一个辅助数组里面，然后出现标记为1，最后计算数组当中有多少个1就好了 int lengthOfLongestSubstring(char* s) { int i; int temp[26]={0}; for(i=0;s[i]!='\\0';i++){ temp[s[i] - 'a'] = 1; } int sum=0; for(int j=0;j<26;j++){ sum += temp[j]; } return sum; } 对于字符串 "abcabcbb"，不同字符有**'a', *'b'*, *'c'*，所以 *sum* 会是3，而不是题目要求的最长无重复字符子串（"abc"**）的长度，即3。 正确思路 同样采用辅助数组的方法解决，采用滑动窗口算法计算无重复字符子串的长度，使用了一个数组 lastSeen 来记录每个字符最后一次出现的位置，以及一个滑动窗口 start 来标记当前考虑的子串的开始位置，将**lastSeen**然后全部初始化为-1。滑动窗口遍历字符串。 ...