Agent 开发本质上就是高级点的 CRUD

我正在开发 DocFlow，它是一个完整的 AI 全栈协同文档平台。该项目融合了多个技术栈，包括基于 Tiptap 的富文本编辑器、NestJs 后端服务、AI 集成功能和实时协作。在开发过程中，我积累了丰富的实战经验，涵盖了 Tiptap 的深度定制、性能优化和协作功能的实现等核心难点。

如果你对 AI 全栈开发、Tiptap 富文本编辑器定制或 DocFlow 项目的完整技术方案感兴趣，欢迎加我微信 yunmz777 进行私聊咨询，获取详细的技术分享和最佳实践。

如果你对 OpenClaw 也感兴趣，也欢迎添加我微信，我拉你进交流群

很多做了一段时间 Agent 开发的人，都会冒出一种奇怪的失落感------明明在做"最前沿的 AI 应用"，但每天干的事情和普通后端开发没啥区别：读数据、调接口、存结果、处理格式。

这种感觉其实非常精准。说明你已经看穿了目前市面上大多数 AI 应用的真面目，不过是通过胶水代码连接不同数据源和服务的系统。

但如果只停在这里，会错过一个更重要的认识：Agent 和传统 CRUD 的根本差异，不在于你调了多少接口，而在于"决策权"交给了谁，以及你如何处理那些无法被穷举的"不确定性"。

核心逻辑的变化，从硬编码到概率推理

传统业务系统里，if-else 是确定性的。开发者在写代码时，就已经预判了所有可能的分支，逻辑路径在 deploy 那一刻就已经完全固化。

typescript 复制代码

// 传统 CRUD：逻辑路径写死在代码里
if (order.status === "PAID") {
  await shipOrder(order.id);
} else if (order.status === "PENDING") {
  await sendReminder(order.userId);
} else {
  await logUnhandledStatus(order.status);
}

Agent 的逻辑根本不是这么运作的。你把工具的用途用自然语言描述出来，模型根据当前的对话上下文，概率性地判断要不要调用它、传什么参数进去。

typescript 复制代码

const tools: ChatCompletionTool[] = [
  {
    type: "function",
    function: {
      name: "ship_order",
      description:
        "当用户明确表示已完成支付，或系统确认订单状态为已支付时，发起发货流程。若用户只是咨询发货进度，不应调用此工具。",
      parameters: {
        type: "object",
        properties: {
          orderId: { type: "string", description: "订单唯一标识符" },
          priority: {
            type: "string",
            enum: ["normal", "express"],
            description: "发货优先级，默认为 normal",
          },
        },
        required: ["orderId"],
      },
    },
  },
];

const response = await openai.chat.completions.create({
  model: "gpt-4.1",
  messages: conversationHistory,
  tools,
  tool_choice: "auto",
});

const toolCall = response.choices[0].message.tool_calls?.[0];
if (toolCall?.function.name === "ship_order") {
  const args = JSON.parse(toolCall.function.arguments) as {
    orderId: string;
    priority?: "normal" | "express";
  };
  await shipOrder(args.orderId, args.priority ?? "normal");
}

关键点就在这里：你最终还是要写代码处理返回值，但中间那个"判断用户意图、决定执行哪个操作"的过程，不再是你写的条件判断，而是 LLM 的语义理解。这一层"决策权的让渡"，是两者最本质的差异。

更微妙的是，你写的那段 description 字符串，实际上变成了系统行为的一部分。传统 CRUD 里，逻辑写在代码里，可以被静态分析、单元测试覆盖。而 Agent 的行为边界，部分藏在自然语言里，测试难度和不确定性都随之上升。

接口协议的演变，从手动对接到工具标准化

在传统开发里，你对接一个外部 API，流程通常是：

看文档，理解数据结构
写类型定义，手动组装请求参数
处理各种奇怪的错误码和返回格式
维护一份内部的封装层，隔离外部变化

到了 Agent 开发，这套流程变成了：把 API 的能力定义成一份 JSON Schema，让模型"看懂"这个工具能做什么、需要什么参数。工具描述的质量，直接决定了模型调用的准确率。

Function Call 解决的是单个模型和工具的对接问题。MCP（Model Context Protocol）则把这个过程彻底标准化------不管你用的是 Claude、GPT，还是 DeepSeek，只要服务提供方遵循 MCP 协议，Agent 就可以像接入 USB 设备一样无缝使用外部能力，包括数据库、搜索服务、本地文件系统、甚至另一个 AI 服务。

从工程角度看，这确实只是"换了一套接口协议"。但标准化带来的意义在于：工具可以在不同的 Agent、不同的模型之间复用，工具市场得以形成，开发者不再需要为每一个 LLM 重新写一遍对接代码。

这个演进方向很像当年从 SOAP 到 REST，再到 OpenAPI 规范的历程。每一次标准化，都会让生态扩张一个量级。

为什么很多人觉得"换汤不换药"

在 LangChain 这类框架下，这种感觉会尤其强烈。原因主要有两个。

第一，工程化的碎片极多。现在做 Agent 开发，80% 的精力都在处理 ChatPromptTemplate 的格式化、OutputParser 的解析逻辑、Memory 的上下文维护、Runnable 的链路拼装。这些工作和处理数据库连接池、管理事务、封装 DAO 层没有本质区别，都是繁琐的工程细节，只是套了一层 AI 的外壳。

第二，大多数"Agent"其实只是语义路由器。用户问 A，调工具 A，返回结果。整个流程是线性的、确定性的，和传统的请求-响应模式几乎相同。更直白地说，这种 Agent 不过是把原来的 if-else 路由，换成了"让 LLM 来决定调哪个函数"。能力边界没有变，只是路由逻辑的实现方式变了。

这种形态的 Agent 当然像 CRUD，因为它本来就没有超出 CRUD 的范畴。

真正让 Agent 和 CRUD 拉开距离的，是当任务本身无法被预先拆解、执行路径需要在运行时动态生成的时候。

真正的差异，出现在多步推理和自我纠错里

当任务变得复杂，无法用一次工具调用解决时，Agent 的价值才开始显现。

以"分析两家公司最近两个季度的财报并写一份竞争格局对比"为例，传统系统需要你预先设计好完整的工作流：先搜索 A 公司财报，再搜索 B 公司财报，提取关键数据，写入临时存储，最后调用生成模块输出结论。每一步的路径、每一步的数据格式，都要在代码里明确指定。

而用 ReAct（Reasoning + Acting）模式，模型可以自主循环规划和执行，不需要你把执行路径完全写死：

上图展示了 ReAct 循环的完整链路：模型接到复杂任务后，先动态拆解步骤，再进入"调用工具 → 观察结果 → 决定下一步"的循环，遇到失败时自动纠错调整策略，直到任务完成才退出。

这里有两个在传统 CRUD 里很难实现的能力，值得单独拆出来看。

动态规划，执行路径在运行时生成

传统系统里，你写代码时就要把所有执行路径确定下来。遇到没预见到的情况，系统要么报错，要么走 fallback。

Agent 里，模型可以根据上一步的结果，动态决定下一步做什么。搜索接口返回空数据？换个关键词再搜一次。第一家公司的财报在 PDF 里、第二家在网页上？模型会自己选合适的工具去读，不需要你提前为这种"格式不统一"的情况写分支处理。

执行路径是在推理过程中生长出来的，不是在编码时被预先铸造的。

错误自愈，异常不再是需要穷举的边界情况

当工具报错时，Agent 可以把错误信息读回上下文，自己判断是参数格式问题、权限问题还是业务逻辑问题，然后决定下一步策略。

typescript 复制代码

interface AgentMessage {
  role: "user" | "assistant" | "tool";
  content: string;
  tool_call_id?: string;
}

interface AgentState {
  messages: AgentMessage[];
  retryCount: number;
}

async function runReActLoop(
  initialMessages: AgentMessage[],
  maxRetries: number = 5,
): Promise<string> {
  const state: AgentState = {
    messages: [...initialMessages],
    retryCount: 0,
  };

  while (state.retryCount < maxRetries) {
    const response = await openai.chat.completions.create({
      model: "gpt-4.1",
      messages: state.messages,
      tools,
    });

    const message = response.choices[0].message;
    state.messages.push({
      role: "assistant",
      content: message.content ?? "",
    });

    if (!message.tool_calls || message.tool_calls.length === 0) {
      return message.content ?? "";
    }

    for (const toolCall of message.tool_calls) {
      try {
        const result = await executeTool(
          toolCall.function.name,
          JSON.parse(toolCall.function.arguments),
        );
        state.messages.push({
          role: "tool",
          tool_call_id: toolCall.id,
          content: JSON.stringify(result),
        });
      } catch (error) {
        // 把错误信息原样喂回给模型，让它自己决定怎么处理
        state.messages.push({
          role: "tool",
          tool_call_id: toolCall.id,
          content: `Error: ${(error as Error).message}`,
        });
        state.retryCount++;
      }
    }
  }

  throw new Error(`Agent 超过最大重试次数 ${maxRetries}`);
}

传统系统里要实现类似能力，需要提前把所有可能的错误类型都枚举出来，针对每种错误写对应的恢复逻辑。Agent 不需要------你只要把错误信息给到模型，它自己会推理出下一步。

这不是魔法，而是把"异常处理的决策逻辑"从代码迁移到了模型的推理能力上。

Agent 架构的三个层次

可以把目前的 Agent 开发用一个简单的分层来理解：

层次	形态	特征
语义路由层	Prompt + 单次工具调用	if-else 的 AI 替代品
动态执行层	ReAct 循环、多步规划	执行路径在运行时生成
自主代理层	多 Agent 协作、持久状态	接近"数字员工"形态

目前大多数 Agent 产品停留在第一层，少数进入第二层，真正做到第三层的极少。

停留在第一层的 Agent，很快会被更自动化的低代码平台取代，因为本质上它们就是把接口调用包了一层自然语言的壳。真正的门槛在于：

如何设计高质量的 RAG 检索流水线，让模型在推理时拿到足够准确的上下文，而不是把无关信息一股脑塞进去
如何构建高可靠的工具集，保证工具的输入输出契约稳定，减少模型在格式解析上消耗的额外推理
如何管理 Agent 的执行状态，让长程任务在中途中断后可以从断点恢复，而不是从头重来
如何设计多 Agent 的协作边界，让不同专长的子 Agent 各司其职，而不是把所有能力堆给一个 Agent

从 LangChain 到 LangGraph 的思维跃迁

如果你已经在用 LangChain，建议花时间研究一下 LangGraph。这不是简单的框架升级，而是一个思维模型的切换。

SequentialChain 的思路是：输入 → 步骤 A → 步骤 B → 输出。这个模型对线性任务很够用，但一旦遇到需要循环、分支、并行的场景，就会开始变扭曲。

LangGraph 把 Agent 看作一个有状态的图（Stateful Graph）。每个节点是一个处理单元，可以是 LLM 调用，也可以是工具执行，甚至是一个子 Agent；节点之间通过共享状态（State）传递数据，边可以是条件边，根据状态的值决定下一步跳到哪个节点。

typescript 复制代码

import { StateGraph, END } from "@langchain/langgraph";

interface GraphState {
  messages: AgentMessage[];
  planSteps: string[];
  currentStep: number;
  isComplete: boolean;
}

const graph = new StateGraph<GraphState>({
  channels: {
    messages: { reducer: (a, b) => [...a, ...b] },
    planSteps: { default: () => [] },
    currentStep: { default: () => 0 },
    isComplete: { default: () => false },
  },
});

graph.addNode("planner", plannerNode);
graph.addNode("executor", executorNode);
graph.addNode("evaluator", evaluatorNode);

graph.addConditionalEdges("evaluator", (state) => {
  if (state.isComplete) return END;
  if (state.currentStep >= state.planSteps.length) return "planner";
  return "executor";
});

graph.setEntryPoint("planner");

在这个模型下，你会发现自己在设计的不是"代码流程"，而是"决策拓扑"------哪些节点可以并行、哪些节点需要等待上游结果、失败时应该回溯到哪个检查点。这和传统的业务流程设计有相似之处，但多了一层：每个节点的行为可以由 LLM 的推理驱动，而不是硬编码的条件判断。

"Agent 开发是高级 CRUD"这个判断是对的。但停在这里，就像说"编程不过是操作内存"一样------技术上没错，却少了最关键的那层：你在这些机制之上，能搭出什么来。

CRUD 给你的是确定性和可控性，代价是所有路径都需要被预先设计。Agent 给你的是泛化能力和动态性，代价是不确定性和更高的调试难度。两者不是替代关系，而是在不同场景下各有优劣的工具。

真正难的不是"学会怎么调 API"，而是在一个充满不确定性的系统里，设计出足够可靠的架构，让模型的概率性能力在你能接受的误差范围内稳定运行。