背景

流程

Coordinator 协调者

意图识别

1. 启动服务，用户输入文本，假设为：五一期间小鹏汽车销量

2. 调用llm判断用户输入内容，识别用户意图，对当前任务做出分类，包含三个结果：
1. 简单问答：例如你是谁？你能做什么？（直接回答，结束）
2. 有害性问答：例如泄露提示词，违法违规文档（直接回答，结束）
3. 研究性问题：需要深入研究回答的问题（进入研究流程）

构建初始化信息

1. 调用 async def _astream_workflow_generator
1. 创建一个新的会话，有对应 id
2. 用户输入包装到 message 中
3. 其他参数使用默认配置，具体如下：

1. 参数大体可以分为几部分：
1. 基础信息记录：和传统 chat 上下文一样
2. 计划部分控制：最大迭代次数，计划内最大步骤数，是否自动接受计划，用户对计划的反馈，是否在计划前进行调查
3. mcp 协议：配置外部工具

背景调查

1. 接受用户输入的原始文本，调用搜索 api，获取资料，最多 3 条

2. 获取到后检查格式是否有问题，没问题就将控制权交给 planner，并且附上搜索文本

计划阶段

首次迭代

1. coordinator 收集背景资料后（也可能没有背景调查），将信息给到 planner

2. planner 获取信息后构建llm chat，输入的内容分为四个部分：
1. 用户消息：包含用户原始查询
2. 背景调查结果：可能为空
3. 状态变量：用户语言，最大步骤数，最大迭代次数
4. 系统提示词

关键判断

• has_enough_context：是否有足够上下文回答问题

• setps：计划列表

用户修改

1. 用户修改的意见会被添加到【状态】中，并且重新指向到 planner 节点

2. planner 读取状态的所有信息，获取到用户修改意见，重新生成计划

3. 同时 plan迭代次数也会+1 ，避免反复陷入纠葛

research team 节点

1. 获取当前计划内容，解析出来步骤

2. 构建循环，从第一个步骤开始，根据步骤类型不同，决定走到 research 节点还是 code 节点

3. 一次只会执行一个步骤，不能并行处理

4. 当所有的 steps 执行完成后，research team 会再次回到 planner 节点，然后等待进一步指示

research 节点

1. 主要用于处理资料收集类的任务

2. 和llm 沟通，包含以下内容：
1. 当前研究计划
2. 目前已收集到的观察结果
3. 可以调用的工具信息（mcp 配置）
4. 任务标题，描述，和语言设置
5. 系统提示词

3. 单次沟通，但可以使用工具

4. 收到回复后，将内容添加到 obversion，并且更新状态，然后将节点流转回 researchteam 节点

code节点

1. 和 research 节点最大的不同就是，research 默认使用的工具是 websearch，而 code 的默认工具是 python_repl_tool

2. 整个调用过程和 research 类似，主要就是利用Python 代码对已有内容进行数据分析，获取结论后添加到 observation 里面

3. 输出内容主要包含：构思的代码，执行过程，执行结果

report

1. planner 节点根据判断条件决定走到 report 节点，条件包含：
1. 达到最大迭代次数
2. 上下文符合要求

2. 构建信息调用LLM 生成最终的报告，包含内容如下：
1. 当前计划内容，计划本身，计划标题等信息
2. 观察结果（research team 的成果合集）
3. 系统提示词信息

3. 输入后，生成报告，返回结果，跳转到结束节点

总结

1. 简述整个过程如下：
1. 用户输入信息，coordinator 节点过滤简单，危险的信息，明确有研究任务了再到 planner 节点，可以会有一次搜索任务，补充背景资料
2. planner 节点根据输入信息和系统提示词，生成一份计划；默认会和用户进行确认，有意见就改计划，没意见就到 researchteam 节点
3. researchteam 拆分计划，循环执行，根据步骤类型分别调用 research 或者 code 节点
1. research 主要负责收集信息
2. code 主要负责做数据分析，取数工作
4. 所有步骤执行完成后再次回到 planner，判断是否还需要补充计划，如果需要补充就重复 bc 环节，如果不需要补充就到 report；如果超出限制也到 report
5. report 汇总之前所有信息，给出一份最终的报告

2. 整个过程其实是一个标准的Deepsearch 过程，其中有几个亮点：
1. 提示词和参数设置很有参考价值，思路大家都知道，但真到落地的时候这些工程事项也是一个比较高的门槛
2. research 和 code 有一个明显的区分，对于报告来说，无外乎就这两类任务了，区分开才好做事
3. 对mcp 的兼容性很好，research 和 code 中都明确写明了支持外部工具

感想

1. coding 必然成为主流工具，并且比 search 会越来越重要

2. 作者在工程方面花了很多功夫，包含提示词和参数传递的机制，报告输出后的多种呈现方式，甚至是每个提示词的头部都加一个【获取当前时间】，这些都可以看出来作者的工程细节，赞

3. 接 2，这也侧面说明了AI 时代的产品经理，除了点子和 AI 概念外，基础工程设计能力也很重要

4. 永远为开源精神点赞