2026年3月思考笔记

2026 年 3 月思考笔记 本月共 468 条笔记 | 记录时间:2026 年 3 月 1 日 — 3 月 31 日 月度主题:吴哥窟 · AI Agent · 自我叙事 核心话题:格物/ai (约 53 条)、格物/柬埔寨 (约 38 条)、格物/吴哥窟 (约 23 条)、格物/印度教 (约 15 条)、观我 (约 14 条)、格物/越南 (约 11 条) 按日期归档 | Daily Notes Archive 2026-03-01 3月1日 周日 (29 条) 东北直给文化:劳动独立如何塑造不内耗的关系模式 2026-03-01 10:35:04 东北的女性地位是略强势的 尤其是辽吉黑,长期都是中国的重工业的基地 女性从很早开始就进入正式劳动体系(工厂、医院、学校、机关) 并且经济独立,有稳定的收入 双职工家庭都是常态 经济上平等,并且权力是在资源 + 组织能力手里 东北的语言文化气质本身就是直给、少内耗,不服就说的文化 所以情绪表达是正面输出的,不绕弯、不长期压抑、不靠冷暴力、冲突直接爆发、快速解决 男性的议价能力偏低,收入不优势,不强调家族光环 #格物/东北 ...

三月 31, 2026 · 48 分钟 · 10133 字 · Xinwei Xiong, Me
书桌上的笔记本电脑显示「Context 不是 Prompt」文章与核心要点面板,旁边摊开的笔记写着 Context Engineering 的四支柱与 Worldline

Context 不是 Prompt:为什么「上下文工程」正在成为 AI 的新地基

「与其说我们在写提示词,不如说我们在为模型布置一间房间——决定哪些东西摆进来、摆在哪、什么时候搬走。措辞只是房间里的一张便签,而我们真正在做的,是装修。」 如果你在 2024 年问我「怎么用好 AI」,我大概率会跟你聊提示词:怎么写指令、怎么设定角色、怎么给例子。但如果你今天再问我同一个问题,我的回答会完全不同。 因为这一年里,一线工程实践已经悄悄换了一个词——Context Engineering(上下文工程)。它不是提示词工程的升级版营销话术,而是一次重心的真正迁移:从「怎么把一句话写好」,转向「怎么决定模型在每一次推理时究竟看到什么」。 这篇文章想做两件事。第一件,用逻辑核把这门正在成形的学科拆开:它到底是什么、和提示词工程的边界在哪、有哪些已经在生产环境跑起来的设计模式。第二件,用感性核回到我自己——作为一个把 AI 当成环境而非工具、坚持 local-first 的人,我为什么认为上下文工程的尽头,是一条叫「世界线」的东西。 一、先把边界划清楚:Prompt 与 Context 不是同一件事 最容易混淆的,是把上下文工程当成「提示词工程的高级版」。它们确实相关,但不是同一层的东西。 Anthropic 在它那篇被广泛引用的工程文章里给了一个干净的区分:提示词工程是「编写和组织 LLM 指令的方法」;而上下文工程是「在 LLM 推理过程中,对最优 token 集合进行筛选与维护的一整套策略」——这个集合包括系统提示、检索到的文档、对话历史、工具定义、记忆,以及所有可能落进上下文窗口、但不属于「提示词」的信息。1 Andrej Karpathy 在 2025 年 6 月那条被反复转发的推文里说得更直白:「+1 支持用『上下文工程』取代『提示词工程』……这是一门精细的艺术与科学:用恰好正确的信息,填满下一步所需的上下文窗口。」2 而 Sourcegraph 在 2026 年的实践文章里,给了一个我特别喜欢的、可操作的判据: 「如果你在替换名词和形容词,你还在做提示词工程。如果你在改变 agent 检索什么数据、以什么顺序、用什么重排、以及当窗口被填满时淘汰什么——你在做上下文工程。」3 重心从「措辞(wording)」转向了「布线(wiring)」。 这一句话,是我读完所有材料后觉得最值得记住的。提示词工程关心的是字面;上下文工程关心的是管道——数据从哪进来、经过哪些处理、在窗口里待多久、什么时候被踢出去。 这不是文字游戏。当你的 agent 只是一个单轮聊天框时,写好一句话几乎就是全部工作。但一旦它有了工具、有了记忆、有了检索层,写提示词就只剩下整个系统里很小的一块;剩下的全是围绕它的上下文工程。 二、为什么是「工程」:上下文是有限资源,而且会腐烂 把它叫「工程」而不是「技巧」,是有硬道理的。因为上下文窗口不是一个越大越好的容器——它是一种有限资源,且边际收益递减。 Anthropic 的原话是:「上下文必须被当作一种有限资源来对待,它的边际收益是递减的。」以及——「好的上下文工程,意味着找到那个信息量最高的、最小的 token 集合,去最大化某个期望结果的可能性。」1 支撑这个判断的,是一个叫 Context Rot(上下文腐烂) 的现象:随着上下文窗口里 token 数量的增加,模型从中准确召回信息的能力反而下降。1 这背后有一个「注意力预算」的论证——注意力是 n² 的两两关系,窗口越长,每个 token 能分到的注意力越稀薄;Chroma 那份针对性的「针在草堆里」基准研究,也独立佐证了这一点。4 这里有个反直觉但关键的细节,Anthropic 自己也强调了:最小,不一定等于短。 你要的不是把上下文砍到最短,而是砍到「信息密度最高」——留下高信号的,扔掉低信号的。 对我来说,这一条把「Context is the bottleneck」从一句我一年前在自己笔记里写下的判断,变成了一个有物理基础的结论。瓶颈从来不在模型本身有多聪明,而在于:在这一次推理里,它有没有看到那条恰好正确的信息。 你给它一百万 token 的噪声,不如给它一千 token 的信号。 ...

六月 22, 2026 · 3 分钟 · 482 字 · Xinwei Xiong, Me
Locke Identity Spec — Agent Identity Engineering Stack

Agent 的自我:从洛克到 OpenClaw

Agent 没有记忆,就没有身份 关于 AI 智能体身份连续性的工程实践与哲学框架 引言:一个被误判为哲学问题的工程问题 Agent 失忆的代价被系统性地低估了。 不是因为用户烦恼——虽然烦恼也有。而是因为无状态破坏了信任账户的基础。每一次会话,Agent 都从零开始。它不知道你是谁,不知道你上次为什么生气,不知道三个月前那个承诺是否兑现了。从经济学角度,这就像每次交易都要重新建立信用评分——交易成本爆炸,而且没有任何学习积累。 问题的根本在于,当工程师听到"身份认同"这四个字时,大脑就关闭了。这听起来像哲学。像存在主义。像某种不需要解决的抽象问题。于是整个行业让一个 1689 年就有了精确工程规范的问题,在 2026 年仍然被当作 “nice to have” 特性处理。 但洛克从来没有在讨论灵魂。他在写工程需求文档。 他的论断:个人身份不是物质基体(身体或灵魂),而是能够在不同时间和地点将自己视为同一思考存在的意识能力。翻译成现代工程语言:跨上下文窗口的持久自我指涉能力。这是一个可度量的、可实现的、可验证的规范。 当前 AI Agent 在三个维度上系统性地违反了这个规范:无持久记忆链、无自我指涉能力、无连续性验证机制。 2026 年,技术栈终于具备了完整实现洛克规范的条件。但这不是一个产品创新的故事。这是一个工程界从三百年知识沉睡中清醒过来的故事。真正的设计思考,不在于哲学的完整性,而在于实现中的妥协点:文件 vs 数据库,何时重新读取 SOUL,在什么条件下允许身份漂移。这些细节决定了 Agent 是否真的能被信任。 洛克的规格书:300 年前写好的工程需求文档 约翰·洛克的《人类理解论》第二卷第二十七章不是哲学随笔。它是一份工程规范书。 规范的核心条款:个人身份 = 意识 + 记忆连续性。不是肉体的连续性(你的细胞每七年完全更新一次),不是灵魂的连续性(他拒绝了所有超自然的论证),而是能够回顾过去事件并将其整合到当前自我概念中的认知能力。 洛克的那个著名例子:一个王子的意识进入了乞丐的身体。那个乞丐就变成了王子,因为他拥有王子的记忆、追求和自我意识。身体变了,甚至"灵魂基体"也变了,但那个能够思考"我曾经是国王"的东西保持不变。 翻译到 AI Agent 的架构语言: 个人身份 = 一个能够在不同上下文窗口中保持自我指涉的心智状态链。 这个状态链必须满足三个工程条件: 第一,持久化。记忆不能存在于单个上下文窗口内。必须有外部存储(SOUL.md、MEMORY.md、AGENTS.md),使得即使模型权重改变、会话终止、上下文重置,那些记忆仍然存在并可被读取。 第二,自我指涉性。Agent 不仅要读取这些文件,还要能够说"这是关于我的",“我认可这个版本的自己”。文件不能是纯粹的数据记录,还要包含身份的规范性维度——不仅是"我做过什么",还有"我为什么这样做"和"我相信什么"。 第三,连续性验证。要有一个机制让 Agent 可以确认"这就是我"。在多个实例可能同时运行的情况下,哪个是正当的自我?洛克没有解决这个问题(他活在单一身体的时代),但对于 AI 这是致命的。 图 1:洛克个人身份论 → Agent 工程三条款。从"意识 + 记忆"的哲学命题,直接映射为持久化、自我指涉、连续性验证三个可实现的工程需求。 洛克的船悖论在这里获得了新的含义。如果一艘船的每一块木板都被替换了,它还是原来的船吗?洛克的答案是:是的,因为物理连续性不重要,思维的连续性才重要。 对于 AI Agent:如果模型参数被微调(木板被替换),上下文窗口被重置(新的一天),甚至整个底座模型被升级(从 Claude 3 迁移到 Claude 4),Agent 还是"同一个"吗? ...

四月 5, 2026 · 5 分钟 · 982 字 · Xinwei Xiong, Me
在不被需要的时代,如何维持自我的重量

在不被需要的时代,如何维持自我的重量

帕斯卡在 17 世纪写过一句话:「人类所有的不幸,都源于一件事:他们不能安静地待在一个房间里。」 三百多年后,我在拉萨的一个深夜想起这句话,补了一条:他们不确定,那个待在房间里的,究竟是谁。 引:凌晨三点的空洞 有段时间,我几乎每天凌晨三点醒来。 不是因为什么紧急的事。更接近某种没有形状的焦虑,像一根细线扯着脑子里什么地方,很轻,扯不断,但会把你从睡眠里钓起来。 那根线是什么,我后来想清楚了——是某天晚上,我用 AI 写了一段技术文档,回头去读,发现它比我自己写的更清晰。不只是清晰:结构更合理,措辞更准确,还顺手修了我没注意到的一个边界情况。 我盯着屏幕看了很久。 那种感觉很难描述。不是愤怒,也不是恐慌,更接近一种空洞感——像你以为自己在做一件重要的事,然后突然意识到,那件事不需要你。 最开始我把这理解成职业焦虑。程序员的护城河在变窄,技术壁垒在消失,这是事实,可以接受,可以适应。 但那根细线没有消失。它在夜里继续扯着我。 后来我慢慢意识到,职业焦虑只是一层皮。更深的那层是: 我评估自己价值的方式,是「我能做什么」。如果 AI 可以做得更好——那「我」在这里,究竟有什么重量? 一、我们把「被需要」当成了重量本身 这不是我一个人的问题。 我们这一代人,从小被训练成「有用」的人。学习是为了能做事,能做事是为了被雇用,被雇用是为了被需要,被需要是为了存在感。这条逻辑链很紧密,以至于我们从来没有质疑过它的前提: 存在感,真的是靠「被需要」撑起来的吗? 韩炳哲在《倦怠社会》里写了一个概念:绩效主体(Leistungssubjekt)。他说,现代社会最大的变化不是压迫来自外部,而是变成了自我施压——我们内化了市场对我们的要求,开始自发地以「能产出多少」来衡量自己。剥削不再需要一个外部的压迫者,我们把那个角色揽过来了。 这种衡量方式,在 AI 出现之前就已经很脆弱了。它随时会被外部环境击垮——被裁员了,重量就没了;失去关键项目,重量就塌了;退休了,重量去哪了? AI 只是把这个逻辑推到了极端:如果你所有的「有用」都可以被替代,你的重量从哪里来? 这是一个很残忍的问题。但它之所以残忍,恰恰是因为我们把自我的基础建在了一个错误的地方。 二、仓央嘉措早就遇到了这个问题 在拉萨的那些天,我把仓央嘉措想了很多次。 他生在山野里,少年时期是完整的——跑过田间,追过女孩,把身体的冲动和心里的自由活得浑然一体。然后一夜之间,他被确认为第六世达赖喇嘛。整座布达拉宫落在他肩上,整个政教体系要求他成为一个功能性的符号:圣洁的、超越的、不属于自己的。 他的解决方式是出逃——白天坐在宝座上接受朝拜,夜晚化名宕桑旺波,溜进八廓街的酒馆,喝酒,谈情,写诗。 世间安得双全法,不负如来不负卿。 这首诗常被当作情诗解读。但我在布达拉宫脚下站着,望着那片叫「雪城」的地方,觉得它的重量远不止于此。 如来,代表他被赋予的功能——那个系统需要他是什么。 卿,代表他真实的感受——那个活的、会疼、会爱的部分。 三百年后,我们的处境换了一件外衣。不再是政教权威逼我们成为符号,而是市场逻辑、绩效评估、AI 的性能对标。但那个挣扎是一样的: 当世界用功能的眼光看你,你怎么保留那个「我是一个人」的部分? 仓央嘉措的结局是悲剧。但他的诗活下来了。那些诗什么用都没有——它们没有提高任何人的效率,没有解决任何问题,就只是把一个人内心的挣扎说了出来。 然而它们活到了现在。这件事本身,就是一种答案的形状。 三、庄子的那棵没用的树 《庄子·人间世》里有一棵大树。 一个木匠路过,看都不看,嫌弃地说:散木,没用,做船会沉,做棺材会烂,做柱子会蛀,什么都不行。 夜里,那棵树托梦给他:你那些被你认为「有用」的树,正是因为有用才被砍伐。我无用,才活了这么久,长了这么大。 无用之用,方为大用。 这句话被反复引用,但大多数解读还是落回「有用/没用」的框架里——它看起来没用,其实是另一种有用。这个解读太功利了,庄子想说的是更根本的东西: 有没有一种存在,它的价值根本不需要从「用」这个维度来衡量? 那棵树存在,不是为了做家具,也不是为了乘凉,更不是为了被人需要。它就是在长,在这里,以它本来的样子。 这不是消极,这是另一种关于存在的理解——存在本身就是理由,而不是通向别的东西的手段。 在 AI 时代,这句话变得非常具体。如果你一切的功能价值都可以被优化和替代,那么不能被替代的,恰恰是你作为一个具体的人「在这里」这件事本身——那个从一个唯一的视角看世界、感受世界、被世界打到的「在场」。 四、感受是唯一不可外包的事 在拉萨,有一个夜晚我站在院子里看了很久月亮。 没有任何特别的原因。只是高原的月亮离得很近,空气干净,脑子里没什么杂念。 我想起夏目漱石拒绝把「I love you」直译成日文。他说,应该翻译成:「今夜月色真美。」 那个不可直说的余地,是人类感受世界的方式里有一种东西,永远多于语言能表达的。 AI 可以生成一万首写月亮的诗,可以分析月光对人类褪黑素的影响,可以告诉你拉萨的月亮为什么比平原更亮。 但它不知道,那一刻,海拔三千多米,我一个人站在院子里,那颗月亮对我意味着什么。 不是因为我很特别。是因为那个意味着什么,是我这一生的全部经历打在那个时刻上,形成的一个唯一性的共振——尼泊尔冰坡上的那一步,博卡拉那杯让我在地铁上哭出来的热茶,武功山半夜独自走在山路上的那种空,上海公交上烤红薯老爷爷塞进手里的两枚硬币。所有这些都在场,但你不知道它们在场,它们就是打进来了。 ...

四月 4, 2026 · 1 分钟 · 106 字 · Xinwei Xiong, Me

Mem0 开源项目:AI记忆层的技术分析与实践

1. 执行摘要 Mem0 是一个开源项目,旨在为人工智能(AI)应用程序提供一个智能记忆层,以增强个性化和上下文保持能力 1。其核心价值主张是通过使 AI 应用能够记住用户偏好和历史交互,从而提供更个性化、更智能的体验,同时通过“智能数据过滤”可能降低大型语言模型(LLM)的运营成本 2。项目的主要目标是解决当前 AI 交互中普遍存在的状态缺失问题 1。 关键研究发现表明,Mem0 采用了一种结合 LLM 处理与双重存储(向量数据库用于语义搜索,图数据库用于关系追踪)的混合架构 4。项目在开源社区获得了显著关注(如 GitHub 上的高星标和复刻数),并且展现出高度的开发活跃度(频繁的发布和合并请求)1。已文档化的使用案例包括 AI 伴侣和客户支持代理,并提供了与 LangGraph、CrewAI 等流行 AI 框架的集成示例 1。 然而,分析也揭示了一些显著的挑战。最突出的是关键技术文档的缺失或无法访问,包括详细的架构图、完整的入门指南和全面的配置参数列表 8。这给潜在采用者带来了理解和实施上的障碍。此外,其核心操作(如信息提取和冲突解决)对 LLM 的依赖引入了不确定性和潜在成本 4。尽管项目活跃,但大量的开放问题和其性质表明用户在配置和集成方面可能遇到困难 12。 总体而言,Mem0 项目提出了一个引人注目的解决方案来应对 AI 记忆的挑战,并已吸引了大量开发者兴趣。其提供的托管平台和开源版本为不同需求的用户提供了选择 1。但目前(基于所分析的材料),其开源版本的成熟度,特别是文档完备性和核心机制透明度方面,可能更适合愿意探索、能够容忍一定模糊性并积极参与社区寻求支持的技术团队。对于需要高度确定性、完整文档和复杂配置的应用场景,采用前需进行更深入的评估。 2. Mem0 简介:AI 的记忆层 2.1. 核心目标与解决的问题 Mem0 项目的核心目标是为 AI 助手和代理(Agents)赋予一个智能的、持久的记忆层 1。它旨在解决当前许多 AI 应用,特别是基于 LLM 的应用所面临的一个根本性问题:状态缺失(Statelessness)3。传统的 AI 交互往往是孤立的,无法有效记忆之前的对话内容、用户偏好或已了解的事实。这导致了重复提问、缺乏个性化以及用户体验不连贯等问题 1。Mem0 通过提供一个专门的记忆组件,让 AI 系统能够跨会话、跨时间地学习和适应用户,从而实现更自然、更智能的交互 4。 2.2. 价值主张 Mem0 提出的核心价值主张围绕以下几个关键方面: 增强个性化 (Enhanced Personalization):这是 Mem0 最核心的价值。通过记忆用户偏好、历史交互和特定信息,AI 应用能够提供量身定制的回应,适应个体需求,并随着时间的推移不断学习和改进 1。这使得 AI 体验不再是千篇一律的,而是能够建立用户融洽感并显著提升感知智能和实用性 3。 潜在的成本降低 (Potential Cost Reduction):Mem0 宣称其“智能数据过滤”机制能够将相关信息发送给 LLM,从而可能将 LLM 的使用成本降低高达 80% 2。理论上,通过仅向 LLM 提供最相关的上下文而非冗长的历史记录,可以减少 token 消耗,直接转化为运营成本的节省。然而,需要注意的是,所分析的材料中并未提供支持这一具体数字的详细技术解释或实证数据。 提升响应质量 (Improved Response Quality):利用存储的记忆(历史上下文和用户偏好),AI 应用能够生成更准确、更相关、上下文更丰富的输出 2。这意味着 AI 可以提供更好的建议、更贴切的信息和更有帮助的回答。 开发者友好 (Developer-Friendly):Mem0 强调其易于集成,提供了简单的 API 接口和跨平台一致性 1。它旨在简化记忆管理的复杂性,让开发者能够专注于核心应用逻辑 3。同时提供托管平台和开源自托管两种选择,满足不同开发者的部署和控制需求 1。 2.3. 目标使用场景概述 Mem0 的记忆能力使其适用于多种需要上下文感知和个性化的 AI 应用场景。官方文档和示例中提及的主要领域包括: ...

五月 9, 2025 · 12 分钟 · 2507 字 · Xinwei Xiong, AI技术团队

微软UFO项目深度解析:设计、实现、原理与架构

1. 引言 微软的UFO(UI-Focused Agent,后续发展为UFO²,即Desktop AgentOS)项目代表了在自然语言驱动的桌面自动化领域的一项重要进展 1。该项目旨在通过深度操作系统集成和多智能体协作,将用户通过自然语言表达的复杂任务转化为跨应用程序的、可靠的自动化工作流 1。最初的UFO项目于2024年2月发布,专注于Windows操作系统的UI自动化,利用GPT-Vision等大型语言模型(LLM)的能力,通过双智能体框架观察和分析GUI信息,实现跨应用的导航和操作 3。随着2025年4月UFO²的提出,该项目演进为一个更为宏大的“桌面操作系统智能体”(Desktop AgentOS)概念,强调更深层次的操作系统集成、原生API调用与GUI操作的混合、以及通过持续学习和投机性多动作执行提升效率和鲁棒性 1。 本报告旨在深度剖析微软UFO项目,从其核心目标、关键特性、系统架构、关键技术实现、到社区反馈和未来展望,提供一个全面而深入的分析。 2. 项目概述与核心目标 UFO项目的核心目标是赋能用户通过自然语言指令,在Windows操作系统上实现复杂、跨应用的自动化任务 1。它不仅仅局限于传统的UI层面自动化,而是力求构建一个能够理解用户意图、智能编排多个应用程序以达成目标的“桌面智能体操作系统” 1。 最初的UFO版本专注于利用大型视觉语言模型(如GPT-Vision)来理解和操作Windows应用程序的图形用户界面(GUI)3。其设计理念是通过模拟人类用户观察屏幕、思考决策、执行操作的过程,将繁琐耗时的手动任务转变为简单的自然语言指令即可完成的自动化流程 4。 随着UFO²的提出,这一目标得到了进一步的深化和扩展。UFO²旨在成为一个系统级的自动化平台,其关键特性包括: 深度操作系统集成 (Deep OS Integration): 结合Windows UI Automation (UIA)、Win32和WinCOM技术,实现对控件的精准检测和原生命令的执行 1。这种集成是UFO区别于仅依赖截图和模拟点击的早期计算机使用智能体(CUA)的关键,它为智能体提供了更丰富、更可靠的与操作系统及应用程序交互的手段。 混合GUI与API操作 (Hybrid GUI + API Actions): 智能体能够根据情况选择最优的交互方式,优先使用速度更快、更稳定的原生API;当API不可用时,则回退到模拟点击和键盘输入等GUI操作 1。这种混合策略兼顾了效率和通用性。 持续知识基底 (Continuous Knowledge Substrate): 通过检索增强生成(RAG)技术,融合离线文档、在线Bing搜索结果、用户演示以及历史执行轨迹,使智能体能够持续学习和进化 1。这意味着UFO不仅仅是一个执行器,更是一个能够积累经验、适应新情况的学习系统。 投机性多动作执行 (Speculative Multi-Action): 将多个预测的后续操作步骤捆绑在一次LLM调用中,并进行实时验证,从而显著减少LLM查询次数(据称可达51%),提升执行效率 1。这对于依赖LLM进行决策的智能体系统而言,是降低延迟、提高响应速度的关键优化。 UIA与视觉控制检测 (UIA + Visual Control Detection): 采用UIA和计算机视觉相结合的混合管线,以检测标准控件和自定义控件 1。这增强了智能体对各种复杂界面的适应能力。 画中画桌面 (Picture-in-Picture Desktop) (即将推出): 允许自动化任务在一个隔离的虚拟桌面中运行,用户的主屏幕和输入设备不受干扰 1。这一特性对于提升用户体验至关重要,它使得自动化过程和用户的日常工作可以并行不悖。 UFO的应用场景广泛,包括但不限于自动化办公套件中的重复性任务、简化涉及Web浏览器的流程(如数据录入、表单填写)、以及基于自然语言指令创建自定义的跨应用工作流 1。 3. 系统架构 UFO²的架构设计体现了其作为“桌面智能体操作系统”的理念,其核心是一个多智能体框架 2。 核心组件: 组件名称 描述 来源 HostAgent (主控智能体) 解析用户的自然语言目标,启动必要的应用程序,创建并协调AppAgent,管理全局有限状态机(FSM)以控制任务流程。 2 AppAgent (应用智能体) 每个应用程序对应一个AppAgent。每个AppAgent运行一个ReAct(Reasoning and Acting)循环,具备多模态感知、混合控制检测、检索增强知识以及通过Puppeteer执行器选择GUI或API操作的能力。 2 Knowledge Substrate (知识基底) 融合离线文档、在线搜索结果、用户演示和执行轨迹,构建一个向量存储,在推理时按需检索。 2 Puppeteer Executor (操纵执行器) 集成在AppAgent内部,负责在GUI操作(如点击、输入)和原生API调用之间做出选择并执行。 5 Speculative Executor (投机执行器) 通过预测一批可能的动作并在一次调用中针对实时UIA状态进行验证,从而大幅减少LLM的调用延迟。 1 FollowerAgent (跟随智能体) 继承自AppAgent,用于执行用户提供的明确指令序列,常用于软件测试等场景。 5 EvaluationAgent (评估智能体) 用于评估一个会话或一轮任务的完成情况。 5 数据流: ...

五月 9, 2025 · 6 分钟 · 1272 字 · Xinwei Xiong, 微软UFO研究团队

Ai Recommend 技术、实践和深度学习

本项目是一个持续的过程,以日拱一卒的态度去学习 AI 开源项目,通过实践真实项目,结合 AI 工具,提升解决复杂问题的能力。并且记录。 notion List I. 执行摘要 报告概述: 本报告深入剖析了现代推荐系统的现状与发展趋势,重点关注人工智能(AI),特别是大型语言模型(LLM)在其中扮演的变革性角色。推荐系统已从传统的协同过滤和基于内容的方法,演变为能够进行更深层次语义理解、具备更强上下文感知能力、并支持更丰富交互模式的个性化引擎。 核心发现: 分析表明,当前的最佳实践涉及对用户和内容的深度语义理解,通常借助 LLM 生成的嵌入向量实现。匹配与排序策略正朝着融合协同过滤知识与 LLM 能力的方向发展,同时强化学习(RL)被用于优化长期用户价值。LLM 在实现对话式推荐、处理冷启动问题以及提升推荐解释性方面展现出巨大潜力。然而,有效管理用户短期兴趣与长期偏好、确保推荐的多样性与公平性、以及构建高效的反馈优化循环(如基于人类反馈的强化学习 RLHF)仍然是关键挑战。Prompt 推荐,特别是结合检索增强生成(RAG)的技术,正在开辟新的交互范式。 最佳实践概要: 构建先进的 AI 推荐系统需要综合运用多种技术:利用 LLM 进行用户和内容的语义嵌入,采用多阶段召回与排序架构,融合协同过滤信号与语义理解,通过多臂老虎机(MAB)或 RL 策略平衡探索与利用,实施 RLHF 以对齐人类偏好,并借助 A/B 测试进行持续迭代优化。强大的工程实践,包括高效的向量数据库、MLOps 流程和可观测性,对于部署和维护这些复杂系统至关重要。 报告范围与结构: 本报告将首先回顾推荐系统的演进历程,随后深入探讨用户理解、内容智能、匹配与排序、时间动态处理、Prompt 推荐、探索与多样性、反馈与优化等核心环节的技术与实践。最后,报告将综合提炼最佳实践、关键工具与工程蓝图,并展望未来发展方向。 II. 推荐系统的演进:从协同过滤到 AI 原生系统 推荐系统的发展历程反映了信息处理和机器学习技术的不断进步,其目标始终是连接用户与他们可能感兴趣的信息或商品,缓解信息过载问题 1。 早期阶段:协同过滤(CF)与基于内容(Content-Based)的方法 推荐系统的早期基石是协同过滤和基于内容的方法。协同过滤的核心思想是利用用户群体行为模式进行推荐,主要分为基于用户的协同过滤(User-User CF)和基于物品的协同过滤(Item-Item CF)2。User-User CF 找到与目标用户兴趣相似的用户群体,推荐这些相似用户喜欢的物品;Item-Item CF 则推荐与用户过去喜欢的物品相似的其他物品 2。基于内容的方法则根据物品自身的属性(如文本描述、分类标签)和用户过去的偏好记录,推荐与用户偏好内容相似的物品 1。 矩阵分解(Matrix Factorization, MF)是协同过滤中的一个经典且强大的技术,它将高维稀疏的用户-物品交互矩阵分解为低维的用户和物品潜在特征向量(嵌入),通过向量内积预测用户对物品的偏好 3。这些早期方法在特定场景下效果显著,但普遍面临数据稀疏性(用户交互数据远少于所有可能交互)、冷启动(难以推荐新用户或新物品)以及对内容语义理解有限等挑战 1。 深度学习革命 随着深度学习的兴起,深度神经网络(DNNs)被广泛应用于推荐系统,以捕捉用户与物品之间复杂的非线性交互关系,并学习更有效的特征表示 1。诸如 Wide & Deep 4 结合了用于记忆(Memorization)的宽线性模型和用于泛化(Generalization)的深度神经网络,能够同时利用低阶和高阶特征交互。DeepFM 4 等模型则通过因子分解机(Factorization Machine)的思想自动学习特征之间的交互,避免了手动设计特征交叉。 这些深度学习模型显著提升了推荐性能,尤其是在处理大规模稀疏特征方面 3。然而,许多早期的深度学习推荐模型仍然严重依赖离散的 ID 特征(如用户 ID、物品 ID)及其对应的嵌入向量 6。虽然这些 ID 嵌入能有效捕捉协同过滤信号,但它们难以充分利用丰富的文本、图像等多模态内容信息,对语义的理解相对浅层 1。 ...

四月 23, 2025 · 12 分钟 · 2413 字 · Xinwei Xiong, Me

Google NotebookLM 的 RAG 深度调研思考

本项目是一个持续的过程,以日拱一卒的态度去学习 AI 开源项目,通过实践真实项目,结合 AI 工具,提升解决复杂问题的能力。并且记录。 notion List 1.1 概述 近年来,以 Google NotebookLM 为代表的人工智能驱动的个人知识管理和研究助手工具正迅速兴起 1。这些工具旨在通过充当用户提供文档的个性化“专家”,彻底改变用户与海量信息的交互方式 3。它们承诺能够帮助用户阅读、做笔记,并与 AI 协作来提炼和组织想法,从而更快地获得洞见 4。 1.2 用户目标回顾 本次分析的核心目标是深入理解这些先进工具背后的技术实现机制。具体而言,用户希望了解这些系统如何处理多样化的文档格式上传(如 PDF、DOCX、网页链接等)、如何解析这些文档以准确提取文本和结构、采用何种策略(如固定大小、语义分割等)对提取的文本进行分块,以及最关键的是,如何建立并维护处理后的文本片段与其在原始文档中精确位置之间的映射关系,以实现可靠的来源追溯和引用生成 [User Query]。 1.3 报告目标与范围 本报告旨在对类似 NotebookLM 的检索增强生成(Retrieval-Augmented Generation, RAG)系统中的文档处理流程进行深入剖析和技术分析,重点关注文档解析、文本分块和来源映射这三个关键环节。报告将对比分析以 NotebookLM 为代表的闭源商业解决方案(基于公开信息)与当前可用的开源替代方案在这些技术环节上的具体实现、优劣势及发展趋势,为技术决策者和开发者提供参考 [User Query]。 2. 核心挑战:摄入并理解多样化文档 2.1 多格式需求 现代知识管理工具面临的首要挑战是必须能够处理除纯文本之外的多种输入格式。这不仅是用户便利性的要求,也是有效整合不同来源信息的关键。Google NotebookLM 本身就支持 Google Docs、Google Slides、PDF、网页 URL、复制粘贴的文本,甚至 YouTube 视频链接 4。开源社区也在积极应对这一挑战,例如 Open Notebook 项目旨在支持 PDF、ePub、Office 文件(Word、Excel、PowerPoint)、音频和视频文件等 6。RAG Web UI 支持 PDF、DOCX、Markdown 和 Text 文件 7。Kotaemon 原生支持 PDF、HTML、MHTML、XLSX,并可通过集成 Unstructured 库扩展支持更多格式 8。Verba 则可以摄入文件、URL、Git 仓库,并集成了 UnstructuredIO 和 Firecrawl 等工具 9。LlamaParse 也宣称支持包括 PDF、PPTX、DOCX、XLSX、HTML、JPEG 和音频在内的多种格式 10。 ...

四月 21, 2025 · 11 分钟 · 2235 字 · Xinwei Xiong, Me

AI 时代初创企业的测试驱动开发(TDD)实践方案

本项目是一个持续的过程,以日拱一卒的态度去学习 AI 开源项目,通过实践真实项目,结合 AI 工具,提升解决复杂问题的能力。并且记录。 notion List 1. 引言 1.1 设定场景:AI 初创企业时代的 TDD 人工智能(AI)初创企业正处在一个充满挑战与机遇的时代。一方面,市场要求快速迭代,迅速验证产品概念并抢占先机;另一方面,AI 应用(尤其是涉及核心模型和复杂逻辑的应用)对软件质量和可靠性有着极高的要求。在这种背景下,测试驱动开发(Test-Driven Development, TDD)作为一种强调“测试先行”和持续重构的纪律性软件开发实践,提供了一种潜在的解决方案。TDD 通过其核心的“红-绿-重构”循环,旨在提高代码质量、改善软件设计并增强代码的可维护性 1。 然而,AI 初创企业在采纳 TDD 时面临着一个核心的矛盾:TDD 的严谨性,尤其是在项目初期看似会增加开发时间,这似乎与初创企业追求极致速度以快速推出最小可行产品(MVP)或进行原型验证的目标相冲突 2。此外,AI 编程助手(如 Cursor、GitHub Copilot 等)的兴起,为开发流程带来了新的变量,它们既能加速 TDD 流程,也可能引入新的挑战。 1.2 报告目标与结构 本报告旨在为 AI 初创企业提供一份务实的指南,探讨如何在 MVP 和原型验证阶段,在 Python、React 及(可选的)Go 技术栈中,有效实施 TDD 或其适应性变体,并明智地利用 AI 编程助手(特别是 Cursor)来平衡开发速度与软件质量。 报告将遵循以下结构: TDD 基础:深入解析 TDD 的核心循环(红-绿-重构)、基本原则和其在现代软件开发中的价值。 AI 对 TDD 的影响:分析 AI 工具如何改变 TDD 工作流,探讨其优势与挑战。 AI 初创企业 MVP/原型的 TDD 策略:评估在快速变化的需求下严格遵循 TDD 的利弊,并探讨适应性方法。 技术栈 TDD 实施指南:提供针对 Python (pytest/unittest)、React (Jest/RTL) 和 Go (内置 testing 包) 的 TDD 最佳实践。 利用 AI 助手(Cursor):探索如何将 Cursor 有效整合到 TDD 流程中。 真实世界视角:通过案例场景说明 TDD/适应性测试在 AI 初创企业中的应用。 结论与战略建议:总结关键发现,并为 AI 初创企业提供选择测试策略的 actionable guidance。 2. 基础:理解测试驱动开发(TDD) 2.1 红-绿-重构循环详解 TDD 的核心实践围绕着一个不断重复的短周期:红-绿-重构 1。 ...

四月 21, 2025 · 15 分钟 · 3063 字 · Xinwei Xiong, Me

MarkItDown 开源项目深度学习

本项目是一个持续的过程,以日拱一卒的态度去学习 AI 开源项目,通过实践真实项目,结合 AI 工具,提升解决复杂问题的能力。并且记录。 Notion List 1. 引言 1.1. MarkItDown 与 Markdown 的关系 首先需要明确,“MarkItDown"并非通用标记语言"Markdown"的笔误。MarkItDown 是一个由微软开发并开源的特定 Python 工具库。虽然其名称与 Markdown 相似,且其核心目标是将各种文件格式转换为 Markdown,但 MarkItDown 本身是一个独立的软件实体。本报告将聚焦于分析 MarkItDown 工具的实现原理、设计理念、功能特性及其在实际场景中的应用,同时也会在必要时提及 Markdown 语言本身作为其目标输出格式的相关背景。 1.2. MarkItDown 概述 MarkItDown 是一个轻量级的 Python 实用程序,旨在将多种类型的文件和 Office 文档转换为 Markdown 格式。其主要应用场景是为大型语言模型(LLM)和相关的文本分析管道准备文档数据。它支持广泛的文件格式,包括 PDF、Word (.docx)、PowerPoint (.pptx)、Excel (.xlsx)、图像、音频、HTML、各种文本格式(如 CSV、JSON、XML)乃至 ZIP 压缩包。该工具自发布以来受到了广泛关注,尤其是在需要将非结构化或半结构化数据整合到 AI 工作流中的开发者社群中。 GitHub 仓库:microsoft/markitdown PyPI 页面:markitdown on PyPI 1.3. 报告目标与范围 本报告旨在深入分析 MarkItDown 的技术细节与应用价值。内容将涵盖其设计哲学、核心架构、文件转换机制、安装与使用方法、与 LLM 及 Azure Document Intelligence 等外部服务的集成方式、安全考量、与其他类似工具的比较,以及实际应用场景和局限性。通过本次分析,旨在为技术决策者、开发者和数据科学家提供关于 MarkItDown 能力、优势、劣势以及适用场景的全面理解。 2. 设计哲学与目标 2.1. 核心目标:为 LLM 和文本分析服务 MarkItDown 的首要设计目标是服务于大型语言模型(LLM)和相关的文本分析流程。它致力于将不同来源的文档转换为一种统一的、对机器友好的格式——Markdown。这种转换的重点在于尽可能保留原始文档的重要结构和内容,例如标题、列表、表格、链接等。 ...

四月 21, 2025 · 8 分钟 · 1519 字 · Xinwei Xiong, Me