无需脚手架：从零构建 AI Agent 的开发模式解析

📖 读完本文你将获得：

• 理解 AI Agent 的核心架构组件，不再依赖框架的「黑箱」
• 掌握从零构建 Agent 的完整开发路径，从手写循环到模块化架构
• 对比无框架开发 vs 框架开发的优劣，知道何时该用什么
• 了解 2026 年 AI Agent 开发的最新趋势和最佳实践
• 获得一个可复用的 Agent 核心架构模板，可根据需求扩展

2026 年，AI Agent 开发框架的选择比任何时候都多：LangChain、LlamaIndex、CrewAI、AutoGen、LangGraph、DSPy、Semantic Kernel……每个框架都声称能让 Agent 开发变得「简单」。

但「简单」的背后有一个代价：抽象泄漏（Leaky Abstraction）。

框架的抽象泄漏问题

当 Agent 的行为不符合预期时，框架使用者面临的典型困境是：

• 你不知道问题是出在你的 Prompt 设计、工具定义，还是框架内部的逻辑
• 框架的文档通常覆盖了「happy path」，但对异常处理和边缘情况的说明不足
• 框架的版本升级可能引入不兼容的变更，而你并不清楚自己依赖了哪些内部行为
• 当你需要定制 Agent 的行为模式时，可能需要深入框架源码——这意味着你最终还是得理解底层机制

一个具体的例子：使用 LangChain 构建一个需要多步推理的 Agent。当 Agent 在某个步骤卡住时，你看到的是框架的抽象层——AgentExecutor、Tool 调用链、ChatModel 接口——而不是你真正需要调试的东西：Prompt 中的推理步骤是否清晰？工具的输入输出格式是否正确？模型是否在某个决策点上做出了错误的选择？

不依赖框架的好处

从零构建 Agent 有几个被低估的好处：

第一，深度理解。 当你亲手实现 Agent 的核心循环（感知→推理→行动→观察），你会真正理解 Agent 的行为机制。这种理解在你调试复杂 Agent 行为、设计新的 Agent 模式时至关重要。

第二，精确控制。 没有框架意味着没有「隐藏的逻辑」。Agent 的每一个行为都是你明确编写的——这意味着你可以精确控制超时、重试、错误恢复、状态持久化等关键行为。

第三，性能优化。 框架通常为了通用性而牺牲性能。当你不需要框架的全部功能时，自己实现可以显著减少延迟和内存占用。

第四，技术债务最小化。 框架是外部依赖。框架的 API 变更、停止维护、安全漏洞——这些风险在你自己实现的核心逻辑中不存在。

本站的立场：框架是工具，不是替代品。在生产环境中，框架可以极大加速开发。但理解 Agent 的底层机制——不依赖任何框架地构建一个完整的 Agent——是每个 AI 开发者应该具备的核心能力。

// Agent 核心循环的最小实现
async function agentLoop(userInput, maxSteps, { model, tools, safetyGuard }) {
  let state = { history: [{ role: "user", content: userInput }] };
  
  for (let step = 1; step <= maxSteps; step++) {
    const messages = buildMessages(state);
    const response = await model.generate(messages, { tools: tools.map(t => t.schema) });
    
    if (response.finish_reason === "stop") {
      return response.content;
    }
    
    if (response.tool_calls) {
      for (const tc of response.tool_calls) {
        if (!safetyGuard.validate(tc)) {
          state.history.push({ role: "system", content: "操作被安全守卫拦截" });
          continue;
        }
        const tool = tools.find(t => t.name === tc.name);
        const result = await tool.execute(tc.arguments);
        state.history.push({ role: "tool", content: JSON.stringify(result) });
      }
    }
  }
  return "达到最大步骤数，任务未完成";
}

任何 AI Agent 都可以简化为一个核心循环：接收输入→推理→行动→观察结果→重复。这个循环看似简单，但实现一个生产级的 Agent 需要考虑多个维度的设计决策。

Agent 的最小组件

一个功能完整的 Agent 至少需要以下组件：

1. 模型接口（Model Interface）。负责与大语言模型通信。即使是「从零构建」，你也需要调用 LLM 的 API。核心是管理 API 调用、处理速率限制、实现重试逻辑和错误恢复。

2. 工具注册表（Tool Registry）。Agent 可以调用的工具集合。每个工具需要定义：名称、描述、输入参数 schema、执行函数、输出格式。工具注册表需要支持动态注册和注销——Agent 在不同的任务阶段可能需要不同的工具集。

3. 状态管理器（State Manager）。维护 Agent 的当前状态，包括：对话历史、工具调用记录、中间推理结果、当前任务进度。状态管理器的设计决定了 Agent 能否处理长对话、能否从错误中恢复、能否在执行中断后继续。

4. 推理引擎（Reasoning Engine）。Agent 的「大脑」——负责根据当前状态和可用工具，决定下一步行动。这是 Agent 架构中最核心的组件，不同的推理模式（ReAct、Plan-and-Execute、Reflexion）在这里实现。

5. 安全守卫（Safety Guard）。在执行任何工具调用之前，验证该调用是否符合安全策略。包括：输入验证、权限检查、速率限制、输出过滤。

核心循环的实现

上述代码展示了 Agent 核心循环的最小实现。这个循环的每个组件都可以独立优化。推理引擎是最需要精心设计的部分——它决定了 Agent 是「聪明地」还是「盲目地」行动。

推理模式是 Agent 架构的灵魂。不同的推理模式决定了 Agent 如何处理复杂任务、如何从错误中学习、如何规划多步行动。

ReAct（Reasoning + Acting）

ReAct 是最经典的 Agent 推理模式。它的核心思想是：在每个步骤中，模型先进行「思考」（Thought），然后决定「行动」（Action），观察行动的「结果」（Observation），再进入下一步思考。

ReAct 的优势：实现简单，适合中等复杂度的任务（需要 3-5 步推理的任务）。模型的每一步推理都是透明的——你可以看到 Agent 的思考过程。

ReAct 的局限：在需要长期规划的任务中表现不佳。因为 ReAct 每一步只关注「下一步做什么」，没有全局规划能力。当任务需要 10 步以上时，ReAct 容易迷失方向。

Plan-and-Execute（规划-执行）

Plan-and-Execute 模式将任务分为两个阶段：规划阶段和执行阶段。在规划阶段，模型根据用户输入生成一个完整的行动计划。在执行阶段，模型按照计划逐步执行，每一步完成后检查计划是否需要调整。

Plan-and-Execute 的优势：适合需要多步骤规划的复杂任务。模型在开始行动之前就有了全局视角，减少了中途迷失方向的风险。

Plan-and-Execute 的局限：规划质量高度依赖模型的规划能力。如果初始计划有缺陷，后续执行可能会在错误的方向上越走越远。需要引入计划调整机制来应对这种情况。

Reflexion（反思）

Reflexion 模式在 ReAct 的基础上增加了一个反思层。当 Agent 的执行结果不符合预期时，它不会简单地重试，而是反思「为什么失败」，并将反思结果纳入下一步的推理中。

Reflexion 的优势：具有从错误中学习的能力。在需要试错的任务中（如代码调试、复杂查询），Reflexion 的表现显著优于 ReAct。

Reflexion 的局限：需要额外的 API 调用来进行反思，增加了延迟和成本。在某些简单任务中，反思可能引入不必要的复杂度。

模式选择决策树

任务决策策略如下：如果任务需要 10 步以上的长期规划，选择 Plan-and-Execute 模式；如果执行过程中还需要适应变化，则在 Plan-and-Execute 基础上增加 Reflexion 层。如果任务少于 5 步，选择 ReAct 模式；如果需要从错误中学习，则在 ReAct 基础上增加 Reflexion 反思层。

在实际开发中，建议从 ReAct 开始——它是最简单、最容易调试的模式。当发现 ReAct 无法满足需求时，再升级到更复杂的模式。不要一开始就使用最复杂的模式——过度工程是 Agent 开发中最常见的错误。

工具调用是 Agent 与现实世界交互的桥梁。一个强大的 Agent 不是因为它「聪明」，而是因为它能正确地使用工具。

工具定义规范

每个工具应该定义以下属性：

• 名称（name）：唯一标识符，建议使用 snake_case
• 描述（description）：工具的功能说明，模型根据这个描述决定是否调用该工具
• 参数 schema（parameters）：使用 JSON Schema 定义输入参数的类型、必填字段、枚举值
• 执行函数（execute）：实际执行工具逻辑的代码
• 安全级别（securityLevel）：定义工具的权限等级——只读、写入、危险操作

工具描述的质量直接决定了 Agent 能否正确使用工具。一个好的工具描述应该：

• 明确说明工具的用途和适用场景
• 指出工具的限制和不适用的场景
• 提供参数含义的详细说明
• 给出典型的调用示例

工具调用的安全守卫

这是从零构建 Agent 时必须重视的环节。框架通常内置了安全机制，但如果你从零构建，安全守卫必须自己实现。

核心安全检查：

1. 参数验证：检查工具调用的参数是否符合 schema 定义。不符合 schema 的调用应该被拦截，而不是传递给执行函数。

2. 权限检查：根据用户的权限级别，决定哪些工具可以调用。比如，一个只读权限的用户不应该能调用「删除数据库」的工具。

3. 速率限制：防止 Agent 在短时间内发起大量工具调用。这既是安全考虑（防止滥用），也是成本控制（每次工具调用都可能涉及 API 费用）。

4. 输出过滤：工具返回的结果可能包含敏感信息。在执行结果传递给模型之前，应该经过过滤层，移除不应该暴露给模型的信息。

Deno 团队 2026 年发布的 Claw Patrol 是一个 Agent 安全防火墙的典型案例。它通过在 Agent 和外部系统之间插入一个安全层，实时监控 Agent 的工具调用行为，在检测到异常模式（如权限提升尝试、敏感数据访问、异常调用频率）时自动拦截。这种「安全守卫即服务」的模式正在成为 Agent 开发的标配。

结合上述所有设计原则，以下是一个生产级 Agent 的完整架构。这个架构不依赖任何框架，每个组件的职责清晰，易于调试和扩展。

架构分层

Agent 架构分为四层：用户接口层（HTTP API / WebSocket / CLI）、Agent 核心层（推理引擎 + 状态管理 + 安全守卫）、工具层（搜索、代码、文件等工具）和模型接口层（LLM API 调用、速率管理、重试、缓存）。

关键设计决策

状态持久化。生产环境中的 Agent 需要支持会话恢复。当 Agent 进程重启或用户重新连接时，Agent 应该能够恢复到之前的状态。实现方式：将状态序列化后存储在数据库（如 SQLite、Redis）中，每次 Agent 启动时从存储中恢复状态。

流式输出。LLM 的推理是逐步生成 token 的过程。如果 Agent 等待模型完全生成再处理，会增加不必要的延迟。流式处理允许 Agent 在模型生成的过程中就开始处理部分结果——这在需要实时响应的场景中至关重要。

错误恢复策略。Agent 的工具调用可能失败（网络超时、API 限流、参数错误）。需要为每个工具定义重试策略：最大重试次数、重试间隔、回退方案（如果重试失败，是否有替代工具）。

监控与可观测性。生产环境中的 Agent 必须有完善的监控：每一步推理的输入输出、工具调用的成功率和延迟、异常行为的告警。这些信息不仅用于运维，也是调试 Agent 行为的关键数据。

为了公平对比，我们用一个具体的场景来评估无框架开发和框架开发的差异：构建一个需要多步推理、工具调用、状态管理的代码审查 Agent。

开发效率对比

运行时对比

何时选择无框架

以下场景强烈建议从零构建：

• 安全要求极高的场景：金融、医疗等行业的 Agent 开发。安全守卫必须精确可控，不能依赖框架的默认实现
• 性能敏感的场景：需要极低延迟的实时 Agent 应用。框架的抽象层可能引入不可接受的延迟
• 需要深度定制的场景：当你的 Agent 行为模式超出框架的设计范围时，从零构建是唯一的选择
• 学习和研究目的：理解 Agent 的底层机制

何时选择框架

以下场景建议使用框架：

• 快速原型验证：需要快速验证一个 Agent 概念的可行性
• 标准用例：你的 Agent 模式在框架的「舒适区」内（如标准的 ReAct Agent、多 Agent 协作）
• 团队开发：多人协作时，框架提供的统一架构和约定有助于代码维护
• 社区生态依赖：需要框架社区提供的工具集成、模板、最佳实践

最佳实践：先用无框架构建一个最小可行实现，理解核心机制。然后评估框架是否能为你的具体场景带来显著的开发效率提升。如果是，迁移到框架；如果不是，继续使用自定义实现。

2026 年的 AI Agent 开发正在经历几个关键的趋势变化。理解这些趋势对于做出正确的架构决策至关重要。

趋势一：Agent 运行时（Agent Runtime）的标准化

2026 年，Agent 运行时的概念正在从框架特定的实现演变为行业标准。一个 Agent 运行时负责：模型调用管理、工具调度、状态持久化、安全守卫、监控。开发者只需要定义 Agent 的行为逻辑（Prompt、工具、推理模式），运行时负责执行。

这种模式类似于 Web 开发中的「服务器运行时」——开发者编写业务逻辑，运行时处理 HTTP、数据库、安全等基础设施问题。标准化的 Agent 运行时将大幅降低 Agent 开发的复杂度，同时保持足够的灵活性。

趋势二：安全守卫即服务

Claw Patrol 的发布标志着 Agent 安全正在从「每个项目自己实现」转向「标准化的安全服务」。未来，Agent 安全守卫可能成为一个独立的云服务——开发者只需要将 Agent 的工具调用通过安全守卫代理，即可获得实时的安全监控和拦截能力。

趋势三：从单一 Agent 到 Agent 编排

随着 Agent 能力的增强，Agent 编排（Agent Orchestration） 正在成为一个独立的技术领域。编排器负责：任务分解、Agent 分配、结果聚合、冲突解决。这与 MapReduce 的范式类似——将一个大任务分解为多个子任务，分配给不同的 Agent 并行处理，然后聚合结果。

本站预判

2027 年，Agent 开发将进入「框架收敛期」。当前的框架生态过于碎片化——每个框架都有自己的架构设计、API 风格、抽象层次。未来 1-2 年，行业将收敛到 2-3 种主流的 Agent 架构模式。开发者需要做的不是学习所有框架，而是理解这些核心模式。

从第一性原理出发的 Agent 开发能力——不依赖任何框架地构建、调试和优化 Agent——将成为 AI 开发者的核心竞争力。框架会来来去去，但 Agent 的核心机制（推理、规划、工具调用、安全）是不变的。

本文首次发布于 2026 年 6 月初，以下补充 2026 年 6 月中旬的最新行业动态对 Agent 开发的影响。

Anthropic Fable 5：Agent 能力的新标杆

Anthropic 发布的 Claude Fable 5 是首个公开可用的 Mythos 级旗舰模型，在 Agent 开发领域引起了巨大关注：

• 100 万 token 上下文窗口：相比此前 Claude 系列的 200K 大幅扩展，Agent 可以处理更长的任务历史和更复杂的多步骤规划
• 推理预算可控：Fable 5 支持开发者精细控制推理预算，这在生产级 Agent 中是关键能力——你不再需要担心一个 Agent 任务消耗意外暴增
• 安全护栏增强：内置更完善的安全对齐机制，Agent 工具调用的安全性得到进一步提升

定价影响：Fable 5 的 API 定价翻倍（输入 $30/M token，输出 $75/M token），这意味着对于高频 Agent 调用场景，成本压力显著增加。但 Anthropic 的逻辑是：Fable 5 定位为高价值场景的首选——安全审计、复杂代码重构、法律分析等，这些场景中能力的价值远超成本。

OpenAI Codex 降价 75%：Agent 开发成本断崖式下降

同步发生的另一件大事是 OpenAI 将 Codex 价格下调 75%（从 $3/M token 降至 $0.75/M token），这对 Agent 开发者的影响更为直接：

• Codex Agent 成本骤降：如果你正在构建基于 Codex 的编码 Agent，单次任务的成本从约 $0.50 降至 $0.125
• Agent 调用频率可以大幅提升：降价使得「每次用户交互都调用 Agent」从经济不可行变为可行
• 全仓库自动化成为现实：Codex 降价 75% + 100 万 token 上下文 = Agent 可以一次性理解整个代码库并执行重构

对本文的补充建议

结合上述最新动态，更新本文的 Agent 架构建议：

1. 模型选择需要重新评估：如果你的 Agent 场景对安全要求极高（如金融、医疗），Fable 5 是首选；如果是高频通用场景（如客服、内容生成），Codex 降价后的性价比更优
2. 上下文窗口设计可以更大胆：100 万 token 的上下文意味着你的 Agent 可以维护更长的对话历史和更复杂的状态
3. 推理预算管理成为必选项：Fable 5 的高定价使得 Agent 的 token 预算控制从「最佳实践」升级为「生存技能」

💡 核心洞察：2026 年 6 月的定价变化标志着 AI Agent 开发进入新阶段——不再是「能不能做」的问题，而是「用哪个模型、花多少钱做」的工程决策。理解定价格局的 Agent 开发者，将在 2026 下半年获得显著的竞争优势。

从零构建 AI Agent 不是为了对抗框架，而是为了获得对抗框架泄漏的能力。

给 AI 开发者的具体建议：

1. 先做一次「无框架挑战」。选一个中等复杂度的 Agent 任务，不依赖任何框架，从零实现。这个过程会让你发现很多之前被框架掩盖的细节。

2. 理解每个框架的核心设计选择。LangGraph 选择图模型作为 Agent 的执行流，CrewAI 选择多 Agent 协作为核心范式，AutoGen 选择对话作为 Agent 交互方式。理解这些选择背后的权衡，才能做出正确的框架选择。

3. 安全守卫永远是第一位的。无论使用框架还是从零构建，安全守卫都不能省略。一个没有安全守卫的 Agent 就像一辆没有刹车的汽车——在平路上可能没问题，但一旦遇到下坡就完了。

4. 从简单开始，逐步复杂化。先用 ReAct 模式实现一个简单的 Agent，验证端到端的流程。然后根据需要逐步添加：规划能力、反思能力、多 Agent 协作、状态持久化。每一步都确保当前版本可以正常工作。

5. 建立你的 Agent 工具箱。随着开发经验的积累，你会积累一套可复用的组件：模型调用包装器、工具注册表、安全守卫、状态管理器。这些组件可以在不同的项目中复用，大幅降低后续开发的成本。

AI Agent 开发正在经历从「手工作坊」到「工业化生产」的转变。2026 年 6 月的 Fable 5 发布和 OpenAI 降价 75% 进一步加速了这一进程——Agent 开发的门槛在降低，但对开发者的第一性原理能力要求在提高。理解底层机制的开发者将比只懂框架 API 的开发者走得更远。