Open-source landscape · 2026

Agent Harness
开源生态观察

从近 300 条社区回复中整理出的项目地图。这里关注的不只是“又一个 Agent”,而是 Runtime、控制面、验证治理、上下文与垂直闭环正在如何重新分工。

— 个表格记录5 个主要类别基于公开报名信息,尚未代码审计

底层 Agent loop 正在快速商品化。长期价值正向 运行治理上下文工程可验证执行、跨 Harness 互操作,以及垂直领域闭环迁移。

明确表格记录
带可访问仓库链接
最大类别记录数
5重点观察方向
01 · Landscape

生态结构

清单覆盖完整产品、Runtime、插件、MCP、方法论和垂直应用。分类沿用原始资料,仅用于观察供给结构,不代表严格的产品边界。

02 · Signals

六个关键洞察

“支持 MCP、Subagent、多模型、本地优先”正在成为准入能力;真正的差异开始发生在状态、协议、证据和专业工作流里。

SIGNAL 01

通用 Harness 进入拥挤区

聊天框、文件树、终端、MCP 与桌面壳的组合已高度同质化。仅替换 Provider 或 UI,难以建立长期壁垒。

SIGNAL 02

Control Plane 独立成层

用户会长期并用多个 Coding Agent。会话调度、权限、成本、路由和可观测性正在形成 Harness 之上的控制面。

SIGNAL 03

多 Agent 要从角色扮演走向任务系统

真正有效的编排需要 DAG、持久状态、隔离、冲突处理、终止条件和单 Agent 对照,而不只是串联角色 prompt。

SIGNAL 04

Long-horizon 的本质是可恢复

运行时间长不是目标。状态持久化、有界上下文、阶段验收、错误分类、预算与中断恢复才是核心能力。

SIGNAL 05

验证层成为稀缺基础设施

Agent 的瓶颈正从“不会做”变为“声称完成但没有证据”。Verification、evidence boundary 与执行门禁价值上升。

SIGNAL 06

Memory 不等于向量检索

可信记忆必须有来源、时间、作用域、纠错和防污染机制,并兼顾 prompt cache 与跨会话运行连续性。

03 · Opportunity map

机会地图

项目数量并不等于机会大小。越靠近确定性工具、专业数据、权限治理和验收标准,越可能形成难复制的价值。

拥挤区

  • 通用 Coding Agent 壳
  • 基础桌面聊天工作台
  • 简单角色式多 Agent
  • 仅 API 兼容的 “native”

上升区

  • 跨 Harness 控制面
  • Long-horizon Runtime
  • Skill 生命周期管理
  • 上下文与成本优化

高壁垒区

  • 可验证执行与安全治理
  • 可信、分域、可纠错记忆
  • 专业软件深度集成
  • 领域数据与验收闭环
04 · Watchlist

优先深读样本

下一轮不应平均扫描所有项目,而应选取代表不同技术命题的样本,使用统一 rubric 对照。

simple-long-horizon-agentDeepDiveTrellisorcana-runtimeccteamopen-agent-connectroutaHarness-routebenchdynoboxLoopForgePatchWardenverifiersOpenVikinglianaengrammnemaskills-hubheadroomskflow
05 · Review rubric

统一审查框架

总分只是辅助。最终应分别给出“产品潜力”和“技术价值”,避免用一个数字混淆成熟度与创新性。

项目基本面 · 15问题、用户、License、文档、维护
技术架构 · 20抽象、边界、状态、扩展、解耦
Agent 可靠性 · 20失败、恢复、终止、验证、预算
安全性 · 20权限、隔离、凭据、插件、供应链
工程质量 · 15测试、CI、错误处理、可观测、升级
差异化与证据 · 10真实差异、可复现 benchmark、用户证据
06 · Caveats

阅读边界

本报告是线索地图,不是排行榜。所有判断来自名称、链接和一句话说明,尚未验证代码、活跃度、安全性与宣传指标。

  • 项目粒度不统一:完整产品、框架、插件、单个 Skill 和组织主页混在同一数据集中。
  • 一行可能包含多个项目,但只有一个链接;重复项和跨分类引用仍需以规范化 GitHub URL 二次去重。
  • Star、下载、SOTA、节省 token、支持 Agent 数量等均是未验证的项目方声明。
  • 外链由 X 的卡片信息还原,可能存在 rename、transfer、fork 或描述错配。
  • “开源”仍需通过仓库 License 和实际代码可用性确认。