DeepSeek Harness vs AutoGPT/LangGraph/MetaGPT/CrewAI：Agent 框架到底怎么选

系列导航：本篇是 DeepSeek Harness 实战系列第 2 篇。上一篇《用 dsh 从零搭一个编码 Agent》讲了怎么把它跑起来；本文退一步，把它放进整个 Agent 框架的版图里，回答一个更根本的问题------我到底该用哪个？ 这恰恰是选题时最容易踩坑的地方：选错框架，后面全是在和工具较劲。

引言：Agent 框架不是"谁更强"，是"谁更对味"

只要你搜过"AI Agent 框架"，大概率被一堆名字淹没：AutoGPT、LangChain/LangGraph、MetaGPT、CrewAI、CAMEL、AutoGen......再加上 2026-08-13 开源的 DeepSeek Harness（dsh）。每个都说自己"最灵活""最像人""最适合生产"。

但选框架和选手机不一样------手机是"性能越强越好"，Agent 框架却是"架构哲学决定了它能舒服地解决哪类问题"。一个为"自主循环探索"设计的框架，硬拿去做"严格的状态机流水线"会非常别扭；反之亦然。我见过团队用 LangGraph 硬写一个"自主探索爬虫"，三个月后图被补丁补得像毛线团；也见过人用 AutoGPT 跑需要审计的金融流程，结果失控到 token 烧穿预算。

所以本文不排名次，而是做一件事：把 DSH 和四个最常被拿来比较的框架摆到一起，讲清各自的架构基因、擅长什么、不擅长什么，最后给你一张选型决策树。 看完你就能判断------DSH 是不是你要找的那个。判断标准只有一条：它假设的"人和 Agent 怎么协作"，是否和你真实的协作方式一致。

一、一张总表：五种框架的定位

框架	开源方	核心隐喻	最适合	最大特点
DeepSeek Harness	DeepSeek	插件树（Cordis 内核）	需要"可替换、可组合"的本地 Agent 服务	一切皆插件，无特权核心
LangGraph	LangChain	有向状态图	需要精确控制流程的复杂 Agent	图状编排、可中断/恢复
AutoGPT	AutoGPT	自主循环	目标驱动的开箱探索	自主性强，但易失控
MetaGPT	深度赋智	SDLC 角色流水线	软件公司级的多角色协作生成	把"产品经理/架构/工程师"流程化
CrewAI	CrewAI	角色扮演团队	多 Agent 分工协作的业务流	角色+任务+流程，轻量易上手

这张表先建立直觉：它们不是同一维度的竞品，而是各自占据了一个"问题象限"。 下面逐个拆，重点不是记结论，是理解"为什么它会长这样"。

二、架构哲学的分野：插件树 vs 计算图 vs 角色编排 vs 自主循环

所有 Agent 框架本质上都在回答三个问题：

Agent 的"能力"从哪来？（工具、记忆、模型怎么挂上）
步骤之间怎么连接？（线性、图、循环、角色交接）
谁来控制流转？（框架调度、模型自主、还是人）

这三个问题的不同答案，塑造了五个框架截然不同的形态。

2.1 DeepSeek Harness：插件树（Spatiotemporal Composability）

DSH 构建在 Cordis 微内核 之上（源自 Koishi 生态，设计思想来自论文 A Programming Paradigm for Spatiotemporal Composability ，即"时空可组合性范式"）。它的答案是：整个系统的每一个环节------模型接入、工具调用、会话存储、审批策略、UI 组件------都是可替换、可组合的插件，挂在一棵"插件树"上。

"时空可组合性"听起来玄，拆开就两层意思：

时间可组合性 ：插件能安全地装载/卸载/热替换，卸载时不能让系统状态 corruption。Cordis 用 ctx.effect() 把"清理逻辑"和"注册逻辑"绑定在一起，插件卸载时框架自动回收它挂上去的一切（监听器、定时器、子插件），你不用手写 removeListener、不用手动 clearInterval。
空间可组合性 ：插件通过"依赖声明"互相隔离又互相组合。一个插件声明"我依赖 tools 服务"，框架保证等 tools 就绪才激活它，缺依赖时它保持 PENDING 而不是崩溃。

这意味着：想换模型服务？改配置，不动源码。想加个工具？装个插件。想改审批策略？换个审批插件。想换 UI？UI 本身也是插件（client/host 包）。

与 Claude Code、Codex 等"把核心逻辑写死"的工具不同，DSH 从模型到工具注册表、从会话日志到审批策略，全部插件化。它用"时空可组合性"解决了 Agent 运行时最难的坑：插件卸载时不能让系统状态 corruption。

2.2 LangGraph：有向状态图

LangGraph 把 Agent 建模成一张图：节点是"做什么"（调用模型、调工具、判断），边是"下一步去哪"。你可以显式定义条件分支、循环、人工审批节点（interrupt）。它适合流程复杂但要求可控的场景------比如"先检索、再判断是否需要追问、再生成、再人工确认"。

代价是：你得把流程画出来。对"我也不知道要走几步"的探索型任务，画图的负担反而成了阻力。它的强项是"确定性编排"，弱项是"开放式探索"。

2.3 AutoGPT：自主循环

AutoGPT 的范式是"给一个目标，它自己拆、自己干、自己判断完成没"。它没有预设流程图，靠模型在每一步决定"下一步做什么"。自主性最强，但 notoriously 容易在一个失败方案上反复横跳、烧 token、跑偏------这也是为什么它名声两极分化。它假设"人是甩手掌柜"，模型全程掌舵。

2.4 MetaGPT / CrewAI：角色编排

这两个是"多 Agent 协作"路线的代表，但侧重不同：

MetaGPT 把软件公司的 SDLC（软件开发生命周期） 角色化：产品经理写需求文档、架构师出设计、工程师写代码、QA 测。它用"标准化文档"在角色间传递上下文，像一条流水线。它解决的是"多角色协作生成"。
CrewAI 更轻量：你定义几个"角色"（比如研究员、写手、审校），给每个角色一个"任务"，框架按你设定的流程（sequential / hierarchical）让它们接力。它适合业务流（比如"研究竞品→写周报→审校格式"）。

它们的强项都是"多角色分工"，弱项都是"单角色深度干活的能力不如专用编码 Agent"------比如让 CrewAI 在已有仓库里精细改代码，它会比 DSH 吃力。

三、DeepSeek Harness 的"一切皆插件"到底特别在哪

这里要点破一个常见的误解："支持插件"不是 DSH 的卖点，"一切都是插件"才是。

很多框架也支持插件/工具扩展，但通常是"核心逻辑写死 + 外围留几个扩展点"。DSH 的区别在于：连它自己的核心能力都是插件 。官方的 packages/ 目录就是一个长长的插件清单------agent-loop、session、tools、shell、fs、web、host、client、sandbox、subagent、llm......每一个都是挂在 Cordis 树上的插件。

这带来一个别的框架很难给的性质：没有特权核心 。你想替换"Agent 循环怎么驱动"，不需要 fork 源码改 agentLoop，只要知道那行配置的 id，用一层 patch 把它换掉即可。这种"组合即一切"的设计，让 DSH 在"长期演进、不停机改代码（HMR）、按需裁剪"上天然占优。

反过来说，这也意味着 DSH 的"开箱即用感"不如 LangGraph 那种"给你一张流程图模板"来得直接。它是个内核，不是个成品。你拿到的是乐高底座，不是拼好的模型。对想"今天就用"的人，这有点劝退；对想"搭自己的 Agent 平台"的人，这正是金矿。

四、LangGraph：当你需要"精确控制每一步"

选 LangGraph 的理由：你的业务流程长、分支多、且容错率低。比如金融审批、合规审查、需要人工在中间节点介入并能被审计的流程。图的"可中断/可恢复/可被人在任意节点接管"是它真正的护城河------你可以把"人工审批"做成一个 interrupt 节点，流程跑到这停住，人点通过才继续。

不选 LangGraph 的理由：你只是想"让 AI 在本地帮我改改代码、跑跑测试"。这时候画图的负担是纯开销，DSH 的插件树反而更轻------你甚至不需要理解"图"这个概念，装个插件就加个能力。

一个判断标准：如果你能用一句话说清流程（"读代码→改→测"），别上图；如果流程里有"根据上一步结果决定跳到 A 还是 B，且 B 还可能回退到 A"这种非线性，才考虑 LangGraph。多数编码 Agent 场景属于前者。

五、AutoGPT：自主探索的先驱，也是警示

AutoGPT 证明了"给目标、模型自己干"是可行的，也暴露了这种范式的软肋：缺乏约束时容易失控。它适合"探索性、容错高、成本不敏感"的场景（比如让它在沙箱里试各种方式抓一个网页数据）。

但在生产代码、涉及写文件/跑命令的场景，纯自主循环风险太高。 这恰恰是 DSH 用"沙箱 + 三档权限 + 审批 seam + 纠偏插件"重点补上的地方。所以如果你被 AutoGPT 的"失控"劝退，DSH 是个更稳的替代------它保留了自主拆解能力，但把"手"绑在了沙箱里。我个人的取舍是：探索性爬虫用 AutoGPT 思路，写代码的活一律用 DSH + 沙箱。

六、MetaGPT：把"软件公司"流程化

如果你要的是"输入一句话需求，产出一整套带文档、带架构、带代码的软件"，MetaGPT 的 SDLC 角色流水线非常对路。它解决的是"多角色协作生成"的问题，文档在角色间充当上下文契约------产品经理的 PRD 传给架构师，架构师的 design 传给工程师。

但它不是为"在你已有仓库里持续改代码"设计的。 它的强项是"从 0 生成"，弱项是"在别人的代码上精细迭代"。而 DSH 的编码 Agent 恰恰是后者------它活在真实工程里，读你的文件、改你的函数、跑你的测试。两者其实可以配合：用 MetaGPT 出初版，用 DSH 进仓库维护。这比硬让一个框架干两件事舒服得多。

七、CrewAI：轻量多角色协作

CrewAI 的定位是"最易上手的协作框架"。定义角色、分配任务、设个流程，几行代码就能让几个 Agent 接力干活。它适合业务流（比如"研究竞品→写周报→审校格式"），不适合需要深层工具调用的编码任务。

和 DSH 的关系：DSH 的 subagent（子代理）能力其实也能做"多 Agent 协作"，而且它的子代理 provider 里默认就躺着 codex 和 claude-code 两个 provider（disabled 状态）------也就是说 DSH 天然支持把别的家的模型/产品当子代理用。这一点我们在后续"多 Agent 协作"篇会展开。所以如果你已经在用 DSH，未必需要再引入 CrewAI 做协作，用 subagent 就够了。

八、Claude Code / Codex：闭源但强大的参照

虽然不算"框架生态"，但提到编码 Agent 绕不开这两个闭源强手。它们的能力和 DSH 高度重叠（读文件、跑 shell、保持计划、派子代理），但核心逻辑写死、不可插件化、不开源。DSH 的差异化价值正是"同样的编码 Agent 体验，但是开放、可替换、可自建"。如果你认同"我的 Agent 基础设施不该被一家闭源产品锁死"，DSH 是当下最接近这个理想的选项。代价是：闭源产品打磨更细、bug 更少，DSH 还在 rc 阶段，会踩到毛刺。

九、选型决策树：什么场景用哪个

我把它压缩成一组问题，按顺序问：

你要的是"在真实工程里持续干活"（改代码/跑测试/操作文件）吗？
- 是 → DeepSeek Harness（或 Claude Code/Codex，若你能接受闭源）。
- 否 → 继续。
流程长且非线性、需要人工在中间接管、要可审计吗？
- 是 → LangGraph。
- 否 → 继续。
是"从 0 生成一整套软件/文档"吗？
- 是 → MetaGPT。
- 否 → 继续。
是"几个角色分工完成一个业务流"吗？
- 是 → CrewAI。
- 否 → 继续。
是"给个目标让它在沙箱里自由探索"吗？
- 是且容错高 → AutoGPT。
- 是但涉及写操作 → 用 DSH + 沙箱 更稳。

一句话总结：DSH 是"可组合的 Agent 运行时底座"，LangGraph 是"可控流程图"，MetaGPT 是"软件公司流水线"，CrewAI 是"轻量协作队"，AutoGPT 是"自主探险家"。 它们解决的是不同象限的问题，别用一个去硬刚另一个的主场。

十、能不能混用？DSH 把竞争对手当零件

最有意思的一点：DSH 的开放度让它不排斥别的框架 。它的 subagent provider 默认就包含 codex 和 claude-code（disabled，去掉 disabled 即可启用），意味着你可以让 DSH 的主 Agent 把某段子任务派给 Claude Code 或 Codex 去跑。

这背后是 DSH 的中立姿态：官方支持 40+ 家模型厂商（DeepSeek、Anthropic、OpenAI、Bedrock、Azure、Gemini 等），甚至能把竞争对手的产品当子代理接入。这种"连对手的模型都能跑"的开放，正是它生态想象力的来源------你不会被锁死在任何一家能力上。反观把核心写死的闭源产品，你要么全用它的模型，要么干脆不用。

十一、给团队的技术选型建议

结合上面的分析，给不同规模的团队一句实在话：

个人开发者 / 小团队想提效：直接上 DSH，享受"可替换、可组合、开源"的长期红利，陪它一起演进。
企业有严格合规流程：DSH 的"审批 seam + 会话日志全留痕"很契合，但要等它出稳定版（rc 阶段接口会变）。过渡期可用 LangGraph 做可控流程。
做 AI 编程产品：DSH 的插件化底座适合做"白标"------你在它上面挂自己的工具、自己的 UI、自己的模型，不必从零造轮子。
做内容/研究的多 Agent 流水线：MetaGPT/CrewAI 更快出活，DSH 作为"进仓库维护"的下游环节。

十二、每个框架的"反例"：什么时候千万别用

正向推荐说完，说点扎心的------每个框架都有"用了就后悔"的场景：

DeepSeek Harness 的反例：你要的是"今天下班前跑通一条固定业务流"，且不愿花时间跟 rc 版本的破坏性变更。DSH 是内核不是成品，前期要折腾预设/插件/配置，rc 阶段接口还会变。这种"要快交付"的场景，先用 LangGraph 或闭源成品更省心。等你想"搭自己的 Agent 平台"再回来。
LangGraph 的反例：你的任务就是"读代码→改→测"这种一句话能说清的线性流程。硬画一张图，维护成本远高于收益，图迟早变成补丁毛线团。
AutoGPT 的反例：任务涉及真金白银、或会写生产数据库、或会删文件。纯自主循环在缺乏约束时失控风险高，烧 token 事小，误删数据事大。
MetaGPT 的反例：你要维护一个已经很大的存量代码库。它的强项是"从 0 生成"，在别人代码上精细迭代是它的弱项，强行用会反复生成不兼容的代码。
CrewAI 的反例：你的任务需要深度工具调用（读文件、跑 shell、调内部 API）。CrewAI 擅长"角色接力做业务文本流"，不是"在真实工程里干活"。这种活交给 DSH。

记住：没有框架能通吃。选错框架，后面全是在和工具较劲。

十三、迁移与学习成本对比

很多选型最后败在"迁移成本"上。一张表说清：

维度	DSH	LangGraph	AutoGPT	MetaGPT	CrewAI
学习曲线	中（要懂 Cordis 插件树）	中高（要懂图编排）	低（给目标就跑）	中（懂角色/文档流）	低（定义角色即可）
改造成本	低（组合不 fork）	高（流程写进图）	高（失控要兜底）	中（流程模板化）	中
是否锁死	否（可替换）	部分（图即逻辑）	是（自主难控）	是（流水线固定）	部分
社区成熟度	新（rc 阶段）	成熟	成熟但口碑两极	成熟	成熟
适合团队规模	中大型/平台型	中大型/流程型	个人探索	研究/生成型	小团队业务流

结论很清晰：DSH 的"改造成本低、不锁死"是长期红利，代价是"当下不够成熟、要跟演进"；其余四个要么成熟但锁死，要么简单但失控。 你的选择取决于"你是在赌未来还是救当下"。

十四、未来 12 个月演进判断

给一句实在的预判（基于 2026-08 的状态）：

DSH：会快速迭代，rc 之间仍有破坏性变更，但"一切皆插件"的架构不会大改。现在是"上车建认知"的最佳窗口------等它出稳定版，学习曲线会陡增（别人都成专家了）。
LangGraph：已较稳，是企业可控流程的默认答案，演进偏保守。
AutoGPT：仍在找"自主但不失控"的定位，安全机制会持续补强。
MetaGPT / CrewAI：在"多 Agent 协作"层深耕，会和标准协议（如 ACP、Agent Client Protocol）对齐。
闭源产品（Claude Code/Codex）：打磨持续领先，但永远不开源、不可插件化。

所以我的建议是：如果你是平台型思考者或想深度掌控 Agent 基础设施，现在就开始跟 DSH，陪它演进；如果你只是要"今天能用"，选成熟的专用框架或闭源成品，别硬上预览版。

十五、一个真实团队的选型复盘

讲个我见过的真实案例（脱敏）：一支 8 人后端团队，想引入 AI 提效。一开始全员上了某闭源编码 Agent，前两周爽翻天，第三周出问题------它的内部逻辑他们完全改不了，想要"提交前自动跑 lint + 单测 + 生成变更说明"这种定制流程，只能等官方更新；更糟的是模型被锁死，想换更便宜的自建端点做不到。

他们重新评估后做了分层：

个人 Coding：保留闭源 Agent 做探索（接受它的不可改，因为它确实好用）。
团队流水线：引入 DSH，挂上自己的 lint/测试/commit 工具插件，模型指向自建网关。这一步把"定制化"和"不锁死"拿回来了。
跨服务编排：用 LangGraph 把"需求→DSH 改代码→自动 PR→CI"串成一条可审计的图。

复盘结论很朴素：没有哪个框架通吃，但他们犯的最大错是"一开始假设有一个能通吃的框架"。 先想清楚"哪些能力要定制、哪些要可控、哪些要探索"，再按象限拆给不同框架，反而最省时间。这篇对比表，本质上就是帮你在动手前做完这道拆解。

十六、术语表与延伸阅读

怕你看晕，把全文关键术语收个尾：

Harness：Agent 的"执行身体"，提供工具、环境、持久化，让模型在真实世界干活。
Cordis：DSH 底层的插件微内核，源自 Koishi，核心是"时空可组合性"。
Preset（预设）：预定义的能力组合包（Standard/Code Mode/Minimal/Creator）。
Patch（覆盖层） ：启动时叠加的配置层，用 cordis.yml 描述，不影响源码。
Trajectory（轨迹）：只追加的会话日志，记录模型所见所做，可回溯。
Subagent（子代理）：主 Agent 派出去干子任务的可复用 Agent，provider 可换。
Seam（缝合点）：DSH 里"能力"的抽象边界，分定义/提供/消费三角色。

延伸阅读建议按这个顺序：① 官方 docs/architecture.md（架构真相源）；② @deepseek-ai/cordis 仓库（内核原理）；③ 本系列的前四篇（概念/教程/架构/插件）；④ 社区实测帖（laserlloyd 的 first-look、掘金/SSD Nodes 的插件教程）。读源码前先读架构文档，能省你两周弯路。

十七、一张速查卡：30 秒做决定

把全文压成一张卡，贴在你工位上：

想在真实工程里持续改代码/跑测试 → DSH
流程长、要人工审批、要可审计 → LangGraph
从一句话生成整套软件+文档 → MetaGPT
几个角色接力做业务流 → CrewAI
给目标让它在沙箱自由探索 → AutoGPT（容错高）
要今天就用、不想跟预览版 → 闭源成品（Claude Code/Codex）

记住：DSH 是底座，其他多是成品。底座前期累，长期自由；成品上手快，但被锁死。 你是在"买乐高"还是"买拼好的模型"，决定了你后面是被框架托着走，还是被框架绑着走。

十八、常见误区澄清

收尾前澄清三个高频误解，避免你踩我踩过的坑：

误区一："框架越多越好，全装上。" 错。框架解决不同象限的问题，硬叠加只会增加集成成本和不确定性。先想清楚问题属于哪个象限，再选一个主线，其他按需补位。
误区二："DSH 是 AutoGPT 的国产替代品。" 不准确。DSH 的架构基因是"插件树运行时"，AutoGPT 是"自主循环"。两者解决不同问题，DSH 更像"Agent 界的 Kubernetes 底座"，而非"另一个 AutoGPT"。把它当底座用，才对得起它的设计。
误区三："选了就能躺平。" 任何框架都只是工具，真正的杠杆在"你会不会把目标说清楚、把验收标准定清楚"。框架帮你执行，但方向得你定。我见过最会用 DSH 的人，不是提示词写得最花哨的，而是"验收标准列得最清楚"的。

把这三点记住，选型基本不会翻车。框架是手段，把活干好才是目的。

十九、框架之外的三个变量

选完框架只是第一步，真正决定项目成败的，往往是框架之外的三个变量：

数据质量：无论哪个框架，喂进去的需求、上下文、工具描述的质量，直接决定输出质量。DSH 的"模型可见必进日志"不变量，本质上就是在逼你把"模型该看到什么"想清楚------这比换框架重要十倍。
评估体系（Eval）：你凭什么说"新版本比旧版本好"？没有一套离线评估集（固定任务 + 固定判分），任何框架的迭代都是在盲飞。LangGraph 可控、DSH 可组合，但都得配 eval 才有意义。
运维与可观测：Agent 上线后怎么监控？DSH 的 Trajectory 给了"每一步可回溯"的基础；但你要在此基础上建"异常告警""成本看板""回放复现"。框架不替你做这些，但选对了框架（比如 DSH 的日志即真相）会让这些事容易十倍。

这三点，比"选哪个框架"更难、也更值钱。很多团队框架选得对，却栽在"没 eval、没监控"上。提醒一句：框架是战术，数据/eval/运维是战略。

二十、当老板问"为什么选这个框架"

最后给一线工程师一个实用话术------当你要向老板/架构委员会 justification 时，别讲"它最先进"，讲"它匹配我们的约束"：

选 DSH 的理由："我们要的是可演进的 Agent 底座，不想被闭源锁死，且团队有能力跟开源演进。它的插件化和会话留痕，正好匹配我们对'可控、可审计'的要求。"
选 LangGraph 的理由："我们的流程长且要人工审批、要可审计，图的'可中断/可恢复'是硬需求。"
选闭源成品的理由："我们要的是今天就能用、打磨成熟，愿意用'不可插件化'换'省心'。"

老板不在乎框架多酷，在乎"它能不能在 our 约束下把活干好、且不出事"。你的选型陈述，应该是一份"约束→框架"的映射，而不是一份"框架功能清单"。

二十一、如果只记一句话

如果全文你只能记住一句，记住这句：选框架，先看它"假设你怎么和 Agent 协作"，而不是看它"功能多不多"。

功能列表是会骗人的------每个框架都能罗列一长串能力。但"它假设你画好流程图""它假设你甩手掌柜""它假设能力是可插拔零件"，这些隐含假设才是真正决定你用得爽不爽的东西。匹配你的协作习惯，功能少也顺手；不匹配，功能再多也是枷锁。

所以别问"哪个框架最强"，改问"我的协作方式长什么样"。答案清楚后，框架自己会浮现。

二十二、写在选型之后

选型只是起点。无论你最后选了 DSH 还是别的，有三件事建议立刻做，别等"有空"：

建一个 eval 集：10--20 个固定任务 + 固定判分，用来衡量"换模型/换配置后是不是真的变好了"。没有它，所有迭代都是盲飞。
把日志当资产：选支持"全留痕"的框架（DSH 的 Trajectory 就是典范），出问题能回放，而不是靠猜。
定一条红线：哪些操作必须人工审批、哪些数据 Agent 永远碰不到。这条线越早定，后面越省心。

这三件事比"选哪个框架"更影响长期成败。框架会过时、会合并、会被新秀取代；但你对"数据、评估、边界"的重视，是穿越框架更替的能力。

二十三、把框架装进你的技术雷达

选型不是一次性决定，是持续评估。建议把 Agent 框架纳入团队的"技术雷达"，每季度复盘一次，关注四个信号：

接口稳定性：DSH 还在 rc，破坏性变更频繁，适合"跟演进"但不适合"押生产"。当它出稳定版（breaking-change 承诺收敛），才算脱离观察期。
生态浓度 ：插件/provider 的数量、社区教程的质量、issue 响应速度。DSH 目前生态在快速生长（官方 packages/ 已经几十个能力包），但第三方插件还少，这是要持续观察的点。
协议收敛 ：Agent Client Protocol（ACP）、模型无关接口是否在向标准靠拢。DSH 自带 acp 包（自动化专用的 ACP server），说明它在往"可互操作"走，这是个积极信号。
你的需求演化：今天你要"改代码"，半年后可能要"多 Agent 协作"或"接进生产流水线"。框架能不能跟着你长，比它今天多几个功能重要。

技术雷达的意义，是让你在"跟风"和"守旧"之间找到节奏------既不盲目追新，也不被旧选择锁死。

二十四、结语前的最后提醒

写到这里，我其实有点担心你"看完更有道理，动手更不敢动"。所以最后提醒一句：框架对比是认知投资，不是行动替代品。 你花一小时读这篇，省下的是"选错框架后三个月的返工"。但读完后，请立刻做最小的那一步------哪怕只是 npx @deepseek-ai/dsh web 起来，跑一个"读我的代码并总结"的任务。

认知只有在动手中才会变成能力。这篇文章帮你"选对方向"，但"跑通"得靠你自己敲下那行命令。别让对比变成拖延的借口。

二十五、给不同规模团队的框架优先级

最后一节，按团队规模给一份"优先级清单"，方便你直接抄作业：

个人开发者 / 自由职业者：首选 DSH（或闭源编码 Agent）。你没历史包袱，最该趁机建立"Agent 基础设施"的认知。DSH 的插件化让你从第一天就在练"组合能力"的肌肉，这比会用某个成品值钱。
5--20 人初创 / 小团队：主线用 DSH 做编码与自动化，关键可控流程（如发布审批）用 LangGraph 兜底。别上 MetaGPT/CrewAI 除非你真有"多角色生成"的需求------多数小团队用不上那么重的协作层。
20--100 人中型团队：把"可控"放在第一位。DSH 的会话留痕 + 审批 seam 适合做内部 Agent 平台；LangGraph 做需要审计的复杂流程；闭源成品用于个人提效（允许但不强推）。建立统一的 eval 集和成本看板，比选框架更紧迫。
100 人+ 大型企业：框架选型要服从合规与可审计。DSH 的开源、可插件化、日志全留痕是加分项，但必须等它脱离 rc、出稳定承诺；过渡期可用 LangGraph 等成熟方案。无论选哪个，先把"数据/eval/运维"三件套立起来。

这份清单的核心逻辑是：团队越小，越该赌 DSH 这类底座（因为试错成本低、长期红利大）；团队越大，越该优先"可控与可审计"（因为出错代价高）。 没有放之四海皆准的答案，只有"匹配你当下约束"的答案。

二十六、关于"锁死"的一句真心话

全文反复提"别被锁死"，但我想说句平衡的话：锁死不一定是坏事，关键看"锁在谁手里、锁得值不值"。

用闭源编码 Agent，你被"锁"在它的产品逻辑里，但你换来了"今天就能用、打磨成熟、bug 少"。如果你的核心诉求是"赶紧把活干完"，这种锁死是划算的------你用"灵活性的丧失"换了"确定性的交付"。用 DSH，你不被任何一家模型/工具锁死，但代价是"前期要折腾、rc 阶段会踩刺"。如果你的核心诉求是"搭一个能演进十年的 Agent 底座"，这种自由才值钱。

所以"怕锁死"不该是口号，而该是计算：我失去的灵活性，和我换来的确定性，哪个在当前阶段更贵？创业公司早期要的是确定性交付，闭源成品的"锁死"是福不是祸；平台型团队要的是长期自由，DSH 的"不锁死"才是资产。把这句话刻进选型逻辑，你就不会再被"开源一定比闭源好"之类的绝对判断带偏。

二十七、彩蛋：让 DSH 自己帮你选框架

最后抖个机灵：既然 DSH 能读代码、能上网、能总结，你完全可以让它"基于你团队的真实约束"生成一份选型建议。把这篇的对比表 + 你团队的情况（规模、合规要求、现有模型、是否要审计）一起丢给 DSH，让它输出一份"我们该选哪个、为什么、第一步做什么"。你会发现，让 Agent 基于你的具体上下文做选型，比读十篇泛泛对比文都准------这本身就是 DSH "模型可见必进日志、可回溯"价值的体现。

当然，最终拍板的还是你。Agent 给的是"有依据的草稿"，不是"替你决定的圣旨"。

给读者一个小作业

读完别划走，花五分钟做一件事：拿出一张纸，写下你团队当前最痛的"AI 能帮忙但没搞定"的场景，然后对照本文的决策树，圈出它属于哪个象限、该用什么框架。这个动作比收藏本文有用十倍------因为选型从来不是"知道哪个好"，而是"知道自己要什么"。

如果这篇帮你少踩一个坑、少一次"选错框架三个月返工"，它就值回了你读它的二十分钟。框架会过时，但"先想清楚协作方式再选工具"这个习惯，能陪你穿越每一轮技术更替。

选型没有终点，只有下一次更聪明的决定。祝你选得准、用得爽，也欢迎在评论区告诉我你最终选了谁、为什么。

结语：选框架，先看"它假设你怎么工作"

回到最根本的一点：每个框架都隐含了一个对"人怎么和 Agent 协作"的假设。

LangGraph 假设"流程是我画好的"。
AutoGPT 假设"目标是我给的，路它自己找"。
MetaGPT 假设"产出是一套软件文档与代码"。
CrewAI 假设"任务是一群角色接力"。
DeepSeek Harness 假设"能力是可插拔的零件，我随时重组"。

如果你认同最后这种------想要一个不被写死、能跟着你的工程一起演进的 Agent 底座------那 DSH 值得你花时间。如果你要的是"今天就能跑通一条固定业务"的成品，那上面的某个专门框架可能更快。没有银弹，只有适配。

下一篇我们深入 DSH 的"会话日志与会话管理"------为什么它坚持"模型看到的一切都记进只追加日志"，以及 fork/resume/transcript 这些能力怎么从这一条流派生出来。理解了日志即真相，你才真正摸到了 DSH 的脉搏。

如果这篇帮你理清了选型，点个关注。我会持续更新 DeepSeek Harness 实战系列（概念 / 教程 / 架构 / 插件 / 编码实战 / 本文 / 会话管理 / Headless 接入 CI / 自定义工具 / 模型适配 / Web 协同 / 安全沙箱 / 多 Agent / 二次开发）。有问题欢迎评论区交流，我会挑典型的回。

本文基于 deepseek-ai/deepseek-harness 官方仓库、Cordis 官方文档、社区实测（laserlloyd、jb51、掘金教程）及 AutoGPT/LangGraph/MetaGPT/CrewAI 公开资料整理，截至 2026-08。框架演进快，具体能力以各项目最新文档为准。