开源 Agent 已经分成四层：DeerFlow、OpenHands、Orca 与 Paperclip 应该怎样选

开源 Agent 项目越来越多，但“它支持多个模型、会调用工具、能运行子 Agent”已经不足以描述差异。真正决定能否落地的，是项目处在 Agent 栈的哪一层：它是在一个任务内部组织推理，提供可嵌入的执行引擎，管理多个并行工作区，还是治理一支长期运行的 Agent 团队？

DeerFlow、OpenHands Software Agent SDK、Orca 和 Paperclip 恰好代表四种不同答案。把它们放在一张星标榜上比较会产生误导；更合理的方式，是把它们分别看成 Harness、Engine、Agent Development Environment 和 Control Plane。

先画清楚四层，而不是先选仓库

图解：Paperclip、Orca、DeerFlow 与 OpenHands SDK 解决的是不同层级的问题；最底层仍需要本地、Docker 或 Kubernetes 隔离执行。

这不是说四个项目必须这样组合，也不是说它们之间完全没有功能重叠。图的价值在于指出主要责任：越靠下越关心一次执行怎样安全完成，越靠上越关心许多执行为何发生、花了多少预算、谁批准、失败后怎样追责。

DeerFlow：解决一次长任务内部怎样组织

DeerFlow 2.0 是一次从头重写。官方将它描述为面向长时程工作的“super agent harness”，核心包括子 Agent、记忆、技能、沙箱、MCP 与上下文工程，并以 LangGraph/LangChain 组织运行。它适合研究、报告、网页或演示生成等需要拆解、并行探索和合成的任务。

Harness 的价值，在于把模型调用周围那一圈容易被忽略的工程补齐：计划怎样转成子任务，子 Agent 获得哪些上下文，技能何时加载，文件与命令在哪个沙箱执行，结果怎样回收到主线程。单次模型调用无法自然解决这些问题。

但 DeerFlow 不是“安装后就得到企业 Agent 平台”。官方文档明确提供本地、Docker 与 Kubernetes 等沙箱模式，并提醒不当部署会带来安全风险；面向共享部署的推荐资源也明显高于个人演示。若要进入多人生产环境，还需要额外回答：

• 用户之间的工作区和凭据是否真正隔离；
• MCP/OAuth token 怎样加密、轮换和吊销；
• 子 Agent 是否继承父任务的全部权限；
• 长任务中断后从哪里恢复，重复工具调用是否幂等；
• 生成文件怎样经过病毒扫描、内容审查和发布审批；
• 模型、搜索、浏览器和沙箱成本怎样归属到团队。

因此 DeerFlow 更适合作为“任务执行面”进行评估，而不是直接承担组织预算与合规控制面。

OpenHands SDK：把 Agent 变成可嵌入的软件部件

OpenHands Software Agent SDK 关注的是另一层：通过 Python 与 REST API 构建代码 Agent，并用 Agent Server 把它们运行在本地、临时 Docker 或 Kubernetes 环境。会话、工具、工作区与运行时被抽象为可以组合的部件，OpenHands 自己的 CLI 与云产品也建立在这套引擎之上。

SDK 路线的优势，是团队可以把 Agent 嵌入现有系统，而不是接受一套固定 UI。比如，内部缺陷平台创建工单后启动一个只读诊断 Agent；CI 失败时在临时容器复现；代码审查页面允许 Agent 生成补丁但不能推送；安全平台为每种工具注入独立授权策略。

代价是“自由度越高，需要自己补的系统越多”。SDK 不会自动替你决定多租户、队列、成本分摊、审批、模型路由和产物保留策略。最小生产封装至少应有：

身份 -> 任务策略 -> 临时工作区 -> 最小工具权限
     -> Agent 会话 -> 验证器 -> 审批/交付 -> 完整审计

如果团队已经有任务平台、容器基础设施和安全控制，OpenHands SDK 是更自然的底座；如果只是想让开发者立即并行操作多个 Agent，直接从 SDK 造一套界面可能得不偿失。

Orca：并行 Agent 的瓶颈往往是人的注意力

Orca 把自己定位为 Agent Development Environment。它支持多种 CLI 编码 Agent，为每个 workspace 管理独立终端、Git worktree 与环境，使开发者可以同时观察多个任务。这一层解决的不是模型会不会写代码，而是一个人怎样避免被十几个终端、分支和上下文切换淹没。

编码 Agent 并行后会出现一种新型拥塞：算力很空闲，人类审查却排队。多个 Agent 可能改到同一模块，分别通过局部测试，却在合并时产生语义冲突；也可能一个任务依赖另一个尚未稳定的接口。ADE 因此必须把状态可视化：哪个 Agent 在思考、执行还是等待，改了哪些文件，测试是否通过，与主分支偏离多少。

worktree 提供文件层隔离，但不等于完整隔离。多个工作区仍可能共享：

• 本机 Docker daemon、端口和缓存；
• 数据库、云账号与开发凭据；
• 包管理器全局目录和后台进程；
• 同一个远端分支或外部 API 配额。

所以 Orca 适合交互式并行开发与人工在环审查，不应因为界面上有多个工作区，就被当作安全的无人值守执行集群。高风险命令仍需要沙箱和策略层兜底。

Paperclip：管理的不是对话，而是组织责任

Paperclip 的官方定义是“agent orchestration for zero-human companies”，但其核心更准确地说是 Agent 控制面。它维护公司与组织结构、目标、Agent 注册、任务、预算、审批、审计和 heartbeat；实际执行由控制面之外的 adapter 与 Agent Runtime 完成。

这个边界非常重要。很多团队在一个聊天机器人里不断追加系统提示，试图同时表达组织目标、预算、汇报关系和执行权限。随着 Agent 数量增加，这些状态会散落在提示词、数据库和 Slack 线程里。Paperclip 把它们提升为显式对象：谁向谁汇报，任务服务哪个目标，花费是否超预算，关键动作是否获批。

控制面本身却不能保证任务正确。它可以证明某个 Agent 获批并花了 20 美元，却不能证明代码安全或报告事实准确。企业若采用这类架构，必须让任务状态与下层验证证据相连：测试报告、扫描结果、引用、差异、部署回执和人工审批都要成为可追溯附件。

四层系统真正难的是失败语义

演示通常展示成功路径：创建任务，Agent 调用工具，返回一个漂亮结果。生产系统更关心失败发生在哪一层，以及谁负责恢复。

最危险的设计，是每层都自动重试。底层命令重试、Harness 重新规划、上层控制面再次派单，可能把一次小故障放大成重复写入、预算失控或外部消息轰炸。重试权必须有唯一归属，并用幂等键把同一业务动作关联起来。

选择项目之前，先做一组逆向问题

与其问“哪个最强”，不如先问系统目前缺哪一层：

1. 已有内部平台，只缺可编程代码 Agent 引擎：优先评估 OpenHands SDK；
2. 需要完成研究、生成等长任务，强调子 Agent、技能与沙箱：评估 DeerFlow；
3. 开发者要同时驾驭多种 CLI Agent，主要瓶颈是工作区与审查：评估 Orca；
4. 已有多个 Runtime，却缺组织、预算、审批和审计：评估 Paperclip；
5. 需要端到端企业平台：不要幻想一个仓库全部解决，应按层组合，并明确每个边界的责任。

评估时不要只跑项目自带示例。用自己的私有仓库或脱敏镜像，设计包含中断、限流、错误工具输出、权限不足、分支冲突和预算超限的任务。记录首次通过率、人工干预分钟数、恢复成功率、权限暴露面和每个验收任务的总成本。

结论：Agent 生态正在复刻云原生的分层

容器时代早期，人们也曾把镜像、Runtime、编排器、开发环境和治理平台混为一谈。随着生产实践成熟，各层责任才逐渐清晰。开源 Agent 正在经历相似过程。

DeerFlow、OpenHands SDK、Orca 与 Paperclip 的价值，不在于谁能吞并其余三者，而在于它们让团队看到不同层的独立问题。选型的第一步应当是画出自己的 Agent 栈，标清任务内编排、执行引擎、工作区体验和组织控制面；第二步才是选择仓库。

当边界清楚，模型和工具可以替换，失败可以定位，预算与权限才真正可控。否则所谓“多 Agent 平台”，很可能只是更多会同时犯错的终端。

参考资料

• ByteDance：DeerFlow
• DeerFlow：Core Concepts
• OpenHands：Software Agent SDK
• Stably AI：Orca
• Paperclip：What is Paperclip?