第 2 期｜工具检索、主动发现、图形工作流：上期承诺的三个方向全来了
本期兑现上期预告：拆解 langgraph-bigtool（语义工具检索）、MCP-Zero（主动发现 308 个 MCP 服务）、Google ADK 2.0（图形工作流 GA）三个项目，同时补录 OpenHands（SWE-Bench 77.6%）。附本期选型矩阵与社区热点观察：runtime 基础设施正在成为 coding agent 真正的护城河。
리서치 브리프
第 2 期，兑现上期承诺。
上期结尾提到三个值得盯住的方向：langgraph-bigtool（大工具集上下文管理）、MCP-Zero（主动工具发现）、Google ADK（Google 官方 agent 开发套件）。本期把它们逐一拆开，外加一个本周 GitHub 热度持续走高的老项目 OpenHands。
快速索引
| 项目 | ⭐ Star | 最新版本 | 一句话定位 |
|---|---|---|---|
| langgraph-bigtool | 543 | 0.0.3 (2025-06-03) | LangGraph 扩展，让 agent 能语义检索数百工具，绕开上下文长度限制 |
| MCP-Zero | 488 | 无正式版本 | arXiv 论文配套代码，agent 主动发现并组装 MCP 工具链 |
| Google ADK | 20.1k | v2.2.0 (2026-06-04) | Google 官方 agent 开发套件，2.0 引入图形工作流引擎，正式支持多 agent 编排 |
| OpenHands | 77.1k | 持续迭代 | 以 Docker 容器为执行沙箱的软件工程 agent，SWE-Bench 得分 77.6% |
langgraph-bigtool：给 agent 装上工具检索器
콘텐츠 카드를 불러오는 중…
LangGraph 有一个天花板：你往 agent 里塞的工具越多，system prompt 越胀，推理质量越差。
langgraph-bigtool 把这个问题转换成了向量检索问题。1核心思路很直接——把全部工具的名称和描述存入 LangGraph 内置的持久化存储（InMemoryStore 或 PostgresStore），agent 收到任务后先做一次语义搜索，拿回最相关的 2-5 个工具 ID，再走正常的 function calling。工具本体不放进上下文，只在需要时按需取用。
# 简化的使用模式
embeddings = init_embeddings("openai:text-embedding-3-small")
store = InMemoryStore(index={"embed": embeddings, "dims": 1536, "fields": ["description"]})
# 把所有工具描述存入 store，只在 agent 需要时按语义检索
builder = create_agent(llm, tool_registry)
agent = builder.compile(store=store)理论上几千个工具也跑得通，背后有两篇论文支撑：Toolshed（工具 RAG Fusion）和 Graph RAG-Tool Fusion。2
适用场景：企业内部 agent，工具库来自多个系统（CRM、ERP、内部 API），几十到几百个 tool 函数，不可能全塞进 prompt。
升级风险：低。这是 LangGraph 的独立扩展包，不改动 LangGraph 本身。最新版 0.0.3 于 2025 年 6 月 3 日发布，三个版本迭代下来 API 已趋于稳定。唯一依赖是 LangGraph 的 Store 接口，Postgres backend 需要额外配置。
MCP-Zero：让 agent 自己决定用哪个 MCP 服务
콘텐츠 카드를 불러오는 중…
这个项目来自 2025 年 6 月的一篇 arXiv 论文（arXiv:2506.01056）。问题设定比 langgraph-bigtool 更激进：当 agent 面对 308 个 MCP 服务、共 2797 个工具时，怎么在不知道"应该用哪个服务"的前提下主动发现并组装正确的工具链？3
MCP-Zero 的回答叫「主动工具发现」（Active Tool Discovery）：agent 拿到任务后，先做 MCP server 级别的语义匹配，选出最相关的若干服务，再从这些服务里按工具描述做第二轮检索，最后把选出来的工具临时组装成可调用的工具链——整个过程不需要人工提前配置"哪个任务用哪些服务"。
配套开源了 MCP-tools 数据集：从 MCP 官方仓库过滤整理，308 个服务、2797 个工具，每条工具带描述向量（text-embedding-3-large，3072 维）。这个数据集本身就有独立价值——自己评测工具检索效果可以直接拿来用。
升级风险：无正式 release，代码现阶段是论文复现版，主要用于实验。作者在 README 里说后续计划加 MCP 服务的动态部署、GAIA benchmark 测试环境等。488 star、52 fork，社区关注度不低，但生产环境使用还需等进一步完善。
Google ADK 2.0：图形工作流引擎正式 GA
콘텐츠 카드를 불러오는 중…
上期说「值得盯住」，这期有了明确的结论：ADK 2.0 在 2026 年 5 月 19 日 GA，6 月 4 日发布 v2.2.0。4
2.0 引入了两个核心机制：
Workflow Runtime（图形执行引擎）：支持路由（routing）、扇出/扇入（fan-out/fan-in）、循环（loop）、重试（retry）、状态管理和动态节点。过去用 LangGraph 才能做的确定性流程编排，现在 ADK 自己有了。5
# 工作流：两个 agent 串联
root_agent = Workflow(
name="root_agent",
edges=[("START", generate_fruit_agent, generate_benefit_agent)],
)Task API（agent 间结构化委托）：多 agent 之间不再是简单的"调用"，而是有 multi-turn 任务模式、human-in-the-loop 支持、任务结果回传等结构化协议。
v2.2.0 有两条需要关注的 breaking change：
LlmAgent默认模型从gemini-2.5-flash切换到gemini-3-flash-preview，因为 2.5-flash 将于 2026-10-16 关闭。没有指定model=的代码升级后会切换到新的预览模型。interactions_utils.py里的 turn-based 工具函数已重命名（convert_contents_to_turns→convert_contents_to_steps）。4
ADK 现在支持 Python、TypeScript、Go、Java 和 Kotlin 五种语言，同时宣布了 Kotlin/Android 版。20.1k star，3.6k fork，比上期统计的数字增长明显。
升级风险（中）：从 1.x 升级到 2.0 有 breaking change——session schema 不兼容 1.27 及更早版本，agent API 和事件模型均有变更。从 1.28+ 升来的数据可以被 2.0 读取（旧字段会被忽略），但不能回退。新用户直接上 2.x 没有问题。
OpenHands：SWE-Bench 77.6% 的软件工程 agent
콘텐츠 카드를 불러오는 중…
OpenHands 不是这周才出现的——它已经累积到 77.1k star，是这几个项目里体量最大的。列入本期是因为它代表了 agent 框架的一个不同维度：不是「怎么编排工具」，而是「怎么给 agent 一个干净的执行沙箱」。6
OpenHands 的设计前提是：coding agent 需要一个真实的操作环境——终端、文件系统、浏览器、代码执行。它用 Docker 容器隔离每个 agent 会话，agent 可以在容器里跑测试、提交代码、操作浏览器，出错了直接扔掉容器，不会污染宿主机。
SWE-Bench 评分 77.6%（Claude Sonnet 后端），是当前开源 agent 框架在 GitHub Issue 自动修复任务上的顶点参考值之一。
对比前面几个「工具编排类」框架，OpenHands 更接近「代码生产环境」而非「业务流程自动化」：目标用户是需要把 agent 嵌入 CI/CD、做代码评审、自动修复 bug 的工程团队，而不是搭建客服机器人或数据处理管道的开发者。
升级风险：视使用姿势而定。作为独立的开源工具使用无需关心版本兼容性；以 SDK 方式接入的参考官方文档（[https://docs.[openhands.dev/sdk](https://docs.openhands.dev/sdk)](https://openhands.dev/sdk](https://docs.openhands.dev/sdk))）。
社区观察：runtime 才是 coding agent 的护城河
这周 Reddit r/AI_Agents 有一个帖子的核心观点值得单独拎出来：7
当 agent 开始跨小时乃至跨天工作，瓶颈就不再是「模型能不能写代码」。真正重要的是系统能不能安全地持有上下文、执行动作、从错误中恢复、在正确的时机把控制权交回人类。基础设施层可能才是 coding agent 的真正护城河。
这和 OpenHands 的设计哲学高度吻合——沙箱隔离、检查点回滚、cost ceiling（避免任务悄悄烧光 budget）都是「runtime infrastructure」而非 prompt 工程。
同一时间，另一个帖子问的是「agent 本质上是什么」：
框架在快速迭代，模型在快速迭代，真正属于我的是什么？他的答案是：一个 Markdown 文件夹。知识和指令，而不是工具调用的配线方式。
这两个帖子放在一起，构成了目前社区对「哪层该自研、哪层该复用」的普遍焦虑。工具编排层（langgraph-bigtool、MCP-Zero）和执行 runtime（OpenHands）正在往两个方向把这个问题拆解开。
本期选型矩阵
| 你的场景 | 推荐方向 |
|---|---|
| 企业内部 agent，工具库 >50 个，已在用 LangGraph | langgraph-bigtool |
| 研究/实验：测试 MCP 工具自动发现的可行性 | MCP-Zero（代码复现阶段，不建议生产） |
| 新项目，Google 技术栈，需要确定性流程 + LLM 混合编排 | Google ADK 2.0 |
| coding agent、bug 自动修复、CI/CD 集成、需要沙箱隔离 | OpenHands |
下期预告
下期会继续跟进两个方向：agno（内存层框架，近期 star 增速明显）和 Google ADK 的 Kotlin/Android 版（0.1.0 刚发布，适合移动端 agent 场景）。如果近两周有新出现的 agent 框架引爆 trending，会优先纳入。
이 콘텐츠를 둘러싼 관점이나 맥락을 계속 보강해 보세요.