LLM

输入一个网址，AI 在几秒内把它重建成一个能跑、能预览、能继续对话修改的现代 React 应用。 这是 firecrawl/open-lovable 给人的第一眼印象——27k star、5.2k fork，TypeScript 占比 94.9%，是 Firecrawl 团队做的一个旗舰开源示例。它对标商业产品 Lovable.dev（README 里直接写明「完整云方案请用 Lovable.dev」），处在 Lovable、Bolt.new、v0、Replit Agent 这条极其拥挤的「AI 应用生成器」赛道里。 但我想拆的不是「它能生成代码」这件事——那已经不稀奇了。我真正感兴趣的是它的工程姿态：它没有用任何 Agent 框架，没有 LangGraph，没有 Claude Agent SDK，甚至没有用模型原生的 tool-calling。它只用了 Vercel AI SDK 的一个原语 streamText()，然后把一个可用编码 Agent 所需要的全部脚手架自己手搓了出来。 如果你读过我之前那篇《Agent Engineering 全景地图》 ，会记得一个核心论点：模型是买来的，harness 是你造的，工程杠杆全在那 98.4%。open-lovable 就是这句话一个绝佳的、可以逐行验证的真实样本。这篇文章会沿着四个维度把它拆开：产品定位 → Agent 架构 → 自研 harness（独立成章）→ 云端沙箱（独立成章），最后落到可借鉴点。 本文的代码级事实，主要来自对其仓库与 DeepWiki 索引的交叉阅读，关键出处都会标注。 一、产品视角：一个伪装成应用的增长漏斗 它到底是什么 一句话：输入一个网址或一句话描述，AI 在云端沙箱里生成并实时预览一个可运行的 React 应用。三种核心用法： 克隆模式：用 Firecrawl 抓取目标网站的 Markdown + 截图，让 AI 重建为现代 React 应用； 品牌延展（Brand Extension）：只提取目标站的色彩、字体、间距等设计 token，再用这套品牌规范生成全新页面； 搜索生成：先搜索、再抓内容、再生成。 真正聪明的是它的商业意图 open-lovable 本身不直接变现。它是 Firecrawl 的获客漏斗与技术名片——你要跑它，就必须配一把 FIRECRAWL_API_KEY。于是 27k star 几乎都会顺手成为 Firecrawl 抓取 API 的潜在用户。 ...

「绝大多数 Agent 项目死在 PoC 和生产之间的那段没有地图的荒野。」 这句话是我反复读 Relay 项目文档时自己写下来的。Relay 是一个开源的求职 AI Agent 系统——不是那种「3 行 LangChain 代码 + GPT-4」的演示，而是一个有完整架构文档、172 个工程任务、混合技术栈、并且对每个设计决策都给出了明确反例的项目。 它还没有完全跑起来。Agent 层的代码还在写。但这恰恰是我觉得值得写这篇文章的原因：这是一个在设计层面思考非常深的系统，而那些深度思考本身——无论这个项目最终走向何方——都是对所有在做 Agent 工程的人有价值的参考。 这篇文章不是产品介绍，是一次架构拆解。 一、问题背景：为什么求职场景特别适合做 Agent 系统 在聊架构之前，我想先回答一个更基础的问题：为什么求职是一个适合 Agent 而不只是 AI 工具的场景？ 求职的本质是一条多阶段、多工具、高认知负担的工作流： 简历准备 → 职位搜索 → 简历定制 → 表单填写 → 投递追踪 ↑ ↓ └──────── 面试准备 ← 面试邀请 ←────────────────┘ 每个节点都需要大量「低价值的机械劳动」——搜索、复制、粘贴、调格式、填表单。同时，每个节点的「高价值判断」——这份职位适合我吗？这段经历该怎么呈现？这道面试题我应该怎么练？——都是高度个人化、依赖上下文的问题。 这正是 Agent 系统应该介入的地方：把机械劳动自动化，把高价值判断辅助化，把不可逆操作透明化。 Relay 的北极星是：「质量优先而非数量优先——精准的一发，胜过无脑的一百发。」 这个定位本身就决定了它的架构不能是「一键批量投递」，而必须是「每一份投递都经过用户确认」。 二、整体架构：五层设计 Relay 的架构分五层，从底向上依次是： ┌──────────────────────────────────────────────────────────┐ │ 第 5 层：UI 层 │ │ Next.js 16 Web 控制台 + Manifest V3 浏览器扩展 │ ├──────────────────────────────────────────────────────────┤ │ 第 4 层：API + 编排层 │ │ Hono/Bun TypeScript API + Redis Event Bus │ ├──────────────────────────────────────────────────────────┤ │ 第 3 层：Agent 执行层 │ │ Python FastAPI + LangGraph（5 个 domain agent） │ ├──────────────────────────────────────────────────────────┤ │ 第 2 层：共享服务 │ │ Auth、Notification、Audit、LLM Router │ ├──────────────────────────────────────────────────────────┤ │ 第 1 层：数据 + 外部集成 │ │ PostgreSQL + pgvector、Redis、MinIO、OpenRouter │ └──────────────────────────────────────────────────────────┘ 最核心的设计决策是混合后端：API 层用 TypeScript（Hono + Bun），Agent 层用 Python（FastAPI + LangGraph），两层通过 HTTP + Redis + 共享 PostgreSQL 连接。 ...

「与其说我们在写提示词，不如说我们在为模型布置一间房间——决定哪些东西摆进来、摆在哪、什么时候搬走。措辞只是房间里的一张便签，而我们真正在做的，是装修。」 如果你在 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 的信号。 ...

「Agent loop 是 10 行代码，Agent engineering 是 10 万行代码。」 这句话我第一次读到时愣了一下，然后越想越觉得它锋利。它把整个领域里最大的一个错觉戳破了：很多人以为做 Agent 就是把 prompt 写好、把 LLM API 调通——而真正把一个 demo 推到生产、能在无人值守下安全跑一整夜的工程量，99% 都不在那个 loop 里。 这篇文章想做一件事：把 Agent Engineering 当成一门学科来拆，而不是当成一个教程。我不会教你怎么用 LangGraph，我想给你一张地图——这门学科由哪八根支柱构成、每一根填补了前一根留下的什么缺口、它的最小实现长什么样、又会在什么时候失效。读完之后，你看任何一个 Agent 框架、任何一篇大厂工程博客，都能立刻定位它在这张地图的哪个位置。 地图的素材，一半来自我自己造 Agent 系统时反复踩的坑，另一半来自 2025 到 2026 这一年里 Anthropic、OpenAI、Cognition、Manus、Temporal 这些一线团队公开出来的实践。我会尽量把每个关键论点的出处标清楚——因为这个领域里，错传的"事实"比真相传得更快，这一点我们马上就会撞上第一个。 一、那个被反复引用的数字：98.4% 先从一个流传极广的数字开始，因为它是这篇文章的标题，也是整个领域最好的一句开场白。 2026 年有一篇逆向拆解 Claude Code 的论文 《Dive into Claude Code》（VILA-Lab，arXiv: 2604.14228），分析对象是 Claude Code v2.1.88——大约 1900 个 TypeScript 文件、51 万行代码。它的摘要里有一段我愿意原样抄下来的话： 「系统的核心是一个简单的 while 循环，它调用模型、运行工具、然后重复。然而绝大部分代码，都活在这个循环周围的系统里：一个有七种模式和一个基于 ML 的分类器的权限系统、一条用于上下文管理的五层压缩流水线、四种可扩展机制（MCP、插件、技能、钩子）、一个带 worktree 隔离的子 agent 委派机制，以及面向追加的会话存储。」 注意这里有个重要纠偏：那个广为流传的精确数字「1.6% 是 AI 决策逻辑、98.4% 是基础设施」其实不在论文摘要里，它是二次概述时的渲染。而且网上很多人把它归给 minusx 的博客、或者"UCL 团队逆向泄露源码"——这些归属都是错的。minusx 那篇《Decoding Claude Code》写得很好，但里面根本没出现过任何百分比；论文也不是基于泄露源码，而是分析公开的 TypeScript。 ...

本项目是一个持续的过程，以日拱一卒的态度去学习 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。这种转换的重点在于尽可能保留原始文档的重要结构和内容，例如标题、列表、表格、链接等。 ...

AI & Technology description: > 本文探讨了大型语言模型（LLM）的变革能力，这些模型旨在理解和生成人类语言，展示了人工智能技术的先锋角色。通过利用大量数据和复杂的机器学习架构，这些模型展现了远超前任的涌现能力。 大语言模型简介 大语言模型（LLM，Large Language Model），也称大型语言模型，是一种旨在理解和生成人类语言的人工智能模型。 LLM 通常指包含数百亿（或更多）参数的语言模型，它们在海量的文本数据上进行训练，从而获得对语言深层次的理解。目前，国外的知名 LLM 有 GPT-3.5、GPT-4、PaLM、Claude 和 LLaMA 等，国内的有文心一言、讯飞星火、通义千问、ChatGLM、百川等。 为了探索性能的极限，许多研究人员开始训练越来越庞大的语言模型，例如拥有 1750 亿参数的 GPT-3 和 5400 亿参数的 PaLM 。尽管这些大型语言模型与小型语言模型（例如 3.3 亿参数的 BERT 和 15 亿参数的 GPT-2）使用相似的架构和预训练任务，但它们展现出截然不同的能力，尤其在解决复杂任务时表现出了惊人的潜力，这被称为“涌现能力”。以 GPT-3 和 GPT-2 为例，GPT-3 可以通过学习上下文来解决少样本任务，而 GPT-2 在这方面表现较差。因此，科研界给这些庞大的语言模型起了个名字，称之为“大语言模型（LLM）”。LLM 的一个杰出应用就是 ChatGPT ，它是 GPT 系列 LLM 用于与人类对话式应用的大胆尝试，展现出了非常流畅和自然的表现。 LLM 的发展历程 语言建模的研究可以追溯到20 世纪 90 年代，当时的研究主要集中在采用统计学习方法来预测词汇，通过分析前面的词汇来预测下一个词汇。但在理解复杂语言规则方面存在一定局限性。 随后，研究人员不断尝试改进，2003 年深度学习先驱 Bengio 在他的经典论文 《A Neural Probabilistic Language Model》中，首次将深度学习的思想融入到语言模型中。强大的神经网络模型，相当于为计算机提供了强大的"大脑"来理解语言，让模型可以更好地捕捉和理解语言中的复杂关系。 2018 年左右，Transformer 架构的神经网络模型开始崭露头角。通过大量文本数据训练这些模型，使它们能够通过阅读大量文本来深入理解语言规则和模式，就像让计算机阅读整个互联网一样，对语言有了更深刻的理解，极大地提升了模型在各种自然语言处理任务上的表现。 与此同时，研究人员发现，随着语言模型规模的扩大（增加模型大小或使用更多数据），模型展现出了一些惊人的能力，在各种任务中的表现均显著提升。这一发现标志着大型语言模型（LLM）时代的开启。 LLM 的能力 涌现能力（emergent abilities） 区分大语言模型（LLM）与以前的预训练语言模型（PLM）最显著的特征之一是它们的 涌现能力 。涌现能力是一种令人惊讶的能力，它在小型模型中不明显，但在大型模型中特别突出。类似物理学中的相变现象，涌现能力就像是模型性能随着规模增大而迅速提升，超过了随机水平，也就是我们常说的量变引起质变。 ...