LLM

先给答案：信任是证据，不是平台技巧 一页内容可以技术健康、结构清楚、方便引用，却仍然没有被答案引擎展示为来源。这不证明背后有一道神秘“信任闸门”拒绝了它。页面可能根本没被选中，另一份来源可能更贴合问题，答案可能吸收了它的事实却没有给链接，也可能只是平台在这一次运行里表现不同。 ...

先给答案：不存在一套通吃所有平台的引用算法 AI 搜索没有公开一条所有产品共用的流水线，更不存在一份可以反向破解成公式的 GEO 秘籍。 Google 明确说 AI Overviews 与 AI Mode 会使用检索增强生成和查询扇出；Perplexity 公开的是实时搜索、综合与来源链接；OpenAI 说明 ChatGPT search 会使用第三方搜索服务和合作伙伴直接提供的内容。这些事实都不能推出它们共享同一个索引、切块器、关键词检索器、向量库、重排器、上下文拼装方式或引用策略。 ...

先给短答案 生成式引擎优化（GEO）是一个工作标签：当 AI 辅助搜索生成答案时，让内容具备被访问、被理解、被选择和被正确归因的条件。它不是一个统一的排名算法，也不是一套特殊标记技巧。 ...

open-lovable 看起来像一句很短的产品承诺：给它一个网址，得到一个可继续修改的 React 应用。真正值得读的却不是生成结果，而是它怎样把抓取、模型输出和不可信代码执行接成一条可控链路。 ...

架构图是一张承诺清单；源码审计要问的是，其中哪些箭头已经有了重量。 这篇文章的旧版把 Relay 写成一个公开的开源方案，还说它的 Agent 层尚未开工。到 2026 年 7 月 31 日，这两个判断都不再成立：旧文引用的公开 GitHub 地址返回 404，而我能够核对的是一份私有本地检出。 ...

上下文工程（Context Engineering）是在 LLM 每一次推理时，对进入上下文窗口的最优 token 集合——系统提示、检索文档、对话历史、工具定义与记忆——进行筛选、排序与淘汰的一整套工程策略。 它与提示词工程的区别一句话讲清：提示词工程优化「一句话的措辞」，上下文工程优化「整扇窗口的布线」。这个定义来自 Anthropic 的工程文章，Karpathy 也公开背书了这次改名。下文把这门正在成形的学科完整拆开。 ...

「Agent loop 是 10 行代码，Agent engineering 是 10 万行代码。」 这句话不是代码审计结论，更像一把拆系统的刀。它戳破了一个常见错觉：把 prompt 写好、把 LLM API 调通，只能证明 loop 能转；要让系统在无人值守时仍可恢复、可追踪、可约束，主要工作在 loop 外。 ...

关于 AI 智能体身份连续性的哲学边界与工程实践 引言：先把“身份”降到工程可讨论的尺度 Agent 失忆，最先伤害的不是拟人感，而是合作成本。 一次会话里表现出色，并不等于下次还能沿用同一套判断。用户要重新说明偏好，团队要重新交代约束，系统也很难解释某个决定从哪里来。长期合作所依赖的信任，恰好建立在这些看似琐碎的连续性上：它记得什么，忘掉什么，为什么改变，以及谁批准了改变。 ...

这篇笔记来自我对开源 AI 系统的长期拆解：先跑起来，再读迁移文档，最后记录抽象在哪些地方成立，又在哪些地方开始漏水。 问题从来不是“记得越多越好” 只要对话还装得进上下文窗口，LLM 就能维持短暂的连续感。但这不是长期记忆，更不是可靠的应用状态。会话结束之后，模型不会自然记住用户偏好简短回答、上个月换了工作，或者已经放弃某个计划。 ...

推荐系统最容易制造一种错觉：模型越新，系统就越先进。 真正做过推荐的人会知道，模型只是水面上的一小部分。水面之下还有曝光偏差、延迟预算、特征新鲜度、库存约束、探索风险和反事实评估。大语言模型（LLM）确实给推荐系统增加了新的语义入口，却没有替我们消除这些旧问题。它甚至会带来新的麻烦：成本更高、输出不稳定、解释可能看似合理却与排序依据无关。 ...

2026 年 7 月 16 日，Google 正式把 NotebookLM 更名为 Gemini Notebook。 名字变了，最值得保留的问题没有变： 我能不能沿着一段答案，走回一份自己愿意相信的证据？ 这才是 Gemini Notebook 与普通聊天工具真正不同的地方。普通对话从一个宽广模型出发，靠提示词收窄范围；Gemini Notebook 先让你圈定来源，再围绕这些来源提问、比较和生成结果。它最有价值的不是“更会写”，而是缩短了生成主张到检查原文之间的距离。 ...

当被测函数只是把两个数字相加时，测试驱动开发很好解释：先写一个失败测试，让它通过，再在行为不变的前提下改善实现。困难出现在函数开始调用大模型之后——同一个问题可能有五种都算正确的回答，今天通过的结果，明天也可能因为模型、检索索引或服务端推理环境变化而不同。 ...

文档转换器是一座桥，不是真相本身。真正重要的不是输出第一眼是否整洁，而是下一套系统需要的证据有没有过桥。 MarkItDown 的演示很简单：装一个包，传入文件，得到 Markdown。困难往往从下一分钟开始。一个 PDF 可能同时包含可选文字、扫描页、图表和复杂表格；一份演示文稿的关键数字可能藏在截图里；一个工作簿的含义可能依赖公式、合并单元格与空间关系。它们虽然都叫“文档”，却不该走同一条转换路径。 ...

这个项目是一场持续的开源学习：每天向前一点，用真实项目训练解决复杂问题的能力，也把判断变化的过程留下来。 项目学习清单 ...

过去介绍 LangChain，常会列出 Chain、Memory、Prompt、Loader 和各种集成。那段历史没有错，却已经不适合指导今天的项目。 ...

AI Gateway 不是“给大模型套一层反向代理”这么简单。真正进入生产以后，模型调用同时带着长连接、流式响应、令牌计费、供应商限额、敏感数据和不可预测的输出。普通 API 网关能处理其中一部分，却很难独自回答三个问题： ...

第一次认识 Jina 时，我把它理解成“用 Flow 编排神经搜索服务的 Python 框架”。这个理解没有错，只是停在了旧地图上。 2025 年 10 月 9 日，Elastic 宣布与 Jina AI 合并力量，随后完成收购。Jina 创始人肖涵加入 Elastic 担任 AI 副总裁，模型继续通过 Hugging Face 提供，并逐步进入 Elastic Inference Service。到 2026 年再谈 Jina，更准确的起点已经不是一个通用 MLOps 框架，而是一个面向检索的 Search Foundation Models（搜索底座模型）品牌：它提供嵌入、重排、网页读取、文本切分、分类和深度搜索等能力。Elastic 的收购公告 把方向说得很明确——把多语言、多模态检索能力放到 Elasticsearch 的搜索规模与生态中。 ...

一个框架最危险的时刻，不是它没有能力，而是旧教程仍然看起来能够运行。代码一旦跨过版本边界，熟悉感往往比报错更会误导人。 这篇文章只讨论 LangChain Python 1.x 的当前主线：模型、Agent、工具、结构化输出、中间件、记忆、RAG、SQL、Ollama 与 LangSmith。它不再复述 LangChain 的项目历史，也不把几十种组件罗列成字典；目标是让你拿到一条短而完整的工程路径。 ...

引言：不要从聊天窗口理解大模型 第一次使用大语言模型，很容易产生一种错觉：屏幕另一端似乎住着一个读过许多书、能够推理也愿意解释的人。它会写代码，会概括论文，会在同一段对话里保持语气，甚至会为自己的错误给出一套听起来完整的理由。 ...

这篇文章最初写于 2024 年 1 月的一场大语言模型分享会。那时，行业的问题还是“模型能做什么”；两年后，更重要的问题变成了“系统凭什么值得相信”。 我没有把旧笔记涂成一篇仿佛从未犯错的新文章。时间留下的误判也有价值：它提醒我们，技术判断不是预言，而是带着证据期限的下注。以下每节都保留 2024 年的观察，并用 仍成立 / 已变化 / 当时误判 做 2026 年校准。 ...

状态说明（核验于 2026 年 7 月 31 日）： 本文最初是一篇 2023 年的 Auto-GPT 本地安装教程。那些命令已经过时。官方现在明确说明：AutoGPT Classic 已停止支持，依赖不会再更新，并且存在已知安全问题。它适合研究历史，不适合生产使用。新项目应从仍在维护的 AutoGPT Platform，或其他活跃的工作流系统开始。 ...