01
WorkBuddy
交互 · 任务管理 · 意图理解
接收自然语言研究需求，理解目标和上下文，创建并管理研究任务，再调用 deepFlow Skill 将任务交给后端。
调用：LangGraph API →MyWorkflow · Research Flow
deepFlow
深度研究工作流
deepFlow 用于围绕特定主题开展深度研究与持续跟踪，并将研究任务、过程与结果组织成可以长期运行和持续积累的工作流。
当前方案以 WorkBuddy 为人机交互与任务管理入口，通过专用 Skill 调用自托管的 LangGraph API，由 LangGraph 编排研究流程，并按任务需要调用多个数据源、检索服务、分析模型及其他专业工具。
开发中
总体架构已确定
API、状态模型与工具集待实现
RESEARCH WORKFLOW
从提出研究问题，到获得持续生长的研究资产
交互、编排与执行彼此解耦。用户始终面对 WorkBuddy，复杂的任务拆解和工具协作则留在后端工作流中完成。
02
LangGraph
状态维护 · 研究流程编排
接收结构化任务，拆解研究步骤、维护运行状态、安排执行顺序，并根据上下文组织多轮工具调用。
输出：工具调用计划 →03
多途径工具
检索 · 验证 · 分析 · 执行
按研究计划调用数据源、搜索与检索服务、RAG/知识库、分析模型及其他专业工具，形成研究资料与阶段结果。
输出：资料、判断与研究结果任务状态、阶段进展与最终结果通过 API 回传至 WorkBuddy，用户继续在原交互入口查看和管理
RESPONSIBILITY BOUNDARIES
四层分工，让入口保持简单，让后端保持可编排
deepFlow 不把所有逻辑塞进一个 Skill。每一层只承担自己最稳定的职责，未来替换模型、数据源或执行工具时，不需要改写整条链路。
WorkBuddy
面向用户，负责意图理解、任务创建与管理，以及进度和结果呈现。
deepFlow Skill
整理和校验任务参数，调用后端 API，并将后端响应转换为 WorkBuddy 可使用的信息。
LangGraph API
承载任务状态、研究步骤与分支逻辑，决定何时以及如何调用不同研究能力。
Tools
执行具体检索、抓取、知识查询、分析与其他专业动作，并向编排层返回结果。
信息回传保持隐式。 WorkBuddy 是用户的主要工作台；LangGraph 和工具层应通过 API 暴露任务状态与结果，而不是要求用户直接进入后端系统操作。
RESEARCH MODES
既完成一次研究，也为下一次研究保留上下文
deepFlow 的价值不止是完成一次检索与总结。研究过程可以被记录、复用和继续，从而逐步支持长期主题跟踪与增量研究。
单次深度研究
围绕一个明确问题进行多途径检索、交叉验证、分析与综合，形成符合特定内容、格式和用途要求的研究产出。
持续跟踪研究
在已有成果基础上继续研究，关注新增资料与重要变化，并逐步形成可以持续更新和复用的研究资产。周期执行与增量识别机制将在后续状态模型中固化。
提出目标
拆解任务
多途径研究
综合与产出
沉淀为下一轮基线
DESIGN PRINCIPLES
一个面向长期研究的可演化工作流
现阶段先冻结边界和方向，再在真实任务中逐步确定 API、状态模型、工具路由与产出规范。
入口简单
用户主要与 WorkBuddy 交互，不需要理解或操作后端编排细节。
职责分离
Skill 负责适配，LangGraph 负责编排，工具负责执行具体研究动作。
工具可替换
搜索、数据源、模型与专业工具通过稳定接口接入，不与核心流程强绑定。
状态可追踪
长任务能够表达进度、阶段结果与最终状态，并为异常恢复留下空间。
研究可延续
既有成果成为后续研究的上下文与基线，让研究资产随运行持续增长。
人保留判断权
系统推进过程与执行工具调用，用户保留目标、关键判断和结果使用的决定权。
CURRENT STATUS
现在先把架构说清楚，再让实现从真实任务中生长
deepFlow 当前仍处于开发阶段。本页描述的是已经对齐的目标架构与职责边界，不代表所有后端能力都已经部署。
已经确定
WorkBuddy 作为人机交互与任务管理入口；专用 Skill 访问自托管 API；LangGraph 作为核心编排层；研究执行层允许组合多个数据源、检索服务、分析模型及专业工具；状态与结果最终回到 WorkBuddy。
下一阶段
随着首批真实研究任务进入开发，再逐步固化：