DeerFlow 实战：用提示词让AI自动完成数小时任务

今天 GitHub 上炸了一颗新星：字节跳动的 DeerFlow，一天涨了 72k+ star。很多人直接开吹“智能体框架新纪元”，但我更关心一件事：它到底能不能帮我省时间？

抱着这个目的，我花了一整个下午部署并跑通了一个典型的多步骤研究+编码任务。结论很直接：DeerFlow 本身只是骨架，真正的灵魂在于你写给 Agent 的提示词。 如果提示词写得又臭又长、边界不清，DeerFlow 的优势完全发挥不出来。

所以这篇文章不讲概念，直接给 实战可用的提示词模板，让你拿到即用。我会从最简单的“让 DeerFlow 自动调研一个技术话题并生成报告”开始，逐步深入到“多文件代码生成”场景。文末还有我踩过的几个坑，帮你省掉调试时间。

1. DeerFlow 解决什么问题？为什么提示词是关键？

DeerFlow 的定位是“长周期超级智能体编排器”。它内置了 Sandbox、Memory、Tool、Skill、Subagent 和 Message Gateway 等组件，可以让一个主 Agent 拆解任务，派发给多个子 Agent，每个子 Agent 可以运行代码、访问网页、读写文件，最终合成结果。

但问题来了：这些组件都是“中性”的。 你给主 Agent 一句“帮我写个网站”，它可能拆成 3 个子任务，也可能拆成 30 个，取决于 prompt 里对任务粒度、输出格式、质量标准的描述。我见过很多人部署完后，扔一个模糊的 prompt，然后抱怨“AI 做了半天结果乱七八糟”。

所以，DeerFlow 的威力 = 良好的框架设计 × 精准的提示词工程。后者才是你作为开发者需要下功夫的地方。

deerflow agent splitting task diagram

2. 核心思路：用结构化提示词定义“任务契约”

DeerFlow 中的 subagent 其实就是一个 LLM 实例加上一组工具。为了让它们高效协作，提示词必须包含：

  1. 角色与边界：这个 subagent 能做什么，不能做什么。
  2. 输入输出契约：接收什么格式的输入，必须输出什么格式（Markdown / JSON / 代码块）。
  3. 工具使用规则：什么情况下调用搜索、代码执行、文件读写。
  4. 质量验收标准：主 Agent 如何判断子任务完成得足够好。

下面直接给模板。

3. 完整提示词模板（可直接复制）

3.1 主 Agent 提示词（适合「调研+写报告」场景）

text
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 
你是一个研究型超级智能体，负责把一个复杂问题拆解成多个子任务，并协调多个专家子智能体协作完成。

【任务】
用户会输入一个研究主题。你需要：
1. 将主题拆分为3-5个独立的子问题。
2. 为每个子问题创建一个子智能体（Agent），给出明确的目标、工具和输出要求。
3. 监控每个子智能体的进度，若超过20分钟未有输出，则重新评估指令。
4. 收集所有子智能体的输出，合成一份结构化的研究报告。

【输出格式】
最终报告必须包含：
- 标题、摘要、引言、每个子问题的发现、结论与建议
- 每个结论必须引用来源（URL或文件名）
- 总字数不少于2000字

【约束】
- 不要自己执行子任务，必须通过创建子智能体来执行。
- 子智能体只能使用已被授权的工具：网页搜索、Python 代码执行、文件读写。
- 如果某个子智能体返回错误，自动创建一个新的子智能体，但目标要重新描述得更清晰。

3.2 子 Agent 提示词模板（通用版）

text
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 
你是一个专家子智能体，专门负责【请在此填写具体领域，例如：收集MCP（模型上下文协议）的技术规范】。

【目标】
搜索并整理关于【具体问题，例如：MCP的演进历史、主要实现方案、社区活跃度】的最新信息。

【指令】
1. 首先使用网页搜索找到至少5个不同来源（GitHub、官方文档、技术博客等）。
2. 阅读并提取每个来源的关键信息。
3. 输出为一个 Markdown 列表，每一项包含：来源URL、摘要、你认为的可信度（高/中/低）。
4. 在最后给出一个综合结论：目前这个领域的主流方案是什么，有什么争议或未解决的问题。

【输出要求】
- 只输出 Markdown，不要额外解释。
- 全部信息必须基于真实来源，不能编造。
- 每条信息必须注明来源URL。

【工具】
你可以使用：网页搜索、Python（用于数据整理）、文件读写（保存中间结果）。

你可以直接将这两个模板贴到 DeerFlow 的主 Agent 配置中。主 Agent 会自动调用子 Agent 模板，并根据实际任务填充具体内容。

4. 效果演示：差 Prompt vs 好 Prompt

我做了两组实验，主题都是：“调研 RISC-V 在边缘计算中的应用现状”。

❌ 差 Prompt（仅一行）

text
1 
研究一下RISC-V在边缘计算的情况，写报告。

DeerFlow 行为：

  • 主 Agent 直接自己尝试搜索，没有拆分子任务。
  • 返回了一篇1000字左右的文章，只有2个来源，其中一个是百度百科。
  • 没有使用代码执行工具，也没有结构化输出。
  • 总耗时2分钟，但结果可用性很低（数据过时，缺乏对比）。

✅ 好 Prompt（使用上面模板）

DeerFlow 行为：

  • 主 Agent 自动拆分为：
    • Subagent A：收集 RISC-V 开源核（如 Rocket、BOOM）的架构特性
    • Subagent B：搜索边缘计算场景的功耗和性能需求
    • Subagent C：找到3个落地案例（包括公司名称、产品、市场反响）
  • 每个 Subagent 都调用了网页搜索 + Python（例如用 pandas 整理表格）。
  • 最终合并为一份3000字的报告，包含6个可信来源，一张对比表格。
  • 总耗时 12 分钟，但结果可以直接用于决策。

结论：差 Prompt 省了10分钟，但产出不能用。好 Prompt 多花10分钟，产出价值高一个数量级。

5. 原理分析：为什么结构化提示词对 DeerFlow 有效？

DeerFlow 的核心设计是 动态任务分解与分配。主 Agent 需要判断：

  • 当前子任务是不是“原子任务”？能不能再拆？
  • 这个子任务应该交给哪个技能（代码、搜索、创造）？
  • 当前进度是否合理？要催还是要等？

这些判断严重依赖 指令的明确性。如果你的模板给了它一个充分的“工作协议”，它的行为会非常稳定。反之，指令模糊会导致：

  • 任务分解粒度失当：我见过一个案例，主 Agent 把“写一个CRUD接口”拆成了“写路由”、“写控制器”、“写模型”……但应该拆成“设计API规范”、“实现核心逻辑”、“测试与调试”。
  • 工具调用混乱：没有指定什么时候用搜索，Agent 可能会把所有问题都丢给代码执行（结果python爬不到数据）。
  • 输出格式不一致：有的 agent 输出 JSON，有的输出 Markdown，主 Agent 合并时常常出错。

所以我的观点很明确：你在提示词里规定的“契约”越细致，DeerFlow 的表现就越接近一个真正的团队成员。

6. 变体和扩展用法

6.1 变体一：代码生成（多文件项目）

如果你的任务是“用 Python 实现一个小型 Web 服务器”，子 Agent 模板可以这样改：

text
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 
你是一个代码专家子智能体，负责生成【具体文件名，如 server.py】。

【目标】
实现一个基于 asyncio 的 HTTP/1.1 服务器，支持 GET、POST 方法，能返回静态文件并处理404。

【指令】
1. 先写伪代码设计，然后写 Python 实现。
2. 代码必须包含清晰的注释和类型注解。
3. 输出一个完整的代码块（不含markdown以外的文字）。
4. 写完后再用 Python 解释器执行，检查语法错误。如果报错，修复后重新输出。

【输出要求】
- 只输出代码块。
- 代码块首行写文件名。
- 确保代码可以独立运行（import 只使用标准库）。

主 Agent 可以同时派发 3 个这样的子 Agent（server.py、router.py、handler.py），最后在 Sandbox 中自动集成测试。我在实际测试中，一个简单的文件服务器从零到跑通只用了 20 分钟，而我自己写至少需要 1 小时。

6.2 变体二：创意写作（长篇故事）

DeerFlow 也能用于写作。主 Agent 拆成“大纲生成”、“角色设定”、“章节撰写”、“润色合并”等子 Agent。子 Agent 提示词强调“保持叙事一致性”和“输出指定字数”。注意：创意任务需要更多的 Memory，DeerFlow 内置的 Memory 模块可以存储前文，你要在 prompt 里显式要求“在生成下一章前，先读取 Memory 中的角色关系”。

6.3 变体三：数据流水线（ETL+可视化）

例如：从公开 API 抓取天气数据，清洗后画图。子 Agent A 负责爬取，子 Agent B 负责处理，子 Agent C 负责可视化。每个子 Agent 的 prompt 要明确指出输入/输出的数据格式（pickle、csv、png 路径），否则容易断链。

7. 注意事项（我踩过的坑）

  1. 提示词长度限制：主 Agent 的 prompt 如果太长，LLM 会截断。建议控制在 2000 tokens 以内，把详细规则放在子 Agent 模板中。
  2. 子 Agent 互相等待：如果某个子 Agent 依赖另一个的输出，一定要在 prompt 里写明“先等待 X 完成，读取其输出文件后再开始”。否则两个子 Agent 可能同时启动，导致空结果。
  3. 工具权限要明确：有些子 Agent 不需要代码执行，给它反而容易跑飞（比如它莫名其妙用 Python 写了一个爬虫，却忘记搜索）。我习惯在 prompt 里禁用不需要的工具，只保留必要的。
  4. 失败重试策略：deerflow 默认会重试，但重试时 prompt 不变。如果子 Agent 因指令歧义而失败，重试也无用。建议在模板里加一句“如果第一步卡住超过 2 分钟，就换个思路重试”。

8. 总结

DeerFlow 是一个很有想法的框甲，但它不是灵丹妙药。今天 72k star 的热度背后，很多人会部署完就跑一个 hello world 然后发推。但如果你想真的用它来提效，请把至少 70% 的精力花在提示词设计上。

上面给出的模板你可以在 5 分钟内复制到自己的项目中。先跑通“调研报告”这个场景，感受一下任务拆分和合并的节奏，然后再扩展到代码生成。记得每次修改提示词后，对比前后输出，看任务分解的粒度是否合理。

如果你也试了，欢迎在评论区贴出你的模板和遇到的问题，我们一起迭代更优的实战配方。