你有没有想过，为什么 Cursor、v0、Perplexity、Lovable、Bold 这些服务数百万用户的顶级 AI Agent 产品，竟然都有一个惊人的共同点？它们全部都不是基于任何 AI 框架构建的。当整个行业都在疯狂追逐最新的 AI 框架，试图通过层层抽象来简化开发时，这些真正成功的产品却选择了完全相反的道路——它们基于 AI 基本单元（primitives）直接构建，用最朴素的方式解决最复杂的问题。这不是巧合，而是揭示了一个我们可能一直忽视的根本性真相：在快速变化的 AI 时代，框架的抽象可能反而成为了创新和规模化的最大障碍。
最近，我深度研究了 Langbase 创始人兼 CEO Ahmad Awais 的一次演讲。Ahmad 绝非泛泛之辈，他的技术履历堪称传奇：NASA 直升机任务代码贡献者、Google 开发者顾问委员会成员、前开发者工具副总裁，WordPress、Next.js、Node.js、React 等知名开源项目的核心贡献者。他的开源包年下载量达到惊人的 4000-5000 万次，还创建了广受欢迎的 Shades of Purple 代码主题。
更重要的是，他从 2020 年就开始深度参与 LLM 技术开发，当时 GPT-3 才发布一个月，Greg Brockman 就直接给了他访问权限，比 GitHub Copilot 早一年就开始构建代码生成工具。这样的技术深度让他对 AI agent 构建的洞察显得格外有分量。在这次演讲中，他不仅现场用基本单元构建了 8 种不同架构的 AI agent，更提出了一个颠覆性观点：最好的 AI agent 应该像搭积木一样用基本单元组装，而不是被框架的抽象层束缚。
框架的陷阱：为什么抽象成了生产力杀手
在Ahmad十多年的技术生涯中，他见证了无数个技术周期，但 AI 领域的情况让他重新思考了框架存在的意义。Ahmad 在演讲中一针见血地指出：框架并没有真正增加价值，它们臃肿、迭代缓慢，充满了没人真正需要的抽象。这个观点初听可能有些刺耳，但深入思考后，我发现这恰恰击中了当前 AI 开发的核心痛点。
传统软件开发中，框架之所以有价值，是因为技术栈相对稳定，业务模式相对固定，抽象层能够帮助开发者处理重复性工作，提高开发效率。但 AI 领域完全不是这么回事。每隔几周就有新的大模型发布，新的 agent 架构出现，新的能力边界被突破。就像 Ahmad 说的，这个领域变化如此之快，任何预先定义的抽象都可能很快过时。更要命的是，当你深度依赖某个框架时，你就被锁定在了那个特定的抽象层里。当技术发生重大突破时，你很难快速适应，因为你要么等待框架作者更新（通常很慢），要么费劲地迁移到新框架。
我特别认同 Ahmad 提到的 Amazon S3 这个经典例子。S3 之所以能够支撑起整个云计算生态，不是因为它提供了复杂的对象存储框架，而是因为它提供了极其简单的基本单元：上传数据和下载数据。就这样两个基本操作，却支撑起了无数复杂的应用场景，从简单的文件存储到复杂的数据湖架构。这种设计哲学的核心在于：提供足够强大的底层能力，让开发者能够根据具体需求灵活组合，而不是试图预测所有可能的使用场景并提供对应的抽象。
从生产实践的角度看，我发现当前大多数 AI 框架的最大问题是它们试图解决一个本质上无法解决的问题：如何为一个快速变化的技术领域提供稳定的抽象。这就像试图为一个正在爆发的火山制作精确的地形图，注定会失败。框架的另一个问题是它们往往过于通用化，为了满足各种可能的使用场景，引入了大量的配置选项和抽象层，最终变得既复杂又低效。在 AI 这样对性能和响应速度要求极高的领域，这种臃肿是不可接受的。
Ahmad 的另一个深刻洞察是：大多数工程师正在快速转变为 AI 工程师。前端开发者、后端开发者、DevOps 工程师、ML 工程师，都在学习如何将 AI 能力集成到他们的产品中。这种转变要求我们重新思考开发工具的设计哲学。这些工程师已经有了丰富的编程经验和成熟的思维模式，他们需要的不是另一套复杂的框架和抽象概念，而是能够用熟悉的编程语言和模式直接操作的基本单元。正如演讲中展示的那样，基于基本单元构建的 AI agent 本质上就是普通的 JavaScript/TypeScript 代码，任何有编程经验的开发者都能立即理解和修改。
AI 基本单元的威力：像乐高一样构建智能
在深入研究 Ahmad 的方法论后，我开始重新理解 AI agent 的本质架构。我发现，无论多么复杂的 AI agent，其核心都可以分解为几个基本的构建模块，就像化学元素周期表一样，所有的化合物都由基本元素组成。Ahmad 在演讲中识别出了几个关键的 AI 基本单元：Memory（具备向量存储能力的长期记忆系统）、Thread（对话上下文和状态管理）、Tools（外部工具调用能力）、Parser（多格式数据解析）、Chunker（文档分割和预处理）、Router（智能路由决策）、Evaluator（质量评估和反馈）。
这些基本单元的美妙之处在于它们的可组合性和专业性。每个单元都专注于解决一个特定问题，并在这个问题上做到极致，然后通过灵活组合来构建复杂功能。这就像 Unix 哲学中的"做一件事并做好"在 AI 时代的完美体现。Memory 单元不需要关心如何解析 PDF，Parser 单元不需要考虑如何存储向量，每个单元都有清晰的职责边界，这使得整个系统既高效又易于理解。
在演讲的现场演示中，Ahmad 仅仅说了一句"chat with PDF"，他的 CHAI 系统就自动识别出需要哪些基本单元，并生成了完整的实现代码。整个过程令人印象深刻：系统自动判断需要 Memory 单元来存储 PDF 内容（包含向量存储功能），需要 Parser 单元来处理 PDF 格式，需要 Chunker 单元来分割长文档，需要 LLM 单元来理解问题和生成答案。最关键的是，生成的代码完全没有框架依赖，就是纯粹的 JavaScript 代码，清晰、可读、易于修改。
演示的效果让我深受震撼。Ahmad 上传了几个 PDF 文件，包括他的个人简介、演讲信息、Langbase 的 API 文档等。Parser 单元自动将这些 PDF 转换为文本，Chunker 单元将长文档分割成适合处理的片段，Memory 单元自动进行向量化并存储，整个过程完全自动化。当他问"谁是创始人以及他最近三次演讲的主题"时，agent 能够跨越多个文档找到相关信息并给出准确答案。这种跨文档的信息整合能力，正是基本单元组合的威力体现。
我特别欣赏这种架构的透明性和可控性。与黑盒框架不同，基于基本单元的系统让你能够清楚地看到每一步发生了什么，理解数据是如何流动的，问题出现时也容易定位和调试。Ahmad 在演示中甚至发现了一个小 bug，他可以直接在"vibe code"模式下快速修复，而不需要深入复杂的框架源码或等待框架更新。这种immediate feedback和直接控制能力对生产环境来说至关重要。
从架构演进的角度看，我认为基本单元方法更符合软件系统的自然演化规律。复杂系统往往是从简单组件逐步演化而来的，而不是一开始就设计得很复杂。基本单元提供了这样的演化路径：你可以从最简单的组合开始，根据实际需求逐步添加更多单元，每一步都是可控的、可验证的。这种渐进式的构建方式不仅降低了风险，也让系统更容易维护和扩展。
八种架构模式：基本单元组合的生产实践
Ahmad 在演讲中详细展示了八种不同的 AI agent 架构模式，每一种都基于基本单元的不同组合方式。这些架构模式不仅展现了基本单元的强大组合能力，更重要的是它们覆盖了当前生产环境中绝大多数的 AI agent 需求。我仔细分析后发现，这八种模式实际上构成了一个完整的 AI agent 设计语言，可以应对从简单问答到复杂推理的各种场景。
第一种是增强型 LLM（Augmented LLM）架构，这是最基础也是最常用的模式。它将 LLM 与 Tools、Thread、Memory 等基本单元组合，形成一个能够调用外部工具、维护对话状态、访问长期记忆的智能 agent。在这种架构中，LLM 不再是一个孤立的文本生成器，而是一个能够感知环境、调用工具、学习记忆的智能体。Ahmad 强调，这种架构的关键在于每个基本单元都是独立的、可替换的，你可以根据具体需求选择最合适的实现。
第二种是提示链和组合（Prompt Chaining & Composition）架构，这种模式通过串联多个专门的 agent 来处理复杂的多步骤任务。Ahmad 演示了一个营销内容生成的例子，包含总结 agent、功能提取 agent 和营销文案 agent。每个 agent 都有明确的职责分工，按照预定的顺序工作，将前一个 agent 的输出作为下一个 agent 的输入。这种设计的巧妙之处在于每个 agent 都可以使用最适合其任务的模型，比如用 Gemini 做总结（因为它在理解和概括方面表现优秀），用 Claude 做推理（因为它在逻辑分析方面更强），用 GPT-4 做编程（因为它的代码生成能力出色）。
第三种是 Agent 路由器（Agent Router）架构，这是我个人最感兴趣的模式之一。在这种架构中，一个智能路由 agent 负责分析用户输入，然后决定调用哪个专门的执行 agent。Ahmad 构建了一个包含三个专门 agent 的系统：总结 agent（使用 Gemini）、推理 agent（使用 DeepSeek Llama 70B）和编程 agent（使用 Claude Sonnet）。当用户问"为什么冬天的白天更短"时，路由 agent 正确识别出这是一个需要科学推理的问题，自动将任务路由给推理 agent 处理。这种架构的价值在于它能够根据任务特性自动选择最优的处理路径，而且每个专门 agent 都可以独立优化和升级。
第四种是并行 Agent（Parallel Agents）架构，这种模式利用现代编程语言的并发能力，同时运行多个 agent 来处理同一个输入的不同方面。在 JavaScript 中，这通过 Promise.all 就能轻松实现。比如，对于一段客户反馈，你可以同时运行情感分析 agent、关键信息提取 agent 和问题分类 agent，然后将结果组合起来形成全面的分析报告。这种并行处理不仅大大提高了效率，还能从多个角度同时分析问题，获得更全面的洞察。
第五种是编排器-工作者（Orchestrator-Worker）架构，这是我认为最具创新性的模式，它模拟了人类团队协作的工作方式。一个编排器 agent 负责分析复杂任务并将其分解为多个子任务，然后分配给多个工作者 agent 并行处理，最后由一个综合 agent 将所有结果整合成最终输出。Ahmad 演示的博客写作例子特别精彩：编排器将"写一篇关于远程工作好处的博客"分解为五个具体子任务：写引言、写生产力部分、写工作生活平衡部分、写环境影响部分、写结论。五个工作者 agent 并行工作，每个专注于自己的部分，最后由综合 agent 将所有部分组合成一篇连贯的完整文章。这种架构的威力在于它可以处理几乎任意复杂度的任务，只要能够有效分解。
第六种是评估器-优化器（Evaluator-Optimizer）架构，这种模式通过持续的评估和优化来提高输出质量，类似于 RLHF（人类反馈强化学习）的简化版本。一个生成 agent 创建初始内容，然后一个评估 agent（通常使用性能最好的 LLM）对结果进行评估，如果不满意就提供具体的改进建议，生成 agent 根据反馈进行优化。Ahmad 演示的生态友好水瓶产品描述例子很有说服力：第一次生成的描述被评估 agent 认为没有很好地针对"环保意识的千禧一代"这个目标受众，评估 agent 提供了非常具体的改进建议，包括应该强调哪些特点、使用什么样的语调等。第二次生成的描述明显更符合目标受众的需求和偏好。
第七种是工具调用（Tool Calling）架构，这使得 agent 能够与外部系统无缝集成，扩展其能力边界。第八种是记忆型（Memory）架构，这就是我们在演讲开头看到的文档问答模式。
让我印象最深刻的是，Ahmad 现场使用 CHAI 构建了几个复杂的实际应用。他构建了一个类似 Perplexity 的深度研究 agent，系统自动识别出需要分析查询、进行网络搜索（使用 Exa 搜索工具）、整合结果并生成回应的完整流程，所有代码都是纯 JavaScript，没有任何框架依赖。他还演示了一个收据检查器，当系统发现没有现成的 OCR 基本单元时，它自动找到了 Mistral 的 OCR API 并集成进来，展现了基本单元系统的强大扩展性。还有一个图像分析 agent，能够分析图片中人物的表情和情绪，Ahmad 上传了一张自己的照片，agent 准确地描述了他"眉毛微扬，表情略显怀疑和好奇"的神态。
为什么基本单元是未来的必然选择
在深入理解了 Ahmad 的理念和实践后，我开始从更宏观的角度思考这种基于基本单元的方法对整个 AI 行业的深远影响。我认为，我们正在经历一场类似于从汇编语言到高级语言的技术革命，但有趣的是，这次的方向看起来是相反的：我们正在从过度抽象回归到更接近本质、更可控的表达方式。
从技术发展趋势来看，基本单元方法符合软件系统的自然演化规律。在计算机科学的历史中，那些经久不衰的技术往往都遵循"简单而强大"的设计原则。Unix 的管道和工具、HTTP 协议、SQL 语言，这些技术之所以能够长期存在并不断发展，正是因为它们提供了简单而强大的基本单元，让开发者能够灵活组合来解决复杂问题。AI 基本单元延续了这一传统，为快速变化的 AI 领域提供了稳定的基础设施。
从开发者体验的角度看，基本单元方法大大降低了 AI 开发的认知负担。Ahmad 在演讲中提到一个重要观点：当大多数工程师都在向 AI 工程师转变时，他们需要的不是另一套复杂的概念体系，而是能够用熟悉的工具和思维模式来构建 AI 应用。基本单元正好满足了这个需求。一个有 JavaScript 经验的开发者可以立即理解基于基本单元的 AI agent 代码，因为它本质上就是普通的 JavaScript 代码，只是调用了一些特殊的 API。这种连续性对于技术推广和应用普及至关重要。
从性能和可扩展性的角度看，基本单元方法具有显著优势。每个基本单元都可以独立优化，比如 Memory 单元可以专注于向量搜索的性能优化，Parser 单元可以专注于各种文档格式的处理效率。这种专业化分工使得整个系统能够达到更高的性能水平。同时，基本单元的无状态设计使得它们天然支持水平扩展，可以轻松实现 serverless 架构。Ahmad 在演讲中特别强调了这一点：基于 Langbase 基本单元构建的 agent 可以自动扩展，处理从几个请求到数百万请求的各种负载。
从业务灵活性的角度看，基本单元方法让企业能够更快地响应市场变化和用户需求。当新的 LLM 发布或新的 AI 能力出现时，企业可以快速集成新技术而不需要重构整个系统。比如，如果出现了更好的文档解析技术，你只需要替换 Parser 基本单元，其他部分完全不受影响。这种模块化设计大大降低了技术迭代的风险和成本。
从技术生态的角度看，基本单元方法促进了真正的技术标准化。不像框架那样试图标准化抽象层（往往导致碎片化），基本单元标准化的是能力接口。这使得不同厂商的基本单元可以互相替换和组合，形成一个开放、竞争、协作的生态系统。Ahmad 提到的 Model Context Protocol（MCP）就是这种标准化努力的一个例子。
我特别认同 Ahmad 对未来趋势的判断：随着 LLM 在 agent 工作流程方面变得更加智能，那些绑定在特定框架抽象上的应用将很难快速适应新能力。而基于基本单元构建的系统，由于其底层的灵活性，可以更容易地集成新的 AI 能力和工作模式。这就像是为 AI 时代构建了一套可扩展的指令集架构，让上层应用能够持续演进而不受底层技术变化的制约。
从长远来看，我预测我们将看到一个分层的 AI 开发生态系统：底层是高性能、高可靠性的基本单元服务（如 Langbase、OpenAI API、Anthropic API 等），中层是针对特定行业或场景的组合模式和最佳实践库，上层是面向最终用户的应用产品。这种分层结构将既保持足够的灵活性来适应技术变化，又提供足够的抽象来简化开发工作。
最终，我认为基本单元方法代表了一种新的技术哲学：不是试图预测和控制未来，而是构建足够灵活和强大的基础设施来适应未来的各种可能性。在这个充满不确定性的 AI 时代，这可能正是我们最需要的技术范式。正如 Ahmad 在演讲结尾所说：与其使用臃肿的框架来构建 agent，不如像搭积木一样用基本单元造出属于你自己的"Agent Stack"。这不仅是一种技术选择，更是一种面向未来的战略思维。
