> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # DeepFlow：可组合智能体框架 - URL: https://www.hubwiz.com/blog/deepflow-a-composable-agent-framework/ - Published: 2026-03-18T03:19:01.000Z - Updated: 2026-03-18T03:19:01.000Z - Description: AutoGen vs. LangGraph vs. CrewAI vs. 字节跳动的DeerFlow vs. Anthropic——以及一个金融Agent来证明，可组合的基础设施最重要。 - Author: admin - Tags: AGENT, #Import 2026-10-14 14:41 Andrej Karpathy最近组建了八AI Agent作为研究团队，每个Agent配备独立的GPU，自主运行机器学习实验。他的结论是："这不work，简直一团糟。" 不是因为这些Agent不会编程。他描述的任何东西它们都能实现。问题出在其他方面：没有基线，没有对照实验，一个Agent"发现"把网络做大能改善损失——这个结果任何一年级博士生都能注意到。 但他对问题的阐述让我印象深刻： > 你现在在编程一个组织……源代码是由提示词、技能、工具和流程组成的集合。 这改变了问题本身。问题不在于更智能的Agent，而在于围绕它们的更好的基础设施：它们如何加载能力、管理上下文、持久化状态，以及如何在彼此的令牌海洋中协调而不被淹没。当基础设施出错时，你会看到AutoGen Agent花三个小时在循环中重复添加同一个逗号，或者每天2000美元的费用账单——因为Agent递归调用自己却没有终止开关。 在为一个对合规敏感的研究管道分析五个框架之后，我得出一个论点： **可组合基础设施优于单体框架。**渐进式技能加载、模块化中间件和文件系统优先的状态管理不是特性，而是可扩展的架构。 以下是原因，以及在这个基础上构建金融研究Agent是什么样子。 ## 1、五种哲学，5分钟速览 五个框架，五种对Agent应该如何协调的押注。差异不在于特性，而在于每个框架在哪里崩溃。 > **AutoGen押注于对话。** Agent通过GroupChatManager相互交谈，广播消息并选择下一个发言者。对演示很直观。规模化就很残酷。 数学告诉你为什么。四个Agent交换20条消息意味着每个Agent在每一轮都要处理所有20条消息。这是每轮80条消息读取。每条消息约500令牌，在任何Agent做实际工作之前，一轮就烧掉了40000个输入令牌。 链接五轮，你就只在协调开销上花费了200000个令牌。按Sonnet的费率，每任务约0.60美元——仅仅是为了Agent互相读取邮件。 这个项目也分裂了。原始创建者分叉到AG2，微软将核心重写为v0.4，然后将其与Semantic Kernel合并到微软Agent框架中。如果你在2024年开始在AutoGen上构建，现在你面对着三个API各不相同的代码库，没有清晰的迁移路径。这是治理风险，不只是技术风险。 > **LangGraph押注于图。** 带有节点、边和条件路由的有向状态机。你精确定义哪个Agent何时运行，以及传递什么状态。每个节点转换时的检查点给你暂停、恢复、回放和时间旅行调试的能力。 代价是样板代码。一个带条件路由、状态模式和检查点的基本两Agent管道在第一个Agent做任何有用的事之前就需要200多行设置。而且当你重构图时，状态模式随之改变。现有的检查点失效。控制是真实的，僵硬也是。 > **CrewAI押注于角色。** 给每个Agent角色、目标和背景故事，然后让它们自己弄清楚。从想法到可工作演示的最快路径，大概30行代码。 文档没有强调的是：基于角色的委托是非确定性的。同一个输入在不同的运行中可能路由到不同的Agent，取决于LLM对"谁应该处理这个"的解释。这就是为什么CrewAI不得不在生产团队持续遇到不可预测的行为后强加Flows（确定性事件驱动管道）。 他们自己在20亿工作流上的博客文章说得直白：从100%人工审查开始，逐步降低到50%。这不是最佳实践。这是对自主角色委托没有护栏就无法安全投入生产的坦承。 > **DeerFlow押注于可组合基础设施。** 它不定义Agent如何交谈，而是定义它们如何加载能力、处理上下文和持久化状态。一个9中间件管道包装每个LLM调用。技能渐进加载（先元数据，只有触发时才加载完整指令）。状态存在磁盘上，而不是令牌中。 Agent协调层在LangGraph之上，但真正的架构是中间件。它也是这里最新的框架（2026年2月），意味着中间件抽象很干净但实战考验还不足。 > **Anthropic押注于无框架。** 六个可组合模式（提示链路由、分发、并行化、编排器-工作者）你自己连线。他们发布的立场是："最成功的实现不是使用复杂框架。" 优势是最大控制和零框架锁定。劣势是你要自己负责一切，包括框架为你处理的那些部分：状态持久化、错误恢复、Agent生命周期、上下文管理。对于拥有强大基础设施工程师的团队，这是解放。对于其他人，这是长达数月的绕道——在第一个Agent运行真实任务之前先搭建管道。 这这一切之下有一个频谱，生产正在强力拉向一端： **有趣的问题不是每个框架在这个线上的位置。而是在每个位置上你的上下文窗口会发生什么。** **这才是真正的差异化所在。**基于对话的协调（AutoGen、CrewAI Crews）把所有东西塞进共享上下文。每个Agent看到每条消息。 基于图的协调（LangGraph）选择性传递状态但仍然积累。可组合基础设施（DeerFlow）主动管理上下文：总结已完成的工作、卸载到磁盘、只在需要时加载技能。你在频谱上越往右走，每次决策的成本就越低。 ## 2、为什么可组合优于单体 "可组合"这个词被随意使用，让我具体一点。可组合Agent架构做三件事： **1.只加载你需要的。**大多数框架从一开始就把所有能力塞进Agent的上下文。每个工具描述、每个指令集、每个系统提示，无论Agent是否使用，都在燃烧令牌。 渐进式技能加载颠覆了这一点。将数十个技能存储为轻量级元数据（名称和单行描述，每个约100令牌）。只有当技能触发时才加载完整指令。重型资源（脚本、模板、参考文档）只在明确引用时才拉入。 差异是持图书卡 versus 持图书馆。称之为**图书卡原则**：索引一切，只加载你需要的。 **2.把状态存在磁盘上，而不是令牌中。**SEC的一份10-K文件就有60000到100000个令牌。把三份塞进共享Agent上下文，在Agent开始推理之前你就烧掉了180000到300000个输入令牌。 按Claude Sonnet每百万输入令牌3美元，每次调用不到一美元。还不算灾难性。但一个团队每天运行100个研究查询，光是原始文件上下文每天就要花费54到90美元——在任何实际分析令牌之前。我称之为**令牌税**：把应该存在磁盘上的数据存在上下文中的代价。 文件系统优先的状态管理修复这个问题。Agent读取文件，提取需要的内容，将摘要写入磁盘，然后释放原始令牌。下一个Agent读取摘要，而不是原始内容。上下文窗口持有工作记忆，而不是仓储数据。 **3.中间件作为模块化管道。**不要把上下文管理、内存、沙箱和总结烘焙到框架核心，而是将它们视为包装每个LLM调用的独立模块。长文档需要总结？插进去。不需要只读研究Agent的沙箱？省掉。每个中间件组件有单一职责，管道可按Agent、按任务配置。 为什么现在这比一年前更重要？因为模型在变便宜但上下文窗口越来越难以用好。GPT-4o的输入价格比GPT-4降了10倍。但*滥用*128K上下文窗口的成本一点没降。把无关上下文塞进去仍然降低输出质量，仍然增加延迟，仍然烧钱。更便宜的令牌让浪费更不明显，而不是更不真实。 单体框架隐藏了这个问题。它们给你一个大上下文窗口让你填。可组合基础设施强迫你问：这个令牌值得它的位置吗？ 这对于单个任务看起来是这样的："研究AAPL并产生投资备忘录。" ``` 单体（一切在上下文中）： 系统提示 + 指令: 2,000 令牌 40个技能定义（完整）: 40,000 令牌 10-K文件（原始文本）: 80,000 令牌 之前的对话历史: 15,000 令牌 ───────────────────────────────────────────────── 每次LLM调用输入: 137,000 令牌 × 12次调用/管道: 1,644,000 令牌 按$3/M输入: $4.93 可组合（渐进式 + 文件系统）: 系统提示 + 指令: 2,000 令牌 40个技能元数据（仅名称）: 4,000 令牌 1个活动技能主体: 1,500 令牌 磁盘上的结构化摘要: 3,000 令牌 ───────────────────────────────────────────────── 每次LLM调用输入: 10,500 令牌 × 12次调用/管道: 126,000 令牌 按$3/M输入: $0.38 ``` 每次运行便宜13倍。每天运行50个研究管道的团队用可组合基础设施每月支付约570美元，而单体每月约7400美元。随着技能增加差距扩大：每个新能力花费约100令牌（元数据）而不是约1000-2000令牌（完整定义）。 但成本甚至不是最有力的论据。质量才是。Anthropic和Google的研究都表明，随着上下文被无关信息填满，LLM准确性会下降。137000个令牌的输入中有120000个是未使用的技能描述和原始文件文本，不只是更贵。思考更差。 ## 3、DeerFlow架构：可组合在实践中如何工作 DeerFlow是字节跳动的开源Agent框架，2026年2月以MIT许可证发布。值得研究这个架构不是因为DeerFlow是"赢家"（它太新了，未经考验，不能这么叫），而是因为它是一个代码库中最清晰的可组合基础设施原则实现。把它当作参考架构，而不是推荐。 在底层，它是一个带有9个专门节点的LangGraph StateGraph。接收用户请求的领导Agent将它们分解为子任务，并根据StepType分类将每个路由到正确的子Agent类型（Researcher、Coder、Reporter或Analyst）。 子Agent隔离运行。每个通过task\_tool()生成为独立实例，有自己的上下文窗口和工作目录。它们向领导Agent报告结果，领导Agent综合并继续。 这是协调层。以下是可组合支柱出现的地方： #### 支柱1：渐进式技能加载 DeerFlow将能力组织成三个层级的技能： 数学很重要。假设你安装了40个技能。在第一层，那是约4000个令牌的元数据，始终存在。在一个加载一切的单体框架中，在Agent做任何事之前你就会燃烧40000到80000个令牌。按Claude Sonnet每百万输入令牌3美元，每次调用渐进式加载是0.012美元而单体是0.24美元。每天1000次Agent调用，那是12美元vs240美元。图书卡原则在工作。 #### 支柱2：文件系统优先状态 DeerFlow为每个会话强制执行目录结构： ``` /mnt/user-data/ ├── uploads/ ← 用户提供的文件 ├── workspace/ ← Agent工作目录（中间结果） └── outputs/ ← 最终交付物 ``` 这不只是组织。这是上下文管理策略。当子Agent完成10-K文件分析后，它将结构化发现写入/workspace/，SummarizationMiddleware压缩对话历史。下一个Agent读取摘要文件，而不是原始对话。已完成的工作移出上下文放到磁盘上。 结果是无论多少数据流经，多步骤管道中的上下文窗口保持精简。 #### 支柱3：中间件管道 这里变得具体了。DeerFlow中每个LLM调用通过可配置中间件栈。默认发货9个模块： 每个中间件运行before()钩子（预处理提示）和after()钩子（后处理响应）。你可以重新排序、禁用或编写自定义。 研究Agent可能优先SummarizationMiddleware和MemoryMiddleware。代码执行Agent可能优先SandboxMiddleware和ThreadDataMiddleware。 管道不是装饰性的。这是可组合架构实际存在的地方。Agent不需要知道总结如何工作。它不管理自己的内存。中间件处理它，不同任务获得不同中间件栈。 ## 4、用DeerFlow构建金融研究Agent 现在，让我们动手吧。假设你想要一个Agent，接收股票代码并产生投资研究报告：基本面、近期文件、新闻情绪、风险评估、同行比较。不是玩具演示。是你可以交给分析师作为起点的的东西。 这是你在DeerFlow中设计的方式。 #### Agent管道 四个Agent，一个管道，每个有清晰的范围： 领导Agent自己不做研究。它把"研究AAPL"分解为三个工作包：收集原始数据（Researcher）、运行定量分析（Analyst）、编撰最终报告（Reporter）。每个子Agent通过task\_tool()生成，有自己的上下文窗口，/workspace/下自己的工作目录，只有它需要的中间件。 #### 定义金融研究技能 这是渐进式加载发挥作用的地方。金融研究技能存在于SKILL.md文件中，包含所有三层： ``` # SKILL.md — financial-research ## 元数据（第一层，始终加载） name: financial-research description: SEC文件分析、财务比率计算、 同行比较、风险评分、投资备忘录生成 ## 主体（第二层，触发时加载） ### 研究程序 1. 从SEC EDGAR拉取最新10-K和10-Q 2. 提取关键财务：收入、利润率、现金流、债务比率 3. 与3-5个行业竞争对手运行同行比较 4. 风险因素评分：监管、集中度、宏观敞口 5. 标记与前一文件期间重大变化 ### 输出格式 - Analyst Agent消费的结构化JSON - 所有金额以百万美元计，比率保留两位小数 - 每个提取数据点的来源引用 ## 资源（第三层，引用时加载） - templates/investment-memo-template.md - scripts/ratio-calculator.py - reference/sector-classifications.json ``` 当领导Agent看到"研究AAPL"，它匹配第一层元数据。然后Researcher子Agent才加载第二层指令。比率计算器脚本只在Analyst实际需要运行计算时才加载。 其他40个安装的技能（代码审查、数据可视化、报告格式化）每个约100令牌，纹丝不动。 #### 中间件配置：此用例重要的是什么 不是每个中间件在每个任务上都值得它的权重。以下是金融研究重要的是什么： #### MCP服务器设置：连接金融数据 DeerFlow使用MCP（模型上下文协议）连接Agent到外部工具。对于金融研究，你会在conf.yaml中配置数据源： ``` mcp: servers: sec-edgar: transport: stdio command: "python" args: ["-m", "mcp_sec_edgar"] add_to_agents: ["researcher"] market-data: transport: streamable-http url: "http://localhost:8080/market" add_to_agents: ["researcher", "analyst"] news-sentiment: transport: stdio command: "python" args: ["-m", "mcp_news"] add_to_agents: ["researcher"] ``` add\_to\_agents字段是可组合的部分。Researcher获得SEC EDGAR和新闻工具。Analyst获得市场数据。Reporter两者都不获得。每个Agent的工具集匹配其工作，仅此而已。 #### 管道实际产生什么 Researcher将原始发现写入/workspace/aapl-research/： ``` /mnt/user-data/workspace/aapl-research/ ├── 10k-summary.json ← 提取的财务数据 ├── recent-news.json ← 情绪评分的文章 ├── peer-tickers.json ← 识别的可比公司 └── raw-filings/ ← 完整文本（归档，不在上下文中） ``` Analyst读取摘要（而不是原始文件），在沙箱环境中运行比率计算，并将分析写入同一工作空间。Reporter读取两者，应用第三层资源的备忘录模板，并将最终输出写入/outputs/。 在任何时候，任何Agent都不在上下文中持有完整10-K。SummarizationMiddleware在每个子任务完成后压缩。文件系统承载数据。上下文窗口承载思考。 ## 5、实践中什么会出问题 干净的架构不意味着干净的部署。以下是你实际构建时会出错的。 **总结丢弃关键信息。**SummarizationMiddleware将60000令牌的10-K压缩成3000令牌的摘要。这是95%的削减。总有东西被削减。 在金融文件中，"什么东西"通常是 buried risk factors、关联方交易或脚注中的或有负债。恰恰是投资分析最重要的细节。 修复不是更好的总结。是总结之前的结构化提取。运行第一轮拉取特定字段（收入细分、债务期限、风险因素、法律程序）到结构化JSON。然后总结叙述部分。结构化数据完全绕过总结直接上磁盘。 **外部数据源会限制你。**SEC EDGAR强制每秒10个请求。Yahoo Finance、Bloomberg API和新闻服务各有各的限制。一个天真的Agent管道同时生成三个子Agent hitting EDGAR会在几秒内被节流。 缓解在MCP服务器层面，而不是Agent层面。将速率限制和响应缓存构建到MCP服务器本身。Agent不需要知道速率限制。它们只看到更慢的响应。为文件添加TTL缓存（10-K一旦发布就不变），对你对同一公司的第二次研究运行几乎零外部API调用。 **Agent生成的计算没有 ground truth。**当你的Analyst Agent计算债务权益比率时，你怎么知道它是对的？它从摘要中拉取数字，而不是原始文件。它可能用总债务除以总权益，或长期债务除以股东权益。两者在某种定义下都"正确"，但产生不同数字。 在管道中构建断言检查。用磁盘上的结构化JSON在ratio-calculator.py中运行相同计算，然后与Agent的输出比较。如果差异超过1%，标记供人工审查。这是基本的模型验证，与SR 11-7（OCC的模型风险管理指南）背后的原则相同，应用于Agent输出。 **复杂实体的上下文溢出。**研究单一产品公司如Chipotle，管道运行干净。研究像伯克希尔哈撒韦这样有60+运营公司的企业集团，你的Researcher Agent在完成提取细分数据之前上下文窗口就满了。 架构答案是分解：将集团研究分解为每个有自己上下文窗口的按细分子任务。DeerFlow的task\_tool()支持这个，但你的技能定义需要检测多细分公司并相应路由。这个检测逻辑是你的问题，不是框架的。 ## 6、合规视角 大多数框架比较在开发者体验就停止了。但如果你在受监管行业工作，你的infosec团队的第一个问题不是"它能多快发货？"而是"代码在哪里执行？记录了什么？谁审查了输出？" 这些问题比任何技术限制更快杀死Agent部署。 **沙箱隔离："你的infosec团队能批准这个吗？"** CrewAI在与应用程序相同的Python进程中运行工具。没有隔离。有代码执行工具的Agent与你的应用有相同权限。 AutoGen提供可选Docker容器但不强制。DeerFlow提供三种沙箱模式（本地进程、Docker容器、Kubernetes pod），默认通过SandboxMiddleware路由代码执行。在银行里，这是概念验证与通过安全审查的生产部署之间的区别。 **审计追踪缺口："发生了什么，为什么？"** 基于对话的框架把决策埋藏在聊天日志中。当监管者问为什么你的Agent做了特定推荐，你要在数千条交织消息中挖掘试图重建推理链。 这不是假设的担忧。OCC Bulletin 2011-12和美联储SR 11-7为金融机构定义模型风险管理标准。做出或影响决策的Agent系统属于这些框架。 标准不是"我们记录了什么。"是可重现性：给定相同输入，你能证明系统产生相同路由决策和相同输出吗？ 基于对话的协调几乎不可能实现可重现性，因为Agent选择取决于LLM解释，而这是非确定性的。中间件管道生来是确定性的。相同输入，相同中间件栈，相同路由。 DeerFlow的中间件管道创建自然日志点。每个LLM调用通过相同栈。每个中间件可以发出结构化日志。文件系统优先模式意味着中间结果作为文件持久化，而不是临时上下文。 你可以从最终备忘录追踪建议，通过分析师计算、研究员发现，到原始源数据。这是审计追踪，而不是聊天记录。 **人在环中：从100%开始，向下努力。** CrewAI自己在20亿工作流上的经验教训博客说得直白：从100%人工审查开始，随着建立信心逐渐降低到50%。这正是合规团队的想法。 DeerFlow中的ClarificationMiddleware在Agent行动之前拦截模糊请求。结合领导Agent编排模式（一个Agent协调，人类在子Agent执行之前审查计划），你获得可审查的检查点，而不需要手动检测每一步。 对于在FINRA监管环境的团队，这直接映射到Rule 3110下的监督义务。生成投资研究的Agent需要与人类分析师相同的监督审查。问题不是是否有审查。是你的框架让审查架构上自然还是事后补救。 **成本治理：令牌作为预算线。** 文件系统优先的状态管理不只是性能模式。它是成本控制模式。当中间结果在磁盘上而不是上下文中时，你获得令牌支出的结构化上限。 SummarizationMiddleware主动压缩，而不是被动压缩。对于每天运行50个研究管道的团队，那是可预测的月度账单和来自LLM供应商的惊喜发票之间的区别。 ## 7、局限性 DeerFlow比我看过的任何其他都更好地实现了可组合架构。但这不意味着它可以无警告投入生产。 **没有发布的基准。** DeerFlow没有GAIA分数，没有SWE-bench结果。25000个GitHub星告诉你它流行。不告诉你它更好。 **子Agent隔离有利有弊。** 每个子Agent有自己的上下文窗口，防止污染但杀死实时协作。Researcher不能问Analyst"这个数据点看起来可疑吗？"整个协调通过领导Agent瓶颈。 **字节跳动依赖。** MIT许可，完全开源，但字节跳动工程师驱动路线图。比较LangGraph（LangChain资助公司支持）或CrewAI（企业客户的 Venture支持）。DeerFlow的可持续性故事还未写。 **令牌溢出仍然发生。** SummarizationMiddleware买的是喘息空间，不是解决方案。对于真正大规模的文件处理——数百文件，数千页——你仍然需要外部分块和检索。 ## 8、结束语 这篇文章不是"使用DeerFlow"。 但如果你考虑使用Agent框架，你可以考虑采用这三个支柱： **1.审计你的上下文窗口。** 在构建之前，测量你Agent的上下文中实际是什么。如果超过30%是未使用的工具描述或原始源文件，你在支付令牌税。 **2.尽早把状态移到磁盘。** 不要等到上下文溢出强迫它。从第一天设计文件系统优先。中间结果属于文件，而不是对话历史。 **3.让中间件显式。** 无论你使用DeerFlow的管道还是构建自己的，让上下文管理、总结和沙箱模块化且可按Agent配置。研究10-K文件的Agent不需要与写报告的Agent相同的中间件栈。 Karpathy是对的：你现在在编程一个组织。问题是你的组织源代码是一堆聊天消息还是一个可组合架构。 --- 原文链接: [5 Agent Frameworks. One Pattern Won.](https://levelup.gitconnected.com/5-agent-frameworks-one-pattern-won-54cc0eedf027?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处