Agent 编排层的分岔：开源框架分工与托管 Harness 的工程选型

引子：两条同时出现的信号

2026 年 9 月，Agent 工程领域出现两条方向相反、却互相印证的消息。

一条来自模型厂商：托管式 Agents API 上线，把驱动编程智能体的 harness（编排层）与 sandbox 一起打包成服务，一次 API 调用即可创建可连续运行数天的智能体，模型、工具（走 MCP）、执行环境均可指定，配套的 Codex harness 同步开源。

另一条来自开源社区：Pydantic AI v2、LangGraph 1.x、LlamaIndex Workflows 1.0、Strands Agents、Mastra 等框架密集发版，但没有一家再宣称要做唯一的通用框架，而是各自认领一条赛道。

两者合起来看，编排层正经历一次典型分层：通用编排能力下沉为运行时（runtime），框架上浮为特定执行模型的表达方式。

一、Harness 成为标准件之后，中间层还剩下什么

托管 harness 解决的是长时程任务的三个硬问题：上下文接近上限时自动压缩、同时保留继续干活所需的信息；按需加载工具定义（tool search）以节省 token 并保住 prompt 缓存；主代理拆分任务、子代理各带独立上下文并发执行。

这三项能力此前正是 LangGraph、CrewAI 一类框架的核心卖点。当它们变成随模型发布同步版本化的标配，中间层框架的差异化只剩一条：多模型中立。对已深度绑定单一模型生态的团队，自建编排的边际收益正在变薄。

但更准确的判断是：harness 标准化的是执行环境 ，不是流程语义。工单审批要几级回退、风控节点在什么条件下熔断、人工复核卡在哪一步------这些仍是业务资产，仍需要显式的流程表达。

二、开源框架的分工格局

框架	执行模型	最适配场景	语言	替换成本
LangGraph 1.x	显式状态图 + checkpoint	需审计与人机回环的长流程	Python / TS	低
Pydantic AI v2	类型化 agent loop	契约优先的 Python 单体栈	Python	低
LlamaIndex Workflows 1.0	事件驱动 async 组合	文档处理、多步流水线	Python / TS	低
Strands Agents	模型驱动 SDK	云厂商生态集成	Python	中
Mastra	工作流 + RAG + evals	全栈 TypeScript 产品	TypeScript	低

LangGraph 今年的更新值得单独说：节点缓存跳过重跑时的冗余计算；deferred nodes 先把并行分支收拢到屏障再触发下游；模型前后置 hook 把上下文裁剪、护栏、PII 脱敏收敛到模型边界；内容块流式 API 统一输出结构。加上节点级超时与类型化错误处理，它的定位已经很清晰------当你能把流程画成图并说清节点名，它就给你带崩溃恢复和时光回放的执行引擎。

python 复制代码

from typing import TypedDict
from langgraph.graph import StateGraph, START

class AgentState(TypedDict):
    ticket_id: str
        review_status: str      # 必须放进状态对象，否则条件边读不到
            draft: str
                citations: list[str]
def route(state: AgentState) -> str:
    return "publish" if state["review_status"] == "approved" else "revise"
builder = StateGraph(AgentState)
builder.add_node("intake", intake, cache=True)   # 节点缓存
builder.add_node("research", research)
builder.add_node("draft", draft)
builder.add_node("review", review)
builder.add_edge(START, "intake")
builder.add_conditional_edges(
    "review", route,
        {"publish": "publish", "revise": "draft"},
        )
        ```
Pydantic AI v2 走的是另一条路：把指令、工具、hook、设置收拢为单一原语 capability，围绕一个极小的可移植核心做组合。换来的是类型系统在真实项目里的收益------有团队在 90 天基准中统计到，类型检查提前拦下了 23 个此前要到运行时才暴露的问题。代价同样明确：生态规模约为 LangChain 体系的十五分之一。

## 三、选型的三个问题

1. **流程能不能画成图？** 能，且需要持久化、人机回环、审计链路------LangGraph。
2. **契约优先还是编排广度优先？** 输入输出与工具签名必须强类型------Pydantic AI。
3. **是不是事件驱动的多步管道？** 触发、拉取、转换、闸门、发布这类结构------Workflows 1.0 的心智模型与既有 webhook / cron 几乎一一对应，迁移成本最低。
另有两个协议应纳入架构决策：MCP 负责代理到工具的连接（给代理一双手），A2A 负责代理之间的协同（给代理一群同事）。它们让框架选择从"押注公司"退化为"挑选组件"------CrewAI 的 crew 可以复用 LangGraph 代理也在用的 MCP server。

## 四、两个容易踩的坑

**其一，状态对象的边界。** 图式框架要求所有节点间传递的数据都经过状态对象。把字段定义在状态之外，条件边会静默读不到值------这类问题不报错，只会让流程走错分支。建议在状态类上引入严格校验，并给每个条件边写单元测试。

**其二，迁移收益被高估或低估。** 公开案例数据可作参照：某审计流程迁移到托管 harness 后单案例成本下降约六成；把 harness 与环境分离后失败响应下降约 86%；启用子代理并发后延迟改善约四倍、评估分从 0.71 提升到 0.85。但这些数字都来自"自建编排迁移到托管"的场景。反过来说，如果你的复杂度还停在一段 API 调用加几次工具调用，**最该做的可能是不引入框架。**

## 结语

编排层的竞争，正从"谁的抽象更全"转向"谁的执行模型更贴合你的流程形状"。框架的名字不重要，重要的是先写清状态转移图，再决定把哪些环节交给托管运行时、哪些留在自己的代码里。保持可替换性，是这一轮技术周期里最划算的架构投资。

**技术标签**：#AI Agent #LangGraph #Pydantic AI #MCP #架构设计 #工程实践