面壁智能的团队前几天公开点赞了一个组合玩法用 GPT-6 来编排 MiniCPM5-2B在本地搭一只专门干研究活的智能体。乍一看是两家厂商互相捧场但等你真把它跑一遍就会发现这是在给过去一年吵翻天的大模型还是小模型之争画一个非常务实的句号——答案是都要。大模型管脑子小模型管手脚。我最近一直在折腾本地研究智能体LangGraph、Dify、n8n、自研 harness 都试过热搜里那些 gpt-6 astra 怎么用、workflow编排、deepseek harness 多个智能体编排我基本都踩过一遍。这篇就把云端编排 本地执行这套架构掰开揉碎讲清楚从设计思路到工具选型再到完整的搭建步骤和排坑经验一次性给你整理完。1. 先把这个组合拆明白GPT-6、MiniCPM5-2B、编排各负责什么1.1 四个关键词拼起来是一条完整的研究产线很多人看到这个标题第一反应是GPT-6 不是云端模型吗MiniCPM5-2B 不是本地小模型吗这俩怎么搭要理解这件事得先把标题里的四个词拆开看。GPT-6 在这里的角色不是回答问题的聊天机器人而是项目经理。它负责把一个大研究问题拆成一串可执行的小任务决定每个任务调哪个工具、把结果交给谁、什么时候收尾。MiniCPM5-2B 是面壁智能那条 MiniCPM 产品线里的新一代 2B 规模模型跑在本地——笔记本、小主机甚至手机端。它不负责思考宏大问题负责的是把这段本地文档读进去把网页正文提炼成三句话把这些条目归个类这种具体的脏活。编排指的是任务调度这件事谁先谁后、谁的输出是谁的输入、中间结果存在哪、失败了重试几次。你可以把它理解成一套工作流引擎只不过流程不是写死的而是大模型每一轮动态生成的。本地研究智能体是最终形态给它一个研究方向它自己查资料、读文档、提取关键信息、交叉验证、沉淀成一份结构化的研究笔记整个过程中敏感数据不出本机。四个词连起来就是一句话GPT-6 负责想MiniCPM5-2B 负责做编排负责派活最后得到的是一个能把研究任务从模糊想法推进到成稿的本地闭环。1.2 面壁智能这一赞其实是在给小模型正名很多人觉得面壁智能点赞 GPT-6是商业互吹但如果你一直关注这家公司的产品路线就会发现这一赞的本质是在给小模型正名。过去一年小模型被质疑最多的就是啥都干不好写代码不如大模型推理不如大模型聊天不如大模型。这个质疑本身没错但前提是把小模型放在独立完成一切的岗位上。而在编排架构里小模型根本不需要独立完成一切它只需要在明确指令下完成一个边界清晰的小任务然后把结果交回去。面壁智能自己反复讲过模型不是越大越好而是在合适的算力下达到合适的效果。这句话放在编排架构里特别好懂——2B 模型单机就能跑响应快、成本接近于零、数据不出门这些恰恰是大模型做不到的。所以当 GPT-6 这样的强规划模型出现时小模型不但没被淘汰反而因为有人替它想而变得特别能打。这套逻辑也回答了社区里一直在吵的问题既然 GPT-6 这种超大上下文模型都有了为什么还需要本地模型答案就是落地。研究型任务最怕两件事一是把你积累了多年的本地资料库整个传到云端二是每次跑长任务烧掉几百上千万的 token。本地模型做粗加工云端模型只做精规划成本和隐私两个问题同时缓解。2. 核心设计思路把研究任务拆成规划、执行、记忆三层2.1 编排层GPT-6 的动态工作流怎么设计先说编排层。研究智能体不同于简单的问答机器人问答是来一个问题答一个答案研究是给一个方向走完一整套流程。所以编排层的核心不是模型本身而是模型 工具 状态三个东西的组合。举个例子我让智能体做梳理 2025 年开源小模型的主流部署方案这个研究时GPT-6 拿到任务后生成的计划大致是这样拆成 5 个子方向模型选型、量化方案、推理框架、硬件门槛、社区案例。先对每个子方向做一轮网络检索拿到标题和摘要。挑出命中率高的 8~10 篇文章逐个抓正文交给本地模型提炼要点。把提炼出的要点按厂商和框架维度归并、去重、补齐冲突信息。最后合成一份带引用来源的研究报告。注意这个计划不是我写死的也不是模型随便列的而是 GPT-6 基于工具清单实时生成的。每完成一步它都会拿到上一步的实际结果继续往下推这就是动态编排和固定工作流的本质区别固定工作流是画好的流程图动态编排是模型在现场画流程图。顺带回答一下最近被问爆的 gpt-6 astra 怎么用。Astra 是 GPT-6 的多模态变体语音、图片、屏幕内容都能进。研究场景里你可以直接把一张图表截图扔给它让它把图表信息纳入研究计划。用法上和普通文本接口没有本质区别只是请求里多传多模态字段后面代码部分我会给出占位。设计编排层时我建议把三个状态分开管理任务状态做到哪一步了、上下文状态目前掌握了哪些事实、工具状态哪些工具可用、哪些失败过。GPT-6 的上下文里只放这三样东西的摘要不要把整个研究过程的所有原文都塞进去否则长任务跑到一半上下文就爆了。2.2 执行层MiniCPM5-2B 适合接哪些活不适合接哪些活执行层的设计原则是给模型划定边界。我在实践中整理了一张分诊表可以直接参考。适合交给 MiniCPM5-2B 的活本地文档解析PDF、Markdown、TXT 的正文提取与分段。单片段摘要给定 2000 字以内的文本输出 100 字以内的要点。实体与关键词抽取从文本里抽出人名、机构名、产品名、时间。分类打标把研究条目归入预设的类别标签。格式清洗把网页里的乱码、广告噪声、重复段落清掉。不适合交给它的活多步推理比如比较 A 方案和 B 方案的优劣并给出建议。需要全局信息综合的长文写作。任何需要调用外部工具的决策。这个边界为什么这么定因为 2B 模型的能力上限是真实的。它擅长小范围、明确指令、单一技能的工作不擅长开放探索。你非让它干规划级的活它会一本正经地编造来源但你让它把这段文字总结成三条要点它反而又快又稳。有一个关键实操细节执行层的输出格式一定要极简。我建议统一要求 MiniCPM5-2B 输出纯文本或非常轻量的 JSON别让它输出 Markdown 表格更别指望它自己决定格式。格式一旦复杂2B 模型很快就会乱。你可以在系统提示里写死只输出 JSON键名为 summary、entities、category整个执行层就变成了一个文本进、结构化文本出的翻译器后面接任何编排框架都不用改。2.3 记忆与上下文小模型装不下的东西交给向量库小模型上下文窗口有限这是你必须接受的事实。解决思路不是换大窗口模型而是把记忆外置。我的做法是在编排层和本地模型之间加一个轻量向量检索层。研究过程中的中间产物——网页摘要、文档片段、自己的笔记——全部先写入向量库每次给执行层的上下文不是全部资料而是根据当前子任务检索出来的 Top-K 片段。这样既保证执行层手头永远只有 1~3 段相关文本又保证关键信息不会在研究过程中丢失。这个设计还有个附带好处它可以给你展示研究轨迹。每一步用了哪些资料、提炼了什么结论都记录在案最后合成报告时能自动带上引用来源。对研究型智能体来说可追溯性和结论本身一样重要否则你根本不敢信它输出的东西。3. 工具选型Agent 框架和编排平台怎么选才不踩坑3.1 主流编排方案横向对比前面说的都是思路落到代码上就得选框架。我把这段时间实际跑过的几种方案放在一起对比你根据自己的技术底子选就行。方案适合人群上手难度动态编排能力扩展性我的评价LangGraph熟悉 Python 的开发者中强流程可以完全由模型动态生成高最灵活但代码量大状态机要自己维护Dify想快速出产品的团队低中偏向可视化固定流程中适合快速验证复杂动态编排偏吃力n8n偏自动化的运营或开发低中节点化触发中强在连接各类外部服务弱在让模型自由规划自研 harness想彻底掌控的进阶玩家高最强最高社区里那套 deepseek harness 多智能体编排就是这条路如果你问我怎么选第一次搭无脑从 Dify 开始。原因很简单它把模型调用、工具注册、节点编排做成了界面操作两小时就能跑通一个雏形。跑通之后你会自然遇到瓶颈这时候再迁移到 LangGraph 或自研 harness你已经有明确的痛点了不会乱选。社区里最近聊得很多的 deepseek harness 多个智能体编排本质就是自研路线。它在热搜里反复出现说明越来越多的人不满足于固定工作流想要一个总智能体动态调度多个子智能体的效果。这个方向我非常看好但建议你在没跑通单智能体之前先别上多智能体复杂度是指数级上升的。3.2 硬件门槛和本地模型部署选型很多人被本地模型四个字吓住以为要很贵的显卡。MiniCPM5-2B 这种规模的模型门槛其实比想象的低得多。只要你有 M 系列 Mac16GB 内存或 8GB 显存以上的 N 卡就能流畅跑。哪怕是纯 CPU 的老笔记本用 Q4 量化版本也能跑只是慢一点。部署工具首选 Ollama一条命令拉模型它会自动起一个 OpenAI 兼容的 API 服务端口默认 11434。面壁智能的模型通常第一时间支持 GGUF 格式。如果你在 Ollama 库里没找到现成标签就去 Hugging Face 下载 GGUF 文件用 ollama create 手动导入效果一样。这里多提醒一句本地执行模型的 API 地址和云端编排模型的 API 地址在代码里一定要分开配置。千万别图省事把两个 base_url 写成一个否则你会在不知不觉中把本地流量全打到云端隐私保护直接失效。这个坑我踩过后面还会具体说。4. 手把手搭建本地研究智能体的完整实现4.1 第一步把 MiniCPM5-2B 部署成本地服务先启动本地模型。假设你用 Ollamaollama pull minicpm5-2b ollama serve然后验证服务是否正常curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: minicpm5-2b, messages: [{role: user, content: 用一句话总结本地小模型适合做什么}] }看到正常的 JSON 响应就说明本地执行端已经就绪。这里注意两个参数temperature 建议设成 0.2 以下执行层要的是稳定输出不需要创造力max_tokens 根据任务长度设摘要类任务给 512 足够。如果你的机器有 GPU 且想追求更高吞吐可以换 vLLM 部署但 2B 模型在 Ollama 下已经足够快单路研究任务一般感知不到延迟没必要一开始就上重型方案。4.2 第二步接入 GPT-6 编排层并注册执行工具编排层的代码我用 Python 示例。核心思路是给 GPT-6 注册一个名叫 run_research_subtask 的工具这个工具的实现体是本地 MiniCPMfrom openai import OpenAI # 编排层GPT-6 planner OpenAI( base_urlhttps://your-gpt6-endpoint/v1, api_keyyour-key, ) # 执行层本地 MiniCPM5-2B executor OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, ) TOOLS [ { type: function, function: { name: run_research_subtask, description: 把单个研究子任务交给本地 MiniCPM5-2B 执行返回结构化结果, parameters: { type: object, properties: { task: {type: string, description: 子任务描述必须包含明确指令和期望输出}, context: {type: string, description: 需要处理的文本片段控制在 2000 字以内}, }, required: [task, context], }, }, }, ] def run_subtask(task: str, context: str) - str: resp executor.chat.completions.create( modelminicpm5-2b, messages[ {role: system, content: 你是研究助手只输出 JSON{\summary\: \...\, \entities\: [...], \category\: \...\}}, {role: user, content: f任务{task}\n\n文本{context}}, ], temperature0.2, max_tokens512, ) return resp.choices[0].message.content这个函数就是编排层和本地模型的握手协议。你会发现它刻意只暴露两个参数task 和 context。这是有意为之——参数越少GPT-6 越不容易在调用时犯错本地模型收到的指令也越干净。如果你用的是支持多模态输入的 Astra 接口只需在请求消息里额外加一个 image_url 字段把截图或文档图片传进去其他保持不变。编排层会自动把视觉信息纳入任务规划。4.3 第三步补齐研究工具搜索、解析、归档只有本地模型还不够研究智能体还需要看得见外部世界。我在实际项目里注册了四个工具web_search(query)调用搜索 API返回前 10 条标题、链接、摘要。fetch_page(url)抓取网页正文去掉导航和广告返回纯文本前 5000 字。run_research_subtask(task, context)即上一步的本地执行工具。save_note(title, content)把中间结论写入本地知识库Markdown 文件或向量库都行。这四件套覆盖了一条最小研究闭环搜索发现问题、抓取原文、本地提炼、归档沉淀。你可以把它理解成给智能体配了眼睛、手、大脑和笔记本。系统提示词我也给一份可以直接抄的模板它决定了 GPT-6 的编排风格你是本地研究智能体的总规划师。你的工作方式 1. 把用户的研究问题拆解成不超过 8 个子任务按依赖顺序排列。 2. 每个子任务必须指定使用的工具web_search/fetch_page/run_research_subtask/save_note。 3. 每完成一个子任务检查结果是否满足预期不满足就调整后重试最多重试 2 次。 4. 所有子任务完成后基于已归档的中间结论撰写最终研究报告并标注每条结论对应的来源。 5. 严禁编造来源。找不到的信息明确写未找到可靠来源。第五点特别重要。研究智能体和普通聊天机器人的最大区别就是真实性要求所以一定要在编排层把编造来源这条路堵死。4.4 第四步跑一次端到端研究任务看日志调流程我用一个测试任务来演示效果梳理 2B 规模开源模型在个人电脑上的部署方案。跑起来之后编排层的输出节奏大致是这样第一轮GPT-6 调用 web_search 拿到 10 条搜索结果。第二轮它挑出 5 篇看起来相关的文章逐个调用 fetch_page。第三轮每篇正文通过 run_research_subtask 传给本地模型本地模型返回简短的 summary 和 entities。第四轮GPT-6 检测到其中两篇内容高度重复调用 run_research_subtask 做了一次归并去重。第五轮调用 save_note 写入中间结论然后开始合成最终报告。整个流程看起来像有一个研究员在按部就班地干活只不过这个研究员的大脑是 GPT-6手脚是本地模型。你把每轮日志打出来看能清楚看到每个子任务的输入输出排查问题非常方便。这里有个值得注意的细节不要在编排层让 GPT-6 直接阅读全部网页正文。把正文交给本地模型提炼后再把摘要交回去这个先粗加工、再精加工的顺序能大幅节省云端 token。同样是 10 篇文章直接读全文可能烧掉几万 token先本地提炼可能只要几千 token效果反而更好因为本地模型先把噪声滤掉了一层。5. 实操中的典型问题与排查技巧实录5.1 本地模型上下文一长就输出乱码这是本地小模型最高频的问题。症状是给定大段文本后执行层的输出开始答非所问甚至蹦出无意义字符。排查思路很简单先看是不是把超过模型能力的文本塞进去了。2B 模型的有效上下文通常没有宣传窗口那么大喂到 90% 窗口就是找死。我的经验是单次调用控制在 1500~2500 字以内最稳超过就切块。切块之后还有个隐藏坑每个块独立总结会导致信息碎片化。所以我在编排层加了聚合阶段先让本地模型逐块输出要点再把这些要点汇总成一份清单交给 GPT-6 做最终综合。这就是典型的 map-reduce 模式研究型任务里非常实用。5.2 编排层生成假大空计划第一种情况是 GPT-6 抛出一堆模糊步骤比如深入研究相关主题。这种计划没有任何可执行性。原因通常是工具描述写得太笼统模型不知道每个工具能干嘛。解决方法是把工具描述当 API 文档写。我给 web_search 的描述是搜索公开网页返回标题/链接/摘要列表适合发现线索不适合精读给 run_research_subtask 的描述是把单段文本提炼为结构化 JSON适合精读与摘要。描述里写明工具边界模型才能排出靠谱计划。第二种情况是计划很具体但顺序错了比如先写报告再查资料。解决办法是强制在计划里标注依赖关系并在每轮执行前让模型看一眼当前已完成步骤清单。说白了要给编排层一块随时可以回顾的进度黑板。5.3 执行层输出格式漂移MiniCPM5-2B 有时会返回好的我来总结\n\n1. ...这样的文本而不是要求的 JSON。这不是模型坏了是它在遵循指令时不够稳定。我的对策分三层。第一层系统提示里只给一个格式示例不给多个示例越多它越容易选错。第二层解析时做容错用正则把 JSON 块提取出来而不是直接 json.loads。第三层如果连续两次解析失败就把这次结果标记为执行失败并回传给编排层让 GPT-6 决定是换个说法重新下指令还是直接跳过。记住一个原则执行层出错不可怕可怕的是出错后没有反馈回路。只要编排层能感知到这步结果不可用它就能自动修正。这也是编排架构比单模型硬刚更稳定的原因。5.4 性能与成本怎么同时调优本地模型几乎不花钱成本主要在编排层。我用三个手段把成本压到很低的水平。一是缓存。对完全相同的 context 重复调用的情况——比如多轮调试时——在本地做一个简单的 KV 缓存直接命中返回。实测能省掉 30% 以上的重复 token。二是分级路由。简单任务只调用本地模型比如这段文字分类本地就能干得很好根本不值得惊动 GPT-6。只有复杂规划、结果综合这类任务才走云端。一个研究任务跑下来云端 token 大多花在最后合成报告那一步中间大量粗加工全在本地消化。三是压缩中间上下文。前面说过喂给编排层的永远是摘要而不是原文。我发现把摘要控制在每条 100 字以内事实保留度最好代价又最低。超过 200 字的摘要GPT-6 的注意力就开始分散综合质量反而下降。6. 这套玩法还能往哪些方向延伸6.1 多智能体协作从一个执行者变成一支队伍单执行者版本跑通之后最自然的下一步是多智能体。思路还是那个GPT-6 当总指挥手下不再只有 MiniCPM5-2B 一个兵而是一批各有分工的本地模型。比如我对接过一套组合一个模型擅长文本摘要一个擅长代码审查一个专门做数据抽取。GPT-6 根据任务性质把活派给不同的执行者这就是社区里讨论度很高的 deepseek harness 多智能体编排模式。注意多智能体的复杂度主要在任务分配和结果冲突仲裁建议等单智能体稳定运行两周以上再动这个否则你连日志都看不懂。6.2 Dify 编排应用能不能当 Continue 的 API 用最近很多人问这个问题我直接给结论能但中间要包一层转换。Dify 工作流发布后确实会生成 API但它的接口格式是 Dify 自己的 /chat-messages不是 OpenAI 兼容格式。而 Continue 这类编程助手默认只对接 OpenAI 兼容接口。解法之一是用网关类工具把 Dify 注册成渠道统一暴露成 OpenAI 兼容的 /v1/chat/completions。解法之二是自己写一个不到 100 行的 FastAPI 中转把 Continue 的请求转成 Dify 格式再把 Dify 的响应包装回 OpenAI 格式。两条路我都试过网关方案省事自研中转更方便调试。弄好之后你可以在 IDE 的 Continue 配置里这样接入{ models: [ { title: Dify Research Agent, provider: openai, model: dify-research-agent, apiBase: http://localhost:8000/v1, apiKey: sk-local-proxy } ] }这样就能在编辑器里直接调用你编排好的研究智能体写代码和查资料一体化体感上等于把一个完整的研究流水线塞进了 IDE用起来相当顺手。6.3 移动端与边缘设备的想象空间热搜里还有一个词是 gpt-6 手机模型。这背后的趋势是编排 小模型的组合正在向移动端迁移。手机本地跑一个 2B 量级的模型配合云端强模型的编排资料完全不出手机就能完成个人知识库问答、会议纪要整理、本地相册语义检索这些任务。MiniCPM 系列本来就在往端侧走量级和功耗都合适。未来大概率会出现更多手机本地模型 云端编排大脑的产品形态本地研究智能体从电脑搬到手机里只是时间和工程问题。最后分享一个我最近最大的体会编排架构能不能跑好模型本事只占一半另一半是你有没有把执行层的边界画清楚。MiniCPM5-2B 不是万能的但当你把它的工作定义成读一段、提炼一段、输出一个 JSON时它就会变得异常可靠GPT-6 也不是万能的但你给它配齐工具和反馈回路之后它能把一个模糊的研究方向推成一份带来源的完整报告。我自己现在每天都会让这套组合读本地笔记、生成项目复盘资料从头到尾不离开本机。这种大模型想、小模型做、编排管流程的组合我觉得会是接下来一两年本地智能体最主流的形态。趁现在把流程跑通后面想扩展成多智能体、接进编辑器或者搬到手机上都不会慌。 GPT-6+MiniCPM5-2B：云端编排与本地执行打造研究智能体
面壁智能的团队前几天公开点赞了一个组合玩法用 GPT-6 来编排 MiniCPM5-2B在本地搭一只专门干研究活的智能体。乍一看是两家厂商互相捧场但等你真把它跑一遍就会发现这是在给过去一年吵翻天的大模型还是小模型之争画一个非常务实的句号——答案是都要。大模型管脑子小模型管手脚。我最近一直在折腾本地研究智能体LangGraph、Dify、n8n、自研 harness 都试过热搜里那些 gpt-6 astra 怎么用、workflow编排、deepseek harness 多个智能体编排我基本都踩过一遍。这篇就把云端编排 本地执行这套架构掰开揉碎讲清楚从设计思路到工具选型再到完整的搭建步骤和排坑经验一次性给你整理完。1. 先把这个组合拆明白GPT-6、MiniCPM5-2B、编排各负责什么1.1 四个关键词拼起来是一条完整的研究产线很多人看到这个标题第一反应是GPT-6 不是云端模型吗MiniCPM5-2B 不是本地小模型吗这俩怎么搭要理解这件事得先把标题里的四个词拆开看。GPT-6 在这里的角色不是回答问题的聊天机器人而是项目经理。它负责把一个大研究问题拆成一串可执行的小任务决定每个任务调哪个工具、把结果交给谁、什么时候收尾。MiniCPM5-2B 是面壁智能那条 MiniCPM 产品线里的新一代 2B 规模模型跑在本地——笔记本、小主机甚至手机端。它不负责思考宏大问题负责的是把这段本地文档读进去把网页正文提炼成三句话把这些条目归个类这种具体的脏活。编排指的是任务调度这件事谁先谁后、谁的输出是谁的输入、中间结果存在哪、失败了重试几次。你可以把它理解成一套工作流引擎只不过流程不是写死的而是大模型每一轮动态生成的。本地研究智能体是最终形态给它一个研究方向它自己查资料、读文档、提取关键信息、交叉验证、沉淀成一份结构化的研究笔记整个过程中敏感数据不出本机。四个词连起来就是一句话GPT-6 负责想MiniCPM5-2B 负责做编排负责派活最后得到的是一个能把研究任务从模糊想法推进到成稿的本地闭环。1.2 面壁智能这一赞其实是在给小模型正名很多人觉得面壁智能点赞 GPT-6是商业互吹但如果你一直关注这家公司的产品路线就会发现这一赞的本质是在给小模型正名。过去一年小模型被质疑最多的就是啥都干不好写代码不如大模型推理不如大模型聊天不如大模型。这个质疑本身没错但前提是把小模型放在独立完成一切的岗位上。而在编排架构里小模型根本不需要独立完成一切它只需要在明确指令下完成一个边界清晰的小任务然后把结果交回去。面壁智能自己反复讲过模型不是越大越好而是在合适的算力下达到合适的效果。这句话放在编排架构里特别好懂——2B 模型单机就能跑响应快、成本接近于零、数据不出门这些恰恰是大模型做不到的。所以当 GPT-6 这样的强规划模型出现时小模型不但没被淘汰反而因为有人替它想而变得特别能打。这套逻辑也回答了社区里一直在吵的问题既然 GPT-6 这种超大上下文模型都有了为什么还需要本地模型答案就是落地。研究型任务最怕两件事一是把你积累了多年的本地资料库整个传到云端二是每次跑长任务烧掉几百上千万的 token。本地模型做粗加工云端模型只做精规划成本和隐私两个问题同时缓解。2. 核心设计思路把研究任务拆成规划、执行、记忆三层2.1 编排层GPT-6 的动态工作流怎么设计先说编排层。研究智能体不同于简单的问答机器人问答是来一个问题答一个答案研究是给一个方向走完一整套流程。所以编排层的核心不是模型本身而是模型 工具 状态三个东西的组合。举个例子我让智能体做梳理 2025 年开源小模型的主流部署方案这个研究时GPT-6 拿到任务后生成的计划大致是这样拆成 5 个子方向模型选型、量化方案、推理框架、硬件门槛、社区案例。先对每个子方向做一轮网络检索拿到标题和摘要。挑出命中率高的 8~10 篇文章逐个抓正文交给本地模型提炼要点。把提炼出的要点按厂商和框架维度归并、去重、补齐冲突信息。最后合成一份带引用来源的研究报告。注意这个计划不是我写死的也不是模型随便列的而是 GPT-6 基于工具清单实时生成的。每完成一步它都会拿到上一步的实际结果继续往下推这就是动态编排和固定工作流的本质区别固定工作流是画好的流程图动态编排是模型在现场画流程图。顺带回答一下最近被问爆的 gpt-6 astra 怎么用。Astra 是 GPT-6 的多模态变体语音、图片、屏幕内容都能进。研究场景里你可以直接把一张图表截图扔给它让它把图表信息纳入研究计划。用法上和普通文本接口没有本质区别只是请求里多传多模态字段后面代码部分我会给出占位。设计编排层时我建议把三个状态分开管理任务状态做到哪一步了、上下文状态目前掌握了哪些事实、工具状态哪些工具可用、哪些失败过。GPT-6 的上下文里只放这三样东西的摘要不要把整个研究过程的所有原文都塞进去否则长任务跑到一半上下文就爆了。2.2 执行层MiniCPM5-2B 适合接哪些活不适合接哪些活执行层的设计原则是给模型划定边界。我在实践中整理了一张分诊表可以直接参考。适合交给 MiniCPM5-2B 的活本地文档解析PDF、Markdown、TXT 的正文提取与分段。单片段摘要给定 2000 字以内的文本输出 100 字以内的要点。实体与关键词抽取从文本里抽出人名、机构名、产品名、时间。分类打标把研究条目归入预设的类别标签。格式清洗把网页里的乱码、广告噪声、重复段落清掉。不适合交给它的活多步推理比如比较 A 方案和 B 方案的优劣并给出建议。需要全局信息综合的长文写作。任何需要调用外部工具的决策。这个边界为什么这么定因为 2B 模型的能力上限是真实的。它擅长小范围、明确指令、单一技能的工作不擅长开放探索。你非让它干规划级的活它会一本正经地编造来源但你让它把这段文字总结成三条要点它反而又快又稳。有一个关键实操细节执行层的输出格式一定要极简。我建议统一要求 MiniCPM5-2B 输出纯文本或非常轻量的 JSON别让它输出 Markdown 表格更别指望它自己决定格式。格式一旦复杂2B 模型很快就会乱。你可以在系统提示里写死只输出 JSON键名为 summary、entities、category整个执行层就变成了一个文本进、结构化文本出的翻译器后面接任何编排框架都不用改。2.3 记忆与上下文小模型装不下的东西交给向量库小模型上下文窗口有限这是你必须接受的事实。解决思路不是换大窗口模型而是把记忆外置。我的做法是在编排层和本地模型之间加一个轻量向量检索层。研究过程中的中间产物——网页摘要、文档片段、自己的笔记——全部先写入向量库每次给执行层的上下文不是全部资料而是根据当前子任务检索出来的 Top-K 片段。这样既保证执行层手头永远只有 1~3 段相关文本又保证关键信息不会在研究过程中丢失。这个设计还有个附带好处它可以给你展示研究轨迹。每一步用了哪些资料、提炼了什么结论都记录在案最后合成报告时能自动带上引用来源。对研究型智能体来说可追溯性和结论本身一样重要否则你根本不敢信它输出的东西。3. 工具选型Agent 框架和编排平台怎么选才不踩坑3.1 主流编排方案横向对比前面说的都是思路落到代码上就得选框架。我把这段时间实际跑过的几种方案放在一起对比你根据自己的技术底子选就行。方案适合人群上手难度动态编排能力扩展性我的评价LangGraph熟悉 Python 的开发者中强流程可以完全由模型动态生成高最灵活但代码量大状态机要自己维护Dify想快速出产品的团队低中偏向可视化固定流程中适合快速验证复杂动态编排偏吃力n8n偏自动化的运营或开发低中节点化触发中强在连接各类外部服务弱在让模型自由规划自研 harness想彻底掌控的进阶玩家高最强最高社区里那套 deepseek harness 多智能体编排就是这条路如果你问我怎么选第一次搭无脑从 Dify 开始。原因很简单它把模型调用、工具注册、节点编排做成了界面操作两小时就能跑通一个雏形。跑通之后你会自然遇到瓶颈这时候再迁移到 LangGraph 或自研 harness你已经有明确的痛点了不会乱选。社区里最近聊得很多的 deepseek harness 多个智能体编排本质就是自研路线。它在热搜里反复出现说明越来越多的人不满足于固定工作流想要一个总智能体动态调度多个子智能体的效果。这个方向我非常看好但建议你在没跑通单智能体之前先别上多智能体复杂度是指数级上升的。3.2 硬件门槛和本地模型部署选型很多人被本地模型四个字吓住以为要很贵的显卡。MiniCPM5-2B 这种规模的模型门槛其实比想象的低得多。只要你有 M 系列 Mac16GB 内存或 8GB 显存以上的 N 卡就能流畅跑。哪怕是纯 CPU 的老笔记本用 Q4 量化版本也能跑只是慢一点。部署工具首选 Ollama一条命令拉模型它会自动起一个 OpenAI 兼容的 API 服务端口默认 11434。面壁智能的模型通常第一时间支持 GGUF 格式。如果你在 Ollama 库里没找到现成标签就去 Hugging Face 下载 GGUF 文件用 ollama create 手动导入效果一样。这里多提醒一句本地执行模型的 API 地址和云端编排模型的 API 地址在代码里一定要分开配置。千万别图省事把两个 base_url 写成一个否则你会在不知不觉中把本地流量全打到云端隐私保护直接失效。这个坑我踩过后面还会具体说。4. 手把手搭建本地研究智能体的完整实现4.1 第一步把 MiniCPM5-2B 部署成本地服务先启动本地模型。假设你用 Ollamaollama pull minicpm5-2b ollama serve然后验证服务是否正常curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: minicpm5-2b, messages: [{role: user, content: 用一句话总结本地小模型适合做什么}] }看到正常的 JSON 响应就说明本地执行端已经就绪。这里注意两个参数temperature 建议设成 0.2 以下执行层要的是稳定输出不需要创造力max_tokens 根据任务长度设摘要类任务给 512 足够。如果你的机器有 GPU 且想追求更高吞吐可以换 vLLM 部署但 2B 模型在 Ollama 下已经足够快单路研究任务一般感知不到延迟没必要一开始就上重型方案。4.2 第二步接入 GPT-6 编排层并注册执行工具编排层的代码我用 Python 示例。核心思路是给 GPT-6 注册一个名叫 run_research_subtask 的工具这个工具的实现体是本地 MiniCPMfrom openai import OpenAI # 编排层GPT-6 planner OpenAI( base_urlhttps://your-gpt6-endpoint/v1, api_keyyour-key, ) # 执行层本地 MiniCPM5-2B executor OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, ) TOOLS [ { type: function, function: { name: run_research_subtask, description: 把单个研究子任务交给本地 MiniCPM5-2B 执行返回结构化结果, parameters: { type: object, properties: { task: {type: string, description: 子任务描述必须包含明确指令和期望输出}, context: {type: string, description: 需要处理的文本片段控制在 2000 字以内}, }, required: [task, context], }, }, }, ] def run_subtask(task: str, context: str) - str: resp executor.chat.completions.create( modelminicpm5-2b, messages[ {role: system, content: 你是研究助手只输出 JSON{\summary\: \...\, \entities\: [...], \category\: \...\}}, {role: user, content: f任务{task}\n\n文本{context}}, ], temperature0.2, max_tokens512, ) return resp.choices[0].message.content这个函数就是编排层和本地模型的握手协议。你会发现它刻意只暴露两个参数task 和 context。这是有意为之——参数越少GPT-6 越不容易在调用时犯错本地模型收到的指令也越干净。如果你用的是支持多模态输入的 Astra 接口只需在请求消息里额外加一个 image_url 字段把截图或文档图片传进去其他保持不变。编排层会自动把视觉信息纳入任务规划。4.3 第三步补齐研究工具搜索、解析、归档只有本地模型还不够研究智能体还需要看得见外部世界。我在实际项目里注册了四个工具web_search(query)调用搜索 API返回前 10 条标题、链接、摘要。fetch_page(url)抓取网页正文去掉导航和广告返回纯文本前 5000 字。run_research_subtask(task, context)即上一步的本地执行工具。save_note(title, content)把中间结论写入本地知识库Markdown 文件或向量库都行。这四件套覆盖了一条最小研究闭环搜索发现问题、抓取原文、本地提炼、归档沉淀。你可以把它理解成给智能体配了眼睛、手、大脑和笔记本。系统提示词我也给一份可以直接抄的模板它决定了 GPT-6 的编排风格你是本地研究智能体的总规划师。你的工作方式 1. 把用户的研究问题拆解成不超过 8 个子任务按依赖顺序排列。 2. 每个子任务必须指定使用的工具web_search/fetch_page/run_research_subtask/save_note。 3. 每完成一个子任务检查结果是否满足预期不满足就调整后重试最多重试 2 次。 4. 所有子任务完成后基于已归档的中间结论撰写最终研究报告并标注每条结论对应的来源。 5. 严禁编造来源。找不到的信息明确写未找到可靠来源。第五点特别重要。研究智能体和普通聊天机器人的最大区别就是真实性要求所以一定要在编排层把编造来源这条路堵死。4.4 第四步跑一次端到端研究任务看日志调流程我用一个测试任务来演示效果梳理 2B 规模开源模型在个人电脑上的部署方案。跑起来之后编排层的输出节奏大致是这样第一轮GPT-6 调用 web_search 拿到 10 条搜索结果。第二轮它挑出 5 篇看起来相关的文章逐个调用 fetch_page。第三轮每篇正文通过 run_research_subtask 传给本地模型本地模型返回简短的 summary 和 entities。第四轮GPT-6 检测到其中两篇内容高度重复调用 run_research_subtask 做了一次归并去重。第五轮调用 save_note 写入中间结论然后开始合成最终报告。整个流程看起来像有一个研究员在按部就班地干活只不过这个研究员的大脑是 GPT-6手脚是本地模型。你把每轮日志打出来看能清楚看到每个子任务的输入输出排查问题非常方便。这里有个值得注意的细节不要在编排层让 GPT-6 直接阅读全部网页正文。把正文交给本地模型提炼后再把摘要交回去这个先粗加工、再精加工的顺序能大幅节省云端 token。同样是 10 篇文章直接读全文可能烧掉几万 token先本地提炼可能只要几千 token效果反而更好因为本地模型先把噪声滤掉了一层。5. 实操中的典型问题与排查技巧实录5.1 本地模型上下文一长就输出乱码这是本地小模型最高频的问题。症状是给定大段文本后执行层的输出开始答非所问甚至蹦出无意义字符。排查思路很简单先看是不是把超过模型能力的文本塞进去了。2B 模型的有效上下文通常没有宣传窗口那么大喂到 90% 窗口就是找死。我的经验是单次调用控制在 1500~2500 字以内最稳超过就切块。切块之后还有个隐藏坑每个块独立总结会导致信息碎片化。所以我在编排层加了聚合阶段先让本地模型逐块输出要点再把这些要点汇总成一份清单交给 GPT-6 做最终综合。这就是典型的 map-reduce 模式研究型任务里非常实用。5.2 编排层生成假大空计划第一种情况是 GPT-6 抛出一堆模糊步骤比如深入研究相关主题。这种计划没有任何可执行性。原因通常是工具描述写得太笼统模型不知道每个工具能干嘛。解决方法是把工具描述当 API 文档写。我给 web_search 的描述是搜索公开网页返回标题/链接/摘要列表适合发现线索不适合精读给 run_research_subtask 的描述是把单段文本提炼为结构化 JSON适合精读与摘要。描述里写明工具边界模型才能排出靠谱计划。第二种情况是计划很具体但顺序错了比如先写报告再查资料。解决办法是强制在计划里标注依赖关系并在每轮执行前让模型看一眼当前已完成步骤清单。说白了要给编排层一块随时可以回顾的进度黑板。5.3 执行层输出格式漂移MiniCPM5-2B 有时会返回好的我来总结\n\n1. ...这样的文本而不是要求的 JSON。这不是模型坏了是它在遵循指令时不够稳定。我的对策分三层。第一层系统提示里只给一个格式示例不给多个示例越多它越容易选错。第二层解析时做容错用正则把 JSON 块提取出来而不是直接 json.loads。第三层如果连续两次解析失败就把这次结果标记为执行失败并回传给编排层让 GPT-6 决定是换个说法重新下指令还是直接跳过。记住一个原则执行层出错不可怕可怕的是出错后没有反馈回路。只要编排层能感知到这步结果不可用它就能自动修正。这也是编排架构比单模型硬刚更稳定的原因。5.4 性能与成本怎么同时调优本地模型几乎不花钱成本主要在编排层。我用三个手段把成本压到很低的水平。一是缓存。对完全相同的 context 重复调用的情况——比如多轮调试时——在本地做一个简单的 KV 缓存直接命中返回。实测能省掉 30% 以上的重复 token。二是分级路由。简单任务只调用本地模型比如这段文字分类本地就能干得很好根本不值得惊动 GPT-6。只有复杂规划、结果综合这类任务才走云端。一个研究任务跑下来云端 token 大多花在最后合成报告那一步中间大量粗加工全在本地消化。三是压缩中间上下文。前面说过喂给编排层的永远是摘要而不是原文。我发现把摘要控制在每条 100 字以内事实保留度最好代价又最低。超过 200 字的摘要GPT-6 的注意力就开始分散综合质量反而下降。6. 这套玩法还能往哪些方向延伸6.1 多智能体协作从一个执行者变成一支队伍单执行者版本跑通之后最自然的下一步是多智能体。思路还是那个GPT-6 当总指挥手下不再只有 MiniCPM5-2B 一个兵而是一批各有分工的本地模型。比如我对接过一套组合一个模型擅长文本摘要一个擅长代码审查一个专门做数据抽取。GPT-6 根据任务性质把活派给不同的执行者这就是社区里讨论度很高的 deepseek harness 多智能体编排模式。注意多智能体的复杂度主要在任务分配和结果冲突仲裁建议等单智能体稳定运行两周以上再动这个否则你连日志都看不懂。6.2 Dify 编排应用能不能当 Continue 的 API 用最近很多人问这个问题我直接给结论能但中间要包一层转换。Dify 工作流发布后确实会生成 API但它的接口格式是 Dify 自己的 /chat-messages不是 OpenAI 兼容格式。而 Continue 这类编程助手默认只对接 OpenAI 兼容接口。解法之一是用网关类工具把 Dify 注册成渠道统一暴露成 OpenAI 兼容的 /v1/chat/completions。解法之二是自己写一个不到 100 行的 FastAPI 中转把 Continue 的请求转成 Dify 格式再把 Dify 的响应包装回 OpenAI 格式。两条路我都试过网关方案省事自研中转更方便调试。弄好之后你可以在 IDE 的 Continue 配置里这样接入{ models: [ { title: Dify Research Agent, provider: openai, model: dify-research-agent, apiBase: http://localhost:8000/v1, apiKey: sk-local-proxy } ] }这样就能在编辑器里直接调用你编排好的研究智能体写代码和查资料一体化体感上等于把一个完整的研究流水线塞进了 IDE用起来相当顺手。6.3 移动端与边缘设备的想象空间热搜里还有一个词是 gpt-6 手机模型。这背后的趋势是编排 小模型的组合正在向移动端迁移。手机本地跑一个 2B 量级的模型配合云端强模型的编排资料完全不出手机就能完成个人知识库问答、会议纪要整理、本地相册语义检索这些任务。MiniCPM 系列本来就在往端侧走量级和功耗都合适。未来大概率会出现更多手机本地模型 云端编排大脑的产品形态本地研究智能体从电脑搬到手机里只是时间和工程问题。最后分享一个我最近最大的体会编排架构能不能跑好模型本事只占一半另一半是你有没有把执行层的边界画清楚。MiniCPM5-2B 不是万能的但当你把它的工作定义成读一段、提炼一段、输出一个 JSON时它就会变得异常可靠GPT-6 也不是万能的但你给它配齐工具和反馈回路之后它能把一个模糊的研究方向推成一份带来源的完整报告。我自己现在每天都会让这套组合读本地笔记、生成项目复盘资料从头到尾不离开本机。这种大模型想、小模型做、编排管流程的组合我觉得会是接下来一两年本地智能体最主流的形态。趁现在把流程跑通后面想扩展成多智能体、接进编辑器或者搬到手机上都不会慌。