Loading…

`create_agent` vs 完整 Harness

同样的 agent 抽象为什么要分成"通用 create_agent"和"完整 harness"两档？什么时候应该升一档、什么时候降一档。

Core Curriculum Level 2 · 工程判断阅读时间 · 23 分钟练习 · 建议必做低波动 Last reviewed · 2026-04-22

你将学会什么

建议先读《一个典型 Runtime / LangGraph 漫游》；如果你是跳读，至少先看本章索引与本页 TL;DR。

这页在课程中的位置

runtime 认知层，用来分清编排、执行、持久化与产品边界。

本页 1 句话结论

同样的 agent 抽象为什么要分成"通用 create_agent "和"完整 harness"两档？什么时候应该升一档、什么时候降一档。

带走的判断法

先分清谁负责编排、谁负责执行、谁负责产品化，再评估复杂度。

Source Policy

课程主线：稳定 runtime 机制 + 官方实现。

TL;DR

"在 LangGraph runtime 上跑 agent"有 三档抽象：① 裸 graph 自写每个节点；② create_agent(...) 一行起 ReAct；③ 完整 harness（如 Deep Agents）—— 自带 planner / VFS / task / middleware。
从①到③，代码量从 ~50 行降到 ~5 行，但默认能力从 0 涨到 8 项。代价是"默认能力是别人定义的"——改动它要更多框架知识。
选档的判据不是"复杂度"，是"我会改动多少 / 我接受多少默认值"。改动多 → 降一档；接受默认 → 升一档。
"framework 越来越像产品"是当下趋势——OAI Agents SDK / Deep Agents / Claude Code SDK 都在朝完整 harness 演进。这是好事但有副作用：用户被默认值"教育"出某种 agent 风格，反向限制了想象力。

任务："做一个能查 weather 的 agent，需要支持工具调用循环"。下面看三档实现的代码、能力、line count、改造难度——切换 tab 看：

代码行

—

默认能力

—

改造难度

—

学习曲线

—

从①到②到③，每一档的"内置默认值"叠加变多。同时，"改一项默认值要懂多少"也变多：

维度	① 裸 graph	② create_agent	③ 完整 harness
典型代码量（hello-world）	~ 50 行	~ 8 行	~ 5 行
默认 ReAct loop	×（自写）	✓	✓
默认 system