第 7 章：四大 Agent 框架的设计取舍

我遇到了什么问题

前六章讲完了我自己的 Agent 架构演化过程。每一章都提到了其他框架的做法，但都是点到为止。

这一章把四个框架拉出来，正面比较。

但比较之前，先说清楚一件事：没有"最好的框架"，只有"最适合你的场景的取舍"。

每个框架的设计决策，都是在回答同一个问题的不同面：Agent 应该怎么被控制？

四个框架，四个答案

LangGraph：用"图"控制

核心思想：Agent 的行为由图的结构决定。

用户输入 → 节点 A（理解意图）
           ├── 条件边（是查询类？）→ 节点 B（数据库查询）→ 结束
           ├── 条件边（是操作类？）→ 节点 C（执行操作）→ 节点 D（确认）→ 结束
           └── 条件边（都不匹配？）→ 节点 E（兜底回复）→ 结束

LangGraph 把 Agent 建模为一个有向图。节点是处理步骤，边是流转条件。Agent 不能做图里没有定义的事。

核心取舍：

• 优势：确定性强。你画的图就是 Agent 的行为边界，不会超出。
• 代价：灵活性差。加一个新能力就要改图结构。对于"不确定要做什么"的开放场景，图会变得极其复杂。

适合场景：流程明确的业务自动化——客服机器人、工单处理、数据管道。

我的评价：LangGraph 的思路适合"我知道 Agent 要做什么，但不确定走哪条路"的场景。但对于"我不知道用户会问什么"的开放对话场景，图编排太重了。

微软 Agent Framework (MAF)：用"管道"控制

核心思想：Agent 的能力通过装饰器管道叠加。

基础 ChatClient
  → LoggingChatClient（日志）
    → OpenTelemetryChatClient（追踪）
      → CustomRetryingChatClient（重试）
        → FunctionInvokingChatClient（工具调用循环）
          → CompactionChatClient（上下文压缩）
            → 最终 Agent

MAF 把 Agent 建模为一个装饰器管道。每个装饰器做一件事——日志、重试、监控、压缩、工具调用。通过组合不同的装饰器，构建不同能力的 Agent。

核心取舍：

• 优势：可组合性强。加一个新能力就加一个新装饰器，不需要改现有代码。完美符合开闭原则。
• 代价：调试复杂。管道越长，出了问题越难定位。你需要理解整个管道的执行顺序。

适合场景：企业级 .NET 应用——需要可观测性、安全合规、评估校验的场景。

我的评价：MAF 的设计是四个框架中最"工程化"的。我的 Harness 架构大量参考了 MAF——装饰器管道、EvalCheck、上下文提供者链，都是 MAF 的核心概念。但 MAF 的学习曲线也最陡——你需要理解 .NET 的装饰器模式、依赖注入、中间件管道等概念。

AgentScope Java：用"安全"控制

核心思想：Agent 必须在人的监督下工作。

Agent 执行中
  ├── 安全检查 → 发现危险操作 → 安全中断（立即停止）
  ├── 进度检查 → 超过时间限制 → 优雅取消（保存状态后停止）
  └── 决策点 → 需要人工确认 → 人工注入（等待人的指令）

AgentScope 把 Agent 建模为一个可中断的循环。核心不是"Agent 能做什么"，而是"人什么时候可以介入"。

核心取舍：

• 优势：安全性高。人随时可以中断、取消、注入指令。适合高风险场景。
• 代价：效率低。频繁的人工介入会降低自动化程度。

适合场景：金融、医疗、法律等对安全性要求极高的企业场景。

我的评价：AgentScope 的 RAG 生态也很丰富——5 个 RAG 扩展（百炼、Dify、RAGFlow、HayStack、pgvector），是四个框架中 RAG 支持最完善的。但它的 Agent 控制思路偏保守——适合"不能出错"的场景，不适合"快速迭代"的场景。

Hermes：用"插件"控制

核心思想：Agent 的能力通过插件动态扩展。

Agent 核心
  ├── 工具自动发现 → 新增工具自动可用
  ├── 插件系统 → 按需加载/卸载能力
  ├── 多平台网关 → Slack/终端/Web/定时任务
  └── Skill 市场 → 社区共享 Skill

Hermes 把 Agent 建模为一个可扩展的核心 + 可插拔的能力。核心只做"理解意图 → 调用工具 → 返回结果"，其他一切都由插件提供。

核心取舍：

• 优势：扩展性最强。加一个新能力就是加一个插件，Agent 自动发现并使用。
• 代价：控制力最弱。工具自动发现意味着你无法精确控制"Agent 在什么场景下用什么工具"。

适合场景：终端极客、个人开发者、快速原型。

我的评价：Hermes 是四个框架中最"酷"的——多平台网关、插件市场、Skill 自动发现。但它的设计哲学是"让 Agent 自己搞定"，缺少企业级需要的治理和监控。

一张对比表

维度	LangGraph	MAF	AgentScope Java	Hermes	我的 Components
控制方式	图结构	装饰器管道	可中断循环	插件系统	管道 + Provider
确定性	最高	高	中	低	中
灵活性	低	高	中	最高	高
学习曲线	中	最高	中	低	中
可观测性	弱	最强	中	弱	强
安全控制	中	强	最强	弱	中
RAG 支持	通过 LangChain	内置	5 个扩展	弱	RepoWiki
多 Agent	子图	Agent 组合	Pipeline	弱	Lead-Sub
语言	Python/JS	.NET/Python	Java	Python	.NET

我的选择：为什么是"管道 + Provider"

看完四个框架，我的 Components 走的是 MAF 的路线，但做了简化：

借鉴 MAF 的：

• 装饰器管道模式（日志 → 重试 → 工具调用 → 压缩）
• EvalCheck 评估校验
• 上下文提供者链（AIContextProvider）

没有借鉴的：

• MAF 的完整 EvalCheck 体系太重——我只用了核心委托模型
• MAF 的多层 Agent 组合——我用 Lead-Sub 两层就够了

自己加的：

• Provider 可覆盖模式（核心层注册默认空实现，业务层覆盖）
• Skill + Rule 双轨规范体系
• RepoWiki 结构化检索（替代 RAG + 向量库）

为什么不全盘照搬 MAF？因为过度设计比设计不足更危险。

MAF 是一个面向全行业的框架——它要考虑金融、医疗、法律等各种场景。我的 Components 是面向自己的产品的——我只需要考虑"企业自动化"这一个场景。

过度设计的代价是：

• 代码量翻倍
• 学习成本翻倍
• 维护成本翻倍

设计不足的代价是：

• 遇到新场景要改代码

对于我的场景，"遇到新场景改代码"的成本远低于"维护一个过度设计的框架"的成本。

关键认知

这一章的关键认知：

框架选型不是选"最强的"，是选"取舍最合适的"。

四个框架代表了四种控制哲学：

• LangGraph：用结构控制（图）
• MAF：用管道控制（装饰器）
• AgentScope：用安全控制（中断）
• Hermes：用扩展控制（插件）

每种哲学都有它最适合的场景。没有对错，只有取舍。

我的选择是 MAF 的管道 + 自己的简化。因为我的场景是"企业自动化"——需要可观测性、需要评估校验、但不需要金融级的安全控制。

下一章要讨论一个更宏观的问题：Agent Flow 和低代码编排，到底是两条路线还是一条路线？