April 2026

当你开发 Agent 时，你在做什么？

从工程视角看三种 Agent 开发模式

Archived April 2026 Markdown source

Anthropic 在 2024 年底的 Building Effective Agents 里区分了 Workflow 和 Agent：Workflow 代码路径预定义；Agent 由 LLM 动态决定流程和工具调用。到了 2026 年，这条线正在模糊——大多数框架默认「workflow 外层 + ReAct agent 内层」。Workflow 和 Agent 正在融合，Agent 在吞噬 Workflow。

基于十几个产品和框架的源码调研（Claude Code、Codex、LangChain、LangGraph、Dify 等），从工程视角分析三种开发模式各自在做什么。

三种开发模式：

  1. 低代码平台——拖节点搭 workflow，门槛最低
  2. 通用 Agent（Single-Agent）——ReAct 循环自决一切
  3. 企业 Agent（Multi-Agent 编排）——workflow 编排多步骤，可控性优先

二、低代码平台上的 Agent 开发

门槛最低的一种。你不写代码——你在一个网页 UI 里拖节点、连线、配 prompt，搭出一个带 LLM 的业务 bot。

你在做什么：在扣子（Coze）、Dify 这类平台上，用可视化编辑器组装一个 workflow。典型的节点包括：开始节点、知识库检索、LLM 调用、条件分支、消息发送、结束节点。LLM 只是 workflow 里的一种节点——和「调一个 API」「查一个数据库」在流程上是平级的。

工程本质：这是一种可视化的 workflow 编排。对用户来说是"搭 Agent"，对平台来说是执行一张有向图。

平台背后的执行引擎

以 Dify 为例（我读了它的源码）：Dify 在 2024 年把执行引擎拆成了一个独立的 Python 包叫 graphon。它的执行模型是一个 queue-based worker pool——不是 DAG 拓扑排序，不是 Pregel BSP，而是一个 ready queue + 动态线程池 + 事件分发器。节点跑完之后，dispatcher 根据边的条件决定下一个节点入队。外部控制信号（比如用户点「停止」）通过 Redis 的 command channel 送达。

Dify 内置了 24 种节点类型：start、end、llm、knowledge_retrieval、if_else、code（沙箱执行）、http_request、tool、agent、loop、iteration、human_input……其中 agent 节点在 Dify 2.x 里是一个plugin RPC 边界——ReAct 循环不在 Dify 核心代码里跑，而是委托给一个外部的插件进程。这意味着不同的 agent 策略（ReAct、function calling、自定义）可以作为插件安装，不用改 Dify 核心。

节点之间的状态传递通过一个叫 VariablePool 的二级字典：variable_pool.get(["node_id", "output_key"])。弱类型，没有 schema 校验——下游节点拿到的是 raw value，类型不匹配只有运行时才能发现。

代表

  • 扣子 Coze（字节，2024-02 国内版上线）——国内大众认知度最高，深度绑定微信/QQ/飞书生态
  • Dify（开源，2023-04 创建，137k+ stars）——开发者和创业者的自部署选择

国内几乎所有大厂都有自己的版本：百度文心智能体平台、腾讯元器、阿里云百炼……产品名经常改，但工程本质都是同一套范式。

个人观察：对这一档的长期前景有点怀疑

Agent 编排平台本质上是低代码平台——只是这次的"代码"换成了「写一个调 LLM 的 workflow」。低代码平台在传统编程领域已经有几十年历史了（OutSystems、Mendix、钉钉宜搭），它们一直有一个根本矛盾：简单的需求用低代码足够，复杂的需求总会突破低代码的表达能力。

而这一档现在面临一个新变量：AI 写代码的能力本身在变强。如果有一天业务人员可以直接让 Coding Agent 帮自己写一个 Python 后端，那"让不写代码的人也能搭 agent"这个价值可能就被消解了。

当然这只是一种推演。但和传统低代码平台花了十几年才被质疑不同，Agent 编排平台面临的节奏可能快得多——2026 年可能就能看出走势，因为 Coding Agent 的能力提升速度远超传统软件工具的迭代周期。

三、通用 Agent 开发（Single-Agent）

为什么叫"通用 Agent"

这一类最早出现在 coding 场景——Claude Code、Cursor 是给开发者写代码用的,所以业界习惯叫它们「Coding Agent」。但它的底层架构——ReAct 循环 + 工具集 + sandbox——本身不限于 coding：

  • Claude Code 改代码 → coding 场景
  • Manus 在云端 VM 里做 PPT、画图表、写报告 → 通用任务
  • Claude Co-worker 帮你做研究、整理数据 → 通用任务

架构完全一样，只是工具集和 sandbox 范围不同。 2026 年的事实是：「Coding Agent」就是通用 Agent，"Coding"只是这个架构最先跑通的场景,不是它的边界。

个人观点：为什么通用 Agent 一定是 Coding Agent。 我认为这不只是一个市场观察,而是一个必然。Coding 是计算机的原生语言——就像一个通用的人一定要会说英语（因为英语是当前世界的通用交流语言），一个真正通用的 Agent 一定要会写代码,因为代码是操作计算机最直接、最精确、最强大的方式。你想让 Agent 分析数据？它可以写 Python。搭网站？写 HTML + JS。操作 API？写 curl。只要 Agent 能写代码,它就可以通过代码去做几乎任何事——代码本身就是那个万能 tool,不需要为每个场景预制专用工具。这也解释了为什么 Claude Code / Manus 可以从 coding 自然扩展到通用任务,而反过来不行——一个不会写代码的 Agent,本质上是一个被限制了表达能力的 Agent。

核心架构：ReAct 循环

这类产品的架构极其简单。核心就是一个循环：

while True:
    thought = LLM.think(context)      # 思考下一步做什么
    action = LLM.decide_tool(thought) # 决定调哪个工具
    if no action:
        break                          # 没有工具要调 → 任务完成
    result = execute(action)           # 执行工具
    context.append(result)             # 把结果加回上下文

这就是 2022 年 10 月 Yao et al. 在 ReAct 论文（arxiv:2210.03629）里提出的 Thought → Action → Observation 循环。2026 年最成功的 Agent 产品，用的还是这个最原始的循环——没有多 agent，没有 Plan 产物，没有复杂的 workflow 编排。

工具集也很简单：文件系统 + shell。Claude Code 能读取你本地任何文件、执行任何 shell 命令。Manus 的工具集加了一个浏览器。就这些。

上下文工程与记忆：真正的工程壁垒

如果 ReAct 循环这么简单，工程难度在哪里？答案是上下文管理。

LLM 的上下文窗口是有限的——一个长任务可能跑几十个循环，工具调用结果累积起来很快就会塞爆上下文。所有 Coding Agent 产品的核心工程挑战都是同一个：如何在几十步之后让 LLM 还能记得自己在干什么。

我读了六个 Coding Agent 产品的源码，它们的共同架构模式是分层压缩——旧的工具结果逐步被摘要化或截断，腾出空间给新的内容。具体的压缩策略各家不同（Claude Code 做了四层渐进压缩，Codex 是双路并行，Gemini CLI 有验证式压缩），但底层思路一致。记忆方面，几乎所有产品都选择了纯文本文件（CLAUDE.md、AGENTS.md、GEMINI.md）而不是数据库或向量检索——因为纯文本对 prompt cache 最友好。

这些上下文和记忆的工程细节，我在之前发过的《6 个主流 Agent 的上下文管理与记忆系统深度对比》和《Claude Code 为啥好用》两篇里做了源码级的展开分析，这里不重复了。

一句话：上下文工程是 Coding Agent 的第一工程挑战，不是 ReAct 循环本身。 循环谁都能写，但"跑 50 步之后还能保持连贯"——这才是区分产品质量的地方。

历史脉络

  • 2022-10：ReAct 论文发布，LangChain 同月诞生（晚 18 天）。但 GPT-3.5-turbo 的 API 到 2023-03 才开放，没人真用
  • 2023-03/04：GPT-4 发布后两周，AutoGPT 和 BabyAGI 同时爆红。有意思的是这两个爆款架构完全不同：AutoGPT 是 ReAct 风格的循环，BabyAGI 走的是 Plan-and-Execute 路线（三个子 agent + 任务队列）。两条路线从一开始就并行存在
  • 2024-03：Cognition 发布 Devin，重新定义了 Coding Agent 的产品形态
  • 2024 底 - 2025：Cursor、Claude Code、Codex CLI 相继成熟。模型够强之后，架构反而回到了最朴素的循环——没有多 agent，没有复杂 plan，就是 ReAct + 工具 + 上下文压缩
  • 2025-2026：Manus / Claude Co-worker 把同样的架构从本地 CLI 扩展到云端 sandbox，从 coding 扩展到通用任务

工程 insight

模型够强之后，架构反而回到最朴素的循环。 Coding Agent 的成功不是因为架构精巧，而是因为模型能力跨过了一个门槛——跨过之后，简单的 ReAct 循环就足以完成复杂任务，更复杂的架构反而成了负担。

四、企业/领域 Agent 开发（Multi-Agent 编排）

和第三类用一样的技术，但做不一样的选择

先澄清一件事：通用 Agent（§三）说的"Single-Agent"并不是说只有一个 LLM 在跑。Claude Code 也会 spawn 子 agent 去做特定子任务——但关键是，这些 sub-agent 的结果是汇报给主 agent，由主 agent 在 ReAct 循环里决定下一步做什么。主链路的控制权始终在一个 LLM 手里。

企业/领域 Agent 也用多个 agent，但谁在做调度不一样：

  • 通用 Agent：LLM 做协调者——主 agent 在 ReAct 循环里自决一切，sub-agent 只是它的工具
  • 企业 Agent：程序化 workflow 做协调者——一个确定性的代码路径（或可视化 workflow）决定先跑哪个 agent、再跑哪个、条件分支怎么走

这是两类最本质的架构差异。不在于"有没有多个 agent"，而在于"协调者是 LLM 还是代码"。

企业场景选程序化 workflow 做协调者，是因为业务需要可审计、可回滚、成本可预估——这些东西让 LLM 自己协调天然给不了。

核心架构共识："workflow outer + ReAct inner"

2025-2026 年，几乎所有代码框架都收敛到了同一个架构模式：

外层是一个 workflow（开发者定义），内层每个节点跑一个 ReAct agent。 不同框架对这个模式的实现不同：

  • Mastra（TypeScript）：.then() / .parallel() / .dowhile() 组合 workflow，每个 step 内部是 ReAct，默认 stepCountIs(5) 停止
  • Google ADK（Python）：SequentialAgent / LoopAgent / ParallelAgent 三种固定编排原语。底层执行循环是 while True: _run_one_step_async，没有默认步数限制
  • LangGraph（Python）：StateGraph + 条件边 + Send 动态扇出。底层是 Pregel BSP 引擎——这一点和其他框架不同，它原生支持 cycles，agent 循环直接表达为图的回边，不需要额外的 while loop 代码
  • Pydantic AI（Python）：固定的 4 节点图（UserPromptNode → ModelRequestNode → CallToolsNode → loop），每次 run 都是这同一张图。它的独特之处在于用 Python 泛型做类型传递——Agent[DepsT, OutputT] 的 OutputT 会从定义一路传到最终 result
  • AgentScope（阿里通义，Python）：ReActAgent 为核心 + 可选的 PlanNotebook sidecar。PlanNotebook 有真实的 Plan / SubTask Pydantic 数据模型，但执行依然是 ReAct——plan 的合规靠 prompt hint injection，不是代码强制

历史演化：代码框架最激烈的三年

这一档的历史比前两类都精彩。

2022-10：LangChain v1 诞生。 和 ReAct 论文同月出生（晚 18 天）。早期就是一个把 ReAct 循环变成 Python API 的库，有 9 种 AgentType（ZeroShotReact、OpenAIFunctions、StructuredChatReact……），本质上都是 ReAct 的不同 prompt 包装。

2023-05：LangChain 官方提出 Plan-and-Execute。 发了一篇博客推出 plan_and_execute 包。博客原话：

"User objectives are becoming more complex... The need for increasingly complex abilities and increased reliability are causing issues when working with most language models." —— LangChain, "Plan-and-Execute Agents", 2023-05-10

这是业界第一次官方讨论在 ReAct 之外探索另一种 agent 架构的可能性。

2023-2024：Multi-Agent 狂潮。 MetaGPT（DeepWisdom 团队，论文 2023-08，作者列表里甚至有 LSTM 发明人 Jürgen Schmidhuber）、AutoGen（Microsoft Research，2023-09 开源）、CrewAI（2023-11 开源，2024-10 商业化）相继涌现。它们的共同点：把 agent 从一个 LLM 在循环，变成多个 LLM 在互相对话。"AI team 协作比单 agent 强"成了 2024 年的业界想象。

2024-01：LangGraph 发布。 LangChain 推出 LangGraph，用 StateGraph 重写 agent。底层 Pregel BSP 引擎原生支持 cycles。早期主打 multi-agent subgraph 组合。

2025：Cognition + MAST 的质疑。 这一年发生了两件影响代码框架走向的事。

Multi-Agent Handoff 的工程陷阱

这个问题值得单独讲,因为我在源码级调研中发现所有主流框架几乎都踩了同一个坑。

当 agent A 需要调用 agent B 时，大多数框架的做法是：把 B 包装成一个 tool，A 调用这个 tool，拿到 B 的最终文本输出。B 的中间推理、工具调用历史、尝试过又放弃的路径——全部丢失。

  • Mastra：AgentTool 把 sub-agent 包装成 tool，只返回最终文本
  • CrewAI：DelegateWorkTool 返回 str，worker 的整个 ReAct trace 对 caller 不可见
  • Pydantic AI：默认的 agent delegation 模式同样丢失 sub-agent 的 message history

Google ADK 是我调研过的框架里唯一做对了这件事的：它的 transfer_to_agent 机制让 child agent 共享 parent 的 InvocationContext，child 的完整 trace 保留在 session 里。但它的另一个 API AgentTool 又回到了"只返回文本"的老路。

这就是 2025 年 6 月 Cognition 的 Walden Yan 在 Don't Build Multi-Agents 里说的那件事。他给了两条原则：

Principle 1: "Share context, share full agent traces" Principle 2: "Actions carry implicit decisions, and conflicting decisions carry bad results"

并用了一个具象的例子来解释——假设你让 multi-agent 系统做一个 Flappy Bird 克隆，planner 拆出两个 subtask：「做一个有绿水管和碰撞盒的滚动背景」和「做一只可以上下移动的鸟」。subtask 已经写得非常具体了——「绿水管」几乎就是 Flappy Bird 的视觉商标。但两个 subagent 各自一跑：一个做出 Super Mario Bros 风格的背景，另一个做出一只不像游戏素材、移动方式也完全不像 Flappy Bird 的鸟。两个 subagent 各自"完成了任务"，最后 combiner agent 只能硬着头皮拼在一起。

同期，Berkeley + Cornell 在 2025 年 3 月发了 MAST 论文（arxiv:2503.13657），用 150 条 trace 构建了 14 种 multi-agent 失败模式的 taxonomy，然后用 1600+ 条 trace 验证。一个关键发现：14 种失败模式里有 8 种属于「架构级」——不一定能靠换更聪明的模型解决。

这两份证据——Cognition 的 production 经验 + MAST 的定量数据——让业界开始重新审视"拆 agent 越多越好"这个假设。这场辩论现在还没有完全结束（CrewAI 这类框架依然有用户），但代码框架的设计天平在 2025 下半年明显开始往"单 agent + workflow 外层"一侧倾斜。

2025-10-22：LangChain 1.0 发布。 彻底重写为 LangGraph 的 wrapper。Classic 时代的所有老 API（9 种 AgentType、AgentExecutor、plan_and_execute）全部挪到 langchain-classic 兼容包。最值得玩味的是：连 create_react_agent 都被 deprecated 了，新的入口叫 create_agent——不带"react"这个词。

2022 年 10 月 LangChain 和 ReAct 论文同月诞生。三年后 LangChain 的终极 API 里不再提 ReAct 的名字——不是因为它被抛弃了，恰恰相反：它赢到了所有框架都默认是它，名字都不用再挂出来了。

工程 insight

§三 的通用 Agent 和 §四 的企业 Agent，本质区别就是 Single vs Multi。 一个选择不拆（一个大循环搞定），一个选择拆（workflow 编排多个步骤/agent）。2025 年之后代码框架的天平开始从"拆"往"不拆"一侧倾——但这是一个进行中的趋势，不是定论。在企业场景中，可审计、可回滚、成本可预估的需求依然存在，这些需求目前单靠 Single-Agent 的 ReAct 循环还给不了。

五、总结

时间线

年份 低代码平台 通用 Agent (Single) 企业 Agent (Multi / 代码框架)
2022-10 — ReAct 论文 LangChain v1
2023-03/04 — AutoGPT + BabyAGI —
2023-04 Dify 开源 — —
2023-05 — — LangChain Plan-and-Execute
2023-08/09 — — MetaGPT / AutoGen
2023-11 — — CrewAI 开源
2024-01 — — LangGraph
2024-02 扣子上线 — —
2024-03 — Devin —
2024 底 — Claude Code / Cursor 成熟 —
2025-03 — — MAST 论文
2025-06 — — Cognition "Don't Build Multi-Agents"
2025-10 — — LangChain 1.0 (create_react_agent deprecated)
2025-2026 — Manus / Claude Co-worker —

2025 年的转折

2025 年是代码框架演化的一个转折点。Anthropic 在 2024 年底给了 Workflow vs Agent 的通用定义，Cognition 从 production 经验角度质疑了 multi-agent 的可靠性，MAST 论文从学术数据角度提供了量化证据。

这三件事加起来给了业界一个值得认真对待的观点：multi-agent 系统的不稳定不一定来自模型能力，可能来自架构本身。但需要说明的是，这个观点目前并没有成为定论——CrewAI 这类框架依然有用户，有它的适用场景。代码框架的趋势在转向，但不是所有人都在同一条船上。

Agent 和 Workflow 的趋同

一个值得关注的趋势是 Agent 和 Workflow 正在融合。Mastra 外层是 workflow DAG、内层每个节点跑 ReAct。扣子/Dify 是 workflow 编排平台，但 LLM 节点又允许 agent 式的工具调用。Claude Code 看起来是纯 Agent，但你给它一个 todo.md 让它按列表执行，它就在跑一个隐式的 workflow。

大部分 2026 年的 Agent 产品，都落在"纯 Agent"和"纯 Workflow"的光谱中间。

个人观点：任何精妙的编排设计都在限制模型的上限

从我自己的经验看，我倾向于一个判断：如果你的任务需要足够的灵活度，那么当模型足够聪明之后，你永远应该选择 ReAct 这种足够灵活的框架，而不是预先给它套上编排。

原因很简单——预先制定的 workflow，无论是外部的可视化编排还是内部的代码 DAG，都在限制能力的上限。你画好的流程图只能覆盖你预见到的路径；而一个足够聪明的 LLM 在 ReAct 循环里，可以走出你没预见到的路径。编排给你的是确定性，代价是丢掉了模型本来可以发挥的灵活性。

当然，这个判断有两个前提：

  1. 你需要的是通用能力——你的任务足够开放、足够多变，不能被一个固定流程覆盖
  2. 你能接受不确定性——在企业级场景下，过于通用可能会影响稳定性，也可能收不住成本。当业务需要可审计、可预估、可回滚时，编排的"限制"恰恰是它的价值

所以这不是一个「哪个更好」的问题，而是一个场景匹配问题。但如果你问我个人的赌注压在哪边——我赌模型会越来越聪明，编排的必要性会越来越小。

六、结尾

三种 Agent 开发模式，三个 one-liner：

  • 低代码平台：给非开发者的可视化 workflow 编辑器。工程本质是图执行引擎 + LLM 节点
  • 通用 Agent：一个 LLM 在 ReAct 循环里自决一切。工程壁垒在上下文压缩，不在循环本身
  • 企业 Agent：用 workflow 编排多个 agent 步骤。和通用 Agent 用一样的技术，但选择拆——而拆不拆这件事，2025 年以来一直在被辩论

续集预告

这篇博客讲的是三种 Agent 开发模式各自长什么样。但有一个灰色地带这次没展开——某些生产场景里，通用 Agent 的 ReAct 循环给不了成本预估和审计追溯，企业 Agent 的 multi-agent 编排又有 Cognition 指出的 handoff 问题。

人们在这个灰色地带做了一些介于两者之间的东西——比如 Plan-and-Execute 架构。它既不是纯 Single-Agent，也不是传统的 Multi-Agent workflow，而是另一种东西。

下一篇我聊这个灰色地带，以及为什么我自己做的生产 Agent 系统在这里。